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