這篇文章主要介紹“MQTT的介紹及使用”，在日常操作中，相信很多人在MQTT的介紹及使用問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MQTT的介紹及使用”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

創(chuàng)新互聯(lián)建站專注于墾利企業(yè)網(wǎng)站建設,自適應網(wǎng)站建設,商城網(wǎng)站定制開發(fā)。墾利網(wǎng)站建設公司,為墾利等地區(qū)提供建站服務。全流程定制網(wǎng)站開發(fā)，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務

1 簡述

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

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

2 設計規(guī)范

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

• 精簡，不添加可有可無的功能；

• 發(fā)布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞；

• 允許用戶動態(tài)創(chuàng)建主題，零運維成本；

• 把傳輸量降到最低以提高傳輸效率；

• 把低帶寬、高延遲、不穩(wěn)定的網(wǎng)絡等因素考慮在內(nèi)；

• 支持連續(xù)的會話控制；

• 理解客戶端計算能力可能很低；

• 提供服務質(zhì)量管理；

• 假設數(shù)據(jù)不可知，不強求傳輸數(shù)據(jù)的類型與格式，保持靈活性。

3 主要特性

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

• 使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應用程序耦合。這一點很類似于XMPP，但是MQTT的信息冗余遠小于XMPP，因為XMPP使用XML格式文本來傳遞數(shù)據(jù)。

• 對負載內(nèi)容屏蔽的消息傳輸。

• 使用TCP/IP提供網(wǎng)絡連接。主流的MQTT是基于TCP連接進行數(shù)據(jù)推送的，但是同樣有基于UDP的版本，叫做MQTT-SN。這兩種版本由于基于不同的連接方式，優(yōu)缺點自然也就各有不同了。

• 有三種消息發(fā)布服務質(zhì)量QoS (Quality of Service)：

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

• At Least Once 至少一次，確保消息到達，但消息重復可能會發(fā)生。

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

• 小型傳輸，開銷很?。ü潭ㄩL度的頭部是2字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡流量。這就是為什么在介紹里說它非常適合"在物聯(lián)網(wǎng)領(lǐng)域，傳感器與服務器的通信，信息的收集"，要知道嵌入式設備的運算能力和帶寬都相對薄弱，使用這種協(xié)議來傳遞消息再適合不過了。

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

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

• Testament：遺囑機制，功能類似于Last Will。

4 MQTT協(xié)議原理

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

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

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

• Topic，可以理解為消息的類型，訂閱者訂閱（Subscribe）后，就會收到該主題的消息內(nèi)容（Payload）；

• Payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容。

4.2 網(wǎng)絡傳輸與應用消息

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

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

4.3 MQTT客戶端

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

• 發(fā)布其他客戶端可能會訂閱的信息；

• 訂閱其它客戶端發(fā)布的消息；

• 退訂或刪除應用程序的消息；

• 斷開與服務器連接。

4.4 MQTT服務器

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

• 接受來自客戶的網(wǎng)絡連接；

• 接受客戶發(fā)布的應用信息；

• 處理來自客戶端的訂閱和退訂請求；

• 向訂閱的客戶轉(zhuǎn)發(fā)應用程序消息。

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

4.5.1 訂閱（Subscription）

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

4.5.2 會話（Session）

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

4.5.3 主題名（Topic Name）

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

4.5.4 主題篩選器（Topic Filter）

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

4.5.5 負載（Payload）

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

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

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

• Connect：等待與服務器建立連接。

• Disconnect：等待MQTT客戶端完成所做的工作，并與服務器斷開TCP/IP會話。

• Subscribe：等待完成訂閱。

• UnSubscribe：等待服務器取消客戶端的一個或多個topics訂閱。

• Publish：MQTT客戶端發(fā)送消息請求，發(fā)送完成后返回應用程序線程。

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

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

• 固定頭（Fixed header）：存在于所有MQTT數(shù)據(jù)包中，表示數(shù)據(jù)包類型及數(shù)據(jù)包的分組類標識。

• 可變頭（Variable header）：存在于部分MQTT數(shù)據(jù)包中，數(shù)據(jù)包類型決定了可變頭是否存在及其具體內(nèi)容。

• 消息體（Payload）：存在于部分MQTT數(shù)據(jù)包中，表示客戶端收到的具體內(nèi)容。

5.1 MQTT固定頭

固定頭存在于所有MQTT數(shù)據(jù)包中，包含兩部分內(nèi)容：首字節(jié)(Byte 1) 和 剩余消息報文長度(1-4字節(jié))

• Byte 1 首字節(jié)：

• Bit 7 6 5 4  高四位無符號值，用于表示MQTT消息的報文類型(MQTT Control Packet type)，總共可以表示2^4=16種協(xié)議類型。

• Bit 3 2 1 0 低四位無符號值，用作某些報文的特殊標記(Flags specific to each MQTT Control Packet type)。

• Byte 2… Remaining Length 剩余消息報文長度

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

位于 首字節(jié)的高四位，即Byte 1中的 bits 7-4，相于一個4位的無符號值。用于確定報文類型。共有2^4=16種，其中0000和1111是保留字段。具體如下：

報文類型	字段值	數(shù)據(jù)方向	描述
保留	0	禁用	保留
CONNECT	1	Client -> Server	客戶端連接到服務器
CONNACK	2	Server -> Client	連接確認
PUBLISH	3	Client <-> Server	發(fā)布消息
PUBACK	4	Client <-> Server	發(fā)布確認
PUBREC	5	Client <-> Server	消息已接收(QoS2第一階段)
PUBREL	6	Client <-> Server	消息釋放(QoS2第二階段)
PUBCOMP	7	Client <-> Server	發(fā)布結(jié)束(QoS2第三階段)
SUBSCRIBE	8	Client -> Server	客戶端訂閱請求
SUBACK	9	Server -> Client	服務端訂閱確認
UNSUBACRIBE	10	Client -> Server	客戶端取消訂閱
UNSUBACK	11	Server -> Client	服務端取消訂閱確認
PINGREQ	12	Client -> Server	客戶端發(fā)送心跳
PINGRESP	13	Server -> Client	服務端回復心跳
DISCONNECT	14	Client -> Server	客戶端斷開連接請求
保留	15	禁用	保留

5.1.2 標識位 Flags specific to each MQTT Control Packet type

位于首字節(jié)的低四位，即Byte 1中bits 3-0。表示某些報文類型的控制字段，實際上只有少數(shù)報文類型有控制位。

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

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

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

?00：最多一次，即：<=1?01：至少一次，即：>=1?10：一次，即：=1?11：預留

• RETAIN： 發(fā)布保留標識，表示服務器要保留這次推送的信息，如果有新的訂閱者出現(xiàn)，就把這消息推送給它，如果設有那么推送至當前訂閱者后釋放。

5.1.3 剩余長度（Remaining Length）

用來保存變長頭部(Variable Header)和消息體(Payload)的總大小。從第二字節(jié)(Byte 2)開始，最長可達4字節(jié)，所以剩余長度范圍是Byte[2-5]。那么怎樣確定其長度到底是1字節(jié)還是4字節(jié)呢？它先用從低位Bit 0到Bit 6來存儲，當發(fā)現(xiàn)不夠時，則將 最高位Bit 7(默認都是高字節(jié)在前)置為 1，表示長度不足，需要使用下一個字節(jié)繼續(xù)保存，就繼續(xù)計算字節(jié)長度；如果是0，那么就不再計算字節(jié)長度。

消息長度可以簡單理解為128進制的數(shù)據(jù)，4位長度最大可以表示128, 128, 128*128Byte=256MB。但是這個長度的計算有些特別，就是低位在前，高位在后(因為正常的表示方法是高位在前，低位在后)，字節(jié)最高位Bit7用于標記是否需要繼續(xù)計算消息長度。以下是消息長度的長度范圍：

字節(jié)數(shù)	長度最小值	長度最大值
1	0(0x00)	127(0x7F)
2	128 (0x80, 0x01)	16 383 (0xFF, 0x7F)
3	16 384 (0x80, 0x80, 0x01)	2 097 151 (0xFF, 0xFF, 0x7F)
4	2 097 152 (0x80, 0x80, 0x80, 0x01)	268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

5.2 MQTT可變頭

MQTT數(shù)據(jù)包中包含一個可變頭，它駐位于固定的頭和負載之間?？勺冾^的內(nèi)容因數(shù)據(jù)包類型而不同，較常的應用是作為包的標識：

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

5.3 Payload消息體

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

• CONNECT，消息體內(nèi)容主要是：客戶端的ClientID、訂閱的Topic、Message以及用戶名和密碼。

• SUBSCRIBE，消息體內(nèi)容是一系列的要訂閱的主題以及QoS。

• SUBACK，消息體內(nèi)容是服務器對于SUBSCRIBE所申請的主題及QoS進行確認和回復。

• UNSUBSCRIBE，消息體內(nèi)容是要訂閱的主題。

到此，關(guān)于“MQTT的介紹及使用”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

名稱欄目：MQTT的介紹及使用
新聞來源：http://jinyejixie.com/article16/ijjigg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供域名注冊、網(wǎng)站導航、微信小程序、網(wǎng)站內(nèi)鏈、定制網(wǎng)站、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)