MQTT 协议概念详解
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种轻量级、基于发布 / 订阅（Publish/Subscribe）模式的物联网（IoT）通信协议，由 IBM 在 1999 年首次提出，最初用于解决石油和天然气行业远程设备的低带宽、高延迟数据传输问题，如今已成为物联网领域最主流的通信协议之一，被广泛应用于智能家居、工业监控、车联网、远程医疗等场景。
一、MQTT 协议的核心定位：为何是 “轻量级”？
MQTT 的核心优势在于 “轻量”，这一特性使其能适配物联网场景中资源受限的设备（如传感器、嵌入式设备，通常内存小、算力低）和不稳定的网络环境（如低带宽、高丢包率的无线通信），具体体现在以下两点：
- 协议头部极小：固定头部仅 2 字节，可变头部和有效载荷按需添加，极大减少数据传输量（例如，一条简单的传感器数据（如 “温度 25℃”）的 MQTT 数据包大小可能仅几十字节）。
- 低资源消耗：客户端（设备）实现 MQTT 协议所需的代码量少（核心逻辑仅需几百行代码），对设备内存、CPU 的占用极低，甚至可在 8 位单片机上运行。
二、MQTT 的核心架构：发布 / 订阅（Pub/Sub）模式
MQTT 不采用传统的 “客户端 – 服务器直接通信”（如 HTTP 的请求 / 响应模式），而是通过 “发布 / 订阅” 模式解耦设备间的通信，核心包含 3 个角色：
角色 | 核心功能 | 典型示例 |
发布者（Publisher） | 产生并发送消息的设备 / 应用，不关心谁接收消息（无直接交互） | 温度传感器、智能门锁（发送 “门已打开” 消息） |
订阅者（Subscriber） | 主动订阅感兴趣的消息类型，仅接收订阅过的消息 | 手机 APP（订阅 “客厅温度”）、报警系统（订阅 “门锁异常”） |
** broker（服务器）** | 核心中间件，负责接收发布者的消息，根据 “主题（Topic）” 筛选并转发给对应的订阅者，是 “发布 / 订阅” 模式的核心枢纽 | EMQX、Mosquitto、AWS IoT Core |
举个通俗例子：
发布者如同 “报社”，只负责印刷报纸（发送消息）；订阅者如同 “订报人”，只接收自己订阅的报纸（如 “体育报”“财经报”）；Broker 则是 “邮局”，负责将不同类型的报纸精准送到对应的订报人手中 —— 报社和订报人无需知道彼此的存在，完全由邮局衔接。
三、MQTT 的关键核心概念
1. 主题（Topic）：消息的 “分类标签”
Topic 是 MQTT 中消息的 “地址标识”，用于区分不同类型的消息，Broker 通过 Topic 判断消息该转发给哪些订阅者。
- 格式规则：用斜杠（/）分隔层级，支持多层级分类，例如：
- home/livingroom/temperature（客厅温度）
- home/bedroom/light（卧室灯光状态）
- car/engine/speed（汽车发动机转速）
- 通配符支持：订阅者可通过通配符订阅一类消息（发布者不可用通配符）：
- +：匹配单个层级的任意内容，例如 home/+/temperature 可订阅 “home 下所有房间的温度”（如home/livingroom/temperature、home/bedroom/temperature）。
- #：匹配当前及以下所有层级（仅能放在 Topic 末尾），例如 home/# 可订阅 “home 下所有消息”（包括温度、灯光、门锁等）。
2. 服务质量（QoS）：消息可靠性的 “保障等级”
MQTT 定义了 3 种 QoS 等级，用于平衡 “消息可靠性” 和 “网络开销”，适配不同场景的需求：
QoS 等级 | 名称 | 核心逻辑 | 适用场景 |
QoS 0 | 最多一次（At Most Once） | 发布者仅发送一次消息，不确认、不重发；Broker 收到后直接转发，不存储。可能丢包。 | 非关键数据，如实时温度采集（丢一条不影响整体监控）。 |
QoS 1 | 至少一次（At Least Once） | 发布者发送消息后，需等待 Broker 的 “确认（ACK）”；若未收到 ACK 则重发，直到收到为止。消息可能重复，但不会丢失。 | 关键但可容忍重复的数据，如设备报警（确保报警必到，重复可后续去重）。 |
QoS 2 | 恰好一次（Exactly Once） | 采用 “四次握手” 机制（发布者→Broker、Broker→发布者确认、Broker→订阅者、订阅者→Broker 确认），确保消息仅被接收一次，不丢包、不重复。 | 绝对不能重复 / 丢失的数据，如金融交易、设备指令（如 “扣款”“启动设备”）。 |
3. 会话（Session）与持久化
MQTT 支持 “会话持久化”，确保设备离线后消息不丢失：
- 持久会话（Clean Session = 0）：Broker 会保存订阅者的订阅关系和未送达的 QoS 1/2 消息；当订阅者重新连接时，Broker 会将未送达的消息补发，且无需重新订阅。
- 临时会话（Clean Session = 1）：Broker 不保存订阅关系和未送达消息；订阅者断开连接后，会话信息立即删除，重新连接时需重新订阅。
4. 保留消息（Retained Message）
发布者可在发送消息时设置 “保留标志”，Broker 会保存该 Topic 的最新一条保留消息：
- 新订阅该 Topic 的订阅者，无需等待发布者再次发送，会直接收到 Broker 保存的最新保留消息。
- 例如：传感器每隔 1 小时发送一次温度（保留消息），新打开的 APP 订阅温度 Topic 时，会立即收到 1 小时内的最新温度，无需等待 1 小时。
5. 遗嘱消息（Last Will and Testament, LWT）
设备（客户端）连接 Broker 时，可预先设置 “遗嘱消息” 和 “遗嘱 Topic”：
- 若设备异常断开连接（如断电、网络中断，未发送 “断开连接（DISCONNECT）” 指令），Broker 会自动将 “遗嘱消息” 发送到预设的 “遗嘱 Topic”。
- 例如：智能门锁连接时设置 “遗嘱消息 = 离线”“遗嘱 Topic=home/door/state”，若门锁断电，Broker 会向订阅该 Topic 的手机 APP 发送 “离线” 消息，提示用户门锁异常。
四、MQTT 的通信流程（简化版）
以 “温度传感器向手机 APP 发送温度” 为例，核心流程如下：
- 连接阶段：温度传感器（发布者）和手机 APP（订阅者）分别与 Broker 建立 TCP 连接（MQTT 基于 TCP 协议，确保底层通信可靠），并在连接时指定 “Clean Session”“LWT” 等参数。
- 订阅阶段：手机 APP 向 Broker 发送 “订阅请求”，指定要订阅的 Topic（如home/livingroom/temperature）和 QoS 等级（如 QoS 1）；Broker 确认后，保存 APP 的订阅关系。
- 发布阶段：温度传感器采集到 “25℃” 后，向 Broker 发送 “发布请求”，包含 Topic（home/livingroom/temperature）、消息内容（“25”）、QoS 等级（QoS 1）。
- 转发阶段：Broker 收到发布者的消息后，检查该 Topic 的订阅者列表，将消息转发给手机 APP；APP 收到消息后，向 Broker 发送 ACK 确认（QoS 1 要求）。
- 断开阶段：若设备无需通信，可主动向 Broker 发送 “DISCONNECT” 指令，断开 TCP 连接；若异常断开，Broker 触发 LWT 机制。
五、MQTT 的典型应用场景
由于其轻量、可靠、低功耗的特性，MQTT 几乎覆盖物联网所有领域：
- 智能家居：传感器（温度、湿度、人体感应）向网关发送数据，网关转发给手机 APP；APP 向智能灯、空调发送控制指令。
- 工业物联网（IIoT）：工厂设备（机床、传感器）向监控平台发送运行数据（如转速、温度），平台向设备发送调度指令。
- 车联网（V2X）：车载设备向云端发送车辆状态（速度、油量），云端向车辆推送导航、预警信息；车辆之间通过 MQTT 交换路况数据。
- 远程医疗：医疗设备（血糖仪、心率监测仪）向医院平台发送患者数据，平台向设备发送校准指令。
- 农业物联网：农田传感器（土壤湿度、光照）向云端发送数据，云端根据数据自动控制灌溉设备。
六、常见的 MQTT Broker 与客户端工具
- Broker（服务器）：
- 开源：Mosquitto（轻量级，适合小型场景）、EMQX（高并发，支持百万级连接，适合企业级场景）、ActiveMQ。
- 云服务：AWS IoT Core、阿里云 IoT 平台、腾讯云 IoT Explorer。
- 客户端工具（调试 / 测试）：
- MQTT X（跨平台，图形化界面，支持发布 / 订阅、QoS 设置）、MQTT.fx、mosquitto_sub/mosquitto_pub（命令行工具）。
综上，MQTT 协议通过 “轻量级设计”“发布 / 订阅解耦”“灵活的 QoS 保障”，完美解决了物联网场景中设备资源有限、网络不稳定的核心痛点，成为连接 “物与物”“物与人” 的关键通信标准。