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

作者： /

深入理解 HTTP Server-Sent Events (SSE)：构建高效的服务器到客户端实时通信

在现代 Web 应用中，用户对于实时更新的需求日益增长。从社交媒体的通知、股票价格的跳动、在线游戏的得分变化到后台任务的进度显示，能够即时接收服务器推送的数据已经成为衡量应用交互性和用户体验的重要标准。为了实现这一目标，开发者们探索了多种技术方案，而 HTTP Server-Sent Events (SSE) 就是其中一种优雅且高效的选择，尤其适用于服务器需要单向、持续地向客户端发送数据的场景。

本文将带你深入了解 HTTP SSE 的方方面面：它是什么，为什么我们需要它，它是如何工作的，它的优点、缺点，以及如何在实际应用中有效地使用它。

第一部分：背景与需求 – 为什么需要实时通信？

传统的 Web 应用模型是基于请求-响应机制的：客户端（浏览器）发起一个 HTTP 请求，服务器处理请求并返回一个 HTTP 响应。这种模型对于大多数交互场景（如浏览网页、提交表单）是足够的。然而，当涉及到需要服务器主动向客户端发送信息时，这种模型就显得力不从心了。

考虑以下场景：

  1. 新闻推送/社交媒体更新： 当有新文章发布或新消息到来时，服务器需要立即通知在线的用户。
  2. 实时数据展示： 股票行情、体育赛事比分、天气预报等数据持续变化，客户端需要实时获取最新值。
  3. 后台任务进度： 当用户触发一个耗时较长的后台任务（如文件处理、报告生成）时，客户端需要看到任务的实时进度或完成通知。
  4. 通知系统： Web 应用需要弹出通知来提醒用户事件（如新邮件、系统告警）。

在没有专门的实时通信技术之前，开发者们通常采用以下变通方法来模拟实时性：

  • 轮询 (Polling)： 客户端定时（例如每隔几秒）向服务器发起 HTTP 请求，询问是否有新的数据。
    • 优点： 实现简单，基于标准 HTTP。
    • 缺点： 效率低下，特别是数据不经常更新时，会产生大量无效请求，浪费带宽和服务器资源；数据更新不够实时，取决于轮询间隔。
  • 长轮询 (Long Polling)： 客户端发起一个 HTTP 请求，服务器收到请求后并不立即响应，而是 holding 住连接，直到有新数据可用或连接超时。有新数据时，服务器立即响应并将数据发送给客户端，然后客户端收到响应后立即发起新的请求，重复这个过程。
    • 优点： 比普通轮询更实时，有效避免了无谓的请求。
    • 缺点： 实现相对复杂，服务器需要管理大量挂起的连接；每个事件都需要重新建立连接，有一定开销；仍然是请求-响应模型，不是真正的推送。

虽然长轮询在一定程度上改善了实时性，但这些方法都不能提供一个真正高效、低延迟、可持续的服务器到客户端的推送机制。为了满足这一需求，更先进的 Web 技术应运而生，其中最广为人知的可能是 WebSockets。然而，WebSockets 提供了 双向 通信能力，这意味着客户端和服务器都可以随时发送数据给对方。对于许多只需要 服务器单向 推送数据的场景，WebSockets 可能显得过于复杂或重量级。

正是在这种背景下，HTTP Server-Sent Events (SSE) 应运而生，它专注于解决服务器到客户端的单向实时数据流问题。

第二部分：HTTP Server-Sent Events (SSE) 是什么？

HTTP Server-Sent Events (SSE) 是一种基于 HTTP 的技术，允许服务器通过一个持久的 HTTP 连接向客户端推送事件流数据。与 WebSockets 不同，SSE 是一个 单向 的通信通道，数据只能从服务器流向客户端。

SSE 的核心思想非常简洁：

  1. 客户端通过一个标准的 HTTP GET 请求与服务器建立连接。
  2. 服务器返回一个特殊的响应，其 Content-Type 被设置为 text/event-stream。
  3. 服务器在这个持久的连接上持续地向客户端发送格式化的文本数据块，每个数据块代表一个“事件”。
  4. 客户端通过浏览器内置的 EventSource API 接收并处理这些事件。

SSE 利用了现有的 HTTP 协议，这意味着它可以通过标准的 HTTP/2 连接进行多路复用，并且可以很好地兼容现有的 HTTP 基础设施（如代理服务器、防火墙等）。它提供了一个简单、标准化的方式来实现服务器到客户端的实时数据推送。

第三部分：SSE 的工作原理详解

理解 SSE 的工作原理需要从客户端和服务器两个角度来看。

3.1 客户端如何发起 SSE 连接？ (EventSource API)

在客户端（通常是浏览器），使用 SSE 非常简单，因为它提供了一个内置的 EventSource JavaScript API。

要建立一个 SSE 连接，客户端只需创建一个 EventSource 对象，并传入服务器提供 SSE 流的 URL：

javascript
const eventSource = new EventSource('http://example.com/event-stream');

一旦 EventSource 对象被创建，浏览器就会立即向指定的 URL 发起一个标准的 HTTP GET 请求。服务器收到这个请求后，如果支持 SSE，就会开始发送事件流数据。

EventSource 对象提供了一系列事件来处理连接状态和接收到的数据：

  • open 事件： 当连接成功建立时触发。
    javascript
    eventSource.onopen = function(event) {
    console.log('SSE connection opened.');
    };
  • message 事件： 当服务器发送一个没有指定 event 类型的事件时触发。这是最常见的事件类型，用于接收普通数据。事件数据存储在 event.data 属性中。
    javascript
    eventSource.onmessage = function(event) {
    console.log('Received message:', event.data);
    // event.data 总是字符串
    // 如果发送的是 JSON，需要手动解析：JSON.parse(event.data)
    };
  • error 事件： 当连接发生错误或连接关闭时触发。
    javascript
    eventSource.onerror = function(event) {
    console.error('SSE error occurred:', event);
    // 可以在此处尝试重连或显示错误信息
    };

  • 自定义事件： 服务器可以发送带有特定 event 类型的事件。客户端可以通过 addEventListener() 方法监听这些自定义事件。
    “`javascript
    eventSource.addEventListener(‘priceUpdate’, function(event) {
    console.log(‘Price update received:’, event.data);
    });

    eventSource.addEventListener(‘notification’, function(event) {
    console.log(‘Notification received:’, event.data);
    });
    “`

客户端可以通过调用 eventSource.close() 方法来手动关闭 SSE 连接。

3.2 服务器如何发送 SSE 事件流？

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

  1. 设置正确的 HTTP 响应头： 告诉客户端这是一个事件流。
  2. 保持连接开放： 不要发送 End-of-Stream 指示（如关闭连接或发送 Content-Length）。
  3. 按照特定的格式发送数据： 将数据封装成 SSE 事件格式。
  4. 持续向客户端发送数据： 当有新数据时，将其写入响应体并刷新缓冲区。

3.2.1 重要的响应头

服务器响应客户端的 SSE 请求时，必须包含以下 HTTP 头：

  • Content-Type: text/event-stream： 这是最重要的头，它告诉浏览器这个响应是一个事件流，应该由 EventSource API 处理。
  • Cache-Control: no-cache 或 no-store： 防止浏览器或中间代理缓存事件流数据。
  • Connection: keep-alive： 尽管在 HTTP/1.1 中这通常是默认行为，但明确指定有助于确保连接保持开放。
  • X-Accel-Buffering: no (对于 Nginx): 有些代理服务器（如 Nginx）可能会默认缓冲响应以提高效率。对于 SSE，我们需要禁用缓冲，确保数据一旦可用就立即发送给客户端。其他服务器/代理可能有类似的配置项。

3.2.2 事件流数据格式 (text/event-stream)

服务器发送给客户端的数据必须遵循特定的格式，这个格式是由一系列以换行符分隔的文本行组成的。每个事件由一个或多个字段行组成，最后以一个空行结束。

SSE 定义了四种标准的字段类型：

  1. data: 字段： 携带事件的数据载荷。一个事件可以包含多行 data: 字段。所有 data: 字段的值会合并成一个字符串，每行之间用换行符分隔（但末尾的换行符会被移除）。
    “`
    data: 这是第一行数据。
    data: 这是第二行数据。

    ``
    客户端接收到的    event.data会是“这是第一行数据。\n这是第二行数据。”`

  2. event: 字段： 指定事件的类型。如果存在，客户端可以通过 eventSource.addEventListener() 监听这种类型的事件。如果没有指定 event: 字段，事件类型默认为 "message"。
    “`
    event: notification
    data: 您有一个新通知！

    ``
    客户端可以通过    eventSource.addEventListener(‘notification’, …)` 来监听。

  3. id: 字段： 指定事件的 ID。客户端的 EventSource 会记住最后接收到的事件的 ID。如果连接断开并自动重连，浏览器会在发起的 GET 请求头中包含一个 Last-Event-ID 头，其值为最后接收到的 ID。服务器可以使用这个 ID 来判断客户端错过了哪些事件，从而实现断线重连后从上次断开的地方继续发送事件（但这需要服务器端逻辑支持）。
    “`
    id: 123
    event: message
    data: 这是一条重要消息。

    ``
    如果连接断开后重连，客户端的请求头会包含    Last-Event-ID: 123`。

  4. retry: 字段： 指定浏览器在连接断开后，应该等待多少毫秒再尝试重新连接。如果服务器没有发送 retry 字段，或者 retry 字段的值无效，浏览器会使用一个默认的重连间隔（通常是几秒，具体取决于浏览器实现，例如 Chrome 可能是 3 秒）。
    “`
    retry: 5000
    event: message
    data: 这是一个事件。

    “`
    如果连接断开，浏览器会等待 5 秒后尝试重新连接。

每个事件必须以一个空行结束。 这个空行标志着一个事件的完整发送，浏览器收到空行后才会触发相应的事件监听器。

注释行： 以冒号 : 开头的行是注释行，会被浏览器忽略。服务器可以发送注释行（例如，定期发送一个空的注释行，如 :keepalive\n\n）来保持连接活跃，防止连接因为长时间没有数据传输而被某些代理或防火墙关闭。

“`
: 这是服务器发送的一个心跳包，保持连接活跃

event: message
data: 这是一个实际的数据事件

id: 456
event: update
data: 另一条更新

retry: 10000
id: 457
data: 设置新的重连间隔

“`

3.2.3 服务器端实现逻辑（概念）

服务器端实现 SSE 的基本逻辑如下：

  1. 接收到客户端的 HTTP GET 请求。
  2. 检查请求头，特别是 Accept: text/event-stream 和 Last-Event-ID（如果存在）。
  3. 设置响应头：Content-Type: text/event-stream、Cache-Control: no-cache 等。
  4. 根据需要，发送一个初始的 retry 字段。
  5. 进入一个循环或使用异步机制，等待新的数据或事件发生。
  6. 当有新数据/事件时，将其格式化为 SSE 格式（data: ...\nevent: ...\nid: ...\n\n）。
  7. 将格式化的数据写入响应体的输出流。
  8. 强制刷新 (flush) 输出缓冲区：这是关键步骤，它确保数据立即被发送到客户端，而不是在缓冲区满时才发送。不同编程语言/框架有不同的刷新机制。
  9. 重复步骤 5-8，直到连接关闭（客户端关闭连接，服务器主动关闭，或发生错误）。
  10. 处理连接关闭事件，释放相关资源。

示例（概念性的伪代码）：

“`pseudo
function handleSseRequest(request, response):
// 1. 设置响应头
response.setHeader(‘Content-Type’, ‘text/event-stream’)
response.setHeader(‘Cache-Control’, ‘no-cache’)
response.setHeader(‘Connection’, ‘keep-alive’)
// 对于 Nginx 等可能需要
// response.setHeader(‘X-Accel-Buffering’, ‘no’)

// 可选：从 Last-Event-ID 头获取上次的事件ID，用于断线重连续传
// lastEventId = request.getHeader('Last-Event-ID')

// 2. 发送初始设置 (例如重连间隔)
response.write('retry: 5000\n\n') // 浏览器断开后5秒重连
response.flush()

// 3. 注册事件监听器 或 进入数据发送循环
// 假设有一个事件总线或数据源
eventBus.on('newDataAvailable', function(data):
    // 格式化数据为SSE事件
    sseEvent = formatAsSse(data) // 例如: 'event: update\ndata: ' + JSON.stringify(data) + '\n\n'

    // 4. 将数据写入响应体并刷新
    response.write(sseEvent)
    response.flush() // 强制发送数据到客户端

)

// 5. 保持连接开放 (例如，发送心跳包或等待事件)
// 可以定期发送注释行作为心跳
intervalId = setInterval(function():
    response.write(':keepalive\n\n')
    response.flush()
, 15000) // 每15秒发送一个心跳

// 6. 处理客户端断开连接
request.on('close', function():
    console.log('Client disconnected.')
    clearInterval(intervalId)
    eventBus.off('newDataAvailable', ...) // 移除事件监听器
    // 清理与此连接相关的资源
)

// 注意：服务器框架通常会提供更高级的抽象来处理SSE

“`

实际的服务器端实现会依赖于所使用的编程语言和 Web 框架（如 Node.js, Python/Flask, Ruby/Rails, Java/Spring, PHP 等），但核心原理是相通的。大多数现代 Web 框架都有库或内置支持来更容易地实现 SSE。

3.3 自动重连接机制

SSE 一个非常实用的内置特性是自动重连接。当 EventSource 连接由于网络问题、服务器错误或超时而断开时，浏览器会根据以下规则尝试重新建立连接：

  1. 等待由服务器发送的 retry: 字段指定的毫秒数。如果服务器没有发送 retry 字段，浏览器会使用一个默认的重连间隔（通常是几秒）。
  2. 等待时间结束后，浏览器会向服务器发起一个新的 HTTP GET 请求。
  3. 如果之前服务器发送过带有 id: 字段的事件，浏览器会在重连请求的 HTTP 头中包含 Last-Event-ID 字段，其值是断开前收到的最后一个事件的 ID。
  4. 服务器收到带有 Last-Event-ID 的重连请求后，可以利用这个 ID 来确定从哪个事件开始重新发送数据，从而避免客户端漏掉数据。这部分逻辑需要在服务器端实现。

这个自动重连接机制大大简化了客户端代码，开发者不需要手动编写复杂的重连逻辑。

第四部分：SSE 的优点

相较于其他实时通信技术（尤其是与 WebSockets 相比，或与传统的轮询/长轮询相比），SSE 具有以下显著优点：

  1. 简单性： SSE 基于标准的 HTTP 协议和简单的 EventSource API。与 WebSockets 复杂的握手过程和新的 ws 协议相比，SSE 更容易理解和实现，尤其是在客户端。数据格式也简单，是纯文本。
  2. 基于 HTTP： SSE 直接运行在 HTTP 上，这意味着它能很好地兼容现有的 HTTP 基础设施。大多数代理服务器、防火墙和负载均衡器都对 HTTP 友好，而无需额外的配置来支持 WebSockets（WebSockets 使用不同的协议升级过程）。这使得部署和运维 SSE 应用通常比 WebSockets 更容易。
  3. 自动重连接： 如前所述，浏览器内置的 EventSource API 提供了强大的自动重连接机制，并且可以通过 Last-Event-ID 和 retry 字段进行控制。这极大地减少了客户端处理网络断开和重连的复杂性。
  4. 高效的单向通信： 对于只需要服务器向客户端推送数据的场景，SSE 比 WebSockets 更高效，因为它不需要维护双向通道的状态和协议开销。它的设计就是为流式数据推送量身定制的。
  5. 更好的错误处理： EventSource API 的 onerror 事件可以捕获各种连接错误，并且自动重连机制有助于从临时错误中恢复。
  6. HTTP/2 多路复用： 在 HTTP/2 环境下，多个 SSE 连接可以复用同一个 TCP 连接，这进一步提高了效率，减少了连接建立的开销，并绕过了 HTTP/1.1 中浏览器对同一域名并发连接数的限制（通常是 6-8 个）。

第五部分：SSE 的缺点与限制

尽管 SSE 有很多优点，但它并非万能，存在一些局限性：

  1. 单向通信： 这是 SSE 设计上的特性，但也限制了其应用场景。如果客户端也需要频繁地向服务器发送实时数据（例如聊天应用、在线协作文档），SSE 就无法满足需求，需要使用 WebSockets 或其他双向通信技术。
  2. 仅支持文本数据： SSE 只能传输 UTF-8 编码的文本数据。如果需要传输二进制数据（如图片、音频文件），SSE 需要将二进制数据编码成文本格式（例如 Base64），这会增加数据体积和编解码开销。WebSockets 原生支持二进制数据传输。
  3. 浏览器并发连接限制： 虽然 HTTP/2 缓解了这个问题，但在 HTTP/1.1 环境下，大多数浏览器对同一域名下的 SSE 连接数量有限制（通常是 6 个）。这对于需要在同一页面上建立大量独立 SSE 连接的应用来说可能是一个问题。
  4. 服务器端实现复杂性（相较于简单的请求/响应）： 虽然比 WebSockets 简单，但实现 SSE 服务器端需要特殊处理，如保持连接开放、禁用缓冲、强制刷新输出流等，这与传统的请求-响应模型有所不同，可能需要依赖 Web 框架的特定功能或库。
  5. 缺乏内置的发布/订阅模式： SSE 本身只是一个传输协议，它不提供内置的服务器端发布/订阅（Pub/Sub）或消息队列功能。服务器需要自己实现或集成外部的消息代理来管理事件的分发给多个连接的客户端。
  6. 旧版 Internet Explorer 不支持： EventSource API 不被 Internet Explorer 浏览器原生支持（包括 IE11）。如果需要支持这些旧版浏览器，需要使用 polyfills（模拟实现的库），或者考虑长轮询等回退方案。

第六部分：SSE vs. WebSockets

SSE 和 WebSockets 是 Web 上实现实时通信的两种主要技术，但它们服务于不同的用例：

特性 HTTP Server-Sent Events (SSE) WebSockets
通信方向 单向 (服务器 -> 客户端) 双向 (服务器 <-> 客户端)
底层协议 基于 HTTP 协议，使用标准请求响应模型 独立协议 (ws/wss)，通过 HTTP 升级握手建立
数据格式 只能传输 文本 (UTF-8) 支持 文本 和 二进制 数据
实现复杂性 客户端简单 (EventSource API)，服务器端相对简单（与 WebSockets 相比） 客户端和服务器端都相对复杂（需要处理握手、帧、状态等）
协议开销 每条消息开销相对 较低 (只包含数据和事件头) 每条消息开销相对 较高 (包含帧头等)
基础设施兼容性 对现有 HTTP 基础设施友好 (代理、防火墙、负载均衡) 可能需要 特殊配置 支持 WebSocket 协议
自动重连 内置 于 EventSource API，可控 需要 手动实现 或依赖库
适用场景 服务器 持续推送 数据，客户端 只接收 (通知、订阅数据、进度更新) 需要频繁的 双向 实时交互 (聊天、游戏、协同编辑)
HTTP/2 可利用 HTTP/2 多路复用 通常在自己的 TCP 连接上运行 (除非使用某些代理)
浏览器支持 现代浏览器普遍支持，IE 不支持，有 Polyfill 现代浏览器普遍支持，IE 也支持

总结选择建议：

  • 选择 SSE： 如果你的应用主要需求是服务器单向地向客户端推送事件或数据流，并且不需要客户端频繁地向服务器发送实时消息，同时希望实现简单、利用现有 HTTP 基础设施，那么 SSE 是一个非常好的选择。例如：新闻推送、股票报价、后台任务进度条、通知系统。
  • 选择 WebSockets： 如果你的应用需要客户端和服务器之间进行高频率、低延迟的双向实时通信，或者需要传输二进制数据，那么 WebSockets 是更合适的选择。例如：实时聊天室、多人在线游戏、实时协作工具。

有时候，一个复杂的应用可能会同时使用这两种技术：例如，使用 WebSockets 进行聊天消息的发送和接收，使用 SSE 来推送系统通知或朋友的在线状态更新。

第七部分：SSE 的典型应用场景

基于其特点，SSE 非常适合以下应用场景：

  1. 实时通知系统： 当后台发生某个事件（如订单完成、新评论、好友请求）时，服务器通过 SSE 向相关用户推送通知。
  2. 实时数据订阅： 例如，股票交易平台推送实时价格，体育应用推送实时比分，天气应用推送实时天气更新。
  3. 后台任务进度指示： 当用户在 Web 界面触发一个耗时任务（如文件上传/处理、数据导出、计算）时，服务器可以定期通过 SSE 发送任务的当前进度百分比。
  4. 实时日志输出： 对于开发者或运维人员，可以在 Web 界面上实时查看服务器端应用的日志输出。
  5. 消息队列消费者状态： 显示消息队列中待处理的消息数量、消费者状态等实时指标。
  6. 监控仪表盘： 推送系统指标（CPU 使用率、内存、网络流量等）的实时数据到监控仪表盘界面。
  7. 任何只需要服务器周期性或事件驱动地向客户端发送少量数据的场景。

第八部分：浏览器支持与 Polyfills

现代主流浏览器（Chrome, Firefox, Safari, Edge, Opera）都原生支持 EventSource API。

主要的例外是 Internet Explorer (IE)。IE 浏览器（包括 IE11）不原生支持 SSE。

如果你的应用需要支持 IE，你需要使用 polyfill 库来模拟 EventSource 的功能。有几个可用的 polyfill 项目，例如 eventSource.js。使用 polyfill 时，需要引入相应的 JavaScript 文件，它会在不支持 EventSource 的环境中创建一个兼容的实现。

“`html


“`

在使用 polyfill 时，需要注意其性能和兼容性可能不如原生实现，并且服务器端可能需要配合一些特定的 HTTP 头或行为来更好地支持 polyfill。

第九部分：高级考虑与挑战

虽然 SSE 在基础使用上非常简单，但在构建大规模或复杂的实时系统时，仍然需要考虑一些高级问题：

  • 服务器端的可伸缩性： 维持大量的持久连接会消耗服务器资源（内存、CPU、网络连接）。对于需要支持成千上万甚至更多的并发连接的应用，需要考虑服务器的架构设计，例如使用高性能的异步 I/O 框架、垂直或水平扩展服务器实例。
  • 负载均衡： 如果使用负载均衡器分发请求，需要确保客户端的 SSE 连接能够持续地连接到同一个服务器实例（ sticky sessions ），或者通过共享状态（如 Redis Pub/Sub）来确保任何一个服务器都能向连接在其上的客户端推送正确的事件。
  • 事件分发： 服务器如何有效地将事件广播给所有相关客户端？简单的实现可能是每个连接都监听所有事件，然后过滤。更高效的方式是利用 Pub/Sub 系统（如 Redis、Kafka、RabbitMQ）或专门的实时框架，服务器订阅相关频道，然后将收到的消息推送到对应的 SSE 连接。
  • 断线重连与数据一致性： 虽然 EventSource 提供了自动重连和 Last-Event-ID 机制，但服务器端利用 Last-Event-ID 来续传数据需要额外的逻辑实现。这涉及到如何存储和管理历史事件，以及如何根据 ID 查找并发送丢失的事件。
  • 安全性： SSE 连接与其他 HTTP 连接一样，可以通过 HTTPS 加密传输。对于需要用户认证的应用，可以在建立 SSE 连接的请求中包含认证信息（如 Cookies, Authorization 头），服务器端需要验证这些信息。

第十部分：结论

HTTP Server-Sent Events (SSE) 是一种强大而简洁的 Web 技术，为服务器单向推送数据到客户端提供了一种标准化的解决方案。它基于成熟的 HTTP 协议，客户端使用易于理解的 EventSource API，并内置了自动重连接机制。

与 WebSockets 相比，SSE 在需要双向通信的场景下显得不足，且仅支持文本数据。然而，对于许多只需要服务器向客户端推送实时数据的应用来说，SSE 提供了更高的实现简易性、更好的基础设施兼容性以及相对于轮询/长轮询更高的效率和更低的延迟。

理解 SSE 的工作原理、事件格式以及 EventSource API，可以帮助开发者在合适的场景下做出明智的技术选择。在构建通知系统、实时数据订阅、进度更新等功能时，SSE 往往是比 WebSockets 更轻量、更易于管理的方案。随着 Web 技术的不断发展，SSE 作为 HTTP 家族的一部分，将继续在特定领域发挥其独特的价值。

选择最适合你应用需求的技术始终是关键。如果你的应用侧重于服务器向客户端推送数据，并且不涉及大量的客户端到服务器的实时交互，那么 HTTP Server-Sent Events 绝对值得你深入了解和考虑使用。

发表评论

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

滚动至顶部