5.4 TCP的流量控制
TCP的流量控制
确实,发送数据并不是越快越好,要让对方来得及接收,这就是流量控制
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
先不考虑拥塞的情况,假设B告诉A,我的接收窗口可以接收400,那么A也将自己的发送窗口设置为400。
用自己的语言描述以下整个过程,A把自己的发送窗口设置为400,但是每一次只发送100.
如下图发送seq=1,表示发送数据报的首部为1,seq=101,表示发送数据报的首部为101.
如下图所示,seq=201的数据报发送过程中丢失了。
这时候接收方给发送方发送确认分组了,ACK=1表示是确认分组,ack=201表示201前的数据报都接收到了,rwnd=300,这是第一个流量控制,将接收窗口调整为300,对主机A进行流控。
然后窗口向前滑动,接受完的就可以丢弃。
然后接收窗口就可以相应改变为新的300.
然后对于201-300的数据的超时重传到了,然后就重传该数据分组,当落入窗口的三个数据分组都发送完毕后,当再次收到501号前的数据的累计确认后,就可以再一次调整窗口。
调整为100后,主机可以发送500到600的数据报。
然后再次收到累计确认,
这次的流量控制,接收窗口调整为0,就甭能再发送数据了。
现在不能再发送了,因为发送窗口被调整为0
而如此主机B这是缓存中又有位置了,可以发送非零窗口给A,通知它可以继续发送。
但是如果恰好此时B发送给A的非零通知丢失了,而A一直在等待B的非零通知,B一直在等待A的数据,这种时候大家互相等待,就会出现TCP的死锁问题
为了解决这个问题,设置了一个持续计时器。
主机A在接收到0窗口通知时,就立即启动一个计时器。当计时器超时时,主机A立即发送一个携带一字节数据的零窗口探测报文段
如果主机B现在还是0,就在接收到零窗口探测报文段后仍然发送主机的接收窗口仍然为0.
主机A再次接收到零窗口,就再次开启一个计时器。
反正没接收到非零时,就一直计时,一直探测。
如果零窗口探测报文丢失了,不怕,
因为零窗口探测报文也有计时器,如果丢失了,就会重传
TCP的拥塞控制
为什么会产生拥塞?
因为我们传到网络上的数据太多了,太大了,大过了硬件所能处理的数据的上限。
所以产生了发的数据来不及传送的状态。
主要是怎么判断拥塞呢
- 重传定时器超时
- 收到三个相同(重复)的ACK
假设第二个分组发送过程中丢失了,即使345都到达了,但是它们都只会返回还未收到2的确认分组ACK。
这里重要的是,收到ACK的时候 只是可能或者即将发生拥塞,而超时就已经是发生拥塞了
慢开始:
第一个轮次只发少量的分组(1个)
然后随着轮次越来越大,发送分组的个数也就越来越多,随指数增长。
- 我们为其设置一个阈值,因为希望拥塞越慢越好,所以再拥塞窗口为16之后,就不要让其指数增长了,就让其每次加1加1。
- 到了遇到超时的状态,这是非常严重的状态,就直接让其恢复到1,让其继续慢开始。而且它的阈值得减为上次超时的拥塞窗口的一半
- 然后发现了3-ACK的拥塞状态,不过这种还好,因为它不是一种很严重的状态,所以不需要回到1.而可以直接让其减到一半,然后再慢慢加1就可以了。
总结一下就是
慢开始,拥塞避免,快重传,快恢复