【正文】 每個(gè) MQTT 命令消息的消息頭部都包含一個(gè)固定頭部。 以下章節(jié)將詳細(xì)介紹這些字段。當(dāng)前協(xié)議版本中該字段的具體枚舉值如下表所示。這適用于消息的 QoS 標(biāo)志值大于 0 的情況，此時(shí)消息確認(rèn)是必需的。具體的 QoS 級(jí)別如下表所示。當(dāng)然，如果不存在保持消息，則什么也不用發(fā) 。這樣做可以使得區(qū)分它接 收到的 PUBLISH 消息是服務(wù)器之前保持的（ RETAIN 標(biāo)志置位）還是即時(shí)收到的（ RETAIN 標(biāo)志不置位）。 該字段本身的字節(jié)數(shù)是根據(jù)可變頭部和有效載荷的長度不同而變化的。 舉例如下，十進(jìn)制數(shù)字 64只需用 1個(gè)字節(jié)來編碼，即 0x40。 該編碼方案的算法如下所示，輸入為一個(gè)十進(jìn)制數(shù)（ X），輸出為編碼后的結(jié)果。 相應(yīng)地，剩余長度字段的解碼算法如下所示： multiplier = 1 value = 0 do digit = 39。 當(dāng)該解碼算法終止， value 等于剩余長度的字節(jié)數(shù)。 譯者注：可認(rèn)為剩余長度字段雖然是固定的，但該字段的長度卻是變化的（ 14 字節(jié)）。該值只包括可變頭部和有效載荷。該字段以 UTF 編碼方式顯示協(xié)議名稱： MQIsdp，大小寫如上所示。 連接標(biāo)志（ Connect flags） 該字段用于 CONNECT 消息的可變頭部中，占 1字節(jié)，包括 Clean session、 Will、 Will QoS和 Retain 標(biāo)志。同時(shí)，當(dāng)客戶端斷線時(shí)，服務(wù)器必須丟棄其所有狀態(tài)。而一個(gè) nonclean session 客戶端則不會(huì)漏接任何它在斷線時(shí)服務(wù)器發(fā)布的交付質(zhì)量級(jí)別為 QoS 1 和 QoS 2的消息。 服務(wù)器可以提供一種管理機(jī)制，當(dāng)確定一個(gè)客戶端將永遠(yuǎn)不會(huì)重新連接時(shí)，可以清除該客戶端的存儲(chǔ)信息。 如果 Will標(biāo)志被置位，則 Will QoS標(biāo)志和 Will Retain標(biāo)志的設(shè)置將會(huì)發(fā)生作用，同時(shí)，在有效載荷里必須填寫 Will 主題和 Will 消息內(nèi)容字段。 Will消息的內(nèi)容在客戶端發(fā)送的 CONNECT 消息里的有效載荷里填寫。 Will Retain 標(biāo)志 位置 ： bit 5 Will Retain 標(biāo)志指明服務(wù)器是否需要保持客戶端異常離線時(shí)發(fā)送給客戶端的 Will 消息。 User name and password 標(biāo)志 位置 ： bit 6 和 bit 7 客戶端在連接服務(wù)器時(shí)可以指定用戶名和密碼，通過將用戶名標(biāo)志和密碼標(biāo)志（可選）置位表明在 CONNECT 消息的有效載荷里包含有用戶名和密碼。 連接標(biāo)志中的第 0 位在目前協(xié)議版本中沒有使用到，保留為將來使用?？蛻舳擞辛x務(wù)在每個(gè)?；顣r(shí)間間隔內(nèi)至少發(fā)送一條消息給服務(wù)器。具體細(xì)節(jié)參見 DISCONNECT。如果設(shè)為 0，則表示客戶端不斷線。 這個(gè)字段用一個(gè)無符號(hào)字節(jié)來表示返回碼。 主題名決定消息要發(fā)送到哪個(gè)信息通道。主題名支持的最大字符度為 32767。 SUBSCRIBE 該有效載荷包含一系列要訂閱的主題名，以及每個(gè)主題的 QoS級(jí)別。授權(quán)的 QoS 級(jí)別順序與相應(yīng)訂閱的主題的順序保持一致。你不能在固定狀況或可變頭部里定義與特定應(yīng)用相關(guān)的標(biāo)志。 消息 ID 用 16 位無符號(hào)整數(shù)來表示，在同一個(gè)方向上的在傳消息 ID 必須是唯一的。 表示消息 ID 的 2 個(gè)字節(jié)的順序?yàn)橄? MSB， 再 LSB（大端模式）。 在 MQTT 中，字符串編碼的頭 2 個(gè)字節(jié)用來記錄字符串的長度，如下表所示。 未使用的位（ Unused bits） 任何標(biāo)明為未使用的位都應(yīng)當(dāng)置為 0。 剩余長度字段的值為可變頭部（ 12 字節(jié)）和有效載荷的字節(jié)數(shù)總和。 密碼標(biāo)志 置位（ 1）。這些字符串如果出現(xiàn)的話，必須符合以下順序： 客戶端 ID 這是第 1 個(gè) UTF 編碼字符串。 Will 主題 如果 Will 標(biāo)志被置位，則 Will 主題將是有效載荷中的下一個(gè)字符串。 Will 消息定義了客戶端異常離線時(shí)服務(wù)器發(fā)送給 Will主題的消息內(nèi)容。 用戶名 如果用戶名標(biāo)志被置位，則用戶名將是有效載荷中的下一個(gè)字符串。服務(wù)器的實(shí)現(xiàn)必須允許用戶名標(biāo)志被置位，但不存在用戶名字符 串的情況。建議密碼不超過 12 個(gè)字符，但不強(qiáng)制如此。 回復(fù)（ Response） 服務(wù)器收到客戶端發(fā)送的 CONNECT 消息后會(huì)回復(fù)一個(gè) CONNACK 消息。 以上兩種場景中，一段合理時(shí)間的設(shè)置依賴于特定應(yīng)用的需求和通信架構(gòu)。 CONNACK 連接確認(rèn) 當(dāng)客戶端向服務(wù)器發(fā)起 CONNECT 請(qǐng)求，服務(wù)器會(huì)回復(fù)其 CONNACK 消息。 其中，連接返回碼用 1 個(gè)無符合字節(jié)表示，具體含義如下表所示。每個(gè) PUBLISH 消息都關(guān)聯(lián)一個(gè)主題名（也可稱為話題或頻道）。 譯者注：其實(shí)流程簡單來說就是，發(fā)布者客戶端發(fā)送某 topic 的 PUBLISH 消息給服務(wù)器，然后服務(wù)器再發(fā) PUBLISH 消息給所有該 topic 的訂閱者客戶端。 DUP 標(biāo)志 設(shè)為 0。表示不保持。 可變頭部（ Variable header） 可變頭部包含以下字段： 主題名 一個(gè) UTF 編碼字符串。詳見 消息標(biāo)識(shí)符 。數(shù)據(jù)的內(nèi)容和格式由應(yīng)用決定。具體見下表。 QoS 1 將消息持久化存儲(chǔ)，將消息發(fā)送給所有相關(guān)的部分，回復(fù) PUBACK 消息給發(fā)送者。 更多信息請(qǐng)參見 交付質(zhì)量級(jí)別和消息流 。 PUBACK 發(fā)布確認(rèn) PUBACK 消息是對(duì) QoS級(jí)別 1的 PUBLISH 消息的回應(yīng)。 其中， QoS 級(jí)別 未使用。 可變頭部（ Variable header） 包含被確認(rèn)的 PUBLISH 消息的消息標(biāo)識(shí)符（消息 ID）。 PUBREC 發(fā)布接收（有保證的交付第 1 部分） PUBREC 消息是對(duì) QoS 級(jí)別 2 的 PUBLISH 消息的回應(yīng)。 其中， QoS 級(jí)別 未使用。 可變頭部（ Variable header） 包含被確認(rèn)的 PUBLISH 消息的消息標(biāo)識(shí)符（消息 ID）。 PUBREL 發(fā)布釋放（有保證的交付第 2 部分） PUBREL 消息可以是發(fā)布者客戶端對(duì)服務(wù)器發(fā)送給它的 PUBREC 消息的回應(yīng)，也可是服務(wù)器對(duì)訂閱者客戶端發(fā)送給它的 PUBREC 消息的回應(yīng)。 PUBREL 消息使用 QoS 級(jí)別 1，期望得到 PUBCOMP 消息回應(yīng)。詳見 DUP。格式如下表所示。 PUBCOMP 發(fā)布完成（有保證的交付第 3 部分） PUBCOMP 消息可以是服務(wù)器對(duì)發(fā)布者客戶端發(fā)送給它的 PUBREL 消息的回應(yīng)，也可以是訂閱者客戶端對(duì)服務(wù)器發(fā)送給它的 PUBREL 消息的回應(yīng)。 DUP 標(biāo)志 未使用。格式如下表所示。這些主題的發(fā)布消息都會(huì)通過 PUBLISH 消息從服務(wù)器發(fā)送給客戶端。相應(yīng)的 SUBACK 消息攜帶與之相同的消息 ID。詳見 DUP。 可變頭部（ Variable header） 因?yàn)? SUBSCRIBE 消息使用 QoS 級(jí)別 1，所以可變頭部里包含有一個(gè)消息 ID。字符串經(jīng)過 UTF 編碼，指定的 QoS 級(jí)別雖然只用 2bits表示，但仍要占用一個(gè)字節(jié)。 上個(gè)例子的具體格式如下表所示。 如果客戶端以 QoS 級(jí)別 2 來訂閱某主題，客戶端相當(dāng)于說： “我愿意以發(fā)布消 息時(shí)設(shè)置的QoS 級(jí)別來接收這個(gè)主題的消息。不過，訂閱者可以根據(jù)自己的需求來降格 QoS 級(jí)別。 如果最后 2 位都被置位（即值為 3），則應(yīng)當(dāng)將其視為非法包并關(guān)閉連接。因此，當(dāng)授權(quán)通過時(shí)，它必須發(fā)送 SUBACK 消息來進(jìn)行正面的回應(yīng)。例如，如果服務(wù)器不提供可靠的持久化存儲(chǔ)，它可以選擇 只能 QoS級(jí)別 0 來授權(quán)訂閱。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 剩余長度字段 長度包括可變頭部和有效載荷（原文： The length of the payload）。各個(gè) QoS級(jí)別對(duì)應(yīng) SUBSCRIBE 消息里的主題名。 當(dāng)前版 本協(xié)議中該字節(jié)的前 6 位未被使用，保留作將來使用。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 DUP 標(biāo)志 設(shè)為 0。 剩余長度字段 長度包括可變頭部和有效載荷（原文： This the length of the payload）。 下表是一個(gè)消息 ID 為 10 的可變頭部例子的格式。一個(gè)有效載荷的例子如下表所示。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 剩余長度字段 因?yàn)闆]有有效載荷，所有長度為可變頭部的長度（ 2 字節(jié)）。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 回復(fù)（ Response） PINGREQ 消息的期望回復(fù)是 PINGRESP 消息。 其中， DUP， QoS 以及 RETAIN 標(biāo)志未使用。這是為了干凈地?cái)嚅_連接，而不僅僅是斷開連線。 其中， DUP， QoS 以及 RETAIN 標(biāo)志未使用。所有級(jí)別描述如下所示： QoS 級(jí)別 0: 至多交付一次 消息依賴底層的 TCP/IP網(wǎng)絡(luò)做盡可能的發(fā)送。 QoS 級(jí)別 1：至少交付一次 服務(wù)器確認(rèn)收到 PUBLISH 消息后要回復(fù)客戶端一個(gè) PUBACK 消息。 QoS 級(jí)別 1 的消息頭部里都包含有一個(gè)消息 ID。 QoS 級(jí)別 2：正好交付一次 QoS 級(jí)別 2是在 QoS級(jí)別 1 上更進(jìn)一步的協(xié)議流，可以保證重復(fù)消息不會(huì)發(fā)送給接收端應(yīng)用。 QoS級(jí)別 2的協(xié)議流如下表所示。 如果檢測到故障，或 發(fā)生超時(shí)，協(xié)議流將重發(fā)最后一個(gè)未確認(rèn)的協(xié)議消息，包括 PUBLISH 或 PUBREL。發(fā)生故障時(shí)，鏈路的一端可能并不知道另一端發(fā)生了什么事，這被稱為懷疑窗口（ in doubt windows）。從設(shè)備中恢復(fù)數(shù)據(jù)的可能性是很低的。 消息重傳 盡管 TCP通?？梢员ＷC數(shù)據(jù)包的送達(dá)，然而 MQTT 消息沒有被收到的情況無疑是存在的。例如，通過一條擁擠的網(wǎng)絡(luò)發(fā)送一條大消息的時(shí)間通常要長于通過一條快速的網(wǎng)絡(luò)發(fā)送一條小消息的時(shí)間。 不同于上述 “重連 ”重傳行為，客戶端不需要重發(fā)消息。 對(duì)于一個(gè)提供有序消息保證的實(shí)現(xiàn)，它必須保證消息流的每個(gè)階段的完成順序都應(yīng)該與它們的啟動(dòng)順序 保持一致。 附錄 A 主題通配符（ Topic wildcards） 訂閱的主題可以包含特殊字符，從而可以使你一次訂閱多個(gè)主題。主題層次分隔符的引入為解決主題沖突有重要的意義。當(dāng)然，在這種情況下，多層次通配符的使用是沒有意義的，因?yàn)楦緵]有層次需要分隔。例如， finance/ 是合法的，而 finance//closingprice 是不合法的。 單層次通配符可以用于主題樹中的任意層次，而且可以與多層次通配符配合使用。例如， finance/+ 和 finance/+/ibm 都是合法的。 ? 主題名可以包含空格。 ? 不要在任何主題名中包含 ｀ null｀ 字符（ Unicode \x000