MQTT 控制报文类型
| 名字 | 值 | 报文流动方向 | 描述 |
|---|---|---|---|
| Reserved | 0 | 禁止 | 保留 |
| CONNECT | 1 | 客户端到服务端 | 客户端请求连接服务端 |
| CONNACK | 2 | 服务端到客户端 | 连接报文确认 |
| PUBLISH | 3 | 两个方向都允许 | 发布消息 |
| PUBACK | 4 | 两个方向都允许 | QoS 1 消息发布收到确认 |
| PUBREC | 5 | 两个方向都允许 | 发布收到(保证交付第一步) |
| PUBREL | 6 | 两个方向都允许 | 发布释放(保证交付第二步 ) |
| PUBCOMP | 7 | 两个方向都允许 | QoS 2 消息发布完成(保证交互第三步) |
| SUBSCRIBE | 8 | 客户端到服务端 | 客户端订阅请求 |
| SUBACK | 9 | 服务端到客户端 | 订阅请求报文确认 |
| UNSUBSCRIBE | 10 | 客户端到服务端 | 客户端取消订阅请求 |
| UNSUBACK | 11 | 服务端到客户端 | 取消订阅报文确认 |
| PINGREQ | 12 | 客户端到服务端 | 心跳请求 |
| PINGRESP | 13 | 服务端到客户端 | 心跳响应 |
| DISCONNECT | 14 | 客户端到服务端 | 客户端断开连接 |
| Reserved | 15 | 禁止 | 保留 |
QoS:发布消息的服务质量,即:保证消息传递的次数
Ø00:最多一次,即:<=1
Ø01:至少一次,即:>=1
Ø10:一次,即:=1
Ø11:预留
发布和订阅都可以指定QoS级别,pub中指定的QoS与服务器相关。
例如,当使用qos2时,有必要确保服务器只接收一次,而不是最终的订阅用户。虽然用户在sub中指定了QoS,但是接收到的消息可能不是具有指定QoS级别的消息,而是可能被降级的消息。
响应订阅而发出的消息的有效负载的QoS必须是原始发布消息的QoS和服务器授予的QoS中的最小值。
例如,sub qos2和pub qos0,服务器转发的消息是qos0级别的,这意味着sub可能接收到消息,也可能无法接收到消息。
另一个例子是sub qos0和pub qos2。此时,服务器转发的消息也是qos0级别,sub可能只接收一次消息,也可能不接收。
也就是说,服务器将只根据最低QoS级别pub和sub的QoS规则发送消息。
pub发布时指定的QOS是服务器肯定按此质量接收,但是最终订阅者不一定。
sub订阅时指定的QOS表示订阅者可以接收的最高消息等级,也可能收到更低等级的消息。
最后
以上就是开朗白昼最近收集整理的关于MQTT协议控制报文类型,发布/订阅 QOS 代表的含义MQTT 控制报文类型的全部内容,更多相关MQTT协议控制报文类型,发布/订阅内容请搜索靠谱客的其他文章。
本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
发表评论 取消回复