国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

MQTT協議介紹

lewinlee / 2145人閱讀

摘要:協議簡介,消息隊列遙測傳輸是一個輕量的發布訂閱模式消息傳輸協議,是專門針對低帶寬和不穩定網絡環境的物聯網應用設計的。它是等級協議交換的第二個報文。

1.MQTT協議簡介


MQTTMessage Queuing Telemetry Transport,消息隊列遙測傳輸)是一個輕量的發布/訂閱模式消息傳輸協議,是專門針對低帶寬和不穩定網絡環境的物聯網應用設計的。

特點:

????????1.開放消息協議,易實現

????????2.發布訂閱模式,一對多消息發布

????????3.基于TCP/IP網絡連接

????????4.報文結構緊湊

????????5.消息QoS支持,保證可靠傳輸

MQTT協議原理

????????實現MQTT 協議需要客戶端和服務器 端建立 TCP 連接, 在通訊過程中, MQTT 協議中 有三種身份 :發布 者( Publish )、代理( Broker )(服務器)、訂閱者( Subscribe )。其中,消息的發布者和訂閱者都是客戶端,消息代理是服務器,消息發布者可以同時是訂閱者
MQTT 傳輸的消息分為 :主 題( Topic )和負載( payload
????????(1) Topic ,可以理解為消息的類型,訂閱者訂閱( Subscribe )后,就會收到該主題 的 消息 內容( payload );

????????(2payload可以理解為消息的內容,是指訂閱者具體要使用的內容。

MQTT協議服務器?:

????????MQTT服務器以稱為“消息代理”(Broker),它是位于消息發布者和訂閱者之間,服務器可以:

????????(1)接受來自客戶端的網絡連接;

????????(2接受客戶端發布的信息;

????????(3)處理來自客戶端的訂閱和退訂請求;

????????(4)向訂閱的客戶轉發消息

?MQTT協議客戶端:

????????一個使用MQTT協議設備,它總是建立到服務器的網絡接,客戶端可以:

????????(1)發布其他客戶端可能會訂閱的信息;

????????(2)訂閱其它客戶端發布的消息;

????????(3)退訂或刪除消息;

????????(4)斷開與服務器連接。

MQTT協議棧

?2.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 的值可以等于 012

User Name Flag:用戶名標志,標志被設置為 0,有效載荷中 不能包含用戶名字段,標志被設置為 1,有效載荷中 必須包含用戶名字段;

Password Flag:密碼標志,標志被設置為 0,有效載荷中 不能包含密碼字段,標志被設置為 1,有效載荷中必須包含密碼字段;

2.2? CONNACK 報文解讀

?返回碼說明:

?服務端發送給客戶端的第一個報文 是 CONNACK,服務端發送 CONNACK 報文響應從客戶端收到的 CONNECT 報文。

Sp: Session Present Flag

當前會話標志

session信息在服務器已保持,置1

未保存,置0

2.3 PUBLISHC<>S發布消息報文解讀

DUP:重發標志

QoS2Qos1:如果為0,則表示是第一次發送該包,如果為1,則表示為重復發送的包。

Qos0DUP必須為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. MQTT接入流程


3.1 連接流程

? 設備向平臺發起 CONNECT 請求 , CONNECT 中攜帶鑒權信息 , 平臺拿到鑒權信息進行鑒權。

? 鑒權通過后,如果 CLEANSESSION=0, 平臺將會加載保存的設備的一些信息 如果 CLEANSESSION=1, 設備沒有保存信息在平臺,則不加載設備相關信息
?
? 返回鑒權結果 CONNACK

?3.2 發布消息流程

? 設備發布 Qos0 消息;
?

平臺收到上報數據點后保存起來

? 設備發布 Qos1 消息
? 平臺收到上報數據點后保存起來
? 平臺給設備回復相應的 PUBACK

?

? 設備發布 Qos2 消息
? 平臺收到上報數據點后保存起來
? 平臺給設備回復相應的 PubRec 報文
? 設備需回復平臺 PubRel 報文,如超時不回平臺則會斷開相應連接
? 平臺給設備回復 PubComp 報文

3.3 訂閱流程

設備發起訂閱請求;

平臺收到請求后更新topic列表;

平臺給設備回復SubAck;

subscriberequestqos級別可以為012

? 設備發起取消訂閱請求
? 平臺收到請求后更新 topic 列表
? 平臺給設備回復 UnSubAck

?3.5 連接保活流程

客戶端發送 PINGREQ 報文給服務端的,服務端發送 PINGRESP 報文響應客戶端的 PINGREQ 報文,表示服務端還活著。

3.6 斷開連接流程

DISCONNECT 報文是客戶端發給服務端的最后一個控制報文,表示客戶端正常斷開連接。

?4.MQTT消息QOS


級別0:最多一次,消息發送者會想盡辦法發送消息,但是遇到意外并不會重試,這一級別會發生消息丟失。

級別 1 :至少一次。消息接收者如果 沒有知會或者知會本身 丟失,消息發送者會再次發送以保證消息接收者至少會收到一次 ,這一級別會保證消息到達,可能造成消息重復。

級別 2 :恰好一 次,確保消息只有一次到達。

?

?MQTT發布消息QoS保證不是端到端的,是客戶端與服務器之間的。訂閱者收到MQTT消息的QoS級別,最終取決于發布消息的QoS和主題訂閱的QoS

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/120928.html

相關文章

  • MQTT

    摘要:協議版本介紹互聯網的基礎網絡協議是協議消息隊列遙測傳輸是基于協議棧而構建的已成為通信的標準為什么選擇有多好多好多么牛逼我就不說了說的再多不如一個一個試試完了做比對剩下的那個就是要選擇的實在不想這樣搞技術就跟著一線走發布和訂閱模型協議在網絡中 mqtt 協議版本: 3.1.1 MQTT 介紹 互聯網的基礎網絡協議是 TCP/IP協議. MQTT(消息隊列遙測傳輸)是基于 TCP/IP 協...

    lastSeries 評論0 收藏0
  • 搭建IM服務 so easy

    摘要:現在很多網站都通過服務來實現消息推送及數據即時同步功能,即時通訊組件逐漸成為產品的標配。目前國內有很多成熟穩定的第三方即時通訊服務廠家,比如融云。 現在很多網站、APP都通過IM服務來實現消息推送及數據即時同步功能,即時通訊組件逐漸成為產品的標配。目前國內有很多成熟穩定的第三方即時通訊服務廠家,比如:融云。使用這些專業的服務可以提高開發效率而且服務穩定有保障。 如果自己DIY或者需要在...

    imccl 評論0 收藏0
  • mosquitto 與 websocket 的結合

    摘要:前言作為一個消息代理客戶端與服務端的通信時基于協議的而現在的主流應用時呈現在瀏覽器中這意味著用戶與服務端只能通過或者這類瀏覽器能理解的協議傳輸所以后端還要建立一個代理層將協議傳輸的內容解析一下以協議發送到最后再由發送到硬件端在瀏覽器支持的協 前言 mosquitto 作為一個消息代理, 客戶端與 mosquitto 服務端的通信時基于 MQTT 協議的, 而現在的主流 web 應用時呈...

    joy968 評論0 收藏0
  • mosquitto 與 websocket 的結合

    摘要:前言作為一個消息代理客戶端與服務端的通信時基于協議的而現在的主流應用時呈現在瀏覽器中這意味著用戶與服務端只能通過或者這類瀏覽器能理解的協議傳輸所以后端還要建立一個代理層將協議傳輸的內容解析一下以協議發送到最后再由發送到硬件端在瀏覽器支持的協 前言 mosquitto 作為一個消息代理, 客戶端與 mosquitto 服務端的通信時基于 MQTT 協議的, 而現在的主流 web 應用時呈...

    tomener 評論0 收藏0
  • 在Node.js下運用MQTT協議實現即時通訊及離線推送

    摘要:前言前些日子了解到這樣一個協議,可以在上達到即時通訊的效果,但網上并不能很方便地找到一篇目前版本的在下正確實現這個協議的博客。 前言 前些日子了解到mqtt這樣一個協議,可以在web上達到即時通訊的效果,但網上并不能很方便地找到一篇目前版本的在node下正確實現這個協議的博客。 自己搗鼓了一段時間,理解不深刻,但也算是基本能夠達到使用目的。 本文目的為對MQTT有需求的學習者提供一定程...

    jlanglang 評論0 收藏0

發表評論

0條評論

lewinlee

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<