非专线场景下的高速传输

本文以同步发布到比扬云官方服务号，您可以微信搜索比扬云或者点击：原文链接 查看

通常所说的网络优化主要是两个网络指标的优化：

• 网络丢包，丢包事件在TCP当中是个非常严重的信号，非常影响TCP的传输速度
• 网络延迟，相比较丢包而言，延迟对TCP的影响会小一些，主要是影响TCP窗口增长速度，但是对于UDP而言就不一样，UDP使用场景主要是实时性要求很高的领域，比如在线会议，对战类游戏，这些场景对于网络延迟要求非常高。

针对这两个方面优化做的最好的当然是无脑上专线，但是上专线意味着更高的成本，而且专线的线路有限。这篇文章来分享比扬云SD-WAN加速是如何在非专线的基础之上，从技术层面实现网络加速的。

比扬云SD-WAN加速原本也叫全球加速，为了更加聚焦在SD-WAN领域，我们将其调整为SD-WAN加速，目前将该技术已经用于海外电商加速，组网传输加速，Docker镜像加速等场景，并且取得不错的效果，比扬云的SD-WAN加速也是我们所有产品的加速底座，可以认为所有需要加速的功能，我们都是基于SD-WAN加速来实现的。

加速效果

以上是我们基于SD-WAN加速实现的Office365文件下载的加速效果，整个过程不涉及任何专线线路，如果希望体验我们的加速效果，可以到比扬云官网上进行免费使用，我们会提供两种类型的加速：

• 通用的端口转发，适用于您海外有一个服务，比如ssh，远程桌面，您可以配置此类型应用的加速
• Docker镜像加速，可以用来加速拉取docker镜像

有了加速效果之后我们再来看看比扬云是如何达到这一效果的。

如何实现加速

正如之前提到的网络优化的两个指标，网络丢包和网络延迟，那我们分别针对这两个指标进行优化。
首先在网络丢包上，丢包是必然存在的，我们在丢包上做了以下优化。

• 实时探测全链路的丢包，将丢包纳入网络质量计算里面，每个请求过来我们都会根据计算结果走此时此刻最优质的线路。

• 在1的基础之上使用FEC策略来降低丢包的影响，FEC属于一种纠错机制，我们可以简单理解为会多发一些数据，然后根据数学原理计算出完整的数据，允许你丢包，但是丢的包可能会被计算出来，这时候其实就不算丢包

• 将长距离传输分成多段短距离传输，长距离传输会存在一些问题，尤其是在TCP协议上

  • 从TCP的角度看，RTT（RoundTrip Time）变长了，RTT会影响TCP的窗口增长速度以及RTO
  • 链路太长意味着丢包几率变大，这里的丢包不一定是真正的丢包，而是TCP认为你丢包了，也就是超时没收到收到ACK包，
    我们来看一下变成多个短距离之后是如何有优化作用的。
    假设你在深圳，使用了比扬云SD-WAN加速之后，跟你进行TCP握手的节点可能就在深圳，那么你看到的RTT就是从你到深圳节点的延迟，从你的角度看，等于是低于10ms的延迟，丢包也是同样的道理，从你的角度看，丢包是到深圳节点的丢包。
    

  整个全流程都是按照这个模式一步一步传下去，直到到达目的地，这也就是将长距离传输转换为短距离传输带来的一个效果。

以上是针对网络丢包的一些微创新，在网络延迟的优化上基本跟上面是重合的。

• 就近节点的接入，这个在上面的RTT变短已经提到了，这里不在复述
• 实时探测全链路延迟，将延迟纳入网络质量计算里面，网络质量计算是综合上面的实时全链路延迟和丢包来进行计算的，我们会部署多条线路，根据计算的结果走此时评分最高的线路。
  整体而言我们认为都是一些比较经典的手段，但是能达到不错的效果。

缺陷

最后我们来看一下存在的缺陷。

• 很明显第一个缺陷是对延迟的优化效果有限，无论你如何进行优化都不会达到专线的延迟效果，这点我们从未怀疑过，毕竟两点之间线段最短是个公理。
• 第二个缺陷是随着线路和节点的上升，成本也可能会慢慢上涨，比如直连到达和经过2-3跳的转发节点再到达，成本肯定是后者更高。

无脑上专线很重要的原因其实也是这两个缺陷，一方面可能没有成本的优势，另外一方面优化的效果也达不到专线的效果，何不直接上专线，一旦SD-WAN选路的成本超过专线，我们就会强烈推荐使用专线，比扬云由于基于PLG的策略，提供的免费版本，而针对免费用户以及一些中小微客户，对成本比较敏感，肯定是不可能使用专线，只能基于本文提到的优化策略的线路。