从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
1、前言
IM App 是我做过 App 类型里复杂度最高的一类，里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制（因为我个人对移动客户端的经验积累的比较丰富嘛）。
学习交流：
- 即时通讯开发交流群：320837163[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-1470-1-1.html）
2、关于作者
作者网名：Peak，毕业于浙江大学，现为Facebook iOS 工程师。
作者的github：https://github.com/music4kid
作者的博客：http://mrpeak.cn/About/
3、相关文章
IM开发干货系列文章或许也值得您读一读，总目录如下：
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
《移动端IM登录时拉取数据如何作到省流量？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《浅谈移动端IM的多点登陆和消息漫游原理》
《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。
4、TCP协议的可靠性之外还会出现消息丢失？
如何确保 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协议一篇就够》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
>> 更多同类文章 ……
业务层保障可以采取以下两种方案，请继续阅读下一节。
5、客户端方案1：应用层 Ack 消息
这个方案可以简单理解为，将 TCP 的 Ack 流程再走一遍，在应用层也构建一个 Ack 消息，在应用层可靠性得到确认（一般以存入 db 为准，更准确说是事务提交成功的回调函数）之后再发送这个 Ack 消息，Server 收到应用层 Ack 消息之后才认为 Receiver 已收到，否则也采取某种策略重发消息。
具体到 IM App 当中，接收端接受到 Server 的 Message，将 Message 存入 db，在确认回调里发送 Ack Receive 消息，Server 收到 Ack Receive 即认为消息已经可靠抵达，否则会在某个时机重新推送（比如客户端重连服务器时候 Pull，比如有新消息时 Server Push）。
6、客户端方案2：应用层 Seq ID
这个方案和上面不同，但也是在应用层操作。我们个每个 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 消息的数据量。
7、本文小结
消息的可靠抵达可以抽象为更一般意义上的可靠性问题，工程上总会碰到需要解决各种形式可靠性问题的场景，以经典计算机理论或者实践为基础来分析应用层的工程问题，可以举一反三，药到病除。
在工程上实践可靠性，需要线了解工程的每一个环节以及数据如何在各个环节流动，接下来才是分析每一个环节数据出错的可能性。检验可靠性的标准时「入袋为安」，存入 db 或者以其他方式持久化到 disk 当中，这样才能保证客户端每次都能正确读取到消息。
另外，可靠性可以理解为两方面：
一是数据可靠抵达（没有任何中间数据被丢失）；
二是正确抵达（没有乱序或者数据更改）。
其实理论上 TCP 也不是 100% 可靠（数据有可能在传输时改变而无法被检测到），而是 100% 工程上可靠（数据改变而不被检测到时个极小概率的事件），这是另外一个有意思的话题。
附录：更多IM开发技术文章
[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：压力测试报告》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1470-1-1.html）