云南龙网

  1. 首页 > 云知道 > >

TCP快速恢复算法NewReno修正( 三 )

云知道


在这种情况下 ， 假如拥塞窗口没有减小 ， 数据端可能能够紧接着发送将近一个窗口的数据 。
上面描述的对部分确认的简单响应可能有许多变形 。首先 ， 一个问题是部分确认之后何
时重设定时器 。这在下面的第4节进一步讨论 。
一个相关的问题是在每一个部分确认之后 ， 重传多少数据包 。上面描述的算法在每个部
分确认之后重传一个数据包 。这是最保守的选择 ， 因为这种办法最没有可能导致一个没有必
要重传的数据包 。有效地慢启动也是一个变形 ， 它能从丢失了许多数据包的窗口中更快地恢
复过来 ， 但是要求从丢失了N个数据包[Hoe96]的恢复必须少于N往返时间 。对部分确认采
用这种稍微激烈一点的响应的话 ， 在每个重传之后重设重传定时器就会很有利 。因为我们还
没有在我们的模拟器上试验这种变形 ， 我们在这篇文档中不会进一步对此进行讨论 。
第三个问题是避免由接收端已经到的数据包的重传引起的多次快速重传 。这在下面的第
5节中讨论 。避免多次快速重传在对部分确认采用更激烈的响应的情况下非凡重要 ， 因为在
这种情况下 ， 发送端更可能重传接收端已经接收的数据包 。
最后 ， 我们考察一下没有SACK选项的情况 ， 数据发送端在没有足够信息的情况下工作 。
一个发送端可能花很长时间仔细考虑在这种情况哪个快速恢复的变形对这种环境是最优的 。
因为从丢失了多个数据包的一个窗口中恢复的问题非凡重要 ， 所以最好的选择是使用SACK
选项 。
4.重设重传定时器
第3节的算法仅在第一个部分ACK之后重设重传定时器 。在这种情况下 ， 假如很多数据
包从一个窗口中丢失了 ， TCP数据发送端的重传定时器最终将超时 ， 接着TCP数据发送端将
调用慢启动 。（这在[F98]在12页中被例证 。）我们称此为NewReno的Impatient变形 。
相反地 ， [FF96]中的NewReno模拟例证了上面描述的算法 ， 不同的是重传定时器在每个
部分确认之后都要重设 。我们称此为Slow-but-Steady变形 。在这种情况下 ， 对于一个丢失
了大量数据包的窗口来说 ， TCP数据发送端每个往返时间至少发送一个数据包 。（这种行为
在[FF96]中的NewRenoTCP模拟和[F98]的11页中被例证 。）
对于超时重传值（RTO）一般不大于往返时间（RTT）的TCP实现来说 ， Impatient变形
即使在只有少量数据包丢失的情况下也会导致一个超时重传 。对于超时重传值（RTO）一般
远大于往返时间(RTT)的TCP实现来说 ， Slow-but-Steady变形当多个数据包从一个窗口中
丢失时能够长时间维持快速恢复 。这些变形没有一个是最优的；一个更优的算法可能是某个
从多个数据包丢失中迅速恢复 ， 并且在重设重传定时器时与Slow-but-Steady进行混合的算
法 。然而我们注重到 ， 在没有SACK选项的情况下 ， 对潜在性能有个限制 。
5.避免多次快速重传
在没有SACK选项时 ， 一个重复确认没有携带任何有关信息 ， 这种信息是用来确定TCP
数据接收端触发重复确认的一个或多个数据包的 。TCP数据发送端不能把区分重复确认是由
数据包丢失或延时引起的 ， 还是由发送端重传了一个TCP接收端已经接收到的数据包引起
的 。由于这个原因 ， 一个窗口的多个数据段丢失某些时候能导致不必要的多次重传（以及拥
塞窗口的多次缩减）[Flo94] 。
在Reno或NewRenoTCP中使用了快速重传和快速恢复算法的话 ， 由多次快速重传引起
的性能问题就相对小一些（和TahoeTCP的潜在问题相比 ， 它没有实现快速恢复） 。然而 ，

推荐阅读


上一篇：磁铁怎么给电视机消磁

下一篇：空心菜炒肉的做法