1. 重传机制
TCP 实现可靠传输的方式之一，是通过序列号与确认应答。在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。但是在错综复杂的网络，并不一定能顺利正常的进行数据传输，万一数据在传输过程中丢失，针对这种情况 TCP 就会利用重传机制解决数据丢包的问题。
常见的重传机制：
- 超时重传
- 快速重传
- SACK
- D-SACK
1.1 超时重传
重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是超时重传。
TCP 会在以下两种情况发生超时重传：
- 数据包丢失
-
确认应答丢失
-
RTT（往返时延）：数据从网络一端传送到另一端所需的时间，也就是包的往返时间。
-
RTO：超时重传时间。
RTO的时间长短的区别：
上图中有两种超时时间不同的情况：
当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
所以精确的测量超时时间 RTO 的值是非常重要的，这可让重传机制更加高效。根据上述的两种情况，可以得出结论，超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。
当超时重发的数据再次超时的时候，TCP 的策略是超时间隔加倍。也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
超时触发重传存在的问题是，超时周期可能相对较长。于是就可以用「快速重传」机制来解决超时重发的时间等待。
1.2 快速重传
不以时间为驱动，以数据驱动重传。也就是说，如果包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传。快速重传的好处是不用等timeout了再重传。
在上图，发送方发出了 1，2，3，4，5 份数据：
- 第一份 Seq1 先送到了，于是就 Ack 回 2；
- 结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；
- 后面的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
- 发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
- 最后，接收到收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。
所以，快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。
快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传之前的一个，还是重传所有的问题。对于上面的例子，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不清楚这连续的三个 Ack 2 是谁传回来的。为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。
1.3 SACK
这种方式需要在TCP头里加一个SACK的东西，ACK还是快速重传的ACK，SACK则是汇报收到的数据碎版。参看下图：
发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重发。
如果要支持 SACK，必须双方都要支持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux 2.4 后默认打开）。
1.4 Duplicate SACK
Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。
ACK 丢包
- 「接收方」发给「发送方」的两个 ACK 确认应答都丢失了，所以发送方超时后，重传第一个数据包（3000 ~ 3499）
- 「接收方」发现数据是重复收到的，于是回了一个 SACK = 3000~3500，告诉「发送方」 3000~3500 的数据早已被接收了，因为 ACK 都到了 4000 了，已经意味着 4000 之前的所有数据都已收到，所以这个 SACK 就代表着 D-SACK。
- 「发送方」就知道了，数据没有丢，是「接收方」的 ACK 确认报文丢了。
网络延时
- 数据包（1000~1499） 被网络延迟了，导致「发送方」没有收到 Ack 1500 的确认报文。
- 而后面报文到达的三个相同的 ACK 确认报文，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）又到了「接收方」；
- 所以「接收方」回了一个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。
- 这样发送方就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，而是因为网络延迟了。
Duplicate SACK的好处
- 可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了。
- 可以知道是不是「发送方」的数据包被网络延迟了。
- 可以知道网络中是不是把「发送方」的数据包给复制了。
在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能（Linux 2.4 后默认打开）
2. 滑动窗口
TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。这种方式的缺点是效率比较低的。数据包的往返时间越长，通信的效率就越低。
为解决这个问题，TCP 引入了窗口概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。
有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。如下图：
图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通话下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。
窗口大小由哪一方决定？
TCP 头里有一个字段叫 Window，也就是窗口大小。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
所以，通常窗口的大小是由接收方的决定的。发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。
2.1 发送方的滑动窗口
深蓝色方框是发送窗口，紫色方框是可用窗口
-
#1是已发送并收到 ACK确认的数据：1~31 字节 -
#2是已发送但未收到 ACK确认的数据：32~45 字节 -
#3是未发送但总大小在接收方处理范围内（接收方还有空间）：46~51字节 -
#4是未发送但总大小超过接收方处理范围（接收方没有空间）：52字节以后
在下图，当发送方把数据「全部」都一下发送出去后，可用窗口的大小就为 0 了，表明可用窗口耗尽，在没收到 ACK 确认之前是无法继续发送数据了。
在下图，当收到之前发送的数据 32~36 字节的 ACK 确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被应答确认，接下来 52~56 字节又变成了可用窗口，那么后续也就可以发送 52~56 这 5 个字节的数据了。
程序表示发送方的四个部分
TCP 滑动窗口方案使用三个指针来跟踪在四个传输类别中的每一个类别中的字节。其中两个指针是绝对指针（指特定的序列号），一个是相对指针（需要做偏移）。
-
SND.WND：表示发送窗口的大小（大小是由接收方指定的）； -
SND.UNA：是一个绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。 -
SND.NXT：也是一个绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个字节。 - 指向 #4 的第一个字节是个相对指针，它需要
SND.UNA指针加上SND.WND大小的偏移量，就可以指向 #4 的第一个字节了
那么可用窗口大小的计算就可以是：可用窗口大 = SND.WND -（SND.NXT - SND.UNA）
2.2 接收方的滑动窗口
-
#1 + #2是已成功接收并确认的数据（等待应用进程读取）。 -
#3是未收到数据但可以接收的数据。 -
#4未收到数据并不可以接收的数据。
其中三个接收部分，使用两个指针进行划分:
-
RCV.WND：表示接收窗口的大小，它会通告给发送方。 -
RCV.NXT：是一个指针，它指向期望从发送方发送来的下一个数据字节的序列号，也就是 #3 的第一个字节。 - 指向 #4 的第一个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND 大小的偏移量，就可以指向 #4 的第一个字节了。
接收窗口和发送窗口的大小并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。
3. 流量控制
发送方不能无脑的发数据给接收方，要考虑接收方处理能力。如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。
为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。
假设以下场景：
- 客户端是接收方，服务端是发送方
- 假设接收窗口和发送窗口相同，都为 200
- 假设两个设备在整个传输过程中都保持相同的窗口大小，不受外界影响
根据上图的流量控制，说明下每个过程：
- 客户端向服务端发送请求数据报文。这里要说明下，本次例子是把服务端作为发送方，所以没有画出服务端的接收窗口。
- 服务端收到请求报文后，发送确认报文和 80 字节的数据，于是可用窗口 Usable 减少为 120 字节，同时 SND.NXT 指针也向右偏移 80 字节后，指向 321，这意味着下次发送数据的时候，序列号是 321。
- 客户端收到 80 字节数据后，于是接收窗口往右移动 80 字节，RCV.NXT 也就指向 321，这意味着客户端期望的下一个报文的序列号是 321，接着发送确认报文给服务端。
- 服务端再次发送了 120 字节数据，于是可用窗口耗尽为 0，服务端无法在继续发送数据。
- 客户端收到 120 字节的数据后，于是接收窗口往右移动 120 字节，RCV.NXT 也就指向 441，接着发送确认报文给服务端。
- 服务端收到对 80 字节数据的确认报文后，SND.UNA 指针往右偏移后指向 321，于是可用窗口 Usable 增大到 80。
- 服务端收到对 120 字节数据的确认报文后，SND.UNA 指针往右偏移后指向 441，于是可用窗口 Usable 增大到 200。
- 服务端可以继续发送了，于是发送了 160 字节的数据后，SND.NXT 指向 601，于是可用窗口 Usable 减少到 40。
- 客户端收到 160 字节后，接收窗口往右移动了 160 字节，RCV.NXT 也就是指向了 601，接着发送确认报文给服务端。
- 服务端收到对 160 字节数据的确认报文后，发送窗口往右移动了 160 字节，于是 SND.UNA 指针偏移了 160 后指向 601，可用窗口 Usable 也就增大至了 200。
3.1 操作系统缓冲区与滑动窗口的关系
上面的流量控制例子，我们假定了发送窗口和接收窗口是不变的，但是实际上，发送窗口和接收窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。当应用进程没办法及时读取缓冲区的内容时，会对缓冲区造成影响。
当应用程序没有及时读取缓存时，发送窗口和接收窗口的变化。假设以下场景：
- 客户端作为发送方，服务端作为接收方，发送窗口和接收窗口初始大小为 360。
- 服务端非常的繁忙，当收到客户端的数据时，应用层不能及时读取数据。
根据上图的流量控制，说明下每个过程：
- 客户端发送 140 字节数据后，可用窗口变为 220 （360 - 140）。
- 服务端收到 140 字节数据，但是服务端非常繁忙，应用进程只读取了 40 个字节，还有 100 字节占用着缓冲区，于是接收窗口收缩到了 260 （360 - 100），最后发送确认信息时，将窗口大小通过给客户端。
- 客户端收到确认和窗口通告报文后，发送窗口减少为 260。
- 客户端发送 180 字节数据，此时可用窗口减少到 80。
- 服务端收到 180 字节数据，但是应用程序没有读取任何数据，这 180 字节直接就留在了缓冲区，于是接收窗口收缩到了 80 （260 - 180），并在发送确认信息时，通过窗口大小给客户端。
- 客户端收到确认和窗口通告报文后，发送窗口减少为 80。
- 客户端发送 80 字节数据后，可用窗口耗尽。
- 服务端收到 80 字节数据，但是应用程序依然没有读取任何数据，这 80 字节留在了缓冲区，于是接收窗口收缩到了 0，并在发送确认信息时，通过窗口大小给客户端。
- 客户端收到确认和窗口通告报文后，发送窗口减少为 0。
当服务端系统资源非常紧张
当服务端系统资源非常紧张的时候，操作系统可能会直接减少了接收缓冲区大小，这时应用程序又无法及时读取缓存数据，那么这时候就会出现数据包丢失的现象。
- 客户端发送 140 字节的数据，于是可用窗口减少到了 220。
- 服务端因为现在非常的繁忙，操作系统于是就把接收缓存减少了 100 字节，当收到 对 140 数据确认报文后，又因为应用程序没有读取任何数据，所以 140 字节留在了缓冲区中，于是接收窗口大小从 360 收缩成了 100，最后发送确认信息时，通告窗口大小给对方。
- 此时客户端因为还没有收到服务端的通告窗口报文，所以不知道此时接收窗口收缩成了 100，客户端只会看自己的可用窗口还有 220，所以客户端就发送了 180 字节数据，于是可用窗口减少到 40。
- 服务端收到了 180 字节数据时，发现数据大小超过了接收窗口的大小，于是就把数据包丢失了。
- 客户端收到第 2 步时，服务端发送的确认报文和通告窗口报文，尝试减少发送窗口到 100，把窗口的右端向左收缩了 80，此时可用窗口的大小就会出现诡异的负值。
所以，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间在减少缓存，这样就可以避免了丢包情况。
3.2 窗口关闭
TCP 通过让接收方指明希望从发送方接收的数据大小（窗口大小）来进行流量控制。如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。
窗口关闭潜在的危险
接收方向发送方通告窗口大小时，是通过 ACK 报文来通告的。
当发生窗口关闭时，接收方处理完数据后，会向发送方通告一个窗口非 0 的 ACK 报文，如果这个通告窗口的 ACK 报文在网络中丢失了，接收方也一直等待发送方的数据，这种相互等待的过程，就会造成死锁现象。
为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。如果持续计时器超时，就会发送窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。
- 如果接收窗口仍然为 0，那么收到这个报文的一方就会重新启动持续计时器。
- 如果接收窗口不是 0，那么死锁的局面就可以被打破了。
3.3 糊涂窗口综合症
如果接收方太忙了，来不及取走接收窗口里的数据，那么就会导致发送方的发送窗口越来越小。到最后，如果接收方腾出几个字节并告诉发送方现在有几个字节的窗口，而发送方会义无反顾地发送这几个字节，这就是糊涂窗口综合症。
