多数人并不懂带宽

请先看懂我的前文。

大部分人根本不懂带宽，包括几乎所有的所谓客户以及多数编程的人，显然，带宽根本不是他们认为的越大越好的东西。

带宽是一个数量，而不是一个速率，它并不代表快，反而可能更慢。说轮船代表大带宽，飞机代表低时延，基本就都懂了。

至于吞吐，它指的是有效带宽，即有效送达的那部分。

有悖直觉的是，越快的网络对吞吐的要求越低，理想情况下所需吞吐仅取决于 min { 生成带宽，消费带宽 } \text{min}\{生成带宽，消费带宽\} min{生成带宽，消费带宽}，以流媒体为例，人可消费的带宽，约 $20\text{Mbps}$ 级，控制信令则更低，这就是自限定的 $\text{app-limited}$ 吞吐，即使数据生成或网络的带宽有 $100\text{Gbps}$，你也只需要几十 $\text{Mbps}$ 不到，这区别于传统的 $\text{capacity-seeking}$ 追求更大吞吐的做法。

如此，如果流执行 $\text{capacity-seeking}$ 行为，网络就会抖，时延不确定性增加，而自限定流量降低了单流规模，这在统计意义上(重点强调这个编程的人总是有意忽略的修饰词)降低了总时延的方差，也就降低了抖动，降低了时延期望。

$\text{BDP}$ 一定，带宽代表的截面和时延代表的长度就是一对矛盾，下载追求高吞吐，在线则要求低延时，只有在网络很慢的时候，才需要高带宽下载，如果网络很快，就会直接在线，而 $\text{CDN}$ 和边缘计算则在两者中间。

随网络基础设施持续迭代，自限定的 $\text{app-limited}$ 吞吐需求成为趋势，得寸进尺地追求自己根本不需要的单流带宽，而不是多流总带宽，这是无知且愚蠢的：

• 单流大带宽总有损于时延和抖动；
• 多流大带宽多被统计律平滑优化；

即使实际流量在重尾帕累托分布下，$\text{Hurst}$ 参数描述，抖动也会随流的叠加而降低，$H$ 越大，降低越慢罢了，但总体还是会随聚合度 $m$ 而降低。统计复用网络传输，核心就是多流的叠加统计，而不是单流的确定性指标，多流的 $\text{buffer}$ 动力学使全局达到帕累托最优状态，收敛到公平。

你们要顺应统计不确定，并习惯将确定性方向交还给统计。

一个简单的例子，若将若干条视频流，文件下载流，控制信令流复用到一个大吞吐流，它们将承受相同程度的大抖动，若将其分开自行传输，则可获得更低的平均时延，而带宽总是够用的。

核心网络指标主要是低延时而非大带宽，广域网的端到端延时标准差一直在感知极限(边缘计算，游戏，视频会议，AI 互动等)内，几乎同一个 $5\text{ms}\sim 100\text{ms}$ 量级，所以网络没有明显的带宽短板，如果非要优化，那就是 $\text{P99}，\text{P999}$，抗抖动最重要。

再重申，没有带宽短板，更没有单流带宽短板，随着基建持续更新，这里对 “没有” 的强调还会加强。如果你实在觉得下载慢，那就多流下载，利用统计律满足你，而统计律会抹平一切贪婪的麦芒。

裤衩子锁着边儿，而且绣着花儿。

题外话， Android 17 release notes 有个有趣的特性：

内存限制器：内存限制器是一种系统服务，用于使用 Linux cgroup v2 监控和限制应用进程的内存用量。内存限制器可防止单个应用消耗过多的系统内存，从而降低系统范围内的内存压力，并防止关键进程被强制终止 (OOM)。

或许网络中也应该有个类似的，专治 $\text{capacity-seeking}$ 协议，这并不是一个限速器，事实上网络并不应该限速，而应该限制 $\text{buffer}$ 的占用，而且也不是设计一个类似 $\text{CoDel}$ 的 $\text{AQM}$，而是作为一个 $\text{RFC-Must}$ 发布。

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