mqtt協議
MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸協議),是一種基于發布/訂閱(publish/subscribe)模式的“輕量級”通訊協議,該協議構建于TCP/IP協議上,由IBM在1999年發布。
MQTT最大優點在于,用極少的代碼和有限的帶寬,為連接遠程設備提供實時可靠的消息服務。
作為一種低開銷、低帶寬占用的即時通訊協議,使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。
1 MQTT協議特點
MQTT是一個基于客戶端-服務器的消息發布/訂閱傳輸協議。
MQTT協議是輕量、簡單、開放和易于實現的,這些特點使它適用范圍非常廣泛。在很多情況下,包括受限的環境中,如:機器與機器(M2M)通信和物聯網(IoT)。
其在,通過衛星鏈路通信傳感器、偶爾撥號的醫療設備、智能家居、及一些小型化設備中已廣泛使用。
MQTT協議當前版本為,2014年發布的MQTT v3.1.1。除標準版外,還有一個簡化版MQTT-SN,該協議主要針對嵌入式設備,這些設備一般工作于TCP/IP網絡,如:ZigBee。
MQTT 與 HTTP 一樣,MQTT 運行在傳輸控制協議/互聯網協議 (TCP/IP) 堆棧之上。
MQTT OSI
發布和訂閱
MQTT使用的發布/訂閱消息模式,它提供了一對多的消息分發機制,從而實現與應用程序的解耦。
這是一種消息傳遞模式,消息不是直接從發送器發送到接收器(即點對點),而是由MQTT server(或稱為 MQTT Broker)分發的。
MQTT 服務器是發布-訂閱架構的核心。
它可以非常簡單地在Raspberry Pi或NAS等單板計算機上實現,當然也可以在大型機或 Internet 服務器上實現。
服務器分發消息,因此必須是發布者,但絕不是訂閱者!
客戶端可以發布消息(發送方)、訂閱消息(接收方)或兩者兼而有之。
客戶端(也稱為節點)是一種智能設備,如微控制器或具有 TCP/IP 堆棧和實現 MQTT 協議的軟件的計算機。
消息在允許過濾的主題下發布。主題是分層劃分的 UTF-8 字符串。不同的主題級別用斜杠/作為分隔符號。
我們來看看下面的設置。
這就是一個簡單的MQTT的應用場景,具體如下圖所示;
MQTT 發布和訂閱
QoS(Quality of Service levels)
服務質量是 MQTT 的一個重要特性。當我們使用 TCP/IP 時,連接已經在一定程度上受到保護。但是在無線網絡中,中斷和干擾很頻繁,MQTT 在這里幫助避免信息丟失及其服務質量水平。這些級別在發布時使用。如果客戶端發布到 MQTT 服務器,則客戶端將是發送者,MQTT 服務器將是接收者。當MQTT服務器向客戶端發布消息時,服務器是發送者,客戶端是接收者。
QoS 0
這一級別會發生消息丟失或重復,消息發布依賴于底層TCP/IP網絡。即:<=1
QoS 1
QoS 1 承諾消息將至少傳送一次給訂閱者。
QoS 2
使用 QoS 2,我們保證消息僅傳送到目的地一次。為此,帶有唯一消息 ID 的消息會存儲兩次,首先來自發送者,然后是接收者。QoS 級別 2 在網絡中具有最高的開銷,因為在發送方和接收方之間需要兩個流。
2 MQTT 數據包結構
固定頭(Fixed header),存在于所有MQTT數據包中,表示數據包類型及數據包的分組類標識;
可變頭(Variable header),存在于部分MQTT數據包中,數據包類型決定了可變頭是否存在及其具體內容;
消息體(Payload),存在于部分MQTT數據包中,表示客戶端收到的具體內容;
整體MQTT的消息格式如下圖所示;
2.1 MQTT固定頭
固定頭存在于所有MQTT數據包中,其結構如下:
下面簡單分析一下固定頭的消息格式;
MQTT消息類型 / message type
**位置:**byte 1, bits 7-4。
4位的無符號值,類型如下:
標識位 / DUP
**位置:**byte 1, bits 3-0。
在不使用標識位的消息類型中,標識位被作為保留位。如果收到無效的標志時,接收端必須關閉網絡連接:
00:最多一次,即:<=1
01:至少一次,即:>=1
10:一次,即:=1
11:預留
剩余長度(Remaining Length)
位置:byte 1。
固定頭的第二字節用來保存變長頭部和消息體的總大小的,但不是直接保存的。這一字節是可以擴展,其保存機制,前7位用于保存長度,后一部用做標識。當最后一位為 1時,表示長度不足,需要使用二個字節繼續保存。例如:計算出后面的大小為0
2.2 MQTT可變頭 / Variable header
MQTT數據包中包含一個可變頭,它駐位于固定的頭和負載之間。可變頭的內容因數據包類型而不同,較常的應用是做為包的標識:
RETAIN:發布保留標識,表示服務器要保留這次推送的信息,如果有新的訂閱者出現,就把這消息推送給它,如果設有那么推送至當前訂閱者后釋放。
QoS發布消息的服務質量(前面已經做過介紹),即:保證消息傳遞的次數
DUP:發布消息的副本。用來在保證消息的可靠傳輸,如果設置為 1,則在下面的變長中增加MessageId,并且需要回復確認,以保證消息傳輸完成,但不能用于檢測消息重復發送。
很多類型數據包中都包括一個2字節的數據包標識字段,這些類型的包有:
PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、
SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK
2.3 Payload消息體
Payload消息體是MQTT數據包的第三部分,CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息 有消息體:
3 環境搭建
介紹完基礎理論部分,下面在Windows平臺上搭建一個簡單的MQTT應用,進行簡單的應用,
3.1 MQTT服務器搭建
目前MQTT代理的主流平臺有下面幾個:
本文將使用 Mosquitoo 進行測試,進入到安裝頁面,下載自己電腦的系統所適配的程序;
UNSUBSCRIBE,消息體內容是要訂閱的主題。
SUBACK,消息體內容是服務器對于SUBSCRIBE所申請的主題及QoS進行確認和回復。
SUBSCRIBE,消息體內容是一系列的要訂閱的主題以及QoS。
CONNECT,消息體內容主要是:客戶端的ClientID、訂閱的Topic、Message以及用戶名和密碼
下載頁面
安裝成功之后,進入到安裝路徑下,找到mosquitto.exe;
按住Shift,右鍵鼠標點擊空白處,然后打開Powershell,正常打開一個終端軟件即可;
輸入./mosquitto.exe -p 10086,就開啟了MQTT服務,監聽的地址是127.0.0.1,端口是10086;
輸入./mosquitto.exe -h 可以查看相應的幫助;
具體如下圖所示;
3.2 MQTT Client
服務器搭建好了,下面就是開啟客戶端,進行發布和訂閱,這樣就可以傳輸相應的消息。
這里我使用的是自己編譯了一個QT mqtt client 程序,是基于Qt的官方庫進行編譯的,下面打開這個軟件,下一期簡單介紹一下如何完成這個客戶端,并設置好相應參數:
然后訂閱主題,就可以互相發送數據了,具體如下圖所示;
端口:10086
地址:127.0.0.1
結合前面的圖片來看,整體的架構如下所示;
4 總結
本文簡單介紹了MQTT協議的工作原理,以及相應的協議格式,簡單介紹了協議的一些細節,具體舉出了相應的應用場景,作者水平和能力有限,文中難免存在錯誤和紕漏,請大佬不吝賜教。
審核編輯:劉清
-
WINDOWS
+關注
關注
4文章
3598瀏覽量
90692 -
TCPIP協議
+關注
關注
0文章
35瀏覽量
12136 -
MQTT協議
+關注
關注
0文章
98瀏覽量
5731
發布評論請先 登錄
相關推薦
mqtt協議怎么用?以MQTT3.1協議ESP8266連接阿里云物聯網平臺

[MicroPython]TPYBoard v202 MQTT協議2:上傳數據點到OneNET平臺
怎么在HI3516DV300上移植一個MQTT?
怎樣通過MQTT協議向onenet平臺推送數據呢
基于Dragonboard 410c開發板android平臺上搭建kinect運行環境
物聯網通信協議之MQTT協議介紹MQTT協議測試環境如何搭建及分析

評論