短线重连：网络抖动下的快速恢复策略

1. 先搞清楚短线重连到底在解决哪种断线1.1 短线断连的典型场景做过网络编程的同学大概率都遇到过这么个场景客户端连着服务器一切正常。结果某天网络只是抖动了三五秒——比如手机从 Wi-Fi 切到 4G、家里路由器临时重启、办公网闸道更新策略、云主机做无损升级导致连接被负载均衡回收——然后客户端和服务端之间的连接就断了。这种断连有一个共同特征断线时间极短通常不超过几十秒网络本身是健康的只是连接通道被中间环节打断。它不是服务器宕机也不是客户端长时间离线更不是账号被踢。如果我们兴师动众地走一遍清空状态、重新登录、重新拉全量数据的流程用户会明显感到卡顿部分实时业务比如 IM、行情推送、设备指令下发还会因为恢复太慢导致一连串的连锁问题。短线重连要解决的就是这样一个被很多人当作小题大做、实际却极其影响体验的问题当一次短促的、非致命的连接中断发生时客户端能够在用户几乎无感知的情况下自动把连接恢复到可用状态。1.2 短线重连与全量重建会话的本质区别很多早期客户端的写法是检测到断线 - 清空内存里的连接状态跳回登录页或者调用登录接口重新拿 token重新订阅所有业务主题把服务端全量数据重新拉一遍这个流程如果用两个字概括就是重建。它的问题是把一次网络抖动放大成了一整场事故。短线重连要做的恰恰相反它追求的是复用与补偿复用原有的会话凭据、保留已确认的消息游标、只补拉断线期间漏掉的数据而不是把所有东西推倒重来。这背后的代价权衡非常关键。一次短线重连如果设计得好客户端代码里甚至不需要有一个明显的loading状态但如果设计成全部重建你至少要多承担三部分开销重新鉴权的时间重新建立业务上下文的 CPU/网络开销全量数据拉取带来的带宽和流量费用所以判断一个重连逻辑是不是短线重连其实有个很朴素的标准**恢复连接的成本是否和断线时长成正比。**如果断线 3 秒恢复动作只需要 1 次 TCP 握手 1 次增量同步那这是短线重连如果断线 3 秒恢复动作需要重新登录 全量拉取那这只能算重连外壳重建内核。1.3 一个简单的时序模型我自己在实现短线重连时脑子里会先画一条时间线t0 网络抖动发生连接断开底层 socket 产生 close 事件 t0.2 客户端捕获到断线进入退避等待阶段不立即重连 t1.2 退避结束发起新的 TCP/WebSocket 连接 t1.4 连接建立成功服务端下发断线期间的增量消息 t1.5 客户端补拉完毕恢复实时订阅这条时间线里从 close 到恢复的时间段就是短线重连的核心性能指标。如果这个时间能控制在 3 秒以内绝大多数用户根本感知不到发生过断线如果超过 10 秒用户就会开始抱怨消息收不到页面卡死。后面所有章节讲的退避策略、状态机、心跳配合、消息补偿本质上都是在优化这条时间线里的各个节点。2. 重连策略设计指数退避、抖动和上限2.1 固定间隔为什么不行刚入行的时候很多人写重连就是function reconnect() { setTimeout(connect, 3000); }固定 3 秒重试一次。这个写法在 demo 里没问题但放到真实环境里会有两个非常明显的问题。第一个问题是网络抖动场景下的无效重试。假设断线的根因是路由器切换需要 5 秒才能恢复。固定 3 秒重试意味着第 1 次重连必然失败紧接着第 2 次重试又是在网络还差着 1 秒的情况下发起。这种情况下客户端在恢复之前反复做无用功每次失败还会带来额外的 DNS 查询、TCP 握手、日志上报等于把一次抖动放大了好几倍。第二个问题是恢复后反应太慢。如果断线发生的根因只持续了 1 秒固定 3 秒的等待其实还算合理但如果你的业务要求高实时性比如交易行情、协同编辑哪怕只多了 2 秒用户都能感觉到卡了一下。固定间隔最大的问题在于它完全不区分故障的持续时间。而现实中的网络故障有一个经验规律**大多数断线是短时的越重试越接近恢复少部分断线是长期的越重试越需要克制。**因此重试间隔应该随着失败次数增加而增长这就是指数退避的核心思想。2.2 指数退避 全抖动的计算方法业界常用的方案是指数退避 抖动。在同一点上我推荐直接用公式delay min(cap, base * (2 ** attempt)) * random(0.5, 1.5)其中base是基础间隔attempt是连续失败的次数成功重连后归零cap是最大间隔上限。random(0.5, 1.5)是抖动系数也可以写成更复杂的 Full Jitter 算法但实际用下来这个简版已经足够。举个例子假设base 1scap 30s前几次重试的间隔如下连续失败次数 attempt理论间隔加 0.5~1.5 倍抖动后的范围01s0.5s ~ 1.5s12s1s ~ 3s24s2s ~ 6s38s4s ~ 12s416s8s ~ 24s530s封顶15s ~ 45s630s15s ~ 45s这里的抖动不是可有可无的装饰。假如没有抖动所有客户端都会严格按照同一个时间点比如第 1s、第 2s、第 4s……发起重连当一次大规模网络故障恢复时会出现成千上万个客户端在同一秒涌向服务器这就是所谓的重连风暴。加入抖动之后重连请求在时间轴上被摊开服务器受到的冲击会明显平缓。另外注意每次重试时Math.random()都要重新取不要复用固定的随机种子否则所有客户端的抖动又会趋于一致。2.3 其他决定重连质量的参数上限、错误分类、成功重置围绕这个公式还有几个参数值得单独讲一下。**最大重试次数。**无限重连看起来很保险但会造成两个隐患一是连续失败几十次后客户端仍然在做无用功浪费电量和流量二是一些深层故障比如账号被踢、服务端协议升级、token 永久失效靠重连根本解决不了反而会掩盖真正需要人工干预的问题。我一般会把错误分成两类可重试错误网络不可达、连接超时、服务端主动断开且没有明确拒绝原因不可重试错误HTTP 401/403、协议版本不匹配、服务端返回明确的该连接已永久失效对不可重试错误直接停止重连并触发业务提示对可重试错误才走指数退避。**成功重置。**一旦连接建立成功并进入稳定状态attempt必须归零。否则下次断线时会带着之前的失败计数起步导致重连间隔过大恢复太慢。**连接超时。**很多人只关注断线后的重试间隔忽略了连接建立阶段也可能挂起。如果目标 IP 不可达connect可能长时间不返回客户端一直卡在 CONNECTING 状态。所以重连代码里一定要给建立连接这一步单独设置超时我一般设 5~10 秒超时后强制放弃并计入失败次数。3. 短线重连的状态机与核心代码实现3.1 状态机设计把重连从 if-else 泥潭里解放出来把重连逻辑写成一堆onclose回调里嵌套的 if-else短期能跑但一旦加入心跳、手动停止、手动重连、页面隐藏暂停这些需求代码很快就会失控。我的习惯是先定义一套简单的状态DISCONNECTED初始状态或调用 stop() 之后的静止状态 CONNECTING正在建立连接 CONNECTED连接已建立正常收发数据 BACKOFF等待退避定时器触发状态之间的流转只有几条固定路径connect()被调用 - CONNECTING连接成功open 事件- CONNECTED连接关闭close 事件且未停止 - BACKOFF退避定时器到期 - CONNECTING连接过程中发生超时 - BACKOFFstop()被调用 - DISCONNECTED清理所有定时器这个状态下每条路径都只有一个源头。比如发起新连接这件事只可能由两个动作触发外部手动调用connect()或退避定时器到期。不会出现close 事件触发一次重连、error 事件又触发一次重连的双重连接问题。3.2 基于 WebSocket 的短线重连代码骨架我习惯拿 TypeScript 写网络层类型清晰不容易踩低级错误。下面这个类是一个能直接落地的骨架核心不依赖任何框架Web 和 React Native 里都能用type ConnectionState DISCONNECTED | CONNECTING | CONNECTED | BACKOFF; class ReconnectingSocket { private state: ConnectionState DISCONNECTED; private attempt 0; private backoffTimer: ReturnTypetypeof setTimeout | null null; private connectTimer: ReturnTypetypeof setTimeout | null null; private ws: WebSocket | null null; private stopped false; // 可配置参数 private readonly baseDelay 1000; // 基础间隔单位 ms private readonly maxDelay 30000; // 间隔上限 private readonly connectTimeout 8000; // 连接超时 private readonly maxAttempts 8; constructor(private readonly url: string) {} start() { this.stopped false; this.transition(CONNECTING); } stop() { this.stopped true; this.clearTimers(); if (this.ws) { this.ws.onclose null; // 防止 stop 时触发重连 this.ws.close(); this.ws null; } this.transition(DISCONNECTED); } private transition(next: ConnectionState) { this.state next; if (next CONNECTING) { this.openConnection(); } else if (next BACKOFF) { this.scheduleReconnect(); } } private openConnection() { this.clearConnectTimer(); this.ws new WebSocket(this.url); // 连接超时兜底 this.connectTimer setTimeout(() { if (this.state CONNECTING) { this.ws?.close(); this.attempt; this.transition(BACKOFF); } }, this.connectTimeout); this.ws.onopen () { this.clearConnectTimer(); this.attempt 0; // 成功重置 this.transition(CONNECTED); this.onConnected(); }; // 注意onerror 里不触发重连只记录日志。 // 因为 error 之后通常还会跟一个 close 事件如果在两边都处理会重复调度。 this.ws.onerror (e) { this.onError(e); }; this.ws.onclose () { if (this.state CONNECTING || this.state CONNECTED) { this.transition(BACKOFF); } }; } private scheduleReconnect() { this.clearBackoffTimer(); if (this.stopped) return; if (this.attempt this.maxAttempts) { this.onGiveUp(); return; } const delay this.calculateDelay(this.attempt); this.backoffTimer setTimeout(() { if (!this.stopped) { this.transition(CONNECTING); } }, delay); } private calculateDelay(attempt: number): number { const base Math.min(this.maxDelay, this.baseDelay * Math.pow(2, attempt)); const jitter 0.5 Math.random(); // 0.5 ~ 1.5 return Math.round(base * jitter); } private clearTimers() { this.clearBackoffTimer(); this.clearConnectTimer(); } private clearBackoffTimer() { if (this.backoffTimer) { clearTimeout(this.backoffTimer); this.backoffTimer null; } } private clearConnectTimer() { if (this.connectTimer) { clearTimeout(this.connectTimer); this.connectTimer null; } } // 子类实现连接成功后的业务处理 protected onConnected() {} protected onError(e: unknown) {} protected onGiveUp() {} }这个骨架里有两个很容易被忽略的细节值得展开。**细节一不要在 onerror 里直接重连。**WebSocket 的 error 事件之后通常还会触发 close 事件。如果你在 error 里connect()一次再在 close 里connect()一次就会出现两个 WebSocket 对象同时存在旧连接的回调还会回来捣乱日志里会出现莫名其妙的双倍重连。我见过好几个项目踩这个坑症状是每次断线都会出现两条连接记录。细节二连接超时必须单独处理。new WebSocket(url)并不会在目标不可达时立刻失败。某些网络环境下它可能一直处于 CONNECTING 状态等几十秒才报错。如果不加超时兜底你的短线重连会变成长期悬挂恢复时间完全不可控。3.3 心跳与短线重连的组合方式短线重连不能只依赖被动监听 close 事件因为很多假死连接根本不会触发 close。想象一下这样的场景手机锁屏 10 分钟系统把 App 的 TCP 连接挂起但连接没有被正常关闭服务端因为一段时间没收到数据已经把这边的 socket 回收了。这时候客户端的 TCP 栈还认为连接是好的任何业务消息发出去都石沉大海但 close 事件迟迟不来。解决办法是应用层心跳。客户端定时发一个 ping 帧服务端回 pong也可以顺便带服务端最新 seq。客户端连续 N 次通常是 2~3 次没收到 pong就主动关闭当前连接并进入重连流程。心跳周期怎么定要看你所在网络的中间设备空闲超时阈值网络环境常见空闲超时建议心跳周期云负载均衡四层60s ~ 300s15s ~ 30sNAT 网关UDP/TCP 会话30s ~ 120s15s ~ 30s内网交换机通常很长30s ~ 60s移动网络基站侧不稳定10s ~ 20s我通常的做法是心跳周期设为服务端空闲回收阈值的 1/3 左右。比如服务端说空闲 60 秒回收连接心跳就设 20 秒。然后连续 2 次心跳没收到响应就认定连接已死主动ws.close()触发重连。3.4 服务端如何配合短线重连客户端单方面重连是不够的。短线重连要真正做到短服务端至少要配合三件事。第一保留最近一段时间的会话上下文。连接断开后服务端不要立刻清掉该连接的离线缓冲队列。我常用的做法是客户端断线后服务端把该连接的消息缓存保留 1~5 分钟同时记录客户端最后确认的消息序号ackSeq。客户端重连成功时携带 ackSeq服务端从 ackSeq 开始补发。第二下发一个重连成功事件和当前的全局游标。客户端重连成功后需要知道我该从哪条消息开始补而这个信息只能由服务端给出。常见做法是重连成功后服务端立刻推送一个{ type: sync, cursor: 10245 }的同步帧。第三主动清理僵尸连接。服务端要把它认为的死连接及时关闭否则客户端的心跳机制起不到作用。服务端清理一般用最近活动时间lastActive来判断超过 2~3 个心跳周期没有任何数据就主动断开。4. 上线后最容易踩的坑消息补偿、重复消费和重连风暴4.1 重连期间的离线状态要能对账短线重连最理想的形态是断线只有 2 秒用户发的一条消息在重连后立刻补发成功。但真实业务里客户端在断线期间可能有本地操作。比如 IM 客户端里用户发出了一条消息网络恰好断了这条消息是留在输入框还是进本地队列重连成功后要不要重新发送我推荐的做法是客户端维护一个发送队列 确认机制。消息先写到本地持久化存储再发送服务端收到并落盘后回一个 ack客户端收到 ack 才从本地队列移除。重连成功后扫描队列中未被 ack 的消息统一重发。这里的核心不是重连代码本身而是要让重连参与消息可靠性闭环。对应地服务端要能区分这条消息是第一次收到还是客户端重连后重发的所以客户端发的每条业务消息要带一个全局唯一的 msgId。服务端按 msgId 去重而不是按连接实例去重。4.2 立即重连与重连风暴断线后立刻重连听起来响应最快但在两种情况会出事。第一种是服务端正在进行重启或发布。比如 Kubernetes 滚动更新里旧的 Pod 正在被销毁新的 Pod 还没就绪。这时所有连接到旧 Pod 的客户端都会同时断开、同时重连。如果大家在断线瞬间马上发起新连接而新的服务端实例还在启动中就会出现出发即失败然后大量客户端一起进入相同节奏的退避重试最终把新实例也打垮。第二种是区域性网络故障。假设整个机房的网络出口闪断了 30 秒恢复瞬间所有客户端一起重连。如果没有足够的抖动网关和负载均衡会在第一秒内涌入全部流量此时连接成功率反而很低进而触发第二轮重试形成恶性循环。所以在这个环节策略上要坚持两个原则断线后先退避再重连不要立即重连。即使只是网络切换给一个 200ms~500ms 的短退避能跨过很多瞬时抖动。抖动幅度要足够大。我在生产环境用的比例是 0.5~1.5 倍甚至 0.5~2.0 倍。幅度太小的抖动比如 0.9~1.1在大规模故障时本质上还是同步重连。4.3 重复消息要靠幂等兜底短线重连和消息重发机制一起工作时必须接受一个现实重连期间的消息极大概率会重复收到。原因很简单客户端可能已经收到并处理了某条消息但还没来得及把 ack 发出去连接就断了重连后服务端以为这条消息没被接收于是又补发一次。处理重复消息的经典方案是客户端维护一个最近消息ID的环状缓存比如一个能容纳最近 500 条消息ID的 Set收到消息后先查重是新消息就处理并放入缓存是重复消息就直接丢弃。如果消息量很大可以直接用 Bloom Filter 做近似去重但要注意有一定的误判率业务上必须能容忍偶发丢消息才用。另外一个容易被忽略的点短线重连之后要做的是增量同步不是全量同步。如果你在重连成功后无条件拉取全量状态短时间内大量客户端同时拉取仍然会把服务端压垮。增量同步需要服务端提供按游标拉取的接口客户端传lastSeq服务端只返回lastSeq之后的数据。5. 从日志和指标里验证重连策略是否合理5.1 必采集的重连指标代码写完了策略也定了但怎么知道它到底有没有用光靠体感流畅是不够的。我建议在重连模块里至少埋这几类指标断线原因分布网络切换、空闲超时、心跳超时、服务端关闭、异常报错分别占比多少断线时长分布小于 5 秒的算短线5~60 秒算中线超过 60 秒算长线重连成功率首重成功率、二次重试成功率、最终放弃率恢复耗时从 close 事件到 CONNECTED 状态的延迟每次重连的 attempt 次数分布瞬间重连速率每秒钟全客户端发起的重连请求数第六个指标尤其重要。它不需要像前几个那样逐个上报而是可以在网关或接入层做一个简单的请求速率统计一旦发现每秒重连请求数超过正常值 3 倍以上立刻报警。这是发现重连风暴最直接的手段。5.2 通过日志判断连接是短期抖动还是长期离线日志字段设计上有一个字段最容易被忽略那就是重连原因来源。我习惯在日志里记录下close事件的 code 和 reasonconnIdabc123 stateBACKOFF attempt2 delay4231ms reasonremote_close code1006 connIdabc123 stateCONNECTING attempt3 endpointwss://xxx/resource connIdabc123 stateCONNECTED attempt0 duration12500ms1006是 WebSocket 里最常见的异常关闭码通常意味着底层 TCP 连接直接断掉没有正常的关闭握手。如果你发现大量1006基本可以判断是网络层面抖动或中间设备回收连接如果错误码是1008、1009说明是服务端策略问题重连策略再优化也救不了。有了这些日志调参的时候就能回答重连间隔应该调大还是调小这类问题如果断线时长主要集中在 2 秒内说明你需要缩小 baseDelay让恢复更快如果大量断线都持续几十秒说明退避增长太慢中间产生的无效重试太多需要拉大 baseDelay 或抖动幅度。5.3 结合运营环境做调参重连参数不是一套打天下需要结合你的实际网络环境。我自用的几套基础参数如下你可以直接抄作业然后微调环境类型baseDelaymaxDelay心跳周期说明内网/有线500ms10s30s网络稳定可以激进一点公网/移动端1s30s15~20s抖动大退避要保守弱网/IoT设备2s60s10~15s节省流量电量重试克制Web 前端页面1s30s30s页面不可见时应暂停重连Web 前端还有一个特殊点当页面处于后台或标签页休眠状态时setTimeout可能被浏览器节流。这种情况下不建议硬扛着重连而是监听visibilitychange事件页面重新可见时才恢复重连逻辑。否则你会发现浏览器把定时器压到 1 分钟一次你的退避策略完全失真。我个人在调这一类代码的时候最深的感受是短线重连不是一个连上就行的功能而是一个需要不断跟业务指标对齐的系统。真正上线之后你会发现一半的精力不在 connect 逻辑本身而在消息补偿、风暴控制、日志指标这些看似边缘的细节上。先把这些细节想清楚代码写起来会顺很多。