物聯網通信之初識MQTT協議

前言

不論使用哪種互聯網接入方式，只要我們的設備可以通過UDP/TCP通信訪問互聯網上對應的IP地址的主機，那麼理論上，當設備與雲服務器建立UDP/TCP通信後，只要按照雲服務 器所規定的通信協議（數據格式）發送/接受消息，我們的設備就能夠接入雲平臺，實現物聯網。
學習物聯網的話mqtt協議就必須要熟悉，否則就像迷路的孩子，找不到回家的方向。
MQTT是一個客戶端服務端架構的發佈/訂閱模式的消息傳輸協議，在實際物聯網項目中有着舉足輕重的地位。

一、關於MQTT術語

1.應用消息（message）：MQTT協議通過網絡傳輸應用數據，這個數據就稱爲消息。
2.客戶端 (client),使用MQTT的程序或者設備，客戶端總是通過網絡連接到服務端。

• 發佈消息給其他客戶端。
• 訂閱已請求接受的消息。
• 取消訂閱已移除接受消息的請求(取消訂閱)。
• 和服務端斷開連接。
  注：一般情況下，雲下設備就是客戶端。
  3.服務端（server），一個程序或設備，作爲發送消息的客戶端和請求訂閱的客戶端之間的中介。
• 接受來自客戶端的網絡連接。
• 接受客戶端發佈的應用消息。
• 處理客戶端的訂閱和取消訂閱請求。
• 轉發應用消息個給符合條件的已訂閱客戶端。
  注：一般情況下，雲平臺就是服務端，服務端不是數據的終點，他只是數據的中轉站。
  4.訂閱（subscription），訂閱包含一個主題過濾器（Topic Filter）和一個最大的服務質量（QoS）等級。訂閱與單個會話關聯。會話可以包含多於一個的訂閱。會話的每個訂閱都會有一個不同的主題過濾器。
  5.主題名（topic name），附加在應用消息上的一個標籤，服務端已知且與訂閱匹配。服務端發送給應用消息的一個副本，給每一個匹配的客戶端訂閱。
  6.主題過濾器（Topic filter），訂閱中包含的一個表達式，用於表示的一個或多個主題。主題過濾器可以使用通配符。
  7.會話(session),客戶端和服務端之間的狀態交互。一些會話持續時長與網絡連接一樣，另一些可以在客戶端和服務端的多個連續網絡連接間擴展。
  8.控制報文（MQTT control packet），通過網絡連接發送的信息數據包。MQTT規範定義了14種不同類型的控制報文，其中publish報文用於傳輸應用消息。
  小注:在實際開發過程中，這些概念要理解才能應用。

---

二、MQTT協議特點

• "輕量級"通信協議：實現MQTT協議的開銷比較小，不需要太多的額外數據。
• 基於TCP/IP協議：建立TCP連接後，雲下設備和雲平臺按照MQTT協議規定的數據格式(一般是JSON)來通信（屬於應用層）。
• 基於客戶端-服務端模式：雲下設備=客戶端，雲平臺=服務端。
• 基於消息發佈（publish）和消息訂閱（subscribe）模式。
  http->請求/回答模式：類似與打電話，只有你打電話給朋友，需要等待朋友接電話纔可以交流。
  mqtt->發佈/訂閱模式：類似郵件的發送，你可以向你的朋友發送郵件，發送後你就不用管了，服務器會將郵件發送給你的朋友，朋友收到郵件後，隨時可以查看郵件。
  發佈/訂閱模式解耦了發佈者和訂閱着之間的聯繫，這就意味着發佈者和訂閱者之間並不需要直接建立聯繫。（實際上通過MQTT服務器建立聯繫的）
  舉個栗子：
  如下圖：在上圖中，假如客戶端C和客戶端B訂閱了MQTT服務端的主題topic，客戶端A向MQTT服務端發佈了一個topic主題參數的消息，那麼這個MQTT服務端就會將消息分發給客戶端B和客戶端C，因爲客戶端B和客戶端C都向MQTT服務器訂閱了這個主題topic。當然客戶端A也可以訂閱MQTT服務端的主題，客戶端B和客戶端C也可以向MQTT服務器發佈消息。雖然在邏輯上三個客戶端之間通信，但是在網絡連接方面，客戶端A只和MQTT服務端建立網絡連接，同理其他兩個客戶端也是隻和MQTT服務端建立網絡連接。
  

三、MQTT協議數據表示

MQTT協議中控制報文的文本字段的編碼爲UTF-8格式的字符串。
MQTT協議規定，每一個字符串都有以兩字節的長度字段作爲前綴，兩字節的前綴給出這個字符串utf-8編碼的字節數。

---

四、MQTT協議控制報文格式

1.MQTT協議通過交換預定義的MQTT控制報文來進行通信。

注：PUBREC、PUBREL、PUBCOMP都只有在QoS等於2的時候纔會使用。
2.MQTT控制報文的結構
第一部分：固定報頭，所有控制報文都含有這個固定報文。
第二部分：可變報頭，部分控制報文才含有這個可變報文。
第三部分：有效載荷，部分控制報文才含有這個有效載荷。
3.固定報頭

MQTT控制報文的第一個字節的高四位用來表示控制報文的類型，也就是表格2-1中的值，低四位用來指定控制報文類型的標誌位，如下圖表格2.2，出發布消息publish之後，其他每個控制報文的四個bit都是固定的。第二個字節開始就是剩餘長度，表示當前報文剩餘部分的字節數，包括可變報頭和有效載荷的數據。
也就是說只有知道剩餘長度是多少，才能知道MQTT控制報文到哪裏才能結束。剩餘報文不包括剩餘長度字段本身的字節數。剩餘長度字符使用一個變長度編碼方案，只有低7位有效位用於編碼數據，最高位有效位用於指示是否有更多的字節。最多有四個剩餘字節。

4.可變報頭
有些MQTT控制報文包含一個可變報文部分，可變報文子在固定報頭和有效載荷之間。
報文標識符
重發消息所用到的報文標識符，如果客戶端要重發控制報文，重發的報文必須和之前的報文使用相同的標識符。當客戶端處理完報文對應的確認後，這個報文標識符就可釋放重用。
包含報文標識符的控制報文有：PUBLISH（QoS > 0時）， PUBACK，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE, SUBACK，UNSUBSCIBE，UNSUBACK。

注：客戶端和服務端彼此獨立地分配報文標識符，所以客戶端服務端組合使用相同的報文標識符可以實現併發的消息交換。
5.有效載荷
對publsh報文來說，有效載荷就是應用消息。

---

五、服務質量等級QoS

QoS表示MQTT客戶端向MQTT服務端發佈消息或者MQTT服務端向MQTT客戶端分發消息的服務質量等級。QoS只能由三種取值（0，1，2）。
1.QoS=0表示消息最多發送一次。
也就是發送方發送消息，接受方不會發送響應，發送者也不會重試（因爲最多隻發送一次，發送方就把這一次的機會佔用了，所以接受方是不會發送消息的）。所以消息可能送達一次也可能根本沒有送達。
2.QoS=1表示消息至少發送一次。
發送方發送消息，需要等待接受方的應答，如果接受方沒有發送應答，發送方會嘗試再次發送消息，所以消息最少被髮送一次。
3.QoS=2表示消息僅僅發送一次。
使用控制報文中PUBREC、PUBREL、PUBCOMP類型實現僅僅發送一次。
注：百度雲、騰訊雲、阿里雲支持QoS爲0和1的服務質量，不支持QoS爲2的服務質量，所以只是瞭解QoS爲2即可。
4.提醒
發佈消息和訂閱主題的QoS服務質量是不相關的，也就是發佈消息和訂閱主題有着自己的服務質量等級QoS.
發佈消息QoS:客戶端發佈消息到服務端的服務質量等級。
訂閱主題QoS：服務端分發消息到客戶端時消息的服務質量等級。

注：使用QoS服務質量等級，根據消息是否需要應答來決定QoS的值。

---

**逆水行舟不進則退，有問題在下方評論或者私聊我一直在，一起進步！**