WebSocket、SSE、MQTT 实时通信协议对比:30 分钟搞懂技术选型

WebSocket、SSE、MQTT 实时通信协议对比:30 分钟搞懂技术选型 做实时功能开发的时候你是不是经常陷入选择困难做实时聊天选 WebSocket 还是 MQTT做监控大屏用 SSE 还是 WebSocket做物联网设备接入到底哪个协议更合适这三个协议根本不是 “竞争关系”而是分工明确的不同工具WebSocket 是对讲机SSE 是广播电台MQTT 是物联网消息中转站。今天把它们的原理、差异、适用场景、踩坑点全讲透看完直接能选对不用再纠结。一句话抓住核心定位先把三个协议的本质摸清楚后面理解细节就很简单协议通俗比喻核心能力最适配场景WebSocket双向对讲机客户端和服务端随时互相发消息支持文本/二进制聊天、弹幕、协同编辑、实时游戏SSE单向广播电台服务端持续向客户端推数据客户端只能收LLM 流式输出、股票行情、监控大屏、系统通知MQTT物联网消息中转站发布/订阅模式轻量低功耗支持百万级设备并发智能家居、车联网、工业设备监控、传感器数据采集逐个拆解原理、优缺点、代码示例WebSocket双向实时通信的标配核心原理WebSocket 是基于 TCP 的独立全双工协议先通过一次 HTTP 握手完成协议升级之后脱离 HTTP 协议数据以帧为单位传输帧头只有 2-10 字节传输开销极低。连接建立后客户端和服务端可以随时互相发送消息延迟通常在 10-50ms 之间。优点真正的双向通信客户端和服务端都能主动发消息支持文本和二进制数据可以传图片、音视频流延迟低适合高频交互场景浏览器原生支持不用装额外库缺点没有内置心跳、重连机制需要手动实现部分严格的防火墙/代理会拦截 WebSocket 升级请求负载均衡需要配置 Sticky Session部署复杂度略高代码示例// 建立连接wss://是加密版本类似 HTTPS const ws new WebSocket(wss://api.example.com/chat); ws.onopen () { console.log(连接成功); // 发送消息 ws.send(JSON.stringify({ user: 张三, content: 你好 })); }; ws.onmessage (event) { const msg JSON.parse(event.data); console.log(收到消息${msg.user}: ${msg.content}); }; ws.onclose () { console.log(连接断开3秒后重试...); setTimeout(() initWebSocket(), 3000); };适用场景微信网页版聊天、B站弹幕、腾讯文档多人协作、在线游戏实时对战、实时语音信令传输。SSE最轻量的单向推送方案核心原理SSE 完全基于标准 HTTP 协议客户端发起 GET 请求后服务端保持连接不关闭持续以text/event-stream格式推送数据。浏览器内置了自动重连机制断线后会自动重试还能通过Last-Event-ID实现断线期间的消息续传。优点实现极简服务端只需要设置几个 HTTP 头就能用浏览器自动重连不用写重连逻辑基于 HTTP能穿透所有防火墙、CDN、负载均衡部署成本几乎为 0服务端资源占用低单连接内存只有 1-5KB缺点只能服务端向客户端推送客户端要发消息得额外发起 HTTP 请求只支持 UTF-8 文本数据不能传二进制内容HTTP/1.1 下同一域名最多只能有 6 个并发 SSE 连接HTTP/2 下限制解除代码示例// 客户端3 行代码搞定 const eventSource new EventSource(/api/stock-stream); eventSource.onmessage (event) { const data JSON.parse(event.data); console.log(股票行情更新, data); };// 服务端Node.js 示例 app.get(/api/stock-stream, (req, res) { res.setHeader(Content-Type, text/event-stream); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); const interval setInterval(() { res.write(data: ${JSON.stringify(getStockData())}\n\n); }, 1000); req.on(close, () clearInterval(interval)); });适用场景ChatGPT/通义千问等 LLM 的流式输出、股票行情推送、物流状态更新、监控大屏只读数据展示、系统公告通知。MQTT物联网场景的绝对王者核心原理MQTT 是专门为物联网设计的轻量级发布/订阅协议核心是 Broker消息中转站设备作为发布者把数据发到指定主题Topic订阅了对应主题的客户端就能收到消息发布者和订阅者完全解耦不需要同时在线。协议头最小只有 2 字节还支持 QoS 分级可以根据场景选择消息可靠性。优点超轻量协议开销极低适合低带宽、低功耗的嵌入式设备支持离线消息设备断线后 Broker 会缓存消息重连后自动补发支持遗嘱消息设备异常断线时自动通知其他客户端单机 Broker 可以支撑百万级设备并发扩展性极强缺点需要额外搭建 MQTT Broker部署成本略高不适合复杂的实时双向交互场景主要面向设备通信浏览器端支持不如 WebSocket/SSE 完善代码示例// 客户端使用 mqtt.js 库 const mqtt require(mqtt); const client mqtt.connect(mqtt://broker.example.com); client.on(connect, () { // 订阅温度主题 client.subscribe(sensor//temperature, { qos: 1 }); // 发布消息 client.publish(sensor/001/status, JSON.stringify({ online: true })); }); client.on(message, (topic, message) { console.log(收到主题${topic}的消息, message.toString()); });适用场景智能家居设备联动、工厂传感器数据采集、车联网车辆状态上报、物流资产追踪、智慧农业环境监测。核心维度对比一张表选对协议对比维度WebSocketSSEMQTT通信模式全双工双向服务端单向推送发布/订阅双向底层协议独立协议基于 TCP标准 HTTP/HTTPS基于 TCP 的轻量协议数据格式文本/二进制仅 UTF-8 文本任意二进制/文本延迟10-50ms50-100ms20-80ms服务端资源占用中低极低重连机制需手动实现浏览器自动支持内置自动重连部署复杂度中需配置协议升级极低复用 HTTP 基础设施中需搭建 Broker并发能力万级连接万级连接百万级连接选型决策树按场景直接选不用纠结按下面 3 个问题判断就能选对是否需要客户端和服务端随时互相发消息是 → 选 WebSocket否 → 进入第 2 步是否是物联网/设备端通信场景是 → 选 MQTT否 → 选 SSE避坑指南这些坑别踩WebSocket一定要做心跳保活不然长时间不发消息会被防火墙或代理断开连接生产环境建议用wss://加密避免被运营商拦截。SSEHTTP/1.1 下注意连接数限制不要在同一域名开太多 SSE 连接建议升级到 HTTP/2 解除限制不要尝试用 SSE 传二进制数据会报错。MQTT不要随便用 QoS 2它的四次握手会大幅降低性能除非是金融交易这种绝对不能丢消息的场景否则 QoS 0 或 1 就够用主题设计要规范避免用太宽泛的通配符导致消息风暴。