从物理层到应用层，系统讲解 IoT 设备如何与服务端保持稳定、可靠的双向通信
IoT 通信是一个分层系统：设备通过 传输层 连接到网络， 通过 协议层 与服务端交换消息， 最终由 应用层 处理业务逻辑。
IoT 领域有众多协议，不同协议适用于不同场景。以下是最常用的五种协议对比：
| 协议 | 传输层 | 拓扑模型 | QoS 等级 | 典型场景 |
|---|---|---|---|---|
| MQTT | TCP | 发布/订阅 | 0 / 1 / 2 | 设备上报、远程控制、遥测 |
| CoAP | UDP | 请求/响应（RESTful） | Confirmable / Non-confirmable | 受限设备、低功耗传感器 |
| HTTP/HTTPS | TCP | 请求/响应 | 无（依赖 TCP） | 固件升级、配置管理 |
| WebSocket | TCP（HTTP 升级） | 全双工长连接 | 无（依赖 TCP） | 实时控制面板、即时推送 |
| LwM2M | UDP（基于 CoAP） | 资源模型（对象/实例） | Confirmable / Non-confirmable | 蜂窝 IoT（NB-IoT / LTE-M） |
MQTT（Message Queuing Telemetry Transport）是 IoT 领域 使用最广泛 的协议， 专为高延迟、低带宽、不稳定网络设计。
| QoS 等级 | 含义 | 握手次数 | 适用场景 |
|---|---|---|---|
| QoS 0 — 至多一次 | 消息最多投递一次，不确认，不重传 | 0 次（fire and forget） | 温度上报等允许少量丢失的场景 |
| QoS 1 — 至少一次 | 消息至少到达一次，可能重复 | 1 次（PUBACK 确认） | 设备控制指令（可接受去重） |
| QoS 2 — 恰好一次 | 消息确保只到达一次，无丢失无重复 | 4 次握手（PUBREC/PUBREL/PUBCOMP） | 计费/交易等关键数据 |
MQTT 客户端在 CONNECT 时携带 Keep Alive 时间（秒），
若在此时间内没有消息发送，必须发送一个 PINGREQ 报文，
服务端回复 PINGRESP。若超时未收到，双方均认为连接已断开。
设备 --PINGREQ--> Broker 设备 <--PINGRESP-- Broker （保活正常） // 若超时 1.5 x KeepAlive 未收到任何报文 // 服务端判定设备离线，触发 LWT（遗言）消息
设备在连接时预先在 Broker 注册一条"遗言"消息。 当设备 异常断开（非发送 DISCONNECT）时，Broker 自动发布该消息到指定 Topic， 通知其他客户端该设备已离线。
物联网设备往往运行在 不稳定网络（移动网络、弱 WiFi）环境中， 如何保持连接、检测断线、自动重连是整个系统稳定性的关键。
// 伪代码：指数退避重连算法
attempt = 0
max_attempts = 10
base_delay = 1 // 秒
while not connected and attempt < max_attempts:
delay = min(base_delay * 2^attempt, 60) // 指数增长，上限 60s
delay += random(0, delay * 0.3) // 随机抖动，避免惊群
sleep(delay)
attempt += 1
try_connect()
IoT 设备暴露在物理空间和公共网络中，安全设计必须贯穿通信全过程。
| 层级 | 技术手段 | 作用 |
|---|---|---|
| 传输层 | TLS 1.2+ / DTLS 1.2+ | 加密链路，防止窃听和中间人攻击 |
| 认证层 | 设备证书（X.509）/ Token / AK/SK | 验证设备身份，防止伪造设备接入 |
| 授权层 | ACL / Topic 权限 / 设备影子隔离 | 控制设备只能访问授权资源 |
| 数据层 | Payload 加密（AES-128+/ChaCha20） | 即使传输层被破解，数据仍无法解读 |
以"温度传感器上报数据 - 服务端处理 - 触发告警推送"为例，梳理完整的数据流：
CoAP（Constrained Application Protocol）运行在 UDP 之上， 报文头部仅 4 字节，专为电池供电、计算能力极弱的传感器设计。
| 维度 | CoAP | MQTT |
|---|---|---|
| 传输层 | UDP（无连接） | TCP（面向连接） |
| 报文开销 | 极简（4 字节头） | 较大（固定 2 字节 + 可变头） |
| 可靠性 | 应用层 Confirmable 重传 | TCP 内置可靠传输 |
| 适合设备 | 8-bit MCU、休眠传感器 | 32-bit MCU、持续在线设备 |
| 通信模式 | 请求/响应（类 HTTP） | 发布/订阅（事件驱动） |
| 观察模式 | 内置 OBSERVE（服务器推） | 需持久连接 + 订阅 |
CoAP 支持服务器在资源变化时 主动推送 给客户端（类似 MQTT 的订阅）， 但无需维持长连接，极度节省功耗。
客户端 GET /temp (Observe: 0) --> 服务端 客户端 <-- 2.05 Content (Observe: 1) 服务端 // 首次响应 ... 温度发生变化 ... 客户端 <-- 2.05 Content (Observe: 2) 服务端 // 主动推送 客户端 <-- 2.05 Content (Observe: 3) 服务端 // 再次推送
没有"最好"的协议，只有"最合适"的协议。根据场景特征做权衡：
| 场景特征 | 推荐协议 | 理由 |
|---|---|---|
| 设备持续供电、网络稳定 | MQTT | 简单成熟，生态完善，QoS 灵活 |
| 电池供电、偶尔唤醒 | CoAP | UDP 无连接，报文极小，Observe 推送到服务端 |
| 需浏览器直接访问（Web 面板） | WebSocket | 浏览器原生支持，全双工，低延迟 |
| 固件升级（大文件传输） | HTTP/HTTPS | 有分块传输、校验和 CDN 加速支持 |
| NB-IoT / LTE-M 蜂窝网络 | LwM2M | 专为蜂窝 IoT 优化，IPSO 对象模型标准化 |
| 局域网设备互联（无云端） | Zigbee / BLE / Thread | 短距离、低功耗、无需公网 |