# 1.1 MQTT结构
整个规范由如下7个章节构成
* 1 介绍
* 2 MQTT控制包格式
* 3 MQTT控制包
* 4 操作行为
* 5 安全
* 6 使用WebSocket作为网络传输
* 7 一致性
# 1.2 术语
关键字 “必须MUST”、“不应该MUST NO”,“要求REQUIRED”, “应当SHALL”、“不得SHALL NO”、“应该SHOULD”、“应该 不SHOULD NOT”、“建议RECOMMENDED”、“可能MAY”和“可选的OPTIONAL” 在本规范中描述将根据IETF RFC 2119(RFC2119)的定义来解释。
#### 网络连接:
一个由底层传输协议构筑的、被MQTT使用的传输。
* 它连接客户端和服务器。
* 它能提供一个在两个方向上发送有序、无损的字节流的方式。
实例请参见4.2节。
#### 应用程序消息:
应用所需要的由MQTT协议所携带的在网络上传输的数据。当应用消息通过MQTT传输时，它们和服务质量和主题名称相关。
#### 客户机Client:
使用MQTT的程序或设备。客户总是建立网络连接到服务器。 它可以：
* 发布 其他客户可能感兴趣的应用消息。
* 订阅 感兴趣的应用消息。
* 退订 应用消息。
* 断开连接。
#### 服务器Server:
程序或设备,充当那些发布和订阅应用消息的客户之间的中介。 一个服务器：
* 接受 来自客户机的网络连接。
* 接受 客户发布的应用消息。
* 处理 来自客户的订阅和退订请求。
* 转发 应用消息给到正确的订阅者。
#### 订阅Subscription:
订阅包含一个主题过滤器和最大的QoS。一个订阅与单个会话相关联。但是一个会话可以包含多个订阅。会话中的每个订阅都有不同的主题过滤器。
#### 主题名称Topic Name:
附加到应用消息的标签，能匹配被服务器知道的订阅。服务器会给每个匹配的订阅客户机发送一个应用消息的副本。
#### 主题过滤器Topic Filter:
一个订阅中包含的表达式，表明一个或多个感兴趣的主题。一个主题过滤器可以包含通配符。
#### 会话Session:
一个有状态的客户端和服务器之间的交互。一些会话只在一次网络连接存在的情况下存在；也有会话可以跨越多个连续的网络连接。
#### MQTT控制包:
通过网络连接发送的信息包。 MQTT规范定义了14个不同类型的控制包,其中一个(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/
# 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/
[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
# 1.5 数据表示
### 1.5.1 位Bit
把一个字节Byte的8位标记为Bit7到Bit0，其中Bit7是最高位（MSB），Bit0是最低位（LSB）
### 1.5.2 整数数据值
整数值是16位的，遵循高/大字节序（Big-Endian，高位在内存地址低位，而低位在内存地址高位，和TCP/IP的网络序一致），这相当于一个16位的数字在网络上的表示形式是一个MSB跟着一个LSB。
### 1.5.3 UTF-8编码的字符串
在下面章节会描述的控制包中的文本字段使用UTF-8编码字符串。UTF-8[RFC3629]是一个高效的、为支持基于文本通讯而对ASCII编码优化的Unicode编码。
每一个这样的字符串都会有两个字节长度的前缀字段,这两个字节的前缀字段会给出这个字符串UTF-8编码的字节长度， 见图1.1 UTF-8编码字符串的结构。 因此，一个UTF-8编码的字符串组件事实上是有长度限制的，最长不能超过65535字节。
除非另有声明所有UTF-8编码的字符串的长度范围在0到65535字节之间。
图1.1 UTF-8编码的字符串的结构
**这里的UTF-8编码格式的字符数据必须是定义完备的UTF-8编码，由Unicode规范[Unicode]定义并在RFC3629[RFC3629]中重申。特别需要指出的是此数据不得包含任何在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
**一个UTF-8编码的字符流0xEF 0xBB 0xBF总是被解释为U+FEFF（零宽度非中断），只要它出现在字符串中，就不能被包接收者跳过或者剥离。[MQTT-1.5.3-3]**
#### 1.5.3.1 非规范性案例
比如，拉丁（LATIN）大写字符A及其后面的U+2A6D4（代表CJK IDEOGRAPH EXTENSION-CJK象形文字扩展B字符）可以被编码成如下格式：
图1.2 UTF-8编码的字符串非规范性的例子
# 1.6 编辑约定
黑体是一致性描述。每个一致性描述都被分配[MQTT-x.x.x-y]这样一个参考格式。
