1. 协议概述

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一套运行在TCP/IP协议之上的轻量级发布/订阅模式应用层协议。其名称虽包含“队列”，但协议本身不具备消息持久化队列能力，仅实现消息分发与投递，持久化能力完全依赖Broker实现。

协议核心设计目标：低带宽、低功耗、弱网络兼容、适配资源受限设备、支持百万级长连接，是物联网IoT、边缘设备通信的工业标准协议。主流端口规范：明文1883、TLS加密8883、WebSocket明文8083、WebSocket加密8084。

2. 核心架构模型

MQTT采用去中心化解耦的发布-订阅模型，核心分为三类角色，发布者与订阅者全程无直接通信，所有消息经由Broker中转。

2.1 核心角色

• Broker（服务端代理）：核心枢纽，负责接收消息、校验权限、匹配主题、分发消息、维护客户端会话与连接状态。主流开源实现：EMQX、Mosquitto、VerneMQ。

• Publisher（发布者）：消息生产者，向指定Topic推送业务数据，无需关注订阅方信息。

• Subscriber（订阅者）：消息消费者，订阅目标Topic过滤器，被动接收Broker推送的匹配消息。

2.2 Topic主题规则

Topic为层级式字符串，以/分割，区分大小写，是消息匹配的唯一依据，分为精准主题与通配符过滤器：

• 单层通配符 +：匹配单个层级，例：sensor/+/temp 匹配 sensor/room1/temp，不跨层级。

• 多层通配符 #：匹配后续所有层级，仅可放置在主题末尾，例：device/# 匹配所有device下级主题。

3. 核心关键机制

3.1 QoS消息投递质量等级

MQTT核心可靠性保障机制，用于适配不同业务的消息一致性需求，仅对当前一次消息会话生效：

• QoS 0（最多一次）：无应答、无重发，单向投递。速度最快、开销最低，适用于高频非关键数据（实时温湿度、设备心跳数据），存在丢包风险。

• QoS 1（至少一次）：两次握手（PUBLISH→PUBACK）。保证消息一定送达，超时未收到应答则自动重发，会产生消息重复，适用于设备状态上报、告警通知、交易数据。

• QoS 2（恰好一次）：四次握手（PUBLISH→PUBREC→PUBREL→PUBCOMP）。彻底杜绝丢失与重复，开销最大、时延最高，仅用于指令类核心场景（设备OTA升级、远程开关锁、计费控阀）。

3.2 Retain保留消息

发布消息时设置retain=1，Broker会持久化该主题的最新一条消息。新客户端订阅对应主题后，会立即收到该保留消息，无需等待设备下次上报。核心用途：设备初始状态同步、APP/大屏页面初始化数据加载。

3.3 Will遗嘱消息

客户端建立连接时预先注册离线消息（主题、载荷、QoS、retain）。仅在客户端异常断开（断电、断网、进程崩溃、心跳超时）时，Broker自动推送遗嘱消息；客户端主动发送DISCONNECT正常断开时，不触发遗嘱机制。核心用途：设备离线状态监测、无人值守设备故障告警。

3.4 KeepAlive心跳保活

连接握手时约定心跳时间（秒），客户端必须在心跳周期内发送任意报文，无业务数据则发送PINGREQ心跳包，Broker回复PINGRESP确认在线。Broker判定离线阈值为1.5倍心跳时间，超时未检测到客户端报文则强制断开连接并触发遗嘱消息。

3.5 CleanSession会话机制

• CleanSession=1：临时会话。连接断开后，Broker清空该客户端的订阅关系、未送达消息，重连后需重新订阅，适用于移动端APP、临时监控终端。

• CleanSession=0：持久会话。Broker永久保存订阅关系与离线积压消息，客户端重连后自动补发QoS1/QoS2未送达消息，适用于无人值守物联网终端、工业设备。

4. MQTT完整工作流程

MQTT通信必须基于TCP长连接，全程分为6个阶段，TCP连接成功不代表MQTT会话建立，仅完成底层链路初始化。

1. TCP三次握手：客户端与Broker建立底层TCP套接字链路。

2. MQTT握手鉴权：客户端发送CONNECT报文（携带ClientId、心跳、会话模式、账号密码、遗嘱配置），Broker返回CONNACK应答，确认MQTT会话建立成功。

3. 主题订阅：订阅端发送SUBSCRIBE报文（主题过滤器+QoS），Broker返回SUBACK确认订阅结果，自动下发对应主题Retain消息。

4. 消息发布与分发：发布端推送PUBLISH报文，Broker更新Retain消息、匹配订阅客户端，按对应QoS规则分发消息。

5. 心跳维持连接：周期发送PINGREQ/PINGRESP保活，维持长连接状态。

6. 连接断开：主动发送DISCONNECT为优雅断开，无遗嘱触发；异常超时断开触发遗嘱消息推送。

5. 协议版本核心差异

5.1 MQTT 3.1.1（经典版）

兼容性最强、生态最成熟，适配99%老旧物联网设备，功能精简，满足基础发布订阅、QoS、遗嘱、保留消息核心能力，无高级扩展特性，是传统IoT项目主流选择。

5.2 MQTT 5.0（增强版）

新一代标准，向下不兼容，新增企业级核心能力：共享订阅（集群负载均衡）、消息过期时间、自定义用户属性、完整错误码、主题别名、最大报文长度限制，适合高并发、集群化、标准化的现代化IoT平台，新项目优先选用。

6. 报文结构规范

所有MQTT报文由三部分组成，最小报文仅2字节，极致精简：

• 固定头部（必选）：标识报文类型、QoS等级、重发标志、剩余长度。

• 可变头部（可选）：部分报文独有，包含报文标识、主题名等关键信息。

• 有效载荷Payload（可选）：业务原始数据，协议无格式限制，行业统一使用JSON格式。

7. 核心应用场景与特性匹配

业务场景	核心使用特性	适配原因
智能家居设备状态上报与控制	Retain、Will、低功耗、双向通信	弱网适配，APP秒获设备状态，自动感知设备离线
工业设备数据采集、故障告警	QoS1/QoS2、CleanSession离线缓存	保障告警、参数指令不丢失，断网重连补发数据
充电桩、智能表计、新能源设备	QoS1、主题分级、低带宽占用	海量分散设备适配4G/NB-IoT弱网，保障计费数据可靠
智慧农业野外设备监控	低功耗、Will离线检测、轻量报文	无人值守、野外弱网、低供电场景适配
设备OTA远程升级	QoS2、持久会话	杜绝升级指令重复/丢失，防止设备变砖
物联网大屏实时展示	MQTT over WebSocket、通配符订阅	浏览器直接接入，毫秒级批量数据刷新

8. 协议优缺点总结

8.1 核心优势

• 极致轻量：最小2字节报文，带宽、算力、功耗消耗极低，适配单片机等低端设备；

• 高度解耦：发布订阅架构，设备无需点对点对接，扩展性极强；

• 可靠性可控：三级QoS适配不同业务场景，兼顾速度与可靠性；

• 弱网适配：支持心跳保活、离线会话、重连补发，容忍网络抖动与断连；

• 高并发能力：支持十万/百万级设备长连接，Broker生态成熟稳定。

8.2 局限性

• 无原生持久化：协议本身不存储消息，依赖Broker实现持久化与堆积；

• 不适合大数据传输：仅适配短小高频报文，不支持视频、大文件传输；

• QoS2开销较高：四次握手机制会增加时延与网络开销，高并发场景需谨慎使用；

• 非通用IM协议：不适合海量用户即时聊天场景，仅适配设备通信。

9. 技术选型准则

9.1 优先选用MQTT的场景

资源受限嵌入式设备、弱网络4G/NB-IoT环境、大量长连接终端、双向实时指令交互、设备状态监控与告警场景。

9.2 不适用MQTT的场景

大文件/流媒体传输、高一致性事务业务、海量用户社交IM聊天、复杂接口交互业务（此类场景优先使用HTTP、WebSocket原生协议、专用消息队列）。