wordpress拖拽式建站主题服务器

看一下 pacing 流失速的成因：

一段时间收不到 ack，丢了 ack 自时钟，cwnd 将耗尽，bbr 虽有 cwnd_gain(上图没有表现)，但在该 cwnd_gain 下不依赖 ack 持续坚持发送多久取决于 cwnd_gain 的数值。

bbr 失速的后果在于它是 pacing 流，即使收到了迟到但正常的 ack，sender 也无法 burst 发送失速期间挤压的数据，bbr 依然按照 pacing_gain * max-win-filtered bw 生成 pacing rate：

考虑到现网环境中 delayed ack，聚合 ack，ack 丢失，lro/gro 很常见，bbr 引入 extra_cwnd 作为 cwnd 的动态补偿缓解失速问题，bbr pacing 流理论上耗尽 cwnd 时，仍有 extra_cwnd 可作为继续发送的配额：

这种动态自适应解决了盲目静态增加 cwnd_gain 削弱限制 inflight 初衷带来 shallow buffer 下的高丢包问题。

问题是如何在理论上失速的那一刻知道未来的 extra_cwnd，这是在预测未来。常规的方法是 “用历史预测未来”，无论保持一个 round-win-filter 还是移动指数平均(EWMA)均可，用曾经的 extra_cwnd 经过运算得到当前 extra_cwnd，即 cwnd = cwnd + extra_cwnd。

这似乎是解决失速问题的唯一方式。

为什么收到迟到但正常的 ack 后立即执行 probe up 为什么不行呢？如图所示：

bbr 是精确调制的 pacing 流，除非有空闲带宽资源出让，probe up 的结果无论理论上还是实际中都不好。理论上，迟到但正常的 ack 是下行链路的独立问题，如果当前记忆中稳定的 bw 恰好合适，上行链路 probe up 行为会造成 queuing，接下来的 drain to target 将回滚掉 probe up 的结果，相当于 probe up 做无用功，在现实的多流共存场景，probe up 行为一定会挤占些 bw 出来，伤害公平性。

ack 是 TCP(and QUIC) 本身属性，它的行为不应作为 bbr 状态机转换的驱动因素，但路径属性的变化却可以，比如 minrtt 改变后就适合立即进行 probe up：

下面的内容为独立但相关的新内容。

无论 extra_cwnd or 是否检测到更小的 rtt 后立即 probe up，均涉及启发判断是否准确，无论过估的 extra_cwnd 还是在不该 probe up 时 probe up，误判代价均是丢包增加。而提高判断的准确性需要更多的 “微观知识”，这意味着算法需要捕捉更多的细节。

比如，算法是否能捕捉下面的细节呢：

聚合 ack 典型的模式(更陡峭些，但图示为了表达意思，缓和了)，显然这种情况下要在一个更长的周期计算 extra_cwnd，rtt 变化快但不必频繁 probe up。问题是如何精确捕捉到这种 “模式”，TCP 自身并没有甄别出这种模式所需的 “知识”。

另一方面，确实只需要遵守一个大原则，而不是精确刻画微观。就像足球，每一场比赛从每一个细节上看是完全随机的，但结果很大程度上却是可预测的，这是既精确又模糊的艺术。但若仅考虑统计特征，显然这些微观细节必然会被湮没，这本身就是一对矛盾。

在 rtt 测量方法 中，我展示的方法或许能解决这个问题，这更像一种基于神经网络的机器学习方法，模型训练好了，链路画像自然就明确了，至于微观细节也就无需再关注，就像 chatgpt 的 “原理”，没人知道 why，但事实上它就是能写出像人写的文本，这本事是涌现出来的。

皮鞋没有蹬上，露着白袜子。

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