概述

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

MQTT協(xié)議是為大量計算能力有限，且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備通訊而設(shè)計的協(xié)議。有以下特點：

使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布

使用TCP/IP提供網(wǎng)絡(luò)連接

小型傳輸，開銷很?。ü潭ㄩL度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量，傳輸?shù)膬?nèi)容最大為256MB。

使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機(jī)制。

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

MQTT系統(tǒng)由與服務(wù)器通信的客戶端組成，通常稱服務(wù)器為“代理Broker”?？蛻艨梢允切畔l(fā)布者Publish或訂閱者Subscribe。每個客戶端都可以連接到代理。

信息按主題層次結(jié)構(gòu)組織。當(dāng)發(fā)布者具有要分發(fā)的新數(shù)據(jù)時，它會將包含數(shù)據(jù)的控制消息發(fā)送到連接的代理。然后，代理將信息分發(fā)給已訂閱該主題的任何客戶端。發(fā)布者不需要有關(guān)于訂閱者數(shù)量或位置的任何數(shù)據(jù)，而訂閱者又不必配置有關(guān)發(fā)布者的任何數(shù)據(jù)。

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

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

2.1訂閱（Subscription）

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

2.2會話（Session）

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

2.3主題名（Topic Name）

連接到一個應(yīng)用程序消息的標(biāo)簽，該標(biāo)簽與服務(wù)器的訂閱相匹配。服務(wù)器會將消息發(fā)送給訂閱所匹配標(biāo)簽的每個客戶端。 系統(tǒng)主題：通過定義$SYS開頭的主題可以查看一些系統(tǒng)信息，如客戶端連接數(shù)量等， 詳細(xì)介紹：https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics

2.4主題篩選器（Topic Filter）

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

2.5負(fù)載（Payload）

消息訂閱者所具體接收的內(nèi)容。

3.保留消息和最后遺囑

保留消息 Retained Messages

MQTT中，無論是發(fā)布還是訂閱都不會有任何觸發(fā)事件。 1個Topic只有唯一的retain消息，Broker會保存每個Topic的最后一條retain消息。 發(fā)布消息時把retain設(shè)置為true，即為保留信息。每個Client訂閱Topic后會立即讀取到retain消息。如果需要刪除retain消息，可以發(fā)布一個空的retain消息，因為每個新的retain消息都會覆蓋最后一個retain消息。

最后遺囑 Last Will & Testament

MQTT本身就是為信號不穩(wěn)定的網(wǎng)絡(luò)設(shè)計的，所以難免一些客戶端會無故的和Broker斷開連接。 當(dāng)客戶端連接到Broker時，可以指定LWT，Broker會定期檢測客戶端是否有異常。 當(dāng)客戶端異常掉線時，Broker就往連接時指定的topic里推送當(dāng)時指定的LWT消息。

4.消息服務(wù)質(zhì)量

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

4.1“至多一次”

至多一次

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

4.2“至少一次”

至少一次

PUBACK消息是對QoS級別為1的PUBLISH消息的響應(yīng).PUBACK消息由服務(wù)器發(fā)送以響應(yīng)來自發(fā)布端的PUBLISH消息，訂閱端也會響應(yīng)來自服務(wù)器的PUBLISH消息。當(dāng)發(fā)布端收到PUBACK消息時，它會丟棄原始消息，因為它也被服務(wù)器接收（并記錄）。

如果一定時間內(nèi)，發(fā)布端或服務(wù)器沒有收到PUBACK消息，則會進(jìn)行重發(fā)。這種方式雖然確保了消息到達(dá)，但消息重復(fù)可能會發(fā)生。

4.3“只有一次”

只有一次

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

PUBREL消息是從發(fā)布端對PUBREC的響應(yīng)，或從服務(wù)器對訂閱端PUBREC消息的響應(yīng)。 這是QoS 2協(xié)議流中第三個消息。當(dāng)服務(wù)器從發(fā)布者收到PUBREL消息時，服務(wù)器會將PUBLISH消息發(fā)送到訂閱端，并發(fā)送PUBCOMP消息到發(fā)布端。 當(dāng)訂閱端收到來自服務(wù)器的消息PUBREL時，使得消息可用于應(yīng)用程序并將PUBCOMP消息發(fā)送到服務(wù)器。

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

在一些要求比較嚴(yán)格的計費系統(tǒng)中，可以使用此級別。在計費系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果。這種最高質(zhì)量的消息發(fā)布服務(wù)還可以用于即時通訊類的APP的推送，確保用戶收到且只會收到一次。