IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

1、前言

互联网发展至今，IM（即时通讯聊天应用）一直是互联网上最为成功也是最为平常的应用类型。尤其现今的移动互联网时代，因即时通讯技术的发展和普及，IM这种即时通讯应用已乎达成了各即时通讯应用运营者梦寐已求的所谓“全时在线”，而这种“全时在线”及其应用体验的背后，回归到技术本质就是各种行为消息（或者说信息）的实时性、必达性。

本文将要讨论的是即时IM应用中极其重要但也不被用户感知的消息送达保证机制（即QoS机制），文中将给出目前主流的参考实现思路。

另外，开源轻量级移动端即时通讯框架 MobileIMSDK 的消息送达保证（QoS机制）的大致原理请见：http://www.52im.net/thread-129-1-2.html，3楼Jack Jiang的回复已指出技术原理，跟本文中所描术的思路异曲同工，需要的可以看看。也可以从《为什么说基于TCP的移动端IM仍然需要心跳保活？》一文中了解到TCP协议下的移动端IM网络状况分析。

2、IM开发干货系列文章

本文是系列文章中的第1篇，总目录如下：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》（本文）
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
• 《移动端IM登录时拉取数据如何作到省流量？》
• 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
• 《浅谈移动端IM的多点登陆和消息漫游原理》
• 《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
• 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
• 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
• 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
• 《IM群聊消息的已读回执功能该怎么实现？》
• 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
• 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
• 《一个低成本确保IM消息时序的方法探讨》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
• 《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
• 《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
• 《IM的扫码登功能如何实现？一文搞懂主流应用的扫码登陆技术原理》
• 《IM要做手机扫码登陆？先看看微信的扫码登录功能技术原理》
• 《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
• 《IM开发实战干货：我是如何解决大量离线聊天消息导致客户端卡顿的》
• 《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群消息的可靠投递问题感兴趣的可查阅相关资料。

14、更多IM开发综合文章

《新手入门一篇就够：从零开发移动端IM》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《小白必读：闲话HTTP短连接中的Session和Token》
《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是如何实现海量用户图片的无损压缩的？》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移动端主流图片格式的特点、性能、调优等》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《融云技术分享：解密融云IM产品的聊天消息ID生成策略》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》
《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《IM要做手机扫码登录？先看看微信的扫码登录功能技术原理》
《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
《零基础IM开发入门(一)：什么是IM系统？》
《零基础IM开发入门(二)：什么是IM系统的实时性？》
《零基础IM开发入门(三)：什么是IM系统的可靠性？》
《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》
《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
《IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《IM扫码登录技术专题(一)：微信的扫码登录功能技术原理调试分析》
《IM扫码登录技术专题(二)：市面主流的扫码登录技术原理调试分析》
《IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够》
《IM扫码登录技术专题(四)：你真的了解二维码吗？刨根问底、一文掌握！》
《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
《IM开发干货分享：万字长文，详解IM“消息“列表卡顿优化实践》
《IM全文检索技术专题(三)：网易云信Web端IM的聊天消息全文检索技术实践》
《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》
《探探的IM长连接技术实践：技术选型、架构设计、性能优化》
《IM开发干货分享：浅谈IM系统中离线消息、历史消息的最佳实践》
>> 更多同类文章 ……

（原文链接：http://www.habadog.com/2015/04/29/webim-msg-send-ack/）

模型总结很好

学习了

引用：kezhaoyuan 发表于 2016-05-11 11:17
你说的跟微信的设计是一致的，把群消息当个人消息处理。
而2个问题我在实际中确实遇到了。
第1个还好解 ...

我觉着这篇文章可以解决你的问题http://www.52im.net/thread-1616-1-1.html。消息存一份就够了。
但是四年前的评论。。。。

引用：pengion 发表于 2021-03-25 20:54
应用层的逻辑是具体指什么？能详述下或者有什么文章参考吗

这篇文章《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》，第4节“4、TCP协议的可靠性之外还会出现消息丢失？”应该能解答你的问题。

引用：JackJiang 发表于 2021-03-19 12:19
这里的重传和去重，主要是应用层的逻辑带来的，跟tcp协议栈这一层无关

应用层的逻辑是具体指什么？能详述下或者有什么文章参考吗

引用：pengion 发表于 2021-03-19 09:11
没太理解，有什么帖子能解释吗？tcp已经有了重传和去重的机制，为什么还要Qos。。。

这里的重传和去重，主要是应用层的逻辑带来的，跟tcp协议栈这一层无关

引用：JackJiang 发表于 2021-02-15 16:05
应用层的情况很复杂，QoS有必要

没太理解，有什么帖子能解释吗？tcp已经有了重传和去重的机制，为什么还要Qos。。。

引用：某非著名程序 发表于 2021-03-10 19:30
要是想要实现消息历史记录，服务端就需要存储消息，是不是就不用这种方式了

需要

要是想要实现消息历史记录，服务端就需要存储消息，是不是就不用这种方式了

引用：pengion 发表于 2021-02-14 21:06
请教楼主，如果用tcp的话，Qos机制还有必要吗？

应用层的情况很复杂，QoS有必要

请教楼主，如果用tcp的话，Qos机制还有必要吗？

引用：yangyang 发表于 2020-09-25 15:17
源码3.0中没有处理粘包的情况吗，我只看到直接一堆发出去了，没有包头吗

你指的源码，具体指的是哪个工程？

源码3.0中没有处理粘包的情况吗，我只看到直接一堆发出去了，没有包头吗

a为什么需要关心b是否收到消息，a只需要保证是否收到server的response就可以了。b是否收到消息由b和server之间的ack保证就可以了。按照你的设计思路，如果server给b下推了a发送的消息，但是b由于网络原因没有收到，那岂不是a要一直重新发送吗？

引用：JackJiang 发表于 2019-04-10 14:55
如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最 ...

关于这一点我不太想得通
我目前认为，在具有离线存储功能的消息系统中，由服务器ack client_a 就足够了。
至于由client_b 做ack更精准，我觉得这一步更像是为 【未读-已读】做服务。
至于群主前面说的，当client_b离线时由服务器替client_b做伪ack，其实还是由服务器做ack罢了

顺便问下，系统消息与客户端消息的处理过程，应该差不多吧

请问有关于用TCP还是UDP的分析的文章么？目前初接触IM，还在写玩具玩，个人认为TCP能省不少事=。=

找到了=。=

引用：JackJiang 发表于 2019-04-10 14:55
如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最 ...

B如何告诉A呢？

我想买一份你的源码

引用：lijingpei2016 发表于 2019-04-10 14:28
群主好，请问在A和B都同时在线的时候，又不用做“已读”功能
是否可以简化为这样？

如果你读过我写的 MobileIMSDK的源码，就可以知道，我认为：应答应该由B来告诉A，而不是由服务器，这样最精简，也最精确，因为收没收到B的应答是最精准的

群主好，请问在A和B都同时在线的时候，又不用做“已读”功能
是否可以简化为这样？