MQTT-3.1.1-CN 1
MQTT 协议 3.1.1 中文版
OASIS 标准
2014 年 10 月 29 日
规范链接
当前版本：
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc (Authoritative)
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf
以前の版本：
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.doc (Authoritative)
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.html
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/cos01/mqtt-v3.1.1-cos01.pdf
最新版本：
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc (Authoritative)
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf
技术委员会：
结构化信息标准促进组织 MQTT 技术委员会
主席：
拉斐尔·J·科恩 (raphael.cohn@stormmq.com), 个人
理查德·J·科彭 (coppen@uk.ibm.com), IBM
编辑：
安德鲁·班克斯 (Andrew_Banks@uk.ibm.com), IBM
拉胡尔·吉普塔 (rahul.gupta@us.ibm.com), IBM
相关文档：
本仕様はこれに関連する：
MQTT と NIST 网络安全框架 1.0 版。 編集者はジェフ・ブラウンとルイ·菲利普·拉穆勒。最新版
本： http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-
v1.0.html.
摘要：
MQTT は一つの客户端服务エンドアーキテクチャの発信布/订阅模式のメッセージ転送プロトコル。その設計思想は轻巧、开放、
简单、规范，因此易于实现。これらの特性によりそれは多くのシナリオにとって非常に良い選択です。，包括制限された環境、例えば
マシンとマシンの通信信（M2M）以及物联网环境（IoT），これらのシナリオは非常に小さなコードを必要とします码封装或者网络带宽
非常昂贵。
本协议运行に TCP/IP，或他は順序付きのものを提供する、可靠、双向接続されたネットワーク接続接上。它有以下特点：
使用发布/订阅消息模式，提供一対多のメッセージ配信とアプリケーションとの間の解耦。
消息传输不需要知道负载内容。
3つのレベルを提供する服务质量：.
MQTT-3.1.1-CN 2
“最多一次”，尽操作环境所能提供される最大限の努力力分发消息。消息可能会丢失。例如，この
等级可用于环境传感器数据，単一のデータ損失失没关系，なぜなら不久之后会再次发送。
“至少一次”，保证消息可以到达，しかし可能会重复。
“仅一次”，保证消息只到达一次。例如，このレベルは...で利用可能一个计费系统中で、ここで、もし
消息重复或丢失会导致不正确の課金。
非常に小さな伝送オーバーヘッドおよびプロトコルデータ交換换，最大限度减少网络流量
异常连接断开发生时，能通知到相关各方。
状态：
本文档最后由 OASIS メンバーで上に示された日付は最終のに修订或批准。承認されたレベルも上記に列挙されています。如果
要查看本文档最新しい改訂版については上記の...を確認する
最新版本
位置。技術委員会が作成したその他の改訂版および其它技
技術文書はすべてここに列挙されています里：https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=mqtt#technical 。
技术委员会成员本仕様に対するコメント论应该发送到技术委委員会のメーリングリスト表。其他人应该发送评论到技术委
委員会のパブリックコメント列表，方法点である击技术委员ウェブサイトの 发送评论 按钮，ウェブページのアドレスは
https://www.oasis-open.org/committees/mqtt/ 。
关于实现本规范不可欠なタスク何らかの特許が公開されているかどうか、およびその他の専門家ライセンス条項に関する情報息，请参考技
技術委員会のウェブサイトの知识产权部分（(https://www.oasis-open.org/committees/mqtt/ipr.php）。
引用格式：
引用此规范时应以下を使用すべき引文格式：
[mqtt-v3.1.1]
MQTT Version 3.1.1. Edited by Andrew Banks and Rahul Gupta. 29 October 2014. OASIS
Standard. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. Latest version:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html.
MQTT-3.1.1-CN 3
文档链接
MQTT 协议 3.1.1 中文翻译项目
MQTT 协议 3.1.1 中文版 PDF
修订记录
版 本
日 期
发布说明
1.0.0
2015-07-30
翻译全部文本，完成初步审校，公开发布第一版
1.0.1
2015-10-22
修订几处笔误，增补几处未翻翻訳されたテキスト
关于译者
GitHub
Blog
Email
MQTT-3.1.1-CN 4
目录
1 概述 ...................................................................................................................................................... 8
1.1 MQTT プロトコルの組織構造 ........................................................................................................................ 8
1.2 术语 ..................................................................................................................................................... 8
1.3 规范引用 .............................................................................................................................................. 9
1.4 非规范引用 ........................................................................................................................................ 10
1.5 数据表示 ............................................................................................................................................ 12
1.5.1 二进制位 .................................................................................................................................... 12
1.5.2 整数数值 .................................................................................................................................... 12
1.5.3 UTF-8 编码字符串 ..................................................................................................................... 12
1.6 编辑约定 ............................................................................................................................................ 13
2 MQTT 控制报文格式 ........................................................................................................................... 14
2.1 MQTT 制御メッセージの構造 ...................................................................................................................... 14
2.2 固定报头 ............................................................................................................................................ 14
2.2.1 MQTT 制御メッセージのタイプ .............................................................................................................. 14
2.2.2 标志 ........................................................................................................................................... 15
2.2.3 剩余长度 .................................................................................................................................... 16
2.3 可变报头 ............................................................................................................................................ 17
2.3.1 报文标识符 ................................................................................................................................. 17
2.4 有效载荷 ............................................................................................................................................ 19
3 MQTT 控制报文 .................................................................................................................................. 20
3.1 CONNECT – 连接服务端 .................................................................................................................. 20
3.1.1 固定报头 .................................................................................................................................... 20
3.1.2 可变报头 .................................................................................................................................... 20
3.1.3 有效载荷 .................................................................................................................................... 26
3.1.4 响应 ........................................................................................................................................... 27
3.2 CONNACK – 确认连接请求 .............................................................................................................. 28
3.2.1 固定报头 .................................................................................................................................... 28
3.2.2 可变报头 .................................................................................................................................... 28
3.2.3 有效载荷 .................................................................................................................................... 30
3.3 PUBLISH – 发布消息 ........................................................................................................................ 30
3.3.1 固定报头 .................................................................................................................................... 30
3.3.2 可变报头 .................................................................................................................................... 32
3.3.3 有效载荷 .................................................................................................................................... 33
3.3.4 响应 ........................................................................................................................................... 33
3.3.5 动作 ........................................................................................................................................... 33
3.4 PUBACK –发布确认 .......................................................................................................................... 33
3.4.1 固定报头 .................................................................................................................................... 33
3.4.2 可变报头 .................................................................................................................................... 34
3.4.3 有效载荷 .................................................................................................................................... 34
MQTT-3.1.1-CN 5
3.4.4 动作 ........................................................................................................................................... 34
3.5 PUBREC – 发布收到（QoS 2，第一步） ........................................................................................ 34
3.5.1 固定报头 .................................................................................................................................... 34
3.5.2 可变报头 .................................................................................................................................... 34
3.5.3 有效载荷 .................................................................................................................................... 35
3.5.4 动作 ........................................................................................................................................... 35
3.6 PUBREL – 发布释放（QoS 2，第二步） ......................................................................................... 35
3.6.1 固定报头 .................................................................................................................................... 35
3.6.2 可变报头 .................................................................................................................................... 35
3.6.3 有效载荷 .................................................................................................................................... 36
3.6.4 动作 ........................................................................................................................................... 36
3.7 PUBCOMP – 发布完成（QoS 2，第三步） ..................................................................................... 36
3.7.1 固定报头 .................................................................................................................................... 36
3.7.2 可变报头 .................................................................................................................................... 36
3.7.3 有效载荷 .................................................................................................................................... 36
3.7.4 动作 ........................................................................................................................................... 36
3.8 SUBSCRIBE - 订阅主题 ................................................................................................................... 37
3.8.1 固定报头 .................................................................................................................................... 37
3.8.2 可变报头 .................................................................................................................................... 37
3.8.3 有效载荷 .................................................................................................................................... 37
3.8.4 响应 ........................................................................................................................................... 39
3.9 SUBACK – 订阅确认 ......................................................................................................................... 40
3.9.1 固定报头 .................................................................................................................................... 40
3.9.2 可变报头 .................................................................................................................................... 40
3.9.3 有效载荷 .................................................................................................................................... 41
3.10 UNSUBSCRIBE –取消订阅 ............................................................................................................ 41
3.10.1 固定报头 .................................................................................................................................. 42
3.10.2 可变报头 .................................................................................................................................. 42
3.10.3 有效载荷 .................................................................................................................................. 42
3.10.4 响应 ......................................................................................................................................... 43
3.11 UNSUBACK – 取消订阅确认 .......................................................................................................... 43
3.11.1 固定报头 .................................................................................................................................. 44
3.11.2 可变报头 .................................................................................................................................. 44
3.11.3 有效载荷 .................................................................................................................................. 44
3.12 PINGREQ – 心跳请求 ..................................................................................................................... 44
3.12.1 固定报头 .................................................................................................................................. 44
3.12.2 可变报头 .................................................................................................................................. 45
3.12.3 有效载荷 .................................................................................................................................. 45
3.12.4 响应 ......................................................................................................................................... 45
3.13 PINGRESP – 心跳响应 ................................................................................................................... 45
3.13.1 固定报头 .................................................................................................................................. 45
MQTT-3.1.1-CN 6
3.13.2 可变报头 .................................................................................................................................. 45
3.13.3 有效载荷 .................................................................................................................................. 45
3.14 DISCONNECT –断开连接............................................................................................................... 45
3.14.1 固定报头 .................................................................................................................................. 46
3.14.2 可变报头 .................................................................................................................................. 46
3.14.3 有效载荷 .................................................................................................................................. 46
3.14.4 响应 ......................................................................................................................................... 46
4 操作動作 ............................................................................................................................................. 47
4.1 状态存储 ............................................................................................................................................ 47
4.1.1 非规范示例 ................................................................................................................................. 47
4.2 网络连接 ............................................................................................................................................ 47
4.3 服务质量レベルとプロトコルフロー .................................................................................................................. 48
4.3.1 QoS 0:最多分发一次 .................................................................................................................. 48
4.3.2 QoS 1: 至少分发一次 ................................................................................................................. 48
4.3.3 QoS 2: 仅分发一次 .................................................................................................................... 49
4.4 消息分发重试 .................................................................................................................................... 51
4.5 消息收到 ............................................................................................................................................ 51
4.6 消息排序 ............................................................................................................................................ 51
4.7 件名と主题过滤器 ......................................................................................................................... 52
4.7.1 主题通配符 ................................................................................................................................. 52
4.7.2 以$开ヘッダーの件名 ........................................................................................................................... 53
4.7.3 主题意味と用法 ......................................................................................................................... 53
4.8 错误处理 ............................................................................................................................................ 54
5 安全 .................................................................................................................................................... 55
5.1 概述 ................................................................................................................................................... 55
5.2 MQTT 解決策：セキュリティと认证 ........................................................................................................... 55
5.3 軽量の暗号化と制約付きデバイス .................................................................................................................. 55
5.4 实现注意事项 .................................................................................................................................... 55
5.4.1 客户端身份验证 ......................................................................................................................... 56
5.4.2 客户端授权 ................................................................................................................................. 56
5.4.3 服务端身份验证 ......................................................................................................................... 56
5.4.4 控制メッセージおよびアプリケーションメッセージメッセージの完全性 .................................................................................................... 56
5.4.5 控制メッセージおよびアプリケーションメッセージメッセージの機密性 .................................................................................................... 56
5.4.6 消息伝送の否認防止认性 .............................................................................................................. 56
5.4.7 检测クライアントとサーバーエンドポイントの盗用 ....................................................................................................... 57
5.4.8 检测異常な動作 ............................................................................................................................. 57
5.4.9 其它の安全に関する注意事項项 .................................................................................................................. 57
5.4.10 使用 SOCKS 代理 .................................................................................................................... 58
5.4.11 安全配置文件 ........................................................................................................................... 58
6 使用 WebSocket 作ネットワーク層として .............................................................................................................. 59
6.1 IANA 注意事项 .................................................................................................................................. 59
MQTT-3.1.1-CN 7
7 一致性 ................................................................................................................................................. 60
7.1 一致性目标 ........................................................................................................................................ 60
7.1.1 MQTT 服务端 ............................................................................................................................. 60
7.1.2 MQTT 客户端 ............................................................................................................................. 60
附录 B 强制性规范声明（非规范） ............................................................................................................. 62
MQTT-3.1.1-CN 8
1 概述
1.1 MQTT 协プロトコルの組織構造
本仕様は7つに分かれている章节：
第一章 - 介绍
第二章 – MQTT 控制报文格式
第三章 – MQTT 控制报文
第四章 – 操作動作
第五章 – 安全
第六章 – 使用 WebSocket ネットワークトランスポート層として t
第七章 – 一致性目标
1.2 术语
本仕様で用いられる关键字 必须 MUST，不能 MUST NOT，要求 REQUIRED，将会 SHALL，不会 SHALL
NOT，应该 SHOULD，不应该 SHOULD NOT，推荐 RECOMMENDED，可以 MAY，可选 OPTIONAL
すべて...に従って IETF RFC 2119 [RFC2119] 中の記述解释。
网络连接（Network Connection）：
MQTT 使用される底层传输协议基础设施。
客户端使用它连接服务端。
それは順序付けられた、可靠の、双向字节流传输。
例子见 4.2 节。
应用消息（Application Message）：
MQTT 协议通过网络传输应用数据。应用消息通过 MQTT 伝送時に、それらは関連するサーバ务质量（QoS）と主题
（Topic）。
客户端（Client）：
使用 MQTT のプログラムまたはデバイス。クライアントは常に通信过网络连接到服务端。它可以
发布应用消息给其它相关のクライアント。.
订阅以请求関連するアプリケーションメッセージを受信する
取消订阅以移除接受应用消息のリクエスト。
サーバーから接続を切断接。
服务端（Server）：
一个程序或设备、送信メッセージとしてメッセージのクライアントとサブスクリプションを要求するクライアントの間の仲介。サーバー务端
クライアントからのネットワーク接続を受け入れる
接受客户端发布のアプリケーションメッセージ
MQTT-3.1.1-CN 9
クライアントの購読を処理購読と購読解除请求。
转发应用消息给符合条コンポーネントのクライアント订阅。
订阅（Subscription）：
订阅包含一个主题过滤器（Topic Filter）と最大のサーバー务质量（QoS）レベル。サブスクリプションと単一会话
（Session）关联。会话可以複数のサブスクリプションを含む。会话各サブスクリプションには1つの異なるトピックフィルタ滤器。
主题名（Topic Name）：
アプリケーションメッセージに付加上のタグ、サーバーは既知であり、サブスクリプションと阅匹配。服务端发送アプリケーションメッセージの一个副本给每一个匹配
クライアントの購読。
主题过滤器（Topic Filter:）：
購読に含まれる一个表达式，用関連するものを示す一个或多个主题。主题过滤器可以使用通配符。
会话（Session）：
クライアントとサーバー間の状態交換互。一些会话持续时長さとネットワーク络连接一样，他のものもあり得るクライアントとサーバーの複数の
个连续网络连接间扩展。
控制报文（MQTT Control Packet）：
通过网络连接发送信された情報データ包。MQTT 仕様は十四のさまざまな異なるタイプの制御パケット文，其中一个（PUBLISH 报
文）用于传输应用消息。
1.3 规范引用
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March
1997.
http://www.ietf.org/rfc/rfc2119.txt
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003
http://www.ietf.org/rfc/rfc3629.txt
[RFC5246]
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
http://www.ietf.org/rfc/rfc5246.txt
[RFC6455]
Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
http://www.ietf.org/rfc/rfc6455.txt
[Unicode]
The Unicode Consortium. The Unicode Standard.
http://www.unicode.org/versions/latest/
MQTT-3.1.1-CN 10
1.4 非规范引用
[RFC793]
Postel, J. Transmission Control Protocol. STD 7, IETF RFC 793, September 1981.
http://www.ietf.org/rfc/rfc793.txt
[AES]
Advanced Encryption Standard (AES) (FIPS PUB 197).
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[DES]
Data Encryption Standard (DES).
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
[FIPS1402]
Security Requirements for Cryptographic Modules (FIPS PUB 140-2)
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[IEEE 802.1AR]
IEEE Standard for Local and metropolitan area networks - Secure Device Identity
http://standards.ieee.org/findstds/standard/802.1AR-2009.html
[ISO29192]
ISO/IEC 29192-1:2012 Information technology -- Security techniques -- Lightweight cryptography -- Part
1: General
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425
[MQTT NIST]
MQTT supplemental publication, MQTT and the NIST Framework for Improving Critical Infrastructure
Cybersecurity
http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html
[MQTTV31]
MQTT V3.1 Protocol Specification.
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
[NISTCSF]
Improving Critical Infrastructure Cybersecurity Executive Order 13636
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf
[NIST7628]
NISTIR 7628 Guidelines for Smart Grid Cyber Security
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf
[NSAB]
NSA Suite B Cryptography
http://www.nsa.gov/ia/programs/suiteb_cryptography/
MQTT-3.1.1-CN 11
[PCIDSS]
PCI-DSS Payment Card Industry Data Security Standard
https://www.pcisecuritystandards.org/security_standards/
[RFC1928]
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC
1928, March 1996.
http://www.ietf.org/rfc/rfc1928.txt
[RFC4511]
Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June
2006.
http://www.ietf.org/rfc/rfc4511.txt
[RFC5077]
Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session
Resumption without Server-Side State", RFC 5077, January 2008.
http://www.ietf.org/rfc/rfc5077.txt
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
http://www.ietf.org/rfc/rfc5280.txt
[RFC6066]
Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January
2011.
http://www.ietf.org/rfc/rfc6066.txt
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
http://www.ietf.org/rfc/rfc6749.txt
[RFC6960]
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public
Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
http://www.ietf.org/rfc/rfc6960.txt
[SARBANES]
Sarbanes-Oxley Act of 2002.
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm
[USEUSAFEHARB]
U.S.-EU Safe Harbor
http://export.gov/safeharbor/eu/eg_main_018365.asp
MQTT-3.1.1-CN 12
1.5 数据表示
1.5.1 二进制位
バイト内のビットは 0 到 7。第 7 ビットは最上位有效位，第 0 ビットは最下位ビットです。
1.5.2 整数数值
整数値は 16 位，使用大端序（big-endian，高位字节下位バイトの前前）。これは意味を一つ持つ 16 位のバイトはネットワーク上に
ネットワーク上では最高として表される有效字节（MSB），后面跟最下位有効バイト节（LSB）。
1.5.3 UTF-8 编码字符串
後で説明される制御制御パケット内のテキストこのフィールドはエンコードされる UTF-8 フォーマットの文字串。UTF-8 [RFC3629] は一つの効率のな
Unicode 字符编码形式、基数をサポートするためにテキストベースの通信、それは ASCII 字符の符号化を最適化した。
每一个字符串都有一个两字节長さフィールドとして接頭辞として、それはとえるこの文字列を出力する UTF-8 エンコードされたバイト数，それらに图例
1.1 UTF-8 编コード文字列の構造 中描述。したがって、伝送可能な UTF-8 编码文字列のサイズには1つの限制，不能超过
65535 字节。
除非另有说明，すべての UTF-8 编码字符串の長さはすべて必ず 0 到 65535 字节この範囲内。
图例 1.1 UTF-8 编码字符文字列の終わり构
二进制位
7
6
4
3
2
1
0
byte 1
文字列の長さの最大高有效字节（MSB）
byte 2
文字列の長さの最大低有效字节（LSB）
byte 3 ….
如果长度大于 0、ここは UTF-8 エンコードされた文字数据。
UTF-8 编码文字列内の文字符数据必须に従って Unicode 规范 [Unicode] 定義された...と...で RFC3629 [RFC3629] 中
再確認された有効な UTF-8 格式。特别需指摘すべきは、これらの数据不能文字コードを含む U+D800 と U+DFFF の間の
数据。如果服务端或客户端收を含むもの无效 UTF-8 文字の制御报文，它必须关闭网络连接 [MQTT-
1.5.3-1]。
UTF-8 编码の文字列不能包含空字符 U+0000。如果客户端或服务端收を含むもの U+0000 の制御制报
文，它必须关闭网络连接 [MQTT-1.5.3-2]。
数据中不应该以下を含む Unicode 代码点のエンコード。もし一个接收者（服务端或客户端）はパケットを受信した含下列
任意の文字の制御报文，它可以关闭网络连接：
U+0001 と U+001F の間の控制字符
U+007F と U+009F の間の控制字符
Unicode 规范定義された非字符代码点（例如 U+0FFFF）
Unicode 规范定義された保護留字符（例如 U+0FFFF）
MQTT-3.1.1-CN 13
UTF-8 编码序列 0XEF 0xBB 0xBF 常に...として解釈される U+FEFF（零宽度非换行空白字符），无论それは文字に現れる
文字列のどの位置に、报文接收者都不能跳过或者剥离它 [MQTT-1.5.3-3]。
1.5.3.1 非规范示例
例如，字符串 A𪛔 である一个拉丁字母 A 後ろに続く代码点 U+2A6D4(它表示一个中日韩统一表意文字
扩展 B 中の文字)，この字符串编码如下：
图例 1.2 UTF-8 编码字符串非规范示例
Bit
7
6
5
4
3
2
1
0
byte 1
字符串长度 MSB (0x00)
0
0
0
0
0
0
0
0
byte 2
字符串长度 LSB (0x05)
0
0
0
0
0
1
0
1
byte 3
‘A’ (0x41)
0
1
0
0
0
0
0
1
byte 4
(0xF0)
1
1
1
1
0
0
0
0
byte 5
(0xAA)
1
0
1
0
1
0
1
0
byte 6
(0x9B)
1
0
0
1
1
0
1
1
byte 7
(0x94)
1
0
0
1
0
1
0
0
1.6 编辑约定
本规范用黄色高ハイライトされたテキストラベル一致性声明，每个一致性声すべてにこの種の1つが割り当てられた形式の参照：[MQTT-x.x.x-
y]。
MQTT-3.1.1-CN 14
2 MQTT 控制报文格式
2.1 MQTT 制御メッセージの構造
MQTT 协议通过交换预定意味の MQTT 控制报文来通信。この節ではこれらのパケットを説明するの形式。
MQTT 控制报文由三部分组成，按照 图例 2.1 –MQTT 控制御パケットの構造 説明の順序：
图例 2.1 –MQTT 制御メッセージの结构
Fixed header 固定报头，所有控制报文都包含
Variable header 可变报头，部分控制报文包含
Payload 有效载荷，部分控制报文包含
2.2 固定报头
每个 MQTT 控制报文都包含一个固定报头。图例 2.2 -固固定ヘッダーの形式 固定ヘッダーについて説明ヘッダーの形式。
图例 2.2 -固定ヘッダーの形式式
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报メッセージのタイプ
用于指定された制御パケットタイプの标志位
byte 2…
剩余长度
2.2.1 MQTT 制御メッセージのタイプ
位置：第 1 个字节，二进制位 7-4。
として表される 4 位无符号値、これらの値の定義は...を参照 表格 2.1 -制御メッセージのタイプ
表格 2.1 -控制メッセージの種類型
名字
值
报文流动方向
描述
Reserved
0
禁止
保留
CONNECT
1
客户端到服务端
客户端请求连接服务端
CONNACK
2
服务端到客户端
连接报文确认
PUBLISH
3
两个方向都允许
发布消息
PUBACK
4
两个方向都允许
QoS 1 消息发布收到确认
PUBREC
5
两个方向都允许
发布收到（保证交付第一步）
PUBREL
6
两个方向都允许
发布释放（保证交付第二步）
MQTT-3.1.1-CN 15
PUBCOMP
7
两个方向都允许
QoS 2 消息发布完成（保证交互第三步）
SUBSCRIBE
8
客户端到服务端
客户端订阅请求
SUBACK
9
服务端到客户端
订阅请求报文确认
UNSUBSCRIBE
10
客户端到服务端
客户端取消订阅请求
UNSUBACK
11
服务端到客户端
取消订阅报文确认
PINGREQ
12
客户端到服务端
心跳请求
PINGRESP
13
服务端到客户端
心跳响应
DISCONNECT
14
客户端到服务端
客户端断开连接
Reserved
15
禁止
保留
2.2.2 标志
固定报头第 1 バイトの残りの 4 位 [3-0]包含每个 MQTT 控制报パケットタイプ固有のフラグ、见 表格 2.2 -标志位。
表格 2.2 中の任意のフラグが“保留”のフラグビットはすべて予約将来の使用のために、必须表の中に設定される列挙された値 [MQTT-
2.2.2-1]。如果不正なフラグを受信した場合、接收者必须关闭网络连接。有エラー処理に関する详细信息见 4.8 节 [MQTT-
2.2.2-2]。
表格 2.2 -标志位
控制报文
固定报头标志
Bit 3
Bit 2
Bit 1
Bit 0
CONNECT
Reserved
0
0
0
0
CONNACK
Reserved
0
0
0
0
PUBLISH
Used in MQTT 3.1.1
DUP
1
QoS
2
QoS
2
RETAIN
3
PUBACK
Reserved
0
0
0
0
PUBREC
Reserved
0
0
0
0
PUBREL
Reserved
0
0
1
0
PUBCOMP
Reserved
0
0
0
0
SUBSCRIBE
Reserved
0
0
1
0
SUBACK
Reserved
0
0
0
0
UNSUBSCRIBE
Reserved
0
0
1
0
UNSUBACK
Reserved
0
0
0
0
PINGREQ
Reserved
0
0
0
0
PINGRESP
Reserved
0
0
0
0
DISCONNECT
Reserved
0
0
0
0
MQTT-3.1.1-CN 16
DUP
1
=控制パケットの重複配信发标志
QoS
2
= PUBLISH 报文の服务质量等级
RETAIN
3
= PUBLISH メッセージの保留标志
PUBLISH 控制パケット内の DUP, QoS と RETAIN フラグの記述述见 3.3.1 节。
2.2.3 剩余长度
位置：第から 2 个字节开始。
剩余长度（Remaining Length）表示当前报文剩余部分の字节数，包括可变报頭と负载の数据。剩余长度
不包括用于编码剩余长度字段自身のバイト数。
剩余长度字段使用一个变长度编码方案，未満に対して 128 の値它使用单字节编码。より大きな值按下面の方法处理。
低 7 位有效位用于编码数据，最高有效位さらにあるかどうかを示すためにのバイト。因此每个字节可以编码 128 个数值
と一つの
延续位（
continuation bit
）
。剩余长度字段最大 4 个字节。
非规范评注
例如，十进制数 64 会される编码ために一个字节，数值である 64，十六进制表示ために 0x40,。十进制数字
321(=65+2*128)エンコードされる2バイトであり、最下位ビットは前。第一个字節は 65+128=193。注意最上位ビットは
1 表示后面至少还有一个字节。第二バイトは 2。
非规范评注
この允许 应用发送最大 256MB(268,435,455)大小 の控制 报文。 この个数 值に 报文中の表 示である：
0xFF,0xFF,0xFF,0x7F。
表格 2.4 残り長さフィールドの大小残りの長さフィールドを示している表される値は～に応じて字节增长。
表格 2.4 剩余长度フィールドの大小
字节数
最小值
最大值
1
0 (0x00)
127 (0x7F)
2
128 (0x80, 0x01)
16 383 (0xFF, 0x7F)
3
16 384 (0x80, 0x80, 0x01)
2 097 151 (0xFF, 0xFF, 0x7F)
4
2 097 152 (0x80, 0x80, 0x80, 0x01)
268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)
分别表示（每个バイトの下位 7 位用于编码数据、最上位ビットはフラグビットです）：
1 个字节时，から 0(0x00)到 127(0x7f)
2 个字节时，から 128(0x80,0x01)到 16383(0Xff,0x7f)
3 个字节时，から 16384(0x80,0x80,0x01)到 2097151(0xFF,0xFF,0x7F)
4 个字节时，から 2097152(0x80,0x80,0x80,0x01)到 268435455(0xFF,0xFF,0xFF,0x7F)
MQTT-3.1.1-CN 17
非规范评注
非负整数 X 使用变长编码方案のアルゴリズムは次のとおりである：
do
encodedByte = X MOD 128
X = X DIV 128
// if there are more data to encode, set the top bit of this byte
if ( X > 0 )
encodedByte = encodedByte OR 128
endif
'output' encodedByte
while ( X > 0 )
MOD モデルである运算，DIV 整数除算であり、OR ビット演算または（C 语言中ではそれぞれ%，/，|）
非规范评注
残り長さフィールドの解码算法如下：
multiplier = 1
value = 0
do
encodedByte = 'next byte from stream'
value += (encodedByte AND 127) * multiplier
multiplier *= 128
if (multiplier > 128*128*128)
throw Error(Malformed Remaining Length)
while ((encodedByte AND 128) != 0)
AND はビット操作と（C 言語における&）
このアルゴリズムが終了するとき，value 包含まれているのは残り長さの値。
2.3 可变报头
某些 MQTT 控制报文包含一个可变报头部分。それは固定ヘッダー内でとペイロード之间。可变报头の内容は...に基づいてメッセージタイプの
不同而不同。可可変ヘッダーのパケット标识符（Packet Identifier）フィールドは～に存在する複数のタイプのメッセージ内で。
2.3.1 报文标识符
图例 2.3 -报文标识符类型
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
MQTT-3.1.1-CN 18
多くの制御パケットの可变报头部分2バイトのメッセージを含む文标识符字段。これらメッセージは PUBLISH（QoS>0 时），
PUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE, SUBACK，UNSUBSCIBE，
UNSUBACK。
SUBSCRIBE，UNSUBSCRIBE と PUBLISH（QoS 大于 0）控制报文必须包含一非ゼロの 16 位报文标识
符（Packet Identifier）[MQTT-2.3.1-1]。客户端每次发送一个新これらのタイプの报文时都必须分配一个当前
未使用のパケットフラグ识符 [MQTT-2.3.1-2]。如果一个客户端要重发この特別な制御制御メッセージは、後で再送信されるそのパケット
时，它必须同じ識別子を使用する。クライアントがこれを処理し終えるとパケットに対応する確認後、この报文标识符就释放可重用。
QoS 1 の PUBLISH 対応のは PUBACK，QoS 2 の PUBLISH 対応のは PUBCOMP、と SUBSCRIBE 或
UNSUBSCRIBE 対応する分别である SUBACK 或 UNSUBACK [MQTT-2.3.1-3]。发送一个 QoS 0 の PUBLISH
报文時、同じ条件が適用される服务端 [MQTT-2.3.1-4]。
QoS に設定される 0 の PUBLISH 报文不能包含报文标识符 [MQTT-2.3.1-5]。
PUBACK, PUBREC, PUBREL 报文必须を含むと最初に送信された PUBLISH 报同じメッセージ文标识符 [MQTT-2.3.1-
6]。类似地，SUBACK と UNSUBACK 必须対応する～に含まれる SUBSCRIBE と UNSUBSCRIBE 报文中使用の
报文标识符 [MQTT-2.3.1-7]。
需要メッセージ識別子の制御メッセージは 表格 2.5 -包含报文标识符の制御パケット 中列出。
表格 2.5 -包含报文标识符号の制御制报文
控制报文
报文标识符字段
CONNECT
不需要
CONNACK
不需要
PUBLISH
需要（如果 QoS > 0）
PUBACK
需要
PUBREC
需要
PUBREL
需要
PUBCOMP
需要
SUBSCRIBE
需要
SUBACK
需要
UNSUBSCRIBE
需要
UNSUBACK
需要
PINGREQ
不需要
PINGRESP
不需要
DISCONNECT
不需要
MQTT-3.1.1-CN 19
クライアントとサーバー彼此独立地分配报文标识符。因此，客户端服务端组合同じパケットを使用する文标识符可以实现并
送信されたメッセージ交換。
非规范评注
客户端发送标识符号である 0x1234 の PUBLISH 报文，它有可それを受信したときにパケットの PUBACK 之前，先
收到服务端发送もう一つの異なるしかし、パケット識別子は識別子も 0x1234 の PUBLISH 报文。
Client Server
PUBLISH Packet Identifier=0x1234---
--PUBLISH Packet Identifier=0x1234
PUBACK Packet Identifier=0x1234---
--PUBACK Packet Identifier=0x1234
2.4 有效载荷
某些 MQTT 制御パケットはパケット内のの最後の部分は含む含一个有效载荷、これは第三章论述。に対して PUBLISH 来说有效
载荷すなわちアプリケーションメッセージである。表格 2.6 – 包含有效ペイロードの制御パケット 必要なものを列挙したペイロードの制御パケット。
表格 2.6 – 包含有效载荷の制御パケット文
控制报文
有效载荷
CONNECT
需要
CONNACK
不需要
PUBLISH
可选
PUBACK
不需要
PUBREC
不需要
PUBREL
不需要
PUBCOMP
不需要
SUBSCRIBE
需要
SUBACK
需要
UNSUBSCRIBE
需要
UNSUBACK
不需要
PINGREQ
不需要
PINGRESP
不需要
DISCONNECT
不需要
MQTT-3.1.1-CN 20
3 MQTT 控制报文
3.1 CONNECT – 连接服务端
客户端到服务端ネットワーク接続の確立立后，客户端发送给服务端最初のパケット必须である CONNECT 报文 [MQTT-
3.1.0-1]。
ネットワーク接続内で上，客户端只能发送一次 CONNECT 报文。服务端必须将客户端发送られる2番目 CONNECT
报文当作协议违规处理并断开クライアントの接続 [MQTT-3.1.0-2]。有关错误処理した情報は参照してください 4.8 节。
有效载荷包含一个或多个编码のフィールド。を含むクライアントの一意の标识符，Will 主题，Will 消息，用ユーザー名とパスワード。除
クライアント識別子之外，其它のフィールドはすべてオプションです，基于标志位来决定可变报头中かどうかこれらのフィールドを含める必要があります。
3.1.1 固定报头
图例 3.1 –CONNECT パケットの固定定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 报文类型 (1)
Reserved 保留位
0
0
0
1
0
0
0
0
byte 2…
剩余长度值
剩余长度字段
剩余长度等于可可変ヘッダーの長さ（10 字节）加上有效载荷の長さ。符号化方式见 2.2.3 节の説明。
3.1.2 可变报头
CONNECT 报メッセージの可変ヘッダー头按下列次序包含四个字段：协议名（Protocol Name），协议级别（Protocol
Level），连接标志（Connect Flags）と保持连接（Keep Alive）。
3.1.2.1 协议名
图例 3.2 -协议名字节构成
说明
7
6
5
4
3
2
1
0
协议名
byte 1
长度 MSB (0)
0
0
0
0
0
0
0
0
byte 2
长度 LSB (4)
0
0
0
0
0
1
0
0
byte 3
‘M’
0
1
0
0
1
1
0
1
byte 4
‘Q’
0
1
0
1
0
0
0
1
byte 5
‘T’
0
1
0
1
0
1
0
0
MQTT-3.1.1-CN 21
byte 6
‘T’
0
1
0
1
0
1
0
0
プロトコル名はプロトコルを表す议名 MQTT の UTF-8 エンコードされた文字列。MQTT 規範の后续版本不これを変える文字列のオフセットと
长度。
如果协议名不正确服务端可以断开客户端の接続、また可以按照某些其它规范继续处理 CONNECT パケット。に対して
于后一种情况，按照本规范，服务端不能继续处理 CONNECT 报文 [MQTT-3.1.2-1]。
非规范评注
数据包检测工具，例如防火墙，可以使用协议名来识别 MQTT 流量。
3.1.2.2 协议级别
图例 3.3 - Protocol Level byte 协议级别字节构成
说明
7
6
5
4
3
2
1
0
协议级别
byte 7
Level(4)
0
0
0
0
0
1
0
0
客户端用 8 ビットの無符号值表示プロトコルのリビジョン。に対して于 3.1.1 版协议，协议级他のフィールドの値である 4(0x04)。如果发
サポートされていないプロトコル级别，服务端必须给发送一个返回码ために 0x01（不サポートされるプロトコルレベル別）の CONNACK 报文响应
CONNECT 报文，然后断クライアントを開く连接 [MQTT-3.1.2-2]。
3.1.2.3 连接标志
连接标志字节包含一些用于指定 MQTT 连接続動作のパラメータ。它还指出有ペイロード内の文字フィールドが存在するかどうか。
图例 3.4 -连接标志位
Bit
7
6
5
4
3
2
1
0
User Name
Flag
Password
Flag
Will Retain
Will QoS
Will Flag
Clean
Session
Reserved
byte 8
X
X
X
X
X
X
X
0
服务端必须验证 CONNECT 控制报パケットの予約フラグ位（第 0 位）であるかどうか 0，如果ではない 0 必须断开客户端连接
[MQTT-3.1.2-3]。
3.1.2.4 清理会话
位置：接続フラグバイトの第 1 位
このビットは～を示すセッション状態を決定するの処理方法。
クライアントとサーバー可以保存会话状态，以支持ネットワーク接続をまたぐ可靠消息传输。このフラグビットセッション状態を制御するための
生存时间。
MQTT-3.1.1-CN 22
如果清理会话（CleanSession）フラグが設定されに設定する 0，服务端必须基于当前会话（使用客户端标识符识別）の
状態復元とクライアントクライアントとの通信。例えばもしこの～と関連するものがなければ客户端标识符関連するセッション、服务端必须创建一个新しいセッション。では
连接断开之后，当连接断开后、クライアントとサーバー务端必须保存会话信息 [MQTT-3.1.2-4]。当清理セッションフラグは 0
のセッション接続が切断之后，服务端必须将之後の QoS 1 と QoS 2 级别のメッセージは保存されセッション状態の一部分，如果この
些消息匹配断开连接时客户端の任意の購読 [MQTT-3.1.2-5]。服务端也可以保存满足相同条件の QoS 0 级别
のメッセージ。
如果清理会话（CleanSession）标志される设置ために 1，客户端と服务端必须丢弃之前の任何会话并开始一个新
の会话。会话仅持续と网络连接同样长の时间。とこの个会话关联の状态数据不能される任何之后の会话重用
[MQTT-3.1.2-6]。
クライアントのセッション状態态包括：
已经发送给服务端，しかしまだ確認を完了していない QoS 1 と QoS 2 级他のメッセージ
サーバーから受信した、しかしまだ完了確認の QoS 2 级他のメッセージ。
サーバー側のセッション状态包括：
会话存在するかどうか、セッション状態がの他の部分はすべては空である。
クライアント側の購読情息。
已经发送给客户端，しかしまだ確認を完了していない QoS 1 と QoS 2 级他のメッセージ。
即将クライアントに伝送される QoS 1 と QoS 2 级他のメッセージ。
クライアントから受信した、しかしまだ完了確認の QoS 2 级他のメッセージ。
可选，准备クライアントに送信される QoS 0 レベルのメッセージ。
保留メッセージはサーバーではない务端会话状态の一部であり、话终止时不能删除保留消息 [MQTT-3.1.2.7]。
状態ストレージに関する制限と詳細は参照第 4.1 节。
当清理会话标志に設定される 1 时，クライアントとサーバーサーバー側の状態削除は不要アトミック操作でなければならない。
非规范评注
発生時に確実にするため障害時の状態の一致性，客户端应该使用会话状态标志 1 重复请求连接，直到连接成
功。
非规范评注
一般来说，客户クライアント接続時は常に将清理会话标フラグが設定される 0 或 1，并且不交替使用两種類の値。この选择取
具体的なアプリケーションに依存する。清理会话标フラグが設定される 1 のクライアントは...ない古いものを受け取る应用消息，而且毎回の接続で成功后
都需要重新订阅任何相关のトピック。クリーンセッションフラグを設定 0 の客户端会收到所有それが接続する際断开期间发
布の QoS 1 と QoS 2 レベルのメッセージ。したがって、要确保不丢失连接断开期间のメッセージは必要使用 QoS 1 或
QoS 2 级别，同时将清理セッションフラグは設定される 0。
非规范评注
MQTT-3.1.1-CN 23
清理会话标志 0 のクライアント接続時、それはサーバーに要求する连接断开后保それを保持する MQTT 会话状态。如果打
後のある時点で計算される时间点重连到このサーバーは、客户端连接应该只使用清理会话标志 0。当客户端决定
之后このセッションをもう使用しない場合は、该将清理会话フラグを設定 0 最后再连接一次，然后断开连接。
3.1.2.5 遗嘱标志
位置：接続フラグの第 2 位。
遗嘱标志（Will Flag）設定されために 1，表示如もし接続要求が受け入れられると、遺言（Will Message）消息必须に格納され
サーバー側であり、これと个网络连接关联。之后网络连接关闭时，服务端必须これを公開する遗嘱消息，除非服务端收到
DISCONNECT メッセージの際に削除されこの遗嘱消息 [MQTT-3.1.2-8] 。
遺言メッセージの公開条件，包括但不限于：
サーバーが検出した一个 I/O 错误或者网络故障。
クライアントが接続を維持している接（Keep Alive）の時間内にできなかった通讯。
客户端没有先发送 DISCONNECT メッセージはネットワーク接続を直接クローズしました。
由于协议错误服サーバーがネットワークを閉じた络连接。
如果遺言フラグが設定されます 1，连接続フラグ中の Will QoS と Will Retain 字段サーバーによって使用され到，同时有效载荷中必
须包含 Will Topic と Will Message 字段 [MQTT-3.1.2-9]。
一度公開されると、またはサーバーが受信したクライアントが送信した DISCONNECT 报文，遗嘱消息就必须保存されたセッション状態から削除
除 [MQTT-3.1.2-10]。
如果遺言フラグが設定されます 0，连接フラグの中の Will QoS と Will Retain 字段必须に設定される 0，并且有效载荷中不能
包含 Will Topic と Will Message 字段 [MQTT-3.1.2-11]。
如果遺言フラグが設定されます 0，网络连接断开时，不能发送遗嘱消息 [MQTT-3.1.2-12]。
服务端应该迅速发布遗嘱消息。に关机或故障の情况下，服务端可以推迟遗嘱消息の发布直到之后の重启。
このようなことが発生した場合状況では、サーバーではサーバー障害と遺言メッセージが公開され间可能会有一个延迟。
3.1.2.6 遗嘱 QoS
位置：接続フラグの第 4 と第 3 位。
この2ビットは指定に使用される发布遗嘱メッセージ時に使用されるサービス质量等级。
如果遺言フラグが設定されます 0，遗嘱 QoS 也必须に設定される 0(0x00) [MQTT-3.1.2-13]。
如果遺言フラグが設定されます 1，遗嘱 QoS の値可以等于 0(0x00)，1(0x01)，2(0x02)。它の値不能等于 3
[MQTT-3.1.2-14]。
3.1.2.7 遗嘱保留
位置：接続フラグの第 5 位。
MQTT-3.1.1-CN 24
如果遺言メッセージが公開される際に保持する必要が留，需要指定このビットの値。
如果遺言フラグが設定されます 0，遗嘱保留（Will Retain）标志也必须に設定される 0 [MQTT-3.1.2-15]。
如果遺言フラグが設定されます 1：
如果遺言保持が設定されます 0，服务端必须将遗嘱消息当作非保留消息发布 [MQTT-3.1.2-16]。
如果遺言保持が設定されます 1，服务端必须将遗嘱消息当作保留消息发布 [MQTT-3.1.2-17]。
3.1.2.8 用户名标志
位置：接続フラグの第 7 位。
如果用户名（User Name）フラグは設定される 0，有效载荷中不能包含用户名字段 [MQTT-3.1.2-18]。
如果用户名（User Name）フラグは設定される 1，有效载荷中必须包含用户名字段 [MQTT-3.1.2-19]。
3.1.2.9 密码标志
位置：接続フラグの第 6 位。
如果密码（Password）标志に設定される 0，有效载荷中不能包含密码字段 [MQTT-3.1.2-20]。
如果密码（Password）标志に設定される 1，有效载荷中必须包含密码字段 [MQTT-3.1.2-21]。
如果用户名标志に設定される 0，密码标志也必须に設定される 0 [MQTT-3.1.2-22]。
3.1.2.10 保持连接
图例 3.5 保持连接字节
Bit
7
6
5
4
3
2
1
0
byte 9
保持连接 Keep Alive MSB
byte 10
保持连接 Keep Alive LSB
保持连接（Keep Alive）は一秒単位の時間間隔は、次のように表される一个 16 ビットのワード、それは指します客户端传输完成
ある制御メッセージの時刻から次のメッセージを送信する時刻まで，两者之间允许空闲の最大时间间隔。客户端负责保证控制
报文发送の时间间隔不超过キープアライブの値。如果没有任何其它の制御制报文可以发送，客户端必须发送一个
PINGREQ 报文 [MQTT-3.1.2-23]。
不管キープアライブの値はいくらですか、客户端任何时候都可以发送 PINGREQ 报文，并且使用 PINGRESP 报文判断网
ネットワークとサーバー側のアクティビ动状态。
如果保持连接の値非零，并且服务端に一点五倍の保持连接时间内没有收到客户端の控制报文，它必须断
クライアントのネットワークを切断する接続では、ネットワークと見なす络连接已断开 [MQTT-3.1.2-24]。
クライアントが送信した PINGREQ 报文その後、合理的な時間内に仍没有收到 PINGRESP 报文，它应该关闭到服务
クライアント側のネットワーク接続。
MQTT-3.1.1-CN 25
キープアライブの値は零表示关闭保持连接功能。これは意味する，服务端不需要なぜなら客户端不活跃而断开连接。注意：
接続を維持する値が何であっても、いつでも，只要服务端认ためにクライアントが非アクティブまたは無応答の場合、切断できます。客户端の连
接。
非规范评注
キープアライブの実際値はアプリケーションによって指定され定められ、一般的には几分钟。允许の最大値は 18 小时 12 分 15 秒。
3.1.2.11 可变报头非规范示例
图例 3.6 -可变报头非规范示例
描述
7
6
5
4
3
2
1
0
协议名
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (4)
0
0
0
0
0
1
0
0
byte 3
‘M’
0
1
0
0
1
1
0
1
byte 4
‘Q’
0
1
0
1
0
0
0
1
byte 5
‘T’
0
1
0
1
0
1
0
0
byte 6
‘T’
0
1
0
1
0
1
0
0
协议级别
描述
7
6
5
4
3
2
1
0
byte 7
Level (4) 级别
0
0
0
0
0
1
0
0
连接标志 Connect Flags
byte 8
User Name Flag (1) 用户名标志
Password Flag (1) 密码标志
Will Retain (0) Will 保留标志
Will QoS (01) Will 服务质量
Will Flag (1) Will 标志
Clean Session (1) 清理会话
Reserved (0) 保留位
1
1
0
0
1
1
1
0
保持连接时间
byte 9
保持连接 MSB (0)
0
0
0
0
0
0
0
0
byte 10
保持连接 LSB (10)
0
0
0
0
1
0
1
0
MQTT-3.1.1-CN 26
3.1.3 有效载荷
CONNECT 报メッセージの有効ペイロード荷（payload）包含一个或多个以长度をプレフィックスとするフィールド、可変ヘッダー内のフラグ决定かどうか
これらのフィールドを含む。含まれている場合，必须この順序で現れる：客户端标识符，遗嘱主题，遗嘱消息，用户名，密
码 [MQTT-3.1.3-1]。
3.1.3.1 客户端标识符
服务端使用客户端标识符 (ClientId) 识别客户端。连接服务端の每个客户端都有唯一の客户端标识符
（ClientId）。クライアントとサーバー端都必须使用 ClientId 识别两者之間の MQTT セッションに関連する状態态 [MQTT-3.1.3-
2]。
客户端标识符 (ClientId) 必须存在而且必须である CONNECT 报文ペイロードの第一个字段 [MQTT-3.1.3-3]。
客户端标识符必须である 1.5.3 バイトで定義された UTF-8 编码字符串 [MQTT-3.1.3-4]。
服务端必须允许 1 到 23 バイト長の UTF-8 エンコードされたクライアント端标识符，客户端标识符只能包含これらの文字:
“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”（大写字母，小写字母
と数字）[MQTT-3.1.3-5]。
服务端可以允许编码后超过 23 个字節のクライアント标识符 (ClientId)。服务端可以允许包上記に列挙されていないものを含む表字符
のクライアント識別子 (ClientId)。
服务端可以允许客户端提供一个零字バイトのクライアント識別子 (ClientId) ，如果こうして、服务端必须これを特別と見なす
殊情况并分配唯一意のクライアント識別子識別子をそのクライアントに户端。然后它必须假设クライアントが提供したその一意のクライアント标识
符，正常处理この CONNECT 报文 [MQTT-3.1.3-6]。
如果客户端提供ゼロバイトのクライアント識別子符，它必须同时将清理会话标志设に設定する 1 [MQTT-3.1.3-7]。
如果客户端提供の ClientId ゼロバイトである且清理会话标志は 0，服务端必须リターンコードを送信する 0x02（表示标识符不
合格）の CONNACK 报文响应客户端の CONNECT 报文，然后关闭网络连接 [MQTT-3.1.3-8]。
如果服务端拒绝したこの ClientId，它必须发送リターンコードは 0x02（表示标识符不合格）の CONNACK 报文响应
クライアントの CONNECT 报文，然后关闭网络连接 [MQTT-3.1.3-9]。
非规范评注
客户端实现可以提供一个方便乱数を生成するための方法の ClientId。当清理会话フラグが設定され 0 时应该
この使用を積極的に放棄する种方法。
3.1.3.2 遗嘱主题
如果遺言フラグが設定されます 1，有ペイロードの次のこのフィールドは遺言（Will）である主题（Will Topic）。遗嘱主题必须である 1.5.3 节定
意味の UTF-8 编码字符串 [MQTT-3.1.3-10]。
MQTT-3.1.1-CN 27
3.1.3.3 遗嘱消息
如果遺言フラグが設定されます 1，有ペイロードの次のこのフィールドは遺言（Will）である消息。遗嘱消メッセージは、これから～されることを定義している发布到遗嘱主問題の応
用消息，见 3.1.2.5 バイトの記述。このフィールドは、2バイトの長さと遺言メッセージの有効ペイロードから構成され、次のように表される零字节或
多个字节序列。長さは、後に続くデータのバイト数、いいえ、包含长度フィールド自体が占める2个字节。
遗嘱メッセージが遺言トピックに公開されるときその有効ペイロードはこのヘッダーのフィールドのデータ部分，不包含开2つの長さ字节。
3.1.3.4 用户名
如果用户名（User Name）フラグは設定される 1、ペイロードの次のフィールドがそれである。用户名必须である 1.5.3 节定義された
UTF-8 编码字符串 [MQTT-3.1.3-11]。服务端可以将它用于身份検証と認可。
3.1.3.5 密码
如果密码（Password）标志に設定される 1、ペイロードの次のフィールドは它。密码字段包含一个两字バイトの長さ
字段，长度バイナリデータのバイト数を表す（不包含长度字段本自身が占める2つの字节），后面続いて 0 到 65535 字节
のバイナリデータ。
图例 3.7 - 密码字节
Bit
7
6
4
3
2
1
0
byte 1
数据长度 MSB
byte 2
数据长度 LSB
byte 3 ….
如果长度大于 0、ここがデータ部分です
3.1.4 响应
注意：服务器可同じ一つの TCP 端口或其他网络端点上支持多种协议（包括本プロトコルの初期バージョン本）。如果服
サーバーが決定するプロトコルは MQTT 3.1.1、ならばそれは、次の方法验证连接请求。
1. 网络连接建立后，如果服务端合理的な時間内に内没有收到 CONNECT 报文，服务端应该关闭この接続
接。
2. 服务端必须按照 3.1 節の要件に従って検証する CONNECT 报文，如果报文不符合规范，服务端不发送
CONNACK 报文直接关闭网络连接 [MQTT-3.1.4-1]。
3. 服务端可以检查 CONNECT メッセージの内容が満たしているか足任何进一步の制限、可以执行身認証と認可
检查。如果任何一项检查没通过，按照 3.2 節の説明では、それは应该发送一个适適切な、戻りコードが非ゼロの
CONNACK 响应，并且必须このネットワーク接続を閉じます。
如果验证成功，服务端会执行下列步骤。
1. 如果 ClientId 表明クライアントはこのサービスに接続していますサーバー側、その場合はサーバー側必须既存のクライアントを切断する户端连接 [MQTT-
3.1.4-2]。
2. 服务端必须按照 3.1.2.4 节の描述执行セッションをクリーンアップするプロセス [MQTT-3.1.4-3]。
3. 服务端必须リターンコードを送信するゼロの CONNACK パケットとして CONNECT メッセージの确认响应 [MQTT-3.1.4-4]。
4. メッセージ配信を開始し、保持连接状态监视。
MQTT-3.1.1-CN 28
允许クライアントが送信している CONNECT 报文之后立即发送その他の制御パケット；客户端不サーバー側を待つ必要がある CONNACK
报文。如果サーバーが拒否した CONNECT，它不能处理客户端に CONNECT 报文之后发送信された任意のデータ [MQTT-
3.1.4-5]。
非规范评注
客户端通常会等待一个 CONNACK 报文。然而クライアントには権利がある收到 CONNACK 之前发送控制报文，
由于不需要维持接続状態、これはクライアントの実装を簡素化できる现。
3.2 CONNACK – 确认连接请求
服务端发送 CONNACK 报文クライアントからの応答受信した CONNECT 报文。服务端发送给客户端最初のパケット必
须である CONNACK [MQTT-3.2.0-1]。
クライアントが適合している場合合理的な時間内にない有收到服务端の CONNACK 报文，客户端应该关闭网络连接。
合理
の時間を取り
アプリケーションの種類に依存するおよび通信インフラストラクチャ施。
3.2.1 固定报头
固定ヘッダーの形式见 图例 3.8 – CONNACK 报文固定报头 の説明。
图例 3.8 – CONNACK 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (2)
Reserved 保留位
0
0
1
0
0
0
0
0
byte 2
剩余长度 (2)
0
0
0
0
0
0
1
0
剩余长度字段
表示可変ヘッダーの長さ。に対して CONNACK 报文この値は等しい 2。
3.2.2 可变报头
可変ヘッダーの形式见 图例 3.9 –CONNACK 报文可变报头 の描述。
图例 3.9 –CONNACK 报文可变报头
描述
7
6
5
4
3
2
1
0
连接确认标志
Reserved 保留位
SP
1
byte 1
0
0
0
0
0
0
0
X
连接返回码
byte 2
X
X
X
X
X
X
X
X
MQTT-3.1.1-CN 29
3.2.2.1 连接确认标志
第 1 バイトは
连接确认标志
，位 7-1 保である留位且必须に設定される 0。
第 0 (SP)位 は現在会话（Session Present）标志。
3.2.2.2 当前会话
位置：接続確認フラグの第 0 位。
如果服务端收到清理会话（CleanSession）标志ために 1 の连接，除た将 CONNACK パケット内のリターンコードに設定される 0
之外，还必须将 CONNACK パケット内の当前会话设置（Session Present）标志ために 0 [MQTT-3.2.2-1]。
如果服务端收到一个 CleanSession ために 0 の连接，当前会话标志の値はサーバーが...であるかどうかによって異なるかどうか、すでに保存されている ClientId
対応するクライアントのセッション话状态。如果服务端已经保セッション状態を保存した，它必须将 CONNACK パケット内の現在のセッション话标志设
に設定する 1 [MQTT-3.2.2-2]。如果服务端保存されたものがない会话状态，它必须将 CONNACK 报文中の当前会话设置
ために 0。还需要将 CONNACK 报メッセージ内のリターンコードは...に設定される 0 [MQTT-3.2.2-3]。
当前会话标志使サーバーとクライアントが既に存在するかどうか保存されたセッション状態を保持する持一致。
一旦セッションの初期化設定が完了しました，已经保存会セッション状態のクライアントは期待する望服务端维持它存储のセッション状態。如果客
クライアントがサーバーから受信する着いた当前の値が予期されたものと異なる，客户端可以この端末間の会话或者断开连接。客户端可以丢
クライアントとサーバーを破棄するセッションを継続することを選択する状态，方法である、断开连接，将清理会话标フラグが設定される 1，再次连接，然后再次
断开连接。
如果服务端发送非可変ゼロの戻りコードの CONNACK 报文，它必须将当前会话标志に設定される 0 [MQTT-
3.2.2-4]。
3.2.2.3 连接返回码
位置：ヘッダーの第 2 个字节。
连接返回码字段使用一个字节の符号なし値、に 表格 3.1 –连接返リターンコードの値 中列出。如果服务端收到一个合
法的 CONNECT 报文，但出于某些原因无法处理它，服务端应该尝试发送一个包含非零返回码（表格中の
そのうちの1つ）の CONNACK 报文。如果サーバーが送信した一个包含非零返回码の CONNACK 报文，それなら必须关
闭网络连接 [MQTT-3.2.2-5].。
表格 3.1 –接続リターンコードの値
值
返回码响应
描述
0
0x00 连接已接受
接続はサーバーにより既に接受
1
0x01 连接已拒絶対に、サポートされていない协议版本
服务端不支持客クライアント要求の MQTT 协议级别
2
0x02 连接已拒绝，不有効なクライアント識別子
クライアント識別子は正しい UTF-8 编码，但服务
端不允许使用
3
0x03 连接已拒绝，服务端不可用
网络连接已建立，但 MQTT 服务不可用
4
0x04 连接已拒绝，无效のユーザー名またはパスワード
ユーザー名またはパスワードの数据格式无效
MQTT-3.1.1-CN 30
5
0x05 连接已拒绝，未授权
クライアントは認可されていない连接到此服务器
6-255
保留
上表に示されていると考える場合のすべての接続が返す回码都不太合适，では服务端必须关闭网络连接，不需要发送 CONNACK 报
文 [MQTT-3.2.2-6]。
3.2.3 有效载荷
CONNACK 报文没有有效载荷。
3.3 PUBLISH – 发布消息
PUBLISH 控制パケットはクライアントから户端向服务端或者服务端向客户端传输一个应用消息。
3.3.1 固定报头
图例 3.10 – PUBLISH 报文固定报头固定ヘッダーについて説明ヘッダーの形式
图例 3.10 – PUBLISH 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (3)
DUP
QoS 等级
RETAIN
0
0
1
1
X
X
X
X
byte 2
剩余长度
3.3.1.1 重发标志
位置：第 1 个字节，第 3 位
如果 DUP フラグが設定され 0、これはクライアントまたはサーバーであることを示す务端第一次请これを送信する要求 PUBLISH 报文。如果 DUP 标志
に設定される 1，表これはおそらく一つの个早前报文请再送の要求。
客户端或服务端请求重发一个 PUBLISH 报文时，必须将 DUP 标フラグが設定される 1 [MQTT-3.3.1.-1].。に対して QoS
0 のメッセージ、DUP 标志必须に設定される 0 [MQTT-3.3.1-2]。
服务端发送 PUBLISH 报文给订阅者时，收到（インバウンド）の PUBLISH メッセージの DUP フラグの値伝播されません。发
送信（アウトバウンド）の PUBLISH 报文と受信（インバウンド）の PUBLISH パケット内の DUP フラグは独立独立して設定された、その値必须
送信のみに基づいて（アウトバウンド）の PUBLISH 报文再送信であるかどうか发来确定 [MQTT-3.3.1-3]。
非规范评注
接收者收到一个 DUP マークされる 1 の控制报文时，不能假设它看到このメッセージの前にのコピー。
非规范评注
特に指摘する必要があるである、DUP 标注目しているのは制御制报文本身，それに含まれるアプリケーションメッセージと无关。当使用 QoS 1
时，客户端可能会收到一个 DUP マークされる 0 の PUBLISH 报文，この报文包含一それが以前に受信したもの
アプリケーションメッセージのコピー、ただし使用しているのは異なるパケット識別子识符。 2.3.1 節は...に関するパケット識別子に関する更多信息。
MQTT-3.1.1-CN 31
3.3.1.2 服务质量等级
位置：第 1 个字节，第 2-1 位。
このフィールドは～すべきことを示しているメッセージ配信に使用される服务质量等级保证。服务质QoSレベルでは 表格 3.2 -服务质量定义 中列出。
表格 3.2 -服务质量定义
QoS 值
Bit 2
Bit 1
描述
0
0
0
最多分发一次
1
0
1
至少分发一次
2
1
0
只分发一次
-
1
1
保留位
PUBLISH 报文不能将 QoS 所一部のビットが...に設定される 1。如果服务端或客户端收到 QoS すべてのビットが 1 の PUBLISH
报文，它必须关闭网络连接 [MQTT-3.3.1-4]。
3.3.1.3 保留标志
位置：第 1 个字节，第 0 位。
如果客户端发给サーバー側の PUBLISH メッセージの保留（RETAIN）フラグが設定されるために 1，服务端必须このアプリケーションメッセージを保存する
息と它の服务质量等级（QoS），以便它可以される分发给未来の主题名匹配の订阅者 [MQTT-3.3.1-5]。一个
新しい订阅建立时、に対して每个匹配の主题名，如果存に最近保残りの消息，它必须送られる送给この订阅者 [MQTT-
3.3.1-6]。如果服务端收到一条保留（RETAIN）フラグは 1 の QoS 0 消息，它必须丢弃以前にそのトピックに対して题保留
任意のメッセージの。それは应该これを新しい QoS 0 メッセージをそのトピックとして扱うトピックの新しいリテインドメッセージだがはいつでも可以选择丢弃它
— 如果この状況が発生した場合、その主题将没有保留消息 [MQTT-3.3.1-7]。有关存储状态の詳細については 4.1 节。
服务端发送 PUBLISH 报文给客户端时，如メッセージがクライアントとして送信される場合一个新購読の結果を送信送，它必须メッセージの保留を
保留フラグを設定 1 [MQTT-3.3.1-8]。当一个 PUBLISH 报文发クライアントに送信されるのは、一致するため配一个已建立の購読時に、サーバー
务端必须RETAINフラグを設定する 0，不管它受信したこのメッセージ息中保留フラグの値は何か [MQTT-3.3.1-9]。
保留マークされる 1 且有效ペイロードがゼロバイトの PUBLISH 报メッセージは服务端当作正常消息処理され、それは发送给订阅主题
一致する客户端。此外，同一个主题下任何现存の保留消息必须される移除，因此この个主题之后の任何订阅者都
不会收到一个保留消息 [MQTT-3.3.1-10]。
当作正常
意味は既存の客户端收到のメッセージ中保留标志未設定される。
服务端不能ゼロバイトを格納する保留消息 [MQTT-3.3.1-11]。
如果客户端发给サーバー側の PUBLISH メッセージの保留标志位 0，服务端不能このメッセージを格納する也不能移除或替换任何
既存の保持メッセージ [MQTT-3.3.1-12]。
非规范评注
パブリッシャーにとっては不定期发送状态消メッセージというシナリオでは、保留消息很有使用。新しい購読購読者は最新の状態を受け取る态。
剩余长度字段
等于可変ヘッダーの長さに有効ペイロードの長さ。
MQTT-3.1.1-CN 32
3.3.2 可变报头
可变报头按顺序包含主题名前とパケット識別子。
3.3.2.1 主题名
主题名（Topic Name）用于识别有效载荷データはどこに公開されるべきか一个信息通道。
主题名必须である PUBLISH 报文可变报ヘッダの最初のフィールド。它必须である 1.5.3 节定義された UTF-8 エンコードされた文字列
[MQTT-3.3.2-1]。
PUBLISH 报文中のトピック名不能包含通配符 [MQTT-3.3.2-2]。
服务端发送给订購読クライアントの PUBLISH 报文のトピック名必须匹配その購読のトピック过滤器（根据 4.7 節で定義されたマッチング
过程）[MQTT-3.3.2-3]。
3.3.2.2 报文标识符
只有当 QoS 等レベルは 1 或 2 时，报文标识符（Packet Identifier）字段のみ現れる PUBLISH 报文中。2.3.1
節は関連するメッセージについての情報を提供するパケット識別子の変更多信息。
3.3.2.3 可变报头非规范示例
图例 3.11 – PUBLISH 报文可变报头非规范示例 例で説明した 表格 3.3 - PUBLISH 报文非规范示例 中简要描
述べた PUBLISH パケットの可変ヘッダー头。
表格 3.3 - PUBLISH 报文非规范示例
Field
Value
主题名
a/b
报文标识符
10
图例 3.11 – PUBLISH 报文可变报头非规范示例
描述
7
6
5
4
3
2
1
0
Topic Name 主题名
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (3)
0
0
0
0
0
0
1
1
byte 3
‘a’ (0x61)
0
1
1
0
0
0
0
1
byte 4
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 5
‘b’ (0x62)
0
1
1
0
0
0
1
0
报文标识符
byte 6
报文标识符 MSB (0)
0
0
0
0
0
0
0
0
byte 7
报文标识符 LSB (10)
0
0
0
0
1
0
1
0
MQTT-3.1.1-CN 33
例の中のトピック名ために “a/b”，长度等于 3、パケット識別子は “10”
3.3.3 有效载荷
有效载荷包含将公開されたアプリケーションメッセージ。データの内容と形式はアプリケーション固有の。ペイロードの長さ長さは次のように計算されます：用固定
ヘッダー内の残りの長さ長さフィールドの値を減算可変ヘッダーの長さを除く。包含零长度有效载荷の PUBLISH 报パケットは有効です。
3.3.4 响应
PUBLISH 报文の受信者必须按照根据 PUBLISH パケット内の QoS 等级发送响应，见下面表形式の記述 [MQTT-
3.3.4-1]。
表格 3.4 – PUBLISH メッセージの予想响应
服务质量等级
预期响应
QoS 0
无响应
QoS 1
PUBACK 报文
QoS 2
PUBREC 报文
3.3.5 动作
客户端使用 PUBLISH 报文发送应用消息给服务端、目的は配信することです到其它订阅匹配信されるクライアント。
服务端使用 PUBLISH 报文发送应用消息给每一个订阅匹配のクライアント。
客户端使用带通ワイルドカードのトピックフィルタ滤器请求订阅时，客クライアントのサブスクリプションは能会重复，因此公開されたメッセージは複数の
フィルター。に対してこの場合、サーバー务端必须将消息分发给所有订阅匹配の QoS 等最も高いレベルのクライアント [MQTT-3.3.5-
1]。服务端之后可以按照订阅の QoS 等级、メッセージを配信する副本给每一个一致するサブスクライバー。
收到一个 PUBLISH 报文时，受信者の動作取决于 4.3 节記述された QoS 等级。
如果服务端实现不授权某个客户端发布 PUBLISH 报文，それはそれを通知する方法がない。客户端。它必须按照正通常の
QoS 规则发肯定応答を送る确认，或者关闭网络连接 [MQTT-3.3.5-2]。
3.4 PUBACK –发布确认
PUBACK 报文正しい QoS 1 等级の PUBLISH 报パケットの応答。
3.4.1 固定报头
图例 3.12 - PUBACK 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (4)
保留位
0
1
0
0
0
0
0
0
MQTT-3.1.1-CN 34
byte 2
剩余长度(2)
0
0
0
0
0
0
1
0
剩余长度字段
可変ヘッダーを示す長さ。に対して PUBACK 报文この値は等しい 2.
3.4.2 可变报头
確認待ちのパケットを含む PUBLISH パケットのヘッダ文标识符。
图例 3.13 – PUBACK 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
3.4.3 有效载荷
PUBACK 报文没有有效载荷。
3.4.4 动作
完全な説明は参照 4.3.2 节。
3.5 PUBREC – 发布收到（QoS 2，第一步）
PUBREC 报メッセージは正しい QoS 等级 2 の PUBLISH 报メッセージの応答。それは QoS 2 等级协议交交換の2番目のパケット文。
3.5.1 固定报头
图例 3.14 – PUBREC 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 e (5)
保留位
0
1
0
1
0
0
0
0
byte 2
剩余长度 (2)
0
0
0
0
0
0
1
0
剩余长度字段
可変ヘッダーを示す長さ。に対して PUBREC 报メッセージの值等于 2。
3.5.2 可变报头
可变报头包含等確認待ちの PUBLISH 报のパケット識別子识符。
MQTT-3.1.1-CN 35
图例 3.15 – PUBREC 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
3.5.3 有效载荷
PUBREC 报文没有有效载荷。
3.5.4 动作
完全な説明は参照 4.3.3 节。
3.6 PUBREL – 发布释放（QoS 2，第二步）
PUBREL 报文正しい PUBREC パケットへの応答。それは QoS 2 等レベルのプロトコル交換の第三个报文。
3.6.1 固定报头
图例 3.16 – PUBREL 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (6)
保留位
0
1
1
0
0
0
1
0
byte 2
剩余长度 (2)
0
0
0
0
0
0
1
0
PUBREL 控制报文固定报ヘッダーの 3,2,1,0 ビットは予約ビット，必须に設定される 0,0,1,0。服务端必须それ以外の任意の値を
すべて無効とみなすし、ネットワークを閉じる连接 [MQTT-3.6.1-1]。
剩余长度字段
可変ヘッダーを示す長さ。に対して PUBREL 报この値は等しい于 2.
3.6.2 可变报头
可変ヘッダーには、確認待ちの PUBREC 报文同じパケット識別子识符。
图例 3.17 – PUBREL 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
MQTT-3.1.1-CN 36
3.6.3 有效载荷
PUBREL 报文没有有效载荷。
3.6.4 动作
完全な説明は参照 4.3.3 节。
3.7 PUBCOMP – 发布完成（QoS 2，第三步）
PUBCOMP 报メッセージは正しい PUBREL 报パケットの応答。それは QoS 2 等级プロトコル交換の第4つ目で最後一个报文。
3.7.1 固定报头
图例 3.18 – PUBCOMP 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (7)
保留位
0
1
1
1
0
0
0
0
byte 2
剩余长度 (2)
0
0
0
0
0
0
1
0
剩余长度字段
可変ヘッダーを示す長さ。に対して PUBCOMP 报この文个值等于 2。
3.7.2 可变报头
可変ヘッダーには、確認待ちの PUBREL 报文同じパケット标识符。
图例 3.19 – PUBCOMP 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
3.7.3 有效载荷
PUBCOMP 报文没有有效载荷。
3.7.4 动作
完全な説明は参照 4.3.3 节。
MQTT-3.1.1-CN 37
3.8 SUBSCRIBE - 订阅主题
客户端向服务端发送 SUBSCRIBE 报文用于创建一个或多个订阅。每个订阅注册客户クライアントが関心を持つ一つの或多个
トピック。応答するためには用消息转发给それらのサブスクリプションと一致する一致したトピック、サーバー务端发送 PUBLISH 报文给客户端。SUBSCRIBE
メッセージも（各サブスクリプション）は指定している最大の QoS 等级，服务端これに基づいて送信する应用消息给客户端。
3.8.1 固定报头
图例 3.20 – SUBSCRIBE 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (8)
保留位
1
0
0
0
0
0
1
0
byte 2
剩余长度
SUBSCRIBE 控制报固定报头の第 3,2,1,0 位予約されている位，必须それぞれ設定される 0,0,1,0。服务端必须その他の任意の
どの値も...とはみなされない有効であり、閉じる网络连接 [MQTT-3.8.1-1]。
剩余长度字段
等于可変ヘッダの長さ（2 字节）加上有效载ペイロードの長さ。
3.8.2 可变报头
可变报头包含客户端标识符。2.3.1 提供パケットに関する識別子の詳細情報。
3.8.2.1 可变报头非规范示例
图例 3.21 – 报文标识符等于 10 の可変ヘッダー、非規範的な例例 パケットを示しパケット識別子は...に設定 10 時の可変ヘッダー
头。
图例 3.21 – 报文标识符等于 10 の可变报头，非规范示例
描述
7
6
5
4
3
2
1
0
报文标识符
byte 1
报文标识符 MSB (0)
0
0
0
0
0
0
0
0
byte 2
报文标识符 LSB (10)
0
0
0
0
1
0
1
0
3.8.3 有效载荷
SUBSCRIBE メッセージの有效载荷一つのトピックを含む题过滤器列表，それらはクライアントを表すクライアントが購読したいトピック。SUBSCRIBE
报文ペイロード内のトピックフィルター列表必须である 1.5.3 节定義された UTF-8 字符串 [MQTT-3.8.3-1]。服务端应该支持
包含通配符（4.7.1 节定意味）のトピック题过滤器。如果服务端选择不支持ワイルドカードを含む主题过滤器，必须拒绝
任何包含通配符フィルターのサブスクリプション请求 [MQTT-3.8.3-2]。每一个过滤器后面1バイトが続く、このバイトは叫做 服
务质量要求（Requested QoS）。それはサーバーにとえる务端向客户端发送应用消メッセージに許容される最大 QoS 等级。
MQTT-3.1.1-CN 38
SUBSCRIBE メッセージの有效载荷必须包含至少一対主题过滤器 と QoS 等级字段组合。没有有效载荷の
SUBSCRIBE 报パケットはプロトコル違反ですの [MQTT-3.8.3-3]。有关错误处処理の情報は...を参照してください 4.8 节。
要求された最大のサービス质量等级字段1バイトにエンコードされる节，它后面続いて UTF-8 编エンコードされたトピック名、それらのトピックフィルター /と
QoS 等级组合連続のにパックされている。
图例 3.22 – SUBSCRIBE 报文有效载荷格式
描述
7
6
5
4
3
2
1
0
主题过滤器
byte 1
长度 MSB
byte 2
长度 LSB
bytes 3..N
主题过滤器（Topic Filter）
服务质量要求（Requested QoS）
保留位
服务质量等级
byte N+1
0
0
0
0
0
0
X
X
現在のバージョンのプロトコル没有用到服务质量要求（Requested QoS）バイトの上位6ビット。如果有效ペイロード内の任意のビットは非
零值，或者 QoS 不等于 0,1 或 2，服务端必须考える SUBSCRIBE メッセージは不正な、および关闭网络连接 [MQTT-
3-8.3-4]。
3.8.3.1 有效载荷非规范示例
图例 3.23 – 有效载荷字节格式非规范示例 展示た 表格 3.5 – 有效载荷非规范示例 中で簡単に説明されている
SUBSCRIBE 报パケットのペイロード。
表格 3.5 – 有效载荷非规范示例
主题名
“a/b”
服务质量要求
0x01
主题名
“c/d”
服务质量要求
0x02
图例 3.23 – 有效载荷字节格式非规范示例
描述
7
6
5
4
3
2
1
0
主题过滤器（Topic Filter）
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (3)
0
0
0
0
0
0
1
1
byte 3
‘a’ (0x61)
0
1
1
0
0
0
0
1
MQTT-3.1.1-CN 39
byte 4
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 5
‘b’ (0x62)
0
1
1
0
0
0
1
0
服务质量要求（Requested QoS）
byte 6
Requested QoS(1)
0
0
0
0
0
0
0
1
主题过滤器（Topic Filter）
byte 7
Length MSB (0)
0
0
0
0
0
0
0
0
byte 8
Length LSB (3)
0
0
0
0
0
0
1
1
byte 9
‘c’ (0x63)
0
1
1
0
0
0
1
1
byte 10
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 11
‘d’ (0x64)
0
1
1
0
0
1
0
0
服务质量要求（Requested QoS）
byte 12
Requested QoS(2)
0
0
0
0
0
0
1
0
3.8.4 响应
服务端收到客户クライアントが送信する一つの SUBSCRIBE 报文时，必须使用 SUBACK 报文响应 [MQTT-3.8.4-1]。
SUBACK 报文必须と確認応答を待つ SUBSCRIBE 报文同じパケット識別子を持つ符 [MQTT-3.8.4-2]。
サーバーは送信することができる送 SUBACK 报文之前送信と購読を開始する一致する PUBLISH 报文。
如果服务端收到一个 SUBSCRIBE 报文，报文のトピックフィルタと既存のサブスクリプションの主题过滤器相同，では必须
新しい購読を完全に使用して完全に既存の購読。新しい購読のトピック。フィルターと以前のサブスクリプションと同じ、しかしそれはの最大 QoS 值可以不
同。このトピックフィルターに一致する任意の既存の保持された留消息必须再送され、ただし、パブリッシュフローは不能中断 [MQTT-3.8.4-3]。
如果主题过滤器不同于任何现購読フィルターを保存し、サーバー务端会创建一新しい購読を作成し、すべてを送信一致する保持されたものがある消息。
如果服务端收到包含多个主题フィルターの SUBSCRIBE 报文，它必须一連の...を受信したかのようにの複数 SUBSCRIBE
メッセージを同じように処理する个，除いてそれらの応答を...する必要がある合并到一个单独立した SUBACK 报文发送 [MQTT-3.8.4-4]。
服务端发送给客クライアントの SUBACK 报文に対して各トピックフィルターのペア と QoS 等级都必须包含一个返回码。この返回
码必须その購読が許可されたことを示す与えられた最大 QoS 等级，或者この購読が失敗したことを示す [MQTT-3.8.4-5]。服务端可以授予比
購読者が要求した低いいくつかの QoS 等级。購読に応答して送信される送信されたメッセージのペイロードの QoS 必须元のパブリッシュメッセージの
QoS とサービス側が付とした QoS 両者のうち最小值。如果原始消息の QoS である 1 そして付とされた最大 QoS である 0，允许服
务端重复发送一1つのメッセージのコピー给订阅者 [MQTT-3.8.4-6]。
非规范示例
特定のトピックに対して题过滤器，如果サブスクライブ中のクライアントが付とされるの最大 QoS 等レベルは 1、ならばこのフィルターに一致する
フィルターの QoS 等级 0 のアプリケーションメッセージは...に従って QoS 等级 0 このクライアントに配信する。これはクライアントがクライアントは最大でこれを受け取る
MQTT-3.1.1-CN 40
メッセージの1つのコピー。他方では说，发布给同トピックの QoS 等级 2 のメッセージサーバーによって...に降格される QoS 等
级 1 再分发给客户端，因此客户端可能会收重複メッセージに副本。
購読している場合のクライアントが付とされるの最大 QoS レベルは 0、ならば原来按 QoS 等级 2 发布给クライアント側のアプリケーション
メッセージはビジー時には能会丢失，しかし服务端不应重複メッセージを送信すべき消息副本。发布给同トピックの QoS 等级
1 のメッセージが伝送中输给客户端时可能会丢失或重复。
非规范评注
使用 QoS 等级 2 订阅一个主题过滤器等于つまり：
私はそれらの公開に従って時の
QoS
これに一致するレベルを受け入れる个
フィルターのメッセージ
。つまり、确定メッセージ配信時に起こり得る最大 QoS 等レベルはパブリッシャーの責任であり、订阅者可以
要求服务端降低 QoS 到更适そのレベルに適合する。
3.9 SUBACK – 订阅确认
服务端发送 SUBACK 报文给客户端，用于确认它已收到并且正処理中に SUBSCRIBE 报文。
SUBACK 报文包含一个返回コード一覧、それらは指定した SUBSCRIBE 请求めた各サブスクリプションが付とされる最大 QoS 等级。
3.9.1 固定报头
图例 3.24 – SUBACK 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (9)
保留位
1
0
0
1
0
0
0
0
byte 2
剩余长度
剩余长度字段
可変ヘッダーの...に等しい长度加上有效ペイロードの長さ。
3.9.2 可变报头
可变报头包含等確認待ちの SUBSCRIBE 报文の报文标识符。图例 3.25 – SUBACK 报文可变报头 可能なことを説明した
可変ヘッダーの形式。
图例 3.25 – SUBACK 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
MQTT-3.1.1-CN 41
3.9.3 有效载荷
有效载荷包含一个返回码清单。每个返回码確認待ちに対応するの SUBSCRIBE パケット内の一个主题过滤器。返回
コードの順序必须と SUBSCRIBE 报文その中のトピックフィルターの順序相同 [MQTT-3.9.3-1]。
图例 3.26 – SUBACK 报文有效载荷格式 記述した有效载荷中单字节エンコードされたリターン码字段。
图例 3.26 – SUBACK 报文有效载荷格式
Bit
7
6
5
4
3
2
1
0
返回码
byte 1
X
0
0
0
0
0
X
X
許可されたリターンコード値：
0x00 - 最大 QoS 0
0x01 - 成功 – 最大 QoS 1
0x02 - 成功 – 最大 QoS 2
0x80 - Failure 失败
0x00, 0x01, 0x02, 0x80 之外の SUBACK 返リターンコードは予約の、不能使用 [MQTT-3.9.3-2]。
3.9.3.1 有效载荷非规范示例
图例 3.27 -有效载荷字节格式非规范示例 に示している 表格 3.6 -有效载荷非规范示例 簡潔に記述された
SUBACK 报文のペイロード。
表格 3.6 -有效载荷非规范示例
Success - Maximum QoS 0
0
Success - Maximum QoS 2
2
Failure
128
图例 3.27 -有效载荷字节格式非规范示例
描述
7
6
5
4
3
2
1
0
byte 1
Success - Maximum QoS 0
0
0
0
0
0
0
0
0
byte 2
Success - Maximum QoS 2
0
0
0
0
0
0
1
0
byte 3
Failure
1
0
0
0
0
0
0
0
3.10 UNSUBSCRIBE –取消订阅
客户端发送 UNSUBSCRIBE 报文给服务端，用于取消订阅主题。
MQTT-3.1.1-CN 42
3.10.1 固定报头
图例 3.28 – UNSUBSCRIBE 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (10)
保留位
1
0
1
0
0
0
1
0
byte 2
剩余长度
UNSUBSCRIBE 报文固固定ヘッダーの第 3,2,1,0 ビットは予約留位且必须分别设置ために 0,0,1,0。服务端必须任意と見なす其
その値はすべて不正法的で、ネットワークを切断する络连接 [MQTT-3.10.1-1]。
剩余长度字段
可変ヘッダーの...に等しい长度加上有效ペイロードの長さ。
3.10.2 可变报头
可变报头包含一个报文标识符。2.3.1 节に関する情報を提供パケット識別子の詳細信息。
图例 3.29 – UNSUBSCRIBE 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
3.10.3 有效载荷
UNSUBSCRIBE メッセージの有效载荷包含客户クライアントが購読を解除したいトピック题过滤器列表。UNSUBSCRIBE パケット内の
主题过滤器必须連続のにパックされており、按照 1.5.3 节定意味の UTF-8 编码字符串 [MQTT-3.10.3-1]。
UNSUBSCRIBE メッセージの有效载荷必须至少包含一个消息过滤器。没有有效载荷の UNSUBSCRIBE メッセージは
プロトコルに違反する [MQTT-3.10.3-2]。有エラー処理に関する詳細情報请查看 4.8 节。
3.10.3.1 有效载荷非规范示例
图例 3.30 -有效载荷字节格式非规范示例 示している 表格 3.7 -有效载荷非规范示例 簡潔に記述された
UNSUBSCRIBE メッセージの有效载荷。
表格 3.7 -有效载荷非规范示例
主题过滤器
“a/b”
主题过滤器
“c/d”
MQTT-3.1.1-CN 43
图例 3.30 -有效载荷字节格式非规范示例
描述
7
6
5
4
3
2
1
0
主题过滤器
byte 1
Length MSB (0)
0
0
0
0
0
0
0
0
byte 2
Length LSB (3)
0
0
0
0
0
0
1
1
byte 3
‘a’ (0x61)
0
1
1
0
0
0
0
1
byte 4
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 5
‘b’ (0x62)
0
1
1
0
0
0
1
0
主题过滤器
byte 6
Length MSB (0)
0
0
0
0
0
0
0
0
byte 7
Length LSB (3)
0
0
0
0
0
0
1
1
byte 8
‘c’ (0x63)
0
1
1
0
0
0
1
1
byte 9
‘/’ (0x2F)
0
0
1
0
1
1
1
1
byte 10
‘d’ (0x64)
0
1
1
0
0
1
0
0
3.10.4 响应
UNSUBSCRIBE 报文提提供されたトピックフィルター（含むかどうかに関わらず通配符）必须サーバーが保持するこのクライアントの現在の主
题过滤器集合逐个字符比较。如果有任何过滤器完全匹配，その場合、それ（サーバーサーバー）自身の購読は削除されます、否则
それ以上の...はありません处理 [MQTT-3.10.4-1]。
如果服务端删除サブスクリプション：
它必须停止分发任何新消メッセージをこのクライアントに户端 [MQTT-3.10.4-2]。
它必须完成分发任何已经开始往客户側から送信された QoS 1 と QoS 2 のメッセージ [MQTT-3.10.4-3]。
它可以继续发送任何现存配信の準備クライアントへのキャッシュ存消息。
服务端必须发送 UNSUBACK 报文响应クライアントの UNSUBSCRIBE 请求。UNSUBACK 报文必须含むと
UNSUBSCRIBE 报文相同じパケット識別子 [MQTT-3.10.4-4]。即使没有删除任何主题订阅，服务端也必须发
送一个 SUBACK 响应 [MQTT-3.10.4-5]。
如果服务端收到包含多个主题フィルターの UNSUBSCRIBE 报文，它必须一連のものを受け取ったかのように多个
UNSUBSCRIBE 报文一同じようにそのパケットを処理し、除いてそれらの応答を一つに統合する個別の UNSUBACK 报文外。
[MQTT-3.10.4-6]。
3.11 UNSUBACK – 取消订阅确认
服务端发送 UNSUBACK 报文给客户端用于确认收到 UNSUBSCRIBE 报文。
MQTT-3.1.1-CN 44
3.11.1 固定报头
图例 3.31 – UNSUBACK 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (11)
保留位
1
0
1
1
0
0
0
0
byte 2
剩余长度 (2)
0
0
0
0
0
0
1
0
剩余长度字段
可変ヘッダーを示す長さ、対 UNSUBACK このメッセージ个值等于 2。
3.11.2 可变报头
可变报头包含等確認待ちの UNSUBSCRIBE 报文のパケット識別子。
图例 3.32 – UNSUBACK 报文可变报头
Bit
7
6
5
4
3
2
1
0
byte 1
报文标识符 MSB
byte 2
报文标识符 LSB
3.11.3 有效载荷
UNSUBACK 报文没有有效载荷。
3.12 PINGREQ – 心跳请求
客户端发送 PINGREQ 报文サーバーに送る。使用于：
1. 他に何もない場合制御パケットはクライアントからクライアントがサーバーに送信するとき、告知服务端客クライアントはまだ生存しています。
2. 请求服务端发送 响应确认它还生きている。
3. 使用网络以确认网络连接没有断开。
保持连接（Keep Alive）处理中用到このパケット、详细信息请查看 3.1.2.10 节。
3.12.1 固定报头
图例 3.33 – PINGREQ 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (12)
保留位
MQTT-3.1.1-CN 45
1
1
0
0
0
0
0
0
byte 2
剩余长度 (0)
0
0
0
0
0
0
0
0
3.12.2 可变报头
PINGREQ 报文没有可变报头。
3.12.3 有效载荷
PINGREQ 报文没有有效载荷。
3.12.4 响应
服务端必须发送 PINGRESP 报文响应クライアントの PINGREQ 报文 [MQTT-3.12.4-1]。
3.13 PINGRESP – 心跳响应
服务端发送 PINGRESP 报文响应客クライアントの PINGREQ 报文。表示服务端还活ている。
保持连接（Keep Alive）处理中用到このパケット、详情请查看 3.1.2.10 节。
3.13.1 固定报头
图例 3.34 – PINGRESP 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (13)
保留位
1
1
0
1
0
0
0
0
byte 2
剩余长度 (0)
0
0
0
0
0
0
0
0
3.13.2 可变报头
PINGRESP 报文没有可变报头。
3.13.3 有效载荷
PINGRESP 报文没有有效载荷。
3.14 DISCONNECT –断开连接
DISCONNECT パケットはクライアントからサーバーへ送信されるサーバーの最後の个控制报文。表示客户端正常断开连接。
MQTT-3.1.1-CN 46
3.14.1 固定报头
图例 3.35 – DISCONNECT 报文固定报头
Bit
7
6
5
4
3
2
1
0
byte 1
MQTT 控制报文类型 (14)
保留位
1
1
1
0
0
0
0
0
byte 2
剩余长度 (0)
0
0
0
0
0
0
0
0
服务端必须すべてのキープアライブを検証する予約ビットはすべて設定に設定する 0，如果それらは～ではない 0 必须断开连接 [MQTT-3.14.1-1]。
3.14.2 可变报头
DISCONNECT 报文没有可变报头。
3.14.3 有效载荷
DISCONNECT 报文没有有效载荷。
3.14.4 响应
客户端发送 DISCONNECT 报文之后：
必须关闭网络连接 [MQTT-3.14.4-1]。
不能そのネットワーク接続を介して、その後发送任何控制报文 [MQTT-3.14.4-2]。
サーバーが受信すると DISCONNECT 报文时：
必须現在の接続に関連するものをすべて破棄する関連する未送信布の遗嘱消息，具体描述见 3.1.2.5 节 [MQTT-3.14.4-3]。
应该关闭网络连接，如果客户端 まだそうしていない。
MQTT-3.1.1-CN 47
4 操作動作
4.1 状态存储
サービス品質を提供するために量保证，客户クライアントとサーバーには必要存储会话状態。セッション全体にわたって间，客クライアントとサーバー都必须
存储会话状态 [MQTT-4.1.0-1]。会话必须少なくともそのアクティブなネットワークと同じくらい持続する络连接同样长の時間 [MQTT-4.1.0-2]。
サーバーの保留メッセージメッセージはセッション状態ではない状態の構成要素。服务端应该そのメッセージを保持息直到客户端删除它。
非规范评注
クライアントとサーバー実装のストレージ容量必然的に有限の、さらに必要になる可能性がある管理ポリシーの制約を受ける限制，比如跨ネットワーク接続のセッション
セッション状態の最大ストレージ储时间。已保保存されたセッション状態喪失は何らかの一つの管理操作によって引き起こされた、例えば某个预定义条
条件の自動応答。それがもたらす結果セッション終了である。これらの操作は可能リソース制限である可能性がある或其他操作原因引发の。必要
顧客を慎重に評価する必要があるクライアントとサーバーのストレージ容量、以确保存储空间够用。
非规范评注
客户端或服务端のソフトウェア／ハードウェア障害都可能导致会话状态の紛失または破損。
非规范评注
サーバーとクライアント操作正常可能つまり、保存された状態态丢失或损坏管理操作またはソフトウェア/ハードウェアである故障によるものです。
管理操作は可能性があるある定義済みの条件に対する自動応答。これは一部の操作は...かもしれない资源限制或其他操作原因によって引き起こされた。
例如，服务端可能会基于外部条件，决定不再将某个消息或某些消息分发给任現在の、または以降後のクライアント
户端。
非规范评注
MQTT 用户应该评估 MQTT クライアントとサーバーの実装のストレージ容量、确保能满足需求。
4.1.1 非规范示例
例如，想要收集電力量計の読み値の使用户可能会决定使用 QoS 1 等级のメッセージ、なぜならそれらはできないからネットワーク上でデータを受信络传输途
中で失われるが、しかし、彼らは思うかもしれないクライアントとサーバーのデータデータは格納できる内存（易失性存储器）中、なぜなら（彼らは思う
得）電力供給は非常に信頼できる、それほど大きな...はない数据丢失风险。
それとは逆に、停止计费支付应用のプロバイダーは任意のものを決定できる何情况下都不能让数据支付消息丢失，因此彼らは要求する
通过网络传输之前、すべてのデータ据必须写入到非易失性存储器中（如硬盘）。
4.2 网络连接
MQTT 协议要求基础传输层能够提供順序付けられた、信頼できるの、双向伝送（クライアントから服务端 とから服务端到客户
端）のバイトストリーム。
非规范评注
MQTT 3.1 使使用されるトランスポート層プロトコルである [RFC793] 定義された TCP/IP 协议。以下のプロトコルも支持：
MQTT-3.1.1-CN 48
TLS 协议 [RFC5246]
WebSocket 协议 [RFC6455]
非规范评注
TCP 端口 8883 と 1883 既に IANA 注册，分别用于 MQTT の TLS と非 TLS 通信。
コネクションレスのネットワーク伝送输协议如 UDP であるサポートされていない、なぜなら彼らは可能能会丢失数据パケット、またはデータパケットの並べ替え。
4.3 サービス品質レベルとプロトコルフロー
MQTT これに従ってここで定義されたサービス务质量 (QoS) 等级分发应用消息。分发プロトコルは対称のであり、以下の記述中では、客户端
とサーバーは両方ともできる送信者でもあり、受信者であり得る。分发协议关注のは単一の送信者から...へ単一の受信者の应用消息。服
务端分发应用消息给多个客户端时，每个客户端独立处理。分发给客户エンドのアウトバウンドアプリケーションメッセージとインバウンドアプリケーションメッセージ
の QoS 等级可異なる場合がある。
以下の非規範的なフローフローチャートは可能であることを示している可能な実装方法。
4.3.1 QoS 0:最多分发一次
メッセージの配信は依存する下位ネットワークの能力。接收者不会发送响应，发送者也不会重试。消息可能送达一次也可能
根本没送达。
に対して QoS 0 の分发协议，发送者
必须发送 QoS 等于 0，DUP 等于 0 の PUBLISH 报文 [MQTT-4.3.1-1]。
に対して QoS 0 の分发协议，接收者
接受 PUBLISH 报文时同时接受信メッセージのすべて权。
图例 4.1 – QoS 0 协议流程图，非规范示例
发送者动作
控制报文
接收者动作
PUBLISH 报文 QoS 0, DUP=0
---------->
分发应用消息给適切な後続の受信收
者（たち）
4.3.2 QoS 1: 至少分发一次
服务质量确保消息至少送达一次。QoS 1 の PUBLISH 报文の可变报头中包含一个报文标识符，需要
PUBACK 报文确认。2.3.1 节パケット識別子に関する情報を提供します識別子の詳細情報。
に対して QoS 1 の分发协议，发送者
毎回新しい応答を送信する用消息都必须分配一个未使用されるパケット識別子符。
送信された PUBLISH 报文必须包含报文标识符且 QoS 等于 1，DUP 等于 0。
MQTT-3.1.1-CN 49
必须これを PUBLISH 报文は～と見なされる
未確認の
，直到受信者から対応するものを受け取る PUBACK 报文。4.4 节
有一个关于未确確認メッセージの議論。
[MQTT-4.3.2-1].
一旦发送者收到 PUBACK 报文，この报文标识符就可以重用。
注意：允许送信者は確認応答を待っている時に異なる...を使用する报文标识符发送后续の PUBLISH 报文。
に対して QoS 1 の分发协议，接收者
応答の PUBACK 报文必须包含一个报文标识符，この識別子を使って受信したものから、已经接受所有権利の
PUBLISH 报文。
送信した PUBACK 报文之后，接收者必须将任何包含相同パケット識別子のインバウンド PUBLISH 报文当作一
新しいメッセージを、そしてそれを無視する DUP 标フラグの値。
[MQTT-4.3.2-2].
图例 4.2 – QoS 1 协议流程图，非规范示例
发送者动作
控制报文
接收者动作
存储消息
发送 PUBLISH 报文 QoS=1,
DUP=0，带报文标识符
---------->
メッセージの適用を開始する后续分发
1
<----------
发送 PUBACK 报文，带报文标
识符
丢弃消息
1
受信者が...にいることを要求しない发送 PUBACK 之前完整分アプリケーションメッセージを送信します。元の发送者收到 PUBACK 报文之后，
アプリケーションメッセージのすべて权就会转移给この受信者。
4.3.3 QoS 2: 仅分发一次
これは最高レベルの服务质量，消息損失と重複すべて受け入れられないの。このサービス品質を使用します量等级会有额追加のオーバーヘッド。
QoS 2 の消去息可变报头中有报文标识符。2.3.1 节に関する情報を提供パケット識別子の更新多信息。QoS 2 の PUBLISH
パケットの受信者は使う用一个两步确认过程来确认收到。
に対して QoS 2 の分发协议，发送者
送信するものに必ずとえる新应用消息分未使用のパケットを割り当てます标识符。
发送の PUBLISH 报文必须包含パケット識別子とパケットの QoS 等于 2,，DUP 等于 0。
必须これを PUBLISH 报文は～と見なされる
未確認の
，直到受信者から対応するものを受け取る PUBREC 报文。4.4 节
有一个关于未确確認メッセージの議論。
MQTT-3.1.1-CN 50
收到 PUBREC 报文后必须发送一个 PUBREL 报文。PUBREL 报文必～とを含まなければならない原始 PUBLISH 报文
相同のパケット識別子。
必须これを PUBREL 报文は～と見なされる
未確認の
，直到受信者から対応するものを受け取る PUBCOMP 报文。
対応するものを送信したらの PUBREL 报文就不能これを再送する PUBLISH 报文。
[MQTT-4.3.3-1].
一旦发送者收到 PUBCOMP パケット、この报文标识符就可以重用。
注意：允许送信者は確認応答を待っている時に異なる...を使用する报文标识符发送后续の PUBLISH 报文。
に対してQoS 2の配信プロトコル、受信者
応答の PUBREC 报文必须包含报文标识符、この識別子受信したものから、已经接受所権利のある
PUBLISH 报文。
対応する...を受信すると PUBREL 报文之前，接收者必须发送 PUBREC 报文确认同じ...を持つ後続の任意の同标识符
の PUBLISH 报文。 この場合、它不能重复分发消息後続のいかなる...にも接收者。
响应 PUBREL メッセージの PUBCOMP 报文必须を含むと PUBREL 报メッセージと同じ識別子符。
发送 PUBCOMP 报文之后，接收者必须将包含相同じパケット識別子を持つ任意の后续 PUBLISH 报文当作一
新しいパブリッシュ。
[MQTT-4.3.3-2].
图例 4.3 – QoS 2 协议流程图，非规范示例
发送者动作
控制报文
接收者动作
存储消息
发送 PUBLISH 报文，QoS=2,
DUP=0，带报文标识符
---------->
方法 A：存储消息，或方法 B：
存储报文标识符，然后开始向前
このアプリケーションメッセージを配信する息
1
。
发送 PUBREC 报文，带报文标
识符。
<----------
丢弃消息，存储 PUBREC 中の
报文标识符
发送 PUBREL 报文，带报文标
识符
---------->
MQTT-3.1.1-CN 51
方法 A：开始向前分发应用消息
1
然后丢弃消息 或方法 B：丢弃
报文标识符
发送 PUBCOMP 报文，带报文
标识符
<----------
保存された状態を破棄する态
1
不要求接收者送信中に PUBREC 或 PUBCOMP 之前完整分发应メッセージを使用します。元の送信者收到
PUBREC 报文之后，应用消メッセージの所有権はこの受信者に転送されます。
图例 4.3 – QoS 2 协议流程图，非规范示例 展示受信者に対する QoS 2 等レベルのメッセージの2種類处理方法。彼ら
違いはメッセージが何么时候可以开始分发。实现者可以决定使用哪种方法。只要实実装者は選択しただけ一种方
法，就不会影响 QoS 流プロセスの信頼性。
4.4 消息分发重试
客户端设置清理会话（CleanSession）标志ために 0 重连时，客户端とサーバー必须使用原元のパケット識別子で再送信します
未確認のあらゆる PUBLISH 报文（如果 QoS>0）と PUBREL 报文 [MQTT-4.4.0-1]。これは唯一一要求客户端或
服务端重发消息の場合。
非规范评注
制御パケットの再送曾经需要克服某些陈旧 TCP ネットワーク上のデータ据丢失问题。それらの環境にデプロイされた MQTT
3.1.1 实现可能仍然需要この問題に注目题。
4.5 消息收到
服务端接管入站アプリケーションメッセージの所有有权时，它必须将消息添加到订阅一致するクライアントのセッション状态中。匹配规则定
义见 4.7 节 [MQTT-4.5.0-1]。
正常情况下，客户端收到发送そのサブスクリプションへの消息。客户端それと関係のないものも受信する可能性がありますサブスクリプションの正確な一致割り当てられたメッセージ。例えば
果服务端自动给クライアントが割り当てた一个订阅，可能このような状況が発生状況。処理中 UBSUBSCRIBE 请求时也可能收到
消息。客户端必须按照可使用されるサービス品質量（QoS）规则确认它收到の任意の PUBLISH 报文，不管它选择処理するかどうか
処理パケットに含まれる応答用消息 [MQTT-4.5.0-2]。
4.6 消息排序
本章で定義されたものを実装する协议流程时，客户端必须遵循下列规则：
以前のあらゆるものを再送する PUBLISH 报文时，必须按原始 PUBLISH 报文の送信順序重发（适用于 QoS 1 と
QoS 2 消息）[MQTT-4.6.0-1]。
必须対応するに従って PUBLISH パケットの順序送信 PUBACK 报文（QoS 1 消息）[MQTT-4.6.0-2]。
必须対応するに従って PUBLISH パケットの順序送信 PUBREC 报文（QoS 2 消息）[MQTT-4.6.0-3]。
必须対応するに従って PUBREC パケットの順序送信 PUBREL 报文（QoS 2 消息）[MQTT-4.6.0-4]。
服务端必须デフォルトでは各トピックはすべて順序の。それは可以提供一个管理功能或其它机制，以允许将一个或多个主
問題を順序なしとみなす [MQTT-4.6.0-5]。
MQTT-3.1.1-CN 52
服务端处理发送順序付きトピックへの消息时，必须按照上面の規則は削除され息分发给每个订阅者。此外，它必须按照
クライアントから受信した顺序发送 PUBLISH 报文给消费者（同じトピックに対する問題と QoS）[MQTT-4.6.0-6]。
非规范评注
上記の規則确保，使用 QoS 1 发布購読のメッセージフローと、订阅者按照消メッセージ公開時の順序序收到每条
消息の最終コピーですが、メッセージは重複する可能性があり、これ原因となる可能性があり、その後続メッセージの間に后收到某个已すでにメッセージを受信した
重发版本。例如，发布者按顺序 1,2,3,4 发送消息，订阅購読者が受け取る順序かもしれない 1,2,3,2,3,4。
もしクライアントとサーバーが务端能保证任何时刻最多有一条消息が
传输中（
in-flight
）
（あるメッセージが確認される前
後続のその部分を送信しない件のメッセージ）、その場合么，不会有 QoS 1 のメッセージそのいずれかの前に発生する后续消息之后收到。 例如，
購読者が受け取る順序かもしれない 1,2,3,3,4、ではなく 1,2,3,2,3,4。将传输窗口 （in-flight window）设ために 1
つまり、同じ个主题上，即使发布者发送一連の異なる QoS レベルのメッセージ、それらの順序も保護される
留。
4.7 トピック名とトピックフィルター
4.7.1 主题通配符
主题层级（topic level）分隔符用于将结构化引入主题名。もし区切りが存在するなら隔符，它将主題名を複数に分割する
主题层
级
topic level 。
購読するトピックフィルタ器可以包含特特別なワイルドカードを使用すると、あなたは一次订阅多个主题。
主题过滤器中可以使用通配符、ただしトピック名は不能使用通配符 [MQTT-4.7.1-1]。
4.7.1.1 主题层级分隔符
斜杠（‘/’ U+002F）用于分割されたトピックの各层级、テーマ名に階層を提供する结构。当客户クライアントが購読を指定した主题过滤
器包含两种通配符时，主题层级分隔符就很役に立つようになりました。トピック层级分隔符可トピックフィルターに出現できますまたはトピック名の
任何位置。相邻トピックの階層区分隔符表示一个長さゼロのトピック层级。
4.7.1.2 多层通配符
数字标志（‘#’ U+0023）は使用于匹配主题中任意层级のワイルドカード。マルチレベルワイルドカードワイルドカードはその親レベルと任意の数の量のサブ
层级。多层通配符必须位于它自身のレベルまたは後続に主题层级分隔符后面。不管哪种情况，它都必须はトピック
フィルタの最後の个字符 [MQTT-4.7.1-2]。
非规范评注
例如，如果客户端订阅主题 “sport/tennis/player1/#”，它会收到使用下列トピック名で公開された消息：
“sport/tennis/player1”
“sport/tennis/player1/ranking”
“sport/tennis/player1/score/wimbledon”
非规范评注
“sport/#”也匹配単独の “sport” 、なぜなら # 包括その親レベル。
“#”は有効の、会收到所有のアプリケーションメッセージ。
“sport/tennis/#”也は有効の。
“sport/tennis#”は無効の。
MQTT-3.1.1-CN 53
“sport/tennis/#/ranking”である無効である。
4.7.1.3 单层通配符
加号 (‘+’ U+002B) は～のみ使用できる于单个主题层レベルに一致するワイルドカード符。
トピックフィルタの任意层级都可以使用单层通配符，包括第1つのレベルと最後のレベル。然而它必须フィルターの
整个层级 [MQTT-4.7.1-3]。トピックフィルタ内で可能フィルター内の複数のレベル级中使用它，複数のレベルとも一致できます通配符一起使用。
非规范评注
例如， “sport/tennis/+” 匹配 “sport/tennis/player1” と “sport/tennis/player2” ，しかし不匹配
“sport/tennis/player1/ranking” 。同时，由于单层通配符只能匹配一个层级， “sport/+” 不匹配
“sport” しかし～と一致する配 “sport/”。
非规范评注
“+” は有効の。
“+/tennis/#” は有効の。
“sport+” は無効の。
“sport/+/player1” これも有効です。
“/finance” 匹配 “+/+” と “/+” 、しかし～ではない匹配 “+”。
4.7.2 以$で始まるトピック
服务端不能将 $ 字符开先頭のトピック名と一致配通配符 (#或+) 开先頭のトピックフィルタ [MQTT-4.7.2-1]。服务端应该阻止
クライアントはこのようなトピック名と他の客户端交换消息。服务端实现可以将 $ 先頭のトピック名には他の目的に使用します。
非规范评注
$SYS/ 広く用作包含服务器特定信息或控制接口トピックの接頭辞。
应用不能使用 $ 文字で始まるトピック题。
非规范评注
订阅 “#” のクライアントは受信しない到任何发布到以 “$” 开头主トピックのメッセージ。
订阅 “+/monitor/Clients” のクライアントは...ない会收到任何发布到 “$SYS/monitor/Clients” の消去息。
订阅 “$SYS/#” のクライアント会收到发布到以 “$SYS/” 开头トピックのメッセージ。
订阅 “$SYS/monitor/+” の客户端会收到发布到 “$SYS/monitor/Clients” 主トピックのメッセージ。
如果客户端想同时接受以 “$SYS/” 开头主题メッセージと、～で始まらない $ 开头主题のメッセージには、それが必要同时
订阅 “#” と ““$SYS/#”。
4.7.3 主题语义と用法
トピック名とトピックフィルタ滤器必须符合下列规则：
すべてのトピック名と主题过滤器必须至少包含一个字符 [MQTT-4.7.3-1]。
トピック名とトピックフィルタフィルターは大文字と小文字を区別します小文字である。
トピック名とトピックフィルタ滤器可以包含空格。
MQTT-3.1.1-CN 54
主题名或主题过滤器以前置或后置斜杠 “/” 区分。
只包含斜杠 “/” のトピック名またはトピックフィルターフィルターは有効です。
トピック名とトピックフィルタ滤器不能包含空字符 (Unicode U+0000) [Unicode] [MQTT-4.7.3-2]。
トピック名とトピックフィルタフィルターは UTF-8 编码字符串、それら不能超过 65535 字节 [MQTT-4.7.3-3]。见 1.5.3
节。
除いて不能超过 UTF-编码字符文字列の長さの制限之外，主题名或主题フィルターの階層レベル数量没有其它限制。
匹配订阅时，服务端不能トピック名または主题过滤器执行任何规范化（normalization）处理，不能修改或替换
未認識の文字は符 [MQTT-4.7.3-4]。主题フィルター内の各非ワイルドカード文字符层级需要逐字符匹配主题名前の中の対応するレベル
级才算匹配成功。
非规范评注
使用 UTF-8 エンコード規則は意味する，主题过滤器トピック名との比較较可以通过比エンコード後の比較 UTF-8 字节或解
エンコード後の Unicode 字符。
非规范评注
“ACCOUNTS” と “Accounts” は異なるトピック题名。
“Accounts payable” 適合である有効なトピック名
“/finance” と “finance” は異なるの。
如果購読したトピックフィルターとメッセージトピック名のマッチング，应用消息会それぞれに送信されるマッチしたクライアント端订阅。主题かもしれない
管理者はサーバー側で事前定義された、またはサーバー务端收到第一あるサブスクリプション、またはそのトピックを使用するトピック名のアプリケーションメッセージ息时动态添加
の。サーバー側も可能以使用一个安全组件有选择地授权客户端使用某个主题资源。
4.8 错误处理
除非另有说明，如果服务端或クライアントが遭遇したプロトコル違反の行為、它必须この伝送を閉じる个协议违规制御パケットのネットワーク
络连接 [MQTT-4.8.0-1]。
客户端或服务端实现可能会遇到瞬时错误（Transient Error）（例如内内部バッファがいっぱいになったの状況）が原因で无法成功
处理 MQTT 报文。
如果客户端或服务端处理入站制御パケット処理中に一時的な問題が発生しました时错误，它必须その送信を閉じる制御パケットのネットワーク接続接
[MQTT-4.8.0-2]。如果サーバーは発見した瞬时错误，它不应该断开连接或者执行他のクライアントに対するいかなるクライアントに影響をとえる操作
作。
MQTT-3.1.1-CN 55
5 安全
5.1 概述
本章の内容は参考用のみ参考、非規範規範的な。しかし，强烈推荐提供 TLS の服务端实现应该使用 TCP 端口 8883
（IANA 服务名：secure-mqtt）。
解决方案提供者需要考虑很多风险。例如：
デバイスが盗まれる可能性がある用
クライアントとサーバーの静的データは可能アクセス可能である（修正される可能性がある改）
プロトコルの動作には副作用（如计时器攻击）
拒绝服务攻击
通信が傍受される可能性がある截、修改、重定向或者泄露
虚假控制报文注入
MQTT 方案通通常は展開され安全な通信環境中で。ここでは种情况下，协议实现通常需これらのメカニズムを提供する必要がある：
ユーザーとデバイスの身元认证
服务端资源访问授权
MQTT 控制报文と埋め込みアプリ用データの完全性整性校验
MQTT 控制报文と埋め込みアプリ用データのプライバシー私控制
トランスポート層プロトコルとして，MQTT 仅关注消息传输，適切なセキュリティを提供する完全な機能の実装は実装者の責任です任。使用 TLS [RFC5246] である
比較の一般的な選択。技術のな面は別としてのセキュリティ問題のほかに、还有地理因素（例如美国欧盟安全港原则
[USEUSAFEHARB]），行业标准（例如第三方支付行业数据安全标准 [PCIDSS]），监管側面の考慮（例
如萨班斯-奥克斯利法案 [SARBANES]）等问题。
5.2 MQTT 解決策：セキュリティと認証
协议实现可能想特定の要件を満たす必要がある工业安全标准，如 NIST 网络安全框架 [NISTCSF] ，第三方支付行业数据安
全标准 [PCIDSS] ，美国联邦信息处理标准 [FIPS1402] と NSA 加密组合 B [NSAB] 。
に MQTT の補足充出版物 （MQTT and the NIST Framework for Improving Critical Infrastructure
Cybersecurity [MQTT NIST]） 中可以找到に NIST 网络安全框架 [NISTCSF] 中使用 MQTT の指导。使用
行业证明、独立監査および認証技術术有助于满足合规要求。
5.3 軽量な暗号化と制約のあるデバイス
广泛采用高级加密标准 [AES] 数据加密标准 [DES] 。
制限された環境での使用を推奨のローエンドデバイスの特性特に最適化された軽量量级加密国际标准 ISO 29192 [ISO29192] 。
5.4 实现注意事项
実装と使用 MQTT 时需要考虑许多安全问题。下面の部分はすべきではないそれは一つのものとして扱われるべき个 チェックリスト 。
协议实现可以实以下の一部を実装する分或全部：
MQTT-3.1.1-CN 56
5.4.1 客户端身份验证
CONNECT 报文包含用户名前とパスワードフィールド。实现これらの文字をどのように使用するかを決定できる段落の内容。実際现者可以提供自分の
身份验证机制，或者使用外部の認証システムのような LDAP [RFC4511] 或 OAuth [RFC6749] ，还可以利用操作系统
の認証メカニズム。
实现可以明文传递认证数据，それらのデータを難読化する，或者不要求任何认证数据，但应该意识これにより中間者...が増加する间人攻
攻撃とリプレイ攻撃の风险。5.4.5 节確認を紹介したデータの機密性を保証する方法。
クライアント側とサーバー側の端之间使用虚拟专用网（VPN）可以确保数据只認可されたクライアント端收到。
使用 TLS [RFC5246] 时，服务端可以使用クライアントが送信した SSL 证书验证客户端の身分。
实现可以允许客户端通过应用消息给服务端发送凭证用于身份验证。
5.4.2 客户端授权
基于客户端提供の情報（ユーザーなど）名、客户端标识符（ClientId）、客户端のホスト名または IP 地址，或者身份认证
の結果、サーバー側は特定の...へのアクセスを制限できる些服务端资源のアクセス。
5.4.3 服务端身份验证
MQTT 协议不は双方向の信頼の、それはない提供客户端验证服务端身份の仕組み。
しかし使用 TLS [RFC5246] 时，客户端可以使用服サーバー側が送信した SSL 证书验证服务端の身元。単一の接続から IP 多域名
提供 MQTT サービスの実装は考虑 RFC6066 [RFC6066] 第 3 节定義された TLS の SNI 扩展。SNI 允许客户端
告诉服务端它要接続のサーバー主机名。
实现可以允许服务端通过应用消息给客户端发送凭证用于身份验证。
クライアント側とサーバー側の端之间使用虚拟专用网（VPN）可以确保客户端接続は意図されたもののサーバー。
5.4.4 控制报文とアプリケーションメッセージメッセージの完全性整性
アプリケーションはアプリケーション層で消息中单独包ハッシュ値を含む。これはこのようにすることで PUBLISH 控制メッセージのネットワーク転送転送と静的データ提供内容
の完全性チェック。
TLS [RFC5246] 提ネットワークに対して提供した送信されるデータに対して整合性チェック用のハッシュアルゴリズム法。
クライアント側とサーバー側の端之间使用虚拟专用网（VPN）连接〜することができる VPN カバーされる网络段提供数据完整性检查。
5.4.5 制御メッセージと应用消息の機密性
TLS [RFC5246] 可ネットワーク伝送に対して転送データの暗号化。有効な場合 TLS 密码组組み合わせに含まれる暗号化アルゴリズムは NULL，それなら
不会加密数据。要确保客户端とサーバー側の保密，应避免使これらの暗号スイートを使用合。
应用可以单独加暗号化アプリケーションメッセージの内容。これにより提供应用消息传输途中和と静的データの機密性性。但不能给应用消
情報のその他の属性、例えば主题名加密。
クライアントとサーバー实现可以加密存储静态数据，例如可以将应用消情報をセッションの一部として存储。
クライアント側とサーバー側の端之间使用虚拟专用网（VPN）连接〜することができる VPN カバーされるネットワークセグメントはデータを保証する私密性。
5.4.6 メッセージ伝送の不可否认性
应用设计者可能需要考虑适当の戦略により、実現エンドツーエンドの非可否认性（non-repudiation）。
MQTT-3.1.1-CN 57
5.4.7 检测客户クライアントとサーバーサーバー側の盗用
使用 TLS [RFC5246] のクライアントクライアントとサーバーの実装は〜すべきです能够确保，初始化 TLS [RFC5246] 连接时提提供の SSL 证
証明書はホスト名（客户端要连接の、またはサーバーが接続されますの）関連関連している。
使用 TLS [RFC5246] のクライアントクライアントとサーバーの実装は、〜できます以选择提供检查证书吊销列表 (CRLs [RFC5280]) とオンライン
证书状态协议 (OSCP) [RFC6960] の功能，失効したものの使用を拒否する证书。
物理部署可以将耐改ざんハードウェアとアプリケーションメッセージの特殊データ传输结合。例如，一个仪表可能会内置一个 GPS 以确保
許可されていない...にはない地区使用。IEEE 安全设备认证 [IEEE 802.1AR] つまり使用このメカニズムを実現するための制御の標準であり、它使
用加密绑定标识符验证设备身份。
5.4.8 異常な動作を検出する
服务端实现可以クライアントの監視行動、潜にのな存在するセキュリティリスク。例如：
重複した接続要求
重複する認証请求
接続の異常終了
主题扫描（请求发送或订阅大量主题）
配信できない...を送信する消息（没有订購読者のトピック）
クライアントは接続するが、不发送数据
发现违反安全规規則の行動、サービス务端实现可以断开客户端连接。
服务端实现检测望ましくない行為行動、に基づくことができる IP 地址或客户端标识符实现一个动态黑名单列表。
服务部署可以使用网络层次控制（如果可用）实现基于 IP 地址或其その情報のレート制限或黑名单。
5.4.9 其它の安全全注意事项
如果客户端或服サーバー側の SSL 证书丢失，或者我証明書が盗まれることを考慮する使用または失効(利用 CRLs [RFC5280] と
OSCP [RFC6960])の情况。
客户端或服务端验证凭证时，如果发现用户ユーザー名とパスワードの紛失または盗用され、该吊销或者重新发放。
持続のな接続を使用する場合：
クライアントとサーバー使用 TLS [RFC5246] 时应该允许重新协商会话以确认新しい暗号化パラメータ（置換会话密
钥，更换密码组合，更换认证凭证）。
服务端可以断开客户端连接，そして彼らに使用を要求新しい資格情報を使用して再新验证身份。
制限されたネットワーク上の信頼された制限されたデバイスとクライアント端可以使用 TLS 会话恢复 [RFC5077] 降低 TLS 会话重连 [RFC5246] の成果
本。
サーバー側に接続するクライアントと他のサーバーに接続しているクライアント端 之间有一个信任传递关系、それらはすべて権利を有する同じトピック上で
上发布消息。
MQTT-3.1.1-CN 58
5.4.10 使用 SOCKS 代理
客户端实现应该意识到某些环境要求使用 SOCKSv5 [RFC1928] 代アウトバウンドの作成を管理网络连接。某些 MQTT 实
现可以利用安全隧道（如 SSH）通过 SOCKS 代理。一个实现决定支持 SOCKS 时，それらは同時にサポートすべきである匿
名前とユーザー名・パスワードのコード検証の SOCKS 代理。後者の場合情况，实现应该意识到 SOCKS 可能使用明文认证，
因此同じ認証情報を使用することは避けるべきである连接 MQTT 服务器。
5.4.11 安全配置文件
実装者と設計者计者可能希望将安全当作配置文件集合应用到 MQTT プロトコル中。以下で説明するは階層型のセキュリティ...
全等级结构。
5.4.11.1 开放通信配置
使用开放通信配置时，MQTT プロトコルは組み込みの追加なしで実行されます外部安全通信機構の開始放网络上。
5.4.11.2 安全网络通信配置
使用安全网络通信配置时，MQTT 协议运安全な環境で実行され制御された物理または仮想网络上，如 VPN 或物理安全网络。
5.4.11.3 安全传输配置
使用安全传输配置时，MQTT プロトコルは...で動作する使用 TLS [RFC5246] の物理或虚拟网络上，它提認証を提供，
完全性と機密性。
組み込みのユーザーを使用するユーザー名とパスワードフィールド，TLS [RFC5246] 客户端身認証は使用可能于（或者代替）MQTT 客户端认
证。
5.4.11.4 業界標準のセキュリティ全配置
当然のことながら、MQTT されるサポートするように設計されている多くの産業標準アプリケーション配置，每一种定义一脅威モデルと定義に使用する位威胁
の特別なセキュリティ機構。特別なセキュリティメカニズムは以下の方法から推奨される案中选择：
[NISTCSF] NIST 网络安全框架
[NIST7628] NISTIR 7628 智能电网网络安全指南
[FIPS1402] (FIPS PUB 140-2) 加密模块のセキュリティ要件
[PCIDSS] PCI-DSS 第三方支付行业数据安全标准
[NSAB] NSA 加密组合 B
MQTT-3.1.1-CN 59
6 使用 WebSocket として网络层
如果 MQTT に WebSocket [RFC6455] 连接上传输，必须满足以下の条件：
MQTT 控制报文必须使用 WebSocket 二进制数据帧发送。如果受信した他の任意のタイプの数据帧，接收
者必须关闭网络连接 [MQTT-6.0.0-1]。
单个 WebSocket 数据帧可以包含多个或者部分 MQTT 报文。接收者不能假设 MQTT 控制报文按
WebSocket フレーム境界のアライメント [MQTT-6.0.0-2]。
客户端必须将字符串 mqtt それに含まれている提供された WebSocket 子协议列表里 [MQTT-6.0.0-3]。
サーバー側の選択と返却戻りの WebSocket 子协议名必须である mqtt [MQTT-6.0.0-4] 。
用于连接客户端とサーバーの WebSocket URI に対して MQTT 协议没有任何影响。
6.1 IANA 注意事项
本规范请求 IANA に WebSocket 子协议名条目下注册 WebSocket MQTT 子协议，使用下列数据：
图例 6.1 - IANA WebSocket 标识符
子协议标识符
mqtt
子协议通用名
mqtt
子协议定义
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
MQTT-3.1.1-CN 60
7 一致性
MQTT 规范定定義した MQTT 客クライアント実装と MQTT サーバー側実装の一致性要求
MQTT 实现可同時に～である MQTT クライアントと MQTT 服务端。接受入站连接および他への確立サーバーのアウトバウンド接続の服
务端必须同时符合 MQTT 客クライアントと MQTT サーバー側の要件求 [MQTT-7.0.0-1]。
他のあらゆるものと一貫性のある実装交互操作，一致性实现不能本仕様に従って使用することが要求される外部定義された任意の扩展 [MQTT-
7.0.0-2]。
7.1 一致性目标
7.1.1 MQTT 服务端
一个 MQTT 服务端只有满足下面所有の要件を満たして初めて適合する本规范：
1. 服务端发送のすべての制御メッセージの形式は...に準拠しなければならない第2章と第第3章で説明されている形式
2. 遵守第 4.7 節に記載されているトピックに一致配规则。
3. 满足下列章节中所有必须レベルの要件求，明确クライアントに対してのみ適用されるの例外：
- 第一章 – 介绍
- 第二章 – MQTT 控制报文格式
- 第三章 – MQTT 控制报文
- 第四章 – 操作動作
- 第六章 –（如果 MQTT のネットワーク層は WebSocket）
- 第七章 – 一致性目标
满足一致性要求のサーバー必须支持使用一个或多个底层传输协议，只要それは順序付きの、信頼性のある、双向字节
フロー（クライアントからサーバー側とクライアント务端到客户端）[MQTT-7.1.1-1]。しかし一致性并不依赖于它支任意の特定のサポート
传输协议。服务端可以支持第 4.2 节リストされた任意の传输协议，或者任何其它满足 [MQTT-7.1.1-1] 要求の传输
协议。
7.1.2 MQTT 客户端
一个 MQTT 客户端只有满足以下のすべての要件要件を満たして初めて適合本规范：
1. 客户端发送のすべての制御メッセージの形式は...に準拠しなければならない第2章と第第3章で説明されている形式
2. 满足下列章节中所有必须レベルの要件求，明确サーバーに対してのみ適用されるの例外：
- 第一章 – 介绍
- 第二章 – MQTT 控制报文格式
- 第三章 – MQTT 控制报文
- 第四章 – 操作動作
- 第六章 – （如果 MQTT のネットワークネットワーク層は WebSocket）
- 第七章 – 一致性目标
满足一致性要求のクライアント必须支持使用一个或多个底层传输协议，只要それは順序付きの、信頼性のある、双向字节
フロー（クライアントからサーバー側とクライアント务端到客户端）[MQTT-7.1.2-1]。しかし一致性并不依赖于它支任意の特定のサポート
MQTT-3.1.1-CN 61
传输协议。客户端可以支持第 4.2 节リストされた任意の传输协议，或者任何其它满足 [MQTT-7.1.2-1] 要求の传输
协议。
MQTT-3.1.1-CN 62
附录 B 强制性规范声明（非规范）
この付録は非規範規範的な、単に...として本文档正文中見つけることができる大量一致性声明の要約として提供。適合性要件の限制列
表见第七章。
声明序号
规范声明
[MQTT-1.5.3-1]
UTF-8 エンコードされた文字列の中の文字符数据必须に従って Unicode 规范 [Unicode] 定義された...と...で
RFC3629 [RFC3629] 中重申請した有効な UTF-8 格式。特他に指摘すべき点は、これらの数
据不能文字コードを含む U+D800 と U+DFFF 之间のデータ。如果服务端或客户端收到
無効な...を含む... UTF-8 字符の制御パケット、它必须关闭网络连接。
[MQTT-1.5.3-2]
UTF-8 エンコードされた文字列不能包含空字符 U+0000。如果客户端或服务端收パケットが到着した
含 U+0000 の控制报文，它必须关闭网络连接。
[MQTT-1.5.3-3]
UTF-8 编码序列 0XEF 0xBB 0xBF 总として解釈される U+FEFF（零宽度非换行空白字
符），无论それは文字列の中に現れる什么位置，报文接收者都不能跳过或者剥离它。
[MQTT-2.2.2-1]
表格 2.2 中の任意のフラグが“保留”のフラグビットはすべて予約将来のために予約された，必须テーブルとして設定
に列挙された値。
[MQTT-2.2.2-2]
如果不正なフラグを受信した場合、接收者必须关闭网络连接。
[MQTT-2.3.1-1]
SUBSCRIBE，UNSUBSCRIBE と PUBLISH（QoS 大于 0）控制报文必须包含一
非ゼロの 16 位报文标识符（Packet Identifier。
[MQTT-2.3.1-2]
客户端每次发送これらの新しいもの種類のメッセージのときは常に必须分配一个当前未使用のパケット标
识符。
[MQTT-2.3.1-3]
如果クライアントがこの特定のものを再送信しようとする特殊な制御パケット、その後再送そのパケットのとき、它必须使
同じ識別子を使用する。当客户端处このパケットに対応する処理を完了した確認後、この报文标识符就释
放可重用。QoS 1 の PUBLISH に対して対応するのは PUBACK，QoS 2 の PUBLISH 対応する
である PUBCOMP、と SUBSCRIBE 或 UNSUBSCRIBE に対して対応するものはそれぞれ SUBACK 或
UNSUBACK
[MQTT-2.3.1-4]
发送一个 QoS 0 の PUBLISH 报文时，相同の条件はサーバーにも適用される端。
[MQTT-2.3.1-5]
QoS に設定される 0 の PUBLISH 报文不能包含报文标识符。
[MQTT-2.3.1-6]
PUBACK, PUBREC, PUBREL 报文必须を含むと最初に送信された PUBLISH メッセージと同じ
报文标识符。
[MQTT-2.3.1-7]
と [MQTT-2.3.1-6] 类似，SUBACK と UNSUBACK 必须対応する～に含まれる
SUBSCRIBE と UNSUBSCRIBE 报文中で使用されるパケット識別子符。
[MQTT-3.1.0-1]
客户端到服务端ネットワーク接続の確立立后，客户端发送给サーバーの最初の个报文必须である
CONNECT 报文。
[MQTT-3.1.0-2]
ネットワーク接続内で上，客户端只能发送一次 CONNECT 报文。服务端必须将客户端
送信された2番目の CONNECT 报文当作协议违规处理そしてクライアントの接続を切断する。
[MQTT-3.1.2-1]
如果协议名不正确服务端可以断开客户端の接続、また可以按照某些其它规范继续
处理 CONNECT パケット。については后一种情况，按照本规范，服务端不能继续处理
CONNECT 报文。
MQTT-3.1.1-CN 63
[MQTT-3.1.2-2]
如果发现不支持のプロトコルレベル、服务端必须给发送一个リターンコードは 0x01（サポートされていないプロトコル
议级别）の CONNACK 报文响应 CONNECT 报文，然后クライアントの接続を切断する。
[MQTT-3.1.2-3]
服务端必须验证 CONNECT 制御パケットの保留留标志位（第 0 ビット）が〜であるかどうか 0，如果不
ために 0 必须断开客户端连接。
[MQTT-3.1.2-4]
如果清理会话（CleanSession）フラグが設定されに設定する 0，服务端必须基于当前会话（使
用客户端标识符識別）の状態クライアントとの回復の通信。もしこのクライアント識別子に関連するものはない识
識別子に関連付けられたセッション、服务端必须创建一个新しいセッション。では连接断开之后，当连接断开
后，クライアントとサーバー必须保存会话信息。
[MQTT-3.1.2-5]
当清理会话标志ために 0 のセッション接続接断开之后，服务端必须以降の QoS 1 と QoS 2
レベルのメッセージ保存セッション状態のための一部分，如果これらのメッセージの一致断开连接时客クライアントの任意の
何订阅。
[MQTT-3.1.2-6]
如果清理会话（CleanSession）フラグが設定されに設定する 1，客户端とサーバー必须丢弃之前
の任意のセッションを開始し新しいセッションを開始セッション。セッションはネットワークとの間だけ継続する络连接同样长の時間。とこの
セッションに関連付けられた状態数据不能何らかの後でのセッション再利用。
[MQTT-3.1.2.7]
保留メッセージはサーバーではない务端会话状态の一部であり、セッションは終了する时不能删除保留消息。
[MQTT-3.1.2-8]
遗嘱标志（Will Flag）設定されために 1，表示如もし接続要求が受け付けられました、遺言（Will
Message）消息必须に格納されサーバーであり、このネットワークと络连接关联。之后网络连接关
闭时，服务端必须この遺言メッセージをパブリッシュする，除非服务端收到 DISCONNECT 报文时删
この遺言メッセージ以外息。
[MQTT-3.1.2-9]
遺言フラグがに設定される 1，连接続フラグ中の Will QoS と Will Retain 字段サーバー側で
用到，同时有效载荷中必须包含 Will Topic と Will Message 字段。
[MQTT-3.1.2-10]
一度公開されると、またはサーバーが受信したクライアントが送信した DISCONNECT 报文，遗嘱消息就必
须ストレージから保存されたセッション状態から削除する。
[MQTT-3.1.2-11]
遺言フラグがに設定される 0，连接フラグの中の Will QoS と Will Retain 字段必须に設定される
0，并且有效载荷中不能包含 Will Topic と Will Message 字段。
[MQTT-3.1.2-12]
遺言フラグがに設定される 0，网络连接断开时，不能发送遗嘱消息。.
[MQTT-3.1.2-13]
遺言フラグがに設定される 0，遗嘱 QoS 也必须に設定される 0(0x00)。
[MQTT-3.1.2-14]
遺言フラグがに設定される 1，遗嘱 QoS の値可以等于 0(0x00)，1(0x01)，2(0x02)。
その値不能等于 3。
[MQTT-3.1.2-15]
遺言フラグがに設定される 0，遗嘱保留（Will Retain）标志也必须に設定される 0。
[MQTT-3.1.2-16]
如果遺言保持が設定されます 0，服务端必须将遗嘱消息当作非保留消息发布。
[MQTT-3.1.2-17]
如果遺言保持が設定されます 1，服务端必须将遗嘱消息当作保留消息发布。
[MQTT-3.1.2-18]
如果用户名（User Name）フラグは設定される 0，有效载荷中不能包含用户名字段。
[MQTT-3.1.2-19]
如果用户名（User Name）フラグは設定される 1，有效载荷中必须包含用户名字段。
[MQTT-3.1.2-20]
如果密码（Password）标志に設定される 0，有效载荷中不能包含密码字段。
[MQTT-3.1.2-21]
如果密码（Password）标志に設定される 1，有效载荷中必须包含密码字段
MQTT-3.1.1-CN 64
[MQTT-3.1.2-22]
如果用户名标志に設定される 0，密码标志也必须に設定される 0。
[MQTT-3.1.2-23]
客户端负责保证控制报文发送の時間間隔はキープアライブを超えない接続を保持する値。如果没有任何其
その制御パケットは以发送，客户端必须发送一个 PINGREQ 报文。
[MQTT-3.1.2-24]
もしキープアライブの值非零，并且サーバーは1.5倍の保持连接时间内没有收到客户
端の制御パケット、它必须クライアントを切断する网络连接，考える网络连接已断开。
[MQTT-3.1.3-1]
含まれている場合、必须この順序で現れる：客户端标识符，遗嘱主题，遗嘱消息，用
户名，密码。
[MQTT-3.1.3-2]
服务端使用客户端标识符 (ClientId) 识别客户端。连接服サーバーの各クライアント户端都有唯
一意のクライアント識別子符（ClientId）。クライアントと服务端都必须使用 ClientId 识别两者之
間の MQTT セッション関連の状態。
[MQTT-3.1.3-3]
客户端标识符 (ClientId) 必须存在而且必须である CONNECT 报文ペイロードの第一个
字段。
[MQTT-3.1.3-4]
客户端标识符必须である 1.5.3 バイトで定義された UTF-8 编码字符串。
[MQTT-3.1.3-5]
服务端必须允许 1 到 23 バイト長の UTF-8 エンコードされたクライアント端标识符，客户端标识符
これらの文字のみを含む符：
“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY
Z”（大写字母、小文字と数字字）。
[MQTT-3.1.3-6]
服务端可以允许客户端提供一个零字ノードのクライアント識別子识符 (ClientId) ，もしそうした場合
ました、服务端必须これを特別な場合と見なして一意のクライアントを割り当てる户端标识符给そのクライアント。然
后它必须假设客户側がその唯一のものを提供したクライアント識別子符，正常これを処理する CONNECT
报文。
[MQTT-3.1.3-7]
如果客户サーバーはゼロバイトを提供するクライアント識別子符，它必须同时将清理会话标志设置
ために 1。
[MQTT-3.1.3-8]
如果客户端提供の ClientId ゼロバイトである且清理会话标志は 0，服务端必须发送返回码
ために 0x02（表示标识符不合格）の CONNACK 报文响应クライアントの CONNECT 报
文，然后关闭网络连接。
[MQTT-3.1.3-9]
如果服务端拒绝したこの ClientId，它必须发送返回コードは 0x02（表示标识符不合
格）の CONNACK 报文响应クライアントの CONNECT 报文，然后关闭网络连接。
[MQTT-3.1.3-10]
遗嘱主题必须である 1.5.3 バイトで定義された UTF-8 编码字符串。
[MQTT-3.1.3-11]
用户名必须である 1.5.3 バイトで定義された UTF-8 编码字符串。
[MQTT-3.1.4-1]
服务端必须按照 3.1 节の要件の検証 CONNECT 报文，如果报文不符合规范，服务
端不发送 CONNACK 报文直接关闭网络连接。
[MQTT-3.1.4-2]
如果 ClientId 表明客户端已经连接到このサーバーは、その場合、サーバーは必须断开原一部のクライアント
端连接。
[MQTT-3.1.4-3]
服务端必须按照 3.1.2.4 節の描述执行清理セッションのプロセス。
[MQTT-3.1.4-4]
服务端必须发送返リターンコードがゼロの CONNACK パケットとして CONNECT メッセージの确认响应。
[MQTT-3.1.4-5]
如果サーバーが拒否した CONNECT，它不能クライアントでの処理 CONNECT 报文之后发送の
任何数据。
MQTT-3.1.1-CN 65
[MQTT-3.2.0-1]
服务端发送 CONNACK 报文クライアントから受信した応答 CONNECT 报文。服务端发送给
クライアントの最初の报文必须である CONNACK。
[MQTT-3.2.2-1]
如果服务端收到清理会话（CleanSession）标志ために 1 の连接，除た将 CONNACK
パケット内のリターンコードに設定される 0 之外，还必须将 CONNACK パケット内の当前会话设置
（Session Present）マークされる 0。
[MQTT-3.2.2-2]
如果服务端收到一个 CleanSession ために 0 の连接，当前会セッションフラグの値を取得决于服务端
すでに保存されているかどうか ClientId に対して应客户端のセッション状態。如果服务端已经保存セッション状態を
态，它必须将 CONNACK 报本文中の現在のセッションフラグに設定される 1。
[MQTT-3.2.2-3]
如果サーバー側には保存されたセッションがない状态，它必须将 CONNACK 报文中の現在のセッション設定置
ために 0。还需要将 CONNACK 报メッセージ内のリターンコードは...に設定される 0。
[MQTT-3.2.2-4]
如果服务端发送非可変ゼロの戻りコードの CONNACK 报文，它必须将当前会话标
フラグが設定される 0。
[MQTT-3.2.2-5]
如果服务端发送非可変ゼロの戻りコードの CONNACK 报文，では它必须关闭网络
连接。.
[MQTT-3.2.2-6]
もし上記の表が 3.1 内のすべての接続が回码都不太合适，では服务端必须关闭网络连
接，不需要发送 CONNACK 报文。
[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 パケットと受信（インバウンド）の
PUBLISH 报文中の DUP 标フラグは独立設定された、その値は必须单独の送信（出）に基づく
サイト）の PUBLISH 报文が～であるかどうか一个重发来确定。
[MQTT-3.3.1-4]
PUBLISH 报文不能将 QoS 所一部のビットが...に設定される 1。如果服务端或客户端收到 QoS 所
すべてのビットが 1 の PUBLISH 报文，它必须关闭网络连接。
[MQTT-3.3.1-5]
如果客户端发给サーバー側の PUBLISH 报文の保留（RETAIN）标フラグが〜に設定される 1，服
务端必须このアプリケーションメッセージとそのサービスを保存する务质量等级（QoS），以便それは配信されることができる给
将来のトピック名の一致割り当てられたサブスクライバ。
[MQTT-3.3.1-6]
新しいサブスクリプション確立時に、各一致するトピック名。もし存在最近保持されたメッセージ，它必须
このサブスクライバーに送信される阅者。
[MQTT-3.3.1-7]
如果服务端收到一条保留（RETAIN）标志は 1 の QoS 0 消息，它必须丢弃之前
そのトピックのために保持されたの任意のメッセージ。它应该この新しいものを QoS 0 消メッセージをその～と見なすトピックの新しい保留
保留メッセージ、ただし何时候都可以选择丢弃它 — 如果この状況が発生し、その主题将没
有保留消息。
[MQTT-3.3.1-8]
服务端发送 PUBLISH 报文给客户端时，如果消息クライアントとして新しいサブスクリプションの結果
发送，它必须将报文の保持フラグが...に設定され 1。
[MQTT-3.3.1-9]
当一个 PUBLISH 报文发送给クライアントはあるものに一致するため確立されたサブスクリプション阅时，服务端必须
RETAINフラグを設定する 0，不管受信したこのメッセージに保持されているフラグの値は複数少。
MQTT-3.1.1-CN 66
[MQTT-3.3.1-10]
保持フラグが 1 かつペイロードがゼロバイトの PUBLISH 报文サーバー側で肯定として扱われ常消息处
処理され、送信される给订阅主题匹一致するクライアント。さらに、同一个主题下任何现保存された保持
メッセージは削除されなければならない、したがってこのトピックトピックの後の任意のサブスクライバー都不会收到一个保留消息。
[MQTT-3.3.1-11]
服务端不能存储零バイトの保留メッセージ。
[MQTT-3.3.1-12]
如果客户端发给サーバー側の PUBLISH 报文の保留标志位 0，服务端不能このメッセージを保存する
息也不能既存の予約語を削除または置換する消息。
[MQTT-3.3.2-1]
主题名必须である PUBLISH 报文可变报ヘッダの最初のフィールド。它必须である 1.5.3 节定意味の
UTF-8 エンコードされた文字列。
[MQTT-3.3.2-2]
PUBLISH 报文中のトピック名不能包含通配符。
[MQTT-3.3.2-3]
服务端发送给订購読クライアントの PUBLISH 报文のトピック名必须匹配その購読のトピック过滤器
（根据 4.7 節で定義されたマッチング过程）。
[MQTT-3.3.4-1]
PUBLISH 报パケットの受信者必须按照根据 PUBLISH パケット内の QoS 等级发送响应，见
表格 3.4 の説明。
[MQTT-3.3.5-1]
服务端必须将消息分发给所有订阅匹配の QoS 最も高いレベルのクライアント端。
[MQTT-3.3.5-2]
如果服务端实现不授权某个客户端发布 PUBLISH 报文，它没有方法でそれを通知客户
端。它必须通常どおりの QoS 规则肯定のな確認を送信する认，或者关闭网络连接。
[MQTT-3.6.1-1]
PUBREL 控制报文固定报ヘッダーの 3,2,1,0 位置は保留位，必须に設定される 0,0,1,0。服
务端必须その他の任意の値をすべて「不」として扱う有効であり、閉じる网络连接。
[MQTT-3.8.1-1]
SUBSCRIBE 控制报固固定ヘッダーの第 3,2,1,0 ビットは予約済みである位，必须それぞれ設定される 0,0,1,0。
服务端必须将其它の任意の値は...として扱われ不合法な関連闭网络连接。
[MQTT-3.8.3-1]
SUBSCRIBE 报文有效ペイロード内のトピックフィルター列表必须である 1.5.3 节定義された UTF-8 字
符串。
[MQTT-3.8.3-2]
如果服务端选择不支持包含通ワイルドカードのトピックフィルター、必须拒绝任何包含通配符过滤
器の購読要求。
[MQTT-3.8.3-3]
SUBSCRIBE 报文章には效载荷必须包含至少一トピックフィルターに対して と QoS 等级字段组
合。没有有效载荷の SUBSCRIBE 报文プロトコル違反である。
[MQTT-3-8.3-4]
如果有效载荷中の任意のビットは非零值，或者 QoS 不等于 0,1 或 2，服务端必须考える
SUBSCRIBE 报文は有効でネットワーク接続を閉じ接。
[MQTT-3.8.4-1]
服务端收到客户クライアントが送信する一つの SUBSCRIBE 报文时，必须使用 SUBACK 报文响
应。
[MQTT-3.8.4-2]
SUBACK 报文必须と確認応答を待つ SUBSCRIBE 报文同じパケットを持つ文标识符。
[MQTT-3.8.4-3]
如果服务端收到一个 SUBSCRIBE 报文，报文のトピックフィルターと既存のサブスクリプションのトピック
题过滤器相同，では必须新しいサブスクリプションを使用する阅彻底替换现既存のサブスクリプション。新しいサブスクリプションの主题过滤
サーバーと以前に購読した同じであるが、それはの最大 QoS 值可以不同。このトピックフィルターとフィルタに一致する
既存の保留メッセージ消息必须再送され、しかし发布流程不能中断。
[MQTT-3.8.4-4]
如果服务端收到包含多个主题フィルターの SUBSCRIBE 报文，它必须あたかも受信したかのように
一連の複数の SUBSCRIBE 报文同様にそれを処理、ただし、～する必要があるそれらの応答を一つに統合する个
単独の SUBACK 报文发送。
MQTT-3.1.1-CN 67
[MQTT-3.8.4-5]
服务端发送给客クライアントの SUBACK パケットペア各トピックフィルタのペア器 と QoS 等级都必须包
含一个返回码。このリターンコード必须そのサブスクリプションが付とされることを示すの最大 QoS 等级，或者表示
この購読は失敗。
[MQTT-3.8.4-6]
服务端可以授予比订阅者要求やや低い QoS レベル。購読に応答して購読によって送信されるメッセージ息の
ペイロードの QoS 必须である原始发布消息の QoS とサーバーが付とした QoS 两の中の最小
值。如果原始消息の QoS である 1 そして付とされるの最大 QoS である 0，允许服务端重复发送一
メッセージのコピーを订阅者。
[MQTT-3.9.3-1]
リターンコードの順序必须と SUBSCRIBE 报文中主题过滤器の順序は同じ。
[MQTT-3.9.3-2]
0x00, 0x01, 0x02, 0x80 之外部の SUBACK リターンコードは予約済みの、不能使用。
[MQTT-3.10.1-1]
UNSUBSCRIBE 报文固固定ヘッダーの第 3,2,1,0 ビットは予約留位且必须分别设置ために
0,0,1,0。服务端必须他のいずれかと見なす値はすべて無効し、ネットワークを閉じる连接。
[MQTT-3.10.3-1]
UNSUBSCRIBE 报文中のトピックフィルター必须連続してパックされている、按照 1.5.3 节定義された
UTF-8 编码字符串。
[MQTT-3.10.3-2]
UNSUBSCRIBE 报文の有效载荷必须至少包含一个消息过滤器。没有ペイロードの
UNSUBSCRIBE 报文章はプロトコルに違反する。
[MQTT-3.10.4-1]
UNSUBSCRIBE 报文提提供されたトピックフィルター（含むかどうかに関わらず通配符）必须サーバーとの保持
このクライアントが持つの現在のトピックフィルター滤器集合逐个字符比较。如果有任何过滤器完全匹
配，すると、それ（サーバー側）は自分のサブスクリプションが削除される，否则不会有さらなる処理。
[MQTT-3.10.4-2]
如果服务端删除購読を1つ、它必须停止分发任何新この〜にメッセージを客户端。
[MQTT-3.10.4-3]
如果服务端删除購読を1つ、它必须完成分发任何已经开始往客クライアントが送信した QoS
1 と QoS 2 のメッセージ。
[MQTT-3.10.4-4]
服务端必须发送 UNSUBACK 报文响应クライアントの UNSUBSCRIBE 请求。
UNSUBACK 报文必须含むと UNSUBSCRIBE 报文同じパケット标识符。
[MQTT-3.10.4-5]
即使没有删除任何主题订阅，服务端也必须发送一个 SUBACK 响应。
[MQTT-3.10.4-6]
如果服务端收到包含多个主题フィルターの UNSUBSCRIBE 报文，它必须受信したかのように
一連の複数の UNSUBSCRIBE 报文一样处そのパケットを処理し、それらの～を除いて响应合并到
単一の UNSUBACK 报文外。
[MQTT-3.12.4-1]
服务端必须发送 PINGRESP 报文响应クライアントの PINGREQ 报文。
[MQTT-3.14.1-1]
服务端必须验证所すべての予約ビットが...に設定されに設定する 0，如果それらは～ではない 0 必须断开连接。
[MQTT-3.14.4-1]
客户端发送 DISCONNECT 报文之后，必须关闭网络连接。
[MQTT-3.14.4-2]
客户端发送 DISCONNECT 报文之后，不能その～を通じて网络连接再发送任何控制报
文。
[MQTT-3.14.4-3]
服务端收到 DISCONNECT 报文时，必须任意の〜を破棄する現在の接続に関連する未公開された遺言
嘱消息，具体描述见 3.1.2.5 节。
[MQTT-4.1.0-1]
セッション全体にわたって、クライアントとサーバー务端都必须存储会话状态。
[MQTT-4.1.0-2]
会话必须少なくともそのアクティブなネットワーク接続と同程度に持続する同じ長さの時間接続する间。
MQTT-3.1.1-CN 68
[MQTT-4.3.1-1]
に対して QoS 0 の分发协议，发送者必须发送 QoS 等于 0，DUP 等于 0 の PUBLISH
报文。
[MQTT-4.3.2-1]
に対して QoS 1 の分发协议，发送者
毎回新しい応答を送信する用消息都必须分配一个未使用されるパケット識別子符。
MUST send a PUBLISH Packet containing this Packet Identifier with
QoS=1, DUP=0.
送信された PUBLISH 报文必须包含报文标识符且 QoS 等于 1，DUP 等于
0。
必须これを PUBLISH 报文と見なす
未確認の
，直到受信者から対応するものを受け取る
の PUBACK 报文。4.4 节有一个关于未确认メッセージの議論。
[MQTT-4.3.2-2]
に対して QoS 1 の分发协议，接收者
応答の PUBACK 报文必须包含一个报文标识符，この識別子を使って自接收到
の、すでに所有権を受け入れた PUBLISH 报文。
送信した PUBACK 报文之后，接收者必须将任何包含相同报文标識別子の受信
站 PUBLISH 报文当作一个新のメッセージ、そしてその...を無視する DUP 标志の値。
[MQTT-4.3.3-1]
に対して QoS 2 の分发协议，发送者
送信するものに必ずとえる新应用消息分未使用のパケットを割り当てます标识符。
MUST send a PUBLISH packet containing this Packet Identifier with
QoS=2, DUP=0.
送信された PUBLISH 报文必须包含报文标识符且报文の QoS 等于 2,，DUP
等于 0。
必须これを PUBLISH 报文と見なす
未確認の
，直到受信者から対応するものを受け取る
の PUBREC 报文。4.4 节有一个关于未确认メッセージの議論。
收到 PUBREC 报文后必须发送一个 PUBREL 报文。PUBREL 报文必须
元の〜を含む PUBLISH パケットと同じ報文标识符。
MUST treat the PUBREL packet as “unacknowledged” until it has
received the corresponding PUBCOMP packet from the receiver.
必须これを PUBREL 报文は～と見なされる
未確認の
，直到受信者から対応するものを受け取る
PUBCOMP 报文。
対応するものを送信したらの PUBREL 报文就不能これを再送する PUBLISH 报文。
[MQTT-4.3.3-2]
に対してQoS 2の配信プロトコル、受信者
応答の PUBREC 报文必须パケット識別子を含む、この識別子は受信した...に由来する、
已经所有権を受け入れる PUBLISH 报文。
対応する...を受信すると PUBREL 报文之前，接收者必须发送 PUBREC 报文确认任
後続の同じ同じ識別子の PUBLISH 报文。 この場合下，它不能重复
分发消息给任何後続の受信者。
响应 PUBREL メッセージの PUBCOMP 报文必须を含むと PUBREL 报メッセージと同じ
标识符。
发送 PUBCOMP 报文之后，接收者必须将包含相同じパケット識別子を持つ任意の后
续 PUBLISH 报文当作一个新の公開。
MQTT-3.1.1-CN 69
[MQTT-4.4.0-1]
客户端设置清理会话（CleanSession）标志は 0 重连时，客户端とサーバー必须使
元のパケット識別子を使用识符重发任何未確認の PUBLISH 报文（如果 QoS>0）と
PUBREL 报文。
[MQTT-4.5.0-1]
服务端接管入站アプリケーションメッセージの所有有权时，它必须将消息添加到订阅一致するクライアントの
会话状态中。匹配规则定义见 4.7 节。
[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]
服务端必须默认认各トピックには...がある順序の。それは可以提供一个管理功能或其它机
制，以允许将一个或多个主题として扱う順序のない。
[MQTT-4.6.0-6]
服务端处理发送順序付きトピックへの消息时，必须按照上面の規則は削除され息分发给每个订
阅者。此外，它必须クライアントから受信した内容に従って到着順に送信する PUBLISH 报文消費者（対象
同じトピックと QoS）。
[MQTT-4.7.1-1]
主题过滤器中可以使用通配符、ただしトピック名は不能使用通配符。
[MQTT-4.7.1-2]
多层通配符必须それ自身の位置にある階層、またはトピックレベルの後に続く级分隔符后面。不管哪种情
况，它都必须トピックフィルターの最後の文字である个字符。
[MQTT-4.7.1-3]
トピックフィルタの任意层级都可以使用单层通配符，包括第1つと最後の个层级。
然而它必须フィルターのレベル全体を占める。
[MQTT-4.7.2-1]
服务端不能将 $ 文字で始まるトピック名に一致配通配符 (#或+) 开先頭のトピックフィルター器。
[MQTT-4.7.3-1]
すべてのトピック名と主题过滤器必须至少包含一个字符。
[MQTT-4.7.3-2]
トピック名とトピックフィルタ滤器不能包含空字符 (Unicode U+0000) [Unicode] 。
[MQTT-4.7.3-3]
トピック名とトピックフィルタフィルターは UTF-8 编码字符串、それら不能超过 65535 字节。
[MQTT-4.7.3-4]
匹配订阅时，服务端不能トピック名または主题过滤器执行任何规范化
（normalization）处理，不能修改或替换任任意の未認識の文字符。
[MQTT-4.8.0-1]
除非另有说明，如果服务端或クライアントが遭遇したプロトコル違反の行為、它必须この伝送を閉じる
个协议违规控制パケットのネットワーク接続接。
[MQTT-4.8.0-2]
如果客户端或服务端处理入站制御パケット処理中に一時的な問題が発生しました时错误，它必须その送信を閉じる
制御メッセージのネットワーク连接。
[MQTT-6.0.0-1]
MQTT 控制报文必须使用 WebSocket 二进制数据帧发送。如果收到任何其它类型
のデータフレームを受信者必须关闭网络连接。
[MQTT-6.0.0-2]
单个 WebSocket 数据帧可以包含多个或者部分 MQTT 报文。接收者不能假设
MQTT 控制报文按 WebSocket フレーム境界のアライメント。
MQTT-3.1.1-CN 70
[MQTT-6.0.0-3]
客户端必须将字符串 mqtt それに含まれている提供された WebSocket 子协议列表里。
[MQTT-6.0.0-4]
サーバー側の選択と返却戻りの WebSocket 子协议名必须である mqtt
[MQTT-7.0.0-1]
MQTT 実装は同時に MQTT クライアントと MQTT 服务端。接受入サイト接続とその...への確立
そのサーバー側のアウトバウンド接続のサーバー必须同时符合 MQTT クライアントと MQTT サーバー側の要件
求。
[MQTT-7.0.0-2]
他のあらゆるものと一貫性のある実装交互操作，一致性实现不能この仕様で使用するための要求规范之外
定義された任意の拡張。
[MQTT-7.1.1-1]
满足一致性要求のサーバー必须支持使用一个或多个底层传输协议，只要它提供有
順序の、信頼できる信頼性のある双方向バイトストリーム（クライアントからサーバーへサーバー側とサーバーからクライアントへの户端）
[MQTT-7.1.2-1]
满足一致性要求のクライアント必须支持使用一个或多个底层传输协议，只要它提供有
順序の、信頼できる信頼性のある双方向バイトストリーム（クライアントからサーバーへサーバー側とサーバーからクライアントへの户端）