先理解ACK的基本工作原理，当发送端发送第N-1个包后，接收端答复的ACK序列号实际上跟发送端发送下一个包，也就是第N个包的序列号一致。
重复ACK是指在接收方收到乱序报文时，所发出的一类TCP报文。TCP使用报文头的序列号和确认号以有效保证数据按照发送的顺序接收和重组。当TCP连接建立以后，握手过程中交换的一个最重要的信息是初始序列号（ISN）。一旦连接双方设定了ISN之后，接下来发送的报文所包含的序列号增加一个数据载荷值。
假设有个主机ISN是5000，发送500字节报文至接收方。一旦报文接收之后，接收端回复一个ACK号为5500的TCP ACK报文，基于以下公式：
Sequence Number In + Bytes of Data Received = Acknowledgment Number Out
按照上述计算结果，返回发送端的确认编号实际上是接收端希望收到的序列号。示例如下图： 
下面看为何快速重传是选择3次ACK？
主要的考虑还是要区分包的丢失是由于链路故障还是乱序等其他因素引发。
两次duplicated ACK时很可能是乱序造成的！三次duplicated ACK时很可能是丢包造成
的！四次duplicated ACK更更更可能是丢包造成的！但是这样的响应策略太慢。丢包肯
定会造成三次duplicated ACK!综上是选择收到三个重复确认时窗口减半效果最好，这是
实践经验。
在没有fast retransmit / recovery 算法之前，重传依靠发送方的retransmit timeout，就是
在timeout内如果没有接收到对方的ACK，默认包丢了，发送方就重传，包的丢失原因
1）包checksum 出错 2）网络拥塞 3）网络断，包括路由重收敛，但是发送方无法判断
是哪一种情况，于是采用最笨的办法，就是将自己的发送速率减半，即CWND 减为
1/2，这样的方法对2是有效的，可以缓解网络拥塞，3则无所谓，反正网络断了，无论发
快发慢都会被丢；但对于1来说，丢包是因为偶尔的出错引起，一丢包就对半减速不合
理。于是有了fast retransmit 算法，基于在反向还可以接收到ACK，可以认为网络并没
有断，否则也接收不到ACK，如果在timeout 时间内没有接收到> 2 的duplicated ACK，
则概率大事件为乱序，乱序无需重传，接收方会进行排序工作；而如果接收到三个或三
个以上的duplicated ACK，则大概率是丢包，可以逻辑推理，发送方可以接收ACK，则
网络是通的，可能是1、2造成的，先不降速，重传一次，如果接收到正确的ACK，则一
切OK，流速依然（包出错被丢）。而如果依然接收到duplicated ACK，则认为是网络拥
塞造成的，此时降速则比较合理。