SSE(Server-Sent Events)的retry配置项的正确工作机制是什么？

核心归属 #

retry 是SSE协议中由服务端配置、客户端内置逻辑自动执行的参数，不需要前端额外写代码处理，浏览器原生的EventSource实现会自动识别该字段并更新配置。

工作逻辑 #

• 浏览器默认的SSE重连间隔是3秒：当SSE连接意外断开（网络波动、服务端超时、服务端重启等场景），客户端会自动每隔3秒尝试重新和服务端建立连接。
• 服务端可以在任意一次SSE消息（可以是单独的配置消息，也可以是和业务数据一起下发的消息）中携带retry字段，值为整数类型的毫秒数，客户端收到后会直接更新本地的重连间隔配置。
• 如果retry字段的值不是有效整数，客户端会直接忽略该配置，继续沿用之前的重连间隔。

典型的带retry配置的SSE消息格式如下：

retry: 5000
data: {"msg": "业务消息内容"}

上述消息下发后，后续客户端断开连接时会自动改为每5秒尝试重连一次。

适用场景 #

• 服务端限流/降级场景：当服务端遇到流量峰值需要主动断开部分非核心SSE连接，或者正在进行滚动重启时，可以提前下发retry: 10000甚至更长的间隔，避免大量客户端短时间内反复重试请求，进一步加剧服务端压力。
• 匹配业务实时性要求：对实时性要求高的业务（比如实时预警、实时订单推送），可以设置retry: 1000，断开后1秒就尝试重连，尽可能降低消息延迟；对实时性要求低的业务（比如每日统计通知、非即时公告推送），可以设置retry: 30000甚至更长，减少无效重连请求，降低资源消耗。
• 服务端维护场景：如果需要停机维护一段时间，可以提前给所有在线SSE连接下发对应时长的retry配置，维护期间客户端不会反复重试，维护结束后第一次重连即可成功，用户侧几乎不会感知到异常。

注意事项 #

retry参数只会影响连接断开后的自动重连间隔，不会对正常连接中的消息推送频率、消息处理逻辑产生任何影响。

内容的提问来源于stack exchange，提问作者WHITECOLOR