EventSource如何处理连接超时重连？

Question

在使用 EventSource 实现服务器发送事件（SSE）时，连接超时或网络中断后如何正确处理自动重连是一个常见问题。EventSource 内置了自动重连机制，默认在连接断开后会等待一段时间（通常为3秒）尝试重新连接。然而，在实际应用中，若服务器长时间无响应或网络异常，可能导致重连失败或资源浪费。开发者常困惑于如何自定义超时时间、监听重连事件以及避免频繁无效重试。此外，当服务端关闭连接或返回非200状态码时，EventSource 可能不会按预期重试。因此，如何通过监听 error 事件、合理设置重连间隔并判断重连状态，成为保障 SSE 连接稳定性的关键技术难点。

Answer 1

一、EventSource 基础机制与默认重连行为

EventSource 是浏览器原生支持的服务器发送事件（SSE）客户端接口，用于建立持久的 HTTP 连接，实现服务端向客户端的单向实时推送。其核心优势在于轻量级、基于文本、自动重连等特性。

当连接因网络中断或服务器关闭而断开时，EventSource 会自动尝试重新连接，默认重连间隔为 3000 毫秒（3 秒）。该值可通过服务端在消息中携带 retry: 字段进行设置：

data: Hello, client!
retry: 5000
id: 1
    

需要注意的是，这个 retry 指令仅影响后续的重连延迟，且只在合法的 SSE 响应流中生效。若服务端返回非 200 状态码（如 404、500），或响应头未设置 Content-Type: text/event-stream，则 EventSource 不会触发重连机制。

二、深入分析自动重连的触发条件与限制

EventSource 的自动重连并非无条件执行，其行为受多种因素制约。以下是常见场景下的重连逻辑：

• 网络临时中断（如 Wi-Fi 切换）：触发标准重连流程，使用上次设定的 retry 值。
• 服务端主动关闭连接：若关闭前未发送 retry，则使用默认 3 秒间隔。
• 首次请求失败（如 DNS 解析失败、CORS 错误）：不会重连，需开发者手动干预。
• 返回非 200 状态码：EventSource 将终止连接且不再重试，这是规范要求。

这一设计避免了对无效端点的无限轮询，但也带来了问题——开发者无法仅依赖内置机制应对所有异常情况。

三、监听 error 事件以掌握连接状态变化

为了精确控制重连逻辑，必须监听 error 事件。该事件在连接丢失、解析错误或收到非 200 响应时触发，但其语义模糊，需结合上下文判断原因。

const eventSource = new EventSource('/stream');

eventSource.onerror = function(event) {
    console.log('SSE Error:', event);
    // 注意：连接成功后的错误才会触发重连
};
    

关键点在于：onerror 在以下三种状态下行为不同：

连接状态	error 触发	是否自动重连
正在连接中（首次）	是	否
已连接并接收数据	是	是
重连尝试中失败	是
是（继续按间隔重试）

四、自定义重连策略：超越默认机制

由于 EventSource 不暴露当前重连状态和计数，开发者常采用“代理模式”封装实例，实现更智能的重试逻辑。

class ReliableEventSource {
    constructor(url, options = {}) {
        this.url = url;
        this.reconnectInterval = options.reconnectInterval || 3000;
        this.maxReconnectDelay = options.maxReconnectDelay || 30000;
        this.backoffFactor = options.backoffFactor || 1.5;
        this.currentDelay = this.reconnectInterval;
        this.eventSource = null;
        this.connect();
    }

    connect() {
        this.eventSource = new EventSource(this.url);

        this.eventSource.onopen = (e) => {
            console.log('SSE connected');
            this.currentDelay = this.reconnectInterval; // 重置退避
        };

        this.eventSource.onmessage = (e) => {
            console.log('Message:', e.data);
        };

        this.eventSource.onerror = (e) => {
            console.warn('SSE error, retrying in', this.currentDelay, 'ms');
            setTimeout(() => this.connect(), this.currentDelay);
            this.currentDelay = Math.min(
                this.currentDelay * this.backoffFactor,
                this.maxReconnectDelay
            );
        };
    }

    close() {
        if (this.eventSource) {
            this.eventSource.close();
        }
    }
}
    

上述实现引入指数退避（exponential backoff），有效防止在网络长时间不可达时造成频繁无效请求。

五、服务端协同控制：合理设置 retry 与状态码

客户端的稳定性离不开服务端的配合。服务端应在正常关闭流时发送 retry: 指令，并避免返回非 200 状态码中断重连。

示例 Node.js 服务端代码：

app.get('/stream', (req, res) => {
    res.writeHead(200, {
        'Content-Type': 'text/event-stream',
        'Cache-Control': 'no-cache',
        'Connection': 'keep-alive'
    });

    const interval = setInterval(() => {
        res.write(`data: ${JSON.stringify({ time: new Date() })}\n\n`);
    }, 1000);

    req.on('close', () => {
        clearInterval(interval);
        // 可选：不立即结束，等待下次重连
    });
});
    

注意：不要在每次响应末尾写入 retry:，除非需要动态调整客户端重连间隔。

六、高级监控与诊断：构建可观察性体系

对于生产环境，建议记录连接生命周期事件，便于排查问题。可结合日志上报与心跳检测。

graph TD A[创建 EventSource] --> B{连接成功?} B -- 是 --> C[监听 onmessage] B -- 否 --> D[记录初始化失败] C --> E[收到数据] E --> F{是否包含心跳?} F -- 否 --> G[标记连接异常] F -- 是 --> H[更新最后活跃时间] C --> I[onerror 触发] I --> J{是否已连接过?} J -- 是 --> K[启动重连定时器] J -- 否 --> L[记录首次连接失败] K --> M[指数退避重连] M --> A

通过此流程图可见，完整的重连管理涉及状态判断、退避策略、服务端协作等多个环节。

七、常见陷阱与最佳实践总结

在实际项目中，以下问题频繁出现：

1. 误以为 onerror 总能触发重连——实际上首次连接失败不会自动重试。
2. 服务端返回 503 后期望客户端重连——违反 SSE 规范，应保持 200 状态码。
3. 未处理重复消息——通过 id: 字段维护消息序号可解决。
4. 多个 EventSource 实例共存导致资源浪费——应使用单例或连接池管理。
5. 忽略浏览器兼容性——Safari 对 SSE 支持较弱，需降级方案。
6. 未设置超时限制——长连接可能被代理或防火墙中断。
7. 跨域问题导致连接失败——需正确配置 CORS 头部。
8. 内存泄漏——未在页面卸载时调用 close()。
9. 重连风暴——缺乏退避机制导致服务器压力激增。
10. 缺乏监控——无法定位连接中断的根本原因。

综上，构建高可用的 SSE 系统需从客户端、服务端、网络环境三方面综合考量。