背景
这是我最近了解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 Essentials Part 6: Quality of Service 0, 1 & 2
MQTT Essentials Part 10: Keep Alive and Client Take-Over
来源：oschina
链接：https://my.oschina.net/u/168875/blog/2120345