一次选路背后有几个判断
一次连接从建立到稳定，中间要经过 4 次判断：候选线路怎么组、评分怎么算、何时切换、切完之后要不要回。本文按 2026 年 7 月的调度日志把这 4 步拆开写。
用户看到的是"连上了"，系统看到的是一连串判断。这四步里任何一步的策略不匹配，体感都会表现为"偶尔卡一下"而不是"连不上"，因此也就更难被定位——这也是我们把决策过程写下来的原因。
第一步是组候选。同一个方向的 6 条候选线路来自三类来源：同城节点、跨洲骨干链路、合作机房，三类按固定比例混合。混合的目的很直接：如果全部候选来自同一家上游，那么上游一次抖动就会同时打掉全部候选；2026 年 7 月 6 日凌晨的跨洲抖动就是这个问题的反例。
第二步是算评分。三项输入分别是往返延迟、丢包率与带宽占用，2026 年 7 月的权重为 45%、35% 与 20%，逐条记录可从调度日志导出。三项都取最近三次探测的中位数而不是单次值，避免单次抖动把健康线路拉下榜单。
用中位数是有代价的：线路刚恢复时会有一个滞后期，实测约 6 秒。这个滞后期换来的好处是稳定性——2026 年 7 月的调度日志里，同一方向每小时平均发生 0.7 次切换，其中 82% 发生在上游恢复之后的回切阶段，真正由抖动引发的切换不到两成。
第三步是判断何时切。规则是排名第一的线路连续 3 个评估周期评分低于阈值，客户端才发起切换；评估周期 2 秒，所以一次完整的切换决策最短约 6 秒。单周期抖动不触发，这是刻意留的缓冲。
第四步是决定要不要回。上游恢复之后系统不立即回切，而是按 30 秒间隔逐条把权重加回去。理由是刚恢复的链路还没验证过承载能力，一次性把流量打回去很容易造成二次拥塞；2026 年 7 月的两起跨洲抖动都在上游恢复后 90 秒内被冗余线路吸收，没有出现回切抖动。
把四步串起来看，切换耗时就不是一个孤立数字。2026 年 7 月的调度日志记录了 3180 次切换，其中 61% 落在 35~55 毫秒区间，最长一次为 110 毫秒；这个耗时的构成主要是改写转发路径与状态同步，与网络本身的 RTT 无关。
这也是为什么跨洲对照能成立：2026 年 7 月 19 日上海至纽约方向的往返延迟，接入快连后中位数为 92 毫秒，未接入时为 178 毫秒，连续 8 次取中位数。改善来自"选到了更短的路"，而不是"把路修得更快"，所以它不随时间衰减，也不会因为流量涨上去而失效。
数据要点
- 候选线路共 6 条，按同城节点、跨洲骨干、合作机房三类来源固定比例混合，避免全部候选落在同一风险域。
- 评分权重依据 2026 年 7 月的调度日志为延迟 45%、丢包率 35%、带宽占用 20%，三项均取最近三次探测的中位数。
- 切换触发条件为连续 3 个评估周期低于阈值，评估周期 2 秒，因此一次完整决策最短约 6 秒。
- 2026 年 7 月共记录 3180 次线路切换，61% 落在 35~110 毫秒区间中的 35~55 毫秒段，最长一次 110 毫秒。
- 回切按 30 秒间隔逐条加权重，依据 2026 年 7 月的两起跨洲抖动记录，均在上游恢复后 90 秒内完成吸收。
延伸问题
单次抖动为什么不立刻切换？
立刻切换会把一次抖动放大成一次连接重建，用户侧表现为卡顿。等待 3 个周期（约 6 秒）可以过滤掉绝大多数瞬时抖动，代价是真实故障的恢复晚 6 秒，这个交换在 2026 年 7 月的调度日志里被证明是划算的。
参考与口径
本文调度数据来自 2026 年 7 月的调度日志（可按时间导出）与同区间的分钟级探测记录。跨洲延迟测试条件为上海至纽约，2026 年 7 月 19 日连续 8 次取中位数；切换耗时统计覆盖当月 3180 次切换记录。权重配置在当月内保持固定，变更只在月度复盘后统一发布。