前面屡次提到丢包最终转化为重传时延而类似PFC\text{PFC}PFC憋着不丢则会转化为排队时延这是时延的交易。习惯上人们将拥塞控制算法分类为loss-based\text{loss-based}loss-based和delay-based\text{delay-based}delay-based如果基于时延交易的视角二者则可以统一为一个。TCP\text{TCP}TCP的RFC\text{RFC}RFC以及Linux\text{Linux}Linux实现法则为当出现丢包时重传RTT\text{RTT}RTT采样将不被用于SRTT\text{SRTT}SRTT计算因此丢包和重传便从传输中分离开来单独记为一个事件用来触发AIMD\text{AIMD}AIMD这很合理但作为端到端协议所谓的网络状态其实就是RTT\text{RTT}RTT样本因此这段时间的网络状态监测也跟着脱离了。若将重传的RTT\text{RTT}RTT样本也加入SRTT\text{SRTT}SRTT计算则不但简化了标准和实现也使网络状态监测更加精准。设一个TCP\text{TCP}TCP流的SRTT\text{SRTT}SRTT为ttt一个报文P\text{P}P首次传输的时间戳为t0t_0t0未收到应答后重传若重传111次后收到应答的时间戳为t1t_1t1那么此报文P\text{P}P的RTT\text{RTT}RTT样本则为t1−t0t_1-t_0t1−t0若重传222次后收到应答的时间戳为t2t_2t2那么此报文P\text{P}P的RTT\text{RTT}RTT样本则为t2−t0t_2-t_0t2−t0显然大概率t2−t0t1−t0tt_2-t_0\gt t_1-t_0\gt tt2−t0t1−t0t。这样一来丢包事件就完全体现在RTT\text{RTT}RTT样本里了。把丢包重传时间样本也算入RTT\text{RTT}RTT加权这类样本的比重这样就把loss-based\text{loss-based}loss-based和delay-based\text{delay-based}delay-based算法统一了。除此之外它还能平滑掉噪声丢包而不被误判为拥塞因为偶尔丢一个包引入的大RTT\text{RTT}RTT样本加权移动指数平均会自动平滑掉。你看多好。至于如何去做拥塞控制就需要一个算法设计类似Vegas\text{Vegas}Vegas但也可以基于delay\text{delay}delay去做AIMD\text{AIMD}AIMD。另外像BBR\text{BBR}BBR这种测吞吐的算法其实也将丢包包含了因为丢包一定会体现在吞吐上所以本质上就是正交一旦叠加非正交量参与计算就是故弄玄虚最终弄巧成拙。浙江温州皮鞋湿下雨进水不会胖。