IM App 是我做過 App 類型里復雜度最高的一類，里面可供深究探討的技術難點非常之多。這篇文章和大家聊下從移動端客戶端的角度所關注的IM消息可靠性和送達機制（因為我個人對移動客戶端的經驗積累的比較豐富嘛）。
學習交流：
- 即時通訊開發交流群：320837163[推薦]- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 即時通訊開發交流群：320837163[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-1470-1-1.html）
作者網名：Peak，畢業于浙江大學，現為Facebook iOS 工程師。
作者的github：https://github.com/music4kid
作者的博客：http://mrpeak.cn/About/
IM開發干貨系列文章或許也值得您讀一讀，總目錄如下：
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》《如何保證IM實時消息的“時序性”與“一致性”？》《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》《IM群聊消息如此復雜，如何保證不丟不重？》《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》《移動端IM登錄時拉取數據如何作到省流量？》《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》《淺談移動端IM的多點登陸和消息漫游原理》《IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登陸接口的原理》《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》
《移動端IM登錄時拉取數據如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《淺談移動端IM的多點登陸和消息漫游原理》
《IM開發基礎知識補課(一)：正確理解前置HTTP SSO單點登陸接口的原理》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
如果您是IM開發初學者，強烈建議首先閱讀《新手入門一篇就夠：從零開發移動端IM》。
如何確保 IM 不丟消息是個相對復雜的話題，從客戶端發送數據到服務器，再從服務器抵達目標客戶端，最終在 UI 成功展示，其間涉及的環節很多，這里只取其中一環「接收端如何確保消息不丟失」來探討，粗略聊下我接觸過的兩種設計思路。
說到可靠抵達，第一反應會聯想到 TCP 的 reliability。數據可靠抵達是個通用性的問題，無論是網絡二進制流數據，還是上層的業務數據，都有可靠性保障問題，TCP 作為網絡基礎設施協議，其可靠性設計的可靠性是毋庸置疑的，我們就從 TCP 的可靠性說起。
在 TCP 這一層，所有 Sender 發送的數據，每一個 byte 都有標號（Sequence Number），每個 byte 在抵達接收端之后都會被接收端返回一個確認信息（Ack Number）， 二者關系為 Ack = Seq + 1。簡單來說，如果 Sender 發送一個 Seq = 1，長度為 100 bytes 的包，那么 receiver 會返回一個 Ack = 101 的包，如果 Sender 收到了這個Ack 包，說明數據確實被 Receiver 收到了，否則 Sender 會采取某種策略重發上面的包。
第一個問題是：現在的 IM App 幾乎都是走 TCP 通道，既然 TCP 本身是具備可靠性的，為什么還會出現消息接收端（Receiver）丟失消息的情況，看下圖一目了然：
一句話總結上圖的含義：網絡層的可靠性不等同于業務層的可靠性。
數據可靠抵達網絡層之后，還需要一層層往上移交處理，可能的處理有：安全性校驗，binary 解析，model 創建，寫 db，存入 cache，UI 展示，以及一些 edge cases（斷網，用戶 logout，disk full，OOM，crash，關機。。） 等等，項目的 feature 越多，網絡層往上的處理出錯的可能性就越大。
舉個最簡單的場景為例子：消息可靠抵達網絡層之后，寫 db 之前 App crash（不稀奇，是 App 都會 crash），雖然數據在網絡層可靠抵達了，但沒存進 db，下次用戶打開 App 消息自然就丟失了，如果不在業務層再增加可靠性保障，網絡層面不會重發，那么意味著這條消息對于 Receiver 永遠丟失了。
有關TCP協議的更多技術文章，請參考以下鏈接：
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》《TCP/IP詳解 - 第18章·TCP連接的建立與終止》《TCP/IP詳解 - 第21章·TCP的超時與重傳》《通俗易懂-深入理解TCP協議（上）：理論基礎》《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》《理論經典：TCP協議的3次握手與4次揮手過程詳解》《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》>> 更多同類文章 ……
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
>> 更多同類文章 ……
業務層保障可以采取以下兩種方案，請繼續閱讀下一節。
這個方案可以簡單理解為，將 TCP 的 Ack 流程再走一遍，在應用層也構建一個 Ack 消息，在應用層可靠性得到確認（一般以存入 db 為準，更準確說是事務提交成功的回調函數）之后再發送這個 Ack 消息，Server 收到應用層 Ack 消息之后才認為 Receiver 已收到，否則也采取某種策略重發消息。
具體到 IM App 當中，接收端接受到 Server 的 Message，將 Message 存入 db，在確認回調里發送 Ack Receive 消息，Server 收到 Ack Receive 即認為消息已經可靠抵達，否則會在某個時機重新推送（比如客戶端重連服務器時候 Pull，比如有新消息時 Server Push）。
這個方案和上面不同，但也是在應用層操作。我們個每個 Message 分配一個 Seq ID，這個 Seq ID 對于單個用戶的接受消息隊列來說是連續的，如果 Message A 和 Message B 是相鄰的，那么 MsgBSeqID = MsgASeqID + 1。每次存入 db 的時候更新 db 里的 LastReceivedSeqID，LastReceivedSeqID 即為上一條寫入數據庫消息的 Seq ID。
這么做的好處是，每次從網絡層收到消息時，從 db 里取出 LastReceivedSeqID，如果 LastReceivedSeqID = 新消息 Seq ID - 1，那么說明應用層消息時連續的沒有發生丟失。還可以對收到的批量消息做預檢測，檢查消息隊列里的 Seq ID 是否為聯系的，只要存在任何一種不連續的 Seq ID 情況，就說明發送了丟失，此時接收端可以用 LastReceivedSeqID 從 Server 重新獲取準確的接受消息隊列。
這么做的好處是避免了每次都需要發送一條 Ack 消息，壞處是應用層邏輯復雜之后，一旦出現 Seq ID 不連續的情況，會過度依賴于 refetch，難以分析問題出現的原因，refetch 一旦過于頻繁，其流量損耗極有可能大于 Ack 消息的數據量。
消息的可靠抵達可以抽象為更一般意義上的可靠性問題，工程上總會碰到需要解決各種形式可靠性問題的場景，以經典計算機理論或者實踐為基礎來分析應用層的工程問題，可以舉一反三，藥到病除。
在工程上實踐可靠性，需要線了解工程的每一個環節以及數據如何在各個環節流動，接下來才是分析每一個環節數據出錯的可能性。檢驗可靠性的標準時「入袋為安」，存入 db 或者以其他方式持久化到 disk 當中，這樣才能保證客戶端每次都能正確讀取到消息。
另外，可靠性可以理解為兩方面：
一是數據可靠抵達（沒有任何中間數據被丟失）；二是正確抵達（沒有亂序或者數據更改）。
一是數據可靠抵達（沒有任何中間數據被丟失）；
二是正確抵達（沒有亂序或者數據更改）。
其實理論上 TCP 也不是 100% 可靠（數據有可能在傳輸時改變而無法被檢測到），而是 100% 工程上可靠（數據改變而不被檢測到時個極小概率的事件），這是另外一個有意思的話題。
[1] 有關IM/推送的通信格式、協議的選擇：《簡述傳輸層協議TCP和UDP的區別》《為什么QQ用的是UDP協議而不是TCP協議？》《移動端即時通訊協議選擇：UDP還是TCP？》《如何選擇即時通訊應用的數據傳輸格式》《強列建議將Protobuf作為你的即時通訊應用數據傳輸格式》《全方位評測：Protobuf性能到底有沒有比JSON快5倍？》《移動端IM開發需要面對的技術問題（含通信協議選擇）》《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》《理論聯系實際：一套典型的IM通信協議設計詳解》《58到家實時消息系統的協議設計等技術實踐分享》《詳解如何在NodeJS中使用Google的Protobuf》《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》>> 更多同類文章 ……[2] 有關IM/推送的心跳保活處理：《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》《Android進程保活詳解：一篇文章解決你的所有疑問》《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》《深入的聊聊Android消息推送這件小事》《為何基于TCP協議的移動端IM仍然需要心跳保活機制？》《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》《微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)》《移動端IM實踐：實現Android版微信的智能心跳機制》《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》>> 更多同類文章 ……[3] 有關WEB端即時通訊開發：《新手入門貼：史上最全Web端即時通訊技術原理詳解》《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》《SSE技術詳解：一種全新的HTML5服務器推送事件技術》《Comet技術詳解：基于HTTP長連接的Web端實時通信技術》《新手快速入門：WebSocket簡明教程》《WebSocket詳解（一）：初步認識WebSocket技術》《WebSocket詳解（二）：技術原理、代碼演示和應用案例》《WebSocket詳解（三）：深入WebSocket通信協議細節》《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關系(上篇)》《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關系(下篇)》《WebSocket詳解（六）：刨根問底WebSocket與Socket的關系》《socket.io實現消息推送的一點實踐及思路》《LinkedIn的Web端即時通訊實踐：實現單機幾十萬條長連接》《Web端即時通訊技術的發展與WebSocket、Socket.io的技術實踐》《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》《開源框架Pomelo實踐：搭建Web端高性能分布式IM聊天服務器》《使用WebSocket和SSE技術實現Web端消息推送》《詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket》《MobileIMSDK-Web的網絡層框架為何使用的是Socket.io而不是Netty？》《理論聯系實際：從零理解WebSocket的通信原理、協議格式、安全性》>> 更多同類文章 ……[4] 有關IM架構設計：《淺談IM系統的架構設計》《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》《一套原創分布式即時通訊(IM)系統理論架構方案》《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》《蘑菇街即時通訊/IM服務器開發之架構選擇》《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》《微信技術總監談架構：微信之道——大道至簡(演講全文)》《如何解讀《微信技術總監談架構：微信之道——大道至簡》》《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》《17年的實踐：騰訊海量產品的技術方法論》《移動端IM中大規模群消息的推送如何保證效率、實時性？》《現代IM系統中聊天消息的同步和存儲方案探討》《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》>> 更多同類文章 ……[5] 有關IM安全的文章：《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》《理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）》《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》《移動端安全通信的利器——端到端加密（E2EE）技術詳解》《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》>> 更多同類文章 ……[6] 開源實時音視頻技術WebRTC的文章：《開源實時音視頻技術WebRTC的現狀》《簡述開源實時音視頻技術WebRTC的優缺點》《訪談WebRTC標準之父：WebRTC的過去、現在和未來》《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》《WebRTC實時音視頻技術的整體架構介紹》《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》《WebRTC實時音視頻技術基礎：基本架構和協議棧》《淺談開發實時視頻直播平臺的技術要點》《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》《基于開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》《實時通信RTC技術棧之：視頻編解碼》《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》>> 更多同類文章 ……[7] 實時音視頻開發的其它精華資料：《即時通訊音視頻開發（一）：視頻編解碼之理論概述》《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》>> 更多同類文章 ……[8] IM開發綜合文章：《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》《IM開發基礎知識補課：正確理解前置HTTP SSO單點登陸接口的原理》《移動端IM中大規模群消息的推送如何保證效率、實時性？》《移動端IM開發需要面對的技術問題》《開發IM是自己設計協議用字節流好還是字符流好？》《請問有人知道語音留言聊天的主流實現方式嗎？》《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》《如何保證IM實時消息的“時序性”與“一致性”？》《一個低成本確保IM消息時序的方法探討》《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》《IM群聊消息如此復雜，如何保證不丟不重？》《談談移動端 IM 開發中登錄請求的優化》《移動端IM登錄時拉取數據如何作到省流量？》《淺談移動端IM的多點登陸和消息漫游原理》《完全自已開發的IM該如何設計“失敗重試”機制？》《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》《微信對網絡影響的技術試驗及分析（論文全文）》《即時通訊系統的原理、技術和應用（技術論文）》《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》《基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》>> 更多同類文章 …… [9] 開源移動端IM技術框架資料：《開源移動端IM技術框架MobileIMSDK：快速入門》《開源移動端IM技術框架MobileIMSDK：常見問題解答》《開源移動端IM技術框架MobileIMSDK：壓力測試報告》>> 更多同類文章 ……
[1] 有關IM/推送的通信格式、協議的選擇：
《簡述傳輸層協議TCP和UDP的區別》
《為什么QQ用的是UDP協議而不是TCP協議？》
《移動端即時通訊協議選擇：UDP還是TCP？》
《如何選擇即時通訊應用的數據傳輸格式》
《強列建議將Protobuf作為你的即時通訊應用數據傳輸格式》
《全方位評測：Protobuf性能到底有沒有比JSON快5倍？》
《移動端IM開發需要面對的技術問題（含通信協議選擇）》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《理論聯系實際：一套典型的IM通信協議設計詳解》
《58到家實時消息系統的協議設計等技術實踐分享》
《詳解如何在NodeJS中使用Google的Protobuf》
《技術掃盲：新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》
[2] 有關IM/推送的心跳保活處理：
《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》
《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》
《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》
《Android進程保活詳解：一篇文章解決你的所有疑問》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《深入的聊聊Android消息推送這件小事》
《為何基于TCP協議的移動端IM仍然需要心跳保活機制？》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
[3] 有關WEB端即時通訊開發：
《新手入門貼：史上最全Web端即時通訊技術原理詳解》
《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》
《SSE技術詳解：一種全新的HTML5服務器推送事件技術》
《Comet技術詳解：基于HTTP長連接的Web端實時通信技術》
《新手快速入門：WebSocket簡明教程》
《WebSocket詳解（一）：初步認識WebSocket技術》
《WebSocket詳解（二）：技術原理、代碼演示和應用案例》
《WebSocket詳解（三）：深入WebSocket通信協議細節》
《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關系(上篇)》
《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關系(下篇)》
《WebSocket詳解（六）：刨根問底WebSocket與Socket的關系》
《socket.io實現消息推送的一點實踐及思路》
《LinkedIn的Web端即時通訊實踐：實現單機幾十萬條長連接》
《Web端即時通訊技術的發展與WebSocket、Socket.io的技術實踐》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《開源框架Pomelo實踐：搭建Web端高性能分布式IM聊天服務器》
《使用WebSocket和SSE技術實現Web端消息推送》
《詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket》
《MobileIMSDK-Web的網絡層框架為何使用的是Socket.io而不是Netty？》
《理論聯系實際：從零理解WebSocket的通信原理、協議格式、安全性》
[4] 有關IM架構設計：
《淺談IM系統的架構設計》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
[5] 有關IM安全的文章：
《即時通訊安全篇（一）：正確地理解和使用Android端加密算法》
《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》
《即時通訊安全篇（三）：常用加解密算法與通訊安全講解》
《即時通訊安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《即時通訊安全篇（五）：對稱加密技術在Android平臺上的應用實踐》
《即時通訊安全篇（六）：非對稱加密技術的原理與應用實踐》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯系實際：一套典型的IM通信協議設計詳解（含安全層設計）》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端安全通信的利器——端到端加密（E2EE）技術詳解》
《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》
[6] 開源實時音視頻技術WebRTC的文章：
《開源實時音視頻技術WebRTC的現狀》
《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議棧》
《淺談開發實時視頻直播平臺的技術要點》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基于開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《實時通信RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
[7] 實時音視頻開發的其它精華資料：
《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
[8] IM開發綜合文章：
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《IM開發基礎知識補課：正確理解前置HTTP SSO單點登陸接口的原理》
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現方式嗎？》
《一個低成本確保IM消息時序的方法探討》
《談談移動端 IM 開發中登錄請求的優化》
《完全自已開發的IM該如何設計“失敗重試”機制？》
《微信對網絡影響的技術試驗及分析（論文全文）》
《即時通訊系統的原理、技術和應用（技術論文）》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《基于社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》
[9] 開源移動端IM技術框架資料：
《開源移動端IM技術框架MobileIMSDK：快速入門》
《開源移動端IM技術框架MobileIMSDK：常見問題解答》
《開源移動端IM技術框架MobileIMSDK：壓力測試報告》
作者：Jack Jiang (點擊作者姓名進入Github) 出處：http://www.52im.net/space-uid-1.html 交流：歡迎加入即時通訊開發交流群 215891622 討論：http://www.52im.net/ Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者，可前往下載交流。 本博文 歡迎轉載，轉載請注明出處（也可前往 我的52im.net 找到我）。
Powered by: BlogJava Copyright © Jack Jiang