2. IoT设备接入与消息协议选型
在IoT系统中，设备接入协议决定了设备与云平台之间“怎么说话”。选错协议，轻则功耗超标、流量浪费，重则连接不稳定、消息丢失、运维成本失控。本节围绕MQTT、CoAP、HTTP、AMQP四种主流协议，从传输模型、消息模式、开销特征和工程约束出发，给出可落地的选型判断方法。
一、四种协议的本质差异
理解协议选型，先要抓住三个维度：传输层依赖、通信模式、消息语义。
- MQTT：基于TCP，采用发布/订阅模型，通过Broker解耦设备与应用。支持QoS 0/1/2、遗嘱消息、保留消息，适合长连接、低带宽、双向通信场景。
- CoAP：基于UDP，采用请求/响应模型，类HTTP语义但二进制编码，支持Confirmable/Non-confirmable消息、观察模式（Observe）。适合受限设备、低功耗、短报文场景。
- HTTP：基于TCP，请求/响应模型，文本头开销大，无服务端主动推送（需轮询或长轮询）。适合设备主动上报、固件下载、配置拉取等非实时场景。
- AMQP：基于TCP，支持消息队列、路由、事务、确认机制，语义最丰富但实现最重。适合平台内部服务间可靠消息传递，而非海量终端直连。
一个常见的工程误区是“用HTTP做设备实时控制”。HTTP每次请求都要建立或复用TCP连接，头部动辄几百字节，且服务端无法主动下发指令。若1000台设备以10秒间隔轮询，仅头部流量就可能达到数十MB/天，且控制延迟受轮询周期限制。
二、关键工程参数对比
选型不能只看“协议特性”，还要看实际运行中的量化指标。下表给出典型参考值，实际数值受网络环境、报文大小、实现库影响，应视为量级参考而非精确承诺。
| 维度 | MQTT | CoAP | HTTP | AMQP |
|---|---|---|---|---|
| 传输层 | TCP | UDP | TCP | TCP |
| 最小报文头 | 2字节 | 4字节 | 数百字节 | 8字节+帧头 |
| 通信模式 | 发布/订阅 | 请求/响应+Observe | 请求/响应 | 队列/路由 |
| 服务端推送 | 支持 | Observe支持 | 不支持 | 支持 |
| 典型功耗 | 中（长连接） | 低（可休眠） | 高（频繁建连） | 高（长连接+重协议） |
| 适用终端规模 | 万~百万级 | 万~十万级 | 百~千级 | 平台内部服务 |
三、选型决策路径
面对具体项目，可按以下顺序判断：
- 设备是否极度受限（MCU内存<64KB、电池供电、NB-IoT/ LoRa等窄带）？若是，优先CoAP；若还需服务端主动下发，用CoAP Observe或经网关转MQTT。
- 是否需要服务端主动控制设备？若是，排除纯HTTP，选MQTT或CoAP Observe。
- 设备数量是否超过千级？若是，HTTP轮询的流量和连接压力会迅速放大，应选MQTT。
- 是否在平台内部做可靠消息路由（如订单、告警、计费）？若是，AMQP更合适，但不应让海量终端直连AMQP Broker。
- 是否只是设备主动上报、对实时性要求低？HTTP最简单，适合原型验证或低频采集。
工程经验：大量实际项目采用“边缘网关+协议转换”的混合架构——终端用CoAP或Modbus，网关转MQTT上云；平台内部再用AMQP做服务解耦。不要试图用一种协议覆盖所有环节。
四、一个可执行的选型示例
假设某智慧农业项目：2000个土壤墒情传感器，每5分钟上报一次温湿度，电池供电，需要支持远程下发采样周期。按上述路径判断：
- 设备受限、电池供电 → CoAP候选；
- 需要远程下发 → CoAP Observe或MQTT；
- 2000台规模，MQTT Broker可轻松承载；
- 最终选择：MQTT over TCP，QoS 1，KeepAlive 300秒，遗嘱消息上报离线状态。
若改为“设备通过NB-IoT上报，每天仅上报4次，不需要远程控制”，则CoAP更优：UDP无连接、可休眠、报文头仅4字节，单次上报流量可控制在50字节以内，电池寿命显著优于MQTT长连接。
常见陷阱：MQTT的QoS 2虽然保证“恰好一次”，但握手开销大，在弱网下反而容易阻塞。多数IoT场景QoS 1（至少一次）+ 应用层幂等去重即可，不要盲目追求QoS 2。
五、选型检查清单
在最终确定协议前，逐项确认：
- 设备侧是否有成熟的协议栈和内存余量？
- 网络是否稳定？UDP丢包率是否可接受？
- 是否需要双向通信？下行指令的实时性要求是多少？
- 消息可靠性要求：允许丢失、至少一次、还是恰好一次？
- 平台侧Broker/网关的并发连接数和吞吐是否匹配设备规模？
- 安全方案：TLS/DTLS、证书管理、设备认证方式是否可落地？
- 运维可观测性：是否支持连接状态、消息轨迹、离线告警？
协议选型没有绝对优劣，只有与场景匹配与否。把设备能力、网络条件、业务实时性、平台规模和运维成本放在一起权衡，才能选出真正可长期运行的接入方案。