最近这一两年，SD-WAN在业界有点甚嚣尘上 ，而且一般都把SD-WAN视为是要取代MPLS VPN的‘掘墓人’ ，认为MPLS VPN早晚要被SD-WAN所淘汰。恰好本人多年前曾参与MPLS VPN产品的开发，最近又与SD-WAN瓜葛匪浅，所以在此也凑个热闹反思一下这两种组网技术的前世今生 。
2000年以后 ，MPLS技术在运营商网络中开始规模部署 ，特别是其天然与VPN业务相关，使得MPLS VPN成为当年政企组网市场上的宠儿 ，当初其发展的对照物 ，主要是点到点的传输专线，总体来说 ，MPLS VPN相对于之前的传输专线 ，其优势的本质是产生了‘网’的概念（一点接入，全网任意别的点都可达） ，而非传输专线一直是‘线’的连接（一头进入 ，必须另外一头对应出去），给客户组网带来了不少的好处 。具体来说 ，从客户的视角 ，主要如下：随着一个企业/单位内部不同站点间互相通信需求的增加，Full Mesh（全网状）或者部分网状组网的情况越来越多 ，此时 ，如果是采用点对点的连接，那么就必然面临N2的连线问题（即 ，N个站点需要N*（N-1）/2条电路互联） ，而采用MPLS VPN时接入电路则只有N条（每个站点接入到运营商网络的局端设备后，默认是和其余的N-1个站点都连通的）。这在三个点组网时 ，两者所需的电路数是没有差异的 ，如下图1所示。
图1：三点间full mesh组网时，传输专线与MPLS VPN在接入电路上无差别
但是 ，如果在四个点或者四个点以上组网时 ，差异就非常明显，如下图2所示 。因为是以线为单位进行连接构建的原因 ，此时四个点做full mesh的传输专线 ，就不得不需要6条线互联；而以网的概念构建连接的MPLS VPN，四个点还是4条接入线（局端设备间虽然还有full mesh的虚拟连接，但是可以不实际占用/消耗带宽） 。
图2：四点间full mesh组网时 ，MPLSVPN所需的接入电路较少
而且 ，组网便利性的最明显体现之一，在于增加一个站点的情况（如 ，企业新扩展了一个分支机构 ，或者收购一家别的小企业）。如下图3所示，如果是传输专线 ，需要增加对现存四个点的4条电路 ，而如果是MPLS VPN则只需要补充1点的接入电路即可 。一般来说，这不仅大大简化了对运营商电路资源的需求 ，也减少了对企业站点侧网络设备广域网（WAN）侧端口占用的需求 。
图3：增加第5个点是 ，MPLS VPN只需要补上1条接入电路即可
在传输电路情况下 ，任意两点间的带宽是固定的 ，即站点A-站点B的链接上，如果A点是2M，那么B点一定也是2M ，假设A是一个中心点（hub） ，存在类似B这样的分支点（spoke）有10个，那么A点所需的就是10*2M=20M带宽（当然 ，如果用个公式表达 ，应该是,这里简化起见，把每个分支点的带宽都设为一样是2M算了）。此时 ，即使在某条链路上没有流量产生（未必实时都有通信的流量 ，或者说一定会把带宽跑满），但是这条2M的带宽还是被占用了不能被别人所分享 ，如下图4左侧所示 。
而MPLS VPN中 ，因为本身不存在点对点的物理电路的概念，所以完全可以考虑对带宽进行复用 ，也就是说如果不出现10个分支点同时向中心点满额发送流量的情况（这种情况也比较少见） ，那么中心点的带宽就不需要是分支点之和 。当然，为了以防万一，需要考虑配置QoS ，以便一旦发生流量超过端口速率时怎么进行低等级应用报文的丢弃（也就是说 ，省钱也有一定的代价，此时会引入令人讨厌的QoS配置了）
图4：MPLS VPN组网时 ，hub点的带宽一般不会是spoke点带宽的总和
上述两点其实对比的对象都是专网专线 ，MPLSVPN在本质上和传输专线一样都是运营商的专网，而且接入段也是用了专线 ，还是与互联网基本上完全隔离的一个组网形式。只是相对于过去的传输专线 ，对于客户而言有上述组网便利性和省钱的好处，同时自身网络上因为MPLS/IP的特性 ，可以充分利用到链路/带宽复用一定程度建网成本也会低于传输网络 。其实还有一个很重要的考虑点 ，就是和基于互联网条件的企业内部组网（也就是说和IP Sec VPN/SSL VPN等基于Internet接入的组网）相对比 。
这里需要总体来看，企业的连接型需求不外乎两大场景 ，一是上网（可以简称为Internet） ，能够上互联网冲浪或者让互联网用户访问企业；二是组网（可以简称为Intranet），把不同的分支点连接起来实现内部数据的交互。上述的MPLS VPN也好，传输专线也好 ，从业务形态上 ，只是解决组网（Intranet）的需求，对于上网（Internet）的需求还是需要另外拉线来解决的 。可以简单用下图5来表示 ，其中站点A和站点B都另外拉线接入了互联网（理论上每个点都可以这么干 ，这里简化了一下示意而已），这样最大的好处是把Intranet和Internet事实上做了隔离 ，特别对于Intranet来说安全和带宽的保障都很容易做 。
图5：MPLS VPN本质上只解决Intranet问题
当然 ，长期以来，技术上也有很多不把Intranet和Internet在物理电路层面区隔开的做法 ，具体实现的技术方案有很多 ，我这里也只做一个简单的示意，如下图6所示。基本的原则就是在互联网接入电路（图中的黑实线）的基础上 ，再在不同站点间起一些隧道（图中的黑虚线） ，一般是安全加密的隧道（比如IPSec），此时可以把互联网连接视为一个底层的基础网络（所谓underlay），然后在此基础上再overlay一个虚拟网络（Intranet）。
图6：基于Internet也可以实现Intranet
可见 ，基于互联网的Intranet网络 ，主要面临两个问题，一是安全 ，虽然可以有上述IPSec之类的安全加固方案 ，但是从组网的角度，如果是企业内部的重要数据 ，为何不在链路上就走‘专用通道’呢？就好比领导要出行 ，有专车可用的话，干嘛让人去坐公交/地铁？二是带宽（QoS）保障 ，毕竟互联网设计的初衷并不是一个端到端质量保障（承诺）的网络 ，一旦发生拥塞，QoS指标（如 ，时延）会大幅下降 ，严重影响各种应用和体验 。
为此，综合来看，MPLS VPN作为对传统传输专线的一种升级和替代 ，再政企组网（Intranet）市场上受到了热忱的欢迎 ，曾经连续多年有30%以上的收入增长率（考虑到单位带宽逐年降价的压力，实际增长更可观） ，根源还是给企业客户提供了更佳性价比的组网方案 。
虽然 ，MPLS VPN给企业组网提供了相对于过去传输专线更好性价比的选择，在技术层面存在一定的共享机制 ，但是其本质上来说 ，还是基于专网提供的业务，在技术实现上还是基于专用网络基础设施的underlay方案。与之相比 ，上述图6所示的基于互联网接入的overlay方式的组网方案 ，如果能够解决安全和质量的问题，必然在组网成本会上大幅的降低（至少对于客户来说 ，正常市场的价格 ，组网专线-不论是MPLS还是传输，总是要远高于互联网接入） 。
从承载通道的安全性角度，IPSec/HTTPS等已经解决了隧道加密的问题 ，如果是信息安全层面的问题 ，也不该由网络来解决 。这里举个例子，如果用HTTPS来访问国外的资源 ，经常会遇到连接速度放慢的情况 ，从中不难发现一定是某些机制在起作用，那么反过来我们可以推论出 ，这种加密真的是很可靠的了：）
所以 ，如果企业无法保障某个通信端到端与互联网的隔离，那么连接通道承载在互联网上所存在的被攻击的威胁已经不应该成为其顾虑的重点。
这么多年以来 ，宽带市场的不断提速总体上已经使得互联网的质量得到了极大极大的提升 ，在网速大幅提高的前提下结合CDN等多种辅助手段，现在已经很难找出什么应用一定不能承载在互联网之上了 。特别是SPDY 、QUIC、BBR、SRT等等不同协议的出现 ，即时承载网络不做进一步的提升 ，应用的两头双边加载一下这些新协议，也能很大改善应用的质量 。
所以，可以说互联网还是没有质量保障的网络 ，但是并不意味着其质量一定不可靠。
正是基于上述两个问题的解决（至少是缓解） ，上图6中那样的overlay的Intranet终于迎来了其新的发展阶段，尤其是最近比较火的SD-WAN 。SD-WAN的具体实现方案 ，在技术层面有很多种 ，我在此也不一一赘述，用下图7大致示意一下吧 。
1.稳定可靠的廉价互联网接入：如图7中的黑色实线所示 ，这是SD-WAN竞争力的基础 ，随着宽带质量的稳定（如上述分析）和价格的跳水（大家日常应该深有体会），其作为Intranet的基础（undelay部分）已经具备了。
2.部署在客户侧的CPE和网络侧的SDN控制器：这个CPE可以是物理的（目前多数这种情况） ，也可以是虚拟化的（未来应该能占据半壁江山） ，关键作用是在控制器的‘指导下’与别的CPE建立安全可靠隧道，解决Intranet安全和可达的问题 。
3.按需部署的网络侧资源：很抱歉没有在上述图7中详细表达出来这个意思 ，主要是想说除了CPE和控制器外 ，还会有一些配合的系统或资源需要按需灵活配置 。比如解决跨网问题（跨运营商互联网质量一直不好），SD-WAN的服务商可能需要在每个运营商网内部署一些网关（一般在云/IDC内）用以解决选路和中继的问题；而且，SD-WAN的服务商应该相对比较短周期的（每周 、每月）来监测这些资源的部署效果（如 ，对于该运营商网内CPE侧的QoS质量） ，并予以动态的调整部署的位置和数量。
可见，SD-WAN的本质是基于可靠低价的互联网接入 ，结合SDN等先进技术手段 ，实现比传统传输专线和MPLS VPN等更佳性价比的组网服务。所以，虽然目前来看 ，SD-WAN还暂时不会冲击到存量的MPLS VPN/传输专线的存量市场 ，主要还是增量的带宽和连接需求为主（如，MPLS VPN扩容带宽需求 、备份电路需求挪到SD-WAN） ，但是未来就不好说了……
在这里 ，我还想谈谈我个人对于业界某些SD-WAN论点的不同认识（或者不完全一致的认识）：
1. SD-WAN的核心不在SDN，在于互联网接入 。从技术的角度 ，大家深入研究SDN是对的 ，比如其在路由选择方面的优化，在应用感知方面的结合等等，但是我们一定不能本末倒置 ，SD-WAN在产业上要成功 ，第一要素一定不是科学家发明了什么，而是互联网的普及和网络质量的可靠 。
SDN也好 ，SDN控制器也好 ，只是提供了一种网络组织和资源配置的工具和方法，本身没有改变网络业务生产的本质。打个比方来说 ，SDN或者SDN控制器相比于传统的或者现行的网管等工具 ，就像是引入了天然气或者燃气灶来替代过去的煤饼炉或者柴火灶，其方便了火候的控制、简化了火力的接续 ，有助于厨师更好的做菜 ，但是并不会因为炉具的改进就保证能做出好吃的菜来 。一个不会做菜的人，你给他全世界最好的燃气灶也是白搭 。
目前的SD-WAN业务提供时 ，有一个前提是客户自己已经开通了互联网接入电路（当然 ，如果是电信运营商提供的SD-WAN服务，该互联网电路可以是同一家运营商提供的，但是在流程上还是要先开通互联网接入电路） 。所以 ，目前所谓的快速开通 ，是指的作为underlay存在的互联网电路存在前提下，overlay部分的网络开通的时长 ，所以如果拿这个来和传统的MPLS VPN或者传输电路做比较 ，是不对的，因为后两者的开通瓶颈主要是在接入段电路的具备上 ，如果是局端设备的配置开通（比如 ，MPLS VPN中在PE设备上配VRF）也完全可能做到很快 。
当然，互联网接入电路相对于专线接入段确实也有开通快一些的体验 ，这也得感谢这些年宽带的大发展 ，FTTH/B的盛行，使得互联网接入的接入段基本上不需要做资源核查 ，而且还有“当当慢”之类的要求在做保障。
3. SD-WAN服务商从应用服务商开始是合理的 ，但不是绝对（应用不是杀手锏） 。目前业界很多SD-WAN服务商是从应用提供者（如，3V：Versa 、Viptela 、Velocloud）转型/拓展而来，是一种正常现象 ，因为它们可以近水楼台 。但是应用不完全就是与客户黏性的必然 ，或者说应用服务对于Intranet的需求而言，目前还是充分非必要条件。SD-WAN的核心还是上述分析到的 ，可靠安全的高性价比组网 。
4. 线下服务和渠道仍然是电信运营商做SD-WAN的优势 。虽然技术层面overlay是目前SD-WAN的优越性所在 ，但是擅长做underlay的电信运营商也并非没有做SD-WAN的可能。比如，上面分析到SD-WAN部署的三个要点 ，从技术实施上哪个是电信运营商不能做的？或者说 ，现有SD-WAN服务商能做的，为什么电信运营商就不能做？当然 ，机制体制方面的存量制约 ，可以另外再谈。
从目前很多SD-WAN服务商希望找电信运营商合作的需求来看，虽然overlay在一定程度上做到了“轻运营 ” ，但是很多与underlay相关的事情 ，还是需要借助电信运营商的资源和禀赋才能做得更好 。比如，电信运营商存量的海量客户资源、数以万计/十万计的线下服务队伍 、宽带互联网服务的收费渠道等等，都是人家所缺乏的 。
我想 ，SD-WAN其实是一种更加深刻的网络供给侧改革 ，其本质是将overlay的理念进一步运用到基础网络连接层面，不仅在基础设施的组织和供应上 ，更是在服务形式和组织流程上的结构性颠覆。对此 ，电信运营商面临的是传统以underlay为基础的网络构建和运营体系如何进行应对，是否需要改变的问题？虽然支撑运营商组网连接产品（主要是政企）也有一些年头 ，但总体上我还是一个小学生 ，对于产品和服务的认识比较肤浅，不过多年来也不只是坐而论道 ，也勇于承认和反思自己犯过的错 ，所以也大胆谈谈对于这一问题的几点思考：
1. 摆正战略对象，不要瞄准OTT ，眼光主要盯住友商这些年运营商大谈OTT ，很多方面都对标OTT，我想了解和参考人家的优势和优良做法是应该的，也是必要的 ，但是运营商一定要看清OTT的基因是运营商学不来的 ，或者说运营商根本上是不可能削足适履的 。这么多年以来，运营商基于underlay建立的重资产的基础设施 ，以及配套而生的重运营的体制流程 ，不是没有价值的 。至少在基础网络层面，OTT的资产包袱就没有运营商重 ，运营层面就更是了 ，某种意义上讲这是OTT的后发优势，如果哪一天人家的资产做重了 ，情况也不见得好到哪里去……简单一个例子 ，在网络连接市场，新进入者可以尽量参照成本进行定价 ，而运营商有那么多“转移支付 ”的压力 ，就不可能参照，最多根据市场竞争进行调价。所以运营商的竞争对象一定是同类项，也就是我们的友商 。
2. 网络能力尽快产品化 ，快是唯一可行的‘差异化’产品生存和立足的根本 ，必须是“一切从客户出发/满足客户的需求+不断运营迭代优化完善” 。在传统以话音为主要代表的相对封闭的环境下，运营商的网络能力=客户必须接受的电信产品 ，而在现今以互联网为核心的充分开放的背景下 ，运营商的网络能力≠客户愿意买单的通信产品，所以 ，如何使运营商的网络能力真正产品化 ，而不是停留在发文上，是我们必须解决的问题。
这其中 ，最重要的还是快 ，特别是面向市场、面向客户真正的快，技术手段 、解决方案没有什么学不来的 ，差异化的只能是通过迭代运营持续深化踩过的坑和获得的血淋淋的教训 。举例而言 ，为什么MPLS VPN在国内运营商中我们做得最好，是一个简单的Multi-VRF功能搞死了IT和单式 、是一个复杂的BGP路由限制推动了思科和华为……才使得其在同类产品中能够有相对优势 。
3. 简化网络+减少‘技术含量’，把企业当成自己家理论上 ，网络可以做得复杂 ，而产品则做得简单（客户容易上手、客户经理容易销售），但是事实上 ，一旦我们把网络做复杂了 ，往往伴随而来的就是产品的复杂。以MPLS VPN如果是通过城域网跨域接入CN2为例，城域网和CN2因为有两条Option A电路 ，所以在此时还需要客户额外提供两对互联IP地址（私网）给我们 ，否则下单就走不下去 。这样的问题，95%以上的客户和客户经理都是懵圈的……
还有很重要的一点 ，技术方案本身都是没错的 ，如何选择是有优劣的，网络类的产品的好坏往往被技术选择所左右 ，而我们在做技术选择时 ，一定要扪心自问，如何我是客户/客户经理我会怎么看？如果这个方案是实施在我家的，我会怎么选？
前一段看到网上有篇文章 ，大意是运营商很难做2B，我个人也有一定同感 ，其实从客户群的角度 ，我们当然有2B，但是从产品来看 ，我们还是以2C为主 ，2B其实更多的还是依靠ICT项目的方式来做（以后是DICT项目？） 。
其实运营商的产品一直强调的是标准化，这和2B是天然有隔阂的 ，尤其是运营体系和流程 ，也是与定制化的2B需求不能很好适配的，所以从这个角度 ，一方面可能不得不对存量的运营维护队伍对大手术（如果真的要转型的话） ，一方面还是要借助内外部多种力量（如，集成体系+外包）来解近渴。关于SD-WAN和MPLS的争论，SD-WAN和SDN的关系以及运营商是否要改革有很多说法 ，小编搜集了一些网友的看法:
版权声明
本文所呈现的内容仅为快连 VPN 相关创作者或发言个体的观点表达，并不等同于快连 VPN 平台的官方立场
观点往往是基于个人认知、经验或特定视角形成的主观判断，具有一定的局限性和个性化特征，可能随信息更新或场景变化而调整。
而快连 VPN 的立场则是平台基于合规运营、用户权益保障及行业规范确立的稳定原则与价值取向，是经过审慎考量的系统性主张。平台尊重个体表达观点的权利，允许在合理范围内进行交流探讨，但这并不意味着对所有观点全盘认同。特此明确区分，旨在让用户清晰辨识内容属性，避免将个体观点误读为平台官方态度，确保信息接收的准确性。，未经许可，不得转载。
