什么是Server-Sent Events (SSE)？一文读懂其原理与应用

在Web 2.0时代，实时通信能力已成为现代Web应用不可或缺的核心要素。从社交媒体的即时通知，到股票价格的实时波动，再到在线文档的协同编辑，用户对“即时”的需求从未如此强烈。为了满足这一需求，开发者们探索并实践了多种技术，其中 Server-Sent Events (SSE) 以其独特的优势，在服务器到客户端的单向实时数据推送领域占据了一席之地。

本文将深入探讨 Server-Sent Events (SSE) 的方方面面，从其诞生的背景，到工作原理的细致剖析，再到与其他主流实时通信技术的对比，最后通过丰富的应用场景和代码示例，助您一文读懂 SSE 的精髓。

引言：实时Web的挑战与SSE的诞生

传统Web应用的基石是HTTP协议，它遵循经典的“请求-响应”模型：客户端发起请求，服务器处理并返回响应。这个模型对于静态内容或一次性数据获取非常高效。然而，当涉及到服务器需要主动向客户端推送数据时，传统的HTTP模型就显得力不从心了。例如，当您的朋友点赞了您的动态，服务器需要立即通知您，而不是等待您下次刷新页面。

为了解决这一问题，开发者们曾尝试了多种“曲线救国”的方案：

短轮询 (Short Polling)：客户端每隔N秒就向服务器发送一个请求，询问是否有新数据。
- 优点：实现简单。
- 缺点：效率低下，大量重复请求消耗服务器资源和网络带宽，数据实时性取决于轮询间隔，延迟较高。
长轮询 (Long Polling)：客户端发送请求后，如果服务器没有新数据，则挂起连接，直到有新数据可用或者连接超时才返回响应。客户端收到响应后立即发起新的请求。
- 优点：相较于短轮询，减少了请求次数，降低了服务器负载。
- 缺点：实现相对复杂，每个连接仍需维护较长时间，服务器资源占用依然存在，并且每次响应后都需要重新建立连接，仍有延迟。

这些方案或多或少地存在效率、资源消耗或实时性方面的不足。随着HTML5的兴起，浏览器和Web标准开始探索更原生、更高效的实时通信方式。WebSocket 应运而生，提供了全双工的持久连接。然而，对于某些特定的场景——即仅需服务器向客户端单向推送数据，而客户端无需向服务器发送大量实时消息——WebSocket 的全双工特性可能显得有些“大材小用”，且其协议握手和实现复杂度也略高于需求。

正是在这样的背景下，Server-Sent Events (SSE) 作为一种更轻量级、更专注于单向服务器推送的技术被引入。它提供了一种基于HTTP的、原生的、高效的解决方案，专注于解决“服务器有什么新的，告诉我”这一核心需求。

一、什么是Server-Sent Events (SSE)？核心概念解析

Server-Sent Events (SSE) 直译为“服务器发送事件”，它是一种 HTML5 规范，允许浏览器通过 HTTP 连接从服务器接收事件流。简单来说，它使得服务器能够以流的形式将数据实时推送给客户端，而客户端无需显式地不断发送请求。

SSE 的核心特点可以概括为：

基于 HTTP/S 协议：SSE 并不是一个全新的协议，它完全构建在现有的 HTTP/S 协议之上。这意味着它能很好地兼容现有的基础设施（如代理、防火墙），并且易于部署。
单向通信：SSE 仅支持服务器向客户端的单向数据流。客户端可以发起连接请求，但一旦连接建立，数据流的方向就固定为服务器到客户端。
持久连接 (Long-lived HTTP Connection)：一旦客户端发起连接，服务器会保持这个 HTTP 连接打开，并源源不断地通过这个连接发送数据。这与传统的“请求-响应”模式不同，后者在发送完响应后会立即关闭连接。
事件流 (Event Stream)：服务器发送的数据被格式化为一系列事件，每个事件包含一个或多个字段，如 data（事件数据）、event（事件类型）、id（事件ID）和 retry（重连间隔）。
浏览器原生支持：现代浏览器通过 EventSource 接口原生支持 SSE，使得在客户端实现 SSE 变得非常简单。

二、SSE 工作原理：幕后的魔法

理解 SSE 的工作原理需要分别从客户端和服务器端来看。

2.1 客户端：EventSource API

在客户端，JavaScript 提供了一个内置的 EventSource 对象来处理 SSE 连接。

建立连接：
客户端通过创建一个 EventSource 实例来发起与服务器的 SSE 连接。
javascript const eventSource = new EventSource('/events');
这里的 /events 是服务器端用于处理 SSE 请求的URL。当 EventSource 实例被创建时，浏览器会自动向该 URL 发送一个标准的 HTTP GET 请求。
HTTP 请求头部：
这个 GET 请求会带有一个特殊的 Accept 请求头：Accept: text/event-stream。这个头部告知服务器，客户端期望接收一个事件流。
监听事件：
EventSource 对象提供了几种事件监听器来处理不同状态和接收到的数据：
- eventSource.onopen：当连接成功建立时触发。
- eventSource.onmessage：当服务器发送不带 event 字段的普通消息时触发。消息内容通过 event.data 访问。
- eventSource.onerror：当连接发生错误（如网络中断、服务器关闭连接）时触发。
- eventSource.addEventListener(eventName, handler)：用于监听服务器发送的带有特定 event 字段的自定义事件。
自动重连：
SSE 规范内置了自动重连机制。如果连接中断（例如网络故障或服务器端关闭连接），浏览器会尝试在一段时间后自动重新建立连接。服务器可以通过发送 retry: 字段来指定重连间隔（毫秒），否则浏览器会使用默认的重连间隔（通常是几秒）。
事件 ID (Event ID)：
服务器可以为每个事件指定一个 id: 字段。当浏览器尝试重连时，它会向服务器发送一个特殊的 Last-Event-ID 请求头，值为上次成功接收到的事件的 id。这允许服务器在重连后从上次发送中断的地方继续发送数据，确保消息不丢失。
关闭连接：
客户端可以通过调用 eventSource.close() 方法来手动关闭 SSE 连接。

2.2 服务器端：构建事件流

服务器端需要做以下几件事来响应客户端的 SSE 请求：

设置响应头部：
当服务器接收到客户端的 Accept: text/event-stream 请求时，它必须返回以下HTTP响应头部：
- Content-Type: text/event-stream：这是最重要的头部，它告知浏览器此响应是一个事件流。
- Cache-Control: no-cache：指示客户端不要缓存此响应。
- Connection: keep-alive：保持连接打开。这是长连接的关键。
保持连接开放：
服务器不能像处理普通HTTP请求那样在发送完数据后立即关闭连接。它需要持续地保持连接打开，并通过该连接不断地写入数据。
数据格式：
服务器发送的每个事件都必须遵循特定的文本格式，以换行符 \n 分隔字段，并以双换行符 \n\n 结束一个事件。
- data: 字段：包含事件的数据内容。可以有多行 data: 字段，它们会被合并为一个字符串，并在每行之间插入换行符。
  data: 这是第一行数据 data: 这是第二行数据 \n\n
- event: 字段：可选。指定事件的类型。客户端可以通过 addEventListener() 监听特定类型的事件。
  event: priceUpdate data: {"stock": "AAPL", "price": 175.25} \n\n
- id: 字段：可选。指定事件的唯一ID。用于客户端自动重连时告知服务器上次收到的事件。
  id: 12345 event: notification data: 您有新的消息！ \n\n
- retry: 字段：可选。指定客户端在连接断开后，下次尝试重连前的等待时间（毫秒）。
  retry: 5000 data: server is busy, retry after 5 seconds \n\n
- : (注释行)：以冒号开头的行会被忽略，可用于发送心跳包或调试信息。
  : This is a comment, useful for heartbeats \n\n
刷新缓冲区 (Flush)：
服务器在发送数据后，需要确保数据立即被发送到客户端，而不是停留在服务器的输出缓冲区中。不同的服务器语言和框架有不同的方式来刷新（flush）输出缓冲区。

2.3 连接生命周期总结

客户端发送 GET 请求，带 Accept: text/event-stream。
服务器响应 200 OK，带 Content-Type: text/event-stream 等头部。
服务器保持连接打开，并周期性地发送格式化的事件数据。
客户端通过 EventSource 监听并处理事件。
如果连接中断，浏览器等待 retry 指定的时间（或默认时间），然后自动使用 Last-Event-ID 发起新的连接请求。
客户端调用 eventSource.close() 或页面关闭时，连接终止。

三、SSE 的核心特性与优势

SSE 之所以能够在实时通信领域占据一席之地，得益于其一系列显著的特性和优势：

实现简单，API 直观：
- 客户端仅需 EventSource 一个API即可实现，无需复杂的WebSocket握手或第三方库。
- 服务器端也只是设置HTTP头部并按特定格式输出文本流，基于HTTP的天然特性让它易于理解和实现。
基于 HTTP，兼容性好：
- 由于是基于标准的 HTTP/S 协议，SSE 能够很好地穿透各种代理服务器、防火墙，无需特殊的配置或协议升级。
- 它无需额外的端口或协议，与现有的Web基础设施无缝集成。
内置的自动重连机制：
- 这是 SSE 最强大的特性之一。当网络连接中断或服务器故障时，浏览器会自动尝试重新建立连接。
- 结合 id: 字段和 Last-Event-ID 请求头，可以实现断点续传，确保客户端不会丢失任何消息，这大大简化了开发者的错误处理逻辑。
高效的单向通信：
- 对于那些只需要服务器向客户端推送数据的场景（如实时通知、数据更新），SSE 比全双工的 WebSocket 更加轻量和高效。它避免了 WebSocket 协议握手和帧处理的开销。
- 利用 HTTP/2 的多路复用特性，单个 TCP 连接可以承载多个 SSE 流，进一步提升效率。
事件化设计：
- 支持自定义事件类型 (event: 字段)，使得客户端可以根据不同的事件类型注册不同的处理函数，增强了消息的语义化和可维护性。
纯文本协议：
- SSE 传输的数据是纯文本，易于阅读、调试和排错。
内存占用相对较少：
- 相较于长轮询每次请求和响应的HTTP头部开销，SSE 的一个持久连接可以大大减少头部重复发送，降低了网络和服务器的内存占用。

四、SSE 的局限性与缺点

尽管 SSE 拥有诸多优势，但它并非万能，也存在一些局限性，使得其不适用于所有实时通信场景：

仅支持单向通信：
- 这是 SSE 最核心的限制。如果您的应用需要客户端频繁地向服务器发送实时消息（如聊天室、多人游戏），SSE 无法满足需求。它只能从服务器向客户端推送数据。
仅支持文本数据：
- SSE 协议规定传输的数据必须是 UTF-8 编码的文本。如果需要传输二进制数据（如图片、音频、视频流），则必须先将其编码为文本格式（如 Base64），这会增加数据量和编解码开销。
浏览器连接数限制：
- 出于浏览器设计和资源考虑，大多数浏览器对每个域名下的 SSE（以及普通 HTTP）连接数量有限制，通常为 6 个。这意味着一个页面最多只能同时打开 6 个 SSE 连接。对于需要大量独立数据流的应用来说，这可能成为瓶颈。
- 虽然可以通过 HTTP/2 的多路复用来缓解，但物理连接数依然受到限制。
缺少原生客户端支持：
- EventSource 是浏览器端的 API。对于原生移动应用（iOS/Android），通常需要自行实现 HTTP 长连接和事件流解析逻辑，或者使用第三方库。
IE 浏览器不支持：
- Internet Explorer 及旧版 Edge 浏览器原生不支持 EventSource。如果需要兼容这些浏览器，需要使用 Polyfill（垫片库），例如 event-source-polyfill。

五、SSE 与其他实时通信技术的对比

为了更好地理解 SSE 的定位，我们将其与短轮询、长轮询和 WebSocket 进行详细对比。

特性/技术	短轮询 (Short Polling)	长轮询 (Long Polling)	Server-Sent Events (SSE)	WebSocket
通信方向	客户端 -> 服务器 (请求-响应)	客户端 -> 服务器 (请求-响应，服务器挂起)	服务器 -> 客户端 (单向)	双向
底层协议	HTTP/S	HTTP/S	HTTP/S	WS (独立协议，基于HTTP握手)
连接模型	每次请求都建立和关闭连接	保持连接直到有数据或超时，再新建	持久的HTTP连接	持久的全双工TCP连接
数据格式	任意 (基于HTTP)	任意 (基于HTTP)	UTF-8 文本流	文本或二进制帧
实现复杂度	简单	中等	简单	中等 (需要处理帧、心跳等)
网络开销	高 (大量重复HTTP头部)	中等 (每次响应后重建连接)	低 (一次HTTP握手)	低 (一旦连接建立，只传输数据帧)
自动重连	无	无 (需手动实现)	内置	无 (需手动实现)
防火墙/代理	友好	友好	友好 (基于HTTP)	可能受限 (需支持WebSocket协议)
浏览器限制	无	无	每个域名通常6个连接	无明显限制 (受限于系统资源)
典型应用	不敏感的定期数据更新	简单通知、聊天室	实时仪表盘、新闻、比分、通知	聊天室、多人游戏、协同编辑

总结：

短轮询：最简单，但效率最低，几乎不推荐用于实时场景。
长轮询：效率有所提升，但仍需重复建立连接，适用于简单、低频的实时场景。
SSE：完美适用于服务器到客户端单向推送的场景，实现简单，内置自动重连和事件ID，基于HTTP兼容性好。
WebSocket：最强大、最灵活，适用于双向实时交互的场景，支持文本和二进制数据。

何时选择 SSE？

当您的应用需求是：
1. 主要是服务器向客户端推送数据。
2. 客户端不需要向服务器发送频繁的实时消息。
3. 对数据格式要求是文本。
4. 希望实现简单，且享受自动重连等内置功能。
5. 对浏览器同时连接数（6个）有一定容忍度。

典型的例子就是各种通知、数据监控、实时行情等。

何时选择 WebSocket？

当您的应用需求是：
1. 需要客户端和服务器进行频繁、实时的双向通信。
2. 需要传输二进制数据。
3. 对连接数没有严格限制，或需要突破 6 个连接的限制。
4. 实现更复杂、更互动性强的实时应用，如聊天室、在线游戏、实时协同编辑等。

六、SSE 的典型应用场景

SSE 在许多领域都有广泛的应用，以下是一些典型的例子：

实时新闻与博客更新：当新的文章或评论发布时，立即推送到用户的浏览器。
股价/汇率实时更新：金融平台实时显示股票、外汇、加密货币等价格变动。
体育赛事比分直播：实时更新球赛比分、赛况等信息。
社交媒体通知/动态流：用户收到点赞、评论、关注、私信等通知，或者实时刷新好友动态。
数据监控仪表盘：运维或BI系统实时展示服务器性能、业务指标、生产线数据等。
在线教育/会议直播：直播过程中，老师或主持人发布公告、投票结果、答题器结果等。
长时间运行任务进度：例如文件上传进度、数据处理进度、报告生成进度等，服务器实时通知客户端任务状态。
日志实时输出：开发或运维工具实时显示服务器应用程序的日志。

七、SSE 实现示例

下面通过一个简单的 Node.js (Express) 服务器和纯 JavaScript 客户端的例子来演示 SSE 的实现。

7.1 服务器端 (Node.js with Express)

“`javascript
// app.js
const express = require(‘express’);
const app = express();
const port = 3000;

// 存储所有连接的客户端的响应对象
const clients = [];

// 心跳间隔，确保连接不会因为不活动而被代理或防火墙关闭
const HEARTBEAT_INTERVAL = 30000; // 30秒

// SSE 路由
app.get(‘/events’, (req, res) => {
// 设置SSE响应头部
res.writeHead(200, {
‘Content-Type’: ‘text/event-stream’,
‘Cache-Control’: ‘no-cache’,
‘Connection’: ‘keep-alive’,
‘Access-Control-Allow-Origin’: ‘*’, // 允许跨域访问
// 如果使用Nginx等反向代理，可能需要添加以下头部以确保缓冲被禁用
// ‘X-Accel-Buffering’: ‘no’
});

// 发送一个初始事件，告知客户端连接已建立
// event: open 可以是自定义的，客户端用 addEventListener('open', ...) 监听
res.write('event: open\n');
res.write('data: Connection established\n\n');

// 将客户端响应对象存储起来，以便后续推送数据
clients.push(res);
console.log(`Client connected. Total clients: ${clients.length}`);

// 发送心跳包以保持连接活跃，防止连接超时
// 心跳包通常是注释行，客户端会忽略，但能让连接保持活跃
const heartbeat = setInterval(() => {
    res.write(': heartbeat\n\n'); // 发送注释行作为心跳
    res.flush && res.flush(); // 确保数据立即发送
}, HEARTBEAT_INTERVAL);

// 监听客户端断开连接事件
req.on('close', () => {
    console.log('Client disconnected');
    clearInterval(heartbeat); // 清除心跳定时器
    // 从客户端列表中移除断开的连接
    const index = clients.indexOf(res);
    if (index > -1) {
        clients.splice(index, 1);
    }
    console.log(`Client disconnected. Total clients: ${clients.length}`);
});

});

// 模拟数据推送的API
// 任何请求到 /send-message 都会向所有连接的SSE客户端推送消息
let messageId = 0;
app.get(‘/send-message’, (req, res) => {
const { type = ‘message’, data = ‘Hello from server!’ } = req.query;
messageId++;
const message = id: ${messageId}\n;
if (type !== ‘message’) {
message += event: ${type}\n;
}
message += data: ${data}\n\n;

// 向所有连接的客户端推送消息
clients.forEach(client => {
    try {
        client.write(message);
        client.flush && client.flush(); // 确保数据立即发送
    } catch (error) {
        console.error('Error writing to client:', error.message);
        // 如果写入失败，可以考虑移除该客户端
        // 注意：req.on('close') 应该会处理这种情况，此处仅作示例
    }
});

res.send('Message sent to all connected clients.');

});

// 启动服务器
app.listen(port, () => {
console.log(Server listening at http://localhost:${port});
console.log(SSE endpoint: http://localhost:${port}/events);
console.log(Trigger message: http://localhost:${port}/send-message);
console.log(Trigger custom event: http://localhost:${port}/send-message?type=customEvent&data=Custom event data);
});

“`

运行服务器：
1. npm init -y
2. npm install express
3. node app.js

7.2 客户端 (HTML/JavaScript)

“`html

Server-Sent Events (SSE) Client

Server-Sent Events (SSE) 示例

打开浏览器的控制台查看 EventSource 的详细日志。

尝试在浏览器地址栏访问 http://localhost:3000/send-message 来触发服务器推送消息。

尝试访问 http://localhost:3000/send-message?type=news&data=突发新闻：地球是圆的！触发自定义新闻事件。

接收到的消息：

“`

将上述HTML保存为 index.html，然后通过浏览器打开该文件（确保服务器 app.js 正在运行）。您将看到实时消息不断从服务器推送到浏览器。

八、高级主题与注意事项

可扩展性 (Scalability)：
当并发连接数很高时，单个服务器可能无法处理。可以采用以下策略：
- 负载均衡：使用 Nginx 等负载均衡器分发客户端请求。需要注意的是，SSE 是持久连接，为了避免客户端在重连时被分配到不同的服务器导致 Last-Event-ID 丢失，可能需要配置“粘性会话 (Sticky Sessions)”，确保同一个客户端的请求总是路由到同一台服务器。
- 消息总线：在微服务架构中，多个 SSE 服务器实例可以通过消息队列（如 Redis Pub/Sub, Kafka, RabbitMQ）订阅消息，然后将消息转发给各自维护的客户端连接。这样可以解耦消息生产者和消费者，并实现水平扩展。
安全性 (Security)：
- 认证与授权：SSE 连接通常需要在请求时进行认证（如通过 Cookie、JWT Token 在请求头或URL参数中传递）。服务器端应验证用户的权限，确保只有授权用户才能接收特定事件。
- 跨域 (CORS)：如果客户端和服务器不在同一个域，服务器需要设置 Access-Control-Allow-Origin 等 CORS 头部。
- 数据加密：始终通过 HTTPS 建立 SSE 连接，以确保数据传输的机密性和完整性。
代理与防火墙：
由于 SSE 基于标准 HTTP，它通常能很好地穿透代理和防火墙。但某些代理服务器可能会对长连接进行缓冲或超时处理，导致 SSE 连接中断。在服务器端设置 Cache-Control: no-cache 和 X-Accel-Buffering: no (针对 Nginx) 等头部可以帮助缓解这些问题。心跳机制也非常重要，可以防止中间件因长时间无数据传输而关闭连接。
错误处理与心跳：
- 服务器端：除了之前提到的心跳注释行，服务器还应处理客户端意外断开连接的情况（如 req.on('close')），及时清理资源。
- 客户端：EventSource.onerror 是捕获连接错误的关键。利用 event.readyState 判断连接状态，可以提供更好的用户体验。
Polyfill for IE/Edge：
对于不支持 SSE 的旧版浏览器，可以使用 event-source-polyfill 等库来提供兼容性。

总结与展望

Server-Sent Events (SSE) 作为一种基于 HTTP 的轻量级单向实时通信技术，在特定的应用场景下展现出了独特的优势。它通过简单的 API、内置的自动重连和事件 ID 机制，极大地简化了服务器到客户端的数据推送实现，避免了短轮询和长轮询的效率低下，同时也比 WebSocket 在某些场景下更加“恰如其分”。

尽管其单向性和文本限制使其不适用于所有实时场景，但对于那些需要“持续从服务器获取更新”的应用，如实时仪表盘、新闻推送、比分直播、通知系统等，SSE 无疑是一个优雅、高效且易于维护的选择。

随着 HTTP/2 和 HTTP/3 的普及，SSE 能够更好地利用多路复用等特性，进一步提升其在网络传输层面的效率。在未来，SSE 将继续作为Web实时通信技术栈中不可或缺的一员，与 WebSocket 相互补充，共同赋能开发者构建更加动态、响应更迅速的现代Web应用。理解并合理运用 SSE，无疑能为您的项目带来更佳的用户体验和更高的开发效率。

什么是Server-Sent Events (SSE)？一文读懂其原理与应用 – wiki基地

什么是Server-Sent Events (SSE)？一文读懂其原理与应用

引言：实时Web的挑战与SSE的诞生

一、什么是Server-Sent Events (SSE)？核心概念解析

二、SSE 工作原理：幕后的魔法

2.1 客户端：EventSource API

2.2 服务器端：构建事件流

2.3 连接生命周期总结

三、SSE 的核心特性与优势

四、SSE 的局限性与缺点

五、SSE 与其他实时通信技术的对比

六、SSE 的典型应用场景

七、SSE 实现示例

7.1 服务器端 (Node.js with Express)

7.2 客户端 (HTML/JavaScript)

Server-Sent Events (SSE) 示例

接收到的消息：

八、高级主题与注意事项

总结与展望

发表评论取消回复

什么是Server-Sent Events (SSE)？一文读懂其原理与应用

引言：实时Web的挑战与SSE的诞生

一、什么是Server-Sent Events (SSE)？核心概念解析

二、SSE 工作原理：幕后的魔法

2.1 客户端：EventSource API

2.2 服务器端：构建事件流

2.3 连接生命周期总结

三、SSE 的核心特性与优势

四、SSE 的局限性与缺点

五、SSE 与其他实时通信技术的对比

六、SSE 的典型应用场景

七、SSE 实现示例

7.1 服务器端 (Node.js with Express)

7.2 客户端 (HTML/JavaScript)

Server-Sent Events (SSE) 示例

接收到的消息：

八、高级主题与注意事项

总结与展望

发表评论 取消回复

发表评论取消回复