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

71 阅读 0 评论 47 点赞

我是靠谱客的博主微笑香烟，最近开发中收集的这篇文章主要介绍丢包和网络延迟对网络性能的影响，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

一般地，网络性能指标涉及延迟、丢失和抖动。现在，我们将探讨这些问题(尤其是延迟和丢包)如何影响应用程序的性能。

实际上，所有的应用程序都使用TCP，即从A到B的数据传输控制协议。85%的因特网流量是TCP。

TCP的一个有趣之处是，它完全隐藏了应用程序中基于分组的网络特性。不管是应用程序偶尔向TCP(如Telnet或SSH)传递单个字符，还是以最快速度(FTP)或介于这两者之间的速度转储一个兆字节的文件，TCP都会把数据放入数据包中，然后通过网络发送。

因特网对包的恐惧之处是：包会丢失，永远不会传播，而且到达的顺序和传送的顺序不同也是很正常的。

延误。

以前的网络协议一般都是为了运行在卫星或园区网络上，在那里数据包可以在几毫秒内从网络的一端传送到另一端。在因特网上，这些协议并不总能很好地工作，在这种情况下，数据包在到达目的地前可以轻易地绕着地球转十分之一秒。当你以后还需要返回一个包时，这个数字会加倍到200毫秒。

队列理论表明，链接越忙碌，所需等待的时间越长。

比如，10的运行速度是8Gbps(80%的利用率)。

平均而言，Gbps链路意味着，当一个包到达时，其他四个包正在等待。这个队列的使用率达到99%，增加到99个包。如果连结速度很慢，这可能会增加很多额外的延迟，但是可以达到10。

Gbps传输99个平均500字节的包，只需0.248毫秒。

TCP具有多种机制，可以在高延迟条件下获得较好的性能。

重要的是要确保有足够的“正在运行”的数据包。简单地发送一个信息包，然后等对方说“知道了，然后发下一个”，就不会被打断。

所以，TCP试图确保发送足够的数据包来填充这些链接，但是数量不会太大，以致于它使链接或路径饱和。这种方法对长期数据传输非常有效(比如大量下载量)。

云专线（Direct Connect）是搭建在用户本地数据中心与云上虚拟私有云（Virtual Private Cloud，简称VPC）之间的高安全、高速度、低延迟、稳定可靠的专属连接通道。

但对较小的数据传输来说，这并不奏效，因为TCP采用了“慢启动”机制，以确保不会使您的网络连接变得沉重。

慢启动部分只占长下载量的一小部分，但是当TCP加速时，短传输的传输将结束。由于TCP必须等待接受者的确认，更多的延迟意味着更多的时间被浪费在启动缓慢。以前，Web浏览器的性能受到了启动速度的限制，但浏览器开始重用TCP会话，因为TCP会话开始下载其他图像和其他元素，而不再打开新的TCP会话。

毫无疑问，几乎每一个TCP连接都是在TCP查找之前的。假如在Securities服务器上等得太久，整个过程就会慢下来。所以试着使用附近一台S-服务器。

丢了包。

理论上来说，网络绝不会丢失一个单独的包。在现实世界中，他们之所以这么做，当然有两个原因。每一种传输媒介会偶尔“翻车”，从而丢失整个数据包。

一旦出现这样的错误，丢失的数据包需要重新传送。这能阻止转移。

比如说200毫秒。

在RTT连接上以每秒1000包的速度发送数据。这就是说，当发送端发送数据包500时，数据包401–

499仍然在运行，而接收者只是对400的数据包发出了确认。然而，确认301–

由于399的运行方向不同，所以发送方所看到的最近的确认值为300。所以如果500包丢失了，发送者在看到499确认后才会注意到501。现在它正在发送一个数据包700。这样，接收者就可以看到包499,501。

-700、500，然后是701及以后的版本。这就是说，接收者必须缓冲501-700等待500时的包。

若网络延迟或丢包过大，TCP将耗尽缓冲区空间，传输必须停止，直到接收到重新传输的丢失包。换言之：高延迟或高丢失的情况并不好，但仍可使用，但同时高延迟和高丢失会让TCP爬网变慢。

丢包的第二个原因是TCP被发送得太快了，以至于路由器/交换机缓冲区被填塞得比包的传输快。在缓冲区满的情况下，另一个数据包也会进入，路由器或交换机只能做一件事情：“丢弃”包。因为TCP不能识别因网络中的位翻转或缓冲区溢出而丢失的包之间的差异，所以会假设后者，并降低速度。上例中，此速度降低并不太严重，因为随后的包会一直被确认。这样就可以使用TCP“快速转发”。

然而，如果传输中的最后三个包中的一个丢失了，快速重传就会失效。这种情况下，TCP不能区分单独丢失的包和网络超载过大而不能通过的情况。现在，TCP会让它的超时计时器计数减少到0，通常需要1秒钟，然后再试着让所有的东西以慢速开始。Web会话通常会出现这种问题，而且Web会话通常很短，尽管页面的大部分很快就会出现，但是页面要花几秒钟才能完全完成加载。

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

连环。

摇晃。

抖抖是指数据包之间的延迟。很明显，光速是不变的，光纤的长度通常是一样的。

所以，延时通常是由节点上的封包缓冲和交换机上的封包终止高利用率的链路造成的。尤其是在低带宽链路上，如宽带或3G链路。

四G连接方式)

有时候，信息包是幸运的，有时候，排队的时间比平时长。

对TCP来说，这个问题不大，虽然这意味着TCP必须对RTT的估计使用保守值，而且超时时间会更长。然而，抖动对于(非TCP)实时音频和视频流量来说是一个问题，因为音频/视频播放速率必须是稳定的。这就是说，应用程序必须缓存“快速”包，并等待慢速的包。

总之，在使用多个Internet连接的网络中，这样做确实可以避免这样的情况：避免路径过长，导致比到达同一目的地的替代路径和阻塞路径(高丢包率)更长的延迟。

我们实现了Vecloud微云主干网络环境下的自动路径选择过程。确定您的智能路由，以及它如何评估多个提供商之间的包丢失和延迟，以选择最优路径。