《Linux操作系统编程详解》《笔试/面试常见算法：从基础到进阶》《Python干货分享》
🎬 艾莉丝的简介：
文章目录
- 1 ~> 协议背景：为什么需要 WebSocket
- 1.1 HTTP 固有模型限制
- 1.2 WebSocket 的设计目标
- 2 ~> WebSocket 协议核心原理
- 2.1 握手流程（协议升级）
- 2.2 通信特性
- 3 ~> SSE 协议核心原理
- 3.1 通信模型
- 3.2 内置能力
- 3.3 典型适用场景
- 4 ~> SSE 与 WebSocket 关键对比
- 5 ~> 面试重点：大模型流式对话为什么优先选用 SSE，而不是 WebSocket
- 5.1 业务模式匹配
- 5.2 工程架构层面优势
- 5.3 补充边界
- 6 ~> 典型业务选型总结
- 6.1 补充案例：在线五子棋
- 结尾
1 ~> 协议背景：为什么需要 WebSocket
1.1 HTTP 固有模型限制
- HTTP 是一问一答的请求‑响应模型，默认短连接；服务端无法在客户端没有发起请求的情况下主动推送数据。
- 现有方案局限
- 轮询：客户端周期性发起 HTTP 请求查询服务端是否有新数据
- 缺陷：大量无效请求；存在时间差，数据无法做到实时；HTTP1.0 每次轮询都要重建 TCP 握手。
- HTTP + 长连接 + 轮询：复用 TCP 连接，依旧无法解决无效请求、实时性差的根本问题。
- SSE（Server‑Sent‑Events）：基于 HTTP 长连接，单向通信，仅服务端向客户端推送。
- 适用场景：新闻推送、股票行情、大模型流式输出。
- 局限：不支持客户端向服务端实时回传消息，无法实现双向交互，群聊、多人在线游戏、在线五子棋这类双向实时场景无法直接使用 SSE 实现。
- 轮询：客户端周期性发起 HTTP 请求查询服务端是否有新数据
1.2 WebSocket 的设计目标
- 建立全双工长连接：连接建立完成后，客户端与服务端双方都可以随时向对方发送数据。
- 典型业务场景：在线五子棋、群聊、多人网络游戏、实时协作编辑。
2 ~> WebSocket 协议核心原理
2.1 握手流程（协议升级）
- 客户端发起普通 HTTP GET 请求，携带协议升级相关请求头，请求将连接升级为 WebSocket 协议。
- 服务端校验请求，返回 101 Switching Protocols 响应。
- HTTP 握手完成，底层 TCP 连接保留，后续通信不再使用 HTTP，切换为 WebSocket 帧格式通信。
- 协议标识
ws://：WebSocket 明文协议wss://：WebSocket over TLS，加密传输，对应 HTTP/HTTPS 关系。
2.2 通信特性
- 全双工：客户端、服务端可独立随时发送消息，不受请求‑响应次序约束。
- 支持文本帧、二进制帧两种数据载荷。
- 属于应用层协议，构建在 TCP 之上。
- 连接一旦建立持续保持，直到任意一方主动关闭、网络异常断开。
3 ~> SSE 协议核心原理
3.1 通信模型
- SSE 并非独立网络协议，是 HTTP 之上的扩展能力，基于
Transfer‑Encoding: chunked分块传输实现。 - 通信模式：一问多答。客户端发起一次 HTTP 请求，服务端持续分块推送事件数据；推送完毕返回
[DONE]标记，连接关闭。 - 通信方向：半双工，仅服务端 → 客户端单向推送；客户端无法在该长连接内回传数据，如果需要发数据，需要发起全新 HTTP 请求。
3.2 内置能力
- 自动断线重连：浏览器原生支持断开后自动重连。
- Last‑Event‑ID：客户端重连时携带上次接收事件 ID，服务端可补发丢失消息，实现消息断点续传。
3.3 典型适用场景
- 大模型 LLM 流式输出、实时日志推送、消息通知、比分行情。
4 ~> SSE 与 WebSocket 关键对比
| 特性 | SSE | WebSocket |
|---|---|---|
| 通信方向 | 半双工，仅服务端推送给客户端 | 全双工，客户端↔服务端双向自由收发 |
| 底层依赖 | HTTP/1.1、HTTP/2，基于 chunked 分块传输 | TCP，通过 HTTP 握手完成协议升级 |
| 数据格式 | 仅文本 | 文本、二进制均支持 |
| 断线重连 | 浏览器原生内置自动重连、Last‑Event‑ID | 无原生支持，需要业务层手动实现心跳、重连、消息去重 |
| 网络穿透 | 兼容 CDN、Nginx、负载均衡、老旧防火墙，运维成本低 | ws/wss 协议，部分老旧防火墙、代理会拦截协议升级报文 |
| 服务端资源开销 | 单向输出流，高并发场景内存 CPU 开销更低 | 全双工，需要维护状态机、双向缓冲区，资源开销更高 |
| 业务适配场景 | 单向流式输出：大模型对话、通知、日志流 | 双向强交互：在线游戏、群聊、实时协同编辑 |
5 ~> 面试重点：大模型流式对话为什么优先选用 SSE，而不是 WebSocket
5.1 业务模式匹配
- LLM 聊天交互模式：客户端发起请求 → 服务端流式返回结果，一轮对话结束连接结束。属于请求‑流式响应，不需要在生成过程中客户端往长连接内持续发送消息。SSE 天然适配。
- WebSocket 为全双工长连接，如果用于该场景，长连接会大量占用服务端资源；大量用户空闲时依然维持连接，服务端连接数压力巨大。
5.2 工程架构层面优势
- 网络基础设施兼容性：SSE 走标准 HTTP，各类代理、CDN、负载均衡兼容度远高于 WebSocket。
- 断线恢复能力：SSE 浏览器自带重连与事件 ID 断点续传；WebSocket 全部逻辑需要开发者手写。
- 模型推理状态管理
- 大模型推理依赖 KV‑Cache 显存上下文。
- SSE：一次请求对应一次推理任务，请求结束释放资源，生命周期清晰，不会出现生成中途客户端乱发消息带来的竞态问题。
- WebSocket 长连接允许客户端随时下发新消息，需要额外处理：生成中收到新指令是丢弃、排队还是打断，业务逻辑复杂度显著上升。
- 如何实现停止生成（Stop Generation）
- 面试官高频追问
- 不需要 WebSocket。客户端发送独立 POST 请求，携带任务 ID，服务端找到对应流式任务终止输出流即可。遵循关注点分离。
5.3 补充边界
- WebSocket 本身完全可以实现大模型流式输出，不是技术不可行；只是 SSE 以更低编码、运维、资源成本满足业务需求。
- SSE 在大模型行业爆发之后大规模普及，找到了自身核心落地场景。
6 ~> 典型业务选型总结
- 选用SSE：业务只需要服务端向客户端推送，客户端不需要在长连接通道内回传消息，例如 AI 流式输出、监控日志、消息通知。
- 选用WebSocket：业务需要双方频繁实时交互，例如在线对战游戏、聊天室、实时文档协同。
6.1 补充案例：在线五子棋
- SSE 无法实现：玩家 A 落子，服务端主动推送给玩家 B。SSE 要求客户端必须发起请求才能收到数据。
- 普通轮询：B 不停询问 “A 是否落子”，实时差大、无效请求多。
- WebSocket 最优：A、B 分别建立 ws 长连接；A 落子发送给服务端，服务端立刻转发给 B，双向实时同步棋局状态。
结尾
uu们，本文的内容到这里就全部结束了，艾莉丝在这里再次感谢您的阅读！
|
结语：希望对学习Linux相关内容的uu有所帮助，不要忘记给博主“一键四连”哦！
往期回顾：
【AI大模型接入SDK】SSE协议
🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡 ૮₍ ˶ ˊ ᴥ ˋ˶₎ა
