1.MQTT協議簡介
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協議堆疊
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 的值可以等于 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. MQTT接入流程
3.1 連接流程
3.2 發布訊息流程
平臺收到上報資料點后保存起來
3.3 訂閱流程
設備發起訂閱請求;
平臺收到請求后更新topic串列;
平臺給設備回復SubAck;
subscribe的requestqos級別可以為0、1、2，
3.5 連接保活流程
客戶端發送 PINGREQ 報文給服務端的，服務端發送 PINGRESP 報文回應客戶端的 PINGREQ 報文，表示服務端還活著，
3.6 斷開連接流程
DISCONNECT 報文是客戶端發給服務端的最后一個控制報文，表示客戶端正常斷開連接，
4.MQTT訊息QOS
級別0：最多一次，訊息發送者會想盡辦法發送訊息，但是遇到意外并不會重試，這一級別會發生訊息丟失，
MQTT發布訊息QoS保證不是端到端的，是客戶端與服務器之間的，訂閱者收到MQTT訊息的QoS級別，最終取決于發布訊息的QoS和主題訂閱的QoS，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/302478.html
標籤：其他