AI大模型爆火的SSE技术是什么？一文读懂

作者：快去debug2026.11.04 07:09浏览量：0

简介：SSE（Server-Sent Events）是基于HTTP的服务器单向推送技术，凭借长连接与标准化事件流格式，成为实时通知、日志推送、大模型逐字输出等场景的主流方案。本文系统讲解SSE的定义、工作原理、消息格式、典型场景，及其与轮询、WebSocket的区别，并给出接入注意事项，帮你快速掌握这项轻量级推送技术。

一、概念定义：SSE到底是什么

SSE（Server-Sent Events，服务器推送事件）是一种基于HTTP协议的服务器推送技术。它允许服务端在一个持久的HTTP连接之上，主动、持续地向客户端发送数据流，而无需客户端反复发起请求来获取更新。

理解SSE，可以抓住三个关键点：

  1. 基于HTTP，而非独立新协议。SSE不是一套全新的协议，而是构建在标准HTTP/1.1之上的扩展用法：客户端先发起一个普通的HTTP请求，服务端返回响应头之后“不结束”这个响应，而是持续向响应体写入数据。它复用了HTTP的连接管理、鉴权、加密等既有能力，部署与理解成本都很低。

  2. 单向数据管道。可以把SSE想象成服务器向浏览器打开的一条“单向数据管道”：数据只能从服务端流向客户端。如果客户端需要向服务端发送数据，另起一个普通HTTP请求即可。

  3. 标准化的事件流格式。SSE规定了专门的媒体类型text/event-stream和统一的文本消息格式，浏览器可以原生解析，并把每条消息转换为事件回调。

一个公式可以概括其本质：SSE = HTTP扩展字段 + Keepalive长连接 + 标准化事件流格式。正因如此，目前几乎所有主流浏览器都原生支持SSE，客户端无需引入第三方库，使用内置的EventSource接口即可完成接入。

二、背景与价值：SSE为什么会出现

在SSE流行之前，Web应用想要“实时拿到服务端更新”，主要有几条路径，但各有明显缺陷：

  • 短轮询：客户端按固定间隔发请求（如每5秒一次）。大多数请求是“空手而归”，既浪费带宽与服务器资源，实时性也有天然延迟，最坏要等满一个轮询周期才能看到新数据。
  • 长轮询：服务端收到请求后先不返回，挂起等待直到有新数据才响应；客户端收到响应后立即再发下一个请求。实时性更好，但服务端要维护大量挂起中的请求，实现与运维复杂，“响应—断开—重连”的循环也不够优雅。
  • WebSocket：提供真正的全双工通信，能力最强，但它是一套独立协议，需要服务端、代理、网关、负载均衡都做相应适配，鉴权也要单独处理，对“只需要下行推送”的场景而言显得偏重。

SSE的价值恰好补齐了这些短板：

  1. 接入足够简单：客户端一个EventSource对象即可；服务端本质上只是“不让HTTP响应结束，持续往响应体写文本”。
  2. 复用HTTP基础设施：现有网关、代理、负载均衡、Cookie/Token鉴权、HTTPS加密等能力可直接沿用，不需要为长连接单独搭建一套体系。
  3. 可靠性内建：浏览器原生支持断线自动重连，并配合Last-Event-ID机制实现断点续传，这是长轮询很难做好的部分。
  4. 足够轻量：对于“只需要服务端到客户端单向推送”的大多数场景，SSE往往是比WebSocket更简单、更轻量的选择。

三、核心组成：SSE由哪些要素构成

1. 连接协商：HTTP头

客户端发起一个普通GET请求，通过Accept头声明自己能接收事件流：

  1. Accept: text/event-stream

服务端则返回如下关键响应头：

  1. Content-Type: text/event-stream
  2. Cache-Control: no-cache
  3. Connection: keep-alive

text/event-stream是SSE专属的媒体类型，含义是“响应体是一个持续的事件流，不要等响应结束，收到即处理”；no-cache则防止中间层缓存事件数据。

2. 消息格式：四个标准字段

SSE消息由若干“字段行 + 空行”构成，每条消息以一个空行结束。标准字段共四个：

  • data：数据本体，必填；一行放不下时可写多行data，客户端会按换行拼接。
  • event：自定义事件类型，默认为message；客户端可针对不同事件注册不同监听器。
  • id：事件编号。浏览器会记住最新收到的id，断线重连时通过Last-Event-ID请求头带回，供服务端续传定位。
  • retry：服务端建议客户端的重连等待时间，单位毫秒。

一个典型的事件流响应体如下（以冒号开头的行为注释行，客户端会忽略）：

  1. : keepalive comment
  3. id: 1
  4. event: message
  5. data: 第一条推送内容
  7. id: 2
  8. event: notice
  9. data: {"type":"update","payload":"第二条内容"}
  11. retry: 3000

3. 客户端接口：EventSource

浏览器原生提供EventSource接口，示意用法如下：

  1. // 建立连接
  2. const es = new EventSource('/api/stream');
  4. // 监听默认的message事件
  5. es.onmessage = (e) => {
  6.   console.log('收到数据：', e.data);
  7. };
  9. // 监听自定义事件类型
  10. es.addEventListener('notice', (e) => {
  11.   console.log('收到notice：', e.data);
  12. });
  14. // 连接异常时浏览器会自动重连，可在onerror中记录或做降级
  15. es.onerror = () => {
  16.   console.log('连接异常，浏览器将自动重连');
  17. };
  19. // 不再需要推送时，主动关闭连接
  20. // es.close();

可以看到，客户端几乎不需要写重连、心跳、消息解析逻辑——这些都由浏览器统一承担，这正是SSE“轻量”的直接体现。

四、工作原理：SSE是如何运行的

把SSE的完整生命周期串起来，流程大致如下：

  1. 发起连接：客户端向服务端发起GET请求，声明接受text/event-stream。
  2. 服务端“不关响应”：服务端返回响应头后保持连接不关闭，持续向响应体写入符合SSE格式的文本块，底层通常依赖HTTP的分块传输机制。
  3. 客户端流式接收：浏览器边收边解析，每凑齐一条完整消息（即遇到空行）就触发对应的事件回调，上层业务拿到数据即可处理。
  4. 心跳保活：连接空闲时，服务端周期性发送以冒号开头的注释行，防止中间的代理、网关因空闲超时把连接掐断。
  5. 自动重连：连接意外断开后，浏览器按retry建议的时间自动重新建立连接，并把最近收到的消息id通过Last-Event-ID请求头带回。
  6. 断点续传：服务端读取Last-Event-ID，只补发该编号之后的消息，避免客户端漏收或重复消费。

“自动重连 + 编号续传”的组合是SSE可靠性的核心设计，也让它成为通知、日志流这类“不能丢消息”场景的常见选择。

五、典型应用场景：SSE适合用在哪里

SSE适用于“服务端主动推送、且基本不需要反向实时通信”的场景，常见包括：

  1. AI大模型的流式输出。大模型逐字、逐段生成回复，服务端每生成一小段就通过SSE推给前端，形成“打字机”式的输出效果，显著降低用户的首字等待时间。这正是近年来SSE爆火的直接原因——多数大模型对话类应用的流式接口都采用这条技术路线。
  2. 实时通知与消息。站内信、系统公告、审批提醒等“事件发生才推送”的场景，无需前端轮询，既省资源又保证及时。
  3. 日志与监控数据流。持续输出服务日志、任务日志，前端实时滚动展示，契合运维观测需求。
  4. 行情与数据看板。监控大盘、指标仪表等需要服务端持续刷新的数据面板。
  5. 任务进度推送。文件导入、批处理、报表导出等耗时任务的进度实时更新。

反过来，如果应用要求客户端与服务端双向高频通信（如多人协同编辑、实时游戏、音视频信令），则应选择WebSocket这类全双工方案。

六、相关概念区别：SSE、轮询与WebSocket怎么选

维度 短轮询 长轮询 SSE WebSocket
通信方向 客户端拉 客户端拉 服务端推（单向） 双向全双工
协议基础 HTTP HTTP HTTP 独立协议（由HTTP升级）
实时性 差 较好 好 最好
断线重连 无 无 浏览器内建 需自行实现
实现复杂度 低 中 低 中高
数据格式 无约束 无约束 文本 文本与二进制

选型可以浓缩为一句话：只需要服务器向客户端推，选SSE；需要双向实时互通，选WebSocket。在“下行流为主、偶有上行”的场景中，业界也常用“SSE负责下行流 + 普通HTTP请求负责上行”的组合，实现简单且各取所长。

另需注意：SSE本质上是文本协议，适合传输文本与结构化文本（如JSON）。若业务以二进制数据为主，传输前需要额外编码（如Base64），此时WebSocket的二进制帧通常是更合适的选择。

七、使用注意事项：接入SSE要关注什么

  1. 并发连接数限制。HTTP/1.1下浏览器对同一域名的并发连接数有限（通常为6个左右），每个SSE连接会长期占用一个名额，页面里同时开多个SSE连接可能耗尽额度、阻塞其他请求。启用HTTP/2后，多路复用可让同一域名下的多个流共享连接，此问题可明显缓解。
  2. 中间层配置。反向代理、网关等中间层默认可能开启响应缓冲或设置较短超时，导致事件流“攒够一批才下发”或连接被提前断开。上线前应确认中间层关闭了对事件流的缓冲，并调大读写超时；若服务部署在百度智能云等云平台上，同样应结合所用网关、负载均衡类产品的配置项，确认其对流式响应与长连接的支持情况。
  3. 服务端连接管理。SSE连接是长连接，连接本身就是资源。服务端应设置最大连接数、空闲超时与主动关闭策略，防止连接泄漏；推送结束时（如大模型输出完成）应通过约定的事件或结束标记告知客户端，并适时释放服务端资源。
  4. 心跳保活。即使没有业务数据，也应周期性发送注释行作为心跳，避免中间设备因空闲判定连接失效。
  5. 鉴权与安全。SSE走标准HTTP，可直接复用Cookie、Token等既有鉴权体系；但要注意浏览器EventSource构造器不便于注入自定义请求头，实践中常用Cookie或URL参数携带凭证。生产环境应使用HTTPS，防止事件流中的敏感数据被窃听或篡改。
  6. 消息结束语义。SSE规范本身没有“流结束”字段，实践中通常以约定的结束事件（如event: done或特定结束标记）通知客户端，客户端收到后调用close()主动释放连接。
  7. 错误处理与降级。在少数不支持流式响应的老旧网络环境（如个别企业代理）下，SSE可能表现为“长时间无数据”。必要时可探测后降级为长轮询，保证功能可用。

八、总结

回到定义本身：SSE是一种基于HTTP协议的服务器单向推送技术，通过Keepalive长连接与标准化的事件流格式，让服务端能够简单、可靠地持续向客户端发送数据。

它的核心价值在于：复用HTTP基础设施、客户端零依赖、内建自动重连与断点续传、实现与运维成本低；它的适用边界也很清晰：只支持服务端到客户端的单向推送、以文本传输为主。对实时通知、日志流、数据看板，尤其是大模型逐字输出这类“只下不上”的场景，SSE往往是比WebSocket更简单、更轻量的选择。理解了“HTTP扩展字段 + Keepalive长连接”这个本质，也就抓住了SSE技术设计的全部出发点。

最热文章