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

1、前言

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

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

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

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

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

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

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

學(xué)習(xí)交流：

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

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

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

2、相關(guān)文章

《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《寫給小白的實(shí)時(shí)音視頻技術(shù)入門提綱》

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

維基百科關(guān)于網(wǎng)絡(luò)游戲的定義：

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

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

1）客戶端；

2）網(wǎng)絡(luò)；

3）服務(wù)器。

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

1）C/S 架構(gòu)：這個(gè)最好理解；

2）P2P架構(gòu)：特指客戶端間直連通信；

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

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

P2P架構(gòu)不在本文討論范圍。

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

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

2）游戲邏輯層；

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

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

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

4、題外話：該如何理解C/M架構(gòu)？

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

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

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

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

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

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

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

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

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

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

考核該層的主要性能指標(biāo)是：

1）高吞吐；

2）低延遲。

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

題外話：有關(guān)高性能網(wǎng)絡(luò)編程的C10K、C10M話題，請?jiān)敿?xì)閱讀以下文章

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

知識點(diǎn)掃盲：

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

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

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

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

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

關(guān)于Protobuf的詳細(xì)資料，請見：

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

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

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

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

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

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

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

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

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

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

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

7.1）進(jìn)程：

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

7.2）線程：

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

7.3）IO多路復(fù)用：

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

7.4）協(xié)程：

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

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

7.5）小結(jié)：

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

附錄：更多精華文章，供進(jìn)一步學(xué)習(xí)

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

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

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

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

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

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

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

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

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

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

《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》

《UDP中一個(gè)包的大小最大能多大？》

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

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

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

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

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

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

《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> 更多同類文章 ……

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

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

《一個(gè)基于Protocol Buffer的Java代碼演示》

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

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

《簡述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》

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

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

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

>> 更多同類文章 ……

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《IM實(shí)時(shí)音視頻聊天時(shí)的回聲消除技術(shù)詳解》

《淺談實(shí)時(shí)音視頻直播中直接影響用戶體驗(yàn)的幾項(xiàng)關(guān)鍵技術(shù)指標(biāo)》

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

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

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

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

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

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

《專訪微信視頻技術(shù)負(fù)責(zé)人：微信實(shí)時(shí)視頻聊天技術(shù)的演進(jìn)》

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

《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

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

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

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

《實(shí)時(shí)音視頻聊天中超低延遲架構(gòu)的思考與技術(shù)實(shí)踐》

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

《實(shí)時(shí)視頻直播客戶端技術(shù)盤點(diǎn)：Native、HTML5、WebRTC、微信小程序》

《寫給小白的實(shí)時(shí)音視頻技術(shù)入門提綱》

《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》

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

《微信多媒體團(tuán)隊(duì)梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》

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

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

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

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