亚马逊AWS官方博客
基于互联网的跨区域互连网络性能优化
一、背景
亚马逊云科技出海客户希望将他们在亚马逊云科技中国和海外区域的数据中心进行互连。但由于中国和海外区域间无骨干网络连接，因此互连面临着诸多的挑战，其中之一就是出海线路的选择。DX专线具备高品质，但因为国际线路价格昂贵，令很多客户望而却步；互联网线路虽然价格便宜，但我国的国际互联网出口往往会出现随机丢包，甚至持续丢包的情况，有时导致到海外区域的延时比较大。在这种弱网络的环境下，带来最大的影响是网络吞吐量会出现断崖式的下降，在后续的测试验证中我们会看到这一点。
本文将从TCP协议出发，对弱网环境吞吐量受到影响的原因、如何对网络吞吐量进行优化、本例中采用的思科SDWAN解决方法如何帮助出海企业搭建旨在优化网络吞吐量的网络架构，进行全面的介绍，并以具体的测试为基础，对所采用的核心技术和具体的配置，进行详细的说明。
本文中的测试拓扑及所涉及到的网络组建说明如下：
测试中，我们模拟国内和海外两个区域，每个区域都部署一台思科SDWAN路由器Catalyst8000v和一台虚拟机，通过安装iperf3来模拟TCP流量。同时在国内站点中安装一台WAN-EM，用来模拟互联网上的延时和丢包。
二、技术分析
这部分内容将从TCP协议的三次握手以及拥塞控制机制入手，分析延时和丢包两个指标对网络吞吐量造成影响的原因，以及如何对网络吞吐量进行优化。在进入到具体的技术分析之前，让我们通过测试来展现丢包和延时对网络吞吐量造成的影响有多大。
在初始网络环境下，对TCP数据流进行测试，测试结果为单向吞吐量为84M，测试结果见下图：
当我们将网络延时增加到150ms后，吞吐量直线下降到了单向7.97M，测试结果见下图：
我们在网络延时150ms的基础上，进一步增加5%的丢包，此时吞吐量下降到了单向309k，测试结果见下图：
由此我们可以得出结论，网络上存在延时和丢包都会对网络吞吐量造成巨大的影响。
网络的延时和丢包为什么会对网络吞吐量有如此大的影响呢？让我们回归基础，对TCP协议进行一个回顾。
1、TCP三次握手
所有TCP连接的建立都是从三次握手开始的，server和client在传输数据之前，双方必须协商TCP连接的sequence number。
SYN：client随机选择一个sequence number x并发送SYN报文
SYN ACK：server对client的sequence number加1，同时随机选择server侧的sequence number y，发送SYN ACK报文。
ACK：client对x和y都增加1，并回复给server，这时client可以开始发送数据。
这样就完成了TCP的三次握手，并建立TCP连接，开始传送数据。 如上图中，如果server与client之间的单向延时为28ms，在传送数据之前，至少需要等待56ms，延时越大等待时间越长，这就是大延时对网络吞吐量造成影响的根源。虽然看起来这部分的延时影响对吞吐量的影响并不大，因为一旦TCP连接建立，就可以持续的传送数据。但试想如果需要传送多个小文件，或者网络中存在丢包导致TCP报文重传，网络延时的影响就会变大。这个现象也会在后续的测试中得到验证。
2、拥塞控制和避免
TCP拥塞控制和避免机制是TCP协议的重要组成部分，由flow control、congestion control和congestion avoidance三部分内容组成。
flow control是TCP协议为了避免发送端由于传送大量数据而导致接收端过载而设计的机制，接收端可能由于负载过高或系统分配的buffer空间等问题，每次只允许接收一定范围的数据量，TCP连接的两侧会协商接收窗口参数（RWND），用于设定每次允许接收的数据报文的大小。
虽然flow control机制有效提供了server/client之间的流控问题，但server和client并不知道underlay网络的可用带宽有多大，为了避免由于一次性发送大量数据报文而导致的网络拥塞，TCP协议又设计了慢启动机制（slow start），系统第一次发送报文的数量是受限于系统的发送窗口（CWND），不同于RWDN的是，CWND不需要在server和client之间协商，而是遵循操作系统的默认设定，目前主流的操作系统CWDN默认设置为10 segment（1 segment = 1460 bytes）。当接受端收到所有的数据包后，会以ACK报文来确认接受到数据包的多少。假设没有拥塞或丢包，发送端会进一步加大CWND（通常会加大一倍），直到拥塞或丢包出现，CWND会减半。通过这种方式，TCP会通过持续调整CWDN大小的方式，来实现针对网络拥塞的控制。
下面我们就以一个例子来说明从TCP建立到传送数据完成的完整过程。
假设网络的单向延时为28ms，server和client的RWND设置为65535 bytes，初始化CWND为10 segment（10 * 1460 bytes = 14KB），server处理请求的时间为40ms，需要发送文件的大小为64K，网络没有丢包。
如上图，TCP连接建立时间为56ms，server接收到GET请求的时间为84ms，经过处理后，从124ms开始传送数据，经过三个round trip，完成了整个文件的传送。也就是说，传送64k大小的文件，共耗时264ms。从这个例子可以看出，网络延时越大，传送相同大小的文件耗时越长，反映到网络吞吐量上就是吞吐量越低。另外，一旦出现网络丢包，会导致每次发送数据包窗口变小，甚至会出现TCP连接重新建立的情况，会进一步影响到网络的吞吐量。
TCP拥塞避免和流控算法是内嵌在操作系统内核中的，随着操作系统的持续更新，TCP拥塞避免算法也有了多个不同的版本，以Linux为例，到目前为止，已经出现了如Reno、Vegas、New Reno、CUBIC等多个算法，目前默认的TCP算法为CUBIC。更新TCP拥塞机制的原因也是为了更有效地利用带宽，更大限度地提高吞吐量。
TCP协议的拥塞避免和流控机制的基础是假设网络带宽不足，或者server/client内存不足而设计的，并以丢包作为网络拥塞出现的一个特征。在协议设计初期的80年代，这样的假设显然是合理的。但当前的情况出现了巨大的变化，网络的带宽和服务器的内存显然已经不再是瓶颈，经典的TCP拥塞避免机制已经极大地影响了网络带宽的利用率。
3、BBR
从经典的TCP协议可以看到，系统发送数据量的大小依据是RWND和CWND，并根据系统设置和ACK动态调整窗口的大小，只有当发送端收到接收端ACK报文后，才会增加发送窗口。这里就存在一个明显的缺陷，如果每次发送的数据量远小于网络带宽能够承载的数据量，发送端每次都需要等待ACK才能再次发送数据，这也就变成了TCP无法有效使用网络带宽的根源，从下图中可以明显的看到这个问题。
这个问题有多明显呢？让我们用一个例子来进行说明，假设系统发送窗口为16KB，网络延时为100ms，网络的吞吐量为：（16KB * 8 * 1024） / 100ms = 1.31Mbps，不管当前可用的网络带宽有多大，由于发送窗口的限制，网络的吞吐量也只有1.31M。显然，通过调整发送窗口是可以有效的解决这个问题的。但发送窗口设置为多大是合理的呢？让我们进行一个简单的计算，假设当前网络可用带宽为10M，网络延时为100ms，能够充分利用带宽的发送窗口大小为：10M / （8 * 1024） * 100ms = 122KB。这个公式就是BDP（Bandwidth Delay Product）= Bandwidth * Latency，即网络中一次性允许发送的最大数量的数据报文。可以把网络想象成一根水管，网络带宽为水管的截面积，网络延时为水管的长度，那么一次性发送的数据就是能够灌满水管又不会溢出的最大水量。这样，接收端就可以持续的处理数据并恢复ACK，发送端也不再需要等待ACK后再进行下一次的数据发送，而是可以持续的发送数据。
以上的机制就是经典的BBR（Bottleneck Bandwidth and Round-trip Propagation Time）拥塞控制算法的基础，BBR是Google在2016年发布的一种全新的拥塞控制算法，其目的是允许系统尽可能多的发送数据并利用网络带宽资源，而不像如传统的CUBIC拥塞控制算法那样，逐渐调整发送窗口，缓慢的增加数据发送量。BBR采用的机制是尽快的将发送窗口调整为BDP，并尽快占用网络资源，那系统就必须计算出当前可用的网络带宽（Bandwidth）和网络延时（Latency），下面这张图就是经典的BBR原理：
在图中，上图Y轴为round-trip time，下图Y轴为delivery rate，也可以理解为可用的网络带宽，X轴都是amount data inflight，即在网络中传送而没有被接受端ACK的数据。
图中分成三个阶段，分别为app limited、bandwidth limited和buffer limited，app limited阶段为数据发送量没有达到BDP的阶段，这时数据发送速度会持续增加，同时round-trip time并没有变化；bandwidth limited阶段为发送数据量达到BDP，但中间网络设备的buffer还未填满的阶段，这时数据发送速率达到恒定，同时round-trip time由于buffer的作用，会持续增加；buffer limited阶段为途中网络设备buffer溢出，造成丢包。
BBR会按照上图的原理，持续的探测round-trip time和bandwidth，并根据这两个值设定发送窗口，迅速占用带宽。通过启动BBR，可以充分的利用当前的网络带宽，而且在存在丢包的弱网络环境下，对吞吐量的影响进行了优化。目前，BBR在大量的应用中得到了使用，如Youtube等，而且对网络吞吐量的优化效果非常的显著。
4、Forward Error Correction（FEC）
Forward Error Correction（FEC）是一种数字信号处理技术，其目的是应对数据或信号在网络传输过程中，由于网络丢包或网络噪声而导致的数据丢失。FEC最早得到广泛应用的场景在是OTN光网中，在OTN G709封装中具备了FEC功能。现在，该技术已经被广泛应用到了SDWAN网络中，发送端SDWAN设备会根据FEC算法，自动生成用于纠错的数据包，通常每4个数据包会产生1个纠错包，并与原始数据包一起传输。当网络中存在丢包时，如果网络丢弃的数据包不超过一个，接收端就可以根据纠错包，对被丢失的数据包进行重构，以达到对网络丢包进行补偿的效果。下图为FEC机制示意图（vEdge为SDWAN边缘路由器）。
三、测试环境搭建及测试说明
本例测试用的思科SDWAN解决方案已经支持FEC功能和BBR功能，可以针对弱网环境中，对网络吞吐量进行优化。下面我们就这对这两个功能进行测试，并根据测试结果给出推荐配置。
1、FEC测试
在思科SDWAN网络中启动FEC功能，配置界面如下：
下面就是开启FEC前后对网络吞吐量测试结果，及测试结果数据截屏。
测试环境：网络延时10ms，分别测试0%、1.5%、5%、10%网络丢包的情况下，网络吞吐量的变化。
首先是无丢包的情况，网络吞吐量为84Mbps。
增加丢包为1.5%，开启FEC功能前后吞吐量分别为6.74Mbps和44.1Mbps，可以看出启动FEC后，对微弱丢包的环境下，吞吐量得到了极大的改善。
增加丢包到5%，开启FEC前后吞吐量分别为3.25Mbps和11.7Mbps，说明5%丢包环境下，FEC仍然可以有效提高网络吞吐量，但显然效果下降了。
进一步测试10%丢包，开启FEC前后吞吐量分别为1.87Mbgs和5.58Mbps，效果进一步下降。
由此我们可以得出结论，FEC开启后，确实对丢包的弱网环境下，对网络吞吐量具有优化作用，但伴随着丢包量的增加，优化效果会持续下降。
2、BBR测试
思科SDWAN的BBR是在TCP Optimization功能中开启的，配置步骤如下：
第一步：在AppQoE界面中进行相关配置，Configuration – Template – Feature Template – Other Template – AppQoE。
第二步：定义Control Node和Service Node。
第三步：将定义的AppQoE feature temlate添加到相应的Device Temlate中。
第四步：创建Centralized Data Policy，并开启TCP优化功能。
测试环境：网络延时100ms，分别测试1.5%、5%、10%、15%、20%，网络丢包的情况下，网络吞吐量的变化。
首先测试1.5%丢包的环境下，开启BBR功能前后网络吞吐量分别为1.03Mbps和42.2Mbps。
增加丢包到5%，开启BBR前后的吞吐量测试结果分别为464Kbps和39.3Mbps。
增加丢包到10%，开启BBR前后的吞吐量测试结果分别为313Kbps和35.5Mbps。
增加丢包到15%，开启BBR前后的吞吐量测试结果分别为248Kbps和30.7Mbps。
增加丢包到20%，开启BBR前后的吞吐量测试结果分别为187Kbps和19.1Mbps。
从上面的测试结果可以看出，在SDWAN中启动了BBR功能后，即使在持续大量丢包的弱网络环境下，网络传输的吞吐量都得到了极大的改善。
下面对延时分别为100ms、200ms、300ms，丢包为1.5%、5%、10%、15%、25%进行了测试，测试结果整理如下：
可以看出，在未启动TCP Optimization功能前，只要存在丢包，网络吞吐量几乎下降到了无法使用的程度，但开启了TCP Optimization功能后，受益于BBR，网络吞吐量都得到了极大的改善，而且对于延时和丢包并不像FEC那么敏感。
四、总结
通过上面的测试，我们可以得出结论，针对出海客户，由于互联网丢包和大延时状况的存在，网络吞吐量都会受到极大的影响。如果跨域互连架构在SDWAN网络上，则可以通过在SDWAN路由器上开启TCP优化功能和FEC功能，极大的优化网络吞吐量。
测试结果显示，开启FEC功能后，在低于5%网络丢包的情况下，吞吐量优化效果明显，能够达到4 ～7倍的优化效果；但随着丢包比例的增大，以及延时的增加，优化效果会出现明显下降。开启TCP优化和BBR功能后，在网络大延时和持续频繁丢包的情况下，吞吐量优化效果非常明显，即使在出现20%持续丢包的情况下，吞吐量仍然有近100倍的提升。因此，建议使用TCP优化和BBR作为吞吐量优化的首选。
另外，在SDWAN网络中开启BBR功能后，无需在应用服务器端进行单独的BBR配置，即使操作系统不支持BBR功能，也可以达到令人满意的优化效果。