引言
TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。对任何实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传的频率。
超时与重传的简单例子
首先观察TCP所使用的重传机制，我们将建立一个连接，发送一些分组来证明一切正常，然后拔掉电缆，发送更多的数据，再观察TCP的行为。
下图表示的是tcpdump的输出结果（已经去掉了bsdi设置的服务类型信息）。
第1、2和3行表示正常的TCP连接建立的过程，第4行是“hello, world”（1 2个字符加上回车和换行）的传输过程，第5行是其确认。接着我们从svr4拔掉了以太网电缆，第6行表示"and hi"将被发送。第7 ~ 18行是这个报文段的12次重传过程，而第1 9行则是发送方的TCP最终放弃并发送一个复位信号的过程。
现在检查连续重传之间不同的时间差，它们取整后分别为 1、3、6、12、24、48和多个6 4秒。在本章的后面，我们将看到当第一次发送后所设置的超时时间实际上为 1.5秒，此后该时间在每次重传时增加1倍并直至64秒。这个倍乘关系被称为"指数退避 (exponential backoff)"
首次分组传输（第6行，24 . 4 80秒）与复位信号传输（第19行，566.488秒）之间的时间差约为9分钟，该时间在目前的TCP实现中是不可变的。
快速重传与快速恢复算法
拥塞避免算法的修改建议1 9 9 0年提出 [Jacobson 1990b]。
在介绍修改之前，我们认识到在收到一个失序的报文段时， TCP立即需要产生一个ACK（一个重复的ACK）。这个重复的ACK不应该被迟延。该重复的ACK的目的在于让对方知道收到一个失序的报文段，并告诉对方自己希望收到的序号。
由于我们不知道一个重复的ACK是由一个丢失的报文段引起的，还是由于仅仅出现了几个报文段的重新排序，因此我们等待少量重复的ACK到来。假如这只是一些报文段的重新排序，则在重新排序的报文段被处理并产生一个新的ACK之前，只可能产生1 ~ 2个重复的ACK。
如果一连串收到3个或3个以上的重复ACK，就非常可能是一个报文段丢失了。于是我们就重传丢失的数据报文段，而无需等待超时定时器溢出。这就是快速重传算法。接下来执行的不是慢启动算法而是拥塞避免算法。这就是快速恢复算法。
在下图中可以看到在收到3个重复的ACK之后没有执行慢启动。相反，发送方进行重传，接着在收到重传的ACK以前，发送了3个新的数据的报文段（报文段67, 69和7 1）。
在这种情况下没有执行慢启动的原因是由于收到重复的ACK不仅仅告诉我们一个分组丢失了。
由于接收方只有在收到另一个报文段时才会产生重复的ACK，而该报文段已经离开了网络并进入了接收方的缓存。也就是说，在收发两端之间仍然有流动的数据，而我们不想执行慢启动来突然减少数据流。
这个算法通常按如下过程进行实现：
1) 当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的报文段。设置cwnd为ssthresh加上3倍的报文段大小。
2) 每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送 1个分组（如果新的cwnd允许发送）。
3) 当下一个确认新数据的ACK到达时，设置cwnd为ssthresh（在第1步中设置的值）。这个
ACK应该是在进行重传后的一个往返时间内对步骤 1中重传的确认。另外，这个ACK也应该是对丢失的分组和收到的第1个重复的ACK之间的所有中间报文段的确认。这一步采用的是拥塞避免，因为当分组丢失时我们将当前的速率减半。
快速重传算法最早出现在 4.3BSD Ta h o e版本中，但它随后错误地使用了慢启动。
快速恢复算法出现在4.3BSD Reno版本中。