WebSocket 与长连接题库

这部分非常适合你后面面 AI 后端、实时消息、流式输出、Swoole 或 Go 服务岗位。

一、为什么需要 WebSocket

标准回答

因为 HTTP 是请求响应模型，客户端要主动轮询；WebSocket 建立的是长连接，可以实现服务端主动推送。

更好的说法

当业务需要实时交互、流式返回、状态持续更新或服务端主动通知时，WebSocket 比轮询更合适。

二、SSE 是什么

SSE，Server-Sent Events，本质上是：

服务端基于 HTTP 持续返回一个流式响应
客户端持续接收服务端推送的事件
通信方向是服务端单向推送给客户端

它常见于：

AI token streaming
实时日志
任务进度推送
简单通知流

三、WebSocket 和 HTTP 的区别

HTTP：默认请求响应
SSE：基于 HTTP 的单向流式推送
WebSocket：升级后保持长连接，支持双向通信

四、WebSocket 握手过程

客户端先发 HTTP Upgrade 请求
服务端返回 101 Switching Protocols
协议升级成功，之后走 WebSocket 帧通信

五、为什么 AI 场景经常会用 WebSocket 或 SSE

AI 输出经常是流式的，比如逐 token 返回、生成内容分段返回、任务进度流式更新。

单向流式输出：SSE
双向交互和会话控制：WebSocket

六、SSE 和 WebSocket 的根本区别

SSE：单向，服务端推给客户端
WebSocket：双向，客户端和服务端都能主动发消息
SSE：基于 HTTP 流式响应，没有 Upgrade
WebSocket：先走 HTTP Upgrade，再进入帧协议
SSE：更适合文本事件流
WebSocket：更适合复杂交互、二进制、房间消息、多事件控制

七、什么时候优先选 SSE

如果场景是下面这些，SSE 往往更合适：

只是服务端往前端单向推送
主要是 token streaming、进度更新、日志输出
前端不需要频繁主动给服务端发实时控制消息
想尽量复用 HTTP 基础设施和开发心智

一句话总结：

能用 SSE 解决的单向流式问题，不一定要一上来就 WebSocket。

八、什么时候更适合 WebSocket

如果场景是下面这些，WebSocket 更合适：

客户端和服务端都需要主动发消息
需要实时任务控制，比如暂停、继续、取消
需要房间、频道、多人协作
需要更复杂的消息类型
需要低延迟双向交互

比较典型的就是：

IM
实时协作
在线对战
双向语音 / 音视频信令
多事件 AI Agent 会话

九、SSE 的工程注意点

很多人只会说“简单”，但不会说坑点。

真正要注意的是：

反向代理别把流式响应缓冲住
要处理连接超时和自动重连
最好给事件带 id
需要心跳注释或 keepalive，避免中间层断开

SSE 常见优点是简单，但它不是“零治理成本”。

十、WebSocket 的工程注意点

指数退避
心跳检测
断线重连
重连后重新鉴权
connection -> user 映射
多实例下的消息路由
广播风暴和热点频道

十一、为什么很多 AI 场景先用 SSE 而不是 WebSocket

因为很多 AI 页面看起来像“实时交互”，但实际上数据流经常是：

用户先发一个普通 HTTP 请求
服务端开始持续把生成结果往前端推

这条链路本质上仍然是“客户端发起一次请求，服务端持续往回写流”。

如果只是这样，SSE 就够了。

这里很容易讲错的一点

很多人会说：

“只要有取消按钮，就必须 WebSocket”

其实不一定。

很多系统完全可以这样做：

输出流用 SSE
取消任务走单独 HTTP 接口

所以不要把“有一点交互”直接等价成“必须 WebSocket”。

十二、认证怎么做

握手时带 token
握手成功后绑定用户身份
服务端维护 connection -> user 映射

如果是 SSE，一般是请求阶段就完成鉴权；如果是 WebSocket，还要继续考虑：

token 过期怎么处理
重连后如何重新认证
多 tab / 多设备连接如何识别

十三、多实例部署下怎么推消息

如果服务有多实例，不能假设用户一定连在当前机器上，所以一般会通过：

Redis Pub/Sub
Kafka
消息总线
或统一连接网关层

十四、连接数很大时要注意什么

连接占用内存
心跳成本
广播成本
单机 fd 限制
负载均衡和连接保持
热点房间 / 热点频道

十五、结合你的项目怎么讲

虽然你历史主项目不一定是典型 IM，但你完全可以从 AI 后端角度讲：

如果做 AI 对话服务，需要把模型输出流式返回给前端
如果是单向 token streaming，可以考虑 SSE
如果要做会话控制、任务取消、实时状态、多事件消息，更适合 WebSocket

十六、技术总监最爱问的问题

1. 为什么不用轮询

因为实时性差、请求浪费大、服务端和客户端都更耗资源。

2. WebSocket 最大难点是什么

不是建连接，而是长连接管理、鉴权、心跳、断线重连、多实例路由和消息分发。

3. AI 场景用 WebSocket 还是 SSE

如果只是单向流式输出，SSE 更简单；如果要更强交互能力，WebSocket 更合适。

4. SSE 和 WebSocket 怎么选，能不能一句话讲清

可以。

单向流式推送优先 SSE，双向实时交互优先 WebSocket。

十七、你最适合背的总结句

我对 SSE 和 WebSocket 的理解重点不是记协议名，而是看通信方向和治理成本。如果只是服务端单向把 token、进度、日志持续推给前端，SSE 往往更简单；如果要双向实时交互、任务控制、多人协作或复杂消息路由，WebSocket 更合适。但 WebSocket 带来的长连接治理成本也更高，所以不是所有流式场景都需要它。