概述

MQTT是IBM開發(fā)的一個即時通訊協(xié)議择克，有可能成為物聯(lián)網的重要組成部分几迄。該協(xié)議支持所有平臺可训，幾乎可以把所有聯(lián)網物品和外部連接起來沫勿，被用來當做傳感器和制動器之間通信的橋梁。

MQTT協(xié)議是為大量計算能力有限梯找，且工作在低帶寬倦炒、不可靠的網絡的遠程傳感器和控制設備通訊而設計的協(xié)議庸队。有以下特點：

• 使用發(fā)布/訂閱消息模式获枝，提供一對多的消息發(fā)布
• 使用TCP/IP提供網絡連接
• 小型傳輸蠢正，開銷很小（固定長度的頭部是 2 字節(jié)）省店，協(xié)議交換最小化嚣崭，以降低網絡流量笨触，傳輸?shù)膬热葑畲鬄?56MB。
• 使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制雹舀。

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

MQTT系統(tǒng)由與服務器通信的客戶端組成芦劣，通常稱服務器為“代理Broker”∷涤埽客戶可以是信息發(fā)布者Publish或訂閱者Subscribe虚吟。每個客戶端都可以連接到代理。

信息按主題層次結構組織签财。當發(fā)布者具有要分發(fā)的新數(shù)據(jù)時串慰，它會將包含數(shù)據(jù)的控制消息發(fā)送到連接的代理。然后荠卷，代理將信息分發(fā)給已訂閱該主題的任何客戶端模庐。發(fā)布者不需要有關于訂閱者數(shù)量或位置的任何數(shù)據(jù)烛愧，而訂閱者又不必配置有關發(fā)布者的任何數(shù)據(jù)油宜。

MQTT傳輸?shù)南⒎譃椋褐黝}（Topic）和負載（payload）兩部分：
（1）Topic，可以理解為消息的類型怜姿，訂閱者訂閱（Subscribe）后慎冤，就會收到該主題的消息內容（payload）；
（2）payload沧卢，可以理解為消息的內容蚁堤，是指訂閱者具體要使用的內容。

2. MQTT協(xié)議中的訂閱但狭、主題披诗、會話

2.1訂閱（Subscription）

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

2.2會話（Session）

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

2.3主題名（Topic Name）

連接到一個應用程序消息的標簽几于，該標簽與服務器的訂閱相匹配。服務器會將消息發(fā)送給訂閱所匹配標簽的每個客戶端沿后。
系統(tǒng)主題：通過定義$SYS開頭的主題可以查看一些系統(tǒng)信息沿彭，如客戶端連接數(shù)量等，
詳細介紹：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中非剃，無論是發(fā)布還是訂閱都不會有任何觸發(fā)事件。
1個Topic只有唯一的retain消息推沸，Broker會保存每個Topic的最后一條retain消息备绽。
發(fā)布消息時把retain設置為true，即為保留信息鬓催。每個Client訂閱Topic后會立即讀取到retain消息肺素。如果需要刪除retain消息，可以發(fā)布一個空的retain消息宇驾，因為每個新的retain消息都會覆蓋最后一個retain消息倍靡。

最后遺囑 Last Will & Testament

MQTT本身就是為信號不穩(wěn)定的網絡設計的，所以難免一些客戶端會無故的和Broker斷開連接课舍。 當客戶端連接到Broker時塌西，可以指定LWT，Broker會定期檢測客戶端是否有異常筝尾。
當客戶端異常掉線時捡需，Broker就往連接時指定的topic里推送當時指定的LWT消息。

4.消息服務質量

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

4.1“至多一次”

至多一次

消息發(fā)布完全依賴底層TCP/IP網絡筹淫。會發(fā)生消息丟失或重復站辉。這一級別可用于如下情況，環(huán)境傳感器數(shù)據(jù)损姜，丟失一次讀記錄無所謂饰剥，因為不久后還會有第二次發(fā)送。

4.2“至少一次”

至少一次

PUBACK消息是對QoS級別為1的PUBLISH消息的響應.PUBACK消息由服務器發(fā)送以響應來自發(fā)布端的PUBLISH消息摧阅，訂閱端也會響應來自服務器的PUBLISH消息汰蓉。當發(fā)布端收到PUBACK消息時，它會丟棄原始消息逸尖，因為它也被服務器接收（并記錄）古沥。

如果一定時間內，發(fā)布端或服務器沒有收到PUBACK消息娇跟，則會進行重發(fā)岩齿。這種方式雖然確保了消息到達，但消息重復可能會發(fā)生苞俘。

4.3“只有一次”

只有一次

PUBREC消息是對QoS級別為2的PUBLISH消息的響應盹沈。它是QoS級別2協(xié)議流的第二個消息。 PUBREC消息由服務器響應來自發(fā)布端的PUBLISH消息，或訂閱端響應來自服務器的PUBLISH消息乞封。發(fā)布端或服務器收到PUBREC消息時做裙，會響應PUBREL消息。

PUBREL消息是從發(fā)布端對PUBREC的響應肃晚，或從服務器對訂閱端PUBREC消息的響應锚贱。 這是QoS 2協(xié)議流中第三個消息。當服務器從發(fā)布者收到PUBREL消息時关串，服務器會將PUBLISH消息發(fā)送到訂閱端拧廊，并發(fā)送PUBCOMP消息到發(fā)布端。 當訂閱端收到來自服務器的消息PUBREL時晋修，使得消息可用于應用程序并將PUBCOMP消息發(fā)送到服務器吧碾。

PUBCOMP消息是服務器對來自發(fā)布端的PUBREL消息的響應，或訂閱者對來自服務器的PUBREL消息的響應墓卦。 它是QoS 2協(xié)議流程中的第四個也是最后一個消息倦春。當發(fā)布端收到PUBCOMP消息時，它會丟棄原始消息落剪，因為它已經將消息發(fā)給了服務器睁本。

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

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