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：只有一次的传输