WebSocket 与长连接题库
这部分非常适合你后面面 AI 后端、实时消息、流式输出、Swoole 或 Go 服务岗位。
一、为什么需要 WebSocket
标准回答
因为 HTTP 是请求响应模型，客户端要主动轮询；WebSocket 建立的是长连接，可以实现服务端主动推送。
更好的说法
当业务需要实时交互、流式返回、状态持续更新或服务端主动通知时，WebSocket 比轮询更合适。
二、WebSocket 和 HTTP 的区别
- HTTP：短连接，请求响应
- WebSocket：长连接，双向通信
三、WebSocket 握手过程
- 客户端先发 HTTP Upgrade 请求
- 服务端返回 101 Switching Protocols
- 协议升级成功，之后走 WebSocket 帧通信
四、为什么 AI 场景经常会用 WebSocket 或 SSE
AI 输出经常是流式的，比如逐 token 返回、生成内容分段返回、任务进度流式更新。
- 单向流式输出：SSE
- 双向交互和会话控制：WebSocket
五、SSE 和 WebSocket 的区别
- SSE：服务端单向推送，基于 HTTP，实现简单
- WebSocket：双向通信，更适合交互式场景
六、心跳为什么重要
WebSocket 是长连接，需要通过心跳机制判断连接是否仍然可用，及时清理断开的连接。
七、断线重连怎么做
- 指数退避
- 最大重试次数
- 重连后重新鉴权
- 必要时补发未完成请求
八、认证怎么做
- 握手时带 token
- 握手成功后绑定用户身份
- 服务端维护 connection -> user 映射
九、多实例部署下怎么推消息
如果服务有多实例，不能假设用户一定连在当前机器上，所以一般会通过：
- Redis Pub/Sub
- Kafka
- 消息总线
- 或统一连接网关层
十、连接数很大时要注意什么
- 连接占用内存
- 心跳成本
- 广播成本
- 单机 fd 限制
- 负载均衡和连接保持
- 热点房间 / 热点频道
十一、结合你的项目怎么讲
虽然你历史主项目不一定是典型 IM，但你完全可以从 AI 后端角度讲：
- 如果做 AI 对话服务，需要把模型输出流式返回给前端
- 如果是单向 token streaming，可以考虑 SSE
- 如果要做会话控制、任务取消、实时状态、多事件消息，更适合 WebSocket
十二、技术总监最爱问的问题
1. 为什么不用轮询
因为实时性差、请求浪费大、服务端和客户端都更耗资源。
2. WebSocket 最大难点是什么
不是建连接，而是长连接管理、鉴权、心跳、断线重连、多实例路由和消息分发。
3. AI 场景用 WebSocket 还是 SSE
如果只是单向流式输出，SSE 更简单；如果要更强交互能力，WebSocket 更合适。
十三、你最适合背的总结句
我对 WebSocket 的理解重点不是协议细节，而是它适合解决实时交互和流式输出问题。尤其在 AI 场景里，如果只是单向 token streaming，SSE 已经很好用；如果需要双向交互、任务控制和多事件消息，WebSocket 会更适合，但也要额外处理鉴权、心跳、断线重连和多实例消息分发。