MQTT实战 - MQTT vs HTTP：为什么你的物联网项目上线就崩？（二）

01、适配业务场景的协议才是好协议

很多物联网团队做原型阶段，图简单直接选用HTTP做设备接入。Demo环境下三五个设备跑的非常顺畅，接口调通，数据正常上报。

一旦批量投产，接入几百、上千台4G/NB‑IoT设备之后，各种灾难接踵而至：服务器CPU打满、接口大量超时、设备电池快速耗尽、网络故障恢复瞬间出现请求风暴、指令下发延迟严重。

我见过不止一个项目：原型用HTTP快速做完，上线之后扛不住设备规模，不得不整体重构接入层，付出巨大返工成本。

但我并不想直接下结论：HTTP就是垃圾，全部项目必须上MQTT。

8年物联网实战告诉我：没有绝对最好的协议，只有适配业务场景的协议。HTTP在物联网里面依然有大量适合的场景。真正坑人的，是把HTTP用在了它不擅长的设备长连接、高频上报、双向指令下发场景。

本文站在.NET物联网后端视角，对比MQTT与HTTP真实生产表现，拆解很多项目上线就崩的底层原因，同时给出可直接套用的选型决策标准。

02、测试环境给了你四个"错觉"

很多人做物联网开发都是Web后端出身，对HTTP太熟悉了——熟悉到会下意识地拿它套所有场景。

测试环境下这四个错觉，你八成也犯过。

‌错觉一："设备会乖乖等我来拿数据"——这是轮询的原罪。‌

HTTP是‌请求-响应‌模型，设备端不能主动推，只能设备主动问、或者你去轮询设备。你想想：你不知道水表什么时候有水，就每30秒去问一次"有数据吗"，问了 99 次都是空，第100次才有。这99次全是白问的。到了上千台设备，这些"白问"的请求会把服务端活活累死。

‌错觉二："多几百字节的 HTTP头算什么"——代价在窄带网络上被放大一百倍。‌

一条HTTP请求，光Header（Host、User-Agent、Content-Type、Cookie……）就动辄几百字节。而MQTT的最小报文头‌只有2个字节‌。看似都是"发个温度值"，一个在宽带上看毫无区别，一个在4G/NB-IoT/LoRa 这种按流量计费、按毫安计电的链路上，就是压垮设备的那根稻草。

‌错觉三："网络总是稳定的"——HTTP 一断，数据就没了。‌

测试环境里的网络是你公司机房的网络，稳得很。现场呢?工地的光纤会割接、地库没信号、山区基站会飘——HTTP这种短连接一断，这次请求直接失败，数据要么丢，要么等你重试。而MQTT用的是‌长连接‌，还天生带QoS和离线消息暂存，断了能补。

‌错觉四："设备插着电呢"——电池设备经不起HTTP折腾。‌

一个插在插座上的设备，怎么发都无所谓。但物联网里大量是电池供电的传感器。每发一次HTTP就要建连、握手、发完断开，射频模块的耗电是持续保持一条 MQTT 长连接的‌数倍‌。很多团队上线后才发现，标称一年的电池三个月就没电，回头改协议已经晚了。

03、HTTP在物联网里到底哪里"水土不服"？

HTTP是互联网上最伟大的协议，但它天生就不是为"海量设备持续通信"设计的。

下面这5个问题，每一个我都亲自踩过。不是理论推演，是生产环境里的真实故障复盘。

崩点1：连接开销——每个请求都是一次"重新握手"

HTTP是请求/响应模型。每次上报数据，设备都要走一遍完整流程：

• TCP三次握手

• TLS握手（如果用HTTPS）

• 发送请求头（通常500–1000字节）

• 发送数据

• 等服务端响应

• 四次挥手断开

我们来算一下：

一台设备每分钟上报一次，一天就是1440次完整握手。

200台设备 × 1440次 = 每天28.8万次TCP连接建立+销毁。

服务器不是被数据打垮的，是被连接开销打垮的。

我做过实测对比（同配置云服务器，2核4G，2000台设备并发场景）：

说明：HTTP短连接模式下，大量设备周期性上报会产生海量TCP握手与释放，CPU与内存资源被连接管理大量消耗；MQTT依靠常驻长连接，仅在设备首次上线建立连接，后续依靠心跳保活，服务器资源消耗远低于HTTP。

HTTP 的CPU占用是 MQTT 的5–10倍，而且随着设备数量增加，HTTP是线性增长，MQTT 几乎不变。

MQTT 怎么解决的？ 一条TCP长连接，保持几小时甚至几天。设备连上Broker后，连接一直开着，有数据就发，没数据就心跳保活。

崩点 2：服务端主动下发——HTTP 做不到"推"

物联网场景里，后端经常要主动发指令给设备：

• 大棚温度超过35度，后台要下发"打开通风"指令

• 智能门锁收到访客请求，后台要下发"临时开锁密码"

• 工业设备异常，后台要下发"停机保护"指令

用HTTP怎么做？两个方案都是死路：

方案 A：设备轮询

2000台设备，每10秒轮询一次 = 每分钟12万次 HTTP 请求。服务器光是处理这些空轮询就累死了，而且指令延迟最高10秒。

99%的轮询返回"没有指令"，网络带宽和服务器CPU全浪费在空轮询上。

方案 B：长轮询（Long Polling）

设备发请求，服务器有指令才返回。但问题是：

• 连接挂着不释放，2000台 = 2000个长连接

• 指令延迟取决于轮询间隔，做不到实时

• 实现复杂度比 MQTT 还高

MQTT 怎么做的？ 发布/订阅模型。设备订阅一个Topic，比如device/001/command。后端要发指令时，往这个Topic发一条消息，Broker自动推送给设备。

不需要轮询，不需要设备暴露接口，不需要知道设备IP。一条消息，毫秒级到达。

崩点 3：弱网环境下的重连风暴

物联网设备的网络环境，比互联网应用恶劣 100 倍：

• 4G 信号时有时无

• WiFi 穿墙后衰减严重

• 设备进入电梯、地下室，直接断网

• 工业现场电磁干扰，网络闪断

• 地下停车场（信号差），断连频率5–10分钟一次

真实案例： 某共享设备项目用HTTP，设备装在地下停车场（信号差），断连频率5–10分钟一次。TLS 握手叠加重连风暴，服务器CPU直接跑满。

更麻烦的是 NAT穿透问题。很多物联网设备跑在 4G/NB-IoT上，运营商的 NAT 超时通常只有 30–60 秒。HTTP 短连接每次都要重新三次握手，在弱网环境下握手失败率极高。

MQTT 的重连机制：

• 已有会话（Clean Session = false）：重连后从上次断开的地方继续，不需要重新订阅、不需要重新鉴权

• Keep-Alive 心跳：建议设 30 秒，小于 NAT 超时，能稳定维持连接不中断

• QoS 1/2：消息至少送达一次，网络恢复后自动补发

• Session 持久化：设备断网期间，Broker 把消息存起来，设备重连后一次性推送

• 遗嘱消息（LWT）：设备异常断网时，Broker 自动通知后端"这台设备离线了"

崩点 4：HTTP 的"重试风暴"，能把服务器打崩

HTTP请求失败了，怎么办？重试。设备端通常会这样写：

看起来没问题？但如果是 2000 台设备同时重试 呢？

服务器因为某个Bug返回了500错误，2000台设备同时收到错误，同时等待1秒，同时再次发起请求……这就是 DDOS 攻击的雏形。

MQTT的重连机制是内置的，而且Broker会控制重连速率（比如指数退避），不会因为设备集体重连就把服务打崩。

崩点 5：无状态 = 掉线即失联

HTTP服务器不知道设备什么时候掉线的。设备断电、SIM卡欠费、信号消失——服务端毫无感知，直到下次轮询超时才发现，可能已经过去几分钟。

在告警场景下，这个延迟是致命的：

假设你要实现"设备温度超过40°C立即告警"。

• HTTP 方案：设备每30秒POST一次温度。最坏情况下，告警延迟接近30秒。如果想降到5秒延迟,那边POST频率就要增加6倍，500台设备每分钟就是6000个请求——服务器和运营商流量费一起炸。

• MQTT 方案：设备订阅device/{id}/command主题，温度超阈值时立即发布一条消息到device/{id}/alarm，服务端毫秒级收到。零轮询，零浪费。

MQTT 的遗嘱消息（Last Will）机制 解决了这个问题：设备连接时预先注册一条"我离线了"的消息，一旦异常断线，Broker 自动替它发布。服务端秒级感知，告警、工单、运维通知全部自动触发。

崩点 6：HTTP 报文太大，浪费流量和电量

HTTP请求头有多大？随便一个POST请求，Header就有几百字节：

Header 占了 200+ 字节，实际数据只有 45 字节。有效载荷比例不到 20%。

对于用 4G 流量卡、电池供电的传感器来说，这意味着：

• 流量费翻倍

• 电池消耗翻倍

• 通信成本翻倍

MQTT 报文呢？最小只有 2 字节头部。一条温度上报消息，总共不到 50 字节，比 HTTP 节省 80% 以上。

五个崩点速查

物联网设备接入常见故障点，原型正常，规模上来就暴露问题

一句话总结： HTTP 是"问一次答一次"的邮局模式，MQTT 是"拨通后一直聊"的电话模式。在设备量大、频率高、网络差的物联网场景里，HTTP 的每一个设计假设都在变成负担。

HTTP短连接在设备规模上涨后，连接、推送、重连、重试、报文五大问题集中爆发；MQTT长连接模型从协议层面规避以上问题。

04、核心差异：MQTT 和 HTTP 的本质区别

理解MQTT和HTTP的差异，不能只看“哪个快”，而要看它们各自为什么被设计成这样。

HTTP诞生于1990年代，解决的是“浏览器怎么从服务器获取网页”的问题。它的核心模型是请求/响应——客户端主动发起请求，服务器被动响应，然后连接关闭。这个模型对于“用户点一下、服务器返回一个页面”的场景是完美的。

MQTT诞生于1999年，最初是为石油管道遥测设计的。它的核心模型是发布/订阅——设备与Broker建立一次长连接后，通过Topic进行消息路由。发布者不需要知道谁在接收，订阅者也不需要知道谁在发送。

这两种模型在物联网场景下的差异，可以用一个类比来理解：

HTTP就像寄信。 你要先跑到邮局（建立连接），填好信封（携带头部信息），把信寄出去（发送请求），然后回家等回信（等待响应）。每寄一封信，都要重复这个过程。如果你想频繁收到信，只能每隔一段时间跑去邮局问“有我的信吗”（轮询）。

MQTT就像打电话。 你拨通一次（建立连接），之后双方可以随时说话。你不用每次说话都重新拨号，对方也可以主动告诉你消息，不需要你反复问。

这个差异带来的最直接后果是：HTTP的服务端无法主动推送消息给设备。在物联网场景里，“平台下发指令给设备”是一个极高频的需求，HTTP只能靠设备轮询来实现，而轮询的延迟和资源浪费是致命的。

05、MQTT 与 HTTP 核心维度对比表

该对比表可用于方案评审、技术选型，附带业务实际影响说明。

我们再来看几组来自实测的数据，这些数据直接解释了为什么HTTP在物联网场景下“扛不住”。

协议头开销：2字节 vs 247字节

这是最直观的差异。MQTT的固定报头最小只有2字节，而HTTP的请求头即使是最简单的GET请求，也至少几百字节。

一项针对智能交通系统的微服务架构研究实测了两种协议的头部大小：MQTT为2字节，HTTP为247字节。这意味着，每传输一次数据，HTTP要多消耗100倍以上的头部开销。

对于传感器每5秒上报一次温度的场景，一个JSON数据包本身可能只有50字节。用HTTP传输，实际网络流量是50+247=297字节，有效率只有17%。用MQTT传输，实际流量是50+2=52字节，有效率超过96%。

可靠性：91.88% vs 81.06%

一项在真实农业物联网环境中进行的对比研究，用54小时同时采集了HTTP和MQTT的传输数据。结果：

MQTT的可靠性比HTTP高出10个百分点以上，延迟只有HTTP的四分之一，带宽效率高出近7倍。

另一项针对智能交通系统的研究给出了更极致的数字：MQTT的送达可靠性达到99.97%，而HTTP为99.89%，低于99.9%的SLA要求。该研究明确指出，HTTP“勉强低于”工业级SLA标准，因此架构决策是将主要传感器流量路由到MQTT，HTTP仅保留用于遗留系统集成。

延迟：63ms vs 1419ms

在ESP32微控制器上的实测数据更为惊人。研究者对比了三种协议在16、64、256字节三种传输大小下的延迟表现：

• MQTT平均延迟：63毫秒

• HTTP平均延迟：1419毫秒

差距超过20倍。即使在性能更强的ESP32-S3上，HTTP的延迟也有449毫秒，而MQTT仍然保持在更低水平。

能耗：MQTT比HTTP省20%

法国的一项博士论文专门对比了MQTT和HTTP在物联网设备上的能耗表现。结论是：在发布/订阅模式下，MQTT比HTTP的能耗开销低约20%。

更关键的是，该研究还发现：发布/订阅模式比请求/响应模式平均节省92%的能耗。这意味着，即使不看协议本身的差异，仅仅是把HTTP轮询改成MQTT订阅，就能带来一个数量级的能耗优化。

对于电池供电的传感器设备，这个差异直接决定了设备能跑一个月还是一年。

06、什么时候用MQTT，什么时候用HTTP

规则：从第一个问题开始，顺着箭头走，命中任何一个✅是就直接停止判断；全部走完均为否，执行兜底方案。

汇总速查表（一图带走）

该表可用于立项评审快速筛选：首选✅ /备选 /一票否决❌；"—"代表无合适备选/无否决项。

补充说明：
1、一票否决代表该需求场景不建议使用此协议，不是协议本身有Bug，是业务场景下代价巨大；
2、工程最佳实践：推荐混合架构，设备遥测指令走MQTT，文件、第三方对接走HTTP；
3、Web端大屏优先WebSocket/MQTToverWebSocket，不要浏览器直连Broker 1883端口。

高危组合（踩坑重灾区，看到请绕道）

该表可用于评审风险检查，当出现以下组合需要重点拦截，各种组合均来自线上真实故障案例。

风险提示：上表为项目评审检查项，出现高危组合不代表一定马上故障，但设备规模上涨、网络变差后故障必然爆发。

现实项目最佳实践：混合架构（不是二选一）

工程上适合才最重要。成熟的物联网平台，从来不是"全 MQTT"或"全 HTTP"，而是各司其职。

混合架构分工：不同业务职责对应最合适协议，生产项目不要单一协议包打天下。

一句话总结：

• 设备多、要推送、网络差、频率高 → MQTT

• 设备少、纯上报、网络好、频率低 → HTTP

• 两者都不完全符合 → 优先考虑MQTT（扩展性更好）

很多新手会陷入非黑即白思维：要么全部 MQTT，要么全部 HTTP。工程上，适合才最重要。真正的经验是：‌别在项目中期才想起换协议，那叫返工；一开始就想清楚什么数据走哪条路，那叫架构。‌

真实项目对比：同一个项目，HTTP vs MQTT

我 2019 年做过一个对比测试，同一个智慧楼宇项目：

服务器成本降了 60%，延迟降了一个数量级。

07、写在最后：选型错了，代价不只是技术债

如果我们在架构设计阶段，就意识到"2000台设备持续上报"这个场景不适合HTTP，选择MQTT作为接入协议，整个项目的走向会完全不同。

选错协议的代价，不只是技术债，是时间、金钱、团队士气和客户信任。

这也是为什么我把这篇文章放在系列的第2篇。在你开始写任何MQTT代码之前，请先确认：你的场景，真的适合MQTT吗？ 如果适合，请继续往下看。如果不适合，用HTTP也挺好，别硬上。

选型的核心不是“谁更好”，而是“谁更适合”。

08、最后

我整理了一份《物联网通信协议选型对比表》和《物联网通信协议选型深度对比总表》，包含：

• 11 种协议的完整对比（MQTT / HTTP / WebSocket / CoAP / Modbus / AMQP / QUIC / LwM2M / OPC UA / TCP 私有 / UDP 私有）

• 20 个核心维度逐项拆解（通信模型、报文开销、实时性、功耗、连接数、安全、生态、离线消息、遗嘱消息等）

• 实测性能数据（2000 台设备下 MQTT vs HTTP 的 CPU、内存、连接数对比，差距 5–10 倍）

• 一张选型决策树（8 步定位，从设备条件直接推到该用哪个协议）

• 4 套混合架构模板 + 6 大选型误区避坑清单（含高危组合提醒）

私信「IoT协议选型表」直接领取，无套路。

做物联网 MQTT 的朋友可以一起交流。后面我会在这个号持续更新这个系列，也会穿插一些软考架构师备考、技术管理转型、嵌入式学习的记录。

我是【IT规划师】，8 年 .NET 物联网后端，正在从纯后端往软硬融合架构师的方向走。这条路不容易，但值得。

注： 测试方法代码以及示例源码都已经上传至代码库，有兴趣的可以看看。https://gitee.com/hugogoos/Planner