MQTT——发布报文

发布报文的知识点并不难，只是多。看过前面几章的读者们应该或多或少都认识服务质量QOS。发布报文跟他的联系最紧的。咱们也清楚订阅报文里面虽然也有用到QOS，可是他却没有更进一步的联系。往下看就知道是什么一会事了。

服务质量QOS

不论是订阅报文仍是发布报文都会遇到一个问题——报文流失的问题。因此才会有了服务质量这一说法(我的见解)。什么意思呢？就是用来处理流失的问题。即然报文在发送的过程当中可能存在流失的问题。那么最直接的决解方案就是从新发送，不就好了吗。因此服务质量事实就是在表示报文要分送几回。QOS有三个值。分别表示着三种不一样的处理报文方式。相应的值以下

QOS 0：最多分发一次。便是能够零次或是一次。不过笔者认零次的状况大多数是不可能存在的。一次到很常见。

QOS 1：至少分发一次。

QOS 2：只分发一次。

笔者在看MQTT协议文档的时候，对于QOS的分发一直有一个小问题。笔者觉得是指客户端到客户端的分发。不过看了几遍以为他是指客户端到服务端的分发。那么为何笔者会认为是客户端到客户端的分发呢？主要是笔者认为QOS是指报文到客户端的次数。好比QOS 1说明分送到每个符合客户端的报文至少一次。因此才会有至少分送一次的说法。原来一开始笔者理解错了。因此请记住这里服务质量QOS是指客户端与服务端的分发。所谓的分发- 次，至少一次，更不是指报文到客户端的次数。

若是分发是客户端到服务端的话。假设服务端收到了QOS 1的报文。那么服务端就会回发一个响应表示收到，QOS 1的处理就这样子结束了。而服务端还要把这个报文发送到别的符合的客户端。这个时候仍是存在的报文流失的问题。大家也清楚网络有时候就是这样子。固然这个可能笔者多虑了。可是服务质量QOS就是把相关的报文不停的重发。那么对于重数的次数MQTT确定不可能不作一些记录。因此固定报头的DUP做用就出来了。重发一次就把DUP加1。下面笔者会细说。

服务质量QOS 0 笔者喜欢用一词来形客。管杀无论埋。发出去以后。收不收的到无论了。固然笔者说的有一点过头了。这里是指客户端向服务端发送发布报文，只要服务端接收到了。那么客户端就在也无论了。

服务质量QOS 1的要求是至少分发一次。若是失败的话就一直重复分发。笔者先把流程写出来。而后加一张图来加深理解。

1）客户端向服务端发起一个发布报文。若是服务端没有接到。请你继续起发不用客气。

2）服务端收到一个来看客户端的发布报文。查看一下原来是服务质量QOS为1的报文。服务端就必须回发一个叫发布确认(PUBACK)的报文。而这个时候客户端也在等待着服务端的回应（好了故事就从这里开始了）。

3）客户端等了一段时间就是没有接到来自服务端的回应，没有办法客户端只能认为失败了。在重发一次吧。这个时候客户端就必须把固定报头里面的DUP加1了。可是服务端事实上没有问题，而且开始给符合主题的客户端们发分信息了。只是可能这一段时间正在处理一些事情，回应慢了。

4）客户端终于接收到了回应（PUBACK）。结束了。

 

注意：图片中的红线就是一个重发的环。

从上面的流程咱们就能够看出来一个问题，服务端有可能收到屡次的发布报文。那么当服务端在次接收到DUP大于0的报文，无论他，当前普通的报文同样了处理。一样子也要给客户端一个回应，否则他又要重发了。那么这就意味着服务端要处理相同的发布报文问题。惋惜文档里面要求看成正常的报文来处理就好了。便是不论是不是重发的报文，只要接到报文而且他的QOS大于0，那么给对应的客户端一个回应。同时给符合主题的客户端们分发报文。显然客户端们会接收到多个相同的信息了。

服务质量QOS 2表示只分发一次。 笔者在看文档MQTT 3.1里面的QOS2 处理时候，有一点不理解。后来在去看一下MQTT 3.1.1果真写的清楚一点了。否则笔者觉得跟服务质量QOS 1没有什么区别。让咱们看一下他是什么处理才只分一次呢？

1）客户端向服务端发起一个发布报文。若是服务端没有接到。请你继续起发不用客气。

2）服务端收到一个来看客户端的发布报文。查看一下原来是服务质量QOS为2的报文。服务端处理相关操做以后，就回应一个叫PUBREC 的报文。若是是服务质量QOS 1的话，这个时候会给符合的客户端们发送信息。那么服务质量QOS 2这边要不要这个时候给符合主题的客户端们发送信息呢？固然这一点档文也没有特别指出来。因此笔者认为应该是能够的。同时服务端还要等待来自客户端的一个叫PUBREL的报文呢？

3）客户端在一段时间以后，若是没有收到相关回应的话，重发一次，同时DUP加1。直到接收到回应(PUBREC)。

4）当前客户端接收到了来自服务端的回应(PUBREC)。客户端就必须在回头跟服务端说一声：“我收到你的回应了”。由于服务端一直在等客户端的回应，便是PUBREL报文。若是客户端一直不给服务端回发一个回应，表示客户端已经收到回应。服务端会一直重发PUBREC。这个时候DUP有没有加1。文档里面没有说明。因此应该是不须要。直到服务端接收到客户端的回应(PUBREL)。在笔者内心面这里才是给符合主题的客户端们发送信息的时候。

5）客户端在给服务端发送PUBREL报文，说明我收到了你的回应了。同时客户端又在等待服务端的另外一个回应。告诉客户端动做结束了。便是PUBCOMP报文。

6）客户端收到来自服务端的PUBCOMP报文响应。结束了。

注意：图片中的红线就是一个重发的环。

理论上来说服务质量QOS 2的安全等级绝对高于服务质量QOS 1。关是步棸QOS 2就比QOS1多了二步。并且这二步都是一个重发的环。图片中咱们能够看到。但是若是细想一下，笔者内心面有一点不理解。所谓的至少分一次，只分发一次好像并无体现出来。如QOS 2里面客户端没有接到PUBREC的报文时候，不是仍是要重发一下发布报文。那么因此只分发一次。理解上就有一点怪怪的。笔者也想过可能QOS 2会根据消息ID特别处理报文，让同一个报文只处理一次。否则的话，不是仍是会出现QOS 1那样子客户端们可能会收到重复的信息。但是笔者在MQTT 文档里面没有找到。这一点读者们自行去查看吧。

不论是QOS 1仍是QOS 2。最后都要给符合主题的客户端发送信息。那么关键点是在何时发送。虽然文档里面有指出能够在PUBACK或是PUBREC以后就能够给符合主题的客户端发送信息。总之笔者没有找到特别指出的地方。因此大部分都是网络说的。QOS 1在PUBACK发出以后就能够发送给客户端信息。QOS 2在服务端接受PUBREL以后发送给客户端信息。固然读者们也能够自行选择吧。

发布报文结构

发布报文的格式比较单简。即然是发布报文那么主题和发布的内容是必定少了的。因此相对于别他报文来说，发布报文对固定报头，可变报头，还有有效载荷都有须要。固定报头笔者就不用多讲了。把官方的列表拿过来你们本身看。就是那几个经常使用的信息。以下

看列表就是他的固定报头的二进制是00110000或是00110010或是00110100。分别对应QOS 0,QOS 1,QOS2。

可变报头里面存放了俩个信息对服务端来说很重要。一个是主题，一个是消息ID。除了这俩个没有别的了。以下

官方的列表第一次看时候是有一点看不懂。特别是byte1,byte2是什么。若是看不懂他也没有事。你只要明白这些是组成元素就能够了。如上面列表的主题是“a/b”。有三个元素组成的。后面就是每个元素对应的二进制。而LSB和MSB前面讲过了。

有效载荷就是存放就是发布的内容了。略过。

这一部分的代码笔者就不写了。由于笔者比较赖。只要上章读者们有去实现把相关订阅的主题保留住的话，那么发布报文的时候，只要从保留的主题中找到符合的。而后过通主题的信息找到对应的客户端链接。在发送信息就好了。可是必定要记得服务质量的要求。笔者这里只分析包的结构。以下

服务质量QOS 0的发布报文包

图片上笔者已经标出来相关的内容。分别为不一样的颜色。咱们知道服务质量QOS 0是没有回应的。因此只是单向的发送。比较简单。可是有一点要记得他好像没有消息ID。

服务质量QOS 1的发布报文包

咱们能够看到跟QOS 0没有什么区别。主要是有了消息ID。但很重要。

服务质量QOS 1的发布报文肯定（PUBACK）包

咱们发现他没有有效载荷。除了固定报头以外，就是可变报头，同时只有一个消息ID。并且跟上面的发布报文的消息ID是相同的。

服务质量QOS 2的发布报文包

 

服务质量QOS 2的发布肯定包（PUBREC）

相同的消息ID,没有有效载荷

服务质量QOS 2的发布肯定包（PUBREL）

相同的消息ID,没有有效载荷

服务质量QOS 2的发布肯定包（PUBCOMP）

相同的消息ID,没有有效载荷