6.1 MQTT与CoAP的选型台账
文档摘要
6.1 MQTT 与 CoAP 的选型台账 本节摘要：把 MQTT 与 CoAP 拉到同一张多维对比桌——传输承载、语义模型、可靠保证、资源开销、适用边界——并用决策树帮你在设备端做取舍。承接第 3、4 章的细节，通往 6.2 的广域对比。 MQTT 与 CoAP 都跑在 IP 之上，都想服务"连了网的设备"，却走了两条完全不同的路。本节把它们每一项摊开对齐，让"选哪个"变成一道有依据的判断题。 一张多维台账差异 下面这张矩阵把 MQTT 与 CoAP 在多维刻度上的取向一次性对比，尤其适合贴在评审白板上： 一张多维台账差异 逐项解读：差别藏在语义里 承载：MQTT 坐 TCP 有连接，天然可靠却较"重"；CoAP 坐 UDP 无连接、自建可靠，更省。 语义：这是分水岭。
6.1 MQTT 与 CoAP 的选型台账
本节摘要：把 MQTT 与 CoAP 拉到同一张多维对比桌——传输承载、语义模型、可靠保证、资源开销、适用边界——并用决策树帮你在设备端做取舍。承接第 3、4 章的细节，通往 6.2 的广域对比。
MQTT 与 CoAP 都跑在 IP 之上，都想服务"连了网的设备"，却走了两条完全不同的路。本节把它们每一项摊开对齐，让"选哪个"变成一道有依据的判断题。
一张多维台账差异
下面这张矩阵把 MQTT 与 CoAP 在多维刻度上的取向一次性对比，尤其适合贴在评审白板上：
逐项解读：差别藏在语义里
- 承载：MQTT 坐 TCP 有连接，天然可靠却较"重"；CoAP 坐 UDP 无连接、自建可靠，更省。
- 语义：这是分水岭。MQTT 是"对主题喊话、谁订阅谁知道"的广播逻辑；CoAP 是"对 URI 点名、要个表示"的读写逻辑。前者天然多对多解耦，后者天然一对一精确。
- 可靠：MQTT 用 QoS 逐跳保证且是代理集中保证；CoAP 的 CON/超时重传是端点各自负责。
- 开销：CoAP 固定头 4 字节，整体比 MQTT（虽有 QoS/主题等字段）更简省，对受限内存更友好。
决策树：给我一句话，我还你一套协议
- 要常年在线、双向可靠、多对多广播 → MQTT。
- 休眠省电、以读改为重点、资源受限 → CoAP。
- 两条常打架时，把"是不是要立一个人人订阅的中央话题"作为最后裁决一问。
一张逐字段的对照台账
矩阵看取向，下表看细部，把两套协议在务实维度上一行行对齐（适用于多数按协议实现，个别能力随实现而异）：
| 维度 | MQTT | CoAP | 谁更占优 |
|---|---|---|---|
| 传输承载 | TCP 有连接 | UDP 无连接 | CoAP 更轻 |
| 固定头/报文开销 | QoS+主题等字段，头较小 | 固定头 4 字节 | CoAP |
| 通信语义 | 发布订阅、主题路由 | 请求响应 + Observe | 看需求 |
| 可靠保证 | QoS 0/1/2 代理集中 | CON/超时重传端点各自负责 | MQTT 更系统 |
| 解耦模式 | 多对多、发布订阅者解耦 | 一对一精确读写 | MQTT |
| 设备常驻要求 | 需长期连接与心跳 | 可深睡按需唤醒 | CoAP |
| Broker/中枢 | 必须一台 Broker | 端点直连或代理 | CoAP 更扁平 |
| 受限于弱内存设备 | 会话状态较重 | 极简更友好 | CoAP |
| 多云话题多租户管理 | Broker 统一 ACL 强 | 分散处理较弱 | MQTT |
把这张表记住条目比记忆次"谁好"更值——绝大多数"选型"其实是"找这张表里最适合自己约束的那一列"，而不是在比绝对优劣。
一次"两难"场景的判定演练
让决策树真正跑一趟。假设你有若干台可插电的智能灯，网关带宽充裕，运维希望统一管理订阅、下发批量控制指令。走判定：设备能不能常年在线？能（插电）→ 走 MQTT；要双向可靠订阅批量控制？要 → MQTT。这套需求几乎无悬念落 MQTT。
再换：一批埋入墙内的电池温湿度传感，内存 8 KB、尽量想撑两年电，主要是被网关定时读状态。判定：能否常驻线？不能（要省电）→ 走 CoAP；以读改为重点？是 → CoAP。于是内存与省电约束直接把它推到 CoAP。两个例子说明：判定树的两问（能否常驻 + 是否读写/订阅）几乎每次都能收敛到单一答案，很少真正僵持。
一个常被低估的提醒
选 MQTT 往往不是因为"它最好"，而是因为"它背后有个 Broker，能把一堆设备的订阅统一管理、多租户 ACL 一次配齐"；选 CoAP 往往是"预算内存小到撑不住 MQTT 客户端 + 会话状态"。把"运维成本"和"内存预算"都写进选型理由，比单比性能更接近生产现实。
一批设备混搭，怎么不让协议打架
现实中往往不是"整批设备选一种协议"，而是同一批里既有能常年上电的路由器、又有靠电池的传感器。此时正确的做法不是强求统一语言，而是在网关上做一次透明的协议翻译：一边用 CoAP 把埋在墙里的传感节点收进来，一边用 MQTT 把整理好的数据推给云端与多租户订阅。对上层业务，用得越多地看到统一的数据流；对下层设备，各按其约束协议自由生长。这样"设备侧按省电选 CoAP、平台侧按订阅与管理选 MQTT"的分工，恰好把两套协议的优点都留下来——而这正是第 6.3 节桥接的实战内容，这里先把"可以混搭"这颗种子点下去。
从运维视角给两套协议各画一张生命线
选型时若只比报文、比语义，容易漏掉"日常怎么伺候它"。站到运维角度各看一遭：MQTT 的生命线离不开一台健康的 Broker——Broker 要监控连接数、主题、ACL、消息积压，Broker 一挂了所有订阅者集体失联，所以它的健康度直接决定整条链路的可用性；CoAP 的生命线则在网络与资源本身——端点分散、无统一中枢，个别端点掉线不影响别的，但因为是 UDP+ 自建可靠，排查经常要抓包逐条看 CON/重传，比 MQTT 的日志更费手工。这两条"伺候线"一对比就明白：MQTT 把复杂度集中到一台运维对象上，CoAP 把复杂度摊薄到每一条资源上——各有一段难伺候，配运维人力时要看清自己更养得起哪一头。
附一张快速对照的最终纪要
把全节压缩成一段可贴墙的纪要供方案评审时引用：同是 IP 之上，MQTT 以长连接和订阅换集中管理，CoAP 以无连接和 REST 换扁平省电；前者适合"能常驻、要双向可靠、多对多"的一群设备，后者适合"要深睡、以读改为重、内存极紧"的受限节点。真遇到悬案，回到那两个判据问——"能不能常驻线"与"要不要订阅广播"——答案一出，协议多半自己浮出水面。
💡 关键直觉：别问"MQTT 和 CoAP 哪个强"，要问"我这台设备是'易于常驻在线'还是'必须深睡'"——答案几乎就决定了协议。
本节要点回顾
- 要点一：MQTT 坐 TCP 强在发布订阅 + 代理集中的双向可靠。
- 要点二：CoAP 坐 UDP 强在资源化精简 + 极致省电。
- 要点三：语义模型是分水岭——广播解耦 vs 精确读写。
- 要点四：运维成本（Broker 管理）与内存预算也决定选型，不止性能。
同层的对比看清了，6.2 把镜头拉远到广域——LoRaWAN 与 NB-IoT、Sigfox 这三个 LPWAN 怎么选。