@(Network)[tcp, 慢启动]
TCP拥塞控制两个速率增长阶段分析
0. 参考文档
[1] rfc-5681
[2] tcp-abc-rfc
[3] rfc-3465
[4] rfc-3742
1. 拥塞控制个人理解
1.1 慢启动与拥塞避免
慢启动和拥塞避免,主要是用于拥塞控制中拥塞窗口增长的维护。
根据阈值,拥塞控制其实分为两部分,小于阈值的慢启动阶段,大于阈值进入拥塞避免阶段。
慢启动作为拥塞控制的一部分,我觉得其名字取的比较具有混淆性。个人理解的慢启动分为两种,一种是拥塞窗口小于阈值时候正常的一个指数增长的过程,这个过程中的拥塞窗口不会重置,会持续增长,还有一种是与快速恢复对应的慢启动重新启动,这种时候会将拥塞窗口重置为1,并重新开始指数增长。这么理解的原因如下:
在文档中描述快速恢复时,当收到三个重复ack时候,这时候可能并不是实际丢包,可能是因为链路问题,较晚到达接收端。
- 在BSD 4.3之前会进入慢启动阶段,但是理论上慢启动一般是指数上升的过程,反而是拥塞避免阶段线性上升速度较慢,且拥塞避免会更新当前的拥塞窗口和阈值,会出现小范围衰减。
- 假如tcp认为当前包丢失,会很严格的重置拥塞窗口(具体代码如rto触发tcp_enter_loss),这时候速率曲线不会只是单纯减低到某个值,而是会降低到零点。
1.2 快速恢复和快速重传
因此,个人理解,老版本上收到三个重复ack认为丢包,进入丢包处理,重置了拥塞窗口,在非重复ack到来后,拥塞窗口仍然需要从零开始指数上升,而对于快速恢复而言,其只进入拥塞避免阶段,拥塞窗口只是进行一定修正,在非重复ack到来后,仍然能根据阈值来决定是否执行非重启的慢启动,这时候恢复速度相较于严格的丢包处理快了不少。
由于tcp对于丢包的容忍极低,一旦丢包发生,就会进入严格的拥塞处理,而RTO是丢包主要判断依据,因此快速重传也是针对tcp对于丢包容忍度低的一个修正,避免进入RTO,直接影响传输性能。
2. 拥塞控制代码分析
本章主要基于reno的拥塞控制。下文中的代码均基于linux kernel 2.6.32版本,直到linux kernel 4.9-rc8之前的版本,tcp整体并没有太大变化。本文不分析frto相关内容。
2.1 调用链
由于文档描述上是直接给出一个计算过程,如慢启动阶段的指数上升,和代码直观上看略有不同,因此这里需要先缕清楚整个的调用链,能更好的描述整个拥塞控制的过程。
tcp的拥塞主要是基于定时器(RTO)和ack的,因此主要处理函数都以tcp_ack为起点。这里不分析整个tcp_ack函数,仅分析常规调用链。
整体入口如下:
|
|
2.2 tcp reno的拥塞控制
tcp reno注册到拥塞控制框架中的是tcp_reno_cong_avoid函数。
其代码较为简单,只是其中多了一部分tcp-abc的拥塞避免算法,其慢启动实现在tcp_slow_start中,可以参考[rfc-3465][tcp_abc]。大体是用已经确认的byte大小来作为拥塞控制的计算,在慢启动阶段会更加激进,但是可能会带来更大的burst。
|
|
2.3 慢启动
慢启动里面额外涉及两篇rfc,rfc-3742和tcp_abc。
其中snd_cwnd_cnt为线性增长器,只有当线性增长器大于一个窗口大小时,其才会将发送窗口增加,即其单位为1/snd_cwnd,后续还会在拥塞避免代码中见到。
刚开始看代码时对下面那个循环并不是很理解,不理解为什么++是指数增长,直到放到整个调用栈上看,其具体流程如代码注释中所写,为指数增长的过程。
|
|
2.4 拥塞避免
拥塞避免的代码比较简短,注意2.3中所写的,snd_cwnd_cnt为线性增长器,其单位为1 / w。在reno调用中,这里的w也为snd_cwnd窗口大小。即每一个ack只增加1 / snd_\cwnd大小的窗口。
|
|
3. kernel 4.9的改变
对tcp_slow_start的改动不算是4.9的,早在3.18之前就已经改变了,使用的已经不是之前的snd_cwnd_cnt,而是采用tcp-abc算法来进行慢启动。
慢启动仍然使用类似tcp-abc的实现机制,不过其并不以byte作为单位,而是以MSS作为单位进行处理。
拥塞避免上和老版本类似,也使用到了线性增长器,但是涨幅比之前版本较大,并不是以1为计数,而是以acked,即已经确认的MSS个数据片作为单位。
|
|
@小刘