本文为原创，转载请注明：http://www.cnblogs.com/gistao/
Background
写网络程序的都知道，tcp的窗口控制分为慢启动阶段和拥塞避免阶段，重传机制有快速重传/恢复和超时重传。网上关于快速重传的文章很多，但质量参差不齐，这里对它的设计背景和原理总结下。
Concept
rtt,即网络往返时间。
慢启动过程，指的是请求窗口的变化过程，是指数级的，这变化可不慢吧，这里说它慢是说窗口每次都要从1开始，需要经过好几个rtt才能达到理想的窗口数。
Network traffic
用实时路况描述网络状态比较合适，分成三个状态。
- 畅通
- 发送方发送序列号为1，2，3，4，5的段(包)，立即收到这些1，2，3，4，5段对应的的ack，网络状况非常的好。
- 缓慢
- 发送方发送序列号为1，2，3，4，5的段，由于ack的序列号总是在(请求序列号上＋1)，接收方收到1后立即回复序列号是(1+1=2)的ack，这个2也意味着等待下一个请求序列(2)的段到来，假设2段丢失了，接收方收到3后，这个并不是它预期的，它期望2，所以继续回复序列号是2的ack，同理在收到4和5后，连续发送了三个重复的ack。
- 拥堵
- 接着上边继续说，发送方在rtt时间内连ack都没收到，就表示拥堵了，拥堵的路况比缓慢要差，最起码缓慢路况还是可以收的到ack的。
Fast retransmit
tcp被设计成一个文质彬彬的协议，如果网络丢包了，它会非常谨慎，使用超时重传策略，对应的处理就是从新开始慢启动阶段，然后再进入拥塞避免阶段，所以性能非常的差。所以重传策略要尽可能的使用快速重传/恢复，或者说快速重传/恢复是较理想的重传方式，注意快速重传对应的同序列号ack总共是4个(3个重复＋1个确认)，如果前面举的例子，2段没丢失而3段丢失了，这样只有两个连续重复ack，就不能使用快速重传了。当然有一些针对的优化算法，比如 tlp，fack 等。