局限来自哪里
HTTP 为通用 Web 场景设计：头部是文本、交互由客户端发起、连接按请求使用。放到成千上万台设备上，问题集中在三处——设备侧要维持可达的服务端连接或频繁轮询，每次交互都带一份体积不小的头部，服务端无法主动推送而只能依靠长轮询或连接升级。
局限与缓解对照
| 局限 | 表现 | 缓解方向 |
|---|---|---|
| 头部冗余 | 小载荷报文里头部占比过半 | 压缩头部、减少交互次数、改用二进制协议 |
| 缺少原生推送 | 只能轮询或长轮询 | 升级为长连接或引入消息协议 |
| 连接管理成本 | 连接数与文件描述符成为瓶颈 | 连接复用、网关收敛、分层部署 |
| 轮询耗电 | 固定间隔请求持续唤醒设备 | 拉长间隔、改变化上报、改用推送 |
| 同连接排队 | 大响应拖慢后续请求 | 改用支持多路复用的版本或分解资源 |
典型使用场景
- 低频配置查询：交互很少时保留 HTTP 的成本最低
- 设备侧已有成熟 HTTP 栈：改协议的收益不足以覆盖改造成本
- 平台已就绪：服务端接口与运维工具链已经基于 HTTP 建成
- 内网设备管理：网络稳定且设备数量可控，轮询代价可以接受
设备侧既然能跑 HTTP，通常也具备改用更轻协议的条件；选择保留 HTTP 往往是因为生态、调试便利或服务端已就绪，这是合理的取舍，但要把规模上限写进设计文档。
用短轮询实现准实时是设备规模增长后最先崩掉的环节：流量、耗电与服务端连接数都会随设备数量线性上升。