linux内核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函数，仅分析常规调用链。

整体入口如下：

// 当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。

<