MQTT3.1.1 使用規範和注意事項
阿新 • • 發佈：2018-12-18
如下是轉載mcxiaoke翻譯的MQTT規範中的比較重要的概括性規範，非常感謝mcxiaoke翻譯並開源給大家使用，原文地址點選這裡獲取。如有侵權，聯絡作者刪除。
表格：MQTT3.1.1 強制性規範宣告
| 宣告序號 | 規範宣告 |
|---|---|
| [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）控制報文必須 |
| [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報文。服務端必須將客戶端傳送的第二個CONNECT報文當作協議違規處理並斷開客戶端的連線。 |
| [MQTT-3.1.2-1] | 如果協議名不正確服務端可以斷開客戶端的連線，也可以按照某些其它規範繼續處理CONNECT報文。對於後一種情況，按照本規範，服務端不能繼續處理CONNECT報文。 |
| [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.2-22] | 如果使用者名稱標誌被設定為0，密碼標誌也必須設定為0。 |
| [MQTT-3.1.2-23] | 客戶端負責保證控制報文傳送的時間間隔不超過保持連線的值。如果沒有任何其它的控制報文可以傳送，客戶端必須傳送一個PINGREQ報文。 |
| [MQTT-3.1.2-24] | 如果保持連線的值非零，並且服務端在一點五倍的保持連線時間內沒有收到客戶端的控制報文，它必須斷開客戶端的網路連線，認為網路連線已斷開。 |
| [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編碼的客戶端識別符號，客戶端識別符號只能包含這些字元：“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”（大寫字母，小寫字母和數字）。 |
| [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.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報文傳送給客戶端是因為匹配一個已建立的訂閱時，服務端必須將保留標誌設為0，不管它收到的這個訊息中保留標誌的值是多少。 |
| [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.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] | 如果服務端刪除了一個訂閱，它必須停止分發任何新訊息給這個客戶端。 |
| [MQTT-3.10.4-3] | 如果服務端刪除了一個訂閱，它必須完成分發任何已經開始往客戶端傳送的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-4.3.1-1] | 對於QoS 0的分發協議，傳送者必須傳送QoS等於0，DUP等於0的PUBLISH報文。 |
| [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] | 在主題過濾器的任意層級都可以使用單層萬用字元，包括第一個和最後一個層級。然而它必須佔據過濾器的整個層級。 |
| [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-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] | 滿足一致性要求的客戶端必須支援使用一個或多個底層傳輸協議，只要它提供有序的、可靠的、雙向位元組流（從客戶端到服務端和從服務端到客戶端） |
關於QoS的補充說明
[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報文相同的報文識別符號。
- 必須將這個PUBREL報文看作是 未確認的 ，直到從接收者那收到對應的PUBCOMP報文。
- 一旦傳送了對應的PUBREL報文就不能重發這個PUBLISH報文。
[MQTT-4.3.3-2] 對於QoS 2的分發協議，接收者
- 響應的PUBREC報文必須包含報文識別符號，這個識別符號來自接收到的、已經接受所有權的PUBLISH報文。
- 在收到對應的PUBREL報文之前，接收者必須傳送PUBREC報文確認任何後續的具有相同識別符號的PUBLISH報文。 在這種情況下，它不能重複分發訊息給任何後續的接收者。
- 響應PUBREL報文的PUBCOMP報文必須包含與PUBREL報文相同的識別符號。
- 傳送PUBCOMP報文之後，接收者必須將包含相同報文識別符號的任何後續PUBLISH報文當作一個新的釋出。