9.1 物联网应用层协议概览
9.1.1 物联网应用层协议分类
传感器数据从现场到云端，中间经过的每一层协议都在做一件事：定义数据的形状和交换的规则。应用层作为四层架构中最靠近业务的一层，承担着将物理信号转换为业务语义的角色。面对碎片化的设备类型、通信介质和功耗约束，工程师需要在协议选择上做出第一道权衡。
通信模型：两种基本交互模式
物联网应用层协议按通信模型分为请求/响应和发布/订阅两类，两者设计的出发点截然不同。
请求/响应模型（Request/Response）的逻辑与 HTTP（HyperText Transfer Protocol，超文本传输协议）相近：客户端针对资源发起请求，服务端返回响应。CoAP（Constrained Application Protocol，受限应用协议）由 IETF 定义，采用 REST 风格并提供 GET、PUT、POST、DELETE 等方法，但它在 UDP 之上的消息、Token、异步响应、Observe 和可选组播语义与 HTTP 并不相同。轮询大量终端会带来请求扇出与唤醒开销，不过并非每次 CoAP 请求都会发生“完整握手”；安全上下文能否复用、终端是否可达以及是否采用 Observe，才共同决定代价。
发布/订阅模型（Publish/Subscribe）引入 Broker：设备向主题发布，其他设备或服务订阅匹配主题，由 Broker 路由消息。MQTT 是这一模型的典型代表，早期面向窄带、高时延和不稳定链路。它降低了发布者与订阅者的地址和拓扑耦合，但不自动实现时间上的完全解耦。订阅者离线期间是否保留消息，取决于 QoS、持久会话、订阅状态、消息过期和 Broker 存储；发布者也要按所选 QoS 完成相应交换后，才能安全休眠。续航收益必须结合连接保持、无线唤醒和上报周期实测。
两种模型更准确的分界是交互契约：请求/响应围绕资源和一次交换组织，发布/订阅围绕主题和中介分发组织。二者都可异步实现，也都受在线状态、缓存和超时约束。前者常用于按需查询与资源操作，后者常用于持续采集和多消费者分发。
传输层与设备能力：TCP 还是 UDP？
第二个决定协议选择的分岔路口，来自传输层的 TCP（Transmission Control Protocol，传输控制协议）与 UDP（User Datagram Protocol，用户数据报协议）。
MQTT 跑在 TCP 之上，TCP 提供有序字节流、重传和流量控制；应用消息能否在断线后继续交付，还取决于 MQTT QoS、会话状态、客户端标识、消息过期和 Broker 持久化。维持长连接可能产生握手、保活与无线唤醒开销，但它与数据能耗的比例取决于接入网络、Keep Alive 和上报周期，不能脱离测量下结论。MQTT-SN（MQTT for Sensor Networks）采用适配非 TCP 网络的设计，也说明资源受限环境需要重新权衡传输与会话成本。
CoAP 通常以 UDP 为基础。UDP 无连接且不提供交付保证；CoAP 再用 CON（确认消息）和 NON（非确认消息）区分交换方式。CON 在未收到 ACK 或 RST 时按退避策略重传，达到上限后仍会失败；NON 则没有协议层确认与重传。ACK 只确认 CoAP 消息交换，不等于物理动作完成。这样的设计允许系统按消息选择确认成本，但实际时延、能耗与到达率仍需在目标网络中测量。
LwM2M（Lightweight Machine-To-Machine，轻量级 M2M 协议）的定位更特殊。它由 OMA SpecWorks 定义，在 CoAP 等承载绑定之上规定对象/资源模型以及引导、注册、观测、配置和固件更新等设备管理流程。CoAP 负责请求/响应与消息交换，LwM2M 负责设备管理语义；安全与交付属性还取决于所选传输绑定、确认方式和具体实现，不能由“采用 LwM2M”一项直接推出。
分类图谱：一张图看清协议布局
下面的分层图展示了从感知层到应用层的主要协议位置。底层是感知层的传感器与执行器；向上是无线接入技术（Wi-Fi、BLE（Bluetooth Low Energy，低功耗蓝牙）、Zigbee、LoRa、NB-IoT（Narrowband IoT，窄带物联网）、5G）；再往上是传输层（TCP/UDP）；最顶层是应用层协议。在应用层内部，MQTT 归入发布/订阅类，CoAP 和 HTTP 归入请求/响应类，LwM2M 作为 CoAP 上层的一个特殊分支。
基于以上分类，工程师需要做的不是背诵协议参数，而是建立一条选择逻辑：如果传感器只上报、不反控、电池寿命要求三年以上，CoAP（必要时加一层 LwM2M 管理）在能耗上比保持 TCP 长连接的 MQTT 更有优势；如果平台需要双向控制、命令下发，或已经依赖成熟的消息队列基础设施，MQTT 的发布/订阅模型是更稳妥的选择。不存在万能协议——只有最能匹配设备约束与通信需求的那一个。
9.1.2 协议选择影响因素
看清了 MQTT 和 CoAP 在通信模型上的分野，但真正落到工程决策——燃气表一天上报一次读数、智能灯控要求响应在百毫秒级、工厂 PLC 需要对接 OPC UA（OPC Unified Architecture，OPC 统一架构）统一地址空间——选哪个？单看通信模型不够。协议选型本质上是在三个约束维度里找平衡：网络约束（带宽、延迟、可靠性）、设备约束（功耗、内存、算力）、生态约束（标准成熟度、工具链、社区支持）。三者的交点，往往是那个“不是最先进，但最合适”的方案。以下逐一拆解。
网络约束：带宽、延迟与可靠性
先谈带宽。共享单车开锁指令：一次上报只携带状态码和锁标识符，单次通讯数据量通常只有几个字节。CoAP 的数据包开销极低，固定头仅数个字节，跑在 UDP 之上，无握手、无保活。如果换成 HTTP REST 轮询，每次请求都得携带完整的文本头部，对于一条“锁状态 0x01”的消息而言，绝大部分流量是协议开销。当一座城市部署数万辆共享单车时，这笔开销会直接反映在运营成本上。
再谈延迟。智能灯控这类“人在回路中”的场景，用户按下开关到灯光响应，感知延迟需要控制在不可察觉的区间内。MQTT 基于 TCP，三次握手和长连接保活，在稳定的局域网内能满足要求。但若设备通过蜂窝网络接入，经历频繁断线重连时，TCP 的握手与超时重传反而会成为延迟卡顿的来源。CoAP 的 NON（Non-Confirmable，无需确认）消息类型允许设备“发了就不管”，把端到端延迟保障从传输层抽离，交由业务层定义自己的可靠策略。
设备约束：功耗、内存与算力
设想一个要求多年续航的电池供电管道监测终端。MQTT/TCP 可能产生建连、保活和会话恢复开销；CoAP/UDP 不维持 TCP 连接，可让应用按消息选择 NON 或 CON，因而常进入低频上报场景的候选集。但无线模组注册、PSM/eDRX、DTLS 或 OSCORE、安全握手、重传和传感器采样往往比四字节报文头更影响能耗。没有任何应用层协议能保证“零功耗待机”，最终选择必须以目标模组和覆盖条件下的电流曲线、丢包与续航预算为准。
内存和算力同样构成边界，但“Cortex-M0”本身不足以给出协议结论：具体 MCU 的 RAM/Flash、网络栈、TLS/DTLS 库、证书链和缓冲配置差异很大。CoAP 实现通常可以较精简，LwM2M 则在其上增加对象模型和生命周期管理；MQTT/TCP/TLS 也存在面向受限终端的裁剪实现。应以目标固件的链接产物、峰值堆栈、握手内存和故障恢复测试比较，而不是按内核名称直接排除协议。
生态约束：标准成熟度与工具链
协议再好在理论上完美，缺少成熟的开源实现和调试工具，落地就难。MQTT 的生态相对成熟：Eclipse Paho、Mosquitto、EMQX 等实现经过大规模验证，覆盖主流语言；调试工具齐全（MQTTX 等 GUI 客户端、Wireshark 的 MQTT 解析器）。工程师将一个功能从原型推进到产线，很少被工具链卡住。这些条件都建立在 OASIS 标准（MQTT v3.1.1、v5.0）之上。
CoAP 的生态相对“年轻”。有 IETF RFC 7252 作为标准，Californium（Java）、libcoap（C）等成熟实现，但调试工具箱的深度和广度不如 MQTT。若选择 LwM2M，它架在 CoAP 之上，把设备管理、固件升级、远程配置标准化为对象模型，在电信级终端如 NB-IoT 模组、智能表计中日渐常见。代价是学习曲线更陡：开发者需要理解“对象/对象实例/资源”三级树结构，而不仅仅是发一条消息。是否需要这种额外的抽象层，取决于是否真的需要远程固件升级、设备配置读取等管理功能——不可本末倒置。
安全考量
任何协议落到实际部署都绕不开安全层。HTTP 有 HTTPS（TLS），MQTT 可在 TCP 之上跑 TLS（常称 MQTTS），CoAP 使用 DTLS（Datagram Transport Layer Security，数据报传输层安全）加密，LwM2M 同样基于 CoAP 的 DTLS 保护通信。此外，设备身份认证——预共享密钥、X.509 证书还是 Token——不同协议和 Broker 的支持深度各不相同，会直接影响设备接入的整体安全架构设计。
选型框架：简化决策对比
把这些维度拉成一张对比表，决策会更清晰。
表9-1 主流物联网应用层协议选型对比
| 维度 | MQTT | CoAP | LwM2M | HTTP |
|---|---|---|---|---|
| 传输层 | TCP | UDP | CoAP/UDP + DTLS（默认形态） | TCP |
| QoS 等级 | 0 / 1 / 2 | CON / NON（映射0/1） | 同 CoAP，叠加对象确认 | TCP 自身重传 |
| 典型延时特征 | 适中（TCP 握手+保活） | 低（无连接维护） | 低 | 相对高（头开销大） |
| 功率消耗特征 | 中 | 低 | 低 | 高 |
| 典型应用场景 | 智能家居、车联网、工业监控 | 传感器低频上报、地磁车位、农田监测 | NB-IoT 模组、智能表计、远程设备管理 | 第三方 API 取数、网关上行批量、配置管理 |
| 较适合场景 | 经 Broker 分发的双向消息，需要 QoS 与会话语义 | 大量小数据包、按消息选择确认方式的受限终端 | 需要标准化远程管理流程的终端 | 已有 Web 基础设施的 RESTful API 与大对象传输 |
| 最差场景 | 深度休眠、极低功耗终端 | 需要严格消息排序和持久化的应用 | 开发速度优先、团队 CoAP 经验不足 | 海量高频率小数据包上报 |
注：表中各维度的定性判断基于协议设计规格与典型部署经验的工程归纳，非精确测量数据。具体部署条件不同，结论可能存在偏移。
另注：LwM2M 一栏的“CoAP/UDP + DTLS”是默认形态，并非唯一选择——LwM2M 1.2 起已支持 OSCORE（RFC 8613，在 CoAP 报文层提供端到端加密与完整性保护，机制见第 8 章 8.3.2 节），在 DTLS 握手开销难以承受或需要跨代理端到端保护的场景中，可作为替代安全路径。
这张表可以作为决策起点。当你走进后续章节，看到每个协议在具体案例中的表现时，可以随时回来对照：为什么这个场景选了 CoAP 而非 MQTT？为什么智能家居网关用了 MQTT 而传感器本身走 CoAP？选型框架会帮你把答案连起来。