MQTT应用笔记

cleansession 与 Qos 的配置关系

1. cleanSession的语义

   cleanSession标志是MQTT协议中对一个消费者客户端建立TCP连接后是否关心之前状态的定义，与消息发送端的设置无关。具体语义如下： - cleanSession=true：消费者客户端再次上线时，将不再关心之前所有的订阅关系以及离线消息。（服务器不保存之前的topic历史关系和不存储离线消息，客户连接需要重新订阅topic且不会收到离线消息） - cleanSession=false：消费者客户端再次上线时，还需要处理之前的离线消息，而之前的订阅关系也会持续生效。（服务器会保存之前的topic订阅关系，客户端连接之后不需要重新订阅topic，且会收到离线消息）

2. cleanSession 与 Qos 配置的关系

QoS级别	cleanSession=true	cleanSession=false
QoS0	无离线消息，在线消息只尝试推一次。	无离线消息，在线消息只尝试推一次。
QoS1	无离线消息，在线消息保证可达。	有离线消息，所有消息保证可达。
QoS2	无离线消息，在线消息保证只推一次。	有离线消息，所有消息保证只推一次。（也需要服务器支持该功能才有效）

发布、订阅消息不同 Qos 配置的作用、交互流程及其特点

1. 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

2. 不同 Qos 消息在消息发布者、服务器、消息订阅者之间的交互流程

• Qos0 的交互流程

特点：

1. 没有重发机制，消息订阅者不一定能收到消息。

• Qos1的交互流程

特点：

1. 有重传机制，消息发送者PUBLISH消息之后，在特定时间之内没有收到 PUBACK 确认消息，就会触发重传。
2. 重传对象为 PUBLISH 报文，重传动作在发送端进行。
3. 一般重传有次数限制，比如腾讯云 iot 平台，3s 内没有收到ACK触发重传，重传次数最大为3次。
4. 由于有重传，在应用层有可能会收到重复消息，需要根据应用场景判断要不要增加消息去重处理。

• Qos2的交互流程

特点：

1. Qos2 不一定服务器都支持。
2. Qos2 发送消息，发送端和接收端需要个发两次报文才完成整个流程，共4次报文传输，流程更复杂，开销相对较大。
3. 重传动作发生在消息发送端，重传对象有 PUBLISH 报文和 PUBREL 报文。
4. 虽然有重传，但是应用层不会收到重复消息。

搭建 mqtt 测试服务器

• 搭建 emqx

推荐使用 docker 的方式，部署简单，一条命令搞定。

docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:latest

扫码关注