MQTT協議詳解
1 術語定義
客戶端 Client:
· 釋出應用訊息給其它相關的客戶端。
· 訂閱以請求接受相關的應用訊息。
· 取消訂閱以移除接受應用訊息的請求。
·
服務端 Server:
· 接受來自客戶端的網路連線。
· 接受客戶端釋出的應用訊息。
· 處理客戶端的訂閱和取消訂閱請求。
· 轉發應用訊息給符合條件的已訂閱客戶端
訂閱 Subscription
訂閱包含一個主題過濾器(Topic Filter)和一個最大的服務質量(QoS)等級。訂閱與單個會話(Session)關聯。會話可以包含多於一個的訂閱。會話的每個訂閱都有一個不同的主題過濾器。
主題名 Topic Name:
附加在應用訊息上的一個標籤,服務端已知且與訂閱匹配。服務端傳送應用訊息的一個副本給每一個匹配的客戶端訂閱。
主題過濾器 Topic Filter:
訂閱中包含的一個表示式,用於表示相關的一個或多個主題。可以使用萬用字元。
會話 Session:
客戶端和服務端之間的狀態互動。一些會話持續時長與網路連線一樣,另一些可以在客戶端和服務端的多個連續網路連線間擴充套件。
2 MQTT報文結構
Bit |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
byte 1 |
報文型別(14種) |
DUP |
Qos(3種) |
RETAIN |
||||
byte 2 |
剩餘長度=可變報頭長度+有效載荷長度 |
|||||||
byte 3 |
可變報頭(此處舉例子5個位元組,實際根據報文型別決定) |
|||||||
byte 4 byte 5 |
||||||||
byte 6 |
||||||||
byte 7 |
有效載荷 |
2.1 報文型別
協議型別 |
值 |
描述 |
Reserved |
0 |
保留 |
CONNECT |
1 |
客戶端請求連線服務端 |
CONNACK |
2 |
連線報文確認 |
PUBLISH |
3 |
釋出訊息 |
PUBACK |
4 |
釋出訊息確認 |
PUBREC |
5 |
釋出收到(保證交付第一步) |
PUBREL |
6 |
釋出釋放(保證交付第二步) |
PUBCOMP |
7 |
QoS 2訊息釋出完成(保證互動第三步) |
SUBSCRIBE |
8 |
客戶端訂閱請求 |
SUBACK |
9 |
訂閱請求報文確認 |
UNSUBSCRIBE |
10 |
取消訂閱報文請求 |
UNSUBACK |
11 |
取消訂閱報文確認 |
PINGREQ |
12 |
心跳請求 |
PINGRESP |
13 |
心跳確認 |
DISCONNECT |
14 |
斷開連線 |
Reserved |
15 |
保留 |
2.2 DUP描述
DUP Value |
描述 |
0 |
訊息第一次傳輸 |
1 |
訊息已經傳輸過一次,現在是再次傳輸。但是不能作為Qos=1重複的檢測依據 |
2.3 Qos Level描述
Qos Level |
bit 2 |
bit 1 |
描述 |
0 |
0 |
0 |
至多一次傳輸,不能保證訊息到達伺服器,客戶端發完就釋放 |
1 |
0 |
1 |
伺服器接收到訊息會被確認,通過傳輸一個PUBACK資訊。如果有一個可以辨認的傳輸失敗,無論是通訊連線還是傳送裝置,還是過了一段時間確認資訊沒有收到,傳送方都會將訊息頭的DUP位置1,然後再次傳送訊息。訊息最少一次到達伺服器。 |
2 |
1 |
0 |
準確傳輸一次。在QoS level 1上附加的協議流保證了重複的訊息不會傳送到接收的應用 |
2.4 訊息保留描述(RETAIN)
RETAIN |
描述 |
0 |
僅僅為當前訂閱者推送此訊息。 |
1 |
表示傳送的訊息需要一直持久儲存(不受伺服器重啟影響),不但要傳送給當前的訂閱者,並且以後新來的訂閱了此Topic name的訂閱者會馬上得到推送。 |
2.5 剩餘長度
剩餘長度為變長位元組編碼方案。每個位元組的最高位為1則代表後面還跟有一個長度位元組,為0則表示長度位元組到此結束。長度位元組標識的長度為可變報頭和有效載荷的長度。剩餘長度位元組最多為4個。可表示的位元組範圍如下:
Digits |
From |
To |
1 |
0 (0x00) |
127 (0x7F) |
2 |
128 (0x80, 0x01) |
16 383 (0xFF, 0x7F) |
3 |
16 384 (0x80, 0x80, 0x01) |
2 097 151 (0xFF, 0xFF, 0x7F) |
4 |
2 097 152 (0x80, 0x80, 0x80, 0x01) |
268 435 455 (0xFF, 0xFF, 0xFF, 0x7F) |
2.6 可變報頭(CONNECT報文)
可變報頭是隨著報文協議不同而變化的。這裡詳細著重介紹CONNECT報文,CONNECT報文的可變報頭按下列次序包含四個欄位:協議名(Protocol Name),協議級別(Protocol Level),連線標誌(Connect Flags)和保持連線(Keep Alive)。
Protocol Name:協議名是表示協議名 MQTT 的UTF-8編碼的字串,如果定義有誤的話,服務端會拒絕客戶端的連線請求。
Protocol Level:客戶端用8位的無符號值表示協議的修訂版本。對於3.1.1版協議,協議級別欄位的值是4(0x04)。如果發現不支援的協議級別,服務端必須給傳送一個返回碼為0x01(不支援的協議級別)的CONNACK報文響應CONNECT報文,然後斷開客戶端的連線
Clean session :
0 |
server需要儲存client的訂閱。包括儲存Qos 1和2的訂閱主題(當client重連時能將訊息傳送);當連線丟失的時候 伺服器必須維護正在傳送的訊息的狀態直到客戶端重新連線到伺服器。 |
1 |
server MUST忽略之前維護關於client的資訊,並且將該connection當成clean的。server MUST 忽略任何client斷開的狀態。 |
Will Flag:
在自己異常斷開的情況下,一個由客戶端預先定義好的主題和對應訊息,附加在CONNECT的可變頭部中,在客戶端連接出現異常的情況下,由伺服器主動釋出此訊息。
Will Qos:
兩位表示,和PUBLISH訊息固定頭部的QoS level含義一樣。
若標識了Will Flag值為1,那麼Will QoS就會生效,否則會被忽略掉。
Will RETAIN:
如果設定Will Flag,Will Retain標誌就是有效的,否則它將被忽略。
當客戶端意外斷開伺服器釋出其Will Message之後,伺服器是否應該繼續儲存。
User name 和password Flag:
用於授權,兩者要麼為0要麼為1,否則都是無效。都為0,表示客戶端可自由連線/訂閱,都為1,表示連線/訂閱需要授權。
2.7 有效載荷
有效載荷有可變報頭部分決定,例如CONNECT報文中可變報頭ConnectFlags中定義了Username 和password Flag,則此部分會附加使用者名稱和密碼字串
3 報文互動介紹