MQTT 总览与工作原理

MQTT：轻量级发布/订阅消息传输协议
跑在 TCP/IP（或其它有序、无损、双向连接）之上
设计目标：小代码体积、低带宽、弱网友好（IoT / M2M）

权威摘要来自 OASIS MQTT 5.0 规范引言：
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html

---

1. MQTT 是什么

MQTT 是 Client–Server 架构下的 发布/订阅（Pub/Sub） 协议：

• Client：连接 Broker，可 Publish、可 Subscribe
• Server（Broker）：接收发布、按订阅关系转发

属性	值
标准组织	OASIS MQTT TC
现行标准	MQTT 5.0（OASIS Standard, 2019-03-07）
广泛兼容版	MQTT 3.1.1（亦为 ISO/IEC 20922）
历史版	MQTT 3.1
传输	通常 TCP；也可 WebSocket；MQTT-SN 面向非 TCP
默认端口	1883（明文）/ 8883（TLS）
载荷	对内容无关（JSON/Protobuf/二进制均可）

规范列表：mqtt.org — Specifications

---

2. 核心交互模型

Publisher                Broker                 Subscriber
    │                      │                        │
    │──── CONNECT ────────▶│◀────── CONNECT ────────│
    │◀─── CONNACK ─────────│─────── CONNACK ───────▶│
    │                      │◀────── SUBSCRIBE ──────│
    │                      │─────── SUBACK ────────▶│
    │──── PUBLISH ────────▶│───── PUBLISH ─────────▶│
    │                      │                        │

特点：

• 发布者不需要知道订阅者是谁（解耦）
• 一对多自然支持（同主题多订阅）
• 应用只关心 Topic + Payload + QoS

---

3. 为什么用 MQTT（而不是裸 TCP / HTTP）

需求	MQTT 如何满足
设备多、连接弱	固定头部很小；Keep Alive / 会话恢复
一对多分发	Broker 按 Topic 扇出
投递可靠性可选	QoS 0/1/2
异常下线通知	Last Will and Testament
后上线也能拿到状态	Retain 消息
跨语言	各语言客户端库丰富

不适合的场景（需另选）：

• 硬实时微秒级控制环（更像 EtherCAT / 实时 DDS）
• 需要强类型接口契约与发现（ROS 2 DDS / IDL 更合适）
• 超大文件传输（用对象存储 + 通知更合适）

---

4. 与常见中间件对比（机器人语境）

	MQTT	ROS 2 DDS	HTTP/REST
模型	Pub/Sub + Broker	Pub/Sub（去中心或 discovery）	请求/响应
中心节点	通常需要 Broker	通常无单一 Broker	服务端
典型用途	云边、设备遥测、跨网段	机器人内部实时通信	配置/API
QoS	0/1/2	DDS QoS（更丰富）	应用层自建
发现	约定 Topic	DDS Discovery	URL

工程上常见分层：

机器人内部：ROS 2 / DDS / 实时总线
    ↕ 桥接（mqtt_client 等）
厂区/云端：MQTT Broker

---

5. 版本怎么选

版本	建议
3.1.1	兼容面最大；存量设备首选
5.0	新项目优先：Reason Code、用户属性、共享订阅、主题别名、更好的错误报告与流控
3.1	仅遗留

MQTT 5 细节见 04-MQTT5新特性.md。

---

6. 最小心智模型

1. Client 连上 Broker（CONNECT）
2. 订阅感兴趣的 Topic（SUBSCRIBE）
3. 向某 Topic 发消息（PUBLISH）
4. Broker 转发给匹配的订阅者
5. 用 QoS / Retain / Will 补齐可靠性与运维语义

下一篇：01-主题与发布订阅模型.md