适合 服务器主动推送 或 高频双向数据交换 的场景 在WebSocket出现前，Web应用实现实时通信主要依赖HTTP的“请求-响应”模式，其局限性在于短连接和单向被动。每次交互都需要客户端主动发起请求，而服务器无法主动推送数据。这导致了效率低下，例如HTTP头部开销大，实时性差，服务器压力大。 与传统HTTP模式相比，WebSocket作为基于TCP的独立协议，它通过一次HTTP握手，在客户端和服务器之间建立一个持久化的全双工连接。此后，任何一方都可以随时主动发送数据，实现了真正的实时通信。它的核心优势包括：

• 极低的延迟：连接建立后，消息延迟可从秒级降至毫秒级。
• 高效传输：数据帧头部极小（仅2-14字节），相比动辄数百字节的HTTP头部，极大提升了带宽利用率。
• 减少开销：只需一次TCP握手建立持久连接，后续数据传输无需重复握手。

HTTP 不能服务端向客户端推送数据，SSE(Server-Sent Events) 适合一次请求之后服务端多次推送数据的场景。 类似聊天室这种，需要实时的双向通信的场景，还是得用 WebSocket SSE与 WebSocket 对比

维度	SSE	WebSocket
方向	单向（服务器 → 客户端）	全双工（双向实时）
协议	HTTP (纯文本)	独立协议 ws:// / wss://
实现复杂度	非常简单（服务端打印文本即可）	需要处理帧、掩码、心跳、关闭等
自动重连	内置	需要自己实现
二进制数据	需要编码	原生支持
浏览器兼容性	除 IE 外均支持，可用 polyfill	现代浏览器均支持
典型场景	通知、行情、监控仪表盘	聊天、游戏、协同编辑

• SSE：它不是一个独立的协议，而是 HTTP 协议的一种特定用法（通过 text/event-stream 媒体类型实现流式输出）。所以它完全复用 HTTP 的请求/响应模型，只是响应变成了“永不结束”的流。

• WebSocket：它是一个独立的应用层协议（ws:// 或 wss://），有自己的一套帧格式、掩码规则等。但它为了兼容网络基础设施（防火墙、代理等），握手阶段是用 HTTP 完成的（Upgrade 头部），握手成功后协议升级为 WebSocket。

所以它们的关系是：

TCP/IP 协议族
├── 应用层
│   ├── HTTP (SSE 基于此)
│   └── WebSocket (独立协议，但握手依赖 HTTP)
├── 传输层 (TCP/UDP)
└── 网络层 (IP)

无论哪种，底层最终都是通过 TCP 传输（WebSocket 也可通过 TLS 即 wss 加密） AI对话，背后主要依靠 “流式传输” 技术来模拟实时的打字效果。目前，主流方案普遍采用 SSE (Server-Sent Events) 协议，因为它足够简单，也最贴合“一问一答”的场景。对于需要更多功能（如中途打断、联网搜索）的复杂场景，则会用到 WebSocket。

下面是这两种技术的对比与选择分析，能帮你更好地理解它们是如何支撑起AI对话体验的。

特性	✅ SSE (主流选择)	🤹 WebSocket (复杂场景选择)
通信方向	单向 (服务器 → 客户端)	全双工 (服务器 ↔ 客户端)
协议基础	基于 HTTP/HTTPS，协议非常简单	独立协议 (ws:///wss://)，握手依赖HTTP
核心优势	简单、轻量、浏览器原生支持，无需额外库，自动重连	双向实时交互、功能灵活、一个连接可进行多轮操作
主要局限	仅支持服务器推送，客户端无法通过同一连接主动发送消息	协议复杂度高，连接开销较大
资源消耗	较低，首字响应时间可压缩至200ms以内	连接建立后开销小，时延可稳定在50ms以内
典型场景	典型的 ChatGPT、Claude 风格的Web端对话	需要联网搜索、中途打断、多轮工具调用或实时语音交互的Agent应用

---

🤔 为什么SSE成为大多数AI对话应用的主流选择？

对于面向大众的AI聊天应用，开发者和服务提供商通常会优先选择SSE，原因在于它精准地满足了核心需求，同时在技术和资源上实现了最佳的平衡。

• 完美的场景匹配：AI对话本质上是一问一答模式。用户发送一次请求，AI服务器持续生成并推送回答。SSE的单向推送特性，完美适配了这种模式，无需复杂的双向通信，大大降低了实现难度和成本。

• 极致的用户体验与效率：SSE允许服务器逐字或逐段地推送回答，产生了流式的“打字机”效果，用户能实时看到思考过程，有效缓解了等待焦虑。同时，这种方式在首字节响应时间上表现优异（低于200ms），内存占用也有显著优化（比传统方式降低60%以上）。

• 技术与生态的便捷性：

  • 简单易行：SSE基于标准的HTTP协议，实现简单。例如，Python的Flask框架中，几行代码就能快速搭建一个SSE服务端。

  • 原生支持：浏览器原生支持EventSource API，无需引入复杂的外部库，降低了前端开发的复杂度。

  • 自动重连：SSE协议内置了自动重连机制，能保证连接中断后的稳定性，无需在应用层做太多额外工作。

🦾 什么时候WebSocket会更合适？

AI应用的范围远不止基本的问答。当AI需要与环境、工具进行更复杂的交互时，仅靠SSE的单向通道就不够了。这时，WebSocket就成为了自然而然的选择。

你可以把SSE和WebSocket的关系，类比为早年的功能手机和智能手机：

• SSE (功能手机)：专为“通话”这一核心功能设计。它简单、可靠、省电，对于那些仅需“一问一答”的AI应用来说，是最高效、最直接的选择。

• WebSocket (智能手机)：它是一个强大的平台，可以承载各种复杂的应用。它的双向通信能力，允许它在完成“通话”的同时，还能“发短信”、“上网”、“用App”，对于需要处理复杂任务的AI来说，是更合适的平台。

一个典型的例子是 “Agent”（智能体） 类应用。在这种场景下，AI不仅需要和你对话，还可能调用搜索引擎、预订机票、或其他工具来帮你完成任务。整个过程可能会涉及多轮交互，比如：

1. 用户提问：“帮我订一张下周去北京的机票。”

2. AI可能需要调用工具搜索航班，并将几个选项推送给用户。

3. 用户需要选择其中一个选项，这个“选择”动作需要主动发送回服务器。

4. AI再根据用户的选择，继续进行下一步操作。

在这个多轮、交互式的流程中，SSE的单向推送就无能为力了。而WebSocket的全双工特性，允许客户端在生成过程中随时发送“打断”、“选择选项”或“补充信息”等指令，实现真正的实时互动，这正是WebSocket的优势所在。

此外，WebSocket协议效率更高，其数据帧头部只有 2-6字节，远小于HTTPS/SSE的头部开销，对于需要高频率、低延迟推送的场景也有理论优势。

• 一个服务器进程可以同时监听多个端口，每个端口支持不同的协议。
• 也可以在同一个端口上多路复用多种协议（比如 HTTP + WebSocket，或者 HTTP + gRPC 等，只要协议设计允许）。

webworker