然而，在许多场景下，我们真的需要如此“重型”的武器吗？

想象一下这些常见的需求：

• 一个实时更新的数据大屏，展示最新的业务指标。
• 一个新闻网站，向用户推送突发新闻。
• 一个后台系统，当耗时任务完成后给用户发送通知。

在这些场景中，数据流是单向的：从服务器到客户端。客户端只是一个被动的接收者。如果这时我们依然选择 WebSocket，就好像为了寄一封信而专门建立了一条双向的私人高速公路——功能强大，但过于复杂且成本高昂。

 是时候认识一下 WebSocket 的轻量级表亲了：Server-Sent Events (SSE)。它用一种极其优雅和简单的方式，完美解决了单向数据推送的难题。

一： SSE 核心原理：HTTP 长连接的流式传输实现

        SSE 的本质是基于 HTTP 协议的单向长连接通信，其核心机制依赖 HTTP 分块传输编码（Transfer-Encoding: chunked），无需新增协议或端口，可直接复用现有 HTTP/HTTPS 生态。

 SSE 是什么？它为何如此轻量？

   Server-Sent Events (SSE) 是一种允许服务器通过单个、持久的 HTTP 连接向客户端推送更新的技术。它的魅力在于它的极简主义。

1. 通信流程

• 连接建立
  ：客户端通过 EventSource 接口发起 GET 请求，请求头指定 Content-Type: text/event-stream，告知服务端需建立 SSE 连接；
• 长连接维持
  ：服务端接收请求后，返回 200 OK 响应，并通过响应头 Cache-Control: no-cache（禁用缓存）、Connection: keep-alive（保持长连接）维持连接不中断；
• 数据流式推送
  ：服务端通过分块传输编码，将数据按 SSE 规范格式持续推送至客户端，每块数据以空行分隔，客户端接收后即时解析渲染；
• 连接断开与重连
  ：客户端断开连接（如刷新页面、网络异常）时，浏览器会自动触发重连（默认间隔 3 秒），且可通过 Last-Event-ID 请求头携带最后接收的消息 ID，实现断点续传。

2. 数据格式规范

SSE 对推送数据有严格的格式要求，确保客户端能正确解析，核心字段包括：

• data
  ：消息体核心内容，支持多行（每行前缀均为 data:），最终客户端会合并为一个字符串；
• id
  ：消息唯一标识，用于断点续传，客户端重连时会通过 Last-Event-ID 告知服务端最后接收的消息；
• event
  ：自定义事件类型，默认触发客户端 onmessage 事件，可通过该字段分类推送（如 event: notice 对应通知类消息）；
• 格式示例：

event: alertid: 1001data: 服务器 CPU 使用率超过 80%data: 告警时间：2024-05-2014:30:00data: 系统运行正常，当前在线人数：1200

二、SSE 核心特性与应用场景

1. 关键特性

• 原生支持，零依赖
  ：主流浏览器（Chrome、Firefox、Safari、Edge 现代版）原生支持 EventSource 接口，无需引入 WebSocket 等第三方库；
• 部署轻便，兼容性强
  ：基于 HTTP 协议，可直接适配现有代理服务器、负载均衡器和认证机制，无需额外配置端口或协议；
• 单向推送，轻量高效
  ：专注服务端→客户端的单向数据传输，无需维护双向通信状态，开发复杂度远低于全双工技术；
• 自动重连，可靠性高
  ：浏览器原生实现重连机制，配合 id 字段可实现断点续传，降低数据丢失风险。

2. 典型应用场景

SSE 适合无需客户端反向传输数据的实时场景，例如：

• 实时通知：系统公告、订单状态变更、消息提醒；
• 数据监控：服务器资源监控、设备状态实时反馈；
• 流式输出：LLM 聊天机器人逐字响应、文件上传/下载进度提示；
• 实时数据展示：股票行情、新闻更新、体育赛事比分直播。

拓展： 

1. 它就是 HTTP，别无其他

与 WebSocket 需要通过 ws:// 协议进行复杂的“升级握手”不同，SSE 完全运行在标准的 HTTP/HTTPS 之上。这意味着： 

• 无需特殊的服务器：任何支持 HTTP 长连接的后端框架（Node.js, Python, Go, Java…）都能轻松实现。

• 无缝兼容现有网络：代理、防火墙、负载均衡器都能自然地处理 SSE，因为对它们来说，这只是一个尚未结束的 HTTP 请求。

• 更少的协议开销：没有复杂的帧封装，消息就是纯文本，简单直接。

2. 客户端简单到令人惊喜

在前端，你不需要引入任何第三方库。浏览器原生提供了 EventSource API，使用起来极其简单：

// 连接到服务器的事件流端点const sse = new EventSource('/sse');// 监听服务器发来的消息sse.onmessage = (event) => {    console.log('新消息:', event.data);}// 监听错误sse.onerror = (err) => {    console.error('SSE 发生错误:, err);    // 最棒的是:浏览器会自动处理重连!};

    就是这么简单！没有复杂的连接状态管理，没有心跳检测，更没有手动重连逻辑。浏览器为你搞定了一切。

三： 直观对比：SSE vs. WebSocket vs. 长轮询

在实时通信领域，SSE 常与 WebSocket、长轮询进行对比，三者的核心差异如下：

一言以蔽之： 当你需要双向对话时，用 WebSocket。当你只需要听服务器“广播”时，SSE 是更聪明、更轻量的选择。

选型建议：

• 若需双向交互（如即时聊天、在线文档协作），优先选择 WebSocket；
• 若仅需服务端单向推送，且追求低开发成本、兼容现有 HTTP 生态，选择 SSE；
• 长轮询仅适用于不支持 SSE 和 WebSocket 的老旧环境，现已基本被淘汰。

四、SSE 技术短板与规避方案

          SSE 虽轻量易用，但受限于 HTTP 协议特性和设计定位，存在明显短板，需结合场景合理规避：

1. 单向通信限制

• 问题：仅支持服务端→客户端推送，客户端无法通过同一连接向服务端发送数据；
• 规避方案：需双向交互时，搭配 HTTP POST/AJAX 实现“ SSE 推送 + 普通请求回传”的组合模式，或直接切换 WebSocket。

2. 浏览器兼容性与连接限制

• 问题：IE 浏览器完全不支持，Edge 早期版本需特殊配置；浏览器对同一域名的并发 HTTP 连接数限制为 6 个，多 SSE 连接会占用连接池；
• 规避方案：需兼容 IE 时使用 event-source-polyfill 垫片；多连接场景采用“域名分片”（不同模块使用不同子域名）或“合并推送”（多个模块数据打包为一个 SSE 流）。

3. 功能局限性

• 问题：仅支持 GET 请求，无法携带大量请求体；不支持二进制数据传输，需 Base64 编码（额外消耗 33% 带宽）；
• 规避方案：复杂参数通过 URL 或请求头传递；二进制数据场景优先选择 WebSocket。

4. 服务器与网络适配问题

• 问题：长连接会占用服务器文件描述符和内存，高并发场景需额外优化；部分老旧代理/网关不支持 HTTP 分块传输，可能断开空闲连接；
• 规避方案：实现心跳检测（每 30 秒推送空消息）维持连接；配置代理/网关超时时间（如 Nginx proxy_read_timeout = 3600s）；通过连接池管理、空闲连接回收优化服务器资源。

五: 实战演示：一个简单的实时时钟

让我们看看用 Node.js (Express) 实现一个 SSE 服务有多简单。

后端 (server.js):

const express = require('express');const app = express();app.get('/sse', (reg，res)=>{    // 设置 SSE 必需的头部信息    res.writeHead(200, {        'Content-Type': 'text/event-stream',        'Cache-Control': 'no-cache',        'Connection': 'keep-alive',    });    // 每秒向客户端发送一次当前时间    const intervalId = setInterval(() => {        // SSE 格式:`data:[你的数据]\n\n`        res.write(`data: ${new Date().toLocaleTimeString()}\n\n`);     }, 1000);    // 当客户端关闭连接时，停止发送，避免资源浪费    req.on('close', () => {        clearInterval(intervalId);        res.end();    });});// 提供一个简单的 HTML 页面app.get('/', (req, res) => {    res.send(`      <h1>SSE 实时时钟</h1>      <div id="clock"></div>      <script>        const clock=document.getElementById('clock');        const sse =new EventSource('/sse');        sse.onmessage = (event) => {          clock.textContent = event.data;        };      </script>     `);});app.listen(3000, () =>{    console.log('服务器运行在 http://lcalhost:3000');});

后端代码清晰明了：设置头部，然后在一个循环里用 res.write() 发送格式化的数据即可。

前端代码更是嵌入在 HTML 中，只有短短几行。

总结：

SSE 是 HTTP 原生的实时推送技术，以“简单、轻量、低部署成本”为核心优势，完美适配无需双向交互的实时场景。其本质是通过 HTTP 长连接与分块传输，实现服务端到客户端的流式数据推送，无需复杂的协议升级或第三方依赖，可快速集成到现有 Web 生态中。

但需明确：SSE 并非万能方案，其单向通信、不支持二进制传输、IE 兼容性差等短板，决定了它无法替代 WebSocket 在双向交互场景的地位。开发时需根据实际需求选型——若追求“快速落地、低维护成本”且仅需单向推送，SSE 是最优解；若需双向交互或二进制传输，则应优先选择 WebSocket。

随着实时通信需求的普及，SSE 作为“轻量级实时方案”，在 LLM 应用、监控系统、实时通知等场景的应用会愈发广泛。掌握其核心原理与实践技巧，能帮助开发者在满足业务需求的同时，平衡开发效率与系统性能。

阅读原文：原文链接