一、簡述

MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸協(xié)議），是一種基于發(fā)布/訂閱（publish/subscribe）模式的'輕量級'通訊協(xié)議，該協(xié)議構(gòu)建于TCP/IP協(xié)議上，由IBM在1999年發(fā)布。MQTT最大優(yōu)點(diǎn)在于，可以以極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。作為一種低開銷、低帶寬占用的即時(shí)通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動應(yīng)用等方面有較廣泛的應(yīng)用。

MQTT是一個(gè)基于客戶端-服務(wù)器的消息發(fā)布/訂閱傳輸協(xié)議。MQTT協(xié)議是輕量、簡單、開放和易于實(shí)現(xiàn)的，這些特點(diǎn)使它適用范圍非常廣泛。在很多情況下，包括受限的環(huán)境中，如：機(jī)器與機(jī)器（M2M）通信和物聯(lián)網(wǎng)（IoT）。其在，通過衛(wèi)星鏈路通信傳感器、偶爾撥號的醫(yī)療設(shè)備、智能家居、及一些小型化設(shè)備中已廣泛使用。

二、設(shè)計(jì)規(guī)范

由于物聯(lián)網(wǎng)的環(huán)境是非常特別的，所以MQTT遵循以下設(shè)計(jì)原則：

• （1）精簡，不添加可有可無的功能；
• （2）發(fā)布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞；
• （3）允許用戶動態(tài)創(chuàng)建主題，零運(yùn)維成本；
• （4）把傳輸量降到最低以提高傳輸效率；
• （5）把低帶寬、高延遲、不穩(wěn)定的網(wǎng)絡(luò)等因素考慮在內(nèi)；
• （6）支持連續(xù)的會話控制；
• （7）理解客戶端計(jì)算能力可能很低；
• （8）提供服務(wù)質(zhì)量管理；
• （9）假設(shè)數(shù)據(jù)不可知，不強(qiáng)求傳輸數(shù)據(jù)的類型與格式，保持靈活性。

三、主要特性

MQTT協(xié)議工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備通訊而設(shè)計(jì)的協(xié)議，它具有以下主要的幾項(xiàng)特性：

• （1）使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應(yīng)用程序耦合。

  這一點(diǎn)很類似于XMPP，但是MQTT的信息冗余遠(yuǎn)小于XMPP，,因?yàn)閄MPP使用XML格式文本來傳遞數(shù)據(jù)。

• （2）對負(fù)載內(nèi)容屏蔽的消息傳輸。

• （3）使用TCP/IP提供網(wǎng)絡(luò)連接。

  主流的MQTT是基于TCP連接進(jìn)行數(shù)據(jù)推送的，但是同樣有基于UDP的版本，叫做MQTT-SN。這兩種版本由于基于不同的連接方式，優(yōu)缺點(diǎn)自然也就各有不同了。

• （4）有三種消息發(fā)布服務(wù)質(zhì)量：

  '至多一次'，消息發(fā)布完全依賴底層TCP/IP網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)。這一級別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因?yàn)椴痪煤筮€會有第二次發(fā)送。這一種方式主要普通APP的推送，倘若你的智能設(shè)備在消息推送時(shí)未聯(lián)網(wǎng)，推送過去沒收到，再次聯(lián)網(wǎng)也就收不到了。

  '至少一次'，確保消息到達(dá)，但消息重復(fù)可能會發(fā)生。

  '只有一次'，確保消息到達(dá)一次。在一些要求比較嚴(yán)格的計(jì)費(fèi)系統(tǒng)中，可以使用此級別。在計(jì)費(fèi)系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果。這種最高質(zhì)量的消息發(fā)布服務(wù)還可以用于即時(shí)通訊類的APP的推送，確保用戶收到且只會收到一次。

• （5）小型傳輸，開銷很?。ü潭ㄩL度的頭部是2字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。

  這就是為什么在介紹里說它非常適合'在物聯(lián)網(wǎng)領(lǐng)域，傳感器與服務(wù)器的通信，信息的收集'，要知道嵌入式設(shè)備的運(yùn)算能力和帶寬都相對薄弱，使用這種協(xié)議來傳遞消息再適合不過了。

• （6）使用Last Will和Testament特性通知有關(guān)各方客戶端異常中斷的機(jī)制。

  Last Will：即遺言機(jī)制，用于通知同一主題下的其他設(shè)備發(fā)送遺言的設(shè)備已經(jīng)斷開了連接。

  Testament：遺囑機(jī)制，功能類似于Last Will。

四、MQTT協(xié)議原理

4.1 MQTT協(xié)議實(shí)現(xiàn)方式

實(shí)現(xiàn)MQTT協(xié)議需要客戶端和服務(wù)器端通訊完成，在通訊過程中，MQTT協(xié)議中有三種身份：發(fā)布者（Publish）、代理（Broker）（服務(wù)器）、訂閱者（Subscribe）。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務(wù)器，消息發(fā)布者可以同時(shí)是訂閱者。

MQTT傳輸?shù)南⒎譃椋褐黝}（Topic）和負(fù)載（payload）兩部分：

• （1）Topic，可以理解為消息的類型，訂閱者訂閱（Subscribe）后，就會收到該主題的消息內(nèi)容（payload）；
• （2）payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容。

4.2 網(wǎng)絡(luò)傳輸與應(yīng)用消息

MQTT會構(gòu)建底層網(wǎng)絡(luò)傳輸：它將建立客戶端到服務(wù)器的連接，提供兩者之間的一個(gè)有序的、無損的、基于字節(jié)流的雙向傳輸。

當(dāng)應(yīng)用數(shù)據(jù)通過MQTT網(wǎng)絡(luò)發(fā)送時(shí)，MQTT會把與之相關(guān)的服務(wù)質(zhì)量（QoS）和主題名（Topic）相關(guān)連。

4.3 MQTT客戶端

一個(gè)使用MQTT協(xié)議的應(yīng)用程序或者設(shè)備，它總是建立到服務(wù)器的網(wǎng)絡(luò)連接?？蛻舳丝梢裕?/p>

• （1）發(fā)布其他客戶端可能會訂閱的信息；
• （2）訂閱其它客戶端發(fā)布的消息；
• （3）退訂或刪除應(yīng)用程序的消息；
• （4）斷開與服務(wù)器連接。

4.4 MQTT服務(wù)器

MQTT服務(wù)器以稱為'消息代理'（Broker），可以是一個(gè)應(yīng)用程序或一臺設(shè)備。它是位于消息發(fā)布者和訂閱者之間，它可以：

• （1）接受來自客戶的網(wǎng)絡(luò)連接；
• （2）接受客戶發(fā)布的應(yīng)用信息；
• （3）處理來自客戶端的訂閱和退訂請求；
• （4）向訂閱的客戶轉(zhuǎn)發(fā)應(yīng)用程序消息。

4.5 MQTT協(xié)議中的訂閱、主題、會話

一、訂閱（Subscription）

訂閱包含主題篩選器（Topic Filter）和最大服務(wù)質(zhì)量（QoS）。訂閱會與一個(gè)會話（Session）關(guān)聯(lián)。一個(gè)會話可以包含多個(gè)訂閱。每一個(gè)會話中的每個(gè)訂閱都有一個(gè)不同的主題篩選器。

二、會話（Session）

每個(gè)客戶端與服務(wù)器建立連接后就是一個(gè)會話，客戶端和服務(wù)器之間有狀態(tài)交互。會話存在于一個(gè)網(wǎng)絡(luò)之間，也可能在客戶端和服務(wù)器之間跨越多個(gè)連續(xù)的網(wǎng)絡(luò)連接。

三、主題名（Topic Name）

連接到一個(gè)應(yīng)用程序消息的標(biāo)簽，該標(biāo)簽與服務(wù)器的訂閱相匹配。服務(wù)器會將消息發(fā)送給訂閱所匹配標(biāo)簽的每個(gè)客戶端。

四、主題篩選器（Topic Filter）

一個(gè)對主題名通配符篩選器，在訂閱表達(dá)式中使用，表示訂閱所匹配到的多個(gè)主題。

五、負(fù)載（Payload）

消息訂閱者所具體接收的內(nèi)容。

4.6 MQTT協(xié)議中的方法

MQTT協(xié)議中定義了一些方法（也被稱為動作），來于表示對確定資源所進(jìn)行操作。這個(gè)資源可以代表預(yù)先存在的數(shù)據(jù)或動態(tài)生成數(shù)據(jù)，這取決于服務(wù)器的實(shí)現(xiàn)。通常來說，資源指服務(wù)器上的文件或輸出。主要方法有：

• （1）Connect。等待與服務(wù)器建立連接。
• （2）Disconnect。等待MQTT客戶端完成所做的工作，并與服務(wù)器斷開TCP/IP會話。
• （3）Subscribe。等待完成訂閱。
• （4）UnSubscribe。等待服務(wù)器取消客戶端的一個(gè)或多個(gè)topics訂閱。
• （5）Publish。MQTT客戶端發(fā)送消息請求，發(fā)送完成后返回應(yīng)用程序線程。

五、MQTT協(xié)議數(shù)據(jù)包結(jié)構(gòu)

在MQTT協(xié)議中，一個(gè)MQTT數(shù)據(jù)包由：固定頭（Fixed header）、可變頭（Variable header）、消息體（payload）三部分構(gòu)成。MQTT數(shù)據(jù)包結(jié)構(gòu)如下：

• （1）固定頭（Fixed header）。存在于所有MQTT數(shù)據(jù)包中，表示數(shù)據(jù)包類型及數(shù)據(jù)包的分組類標(biāo)識。
• （2）可變頭（Variable header）。存在于部分MQTT數(shù)據(jù)包中，數(shù)據(jù)包類型決定了可變頭是否存在及其具體內(nèi)容。
• （3）消息體（Payload）。存在于部分MQTT數(shù)據(jù)包中，表示客戶端收到的具體內(nèi)容。

5.1 MQTT固定頭

固定頭存在于所有MQTT數(shù)據(jù)包中，其結(jié)構(gòu)如下：

5.1.1 MQTT數(shù)據(jù)包類型

位置：Byte 1中bits 7-4。

相于一個(gè)4位的無符號值，類型、取值及描述如下：

5.1.2 標(biāo)識位

位置：Byte 1中bits 3-0。

在不使用標(biāo)識位的消息類型中，標(biāo)識位被作為保留位。如果收到無效的標(biāo)志時(shí)，接收端必須關(guān)閉網(wǎng)絡(luò)連接：

（1）DUP：發(fā)布消息的副本。用來在保證消息的可靠傳輸，如果設(shè)置為1，則在下面的變長中增加MessageId，并且需要回復(fù)確認(rèn)，以保證消息傳輸完成，但不能用于檢測消息重復(fù)發(fā)送。

（2）QoS：發(fā)布消息的服務(wù)質(zhì)量，即：保證消息傳遞的次數(shù)

（3）RETAIN： 發(fā)布保留標(biāo)識，表示服務(wù)器要保留這次推送的信息，如果有新的訂閱者出現(xiàn)，就把這消息推送給它，如果設(shè)有那么推送至當(dāng)前訂閱者后釋放。 5.1.3 剩余長度（Remaining Length）

地址：Byte 2。

固定頭的第二字節(jié)用來保存變長頭部和消息體的總大小的，但不是直接保存的。這一字節(jié)是可以擴(kuò)展，其保存機(jī)制，前7位用于保存長度，后一部用做標(biāo)識。當(dāng)最后一位為1時(shí)，表示長度不足，需要使用二個(gè)字節(jié)繼續(xù)保存。例如：計(jì)算出后面的大小為0

5.2 MQTT可變頭

MQTT數(shù)據(jù)包中包含一個(gè)可變頭，它駐位于固定的頭和負(fù)載之間。可變頭的內(nèi)容因數(shù)據(jù)包類型而不同，較常的應(yīng)用是作為包的標(biāo)識：

很多類型數(shù)據(jù)包中都包括一個(gè)2字節(jié)的數(shù)據(jù)包標(biāo)識字段，這些類型的包有：PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK。

5.3 Payload消息體

Payload消息體位MQTT數(shù)據(jù)包的第三部分，包含CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息：

• （1）CONNECT，消息體內(nèi)容主要是：客戶端的ClientID、訂閱的Topic、Message以及用戶名和密碼。
• （2）SUBSCRIBE，消息體內(nèi)容是一系列的要訂閱的主題以及QoS。
• （3）SUBACK，消息體內(nèi)容是服務(wù)器對于SUBSCRIBE所申請的主題及QoS進(jìn)行確認(rèn)和回復(fù)。
• （4）UNSUBSCRIBE，消息體內(nèi)容是要訂閱的主題。

原文鏈接：https://blog.csdn.net/qq_28877125/article/details/78325003