MQTT 控制报文深度剖析（二）

三、核心组成部分深度解析

3.1 固定报头：协议解析的 “钥匙”

3.1.1 报文类型编码规范

在 MQTT 控制报文中，固定报头的第一个字节的高 4 位承担着定义报文类型的重任，它是一个 4 位无符号整数，理论上可以表示 16 种不同的类型 。不过在实际应用中，0 和 15 这两个值被保留，暂未被赋予具体的功能，剩下的 1 - 14 这 14 个值则各自对应着不同的 MQTT 控制报文功能 。

以常见的报文类型为例，当这 4 位的值为 0001 时，表示该报文是 CONNECT 类型，这是客户端向服务端发起连接请求时使用的报文，它携带了客户端的基本信息和连接配置，就像是客户端向服务端递出的一张 “名片” 。而当值为 1100 时，代表这是 PINGREQ 报文，客户端通过发送它来向服务端进行心跳检测，确保连接的有效性，维持客户端与服务端之间的 “沟通桥梁” 。

接收端在接收到 MQTT 控制报文时，首先会读取这个报文类型编码字段，以此作为后续解析报文的关键依据。一旦识别出报文类型，接收端就会按照对应的规则来解析后续的报文内容。比如当检测到报文类型为 PUBLISH（值为 0011）时，接收端就知道接下来需要重点关注报文中的主题名、消息内容以及 QoS 等级等关键信息，因为这些都是与消息发布密切相关的内容 。

3.1.2 标识位的差异化语义

固定报头第一个字节的低 4 位是标识位，不过在目前的 MQTT 协议中，只有 PUBLISH 报文对这 4 位标识位进行了详细的定义，其他报文类型的标识位都被设置为保留值，若在其他报文中出现违规设置，将会导致连接断开 。

在 PUBLISH 报文中，这 4 位标识位各自有着独特的语义：

• Bit3（DUP）：这一位用于标记当前 PUBLISH 报文是否为重传报文，当 DUP = 1 时，表示该报文是之前发送过的报文的重传版本 。在 QoS≥1 的消息传输场景中，由于需要确保消息能够成功送达，当发送端没有收到接收端的确认消息时，就会重发该消息，并将 DUP 位置为 1 。例如在一个智能家居系统中，智能开关向控制中心发送控制指令（QoS 1 级别），若控制中心未及时确认收到，智能开关就会重发指令，此时重发的 PUBLISH 报文的 DUP 位就会被设置为 1 。

• Bit2 - Bit1（QoS）：这两位共同决定了 PUBLISH 报文的服务质量等级。其中，00 表示 QoS 0，即最多发送一次，这种等级下消息可能会丢失，适用于一些对消息准确性要求不高的场景，比如环境监测数据的偶尔丢失可能不会对整体分析造成太大影响 ；01 表示 QoS 1，保证至少发送一次，消息可能会重复，但能确保接收端有较高概率接收到消息，像智能设备的状态更新消息，重复接收影响不大，关键是要保证能收到 ；10 表示 QoS 2，确保消息只被准确送达一次，不会重复也不会丢失，常用于金融交易、医疗数据传输等对数据准确性和完整性要求极高的场景 。

• Bit0（Retain）：当 Retain = 1 时，表示该 PUBLISH 报文是一个保留消息 。服务端在接收到这样的消息后，会将其存储起来，并在有新的订阅者订阅该主题时，立即将这条保留消息推送给新订阅者 。比如在一个气象信息发布系统中，最新的气象预警消息可以设置为保留消息，新加入的气象监测设备订阅相关主题后，能马上获取到这条重要的预警信息 。

3.1.3 剩余长度的解析逻辑

剩余长度字段是固定报头中非常关键的一部分，它用于指示后续可变报头和有效载荷的总字节数，采用了可变字节整数编码方式，这种编码方式能够在保证表示范围的同时，尽可能地节省字节空间 。

在解析剩余长度时，需要按照特定的逻辑进行。具体步骤如下：从固定报头的第二个字节开始读取，每个字节的低 7 位用于存储实际的数据值，最高位则充当延续位 。当最高位为 0 时，说明这是编码剩余长度的最后一个字节；当最高位为 1 时，表示后续还有更多字节参与剩余长度的编码 。

以字节序列 0x82 0x9f 0x7f 为例，解析过程如下：

1. 第一字节 0x82（二进制为 10000010）：最高位是 1，说明后续还有字节参与编码，其低 7 位 0000010 转换为十进制是 2 。

1. 第二字节 0x9f（二进制为 10011111）：最高位依旧是 1，表明还有后续字节，低 7 位 0011111 转换为十进制是 31 。

1. 第三字节 0x7f（二进制为 01111111）：最高位为 0，代表这是编码剩余长度的最后一个字节，低 7 位 1111111 转换为十进制是 127 。

根据可变字节整数编码的计算规则，总长度的计算公式为：各个字节低 7 位的值加上其对应 128 的幂次方的乘积之和 。所以，该字节序列表示的总长度 = 2 + 31×128 + 127×128² = 2 + 3968 + 2092176 = 2097151 字节，接近 2MB（2097152 字节），这展示了可变字节整数编码在表示大数值时的高效性 。

3.2 可变报头：差异化功能的载体

3.2.1 字段顺序的严格性

MQTT 控制报文可变报头的字段顺序遵循着严格的协议规范，这是确保报文能够被正确解析的关键前提。不同类型的报文，其可变报头包含的字段各不相同，但每个报文类型内部字段的排列顺序是固定不变的 。

以 CONNECT 报文为例，其可变报头依次包含以下字段：

1. 协议名：这是一个 UTF - 8 编码的字符串 “MQTT”，用于标识协议类型 。在传输时，前 2 字节表示后续 “MQTT” 字符串的长度，固定为 4，接着的 4 个字节则依次存储 “MQTT” 这 4 个字符 。例如，在字节流中，协议名部分可能表示为 00 04 4D 51 54 54，其中 00 04 表示后续字符串长度为 4，4D 51 54 54 分别是 “M”“Q”“T”“T” 的十六进制表示 。

1. 协议级别：仅占 1 字节，用于明确 MQTT 协议的版本号 。在 MQTT 3.1.1 版本中，该值为 4；MQTT 5.0 版本中，该值为 5 。通过这个字段，服务端能够判断客户端使用的协议版本，以便进行相应的兼容性处理 。

1. 连接标志：同样是 1 字节，却蕴含着丰富的连接行为指示信息 。从高位到低位，依次包括保留位（必须为 0）、清理会话（Clean Session）、遗嘱标志（Will Flag）、遗嘱 QoS（Will QoS，占 2 位，用于表示遗嘱消息的服务质量等级）、遗嘱保留（Will Retain）、密码标志（Password Flag）、用户名标志（User Name Flag） 。这些标志位决定了连接的一些关键行为和有效载荷中字段的存在情况 。比如，当清理会话标志位为 1 时，表示客户端希望在本次连接时清理之前的会话信息；若密码标志位为 1，则意味着有效载荷中会包含密码字段 。

1. Keep Alive：由 2 字节组成，以秒为单位，表示客户端在两次控制报文传输之间允许的最大空闲时间 。例如，若 Keep Alive 设置为 60 秒，那么客户端如果在 60 秒内没有向服务端发送任何控制报文，就需要发送一个 PINGREQ 报文来保持连接的活跃，防止连接因长时间无活动而被断开 。

1. 属性（MQTT 5.0）：这是 MQTT 5.0 引入的新特性，位于可变报头的末尾 。属性字段由属性长度（2 字节）和属性列表组成，属性长度表示后面所有属性的总长度，属性列表则包含了一系列的属性，每个属性都有其特定的标识符和对应的值，用于扩展协议的功能，如设置会话过期时间、用户自定义的标识符等 。

如果在传输过程中，字段顺序出现错误，比如在 CONNECT 报文中跳过协议名直接传输协议级别，接收端按照正常的解析流程，会将协议级别误当作协议名的长度来解析，从而导致整个报文解析失败，通信中断 。

3.2.2 报文标识符的唯一性机制

在 MQTT 协议中，有 9 种报文类型包含 2 字节的报文标识符，它们分别是 PUBLISH（QoS>0 时）、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK 。报文标识符的取值范围是 1 - 65535，当达到最大值 65535 后，会重新从 1 开始循环使用 。

客户端和服务端在进行消息交互时，会独立分配报文标识符 。这一机制的关键作用在于实现请求 - 响应的匹配，确保并发消息处理时不会出现混淆 。以 SUBSCRIBE 和 SUBACK 报文为例，当客户端发送一个 SUBSCRIBE 报文请求订阅某个主题时，会为该报文分配一个唯一的报文标识符，假设为 0x1234 。服务端在接收到这个 SUBSCRIBE 报文后，会根据请求进行处理，并在返回 SUBACK 报文时，使用与 SUBSCRIBE 报文中相同的报文标识符 0x1234 。这样，客户端在收到 SUBACK 报文时，就能通过报文标识符快速准确地将其与之前发送的 SUBSCRIBE 报文进行关联，确认订阅请求的处理结果 。

在一个复杂的物联网系统中，可能同时存在多个客户端与服务端进行消息交互，每个客户端都可能发送多个不同类型的报文 。通过这种报文标识符的唯一性机制，即使在高并发的情况下，也能保证消息的准确传输和处理，不会因为消息的交织而出现错误 。

3.2.3 MQTT 5.0 属性扩展

MQTT 5.0 对协议进行了重要扩展，引入了属性机制，为 MQTT 控制报文带来了更强大的功能和灵活性 。属性位于可变报头的末尾，由属性长度和属性列表两部分组成 。

属性长度占用 2 字节，用于表示后续属性列表的总长度 。当属性长度为 0 时，说明该报文中不包含任何属性；当属性长度不为 0 时，接收端会根据这个长度值来读取后续的属性列表 。

属性列表是一系列属性的集合，每个属性都有一个唯一的标识符（1 字节），用于定义属性的用途和数据类型 。例如，标识符 1 表示 Session Expiry Interval 属性，用于设置会话的过期时间 。属性的值则根据其数据类型进行解析，可能是双字节整数、UTF - 8 字符串等 。比如，Session Expiry Interval 属性的值如果是双字节整数，那么它表示的就是会话过期的时间长度，单位根据协议定义而定 。

在实际应用中，属性的可选性为 MQTT 协议带来了极大的便利 。在 CONNECT 报文中，客户端可以根据自身需求，通过属性设置一些个性化的参数 。如果客户端希望服务端在一段时间后自动清除其会话信息，就可以设置 Session Expiry Interval 属性来指定会话的过期时间 。在 PUBLISH 报文中，也可以通过属性设置消息的过期时间，使得服务端在消息过期后不再进行转发，提高消息处理的效率和资源利用率 。这种属性扩展机制，使得 MQTT 协议能够更好地适应不同的应用场景，满足日益增长的物联网应用需求 。

3.3 有效载荷：数据承载的 “容器”

3.3.1 内容与报文类型强相关

MQTT 控制报文的有效载荷是实际承载应用数据的部分，其内容与报文类型紧密相关，不同的报文类型在有效载荷中携带不同的数据 。

• CONNECT 报文：在建立连接时，有效载荷包含了客户端 ID、用户名、密码（若需要进行身份验证）以及遗嘱消息相关内容（遗嘱主题和遗嘱消息） 。客户端 ID 是客户端在 MQTT 网络中的唯一标识，用于服务端识别和管理客户端连接 。用户名和密码用于身份验证，确保只有合法的客户端能够连接到服务端 。遗嘱消息则是在客户端异常断开连接时，服务端根据遗嘱标志和遗嘱主题，向其他订阅了该主题的客户端发布的消息，例如在智能家居场景中，智能设备在上线时设置了遗嘱消息，当设备因故障突然断电而异常断开连接时，服务端就会将遗嘱消息发布给相关客户端，通知其他设备该设备已离线 。

• PUBLISH 报文：主要承载应用数据，也就是实际的消息内容 。有效载荷的长度可以通过固定报头中的剩余长度减去可变报头的长度来计算 。当 QoS = 0 时，由于不要求消息确认，所以 PUBLISH 报文在这种情况下不包含报文标识符；而当 QoS≥1 时，为了确保消息的可靠传输和确认，PUBLISH 报文会包含报文标识符 。在一个智能农业监测系统中，传感器通过 PUBLISH 报文将采集到的土壤湿度、温度等数据发布到指定主题，这些数据就包含在 PUBLISH 报文的有效载荷中 。

• SUBSCRIBE 报文：有效载荷包含主题过滤器和请求 QoS 。主题过滤器用于指定客户端希望订阅的主题模式，支持通配符，如 “home/temp/#” 表示订阅 “home/temp” 主题下的所有子主题 。请求 QoS 则表示客户端希望在接收该主题消息时的服务质量等级 。在一个智能楼宇控制系统中，智能空调设备通过 SUBSCRIBE 报文订阅 “building/room1/temperature” 主题，并设置请求 QoS 为 1，这样当有关于该房间温度的消息发布时，智能空调就能按照 QoS 1 的等级接收消息，确保不会错过重要的温度控制指令 。

3.3.2 QoS 对载荷处理的影响

QoS（Quality of Service）即服务质量等级，在 MQTT 协议中分为 0、1、2 三个级别，不同的 QoS 级别对有效载荷的处理方式有着显著的影响 。

当 QoS = 1 时，发送端在发送 PUBLISH 报文后，需要缓存有效载荷，直到收到接收端返回的 PUBACK 报文 。这是因为 QoS 1 保证至少发送一次，发送端需要等待接收端的确认，以确保消息成功送达 。若在规定时间内没有收到 PUBACK 报文，发送端会重发 PUBLISH 报文，并将固定报头中的 DUP 位置为 1，表示这是一个重发的报文 。在一个工业物联网场景中，生产线上的设备向控制中心发送设备状态消息（QoS 1），设备会一直缓存消息的有效载荷，直到收到控制中心的 PUBACK 确认，若超时未收到确认，就会重发消息，保证控制中心能够及时掌握设备状态 。

当 QoS = 2 时，消息的传输过程更为复杂，需要通过 PUBREC、PUBREL、PUBCOMP 三个阶段来确保消息仅被处理一次 。发送端发送 PUBLISH 报文后，接收端收到消息后会返回 PUBREC 报文，表示已收到消息；发送端收到 PUBREC 后，会发送 PUBREL 报文；接收端收到 PUBREL 后，再返回 PUBCOMP 报文，至此整个消息传输确认过程完成 。在这个过程中，发送端在每个阶段都需要妥善处理有效载荷，确保消息的完整性和准确性 。例如在金融交易系统中，资金转账指令的传输必须保证准确无误且只被处理一次，就会采用 QoS 2 级别，严格按照这三个阶段的确认流程来处理有效载荷 。

在进行有效载荷解析时，需要结合主题名（PUBLISH 报文）或主题过滤器（SUBSCRIBE 报文） 。通过主题名或主题过滤器，接收端能够准确地将消息路由到对应的应用程序或设备，实现消息的精准消费 。在一个智能城市交通管理系统中，交通传感器发布的交通流量数据，根据不同的主题名（如 “city/area1/traffic”“city/area2/traffic” 等），被准确地分发给负责不同区域交通管理的应用程序，以便进行实时的交通状况分析和调度 。

四、典型控制报文功能解析

4.1 连接管理类报文：会话生命周期控制

4.1.1 CONNECT/CONNACK：连接建立的 “握手”

1. CONNECT 报文：当客户端试图与服务端建立 MQTT 连接时，CONNECT 报文便开始发挥作用。它就像是客户端递交给服务端的一份 “见面礼”，包含了诸多关键信息。其可变报头部分承载着至关重要的协议信息与连接参数，例如协议名 “MQTT”，它以 UTF - 8 编码的形式存在，前 2 字节表示后续 “MQTT” 字符串的长度，固定为 4，紧接着的 4 个字节则依次存储 “M”“Q”“T”“T” 的 ASCII 值 。协议级别字段以 1 字节来标识客户端所使用的 MQTT 协议版本，在 MQTT 3.1.1 中该值为 4，MQTT 5.0 中则为 5，这使得服务端能够清楚知晓客户端的协议版本，从而进行相应的兼容性处理 。连接标志字段虽然仅占 1 字节，却蕴含丰富，包含清理会话（Clean Session）、遗嘱标志（Will Flag）、用户名标志（User Name Flag）等多个标志位 。其中，Clean Session 标志位尤为关键，当它被设置为 1 时，意味着客户端期望在本次连接时清除之前的会话信息，即建立一个全新的会话；若为 0，则尝试复用已存在的会话 。例如在智能家居系统中，新加入的智能设备首次连接家庭网关时，通常会将 Clean Session 设置为 1，以确保与网关建立全新的会话关系 。有效载荷部分同样不可小觑，它携带了客户端的详细配置信息，其中客户端标识符（Client ID）是客户端在 MQTT 网络中的唯一标识，必须保证其唯一性，否则可能导致连接失败 。用户名和密码（若需要进行身份验证）也包含在此，用于确保只有合法的客户端能够接入服务端 。若启用 TLS（Transport Layer Security）加密，客户端需要在 TCP 层完成加密握手后，再将 CONNECT 报文进行传输，从而保障连接过程中的数据安全 。

1. CONNACK 报文：作为服务端对 CONNECT 报文的响应，CONNACK 报文扮演着连接结果告知者的角色 。它的可变报头包含会话存在标志（Session Present），这个标志位在客户端 CONNECT 报文中 Clean Session 为 0 时才有意义，若 Session Present 为 1，表示服务端正在使用已存在的会话与客户端恢复通信 。有效载荷中的返回码是判断连接是否成功的关键依据，0 代表连接成功，客户端可以正常进行后续的通信操作；1 表示协议错误，可能是客户端发送的 CONNECT 报文协议版本不被服务端支持；2 则意味着拒绝连接，可能是客户端标识符不合法等原因导致 。在工业物联网场景中，当工厂中的传感器节点连接到 MQTT 服务器时，服务器会返回 CONNACK 报文，传感器节点根据返回码来判断连接状态 。若返回码为 0，传感器节点就可以开始向服务器上报采集到的生产数据；若返回码不为 0，则需要检查自身的配置信息，重新尝试连接 。

4.1.2 DISCONNECT/AUTH：连接终止与增强认证

1. DISCONNECT：当客户端或服务端决定主动断开连接时，DISCONNECT 报文就会被发送 。它的结构十分简洁，既无可变报头，也没有有效载荷，仅包含 2 字节的固定报头，其中第一个字节高 4 位表示报文类型为 14（0b1110），低 4 位全为 0，第二个字节表示剩余长度为 0 。别看它简单，作用可不小，它就像是一个 “礼貌的告别通知”，确保对端知晓连接是正常断开的，这样服务端就能及时清理与该客户端相关的资源，避免残留无效会话 。在智能交通系统中，当一辆车的车载终端需要下线进行维护时，会向 MQTT 服务器发送 DISCONNECT 报文，服务器收到后，就会清理与该车终端相关的会话信息，释放占用的资源 。

1. AUTH（MQTT 5.0）：这是 MQTT 5.0 引入的一个重要特性，主要用于支持动态认证流程 。在传统的认证方式中，若首次认证失败，客户端可能就无法正常连接 。而 AUTH 报文改变了这一局面，当首次认证失败后，客户端可以通过该报文向服务端传递额外的凭证，比如令牌（Token）、证书摘要等 。通过这种多阶段的安全认证机制，能够有效提升物联网设备接入的安全性 。例如在金融物联网场景中，智能 POS 机在连接到银行的 MQTT 服务器时，可能会先进行初步的用户名和密码认证 。若认证失败，POS 机可以通过 AUTH 报文发送更高级别的认证信息，如数字证书摘要，服务器在接收到这些信息后，进行进一步的验证，从而确保只有合法的 POS 机能够接入，保障金融交易的安全 。

4.2 消息传输类报文：可靠通信的核心

4.2.1 PUBLISH：消息发布的 “基石”

1. 格式解析：PUBLISH 报文在 MQTT 消息传输体系中占据着核心地位，是实现消息发布的关键报文 。它的可变报头部分包含主题名（Topic Name），这是一个 UTF - 8 编码的字符串，用于标识消息所属的主题，就像是一个 “分类标签”，决定了消息的流向 。例如在智能农业监测系统中，“field1/temperature” 这样的主题名，就明确表示该消息是关于 field1 区域的温度数据 。当 QoS > 0 时，可变报头还包含报文标识符（Packet Identifier），这是一个 2 字节的无符号整数，用于在消息确认过程中唯一标识该 PUBLISH 报文 。有效载荷则是真正的消息内容，承载着应用层的数据 。固定报头中的 DUP 位（Bit 3）用于标记当前 PUBLISH 报文是否为重传，若 DUP = 1，说明这是一个重发的报文，常用于 QoS 1 和 QoS 2 级别下确保消息送达 。Retain 位（Bit 0）控制消息保留策略，当 Retain = 1 时，服务端会将此消息保留，并在新的订阅者订阅该主题时，立即将保留消息发送给新订阅者 。比如在一个智能家居控制系统中，用户设置的最新温度控制指令可以设置为保留消息，新加入的智能温控设备订阅相关主题后，能马上获取到这条指令 。

1. QoS 处理：

• • QoS0：在 QoS 0 级别下，消息的传输方式最为简单直接，发送即丢弃，不保证到达 。发送端只管将 PUBLISH 报文发送出去，不会等待接收方的确认，也不会进行重传操作 。这种方式适用于一些对消息准确性要求不高，且实时性较强的场景 。例如在环境监测系统中，传感器每隔一段时间采集一次环境数据，并通过 PUBLISH 报文（QoS 0）将数据发布到 “environment/data” 主题 。即使偶尔丢失一些数据，也不会对整体的环境趋势分析造成太大影响 。

• • QoS1：为了保证消息至少能够被接收一次，QoS 1 引入了确认机制 。发送端在发送 PUBLISH 报文后，会等待接收端返回 PUBACK 报文 。若在规定时间内没有收到 PUBACK，发送端会重传 PUBLISH 报文，并将 DUP 位置为 1 。在工业物联网中，设备的状态更新消息通常采用 QoS 1 级别进行传输 。比如工厂中的机器设备，每隔一段时间会向控制中心发送自身的运行状态消息（QoS 1），控制中心在收到消息后，会返回 PUBACK 报文进行确认 。若设备未收到确认，就会重发消息，确保控制中心能够及时掌握设备状态 。

• • QoS2：这是 MQTT 协议中最高级别的服务质量保证，通过 PUBREC（服务端接收确认）、PUBREL（客户端释放）、PUBCOMP（服务端完成）三阶段，确保消息恰好一次交付 。发送端发送 PUBLISH 报文后，接收端收到消息后会返回 PUBREC 报文，表示已收到消息；发送端收到 PUBREC 后，会发送 PUBREL 报文；接收端收到 PUBREL 后，再返回 PUBCOMP 报文，至此整个消息传输确认过程完成 。在医疗物联网场景中，病人的生命体征数据传输必须保证准确无误且只被处理一次，就会采用 QoS 2 级别 。例如医院中的监护设备向医疗信息系统发送病人的实时心率、血压等数据（QoS 2），通过这三个阶段的严格确认流程，确保医疗信息系统能够准确接收到数据，为医生的诊断提供可靠依据 。

4.2.2 确认机制：QoS 的 “保驾护航”

1. PUBACK（QoS1）：当服务端收到 QoS 1 级别的 PUBLISH 报文后，会返回 PUBACK 报文作为确认 。PUBACK 报文的可变报头包含与原始 PUBLISH 报文相同的报文标识符，发送端在收到 PUBACK 后，会根据报文标识符清除对应的 PUBLISH 报文缓存，确认消息已被接收端成功接收 。在一个智能物流系统中，物流车辆上的终端设备向物流中心发送货物运输状态消息（QoS 1），物流中心收到消息后，返回 PUBACK 报文，终端设备收到 PUBACK 后，就知道消息已成功送达物流中心，可以清理缓存中的消息，准备发送下一条数据 。

1. PUBREC/PUBREL/PUBCOMP（QoS2）：这三个报文协同工作，共同完成 QoS 2 级别的消息确认流程 。PUBREC 报文是服务端对 QoS 2 级别的 PUBLISH 报文的接收确认，当服务端收到 PUBLISH 报文后，会立即返回 PUBREC，告知发送端消息已被接收 。发送端收到 PUBREC 后，会发送 PUBREL 报文，触发服务端释放与该消息相关的资源 。服务端收到 PUBREL 后，会返回 PUBCOMP 报文，完成整个 QoS 2 消息传输流程 。通过精心设计的状态机机制，能够有效避免重复处理与数据丢失 。在一个电力物联网系统中，电网中的智能电表向电力调度中心发送实时电量数据（QoS 2），电表发送 PUBLISH 报文后，调度中心收到返回 PUBREC；电表收到 PUBREC 后发送 PUBREL，调度中心收到 PUBREL 后返回 PUBCOMP 。通过这种严谨的流程，确保电量数据准确无误地传输到调度中心，为电力调度提供精准的数据支持 。

4.3 会话维护类报文：连接状态的 “守护者”

4.3.1 PINGREQ/PINGRESP：轻量心跳机制

1. 报文结构：PINGREQ 和 PINGRESP 报文是 MQTT 协议中用于保持连接活跃度的轻量心跳机制的关键组成部分 。它们的结构极其简单，仅包含固定报头，总长度均为 2 字节 。PINGREQ 报文的固定报头中，第一个字节高 4 位表示报文类型为 12（0b1100），低 4 位全为 0；PINGRESP 报文的第一个字节高 4 位表示报文类型为 13（0b1101），低 4 位也全为 0 。由于它们不包含可变报头和有效载荷，所以剩余长度字段的值始终为 0 。客户端会周期性地发送 PINGREQ 报文（间隔≤Keep Alive 时间），就像是在向服务端 “打招呼”，询问连接是否正常 。

1. 超时逻辑：对于服务端而言，若在 1.5 倍 Keep Alive 时间内未收到客户端发送的任何报文（包括 PINGREQ），就会判定客户端失联，并主动断开连接 。这是为了防止客户端出现异常情况（如设备断电、网络故障）时，服务端一直保持无效的连接，浪费资源 。对于客户端来说，在发送 PINGREQ 报文后，如果未在预期时间内收到 PINGRESP 报文，就会触发重连逻辑 。在一个智能安防系统中，摄像头作为客户端，每隔一段时间（如 30 秒，Keep Alive 设置为 60 秒）向安防监控中心（服务端）发送 PINGREQ 报文 。若监控中心在 90 秒内都未收到摄像头的任何报文，就会断开与该摄像头的连接 。而摄像头发送 PINGREQ 后，若 10 秒内未收到 PINGRESP，就会尝试重新连接监控中心，确保及时检测网络故障，维持系统的正常运行 。

4.3.2 订阅管理：SUBSCRIBE/SUBACK 与 UNSUBSCRIBE/UNSUBACK

1. SUBSCRIBE：当客户端希望接收特定主题的消息时，会发送 SUBSCRIBE 报文 。它的可变报头包含报文标识符，用于标识本次订阅请求 。有效载荷则包含主题过滤器（Topic Filter）和期望 QoS 。主题过滤器支持通配符，“+” 通配符表示单级通配，例如 “home/+/temperature”，可以匹配 “home/livingroom/temperature”“home/bedroom/temperature” 等主题；“#” 通配符表示多级通配，如 “home/#”，可以匹配 “home/livingroom/temperature”“home/bedroom/lightstatus” 等所有以 “home” 开头的主题 。期望 QoS 表示客户端希望在接收该主题消息时的服务质量等级 。在一个智能楼宇控制系统中，智能照明设备通过 SUBSCRIBE 报文订阅 “building/room*/lightcontrol” 主题，并设置期望 QoS 为 1，这样当有关于该楼宇内各个房间照明控制的消息发布时，智能照明设备就能按照 QoS 1 的等级接收消息，及时响应控制指令 。

1. SUBACK：作为对 SUBSCRIBE 报文的响应，SUBACK 报文由服务端返回给客户端 。它的有效载荷包含每个主题的最大允许 QoS，这可能与客户端在 SUBSCRIBE 报文中请求的 QoS 不同 。例如，客户端请求订阅某个主题时设置 QoS 为 2，但服务端可能由于资源限制等原因，将最大允许 QoS 降配为 1，就会在 SUBACK 报文中告知客户端 。SUBACK 报文中的标识符与 SUBSCRIBE 报文中的标识符一致，以便客户端能够准确匹配订阅请求和响应 。在上述智能楼宇控制系统中，当智能照明设备收到 SUBACK 报文后，会根据报文中的最大允许 QoS 来调整自身接收消息的策略 。

1. UNSUBSCRIBE/UNSUBACK：当客户端不再希望接收某个主题的消息时，会发送 UNSUBSCRIBE 报文，其流程与 SUBSCRIBE 类似 。UNSUBSCRIBE 报文的可变报头包含报文标识符，有效载荷包含要取消订阅的主题过滤器 。服务端在收到 UNSUBSCRIBE 报文后，会返回 UNSUBACK 报文进行确认 。UNSUBACK 报文中也包含与 UNSUBSCRIBE 报文相同的报文标识符，用于确认取消订阅请求 。这一过程确保了资源的合理释放与消息过滤规则的及时更新 。在智能城市交通管理系统中，某路段的交通监测设备如果不再需要接收某个区域的交通流量预测消息，就会发送 UNSUBSCRIBE 报文取消订阅相关主题，服务端收到后返回 UNSUBACK 确认，避免该设备继续接收不必要的消息，节省网络带宽和设备资源 。