什么是MQTT

MQTT（Message Queuing Telemetry Transport）是一種輕量級、基于發布-訂閱模式的消息傳輸協議，適用于資源受限的設備和低帶寬、高延遲或不穩定的網絡環境。它在物聯網應用中廣受歡迎，能夠實現傳感器、執行器和其它設備之間的高效通信。

為什么 MQTT 是適用于物聯網的最佳協議？

MQTT 所具有的適用于物聯網特定需求的特點和功能，使其成為物聯網領域最佳的協議之一。它的主要特點包括：

• 輕量級：物聯網設備通常在處理能力、內存和能耗方面受到限制。MQTT 開銷低、報文小的特點使其非常適合這些設備，因為它消耗更少的資源，即使在有限的能力下也能實現高效的通信。
• 可靠：物聯網網絡常常面臨高延遲或連接不穩定的情況。MQTT 支持多種 QoS 等級、會話感知和持久連接，即使在困難的條件下也能保證消息的可靠傳遞，使其非常適合物聯網應用。
• 安全通信：安全對于物聯網網絡至關重要，因為其經常涉及敏感數據的傳輸。為確保數據在傳輸過程中的機密性，MQTT 提供傳輸層安全（TLS）和安全套接層（SSL）加密功能。此外，MQTT 還通過用戶名/密碼憑證或客戶端證書提供身份驗證和授權機制，以保護網絡及其資源的訪問。
• 雙向通信：MQTT 的發布-訂閱模式為設備之間提供了無縫的雙向通信方式。客戶端既可以向主題發布消息，也可以訂閱接收特定主題上的消息，從而實現了物聯網生態系統中的高效數據交換，而無需直接將設備耦合在一起。這種模式也簡化了新設備的集成，同時保證了系統易于擴展。
• 連續、有狀態的會話：MQTT 提供了客戶端與 Broker 之間保持有狀態會話的能力，這使得系統即使在斷開連接后也能記住訂閱和未傳遞的消息。此外，客戶端還可以在建立連接時指定一個保活間隔，這會促使 Broker 定期檢查連接狀態。如果連接中斷，Broker 會儲存未傳遞的消息（根據 QoS 級別確定），并在客戶端重新連接時嘗試傳遞它們。這個特性保證了通信的可靠性，降低了因間斷性連接而導致數據丟失的風險。
• 大規模物聯網設備支持：物聯網系統往往涉及大量設備，需要一種能夠處理大規模部署的協議。MQTT 的輕量級特性、低帶寬消耗和對資源的高效利用使其成為大規模物聯網應用的理想選擇。通過采用發布-訂閱模式，MQTT 實現了發送者和接收者的解耦，從而有效地減少了網絡流量和資源使用。此外，協議對不同 QoS 等級的支持使得消息傳遞可以根據需求進行定制，確保在各種場景下獲得最佳的性能表現。
• 語言支持：物聯網系統包含使用各種編程語言開發的設備和應用。MQTT 具有廣泛的語言支持，使其能夠輕松與多個平臺和技術進行集成，從而實現了物聯網生態系統中的無縫通信和互操作性。您可以閱讀我們的 MQTT 客戶端編程系列文章，學習如何在 PHP、Node.js、Python、Golang、Node.js 等編程語言中使用 MQTT。

MQTT 的工作原理

要了解 MQTT 的工作原理，首先需要掌握以下幾個概念：MQTT 客戶端、MQTT Broker、發布-訂閱模式、主題、QoS。

MQTT 客戶端

任何運行 MQTT 客戶端庫的應用或設備都是 MQTT 客戶端。例如，使用 MQTT 的即時通訊應用是客戶端，使用 MQTT 上報數據的各種傳感器是客戶端，各種 MQTT 測試工具也是客戶端。

MQTT Broker

MQTT Broker 是負責處理客戶端請求的關鍵組件，包括建立連接、斷開連接、訂閱和取消訂閱等操作，同時還負責消息的轉發。一個高效強大的 MQTT Broker 能夠輕松應對海量連接和百萬級消息吞吐量，從而幫助物聯網服務提供商專注于業務發展，快速構建可靠的 MQTT 應用。

關于 MQTT Broker 的更多詳情，請參閱文章 2023 年最全面的 MQTT Broker 比較指南。

發布-訂閱模式

發布-訂閱模式與客戶端-服務器模式的不同之處在于，它將發送消息的客戶端（發布者）和接收消息的客戶端（訂閱者）進行了解耦。發布者和訂閱者之間無需建立直接連接，而是通過 MQTT Broker 來負責消息的路由和分發。

下圖展示了 MQTT 發布/訂閱過程。溫度傳感器作為客戶端連接到 MQTT Broker，并通過發布操作將溫度數據發布到一個特定主題（例如 Temperature）。MQTT Broker 接收到該消息后會負責將其轉發給訂閱了相應主題（Temperature）的訂閱者客戶端。

主題

MQTT 協議根據主題來轉發消息。主題通過 / 來區分層級，類似于 URL 路徑，例如：

chat/room/1
sensor/10/temperature
sensor/+/temperature

MQTT 主題支持以下兩種通配符：+ 和 #。

• +：表示單層通配符，例如 a/+ 匹配 a/x 或 a/y。
• #：表示多層通配符，例如 a/# 匹配 a/x、a/b/c/d。

注意：通配符主題只能用于訂閱，不能用于發布。

關于 MQTT 主題的更多詳情，請參閱文章通過案例理解 MQTT 主題與通配符。

QoS

• MQTT 提供了三種服務質量（QoS），在不同網絡環境下保證消息的可靠性。
• QoS 0：消息最多傳送一次。如果當前客戶端不可用，它將丟失這條消息。
• QoS 1：消息至少傳送一次。
• QoS 2：消息只傳送一次。
  關于 MQTT QoS 的更多詳情，請參閱文章 MQTT QoS 0, 1, 2 介紹。

MQTT 的工作流程

在了解了 MQTT 的基本組件之后，讓我們來看看它的一般工作流程：

1. 客戶端使用 TCP/IP 協議與 Broker 建立連接，可以選擇使用 TLS/SSL 加密來實現安全通信。客戶端提供認證信息，并指定會話類型（Clean Session 或 Persistent Session）。
2. 客戶端既可以向特定主題發布消息，也可以訂閱主題以接收消息。當客戶端發布消息時，它會將消息發送給 MQTT Broker；而當客戶端訂閱消息時，它會接收與訂閱主題相關的消息。
3. MQTT Broker 接收發布的消息，并將這些消息轉發給訂閱了對應主題的客戶端。它根據 QoS 等級確保消息可靠傳遞，并根據會話類型為斷開連接的客戶端存儲消息。

開始使用 MQTT：快速教程

下面我們將通過一些簡單的示例來展示如何使用 MQTT。在開始之前，需要準備 MQTT Broker 和 MQTT 客戶端。

準備 MQTT Broker–EMQX

EMQX

EMQ X (Erlang/Enterprise/Elastic MQTT Broker) 是基于 Erlang/OTP 平臺開發的開源物聯網 MQTT 消息服務器。Erlang/OTP 是出色的軟實時(Soft-Realtime)、低延時(Low-Latency)、分布式(Distributed) 的語言平臺。MQTT 是輕量的(Lightweight)、發布訂閱模式(PubSub) 的物聯網消息協議。

下載和安裝

文檔：下載EMQX開源版本

web訪問

http://localhost:18083 來查看Dashboard，默認用戶名是 admin，密碼是 public。

文檔

EMQX文檔

• EMQX 快速入門指南
• EMQX Dashboard 介紹
• 如何進行訪問控制
• 如何使用數據集成
• 如何使用規則引擎
• EMQX 配置文件指南
• 使用 EMQX REST API

準備 MQTT 客戶端–MQTTX

MQTTX

MQTTX 是 EMQ 開源的一款優雅的跨平臺 MQTT 5.0 客戶端工具，它支持 macOS、Linux 和 Windows，并且支持 MQTT 消息格式轉換。

MQTTX 的用戶界面借助聊天軟件的形式簡化了頁面的操作邏輯，用戶可以快速創建連接保存并同時建立多個連接客戶端，方便用戶快速測試 MQTT/TCP、MQTT/TLS、和 MQTT/WebSocket 的 連接/發布/訂閱 功能及其他特性。

windows客戶端工具

下載：https://mqttx.app/zh
文檔：https://mqttx.app/zh/docs

MQTTX CLI

MQTTX CLI 是 EMQ 開源的一款 MQTT 5.0 命令行客戶端工具，也是命令行上的 MQTTX，旨在幫助開發者在不需要使用圖形化界面的基礎上，也能更快的開發和調試 MQTT 服務與應用。
文檔：https://mqttx.app/zh/docs/cli

MQTTX Web

MQTTX Web 是一款開源的 MQTT 5.0 瀏覽器客戶端，也是一個在線 MQTT WebSocket 客戶端工具。使用 WebSocket 在瀏覽器中連接到 MQTT，幫助開發者更快地開發和調試 MQTT 服務和應用程序，而不必在本地下載和安裝 MQTTX。
在線地址：https://mqttx.app/web-client#/recent_connections
文檔：https://mqttx.app/zh/docs/web

創建 MQTT 連接

具體文檔查看 MQTT 協議入門：基礎知識和快速教程

MQTT入門

• MQTT 協議入門：基礎知識和快速教程
• MQTT 發布/訂閱模式介紹
• 創建 MQTT 連接時如何設置參數？
• 通過案例理解 MQTT 主題與通配符
• MQTT會話詳情
• MQTT QoS 0, 1, 2 介紹

MQTT進階

• 保留消息（Retained Messages）
• 遺愿消息（Will Messages）
• 請求/響應（Request/Response）
• 用戶屬性（User Properties）
• 主題別名（Topic Alias）
• 載荷格式指示與內容類型（Payload Format Indicator & Content Type）
• 共享訂閱（Shared Subscriptions）
• 訂閱選項（Subscription Options）
• 訂閱標識符（Subscription Identinfier）
• 保持連接（Keep Alive）
• 消息過期間隔（Message Expiry Interval）
• 最大報文大小（Maximum Packet Size）
• 原因碼以速查表（Reason Code & Quick Reference）
• 增強認證（Enhanced Authentication）
• 控制報文（Control Packets）

MQTT編程

服務端

• 如何在 Python 中使用 MQTT
• 如何在 Java 中使用 MQTT
• 如何在 Node.js 項目中使用 MQTT
• 如何在 PHP 項目中使用 MQTT
• 如何在 Golang 中使用 MQTT
• 如何在 Rust 中使用 MQTT
• 開發指南：使用 MQTTNet 庫構建 .Net 物聯網 MQTT 應用程序
• 如何在 Dart 中使用 MQTT

前端

• MQTT.js 入門教程
• 使用 WebSocket 連接 MQTT 服務器
• 如何在 Vue 項目中使用 MQTT
• 如何在 React 項目中使用 MQTT
• 如何在 Angular 項目中使用 MQTT
• 如何在 Electron 項目中使用 MQTT

移動端

• 如何在 React Native 項目中使用 MQTT
• CocoaMQTT v2.0：首個支持 MQTT 5.0 的 iOS 客戶端
• Android 使用 Kotlin 連接 MQTT
• 在 Flutter 項目中使用 MQTT
• Android MQTT TLS/SSL 認證

硬件

• 在樹莓派上使用 MQTT
• 在樹莓派中使用 MicroPython 接入 MQTT
• ESP32 連接到免費的公共 MQTT 服務器
• ESP8266 連接到免費的公共 MQTT 服務器
• ESP8266 + MQTT ：如何實現 LED 燈的遠程控制
• 通過 NodeMCU (ESP8266) 將傳感器數據上傳至 MQTT 云服務

MQTT術語表

Broker

有時我們也會直接將服務端稱為 Broker，這兩個術語可以互換使用。

Clean Start

客戶端可以在連接時使用這個字段來指示是期望從已存在的會話中恢復通信，還是創建一個全新的會話。僅限 MQTT v5.0。

Client

使用 MQTT 協議連接到服務端的設備或應用程序，并通過服務端完成發布訂閱。

Client ID

Client ID 用于唯一標識客戶端連接與會話，MQTT 允許客戶端自行指定 Client ID，也支持由服務端統一為客戶端分配 Client ID。

Connection

MQTT 客戶端與 MQTT 服務端之間的網絡連接。MQTT 客戶端之間并不會直接建立連接。

Content Type

用來描述消息的內容類型，方便接收方處理。可以使用 MIME 類型，例如 text/plain，也可以使用自定義的字符串來描述消息內容。僅限 MQTT v5.0。

Enhanced Authentication

MQTT v5.0 通過新增的 AUTH 報文實現了對增強認證的支持，在原先通過 Username 和 Password 提供的密碼認證和 Token 認證的基礎上進行了擴展。

它更像是一種認證框架，允許使用各種更安全的認證機制，例如 SCRAM 認證就支持服務端和客戶端互相確認對方的身份，以抵御中間人攻擊。

Flow Control

MQTT v5.0 引入了流控機制，允許客戶端和服務端根據自己的接收能力約定對方的最大消息發送速率，避免了一方發送過快，導致網絡擁塞和接收方過載的問題。

Keep Alive

Keep Alive 表示客戶端在傳輸完成一個 MQTT 控制報文到發送下一個報文，兩者之間允許空閑的最大的時間間隔。

如果沒有其他控制報文可以發送，客戶端必須發送一個 PINGREQ 報文。

如果服務端在 1.5 倍的 Keep Alive 時間內沒有收到任何客戶端的控制報文，它就會斷開連接。

Message

通常指 PUBLISH 報文。

Message Expiry Interval

MQTT v5.0 允許客戶端為消息設置過期時間，避免在服務端中停留了較長時間的消息仍然被轉發給訂閱端。

MQTT over QUIC

MQTT over … 指的是 MQTT 運行在什么協議之上。常見的有 MQTT over TCP、MQTT over TLS 等。

MQTT 協議只要求基礎傳輸層能夠提供有序、可靠的雙向傳輸字節流，并未強制指定使用某種傳輸協議。

MQTT over QUIC 是 EMQX 對 MQTT 的一個擴展。相比于 TCP，QUIC 能夠有效減少連接開銷和弱網環境下的消息延遲，同時還具備多路復用、連接遷移、端到端加密等特性，為現代移動互聯網提供了一個更加靈活可靠的傳輸層。

MQTT v3.1.1

OASIS 技術委員會于 2014 年 10 月發布的 MQTT 規范。

MQTT v5.0

OASIS 技術委員會于 2019 年 3 月發布的 MQTT 規范，也是目前最新的 MQTT 規范。MQTT v5.0 在引入大量新特性的同時，仍然向后兼容 v3.1.1。

Packet

通常指 MQTT 的控制報文。MQTT 協議通過交換預定義的 MQTT 控制報文來通信。

例如用于連接的 CONNECT、AUTH（僅限 MQTT v5.0） 報文，用于發布的 PUBLISH 報文，以及用于訂閱的 SUBSCRIBE 報文等等。

Packet Identifier

報文標識符用于在客戶端和服務端之間唯一地標識一條 QoS 大于 0 的消息或一個訂閱/取消訂閱請求。

報文標識符的設置通常都在客戶端和服務端的內部完成。

Payload

MQTT 報文中的有效載荷部分，根據報文類型，有效載荷的內容會有所不同。

對于 PUBLISH 報文來說，有效載荷即消息的實際內容。而對于 SUBSCRIBE 報文來說，有效載荷指的是訂閱列表。

不過大部分情況下，如無特別說明，Payload 都是指 PUBLISH 報文中消息的實際內容。

Payload Format Indicator

用于指示消息內容（包括遺囑消息）是否是 UTF-8 編碼的字符串。僅限 MQTT v5.0。

PINGREQ & PINGRESP

客戶端需要及時發送 PINGREQ 報文告知服務端自己還活著。

服務端也需要及時響應 PINGRESP 報文以便客戶端判斷網絡和服務端的活動狀態。

Property

MQTT 為絕大部分的控制報文中都定義了一組可選屬性。不同類型的控制報文有不同的可選屬性。

例如 Session Expiry Interval 是 CONNECT 報文的一個可選屬性，Topic Alias 則是 PUBLISH 報文的一個可選屬性。

Publish/Subscribe

發布訂閱機制是 MQTT 協議的核心。它解耦了消息的發送方（發布者）和接收方（訂閱者），引入了一個中間代理的角色來完成消息的路由和分發。

發布者和訂閱者不需要知道彼此的存在，他們之間唯一的聯系就是對消息的一致約定，例如消息將使用什么主題、消息將包含哪些字段等等。

通過發布訂閱機制，我們可以實現消息的廣播、組播和單播。

QoS

MQTT 定義了三種 QoS 等級，來分別提供不同的消息可靠性保證。每條消息都可以在發布時獨立設置自己的 QoS。

• QoS 0：最多交付一次，消息可能丟失。
• QoS 1：至少交付一次，消息可以保證到達，但是可能重復到達。
• QoS 2：只交付一次，消息保證到達，并且不會重復。

Reason Code

MQTT 通過 CONNACK 等響應報文中的 Reason Code 字段來指示操作結果。

MQTT v5.0 擴展了 Reason Code 以便反映更準確的結果，并且令所有響應報文都支持了 Reason Code。

Reason String

Reason Code 通常是機器易讀的，所以 MQTT 還提供了 Reason String 來承載人類可讀的內容，在 Reason Code 的基礎上進一步指示結果。僅限 MQTT v5.0。

Receive Maximum

用于聲明服務端和客戶端愿意同時處理的 QoS 1 和 QoS 2 的消息的最大數量，對端在發送消息時需要遵守這個限制。僅限 MQTT v5.0。

Request & Response

MQTT 的發布訂閱機制使得發布端最多只能確保消息到達了服務端，但不能確保消息到達了訂閱端，我們必須借助額外的請求響應機制。

MQTT v5.0 改善了對請求響應的支持，請求方可以在請求中直接指定響應主題，這樣請求方和響應方無需再提前約定主題。同時，他們還可以通過對比數據來確保請求和響應的正確匹配。

Retained Message

保留消息除了與正常消息一樣被轉發以外，還會保留在 MQTT 服務端中。

當一個新的訂閱被創建，如果服務端中存在與該訂閱匹配的保留消息，那么這些保留消息就會被發送給訂閱者。

服務端只能為每個主題存儲一條最新的保留消息。

Security

MQTT 支持多種安全機制，包括但不限于：支持在傳輸層使用 TLS 來提供端到端的安全連接，保護消息免受竊聽、篡改或偽造；在 MQTT 協議層面支持對客戶端和服務端的身份驗證，以及對客戶端的授權檢查，以確保只有授權用戶才能訪問特定的主題。

Server

在發布消息的客戶端和訂閱的客戶端之間充當中介的設備或應用程序，它的首要職責是將所有接收到的消息轉發給匹配的訂閱客戶端。

Server Disconnect

MQTT v5.0 允許服務端發出 DISCONNECT 報文，以便向客戶端指示連接被關閉的具體原因。

Server Reference

MQTT v5.0 允許服務端通過 CONNACK 或者 DISCONNECT 報文中的服務端參考屬性指示客戶端臨時或永久切換至另一臺服務端。

Session

MQTT 的會話機制確保了 QoS 1、2 消息的協議流程得以實現。

會話是客戶端與服務端之間的有狀態交互，存儲了 QoS 1、2 消息的傳輸狀態以及訂閱信息等狀態信息。

它可以僅持續和網絡連接一樣長的時間，也可以跨越多個網絡連接存在。我們通常將后者稱為持久會話。

我們可以選擇讓連接從已存在的會話中恢復，也可以選擇從一個全新的會話開始。

Session Expiry Interval

會話過期時間。表示客戶端連接斷開后會話能夠在服務端中保留多久，僅限 MQTT v5.0。

Session Present

服務端通過這個字段告知客戶端本次連接是之前會話的延續還是一個全新的會話，以便客戶端做出相應的調整。

Shared Subscription

MQTT v5.0 允許將客戶端劃分為多個訂閱組，消息仍然會被轉發給所有訂閱組，但一個訂閱組內的客戶端將以隨機、輪詢等策略交替接收消息。

這使得訂閱者能夠以負載均衡的方式來消費消息。

一些 MQTT Server 例如 EMQX 在協議之外為非 MQTT v5.0 的設備提供了共享訂閱的支持。

Subscription Identifier

客戶端可以在訂閱時指定訂閱標識符，服務端在轉發與這些訂閱匹配的消息時需要附上與之關聯的訂閱標識符。

在特定的使用場景下，訂閱標識符可以幫助減少需要傳輸的數據量，或者幫助客戶端確定為消息觸發哪個回調。

Subscription Options

MQTT 允許客戶端為自己每個訂閱使用不同的訂閱選項，例如訂閱建立時是否需要接收保留消息，服務端可以向自己發送的消息的最大 QoS 等等。

MQTT v3.1.1 僅支持設置最大 QoS。

Topic

主題被用來標識和區分不同的消息，它是 MQTT 消息路由的基礎。發布者可以在發布時指定消息的主題，訂閱者則可以選擇訂閱自己感興趣的主題來接收相關的消息。

Topic Alias

MQTT v5.0 允許發送端將主題名映射成由一個雙字節整數表示的別名，然后在消息傳輸時用別名替換原本的主題名，以此降低帶寬消耗。

Topic Filter

主題過濾器在訂閱時使用，可以包含主題通配符來同時訂閱多個主題。

Topic Name

主題名在發布消息時使用，不允許使用主題通配符。

Topic Wildcards

MQTT 提供了兩種主題通配符，分別是 + 表示的單層通配符和 # 表示的多層通配符。通配符只能在主題過濾器中使用。

Username & Password

MQTT 在連接報文中提供了可選的 Username 和 Password 字段，以實現對密碼認證和 Token 認證的支持。

User Property

MQTT v5.0 允許客戶端和服務端將自定義的、不限數量的字符串鍵值對作為元數據添加到除 PING 報文以外的所有控制報文當中，以提供更好的可擴展性。

用戶屬性可以在客戶端和服務端之間傳遞，也可以在客戶端和客戶端之間傳遞，這主要取決于具體的控制報文類型。

Will Delay Interval

用于指示遺囑消息可以在連接斷開后延遲多久發出，僅限 MQTT v5.0。

Will Message

如果客戶端不正常地斷開連接，那么該客戶端在連接時設置的遺囑消息就會被服務端轉發給其他的客戶端。

遺囑消息和普通消息一樣具有主題、QoS、Payload、保留消息標識位等字段。

$ Topic

以 $ 開頭的主題必須由服務端來決定其使用方式和場景，客戶端不能僅出于自己的目的來隨意使用這類主題。

例如 $share開頭的主題用于共享訂閱，$SYS 開頭的主題通常被服務端用于發布系統消息。

EMQX 還定義了 $delay 前綴用于實現消息的延遲發布。

MQTT FAQs

什么是 MQTT？

MQTT 是用于物聯網連接的 OASIS 標準，它是一種基于發布訂閱模式的、輕量級的消息傳輸協議，專為受限設備和低帶寬、高延遲和不可靠的網絡設計，并且能夠提供一定的消息可靠性保證。得益于這些特性，MQTT 在車聯網、工業制造、移動通信等領域廣泛應用。

目前 MQTT 的主要版本有 v3.1.1 和 v5.0，v5.0 于 2019 年 3 月發布，相比于 v3.1.1 引入了很多改進和增強，目前市面上絕大部分的客戶端 和代理都已經支持了 MQTT v5.0。

什么是 MQTT Broker？

基于發布訂閱模式的 MQTT 解耦了消息的發送方和接收方，并且引入了 Broker 這個中間角色。Broker 是 MQTT 客戶端之間消息傳輸的橋梁，它的主要職責是從客戶端接收消息并根據消息的主題將它們路由到適當的訂閱者。

什么是 EMQX？

EMQX 是一款開源的、云原生的分布式物聯網 MQTT 消息服務器，能夠輕松支持數百萬個并發連接，并且可以通過集群部署擴展至 1 億并發連接。在處理每秒百萬級的消息吞吐的同時，EMQX 還能保證超低的消息時延。

EMQX 提供了 SSL/TLS、密碼認證、增強認證、ACL 等多種安全機制來保障數據安全，提供了基于 SQL 的、能夠實時過濾、轉換與處理消息的規則引擎，以及強大的管理監控功能。EMQX 最新的 5.0 版本還提供了全球首個 MQTT over QUIC 的實現，可以有效減少連接開銷和弱網環境下的消息延遲，并具備多路復用、連接遷移等特性。

目前 EMQX 已經廣泛地應用在車聯網、工業制造、能源電力等領域。

EMQX 支持 TLS 嗎？

是的。EMQX 提供了非常完整的 SSL/TLS 能力支持，包括支持單/雙向認證、X.509 證書認證、SNI 等等。

EMQX 除了支持為包括 MQTT 在內的所有客戶端連接啟用 TLS，以保證接入和消息傳輸安全以外，還支持為與其他所有外部資源的連接啟用 TLS，以確保訪問外部資源時的數據安全。

什么是 MQTT 主題？

主題被用來標識和區分不同的消息，它是 MQTT 消息路由的基礎。發布者可以在發布時指定消息的主題，訂閱者則可以選擇訂閱自己感興趣的主題來接收相關的消息。

MQTT 和 EMQX 有什么區別？

MQTT 是一個消息傳輸協議，它廣泛地應用在物聯網等領域。MQTT 需要一個服務端來為所有客戶端路由和分發所有消息，而 EMQX 就是這個服務端的具體實現。EMQX 也是目前全球最受歡迎的開源 MQTT 消息服務器之一，它提供了對 MQTT v3.1、v3.1.1 以及 v5.0 協議標準的完整支持。

MQTT 和 AMQP 有什么區別？

MQTT 和 AMQP 都是運行在 TCP/IP 之上的二進制消息傳遞協議，也都是開放的標準協議。

但 MQTT 主要為高延遲、低帶寬和不可靠的網絡而設計，使用發布訂閱模式，支持通過主題路由消息。MQTT 擁有更輕巧的報文結構，對于資源受限的設備更加友好。MQTT 還提供了遺囑消息、保留消息、會話等專為運行在不可靠網絡下的設備設計的功能。

而 AMQP 則旨在提供通用的消息隊列協議，確保業務消息在應用程序或者服務端之間安全高效地傳輸，它提供了多種不同的路由規則來滿足更復雜的應用場景，目前 AMQP 廣泛地應用于商業領域。

MQTT 和 Kafka 有什么區別？

MQTT 和 Kafka 是完全不同的技術，雖然它們具有一些類似的特性，比如都基于發布訂閱模式，都通過主題來路由消息等等。

但實際上，Kafka 更多地是專注于數據的存儲和讀取，針對實時性高的流式數據處理場景。而 MQTT 則側重于海量的設備連接和主題路由，并且在不穩定的網絡環境中進行實時的、可靠的消息交換。所以，MQTT 和 Kafka 的最大差異在于它們有著不同的適用場景，解決的是不同的問題。

在實際的生產應用中，MQTT 和 Kafka 經常會結合一起使用。MQTT 代理解決海量終端設備的接入問題，并將匯入的海量終端數據轉發給 Kafka，再由 Kafka 分發給不同的業務應用程序，進行進一步的消息分析和處理。

EMQX 是免費的嗎？

是的，EMQX 是一個基于 Apache 2.0 許可證完全開源的 MQTT 消息服務器，從 2013 年在 Github 上開源至今，EMQX 已經收獲了超過 11K 的 Star 數。你可以在 EMQX 官網或者 Github 免費下載使用 EMQX。

除了 MQTT，EMQX 還支持哪些協議？

除了 MQTT 協議，EMQX 還支持 MQTT-SN、CoAP、STOMP 以及 LwM2M 多種其他物聯網協議，并且允許接入的客戶端跨協議通信。

EMQX 支持哪個 MQTT 版本？

EMQX 提供了對所有協議版本的完整的 MQTT 支持，包括 MQTT v3.1、v3.1.1 以及 v5.0，并且允許不同協議版本的客戶端同時接入。

MQTT 有多安全？

MQTT 提供了多項安全機制，通過密碼認證、Token 認證或者支持多種認證算法的增強認證機制，可以實現對客戶端和服務端的身份驗證，再配合服務端的權限檢查，可以確保只有經過身份驗證的客戶端才能訪問權限以內的數據。

MQTT 還支持使用 SSL/TLS 進行加密通信，以保護數據的隱私性和完整性。

需要注意的是，最終的安全性仍然取決于您的具體實施。比如，是否安全地存儲了密碼，是否在 TLS 中使用了足夠安全的加密套件等等。

MQTT 使用 TCP 還是 UDP？

MQTT 協議要求基礎傳輸層能夠提供有序、可靠的雙向傳輸字節流，所以 TCP 協議通常是 MQTT 的首要選擇。

不過 MQTT 并未強制指定使用某種傳輸協議。雖然無法保證消息有序到達的 UDP 并不適合直接作為 MQTT 的底層傳輸協議，但是基于 UDP 實現的 QUIC，由于集成了 TCP 和 TLS 的所有優點并且解決了連接開銷、連接不可遷移等缺點，所以也非常適合作為 MQTT 的傳輸協議。

EMQX 能否代替 RabbitMQ？

EMQX 的核心是 MQTT，RabbitMQ 的核心是 AMQP，他們有著不同的設計目標和用例。EMQX 是一個高性能、可擴展、功能豐富的 MQTT 消息服務器，針對物聯網和 M2M 通信進行了優化。EMQX 旨在處理海量的并發連接和消息吞吐，使其適用于需要低延遲和實時通信的應用程序。

RabbitMQ 則更多的應用在不同系統間的數據交流和傳遞上。與 Kafka 類似，很多時候，RabbitMQ 與 EMQX 結合使用能夠獲得更好的效果。

MQTT 比 AMQP 快嗎？

單純比較協議之間的性能差異是沒有意義的，這更多的取決于具體用例的實現。即便是同一種協議的不同實現，也可能存在較大的性能差異。根據應用場景來選擇協議，根據期望的性能來對協議的具體實現進行選型，會是一個更加合理的方案。