电脑网站生成手机网站,外贸圈海关数据,dnf怎么做提卡网站,网站商城支付接口1、QoS介绍
1.1、QoS简介
使用MQTT协议的设备大部分都是运行在网络受限的环境下#xff0c;而只依靠底层的TCP传输协议#xff0c;并不
能完全保证消息的可靠到达。
MQTT提供了QoS机制#xff0c;其核心是设计了多种消息交互机制来提供不同的服务质量#xff0c;来满足…1、QoS介绍
1.1、QoS简介
使用MQTT协议的设备大部分都是运行在网络受限的环境下而只依靠底层的TCP传输协议并不
能完全保证消息的可靠到达。
MQTT提供了QoS机制其核心是设计了多种消息交互机制来提供不同的服务质量来满足用
户在各种场景下对消息可靠性的要求。
MQTT 定义了三个 QoS 等级分别为
1、QoS 0最多交付一次 ----- 可能丢失消息
2、QoS 1至少交付一次 ----- 可以保证收到消息但消息可能重复
3、QoS 2只交付一次 ----- 可以保证消息既不丢失也不重复
QoS等级是由发布者在PUBLISH报文中指定的大部分情况下Broker向订阅者转发消息时都会维
持原始的 QoS 不变。不过也有一些例外的情况根据订阅者的订阅要求
消息的 QoS 等级可能会在转发的时候发生降级。
例如订阅者在订阅时要求Broker可以向其转发的消息的最大QoS等级为QoS 1那么后续所有
QoS 2消息都会降级至QoS 1转发给此订阅者而所有QoS 0和QoS 1消息
则会保持原始的QoS等级转发。 1.2、QoS 0原理介绍
1.2.1、通讯原理说明
QoS 0 是最低的 QoS 等级。QoS 0 消息即发即弃不需要等待确认不需要存储和重传因此对
于接收方来说永远都不需要担心收到重复的消息。 涉及到的相关报文 1.2.2、Qos 0消息丢失原因
当我们使用 QoS 0 传递消息时消息的可靠性完全依赖于底层的 TCP 协议。而 TCP 只能保证在
连接稳定不关闭的情况下消息的可靠到达一旦出现连接关闭、重置
仍有可能丢失当前处于网络链路或操作系统底层缓冲区中的消息。这也是 QoS 0 消息最主要的丢
失场景。
1.3、Qos 1原理介绍
1.3.1、通讯原理说明
为了保证消息到达QoS 1 加入了应答与重传机制发送方只有在收到接收方的 PUBACK 报文以
后才能认为消息投递成功在此之前发送方需要存储该 PUBLISH 报文以便下次重传。 QoS 1需要在 PUBLISH 报文中设置 Packet ID而作为响应的 PUBACK 报文则会使用与
PUBLISH 报文相同的 Packet ID以便发送方收到后删除正确PUBLISH报文缓存。
涉及到的相关报文 1.3.2、Qos 1消息会重复原因
对于发送方来说没收到 PUBACK 报文分为以下两种情况
1、PUBLISH 未到达接收方
2、PUBLISH 已经到达接收方接收方的 PUBACK 报文还未到达发送方
在第一种情况下发送方虽然重传了 PUBLISH 报文但是对于接收方来说实际上仍然仅收到了
一次消息。
在第二种情况下在发送方重传时接收方已经收到过了这个 PUBLISH 报文这就导致接收方将
收到重复的消息。 重传 PUBLISH 报文的时候PUBLISH 中的 DUP 标志会被设置为 1用以表示这是一个重传的报
文。
1.4、Qos 2原理介绍
1.4.1、通讯原理说明
QoS 2 解决了 QoS 0、1 消息可能丢失或者重复的问题但相应地它也带来了最复杂的交互流程
和最高的开销。每一次的 QoS 2 消息投递都要求发送方与接收方进行至少两次请求/响应流
程。 流程说明
1、首先发送方存储并发送 QoS 为 2 的 PUBLISH 报文以启动一次 QoS 2 消息的传输然后等
待接收方回复 PUBREC 报文。这一部分与 QoS 1 基本一致只是响应报文从 PUBACK 变成了
PUBREC。
2、当发送方收到 PUBREC 报文即可确认对端已经收到了 PUBLISH 报文发送方将不再需要重
传这个报文并且也不能再重传这个报文。所以此时发送方可以删除本地1存储的 PUBLISH 报
文然后发送一个 PUBREL 报文通知对端自己准备将本次使用的 Packet ID 标记为可用了。与
PUBLISH 报文一样我们需要确保 PUBREL报文到达对端所以也需要一个响应报文并且这个
PUBREL 报文需要被存储下来以便后续重传。
3、当接收方收到 PUBREL 报文也可以确认在这一次的传输流程中不会再有重传的 PUBLISH 报
文到达因此回复 PUBCOMP 报文表示自己也准备好将当前的 PacketID 用于新的消息了。
4、当发送方收到 PUBCOMP 报文这一次的 QoS 2 消息传输就算正式完成了。在这之后发送
方可以再次使用当前的 Packet ID 发送新的消息而接收方再次收到使用这个 Packet ID 的
PUBLISH 报文时也会将它视为一个全新的消息。
涉及到的报文 1.4.2、Qos 2消息不会重复原因
消息不丢失原因与 QoS 1 相同
消息不会重复原因
快速回顾一下 QoS 1 消息无法避免重复的原因
当我们使用 QoS 1 消息时对接收方来说回复完 PUBACK 这个响应报文以后 Packet ID 就重新
可用了也不管响应是否确实已经到达了发送方。所以就无法得知之后到达的携带了相同
Packet ID 的 PUBLISH 报文到底是发送方因为没有收到响应而重传的还是发送方因为收到了
响应所以重新使用了这个 Packet ID 发送了一个全新的消息。 所以消息去重的关键就在于通信双方如何正确地同步释放 Packet ID换句话说不管发送方
是重传消息还是发布新消息一定是和对端达成共识了的。而 QoS 2中增加的 PUBREL 流程正
是提供了帮助通信双方协商 Packet ID 何时可以重用的能力。 QoS 2 规定发送方只有在收到 PUBREC 报文之前可以重传 PUBLISH 报文。一旦收到 PUBREC 报
文并发出 PUBREL 报文发送方就进入了 Packet ID 释放流程不可以再使用当前 Packet ID 重
传 PUBLISH 报文。同时在收到对端回复的 PUBCOMP 报文确认双方都完成 Packet ID 释放之
前也不可以使用当前Packet ID 发送新的消息。 因此对于接收方来说能够以 PUBREL 报文为界限凡是在 PUBREL 报文之前到达的
PUBLISH 报文都必然是重复的消息而凡是在 PUBREL 报文之后到达的
PUBLISH 报文都必然是全新的消息。一旦有了这个前提我们就能够在协议层面完成 QoS 2 消
息的去重。
