发送端收到3个冗余ACK后，重传冗余ACK指示可能丢失的那个包segment1，如果segment1的ACK通告接收端已经收到发送端的全部已经发出的数据的话，那么就是只丢失一个包，如果没有，那么就是有多个包丢失了。
发送端根据segment1的ACK判断出有多个包丢失，那么发送端继续重传窗口内未被ACK的第一个包，直到sliding window内发出去的包全被ACK了，才真正退出Fast Recovery阶段。
我们可以看到，拥塞控制在拥塞避免阶段，cwnd是加性增加的，在判断出现拥塞的时候采取的是指数递减。为什么要这样做呢？这是出于公平性的原则，拥塞窗口的增加受惠的只是自己，而拥塞窗口减少受益的是大家。这种指数递减的方式实现了公平性，一旦出现丢包，那么立即减半退避，可以给其他新建的连接腾出足够的带宽空间，从而保证整个的公平性。
TCP发展到现在，拥塞控制方面的算法很多，请查看《wiki-》，《斐讯面试记录—TCP滑动窗口及拥塞控制》
总的来说TCP是一个有连接的、可靠的、带流量控制和拥塞控制的端到端的协议。TCP的发送端能发多少数据，由发送端的发送窗口决定(当然发送窗口又被接收端的接收窗口、发送端的拥塞窗口限制)的，那么一个TCP连接的传输稳定状态应该体现在发送端的发送窗口的稳定状态上，这样的话，TCP的发送窗口有哪些稳定状态呢？
TCP的发送窗口稳定状态主要有上面三种稳定状态：
【1】接收端拥有大窗口的经典锯齿状
大多数情况下都是处于这样的稳定状态，这是因为，一般情况下机器的处理速度就是比较快，这样TCP的接收端都是拥有较大的窗口，这时发送端的发送窗口就完全由其拥塞窗口cwnd决定了；网络上拥有成千上万的TCP连接，它们在相互争用网络带宽，TCP的流量控制使得它想要独享整个网络，而拥塞控制又限制其必要时做出牺牲来体现公平性。于是在传输稳定的时候TCP发送端呈现出下面过程的反复
[1]用慢启动或者拥塞避免方式不断增加其拥塞窗口，直到丢包的发生；
[2]然后将发送窗口将下降到1或者下降一半，进入慢启动或者拥塞避免阶段(要看是由于超时丢包还是由于冗余ACK丢包)；过程如下图：
【2】接收端拥有小窗口的直线状态
这种情况下是接收端非常慢速，接收窗口一直很小，这样发送窗口就完全有接收窗口决定了。由于发送窗口小，发送数据少，网络就不会出现拥塞了，于是发送窗口就一直稳定的等于那个较小的接收窗口，呈直线状态。
【3】两个直连网络端点间的满载状态下的直线状态
这种情况下，Peer两端直连，并且只有位于一个TCP连接，那么这个连接将独享网络带宽，这里不存在拥塞问题，在他们处理能力足够的情况下，TCP的流量控制使得他们能够跑慢整个网络带宽。
通过上面我们知道，在TCP传输稳定的时候，各个TCP连接会均分网络带宽的。相信大家学生时代经常会发生这样的场景，自己在看视频的时候突然出现视频卡顿，于是就大叫起来，哪个开了迅雷，赶紧给我停了。其实简单的下载加速就是开启多个TCP连接来分段下载就达到加速的效果，假设宿舍的带宽是1000K/s，一开始两个在看视频，每人平均网速是500k/s，这速度看起视频来那叫一个顺溜。突然其中一个同学打打开迅雷开着99个TCP连接在下载爱情动作片，这个时候平均下来你能分到的带宽就剩下10k/s，这网速下你的视频还不卡成幻灯片。在通信链路带宽固定(假设为W)，多人公用一个网络带宽的情况下，利用TCP协议的拥塞控制的公平性，多开几个TCP连接就能多分到一些带宽(当然要忽略有些用UDP协议带来的影响)，然而不管怎么最多也就能把整个带宽抢到，于是在占满整个带宽的情况下，下载一个大小为FS的文件，那么最快需要的时间是FS/W，难道就没办法加速了吗？