摘要:協議簡介,消息隊列遙測傳輸是一個輕量的發布訂閱模式消息傳輸協議,是專門針對低帶寬和不穩定網絡環境的物聯網應用設計的。它是等級協議交換的第二個報文。
MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸)是一個輕量的發布/訂閱模式消息傳輸協議,是專門針對低帶寬和不穩定網絡環境的物聯網應用設計的。
特點:
????????1.開放消息協議,易實現
????????2.發布訂閱模式,一對多消息發布
????????3.基于TCP/IP網絡連接
????????4.報文結構緊湊
????????5.消息QoS支持,保證可靠傳輸
MQTT協議原理
????????(2)payload可以理解為消息的內容,是指訂閱者具體要使用的內容。
MQTT協議服務器?:
????????MQTT服務器以稱為“消息代理”(Broker),它是位于消息發布者和訂閱者之間,服務器可以:
????????(1)接受來自客戶端的網絡連接;
????????(2)接受客戶端發布的信息;
????????(3)處理來自客戶端的訂閱和退訂請求;
????????(4)向訂閱的客戶轉發消息。
?MQTT協議客戶端:
????????一個使用MQTT協議設備,它總是建立到服務器的網絡連接,客戶端可以:
????????(1)發布其他客戶端可能會訂閱的信息;
????????(2)訂閱其它客戶端發布的消息;
????????(3)退訂或刪除消息;
????????(4)斷開與服務器連接。
MQTT協議棧
MQTT協議數據包結構:
在MQTT協議中,一個MQTT數據包由:固定頭(Fixed header)、可變頭(Variable header)、消息體(Payload)三部分構成。MQTT數據包結構如下:
?Fixed Header(固定報文頭)
?Variable Header &Payload
2.1? CONNECT報文解讀
Clean Session:清理會話,用于控制會話狀態的生存時間,標志被設置為 1,客戶端和服務端 必須丟棄之前的任何會話并開始一個新的會話。標志被設置為 0,服務端 必須基于當前會話(使用客戶端標識符識別)的狀態恢復與客戶端的通信;
Will Flag:遺囑標志設置為 1,表示如果連接請求被接受了,遺囑(Will Message)消息 必須被存儲在服務端;
QoS:遺囑消息服務質量等級,遺囑標志被設置為 0,遺囑 QoS 也設置為 0;遺囑標志被設置為 1,遺囑 QoS 的值可以等于 0,1,2;
User Name Flag:用戶名標志,標志被設置為 0,有效載荷中 不能包含用戶名字段,標志被設置為 1,有效載荷中 必須包含用戶名字段;
Password Flag:密碼標志,標志被設置為 0,有效載荷中 不能包含密碼字段,標志被設置為 1,有效載荷中必須包含密碼字段;
2.2? CONNACK 報文解讀
?返回碼說明:
?服務端發送給客戶端的第一個報文 是 CONNACK,服務端發送 CONNACK 報文響應從客戶端收到的 CONNECT 報文。
Sp: Session Present Flag
當前會話標志
session信息在服務器已保持,置1;
未保存,置0。
2.3 PUBLISH(C<>S)發布消息報文解讀
DUP:重發標志
QoS2、Qos1:如果為0,則表示是第一次發送該包,如果為1,則表示為重復發送的包。
Qos0:DUP必須為0
QOS: 指定了該Publish包的Qos等級如下
RETAIN: 保留標志位,如果為1,服務器存儲最新一條RETAIN消息,以便分發給新的訂閱者;
2.4. PUBACK? 收到發布消息確認報文解讀
PUBACK 報文是對 QoS 1 等級的 PUBLISH 報文的響應。
2.5 PUBREC? 發布消息收到
PUBREC 報文是對 QoS 等級 2 的 PUBLISH 報文的響應。它是 QoS 2 等級協議交換的第二個報文。
2.6 PUBRECL? 發布消息釋放報文解讀
PUBREL 報文是對 PUBREC 報文的響應。它是 QoS 2 等級協議交換的第三個報文。
2.7 PUBCOMP? 發布完成報文解讀
PUBCOMP 報文是對 PUBREL 報文的響應。它是 QoS 2 等級協議交換的第四個也是最后一個報文。
2.8 SUBSCRIBE? 訂閱主題報文解讀
?SUBSCRIBE 報文的有效載荷包含了一個主題,它們表示客戶端想要訂閱的主題,后面跟著一個字節,這個字節被叫做 服務質量要求(Requested QoS)。它給出了服務端向客戶端發送應用消息所允許的QoS 等級。
2.9 SUBACK? 訂閱確認報文解讀
返回碼說明:
2.10? UNSUBSCRIBE? 取消訂閱報文解讀
??UNSUBSCRIBE 報文提供的主題與服務端持有的這個客戶端的當前主題集合逐個字符比較。如果主題完全匹配,那么它(服務端)自己的訂閱將被刪除,否則不會有進一步的處理。
2.11 UNSUBACK? 取消訂閱確認
可變報頭包含等待確認的 UNSUBSCRIBE 報文的報文標識符。
2.12 PINGREQ? 心跳請求報文解讀
2.13 PINGRESP? 心跳響應報文解讀
客戶端發送 PINGREQ 報文給服務端的。用于:
1. 在沒有任何其它控制報文從客戶端發給服務的時,告知服務端客戶端還活著。
2. 請求服務端發送 響應確認它還活著。
3. 使用網絡以確認網絡連接沒有斷開。
14. DISCONNECT? 斷開連接
客戶端發送 DISCONNECT 報文之后:
服務端在收到 DISCONNECT 報文時:
3.1 連接流程
?3.2 發布消息流程
平臺收到上報數據點后保存起來
?
3.3 訂閱流程
設備發起訂閱請求;
平臺收到請求后更新topic列表;
平臺給設備回復SubAck;
subscribe的requestqos級別可以為0、1、2。
?3.5 連接保活流程
客戶端發送 PINGREQ 報文給服務端的,服務端發送 PINGRESP 報文響應客戶端的 PINGREQ 報文,表示服務端還活著。
3.6 斷開連接流程
DISCONNECT 報文是客戶端發給服務端的最后一個控制報文,表示客戶端正常斷開連接。
級別0:最多一次,消息發送者會想盡辦法發送消息,但是遇到意外并不會重試,這一級別會發生消息丟失。
?
?MQTT發布消息QoS保證不是端到端的,是客戶端與服務器之間的。訂閱者收到MQTT消息的QoS級別,最終取決于發布消息的QoS和主題訂閱的QoS。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/120928.html
摘要:協議版本介紹互聯網的基礎網絡協議是協議消息隊列遙測傳輸是基于協議棧而構建的已成為通信的標準為什么選擇有多好多好多么牛逼我就不說了說的再多不如一個一個試試完了做比對剩下的那個就是要選擇的實在不想這樣搞技術就跟著一線走發布和訂閱模型協議在網絡中 mqtt 協議版本: 3.1.1 MQTT 介紹 互聯網的基礎網絡協議是 TCP/IP協議. MQTT(消息隊列遙測傳輸)是基于 TCP/IP 協...
摘要:現在很多網站都通過服務來實現消息推送及數據即時同步功能,即時通訊組件逐漸成為產品的標配。目前國內有很多成熟穩定的第三方即時通訊服務廠家,比如融云。 現在很多網站、APP都通過IM服務來實現消息推送及數據即時同步功能,即時通訊組件逐漸成為產品的標配。目前國內有很多成熟穩定的第三方即時通訊服務廠家,比如:融云。使用這些專業的服務可以提高開發效率而且服務穩定有保障。 如果自己DIY或者需要在...
摘要:前言作為一個消息代理客戶端與服務端的通信時基于協議的而現在的主流應用時呈現在瀏覽器中這意味著用戶與服務端只能通過或者這類瀏覽器能理解的協議傳輸所以后端還要建立一個代理層將協議傳輸的內容解析一下以協議發送到最后再由發送到硬件端在瀏覽器支持的協 前言 mosquitto 作為一個消息代理, 客戶端與 mosquitto 服務端的通信時基于 MQTT 協議的, 而現在的主流 web 應用時呈...
摘要:前言作為一個消息代理客戶端與服務端的通信時基于協議的而現在的主流應用時呈現在瀏覽器中這意味著用戶與服務端只能通過或者這類瀏覽器能理解的協議傳輸所以后端還要建立一個代理層將協議傳輸的內容解析一下以協議發送到最后再由發送到硬件端在瀏覽器支持的協 前言 mosquitto 作為一個消息代理, 客戶端與 mosquitto 服務端的通信時基于 MQTT 協議的, 而現在的主流 web 應用時呈...
摘要:前言前些日子了解到這樣一個協議,可以在上達到即時通訊的效果,但網上并不能很方便地找到一篇目前版本的在下正確實現這個協議的博客。 前言 前些日子了解到mqtt這樣一個協議,可以在web上達到即時通訊的效果,但網上并不能很方便地找到一篇目前版本的在node下正確實現這個協議的博客。 自己搗鼓了一段時間,理解不深刻,但也算是基本能夠達到使用目的。 本文目的為對MQTT有需求的學習者提供一定程...
閱讀 2083·2023-04-26 02:41
閱讀 2146·2021-09-24 09:47
閱讀 1545·2019-08-30 15:53
閱讀 1204·2019-08-30 13:01
閱讀 1884·2019-08-29 11:27
閱讀 2856·2019-08-28 17:55
閱讀 1739·2019-08-26 14:00
閱讀 3375·2019-08-26 10:18