TCP的可靠性之道：确认重传和流量控制

TCP 全称为 Transmission Control Protocol（传输控制协议），是一种面向连接的、可靠的、基于字节流的传输层通信协议，其中可靠性是相对于其他传输协议的优势点。TCP 为了确保数据传输的可靠性主要做了以下几点：

• 发送确认机制
• 丢包重传机制
• 滑动窗口
• 拥塞控制

TCP 的传输基于字节流，记录起始序列号、是否发送、是否接收。本文从实战出发，使用 Wireshark 抓包工具来分析具体的请求。

确认和重传

• TCP 报文头中有两个字段：
  • Sequence number 序列号：表示要发送数据的起始号
  • Acknowledgment number 确认号：表示消息已经接收，返回下次要发送的起始号

发送确认

TCP 每次发送数据，都有一个确认应答 ACK，表示已经收到了数据包。确认号表示下一个传送的起始号。

发送一个 http 请求，使用 Wireshake 抓取数据包，打开 Statistics -> Flow Graph，在弹出的页面上将 Flow type 修改成 TCP Flows，就能看到 TCP 的数据包请求：

上图中标记了三个地方，中间的的标记的发送确认,就表示数据发送和确认应答，len 表示字节长度。发送 1 ~ 218 的字节，确认应答返回了确认号 219。第二个发送确认也是类似原理，所不同的是，这个发送确认时接收端的发送确认。

重传机制

发送端的数据包，一般都发送到接收端。但是在网络不好，或者信号比较差的情况，可能就无法正常发送到数据。

先介绍两个概念，RTT 和 RTO。

RTT Round-Trip Time 表示往返时间，表示网络一段到另一端所需要的时间，也就是数据包的往返时间，以 TCP 握手为例：

RTT 表示数据包从发送到收到确认应答的时间。

RTO Retransmission Timeout 表示超时重传时间。超过这个时间没有确认应答，就会重传报文段，这个时间根据 RTT 来设置的。

重传机制是 TCP 基本的错误恢复功能，常见的重传机制有两种：

• 超时重传
• 快速重传

1、超时重传

超时重传，字面意思是，超时规定的时间没有收到确认消息，就会再次发送一个消息请求。TCP 发送方发送报文时，会设置一个定时器，如果在时间范围内没有收到接收方发来的 ACK 确认报文，发送方就会重传已经发送的报文段。

TCP 有两种超时重传的情况：

• 报文在发送途中丢失
• 确认包在途中丢失

上面的 RTO 表示超时重传时间，RTO 的设定不能过大的或者过小：

• 如果过大，请求等待的时间过长，请求的效率低。
• 如果过小，正常返回的确认还未来得及返回，就重传。加大网络符合。

设置一个适当的 RTO 才会让重传机制更加高效。超时时间 RTT 应该略大于往返时间 RTT。

如果超时重传的报文段又超时了该怎么办呢？，答案就是重传的超时时间加倍，也就是再次超时重传的超时时间会增加到之前的两倍。

如果超时重传的报文段又丢包呢？此时发送方会以 RTO 时间的 2、4、8倍的倍数尝试多次重传。

超时重传如果消息多次没有收到确认报文，超时的周期也比较长，有没有更加高效的方法减少超时重传的时间呢？就引出下面的要讲的快速重传。

快速重传

快速重传不会等待超时时间到了再重传，发送方收到 3 次重复确认报文端，就不会等超时时间重试，而是直接重传报文。

连续发送的报文段，中间只要有一个丢失，后续返回的确认号都是相同，后面的报文段无论有没有返回，都会重传一遍，这种设置还是比较合理的。在一段时间内，如果网络状况不好，导致丢包情况，后续的报文段一般也会丢包。

但是重传丢包后面所有的包，也会造成网络传输的浪费。对于上面的例子，如果只想传输 seq2，其他有返回的确认包就不用重传。

TCP 有一种重传机制： SACK Selective Acknowledgment 选择性重传。

这种方式需要 TCP 报文段选项加一个 SACK 字段，使用查看 Wireshake SYN 包中 SACK Permitted:

发送包有返回确认应答，就会发送给发送方告知对应的数据被接收了，发送方就能记录哪些数据被接收了，哪些数据没有被接收。后面只会重传没有被接收的数据包，这就是选择性重传。

滑动窗口

TCP 发送比较大的数据包，TCP 会一次性发送大的数据包给接收方？答案是不会的，需要考虑网络带宽，TCP 会将大的数据包拆分成多个大小适中的数据包，发送一个 http 请求，添加较大的参数，使用 Wireshake 抓取数据包：

数据包被拆分成五个小的数据包。

数据包被拆分成多个小的数据包之后，数据包发送都有返回一个确认序列号，每次发送一个新的包，都等待上一个包的 ACK 回来之后才能发送，这样一来一回的效率是很低的：

TCP 为了解决这个问题，引入窗口的概念，在窗口范围内的数据包，无需等待上一次 ACK 确认，可以直接发送数据包：

滑动窗口是 TCP 协议中的一种流量控制机制，用来控制发送方和接收方数据传输的速率，避免数据过多造成数据无法及时处理。

窗口的大小也就是 TCP 报文段的 windos 字段，表示的就是接收方目前能接收的缓冲区的剩余大小，发送端根据这个字段处理发送的数据。

发送端的窗口

发送窗口根据三个标准来划分：是否发送、是否收到 ACK、是否在接收方处理范围内，分成了四个部分:

四个部分组成：

• 第一部分是已经发送并收到 ACK 确认的数据，这部分数据已经发送成功了，无需在缓存中保留了。
• 第二部分数据是已经发生但是未收到 ACK 确认的数据。
• 第三部分数据是未发送，但是在接收方处理范围之内的数据。第二、第三部分共同组成发送的窗口。
• 第四部分是需要发送，但是未在接收方范围之内的数据。这部分数据在没有接收 ACK 确认之前，是不会发送数据的。

如果发送方一直没有收到 ACK,数据不断的发送，很快可用窗口也被耗尽，这时发送方也不会继续发送数据了，这时发送端可用窗口为零的情况我们成为“零窗口”。

随着 ACK 的确认，窗口也会依次向右滑动，比如发送端的窗口中，比如 40 ~ 43 字节都收到了 ACK 确认，那么整个可用的窗口就会顺次往右移动。此时 53 ~ 57的数据也都能发送了。

接收端的窗口

接收端的滑动窗口相对发送的窗口要简单的多，主要分为三个部分：

• 已经接收并确认的数据
• 可以接收但是未接收的数据
• 在接收范围之外（不够缓存的数据），也就是不可以接收的数据。

但数据接收后，窗口也向右边滑动，给发生端的数据提供数据缓存。如果读取缓存的数据速度有变化时，接收端可能也会改变接收窗口的大小，以此来控制发送端的发送速度。这就是滑动窗口进行流量控制的一种机制。

拥塞控制

网络中由于有大量的包传输，在固定带宽下处理不过来数据包的传输，可能会导致数据包阻塞，网络传输的速度下降，甚至会下降到 0 的情况。这就有点类似排队买东西，如果正常排队，速度虽然不快但处理速度比较稳定。但是如果一下涌来很多人口，就会处理不过来，导致堵死情况。

而 TCP 被设置成一个无私的协议，当遇到网络拥塞时，TCP 会减少自己发送数据包，这样网络拥塞会得到很大的缓解。

为了实现拥塞控制，首先在发送端定义一个拥塞窗口 CWND (congestion window),限制发送端发送数据最多没有收到 ACK 确认包的大小，超过拥塞窗口范围后，就不会继续发送数据了。

拥塞窗口会随着网络情况的变化动态的调用自身的大小，大体的变化规则是：如果没有出现拥塞，就扩大窗口大小，否则就缩小窗口的大小。

拥塞控制算法主要包含四个部分：

• 慢启动
• 拥塞避免
• 拥塞发生
• 快速恢复

慢启动

当一个新的TCP连接开始时，无法确定是否用拥塞发生，一开始不会发送大量的包，而是从最小的发送窗口开始，后续会采用倍增的方式增加窗口的大小，窗口大小从 1 开始，后续慢慢增大到 2、4、8 等。

指数增加速度会越来越快，窗口扩大的一定的程度，就会减慢增加的速度，改成线性增加，这时候就进入拥塞避免阶段。

拥塞避免

慢启动和拥塞避免的临界点叫做慢启动门限 ssthresh （slow start threshold。

• cwnd < ssthresh 时，使用慢启动算法。
• cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

ssthresh 大小一般是 65535 字节。拥塞避免的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。就变成线性增长了。

拥塞发生

拥塞避免将原来的指数增长改成了线性增长，虽然增长速度减慢，但 CWND 窗口还是在增长阶段。随着窗口进一步缓慢增加，网络还是会遇到阻塞的状态，会出现丢包的情况。就需要对丢包进行重传。

重传机制有两种：

• 超时重传
• 快速重传

当发生超时重传时，sshresh 和 cwnd 的值会发生如下变化：

• sshresh 变成 cwnd 的一半
• cwnd 重置为 1

cwnd 重置为1，表示直接进入慢启动状态。

上面的超时重传速度变化太快，而快速重传是一个相对温和的方案。如果我们连续 3 次收到同样序号的 ACK，包还能回传，说明这个时候可能只是碰到了部分丢包，网络阻塞还没有很严重，无需重置 cwnd。

此时 ssthresh 和 cwnd 变化如下：

• cwnd = cwnd/2 ，也就是设置为原来的一半;
• ssthresh = cwnd

并进入到快速恢复阶段。

快速恢复

快速恢复主要是将 cwnd 恢复到正常大小，上面说的 cwnd 设置成原来的一半，ssthresh 设置成 cwnd 的大小。

快速恢复算法如下：

• 重传丢失的数据包。
• 如果接收到重复 ACK 确认，cwnd 增加 1。
• 如果接收到新数据的 ACK 确认，就将 ssthresh 恢复到慢启动时期的值，因为返回新数据的 ACK 确认，表示网络阻塞已经结束，可以恢复到之前的状态，cwnd 也可以指数或者线性增加。

总结

TCP 提供基于字节流、可靠的数据传输，为了确保数据的可靠性，做了很多工作：

• 报文段序号和确认号
  • 每个报文都有序号和确认号，序号表示报文段第一个字节号，确认号表示下一个接收字节的序号。
• 发送确认和重传机制
  • 每个报文段发送后，都会确认应答 ACK，表示已经报文段已经成功发送。
  • 当网络异常数据包无法达到时，就会触发重传机制。重传主要有两种方式：超时重传和快速重传。
  • 超时重传：设置一个定时器，超过时间未收到确认应答，就会重新传数数据包。这个重传方式周期比较长。
  • 快速重传：快速重传不会等待超时时间到了再重传，是以数据为基点，发送多次报文段，当接受到重复的确认应答号 ACK 时，直接重传所有的报文段。可以使用 SACK 记录哪些报文段已经成功接收了，只重传没有被成功接收的报文段。
• 滑动窗口
  • 报文段拆分，TCP 将要发送的数据拆分适当大小的数据包。
  • 引入窗口的概念，这个窗口大小是由接收方来决定，表示接收方可以接收的缓存大小。在窗口范围之内， TCP 可以连续发送多个数据包给接收方，当数据包发送并且有确认应答，整个窗口会往后移动，继续发送新的数据。
  • 随着数据传输的速度和网络情况，接受方可能会动态修改窗口的大小，以此来控制数据传输的速度。
  • 滑动窗口能流量进行控制，控制数据发送的速度和频率，避免出现拥塞情况。
• 拥塞控制，在网络传输中可能会出现大量的数据请求，而固定的网络宽带可能处理不过来这么多数据传输，容易形成阻塞的情况。TCP 遇到网络拥塞时，会自动减少自己发送包的数量，这样网络拥塞情况就会缓解。TCP 发送端定义拥塞窗口 CWND,表示没有接收到 ACK 确认数据的最大发送量。拥塞控制算法主要包含四个部分：
  • 慢启动：开始一个新的连接时，从较小的发送窗口开始，然后指数增长增加 CWND 窗口大小，知道达到慢启动门限。
  • 拥塞避免：窗口达到慢启动门限临界点时候，慢启动阶段结束，这个阶段，窗口大小线性增加，增长速度比较慢，避免发生网络拥塞。
  • 拥塞发生：窗口进一步缓慢增加，网络还是会遇到阻塞的状态，会出现丢包的情况。就需要对丢包进行重传。此时有两种重传机制：超时重传和快速重传。超时重传，是窗口大小重置为 1，数据传输又恢复成慢启动时的速度。这种传输速度急剧下降，不利于系统稳定，由于窗口大小限制，网络传输次数更多，拥塞的情况也会更大。而快速重传是相对温和的方案，此时认为网络只是暂时有阻塞情况，将窗口大小 CWND 改成原来的一半，并进入快速恢复阶段。
  • 快速恢复：重传丢失的数据包，如果接收到重复 ACK 确认，cwnd 增加 1。如果接收到新数据的 ACK 确认，就将 ssthresh 恢复到慢启动时期的值，因为返回新数据的 ACK 确认，表示网络阻塞已经结束，cwnd 也可以指数或者线性增加。

参考

• TCP 重传、滑动窗口、流量控制、拥塞控制

• 滑动窗口：TCP是如何进行流量控制和拥塞控制的