MQTT 協議概述

概述

MQTT是IBM開發的一個即時通信協議，有可能成爲物聯網的重要組成部分。該協議支持全部平臺，幾乎能夠把全部聯網物品和外部鏈接起來，被用來當作傳感器和制動器之間通訊的橋樑。

MQTT協議是爲大量計算能力有限，且工做在低帶寬、不可靠的網絡的遠程傳感器和控制設備通信而設計的協議。有如下特色：

• 使用發佈/訂閱消息模式，提供一對多的消息發佈
• 使用TCP/IP提供網絡鏈接
• 小型傳輸，開銷很小（固定長度的頭部是 2 字節），協議交換最小化，以下降網絡流量，傳輸的內容最大爲256MB。
• 使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制。

1.MQTT協議實現方式

---

MQTT系統由與服務器通訊的客戶端組成，一般稱服務器爲「代理Broker」。客戶能夠是信息發佈者Publish或訂閱者Subscribe。每一個客戶端均可以鏈接到代理。

信息按主題層次結構組織。當發佈者具備要分發的新數據時，它會將包含數據的控制消息發送到鏈接的代理。而後，代理將信息分發給已訂閱該主題的任何客戶端。發佈者不須要有關於訂閱者數量或位置的任何數據，而訂閱者又沒必要配置有關發佈者的任何數據。

MQTT傳輸的消息分爲：主題（Topic）和負載（payload）兩部分： （1）Topic，能夠理解爲消息的類型，訂閱者訂閱（Subscribe）後，就會收到該主題的消息內容（payload）； （2）payload，能夠理解爲消息的內容，是指訂閱者具體要使用的內容。

2. MQTT協議中的術語

---

2.1訂閱（Subscription）

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

2.2會話（Session）

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

2.3主題名（Topic Name）

鏈接到一個應用程序消息的標籤，該標籤與服務器的訂閱相匹配。服務器會將消息發送給訂閱所匹配標籤的每一個客戶端。 系統主題：經過定義$SYS開頭的主題能夠查看一些系統信息，如客戶端鏈接數量等， 詳細介紹：github.com/mqtt/mqtt.g…

2.4主題篩選器（Topic Filter）

一個對主題名通配符篩選器，在訂閱表達式中使用，表示訂閱所匹配到的多個主題。 多級匹配符 # 單級匹配符 + 更多主題討論，請移步github wiki github.com/mqtt/mqtt.g…

2.5負載（Payload）

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

3.保留消息和最後遺囑

---

保留消息 Retained Messages

MQTT中，不管是發佈仍是訂閱都不會有任何觸發事件。 1個Topic只有惟一的retain消息，Broker會保存每一個Topic的最後一條retain消息。 發佈消息時把retain設置爲true，即爲保留信息。每一個Client訂閱Topic後會當即讀取到retain消息。若是須要刪除retain消息，能夠發佈一個空的retain消息，由於每一個新的retain消息都會覆蓋最後一個retain消息。

最後遺囑 Last Will & Testament

MQTT自己就是爲信號不穩定的網絡設計的，因此不免一些客戶端會無端的和Broker斷開鏈接。 當客戶端鏈接到Broker時，能夠指定LWT，Broker會按期檢測客戶端是否有異常。 當客戶端異常掉線時，Broker就往鏈接時指定的topic裏推送當時指定的LWT消息。

4.消息服務質量

---

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

4.1「至多一次」

消息發佈徹底依賴底層TCP/IP網絡。會發生消息丟失或重複。這一級別可用於以下狀況，環境傳感器數據，丟失一次讀記錄無所謂，由於不久後還會有第二次發送。

4.2「至少一次」

PUBACK消息是對QoS級別爲1的PUBLISH消息的響應.PUBACK消息由服務器發送以響應來自發布端的PUBLISH消息，訂閱端也會響應來自服務器的PUBLISH消息。當發佈端收到PUBACK消息時，它會丟棄原始消息，由於它也被服務器接收（並記錄）。

若是必定時間內，發佈端或服務器沒有收到PUBACK消息，則會進行重發。這種方式雖然確保了消息到達，但消息重複可能會發生。

4.3「只有一次」

PUBREC消息是對QoS級別爲2的PUBLISH消息的響應。它是QoS級別2協議流的第二個消息。 PUBREC消息由服務器響應來自發布端的PUBLISH消息，或訂閱端響應來自服務器的PUBLISH消息。發佈端或服務器收到PUBREC消息時，會響應PUBREL消息。

PUBREL消息是從發佈端對PUBREC的響應，或從服務器對訂閱端PUBREC消息的響應。 這是QoS 2協議流中第三個消息。當服務器從發佈者收到PUBREL消息時，服務器會將PUBLISH消息發送到訂閱端，併發送PUBCOMP消息到發佈端。 當訂閱端收到來自服務器的消息PUBREL時，使得消息可用於應用程序並將PUBCOMP消息發送到服務器。

PUBCOMP消息是服務器對來自發布端的PUBREL消息的響應，或訂閱者對來自服務器的PUBREL消息的響應。 它是QoS 2協議流程中的第四個也是最後一個消息。當發佈端收到PUBCOMP消息時，它會丟棄原始消息，由於它已經將消息發給了服務器。

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

---

附錄：各編程語言對MQTT客戶端/服務器的實現

Name	Language	Type	Last release	License
Adafruit IO	Ruby on Rails, Node.js	Client	2.0.0	?
flespi	C	Broker	?	Proprietary License
M2Mqtt	C#	Client	4.3.0.0	Eclipse Public License 1.0
Machine Head	Clojure	Client	1.0.0	Creative Commons Attribution 3.0 Unported License
moquette	Java	Broker	0.10	Apache License 2.0
Mosquitto	C, Python	Broker and client	1.4.15	Eclipse Public License 1.0, Eclipse Distribution License 1.0 (BSD)
Paho MQTT	C, C++, Java, Javascript, Python, Go	Client	1.3.0	Eclipse Public License 1.0, Eclipse Distribution License 1.0 (BSD)
SharkMQTT	C	Client	1.5	Proprietary License
VerneMQ	Erlang/OTP	Broker	1.4.1	Apache License 2.0
wolfMQTT	C	Client	0.14	GNU Public License, version 2
MQTTRoute	C, Python	Broker	1.0	Proprietary License
HiveMQ	Java	Broker	3.4.0	Proprietary License
SwiftMQ	Java	Broker	11.1.0	Proprietary License
JoramMQ	Java	Broker	11.1.0	Proprietary License