SSE vs WebSocket：实时通信技术选型与协议底层原理详解

开头先说个事儿。我这两年做实时功能，从消息推送、文件状态监控到 AI 流式输出，前前后后写了好几套模块，最深的体会是：很多团队在选 SSE 还是 WebSocket 时，根本不是在做技术选型，而是在做“跟风”。看别人用 WebSocket 就跟着上，压测时一开连接数内存先爆；听说 SSE 轻量又顺手，结果反过来需要在服务器推数据给客户端时，发现 EventSource 自带的断线重连正好卡在自己业务逻辑的喉咙上。

实时通信，说白了就是服务器往浏览器主动吐数据的手段。但“主动吐”这件事，SSE 和 WebSocket 走的是两条完全不同的路线：一个是基于 HTTP 的单项长连接，一个是基于 TCP 的双向全双工通道。两者的协议设计、连接模型、重连策略、代理兼容性、资源消耗都差得很远。这篇文章我想把这两条路线从底层协议原理到生产环境踩坑，再到具体代码落地，完整掰开讲清楚。

我自己技术栈主要在 Java/Spring 和后端 Python，前端 Vue/React 都在写，所以下面给出的例子尽量覆盖主流的几种写法。读完这套对比，你至少能做到两件事：第一，给一个具体需求时能快速判断用哪个；第二，无论哪个方案，都能避开那些线上才会冒出来的坑。

1. 先理解本质：单向通知与双向通道的取舍

很多对比文章一上来就甩协议差异、性能数据，但对一个刚接触实时通信的人来说，真正需要先弄清楚的是：SSE 和 WebSocket 解决的问题，根本不是一个维度的事。

1.1 广播站与电话线

我来打个比方。SSE 就像一个广播站，信息只有一个方向：站长（服务器）拿着喇叭喊话，听众（浏览器）只能听。广播站的频道是唯一的，站长喊到谁家的消息，谁家就去处理，喊完这波接着喊下一波，周而复始。WebSocket 则是一条电话线，两边都能说话，而且是同时说话都行——你问我答、你打断我、我打断你，全部实时进行。

这个比喻直接决定了你能干什么。

如果你要做的是：系统里某个数据变了，服务器主动告诉前端去刷新；后端算好一段内容，一路吐字一样把结果推给页面；或者监控任务跑完了，通知用户查看结果——这些都是单向的，服务器是唯一的信息生产者，客户端只需要收。用广播站（SSE）就行，而且这条线路本身就带“失联自动重播”的机制，省心得多。

但如果你要做的是在线协作编辑、一对一聊天、游戏同步、远程操控这一类，客户端不仅要收消息，还要随时把自己的状态发给服务器，甚至两边同时高频互怼数据，那就必须上电话线（WebSocket）。你不可能拿广播站假装做双向通信——虽然 SSE 配合额外的 HTTP POST 请求勉强能模拟，但那种做法一旦高频起来，连接管理和消息顺序都会乱成一锅粥。

1.2 浏览器限制倒逼出的 HTTP 单向长连接

先补一个背景。早年想做“推”，标准方案是轮询，也就是前端隔几秒发一次请求问“有变化吗？”。轮询的浪费很明显：每一次请求都带上几百字节的 Cookie、Header，服务器收到后哪怕没有新数据也得回个 200，高频场景下带宽和 CPU 消耗非常可观。

SSE 的思路则是把“轮”省掉，建立一条 HTTP 长连接，服务器在这条连接上持续的、按需的往外写数据。因为浏览器原生支持一个叫 EventSource 的 API，理论上你连第三方库都不用引，new EventSource(url) 就建立了一条长连接，服务端往连接里写文本，浏览器自动解析成事件。

这里的“长”很关键：普通 HTTP 响应是一锤子买卖，请求到了响应完就断开。而 SSE 的响应体不会立刻结束，服务器一直占着这条连接，源源不断地追加数据。对浏览器来说，它只知道这是一个还没完成的响应，一直在收包而已。这种设计让它天然能穿越几乎所有 HTTP 代理和负载均衡器，因为从代理的视角看，这就是一个正常的、还没结束的 HTTP 请求。这条特性，等会儿在东线实战中救了我好几次。

1.3 最常见的选型误区

我见过最典型的错误，是看到“实时”两个字就无脑选 WebSocket。有一种场景特别典型：后台跑着一个 Python 爬虫或者数据同步任务，每跑完一条就往前端推一条进度信息，或者一个 Django 后台系统在做文件变化监控，把新出现的文件路径实时推到浏览器。这类需求有个共同点：客户端只需被动接收，连接断开后如果能自动重连最好。WebSocket 能做，但你要额外处理的东西很多，比如断线后应用层心跳、消息补偿、重连时的订阅恢复；而用 SSE，EventSource 自带断线重连和 last-event-id 恢复机制，代码量少了一半不止。

反方向也有不少坑。有人拿着 SSE 去做聊天工具，结果前端发消息得额外走一个 fetch POST，收发两条链路要分别维护会话状态，消息顺序还得靠服务端额外协调，越写越别扭。这种需求从一开始就应该用 WebSocket 的双向通道来承载，硬拿 SSE 顶，最终维护成本一定超过当初省下的那点代码量。

所以真实项目里我的习惯是，先把“数据流方向”画出来，再考虑技术方案。方向只有从服务器到客户端，默认 SSE；方向是双向的，才考虑 WebSocket；如果还要在高频/大包/二进制上做文章，WebSocket 更是唯一解。

2. 协议层面的关键差异：HTTP 长连接与 101 状态切换

聊完概念，必须下钻到协议层。这里有两个完全不同的东西浮出水面：SSE 把 HTTP 这条现成的路用到极致；WebSocket 则是借 HTTP 搭了个桥，桥搭好后就换成了另一套完全独立的通信语言。

2.1 SSE 的报文格式与 EventSource 解析规则

SSE 的数据格式很简单，本质就是一段由特殊字段组成的纯文本流。服务端按以下约定往连接里写：

• 每一行可以用 field: value 的形式表示一个字段，常用字段包括 data、event、id、retry。
• 多个 data 行用换行符拼起来，构成一条事件的消息体。
• 一条事件结束后，用一个空行（两个换行符）告诉解析器“这是一条完整消息”。
• 如果想让客户端监听自定义事件名，用 event: customName 指定，否则默认触发 message 事件。

典型输出看起来是这个样子：

code复制event: progress
id: 101

data: {"step": 1, "message": "开始解析"}

event: done
data: {"fileUrl": "http://xxx/file.pdf"}

前端监听时：

javascript复制const es = new EventSource('/api/stream/task');
es.addEventListener('progress', (e) => {
  const data = JSON.parse(e.data);
  console.log('进度：', data);
});
es.onmessage = (e) => {
  console.log('默认消息', e.data);
};
es.onerror = () => {
  // 连接异常时触发，EventSource 会尝试自动重连
};

这套协议是文本优先的，天然适合 JSON 字符串、事件名、提示消息这类结构。没有二进制帧、没有子协议协商，甚至连消息都能没有额外封装——你甚至可以把它理解成一个有格式约定的分块下载流。

2.2 WebSocket 的握手与帧格式

WebSocket 的建立过程分两步。第一步是 HTTP 握手：客户端发起一个带 Upgrade: websocket 头的请求，服务器校验通过后返回 101 Switching Protocols，此时 HTTP 连接升级为 WebSocket 连接。HTTP 在这里只负责“登记注册”，之后的通信不再走 HTTP 语义，而是切换到一个依托于 TCP 的双向帧协议。

帧格式是核心差异点。WebSocket 的每条消息都会被包装成帧，帧头包含 FIN 位（是否最后一帧）、opcode（数据类型，文本1，二进制2，控制帧8/9/10）、长度、掩码等信息。收发双方通过帧级别的控制进行消息切割和类型识别，所以二进制的音视频流、大块数据包都能直接传输。

这带来几个直接后果：

• 协议开销比 SSE 小：WebSocket 帧头最小 2 字节，而对一条 SSE 消息来说，后面拖着的换行符和没有自定义事件时的 \n\n 相当于格式上的固定开销。
• 消息之间天然隔离：客户端 onmessage 收到的就是一条完整的消息，不用像 SSE 那样在服务端手动用空行切消息。
• 双向同时收发：WebSocket 的底层是全双工 TCP，客户端和服务端在任意时刻都可以发起数据。SSE 的底层依然是普通 HTTP，同一时刻里只能由服务端往下写，客户端往上传只能靠另开请求。

2.3 隐藏优势：SSE 的自动重连与最后事件 ID

刚才提到 SSE 自带断线重连，这是它最“反直觉”的优势。浏览器 EventSource 在连接断开后，默认大约每 3 秒里自动重连。更重要的是它的消息恢复机制：如果服务端发出来的每一段数据里带了 id 字段，那么重连时请求头里会自动带上 Last-Event-ID，服务端读到这个 ID 就能从断掉的进度接着发，前端完全不用写补偿逻辑。

这一点在“长耗时任务推送 + 浏览器不小心刷新”的场景里特别救命。比如我用 SSE 封装过一个 AI 智能体的流式接口，后端把所有思考过程以事件流的形式推到前端。断线重连时，只要读到前端带回来的最后事件号，就能把这段时间里遗漏的中间过程补推过去，用户无感，代码也没做额外处理。而 WebSocket 在这件事上没有任何内置机制，断线后要自己实现“重连 + 消息去重 + 断点续传”，这通常意味着要引入一个消息序列号体系，复杂度一下子就上去了。

2.4 协议层差异一览表

我习惯把关键差异整理成表，方便做技术评审时直接贴进文档：

3. 生产选型依据：数据流方向、消息体量与基础设施

到了真正做决定的时候，我会按下面几条硬指标来排查需求，而不是拍脑袋“用哪个火就用哪个”。

3.1 服务器单向推送：SSE 的明显优势

只要业务是“服务器有数据，我来推给你”，SSE 在我这里的优先级高出 WebSocket 一截。原因有两点。

第一，运维层省心。SSE 复用了 HTTP 线路，本机 Nginx、云上负载均衡器、各类 Web 应用防火墙，基本都能直接透传。换句话说，线上出问题时，SSE 通常不用动大架构，而 WebSocket 在 Nginx 里要显式配置 Upgrade 头透传，在云厂商的负载均衡上有时还要单独开 WebSocket 协议支持，或者面临闲置超时强行断连的风险。

第二，应用层代码省心。EventSource 自动重连、自动恢复事件号，这相当于把 WebSocket 社区里最常被重复踩的坑给填平了。我自己用 SSE 接过的典型场景包括：

• Python Django 后台跑数据，前台 Vue 页面展示推送数据（后台有数据就推前端，经典模型）。
• React 页面监听文件系统变化，后端告诉我某个目录下新增/改动了哪些文件，页面实时刷新文件树。
• 大模型流式输出：服务端把 token 逐个吐出来，前端边收边往界面上写。

这些例子有个共性：数据方向永远是服务端到前端，客户端回传的状态要么没有，要么频率极低（比如回复一句“收到”）。这种使用场景，EventSource 几乎就是为它量身定制的。

3.2 双向交互场景：不建议用 SSE 硬撑

如果需求里有明显的“你来我往”，比如：

• 用户 A 在聊天窗口发消息，服务器要立刻转给用户 B；
• 多人编辑器里 A 的光标移动要实时同步给 B；
• 前端某个长期运行的表格里要一直把筛选条件实时发给后端，后端再把结果推回来；
• 做在线画板，拖拽坐标高频同步。

一个共同点出现了：客户端不只是接收方，它也必须随时、连续地往服务器发数据。倘若你用 SSE 模拟，方案就变成“SSE 接推送 + POST 发数据”，此时你同时持有两条连接、两个会话，而且消息到达顺序不再天然有序。更何况每次 POST 都是一次独立 HTTP 请求，高频交互下开销立刻翻倍。这种情况下，WebSocket 一条连接全搞定，收发同路、顺序有保证、频率无上限，价值不言而喻。

3.3 消息体量与二进制框架

这里还藏着一个经常被忽略的判断依据：你要推的数据里有没有二进制块。

WebSocket 从设计上就支持二进制帧，推送时只要 opcode 标成二进制，接收端拿到就是 ArrayBuffer 或 Blob，不用转码。SSE 只能传文本，二进制内容要么 Base64 编码让体积膨胀 33%，要么转 Blob 后沿文本通道传，再在前端解码。偶尔推几张图片还能忍，但如果是一个在线预览 PDF 系统、远程桌面截图流或者音视频语音对讲，SSE 的额外开销和编解码复杂度会让人非常难受。

通常我会定一条线：数据体积小且文本化，SSE 很合适；数据是大块二进制或要求低延迟高频互发，直接 WebSocket。

3.4 前端框架的适配成本

考虑到现在前后端分离是常态，选型还得算上前端适配工作量。

SSE 在 Vue 里最常见的一句话就是：

javascript复制const es = new EventSource('/api/stream');
es.onmessage = (e) => (state.message = JSON.parse(e.data).text);

React 里稍微控制下生命周期，在 useEffect 里创建、cleanup 里关闭，也很快就完事。因为 EventSource 是浏览器原生 API，连 npm install 都省了。

WebSocket 其实也有一条原生路径，但稍微复杂一些，需要维护连接状态机，处理 onopen/onmessage/onclose/onerror 四个事件的排列组合，还要自己写心跳、手动重连。通常我会直接引入 Socket.IO 这类封装库，把需要自己去补丁的细节都交给库处理。可是引入库又带来选库、升级、兼容性等新的取舍问题。

所以很真实的一幕是：前端团队技术栈越多样，越愿意选 SSE，因为它对前端的要求趋近于零；越需要控制精细粒度协议，越容易倒向 WebSocket——因为这些场景下原生 API 裸露出来的复杂度反而成了必要的能力。

4. 核心代码落地：两个方向的典型实现与避坑

说再多，不如直接把代码跑通。下面我用几个我实际写过的例子，把 SSE 和 WebSocket 从服务端到前端完整串一遍。

4.1 用 Python/FastAPI + Vue 实现 SSE 流式推送

后端的实现核心，是返回一个 StreamingResponse，并在内部循环里持续产出符合 SSE 格式的文本。下面这段代码是典型的“后台任务跑进度，往前端推数据”结构：

python复制import asyncio
import json
from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

async def event_generator(task_id: str):
    # 模拟一个会持续产生事件的流程
    for i in range(100):
        # 每隔一段时间生产一条数据
        await asyncio.sleep(1)
        payload = json.dumps({"task_id": task_id, "progress": i + 1})
        # SSE 格式：每条消息之间必须有空行分隔
        yield f"event: progress\ndata: {payload}\n\n"
    # 结束时发送一条 done 事件，方便前端做收尾
    yield f"event: done\ndata: {json.dumps({'status': 'finished'})}\n\n"

@app.get("/api/stream/{task_id}")
async def stream(task_id: str):
    return StreamingResponse(
        event_generator(task_id),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "X-Accel-Buffering": "no",
            "Connection": "keep-alive",
        },
    )

这里有两个关键头信息：

• X-Accel-Buffering: no 是专门写给 Nginx 看的，防止它在中间做缓冲区，把数据攒到一定量才转发。没有这行，前端经常遇到“等半天才刷一屏”。
• Cache-Control: no-cache 避免浏览器和中间代理缓存整个流。

Vue 侧接收就很简单了：

javascript复制const es = new EventSource('/api/stream/task-123');
es.addEventListener('progress', (e) => {
  const data = JSON.parse(e.data);
  progress.value = data.progress;
});
es.addEventListener('done', () => {
  es.close();
});
onUnmounted(() => es.close());

在 Python/Django 里做同类事情也大同小异，只是流的产出用 StreamingHttpResponse，然后把生成器函数替换成查询数据库或者读消息队列。Django 的注意点是在有 GZipMiddleware 时一定要跳过压缩，否则数据还会被压在服务端等到结束才统一发出。

4.2 Java/Spring 实现 SSE 时的三个坑

后端用 Java 的老哥也不少，Spring Boot 里实现 SSE 通常走 SseEmitter。这里我踩过的坑值得单独拎出来讲。

第一个坑是超时时间。Spring 的 SseEmitter 默认超时时间非常短，不主动配置的话，长连接一会儿就被断开了。所以初始化时必须显式指定：

java复制SseEmitter emitter = new SseEmitter(0L); // 0 表示永不过期

第二个坑是线程池的控制。SseEmitter 的 send() 是在处理请求的线程里执行的，如果你在一个耗时的任务循环里直接调用 emitter.send()，很容易把业务线程池占满。我的做法是引入一个异步执行的线程池，任务完成一段就往 emitter 里写入一段数据，写完了也不挡业务腿。

第三个坑是客户端断线异常。浏览器一旦关页面，服务端再执行 emitter.send() 会抛 IOException。如果不捕获，异常会污染日志，而且这个 emitter 对象不会自动释放，最终成为内存泄漏。标准做法是注册 onCompletion / onTimeout 回调清理资源，在 send 里捕获异常后主动 emitter.complete()。

一个相对完整的 Java 片段是这样：

java复制@GetMapping("/api/stream/{taskId}")
public SseEmitter stream(@PathVariable String taskId) throws Exception {
    SseEmitter emitter = new SseEmitter(0L);
    // 用专门的线程池持续推送
    taskExecutor.execute(() -> {
        try {
            for (int i = 0; i < 100; i++) {
                Thread.sleep(1000);
                emitter.send(SseEmitter.event()
                        .name("progress")
                        .data(Map.of("progress", i + 1)));
            }
            emitter.send(SseEmitter.event().name("done").data("finished"));
            emitter.complete();
        } catch (Exception e) {
            emitter.completeWithError(e);
        }
    });

    emitter.onError(err -> {
        log.warn("SSE 连接异常，清理资源");
        emitter.complete();
    });
    return emitter;
}

4.3 WebSocket 服务端与前端的最小实现

WebSocket 的最小可用服务端用 Node.js 的 ws 库非常典型：

javascript复制const { WebSocketServer } = require('ws');

const wss = new WebSocketServer({ port: 8080 });

wss.on('connection', (ws, req) => {
  console.log('客户端已连接：', req.socket.remoteAddress);

  ws.on('message', (message) => {
    // 收到的消息可能是 Buffer 也可能是文本
    const text = message.toString();
    console.log('收到消息：', text);

    // 原样返回，演示双向通信；实际业务中可以按通道路由
    ws.send(`echo: ${text}`);
  });

  ws.on('close', () => {
    console.log('连接关闭');
  });

  ws.on('error', (err) => {
    console.error('连接异常：', err);
  });
});

前端与之配套的一段代码：

javascript复制const wsUrl = 'ws://localhost:8080';
let socket;
let heartbeatTimer = null;

function connect() {
  socket = new WebSocket(wsUrl);

  socket.onopen = () => {
    console.log('已建立 WebSocket 连接');
    // 启动应用层心跳，避免代理或防火墙把空闲连接掐断
    heartbeatTimer = setInterval(() => {
      socket.send(JSON.stringify({ type: 'ping', ts: Date.now() }));
    }, 30000);
  };

  socket.onmessage = (e) => {
    console.log('收到消息：', e.data);
  };

  socket.onclose = () => {
    console.log('连接关闭，准备重连');
    clearInterval(heartbeatTimer);
    // 简化重连：3 秒后重新 connect
    setTimeout(connect, 3000);
  };

  socket.onerror = () => {
    // 触发 onerror 后一般立刻触发 onclose，不要在 onerror 里做重复重连
  };
}

connect();

4.4 心跳为什么要分“底层保活”和“应用层心跳”

这里把刚才代码里的心跳单独解释一下。

TCP 层本身有个 KeepAlive 机制，但默认闲置时间大约 2 小时，对实时系统来说几乎没有意义。真正起作用的通常是在应用层写一个定时器，每隔 20~30 秒往服务端发一个 ping 帧或自定义的 {"type":"ping"} 消息，服务端收到后回一个 pong。这样做的目的一是让中间设备认为这条连接还在活跃，二是用最廉价的方式探测网络链路是否真的通着。

注意，WebSocket 协议本身有 Ping/Pong 控制帧，但浏览器原生 WebSocket API 并不允许 JavaScript 直接发送 Ping 帧——只能由服务端主动 Ping，客户端浏览器自动回 Pong。所以在浏览器端实现心跳时，通常要发自定义的文本消息，由服务端配合返回对应响应。当然，如果是服务端连服务端的场景，可以直接用协议层的 Ping/Pong 帧，开销更小。

SSE 侧的情况不太一样。EventSource 也是走 HTTP 长连接的，中间代理同样可能掐闲置连接，因此我同样会写一个服务端的定时注释消息（形如 : keep-alive\n\n，这种以冒号开头的行是 SSE 注释，浏览器 EventSource 会忽略）。每一小段时间发一条注释，连接就能始终保持活跃，前端代码零改动，非常隐蔽且有效。

5. 线上踩坑记录：断线、超时、代理与并发

到了生产环境，理论对比就变成了一连串具体问题。这几段值得反复看，因为都是文档里翻不到的硬经验。

5.1 “stream disconnected before completion: idle timeout waiting for sse”的成因与对策

有阵子我接了一个舆情采集系统的前端展示页，SSE 连接总是跑了不到一分半钟就断开，后端日志里偶尔出现类似 “stream disconnected before completion: idle timeout waiting for sse” 的报错。起初我以为是自己后端问题，排查了半天发现后端明明还在正常发数据，但连接就是被悄无声息地切断了。

最后定位到两个元凶：一是公网入口那台 Nginx 配置了默认的 proxy_read_timeout 60s，意味着如果代理在 60 秒内没有读到来自后端的数据，它就主动断开连接；二是我当时没在响应头里加 X-Accel-Buffering: no，Nginx 把后端吐的数据缓冲起来，前端浏览器迟迟收不到，也直接影响了代理对连接活跃度的判断。

解决方案很直接：

1. 在 Nginx 配置里，对 SSE 专用的 location 设置 proxy_buffering off，并把 proxy_read_timeout 调到如 3600s，同时 proxy_http_version 1.1。
2. 在后端响应头里显式加上 X-Accel-Buffering: no 和 Cache-Control: no-cache。
3. 如果后端是 Java 等实现 SSE，还要检查应用服务器的 Servlet 异步请求超时时间（例如 Tomcat 的 asyncTimeout），同样调大或者关闭。

改完之后，那条连接可以稳稳地挂好几个小时，问题根除。

5.2 为什么 WebSocket 后端必须自己实现心跳

WebSocket 断线检测在纯客户端侧几乎不可靠。你写一段 socket.onclose 的逻辑，期望它能在网线被拔掉时立即触发，但实际上浏览器可能过很久才意识到连接已经断了，中间这段时间消息全部丢失或者排队，用户界面还会显示“在线”。如果服务端没有心跳探测机制，服务端也会一直认为连接还活着，造成僵尸连接累积，连接数越来越离谱，内存缓慢上涨。

我最开始的 WebSocket 推送服务就吃过这个亏。线上运行一段时间后，连接数和服务内存双双居高不下，排查发现大量连接其实是已经终结的“幽灵连接”。后来服务端引入每 30 秒扫一遍所有连接的机制，向客户端发一次 Ping，如果在规定时间内没收到 Pong 或响应消息，就主动 terminate() 掉这个连接。架构图上看起来是小事，但对稳定性来说是大事。

对使用 Spring 后端的场景，还可以在 WebSocketHandler 里配合 WebSocketSession 的 pingMessage 实现服务端主动探测，Java 侧可以直接拿 PingMessage 控制帧来用，比发自定义文本稍微干净一点。

5.3 网关与负载均衡器的长连接兼容性

在大型系统里，你基本不可能让浏览器直连业务端口，中间必然有 Nginx、云 LB、网关层。SSE 通常不用操心这块，因为它就是普通 HTTP GET 长响应；但 WebSocket 在每一跳代理上都要求支持协议升级（Upgrade）。

Nginx 里必须显式配置：

nginx复制location /websocket/ {
    proxy_pass http://backend_servers;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

几个点很容易踩：

• proxy_http_version 必须设置为 1.1，HTTP/1.0 不支持 Upgrade 头。
• Connection: upgrade 必须写死，不能沿用默认的 Connection: close。
• 云负载均衡如果支持 TCP 负载均衡可以直通，但使用 HTTP 监听规则时，要看面板上是否默认开了 WebSocket 支持，很多云厂商其实是支持并默认开启，但个别老的实例或某些端口策略下需要单独联系客服调整。
• 网关的闲置超时，比如阿里云 SLB 的 60 秒空闲超时，会造成 WebSocket 连接被周期性掐断。此时要么缩短应用层心跳间隔，让连接不停有数据交互，要么开放长连接超时配置。

5.4 浏览器连接数限制与服务端资源估算

SSE 还有一个特别容易被忽略的隐藏限制。HTTP/1.1 协议下，一个浏览器域名同一时间最多只能开 6 个连接。每个 EventSource 实例占一个连接，如果你同屏同时开了 6 个及以上 SSE 流，多出来的连接就会被 HOLD 住，请求根本发不出去，只排在队列里等待前面释放。我之前做多任务并行监控时，一屏挂 8 个 SSE 任务，结果最后两个任务迟迟不来进度，就是这个原因。

WS 没有这种固定限制，因为它是全双工且帧复用，但连接数无限制不意味着内存无限制。一条 WebSocket 连接在服务端至少要占用一个文件描述符、一个 TCP 缓冲区和若干业务对象实例，正经评估时得按每条连接有几十 KB 常驻内存来估算。只要服务端机器规格低，几千条连接就能把人打得手忙脚乱。

所以在做并发设计时，SSE 侧我要么控制单页事件流的数量，要么把多个任务合并到一个事件流里、用事件名区分；WebSocket 侧则要盯紧单机连接数上限和内存曲线，提前做水平扩展和连接转发策略。

6. 综合对比表与最后的选型建议

到此为止，协议原理、实现代码、线上问题都走了一遍。最后我做一张覆盖绝大多数决策点的对比表，再给几条我实际遵循的决策建议。

6.1 一句话判断标准

如果你想在 30 秒内给同事一个答案，可以这样判断：

• 数据只管从服务器往下推，客户端基本不往上发东西 —— SSE。
• 客户端需要高频、双向互发，或者涉及二进制传输 —— WebSocket。
• 技术栈完全受限、中间代理链路复杂、想要最少的代码实现推送 —— SSE。
• 需要极低延迟（如游戏、语音对讲、协同编辑）且不在乎额外接入成本 —— WebSocket。

6.2 全维度对比表

6.3 迁移不是非黑即白

现实项目里，很多系统的实时功能是逐步演进的。如果你现在是个 HTTP 接口 + 轮询的系统，想降低轮询压力和延迟，第一步完全可以只接入 SSE，把服务端到客户端的推送全部换成事件流。这样改动面小、风险可控，如果后续出现了真正需要双向高频通信的模块，再把那一部分单独升级为 WebSocket 也不迟。

反过来，如果你已经上了 WebSocket，但业务需求根本用不到双向通道，甚至因为心跳、重连、网关配置问题三天两头线上报警，那就有充分理由把其中单向推送的业务迁移到 SSE 上，把宝贵的 WebSocket 连接留给真正需要它的功能。

我在实际项目里经常保留混合架构：通知中心用 SSE，在线协作的实时数据通道用 WebSocket，两者互不干扰，各自发挥各自的优势。挂在同一个前端的页面上也没有任何冲突，因为它们走的协议路径完全不同。

最后再分享一点个人体会：技术选型这回事，多数时候拼的不是“技术上限”而是“团队的日常运维复杂度”。SSE 和 WebSocket 都不是银弹，但只要你把数据流方向厘清了、把底层协议差异吃透了，选型就是一件非常确定的事情。我后面遇到实时需求，第一件事永远是打开这篇文章里那张表，对着确认一遍：数据单向还是双向？客户端要不要重连恢复？中间有没有代理要穿越？三个问题一过，方案基本就锁定了。希望这篇对比能帮你以后少折腾几个通宵，也省得在公司技术评审时和人吵到面红耳赤。