讲师博文
1. 引言
随着物联网技术的发展，大量嵌入式设备需要连接云端，实现设备状态上报、远程控制以及数据采集。
传统网络通信方式，例如 HTTP 协议，虽然应用广泛，但是在物联网场景中存在一定局限：
设备数量巨大，连接数量多
传感器数据量小，但发送频率高
嵌入式设备资源有限
网络环境可能不稳定
例如：
一个温湿度传感器，每隔5秒上传一次数据：
{
"temperature":25,
"humidity":60
}
如果采用 HTTP：
设备
|
| HTTP POST
|
服务器
每次通信都需要：
建立TCP连接
HTTP请求头
HTTP响应
大量无效协议开销会消耗设备资源。
因此，物联网领域提出了一种更加轻量化的通信协议：
MQTT(Message Queuing Telemetry Transport)。
MQTT是一种基于发布/订阅模型的轻量级消息传输协议，被广泛应用于物联网设备、工业控制、智能家居等场景。MQTT协议由OASIS维护，目前最新规范包括MQTT 5.0版本。
2. MQTT整体架构
MQTT系统主要包含三个角色：
MQTT Broker
|
-------------------
| |
Device A Device B
Publisher Subscriber
分别是：
2.1 MQTT客户端(Client)
客户端可以是：
STM32
ESP32
Linux设备
手机APP
Web应用
客户端可以：
发布消息(Publish)
订阅消息(Subscribe)
例如：
STM32采集温度：
STM32
|
| Publish
|
temperature/device001
手机控制设备：
手机APP
|
| Publish
|
fan/device001/control
2.2 MQTT服务器(Broker)
Broker是MQTT系统核心。
它负责：
接收客户端消息
根据Topic转发消息
管理客户端连接
保存离线消息
常见Broker：
Mosquitto
EMQX
HiveMQ
例如：
设备发送：
topic:
home/device001/temp
payload:
25℃
Broker收到后：
查找：
谁订阅了
home/device001/temp
然后发送给对应客户端。
3. MQTT核心机制：发布/订阅模型
传统TCP通信：
客户端A
|
|
服务器
|
|
客户端B
双方必须知道对方IP。
但是MQTT：
Broker
/ | \
设备1 手机 Web网页
设备之间不直接通信。
而是通过Topic进行消息匹配。
3.1 Topic主题
Topic类似一个消息地址。
例如智能家居：
home/device001/light/state
home/device001/light/control
home/device001/temp
设备上传：
Topic:
home/device001/temp
Payload:
{
"temp":26
}
控制灯：
APP发布：
Topic:
home/device001/light/control
Payload:
{
"state":1
}
设备订阅：
home/device001/light/control
收到消息：
执行：
GPIO_Set(LED_PIN,1);
4. MQTT通信流程
一个完整MQTT通信过程如下：
第一步：建立连接
客户端发送：
CONNECT
包含：
Client ID
用户名
密码
Keep Alive时间
Broker回复：
CONNACK
连接成功。
第二步：订阅Topic
设备：
SUBSCRIBE
home/device001/control
Broker：
SUBACK
之后设备等待控制命令。
第三步：发布数据
设备采集：
temperature=30℃
发送：
PUBLISH
Topic:
home/device001/temp
Payload:
30
Broker转发给订阅者。
5. MQTT的重要特性
5.1 QoS服务质量
MQTT提供三种消息可靠等级。
QoS 0
最多一次：
发送 ---->
特点：
速度最快
不保证成功
资源消耗最小
适合：
实时环境数据，GPS位置更新。因为下一秒就有新数据，丢一两个旧数据点无所谓，但必须保证速度。
例如：
摄像头状态：
online
offline
QoS 1
至少一次：
发送
|
PUBACK
如果没有收到确认：
重新发送。
特点：
这是最常用的等级，保证了消息一定能送到，但允许出现重复，由于重发机制，接收方可能会收到多条重复的消息（比如接收方其实收到了，只是确认包在路上丢了，发送方就会再发一次）。
适合：
需要确保收到，但重复影响不大的指令或通知，比如“远程开锁”、“打开风扇”。即使开锁指令被重复执行两次，通常也能接受。
QoS 2
只有一次：
通过多次握手保证：
PUBLISH
PUBREC
PUBREL
PUBCOMP
这是最高等级，确保消息既不会丢，也绝对不会重复。但代价最大，流程最复杂。
适合：
关键资金交易、计费扣款、精准控制命令。比如“关闭燃气阀门”，如果重复一次就可能引发危险，所以必须确保恰好一次。。
6. Retain保留消息
MQTT还有一个重要机制：
Retained Message。
例如：
设备上线发送：
Topic:
device001/status
Payload:
online
retain=1
之后新的客户端订阅：
device001/status
Broker立即返回：
online
因此APP打开时，可以立即知道设备状态。
7. Keep Alive心跳机制
物联网设备可能长期连接。
但是：
WiFi可能断开
4G信号可能丢失
因此MQTT提供Keep Alive。
例如：
设置：
Keep Alive = 60s
设备60秒内没有发送数据：
发送：
PINGREQ
Broker回复：
PINGRESP
用于检测连接状态。
8. MQTT在物联网系统中的典型架构
实际物联网系统：
云平台
MQTT Broker
|
-------------------------
| | |
STM32 ESP32 Linux网关
传感器 控制器 边缘计算
例如智能家居：
数据上传
温湿度传感器：
STM32
读取:
temp=25
MQTT Publish
home/temp
云端保存数据。
云端控制设备
手机：
点击打开风扇
发送：
Topic:
home/fan/control
Payload:
{
speed:3
}
Broker转发：
STM32
收到消息
PWM调整
9. MQTT与OneNET平台的关系
很多物联网平台，例如：
OneNET
阿里云IoT
腾讯云IoT
AWS IoT
底层通信实际上大量采用MQTT。
以OneNET为例：
设备接入流程：
STM32
|
MQTT协议
|
OneNET MQTT服务器
|
云端应用
但是实际开发中：
平台通常提供SDK。
例如：
OneNET_Send_Property();
开发者调用：
应用接口
↓
SDK封装
↓
MQTT PUBLISH
↓
Broker
因此：
OneNET SDK降低了MQTT使用难度，但是隐藏了MQTT底层通信过程。
如果想深入理解物联网系统，应该掌握：
TCP/IP
↓
MQTT协议
↓
MQTT Client库
↓
物联网平台SDK
↓
业务应用
10. MQTT优势与不足
优势
1. 协议轻量
消息头小，适合资源受限设备。
2. 解耦通信
设备不用知道服务器地址。
只需要关注Topic。
3. 支持大量设备
Broker统一管理连接。
4. 支持弱网络环境
QoS、Keep Alive、离线消息机制提高可靠性。
不足
1. 依赖Broker
Broker成为核心节点。
2. 安全需要额外设计
通常需要：
TLS
用户认证
Topic权限控制
3. 不适合大文件传输
例如：
视频、固件升级文件通常使用HTTP。
11. 总结
MQTT并不是一个完整的物联网平台，而是一种设备通信协议。
物联网系统关系：
硬件设备
↓
MQTT协议
↓
MQTT Broker
↓
云平台
↓
APP/Web应用
对于嵌入式工程师而言：
学习物联网不能只停留在调用平台SDK。
理解MQTT底层机制，包括：
Client/Broker模型
Publish/Subscribe
Topic设计
QoS机制
Retain消息
心跳保持
才能真正理解设备如何连接云端。
而OneNET、阿里云等平台，本质上是在MQTT协议基础上，为开发者提供了设备管理、数据存储、可视化等高级能力。
扫码申领本地嵌入式教学实录全套视频及配套源码
