Gaming@Edge：基于邊緣節點的低延遲云游戲系統

林立 熊金波 肖如良 林銘煒 陳秀華

摘 要：云游戲作為云計算的“殺手級”應用正在引領游戲運行方式的變革。然而，云端與終端設備之間較大的網絡延遲影響了云游戲的用戶體驗，因此，提出一種基于邊緣計算理念，部署在邊緣節點之上的低延遲的云游戲框架——Gaming@Edge。為了降低邊緣節點的計算負載以提升其并發能力，Gaming@Edge實現了一種基于壓縮圖形流的云游戲運行機制——GSGOD。GSGOD分離了游戲運行中的邏輯計算和畫面渲染，實現了一種邊+端的計算融合。此外，GSGOD還通過數據緩存、指令流水處理以及對象狀態延遲更新等機制優化了云游戲的網絡數據傳輸和系統延遲。實驗結果表明，Gaming@Edge相比傳統的云游戲系統能夠降低平均74%的網絡延遲，并提高4.3倍游戲實例并發能力。

關鍵詞：云游戲;云計算;邊緣計算;視頻流;圖形流

Abstract： As a “killer” application in cloud computing， cloud gaming is leading the revolution of way of gaming. However， the high latency between the cloud and end devices hurts user experience. Aiming at the problem， a low latency cloud gaming system deployed on edge nodes， called Gaming@Edge， was proposed based on edge computing concept. To reduce the overhead of edge nodes for improving the concurrency， a cloud gaming running mechanism based on compressed graphics streaming， named GSGOD （Graphics Stream based Game-on-Demand）， was implemented in Gaming@Edge system. The logic computing and rendering in the game running were separated and a computing fusion of edge nodes and end devices was built by GSGOD. Moreover， the network data transmission and latency were optimized through the mechanisms such as data caching， instruction pipeline processing and lazy object updating in GSGOD. The experimental results show that Gaming@Edge can reduce average network latency by 74% and increase concurrency of game instances by 4.3 times compared to traditional cloud gaming system.

Key words： cloud gaming; cloud computing; edge computing; video streaming; graphics streaming

0 引言

隨著技術、架構以及商業模式的快速發展和完善，云計算作為一種成熟的計算范型已經得到廣泛應用。云計算憑借強大的計算和存儲能力提供了分層服務體系，并最終以一切即服務（X as a Service， XaaS）的方式面向終端用戶提供便捷、多平臺、任意時間和地點訪問的服務。云游戲正是近年來出現的被認為是“殺手級”的云計算應用[1]。在云游戲中，當用戶請求運行一個游戲時，數據中心啟動該游戲實例，執行游戲邏輯，響應用戶輸入，同時將游戲渲染畫面實時壓縮以視頻流方式傳輸至用戶端。用戶接收視頻流后可以在任何平臺播放游戲畫面，如PC、智能手機、平板電腦、互聯網電視等。云游戲的出現改變了以客戶端為中心的傳統游戲運行模式，它實現了按需游戲的理念（Game on Demand），避免了用戶對游戲軟硬件的頻繁更新，使得用戶可以輕松地跨平臺同步游戲狀態和運行記錄[2]。這種新型的云應用目前已吸引了大量游戲玩家并出現了許多成功的商業案例，如PlayStationNow、LiquidSky、Paperspace等。

上述的云游戲運行方式，以游戲畫面的視頻流為基礎進行傳輸，本文稱之為“視頻流”云游戲。云游戲帶來游戲運行方式的革新，但這種基于視頻流構建的云游戲存在用戶體驗的嚴重不足，即游戲延遲高和帶寬需求大。由于云數據中心遠離用戶終端設備，兩者之間的網絡往返時間（Round Trip Time， RTT）較大，導致游戲延遲高;同時，由于高清視頻編碼需要較高的碼率，因此云游戲對于用戶帶寬需求較大，如當前主流的云游戲要求用戶至少擁有3MB/s的帶寬[3]。此外，當大規模用戶請求服務時，數據中心整體的帶寬消耗巨大和游戲實例并發能力不足的問題突出。云數據中心基于虛擬化技術為云游戲提供服務[4]，而游戲是一種計算和渲染任務都極其繁重的應用，它不但要求CPU的邏輯計算能力，同時依賴GPU的渲染能力。當前的虛擬化技術對于GPU支持不足[5-6]，導致云游戲數據中心部署成本高昂，游戲并發能力較弱。據報道，曾經著名的云游戲公司OnLive就因高昂的系統維護成本導致破產倒閉。

近年來，一種新的計算范型——邊緣計算[7-8]的出現，成為解決云游戲高延遲問題極具前景的方式。邊緣計算將計算從網絡中心（如數據中心）推向網絡的邊緣（如眾多的終端設備）。邊緣計算利用邊緣節點（如Cloudlet[9]）的網絡鄰近性解決了云游戲中的延遲問題，同時這種分布式處理克服了云數據中心集中計算的高帶寬消耗?；谶@種分析，本文設計和實現了Gaming@Edge，一種基于邊緣節點的云游戲運行框架。在Gaming@Edge中，云負責用戶注冊、服務注冊、服務發現以及協調各節點的資源調度;邊緣節點則作為分布式的計算節點。由于邊緣節點計算能力相對有限，框架首先要解決傳統視頻流云游戲中服務器端負載高、游戲實例并發性低的問題，因此，本文在Gaming@Edge中實現了一種基于圖形指令流的云游戲機制——GSGOD（Graphics Stream based Game-on-Demand）。GSGOD云游戲運行機制繼承了云游戲的便利性，游戲運行和維護仍然在服務器端。不同的是在GSGOD中服務器攔截游戲的圖形渲染指令，以圖形流的方式傳輸至客戶端?？蛻舳藙t完成圖形指令的執行，即游戲畫面的渲染。GSGOD分離了游戲邏輯計算和畫面渲染任務，既利用邊緣節點較強的計算能力，又發揮了客戶端的渲染能力，以高效和合理的方式進行端和邊緣節點之間的任務分配。這種方式大幅度降低了系統延遲，提升了用戶體驗，同時成倍地提高了服務器游戲并發性能。此外，為了減少圖形流的數據傳輸量，GSGOD基于圖形渲染指令的統計分析，實現了圖形流的壓縮;同時優化了圖形指令的流水執行和對象狀態同步機制，進一步降低了系統延遲。

本文的主要貢獻有三點：1）實現了基于邊緣節點構建的云游戲框架Gaming@Edge;2）實現了基于壓縮圖形流的云游戲機制GSGOD;3）系統性對比了圖形流和視頻流這兩種云游戲運行機制的性能。本文所提出的Gaming@Edge驗證了基于邊緣計算構建云游戲系統的可行性，為后續相關工作提供了經驗。

1 相關工作

1.1 云游戲系統的技術和架構

當前云游戲系統的實現方式可以分為兩類：視頻流（Video Streaming）方式和圖形流（Graphics Streaming）方式[10]。GamingAnywhere（GA）[11]是首個開源視頻流云游戲系統，它完整實現了視頻流云游戲的各部分組件：客戶端的用戶輸入處理，事件捕捉以及媒體播放;服務器端的音頻視頻捕捉，基于H.264/MPEG-4 AVC的視頻壓縮以及實時流傳輸協議。GamingAnywhere具備良好的可擴展、可移植和可配置等特性，引起學術界和工業界的廣泛關注。本文采用GamingAnywhere作為視頻流云游戲系統解決方案，與GSGOD系統進行比較分析。Shi等[12]在視頻流方式基礎上提出一種基于3D圖像變形輔助的實時視頻編碼方法，該方法使用圖形渲染語義提升云游戲的視頻編碼性能，從而減少了視頻數據的傳輸量和系統延遲。此外，Lee等[13]以及Lin等[14]分別在降低云游戲系統的延遲和提高云游戲服務質量上進行了相關研究。

Games@Large項目[15-17]設計了一個通用的云游戲框架，在該框架中用戶可以從任何接入設備訪問游戲中心并運行游戲。Games@Large提出了在服務器端攔截和捕獲3D圖形指令，并以圖形流方式傳送至客戶端進行渲染的方法。該方法與GSGOD的原理類似，然而Games@Large基于傳統的端云架構，且未對網絡傳輸和延遲進行優化，導致其性能不佳。針對上述缺陷，GSGOD實現了高效緩存和對象同步機制，從而減小了圖形指令和幾何數據的傳輸量，并降低了系統延遲。

1.2 邊緣計算

邊緣計算使得計算發生在網絡的邊緣，鄰近數據產生的地方（即大量的終端設備）。邊緣計算的出現源于物聯網（Internet of Things， IoT）[18]和5G網絡的發展[19]，并用于解決實時應用的低延遲需求。邊緣計算所提供的低延遲計算依賴于大量部署的邊緣節點，邊緣節點的形式有多種，包括微云（cloudlet）、網絡設備、基站、網絡互連車輛[20]等。本文所指的邊緣節點即微云，一種可靈活部署的鄰近終端設備的“盒中的數據中心”[9]。

邊緣計算現在被廣泛應用于實時處理應用中。Chen等[21]設計和實現了Glimpse，一個持續的、實時的移動對象識別系統。Glimpse利用計算遷移機制[22]，分離對象識別中對象捕捉和識別算法的執行。移動端負責捕捉動態的視頻流以及獲取對象的位置，而服務器則執行復雜的對象實時識別算法。Satyanarayanan團隊在實時視頻分析應用方面進行了相關研究，開發了GigaSight[23]，一個多層架構的實時視頻流分析系統。GigaSight系統包含移動設備、邊緣節點和云三層架構，采用一種去中心化的計算模式。在這種模式中，移動端捕獲的實時視頻流數據存儲在鄰近的邊緣節點上，并在邊緣節點端進行分析，只有分析的結果和元數據發送到云數據中心，以便后續的大數據分析。云游戲也是一種典型的實時應用，對于網絡延遲要求高，而上述應用的構建，為基于邊緣計算解決云游戲的高延遲問題提供了參考價值。本文將對這一方案進行討論和驗證。

2 系統架構

Gaming@Edge的系統框架如圖1所示。在Gaming@Edge中，云端負責游戲服務的注冊和發現;當發現可用的邊緣節點后，將用戶請求重定向到節點，并由節點提供云游戲的計算服務。本文在邊緣節點上實現了一套基于壓縮圖形流的云游戲系統——GSGOD。GSGOD不同于傳統的視頻流云游戲，它實現了一種終端設備遷移游戲邏輯計算至邊緣節點，并和邊緣節點協同計算完成游戲執行過程的計算范型。該范型既利用云游戲便利、多平臺同步的特性，又降低了邊緣節點的計算負載。

GSGOD云游戲系統的流程如圖2所示。整個系統的設計和實現分為兩部分：服務器端和客戶端。首先客戶端請求一個游戲實例，服務器響應請求并啟動一個游戲進程。接著客戶端和服務器進入一個交互循環，服務器不斷接收來自客戶端的輸入，客戶端則持續執行來自服務器端的圖形渲染指令。服務器將接收到的用戶輸入注入游戲進程，通過3D指令代理庫攔截3D指令，經過緩存處理和數據壓縮，形成可由網絡傳輸的指令幀?？蛻舳私邮盏街噶顜螅M行解壓并協同本地緩存還原指令序列，隨后這些指令序列被執行后得到游戲畫面。

2.1 服務器端實現

服務器端的核心組件是3D圖形指令代理庫。本文實現了一套3D指令代理庫對系統的圖形API進行攔截和封裝。當前有兩種比較常見的3D圖形API：Direct3D和OpenGL，盡管兩者存在許多實現細節上的差異，但基本的渲染機制和圖形算法是一致，因此兩類圖形API的代理庫實現原理相似。3D指令代理庫繼承圖形API的類和接口，添加了用于重建渲染場景的對象信息，并對API的某些行為進行重寫，這些修改便于獲取場景信息，方便對象管理和對指令幀的處理。GSGOD采用hook機制攔截圖形API的調用信息，并將系統調用信息傳遞給代理庫，代理庫從而接管圖形對象的生成和管理。

本文將執行每幀游戲畫面渲染的所有指令總和稱為指令幀。相鄰或間隔相近的指令幀存在許多圖形渲染指令和圖形幾何數據上的相似性。這些冗余信息若未經數據傳輸優化，將大幅度增加網絡帶寬，導致網絡性能下降。GSGOD采用高效緩存機制緩存指令和幾何數據，數據分別在服務器和客戶端緩存，兩端保持緩存信息和狀態的同步，系統的緩存機制運行邏輯由服務器驅動。關于高效緩存機制的實現細節將在3.1節闡述。經緩存機制優化后傳輸的指令幀在傳輸之前需要進行壓縮，壓縮算法必須高效執行以減少頻繁處理的延遲，本系統采用LZO（Lempel-Ziv-Oberhumer）算法進行快速無損壓縮。壓縮之后的指令幀以網絡數據包傳輸，為了使網絡傳輸有效負荷最大化，GSGOD以最大傳輸單元（Maximum Transmission Unit， MTU）為標準劃分網絡包，同時采用TCP協議保證可靠傳輸。

2.2 客戶端實現

客戶端的主要任務包含：用戶輸入處理、音頻播放和渲染指令執行。GSGOD使用SDL（Simple DirectMedia Layer）庫（https：//www.libsdl.org/）捕捉用戶輸入事件和播放游戲聲音。SDL是一套跨平臺的開發庫，支持對音頻、鍵盤、鼠標、控制桿的底層訪問，并且可以通過OpenGL庫和Direct3D庫訪問GPU。SDL的跨平臺特性使得GSGOD具備良好的可擴展性，同時其事件通知機制可以快速響應用戶輸入，使得用戶輸入及時傳輸至服務器從而保證系統的低響應延遲。

游戲畫面的渲染是客戶端的核心任務。客戶端持續接收來自服務器的指令幀數據包，使用LZO算法快速解壓。解壓后的數據包與緩存管理模塊交互以正確讀取客戶端緩存中的指令參數和圖形幾何數據。

緩存管理模塊根據指令幀數據包的相關索引信息快速檢索本地緩存，取得緩存數據后整合數據包中已有的數據，形成原始的可執行指令。圖形渲染指令的執行依靠具體的圖形API（Direct3D和OpenGL），而這兩種3D圖形API得到各類GPU硬件的廣泛支持，并且它們屏蔽了硬件的底層特性，因此GSGOD實現方案具備良好的通用性。

3 網絡傳輸和響應延遲優化機制

圖形渲染指令的正確執行需要包含正確的指令參數、頂點和索引數據以及紋理數據等。這些數據的數據量大，若未經優化進行傳輸將消耗大量的網絡帶寬。實驗表明，游戲的相鄰畫面幀之間存在大量的場景相似性，因此圖形渲染指令和幾何數據大量重疊，這些冗余的信息可以利用緩存機制有效減少。GSGOD實現了一種高效的服務器和客戶端同步緩存機制，該機制能夠保證數據的有效緩存以及快速索引和讀取。響應延遲的優化包括兩個方面：一方面GSGOD利用圖形指令幀在服務器端和客戶端的執行特性，設計了流水線的執行方式，提升了兩端的執行效率;另一方面，圖形API的許多方法調用需要返回圖形渲染硬件渲染管線的相關狀態，而在GSGOD中，圖形渲染指令的計算和執行是在服務器和客戶端異步執行，服務器如果等待從客戶端返回的結果將導致不可容忍的延遲。GSGOD實現了根據對圖形API類對象信息追蹤和GPU硬件狀態模擬來快速返回方法調用過程的機制。

3.1 高效緩存機制

GSGOD系統在服務器和客戶端實現了一套同步緩存機制，兩者在緩存的數據以及命中狀態信息上保持一致，但在數據組織和管理上存在差異。服務器負責數據的查找和標識，客戶端則根據服務器傳輸的標識進行數據的快速讀取，緩存機制運行的邏輯由服務器驅動。GSGOD緩存了三類圖形相關數據：圖形渲染指令參數、頂點數據（vertex）和索引數據（index）。

3.1.1 指令參數緩存

服務器攔截封裝的指令幀包含成千上萬條的圖形渲染指令，這些圖形渲染指令多數都包含多個參數，有的指令參數數據量大，可以達到成百上千個字節，于是每一指令幀可能包含數千字節乃至上萬字節的參數信息。然而對于一些頻繁調用指令，在幀內或相鄰幀調用時，它們的參數往往相同。GSGOD緩存了一些高頻調用指令的參數，服務器端使用哈希鏈表節點保存指令的參數信息，并輔以哈希表管理節點的查找、插入和刪除等操作，而客戶端則以簡單的數組方式存儲指令的參數。服務器每攔截一條高頻調用指令，便生成其參數的哈希值，并對比哈希鏈表節點中的哈希碼。如果命中某個節點，則服務器生成一個索引值指示客戶端緩存數據的具體位置;若沒有命中，則向客戶端發送原始的參數數據，并更新本地緩存數據。客戶端接收到的指令幀包含緩存命中標志位，緩存管理模塊檢查標志位。若標志位標示緩存命中，客戶端按照索引值讀取本地緩存的參數值;否則接收網絡包中的參數值，并更新本地緩存?？蛻舳说木彺鎴绦羞壿嬘煞掌黩寗?，不同于服務器哈希表的管理方式，客戶端采用數組存儲參數值。這樣的實現方式降低了客戶端的計算負載，同時能夠快速訪問數據。

3.1.2 頂點和索引數據緩存

頂點（Vertex）和索引（Index）數據是圖形渲染指令的重要幾何數據，它們存儲了頂點坐標、法線向量、切線向量、頂點顏色以及頂點索引值等信息。在復雜場景或精細模型建模的游戲中，頂點和索引的數據量往往很大，同時相鄰和相近幀的數據重復度很高。GSGOD緩存了一定數量的頂點和索引數據，并且采取增量更新的方法傳輸更新的數據。服務器計算新的頂點和索引數據與緩存數據的差值，并以地址偏移量標識更新數據的位置，這樣不僅縮小了編址長度同時提高了尋址速度。

3.2 響應延遲優化

云游戲系統的響應延遲是系統的關鍵指標，直接影響游戲玩家的體驗。在云游戲中，響應延遲定義為從玩家輸入控制指令到最終得到游戲畫面的時間間隔。GSGOD系統的延遲組成如圖3所示，包括在服務器端指令攔截、數據包封裝，客戶端的指令執行，以及最耗時的網絡傳輸。視頻流方式的云游戲系統（典型的如GamingAnywhere，詳見1.1節）的響應延遲構成如圖4所示。這種方式首先在服務器端進行畫面渲染，然后通過視頻編碼生成視頻流，隨后進行網絡傳輸。

在GSGOD中，為了降低系統延遲，加快云游戲的執行流程，采用了流水線處理機制。圖5說明了GSGOD系統的處理流程，RD（Response Delay）代表系統的響應延遲。服務器的總處理時間用SP（Server Processing）表示。用戶輸入經過ND（Network Delay）網絡延遲時間之后到達服務器，服務器將用戶輸入注入正在運行的游戲之中并執行游戲邏輯，隨后開始產生圖形渲染指令;經過短暫的啟動時間PB（Pipeline Beginning），圖形渲染指令及其相關的圖形數據被封裝成數據包送往客戶端，客戶端隨即開始執行渲染指令。這里需要注意的是，服務器不會等待一個完整的游戲幀處理結束才開始數據傳輸，而是當數據量達到一個閾值（比如一個MTU）就立即開始傳輸。服務器端生成渲染指令、指令數據網絡傳輸、客戶端執行渲染指令三者并發執行，實現了一種處理流水線，并持續一個時間周期PR（Pipeline Running）。最后，客戶端在接收到所有圖形數據之后的PS時間（Pipeline Stalling），完成游戲幀的渲染，整個客戶端的處理時間為CP（Client Processing）。

視頻流方式的云游戲系統的處理流程如圖6所示。在視頻流方式中，服務器花費SP（Server Processing）時間處理從用戶輸入注入游戲直至視頻流傳輸至客戶端的過程。服務器端的主要處理過程包括執行游戲邏輯從而生成圖形渲染指令、游戲畫面渲染、內存數據拷貝及格式轉換、使用H.264協議進行視頻編碼以及最后的封裝數據包進行傳輸。這些操作在游戲畫面幀粒度層次上并行，而GSGOD在更細粒度的指令數據包上流水處理，因此GSGOD在整體的延遲上較視頻流有優勢。

3.3 對象管理和狀態同步

GSGOD攔截了游戲的圖形渲染指令，使指令在服務器和客戶端異步執行。服務器并不執行畫面的渲染，但其需要掌握當前圖形API類對象以及GPU硬件渲染管線（Pipeline）的狀態，而服務器和客戶端的異步執行大幅度增加了服務器同步客戶端狀態的響應時間。GSGOD維護了服務器和客戶端圖形API類對象列表，在圖形渲染指令執行過程中，每一個對象的初始化操作將在服務器和客戶端同時生成圖形對象，并設置一致的對象ID進行對象索引。這種方式保證了類對象的快速調用和狀態同步。同時GSGOD實現了硬件狀態模擬機制：系統初始化時，服務器獲取客戶端的GPU相關參數，這些參數合并服務器自身的GPU參數，形成一個標準參數集合;當圖形API類對象需要獲取和設置GPU狀態時，服務器以自身GPU狀態模擬客戶端硬件執行，并預測對象方法的返回值。該機制確保了GSGOD圖形渲染指令的快速執行和返回，減少了端到端的延遲。

針對圖形渲染指令中一些臨界資源（互斥訪問資源）的訪問操作，GSGOD實現了一種延遲狀態同步機制。這些資源訪問操作包含頂點和索引的更新、表面繪制、紋理映射等，這些方法涉及到臨界資源的鎖（lock）和解鎖（unlock）等費時操作。在場景繪制中，通常需要在短時間內頻繁地訪問臨界資源，而在服務器和客戶端異步執行時，若每次訪問臨界資源都執行端到端的狀態同步，將導致大量的時間開銷。在實際運行中，上述的資源訪問操作在多數情況下并未立即生效，因此GSGOD實現了一種端到端的狀態延遲同步機制，即直到資源狀態真正改變時才執行同步。延遲同步機制合并了資源訪問操作，減小了頻繁資源更新的時間開銷。

4 系統評估

Gaming@Edge中游戲服務注冊，邊緣節點的注冊和發現以及資源管理采用Python語言實現，而GSGOD目前實現了Direct3D的版本，基于C++語言實現，代碼超過20000行。本章從三個方面對GSGOD的性能進行評估：游戲實例的服務器并發測試、系統響應延遲以及緩存機制性能。實驗搭建了一臺具有高性能GPU的服務器作為邊緣節點，服務器使用VMware Workstation技術提供虛擬桌面連接，宿主機和虛擬主機均采用Windows 7操作系統，每個客戶端連接一個虛擬主機，具體的實驗環境配置參見表1，實驗平臺的部署如圖7所示。

本實驗選取了三類不同的熱門3D游戲進行系統測試，分別是休閑類游戲SprillRitchie、策略類游戲CastleStorm和動作類游戲Trine。經實驗測試，游戲CastleStorm和Trine的邏輯計算和渲染計算復雜度均高于SprillRitchie。為了對比視頻流云游戲系統的性能，本實驗采用GamingAnywhere（GA）[11]作為視頻流云游戲機制的參照系統。如1.1節所述，GA是學術界知名的開源視頻流云游戲系統，由臺灣幾所大學聯合開發。GA系統實現了視頻流云游戲機制的完整功能，即客戶端的輸入處理和畫面輸出，服務器的游戲執行、畫面渲染以及視頻流的壓縮和傳輸;同時，它還優化了系統的擴展性、移植性和配置性。

4.1 游戲實例并發測試

本節測試服務器游戲實例的并發能力，即隨著客戶端連接數目不斷增加（服務器并發的游戲實例逐漸增加），服務器的幀速率（Frames Per Second， FPS）、CPU利用率和GPU利用率。本節測試服務器游戲實例的并發能力，即測試當客戶端連接數目不斷增加時（服務器并發的游戲實例逐漸增加），服務器的幀速率（Frames Per Second， FPS）、CPU利用率和GPU利用率的變化情況。此處語句不通順幀速率表明了圖形處理器每秒能夠渲染刷新的畫面幀數目，它是一種綜合體現圖形處理設備渲染能力的指標。幀速率高于每秒10～12幀時，畫面被認為是連貫的，一般認為FPS大于25幀時，游戲畫面是流暢的。在并發測試中，每個客戶端連接一個虛擬機（Virtual Machine， VM），每個虛擬機運行一個游戲實例，一個虛擬機分配1GB內存。圖8圖8、圖9、圖10分別顯示了3個游戲在虛擬機個數從1到8情況下服務器的性能表現，其中FPS為計算所有虛擬機幀速率的平均值。實驗結果表明GSGOD系統在三個指標上均優于GA，即服務器整體的負載小，游戲運行綜合性能好。這主要因為GSGOD實現的圖形流云游戲機制采取游戲邏輯和圖形渲染分離的機制，并由客戶端執行圖形渲染，從而降低了服務器的負載，大幅度提升了服務器的整體性能。

4.1.1 游戲實例并發性能

游戲實例并發性能反映了服務器運行的綜合性能，即在相同硬件配置下，服務器能夠運行的最大有效游戲實例數目。這里“有效”游戲實例指游戲運行時FPS能夠大于某個閾值（以25FPS為基準），達到運行流暢的標準。表2對比了GSGOD和GA系統在CastleStorm和Trine中（SprillRitchie邏輯較為簡單，當服務器達到最大承載虛擬機數時，其FPS仍高于游戲流暢標準，因此不作對比。）游戲實例并發性能，可以看出GSGOD分別取得1.67倍和7倍的性能提升。

4.1.2 CPU和GPU利用率

GSGOD不僅獲得了良好的游戲FPS性能，同時其服務器的CPU利用率也相對較低。GSGOD的3D指令代理庫在攔截渲染指令時，增加了額外的計算開銷，但是這些開銷低于GA在游戲畫面視頻編碼時產生的計算開銷，因此GSGOD系統服務器CPU計算負載更低。隨著游戲復雜度的增加，這種趨勢更加明顯。

實驗結果中三個游戲的GPU利用率呈現出不同的變化趨勢，但總體看來GSGOD仍然顯著低于GA系統。GPU利用率跟游戲自身特性以及游戲的幀速率密切相關。通常情況下，當游戲場景越復雜、幀速率越高時，GPU渲染的負載越高。SprillRitchie是休閑類游戲，畫面復雜度低，GPU能夠以較少的處理時間高速渲染游戲場景，因此表現出很高的幀速率和較高的GPU利用率，而CastleStorm和Trine兩款游戲由于場景復雜，對象模型數據量大以及眾多的紋理和光影特效等，使得GPU渲染游戲的負載增長較為平穩。三個游戲的GPU利用率變化先是隨著游戲實例數的增加而升高，達到一定閾值之后，實驗硬件設備達到較大的負載，隨后游戲的整體幀速率下降明顯，GPU利用率也隨之下降。在GSGOD中，雖然服務器端不執行圖形的渲染，但是一些圖形操作，如圖形指令生成、模型加載以及紋理的處理等仍然需要大量GPU的參與，因此當游戲實例數增加時，GPU的負載隨之增加。由于GSGOD系統遷移了大部分的渲染任務，因此其GPU利用率較GA有明顯的下降;同時視頻流方案中，游戲畫面的實時壓縮使得渲染數據在GPU專屬內存和系統內存中頻繁拷貝，導致了系統處理時間增加，而多個虛擬機共享GPU也加劇了其性能的下降。

4.2 系統響應延遲

云游戲系統作為一個實時系統，對系統的響應延遲有很高的要求，不同類型的游戲對于端到端延遲有明確限定[24]。云游戲的響應延遲定義為：從客戶端接收一個用戶輸入，直至用戶最終在客戶端看到由該輸入觸發的游戲畫面幀為止的時間間隔[25]。GSGOD系統的響應延遲包含三部分：網絡傳輸延遲，通常情況下可以認為是網絡的往返時延RTT;服務器處理用戶請求的時間，即服務器接收用戶輸入并注入到游戲中，隨后執行邏輯處理，完成某一特定幀渲染指令的封裝，并傳輸該幀數據包的總時間開銷;客戶端完成幀渲染的時間，即客戶端接收到來自服務器的數據包并調用圖形API完成幀渲染的時間。GA系統的響應延遲劃分與GSGOD類似，但是其服務器處理請求需要完成畫面渲染和視頻壓縮，而客戶端則是播放視頻。關于兩個系統的延遲構成細節可以參閱3.2節。

測試響應延遲是一項復雜的工作，主要是由于系統很難捕獲用戶輸入所指向的特定幀。文獻[25]通過測定特殊畫面（如游戲菜單選擇界面）的像素值變化來判斷用戶輸入所產生的渲染畫面，該方式具有一定的特殊性，無法測試游戲運行過程中不同場景的延遲。本實驗的方法是通過向服務器發送特殊的鍵盤輸入（如F8），服務器接收到該輸入指令后，在當前幀的下一幀執行輸入請求，完成指令封裝或者幀渲染處理之后立即將數據返回給客戶端，其中的時間間隔即為該輸入產生的延遲。本實驗分別對三個游戲進行300次延遲采樣，圖119對比了兩個系統的平均響應延遲（300次延遲的平均值）。結果表明GSGOD的平均響應延遲遠低于GA，主要是由于GSGOD端到端更快的流水線處理（如3.2節所述）。在GSGOD系統中，服務器渲染指令的攔截，數據包的封裝和發送可以快速啟動而不必等待完整一幀指令全部產生，即一旦指令產生，就可以開始數據封裝和網絡傳輸。該方式加快了服務器和客戶端的渲染同步，降低了系統響應延遲。

4.3 緩存機制性能

緩存機制在GSGOD系統中發揮重要的作用，本節評估了緩存機制的性能。實驗針對GSGOD在游戲運行過程中Direct3D庫高頻調用方法的一個子集：{SetIndices，SetStreamSource，SetTexture，DrawIndexedPrimitives}的緩存性能進行了評估。實驗中，分別運行三個游戲5min，記錄其總渲染幀數、高頻子集的總調用次數和總命中次數，實驗結果如表3所示。結果表明，高頻調用方法集在游戲渲染中調用頻繁，并且指令參數緩存機制具備很高的命中率，將節省大量的網絡傳輸帶寬。

5 結語

云游戲是云計算的“殺手級”應用，它帶來了游戲運行方式的革命性變革，但是受限于客戶端與云數據中心較大的響應延遲，云游戲體驗不佳。本文提出一種基于邊緣節點部署的云游戲運行框架——Gaming@Edge，該框架能夠有效降低系統的延遲;同時，為了降低邊緣節點的計算負載，Gaming@Edge設計和實現了一種基于壓縮圖形流的云游戲運行機制——GSGOD。GSGOD通過攔截游戲渲染的3D圖形指令，并遷移至客戶端進行本地渲染的方式，實現了一種客戶端和邊緣節點的計算融合。這種方式既繼承了云游戲諸多優點，又有效降低了邊緣節點的計算負載。此外，GSGOD通過高效的緩存機制優化了網絡數據量的傳輸，同時基于指令流水線處理、對硬件狀態模擬的異步執行方式，以及延遲狀態同步等方法，降低了系統端到端的延遲。最后，本文從系統的并發性、游戲的響應延遲以及緩存性能等三個方面綜合評估了系統性能。實驗結果表明GSGOD顯著提升了服務器游戲實例并發性能，同時獲得較小的系統響應延遲。

參考文獻 （References）

[1] ROSS P E. Cloud computings killer app： gaming [J]. IEEE Spectrum， 2009， 46（3）： 14.

[2] CAI W， SHEA R， HUANG C Y， et al. The future of cloud gaming point of view] [J]. Proceedings of the IEEE， 2016， 104（4）： 687-691.

[3] USMAN M， IQBAL A， KIRAN M. A bandwidth friendly architecture for cloud gaming [C]// Proceedings of the 2017 IEEE International Conference on Information Networking. Piscataway， NJ： IEEE， 2017： 179-184.

[4] SHEA R， LIU J C， NGAI E C H， et al. Cloud gaming： architecture and performance [J]. IEEE Network， 2013， 27（4）： 16-21.

[5] DOWTY M， SUGERMAN J. GPU virtualization on VMwares hosted I/O architecture [J]. ACM SIGOPS Operating Systems Review， 2009， 43（3）： 73-82.

[6] ZHANG W， LIAO X F， LI P， et al. ShareRender： bypassing GPU virtualization to enable fine-grained resource sharing for cloud gaming [C]// Proceedings of the 25th ACM International Conference on Multimedia. New York： ACM， 2017： 324-332.

[7] 施魏松，孫輝，曹杰，等.邊緣計算：萬物互聯時代新型計算模型[J].計算機研究與發展，2017，54（5）：907-924.（SHI W S， SUN H， CAO J， et al. Edge computing—an emerging computing model for the Internet of everything era [J]. Journal of Computer Research and Development， 2017， 54（5）： 907-924.）

[8] SHI W S， CAO J， ZHANG Q， et al. Edge computing： vision and challenges [J]. IEEE Internet of Things Journal， 2016， 3（5）： 637-646.

[9] SATYANARAYANAN M， BAHL V， CACERES R， et al. The case for VM-based cloudlets in mobile computing [J]. IEEE Pervasive Computing， 2009， 8（4）： 14-23.

[10] LIAO X F， LIN L， TAN G， et al. LiveRender： a cloud gaming system based on compressed graphics streaming [J]. IEEE/ACM Transactions on Networking， 2016， 24（4）： 2128-2139.

[11] HUANG C Y， HSU C H， CHANG Y C， et al. GamingAnywhere： an open cloud gaming system [C]// Proceedings of the 4th ACM Multimedia Systems Conference. New York： ACM， 2013： 36-47.

[12] SHI S， HSU C H， NAHRSTEDT K， et al. Using graphics rendering contexts to enhance the real-time video coding for mobile cloud gaming [C]// Proceedings of the 19th ACM International Conference on Multimedia. New York： ACM， 2011： 103-112.

[13] LEE K， CHU D， CUERVO E， et al. Outatime： using speculation to enable low-latency continuous interaction for mobile cloud gaming [C]// Proceedings of the 13th Annual International Conference on Mobile Systems， Applications， and Services. New York： ACM， 2015： 151-165.

[14] LIN Y， SHEN H. CloudFog： leveraging fog to extend cloud gaming for thin-client MMOG with high quality of service [J]. IEEE Transactions on Parallel and Distributed Systems， 2017， 28（2）： 431-445.

[15] NAVE I， DAVID H， SHANI A， et al. Games@Large graphics streaming architecture [C]// Proceedings of the 2008 IEEE International Symposium on Consumer Electronics. Piscataway， NJ： IEEE， 2008： 1-4.

[16] EISERT P， FECHTELER P. Low delay streaming of computer graphics [C]// Proceedings of the 15th IEEE International Conference on Image Processing. Piscataway， NJ： IEEE， 2008： 2704-2707.

[17] JURGELIONIS A， FECHTELER P， EISERT P， et al. Platform for distributed 3D gaming [J]. International Journal of Computer Games Technology， 2009， 2009（1）： 1-15.

[18] GUBBI J， BUYYA R， MARUSIC S， et al. Internet of Things （IoT）： a vision， architectural elements， and future directions [J]. Future Generation Computer Systems， 2013， 29（7）： 1645-1660.

[19] HU Y C， PATEL M， SABELLA D， et al. Mobile edge computing—a key technology towards 5G [J]. ETSI White Paper， 2015， 11（11）： 1-16.

[20] 劉小洋，伍民友.車聯網：物聯網在城市交通網絡中的應用[J].計算機應用，2012，32（4）：900-904.（LIU X Y， WU M Y. Vehicular CPS： an application of IoT in vehicular networks [J]. Journal of Computer Applications， 2012， 32（4）： 900-904.）

[21] CHEN T Y， RAVINDRANATH L， DENG S， et al. Glimpse： continuous， real-time object recognition on mobile devices [C]// Proceedings of the 13th ACM Conference on Embedded Networked Sensor Systems. New York： ACM， 2015： 155-168.

[22] DINH H T， LEE C， NIYATO D， et al. A survey of mobile cloud computing： architecture， applications， and approaches [J]. Wireless Communications and Mobile Computing， 2013， 13（18）： 1587-1611.

[23] SATYANARAYANAN M， SIMOENS P， XAIO Y， et al. Edge analytics in the Internet of things [J]. IEEE Pervasive Computing， 2015， 14（2）： 24-31.

[24] CLAYPOOL M， CLAYPOOL K. Latency and player actions in online games [J]. Communications of the ACM， 2006， 49（11）： 40-45.

[25] CHEN K T， CHANG Y C， TSENG P H， et al. Measuring the latency of cloud gaming systems [C]// Proceedings of the 19th ACM International Conference on Multimedia. New York： ACM， 2011： 1269-1272.