关于CentOS 6.7之一个TCP重传细节的证实

如果你真的就看完了《 packetdrill框架点滴剖析以及TCP重传的一个细节》，我觉得你应该有一个疑问，那就是RH发行版使用的2.6.32内核真的使用了PRR降窗算法吗？为此，我把故事再撸一遍。
按照标准的2.6.32内核，第一次收到SACK的时候，在进入重传之前，拥塞窗口的值应该是in_flight+1，即2+1=3个段，也就是说可以重传1个段，但是抓包发现重传了2个段，tcpprobe也证实了在进入重传之前，拥塞窗口的值是4，而in_flight的值为2，完全对不上tcp_cwnd_down函数的逻辑啊！
我此时认为一定是哪里我理解错了，肯定是个小问题，于是我试图用tcpprobe去probe这个降窗函数，然而加载模块失败，也就是说系统找不到tcp_cwnd_down这个符号。这隐约让我觉得RH对内核做了patch，以前用Debian的时候发生过这样的事，毕竟每一类发行版甚至同一个发行版的不同版本就是一次定制。于是我在/proc/kallsyms里面找名字比较像的降窗函数，但是没有找到。然后，我准备在http://vault.centos.org/6.7/updates/Source/SPackages/上看看有没有什么端倪。
我的系统发行版版本是：CentOS release 6.7 (Final)
于是我下载了kernel-2.6.32-573.1.1.el6.src.rpm，安装后我查看了源码，主要是tcp_fastretrans_alert的最后：

        if (do_lost || (tcp_is_fack(tp) && tcp_head_timedout(sk)))
                tcp_update_scoreboard(sk,fast_rexmit);
        tp->prr_delivered += newly_acked_sacked;
        tcp_update_cwnd_in_recovery(sk,newly_acked_sacked,fast_rexmit,flag);
        tcp_xmit_retransmit_queue(sk);

注意，在重传之前并没有调用社区版本内核的tcp_cwnd_down来执行Rate Halving降窗算法。我有看一看tcp_update_cwnd_in_recovery的欲望：

/* This function implements the PRR algorithm,specifcally the PRR-SSRB
 * (proportional rate reduction with slow start reduction bound) as described in
 * http://www.ietf.org/id/draft-mathis-tcpm-proportional-rate-reduction-01.txt.
 * It computes the number of packets to send (sndcnt) based on packets newly
 * delivered:
 *   1) If the packets in flight is larger than ssthresh,PRR spreads the
 *      cwnd reductions across a full RTT.
 *   2) If packets in flight is lower than ssthresh (such as due to excess
 *      losses and/or application stalls),do not perform any further cwnd
 *      reductions,but instead slow start up to ssthresh.
 */
static void tcp_update_cwnd_in_recovery(struct sock *sk,int newly_acked_sacked,int fast_rexmit,int flag)
{
        struct tcp_sock *tp = tcp_sk(sk);
        int sndcnt = 0;
        int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);

        if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {
                u64 dividend = (u64)tp->snd_ssthresh * tp->prr_delivered +
                               tp->prior_cwnd - 1;
                sndcnt = div_u64(dividend,tp->prior_cwnd) - tp->prr_out;
        } else {
                sndcnt = min_t(int,delta,max_t(int,tp->prr_delivered - tp->prr_out,newly_acked_sacked) + 1);
        }

        sndcnt = max(sndcnt,(fast_rexmit ? 1 : 0));
        tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
}

这就是PRR了。通过rpm安装包的发布时间以及PRR草案正式变成标准的时间，我们可以看到RH对这个PRR patch的反应是多么的及时。