4、HTTP的痛点：高功耗、实时性差、头部开销大、服务端推送困难

聊完MQTT和CoAP，咱们再来看看HTTP。说实话，HTTP在物联网场景里，真的有点「水土不服」。它本来是给Web页面设计的，你想想看，浏览器加载个网页，几百毫秒的延迟用户都能忍。但物联网设备不一样，传感器节点、智能门锁、温控器，这些玩意儿对功耗和实时性要求极高。HTTP那套「请求-响应」模型，放在这里，问题就全暴露了。

4.1 高功耗：一次请求，半管电没了

我个人习惯把HTTP比作「大胃王」。它每次通信，都要建立TCP连接，三次握手、四次挥手，再加上TLS加密握手，这一套流程下来，电量消耗相当可观。

为什么会这样？

• TCP连接开销：每次HTTP请求，都得先建立TCP连接。对于电池供电的传感器，这简直是噩梦。我记得有个项目，用的是ESP8266上报温度数据，用HTTP轮询，结果电池撑了不到两周就挂了。换成MQTT后，同样的电池撑了三个月。
• TLS加密开销：现在都要求HTTPS，但TLS握手过程需要多次往返，计算量也大。低功耗MCU做一次TLS握手，CPU得全速跑好几秒，功耗直接飙升。
• 长连接保活：有人会说「我用HTTP长连接（Keep-Alive）」。但长连接需要心跳保活，设备得定期发心跳包，这本身也在耗电。而且运营商NAT超时时间短，长连接经常断，断了又得重连，更费电。

4.2 实时性差：轮询的痛，谁用谁知道

HTTP是典型的「客户端主动拉取」模式。设备想获取最新数据，只能不停地轮询服务器。这带来了两个问题：

• 延迟不可控：轮询间隔设短了，功耗高；设长了，实时性差。比如智能门锁，你希望门被打开后，手机能立刻收到通知。用HTTP轮询，假设间隔5秒，那最坏情况下，你得等5秒才知道门开了。这体验能好吗？
• 无效请求太多：大部分轮询请求，服务器返回的都是「没有新数据」。这些请求白白浪费了带宽和电量。我在项目中遇到过，一个设备管理平台，用HTTP轮询，高峰期每秒几万次请求，服务器CPU直接打满，其实90%的请求都是无效的。

4.3 头部开销大：一个数据包，半包是头

HTTP的头部是纯文本的，而且非常臃肿。一个简单的GET请求，头部可能就有几百字节。你想想看，传感器上报的数据可能就几个字节（比如温度25.3°C），但HTTP头部占了200多字节，这效率太低了。

具体对比一下：

协议	典型头部大小	数据载荷	传输效率
HTTP/1.1	200-800 字节	10 字节	极低
CoAP	4 字节	10 字节	高
MQTT	2-14 字节	10 字节	高

你看，HTTP的头部开销是CoAP和MQTT的几十倍甚至上百倍。在NB-IoT、LoRa这类低带宽、低速率网络里，这种浪费是致命的。说白了，你花同样的流量费，HTTP只能传几条数据，CoAP能传几百条。

4.4 服务端推送困难：HTTP天生「不会说话」

这是HTTP最大的硬伤。HTTP是「请求-响应」模型，服务器不能主动给客户端发数据。客户端不发请求，服务器就只能干等着。

那怎么办？

• 轮询：前面说了，实时性差、功耗高。
• 长轮询（Long Polling）：客户端发请求，服务器hold住连接，直到有新数据才返回。这看起来解决了实时性问题，但服务器需要维护大量长连接，资源消耗巨大。而且，如果网络不稳定，连接断了，客户端还得重新建立。
• Server-Sent Events (SSE)：这是HTML5的标准，服务器可以主动推送事件。但它基于HTTP长连接，而且只支持文本数据，浏览器兼容性也一般。在嵌入式设备上，SSE的支持非常有限。
• WebSocket：这其实已经不是HTTP了，它是在HTTP握手后升级到WebSocket协议。虽然能实现双向通信，但WebSocket的握手开销和头部开销依然不小，而且很多物联网网关和防火墙对WebSocket的支持并不好。

所以，如果你需要服务器主动下发控制指令（比如远程开锁、调整温度），HTTP基本没法用。你想想看，智能灯泡，你希望手机一点「关灯」，灯泡立刻灭。用HTTP轮询？那得等好几秒。用WebSocket？又太重了。这时候，MQTT的发布/订阅模型，才是正解。

小结

HTTP的四个痛点，说白了就是：费电、太慢、太胖、太被动。在物联网这个讲究「低功耗、低带宽、高实时」的领域，HTTP确实不太够用。当然，它也不是一无是处，比如在设备配置、固件升级、管理API这些场景，HTTP依然有它的用武之地。但如果你要做的是传感器数据上报、设备控制、实时告警，嗯，我建议你直接跳过HTTP，看看MQTT和CoAP。