新功能发布记录
接收最大值（Receive Maximum）
概述
物联网应用中的设备能力存在差异，一些资源受限的设备可能无法同时处理大量传入的消息。为了应对这一问题，MQTT 5.0 引入了一套基于发送配额的流量控制机制，其核心实现便是 Receive Maximum 属性。Receive Maximum 旨在防止消息的发送速率超过接收端的处理能力，从而避免接收端因过载而崩溃，提升通信的可靠性和稳定性。
什么是 Receive Maximum
Receive Maximum 是一个在连接建立时协商的参数，同时存在于客户端的 CONNECT 报文和服务端的 CONNACK 报文中。它表示通信一方（客户端或服务端）愿意同时处理的、尚未完成确认的 QoS 1 或 QoS 2 的 PUBLISH 报文的最大数量，即可用的最大发送配额。
简单来说，当客户端 A 连接到服务端时：
客户端 A 可以在 CONNECT 报文中设置一个 Receive Maximum，例如 10。这等于告诉服务端：“你最多可以同时发送 10 个 QoS>0 的消息给我，在我确认之前，请不要发送第 11 个。”
同样，服务端也可以在 CONNACK报文中返回一个 Receive Maximum，例如 50。这等于告诉客户端 A：“你最多可以同时‘在途’ 50 个 QoS>0 的消息给我。”
工作原理
Receive Maximum 的实现依赖于一个动态的“发送配额”计数器：
1. 初始状态：当连接建立时，发送端的初始可用配额等于接收端声明的 Receive Maximum 值。
2. 发送消息：每当发送端发出一个 QoS 1 或 QoS 2 的 PUBLISH 报文，其可用配额就减 1。
3. 接收确认：当接收端返回相应的确认报文（对于 QoS 1 是 PUBACK，对于 QoS 2 是 PUBREC 或 PUBCOMP），发送端的可用配额就加 1。
4. 配额耗尽：如果可用配额减至 0，发送端必须停止发送任何新的 QoS 1 或 QoS 2 的消息，直到收到确认报文并恢复配额为止。
5. 违规处理：如果接收端发现对端违反此规则（例如，在配额为 0 时仍发送 QoS>0 的消息），它必须将此视为协议错误，并断开连接以保护自己。
说明：
Receive Maximum 机制仅针对 QoS 1 和 QoS 2 的消息。QoS 0 消息（最多交付一次）没有对应的确认报文，因此不受此配额限制。
MQTT 5.0 规范对此情况给出了一个非强制性建议：
当发送端的配额为 0 时，发送端可以选择继续发送 QoS 0 消息，也可以选择暂停发送。
最佳实践是暂停发送。因为若 QoS 1/2 的 PUBLISH 报文的应答速度变慢，通常意味着接收端的消费能力已经下降，此时继续发送 QoS 0 消息只会加剧问题。
优势与价值
尽管存在对 QoS 0 消息控制的局限性，Receive Maximum 机制依然带来了显著的好处：
防止过载：为核心的消息传输（QoS 1/2）提供了可靠的保护，确保接收端不会因消息洪泛而崩溃。
动态高效：基于确认的配额恢复机制使得发送端可以最大限度地利用网络带宽和接收端的处理能力，实现最大程度地利用资源 。
无需预先协商：连接双方在建立连接时即宣告自身的能力，无需在应用层进行复杂的额外协商，通信过程透明。
异构系统兼容：在需要接入来自不同厂商、处理能力各异的设备时，此机制提供了极大的灵活性。
Receive Maximum 是 MQTT 5.0 为改善协议可靠性和资源管理而引入的一项关键特性。它通过一种优雅的发送配额模型，有效地解决了 QoS 1 和 QoS 2 消息的流量控制问题。虽然它对 QoS 0 消息的控制是建议性的而非强制性的，存在一定的不足，但这套机制仍然是 MQTT 发展中的重要进步。我们强烈建议用户在支持 MQTT 5.0 的环境中积极使用此特性，以构建更加健壮和稳定的物联网应用。
文档反馈