彻底搞懂TCP协议：从 TCP 三次握手四次挥手说起（三）

李玮

疑症（7）TCP 的延迟确认机制

按照 TCP 协议，确认机制是累积的，也就是确认号 X 的确认指示的是所有 X 之前但不包括 X 的数据已经收到了。确认号(ACK)本身就是不含数据的分段，因此大量的确认号消耗了大量的带宽，虽然大多数情况下，ACK 还是可以和数据一起捎带传输的，但是如果没有捎带传输，那么就只能单独回来一个 ACK，如果这样的分段太多，网络的利用率就会下降。为缓解这个问题，RFC 建议了一种延迟的 ACK，也就是说，ACK 在收到数据后并不马上回复，而是延迟一段可以接受的时间，延迟一段时间的目的是看能不能和接收方要发给发送方的数据一起回去，因为 TCP 协议头中总是包含确认号的，如果能的话，就将数据一起捎带回去，这样网络利用率就提高了。

延迟 ACK 就算没有数据捎带，那么如果收到了按序的两个包，那么只要对第二包做确认即可，这样也能省去一个 ACK 消耗。由于 TCP 协议不对 ACK 进行 ACK 的，RFC 建议最多等待 2 个包的积累确认，这样能够及时通知对端 Peer，我这边的接收情况。Linux 实现中，有延迟 ACK 和快速 ACK，并根据当前的包的收发情况来在这两种 ACK 中切换。一般情况下，ACK 并不会对网络性能有太大的影响，延迟 ACK 能减少发送的分段从而节省了带宽，而快速 ACK 能及时通知发送方丢包，避免滑动窗口停等，提升吞吐率。关于 ACK 分段，有个细节需要说明一下，ACK 的确认号，是确认按序收到的最后一个字节序，对于乱序到来的 TCP 分段，接收端会回复相同的 ACK 分段，只确认按序到达的最后一个 TCP 分段。TCP 连接的延迟确认时间一般初始化为最小值 40ms，随后根据连接的重传超时时间（RTO）、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。

疑症（8）TCP 的重传机制以及重传的超时计算【1】TCP 的重传超时计算

TCP 交互过程中，如果发送的包一直没收到 ACK 确认，是要一直等下去吗？显然不能一直等(如果发送的包在路由过程中丢失了，对端都没收到又如何给你发送确认呢？)，这样协议将不可用，既然不能一直等下去，那么该等多久呢？等太长时间的话，数据包都丢了很久了才重发，没有效率，性能差；等太短时间的话，可能 ACK 还在路上快到了，这时候却重传了，造成浪费，同时过多的重传会造成网络拥塞，进一步加剧数据的丢失。也是，我们不能去猜测一个重传超时时间，应该是通过一个算法去计算，并且这个超时时间应该是随着网络的状况在变化的。为了使我们的重传机制更高效，如果我们能够比较准确知道在当前网络状况下，一个数据包从发出去到回来的时间 RTT——Round Trip Time，那么根据这个 RTT 我们就可以方便设置 TimeOut——RTO（Retransmission TimeOut）了。

为了计算这个 RTO，RFC793 中定义了一个经典算法，算法如下：

[1] 首先采样计算RTT值[2] 然后计算平滑的RTT，称为Smoothed Round Trip Time (SRTT)，SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)[3] RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]

其中：UBOUND 是 RTO 值的上限；例如：可以定义为 1 分钟，LBOUND 是 RTO 值的下限，例如，可以定义为 1 秒；ALPHA is a smoothing factor (e.g., .8 to .9), and BETA is a delay variance factor(e.g., 1.3 to 2.0).

然而这个算法有个缺点就是：在算 RTT 样本的时候，是用第一次发数据的时间和 ack 回来的时间做 RTT 样本值，还是用重传的时间和 ACK 回来的时间做 RTT 样本值？不管是怎么选择，总会造成会要么把 RTT 算过长了，要么把 RTT 算过短了。如下图：(a)就计算过长了，而(b)就是计算过短了。

针对上面经典算法的缺陷，于是提出 Karn / Partridge Algorithm 对经典算法进行了改进(算法大特点是——忽略重传，不把重传的 RTT 做采样)，但是这个算法有问题：如果在某一时间，网络闪动，突然变慢了，产生了比较大的延时，这个延时导致要重转所有的包（因为之前的 RTO 很小），于是，因为重转的不算，所以，RTO 就不会被更新，这是一个灾难。于是，为解决上面两个算法的问题，又有人推出来了一个新的算法，这个算法叫 Jacobson / Karels Algorithm（参看 FC6289），这个算法的核心是：除了考虑每两次测量值的偏差之外，其变化率也应该考虑在内，如果变化率过大，则通过以变化率为自变量的函数为主计算 RTT(如果陡然增大，则取值为比较大的正数，如果陡然减小，则取值为比较小的负数，然后和平均值加权求和)，反之如果变化率很小，则取测量平均值。

公式如下：（其中的 DevRTT 是 Deviation RTT 的意思）

SRTT = SRTT + α (RTT – SRTT)  —— 计算平滑RTTDevRTT = (1-β)*DevRTT + β*(|RTT-SRTT|) ——计算平滑RTT和真实的差距（加权移动平均）RTO= µ * SRTT + ∂ *DevRTT —— 神一样的公式（其中：在Linux下，α = 0.125，β = 0.25， μ = 1，∂ = 4 ——这就是算法中的“调得一手好参数”，nobody knows why, it just works…） 最后的这个算法在被用在今天的TCP协议中并工作非常好

最后的这个算法在被用在今天的 TCP 协议中并工作非常好。

知道超时怎么计算后，很自然就想到定时器的设计问题。一个简单直观的方案就是为 TCP 中的每一个数据包维护一个定时器，在这个定时器到期前没收到确认，则进行重传。这种设计理论上是很合理的，但是实现上，这种方案将会有非常多的定时器，会带来巨大内存开销和调度开销。既然不能每个包一个定时器，那么多少个包一个定时器才好呢，这个似乎比较难确定。可以换个思路，不要以包量来确定定时器，以连接来确定定时器会不会比较合理呢？目前，采取每一个 TCP 连接单一超时定时器的设计则成了一个默认的选择，并且 RFC2988 给出了每连接单一定时器的设计建议算法规则：

[1].每一次一个包含数据的包被发送（包括重发），如果还没开启重传定时器，则开启它，使得它在 RTO 秒之后超时（按照当前的 RTO 值）。 [2]. 当接收到一个 ACK 确认一个新的数据； 如果所有的发出数据都被确认了，关闭重传定时器； [3].当接收到一个 ACK 确认一个新的数据，还有数据在传输，也就是还有没被确认的数据，重新启动重传定时器，使得它在 RTO 秒之后超时（按照当前的 RTO 值）。

当重传定时器超时后，依次做下列 3 件事情： [4.1]. 重传最早的尚未被 TCP 接收方 ACK 的数据包； [4.2]. 重新设置 RTO 为 RTO *2（“还原定时器”），但是新 RTO 不应该超过 RTO 的上限(RTO 有个上限值，这个上限值最少为 60s)； [4.3]. 重启重传定时器。

上面的建议算法体现了一个原则：没被确认的包必须可以超时，并且超时的时间不能太长，同时也不要过早重传。规则[1][3][4.3]共同说明了只要还有数据包没被确认，那么定时器一定会是开启着的(这样满足没被确认的包必须可以超时的原则)。规则[4.2]说明定时器的超时值是有上限的(满足超时的时间不能太长)。

规则[3]说明，在一个 ACK 到来后重置定时器可以保护后发的数据不被过早重传；因为一个 ACK 到来了，说明后续的 ACK 很可能会依次到来，也就是说丢失的可能性并不大。规则[4.2]也是在一定程度上避免过早重传，因为，在出现定时器超时后，有可能是网络出现拥塞了，这个时候应该延长定时器，避免出现大量的重传进一步加剧网络的拥塞。

【2】TCP 的重传机制

通过上面我们可以知道，TCP 的重传是由超时触发的，这会引发一个重传选择问题，假设 TCP 发送端连续发了 1、2、3、4、5、6、7、8、9、10 共 10 包，其中 4、6、8 这 3 个包全丢失了，由于 TCP 的 ACK 是确认最后连续收到序号，这样发送端只能收到 3 号包的 ACK，这样在 TIME_OUT 的时候，发送端就面临下面两个重传选择： [1].仅重传 4 号包 [2].重传 3 号后面所有的包，也就是重传 4~10 号包

对于，上面两个选择的优缺点都比较明显。方案[1]，优点：按需重传，能够最大程度节省带宽。缺点：重传会比较慢，因为重传 4 号包后，需要等下一个超时才会重传 6 号包。方案[2]，优点：重传较快，数据能够较快交付给接收端。缺点：重传了很多不必要重传的包，浪费带宽，在出现丢包的时候，一般是网络拥塞，大量的重传又可能进一步加剧拥塞。

上面的问题是由于单纯以时间驱动来进行重传的，都必须等待一个超时时间，不能快速对当前网络状况做出响应，如果加入以数据驱动呢？TCP 引入了一种叫 Fast Retransmit(快速重传)的算法，就是在连续收到 3 次相同确认号的 ACK，那么就进行重传。这个算法基于这么一个假设，连续收到 3 个相同的 ACK，那么说明当前的网络状况变好了，可以重传丢失的包了。

快速重传解决了 timeout 的问题，但是没解决重传一个还是重传多个的问题。出现难以决定是否重传多个包问题的根源在于，发送端不知道那些非连续序号的包已经到达接收端了，但是接收端是知道的，如果接收端告诉一下发送端不就可以解决这个问题吗？于是，RFC2018 提出了 Selective Acknowledgment(SACK，选择确认)机制，SACK 是 TCP 的扩展选项，包括(1)SACK 允许选项（Kind=4,Length=2，选项只允许在有 SYN 标志的 TCP 包中），(2)SACK 信息选项 Kind=5,Length）。一个 SACK 的例子如下图，红框说明：接收端收到了 0-5500，8000-8500，7000-7500，6000-6500 的数据了，这样发送端就可以选择重传丢失的 5500-6000，6500-7000，7500-8000 的包。

SACK 依靠接收端的接收情况反馈，解决了重传风暴问题，这样够了吗？接收端能不能反馈更多的信息呢？显然是可以的，于是，RFC2883 对对 SACK 进行了扩展，提出了 D-SACK，也就是利用第一块 SACK 数据中描述重复接收的不连续数据块的序列号参数，其他 SACK 数据则描述其他正常接收到的不连续数据。这样发送方利用第一块 SACK，可以发现数据段被网络复制、错误重传、ACK 丢失引起的重传、重传超时等异常的网络状况，使得发送端能更好调整自己的重传策略。D-SACK，有几个优点： 1）发送端可以判断出，是发包丢失了，还是接收端的 ACK 丢失了。(发送方，重传了一个包，发现并没有 D-SACK 那个包，那么就是发送的数据包丢了；否则就是接收端的 ACK 丢了，或者是发送的包延迟到达了)； 2）发送端可以判断自己的 RTO 是不是有点小了，导致过早重传(如果收到比较多的 D-SACK 就该怀疑是 RTO 小了)； 3）发送端可以判断自己的数据包是不是被复制了。(如果明明没有重传该数据包，但是收到该数据包的 D-SACK)； 4）发送端可以判断目前网络上是不是出现了有些包被 delay 了，也就是出现先发的包却后到了。