物联网通信基础：从设备到平台的连接之道
一、物联网的四层架构
物联网系统虽然形态各异，但从数据流动的角度看，几乎所有方案都可以归纳为四层架构。理解这四层，是后续学习 MQTT 协议的前提，因为 MQTT 正是为打通其中“感知层—网络层—平台层”的数据通道而设计的。
感知层负责采集物理世界的数据，网络层解决“数据怎么传”的问题，平台层处理“数据存哪里、怎么用”，应用层面向最终用户提供交互界面。MQTT 协议运行在 TCP/IP 之上，因此它既可以部署在 Wi-Fi 或 4G 网络，也可以跑在以太网中，是感知层与平台层之间最常见的通信协议之一。
二、三大物联网通信协议对比
HTTP、CoAP、MQTT 是物联网领域最常被提及的三种应用层协议。它们的设计目标不同，适用场景也截然不同。下面从连接模型、消息模式、开销和可靠性四个维度进行对比。
| 对比维度 | HTTP | CoAP | MQTT |
|---|---|---|---|
| 传输层 | TCP（可靠） | UDP（不可靠，需重传机制） | TCP（可靠） |
| 通信模型 | 请求/响应（客户端主动） | 请求/响应 + 观察（Observe） | 发布/订阅（Broker 中转） |
| 消息开销 | 头部大（数百字节） | 头部小（4 字节基础头） | 头部小（2 字节固定头） |
| 实时性 | 轮询延迟高 | 较好（UDP 低延迟） | 极好（服务端推送） |
| 典型场景 | 设备配置、固件下载 | 资源受限的传感器节点 | 遥测上报、指令下发、消息广播 |
HTTP 是“一问一答”模式，客户端必须主动发起请求才能获取数据，服务器无法主动推送。CoAP 虽然针对低功耗设备做了优化，但它基于 UDP，在 NAT 穿透和企业防火墙场景下会遇到麻烦。MQTT 则通过 Broker 中转实现了“发布/订阅”解耦，服务器可以主动将消息推送给订阅者，天然适合设备状态频繁变化的物联网场景。
三、MQTT 的设计理念与核心优势
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）诞生于 1999 年，最初用于石油管道卫星通信。它的设计目标非常明确：在带宽有限、网络不稳定、设备计算能力弱的环境下，提供一种轻量、可靠、双向的消息传输机制。
核心设计理念：
- 发布/订阅解耦：发送者不关心谁在接收，接收者不关心消息来自哪里，双方只需通过主题（Topic）建立逻辑连接。
- 以 Broker 为中心：所有消息经由 Broker 路由，Broker 负责会话状态、消息存储和转发策略。
- 网络开销极小：固定头仅 2 字节，适合 NB-IoT、2G 等窄带网络。
- QoS 分级保障：提供 0/1/2 三档服务质量，用户可在“效率”和“可靠”之间做取舍。
- 遗嘱消息（Last Will）：设备异常离线时，Broker 可代发预设的遗嘱，让平台及时感知设备失联。
MQTT 的发布/订阅模型可以用一个简单的例子来理解：温度传感器每隔 5 秒向主题 sensors/room1/temperature 发布一次数据；手机 App 订阅了该主题，就能实时收到温度更新。整个过程传感器不需要知道 App 的 IP 地址，App 也不需要轮询传感器，双方通过 Broker 完成了解耦。
# 发布端（传感器）
mosquitto_pub -h broker.emqx.io -t sensors/room1/temperature -m '{"value": 25.6, "unit": "℃"}' -q 1
# 订阅端（手机 App）
mosquitto_sub -h broker.emqx.io -t sensors/room1/temperature -q 1MQTT 的 QoS 机制是它区别于其他协议的重要特性。QoS 0 是“尽力而为”，消息可能丢失；QoS 1 保证“至少一次”，但可能重复；QoS 2 保证“恰好一次”，代价是多次握手。在实际项目中，遥测数据通常用 QoS 0 或 QoS 1，而控制指令（如“打开阀门”）建议用 QoS 1 或 QoS 2，避免因消息丢失造成安全事故。
四、典型应用场景：智能工厂设备监控
假设一个工厂需要监控 200 台注塑机的运行状态，每台设备每秒上报一次温度、压力和振动数据，同时需要接收中控室下发的启停指令。如果使用 HTTP 轮询，200 台设备 × 每秒 1 次请求，中控服务器每秒要处理 200 个 HTTP 请求，且设备无法主动感知指令变化。改用 MQTT 后，每台设备只需维持一个 TCP 长连接，通过主题区分设备类型和功能：
factory/machine/001/telemetry—— 设备 001 的上行遥测数据factory/machine/001/command—— 设备 001 的下行控制指令factory/alarm/all—— 全厂告警广播
中控室订阅所有设备的 telemetry 主题，即可实时获取全部数据；需要控制某台设备时，只需向对应 command 主题发布指令。整个系统消息路由清晰，新增设备时无需修改服务器代码，只需让新设备连接到 Broker 并发布/订阅相应主题即可。
选型建议：如果设备需要“服务器主动推送”或“设备间消息转发”，优先选择 MQTT；如果只是设备偶尔上报一次数据且能容忍轮询延迟，HTTP 也能胜任；CoAP 更适合电池供电、深度睡眠的传感器节点，但需要自行处理 NAT 穿透问题。
五、常见误区与复盘
误区一：认为 MQTT 一定比 HTTP 快。实际上，MQTT 的实时性优势来自“服务端推送”而非传输速度。在局域网内，HTTP 的响应速度可能并不慢，但 HTTP 需要客户端频繁轮询才能达到类似效果，浪费带宽和电量。
误区二：把所有消息都设为 QoS 2。QoS 2 的握手流程复杂，会显著增加网络流量和 Broker 负载。对于温度、湿度等周期性遥测数据，丢失一帧影响不大，QoS 0 或 QoS 1 足够；只有资金交易、设备启停等关键指令才需要 QoS 2。
误区三：忽略遗嘱消息的重要性。很多初学者只关注正常消息收发，却忽略了设备异常掉线时的处理。没有遗嘱消息，平台可能长时间无法感知设备“已经死了”，导致数据空洞或误判。正确做法是：设备连接时注册遗嘱主题，内容设为“设备离线”，Broker 在连接断开时自动发布该消息。
误区四：主题设计随意。主题是 MQTT 的路由核心，设计不当会导致权限混乱、消息风暴或难以扩展。建议采用“层级化 + 通配符”的方式，例如 工厂/车间/设备编号/数据类型，并利用 +（单层通配）和 #（多层通配）实现灵活订阅。
# 订阅 1 号车间所有设备的所有数据
factory/workshop1/+/+
# 订阅全厂所有告警
factory/+/+/alarm