长肥管道传输之痛与解决之道

随着腾讯云业务的全球扩张，越来越多的海外节点在陆续的建立起来，跨海，跨洲的长距离传输也越来越成为业务的常态（像直播视频云业务就有海外主播国内乃至全球观看的业务形态）。这种远距离的数据传输，拥有长的RTT(Round Trip Time往返时间)和高的带宽，管道容量（BDP，即Bandwidth和RTT的乘积）大，被称作长肥管道。传统的TCP应用于网络不稳定的长肥管道，传输效率不高，已越来越不能满足业务稳定高速传输的苛刻要求。本文分析了长肥管道存在的问题，并提出了解决此问题的一个思路。

长肥管道的困境

拥有长的RTT(Round Trip Time往返时间)和高的带宽，管道容量（BDP，即Bandwidth和RTT的乘积）大，被称作长肥管道。理想的长肥管道是这样的。但现实中，链路是被网络中的节点共享的。复杂且动态的链路数据包收敛汇聚行为使得传输并不稳定，排队，丢包造成巨大的影响。而TCP是基于ACK反馈驱动的，其对链路的感知与响应时间是正比于RTT时长的。相比短链路，长肥管道对网络状况的响应更加滞后（RTT长意味着ACK越久，RTO越大），收敛更慢（例如慢启动会耗费更长的时间），体现在传输过程中现象就是偶发的丢包或拥塞会使得传输速率急剧下降并且恢复慢，严重时，传输速度根本起不来。有没有办法适当“缩短“这个反馈路径呢？

理想中的长肥管道vs现实中的长肥管道

基于丢包的拥塞算法已过时

TCP的拥塞控制算法诞生于1980年代，那时硬件水平，处理速度都不够快，互联网节点数量也不多（1000+），中间转发设备处理性能和缓存能力也极其有限。“丢包”跟“网络拥塞”是等价的。Van Jacobson正是在那样的情况下，提出了基于丢包感知的AIMD拥塞控制算法：在拥塞时更加积极主动退避即遵循MD(Multiple Decrease，乘性减窗)原则，而申请网络资源时应该更保守的探测网络可用带宽即遵循AI原则(Addtive Increase，加性增窗)。AIMD原则是让大家以合作的方式公平的使用公共的网络资源，是唯一正确的收敛的算法。这种基于丢包感知的拥塞控制方法30多年来一直沿用至今，占据着统治地位。

Loss-Based拥塞控制算法与BBR拥塞控制算法对比(来自https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster)

但是随着技术的进步与网络的普及，互联网设备也越来越多（近年来由于IPV4地址耗尽而加快了IPV6部署的步伐）。节点多了，发送的数据量大了，必然带来更多的拥塞。为求缓和拥塞的冲击，提升转发的成功率，各大网络设备厂商纷纷在设备里加入越来越大的缓存。如今的网络已然成为一个带有强悍“蓄水”能力的缓冲池。传统的基于丢包感知网络拥塞的传输控制，在感知到丢包时，却是在早已把网络的缓冲占满之后了，就如同国庆塞满车动弹不得的高速路，连应急车道和加油站这些“缓存”都塞满了随时要插入的车辆（这里的比喻可能不恰当，一是真实的网络环境缓存可能跟管道容量至少在一个数量级，二是排列的数据一般是优先发送），这就是buffer bloat现象。需要有一种更符合当下网络环境的拥塞控制算法来应对Buffer Bloat问题。Google的提出的BBR(Bottleneck Bandwidth and Round-trip propagation time)拥塞控制算法正是为了解决这一问题而提出的，它和Cubic这种Loss-Based的拥塞控制算法有本质区别。

拥塞控制算法工作方式对比

TCP传输最大的吞吐率受限于链路双端物理时延（Round-Trip Propagation Time简写为RTprop）和链路的瓶颈（速率最低的那一段）带宽（Bottle-neck Bandwidth简写为BtlBw）的乘积。这个乘积叫做BDP（Bottle-neck Bandwidth Delay Production），即BDP=BltBw x RTprop。BDP是将链路填满而不造成中间设备缓存数据包最大数据容量。再多的数据包进来，只能被路由设备给缓存起来延迟投递。延迟投递会造成RTT升高，而投递成功率（Dilivery Rate)却没法上升(投递效率的上限是瓶颈带宽BtlBw）。吞吐率到达BDP才是链路的最优工作点，BBR即寻求工作于这个最优点：即寻求在不排队的情况下，以瓶颈带宽的速率持续发包，保持数据包排满管道，以求获取最大的吞吐率BDP。而Cubic这类Loss-Based的拥塞控制算法，则要等到链路的Buffer填满后发生丢包才会降窗退避缓解拥塞，更要命的是，随机偶发性的丢包（如中间的路由故障切换到备份设备导致部分包丢失等）也会被误判成“拥塞”造成窗口减半，传输速率的急剧下降。在互联网发展的初期，网络节点少，链路Buffer很小的情况下，基于丢包感知拥塞的解法是近似于最优解的（buffer小意味着bandwidth limited区段更窄，两个operating point越接近）。但在现在缓存巨大的现代网络环境下，BBR才是抓住了问题本质正确做法：测量好表征链路特性的物理时延RTprop以及瓶颈带宽BltBw，以二者乘积BDP作为链路容量Pacing发包。Pacing在BBR里是极其重要的，假如瓶颈带宽BtlBw为1Mbps/s，意思是在1s的时间内，链路有能力匀速传输1M bits，即1微秒传输一个bit，如果以burst的方式突发传输1Mbits数据到链路，仍然会造成排队，究其根本原因是所有的数字信号最后都是调制成连续的模拟信号在物理介质上传输的。BBR的这种做法，不像Cubic之类的Loss-Based拥塞控制算法，不会受随机丢包干扰的影响。（欲了解更多关于BBR的实现细节， 请参照Google官方发布的BBR算法介绍：BBR: Congestion-Based Congestion Control进一步了解，这里不展开讲了）。

读到这里，读者应该会想，如果我们让长肥管道的反馈更及时，同时“正确”识别与响应网络中的拥塞，是不是就能更好的解决长肥管道传输的问题呢？答案是肯定的。下面让我们看看，针对长肥管道的这些问题，我们如何一一化解。

更好的端到端协议

由上面的分析可知，Loss-Based让拥塞控制已经不能很好的适应当前的有缓冲能力的网络环境了，Google 提出了新的BBR拥塞控制算法来应对。但是由于TCP协议栈的实现是和操作系统绑定在一起的，除非替换内核，否则就没有办法应用起来（BBR作为TCP的可选拥塞控制算法，自Linux 4.9以后进入了主线版本，但是应用广泛的centos主流版本依然使用的是旧版本的内核，无法开启BBR，另外像windows，ios等平台目前还没有支持BBR)，实用价值不高。

30年来，随着网络环境的发展，TCP也应用时也遇到了设计时没有预想到的corner case与设计的不完善，陆续出现了TCP的各种补丁，这些补丁基本都要修改内核的实现。但是由于TCP跟内核的绑定关系，升级困难，各种补丁应用效果有限。TCP的这些顽疾也一直困难困扰着Google的chomium团队，他们对此的解决方案是在UDP的基础上构建的“更好的TCP”-QUIC（Quic UDP Internet Connection protocol)。

QUIC协议栈

Chromium团队坦诚，QUIC是立足在业界TCP多年的Best Practice之上建立的。下面是TCP与QUIC的对比，当然和BBR一样，同样诞生于Google的QUIC也是第一时间得到了BBR支持。

TCP的问题与QUIC的改进

通过上面的对比可知，QUIC更像是一个完成版的TCP。据Google透露，使用了QUIC后，YouTube的rebuffer率降低最多达18%，应用效果是极好的。

但Chrome版本的QUIC默认只有七层HTTP语言的QUIC实现，所幸QUIC基于C++面向对向的封装，提供了4层QUIC协议实现的可能性，我们团队通过学习与攻关，在Chromium开放的QUIC实现基础上实现了通用的4层全双工QUIC通信并做了相应的优化，解决了QUIC应用的难题。

“分段中继”提升吞吐

上文通过使用QUIC替代TCP，解决了传输线路可能带来的Buffer Bloat问题，也利用了QUIC抗丢包的特性和对BBR的支持，为长肥管道链路的抗抖动和丢包提供了更好的保障。但是，长RTT带来的响应滞后问题，依然没有解决，这个是反馈式端到端的协议没法解决的问题，是端到端的距离带来的无法逾越的物理极限。

以慢启动为例，假设慢启动初始窗口为1，最大BDP为bdp，带宽为B，RTT为t，则慢启动耗时为：

T=(log2(bdp))×t=(log2(B×t))×t

可知，慢启动耗时，至少和RTT呈现正比关系。越短的RTT，慢启动时间越短，同理在网络波动时候，链路的响应会更加及时，收敛也会更快。从这个角度看，是不是我们冗长的长肥管道切分成RTT更小的段级连能否提升传输效率呢？是可以的。这种模式叫做业界叫做“TCP中继”，dog250在流水线式的TCP中继代理是如何提高吞吐的中对此有精彩的论证。下面引用文章中的图例说明为什么“中继”的引入能提升传输效率，方便读者对其有一个直观的认识。

传输中继提升传输效率(https://blog.csdn.net/dog250/article/details/83997773)

本质上讲，中继代理技术通过引入了良好的短距离端到端传输控制，提升了网络的抗性，同时借由多级中继流水线的工作方式，提升了吞吐率。

具体来说，我们如何切分链路与选择链路，若某段中继链路有问题怎么办？怎样保证最大程度的可用？这就到了下一个话题“构建智能路由网络”。

构建智能路由网络

上文说明了使用更好的底层传输协议，切分链路通过分段中继来提升网络稳定性与吞吐率的，起到加速的作用。立足于加速跨洲的长距离传输，我们选择了国内外靠近国际光缆出口的地方核心城市作为中继节点，构建了全球动态加速网络。

有了中继节点后，通过将节点两两互连，形成full mesh的网络。相邻节点间网络互探感知邻边质量。然后各个节点，将感知的网络质量广播扩散至整个网络的各个节点，让全网节点都能感知到整个网络加速节点间网络质量。

加速节点两两互连建立fullmatch网络

用户于靠其最近的节点接入，再由接入节点根据源站IP信息，查找其地理位置归属，选择靠近源站最近的节点作为最优出口节点。有了入和出节点，则可以根据获取的全局网络视图，计算最优路径，进行传输。在传输的过程，最优路径会根据最新的网络状态进行实时更新，当有网络拥塞或者故障发生导致部分中间线路有问题时，最优路径计算过程能能自动避开有问题的中继节点（当有节点故障不可达时，路径权重无限大，最优路径计算时其排序会靠后导致自动切换），自动进行容灾，比TCP直连能提供更高可用性。如下图展示的场景中，在走了加速网络后，整个延时比TCP直连提升了26.7%。

智能路由网络传输路径加速提速示例

同时，在传输的TCP中继模式的基础上，将底层传输协议替换成使用BBR拥塞控制算法的QUIC协议，能更获取更好的网络抗性。在协议之上，我们也可以采取了一些其它的优化措施，进一步提升传输效率：在节点与节点之间，预建连接，并予以预热，让窗口充分扩大；发包时，将大包拆分成小包，小包合并成大包，使用多连接并发传送，让数据不再受限于单条连接窗口的限制。数据包在入节点拆分编号，出节点重组后再发往源站。这样用户数据一旦进入加速网络，就乘上了路径最短的“高铁”，以最快速度将数据包转送到源站。

总结

本文讨论了长肥管道的问题，分析了当前的网络环境以及传统基于丢包的拥塞控制算法的局限。在此基础上，提出了一种基于QUIC协议，短距离可靠传输中继的智能路由网络解决方案。