上家公司中前端项目有用MQTT协议和硬件通信的场景，虽然很早就听说过MQTT协议，但是这是第一次在前端项目里基于MQTT协议做网络通信。当时没了解太多，工作中只做好了代码层面的工作，并没有深入了解MQTT协议的好处和适合的应用场景。

在前端项目中，应该99%的情况都会基于HTTP和WebSocket来进行网络通信，使用MQTT在前端里确实比较小众。

目前可能只会在物联网项目中，需要跟硬件通信的前提下，前端才会有MQTT协议的选项。

我搜罗了一些资料来了解这样做的好处。

轻量级 & 低带宽消耗

前端项目里，在绝大多数的情况下，业务场景都是去跟服务端通信，服务端理论上是可以无限扩展的。但是如果通信对象是一个设备参数固定的硬件，其实是不具备扩展能力的。

所以轻量级和低消耗很关键。

• ​协议开销极小： MQTT报文头仅2字节，远低于HTTP的冗长Header，适合硬件资源（CPU、内存）有限的设备。
• 节省流量： 对网络带宽要求低，尤其适用于NB-IoT、LoRa等低功耗广域网络。

发布/订阅模型

HTTP协议是基于请求/响应的设计，每次请求都应该立即得到相应的响应，完整的【请求参数+响应结果】才算一次完整的通信。

WebSocket协议是基于长连接且全双工通信的设计，通信的双方在建立长连接后，可以由任何一方进行消息的发送。

MQTT协议在WebSocket的长连接 + 全双工通信的基础上，使用了发布/订阅的模式。

• 解耦通信双方： 硬件只需向Topic发布消息，无需感知订阅者（如Web前端、其他设备），扩展性强。
• 一对多广播： 单个消息可被多个订阅者接收，避免为每个客户端重复建立连接（如WebSocket需维护多个连接）。

MQTT协议在设计上有一个订阅中心的概念，硬件设备其实从角色上来说跟前端一样，也是client。

现在有一个前端A和一个前端B，都需要跟硬件C进行通信，接收硬件的统一消息。

如果是基于MQTT协议，硬件C只需要把要发布的消息发给指定的Topic，不需要跟接收者进行直接的交互。

前端A和前端B可以通过订阅指定Topic来接受硬件C发布的消息。

这样理论上硬件C的消息可以发布给任何数量的前端。

反过来也是同理，因为硬件和前端都属于client的角色

那如果这种场景用WebSocket协议来做呢，硬件C就需要分别跟前端A和前端B建立长连接，然后将消息分发出来。而MQTT协议中，硬件C只需要跟订阅中心建立关系，不需要管订阅中心分发给了多少client。

QoS消息质量保障

在MQTT协议中，QoS（服务质量） 是确保消息在不同网络环境下可靠传输的核心机制。它分为三个等级，从"尽力而为"到"绝对可靠"，适应多种场景需求。

1. QoS 0：至多一次（At Most Once）

• 工作原理：

  • 发送方（发布者）将消息发出后，不等待确认，直接处理下一条消息。
  • 接收方（订阅者）可能收到消息，也可能因网络问题完全丢失。

• 适用场景：

  • 不重要或高频数据： 如温度传感器定期上报数据，偶尔丢失不影响整体趋势。
  • 低功耗设备： 免确认交互，节省电量（如电池供电的传感器）。

• 示例：

  • 智能灯泡每隔10秒上报一次亮度值，丢失一次数据不影响用户体验。

2. QoS 1：至少一次（At Least Once）

• 工作原理：

  • 发送方发出消息后，等待接收方的确认。
  • 若未收到确认，发送方会重复发送消息，直到收到确认为止。
  • 接收方可能收到重复消息，需应用层去重（如通过消息ID）。

• 适用场景：

  • 关键但允许重复的操作： 远程开灯指令（多按一次开关影响不大）。
  • 网络波动环境： 保消息必达，容忍少量重复。

• 示例：

  • 用户通过APP发送"关闭空调"指令，即使网络延迟导致指令重复发送，空调只需执行一次关闭操作。

3. QoS 2：恰好一次（Exactly Once）

• 工作原理：

  • 两阶段握手，确保消息既不丢失也不重复：

    • PUBLISH → PUBREC： 发送方发出消息，接收方确认收到并暂存。
    • PUBREL → PUBCOMP： 发送方释放消息存储，接收方最终确认。

  • 协议层自动处理去重，应用层无需额外逻辑。

• 适用场景：

  • 敏感数据或交易： 如支付指令、告警信号（如烟雾探测器报警）。
  • 严格不允许重复的场景： 如工业设备的状态控制命令。

• 示例：

  • 银行系统发送"转账100元"指令，必须确保仅执行一次，避免重复扣款。

MQTT还有离线消息缓存，Broker可为断开连接的订阅者暂存消息（Clean Session=false），设备重连后补发。

QoS选择指南

维度	QoS 0	QoS1	QoS2
可靠性	可能丢失	必达但可能重复	必达且不重复
网络开销	最低	中等	最高
延迟	最低	中等	最高
适用设备	低功耗设备	常规设备	高可靠设备

适应不稳定网络

• 心跳机制： Keep Alive参数检测连接状态，自动重连减少断线影响。
• 遗嘱消息（LWT）： 设备异常离线时，Broker自动发布预设消息，通知其他系统处理故障。

低功耗优化

• 短连接模式： 设备发送数据后立即休眠，相比HTTP的长连接更省电。
• 避免轮询： 订阅者实时接收消息，无需如HTTP轮询查询状态，减少无效请求。

对比其他协议劣势

• HTTP：

  • 请求/响应模式导致高延迟，不适合实时通信。
  • 无状态特性需频繁重建连接，Header冗余大。
  • 服务端无法主动推送数据，依赖轮询（浪费资源）。

• WebSocket：

  • 虽支持全双工，但无原生消息队列和QoS支持。
  • 需自行实现订阅逻辑和消息路由，增加开发复杂度。
  • 维护大量长连接对服务端资源消耗较高。

适用场景举例

• 传感器数据采集： 大量设备高频上报温度、GPS等数据，MQTT轻量级特性显著降低负载。
• 远程设备控制： 通过QoS 2确保关键指令（如阀门开关）可靠执行。
• 多端数据同步： Web、App、硬件均订阅同一Topic，实现数据实时同步。

何时选择其他协议

• 需要强事务性： 如支付场景，HTTP+RESTful API更合适。
• 简单单向通信： 如上传文件，可使用HTTP PUT。
• 浏览器兼容性优先： 若无跨平台SDK支持，WebSocket更易集成。

总结

MQTT在物联网场景下，以低开销、高可靠、易扩展等特性成为最优解，而其他协议更适用于侧重事务处理或简单通信的场景。