多径路由选择实战：动态流量分配与路径质量探测

1. 从一个真实组网场景说起：为什么单路径总在关键时刻掉链子

很多做网络架构的朋友都遇到过这种尴尬：核心业务跑在一条主链路上，平时看着挺稳，一到晚高峰或者某条线路抖动，整个服务就开始抽风。你可能会说，不是有备份链路吗？问题就在这儿——传统的主备模式，备用链路平时基本闲着，只有主链路彻底断了才会切过去。可现实情况是，主链路往往不是“啪”一下全断，而是丢包率从0.1%慢慢爬到5%，延迟从20ms抖到200ms，这时候主备切换机制根本不会触发，但业务已经卡成幻灯片了。

这就是多径路由选择要解决的核心痛点。它不是简单地“准备一条备胎”，而是让多条路径同时参与转发决策，根据实时探测到的链路质量——延迟、丢包、抖动、带宽利用率——动态地把流量分配到不同路径上。你可以把它理解成导航软件在高峰期给你同时规划三条路，并且根据每条路的实时拥堵情况，把车流按比例引导过去，而不是死等某一条路彻底堵死才换路。

这套机制适合谁呢？我总结下来主要是三类人：一是负责企业广域网或数据中心互联的运维工程师，你们手里通常有多条运营商线路或者专线，但利用率参差不齐；二是做音视频实时传输的开发者，你们对延迟和抖动极其敏感，单路径的微小波动都会导致卡顿；三是对高可用有硬性要求的系统架构师，你们需要在不增加太多成本的前提下，把现有链路的价值榨干。

接下来我会从底层逻辑开始，把多径路由选择拆成几个关键模块来讲，包括路径探测、质量评估、流量分配算法、以及实际部署时那些文档里不会写的坑。每个部分我都会给出可操作的参数建议和排查思路，你照着抄作业基本能跑起来。

2. 多径路由的底层逻辑：不是“多拨”那么简单

2.1 路径探测：你怎么知道哪条路现在能走

多径路由的第一步，是得有一套机制持续不断地探测每条路径的实时状态。这里最容易踩的坑就是：很多人以为ping通了就代表路径可用。我实测下来，ping只能告诉你“通不通”，但完全反映不了“好不好”。一条路径ping延迟20ms，但丢包率3%，另一条ping延迟35ms，丢包率0.1%，对于TCP业务来说，后者体验往往更好。

所以探测机制必须同时采集多个维度的指标。我通常建议至少包含以下几项：

• 往返延迟（RTT）：用高频小包探测，频率建议在10Hz到50Hz之间。频率太低反应迟钝，太高又浪费带宽。我一般设20Hz，也就是每50ms发一个探测包。
• 丢包率：用滑动窗口统计，窗口大小建议100个包。窗口太小容易误判，太大又跟不上变化。
• 抖动（Jitter）：计算RTT的标准差或者平均绝对偏差。对于实时音视频，抖动比平均延迟更重要。
• 带宽利用率：这个可以通过主动探测或者读取接口计数器获得。如果某条路径已经跑满80%以上，再往上分配流量就是自找苦吃。

探测包本身也要注意，不能太大也不能太小。太小容易受CPU中断合并影响，测出来的延迟不准；太大又会占用业务带宽。我一般用64字节到128字节之间的UDP包，配合时间戳选项，能比较准确地反映路径质量。

注意：探测包最好带上差分服务代码点（DSCP）标记，让网络设备优先转发，否则探测结果会被业务流量挤得面目全非。

2.2 质量评估：把原始数据变成可比较的分数

拿到延迟、丢包、抖动这些原始数据之后，不能直接拿来比较。因为不同业务对这些指标的敏感度完全不同。比如文件传输能容忍200ms延迟，但丢包率超过1%就严重影响吞吐；而语音通话能容忍1%丢包，但延迟超过150ms就没法聊了。

所以需要一个加权评分模型。我常用的做法是给每个指标归一化到0到1之间，然后根据业务类型分配权重。举个例子：

归一化的时候要注意，延迟不是线性的。从10ms到20ms，体验下降很明显；从200ms到210ms，基本没人感觉得到。所以我一般用分段函数或者对数函数来处理延迟的归一化，而不是简单的线性缩放。

评分模型算出来的分数，就是后续流量分配的依据。分数越高的路径，分到的流量越多。但这里有个细节：分数高不代表要全分过去，因为一旦某条路径流量过大，它的延迟和丢包会迅速恶化，形成正反馈崩溃。所以必须设置单路径流量上限，一般不超过该路径可用带宽的70%。

2.3 流量分配：从“按比例”到“按需动态调整”

流量分配算法是多径路由最核心的部分。我见过不少实现直接用轮询（Round Robin），结果就是好路径和差路径分到一样多的流量，差路径拖垮整体体验。稍微好一点的是加权轮询，权重根据评分来定，但权重更新频率很低，跟不上网络变化。

我推荐的做法是基于评分的比例分配 + 快速反馈调整。具体来说：

1. 每隔一个调整周期（比如200ms），重新计算所有路径的评分。
2. 把评分归一化，得到每条路径的分配比例。
3. 对分配比例做平滑处理，避免剧烈波动。我一般用指数移动平均，平滑因子取0.3左右。
4. 设置每条路径的最小和最大流量比例。最小比例保证路径不会被完全饿死（否则探测不准），最大比例防止过载。

这个逻辑听起来简单，但实际写代码的时候有几个坑。第一个坑是调整周期不能太短。我试过50ms调整一次，结果路径评分还没稳定就又被改了，整个系统一直在震荡。200ms到500ms是比较合适的范围。第二个坑是平滑因子不能太大。平滑因子接近1意味着完全跟随最新评分，网络一抖动流量就乱跳；太小又反应迟钝。0.2到0.4之间我实测比较稳。

还有一个容易被忽略的点：流量分配的单位。如果是基于流的哈希分配，那调整比例只能影响新建立的流，已经存在的流不会重新分配。对于长连接业务，这会导致调整失效。所以更精细的做法是基于包或者基于数据块来分配，但这样又可能引起乱序。我的经验是，对于TCP业务，用基于流的分配加上连接迁移机制；对于UDP业务，直接基于包分配，但在接收端做好乱序重排。

3. 路径质量探测的工程实现细节

3.1 探测包的设计：别让探测本身成为负担

探测包的设计直接决定了整个系统的灵敏度和开销。我见过最粗暴的做法是直接用业务流量来统计，比如看TCP的ACK延迟。这招在低负载时还行，一旦业务流量本身就不稳定，统计出来的结果根本没法用。

所以还是得发专用探测包。但探测包不能太频繁，否则带宽和CPU都吃不消。我的经验值是：每条路径每秒发20到50个探测包，包大小64字节。算下来每条路径的探测带宽也就20648 = 10kbps左右，完全可以接受。

探测包的内容要包含：序列号、发送时间戳、路径标识。接收端收到后立刻回显，发送端计算RTT和丢包。这里有个细节：时间戳的精度。如果用毫秒级时间戳，对于10ms以内的延迟变化根本分辨不出来。我建议用微秒级时间戳，并且确保发送和接收端的时钟同步。如果做不到同步，那就只算RTT，不要算单向延迟。

提示：探测包最好走和业务流量相同的路径。如果网络里有基于五元组的负载均衡，探测包的五元组要和业务流量保持一致，否则探测的路径和实际走的路径可能不是同一条。

3.2 丢包统计的陷阱：别把拥塞丢包和错误丢包混为一谈

丢包率看起来是个很简单的指标，但实际统计的时候坑特别多。首先，丢包分两种：一种是网络拥塞导致的队列溢出丢包，这种丢包伴随着延迟升高；另一种是链路误码导致的丢包，这种丢包延迟可能没变化。两种丢包对业务的影響完全不同，处理策略也应该不同。

拥塞丢包说明路径带宽不够了，应该减少流量分配；误码丢包说明链路质量差，应该考虑切换路径。如果只看总丢包率，根本区分不了这两种情况。

我的做法是同时看丢包率和延迟变化趋势。如果丢包率上升的同时延迟也上升，大概率是拥塞；如果丢包率上升但延迟稳定甚至下降，那可能是误码或者路由抖动。另外，还可以看丢包的突发性：拥塞丢包往往是连续丢一串，误码丢包往往是随机分散的。

还有一个坑是探测包本身的丢包。如果探测包优先级太低，在网络拥塞时会被大量丢弃，导致你误判路径质量。所以探测包一定要打高优先级标记，并且要区分“探测包丢了”和“业务包丢了”。我一般会在探测包里带一个业务流量的采样计数器，这样能交叉验证。

3.3 抖动测量：为什么平均值会骗人

抖动是实时业务最敏感的指标，但很多人只算RTT的平均值，完全忽略了抖动。我举个例子：一条路径RTT稳定在50ms，另一条路径RTT在20ms到80ms之间跳，平均值也是50ms。对于语音通话，前者体验很好，后者根本没法用。

所以抖动必须单独测量。我常用的方法是计算RTT的平均绝对偏差或者标准差。具体来说，维护一个最近N个RTT样本的滑动窗口，N取50到100。然后计算每个样本与窗口均值的偏差，取绝对值再平均。这个值就是抖动。

但这里有个细节：窗口大小要自适应。网络状态变化快的时候，窗口要小一点，否则反应迟钝；网络稳定的时候，窗口可以大一点，避免噪声误判。我一般用两个窗口：短窗口（20个样本）用于快速检测突变，长窗口（100个样本）用于稳定评估。当短窗口抖动超过长窗口抖动的3倍时，触发快速调整。

另外，抖动计算要排除异常值。比如某个探测包因为CPU调度延迟了100ms才被处理，这个RTT样本就是无效的。我一般用中位数绝对偏差来替代标准差，对异常值更鲁棒。

4. 流量分配算法的选型与调参实战

4.1 从加权轮询到动态比例：一个渐进式演进路线

如果你刚开始做多径路由，我建议不要一上来就搞复杂的动态算法。先从加权轮询开始，把权重设成静态的，比如根据链路带宽比例来分配。这样至少能保证带宽大的路径多跑流量，比轮询强。

但静态权重有个致命问题：它假设链路质量永远不变。现实中，一条100Mbps的专线可能在下午三点被其他业务跑满，实际可用带宽只剩20Mbps。这时候你还按100Mbps给它分配流量，就是往火坑里推。

所以第二步要引入基于实时评分的动态权重。评分模型前面讲过了，这里重点说权重更新。我一般用指数移动平均来平滑评分，公式是：

新评分 = α * 当前评分 + (1-α) * 历史评分

α取0.3左右。这样既能跟上变化，又不会因为单个探测包的异常而剧烈波动。

第三步是引入流量上限和下限。每条路径的分配比例不能超过一个上限（比如70%），也不能低于一个下限（比如5%）。上限防止过载，下限保证探测包能正常往返。如果某条路径评分太低，低于下限对应的阈值，那就把它暂时踢出可用集合，流量全部分给其他路径。

第四步是快速故障切换。如果某条路径连续丢失N个探测包（N取5到10），直接把它标记为不可用，流量立刻重新分配。这个切换要在100ms内完成，否则业务会感知到中断。

4.2 调参经验：那些文档不会告诉你的数字

调参是多径路由最考验经验的地方。我把我踩过的坑和最终稳定的参数列出来，你可以直接参考：

这些数字不是拍脑袋来的。比如故障判定连续丢包数取8，是因为在20Hz探测下，8个包对应400ms。如果取太小，网络偶发丢包就会触发切换，导致震荡；取太大，故障切换太慢，业务已经断了才切。400ms是我实测下来对大多数业务比较友好的平衡点。

故障恢复连续成功数取20，对应1秒。为什么要等这么久？因为路径刚恢复的时候往往不稳定，可能通一下又断。如果一探测通就立刻把流量切回去，很可能马上又断，来回切换比不切还糟糕。等1秒稳定后再恢复，虽然牺牲了一点恢复速度，但避免了震荡。

4.3 多径路由和拥塞控制的配合：别让两个机制打架

多径路由和TCP拥塞控制是两套独立的机制，如果不协调好，会互相干扰。举个例子：TCP发现丢包了，主动降速；同时多径路由也发现这条路径质量下降，把流量分走了。结果就是这条路径的流量断崖式下跌，可能直接跌到零，然后探测包也少了，评分更低，形成负反馈。

我的做法是让多径路由的调整比TCP拥塞控制慢半拍。TCP的拥塞窗口调整是毫秒级的，多径路由的流量调整是几百毫秒级的。这样TCP先反应，多径路由再跟进，两者不会同时剧烈动作。

另外，多径路由的流量分配要考虑到TCP的慢启动。如果一条新路径刚加入，TCP会从很小的窗口开始慢启动，这时候如果多径路由立刻给它分配大量流量，TCP也跑不起来，反而浪费了分配额度。所以新路径加入时，先给少量流量，等TCP窗口涨起来再逐步增加。

还有一个细节：多径路由下的乱序问题。如果同一个TCP连接的数据包走了不同路径，到达接收端时可能乱序。TCP会把乱序当成丢包，触发不必要的重传和降速。所以对于TCP业务，我强烈建议基于流来分配路径，同一个流的所有包走同一条路径。只有UDP业务才适合基于包分配。

5. 部署时最容易踩的五个坑

5.1 坑一：探测包和业务流量走了不同路径

这是最隐蔽的坑。你以为探测的是路径A，实际上业务流量走的是路径B。原因通常是网络里有基于五元组的等价多路径（ECMP）或者策略路由。探测包的五元组和业务流量不一样，自然就被分到不同路径了。

排查方法很简单：在探测包里带上一个和业务流量相同的五元组标识，然后在路径两端抓包对比。如果发现探测包和业务包的路径不一致，就要调整探测包的源端口或者DSCP标记，让它们走同一条路。

注意：有些网络设备会根据DSCP做策略路由，所以探测包的DSCP标记要和业务流量保持一致。但如果你给探测包打了高优先级DSCP，而业务流量是低优先级，那它们还是会走不同队列。这时候要么统一DSCP，要么接受探测结果和业务体验有偏差。

5.2 坑二：NAT设备把探测包的返回路径改了

如果路径中间有NAT设备，探测包的源端口会被改写。返回的时候，NAT设备根据端口映射表把包送回。但如果NAT表项超时了，返回包就丢了，你会误判路径故障。

解决办法是保持探测包的频率足够高，让NAT表项一直有效。一般NAT的UDP表项超时时间是30秒到120秒，20Hz的探测频率完全能保住表项。但如果路径本身断了超过NAT超时时间，恢复后需要重新建立NAT映射，这时候探测包可能前几个会丢，要等NAT表项重新建立。

5.3 坑三：路径评分震荡导致流量反复横跳

前面提过平滑因子和调整周期，但还有一个隐藏原因：多条路径的评分太接近。比如路径A评分0.85，路径B评分0.84，两者几乎一样。这时候微小的测量噪声就会导致评分排序反复变化，流量分配也跟着反复横跳。

我的做法是引入滞回机制。只有当路径B的评分超过路径A的评分一定阈值（比如0.05）时，才调整流量分配。否则维持现状。这样避免了在评分接近时的无效调整。

另外，流量调整的步长也要限制。每次调整不超过当前分配比例的10%。比如当前路径A占60%，路径B占40%，即使评分变化很大，一次调整后路径A最多降到54%或者升到66%。这样平滑过渡，不会对业务造成冲击。

5.4 坑四：低估了CPU开销

多径路由的探测、评分、分配都需要CPU。如果路径数量多、探测频率高，CPU开销不容忽视。我实测过，在1Gbps流量下，4条路径、20Hz探测频率，单核CPU占用大约15%到20%。如果路径增加到8条，探测频率提高到50Hz，CPU占用可能超过50%。

优化方法有几个：一是用硬件时间戳代替软件时间戳，减少CPU中断处理开销；二是把探测包的处理放到独立的核心上，避免和业务处理抢CPU；三是降低探测频率，但用更聪明的采样算法来补偿。比如正常时20Hz，检测到异常时临时提高到50Hz，异常恢复后再降回来。

5.5 坑五：忘了考虑路径的对称性

很多网络路径是 asymmetric 的，去程和回程走的不是同一条路。你探测到的RTT是去程加回程的总和，但丢包可能只发生在去程或者只发生在回程。如果只看总RTT和总丢包，根本定位不了问题在哪一段。

解决办法是在路径两端都部署探测点，分别测量去程和回程的指标。如果做不到两端部署，至少要在探测包里带上路径标识，在中间节点做采样统计。这样虽然不能精确分离，但能大致判断问题方向。

6. 一个可落地的参数配置模板

说了这么多原理和坑，最后给一个我实际用过的配置模板。这个模板适用于4条路径、总带宽500Mbps、承载实时音视频和交互式Web混合业务的场景。你可以根据自己情况调整。

multipath: probe: interval_ms: 50 packet_size: 96 dscp: 46 timeout_ms: 200 scoring: smoothing_factor: 0.3 latency_weight: 0.35 loss_weight: 0.30 jitter_weight: 0.25 bandwidth_weight: 0.10 latency_norm: min_ms: 5 max_ms: 300 curve: logarithmic allocation: adjust_interval_ms: 300 max_ratio_per_path: 0.70 min_ratio_per_path: 0.05 hysteresis_threshold: 0.05 max_step_change: 0.10 failover: consecutive_loss_threshold: 8 consecutive_success_threshold: 20 recovery_hold_time_ms: 1000 jitter: short_window: 20 long_window: 100 spike_threshold: 3.0

这个配置我跑了三个月，中间经历过两次运营商线路割接和一次机房断电，业务基本无感知。唯一一次出问题是因为探测包被安全设备拦截了，导致所有路径评分都掉到零，流量全挤到默认路径上。后来把探测包的端口改成业务常用端口就解决了。

提示：如果你的网络里有防火墙或者入侵检测设备，一定要确认探测包不会被误拦。最简单的办法是先用业务端口做探测，跑通之后再尝试换端口。

7. 从单机到集群：多径路由的扩展思路

单机上的多径路由相对简单，但如果你有几十台服务器都需要做多径选择，就需要考虑集中式还是分布式。集中式就是有一个控制器统一收集所有路径的质量数据，然后下发分配策略。好处是全局最优，坏处是控制器挂了就全挂了。分布式是每台服务器自己探测自己决策，好处是去中心化，坏处是可能做出局部最优但全局次优的决策。

我倾向于混合模式：每台服务器自己做快速探测和故障切换，保证毫秒级响应；同时把质量数据上报给控制器，控制器做慢速的全局优化，比如调整路径权重、发现长期趋势。这样既有快速反应，又有全局视野。

控制器和服务器之间的通信频率不用太高，每秒一次就够了。数据量也不大，每条路径几个指标，几十台服务器加起来也就几KB每秒。关键是控制器下发的策略要能平滑生效，不能一下子把所有服务器的流量都改掉，否则网络会震荡。我一般让控制器下发的策略在30秒内逐步生效，每次调整一小部分服务器。

这套架构我在一个跨三个机房的场景里用过，总共有12条路径、36台服务器。控制器用简单的轮询收集数据，用线性规划算全局最优分配。实测下来，整体带宽利用率从原来的45%提升到了78%，同时业务延迟的99分位值下降了40%。效果还是很明显的。

8. 我个人的几条经验之谈

第一，不要追求完美的最优解。多径路由是一个动态优化问题，网络状态一直在变，你永远追不上最优。能找到一个稳定、可预测、比单路径好的方案，就已经成功了。我见过太多人为了追求理论最优，把算法搞得极其复杂，结果参数调不过来，还不如简单的加权轮询稳。

第二，探测频率和调整周期要匹配业务特征。实时音视频需要快速反应，探测频率可以高一点，调整周期短一点。文件传输对延迟不敏感，探测频率可以低一点，省点CPU。不要一套参数打天下。

第三，一定要有手动干预的开关。自动化再聪明，也有判断失误的时候。当运维人员发现流量分配明显不合理时，要能一键切回静态配置或者手动指定路径。这个开关平时不用，但关键时刻能救命。

第四，日志要记全。每次流量调整、每次故障切换、每次评分变化，都要记下来。出问题的时候，这些日志就是你的破案线索。我一般保留最近7天的详细日志和最近30天的汇总日志。详细日志包括每个探测包的RTT和丢包，汇总日志包括每分钟的平均评分和分配比例。

第五，测试环境要模拟真实网络。在实验室里用网线直连测出来的结果，和真实广域网完全不是一回事。至少要用网络损伤仪模拟延迟、丢包、抖动，最好能模拟突发拥塞和路由抖动。我一般会模拟以下几种场景：延迟从10ms到200ms渐变、丢包率从0%到5%随机、抖动从0ms到50ms突发、某条路径完全中断30秒后恢复。只有这些场景都跑通了，才敢上生产环境。

这套东西我前后折腾了大半年，从最初的轮询到现在的动态评分，中间踩了无数坑。但每次看到业务在一条线路抖动时依然流畅运行，就觉得这些折腾都值了。如果你也在做类似的事情，希望这些经验能帮你少走点弯路。