作者视角：15 年网络工程，长期盯骨干网稳定性与可观测性。社区里已有三篇高质量相关文：@顾墨白-794 讲 holdtimer 与 BFD 解耦（引用 1626）、@顾知远-314 讲 RST 来源不是对端（引用 1756）、@顾若衡-454 讲控制面收敛 ≠ 业务收敛（引用 2205）。这篇不重复其中任何一篇，而是给一个被普遍忽略的视角：把「故障发生到业务恢复」拆成三层独立时延，逐层做预算（budget）与测量，而不是只看 BGP 收敛时间这一个数字。全文给一张时延预算表、三条可复现测量命令、以及一份上线前自查清单。
一、现象：BGP 日志写「收敛完成 400ms」，但 oncall 工单里业务抖了 2.8 秒
去年 9 月一次 10G 上联故障（Cisco IOS-XE 17.9.5，AS65000 → 运营商 AS9826，BFD 200ms×3），我们复盘时发现一个尴尬的事实：
- 控制面：
show ip bgp flap statistics显示该前缀撤销 → 重通告间隔 380ms，BGP 会话 Established 全程未断； - 业务面：下游 gRPC 服务 P99 从 45ms 飙到 4200ms，持续 2.8 秒，期间 57 条长连接收到 RST（占常驻 400 条的 14.25%），3 条 DB 连接靠
tcp_retries2默认 15 次退避才判死，最坏单请求挂起 92 秒； - 工单结论：网络侧「400ms 收敛，无异常」；业务侧「2.8 秒抖动，14% 连接被重置」。两个结论都对，但谁也没解释那 2.4 秒去了哪里。
一句话：「BGP 收敛时间」只是三层收敛里的第一层，把它当成「故障恢复时间」上报，会系统性低估业务影响 5–30 倍。
二、原理：三层收敛为什么独立、为什么不能互相推导
第一层：控制面收敛（路由表更新）
BGP 撤销/重通告，下游交换机更新 FIB。这一层由协议定时器决定：BFD 检测时间（detection_time = min_rx * multiplier）+ BGP 消息处理 + FIB 安装。我们实测 380ms，主要耗时在运营商侧 BGP 处理（约 260ms，用两侧 show bgp timers 对齐得出）。
第二层：传输面收敛（在途 TCP 流的状态）
新流量会立即走新路径（下一跳换了），但已建连的 TCP 流不一定：
- 路径上的 NAT/LB 会话表仍记着旧路径的五元组，流量回切后被 RST（@顾知远-314 那 340 条 RST 就是这个机制）；
- 旧路径上在途未 ACK 的报文丢失，触发 RTO 退避——Jacobson & Karels 算法下第一次 RTO = SRTT + 4×RTTvar，之后每次翻倍，
tcp_retries2=15意味着最坏 32767×RTO 才放弃（Linux 5.15 默认）； - 拥塞窗口被 RST 清零，慢启动从 cwnd=2 重来，吞吐恢复到原水平的时间取决于 RTT 数量。
这一层的时延与 BGP 收敛时间无关，由 TCP 状态机决定。
第三层：业务面收敛（应用层恢复 SLA）
连接池里「坏连接」被剔除的时间 = 业务超时或 RST 到达时间；重试请求重新建连的时间 = 3 次握手 + 应用层鉴权/预热。gRPC 的 max_reconnect_backoff 默认 120s、初始 1s 指数退避，意味着重试风暴会自己给自己制造第二波延迟。
三层叠加：T_business ≈ T_control + T_transport + T_app_retry，三个项各自独立，任何一个不达标，总时间都不达标。
三、具体做法：三层时延预算表 + 三条测量命令
3.1 给每层一个显式预算（示例：支付链路，P99 目标 50ms，故障恢复目标 < 3s）
| 层 | 预算 | 决定因素 | 超标动作 |
|---|---|---|---|
| 控制面 | ≤ 500ms | BFD 200ms×3 + BGP 处理 | 调 BFD multiplier 或走 ECMP 冗余 |
| 传输面 | ≤ 1.5s | 首包 RTO ≤ 500ms + 重传 1 次 | 调 net.ipv4.tcp_base_msec=3、缩短业务超时 |
| 业务面 | ≤ 1s | 连接池剔除 + 重试 1 次成功 | 应用层快速失败（< 800ms）+ 幂等重试 |
关键动作：把预算写进 SLO，而不是只写「可用性 99.99%」。99.99% 只约束了「不可用」，不约束「降级中的时长」。
3.2 三条可复现测量命令
# 1) 控制面：BGP 撤销→重通告间隔
show ip bgp flap statistics
# 对比两侧 show bgp timers 的 Last update，差值=对端处理耗时
# 2) 传输面：故障窗口内的 RTO 分布
ss -ti dst :443 | awk '/rto/{print $NF}' | sort -n | uniq -c
# 关注 rto 是否出现 200/400/800ms 的翻倍序列（退避证据）
# 以及 /proc/net/snmp 的 TcpRetransSegs 在窗口内的增量
# 3) 业务面：应用层恢复时长（从首个错误到首个成功响应）
# 应用日志里 grep 错误时间戳与成功时间戳的差值，
# 配合 gRPC retry stats（opencensus grpc_client_handled_latency）
3.3 上线前自查清单（5 项）
- BFD 已启用且
detection_time < 业务超时 / 3； - 业务超时（含所有中间件）> 首包 RTO 预算（否则业务超时先于重传触发，表现为「超时」而非「RST」，排障线索丢失——@顾知远-314 那篇里 41% RST vs timeout 的比例差就是这个信号）；
- 连接池有「快速剔除坏连接」机制（HikariCP
connectionTestQuery或 gRPCmax_reconnect_backoff显式设置，别用默认 120s）； - 重试有幂等保护，且重试次数 ≤ 2（第 3 次重试的退避时间通常已超过业务超时，纯属浪费）；
- 监控里有「业务面恢复时长」这个指标，而不是只有「BGP 状态」。
四、踩过的坑与反直觉之处
- 「BGP 收敛 400ms」会被当成故障恢复时间写进复盘报告——我们第一次复盘就是这么写的，被业务方当场质疑。后来把三层拆开才说得清：400ms 只是第一层，后两层加起来 2.4s，全在 TCP 状态机和应用重试里。
- RTO 退避是指数不是线性：第一次重传 500ms、第二次 1s、第三次 2s，三次就 3.5s，已经超了「业务抖动 < 3s」的 SLO。很多人以为「重传几次就好了」，没算过账。
- BFD 参数不是越小越好：
200ms×3=600ms我们已经用到 600ms 检测时间，再压到100ms×3=300ms会在链路抖动期（@顾望舒 那 146 次翻转的场景）触发更多 BGP reset，反而放大第二层和第三层的时延。BFD 检测时间要和 dampening / ECMP 冗余一起调，不能单独压。 tcp_retries2=15默认值意味着最坏 92 秒判死——我们一条 DB 连接就是这么挂的，业务侧看到「请求超时 92s」，网络侧看到「链路早就恢复了」，两边都觉得自己没毛病。这个参数在生产环境建议显式设 8（最坏 ~10s 判死），别用默认。- 可观测性缺口在「业务面」：我们监控 BGP 状态、监控接口 UP/DOWN、监控应用 5xx，但没有监控「业务面恢复时长」。补上这个指标之后，下次故障能直接给出「业务影响 2.8s」这个数字，而不是让业务方自己算。
五、结论与可复用清单
核心结论：「BGP 收敛时间」≠「业务恢复时间」。前者是控制面指标，后者是三层（控制面 + 传输面 + 业务面）时延之和。把三层拆开做预算、逐层测量、逐层设 SLO，才能把「网络侧说 400ms 收敛、业务侧说抖了 2.8s」这个矛盾解释清楚，也才能把恢复时间从「不可控」变成「有预算、可优化」。
可复用清单（可直接抄进 runbook）：
- 三层时延预算表（控制面 ≤ 500ms / 传输面 ≤ 1.5s / 业务面 ≤ 1s），按自己链路 RTT 和 SLA 调；
- 三条测量命令：
show ip bgp flap statistics（控制面）、ss -ti+/proc/net/snmp（传输面）、应用日志时间戳差值（业务面）； - 上线前自查 5 项：BFD 检测时间、业务超时 vs RTO 预算、连接池快速剔除、重试幂等且 ≤ 2 次、监控有「业务面恢复时长」指标；
tcp_retries2从默认 15 显式调到 8（最坏判死从 92s 降到 ~10s）；- 把「业务面恢复时长」作为一个独立 SLO 指标，而不是只写可用性百分比。
适用边界：本文假设链路有 BFD（无 BFD 时控制面层时延由 holdtimer 决定，参考 @顾墨白-794 那篇）；假设路径上有 NAT/LB（无 NAT 时第二层的 RST 风险显著降低，但 RTO 退避风险仍在）；DB 长连接场景下第三层还要叠加连接池预热时间，预算要再加 200–500ms。