HTTP Server-Sent Events (SSE) 完整指南 – wiki基地

作者： /

HTTP Server-Sent Events (SSE) 完整指南：构建高效的服务器到客户端实时通信

在现代 Web 应用中，实时或近乎实时的用户体验变得越来越重要。无论是股票报价、社交媒体通知、实时日志输出还是仪表盘更新，都需要服务器能够主动向客户端推送数据，而无需客户端反复请求。传统的 HTTP 请求/响应模型无法满足这种需求，因此出现了多种技术来弥补这一不足，如轮询、长轮询、WebSocket 以及本文将要深入探讨的 Server-Sent Events (SSE)。

Server-Sent Events (SSE) 是一种基于 HTTP 的技术，允许服务器通过持久化的 HTTP 连接向客户端推送数据。它提供了一种简单、高效的方式来实现服务器到客户端的单向数据流。与全双工的 WebSocket 不同，SSE 专注于服务器向客户端的推送，这使得它在许多只需要服务器向客户端发送更新的场景下成为一个更轻量级的选择。

本文将带你全面了解 SSE，包括其核心概念、工作原理、服务器端和客户端的实现细节、优缺点、适用场景以及与其它实时技术的对比。

第一部分：理解 SSE 的核心概念与工作原理

1. 什么是 Server-Sent Events (SSE)?

Server-Sent Events (SSE) 是一种 Web API，用于通过一个持久的 HTTP 连接从服务器向浏览器推送数据。它允许客户端订阅服务器上的“事件流”，并在有新数据可用时自动接收更新。SSE 是 W3C 标准的一部分，并且构建在标准的 HTTP 和 MIME 类型之上。

与传统的 HTTP 请求（客户端发起请求，服务器响应后连接关闭）不同，SSE 利用 HTTP/1.1 的 keep-alive 特性，在服务器发送响应后不立即关闭连接。服务器可以持续地向客户端发送数据，每次发送的数据被视为一个“事件”。

2. 工作原理

SSE 的工作原理相对简单：

  • 客户端发起连接： 客户端（通常是浏览器）使用 EventSource 对象发起一个标准的 HTTP GET 请求到服务器的特定 URL。
  • 服务器响应： 服务器收到请求后，不会像普通请求那样发送一个完整的响应然后关闭连接。取而代之的是，服务器设置特定的响应头 (Content-Type: text/event-stream)，然后保持连接开放。
  • 数据推送： 服务器通过这个开放的连接，按照特定的格式（SSE 事件格式）持续地向客户端发送数据块。
  • 客户端接收与处理： 客户端的 EventSource 对象监听这个连接。每当服务器发送一个完整的事件数据块时，EventSource 对象就会触发相应的事件（通常是 message 事件），并将数据传递给客户端的 JavaScript 代码进行处理。
  • 连接管理： 如果连接因为网络问题、服务器重启等原因中断，客户端的 EventSource 会尝试自动重新连接。服务器也可以通过在事件流中包含 retry 字段来建议客户端等待多久后重试。同时，服务器或客户端也可以主动关闭连接。

3. SSE 的关键特性

  • 基于 HTTP： SSE 完全建立在标准的 HTTP 协议之上，这使得它能够很好地与现有的 Web 基础设施（如代理服务器、防火墙）兼容。
  • 单向通信： 数据流是单向的，只能从服务器流向客户端。客户端向服务器发送数据仍需要使用传统的 HTTP 方法（如 POST、PUT）或其它机制。
  • text/event-stream MIME 类型： 服务器通过设置响应头的 Content-Type 为 text/event-stream 来告知客户端这是一个事件流。
  • 简单的文本协议： 事件数据以纯文本格式发送，每条数据记录由一系列以换行符 (\n) 分隔的行组成，最后以连续两个换行符 (\n\n) 表示一个事件的结束。
  • 内置的连接管理和重连机制： 客户端的 EventSource 对象自动处理连接中断和重试逻辑，极大地简化了客户端的开发。
  • 事件 ID： 服务器可以为每个事件分配一个唯一的 ID (id 字段)。客户端的 EventSource 会记住最后一个接收到的事件 ID，并在重连时发送给服务器（通过 Last-Event-ID 请求头），服务器可以据此判断从哪个事件开始继续发送数据，避免数据丢失。

第二部分：SSE 事件格式详解 (text/event-stream)

SSE 定义了一个简单的、基于行的纯文本协议来传输事件数据。每个事件由一个或多个字段组成，每个字段占据一行，格式为 字段名: 字段值。一个事件的所有字段后必须跟随一个空行 (\n) 或连续两个换行符 (\n\n) 来分隔不同的事件。

以下是 SSE 标准定义的四个标准字段：

  1. data:

    • 用途： 包含事件的数据负载。一个事件可以包含多行 data: 字段，它们将被连接起来，每行之间插入一个换行符，作为最终的数据传递给客户端。
    • 示例：
      data: 这是第一行数据
      data: 这是第二行数据
      data: {"key": "value"}
      客户端接收到的数据将是 "这是第一行数据\n这是第二行数据\n{\"key\": \"value\"}"。
    • 注意： 字段名 : 后面的空格是可选的，但建议保留以提高可读性。数据内容可以包含几乎任何文本，但其中的换行符会被特殊处理（如上所述）。

  2. event:

    • 用途： 指定事件的类型。如果指定了 event: 字段，客户端的 EventSource 将触发一个具有指定类型的事件，而不是默认的 message 事件。这允许服务器发送不同类别的事件，客户端可以针对不同类型的事件注册不同的处理函数。
    • 示例：
      event: user_joined
      data: {"userId": 123, "username": "Alice"}
      客户端可以监听 user_joined 事件。
    • 注意： 事件类型名称不能包含换行符。

  3. id:

    • 用途： 为事件设置一个唯一的标识符。客户端的 EventSource 对象会自动追踪接收到的最后一个事件的 ID。如果连接中断并重新建立，客户端会在新的请求头中发送 Last-Event-ID，其值为断开前收到的最后一个事件的 ID。服务器可以利用这个 ID 来恢复中断的事件流。

    • 示例：
      “`
      id: 1
      data: First update

      id: 2
      data: Second update
      “`
      * 注意： 事件 ID 可以是任何字符串，通常使用时间戳、序列号或 UUID。

  4. retry:

    • 用途： 指定客户端在连接断开后，应该等待多少毫秒后尝试重新连接。这是一个服务器向客户端发出的建议。如果服务器不发送此字段，客户端将使用浏览器默认的重试间隔（通常是几秒）。
    • 示例：
      retry: 10000
      data: This is a message.
      客户端将在断开后等待 10 秒（10000 毫秒）再尝试重连。
    • 注意： retry 的值必须是一个整数，表示毫秒数。

示例：一个完整的 SSE 事件流

以下是一个包含不同事件类型、ID 和 retry 字段的示例服务器发送的 SSE 流：

“`
: 这是注释行，以冒号开头
: 客户端会忽略注释行

retry: 5000
event: notification
id: 1678886400
data: New message received!

id: 1678886401
data: User “Bob” is online.

event: price_update
id: stock_ABC_1678886402
data: {“stock”: “ABC”, “price”: 150.25}

``
注意每个事件之间的空行 (\n\n)。注释行以冒号:` 开头，客户端会忽略它们。

第三部分：服务器端实现 SSE

实现 SSE 的服务器端需要完成以下几个关键任务：

  1. 设置正确的响应头： 必须设置 Content-Type: text/event-stream。同时，为了防止代理服务器或浏览器缓存事件流，建议设置 Cache-Control: no-cache 或 Cache-Control: no-store，以及 Connection: keep-alive（尽管这是 HTTP/1.1 的默认行为，显式设置更清晰）。
  2. 保持连接开放： 服务器不能在发送完数据后立即关闭连接。这通常意味着使用底层 HTTP 库提供的功能来维持连接。
  3. 格式化并发送事件数据： 按照 SSE 格式（字段名: 字段值\n，事件之间以 \n\n 分隔）将数据写入响应体。
  4. 刷新（Flush）缓冲区： 确保数据被立即发送到客户端，而不是在服务器的发送缓冲区中等待。这是非常关键的一步，否则客户端可能无法及时收到数据。
  5. 处理客户端连接和断开： 服务器需要知道哪些客户端连接是活跃的，并处理连接中断的情况。在一些应用中，服务器可能需要跟踪客户端的 Last-Event-ID 以便在重连时恢复数据。
  6. 发送心跳： 为了防止连接因为长时间没有数据传输而被中间代理或防火墙关闭，服务器应该定期发送心跳信息。心跳可以是一个空的事件（只包含 \n\n）或一个注释行（: some comment\n\n）。

以下是几种常见服务器端技术的实现思路或简化示例：

1. Node.js / Express

Node.js 的非阻塞 I/O 特性非常适合处理大量持久连接。

“`javascript
const express = require(‘express’);
const app = express();
const cors = require(‘cors’); // 处理跨域

app.use(cors()); // 允许所有来源，实际应用中应限制

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

// 处理新的 SSE 连接请求
app.get(‘/events’, (req, res) => {
// 1. 设置响应头
res.setHeader(‘Content-Type’, ‘text/event-stream’);
res.setHeader(‘Cache-Control’, ‘no-cache’);
res.setHeader(‘Connection’, ‘keep-alive’);

// 可选：支持断线重连时恢复
const lastEventId = req.headers['last-event-id'];
if (lastEventId) {
    console.log(`Client wants to resume from ID: ${lastEventId}`);
    // 在实际应用中，这里需要根据 lastEventId 从存储中查找并发送丢失的事件
}

// 2. 保持连接开放并存储响应对象
clients.push(res);
console.log(`Client connected. Total clients: ${clients.length}`);

// 3. 发送初始数据或心跳 (可选)
// res.write('retry: 5000\n\n'); // 建议客户端等待5秒重连
// res.write('data: Connection established\n\n');
// res.flush(); // 刷新缓冲区，确保数据立即发送

// 4. 处理客户端断开连接
req.on('close', () => {
    clients = clients.filter(client => client !== res);
    console.log(`Client disconnected. Total clients: ${clients.length}`);
    res.end(); // 确保连接完全关闭
});

});

// 模拟一个定时发送事件的函数
setInterval(() => {
const now = new Date().toISOString();
const eventId = Date.now();
const data = data: Server time is ${now}\nid: ${eventId}\n\n;

// 遍历所有连接的客户端，发送数据
clients.forEach(client => {
    try {
        client.write(data);
        // 刷新缓冲区
        if (typeof client.flush === 'function') {
             client.flush();
        } else {
            // 对于某些旧版本的Node或http模块，可能需要其他方式或flush不可用
            // 但Express通常会自动处理或通过底层库实现
        }
    } catch (error) {
        console.error('Error writing to client:', error);
        // 如果写入失败，可能是客户端已断开，可以从 clients 列表中移除
        // clients = clients.filter(c => c !== client); // 更健壮的断开处理应在req.on('close')中
    }
});
console.log(`Sent time update to ${clients.length} clients.`);

}, 5000); // 每5秒发送一次更新

// 示例：另一个触发事件的路由 (例如：有新消息时调用此路由)
app.post(‘/send-message’, express.json(), (req, res) => {
const message = req.body.message || ‘Default message’;
const eventId = Date.now();
const data = event: new_message\ndata: ${JSON.stringify({ message })}\nid: ${eventId}\n\n;

 clients.forEach(client => {
    try {
        client.write(data);
        if (typeof client.flush === 'function') client.flush();
    } catch (error) {
         console.error('Error sending message to client:', error);
    }
});

res.status(200).send('Message sent to SSE clients.');

});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
console.log(SSE server listening on port ${PORT});
});
“`
这个示例展示了如何设置头、存储客户端连接以及定时发送数据。在实际应用中，你需要更复杂的逻辑来管理客户端连接、广播数据和处理错误。

2. Python / Flask

Flask 使用 Werkzeug 作为底层 WSGI 工具集，可以方便地实现流式响应。

“`python
from flask import Flask, Response, request, jsonify
import time
import json
import queue
import threading

app = Flask(name)

使用一个字典来存储每个客户端的队列

更好的做法是维护一个全局广播列表或使用消息队列系统 (如 Redis Pub/Sub)

clients = {}
client_lock = threading.Lock() # 保护 clients 字典的访问

模拟向所有连接的客户端发送事件

def send_message_to_clients(event_data):
with client_lock:
# 清理已断开的客户端
disconnected_clients = []
for client_id, q in clients.items():
try:
q.put(event_data)
# 简单的检查队列是否活跃，更可靠的方法是在连接中断时移除
# if q.empty() and client_id not in request.sid: # 仅为示例，request.sid 不适用于SSE
# disconnected_clients.append(client_id)
except Exception as e:
print(f”Error sending to client {client_id}: {e}”)
disconnected_clients.append(client_id) # 假设发送异常表示断开

    for client_id in disconnected_clients:
        if client_id in clients:
             print(f"Removing disconnected client {client_id}")
             del clients[client_id]

定时发送心跳或数据更新

def sse_heartbeat():
while True:
time.sleep(5) # 每5秒发送一次
event_id = int(time.time() * 1000)
data_payload = {“message”: f”Heartbeat at {time.ctime()}”}
event_data = f”id: {event_id}\ndata: {json.dumps(data_payload)}\n\n”
send_message_to_clients(event_data)
print(f”Sent heartbeat to {len(clients)} clients”)

启动心跳线程

heartbeat_thread = threading.Thread(target=sse_heartbeat, daemon=True)
heartbeat_thread.start()

@app.route(‘/events’)
def sse_events():
# 生成一个唯一的客户端ID，这里使用时间戳，实际应用中可以使用 UUID
client_id = str(int(time.time() * 1000000)) + “_” + str(threading.current_thread().ident)
print(f”New client connected: {client_id}”)

# 创建一个队列用于存储待发送给该客户端的事件
event_queue = queue.Queue()
with client_lock:
    clients[client_id] = event_queue

# 处理断开连接
def client_disconnect():
    print(f"Client disconnected: {client_id}")
    with client_lock:
        if client_id in clients:
            del clients[client_id]

request.environ['wsgi.websocket.handler'].on_close = client_disconnect # Werkzeug/Flask 特有，处理连接关闭

# 获取 Last-Event-ID 以支持断线重连
last_event_id = request.headers.get('Last-Event-ID')
if last_event_id:
    print(f"Client {client_id} wants to resume from ID: {last_event_id}")
    # 在实际应用中，根据 last_event_id 从存储中加载并推送丢失的事件

def generate():
    # 发送初始信息或 retry 间隔 (可选)
    # yield 'retry: 5000\n\n' # 建议客户端等待5秒重连

    while True:
        try:
            # 从队列中获取事件数据
            event_data = event_queue.get()
            yield event_data
            # Flask 的 Response 对象通常会处理 flush，但也可能依赖于 WSGI 服务器

        except queue.Empty:
             # 队列为空，短暂等待
             time.sleep(0.1)
        except GeneratorExit:
            # 客户端断开时会触发 GeneratorExit
            client_disconnect()
            return
        except Exception as e:
            print(f"Error in generate for client {client_id}: {e}")
            client_disconnect()
            return

# 设置响应头并返回流式响应
return Response(generate(), mimetype='text/event-stream')

示例：一个触发事件的路由

@app.route(‘/trigger_event’, methods=[‘POST’])
def trigger_event():
message = request.json.get(‘message’, ‘Manual trigger’)
event_type = request.json.get(‘event’, ‘manual’)
event_id = int(time.time() * 1000)
data_payload = {“status”: message}
event_data = f”event: {event_type}\nid: {event_id}\ndata: {json.dumps(data_payload)}\n\n”
send_message_to_clients(event_data)
return jsonify({“status”: “Event triggered”})

if name == ‘main‘:
# 使用一个支持流的 WSGI 服务器，如 Waitress 或 Gunicorn
# 例如： waitress-serve –listen=*:5000 your_module:app
# app.run(debug=True) # Flask 自带的开发服务器对流支持可能不完美，生产环境不推荐
print(“Starting Flask SSE server. Use a production WSGI server like Waitress or Gunicorn.”)
# 简单的运行方式 (可能不支持大并发或完美流)
# app.run(port=5000) # 请在生产环境使用 WSGI server
from waitress import serve
print(“Running with Waitress…”)
serve(app, host=’0.0.0.0’, port=5000)

``
这个 Flask 示例使用队列来向每个客户端发送数据，并在单独的线程中处理定时任务。Response(generate(), mimetype=’text/event-stream’)` 创建一个流式响应。注意生产环境需要使用支持流的 WSGI 服务器（如 Waitress, Gunicorn + eventlet/gevent worker）。

总结服务器端实现要点：

  • 设置正确的 Content-Type, Cache-Control, Connection 响应头。
  • 使用服务器框架或库提供的流式响应或保持连接的功能。
  • 定期将 SSE 格式的数据块写入响应体。
  • 务必刷新缓冲区，将数据立即发送出去。
  • 实现客户端连接的管理，以便向所有（或特定的）连接广播数据。
  • 考虑实现基于 Last-Event-ID 的断线重连数据恢复逻辑。
  • 发送心跳以维持连接。

第四部分：客户端实现 SSE

客户端实现 SSE 主要依赖于浏览器原生的 EventSource API。这个 API 极其简单易用。

1. EventSource 构造函数

javascript
const eventSource = new EventSource(url);
创建一个新的 EventSource 实例，连接到指定的 URL。这个 URL 就是服务器端处理 SSE 请求的端点。

2. 事件监听

EventSource 实例是一个事件目标，你可以通过 addEventListener 或直接设置 on 属性来监听不同的事件。

  • message 事件： 接收没有指定 event: 字段的普通消息。
    javascript
    eventSource.onmessage = function(event) {
    console.log("Received message:", event.data); // event.data 是服务器发送的数据
    console.log("Event ID:", event.lastEventId); // event.lastEventId 是事件ID
    };
    // 或者
    eventSource.addEventListener('message', function(event) {
    console.log("Received message:", event.data);
    console.log("Event ID:", event.lastEventId);
    });

  • 自定义事件： 接收服务器通过 event: 字段指定的特定类型事件。
    “`javascript
    eventSource.addEventListener(‘notification’, function(event) {
    console.log(“Received notification:”, event.data);
    console.log(“Event ID:”, event.lastEventId);
    // event.data 通常是JSON字符串，需要解析
    const notificationData = JSON.parse(event.data);
    console.log(“Notification:”, notificationData.message);
    });

    eventSource.addEventListener(‘price_update’, function(event) {
    console.log(“Received price update:”, event.data);
    const priceData = JSON.parse(event.data);
    console.log(Stock ${priceData.stock} price: ${priceData.price});
    });
    “`

  • open 事件： 当连接成功建立时触发。
    javascript
    eventSource.onopen = function(event) {
    console.log("SSE connection opened.");
    };

  • error 事件： 当发生错误（如连接失败、断开）时触发。EventSource 会在触发 error 事件后尝试根据服务器的 retry 设置或默认间隔进行重连。
    javascript
    eventSource.onerror = function(event) {
    console.error("SSE error occurred:", event);
    if (eventSource.readyState === EventSource.CLOSED) {
    console.log("Connection was closed.");
    }
    // EventSource 会自动尝试重连，除非代码显式关闭它
    };

3. EventSource 状态

eventSource.readyState 属性表示连接的当前状态：

  • EventSource.CONNECTING (0): 正在连接或重连。
  • EventSource.OPEN (1): 连接已打开，可以接收数据。
  • EventSource.CLOSED (2): 连接已关闭。

4. 关闭连接

客户端可以通过调用 eventSource.close() 方法来主动关闭 SSE 连接。
javascript
eventSource.close();
console.log("SSE connection closed by client.");
调用 close() 后，EventSource 将不再尝试重连。

5. lastEventId

eventSource.lastEventId 属性存储了最后一个接收到的事件的 ID (id: 字段的值)。在连接断开后，EventSource 会自动将这个值作为 Last-Event-ID 请求头发送给服务器，以便服务器知道从哪里继续发送数据。

客户端实现示例 (HTML + JavaScript)

“`html




SSE Client Example


SSE Client Example

Connecting…



``
这个客户端示例展示了如何创建EventSource对象，监听不同类型的事件（open,message,error以及自定义事件），并将收到的数据显示在页面上。它依赖于EventSource` 内置的重连机制。

第五部分：SSE 的优势与劣势

优势：

  1. 简单易用： SSE 基于标准的 HTTP 和简单的文本协议，客户端有原生的 EventSource API，服务器端实现也比 WebSocket 简单得多（特别是对于只需要单向通信的应用）。
  2. 基于 HTTP： 兼容性好，能够天然地通过现有的 HTTP infrastructure (代理服务器、防火墙) 工作，无需特殊的端口或协议处理。
  3. 内置的连接管理与重连： EventSource API 自动处理连接断开的检测和重试逻辑，包括使用 Last-Event-ID 恢复数据流，这极大地减轻了开发负担。
  4. 针对文本优化： SSE 专为发送文本数据而设计，格式简单明了。对于主要发送文本更新的场景，它的开销可能比 WebSocket 更低。
  5. 带宽效率： 相较于轮询和长轮询，SSE 通过一个持久连接持续接收数据，避免了重复的 HTTP 请求和响应头开销，更加高效。
  6. 多播/广播友好： 服务器端可以很容易地维护一个客户端连接列表，并将同一条消息广播给所有（或部分）连接，实现多播效果。

劣势：

  1. 单向通信： SSE 只能用于服务器到客户端的数据推送。如果需要客户端向服务器发送实时数据（例如聊天应用中客户端发送消息），则需要结合其他技术（如传统的 AJAX 请求或 WebSocket）。
  2. 浏览器连接限制： 浏览器通常限制了单个域名下同时进行的 HTTP 连接数量（如 Chrome 和 Firefox 大约是 6-8 个）。由于 SSE 使用持久连接，可能会占用这些连接数，影响同一页面加载其他资源。虽然对于大多数单页应用问题不大，但在某些复杂场景下需要考虑。
  3. 缺乏对二进制数据的原生支持： SSE 协议是基于文本的。虽然可以通过 Base64 等编码方式传输二进制数据，但这不是其设计的初衷，效率和便捷性不如 WebSocket。
  4. 浏览器兼容性： 现代浏览器（Chrome, Firefox, Safari, Edge, Opera）都支持 EventSource。但 Internet Explorer (IE) 不支持 SSE。如果需要兼容 IE，则需要使用 Polyfill 或选择其他技术。对于只针对现代浏览器或移动应用的场景，这通常不是问题。
  5. HTTP/2 的影响： 在 HTTP/2 中，多个请求和响应可以在同一个 TCP 连接上复用。这使得传统的 HTTP 请求/响应模型在某些方面变得更高效。然而，SSE 仍然提供了一种更简单的“流”的概念和内置的客户端 API，对于事件流的场景仍有优势。

第六部分：SSE 与其它实时技术的对比

理解 SSE 的最佳方式之一是将其与用于类似目的的其他技术进行比较。

  1. 轮询 (Polling)

    • 原理： 客户端定时（例如每隔几秒）向服务器发起请求，询问是否有新的数据。
    • 优缺点：
      • 优点： 实现简单，兼容所有浏览器和服务器。
      • 缺点： 效率低（无论是否有新数据都会发起请求），延迟较高（取决于轮询间隔），服务器和客户端都有较高的开销（重复的连接建立和拆除）。
    • 与 SSE 对比： SSE 在有数据时立即推送，效率远高于轮询，延迟更低。SSE 使用一个持久连接，减少了连接建立/拆除的开销。

  2. 长轮询 (Long Polling)

    • 原理： 客户端向服务器发起请求，服务器收到请求后如果当前没有新数据，则保持连接不关闭，直到有新数据到来或达到超时时间，然后发送响应并关闭连接。客户端收到响应后立即发起新的长轮询请求。
    • 优缺点：
      • 优点： 比轮询效率高，延迟相对较低（有新数据时能及时推送）。
      • 缺点： 实现比轮询复杂，服务器需要维护大量处于挂起状态的连接，消耗资源；每次推送后连接都会断开，需要重新建立连接，仍有一定的开销和延迟。
    • 与 SSE 对比： SSE 使用一个真正的持久连接，数据持续推送，无需重复建立连接，开销更低。SSE 的内置重连和事件 ID 机制比长轮询更健壮。

  3. WebSocket

    • 原理： 通过一个 HTTP 握手过程升级到 WebSocket 协议，建立一个全双工（客户端和服务器都可以独立发送和接收数据）的持久化连接。
    • 优缺点：
      • 优点： 全双工通信，支持文本和二进制数据，协议开销小（一旦连接建立），延迟极低，适合需要客户端和服务器频繁双向交互的场景（如在线游戏、实时协作应用）。
      • 缺点： 实现比 SSE 复杂（需要处理握手、帧协议、连接状态等），需要专门的 WebSocket 服务器或库支持，基于独立的协议（ws:// 或 wss://），可能受到一些严格的防火墙限制（尽管大多数也允许）。
    • 与 SSE 对比： SSE 是单向的，WebSocket 是双向的。如果你的应用只需要服务器向客户端推送数据，SSE 通常是更简单、更轻量级的选择，并且天然集成在 HTTP/1.1 中，兼容性更好。如果需要双向通信或传输大量二进制数据，WebSocket 是更合适的选择。

对比总结表：

特性/技术 轮询 长轮询 Server-Sent Events (SSE) WebSocket
通信方向 单向 (拉取) 单向 (拉取，挂起) 单向 (推送) 全双工 (双向)
连接方式 短连接 (频繁) 短连接 (有数据或超时) 长连接 (持久) 长连接 (持久)
基于协议 HTTP/1.1 或 HTTP/2 HTTP/1.1 或 HTTP/2 HTTP/1.1 或 HTTP/2 WebSocket (升级自 HTTP)
数据格式 任何 (取决于请求) 任何 (取决于请求) 文本 (text/event-stream) 文本或二进制
实现复杂度 简单 中等 客户端简单，服务器中等 客户端中等，服务器复杂
延迟 高 (取决于轮询间隔) 中等 (取决于数据到达) 低 (有数据立即推送) 极低
服务器资源 高 (连接/断开开销) 高 (维持挂起连接) 中等 (维持少量长连接) 中等 (维持少量长连接)
浏览器 API XMLHttpRequest/Fetch XMLHttpRequest/Fetch EventSource WebSocket
自动重连 客户端需手动实现 客户端需手动实现 内置支持 客户端需手动实现
事件 ID N/A N/A 内置支持 客户端需手动实现
兼容性 所有浏览器 所有浏览器 现代浏览器支持 (IE 不支持) 现代浏览器支持

何时选择 SSE?

  • 你的应用主要需求是服务器向客户端推送数据（例如：通知、实时更新）。
  • 你不需要客户端向服务器发送大量实时消息。
  • 你希望利用现有的 HTTP 基础设施，简化部署和兼容性问题。
  • 你想要一个比轮询/长轮询效率更高、延迟更低的方案。
  • 你优先考虑客户端实现的简单性，利用浏览器原生的 EventSource API。

第七部分：SSE 的常见用例

SSE 非常适合以下场景：

  • 实时通知： 当用户的某些状态发生变化（例如：收到新消息、订单状态更新、有新的关注者）时，服务器主动通知客户端。
  • 实时数据流： 股票价格、天气预报、体育比赛得分等持续变化的数据需要实时推送给用户。
  • 仪表盘更新： 运维监控、业务数据统计等仪表盘需要显示最新的指标数据。
  • 日志和构建输出： 在线编译、代码部署、系统日志等过程的实时输出流可以轻松通过 SSE 推送到浏览器。
  • 排队系统： 用户提交一个耗时任务后，服务器可以通过 SSE 告知用户任务的当前进度或完成状态。
  • 多用户协作状态： 在线文档编辑中，告知用户其他用户正在查看或编辑的区域（尽管编辑内容本身可能需要 WebSocket）。

第八部分：高级主题与注意事项

  1. 安全性 (CORS 和认证)

    • CORS: 如果你的客户端和服务器部署在不同的域名、端口或协议下，需要处理跨域问题。由于 SSE 是基于 HTTP 的，标准的 CORS 机制（服务器端设置 Access-Control-Allow-Origin 等响应头）同样适用。EventSource 会遵循 CORS 规则。
    • 认证： SSE 连接是标准 HTTP 请求发起的，因此可以利用现有的 HTTP 认证机制，如 Cookie 或 HTTP Basic/Digest 认证。客户端的 EventSource 对象会携带浏览器为该域名存储的 Cookie。
    • Token 认证： 如果使用基于 Token (如 JWT) 的认证，可以在建立 EventSource 连接的 URL 中包含 Token 作为查询参数（例如 /events?token=...）。服务器端验证 Token 的有效性。

  2. 服务器端连接管理与状态

    • 在需要向特定用户或用户组发送数据时，服务器需要维护一个活跃连接与用户 ID 的映射关系。
    • 广播消息相对简单，只需遍历所有连接发送即可。
    • 处理服务器端的状态变化并触发相应的 SSE 事件。

  3. 扩展性

    • 单个服务器实例能够处理的 SSE 连接数量受到其资源（内存、CPU、文件描述符限制）和操作系统、服务器软件性能的影响。
    • 对于需要处理大量并发连接的应用，需要考虑水平扩展。在分布式系统中，如何有效地向所有服务器上的相关客户端广播消息是一个挑战。通常需要引入消息队列系统（如 Redis Pub/Sub, Kafka, RabbitMQ）作为消息总线，不同的服务器实例都连接到消息总线，接收消息后再转发给各自维护的客户端连接。

  4. 心跳机制

    • 为了防止长时间没有数据传输导致连接被中间代理或防火墙断开，服务器应该定期发送心跳包。心跳包可以是简单的注释行（以冒号 : 开头）或没有 data: 字段的空事件。客户端的 EventSource 收到心跳不会触发任何事件（除非是特殊的实现），但能保持连接活跃。

  5. 优雅关闭

    • 服务器在关闭或重启时，应该尝试向所有连接的客户端发送一个特殊的事件（例如 event: end\ndata: Server is shutting down\n\n），并在发送后关闭连接。客户端接收到这个事件后，可以决定不再重试连接。

  6. 带宽消耗

    • 虽然比轮询高效，但 SSE 仍是基于 HTTP 的，每个事件包含字段名和换行符，相比 WebSocket 的二进制帧协议，对于相同的数据量，SSE 的协议开销略大（特别是数据很小且频繁时）。但对于文本数据，这个差异通常可以忽略不计。

结论

HTTP Server-Sent Events (SSE) 提供了一种简单、高效且基于标准 HTTP 的方式来实现服务器到客户端的单向数据推送。凭借其原生的 EventSource API、内置的连接管理和重连机制，SSE 在许多实时应用场景中（特别是只需要服务器向客户端发送更新的场景）是一个极具吸引力的选择。

虽然它不像 WebSocket 那样提供全双工通信或原生支持二进制数据，但在实时通知、数据流展示、日志输出等场景下，SSE 的简单性、对现有 HTTP 基础设施的友好性以及强大的客户端 API 优势使其成为一个优秀的解决方案。

在选择实时技术时，重要的是根据你的具体需求权衡 SSE、WebSocket、长轮询和轮询的优缺点。如果你的应用场景与 SSE 的优势高度契合，那么它无疑能为你提供一个高效且易于实现的实时通信方案。掌握 SSE，将能助你更好地构建现代化的实时 Web 应用。

发表评论

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

滚动至顶部