MQTT教程--服务器使用EMQX和客户端使用MQTTX

什么是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

以 $ 开头的主题必须由服务端来决定其使用方式和场景，客户端不能仅出于自己的目的来随意使用这类主题。

例如 s h a r e 开头的主题用于共享订阅， share 开头的主题用于共享订阅， 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 快吗？

单纯比较协议之间的性能差异是没有意义的，这更多的取决于具体用例的实现。即便是同一种协议的不同实现，也可能存在较大的性能差异。根据应用场景来选择协议，根据期望的性能来对协议的具体实现进行选型，会是一个更加合理的方案。