SD-WAN 智能选路是如何实现的？从链路检测到业务切换
“SD-WAN 智能选路，是不是自动找一条最快的线路？”
这个说法只对了一半。企业真正遇到的情况通常是：宽带测速很快，但视频会议仍然卡；专线没有断，但远程桌面已经明显延迟；两条线路都能访问业务，却不知道为什么系统把关键流量送到了质量更差的路径。
SD-WAN 智能选路解决的不是单纯的“最快”，而是：识别当前业务、持续测量可用路径、按照业务目标选择合适路径，并在质量不满足要求时执行预先定义的动作。
先理解：SD-WAN 选的不是“线路”，而是业务路径
在传统网络中，路由器更关注目的地址和下一跳：只要路由可达，就可以转发。SD-WAN 则会在“可达”之外增加业务和质量维度：
- 这是什么业务：语音、视频会议、ERP、远程桌面、普通网页还是大文件传输。
- 有哪些候选路径：互联网、专线、LTE/5G 或其他可用承载。
- 当前路径质量如何：延迟、丢包、抖动、可用性和带宽占用是否满足要求。
- 企业更看重什么：低时延、低丢包、稳定性、成本、隔离性，还是业务连续性。
- 不满足时做什么：切换备用路径、降低优先级、限速、复制数据包，或者按严格策略阻断。
因此，“带宽最大”不一定是“业务最合适”。直播上行可能更在意持续丢包和抖动；远程桌面更在意交互延迟；批量备份则可以容忍更高延迟，但不应挤占实时业务。
智能选路的 5 个处理步骤
- 应用识别：通过应用特征、协议、端口、地址段、DSCP 或其他策略条件，对流量进行分类。
- 候选路径确认：确认目标站点、云资源或互联网出口有哪些可用的 Overlay / Underlay 路径。
- 质量测量：通过探测或隧道状态持续获取延迟、丢包、抖动和可用性等指标。
- 策略匹配：把业务分类与企业定义的优先路径、质量阈值、备用路径和动作关联起来。
- 持续调整：网络质量变化后，决定新建会话的路径，或对支持的业务执行路径迁移、重建或保护动作。
这里有一个工程上的重要区别：策略下发不等于策略生效。必须确认应用是否被正确识别、探测是否覆盖了真实目的地、阈值是否适合现网，以及切换后业务会话是否真的恢复。
链路质量到底看什么？
| 指标 | 它反映什么 | 典型影响 | 排查提醒 |
|---|---|---|---|
| 延迟 | 数据往返或单向传输耗时 | 远程桌面、语音交互、ERP 操作变慢 | 要确认探测目的地，不能只测本地网关 |
| 丢包 | 数据包在路径上丢失的比例 | 语音断续、视频花屏、TCP 重传 | 要区分接入侧丢包、运营商路径丢包和设备丢包 |
| 抖动 | 数据包到达时间的变化 | 实时音视频不稳定、画面和声音不同步 | 平均延迟正常也可能有突发抖动 |
| 可用性 | 路径、隧道或目标服务是否可达 | 业务中断、隧道重建、访问失败 | “接口在线”不等于“业务可用” |
| 利用率 | 链路当前资源占用情况 | 高峰期排队、突发丢包、关键业务争抢 | 要和队列、QoS 及上行方向一起看 |
为什么“智能选路”有时反而越切越卡？
频繁切换通常不是 SD-WAN 的目标，常见根因是策略和测量设计不匹配：
- 阈值过于敏感：短时抖动就触发切换，业务在两条线路之间来回摆动。
- 探测目标不真实：只探测运营商网关，却没有反映分支到实际 SaaS、云平台或总部业务的路径质量。
- 只看平均值：平均延迟正常，但突发丢包、抖动和带宽拥塞被掩盖。
- 没有滞回机制：主路径刚恢复就立即切回，导致恢复阶段再次中断。
- 业务分类错误：关键应用没有命中策略，或者多个业务被粗略归为同一类。
- 把链路切换当成会话无感：部分长连接、实时会话或有状态业务对出口变化敏感，需要单独验证。
解决方法不是简单把切换关掉，而是建立“进入阈值”和“恢复阈值”两个条件，并设置观察窗口、保持时间和回切策略。例如，路径劣化达到条件后连续保持一段时间才切换，恢复后也需要连续稳定一段时间才回切。
一个实际可执行的策略模板
假设一个分支有企业宽带、第二运营商宽带和 5G 三条链路，可以先用分层策略：
| 业务类别 | 优先路径 | 质量条件 | 备用动作 |
|---|---|---|---|
| ERP / 收银 | 主宽带或专用 Overlay | 按现网基线设置延迟、丢包阈值 | 切换第二运营商，最后使用 5G |
| 视频会议 | 当前实时质量最合格的路径 | 重点关注抖动和丢包，不只看带宽 | 切换到合规路径，必要时启用保护机制 |
| 远程桌面 | 低延迟路径 | 观察交互延迟和突发丢包 | 切换备用路径，但避免频繁回切 |
| 普通网页 | 两条宽带分担 | 可接受一般质量波动 | 任一出口故障后继续使用 |
| 备份 / 大文件 | 低优先级路径 | 限制带宽和时间窗口 | 拥塞时限速，不抢占实时业务 |
| 应急流量 | 5G | 监测流量额度和使用时长 | 超限告警，避免产生额外费用 |
如何判断策略真的生效？
- 先记录基线：在工作日高峰采集各链路到真实业务目标的延迟、丢包和抖动。
- 确认应用识别：检查 ERP、视频会议、远程桌面等业务是否命中对应分类和策略。
- 模拟链路问题：分别模拟断链、延迟升高、持续丢包和带宽拥塞。
- 观察选路过程：确认实际使用路径、策略命中、切换原因和切换时间。
- 验证业务恢复：不要只 ping，要登录 ERP、进行远程桌面操作、召开视频会议或执行真实业务动作。
- 检查回切行为：确认主链路恢复后是否按预期回切，以及是否造成二次中断。
- 保留证据：保存故障前后的链路指标、应用流量、策略事件和业务恢复时间。
几个经常被误解的地方
“智能选路”不等于“多条链路同时加速一个连接”
很多 SD-WAN 场景是按业务流或会话选择路径，并不意味着任意一个 TCP/UDP 连接都能无感拆分到多条线路上。是否支持链路聚合、报文复制、前向纠错或其他增强机制，要以具体产品和业务协议验证为准。
“线路没断”不等于“路径合格”
运营商接口在线、默认网关可达，只能说明局部连通。应用体验可能已经受到中间路径拥塞、跨网互联、云接入位置或出口策略影响。
“切换成功”不等于“业务恢复”
对于有状态连接，路径变化可能触发会话重建或应用重新认证。验收必须站在业务用户角度确认结果。
结论：把“自动选路”做成可验证的业务策略
SD-WAN 智能选路的完整闭环是：
识别业务 → 测量真实路径 → 匹配业务目标 → 选择合适路径 → 质量下降时执行动作 → 用真实业务验证结果。
如果企业只配置了“主线 + 备线”，却没有应用分类、质量基线、阈值设计和故障演练，那么它得到的可能只是更复杂的主备路由，而不是可运营的 SD-WAN。
对于中小企业，建议先从 1 个代表性分支和 2–3 类关键业务开始，验证“链路质量—策略动作—业务恢复”是否闭环，再复制到其他站点。这样比一开始堆叠大量策略，更容易找到真正有价值的配置。