MQTT 和 HTTP 有什么区别？物联网场景该怎么选？
MQTT 和 HTTP 都跑在应用层，很多时候也都基于 TCP，但它们解决的问题不一样。HTTP 更像一次明确的业务请求：客户端问，服务端答，适合查数据、提交表单、上传文件和调用 REST API。MQTT 更像一个消息中转站：设备把消息发到主题，订阅者按主题接收，发布者不需要知道谁在听。
核心区别是什么？
最明显的区别是通信模型。HTTP 是请求/响应，天然以客户端发起为中心；MQTT 是发布/订阅，Broker 负责路由消息，可以把一条温度数据同时分发给监控面板、告警服务和数据入库服务。
第二个区别是连接方式。HTTP/1.1 可以 Keep-Alive，HTTP/2 也能复用连接，但多数业务仍围绕“请求完成即返回”设计。MQTT 通常保持长连接，通过 Keep Alive 和 PINGREQ/PINGRESP 确认连接还活着，这对设备在线状态和服务端主动下发指令很关键。
第三个区别是报文开销。MQTT 固定头部最小 2 字节，主题和载荷之外的额外开销很小；HTTP 请求头常常包含 Cookie、User-Agent、鉴权头等信息，几百字节很常见。对 4G 模组、NB-IoT、卫星链路或电池供电设备来说，这些差距会直接变成流量费和续航差距。
场景怎么选？
设备遥测、实时状态、告警推送、远程控制更适合 MQTT。例如一万个传感器每 5 秒上报一次温度，用 HTTP 轮询会制造大量连接和请求头开销，用 MQTT 长连接发布到 factory/line1/temperature 更自然。
Web 页面、后台管理、文件上传、复杂查询更适合 HTTP。比如查询某台设备过去 7 天的历史曲线，用 HTTP API 带分页、筛选条件和缓存策略更好维护。实际项目里常见做法是混用：MQTT 负责实时上报和控制，HTTP 负责配置、报表、账号体系和历史查询。
快速验证示例
# 订阅温度主题 mosquitto_sub -h test.mosquitto.org -t 'demo/device1/temp' # 另一个终端发布消息 mosquitto_pub -h test.mosquitto.org -t 'demo/device1/temp' -m '25.6'
# 同样的数据用 HTTP 提交 curl -X POST https://api.example.com/devices/device1/temperature \ -H 'Content-Type: application/json' \ -d '{"value":25.6}'
实战里的判断顺序
选型时不要先问哪个协议更先进，而要先看数据流向、频率和失败后果。若设备每隔几秒上报一次状态，并且平台需要随时下发控制命令，MQTT 的长连接会让链路更简单。若用户只是偶尔打开页面查一次报表，HTTP 的一次请求一次响应更符合直觉，日志、鉴权、缓存和排障工具也更成熟。
还要看团队的运维能力。MQTT 引入 Broker 后，要管理主题命名、ACL、离线消息、会话、重连风暴和保留消息；HTTP 则更多依赖 API 网关、负载均衡和服务端限流。很多项目不是败在协议本身，而是没有提前定义边界：哪些消息必须实时，哪些数据必须可追溯，哪些请求失败后允许重试。
追问
MQTT 一定比 HTTP 更省资源吗？
不一定，要看连接生命周期和消息频率。高频、小包、需要服务端下发的场景，MQTT 的长连接和小头部优势明显。低频操作反而可能是 HTTP 更省心，因为不用维护在线状态、重连和主题权限。踩坑最多的是把所有业务都塞进 MQTT，最后发现查询、分页、审计和重放都比 HTTP 难做。
如果 HTTP 有长连接和 HTTP/2，还需要 MQTT 吗？
HTTP/2 解决的是多路复用和传输效率，不等于提供发布/订阅、QoS、遗嘱消息和主题路由。你可以用 HTTP/2 做实时接口，但服务端主动把消息分发给多个订阅方时，应用层要自己补一套消息系统。边界在于业务是否以“资源访问”为核心，还是以“消息流转”为核心。前者继续用 HTTP，后者更像 MQTT 的主场。
MQTT 的 QoS 能替代业务幂等吗？
不能。QoS 1 只能保证至少送达，重复消息很正常；QoS 2 能减少重复投递，但成本更高，也不能替你处理业务端重复扣费、重复开锁这类问题。实际项目里关键指令仍要带 messageId，并在服务端做去重。取舍是：协议层保证传输语义，业务层保证业务结果。
为什么很多系统同时使用 MQTT 和 HTTP？
因为两者擅长的部分互补。设备上线、心跳、实时数据和控制命令走 MQTT，用户登录、设备列表、固件下载、历史报表走 HTTP，会比单押一种协议更稳。踩坑点是鉴权体系要统一，否则 MQTT 的 ACL 和 HTTP 的用户权限容易出现不一致。通常会用同一套账号或 Token 签发逻辑，再分别落到 Broker 和 API 网关。
MQTT 适合传文件或大报文吗？
一般不推荐。MQTT 可以传二进制载荷，但 Broker、客户端内存、最大报文限制和重传成本都会放大风险。固件包、图片、日志压缩包更适合 HTTP、对象存储或 CDN，MQTT 只通知下载地址和版本号。这个边界很重要，否则一次大文件重传就可能拖垮低端设备或 Broker 队列。