什么是IM即时通讯系统的可靠性？

一般来说，IM系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令，为了通俗，统称“消息”）。

从用户行为来讲，消息“可靠性”应该分为两种类型：

• 1）在线消息的可靠性：即发送消息时，接收方当前处于“在线”状态；
• 2）离线消息的可靠性：即发送消息时，接收方当前处于“离线”状态。

从具体的技术表现来讲，消息“可靠性”包含两层含义：

• 1）消息不丢：这很直白，发出去的消息不能像进了黑洞一样，一脸懵逼可不行；
• 2）消息不重：这是丢消息的反面，消息重复了也不能容忍。

对于“消息不丢”这个特征来说，细化下来，它又包含两重含义：

• 1）已明确被对方收到；
• 2）已明确未被对方收到。

是的，对于第1）重含义好理解，第2）重含义的意思是：当对方没有成功收到时，你的im系统也必须要感知到，否则，它同样属于被“丢”范畴。

总之，一个成型的im系统，必须包含这两种消息“可靠性”逻辑，才能堪用，缺一不可。

消息的可靠性（不丢失、不重复）无疑是IM系统的重要指标，也是IM系统实现中的难点之一。本文以下文字，将从在线消息的可靠性和离线消息的可靠性进行讨论。

所谓“服务端中转型IM架构”是指：一条消息从客户端A发出后，需要先经过 IM 服务器来进行中转，然后再由 IM 服务器推送给客户端B，这种模式也是目前{BANNED}最佳常见的 IM 系统的消息分发架构。

你可能会说，IM不可以是P2P模式的吗？是的，目前来说主流IM基本都是服务器中转这种方式，P2P模式在IM系统中用的很少。

原因是以下两个很明显的弊端：

• 1）P2P模式下，IM运营者很容易被用户架空（无法监管到用户行为，用户涉黄了怕不怕？）；
• 2）P2P模式下，群聊这种业务形态，很难实现（我要在千人群中发消息给，不可能我自已来分发1000次吧）。即时通讯聊天软件app开发可以加小蓝豆的v：weikeyun24咨询

话题有点跑偏，我们回到正题：在上面这张图里，客户A发送消息到服务端、服务端中转消息给客户B，假设这两条数据链接中使用的通信协议是TCP，你认为在TCP所谓可靠传输协议加持下，真的能保证IM聊天消息的可靠性吗？

在一个典型的服务端中转型IM架构中，即使使用“可靠的传输协议”TCP，也不能保证聊天消息的可靠性。为什么这么说？

要回答这个问题，网上的很多文章，都会从服务端的角度举例：比如消息发送时操作系统崩溃、网络闪断、存储故障等等，总之很抽象，不太容易理解。

这次我们从客户端角度来理解，为什么使用了可靠传输协议TCP的情况下IM聊天消息仍然不可靠的问题。

具体来说：如何确保 IM 消息的可靠性是个相对复杂的话题，从客户端发送数据到服务器，再从服务器送达目标客户端，{BANNED}最佳终在 UI 成功展示，其间涉及的环节很多，这里只取其中一环「接收端如何确保消息不丢失」来探讨，粗略聊下我接触过的两种设计思路。

说到可靠送达：{BANNED}中国第一反应会联想到 TCP 的可靠性。数据的可靠送达是个通用性的问题，无论是网络二进制流数据，还是上层的业务数据，都有可靠性保障问题，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 会采取某种策略重发上面的包。

{BANNED}中国第一个问题是：既然 TCP 本身是具备可靠性的，为什么还会出现消息接收端（Receiver）丢失消息的情况？

数据可靠抵达网络层之后，还需要一层层往上移交处理，可能的处理有：

• 1）安全性校验；
• 2）binary 解析；
• 3）model 创建；
• 4）写 db；
• 5）存入 cache；
• 6）UI 展示；
• 7）以及一些边界问题：比如断网、用户突然退出登陆、磁盘已满、内存溢出、app奔溃、突然关机等等。

项目的功能特性越多，网络层往上的处理出错的可能性就越大。

举个{BANNED}最佳简单的场景为例子：消息可靠抵达网络层之后，写 db 之前 IM APP 崩溃（不稀奇，是 App 都有崩溃的可能），虽然数据在网络层可靠抵达了，但没存进 db，下次用户打开 App 消息自然就丢失了，如果不在业务层再增加可靠性保障（比如：后面要提到的网络层面的消息重发保障），那么意味着这条消息对于接收端来说就永远丢失了，也就自然不存在“可靠性”了。

那么怎样在应用层增加可靠性保障呢？

有一个现成的机制可供我们借鉴：TCP协议的超时、重传、确认机制。

具体来说就是：

• 1）在应用层构造一种ACK消息，当接收方正确处理完消息后，向发送方发送ACK；
• 2）假如发送方在超时时间内没有收到ACK，则认为消息发送失败，需要进行重传或其他处理。

我们可以把整个过程分为两个阶段。

阶段1：clientA -> server

• 1-1：clientA向server发送消息(msg-Req)；
• 1-2：server收取消息，回复ACK(msg-Ack)给clientA；
• 1-3：一旦clientA收到ACK即可认为消息已成功投递，{BANNED}中国第一阶段结束。

无论msg-A或ack-A丢失，clientA均无法在超时时间内收到ACK，此时可以提示用户发送失败，手动进行重发。

阶段2：server -> clientB

• 2-1：server向clientB发送消息(Notify-Req)；
• 2-2：clientB收取消息，回复ACK(Notify-ACk)给server；
• 2-3：server收到ACK之后将该消息标记为已发送，第二阶段结束。

无论msg-B或ack-B丢失，server均无法在超时时间内收到ACK，此时需要重发msg-B，直到clientB返回ACK为止。