超时重传是按时间来驱动的，如果是网络状况真的不好的情况，超时重传没问题，但是如果网络状况好的时候，只是恰巧丢包了，那等这么长时间就没必要。
于是又引入了数据驱动的重传叫快速重传，什么意思呢？就是发送方如果连续三次收到对方相同的确认号，那么马上重传数据。
因为连续收到三次相同 ACK 证明当前网络状况是 ok 的，那么确认是丢包了，于是立马重发，没必要等这么久。
看起来好像挺完美的，但是你有没有想过我发送1、2、3、4这4个包，就 2 对方没收到，1、3、4都收到了，然后不管是超时重传还是快速重传反正对方就回 ACK 2。
这时候要重传 2、3、4 呢还是就 2 呢？
SACK 的引入是为了解决什么问题？SACK 即 Selective Acknowledgment，它的引入就是为了解决发送方不知道该重传哪些数据的问题。
我们来看一下下面的图就知道了。
SACK 就是接收方会回传它已经接受到的数据，这样发送方就知道哪一些数据对方已经收到了，所以就可以选择性的发送丢失的数据。
如图，通过 ACK 告知我接下来要 5500 开始的数据，并一直更新 SACK，6000-6500 我收到了，6000-7000的数据我收到了，6000-7500的数据我收到了，发送方很明确的知道，5500-5999 的那一波数据应该是丢了，于是重传。
而且如果数据是多段不连续的， SACK 也可以发送，比如 SACK 0-500,1000-1500，2000-2500。就表明这几段已经收到了。
D-SACK 又是什么东西？D-SACK 其实是 SACK 的扩展，它利用 SACK 的第一段来描述重复接受的不连续的数据序号，如果第一段描述的范围被 ACK 覆盖，说明重复了，比如我都 ACK 到6000了你还给我回 SACK 5000-5500 呢？
说白了就是从第一段的反馈来和已经接受到的 ACK 比一比，参数是 tcp_dsack，Linux 2.4 之后默认开启。
那知道重复了有什么用呢？
1、知道重复了说明对方收到刚才那个包了，所以是回来的 ACK 包丢了。
2、是不是包乱序的，先发的包后到？
3、是不是自己太着急了，RTO 太小了？
4、是不是被数据复制了，抢先一步呢？
我们已经知道了 TCP 有序号，并且还有重传，但是这还不够，因为我们不是愣头青，还需要根据情况来控制一下发送速率，因为网络是复杂多变的，有时候就会阻塞住，而有时候又很通畅。
所以发送方需要知道接收方的情况，好控制一下发送的速率，不至于蒙着头一个劲儿的发然后接受方都接受不过来。
因此 TCP 就有个叫滑动窗口的东西来做流量控制，也就是接收方告诉发送方我还能接受多少数据，然后发送方就可以根据这个信息来进行数据的发送。
以下是发送方维护的窗口，就是黑色圈起来的。
图中的 #1 是已收到 ACK 的数据，#2 是已经发出去但是还没收到 ACK 的数据，#3 就是在窗口内可以发送但是还没发送的数据。#4 就是还不能发送的数据。
然后此时收到了 36 的 ACK，并且发出了 46-51 的字节，于是窗口向右滑动了。
TCP/IP Guide 上还有一张完整的图，画的十分清晰，大家看一下。
上文已经说了发送方式根据接收方回应的 window 来控制能发多少数据，如果接收方一直回应 0，那发送方就杵着？
你想一下，发送方发的数据都得到 ACK 了，但是呢回应的窗口都是 0 ，这发送方此时不敢发了啊，那也不能一直等着啊，这 Window 啥时候不变 0 啊？
于是 TCP 有一个 Zero Window Probe 技术，发送方得知窗口是 0 之后，会去探测探测这个接收方到底行不行，也就是发送 ZWP 包给接收方。
具体看实现了，可以发送多次，然后还有间隔时间，多次之后都不行可以直接 RST。
假设接收方每次回应窗口都很小怎么办？你想象一下，如果每次接收方都说我还能收 1 个字节，发送方该不该发？
TCP + IP 头部就 40 个字节了，这传输不划算啊，如果傻傻的一直发这就叫 Silly Window。