SSE连接中断后如何实现自动重连？

Question

在使用SSE（Server-Sent Events）实现服务端消息推送时，网络波动或服务重启常导致连接意外中断。尽管SSE原生支持自动重连机制（通过设置`retry`字段和浏览器默认行为），但在实际应用中，频繁的连接失败或未及时触发重连会导致消息丢失或长时间无响应。常见问题是：当连接中断后，浏览器虽会尝试重连，但若服务端未正确处理事件ID或客户端未监听`error`事件并手动重建连接，则可能陷入无法恢复的状态。如何在前端合理监听错误、控制重连间隔，并结合心跳机制判断真实连接状态，成为保障SSE稳定性的关键挑战。

Answer 1

一、SSE连接中断问题的背景与原生机制解析

Server-Sent Events（SSE）是一种基于HTTP的单向通信协议，允许服务端向客户端推送实时消息。其核心优势在于轻量级、文本流传输以及浏览器原生支持自动重连。当连接断开时，浏览器会根据服务端响应头中的retry字段设定的毫秒值进行重连尝试。

然而，在实际生产环境中，网络波动、服务重启或负载均衡切换等场景常导致连接异常中断。尽管SSE规范定义了自动重连机制，但该机制依赖于以下几个前提：

• 服务端正确发送retry:指令
• 客户端未主动关闭连接
• 连接中断后能收到有效的EOF或错误信号以触发重连逻辑

若服务端未维护事件ID（eventid），则在重连后无法恢复上次中断的位置，造成消息丢失。此外，部分浏览器在长时间无响应或TCP连接卡死时，并不会立即触发error事件，导致“假连接”状态持续存在。

二、常见故障模式与诊断路径

在长期运维中，我们总结出以下几类典型的SSE连接异常现象及其成因：

现象	可能原因	检测方式
连接中断后不再重连	未监听error事件	浏览器DevTools查看EventStream
重连频繁但失败	服务端5xx错误或CORS配置错误	检查Network面板状态码
消息丢失	未使用last-event-id恢复位置	日志比对事件序列号
连接看似正常但无数据	TCP半开连接或代理超时	结合心跳包判断
重连间隔过短引发雪崩	retry设置为低值且无退避策略	监控请求频率
跨域阻塞	响应头缺少Access-Control-Allow-Origin	审查Response Headers
内存泄漏	重复创建EventSource实例未销毁	Performance工具分析对象引用
服务端资源耗尽	并发连接数过高	服务器指标监控
SSL/TLS握手失败	证书过期或中间件拦截	抓包分析TLS过程
CDN缓存SSE流	未设置Cache-Control: no-cache	检查返回头缓存策略

三、前端容错设计：增强Error监听与重连控制

为提升SSE连接稳定性，前端需超越默认行为，实现精细化的错误处理和重连调度。关键在于捕获error事件并结合指数退避算法避免服务冲击。

const EVENT_SOURCE_URL = '/api/stream';
let eventSource = null;
let retryCount = 0;
const MAX_RETRY = 10;
const BASE_DELAY = 1000; // 初始延迟1秒
const MAX_DELAY = 30000; // 最大延迟30秒

function createEventSource() {
    if (eventSource) {
        eventSource.close();
    }

    eventSource = new EventSource(EVENT_SOURCE_URL);

    eventSource.onopen = () => {
        console.log('SSE connection opened');
        retryCount = 0; // 成功连接重置计数
    };

    eventSource.onmessage = (event) => {
        console.log('Received message:', event.data);
        // 处理业务逻辑
    };

    eventSource.onerror = (err) => {
        console.warn('SSE error occurred:', err);
        retryCount++;

        if (retryCount > MAX_RETRY) {
            console.error('Max retry attempts exceeded');
            return;
        }

        const delay = Math.min(BASE_DELAY * Math.pow(2, retryCount), MAX_DELAY);
        console.log(`Reconnecting in ${delay}ms...`);

        setTimeout(() => {
            createEventSource();
        }, delay);
    };
}

// 启动连接
createEventSource();
    

四、心跳机制与连接健康度检测

由于SSE是单向通道，客户端无法感知服务端是否仍在写入数据。引入心跳事件可有效识别“静默断连”状态。服务端应定期发送ping类型事件，客户端通过定时器监督最近一次心跳时间。

let lastHeartbeat = Date.now();
const HEARTBEAT_TIMEOUT = 60000; // 60秒未收到心跳视为断线
let heartbeatTimer = null;

function startHeartbeatCheck() {
    heartbeatTimer = setInterval(() => {
        const timeSinceLast = Date.now() - lastHeartbeat;
        if (timeSinceLast > HEARTBEAT_TIMEOUT) {
            console.warn('No heartbeat received, forcing reconnect');
            if (eventSource) {
                eventSource.close();
            }
            createEventSource(); // 强制重建
        }
    }, 15000); // 每15秒检查一次
}

// 在onmessage中处理心跳
eventSource.onmessage = (event) => {
    if (event.type === 'message') {
        try {
            const data = JSON.parse(event.data);
            if (data.type === 'heartbeat') {
                lastHeartbeat = Date.now();
                return;
            }
            // 正常业务消息处理
        } catch (e) {
            console.error('Parse error:', e);
        }
    }
};
    

五、服务端配合：事件ID管理与重连上下文恢复

为了实现消息不丢失，服务端必须为每条推送的消息分配唯一递增的事件ID，并在客户端重连时通过Last-Event-ID请求头获取断点位置。以下是Node.js Express示例：

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

    let lastId = req.headers['last-event-id'] || 0;
    let currentId = parseInt(lastId, 10);

    const interval = setInterval(() => {
        currentId++;
        res.write(`id: ${currentId}\n`);
        res.write(`data: ${JSON.stringify({ timestamp: Date.now(), value: Math.random() })}\n\n`);
    }, 2000);

    // 心跳保活
    const pingInterval = setInterval(() => {
        res.write('event: heartbeat\n');
        res.write(`data: {"type":"heartbeat","ts":${Date.now()}}\n\n`);
    }, 30000);

    req.on('close', () => {
        clearInterval(interval);
        clearInterval(pingInterval);
    });
});
    

六、架构级优化建议与流程图

对于高可用系统，仅靠客户端重试不足以保障SSE稳定性。建议结合以下架构实践：

• 使用反向代理（如Nginx）配置长连接超时策略
• 部署多实例并通过Redis广播事件，确保任意节点均可恢复上下文
• 前端封装SSE为可复用模块，支持动态启停与状态查询
• 加入埋点监控，统计连接成功率、平均重连次数等SLA指标

graph TD
    A[客户端发起SSE连接] --> B{连接成功?}
    B -- 是 --> C[监听onmessage/onerror]
    B -- 否 --> D[触发error事件]
    D --> E[启动指数退避重连]
    E --> F{达到最大重试?}
    F -- 否 --> G[延迟后重建EventSource]
    F -- 是 --> H[告警并停止重连]
    C --> I[接收消息]
    I --> J{是否为heartbeat?}
    J -- 是 --> K[更新lastHeartbeat时间]
    J -- 否 --> L[处理业务数据]
    M[定时检查lastHeartbeat] --> N{超过阈值?}
    N -- 是 --> D
    N -- 否 --> M