物聯(lián)網(wǎng)數(shù)據(jù)接入篇-應(yīng)用層MQTT(6)
前幾篇文章講述的是TCP/IP 模型中的網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層部分協(xié)議,這里到了第四層應(yīng)用層的 MQTT協(xié)議。都是物聯(lián)網(wǎng)常用的應(yīng)用層協(xié)議。CoAP 協(xié)議 OPC 放到之后寫。
MQTT 協(xié)議
消息隊(duì)列遙測(cè)傳輸,Message Queuing Telemetry Transport,MQTT 是ISO 標(biāo)準(zhǔn)下基于發(fā)布/訂閱(Publish/Subscribe)范式的消息協(xié)議。它工作在TCP/IP協(xié)議族上,是為硬件性能低下的遠(yuǎn)程設(shè)備以及網(wǎng)絡(luò)狀況糟糕的情況下而設(shè)計(jì)的發(fā)布/訂閱型消息協(xié)議。
MQTT最大優(yōu)點(diǎn)在于,用極少的代碼和有限的帶寬,為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。為什么,因?yàn)閰f(xié)議簡(jiǎn)單,開銷就??;發(fā)布訂閱模式,解耦了發(fā)布者和訂閱者,他們不需要直接傳遞消息,有個(gè)中介幫忙,同樣的數(shù)據(jù),我就上傳一份,再傳出去一份,就想導(dǎo)游只說一遍,大家都帶著藍(lán)牙耳機(jī),都能聽到;持久會(huì)話,不會(huì)經(jīng)常斷開重連,這都耗電。
作為一種低開銷、低帶寬占用的即時(shí)通訊協(xié)議,使其在物聯(lián)網(wǎng)、小型設(shè)備、移動(dòng)應(yīng)用等方面有較廣泛的應(yīng)用。
MQTT 的消息發(fā)布和訂閱模式,像微博一樣,有一個(gè)消息發(fā)布者,有一批訂閱著,有個(gè)服務(wù)器。消息發(fā)布者把消息發(fā)送到服務(wù)器,訂閱者訂閱消息,就能收到消息。
HTTP 基于請(qǐng)求響應(yīng),像微信聊天,我和你加好友,建立連接,我發(fā)消息,你接受消息。必須要建立穩(wěn)定可靠的連接。
工作原理
發(fā)布者將消息發(fā)布到代理服務(wù)器,代理服務(wù)器根據(jù)訂閱者的訂閱情況將消息分發(fā)給相應(yīng)的訂閱者。
組成部分
主要包括發(fā)布者(Publisher)、訂閱者(Subscriber)、代理服務(wù)器(Broker)。
發(fā)布者 Publisher:
使用MQTT的程序或設(shè)備??蛻舳送ㄟ^網(wǎng)絡(luò)連接到服務(wù)端。它可以發(fā)布應(yīng)用消息給服務(wù)端。
服務(wù)端 Server:
一個(gè)程序或設(shè)備,作為發(fā)送消息的客戶端和請(qǐng)求訂閱的客戶端之間的中介。服務(wù)端接受來自客戶端的網(wǎng)絡(luò)連接、接受客戶端發(fā)布的應(yīng)用消息、處理客戶端的訂閱和取消訂閱請(qǐng)求、轉(zhuǎn)發(fā)應(yīng)用消息給符合條件的已訂閱客戶端。
訂閱者 Subscriber:
訂閱包含一個(gè)主題過濾器(Topic Filter)和一個(gè)最大的服務(wù)質(zhì)量(QoS)等級(jí)。訂閱與單個(gè)會(huì)話(Session)關(guān)聯(lián)。會(huì)話可以包含多于一個(gè)的訂閱。會(huì)話的每個(gè)訂閱都有一個(gè)不同的主題過濾器。
Topic(主題):
Topic具有兩層含義:其一,在發(fā)布消息時(shí),主題會(huì)與消息相關(guān)聯(lián),以此向 服務(wù)端 表明這條消息要發(fā)送至哪個(gè)主題;其二,在訂閱消息時(shí),客戶端需向 服務(wù)端 表明自己對(duì)哪個(gè)主題感興趣,一旦有消息發(fā)送給這個(gè)主題,服務(wù)端 便會(huì)將該消息發(fā)給此主題的訂閱者。主題支持通配符,而對(duì)于使用通配符的主題,我們將其稱作 Topic Filter。
MQTT 控制報(bào)文
在MQTT協(xié)議中,一個(gè)MQTT數(shù)據(jù)包由:固定頭(Fixed header)、可變頭(Variable header)、消息體(payload)三部分構(gòu)成。MQTT數(shù)據(jù)包結(jié)構(gòu)如下:
- 消息類型:4位的無符號(hào)值。表示服務(wù)器到客戶端的單向還是雙向通信,發(fā)送消息還是訂閱消息還是取消訂閱消息。
- 標(biāo)識(shí)位 / DUP:Duplicate Flag,用于指示該 Publish 報(bào)文是否為重發(fā)報(bào)文。如果 DUP 標(biāo)志被設(shè)置為 0,表示第一次請(qǐng)求發(fā)送這個(gè) Publish 報(bào)文;如果 DUP 標(biāo)志被設(shè)置為 1,表示這可能是一個(gè)早前報(bào)文請(qǐng)求的重發(fā)??蛻舳嘶蚍?wù)器請(qǐng)求重發(fā)一個(gè) Publish 報(bào)文時(shí),必須將 DUP 標(biāo)志設(shè)置為 1。
- Qos:Quality of Service(服務(wù)質(zhì)量)。它是用于消息可靠性傳遞的一個(gè)參數(shù),具有 3 個(gè)取值,具體為:0:表示消息僅發(fā)送一次,不確保發(fā)送成功。1:意味著消息最少發(fā)送一次,保證發(fā)送成功,但由于可能會(huì)發(fā)送多次,所以接收方可能會(huì)收到重復(fù)消息。2:表明消息僅發(fā)送一次且保證成功,接收方不會(huì)接到重復(fù)消息。在發(fā)送消息時(shí),可以對(duì) QoS 進(jìn)行指定,如果 QoS 大于 0,那么消息必然會(huì)被發(fā)送至 Broker。而在訂閱主題時(shí),同樣也可以指定 QoS,如果 QoS 大于 0,那么 Broker 一定會(huì)將消息發(fā)送給訂閱者,不會(huì)出現(xiàn)消息丟失的情況。
- RET:Publish Retain Flag,發(fā)布保留標(biāo)識(shí)。指示服務(wù)器是否要保留發(fā)布的消息。當(dāng)RET標(biāo)志位設(shè)置為1時(shí),表示服務(wù)器要保留這次推送的信息。如果有新的訂閱者出現(xiàn),服務(wù)器會(huì)將保留的消息推送給它。如果沒有新的訂閱者,服務(wù)器會(huì)在推送至當(dāng)前訂閱者后釋放該消息。如果RET標(biāo)志位設(shè)置為0,則服務(wù)器不會(huì)保留發(fā)布的消息。
- 剩余長(zhǎng)度:Remaining Length,表示當(dāng)前報(bào)文剩余部分的字節(jié)數(shù),包括可變報(bào)頭和負(fù)載的數(shù)據(jù)。剩余長(zhǎng)度不包括用于編碼剩余長(zhǎng)度字段本身的字節(jié)數(shù)。
- 可變頭:位于固定頭和負(fù)載之間??勺冾^的內(nèi)容因數(shù)據(jù)包類型而異,通常包含與特定數(shù)據(jù)包類型相關(guān)的信息,例如數(shù)據(jù)包標(biāo)識(shí)、主題名等。
- 消息體:Payload,也叫有效載荷。CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息 有消息體: CONNECT,消息體內(nèi)容主要是,客戶端的ClientID、訂閱的Topic、Message以及用戶名和密碼。 SUBSCRIBE,消息體內(nèi)容是一系列的要訂閱的主題以及QoS。 SUBACK,消息體內(nèi)容是服務(wù)器對(duì)于SUBSCRIBE所申請(qǐng)的主題及QoS進(jìn)行確認(rèn)和回復(fù)。 UNSUBSCRIBE,消息體內(nèi)容是要取消訂閱的主題。
太枯燥了,舉個(gè)例子:
特點(diǎn)
- 輕量級(jí):占用資源少,適合資源受限的設(shè)備。
- 可靠性高:提供不同等級(jí)的服務(wù)質(zhì)量保證。MQTT 協(xié)議提供了 3 種消息服務(wù)質(zhì)量等級(jí),保證了在不同的網(wǎng)絡(luò)環(huán)境下消息傳遞的可靠性。
- 低帶寬需求:MQTT 的最小報(bào)文僅為 2 個(gè)字節(jié),比 HTTP 占用更少的網(wǎng)絡(luò)開銷。
- 穩(wěn)定連接:MQTT 與 HTTP 都能使用 TCP 連接,并實(shí)現(xiàn)穩(wěn)定、可靠的網(wǎng)絡(luò)連接。
- 安全雙工通信:MQTT 基于發(fā)布訂閱模型,HTTP 基于請(qǐng)求響應(yīng),因此 MQTT 支持雙工通信。依賴于發(fā)布訂閱模式,MQTT 允許在設(shè)備和云之間進(jìn)行雙向消息通信。發(fā)布訂閱模式的優(yōu)點(diǎn)在于:發(fā)布者與訂閱者不需要建立直接連接,也不需要同時(shí)在線,而是由消息服務(wù)器負(fù)責(zé)所有消息的路由和分發(fā)工作。
MQTT 可實(shí)時(shí)推送消息,但 HTTP 需要通過輪詢獲取數(shù)據(jù)更新。
MQTT 是有狀態(tài)的,但是 HTTP 是無狀態(tài)的。為了應(yīng)對(duì)網(wǎng)絡(luò)不穩(wěn)定的情況,MQTT 提供了心跳?;睿↘eep Alive)機(jī)制。在客戶端與服務(wù)端長(zhǎng)時(shí)間無消息交互的情況下,Keep Alive 保持連接不被斷開,若一旦斷開,客戶端可即時(shí)感知并立即重連。同時(shí),MQTT 設(shè)計(jì)了遺愿消息,讓服務(wù)端在發(fā)現(xiàn)客戶端異常下線的情況下,幫助客戶端發(fā)布一條遺愿消息到指定的 MQTT 主題。
MQTT 可從連接異常斷開中恢復(fù),HTTP 無法實(shí)現(xiàn)此目標(biāo)。
靈活性:基于服務(wù)訂閱模式,消息路由更為靈活。
MQTT 協(xié)議和 HTTP 的對(duì)比:
應(yīng)用
物聯(lián)網(wǎng):各類物聯(lián)網(wǎng)設(shè)備之間的通信。
移動(dòng)應(yīng)用消息推送。
遠(yuǎn)程監(jiān)控系統(tǒng)。
智能家居。
工業(yè)自動(dòng)化等領(lǐng)域。
后記
這個(gè)系列,物聯(lián)網(wǎng)協(xié)議進(jìn)行到了尾聲,這篇寫 MQTT,下面會(huì)寫 CoAP、OPC,都是重頭戲。
參考文獻(xiàn)
15 張圖, 把TCP/IP 講得一清二楚!-騰訊云開發(fā)者社區(qū)-騰訊云
什么是OPC UA&它是如何工作的?_嗶哩嗶哩_bilibili
探索 OSI 會(huì)話層:建立和管理通信會(huì)話的關(guān)鍵_不同機(jī)器之間用戶會(huì)話的建立與管理-CSDN博客
3、物聯(lián)網(wǎng)的物理層協(xié)議 – 孤情劍客 – 博客園
【2024軟考】《網(wǎng)絡(luò)工程師》新版精講視頻-希賽網(wǎng)(零基礎(chǔ)系統(tǒng)教程,建議收藏)!_嗶哩嗶哩_bilibili
MQTT協(xié)議_mqtt payload一定要字符串嗎-CSDN博客
MQTT協(xié)議_mqtt payload一定要字符串嗎-CSDN博客
物聯(lián)網(wǎng)協(xié)議之COAP簡(jiǎn)介及Java實(shí)踐-CSDN博客
如何使用CoAP的對(duì)稱加密自主接入和DTLS自主接入_物聯(lián)網(wǎng)平臺(tái)(IoT)-阿里云幫助中心
DTU和RTU的區(qū)別_rtu和dtu的區(qū)別-CSDN博客
network_protocol_structures.pdf
一文看懂Modbus協(xié)議-阿里云開發(fā)者社區(qū)
modbus_application_protocol_specification_v1.1b3.pdf
https://help.dtuip.com:8888/images/20191028084839667.pdf
一文看懂Modbus協(xié)議-阿里云開發(fā)者社區(qū)
Modbus 寄存器 | 人人都懂物聯(lián)網(wǎng)
https://zh.wikipedia.org/wiki/Modbus
MQTT教學(xué)(一):認(rèn)識(shí)MQTT – 超圖解系列圖書
https://www.51cto.com/article/670429.html
本文由 @躍曰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
- 目前還沒評(píng)論,等你發(fā)揮!