回答:
報文是網(wǎng)絡(luò)中交換和傳輸?shù)臄?shù)據(jù)單元,也是網(wǎng)絡(luò)傳輸?shù)膯卧?。報文包含了將要發(fā)送的完整的數(shù)據(jù)信息,其長短不需一致。報文在傳輸過程中會不斷地封裝成分組、包、幀來傳輸,封裝的方式就是添加一些控制信息組成的首部,那就是報文頭。
mqtt協(xié)議報文結(jié)構(gòu)
固件報頭Fixed header
最多一次(0), 發(fā)出去了就不管了
至少一次(1),發(fā)出必須要等接收方回復(fù)ack,沒有回復(fù),那么就找時機重發(fā),接收方需要處理去重
準(zhǔn)確一次(2),保證只發(fā)一次,需要持久化,重復(fù)消息自動去重,并且只有當(dāng)接收方把消息投遞出去,才算完成
控制報文的類型 Control Packet type,14種有效類型: [connect, publish, subscribe,.....]
第一個1個字節(jié)前4位,
標(biāo)志Flags,
第一個1個字節(jié)后4位,
DUP 控制報文是否為重復(fù)報文,只有PUBLISH才會有DUP為1的情況,其他的報文類型都是0
QoS 控制PUBLISH報文的質(zhì)量等級,
publish
publish - pubrec
publish - pubrec - pubrel - pubcomp
RETAIN,
每個topic只有唯一的保留消息,每個client訂閱的時候,會立刻讀取到保留消息
如果訂閱者無法與broker連接,可以通過retain消息,讓訂閱者下次連接訂閱成功時一次接受所有的內(nèi)容
發(fā)布者定時發(fā)布retain消息,訂閱者可以根據(jù)retain消息的變化推測發(fā)布者狀態(tài)
剩余長度 Remaining Length
從第二個字節(jié)開始,最大長度是4個字節(jié),低位在前,高位在后,通過每一個字節(jié)第一位[0不需要,1需要]確定是否需要繼續(xù)往后繼續(xù)計算,也就是最多可以存儲256M, 最大值16進制為:0xFF,0xFF,0xFF,0x7F
可變報頭Variable header
可變報文部分是根據(jù)不同的報文類型,這部分的內(nèi)容也不同
比如: 連接報文會有用戶名密碼標(biāo)識,遺囑標(biāo)識,是否清理會話標(biāo)識等,發(fā)布報文會有topic信息
報文標(biāo)識符 PackageIdentifier [messageId]
標(biāo)識符作用:
2個字節(jié)最大65535
這些報文類型需要:PUBLISH(QoS > 0), PUBACK, PUBREL, PUBCOMP, SUBSCRIBE,SUBACK, UNSUSCRIBE,UNSUBACK
重發(fā)使用相同的標(biāo)識符
確認(rèn)后釋放標(biāo)識符
有效載荷Payload
以下這些報文類型才有payload:
CONNECT(用戶名密碼,遺囑消息,遺囑topic,客戶端標(biāo)識),
PUBLISH(可有可無,根據(jù)實際情況),
SUBSCRIBE(訂閱的topic信息集合),
SUBACK(按順序返回的訂閱的topic的報文質(zhì)量等級集合)
UNSUBSCRIBE(取消訂閱的topic信息集合)
報文類型處理邏輯(接收方的處理邏輯)
CONNECT 連接服務(wù)端 客戶端--服務(wù)端
報文解析錯誤:
如果報文解析錯誤,連接失敗
如果解析的報文標(biāo)識符不合法,連接失敗
報文解析成功
重發(fā)QoS1的未完成的消息
重發(fā)QoS2的未完成的消息
連接成功,保存會話信息
連接成功,回會CONNACK報文給客戶端
如果之前保存的會話信息,cleanSession == true,需要清空保存的session,訂閱信息,需要重發(fā)的發(fā)布QoS1報文,需要重發(fā)的發(fā)布的QoS2的報文
關(guān)閉之前的保存的會話
如果報文標(biāo)識符不存在,連接失敗
如果用戶密碼驗證失敗,連接失敗
如果是會話中已經(jīng)存在該連接,說明是發(fā)送重復(fù)的連接報文
檢查心跳包,將已經(jīng)存在的心跳包的間隔時間,更新成客戶端指定的時間
如果連接報文中存在遺囑消息,需要將遺囑消息保存在本次連接的會話對象中
如果本次連接的報文cleanSession == false,也就是不清理會話,如果是客戶端重連的,可能存在服務(wù)端有部分信息沒有發(fā)送出去,需要重新發(fā)送給該客戶端
CONNACK 確認(rèn)連接請求 服務(wù)端--客戶端
客戶端確認(rèn)連接成功
PUBLISH 發(fā)布消息 雙向
客戶端發(fā)送給服務(wù)端,是為了將報文分發(fā)到其他訂閱匹配的客戶端
服務(wù)端發(fā)送給客戶端,是為了發(fā)消息給匹配訂閱的客戶端
根據(jù)不同的質(zhì)量等級進行不同的回復(fù)報文
QoS 0 直接publish消息即可
QoS 1 PUBLISH消息之后,還需要回復(fù)PUBACK給來源客戶端
Qos 2 PUBLISH消息之后,還需要回復(fù)PUBREC給來源客戶端 (后續(xù)客戶端端發(fā)送PUBREL,再服務(wù)端發(fā)送PUBCOMP完成整個生命周期)
如果是保留消息,需要覆蓋之前保存的保留消息
PUBACK 發(fā)布確認(rèn) 雙向
帶著messageId回復(fù)發(fā)布方,通知發(fā)布成功
PUBAREC 發(fā)布收到 雙向
帶著messageId回復(fù)發(fā)布方,通知收到了發(fā)布報文
PUBREL 發(fā)布釋放 雙向
帶著messageId回復(fù)接收方,可以釋放報文
PUBCOMP 發(fā)布完成 雙向
帶著messageId回復(fù)發(fā)布方,可以發(fā)布完成了
SUBSCRIBE 訂閱主題 客戶端--服務(wù)端
根據(jù)訂閱的主題列表,
保存訂閱信息
回復(fù)SUBACK,按順序返回訂閱報文中的報文質(zhì)量等級集合
根據(jù)訂閱的主題,處理服務(wù)端保留信息,立即PUBLISH給客戶端
SUBACK 訂閱確認(rèn) 服務(wù)端-- 客戶端
客戶端確認(rèn)訂閱成功
UNSUBSCRIBE 取消訂閱 客戶端--服務(wù)端
移除掉該客戶端保存的訂閱主題
回復(fù)UNSUBACK報文
UNSUBACK 訂閱確認(rèn) 服務(wù)端-- 客戶端
客戶端確認(rèn)取消訂閱成功
PINGREQ 心跳請求 客戶端--服務(wù)端
返回客戶端PINGRESP報文
PINGRESP 心跳響應(yīng) 服務(wù)端--客戶端
收到報文確認(rèn)服務(wù)端正常
免責(zé)聲明:本網(wǎng)站部分文章、圖片等信息來源于網(wǎng)絡(luò),版權(quán)歸原作者平臺所有,僅用于學(xué)術(shù)分享,如不慎侵犯了你的權(quán)益,請聯(lián)系我們,我們將做刪除處理!