SSE是什么？AI大模型爆火背后的推送技术

一、SSE是什么：先给出清晰定义

SSE（Server-Sent Events，服务器推送事件）是一种基于HTTP协议的服务器推送技术：客户端向服务端发起一次普通的HTTP请求后，服务端不立即结束响应，而是保持连接打开，把数据以“流”的形式持续不断地写回客户端。

理解SSE，可以抓住一个极简公式：

SSE = HTTP扩展字段 + Keepalive长连接

具体可以从三个视角展开：

• 协议视角：SSE不是一个全新的独立协议，而是构建在标准HTTP/1.1之上（对HTTP/2同样兼容）的一种扩展用法。它复用了HTTP的连接管理、鉴权体系与基础设施，没有引入任何“陌生”的东西。
• 格式视角：SSE约定了专属的响应类型——text/event-stream，并规定了一整套标准化的消息报文格式。正因为格式是标准化的，不同语言、不同框架实现的服务端与客户端才能彼此理解。
• 行为视角：可以把SSE想象成服务器打开了一条“单向数据管道”——数据只从服务器流向浏览器，浏览器无需反复发起请求，服务器有新数据就随时写入管道。

它解决的根本问题是：传统HTTP“客户端问、服务器答”的一问一答模型下，服务器无法主动向客户端传递新数据。SSE以极低的改造成本，让服务器拥有了“主动开口说话”的能力。目前几乎所有主流浏览器都原生支持SSE，客户端无需引入任何第三方库即可直接使用，这是它区别于许多推送方案的重要优势。

二、背景与价值：为什么需要SSE，它为什么在大模型时代爆火

1. 传统轮询模式的困境。 在SSE被广泛使用之前，客户端想“及时”拿到服务端最新数据，通常只有两种选择：短轮询与长轮询。短轮询是客户端按固定间隔反复发请求，延迟受轮询间隔限制，且绝大多数请求都是无效请求，服务端压力与带宽浪费随客户端数量线性增长；长轮询是服务端把请求“挂住”，直到有新数据才返回，实时性接近推送，但实现复杂，连接管理与服务端并发压力都很棘手。两者本质上都是在“用请求模拟推送”，成本高、体验差。

2. WebSocket对单向场景而言“能力过剩”。 WebSocket提供了真正的全双工双向通道，但它需要从HTTP升级到独立协议，链路上的网关、代理、鉴权都要额外适配；客户端还需自行实现心跳、重连、消息补偿等一整套可靠性逻辑。如果业务只需要“服务器向客户端单向推送”，引入WebSocket相当于为只需要单行道的场景修了一条双向八车道。

3. 大模型时代的引爆点。 大语言模型的生成过程有两个鲜明特性：一是逐个token（词元）渐进生成，二是长回答的推理耗时可能达到数秒甚至数十秒。如果等全部内容生成完毕再一次性返回，用户将面对漫长的空白等待；而SSE让模型“生成一点、就推送一点”，首字出现的等待时间被压缩到接近推理启动的时间，整体阅读体验接近真人打字。同时，一次对话的信息流向天然是“客户端提交一次提示词 + 服务端单向持续输出”，与SSE的单向模型严丝合缝。因此，当下主流的AI对话应用普遍采用SSE或类SSE的流式方案来完成逐字输出。

三、核心组成：SSE的四个关键要素

1. 专用的HTTP响应头。 服务端开启SSE，只需在响应头中声明：

Content-Type: text/event-stream   // 声明这是一个事件流
Cache-Control: no-cache          // 禁止任何环节缓存
Connection: keep-alive           // HTTP/1.1下保持长连接

服务端返回200状态码后不结束响应体，以流式（通常为分块传输）方式持续写入数据，这条连接就变成了一条推送管道。

2. 标准化的消息报文格式。 SSE规定了四种字段，每条消息由若干“字段: 值”行组成，消息之间以空行分隔：

• data：消息内容本体；同一消息中多个data行会按换行拼接后投递给客户端。
• event：自定义事件类型，客户端可分别监听不同事件；不写则归入默认的message事件。
• id：消息编号，浏览器会记录最新id，断线重连时通过请求头带回服务端，用于断点续传。
• retry：建议的重连等待毫秒数，服务端可用它控制客户端的重连节奏。

此外，以冒号开头的行会被当作注释忽略——这个特性常被用作“心跳”载体。示意报文如下：

: heartbeat            <- 注释行，用作保活心跳
id: 1
event: token
data: 你
id: 2
event: token
data: 好

3. 浏览器原生的EventSource接口。 客户端零依赖，标准用法如下：

const es = new EventSource('/api/stream', { withCredentials: true });
es.onopen = () => console.log('连接已建立');
es.onmessage = (e) => console.log('默认消息：', e.data);
es.addEventListener('token', (e) => appendToPanel(e.data)); // 监听自定义事件
es.onerror = () => console.log('连接异常，浏览器将自动重连');
// es.close();  主动关闭连接

4. 内建的重连与续传机制。 连接意外断开时，EventSource会自动尝试重连，并把最近收到的消息id通过Last-Event-ID请求头带回；服务端据此从断点继续推送，实现“消息不丢”。这套可靠性逻辑由浏览器内建，无需开发者手写，是SSE相对自研推送方案的显著工程优势。

四、工作原理：一次SSE通信的完整生命周期

1. 建立连接：客户端向服务端发起一个普通的HTTP GET请求。
2. 服务端接管：服务端返回200与text/event-stream响应头，随即“挂起”该响应——既不写完整响应体，也不关闭连接。
3. 持续推送：每当有新数据，服务端就向响应流写入一条符合格式的消息（以空行结尾）；没有新数据时，定期写入注释行作为心跳，防止中间设备因空闲而掐断连接。
4. 客户端解析：浏览器按规范解析字段，把data内容投递到对应的事件回调；消息严格按写入顺序到达，SSE保证流内顺序性。
5. 异常与重连：连接中断后，EventSource按retry建议的间隔自动重连，并携带Last-Event-ID请求续传；服务端可据此补发缺失消息。
6. 正常结束：客户端调用close()主动断开；若服务端主动结束响应，客户端会触发错误事件。

补充：AI应用中的常用变体——POST + 流式读取。 标准EventSource只支持GET请求，而AI对话往往需要提交很长的上下文，GET的URL长度无法胜任。因此业界普遍做法是：用通用的fetch接口发起POST请求，直接流式读取响应体，再按SSE的报文规范自行解析——消息格式不变，只是“订阅端”从EventSource换成了流式读取器。另外，流式响应没有“响应自然完成”的信号，业界常约定一个特殊的结束哨兵消息（例如一条表示“流已结束”的标记数据）来告知客户端收尾。

服务端伪代码（语言无关）：

设置响应头：Content-Type: text/event-stream; Cache-Control: no-cache
循环：
    若有待推送数据 -> 写入 "id: n\nevent: xxx\ndata: ...\n\n"
    每隔 N 秒      -> 写入 ": keepalive\n\n"

五、典型应用场景

1. AI大模型流式输出：逐token推送回答，压缩首字等待、实现“打字机”效果，是SSE当前最热门的应用。
2. 实时通知与消息：站内信、订单状态变更、审批提醒等“服务器有事件才通知”的场景。
3. 日志与事件流：部署日志实时滚动、系统事件推送，边生成边呈现。
4. 数据看板与行情播报：监控指标、金融行情、赛事比分等持续刷新的数据面板。
5. 任务进度推送：文件转码、批处理任务等长任务进度的实时更新。
6. 轻量协同广播：单向状态同步，如“数据已更新，请刷新”之类的提示类广播。

六、SSE与相关概念的区别

SSE vs WebSocket（最容易混淆的一对）：

维度	SSE	WebSocket
通信方向	单向（服务器→客户端）	全双工双向
协议基础	标准HTTP	独立协议，需从HTTP升级
重连机制	浏览器内建自动重连+断点续传	需自行实现
数据格式	仅UTF-8文本	文本与二进制均可
基础设施兼容	复用HTTP链路，网关/代理/鉴权基本无感	各环节需额外适配

选型建议：只需要服务器向客户端推送，优先SSE，实现更简单、链路更友好；客户端也要高频主动发消息（如协同编辑、在线游戏、音视频信令），则选WebSocket。

SSE vs 轮询/长轮询：轮询是“客户端反复问”，延迟与开销随频率走高；长轮询接近实时但复杂且占用服务端并发；SSE一次连接持续推送，在实时性、资源效率与实现成本上综合最优。

七、使用注意事项

1. 先判断方向，再选型：单向推送选SSE；双向高频交互选WebSocket；不要为了“用新技术”而引入协议升级的复杂度。
2. 小心中间层缓冲：反向代理、网关默认可能对响应做缓冲，数据会被“攒起来”一次性下发，流式效果完全失效。接入时需在相关链路关闭响应缓冲、调大相关超时，并对text/event-stream类型谨慎启用压缩（部分压缩器需攒满缓冲区才输出，同样破坏流式体验）。
3. 连接数限制：HTTP/1.1下浏览器对同一域名的并发连接数有限（通常约6个），SSE会长期占用连接，多标签页或多条流的页面可能阻塞其他普通请求；启用HTTP/2的多路复用可显著缓解。
4. 心跳与超时配套：服务端务必发送心跳，且心跳间隔应小于链路上任何设备的空闲超时；同时检查服务端框架自身的请求超时设置，避免长连接被误杀。
5. 鉴权与安全：EventSource不便携带自定义请求头，常见做法是使用Cookie凭据，或使用短时效的一次性令牌放在查询参数中；跨域场景需正确配置CORS。SSE内容为明文文本，敏感数据务必走HTTPS传输。
6. 重连与幂等：通知类场景应利用id与Last-Event-ID做好补发与去重；AI对话类场景通常不做细粒度续传，整体重试往往更简单可靠。
7. 容量与运维：每条SSE连接占用一个并发连接与少量内存，海量连接下应选择异步、事件驱动风格的服务端模型，并通过负载均衡做水平扩展。无论是自建服务还是部署在百度智能云等云平台，都需要在负载均衡与网关层确认对长连接与流式响应的支持策略，并做好连接数、推送速率、重连率等指标的监控。

八、总结

回到定义本身：SSE是基于HTTP的服务器单向推送技术——用HTTP扩展字段声明一条事件流，用Keepalive长连接承载持续推送，用标准化报文格式保证跨端互通，用内建重连机制保证可靠性。它的核心价值在于“以最小的成本获得实时推送能力”；它的适用边界同样清晰：单向、文本、轻量。当下AI大模型的逐字输出让这项低调多年的技术走到台前，而在通知、日志、监控、进度推送等传统场景中，它也始终是比WebSocket更简单务实的选择。记住“单向推送优先SSE，双向交互再上WebSocket”，就抓住了这项技术选型的本质。