WebSocket 和 SSE 通信的区别及局限性

一、 核心概念与协议底层原语透视

在传统的 Web 开发中，HTTP 是典型的"请求-响应（Request-Response）"半双工通信协议。为了打破"客户端不发请求，服务端就无法主动通知"的限制，工业界先后经历了短轮询（Polling）、长轮询（Long-Polling/Comet）、WebSocket 到 SSE 的演进历程。

┌────────────────────────────────────────────────────────────────────────┐
│                        Web 实时通信演进路线图                          │
├────────────────────────────────────────────────────────────────────────┤
│ 1. 短轮询 (Polling)     : 客户端定时无差别发起 HTTP 请求 (资源浪费极高) │
│ 2. 长轮询 (Long-Polling): 服务端挂起 HTTP 请求直至有数据 (连接频繁开闭)│
│ 3. WebSocket            : 协议升级，建立基于 TCP 的全双工长连接 (独立协议) │
│ 4. SSE (Server-Sent)    : 复用标准 HTTP 单向长连接，流式下发事件 (轻量规范)│
└────────────────────────────────────────────────────────────────────────┘

1.1 WebSocket 协议原语：脱离 HTTP 的全双工通道

WebSocket（RFC 6455）并不是对 HTTP 的简单修补，而是借助 HTTP 完成初始握手后，彻底切换为独立的基于 TCP 的应用层协议。

握手生命周期（Handshake）

客户端首先发起一个标准的 HTTP/1.1 GET 请求，通过特定的请求头告知服务器希望升级协议：

GET /chat HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com

服务器如果支持 WebSocket，则返回状态码 101 Switching Protocols 完成升级：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

握手成功后，底层 TCP 连接被保留，随后的所有数据交换完全脱离 HTTP 语义，进入自定义的二进制帧（Frame）传输阶段。

WebSocket 数据帧结构（Frame Protocol）

WebSocket 的高效来源于极低的数据包开销。一个标准数据帧的头部仅占用 2 到 14 个字节：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+---------------------------------------------------------------+

• FIN（1 bit）：指示当前帧是否是消息的最后一个分片。

• Opcode（4 bits） ：定义帧类型。例如 0x1 表示文本帧（UTF-8），0x2 表示二进制帧，0x8 表示关闭连接，0x9 表示 Ping，0xA 表示 Pong。

• MASK（1 bit） ：客户端发送给服务端的数据必须进行掩码加密（防止代理缓存污染攻击），服务端发给客户端的数据则不能进行掩码。

• Payload length（7 / 7+16 / 7+64 bits）：灵活支持从小至几字节、大到 GB 级别的负载。

1.2 SSE 协议原语：标准 HTTP 下的文本流式推送

SSE（Server-Sent Events，W3C 规范）并没有创造新的传输层协议，它完全依托于标准的 HTTP 协议。

其底层核心机制是：客户端向服务器发起一个普通的 HTTP GET 请求，服务器返回特定的响应头，告知客户端此连接将永久保持打开状态，并以分块流式形式下发数据。

HTTP 响应头定义

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8
Cache-Control: no-cache
Connection: keep-alive
X-Accel-Buffering: no

SSE 报文帧结构

SSE 规定服务端推送的内容必须为 UTF-8 编码的纯文本，由一系列通过两个连续换行符 \n\n 分隔的事件块组成：

event: custom_event_type
id: message_seq_1024
retry: 5000
data: {"user": "Alice", "message": "Hello World"}

event: ping
data: keep-alive-packet

data: 这是一个没有指定自定义事件类型的默认 message 块
data: 跨越多行的数据会自动拼接

: 这是一行注释，可用于服务端发送周期性心跳保活

• data: 承载数据本体，可多行连续发送，客户端接收时会自动以换行符拼接。

• id: 事件唯一标识。客户端会在断线重连时，通过 Last-Event-ID 请求头自动上报给服务器，实现无感断点续传。

• event: 自定义事件名称。前端可通过 addEventListener("custom_event_type", ...) 实现定向监听。

• retry: 建议客户端在网络断开后，等待多少毫秒后自动发起重连（默认通常为 3 秒）。

• : 以冒号开头的行为注释行，浏览器原生解析器会直接忽略，常用于传输保活心跳包以防止网关超时断连。

二、 维度级技术全景对比矩阵

为了建立系统的技术选型认知，以下将 WebSocket 与 SSE 在协议层、性能层、运维层及工程实践层进行逐项横向对照：

对比维度	WebSocket	Server-Sent Events (SSE)
协议层级	独立的 TCP 应用层协议（ws:// 或 wss://）	标准 HTTP 协议（http:// 或 https://）
通信流向	全双工（Full-Duplex）：双向对等实时收发	单向（Unidirectional）：仅服务端向客户端单向推送
数据载荷格式	原生支持 UTF-8 文本、二进制（ArrayBuffer、Blob）	原生仅支持 UTF-8 文本（二进制需 Base64 编码）
HTTP/2 多路复用	复杂，需 RFC 8441 扩展，目前大部分网关支持不佳	天然原生支持 HTTP/2，可在一个 TCP 连接上并发多路流
连接维护成本	高。需要专门的有状态服务节点，维护 TCP 长连接	低。复用传统 Web 服务器（Nginx、Node、Go、Java 等）
重连机制	无原生支持。必须由开发者手动编写心跳检测与退避重连	浏览器原生自带重连机制 ，并附带 Last-Event-ID 状态续传
防火墙/代理友好度	较差。一些企业级防火墙会主动阻断非标准 HTTP Upgrade	极高。本质是标准 HTTP 流量，穿透所有网关、CDN 与代理
认证与中间件	建立连接后脱离 HTTP，Cookie/Header 无法随单帧更新	完全兼容现有的 API 网关认证、JWT、OAuth、Cookie 机制
客户端 API	浏览器原生 WebSocket API，功能完备	原生 EventSource API（存在缺陷，常被 fetch 替代）
典型适用场景	实时竞技游戏、协同文档（Figma）、高频双向交易系统	LLM 流式吐字（ChatGPT）、监控仪表盘、消息通知中心

三、 WebSocket 的工程局限性与深水陷阱

尽管 WebSocket 在实时全双工领域处于统治地位，但在真实的工业级后端架构中，引入 WebSocket 往往伴随着沉重的维护包袱。

                      [用户流量入口]
                            │
                            ▼
                  [L4/L7 负载均衡集群]
                (必须配置 IP Hash 或会话保持)
                 /          │          \
                ▼           ▼           ▼
        [Node Server 1] [Node Server 2] [Node Server 3]
                \           │           /
                 ▼          ▼          ▼
            [Redis Pub/Sub 分布式消息总线]
        (任何跨节点的广播与推送，都必须走外部消息队列)

1. 破坏无状态架构，增加水平扩展难度

标准的 Web 服务提倡无状态（Stateless）设计，应用容器可以根据流量随时进行弹性扩缩容（HPA），任何一台机器挂掉，网关只需将后续请求路由到其他实例即可。

但 WebSocket 是强状态长连接：

• 用户 A 连接到机器 1，用户 B 连接到机器 2。如果用户 A 想向用户 B 发送消息，机器 1 无法直接推给用户 B。

• 架构代价：必须引入额外的分布式发布/订阅层（如 Redis Pub/Sub、Kafka、RabbitMQ）来打通跨节点的连接状态。

• 扩缩容震荡：当服务集群缩容或重启发布时，必须执行复杂的优雅下线（Graceful Shutdown）流程，避免成千上万个客户端在同一瞬间同时断开并触发"惊群效应（Thundering Herd）"打垮网关。

2. 无法享受 HTTP 生态与 CDN 边缘加速红利

一旦协议从 HTTP 升级为 WebSocket，后续传输的全部数据帧将完全脱离 HTTP 上下文：

• 无缓存能力：无法利用浏览器缓存、CDN 边缘节点缓存或 Nginx 代理缓存。

• API 网关拦截失效：企业内部现有的鉴权过滤器、限流器（Rate Limiter）、日志审计中间件、WAF（Web 应用防火墙）通常深度依赖 HTTP Headers 和 URL Path。在 WebSocket 通道内，业务消息是自定义二进制或 JSON 字符串，网关无法透明解析与审计。

• 错误状态码缺失 ：HTTP 请求失败会有 401 Unauthorized、403 Forbidden、429 Too Many Requests 等明确语义；而 WebSocket 在建立连接后若发生异常，通常只能由客户端或服务端抛出一个笼统的 1006 Abnormal Closure 错误码，故障排查极为繁琐。

3. "幽灵连接（Ghost Connection）"与复杂的保活机制

在移动网络或跨地域广域网中，客户端由于进入电梯、熄屏休眠或基站切换，物理链路可能已经彻底中断，但操作系统的 TCP 连接处于"半打开（Half-Open）"状态，双方的 Socket 均没有收到 FIN 或 RST 报文。

• 服务端依然在内存中为该死连接维护 Session 对象，持续占用文件描述符（FD）和内存资源；

• 如果服务端继续向该连接写入数据，直到 TCP 发送缓冲区填满触发超时，才会感知连接已死；

• 开发负担 ：开发者必须在应用层自主实现高可用的双向心跳探测机制（Ping/Pong 协议），并在客户端实现指数退避重连（Exponential Backoff with Jitter），稍有不慎就会导致客户端死锁或重试风暴。

四、 SSE 的工程局限性与深水陷阱

既然 SSE 继承了 HTTP 的所有优势，为什么在过去很长一段时间内没有全面替代 WebSocket？因为 SSE 本身同样存在若干关键的物理限制。

1. 单向通信的硬伤（半双工约束）

SSE 严格定义为服务端到客户端的单向流。

如果客户端在接收服务端流式数据的同时，想要主动向服务端发送控制指令（例如：在大模型回答过程中，用户点击了"暂停生成"或发送了新的追问）：

• 客户端不能复用当前这个 SSE 连接回传数据；

• 必须在外部通过传统的 HTTP POST 或 PUT 请求另行发起一次调用；

• 服务端必须在业务逻辑层将新发起的 POST 请求与正在持续输出的 SSE 会话（Session ID）进行手动关联。

2. HTTP/1.1 下同域名 6 个并发连接数的物理限制

这是在 SSE 实际开发中最容易踩中的"浏览器级大坑"：

根据 HTTP/1.1 协议规范与现代浏览器（Chrome、Firefox 等）的实现，同一个浏览器对同一个域名（Domain）的最大持久并发连接数被限制为 6 个。

[浏览器标签页 1] ──(SSE 连接 1)──► api.example.com
[浏览器标签页 2] ──(SSE 连接 2)──► api.example.com
[浏览器标签页 3] ──(SSE 连接 3)──► api.example.com
[浏览器标签页 4] ──(SSE 连接 4)──► api.example.com
[浏览器标签页 5] ──(SSE 连接 5)──► api.example.com
[浏览器标签页 6] ──(SSE 连接 6)──► api.example.com
────────────────────────────────────────────────────
[浏览器标签页 7] ──(发起普通 API 请求) ➔ 【严重阻塞！请求排队无法发出】

如果用户在浏览器中打开了多个标签页，每个页面都维持一个 SSE 连接：

• 一旦打开超过 6 个标签页，第 7 个页面发起的所有 HTTP 请求（包括普通接口调用、图片资源加载）将被浏览器强制挂起排队，导致整个站点看似彻底卡死！

• 解决方案 ：生产环境中使用 SSE，必须开启 HTTP/2 或 HTTP/3 支持。在 HTTP/2 的多路复用（Multiplexing）机制下，所有 SSE 流与常规 API 均共享同一个底层的 TCP 连接，彻底解除 6 个连接的上限约束。

3. 反向代理（Nginx / CDN）缓冲陷阱

SSE 依赖底层数据能够即时（Real-time）刷入网络 。然而，企业级链路中的代理服务器（如 Nginx、Envoy）为了提升网络吞吐量，默认开启了响应缓冲区（Response Buffering）。

• Nginx 会在内存中积攒后端服务返回的数据（通常为 4KB 或 8KB），直到缓冲区被填满，才统一向客户端刷出一次网络包。

• 直接后果：原本应该"一个字一个字向外蹦"的打字机流，在用户端变成了"卡顿数秒后突然一次性吐出一大段"，流式体验彻底失效。

• 解决方案 ：必须在 Nginx 反向代理层显式关闭缓冲，或由后端服务主动下发特定的响应头（如 X-Accel-Buffering: no）。

4. 浏览器原生 EventSource API 的缺陷

HTML5 提供了内置的 window.EventSource 对象，用于快速建立 SSE 连接。然而在企业级开发中，原生 EventSource 几乎无法直接投入生产：

• 只支持 GET 请求：无法在建立连接时通过 HTTP 请求体（Body）向后端提交庞大的结构化参数（如复杂的 Prompt、多轮历史对话上下文）。

• 无法自定义 Request Headers ：原生 API 不支持在请求头中注入 Authorization: Bearer <Token> 鉴权信息，迫使开发者只能通过 URL Query 参数传递 Token，带来严重的 URL 日志泄漏安全隐患。

• 生产标准做法 ：抛弃原生 EventSource，改用现代浏览器的 fetch API 配合 response.body.getReader()（ReadableStream），手动解析 SSE 文本帧。

五、 生产级端到端代码实战

为了清晰掌握两者的工程落地细节，本节分别提供包含心跳保活、异常处理与流式控制的高可用实现代码。

5.1 WebSocket 工业级实现：带心跳与指数退避重连

以下为一个健壮的前端 WebSocket 封装类，具备心跳保活检测、双向 Ping/Pong 与随机抖动指数退避重连机制。

export class ResilientWebSocket {
  private url: string;
  private ws: WebSocket | null = null;
  private isAlive: boolean = false;
  private heartbeatTimer: number | null = null;
  private reconnectAttempts: number = 0;
  private maxReconnectAttempts: number = 10;
  private baseDelay: number = 1000; // 基础延迟 1s
  private maxDelay: number = 30000; // 最大延迟 30s
  private isManuallyClosed: boolean = false;

  constructor(url: string) {
    this.url = url;
  }

  public connect(): void {
    this.isManuallyClosed = false;
    this.ws = new WebSocket(this.url);

    this.ws.onopen = () => {
      console.info("[WS] 连接建立成功");
      this.reconnectAttempts = 0;
      this.isAlive = true;
      this.startHeartbeat();
    };

    this.ws.onmessage = (event: MessageEvent) => {
      this.isAlive = true; // 收到任何报文均证明连接健康
      if (event.data === "PONG") {
        return; // 消费心跳应答
      }
      this.handleBusinessMessage(event.data);
    };

    this.ws.onerror = (error: Event) => {
      console.error("[WS] 触发错误:", error);
    };

    this.ws.onclose = (event: CloseEvent) => {
      console.warn(`[WS] 连接关闭，Code: ${event.code}, Reason: ${event.reason}`);
      this.stopHeartbeat();
      if (!this.isManuallyClosed) {
        this.scheduleReconnect();
      }
    };
  }

  private startHeartbeat(): void {
    this.stopHeartbeat();
    this.heartbeatTimer = window.setInterval(() => {
      if (!this.isAlive) {
        console.warn("[WS] 心跳超时未收到应答，判定为幽灵连接，主动切断");
        this.ws?.close();
        return;
      }
      this.isAlive = false;
      this.send("PING");
    }, 15000); // 每 15 秒探测一次
  }

  private stopHeartbeat(): void {
    if (this.heartbeatTimer !== null) {
      clearInterval(this.heartbeatTimer);
      this.heartbeatTimer = null;
    }
  }

  private scheduleReconnect(): void {
    if (this.reconnectAttempts >= this.maxReconnectAttempts) {
      console.error("[WS] 超出最大重试次数，终止重连");
      return;
    }

    // 指数退避算法 + 随机抖动 (Jitter)
    const exponentialBackoff = Math.min(
      this.maxDelay,
      this.baseDelay * Math.pow(2, this.reconnectAttempts)
    );
    const jitter = Math.random() * 1000;
    const delay = exponentialBackoff + jitter;

    this.reconnectAttempts++;
    console.info(`[WS] 将在 ${Math.round(delay)}ms 后发起第 ${this.reconnectAttempts} 次重连...`);

    window.setTimeout(() => {
      this.connect();
    }, delay);
  }

  public send(data: string | ArrayBuffer): void {
    if (this.ws && this.ws.readyState === WebSocket.OPEN) {
      this.ws.send(data);
    } else {
      console.error("[WS] 发送失败，连接未就绪");
    }
  }

  public close(): void {
    this.isManuallyClosed = true;
    this.stopHeartbeat();
    this.ws?.close();
  }

  private handleBusinessMessage(data: any): void {
    console.log("[WS 业务数据]:", data);
  }
}

5.2 SSE 工业级实现：FastAPI 服务端与前端 fetch 流式消费

服务端实现（Python / FastAPI）

展示如何输出标准的 SSE 帧、设置防缓冲头并维持心跳。

import asyncio
import json
import time
from typing import AsyncGenerator
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse

app = FastAPI()

async def server_event_generator(req: Request) -> AsyncGenerator[str, None]:
    """生成符合 SSE 标准规范的事件数据流"""
    sequence_id = 0
    
    # 提取客户端自动上报的历史位点 (用于断点续传)
    last_event_id = req.headers.get("last-event-id")
    if last_event_id:
        sequence_id = int(last_event_id)
        print(f"[SSE] 客户端从位点 {sequence_id} 恢复断线连接")

    while True:
        # 检测客户端是否已经主动中断请求
        if await req.is_disconnected():
            print("[SSE] 客户端连接主动断开")
            break

        sequence_id += 1
        
        # 1. 业务数据帧
        payload = json.dumps({"timestamp": time.time(), "metric_value": 42.5})
        yield f"id: {sequence_id}\n"
        yield f"event: metric_update\n"
        yield f"retry: 3000\n" # 建议客户端断线 3s 后重连
        yield f"data: {payload}\n\n"

        # 2. 定期注入注释行作为轻量级保活心跳
        yield f": keep-alive ping\n\n"

        await asyncio.sleep(2.0)

@app.get("/api/v1/stream/metrics")
async def stream_metrics(request: Request):
    return StreamingResponse(
        server_event_generator(request),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "Connection": "keep-alive",
            "X-Accel-Buffering": "no", # 核心头：通知 Nginx 禁用代理缓冲
            "Access-Control-Allow-Origin": "*"
        }
    )

前端工业级消费实现（TypeScript / fetch + ReadableStream）

绕过原生 EventSource 的局限，支持自定义 POST、自定义 Headers 鉴权并处理多字节中文分片。

export async function consumeSSEWithFetch(
  url: string,
  authToken: string,
  bodyData: object,
  onMessage: (data: string) => void
): Promise<void> {
  const response = await fetch(url, {
    method: "POST", // 支持 POST 传输复杂参数
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${authToken}`, // 支持传递认证头
      "Accept": "text/event-stream"
    },
    body: JSON.stringify(bodyData)
  });

  if (!response.ok || !response.body) {
    throw new Error(`HTTP 异常状态码: ${response.status}`);
  }

  const reader = response.body.getReader();
  // 必须开启 stream: true 模式，防止中文等多字节字符在跨包切分时出现乱码
  const decoder = new TextDecoder("utf-8");
  let partialChunkBuffer = "";

  while (true) {
    const { done, value } = await reader.read();
    if (done) {
      console.info("[SSE] 数据流正常接收完毕");
      break;
    }

    // 拼接前序未处理完的残留字节
    partialChunkBuffer += decoder.decode(value, { stream: true });

    // 按 SSE 协议约定的双换行符 \n\n 切分事件块
    const eventBlocks = partialChunkBuffer.split("\n\n");
    // 保留最后一段不完整的帧数据
    partialChunkBuffer = eventBlocks.pop() || "";

    for (const block of eventBlocks) {
      const trimmedBlock = block.trim();
      if (!trimmedBlock || trimmedBlock.startsWith(":")) {
        // 忽略空行以及冒号开头的保活注释
        continue;
      }

      const lines = trimmedBlock.split("\n");
      for (const line of lines) {
        if (line.startsWith("data:")) {
          const content = line.substring(5).trim();
          onMessage(content);
        }
      }
    }
  }
}

六、 企业级反向代理与网关调优配置（Nginx）

在真实生产部署中，无论 WebSocket 还是 SSE，都必须经过 Nginx、Traefik 或 API 网关。若未正确配置代理策略，系统将出现断流、卡顿或握手失败。

6.1 Nginx 对 WebSocket 的标准反向代理配置

由于 WebSocket 握手请求需要将 HTTP 转换为长连接，Nginx 必须显式捕获并转发 Upgrade 和 Connection 头：

# 定义协议升级映射关系
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream ws_backend_cluster {
    # WebSocket 属于有状态连接，强烈建议配置 ip_hash 或一致性 Hash
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

server {
    listen 443 ssl http2;
    server_name ws.example.com;

    location /chat {
        proxy_pass http://ws_backend_cluster;
        
        # 核心设置：传递 WebSocket 升级头
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # 保持客户端真实 IP
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # 延长长连接读写超时时间（默认通常为 60s，超时未收到数据会被 Nginx 主动掐断）
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

6.2 Nginx 对 SSE 的防卡顿透传配置

针对 SSE 的核心痛点是关闭一切缓冲行为：

server {
    listen 443 ssl http2;
    server_name api.example.com;

    location /api/v1/stream {
        proxy_pass http://backend_cluster;

        # 核心设置 1：必须关闭响应缓冲，使每一个分片立刻推向客户端
        proxy_buffering off;
        proxy_cache off;

        # 核心设置 2：关闭分块传输缓冲区聚合
        chunked_transfer_encoding on;

        # 核心设置 3：保持长连接协议版本
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # 核心设置 4：防止长等待超时（大模型长思考时尤为重要）
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

七、 工业级场景选型决策树

在面对具体的业务系统设计时，可以按照以下决策逻辑快速判断技术路线：

                           [实时通信需求确认]
                                   │
               是否需要客户端高频、低延迟地向服务端回传数据？
                                   │
                  ┌────────────────┴────────────────┐
                  ▼                                 ▼
               【是】                              【否】
                  │                                 │
     是否必须传输原生二进制文件/音频？           主要场景是否为文本/指标单向推送？
                  │                          (如 LLM 问答、系统看板、通知)
        ┌─────────┴─────────┐                       │
        ▼                   ▼                       ▼
     【是】                【否】              优先选用 SSE
  坚决选用 WebSocket   可评估双向 REST       (依托 HTTP/2，架构成本低)
 (如在线协作白板、    或依然选用 WS
  实时 FPS 游戏)

典型场景定性落地指引

1. 大语言模型（LLM）对话与打字机输出：

   • 优选 SSE。交互模式是典型的"输入一段长 Prompt，服务端连续吐字"。单向流式特性与 SSE 完美吻合，且可无缝穿越各类企业的安全防火墙，免去部署独立 WebSocket 接入层的成本。

2. 多人实时协作编辑（如 Figma、文档协同）：

   • 优选 WebSocket。用户的每一次光标移动、键盘敲击都会转化为细粒度的操作变换（OT/CRDT）并广播给其他协作者，要求极低的毫秒级双向网络往返延迟。

3. 金融资产行情与加密货币实时看盘：

   • 混合模式。纯公开的大盘行情看板，使用 SSE 可以借助 HTTP 基础设施轻松实现巨量并发分发；而高频下单、撤单交易终端则使用 WebSocket 保证指令即时双向穿透。

4. 即时通讯（IM）与在线客服系统：

   • 优选 WebSocket。消息双方需要双向频繁沟通，且通常包含"正在输入中"、"消息已读回执"等即时信令。

八、 走向 WebTransport：未来的下一代演进

从计算机网络的发展轨迹来看，WebSocket 和 SSE 都是在传统 TCP 和 HTTP 时代的产物。在当今 HTTP/3 与 QUIC 快速普及的背景下，一种融合两者优势的全新标准正在成为焦点------WebTransport。

• 底层基于 UDP 与 QUIC：彻底消除了 TCP 协议固有的队头阻塞（Head-of-Line Blocking）问题；

• 天然多路复用与双向流：在单个连接内可以同时创建多个可靠的双向流（类似 WebSocket）、不可靠的数据报（Datagram，适合音视频及游戏），以及单向流（类似 SSE）；

• 极速建立连接：结合 TLS 1.3，实现 0-RTT 或 1-RTT 极速握手。

对于当下的工程实践而言，在未来 3 到 5 年内，WebSocket 与基于 HTTP/2 的 SSE 依然是企业级系统中最可靠、生态最完备的黄金组合。理解二者在协议底层与工程运维层面的边界与代价，能帮助架构师在系统高可用、高并发与研发效能之间，做出最理性的技术抉择。