物聯網協議MQTT淺談

阿新 • • 發佈：2019-02-13

第一部分物聯網的組成
第二部分常見物聯網通訊協議比較
第三部分 MQTT協議及開源實現
第四部分 IOT架構及裝置接入實踐

1.物聯網的組成

生活中常見的共享單車、智慧手環、智慧家居等都是物聯網的實際引用。物聯網最初在
1999年提出：即通過射頻識別（ RFID）、紅外感應器、全球定位系統、鐳射掃描器、氣體感應
器等資訊感測裝置，按約定的協議，把任何物品與網際網路連線起來，進行資訊交換和通訊，以
實現智慧化識別、定位、跟蹤、監控和管理的一種網路。簡而言之，物聯網就是“物物相連的

網際網路”。

物聯網組成一般包括：
(1)裝置通常含有各種感測器，如影象感測器、光學感測器、溫度感測器、溼度感測器、加速
度感測器、磁場感測器等。
(2)網路近距離通訊(藍芽、 RFID、 NFC)，遠距離蜂窩通訊(GSM、 WCDMA、 LTE、 NB-IOT)，遠距
離非蜂窩通訊(WiFi、 ZigBee)，有線通訊。
(3)物聯網服務資料的接收與傳送，資料的處理與儲存。

以膜拜單車開鎖流程為例，膜拜智慧鎖開鎖流程：

1.開啟膜拜APP掃描單車二維碼
2.識別二維碼後自動向雲端傳送解鎖請求
3.雲端系統識別使用者資訊、校驗單車情況等
4.業務處理成功後雲端系統向智慧鎖傳送解鎖
5.智慧鎖執行開鎖命令，並上報開鎖結果
6.膜拜APP開鎖進度更新，並開始計費
7.單車定時上報位置資訊， APP端更新行駛

2.常見物聯網通訊協議比較

IOT網路中，通常裝置和網路是受限的。因此在選擇資料通訊協議時需要考慮裝置的計算、

儲存、能耗，窄頻寬和網路不穩定等因素。常見的資料通訊協議有： HTTP、 XMPP、 COAP、 MQTT。

2.1.HTTP

自1990年出現的HTTP協議作為web的標準協議已被廣泛使用，在物聯網中同樣可以採用HTTP協議。例如手機、 PC等終端裝置。但是作為適應瀏覽器場景的HTTP協議，並不適用於物聯網的其他備。
適用範圍：開放物聯網中資源，實現服務被其他應用所呼叫。

優勢：
1.簡單的工作模式，請求/響應
2.完整的方法定義。
3.合理的狀態碼設計

4.友好的媒體型別支援。文字、圖片、視訊

缺點：
1.單向傳輸，可以通過客戶端輪詢實現類似推送效果或者HTTP 2.0。
2.安全性不高， HTTP是明文協議，可以使用HTTPS傳輸
3.HTTP是文字協議，冗長的協議頭部，對於運算、儲存、頻寬資源受限的裝置來說開銷大。

2.2.XMPP(Extensible Messaging and Presence Protocol可擴充套件訊息與存在協議)

XMPP的前身是Jabber開源社群於1999年開發的Jabber協議，用於即時通訊、狀態資訊(比如即時通訊客戶端顯示使用者線上、忙碌、視訊中等)、通訊錄管理。通過類似郵箱地址的JID進行定址(如

[email protected])

適用範圍：即時通訊的應用程式，還能用在網路管理、協同工具、檔案共享、遊戲、遠端系統監控等。

優勢：
1.去中心化，類似於郵件網路架構。
2.安全，支援SASL安全認證和TLS加密。
3.靈活，基於XML的資料格式可以自定義功能。

4.應用廣泛，眾多的客戶端、服務端實現。

缺點：
1.不支援服務質量(Qos)
2.基於文字協議的通訊帶來高的網路負載
3.二進位制資料傳輸支援較差

2.3.CoAP (Constrained Application Protocol 受限的應用協議)

CoAP是為了讓低功耗受限裝置可以接入網際網路，由IETF組織制定的，它借鑑了HTTP大量成功經驗，同樣使用請求/響應工作模式。

適用範圍：適用於區域網環境下一對一M2M通訊。

優勢：
1.採用和HTTP相似語義的請求和響應碼，並使用二進位制報文減小了報文大小
2.傳輸層基於UDP協議，比TCP資料包小，並不需要建立連線帶來握手的開銷

3.資源發現支援，通過觀察者模式實現類似釋出/訂閱效果

缺點：
1.基於UDP的不可靠傳輸，但通過四種報文型別的組合及重傳機制提高傳輸的可靠性。
2.基於UDP的無連線傳輸，不利於不同網路間訊息的回傳。

2.4.MQTT (Message Queuing Telemetry Transport 訊息佇列遙測傳輸)

MQTT協議最初由IBM公司於1999年開發，用於將石油管道上的感測器與衛星相連線。 2014年正式成為OASIS開放標準。MQTT使用類似MQ常用的釋出/訂閱模式，起到應用程式解耦，非同步訊息，削峰填谷的作用。很多MQ中介軟體也支援MQTT協議，比如ActiveMQ、 RabbitMQ、 HiveMQ、 WebSphereMQ等。

適用範圍：在低頻寬、不可靠的網路下提供基於雲平臺的遠端裝置的資料傳輸和監控。

優勢：
1.使用釋出/訂閱模式，提供一對多的訊息釋出，使訊息傳送者和接收者在時間和空間上解耦。
2.二進位制協議，網路傳輸開銷非常小(固定頭部是2位元組)。
3.靈活的Topic訂閱、 Qos、臨終遺言等特性。
缺點：
1.集中化部署，服務端壓力大，需要考慮流程控制及高可用。

2.對於請求/響應模式的支援需要在應用層根據訊息ID做釋出主題和訂閱主題之間的關聯

總體來看， HTTP和XMPP網路開銷大， CoAP和MQTT更適合物聯網受限環境中裝置的通訊。從市場應用層面看， MQTT發展相對成熟、應用相對廣泛，也比較適合裝置的遠端監控與管理。

3. MQTT協議簡介及開源實現
MQTT是基於釋出訂閱模式的，有主題過濾器、 Qos保證、臨終遺言、 Session持久化

等特性，下面我們一起通過報文來了解一下吧。

3.1.MQTT工作模式

3.2.MQTT協議報文組成(基於v3.1.1)

可變頭和訊息體根據不同報文型別而不同，可以看出：

1.MQTT協議最小報文僅有2個位元組(只有固定頭且剩餘長度為1個位元組)，如心跳報文PINGREQ、PINGRESP

2.報文型別最多2^4=16。目前共有14種報文型別， 2個保留型別。下面著重看下連線、釋出、訂閱相關報文。

3.3.CONNECT報文整體結構

CONNECT報文的可變頭中存在以下非常重要的標誌位。

1.Clean Session

作用：該標誌用於指定客戶端連線到服務端後，是否清除之前持久化的session資訊(如果存在)，並且當連線斷開後是否持久化本次會話的session資訊。

場景：由於網路等原因造成裝置臨時下線，當裝置重新連線服務端時，如果上次連線Clean
Session=1則之前訂閱的主題及裝置下線期間傳送的訊息就會丟失，如果需要裝置下線期間訊息

不丟失可以設定Clean Session=0。

Session中儲存資訊有哪些？
1.ClientId用於識別客戶端
2.客戶端的訂閱的主題
3.已經發送或正在傳送到客戶端的Qos1和Qos2訊息，還沒有完全確認(發給訂閱者)
4.已經接收到客戶端傳送的Qos2訊息，還沒有完全確認(接收發布者)
5.在傳送中的Qos0訊息(可選)
2.Will Flag
作用：客戶端連線異常斷開時觸發服務端向訂閱客戶端傳送訊息通知。

場景：由於網路異常導致客戶端下線，可使用臨終遺囑通知訂閱了該遺囑topic的客戶端，從而進行應對處理。

當Will Flag=1，連線建立後，服務端會儲存Will Message。當網路連線關閉後(除服務端接收到DISCONNECT報文外)，遺囑訊息會被髮布。服務端釋出遺囑訊息時按照Will Qos和Will Retain(是否保留訊息)標誌位釋出。

3.Will Qos(服務質量)

MQTT支援三種服務質量等級：

Qos0:至多一次交付訊息。接收方能否接收到訊息完全依賴於網路傳輸情況。一般用於實時性較高的情況下，如感測器傳送當前溫度資料，如果丟失一次資料也沒有影響，因為馬上會有最新的資料到來。

Qos1:至少一次交付訊息。接收方可能接收到重複訊息。應用於確保訊息到達，並有冪等處理的系統。

Qos2:準確一次交付訊息。接收方只能接收到一次訊息。應用於比較嚴格的如計費系統，重複或者丟失資料都會導致不正確的結果。
需要注意的是Qos保證不是端到端的，而是客戶端和伺服器之間的。訂閱者收到MQTT訊息
的Qos級別，取決於釋出訊息的Qos和訂閱主題的Qos，當二者不同是，會產生降級，以最低的

Qos級別為準。

4.Retain
作用：儲存客戶端最新發布的訊息。
場景：通常情況下，訂閱者需要在釋出者釋出訊息前訂閱。使用Retain標誌位可以在服務端保
留最新的訊息，當新的客戶端訂閱相關主題時可以立即收到該主題上的最新訊息。
3.4.PUBLISH報文整體結構

1.PUBLISH報文固定頭中有三個重要的標誌位，其中Qos、 RETAIN和前面介紹的CONNECT報文可變頭中標誌位語義相同。

DUP flag是報文重傳標誌，在Qos1和Qos2的報文重傳過程中會把DUP flag置為1。

2.不同Qos報文傳送的過程

(1)Qos0 訊息釋出流

(2)Qos1 訊息釋出流

(3)Qos2 訊息釋出流

3.5.SUBSCRIBE報文整體結構

訂閱和釋出都是針對topic的， topic根據”/” 分隔為不同的層級。一個PUBLISH報文中只能有一個topic，一個SUBCRIBE報文中可以有多個topic filter。 topic filter中可以使用萬用字元。

多層級萬用字元#
(1)可以匹配父層級主題和任意數量子層級主題

(2)必須是主題過濾器的最後一個字元

單層級萬用字元-
(1)匹配一個層級

(2)可以出現在主題過濾器的任意位置，也可以和#搭配使用

特殊情況：以#或+萬用字元開頭的topic filter不匹配以$開頭的主題。通常以$SYS/字首的主題用於獲取伺服器相關的資訊或者是控制API

3.6.MQTT的開源實現

1.客戶端 Eclipse Paho 支援Java、 C/C++、 Python、 Go、 JavaScript、 Rust

2.服務端 mosquitto、 emqttd、 Apache ActiveMQ、 RabbitMQ

4.IOT架構及裝置接入實踐

4.1.IOT架構

目前，業界像BAT公司都提供了基於自家雲服務的IOT接入整套解決方案，如裝置接入、通
信與管理，安全認證，裝置影子，訊息儲存與分析計算等。大體架構如下：

4.1.裝置影子

在IOT平臺中除了提供MQTT服務端外，還有一個重要概念——裝置影子。裝置影子是一個

JSON文件，用於儲存裝置上報狀態、應用程式期望狀態資訊。

場景1：裝置在不穩定網路中頻繁上下線，應用程式可能無法獲取到裝置最新狀態資訊。
裝置在狀態變化時儲存最新狀態資訊到裝置影子中，則應用程式從影子中獲取裝置狀態即可。
場景2：應用程式多次請求獲取裝置狀態，增加了裝置的負載。使用裝置影子減小裝置的
壓力。
場景3：應用程式傳送指令給裝置，由於網路不穩定，指令可能無法到達。若使用Qos1或2
則增加服務端的壓力，將指令加時間戳存在影子中，裝置上線時根據時間戳來判斷是否執行指

令。

4.2.IOT裝置接入實踐
百度天工、阿里物接入等
4.3.Clean Session 實踐
1.客戶端連線時不勾選CleanSession，則CleanSession=false(0)

2.這裡使用emq broker，可以看到，服務端有一個session

3.斷開客戶端連線(如下圖)，發現服務端session還存在(如上圖所示)， subscription也存在

4.再開啟一個客戶端作為釋出者，向/temperature主題釋出訊息；訂閱者客戶端重新連線後，開啟訂閱者log日誌，可以看雖然沒有重新訂閱/temperature，但訂閱者依然可以收到訊息。

物聯網協議MQTT淺談

物聯網協議MQTT淺談

物聯網協議 MQTT

物聯網之MQTT 協議

物聯網協議 HTTP libcurl

【http協議】淺談

MQTT是IBM開發的一個即時通訊協議，構建於TCP/IP協議上，是物聯網IoT的訂閱協議，借助消息推送功能，可以更好地實現遠程控制

物聯網MQTT協議分析和開源Mosquitto部署驗證

【物聯網雲端對接-4】通過MQTT協議與百度雲進行雲端通信

物聯網通信協議——比較-MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP

淺談物聯網的關鍵技術和難點

使用nodeMCU平臺mqtt協議實現物聯網通訊

淺談物聯網革命對未來ITSM工作方式的影響

MQTT協議與阿里雲IoT物聯網平臺

通過網路抓包學習物聯網流行協議（MQTT）

【物聯網雲端對接-4】通過MQTT協議與百度雲進行雲端通訊

物聯網Mqtt協議使用(1)

工業物聯網的雲端協議將以MQTT+SSL/TLS為主，協議格式以JSON為主

閘道器正式支援MQTT物聯網通訊協議,PLC到MQTT，一個閘道器即可

物聯網接入協議-MQTT

物聯網MQTT協議

物聯網協議MQTT淺談

相關推薦