自学内容网 自学内容网

TCP的滑动窗口和拥塞控制

当我们使用TCP,从客户端发送数据到服务器,这个过程会是怎样的呢?
首先,当然是耳熟能详的三次握手过程,那当连接建立之后,就一股脑发送所有数据吗?
当然不是,一下子发送太多数据,接收端可能没有那么大的空间,就浪费了流量。
TCP使用滑动窗口来管理发送方和接收方之间的数据传输量。滑动窗口通过控制未确认数据包的数量,确保发送方发出的包不会超出接收方的处理能力。

滑动窗口

滑动窗口的工作机制如下:

  • TCP在每个ACK包中,通知对方自己目前能接收多少数据,即TCP头部中的窗口大小(三次握手期间的ACK也会包含窗口大小)。
  • 发送方可以在这个窗口大小内,连续发送多个数据包,而不必等待每个数据包的确认。
  • 当发送方收到接收方的ACK确认,窗口就会向前滑动,允许发送方继续发送新的数据包。

在某个时间段,发送方的TCP数据流如下图所示,可以分成4个部分:
在这里插入图片描述

  • 已发送且已确认的数据:这部分数据已经没用了,不再需要保存。
  • 已发送但未确认的数据:需要保存在缓冲区里,如果丢包了,可以进行重传。
  • 未发送,允许发送的数据:没有超过接收方缓冲区,可以发送数据。
  • 未发送,不允许发送的数据:超过对方缓冲区,不可以发送。

滑动窗口的优点:

  • 高效利用带宽:滑动窗口允许发送方连续发送多个数据包,而无需等待每个数据包的确认,从而提高了带宽利用率。
  • 流量控制:通过动态调整窗口大小,滑动窗口机制能有效控制数据流量,防止网络拥堵。

窗口满的情况

在接收方看来,数据可以分成三个部分:

  • 成功接收并确认的数据
  • 未收到但可以接收的数据
  • 未收到且不可接收的数据
    在这里插入图片描述

未收到但可以接收的部分,就是接收方的窗口大小。
接收方收到数据后,会存放到缓冲区中,等待上层应用获取数据(socket调用read函数)。
如果上层应用繁忙,读取效率较低,那么这个窗口就会慢慢变小,甚至会变成0,也就是窗口满的情况。
这时候,接收方会发送一个ZeroWindow的包,告诉发送方,这边已经不能再接收数据了,发送方就不再发送数据。
等到缓冲区的数据被读取之后,接收方会发一个WindowUpdate的ACK,告诉发送方自己最新的窗口大小,发送方就可以继续发送数据了。

但是这里有个问题,如果这个WindowUpdate的包丢失了的话,发送方就只能继续保持0窗口,数据在这里就卡住不再发送了。
为了解决这个问题,TCP设置了定时探测,发送ZeroWindowProbe,获取接收端最新的窗口大小。
在这里插入图片描述

TCP协议本身并没有一个明确的Window Full标记。然而,在实际使用中,有些网络监测工具和协议分析器(例如Wireshark)会标识或标记某些数据包,以表明发送方的发送窗口已经完全被使用。这种标记主要是用来帮助用户理解和分析TCP连接中的流量控制和拥塞控制情况。

糊涂窗口综合症

当接收方缓冲区满时,窗口关闭,如果应用层读取了一个字节的数据,此时缓冲区就有了一个字节的空间,这时候立刻发送WindowUpdate通知发送方的话,那发送方就可能发一个字节的数据过来,一个TCP包只包含一个字节的数据,这效率就很低下。
这种情况下,这个连接的窗口一直保持在很小的状态,称作糊涂窗口综合症
为了解决这个问题,当窗口大小小于min(MSS,缓存空间/2) ,也就是小于MSS1/2缓存大小中的最小值时,就会向发送方通告窗口为 0,也就阻止了发送方再发数据过来。
等到接收方处理了一些数据后,窗口大小 >= MSS,或者接收方缓存空间有一半可以使用,才更新窗口大小,让发送方发送数据过来。

拥塞控制

滑动窗口控制的是一个TCP连接的流量,避免发送方的数据填满接收方的缓存。但是,网络上不只一个TCP连接,如果不加以控制的话,就可能发生数据的拥堵,拥堵导致丢包,丢包需要重传,则又加大了拥堵。
所以,TCP使用了拥塞控制来避免数据填满整个网络。

拥塞窗口 cwnd 是发送方维护的一个的状态变量,它会根据网络的拥塞程度动态变化的 。当cwnd=n时,表示发送方可以发送nMSS大小的数据

拥塞控制主要是四个算法:

  • 慢启动
  • 拥塞避免
  • 快速重传
  • 快速恢复
慢启动

慢启动的思路就是,不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加cwnd的大小,其算法如下:

  1. 建立连接后,初始化cwnd1,可以发送1个MSS数据。
  2. 每次收到ACK,则将cwnd加1。
  3. cwnd达到某一个阈值ssthresh(slow start threshold)后,不再使用慢启动,改用拥塞避免算法。

在这里插入图片描述

从上图中,可以看到,每一个rtt时间,cwnd都会翻倍,从而快速地增长。在良好的网络环境下,可以很快达到阈值,进入拥塞避免算法。

在一些现代操作系统中(如 Linux 和 Windows),TCP 初始拥塞窗口的默认值为 10 个 MSS。这使得发送方在建立连接后的初始数据传输中,可以一次发送多达 10 个 MSS 的数据包,而不必经历传统的慢启动阶段。

拥塞避免

慢启动时,起点低,但指数增长,速度快,达到一定程度后,就不能再继续指数增长,以防止拥塞。拥塞避免的想法就是,在一个rtt时间内,让cwnd不是翻倍,而是加一,缓慢增长。
那么,如何让cwnd在一个rtt中加一呢?在慢启动算法中,在某一轮次,cwnd=n,此时连续发送nMSS,每次收到ACKcwnd+1,收到n个则cwnd+n,形成翻倍的效果。同理,只要在每次收到ACK时,将cwnd+1改成cwnd+1/n,那么在nACK后,则形成cwnd+1的结果。

在慢启动和拥塞避免阶段,如果出现超时,则重发超时的数据,然后处理如下:

  • ssthresh设为cwnd/2
  • cwnd设为1
  • 进入慢启动算法
快速重传

当检测是否丢包时,每次都要等待超时的发生,会浪费很长时间,因此引入了快速重传:发送方只要收到3个重复的ACK,即认为丢包发生,此时会立即重传丢失的包,而不再等待超时的出现。

快速恢复

为了解决丢包后进入慢启动引起的效率降低,在快速重传的基础上,又引入了快速恢复,在发生快速重传之后,拥塞控制如下处理:

  • ssthresh设为cwnd/2
  • cwnd设为ssthresh+3(+3是因为已经收到3个重复的ACK)。
  • 如果再收到重复的ACK,则cwnd+1
  • 如果收到新的ACK,则快速恢复结束,进入拥塞避免

参考资料


原文地址:https://blog.csdn.net/lch_boy/article/details/140536454

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!