物聯(lián)網(wǎng)協(xié)議MQTT協(xié)議的實(shí)現(xiàn)

概述

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

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

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

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

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

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

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

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

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

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

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

2.1訂閱（Subscription）

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

2.2會(huì)話（Session）

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

2.3主題名（Topic Name）

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

2.4主題篩選器（Topic Filter）

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

2.5負(fù)載（Payload）

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

3.保留消息和最后遺囑

保留消息 Retained Messages

MQTT中，無(wú)論是發(fā)布還是訂閱都不會(huì)有任何觸發(fā)事件。 1個(gè)Topic只有唯一的retain消息，Broker會(huì)保存每個(gè)Topic的最后一條retain消息。 發(fā)布消息時(shí)把retain設(shè)置為true，即為保留信息。每個(gè)Client訂閱Topic后會(huì)立即讀取到retain消息。如果需要?jiǎng)h除retain消息，可以發(fā)布一個(gè)空的retain消息，因?yàn)槊總€(gè)新的retain消息都會(huì)覆蓋最后一個(gè)retain消息。

最后遺囑 Last Will & Testament

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

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

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

4.1“至多一次”

至多一次

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

4.2“至少一次”

至少一次

PUBACK消息是對(duì)QoS級(jí)別為1的PUBLISH消息的響應(yīng).PUBACK消息由服務(wù)器發(fā)送以響應(yīng)來(lái)自發(fā)布端的PUBLISH消息，訂閱端也會(huì)響應(yīng)來(lái)自服務(wù)器的PUBLISH消息。當(dāng)發(fā)布端收到PUBACK消息時(shí)，它會(huì)丟棄原始消息，因?yàn)樗脖环?wù)器接收（并記錄）。

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

4.3“只有一次”

只有一次

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

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

PUBCOMP消息是服務(wù)器對(duì)來(lái)自發(fā)布端的PUBREL消息的響應(yīng)，或訂閱者對(duì)來(lái)自服務(wù)器的PUBREL消息的響應(yīng)。 它是QoS 2協(xié)議流程中的第四個(gè)也是最后一個(gè)消息。當(dāng)發(fā)布端收到PUBCOMP消息時(shí)，它會(huì)丟棄原始消息，因?yàn)樗呀?jīng)將消息發(fā)給了服務(wù)器。

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