2.3 应用层协议全景：HTTP、MQTT、CoAP

2.3 应用层协议全景：HTTP、MQTT、CoAP

本节摘要：在 TCP/UDP 之上，应用层协议决定了"设备之间怎么对话"。本节对比 HTTP、MQTT、CoAP 三套主流的语义偏好、重量与适用对象，给出一个快速定位口诀，为第 3、4 章深挖 MQTT 与 CoAP 做铺垫。

传输层定了运输方式，应用层则管"话怎么说"。物联网应用层有老中青三代代表：传统老将 HTTP、消息派 MQTT、道场新锐 CoAP。三者都跑在 IP 之上，却说着完全不同的三种话。

一句话区分三者

• HTTP：请求-响应语义，面向"你问我答"的网页式访问，报文头重、每次请求独立。
• MQTT：发布-订阅语义，面向"广播给多关心者"的遥测与控制，靠主题解耦，长连接持久。
• CoAP：请求-响应 + 观察者语义，面向受限节点，报文用二进制紧凑编码，可确认可观察。

一张全家福对比表

为什么 HTTP 在设备端吃力

不是说 HTTP 不能用于 IoT——至少数据上云、管理面接口它仍是主力。麻烦在于给受限设备端用时，报文头部几百字节的文本开销、每次请求都要断开重建连接的癖性，会放大功耗与带宽。所以真正贴着传感器的设备，多半转向 MQTT 或 CoAP，只在"上云那一段"交给 HTTP 网关去转。

MQTT 与 CoAP 的分工预演

三者里最常在设备端被比较的是 MQTT 与 CoAP。用一个直观例子收束三者的站位：

• 需要持续在线、双向可靠、可订阅控制的设备 → MQTT；
• 需要按需读写、尽量省电、REST 风格的受限节点 → CoAP；
• 给最终用户看的页面/管理接口 → HTTP。

需要提醒的一个反直觉点

有人以为 CoAP"既然最省电就处处优先",但 CoAP 的省电建立在"平时不保持连接、被 OF（Observe）时服务器主动推"这套设计上，它并不擅长海量双向实时控制。反过来 MQTT 虽可靠，但强依赖 Broker 长连接，对"连 IP 都费劲"的野外终端(比如地下管道)并不合适——那是第 5 章 LoRaWAN 的领域。认清三者的射程边界，远比记住口号重要。

💡 关键直觉：选应用层协议别只比"省不省"，要比"设备能不能常驻线、要不要双向、REST 还是主题"——这三点几乎决定 MQTT 与 CoAP 的归宿。

从报文开销看三者"重量"差异

说 CoAP 省电，光看口号没用，最直观的是比较"发一条最小状态请求"到底带多少个字节。估一下三种报文最小头的量级：

记住这个量级差，就能解释 2.3 的一个常见现象：同样上传一条气温，HTTP 要为一个有效十几位的 JSON 再搭几百字节的车票，CoAP 则几乎贴着有效载荷走。头部开销在"发得越勤、包越小"的遥测场景里会被反复放大，这也是为什么"贴身传感器几乎清一色避开 HTTP"。

三种传输承载的取舍再细一层

既然 MQTT 走 TCP、CoAP 走 UDP，两者背后的成本差异也在 2.2 基础上深化：MQTT 把可靠性外包给 TCP，换回应用层的简单（QoS 语义与序号由传输层兜底）；CoAP 必须自己在报文里扛 CON/Ack、超时重发与去重。于是 CoAP 的字段要比 MQTT 多做不少"可靠账"——这既是它叫"受限应用协议"的原因，也是它与 MQTT 在整个设计哲学上分道扬镳的起点。看懂这层，第 3 章走后 MQTT 理所当然"重而不慌"，第 4 章看完 CoAP 才会明白它"省而不简"。

典型的物联网"三国"各司其职

三个协议往往不是互相取代，而是在同一套系统里各占一段。用一个楼宇能耗系统把三国排位看明白：楼里的温湿度传感大多用 CoAP，按需读写、省电躺着；楼控网关把采集的结果整理后，用 MQTT 推到云端的订阅主题，报表、工单、大屏都能订阅同一份数据；最终运维人员在浏览器上打开 HTTP 页面，看的就是云端渲染好的看板与告警。三个协议从设备端一路排到人机界面，各管一棒、彼此接力——这比"把整家楼都塞进一种协议"现实得多，也正面回答了许多人"是不是只能二选一"的困惑。

一套系统里，三国产物如何商量接口

协议能并存，关键在于"谁和谁说话用什么语言"。工程上常用两条线来划界，避免混乱：设备到网关这一段，多半贴传感器，优先 CoAP 或 MQTT 的轻量侧；网关到云端这一段，往往已经是对外、要曝光接口，常用 MQTT（对外订阅）或 HTTP（对外 API）。至于"网关上要不要做协议翻译"，就是第 6 章桥接的专研内容——本节只把"边界画在哪"的意识先立起来：多个协议并存不是缺陷，而是物联系统天然的分层现实，划清边界比强求统一更重要。

一张选型口诀复盘

把本节浓缩成一句话供你在遇到"三选一"时默念：问它"能不能常驻线"→ 能，看是不是"要双向可靠订阅"（MQTT）；不能，看是不是"要 REST 按需读写"（CoAP）；既不是设备而是人看，那就 HTTP。 需要双向可靠控制且能常驻 → MQTT；受限省电按需 → CoAP；人读的页面/管理接口 → HTTP。

💡 收束直觉：MQTT 偏向"连接型、双向、订阅"；CoAP 偏向"消息型、按需、REST"；HTTP 留给"人机接口"。三者边界一旦画清，第 3、4 章的细读就有了明确坐标。

本节要点回顾

• 要点一：HTTP 面向请求响应和管理面，报文重；MQTT 面向发布订阅和遥测，长连接；CoAP 面向受限节点，二进制紧凑。
• 要点二：设备端倾向于 MQTT/CoAP，云到人这一段常留 HTTP。
• 要点三：MQTT 强在双向可靠订阅，CoAP 强在省电按需读写。
• 要点四：野外无 IP 终端两套都不合适，那是 LPWAN 的舞台。

从下一章起，我们正式进入协议内部：第 3 章把 MQTT 的报文、QoS、握手拆到字节级。