MQTT 協議，終於有人講清楚了
大家好，我是小麥，最近做了一個物聯網的項目，順便總結一下 MQTT 協議。大家都知道，MQTT 協議在物聯網中很常用，如果你對此還不是很瞭解，相信這篇文章可以帶你入門。
mqtt 協議
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基於發佈/訂閱（publish/subscribe）模式的 “輕量級” 通訊協議，該協議構建於 TCP/IP 協議上，由 IBM 在 1999 年發佈。
MQTT 最大優點在於，用極少的代碼和有限的帶寬，爲連接遠程設備提供實時可靠的消息服務。
作爲一種低開銷、低帶寬佔用的即時通訊協議，使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。
1 MQTT 協議特點
MQTT 是一個基於客戶端 - 服務器的消息發佈 / 訂閱傳輸協議。
MQTT 協議是輕量、簡單、開放和易於實現的，這些特點使它適用範圍非常廣泛。在很多情況下，包括受限的環境中，如：機器與機器（M2M）通信和物聯網（IoT）。
其在，通過衛星鏈路通信傳感器、偶爾撥號的醫療設備、智能家居、及一些小型化設備中已廣泛使用。
MQTT 協議當前版本爲，2014 年發佈的 MQTT v3.1.1。除標準版外，還有一個簡化版MQTT-SN，該協議主要針對嵌入式設備，這些設備一般工作於 TCP/IP 網絡，如：ZigBee。
MQTT 與 HTTP 一樣，MQTT 運行在傳輸控制協議 / 互聯網協議 (TCP/IP) 堆棧之上。
發佈和訂閱
MQTT使用的發佈 / 訂閱消息模式，它提供了一對多的消息分發機制，從而實現與應用程序的解耦。
這是一種消息傳遞模式，消息不是直接從發送器發送到接收器（即點對點），而是由MQTT server（或稱爲 MQTT Broker）分發的。
MQTT 服務器是發佈 - 訂閱架構的核心。
它可以非常簡單地在 Raspberry Pi 或 NAS 等單板計算機上實現，當然也可以在大型機或 Internet 服務器上實現。
服務器分發消息，因此必須是發佈者，但絕不是訂閱者！
客戶端可以發佈消息（發送方）、訂閱消息（接收方）或兩者兼而有之。
客戶端（也稱爲節點）是一種智能設備，如微控制器或具有 TCP/IP 堆棧和實現 MQTT 協議的軟件的計算機。
消息在允許過濾的主題下發布。主題是分層劃分的 UTF-8 字符串。不同的主題級別用斜槓/作爲分隔符號。
我們來看看下面的設置。
-
光伏發電站是發佈者（
Publisher）。 -
主要主題（
Topic）級別是"PV"，這個工廠發佈兩個子級別"sunshine"和"data"； -
"PV/sunshine"是一個布爾值（true/fault，也可以是 1/0），充電站需要它來知道是否應該裝載電動汽車（僅在陽光普照時 :)）。 -
充電站（EVSE）是訂閱者，訂閱
"PV/sunshine"從服務器獲取信息。 -
"PV/data"另一方面，以 kW 爲單位傳輸工廠產生的瞬時功率，並且該主題可以例如通過計算機或平板電腦訂閱，以生成一天內傳輸功率的圖表。
這就是一個簡單的 MQTT 的應用場景，具體如下圖所示；
QoS（Quality of Service levels）
服務質量是 MQTT 的一個重要特性。當我們使用 TCP/IP 時，連接已經在一定程度上受到保護。但是在無線網絡中，中斷和干擾很頻繁，MQTT 在這裏幫助避免信息丟失及其服務質量水平。這些級別在發佈時使用。如果客戶端發佈到 MQTT 服務器，則客戶端將是發送者，MQTT 服務器將是接收者。當 MQTT 服務器向客戶端發佈消息時，服務器是發送者，客戶端是接收者。
QoS 0
這一級別會發生消息丟失或重複，消息發佈依賴於底層 TCP/IP 網絡。即：<=1
QoS 1
QoS 1 承諾消息將至少傳送一次給訂閱者。
QoS 2
使用 QoS 2，我們保證消息僅傳送到目的地一次。爲此，帶有唯一消息 ID 的消息會存儲兩次，首先來自發送者，然後是接收者。QoS 級別 2 在網絡中具有最高的開銷，因爲在發送方和接收方之間需要兩個流。
2 MQTT 數據包結構
-
固定頭（Fixed header），存在於所有MQTT數據包中，表示數據包類型及數據包的分組類標識； -
可變頭（Variable header），存在於部分MQTT數據包中，數據包類型決定了可變頭是否存在及其具體內容； -
消息體（Payload），存在於部分MQTT數據包中，表示客戶端收到的具體內容；
整體 MQTT 的消息格式如下圖所示；
2.1 MQTT固定頭
固定頭存在於所有MQTT數據包中，其結構如下：
下面簡單分析一下固定頭的消息格式；
MQTT消息類型 / message type
位置： byte 1, bits 7-4。
4 位的無符號值，類型如下：
標識位 / DUP
位置： byte 1, bits 3-0。
在不使用標識位的消息類型中，標識位被作爲保留位。如果收到無效的標誌時，接收端必須關閉網絡連接：
-
DUP：發佈消息的副本。用來在保證消息的可靠傳輸，如果設置爲 1，則在下面的變長中增加 MessageId，並且需要回復確認，以保證消息傳輸完成，但不能用於檢測消息重複發送。 -
QoS發佈消息的服務質量（前面已經做過介紹），即：保證消息傳遞的次數-
00：最多一次，即：<=1 -
01：至少一次，即：>=1 -
10：一次，即：=1 -
11：預留
-
-
RETAIN：發佈保留標識，表示服務器要保留這次推送的信息，如果有新的訂閱者出現，就把這消息推送給它，如果設有那麼推送至當前訂閱者後釋放。
剩餘長度（Remaining Length）
位置：byte 1。
固定頭的第二字節用來保存變長頭部和消息體的總大小的，但不是直接保存的。這一字節是可以擴展，其保存機制，前 7 位用於保存長度，後一部用做標識。當最後一位爲 1 時，表示長度不足，需要使用二個字節繼續保存。例如：計算出後面的大小爲 0
2.2 MQTT可變頭 / Variable header
MQTT數據包中包含一個可變頭，它駐位於固定的頭和負載之間。可變頭的內容因數據包類型而不同，較常的應用是做爲包的標識：
很多類型數據包中都包括一個 2 字節的數據包標識字段，這些類型的包有：
PUBLISH (QoS> 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、
SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK
2.3 Payload消息體
Payload消息體是MQTT數據包的第三部分，CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE 四種類型的消息 有消息體：
-
CONNECT，消息體內容主要是：客戶端的 ClientID、訂閱的 Topic、Message 以及用戶名和密碼 -
SUBSCRIBE，消息體內容是一系列的要訂閱的主題以及QoS。 -
SUBACK，消息體內容是服務器對於SUBSCRIBE所申請的主題及QoS進行確認和回覆。 -
UNSUBSCRIBE，消息體內容是要訂閱的主題。
3 環境搭建
介紹完基礎理論部分，下面在 Windows 平臺上搭建一個簡單的 MQTT 應用，進行簡單的應用，整體架構如下圖所示；
[外鏈圖片轉存失敗, 源站可能有防盜鏈機制, 建議將圖片保存下來直接上傳 (img-ScRucIVO-1625480723109)(架構圖. png)]
3.1 MQTT 服務器搭建
目前 MQTT 代理的主流平臺有下面幾個：
-
Mosquitto：https://mosquitto.org/
-
VerneMQ：https://vernemq.com/
-
EMQTT：http://emqtt.io/
本文將使用 Mosquitoo 進行測試，進入到安裝頁面，下載自己電腦的系統所適配的程序；
安裝成功之後，進入到安裝路徑下，找到mosquitto.exe；
[外鏈圖片轉存失敗, 源站可能有防盜鏈機制, 建議將圖片保存下來直接上傳 (img-YXZupgOv-1625480723111)(image-20210705171401654.png)]
按住Shift，右鍵鼠標點擊空白處，然後打開Powershell，正常打開一個終端軟件即可；
-
輸入
./mosquitto.exe -h可以查看相應的幫助； -
輸入
./mosquitto.exe -p 10086，就開啓了 MQTT 服務，監聽的地址是127.0.0.1，端口是10086；
具體如下圖所示；
3.2 MQTT Client
服務器搭建好了，下面就是開啓客戶端，進行發佈和訂閱，這樣就可以傳輸相應的消息。
這裏我使用的是自己編譯了一個QT mqtt client 程序，是基於 Qt 的官方庫進行編譯的，下面打開這個軟件，下一期簡單介紹一下如何完成這個客戶端，並設置好相應參數：
-
地址：
127.0.0.1 -
端口：
10086
然後訂閱主題，就可以互相發送數據了，具體如下圖所示；
結合前面的圖片來看，整體的架構如下所示；
4 總結
本文簡單介紹了 MQTT 協議的工作原理，以及相應的協議格式，簡單介紹了協議的一些細節，具體舉出了相應的應用場景，作者水平和能力有限，文中難免存在錯誤和紕漏，請大佬不吝賜教。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rZ9ON7jf2prq6KZSuES1Yw