基于SPICE協(xié)議的云終端傳輸協(xié)議研究

1

背景

傳輸協(xié)議作為“終端”與“算力”的連接通道，其穩(wěn)定性及傳輸效率決定了終端算力應(yīng)用的用戶體驗(yàn)，是產(chǎn)品向用戶提供“一點(diǎn)接入、即取即用”算力服務(wù)的核心關(guān)鍵與重要保障。

行業(yè)內(nèi)主流的云終端傳輸協(xié)議的應(yīng)用主要集中在VMWare的PCoIP協(xié)議、Citrix的ICA協(xié)議、Microsoft的RDP協(xié)議和RedHat的SPICE協(xié)議。其中SPICE協(xié)議是唯一完全開(kāi)源的協(xié)議，多數(shù)云電腦廠商在開(kāi)發(fā)產(chǎn)品時(shí)大都會(huì)參考SPICE協(xié)議的架構(gòu)進(jìn)行傳輸協(xié)議的開(kāi)發(fā)。SaaS產(chǎn)品部算力服務(wù)產(chǎn)品組為了實(shí)現(xiàn)云電腦關(guān)鍵技術(shù)自主掌控，基于SPICE協(xié)議，同時(shí)借鑒前沿的WebRTC、QUIC等協(xié)議，從帶內(nèi)協(xié)議改造、編解碼優(yōu)化、廣域網(wǎng)傳輸、虛擬顯示方案、USB重定向、SDK優(yōu)化等6方面探索云終端傳輸協(xié)議的產(chǎn)品化思路。

2

SPICE協(xié)議原理詳解

2.1 整體架構(gòu)

SPICE協(xié)議從結(jié)構(gòu)上可以分為四個(gè)組成部分：

虛擬機(jī)側(cè)（guest）：部署在服務(wù)器側(cè)、提供虛擬桌面服務(wù)的虛擬機(jī)中，用于接收操作系統(tǒng)和應(yīng)用程序的圖形命令，如虛擬圖形適配器（QXL driver）以及代理(VDI Agent)；

服務(wù)端側(cè)（spice server）：以libspice動(dòng)態(tài)庫(kù)形式供虛擬機(jī)監(jiān)控管理程序(qemu)使用；

客戶端側(cè)（spice client）：終端用戶交互操作遠(yuǎn)程虛擬機(jī)的程序(remote-viewer或者spice-gtk)；

協(xié)議部分（spice protocol）：定義了SPICE各個(gè)組件之間通信的消息和規(guī)則。

各部分之間的關(guān)系如圖所示：

圖2.1 SPICE協(xié)議相關(guān)組件之間的關(guān)系

SPICE協(xié)議整體架構(gòu)，如下圖所示?？蛻舳诉\(yùn)行在用戶終端設(shè)備上，為用戶提供桌面環(huán)境。SPICE服務(wù)端以動(dòng)態(tài)鏈接庫(kù)的形式與KVM虛擬機(jī)整合，通過(guò)SPICE協(xié)議與客戶端進(jìn)行通信。

圖2.2 SPICE協(xié)議架構(gòu)

從架構(gòu)圖上可以看出，Client和Server通過(guò)channels進(jìn)行通信，每個(gè)channel類型對(duì)應(yīng)著特定的數(shù)據(jù)類型。每個(gè)channel使用專門的TCP socket，這個(gè)socket可以是安全的(使用SSL)或者不安全的。關(guān)于channel的細(xì)節(jié)將在后續(xù)章節(jié)講解。

2.2 Server端原理詳解

SPICE服務(wù)端是通過(guò)libspice實(shí)現(xiàn)的，libspice是一個(gè)虛擬設(shè)備接口(VDI)可插拔庫(kù)。一方面，服務(wù)器使用SPICE協(xié)議與遠(yuǎn)程客戶端通信；另一方面，SPICE協(xié)議與VDI主機(jī)應(yīng)用程序（例如QEMU）進(jìn)行交互。服務(wù)端架構(gòu)圖如圖2.3所示，服務(wù)端通過(guò)各種通道與客戶端進(jìn)行通信，包括主通道、輸入通道、回放通道、記錄通道、顯示通道和光標(biāo)通道。

每個(gè)通道傳輸不同類型的數(shù)據(jù)，例如主通道傳輸一些簡(jiǎn)單控制指令、輸入通道傳輸鼠標(biāo)鍵盤等消息、顯示通道傳輸桌面顯示相關(guān)數(shù)據(jù)等，并且每個(gè)通道使用一個(gè)專用的TCP套接字。

圖2.3 服務(wù)端架構(gòu)圖

服務(wù)端與虛擬機(jī)之間的通信需要借助QEMU虛擬化出QXL接口和I/O接口。I/O接口包含代理接口、輸入接口和音頻接口（回放接口和記錄接口），分別完成與主通道、輸入通道、回放通道和記錄接口的建立。QXL接口通過(guò)虛擬機(jī)中的QXL驅(qū)動(dòng)完成圖形設(shè)備接口的封裝調(diào)用，方便對(duì)顯示通道和光標(biāo)通道進(jìn)行操作。與I/O接口不同的是，QXL接口可以有多個(gè)，以便支持多屏顯示等功能。

SPICE圖形系統(tǒng)結(jié)構(gòu)圖如圖2.4所示，Red Sever為每一個(gè)QXL接口發(fā)起調(diào)度請(qǐng)求，而Red Dispatcher會(huì)通過(guò)通道的套接字創(chuàng)建Red Worker。Red Dispatcher負(fù)責(zé)QXL的調(diào)度工作。當(dāng)程序初始化、圖像壓縮更改、視頻流變化、鼠標(biāo)模式設(shè)置時(shí)，就會(huì)新建Red Worker進(jìn)行具體的處理。Red Worker負(fù)責(zé)處理具體的QXL命令，需要對(duì)顯示通道和光標(biāo)通道進(jìn)行管理，包括通信管道的維度、圖像壓縮、視頻流創(chuàng)建和編碼、緩存控制等。

圖2.4 圖形系統(tǒng)架構(gòu)圖

綜合上述，SPICE服務(wù)端核心的三個(gè)組件分別為：

(1) Red Server (reds.c)

Red Server主要用來(lái)監(jiān)聽(tīng)客戶端連接請(qǐng)求，接受連接并與客戶端通信，主要負(fù)責(zé)：

通道

管理通道(注冊(cè)，注銷，停止)

通知Client活動(dòng)的通道，便于Client創(chuàng)建它們

主通道和輸入通道的管理

socket操作以及鏈接管理

處理SSL和ticketing

VDI接口處理(增加，移除)

處理用戶命令

和Guest Agent通信

(2) Red Worker(red_worker.c)

SPICE服務(wù)端為每個(gè)QXL接口創(chuàng)建一個(gè)工作者線程(Red Worker)，Red Worker主要負(fù)責(zé)：

處理QXL設(shè)備命令(draw, update, cursor等)

處理接受自Red分配器的消息

顯示通道和光標(biāo)通道管理

圖像壓縮(使用quic, lz, glz 編碼)

視頻流處理(鑒別視頻流，創(chuàng)建流和編碼)

(3) Red Dispatcher(red_dispatcher.c)

Red Dispatcher主要用于QXL的調(diào)度工作，主要負(fù)責(zé)：

為每個(gè)QXL實(shí)例一個(gè)調(diào)度器

創(chuàng)建和初始化Red Worker線程

執(zhí)行QXL的調(diào)度工作

2.3 Guest端原理詳解

在SPICE協(xié)議中，Guest端即是用戶所使用的虛擬機(jī)，目前Guest端支持windows，linux等不同操作系統(tǒng)的虛擬化。Guest端由虛擬化的硬件構(gòu)成，通過(guò)SPICE將內(nèi)容遠(yuǎn)程傳輸至Client端供用戶操作使用，Guest端的用戶體驗(yàn)存在瓶頸，為此SPICE協(xié)議在Guest端中設(shè)計(jì)了Vdagent和qxl兩個(gè)模塊以增強(qiáng)用戶的使用體驗(yàn)。

圖2.5 guest框架圖

（1）Vdagent

Vdagent是運(yùn)行于Guest端中的應(yīng)用程序，通過(guò)qemu創(chuàng)建的特定spicemvc設(shè)備與Server進(jìn)行通訊。Vdagent既是Client端、Server端的指令執(zhí)行器，也是Guest端的事件監(jiān)聽(tīng)器。在基礎(chǔ)的用戶使用上，如鍵鼠同步、音畫顯示等功能皆可通過(guò)qemu提供的虛擬硬件接口進(jìn)行實(shí)現(xiàn)，但由于Client端是以應(yīng)用程序的形式運(yùn)行在客戶物理機(jī)中，使得Guest端和用戶物理機(jī)間接產(chǎn)生了交互，因此Vdagent實(shí)現(xiàn)了以下四種功能以增強(qiáng)用戶體驗(yàn)。

Client端鼠標(biāo)模式

基于qemu，spcie協(xié)議提供了一種Server端鼠標(biāo)控制模式，該模式通過(guò)接收Client端的鼠標(biāo)位移矢量對(duì)qemu虛擬鼠標(biāo)進(jìn)行相對(duì)位移控制。而Vdagent實(shí)現(xiàn)了一種Client端鼠標(biāo)模式，該模式拋棄了qemu提供的虛擬鼠標(biāo)接口，轉(zhuǎn)而在Vdagent中通過(guò)Client端鼠標(biāo)的相對(duì)位置信息移動(dòng)Guest端鼠標(biāo)。

相比而言，Vdagent的Client端鼠標(biāo)模式可以適應(yīng)更加復(fù)雜的網(wǎng)絡(luò)傳輸環(huán)境，在丟包嚴(yán)重的網(wǎng)絡(luò)狀況下也可以保證整體的控制效果，減少鼠標(biāo)拖影等情況的出現(xiàn)。

分辨率自適應(yīng)

在用戶看來(lái)，協(xié)議的Client端就是運(yùn)行在用戶物理機(jī)上的一個(gè)窗口程序，應(yīng)是可以切換窗口大小的。若沒(méi)有分辨率自適應(yīng)功能，那么在窗口大小切換后，會(huì)導(dǎo)致Client端與Guest端分辨率不匹配，從而桌面畫面出現(xiàn)放大、縮小，甚至顯示不完全或黑邊問(wèn)題。因此，vdagent通過(guò)調(diào)用QXL調(diào)整Guest端分辨率以適應(yīng)Client端窗口大小的方式避免分辨率匹配問(wèn)題。

共享剪切板

若用戶同時(shí)使用其本地的物理機(jī)和Guest端來(lái)進(jìn)行工作學(xué)習(xí)，那么兩臺(tái)機(jī)器之間的文本共享就顯得十分有必要?；诖薈lient端和Vdagent兩端都實(shí)現(xiàn)了剪切板的監(jiān)聽(tīng)與寫入功能，當(dāng)一方的本地剪切板更新時(shí)，另一方便會(huì)接收到該剪切板數(shù)據(jù)并更新其對(duì)應(yīng)的剪切板，以此實(shí)現(xiàn)共享剪切板數(shù)據(jù)。

文件傳輸功能

同共享剪切板類似，兩臺(tái)機(jī)器之前的文件傳輸也同文本共享一樣重要，用戶物理機(jī)可直接選擇文件并拖拽到Client端窗口以啟動(dòng)文件傳輸，而Vdagent則會(huì)將接收文件放在Guest端的指定路徑下。

（2）QXL

廣義上的QXL指顯示模塊，而狹義上的QXL則分為兩部分，一部分是由qemu創(chuàng)建的QXL顯卡設(shè)備，另一部分則是Guest端中對(duì)應(yīng)QXL顯卡的QXL驅(qū)動(dòng)。Guest端的畫面必須經(jīng)過(guò)顯卡繪制，而QXL顯卡僅是qemu通過(guò)cpu虛擬而來(lái)，因此性能較差，在沒(méi)有QXL驅(qū)動(dòng)情況下，畫面刷新存在明顯割裂。

為此，guest端針對(duì)不同系統(tǒng)開(kāi)發(fā)了功能相同的QXL驅(qū)動(dòng)，一方面增強(qiáng)了QXL顯卡處理畫面的效果，另一方面也提供了調(diào)用QXL顯卡實(shí)現(xiàn)調(diào)整分辨率的接口供vdagent實(shí)現(xiàn)分辨率自適應(yīng)功能。

2.4 Client端原理詳解

SPICE客戶端主要作用是解析和渲染遠(yuǎn)端發(fā)送的數(shù)據(jù)，提供遠(yuǎn)程訪問(wèn)虛擬機(jī)桌面的能力。SPICE Server端和Client端均采用了模塊化的思想、多通道的解決方案來(lái)實(shí)現(xiàn)遠(yuǎn)程桌面的傳輸。其優(yōu)點(diǎn)是降低了代碼的耦合度，便于通過(guò)橫向擴(kuò)展來(lái)支持新的功能。SPICE的每一個(gè)通道都提供一個(gè)特定的功能。Client基礎(chǔ)架構(gòu)如圖2.6所示。

為了擁有一個(gè)純凈的跨平臺(tái)結(jié)構(gòu)，SPICE定義了一套通用的接口（Platform類），將其特定于平臺(tái)的實(shí)現(xiàn)保留在并行目錄中。這套接口定義了許多低級(jí)服務(wù)，例如定時(shí)器和光標(biāo)操作。

Application是主類，它包含和控制Client，monitors和screens。主要功能有解析命令行參數(shù)，運(yùn)行主消息循環(huán)，處理事件（連接、斷開(kāi)連接、錯(cuò)誤等），將鼠標(biāo)事件重定向到輸入處理程序，切換全屏模式等。

（1）Channels

Client和server通過(guò)channels進(jìn)行通信。每種channel類型用于特定類型的數(shù)據(jù)。每個(gè)channel都使用專用的TCP套接字，可以是安全（使用SSL）或不安全。在Client端，每個(gè)通道都有一個(gè)線程，可以通過(guò)區(qū)分線程優(yōu)先級(jí)來(lái)為每個(gè)通道提供不同的QoS。

RedClient - main channel類，它能夠控制其他實(shí)例化channel（使用工廠模式創(chuàng)建channel，連接、斷開(kāi)連接等）。

圖2.6 客戶端基礎(chǔ)架構(gòu)圖

- 所有channel的祖先是：

RedPeer - 用于安全和不安全通信的socket封裝類，提供基礎(chǔ)功能，例如connect，disconnect，close，send，receive和用于遷移的套接字交換。它定義了通用消息類：InMessages，CompoundInMessage和OutMessage。所有消息都包括type，size和data。

RedChannelBase - 繼承于RedPeer，提供與Server建立通道連接的基本功能，并支持與服務(wù)器的通道功能交換。

RedChannel - 繼承于RedChannelBase。此類是所有實(shí)例化channel的父級(jí)。處理發(fā)送傳出消息和分派傳入消息。RedChannel線程運(yùn)行具有各種事件源的事件循環(huán)（例如，發(fā)送和中止觸發(fā)器）。通道套接字被添加為事件源，用于觸發(fā)SPICE消息的發(fā)送和接收。

- 可用的channel有：

Main - 由RedClient實(shí)現(xiàn)

DisplayChannel - 處理圖形命令，圖像和視頻流

InputsChannel - 鍵盤和鼠標(biāo)輸入

CursorChannel - 指針設(shè)備位置，可見(jiàn)性和光標(biāo)形狀

PlaybackChannel - 從server端接收的音頻，由Client播放

RecordChannel - 在Client捕獲的音頻

（2）Screens and Windows

ScreenLayer - screen layer被附加到特定screen，提供矩形區(qū)域的操作（set，clear，update，invalidate等）。

RedScreen - 使用screen layers（例如，顯示，光標(biāo)）來(lái)實(shí)現(xiàn)screen邏輯并控制窗口來(lái)顯示其內(nèi)容。

RedDrawable - 特定于平臺(tái)的basic pixmap的實(shí)現(xiàn)。支持基本渲染操作（例如，復(fù)制(copy)，混合(blend)，組合(combine）。

RedWindow_p - 特定于平臺(tái)的窗口數(shù)據(jù)和方法。

RedWindow - 繼承于RedDrawable和RedWindow_p。實(shí)現(xiàn)了基本窗口狀態(tài)和跨平臺(tái)相關(guān)的功能（例如，顯示，隱藏，移動(dòng)，最小化，設(shè)置標(biāo)題，設(shè)置光標(biāo)等）。

3

SPICE協(xié)議產(chǎn)品化改造方案

SPICE協(xié)議具有完全開(kāi)源這個(gè)最大的優(yōu)勢(shì)，方便對(duì)其進(jìn)行功能的擴(kuò)展以及適配特定場(chǎng)景的二次開(kāi)發(fā)。但同時(shí)在產(chǎn)品化方面短板也很明顯。SPICE協(xié)議要實(shí)現(xiàn)產(chǎn)品化的改造，仍然存在著許多亟待解決的問(wèn)題。例如視頻處理能力不足、網(wǎng)絡(luò)傳輸帶寬占用過(guò)大、畫面容易出現(xiàn)卡頓、用戶使用體驗(yàn)差等突出問(wèn)題。本文針對(duì)通用場(chǎng)景下的用戶體驗(yàn)，提出了一些產(chǎn)品化改造的思路。

3.1 帶內(nèi)協(xié)議改造

SPICE協(xié)議是一種典型的帶外協(xié)議，帶外協(xié)議是指客戶端通過(guò)QEMU層與服務(wù)端進(jìn)行交互，這一特點(diǎn)導(dǎo)致SPICE協(xié)議嚴(yán)重依賴于QEMU，使其喪失靈活性。為了更好地與移動(dòng)云的底層虛擬化層進(jìn)行對(duì)接，也為了降低對(duì)QEMU的依賴，需要將SPICE協(xié)議改造成帶內(nèi)協(xié)議。

帶內(nèi)協(xié)議與帶外協(xié)議最大的區(qū)別在于SPICE服務(wù)端的位置不同。帶外協(xié)議的架構(gòu)圖如圖3.1所示，SPICE服務(wù)端位于QEMU層，分別通過(guò)QXL設(shè)備和VDI端口與虛擬機(jī)的QXL驅(qū)動(dòng)和VDI代理進(jìn)行交互?？蛻舳诵枰ㄟ^(guò)宿主機(jī)的IP地址加上端口號(hào)連接上SPICE服務(wù)端，不同的虛擬機(jī)需要不同的端口進(jìn)行連接。

圖3.1 帶外協(xié)議結(jié)構(gòu)圖

帶內(nèi)協(xié)議的架構(gòu)圖如圖3.2所示，SPICE服務(wù)端位于虛擬機(jī)中，作為Guest中的一個(gè)SPICE進(jìn)程，負(fù)責(zé)數(shù)據(jù)的傳輸。Guest除了QXL驅(qū)動(dòng)和VDI代理之外，需要實(shí)現(xiàn)抓屏和視頻編碼的功能。帶外協(xié)議的視頻編碼功能是在服務(wù)端實(shí)現(xiàn)的，帶內(nèi)協(xié)議需要借助DXGI等工具實(shí)現(xiàn)抓屏并傳輸，并在Guest端實(shí)現(xiàn)視頻的編碼。服務(wù)端與客戶端的傳輸部分，借助WebRTC傳輸技術(shù)，實(shí)現(xiàn)更高效、穩(wěn)定的數(shù)據(jù)通信。

圖3.2 帶內(nèi)協(xié)議架構(gòu)圖

目前，SPICE協(xié)議的帶內(nèi)改造有兩種較為可行的方案，如圖3.3所示。方案一是將SPICE服務(wù)端和QEMU有關(guān)SPICE的初始化和調(diào)用部分代碼遷移到SPICE進(jìn)程中，使得SPICE成為一個(gè)可執(zhí)行的服務(wù)，該服務(wù)負(fù)責(zé)完成系統(tǒng)底層的數(shù)據(jù)交互，并通過(guò)多通道與客戶端進(jìn)行連接；方案二是借助SPICE流代理組件，流代理負(fù)責(zé)完成抓屏、編碼等功能，并通過(guò)遷移到虛擬機(jī)中l(wèi)ibspice與客戶端進(jìn)行連接。兩種方案的目的相同，均是將SPICE服務(wù)端移植到虛擬機(jī)，但實(shí)現(xiàn)方式不同。難點(diǎn)都在于SPICE服務(wù)端作為QEMU的一個(gè)動(dòng)態(tài)庫(kù)，只包含被QEMU調(diào)用的接口，初始化部分和調(diào)用部分需要從QEMU中移植出來(lái)，并將其改造成兼容不同操作系統(tǒng)的服務(wù)。綜上所述，方案二使用SPICE流代理組件實(shí)現(xiàn)抓屏、編碼等功能可行性更高，也更易于實(shí)現(xiàn)，方案二作為帶內(nèi)改造方案更加合適。

圖3.3 帶內(nèi)改造方案

3.2 H.26x編解碼集成

（1）H.264編解碼集成

H.264是國(guó)際標(biāo)準(zhǔn)化組織（ISO）和國(guó)際電信聯(lián)盟（ITU）共同提出的繼MPEG4之后的新一代數(shù)字視頻壓縮格式。在SPICE中，H.264主要是通過(guò)Gstreamer中的x264enc實(shí)現(xiàn)。目前，Gstreamer主要用于處理音頻或視頻。x264enc是Gstreamer的插件，是基于x264庫(kù)實(shí)現(xiàn)H.264編碼的一種具體方案。

具體的集成過(guò)程如下：首先在spice-server的物理機(jī)上安裝x264編碼庫(kù)，接著安裝Gstreamer。在Gstreamer中，x265enc在gst-plugins-bad插件包中，正確安裝該插件包后，安裝spice-server即可在Server端開(kāi)啟H264編碼。同樣的，客戶端正確安裝Gstreamer后，可以進(jìn)行H264解碼。

Gstreamer的核心就是管道，將數(shù)據(jù)流輸入管道，經(jīng)過(guò)管道的處理后輸出數(shù)據(jù)流。在sever端的H.264編碼中，管道使用x264enc對(duì)數(shù)據(jù)流進(jìn)行編碼后，最輸出H.264數(shù)據(jù)流并發(fā)送至客戶端?？蛻舳诉M(jìn)行解碼處理后，將圖形界面顯示到客戶端上。在SPICE中，對(duì)Gstreamer中H.264編碼管道的具體描述如下：

appsrc is-live=true format=time do-timestamp=true name=src ! videoconvert ! x264enc name=encoder byte-stream=true qp-min=15 qp-max=35 tune=4 sliced-threads=true speed-preset=ultrafast intra-refresh=true ! appsink name=sink

H.264編碼管道主要由四個(gè)元素構(gòu)成，分別是appsrc，videoconvert，x264enc和appsink。其中appsrc主要是獲取應(yīng)用程序的數(shù)據(jù)，將其插入到Gstreamer的管道中。videoconvert的主要功能是轉(zhuǎn)換多種視頻格式，具體而言是在SPICE中將appsrc獲取的數(shù)據(jù)流格式轉(zhuǎn)換為下一個(gè)元素，如x264enc，能夠接收的視頻格式。appsink是一個(gè)sink的應(yīng)用程序插件，能夠使得應(yīng)用程序獲取管道中的數(shù)據(jù)流。以上三個(gè)元素為Gstreamer常用的元素。

在H.264編碼中，核心是x264enc元素。x264enc主要是將原始視頻編碼為H.264編碼格式，在x264enc的屬性控制中，qp代表量化器參數(shù)，qp相關(guān)的參數(shù)與碼率控制相關(guān)，當(dāng)啟用了qp相關(guān)的參數(shù)設(shè)置，x264enc將使用QP模式，qp的值反應(yīng)了編碼后圖像的質(zhì)量與原始視頻流質(zhì)量的差距，當(dāng)量化參數(shù)qp=0時(shí)，編碼器將產(chǎn)生無(wú)損的輸出，當(dāng)量化參數(shù)qp=51（x264enc可設(shè)置的最大量化器）時(shí)，圖像的質(zhì)量將會(huì)降到最低，但是碼率會(huì)提升。

目前，Server端能夠完成H.264編碼，流量帶寬有明顯下降。H.264的解碼工作主要由Client端完成，使用基于Gstreamer的H.264解碼器。在Client具體的實(shí)現(xiàn)主要是由uridecodebin插件實(shí)現(xiàn)，該插件可以根據(jù)給定的uri，自動(dòng)選擇合適的音視頻解碼器，從而屏蔽了不同媒體的封裝類型和解碼器的類型。在Client端中，首先采用同樣采取appsrc將數(shù)據(jù)流從應(yīng)用程序中獲取出來(lái)，decodebin會(huì)自動(dòng)檢測(cè)輸入數(shù)據(jù)流的格式并在后臺(tái)構(gòu)造相應(yīng)的Gstreamer元素來(lái)進(jìn)行解碼。decodebin插入typefind元素來(lái)確定流的媒體類型，在H.264解碼過(guò)程中，視頻流的數(shù)據(jù)格式為h-x264，使用h264parse元素來(lái)分割輸出H.264幀數(shù)據(jù)，使用avdec_h264進(jìn)行解碼，解碼后使用videoconvert將視頻流轉(zhuǎn)換成appsink能夠接收的方式，進(jìn)而傳輸至應(yīng)用程序進(jìn)行渲染成像。

圖3.5 H.264解碼器管道

（2）H.265編解碼集成

H.265是ITU-T VCEG繼H.264之后所制定的新的視頻編碼標(biāo)準(zhǔn)。在server端，H.265的集成同樣是基于Gstreamer的，采用的是x265enc編碼器，最終具體實(shí)現(xiàn)的管道描述如下：

appsrc is-live=true format=time do-timestamp=true name=src ! videoconvert ! video/x-raw,format=(string)I420 ! x265enc name=encoder tune=4 speed-preset=ultrafast ! video/x-h265, stream-format=byte-stream, alignment=au, profile=(string)main ! appsink name=sink

與H.264相同，H.265的管道輸入的原始數(shù)據(jù)流同樣是從應(yīng)用程序中獲取，因此仍然采用appsrc獲取數(shù)據(jù)，通過(guò)videoconvert將視頻轉(zhuǎn)換成x265enc能夠處理的數(shù)據(jù)格式。與H.264不同的是，此處顯式的給出了videoconvert的輸出數(shù)據(jù)格式，為I420格式，原因在于，采用的x265enc版本對(duì)于I420格式適應(yīng)較好。相較于x264enc，x265enc的參數(shù)量較少，在SPICE中目前僅設(shè)置tune與speed-preset=ultrafast來(lái)控制碼率與圖像質(zhì)量。需要指出的是，在開(kāi)發(fā)過(guò)程中，H.265相較于H.264，采用的x265enc不成熟，在H.265理論上可行的方案并沒(méi)有完全支持，因此需要顯式地指出數(shù)據(jù)的各種格式，如果數(shù)據(jù)流沒(méi)有指定視頻格式，可能會(huì)導(dǎo)致數(shù)據(jù)流錯(cuò)誤，無(wú)法進(jìn)行正確地編碼。H.265解碼工作與H.264工作類似，僅需要將h264parse與avdec_h264替換為h265parse與avdec_h265，該工作可以由decodebin進(jìn)行自行處理完成替換。

3.3 廣域網(wǎng)環(huán)境傳輸優(yōu)化

（1）SPICE在廣域網(wǎng)的局限性

SPICE的三大模塊相互隔離，為保證模塊間的通信，SPICE基于qemu虛擬硬件實(shí)現(xiàn)了Server端與Guest端的通信。而Client端與Server端通常安裝在不同的物理機(jī)上，因此采用TCP傳輸協(xié)議建立二者的數(shù)據(jù)通道。

在局域網(wǎng)環(huán)境下TCP協(xié)議尚能滿足視音頻傳輸?shù)男枨?，而在較為復(fù)雜的廣域網(wǎng)環(huán)境中，TCP協(xié)議較大的數(shù)據(jù)頭部和阻塞、丟包重發(fā)等機(jī)制都會(huì)增加數(shù)據(jù)在長(zhǎng)鏈路網(wǎng)絡(luò)下的延遲和額外帶寬消耗。SPICE是實(shí)時(shí)桌面?zhèn)鬏攨f(xié)議，遠(yuǎn)程數(shù)據(jù)不僅包含實(shí)時(shí)音視數(shù)據(jù)，還包括其他實(shí)時(shí)指令數(shù)據(jù)，對(duì)網(wǎng)絡(luò)傳輸?shù)难舆t和吞吐有著較高的要求。為實(shí)現(xiàn)SPICE移植到廣域網(wǎng)下的需求，勢(shì)必需要對(duì)傳輸進(jìn)行優(yōu)化。

（2）基于QUIC協(xié)議的傳輸優(yōu)化

QUIC是由谷歌對(duì)標(biāo)TCP制定的一種基于UDP的應(yīng)用層可靠傳輸協(xié)議,相比TCP在傳輸層實(shí)現(xiàn)的可靠性，QUIC在應(yīng)用層實(shí)現(xiàn)的可靠性更能適應(yīng)復(fù)雜網(wǎng)絡(luò)，因此在網(wǎng)絡(luò)情況較為復(fù)雜的廣域網(wǎng)，QUIC可以充分利用底層UDP的特點(diǎn)，在保證數(shù)據(jù)傳輸可靠性的前提下，降低傳輸延遲、提高傳輸速率。

圖3.6 TCP和QUIC的傳輸架構(gòu)

如圖所示，Client端和Server端都屬于應(yīng)用層，左邊是SPICE當(dāng)前的網(wǎng)絡(luò)傳輸方案，基于websocket通過(guò)底層TCP協(xié)議傳輸與接收數(shù)據(jù)。右邊則是改造后的QUIC傳輸方案，改造需要在Client端和Server端同時(shí)進(jìn)行，由于QUIC的功能與TCP一致，因此在將TCP切換為QUIC后，還需要在整體架構(gòu)上增加部分機(jī)制以實(shí)現(xiàn)websocket的功能。

（3）基于webrtc框架的傳輸優(yōu)化

webrtc是谷歌發(fā)布的一項(xiàng)實(shí)時(shí)通信的音視頻傳輸技術(shù)，它提供了包括音視頻的采集、編解碼、網(wǎng)絡(luò)傳輸、顯示等功能。相比QUIC，webrtc則是直接對(duì)標(biāo)websocket等傳輸框架，實(shí)現(xiàn)應(yīng)用間的傳輸連接。標(biāo)準(zhǔn)webrtc采用UDP協(xié)議作為底層傳輸協(xié)議，實(shí)現(xiàn)了應(yīng)用間點(diǎn)對(duì)點(diǎn)的連接，并且對(duì)傳輸機(jī)制進(jìn)行了優(yōu)化，相比基于TCP的websocket框架，基于UDP的webrtc有著更強(qiáng)的穩(wěn)定性和更低的延遲。

圖3.7 websocket和webrtc的傳輸架構(gòu)

相較來(lái)說(shuō)基于webrtc的優(yōu)化架構(gòu)與原本websocket架構(gòu)類似，在Client和Server端，二者都需要將原本的websocket框架轉(zhuǎn)換為webrtc。

3.4 虛擬顯示方案

在云終端傳輸協(xié)議的顯示技術(shù)方案中，通常有3種實(shí)現(xiàn)方式分別為：

虛擬顯卡、GPU虛擬化（vGPU）、顯卡直通。

考慮到產(chǎn)品成本及物理資源消耗，針對(duì)普通辦公需求的用戶，目前主流的云桌面（電腦）產(chǎn)品均采用的是虛擬顯卡技術(shù)方案。

（1）虛擬顯卡工作原理

在傳輸協(xié)議服務(wù)端（Server）的虛擬機(jī)管理軟件（vmware、hyper-v、qemu-kvm）中，通常內(nèi)置有一種或多種虛擬顯卡設(shè)備（QXL、Cirrur、SVGA等）提供給虛擬機(jī)，虛擬機(jī)內(nèi)的windows操作系統(tǒng)會(huì)將桌面顯示數(shù)據(jù)全部寫入到虛擬顯卡中。

虛擬顯卡接收虛擬機(jī)的所有桌面圖像后，把圖像數(shù)據(jù)通過(guò)某種手段（如共享內(nèi)存）共享給宿主機(jī)上的虛擬機(jī)管理軟件。管理軟件將這部分?jǐn)?shù)據(jù)在某個(gè)窗口中還原出來(lái)，從而在宿主機(jī)上看到虛擬機(jī)的桌面圖像；同時(shí)，把虛擬顯卡共享給宿主機(jī)的圖像數(shù)據(jù)截獲下來(lái)（管理軟件內(nèi)置有API截獲每個(gè)虛擬機(jī)的圖像數(shù)據(jù)），再經(jīng)過(guò)圖像壓縮算法（通常采用H.264）壓縮后，通過(guò)網(wǎng)絡(luò)傳輸協(xié)議（如SPICE、VNC）發(fā)送給客戶端。具體工作流程可參考下圖：

圖3.8 虛擬顯卡工作原理

（2）Windows顯示驅(qū)動(dòng)模型（WDDM）

提到顯卡（無(wú)論是物理顯卡，還是虛擬顯卡），自然少不了顯卡驅(qū)動(dòng)的參與。

Windows操作系統(tǒng)的顯示/圖形驅(qū)動(dòng)模型，從win7開(kāi)始均采用的Windows Display Driver Model(WDDM)模型，完整的WDDM顯示驅(qū)動(dòng)模型由兩部分組成：內(nèi)核模式（Kernel-Mode）的微端口驅(qū)動(dòng)（Display Miniport Driver）與用戶模式（User-Mode）的顯示驅(qū)動(dòng)（Display Driver）。其架構(gòu)如下：

圖3.9 WDDM架構(gòu)示意圖

在WDDM 1.2版本中引入了三種顯卡驅(qū)動(dòng)類型，分別為：

Full Graphics Driver

完整功能版本，支持2D和3D硬件加速，擁有完整的渲染（Render）、顯示（Display）和視頻（Video）功能。

DOD：Display Only Driver（內(nèi)核模式驅(qū)動(dòng)）

顧名思義，這一類的驅(qū)動(dòng)只有最基本的顯示功能，不支持運(yùn)算（渲染）。

ROD：Render Only Driver

該類型驅(qū)動(dòng)僅支持渲染功能，不支持顯示功能。

在云桌面應(yīng)用中，虛擬機(jī)內(nèi)部通常采用的是DOD驅(qū)動(dòng)程序來(lái)驅(qū)動(dòng)虛擬顯卡（QXL）進(jìn)行顯示，而把復(fù)雜、耗時(shí)的渲染工作交給宿主機(jī)側(cè)的CPU。

（3）間接顯示驅(qū)動(dòng)（IDD）

在Win10 1607版本之后，WDDM 2.1版本提供了間接顯示驅(qū)動(dòng)（IDD，Indirect Display Driver）的模型來(lái)實(shí)現(xiàn)虛擬顯示器的功能。

IDD工作原理

該驅(qū)動(dòng)在Windows電腦（虛擬機(jī)）上模擬出一個(gè)“虛擬顯示器”設(shè)備，利用軟件的手段將該虛擬顯示器接到（虛擬/物理）顯卡的輸出端口上（模擬HDMI/VGA）。對(duì)于虛擬機(jī)操作系統(tǒng)而言，該虛擬顯示器相當(dāng)于“真實(shí)的物理顯示器”，可以在系統(tǒng)顯示設(shè)置控制面板上看到該設(shè)備，也能像物理顯示器一樣被復(fù)制、擴(kuò)展。客觀上該虛擬顯示器是“不存在”的，因此看不到該顯示器的畫面。但是我們可以將虛擬顯卡輸出到虛擬顯示器的顯示數(shù)據(jù)截獲，再在某個(gè)窗口畫出來(lái)，或者通過(guò)傳輸協(xié)議發(fā)送給所需要的客戶端，即可在客戶端窗口內(nèi)實(shí)現(xiàn)虛擬機(jī)雙屏顯示；

IDD架構(gòu)

IDD驅(qū)動(dòng)是在IddCx(Indirect Display Driver Class eXtension，間接顯示驅(qū)動(dòng)類擴(kuò)展)的基礎(chǔ)上開(kāi)發(fā)的，屬于“純”用戶模式驅(qū)動(dòng)程序，不包含任何內(nèi)核模式的組件，能夠使用任何 DirectX API 來(lái)處理桌面鏡像數(shù)據(jù)。同時(shí)，IDD運(yùn)行在session 0中，在用戶session中沒(méi)有運(yùn)行任何組件，因此有助于提高整體系統(tǒng)可靠性。該驅(qū)動(dòng)框架如下圖：

圖3.10 IDD架構(gòu)示意圖

（4）虛擬顯示方案優(yōu)化

基于SPICE傳輸協(xié)議的虛擬機(jī)，若要提升虛擬機(jī)畫面顯示性能，支持多屏顯示、窗口自適應(yīng)、分辨率調(diào)節(jié)等功能，需要開(kāi)發(fā)相應(yīng)的顯示驅(qū)動(dòng)程序；具體可以參考以下方案：

一顯卡、多顯示器（DoD+IDD）

圖3.11 DoD+IDD顯示方案

該方案利用底層虛擬化軟件加載一個(gè)虛擬顯卡并采用DoD驅(qū)動(dòng)顯示，再通過(guò)一個(gè)IDD虛擬顯示器拓展屏幕，實(shí)現(xiàn)雙屏；

多顯卡、多顯示器（DoD+DoD）

圖3.12 DoD+DoD顯示方案

該方案實(shí)際上是給虛擬機(jī)添加2個(gè)虛擬顯卡并采用DoD驅(qū)動(dòng)，每個(gè)虛擬顯卡對(duì)應(yīng)一個(gè)宿主機(jī)中的虛擬顯示設(shè)備，進(jìn)而實(shí)現(xiàn)雙屏；

3.5USB重定向策略

（1）SPICE協(xié)議中的USB重定向存在的問(wèn)題

USB外設(shè)的使用是云終端產(chǎn)品中影響用戶體驗(yàn)的關(guān)鍵一環(huán)。現(xiàn)階段SPICE協(xié)議在USB重定向上還存在如下問(wèn)題：

①由于USB驅(qū)動(dòng)加載模式會(huì)頻繁的安裝卸載驅(qū)動(dòng)，造成了在文件（夾）

的傳輸過(guò)程中效率低下且不穩(wěn)定。首先，驅(qū)動(dòng)的安裝和卸載時(shí)間較長(zhǎng)，在一些老舊配置的機(jī)器上甚至要花費(fèi)幾分鐘來(lái)安裝驅(qū)動(dòng)，導(dǎo)致設(shè)備從開(kāi)始映射到真正能夠使用需要花費(fèi)較長(zhǎng)的時(shí)間等待。其次，驅(qū)動(dòng)的安裝卸載會(huì)引起設(shè)備的反復(fù)刷新，容易影響已經(jīng)映射成功的其他設(shè)備，導(dǎo)致其他設(shè)備工作異常等。最后，頻繁的安裝卸載驅(qū)動(dòng)容易造成系統(tǒng)的設(shè)備庫(kù)混亂，在不進(jìn)行重定向時(shí)，系統(tǒng)也沒(méi)辦法加載正確的設(shè)備驅(qū)動(dòng)導(dǎo)致設(shè)備不可用。

②其它USB設(shè)備如攝像頭重定向等有待進(jìn)一步功能開(kāi)發(fā)及測(cè)試。對(duì)于大容

量數(shù)據(jù)的傳輸和USB攝像頭等有大量實(shí)時(shí)輸出傳輸?shù)膱?chǎng)景，其效率是比較低的，同時(shí)一定會(huì)占用大量的帶寬，這些也都是要考慮的因素。

（2）改造方案

整個(gè)重定向的過(guò)程中涉及到了SPICE客戶端，SPICE服務(wù)端和Guest端，詳細(xì)的處理流程如下圖3.12所示。

在需要USB設(shè)備映射時(shí)，USB設(shè)備的控制和讀寫請(qǐng)求通過(guò)Guest端發(fā)出，通過(guò)虛擬化軟件QEMU提供的VDI接口將命令傳送給SPICE服務(wù)端。SPICE服務(wù)端在收到消息后基于libusbredir定義的USB重定向協(xié)議讀數(shù)據(jù)進(jìn)行處理，然后通過(guò)SPICE協(xié)議定義的USBRedir通道，將數(shù)據(jù)發(fā)送到客戶端?？蛻舳送ㄟ^(guò)USB通用驅(qū)動(dòng)對(duì)收到的數(shù)據(jù)進(jìn)行解析，然后對(duì)物理USB設(shè)備進(jìn)行操作。物理USB設(shè)備做出應(yīng)答后再通過(guò)原路徑返回?cái)?shù)據(jù)。

在不需要進(jìn)行USB設(shè)備映射時(shí)，SPICE將對(duì)應(yīng)標(biāo)識(shí)的通用設(shè)備驅(qū)動(dòng)進(jìn)行卸載，操作系統(tǒng)通過(guò)USB設(shè)備屬性進(jìn)行驅(qū)動(dòng)匹配設(shè)備然后將設(shè)備彈出，再讓設(shè)備重新被識(shí)別，在此查詢自己的驅(qū)動(dòng)庫(kù)，在驅(qū)動(dòng)庫(kù)中查找合適的驅(qū)動(dòng)，由于系統(tǒng)有備份機(jī)制，即使原來(lái)的USB設(shè)備有廠商自定義的功能設(shè)備驅(qū)動(dòng)，在被通用設(shè)備驅(qū)動(dòng)覆蓋安裝后仍然能夠找到設(shè)備驅(qū)動(dòng)，SPICE將對(duì)應(yīng)標(biāo)識(shí)的通用設(shè)備驅(qū)動(dòng)卸載后，USB設(shè)備重新識(shí)別時(shí)，仍能重新正確加載設(shè)備驅(qū)動(dòng)。

圖3.13 USB設(shè)備重定向架構(gòu)圖

整個(gè)SPICE云終端傳輸協(xié)議項(xiàng)目中USB設(shè)備重定向采用USBRedir技術(shù)，基于該技術(shù)，針對(duì)SPICE協(xié)議中USB重定向存在的問(wèn)題，改造方案如下：

驅(qū)動(dòng)替換

通過(guò)驅(qū)動(dòng)替換技術(shù)代替目前采用的驅(qū)動(dòng)安裝方式加載驅(qū)動(dòng)。驅(qū)動(dòng)安裝時(shí)更新操作系統(tǒng)的驅(qū)動(dòng)庫(kù)來(lái)進(jìn)行設(shè)備驅(qū)動(dòng)的加載，而驅(qū)動(dòng)替換技術(shù)則是修改USB設(shè)備屬性來(lái)達(dá)到匹配通用驅(qū)動(dòng)的目的。操作系統(tǒng)是通過(guò)USB設(shè)備屬性進(jìn)行驅(qū)動(dòng)匹配，預(yù)先將通用設(shè)備驅(qū)動(dòng)安裝到一組自定義的設(shè)備屬性上面，在進(jìn)行映射時(shí)修改USB屬性信息為之前預(yù)定義的的設(shè)備屬性，這樣操作系統(tǒng)根據(jù)設(shè)備屬性匹配驅(qū)動(dòng)時(shí)，就會(huì)加載通用設(shè)備驅(qū)動(dòng)，在不進(jìn)行重定向時(shí)不做任何設(shè)備信息的修改直接上報(bào)設(shè)備的真實(shí)信息，以此操作系統(tǒng)就會(huì)加載設(shè)備對(duì)應(yīng)的功能驅(qū)動(dòng)。最終通過(guò)修改設(shè)備屬性實(shí)現(xiàn)驅(qū)動(dòng)替換就可以避免驅(qū)動(dòng)的頻繁安裝卸載。

usbredir+壓縮編解碼

通過(guò)USB數(shù)據(jù)的壓縮方法來(lái)改善USB重定向的效果，降低帶寬，提升數(shù)據(jù)傳輸效率。在USB重定向過(guò)程中，存在大量數(shù)據(jù)傳輸?shù)膱?chǎng)景通常為文件拷貝和USB攝像頭傳輸?shù)?。在文件拷貝的?yīng)用場(chǎng)景中，由于文件內(nèi)容不能被修改，為此需要進(jìn)行無(wú)損壓縮。而在USB攝像頭重定向之類的應(yīng)用場(chǎng)景中，傳輸U(kuò)SB采集的數(shù)據(jù)量通常比較大，一般沒(méi)有進(jìn)行數(shù)據(jù)的壓縮處理，而且此類數(shù)據(jù)可以允許信息量的損失，為此可以通過(guò)成熟的視頻編解碼壓縮算法如MJPEG、H.264等進(jìn)行壓縮處理后再發(fā)送到服務(wù)端，由服務(wù)端做解碼處理后再還原數(shù)據(jù)。

3.6SDK裁剪優(yōu)化

（1）API重構(gòu)

SPICE采用GTK+實(shí)現(xiàn)的客戶端的代碼。GTK+底層采用GObject（C語(yǔ)言）來(lái)模擬面向?qū)ο?，代碼實(shí)現(xiàn)較為繁瑣，隨著代碼量的增加，其代碼的維護(hù)難度也比較高，且最為重要的是如果不熟悉GTK+運(yùn)行機(jī)制，開(kāi)發(fā)者幾乎很難使用這套API接口，因而新版的Server端的代碼已經(jīng)不在使用GObject來(lái)模擬面向?qū)ο螅D(zhuǎn)而使用C++來(lái)開(kāi)發(fā)代碼?；谶@一原因，我們也需要對(duì)客戶端的框架進(jìn)行優(yōu)化，選取基于C++的跨平臺(tái)框架Qt進(jìn)行代碼的重構(gòu)，重新設(shè)計(jì)API，降低用戶調(diào)用API的難度。

（2）smartcard裁剪

智能卡—內(nèi)嵌有微芯片的塑料卡（通常是一張信用卡的大?。┑耐ǚQ ，一般芯片都有CPU、RAM和I/O，需要特定的讀卡器進(jìn)行交互，但是無(wú)法使用一種讀卡器兼容所有類型的智能卡。此外，雖然智能卡對(duì)于許多應(yīng)用程序來(lái)說(shuō)可能更安全，但它們?nèi)匀蝗菀资艿侥承╊愋偷墓?。如可以通過(guò)智能卡技術(shù)從芯片恢復(fù)信息的攻擊。差分功率分析可用于推斷公鑰算法（如RSA）使用的片上私鑰。再者，移動(dòng)云云電腦主要面向個(gè)人用戶，面向私有云部署的智能卡使用情景幾乎很難用到，因此可以移除此功能。

（3）協(xié)程裁剪

spice-gtk采用原生的協(xié)程來(lái)實(shí)現(xiàn)I/O的讀寫，雖然原生的協(xié)程與相比線程能夠減少創(chuàng)建的開(kāi)銷和避免無(wú)意義的調(diào)度，但是并不十分適合移動(dòng)端平臺(tái)。協(xié)程適合于高并發(fā)吞吐的場(chǎng)景，犧牲了線程的公平性，如果存在一個(gè)較長(zhǎng)時(shí)間的計(jì)算任務(wù)（如圖像解碼），將影響到IO任務(wù)的響應(yīng)延時(shí)，即會(huì)影響其它同步進(jìn)行的數(shù)據(jù)處理（如音頻播放）。而且單線程的協(xié)程方案并不能從根本上避免阻塞，如文件操作、內(nèi)存缺頁(yè)，所以對(duì)于云桌面終端這種并不需要應(yīng)對(duì)高并發(fā)的場(chǎng)景，使用多線程更能兼顧各個(gè)channel數(shù)據(jù)處理的公平性，從而在顯示復(fù)雜動(dòng)畫網(wǎng)頁(yè)時(shí)不會(huì)影響音頻播放和外設(shè)重定向。

4

總結(jié)及演進(jìn)方向

由于SPICE協(xié)議的出現(xiàn)是為了解決遠(yuǎn)程桌面的問(wèn)題，其在目前的移動(dòng)互聯(lián)網(wǎng)時(shí)代甚至未來(lái)的全真互聯(lián)網(wǎng)時(shí)代有著明顯的不足。想要適應(yīng)飛速發(fā)展的互聯(lián)網(wǎng)，云終端傳輸協(xié)議還要朝著不同的技術(shù)路線繼續(xù)演進(jìn)。

適配容器技術(shù)

以Docker為代表的容器技術(shù)發(fā)展迅速，不同于資源消耗過(guò)多的虛擬機(jī)，Docker以輕量、資源消耗少的優(yōu)勢(shì)在云游戲、云手機(jī)等云應(yīng)用普遍采用。云終端傳輸協(xié)議應(yīng)適配容器技術(shù)以支持輕量的云應(yīng)用場(chǎng)景。

超高清視頻支持

超高清是顯示產(chǎn)業(yè)繼數(shù)字化、高清化后的新一輪重大技術(shù)變革，隨著用戶顯示屏分辨率的不斷提高，云終端傳輸協(xié)議對(duì)超高清視頻的支持已提上日程。

全景視頻支持

元宇宙已成為當(dāng)下最火熱的話題，虛擬現(xiàn)實(shí)（VR）作為元宇宙最有望落地的入口，被稱為“下一代通用計(jì)算平臺(tái)”，它使用計(jì)算機(jī)創(chuàng)建出逼真的三維立體虛擬場(chǎng)景，用戶可以與虛擬環(huán)境進(jìn)行交互，從而得到強(qiáng)烈的沉浸感。云終端傳輸協(xié)議若想在元宇宙中有一席之地，要朝著可穿戴終端方向演進(jìn)。

綜上，目前的云終端傳輸協(xié)議像是站在下一代互聯(lián)網(wǎng)革命入口的上古猿人，仍處于非常原始的狀態(tài)，想要支撐未來(lái)宇宙，目前來(lái)看要走的路還有很長(zhǎng)。

審核編輯：劉清