cleansession 与 Qos 的配置关系
cleanSession的语义
cleanSession标志是MQTT协议中对一个消费者客户端建立TCP连接后是否关心之前状态的定义,与消息发送端的设置无关。具体语义如下: - cleanSession=true:消费者客户端再次上线时,将不再关心之前所有的订阅关系以及离线消息。(服务器不保存之前的topic历史关系和不存储离线消息,客户连接需要重新订阅topic且不会收到离线消息) - cleanSession=false:消费者客户端再次上线时,还需要处理之前的离线消息,而之前的订阅关系也会持续生效。(服务器会保存之前的topic订阅关系,客户端连接之后不需要重新订阅topic,且会收到离线消息)
cleanSession 与 Qos 配置的关系
QoS级别 | cleanSession=true | cleanSession=false |
---|---|---|
QoS0 | 无离线消息,在线消息只尝试推一次。 | 无离线消息,在线消息只尝试推一次。 |
QoS1 | 无离线消息,在线消息保证可达。 | 有离线消息,所有消息保证可达。 |
QoS2 | 无离线消息,在线消息保证只推一次。 | 有离线消息,所有消息保证只推一次。(也需要服务器支持该功能才有效) |
发布、订阅消息不同 Qos 配置的作用、交互流程及其特点
- mqtt 消息发布者和消息订阅者之间的 Qos 配置关系
MQTT发布消息QoS保证不是端到端的,是客户端与服务器之间的。订阅者收到MQTT消息的QoS级别,最终取决于发布消息的QoS和主题订阅的QoS。
发布消息的 QoS | 主题订阅的 QoS | 接收消息的 QoS |
---|---|---|
0 | 0 | 0 |
0 | 1 | 0 |
0 | 2 | 0 |
1 | 0 | 0 |
1 | 1 | 1 |
1 | 2 | 1 |
2 | 0 | 0 |
2 | 1 | 1 |
2 | 2 | 2 |
- 不同 Qos 消息在消息发布者、服务器、消息订阅者之间的交互流程
- Qos0 的交互流程
特点:
- 没有重发机制,消息订阅者不一定能收到消息。
- Qos1的交互流程
特点:
- 有重传机制,消息发送者PUBLISH消息之后,在特定时间之内没有收到 PUBACK 确认消息,就会触发重传。
- 重传对象为 PUBLISH 报文,重传动作在发送端进行。
- 一般重传有次数限制,比如腾讯云 iot 平台,3s 内没有收到ACK触发重传,重传次数最大为3次。
- 由于有重传,在应用层有可能会收到重复消息,需要根据应用场景判断要不要增加消息去重处理。
- Qos2的交互流程
特点:
- Qos2 不一定服务器都支持。
- Qos2 发送消息,发送端和接收端需要个发两次报文才完成整个流程,共4次报文传输,流程更复杂,开销相对较大。
- 重传动作发生在消息发送端,重传对象有 PUBLISH 报文和 PUBREL 报文。
- 虽然有重传,但是应用层不会收到重复消息。
搭建 mqtt 测试服务器
- 搭建 emqx
推荐使用 docker 的方式,部署简单,一条命令搞定。
|
|