雲遊戲流媒體總體架構設計（雲遊戲流媒體技術前瞻，最近雲遊戲概念很火，加之對流媒體技術略有研究，簡單寫一些）

前言：

遙想當年阿法狗戰敗一衆圍棋國手，風氣一轉，彷佛全部人都懂AI。此次谷歌又放出了stadia，國內鵝廠再次跑步進場，貴州某xx雲提早佈局。

閒來無事，嘗試體驗了一下貴州某xx雲的雲遊戲（不打廣告），暫且不評論如何如何，恰好對流媒體技術略有研究，僅在這裏簡單聊一下這方面涉及的架構和技術。

架構設計：

整體架構自上而下大體分爲四端：

一、雲遊戲主機端（雲遊戲運行端，或者叫雲遊戲畫面渲染端，須要接收控制指令並錄屏推流到流媒體服務）

主機端須要運行遊戲並讓經過錄屏推流程序把渲染好的遊戲畫面（其實就是錄屏）推流到流媒體服務進行實時視頻分發。

有人會想這個雲遊戲主機端可能會很複雜，其實也還好，只是包含了錄屏、推流、用戶控制指令接收和一些其餘諸如計費此類的相關功能。

二、流媒體服務（用於轉發主機端推上來的遊戲實時視頻並分發出去，全部用戶均可以觀看這個視頻）

這個不須要多講了，只是用來轉發遊戲實時視頻，並不涉及雲遊戲主機的控制權。

三、控制指令轉發服務（用戶須要獲取控制指令服務的全部權才能控制雲遊戲主機）

這個是雲遊戲的控制核心，獲取某臺雲遊戲主機的用戶就能夠經過鍵盤或者鼠標進行雲遊戲的試玩（操做），理論上講可以獲取該控制權的不是隻有一個用戶，徹底能夠支持多個用戶同時控制一臺雲遊戲主機。

四、客戶端（瀏覽器，pc客戶端，ios，安卓客戶端等）

客戶端須要從流媒體服務拉取實時遊戲視頻，用戶須要先獲取雲遊戲主機的控制權，纔可以發送控制指令來試玩（操做）雲遊戲（鼠標，鍵盤，手柄等）

靈魂畫師繪製結構圖：

架構示意圖-來自靈魂畫師的傾情手繪

難點或者叫待解決的點：

一、流媒體協議的選擇？高延遲纔是最大殺手

從流媒體技術出身開始，實時視頻延遲一直是個比較棘手的問題，好比rtmp/http-flv等基於tcp的協議自己優化到極點也要幾百毫秒的延遲，hls這種超高延遲到幾秒的不提也罷。就目前看只有sip、rtsp以及基於udp的一些協議可以知足這種超低延遲的需求，可是這種協議就很難在瀏覽器上就很難實現了，除了webrtc，而webrtc協議是谷歌力推的下一代流媒體協議，不排除此次是谷歌webrtc技術的奠定之做，拭目以待。

二、雲遊戲主機控制指令的全部權？依然是延遲

這個全部權其實不算是難點，只是用戶獲取某臺雲遊戲主機的控制權而已。難點在於控制指令的延遲，沒錯，就是網絡延遲。尤爲是在拉取實時視頻時，在視頻已經佔用大量帶寬的狀況下，在這種網絡負載或者網絡波動較大的狀況下控制指令延遲或許值得重視。

跟不少朋友討論過雲遊戲這個話題，不約而同第一個想到的都是網絡延遲，固然這個延遲不只包含控制指令的延遲也指實時遊戲視頻的延遲。

 

後言（囉嗦幾句）：

其實這塊依然屬於共享經濟的後續，相似共享單車。

給你們舉個栗子：我有一百臺性能強勁的遊戲主機，每臺主機價值一萬，當二手貨賣掉可能還會虧點，好惋惜。那麼我把他共享出來，假設如今有十萬個用戶想租我這一百臺機器，而後每人只收10塊錢月租，不考慮電費等其餘成本，請問我何時能回本？

做者：eguid

說明：原CSDN相關博客文章已經所有轉移到博客園