能源星球的博客

AUTH 报文是实现任意次数认证数据交换的核心，也使得 MQTT 的增强认证能够支持各种不同的认证机制。像 SCRAM 认证、Kerberos 认证，都能提供比简单密码认证更高的安全保障，目前 EMQX 已经支持了其中的SCRAM 认证。现在，我们已经介绍了 MQTT 中的所有控制报文类型，MQTT 作为一个二进制协议，允许我们传输任意格式的应用消息。但相应地，我们也需要严格地按照协议规范来编码和解析 MQTT 报文，否则就可能造成协议错误。

客户端和服务端都可以发送 DISCONNECT 报文，表示准备断开网络连接，报文中的原因码可以向接收方指示连接关闭的原因。当 MQTT 连接意外断开时，我们可以优先查看是否收到了 DISCONNECT 报文以及报文中原因码的值。虽然客户端和服务端在 DISCONNECT 报文中可以用的原因码和属性存在差异，但我们并不需要强行去记忆它们。它们通常都和对应的机制与行为相关，例如遗嘱消息只会由服务端发布，所以希望连接正常关闭但对端仍要发布遗嘱消息的原因码 0x04，也会被客户端使用。

PINGREQ 和 PINGRESP 是 MQTT 中最简单的报文类型，它们的内容固定不变。我们唯一可以改变的，就是通过连接时的Keep Alive 选项，影响客户端发送 PINGREQ 报文的频率。如果服务端没有在 1.5 倍 Keep Alive 时间内收到客户端发送的任何控制报文，就会认为客户端处于非活跃状态或网络异常而断开连接。在本文的报文示例中，我们在连接时 Keep Alive 设置为 5 秒，那么对服务端来说超时时间就是 7.5 秒。

SUBSCRIBE 和 SUBACK 报文用于订阅，UNSUBSCRIBE 和 UNSUBACK 用于取消订阅，想要订阅或者取消订阅的主题过滤器列表，都在对应报文的有效载荷中，SUBSCRIBE 报文中的每个主题主题过滤器，都与一组订阅选项相关联。指示请求结果的 Reason Code 位于 SUBACK 和 UNSUBACK 报文的有效载荷部分，并且它是一个列表，一一对应请求报文中的主题过滤器。

主题别名（Topic Alias）是 MQTT v5.0 中新加入的与主题名（topic）相关的特性。它允许用户将主题长度较长且常用的主题名缩减为一个双字节整数来降低发布消息时的带宽消耗。它是一个双字节整数，并将作为属性字段，编码在PUBLISH报文中可变报头部分。并且在实际应用中，将受到CONNECT报文和CONNACK报文中“主题别名最大长度”属性的限制。只要不超过该限制，任何主题名，都可以使用此特性缩减为编码长度2字节的整数。主题别名作为 MQTT v5 新提供的特性，为pub/sub。

Payload Format Indicator 是 MQTT 5.0 引入的一个全新属性，用来指示MQTT 报文中有效载荷的格式。但 CONNECT、SUBSCRIBE 与 UNSUBSCRIBE 报文中有效载荷的格式都是固定不变的，所以实际上只有 PUBLISH 报文和 CONNECT 报文中的遗嘱消息需要声明其有效载荷的格式。如果 Payload Format Indicator 的值为 0 或者没有指定这个属性，表示当前有效载荷是未指定的字节流；

MQTT 报文的理论最大长度为 268435456 字节，也就是 256 MB。但显然，不仅仅是资源受限的客户端，一些作为边缘网关运行的 MQTT 服务端，可能也无法处理这一长度的报文。考虑到不同客户端对报文的处理能力可能有着较大差异，发送过大的报文不仅可能影响对端的正常业务处理，甚至可能直接压垮对端。所以，我们需要使用 Maximum Packet Size 属性来协商客户端和服务端各自能够处理的最大报文长度。

在仅有的两个支持 Reason Code 的报文中，CONNACK 报文只有 5 个用于指示失败的 Reason Code，SUBACK 报文则仅仅只有一个用于指示失败的 Reason Code，无法进一步指示订阅失败的原因。在实际使用中，Reason String 的内容取决于客户端和服务端的具体实现，所以一个实现正确的接收端不应该尝试解析 Reason String 的内容，推荐的使用方式包括但不限于在抛出异常时使用 Reason String，或者将它写入日志。Reason Code 在。

也称主设备，是构成电力系统的主体，是电力系统中直接用于生产、输送、分配和使用电能的设备，它们构成了发电、输电、配电和用电的主回路。它是直接生产、输送和分配电能的设备，包括发电机、变压器、开关电器、电力线路、互感器、避雷器等。一次电气设备按用途及功能相互连接构成的电路，称为一次回路或一次接线或主接线图。

消息过期间隔是 MQTT 5.0 引入的一个新特性，它允许发布端为有时效性的消息设置一个过期间隔，如果该消息在服务端中停留超过了这个指定的间隔，那么服务端将不会再将它分发给订阅端。默认情况下，消息中不会包含消息过期间隔，这表示该消息永远不会过期。MQTT 的持久会话可以为离线客户端缓存尚未发送的消息，然后在客户端恢复连接时发送。但如果客户端离线时间较长，可能有一些寿命较短的消息已经没有必要必须发送给客户端了，继续发送这些过期的消息，只会浪费网络带宽和客户端资源。

本文介绍了 MQTT 协议中 Keep Alive 的机制及 EMQX 中 Keep Alive 的使用，开发者可以借助这一特性确保MQTT 连接的稳定性，构建更加健壮的上层物联网应用。接下来可访问 EMQ 提供的MQTT 入门与进阶系列文章学习 MQTT 主题及通配符、保留消息、遗嘱消息等相关概念，探索 MQTT 的更多高级应用，开启 MQTT 应用及服务开发。

MQTT v5.0 通过新增的 AUTH 报文实现了对增强认证的支持，在原先通过 Username 和 Password 提供的密码认证和 Token 认证的基础上进行了扩展。用来描述消息的内容类型，方便接收方处理。MQTT v5.0 引入了流控机制，允许客户端和服务端根据自己的接收能力约定对方的最大消息发送速率，避免了一方发送过快，导致网络拥塞和接收方过载的问题。MQTT 允许客户端为自己每个订阅使用不同的订阅选项，例如订阅建立时是否需要接收保留消息，服务端可以向自己发送的消息的最大 QoS 等等。

MQTT 中的 QoS 指的是发布者与订阅者之间消息传递的保证级别。QoS 0 – 最多交付一次QoS 1 – 至少交付一次QoS 2 – 只交付一次其中，使用 QoS 0 可能丢失消息，使用 QoS 1 可以保证收到消息，但消息可能重复，使用 QoS 2 可以保证消息既不丢失也不重复。QoS 等级从低到高，不仅意味着消息可靠性的提升，也意味着传输复杂程度的提升。

MQTT 会话本质上就是一组需要服务端和客户端额外存储的上下文数据，这些数据可以仅持续与网络连接一样长的时间，也可以跨越多个连续的网络连接存在。当客户端与服务端借助这些会话数据恢复通信时，可以让网络中断就像从未发生过一样。以服务端为例，它需要存储客户端的订阅列表，那么不管当前客户端是否连接，只要会话没有过期，服务端就能够知道哪些消息是被该客户端订阅的，进而为它缓存这些消息。另外，客户端再次连接时也不需要重新发起订阅，这也减少了服务端的性能开销。MQTT 为服务端和客户端分别定义了它们需要存储的会话状态。

MQTT 主题本质上是一个 UTF-8 编码的字符串，是 MQTT 协议进行消息路由的基础。MQTT 主题类似 URL 路径，使用斜杠进行分层：sensor/#为了避免歧义且易于理解，通常不建议主题以开头或结尾，例如/chat或chat/。不同于消息队列中的主题（比如 Kafka 和 Pulsar），MQTT 主题不需要提前创建。MQTT 客户端在订阅或发布时即自动的创建了主题，开发者无需再关心主题的创建，并且也不需要手动删除主题。下图是一个简单的 MQTT 订阅与发布流程，APP 1订阅了。

至此，相信读者已对 MQTT 连接的建立及各个连接参数的作用有了深刻的理解。接下来，可访问 EMQ 提供的MQTT 入门与进阶系列文章学习 MQTT 主题及通配符、保留消息、遗嘱消息等相关概念，探索 MQTT 的更多高级应用，开启 MQTT 应用及服务开发。

MQTT 的发布/订阅机制可以很轻易地满足我们一对一、一对多、多对一的通信需要。这也在很大程度上拓宽了 MQTT 在 IoT 领域之外的应用，像网络直播互动、手机消息推送等行业场景，都非常适合使用 MQTT。至此，相信读者已对 MQTT 的发布/订阅模式有了深刻的理解，接下来，可查看博客创建 MQTT 连接时如何设置参数？了解如何创建一个 MQTT 连接。或访问 EMQ 提供的MQTT 入门与进阶。

MQTT（Message Queuing Telemetry Transport）是一种轻量级、基于发布-订阅模式的消息传输协议，适用于资源受限的设备和低带宽、高延迟或不稳定的网络环境。它在物联网应用中广受欢迎，能够实现传感器、执行器和其它设备之间的高效通信。