MQTT协议 几个重要的属性

MQTT 3.1.1 特性

MQTT协议其实还是挺简单的,从为数不多的项目中,简单的总结了下MQTT 3.1.1协议某些字段的特性。
MQTT 5.0的特性在 https://blog.csdn.net/mrpre/article/details/87267400 中介绍

1:will(遗言)

包括 Will topic 、will message 、 will Qos、will retain。
一个Client异常断开连接的时候或者Server处理失败的时候,Server会把Client的will信息,当做Publish处理,Publish的topic就是Will topic,消息就是will message。
will Qos 见下文的Qos,will retain见下文的retain。
如果Client发送了disconnect来断开连接,则Server就会清除will信息,不会把will当做Publish处理。

2: Retain

Retain 表示 Publish 的消息,会保留在 Broker上,一旦有其他新的连接上来,并且subscribe了对应的消息,会立刻Publish这个Retain的消息。且回复给订阅者的的这个Publish也会携带Retain标志位。

MQTT规范上说,这个功能,对于发布的消息是自己状态的话,就很有用。

由于Will消息中也携带retain,且Will消息本身会也当做Publish,所以Retain的效果也作用于will,也就是说携带Retain的Will消息会被Server保留,且对于新连接,同样也会尝试去publish(如果topic匹配)。

其次,Client可以多次通过发送Retain标志位的Publish,来更新Server保存的Publish消息,当然Server是保留client发送的所有的Retain消息的,而不是覆盖之前你的Retain,不过回复订阅者的是最新消息(这变成了 消息队列)。

Client可以通过发送Retain标志位的,且没有message的Publish,来告知Server删除这个Retain消息,注意,是清空所有该topic的消息。

Client可以通过发送Retain标志位的,Qos为0的Publish,来告知Server删除对应Topic的所有Retain消息,且保留当前这个消息为Retain的消息。

3:CleanSession

如果Connect 帧的CleanSession为0,则Server会查找保存上次该客户端连接过来的Session,session里面保存了之前Client携带的所有的订阅topic等,如果Server找到了session,会在Connect Ack中把session present置1,否则置0。换句话说,如果成功用老的会话,Client不需要重新订阅之前的Topic。
CleanSession的另一个好处就是Server保留了Qos信息,例如,假设Client上次收到Publish消息,但是还没来得及回复Publish ack或者Publish recvive就挂了,Server知道Client还没处理,会在Client第二次连接完成后立刻再次发送Publish消息。(前提是Client的CleanSession为1,且Server找到了Session)。

4:keep alive

Connect帧中携带这个,这个值是Client发送Ping request的间隔。Client保证keep alive时间之内都有帧,如果没有控制帧可发,就发Ping request,Server必须回复Ping response以表示自己是活着的。

5:Qos

主要分为订阅的Qos,表示的是订阅者期望的自己收到消息的级别,另一个是推送一方的Qos,表示推送方指示的该消息的级别。

换句话说,Qos代表了消息的重要性,订阅方认为的以及推送方认为的。所以,当消息推送的订阅方时3,使用的Qos是 min(订阅方Qos, 推送方Qos)

6:缺点

就是MQTT协议长度太小了,小到太适合嵌入式设备的运行了,小到太节省带宽,小到没有任何拓展字段,当我尝试在publish或者subscribe中加入一些私有信息时,没有找到任何可以允许添加的位置,最终以失败而告终。
注:在MQTT 5.0中已经解决 https://blog.csdn.net/mrpre/article/details/87267400

ACK没有错误标志位。 协议中没有定义publish或者subscribe失败时,对应的ack如何表示失败。单纯的不回复ack,会导致对端重传publish或者subscribe,或者对端进程hang住。
注:在MQTT 5.0中已经解决 https://blog.csdn.net/mrpre/article/details/87267400

分布式痛点也存在。MQTT作为一个轻量级的应用层协议,当分布式模式存在时,其实现就不再轻量级了,开源的Mosquitto是通过bridge方式进行分布式的,并不是很合理的方式。合理的方式就是MQTT server集群携带一个中心化存储,类似redis,用来保存session等信息,MQTT server来读取。但是这种RPC调用就复杂了,用C/C++实现非常耗时间。从各大云厂商公布的Iothub性能来看,也基本能猜到都是用JAVA实现的,而性能就差很多了。

待解决的疑问

当然,目前还有一些疑问,MQTT明明是基于TCP的,为何怕传输丢失然后要有重传的功能?我在协议中找到如下一句话:

Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. 
This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.

即使MQTT客户端是嵌入式设备,但是依赖的TCP总不是不可靠传输协议吧?

其次,我能想到所谓丢失,一般MQTT的模式是broker对应多个client,一个client publish消息,然后broker全权代理,收到消息这个推送消息后,broker会发送到匹配订阅topic的所有client,那么,即使对应的client在tcp层回复了ack,但是订阅者应用层没有read,即业务层没有处理,此时恰巧订阅者挂了(断电),这应该也算是丢失的情况吧,但是这种丢失,我个人觉得能解决的方法就是订阅者的cleansession为0,那么订阅者第二次连接(重启或者加电)的时候,broker会重发(前提是这个丢失的消息,Qos是1或者2,且第一次发时,client没有完成Qos 1或者2的握手)。

排除TCP层不可靠的原因,MQTT的丢失重传,岂不是和cleansession绑定在一起了?即Qos 1 和 2的效果,本质上需要结合cleansession为0来使用?

顺便吐槽一下,MQTT规范写的真是。。。怪不得进不了IEFT。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页