websocket是前端接入mqtt的必要桥梁，因浏览器无tcp支持；设备端则直接运行mqtt，因其轻量、低功耗且无需http栈。
WebSocket 本身不适合直接用于物联网设备端通信，但它是 Web 前端接入 MQTT 的关键桥梁；真正在设备侧跑 MQTT，而不是 WebSocket。
为什么不能直接用 WebSocket 接入传感器或嵌入式设备
多数 MCU、LoRa 模块、NB-IoT 终端（如 ESP32-C3、nRF9160、BC95）没有完整的 HTTP 栈，更不支持 WebSocket 握手所需的 Upgrade: websocket 头和 Sec-WebSocket-Key 签名计算。它们连 new WebSocket() 都无法调用。
- WebSocket 连接建立依赖 HTTP/1.1 升级流程，需完整解析响应头——这对 RAM
- 维持 WebSocket 心跳（ping/pong 帧）需额外状态机，而 MQTT 的
keepalive是单字节字段 + 简单计时器 - 协议帧头开销：WebSocket 最小帧头 6 字节（不含掩码），MQTT CONNECT 报文最小仅 10 字节，PUBLISH QoS 0 最小仅 3 字节
- 实际案例：某工业温控器使用 WebSocket 上报数据后，待机功耗从 12μA 升至 85μA，电池寿命缩短 73%
MQTT over WebSocket 是什么，什么时候必须用它
MQTT over WebSocket 不是新协议，而是把 MQTT 报文封装进 WebSocket 数据帧里传输。本质是“用 WebSocket 当 TCP 替身”，让浏览器能走标准 MQTT 语义。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 典型 URL 形式：
wss://broker.example.com/mqtt或ws://broker.example.com:8083/mqtt - 服务端必须启用 WebSocket listener（如 EMQX 的
listener.ws.external，Mosquitto 需 2.0+ 并配置listener 8083+protocol websockets） - 前端必须用支持 WS 的 MQTT 客户端库，比如
mqtt.js4.0+，且初始化时传protocol: 'wss'而非'mqtts' - 别踩坑：Nginx 反向代理 WebSocket 时，必须显式透传
Upgrade和Connection头，否则连接在 101 Switching Protocols 阶段就失败
混合架构中 WebSocket 和 MQTT 各自该守哪一层
真实高可用 IoT 系统几乎全是“MQTT 做后端总线 + WebSocket 做前端通道”：设备发到 MQTT Broker，Web 页面通过 WebSocket 连 Broker 订阅 Topic，中间不经过业务服务器转发。
- Broker 必须支持 WebSocket endpoint（EMQX/Mosquitto/HiveMQ 都支持），否则你得自己写一层
WebSocket → MQTT bridge，徒增延迟与单点故障 - 禁止让业务 Node.js 服务充当“MQTT 中转站”：它收到 MQTT 消息后再用
ws.send()推给浏览器——这会丢失 QoS 语义，且无法利用 Broker 的离线消息缓存 - Topic 设计要适配双端：设备发布
/device/{id}/status，前端订阅相同路径即可；避免用/user/{uid}/xxx这类需服务端鉴权映射的路径（WebSocket 连接已由 Broker 完成 ACL 校验） - 注意浏览器并发限制：Chrome 对同一域名 WebSocket 连接数上限为 6 个，若页面需订阅 20 个 Topic，请合并为通配符订阅（如
/device/+/status）并做前端过滤
QoS 1/2 在 WebSocket 通道里还能起作用吗
能，但前提是整个链路都支持——从设备 client.publish(..., {qos: 1})，到 Broker，再到前端 mqtt.connect('wss://...') 实例，所有环节都必须保持 MQTT 语义透传。WebSocket 层只负责“搬箱子”，不拆箱。
- QoS 1（至少一次）在前端仍会触发
message事件多次，需前端自行去重（靠mid或业务 ID） - QoS 2（恰好一次）要求 Broker 支持 session 持久化，且前端 client 初始化时设
clean: false和唯一clientId，否则重连后无法恢复 QoS 2 状态 - 别指望 WebSocket 自己保证可靠性：它的 ping/pong 只保连接存活，不保消息送达；丢包重传、ACK 确认全靠 MQTT 协议栈完成
- 实测数据：在 3% 丢包网络下，纯 WebSocket 自研协议消息丢失率约 12%，同等条件下 MQTT over WebSocket + QoS 1 丢失率
真正容易被忽略的是 Broker 的 WebSocket 配置粒度——它和原生 TCP listener 可以设置完全不同的最大连接数、超时、SSL 证书、ACL 规则。很多人只调了 TCP 端口的并发上限，忘了 listener.ws.external.max_connections 还锁在默认的 1024，结果大屏一刷新就 502。
