1、前言

互聯網發展至今，IM（即時通訊聊天應用）一直是互聯網上最為成功也是最為平常的應用類型。尤其現今的移動互聯網時代，因即時通訊技術的發展和普及，IM這種即時通訊應用已乎達成了各即時通訊應用運營者夢寐已求的所謂“全時在線”，而這種“全時在線”及其應用體驗的背后，回歸到技術本質就是各種行為消息（或者說信息）的實時性、必達性。

本文將要討論的是即時IM應用中極其重要但也不被用戶感知的消息送達保證機制（即QoS機制），文中將給出目前主流的參考實現思路。

2、IM開發干貨系列文章

• 《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
• 《如何保證IM實時消息的“時序性”與“一致性”？》

3、本文概述

消息的可靠性，即消息的不丟失和不重復，是IM系統中的一個難點。當初QQ在技術上（當時叫OICQ）因為以下兩點原因才打敗了ICQ：
?

• QQ的消息投遞可靠（消息不丟失，不重復）；
• QQ的垃圾消息少（它antispam做得好，這也是一個難點，但不是本文重點討論的內容）。

今天，本文將用十分通俗的語言，來講述IM系統中消息可靠性的問題。

4、報文類型

IM的客戶端與服務器通過發送報文（也就是請求包）來完成消息的傳遞。

報文分為三種：
?

• 請求報文（request，后簡稱為為R）；
• 應答報文（acknowledge，后簡稱為A）；
• 通知報文（notify，后簡稱為N）。

這三種報文的解釋如下：

• R：客戶端主動發送給服務器的報文
• A：服務器被動應答客戶端的報文，一個A一定對應一個R
• N：服務器主動發送給客戶端的報文

?

5、普通消息投遞流程

用戶A給用戶B發送一個“你好”，很容易想到，流程如下：

• client-A向im-server發送一個消息請求包，即msg:R
• im-server在成功處理后，回復client-A一個消息響應包，即msg:A
• 如果此時client-B在線，則im-server主動向client-B發送一個消息通知包，即msg:N（當然，如果client-B不在線，則消息會存儲離線）

?

6、上述消息投遞流程出現的問題

從流程圖中容易看到，發送方client-A收到msg:A后，只能說明im-server成功接收到了消息，并不能說明client-B接收到了消息。在若干場景下，可能出現msg:N包丟失，且發送方client-A完全不知道，例如：
?

• 服務器崩潰，msg:N包未發出
• 網絡抖動，msg:N包被網絡設備丟棄
• client-B崩潰，msg:N包未接收

結論是悲觀的：接收方client-B是否有收到msg:N，發送方client-A完全不可控，那怎么辦呢？

7、應用層確認+im消息可靠投遞的六個報文

我們來參考網絡傳輸協議的實現：UDP是一種不可靠的傳輸層協議，TCP是一種可靠的傳輸層協議，TCP是如何做到可靠的？答案是：超時、重傳、確認。（即時通訊網注：實際上IM中，數據通訊層無論用的是UDP還是TCP協議，都同樣需要消息送達保證（即QoS）機制，原因在于IM的通信是A端-Server-B端的3方通信，而非傳統C/S或B/S這種2方通信）。

要想實現應用層的消息可靠投遞，必須加入應用層的確認機制，即：要想讓發送方client-A確保接收方client-B收到了消息，必須讓接收方client-B給一個消息的確認，這個應用層的確認的流程，與消息的發送流程類似：
?

• client-B向im-server發送一個ack請求包，即ack:R
• im-server在成功處理后，回復client-B一個ack響應包，即ack:A
• 則im-server主動向client-A發送一個ack通知包，即ack:N

至此，發送“你好”的client-A，在收到了ack:N報文后，才能確認client-B真正接收到了“你好”。

你會發現，一條消息的發送，分別包含（上）（下）兩個半場，即msg的R/A/N三個報文，ack的R/A/N三個報文。一個應用層即時通訊消息的可靠投遞，共涉及6個報文，這就是im系統中消息投遞的最核心技術（如果某個im系統不包含這6個報文，不要談什么消息的可靠性）。

8、可靠消息投遞存在什么問題

期望六個報文完成消息的可靠投遞，但實際情況下：
?

• msg:R，msg:A 報文可能丟失：
  此時直接提示“發送失敗”即可，問題不大；
• msg:N，ack:R，ack:A，ack:N這四個報文都可能丟失：
  （原因如第二章所述，可能是服務器奔潰、網絡抖動、或者客戶端奔潰），此時client-A都收不到期待的ack:N報文，即client-A不能確認client-B是否收到“你好”。

那怎么辦呢？

9、消息的超時與重傳

client-A發出了msg:R，收到了msg:A之后，在一個期待的時間內，如果沒有收到ack:N，client-A會嘗試將msg:R重發。可能client-A同時發出了很多消息，故client-A需要在本地維護一個等待ack隊列，并配合timer超時機制，來記錄哪些消息沒有收到ack:N，以定時重發。

一旦收到了ack:N，說明client-B收到了“你好”消息，對應的消息將從“等待ack隊列”中移除。

10、消息的重傳存在什么問題

第五節提到過，msg:N報文，ack:N報文都有可能丟失：
?

• msg:N 報文丟失：說明client-B之前壓根沒有收到“你好”報文，超時與重傳機制十分有效
• ack:N 報文丟失：說明client-B之前已經收到了“你好”報文（只是client-A不知道而已），超時與重傳機制將導致client-B收到重復的消息。

啟示：

平時使用qq，或許大伙都有類似的體驗，彈出一個對話框“因為網絡原因，消息發送失敗，是否要重發”，此時，有可能是對方沒有收到消息（發送方網絡不好，msg:N丟失），也可能已經收到了消息（接收方網絡不好，反復重傳后，ack:N依然丟失），出現這個提示時，大伙不妨和對端確認一下，看是哪種情況。

11、消息的去重

解決方法也很簡單，由發送方client-A生成一個消息去重的msgid，保存在“等待ack隊列”里，同一條消息使用相同的msgid來重傳，供client-B去重，而不影響用戶體驗。

12、其他

1）上述設計理念，由客戶端重傳，可以保證服務端無狀態性（架構設計基本準則）；
2）如果client-B不在線，im-server保存了離線消息后，要偽造ack:N發送給client-A；
3）離線消息的拉取，為了保證消息的可靠性，也需要有ack機制，但由于拉取離線消息不存在N報文，故實際情況要簡單的多，即先發送offline:R報文拉取消息，收到offline:A后，再發送offlineack:R刪除離線消息。

13、總結

1）im系統是通過超時、重傳、確認、去重的機制來保證消息的可靠投遞，不丟不重；
2）切記，一個“你好”的發送，包含上半場msg:R/A/N與下半場ack:R/A/N的6個報文。

個人消息是一個1對1的ack，群消息就沒有這么簡單了，群消息存在一個擴散系數，im群消息的可靠投遞問題感興趣的可查閱相關資料。

網易云信，你身邊的即時通訊和音視頻技術專家，了解我們，請戳網易云信官網

想要行業洞察和技術干貨，請關注網易云信博客

本文轉載自52im,作者：JackJiang

總結

以上是生活随笔為你收集整理的IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。