如何确保单聊消息100%送达?揭秘消息可靠传输的核心机制!

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 哈喽,大家好!我是技术好朋友小米,今天聊聊单聊消息的可靠传输。通过TCP的超时、重传、确认机制,结合去重和离线消息优化,我们可以设计出高效、可靠的消息传输系统。希望今天的分享能给大家带来帮助!如果有问题,欢迎留言交流。



哈喽,大家好!我是你们的技术好朋友小米,今天我们聊聊单聊消息的可靠传输。这个话题有点酷哦,尤其对于那些正在开发即时通讯项目的小伙伴们。想想你给好友发消息,却总担心消息会不会送达,离线消息会不会丢失,这种场景是不是很常见?不用担心,咱们可以通过一套可靠传输机制来解决!今天我们就来一起拆解这个“套路”。

TCP保证消息可靠传输的三板斧

首先,聊到消息的可靠传输,不得不提我们熟知的TCP三板斧超时、重传、确认。这些基本概念支撑了现代网络传输的可靠性:

  • 超时:每次发送消息后,等待一段时间,如果没有得到回复,就会触发超时机制。
  • 重传:当超时发生时,TCP会自动重发未确认的消息,直到收到确认消息或重试次数耗尽。
  • 确认:每当收到消息时,接收方必须返回一个确认报文,告诉发送方“你的消息我收到了”。

消息传输通过这三个步骤保障,确保每个数据包都不会丢失或重复发送。

消息的三类报文:R、A、N

在设计单聊的消息可靠传输时,通常使用三种不同类型的报文来进行交互,分别是:

  • 请求报文 (Request,R):由客户端发起,向服务器发送的消息请求。
  • 应答报文 (Acknowledge,A):由服务器返回,确认接收客户端的请求。
  • 通知报文 (Notify,N):由服务器主动发送给客户端,通知该客户端有新消息。

简单理解就是,客户端发出消息请求(R),服务器回应确认(A),然后服务器再通知客户端对方是否收到消息或有新消息(N)。

在线消息流程详解

为了让大家更直观理解消息在网络中如何可靠地传输,我们来详细走一遍在线消息传输的整个流程。咱们以一个简单的单聊示例为基础:

  1. A -> 服务器:A用户给服务器发消息,消息是MSG(Request)。
  2. 服务器 -> A:服务器收到A发来的消息,回复一个MSG(Acknowledge),表示消息收到了。
  3. 服务器 -> B:服务器把A发来的消息转发给B,这里发送的是MSG(Notify)。
  4. B -> 服务器:B收到服务器的消息后,发送ACK,确认收到了这条消息。
  5. 服务器 -> A:服务器收到B的确认后,回复给A一个ACK,表示消息成功传达给了B。

这个流程总共6个报文来回传递,确保消息从A到B的可靠传输,每个节点都有ACK确认机制,保证每个消息都能送达。

超时、重传与确认机制

可靠传输的核心之一就是超时与重传机制。我们来看下A用户发送消息时的场景:

  1. 发送消息:A用户发出MSG,并在本地记录这条消息,等待服务器的确认ACK。
  2. 消息重传:如果A没有在设定的时间内收到服务器的MSG确认,就会触发超时机制,重新发送MSG。A还需要维护一个等待ACK的队列,记录哪些消息还未被确认。
  3. 确认ACK:每次A收到服务器的ACK,表示B用户成功接收到消息了,A会从等待ACK的队列中删除对应的消息。

通过这样的机制,消息必达得以实现,即使在网络不稳定的情况下,重发机制也能确保消息最终送达。

去重机制

同时,为了避免重传导致消息重复的问题,服务器和客户端都需要有一套去重机制。每条消息会带上一个唯一的ID,服务器在收到消息时,会检查这个ID是否已经处理过。如果处理过,则忽略该消息,避免重复推送给接收方。

离线消息处理:原方案 vs 优化方案

在单聊场景中,处理离线消息也是至关重要的一环。如果用户在不在线时收到消息,我们该如何保障消息的传递和回执呢?来看下两种方案:

原方案

用户上线后,客户端会主动向服务器拉取离线消息,流程如下:

  • 检测离线:客户端检查用户是否离线。
  • 拉取消息:客户端向服务器发出拉取指定时间段内的消息请求。
  • 返回消息:服务器响应,发送离线期间的消息给客户端。

这种方案虽然简单,但在面对海量消息时效率不高,尤其当消息量非常大时,拉取消息的时间可能会很长,导致用户体验卡顿。

优化方案

针对原方案的不足,我们可以对离线消息的处理进行优化:

  • 全量拉取计数:用户可以勾选全量拉取选项,服务器首先返回离线消息的总条数,当用户需要时再点击具体查看。
  • 默认拉取最近消息:如果用户未选择全量拉取,则服务器只返回最近的全部离线消息,客户端可以根据用户的id进行计算,筛选消息。
  • 分页拉取:为了避免一次拉取过多消息,导致客户端卡顿,可以将全量离线消息分页拉取。客户端通过异步线程分批获取消息,减少瞬时压力。
  • ACK报文优化:当客户端拉取离线消息时,可以将ACK和第二次分页拉取的请求合并,从而减少来回交互次数,提高效率。

通过这些优化,我们能让离线消息传输更高效,确保即使消息量再大,用户也能流畅地收到所有消息。

END

单聊消息的可靠传输涉及到多方面的技术细节,既要保证在线消息的实时可靠传输,也要妥善处理离线消息。通过TCP的超时、重传、确认机制,结合去重离线消息优化,我们可以设计出一套高效、可靠的消息传输系统。

在实际项目开发中,不同场景下的处理逻辑可能会有所不同,大家可以根据自己的需求进行定制。

希望今天的分享能给你们带来帮助!如果有任何问题,欢迎在评论区留言,我是小米,咱们下次见!

我是小米,一个喜欢分享技术的29岁程序员。如果你喜欢我的文章,欢迎关注我的微信公众号软件求生,获取更多技术干货!

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
消息中间件 存储 运维
|
10天前
|
存储 安全 算法
物联网发布者在发送数据时如何保证数据的安全性和完整性
数据加密、密钥管理和数据完整性验证是物联网安全的重要组成部分。对称加密(如AES)和非对称加密(如RSA)分别适用于大量数据和高安全需求的场景。密钥需安全存储并定期更新。数据完整性通过MAC(如HMAC-SHA256)和数字签名(如RSA签名)验证。通信协议如MQTT over TLS/SSL和CoAP over DTLS增强传输安全,确保数据在传输过程中的机密性和完整性。
|
6月前
|
消息中间件
【面试问题】如何确保消息正确地发送至 RabbitMQ? 如何确保消息接收方消费了消息?
【1月更文挑战第27天】【面试问题】如何确保消息正确地发送至 RabbitMQ? 如何确保消息接收方消费了消息?
|
消息中间件 存储 Kafka
如何保证MQ中消息的可靠性传输?
如何保证MQ中消息的可靠性传输?
108 1
|
消息中间件
如何保证消息的可靠性,避免消息丢失
如何保证消息的可靠性,避免消息丢失
102 0
|
消息中间件 数据安全/隐私保护
【OpenAirInterface5g】ITTI消息收发机制
OAI各个模块拥有自己的消息队列,当其他模块需要向该模块发送消息时,只需将封装好的message压入对端模块队列,本模块进行消息接收时,从本模块队列依次取出message,进行解析。
311 0
|
消息中间件 存储 Kafka
MQ 学习日志(六) 保证消息的可靠性传输
消息的可靠性传输 简述
117 0
|
消息中间件 存储 缓存
该如何保证消息的可靠性传输
该如何保证消息的可靠性传输
129 0
|
网络协议 测试技术 Go
海量用户通讯系统-服务器接收消息1
海量用户通讯系统-服务器接收消息1
海量用户通讯系统-服务器接收消息1
|
JSON 网络协议 测试技术
海量用户通讯系统-服务器接收消息2|学习笔记
快速学习海量用户通讯系统-服务器接收消息2
海量用户通讯系统-服务器接收消息2|学习笔记