作者简介：晏志文
我们周围遍布着各式的网络：有 “七国八制”时代的PSTN[ PSTN：Public Switched Telephone Network，公共交换电话网络]，有刚成熟就衰落的ATM[ ATM：Asynchronous Transfer Mode，异步传输模式]，有局域网内的霸主802.3[ 802.3：IEEE 802.3，有线以太网标准]，有高速廉价的接入PON[ PON：无源光纤网络]，有日渐式微的SDH[ SDH：Synchronous Digital Hierarchy，同步数字体系]和传统WDM[ WDM：Wavelength Division Multiplexing，波分复用]，有攻城掠地的分组传输和OTN[ OTN：Optical Transport Network，光传送网]，有3GPP的蜂窝网络，有中远程的微波和卫星网络，有解决短距无线覆盖的WIFI，有面向物联网的M2M和NBIoT…伴生的协议更是名目繁多，单单解决广域网链路层互通就有PPP、Frame-Relay、HDLC等多种协议；各种技术也是互相取长补短，吸收SDH的OAM和交叉复用的PTN和OTN，提供类似传统传输切片的刚性管道的FlexEthernet[ FlexEthernet：柔性以太网]。
返本归真，网络解决的根本问题是互联互通，这是核心诉求，其次是链路质量，因为关系到业务体验，最后是一些增值服务，例如安全加密、日志审计、灵活运维。尽管如TCP从协议层面提供了重传确认、拥塞避免等机制，如无状态的HTTP的数据压缩、双工传输和相应的异步请求，都在试图缓解网络层面的无能为力，但伟大的网络工程师怎会就此甘心，所以也就出现了链路捆绑、冗余组网、广域网加速、流量调度、差分服务的QoS、综合服务的RSVP、综合内嵌差分的DS-TE，甚至还有应用和网络合作产生的CDN，通过推流拉流和内容下沉，在观看网红小姐姐直播的时候再也不用担心卡帧了。
广域网互联一直是存在分支机构的政企客户的刚性需求，无论直接购买L3V**/L2V**服务，还是SDH专线或裸纤，广域链路的互通曾经一直是运营商的天下，并且提供了安全隔离、带宽独占，至少也有QoS保证。随着互联网带宽的迅速增长，公有云或混合云天然需要Internet接入能力，还有IPSEC V**、 SSL V**的加持，分支间通过互联网互通在有些场景甚至成为一种必需，并由此催生了SD-WAN从技术到应用的迅速成熟。SD-WAN借鉴了SDN思想，将其从DC尤其是云计算应用迁移到了广域网互联，将互联控制从局端下沉到了C端。一时间探讨SD-WAN的声音不绝于耳，也许你也曾是那个“追风”的少年。看惯了太多技术的潮起潮落，抛却学院派的固执和血统论的诡辩，让我们抽丝剥茧的看看当前厂商宣传的SD-WAN方案还会面临哪些问题。
01
1、控制集中or分布
计算的流动性和自服务的模式决定了网络的高度动态化和个性化，网络天然需要向业务抽象。为了提高DCI或ISP网络的带宽利用率，需要网络具备全局视图和流量调度的能力。这些毫无疑问只有SDN能解决。但除了这些网络还有园区网、金融网、政务网、教育网等等，迫切的需求只是网络稳定和安全而不是像计算一样弹性，事实上大部分的行业网就是很少发生变化的。
控制集中和计算分布在互联网领域应用的炉火纯青（除了像区块链和GIT这样的异类），其实在电信领域中也不新鲜，移动核心网或是下一代网络NGN就是代表。没有一种技术可以通吃场景，抛开场景谈技术也是空中楼阁，控制面集中的前提是控制流要足够的简单。路由交换上百种的功能和特性，通过复杂的控制面才能支撑起成千上万台的设备组网，一方面如此多的功能很难抽象，大量的协议集中处理消耗了网络带宽，另一方面协议处理伴随着网络时延，网络的健壮性严重依赖控制器的稳定性和安全性。于是你看到打着“简化网络复杂性”旗号的布道者们在有意的退避很多的网络功能，锤着胸膛呐喊着网络AI赋能的有多少还只不过是PPT上的胶片。
分布式的路由计算也没有那么不堪，相反你会发现大量的精巧设计：OSPF通过划分区域拆分了性能压力，ISIS提供了区域热切分的扩展能力，通过CSPF依然可以完成去中心化下的端到端带宽保证，链路状态在网络中洪泛然后本地计算，没有“劳民伤财的工作量证明”最终也实现了全网共识。路由交换技术中也有很多控制面集中的案例，解决IBGP水平分割的路由反射，实现策略集中部署的GDOI[ GDOI：Group Domain of Interpretation，组解释域，一种IPSEC多播密钥管理协议]，PIM-SM中的BSR和汇聚点RP等等。于是有了边缘云、有了MEC，计算并不一定只适合集中，网络控制也一样。索性可以这样做结论SDN的出现不是为了颠覆什么，而是对现有网络的某些场景的功能升级或补充。
SD-WAN中的控制器的安全是全网可提供稳定服务的关键，分布式、Scale-OUT、异地灾备、同城双活，即使具备了全部能力，还要考虑防DDos，防社工，防拖库，防安全渗透。除控制器外，每一个CPE包括POP的VCPE都可能成为打开全网控制能力的缺口，区域边界在从前的一个互联网出口蔓延到了全部网络设备。除了安全要进行分布式，由于上网流量的本地出局，行为审计也需要实现分布式。具体采用集中控制还是分布控制的方式不能绝对化也不能一刀切，还是需要针对具体的场景需求。
02
2、提升网络体验的方法
国家一直奉行提速降费的政策，但带宽上升的同时，P2P应用，视频、直播等流媒体也在加速的消耗着，就像摩尔定律的魔咒一样，加上运营商的策略，将上行带宽卖给高价值客户，网络带宽依然存在着供求矛盾。
ISP内部的互通包括走城域网的市内互通，走省骨干网的城际互通，和走国干的省际互通，一般情况链路质量比较有保证。运营商之间的互通需要跨越AS，而且都是在骨干网对接，加上互联的带宽有限，这条路径的链路质量往往很难保证。对于国际流量需要先到国际互联网出口局，然后从国家互联网出口至国外，这条路径的链路是最长的质量也是最差的。
为了提升网络体验陆续出现过很多方法，这些方法传统网络能用，SD-WAN一样可以：
1）服务端多线接入 智能DNS
服务端多线接入，通过智能DNS判断接入用户的归属ISP，返回相应ISP的地址给客户端，避免了AS穿越问题。
2）具备BGP专线的IDC机房
服务端接入具有BGP专线的IDC机房，使用IDC的公网地址，IDC与三大运营商通过BGP高速互联，服务端只需要一个IP即可保证三个网络的访问质量。
3）CDN服务
通过CDN边缘节点的缓存和全网调度机制，将域名的CNAME指向自己的CDN域名，即可使用CDN服务，实现内容就近获取。尤其是热点流量，能够达到极高的缓存命中率，效果非常明显。
4）边缘接入
电信、阿里这些有海外接入业务的公司企业通过自建POP点，POP点采用自有或租赁的光缆连接到国内，实现境内到境外的网络延伸，向驻外用户提供和国内互通的V**及互联网服务。
（图片取自网络，如有侵权请联系删除）
03
3、SD-WAN的流量模型
上文阐述了几种传统网络提高访问体验的方法，下面再看常见SD-WAN流量模型遇到的一些问题：
1）HairPIN问题
采用POP点接入方式SD-WAN要做这样几件事，部署边缘节点提供接入能力，建立以POP为接入节点的骨干网，这个骨干网可以自建、租用、Overlay或者混合，剩下的工作就是用户的最后一公里的就近接入和骨干网的流量调度，到目前为止看上去还算美好，但是不是所有的流量都有必要从POP接入，经过SD-WAN服务商的骨干网选择一条“满足SLA”的路径？
前面提到过只要不跨运营商AS，跨城域网的城际或省际线路也未必那么不堪，城域内的互联互通可能效果更好，为什么不走直接链路呢？下图的Hub-Spoke模型产生了流量绕行，才会有了DMV**技术，类似的还有园区网L3下移，VxLAN的分布式网关、NAT Mapping等等。发卡流是一种极不经济的做法，至少也要检查下直接链路是否能够满足需求。
2）最后一公里问题
POP解决最后一公里接入，通过探测选择最佳接入点，这是几乎所有SD-WAN厂商都能提供的能力。上文说过普通带宽的上下行带宽严重不对等，上行带宽在宽幅的波动，这最后一段的互联网宽带是不适合HQ[ HQ：Headquarters，总部]这种对外提供以流量输出为主的服务的，与是否接入POP无关。上行输出不稳定意味着无固定的拥塞识别点，本地无法进行QoS排队保证业务流量，甚至限速都很难确定一个有效的水线。
3）链路检测和动态选路
链路质量的几个判定指标时延、抖动、丢包率，最终的业务体验应该是建立在端到端链路上的积累效应，链路质量劣化未必就能依靠源端的限速能够有效解决。常见的检测方式为端到端检测，其中又分为独立报文检测和带内检测，独立报文检测除了额外开销外和业务流量路径未必完全一致会导致检测误差偏大，伴随着业务流的带内检测更能精准的反应承载链路的质量。精准的基于流的测量后才能指导选路的决策，整个过程就像一个负反馈系统，流量选路作为输入，链路质量作为输出并引入负反馈，系统理想的性能指标是快速收敛稳定。但现实情况是流量具有突发和不确定性，控制器对网络观察的颗粒度越粗，这种不确定性的影响就越大，于是这个系统又被叠加了一个不稳定的“噪声源”，当然当带宽容量和备选路径比较充裕时这种影响不会明显。除此之外往返路径的一致性，流量定向的技术选择，业务流量的不对称性等等都需要仔细考量。
4）内网穿透解决POP Bypass问题
上面提到了直连链路如果满足条件应该避免边缘节点绕行，没有公网地址怎么打通V**呢？通过TCP/UDP打洞来解决内网穿透问题在P2P领域早已不是什么新鲜技术，只是针对不同类型的NAT（Full Cone NAT、Address Restricted Cone NAT、Port Restricted Cone NAT和Symmetric NAT）难度依次增强。下面就以较复杂的情况Port Restricted Cone NAT为例来说明内网地址的互通问题，即使是在同一个NAT网关甚至多级NAT这种方法依然适用，对于两边都是Symmetric NAT这种最极端情况依然有解决方案。
如上图所示内网设备和辅助服务器之间维持一条蓝色的控制连接用于信息交互，这条连接的地址端口等信息图中忽略。第①步内网的通信双方分别使用监听端口（500）作为源端口建立到辅助服务器的辅助连接（橙色），辅助服务器上看到了双方NAT后的地址和端口（5000），然后将信息通过蓝色的控制连接发送给双方。第②步由一方（PC2）继续以监听端口（500）作为源端口发起到对端公网端口（5000）的建链，在NAT2上生成了相应的表项，由于NAT1没有表项就在Inbound方向检查地址端口时将报文丢弃。第③步由PC1使用监听端口（500）作为源端口发起到对端公网端口（5000）的建链，在NAT1上生成了相应的表项，到达NAT2时由于②中生成的表项还未老化受限端口检查通过，最终实现了内网设备的直接互通。
SD-WAN应该和传统网络取长补短、因地制宜，无论从成本还是工程化角度考量，除了需要克服上文面临的问题，流量模型也应该更加的多元化。
04
4、小结
本文简述了SD-WAN方案面临的的流量模型、网络带宽等方面的问题，后面将对企业网组网、混合云组网、与传统网络的融合、商业模式等方面继续探讨。
【投稿】
欢迎SDN、NFV、边缘计算、SD-WAN、TSN、5G 网络切片等网络方向的观点类、新闻类、技术类稿件。
联系人：04&07
投稿邮箱：pub@sdnlab.com
详情请参考：SDNLAB原创文章奖励计划
长按二维码关注
注：本公众号允许其他公众号或网络平台进行转载，但任何形式的转载需注明“文章转载自SDNLAB公众号”相关字样
