TCP/IP卷一:88---TCP拥塞控制之（伪RTO处理——Eifel响应算法）

• 在“TCP数据流与窗口管理”已经提到，若TCP出现突发的延时，即使没有出现丢包，也可能造成重传超 时的假象。这种伪重传现象的发生可能由于链路层的某些变化(如蜂窝转换)，也可能是由 于突然出现严重拥塞造成RTT大幅增长。当出现重传超时, TCP会调整ssthresh并将cwnd 置为IW，从而进人慢启动状态。假如没有出现实际丢包，在RTO之后到达的ACK会使得 cwnd快速增大，但在cwnd和ssthesh值重新稳定前，仍然会有不必要的重传，浪费传输 资源
• 针对上述问题已有相关探测方法。我们在“TCP超时与重传”中讨论了其中的一些方法(如DSACK、 Eifel、 F-RTO)。其中任一探测方法只要结合相关响应算法,就能“还原” TCP对拥塞控 制变量的操作。一种比较常用(即在IETF标准化过程中)的响应算法就是Eifel响应算法 [RFC4015]
• Eifel算法包含检测算法和响应算法两部分，两者在理论上是独立的。任何使用Eifel响应算法实现的TCP操作，必须使用相应的标准操作规范或实验RFC(即被记录的RFC)中 定的检测算法
• Eifel响应算法用于处理重传计时器以及重传计时器超时后的拥塞控制操作。这里我们只讨论与拥塞相关的响应算法。在首次发生超时重传时，Eifel算法开始执行。若认为出现伪 重传情况，会撤销对ssthresh值的修改。在所有情况下，若因RTO而需改变ssthresh值，在 修改前需要记录一个特殊变量：pipe_prev=min (在外数据值,ssthresh)。然后需要运行一 个检测算法(即之前提到的检测方法中的某个)来判断RTO是否真实。假如出现伪重传，则当到达一个ACK时，执行以下步骤：

• 在改变ssthresh之前需要设置pipe_prev变量。pipe_prev用于保存ssthresh的记录值，以便在步骤3中重设ssthresho步骤1针对带ECN标志位的ACK的情况(在后面将详细讨论ECN)。这种情况下撤销ssthresh修改会引人不安全因素，所以算法终止。步骤2和步骤3是算法的主要部分(针对cwnd)。步骤2将cwnd设置为一定值，允许不超过IW的新数据进人传输通道。因为即使在未知链路拥塞与否的状况下,发送Iw的新数据也被认为是 安全的。步骤3在真正的RTO发生前重置ssthresh，至此撤销操作完成