🎬 个人主页：艾莉丝努力练剑

❄专栏传送门：《C语言》《数据结构与算法》《C/C++干货分享&学习过程记录》
《Linux操作系统编程详解》《笔试/面试常见算法：从基础到进阶》《Python干货分享》

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

文章目录

• 1 ~> 协议背景：为什么得 WebSocket
• 1.1 HTTP 固有模型限制
• 1.2 WebSocket 的设计目标

• 2.1 握手流程（协议升级）
• 2.2 通信特性

• 3.1 通信模型
• 3.2 内置能力
• 3.3 典型适用场景

• 5.1 业务模式匹配
• 5.2 工程架构层面优势
• 5.3 补充边界

• 6.1 补充案例：在线五子棋

1 ~> 协议背景：为什么得 WebSocket

1.1 HTTP 固有模型限制

• HTTP 是一问一答的请求‑响应模型，默认短连接；服务端无法在客户端没有发起请求的情况下主动推送数据。
• 现有方案局限

• HTTP + 长连接 + 轮询：复用 TCP 连接，依旧无法解决无效请求、实时性差的根本坑。

• 局限：不支持客户端向服务端实时回传消息，无法达成双向交互，群聊、多人在线游戏、在线五子棋这类双向实时场景无法直接使用 SSE 达成。

1.2 WebSocket 的设计目标

• 建立全双工长连接：连接建立做好后，客户端与服务端双方都能随时向对方发送数据。
• 典型业务场景：在线五子棋、群聊、多人网络游戏、实时协作编辑。

2 ~> WebSocket 协议核心原理

2.1 握手流程（协议升级）

1. 客户端发起普通 HTTP GET 请求，携带协议升级相关请求头，请求将连接升级为 WebSocket 协议。
2. 服务端校验请求，返回 101 Switching Protocols 响应。
3. HTTP 握手做好，底层 TCP 连接保留，后续通信不再使用 HTTP，切换为 WebSocket 帧格式通信。

• 协议标识

• wss://：WebSocket over TLS，加密传输，对应 HTTP/HTTPS 关系。

2.2 通信特性

• 全双工：客户端、服务端可独立随时发送消息，不受请求‑响应次序约束。
• 支持文本帧、二进制帧两种数据载荷。
• 属于应用层协议，构建在 TCP 之上。
• 连接一旦建立持续保持，直到任意一方主动关闭、网络异常断开。

3 ~> SSE 协议核心原理

3.1 通信模型

• SSE 并非独立网络协议，是 HTTP 之上的扩展能力，基于Transfer‑Encoding: chunked分块传输达成。
• 通信模式：一问多答。客户端发起一次 HTTP 请求，服务端持续分块推送事件数据；推送完毕返回[DONE]标记，连接关闭。
• 通信方向：半双工，仅服务端 → 客户端单向推送；客户端无法在该长连接内回传数据，如果得发数据，需要发起全新 HTTP 请求。

3.2 内置能力

1. 自动断线重连：浏览器原生支持断开后自动重连。
2. Last‑Event‑ID：客户端重连时携带上次接收事件 ID，服务端可补发丢失消息，实现消息断点续传。

3.3 典型适用场景

• 大模型 LLM 流式输出、实时日志推送、消息通知、比分行情。

4 ~> SSE 与 WebSocket 关键对比

特性SSEWebSocket通信方向半双工，仅服务端推送给客户端全双工，客户端↔服务端双向自由收发底层依赖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 工程架构层面优势

1. 网络基础设施兼容性：SSE 走标准 HTTP，各类代理、CDN、负载均衡兼容度远高于 WebSocket。
2. 断线恢复能力：SSE 浏览器自带重连与事件 ID 断点续传；WebSocket 全部逻辑需要开发者手写。
3. 模型推理状态管理
大模型推理依赖 KV‑Cache 显存上下文。
4. SSE：一次请求对应一次推理任务，请求结束释放资源，生命周期清晰，不会出现生成中途客户端乱发消息带来的竞态坑。
5. WebSocket 长连接允许客户端随时下发新消息，需要额外处理：生成中收到新指令是丢弃、排队还是打断，业务逻辑复杂度显著上升。

如何实现停止生成（Stop Generation）

1. 面试官高频追问
2. 不需要 WebSocket。客户端发送独立 POST 请求，携带任务 ID，服务端找到对应流式任务终止输出流即可。遵循关注点分离。

5.3 补充边界

• WebSocket 本身完全能实现大模型流式输出，不是技术不可行；只是 SSE 以更低编码、运维、资源成本满足业务需求。
• SSE 在大模型行业爆发之后大规模普及，找到了自身核心落地场景。

6 ~> 典型业务选型总结

• 选用 SSE：业务只需要服务端向客户端推送，客户端不需要在长连接通道内回传消息，举个例子 AI 流式输出、监控日志、消息通知。
• 选用 WebSocket：业务需要双方频繁实时交互，举个例子在线对战游戏、聊天室、实时文档协同。

6.1 补充案例：在线五子棋

1. SSE 无法实现：玩家 A 落子，服务端主动推送给玩家 B。SSE 要求客户端必须发起请求才能收到数据。
2. 普通轮询：B 不停询问 “A 是否落子”，实时差大、无效请求多。
3. WebSocket 最优：A、B 分别建立 ws 长连接；A 落子发送给服务端，服务端立刻转发给 B，双向实时同步棋局状态。

结尾

uu们，这篇文章的内容到这里就全部结束了，艾莉丝在这里再次

艾莉丝努力练剑