6.1 应用层协议选型总览

6.1 应用层协议选型总览

MQTT、CoAP、AMQP、DDS、HTTP 五家分居不同性格，本节把它们放上一张横向对比表，按"发布订阅 vs 请求响应"与"轻量 vs 企业级"两条轴定位，给出协议选型的快捷判据。

先把五张脸摆在你面前

阅读完本节，你应当能够：

1. 列出五家协议各自主打的范式与场景。
2. 用"报文胖瘦 × 实时性 × 可靠性 × 交互模式"判断该用谁。
3. 意识到"协议是语言的搭配"，同一条通道能换多种语言。

一、先把五张脸对上号

前文把物理通道讲了个遍，现在要摔到最高一层"业务语言"。物联网应用层有一群常客，它们性子差别很大。把五家放在一起，最大的分水岭是范式的基因——回看 2.3 的发布订阅与请求响应，几乎立刻能分出阵营：

• 发布订阅派：MQTT、AMQP。发出去就不管谁收，靠 broker 中转，天然一对多、解耦、异步。
• 请求响应派：CoAP、HTTP。一问一答，明确发起主动方，靠客户端与服务端对齐。
• 实时数据分发派：DDS。面向强实时、数据随时在多个节点间广播分发的工业/机器人场景，在特定网域内搞"大家都在场"的数据共享。

一句话记法：想一句话发许多人 → MQTT/AMQP；想一问一答 → CoAP/HTTP；想让若干节点各取所需的高频实时数据 → DDS。

二、一张横向对比表

这张表只是开胃。真正选型要靠下面五问定案，而不是凭表头"噢 MQTT 厉害"拍板。先把五家的"性格光谱"铺成一张二维定位图，纵轴 lightweight（轻量度）、横轴范式（发布订阅 ↔ 请求响应），你就能在俯视全局里挑落点：

三、五问选型法

问一：交互是"一呼多应"还是一问一答？
一呼多应、产品要解耦 → 发布订阅（MQTT/AMQP）；一问一答、要确认结果 → 请求响应（CoAP/HTTP）。

问二：设备有多受限（内存、功耗、带宽）？
极受限的传感器 → CoAP 极省、MQTT 轻量可扛；资源宽裕的企业应用 → AMQP，功能全但要厚底子。

问三：实时性与可靠性哪头更重要？
要高速实时数据共享与部署机器集群 → DDS；要消息可靠不丢、可回放、企业级事务 → AMQP；要海量小传感可靠上报 → MQTT 的 QoS。

问四：数据要经过云端还是网域内自发？
要上云、要边缘与平台松耦合 → MQTT（broker 上云天然）；要局域网内节点间实时分发、不追求集中云 → DDS。

问五：要不要和传统 Web 生态兼容？
要、或要浏览器直连、要做管理页面 → HTTP 躲不掉；纯物联后台、不想背 HTTP 头部 → MQTT/CoAP。

四、一个"一眼定音"的快照

真到落地，若每问都对号入座，多半是这样的大概率组合：

• 海量传感器上报 + 解耦 + 上云 → MQTT。
• 极受限设备 + 一问一答 + UDP 省电 → CoAP。
• 企业级订单/产线消息 + 需路由事务可靠 → AMQP。
• 机器人/车协同的高频实时数据 → DDS。
• 网页/管理平台/浏览器直连 → HTTP/HTTPS。
• 底层寻址不可少 → IPv6（本节略，见 6.6）。

五、别被"热门协议"绑架

最后给一句冷静帖：不存在"所有物联网都用 MQTT"这种真理。协议是业务语言的搭配，而语言要看场景脸色。一个静态抄表项目用 CoAP 或 MQTT 皆可，一个需要消息回放与事务的交易平台配 AMQP，一个工业产线要毫秒级协同配 DDS。选型的本质是回到 2.3 的范式判断 + 业务约束，而不是听说谁就抄谁。

六、选型时最容易踩的三个坑

五问定案听着顺，真选起来还有三处特别容易栽跟头，先给你排雷：

• 坑一：把"上云最火"当"最适合"。MVP 阶段一听到 MQTT 就全盘用，结果设备其实只是网关内网几十个点一问一答，CoAP 更省却没人想。排雷口诀：先看范式与受限度，再谈流行度。
• 坑二：混搭时不设边界网关。要用"CoAP 前端 + MQTT 上云"，中间必须有一层协议转换网关把两种语义接好；直接让受限设备硬连 MQTT，省下的内存又全还回去。排雷口诀：混搭可以，但转换器要画在架构图上。
• 坑三：忽略协议的"会话驻留"成本。MQTT/TCP 这类面向连接的协议要保活会话，设备省不了睡眠；一旦你以为 MQTT 就万能、给所有低功耗点都接它，电池会以你意想不到的速度见底。排雷口诀：图省电就把话少的点赶去 UDP 系（CoAP）。

七、一次真把两个项目选错又改对的全过程

用一个真实过程把五问用起来，比背口诀牢靠。团队先是给室内空气监测的一批十几台设备挑协议，拍脑袋上了 MQTT，理由是"大家都用"。可这些设备 RAM 只有 64 KB、功耗预算极紧、场景又是一问一答取读数——MQTT 的 TCP 连接和保活会话让设备根本没法睡稳，电池三月就没。走五问：范式是请求响应、设备极受限 → 该是 CoAP，改成 CoAP 后设备睡眠深度提升、功耗降了七八成，问题解决。

紧接着又要做园区几千点状态上报，这次不敢再拍脑袋，规规矩矩过五问：范式要解耦一对多、要上云 → MQTT，完美落单，一次选对。

两次对比说明：五问选型不是纸上谈兵，它把你从"听说谁火就抄谁"拉回"按约束对号入座"。同一个团队、同两个项目，用对方法一个选错一个选对，差距全在是否按范式与约束去推，而不是靠直觉。

八、同一台设备，五种说法长什么样

光看参数表容易飘，不如把"同一件小事"换五种协议各说一遍，体感立刻上桌。现假定一台咖啡机要上报"水温 88℃，注入 200ml"：

MQTT   → publish 到主题 咖啡A/状态，QoS1，broker 按订阅放给消费方
CoAP   → PUT /咖啡A/状态  body={水温,注量}，UDP 一问一答，可选确认
AMQP   → 放进 咖啡机进线 队列，带事务确认与路由键，多系统各有队列
DDS    → 在网域内 publish 主题数据，机器人/看板直接读到这份状态
HTTP   → POST /api/咖啡机/状态  JSON，浏览器/管理后台直接看
​

同样是"一杯咖啡的数据飞出去"，五种协议长得完全不同：MQTT 找 broker 挂账，CoAP 直接在 UDP 上问答，AMQP 进企业队列，DDS 走本地总线广播，HTTP 穿一身 Web 标准的行头。这一排下来你就明白——协议不是可选项里的"哪个好"，而是"同一句人话翻成哪种专业语言"。挑的是语言，不是答案。业务在哪个生态里、要什么范式与开销，语言就落在哪一格。

本节要点回顾

• 两家边界：发布订阅 vs 请求响应，是应用层协议的第一道分水岭。
• 五家名片：MQTT 上报、CoAP 受限、AMQP 企业、DDS 实时、HTTP 通用。
• 五问法：范式、受限度、实时性、云/网域、Web 生态，问完就能定。
• 没万能协议：选型靠场景与约束，不靠"最火"。
• 为后文铺路：后几节逐个做主角深挖。

五问已建框架，谁做得了海量上报的 boss？下一节请出 MQTT——物联网发布订阅的首选。