当前位置: 首页 > 工具软件 > mica-mqtt > 使用案例 >

mqtt qos属性

姚臻
2023-12-01

QoS 存在3个值 分别 0 1 2
QoS 0:消息最多传递 1 次,如果当时 sub 端不可用,则会丢失该消息。
QoS 1:消息传递至少 1 次,在 pub 消息之后等待 sub 的 ACK,如果没收到 ACK 则重新发送消息,这种模式能保证消息至少能到达一次,但无法保证消息重复。
QoS 2:消息仅传送 1 次,QoS 2 设计了重发和重复消息发现机制,保证消息到达对方并且严格只到达一次。因此正常来说这种模式下 sub 端即使离线,在上线后也会收到消息。
而mqtt的消息重发建立在订阅客户端设置Clean Session 为false的情况。
mqtt5.0:增加了流量控制,在 MQTT v5 中,发送端会有一个初始的发送配额,每当它发送一个 QoS 大于 0 的 PUBLISH 报文,发送配额就相应减一,而每当收到一个响应报文(PUBACK、PUBCOMP 或 PUBREC),发送配额就会加一。如果接收端没有及时响应,导致发送端的发送配额减为 0,发送端应当停止发送所有 QoS 大于 0 的 PUBLISH 报文直至发送配额恢复。我们可以将其视为变种的令牌桶算法,它们之间的区别仅仅是增加配额的方式从以固定速率增加变成了按实际收到响应报文的速率增加。
这种算法能够更加积极和充分地利用资源,因为它没有在发送速率的层面上进行限制,发送速率完全取决于对端的响应速率和网络情况,如果接收端空闲且网络良好,那么发送端可以得到比较高的发送速率,反之则会被限制到一个比较低的发送速率上。
为了支持流量控制,MQTT v5 新增了一个 Receive Maximum 属性,它存在于 CONNECT 报文与 CONNACK 报文,表示客户端或服务端愿意同时处理的 QoS 为 1 和 2 的 PUBLISH 报文最大数量,即对端可以使用的最大发送配额。如果接收端已收到但未发送响应的 QoS 大于 0 的 PUBLISH 报文数量超过 Receive Maximum 的值,接收端将断开连接避免受到更严重的影响。

 类似资料: