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

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

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

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

确认和重传

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

发送确认

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

TCP的可靠性之道:确认重传和流量控制_第1张图片

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

TCP的可靠性之道:确认重传和流量控制_第2张图片

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

重传机制

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

先介绍两个概念,RTTRTO

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

TCP的可靠性之道:确认重传和流量控制_第3张图片

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

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

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

  • 超时重传
  • 快速重传

1、超时重传

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

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

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

TCP的可靠性之道:确认重传和流量控制_第4张图片

TCP的可靠性之道:确认重传和流量控制_第5张图片

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

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

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

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

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

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

快速重传

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

TCP的可靠性之道:确认重传和流量控制_第6张图片

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

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

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

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

TCP的可靠性之道:确认重传和流量控制_第7张图片

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

滑动窗口

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

TCP的可靠性之道:确认重传和流量控制_第8张图片

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

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

TCP的可靠性之道:确认重传和流量控制_第9张图片

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

TCP的可靠性之道:确认重传和流量控制_第10张图片

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

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

TCP的可靠性之道:确认重传和流量控制_第11张图片

发送端的窗口

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

TCP的可靠性之道:确认重传和流量控制_第12张图片

四个部分组成:

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

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

TCP的可靠性之道:确认重传和流量控制_第13张图片

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

TCP的可靠性之道:确认重传和流量控制_第14张图片

接收端的窗口

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

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

TCP的可靠性之道:确认重传和流量控制_第15张图片

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

拥塞控制

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

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

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

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

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

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

慢启动

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

TCP的可靠性之道:确认重传和流量控制_第16张图片

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

拥塞避免

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

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

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

TCP的可靠性之道:确认重传和流量控制_第17张图片

拥塞发生

拥塞避免将原来的指数增长改成了线性增长,虽然增长速度减慢,但 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是如何进行流量控制和拥塞控制的

你可能感兴趣的:(tcp/ip,网络,网络协议)