1. MQTT 5.0 介紹
MQTT 協議 因為其輕量、靈活等特點成為了當今世界上最受歡迎的物聯網協議，它已經廣泛應用於車聯網、智能家居、物流、即時聊天應用和移動消息推送等領域，連接了數以億計的設備，並且每時每刻都有無數設備開始使用和接入 MQTT 協議。MQTT 協議為這些設備提供了穩定、可靠的通信基礎，這些設備龐大的接入數量也向 MQTT 協議規范提出了挑戰， MQTT 5.0 的誕生便是為了更好地滿足這一需求。
MQTT（消息隊列遙測傳輸）最初由 IBM 於上世紀 90 年代晚期發明。它最初的用途是將石油管道上的感測器與衛星相鏈接，所以 MQTT 從則搏局誕生之初就是專為受限設備和低帶寬、高延遲或不可靠的網路而設計，它使用了發布訂閱模型，在空間和時間上解耦了消息的發送者與接收者，並且基於 TCP/IP 提供穩定可靠的網路連接，擁有非常輕量的報頭以減少傳輸開銷，支持可靠消息傳輸，可以說天生就滿足了物聯網場景的各種需求。在 MQTT 3.1.1 發布並成為 OASIS 標準的四年後，MQTT 5.0 正式發布，銀雹這是一次重大的改進和升級，它的目的不僅僅是滿足現階段的行業需求，更是為行業未來的發展變化做了充足的准備。2019 年 3 月，MQTT 5.0 成為了新的 OASIS 標准。
面對迅速增長的設備數量和層出不窮的需求，OASIS MQTT 技術委員會需要從繁雜的需求中提取出通用部分，將其納入標准規范，並且盡可能不增加開銷或降低易用性，在不增加不必要的復雜性的前提下提高性能和易用性。
最終，OASIS MQTT 技術委員會為 MQTT 5.0 添加了大量的全新功能與特性，5.0 成為 MQTT 有史以來變化最大的一個孫讓版本。在這里，我們將列舉一些比較重要的特性：
完整的新屬性列表包含在協議標準的附錄C，您可以訪問以下網址了解詳情： http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs02/mqtt-v5.0-cs02.html#AppendixC 。
隨著各 MQTT 伺服器 廠商不斷加入 MQTT 5.0 的支持陣營（例如 EMQ 在 2018 年 9 月就已經完整支持了 MQTT 5.0 協議），整個行業生態逐步遷移至 MQTT 5.0 已經成為大的趨勢，MQTT 5.0 也將是未來絕大多數物聯網企業的首選。我們也希望用戶能夠盡早擁抱 MQTT 5.0 並且享受到它帶來的便利，這也是這篇文章的目的。如果您已經對 MQTT 5.0 產生了一些興趣，但還想了解更多，您可以嘗試閱讀以下文章，我們將以通俗易懂的方式為您介紹 MQTT 5.0 的重要特性：
2. MQTT 基本認知
物聯網 (internet of thing) ，表示的是可以把一些帶某些感測器的設備(終端)，接入到互聯網的行為。
通過互聯網連接這些設備，這些設備就能夠互相協作。
而 MQTT 就是這些設備之間數據通信的一個基於 TCP/IP 的協議。
每個終端都和實現了 MQTT 協議的代理/伺服器相連。
通過 published MQTT 代理伺服器的某個 主題 發送數據。
通過 subscription 從 MQTT 代理伺服器獲取自己訂閱的 主題 數據。
MQTT 協議是一種輕量級的、靈活的網路協議。並且非常適合 IOT 的場景。
大多數開發人員已經熟悉了 HTTP WEB 協議。那麼為什麼不讓 IOT 設置鏈接到 WEB 服務？
設備可以採用 HTTP 請求的形式發送數據，並採用 HTTP 響應的形式從伺服器獲取數據，接受更新。
因為對於 IOT 的設備來說，這種 主動請求--> 被動等待應答的 數據傳輸模型存在嚴重的局限性：
那麼，MQTT 為什麼如此輕便且靈活？MQTT 協議的一個關鍵的特性是 發布/訂閱模型 。它將數據的發布者和接受者分離。
一個設備終端既可以是數據的發布者 (published) 也可以是數據的訂閱者 (subscription) 。
一個設備如果要發布數據，只需要往代理伺服器中 相應的主題發布數據內容即可。
一個設備如果需要接受到數據，只需要在代理伺服器中， 提前訂閱自己需要關注的主題即可。
MQTT 最基本的體驗，就是使用 mosquitto 。
Mosquitto是一款實現了 MQTT v3.1 協議的開源消息代理軟體，提供輕量級的，支持發布/訂閱的的消息推送模式，使設備對設備之間的短消息通信簡單易用。
它可以理解成一個 MQTT 的代理伺服器。
基本步驟如下：
安裝成功截圖
使用 brew services start mosquitto 啟動 MQTT 服務
運行截圖
然後再打開另外兩個終端窗口，模擬兩個IOT設備。A 訂閱 MQTT 服務。B 向 MQTT 的服務發送數據。
A訂閱當前MQTT的某個服務。
B向 MQTT 伺服器發布(published) 數據。
然後，我們就可以在A控制台里看到由 B 通過 MQTT 服務發送的數據了。
基本流程圖
控制台 A 向 MQTT 伺服器訂閱 dw/demo 服務，並被動的等待 MQTT 伺服器返回數據。
控制台 B 主動的向 MQTT 伺服器的 dw/demo 服務發送 published 數據，之後。伺服器會主動向事先訂閱了 dw/demo 的終端分發此消息。
MQTT 是一種鏈接協議，它指定了如何組織數據位元組並通過 TCP/IP 網路傳輸它們。但實際上，開發人員並不需要鏈接這個鏈接協議的具體細節。我們只需要知道，每條消息都有一個命令和數據有效負載。該命令定義消息類型(比如 CONNECT 消息或者 SUB SCRIBE 消息)。所有的 MQTT 庫和工具都提供了直接處理這些消息的基本方法，並且能自動填充一些必要的欄位(在數據包的對應位元組填充)，比如消息和客戶端 ID。
首先客戶端發送一條 CONNECT消息 來鏈接代理。CONNECT 消息要求建立從客戶端到代理伺服器的鏈接。
CONNECT 命令的基本參數
當客戶端向代理伺服器發送一條 CONNECT 命令之後，伺服器會調用 CONNACK 命令，告知服務鏈接的狀態。
CONNACK 命令的基本參數
當客戶端和伺服器建立連接之後，客戶端就可以向伺服器訂閱某些主題的。(發送一條或多條 SUBSCRIBE消息 )。
表明當伺服器接受到其他終端推送的此主題數據時，伺服器會默認發送給它。
SUBSCRIBE 參數列表
當客戶端成功的向伺服器訂閱某個主題之後，伺服器會返回一條 SUBACK 的消息，其中包含一個或者多個 returnCode 參數。
SUBACK消息參數
returnCode : 值 0 - 2 ，表示成功訂閱，並返回這個訂閱消息的 QOS。值 128 ： 訂閱失敗。
既然客戶端可以向伺服器訂閱某個主題，當然也可以取消訂閱。
與 SUBSCRIBE 訂閱命令相反的命令是 UNSUBSCRIBE 取消訂閱命令。
此命令非常簡單。只有一個topic(主題)參數。
上面講的是訂閱，訂閱是需要有消息從伺服器發送過來的。但是伺服器本身基本不產生數據，那數據從何而來呢？
通過另外一個客戶端執行 PUBLISH 命令，往代理伺服器發送數據。並最終通過代理伺服器將數據傳遞給訂閱了此服務的客戶端。
PUBLISH 消息參數
對於 MQTT 的一張基本理解圖
基本流程圖：
最後總結
參考資料： 初識 MQTT
3. EMQ X 規則引擎系列 （八）橋接消息到 MQTT Broker
橋接是一種連接多猜畢局個 EMQ X 或者其他 MQTT 消息中間件的方式。不同於集群，工作在橋接模式下的節點之間不會復制主題樹和路由表。橋接模式所做的是：
工作在橋接模式下和工作在集群模式下有不同的應用場景，橋接可以完成一些單純使用集群無法實現的功能：
在具體應用中，一個橋接的發起節點可以被近似的看作一個遠程節點的客戶端。
該場景需要將 EMQ X 指定主題下且滿足條件的消息橋接到 EMQ X 或其他 MQTT Broker。
該場景下設備端上報信息如下：穗讓
當上報數據發動機轉速數值大於 8000 時，將該條信息部分數據橋接到指定伺服器。
為了避免與本地的 emqx 出現埠沖突的情況，這里臨時修改一下 mosquitto 的本地埠號。
打開 EMQ X Dashboard，進入左側菜單的 資源 頁面，點擊 新建 按鈕，鍵入 Mosquitto 伺服器信息進行資源創建。
EMQ X 集群中節點所在網路環境可能互不相通，資源創建成功後點擊列表中 狀態按鈕 ，查看各個節點資源連接狀況，如果節點上資源不可用，請檢查配置是否正確、網路連通性，並點擊 重連 按鈕手動重連。
進入左側菜單的 規則 頁面，點擊 新建 按鈕，進行規則創數吵建。這里選擇觸發事件 消息發布 ，在消息發布時觸發該規則進行數據處理。
選定觸發事件後，我們可在界面上看到可選欄位及示例 SQL：
規則引擎使用 SQL 語句處理規則條件，該業務中我們需要將 payload 中所有欄位單獨選擇出來，使用 payload.fieldName 格式進行選擇，還需要消息上下文的 topic 、 qos 、 id 信息，當前 SQL 如下：
使用 SQL 語句 WHERE 字句進行條件篩選，該業務中我們需要定義兩個條件：
組合上一步驟得到 SQL 如下：
藉助 SQL 測試功能，我們可以實時查看當前 SQL 處理後的數據輸出，該功能需要我們指定 payload 等模擬原始數據。
payload 數據如下，注意更改 tachometer 數值大小，以滿足 SQL 條件：
點擊 SQL 測試 切換按鈕，更改 topic 與 payload 為場景中的信息，點擊 測試 按鈕查看數據輸出：
測試輸出數據為：
測試輸出與預期相符，我們可以進行後續步驟。
SQL 條件輸入輸出無誤後，我們繼續添加相應動作，配置寫入 SQL 語句，將篩選結果橋接到 Mosquitto。
點擊響應動作中的 添加 按鈕，選擇 橋接數據到 MQTT Broker 動作，選取剛剛選定的資源。
我們成功創建了一條規則，包含一個處理動作，動作期望效果如下：
切換到 工具 --> Websocket 頁面，使用任意信息客戶端連接到 EMQ X，連接成功後在 消息 卡片發送如下信息：
點擊 發送 按鈕，發送成功後查看得到當前規則已命中統計值為 1。
命令行中查看數據表記錄得到數據如下：
至此，我們通過規則引擎實現了使用規則引擎橋接消息到 MQTT Broker 的業務開發。
准備另外一台 emqx 節點，啟動兩台 emqx。
打開 EMQ X Dashboard，進入左側菜單的 資源 頁面，點擊 新建 按鈕，鍵入 EMQ X 伺服器信息進行資源創建。
EMQ X 集群中節點所在網路環境可能互不相通，資源創建成功後點擊列表中 狀態按鈕 ，查看各個節點資源連接狀況，如果節點上資源不可用，請檢查配置是否正確、網路連通性，並點擊 重連 按鈕手動重連。
進入左側菜單的 規則 頁面，點擊 新建 按鈕，進行規則創建。這里選擇觸發事件 消息發布 ，在消息發布時觸發該規則進行數據處理。
選定觸發事件後，我們可在界面上看到可選欄位及示例 SQL：
規則引擎使用 SQL 語句處理規則條件，該業務中我們需要將 payload 中所有欄位單獨選擇出來，使用 payload.fieldName 格式進行選擇，還需要消息上下文的 topic 、 qos 、 id 信息，當前 SQL 如下：
使用 SQL 語句 WHERE 字句進行條件篩選，該業務中我們需要定義兩個條件：
組合上一步驟得到 SQL 如下：
藉助 SQL 測試功能，我們可以實時查看當前 SQL 處理後的數據輸出，該功能需要我們指定 payload 等模擬原始數據。
payload 數據如下，注意更改 tachometer 數值大小，以滿足 SQL 條件：
點擊 SQL 測試 切換按鈕，更改 topic 與 payload 為場景中的信息，點擊 測試 按鈕查看數據輸出：
測試輸出數據為：
測試輸出與預期相符，我們可以進行後續步驟。
SQL 條件輸入輸出無誤後，我們繼續添加相應動作，配置寫入 SQL 語句，將篩選結果橋接到另一個 EMQ X。
點擊響應動作中的 添加 按鈕，選擇 橋接數據到 MQTT Broker 動作，選取剛剛選定的資源。
我們成功創建了一條規則，包含一個處理動作，動作期望效果如下：
切換到 工具 --> Websocket 頁面，使用任意信息客戶端連接到 EMQ X，連接成功後在 消息 卡片發送如下信息：
點擊 發送 按鈕，發送成功後查看得到當前規則已命中統計值為 1。
使用命令行中查看數據表記錄得到數據如下：
至此，我們通過規則引擎實現了使用規則引擎橋接消息的業務開發。
4. 3. MQTT簡要介紹
——
[1.MQTT項目工程](https://github.com/LiamBindle/MQTT-C)
[2.MQTT API說明文檔](https://liambindle.ca/MQTT-C/group__api.html)
[3.MQTT協議中文版](https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/01-Introction.html)
MQTT是一個客戶端服務端架構的發布/訂閱模式的消息傳輸協議。它的設計思想是輕巧、開放、簡單、規范，易於實現。這些特點使得它對很多場景來說都是很好的選擇，特別是對於受限的環境如機器與機器的通信（M2M）以及物聯網環境（IoT）。
MQTT協議通過交換預定義的MQTT控制報文來通信。
報文格式: 固定包頭+可變包頭+payload。
固定包頭: 由兩個位元組組成
byte1 高四位表示控制報文的類型，低四位表示控制報文類型的標志位。
byte2表示剩餘長度，包括可變報頭和負載的數據。剩餘長度不包括用於編碼剩餘長度欄位本身的位元組數。
可變包頭：
某些MQTT控制報文包含一個可變報頭部分。它在固定報頭和負載之間。可變報頭的內容根據報文類型的不同而不同。可變報頭的報文標（Packet Identifier）欄位存在於在多個類型的報文里。
有效載荷：
對於PUBLISH來說有效載荷就是應用消息。
——1. 網路建立連接後，客戶端發送的第一個報文必須是CONNECT報文
——2. 客戶端只能發送一次CONNECT 報文，發送兩次會當作協議違規處理，並斷開連接。
——3. 有效載荷包括：客戶端唯一標識符，will主題，will消息，用戶名和密碼。
——4.可變包頭：協議名（protocol name）+協議級別（protocol level）+連接標志（connect flags）+保持連接（keep alive）。
——5. 協議名： MQTT的UTF-8編碼的字元串。(MSB+LSB +MQTT 六個位元組)
——6. 協議級別：一個位元組
——7. 連接標志：一個位元組，包含一些用於指定MQTT連接行為的參數。同時還指出有效載荷中的欄位是否存在。服務端必須驗證CONNECT控制報文的保留標志位（第0位）是否為0，如果不為0必須斷開客戶端連接。
——8. 清理會話：byte8 的bit1位標志。
這個二進制位指定了會話狀態的處理方式。客戶端和服務端可以保存會話狀態，以支持跨網路連接的可靠消息傳輸。這個標志位用於控
制會話狀態的生存時間。
標志設置為0：服務端必須基於當前會話（使用客戶端標識符識別）的狀態恢復與客戶端的通信。
標志設置為1：客戶端和服務端必須丟棄之前的任何會話並開始一個新的會話。會話僅持續和網路連接同樣長的時間。
——9. 遺囑標志 WILL FLAG: byte8的bit2位標志。
遺囑標志（Will Flag）被設置為1，表示如果連接請求被接受了，遺囑（Will Message）消息必須被存儲在服務端並且與這個網路連接關聯。之後網路連接關閉時，服務端必須發布這個遺囑消息，除非服務端收到DISCONNECT報文時刪除了這個遺囑消息。
服務端發送CONNACK報文響應從客戶端收到的CONNECT報文。服務端發送給客戶端的第一個報文必須是CONNACK。
如果客戶端在合理的時間內沒有收到服務端的CONNACK報文，客戶端應該關閉網路連接。合理 的時間取決於應用的類型和通信基礎設施。
CONNACK報文沒有有效載荷。
PUBLISH控制報文是指從客戶端向服務端或者服務端向客戶端傳輸一個應用消息。
固定包頭：
注意byte1的bit3為重發標志DUP。
如果DUP標志被設置為0，表示這是客戶端或服務端第一次請求發送這個PUBLISH報文。如果DUP標志被設置為1，表示這可能是一個早前報文請求的重發。
服務端發送PUBLISH報文給訂閱者時，收到（入站）的PUBLISH報文的DUP標志的值不會被傳播。發送（出站）的PUBLISH報文與收到（入站）的PUBLISH報文中的DUP標志是獨立設置的，它的值必須單獨的根據發送（出站）的PUBLISH報文是否是一個重發來確定。
可變包頭：
主題名 :topic name
報文標識符 ：packet identitfier。
有效載荷 ：有效載荷包含將被發布的應用消息。數據的內容和格式是應用特定的。有效載荷的長度這樣計算：用固定報頭中的剩餘長度欄位的值減去可變報頭的長度。包含零長度有效載荷的PUBLISH報文是合法的。
響應：PUBLISH報文的接收者必須按照根據PUBLISH報文中的QoS等級發送響應。
PUBACK報文是對QoS 1等級的PUBLISH報文的響應。
PUBACK報文沒有有效載荷。
PUBREC報文是對QoS等級2的PUBLISH報文的響應。它是QoS 2等級協議交換的第二個報文。
PUBREC報文沒有有效載荷。
PUBREL報文是對PUBREC報文的響應。它是QoS 2等級協議交換的第三個報文。
PUBREL報文沒有有效載荷。
PUBCOMP報文是對PUBREL報文的響應。它是QoS 2等級協議交換的第四個也是最後一個報文。
PUBCOMP報文沒有有效載荷。
客戶端向服務端發送 SUBSCRIBE 報文用於創建一個或多個訂閱。每個訂閱注冊客戶端關心的一個或多個主題。為了將應用消息轉發給與那些訂閱匹配的主題，服務端發送PUBLISH報文給客戶端。SUBSCRIBE報文也（為每個訂閱）指定了最大的QoS等級，服務端根據這個發送應用消息給客戶端。
有效載荷：
SUBSCRIBE報文的有效載荷包含了一個主題過濾器列表，它們表示客戶端想要訂閱的主題。SUBSCRIBE報文的有效載荷必須包含至少一對主題過濾器 和 QoS等級欄位組合。沒有有效載荷的SUBSCRIBE報文是違反協議的。
響應：
服務端收到客戶端發送的一個SUBSCRIBE報文時，必須使用SUBACK報文響應，SUBACK報文必須和等待確認的SUBSCRIBE報文有相同的報文標識符。
服務端發送SUBACK報文給客戶端，用於確認它已收到並且正在處理SUBSCRIBE報文。SUBACK報文包含一個返回碼清單，它們指定了SUBSCRIBE請求的每個訂閱被授予的最大QoS等級。
有效載荷：
有效載荷包含一個返回碼清單。每個返回碼對應等待確認的SUBSCRIBE報文中的一個主題過濾器。返回碼的順序必須和SUBSCRIBE報文中主題過濾器的順序相同。
客戶端發送UNSUBSCRIBE報文給服務端，用於取消訂閱主題。
有效載荷 ：
UNSUBSCRIBE報文的有效載荷包含客戶端想要取消訂閱的主題過濾器列表。
UNSUBSCRIBE報文中的主題過濾器必須是連續打包的、按照定義的UTF-8編碼字元串
UNSUBSCRIBE報文的有效載荷必須至少包含一個消息過濾器。沒有有效載荷的UNSUBSCRIBE報文是違反協議的。
響應：
UNSUBSCRIBE報文提供的主題過濾器（無論是否包含通配符）必須與服務端持有的這個客 戶端的當前主題過濾器集合逐個字元比較。如果有任何過濾器完全匹配，那麼它（服務端）自己的訂閱將被刪除，否則不會有進一步的處理。
如果服務端刪除了一個訂閱：
——它必須停止分發任何新消息給這個客戶端 []。
——它必須完成分發任何已經開始往客戶端發送的QoS 1和QoS 2的消息 []。
——它可以繼續發送任何現存的准備分發給客戶端的緩存消息。
服務端必須發送UNSUBACK報文響應客戶端的UNSUBSCRIBE請求。UNSUBACK報文必須包含和UNSUBSCRIBE報文相同的報文標識符 。即使沒有刪除任何主題訂閱，服務端也必須發送一個UNSUBACK響應 。
如果服務端收到包含多個主題過濾器的UNSUBSCRIBE報文，它必須如同收到了一系列的多個UNSUBSCRIBE報文一樣處理那個報文，除了將它們的響應合並到一個單獨的UNSUBACK報文外。
服務端發送UNSUBACK報文給客戶端用於確認收到UNSUBSCRIBE報文。
UNSUBACK報文沒有有效載荷。
客戶端發送PINGREQ報文給服務端的。用於：
1. 在沒有任何其它控制報文從客戶端發給服務的時，告知服務端客戶端還活著。
2. 請求服務端發送 響應確認它還活著。
3. 使用網路以確認網路連接沒有斷開。
保持連接（Keep Alive）處理中用到這個報文。
——PINGREQ報文沒有可變報頭。
——PINGREQ報文沒有有效載荷。
響應：
服務端必須發送 PINGRESP報文響應客戶端的PINGREQ報文。
服務端發送PINGRESP報文響應客戶端的PINGREQ報文。表示服務端還活著。
保持連接（Keep Alive）處理中用到這個報文。
PINGRESP報文沒有可變報頭。
PINGRESP報文沒有有效載荷。
DISCONNECT報文是客戶端發給服務端的最後一個控制報文。表示客戶端正常斷開連接。
DISCONNECT報文沒有可變報頭。
DISCONNECT報文沒有有效載荷。
響應：
客戶端發送DISCONNECT報文之後：
—— 必須關閉網路連接 [MQTT-3.14.4-1]。
——不能通過那個網路連接再發送任何控制報文。
服務端在收到DISCONNECT報文時：
——必須丟棄任何與當前連接關聯的未發布的遺囑消息。
——應該關閉網路連接，如果客戶端 還沒有這么做。
為了提供服務質量保證，客戶端和服務端有必要存儲會話狀態。在整個會話期間，客戶端和服務端都必須存儲會話狀態 。會話必須至少持續和它的活躍網路連接同樣長的時間。服務端的保留消息不是會話狀態的組成部分。服務端應該保留那種消息直到客戶端刪除它。
MQTT協議要求基礎傳輸層能夠提供有序的、可靠的、雙向傳輸（從客戶端到服務端 和從服務端到客戶端）的位元組流。
無連接的網路傳輸協議如UDP是不支持的，因為他們可能會丟失數據包或對數據包重排序。
MQTT按照這里定義的服務質量 (QoS) 等級分發應用消息。分發協議是對稱的，在下面的描述中，客戶端和服務端既可以是發送者也可以是接收者。分發協議關注的是從單個發送者到單個接收者的應用消息。服務端分發應用消息給多個客戶端時，每個客戶端獨立處理。分發給客戶端的出站應用消息和入站應用消息的QoS等級可能是不同的。
qos0：最多分發一次
qos1：至少分發一次
qos2：僅分發一次
客戶端設置清理會話（CleanSession）標志為0重連時，客戶端和服務端必須使用原始的報文標識符重發任何未確認的PUBLISH報文（如果QoS>0）和PUBREL報文 [MQTT-4.4.0-1]。這是唯一要求客戶端或服務端重發消息的情況。
服務端接管入站應用消息的所有權時，它必須將消息添加到訂閱匹配的客戶端的會話狀態。正常情況下，客戶端收到發送給它的訂閱的消息。客戶端也可能收到不是與它的訂閱精確匹配的消息。如果服務端自動給客戶端分配了一個訂閱，可能發生這種情況。正在處理UBSUBSCRIBE請求時也可能收到消息。客戶端必須按照可用的服務質量（QoS）規則確認它收到的任何PUBLISH報文，不管它選擇是否處理報文包含的應用消息 。
實現本章定義的協議流程時，客戶端必須遵循下列規則：
重發任何之前的PUBLISH報文時，必須按原始PUBLISH報文的發送順序重發（適用於QoS 1和QoS 2消息）[MQTT-4.6.0-1]。
——必須按照對應的PUBLISH報文的順序發送PUBACK報文（QoS 1消息）。
——必須按照對應的PUBLISH報文的順序發送PUBREC報文（QoS 2消息。
——必須按照對應的PUBREC報文的順序發送PUBREL報文（QoS 2消息）。
服務端必須默認認為每個主題都是有序的。它可以提供一個管理功能或其它機制，以允許將一個或多個主題當作是無序的 。
服務端處理發送給有序主題的消息時，必須按照上面的規則將消息分發給每個訂閱者。此外，它必須按照從客戶端收到的順序發送PUBLISH報文給消費者（對相同的主題和QoS）。
斜杠（『/』 U+002F）用於分割主題的每個層級，為主題名提供一個分層結構.
數字標志（『#』 U+0023）是用於匹配主題中任意層級的通配符。
加號 (『+』 U+002B) 是只能用於單個主題層級匹配的通配符。
服務端不能將 $ 字元開頭的主題名匹配通配符 (#或+) 開頭的主題過濾器.
$SYS/ 被廣泛用作包含伺服器特定信息或控制介面的主題的前綴。
應用不能使用 $ 字元開頭的主題。
訂閱 「#」 的客戶端不會收到任何發布到以 「$」 開頭主題的消息。
訂閱 「+/monitor/Clients」 的客戶端不會收到任何發布到 「$SYS/monitor/Clients」 的消息。
訂閱 「$SYS/#」 的客戶端會收到發布到以 「$SYS/」 開頭主題的消息。
訂閱 「$SYS/monitor/+」 的客戶端會收到發布到 「$SYS/monitor/Clients」 主題的消息。
如果客戶端想同時接受以 「$SYS/」 開頭主題的消息和不以 $ 開頭主題的消息，它需要同
時訂閱 「#」 和 「「$SYS/#」。
除非另有說明，如果服務端或客戶端遇到了協議違規的行為，它必須關閉傳輸這個協議違規控制報文的網路連接.
MQTT方案通常部署在不安全的通信環境中。在這種情況下，協議實現通常需要提供這些機制：
——用戶和設備身份認證
——服務端資源訪問授權
——MQTT控制報文和內嵌應用數據的完整性校驗
——MQTT控制報文和內嵌應用數據的隱私控制
作為傳輸層協議，MQTT僅關注消息傳輸，提供合適的安全功能是實現者的責任。使用TLS[RFC5246] 是比較普遍的選擇。
廣泛採用高級加密標准 [AES] 數據加密標准 [DES] 。
推薦使用為受限的低端設備特別優化過的輕量級加密國際標准 ISO 29192 [ISO29192] 。
如果MQTT在WebSocket [RFC6455] 連接上傳輸，必須滿足下面的條件：
——MQTT控制報文必須使用WebSocket二進制數據幀發送。如果收到任何其它類型的數據幀，接收者必須關閉網路連接 。
——單個WebSocket數據幀可以包含多個或者部分MQTT報文。接收者不能假設MQTT控制報文按WebSocket幀邊界對齊 。
——客戶端必須將字元串 mqtt 包含在它提供的WebSocket子協議列表裡 。
——服務端選擇和返回的WebSocket子協議名必須是 。
——用於連接客戶端和伺服器的WebSocket URI對MQTT協議沒有任何影響。
MQTT規范定義了MQTT客戶端實現和MQTT服務端實現的一致性要求
MQTT實現可以同時是MQTT客戶端和MQTT服務端。接受入站連接和建立到其它服務端的出站連接的服務端必須同時符合MQTT客戶端和MQTT服務端的要求 。
為了與任何其它的一致性實現交互操作，一致性實現不能要求使用在本規范之外定義的任何擴展 。
附錄：
控制報文類型
byte1：標志位flags：
5. 【內部分享】MQTT協議解讀及使用經驗
時間：2018-07-26
Q: 什麼是網路連接？
A: 網路連接是傳輸層定義的概念，在傳輸層以下只存在網路數據包的相互交換。
所謂連接，其實也不是在網路上有一條真實存在的數據通道。只要通信雙方在一段時間內持續保持數據包交換，就可以視為雙方建立的連接並沒有斷開。
連接的建立是依託於TCP協議的三次握手，一旦連接已經建立完畢，通信雙方就可以復用這條虛擬通道進行數據交換。如果連接保持長時間工作一直沒有被中斷，那麼這樣的TCP連接就俗稱為長連接。
Message Queue Telemetry Transport ，中文直譯： 消息隊列遙測傳輸協議 。
在MQTT協議被設計出來的年代，還沒有物聯網這么時髦的詞彙，當年叫做 遙測設備 。
MQTT協議真正開始聲名鵲起的原因，是其正好恰恰踩中移動互聯網發展的節拍，為消息推送場景提供了一個既簡便又具有良好擴展性的現成解決方案。
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
可以看出，MQTT對消息頭的規定十分精簡， 固定頭部佔用空間大小僅為1個位元組 ，一個最小的報文佔用的空間也 只有兩個位元組 （帶一位元組的長度標識位）。
這也是MQTT協議針對不穩定及帶寬低下的網路環境做出的特定設計 - - - - 盡可能地節省一切不必要的網路開銷 。
Q：為什麼MQTT協議需要心跳報文(PINGREQ, PINGRESP)來維護連接狀態，只監控該TCP的連接狀態是否可以實現目的？
A: TCP數據傳輸默認的超時時間過長，不符合應用層上細粒度的要求。
TCP數據傳輸超時的情況可分成三種： 服務端斷開 、 客戶端斷開 、 中間網路斷開 。
在前兩種場景下，若斷開操作是一方主動發起的，即表示為TCP連接正常結束，雙方走四次揮手流程；若程序異常結束，則會觸發被動斷開事件，通信另一方也能立刻感知到本次連接所打開的 Socket 出現中斷異常。
唯獨中間網路的狀態是通信雙方不能掌握的。 在Linux系統下 ，TCP的連接超時由內核參數來控制，如果通信中的一方沒有得到及時回復，默認會主動再嘗試 6次 。如果還沒有得到及時回應，那麼其才會認定本次數據超時。
連帶首次發包與六次重試，Linux系統下這7次發包的超時時間分別為 2的0次方 至 2的6次方 ，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT協議認為如此長的超時時間對應用層而言粒度太大，因此其在應用層上還單獨設計屬於自身的心跳響應控制。常見的MQTT連接超時多被設定為 60秒 。
擴展知識 - TCP的KeepAlive機制： http://hengyunabc.github.io/why-we-need-heartbeat/
由通信中的 報文標識符 ( Packet Identifier )傳達。
Q：僅Publish與Pubrec能保證消息只被投遞一次嗎？
A： 業務上可以實現，但MQTT協議並沒有如此設計，原因如下：
每個消息都會擁有屬於自己的報文標識符，但如果需要兩次數據交換就實現消息僅只收到一次，就需要通信雙方記錄下每次使用的報文標識符，並且在處理每一條消息時都需要去重處理，以防消息被重復消費。
但MQTT協議最初被設計的工作對象是輕量級物聯設備，為此在協議的設計中報文標識符被約定為 可重用 ，以減少對設備性能的消耗，換回的代價不得不使用四次網路數據交換，才能確保消息正好被消費一次。
Q：兩個不同客戶端在發布與訂閱同一Topic下的消息時，都可以提出通信Qos要求，此時以哪項為基準？
A： 偽命題，故意在分享時埋下坑，等人來踩。
兩個不同客戶端的通信是需要 Broker 進行中轉，而不是直連。因此，通信中存在兩個不同的會話，雙方的Qos要求僅僅作用於它們與 Broker 之間的會話，最終的Qos基準只會向最低要求方看齊。
例：遺囑消息的正確使用方式可參考此篇文章： https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament
雖然可以藉助 Retain Message 實現綁定一條消息至某個Topic，以達到消息的暫時保留目的。
但首先 Retain Message 並不是為存儲場景而設計的，再次MQTT協議並沒有對消息的持久化作出規定，也就是說Broker重啟後，現有保留消息也將丟失。
Q：兩種特殊消息的使用場景？
A： 遺囑消息，多用於客戶端間獲取互相之間異常斷線的消息通知；
保留消息，可保存 最近一條 廣播通知，多用於公告欄信息的發布。
Eclipse Mosquitto ：MQTT協議的最小集實現
有 EMQ , HiveMQ , RabbitMQ MQTT Adapter 等。
Qos=2 消息保障的網路I/O次數過多，如果不是必需，盡少在程序里使用此類消息。
畢竟當初其設計的目的是為了減少設備的性能佔用，但若應用場景並不是物聯網，而是用於手機、電腦或瀏覽器端等現在已不缺性能的設備上，最好在報文體中，使用UUID生成全局唯一的消息ID，然後自行在業務解析中判斷此報文是否被消費過。
或者，業務方在處理消息時保證其被消費的冪等性，也可消除重復消息對系統帶來的影響。
正如MQTT協議並沒有依賴TCP連接狀態，自己在應用層協議上實現心跳報文來控制連接狀態，業務方作為MQTT協議的使用者，也不要完全依賴協議的工作狀態，而是依託MQTT協議建立屬於業務本身的信息匯報機制，以加強系統的穩健性。
Retain Message 可視為客戶端主動拉取的行為。如果業務系統採用 HTTP+MQTT 雙協議描述業務過程，主動拉取的操作也可使用 HTTP 請求替代。
作為一個長連接型的應用，上線前需要根據業務量級，評估對操作系統 埠數 與 文件描述符 的佔用要求，以防伺服器資源被打滿。
在服務端的配置文件和客戶端的連接參數中，都擁有 max_inflight_messages 此項配置，來維護 Qos=1 or 2 消息是否被成功消費的狀態。
MQTT 最初被設計為物聯網級的通信協議，因此此參數的默認配額較小（大多數情況下被限制到10至20）。
但如果將MQTT協議應用至手機、PC或Web端的推送場景時，硬體性能已不在是瓶頸，在實際使用中推薦把此參數調大。
Mosquitto提供Bridge功能，需要我們自己配置。
Bridge 意為橋接，當我們把兩台Broker橋接在一起時，只需要修改一台Broker的配置，填上另一台Broker的運行地址。前一台Broker將作為客戶端發布與訂閱後一台Broker的所有Topic，實現消息互通的目的。
橋接帶來的問題有以下幾點：
我的建議：
Websockets協議被設計的目的是為瀏覽器提供一個全雙工的通信協議，方便實現消息推送功能。
在Websockets協議被設計出來前，受限於HTTP協議的一問一答模型，消息的推送只能靠輪詢來實現，在資源消耗與時效性保障上，均難以達到令人滿意的效果。
Websockets協議復用了HTTP協議的頭部信息，告知瀏覽器接下來的操作將觸發協議升級，然後通信雙方繼續復用HTTP的Header，但報文內容已轉變為雙方均接受的新協議的格式。
Websockets協議改進了網頁瀏覽中的消息推送的方式，因此被廣泛應用在聊天、支付通知等實時性要求比較高的場合下。
MQTT協議重點在於 消息隊列的實現，其對消息投遞的方式作出約定，並提供一些額外的通信保障 。
MQTT可採取原生的TCP實現，也有基於Websockets的實現版本。當然後者在網路位元組的利用率上，不如前者那麼精簡。但瀏覽器端無法直接使用TCP協議，所以就只能基於Websockets協議開發。
不過基於Websockets的應用也有方便之處：一是證書不需要額外配置，直接與網站共用一套基礎設施；二是可使用 Nginx 等工具管理流量，與普通HTTP流量可共用一套配置方法。
MQTT非常適合入門，原因如下：
實際的應用場景遠比理想中的復雜，無法一招走遍天下，必須做好取捨。
MQTT協議在這方面做得很優秀，以後工作中可以作為參考，設計好自己負責的業務系統。
6. Mqtt介紹一
MQTT ( 消息隊列遙測傳輸 )是ISO 標准(ISO/IEC PRF 20922)下戚坦基於發布/訂閱範式的消息協議。它工作在 TCP/IP協議族 上，是為硬體性能低下的遠程設備以及網路狀況糟糕的情況下而設計的發布/訂閱型消息協議，為此，它需要一個 消息中間件 。
MQTT是一個基於客戶端-伺服器的消息發布/訂閱傳輸協議。MQTT協議是輕量、簡單、開放和易於實現的，這些特點使它適用范圍非常廣泛。在很多情況下，包括受限的沖仔備環境中，如：機器與機器（M2M）通信和物聯網（IoT）。其在，通過衛星鏈路通信感測器、偶爾撥號的醫療設備、智能家居、及一些小型化設備中已廣泛使用。
MQTT協議是為大量計算能力有限，且工作在低帶寬、不可靠的網路的遠程感測器和控制設備通訊而設計的協議，它具有以下主要的幾項特性：
實現MQTT協議需要客戶端和伺服器端通訊完成，在通訊過程中，MQTT協議中有三種身份： 發布者（Publish） 、 代理（Broker） （伺服器） 、訂閱者（Subscribe） 。其中，消息的發布者和訂閱者都是客戶端，消息代理是伺服器，消息發布者可以同時是訂閱者。
MQTT傳輸的消息分為： 主題（Topic）和負載（payload） 兩部分：
MQTT伺服器以稱為"消息代理"（Broker），可以是一個應用程序或一台設備。它是位於消息發布者和訂閱者之間，它可以：
在MQTT協議中，一個MQTT數據包由： 固定頭（Fixed header）、可變頭（Variable header）、消息體（payload） 三部分構成。MQTT數據包結構如下：
（1） 固定頭（Fixed header） 。存在於所有散毀MQTT數據包中，表示數據包類型及數據包的分組類標識。
（2） 可變頭（Variable header） 。存在於部分MQTT數據包中，數據包類型決定了可變頭是否存在及其具體內容。
（3） 消息體（Payload） 。存在於部分MQTT數據包中，表示客戶端收到的具體內容。
固定頭存在於所有MQTT數據包中，其結構如下：
相於一個4位的無符號值，類型、取值及描述如下
在不使用標識位的消息類型中，標識位被作為保留位。如果收到無效的標志時，接收端必須關閉網路連接：
Payload消息體位MQTT數據包的第三部分，包含CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息：
7. 一文讀懂物聯網的靈魂MQTT
名詞釋義：
MQTT——Message Queuing Telemetry Transport消息隊列遙測傳輸
PUB——Publish發布
QoS——Quality of Service服務質量
LWT——Last Will & Testament最後遺囑
MQTT簡介
3.2 通配符
MQTT 中有兩個可用的通配符，分別是+和#，+表示匹配單一層級中的任意主題，#表示匹配任意數量的層次。
3.3 服務質量（QoS）
MQTT 的設計初衷是為了在不可靠的網路中運作良好，為不同的場景提供了三個級別的殲賀服務質量，允許客戶端指定自己想要的可靠性級別。
3.3.1 QoS Level 0：至多一次
這是最簡單的級別，無需客戶端確認，其可靠性與基礎網路層 TCP/IP 一致。
3.3.2 QoS Level 1：至少沖歲一次，有可能重復
確保至少向客戶端發送一次信息，不過也可發送多次；在接收數據包時，需要客戶端返回確認消息（ACK 包）。這種方式常用於傳遞確保交付的信息，但開發人員必須確保其系統可以處理重復的數據包。
3.3.3 QoS Level 2：只有一次，確保消息只散改睜到達一次
這是最不常見的服務質量級別，確保消息發送且僅發送一次。這種方法需要交換4個數據包，同時也會降低消息代理的性能。由於相對比較復雜，在 MQTT 實現中通常會忽略這個級別，請確保在選擇資料庫或消息代理前檢查這個問題。
3.4 「臨終遺囑」信息
MQTT提供了檢測方式，利用KeepAlive機制在客戶端異常斷開時發現問題。因此當客戶端電量耗盡、崩潰或者網路斷開時，消息代理會採取相應措施。
客戶端會向任意點的消息代理發送「臨終遺囑」（LWT）信息，當消息代理檢測到客戶端離線（連接並未關閉），就會發送保存在特定主題上的 LWT 信息，讓其它客戶端知道該節點已經意外離線。
3.5保留消息 Retained Messages
1個Topic只有唯一的retain消息，Broker會保存每個Topic的最後一條retain消息。
8. MQTT客戶端設置
MQTTBox
從MQTTBox應用程序創建新的MQTT客戶端時，您可以指定各種連接設置。大多數設置默認設置為最常用的值，但是您可能仍需要自定義設置以根據需要測試MQTT客戶端。本文檔詳細解釋了每個客戶端設置屬性，以便更好地理解客戶端連接和實際的MQTT協議。
MQTT客戶端名稱： 用於標識MQTT客戶端並在儀錶板上顯示的名稱。它可以是任何字元串值。
例如：client_test_1
客戶端ID： 客戶端標識符是連接猛燃到MQTT代理的每個MQTT客戶端的標識符。對於給定的經紀人，每個客戶應該是唯一的。代理使用它來識別客戶端和客戶端的當前狀態。它默認是自動生成的。如果嘗試連接具有相同客戶端標識符的兩個MQTT客戶端，則代理將拒絕連接。當您打開2個MQTTBox應用程序實例時，請確保您擁有唯一的客戶端ID，否則您的客戶將被代理拒絕並可能顯示為離線。
例如：client_id_1
將時間戳附加到MQTT客戶端ID？： 如果選中，則時間戳將附加到客戶端ID。默認情況下啟用此選項。很多時候，用戶在相同或不同的機器上打開多個MQTTBox應用程序實例，這些機器具有相同的MQTT客戶端設置，包括不同的客戶端ID。這會導致客戶端連接由於相同的客戶端ID而被代理拒絕。如果啟用此選項，MQTTBox會將時間戳附加到每個客戶端ID，使其幾乎唯一，這有助於您節省調試不必要問題的時間。
Broker是否符合MQTT v3.1.1 ?: 如果要連接的MQTT代理僅支持舊版本的MQTT協議3.1或更低版本（v3.1.1是最新版本和當前標准版），則應取消選中此選項。默認情況下，它會被檢查並假定MQTT代理符合當前的MQTT標准v3.1.1（或更高版本）。
協議： MQTT客戶端用於連接MQTT代理的網路協議。
MQTTBox支持TCP，SSL / TLS，MQTT，MQTTS，WebSockets（WS）和Secure WebSockets（WSS）。根據您使用MQTTBox應用程序的平台，由於平台限制，可能不支持所有協議。
請 在此處 查看每個平台支持的MQTTBox功能列表。
主機： 要連接的MQTT主機。確保根據所選的MQTT連接協議指定正確的主機和埠號。如果您念叢提到錯誤的埠號或交換埠號，MQTT客戶端可能無法連接。
例如：test.mosquitto.org:8080
Clean Session？ ：clean session標志指示代理是否客戶端想要建立持久會話。如果您需要持久會話，即代理將存儲客戶端的所有訂閱以及所有丟失的消息，則在訂閱服務質量（QoS）1或2時，取消選中/不選擇此選項。默認情況下會選中此選項或是，這意味著代理將啟動新會話，不會為客戶端存儲任何內容，也會清除先前持久會話中的所有信息。
在應用程序啟動時自動連接？： 如果您選中/是此選項，客戶端將嘗試在啟動MQTTBox應用程序時自動連接到代理，並且可以處於「已連接」或「連接錯誤」狀態，具體取決於客戶端是否已連接到代理或不。如果未選中/沒有此選項，客戶端將處於「未連接」狀態，您需要手動將客戶端連接到代理。
您可以從MQTTBox儀錶板連接，斷開連接，重新連接MQTT客戶端
用戶名： 經紀人所需的用戶名（如果有）。MQTT允許發送用於驗證和授權客戶端的用戶名。
密碼： 經紀人要求的密碼（如果有）。MQTT允許發送密碼以進行客戶端的身份驗證和授權。 請注意，所有密碼都以純文本格式保存。確保您永遠不會在MQTTBox應用程仔知櫻序中保存生產密碼。事實上，所有欄位都保存為純文本，請確保您永遠不會在MQTTBox應用程序中保存任何敏感信息/設置 。
重新安排Ping？ 如果選中/是，則在發送數據包後重新安排ping消息。
隊列傳出QoS零消息： 如果選中/是，如果客戶端和代理之間的連接斷開，則客戶端隊列的傳出QoS零消息。建立連接後，將發布所有這些消息。
重新連接周期（以毫秒為單位）： 兩次重新連接之間的間隔
連接超時（以毫秒為單位）： 收到CONNACK之前等待的時間
KeepAlive（以秒為單位）： keep alive是一個時間間隔，客戶端通過向代理發送常規PING請求消息來提交。具有PING響應和這種機制的代理響應將允許雙方確定另一方是否仍然存活且可達。默認設置為10秒，設置為0表示禁用。
Will Settings - will消息是MQTT Client最後遺囑的一部分。當客戶端斷開連接時，它允許通知其他客戶端。連接客戶端將在CONNECT消息中以MQTT消息和主題的形式提供其意願。如果此客戶端無法正常斷開連接，則代理會自動代表客戶端發送此消息。
將設置 - 主題： 要發布的主題將是有效負載。一個簡單的字元串，可以使用正斜杠作為分隔符進行分層結構化。
例如：topic_test_1或家庭/廚房/濕度
將設置 - QoS： 發布具有QoS集的有效負載。默認情況下為0。
將設置 - 保留： 保留will有效載荷的標志。
將設置 - 有效負載： 客戶端斷開連接時要發布的消息。
要發布 的主題 ： 是要發布到的主題。一個簡單的字元串，可以使用正斜杠作為分隔符進行分層結構化。
例如：topic_test_1或家庭/廚房/濕度
QoS： 此消息的服務質量等級（QoS）。級別（0,1或2）確定傳遞的消息的保證。
保留： 此標志確定代理是否將消息作為上一個已知的良好值保存到指定主題。訂閱該主題的新客戶將在訂閱後立即收到有關該主題的最後保留消息。
要刪除主題的保留消息，請發送包含該主題的零位元組負載的保留消息。
有效負載： 這是要發布到主題的消息的實際內容。
主題： 是要訂閱的String主題。您可以為主題指定單級（+）和多級（＃）訂閱。
例如：topic_test_1或家庭/ + /濕度或家庭/＃
QoS： 此消息的服務質量等級（QoS）。級別（0,1或2）確定傳遞的消息的保證。
9. 阿里雲微消息隊列（MQTT）的基本使用
最近應系統功能需求，采購了一款雲喇叭的物聯網設備，就是插著4G卡那種，可以播放各種語音，仔細閱讀了開發文檔之改粗後發現使用的是MQTT的協議，記錄一下在對接中遇到的各種凱核問題
MQTT是一個輕量的發布訂閱模式消息傳輸協議，專門針對低帶寬和不穩核孫鎮定網路環境的物聯網應用設計。
MQTT特點：
阿里雲的MQTT有兩個版本，這里只說沒有RocketMQ依賴的3.1.1及以上版本。
這里會自動生成用戶名密碼
10. MQTT簡單介紹
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基於發布/訂閱模式的"輕量級"通訊協議，該協議構建於TCP/IP協議上。好比你給好友發送一封電子郵件，發送完成後你可以去做別的事情，收件人也不必立刻響應，可以在自己有空的時候查看郵件，是一個典型的異者彎步發布/訂閱場景。而另一種典型的同步請求/回答場景，可以用接打電話的場景來類比。
MQTT的設計遵循以下的原則：
為了滿足不同的場景，MQTT支持三種不同級別的服務質量（Quality of Service，QoS）為不同場景提供消息可靠性：
MQTT擁有14種不同的消息類型：
實現MQTT協議需要客戶端和伺服器端通訊完成，在通訊過程中，MQTT協議中有三種身份：發布者（Publish）、代理（Broker）（伺服器）、訂閱者（Subscribe）。其中，消息的發布者和訂閱者都是客戶端，消息代理是伺服器，消息發布者可以同時是訂閱者。
MQTT傳輸的消息分為：主題（Topic）和負載（payload）兩部分：
MQTT會構建底層網路傳輸：它將建立客戶端到伺服器的連接，提供兩者之間的一個有序的、無損的櫻嫌蔽、基於位元組流的雙向傳輸。
當應用數據通過MQTT網路發送時，MQTT會把與之相關的服務質量（QoS）和主題名（Topic）相關連。
一個使用MQTT協議的應用程序或者設備，它總是建立到伺服器的網路連接。客戶端可以：
MQTT伺服器以稱為"消息代理"（Broker），可以是一個應用程序或一台設備。它是位於消息發布者和訂閱者之間，它可以：
訂閱包含主題篩選器（Topic Filter）和最大服務質量（QoS）。訂閱會與一個會話（Session）關聯。一個會話可以包含多個訂閱。每一個會話中的每個訂閱都有一個不同的主題篩選器。
每個客戶端與伺服器建立連接後就是一個會話，客戶端和伺服器之間有狀態交互。會話存在於一個網路之間，也可能在客戶端和伺服器之間跨越多個連續的網路連接。
連接到一個應用程序消息的標簽，該標簽與伺服器的訂閱相匹配。伺服器會將消息發送給訂閱所匹配標簽的每個客戶端。
一個對主題名通配符篩選器，在訂閱表達式脊州中使用，表示訂閱所匹配到的多個主題。
消息訂閱者所具體接收的內容。
MQTT協議中定義了一些方法（也被稱為動作），來於表示對確定資源所進行操作。這個資源可以代表預先存在的數據或動態生成數據，這取決於伺服器的實現。通常來說，資源指伺服器上的文件或輸出。主要方法有：