MQTT是什么？
MQTT协议全称是（Message Queuing Telemetry Transport），即消息队列遥测传输协议。
是一种基于发布/订阅（Publish/Subscribe）模式的轻量级通讯协议，并且该协议构建于TCP/IP协议之上，我们知道TCP协议本身就具有高可靠性的特点，因此基于其上的MQTT协议同样也是具有高可靠、低开销的特点，之以是低开销，是以为MQTT协议传输的最小的报文也只有两个字节。
在物联网开发中，MQTT不是唯一的选择，与MQTT互相竞争的协议有XMPP和CoAP协议等。
关于发布和订阅的概念我们拿抖音平台来举个例子，我们每一个用户就都是一个客户端，而抖音就是MQTT协议中的服务器，当我们（用户一）关注某一个视频发布者（用户二）时，这样一个关注的举动就可以理解为订阅；同时用户二也可以关注你，那么这就是相互订阅。当用户二发布作品的时候，这个作品是发布到了抖音平台，也就是我们现在的服务器，这个过程就是消息的发布。
在这里需要留意的是：用户二（客户端）发布的消息并不是直接发布给了用户一，而是发布到了抖音平台（服务器），由于用户一订阅了用户二的消息（相当于点了关注），以是抖音平台（服务器）就会向用户一推送这个消息(留意发布和推送的区别)。这就是MQTT协议订阅&发布的一个简朴比喻。
上面是一个比喻，再来对比一下实际的MQTT协议通信模型：
实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。
MQTT传输的消息分为：主题（Topic）和负载（payload）两部分
- Topic，可以理解为消息的范例，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）
- payload，可以理解为消息的内容，是指订阅者具体要使用的内容
一些术语解释
网络毗连 Network Connection
MQTT 使用的底层传输协议(TCP)根本设施。
- 客户端使用它毗连服务端。
- 它提供有序的、可靠的、双向字节传播输。
应用消息 Application Message
MQTT 协议通过网络传输应用数据。应用消息通过 MQTT 传输时，它们有关联的服务质量（QoS） 和主题（Topic） 。
客户端 Client
使用 MQTT 的程序或装备。客户端总是通过网络毗连到服务端。它可以
- 发布应用消息给其它相干的客户端。
- 订阅以请求接受相干的应用消息
- 取消订阅以移除接受应用消息的请求。
- 从服务端断开毗连。
服务端 Server
一个程序或装备，作为发送消息的客户端和请求订阅的客户端之间的中介。服务端
- 接受来自客户端的网络毗连。
- 接受客户端发布的应用消息。
- 处置惩罚客户端的订阅和取消订阅请求。
- 转发应用消息给符合条件的已订阅客户端。
订阅 Subscription
订阅包含一个主题过滤器（Topic Filter）和一个最大的服务质量（QoS）等级。订阅与单个会话（Session）关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个差别的主题过滤器。
主题名 Topic Name
附加在应用消息上的一个标签，服务端已知且与订阅匹配。服务端发送应用消息的一个副本给每一个匹配的客户端订阅。
主题过滤器 Topic Filter
订阅中包含的一个表达式，用于表现相干的一个或多个主题。主题过滤器可以使用通配符。
会话 Session
客户端和服务端之间的状态交互。一些会话持续时长与网络毗连一样，另一些可以在客户端和服务端的多个连续网络毗连间扩展。
控制报文 MQTT Control Packet
通过网络毗连发送的信息数据包。MQTT规范定义了十四种差别范例的控制报文，其中一个（PUBLISH报文） 用于传输应用消息。
MQTT特点
1.客户端使用它毗连服务端。
2.它提供有序的、可靠的、双向字节传播输。
3.使用发布/订阅消息模式，提供了一对多的消息分发和应用之间的解耦。
4.消息传输不需要知道负载内容。
5.提供三种等级的服务质量QoS ：
6.很小的传输消耗和协议数据互换，最大限度减少网络流量
7.异常毗连断开发生时，能关照到相干各方。
消息质量（QoS）
MQTT消息质量有三个等级，QoS 0，QoS 1和 QoS 2。
QoS 0：最多分发一次。消息的传递完全依赖底层的TCP/IP网络，协议里没有定义应答和重试，消息要么只会到达服务端一次，要么根本没有到达。消息大概会丢失。例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，由于不久之后会再次发送。
QoS 1：至少分发一次。服务器的消息吸取由PUBACK消息进行确认，如果通信链路或发送装备异常，或者指定时间内没有收到确认消息，发送端会重发这条在消息头中设置了DUP位的消息。(保证交付功能)
QoS 2：只分发一次。这是最高级别的消息传递，消息丢失和重复都是不可接受的，使用这个服务质量等级会有额外的开销。例如，这个等级可用在一个计费系统中，这里如果消息重复或丢失会导致不正确的收费。
eg.
目前流行的共享单车智能锁，智能锁可以定时使用QoS level 0质量消息请求服务器，发送单车的当前位置，如果服务器充公到也没关系，反正过一段时间又会再发送一次。之后用户可以通过App查询周围单车位置，找到单车后需要进行解锁，这时候可以使用QoS level 1质量消息，手机App不停的发送解锁消息给单车锁，确保有一次消息能达到以解锁单车。最后用户用完单车后，需要提交付款表单，可以使用QoS level 2质量消息，这样确保只传递一次数据，否则用户就会多付钱了。
MQTT控制报文格式
MQTT 控制报文的结构
Fixed header固定报头，所有控制报文都包含Variable header可变报头，部分控制报文包含Payload有用载荷，部分控制报文包含 注：固定报头必须有，可变报头和有用负载可以没有。
【固定报头】：第一个字节高4位是MQTT控制报文的范例 + 第一个字节低4位用于指定控制报文范例的标志位(只在PUBLISH发布消息时用到) + 剩余长度1~4个字节(剩余长度字段最大4个字节)
剩余长度包罗可变报头和负载的数据。
剩余长度不包罗用于编码剩余长度字段本身的字节数。
剩余长度字段使用一个变长度编码方案，对小于 128 的值它使用单字节编码。更大的值按下面的方式处置惩罚。
低 7 位有用位用于编码数据，最高有用位用于指示是否有更多的字节。因此每个字节可以编码 128 个数值和一个延续位（continuation bit） 。
剩余长度字段最大4个字节。
【可变报头】：可变报头的内容根据报文范例的差别而差别。
某些MQTT控制报文包含一个可变报头部分。它在固定报头和负载之间。可变报头的报文标识符（Packet Identifier） 字段存在于在多个范例的报文里。
报文标志符(2字节)：包含报文标识符的9个控制报文有：PUBLISH(QoS>0),PUBACK ,PUBREC ,PUBREL ,PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK
报文标志符的留意项：
1.客户端和服务端相互独立地分配报文标识符。因此，客户端服务端组合使用相同的报文标识符可以实现并发的消息互换。
2. SUBSCRIBE，UNSUBSCRIBE 和 PUBLISH（QoS 大于 0）控制报文 必须包含一个非零的 16 位报文标识符（Packet Identifier）
3. 客户端每次发送一个新的这些范例的报文时都必须分配一个当前未使用的报文标识符。如果一个客户端要重发这个特别的控制报文，在随后重发谁人报文时，它必须使用相同的标识符。当客户端处置惩罚完这个报文对应的确认后，这个报文标识符就开释可重用。
4. QoS 设置为 0 的 PUBLISH 报文 不能包含报文标识符。
5.PUBACK, PUBREC, PUBREL 报文 必须包含与最初发送的 PUBLISH 报文相同的报文标识符。雷同地，SUBACK 和 UNSUBACK 必须包含在对应的 SUBSCRIBE 和 UNSUBSCRIBE 报文中使用的报文标识符。
6. 作用：基于标志位来决定可变报头中是否需要包含这些字段
【有用载荷】：某些 MQTT 控制报文在报文的最后部分包含一个有用载荷，例如对于 PUBLISH 来说有用载荷就是应用消息。
大概包含有用载荷的控制报文有：CONNECT,PUBLISH,SUBSCRIBE,SUBACK,UNSUBSCRIBE
十四种控制报文
注：C->S指的是客户端到服务端，S->C指的是服务端到客户端，C<->S指的是两个方向都允许
0和15范例值保存无效。
表格中的值指的是固定报头第一个字节的高4位即MQTT控制报文的范例的值
PUBREC和PUBREL和PUBCOMP只有在QoS2等级时才存在
1号控制报文：CONNECT – 毗连到服务端
注:客户端到服务端的网络毗连创建后，客户端发送给服务端的第一个报文 必须是 CONNECT 报文
在一个网络毗连上，客户端只能发送一次 CONNECT 报文。服务端 必须将客户端发送的第二个 CONNECT报文当作协议违规处置惩罚并断开客户端的毗连。
CONNECT 报文的可变报头按下列次序包含四个字段：协议名（Protocol Name），协议级别（Protocol Level），毗连标志（Connect Flags）和保持毗连（Keep Alive）
注：客户端用 8 位的无符号值表现协议的修订版本。对于 3.1.1 版协议，协议级别字段的值是 4(0x04)。如果发
现不支持的协议级别，服务端 必须给客户端发送一个返回码为 0x01（不支持的协议级别）的 CONNACK报文相应CONNECT 报文，然后断开客户端的毗连
注：毗连标志字节包含一些用于指定 MQTT 毗连举动的参数。它还指出有用载荷中的字段是否存在。此毗连标志将预示后面有用载荷的内容
注：服务端 必须验证 CONNECT 控制报文的保存标志位（第 0 位）是否为 0，如果不为 0 必须断开客户端毗连
CONNECT控制报文的内容：
固定报头 MQTT 4位报文范例加4位保存位即10 ，剩余长度字节由后续的数据长度决定
可变报头 固定协议名6字节 长度00 04 + MQTT UTF-8编码 00 04 4D 51 54 54
协议级别1字节 04 代表3.1.1 版协议
毗连标志1字节 C2 置位密码标志，用户名标志，清理会话标志
保持毗连时间2字节 00 78 代表120秒
有用载荷 客户端ID数据长度2字节 + 客户端ID ASC码 + 用户名数据长度2字节 + 用户名 ASC码 + 密码长度2字节 + 密码 ASC码
留意！CONNECT 报文的有用载荷（payload）包含一个或多个以长度为前缀的字段，可变报头中的毗连标志决定是否
包含这些字段。如果包含的话， 必须按这个次序出现：客户端标识符，遗嘱主题，遗嘱消息，用户名，密码
报文举例：
10 | 25 | 00 04 4D 51 54 54 | 04 | C2 | 00 78 | 00 09 35 32 38 39 38 36 38 37 35 | 00 06 32 34 38 34 39 33 | 00 06 6B 66 62 73 6B 64
固定报头0x10表现客户端请求毗连服务端
固定报头0x25表现可变报头和有用负载一共37个字节数据，本身不算在内
协议名00 04 4D 51 54 54 ，00 04表现4个字节 ，4D 51 54 54是MQTT 的 UTF-8 编码的字符串(也是ASC码值)
协议级别04客户端用 8 位的无符号值表现协议的修订版本。对于 3.1.1 版协议，协议级别字段的值是 4(0x04)
毗连标志C2
保持毗连 00 78 即120秒
00 09 35 32 38 39 38 36 38 37 35 装备ID ，9个字节，528986875的ASC码，以下相同
00 06 32 34 38 34 39 33 产品ID 248493
00 06 6B 66 62 73 6B 64 鉴权信息 kfbskd
2号控制报文：CONNACK – 确认毗连请求
留意:服务端发送 CONNACK 报文相应从客户端收到的 CONNECT 报文。服务端发送给客户端的第一个报文 必须是 CONNACK 报文
如果客户端在合理的时间内没有收到服务端的 CONNACK 报文，客户端 应该关闭网络毗连。合理的时间取决于应用的范例和通信根本设施。
CONNACK控制报文的内容：
固定报头 MQTT 4位报文范例加4位保存位即20 ，剩余长度字节由后续的数据长度决定
可变报头 两字节：毗连确认标志(前7位必须为0，最低位取决于毗连标志中的清理会话标志)+毗连返回码(正常为00，否则指示故障)
有用载荷 无
报文举例：
20 02 01 00
固定报头20 02：20标志报文范例2，02剩余长度
可变报头01 00
有用负载无
3号控制报文：PUBLISH – 发布消息
PUBLISH 控制报文是指从客户端向服务端或者服务端向客户端传输一个应用消息。
客户端使用 PUBLISH 报文发送应用消息给服务端，目的是分发到其它订阅匹配的客户端。
服务端使用 PUBLISH 报文发送应用消息给每一个订阅匹配的客户端。
报文内容组成：
固定报头 第一个字节高4位报文范例3 ，低4位分别是DUP重发标志-QoS等级高位-QoS等级低位-保存位，第2个字节开始是剩余长度
可变报头 可变报头按次序包含主题名(UTF-8编码)和报文标识符。主题名之前有两字节主题名的长度，报文标志符是两字节。
留意报文标志符只在QoS等级1和2的报文中有，等级0没有直接忽略
有用负载 有用载荷包含将被发布的应用消息。数据的内容和格式是应用特定的。长度计算是剩余长度-可变报头的长度
关于DUP重发标志：如果 DUP 标志被设置为 0，表现这是客户端或服务端第一次请求发送这个 PUBLISH 报文。如果 DUP 标志
被设置为 1，表现这大概是一个早前报文请求的重发。
客户端或服务端请求重发一个 PUBLISH 报文时， 必须将 DUP 标志设置为 1 。对于 QoS 0 的消息，DUP 标志 必须设置为 0 。
关于QoS等级标志位：PUBLISH 报文不能将QoS所有的位设置为 1。如果服务端或客户端收到QoS所有位都为1的 PUBLISH报文，它必须关闭网络毗连
关于保存位：如果客户端发给服务端的 PUBLISH 报文的保存（RETAIN）标志被设置为 1，服务端 必须存储这个应用消息和它的服务质量等级（QoS），以便它可以被分发给将来的主题名匹配的订阅者。
如果客户端发给服务端的 PUBLISH 报文的保存标志位 0，服务端 不能存储这个消息也 不能移除或替换任何现存的保存消息。
报文举例：
30 0E 00 09 6B 66 62 5F 74 6F 70 69 63 31 32 33 QoS等级0 数据：123，等级0没有回复
32 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 等级1 数据：123
34 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 等级2 数据：123
这里面的主题名称是kfb_topic： 6B 66 62 5F 74 6F 70 69 63，主题名之前有两字节主题名的长度00 09
报文标志符只在QoS等级1和2的报文中有，例子中报文标识符是00 01
4号控制报文：PUBACK – 发布确认
PUBACK 报文是对 QoS 1 等级的 PUBLISH 报文的相应。
报文内容组成:
固定报头 报文范例40+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有用负载 无
报文举例：
40 02 00 01 等级1的回复，表现签收
固定报头40 02：40标志报文范例4，02剩余长度
可变报头00 01 与等待确认的PUBLISH报文的报文标识符一致
有用负载无
5号控制报文：PUBREC – 发布收到（QoS 2 ，第一步）
PUBREC 报文是对 QoS 等级 2 的 PUBLISH 报文的相应。(通常由吸取方回复)它是 QoS 2 等级协议互换的第二个报文。
报文内容组成:
固定报头 报文范例50+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有用负载 无
报文举例：
50 02 00 01 等级2的第一次服务器的回复，等级2有两次回复，客户端再次发送62 02 00 01，得到服务器的二次回复70 02 00 01表现成功
固定报头50 02：40标志报文范例5，02剩余长度
可变报头00 01 与等待确认的PUBLISH报文的报文标识符一致
有用负载无
6号控制报文：PUBREL – 发布 开释（QoS 2 ，第二步）
PUBREL 报文是对 PUBREC 报文的相应。(通常是发送方发出)它是 QoS 2 等级协议互换的第三个报文。
留意！PUBREL 控制报文固定报头的第 3,2,1,0 位是保存位， 必须被设置为 0,0,1,0。服务端 必须将其它的任何值都当做是不正当的并关闭网络毗连。
报文内容组成：
固定报头 报文范例62+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有用负载 无
报文举例：
62 02 00 01 等级2 再次询问
7号控制报文：PUBCOMP – 发布 完成（QoS 2 ，第三步）
PUBCOMP 报文是对 PUBREL 报文的相应。(通常由吸取方回复)它是 QoS 2 等级协议互换的第四个也是最后一个报文。
报文内容组成：
固定报头 报文范例70+剩余长度02
可变报头 包含等待确认的 PUBLISH 报文的报文标识符两个字节。具体内容取决于之前的 PUBLISH 报文中的报文标志符。
有用负载 无
报文举例：
70 02 00 01 等级2的第二次回复，表现彻底完成
8号控制报文：SUBSCRIBE - 订阅主题
客户端向服务端发送 SUBSCRIBE 报文用于创建一个或多个订阅。
为了将应用消息转发给与那些订阅匹配的主题，服务端发送 PUBLISH 报文给客户端。
SUBSCRIBE报文也（为每个订阅）指定了最大的 QoS 等级，服务端根据这个发送应用消息给客户端。
报文内容组成:
固定报头 报文范例82+剩余长度
可变报头 报文标识符两个字节。
有用负载 主题过滤器长度两字节+主题过滤器(+【可包含多个】后一个主题过滤器长度两字节+主题过滤器+)服务质量等级1字节仅低两位有用
SUBSCRIBE 报文的有用载荷 必须包含至少一对主题过滤器 和 QoS 等级字段组合。
每一个过滤器后面跟着一个字节，这个字节被叫做服务质量要求（Requested QoS）。它给出了服务端向客户端发送应用消息所允许的最大 QoS 等级。
报文举例：
82 0E 00 0A 00 09 61 70 70 5F 74 6F 70 69 63 00 等级0
82 0E 00 0B 00 09 61 70 70 5F 74 6F 70 69 63 01 等级1
订阅的主题名为app_topic：61 70 70 5F 74 6F 70 69 63 ，前面的00 09是主题名长度
9号控制报文：SUBACK – 订阅确认
服务端发送 SUBACK 报文给客户端，用于确认它已收到并且正在处置惩罚 SUBSCRIBE 报文。
SUBACK 报文包含一个返回码清单，它们指定了 SUBSCRIBE 请求的每个订阅被授予的最大 QoS 等级。
报文内容组成:
固定报头 报文范例90+剩余长度
可变报头 可变报头包含等待确认的 SUBSCRIBE 报文的报文标识符。两个字节。
有用负载 针对上一个订阅主题报文的等级回复。字节数与上一个SUBSCRIBE报文中的主题过滤器数量相同。
有用载荷包含一个返回码清单。每个返回码对应等待确认的 SUBSCRIBE 报文中的一个主题过滤器。返回码的次序必须和 SUBSCRIBE 报文中主题过滤器的次序相同。
允许的返回码值：
0x00 - 最大 QoS 0
0x01 - 成功 – 最大 QoS 1
0x02 - 成功 – 最大 QoS 2
0x80 - Failure 失败
报文举例：
90 03 | 00 0A | 00 对应上面订阅第一条的报文标识符
90 03 | 00 0B | 01 对应上面订阅第二条的报文标识符
10号控制报文：UNSUBSCRIBE – 取消订阅
客户端发送 UNSUBSCRIBE 报文给服务端，用于取消订阅主题。
报文内容组成:
固定报头 报文范例A2+剩余长度
可变报头 可变报头包含一个报文标识符。两个字节。
有用负载 UNSUBSCRIBE 报文的有用载荷包含客户端想要取消订阅的主题过滤器列表。长度两字节+主题过滤器(+长度两字节+主题过滤器)
UNSUBSCRIBE 报文的有用载荷 必须至少包含一个消息过滤器。
报文举例：
A2 0D 00 0C 00 09 61 70 70 5F 74 6F 70 69 63
00 0C是报文标识符
主题名app_topic，即61 70 70 5F 74 6F 70 69 63，前面的00 09是长度
11号控制报文：UNSUBACK – 取消订阅确认
服务端 必须发送 UNSUBACK 报文相应客户端的 UNSUBSCRIBE 请求。UNSUBACK 报文 必须包含和UNSUBSCRIBE 报文相同的报文标识符
报文内容组成:
固定报头 报文范例B0+剩余长度02
可变报头 可变报头包含等待确认的 UNSUBSCRIBE 报文的报文标识符。两个字节。
有用负载 无
报文举例：
B0 02 00 0C
00 0C对应上一条取消订阅的报文标志符
12号控制报文：PINGREQ – 心跳请求
客户端发送 PINGREQ 报文给服务端的。用于：
- 在没有任何其它控制报文从客户端发给服务的时，告知服务端客户端还在世。
- 请求服务端发送 相应确认它还在世。
- 使用网络以确认网络毗连没有断开。
报文内容组成:
固定报头 报文范例C0+剩余长度00
可变报头 无
有用负载 无
服务端 必须发送 PINGRESP 报文相应客户端的 PINGREQ 报文
报文：
C0 00 （只有这一种）
13号控制报文：PINGRESP – 心跳相应
服务端发送 PINGRESP 报文相应客户端的 PINGREQ 报文。表现服务端还在世。
报文内容组成:
固定报头 报文范例D0+剩余长度00
可变报头 无
有用负载 无
报文：
D0 00 （只有这一种）
14号控制报文：DISCONNECT – 断开毗连
DISCONNECT 报文是客户端发给服务端的最后一个控制报文。表现客户端"正常"断开毗连。
报文内容组成:
固定报头 报文范例E0+剩余长度00
可变报头 无
有用负载 无
报文：
E0 00 （只有这一种）
留意：客户端发送 DISCONNECT 报文之后：
1.必须关闭网络毗连。
2.不能通过谁人网络毗连再发送任何控制报文 。
服务端在收到 DISCONNECT 报文时：
1.必须丢弃任何与当前毗连关联的未发布的遗嘱消息。
2.应该关闭网络毗连，如果客户端 还没有这么做。
关于CONNECT控制报文中的毗连标志
关于密码标志位：
如果密码（Password）标志被设置为 0，有用载荷中不能包含密码字段。
如果密码（Password）标志被设置为 1，有用载荷中必须包含密码字段。
如果用户名标志被设置为 0，密码标志也必须设置为 0。
关于用户名标志位：
如果用户名（User Name）标志被设置为 0，有用载荷中 不能包含用户名字段。
如果用户名（User Name）标志被设置为 1，有用载荷中 必须包含用户名字段。
关于遗嘱保存位：
如果遗嘱标志被设置为 0，遗嘱保存（Will Retain）标志也 必须设置为 0。
如果遗嘱标志被设置为 1：
1.如果遗嘱保存被设置为 0，服务端必须将遗嘱消息当作非保存消息发布。
2.如果遗嘱保存被设置为 1，服务端必须将遗嘱消息当作保存消息发布。
关于遗嘱QoS位：
这两位用于指定发布遗嘱消息时使用的服务质量等级。
如果遗嘱标志被设置为 0，遗嘱 QoS 也 必须设置为 0(0x00)。
如果遗嘱标志被设置为 1，遗嘱 QoS 的值可以即是 0(0x00)，1(0x01)，2(0x02)。它的值不能即是3。
关于遗嘱标志位：
遗嘱消息由服务端发布，通常是断开毗连后紧接着发布的消息
遗嘱标志（Will Flag）被设置为 1，表现如果毗连请求被接受了，遗嘱（Will Message）消息(在有用载荷中)必须被存储在服务端并且与这个网络毗连关联。之后网络毗连关闭时，服务端必须发布这个遗嘱消息，除非服务端收到DISCONNECT 报文时删除了这个遗嘱消息
遗嘱消息发布的条件，包罗但不限于：
- 服务端检测到了一个 I/O 错误或者网络故障。
- 客户端在保持毗连（Keep Alive）的时间内未能通讯。
- 客户端没有先发送 DISCONNECT 报文直接关闭了网络毗连。
- 由于协议错误服务端关闭了网络毗连。
如果遗嘱标志被设置为 1，毗连标志中的 Will QoS 和 Will Retain 字段会被服务端用到，同时有用载荷中必须包含 Will Topic 和 Will Message 字段。一旦被发布或者服务端收到了客户端发送的 DISCONNECT 报文，遗嘱消息就必须从存储的会话状态中移除。
如果遗嘱标志被设置为 0，毗连标志中的 Will QoS 和 Will Retain 字段 必须设置为 0，并且有用载荷中 不能包含 Will Topic 和 Will Message 字段。网络毗连断开时， 服务端更加不能发送遗嘱消息。
服务端应该在条件成立时敏捷发布遗嘱消息。在关机或故障的情况下，服务端可以推迟遗嘱消息的发布直到之后的重启。
如果发生了这种情况，在服务器故障和遗嘱消息被发布之间大概会有一个延迟。
关于清理会话标志：
指定了会话状态的处置惩罚方式。客户端和服务端可以保存会话状态，以支持跨网络毗连的可靠消息传输。这个标志位用于控制会话状态的
生存时间。
如果清理会话（CleanSession）标志被设置为 1，客户端和服务端 必须丢弃之前的任何会话并开始一个新的会话。会话仅持续和网络毗连同样长的时间。与这个会话关联的状态数据不能被任何之后的会话重用。
清理会话标志设置为 1 的客户端不会收到旧的应用消息，而且在每次毗连成功后都需要重新订阅任何相干的主题。
为了确保在发生故障时状态的一致性，客户端应该使用会话状态标志 1 重复请求毗连，直到毗连成功。
(通常使用置1即可)
关于CONNECT控制报文中的保持毗连时间
保持毗连（Keep Alive）是一个以秒为单位的时间间隔，表现为一个 16 位的字，它是指在客户端传输完成一个控制报文的时刻到发送下一个报文的时刻，两者之间允许空闲的最大时间间隔。客户端负责保证控制报文发送的时间间隔不超过保持毗连的值。如果没有任何其它的控制报文可以发送，客户端 必须发送一个PINGREQ 报文。
不管保持毗连的值是多少，客户端任何时候都可以发送 PINGREQ 报文，并且使用 PINGRESP 报文判定网络和服务端的活动状态。
如果保持毗连的值非零，并且服务端在1.5倍的保持毗连时间内没有收到客户端的控制报文，它必须断开客户端的网络毗连，以为网络毗连已断开。
客户端发送了 PINGREQ 报文之后，如果在合理的时间内仍没有收到 PINGRESP 报文，它 应该关闭到服务端的网络毗连。
保持毗连的值为零表现关闭保持毗连功能。这意味着，服务端不需要由于客户端不活跃而断开毗连，即可以一直保持毗连。留意：
不管保持毗连的值是多少，任何时候，只要服务端以为客户端是不活跃或无相应的，可以断开客户端的毗连。
保持毗连的实际值是由应用指定的，一般是几分钟。允许的最大值是 18 小时 12 分 15 秒。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
