当前位置：首页 > news >正文

为何某些“拥塞控制算法”根本不成立

news 2026/7/2 7:16:22

为何某些“拥塞控制算法”根本不成立

摘要

本文从闭环反馈控制原理、信息论基础及Linux内核TCP协议栈实现三个维度，论证一类预设固定带宽、无视网络反馈、甚至将丢包视为正向激励的“暴力加速”算法为何在理论上无法收敛、在工程上必然失败。它们不是拥塞控制算法，而是一种开环的定速发送器。

一、拥塞控制的本质是闭环反馈

任何拥塞控制算法，无论其复杂程度如何，都遵循统一的控制回路：

r(t)=f(obs(t)) r(t) = f(\text{obs}(t))r(t)=f(obs(t))

其中r(t)r(t)r(t)为发送速率，obs(t)\text{obs}(t)obs(t)为基于ACK流的观测信息（RTT、丢包率、带宽估计值）。正确的控制回路必须满足负反馈原则：当网络负载过高时，r(t)r(t)r(t)必须减小，使系统回归均衡。

然而，这类“暴力加速”算法采用开环控制：

r(t)=Cassumed r(t) = C_{\text{assumed}}r(t)=Cassumed

其中CassumedC_{\text{assumed}}Cassumed是用户预设的常量。这完全切断了观测与决策之间的反馈链路。控制理论早已证明，开环系统无法应对动态变化：预设过高则引发大面积丢包，预设过低则浪费带宽。将瓶颈带宽视为常数，是对网络最根本动态特性的无知。

二、正反馈——丢包越多，发得越猛

更荒谬的是，这类算法在丢包时非但不减速，反而提速。它们实现了一种“丢包补偿”机制。设确认率为a=ackedacked+lossesa = \frac{\text{acked}}{\text{acked}+\text{losses}}a=acked+lossesacked，则：

rnew=R×1a r_{\text{new}} = R \times \frac{1}{a}rnew=R×a1

当丢包加剧、确认率下降时，补偿后的速率反而升高。这形成了正反馈循环：

丢包增多→速率调高→更严重的丢包→⋯ \text{丢包增多} \rightarrow \text{速率调高} \rightarrow \text{更严重的丢包} \rightarrow \cdots丢包增多→速率调高→更严重的丢包→⋯

控制论中，正反馈是发散和不稳定的根源。这类算法将网络最强烈的负反馈信号扭曲为加速指令，必然导致频繁的RTO超时、窗口坍缩及吞吐量断崖式下跌。

三、对内核协议栈的代码级破坏

深入Linux内核TCP协议栈实现，可精确预见这类算法的灾难性后果。

1. 污染RTT测量

TCP的发送节奏由ACK时钟控制。内核函数tcp_rtt_estimator()基于ACK时间戳计算SRTT和RTTVAR。当发送端以远超瓶颈的速率突发数据时，会引发ACK压缩，产生虚假的极高带宽和极低RTT样本，彻底污染内核RTT估计器。这不仅让自己失聪，更会误导同链路所有其他TCP流。

2. 触发RTO雪崩

暴力发包造成的巨大丢包，常严重到无法触发快速重传。此时内核的终极防线——重传计时器（RTO）超时。在tcp_retransmit_timer()中，cwnd坍缩为1，RTO指数退避至数十秒，连接陷入长时间断流。恢复后算法逻辑不变，立即再次触发RTO雪崩，形成“发送→丢弃→RTO→等待→发送”的残酷循环。

3. 资源空耗与协议栈劫持

在持续高丢包率下，大量数据包在瓶颈处被丢弃。服务器CPU和带宽被浪费在发送注定被丢弃的数据包上。同时，这类算法通过setsockopt粗暴覆写内核拥塞控制决策，相当于劫持协议栈，破坏多流公平性，导致整个瓶颈链路回到1988年之前的“拥塞崩溃”状态。