本文继续说终端和网络之间发展的辩证，但从一个具体的派驰代码做引。先来看 Linux 6.17 两个关于 TCP 接收约束的派驰：
- tcp: stronger sk_rcvbuf checks
- tcp: do not accept packets beyond window
虽然不复杂，但值得思考，这是少有的关于端资源约束的派驰，是对严进宽出原则的修补，不均等的能力必须补齐，否则会资源分配的不平衡。那么既然超限几 KB 能宽容，一定是超限更多了才引起注意，从而有了这个派驰，这说明容忍能力没有随着超限能力同步，这预示着必然存在某种极限开始错配了。
简单来讲，它做了以下修改：
c
// 6.16
if (当前已分配内存 < 接收缓冲区)
接收；
else
丢弃;
// 6.17
if (当前已分配内存 + skb->len < 接收缓冲区)
接收；
else
丢弃;让派驰解释自身最好：
Currently, TCP stack accepts incoming packet if sizes of receive queues are below sk->sk_rcvbuf limit. This can cause memory overshoot if the packet is big, like an 1/2 MB BIG TCP one.
不过我不说这个派驰在保护接收端内存约束方面的意义，我要强调它在网络拥塞控制中的意义，它将作为一个主机资源限制的论据。按照广义端到端的观点，两个端并非终结于两个主机的传输层，而始于数据源，终结于人脑，其中的瓶颈是人脑带宽，我将在此基础上展开。
曾几何时，专家经理们总是在 win = min(rwin, cwnd) 之外多发几个数据包，以此行为破坏流量控制和拥塞控制的收敛原则，赌网络和接收主机的宽容行为，达到抢带宽的目的，以此在竞速中获得高分，最终赢得客户。
太好了，有了这个派驰，不让超发了，它堵死了上述一条 "TCP 单边优化" 的路。
但且慢，万一 win = cwnd 呢，如果该 TCP 流是 cwnd-limited，它并不受 rwin 控制，该如何？这是重点。
承接 TCP/IP 的韧性：网络的无限扩展 & 主机的有限能力，文章的最后，我提到 PC 的失败和智能手机的成功，性能过剩的 PC 最终被独占屏幕 app 的智能手机替代，这背后涉及到端到端吞吐由最慢的环节决定这个世人皆知的道理。本文依旧用它说明问题。
互联网的发展路径是这样的：
- 最初，主机和网络都慢，应用设计主要考虑节省主机资源，尽力满足用户需求；
- PC 时代，主机极快，网络相对较慢，应用设计的核心矛盾变为隐藏网络延迟；
- 移动互联网时代，智能终端低延迟优先，网络技术进步，app 独占屏幕，多任务弱化；
- 现在，网络技术继续线性缓慢进步，app 依然独占屏幕，智能终端侧处理资源逐渐相对过剩；
- ...
独占屏幕 app 的智能手机替代 PC，独占屏幕 app(短视频，手游) 对处理性能的要求受限于人对信息的反应和消化能力，过剩的终端性能在实际使用中逐渐与相对慢速的网络适配了，而相对慢速的网络亦在缓慢进步，逐渐追平了相对静止的端性能。PC 到智能手机，是一个由强大但少到平庸而多的过程，网络技术的进步恰恰适配后者，这是一个技术追人力的过程，显然会触顶。
只要人还是人，且人口数量控制在一定范围，就难以预见带宽需求的爆发式增长，在 AI 奇点之前，本质上整个过程的瓶颈就是人脑的带宽，若日后 AI 加入会打破该假设，但那是疯狂投资泡沫破灭以后的事，至少在可预见的三五年还看不到影子。
到此为止，结论是，网络最终将会变成池化资源，TCP 最终受限于主机，win = rwin 将成为多数，而不是 cwnd。
若果真如此，文初展示 Linux 6.17 的 TCP 派驰就意味着它堵死了靠超发来抢带宽的路子，但简单反思后就发现，这种情况下超发的目的已经不是抢带宽了，而是抗丢包，超发更多是以 FEC 的方式发送冗余，并不占有 rwin 提示的接收缓存空间，超发作为护送跟随，到达即丢弃，依然阻止不了专家经理们胡作非为。
一丝安慰是，为 TCP 增加 FEC 功能具有不低的门槛，大多数经理及其治下的工人并不具备相关开发能力，虽然他们能快速开发一个 cc 模块比如魔改 BBR，但他们没有能力修改 TCP 拥塞状态机本身的代码，也就有碍但无大碍了。当然，对于有能力自研 DPDK 用户态 TCP 协议栈的经理及其治下的工人来讲，他们的自研多用于自家数据中心的东西流量而非南北流量，自己内部折腾，不入广域网，不扰民就是高尚。
该派驰阻止的是这些经理，他们会增加 cwnd，并且在 rwin 允许发送的范围外多发送一些数据，试图绕开 tcp_write_xmit 函数 while 循环中由于 cwnd 或 rwin 配额导致 break 的点。
还要多说几句，涉及传输控制与 cwnd 脱钩后的公平性。
对于支撑本文结论的证据，我此前也表达过类似观点，即端限制流。即使没有 rwin 的约束，sender 也会约束，未来将有越来越多的 TCP 成为 application-limited，其算法也不再符合早期的 capacity-searching 特征，因此公平性只在它们破坏了该假设时才给与保证，毕竟我不需要的你不能硬塞。
如此一来，cwnd 将脱离 cc 的控制，RED 对 app-limited，rwin-limited 流做丢包后，cwnd-based cc 对其做统一反应会严重破坏公平性.
但公平性问题并没有因此而弱化甚至消失，而是改变了。
公平性保障的进化类比智人社会，非常相似。万年前的石器时代，所有人全凭体力 capacity-searching，公平性被自然保证，人群当中没有弱鸡存在，然而到了现代，从泰森到睿经理都受到同等保护，公平性从体力公平变成了生存公平。
在网络传输领域，codel 调度算法(同样来自 VJ)配合 AIMD 即可促进类似的公平性演化，我依照其思路曾经做了一版 AQM，按照随机抽样原则，越大的流抽样后的比例越大，依据 buffer 动力学原理，不断变换 hash 种子即可在一个 10ms 级 RTT 内将最大的肇事者筛出来，单独惩罚它即可。反之，对于与 cwnd 脱钩的流，则不再控制或弱控制，保护需求不大的弱者，相关函数很容易改，给一个先看个意思：
c
// 但凡 app-limited 或 rwin-limited 的流都不是 cwnd-limited
static void tcp_init_cwnd_reduction(struct sock *sk, bool is_cwnd_limited)
{
struct tcp_sock *tp = tcp_sk(sk);
...
tp->snd_ssthresh = inet_csk(sk)->icsk_ca_ops->ssthresh(sk, is_cwnd_limited);
...
}例行说点形而上。
TCP/IP 终究还是没能守住互联网点到点对等通信的初心，从 HTTP 开始计算资源就向内容中心集中，短暂的 PC 时代进入智能手机，平板时代后，最终只剩下浏览器，终究还是 HTTP。手机里纵有上百 app，你只能同时使用一个，无论哪个 app 都是一个浏览器，你的手机装了几百个浏览器，它们在竞相争夺你的注意力。
从拼 CPU，内存的 PC 时代到抢你的注意力的智能终端时代之间，网络从运送大宗计算原材料转换成运送多媒体流，从关注大吞吐到关注低时延的转变过程，这个转变过程的意义重大，如果认不清其中技术演进的新逻辑，就会吃大亏。
这转变过程涉及的显然不只是技术上限差距的问题，而是生态再分工的问题，我简单列举一些，不全：
- 考虑到对大量的，突发的小请求的承载，0-RTT，多路复用流成为刚需，QUIC/HTTP3 几乎成了必然；
- HTTP over QUIC/TCP 等标准协议足够好，没有必要再研发新的传输协议；
- 终端不再参与过多本地存储和计算，便不再追求大吞吐，渲染，首屏，交互等低延时 QoE 指标更优先；
- 移动终端，物联网终端对能耗的约束，强化终端不能提供强算力，计算进一步向中心集中，网络更加重要；
- 终端退居交互前端，专注于采集和呈现，其硬件潜力被导向专用任务、能效和传感器；
- 还有什么...
在此背景下，回到拥塞控制和传输优化，也许就知道为何超发没用了，所谓优化并不是获得更高的吞吐，而是在 application-limited 或 rwin-limited 自我约束下，不被 capacity-searching 流过多影响，解决之道当然不是将自己也变成 capacity-searching 流。这其中涉及了对整个传输协议各方面意义何手段的重新评估。
再说说 BBR，随便看看，毕竟这么久了 BBR 也不更了，看来真的是更不动了：BBR v3 latest status。
遗憾的是，虽然 BBRv1 未经论证，我们的互联网已经灌入了比例可观的 BBRv1，它在理论上承诺反 bufferbloat，但大量流共存时，minRTT 将收敛到稳定的统计期望，而 maxBW 则取决于瞬时突发，高于所需，BBR 流几乎总以 g·minRTT·maxBW(其中 g >= 2) 为 inflight，BBR 动力学特征消失，AIMD 的统计特征也被冲刷，大比例的 g·minRTT·maxBW 像混凝土一样灌在互联网的每个角落。
核心问题是，AIMD 会根据共存流量导致的丢包周期变化自行收敛，BBRv1 不会做这种收敛，只要流足够多，ProbeRTT 的作用将被统计律擦除，而 BBR 的正确性依赖 ProbeRTT 状态，到头来却获得一个由中心极限定理作用的稳定 minRTT。
若长期维持 CUBIC，它一定能自适应 app-limited，rwin-limited 背景下的网络流，就像它适应 capacity-searching 流量一样，但 2016 年底 BBR 强大的吞吐能力吸引了大多数人的注意，一对 iperf，所见即所得，BBR 打破了平静。
BBR 短时间被部署到各大互联网数据中心支撑南北流量，彼时已经进入移动互联网时代，高吞吐越发让位于低延时，人们操心的应该是低延时而不是 BBR 所宣传的带宽利用率，bufferbloat 是问题，但 BBR 解决不了该问题，只要不能从数学上证明 BBR 在统计上是收敛的(参见 主宰 TCP AIMD 的中心极限定理)，ProbeRTT 能获得 minRTT 就不可信，这一切都怨经理。
这一切都怨经理。
浙江温州皮鞋湿，下雨进水不会胖。