MQTT协议的初浅认识之通信级别和持久会话

背景

这是我最近了解MQTT协议的最后一部份内容了，MQTT协议里面的QOS和Keep Alive是两个比较重要的内容。QOS的设置，直接影响了订阅客户端与中间件之间的消息交互行为。而Keep Alive直接影响了客户端与中间件链接状态。

QOS

MQTT中QOS的三个级别：

• 0:最多一次传送 (只负责传送，发送事后就无论数据的传送状况)
• 1:至少一次传送 (确认数据交付)
• 2:正好一次传送 (保证数据交付成功)

QOS 0

这种状况下面，中间件接收发布者的推送消息后，不会给发布者响应任何消息，也就是说消息推送出去，就无论消息有没有订阅者被收到了。

QOS 1

QoS级别1保证消息至少一次传递给订阅者。 发送者存储消息，直到它从订阅者得到确认收到消息的PUBACK数据包。 能够屡次发送或传递消息。也就是说每次推送一个消息，必定会收到一个订阅者确认收到的PUBACK消息，若是中间件没有收到PUBACK确认消息，中间件就会一直给订阅发消息，直到订阅者响应PUBACK确认消息。

QOS 2

QoS 2是MQTT中的最高级别。 此级别保证每一个消息仅由预期订阅者接收一次。 QoS 2是最安全和最慢的QOS水平。 保证由发布者和订阅者之间的至少两个请求/响应流（四个握手）提供。 发布者和订阅者使用原始PUBLISH消息的包标识符来协调消息的传送。

当订阅者从发布者得到QoS 2 PUBLISH数据包时，它会相应地处理发布消息，并使用PUBREC数据包回复发布者。 若是发布者没有从订阅者得到PUBREC数据包，它会再次发布带有重复（DUP）标志的PUBLISH数据包，直到收到确认。

一旦发布者从订阅者接收到PUBREC数据包，发送方就能够安全地丢弃初始PUBLISH数据包。 发布者存储来自订阅者的PUBREC数据包，并以PUBREL数据包进行响应。

在订阅者得到PUBREL数据包以后，订阅者能够丢弃全部存储的状态，并用PUBCOMP数据包回答（当发布者收到PUBCOMP时也是如此）。 在订阅者完成处理并将PUBCOMP分组发布回发布者以前，订阅者存储对原始PUBLISH分组的分组标识符的引用。 此步骤对于避免第二次处理消息很是重要。 在发送者收到PUBCOMP数据包以后，已发布消息的数据包标识符可供重用。

当QoS 2流程完成时，双方都肯定消息已发送且发送者已确认交付。

若是数据包在途中丢失，则发送者有责任在合理的时间内从新传输消息。 若是发送者是MQTT客户机或MQTT中间件，则一样如此。 订阅者有责任相应地响应每条命令消息。

级别简单总结：

• QOS0：发送消息不可靠。
• QOS1：消息可靠，性能比QOS2好，但可能屡次收到消息，我选这个。
• QOS2：消息可靠，且只能收到一次消息，解决QOS1，可是，性能比QOS1差。

Keep Alive

这个参数很重要，这个影响到消息是否可以及时收到。当发送者与订阅者之间长时间没有收到消息，这个keep alive定义，订阅者与发布者之间能够忍受的时间。这个keep alive时间定义多长时间订阅客户端发PINGREQ消息给中间件的消息，中间件收到PINGREQ消息后，回应PINGRESP消息给订阅者客户端，通常60s。

总结

MQTT协议，咱们就告一段落了，建议你们能够本身阅读HiveMQ的MQTT Essentials Part1-10，十篇文章很容易理解。

参考：

MQTT

MQTT Essentials Part 6: Quality of Service 0, 1 & 2

MQTT Essentials Part 10: Keep Alive and Client Take-Over