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函数,仅分析常规调用链。
整体入口如下:
// 当ack时一个可疑的ack,如sack,或者路由发送的显示拥塞控制,或者当前拥塞状态不是正常状态时。
if (tcp_ack_is_dubious(sk, flag)) {
/* Advance CWND, if state allows this. */
if ((flag & FLAG_DATA_ACKED) && !frto_cwnd &&
tcp_may_raise_cwnd(sk, flag))
// 当窗口仍然满足可以增长的条件时,进入拥塞控制,
// 这是一个钩子函数,具体实现由具体拥塞控制算法来实现,
// 对于reno而言可能是慢启动,可能是拥塞避免。
tcp_cong_avoid(sk, ack, prior_in_flight);
// 处理拥塞状态机,暂时不展开
tcp_fastretrans_alert(sk, prior_packets - tp->packets_out,
flag);
} else {
// 当这个ack是一个正常的数据确认包,进入拥塞控制
if ((flag & FLAG_DATA_ACKED) && !frto_cwnd)
tcp_cong_avoid(sk, ack, prior_in_flight);
}
2.2 tcp reno的拥塞控制
tcp reno注册到拥塞控制框架中的是tcp_reno_cong_avoid函数。
其代码较为简单,只是其中多了一部分tcp-abc的拥塞避免算法,其慢启动实现在tcp_slow_start中,可以参考[rfc-3465][tcp_abc]。大体是用已经确认的byte大小来作为拥塞控制的计算,在慢启动阶段会更加激进,但是可能会带来更大的burst。
<