mqtt协议qos,retain,dup,cleanSession,will的简单理解和应用

前言

搞过物联网开发的同学们肯定都知道mqtt协议,对于简单的应用大家很快就能上手做出来一些东西,稍微深入一点去了解的时候就会发现根本没有想象的那么简单,能查到的资料基本都晦涩难懂,下面简单讨论一下协议中的qos,retain,dup,cleanSession,will的基本概念和应用.
以下代码部分全都是js实现的.
参考文章:
规范部分:协议规范
qos讲解:qos详细讲解

qos

基本概念就不说了,详细的内容如上面的链接文章,务必要知道的是:
1.qos>0并不是表示sub方在任何状态下最终都能收到消息,qos>0只能保证pub方或sub方与broker的通讯是成功的.所以即便配置了qos>0,sub方在离线时错过的消息是收不到的.除非配置cleanSession.(下面会详细说)
2.qos在pub和sub时都是可以配置的,同一个主题下消息是根据级别比较低的一方执行的,例如pub时是qos1,但sub时是qos0,消息是不能保证送达的.

下图是pub方在qos0时发送的报文,只有2帧上行,不需要broker回复确认

下图是pub方在qos1时发送的报文,2帧上行,broker回复一帧确认

下图是pub方在qos2时发送的报文,要进行2个来回的确认,机制相当复杂,以我的智商是理解不了了…
不论是client端还是broker端的性能开销就会大大增加,并且有些broker端还不能够支持qos2.

retain

retain消息可以在sub方离线时保存,重新上线订阅后既能收到retain消息,但broker端每个主题下只能保存一条retain消息,如果你pub的消息都携带retain标志,broker端就会不停的覆盖,只保留最后一条.
应用的场合:你希望sub方订阅成功后立马执行的控制命令
使用的库:mqtt.js

client.publish("changeColor", "R", {qos: 0,retain: true})

dup

重复消息的标志,应该是库能够自动完成的机制,也可以手动修改

client.publish("changeColor", "R", {qos: 0,retain: true,dup: true})

sub方接受到的packet里dup标识就会变成true,但规范里明确的说此标志不能做为判断重复消息的依据,所以感觉没什么用处…

cleanSession

此项配置是client端在初始化时传入的参数

const client  = mqtt.connect('mqtt://127.0.0.1', {clean: false})

每个库的名字可能不一样.
broker端其实并不是靠clientId区别client端的,实际上还是靠session,broker端如果没有持久化到数据库中,重新启动以后session会全部丢失.
此配置项如果改为true,client端每次重连都会重新申请session,broker端就不能够判断出此设备是以前已经连接过的设备了.
如果配置为false,client端在上线并订阅主题后,broker会查找设备在离线时没有接收到的消息,一股脑全发出去,而这些消息很可能早就没有价值了.
当你刚启动client端就收到一堆消息,并且并没有pub消息时,很有可能就是此项配置的问题.
当然如果业务需要离线消息也能接收到可以配置此项.但具体broker端保存多久我也不知道…

will

这个很容易理解,client端在断开连接时broker端会发送的一个主题包.
client端初始化时配置

详细配置与其他pub方配置一致
应用场景: 例如记录设备的最后在线时刻