概述

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開頭的主題可以查看一些系統信息，如客戶端連接數量等， 詳細介紹：https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics

2.4主題篩選器（Topic Filter）

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

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的推送，確保用戶收到且只會收到一次。