MQTT簡介

1 簡述

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基於發佈/訂閱（publish/subscribe）模式的"輕量級"通信協議，該協議構建於TCP/IP協議上，由IBM在1999年發佈。MQTT最大優勢在於，能夠以極少的代碼和有限的帶寬，爲鏈接遠程設備提供實時可靠的消息服務。做爲一種低開銷、低帶寬佔用的即時通信協議，使其在物聯網、小型設備、移動應用等方面有較普遍的應用。

MQTT是一個基於客戶端-服務器的消息發佈/訂閱傳輸協議。MQTT協議是輕量、簡單、開放和易於實現的，這些特色使它適用範圍很是普遍。在不少狀況下，包括受限的環境中，如：機器與機器（M2M）通訊和物聯網（IoT）。其在，經過衛星鏈路通訊傳感器、偶爾撥號的醫療設備、智能家居、及一些小型化設備中已普遍使用。

2 設計規範

因爲物聯網的環境是很是特別的，因此MQTT遵循如下設計原則：

• 精簡，不添加無關緊要的功能；
• 發佈/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞；
• 容許用戶動態建立主題，零運維成本；
• 把傳輸量降到最低以提升傳輸效率；
• 把低帶寬、高延遲、不穩定的網絡等因素考慮在內；
• 支持連續的會話控制；
• 理解客戶端計算能力可能很低；
• 提供服務質量管理；
• 假設數據不可知，不強求傳輸數據的類型與格式，保持靈活性。

3 主要特性

MQTT協議工做在低帶寬、不可靠的網絡的遠程傳感器和控制設備通信而設計的協議，它具備如下主要的幾項特性：

• 使用發佈/訂閱消息模式，提供一對多的消息發佈，解除應用程序耦合。這一點很相似於XMPP，可是MQTT的信息冗餘遠小於XMPP，由於XMPP使用XML格式文原本傳遞數據。

• 對負載內容屏蔽的消息傳輸。

• 使用TCP/IP提供網絡鏈接。主流的MQTT是基於TCP鏈接進行數據推送的，可是一樣有基於UDP的版本，叫作MQTT-SN。這兩種版本因爲基於不一樣的鏈接方式，優缺點天然也就各有不一樣了。

• 有三種消息發佈服務質量QoS (Quality of Service)：

  • At Most Once 至多一次，消息發佈徹底依賴底層TCP/IP網絡。會發生消息丟失或重複。這一級別可用於以下狀況，環境傳感器數據，丟失一次讀記錄無所謂，由於不久後還會有第二次發送。這一種方式主要普通APP的推送，假若你的智能設備在消息推送時未聯網，推送過去沒收到，再次聯網也就收不到了。

  • At Least Once 至少一次，確保消息到達，但消息重複可能會發生。

  • Exactly Once 有且僅有一次，確保消息到達一次。在一些要求比較嚴格的計費系統中，可使用此級別。在計費系統中，消息重複或丟失會致使不正確的結果。這種最高質量的消息發佈服務還能夠用於即時通信類的APP的推送，確保用戶收到且只會收到一次。

• 小型傳輸，開銷很小（固定長度的頭部是2字節），協議交換最小化，以下降網絡流量。這就是爲何在介紹裏說它很是適合"在物聯網領域，傳感器與服務器的通訊，信息的收集"，要知道嵌入式設備的運算能力和帶寬都相對薄弱，使用這種協議來傳遞消息再適合不過了。

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

  • Last Will：即遺言機制，用於通知同一主題下的其餘設備發送遺言的設備已經斷開了鏈接。

  • Testament：遺囑機制，功能相似於Last Will。

 

4 MQTT協議原理

4.1 MQTT協議實現方式

實現MQTT協議須要客戶端和服務器端通信完成，在通信過程當中，MQTT協議中有三種身份：發佈者（Publish）、代理（Broker）、訂閱者（Subscribe）。其中，消息的發佈者和訂閱者都是客戶端，消息代理是服務器，消息發佈者能夠同時是訂閱者。

MQTT傳輸的消息分爲：主題（Topic）和負載（Payload）兩部分：

• Topic，能夠理解爲消息的類型，訂閱者訂閱（Subscribe）後，就會收到該主題的消息內容（Payload）；
• Payload，能夠理解爲消息的內容，是指訂閱者具體要使用的內容。

4.2 網絡傳輸與應用消息

MQTT會構建底層網絡傳輸：它將創建客戶端到服務器的鏈接，提供二者之間的一個有序的、無損的、基於字節流的雙向傳輸。

當應用數據經過MQTT網絡發送時，MQTT會把與之相關的服務質量（QoS）和主題名（Topic）相關連。

4.3 MQTT客戶端

一個使用MQTT協議的應用程序或者設備，它老是創建到服務器的網絡鏈接。客戶端能夠：

• 發佈其餘客戶端可能會訂閱的信息；
• 訂閱其它客戶端發佈的消息；
• 退訂或刪除應用程序的消息；
• 斷開與服務器鏈接。

4.4 MQTT服務器

MQTT服務器以稱爲"消息代理"（Broker），能夠是一個應用程序或一臺設備。它位於消息發佈者和訂閱者之間，它能夠：

• 接受來自客戶的網絡鏈接；
• 接受客戶發佈的應用信息；
• 處理來自客戶端的訂閱和退訂請求；
• 向訂閱的客戶轉發應用程序消息。

4.5 MQTT協議中的訂閱、主題、會話

4.5.1 訂閱（Subscription）

訂閱包含主題篩選器（Topic Filter）和最大服務質量（QoS）。訂閱會與一個會話（Session）關聯。一個會話能夠包含多個訂閱。每個會話中的每一個訂閱都有一個不一樣的主題篩選器。

4.5.2 會話（Session）

每一個客戶端與服務器創建鏈接後就是一個會話，客戶端和服務器之間有狀態交互。會話存在於一個網絡之間，也可能在客戶端和服務器之間跨越多個連續的網絡鏈接。

4.5.3 主題名（Topic Name）

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

4.5.4 主題篩選器（Topic Filter）

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

4.5.5 負載（Payload）

消息訂閱者所具體接收的內容。

4.6 MQTT協議中的方法

MQTT協議中定義了一些方法（也被稱爲動做），來於表示對肯定資源所進行操做。這個資源能夠表明預先存在的數據或動態生成數據，這取決於服務器的實現。一般來講，資源指服務器上的文件或輸出。主要方法有：

• Connect：等待與服務器創建鏈接。
• Disconnect：等待MQTT客戶端完成所作的工做，並與服務器斷開TCP/IP會話。
• Subscribe：等待完成訂閱。
• UnSubscribe：等待服務器取消客戶端的一個或多個topics訂閱。
• Publish：MQTT客戶端發送消息請求，發送完成後返回應用程序線程。

 

5 MQTT協議數據包結構

在MQTT協議中，一個MQTT數據包由：固定頭（Fixed header）、可變頭（Variable header）、消息體（payload）三部分構成。

• 固定頭（Fixed header）：存在於全部MQTT數據包中，表示數據包類型及數據包的分組類標識。
• 可變頭（Variable header）：存在於部分MQTT數據包中，數據包類型決定了可變頭是否存在及其具體內容。
• 消息體（Payload）：存在於部分MQTT數據包中，表示客戶端收到的具體內容。

5.1 MQTT固定頭

固定頭存在於全部MQTT數據包中，包含兩部份內容：首字節(Byte 1) 和 剩餘消息報文長度(1-4字節)

• Byte 1 首字節：
  • Bit 7 6 5 4  高四位無符號值，用於表示MQTT消息的報文類型(MQTT Control Packet type)，總共能夠表示2^4=16種協議類型。
  • Bit 3 2 1 0 低四位無符號值，用做某些報文的特殊標記(Flags specific to each MQTT Control Packet type)。
• Byte 2… Remaining Length 剩餘消息報文長度

5.1.1 MQTT數據包類型 MQTT Control Packet type

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

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

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

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

在不使用標識位的消息類型中，標識位被做爲保留位。若是收到無效的標誌時，接收端必須關閉網絡鏈接：

• DUP：發佈消息的副本。用來在保證消息的可靠傳輸，若是設置爲1，則在下面的變長中增長MessageId，而且須要回覆確認，以保證消息傳輸完成，但不能用於檢測消息重複發送。
• QoS：發佈消息的服務質量，即：保證消息傳遞的次數。

Ø00：最多一次，即：<=1

Ø01：至少一次，即：>=1

Ø10：一次，即：=1

Ø11：預留

• RETAIN： 發佈保留標識，表示服務器要保留此次推送的信息，若是有新的訂閱者出現，就把這消息推送給它，若是設有那麼推送至當前訂閱者後釋放。

5.1.3 剩餘長度（Remaining Length）

用來保存變長頭部(Variable Header)和消息體(Payload)的總大小。從第二字節(Byte 2)開始，最長可達4字節，因此剩餘長度範圍是Byte[2-5]。那麼怎樣肯定其長度究竟是1字節仍是4字節呢？它先用從低位Bit 0到Bit 6來存儲，當發現不夠時，則將 最高位Bit 7(默認都是高字節在前)置爲 1，表示長度不足，須要使用下一個字節繼續保存，就繼續計算字節長度；若是是0，那麼就再也不計算字節長度。

消息長度能夠簡單理解爲128進制的數據，4位長度最大能夠表示128, 128, 128*128Byte=256MB。可是這個長度的計算有些特別，就是低位在前，高位在後(由於正常的表示方法是高位在前，低位在後)，字節最高位Bit7用於標記是否須要繼續計算消息長度。如下是消息長度的長度範圍：

字節數	長度最小值	長度最大值
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數據包中包含一個可變頭，它駐位於固定的頭和負載之間。可變頭的內容因數據包類型而不一樣，較常的應用是做爲包的標識：

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

5.3 Payload消息體

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

• CONNECT，消息體內容主要是：客戶端的ClientID、訂閱的Topic、Message以及用戶名和密碼。
• SUBSCRIBE，消息體內容是一系列的要訂閱的主題以及QoS。
• SUBACK，消息體內容是服務器對於SUBSCRIBE所申請的主題及QoS進行確認和回覆。
• UNSUBSCRIBE，消息體內容是要訂閱的主題。