34-tcp拥塞控制——快重传和快恢复

  前面讲的慢开始算法和拥塞避免算法是tcp拥塞控制早期使用的算法,后来又增加了快重传和快恢复这两个算法。

1. 快重传算法

  考虑这么一种情况:假设现在网络没有发生拥塞,但是发送方发送的个别数据包却在网络中某一处丢失了,而此时发送方的超时计时器超时了,又没有收到确认,在这种情况,tcp拥塞控制会误认为出现网络拥塞,然后马上把拥塞窗口cwnd减小到1(即一个mss),并启动慢开始算法,同时把门限值ssthresh减半,这样就降低了通信效率,所以基于这种情况就有了快重传和快恢复两个算法。

  快重传算法首先要求接收方每收到一个失序的分组后就立即发出重复确认,这么做的原因是让发送方及时知道有个别报文分组丢失了,没有到达对方。如图1中,发送方发送了M1和M2分组,分别都收到了确认,现在假设发送方发送的M3在网络中丢失了,接收方没有收到M3但是却收到了M4(注意:此时M4是一个失序分组)。

这里写图片描述
图1-快重传

  按照快重传算法规定:接收方收到失序的M4分组后,应该立即对M2发出重复确认(总共发送三次重复确认),也就是告诉发送方:“我还没收到M3分组”。

  然后发送方又接着发送了M5,M6,接收方收到后就会继续发送重复确认M2。这样发送方收到了接收方三个重复的M2确认。快重传算法规定,只要发送方一连收到了3个重复确认就应该立即重传对方尚未收到的M3,而不是等待超时计时器超时后再进行重传,这样发送方及时重传了丢失的分组,因此快重传算法提高了通信效率。

2. 快恢复算法

  配合快重传算法使用的还有快恢复算法,快恢复算法是这样规定:当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把慢开始的门限值ssthresh减半,这只是发送方提前预防网络拥塞的措施。由于现在发送方认为没有发生网络拥塞(因为发送方连续收到了接收方发送的三个重复的确认,因此认为现在可能没有发生网络拥塞),但此时并不会执行慢开始算法,而是执行拥塞避免中的加法增大算法,使拥塞窗口缓慢增大,如图2所示,重点关注红色部分。

这里写图片描述
图2-快恢复

  从图2中,我们还可以知道,在使用了快恢复算法后,慢开始算法就只会在建立tcp连接和出现超时的时候才会执行,换句话说,采用这种拥塞控制方法改进了tcp通信效率。

这里写图片描述
图3-快重传和快恢复

  在图3中是在tcp流量控制的快重传和快恢复算法,“TCP Reno版本”是目前使用的版本。而“TCP Tahoe”版本已经废弃了,不再使用,注意它们之间的区别:TCP Reno版本在快重传之后采用快恢复算法,而TCP Tahoe版本是采用慢开始算法


3. 流量控制——发送窗口上限

  在前面的学习中,我们总是假设接收方有足够的接收空间,但实际上接收方的接收空间是有限的。另外,我们知道,发送方的发送窗口是由拥塞窗口来决定的,且接收方的接收窗口在建立tcp连接时,告诉发送方自己的窗口大小。因此,从流量控制的角度来考虑,发送方发送的数据一定不能超过接收方的接收能力,也就是说发送方的发送窗口一定是不能大于接收方的接收窗口的,因此,发送窗口大小应该取拥塞窗口cwnd和接收窗口rwnd中较小的一个,那么公式为:

=min(rwnd,cwnd) 发 送 窗 口 上 限 = m i n ( r w n d , c w n d )

  根据上面的公式可知,如果发送窗口大小的值是取cwnd,则说明tcp流量控制算法在控制发送方的数据发送速率,如果发送窗口大小的值是取rwnd,则说明是发送方是按接收方的接收能力来控制发送速率。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值