Server-Sent Events (SSE) 介绍 – wiki基地

作者： /

服务器发送事件 (Server-Sent Events – SSE) 深入介绍

在现代 Web 应用中，实时数据更新已成为一项基本需求。无论是股票行情、新闻推送、社交媒体通知，还是在线协作工具中的状态更新，用户都期望能够即时获取最新信息，而无需手动刷新页面。为了实现这一目标，Web 技术经历了从传统请求/响应模式到各种实时通信方案的演变。本文将详细介绍其中一种重要且相对简便的技术——服务器发送事件（Server-Sent Events，简称 SSE）。

1. 实时需求的崛起与传统方法的局限性

在 Web 的早期，客户端获取服务器数据的唯一方式是发起 HTTP 请求，服务器处理请求后返回响应，连接随即关闭。这种模式是“请求-响应”型的，完全由客户端驱动。对于需要实时更新的应用场景，这种模式显得力不从心。

考虑一个需要显示实时股票价格的网页。如果使用传统的请求-响应模式，客户端必须定期（例如每隔几秒）向服务器发送一个请求来获取最新的价格。这种技术被称为“轮询”（Polling）。

轮询 (Polling) 的问题：

  1. 效率低下： 客户端无论数据是否更新，都必须不断发起请求。这会消耗服务器资源（处理大量重复请求）、客户端资源（不断发送请求和处理响应）以及网络带宽。
  2. 延迟： 数据更新的及时性取决于轮询间隔。如果间隔太长，用户看到的将是过时的数据；如果间隔太短，又会显著增加系统负担。
  3. 不确定性： 服务器有数据更新时，无法主动通知客户端，只能等待客户端下一次轮询。

为了改进轮询的效率，人们发展出了“长轮询”（Long Polling）。在长轮询中，客户端发起请求后，如果服务器没有新的数据，连接会保持一段时间不关闭，直到有新数据可用或达到超时时间。服务器有新数据时立即返回，客户端收到响应后立即发起新的长轮询请求。

长轮询 (Long Polling) 的问题：

  1. 复杂性： 服务器端需要维护大量处于挂起状态的连接，管理连接的超时和新数据推送逻辑更加复杂。
  2. 效率仍非最优： 虽然比短轮询有所改进，但在数据更新不频繁时，连接仍然会在超时后重新建立，产生额外的开销。在数据频繁更新时，它又退化为类似短轮询的行为。
  3. HTTP 开销： 每次响应后都需要重新建立或维护连接，HTTP 头部等开销依然存在。

这些传统的轮询技术在需要服务器主动向客户端推送数据的场景下显得笨拙且效率低下。因此，需要一种更原生、更高效的服务器推送机制。WebSocket 是一种双向、全双工的通信协议，能够很好地解决实时通信问题。然而，WebSocket 协议相对复杂，需要新的协议头和连接握手过程。对于只需要服务器单向推送数据的场景，引入 WebSocket 可能显得“杀鸡用牛刀”。

Server-Sent Events (SSE) 正是为了解决这一特定问题而诞生的技术：如何在标准的 HTTP 协议基础上，实现服务器向客户端的单向、持续数据推送，并且保持简洁易用。

2. 什么是 Server-Sent Events (SSE)？

Server-Sent Events (SSE) 是 HTML5 规范的一部分，它允许客户端通过标准的 HTTP 连接接收服务器的单向、持续数据流。简单来说，SSE 就是一种浏览器原生支持的技术，让服务器可以“流式”地将数据发送给客户端。

SSE 的核心思想是：

  1. 基于 HTTP： SSE 利用了现有的 HTTP 协议。客户端发起一个普通的 HTTP 请求（通常是 GET 请求）。
  2. 持久连接： 服务器不会在发送完数据后立即关闭连接，而是保持连接开放。
  3. 数据流： 服务器通过这个开放的连接，按照特定的格式持续地向客户端发送数据。
  4. 浏览器原生支持： 现代浏览器内置了 EventSource 这个 JavaScript 对象，专门用于处理 SSE 连接和接收数据。

与 WebSocket 的双向通信不同，SSE 是严格的单向通信，数据流方向只能是从服务器流向客户端。这使得 SSE 特别适合那些只需要从服务器获取实时更新的应用，而客户端无需向服务器发送频繁或大量实时数据的场景。

3. SSE 的工作原理与技术细节

SSE 的工作原理涉及客户端和服务器两端的配合。

3.1 客户端 (Browser) – EventSource API

在客户端，开发者使用内置的 EventSource 对象来建立和管理与服务器的 SSE 连接。

“`javascript
// 创建一个 EventSource 实例，指向服务器的某个 URL
const eventSource = new EventSource(‘/events’);

// 监听 ‘message’ 事件，当服务器发送不带事件类型的数据时触发
eventSource.onmessage = function(event) {
console.log(“收到通用消息:”, event.data); // event.data 包含服务器发送的数据
};

// 监听自定义事件。如果服务器发送了带有 ‘event: ‘ 字段的数据，将触发相应的事件监听器
eventSource.addEventListener(‘priceUpdate’, function(event) {
console.log(“收到价格更新事件:”, event.data);
});

eventSource.addEventListener(‘news’, function(event) {
console.log(“收到新闻事件:”, event.data);
});

// 监听连接打开事件
eventSource.onopen = function(event) {
console.log(“SSE 连接已建立.”);
};

// 监听连接错误事件
eventSource.onerror = function(event) {
console.error(“SSE 连接出错:”, event);
// eventSource.readyState 可以查看连接状态 (0: CONNECTING, 1: OPEN, 2: CLOSED)
if (eventSource.readyState === EventSource.CLOSED) {
console.log(“SSE 连接已关闭.”);
}
};

// 关闭连接
// eventSource.close();
“`

EventSource 对象提供了简洁的 API 来处理连接的建立、数据的接收以及错误和连接关闭等事件。它会自动处理连接断开后的重连逻辑，这是 SSE 一个非常重要的内置特性。

3.2 服务器端 (Server) – text/event-stream 与数据格式

服务器端需要处理客户端发来的 SSE 请求，并按照特定的格式发送数据。关键在于以下两点：

  1. 设置 HTTP 头部： 服务器响应的 Content-Type 必须设置为 text/event-stream。同时，为了保持连接开放并防止代理服务器或浏览器缓存响应，通常还需要设置 Cache-Control: no-cache 和 Connection: keep-alive。
  2. 按照特定格式发送数据： 服务器发送的数据必须遵循 SSE 的流格式。这个格式非常简单，每一条消息由一个或多个以冒号分隔的“字段名: 字段值”对组成，每个字段占一行，消息的结束由一个空行表示。

SSE 定义了四种标准字段：

  • data: 数据字段。服务器发送的实际数据。可以发送多行 data 字段，它们会被连接成一个字符串，并在发送给客户端时用换行符分隔。一个消息可以包含多个 data 行，客户端接收时会将这些行合并，以 \n 分隔。
    data: 这是第一行数据
    data: 这是第二行数据
    客户端 event.data 将会是 "这是第一行数据\n这是第二行数据"。

  • event: 事件类型字段。如果指定了这个字段，客户端的 EventSource 对象将触发一个对应名称的事件，而不是默认的 message 事件。这允许服务器发送不同类型的消息，客户端可以分别监听处理。
    “`
    event: priceUpdate
    data: {“stock”: “AAPL”, “price”: 175.50}

    客户端会触发 `eventSource.addEventListener('priceUpdate', ...)` 中注册的回调。
    * **`id`:** 消息ID字段。如果指定了这个字段，`EventSource` 会记住最后接收到的消息的 ID。如果连接断开，浏览器在尝试重连时会在请求头中包含一个 `Last-Event-ID` 字段，值为最后接收到的 ID。服务器可以利用这个 ID 来判断从哪里开始重新发送数据，避免数据丢失。
    id: 12345
    data: 这是一个带ID的消息

    * **`retry`:** 重连间隔字段。如果指定了这个字段，它表示当连接断开时，浏览器在尝试重连之前应该等待的时间（单位：毫秒）。服务器可以动态地调整客户端的重连策略。
    retry: 5000
    data: 这个消息告诉客户端如果断开，5秒后重连

    “`

一个完整的 SSE 消息示例：

“`
event: notification
id: 98765
retry: 10000
data: 新通知：您有一条新消息！
data: 来自用户Alice

“`
注意：每个消息块之间必须用一个空行分隔。

服务器端实现 SSE 的关键在于：

  1. 当接收到 SSE 请求时，设置正确的 Content-Type 和缓存相关头部。
  2. 保持连接打开，不要发送表示响应结束的信号（例如在 HTTP/1.1 中关闭连接）。
  3. 周期性地或在有新数据可用时，按照 SSE 数据格式将数据写入响应体。
  4. 确保每条消息后有一个空行作为分隔符。

不同的服务器端技术都有相应的库或框架支持 SSE 的实现，例如 Node.js、Python (Flask/Django)、Java (Spring)、PHP 等。

4. SSE 与 WebSocket 的比较

SSE 和 WebSocket 都是实现 Web 实时通信的技术，但它们的设计目标和适用场景有所不同。理解它们的区别对于选择合适的技术至关重要。

特性 Server-Sent Events (SSE) WebSocket
通信方向 单向（服务器 -> 客户端） 双向（服务器 <-> 客户端）
底层协议 基于标准的 HTTP/1.1 或 HTTP/2 协议 独立的 WebSocket 协议 (ws://, wss://)
复杂度 简单，利用现有 HTTP 基础设施，浏览器原生支持 相对复杂，需要单独的握手和协议处理
数据格式 文本 (text/event-stream)，特定格式 文本或二进制，格式自由
自动重连 内置支持，可由服务器控制间隔 (retry) 需要客户端手动实现重连逻辑
代理/防火墙 对 HTTP 友好，通常能穿透 可能受某些代理和防火墙限制
HTTP/2 支持 可以利用 HTTP/2 的多路复用优化性能 需要独立的连接
开销 每次消息只发送数据体和少量格式信息，开销较小 协议开销相对 SSE 略大，但连接一旦建立效率高
浏览器支持 广泛（IE 边缘版本及以上支持，IE11 及更早版本不支持） 广泛（现代浏览器普遍支持）

何时选择 SSE？

  • 当你只需要从服务器向客户端推送数据，而客户端不需要向服务器发送实时或频繁数据时。
  • 应用场景是单向通知、数据流、实时更新（如股票、新闻、评论流、进度条、传感器数据）。
  • 你希望利用现有的 HTTP 基础设施（端口 80/443）和协议特性。
  • 你追求实现上的简洁性，希望利用浏览器内置的自动重连功能。

何时选择 WebSocket？

  • 当你需要服务器和客户端之间的双向实时通信时。
  • 应用场景是聊天应用、在线游戏、协同编辑、需要客户端频繁发送数据的实时仪表盘。
  • 需要传输二进制数据。
  • HTTP/2 并非必须或可用（尽管 SSE 在 HTTP/2 下性能更优，但在 HTTP/1.1 下也能工作，但 WebSocket 的独立连接在高并发双向通信场景下更具优势）。

总的来说，SSE 可以被视为 WebSocket 的一个更轻量级、更专业的替代方案，专注于服务器到客户端的推送。如果你的需求是单向的，SSE 通常是更简单、更有效的选择。

5. SSE 的优点

基于上述分析，SSE 具有以下显著优点：

  1. 实现简单： 基于标准的 HTTP 协议和简单的 EventSource API，开发门槛较低。
  2. 原生支持： 现代浏览器原生支持 EventSource 对象，无需引入第三方库即可使用。
  3. 内置自动重连： 浏览器会自动处理连接断开后的重试逻辑，并且重试间隔可以通过服务器的 retry 字段控制，这大大简化了客户端的开发复杂度。
  4. 基于 HTTP： 可以复用现有的 HTTP 基础设施，例如代理、防火墙、负载均衡器通常对 HTTP 流量友好。SSL/TLS 也能直接应用于 SSE 连接（通过 https://）。
  5. 高效： 相比轮询，SSE 保持连接开放，只在有新数据时发送，避免了不必要的请求和响应开销。相比 WebSocket，对于单向推送场景，其协议开销更小。
  6. 多种事件类型： 通过 event 字段，服务器可以发送不同类型的消息，客户端可以按需监听处理，提高了灵活性。
  7. 断线重传支持： 通过 id 字段和 Last-Event-ID 请求头，服务器可以实现断点续传，减少数据丢失的风险。
  8. HTTP/2 优化： 在 HTTP/2 下，多个 SSE 连接可以复用同一个 TCP 连接（多路复用），进一步减少了连接建立的开销，解决了 HTTP/1.1 下浏览器对同一域名连接数限制的问题。

6. SSE 的常见应用场景

SSE 非常适合以下类型的应用：

  • 实时股票和加密货币行情： 不断更新的价格数据流。
  • 新闻和博客更新： 新文章发布或评论通知。
  • 社交媒体动态： 新的朋友圈、评论或点赞通知。
  • 后台任务进度指示： 例如文件上传、视频转码、报告生成等耗时操作的进度条或完成通知。
  • 实时排行榜或统计数据： 比赛得分、在线用户数、网站流量等。
  • 通知中心： 网站或应用的站内信、系统通知。
  • 日志监控： 将实时的服务器日志或应用日志推送到前端控制台。
  • 物联网 (IoT) 数据监控： 传感器数据的实时推送。

7. SSE 的挑战与注意事项

尽管 SSE 优点很多，但在实际应用中也需要考虑一些限制和挑战：

  1. 浏览器支持： 最大的限制是 Internet Explorer (IE) 及其早期版本不支持 SSE（IE 11 及更早版本）。虽然 Edge 浏览器和所有现代浏览器（Chrome, Firefox, Safari, Opera 等）都支持 SSE，但在需要兼容 IE 的场景下，可能需要考虑回退方案（如长轮询）或使用 WebSocket。
  2. 连接数限制： 在 HTTP/1.1 下，浏览器对同一域名下的并发 HTTP 连接数有限制（通常是 6-8 个）。如果应用需要同时开启大量 SSE 连接（例如每个组件或数据源都开启一个独立的 SSE 连接），可能会达到这个限制。幸运的是，HTTP/2 通过多路复用很好地解决了这个问题。如果服务器和客户端都支持 HTTP/2，多个 SSE 连接可以共用一个底层 TCP 连接。
  3. 单向性： SSE 是单向的。如果你的应用需要客户端频繁地向服务器发送实时数据（例如聊天消息、游戏操作），SSE 就不适合，应该使用 WebSocket。
  4. 代理和缓存问题： 虽然 SSE 基于 HTTP，但某些配置不当的代理服务器可能会缓存 SSE 响应或提前关闭连接。设置正确的 HTTP 头部（如 Cache-Control: no-cache, Connection: keep-alive）可以缓解这些问题，但在复杂的网络环境下仍需注意测试。
  5. 服务器资源： 维持大量开放的 SSE 连接会消耗服务器资源（内存、连接句柄）。虽然通常比长轮询更有效率，但在极端并发量下仍需进行性能测试和优化。
  6. 数据格式： SSE 的数据格式是基于文本的简单格式。虽然可以通过 data 字段发送 JSON 或其他文本格式的数据，但与 WebSocket 原生支持二进制数据相比，SSE 更适合文本数据的推送。

8. 总结

Server-Sent Events (SSE) 是一种优雅且简洁的服务器到客户端单向数据推送技术。它利用了标准的 HTTP 协议和浏览器内置的 EventSource API，提供了自动重连、事件类型区分等实用功能。

对于那些只需要服务器向客户端发送实时更新的应用场景，SSE 提供了一个比轮询更高效、比 WebSocket 更简单的解决方案。它非常适合构建实时仪表盘、通知系统、股票行情、新闻推送等应用。

在选择实时通信技术时，开发者应该充分理解 SSE、WebSocket 以及传统的轮询/长轮询的优缺点，并结合项目的具体需求（通信方向、数据类型、浏览器兼容性要求、实现复杂度偏好等）来做出最合适的决策。在很多只需要单向推送的场景下，SSE 无疑是一个值得优先考虑的强大工具。随着 HTTP/2 的普及，SSE 的连接数限制问题也得到了缓解，其应用前景依然广阔。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部