TCP中窗口和滑动窗口的含义以及流量控制

本文讲述了TCP协议中的窗口概念,包括固定窗口与滑动窗口的工作原理,以及如何通过滑动窗口提高效率。重点介绍了滑动窗口在处理ACK丢失和数据丢包时的策略,同时提到了流量控制的作用,防止窗口过大导致的问题。
摘要由CSDN通过智能技术生成

一.窗口

        

         在TCP中由于要保证可靠性,所以每发送一条数据后,都需要接收方返回一条应答报文,要是我们每发送一条数据,发送方就等待接收应答报文,收到之后再去发送下一条数据,这样我们就会花费大量的时间在等待应答报文上,效率是很低下的

        所以TCP中有了窗口的概念,TCP在发送数据的时候会一次性发送一组数据,发送这一组数据的过程中不用等待ACK(应答报文),就直接往接收方发,而窗口大小就是我们发送这一组数据的大小,如上图,当窗口大小为4000个字节(四个段)时,我们在发送序号为1-4000的信息就直接发送给接收方即可,不需要等待接收方返回ACK(应答报文),在发送好一组数据以后,我们再等待ACK(应答报文),相当于使用一份等待时间,等待四个ACK(应答报文)

        窗口能不能无限大呢

        当我们的窗口越大,此时批量发送的数据就越多,效率就越高,那我们的窗口能不能及其的大呢,这样效率不就非常高了吗?答案是不行,因为窗口要是过于大,批量发送的数据就会很多,就不知道要到什么时候才去等待ACK(应答报文)了,就相当于完全不必等ACK(应答报文),此时就和不可靠传输差不多了,而TCP的特点就是可靠传输,并且如果窗口过于大,批量发送的数据过于多,接收方能不能处理得过来,中间的网络设备能不能承受住,都是未知数

二.滑动窗口

        

         滑动窗口,是一个形象的比喻,实际上就是批量发送数据,这样可以缩短等待时间,提高一定的效率(缩短不代表没有,仍然需要一定的时间等待ACK(应答报文),所以传输效率不会比UDP高)

        如上图,我们在发送一组数据后,等待ACK(应答报文)时,我们需要等待4个段的应答报文都获得了才去发送下一段数据吗,很显然,不需要,由于ACK(应答报文)的发送是有顺序的,所以我们肯定会先接收到当前组中,第一段的ACK(应答报文),当我们收到第一段的ACK(应答报文)后便可以发送下一段数据了,这样我们就保证了一直等待的都是4个段的ACK(应答报文),一段一段的向后推进,就像一个滑动窗口一样。

        在滑动窗口中出现丢包应该怎么办?

        1.ACK(应答报文)丢包

        ACK(应答报文)丢包即使不做任何处理也是正确的,如上图,当1-1000序号的数据发送后,接收方返回的1001的确认序号( ACK(应答报文))出现了丢失,但后面1001-2000序号的数据发送后,接收方返回的2001的确认序号( ACK(应答报文))没有出现丢失,而2001的确认序号就表名在2001之前的数据都已经成功接收,其中就包括了1-1000的数据,所以即使 ACK(应答报文)出现了丢失后面的 ACK(应答报文)也能确认之前的数据被成功接收

        所以在滑动窗口中  ACK(应答报文)丢包即使不做任何处理也是正确的

        2.传输的数据丢包

        

         如上图,在滑动窗口批量传输数据时,1001-2000这段数据出现了丢包,此时接收方就没有收到1001-2000这段数据,所以接收方之后返回的确认序号( ACK(应答报文))都是1001,就像是提醒发送端“我想要的是1001这个数据”一样

        当发送端连续收到多次“1001”这样的应答,就会将对应的1001-2000的数据重新发送

        此时接收端收到了1001后,再次返回的确认序号( ACK(应答报文))就是7001了,因为2001-7000的数据接收端之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中

        这种机制叫做“高速重发控制”,也叫“快重传”

        流量控制(滑动窗口的补充)

        

         我们知道,滑动窗口越大,批量传输的数据越多,传输效率越高,但是窗口也不能无限大,窗口要是太大了,就有可能使接收方处理不过来,或者使传输的中间链路处理不过来,这样就会出现丢包,就得重传了,反而还影响了效率

        流量控制就是给滑动窗口“踩踩刹车”,避免窗口太大,导致接收方处理不过来

        流量控制就是根据接收方的处理能力来限制发送方的发送速度(窗口大小)

        那我们如何衡量接收方的处理能力呢?通过接收方的接收缓冲区剩余空间大小来进行衡量,

接收缓冲区剩余空间大小越大,说明接收方的处理能力越强,发送方的发送速度(窗口大小)就可以越大,反之亦然

        发送方如何知道接收方的处理能力呢?接收方接收到数据后都会给发送方发送ACK(应答报文),所以我们将接收方的接收缓冲区剩余空间大小通过ACK(应答报文)反馈给发送方,作为发送方下一次发送数据窗口大小的依据

        如上图,发送端发送了1-1000的数据,接收端返回的ACK(应答报文)不仅有确认序号1001,还有接收端接收缓冲区的剩余空间大小3000字节,发送端收到ACK(应答报文)以后,便知道了接收端接收缓冲区还有3000字节的剩余空间大小,于是发送了1001-4000共3000字节的数据给接收端,当接收端返回的接收缓冲区剩余空间大小为0时,发送端就会不停的发送一个无意义的数据作为探测信号,去获取接收端接收缓冲区剩余空间大小,当不为0时,便可以继续传输数据。

        滑动窗口并不是TCP就一定涉及

        如果通讯双方大规模的传输数据,那么肯定就是滑动窗口

        如果通讯双方传输数据的规模比较少,这个时候就不会用滑动窗口了,依然按照之前的发一个数据就等待一个ACK(应答报文)的方式工作

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小林想被监督学习

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值