苹果手机做网站服务器地推推广平台

本文以 tcptrace 图为基，描述传输的微观行为，并给出一个初中几何描述的压水井模型。

统计复用网络的拥塞控制，宏观看 inflight，微观看 pacing rate，宏观大方向不对，微观再正确也不行。

而网络的统计动力学事实上就是 buffer 动力学，详情参见 边际效益递减与 buffer 和 buffer 越大越低效。

如左图所示，如果按照 delivery rate 设置 pacing rate，则会引发木桶效应，接下来的 delivery rate 充其量不变，大概率只会越来越小，即使有空闲带宽腾出也无法抓住，ack 流也会过早闭合而引发类似糊涂窗口综合症那般的细流：

所以 bbr 才需要周期性 probe，取 bw window 内的 maxbw 作为 pacing rate，为防止 maxbw 颠簸，还要确保在 bw window 内至少进行一次 probe，这就是 bbr 采用大开合的根本原因，否则 bbr 要么保不住带宽，要么跑飞。

大开合的问题前面已经描述过，详见 bbr 是真的不行，所以需要引入 probertt 和 cwnd_gain 来约束 inflight。cwnd_gain = 2 约束了 bbr 流的最大 inflight 不超过 maxbw*minrtt 的 2 倍。如此，buffer 挤占才不会无限疯长。

看到了吧，bbr 实际是通过引入很多约束来避免大开合潜在的正反馈。如果把 probe 操作多出来的 1/4 bdp 均匀分散在整个传输过程，控制总 inflight，并始终用 4/5 pacing gain 做 pacing，一切就省了。

先看与 pacing rate = delivery rate 相比，bbr 改变了什么：

bbr 逆转个视角，将 probe 流量分摊到整个传输过程，始终以 > 1(比如 5/4) 的 pacing gain 发送，为抑制因此而引发的 buffer 侵占制造的严重拥塞，算法转而控制 inflight 而不是 pacing rate：

• 拥塞避免方面，保持 optimal_bw*minrtt(注意不是 maxbw) 为 inflight 主体以及极小量且负反馈收敛的的 buffer 队列，避免拥塞；
• 带宽利用率方面，微小队列始终保持 100% 利用率；
• 公平性方面，所有流量对 E_best = max(bw / delay) 的共识，bw 达到 optimal_bw 适可而止，向局部最优收敛达到全局最优；
• 自适应带宽变化方面，微小队列保持对带宽变化的感知力。

整体就是用大 pacing rate 保 optimal_bw：

统计的东西要用统计的方式玩，端到端拥塞控制，必须确认哪些度量是确定的，哪些是不确定的，所有度量中，能大致确定的只有 rtt 和 delivery rate，因此只能信任它们本身以及它们的简单运算量，所有其它量都不能信任，不是调参难度很大，而是瞎搞。

pacing rate 根本控制不住，能控制的只有 inflight。

接下来在 tcptrace 图中展示 E_best = max(bw / delay) 共识及其几何和力学意义：

这很像农村的那种压水井，它的操作就是向上拉把手，拉到一定高度后往下压，即可出水，但它不想打气筒，因为打气筒是你拉的越高，充气量越多，压水井却受水压限制，如果把手可以拉无限高，拉得越高，相比出水量而言越不划算(拉高把手所费的力气相比出水量而言)。

能够挤压的任何流体都符合这个模型，包括钞票存贷。模型的操作图示如下：

代数式上，设总带宽为 a，buffer 已用量为 b，问题 4 等价于求 E = a * x / (x + b)^2，物理意义就是 “挤压带宽的边际效益”，也就是 “单位 buffer 的收益”，显然它是一个上凸曲线。

在力学解释上，一开始出大力压杠杠的收益相对于 b 的固有势能收益而言是非常明显的，一旦出大力开始超过固有势能的做功就反转了，倒着看，固有势能做功每减少一点，其损失的收益将减速减少。这背后是向最稳定趋向的趋势，也就是最小作用量原理。

只可惜包括 bbr 在内的几乎所有拥塞控制算法都没能利用这个共识。vegas 稍微沾边儿时就被喷了，几乎所有拥塞控制方案都试图在微观层面控制统计特征，而我揭穿一些事实也不在乎有人白嫖，因为我这些是拥塞控制的核心本质但并不关注单流吞吐，不添堵，我这些和众人的目标并不一致，人们更感兴趣的是把乘法降窗改成减法降窗，把参数调激进，见缝加塞，而这些都是在行业保身立命的根本，可不敢随意给别人看。

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