微信为什么不丢消息？.pdfVIP

微信为什么不丢消息？ 上⼀章和⼤家分享了 《http如何像tcp⼀样实时的收消息？》， 本章来聊⼀聊即时通讯 （Instant Messaging ，后 称im ）消息的可靠投递。 ⼀、报⽂类型 im的客户端与服务器通过发送报⽂ （也就是⽹络包）来完成消息的传递，报⽂分为三 种 请求报⽂ （request ，后 称为为R ） 应答报⽂ （acknowledge ，后 称为A ） 通知报⽂ （notify ，后 称为N ），这三种报⽂的解释如下： R：客户端主动发送给服务器的报⽂ A：服务器被动应答客户端的报⽂，⼀个A对应⼀个R N：服务器主动发送给客户端的报⽂ ⼆、普通消息投递流程 ⽤户A给⽤户B发送⼀个“你好” ，流程如下： 1）client A 向im server发送⼀个消息请求包，即msg:R 2 ）im server在成功处理后，回复client A⼀个消息响应包，即msg:A 3 ）如果此时client B在线，则im server主动向client B发送⼀个消息通知包，即 msg:N （当然，如果client B不在线，则消息会存储离线） 三、上述消息投递流程出现的 题 从流程图中容易看到，发送⽅client A收到msg:A后，只能说明im server成功接收到了 消息，并不能说明client B接收到了消息。在若⼲场景下，可能出现msg:N包丢失，且 发送⽅client A完全不知道，例如： 1）服务器崩溃，msg:N包未发出 2 ）⽹络抖动，msg:N包被⽹络设备丢弃 3 ）client B崩溃，msg:N包未接收 结论是悲观的：接收⽅client-B是否有收到msg:N，发送⽅client-A完全不可控，那怎 么办呢？ 四、应⽤层确认+im消息可靠投递的六个报⽂ upd是⼀种不可靠的传输层协议，tcp是⼀种可靠的传输层协议，tcp是如何做到可靠 的？答案是：超时、重传、确认。 要想实现应⽤层的消息可靠投递，必须加⼊应⽤层的确认机制，即：要想让发送⽅ client A确保接收⽅client B收到了消息，必须让接收⽅client B给⼀个消息的确认，这 个应⽤层的确认的流程，与消息的发送流程类似： 4 ）client B 向im server发送⼀个ack请求包，即ack :R 5 ）im server在成功处理后，回复client B⼀个ack 响应包，即ack :A 6 ）则im server主动向client A发送⼀个ack通知包，即ack :N ⾄此，发送“你好”的client A ，在收到了ack :N报⽂后，才能确认client B真正接收到 了“你好” 。 会发现，⼀条消息的发送，分别包含 （上） （下）两个半场，即msg的R/A/N三个报 ⽂，ack 的R/A/N三个报⽂，⼀个应⽤层即时通讯消息的可靠投递，共涉及6个报⽂， 这就是im系统中消息投递的最核⼼技术。 五、可靠消息投递存在什么 题 期望六个报⽂完成消息的可靠投递，但实际情况，msg:N，ack:N这两个报⽂都可能丢 失 （原因如第⼆章所述，可能是服务器奔溃、⽹络抖动、或者客户端奔溃），此时 client A都收不到期待的ack :N报⽂，即client A不能确认client B是否收到“你好” ，但这 两个报⽂的丢失对应的业务影响又⼤有不同： 1）msg:N包丢失，业务结果是client B没有收到消息 2 ）ack :N包丢失，业务结果是client B收到了消息，只是client A不知道⽽已 那怎么办呢？ 六、消息的超时与重传 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 队列” 中 移除。 七、消息的重传存在什么 题 第五章提到过，msg:N ，ack :N都有可能丢失： 1）msg:N报⽂丢失，说明client B之前压根没有收到“你好”报⽂，超时与重传机制⼗分 有效 2 ）ack :N报⽂丢失，说明client B之前已经收到了“你好”报⽂ （只是client A不知道⽽ 已），超时与重传机制将导致client B收到重复的消息，那怎么办呢？ ⼋、消息的去重 解决⽅法也很 单，由发送⽅client A⽣