SSE vs WebSocket：为什么SSE突然就火了？
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
在这一行干了十几年，经历过好几波技术浪潮。要说近几年后端架构领域最值得关注的一个趋势，不是什么新语言、新框架，而是一个特别不起眼的变化——SSE（Server-Sent Events）正在悄悄吃掉 WebSocket 的大量场景。 你可能会说：SSE？那不是 2006 年就有东西吗？当年 IE 都支持的玩意儿，怎么突然又火了？ 别急，听我从实际项目经验的角度，把这事儿给你讲透。
架构选型的本质：别拿着锤子找钉子先说一个我踩过的大坑。 几年前做一个实时通知系统，需求很简单：服务端有新消息就推给前端。我当时二话不说选了 WebSocket——毕竟"实时"两个字就等于 WebSocket，对吧？ 结果呢？上线之后噩梦才开始： 👉 Nginx 反向代理得专门配 WebSocket 超时和 Upgrade 头 👉 K8s Ingress 要改 annotation，不然连接几秒就断 👉 客户断线重连自己写了一堆，还总有 bug 👉 某企业客户部署时，防火墙直接把 ws:// 给拦了 👉 云厂商的 SLB 不支持 WebSocket 长连接，被迫换方案 折腾了大半个月，最后回头看——我们的业务压根不需要双向通信。客户端发个 HTTP 请求，服务端推消息回来，仅此而已。完全是用大炮打蚊子。 架构选型最忌讳的就是"用最熟的技术去套所有场景"。先搞清楚需求，再选工具。 先搞清楚：它俩本质上是两种通信模型很多人把 WebSocket 和 SSE 放在一起比，好像它们是竞争对手。其实根本不是——它们解决的是完全不同维度的问题。 WebSocket = 全双工电话线 📞建立连接后，双方可以随时互发消息。客户端能主动发，服务端也能主动推。就像打电话——两边都能说话。 底层走的是独立的 SSE = 服务端的广播电台 📻连接建立后，只有服务端能往客户端推数据。客户端就是个听众，只进不出。就像听广播——电台说啥你听啥，你不能跟电台对话。 底层就是标准的 HTTP 长连接，Content-Type 设成
核心参数对比为什么近两年 SSE 突然爆发？这才是本文的重点。SSE 不是突然变强了，而是技术生态变了。 原因一：LLM 的流式输出，简直是给 SSE 量身定做的ChatGPT 的打字机效果，技术上叫 Streaming。大模型生成一个 token 就推一个 token，前端逐字渲染。 你仔细想这个交互模式——用户发一条 prompt（普通 HTTP POST），然后服务端持续单向推回复。这不就是 SSE 的教科书场景吗？ 现在几乎所有大模型的 API 都支持 SSE 流式输出：OpenAI、Anthropic、智谱、通义、DeepSeek……这不是巧合，而是因为 SSE 在这个场景下确实是最优解。 WebSocket 当然也能做，但你用一个全双工通道来干单工的活，连接管理、心跳维护、状态同步全是白搭的成本。
原因二：开发效率差了十倍我带团队做过对比。同样的"服务端推送"功能，两种方案的开发周期： SSE 方案： WebSocket 方案： SSE 前后端加起来不到20行代码。WebSocket 随便一个完整实现就得几百行，还得处理一堆边界情况。 对于一个需要快速验证的 AI 功能，你选哪个？ 原因三：基础设施的兼容性，SSE 完胜这是很多开发者（尤其是小团队）容易忽略的维度——运维成本。 WebSocket 的 • 握手被拦截（代理不认识 Upgrade 头） • 连接超时断开（默认60s，得专门配） • SSL 终端不透传 WebSocket 帧 • 部分云厂商的负载均衡不支持 ws 协议 我在上一个项目就踩过：客户是金融机构，他们的网关只允许标准 HTTPS 流量通过。WebSocket 方案直接被否。换成 SSE，零改造上线。 SSE 就是最标准的 HTTP。 任何代理、CDN、防火墙、网关看到的就是一个普通的 HTTP 长连接，不需要任何特殊配置。 原因四：断线重连不用你写移动端、弱网环境下，连接断开是常态。WebSocket 断了，你得自己实现指数退避重连 + 状态恢复 + 消息补偿。这块代码写不好，要么疯狂重连打爆服务端，要么消息丢失。 SSE 呢？浏览器原生自动重连，还自带 一行代码不用写，白送的功能。 原因五：云原生架构天然适配现在的后端架构：Serverless、API Gateway、Service Mesh、K8s Ingress。这些组件对 HTTP 的理解是一等公民级别的。 SSE 走的是 HTTP，API Gateway 天然支持，Serverless 函数可以直接返回 stream，Ingress 不需要任何特殊配置。 WebSocket 呢？它需要有状态的持久连接。Serverless 函数冷启动的时候连接早断了；K8s Pod 重调度，所有 ws 连接全部丢失；Ingress 得配 sticky session。 在云原生时代，无状态的 HTTP 流比有状态的 ws 连接好运维一个数量级。 但 WebSocket 的铁饭碗，SSE 端不动说了这么多 SSE 的好，不意味着 WebSocket 要被淘汰了。下面这些场景，SSE 根本做不了： 🎮 多人实时游戏 — 玩家操作要双向实时同步，延迟要求 ms 级 💬 IM 聊天 — 双方都要随时发消息，还要传图片、文件 📊 协同编辑 — 多人同时改文档，OT/CRTP 算法需要双向实时 📈 金融交易 — 行情推送 + 下单指令，双向都要求极低延迟 🏠 IoT 设备控制 — 传感器上报 + 下发控制指令 这些场景的核心特征是客户端需要频繁、低延迟地主动发消息。SSE 是单向的，要实现这种效果就得 SSE + HTTP POST 组合，架构复杂度反而更高。 所以结论很清晰：需要双向实时通信的场景，WebSocket 依然是唯一解。 架构选型决策树我总结了这些年做实时系统的选型经验，画了个简单的决策树： 你的业务需要客户端频繁主动发消息吗？ ↓ 是 用 WebSocket，没得选 ↓ 否（只需要服务端推送） 你的推送需要传二进制数据吗？ ↓ 是 用 WebSocket ↓ 否 用 SSE，别犹豫 就这么简单。90% 的"实时推送"场景，走到最后一行都是 SSE。 说几句掏心话SSE 这两年爆发，不是 WebSocket 不行，而是时代变了。 服务端说、客户端听 → SSE。双方互说 → WebSocket。 别被网上那些"SSE 要取代 WebSocket"的标题党忽悠了。它们不是一个赛道的东西，只是这个时代恰好有更多场景需要单向推送罢了。 好的架构师不是什么都用最新的，而是——在正确的场景选正确的工具。 阅读原文：https://mp.weixin.qq.com/s/GKBf8v85TmncL-WqxYSrcw 该文章在 2026/5/29 18:30:58 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
