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)
,也就是小于MSS
与1/2
缓存大小中的最小值时,就会向发送方通告窗口为 0,也就阻止了发送方再发数据过来。
等到接收方处理了一些数据后,窗口大小 >= MSS,或者接收方缓存空间有一半可以使用,才更新窗口大小,让发送方发送数据过来。
拥塞控制
滑动窗口控制的是一个TCP连接的流量,避免发送方的数据填满接收方的缓存。但是,网络上不只一个TCP连接,如果不加以控制的话,就可能发生数据的拥堵,拥堵导致丢包,丢包需要重传,则又加大了拥堵。
所以,TCP使用了拥塞控制来避免数据填满整个网络。
拥塞窗口 cwnd 是发送方维护的一个的状态变量,它会根据网络的拥塞程度动态变化的 。当cwnd=n
时,表示发送方可以发送n
个MSS
大小的数据
拥塞控制主要是四个算法:
- 慢启动
- 拥塞避免
- 快速重传
- 快速恢复
慢启动
慢启动的思路就是,不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加cwnd
的大小,其算法如下:
- 建立连接后,初始化
cwnd
为1
,可以发送1个MSS
数据。 - 每次收到
ACK
,则将cwnd
加1。 cwnd
达到某一个阈值ssthresh
(slow start threshold)后,不再使用慢启动,改用拥塞避免算法。
从上图中,可以看到,每一个rtt
时间,cwnd
都会翻倍,从而快速地增长。在良好的网络环境下,可以很快达到阈值,进入拥塞避免算法。
在一些现代操作系统中(如 Linux 和 Windows),TCP 初始拥塞窗口的默认值为 10 个 MSS。这使得发送方在建立连接后的初始数据传输中,可以一次发送多达 10 个 MSS 的数据包,而不必经历传统的慢启动阶段。
拥塞避免
慢启动时,起点低,但指数增长,速度快,达到一定程度后,就不能再继续指数增长,以防止拥塞。拥塞避免的想法就是,在一个rtt
时间内,让cwnd
不是翻倍,而是加一,缓慢增长。
那么,如何让cwnd
在一个rtt
中加一呢?在慢启动算法中,在某一轮次,cwnd=n
,此时连续发送n
个MSS
,每次收到ACK
则cwnd+1
,收到n
个则cwnd+n
,形成翻倍的效果。同理,只要在每次收到ACK
时,将cwnd+1
改成cwnd+1/n
,那么在n
个ACK
后,则形成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)!