3. 网络通信协议：MQTT、CoAP、HTTP/2、gRPC 在边缘场景的应用
聊到边缘计算，通信协议这块儿是绕不开的坎儿。我见过不少团队，设备端跑得挺欢，结果数据一上云就卡死，或者反过来，云端下发的指令设备半天收不到。说白了，选对协议，项目就成功了一半。
今天咱们就掰开揉碎，聊聊边缘场景下最常用的四个协议：MQTT、CoAP、HTTP/2 和 gRPC。每个协议我都会结合自己的实战经验，讲讲它们适合什么场景，又有什么坑。
3.1 MQTT 协议详解
MQTT，全称 Message Queuing Telemetry Transport，消息队列遥测传输。这名字听着挺唬人，其实核心就三个字：轻、快、省。
发布/订阅模型
MQTT 用的是发布/订阅模式，不是传统的客户端/服务器。有个中间人叫 Broker，设备往 Broker 上发消息，其他设备从 Broker 上订阅感兴趣的主题。这样做的好处是解耦，发送方和接收方不需要知道对方的存在。
我在一个智慧农业项目里用过 MQTT。几百个传感器节点，每个节点每隔 5 秒上报一次温湿度。如果用 HTTP 轮询，服务器早崩了。但用 MQTT，每个传感器只发一条消息到 Broker，后台服务订阅了所有传感器主题，数据就自动流过来了。嗯，省心。
QoS 质量等级
MQTT 定义了三个服务质量等级：
| QoS 等级 | 含义 | 适用场景 |
|---|---|---|
| 0 | 最多一次（At most once） | 传感器数据，丢几条无所谓 |
| 1 | 至少一次（At least once） | 控制指令，确保送达但可能重复 |
| 2 | 恰好一次（Exactly once） | 计费、交易等关键数据 |
保留消息与遗嘱消息
这两个特性很实用。保留消息让新订阅的设备能立即拿到最新值，不用等下一次发布。遗嘱消息则是在设备异常断开时，Broker 自动替它发一条消息，通知其他设备“我挂了”。
举个例子，一个门禁系统。门禁控制器上线后，发布一条保留消息 door/status 值为 closed。新接入的监控服务订阅这个主题，立刻就知道门是关着的。如果控制器掉线，Broker 自动发布遗嘱消息 door/status 值为 offline，监控服务就能及时告警。
3.2 CoAP 协议
CoAP，Constrained Application Protocol，受限应用协议。这名字就说明了一切——它是给资源受限的设备用的。
基于 UDP，轻量级
CoAP 跑在 UDP 上，不像 MQTT 需要 TCP 连接。这意味着它更轻量，适合那些内存只有几十 KB、CPU 主频几十 MHz 的传感器节点。CoAP 的消息头只有 4 个字节，而 MQTT 最小也要 2 个字节，但加上 TCP 头就大了不少。
请求/响应模型 + 观察者模式
CoAP 支持传统的请求/响应，也支持观察者模式。设备可以“观察”一个资源，当资源变化时，服务器主动推送通知。这有点像 MQTT 的订阅，但更轻量。
我记得在一个智能路灯项目里，路灯控制器用的是 CoAP。每个路灯上报自己的状态（开/关、亮度、功耗），控制中心用观察者模式监听所有路灯。当某个路灯故障时，控制中心能秒级感知。如果用 HTTP 轮询，每 5 秒查一次，网络开销大不说，延迟还高。
资源发现
CoAP 支持 /.well-known/core 资源发现。设备可以广播查询，找到网络里有哪些 CoAP 服务。这个特性在动态组网的边缘场景里很实用，设备即插即用，不用手动配置。
3.3 HTTP/2 在边缘场景的应用
很多人觉得 HTTP 太重，不适合边缘。但 HTTP/2 改进了很多，在某些场景下反而比 MQTT 更合适。
多路复用
HTTP/2 最大的改进是多路复用。一个 TCP 连接可以同时处理多个请求，不用像 HTTP/1.1 那样排队。这对边缘网关来说很友好，网关后面可能挂着几十个设备，每个设备都要上报数据。用 HTTP/2，一个连接搞定所有。
服务器推送
服务器可以主动向客户端推送资源。比如边缘节点请求一个配置文件，服务器可以把相关的依赖文件一起推过来，省去客户端多次请求。
二进制分帧
HTTP/2 把消息拆成更小的帧，用二进制编码。解析效率比 HTTP/1.1 的文本协议高得多。在 CPU 资源有限的边缘设备上，这个优势很明显。
我参与过一个视频监控项目，边缘节点需要把抓拍的图片上传到云端做分析。一开始用 HTTP/1.1，每张图片一个连接，连接建立的开销比传输本身还大。后来改成 HTTP/2，多路复用，连接复用率提升了 80%，延迟降低了 40%。
- 边缘网关需要与云端频繁通信
- 设备端有足够的 CPU 和内存（至少几十 MB）
- 需要兼容现有的 RESTful API
3.4 gRPC 在边缘场景的应用
gRPC 是 Google 开源的 RPC 框架，基于 HTTP/2 和 Protocol Buffers。它的特点是高性能、强类型、支持流式通信。
Protocol Buffers 序列化
gRPC 用 Protobuf 做序列化，比 JSON 小 3-10 倍，解析速度快 20-100 倍。在带宽有限的边缘场景里，这个优势是致命的。
四种通信模式
| 模式 | 说明 | 边缘场景举例 |
|---|---|---|
| 一元 RPC | 客户端发一个请求，服务器回一个响应 | 查询设备状态 |
| 服务器流式 | 客户端发一个请求，服务器返回多个响应 | 订阅设备告警 |
| 客户端流式 | 客户端发多个请求，服务器返回一个响应 | 批量上传传感器数据 |
| 双向流式 | 双方同时发送多条消息 | 实时控制与状态同步 |
双向流式通信
这个模式在边缘场景里特别有用。边缘节点和云端可以建立一条长连接，双方随时发消息。不像 MQTT 那样需要 Broker 中转，也不像 HTTP 那样需要轮询。
我曾经做一个工业机器人远程监控项目。机器人每 10 毫秒上报一次关节角度、扭矩等数据，云端需要实时下发控制指令。用 gRPC 双向流，延迟控制在 5 毫秒以内。如果用 MQTT，经过 Broker 中转，延迟至少 20 毫秒，而且 Broker 本身成了瓶颈。
3.5 协议选型对比
| 特性 | MQTT | CoAP | HTTP/2 | gRPC |
|---|---|---|---|---|
| 传输层 | TCP | UDP | TCP | TCP (HTTP/2) |
| 消息模型 | 发布/订阅 | 请求/响应 + 观察者 | 请求/响应 + 推送 | RPC + 流式 |
| 开销 | 低 | 极低 | 中 | 中 |
| 适用设备 | 中等资源 | 极低资源 | 较高资源 | 较高资源 |
| 实时性 | 中 | 中 | 中 | 高 |
| 典型场景 | 传感器数据采集 | 超低功耗节点 | 边缘网关与云端 | 实时控制与同步 |
选协议没有银弹。我的习惯是：
- 设备资源极低（几十 KB 内存）→ CoAP
- 设备资源中等（几百 KB 内存），需要发布/订阅 → MQTT
- 边缘网关与云端通信，需要兼容 REST → HTTP/2
- 需要低延迟、双向流、强类型 → gRPC
你想想看，一个项目里可能同时用多个协议。比如传感器用 CoAP 上报到边缘网关，网关用 MQTT 汇总到本地 Broker，Broker 再用 gRPC 同步到云端。各取所长，才是架构师的智慧。