为什么用 WebSocket

轮询的问题

如果用 HTTP 轮询做弹幕，客户端要不断请求「有没有新消息」：

• 延迟高：轮询间隔决定了延迟下限（5 秒轮询 → 最坏 5 秒延迟）。
• 浪费资源：大量空请求，服务端和带宽都被浪费。
• 无法推送：服务端有新消息时，只能等客户端来问。

直播弹幕需要「服务端主动推」——这正是 WebSocket 的场景。

WebSocket 长连接

WebSocket 让客户端和服务端建立长连接，服务端可以主动推送消息：

浏览器/APP <-> WebSocket 网关 <-> 房间消息服务

关键特性：

• 双向通信：客户端可发、服务端可推。
• 低延迟：建立连接后无需握手开销。
• 连接复用：一次连接承载大量消息。

长连接的代价

WebSocket 不是免费的：

• 连接有成本：每用户占一份内存与文件描述符。
• 状态在服务端：连接状态要维护，断线要处理。
• 扩容复杂：连接是「粘在」某台网关上的。

所以 WebSocket 网关要设计得轻量、可横向扩展、可观测（本章后续小节）。

什么时候不该用 WebSocket

• 低频消息（如邮件通知）：轮询 / 短连接更简单。
• 无状态场景：HTTP 天然适合。
• 需要考虑协议复杂度与运维成本。

实时性要求决定是否使用 WebSocket——直播弹幕是高实时场景，值得付出连接成本。

一句话

WebSocket 解决「低延迟 + 服务端推送」：直播弹幕是典型的高实时场景，用长连接替代轮询。代价是连接状态管理，这正是下一节连接建立要处理的。

下一节看连接建立与状态管理。

上一章节

WebSocket 通信

下一章节

连接建立与状态