前言：写给物联网系统设计者的实战指南

当前物联网已进入规模化落地阶段，从智能家居单品到工业4.0生产线，从智慧农业到城市基础设施，设备联网已成为标配。然而，一个看似简单的问题却经常让团队陷入争论：设备与云端之间，究竟该用哪种通信协议？

作为系统架构师或嵌入式开发者，你可能已经知道MQTT、CoAP、HTTP这三个名字，但面对具体业务场景时，仍然会犹豫：

设备电池只能撑一年，选择哪种协议最省电？

需要控制智能灯泡，云端指令必须实时到达，选哪个？

设备部署在山区2G/NB-IoT网络，弱信号下谁更稳定？

现有团队只懂Web开发，直接上HTTP可行吗？

本文不是简单的“协议三选一”列表，而是一份可落地的选型指南。我们将从协议起源、工作机制、性能数据、安全特性、成本模型、真实案例等多个维度，帮你建立完整的评估框架，并最终给出清晰的选择决策路径。

1.三种协议的前世今生

1.1 HTTP —— 互联网的通用语言

超文本传输协议（HTTP）诞生于1991年，初衷是让CERN的科学家们方便地共享研究文档。它的设计围绕一个极简模型：客户端发起请求，服务器返回响应，然后断开连接。这个模型在PC互联网时代取得了巨大成功——浏览器请求网页，服务器返回HTML，用户阅读信息，完美契合人类“主动获取信息”的行为模式。

HTTP/1.1 → HTTP/2 → HTTP/3 的演进

HTTP/1.1（1997）：引入持久连接（Keep-Alive）和管道化，但队头阻塞问题依然存在。

HTTP/2（2015）：二进制分帧、多路复用、服务器推送，大幅提升性能。

HTTP/3（2022）：基于QUIC协议（UDP封装），解决TCP队头阻塞，连接建立仅需0-RTT或1-RTT。

尽管HTTP/3带来了性能飞跃，但物联网设备上的HTTP库支持度仍然参差不齐。目前大多数物联网项目仍在使用HTTP/1.1或HTTPS。

1.2 MQTT —— 为“机器对机器”而生的消息协议

1999年，IBM的Andy Stanford-Clark博士和Arcom的Arlen Nipper面临一个棘手问题：如何通过昂贵的卫星链路，监控数千公里外的石油管道？ 管道沿线传感器需要定期上报数据，但卫星带宽极其有限，网络延迟大且经常中断。他们创造了一个极简协议——MQTT，核心设计原则是：

1.轻量：协议头部最小仅2字节，减少卫星链路开销。

2.可靠：提供三种消息服务质量等级，适配不同可靠性需求。

3.异步：发布/订阅模型解耦发送方和接收方，允许设备离线后再接收消息。

2014年MQTT成为OASIS标准，2019年发布MQTT 5.0。如今，MQTT已是物联网领域事实上的应用层协议标准，几乎所有主流云IoT平台（AWS IoT Core、Azure IoT Hub、阿里云IoT、腾讯云IoT）都原生支持。

1.3 CoAP —— 让受限设备也能RESTful

IETF的CoRE工作组在2010年左右开始设计CoAP，目标是：把HTTP的RESTful架构带到UDP上，让8位单片机和16位低功耗芯片也能轻松实现Web风格接口。

CoAP的亮点包括：

极小的报文头：基础头部仅4字节，比MQTT还小（MQTT固定头2字节，但可变头和载荷标识会额外占用）。

内建重传机制：基于UDP的确认/重传，弥补UDP可靠性不足。

观察模式：客户端可“观察”资源，服务端在资源变化时主动推送，实现类似MQTT的发布/订阅。

低开销安全：通过DTLS（Datagram TLS）提供加密，比TLS握手更节省CPU和内存。

CoAP常见于NB-IoT、LoRaWAN、6LoWPAN等低功耗广域网络（LPWAN），典型的终端设备如智能水表、烟雾探测器、农业土壤传感器。

2.深入协议内部 —— 工作流程与关键机制

为了帮助你真正理解差异，我们用流程图和时序图详细拆解三种协议的通信过程。

2.1 MQTT 完整通信时序

下图展示了一个典型的MQTT会话流程，包含连接、订阅、发布、QoS确认和遗嘱消息发送。

关键细节解读：

Keep Alive：客户端必须在保活时间内发送任何报文（包括PINGREQ），否则Broker判定离线。

Clean Start：MQTT 5.0中，若设置为true，则会话开始时不继承任何之前的订阅和未确认消息。

遗嘱（Will）：必须在CONNECT报文中预设，不能事后修改。适用于设备异常断网告警。

2.2 CoAP 请求/响应与观察模式

CoAP有两种基本消息类型：CON（需确认） 和 NON（无需确认）。下图展示了CON请求的可靠传输和观察模式。

CoAP的独特优势：

每个请求都可携带Token（类似请求ID），响应时原样返回，支持异步处理。

观察序号递增，客户端可判断是否遗漏更新。

通过.well-known/core资源发现，设备可广播自身能力。

2.3 HTTP 典型物联网调用流程

HTTP在物联网中常用于设备配置更新或历史数据批量上传。下图展示了HTTPS请求的完整握手与数据交互。

每个HTTPS请求至少需要2个RTT（TCP握手1个RTT + TLS握手1~2个RTT），加上数据传输和四次挥手，对于频率较高的传感器上报（例如每10秒一次），开销极其巨大。

3.多维对比 —— 数据驱动的决策依据

3.1 头部开销与带宽效率

实测数据参考（来自Eclipse基金会2020年白皮书）：

发送1000次10字节数据，MQTT总传输量为12KB，HTTP/1.1为800KB。

在卫星链路（2.4kbps）上，MQTT比HTTP快约6倍完成相同数据量传输。

3.2 能耗对比 —— 谁的电池更耐用？

基于Powertower和IoT-LAB平台的测试数据（节点采用Cortex-M0 @ 32MHz，2.4GHz无线电）：

关键结论：

低频上报场景（<1次/分钟）：HTTP反而可能更省电，因为MQTT长连接的心跳包累积能耗可能超过短连接开销。

高频上报场景（>1次/分钟）：MQTT和CoAP优势巨大，尤其是CoAP的观察模式最省电。

接收端功耗：始终开机的网关/接收器比发送端多耗电15%~20%，设计时不要只关注设备端。

3.3 延迟与实时性

下表测量了从设备应用层发出数据，到对端应用层收到数据的端到端延迟（不含处理时间，单位毫秒）：

NB-IoT典型时延在1.6~3秒之间，因此对实时性要求高的场景不适用NB-IoT（可考虑Cat.1或Cat.4）。

实时性排名：CoAP NON ≈ MQTT QoS 0 > CoAP CON > MQTT QoS 1 > HTTP。

3.4 可靠性机制对比

QoS 2的四次握手：发送PUBLISH( QoS 2) → 接收方回复PUBREC → 发送方回复PUBREL → 接收方回复PUBCOMP。经过这四步，接收方确保消息不重复，代价是额外的RTT。

CoAP去重：CoAP客户端通过Message ID和Token组合来检测重复消息，但协议本身不强制去重，由应用实现。

3.5 安全性能对比与选择

OSCORE的亮点：它是CoAP专用的端到端安全协议，加密的是CoAP消息的特定部分，网关无需解密即可转发，大幅降低中间节点的安全风险。对于需要经过多跳代理的物联网系统（例如LoRaWAN到云），OSCORE是更优选择。

4.真实案例与架构实践

4.1 智能家居 —— 为什么几乎都选MQTT？

以小米智能家居为例，米家生态中设备（灯泡、插座、传感器）通过WiFi或Zigbee网关接入，通信协议采用定制版MQTT（部分设备使用CoAP over Zigbee，但云端统一用MQTT）。

选择理由：

控制实时性：用户点击App开关灯，指令需要在毫秒级到达设备。MQTT长连接保证下行指令实时推送。

设备状态同步：设备离线、低电量、故障等状态，通过遗嘱消息和保留消息让所有客户端（App、音箱、自动化引擎）立即感知。

跨厂商互操作：通过MQTT Broker开放API，第三方开发者可以轻松集成。

架构图示：

4.2 工业制造 —— Sparkplug标准化实践

某汽车工厂需要将数百台PLC、机器人、传送带接入中央监控系统。早期采用Modbus TCP轮询（每个设备每2秒查询一次），导致网络拥堵和PLC负荷过高。

改造方案：

在每个工位部署MQTT网关，网关通过Profinet/Modbus与设备通讯，转换为MQTT消息上报。

采用Sparkplug B规范统一消息格式：每个设备定义为spBv1.0/Group_ID/Message_Type/Device_ID主题结构，载荷使用Google Protocol Buffers编码。

中央监控系统订阅所有设备消息，实时显示状态，并可通过MQTT下发指令（例如修改焊接参数）。

收益：

网络流量降低80%（从轮询变为事件触发）。

新增设备无需修改监控系统代码，符合Sparkplug规范的设备自动被发现。

设备“死亡”事件通过Sparkplug的NDEATH消息自动上报，运维人员可立刻介入。

4.3 智慧农业 —— CoAP在电池供电设备中的绝佳表现

某葡萄园部署了500个土壤湿度传感器和气象站，采用NB-IoT通信，要求电池寿命至少3年。每个传感器每10分钟上报一次数据（约30字节）。

为什么放弃MQTT而选择CoAP？

NB-IoT的PSM（省电模式）与eDRX周期匹配：设备大多数时间处于深度睡眠，MQTT的长连接保活需要频繁唤醒（至少每10分钟一次），额外耗电。

CoAP的NON消息可在一次UDP传输中完成数据上报，无需维护连接状态，符合“发送后即休眠”模式。

CoAP的块传输支持将固件升级包分片下发，适应NB-IoT的最大传输单元限制。

实测结果：采用CoAP后，设备平均电流从MQTT方案的120μA降至45μA，电池容量（2000mAh）理论上可工作4.5年。

4.4 混合架构 —— 内部CoAP + 边缘MQTT网关

有些场景不允许云端直连，或需要本地自治。以下架构在油气管道监测中被采用：

南向（传感器-网关）：采用CoAP，传感器极省电，网关本地缓存数据。

北向（网关-云）：采用MQTT，保证数据可靠上传，支持断网续传。

云-应用：采用HTTP RESTful API，方便第三方集成。

5.选型决策框架 —— 一步步走向正确答案

5.1 核心判断矩阵

根据以下6个问题打钩，统计倾向：

简易决策规则：

如果问题1+2为“是”，且问题3为“否”：CoAP。

如果问题3为“是”，且问题4为“是”：MQTT。

如果问题5为“是”，且上报频率很低（每日<100次）：HTTP。

如果以上不明确，默认选择MQTT。

5.2 决策树（详细版）

5.3 常见选型误区

误区1：“MQTT一定比HTTP省电”

事实：对于每天只上报几次的设备，MQTT长连接的心跳包（通常每30~60秒一次）累积的能耗可能远超HTTP单次请求。建议在低频场景下考虑“暂存后批量上传”或使用CoAP。

误区2：“CoAP因为基于UDP所以不可靠”

事实：CoAP的CON消息提供了确认和重传，可靠性与TCP相当，只是不保证顺序。工业级CoAP实现通过序列号能解决乱序问题。

误区3：“我的设备只上传数据，不需要双向通信，所以HTTP就够了”

事实：除非频率极低，否则HTTP的TCP+TLS握手开销依然昂贵。而且，一旦未来需要远程升级或参数配置，HTTP的拉模式很难实现实时推送，改造成本巨大。建议初始设计就预留双向能力。

误区4：“HTTPS认证太复杂，用HTTP明文传输就好”

严重错误：明文HTTP在物联网中意味着任何能监听网络的人都可以伪造指令、窃取数据。至少使用预共享密钥（PSK）或设备证书。

6.协议演进与未来趋势

6.1 MQTT 5.0 带来的关键改进

相比广泛使用的3.1.1版本，MQTT 5.0增加了以下企业级特性：

原因码（Reason Code）：以前只有简单的成功/失败，现在有40多种原因码，例如0x80（不支持的协议版本）、0x95（超出配额），便于诊断。

会话过期（Session Expiry）：设备离线后，Broker可以保留会话一段时间，设备恢复后自动恢复未完成的消息。

共享订阅（Shared Subscription）：多个订阅者负载均衡消费同一主题的消息，适合水平扩展消费者。

主题别名（Topic Alias）：将长主题映射为整数ID，进一步减少消息大小。

用户属性（User Properties）：类似HTTP头，可传递自定义元数据，如request-id、traceparent。

注意：AWS IoT Core等平台对MQTT 5.0支持并不完整，特别是共享订阅和用户属性可能被阉割。选型前查阅文档。

6.2 HTTP/3 与 QUIC 在物联网的潜力

HTTP/3基于QUIC（UDP封装），解决了TCP队头阻塞，连接迁移（切换网络不断连）等痛点。对于移动物联网设备（如车载终端、无人机），QUIC的0-RTT恢复和连接迁移非常有价值。然而，QUIC实现复杂，目前主流IoT设备上缺乏成熟的轻量级QUIC协议栈，预计2~3年后才会逐步应用。

6.3 AMQP 等其他协议何时介入？

本文聚焦三种最通用的协议，但复杂场景下你可能听到AMQP（高级消息队列协议）。AMQP同样基于TCP，提供丰富路由和事务能力，常用于金融、电信级消息中间件。但对于物联网设备端，AMQP开销过大，一般只在设备数量较少的工业网关之间使用。

6.4 无服务器（Serverless）与协议的选择

随着AWS Lambda、阿里云函数计算等普及，许多物联网应用采用“设备→规则引擎→函数”的架构。此时，选择能直接触发函数的协议最方便：

MQTT：通过规则引擎SQL筛选后触发函数，是最成熟的模式。

HTTP：直接POST到API Gateway触发函数，简单。

CoAP：云平台原生触发函数较少见，通常需要代理转换。

因此，如果大量使用无服务器计算，MQTT或HTTP更具优势。

7.FAQ —— 你在选型会议上可能被问到的10个问题

Q1: 我可以在一个设备上同时实现MQTT和CoAP吗？

可以。比如设备平时用CoAP上报数据（省电），但当需要固件升级时切换到MQTT（利用QoS 2保证升级包完整）。代价是代码体积增大，需做好状态同步。

Q2: 哪些公有云IoT平台原生支持CoAP？

¢Azure IoT Hub：支持但不推荐生产环境。

¢Google Cloud IoT Core：已弃用（2023年8月关闭）。

¢阿里云IoT：通过CoAP网关间接支持。

¢开源方案：ThingsBoard、Kaa等支持CoAP。

总体而言，公有云对CoAP支持弱于MQTT。

Q3: 在LoRaWAN网络中应该用哪种协议？

LoRaWAN本身定义了MAC层，应用层通常使用：

¢直接传输自定义载荷（类似CoAP风格）。

¢LoRaWAN over CoAP：通过网关压缩CoAP消息。

¢MQTT不可直接运行，因为LoRaWAN带宽和频次限制不适合长连接。

常用做法是：节点发送自定义二进制消息到网关，网关转换为MQTT上云。

Q4: 使用TLS/DTLS对设备资源要求多高？

¢TLS 1.2需要约30KB RAM和50KB ROM（mbedTLS最小配置）。Cortex-M0+内核设备勉强可跑。

¢DTLS 1.2资源类似，但UDP性质可能导致分片重传，需要更多缓冲区。

¢对于极度受限设备（2KB RAM），建议使用PSK（预共享密钥）认证，或者依靠网关代理加密。

Q5: 协议选择影响设备云平台绑定的难易程度吗？

是的。例如AWS IoT Device SDK主要支持MQTT和HTTPS。如果选择了CoAP，需要自己实现签名认证（AWS Signature V4 over CoAP很复杂）。因此，如果已经确定云厂商，优先使用其官方SDK支持的协议。

Q6: 为什么工业现场更偏爱Modbus TCP而不是MQTT？

历史原因：Modbus RTU/TCP是工控领域的“普通话”，PLC原生支持。MQTT需要额外网关或PLC固件支持。但新项目越来越多地使用MQTT+Sparkplug过渡。

Q7: 广播场景（如升级所有设备）用哪种协议最优？

MQTT的共享订阅或直接使用通配符+/#来广播。CoAP没有原生广播，需要通过组播CoAP（RFC 7390）实现，在IPv6网络上可行，但普及度低。HTTP无广播能力。

Q8: 设备上报的JSON很大（几KB），是否应该压缩？

MQTT和CoAP本身不压缩，但可以应用层使用gzip或CBOR（类似JSON的二进制格式）。CoAP的Content-Format 支持CBOR（application/cbor）和gzip。MQTT可在用户属性中指示压缩方式。

Q9: MQTT Broker单机最大连接数是多少？

¢Mosquitto：约5~10万连接（受限于文件描述符）。

¢EMQX：单节点100万连接+（使用Erlang/OTP）。

¢VerneMQ：类似EMQX。

企业级Broker可以通过集群支持千万级连接。

Q10: 有没有统一的测试工具？

¢MQTT：MQTT.fx, MQTT Explorer, mosquitto_pub/sub。

¢CoAP：Copper (Firefox插件)，libcoap的client。

¢HTTP：curl, Postman。

综合性能测试：Eclipse Paho提供的性能测试套件。

8.结语 —— 没有银弹，但有最佳实践

物联网通信协议的选择不是非黑即白的技术优劣比拼，而是一场基于业务场景、硬件限制、网络环境和团队能力的综合权衡。本文花费大量篇幅对比三种协议，不是为了说服你“选A就赢，选B就输”，而是希望你掌握一套系统化的评估方法：

1.明确约束：电池寿命、CPU/RAM、网络带宽、实时性、可靠性。

2.量化指标：计算每分钟消息数、平均载荷大小、允许的最大延迟。

3.原型验证：在目标硬件上跑通最小demo，测量功耗和延迟。

4.考虑未来：一年后设备数量翻倍，协议栈能支撑吗？需要远程升级吗？

5.保持开放：采用网关/桥接模式，允许混合协议并存，不被单一协议绑定。

最后，分享一个来自工业物联网领域的经验法则：“当你不确定时，用MQTT；当你知道自己需要极低功耗时，用CoAP；当你只是做原型或管理系统时，用HTTP。” 这个法则已经帮助无数团队避免了过早优化或错误选型。