9.1 物联网应用层协议概览
9.1.1 物联网应用层协议分类
传感器数据从现场到云端，中间经过的每一层协议都在做一件事：定义数据的形状和交换的规则。应用层作为四层架构中最靠近业务的一层，承担着将物理信号转换为业务语义的角色。面对碎片化的设备类型、通信介质和功耗约束，工程师需要在协议选择上做出第一道权衡。
通信模型：两种基本交互模式
物联网应用层协议按通信模型分为请求/响应和发布/订阅两类，两者设计的出发点截然不同。
请求/响应模型（Request/Response）的逻辑与 HTTP（HyperText Transfer Protocol，超文本传输协议）一脉相承：客户端发起请求，服务器回复响应。CoAP（Constrained Application Protocol，受限应用协议）由 IETF（Internet Engineering Task Force，互联网工程任务组）定义，以 REST（Representational State Transfer，表征状态转移）架构为基础，支持 GET、PUT、POST、DELETE 四种方法，与 HTTP 的方法一一对应。从 Web 开发转入物联网的工程师几乎无需重新学习交互语义。缺点在于每一次交互都需要客户端知道“找谁要”，且一次请求只能拿到一个响应，不适合一对多的数据分发。监控中心如果轮询上千个温度传感器，每次轮询都会触发一次完整握手。
发布/订阅模型（Publish/Subscribe）的设计则完全不同。设备将消息发布到一个 Broker（代理），其他设备或服务向 Broker 订阅特定主题，Broker 负责消息的转发。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是这一模型的典型代表，早期被设计用于石油管道、远程监控等信道窄、延迟高、不可靠的场景。发送者与接收者在时间和空间上完全解耦——发布者可以发完就休眠，由 Broker 暂存消息，待订阅者上线后再推送。对电池供电的传感器而言，这意味着可以减少无线电收发器的唤醒频次，从而延长续航。
两个模型的根本差异落在“同步 vs 异步”这条分界线上。请求/响应要求双方同时在线；发布/订阅允许发送端离线。前者适合按需查询；后者适合持续采集与分发。
传输层与设备能力：TCP 还是 UDP？
第二个决定协议选择的分岔路口，来自传输层的 TCP（Transmission Control Protocol，传输控制协议）与 UDP（User Datagram Protocol，用户数据报协议）。
MQTT 跑在 TCP 之上，依赖 TCP 的三次握手、保活、重传和流控制来保证可靠性。代价在于维持长连接需要持续的能耗——对于每天只上传几次数据的小型传感器，TCP 的保活心跳可能比数据本身的能耗还高。这个约束在早期 MQTT-SN（MQTT for Sensor Networks）的尝试中已经体现出来：直接沿用 TCP 的设计在资源受限环境下并不经济。
CoAP 选择 UDP 作为基础。UDP 无连接、不保证送达，但开销极低。CoAP 通过 CON（确认消息）和 NON（非确认消息）两种消息类型区分可靠等级：CON 消息要求接收方必须在有限时间内回复 ACK（确认应答），否则发送方会重传；NON 消息则发完即弃。这种设计让 CoAP 在 UDP 之上按需选择可靠性，而非背起整条 TCP 保活链路。
LwM2M（Lightweight Machine-To-Machine，轻量级 M2M 协议）的定位更特殊。它由 OMA（Open Mobile Alliance）定义，是一套面向设备管理与数据采集的应用层协议，但底层完全依赖 CoAP。从协议栈视角看，LwM2M 定义的是“消息怎么编排、可靠到什么程度、设备状态如何管理”，而 CoAP 负责消息收发。二者层次叠加——CoAP 在 UDP 之上，LwM2M 又在 CoAP 之上——构成了面向资源受限设备的完整协议栈。
分类图谱：一张图看清协议布局
下面的分层图展示了从感知层到应用层的主要协议位置。底层是感知层的传感器与执行器；向上是无线接入技术（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，没有连接维护开销，设备发完消息就进入深度睡眠——这才是真正接近“零功耗待机”的模型。这也是为什么在电池供电的低频上报场景中，CoAP 往往比 MQTT 更适合。
内存和算力同样卡着天花板。一片 Cortex-M0 MCU，RAM 总数不过十几 KB，在上面跑完整的 MQTT 协议栈（含 TCP/IP 和 TLS 加密栈）几乎不可能。CoAP 的设计目标就是面向这类 MCU：协议栈足够精简，能塞进有限闪存空间。LwM2M 在 CoAP 之上叠加了设备管理对象模型，虽然多一层抽象，但底层仍保留 CoAP 的资源开销优势。
生态约束：标准成熟度与工具链
协议再好在理论上完美，缺少成熟的开源实现和调试工具，落地就难。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 取数、网关上行批量、配置管理 |
| 最佳场景 | 双向控制、需要高可靠送达的场合 | 大量小数据包、电池供电的深度休眠终端 | 需要远程管理的电信级终端 | 对实时性无要求的 RESTful API 调用 |
| 最差场景 | 深度休眠、极低功耗终端 | 需要严格消息排序和持久化的应用 | 开发速度优先、团队 CoAP 经验不足 | 海量高频率小数据包上报 |
注：表中各维度的定性判断基于协议设计规格与典型部署经验的工程归纳，非精确测量数据。具体部署条件不同，结论可能存在偏移。
另注：LwM2M 一栏的“CoAP/UDP + DTLS”是默认形态，并非唯一选择——LwM2M 1.2 起已支持 OSCORE（RFC 8613，在 CoAP 报文层提供端到端加密与完整性保护，机制见第 8 章 8.3.2 节），在 DTLS 握手开销难以承受或需要跨代理端到端保护的场景中，可作为替代安全路径。
这张表可以作为决策起点。当你走进后续章节，看到每个协议在具体案例中的表现时，可以随时回来对照：为什么这个场景选了 CoAP 而非 MQTT？为什么智能家居网关用了 MQTT 而传感器本身走 CoAP？选型框架会帮你把答案连起来。