MQTTV3.1协议规范中文版

作者： International Business Machines Corporation (IBM) Eurotech翻译：明歌协议原文： /software/dw/webservices/ws-mqtt/mqtt-v3r1.html摘要MQ 遥测传输（MQ Telemetry Transport，MQTT）是一个轻量级的基于代理的发布/订阅式消息传输协议，它的设计目标是开放、简单、轻量和易于实现。这些特征使它适用于各种受限环境，比如，但不限于： 网络代价昂贵，低带宽或不可靠。 在嵌入设备中运行，处理器和内存资源有限。该协议的特性包括： 使用发布/订阅消息模式，提供一对多的消息分发，解除应用程序耦合。 消息传输对有效载荷内容不可知。 使用 TCP/IP 提供基础网络连接。 有 3 个消息发布服务质量级别： “至多一次” ，消息发布完全依赖于底层 TCP/IP 网络。消息有可能丢失或重复。这一级别可应用于如下情景，如环境传感器数据，丢失一次读记录无所谓，因为很快下一次读记录就会产生。 “至少一次” ，确保消息到达，但消息重复有可能发生。 “只有一次” ，确保消息到达且只到达一次。这一级别可用于如计费系统等场景，在计费系统中，消息丢失或重复可能会导致生成错误的费用。 轻量传输，开销很小（固定头部的长度只有 2 字节），协议交换最小化，以降低网络流量。 提供一种机制，当客户端异常中断时，利用 Last Will 和 Testament 特性来通知有关各方。版权声明 1999-2010 Eurotech, International Business Machines Corporation (IBM). All rights reserved.Permission to copy and display the MQ Telemetry Transport specification (the “Specification“), in any medium without fee or royalty is hereby granted by Eurotech and International Business Machines Corporation (IBM) (collectively, the “Authors“), provided that you include the following on ALL copies of the Specification, or portions thereof, that you make:A link or URL to the Specification at one of the Authors websites. The copyright notice as shown in the Specification. The Authors each agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to their respective patents that they deem necessary to implement the Specification. THE SPECIFICATION IS PROVIDED “AS IS,“ AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE SPECIFICATION.The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Specification will at all times remain with the Authors.No other rights are granted by implication, estoppel or otherwise.目录1. 简介 1.1 V3.1 与 V3 之间的变化2. 消息格式 2.1 固定头部 2.2 可变头部 2.3 有效载荷 2.4 消息标识符 2.5 MQTT 和 UTF-8 2.6 未使用的位3. 命令消息 3.1 CONNECT 3.2 CONNACK 3.3 PUBLISH 3.4 PUBACK 3.5 PUBREC 3.6 PUBREL 3.7 PUBCOMP 3.8 SUBSCRIBE 3.9 SUBACK 3.10 UNSUBSCRIBE 3.11 UNSUBACK 3.12 PINGREQ 3.13 PINGRESP 3.14 DISCONNECT4. 消息流 4.1 交付质量级别和消息流 4.2 消息重传 4.3 消息排序5. 附录 A 主题通配符1. 简介该协议规范主要分为 3 个主要部分： 对所有类型的数据包都通用的消息格式 每种特定数据包的具体细节 数据包如何在服务器和客户端之间传输在附录中将介绍如何主题通配符（topic wildcards）的使用方法。1.1 V3.1 与 V3 之间的变化MQTT V3.1 中与 MQTT V3 之间的不同点如下所示： 添加用户验证，用户名和密码现在可以在 CONNECT 数据包中一并发送。 为解决一些安全问题，在 CONNACK 数据包中添加了新的返回码。 当客户端发送未授权的 PUBLISH 或 SUBSCRIBE 命令时，客户端不会收到相应的通知，即客户端不知道命令不会被执行。而且即使命令未被执行，该 MQTT 流也应该正常完成。 MQTT 中的字符串现在支持完整的 UTF-8 字符集，而不仅仅是 US-ASCII 子集。V3.1 中，通过 CONNECT 包传送的协议版本号仍然是“3”，与 V3 相比没有变化。现存的基于 MQTT V3 的服务器实现须通过正确考虑“剩余长度（Remaining Length）字段”，以及相应地忽略多余的安全信息来接受来自 V3.1 协议的客户端的连接。2. 消息格式每个 MQTT 命令消息的消息头部都包含了一个固定头部。其中一些类型的消息可能还需要一个可变头部和一个有效载荷（可理解为消息体）。消息头部的具体格式将在后面章节中进行详细介绍。2.1 固定头部（Fixed header）每个 MQTT 命令消息的消息头部都包含一个固定头部。固定头部的格式如下表如示。Byte 1包含消息类型和标志（包括 DUP，QoS level 和 RETAIN）字段。Byte 2包含剩余长度字段（至少 1 个字节，最多 4 个字节）。以下章节将详细介绍这些字段。所有数据的值都是以 big-endian（大端）模式存储：数据的高位字节存放在内存的低地址中，数据的低位字节存放在内存高地址中。一个 16 位字在内存中的存放顺序是先最高有效位（MSB），然后再最低有效位（LSB）。消息类型（Message Type）位置：byte 1, bits 7-4该字段为 4-bit 无符号值。当前协议版本中该字段的具体枚举值如下表所示。0：保留1：客户端请求连接服务器2：连接确认3：发布消息4：发布确认5：发布接收（有保证的交付第 1 部分）6：发布释放（有保证的交付第 2 部分）7：发布完成（有保证的交付第 3 部分）8：客户端订阅请求9：订阅确认10：客户端取消订阅请求11：取消订阅确认12：PING 请求13：PING 回复14：客户端断开连接15：保留标志位（Flags）固定头部第 1 个字节中剩余的部分包含 DUP，QoS 和 RETAIN 标志字段。相应 bit 位置如下表所示。DUP位置：byte 1，bit 3当客户端或服务器试图重发 PUBLISH、PUBREL、SUBSRIBE、UNSUBSCRIBE 消息时，该标志位要被置位（即设为 1）。这适用于消息的 QoS 标志值大于 0 的情况，此时消息确认是必需的。当 DUP 位被置位时，可变头部将包含一个消息 ID。消息的接收者应当将该标志视为该消息之前可能已收到的提示消息，而不该依赖于它进行消息重复检测。QoS位置：byte 1，bits 2-1该标志位标明 PUBLISH 消息的交付质量级别。具体的 QoS 级别如下表所示。Comment W1: 类似 proto buffer的vaint编码，第 8位表示是否还需要更高位的编码RETAIN位置：byte 1，bit 0该标志位只用于 PUBLISH 消息。当一个客户端发送一条 PUBLISH 消息给服务器，假设该消息所属的主题（topic）为 topicA，如果该标志位被置位（1），服务器在将该条消息发布给当前的所有 topicA的订阅者之后，还应当保持这条消息 。当 topicA出现了一个新的订阅者，则 topicA的最后一条保持消息应当发给该订阅者。当然，如果不存在保持消息，则什么也不用发。当消息发布者以基于 “report by exception” 的方式发送消息时，这个功能就特别有用，因为这种情况下，消息发送间隔往往较长。这个功能使得新的订阅者可以立刻收到之前保持的或上一个确定有效的消息。当服务器收到某个主题的 PUBLISH 消息时，对于之前已经订阅该主题的客户端，服务器将给这些客户端发送这一 PUBLISH 消息，发送前，服务器会将该消息的 RETAIN 标志置为 0（即不置位），不管服务器之前收到该 PUBLISH 消息时其 RETAIN 标志是否被置位。这样做可以使得区分它接收到的 PUBLISH 消息是服务器之前保持的（ RETAIN标志置位）还是即时收到的（RETAIN 标志不置位）。保持消息应当在重启服务器后仍能保留。如果服务器收到有效载荷长度为 0或重复主题的保持消息，服务器可以删除该保持消息。剩余长度（Remaining Length）位置：byte 2（从 byte 2，最大可至 byte 5）该字段表示当前消息的剩余内容的字节数，包括可变头部和有效载荷的数据。该字段本身的字节数是根据可变头部和有效载荷的长度不同而变化的。该可变长度编码方案如下：每个字节的低 7位（7-0 位）编码剩余长度的数据，第 8位表示后面是否还有编码剩余长度的字节。即每个字节编码 128 个值和一个“ 延续位”。所以只用一个字节时，最大只可表示 127 字节的长度。举例如下，十进制数字 64 只需用 1 个字节来编码，即 0x40。 十进制数字 321（=65 + 2x128）则需要用 2 个字节来编码，其中第 1 个字节为 1100 0001，该字节的低 7 位表示65，第 8 位表示后面还有字节；第 2 个字节为 0000 0010，表示 2x128。协议限制该字段最大为 4 个字节，这允许应用程序发送的最大消息长度为268435455（256MB），即 0xFF，0xFF，0xFF ，0x7F。下表给出了增加该字段的字节数时相应可表示的剩余长度值。该编码方案的算法如下所示，输入为一个十进制数（X），输出为编码后的结果。dodigit = X MOD 128X = X DIV 128/ if there are more digits to encode, set the top bit of this digitif ( X 0 )digit = digit OR 0x80endifoutput digitwhile ( X 0 )其中，MOD 是模运算符（在 C 语言中相当于%），DIV 表示整数除法（在 C 语言中相当于/），OR 是位或运算符（在 C 语言中相当于|）。相应地，剩余长度字段的解码算法如下所示：multiplier = 1value = 0dodigit = next digit from streamvalue += (digit AND 127) * multipliermultiplier *= 128while (digit AND 128) != 0)其中，AND 是位与运算符（在 C 语言中相当于&）。当该解码算法终止，value 等于剩余长度的字节数。值得注意的是，剩余长度编码不是可变头部的一部分。剩余长度的值不包括用于编码剩余长度的字节数。这部分“增加的长度 ”（1-3 字节）是固定头部的一部分，而不属于可变头部。译者注：可认为剩余长度字段虽然是固定的，但该字段的长度却是变化的（1-4 字节）。2.2 可变头部（Variable header）某些类型的 MQTT 命令消息还包含了一个可变头部，它位于固定头部和有效载荷之间。可变的剩余长度字段（1-4 字节）不是可变头部的一部分。剩余长度字段的值不包括该字段本身的长度。该值只包括可变头部和有效载荷。更多细节可可见固定头部。可变头部中各个字段的格式将在后续章节中进行详细介绍，介绍顺序与该字段在可变头部中的顺序一致。协议名称（Protocol name）协议名称字段只用于 MQTT CONNECT 消息的可变头部中。该字段以 UTF 编码方式显示协议名称：MQIsdp ，大小写如上所示。协议版本（Protocol version）协议版本字段只用于 MQTT CONNECT 消息的可变头部中。该字段用 8 位无符号值来表示客户端所使用的协议修订级别。当前版本协议中该字段的值为 3（0x03），如下表所示。连接标志（Connect flags）该字段用于 CONNECT 消息的可变头部中，占 1 字节，包括 Clean session、Will、Will QoS 和 Retain 标志。Clean session 标志位置：bit 1（在连接标志字节中，下同）如果没有被置位（即值为 0），则当客户端断线时，服务器必须保存该客户端的订阅信息，包括断线期间发布的该客户端订阅的主题中交付质量级别为 QoS 1 和 QoS2 的消息，这样当客户端重连时，这部分消息能确保被送达到客户端。同时，服务器还必须保持客户端在断线的那个时刻正在传输中的消息的状态，直到客户端重新连接。如果被置位（即值为 1），则服务器必须丢弃任何之前保持的该客户端的信息，将该连接视为“不存在（Clean）”。同时，当客户端断线时，服务器必须丢弃其所有状态。通常情况下，客户端会一直在其中一种模式下操作，不会进行切换。该选择取决于具体应用的需求。一个 Clean session 客户端将不会收到过时的信息，且它每次重连时都需要重新订阅主题。而一个 non-clean session 客户端则不会漏接任何它在断线时服务器发布的交付质量级别为 QoS 1 和 QoS 2 的消息。QoS 0 级别的消息由于只是尽可能的交付，所以它永远不会被存储保持。这个标志以前被称为“Clean start”。因为这个标志其实是作用于整个会话期间的，而不只是在连接的开始阶段，为了明确这个事实，所以将它重命名为“Clean session”。服务器可以提供一种管理机制，当确定一个客户端将永远不会重新连接时，可以清除该客户端的存储信息。连接标志中的第 0 位在目前协议版本中没有使用到，保留为将来使用。Will 标志位置：bit 2Will 消息是指当服务器与客户端通信过程中出现故障或客户端在保活时间内没有与服务器保持正常交流时，服务器特意发给客户端的消息。当客户端通过发送 DISCONNECT 消息正常断开时，Will 消息不会发送。如果 Will 标志被置位，则 Will QoS 标志和 Will Retain 标志的设置将会发生作用，同时，在有效载荷里必须填写 Will 主题和 Will 消息内容字段。Will 标志的格式如下表所示。连接标志中的第 0 位在目前协议版本中没有使用到，保留为将来使用。Will QoS位置：bit 4-3Will QoS 标志用来设置当客户端异常离线时，服务器发送的 Will 消息的交付质量级别。Will 消息的内容在客户端发送的 CONNECT 消息里的有效载荷里填写。如果 Will 标志被置位，则 Will QoS 字段必须填写，否则该字段的值将被忽略。Will QoS 字段的可选值有 0（0x00 ），1（0x01）和 2（ 0x02），格式如下表所示。连接标志中的第 0 位在目前协议版本中没有使用到，保留为将来使用。Will Retain 标志位置：bit 5Will Retain 标志指明服务器是否需要保持客户端异常离线时发送给客户端的 Will 消息。如果 Will 标志被置位，则 Will Retain 标志必须填写，否则其将被忽略。该标志的格式如下表所示。连接标志中的第 0 位在目前协议版本中没有使用到，保留为将来使用。User name and password 标志位置：bit 6 和 bit 7客户端在连接服务器时可以指定用户名和密码，通过将用户名标志和密码标志（可选）置位表明在 CONNECT 消息的有效载荷里包含有用户名和密码。如果将用户名标志置位，则必须在有效载荷里填写用户名字段，否则用户名字段将被忽略。同样地，如果密码标志被置位，则必须在有效载荷里填写密码字段，否则密码字段将被忽略。只提供密码而不提供用户名是不合法的。连接标志中的第 0 位在目前协议版本中没有使用到，保留为将来使用。保活计时器（Keep Alive timer）保活计时器用于 MQTT CONNECT 消息的可变头部中。保活计时器定义了服务器收到客户端消息的最大时间间隔，它以秒为单位。它使得服务器不需要等待漫长的 TCP/IP 超时就可以检测与客户端的网络连接是否断开。客户端有义务在每个保活时间间隔内至少发送一条消息给服务器。如果这期间没有业务相关的消息要发送，客户端则发送一个 PINGREQ 消息给服务器，相应地服务器返回一个 PINGRESQ 消息给客户端。如果服务器在 1.5 个保活时间（可宽容 0.5 个保活时间）内都没有收到客户端的消息，则服务器将其视为客户端发送了一个 DISCONNECT 消息，并断开与客户端的连接。这个动作不影响客户端的订阅。具体细节参见 DISCONNECT。如果客户端在发送 PINGREQ 后的一个保活时间内没有收到服务器发来的 PINGRESP 消息，则客户端可以关闭 TCP/IP 套接字连接。保活计时器用 2 个字节来表示，时间单位为秒。实际设定的值由特定应用决定，不过通常它的值都设为数分钟，最大值接近 18 个小时。如果设为 0，则表示客户端不断线。保活计时器的格式如下表所示。2 个字节的顺序为先 MSB，再 LSB(大端模式)。连接返回码（Connect return code）连接返回码用于 CONNACK 消息的可变头部中。这个字段用一个无符号字节来表示返回码。这些值的含义如下表所示。值为 0 的返回码通常表示连接成功。主题名（Topic name）主题名用于 PUBLISH 消息的可变头部中。主题名决定消息要发送到哪个信息通道。订阅者使用主题名来决定他们要从哪些信息通道接收消息。主题名是一个 UTF 编码字符串。更多信息参见 MQTT 和 UTF-8。主题名支持的最大字符度为 32767。2.3 有效载荷（Payload）以下类型的 MQTT 命令消息拥有一个有效载荷：CONNECT该有效载荷包含了一个或多个 UTF-8 编码字符串。它们包括标识客户端的唯一标识符、Will 主题和消息、要使用的用户名和密码。其中只有第一项是必选的，其余的取决于可变消息头部中的标志置位情况。SUBSCRIBE该有效载荷包含一系列要订阅的主题名，以及每个主题的 QoS 级别。这些字符串都是UTF 编码的。SUBACK该有效载荷包含一系列授权过的 QoS 级别。它们是服务器管理员允许授权给客户端订阅的各个主题的 QoS 级别。授权的 QoS 级别顺序与相应订阅的主题的顺序保持一致。PUBLISH该有效载荷只包含应用特定的数据。协议不对数据的属性和内容作任何假设，协议把消息的这部分内容视为一个 BLOB。如果你想要对有效载荷数据进行压缩，你必须自己在有效载荷里定义合适的标志来处理压缩事宜。你不能在固定状况或可变头部里定义与特定应用相关的标志。2.4 消息标识符（Message Identifiers）消息标识符用于以下 MQTT 消息的可变头部中：PUBLISH，PUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE，SUBACK，UNSUBSCRIBE，UNSUBACK。消息标识符（消息 ID）字段只存在于固定头部中 QoS 标志值为 1 或 2 的消息中。更多信息可参见交付质量级别和消息流。消息 ID 用 16 位无符号整数来表示，在同一个方向上的在传消息 ID 必须是唯一的。它通常是逐个消息递增的，但不强制如此。客户端与它所连接的服务器一样，都需要维护自己的消息 ID 列表，二者的消息 ID 列表互不影响。客户端在发送一个消息 ID 为 1 的 PUBLISH 消息的同时也有可能收到来自服务器的消息 ID 为 1 的 PUBLISH 消息。表示消息 ID 的 2 个字节的顺序为先 MSB，再 LSB（大端模式）。不要使用值为 0 的消息 ID。它是作为无效消息 ID 保留的。2.5 MQTT 和 UTF-8（MQTT and UTF-8）UTF-8 是一种针对 Unicode 的可变长度字符编码，它优化了 ASCII 字符集的编码，以支持基于文本的通信。在 MQTT 中，字符串编码的头 2 个字节用来记录字符串的长度，如下表所示。字符串长度表示所有字符经过 UTF-8 编码后的字节数，而不是字符串中字符的个数。例如，经过 UTF-8 编码后的字符串 OTWP 如下表所示。Java 中的 writeUTF() 和 readUTF() 数据流方法也使用这种格式。2.6 未使用的位（Unused bits）任何标明为未使用的位都应当置为 0。3. 命令消息（Command messages）3.1 CONNECT - 客户端请求连接服务器当客户端与服务器的 TCP/IP 套接字连接建立起来之后，必须发送一个 CONNECT 消息流来建立一个协议级别的会话。固定头部（Fixed header）固定头部的格式如下表所示。DUP、QoS 以及 RETAIN 标志在 CONNECT 消息中没有被使用到。剩余长度字段的值为可变头部（12 字节）和有效载荷的字节数总和。剩余长度字段自身的长度可能大于 1 个字节。可变头部（Variable header）一个可变头部例子的格式如下表所示。其中，用户名标志置位（1）。密码标志置位（1）。Clean session 标志置位（1）。保活计时器设置为 10 秒（0x000A）。Will 消息 Will 标志置位（1） Will QoS 字段值为 1 Will RETAIN 标志不置位（0）有效载荷（Payload）CONNECT 消息的有效载荷根据可变头部中各标志位的置位情况，包含一个或多个 UTF-8编码字符串。这些字符串如果出现的话，必须符合以下顺序：客户端 ID这是第 1 个 UTF 编码字符串。客户端 ID(Client ID)的长度为 1 至 23 个字符，服务器根据客户端 ID 可以指定到唯一的客户端。对于连接到某个服务器的所有客户端，它们的客户端ID 必须都是唯一的，客户端 ID 还是处理 QoS 级别 1 和 2 消息的关键。如果发送的CONNECT 消息中客户端 ID 的长度大于 23 个字符，则服务器会回复一个返回码值为2（标识符被拒绝）的 CONNACK 消息。Will 主题如果 Will 标志被置位，则 Will 主题将是有效载荷中的下一个字符串。Will 消息将会发送给Will 主题。消息的 QoS 级别和 RETAIN 状态在可变头部的 Will QoS 和 Will RETAIN 标志中设置。Will 消息（内容）如果 Will 标志被置位，则 Will 消息将是有效载荷中的下一个字符串。Will 消息定义了客户端异常离线时服务器发送给 Will 主题的消息内容。当然，消息内容可以为空（消息长度为0，但该字符串仍包含 2 个字节以记录其长度为 0）。尽管 Will 消息内容在 CONNECT 消息中是以 UTF-8 编码的，但当它最后被发送到 Will 主题时，只有消息的实际内容被发送，而不包括开头记录长度的 2 个字节。因而，消息必须只包含 7-bits ASCII 字符。用户名如果用户名标志被置位，则用户名将是有效载荷中的下一个字符串。用户名字段用于认证，标明了连接的用户的名字。建议用户名不超过 12 个字符，但不强制如此。值得注意的是，为了与 MQTT V3 版本协议兼容（V3 中不支持用户名密码）， 固定头部中的剩余长度字段的优先级应该高于用户名标志。服务器的实现必须允许用户名标志被置位，但不存在用户名字符串的情况。这是合法的，连接应该继续进行。密码如果密码标志被置位，则密码将是有效载荷中的下一个字符串。密码字段用于认证，对应于连接的用户名。建议密码不超过 12 个字符，但不强制如此。值得注意的是，为了与 MQTT V3 版本协议兼容（V3 中不支持用户名密码）， 固定头部中的剩余长度字段的优先级应该高于密码标志。服务器的实现必须允许密码标志被置位，但不存在密码字符串的情况。这是合法的，连接应该继续进行。回复（Response）服务器收到客户端发送的 CONNECT 消息后会回复一个 CONNACK 消息。如果在 TCP/IP 连接建立后的一段合理时间内服务器没有收到客户端发送的 CONNECT 消息，则服务器应该关闭这个连接。如果客户端在发送 CONNECT 消息后的一段合理时间内客户端没有收到服务器回复的 CONNACK 消息，则客户端应该关闭原先的 TCP/IP 连接。然后建立新的 TCP/IP 连接，并发送 CONNECT 消息以重起会话。以上两种场景中，一段合理时间的设置依赖于特定应用的需求和通信架构。如果尝试连接的客户端 ID 在服务器中已经存在，则服务器会断开“旧” 的客户端并与新的客户端完成连接操作。如果客户端发送了一个不合法的 CONNECT 消息，包括提供了不合法的协议名和协议版本号，服务器应该断开连接。如果服务器可以从 CONNECT 消息中识别并且明确客户端使用了一个不合法的协议，服务器可以尝试在断开连接前回复一个 CONNACK 消息，告知客户端“Connection Refused: unacceptable protocol version”。3.2 CONNACK - 连接确认当客户端向服务器发起 CONNECT 请求，服务器会回复其 CONNACK 消息。固定头部（Fixed header）固定头部的格式如下表所示。DUP、QoS 以及 RETAIN 标志在 CONNACK 消息中没有被使用到。可变头部（Variable header）可变头部的格式如下表所示。其中，连接返回码用 1 个无符号字节表示，具体含义如下表所示。如果客户端 ID 的长度不在 1-23 字节之间，服务器则会发送返回码 2（标识符被拒绝）。有效载荷（Payload）该类型消息没有有效载荷。3.3 PUBLISH - 发布消息当客户端想发布消息给感兴趣的订阅者时，客户端将发送一条 PUBLISH 消息给服务器。每个 PUBLISH 消息都关联一个主题名（也可称为话题或频道）。主题名是一个层次性的空间，它将订阅者感兴趣的信息资源进行分类。一个主题的消息将会发送给连接时订阅了该主题的客户端。当客户端订阅了一个或多个主题，属于这些主题的所有消息都将通过服务器发送相应 PUBLISH 消息给客户端。译者注：其实流程简单来说就是，发布者客户端发送某 topic 的 PUBLISH 消息给服务器，然后服务器再发 PUBLISH 消息给所有该 topic 的订阅者客户端。固定头部（Fixed header）固定头部的格式如下表所示。其中，QoS 级别设为 1。详见交付质量级别和消息流。DUP 标志设为 0。表示该消息是第一次发送。详见 DUP。RETAIN 标志设为 0。表示不保持。详见 RETAIN。剩余长度字段长度包括可变头部和有效载荷。字段自身长度为 1-4 字节。可变头部（Variable header）可变头部包含以下字段：主题名一个 UTF 编码字符串。不允许出现主题通配符字符。客户端订阅主题时主题名可以使用通配符，但服务器最终给订阅客户端发布 PUBLISH 消息时，消息里的主题名是和发布者客户端发布的主题名一致的，也就是肯定不含有通配符。消息 ID当消息的 QoS 级别为 1 或 2 时使用。详见消息标识符。下表是一个 PUBLISH 消息例子的可变头部。该头部的具体格式如下表所示。有效载荷（Payload）包含要发的消息的数据。数据的内容和格式由应用决定。固定头部中的剩余长度字段的值包括可变头部和有效载荷。当然，有限载荷长度为 0 的 PUBLISH 消息也是有效的。回复（Response）对 PUBLISH 消息的回复取决于 QoS 级别。具体见下表。动作（Action）PUBLISH 消息可以由发布者客户端发给服务器，也可以由服务器发给订阅者客户端。PUBLISH 消息的接收者（包括服务器或客户端）根据消息的 QoS 级别做出不同的反应。QoS 0仅仅将消息发送给所有相关的部分。QoS 1将消息持久化存储，将消息发送给所有相关的部分，回复 PUBACK 消息给发送者。QoS 2将消息持久化存储，先不将消息发送给所有相关的部分，而是先回复 PUBREC 消息给发送者。如果是