0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

MQTT協(xié)議通信過程

汽車電子技術(shù) ? 來源:物聯(lián)網(wǎng)IoT開發(fā) ? 作者:杰杰mcu ? 2023-02-28 16:07 ? 次閱讀

MQTT連接服務(wù)器

客戶端到服務(wù)器的網(wǎng)絡(luò)連接建立后,客戶端發(fā)送給服務(wù)器的第一個報文必須是CONNECT報文

在一個網(wǎng)絡(luò)連接上,客戶端只能發(fā)送一次CONNECT報文,如果出現(xiàn)第二個CONNECT 報文,按照協(xié)議標準,服務(wù)器會將第二個CONNECT報文當作協(xié)議違規(guī)處理并斷開客戶端的連接。

對于正常的連接請求,服務(wù)器必須產(chǎn)生應(yīng)答報文,如果無法建立會話,服務(wù)器應(yīng)該在應(yīng)答報文中報告對應(yīng)的錯誤代碼。

圖片

mqtt007

MQTT訂閱主題

客戶端向服務(wù)器發(fā)送SUBSCRIBE報文用于創(chuàng)建一個或多個訂閱。

在服務(wù)器中,會記錄這個客戶關(guān)注的一個或者多個主題,當服務(wù)器收到這些主題的PUBLISH報文的時候,將分發(fā)應(yīng)用消息到與之匹配的客戶端中。

SUBSCRIBE報文支持通配符,也為每個訂閱指定了最大的QoS等級,服務(wù)器根據(jù)這些信息分發(fā)應(yīng)用消息給客戶端。

SUBSCRIBE報文擁有固定報頭、可變報頭、有效載荷。

當服務(wù)器收到客戶端發(fā)送的一個SUBSCRIBE報文時,必須向客戶端發(fā)送一個SUBACK報文響應(yīng),同時SUBACK報文必須和等待確認的SUBSCRIBE報文有相同的報文標識符。

如果服務(wù)器收到一個SUBSCRIBE報文,報文的主題過濾器與一個現(xiàn)存訂閱的主題過濾器相同,那么必須使用新的訂閱徹底替換現(xiàn)存的訂閱。新訂閱的主題過濾器和之前訂閱的相同,但是它的最大QoS值可以不同。與這個主題過濾器匹配的任何現(xiàn)存的保留消息必須被重發(fā),但是發(fā)布流程不能中斷。

圖片

mqtt008

SUBSCRIBE報文的有效載荷包含了一個主題過濾器列表,它們表示客戶端想要訂閱的主題,SUBSCRIBE報文有效載荷中的主題過濾器列表必須是UTF-8字符串。

服務(wù)器應(yīng)該支持包含通配符的主題過濾器。如果服務(wù)器選擇不支持包含通配符的主題過濾器,必須拒絕任何包含通配符過濾器的訂閱請求。

每一個過濾器后面跟著一個字節(jié),這個字節(jié)被叫做服務(wù)質(zhì)量要求(Requested QoS)。它給出了服務(wù)器向客戶端發(fā)送應(yīng)用消息所允許的最大QoS等級。

MQTT發(fā)布消息

PUBLISH控制報文是指從客戶端向服務(wù)器或者服務(wù)器向客戶端發(fā)送一個應(yīng)用消息。其實從服務(wù)器分發(fā)的報文給訂閱者,也是屬于PUBLISH控制報文。

服務(wù)質(zhì)量等級 QoS

QoS的值表示應(yīng)用消息分發(fā)的服務(wù)質(zhì)量等級保證,在不同的服務(wù)質(zhì)量等級中,PUBLISH控制報文的處理方式也是不同的,而且PUBLISH報文的接收者(可以是服務(wù)器,也可以是客戶端)必須按照根據(jù)PUBLISH報文中的QoS等級發(fā)送對應(yīng)的應(yīng)答報文。

PUBLISH報文固定報頭的bit2-bit1位表示服務(wù)質(zhì)量等級:

圖片

MQTT按照這里定義的服務(wù)質(zhì)量 (QoS) 等級分發(fā)應(yīng)用消息。服務(wù)器分發(fā)應(yīng)用消息給多個客戶端(訂閱者)時,每個客戶端獨立處理。從發(fā)布者發(fā)布消息到接受者,分發(fā)的消息服務(wù)質(zhì)量可能是不同的,這取決于訂閱者訂閱主題時指定的服務(wù)質(zhì)量等級。而對于發(fā)布者而言,發(fā)布消息時就指定了服務(wù)質(zhì)量等級。

QoS0的PUBLISH控制報文

消息的分發(fā)依賴于底層網(wǎng)絡(luò)的能力。服務(wù)器不會發(fā)送響應(yīng),發(fā)布者也不會重試,它在發(fā)出這個消息的時候就立馬將消息丟棄,這個消息可能送達一次也可能根本沒送達。

發(fā)布者必須發(fā)送QoS等于0,DUP等于0的PUBLISH報文。

在服務(wù)器接受PUBLISH報文時要將消息分發(fā)給訂閱該主題(消息)的訂閱者。

圖片

mqtt009

QoS1的PUBLISH控制報文

服務(wù)質(zhì)量確保消息至少送達一次,甚至可能被多次處理。QoS1的PUBLISH報文的可變報頭中包含一個報文標識符,需要PUBACK報文確認。

發(fā)布者在每次發(fā)送新的應(yīng)用消息都必須分配一個未使用的報文標識符,在發(fā)布消息的同時將消息存儲起來,等待服務(wù)器的應(yīng)答,直到從接收者那收到對應(yīng)的PUBACK報文。發(fā)送的PUBLISH報文必須包含報文標識符且QoS等于1,DUP等于0。

一旦發(fā)布者收到來自服務(wù)器的PUBACK報文后,這個報文標識符就可以重復(fù)使用。

接收者響應(yīng)的PUBACK報文必須包含一個報文標識符,這個標識符來自接收到的PUBLISH報文。在發(fā)送了PUBACK報文之后,接收者必須將任何包含相同報文標識符的入站PUBLISH報文當作一個新的消息,并忽略它的DUP標志的值。

圖片

mqtt010

QoS2的PUBLISH控制報文

這是最高等級的服務(wù)質(zhì)量,必須保證有且只有處理一次消息,消息丟失和重復(fù)都是不可接受的。使用這個服務(wù)質(zhì)量等級會有額外的開銷。

QoS2的消息可變報頭中有報文標識符。

QoS2的PUBLISH報文的接收者使用一個兩步確認過程來確認收到。

發(fā)送者必須給要發(fā)送的新應(yīng)用消息分配一個未使用的報文標識符。發(fā)送的PUBLISH報文必須包含報文標識符且報文的QoS等于2,,DUP等于0。

在消息發(fā)出去后,需要將這個消息存儲起來,而且必須將這個PUBLISH報文看作是未確認的,直到從接收者那收到對應(yīng)的PUBREC報文。

當發(fā)布者收到的PUBREC報文后必須發(fā)送一個PUBREL報文。PUBREL報文必須包含與原始PUBLISH報文相同的報文標識符。

而且發(fā)布者還必須必須將這個PUBREL報文看作是未確認的,直到從接收者那收到對應(yīng)的PUBCOMP報文。一旦發(fā)送了對應(yīng)的PUBREL報文就不能重發(fā)這個PUBLISH報文。

所以就如下圖所示,在發(fā)布消息的時候,立馬存儲消息,在收到PUBREC報文后必須將存儲的消息丟棄掉,然后存儲報文標識符,與此同時還要將PUBREL報文發(fā)送出去,最后在收到PUBCOMP報文后,才丟棄存儲的報文標識符。

圖片

mqtt011

當然啦,對應(yīng)分發(fā)消息也是比較復(fù)雜的,它一般有兩種處理方案,每一種方案都要確保消息有且只有處理一次。

接收者(此處指服務(wù)器)響應(yīng)的PUBREC報文必須包含報文標識符,這個標識符來自接收到的PUBLISH報文。

發(fā)送PUBREC報文后,在收到對應(yīng)的PUBREL報文之前,接收者可以將消息分發(fā)給訂閱者,但是必須要存儲報文標識符(方案1)。

當然,它在這種情況下,也可以存儲消息,直到收到PUBREL報文才將消息分發(fā)到訂閱者(方案2)。

而當它收到PUBREL報文后,它必須發(fā)送PUBCOMP報文響應(yīng)發(fā)布者,該報文必須包含與PUBREL報文相同的標識符。

與此同時,它可以丟棄存儲的報文標識符(方案1),而不必再分發(fā)應(yīng)用消息給訂閱者。

如果此前沒有分發(fā)應(yīng)用消息給訂閱者(方案2),那么此時需要分發(fā)應(yīng)用消息給訂閱者,然后丟棄消息。

在接收者發(fā)送PUBCOMP報文之后,接收者必須將包含相同報文標識符的任何后續(xù)PUBLISH報文當作一個新的發(fā)布。

取消訂閱

客戶端發(fā)送UNSUBSCRIBE報文給服務(wù)器,用于取消訂閱主題。

UNSUBSCRIBE報文固定報頭的第3,2,1,0位是保留位且必須分別設(shè)置為0,0,1,0。否則服務(wù)器必須認為任何其它的值都是不合法的并關(guān)閉網(wǎng)絡(luò)連。具體的描述可以看協(xié)議文檔。

UNSUBSCRIBE報文的有效載荷包含客戶端想要取消訂閱的主題過濾器列表。UNSUBSCRIBE報文中的主題過濾器必須是連續(xù)打包的UTF-8編碼字符串。

UNSUBSCRIBE報文的有效載荷必須至少包含一個主題過濾器列表,而且這個主題過濾器是已經(jīng)被客戶端訂閱的,否則的話沒有訂閱也就沒有取消訂閱一說了。如果一個UNSUBSCRIBE報文沒有有效載荷是違反協(xié)議的標準的,服務(wù)器也不會去處理它。

而對于服務(wù)器刪除了一個訂閱,那么它將不會再分發(fā)該主題的消息到這個客戶端中。而且它必須完成分發(fā)任何已經(jīng)開始往客戶端發(fā)送的QoS1和QoS2的消息,以保證消息的服務(wù)質(zhì)量。

然后服務(wù)器必須發(fā)送UNSUBACK報文來響應(yīng)客戶端的UNSUBSCRIBE請求。UNSUBACK報文必須包含和UNSUBSCRIBE報文相同的報文標識符。即使沒有刪除任何主題訂閱(客戶端取消訂閱的主題未被訂閱),服務(wù)器也必須發(fā)送一個UNSUBACK響應(yīng)。

圖片

mqtt012

斷開連接

DISCONNECT報文是客戶端發(fā)給服務(wù)端的最后一個控制報文。表示客戶端正常斷開連接。

DISCONNECT報文的固定報頭保留位必須全為0。

客戶端發(fā)送DISCONNECT報文之后必須關(guān)閉網(wǎng)絡(luò)連接,不能通過那個網(wǎng)絡(luò)連接再發(fā)送任何控制報文。

服務(wù)端在收到DISCONNECT報文時必須丟棄任何與當前連接關(guān)聯(lián)的未發(fā)布的遺囑消息。而且當客戶端沒有關(guān)閉網(wǎng)絡(luò)連接的時候服務(wù)器應(yīng)該主動去關(guān)閉網(wǎng)絡(luò)連接。

圖片

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 網(wǎng)絡(luò)
    +關(guān)注

    關(guān)注

    14

    文章

    7485

    瀏覽量

    88540
  • 客戶端
    +關(guān)注

    關(guān)注

    1

    文章

    289

    瀏覽量

    16640
  • Connector
    +關(guān)注

    關(guān)注

    0

    文章

    13

    瀏覽量

    8610
收藏 人收藏

    評論

    相關(guān)推薦

    C語言代碼封裝MQTT協(xié)議報文,了解MQTT協(xié)議通信過程

    MQTT是一種輕量級的通信協(xié)議,適用于物聯(lián)網(wǎng)(IoT)和低帶寬網(wǎng)絡(luò)環(huán)境。它基于一種“發(fā)布/訂閱”模式,其中設(shè)備發(fā)送數(shù)據(jù)(也稱為 “發(fā)布”)到經(jīng)紀人(稱為MQTT代理),這些數(shù)據(jù)被存儲,并在需要時被
    的頭像 發(fā)表于 05-17 09:24 ?3244次閱讀

    RK3568-MQTT通信協(xié)議案例

    RK3568-MQTT通信協(xié)議案例
    的頭像 發(fā)表于 01-19 15:31 ?1704次閱讀
    RK3568-<b class='flag-5'>MQTT</b><b class='flag-5'>通信協(xié)議</b>案例

    TLT507-MQTT通信協(xié)議案例

    TLT507-MQTT通信協(xié)議案例
    的頭像 發(fā)表于 01-26 10:06 ?719次閱讀
    TLT507-<b class='flag-5'>MQTT</b><b class='flag-5'>通信協(xié)議</b>案例

    MQTT協(xié)議通信 - 第1節(jié)

    通信MQTT協(xié)議
    充八萬
    發(fā)布于 :2023年09月01日 14:37:46

    MQTT協(xié)議通信 - 第4節(jié)

    通信MQTT協(xié)議
    充八萬
    發(fā)布于 :2023年09月01日 14:40:16

    MQTT協(xié)議通信 - 第10節(jié)

    通信MQTT協(xié)議
    充八萬
    發(fā)布于 :2023年09月01日 14:45:17

    MQTT協(xié)議通信 - 第11節(jié)

    通信MQTT協(xié)議
    充八萬
    發(fā)布于 :2023年09月01日 14:46:07

    MQTT協(xié)議通信 - 第13節(jié)

    通信MQTT協(xié)議
    充八萬
    發(fā)布于 :2023年09月01日 14:47:48

    MQTT協(xié)議通信 - 第14節(jié)

    通信MQTT協(xié)議
    充八萬
    發(fā)布于 :2023年09月01日 14:48:38

    請問MQTT協(xié)議的整個通信流程是怎樣的?

    請問MQTT協(xié)議的整個通信流程是怎樣的?
    發(fā)表于 10-27 06:27

    如何利用mqtt協(xié)議實現(xiàn)的通信服務(wù)?

    如何利用mqtt協(xié)議實現(xiàn)的通信服務(wù)?
    發(fā)表于 10-27 06:41

    MQTT協(xié)議學(xué)習(xí)過程記錄

    學(xué)習(xí)mqtt協(xié)議(一)介紹1--6步內(nèi)容第一步 了解全局第二步 確定范圍第三步 定義目標第四步 尋找資源第五步 創(chuàng)建學(xué)習(xí)計劃第六步 篩選資源總結(jié)介紹采用10步學(xué)習(xí)法學(xué)習(xí)mqtt協(xié)議,根
    發(fā)表于 01-07 06:32

    MQTT協(xié)議的相關(guān)資料分享

    前言搞智能家居就不得不說到網(wǎng)絡(luò)通信,因為我們需要通過各種終端去控制我們的智能家居設(shè)備,所以網(wǎng)絡(luò)通信這方面是必備的.而在市面上比較流行的網(wǎng)絡(luò)通訊協(xié)議就是MQTT
    發(fā)表于 01-20 07:11

    mqtt-v3.1.1版協(xié)議

    mqtt-v3.1.1版協(xié)議,英文版,時間2014.10.29,物聯(lián)網(wǎng)通信協(xié)議MQTT
    發(fā)表于 10-29 11:22 ?0次下載

    MQTT 協(xié)議:機器對機器通信的解決方案?

    MQTT 協(xié)議:機器對機器通信的解決方案?
    的頭像 發(fā)表于 01-05 09:43 ?800次閱讀