6.5 HTTP 与 HTTPS 在物联网中的角色

6.5 HTTP 与 HTTPS 在物联网中的角色

HTTP 是当今最大的请求响应协议，但它对物联网却常常"贵"：报文头大、一次一问一答耗功耗。本节拆 HTTP/HTTPS 的特点与成本，说明它在物联网里宜当"管理/边缘/浏览器"通道，别把海量传感上报全押在它身上。

读懂"为什么要省着用"

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

1. 说明 HTTP 在物联网场景里的主要开销来自报文头与 TCP 握手。
2. 解释 HTTPS（TLS 加密）对受限设备的内存与时延压力。
3. 判断"设备管理 / 浏览器接入"与"海量传感上报"分别该不该用 HTTP。

一、人人都认得的协议，为什么物联网要省着用

HTTP 统治了 Web，但把一台电池传感器扔给它，就要面对"富家子弟"式的开销。要害在两点：一是报文头臃肿——一个 HTTP 请求动辄几百字节的头部字段，对一条几十字节的传感数据是成倍的浪费；二是每次都要 TCP 握手——一问一答的轮询式上报，握手消耗的功耗与延时远比数据本身多。

另外，开放公网还要用 HTTPS（TLS 加密）。加密带来的握手与运算，在内存几 KB 的芯片上非常吃力，时延与耗电进一步上升。所以对"大量低频上报"的传感终端，HTTP 天生不是好选择——这正是 MQTT/CoAP 这些瘦身协议存在的意义。把"一条传感数据"分别用 HTTP 轮询与 MQTT 长连接去传，报文字节数的悬殊一眼可见：

二、HTTP 真正用得其所的四块地

不是要否定 HTTP——它在物联网里有明确的"正确用武之地"：

• 设备管理 / 配置：数量不大、但要走标准 Web 接口的管理动作，用 HTTP 干净。
• 边缘 / 网关对外：网关向上与云端 REST API 通信，走 HTTP/HTTPS 自然。
• 浏览器直连：管理后台、可视化面板天然是浏览器，免不了 HTTP 那一套。
• 少量低频的轻指令：偶尔一条不痛不痒的请求，HTTP 也能应付。

换句话说，HTTP 适合"人、网页、管理、低频指令"这一端；真正的大头上报，另请 MQTT/CoAP。

三、能耗账簿：HTTP vs MQTT 的对比

四、一次"别把 HTTP 用错地方"的复盘

某团队给一批户外计算器项目做上报，最初图省事直接用 HTTPS 轮询每 5 分钟上报一次。结果设备电池快速耗尽、还经常因弱网重传丢数据。复盘发现：轮询 + HTTPS 的握手与头部开销，把"极简传感上报"做成了一场功耗灾难。改成 MQTT 长连接后，报文瘦、连接复用、功耗大降，寿命恢复预期。教训正是本章主题：HTTP 的"通用方便"换不来物联网的"省"，选协议要按载荷想。

五、HTTPS 的一笔握手账：为什么受限设备最怕它

HTTPS 对物联网最大的隐性负担其实不是加密运算本身，而是 TLS 握手要来回好几趟。一次完整的 TLS 1.2 握手客户端与服务端要交换密钥协商、证书、完成确认等至少 2 个往返（wan RTT 在弱网上尤其疼）；TLS 1.3 收敛到 1 个往返，是明显进步，但代价是设备必须支持新版本、且仍需维护连接。

把这笔账放到"每次上报都重连"的场景看：设备上一次报，先建 TCP、再走 TLS 握手、再发数据，三次往返里数据占比极低。这也是为什么"用 HTTPS 轮询上报"对低功耗传感是灾难——连接建立的开销被反复支付。省电的做法是把长时间连接一次建好（如 MQTT over TLS），或把上报转到不依赖费时握手的 CoAP/DTLS。

另外别忽略证书轮换：HTTPS 的证书有有效期，到期要换。物联网设备没法像浏览器那样自动更新，若证书轮换通道没设计好，一批设备会在某天集体"加密握手失败"。高可靠部署通常要规划好证书注入与轮换机制，而不是一次烧片就当甩手掌柜。加密是对的，但这份"对"必须在受限铁链里被精打细算地落地。

六、一套"内网明文管理 + 上报走 MQTT"的真实拆分

把 HTTP 用得其所，最好的示范是一套成熟的传感器网关管理方案拆两半：

• 网关对外与云端之间：走 MQTT（broker 上云、长连接、省耗），扛住海量上报与下行指令。
• 网关上对内、供运维人员浏览器管理的那一侧：走 HTTP/HTTPS REST——管理员浏览器直接调，改配置、看状态、刷日志，天然契合。

这套拆分的聪明之处在于：把"高并发、必须省"的链路交给 MQTT，把"低频、人要碰"的链路交给 HTTP，各用其对。若反过来——拿 HTTP 做海量上报、拿 MQTT 做给人看的页面——两边都拧巴。这套"上报 MQTT + 管理 HTTP"的模板，几乎对所有网关类设备都能直接照搬，是你判断 HTTP 该在哪的标准答案。

七、该用 HTTP 时，它一样是好手

说了这么多"别乱用"，也该还 HTTP 一个公道：在它该出现的地方，它是无可替代的顺手工具。举两个"非它不可"的时刻：

• 一套现成的 Web 管理后台：管理员要在浏览器里点按钮配设备、看状态，几乎没有比 HTTP/REST 更自然的方式。别的协议还得自建一套 UI 通道，HTTP 直接搭上浏览器生态就能跑。
• 边缘网关与云端 REST API 对接：很多云平台开放的就是 HTTP/HTTPS 接口。边缘网关把本地汇聚的结果封装成一个 HTTP 调用交上去，跟第三方系统握手最顺，不需要搬一整套 broker。

换句话说，判断该不该用 HTTP，看的是"这一端是否天然是 Web/浏览器/管理"。是——HTTP 是主场；否（海量传感上报）——就把它放回工具箱，请 MQTT/CoAP 上场。别再让"人人会 HTTP"成为你给海量设备也硬套 HTTP 的理由。

八、HTTPS 的一笔诚实账

如果确定要用 HTTP，多半还得加 HTTPS 加密，这笔账也要算清楚：

明文 HTTP    简单，但数据裸露，只适合内网/可信链路
HTTPS(TLS)   多一次握手 + 证书校验，芯片内存小时延与耗电上升
一句话取舍    对外公网 → 必须 HTTPS；本地支架/调试 → 可先用明文
​

一句话记住：明文能省，但省在"内网无关痛痒"的场景里才划算；但凡过公网、碰敏感指令，一律上 HTTPS——为省内存与时延而裸奔，往往是事故的开端。

九、两种"反直觉"但该用的 HTTP 时点

谈了不少"别拿 HTTP 扛大上传"，但有两处反直觉的场景，HTTP 反而是值得主动选的：

• 设备的一次性 OTA 激活/上报大文件：设备新装好、一次性要拉下较大的配置包或升级包时，用一次 HTTP 下载往往比长期 MQTT 会话更简单——这种低频、大块、不频繁的数据，正好填满"HTTP 头部大但一次值回票价"的缝隙，干完断连，不拖累平时的省电节奏。
• 边缘节点的引导配置态：很多网关在"首次上电配置"阶段没有云端会话，只有本地 HTTP 服务供部署人员网页配置；等配置完切到 MQTT 主业务。这一个"引导态用 HTTP、运行态用 MQTT"的转换，正是 HTTP 该出现的位置。

总结下来，HTTP 的价值从来不是替代那些瘦协议，而是找准"低频、大块、人要碰、一次性"这几个字眼下的位置。把"何时必须上 HTTP"和"何时千万别上 HTTP"两张清单摆在一起，你用它就不会再拧巴。

本节要点回顾

• HTTP 两贵：头部臃肿 + 每次握手，拖推传感上报的功耗与时延。
• HTTPS 更重：TLS 握手与运算在受限芯片上是负担。
• 四块飞镖：管理、网关、浏览器、低频指令才值得用 HTTP。
• 能耗对比：长连接 MQTT 比轮询 HTTP 更省，数据见高下。
• 复盘教训：海量传感别押 HTTP，按载荷想协议。

应用层几家说完了，可协议要落地还得靠下层撑腰。最后一节，看 IPv4/IPv6 与 TCP/UDP 这对"承上启下"的底料怎么服务物联网。