1、前言

IM App 是我做過(guò) App 類型里復(fù)雜度最高的一類，里面可供深究探討的技術(shù)難點(diǎn)非常之多。這篇文章和大家聊下從移動(dòng)端客戶端的角度所關(guān)注的IM消息可靠性和送達(dá)機(jī)制（因?yàn)槲覀€(gè)人對(duì)移動(dòng)客戶端的經(jīng)驗(yàn)積累的比較豐富嘛）。

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

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

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

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

2、關(guān)于作者

作者網(wǎng)名：Peak，畢業(yè)于浙江大學(xué)，現(xiàn)為Facebook iOS 工程師。

作者的github：https://github.com/music4kid

作者的博客：http://mrpeak.cn/About/

3、相關(guān)文章

IM開(kāi)發(fā)干貨系列文章或許也值得您讀一讀，總目錄如下：

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》

《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》

《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》

《IM群聊消息如此復(fù)雜，如何保證不丟不重？》

《一種Android端IM智能心跳算法的設(shè)計(jì)與實(shí)現(xiàn)探討（含樣例代碼）》

《移動(dòng)端IM登錄時(shí)拉取數(shù)據(jù)如何作到省流量？》

《通俗易懂：基于集群的移動(dòng)端IM接入層負(fù)載均衡方案分享》

《淺談移動(dòng)端IM的多點(diǎn)登陸和消息漫游原理》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(一)：正確理解前置HTTP SSO單點(diǎn)登陸接口的原理》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》

如果您是IM開(kāi)發(fā)初學(xué)者，強(qiáng)烈建議首先閱讀《新手入門一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》。

4、TCP協(xié)議的可靠性之外還會(huì)出現(xiàn)消息丟失？

如何確保 IM 不丟消息是個(gè)相對(duì)復(fù)雜的話題，從客戶端發(fā)送數(shù)據(jù)到服務(wù)器，再?gòu)姆?wù)器抵達(dá)目標(biāo)客戶端，最終在 UI 成功展示，其間涉及的環(huán)節(jié)很多，這里只取其中一環(huán)「接收端如何確保消息不丟失」來(lái)探討，粗略聊下我接觸過(guò)的兩種設(shè)計(jì)思路。

說(shuō)到可靠抵達(dá)，第一反應(yīng)會(huì)聯(lián)想到 TCP 的 reliability。數(shù)據(jù)可靠抵達(dá)是個(gè)通用性的問(wèn)題，無(wú)論是網(wǎng)絡(luò)二進(jìn)制流數(shù)據(jù)，還是上層的業(yè)務(wù)數(shù)據(jù)，都有可靠性保障問(wèn)題，TCP 作為網(wǎng)絡(luò)基礎(chǔ)設(shè)施協(xié)議，其可靠性設(shè)計(jì)的可靠性是毋庸置疑的，我們就從 TCP 的可靠性說(shuō)起。

在 TCP 這一層，所有 Sender 發(fā)送的數(shù)據(jù)，每一個(gè) byte 都有標(biāo)號(hào)（Sequence Number），每個(gè) byte 在抵達(dá)接收端之后都會(huì)被接收端返回一個(gè)確認(rèn)信息（Ack Number）， 二者關(guān)系為 Ack = Seq + 1。簡(jiǎn)單來(lái)說(shuō)，如果 Sender 發(fā)送一個(gè) Seq = 1，長(zhǎng)度為 100 bytes 的包，那么 receiver 會(huì)返回一個(gè) Ack = 101 的包，如果 Sender 收到了這個(gè)Ack 包，說(shuō)明數(shù)據(jù)確實(shí)被 Receiver 收到了，否則 Sender 會(huì)采取某種策略重發(fā)上面的包。

第一個(gè)問(wèn)題是：現(xiàn)在的 IM App 幾乎都是走 TCP 通道，既然 TCP 本身是具備可靠性的，為什么還會(huì)出現(xiàn)消息接收端（Receiver）丟失消息的情況，看下圖一目了然：

一句話總結(jié)上圖的含義：網(wǎng)絡(luò)層的可靠性不等同于業(yè)務(wù)層的可靠性。

數(shù)據(jù)可靠抵達(dá)網(wǎng)絡(luò)層之后，還需要一層層往上移交處理，可能的處理有：安全性校驗(yàn)，binary 解析，model 創(chuàng)建，寫 db，存入 cache，UI 展示，以及一些 edge cases（斷網(wǎng)，用戶 logout，disk full，OOM，crash，關(guān)機(jī)。。） 等等，項(xiàng)目的 feature 越多，網(wǎng)絡(luò)層往上的處理出錯(cuò)的可能性就越大。

舉個(gè)最簡(jiǎn)單的場(chǎng)景為例子：消息可靠抵達(dá)網(wǎng)絡(luò)層之后，寫 db 之前 App crash（不稀奇，是 App 都會(huì) crash），雖然數(shù)據(jù)在網(wǎng)絡(luò)層可靠抵達(dá)了，但沒(méi)存進(jìn) db，下次用戶打開(kāi) App 消息自然就丟失了，如果不在業(yè)務(wù)層再增加可靠性保障，網(wǎng)絡(luò)層面不會(huì)重發(fā)，那么意味著這條消息對(duì)于 Receiver 永遠(yuǎn)丟失了。

有關(guān)TCP協(xié)議的更多技術(shù)文章，請(qǐng)參考以下鏈接：

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

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

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

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

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

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

《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》

《不為人知的網(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ò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

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

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

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

>> 更多同類文章 ……

業(yè)務(wù)層保障可以采取以下兩種方案，請(qǐng)繼續(xù)閱讀下一節(jié)。

5、客戶端方案1：應(yīng)用層 Ack 消息

這個(gè)方案可以簡(jiǎn)單理解為，將 TCP 的 Ack 流程再走一遍，在應(yīng)用層也構(gòu)建一個(gè) Ack 消息，在應(yīng)用層可靠性得到確認(rèn)（一般以存入 db 為準(zhǔn)，更準(zhǔn)確說(shuō)是事務(wù)提交成功的回調(diào)函數(shù)）之后再發(fā)送這個(gè) Ack 消息，Server 收到應(yīng)用層 Ack 消息之后才認(rèn)為 Receiver 已收到，否則也采取某種策略重發(fā)消息。

具體到 IM App 當(dāng)中，接收端接受到 Server 的 Message，將 Message 存入 db，在確認(rèn)回調(diào)里發(fā)送 Ack Receive 消息，Server 收到 Ack Receive 即認(rèn)為消息已經(jīng)可靠抵達(dá)，否則會(huì)在某個(gè)時(shí)機(jī)重新推送（比如客戶端重連服務(wù)器時(shí)候 Pull，比如有新消息時(shí) Server Push）。

6、客戶端方案2：應(yīng)用層 Seq ID

這個(gè)方案和上面不同，但也是在應(yīng)用層操作。我們個(gè)每個(gè) Message 分配一個(gè) Seq ID，這個(gè) Seq ID 對(duì)于單個(gè)用戶的接受消息隊(duì)列來(lái)說(shuō)是連續(xù)的，如果 Message A 和 Message B 是相鄰的，那么 MsgBSeqID = MsgASeqID + 1。每次存入 db 的時(shí)候更新 db 里的 LastReceivedSeqID，LastReceivedSeqID 即為上一條寫入數(shù)據(jù)庫(kù)消息的 Seq ID。

這么做的好處是，每次從網(wǎng)絡(luò)層收到消息時(shí)，從 db 里取出 LastReceivedSeqID，如果 LastReceivedSeqID = 新消息 Seq ID - 1，那么說(shuō)明應(yīng)用層消息時(shí)連續(xù)的沒(méi)有發(fā)生丟失。還可以對(duì)收到的批量消息做預(yù)檢測(cè)，檢查消息隊(duì)列里的 Seq ID 是否為聯(lián)系的，只要存在任何一種不連續(xù)的 Seq ID 情況，就說(shuō)明發(fā)送了丟失，此時(shí)接收端可以用 LastReceivedSeqID 從 Server 重新獲取準(zhǔn)確的接受消息隊(duì)列。

這么做的好處是避免了每次都需要發(fā)送一條 Ack 消息，壞處是應(yīng)用層邏輯復(fù)雜之后，一旦出現(xiàn) Seq ID 不連續(xù)的情況，會(huì)過(guò)度依賴于 refetch，難以分析問(wèn)題出現(xiàn)的原因，refetch 一旦過(guò)于頻繁，其流量損耗極有可能大于 Ack 消息的數(shù)據(jù)量。

7、本文小結(jié)

消息的可靠抵達(dá)可以抽象為更一般意義上的可靠性問(wèn)題，工程上總會(huì)碰到需要解決各種形式可靠性問(wèn)題的場(chǎng)景，以經(jīng)典計(jì)算機(jī)理論或者實(shí)踐為基礎(chǔ)來(lái)分析應(yīng)用層的工程問(wèn)題，可以舉一反三，藥到病除。

在工程上實(shí)踐可靠性，需要線了解工程的每一個(gè)環(huán)節(jié)以及數(shù)據(jù)如何在各個(gè)環(huán)節(jié)流動(dòng)，接下來(lái)才是分析每一個(gè)環(huán)節(jié)數(shù)據(jù)出錯(cuò)的可能性。檢驗(yàn)可靠性的標(biāo)準(zhǔn)時(shí)「入袋為安」，存入 db 或者以其他方式持久化到 disk 當(dāng)中，這樣才能保證客戶端每次都能正確讀取到消息。

另外，可靠性可以理解為兩方面：

一是數(shù)據(jù)可靠抵達(dá)（沒(méi)有任何中間數(shù)據(jù)被丟失）；

二是正確抵達(dá)（沒(méi)有亂序或者數(shù)據(jù)更改）。

其實(shí)理論上 TCP 也不是 100% 可靠（數(shù)據(jù)有可能在傳輸時(shí)改變而無(wú)法被檢測(cè)到），而是 100% 工程上可靠（數(shù)據(jù)改變而不被檢測(cè)到時(shí)個(gè)極小概率的事件），這是另外一個(gè)有意思的話題。

附錄：更多IM開(kāi)發(fā)技術(shù)文章

[1] 有關(guān)IM/推送的通信格式、協(xié)議的選擇：

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

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

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

《如何選擇即時(shí)通訊應(yīng)用的數(shù)據(jù)傳輸格式》

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

《全方位評(píng)測(cè)：Protobuf性能到底有沒(méi)有比JSON快5倍？》

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

《簡(jiǎn)述移動(dòng)端IM開(kāi)發(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》

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

>> 更多同類文章 ……

[2] 有關(guān)IM/推送的心跳保活處理：

《應(yīng)用保活終極總結(jié)(一)：Android6.0以下的雙進(jìn)程守護(hù)保活實(shí)踐》

《應(yīng)用保活終極總結(jié)(二)：Android6.0及以上的保活實(shí)踐(進(jìn)程防殺篇)》

《應(yīng)用保活終極總結(jié)(三)：Android6.0及以上的保活實(shí)踐(被殺復(fù)活篇)》

《Android進(jìn)程保活詳解：一篇文章解決你的所有疑問(wèn)》

《Android端消息推送總結(jié)：實(shí)現(xiàn)原理、心跳保活、遇到的問(wèn)題等》

《深入的聊聊Android消息推送這件小事》

《為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳保活機(jī)制？》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(進(jìn)程保活篇)》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》

《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》

《移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》

>> 更多同類文章 ……

[3] 有關(guān)WEB端即時(shí)通訊開(kāi)發(fā)：

《新手入門貼：史上最全Web端即時(shí)通訊技術(shù)原理詳解》

《Web端即時(shí)通訊技術(shù)盤點(diǎn)：短輪詢、Comet、Websocket、SSE》

《SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)》

《Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)》

《新手快速入門：WebSocket簡(jiǎn)明教程》

《WebSocket詳解（一）：初步認(rèn)識(shí)WebSocket技術(shù)》

《WebSocket詳解（二）：技術(shù)原理、代碼演示和應(yīng)用案例》

《WebSocket詳解（三）：深入WebSocket通信協(xié)議細(xì)節(jié)》

《WebSocket詳解（四）：刨根問(wèn)底HTTP與WebSocket的關(guān)系(上篇)》

《WebSocket詳解（五）：刨根問(wèn)底HTTP與WebSocket的關(guān)系(下篇)》

《WebSocket詳解（六）：刨根問(wèn)底WebSocket與Socket的關(guān)系》

《socket.io實(shí)現(xiàn)消息推送的一點(diǎn)實(shí)踐及思路》

《LinkedIn的Web端即時(shí)通訊實(shí)踐：實(shí)現(xiàn)單機(jī)幾十萬(wàn)條長(zhǎng)連接》

《Web端即時(shí)通訊技術(shù)的發(fā)展與WebSocket、Socket.io的技術(shù)實(shí)踐》

《Web端即時(shí)通訊安全：跨站點(diǎn)WebSocket劫持漏洞詳解(含示例代碼)》

《開(kāi)源框架Pomelo實(shí)踐：搭建Web端高性能分布式IM聊天服務(wù)器》

《使用WebSocket和SSE技術(shù)實(shí)現(xiàn)Web端消息推送》

《詳解Web端通信方式的演進(jìn)：從Ajax、JSONP 到 SSE、Websocket》

《MobileIMSDK-Web的網(wǎng)絡(luò)層框架為何使用的是Socket.io而不是Netty？》

《理論聯(lián)系實(shí)際：從零理解WebSocket的通信原理、協(xié)議格式、安全性》

>> 更多同類文章 ……

[4] 有關(guān)IM架構(gòu)設(shè)計(jì)：

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

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

《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》

《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》

《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》

《蘑菇街即時(shí)通訊/IM服務(wù)器開(kāi)發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》

《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》

《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》

>> 更多同類文章 ……

[5] 有關(guān)IM安全的文章：

《即時(shí)通訊安全篇（一）：正確地理解和使用Android端加密算法》

《即時(shí)通訊安全篇（二）：探討組合加密算法在IM中的應(yīng)用》

《即時(shí)通訊安全篇（三）：常用加解密算法與通訊安全講解》

《即時(shí)通訊安全篇（四）：實(shí)例分析Android中密鑰硬編碼的風(fēng)險(xiǎn)》

《即時(shí)通訊安全篇（五）：對(duì)稱加密技術(shù)在Android平臺(tái)上的應(yīng)用實(shí)踐》

《即時(shí)通訊安全篇（六）：非對(duì)稱加密技術(shù)的原理與應(yīng)用實(shí)踐》

《傳輸層安全協(xié)議SSL/TLS的Java平臺(tái)實(shí)現(xiàn)簡(jiǎn)介和Demo演示》

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

《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》

《來(lái)自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》

《簡(jiǎn)述實(shí)時(shí)音視頻聊天中端到端加密（E2EE）的工作原理》

《移動(dòng)端安全通信的利器——端到端加密（E2EE）技術(shù)詳解》

《Web端即時(shí)通訊安全：跨站點(diǎn)WebSocket劫持漏洞詳解(含示例代碼)》

《通俗易懂：一篇掌握即時(shí)通訊的消息傳輸安全原理》

>> 更多同類文章 ……

[6] 開(kāi)源實(shí)時(shí)音視頻技術(shù)WebRTC的文章：

《開(kāi)源實(shí)時(shí)音視頻技術(shù)WebRTC的現(xiàn)狀》

《簡(jiǎn)述開(kāi)源實(shí)時(shí)音視頻技術(shù)WebRTC的優(yōu)缺點(diǎn)》

《訪談WebRTC標(biāo)準(zhǔn)之父：WebRTC的過(guò)去、現(xiàn)在和未來(lái)》

《良心分享：WebRTC 零基礎(chǔ)開(kāi)發(fā)者教程（中文）[附件下載]》

《WebRTC實(shí)時(shí)音視頻技術(shù)的整體架構(gòu)介紹》

《新手入門：到底什么是WebRTC服務(wù)器，以及它是如何聯(lián)接通話的？》

《WebRTC實(shí)時(shí)音視頻技術(shù)基礎(chǔ)：基本架構(gòu)和協(xié)議棧》

《淺談開(kāi)發(fā)實(shí)時(shí)視頻直播平臺(tái)的技術(shù)要點(diǎn)》

《[觀點(diǎn)] WebRTC應(yīng)該選擇H.264視頻編碼的四大理由》

《基于開(kāi)源WebRTC開(kāi)發(fā)實(shí)時(shí)音視頻靠譜嗎？第3方SDK有哪些？》

《開(kāi)源實(shí)時(shí)音視頻技術(shù)WebRTC中RTP/RTCP數(shù)據(jù)傳輸協(xié)議的應(yīng)用》

《簡(jiǎn)述實(shí)時(shí)音視頻聊天中端到端加密（E2EE）的工作原理》

《實(shí)時(shí)通信RTC技術(shù)棧之：視頻編解碼》

《開(kāi)源實(shí)時(shí)音視頻技術(shù)WebRTC在Windows下的簡(jiǎn)明編譯教程》

《網(wǎng)頁(yè)端實(shí)時(shí)音視頻技術(shù)WebRTC：看起來(lái)很美，但離生產(chǎn)應(yīng)用還有多少坑要填？》

>> 更多同類文章 ……

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> 更多同類文章 ……

[8] IM開(kāi)發(fā)綜合文章：

《從客戶端的角度來(lái)談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》

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

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課：正確理解前置HTTP SSO單點(diǎn)登陸接口的原理》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《移動(dòng)端IM開(kāi)發(fā)需要面對(duì)的技術(shù)問(wèn)題》

《開(kāi)發(fā)IM是自己設(shè)計(jì)協(xié)議用字節(jié)流好還是字符流好？》

《請(qǐng)問(wèn)有人知道語(yǔ)音留言聊天的主流實(shí)現(xiàn)方式嗎？》

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》

《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》

《一個(gè)低成本確保IM消息時(shí)序的方法探討》

《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》

《IM群聊消息如此復(fù)雜，如何保證不丟不重？》

《談?wù)勔苿?dòng)端 IM 開(kāi)發(fā)中登錄請(qǐng)求的優(yōu)化》

《移動(dòng)端IM登錄時(shí)拉取數(shù)據(jù)如何作到省流量？》

《淺談移動(dòng)端IM的多點(diǎn)登陸和消息漫游原理》

《完全自已開(kāi)發(fā)的IM該如何設(shè)計(jì)“失敗重試”機(jī)制？》

《通俗易懂：基于集群的移動(dòng)端IM接入層負(fù)載均衡方案分享》

《微信對(duì)網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》

《即時(shí)通訊系統(tǒng)的原理、技術(shù)和應(yīng)用（技術(shù)論文）》

《開(kāi)源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場(chǎng)有始無(wú)終的開(kāi)源秀》

《QQ音樂(lè)團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂(lè)團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》

《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開(kāi)源》

《基于社交網(wǎng)絡(luò)的Yelp是如何實(shí)現(xiàn)海量用戶圖片的無(wú)損壓縮的？》

>> 更多同類文章 …… 

[9] 開(kāi)源移動(dòng)端IM技術(shù)框架資料：

《開(kāi)源移動(dòng)端IM技術(shù)框架MobileIMSDK：快速入門》

《開(kāi)源移動(dòng)端IM技術(shù)框架MobileIMSDK：常見(jiàn)問(wèn)題解答》

《開(kāi)源移動(dòng)端IM技術(shù)框架MobileIMSDK：壓力測(cè)試報(bào)告》

>> 更多同類文章 ……

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