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

1

背景

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

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

2

SPICE協(xié)議原理詳解

2.1 整體架構

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

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

服務端側（spice server）：以libspice動態(tài)庫形式供虛擬機監(jiān)控管理程序(qemu)使用；

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

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

各部分之間的關系如圖所示：

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

SPICE協(xié)議整體架構，如下圖所示。客戶端運行在用戶終端設備上，為用戶提供桌面環(huán)境。SPICE服務端以動態(tài)鏈接庫的形式與KVM虛擬機整合，通過SPICE協(xié)議與客戶端進行通信。

圖2.2 SPICE協(xié)議架構

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

2.2 Server端原理詳解

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

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

圖2.3 服務端架構圖

服務端與虛擬機之間的通信需要借助QEMU虛擬化出QXL接口和I/O接口。I/O接口包含代理接口、輸入接口和音頻接口（回放接口和記錄接口），分別完成與主通道、輸入通道、回放通道和記錄接口的建立。QXL接口通過虛擬機中的QXL驅動完成圖形設備接口的封裝調用，方便對顯示通道和光標通道進行操作。與I/O接口不同的是，QXL接口可以有多個，以便支持多屏顯示等功能。

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

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

綜合上述，SPICE服務端核心的三個組件分別為：

(1) Red Server (reds.c)

Red Server主要用來監(jiān)聽客戶端連接請求，接受連接并與客戶端通信，主要負責：

通道

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

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

主通道和輸入通道的管理

socket操作以及鏈接管理

處理SSL和ticketing

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

處理用戶命令

和Guest Agent通信

(2) Red Worker(red_worker.c)

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

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

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

顯示通道和光標通道管理

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

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

(3) Red Dispatcher(red_dispatcher.c)

Red Dispatcher主要用于QXL的調度工作，主要負責：

為每個QXL實例一個調度器

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

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

2.3 Guest端原理詳解

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

圖2.5 guest框架圖

（1）Vdagent

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

Client端鼠標模式

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

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

分辨率自適應

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

共享剪切板

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

文件傳輸功能

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

（2）QXL

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

為此，guest端針對不同系統(tǒng)開發(fā)了功能相同的QXL驅動，一方面增強了QXL顯卡處理畫面的效果，另一方面也提供了調用QXL顯卡實現(xiàn)調整分辨率的接口供vdagent實現(xiàn)分辨率自適應功能。

2.4 Client端原理詳解

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

為了擁有一個純凈的跨平臺結構，SPICE定義了一套通用的接口（Platform類），將其特定于平臺的實現(xiàn)保留在并行目錄中。這套接口定義了許多低級服務，例如定時器和光標操作。

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

（1）Channels

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

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

圖2.6 客戶端基礎架構圖

- 所有channel的祖先是：

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

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

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

- 可用的channel有：

Main - 由RedClient實現(xiàn)

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

InputsChannel - 鍵盤和鼠標輸入

CursorChannel - 指針設備位置，可見性和光標形狀

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

RecordChannel - 在Client捕獲的音頻

（2）Screens and Windows

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

RedScreen - 使用screen layers（例如，顯示，光標）來實現(xiàn)screen邏輯并控制窗口來顯示其內容。

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

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

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

3

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

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

3.1 帶內協(xié)議改造

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

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

圖3.1 帶外協(xié)議結構圖

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

圖3.2 帶內協(xié)議架構圖

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

圖3.3 帶內改造方案

3.2 H.26x編解碼集成

（1）H.264編解碼集成

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

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

Gstreamer的核心就是管道，將數(shù)據(jù)流輸入管道，經過管道的處理后輸出數(shù)據(jù)流。在sever端的H.264編碼中，管道使用x264enc對數(shù)據(jù)流進行編碼后，最輸出H.264數(shù)據(jù)流并發(fā)送至客戶端。客戶端進行解碼處理后，將圖形界面顯示到客戶端上。在SPICE中，對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編碼管道主要由四個元素構成，分別是appsrc，videoconvert，x264enc和appsink。其中appsrc主要是獲取應用程序的數(shù)據(jù)，將其插入到Gstreamer的管道中。videoconvert的主要功能是轉換多種視頻格式，具體而言是在SPICE中將appsrc獲取的數(shù)據(jù)流格式轉換為下一個元素，如x264enc，能夠接收的視頻格式。appsink是一個sink的應用程序插件，能夠使得應用程序獲取管道中的數(shù)據(jù)流。以上三個元素為Gstreamer常用的元素。

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

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

圖3.5 H.264解碼器管道

（2）H.265編解碼集成

H.265是ITU-T VCEG繼H.264之后所制定的新的視頻編碼標準。在server端，H.265的集成同樣是基于Gstreamer的，采用的是x265enc編碼器，最終具體實現(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ù)流同樣是從應用程序中獲取，因此仍然采用appsrc獲取數(shù)據(jù)，通過videoconvert將視頻轉換成x265enc能夠處理的數(shù)據(jù)格式。與H.264不同的是，此處顯式的給出了videoconvert的輸出數(shù)據(jù)格式，為I420格式，原因在于，采用的x265enc版本對于I420格式適應較好。相較于x264enc，x265enc的參數(shù)量較少，在SPICE中目前僅設置tune與speed-preset=ultrafast來控制碼率與圖像質量。需要指出的是，在開發(fā)過程中，H.265相較于H.264，采用的x265enc不成熟，在H.265理論上可行的方案并沒有完全支持，因此需要顯式地指出數(shù)據(jù)的各種格式，如果數(shù)據(jù)流沒有指定視頻格式，可能會導致數(shù)據(jù)流錯誤，無法進行正確地編碼。H.265解碼工作與H.264工作類似，僅需要將h264parse與avdec_h264替換為h265parse與avdec_h265，該工作可以由decodebin進行自行處理完成替換。

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

（1）SPICE在廣域網的局限性

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

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

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

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

圖3.6 TCP和QUIC的傳輸架構

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

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

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

圖3.7 websocket和webrtc的傳輸架構

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

3.4 虛擬顯示方案

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

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

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

（1）虛擬顯卡工作原理

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

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

圖3.8 虛擬顯卡工作原理

（2）Windows顯示驅動模型（WDDM）

提到顯卡（無論是物理顯卡，還是虛擬顯卡），自然少不了顯卡驅動的參與。

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

圖3.9 WDDM架構示意圖

在WDDM 1.2版本中引入了三種顯卡驅動類型，分別為：

Full Graphics Driver

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

DOD：Display Only Driver（內核模式驅動）

顧名思義，這一類的驅動只有最基本的顯示功能，不支持運算（渲染）。

ROD：Render Only Driver

該類型驅動僅支持渲染功能，不支持顯示功能。

在云桌面應用中，虛擬機內部通常采用的是DOD驅動程序來驅動虛擬顯卡（QXL）進行顯示，而把復雜、耗時的渲染工作交給宿主機側的CPU。

（3）間接顯示驅動（IDD）

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

IDD工作原理

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

IDD架構

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

圖3.10 IDD架構示意圖

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

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

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

圖3.11 DoD+IDD顯示方案

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

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

圖3.12 DoD+DoD顯示方案

該方案實際上是給虛擬機添加2個虛擬顯卡并采用DoD驅動，每個虛擬顯卡對應一個宿主機中的虛擬顯示設備，進而實現(xiàn)雙屏；

3.5USB重定向策略

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

USB外設的使用是云終端產品中影響用戶體驗的關鍵一環(huán)?，F(xiàn)階段SPICE協(xié)議在USB重定向上還存在如下問題：

①由于USB驅動加載模式會頻繁的安裝卸載驅動，造成了在文件（夾）

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

②其它USB設備如攝像頭重定向等有待進一步功能開發(fā)及測試。對于大容

量數(shù)據(jù)的傳輸和USB攝像頭等有大量實時輸出傳輸?shù)膱鼍埃湫适潜容^低的，同時一定會占用大量的帶寬，這些也都是要考慮的因素。

（2）改造方案

整個重定向的過程中涉及到了SPICE客戶端，SPICE服務端和Guest端，詳細的處理流程如下圖3.12所示。

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

在不需要進行USB設備映射時，SPICE將對應標識的通用設備驅動進行卸載，操作系統(tǒng)通過USB設備屬性進行驅動匹配設備然后將設備彈出，再讓設備重新被識別，在此查詢自己的驅動庫，在驅動庫中查找合適的驅動，由于系統(tǒng)有備份機制，即使原來的USB設備有廠商自定義的功能設備驅動，在被通用設備驅動覆蓋安裝后仍然能夠找到設備驅動，SPICE將對應標識的通用設備驅動卸載后，USB設備重新識別時，仍能重新正確加載設備驅動。

圖3.13 USB設備重定向架構圖

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

驅動替換

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

usbredir+壓縮編解碼

通過USB數(shù)據(jù)的壓縮方法來改善USB重定向的效果，降低帶寬，提升數(shù)據(jù)傳輸效率。在USB重定向過程中，存在大量數(shù)據(jù)傳輸?shù)膱鼍巴ǔ槲募截惡蚒SB攝像頭傳輸?shù)取Ｔ谖募截惖膽脠鼍爸?，由于文件內容不能被修改，為此需要進行無損壓縮。而在USB攝像頭重定向之類的應用場景中，傳輸USB采集的數(shù)據(jù)量通常比較大，一般沒有進行數(shù)據(jù)的壓縮處理，而且此類數(shù)據(jù)可以允許信息量的損失，為此可以通過成熟的視頻編解碼壓縮算法如MJPEG、H.264等進行壓縮處理后再發(fā)送到服務端，由服務端做解碼處理后再還原數(shù)據(jù)。

3.6SDK裁剪優(yōu)化

（1）API重構

SPICE采用GTK+實現(xiàn)的客戶端的代碼。GTK+底層采用GObject（C語言）來模擬面向對象，代碼實現(xiàn)較為繁瑣，隨著代碼量的增加，其代碼的維護難度也比較高，且最為重要的是如果不熟悉GTK+運行機制，開發(fā)者幾乎很難使用這套API接口，因而新版的Server端的代碼已經不在使用GObject來模擬面向對象，轉而使用C++來開發(fā)代碼?；谶@一原因，我們也需要對客戶端的框架進行優(yōu)化，選取基于C++的跨平臺框架Qt進行代碼的重構，重新設計API，降低用戶調用API的難度。

（2）smartcard裁剪

智能卡—內嵌有微芯片的塑料卡（通常是一張信用卡的大小）的通稱 ，一般芯片都有CPU、RAM和I/O，需要特定的讀卡器進行交互，但是無法使用一種讀卡器兼容所有類型的智能卡。此外，雖然智能卡對于許多應用程序來說可能更安全，但它們仍然容易受到某些類型的攻擊。如可以通過智能卡技術從芯片恢復信息的攻擊。差分功率分析可用于推斷公鑰算法（如RSA）使用的片上私鑰。再者，移動云云電腦主要面向個人用戶，面向私有云部署的智能卡使用情景幾乎很難用到，因此可以移除此功能。

（3）協(xié)程裁剪

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

4

總結及演進方向

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

適配容器技術

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

超高清視頻支持

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

全景視頻支持

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

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

審核編輯：劉清