网络延迟和数据包丢失对网络性能的影响

网络性能指标一般指的是延时，丢失和抖动。今天我们将探讨它们（特别是延时和数据包丢失）是如何影响应用程序性能。

几乎所有应用程序都使用TCP，即传输控制协议，将其数据从A传输到B。互联网流量的85％是TCP。

TCP的一个有趣的方面是，它对应用程序完全隐藏了基于分组的网络性质。无论是应用程序偶尔将单个字符交给TCP（例如Telnet或SSH），还是以最快的速度（FTP）或介于两者之间的速度转储一个数兆字节的文件，TCP都会获取数据并将其放入数据包中，并且通过网络发送它。

互联网对于数据包来说是它害怕的地方：数据包丢失，永不传播，到达的顺序与传输的顺序不同的情况并不少见。

‍

延迟

早期的网络协议通常是为在LAN或园区网络上运行而构建的，在这些协议中，数据包可以在几毫秒内从网络的一端传输到另一端。这些协议在互联网上并非总是能很好地工作，在这种情况下，数据包在到达目的地之前很容易花费十分之一秒的时间绕地球旋转。如果您随后还需要返回数据包，则此数字将翻倍至200毫秒。

排队论告诉我们，链接越忙，需要等待的时间越长。

例如，运行速度为8 Gbps（利用率为80％）的10 Gbps链路意味着，平均而言，当一个数据包到达时，已经有四个其他数据包在等待。在99％的利用率下，此队列增长到99个数据包。当链接慢得多时，这可能会增加大量的额外延迟，但以10 Gbps的速度传输99个平均500字节的数据包，仅需0.248毫秒。

在存在高延迟的情况下，TCP具有多种机制来获得良好的性能。

最主要的是确保有足够的数据包“处于运行状态”。只需发送一个数据包，然后等待另一端说“明白了，然后再发送下一个”，它就不会中断。

因此，TCP会尝试确保发送足够的数据包来填充链接，但不会那么多，以至于它会使链接或路径变得过饱和。这对于长期的数据传输（例如大下载量）非常有效。

但是对于较小的数据传输，它并不是那么好用，因为为了确保它不会使网络不堪重负，TCP使用了“慢启动”机制。

对于长下载而言，慢启动部分仅占总时间的一小部分，但对于短传输，在TCP加速运行时，传输已结束。因为TCP必须等待接收者的确认，所以更多的延迟意味着更多的时间花费在缓慢的启动上。Web浏览器的性能过去常常受到启动速度的限制，但是浏览器开始重用TCP会话，而这些会话本来就不是很慢，因为它开始下载其他图像和其他元素，而不是继续打开新的TCP会话。

当然，几乎每个TCP连接都在DNS查找之前。如果对DNS服务器的等待时间很长，则会减慢整个过程。因此，请尝试使用附近的DNS服务器。

‍‍

数据包丢失

理想情况下，网络永远不会丢失单个数据包。当然，在现实世界中，它们这样做是有两个原因的。每个传输介质都会偶尔“翻车”，然后整个数据包都会丢失。

如果发生此类错误，则需要重新传输丢失的数据包。这样可以阻止转移。

假设我们在200 ms RTT连接上以每秒1000个数据包的速率发送数据。这意味着，当发送方发送数据包500时，数据包401 – 499仍在运行中，而接收方刚刚发送了对数据包400的确认。但是，确认301 – 399在另一个方向上运行，因此最新的确认是发送方已经看到的是300。因此，如果数据包500丢失，则发送方直到看到确认499后跟501才注意到。此时，它正在发送数据包700。因此，接收方将看到数据包499、501 – 700、500 ，然后是701及更高版本。这意味着接收方在等待500时必须缓冲501-700数据包。

如果网络延迟或数据包丢失变得过高，TCP将耗尽缓冲区空间，并且传输必须停止，直到收到重新传输的丢失数据包为止。换句话说：高延迟或高丢失并不是很好，但是仍然可以使用，但是高延迟和高丢失一起会使TCP缓慢进行爬网。

数据包丢失的第二个原因是因为TCP的发送速度如此之快，以致路由器/交换机缓冲区的填充速度快于数据包的传输速度。当缓冲区已满并且有另一个数据包进入时，路由器或交换机只能做一件事：“丢弃”数据包。由于TCP无法分辨出由于位翻转或网络中的缓冲区溢出而丢失的数据包之间的差异，因此将假定后者并降低速度。在上面的示例中，这种减速不太严重，因为后续的数据包一直得到确认。这允许TCP使用“快速重传”。

但是，如果传输中最后三个数据包之一丢失，则快速重传将不起作用。在那种情况下，TCP无法分辨单个丢失的数据包与网络大量过载而无法通过的情况之间的区别。因此，现在，TCP将让其超时计时器递减计数到零，这通常需要一秒钟，然后尝试以慢速启动方式使所有内容再次恢复正常。这个问题通常会咬住Web会话，而Web会话通常很短，虽然页面大多数都很快出现，但页面需要几秒钟才能完全完成加载。

TCP在超时情况下结束的另一个原因是在短时间内是否有太多数据包。至此，TCP确定网络只能承受非常保守的数据传输速度，而缓慢的启动确实可以说是正确的。通常，在这种情况下，停止下载并重新开始下载比等待TCP恢复要更快。

‍‍

抖动

抖动是数据包之间的延迟之间的差异。显然，光速不会发生变化，光纤往往保持相同的长度。

因此，延时通常是由路由器和交换机中封包的缓冲造成的，这些数据包终止了高利用率的链路。（特别是在带宽较低的链路上，例如宽带或3G / 4G链路。）

有时，数据包很幸运，可以快速通过，有时，队列比平时更长。

对于TCP来说，这不是一个大问题，尽管这意味着TCP必须为其RTT估计使用保守值，并且超时时间会更长。但是，对于（非TCP）实时音频和视频流量，抖动非常成问题，因为音频/视频必须以稳定的速率播放。这意味着应用程序必须缓冲“快速”数据包并等待慢速数据包。

总而言之，在使用多个连接到互联网的网络中，它可以真正避免出现以下情况：避免路径长得多，从而导致比到达相同目的地的替代路径以及拥塞的路径（丢包率更高）更长的延迟。

在微云网络骨干网环境，我们做到了自动执行路径选择过程。确保检查我们的智能路由，以及它如何评估多个提供商之间的数据包丢失和延迟，以选择性能最佳的路径。