Linux 协议栈之虚假重传超时恢复F-RTO：Forward RTO-Recovery

虚假重传超时恢复算法能使得TCP发送方从虚假RTO中有效的恢复重传。基本思想：RTO有两种原因，一是网络上确实发生了丢包，二是由于IP层转发路径延迟不同造成的RTO。对于后者，称之为F-RTO，RTO发生之前的ACK应该发生在RTO发生之后到达发送端。如果一直收不到ACK，证明确实是发生了丢包，此时发送端应该执行go-back-N重传算法。根据以上原则，F-RTO发送端应该：如果第一个RTO重传的ACK advances the Window，则先不要继续重传，继续发送两个新的段。如果第二个ACK仍然advances the Window，那么此RTO应该是F-RTO，因为第二个ACK是初传段的ACK，RTO之后并未重传。如果两个RTO ACK其中有一个是DACK，发送端接下来按照丢包超时恢复算法进行重传。当重传超时，发送端按照下面步骤执行F-RTO算法（其中snd.una表示第一个unAck段）：
1、当重传定时器到时，重传触发超时的段。按照TCP拥塞控制，ssthresh调整为当前发送窗口的一般，然后等收到两个ACK之后再决定如何改变cwnd。
2、当RTO之后的第一个ACK到达发送端，发送端先判断此ACK advances the window还是DACK，再进行不同的选择：
a)如果此ACK advances snd.una，发送两个初传的段。这是F-RTO与传统超时重传算法主要的不同点。发送这两个段之后，cwnd调整为ssthresh大小。此时发送端发送速率变为RTO发生前的一半。发送端在RTO之后已经发送了3个段，跟传统RTO超时恢复算法类似。如果由于接收窗口的限制而导致这两个段没能发送，或者没有新的段需要发送了，发送端可以只发送一个段。如果此时有新数据可以发送，则发送端按照传统的RTO恢复和慢开始算法重传之前未得到确认的数据。
b)如果此ACK是DACK，则把cwnd调整为1（个段），并且按照传统RTO恢复算法继续执行。这种情况下，并不发送两个初传的段，因为传统RTO恢复算法此时也不会发送任何初传段。相反，F-RTO发送端按照传统RTO慢开始算法重传之前未得到确认的数据。这种情况下不存在F-RTO算法步骤3所描述的场景。执行此分支的原因通常是发生了丢包，因为RTO之前发送的包仍然会使得发送方在RTO之后收到DACK。
3、当RTO之后的第二个ACK到达发送端，是继续发送新数据还是按照慢开始算法开始重传取决于新数据是否得到确认。
a)此ACK advances snd.una，则继续按照拥塞避免算法发送新数据。因为发送端在RTO之后只重传了一个段，此ACK说明一个初传段已经到达接收端。此时虚假RTO的可能性最大。然而，因为发送端不能由此确定导致RTO的段是否真的丢失了，调整RTO之后的拥塞控制参数是一种保守的做法。从这点看，发送端继续执行拥塞避免算法。如果执行了这个分支，发送端忽略指示已发送段最大序号的send_high变量。（send_high是在NewReon算法中提出的为了避免多重快重传而提出的一个参数，由于发送端此时只会重传造成了RTO的那个段，所以多重快重传此时是不会出现的）。因此，如果DACK在RTO之后到达发送端，则RTO的真实原因更可能是丢包了。此后，翻译不了了...
b)如果此ACK是DACK，则把cwnd设为3（个段），继续以慢开始算法重传未得到确认的段。此DACK说明至少一个段丢失了。没有充足的证据表明有段发生延时，因此，发送端像传统RTO一样继续重传数据，并记住重传定时器到期时的send_high来避免不必要的快重传。