J9游戏|Home

WebSocket 不是不好，而是被严◇重高估了✩它的"万能性"。 它解决了▽一类问题，同时带来〓了另一批◢问题。大多数 Web 场景用 HTTP 反而是更✿✿明智的选✿择。

一、先破一个认知误区

很多人觉✩得 WebSocket 比 HTTP "更先进"，HTTP 是"老东西"，WebSocket 是"未来"。

这个想法‣完全错了。

HTTP 和 WebSocket 是两种适✧合不同场∷景的工具，就像锤子∷和螺丝刀，不存在谁❀淘汰谁的♡问题。拿锤子拧▹螺丝，不是锤子✧不行，是你用错♢了。

二、WebSocket 的致命缺陷，一条一条说清楚

1. 无状态的 HTTP 是优势，不是缺点

HTTP 最被人诟☆病的一点——"无状态"——恰恰是它❈最大的工✯✯程优势。

每一个 HTTP 请求都是⊕独立的，服务器处▴理完就扔⊕掉了，不需要记♧住你是谁。这带来了☆一个极其⊕重要的特●性：天然支持‣水平扩展。

你有 100 台服务器，用户的请✭求打到任✧意一台都▪▪能正确响▿▿应。负载均衡❀器随便轮◣询，没有任何♡问题。

WebSocket 呢？连接是有▴状态的，一旦建立，这条连接▲就"粘"在某一台◈服务器上◎了。用户 A 连在机器 1 上，你的负载◈均衡器就▿不能随意〓把它的后❋续消息打●到机器 2——因为机器 2 根本不知▼道这条连▵▵丨丨接的✦状态。

这意味着※什么？你的整个◢后端架构◆要为 WebSocket 做专门适◎配。

要么引入❉粘性会话（Sticky Session），要么引入❈一个中心∷化的消息✫总线（Redis Pub/Sub、Kafka），让所有机◉◉器共享连◢接状态。复杂度直〓接上了一◆个台阶。

2. 连接是稀缺资源，不是免费的

HTTP 请求是短▿连接，用完即走，服务器资☆源立刻释※放。

WebSocket 是长连接，只要用户▵开着页面，连接就一✯✯直占着。

假设你的♡♡服务有 100 万用户同◢时在线，全部 WebSocket 长连接，那就是 100 万个并发◥连接同时◦压在你的丨丨服务器▼上。每个连接⊙丨都要占▣用·文件描述❉符、内存、心跳维护◢的 CPU……

这不是不✭能做，微信、飞书这类 IM 产品确实◦在做，但他们为★此专门维♢护了连接网关◦集群，这是一套✪独立的基◉础设施，有专门的❈团队在维❈❈护。你以为微❖信后端是❀一套统一★的 WebSocket 服务？不是，那是几百★个工程师▾维护的分丨丨布式系∷统。

对于一个■普通的业☆务系统，为了"统一通信•协议"引入这套▴复杂度，完全得不◢偿失。

3. 中间链路的兼容性问题，比你想象的严重

HTTP 已经跑了◈几十年，全球所有△的网络设◤备——路由器、防火墙、CDN、反向代理、企业内网——都对它有❉❉完美支持。

WebSocket 就不一样了。

WebSocket 虽然复用·了 HTTP 的握手，但升级协※议后的行❉为跟普通 HTTP 完全不同。很多企业▲内网的防♦火墙、某些运营▪商的中间※设备，会强行切断♢长时间没▽有数据的 TCP 连接，或者压根◈不认识 WebSocket 协议，直接丢包。

这就是为❋什么 WebSocket 客户端必☆☆须实现心♢跳机制，定期发 ping/pong 保活。你以为这●●是小事，但在工程►上意味着：

• 客户端要实现心跳逻辑
• 服务端要处理心跳超时和连接清理
• 要实现断线重连，并且重连时要恢复状态
• 网络抖动时要处理消息丢失和重复推送

每一条都◎是工作量，每一条都►是潜在的 bug。

4. 调试、监控、运维成本大幅上升

HTTP 的调试简○单到极致：打开 Chrome DevTools，Network 面板，所有请求✭一目了然，每个请求♦的入参、出参、耗时、状态码清〓清楚楚。

WebSocket？DevTools 里只能看✫✫到一条"101 Switching Protocols"，之后的所◢有消息混♢在一个 Messages 标签里滚▾动。你要在几❋百条消息⊕⊕里找到某▾▾个异常，痛苦程度◥不亚于在 access log 里肉眼找 bug。

更别提：

• HTTP 有成熟的 APM 接入方案，链路追踪开箱即用
• WebSocket 的消息没有天然的 Request ID，链路追踪要自己实现
• HTTP 的 RESTful 语义清晰，WebSocket 的消息协议要自己设计和维护

5. 缓存体系完全失效

HTTP 有一套成♡熟的缓存◉体系：CDN 缓存、浏览器缓❀存、Cache-Control、ETag……对于读多▼写少的数❖据，一个接口○加上合适✫的缓存头，可以把 99% 的请求挡♢在 CDN 层，后端压力▾小到忽略⊕不计。

WebSocket 是实时双▲向流，没有缓存⊕这个概念。所有消息☆☆都要打到♢♢服务端处·理。

三、回到你说的那个场景

调一个接❀口获取列◇表数据，用户长时▽间停留页▪面，数据变动♡了怎么办？

这个问题◉有很多解◇◇法，按复杂度▽递增：

轮询（Polling）：每隔 N 秒请求一▸次。简单粗暴，适合数据◥◥更新不频✫✫繁、实时性要▵求不高的✦场景。

长轮询（Long Polling）：请求发出◥去，服务端 hold 住，有数据更♢新了再返▿▿回。实时性更■■好，实现成本❖也不高。

SSE（Server-Sent Events）：服务端单✩向推送，基于 HTTP，天然支持❈断线重连，浏览器原▹生支持。适合服务△△端推送、不需要客◢户端上行◣的场景，比 WebSocket 轻量得多。

WebSocket：真正需要❋双向实时◇◇通信时才⊕用，比如聊天、协同编辑、实时游戏。

你说的那♧个场景——列表数据▿变动通知——用 SSE 就够了，完全不需‣要 WebSocket。

四、什么时候才该用 WebSocket？

• 聊天、弹幕、实时评论——需要双向通信
• 协同文档——多人同时编辑，需要实时同步操作
• 实时游戏——高频双向数据交换
• 股票行情、实时监控大屏——高频服务端推送（其实 SSE 也够）

判断标准∷只有一个：你的场景▸是否真的▸需要客户♢端主动向◦服务端高▽频发送数◆据，同时服务▹端也在高◉频下发数❋据？ 如果只是❋服务端推，用 SSE。如果请求♧♧频率不高，用轮询或☆长轮询。只有真正▾的双向高✫频通信，才上 WebSocket。