MQTT 教程

有时我们也会直接将服务端称为 Broker，这两个术语可以互换使用。

客户端可以在连接时使用这个字段来指示是期望从已存在的会话中恢复通信，还是创建一个全新的会话。仅限 MQTT v5.0。

使用 MQTT 协议连接到服务端的设备或应用程序，并通过服务端完成发布订阅。

Client ID 用于唯一标识客户端连接与会话，MQTT 允许客户端自行指定 Client ID，也支持由服务端统一为客户端分配 Client ID。

MQTT 客户端与 MQTT 服务端之间的网络连接。MQTT 客户端之间并不会直接建立连接。

用来描述消息的内容类型，方便接收方处理。可以使用 MIME 类型，例如 text/plain，也可以使用自定义的字符串来描述消息内容。仅限 MQTT v5.0。

MQTT v5.0 通过新增的 AUTH 报文实现了对增强认证的支持，在原先通过 Username 和 Password 提供的密码认证和 Token 认证的基础上进行了扩展。

它更像是一种认证框架，允许使用各种更安全的认证机制，例如 SCRAM 认证就支持服务端和客户端互相确认对方的身份，以抵御中间人攻击。

MQTT v5.0 引入了流控机制，允许客户端和服务端根据自己的接收能力约定对方的最大消息发送速率，避免了一方发送过快，导致网络拥塞和接收方过载的问题。

Keep Alive 表示客户端在传输完成一个 MQTT 控制报文到发送下一个报文，两者之间允许空闲的最大的时间间隔。

如果没有其他控制报文可以发送，客户端必须发送一个 PINGREQ 报文。

如果服务端在 1.5 倍的 Keep Alive 时间内没有收到任何客户端的控制报文，它就会断开连接。

通常指 PUBLISH 报文。

MQTT v5.0 允许客户端为消息设置过期时间，避免在服务端中停留了较长时间的消息仍然被转发给订阅端。

MQTT over ... 指的是 MQTT 运行在什么协议之上。常见的有 MQTT over TCP、MQTT over TLS 等。

MQTT 协议只要求基础传输层能够提供有序、可靠的双向传输字节流，并未强制指定使用某种传输协议。

MQTT over QUIC 是 EMQX 对 MQTT 的一个扩展。相比于 TCP，QUIC 能够有效减少连接开销和弱网环境下的消息延迟，同时还具备多路复用、连接迁移、端到端加密等特性，为现代移动互联网提供了一个更加灵活可靠的传输层。

OASIS 技术委员会于 2014 年 10 月发布的 MQTT 规范。

OASIS 技术委员会于 2019 年 3 月发布的 MQTT 规范，也是目前最新的 MQTT 规范。MQTT v5.0 在引入大量新特性的同时，仍然向后兼容 v3.1.1。

通常指 MQTT 的控制报文。MQTT 协议通过交换预定义的 MQTT 控制报文来通信。

例如用于连接的 CONNECT、AUTH（仅限 MQTT v5.0） 报文，用于发布的 PUBLISH 报文，以及用于订阅的 SUBSCRIBE 报文等等。

报文标识符用于在客户端和服务端之间唯一地标识一条 QoS 大于 0 的消息或一个订阅/取消订阅请求。

报文标识符的设置通常都在客户端和服务端的内部完成。

MQTT 报文中的有效载荷部分，根据报文类型，有效载荷的内容会有所不同。

对于 PUBLISH 报文来说，有效载荷即消息的实际内容。而对于 SUBSCRIBE 报文来说，有效载荷指的是订阅列表。

不过大部分情况下，如无特别说明，Payload 都是指 PUBLISH 报文中消息的实际内容。

用于指示消息内容（包括遗嘱消息）是否是 UTF-8 编码的字符串。仅限 MQTT v5.0。

客户端需要及时发送 PINGREQ 报文告知服务端自己还活着。

服务端也需要及时响应 PINGRESP 报文以便客户端判断网络和服务端的活动状态。

MQTT 为绝大部分的控制报文中都定义了一组可选属性。不同类型的控制报文有不同的可选属性。

例如 Session Expiry Interval 是 CONNECT 报文的一个可选属性，Topic Alias 则是 PUBLISH 报文的一个可选属性。

发布订阅机制是 MQTT 协议的核心。它解耦了消息的发送方（发布者）和接收方（订阅者），引入了一个中间代理的角色来完成消息的路由和分发。

发布者和订阅者不需要知道彼此的存在，他们之间唯一的联系就是对消息的一致约定，例如消息将使用什么主题、消息将包含哪些字段等等。

通过发布订阅机制，我们可以实现消息的广播、组播和单播。

MQTT 定义了三种 QoS 等级，来分别提供不同的消息可靠性保证。每条消息都可以在发布时独立设置自己的 QoS。

QoS 0：最多交付一次，消息可能丢失。

QoS 1：至少交付一次，消息可以保证到达，但是可能重复到达。

QoS 2：只交付一次，消息保证到达，并且不会重复。

MQTT 通过 CONNACK 等响应报文中的 Reason Code 字段来指示操作结果。

MQTT v5.0 扩展了 Reason Code 以便反映更准确的结果，并且令所有响应报文都支持了 Reason Code。

Reason Code 通常是机器易读的，所以 MQTT 还提供了 Reason String 来承载人类可读的内容，在 Reason Code 的基础上进一步指示结果。仅限 MQTT v5.0。

用于声明服务端和客户端愿意同时处理的 QoS 1 和 QoS 2 的消息的最大数量，对端在发送消息时需要遵守这个限制。仅限 MQTT v5.0。

MQTT 的发布订阅机制使得发布端最多只能确保消息到达了服务端，但不能确保消息到达了订阅端，我们必须借助额外的请求响应机制。

MQTT v5.0 改善了对请求响应的支持，请求方可以在请求中直接指定响应主题，这样请求方和响应方无需再提前约定主题。同时，他们还可以通过对比数据来确保请求和响应的正确匹配。

保留消息除了与正常消息一样被转发以外，还会保留在 MQTT 服务端中。

当一个新的订阅被创建，如果服务端中存在与该订阅匹配的保留消息，那么这些保留消息就会被发送给订阅者。

服务端只能为每个主题存储一条最新的保留消息。

MQTT 支持多种安全机制，包括但不限于：支持在传输层使用 TLS 来提供端到端的安全连接，保护消息免受窃听、篡改或伪造；在 MQTT 协议层面支持对客户端和服务端的身份验证，以及对客户端的授权检查，以确保只有授权用户才能访问特定的主题。

在发布消息的客户端和订阅的客户端之间充当中介的设备或应用程序，它的首要职责是将所有接收到的消息转发给匹配的订阅客户端。

MQTT v5.0 允许服务端发出 DISCONNECT 报文，以便向客户端指示连接被关闭的具体原因。

MQTT v5.0 允许服务端通过 CONNACK 或者 DISCONNECT 报文中的服务端参考属性指示客户端临时或永久切换至另一台服务端。

MQTT 的会话机制确保了 QoS 1、2 消息的协议流程得以实现。

会话是客户端与服务端之间的有状态交互，存储了 QoS 1、2 消息的传输状态以及订阅信息等状态信息。

它可以仅持续和网络连接一样长的时间，也可以跨越多个网络连接存在。我们通常将后者称为持久会话。

我们可以选择让连接从已存在的会话中恢复，也可以选择从一个全新的会话开始。

会话过期时间。表示客户端连接断开后会话能够在服务端中保留多久，仅限 MQTT v5.0。

服务端通过这个字段告知客户端本次连接是之前会话的延续还是一个全新的会话，以便客户端做出相应的调整。

MQTT v5.0 允许将客户端划分为多个订阅组，消息仍然会被转发给所有订阅组，但一个订阅组内的客户端将以随机、轮询等策略交替接收消息。

这使得订阅者能够以负载均衡的方式来消费消息。

一些 MQTT Server 例如 EMQX 在协议之外为非 MQTT v5.0 的设备提供了共享订阅的支持。

客户端可以在订阅时指定订阅标识符，服务端在转发与这些订阅匹配的消息时需要附上与之关联的订阅标识符。

在特定的使用场景下，订阅标识符可以帮助减少需要传输的数据量，或者帮助客户端确定为消息触发哪个回调。

MQTT 允许客户端为自己每个订阅使用不同的订阅选项，例如订阅建立时是否需要接收保留消息，服务端可以向自己发送的消息的最大 QoS 等等。

MQTT v3.1.1 仅支持设置最大 QoS。

主题被用来标识和区分不同的消息，它是 MQTT 消息路由的基础。发布者可以在发布时指定消息的主题，订阅者则可以选择订阅自己感兴趣的主题来接收相关的消息。

MQTT v5.0 允许发送端将主题名映射成由一个双字节整数表示的别名，然后在消息传输时用别名替换原本的主题名，以此降低带宽消耗。

主题过滤器在订阅时使用，可以包含主题通配符来同时订阅多个主题。

主题名在发布消息时使用，不允许使用主题通配符。

MQTT 提供了两种主题通配符，分别是 + 表示的单层通配符和 # 表示的多层通配符。通配符只能在主题过滤器中使用。

MQTT 在连接报文中提供了可选的 Username 和 Password 字段，以实现对密码认证和 Token 认证的支持。

MQTT v5.0 允许客户端和服务端将自定义的、不限数量的字符串键值对作为元数据添加到除 PING 报文以外的所有控制报文当中，以提供更好的可扩展性。

用户属性可以在客户端和服务端之间传递，也可以在客户端和客户端之间传递，这主要取决于具体的控制报文类型。

用于指示遗嘱消息可以在连接断开后延迟多久发出，仅限 MQTT v5.0。

如果客户端不正常地断开连接，那么该客户端在连接时设置的遗嘱消息就会被服务端转发给其他的客户端。

遗嘱消息和普通消息一样具有主题、QoS、Payload、保留消息标识位等字段。

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

例如 $share 开头的主题用于共享订阅，$SYS 开头的主题通常被服务端用于发布系统消息。

EMQX 还定义了 $delay 前缀用于实现消息的延迟发布。