MQTT 协议核心概念详解：从入门到实践

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是物联网领域最广泛使用的轻量级通信协议。本文从核心概念出发，系统讲解 MQTT 的工作原理、关键机制与最佳实践。

---

目录

• 1. 为什么是 MQTT？
• 2. 核心架构：发布/订阅模型
• 3. 四大核心角色
• 4. 主题（Topic）设计
• 5. 服务质量（QoS）深度解析
• 6. 会话机制
• 7. 遗嘱消息（Last Will and Testament）
• 8. 保留消息（Retained Messages）
• 9. 心跳保活（Keep Alive）
• 10. MQTT 5.0 核心升级
• 11. MQTT over WebSocket
• 12. 安全最佳实践
• 13. 协议对比：MQTT vs HTTP vs CoAP vs AMQP
• 14. 学习路线图

---

1. 为什么是 MQTT？

在物联网场景中，设备通常面临以下挑战：

• 带宽有限：NB-IoT、LoRa 等网络带宽仅几十 kbps
• 电量受限：电池供电设备需要最小化通信开销
• 网络不稳定：设备频繁上下线，需要断线重连与消息缓存
• 设备数量庞大：百万级设备同时在线，需要高效的消息路由

MQTT 正是为这些约束条件而设计：

特性	说明
轻量级	最小的协议报文仅 2 字节，非常适合低带宽网络
双向通信	既能上报数据，也能接收指令，支持真正的设备控制
可靠送达	三级 QoS 满足不同可靠性需求
发布/订阅解耦	发布者与订阅者互不知晓，架构灵活易扩展
会话保持	设备断线重连后可恢复订阅和接收离线消息
标准化	OASIS 标准（ISO/IEC 20922），生态成熟

---

2. 核心架构：发布/订阅模型

MQTT 的核心通信模式是 发布/订阅（Publish/Subscribe），这与传统的请求/响应模式有本质区别：

传统请求/响应模式：
┌──────────┐   请求   ┌──────────┐
│  Client  │ ──────→ │  Server  │
│          │ ←────── │          │
└──────────┘   响应   └──────────┘

MQTT 发布/订阅模式：
┌──────────┐                          ┌──────────┐
│ Publisher │ ── publish(topic, msg) →│  Broker  │
└──────────A┘                          │          │
                                      │  路由转发  │
┌──────────┐                          │          │
│Subscriber │ ←── push(topic, msg) ── │          │
└──────────┘                          └──────────┘

发布/订阅模式的三大解耦优势：

1. 空间解耦：发布者不需要知道订阅者的地址，只需向 Broker 发送消息
2. 时间解耦：发布者和订阅者不需要同时在线，Broker 可缓存离线消息
3. 同步解耦：发布与接收异步进行，互不阻塞

---

3. 四大核心角色

角色	英文	职责
Broker	服务器/代理	接收所有消息，按主题路由分发。是系统的”中央邮局”
Publisher	发布者	产生数据并发布到指定主题的设备或应用（传感器、手机 App）
Subscriber	订阅者	向 Broker 注册对某主题的”兴趣”，接收相关消息（监控面板、数据库）
Topic	主题	消息的”地址”，用 / 分隔的层级字符串（如 home/livingroom/temperature）

关键理解：一个客户端可以同时是 Publisher 和 Subscriber。例如，网关设备既发布传感器数据（Publisher），也订阅控制指令（Subscriber）。

---

4. 主题（Topic）设计

4.1 命名规范

MQTT 主题是 UTF-8 编码的字符串，区分大小写，使用 / 分隔层级：

✅ 推荐：
sensor/temperature/room1
factory/line3/motor/speed
device/ECU1051/status

❌ 避免：
sensor/temperature/room1/    ← 以 / 结尾（虽合法但不规范）
sensor//temperature           ← 空层级（虽合法但易混淆）

4.2 通配符

订阅时可以使用通配符来匹配多个主题：

通配符	含义	示例订阅	匹配的主题
+	匹配 单个 层级	home/+/temperature	home/livingroom/temperature，home/bedroom/temperature
#	匹配 零个或多个 层级	home/#	home/temperature，home/livingroom/light，home/bedroom/humidity

⚠️ # 必须是主题的最后一级，home/#/light 是非法写法。

4.3 系统主题（EMQX 特有）

EMQX 提供了以 $ 开头的系统主题，用于获取 Broker 内部状态：

$SYS/brokers/+/clients/connected       # 客户端上线通知
$SYS/brokers/+/clients/disconnected    # 客户端下线通知
$SYS/brokers/+/clients/count           # 当前连接数
$SYS/brokers/+/messages/sent           # 已发送消息数

---

5. 服务质量（QoS）深度解析

MQTT 提供三个 QoS 等级，在消息可靠性和网络开销之间平衡。理解其协议层面的交互细节对于正确选型至关重要。

5.1 QoS 0：最多一次（At most once）

Publisher                     Broker                     Subscriber
    │                            │                            │
    │ ─── PUBLISH(QoS0) ──────→ │ ─── PUBLISH(QoS0) ──────→ │
    │                            │                            │
    ╳  消息可能丢失，无重传机制    ╳

• 特点：发出即忘，不等待确认，不重传
• 适用场景：高频传感器数据（如每秒上报温度），偶尔丢失几条无影响
• 开销：最低

5.2 QoS 1：至少一次（At least once）

Publisher                     Broker                     Subscriber
    │                            │                            │
    │ ─── PUBLISH(QoS1, pktId) → │ ─── PUBLISH(QoS1, pktId) → │
    │          [存储 pktId]       │          [存储 pktId]       │
    │ ←── PUBACK(pktId) ──────── │ ←── PUBACK(pktId) ──────── │
    │          [删除 pktId]       │          [删除 pktId]       │
    │                            │                            │
    ⚠ 如果 PUBACK 丢失，PUBLISH 会被重发 → 订阅者可能收到重复消息

• 特点：确保消息至少送达一次，但可能重复
• 适用场景：常规传感器数据、设备状态上报
• 开销：中等（需要 PUBACK 确认 + 重传机制）
• 应对重复：订阅端需实现幂等处理（如根据消息 ID 去重）

5.3 QoS 2：恰好一次（Exactly once）

Publisher                     Broker                     Subscriber
    │                            │                            │
    │ ─── PUBLISH(QoS2, pktId) → │                            │
    │ ←── PUBREC(pktId) ──────── │                            │
    │ ─── PUBREL(pktId) ───────→ │ ─── PUBLISH(QoS2, pktId) → │
    │          [开始分发]          │ ←── PUBREC(pktId) ──────── │
    │ ←── PUBCOMP(pktId) ─────── │ ─── PUBREL(pktId) ───────→ │
    │          [最终确认]          │ ←── PUBCOMP(pktId) ─────── │
    │                            │          [最终确认]          │

• 交互流程：PUBLISH → PUBREC → PUBREL → PUBCOMP，完整的四次握手
• 特点：确保消息 不丢不重，送达恰好一次
• 适用场景：支付指令、固件升级命令、关键控制指令
• 开销：最高（四次握手，状态机复杂）

5.4 QoS 降级规则

当发布者 QoS 和订阅者 QoS 不同时，Broker 会按较低等级降级转发：

发布者 QoS	订阅者 QoS	实际送达 QoS
0	2	0
2	0	0
1	2	1
2	1	1

这意味着：想让消息以 QoS 2 送达，发布者和订阅者都必须设为 QoS 2。

---

6. 会话机制

会话（Session）是 MQTT 协议保证通信连续性的核心机制。

6.1 什么是会话？

会话是 Broker 为每个客户端维护的一组状态数据：

服务端（Broker）存储：

• 会话是否存在
• 客户端的订阅列表
• 已发送但未确认的 QoS 1/2 消息
• 待传输的 QoS 0/1/2 离线消息
• 遗嘱消息内容
• 会话过期时间

客户端存储：

• 已发送但未确认的 QoS 1/2 消息
• 从服务端收到但未确认的 QoS 2 消息

6.2 Clean Start 与会话过期间隔（MQTT 5.0）

MQTT 5.0 将 MQTT 3.1.1 的 Clean Session 拆分为两个独立参数：

参数	取值	含义
Clean Start	0	复用已有会话（断线重连后恢复订阅和消息）
	1	丢弃旧会话，创建全新会话
Session Expiry Interval	0	连接断开后会话立即过期
	N (秒)	连接断开后会话保留 N 秒
	0xFFFFFFFF	会话永不过期

6.3 MQTT 3.1.1 vs MQTT 5.0 会话机制对比

场景	MQTT 3.1.1	MQTT 5.0
不保存会话	Clean Session = 1	Clean Start = 1
永久保存会话	Clean Session = 0	Clean Start = 0, Session Expiry = 0xFFFFFFFF
会话保留 5 分钟	❌ 不支持	✅ Clean Start = 0, Session Expiry = 300

MQTT 3.1.1 的会话只有”永久”和”不保存”两种选择，这是协议设计的不灵活之处。EMQX 提供了 mqtt.session_expiry_interval 配置项来为 3.1.1 客户端设置统一的过期时间。

6.4 持久会话实践建议

1. 评估资源消耗：会话过期时间越长，Broker 存储开销越大。EMQX 默认每会话最多缓存 1000 条消息
2. 按设备类型设置：关键设备设较长过期时间，非关键设备设较短或 0
3. 正确处理重连：重连时使用相同 Client ID + Clean Start = 0 才能恢复会话

---

7. 遗嘱消息（Last Will and Testament）

7.1 工作原理

遗嘱消息（LWT）是 MQTT 的一项重要容错机制：客户端在连接时预设一条消息，当 Broker 检测到该客户端 异常断开 时，自动将此消息发布到指定主题。

客户端连接时：
┌──────────┐   CONNECT(will_topic="status/device1",
│ Device1  │          will_msg="offline",
│          │          will_qos=1, will_retain=true)
└────┬─────┘ ──────────────────────────────────→  ┌────────┐
     │                                              │ Broker │
     │                                              └────────┘
     
设备异常断开后（未发送 DISCONNECT）：
┌────────┐
│ Broker │ ── publish("status/device1", "offline", retain=true) ──→ 订阅者
└────────┘

7.2 触发条件

情况	是否触发遗嘱消息
网络中断（TCP 连接断开）	✅
设备断电 / 宕机	✅
心跳超时（Keep Alive 超时未收到 PINGREQ）	✅
客户端主动发送 DISCONNECT 报文	❌
Broker 主动关闭连接	✅

7.3 典型应用

python

# Python paho-mqtt 设置遗嘱消息示例
import paho.mqtt.client as mqtt

client = mqtt.Client(client_id="sensor_001")
client.username_pw_set("user", "password")

# 设置遗嘱消息：设备异常断开时，通知其他订阅者
client.will_set(
    topic="status/sensor_001",
    payload="offline",
    qos=1,
    retain=True  # 保留消息，新订阅者也能立即获知设备离线状态
)

client.connect("broker.example.com", 1883, keepalive=60)
client.loop_start()

---

8. 保留消息（Retained Messages）

8.1 工作原理

发布者可以将某条消息标记为”保留”。Broker 会存储该主题下最新的一条保留消息，当有新订阅者订阅该主题时，立即收到这条保留消息，无需等待发布者下一次发布。

① 发布者发布保留消息：
Publisher ── publish("config/device1", '{"interval": 60}', retain=True) ──→ Broker

② 新订阅者上线并订阅：
Subscriber ── subscribe("config/device1") ──→ Broker
Subscriber ←── publish("config/device1", '{"interval": 60}', retain=True) ── Broker
              ↑ 立即收到保留消息！

8.2 清除保留消息

bash

# 发布一条空消息到该主题（Payload 为空），即可清除保留消息
mosquitto_pub -h localhost -t "config/device1" -n -r
# -n: 空消息  -r: 保留标志

8.3 典型应用

• 配置下发：设备上线后立即获取最新配置
• 状态同步：新监控面板打开后立即看到设备上一次上报的状态
• 公告信息：系统广播消息，确保后来的订阅者也能看到

---

9. 心跳保活（Keep Alive）

9.1 工作机制

Keep Alive 是客户端在 CONNECT 报文中设定的心跳间隔（单位：秒）。在此时间内如果没有消息交互，客户端必须发送 PINGREQ 报文，Broker 回复 PINGRESP。

      客户端                          Broker
        │                               │
        │ ─── CONNECT(keepalive=60) ──→ │
        │                               │
        │      [1.5 × keepalive]         │
        │        无消息交互               │
        │                               │
        │ ─── PINGREQ ────────────────→ │
        │ ←── PINGRESP ──────────────── │
        │                               │
        │  如果 1.5 × keepalive 内      │
        │  未收到 PINGREQ                │
        │                               │
        │   连接被 Broker 断开 ❌         │

9.2 合理设置

网络环境	推荐 Keep Alive 值
稳定局域网	60 ~ 120 秒
4G / 5G 移动网络	30 ~ 60 秒
NB-IoT / 弱信号	120 ~ 300 秒
卫星通信	600 秒以上

⚠️ 误区纠正：Keep Alive 不是”多久发一次数据”，而是”多久发一次心跳”。数据报文和心跳报文都会重置计时器。

---

10. MQTT 5.0 核心升级

MQTT 5.0（2019 年发布）相比 MQTT 3.1.1 有显著改进，以下是核心新特性：

10.1 原因码与更详细的错误信息

# MQTT 3.1.1：CONNACK 只知道"连接失败" 
# MQTT 5.0：CONNACK 携带具体原因
原因码 0x86 → "Bad User Name or Password"
原因码 0x87 → "Not Authorized"
原因码 0x89 → "Server Busy"

10.2 会话过期间隔（Session Expiry Interval）

（详见 第 6 节）

10.3 消息过期间隔（Message Expiry Interval）

为单条消息设置生存时间（TTL），超时后 Broker 自动丢弃：

bash

# MQTTX CLI 发布一条 30 秒后过期的消息
mqttx pub -h broker.emqx.io -t "alert/temp" \
  -m "Overheat!" --message-expiry-interval 30

10.4 主题别名（Topic Alias）

用整数编号代替冗长的主题字符串，显著减少报文大小：

# 第一次：主题 "factory/line3/station7/temperature" 映射为别名 1
# 后续：只需发送 "别名 1 + Payload"，节省带宽

10.5 用户属性（User Properties）

在报文中附加自定义键值对（元数据），增强扩展性：

User Property: "model" = "ECU-1051"
User Property: "firmware" = "v2.3.1"
User Property: "region" = "ap-east-1"

10.6 共享订阅（Shared Subscription）

多个客户端订阅同一主题，Broker 按负载均衡分发消息（而不是每个订阅者都收到）：

# 共享订阅语法（EMQX）：$share/<分组名>/<主题>
$share/processor_group/orders/#
→ 订单消息在 processor_group 组内轮询分发

10.7 请求/响应模式

MQTT 5.0 在协议层面支持请求-响应交互，通过在 PUBLISH 报文中携带 Response Topic 和 Correlation Data：

# 请求方发布消息，指定回复主题
publish(topic="cmd/device/reboot", response_topic="reply/req001", correlation_data="req001")

# 响应方收到后，将结果发布到 response_topic
publish(topic="reply/req001", payload="success", correlation_data="req001")

10.8 版本选择建议

场景	推荐版本
新项目，无历史包袱	MQTT 5.0
已有 3.1.1 设备，需兼容	MQTT 3.1.1（或双协议并存）
大多数 IoT 学习场景	MQTT 3.1.1 入门，再补 5.0

EMQX 同时支持 MQTT 3.1、3.1.1 和 5.0，不同版本的客户端可以无缝共存。

---

11. MQTT over WebSocket

11.1 为什么需要 WebSocket？

标准 MQTT 基于 TCP，但浏览器中的 JavaScript 无法直接建立 TCP 连接。WebSocket 是浏览器原生支持的双向通信协议，MQTT over WebSocket 让浏览器也能直接参与 MQTT 通信。

┌─────────────┐                              ┌─────────────┐
│ 浏览器 / Web  │ ←── WebSocket ──→  端口 8083  │   EMQX      │
│  应用        │    (ws://...)                 │   Broker    │
└─────────────┘                              └──────┬──────┘
                                                    │ 内部路由
                                          ┌─────────┴─────────┐
                                          │                   │
                                    ┌─────┴─────┐     ┌──────┴──────┐
                                    │  TCP 设备  │     │  WebSocket  │
                                    │  (1883)   │     │  设备 (8083) │
                                    └───────────┘     └─────────────┘

11.2 JavaScript 连接示例

html

<!-- 在网页中使用 MQTT.js 通过 WebSocket 连接 EMQX -->
<script src="https://unpkg.com/mqtt/dist/mqtt.min.js"></script>
<script>
  const client = mqtt.connect('ws://broker.example.com:8083/mqtt', {
    username: 'web_user',
    password: 'your_password',
    clientId: 'dashboard_' + Math.random().toString(16).substr(2, 8),
    clean: true,
    keepalive: 30
  });

  client.on('connect', () => {
    console.log('WebSocket MQTT 连接成功');
    client.subscribe('sensor/#', { qos: 1 }, (err) => {
      if (!err) console.log('订阅成功');
    });
  });

  client.on('message', (topic, message) => {
    const data = JSON.parse(message.toString());
    console.log(`[${topic}]`, data);
    // 更新网页上的实时数据仪表盘
  });
</script>

---

12. 安全最佳实践

12.1 三层防护体系

┌─────────────────────────────────────────┐
│             应用层（ACL 权限控制）         │
│   "谁" 能对 "哪个主题" 执行 "什么操作"     │
├─────────────────────────────────────────┤
│             传输层（身份认证）              │
│    用户名/密码、JWT Token、X.509 证书      │
├─────────────────────────────────────────┤
│             网络层（TLS 加密）             │
│    数据传输加密，防止窃听与篡改             │
└─────────────────────────────────────────┘

12.2 各层级配置要点

层级	方案	安全性	复杂度	适用场景
TLS 加密	单向 TLS	中	低	大多数项目
	双向 TLS (mTLS)	高	高	金融、工业控制
身份认证	用户名/密码	低	低	开发测试、个人项目
	JWT Token	中	中	与企业认证系统集成
	X.509 证书	高	高	设备出厂预置证书
权限控制	主题级 ACL	中	中	生产环境必备

12.3 个人项目推荐方案

对于个人或小团队项目，性价比最高的组合是 “用户名/密码 + TLS 加密 + 主题级 ACL”：

• TLS：用 Let’s Encrypt 免费证书，零成本加密
• 认证：EMQX 内置数据库管理用户，足够 1000 台以内设备
• ACL：限制每个设备只能发布自己的数据主题，订阅自己的命令主题

---

13. 协议对比：MQTT vs HTTP vs CoAP vs AMQP

特性	MQTT	HTTP	CoAP	AMQP
通信模型	发布/订阅	请求/响应	请求/响应（类 REST）	队列/发布订阅
底层协议	TCP	TCP	UDP	TCP
消息大小	最小 2 字节	数百字节+	最小 4 字节	较大（含头部）
推送能力	✅ 原生支持	❌ 需轮询/SSE/WebSocket	✅ 支持	✅ 支持
QoS 级别	3 级	无	2 级	丰富
适用场景	物联网设备通信	Web API	低功耗 IoT	企业消息中间件
功耗	低	高	极低	中

选择建议：

• 物联网设备 ↔ 云端：首选 MQTT
• Web 前端 ↔ 云端 API：HTTP / WebSocket
• 超低功耗传感器网络：CoAP
• 企业内部微服务通信：AMQP（如 RabbitMQ）

---

14. 学习路线图

第一步：理解核心概念（本文）

•  发布/订阅模型
•  四大角色（Broker / Publisher / Subscriber / Topic）
•  三大 QoS
•  遗嘱消息、保留消息、心跳保活

第二步：动手实践

1. 在本地或云服务器上部署 EMQX → 参考 EMQX 详细安装指南
2. 使用 MQTTX 桌面客户端进行收发测试
3. 用命令行工具 mosquitto_pub / mosquitto_sub 验证环境

第三步：编程实践

Python 示例（paho-mqtt）：

python

import paho.mqtt.client as mqtt
import json

# 回调：连接成功
def on_connect(client, userdata, flags, rc):
    print(f"Connected with result code {rc}")
    client.subscribe("sensor/#", qos=1)

# 回调：收到消息
def on_message(client, userdata, msg):
    data = json.loads(msg.payload.decode())
    print(f"[{msg.topic}] {data}")

client = mqtt.Client(client_id="py_subscriber_001")
client.on_connect = on_connect
client.on_message = on_message

client.username_pw_set("your_username", "your_password")
client.connect("broker.example.com", 1883, keepalive=60)

# 阻塞循环，持续监听
client.loop_forever()

第四步：进阶

• 学习 MQTT 5.0 新特性 → MQTT 5.0 详细介绍
• 了解 EMQX 规则引擎（数据桥接到 MySQL / Kafka / InfluxDB）
• 探索集群部署与高可用方案

推荐资源

资源	说明
EMQ 官方博客	最系统的中文 MQTT 教程
MQTT 5.0 规范	协议标准文档
《MQTT 协议入门》	适合零基础入门
《物联网系统开发：从0到1构建IoT平台》	理论与实践结合
MQTTX	免费跨平台 MQTT 客户端工具

---

总结：MQTT 的精髓在于”简单高效”。掌握发布/订阅模型、QoS 选型、会话管理和安全防护这四个支柱后，你就具备了构建可靠物联网通信系统的核心能力。剩下的，就是在实践中不断深化理解。

下一步实践：参考 MQTT 数据获取与调试实战，开始接收你的第一份 MQTT 数据。