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