MQTT 协议详解

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是ISO/IEC 20922标准化的、基于发布 / 订阅（Pub/Sub）范式的轻量级消息传输协议，专为低带宽、高延迟、网络不稳定、算力 / 内存受限的物联网（IoT）设备设计，是目前物联网领域的主流通信协议。

一、协议发展与核心定位

发展历程

• 1999 年：由 IBM 与 Arcom 联合开发，最初用于石油管道跨洋遥测系统，解决极端弱网环境下的设备通信问题。
• 2014 年：MQTT 3.1.1 成为 OASIS 国际标准，是目前行业最广泛兼容的版本。
• 2019 年：MQTT 5.0 正式发布，新增大量企业级特性，成为云原生、大规模物联网场景的首选版本。

核心设计优势

• 极致轻量：最小报文仅 2 字节，协议开销极低，适配嵌入式设备与窄带网络。
• 解耦能力：发布 / 订阅架构彻底解耦消息生产者与消费者，双方无需感知对方的存在、IP 或状态。
• 可靠传输：3 级可配置的 QoS 服务质量，适配不同可靠性需求的业务场景。
• 弱网适配：内置遗嘱消息、心跳保活、离线消息等机制，完美应对不稳定的移动 / 物联网网络。
• 易扩展：支持 TLS 加密、身份认证、权限控制，可灵活对接各类业务系统。

二、核心架构与角色

MQTT 采用经典的发布 / 订阅架构，核心分为 3 个角色，所有通信均通过中间节点完成，无客户端点对点直连：

补充：一个 MQTT 客户端可同时承担发布者和订阅者双重角色。

三、核心基础概念

1. 主题（Topic）与通配符

主题是 MQTT 消息的路由标识，为 UTF-8 编码的字符串，通过/进行层级划分，例如sensor/temp/room1、device/car01/battery。

• 主题发布规则：发布者必须指定具体的完整主题，禁止使用通配符发布。
• 主题订阅规则：订阅者可通过通配符实现批量主题订阅，分为两种标准通配符：

1. 单层通配符+：匹配主题中单个层级，可出现在主题任意位置，例如sensor/+/room1可匹配sensor/temp/room1、sensor/hum/room1，但无法匹配sensor/temp/room1/floor1。
2. 多层通配符#：匹配主题中当前层级之后的所有层级，只能放在主题末尾，例如sensor/#可匹配sensor/temp/room1、sensor/hum/room1/floor1等所有以sensor/开头的主题。
3. 特殊主题：$开头的主题为系统保留主题（如$SYS/broker/uptime），用于 Broker 状态监控，普通客户端无法发布。

2. 会话（Session）

会话是客户端与 Broker 之间的状态上下文，分为两种类型：

• 非持久会话（Clean Session=1）：客户端断开连接后，Broker 立即清除该客户端的所有会话信息，包括订阅关系、未送达的离线消息。
• 持久会话（Clean Session=0）：客户端断开连接后，Broker 保留其订阅关系，并缓存符合 QoS 1/2 等级的离线消息，待客户端重连后立即推送；MQTT 5.0 支持自定义会话过期时间，灵活性更强。

3. 遗嘱消息（Will Message）

客户端在发起连接时可预设遗嘱消息，当客户端异常断开（未发送 DISCONNECT 报文、心跳超时、网络中断）时，Broker 会自动向预设的遗嘱主题发布该消息，通知其他订阅者该设备的离线状态，是物联网设备状态监控的核心机制。

MQTT 5.0 对遗嘱消息做了增强，支持遗嘱延迟、过期时间、自定义属性等。

4. 保留消息（Retained Message）

发布者可给消息设置Retain=1标志，Broker 收到后会存储该主题的最后一条保留消息。当有新的订阅者订阅该主题时，Broker 会立即将这条保留消息推送给订阅者，解决了 “新订阅者无法立即获取设备最新状态” 的问题。

每个主题仅会存储一条最新的保留消息，新的保留消息会覆盖旧的。

5. 心跳保活（Keep Alive）

客户端在连接时设置的最大时间间隔（单位：秒），用于客户端与 Broker 双向检测连接状态：

• 客户端在保活周期内无报文交互时，必须向 Broker 发送PINGREQ心跳请求。
• Broker 收到PINGREQ后，必须回复PINGRESP心跳响应。
• 若 Broker 超过 1.5 倍保活时间未收到客户端任何报文，会判定客户端离线，触发遗嘱消息。

四、MQTT 报文结构

所有 MQTT 报文均采用统一的三段式结构，分为固定报头、可变报头、有效载荷，其中固定报头是所有报文的必选部分，可变报头和有效载荷根据报文类型可选。

1. 固定报头（Fixed Header）

所有报文必备，最小长度 2 字节，是报文的核心控制部分：

• 第 1 字节：高 4 位为报文类型（定义了报文的核心功能，如 CONNECT、PUBLISH 等）；低 4 位为标志位，不同报文类型有专属的标志定义（如 PUBLISH 报文的 DUP 重传标志、QoS 等级、RETAIN 保留标志）。
• 第 2~5 字节：剩余长度字段，采用可变字节编码，最大支持 4 字节，用于标识后续可变报头 + 有效载荷的总字节数，最大支持 256MB 的单报文大小。

2. 可变报头（Variable Header）

可选部分，不同报文类型有不同的可变报头内容，用于承载报文的核心元数据。例如：

• CONNECT 报文的可变报头包含协议名、协议版本、连接标志、保活时间。
• PUBLISH 报文的可变报头包含主题名、报文标识符（QoS>0 时必备）。

3. 有效载荷（Payload）

可选部分，即报文的业务数据体，不同报文类型的载荷内容不同：

• CONNECT 报文：客户端 ID、用户名、密码、遗嘱主题与遗嘱内容。
• PUBLISH 报文：业务层的消息内容（如传感器数据、控制指令）。
• SUBSCRIBE 报文：待订阅的主题过滤器与对应的 QoS 等级。

核心控制报文类型

MQTT 3.1.1 定义了 14 种核心控制报文，覆盖全生命周期的通信流程，核心报文如下：

五、核心特性：QoS 服务质量等级

QoS（Quality of Service）是 MQTT 协议的核心能力，定义了消息传输的可靠性等级，客户端与 Broker 之间可针对每条消息独立配置 QoS，共分为 3 个等级，最终端到端的 QoS 取发布者到 Broker、Broker 到订阅者两段 QoS 的最小值。

QoS 0：最多一次（At Most Once）

• 传输保证：消息仅发送一次，无确认、无重传机制，网络异常时可能丢失。
• 传输流程：发布者→发送 PUBLISH 报文→结束，无后续交互。
• 适用场景：非关键的周期性数据上报，如环境传感器每秒的温度采集、设备非核心状态上报，丢失少量数据不影响业务。

QoS 1：至少一次（At Least Once）

• 传输保证：确保消息至少送达一次，无丢失风险，但可能出现重复消息。
• 传输流程：

1. 发布者发送带报文 ID 的 PUBLISH（QoS=1）报文，本地存储待确认消息。
2. 接收方收到消息后，回复对应报文 ID 的 PUBACK 确认报文。
3. 发布者收到 PUBACK 后，清除本地待确认消息；超时未收到则重传消息（DUP 标志置 1）。

• 适用场景：关键消息通知，可接受重复消息但不允许丢失，如设备告警、指令下发、开门记录等。

QoS 2：恰好一次（Exactly Once）

• 传输保证：最高可靠性等级，确保消息有且仅有一次送达，无丢失、无重复，是唯一能保证消息不重复的等级。
• 传输流程：四步握手机制

1. 发布者发送带报文 ID 的 PUBLISH（QoS=2）报文，本地存储待确认消息。
2. 接收方收到消息后，存储报文 ID，回复 PUBREC 确认报文。
3. 发布者收到 PUBREC 后，清除原待发布消息，存储 PUBREC 记录，发送 PUBREL 释放报文。
4. 接收方收到 PUBREL 后，清除报文 ID 记录，回复 PUBCOMP 完成报文，发布者收到后完成整个传输流程。

• 适用场景：对消息重复 / 丢失零容忍的核心业务，如金融交易、计费系统、设备核心控制指令、支付回调等。

六、MQTT 核心工作流程

1. 连接建立流程

1. 客户端先与 Broker 建立 TCP 连接（默认明文端口 1883，TLS 加密端口 8883，WebSocket 端口 8083/8084）。
2. 客户端向 Broker 发送 CONNECT 报文，携带客户端 ID、保活时间、清洁会话标志、用户名 / 密码、遗嘱消息等参数。
3. Broker 校验连接请求，回复 CONNACK 报文，报文中的连接返回码标识连接结果（0 = 连接成功，非 0 = 对应错误原因）。

2. 主题订阅流程

1. 连接成功后，客户端向 Broker 发送 SUBSCRIBE 报文，携带待订阅的主题过滤器列表与对应的期望 QoS 等级。
2. Broker 校验订阅权限，处理订阅请求，回复 SUBACK 报文，为每个主题返回对应的订阅结果（允许的 QoS 等级或订阅失败）。
3. 订阅成功后，Broker 会将匹配该主题的所有消息，按约定的 QoS 等级转发给该客户端。

3. 消息发布与转发流程

1. 发布者向 Broker 发送 PUBLISH 报文，指定目标主题、QoS 等级、保留标志与消息内容。
2. Broker 收到消息后，校验发布权限，若为保留消息则更新该主题的保留消息存储。
3. Broker 匹配所有订阅了该主题的客户端，按每个订阅者约定的 QoS 等级，将消息转发给对应的订阅者。

4. 连接断开流程

• 正常断开：客户端先向 Broker 发送 DISCONNECT 报文，Broker 收到后清除该客户端的遗嘱消息，客户端关闭 TCP 连接，会话按清洁会话标志处理。
• 异常断开：客户端网络中断、心跳超时、未发送 DISCONNECT 报文直接断开 TCP 连接，Broker 判定客户端离线，触发预设的遗嘱消息发布。

七、MQTT 5.0 与 3.1.1 核心差异

MQTT 5.0 在完全兼容 3.1.1 的基础上，新增了大量企业级特性，解决了大规模物联网集群的核心痛点，核心升级如下：

八、安全机制

MQTT 提供了多层安全防护体系，覆盖物联网全场景的安全需求：

1. 传输层加密：原生支持 TLS/SSL 加密（端口 8883），防止报文被窃听、篡改、伪造，支持双向 TLS 证书认证，实现客户端与 Broker 的双向身份校验。
2. 应用层认证：CONNECT 报文中支持用户名 / 密码认证，可对接企业账号体系、OAuth2.0、JWT、API Key 等认证方式。
3. 访问控制（ACL）：Broker 可实现精细化的权限管控，限制客户端对指定主题的发布 / 订阅权限，例如仅允许设备发布自身设备号前缀的主题。
4. 协议防护：支持报文大小限制、连接速率限制、消息限流、非法主题过滤等，抵御恶意攻击与泛洪攻击。

九、典型应用场景

• 物联网（IoT）：智能家居、工业物联网（IIoT）、车联网、智慧农业、环境监测、智能电表 / 水表等低功耗、弱网环境的设备通信。
• 移动互联网：APP 消息推送、即时通讯、移动端状态同步，低功耗适配手机、平板等移动设备。
• 实时数据传输：直播弹幕、实时监控数据、金融行情推送、物流轨迹实时更新。
• 边缘计算：边缘设备与云端的消息交互，边缘节点之间的协同通信，适配窄带、低带宽的边缘网络。
• 医疗健康：可穿戴设备健康数据上报、医疗设备远程监控、远程诊疗指令下发。

十、主流实现方案

开源 Broker 实现

• EMQX：国产开源高可用 MQTT Broker，支持 MQTT 3.1.1/5.0，单机支持百万级并发连接，集群支持亿级设备接入，是国内物联网行业的主流选型。
• Eclipse Mosquitto：Eclipse 基金会开源的轻量级 MQTT Broker，资源占用极低，适合嵌入式设备、边缘网关与小型部署场景。
• VerneMQ：开源分布式 MQTT Broker，基于 Erlang 开发，支持高可用集群与水平扩展。
• HiveMQ：企业级 MQTT Broker，提供开源社区版与商业版，主打大规模集群与高可靠性。

主流客户端库

• Eclipse Paho：Eclipse 官方开源客户端，支持 Java、Python、C、C++、JavaScript、Go 等几乎所有主流编程语言，兼容性最强。
• MQTT.js：专为浏览器与 Node.js 设计的 JavaScript MQTT 客户端，支持 WebSocket 传输。
• paho-mqtt：Python 官方推荐的 MQTT 客户端库，简单易用，兼容 MQTT 3.1.1/5.0。

十一、常见误区澄清

1. MQTT 不是消息队列：尽管名称包含 “Message Queuing”，但 MQTT 是消息传输协议，而非消息队列；它没有队列的概念，仅基于主题匹配做消息转发，与 Kafka、RabbitMQ 等消息中间件有本质区别。
2. QoS 是端到 Broker 的，而非端到端的：发布者到 Broker 的 QoS，与 Broker 到订阅者的 QoS 是相互独立的，最终端到端的有效 QoS 为两者的最小值。
3. 通配符仅用于订阅：发布者必须指定具体的完整主题，禁止使用通配符发布消息，只有订阅者可以使用通配符批量订阅主题。
4. 保留消息不是持久化消息：保留消息仅存储主题的最新一条消息，用于新订阅者的即时状态同步，与消息持久化、离线消息缓存是两个独立的机制。