1 簡介
1.1 組織MQTT
本規範分爲七章：
·第6章-使用的WebSocket作爲網絡transport
1.2術語
本說明書中的關鍵詞“必須”，“必須”，“不需要”，“應該”，“不應該”，“應該”，“不應該”，“推薦”，“可以”和“可選”是按照IETF RFC 2119 [RFC2119]中的描述進行解釋。
網絡連接：
由MQTT使用的底層傳輸協議提供的構造。
·它將客戶端連接到服務器。
·它提供了在兩個方向上發送有序，無損，字節流的方法。
有關示例，請參見第4.2節。
應用程序消息：
MQTT協議通過網絡爲應用程序承載的數據。當應用程序消息由MQTT傳輸時，它們具有相關的服務質量和主題名稱。
客戶：
使用MQTT的程序或設備。客戶端始終建立與服務器的網絡連接。它可以
·發佈其他客戶可能感興趣的應用程序消息。
·訂閱請求有興趣接收的應用程序消息。
·取消訂閱以刪除對應用程序消息的請求。
·斷開與服務器的連接。
服務器：
充當發佈應用程序消息的客戶端和已進行訂閱的客戶端之間的中介的程序或設備。一臺服務器
·接受來自客戶端的網絡連接。
·接受客戶發佈的應用程序消息。
·處理訂閱和取消訂閱來自客戶的請求。
·轉發與客戶訂閱匹配的應用程序消息。
訂閱：
訂閱包括主題過濾器和最大QoS。訂閱與單個會話相關聯。會話可以包含多個訂閱。會話中的每個訂閱具有不同的主題過濾器。
主題名稱：
附加到應用程序消息的標籤，該標籤與服務器已知的訂閱進行匹配。服務器將應用程序消息的副本發送給具有匹配訂閱的每個客戶端。
主題過濾器：
訂閱中包含的表達式，用於表示對一個或多個主題的興趣。主題過濾器可以包含通配符。
會話：
客戶端和服務器之間的有狀態交互。某些會話僅與網絡連接一樣長，其他會話可以跨越客戶端和服務器之間的多個連續網絡連接。
MQTT控制數據包：
通過網絡連接發送的信息包。MQTT規範定義了十四種不同類型的控制包，其中一種（PUBLISH包）用於傳送應用程序消息。
1.3 規範性參考文獻
Bradner，S。，“用於RFC指示需求水平的關鍵詞”，BCP 14，RFC 2119，1997年3月 .http：//www.ietf.org/rfc/rfc2119.txt
Yergeau，F。，“UTF-8，ISO 10646的轉換格式”，STD 63，RFC 3629，2003年11月 http://www.ietf.org/rfc/rfc3629.txt
Dierks，T。和E. Rescorla，“傳輸層安全（TLS）協議版本1.2”，RFC 5246，2008年8月。
http://www.ietf.org/rfc/rfc5246.txt
Fette，I。和A. Melnikov，“WebSocket協議”，RFC 6455，2011年12月。
http://www.ietf.org/rfc/rfc6455.txt
[Unicode的]
Unicode聯盟。Unicode標準。
http://www.unicode.org/versions/latest/
1.4非規範性參考文獻
[RFC793]
Postel，J。傳輸控制協議。STD 7，IETF RFC 793，1981年9月。
http://www.ietf.org/rfc/rfc793.txt
高級加密標準（AES）（FIPS PUB 197）。
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[ DES ]
數據加密標準（DES）。
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
[ FIPS1402 ]
加密模塊的安全要求（FIPS PUB 140-2）
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[ IEEE 802.1AR ]
IEEE本地和城域網標準 - 安全設備標識
http://standards.ieee.org/findstds/standard/802.1AR-2009.html
[ ISO29192 ]
ISO / IEC 29192-1：2012信息技術 - 安全技術 - 輕量級加密 - 第1部分：總則
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425
[MQTT NIST]
MQTT補充出版物，MQTT和NIST框架，用於改進關鍵基礎設施網絡安全
http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html
[ MQTTV31 ]
MQTT V3.1協議規範。
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html
[ NISTCSF ]
改進關鍵基礎設施網絡安全執行命令13636
http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf
[ NIST7628 ]
NISTIR 7628智能電網網絡安全指南
http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf
[ NSAB ]
NSA Suite B密碼學
http://www.nsa.gov/ia/programs/suiteb_cryptography/
[ PCIDSS ]
PCI-DSS支付卡行業數據安全標準
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。，“輕量級目錄訪問協議（LDAP）：協議”，RFC 4511，2006年6月。
http://www.ietf.org/rfc/rfc4511.txt
[ RFC5077 ]
Salowey，J.，Zhou，H.，Eronen，P。和H. Tschofenig，“沒有服務器端狀態的傳輸層安全性（TLS）會話恢復”，RFC 5077，2008年1月。
http://www.ietf.org/rfc/rfc5077.txt
[ RFC5280 ]
Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R。和W. Polk，“Internet X.509公鑰基礎結構證書和證書撤銷列表（CRL）配置文件”，RFC 5280，2008年5月。
http://www.ietf.org/rfc/rfc5280.txt
[ RFC6066 ]
Eastlake 3rd，D.，“Transport Layer Security（TLS）Extensions：Extension Definitions”，RFC 6066，2011年1月。
http://www.ietf.org/rfc/rfc6066.txt
[ RFC6749 ]
Hardt，D.，Ed。，“OAuth 2.0 Authorization Framework”，RFC 6749，2012年10月。
http://www.ietf.org/rfc/rfc6749.txt
[ RFC6960 ]
Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S。和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 ]
2002年薩班斯 - 奧克斯利法案。
http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm
[ USEUSAFEHARB ]
美國 - 歐盟安全港
http://export.gov/safeharbor/eu/eg_main_018365.asp
1.5數據表示
1.5.1比特
一個字節中的位標記爲7到0.位號7是最高位，最低有效位分配位號0。
1.5.2整數數據值
整數數據值以大端順序爲16位：高位字節位於低位字節之前。這意味着在網絡上將16位字顯示爲最高有效字節（MSB），然後是最低有效字節（LSB）。
1.5.3 UTF-8編碼的字符串
稍後描述的控制包中的文本字段被編碼爲UTF-8字符串。UTF-8 [ RFC3629 ] 是Unicode [ Unicode ] 字符的有效編碼，可優化ASCII字符的編碼以支持基於文本的通信。
這些字符串中的每一個都以一個兩字節長度字段爲前綴，該字段給出了UTF-8編碼字符串本身的字節數，如圖1.1所示的UTF-8編碼字符串的結構。因此，可以在這些UTF-8編碼的字符串組件之一中傳遞的字符串大小有限制; 您不能使用編碼超過65535字節的字符串。
除非另有說明，否則所有UTF-8編碼的字符串可以具有0到65535字節範圍內的任何長度。
|
位 |
7 |
6 |
五 |
4 |
3 |
2 |
1 |
0 |
|
字節1 |
字符串長度MSB |
|||||||
|
字節2 |
字符串長度LSB |
|||||||
|
字節3 .... |
UTF-8編碼字符數據，如果長度> 0。 |
|||||||
UTF-8編碼字符串中的字符數據必須是由Unicode規範[ Unicode ] 定義的格式良好的UTF-8，並在RFC 3629 [ RFC3629 ]中重述。特別是該數據不得包括U + D800和U + DFFF之間的代碼點編碼。如果服務器或客戶端收到包含 格式錯誤的UTF-8的控制數據包，則必須關閉網絡連接[MQTT-1.5.3-1]。
UTF-8編碼的字符串不得包含空字符U + 0000的編碼。如果接收方（服務器或客戶端）收到包含U + 0000的控制包，則必須關閉網絡連接 [MQTT-1.5.3-2] 。
數據不應包括下面列出的Unicode [ Unicode ]代碼點的編碼。如果接收方（服務器或客戶端）收到包含其中任何一個的控制數據包，它可以關閉網絡連接：
U + 0001..U + 001F控制字符
U + 007F..U + 009F控制字符
Unicode規範中定義的代碼點[ Unicode ] 爲非字符（例如U + 0FFFF）
UTF-8編碼序列0xEF 0xBB 0xBF總是被解釋爲U + FEFF（“ZERO WIDTH NO-BREAK SPACE”），無論它出現在字符串中並且不得被包接收器 [MQTT-1.5.3-3] 跳過或剝離。
例如，字符串A ? 是LATIN CAPITAL字母A，後跟代碼點U + 2A6D4（代表CJK IDEOGRAPH EXTENSION B字符）編碼如下：
|
位 |
7 |
6 |
五 |
4 |
3 |
2 |
1 |
0 |
|
字節1 |
字符串長度MSB（0x00） |
|||||||
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
字節2 |
字符串長度LSB（0x05） |
|||||||
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
|
字節3 |
'A'（0x41） |
|||||||
|
|
0 |
1 |
0 |
0 |
0 |
0 |
0 |
1 |
|
字節4 |
（0XF0） |
|||||||
|
|
1 |
1 |
1 |
1 |
0 |
0 |
0 |
0 |
|
字節5 |
（和0xAA） |
|||||||
|
|
1 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
|
字節6 |
（0x9B） |
|||||||
|
|
1 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
字節7 |
（0x94之間） |
|||||||
|
|
1 |
0 |
0 |
1 |
0 |
1 |
0 |
0 |
1.6編輯約定
本規範中以黃色突出顯示的文本標識了一致性聲明。已爲每個一致性語句分配了[MQTT-xxx-y]格式的引用。
本文是翻譯的mqtt協議原文，爲了以後自己閱讀方便，也方便大家！