上一篇讲到了TCP 的超时重传，但是超时重传往往会带来许多微妙的问题，比如说：
当一个报文段丢失时，会等待一定的超时周期然后才重传分组，增加了端到端的时延。
当一个报文段丢失时，在其等待超时的过程中，可能会出现这种情况：其后的报文段已经被接收端接收但却迟迟得不到确认，发送端会认为也丢失了，从而引起不必要的重传，既浪费资源也浪费时间。
幸运的是，由于TCP采用的是累计确认机制，即当接收端收到比期望序号大的报文段时，便会重复发送最近一次确认的报文段的确认信号，我们称之为冗余ACK（duplicate ACK）。
如图所示，报文段1成功接收并被确认ACK 2，接收端的期待序号为2，当报文段2丢失，报文段3失序到来，与接收端的期望不匹配，接收端重复发送冗余ACK 2。
这样，如果在超时重传定时器溢出之前，接收到连续的三个重复冗余ACK（其实是收到4个同样的ACK，第一个是正常的，后三个才是冗余的），发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，不需要等待超时重传定时器溢出，大大提高了效率。这便是快速重传机制。
二、为什么是3次冗余ACK
首先要明白一点，即使发送端是按序发送，由于TCP包是封装在IP包内，IP包在传输时乱序，意味着TCP包到达接收端也是乱序的，乱序的话也会造成接收端发送冗余ACK。那发送冗余ACK是由于乱序造成的还是包丢失造成的，这里便需要好好权衡一番，因为把3次冗余ACK作为判定丢失的准则其本身就是估计值。
假定通信双方如下：
A为发送端，B为接收端
A的待发报文段序号为 N-1,N,N+1,N+2
假设报文段N-1成功到达
`
从以上罗列的情况可以看出，
在没丢失的情况下，有40%的可能出现3次冗余ACK
在乱序的情况下必定是2次冗余ACK
在丢失的情况下，必定出现3次冗余ACK
基于这样的概率，选定3次冗余ACK作为阈值也算是合理的。在实际抓包中，大多数的快速重传都会在大于3次冗余ACK后发生。
三、快速重传应用实例
快速重传机制比较好理解，这里贴上笔者做的两幅图供大家学习参考，若有建议可以提出。第一幅图是在某报文段的超时重传定时器溢出前重传丢失报文段，第二幅图是对应的接收端缓存队列的窗口移动示意。
