SSE服务器推送常见技术问题：如何实现断线重连？

Question

在使用SSE（Server-Sent Events）实现服务器推送时，如何实现断线重连是一个常见且关键的技术问题。由于SSE基于HTTP长连接，网络波动或服务器异常可能导致连接中断。若未妥善处理，客户端将无法自动恢复接收事件，影响实时性与用户体验。通常需结合事件监听、重连机制设计、连接标识与消息断点续传等策略，确保连接断开后能自动、安全、有效地重新建立连接并恢复数据流。如何在客户端和服务端协同实现稳定、可控的重连机制，成为SSE应用开发中的核心技术难点。

Answer 1

一、SSE 断线重连机制概述

Server-Sent Events（SSE）是一种基于 HTTP 的服务器向客户端推送事件的协议，广泛应用于实时数据更新场景，如股票行情、聊天通知等。SSE 的核心特性是单向通信、自动重连机制以及基于文本的数据流传输。

然而，由于其依赖 HTTP 长连接，网络波动、服务宕机、超时等问题可能导致连接中断。因此，在客户端和服务端协同实现稳定、可控的断线重连机制，是保障 SSE 应用连续性和实时性的关键技术。

二、客户端断线重连机制设计

浏览器内置的 EventSource 对象已经支持基本的自动重连机制，默认会在连接中断后尝试重新连接。

• 默认重连时间间隔为 3 秒
• 可通过服务端返回的 retry 字段自定义重试间隔
• 客户端可监听 error 事件进行额外处理

1. 基础客户端代码示例

const eventSource = new EventSource('https://example.com/stream');

eventSource.addEventListener('message', event => {
  console.log('Received message:', event.data);
});

eventSource.addEventListener('error', error => {
  console.error('SSE error:', error);
});
  

2. 自定义重连逻辑

若需更精细控制重连行为，可封装 EventSource 实例，结合指数退避算法实现更健壮的重连策略。

let retryCount = 0;
const maxRetries = 5;

function connect() {
  const es = new EventSource('https://example.com/stream');

  es.addEventListener('message', event => {
    console.log('Message:', event.data);
    retryCount = 0; // 重置重试计数
  });

  es.addEventListener('error', () => {
    if (retryCount < maxRetries) {
      setTimeout(() => {
        retryCount++;
        connect();
      }, Math.pow(2, retryCount) * 1000); // 指数退避
    } else {
      console.error('Max retries reached.');
    }
  });
}
  

三、服务端配合实现断点续传与连接标识

客户端断线重连后，可能错过部分事件数据。为实现消息的“断点续传”，服务端需具备以下能力：

1. 维护每个客户端的唯一连接标识（如 session ID 或 user ID）
2. 记录事件流的偏移位置（offset）或时间戳（timestamp）
3. 支持通过 Last-Event-ID 请求头恢复事件流

1. 利用 Last-Event-ID 实现消息续传

当连接中断后，客户端在重连请求头中携带上次接收到的事件 ID，服务端根据该 ID 继续发送后续事件。

// 客户端自动发送 Last-Event-ID 请求头
// 服务端读取该头信息并定位事件流位置
app.get('/stream', (req, res) => {
  const lastEventId = req.headers['last-event-id'];
  const offset = getLastOffset(lastEventId);
  sendEventsFromOffset(res, offset);
});
  

2. 消息持久化与事件存储

为支持断点续传，服务端需将事件流持久化存储，如使用 Redis 缓存最近事件或写入数据库。

存储方式	优点	缺点
Redis	高性能、支持过期策略	内存有限、数据易失
数据库	持久化、容量大	性能较低、需索引优化

四、重连流程与状态管理

为实现稳定可控的重连机制，需设计完整的连接状态管理流程。

    
mermaid
graph TD
A[建立连接] --> B[接收事件]
B --> C{连接中断?}
C -->|是| D[触发重连]
D --> E[等待重试间隔]
E --> F[重新建立连接]
F --> G[发送Last-Event-ID]
G --> H[服务端恢复事件流]
H --> B
C -->|否| B
    
  

五、安全与连接控制

在重连过程中，还需考虑以下安全与控制机制：

• 身份认证与授权：确保每次连接的合法性
• 连接频率限制：防止恶意重连攻击
• 连接超时机制：避免无效连接占用资源
• 日志记录与监控：追踪连接状态与异常情况

1. 服务端限制连接频率示例

// 使用 Redis 记录客户端连接频率
const rateLimiter = (req, res, next) => {
  const clientId = getClientId(req);
  const key = `sse:rate_limit:${clientId}`;
  redis.get(key, (err, count) => {
    if (count > 5) {
      return res.status(429).send('Too many requests');
    }
    redis.incr(key, () => {
      redis.expire(key, 60); // 1分钟限制
      next();
    });
  });
};