初識MQTT協議

 OpsDev - 張超 360雲計算

女主宣言

最近在看MQTT協議相關的內容，先整理收集的一些信息，以及本身的一些理解，若有錯誤之處，敬請糾正，有不清楚的地方，也但願可以和你們一塊兒討論，探討 本篇文章，簡述MQTT歷史，產生所要解決的問題，以及協議的基礎格式。

PS：豐富的一線技術、多元化的表現形式，盡在「HULK一線技術雜談」，點關注哦！

前言

MQTT協議是一個簡單的中心輻射型系統：傳感器、應用和設備之間的通訊是經過中央代理端運行的數據中心服務實現的。其精簡低帶寬的特性使得它可以適用於不少應用，好比家庭自動化：包括供暖、通風、空調（HVAC）、照明、智能設備和安全等方面都採用了MQTT協議。

1

淺談歷史

MQTT協議由Andy Stanford-Clark（IBM）和Arlen Nipper（Arcom，現爲Cirrus Link）於1999年發明。他們須要一種協議，以最小化電池損耗和最小帶寬，經過衛星與石油管道鏈接。 發明之初爲協議規定了幾個要求:

1. 實施簡單

2. 提供服務質量的數據傳輸

3. 輕巧和帶寬高效

4. 數據不可知

5. 持續的會話意識

2

協議格式

MQTT協議控制報文的格式包含如下三個部分，以固定報頭，可變報頭和有效載荷，其中固定報文頭是全部的控制報文都有， 可變報頭和有效載荷都是部分控制報文包含。

 

固定報頭

固定報頭是兩個字節組成，其具體的格式以下所示:

控制報文類型

第一個字節的二進制位7-4無符號整數表示控制報文的類型，具體類型對應的值爲:

備註： 其中預留值15已經在MQTT5中使用到AUTH中了。

標誌

第一個字節的二進制位3-0包含每一個MQTT控制報文類型特定的標誌， 控制報文中的標誌爲必須按照以下表格進行設置，若是設置有問題，則接收者必須斷開鏈接。

備註：從協議規範看出，目前只有PUBLISH的標誌位是使用的，其餘控制報文都是預留狀態，可是必須保持上述表格的形式。

剩餘長度

第二個字節表示當前報文剩餘部分的字節數，包括可變報頭和有效載荷。剩餘長度不包括用於編碼剩餘長度字段自己的字節數。剩餘長度字段使用一個變長度編碼方案，對小於128的值使用單字節編碼，超過128的值，最高有效未用於指示是否有更多的字節，所以每一個字節能夠編碼128個數值和一個延續位，剩餘長度字段最大4個字節。 舉例：十進制64被編碼爲一個字節，十六進制表示爲Ox40。十進制數字321編碼爲兩個字節，最低有效位在前，第一個字節65+128=193，第二個字節爲2。 剩餘長度最大爲256M的報文，並且報文是不支持分包處理的，因此MQTT協議並不適合一些數據量特別大的場景，好比視頻直播等數據包比較大的場景。

 

可變報頭

可變報頭介於固定報頭和有效載荷中間。不一樣的控制報文有着不一樣的可變報頭，其中PacketId是一個在多個控制報文中存在一個報文。 PacketId包含兩個字節，如今包含該字段的控制報文有，PUBLISH(Qos>0), PUBACK, PUBREC, PUBREL,PUBCOMP,SUBSCRIBE,SUBACK, UNSUBSCRIBE, UNSUBACK。

具體包含狀況以下:

注意事項

• PUBLISH Qos0的報文是不能又packetId的。

• 有些對應的控制報文中的packetId必須和與該控制報文綁定的其它控制報文保持一直，例如PUBLISH Qos1對應的是PUBACK，PUBLISH Qos2對應的PUBCOMP。

• 發送者和接收者是分開維護各自的packetId,因此會出現交互雙方出現相同packetId的兩個不一樣的控制報文。

• 關於不能有packetId的控制報文，多是因爲packetId是能夠複用的，沒有辦法確承認以複用的場景不能使用報文，好比Qos0的PUBLISH報文，因爲沒有迴應，因此發送者沒法得知packetId什麼時候能夠釋放複用，故不容許存在該字段。

 

有效載荷

有效載荷即爲應用消息。 目前MQTT3.1.1中包含以下的控制報文CONNECT, CONNACK, PUBLISH, PUBACK，PUBREC, PUBREL, PUBCOMP,SUBSCRIBE,SUBACK,UNSUBSCRIBE,UNSUBACK,PINGREQ,PINGRESP,DISCONNECT的協議，關於這些協議的具體格式，使用場景等將在後續的文章中給出解釋。

3

總結

MQTT是二進制的協議，控制字段是精確到Bit級別的，單純這一點就足覺得其在物聯網領域佔據一席之地。MQTT是不支持分包等機制，並不適宜一些數據包特別大的應用場景。