MQTT（消息队列遥测传输）

MQTT （Message Queuing Telemetry Transport，消息队列遥测传输协议）是一种轻量级、基于发布/订阅模式 的消息传输协议，专为受限设备、低带宽、高延迟、不稳定网络的物联网通信设计的。

MQTT 诞生于1999年，目的是用最小的网络带宽和代码量，将石油管道上的传感器数据传回控制中心。2014年，MQTT正式成为OASIS标准 ，2016年升级为ISO/IEC 国际标准。

核心定位

1. 设计目标：极简、开销小、省电、可靠
2. 运行在 TCP/IP 之上（也可跑在 UDP：MQTT-SN）
3. 不是消息队列（MQ），而是消息传输协议
4. 物联网 / IoT 事实上的标准协议

核心特点

1. 轻量高效 ：协议头最小仅为 2字节，远低于HTTP等文本协议，非常适合低带宽、高延迟或不稳定的网络。

2. 发布/订阅模式 ：发送者（发布者）和接收者（订阅者）通过一个中间人（代理Broker）沟通，彼此不需要知道对方的存在，实现了空间、时间、同步上的完全解耦。

3. 三种服务质量（QoS）：

   • QoS 0（至多一次）：发送即忘，消息可能丢失。适用于不重要的数据。

   • QoS 1（至少一次）：保证送达，但可能重复。

   • QoS 2（恰好一次）：通过复杂的握手保证消息不重不漏。最可靠，但开销最大。

4. 最后遗嘱：当设备异常断线时，Broker可以自动向所有订阅者发送一条预设的"遗嘱消息"，告知大家该设备已掉线。

5. 持久会话：客户端断线重连后，Broker会记住该客户端的订阅关系，并补发离线期间错过的消息（需配合QoS 1或2）。

工作原理

• Broker（代理服务器）：是整个系统的核心，负责接收所有消息，并根据主题进行过滤和分发。

• Publisher（发布者） ：发送消息到Broker上的某个主题 （如 home/livingroom/temperature）。

• Subscriber（订阅者） ：向Broker订阅自己关心的主题 （可使用通配符如 home/+/temperature 订阅所有房间的温度）。

• 消息：包含主题和负载（Payload，即实际数据，格式透明，可以是JSON、二进制等）。

流程示例：

1. 手机App订阅主题 alert/fire。

2. 烟雾传感器检测到火情，发布一条消息到 alert/fire，负载为 { "location": "kitchen" }。

3. Broker收到消息后，立即推送给所有订阅了 alert/fire 的手机App。

典型应用场景

MQTT最广为人知的应用是物联网，但实际上它的应用范围更广：

• 物联网/车联网：传感器数据上报、远程控制智能灯泡/插座、车辆状态追踪。

• 移动应用：即时通讯（如Facebook Messenger早期曾使用）、消息推送。

• 能源行业：石油管道、电网、水表的远程监控。

• 工业自动化：SCADA系统、PLC数据采集。

• 智慧家居：小米、Home Assistant等智能家居平台的核心协议。

常用实现

• Broker：

  • EMQX：企业级开源，支持大规模连接（千万级），性能强悍。

  • Mosquitto：Eclipse基金会项目，轻量简单，适合嵌入式或个人测试。

  • VerneMQ 、HiveMQ 、NanoMQ（面向边缘计算）。

• 客户端库 ：几乎支持所有主流语言（Python的 paho-mqtt、JavaScript的 mqtt.js、Go的 paho.golang等）。

安全性考量

原生MQTT安全能力较弱，生产环境通常需要叠加安全措施：

• 传输加密 ：使用 TLS/SSL（即MQTT over TLS，通常端口8883）替代明文的1883端口。

• 身份认证：用户名/密码、JWT Token、或通过TLS客户端证书进行认证。

• 授权：通过插件或规则限制客户端对特定主题的发布/订阅权限。

• 安全建议：不要使用默认配置，禁用匿名访问，定期更新Broker版本。

与HTTP的对比

维度	MQTT	HTTP
协议模型	发布/订阅（异步）	请求/响应（同步）
消息头大小	最小2字节	通常几百字节
通信方向	双向（Broker可主动推）	单向（客户端必须请求）
服务质量	内置3个等级	依赖底层TCP（相当于QoS 0）
典型场景	IoT、实时推送	网页浏览、REST API