当前位置:首页 » 《关于电脑》 » 正文

[Linux][网络][TCP][四][流量控制][拥塞控制]详细讲解

7 人参与  2024年05月14日 11:21  分类 : 《关于电脑》  评论

点击全文阅读


目录

1.流量控制2.拥塞控制0.为什么要有拥塞控制,不是有流量控制么?1.什么是拥塞窗口?和发送窗口有什么关系呢?2.怎么知道当前网络是否出现了拥塞呢?3.拥塞控制有哪些算法?4.慢启动5.拥塞避免6.拥塞发生7.快速恢复


1.流量控制

发送方不能无脑的发数据给接收方,要考虑接收方处理能力

如果一直无脑地发数据给对方,但对方处理不过来,那么就会导致触发重发机制,从而导致网络流量的无端的浪费

为了解决这种现象发生,TCP提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量,这就是所谓的流量控制

假设以下场景:客户端是接收方,服务端是发送方假设接收窗口和发送窗口相同,都为200,假设两个设备在整个传输过程中都保持相同的窗口大小,不受外界影响

根据下图的流量控制,说明下每个过程:

客户端向服务端发送请求数据报文 **说明:**本次例子是把服务端作为发送方,所以没有画出服务端的接收窗口 服务端收到请求报文后,发送确认报⽂和80字节的数据,于是可用窗口Usable减少为120字节,同时SND.NXT指针也向右偏移80字节后,指向321,这意味着下次发送数据的时候,序列号是321客户端收到80字节数据后,于是接收窗口往右移动80字节, RCV.NXT也就指向321,这意味着客户端期望的下⼀个报文的序列号是 321,接着发送确认报⽂给服务端服务端再次发送了120字节数据,于是可用窗口耗尽为0,服务端无法再继续发送数据客户端收到120字节的数据后,于是接收窗口往右移动120字节, RCV.NXT也就指向441,接着发送确认报文给服务端服务端收到对80字节数据的确认报文后, SND.UNA指针往右偏移后指向321,于是可用窗口Usable增大到80服务端收到对120字节数据的确认报文后, SND.UNA指针往右偏移后指向441,于是可用窗口Usable增大到200服务端可以继续发送了,于是发送了160字节的数据后, SND.NXT指向601,于是可用窗口Usable减少到40客户端收到160字节后,接收窗口往右移动了160字节, RCV.NXT也就是指向了601,接着发送确认报文给服务端服务端收到对160字节数据的确认报文后,发送窗口往右移动了160字节,于是SND.UNA指针偏移了160后指向601,可用窗口Usable也就增大至了200

请添加图片描述

接收端将自己可以接收的缓冲区大小放入TCP首部中的"窗口大小"字段,通过ACK端通知发送端窗口大小字段越大, 说明网络的吞吐量越高接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端发送端接受到这个窗口之后,就会减慢自己的发送速度如果接收端缓冲区满了, 就会将窗口置为0,这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端

2.拥塞控制

0.为什么要有拥塞控制,不是有流量控制么?

前面的流量控制是避免「发送方」的数据填满「接收方」的缓存,但是并不知道网络的中发生了什么⼀般来说,计算机网络都处在⼀个共享的环境,因此也有可能会因为其他主机之间的通信使得网络拥堵在网络出现拥堵时,如果继续发送大量数据包,可能会导致数据包时延、丢失等,这时TCP就会重传数据,但是⼀重传就会导致网络的负担更重,于是会导致更大的延迟以及更多的丢包,这个情况就会进入恶性循环被不断地放大所以,TCP不能忽略网络上发生的事,它被设计成⼀个无私的协议,当网络发送拥塞时,TCP会自我牺牲,降低发送的数据量于是,就有了拥塞控制,控制的目的就是避免「发送方」的数据填满整个网络为了在「发送方」调节所要发送数据的量,定义了⼀个叫做「拥塞窗口」的概念

1.什么是拥塞窗口?和发送窗口有什么关系呢?

拥塞窗口cwnd是发送方维护的⼀个的状态变化,它会根据网络的拥塞程度动态变化的前面提到过发送窗口swnd和接收窗口rwnd是约等于的关系,那么由于加入了拥塞窗口的概念后,此时发送窗口的值是**swnd = min(cwnd, rwnd)**,也就是发送窗口和接收窗口中的最小值拥塞窗口cwnd变化的规则 只要网络中没有出现拥塞,cwnd就会增大但网络中出现了拥塞,cwnd就减少

2.怎么知道当前网络是否出现了拥塞呢?

只要「发送方」没有在规定时间内接收到ACK应答报文,也就是发生了超时重传,就会认为网络出现了拥塞

3.拥塞控制有哪些算法?

慢启动拥塞避免拥塞发生快速恢复

4.慢启动

TCP在刚建立连接完成后,首先是有个慢启动的过程,这个慢启动的意思就是⼀点⼀点的提高发送数据包的数量, 如果一上来就发大量的数据,这不就是给网络添堵吗?慢启动的算法记住⼀个规则就行:当发送⽅每收到⼀个ACK,拥塞窗口cwnd的大小就会加1这里假定拥塞窗口cwnd和发送窗口swnd相等,下面举个例子: 连接建立完成后,⼀开始初始化cwnd = 1,表示可以传⼀个MSS大小的数据当收到⼀个ACK确认应答后,cwnd增加1,于是⼀次能够发送2个当收到2个的ACK确认应答后, cwnd增加2,于是就可以比之前多发2个,所以这⼀次能够发送4个当这4个的ACK确认到来的时候,每个确认cwnd增加1,4个确认cwnd增加4,于是就可以比之前多发4个,所以这⼀次能够发送8个可以看出慢启动算法,发包的个数是指数性的增长

请添加图片描述

那慢启动涨到什么时候是个头呢?有⼀个叫慢启动门限ssthresh(slow start threshold)状态变量 当cwnd < ssthresh时,使⽤「慢启动算法」当cwnd >= ssthresh时,就会使⽤「拥塞避免算法」

5.拥塞避免

前⾯说到,当拥塞窗口cwnd「超过」慢启动门限ssthresh就会进入拥塞避免算法⼀般来说ssthresh的大小是65535字节进入拥塞避免算法后,它的规则是:每当收到⼀个 ACK 时,cwnd增加1/cwnd接上前面的慢启动的例子,现假定ssthresh为8: 当8个ACK应答确认到来时,每个确认增加1/8,8个ACK确认cwnd⼀共增加1,于是下次能够发送9个MSS大小的数据,变成了线性增长可以发现,拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长,还是增长阶段,但是增长速度缓慢了⼀些就这么⼀直增长着后,网络就会慢慢进⼊了拥塞的状况了,于是就会出现丢包现象,这时就需要对丢失的数据包进行重传。当触发了重传机制,也就进入了「拥塞发生算法」
请添加图片描述

6.拥塞发生

当网络出现拥塞,也就是会发生数据包重传,重传机制主要有两种:

超时重传快速重传

发生超时重传的拥塞发生算法

ssthresh和cwnd的值会发生变化: ssthresh设为cwnd/2cwnd重置为1 接着,就重新开始慢启动,慢启动是会突然减少数据流的 ⼀旦「超时重传」,马上回到解放前。但是这种方式太激进了,反应也很强烈,会造成网络卡顿
请添加图片描述

发生快速重传的拥塞发生算法

还有更好的方式,前⾯讲过「快速重传算法」。当接收⽅发现丢了⼀个中间包的时候,发送三次前⼀个包的ACK,于是发送端就会快速地重传,不必等待超时再重传TCP认为这种情况不严重,因为大部分没丢,只丢了⼀小部分,则ssthresh和cwnd变化如下: cwnd = cwnd/2 ,也就是设置为原来的⼀半ssthresh = cwnd进⼊快速恢复算法

7.快速恢复

快速重传和快速恢复算法⼀般同时使用,快速恢复算法是认为,你还能收到3个重复ACK说明网络也不那么糟糕,所以没有必要像RTO超时那么强烈正如前⾯所说,进⼊快速恢复之前, cwnd和ssthresh已被更新了 cwnd = cwnd/2 ,也就是设置为原来的⼀半ssthresh = cwnd 然后,进入快速恢复算法如下 拥塞窗口**cwnd = ssthresh + 3**(3的意思是确认有3个数据包被收到了)重传丢失的数据包如果再收到重复的ACK,那么cwnd增加1如果收到新数据的ACK后,把cwnd设置为第⼀步中的ssthresh的值,原因是该ACK确认了新的数据,说明从duplicated ACK时的数据都已收到,该恢复过程已经结束,可以回到恢复之前的状态了,也即再次进⼊拥塞避免状态

点击全文阅读


本文链接:http://zhangshiyu.com/post/108296.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1