2. 接入协议选型与优化
IoT 云平台的高并发接入瓶颈，往往不在服务器 CPU，而在协议本身带来的连接状态、握手开销与报文效率。选错协议，后续再堆机器也很难把单节点并发从 5 万推到 50 万。本节围绕 MQTT、CoAP、HTTP/2 三种主流接入协议，从连接模型、报文开销、QoS 语义、并发承载能力四个维度展开对比，并给出一套可落地的选型决策方法。
一、三种协议的连接模型差异
MQTT 基于 TCP，采用发布/订阅模型。设备与 Broker 建立一条长连接后，通过 Topic 进行消息路由。它的核心优势是：一条连接可承载多主题、双向通信、服务端可主动下发。代价是 Broker 需要为每个客户端维护会话状态（ClientID、订阅关系、QoS 消息队列、遗嘱消息），单连接内存占用通常在 10～50 KB 量级。
CoAP 基于 UDP，采用请求/响应模型，语义上对标 HTTP，但报文是二进制、头部仅 4 字节固定字段。它天然适合受限设备（NB-IoT、LoRa 模组），支持 Observe 机制实现服务端推送。由于无连接，CoAP 在高并发下不占用服务端连接表，但需要处理重传、去重与 DTLS 会话管理。
HTTP/2 基于 TCP，通过多路复用（Multiplexing）在单条连接上并行多个 Stream，解决了 HTTP/1.1 队头阻塞问题。它适合设备主动上报、固件下载、REST 风格接口，但服务端无法主动推送（Server Push 已被主流浏览器弃用），且每个请求仍需完整的头部压缩与流管理。
二、高并发场景下的关键参数对比
把三种协议放到同一台 8 核 16 GB 的接入节点上做容量估算，差异非常直观。以下参数为教学示例假设，用于说明量级关系，不代表任何具体产品的实测值。
| 对比维度 | MQTT | CoAP | HTTP/2 |
|---|---|---|---|
| 传输层 | TCP | UDP | TCP |
| 单连接内存占用 | 约 20 KB | 约 2 KB（DTLS 会话） | 约 30 KB（含流状态） |
| 典型心跳间隔 | 60 s（Keep Alive） | 无心跳，靠 Observe 刷新 | 无心跳，靠 TCP Keepalive |
| 下行推送能力 | 强（订阅即推送） | 中（Observe 资源） | 弱（需轮询或长轮询） |
| 单节点连接上限（示例） | 约 50 万 | 约 80 万（无 DTLS） | 约 20 万 |
| 消息时延（同机房） | 5～20 ms | 10～50 ms | 20～100 ms |
从表中可以看出：CoAP 在连接密度上占优，但下行控制能力弱；MQTT 在双向通信与连接密度之间取得平衡；HTTP/2 连接密度最低，但胜在生态成熟、调试方便、与现有 Web 基础设施兼容。
三、选型决策方法：四步过滤法
面对具体项目，不要凭直觉选协议。建议按以下四步过滤，每一步都会淘汰掉不合适的选项。
第一步：看设备侧约束。如果设备是 NB-IoT 模组、内存小于 64 KB、电池供电且要求 5 年以上寿命，CoAP 几乎是唯一选择——UDP 无连接、报文极小、支持 DTLS 省电模式。如果设备是常供电的网关或车机，MQTT 和 HTTP/2 都可以进入下一轮。
第二步：看通信方向。如果业务需要服务端主动下发指令（如远程开关、参数下发、OTA 触发），MQTT 的订阅推送是最自然的方案。HTTP/2 需要设备轮询，在百万级设备下轮询风暴会直接压垮接入层。CoAP 的 Observe 可以推送，但只适用于资源状态变化，不适合任意指令通道。
第三步：看消息可靠性要求。如果消息不能丢（如计费、告警），MQTT QoS 1 或 CoAP CON 消息是必要的。HTTP/2 依赖 TCP 保证传输可靠，但应用层仍需 ACK 机制确认业务处理成功。如果允许少量丢失（如周期性传感器读数），QoS 0 或 NON 消息可以大幅降低开销。
第四步：看运维与生态。如果团队已有成熟的 HTTP 网关、负载均衡、鉴权体系，HTTP/2 的接入成本最低。MQTT 需要部署 Broker 集群（如 EMQX、HiveMQ），并考虑会话持久化与桥接。CoAP 需要处理 UDP 穿透、DTLS 证书管理，运维复杂度最高。
四、高并发下的协议优化要点
选定协议后，还需要针对高并发做参数调优。以下是三种协议各自最关键的优化项。
MQTT 优化：调整 max_connections 与文件描述符上限；开启 session_expiry_interval 避免离线消息无限堆积；对 QoS 1 消息设置合理的 inflight_window（如 32），防止单连接阻塞；使用共享订阅（$share/）分摊消费者压力。
CoAP 优化：启用 NSTART 参数控制并发重传数；对 Observe 通知设置 Max-Age 与 Observe 序号回绕处理；DTLS 使用会话复用（Session Resumption）减少握手开销；对 NON 消息设置合理的重传超时与最大重传次数。
HTTP/2 优化：调整 SETTINGS_MAX_CONCURRENT_STREAMS（如 128）与 INITIAL_WINDOW_SIZE；开启 HPACK 动态表以压缩重复头部；对固件下载使用 PRIORITY 帧标记高优先级流；在接入层前置 TLS 卸载，减少握手 CPU 开销。
# MQTT Broker 关键并发参数示例（EMQX 风格）
listener.tcp.external.max_connections = 1000000
listener.tcp.external.acceptors = 64
zone.external.max_inflight = 32
zone.external.session_expiry_interval = 2h
zone.external.max_mqueue_len = 1000
# CoAP 服务端关键参数示例
coap.max_transmit_span = 45s
coap.ack_timeout = 2s
coap.nstart = 1
coap.observe_max_age = 60s
# HTTP/2 服务端关键参数示例（Nginx 风格）
http2_max_concurrent_streams 128;
http2_initial_window_size 65535;
http2_recv_buffer_size 256k;
五、一个混合接入的决策示例
假设某智慧园区项目：2000 个电表通过 NB-IoT 上报，500 个摄像头通过 4G 网关回传视频，50 个边缘网关需要接收云端下发的 AI 模型更新。按四步过滤法：
- 电表：受限设备 + 周期性上报 → CoAP，Observe 上报电量，NON 消息容忍偶发丢失。
- 摄像头：主动上报 + 大流量 → HTTP/2，多路复用上传视频片段，HPACK 压缩元数据。
- 边缘网关：需下行控制 + 可靠传输 → MQTT，QoS 1 接收模型更新指令，共享订阅分摊推送。
最终接入层同时暴露 CoAP、HTTP/2、MQTT 三个端点，由设备按自身能力选择。统一在网关层做协议转换与消息归一化，后端只处理标准化的设备事件流。这样既发挥了各协议的优势，又避免了单一协议在混合场景下的短板。