TCP可靠传输保障
TCP 通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。
重传机制
在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。但在错综复杂的网络，并不一定能顺利、正常的传输数据，万一数据在传输过程中丢失(也即出现TCP数据包丢失)，此时可用重传机制解决：
- 超时重传
- 快速重传
- SACK
- D-SACK
超时重传
重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传。
TCP 会在以下两种情况发生超时重传：
- 数据包丢失
- 确认应答丢失
超时时间的设置
RTT：数据从网络一端传送到另一端所需的时间，也就是包的往返时间。超时重传时间以 RTO （Retransmission Timeout 超时重传时间）表示。
两种超时时间不同的情况：
- 当超时时间 RTO 较大时，网络的空隙时间增大，重发就慢，丢了很长时间才重发，没有效率，性能差；
- 当超时时间 RTO 较小时，会导致可能并没有丢就重发从而造成不必要的重传，虽然重发的快，但会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。但报文往返 RTT 的值是经常变化的，因为网络也是时常变化的。也就因为报文往返 RTT 的值 是经常波动变化的，所以超时重传时间 RTO 的值应该是一个动态变化的值。
linux下RTO的计算
估计往返时间，通常需要采样以下两个：
- 需要 TCP 通过采样 RTT 的时间，然后进行加权平均，算出一个平滑 RTT 的值，而且这个值还是要不断变化的，因为网络状况不断地变化。
- 除了采样 RTT，还要采样 RTT 的波动范围，这样就避免如果 RTT 有一个大的波动的话，很难被发现的情况。
如果超时重发的数据，再次超时又需要重传的时候，TCP 的策略是超时间隔加倍。也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
快速重传
超时触发重传存在的问题是，超时周期可能相对较长。TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传。
在上图，发送方发出了 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方法
为了解决不知道该重传哪些 TCP 报文，于是就有 SACK Selective Acknowledgment 选择性确认） 方法。
这种方式需要在 TCP 头部选项字段里加一个 SACK 的东西，它可以将缓存的数据区间发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
如下图，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。
如果要支持 SACK，必须双方都要支持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux 2.4 后默认打开）。
Duplicate SACK
Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉发送方有哪些数据被重复接收了。下面举例两个例子，来说明 D-SACK 的作用。
例子1： 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 包丢了，而是因为网络延迟了。
可见，D-SACK 有这么几个好处：
- 可以让发送方知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
- 可以知道是不是发送方的数据包被网络延迟了;
- 可以知道网络中是不是把发送方的数据包给复制了;
在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能（Linux 2.4 后默认打开）。
滑动窗口
TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。但这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。
为解决这个问题，TCP 引入了窗口这个概念。即使在往返时间较长的情况下，它也不会降低网络通信的效率。有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
假设窗口大小为 3 个 TCP 段，那么发送方就可以连续发送 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过下一个确认应答进行确认。如下图：
图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通话下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据接收方都收到了。这个模式就叫累计确认或者累计应答。
窗口大小的决定方
TCP 头里有一个字段叫 Window，也就是窗口大小。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
所以，通常窗口的大小是由接收方的决定的。发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。