为什么 DeepSeek 采用 SSE 而不是 WebSocket?

DeepSeek 采用 SSE（Server-Sent Events） 而非 WebSocket，主要基于以下技术考量和实际需求：

1. 通信模式差异

DeepSeek 场景：
AI 对话通常只需服务器推送响应（问答流式输出），无需客户端频繁上行数据，SSE 的单向特性更契合。

2. 技术优势对比

SSE 的优势

• 原生浏览器支持：
  通过标准 EventSource API 实现，无需第三方库。

  const es = new EventSource("/api/chat");
  es.onmessage = (e) => console.log(e.data);

• 自动重连：
  内置连接中断重试机制（retry 字段控制）。

• HTTP 友好：
  复用 HTTP 协议栈，兼容现有基础设施（CDN/负载均衡/防火墙）。

WebSocket 的局限性

• 过度设计：
  双向通信能力在 AI 对话中非必需，增加实现复杂度。

• 连接维护成本：
  需手动处理心跳保活、重连等逻辑。

• 协议升级开销：
  Upgrade: websocket 握手过程略长。

• 轻量级：
  数据包头更小，适合文本流传输（如 AI 生成的逐字输出）。

3. 性能与效率

DeepSeek 选择：
AI 响应通常是文本流（如逐字生成），SSE 的文本流模式天然匹配，且服务端资源消耗更低。

4. 实际应用场景

SSE 典型用例

WebSocket 更适合

• 实时游戏/聊天室（双向高频通信）

• 股票行情（二进制数据压缩）

• 协同编辑（多端双向同步）

5. 兼容性与降级方案

• SSE 兼容性：
  所有现代浏览器支持（IE 除外，可通过 polyfill 或降级为长轮询）。

• DeepSeek 的容错：
  可结合 Last-Event-ID 实现断点续传，保障消息完整性。

6. 安全性考量

• SSE：
  复用 HTTP 安全机制（CORS/HTTPS/Cookie）。

• WebSocket：
  需额外实现鉴权（如 Sec-WebSocket-Protocol）。

总结：DeepSeek 的选择逻辑

1. 功能匹配：单向数据流满足 AI 对话需求

2. 开发效率：减少不必要的双向通信实现

3. 运维成本：利用 HTTP 现有生态（监控/日志/缓存）

4. 用户体验：快速建立连接，流畅接收流式响应

对于需要客户端频繁上传数据的场景（如实时语音转文字），WebSocket 可能更合适，但纯文本交互场景下 SSE 是更精简高效的解决方案。