1.数据通信协议简介
数据通信协议，亦称数据通信控制协议。是为保证数据通信网中通信双方能有效，可靠通信而规定的一系列约定。这些约定包括数据的格式，顺序和速率，数据传输的确认或拒收，差错检测，重传控制和询问等操作。数据通信协议分两类：一类称为基本型通信控制协议，用于以字符为基本单位的数据传输，如BSC协议（二进制同步同步通信协议）；另一类称为高级键路控制协议，用于以比特为基本单位的数据传输，如HDLC（高级数据键路控制协议）和SDLC（同步数据键路控制协议）。

数据通信协议是数据通信系统中通信对象之间能准确有效地进行通信所必须遵循的规则和各种约定事项。数据通信是继电报通佶和电话通信之后的一种新型通信方式，是计算机技术和通信技术相结合的产物。电报通信和电话通信是人-人之间的通信，通信过程中的差镨控制等通信控制功能由人来完成。数据通信主要是人-机或机-机之间的通信，这里所说的“机”指的就是电子计算机，其通信控制功能只能严格按照预先在计算机内设置的诸如“使用什么样的规程，交换什么格式的信息”等规则和各种约定事项进行。

2.MQTT协议
MQTT(Message Queuing Telemetry Transport，消息队列遥测传输)是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和制动器(比如通过Twitter让房屋联网)的通信协议。

MQTT是轻量级基于代理的发布/订阅的消息传输协议，它可以通过很少的代码和带宽和远程设备连接。例如通过卫星和代理连接，通过拨号和医疗保健提供者连接，以及在一些自动化或小型设备上，而且由于小巧，省电，协议开销小和能高效的向一和多个接收者传递信息，故同样适用于称动应用设备上。

MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性:
（1）使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合;
（2）对负载内容屏蔽的消息传输;
（3）使用 TCP/IP 提供网络连接;
（4）有三种消息发布服务质量:
“至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。
“至少一次”，确保消息到达，但消息重复可能会发生。
“只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
（5）小型传输，开销很小(固定长度的头部是 2 字节)，协议交换最小化，以降低网络流量;
（6）使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制;
3.MQTT协议初解
整个协议的构造，整体上协议可拆分为：固定头部+可变头部+消息体
在固定头部的构造如下：

（1）MessageType(0和15保留，共占4个字节)
public $operations=array(
“MQTT_CONNECT”=>1,//请求连接
“MQTT_CONNACK”=>2,//请求应答
“MQTT_PUBLISH”=>3,//发布消息
“MQTT_PUBACK”=>4,//发布应答
“MQTT_PUBREC”=>5,//发布已接收，保证传递1
“MQTT_PUBREL”=>6,//发布释放，保证传递2
“MQTT_PUBCOMP”=>7,//发布完成，保证传递3
“MQTT_SUBSCRIBE”=>8,//订阅请求
“MQTT_SUBACK”=>9,//订阅应答
“MQTT_UNSUBSCRIBE”=>10,//取消订阅
“MQTT_UNSUBACK”=>11,//取消订阅应答
“MQTT_PINGREQ”=>12,//ping请求
“MQTT_PINGRESP”=>13,//ping响应
“MQTT_DISCONNECT”=>14//断开连接
);
（2）DUP flag
其是用来在保证消息传输可靠的，如果设置为1，则在下面的变长头部里多加MessageId,并需要回复确认，保证消息传输完成，但不能用于检测消息重复发送。
（3）Qos
主要用于PUBLISH（发布态）消息的，保证消息传递的次数。
00表示最多一次 即<=1
01表示至少一次 即>=1
10表示一次，即==1
11保留后用
（4）Retain
主要用于PUBLISH(发布态)的消息，表示服务器要保留这次推送的信息，如果有新的订阅者出现，就把这消息推送给它。如果不设那么推送至当前订阅的就释放了。
（5）固定头部的byte 2
是用来保存接下去的变长头部+消息体的总大小的。
但是不是并不是直接保存的，同样也是可以扩展的，其机制是，前7位用于保存长度，后一部用做标识。
举个例，即如果计算出后面的大小为0<length<=127的，正常保存。如果是127<length<16383的，则需要二个字节保存了，将第一个字节的最大的一位置1,表示未完。然后第二个字节继续存。拿130来说，第一个字节存10000011,第二个字节存000000001，也就是0x83,0x01,把两个字节连起来看，第二个字节权重从2的8次开始。同起可以加第3个字节，最多可以加至第4个字节。故MQTT协议最多可以实现268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)将近256M的数据。可谓能伸能缩。

可变头部

这个是可变头部的全貌。
（1）首先最上面的8个字节是Protocol Name(编码名)，UTF编码的字符“MQIsdp”，头两个是编码名提长为6，接下去的协议多采用这种方式组合，即头两个字节表示下一部分的长，然后后面跟上内容。这里头两个字节长为6，下面跟6个字符“MQIsdp”。
（2）Protocol Version，协议版本号，v3 也是固定的。
（3）Connect Flag，连接标识，有点像固定头部的。8位分别代表不同的标志。第1个字节保留。
Clean Session,Will flag，Will Qos, Will Retain都是相对于CONNECT消息来说的。
Clean Session:0表示如果订阅的客户机断线了，那么要保存其要推送的消息，如果其重新连接时，则将这些消息推送。
1表示消除，表示客户机是第一次连接，消息所以以前的连接信息。
Will Flag，表示如果客户机在不是在发送DISCONNECT消息中断，比如IO错误等，将些置为1,要求重传。并且下且的WillQos和WillRetain也要设置，消息体中的Topic和MessageID也要设置，就是表示发生了错误，要重传。
Will Qos，在CONNECT非正常情况下设置，一般如果标识了WillFlag，那么这个位置也要标识。
Will RETAIN：同样在CONNECT中，如果标识了WillFlag,那么些位也一定要标识
usename flag和passwordflag，用来标识是否在消息体中传递用户和密码，只有标识了，消息体中的用户名和密码才用效，只标记密码而不标记用户名是不合法的。
（4）Keep Alive，表示响应时间，如果这个时间内，连接或发送操作未完成，则断开tcp连接，表示离线。
（5）Connect Return Code即通常于CONNACK消息中，表示返回的连接情况，我可以通过此检验连接情况。

（6）、Topic Name，订阅消息标识，MQTT是基于订阅/发布的消息，那么这个就是消息订阅的标识，像新闻客户端里的订阅不同的栏目一样。用于区别消息的推送类别。
主要用于PUBLISH和SUBSCRIBE中。最大可支持32767个字符，即4个字节。
消息体（PayLoad）
只有3种消息有消息体CONNECT，SUBSCRIBE，SUBACK
CONNECT主要是客户机的ClientID，订阅的Topic和Message以及用户名和密码，其于变长头部中的will是对应的。
SUBSCRIBE是包含了一系列的要订阅的主题以及QOS。
SUBACK是用服务器对于SUBSCRIBE所申请的主题及QOS进行确认和回复。
而PUBLISH是消息体中则保存推送的消息，以二进制形式，当然这里的编辑可自定义。
7.Message Identifier
包含于PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.
其为16位字符表示，用于在Qos为1或2时标识Message的，保证Message传输的可靠性。

引言

在AIoT 如此流行的今天，未来智能家居、智能车联网、智能物联网必将有广阔的天空，而MQTT 作为一种专门为物联网设计的协议，接下来文章就好好总结相关理论知识。系列文章链接：

• 网络编程——物联网利器MQTT通信协议详解（一）
• 网络编程——物联网利器MQTT通信协议详解（二）
• 网络编程——物联网利器MQTT通信协议详解（三）
• 网络编程——物联网利器MQTT通信协议详解（四）
  以后更多精选系列文章以高度完整的系列形式发布在公众号，真正的形成一套完整的技术栈，欢迎关注，目前第一个系列是关于Android系统启动系列的文章，大概有二十几篇干货：
  

一、MQTT 协议

本文档基于 MQTT 协议版本v3.1.1，部分理论摘自MQTT中文网，其他见图片水印。

1、MQTT协议概述

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）广泛应用于机器对机器(M2M)/物联网(IoT)的应用层连接协议，使用极其轻量级的发布/订阅二进制消息模型通信。对于需要较小代码占用空间和或网络带宽非常宝贵的远程连接非常有用，是专为受限设备（电池功率非常高的移动应用设备）和低带宽、高延迟或不可靠的环境通信而设计的。不仅为新兴的“机器到机器”(M2M)或物联网(IoT)世界提供连接，还被用于通过卫星链路与代理通信的传感器、与医疗服务提供者的拨号连接以及一系列家庭自动化和小型设备场景。

主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN

2、MQTT的主要特点

MQTT协议工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：

• 底层基于TCP/IP (或者UDP） 协议传输，采用发布/订阅模式的二进制消息模式，提供一对多的消息发布

• 控制包结构精简，第一个 1字节固定报头，第二个2字节心跳报文，最小化传输开销和协议交换，有效减少网络流量。

• 消息QoS支持，可靠传输保证

• 使用Last Will和Testament特性通知有关各方客户端异常中断的机制。

  Last Will即遗言机制，用于通知同一主题下的其他设备发送遗言的设备已经断开了连接；而Testament遗嘱机制，功能类似于Last Will。

3、MQTT 设计原则

由于物联网的环境是非常特别的，所以MQTT遵循以下设计原则：

• 精简，不添加可有可无的功能，理解客户端计算能力可能很低
• 发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递；
• 允许用户动态创建主题，零运维成本；
• 把传输量降到最低以提高传输效率，支持低带宽、高延迟、不稳定的网络等因素考虑在内；
• 支持连续的会话控制；
• 提供服务质量管理；
• 假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

二、MQTT 协议核心角色

MQTT 协议主要有三大核心角色：发布者（Publisher）、Broker代理服务器（转发者）、订阅者（Subscriber）。其中消息的发布者和订阅者都是客户端角色，消息代理是服务器，消息发布者可以同时是订阅者。

1、 MQTT客户端

MQTT客户端身兼二职：既可以是发布者角色，又可以是订阅者角色。一个使用MQTT协议的应用程序或者设备就是一个MQTT 客户端，工作时它需要主动去连接到代理服务器，所以MQTT客户端的功能有：

• 主动与Broker 建立连接，主动断开Broker的连接。

• 作为发布者角色，发布给其他客户端订阅的Topic

• 作为订阅者，主动订阅其它客户端发布的Topic

• 退订之前订阅的Topic

• 清空服务端之前保留的Message

2、 MQTT服务器

MQTT通信必须依赖一个MQTT Broker，Broker（服务器）可以看出是MQTT网络的Hub，负责处理客户端的订阅逻辑并转发给其他订阅的客户端，如下图所示。

MQTT服务器又称为"消息代理"服务器（Broker），可以是一个应用程序或一台设备，它是位于消息发布者和订阅者之间，具有以下功能：

• 接受来自客户端的网络连接并建立通信链路
• 接收发布者的Topic并转发给订阅者
• 处理来自客户端的订阅和退订请求
• 向订阅的客户转发相应地Topic

三、MQTT 主要工作流程和服务质量QoS

1、MQTT 通信核心流程

如图https://blog.p2hp.com/archives/4100所示，MQTT 的工作流程十分便捷，MQTT 客户端之间的通信都是需要通过Broker 间接实现，两个客户端想要通信，它们必须具备以下前提：

• 两个MQTT 客户端成功与同一个Broker 建立连接
• 两个MQTT 客户端之间约定一个相同的Topic（不一定完全相同，可以用通配符“+”替代）

发布者和订阅者在成功和同一个Broker 建立连接后，发布者向Broker 发布一个Topic，Broker 转发给订阅了这个Topic 的所有订阅者。

2、MQTT 消息发布的三种服务质量（QoS）

2.1、QoS 0：At most once(deliver and forget)至多分发一次

“至多一次”，消息发布完全依赖底层TCP/IP网络可能会发生消息丢失或重复，接收者不发送响应，发送者也不重新尝试。接收者只能收到一次消息或者一次也收不到。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。

2.2、QoS 1 :At least once至少分发一次

确保消息到达，但消息重复可能会发生。可以确保消息至少一次抵达接收者。QoS 1的PUBLISH包的可变包头包含包唯一标识，而且有PUBACK包确认。在QoS 1的分发协议中，发送者

• 每次发布新的应用消息，必须分配一个没有用过的包唯一标识。
• 包含唯一标识的PUBLISH包也必须是QoS=1，DUP=0。
• 必须把PUBLISH包当作“未确认的”，直到从接收者那里收到对应的PUBACK包。

一旦发送者收到PUBACK包，包唯一标识就可以重用了。而在QoS 1的分发协议中，接收者

• 必须响应一个包含与PUBLISH包相同的包唯一标识，来接受应用消息的所属关系。
• 在发送PUBACK包之后，接收者必须把所有收到的包含相同包唯一标识的PUBLISH包当作一个新的发布，无论是否设置了DUP标识。

2.3、QoS 2 :Exactly once只有一次

最高的服务质量，用在丢失和重复消息都不能被接受的情况确保消息到达一次。在一些要求比较严格的计费系统中，可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。QoS 2消息的可变包头包含包唯一标识，QoS 2的PUBLISH包的接收者分两步确认接收，在QoS 2的分发协议中，发送者

• 每次发布新的应用消息，必须分配一个没有用过的包唯一标识。
• 包含唯一标识的PUBLISH包也必须是QoS=1，DUP=0。
• 必须把PUBLISH包当作“未确认的”，直到从接收者那里收到对应的PUBACK包。
• 当从接收者那里收到PUBREC包时要发送PUBREL包。PUBREL包必须包含与原始PUBLISH包相同的包唯一标识。
• 必须把PUBREL包当作“未确认的”，直到从接收者那里收到对应的PUBCOMP包。
• 一旦已经发送了相应的PUBREL包，就不能再重发PUBLISH包。

当发送者收到PUBCOMP包之后，包唯一标识就可以重用了。在QoS 2的分发协议中，接收者

• 必须响应一个包含与PUBLISH包相同的包唯一标识，来接受应用消息的所属关系。
• 直到收到相应的PUBREL包，接收者必须发送包含相同包唯一标识的PUBREC来确认后来的PUBLISH包。这样一定不会导致重复的消息被分发到接下来的接收者。
• 必须用包含相同包唯一标识的PUBCOMP包来响应一个PUBREL包。
• 在发送PUBCOMP之后，接收者必须把所有收到的包含相同包唯一标识的PUBLISH包当作一个新的发布。

未完待续…

目录

MQTT协议的通信模型

MQTT消息格式*

1 固定报头

2 可变报头

3 负载 

MQTT控制报文

1 CONNECT-连接服务器*

2 CONNACK-确认连接请求

3 PUBLISH-发布消息*

4 PUBACK-发布确认

5 PUBREC-发布收到

6 PUBREL-发布释放

7 PUBCOMP-发布完成

8 SUBSCRIBE-订阅主题*

9 SUBACK-订阅确认

10 UNSUBSCRIBE-取消订阅*

11 UNSUBACK-取消订阅确认

12 PINGREQ-心跳请求*

13 PINGRESP-心跳响应

14 DISCONNECT-断开连接

QoS等级

---

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（Publish/Subscribe）模式的轻量级通讯协议，MQTT 最大的优点在于可以以极少的代码和有限的带宽，为远程设备提供实时可靠的消息服务。做为一种低开销、低带宽占用的即时通讯协议， MQTT 在物联网、小型设备、移动应用等方面有广泛的应用。

MQTT协议的通信模型

发布/订阅模型

MQTT消息格式*

每条 MQTT 命令消息的消息头都包含一个固定的报头，有些消息会携带一个可变报文头和一个负荷。消息格式如下

固定报头|可变报头|负载(消息体)

1 固定报头

固定报头2~5个字节，所有报文都会包含固定报头。 

byte1[7:4]：MQTT控制报文类型

byte1[3:0]：MQTT报文类型特定的表示

控制报文		bit3	bit2:bit1	bit0
PUBLISH	发布消息	DUP	QoS	RETAIN
PUBREL	发布释放	0	1	0
SUBSCRIEB	订阅请求	0	1	0
UNSUBSCRIEB	取消订阅	0	1	1
other		0	0	0

DUP:控制报文的重复分发标志
QoS:PUBLISH报文的服务质量等级

		发送方报文	接收方报文
QoS=0	最多收到一次	publish
QoS=1	最少收到一次	publish	puback
QoS=2	收且收到一次	publish、pubrel(ease)	pubrec(ord)、pubcomp(lete)

RETAIN = PUBLISH报文的保留标志

byte2:剩余长度( Remaining Length)表示当前报文剩余部分的字节数，包括可变报头和负载的数据。剩余长度不包括用于编码剩余长度字段本身的字节数。共1~4个字节，每个字节的低7位用于编码数据，最高位表示是否有更多字节。最大允许发送256M控制报文(0xff,0xff,0xff,0x7f)=256M;

2 可变报头

部分MQTT控制报文包含一个可变报头部分。它在固定报头和负载之间。可变报头的内容根据报文类型的不同而不同。可变报头的报文标识符(Packetldentifier)字段存在于在多个类型的报文里。

很多控制报文的可变报头部分包含一个两字节的报文标识符字段。这些报文是PUBLISH(QoS > 0时),PUBACK,PUBREC，PUBREL,PUBCOMP,SUBSCRIBE,SUBACK,UNSUBSCIBE,UNSUBACK。

3 负载 

部分MQTT控制报文在报文的最后部分包含一个有效载荷。对于PUBLISH来说有效载荷就是应用消息。下面列出了需要有效
载荷的控制报文。

控制报文	有效负载
CONNECT	需要
PUBLISH	可选
SUBSCRIBE	需要
SUBACK	需要
UNSUBSCRIBE	需要

MQTT控制报文

1 CONNECT-连接服务器*

        客户端到服务端的网络连接建立后，客户端发送给服务端的第一个报文必须是CONNECT报文。在一个网络连接上，客户端只能发送一次CONNECT报文。服务端必须将客户端发送的第二个CONNECT报文当作协议违规处理并断开客户端的连接 。有效载荷包含一个或多个编码的字段。包括客户端的唯一标识符，Will主题，Will消息，用户名和密码。除了客户端标识之外，其它的字段都是可选的，基于标志位来决定可变报头中是否需要包含这些字段。

1.1 connect的固定报头

剩余长度等于可变报头的长度(10字节)加上有效载荷的长度。

1.2 connect的可变报头

        CONNECT报文的可变报头按下列次序包含四个字段(共10个字节)：协议名(Protocol Name),协议级别(Protocol Level),连接标志(Connect Flags)和保持连接(Keep Alive) 。

        协议名 Protocol Name

        协议级别 Protocol Level：客户端用8位的无符号值表示协议的修订版本。对于3.1.1版协议，协议级别字段的值是4(0x04)。如果发现不支持的协议级别，服务端必须给发送一个返回码为0x01（不支持的协议级别） 的CONNACK报文响应CONNECT报文，然后断开客户端的连接。

         连接标志 Connect Flags：连接标志字节包含一些用于指定MQTT连接行为的参数。它还指出有效载荷中的字段是否存在。服务端必须验证CONNECT控制报文的保留标志位（第0位） 是否为0，如果不为0必须断开客户端连接。

        保持连接 Keep Alive：是一个以秒为单位的时间间隔，表示为一个16位的字，它是指在客户端传输完成一个控制报文的时刻到发送下一个报文的时刻，两者之间允许空闲的最大时间间隔。客户端负责保证控制报文发送的时间间隔不超过保持连接的值。如果没有任何其它的控制报文可以发送，客户端必须发送一个PINGREQ报文。

1.3 connect的有效负载

        CONNECT报文的有效载荷（payload） 包含一个或多个以长度为前缀的字段，可变报头中的标志决定是否包含这些字段。如果包含的话，必须按这个顺序出现：客户端标识符，遗嘱主题，遗嘱消息，用户名，密码。

2 CONNACK-确认连接请求

        服务端发送CONNACK报文响应从客户端收到的CONNECT报文。服务端发送给客户端的第一个报文必须是CONNACK。如果客户端在合理的时间内没有收到服务端的CONNACK报文，客户端应该关闭网络连接。合理的时间取决于应用的类型和通信基础设施。

2.1 connack的固定报头：CONNACK的剩余长度为2，没有有效负载

2.2 connack的可变报头：第1个字节是 连接确认标志，位7-1是保留位且必须设置为0。 第0 (SP)位 是当前会话(Session Present)标志。

         连接返回码 Connect Return code:连接返回码字段使用一个字节的无符号值，在下表连接返回码的值中列出。如果服务端收到一个合法的CONNECT报文，但出于某些原因无法处理它，服务端应该尝试发送一个包含非零返回码（表格中的某一个） 的CONNACK报文。如果服务端发送了一个包含非零返回码的CONNACK报文，那么它必须关闭网络连接。

        如果认为上表中的所有连接返回码都不太合适，那么服务端必须关闭网络连接，不需要发送CONNACK报文。

2.3 connack有效负载

        CONNACK报文没有有效负载。

3 PUBLISH-发布消息*

        PUBLISH控制报文是指从客户端向服务端或者服务端向客户端传输一个应用消息。

3.1 publish的固定报头 

        byte1[3]:重发标志 DUP,如果DUP标志被设置为0，表示这是客户端或服务端第一次请求发送这个PUBLISH报文。如果DUP标志被设置为1，表示这可能是一个早前报文请求的重发。客户端或服务端请求重发一个PUBLISH报文时，必须将DUP标志设置为1。对于QoS 0的消息，DUP标志必须设置为0 。
        byte1[2:1]:这个字段表示应用消息分发的服务质量等级保证。服务质量等级在下格服务质量定义中列出。PUBLISH报文不能将QoS所有的位设置为1。如果服务端或客户端收到QoS所有位都为1的PUBLISH报文，它必须关闭网络连接

        byte1[0]: 保留标志 RETAIN。问候消息：客户端发布的RETAIN=1的消息，服务端保留为问候消息当新客户订阅相应主题时，服务端将消息发送给订阅者。对于发布者不定期发送状态消息这个场景，保留消息很有用。新的订阅者将会收到最近的状态。

        byte2：剩余长度。等于可变报头的长度加上有效载荷的长度。

3.2 publish的可变报头：可变报头按顺序包含主题名和报文标识符。

        主题名 Topic Name：用于识别有效载荷数据应该被发布到哪一个信息通道。主题名必须是PUBLISH报文可变报头的第一个字段。它必须是UTF-8编码的字符串 。PUBLISH报文中的主题名不能包含通配符。服务端发送给订阅客户端的PUBLISH报文的主题名必须匹配该订阅的主题过滤器。

        报文标识符 Packet Identifier:只有当QoS等级是1或2时，报文标识符（Packet Identifier） 字段才能出现在PUBLISH报文
中。

3.3 publish的有效负载:有效载荷包含将被发布的应用消息。数据的内容和格式(纯文本字符串、JSON字符串)是应用特定的。有效载荷的长度这样计算：用固定报头中的剩余长度字段的值减去可变报头的长度。包含零长度有效载荷的PUBLISH报文是合法的。

3.4 响应：PUBLISH报文的接收者必须按照根据PUBLISH报文中的QoS等级发送响应。

4 PUBACK-发布确认

        PUBACK报文是对QoS 1等级的PUBLISH报文的响应。

4.1 puback的固定报头：puback的剩余长度值为2。

4.2 puback的可变报头：包含等待确认的PUBLISH报文的报文标识符。

 4.3 puback的有效负载

        puback没有有效负载。

5 PUBREC-发布收到

        PUBREC报文是对QoS等级2的PUBLISH报文的响应。它是QoS2等级协议交换的第二个报文。

5.1 pubrec的固定报头：pubrec的剩余长度值为2。

5.2 pubrec的可变报头：可变报头包含等待确认的PUBLISH报文的报文标识符。

 5.3 pubrec的有效负载

        pubrec没有有效负载

6 PUBREL-发布释放

        PUBREL报文是对PUBREC报文的响应。它是QoS 2等级协议交换的第三个报文。

6.1 pubrel的固定报头：PUBREL控制报文固定报头的第3,2,1,0位是保留位，必须被设置为0,0,1,0。服务端必须将其
它的任何值都当做是不合法的并关闭网络连接。PUBREL的剩余长度值为2。

6.2 pubrel的可变报头：可变报头包含与等待确认的PUBREC报文相同的报文标识符。

6.3 pubrel的有效负载

        pubrel没有有效负载。

7 PUBCOMP-发布完成

        PUBCOMP报文是对PUBREL报文的响应。它是QoS2等级协议交换的第四个也是最后一个报文。

7.1 pubcomp的固定报头：pubcomp的剩余长度为2。

7.2 pubcomp的可变报头：可变报头包含与等待确认的PUBREL报文相同的报文标识符。

 7.3 pubcomp的有效负载

        pubcomp没有有效负载。

8 SUBSCRIBE-订阅主题*

        客户端向服务端发送SUBSCRIBE报文用于创建一个或多个订阅。每个订阅注册客户端关心的一个或多个主题。为了将应用消息转发给与那些订阅匹配的主题，服务端发送PUBLISH报文给客户端。SUBSCRIBE报文也（为每个订阅）指定了最大的QoS等级，服务端根据这个发送应用消息给客户端。

8.1 subscribe的固定报头：SUBSCRIBE控制报固定报头的第3,2,1,0位是保留位，必须分别设置为0,0,1,0。服务端必须将
其它的任何值都当做是不合法的并关闭网络连接 。剩余长度字段=可变报头的长度（2字节）+有效载荷的长度。

8.2 subscribe的可变报头：可变报头包含报文标识符。

 8.3 subscribe的有效负载

        SUBSCRIBE报文的有效载荷包含了一个主题过滤器列表，它们表示客户端想要订阅的主题。如果服务端选择不支持包含通配符的主题过滤器，必须拒绝任何包含通配符过滤器的订阅请求 。每一个过滤器后面跟着一个字节，这个字节被叫做 服务质量要求（Requested QoS） 。它给出了服务端向客户端发送应用消息所允许的最大QoS等级。
        SUBSCRIBE报文的有效载荷必须包含至少一对主题过滤器和QoS等级字段组合。没有有效载荷的SUBSCRIBE报文是违反协议的。请求的最大服务质量等级字段编码为一个字节，它后面跟着UTF-8编码的主题名，那些主题过滤器 /和QoS等级组合是连续地打包。

        当前版本的协议没有用到服务质量要求（Requested QoS） 字节的高六位。如果有效载荷中的任何位是非零值，或者QoS不等于0,1或2，服务端必须认为SUBSCRIBE报文是不合法的并关闭网络连接。

8.4 subscribe的订阅响应：服务端收到客户端发送的一个SUBSCRIBE报文时，必须使用SUBACK报文响应。SUBACK报文必须和等待确认的SUBSCRIBE报文有相同的报文标识符。

        允许服务端在发送SUBACK报文之前就开始发送与订阅匹配的PUBLISH报文。
        如果服务端收到一个SUBSCRIBE报文，报文的主题过滤器与一个现存订阅的主题过滤器相同，那么必须使用新的订阅彻底替换现存的订阅。新订阅的主题过滤器和之前订阅的相同，但是它的最大QoS值可以不同。与这个主题过滤器匹配的任何现存的保留消息必须被重发，但是发布流程不能中断。

        如果主题过滤器不同于任何现存订阅的过滤器，服务端会创建一个新的订阅并发送所有匹配的保留消息。

        如果服务端收到包含多个主题过滤器的SUBSCRIBE报文，它必须如同收到了一系列的多个SUBSCRIBE报文一样处理那个，除了需要将它们的响应合并到一个单独的SUBACK报文发送

        客户端发送订阅报文中的Qos=X表示：对于当前主题，客户端最大接收质量是X。但MQTT服务器不一定会同意客户端的要求，有可能对客户端当前订阅主题的质量进行降级。

        当客户端A订阅了主题T，并且订阅质量=X，如果客户端B向主题T发布Qos=Y的消息，服务器只会按照Qos=X的质量，来向客户端A分发消息。

9 SUBACK-订阅确认

        服务端发送SUBACK报文给客户端，用于确认它已收到并且正在处理SUBSCRIBE报文。SUBACK报文包含一个返回码清单，它们指定了SUBSCRIBE请求的每个订阅被授予的最大QoS等级。

9.1 suback的固定报头：剩余长度=可变报头+有效负载。

9.2 suback的可变报头：包含等待确认的SUBSCRIBE报文的报文标识符。

9.3 suback的有效负载：有效载荷包含一个返回码清单。每个返回码对应等待确认的SUBSCRIBE报文中的一个主题过
滤器。返回码的顺序必须和SUBSCRIBE报文中主题过滤器的顺序相同。

允许的返回码值：
        0x00 - 最大QoS 0
        0x01 - 成功 – 最大QoS 1
        0x02 - 成功 – 最大 QoS 2
        0x80 - Failure 失败

10 UNSUBSCRIBE-取消订阅*

        客户端发送UNSUBSCRIBE报文给服务端，用于取消订阅主题。

10.1 unsubscribe的固定报头：UNSUBSCRIBE报文固定报头的第3,2,1,0位是保留位且必须分别设置为0,0,1,0。服务端必须
认为任何其它的值都是不合法的并关闭网络连接。剩余长度=可变报头+有效负载。

10.2 unsubscribe的可变报头：可变报头包含一个报文标识符。

10.3 unsubscribe的有效负载：UNSUBSCRIBE报文的有效载荷包含客户端想要取消订阅的主题过滤器列表。UNSUBSCRIBE报文中的主题过滤器必须是连续打包的、按照UTF-8编码字符串。UNSUBSCRIBE报文的有效载荷必须至少包含一个消息过滤器。没有有效载荷的UNSUBSCRIBE报文是违反协议的。

10.4 unsubscribe的响应：

        UNSUBSCRIBE报文提供的主题过滤器（无论是否包含通配符）必须与服务端持有的这个客户端的当前主题过滤器集合逐个字符比较。如果有任何过滤器完全匹配，那么它（服务端）自己的订阅将被删除，否则不会有进一步的处理。如果服务端删除了一个订阅：
        1 它必须停止分发任何新消息给这个客户端。
        2 它必须完成分发任何已经开始往客户端发送的QoS 1和QoS 2的消息。
        3 它可以继续发送任何现存的准备分发给客户端的缓存消息。
        服务端必须发送UNSUBACK报文响应客户端的UNSUBSCRIBE请求。UNSUBACK报文必须包含和UNSUBSCRIBE报文相同的报文标识符。即使没有删除任何主题订阅，服务端也必须发送一个UNSUBACK响应]。如果服务端收到包含多个主题过滤器的UNSUBSCRIBE报文，它必须如同收到了一系列的多个UNSUBSCRIBE报文一样处理那个报文，除了将它们的响应合并到一个单独的UNSUBACK报文外。

11 UNSUBACK-取消订阅确认

        服务端发送UNSUBACK报文给客户端用于确认收到UNSUBSCRIBE报文。

11.1 unsuback的固定报头：剩余长度=2。

 11.2 unsuback的可变报头：可变报头包含等待确认的UNSUBSCRIBE报文的报文标识符。

11.3 unsuback的有效负载

        没有有效负载。

12 PINGREQ-心跳请求*

        客户端发送PINGREQ报文给服务端的。用于：
        1. 在没有任何其它控制报文从客户端发给服务的时，告知服务端客户端还活着。
        2. 请求服务端发送 响应确认它还活着。
        3. 使用网络以确认网络连接没有断开。保持连接（Keep Alive） 处理中用到这个报文

12.1 pingreq的固定报头

12.2 pingreq没有可变报头和有效负载。

12.3 响应：服务端必须发送 PINGRESP报文响应客户端的PINGREQ报文。

13 PINGRESP-心跳响应

        服务端发送PINGRESP报文响应客户端的PINGREQ报文。表示服务端还活着。保持连接（Keep Alive） 处理中用到这个报文。

13.1 pingresp的固定报头

 13.2 pingresp没有可变报头和有效负载。

14 DISCONNECT-断开连接

        DISCONNECT报文是客户端发给服务端的最后一个控制报文。表示客户端正常断开连接。

14.1 固定报头

14.2 没有可变报头和有效负载。

14.3 响应：客户端发送DISCONNECT报文之后：必须关闭网络连接 。不能通过那个网络连接再发送任何控制报文。
        服务端在收到DISCONNECT报文时：必须丢弃任何与当前连接关联的未发布的遗嘱消息，应该关闭网络连接，如果客户端还没有这么做。

QoS等级

MQTT根据QoS定义的等级来传输消息。等级描述如下：

level 0：最多一次的传输

消息是基于TCP/IP网络传输的。没有回应，在协议中也没有定义重传的语义。消息可能到达服务器1次，也可能根本不会到达。

level 1：至少一次的传输

服务器接收到消息会被确认，通过传输一个PUBACK信息。如果有一个可以辨认的传输失败，无论是通讯连接还是发送设备，还是过了一段时间确认信息没有收到，发送方都会将消息头的DUP位置1，然后再次发送消息。消息最少一次到达服务器。SUBSCRIBE和UNSUBSCRIBE都使用level 1 的QoS。

如果客户端没有接收到PUBACK信息（无论是应用定义的超时，还是检测到失败然后通讯session重启），客户端都会再次发送PUBLISH信息，并且将DUP位置1。当它从客户端接收到重复的数据，服务器重新发送消息给订阅者，并且发送另一个PUBACK消息。

evel 2： 只有一次的传输

在QoS level 1上附加的协议流保证了重复的消息不会传送到接收的应用。这是最高级别的传输，当重复的消息不被允许的情况下使用。这样增加了网络流量，但是它通常是可以接受的，因为消息内容很重要。

QoS level 2在消息头有Message ID。