本文面向负责多分支网络的 IT 负责人与网络架构师。厂商与产品信息为公开资料整理；文中案例均已脱敏，数字为参考值；技术估算基于公开模型，以实测为准。
SD-WAN 已经过了"要不要上"的阶段。十年前它以"用互联网替代昂贵专线"出场，今天几乎所有网络、安全和云厂商都有自己的 SD-WAN，运营商也把它做成了标准套餐。技术本身不再稀缺，项目之间的差距主要来自两件事：组网模式和业务流量是否匹配，底层网络出问题时有没有人兜得住。
一个很典型的场景是这样的：某连锁零售企业在全国有 400 多个门店，上线 SD-WAN 半年后，IT 部门发现两个问题。一是每天晚上八点到十点，门店收银系统访问总部 ERP 时常出现两三秒的卡顿，恰好是客流高峰；二是新门店开业，从设备寄到现场到能用，仍然需要派人跑一趟，因为门店只有一条运营商宽带加一张 4G 卡，4G 地址在运营商的大 NAT 后面，隧道建不起来。设备功能表上的"智能选路""零接触部署"都写着支持，可问题恰恰出在功能表不会写的地方——组网模式选的是星型，所有门店流量都回总部 HUB，而总部 HUB 和门店之间走的全是跨省公网。
这就是 SD-WAN 选型最常见的错位：用功能清单去比较一个本质上是"架构"的问题。下面先从拓扑讲起，再讲 12 个真正决定项目成败的要点。
一、SD-WAN组网的5 种主流模式：先算清楚工程量
组网模式讨论的是站点之间、站点与数据中心和云之间，流量怎么走、隧道怎么建。拓扑一旦定下，后面选设备、选线路、选服务商都要围绕它展开。
SD-WAN 五种主流组网模式
模式一：星型（Hub-Spoke）
所有分支只和总部或数据中心的 HUB 建隧道，分支之间互访经 HUB 中转。它的优点是简单、策略集中、审计方便：安全检测、上网行为管理、日志留存都可以放在 HUB 统一做。
它的问题要用数字看。假设 300 个门店、每店高峰 20 Mbps，HUB 侧要承受的汇聚流量就在 6 Gbps 量级，而且全部是加密隧道流量。HUB 设备要按加密吞吐选型，而不是按路由转发吞吐选型——这两个数字常常相差数倍。同时 HUB 是单点，必须主备或双活部署，两台 HUB 最好分布在不同机房、接入不同运营商。
星型还有一个隐性代价：分支互访走"两跳"。门店之间一般没有互访需求，这个代价可以接受；但如果是多地研发中心之间的代码同步、视频会议，两跳叠加的时延就会被用户直接感知。
模式二：全互联（Full-Mesh）
任意两个站点之间直接建隧道。它消除了绕行，但隧道数量按 n(n−1)/2 增长：30 个站点是 435 条，100 个站点是 4950 条，300 个站点就是 44850 条，每台终端要维持 299 条隧道和对应的链路探测。这对终端的内存、CPU 和控制器的状态管理都是实打实的压力。
实际工程里更常见的是"按需全互联"：平时只和 HUB 保持隧道，当两个分支之间出现持续流量时，由控制器下发指令动态建立直连隧道，空闲一段时间后自动拆除。评估厂商时，要问清楚动态隧道的触发条件、建立耗时，以及在 NAT 环境下能否打通。
模式三：分层汇聚（区域 HUB）
按大区设区域 HUB，分支先到区域、区域之间再互联。它是星型和全互联的折中，适合全国连锁、多工厂制造这类站点多、区域特征明显的企业。区域 HUB 可以部署在自有机房，也可以部署在服务商的边缘节点或公有云上。
某农牧企业有 300 多个养殖场，分布在十几个省份，大部分场区只有一条宽带和一张 4G 卡。它采用的正是分层结构：养殖场按省接入区域汇聚点，区域之间走骨干，总部只保留管理与数据汇总。这样既把单个 HUB 的隧道数量控制在可管理的范围内，又让同省场区的视频监控回传不必跨省绕行（案例已脱敏）。
模式四：骨干网模式（私网底座）
分支 CPE 就近接入服务商的 SDN 骨干，长途段走服务商骨干而不是公网。这个模式要解决的，是 Overlay 本身解决不了的问题。
公网的问题不在于平均质量差，而在于波动和尾部。晚高峰跨省、跨运营商链路的丢包从千分之几上升到百分之一以上并不罕见。对 TCP 来说，丢包的影响是非线性的：按经典的 Mathis 模型估算，单条 TCP 连接的吞吐上限约等于 MSS/(RTT·√p)。在往返 40 ms、丢包 0.1% 的跨省链路上，单流上限约在 10 Mbps 量级；丢包升到 1%，上限会跌到约 3.6 Mbps。这就是为什么带宽明明够、业务照样卡——瓶颈不在带宽，在丢包和时延（理论估算，实际受拥塞控制算法影响）。
SD-WAN 能在多条链路里挑一条丢包少的，但如果所有公网链路在同一时段都变差，它也无路可选。骨干网模式把长途段交给可控的专网，SLA 才有了签约的基础。金融交易、核心生产系统、跨境业务通常需要这一模式。
模式五：混合组网
关键业务走骨干，一般业务走互联网，同时在公有云 VPC 中部署虚拟 HUB，让分支上云不必绕回总部。总部、IDC、多云并存的大中型企业，最终大多会走到这一步。
混合组网的难点不在拓扑，而在策略：哪些应用走骨干、哪些走公网、骨干故障时哪些业务允许降级到公网、哪些必须保持隔离。这些策略要能按应用、按站点、按时段配置，并且在控制台上看得见实际走向。
五种模式的演进关系
五种模式并不互斥。一个常见的路径是：从星型起步，随着云上业务增多加入云上 vHUB，随着跨地域业务变重再把关键链路叠加到骨干上。所以选型时真正要问的是：方案能否在不换设备、不重建网络的前提下，从一种模式平滑演进到另一种。如果模式切换意味着重新招标、重新部署，那三年后的你大概率要为今天的选择买单。
二、SD-WAN组网的12 个选型要点：每一项都对应一个真实的"坑"
下面 12 项按"底层网络—组网能力—安全与运维—商务与服务"四层组织。每一项后面都附上一个常见的现场问题，以及在 POC 里怎么验证。
SD-WAN 组网 12 项选型要点分层
SD-WAN底层网络：决定体验下限
1. 链路类型兼容与 NAT 穿越：至少要统一纳管专线/MPLS、互联网宽带、4G/5G 三类链路，并支持负载分担与聚合。更容易被忽略的是 NAT 环境：4G/5G 地址通常位于运营商级 NAT 之后，两端都在 NAT 后面时，隧道能否建立、靠什么方式建立（主动发起、中转节点、打洞），直接决定了门店和工地能不能"开箱即用"。POC 时专门拿一张普通 4G 卡测一次。
2. 有没有可选的骨干网：这是纯软件 SD-WAN 和"有网络资产的 SD-WAN"的分水岭。纯 Overlay 只能在已有线路里选优；能叠加服务商自有骨干的方案，可以把长途段换成确定性链路。判断方法很直接：请服务商出示骨干拓扑和节点清单，问清楚是否自营、跨省和跨境段分别怎么承载、骨干本身的冗余方式。
3. 上云路径：分支访问公有云是走公网、绕回总部，还是就近经专线直达云？能否在云上部署虚拟 CPE？预连接了哪些云？很多企业在做完 SD-WAN 后才发现，上云流量全部绕回总部出口，总部带宽成了新的瓶颈。
SD-WAN组网能力：决定网络好不好用
**4. 组网模式完整性与业务隔离：**对照上一节的五种模式确认支持情况。同时看多业务隔离：办公、POS、视频监控、IoT 是否能在同一套设备上划分为不同的虚拟网络（VRF），各自独立路由、互不可达。零售和制造企业在等保测评时经常被问到这一点。
5. 智能选路的粒度与速度：基础能力是按时延、抖动、丢包切换链路；进一步是应用级选路——识别 ERP、视频会议、SaaS，并为每类应用设定不同的质量阈值。要追问两个细节：链路探测的间隔是多少（它决定了发现劣化的速度），应用识别是否能在会话的首包或前几个包完成（否则一条连接建立后才发现选错了路，已经来不及切换）。
6. 高可用设计：看设备冗余、链路冗余、节点冗余三层。切换收敛时间和切换期间是否丢包，一定要在 POC 中拔线实测，而不是看宣传册。同时确认控制器失联时，边缘设备能否按最后下发的策略继续转发。
**7. 零接触部署（ZTP）：**设备寄到现场、上电联网即自动向控制器注册并拉取配置。要问清楚 ZTP 依赖什么：是否需要现场有 DHCP、能否只靠 4G 完成首次上线、设备认证靠什么（出厂证书还是序列号绑定）。上百个站点的企业，开站一次少派一个人，一年省下的差旅和工时往往超过设备差价。
安全与运维：决定能否长期管住
**8. 安全能力的融合方式：分支需要的本地安全能力（访问控制、上网行为管控、入侵防护）是设备内置、与安全厂商产品集成，还是放在云端完成？关键看网络策略变更时，安全策略能否同步生效，以及在一个平台上统一编排：**已经大量使用某家防火墙的企业，要重点确认能否利旧。
**9. 可视化与告警：**能否看到每个站点、每条链路、每类应用的实时质量与流量构成；告警能否对接钉钉、企业微信、邮件或现有运维平台。一个判断标准：门店反馈"网慢"时，运维人员能否在 5 分钟内说清楚是哪条链路、哪个应用、从什么时候开始的。
10. 开放性与互通：是否提供 API、能否与现有 ITSM 和监控系统集成；能否通过标准 IPsec 与第三方防火墙、公有云 VPN 网关对接。并购、合资、临时项目都会带来异构网络，封闭体系在这时的代价最高。
SD-WAN商务与服务：决定出了问题谁兜底
11. 责任边界。线路、设备、平台、运维分别由谁负责？回到开头的零售案例，晚高峰卡顿到底是运营商宽带的问题、SD-WAN 选路的问题，还是 HUB 性能的问题？如果三方各自负责一段，企业 IT 就会变成协调员。能由一家对端到端结果负责，是很多中大型企业转向服务型交付的直接原因。
12. 计费模式与三年 TCO。一次性买设备加线路，还是按站点、按带宽订阅？三年 TCO 至少要算五项：线路费、设备折旧、软件授权或订阅、运维人力、扩容与开站成本。只比较首年设备报价，是 TCO 失真最常见的原因。
三、按企业画像的组合建议
20 个站点以内、业务集中在总部机房：星型 + 纯公网 + 双链路（宽带加 4G/5G）通常足够。重点看 ZTP、NAT 穿越和运维可视化。
上百个站点的连锁零售、农牧、制造：分层汇聚或按需全互联，站点侧用标准化桌面级设备批量部署。重点看隧道规格、多业务 VRF 隔离、批量开站效率。
总部、IDC 与多云并存的大中型企业：混合组网。关键业务走骨干、一般业务走公网，云上部署虚拟 CPE。重点看骨干资源、多云中立和网络安全统一编排。某消费电子企业在三地办公之间就采用了这种模式：研发代码同步和视频会议走骨干，日常上网走本地互联网，三地同时直连两家公有云（案例已脱敏）。
有海外分支或跨境业务：必须单独规划跨境段。以中美为例，理论最优往返时延约 120–130 ms，普通公网到美西常见 170–220 ms、美东 240–320 ms，晚高峰更高（参考区间）。关键业务应通过全球骨干或合规跨境通道承载，并在 POC 中用真实业务测量往返时延与丢包。
四、几类服务商的组网特点（公开资料整理）
1. NaaS 服务商
以犀思云为例，它把 SD-WAN 与自有 SDN/SRv6 骨干结合。按公开口径，方案提供骨干网、纯公网、混合三种组网模型，端到端每一段都可以按需选择专线级或公网级；链路统一纳管专线/MPLS、互联网、5G 蜂窝与多链路聚合；终端覆盖硬件 uCPE、云镜像与移动客户端三种形态，单个 HUB 支持上千路 CPE 隧道并发，三级高可用切换收敛为毫秒级；骨干预连接 16 家主流公有云（均为厂商口径）。海外同类有 Aryaka（以自有全球骨干提供托管 SD-WAN 与 SASE）、Megaport（在其 NaaS 网络上以虚拟边缘承载多家 SD-WAN）等。这一类适合希望"组网、上云、跨境一张网"的企业。
2. 运营商
依托自有全国网络与本地化服务网络，标准化程度高、覆盖广，适合以国内站点为主、希望线路与组网一站采购的企业；跨运营商、跨境与多云场景的灵活度受标准化产品形态影响。
3. 设备厂商
如华为、新华三，控制器与路由器产品线完整、国产化适配成熟，通常由集成商或运营商交付，线路需另行采购。
4. 安全厂商
如 Fortinet、深信服，把 SD-WAN 内置在下一代防火墙中，适合安全诉求优先的企业；底层线路需自备。
5. 国际厂商
如 Cisco、Arista VeloCloud、HPE Aruba，在全球分支组网上积累深，适合跨国企业统一全球架构，国内落地通常依赖本地合作伙伴。
写在最后
SD-WAN 组网选型最容易犯的错，是把它当成"买一批设备"。设备只是载体，真正决定体验的是组网模式与底层网络的匹配，真正决定长期成本的是责任边界与演进能力。先画流量地图，再定组网模式，最后才谈设备与厂商——这个顺序反过来，返工几乎不可避免。
参考与依据
事实 / 口径 来源 组网模式与选型维度 行业通行实践整理 犀思云三种组网模型、链路与高可用口径 犀思云官网 syscxp.com（厂商口径） 华为/新华三/Fortinet/Cisco/Arista 方案形态 各厂商官网公开资料 TCP 吞吐估算（Mathis 模型） Mathis et al., The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, ACM CCR 1997 跨境往返时延参考区间 行业公开测量与本系列技术校验口径 说明：厂商信息为公开资料整理；标注"厂商口径"的数字以书面承诺为准，性能数字均为参考值，以实测为准。
