1

背景

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

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

2

SPICE協議原理詳解

2.1 整體架構

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

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

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

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

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

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

圖2.1 SPICE協議相關組件之間的關系

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

圖2.2 SPICE協議架構

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

2.2 Server端原理詳解

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

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

圖2.3 服務端架構圖

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

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

圖2.4 圖形系統架構圖

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

(1) Red Server (reds.c)

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

通道

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

通知Client活動的通道，便于Client創建它們

主通道和輸入通道的管理

socket操作以及鏈接管理

處理SSL和ticketing

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

處理用戶命令

和Guest Agent通信

(2) Red Worker(red_worker.c)

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

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

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

顯示通道和光標通道管理

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

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

(3) Red Dispatcher(red_dispatcher.c)

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

為每個QXL實例一個調度器

創建和初始化Red Worker線程

執行QXL的調度工作

2.3 Guest端原理詳解

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

圖2.5 guest框架圖

（1）Vdagent

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

Client端鼠標模式

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

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

分辨率自適應

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

共享剪切板

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

文件傳輸功能

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

（2）QXL

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

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

2.4 Client端原理詳解

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

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

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

（1）Channels

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

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

圖2.6 客戶端基礎架構圖

- 所有channel的祖先是：

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

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

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

- 可用的channel有：

Main - 由RedClient實現

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

InputsChannel - 鍵盤和鼠標輸入

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

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

RecordChannel - 在Client捕獲的音頻

（2）Screens and Windows

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

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

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

RedWindow_p - 特定于平臺的窗口數據和方法。

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

3

SPICE協議產品化改造方案

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

3.1 帶內協議改造

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

帶內協議與帶外協議最大的區別在于SPICE服務端的位置不同。帶外協議的架構圖如圖3.1所示，SPICE服務端位于QEMU層，分別通過QXL設備和VDI端口與虛擬機的QXL驅動和VDI代理進行交互。客戶端需要通過宿主機的IP地址加上端口號連接上SPICE服務端，不同的虛擬機需要不同的端口進行連接。

圖3.1 帶外協議結構圖

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

圖3.2 帶內協議架構圖

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

圖3.3 帶內改造方案

3.2 H.26x編解碼集成

（1）H.264編解碼集成

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

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

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

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

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

圖3.5 H.264解碼器管道

（2）H.265編解碼集成

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

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

3.3 廣域網環境傳輸優化

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

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

在局域網環境下TCP協議尚能滿足視音頻傳輸的需求，而在較為復雜的廣域網環境中，TCP協議較大的數據頭部和阻塞、丟包重發等機制都會增加數據在長鏈路網絡下的延遲和額外帶寬消耗。SPICE是實時桌面傳輸協議，遠程數據不僅包含實時音視數據，還包括其他實時指令數據，對網絡傳輸的延遲和吞吐有著較高的要求。為實現SPICE移植到廣域網下的需求，勢必需要對傳輸進行優化。

（2）基于QUIC協議的傳輸優化

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

圖3.6 TCP和QUIC的傳輸架構

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

（3）基于webrtc框架的傳輸優化

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

圖3.7 websocket和webrtc的傳輸架構

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

3.4 虛擬顯示方案

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

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

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

（1）虛擬顯卡工作原理

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

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

圖3.8 虛擬顯卡工作原理

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

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

Windows操作系統的顯示/圖形驅動模型，從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）的模型來實現虛擬顯示器的功能。

IDD工作原理

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

IDD架構

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

圖3.10 IDD架構示意圖

（4）虛擬顯示方案優化

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

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

圖3.11 DoD+IDD顯示方案

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

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

圖3.12 DoD+DoD顯示方案

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

3.5USB重定向策略

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

USB外設的使用是云終端產品中影響用戶體驗的關鍵一環。現階段SPICE協議在USB重定向上還存在如下問題：

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

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

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

量數據的傳輸和USB攝像頭等有大量實時輸出傳輸的場景，其效率是比較低的，同時一定會占用大量的帶寬，這些也都是要考慮的因素。

（2）改造方案

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

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

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

圖3.13 USB設備重定向架構圖

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

驅動替換

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

usbredir+壓縮編解碼

通過USB數據的壓縮方法來改善USB重定向的效果，降低帶寬，提升數據傳輸效率。在USB重定向過程中，存在大量數據傳輸的場景通常為文件拷貝和USB攝像頭傳輸等。在文件拷貝的應用場景中，由于文件內容不能被修改，為此需要進行無損壓縮。而在USB攝像頭重定向之類的應用場景中，傳輸USB采集的數據量通常比較大，一般沒有進行數據的壓縮處理，而且此類數據可以允許信息量的損失，為此可以通過成熟的視頻編解碼壓縮算法如MJPEG、H.264等進行壓縮處理后再發送到服務端，由服務端做解碼處理后再還原數據。

3.6SDK裁剪優化

（1）API重構

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

（2）smartcard裁剪

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

（3）協程裁剪

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

4

總結及演進方向

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

適配容器技術

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

超高清視頻支持

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

全景視頻支持

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

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

審核編輯：劉清