吞吐与时延的博弈，超发与冗余的交换

做传输协议加速，大家默认激进超发原则，却认为冗余双发不道德，其实这两个是一回事，它们本质上是一种 “矩” 内的交换，就像力和力臂交换但乘积不变一样，成本是固定的。

人们更能原谅激进超发是因为人们对吞吐率的感知力更强，比如 5mbps 就是比 4.7mbps 更好，激进超发就是能提升吞吐，而对时延却有一个相当大的容忍范围，比如音视频流传输，50ms 内的波动是无感的，且更能用 buffer 平滑。

两个一回事，说的是：

• 要高吞吐，用更多的数据包挤更多带宽，易丢包，丢包后重传，用重传时延换高吞吐；
• 要低时延，怕丢包，用冗余数据包补潜在的丢包，多倍数据包，用带宽浪费换低时延。

所以说就是在 B × D 中做交换。经理和工人们青睐前者，鄙视后者。

高吞吐场景需强调不能让链路空闲，且大包属性，倾向乱序发送，multipath 负载均衡，receiver 重组，而低时延场景则需强调 receiver 不能等，必须消除丢包引入的重传时延，若有小包属性更怕重传，倾向 FEC，多倍发送。

现实世界中，高吞吐和低时延本质上是一对矛盾，同时高吞吐和低时延的需求并不多见，因为即使传输如此满足，平衡二者的压力就推到了端。正如吞吐和时延正交(参考 BBR 对 maxbw 和 minrtt 的测量)一样，高吞吐一定不会低时延，反之亦然。

当对小包低时延流做拥塞控制时，其策略与我们惯常理解的基于 cwnd 的 AIMD 拥塞控制思路完全不同。AIMD 拥塞控制，以 Linux 内核实现为例，隐含了一个 MSS 因数的假设，即采用 full-packet 数量而不是字节数做拥塞控制，但对于小包流(典型的如远程登录，远程控制，游戏对局)来说，几乎都是 app-limited 类型，数据量少到尚未确定到达 AIMD 起作用的阈值，这种场景下再好的 cc 也无用武之地。

如果按照字节做拥塞控制，从端侧看，小包流几乎不会触发拥塞控制逻辑，但却引入了另一种事件调度的控制逻辑，这一点结论在任何处理系统都有效，比如主机处理网络中断，流量和包量对主机系统产生的是两种不同的冲击，流量影响 CPU 有效利用率，包量影响 CPU 无效利用率，抖动大多由包量导致的调度差异引发。1000 个 1 字节的小包和 1 个 1000 字节的大包，哪个更容易塞住路由器，小包流对网络的冲击和对主机的冲击一致。

冗余的逻辑是，怕你处理不过来，多发一份，超发的逻辑则相反，既然你还能处理，那就再压榨你一下。

与拥塞控制截然相对的传输加速也面临一模一样的问题，低时延场景所谓加速即降时延，而发送端的小数据量几乎不会影响时延，唯一能做的就是防丢包，与 PFC 等用 buffer 时延做代价防丢包相反，直接付出带宽代价，用冗余防丢包更靠谱。所以你看，即使做无损网络，PFC 仍未将保时延做第一要务，反而将它当小费支付了出去。

无论做广域网还是数据中心加速，喷多倍发送的则不在少数，显然是舍时延而求带宽的偏见，然而，小包流可能根本就不需要更多带宽。

不理解的，建议重新读《TCP/IP 详解(卷 1)》，“第19章：TCP 的交互数据流” 和 “第20章：TCP 的成块数据流”，看看如何区分这两类传输，以及处理小包和大包的不同思想。

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