tcp拥塞控制原理

18.3 拥塞控制

我们在向对端发送数据时,并不是一股脑子任意发送,因为TCP建立连接后,就是建立了一根管道,这跟管道上,实际上有很多的工作设备,比如路由器和交换机等等,他们都会对接收到的TCP包进行缓存,以便实现排序,然后发送,但是这些设备并不是只为一个TCP连接中转数据包,大量的网络包也许会耗尽存储空间,从而导致TCP连接的吞吐量急剧下降。为了避免这种情况的发送,TCP的设计必须是一种无私的协议,它必须去探测这种网络拥塞的问题,否则我们想想,一旦出现拥塞(判断是否丢包或者是否发生重传),如果TCP只能做重传,那么重传数据包会使得网络上的包更多,网络的负担更重,于是导致更大的延迟以及丢更多的包,于是会进入一个恶性循环,如果网络上的所有TCP连接都是如此行事的话,那么马上就会形成“网络风暴”,会拖垮整个网络,这也是一个灾难。那么TCP就应该能够检测出来这种状况,当拥塞出现时,要做自我牺牲,就像交通阻塞一样,每一辆车都应该把路给让出来,而不是再去抢路了。这说的就是拥塞控制。那是如何控制的呢?

首先,我们得看TCP是如何充分利用网络的,TCP实际上就是逐步探测这个通道的传输的最大能力,这个逐步探索就是我们要讲的慢启动算法,这个慢启动算法就是:新建立的连接不能一开始就大量发送数据包,而是应该根据网络状况,逐步地增加每次发送数据包的量。

具体的工作步骤就是:

慢启动算法:

  1. 发送方维护一个拥塞窗口,刚开始时,这个拥塞窗口(cwnd,congestion window)设置为1,这个1代表是一个MSS个字节。

  2. 如果每收到一个ACK,那么就指数增长这个cwnd(2,4,8,16,32,64)等,

  3. 实际上不会这么一直指数级增长下去,TCP会设置一个慢启动的阈值(ssthresh,slow start threshold,65535个字节) ,当cwnd >= ssthresh时,进入拥塞避免阶段。

拥塞避免阶段

  1. 每收到一个ACK时,cwnd = cwnd + 1/cwnd;

  2. 每当每过一个RTT时,cwnd = cwnd + 1;

这样放缓了拥塞窗口的增长速率,避免增长过快导致网络拥塞,慢慢的增加调整到网络的最佳值。在这个过程中如果出现了拥塞,则进入拥塞状态。

拥塞状态
那是如何判断出现拥塞状态呢?只要出现丢包就认为进入了拥塞状态。进入拥塞状态也分两种情况:
1) 等到RTO超时(重传超时),重传数据包。TCP认为这种情况太糟糕,反应也很强烈:

  • sshthresh = cwnd /2
  • cwnd 重置为 1
  • 进入慢启动过程

快速重传
2)连续收到3个duplicate ACK时,重传数据包,无须等待RTO。此情况即为下面的快速重传。

【问题】什么情况下会出现3个duplicate ACK?

TCP在收到一个乱序的报文段时,会立即发送一个重复的ACK,并且此ACK不可被延迟。

如果连续收到3个或3个以上重复的ACK,TCP会判定此报文段丢失,需要重新传递,而无需等待RTO。这就叫做快速重传。

TCP Tahoe的实现和RTO超时一样。
TCP Reno的实现是:

  • sshthresh = cwnd
  • cwnd = cwnd /2
  • 进入快速恢复算法——Fast Recovery

上面我们可以看到RTO超时后,sshthresh会变成cwnd的一半,这意味着,如果cwnd<=sshthresh时出现的丢包,那么TCP的sshthresh就会减了一半,然后等cwnd又很快地以指数级增涨爬到这个地方时,就会成慢慢的线性增涨。我们可以看到,TCP是怎么通过这种强烈地震荡快速而小心得找到网站流量的平衡点的。

快速恢复算法

TCP Reno

这个算法定义在RFC5681。快速重传和快速恢复算法一般同时使用。快速恢复算法是认为,你还有3个Duplicated Acks说明网络也不那么糟糕,所以没有必要像RTO超时那么强烈。 注意,正如前面所说,进入Fast Recovery之前,cwnd 和 sshthresh已被更新:

  • sshthresh = cwnd
  • cwnd = cwnd /2

然后,真正的Fast Recovery算法如下:

  • cwnd = sshthresh + 3 * MSS (3的意思是确认有3个数据包被收到了)
  • 重传Duplicated ACKs指定的数据包
  • 如果再收到 duplicated Acks,那么cwnd = cwnd +1
  • 如果收到了新的Ack,那么,cwnd = sshthresh ,代表恢复过程结束,然后就进入了拥塞避免的算法了。

如果我们仔细思考一下上面的这个算法,你就会知道,上面这个算法也有问题,那就是——它依赖于3个重复的Acks。注意,3个重复的Acks并不代表只丢了一个数据包,很有可能是丢了好多包。但这个算法只会重传一个,而剩下的那些包只能等到RTO超时,于是,进入了恶梦模式——超时一个窗口就减半一下,多个超时会超成TCP的传输速度呈级数下降,而且也不会触发Fast Recovery算法了。

TCP New Reno

于是,1995年,TCP New Reno(参见 RFC 6582 )算法提出来:

  • 当sender这边收到了3个Duplicated Acks,进入Fast Retransimit模式,开发重传重复Acks指示的那个包。如果只有这一个包丢了,那么,重传这个包后回来的Ack会把整个已经被sender传输出去的数据ack回来。如果没有的话,说明有多个包丢了。我们叫这个ACK为Partial ACK。
  • 一旦Sender这边发现了Partial ACK出现,那么,sender就可以推理出来有多个包被丢了,于是乎继续重传sliding window里未被ack的第一个包。直到再也收不到了Partial Ack,才真正结束Fast Recovery这个过程。

我们可以看到,这个“Fast Recovery的变更”是一个非常激进的玩法,他同时延长了Fast Retransmit和Fast Recovery的过程。

18.4 BBR算法

上一小节,我们接收了两种拥塞控制算法,一个是Reno、一个是New Reno,现如今,google研发了新的拥塞控制算法BBR,详情见:https://www.zhihu.com/question/53559433

对于BBR算法的测试结果可以参考:
https://www.zhihu.com/question/52933117

那我们如何修改拥塞控制算法呢?

  • 首先我们要确保我们是否升级到了4.9版本,使用uname -r 或者uname -a
lizhiyong@ubuntu:~$ uname -r
4.4.0-87-generic
lizhiyong@ubuntu:~$ uname -a
Linux ubuntu 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
lizhiyong@ubuntu:~$

  • 下载linux内核代码方法:到官网下载https://www.kernel.org/
    或者git:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/

升级内核版本的方法:https://kernelnewbies.org/KernelBuild

修改内核使用的拥塞控制算法:

更新完系统内核之后,就可以开启TCP-BBR了。

  1. 编辑/etc/sysctl.conf,并保存

#在文件最底部添加如下两行,如果之前已经有这些内容,请酌情删掉或修改
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

  1. 执行sysctl -p使修改后的配置文件生效
    root@linode:~# sysctl -p
    net.core.default_qdisc = fq
    net.ipv4.tcp_congestion_control = bbr

  2. 查看BBR是否开启

首先,执行下边的命令来确定内核已经开启BBR(如果返回的结果中含有BBR则证明内核已经开启):

sysctl net.ipv4.tcp_available_congestion_control
然后,执行下边的命令,看到有tcp_bbr模块,则说明BBR已经启动:

lsmod | grep bbr

你可能感兴趣的:(操作系统OS,Linux网络编程,tcp/ip,网络,php)