为什么大模子网站利用 SSE 而不是 WebSocket？

在大模子网站（如 ChatGPT、Claude、Gemini 等）中，前端通常利用 EventSource（Server-Sent Events, SSE） 来与后端对接，而不是 WebSocket。这是由于 SSE 更适合类似流式文本生成的场景。下面我们具体对比 SSE、WebSocket 和其他可选方案。
  

---

1. SSE（Server-Sent Events，服务器发送事件）

特点：

• 单向通讯（服务器 → 客户端），实用于大模子输出流式文本的场景。
  
• 基于 HTTP/1.1 及 EventSource API，兼容性较好，易于集成。
  
• 自动重连，如果毗连断开，浏览器会自动实验重新毗连。
  
• 轻量级，开销小，适合传输文本数据。
  

缺点：

• 只支持 服务器推送，客户端无法主动发送消息（必要用 AJAX/Fetch 结合）。
  
• 受 同源策略 影响，跨域时必要 CORS 配置。
  
• 在 HTTP/2 之前，SSE 只能打开 6 个毗连（浏览器限制），但在 HTTP/2 上可复用单毗连，题目减小。
  

实用场景：

✔ 流式返回（如 ChatGPT 逐字输出）
✔ 服务器向前端持续推送数据（如股票行情、日志监控）

---

2. WebSocket

特点：

• 全双工通讯，客户端和服务器可以随时相互发送数据。
  
• 基于 TCP，独立于 HTTP，但通常通过 HTTP/HTTPS 协商（ws:// 或 wss://）。
  
• 低延长，实用于高频交互（如及时聊天、游戏、协作编辑）。
  

缺点：

• 毗连管理复杂（心跳检测、断线重连、负载平衡较难）。
  
• 署理/防火墙兼容性题目，某些企业网络可能会制止 WebSocket。
  
• 服务器资源占用更大，必要维护长毗连，占用线程/内存。
  

实用场景：

✔ 双向及时交互（如在线协作、弹幕、游戏匹配）
✔ 低延长高频数据更新（如金融生意业务、物联网）
为什么大模子网站不用 WebSocket？

• WebSocket 实用于双向通讯，而 大模子的输出是“流式”文本，客户端只需接收数据，WebSocket 的优势无法体现。
  
• WebSocket 必要额外的 毗连管理，而 SSE 依靠于现有的 HTTP 毗连，更易集成。
  

---

3. HTTP 长轮询（Long Polling）

特点：

• 客户端发送请求，服务器 保持毗连不返回数据，直到有新数据才返回。
  
• 客户端收到数据后立即发送新的请求，模拟流式通讯。
  
• 兼容性极好，所有 HTTP 服务器都支持。
  

缺点：

• 请求开销大，每次返回数据后都必要重新创建 HTTP 毗连，浪费资源。
  
• 延长较高，如果服务器没有数据，客户端必须定期请求，服从低。
  

---

4. gRPC（基于 HTTP/2 的流式通讯）

特点：

• 双向流式通讯（客户端和服务器都可以持续发送数据）。
  
• 基于 HTTP/2，性能较好，可在单个毗连上多路复用请求。
  
• 实用于微服务通讯，比 REST API 更高效。
  

缺点：

• 浏览器原生不支持，必要利用 gRPC-Web 署理转换。
  
• 复杂度高，部署比 SSE/WebSocket 难。
  

---

总结：哪种方式适合大模子前端？

方案是否实用于大模子流式返回？特点实用场景SSE（EventSource）✅ 最佳选择服务器 → 客户端单向推送，轻量、自动重连流式输出（ChatGPT）、及时通知WebSocket❌ 过分计划双向通讯，低延长，复杂毗连管理聊天、游戏、协作编辑长轮询（Long Polling）❌ 开销大兼容性强但服从低，每次数据返回后需重新请求旧系统支持gRPC（HTTP/2 流）❌ 必要署理双向流式，高性能，浏览器需 gRPC-Web微服务、API 交互