编码不易，转载请注意出处！
本文按照下面图片中的问题依次深入了解tcp相关知识
本次文章不涉及 TCP 流量控制、拥塞控制、可靠性传输等方面知识，这些留在下篇!
最近在温习TCP的相关知识，不得不说，真是一个伟大的协议，为了对抗网络的不确定性用了很多机制去保证，尽最大努力去保障数据安全传输，真是受益匪浅。
正文
本文将描述TCP作为一个可靠的数据传输协议是如何保证其可靠性的。
为了实现可靠性传输，需要考虑很多事情，例如数据的破坏、丢包、重复以及分片顺序混乱等问题。如不能解决这些问题，也就无从谈起可靠传输。
那么，TCP 是通过序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输的。
今天，将重点介绍 TCP 的重传机制、滑动窗口、流量控制、拥塞控制。
重传机制
TCP 实现可靠传输的方式之一，是通过序列号与确认应答。
在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。
在错综复杂的网络，并不一定能如上图那么顺利能正常的数据传输，万一数据在传输过程中丢失了呢？
所以 TCP 针对数据包丢失的情况，会用重传机制解决。
接下来说说常见的重传机制：
- 超时重传
- 快速重传
- SACK
- D-SACK
超时重传
重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传。
TCP 会在以下两种情况发生超时重传：
- 数据包丢失
- 确认应答丢失
超时时间该设置为多少呢？
超时重传时间是以 RTO （Retransmission Timeout 超时重传时间）表示。
我们先来了解一下什么是 RTT（Round-Trip Time 往返时延）
RTT 就是数据从网络一端传送到另一端所需的时间，也就是包的往返时间。
假设在重传的情况下，超时时间 RTO 「较长或较短」时，会发生什么事情呢？
上图中有两种超时时间不同的情况：
- 当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
- 当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
精确的测量超时时间 RTO 的值是非常重要的，这可让我们的重传机制更高效。根据上述的两种情况，我们可以得知，超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。
怎么计算RTO呢？首先肯定是采样，然后一波加权平均得到 RTO。但实际情况是网络是动态变化的，包的RTT时间也是实时变化的，这可怎么办？
超时触发重传存在的问题是，超时周期可能相对较长。那是不是可以有更快的方式呢？
于是就可以用「快速重传」机制来解决超时重发的时间等待。
快速重传
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 报文时，会在定时器过期之前，重传丢失的报文段。
快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传之前的一个，还是重传所有的问题。
为了解决不知道该重传哪些 TCP 报文，于是就有 SACK 方法。
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 的作用。
ACK 丢失
- 「接收方」发给「发送方」的两个 ACK 确认应答都丢失了，所以发送方超时后，重传第一个数据包（3000 ~ 3499）
- 于是「接收方」发现数据是重复收到的，于是回了一个 SACK = 3000
3500，告诉「发送方」 30003500 的数据早已被接收了，因为 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 是每发送一个数据，都要进行一次确认应答, 当上一个数据包收到了应答了， 再发送下一个。
这个模式就有点像我和你面对面聊天，你一句我一句。但这种方式的缺点是效率比较低的。有没有一种方式我能同时发送多个包呢？所以就引用出来滑动窗口的概念了。
那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。如下图：
图中的 ACK 600 确认应答报文丢失，也没关系，因为可以通过下一个确认应答进行确认，只要发送方收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收方」都收到了。这个模式就叫累计确认或者累计应答。
窗口大小由哪一方决定？
TCP 头里有一个字段叫Window，也就是窗口大小。
这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
所以，通常窗口的大小是由接收方的窗口大小来决定的。
发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。
发送方的滑动窗口
我们先来看看发送方的窗口，下图就是发送方缓存的数据，根据处理的情况分成四个部分，其中深蓝色方框是发送窗口，紫色方框是可用窗口：
流量控制
发送方不能无脑的发数据给接收方，要考虑接收方处理能力。
如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。
为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。其实流量控制核心就是滑动窗口控制的。
TCP 是如何解决窗口关闭时，潜在的死锁现象呢？
如果收到ACK窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。
那么，当发生窗口关闭时，接收方处理完数据后，会向发送方通告一个窗口非 0 的 ACK 报文，如果这个通告窗口的 ACK 报文在网络中丢失了，那麻烦就大了。
这会导致发送方一直等待接收方的非 0 窗口通知，接收方也一直等待发送方的数据，如不采取措施，这种相互等待的过程，会造成了死锁的现象。
为了解决这个问题，TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。
如果持续计时器超时，就会发送零窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。
窗口探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。
Nagle算法
你想象一下，如果每次接收方都说我还能收 1 个字节，发送方该不该发？
TCP + IP 头部就 40 个字节了，这传输不划算啊，如果傻傻的一直发这就叫 Silly Window。
那咋办，一想就是发送端等着，等养肥了再发，要么接收端自己自觉点，数据小于一个阈值就告诉发送端窗口此时是 0 算了，也等养肥了再告诉发送端。
发送端等着的方案就是Nagle算法。
简单的说就是当前能发送的数据和窗口大于等于 MSS 就立即发送，否则再判断一下之前发送的包 ACK 回来没，回来再发，不然就攒数据。
接收端自觉点的方案是 David D Clark’s 方案，如果窗口数据小于某个阈值就告诉发送方窗口 0 别发，等缓过来数据大于等于 MSS 或者接受 buffer 腾出一半空间了再设置正常的 window 值给发送方。
对了提到纳格算法不得不再提一下延迟确认，纳格算法在等待接收方的确认，而开启延迟确认则会延迟发送确认，会等之后的包收到了再一起确认或者等待一段时候真的没了再回复确认。
这就相互等待了，然后延迟就很大了，两个不可同时开启。
拥塞控制
为什么要有拥塞控制呀，不是有流量控制了吗？
简单来说，流量控制是基于端到端的，而拥塞控制就基于整个网络的。
前面的流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。
一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。
在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大….
所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。
于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。
为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。
什么是拥塞窗口？和发送窗口有什么关系呢？
拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。
我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。
拥塞窗口 cwnd 变化的规则：
- 只要网络中没有出现拥塞，cwnd 就会增大；
- 但网络中出现了拥塞，cwnd 就减少；
那么怎么知道当前网络是否出现了拥塞呢？
其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。
拥塞控制有哪些控制算法？
拥塞控制主要是四个算法：
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
慢启动
TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量，如果一上来就发大量的数据，这不是给网络添堵吗？
慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。
当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。发包的个数是指数性的增长。（第一次只有发1个，第二次可以发两个，第三次可以发4个，第四次可以发8个）
那慢启动涨到什么时候是个头呢？
有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。
- 当 cwnd < ssthresh 时，使用慢启动算法。
- 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。
拥塞避免算法
那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。
所以拥塞避免算法不是让拥塞窗口不加了，而是让它以线性增长了，还是增长阶段，但是增长速度缓慢了一些。
就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。
当触发了重传机制，也就进入了「拥塞发生算法」。
拥塞发生
拥塞发生后，也就是会发生数据包重传，重传机制主要有两种：
- 超时重传
- 快速重传
这两种使用的拥塞发送算法是不同的，接下来分别来说说。
发生超时重传的拥塞发生算法
当发生了「超时重传」，则就会使用拥塞发生算法。
这个时候，ssthresh 和 cwnd 的值会发生变化：
- ssthresh 设为 cwnd/2
- cwnd 重置为 1
接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是一旦「超时重传」，马上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。
发生快速重传的拥塞发生算法
还有更好的方式，前面我们讲过「快速重传算法」。当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。
TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：
- cwnd = cwnd/2 ，也就是设置为原来的一半;
- ssthresh = cwnd;
- 进入快速恢复算法
快速恢复
快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。
正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了：
- cwnd = cwnd/2 ，也就是设置为原来的一半;
- ssthresh = cwnd;
然后，进入快速恢复算法如下：
- 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
- 重传丢失的数据包；
- 如果再收到重复的 ACK，那么 cwnd 增加 1；
- 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；
- 快速重传和快速恢复
也就是没有像「超时重传」一夜回到解放前，而是还在比较高的值，后续呈线性增长。