物联网通信心脏：MQTT 协议深度剖析

在 HTTP 统治互联网的年代，为什么我们还需要 MQTT？因为 HTTP 太重了。对于一个只有几 KB 内存、靠电池供电的温度传感器来说，每次都要握手、发送庞大的 HTTP Header 是无法承受之重。

MQTT (Message Queuing Telemetry Transport) 是为低带宽、高延迟网络设计的轻量级发布/订阅协议。

1. 发布/订阅 (Pub/Sub) 模型

传统的 C/S 架构是客户端直接找服务器要数据。而 MQTT 引入了中间人：**Broker (代理)**。

• **Publisher (发布者)**：只管往某个主题 (Topic) 发送消息，不关心谁在听。
• **Subscriber (订阅者)**：只管告诉 Broker 我对哪个 Topic 感兴趣。
• Broker：负责从发布者接收消息，转发给所有匹配的订阅者。

这种解耦使得设备之间不需要知道对方的 IP 地址，也不需要同时在线。

2. 三种服务质量 (QoS)

如何确保消息不丢失？MQTT 提供了三个等级：

• **QoS 0 (At most once)**：最多发一次。“发完即忘”。
  • 应用：传感器数据上报（丢一两个包无所谓）。
• **QoS 1 (At least once)**：至少发一次。Broker 收到后必须回 PUBACK，否则客户端会重发。
  • 后果：可能会收到重复消息，应用层需去重。
  • 应用：关键告警。
• **QoS 2 (Exactly once)**：恰好一次。只有一次，即使网络极差。
  • 机制：四次握手 (PUBLISH, PUBREC, PUBREL, PUBCOMP)。开销最大。
  • 应用：支付交易。

3. 遗嘱机制 (LWT, Last Will and Testament)

在 IoT 场景中，设备可能会因为断电、断网而非正常下线。此时，手机 APP 怎么知道设备掉线了？

机制：

1. 设备连接 Broker 时，预先存一份“遗嘱”消息（如 “Status: Offline”）。
2. 如果设备正常断开 (DISCONNECT)，Broker 删除这份遗嘱。
3. 如果设备心跳超时 (Keep-alive timeout)，Broker 认为设备意外掉线，自动将“遗嘱”消息发布到指定 Topic。

4. 保留消息 (Retained Message)

发布者发布消息时，可以置位 Retain 标志。
Broker 会保存该 Topic 下最后一条 Retain 消息。当有新的订阅者加入时，它会立刻收到这条消息。

• 场景：智能灯泡状态。APP 上线时，不需要等灯泡下次心跳，立刻就能知道当前是开还是关。

总结

MQTT 的精髓在于“轻”与“连”。轻到可以在 8 位单片机上跑，连（Keep-alive）则保证了设备的实时可达性。