【導(dǎo)讀】消息傳輸協(xié)議，它的設(shè)計(jì)目標(biāo)是開(kāi)放、簡(jiǎn)單、輕量和易于實(shí)現(xiàn)。這些特征使它適用于各種受。網(wǎng)絡(luò)代價(jià)昂貴，低帶寬或不可靠。在嵌入設(shè)備中運(yùn)行，處理器和內(nèi)存資源有限。使用發(fā)布/訂閱消息模式，提供一對(duì)多的消息分發(fā)，解除應(yīng)用程序耦合。消息傳輸對(duì)有效載荷內(nèi)容不可知。有3個(gè)消息發(fā)布服務(wù)質(zhì)量級(jí)別：?！爸炼嘁淮巍?，消息發(fā)布完全依賴于底層TCP/IP網(wǎng)絡(luò)?！爸辽僖淮巍?，確保消息到達(dá)，但消息重復(fù)有可能發(fā)生。這一級(jí)別可用于如計(jì)費(fèi)系統(tǒng)等場(chǎng)景，在。計(jì)費(fèi)系統(tǒng)中，消息丟失或重復(fù)可能會(huì)導(dǎo)致生成錯(cuò)誤的費(fèi)用。提供一種機(jī)制，當(dāng)客戶端異常中斷時(shí)，利用LastWill和Testament特性來(lái)通知有關(guān)各。為解決一些安全問(wèn)題，在CONNACK數(shù)據(jù)包中添加了新的返回碼。當(dāng)客戶端發(fā)送未授權(quán)的PUBLISH或SUBSCRIBE命令時(shí)，客戶端不會(huì)收到相應(yīng)的通。MQTT中的字符串現(xiàn)在支持完整的UTF-8字符集，而不僅僅是US-ASCII子集。中，通過(guò)CONNECT包傳送的協(xié)議版本號(hào)仍然是“3”，與V3相比沒(méi)有變化。相應(yīng)地忽略多余的安全信息來(lái)接受來(lái)自協(xié)議的客戶端的連接。

　　

【正文】 UNSUBACK 取消訂閱確認(rèn) 服務(wù)器通過(guò)發(fā)送 UNSUBACK 消息來(lái)確認(rèn)其已收到 UNSUBSCRIBE 消息。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 其中， QoS 級(jí)別 未使用。 DUP 標(biāo)志 未使用。 RETAIN 標(biāo)志 未使用。 剩余長(zhǎng)度字段 因?yàn)闆](méi)有有效載荷，所有長(zhǎng)度為可變頭部的長(zhǎng)度（ 2 字節(jié)）。 可變頭部（ Variable header） 可變頭部包含要確認(rèn)的 UNSUBSCRIBE 消息的消息 ID，它的格式如下表所示。 有效載荷（ Payload） 沒(méi)有有效載荷。 PINGREQ PING 請(qǐng)求 PINGREQ 消息從連接中的客戶端發(fā)送給服務(wù)器，表示詢問(wèn)服務(wù)器： “你還活著嗎 ”？ 更多信息參見(jiàn) ?；钣?jì)時(shí)器 。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 其中， DUP， QoS 以及 RETAIN 標(biāo)志未使用。 可變頭部（ Variable header） 沒(méi)有可變頭部。 有效載荷（ Payload） 沒(méi)有有效載荷。 回復(fù)（ Response） PINGREQ 消息的期望回復(fù)是 PINGRESP 消息。 PINGRESP PING 回復(fù) PINGRESP 消息是服務(wù)器對(duì)客戶端發(fā)送給它的 PINGREQ 消息的回應(yīng)，表示回答客戶端：“對(duì)，哥還活著 ”。 更多信息參見(jiàn) ?；钣?jì)時(shí)器 。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 其中， DUP， QoS 以及 RETAIN 標(biāo)志未使用。 可變頭部（ Variable header） 沒(méi)有可變頭部。 有效載荷（ Payload） 沒(méi)有有效載荷。 DISCONNECT 斷開(kāi)連接通知 當(dāng)客戶端想要斷開(kāi)它的 TCP/IP 連接時(shí)，通過(guò)向服務(wù)器發(fā)送 DISCONNECT 消息告知服務(wù)器。這是為了干凈地?cái)嚅_(kāi)連接，而不僅僅是斷開(kāi)連線。 如果客戶端在連接時(shí)將 clean session標(biāo)志置位，則之前保持的客戶端的信息將會(huì)被丟棄。 服務(wù)器不應(yīng)該僅僅依賴客戶端發(fā)送的 DISCONNECT 消息來(lái)關(guān)閉 TCP/IP 連接。 固定頭部（ Fixed header） 固定頭部的格式如下表所示。 其中， DUP， QoS 以及 RETAIN 標(biāo)志未使用。 可變頭部（ Variable header） 沒(méi)有可變頭部。 有效載荷（ Payload） 沒(méi)有有效載荷。 4. 消息流（ Flows） 交付質(zhì)量級(jí)別和消息流（ Quality of Service levels and flows） MQTT 根據(jù)交付質(zhì)量級(jí)別（ QoS）來(lái)發(fā)送消息。所有級(jí)別描述如下所示： QoS 級(jí)別 0: 至多交付一次 消息依賴底層的 TCP/IP網(wǎng)絡(luò)做盡可能的發(fā)送。不要求響應(yīng)且協(xié)議中也沒(méi)有定義重傳的語(yǔ)義。該消息要么只到達(dá)服務(wù)器 1 次，要么干脆一次也沒(méi)有。 QoS 級(jí)別 0 的協(xié)議流如下表所示。 QoS 級(jí)別 1：至少交付一次 服務(wù)器確認(rèn)收到 PUBLISH 消息后要回復(fù)客戶端一個(gè) PUBACK 消息。不管是通信鏈路還是發(fā)送設(shè)備出現(xiàn)了故障，或是確認(rèn)消息沒(méi)有在規(guī)定時(shí)間內(nèi)收到，則發(fā)送者（即之前發(fā)送 PUBLISH 消息的客戶端）需要重發(fā) PUBLISH 消息，且該消息頭部中的 DUP標(biāo)志要置位。該消息將至少到達(dá)服務(wù)器一次。 SUBSCRIBE 和 UNSUBSCRIBE 消息都需要使用 QoS 級(jí)別 1。 QoS 級(jí)別 1 的消息頭部里都包含有一個(gè)消息 ID。 QoS 級(jí)別 1 的協(xié)議流如下表所示。 如果客戶端沒(méi)有收到 PUBACK 消息（不管是超過(guò)應(yīng)用設(shè)定的時(shí)間還是檢測(cè)到故障然后通信會(huì)話重起），客戶端將重發(fā) DUP 標(biāo)志被置位的 PUBLISH 消息。 當(dāng)服務(wù)器接收到一條客戶端發(fā)來(lái)的重復(fù)消息，服務(wù)器仍然會(huì)將該重復(fù)消息發(fā)送給訂閱者，然后再發(fā)送一條 PUBACK 消息給客戶端。 QoS 級(jí)別 2：正好交付一次 QoS 級(jí)別 2是在 QoS級(jí)別 1 上更進(jìn)一步的協(xié)議流，可以保證重復(fù)消息不會(huì)發(fā)送給接收端應(yīng)用。這是最高級(jí)別的交付質(zhì)量，用在重復(fù)消息不可接受的情況下。雖然使用該級(jí)別將帶來(lái)網(wǎng)絡(luò)流量的增長(zhǎng)，但對(duì)于一些重要的消息內(nèi)容這通常是可以接受的。 QoS 級(jí)別 2 的消息頭部里都包含有一個(gè)消息 ID。 QoS級(jí)別 2的協(xié)議流如下表所示。對(duì)于接收方有 2種方式（語(yǔ)義）用來(lái)處理該 PUBLISH 流。這 2 種不同語(yǔ)義影響的是協(xié)議流中訂閱者可以接收消息的時(shí)間點(diǎn)。這 2 種語(yǔ)義都可以保證QoS 級(jí)別 2 的協(xié)議流，如何選擇取決于具體的實(shí)現(xiàn)。 如果檢測(cè)到故障，或 發(fā)生超時(shí)，協(xié)議流將重發(fā)最后一個(gè)未確認(rèn)的協(xié)議消息，包括 PUBLISH 或 PUBREL。具體細(xì)節(jié)見(jiàn) 消息重傳 。該級(jí)別中附加的協(xié)議流可以保證消息只交付給訂閱者一次。 QoS 級(jí)別 1 和 2 的假設(shè) 在任何網(wǎng)絡(luò)中，設(shè)備或通信鏈路都有可能發(fā)生故障。發(fā)生故障時(shí)，鏈路的一端可能并不知道另一端發(fā)生了什么事，這被稱為懷疑窗口（ in doubt windows）。在這種背景下，對(duì)于消息發(fā)送，必須對(duì)設(shè) 備和網(wǎng)絡(luò)的可靠性作一個(gè)假設(shè)。 MQTT 假設(shè)客戶端和服務(wù)器在一般情況下是可靠的，而通信通道更可能是不可靠的。如果客戶端發(fā)生故障，則通常是災(zāi)難性的故障，而不大可能是暫時(shí)性的。從設(shè)備中恢復(fù)數(shù)據(jù)的可能性是很低的。有些設(shè)備具有非易失性存儲(chǔ)，比如閃存 ROM。為了應(yīng)對(duì)各種可能的故障，需要提供更多的持久化存儲(chǔ)來(lái)保護(hù)最重要的數(shù)據(jù)。 除了最基本的通信鏈路的故障，更多超出 MQTT 處理能力的場(chǎng)景將使得故障模式矩陣顯得更加復(fù)雜。 消息重傳 盡管 TCP通?？梢员ＷC數(shù)據(jù)包的送達(dá)，然而 MQTT 消息沒(méi)有被收到的情況無(wú)疑是存在的。對(duì)于需要收到回應(yīng)的 MQTT 消息（ QoS0， PUBLISH、 PUBREL、 SUBSCRIBE、UNSUBSCRIBE），如果在規(guī)定時(shí)間內(nèi)消息響應(yīng)沒(méi)收到，發(fā)送方將重發(fā)該消息，且該消息的 DUP 標(biāo)志將被置位。 重發(fā)超時(shí)應(yīng)當(dāng)是可配置的。超時(shí)的設(shè)置最好可以保證消息的正常傳輸不會(huì)引發(fā)超時(shí)。例如，通過(guò)一條擁擠的網(wǎng)絡(luò)發(fā)送一條大消息的時(shí)間通常要長(zhǎng)于通過(guò)一條快速的網(wǎng)絡(luò)發(fā)送一條小消息的時(shí)間。一直重復(fù)地重傳一條超時(shí)的消息將使情況變得更糟糕。因此，隨著重傳次數(shù)增加而增大超時(shí)的策略通常會(huì)被采用。 當(dāng)一 個(gè)客戶端重新連接時(shí)，如果 Clean session 標(biāo)志沒(méi)有被置位，則客戶端和服務(wù)器雙方都應(yīng)當(dāng)重發(fā)斷線前正在傳輸中的消息。 不同于上述 “重連 ”重傳行為，客戶端不需要重發(fā)消息。然而， Brokers 需要重發(fā)所有未確認(rèn)的消息。 消息排序 消息的順序會(huì)被一系列因素所影響，包括客戶端允許同時(shí)在傳的 PUBLISH 流的數(shù)量和客戶端是單線程還是多線程的。為了討論的簡(jiǎn)單，我們假設(shè)客戶端在對(duì)網(wǎng)絡(luò)中的數(shù)據(jù)包進(jìn)行讀寫時(shí)是單線程的。 對(duì)于一個(gè)提供有序消息保證的實(shí)現(xiàn)，它必須保證消息流的每個(gè)階段的完成順序都應(yīng)該與它們的啟動(dòng)順序 保持一致。例如，對(duì)于一系列 QoS級(jí)別 2 的消息流，它們發(fā)送 PUBREL 消息的順序與它們發(fā)送 PUBISH 消息的順序保持一致： 客戶端允許同時(shí)在傳的消息數(shù)量（稱為在傳窗口）對(duì)保證交付的類型也有一定的影響： ? 對(duì)于在傳窗口為 1的情況，每個(gè)消息流的開(kāi)始都在上個(gè)消息流完成之后。這保證了消息的傳送順序與提交它們的順序保持一致。 ? 當(dāng)在傳窗口大于 1 時(shí)，消息的有序化只能通過(guò) QoS 級(jí)別來(lái)保證。 附錄 A 主題通配符（ Topic wildcards） 訂閱的主題可以包含特殊字符，從而可以使你一次訂閱多個(gè)主題。 主題層次分隔符是用來(lái)引入主題的結(jié)構(gòu)，因而可以用來(lái)區(qū)分主題內(nèi)的不同目的。多層次通配符和單層次通配符可以用于訂閱，但它們不能用于在一個(gè)主題內(nèi)發(fā)布消息。 主題層次分隔符（ Topic level separator） 斜線（ /）是用來(lái)分隔一棵主題樹里的各個(gè)層次，它提供了一個(gè)層次結(jié)構(gòu)的主題空間。主題層次分隔符的引入為解決主題沖突有重要的意義。 多層次通配符 數(shù)字符號(hào)（ ）即多層次通配符，用來(lái)匹配一個(gè)主題內(nèi)的任意層次。例如，如果你想要訂閱了 finance/stock/ibm/，則你可以收到如下主題的消息： finance/stock/ibm finance/stock/ibm/closingprice finance/stock/ibm/currentprice 多層次通配符可以表示 0 個(gè)或任意多個(gè)層次。因而， finance/ 也可以匹配單單 finance 主題，這時(shí)， 代表 0 層次。當(dāng)然，在這種情況下，多層次通配符的使用是沒(méi)有意義的，因?yàn)楦緵](méi)有層次需要分隔。 多層次通配符只有 2 種用法，一是只有它自己本身，二是放在主題層次分隔符之后。因此， 和 finance/ 都是合法的，而 finance則是不合法的。多層次通配符在主題樹使用時(shí)必須作為最后一個(gè)字符。例如， finance/ 是合法的，而 finance//closingprice 是不合法的。 單層次通配符 加號(hào)（ +）是用來(lái)匹配一個(gè)主題層次的通配符。例如， finance/stock/+ 可以匹配 finance/stock/ibm 和 finance/stock/xyz ，但不能匹配 finance/stock/ibm/closingprice。同時(shí)，因?yàn)閱螌哟瓮ㄅ浞仨毱ヅ湟粋€(gè)層次，所以 finance/+ 不能匹配 finance 。 單層次通配符可以用于主題樹中的任意層次，而且可以與多層次通配符配合使用。與多層次通配符的用法一樣，單層次通配符要么只有它自己，要么要放在主題層次分隔符之后。因而， + 和 finance/+ 都是合法的，而 finance+ 是不合法的。單層次分隔符即可以放在主題樹的最后，也可以放在主題樹的中間。例如， finance/+ 和 finance/+/ibm 都是合法的。 主題語(yǔ)義和慣用法（ Topic semantics and usage） 當(dāng)你在構(gòu)建一個(gè)應(yīng)用時(shí)，主題樹的設(shè)計(jì)可以參考以下關(guān)于主題名語(yǔ)法和語(yǔ)義的設(shè)計(jì)原則： ? 一個(gè)主題名必須不小于 1 個(gè)字符。 ? 主題名是大小寫敏感的。例如， ACCOUNTS 和 Accounts 是兩個(gè)不同的主題。 ? 主題名可以包含空格。例如， Accounts payable 應(yīng)當(dāng)是一個(gè)合法的主題名。 ? 以 “/”開(kāi)頭的主題名和不以 “/”開(kāi)頭的相同主題名是有區(qū)別的。例如， /finance 和 finance 是不同的， /finance 匹配于 +/+ 和 /+ ， 但不匹配于 + 。 ? 不要在任何主題名中包含 ｀ null｀ 字符（ Unicode \x0000）。 以下原則適用于主題樹的構(gòu)建和內(nèi)容： ? 長(zhǎng)度被限制為 64K，但主題樹中的層次數(shù)量沒(méi)有限制。 ? 可以有任意數(shù)量的根節(jié)點(diǎn)，也就是說(shuō)，允許有任意數(shù)量的主題樹。