MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基于發布/訂閱（publish/subscribe）模式的"輕量級"通訊協議，該協議構建于TCP/IP協議上，由IBM在1999年發布。MQTT最大優點在于，可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。作為一種低開銷、低帶寬占用的即時通訊協議，使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。

MQTT是一個基于客戶端-服務器的消息發布/訂閱傳輸協議。MQTT協議是輕量、簡單、開放和易于實現的。

GitHub地址：
GitHub - mcxiaoke/mqtt: MQTT協議3.1.1中文翻譯版，IoT，物聯網

發布訂閱模式是傳統 Client/Server 模式的一種解耦方案。發布者通過 Broker 與消費者之間通信，Broker 的作用是將收到的消息通過某種過濾規則（Topic），正確地發送給消費者。發布/訂閱模式 相對于 客戶端/服務器模式 的好處在于：

1、發布者和消費者之間不必預先知道對方的存在，比如不需要預先溝通對方的 IP Address 和 Port

2、發布者和消費者之間不必同時運行。因為 Broker 是一直運行的?

在 MQTT 協議里，過濾規則?是?Topic。如：所有發布到?news?這個 Topic 的消息，都會被 Broker 轉發給已經訂閱了?news?的訂閱者

訂閱者預先訂閱了?news，然后發布者向 Broker 發布了一條消息 "some msg" 并指定發布到?news?主題，Broker 通過 Topic 匹配，決定將這條消息轉發給訂閱者

一、MQTT協議原理

1、MQTT協議實現方式

實現MQTT協議需要客戶端和服務器端通訊完成，在通訊過程中，MQTT協議中有三種身份：發布者（Publish）、代理（Broker）（服務器）、訂閱者（Subscribe）。其中，消息的發布者和訂閱者都是客戶端，消息代理是服務器，消息發布者可以同時是訂閱者。

MQTT傳輸的消息分為：主題（Topic）和負載（payload）兩部分：

（1）Topic，可以理解為消息的類型，訂閱者訂閱（Subscribe）后，就會收到該主題的消息內容（payload）；

（2）payload，可以理解為消息的內容，是指訂閱者具體要使用的內容。

2、網絡傳輸與應用消息

MQTT會構建底層網絡傳輸：它將建立客戶端到服務器的連接，提供兩者之間的一個有序的、無損的、基于字節流的雙向傳輸。

當應用數據通過MQTT網絡發送時，MQTT會把與之相關的服務質量（QoS）和主題名（Topic）相關連。

3、MQTT客戶端

一個使用MQTT協議的應用程序或者設備，它總是建立到服務器的網絡連接。客戶端可以：

（1）發布其他客戶端可能會訂閱的信息；

（2）訂閱其它客戶端發布的消息；

（3）退訂或刪除應用程序的消息；

（4）斷開與服務器連接。

4、MQTT服務器

MQTT服務器以稱為"消息代理"（Broker），可以是一個應用程序或一臺設備。它是位于消息發布者和訂閱者之間，它可以：

（1）接受來自客戶的網絡連接；

（2）接受客戶發布的應用信息；

（3）處理來自客戶端的訂閱和退訂請求；

（4）向訂閱的客戶轉發應用程序消息。

5、MQTT協議中的訂閱、主題、會話

一、訂閱（Subscription）

訂閱包含主題篩選器（Topic Filter）和最大服務質量（QoS）。訂閱會與一個會話（Session）關聯。一個會話可以包含多個訂閱。每一個會話中的每個訂閱都有一個不同的主題篩選器。

二、會話（Session）

每個客戶端與服務器建立連接后就是一個會話，客戶端和服務器之間有狀態交互。會話存在于一個網絡之間，也可能在客戶端和服務器之間跨越多個連續的網絡連接。

三、主題名（Topic Name）

連接到一個應用程序消息的標簽，該標簽與服務器的訂閱相匹配。服務器會將消息發送給訂閱所匹配標簽的每個客戶端

MQTT 的 Topic 有層級結構，并且支持通配符 + 和 #:

+是匹配單層的通配符。比如 news/+ 可以匹配 news/sports，news/+/basketball 可匹配到 news/sports/basketball
# 是一到多層的通配符。比如 news/# 可以匹配 news、 news/sports、news/sports/basketball 以及 news/sports/basketball/x 等等

MQTT 的主題是不要預先創建的，發布者發送消息到某個主題、或者訂閱者訂閱某個主題的時候，Broker 就會自動創建這個主題

四、主題篩選器（Topic Filter）

一個對主題名通配符篩選器，在訂閱表達式中使用，表示訂閱所匹配到的多個主題。

五、負載（Payload）

消息訂閱者所具體接收的內容。

6、MQTT協議中的方法

MQTT協議中定義了一些方法（也被稱為動作），來于表示對確定資源所進行操作。這個資源可以代表預先存在的數據或動態生成數據，這取決于服務器的實現。通常來說，資源指服務器上的文件或輸出。主要方法有：

（1）Connect。等待與服務器建立連接。

（2）Disconnect。等待MQTT客戶端完成所做的工作，并與服務器斷開TCP/IP會話。

（3）Subscribe。等待完成訂閱。

（4）UnSubscribe。等待服務器取消客戶端的一個或多個topics訂閱。

（5）Publish。MQTT客戶端發送消息請求，發送完成后返回應用程序線程。

二、MQTT協議數據包結構

在MQTT協議中，一個MQTT數據包由：固定頭（Fixed header）、可變頭（Variable header）、消息體（payload）三部分構成。MQTT數據包結構如下：

（1）固定頭（Fixed header）。存在于所有MQTT數據包中，表示數據包類型及數據包的分組類標識。

（2）可變頭（Variable header）。存在于部分MQTT數據包中，數據包類型決定了可變頭是否存在及其具體內容。

（3）消息體（Payload）。存在于部分MQTT數據包中，表示客戶端收到的具體內容

整體MQTT的消息格式如下圖所示

1、MQTT固定頭

固定頭存在于所有MQTT數據包中，其結構如下：

1.1、MQTT數據包類型

位置：**byte 1, bits 7-4

相于一個4位的無符號值，類型、取值及描述如下：

1.2、標識位/ DUP

位置：**byte 1, bits 3-0

在不使用標識位的消息類型中，標識位被作為保留位。如果收到無效的標志時，接收端必須關閉網絡連接：

（1）DUP：發布消息的副本。用來在保證消息的可靠傳輸，如果設置為1，則在下面的變長中增加MessageId，并且需要回復確認，以保證消息傳輸完成，但不能用于檢測消息重復發送。

（2）QoS：發布消息的服務質量，即：保證消息傳遞的次數

?00：最多一次，即：<=1
?
?01：至少一次，即：>=1
?
?10：一次，即：=1
?
?11：預留

（3）RETAIN： 發布保留標識，表示服務器要保留這次推送的信息，如果有新的訂閱者出現，就把這消息推送給它，如果設有那么推送至當前訂閱者后釋放。

1.3 剩余長度（Remaining Length）

地址：Byte 2。

固定頭的第二字節用來保存變長頭部和消息體的總大小的，但不是直接保存的。這一字節是可以擴展，其保存機制，前7位用于保存長度，后一部用做標識。當最后一位為1時，表示長度不足，需要使用二個字節繼續保存。例如：計算出后面的大小為0

2、MQTT可變頭

MQTT數據包中包含一個可變頭，它駐位于固定的頭和負載之間。可變頭的內容因數據包類型而不同，較常的應用是作為包的標識：

很多類型數據包中都包括一個2字節的數據包標識字段，這些類型的包有：

PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK。

3、Payload消息體

Payload消息體位MQTT數據包的第三部分，包含CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息：

（1）CONNECT，消息體內容主要是：客戶端的ClientID、訂閱的Topic、Message以及用戶名和密碼。

（2）SUBSCRIBE，消息體內容是一系列的要訂閱的主題以及QoS。

（3）SUBACK，消息體內容是服務器對于SUBSCRIBE所申請的主題及QoS進行確認和回復。

（4）UNSUBSCRIBE，消息體內容是要訂閱的主題

MQTT 的主要消息類型有：

項目	值	報文流動方向	描述
CONNECT	1	客戶端到服務端	客戶端請求連接服務端
CONNACK	2	服務端到客戶端	連接報文確認
PUBLISH	3	兩個方向都允許	發布消息
PUBACK	4	兩個方向都允許	QoS 1消息發布收到確認
PUBREC	5	兩個方向都允許	發布收到（保證交付第一步）
PUBREL	6	兩個方向都允許	發布釋放（保證交付第二步）
PUBCOMP	7	兩個方向都允許	QoS 2消息發布完成（保證交互第三步）
SUBSCRIBE	8	客戶端到服務端	客戶端訂閱請求
SUBACK	9	服務端到客戶端	訂閱請求報文確認
UNSUBSCRIBE	10	客戶端到服務端	客戶端取消訂閱請求
UNSUBACK	11	服務端到客戶端	取消訂閱報文確認
PINGREQ	12	客戶端到服務端	心跳請求
PINGRESP	13	服務端到客戶端	心跳響應
DISCONNECT	14	客戶端到服務端	客戶端斷開連接

其中0、15作為保留值, PINGREQ / PINGRESP 和 DISCONNECT 報文是不需要可變頭部的，也沒有 Payload，也就是說它們的報文大小僅僅消耗 2 個字節

三、MQTT與消息隊列的區別

1、MQTT 并不要求發布或者訂閱之前顯式地創建主題，唯一可能造成的不良影響是客戶端可能使用錯誤的主題而不自知，但顯然靈活部署帶來的收益更高

2、消息隊列主要用于服務端應用之間的消息存儲與轉發，這類場景往往數據量大但接入量少，而 MQTT 面向的是 IoT 領域和移動互聯網領域，這類場景的側重點是海量的設備接入、管理與消息傳輸

代理作為發布訂閱模式的關鍵角色，它需要準確、高效地向訂閱者轉發其期望的消息，一般來說，比較常用的有以下兩種方式：

根據主題。訂閱者向代理訂閱自己感興趣的主題，發布者發布的所有消息中都會包含自己的主題，代理根據消息的主題判斷需要將消息轉發給哪些訂閱者。
根據消息內容。訂閱者定義其感興趣的消息的條件，只有當消息的屬性或內容滿足訂閱者定義的條件時，消息才會被投遞到該訂閱者。嚴格來講，主題也可以算是消息內容的一種

開源 MQTT 服務器如何選擇

到目前為止，比較流行的開源 MQTT 服務器有幾個：

1. Eclipse Mosquitto

   使用 C 語言實現的 MQTT 服務器。Eclipse 組織還還包含了大量的 MQTT 客戶端項目：Eclipse Paho | The Eclipse Foundation

2. EMQX

   使用 Erlang 語言開發的 MQTT 服務器，內置強大的規則引擎，支持許多其他 IoT 協議比如 MQTT-SN、 CoAP、LwM2M 等。

3. Mosca

   使用 Node.JS 開發的 MQTT 服務器，簡單易用。

4. VerneMQ

   同樣使用 Erlang 開發的 MQTT 服務器.