以網遊服務端的網路接入層設計為例，理解實時通信的技術挑戰
以網遊服務端的網路接入層設計為例，理解實時通信的技術挑戰
來自專欄即時通訊技術分享
12 人贊了文章
本文參考並引用了部分騰訊遊戲學院的相關技術文章內容，感謝原作者的分享。
1、前言
以現在主流的即時通訊應用形態來講，一個完整的即時通訊IM應用其實是即時通信（英文簡寫：IM=Instant messaging）和實時通信（英文簡寫：RTC=Real-time communication）2種技術組合在一起的一整套網路通信系統。之所以以IM這個簡寫代稱整個即時通訊軟體，其實是歷史原因了（因為早期的諸如ICQ這樣的即時通訊工具，也就是文字聊天，並沒有加入實時音視頻這樣的實時通信技術），對這個話題有興趣的可以到網上查一查IM的發展歷史。
以微信、QQ這樣的完整即時通訊應用來說，回歸到工具的本質，它主要包含了兩種應用和技術：
1）廣義的文字聊天：也就是我最常理解的各種聊天消息的傳遞，這部分的技術實現就是眾所周之的IM通信（即Instant messaging）；
2）實時音視頻聊天：包括語音電話、視頻聊天，這部分的技術實現，從網路通信的角度講，就是實時通信（即Real-time communication）。
我們回憶一下：早幾年前市面上主流的移動端IM——比如微信、QQ、以及現在滿屏廣告的網易易信、半死不活的小米米聊、已經入土的阿里來往、打擦邊球的陌陌等，基本都沒有或者很晚才加入實時音視頻聊天功能（我們拋開技術因素之外的原因不議），原因不是不想做，而是實時音視頻這種實時通信技術確實是有相當的門檻，並不容易做。
所以：對於即時通訊網社區內眾多的IM應用開發者來說，實時通信技術如此重要，深入研究和理解實時通信技術的原理、技術實踐，對於自已IM產品的開發來說，都是大有裨益的。
本文將嘗試從開發者角度：梳理開發網遊服務端的網路接入層的過程中面臨的各種技術挑戰，並針對性地提供相應的實時通信網路接入層解決思路，希望對於即時通訊應用的開發者來說，可以從中得到些許啟發。
學習交流：
- 即時通訊開發交流3羣：185926912 [推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發佈於：http://www.52im.net/thread-1915-1-1.html）
2、相關文章
《計算機網路通訊協議關係圖（中文珍藏版）》
《高性能網路編程(一)：單臺伺服器並發TCP連接數到底可以有多少》《高性能網路編程(二)：上一個10年，著名的C10K並發連接問題》《高性能網路編程(三)：下一個10年，是時候考慮C10M並發問題了》《高性能網路編程(四)：從C10K到C10M高性能網路應用的理論探索》《不為人知的網路編程(六)：深入地理解UDP協議並用好它》
《不為人知的網路編程(七)：如何讓不可靠的UDP變的可靠？》《網路編程懶人入門(三)：快速理解TCP協議一篇就夠》《網路編程懶人入門(四)：快速理解TCP和UDP的差異》《網路編程懶人入門(五)：快速理解為什麼說UDP有時比TCP更有優勢》《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》《腦殘式網路編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》《腦殘式網路編程入門(二)：我們在讀寫Socket時，究竟在讀寫什麼？》《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》《理解實時音視頻聊天中的延時問題一篇就夠》《寫給小白的實時音視頻技術入門提綱》
3、主流網遊的網路通信架構原理
維基百科關於網路遊戲的定義：
即通過計算機網路，將專用伺服器和用戶的客戶端設備(手機、PC、遊戲主機等)相連，讓多名玩家同時聯機進行遊戲的娛樂形式。
由此可知網路遊戲涉及三個角色：
1）客戶端；
2）網路；
3）伺服器。
從網路架構上來講，網遊可分為：
1）C/S 架構：這個最好理解；
2）P2P架構：特指客戶端間直連通信；
3）C/M架構：在實際開發中這是一種C/S和P2P架構的混合體。
典型的網路架構如下圖所示：
P2P架構不在本文討論範圍。
C/M架構和C/S架構相似，跟經典的LAMP網站架構類似，一般C/S架構的遊戲後臺也可劃分為如下三層：
1）網路接入層；
2）遊戲邏輯層；
3） 數據存儲層。
一般C/S架構的遊戲後臺分層，如下圖所示：
網路接入、遊戲邏輯、數據存儲層各自所面臨的問題域及對應技術棧都大為不同，做此劃分不僅有助於模塊解耦、技術分工、組件復用，也可方便服務的運維部署。本文要討論的就是這個網路接入層。
4、題外話：該如何理解C/M架構？
可能有人對上節中的C/M架構有疑問，在網遊中這個架構到底是怎麼用的？
其實，網路遊戲中是通過同步機制來保證各個客戶端遊戲世界的一致性。
主流的網遊數據同步機制有兩種：
1）狀態同步：即由客戶端負責將玩家的操作發往中心節點 (伺服器或master客戶端)，由中心節點來負責遊戲邏輯計算並將計算結果廣播給客戶端，再由客戶端負責渲染遊戲結果
2）幀同步：幀同步的理論基礎是遊戲邏輯由操作指令驅動，只要操作序列一致，那麼遊戲結果就應該一致。
也就是說，不管採用哪種數據同步機制，其實都是應用的C/M架構（即Client/Master架構）。
5、網路接入層的作用
網路接入層的主要任務是：
1）建立客戶端和後臺服務以及客戶端之間的信道，；
2）接收來自客戶端大量並發請求。
考覈該層的主要性能指標是：
1）高吞吐；
2）低延遲。
因而網路接入層開發考驗的是開發者高性能網路編程的功底，即解決C10K甚至C10M的能力。
題外話：有關高性能網路編程的C10K、C10M話題，請詳細閱讀以下文章
《高性能網路編程(一)：單臺伺服器並發TCP連接數到底可以有多少》
《高性能網路編程(二)：上一個10年，著名的C10K並發連接問題》《高性能網路編程(三)：下一個10年，是時候考慮C10M並發問題了》《高性能網路編程(四)：從C10K到C10M高性能網路應用的理論探索》
6、網路接入層的通信協議選擇
根據OSI的七層網路參考模型，我們可將網遊網路也做如下7層劃分：
其中4層以下都由操作系統來負責，開發者無需為此操心，在實際的開發過程中開發者首要面臨的問題便是傳輸層是採用TCP還是UDP，下表簡要對比了兩者的優劣。 綜合兩者優劣，簡單來說除非對延遲有極致要求(例如FPS、MOBA類遊戲)需採用UDP外，TCP可應對大部分遊戲。
在實際遊戲開發中不管是採用TCP還是UDP方式，都較少利用通過Socket編程方式直接進行，一來因為開發工作量大，質量性能難以保證；二來平臺兼容性不好(比如H5並沒有提供socket編程能力)，而是基於更上層的通訊協議比如基於TCP的HTTP、Websocket協議，GRPC，以及基於UDP實現的QUIC，WebRTC協議等。
TCP、UDP協議的簡要對比：
有關TCP、UDP協議的詳細對比文章，您可簡讀一下資料：
《網路編程懶人入門(四)：快速理解TCP和UDP的差異》
《網路編程懶人入門(五)：快速理解為什麼說UDP有時比TCP更有優勢》《簡述傳輸層協議TCP和UDP的區別》《為什麼QQ用的是UDP協議而不是TCP協議？》《移動端即時通訊協議選擇：UDP還是TCP？》
值得注意的是基於安全性考慮，瀏覽器標準未提供UDP收發能力，QUIC協議也只在chrome得到了支持，WebRTC也還不是瀏覽器事實標準且協議初始目的是用於實現點對點的音視頻通信，協議內容過於龐雜不容易提煉應用於遊戲開發中，因而現階段H5遊戲還只能採用HTTP或Websocket方式通訊。
知識點掃盲：
1）關於QUIC協議：《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》；
2）關於WebRTC：《開源實時音視頻技術WebRTC的現狀》、《簡述開源實時音視頻技術WebRTC的優缺點》、《訪談WebRTC標準之父：WebRTC的過去、現在和未來》；
3）關於Websocket：《新手入門貼：史上最全Web端即時通訊技術原理詳解》、《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》、《新手快速入門：WebSocket簡明教程》、《WebSocket詳解（一）：初步認識WebSocket技術》。
另外 ，通訊協議確定後，隨後要考慮的便是遊戲對象的序列化，序列化主要有基於文本、基於二進位兩種，其優劣如下表所示。在開發過程中一般會先採用文本序列化方式，便於前後端開發聯調，在遊戲正式上線前切換至二進位序列化方式以減少傳輸流量、提升編解碼效率。
遊戲對象的主要序列化方式：
關於Protobuf的詳細資料，請見：
《Protobuf通信協議詳解：代碼演示、詳細原理介紹等》
《強列建議將Protobuf作為你的即時通訊應用數據傳輸格式》《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數據傳輸更省更快(原理篇)》《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數據傳輸更省更快(實戰篇)》
至於數據安全性問題，為了保護敏感數據安全開發者可以選擇安全的https或WSS通訊協議，而對於直接基於TCP協議通訊，可採用先用RSA協商加密祕鑰，然後使用對稱加密方式將數據加密後發送。
通過以上分析，對於遊戲協議類型的選擇我們給出有以下準則：
1）弱聯網類遊戲：諸如休閑、卡牌類遊戲可直接HTTP協議，對安全性有要求的話就使用HTTPS；
2）實時性，交互性要求較高：這類遊戲一般需要保持長連接，優先選擇標準的ws協議（同時使用二進位序列化方式，如Protobuf），如考慮安全性可使用wss協議。而對於提供socket介面的native平臺也可使用TCP協議，同時對數據做對稱加密增強安全性；
3）實時性要求極高：不僅需要和伺服器保持長連接，且延遲和網路抖動都要求極高（如FPS，賽車類遊戲），可使用基於UDP的實現流傳輸協議如QUIC，KCP等。
7、網路接入層的並發模型
為了處理來自客戶端的並發請求，服務端有4種常見的並發模型。
7.1）進程：
進程是最早採用的並發模型，進程作為操作資源分配、調度的單位，擁有獨立的運行空間。進程並發模型中每個請求由獨立的進程來處理，進程一次只能處理一個請求，該模型最大的優點就是簡單。如果處理請求的進程由於系統調用而阻塞或進程的時間片用完，搶佔式的進程調度器就會暫停舊進程執行，調度執行新的進程，這個過程涉及大開銷的上下文切換，進程並發模型的缺點是比較低效。最典型的採用進程模型的服務有Apache。
7.2）線程：
線程並發模型是進程模型的改進，線程從屬於進程，是系統更小粒度的執行調度單元。不同請求可由進程內多個並發執行的線程來處理，這些線程由操作系統內核自動調度。線程相對進程的主要優勢在於，調度上下文切換開銷更小，但由於多個線程共享地址空間，需要額外的線程間互斥、同步機制來保證程序性正確性。典型的採用線程模型的服務有Tomcat。
7.3）IO多路復用：
利用操作系統提供的epoll等IO多路復用機制，能同時監控多個連接上讀、寫事件， IO多路復用也稱事件驅動模型，網路程序執行邏輯可抽象為事件驅動的狀態機。 IO多路復用避免了讀寫阻塞，減少了上下文切換，提升了CPU利用率和系統吞吐率。但IO多路復用它將原本「同步」、線性的處理邏輯變成事件驅動的狀態機，處理邏輯分散於大量的事件回調函數。這種非同步、非線性的模型，極大地增加了編程難度，如nodeJs的常見的回調地獄問題。典型的採用IO復用模型的服務有Nginx、Netty。
7.4）協程：
協程也稱為輕量級線程，是一種協同的、非搶佔式的多任務並發模型。 協程運行在用戶空間，當遇到阻塞或特定入口時，通過顯式調用切換方法主動讓出CPU，由任務調度器選取另一個協程執行。
協程切換隻是簡單地改變執行函數棧，不涉及內核態與用戶態轉化，也涉及上下文切換，開銷遠小於進程/線程切換。協程的概念雖早已提出，隨著近些年年越來越多的語言（go、 Haskell）內置對協程支持才被開發者所熟知，協程極大的優化了開發者編程體驗，在同步、順序編程風格能快速實現程序邏輯，還擁有IO多路復用非同步編程的性能。典型的採用協程模型的服務有openresty(Lua), gevent(Python), golang。
7.5）小結：
以上總結了目前4種常用的並發模型，它們在工作原理、運行效率、編程難度等方面有顯著區別，各自有適用場景，在實際使用時應該根據需求仔細評估。在實際開發過程中如果沒有可復用的現成網路組件或歷史包袱我們建議使用協程併發模式開發網路接入層服務。
附錄：更多精華文章，供進一步學習
[1] 網路編程基礎資料：
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》《TCP/IP詳解 - 第18章·TCP連接的建立與終止》《TCP/IP詳解 - 第21章·TCP的超時與重傳》《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》《通俗易懂-深入理解TCP協議（上）：理論基礎》《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》《理論經典：TCP協議的3次握手與4次揮手過程詳解》《理論聯繫實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》《計算機網路通訊協議關係圖（中文珍藏版）》《UDP中一個包的大小最大能多大？》《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》《通俗易懂：快速理解P2P技術中的NAT穿透原理》《不為人知的網路編程(一)：淺析TCP協議中的疑難雜症(上篇)》《不為人知的網路編程(二)：淺析TCP協議中的疑難雜症(下篇)》《不為人知的網路編程(三)：關閉TCP連接時為什麼會TIME_WAIT、CLOSE_WAIT》《不為人知的網路編程(四)：深入研究分析TCP的異常關閉》《不為人知的網路編程(五)：UDP的連接性和負載均衡》《不為人知的網路編程(六)：深入地理解UDP協議並用好它》《不為人知的網路編程(七)：如何讓不可靠的UDP變的可靠？》《網路編程懶人入門(一)：快速理解網路通信協議（上篇）》《網路編程懶人入門(二)：快速理解網路通信協議（下篇）》《網路編程懶人入門(三)：快速理解TCP協議一篇就夠》《網路編程懶人入門(四)：快速理解TCP和UDP的差異》《網路編程懶人入門(五)：快速理解為什麼說UDP有時比TCP更有優勢》《網路編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》《網路編程懶人入門(七)：深入淺出，全面理解HTTP協議》《網路編程懶人入門(八)：手把手教你寫基於TCP的Socket長連接》《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》《現代移動端網路短連接的優化手段總結：請求速度、弱網適應、安全保障》《聊聊iOS中網路編程長連接的那些事》《移動端IM開發者必讀(一)：通俗易懂，理解移動網路的「弱」和「慢」》《移動端IM開發者必讀(二)：史上最全移動弱網路優化方法總結》《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》《腦殘式網路編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》《腦殘式網路編程入門(二)：我們在讀寫Socket時，究竟在讀寫什麼？》《腦殘式網路編程入門(三)：HTTP協議必知必會的一些知識》《腦殘式網路編程入門(四)：快速理解HTTP/2的伺服器推送(Server Push)》《以網遊服務端的網路接入層設計為例，理解實時通信的技術挑戰》>> 更多同類文章 ……[2] 有關網路通信的格式、協議的選擇：《Protobuf通信協議詳解：代碼演示、詳細原理介紹等》《一個基於Protocol Buffer的Java代碼演示》《全方位評測：Protobuf性能到底有沒有比JSON快5倍？》《移動端IM開發需要面對的技術問題（含通信協議選擇）》《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》《理論聯繫實際：一套典型的IM通信協議設計詳解》《58到家實時消息系統的協議設計等技術實踐分享》《詳解如何在NodeJS中使用Google的Protobuf》>> 更多同類文章 ……[3] 實時音視頻開發的其它精華資料：《即時通訊音視頻開發（一）：視頻編解碼之理論概述》《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》《即時通訊音視頻開發（九）：實時語音通訊的迴音及迴音消除概述》《即時通訊音視頻開發（十）：實時語音通訊的迴音消除技術詳解》《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》《IM實時音視頻聊天時的回聲消除技術詳解》《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》《如何優化傳輸機制來實現實時音視頻的超低延遲？》《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》《Android直播入門實踐：動手搭建一套簡單的直播系統》《網易雲信實時視頻直播在TCP數據傳輸層的一些優化思路》《實時音視頻聊天技術分享：面向不可靠網路的抗丟包編解碼器》《P2P技術如何將實時視頻直播帶寬降低75%？》《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》《微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密》《近期大熱的實時直播答題系統的實現思路與技術難點分享》《福利貼：最全實時音視頻開發要用到的開源工程匯總》《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》《實時音視頻聊天中超低延遲架構的思考與技術實踐》《理解實時音視頻聊天中的延時問題一篇就夠》《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》《寫給小白的實時音視頻技術入門提綱》《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》《騰訊技術分享：微信小程序音視頻技術背後的故事》《微信多媒體團隊梁俊斌訪談：聊一聊我所瞭解的音視頻技術》《新浪微博技術分享：微博短視頻服務的優化實踐之路》《實時音頻的混音在視頻直播應用中的技術原理和實踐總結》《以網遊服務端的網路接入層設計為例，理解實時通信的技術挑戰》
（本文同步發佈於：http://www.52im.net/thread-1915-1-1.html）
推薦閱讀：
