本文參考并引用了部分騰訊游戲?qū)W院的相關技術文章內(nèi)容，感謝原作者的分享。

1、前言

以現(xiàn)在主流的即時通訊應用形態(tài)來講，一個完整的即時通訊IM應用其實是即時通信（英文簡寫：IM=Instant messaging）和實時通信（英文簡寫：RTC=Real-time communication）2種技術組合在一起的一整套網(wǎng)絡通信系統(tǒng)。之所以以IM這個簡寫代稱整個即時通訊軟件，其實是歷史原因了（因為早期的諸如ICQ這樣的即時通訊工具，也就是文字聊天，并沒有加入實時音視頻這樣的實時通信技術），對這個話題有興趣的可以到網(wǎng)上查一查IM的發(fā)展歷史。

以微信、QQ這樣的完整即時通訊應用來說，回歸到工具的本質(zhì)，它主要包含了兩種應用和技術：

1）廣義的文字聊天：也就是我最常理解的各種聊天消息的傳遞，這部分的技術實現(xiàn)就是眾所周之的IM通信（即Instant messaging）；

2）實時音視頻聊天：包括語音電話、視頻聊天，這部分的技術實現(xiàn)，從網(wǎng)絡通信的角度講，就是實時通信（即Real-time communication）。

我們回憶一下：早幾年前市面上主流的移動端IM——比如微信、QQ、以及現(xiàn)在滿屏廣告的網(wǎng)易易信、半死不活的小米米聊、已經(jīng)入土的阿里來往、打擦邊球的陌陌等，基本都沒有或者很晚才加入實時音視頻聊天功能（我們拋開技術因素之外的原因不議），原因不是不想做，而是實時音視頻這種實時通信技術確實是有相當?shù)拈T檻，并不容易做。

所以：對于即時通訊網(wǎng)社區(qū)內(nèi)眾多的IM應用開發(fā)者來說，實時通信技術如此重要，深入研究和理解實時通信技術的原理、技術實踐，對于自已IM產(chǎn)品的開發(fā)來說，都是大有裨益的。

本文將嘗試從開發(fā)者角度：梳理開發(fā)網(wǎng)游服務端的網(wǎng)絡接入層的過程中面臨的各種技術挑戰(zhàn)，并針對性地提供相應的實時通信網(wǎng)絡接入層解決思路，希望對于即時通訊應用的開發(fā)者來說，可以從中得到些許啟發(fā)。

學習交流：

- 即時通訊開發(fā)交流3群：185926912 [推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-1915-1-1.html）

2、相關文章

《計算機網(wǎng)絡通訊協(xié)議關系圖（中文珍藏版）》

《高性能網(wǎng)絡編程(一)：單臺服務器并發(fā)TCP連接數(shù)到底可以有多少》

《高性能網(wǎng)絡編程(二)：上一個10年，著名的C10K并發(fā)連接問題》

《高性能網(wǎng)絡編程(三)：下一個10年，是時候考慮C10M并發(fā)問題了》

《高性能網(wǎng)絡編程(四)：從C10K到C10M高性能網(wǎng)絡應用的理論探索》

《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》

《網(wǎng)絡編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》

《技術掃盲：新一代基于UDP的低延時網(wǎng)絡傳輸層協(xié)議——QUIC詳解》

《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》

《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》

《七牛云技術分享：使用QUIC協(xié)議實現(xiàn)實時視頻直播0卡頓！》

《理解實時音視頻聊天中的延時問題一篇就夠》

《寫給小白的實時音視頻技術入門提綱》

3、主流網(wǎng)游的網(wǎng)絡通信架構原理

維基百科關于網(wǎng)絡游戲的定義：

即通過計算機網(wǎng)絡，將專用服務器和用戶的客戶端設備(手機、PC、游戲主機等)相連，讓多名玩家同時聯(lián)機進行游戲的娛樂形式。

由此可知網(wǎng)絡游戲涉及三個角色：

1）客戶端；

2）網(wǎng)絡；

3）服務器。

從網(wǎng)絡架構上來講，網(wǎng)游可分為：

1）C/S 架構：這個最好理解；

2）P2P架構：特指客戶端間直連通信；

3）C/M架構：在實際開發(fā)中這是一種C/S和P2P架構的混合體。

 典型的網(wǎng)絡架構如下圖所示：

P2P架構不在本文討論范圍。

C/M架構和C/S架構相似，跟經(jīng)典的LAMP網(wǎng)站架構類似，一般C/S架構的游戲后臺也可劃分為如下三層：

1）網(wǎng)絡接入層；

2）游戲邏輯層；

3） 數(shù)據(jù)存儲層。

一般C/S架構的游戲后臺分層，如下圖所示：

網(wǎng)絡接入、游戲邏輯、數(shù)據(jù)存儲層各自所面臨的問題域及對應技術棧都大為不同，做此劃分不僅有助于模塊解耦、技術分工、組件復用，也可方便服務的運維部署。本文要討論的就是這個網(wǎng)絡接入層。

4、題外話：該如何理解C/M架構？

可能有人對上節(jié)中的C/M架構有疑問，在網(wǎng)游中這個架構到底是怎么用的？

其實，網(wǎng)絡游戲中是通過同步機制來保證各個客戶端游戲世界的一致性。

主流的網(wǎng)游數(shù)據(jù)同步機制有兩種：

1）狀態(tài)同步：即由客戶端負責將玩家的操作發(fā)往中心節(jié)點 (服務器或master客戶端)，由中心節(jié)點來負責游戲邏輯計算并將計算結(jié)果廣播給客戶端，再由客戶端負責渲染游戲結(jié)果

2）幀同步：幀同步的理論基礎是游戲邏輯由操作指令驅(qū)動，只要操作序列一致，那么游戲結(jié)果就應該一致。

也就是說，不管采用哪種數(shù)據(jù)同步機制，其實都是應用的C/M架構（即Client/Master架構）。

5、網(wǎng)絡接入層的作用

網(wǎng)絡接入層的主要任務是：

1）建立客戶端和后臺服務以及客戶端之間的信道，；

2）接收來自客戶端大量并發(fā)請求。

考核該層的主要性能指標是：

1）高吞吐；

2）低延遲。

因而網(wǎng)絡接入層開發(fā)考驗的是開發(fā)者高性能網(wǎng)絡編程的功底，即解決C10K甚至C10M的能力。

題外話：有關高性能網(wǎng)絡編程的C10K、C10M話題，請詳細閱讀以下文章

《高性能網(wǎng)絡編程(一)：單臺服務器并發(fā)TCP連接數(shù)到底可以有多少》

《高性能網(wǎng)絡編程(二)：上一個10年，著名的C10K并發(fā)連接問題》

《高性能網(wǎng)絡編程(三)：下一個10年，是時候考慮C10M并發(fā)問題了》

《高性能網(wǎng)絡編程(四)：從C10K到C10M高性能網(wǎng)絡應用的理論探索》

6、網(wǎng)絡接入層的通信協(xié)議選擇

根據(jù)OSI的七層網(wǎng)絡參考模型，我們可將網(wǎng)游網(wǎng)絡也做如下7層劃分：

其中4層以下都由操作系統(tǒng)來負責，開發(fā)者無需為此操心，在實際的開發(fā)過程中開發(fā)者首要面臨的問題便是傳輸層是采用TCP還是UDP，下表簡要對比了兩者的優(yōu)劣。 綜合兩者優(yōu)劣，簡單來說除非對延遲有極致要求(例如FPS、MOBA類游戲)需采用UDP外，TCP可應對大部分游戲。

在實際游戲開發(fā)中不管是采用TCP還是UDP方式，都較少利用通過Socket編程方式直接進行，一來因為開發(fā)工作量大，質(zhì)量性能難以保證；二來平臺兼容性不好(比如H5并沒有提供socket編程能力)，而是基于更上層的通訊協(xié)議比如基于TCP的HTTP、Websocket協(xié)議，GRPC，以及基于UDP實現(xiàn)的QUIC，WebRTC協(xié)議等。

TCP、UDP協(xié)議的簡要對比：

有關TCP、UDP協(xié)議的詳細對比文章，您可簡讀一下資料：

《網(wǎng)絡編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》

《簡述傳輸層協(xié)議TCP和UDP的區(qū)別》

《為什么QQ用的是UDP協(xié)議而不是TCP協(xié)議？》

《移動端即時通訊協(xié)議選擇：UDP還是TCP？》

值得注意的是基于安全性考慮，瀏覽器標準未提供UDP收發(fā)能力，QUIC協(xié)議也只在chrome得到了支持，WebRTC也還不是瀏覽器事實標準且協(xié)議初始目的是用于實現(xiàn)點對點的音視頻通信，協(xié)議內(nèi)容過于龐雜不容易提煉應用于游戲開發(fā)中，因而現(xiàn)階段H5游戲還只能采用HTTP或Websocket方式通訊。

知識點掃盲：

1）關于QUIC協(xié)議：《技術掃盲：新一代基于UDP的低延時網(wǎng)絡傳輸層協(xié)議——QUIC詳解》；

2）關于WebRTC：《開源實時音視頻技術WebRTC的現(xiàn)狀》、《簡述開源實時音視頻技術WebRTC的優(yōu)缺點》、《訪談WebRTC標準之父：WebRTC的過去、現(xiàn)在和未來》；

3）關于Websocket：《新手入門貼：史上最全Web端即時通訊技術原理詳解》、《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》、《新手快速入門：WebSocket簡明教程》、《WebSocket詳解（一）：初步認識WebSocket技術》。

另外 ，通訊協(xié)議確定后，隨后要考慮的便是游戲?qū)ο蟮男蛄谢蛄谢饕谢谖谋尽⒒诙M制兩種，其優(yōu)劣如下表所示。在開發(fā)過程中一般會先采用文本序列化方式，便于前后端開發(fā)聯(lián)調(diào)，在游戲正式上線前切換至二進制序列化方式以減少傳輸流量、提升編解碼效率。

游戲?qū)ο蟮闹饕蛄谢绞剑?/span>

關于Protobuf的詳細資料，請見：

《Protobuf通信協(xié)議詳解：代碼演示、詳細原理介紹等》

《強列建議將Protobuf作為你的即時通訊應用數(shù)據(jù)傳輸格式》

《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數(shù)據(jù)傳輸更省更快(原理篇)》

《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數(shù)據(jù)傳輸更省更快(實戰(zhàn)篇)》

至于數(shù)據(jù)安全性問題，為了保護敏感數(shù)據(jù)安全開發(fā)者可以選擇安全的https或WSS通訊協(xié)議，而對于直接基于TCP協(xié)議通訊，可采用先用RSA協(xié)商加密秘鑰，然后使用對稱加密方式將數(shù)據(jù)加密后發(fā)送。

通過以上分析，對于游戲協(xié)議類型的選擇我們給出有以下準則：

1）弱聯(lián)網(wǎng)類游戲：諸如休閑、卡牌類游戲可直接HTTP協(xié)議，對安全性有要求的話就使用HTTPS；

2）實時性，交互性要求較高：這類游戲一般需要保持長連接，優(yōu)先選擇標準的ws協(xié)議（同時使用二進制序列化方式，如Protobuf），如考慮安全性可使用wss協(xié)議。而對于提供socket接口的native平臺也可使用TCP協(xié)議，同時對數(shù)據(jù)做對稱加密增強安全性；

3）實時性要求極高：不僅需要和服務器保持長連接，且延遲和網(wǎng)絡抖動都要求極高（如FPS，賽車類游戲），可使用基于UDP的實現(xiàn)流傳輸協(xié)議如QUIC，KCP等。

7、網(wǎng)絡接入層的并發(fā)模型

為了處理來自客戶端的并發(fā)請求，服務端有4種常見的并發(fā)模型。

7.1）進程：

進程是最早采用的并發(fā)模型，進程作為操作資源分配、調(diào)度的單位，擁有獨立的運行空間。進程并發(fā)模型中每個請求由獨立的進程來處理，進程一次只能處理一個請求，該模型最大的優(yōu)點就是簡單。如果處理請求的進程由于系統(tǒng)調(diào)用而阻塞或進程的時間片用完，搶占式的進程調(diào)度器就會暫停舊進程執(zhí)行，調(diào)度執(zhí)行新的進程，這個過程涉及大開銷的上下文切換，進程并發(fā)模型的缺點是比較低效。最典型的采用進程模型的服務有Apache。

7.2）線程：

線程并發(fā)模型是進程模型的改進，線程從屬于進程，是系統(tǒng)更小粒度的執(zhí)行調(diào)度單元。不同請求可由進程內(nèi)多個并發(fā)執(zhí)行的線程來處理，這些線程由操作系統(tǒng)內(nèi)核自動調(diào)度。線程相對進程的主要優(yōu)勢在于，調(diào)度上下文切換開銷更小，但由于多個線程共享地址空間，需要額外的線程間互斥、同步機制來保證程序性正確性。典型的采用線程模型的服務有Tomcat。

7.3）IO多路復用：

利用操作系統(tǒng)提供的epoll等IO多路復用機制，能同時監(jiān)控多個連接上讀、寫事件， IO多路復用也稱事件驅(qū)動模型，網(wǎng)絡程序執(zhí)行邏輯可抽象為事件驅(qū)動的狀態(tài)機。 IO多路復用避免了讀寫阻塞，減少了上下文切換，提升了CPU利用率和系統(tǒng)吞吐率。但IO多路復用它將原本“同步”、線性的處理邏輯變成事件驅(qū)動的狀態(tài)機，處理邏輯分散于大量的事件回調(diào)函數(shù)。這種異步、非線性的模型，極大地增加了編程難度，如nodeJs的常見的回調(diào)地獄問題。典型的采用IO復用模型的服務有Nginx、Netty。

7.4）協(xié)程：

協(xié)程也稱為輕量級線程，是一種協(xié)同的、非搶占式的多任務并發(fā)模型。 協(xié)程運行在用戶空間，當遇到阻塞或特定入口時，通過顯式調(diào)用切換方法主動讓出CPU，由任務調(diào)度器選取另一個協(xié)程執(zhí)行。

協(xié)程切換只是簡單地改變執(zhí)行函數(shù)棧，不涉及內(nèi)核態(tài)與用戶態(tài)轉(zhuǎn)化，也涉及上下文切換，開銷遠小于進程/線程切換。協(xié)程的概念雖早已提出，隨著近些年年越來越多的語言（go、 Haskell）內(nèi)置對協(xié)程支持才被開發(fā)者所熟知，協(xié)程極大的優(yōu)化了開發(fā)者編程體驗，在同步、順序編程風格能快速實現(xiàn)程序邏輯，還擁有IO多路復用異步編程的性能。典型的采用協(xié)程模型的服務有openresty(Lua), gevent(Python), golang。

7.5）小結(jié)：

以上總結(jié)了目前4種常用的并發(fā)模型，它們在工作原理、運行效率、編程難度等方面有顯著區(qū)別，各自有適用場景，在實際使用時應該根據(jù)需求仔細評估。在實際開發(fā)過程中如果沒有可復用的現(xiàn)成網(wǎng)絡組件或歷史包袱我們建議使用協(xié)程并發(fā)模式開發(fā)網(wǎng)絡接入層服務。

附錄：更多精華文章，供進一步學習

[1] 網(wǎng)絡編程基礎資料：

《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報協(xié)議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》

《TCP/IP詳解 - 第18章·TCP連接的建立與終止》

《TCP/IP詳解 - 第21章·TCP的超時與重傳》

《技術往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎》

《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動窗口、擁塞處理》

《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》

《理論聯(lián)系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計算機網(wǎng)絡通訊協(xié)議關系圖（中文珍藏版）》

《UDP中一個包的大小最大能多大？》

《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》

《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》

《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》

《通俗易懂：快速理解P2P技術中的NAT穿透原理》

《不為人知的網(wǎng)絡編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》

《不為人知的網(wǎng)絡編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》

《不為人知的網(wǎng)絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡編程(四)：深入研究分析TCP的異常關閉》

《不為人知的網(wǎng)絡編程(五)：UDP的連接性和負載均衡》

《不為人知的網(wǎng)絡編程(六)：深入地理解UDP協(xié)議并用好它》

《不為人知的網(wǎng)絡編程(七)：如何讓不可靠的UDP變的可靠？》

《網(wǎng)絡編程懶人入門(一)：快速理解網(wǎng)絡通信協(xié)議（上篇）》

《網(wǎng)絡編程懶人入門(二)：快速理解網(wǎng)絡通信協(xié)議（下篇）》

《網(wǎng)絡編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》

《網(wǎng)絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》

《網(wǎng)絡編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》

《網(wǎng)絡編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術實踐分享》

《現(xiàn)代移動端網(wǎng)絡短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應、安全保障》

《聊聊iOS中網(wǎng)絡編程長連接的那些事》

《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡的“弱”和“慢”》

《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡優(yōu)化方法總結(jié)》

《IPv6技術詳解：基本概念、應用現(xiàn)狀、技術實踐（上篇）》

《IPv6技術詳解：基本概念、應用現(xiàn)狀、技術實踐（下篇）》

《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設計思路》

《腦殘式網(wǎng)絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》

《腦殘式網(wǎng)絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》

《腦殘式網(wǎng)絡編程入門(三)：HTTP協(xié)議必知必會的一些知識》

《腦殘式網(wǎng)絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》

《以網(wǎng)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術挑戰(zhàn)》

>> 更多同類文章 ……

[2] 有關網(wǎng)絡通信的格式、協(xié)議的選擇：

《Protobuf通信協(xié)議詳解：代碼演示、詳細原理介紹等》

《一個基于Protocol Buffer的Java代碼演示》

《全方位評測：Protobuf性能到底有沒有比JSON快5倍？》

《移動端IM開發(fā)需要面對的技術問題（含通信協(xié)議選擇）》

《簡述移動端IM開發(fā)的那些坑：架構設計、通信協(xié)議和客戶端》

《理論聯(lián)系實際：一套典型的IM通信協(xié)議設計詳解》

《58到家實時消息系統(tǒng)的協(xié)議設計等技術實踐分享》

《詳解如何在NodeJS中使用Google的Protobuf》

>> 更多同類文章 ……

[3] 實時音視頻開發(fā)的其它精華資料：

《即時通訊音視頻開發(fā)（一）：視頻編解碼之理論概述》

《即時通訊音視頻開發(fā)（二）：視頻編解碼之數(shù)字視頻介紹》

《即時通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎》

《即時通訊音視頻開發(fā)（四）：視頻編解碼之預測技術介紹》

《即時通訊音視頻開發(fā)（五）：認識主流視頻編碼技術H.264》

《即時通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發(fā)（七）：音頻基礎及編碼原理入門》

《即時通訊音視頻開發(fā)（八）：常見的實時語音通訊編碼標準》

《即時通訊音視頻開發(fā)（九）：實時語音通訊的回音及回音消除概述》

《即時通訊音視頻開發(fā)（十）：實時語音通訊的回音消除技術詳解》

《即時通訊音視頻開發(fā)（十一）：實時語音通訊丟包補償技術詳解》

《即時通訊音視頻開發(fā)（十二）：多人實時音視頻聊天架構探討》

《即時通訊音視頻開發(fā)（十三）：實時視頻編碼H.264的特點與優(yōu)勢》

《即時通訊音視頻開發(fā)（十四）：實時音視頻數(shù)據(jù)傳輸協(xié)議介紹》

《即時通訊音視頻開發(fā)（十五）：聊聊P2P與實時音視頻的應用情況》

《即時通訊音視頻開發(fā)（十六）：移動端實時音視頻開發(fā)的幾個建議》

《即時通訊音視頻開發(fā)（十七）：視頻編碼H.264、VP8的前世今生》

《IM實時音視頻聊天時的回聲消除技術詳解》

《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》

《如何優(yōu)化傳輸機制來實現(xiàn)實時音視頻的超低延遲？》

《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》

《Android直播入門實踐：動手搭建一套簡單的直播系統(tǒng)》

《網(wǎng)易云信實時視頻直播在TCP數(shù)據(jù)傳輸層的一些優(yōu)化思路》

《實時音視頻聊天技術分享：面向不可靠網(wǎng)絡的抗丟包編解碼器》

《P2P技術如何將實時視頻直播帶寬降低75%？》

《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》

《騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天》

《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》

《近期大熱的實時直播答題系統(tǒng)的實現(xiàn)思路與技術難點分享》

《福利貼：最全實時音視頻開發(fā)要用到的開源工程匯總》

《七牛云技術分享：使用QUIC協(xié)議實現(xiàn)實時視頻直播0卡頓！》

《實時音視頻聊天中超低延遲架構的思考與技術實踐》

《理解實時音視頻聊天中的延時問題一篇就夠》

《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》

《寫給小白的實時音視頻技術入門提綱》

《微信多媒體團隊訪談：音視頻開發(fā)的學習、微信的音視頻技術和挑戰(zhàn)等》

《騰訊技術分享：微信小程序音視頻技術背后的故事》

《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》

《新浪微博技術分享：微博短視頻服務的優(yōu)化實踐之路》

《實時音頻的混音在視頻直播應用中的技術原理和實踐總結(jié)》

《以網(wǎng)游服務端的網(wǎng)絡接入層設計為例，理解實時通信的技術挑戰(zhàn)》

（本文同步發(fā)布于：http://www.52im.net/thread-1915-1-1.html）