- 缓存
-
网络画像
- 客观网络条件
- 主观外部输入
- 小结
在前两篇博文对带宽、时延与丢包率有了初步的认识后(引流引流哈哈哈),我们已经可以对网络链路进行简单的画像描述了,不同画像的网络在现实中复杂的场景下也会有着不同的表现。在分析这些表现之前,首先对一个参数进行补充。
缓存
还是在前两篇都有提到,端到端的传输链路中存在很多节点(路由器或交换机等),在这些节点+发端和收端中,每个节点都有自己的数据处理(发或收)速度上限(最慢的那个成为了带宽大小的限制)。如果一段时间内,拥入链路中的单位时间数据量超过了某些节点的限制,那么在这些节点的缓存中就会逐渐积累起数据队列。
举个简单的例子,假设一个发端+路由器1+收端的简单链路,发端push数据进链路的速度为(v_{send}),路由器接收并转发数据的最大速度为(v_{route}),收端接收数据的最大速度为(v_{recv}),且有(v_{send} > v_{route} > v_{recv}),那么会发生什么事?即在路由器的接收缓存中,数据会以(v_{send} – v_{route})的速度进行累积,在收端的缓存中,数据会以(v_{route} – v_{recv})的速度进行累积。如果发端push数据的速度不减,那慢慢这两个节点的缓存都会堆满,开始丢包,并且在堆积的过程中,两个节点的排队延时会上涨,RTT也会上涨,直到两个节点都开始丢包,RTT达到增长上限。
这里有两个需要注意的点:
- 两个节点丢包的时间点一样吗:显然不一样,因为缓存有大有小(深缓存、浅缓存),浅缓存下队列稍一堆积就会发生丢包,深缓存下能够堆积较多的数据也不会触发丢包;
- RTT的上涨与缓存的关系:绝大部分情况下浅缓存下RTT的涨幅上限是小于深缓存的(考虑到一些硬件原因),如果发现RTT持续增长到很大却一直没有发生丢包,很可能链路中有一个深缓存节点,反之,如果RTT增长一点就发生了丢包,大概率链路有浅缓存节点。
网络画像
结合已经梳理的参数,我们就可以简单对网络画像进行一个描述,我这里将画像分为两部分:客观网络条件与主观外部输入。
客观网络条件
主要包括链路的带宽、节点缓存大小、除了排队时延之外的时延、链路随机丢包率。这些参数在短时间内是固定不变的,属于客观因素,在路由路径发生改变或者其他用户加入链路时也会发生改变,但在短时间内或者稳定的网络环境下,是比较可靠的。其中,链路随机丢包率是传输过程中数据包损坏或碰撞的概率,取决于传输链路,与拥塞无关,通常都比较小(不足1%)。
主观外部输入
主观外部输入则可以笼统的概括为数据进入网络的模式,数据是以稳定的速度均匀进入网络还是周期性的短时间内发送大量数据,又或是毫无规律的发送。由“主观”可以知道,很多时候数据进入网络的模式是发端可以控制的,如果不加控制会是什么样的场景呢?
稳定的速度均匀发送:如果发送速度小于带宽,发端到收端能够以发送速率的速度稳定交付数据,且时延保持较低水平,只会遇到较低的随机丢包;如果发送速度大于带宽,那么发端到收端能够以带宽的速度交付数据,时延呈线性增长,直到发生拥塞丢包,严重影响体验;
周期性短时间内发送大量数据:这里只考虑短时间速度大于带宽的场景,小于没什么好说的,如果数据量较小,短时间不足以填满缓存,在这段时间发端到收端能够以带宽的速度交付数据,时延先增长后下降(取决于发端停止传输的时间);如果数据量较大,短时间填满了缓存,在这段时间发端到收端能够以带宽的速度交付数据,时延先增长后下降,但会承受一定程度的丢包(取决于数据量与发送速度);
毫无规律的发送:那我也一言半语说不好了。。。需要具体问题具体分析,有点中学做物理题的感觉。
小结
总而言之,在已知网络客观网络条件与主观外部输入的前提下,我们能够从理论上分析具体得数据传输表现与预测可能出现的问题。进一步,在已知客观网络条件下,我们能够制定发送策略以获取优质的传输体验,即低延时,低丢包,高速率。
那么问题来了,怎么获取客观网络条件呢?自然而然就提到了拥塞控制CC(Congestion Control),CC是现代网络传输领域最重要的难题之一,旨在怎么获取可靠的网络参数并制定数据发送策略,使得用户能够获取低延时、低丢包、高速率的网络传输体验,这里以BBR论文里的示意图作为结尾(对于初涉传输的我,这张图给了我很多启发)。
本文来自博客园,转载请注明原文链接:https://www.cnblogs.com/mapleumr/p/17483724.html
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须在文章页面给出原文连接,否则保留追究法律责任的权利。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net
把无所不在的空气般的认知作为“天”, 把承载一切管理工作的沟通作为“地”, 把管理者需要做的“看方向”“带人”“做事”放在中间, 就组成了管理者的管理框架。这就是“管理要做的这些事儿。 根据工作场景将“看方向”“带人”和“做事”拆解和细化出 13 个要素,形成…