一、摘要
在上一篇TCP 滑动窗口原理介绍文章中,我们对 TCP 的滑动窗口原理进行一次总结,也提到了流量控制和拥塞控制。
本文我们重点来说说 TCP 的流量控制和拥塞控制的实现。
话不多说,直接上干货!
二、流量控制
在上文中我们提到,TCP 通过接受方实际能接收的数据量来控制发送方的窗口大小,从而实现所谓的流量控制。
理想的情况下,假如不受外界影响,两台计算机在整个传输过程中,可以保持基本相同的窗口大小值。
而实际的情况,很难做到这一点,因为外部环境比较复杂,可能会出现一些意想不到的问题。
下面我们一起来看看有哪些因素可能会影响窗口大小值。
2.1、影响滑动窗口大小的因素介绍
在实际的数据传输过程中,发送方的窗口大小主要依赖于接受方的可用窗口大小来计算。
因此如果接受方的可用窗口发生变化,发送方的窗口大小也必然会发生变化。
比较常见能影响接受方的可用窗口发生变化的因素,有如下几个:
- 接受方的应用程序没办法及时读取数据,此时会影响滑动窗口大小值
- 接受方的系统资源非常紧张,操作系统可能直接减少可用窗口大小的缓存空间
我们先看看第一个案例!
根据上图描述,大致的过程说明如下:
- 1.发送窗口和接收窗口初始大小为 360,客户端发送 140 字节数据后,可用窗口变为 220
- 2.服务端收到 140 字节数据后,可能因为某种阻塞,应用进程只读取了 40 个字节,还有 100 字节存在缓冲区,于是接收窗口收缩到了 260 (360 - 100),最后发送确认信息时,将窗口大小通过给客户端。
- 3.客户端收到确认和窗口通告报文后,发送窗口减少为 260
- 4.客户端再发送 180 字节数据,此时可用窗口减少到 80
- 5.服务端收到 180 字节数据后,可能又因为某种阻塞,应用程序没有读取任何数据,这 180 字节就直接留在了缓冲区,于是接收窗口收缩到了 80 (260 - 180),并再次发送确认信息时,通过窗口大小给客户端。
- 6.客户端收到确认和窗口通告报文后,发送窗口减少为 80
- 7.客户端发送 80 字节数据后,可用窗口变成 0
- 8.服务端收到 80 字节数据后,应用程序依然没有读取数据,这 80 字节留在了缓冲区,于是接收窗口收缩到了 0,并在发送确认信息时,通过窗口大小给客户端
- 9.最后发送方和接收方,可用窗口都变成 0
当可用窗口都收缩为 0,会发生了窗口关闭,这个对数据传输会造成非常严重的影响,具体等会在说。
我们继续看看第二个案例!
当服务端系统资源非常紧张的时候,操作系统可能会直接减少了接收方的缓冲区大小,此时应用程序又无法及时读取缓存数据,那么这时候就有严重的事情发生了,会出现数据包丢失的现象。
根据上图描述,大致的过程说明如下:
- 1.客户端发送 140 字节的数据,于是可用窗口减少到了 220
- 2.服务端收到 140 字节数据后,因为系统资源紧张,操作系统直接减少接收方的缓存空间,于是可用窗口大小收缩成 100 字节,此时又因为应用程序没有读取数据,收到的 140 字节一直留在了缓冲区中,最后发送确认信息时,通告窗口大小给对方。
- 3.可能客户端因为还没有收到服务端的通告窗口报文,不知道此时接收方的窗口收缩成了 100,客户端只会看自己的可用窗口还有 220,所以客户端就发送了 180 字节数据,于是可用窗口减少到 40。
- 4.服务端收到了 180 字节数据时,发现数据大小超过了接收窗口的大小,于是就把数据包丢弃掉。
- 5.客户端此时收到第 2 步服务端发送的确认报文和通告窗口报文,尝试减少发送窗口到 100,把窗口的右端向左收缩了 80,此时可用窗口的大小就会出现的负值。
因此,从上面的分析中可以发现,如果发生了先减少缓存,再收缩窗口,就会出现数据丢包的现象。
为了防止这种情况发生,TCP 规定是不允许先减少缓存又收缩窗口的,而是采用先收缩窗口,然后告知发送方,过段时间再减少缓存,这样就可以避免了丢包情况。
2.2、窗口关闭的问题
上文中我们提到当可用窗口都收缩为 0,会发生了窗口关闭,此时发送方会停止向接受方传递数据,直到接受方可用窗口变成非 0,再次向发送方通告可用窗口的大小,最后发送方再次重新发起数据传输。
如果这个接受方向发送方通告窗口的 ACK 报文在网络中丢失了,可能会造成死锁!
根据上图描述,大致的过程说明如下:
- 1.发送方向接受方发完 1001~2000 的数据,收到接受方的 ack 报文之后,可用窗口为 0
- 2.发送方不在向接受方传递数据,并且等待接受方的非 0 窗口通知
- 3.过了一段时间之后,接受方处理完数据,可用窗口增大,向发送方通告可用窗口的报文,很不幸,ack 报文丢失了
- 4.最后发送方和接受方,等在默默的等待对方的报文数据,造成了死锁的现象
因此,当发送方一直等待接收方的非 0 窗口通知,接收方也一直等待发送方的数据,如果不采取干预措施,这种相互等待的过程,会造成了死锁的现象。
为了解决这个问题,TCP 为每个连接设有一个持续定时器,只要 TCP 连接一方收到对方的 0 窗口通知,就启动持续计时器。
如果持续计时器超时,就会发送窗口探测 ( Window probe ) 报文,而对方在确认这个探测报文时,给出自己现在的接收窗口大小。
根据上图描述,大致的过程说明如下:
- 1.如果接收窗口仍然为 0,那么收到这个报文的一方就会重新启动持续计时器
- 2.如果接收窗口不是 0,那么死锁的局面就可以被打破了
窗口探查探测的次数一般为 3 次,每次大约 30-60 秒(不同的操作系统实现可能会不一样)。如果 3 次过后接收窗口还是 0 的话,有的 TCP 实现就会发 RST 报文来中断连接。
2.3、糊涂窗口综合症
在上文中,我们提到可能因为接受方阻塞,来不及取走接收窗口里的数据,导致发送方的窗口越变越小。
到最后,可能接收方腾出几个字节并告诉发送方现在有几个字节的窗口,而发送方会义无反顾地发送这几个字节,这就是糊涂窗口综合症。
就好像一个可以承载 50 人的大巴车,每次来了一两个人,就直接发车,这样玩下去,司机迟早要破产不可。
要解决这个问题其实也不难,等乘客数量超过一半,也就是 25 个,就进行发车。
解决糊涂窗口综合症,主要从以下两个方向入手:
- 让接收方不通告小窗口值给发送方
- 让发送方避免发送小数据
接收方通常的解决策略如下:
当窗口大小小于 min( MSS,缓存空间/2 ) ,也就是小于 MSS 与 1/2 缓存大小中的最小值时,就会向发送方通告窗口为 0,也就阻止了发送方再发数据过来。等到接收方处理了一些数据后,窗口大小 >= MSS,或者接收方缓存空间有一半可以使用,就可以把窗口打开让发送方发送数据过来。
发送方通常的解决策略如下:
使用 Nagle 算法来处理,该算法的思路是延时处理,它满足以下两个条件中的一条才可以发送数据:
- 要等到窗口大小 >= MSS 或是 数据大小 >= MSS
- 收到之前发送数据的 ack 回包
如果没满足上面条件中的一条,发送方就一直在囤积数据,直到满足上面的发送条件。
三、拥塞控制
在上文中我们也提到,面对复杂的网络环境,TCP 的流量控制能解决的问题比较有限,尤其是当网络出现拥堵的时候,这个时候 TCP 会采用拥塞控制来解决。
拥塞控制,其目的就是避免发送方的数据填满整个网络!
为了在发送方调节所要发送的数据量,我们需要定义了一个叫做拥塞窗口的概念,使用cwnd
来表示。
在前面我们有提到过发送窗口swnd
大小,取自于接收窗口rwnd
的大小,假设没有外部因素的影响,两者基本上是约等于的关系。
由于入了拥塞窗口的概念后,此时发送窗口的值是 swnd = min(cwnd, rwnd)
,也就是拥塞窗口和接收窗口中的最小值。
拥塞窗口cwnd
值的变化情况,取自于网络环境
- 当网络出现拥堵,
cwnd
就会变小 - 当网络没有出现拥堵,
cwnd
就会变大
那 TCP 是如何知道当前网络是否出现拥堵呢?
一般来说,只要发送方没有在规定时间内接收到 ACK 应答报文,也就是发生了超时重传,就会认为网络出现了拥塞。
当网络出现拥塞时,TCP 主要有以下四种主要的算法来控制发送量。
- 慢启动算法
- 拥塞避免算法
- 拥塞发生算法
- 快速恢复算法
下面我们依次来看看具体的实现逻辑。
3.1、慢启动算法
TCP 在刚建立完连接后,首先是有个慢启动的过程,这个慢启动的意思就是一点一点的提高发送数据包的数量,防止一下子发送大量的数据,填充整个网络。
慢启动的算法,就一个规则:当发送方每收到一个 ACK,拥塞窗口cwnd
的大小就会加 1。
整个慢启动的过程,可以用下图来描述。
其中cwnd=1
表示可以传一个 MSS 大小的数据。
可以看出慢启动算法,发包的个数是成指数性的增长。
那是不是可以无限的增长呢?
答案肯定不是,慢启动有个门限ssthresh
变量值。
- 当
cwnd < ssthresh
时,使用慢启动算法 - 当
cwnd >= ssthresh
时,就会使用拥塞避免算法
下面我们再来看看拥塞避免算法!
3.2、拥塞避免算法
当拥塞窗口cwnd
超过慢启动门限ssthresh
就会进入拥塞避免算法。
进入拥塞避免算法后,它的规则也比较简单:每当收到一个 ACK 时,cwnd
增加1/cwnd
。
假定ssthresh
为 8,可以用下图来描述增长过程。
当 8 个 ACK 应答确认到来时,每个确认增加1/8
,8 个 ACK 确认,cwnd
一共增加 1,于是这一次能够发送 9 个 MSS 大小的数据,变成了线性增长。
所以,可以发现,拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长,还是增长阶段,但是增长速度缓慢了一些。
就这么一直增长着,网络也可能会出现拥塞,一旦出现拥塞,就可能会出现丢包现象,这时就需要对丢失的数据包进行重传。
当触发了重传机制,也就进入了拥塞发生算法阶段。
3.3、拥塞发生算法
当网络出现拥塞,也就是会发生数据包重传,此时会使用拥塞发生算法,重传机制主要上文介绍的两种:
- 超时重传
- 快速重传
当发生超时重传时,sshresh 和 cwnd 的值会发生如下变化:
ssthresh
设为cwnd/2
cwnd
重置为1
整个过程可以用如下图来描述!
当进入超时重传的时候,基本上就重新进入了慢启动过程,慢启动的过程就是会突然减少数据流的,然后重新开始。
除此之外,还有另一种快速重传的机制,当接收方发现丢了一个中间包的时候,发送方收到 3 次重复的 ACK,会进入快速重传阶段,不必等待超时重传。
当发生快速重传时,sshresh 和 cwnd 的值会发生如下变化:
cwnd
设为cwnd/2
ssthresh
设置为cwnd
然后进入快速恢复算法阶段。
3.4、快速恢复算法
快速重传和快速恢复算法一般同时使用,快速恢复算法是认为,你还能收到 3 个重复 ACK 说明网络也不那么糟糕,所以没有必要像超时重传那样重新开始。
进入快速恢复算法之后,主要的调整如下:
cwnd
设置为ssthresh + 3
( 3 的意思是确认有 3 个数据包被收到了)- 重传丢失的数据包
- 如果再收到重复的 ACK,那么
cwnd
增加 1 - 如果收到新数据的 ACK 后,
ssthresh
设置为cwnd
,接着就进入了拥塞避免算法
整个过程可以用如下图来描述!
采用快速恢复算法,依然可以保持比较高的数据传输,不至于向超时重传那样,重新开始!
四、小结
本文整理了一些优秀网友分享的知识,结合自己的理解比较全面的探讨了 TCP 滑动窗口的原理,同时抽取了一些比较干活的内容进行介绍,希望对大家有所帮助。
实际上 TCP 涉及到的知识点比我们介绍的要多得多,如果有描述不对的地方,欢迎网友留言指出!
总的来说,TCP 滑动窗口主要有以下作用:
- 1.相比传统的发送一个包,当收到确认应答再发送下一个数据包的传输模式下,滑动窗口这种一次性批量发包然后批量等待确认应答的传输方式,可以显著的提升数据传输效率
- 2.TCP 在滑动窗口的基础上提供了流量控制,避免客户端发送的数据量超过服务端的接受能力,导致网络流量无端的浪费和数据包丢失等问题
- 3.TCP 针对网络拥堵问题,提供了拥塞控制,避免发送的数据填满整个网络。
五、参考
六、写到最后
不会有人刷到这里还想白嫖吧?点赞对我真的非常重要!在线求赞。加个关注我会非常感激!
此外,本文已整理到技术笔记中,笔记内容还涵盖 Spring、Spring Boot/Cloud、Dubbo、JVM、集合、多线程、JPA、MyBatis、MySQL 等技术知识。需要的小伙伴可以点击 技术笔记 获取!