前置知识，TCP thin stream，参见：

• 该文档中搜索 tcp_thin_linear_timeouts
• TCP-thin-stream

看图说话：

参见 tcp_retransmit_timer 函数，着重看下面段落：

if (sk->sk_state == TCP_ESTABLISHED &&
    (tp->thin_lto || net->ipv4.sysctl_tcp_thin_linear_timeouts) &&
    tcp_stream_is_thin(tp) &&
    icsk->icsk_retransmits <= TCP_THIN_LINEAR_RETRIES) {
        icsk->icsk_backoff = 0;
        icsk->icsk_rto = min(__tcp_set_rto(tp), TCP_RTO_MAX);
} else {
        /* Use normal (exponential) backoff */
        icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
}

thin stream 在严重拥塞丢包率高场景会加大 rto 变 0 的可能性从而按照 HZ 频率盲灌重传报文，加重拥塞。

要么关掉 sysctl_tcp_thin_linear_timeouts，要么用 BBR 算法(BBR 不更新 ssthresh，tcp_stream_is_thin 恒为 false，钻了个空子)。

但真要打开 sysctl_tcp_thin_linear_timeouts 呢？so？我觉得这是 Linux kernel TCP 的 BUG！诚然，srtt，rttvar 为 0 无可厚非，采不到就为 0，可 rto 为 0 没有任何现实意义。

很简单的拍脑袋：

- icsk->icsk_rto = min(__tcp_set_rto(tp), TCP_RTO_MAX);
+ icsk->icsk_rto = min(max(__tcp_set_rto(tp), 1), TCP_RTO_MAX);

谁有空给 Linux kernel 社区提个 patch？反正我对社区鄙视且没兴趣(所有内卷的领域都没兴趣，包括全民发烧)。

Linux kernel 社区，这可是大好的秀场，方便后面找工作吹逼。

浙江温州皮鞋湿，下雨进水不会胖。