- 第一章 - 介绍
- 第二章 – MQTT控制报文格式
- 第三章 – MQTT控制报文
- 第四章 – 操作行为
- 第五章 – 安全（非规范）
- 第六章 – 使用WebSocket作为网络层
- 第七章 – 一致性
- 附录B - 强制性规范声明（非规范）
- 附录C - MQTT v5.0新特性总结（非规范）
此附录是非规范性的，只作为本文档正文中可以找到的大量一致性声明的摘要提供。参考 第七章 一致性要求限制列表。
| 规范声明序号 | 规范声明 |
|---|---|
| [MQTT-1.5.4-1] | UTF-8编码字符串中的数据必须是按照 [Unicode] 规范定义的，在RFC 3629 [RFC3629] 中重申的有效的UTF-8格式。特别需要指出的是，这些数据不能包含字符码在U+D800和U+DFFF之间的数据。 |
| [MQTT-1.5.4-2] | UTF-8编码的字符串不能包含空字符U+0000。 |
| [MQTT-1.5.4-3] | UTF-8编码序列0xEF 0xBB 0xBF总是被解释为U+FEFF ("零宽度非换行空白字符") ，无论它出现在字符串的什么位置，报文接收者都不能跳过或者剥离它。 |
| [MQTT-1.5.5-1] | 编码值必须使用表示该值所需的最少字节数。 |
| [MQTT-1.5.7-1] | 所有的字符串都必须符合UTF-8编码字符串的要求。 |
| [MQTT-2.1.3-1] | 如果标记位被标记为“保留”，则保留它以供将来使用，并且必须设置为所列出的值。 |
| [MQTT-2.2.1-2] | QoS等级为0的PUBLISH报文不能包含报文标识符。 |
| [MQTT-2.2.1-3] | 客户端每次发送新的SUBSCRIBE，UNSUBSCRIBE或PUBLISH（当QoS等级>0）MQTT控制报文时，它必须为其分配一个当前未被使用的非0报文标识符。 |
| [MQTT-2.2.1-4] | 服务端每次发送新的PUBLISH（当QoS等级>0）MQTT控制报文时，它必须为其分配一个当前未被使用的非0报文标识符。 |
| [MQTT-2.2.1-5] | PUBACK，PUBREC，PUBREL或PUBCOMP报文必须包含PUBLISH报文中发送的原始报文标识符。 |
| [MQTT-2.2.1-6] | SUBACK和UNSUBACK报文必须包含相应的SUBSCRIBE和UNSUBSCRIBE报文中使用的报文标识符。 |
| [MQTT-2.2.2-1] | 如果没有属性，属性长度必须为0。 |
| [MQTT-3.1.0-1] | 当协议错误并关闭网络连接时，服务端必须处理客户端发送的第二个CONNECT报文。 |
| [MQTT-3.1.2-1] | 协议名必须是UTF-8字符串"MQTT"。如果服务端不想接受CONNECT，并希望透露它是MQTT服务端，它可以发送一个包含原因码为0x84（不支持的协议版本）的CONNACK报文，然后必须关闭网络连接。 |
| [MQTT-3.1.2-2] | 如果协议版本不为5，且服务端不想接受CONNECT报文，则服务端可以发送一个包含原因码为0x84（不支持的协议版本）的CONNACK报文，然后必须关闭网络连接。 |
| [MQTT-3.1.2-3] | 服务端必须验证CONNECT报文的保留标志位（第0位）是否为 0。 |
| [MQTT-3.1.2-4] | 如果CONNECT报文的新开始标志被设置为1，则客户端和服务端必须丢弃任何已存在的会话并开始一个新的会话。 |
| [MQTT-3.1.2-5] | 如果CONNECT报文的新开始标志被设置为0，并且存在与该客户标识符相关联的会话，服务端必须基于此会话恢复与客户端的通信。 |
| [MQTT-3.1.2-6] | 如果CONNECT报文的新开始标志被设置为0，并且不存在与该客户标识符相关联的会话，则服务端必须创建一个新的会话。 |
| [MQTT-3.1.2.7] | 遗嘱标志被设置为1，表示遗嘱消息必须被存储在服务端并与会话相关联。 |
| [MQTT-3.1.2-8] | 在网络连接被关闭且遗嘱延时间隔已过或会话结束时遗嘱消息必须被发布，除非遗嘱消息被服务端在收到包含原因码为0x00（正常关闭）的DISCONNECT报文后删除或关于此客户标识符的一个新的网络连接在遗嘱消息间隔过期之前被打开。 |
| [MQTT-3.1.2-9] | 如果遗嘱标志被设置为0，连接标志中的遗嘱QoS等级和遗嘱保留字段将会被服务端使用，遗嘱属性、遗嘱主题和遗嘱消息字段必须存在于载荷中。 |
| [MQTT-3.1.2-10] | 一旦遗嘱消息被发布或者服务端收到包含原因码为0x00（正常关闭）的DISCONNECT报文，遗嘱消息必须从服务端的会话中删除。 |
| [MQTT-3.1.2-11] | 如果遗嘱标志设置为0，遗嘱QoS等级必须也设置为0 (0x00)。 |
| [MQTT-3.1.2-12] | 如果遗嘱标志设置为1，遗嘱QoS等级可以被设置为0（0x00），1（0x01）或2（0x02）。 |
| [MQTT-3.1.2-13] | 如果遗嘱标志被设置为0，遗嘱保留标志也必须设置为0。 |
| [MQTT-3.1.2-14] | 如果遗嘱标志被设置为1时，如果遗嘱保留被设置为0，则服务端必须将遗嘱消息当做非保留消息发布。 |
| [MQTT-3.1.2-15] | 如果遗嘱保留被设置为1，则服务端必须将遗嘱消息当做保留消息发布。 |
| [MQTT-3.1.2-16] | 如果用户名标志被设置为0，有效载荷中不能包含用户名字段。 |
| [MQTT-3.1.2-17] | 如果用户名标志被设置为0，有效载荷中必须包含用户名字段。 |
| [MQTT-3.1.2-18] | 如果密码标志被设置为0，有效载荷中不能包含密码字段。 |
| [MQTT-3.1.2-19] | 如果密码标志被设置为1，有效载荷中必须包含密码字段。 |
| [MQTT-3.1.2-20] | 如果保持连接值不为0，且没有任何其它的MQTT控制报文可以发送，客户端必须发送一个PINGREQ 报文。 |
| [MQTT-3.1.2-21] | 如果服务端返回的CONNACK报文中包含服务端保持连接，客户端必须使用此值代替其发送的保持连接。 |
| [MQTT-3.1.2-22] | 如果保持连接的值非零，并且服务端在1.5倍的保持连接时间内没有收到客户端的MQTT控制报文，它必须断开客户端的网络连接，并判定网络连接已断开。 |
| [MQTT-3.1.2-23] | 如果网络连接关闭时会话过期间隔大于0，则客户端与服务端必须存储会话状态。 |
| [MQTT-3.1.2-24] | 服务端不能发送超过最大报文长度的报文给客户端。 |
| [MQTT-3.1.2-25] | 当报文过大而不能发送时，服务端必须丢弃这些报文，然后当做应用消息发送已完成处理。 |
| [MQTT-3.1.2-26] | 服务端在一个PUBLISH报文中发送的主题别名不能超过客户端设置的主题别名最大值。 |
| [MQTT-3.1.2-27] | 如果主题别名最大值没有设置，或者设置为零，则服务端不能向此客户端发送任何主题别名。 |
| [MQTT-3.1.2-28] | 请求响应信息值为0，表示服务端不能返回响应信息。 |
| [MQTT-3.1.2-29] | 如果请求问题信息的值为0，服务端可以选择在CONNACK或DISCONNECT报文中返回原因字符串或用户属性，但不能在除PUBLISH，CONNACK或DISCONNECT之外的报文中发送原因字符串或用户属性。 |
| [MQTT-3.1.2-30] | 如果客户端在CONNECT报文中设置了认证方法，则客户端在收到CONNACK报文之前不能发送除AUTH或DISCONNECT之外的报文。 |
| [MQTT-3.1.3-1] | CONNECT报文的载荷中包含由可变报头中的标志确定的一个或多个以长度为前缀的字段。这些字段若存在，必须按照客户标识符、遗嘱属性、遗嘱主题、遗嘱载荷、用户名、密码的顺序出现。 |
| [MQTT-3.1.3-2] | 客户端和服务端都必须使用客户标识符识别两者之间的MQTT会话相关的状态。 |
| [MQTT-3.1.3-3] | 客户标识符必须存在，且作为CONNECT报文载荷的第一个字段出现。 |
| [MQTT-3.1.3-4] | 客户标识符必须被编码为UTF-8字符串。 |
| [MQTT-3.1.3-5] | 服务端必须允许1到23个字节长的UTF-8编码的客户标识符，客户标识符只能包含这些字符："0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" |
| [MQTT-3.1.3-6] | 服务端可以允许客户端提供一个零字节的客户标识符，如果这样做了，服务端必须将这看作特殊情况并分配唯一的客户标识符给那个客户端。 |
| [MQTT-3.1.3-7] | 服务端必须假设客户端提供了那个唯一的客户标识符，且必须在CONNACK报文中返回分配的客户标识符。 |
| [MQTT-3.1.3-8] | 如果服务端拒绝了某个客户标识符，它可以发送包含原因码0x85（客户标识符无效）的CONNACK报文作为对客户端的CONNECT报文的回应 ，如4.13节所述。之后必须关闭网络连接。 |
| [MQTT-3.1.3-9] | 如果某个会话在遗嘱延时间隔到期之前创建了新的网络连接，则服务端不能发送遗嘱消息。 |
| [MQTT-3.1.3-10] | 服务端在发布遗嘱消息时必须维护用户属性的顺序。 |
| [MQTT-3.1.3-11] | 遗嘱主题必须为UTF-8编码的字符串。 |
| [MQTT-3.1.3-12] | 如果用户名标志被设置为1，用户名为载荷中下一个字段。用户名必须是UTF-8编码字符串。 |
| [MQTT-3.1.4-1] | 服务端必须按照3.1节的要求验证CONNECT报文，如果报文不符合规范，服务端关闭网络连接。 |
| [MQTT-3.1.4-2] | 服务端可以检查CONNECT报文的内容是不是满足任何进一步的限制，应该执行身份验证和授权检查。如果任何一项检查没通过，服务端必须关闭网络连接。 |
| [MQTT-3.1.4-3] | 如果客户标识符所代表的客户端已经连接到此服务端，那么向原有的客户端发送一个包含原因码为0x8E（会话被接管）的DISCONNECT报文，并且必须关闭原有的网络连接。 |
| [MQTT-3.1.4-4] | 服务端必须对新开始标志进行处理。 |
| [MQTT-3.1.4-5] | 服务端必须使用包含原因码为0x00（成功）的CONNACK报文对客户端的CONNECT报文进行确认。 |
| [MQTT-3.1.4-6] | 如果服务端拒绝了CONNECT报文，它不能处理客户端在CONNECT报文之后发送的任何除AUTH以外的报文。 |
| [MQTT-3.2.0-1] | 服务端在发送任何除AUTH以外的报文之前必须先发送包含原因码为0x00（成功）的CONNACK报文。 |
| [MQTT-3.2.0-2] | 服务端在一次网络连接中不能发送多个CONNACK报文。 |
| [MQTT-3.2.2-1] | 第1个字节是连接确认标志，位7-1是保留位且必须设置为0。 |
| [MQTT-3.2.2-2] | 如果服务端接受一个新开始为1的连接，服务端在CONNACK报文中除了把原因码设置为0x00（成功）之外，还必须把会话存在标志设置为0。 |
| [MQTT-3.2.2-3] | 如果服务端接受一个新开始为0的连接，并且服务端已经保存了此客户标识符的会话状态，服务端在CONNACK报文中必须把会话存在标志设置为1。否则，服务端必须把会话存在标志设置为0。无论如何，服务端在CONNACK报文中必须把原因码设置为0x00（成功）。 |
| [MQTT-3.2.2-4] | 如果客户端没有保存的会话状态，但收到会话存在标志为1，客户端必须关闭网络连接。 |
| [MQTT-3.2.2-5] | 如果客户端保存了会话状态，但收到的会话存在标志为0，客户端若要继续此网络连接，它必须丢弃其保存的会话状态。 |
| [MQTT-3.2.2-6] | 如果服务端发送的CONNACK报文中原因码非0，它必须把会话存在标志设置为0。 |
| [MQTT-3.2.2-7] | 如果服务端发送了一个包含原因码大于等于128的CONNACK报文，它随后必须关闭网络连接。 |
| [MQTT-3.2.2-8] | 服务端发送的CONNACK报文必须设置一种原因码。 |
| [MQTT-3.2.2-9] | 如果服务端不支持Qos为1或2的PUBLISH报文，服务端必须在CONNACK报文中发送最大服务质量以指定其支持的最大QoS值。 |
| [MQTT-3.2.2-10] | 即使不支持QoS为1或2的PUBLISH报文，服务端也必须接受请求QoS为0、1或2的SUBSCRIBE报文。 |
| [MQTT-3.2.2-11] | 如果从服务端接收到了最大QoS等级，则客户端不能发送超过最大QoS等级所指定的QoS等级的PUBLISH报文。 |
| [MQTT-3.2.2-12] | 如果服务端收到包含遗嘱的QoS超过服务端处理能力的CONNECT报文，服务端必须拒绝此连接。服务端应该使用包含原因码为0x9B（不支持的QoS等级）的CONNACK报文进行错误处理，随后必须关闭网络连接。 |
| [MQTT-3.2.2-13] | 如果服务端收到一个包含保留标志位1的遗嘱消息的CONNECT报文且服务端不支持保留消息，服务端必须拒绝此连接请求，且应该发送包含原因码为0x9A（不支持保留）的CONNACK报文，随后必须关闭网络连接。 |
| [MQTT-3.2.2-14] | 从服务端接收到的保留可用标志为0时，客户端不能发送保留标志设置为1的PUBLISH报文。 |
| [MQTT-3.2.2-15] | 客户端不应该发送超过最大报文长度的报文给服务端。 |
| [MQTT-3.2.2-16] | 如果客户端使用长度为0的客户标识符，服务端必须回复包含分配客户标识符的CONNACK报文。分配客户标识符必须是没有被服务端的其他会话所使用的新客户标识符。 |
| [MQTT-3.2.2-17] | 客户端在一个PUBLISH报文中发送的主题别名值不能超过服务端设置的主题别名最大值。 |
| [MQTT-3.2.2-18] | 如果主题别名最大值没有设置，或者设置为0，则客户端不能向此服务端发送任何主题别名。 |
| [MQTT-3.2.2-19] | 如果加上原因字符串之后的CONNACK报文长度超出了客户端指定的最大报文长度，则服务端不能发送此原因字符串。 |
| [MQTT-3.2.2-20] | 如果加上用户属性之后的CONNACK报文长度超出了客户端指定的最大报文长度，则服务端不能发送此属性。 |
| [MQTT-3.2.2-21] | 如果服务端发送了服务端保持连接属性，客户端必须使用此值代替其在CONNECT报文中发送的保持连接时间值。 |
| [MQTT-3.2.2-22] | 如果服务端没有发送服务端保持连接属性，服务端必须使用客户端在CONNECT报文中设置的保持连接时间值。 |
| [MQTT-3.3.1-1] | 客户端或服务端请求重发一个PUBLISH报文时，必须将DUP标志设置为1。 |
| [MQTT-3.3.1-2] | 对于QoS为0的消息，DUP标志必须设置为0。 |
| [MQTT-3.3.1-3] | 发送（出站）的PUBLISH报文与收到（入站）的PUBLISH报文中的DUP标志是独立设置的，它的值必须单独的根据发送（出站）的PUBLISH报文是否是一个重发来确定。 |
| [MQTT-3.3.1-4] | PUBLISH报文的2个QoS比特位不能同时设置为1。 |
| [MQTT-3.3.1-5] | 如果客户端发给服务端的PUBLISH报文的保留标志被设置为1，服务端必须存储此应用消息，并用其替换此话题下任何已存在的消息。 |
| [MQTT-3.3.1-6] | 如果载荷为空，消息可以正常被服务端所处理，但是此话题下的任何保留消息必须被丢弃，并且此话题未来的订阅者将不会收到保留消息。 |
| [MQTT-3.3.1-7] | 载荷为空的保留消息将不能被存储在服务端。 |
| [MQTT-3.3.1-8] | 如果客户端发给服务端的PUBLISH报文的保留标志位为0，服务器不能把此消息存储为保留消息，也不能丢弃或替换任何已存在的保留消息。 |
| [MQTT-3.3.1-9] | 如果保留消息处理属性被设置为0，服务端必须发送主题与客户端订阅的主题过滤器相匹配的所有保留消息。 |
| [MQTT-3.3.1-10] | 如果保留消息处理属性被设置为1，如果尚不存在匹配的订阅，服务端必须发送主题与客户端订阅的主题过滤器相匹配的所有保留消息。如果已存在相匹配的订阅，服务器不能发送这些保留消息。 |
| [MQTT-3.3.1-11] | 如果保留消息处理属性被设置为2，服务器不能发送这些保留消息。 |
| [MQTT-3.3.1-12] | 如果发布保留订阅选项被设置为0，服务端在转发应用消息时必须将保留标志设置为0，而不管收到的PUBLISH报文中保留标志位如何设置的。 |
| [MQTT-3.3.1-13] | 如果发布保留订阅选项被设置为1，服务端在转发应用消息时必须将保留标志设置为与收到的PUBLISH消息中的保留标志位相同。 |
| [MQTT-3.3.2-1] | 主题名必须是PUBLISH报文可变报头的第一个字段。它必须是UTF-8编码的字符串。 |
| [MQTT-3.3.2-2] | PUBLISH报文中的主题名不能包含通配符。 |
| [MQTT-3.3.2-3] | 服务端发送给订阅客户端的PUBLISH报文中的主题名必须匹配该订阅的主题过滤器。 |
| [MQTT-3.3.2-4] | 服务端必须把接收到的应用消息中的载荷格式指示原封不动的发给所有的订阅者。 |
| [MQTT-3.3.2-5] | 如果消息过期间隔已过期，服务端还没开始向匹配的订阅者交付该消息，则服务端必须删除该订阅者的消息副本。 |
| [MQTT-3.3.2-6] | 服务端发送给客户端的PUBLISH报文中必须包含消息过期间隔，值为接收时间减去消息在服务端的等待时间。 |
| [MQTT-3.3.2-7] | 接收端不能将任何主题别名映射从一个网络连接转发到另一个网络连接。 |
| [MQTT-3.3.2-8] | 发送端不能发送包含主题别名值为0的PUBLISH报文。 |
| [MQTT-3.3.2-9] | 客户端不能发送主题别名值大于服务端的CONNACK报文中指定的主题别名最大值的PUBLISH报文。 |
| [MQTT-3.3.2-10] | 客户端必须接受所有值大于0且小于等于其发送的CONNECT报文中的主题别名最大值的主题别名。 |
| [MQTT-3.3.2-11] | 服务端不能发送包含主题别名值大于客户端在CONNECT报文中指定的主题别名最大值的PUBLISH报文。 |
| [MQTT-3.3.2-12] | 服务端必须接受所有值大于0且小于等于其发送的CONNACK报文中的主题别名最大值的主题别名。 |
| [MQTT-3.3.2-13] | 响应主题必须是UTF-8编码的字符串。 |
| [MQTT-3.3.2-14] | 响应主题不能包含通配符。 |
| [MQTT-3.3.2-15] | 服务端在收到应用消息时必须将响应主题原封不动的发送给所有的订阅者。 |
| [MQTT-3.3.2-16] | 服务端在收到应用消息时必须原封不动的把对比数据发送给所有的订阅者。 |
| [MQTT-3.3.2-17] | 服务端在转发应用消息到客户端时必须原封不动的把所有的用户属性放在PUBLISH报文中。 |
| [MQTT-3.3.2-18] | 服务端在转发应用消息时必须保持所有用户属性的先后顺序。 |
| [MQTT-3.3.2-19] | 内容类型必须是UTF-8编码的字符串。 |
| [MQTT-3.3.2-20] | 服务端必须把收到的应用消息中的内容类型原封不动的发送给所有的订阅者。 |
| [MQTT-3.3.4-1] | PUBLISH报文的接收端必须按照PUBLISH报文中的QoS等级发送响应报文。 |
| [MQTT-3.3.4-2] | 这种情况下，服务端必须按照所有匹配的订阅中最大的QoS等级把消息发送给客户端。 |
| [MQTT-3.3.4-3] | 如果客户端在这些重叠的订阅中指定了订阅标识符，服务端在发布这些订阅相匹配的消息时必须包含这些订阅标识符。 |
| [MQTT-3.3.4-4] | 如果服务端对这些重叠的订阅只发送一条相匹配的消息，服务端必须在PUBLISH报文中包含所有的相匹配的订阅标识符（如果存在），但没有顺序要求。 |
| [MQTT-3.3.4-5] | 如果服务端对这些重叠的订阅必须分别发送相匹配的消息，则每个PUBLISH报文中包含与订阅相匹配的订阅标识符（如果存在）。 |
| [MQTT-3.3.4-6] | 从客户端发送给服务端的PUBLISH报文不能包含订阅标识符。 |
| [MQTT-3.3.4-7] | 客户端在收到服务端的PUBACK，PUBCOMP或包含原因码大于等于128的PUBREC报文之前，不能发送数量超过服务端的接收最大值的QoS为1和2的PUBLISH报文。 |
| [MQTT-3.3.4-8] | 客户端不能延迟发送任何报文，除了PUBLISH报文--如果已发送且没有收到确认的PUBLISH报文数量已达到服务端的接收最大值。 |
| [MQTT-3.3.4-9] | 服务端在接收到客户端的PUBACK，PUBCOMP或包含原因码大于等于128的PUBREC报文之前，不能发送数量超过客户端的接收最大值的QoS为1和2的PUBLISH报文。 |
| [MQTT-3.3.4-10] | 服务端不能延迟发送任何报文，除了PUBLISH报文--如果已发送且没有收到确认的PUBLISH报文数量已到达客户端的接收最大值。 |
| [MQTT-3.4.2-1] | 服务端或客户端发送PUBACK报文时必须设置其中一种PUBACK原因码。 |
| [MQTT-3.4.2-2] | 如果加上原因字符串之后的PUBACK报文长度超出了接收端指定的最大报文长度，则发送端不能发送此原因字符串。 |
| [MQTT-3.4.2-3] | 如果加上用户属性之后的PUBACK报文长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.5.2-1] | 服务端或客户端发送PUBREC报文时必须设置其中一种原因码。 |
| [MQTT-3.5.2-2] | 发送端使用此值向接收端提供附加信息。如果加上原因字符串之后的PUBREC报文长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.5.2-3] | 如果加上用户属性之后的PUBREC报文长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.6.1-1] | PUBREL固定报头的第3，2，1，0位是保留位，必须被设置为0，0，1，0。服务端必须将其它的任何值都当做是不合法的并关闭网络连接。 |
| [MQTT-3.6.2-1] | 客户端或服务端发送PUBREL报文时必须设置其中一种PUBREL原因码。 |
| [MQTT-3.6.2-2] | 如果加上原因字符串之后的PUBREL报文长度超出了接收端指定的最大报文长度，则发送端不能发送此原因字符串。 |
| [MQTT-3.6.2-3] | 如果加上用户属性之后的PUBREL报文长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.7.2-1] | 服务端或客户端发送PUBCOMP报文时必须设置一种PUBCOMP原因码。 |
| [MQTT-3.7.2-2] | 如果加上原因字符串之后的PUBCOMP报文长度超出了接收端指定的最大报文长度，则发送端不能发送此原因字符串。 |
| [MQTT-3.7.2-3] | 如果加上用户属性之后的PUBCOMP报文长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.8.1-1] | SUBSCRIBE报文固定报头第3，2，1，0比特位是保留位，必须被设置为0，0，1，0。服务端必须将其他的任何值都当做是不合法的并关闭网络连接。 |
| [MQTT-3.8.3-1] | 主题过滤器必须为UTF-8 编码的字符串。 |
| [MQTT-3.8.3-2] | 载荷必须包含至少一个主题过滤器/订阅选项对。 |
| [MQTT-3.8.3-3] | 订阅选项的第2比特表示非本地选项。值为1，表示应用消息不能被转发给发布此消息的客户标识符。 |
| [MQTT-3.8.3-4] | 共享订阅时把非本地选项设为1将造成协议错误。 |
| [MQTT-3.8.3-5] | 订阅选项的第6和7比特为将来所保留。服务端必须把此保留位非0的SUBSCRIBE报文当做无效报文。 |
| [MQTT-3.8.4-1] | 当服务端收到来自客户端的SUBSCRIBE报文时，必须使用SUBACK报文作为相应。 |
| [MQTT-3.8.4-2] | SUBACK报文必须和待确认的SUBSCRIBE报文有相同的报文标识符。 |
| [MQTT-3.8.4-3] | 如果服务端收到的SUBSCRIBE报文中的一个主题过滤器与当前会话的一个非共享订阅相同，那么必须使用新的订阅替换现存的订阅。 |
| [MQTT-3.8.4-4] | 如果保留处理选项为0，任何匹配该主题过滤器的保留消息必须被重发，但替换订阅不能造成应用消息的丢失。 |
| [MQTT-3.8.4-5] | 如果服务端收到的SUBSCRIBE报文包含多个主题过滤器，服务端必须当做收到一系列多个SUBSCRIBE报文来处理--除了将它们的响应组合为单个SUBACK响应。 |
| [MQTT-3.8.4-6] | 服务端发送给客户端的SUBACK报文必须为每一个主题过滤器/订阅选项对包含一个原因码。 |
| [MQTT-3.8.4-7] | 此原因码必须说明为该订阅授予的最大QoS等级，或指示订阅失败。 |
| [MQTT-3.8.4-8] | 响应该订阅的应用消息QoS等级必须为该消息发布时的QoS等级和服务端授予的最大QoS等级二者最小值。 |
| [MQTT-3.9.2-1] | 如果加上原因字符串之后的SUBACK报文长度超出了客户端指定的最大报文长度，则服务端不能发送此原因字符串。 |
| [MQTT-3.9.2-2] | 如果加上用户属性之后的SUBACK报文长度超出了客户端指定的最大报文长度，则服务端不能发送此属性。 |
| [MQTT-3.9.3-1] | SUBACK报文中的原因码顺序必须与SUBSCRIBE报文中的主题过滤器顺序相匹配。 |
| [MQTT-3.9.3-2] | 服务端发送SUBACK报文时必须对收到的每一个主题过滤器设置一种原因码。 |
| [MQTT-3.10.1-1] | UNSUBSCRIBE固定报头的第3，2，1，0位是保留位且必须分别设置为0，0，1，0。服务端必须认为任何其它的值都是不合法的并关闭网络连接。 |
| [MQTT-3.10.3-1] | UNSUBSCRIBE报文中的主题过滤器必须为UTF-8编码的字符串。 |
| [MQTT-3.10.3-2] | UNSUBSCRIBE报文有效载荷必须包含至少一个主题过滤器。 |
| [MQTT-3.10.4-1] | 服务端必须对客户端的UNSUBSCRIBE报文中提供的主题过滤器（不管是否包含通配符）逐个字符与当前持有的主题过滤器集进行比较。如果任何过滤器完全匹配，则必须删除其拥有的订阅。 |
| [MQTT-3.10.4-2] | 当服务端收到UNSUBSCRIBE报文，它必须停止添加为了交付给客户端的与主题过滤器相匹配的任何新消息。 |
| [MQTT-3.10.4-3] | 当服务端收到UNSUBSCRIBE报文，它必须完成任何已经开始发送给客户端的、与主题过滤器相匹配的、QoS等级为1或2的消息。 |
| [MQTT-3.10.4-4] | 服务端必须发送UNSUBACK报文以响应客户端的UNSUBSCRIBE请求。 |
| [MQTT-3.10.4-5] | UNSUBACK报文必须包含和UNSUBSCRIBE报文相同的报文标识符。即使没有删除任何主题订阅，服务端也必须发送一个UNSUBACK响应。 |
| [MQTT-3.10.4-6] | 如果服务端收到的UNSUBSCRIBE报文包含多个主题过滤器，服务端必须当做收到一系列多个UNSUBSCRIBE报文来处理--除了将它们的响应组合为单个SUBACK响应。 |
| [MQTT-3.11.2-1] | 如果加上原因字符串之后的UNSUBACK报文长度超出了客户端指定的最大报文长度，则服务端不能发送此原因字符串。 |
| [MQTT-3.11.2-2] | 如果加上用户属性之后的UNSUBACK报文长度超出了客户端指定的最大报文长度，则服务端不能发送此属性。 |
| [MQTT-3.11.3-1] | UNSUBACK报文中的原因码顺序必须与UNSUBSCRIBE报文中的主题过滤器顺序相匹配。 |
| [MQTT-3.11.3-2] | 服务端发送UNSUBACK报文时对于每个收到的主题过滤器，必须使用一个取消订阅原因码。 |
| [MQTT-3.12.4-1] | 服务端必须发送PINGRESP报文响应客户端的PINGREQ报文。 |
| [MQTT-3.14.0-1] | 服务端不能发送DISCONNECT报文，直到它发送了包含原因码小于0x80的CONNACK报文之后。 |
| [MQTT-3.14.1-1] | 服务端或客户端必须验证所有的保留位都被设置为0，如果他们不为0，发送包含原因码为0x81（无效报文）的DISCONNECT报文。 |
| [MQTT-3.14.2-1] | 客户端或服务端发送DISCONNECT报文时必须使用一种DISCONNECT原因码。 |
| [MQTT-3.14.2-2] | 会话过期间隔不能由服务端的DISCONNECT报文发送。 |
| [MQTT-3.14.2-3] | 如果此属性使得DISCONNECT报文的长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.14.2-4] | 如果加上用户属性之后的DISCONNECT报文长度超出了接收端指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.14.4-1] | 发送端发送完DISCONNECT报文之后不能再在此网络连接上发送任何MQTT控制报文。 |
| [MQTT-3.14.4-2] | 发送端发送完DISCONNECT报文之后必须关闭网络连接。 |
| [MQTT-3.14.4-3] | 接收到包含原因码为0x00（成功）的DISCONNECT时，服务端必须丢弃任何与当前连接相关的遗嘱消息，而不发布它。 |
| [MQTT-3.15.1-1] | AUTH报文固定报头第3，2，1，0位是保留位，必须全设置为0。客户端或服务端必须把其他值当做无效值并关闭网络连接。 |
| [MQTT-3.15.2-1] | AUTH报文的发送端必须使用一种认证原因码。 |
| [MQTT-3.15.2-2] | 如果加上原因字符串之后的AUTH报文长度超出了接收端所指定的最大报文长度，则发送端不能发送此属性。 |
| [MQTT-3.15.2-3] | 如果加上用户属性之后的AUTH报文长度超出了接收端指定的最大报文长度，则服务端不能发送此属性。 |
| [MQTT-4.1.0-1] | 当网络连接打开时，客户端和服务端不能丢弃会话状态。 |
| [MQTT-4.2.0-1] | 客户端或服务端必须支持使用一个或多个提供有序的、可靠的、双向传输（从客户端到服务端和从服务端到客户端）字节流传输的底层传输协议。 |
| [MQTT-4.1.0-2] | 当网络连接被关闭并且会话过期间隔已过时，服务端必须丢弃会话状态。 |
| [MQTT-4.3.1-1] | 对于QoS等级0的分发协议，发送端必须发送QoS等于0，DUP等于0的PUBLISH报文。 |
| [MQTT-4.3.2-1] | 对于QoS等级1的分发协议，发送端每次发送新的应用消息都必须分配一个未使用的用户标识符。 |
| [MQTT-4.3.2-2] | 对于QoS等级1的分发协议，发送端发送的PUBLISH报文必须包含报文标识符且QoS等于1，DUP等于0。 |
| [MQTT-4.3.2-3] | 对于QoS等级1的分发协议，发送端必须将这个PUBLISH报文看作是未确认的 ，直到从接收端那收到对应的PUBACK报文。 |
| [MQTT-4.3.2-4] | 对于QoS等级1的分发协议，接收端响应的PUBACK报文必须包含一个报文标识符，这个标识符来自接收到的、已经接受所有权的PUBLISH报文。 |
| [MQTT-4.3.2-5] | 对于QoS等级1的分发协议，接收端发送了PUBACK报文之后，接收端必须将任何包含相同报文标识符的入站PUBLISH报文当做一个新的消息，并忽略它的DUP标志的值。 |
| [MQTT-4.3.3-1] | 对于QoS等级2的分发协议，发送端必须给要发送的新应用消息分配一个未使用的报文标识符。 |
| [MQTT-4.3.3-2] | 对于QoS等级2的分发协议，发送端PUBLISH报文必须包含报文标识符且报文的QoS等于2，DUP等于0。 |
| [MQTT-4.3.3-3] | 对于QoS等级2的分发协议，发送端必须将这个PUBLISH报文看作是*未确认*的 ，直到从接收端那收到对应的PUBREC报文。 |
| [MQTT-4.3.3-4] | 对于QoS等级2的分发协议，收到发送端发送的包含原因码小于0x80的PUBREC报文后必须发送一个PUBREL报文。PUBREL报文必须包含与原始PUBLISH报文相同的报文标识符。 |
| [MQTT-4.3.3-5] | 对于QoS等级2的分发协议，发送端必须将这个PUBREL报文看作是*未确认*的 ，直到从接收端那收到对应的PUBCOMP报文。 |
| [MQTT-4.3.3-6] | 对于QoS等级2的分发协议，发送端一旦发送了对应的PUBREL报文就不能重发这个PUBLISH报文。 |
| [MQTT-4.3.3-7] | 对于QoS等级2的分发协议，如果PUBLISH报文已发送，不能应用消息过期属性。 |
| [MQTT-4.3.3-8] | 对于QoS等级2的分发协议，接收端响应的PUBREC报文必须包含报文标识符，这个标识符来自接收到的、已经接受所有权的PUBLISH报文。 |
| [MQTT-4.3.3-9] | 对于QoS等级2的分发协议，如果接收端发送了包含原因码大于等于0x80的PUBREC报文，它必须将后续包含相同报文标识符的PUBLISH报文当做是新的应用消息。 |
| [MQTT-4.3.3-10] | 对于QoS等级2的分发协议，接收端在收到对应的PUBREL报文之前，接收端必须发送PUBREC报文确认任何后续的具有相同报文标识符的PUBLISH报文。在这种情况下，它不能重复分发消息给任何后续的接收者。 |
| [MQTT-4.3.3-11] | 对于QoS等级2的分发协议，接收端必须发送包含与PUBREL相同报文标识符的PUBCOMP报文作为对PUBREL报文的响应。 |
| [MQTT-4.3.3-12] | 对于QoS等级2的分发协议，接收端发送PUBCOMP报文之后，必须将后续包含相同报文标识符的PUBLISH报文当做是新的应用消息。 |
| [MQTT-4.3.3-13] | 对于QoS等级2的分发协议，接收端必须继续QoS等级2确认序列，即使它已经应用了消息过期属性。 |
| [MQTT-4.4.0-1] | 客户端以新开始标志为0且会话存在的情况下重连时，客户端和服务端都必须使用原始报文标识符重新发送任何未被确认的PUBLISH报文（当QoS > 0）和PUBREL报文。这是唯一要求客户端或服务端重发消息的情况。客户端和服务端不能在其他任何时间重发消息。 |
| [MQTT-4.4.0-2] | 如果收到包含原因码大于等于0x80的PUBACK或PUBREC，则对应的PUBLISH报文被看作已确认，且不能被重传。 |
| [MQTT-4.5.0-1] | 当服务端接受入站应用消息的所有权时，它必须将消息添加到订阅匹配的客户端的会话状态中。 |
| [MQTT-4.5.0-2] | 客户端必须按照可用的服务质量（QoS）规则确认它收到的任何PUBLISH报文，不管它是否选择处理其包含的应用消息。 |
| [MQTT-4.6.0-1] | 重发任何之前的PUBLISH报文时，客户端必须按原始PUBLISH报文的发送顺序重发（适用于QoS等级1和QoS等级2 消息）。 |
| [MQTT-4.6.0-2] | 客户端必须按照对应的PUBLISH报文的顺序发送PUBACK报文（QoS等级1消息）。 |
| [MQTT-4.6.0-3] | 客户端必须按照对应的PUBLISH报文的顺序发送PUBREC报文（QoS等级2消息）。 |
| [MQTT-4.6.0-4] | 客户端必须按照对应的PUBREC报文的顺序发送PUBREL报文（QoS等级2消息）。 |
| [MQTT-4.6.0-5] | 当服务端处理发布到有序主题的消息时，它必须按照消息从任何给定客户端接收的顺序发送PUBLISH报文给消费端（对于同一主题和QoS等级）。 |
| [MQTT-4.6.0-6] | 默认情况下，服务端转发非共享订阅的消息时，必须将每个主题都视为有序主题。 |
| [MQTT-4.7.0-1] | 主题过滤器中可以使用通配符，但是主题名不能使用通配符。 |
| [MQTT-4.7.1-1] | 多层通配符必须单独指定，或者跟在主题层级分隔符后面。不管哪种情况，它都必须是主题过滤器的最后一个字符。 |
| [MQTT-4.7.1-2] | 在主题过滤器的任意层级都可以使用单层通配符，包括第一个和最后一个层级。在使用它时，它必须占据过滤器的整个层级。 |
| [MQTT-4.7.2-1] | 服务端不能将$字符开头的主题名匹配通配符（\#或+）开头的主题过滤器。 |
| [MQTT-4.7.3-1] | 所有的主题名和主题过滤器必须至少包含一个字符。 |
| [MQTT-4.7.3-2] | 主题名和主题过滤器不能包含空字符 (Unicode U+0000) \[[Unicode](#Unicode)\]。 |
| [MQTT-4.7.3-3] | 主题名和主题过滤器是UTF-8编码字符串，它们不能超过65,535字节。 |
| [MQTT-4.7.3-4] | 匹配订阅时，服务端不能对主题名或主题过滤器执行任何规范化处理，不能修改或替换任何未识别的字符。 |
| [MQTT-4.8.2-1] | 除非另有说明，如果服务端或客户端遇到了协议违规的行为，它必须关闭传输这个协议违规控制报文的网络连接。 |
| [MQTT-4.8.2-2] | 如果客户端或服务端处理入站控制报文时遇到了瞬时错误，它必须关闭传输那个控制报文的网络连接。 |
| [MQTT-4.8.2-3] | 向客户端发送应用消息时，服务端必须考虑授予客户端的QoS等级。 |
| [MQTT-4.8.2-4] | 服务端必须在客户端重新连接时完成向该客户端的消息分发。 |
| [MQTT-4.8.2-5] | 如果客户端的会话在客户端重连之前终止，服务端不能把此消息发送给其他订阅的客户端。 |
| [MQTT-4.8.2-6] | 如果客户端对来自服务端的PUBLISH报文使用包含原因码大于等于0x80的PUBACK或PUBREC报文进行响应，服务端必须丢弃应用消息而不尝试将其发送给任何其他订阅者。 |
| [MQTT-4.9.0-1] | 客户端或服务端必须将其初始发送配额设置为不超过接收最大值的非0值。 |
| [MQTT-4.9.0-2] | 每当客户端或服务端发送了一个QoS等级大于0的PUBLISH报文，它就会减少发送配额。如果发送配额减为0，客户端或服务端不能再发送任何QoS等级大于0的PUBLISH报文。 |
| [MQTT-4.9.0-3] | 它可以继续发送QoS为0的PUBLISH报文，也可以选择暂停发送这些报文。即使配额为0，客户端和服务端也必须继续处理和响应其他MQTT控制报文。 |
| [MQTT-4.12.0-1] | 如果服务端不支持客户端提供的认证方法，它可以发送一个包含原因码0x8C（无效的认证方法）或0x87（未授权）的CONNACK报文，并且必须关闭网络连接。 |
| [MQTT-4.12.0-2] | 如果服务端需要额外的信息来完成认证，它可以向客户端发送AUTH报文，此报文必须包含原因码0x18（继续认证）。 |
| [MQTT-4.12.0-3] | 客户端通过发送另一个AUTH报文响应来自服务端的AUTH报文，此报文必须包含原因码0x18（继续认证）。 |
| [MQTT-4.12.0-4] | 服务端可以在处理过程中随时拒绝认证。它可以发送包含原因码大于等于0x80的CONNACK报文，如4.13节所述，并且必须关闭网络连接。 |
| [MQTT-4.12.0-5] | 如果初始CONNECT报文包含认证方法属性，则所有的AUTH报文和成功的CONNACK报文必须包含与CONNECT报文中相同的认证方法属性。 |
| [MQTT-4.12.0-6] | 如果客户端在CONNECT报文中没有包含认证方法，则服务端不能发送AUTH报文，且不能在CONNACK报文中发送认证方法。 |
| [MQTT-4.12.0-7] | 如果客户端在CONNECT报文中没有包含认证方法，则客户端不能向服务端发送AUTH报文。 |
| [MQTT-4.12.1-1] | 如果客户端在CONNECT报文中提供了认证方法，它可以在收到CONNACK报文之后的任何时间通过发送包含原因码0x19（重新认证）的AUTH报文发起重新认证。客户端必须将认证方法设置为与最初验证网络连接时的认证方法一致。 |
| [MQTT-4.12.1-2] | 如果重新认证失败，客户端或服务端应该发送包含适当原因码的DISCONNECT报文，如 section 4.13节 所述。并且必须关闭网络连接。 |
| [MQTT-4.13.1-1] | 当服务端检测到无效报文或协议错误，并且本规范中给出了相应的原因码时，它必须关闭网络连接。 |
| [MQTT-4.13.2-1] | CONNACK报文和DISCONNECT报文允许使用大于等于0x80的原因码以指示网络连接将被关闭。如果某个大于等于0x80的原因码被指定，无论是否发送CONNACK报文或DISCONNECT报文，必须关闭网络连接。 |
| [MQTT-6.0.0-1] | MQTT控制报文必须使用WebSocket二进制数据帧发送。如果收到任何其它类型的数据帧，接收者必须关闭网络连接。 |
| [MQTT-6.0.0-2] | 单个WebSocket数据帧可以包含多个或者部分MQTT报文。接收者不能假设MQTT控制报文按WebSocket帧边界对齐。 |
| [MQTT-6.0.0-3] | 客户端必须将字符串"mqtt"包含在它提供的WebSocket子协议列表里。 |
| [MQTT-6.0.0-4] | 服务端选择和返回的WebSocket子协议名必须是mqtt。 |