拥塞控制算法（CCA）

$W_{max}$ ：上一次发生丢包时的窗口大小。
$K$ ：在没有拥塞的情况下，窗口从丢包后恢复到 $W_{max}$ 所需要的时间（带入t=0时候计算），其计算公式为： $K = \sqrt[3]{\frac{W_{max} \cdot \beta}{C}}$ 。
推导：

在 t = 0 这一瞬间，窗口值也应该等于 $W_{min}$ 。我们把 $t = 0$ 代入主公式： $W_{min} = C \cdot (0 - K)^3 + W_{max}$

$\beta \cdot W_{max} = -C \cdot K^3 + W_{max}$

所以： $K = \sqrt[3]{\frac{W_{max} \cdot (1 - \beta)}{C}}$
$C$ ：Cubic 的缩放因子（经验常数）。
$\beta$ ：丢包后的窗口乘性减小因子（标准配置通常为 0.7，即发生丢包后窗口立刻砍掉 30%）。

优势与劣势

优势：
- 高带宽时延积（BDP）网络表现优异：由于采用三次函数，当远离 $W_{max}$ 时窗口增长极快，能迅速吃满高带宽长距离有线光纤。
- 稳定性高：当窗口接近 $W_{max}$ 时，三次函数的平台期使得窗口增长非常平缓（W-growth 变慢），能让网络在饱和点保持较长时间的稳定，减少剧烈振荡。
劣势：
- 无线网络下的“丢包错觉”：无线信道存在随机电磁干扰或信道衰落，导致随机丢包。Cubic 分不清这是“拥塞丢包”还是“信道不好引起的随机丢包”，盲目砍掉 30% 窗口，导致吞吐量暴跌 。
- 缓冲区膨胀（Bufferbloat）：它必须排队排到缓冲区溢出才会减速，这会导致网络中长期存在很高的排队时延。

使用场景

有线大宽带网络（如数据中心互联、有线光纤骨干网传输）、传统 Web 网页浏览。

2. BBR： Kleinrock 理想运营点的“模型探测”流派

核心原理

BBR 认为“丢包才减速”太蠢了，它提出应该去实时测量并建立一个网络物理模型 。这个模型有两个最核心的物理量：瓶颈带宽（BtlBw，Bottleneck Bandwidth）和最小传播时延（RTprop， Round-Trip Propagation Time）。BBR 试图让网络维持在两者刚好的交界点——Kleinrock 点（即不排队，但吞吐量达到最大值）。

核心公式

公式一：发送速率（Pacing Rate）—— 决定控流节奏

BBR 彻底抛弃了传统的“拥塞窗口（CWND）”，直接采用速率控制（Pacing Rate）：

$\text{Pacing Rate} = \text{BtlBw} \times \text{Pacing Gain}$

ProbeBw（速度增益）：8 个 RTT 为一个周期。在前 6 个 RTT 中， $\text{Pacing Gain} = 1.0$ （平稳发送）；第 7 个 RTT 中， $\text{Pacing Gain} = 1.25$ （故意超速，把排队队列拉长，试探带宽有没有增加）；第 8 个 RTT 中， $\text{Pacing Gain} = 0.75$ （故意减速，把刚才排队的数据包清空）。

Pacing Rate 决定了发送端均匀发包的速率

公式二：拥塞窗口（CWND）—— 决定管道上限与安全网

$BDP = BtlBw \times RTprop$

将瓶颈带宽和最小传播时延这两者相乘，就得到了网络科学中最著名的物理量——BDP（Bandwidth-Delay Product，带宽时延积）：整条网络管道在完全不产生排队的情况下，最多能容纳的数据包总量。你可以把它想象成一条高速公路上最多能同时跑多少辆车。

$\text{CWND} = \text{BtlBw} \times \text{RTprop} \times \text{Cwnd Gain}$

CWND（Congestion Window，拥塞窗口）在物理意义上并不是“速度上限”，它更准确的物理定义是：网络管道中允许容纳的“最大在途数据量”（Data in Flight）的天花板。

BBR 在常态下会将 $\text{Cwnd Gain}$ （窗口增益）设为 2.0（因为网络是双向的）。

优势与劣势

优势：
- 天然免疫无线随机丢包：不看丢包，只看测出来的带宽和延迟，因此在浅丢包的无线/蜂窝环境下吞吐量极高。
- 彻底解决缓冲区膨胀：由于主动控制排队，时延控制得远比 Cubic 稳定。
劣势：
- 探测机制过于激进：由于每 8 个 RTT 就要“超速”探测一次（对应1.25的那一次），在浅缓冲区（内存小，缓冲区做的浅）或者多流竞争时，极易造成重传率（Retransmission Ratio）大幅度飙升 。
- 强烈的偏见与不公平性：BBR 之间竞争时，大 RTT 的流由于测出来的模型更大（大RTT因为反馈慢会导致探测时，积压更多数据包，积压小RTT的带宽，测得的BtlBw虚高），会疯狂抢占小 RTT 流的带宽，导致严重的不公平。同时，它完全没有对上层 QoE 的感知。

使用场景

视频点播流媒体传输（如 YouTube 骨干网流量）、跨国长距离高丢包率链路。

3. Vegas：极致温和的“时延梯度”流派

核心原理

Vegas 是基于时延（Delay-based）算法的始祖。它的逻辑非常单纯：当网络开始发生拥塞时，路由器/基站的缓冲区会开始排队，此时实际测得的 RTT 必然会大于网络空载时的基准 RTT（BaseRTT） 。Vegas 通过实时监控这个“时延差”，在包还没丢、网络刚开始排队的时候就主动减速。

核心公式

Vegas 通过计算当前网络中排队的期望数据包数量（Diff）来决定调节方向（CWND是一个硬编码的静态常数，根据调节规则进行动态调整）：

$\text{Expected} = \frac{\text{CWND}}{\text{BaseRTT}}$

$\text{Actual} = \frac{\text{CWND}}{\text{CurrentRTT}}$

$\text{Diff} = \text{Expected} - \text{Actual}$

调节规则（引入两个阈值常数 $\alpha$ 和 $\beta$ ，通常为 1 和 3）：

优势与劣势

优势：
- 极致的低延迟与零卡顿：在独占链路时，网络永远不会产生明显的排队时延，重传率接近于零。
- 温和主义：防患于未然，在网络崩溃前完成微调。
劣势：
- “君子”宿命（在竞争中被饿死）：Vegas 只要看到 RTT 上升就会减速。但如果在有源无线基站下，旁边有一个激进的 Cubic 或 BBR 正在疯狂灌包排队，Vegas 会误以为是自己造成的拥塞，不断主动退让，直到把自己的带宽压缩到接近于 0，被彻底饿死（Starvation）。

使用场景

完全隔离的专用网络切片、企业内部专线、对重传和抖动极度敏感的实时互动物联网控制流。

总结：

Cubic 将丢包（Loss）的权衡硬编码为静态；
Vegas 将时延（Delay）的退让硬编码为静态；
BBR 将探测（Probe）的激进程度硬编码为静态。

2. 具有代表性的延时基变体（Copa 家族）

Copa 是学术界近年来最著名的可调节时延基（Tunable Delay-based）拥塞控制算法。它的核心精妙之处在于：它在控制论上证明了，通过调整一个简单的标量参数 $\delta$ ，就能让算法在“极致低时延（像 Vegas）”与“极致高吞吐（像 BBR）”之间连续平滑切换。

1. Copa 的核心原理：基于效用函数最大化的“目标速率”

Copa 属于优化驱动型（Optimization-based）流派的演进（虽然它的执行极其轻量，像规则型算法）。它既不盲目看丢包，也不生硬地去死抠瓶颈带宽，而是为网络流定义了一个性能效用函数（Utility Function）：

$U = \log(\lambda) - \delta \cdot \log(d)$

物理意义： $\lambda$ 代表吞吐量（Throughput）， $d$ 代表排队时延（Queuing Delay），而 $\delta$ 就是应用层对“排队惩罚”的敏感系数。Copa 的目标就是寻找一个发送速率，让这个整体效用 $U$ 达到最大值。

通过精密的控制论推导，Copa 发现要让效用最大化，网络的实际排队时延 $d$ 与当前发送速率 $\lambda$ 在稳态下应该满足一个黄金反比关系： $d = \frac{1}{\delta \cdot \lambda}$ 。

推导：

效用函数是根据网络流体控制理论提出的。让 $U$ 对 $\lambda$ 求导为0（ $\lambda$ 为可控的发送速率）：

$\frac{dU}{d\lambda} = \frac{d(\ln\lambda)}{d\lambda} - \delta \cdot \frac{d(\ln d)}{d\lambda} = 0$

$\frac{1}{\lambda} - \delta \cdot \frac{1}{d} \cdot \frac{dd}{d\lambda} = 0$

当网络稳态时（网络达到了一个动态的平衡运营点）排队时延对发送速率的微分变化率（导数）趋近于一个常数倒数

$\frac{dd}{d\lambda} \approx 1 \quad$

所以得到： $d = \frac{1}{\delta \cdot \lambda}$

2. Copa 的核心计算公式

在实际代码工程中，Copa 不需要去解复杂的对数方程，它把上述稳态解转化为了两步极其轻量的控制回路：

第一步：计算目标速率（ $\lambda_{target}$ ）

Copa 根据当前测得的排队时延 $d$ ，直接计算出当前最理想的目标发送速率：

$\lambda_{target} = \frac{1}{\delta \cdot d}$

变量微观物理含义：
- $d$ （排队时延）： $d = \text{CurrentRTT} - \text{MinRTT}$ 。也就是当前测到的 RTT 减去链路无载时的最小 RTT 。
- $\delta$ （权衡参数）：核心方向盘。 $\delta$ 越大，目标速率对排队时延 $d$ 的惩罚就越敏感，算法越保守； $\delta$ 越小，算法对排队越容忍，越激进。

第二步：速度方向微调（窗口增减规则）

在每个往返周期（RTT）内，Copa 比较当前的实际发送速率 $\lambda_{actual}$ （ $\lambda_{actual} = \text{CWND}/\text{CurrentRTT}$ ）与目标速率 $\lambda_{target}$ 的差距：

(注： $v$ 是速度常数，用来控制增减的步长级别 )。

3. Copa MIT 变体（ $\delta = 0.5$ ）的深层剖析

原理与参数行为

当把参数硬编码设为 $\delta = 0.5$ 时，代入目标速率公式： $\lambda_{target} = \frac{2}{d}$ 。这意味着算法给“排队时延 $d$ ”施加了极高的惩罚权重。只要网络中出现一点点风吹草动的排队（ $d$ 稍微变大），目标速率 $\lambda_{target}$ 就会呈 2 倍的反比剧烈塌陷，迫使 $\text{CWND}$ 立刻转为减速模式。

优势与劣势

优势：
- 极致的空队列与超低延迟：它在物理上能让基站和路由器的排队队列长期保持接近于 0 。
- 零卡顿：由于主动退让，在独占无线信道时，数据流几乎没有任何抖动，能完美保障实时业务的极速传输。
劣势：
- 吞吐量利用率低（恐高症）：在浅丢包或者由于底层无线 HARQ 带来正常时延波动时，它会频繁误判为网络拥塞而疯狂减速，导致无线频谱资源无法被填满（Throughput 偏低）。
- 容易被“饿死”：当它在基站遇到 BBR 这样不顾及排队的激进流竞争时，由于 BBR 灌包导致 $d$ 持续很大，Copa MIT 会无休止地主动退让，直到自己的带宽缩减到接近零。

使用场景

对互动时延要求达到毫秒级极限的实时业务，如 WebRTC 视频会议、云游戏、远程无线控制、无缝音视频通话 。

4. Copa MVFST 变体（ $\delta = 0.04$ ）的深层剖析

原理与参数行为

这是 Meta（Facebook）在构建其全球 QUIC 传输网络（mvfst 库）时选用的工程配置，将参数激进地降低到了 $\delta = 0.04$ 。代入公式： $\lambda_{target} = \frac{25}{d}$ 。这意味着它对排队时延的容忍度直接放大了 12.5 倍！即使网络中已经产生了明显的排队（ $d$ 变大），目标速率依然维持在很高的水位，引导算法继续加大马力灌包。

优势与劣势

优势：
- 极其强悍的吞吐量榨取能力：表现得非常像 BBR，能够容忍并主动填满基站的整个缓冲区，对抗随机丢包的能力大大增强，大文件下载速度极快。
- 极强的抗竞争能力：在面对 Cubic 或 BBR 的压榨时，它凭借超低的退让系数，具备了在基站硬碰硬“肉搏”的底气，不会轻易被饿死。
劣势：
- 人为制造缓冲区膨胀（Bufferbloat）：由于其对排队不敏感，它会在基站内部长期维持一个很深的排队队列，导致单向时延（Delay）大幅度攀升 。
- 对交互式业务极其不友好：高时延会导致视频会议严重掉帧或游戏卡顿。

使用场景

背景大文件下载、CDN 之间的大宗数据同步、超高清视频点播（VoD）的分块预加载。

5. 总结：Mortise 为什么以此指导最终优化？

这两个极端的静态变体完美揭示了拥塞控制的“鱼与熊掌不可兼得” 。

如果你选 Copa MIT（对时延敏感，发包少），文件下载就会慢得像蜗牛（RCT 爆炸）（需要最快的速度、最大的吞吐量传完）；
如果你选 Copa MVFST（对排队无感知，发包大量），视频会议就会卡得像 PPT（延迟/重传爆炸）（极低交互时延）。

Mortise 的做法彻底打破了这个僵局：它不再把 $\delta$ 硬编码死。正如你之前精辟总结的控制行为，当应用处于“视频缓冲区安全”时，Mortise 计算出的偏好提示 $\lambda$ 很大，它就把底层的 $\delta$ 动态拧向 0.5（走 Copa MIT 路线，追求零排队）；而一旦视频面临卡顿风险、或者开始下载超大网页文件时，Mortise 计算出的梯度偏好反转，它就瞬间把 $\delta$ 拧向 0.04 甚至更小（走 Copa MVFST 路线，不惜代价榨干带宽）。

这就是论文通过控制论分析得出闭环映射（Closed-form Mapping），从而用应用层意图实时指挥传输层优化的精妙全貌。

3. 学习型拥塞控制算法（Learning-Based CCAs）

在计算机网络演进到 5G/6G 时代后，由于无线信道的复杂非线性变化，传统的硬编码规则算法（如 Cubic）很难在所有场景下都达到完美的带宽压榨。为了解决这个问题，学术界在 2010 年代末至 2020 年代初，掀起了利用强化学习（Reinforcement Learning, RL）来自动生成拥塞控制策略的高潮。

Orca 代表了“传统规则与强化学习的实用主义结合（单目标）” ，而 MOCC 则代表了“纯数据驱动的多目标灵活迁移” 。

1. Orca：传统与现代联姻的“双引擎”流派

核心原理

传统的纯学习型算法（如早期的 Aurora ）有一个致命缺陷：在一开始没有训练数据时（冷启动阶段），或者在没见过的极端网络环境下，AI 会像无头苍蝇一样乱发包。 Orca提出了一个非常务实（Pragmatic）的混合架构。它保留了经典的 Cubic 算法作为底层执行的“安全网” ，同时在外面挂载了一个深度强化学习（DRL）演员-评论家（Actor-Critic）网络。

当网络平稳时，Cubic 负责提供稳定的底线吞吐。
当 DRL 代理感知到当前处于高动态的无线/移动信道时，AI 就会接管控制权，通过给 Cubic 的拥塞窗口（CWND）或者发送速率乘以一个动态调整因子（ $\Delta$ ），来帮 Cubic 规避无线“丢包错觉”。

核心公式（强化学习的 Reward 奖励函数）

强化学习算法的灵魂在于它的奖励函数（Reward Function, $R_t$ ）。AI 的所有发包动作，都是为了让这个奖励分最高。Orca 是一个单目标（Single-Objective）算法，它采用的是典型的 Kleinrock 效用优化函数变体：

$R_t = \log(Throughput_t) - \alpha \cdot \log(Delay_t) - \beta \cdot Loss_t$

运作机制：
- 输入（State）：AI 实时收集当前的吞吐量变化、延迟梯度、丢包趋势。
- 输出（Action）：AI 决定给底层有线机制施加多大的加速或减速因子。
- 单目标局限：公式里的 $\alpha$ 和 $\beta$ 是固定死的。也就是说，这个 AI 在出厂训练完的那一刻，它对“延迟”和“丢包”的厌恶程度就已经被定死了，不能根据上层应用（如大文件下载 vs 视频会议）的需求动态修改。

使用场景

特定基站覆盖下的高动态移动蜂窝网络、车载移动通信（Walking, Driving 场景）。

优势与劣势

优势：
- 安全性高、泛化底线好：由于有基石 Cubic 托底，即便 AI 在不熟悉的环境里迷路了，系统也能退化回普通的 TCP 运行，绝对不会发生连接彻底中断的灾难。
- 无线压榨强：在移动无线测试环境下，其体验（QoE）和吞吐量显著超越传统的静态算法。
劣势：
- 缺乏业务感知：它是“单目标”的。无法感知上层是网页还是视频，只能以同一套硬编码的 Reward 机制去硬套所有 App。
- 跨域能力受限：如果在没训练过的、排队严重的有源有线网络中运行，AI 的增益因子的扰动容易和骨干网的慢速排队共振，表现变得非常平庸。

2. MOCC：纯数据驱动的“声明式多目标”流派

核心原理

Orca 的单目标 Reward 无法满足多元化 App 的诉求。为了解决这个问题，MOCC（Multi-Objective Congestion Control）彻底抛弃了规则型算法的束缚。它在内部构建了一个纯数据驱动的多目标强化学习网络。它的核心能力是：支持在 runtime（连接运行期间），通过“迁移学习（Transfer Learning）”动态地修改 AI 的优化目标 。

如果应用当前需要“低时延”，网络就通过迁移学习给 AI 注入一套偏向延迟的权重；
如果应用变成“大吞吐”，目标立刻向吞吐量倾斜。

核心公式（动态多目标 Reward 矩阵）

MOCC 不再使用标量 Reward，而是引入了偏好向量（Preference Vector, $\vec{w}$ ）。其奖励函数是一个多维向量与偏好的内积：

$R_t(\vec{w}) = \vec{w} \cdot \vec{F}_t = w_1 \cdot f(T_t) + w_2 \cdot f(D_t) + w_3 \cdot f(L_t)$

其中：
- $\vec{F}_t$ ：是由吞吐量 $T$ 、时延 $D$ 、丢包 $L$ 构成的多维 QoS 得分向量。
- $\vec{w} = [w_1, w_2, w_3]$ ：是由上层应用下发的意图偏好权重。
物理运行：当偏好向量 $\vec{w}$ 改变时（比如从 [0.8, 0.1, 0.1] 变成 [0.1, 0.8, 0.1]），MOCC 会启动内部的迁移学习网络，在几分钟内完成 AI 神经网络策略层的迁移（Migration），从而改变 AI 发包的激进程度。

使用场景

云端多租户混合切片网络、同一个长连接内需要频繁切换业务（如前一秒在下载，后一秒在打实时语音）的智能终端。

优势与劣势

优势：
- 理论上极强的灵活性：它是真正意义上的“意图驱动算法”，第一次实现了让 AI 听从上层命令，动态改变自身的 QoS 追求目标。
劣势（致命的工程代价）：
- 迁移时延极其漫长（反馈黄花菜都凉了）：MOCC 的迁移学习网络在改变目标时，需要耗费几百秒甚至几分钟（several minutes）的时间来完成神经网络的权重调整 。而无线的信道条件变化发生在毫秒和秒级，MOCC 根本来不及反应。
- 完全数据驱动的泛化失败（极高重传的罪魁祸首）：由于没有规则型算法托底，一旦进入没见过的无线弱网环境，AI 极易由于泛化失败而陷入“癫狂发送”状态。

4. 具备自适应能力的调度/接口框架（CCAs with Adaptability）

这些框架与 Mortise 的定位类似，试图根据应用层需求或网络变化做出调整：

Antelope 与 Antelope Copa：一种算法动态切换/选择框架 。它维持一个算法池（如在 Cubic、BBR、Copa 之间切换，或者在 5 个不同的 Copa $\delta$ 参数配置间切换），每隔一段时间根据当前表现决定换用哪种算法。由于切换算法会丢失历史网络状态，容易导致网络振荡和策略错选。
C2TCP 与 DeepCC：专为移动/蜂窝网络设计的开放式调节接口 。它们对外暴露了可调的 Knobs（如允许应用层设置一个期望的平均目标延迟要求），算法在内部据此控制速率。但它们缺乏精准量化上层 QoE 的能力，因此往往只能达到亚最优（Suboptimal）的 QoE 表现

5. 跨层/网络辅助型算法（对标传统启发式）

Mortise 对比的 BBR 和 Cubic 全是“端到端（End-to-End）”算法，即网络中间的基站和路由器是黑盒，全靠端侧去猜。但在无线网络中，基站明明知道当前的信道质量和队列状态。

L4S (Low Latency, Low Loss, Scalable Throughput)：这是当前工业界（如苹果 iOS 16+、谷歌、IETF）正在大力推进的下一代网络标配。它通过极其轻量化的网络侧显式拥塞通知（ECN）标记，让基站毫秒级通知端侧“我要排队了，请微调发送速率”。它实现了超高吞吐与接近零排队延迟的完美结合。
ABC (Available Bandwidth Control) ：这是一种网络侧显式反馈机制，利用无线设备直接向端侧通报瓶颈带宽。

6. 语义感知与应用层紧密协同型（对标 QoE 映射）

在实时音视频传输（如视频会议、直播、云游戏）领域，传统的拥塞控制算法（如 Cubic、BBR）存在一个致命的“跨层断层”：传输层只管运送数据包，视频编码器（Codec）只管按照固定码率压缩视频，两者互不通气。这导致网络变差时，编码器还在源源不断地生成大尺寸的关键帧，瞬间冲垮底层网络。

为了解决这个痛点，学术界和工业界演进出了“语义感知与应用层紧密协同型”流派。它们的核心思想是：打破网络层与应用层的黑盒边界，让拥塞控制与视频编码器深度一体化，从源头上控制每一帧图像的大小。

1. Salsify：帧级别的“编码-传输”全栈一体化流派

核心原理

Salsify 彻底颠覆了传统的“拥塞控制产生一个码率（如 2Mbps），然后编码器去适配这个码率”的粗粒度范式。它提出了一个极具革命性的理念：放弃传统的“秒级码率控制”，直接实行“毫秒帧级别（Frame-by-Frame）”的联动。
微观协同机制：Salsify 内部拥有一套紧密相连的控制环路。视频编码器每完成一帧的编码，就立刻询问传输层当前的瞬时网络时延（RTT）反馈。
双版本编码试探：在实际执行中，Salsify 的编码器在面临不确定网络时，会同时去尝试编码出两个版本的当前帧（一个高画质大文件，一个低画质小文件）。传输层根据最新一毫秒的 RTT 变化，直接下令放行哪一个版本，或者直接命令编码器放弃这一帧。这种设计实现了真正的全栈一体化。
公式微观运行逻辑：

核心公式（基于网络容量的帧尺寸控制）

Salsify 不去计算复杂的应用层 QoE 梯度，它只计算一个核心物理量——当前网络中允许容纳的“最大在途帧尺寸（Token 字节数）上限”：

$\text{Max\_Frame\_Size}_{n} = \text{BtlBw} \times \left( \text{CurrentRTT}_{n-1} - \text{BaseRTT} \right) + \text{MTU}$

公式微观运行逻辑：
- $\text{CurrentRTT}_{n-1}$ ：前一帧传输时测得的实时 RTT。
- $\text{BaseRTT}$ ：网络完全空载时的固有传播时延。
- $(\text{CurrentRTT}_{n-1} - \text{BaseRTT})$ ：代表由于排队产生的纯排队延迟。
- 指导行为：通过这个公式，Salsify 能够精准算出当前瓶颈基站的队列里还剩多少字节的剩余物理空间。它直接把这个字节数作为硬性天花板，强制限制编码器下一帧（第 $n$ 帧）压缩出来的绝对体积，从源头上杜绝了由于视频大帧挤爆基站缓冲区的可能。

使用场景

超低时延交互式视频传输、无人机无线远程实时高清控制、局域网/5G 高清云游戏回传。

优势与劣势

优势：
- 时延控制达到物理极限：由于在发包前就已经算好了基站塞不塞，它能把网络排队时延长期维持在接近 0 的状态。
- 彻底消灭突发卡顿：完美的帧级协同，永远不会因为突发 I 帧（关键帧）导致基站队列溢出丢包。
劣势：
- 对编码器具有极强的侵入性：普通的 H.264/H.265 硬件编码器芯片（如手机内置的硬编）根本不支持这种“一帧编两个版本、毫秒级反复横跳”的变态指令，必须依赖重型 CPU 进行软件编码（Soft-coding），设备功耗极高。
- 缺乏全局公平性：它太自私了，为了保证自己不排队，一看到别人灌包它就自愿把画质缩减到极致，在公网上极其容易被 BBR 或 Cubic 欺负。

2. WebRTC GCC (Delay-based)：基于延迟梯度的 Trendline 滤波流派

核心原理

工业界大名鼎鼎的 Google Congestion Control (GCC) 运行在 WebRTC 架构内部，它是典型的接收端驱动/时延梯度反馈算法。

其中最精妙的部分是基于延迟梯度（Delay Gradient）的控制。当视频包通过无线基站到达接收端时，接收端不看别的，只去测量两个连续数据包组（Packet Group）之间的到达时间差与发送时间差的动态漂移趋势。GCC 利用一个基于最小二乘法的 Trendline 滤波器，去拟合出一条延迟波动的斜率线。如果斜率持续向上，断定基站队列正在累积。

核心公式（Trendline 滤波器与过载检测）

接收端通过计算包组的传输时延差值 $m_i$ （即 $\text{Actual\_Arrival\_Interval} - \text{Expected\_Transmission\_Interval}$ ），并将其送入线性拟合，实时算出延迟梯度的斜率 $m_{trend}$ 。

接收端引入一个动态自适应阈值 $\gamma_t$ ，通过与斜率对比来触发状态机切换：

阈值 $\gamma_t$ 的动态更新公式（防止被恶意有线流量挤死）：

具体更新如下：

$\gamma_t = \gamma_{t-1} + \Delta t \cdot k_t \cdot (|m_{trend}| - \gamma_{t-1})$

变量微观含义解析：

$\gamma_{t-1}$ ：上一个周期使用的旧阈值。
$\Delta t$ ：自上一次阈值更新以来，经过的绝对物理时间。
$|m_{trend}|$ ：当前由 Trendline 滤波器计算出的延时梯度斜率绝对值。它代表了网络队列当前真实的积压或排空速度。
$k_t$ ：控制论中的系统增益系数（System Gain），它不是一个常数，而是取决于 $|m_{trend}|$ 与 $\gamma_{t-1}$ 之间相对大小的分段函数，其设计如下：

标准工程配置中常设为： $k_d = 0.039$ , $k_u = 0.0087$ （即 $k_d > k_u$ ）。

目标码率（ $A_{r}$ ）的加性增/乘性减决策

一旦状态机判定为过载（Overuse），接收端立刻通过 RTCP 消息通知发送端，将发送码率乘性减小：

$A_{r}(t) = \beta \times A_{r}(t-1) )$ （ $\beta$ 通常为0.85）

若处于正常（Normal）且带宽未吃满，则执行类似 Cubic 平台期的加性增加（ $+I$ ）。

使用场景

现代互联网绝大多数在线实时视频会议系统（如腾讯会议、Zoom 的 WebRTC 落地变体、Google Meet）、在线互动直播大厅。

优势与劣势

优势：
- 工业界级高度稳定：Trendline 滤波器能完美滤除无线信道由于多径干扰带来的随机 RTT 抖动噪声，不会因为单个包的延迟而频繁误判。
- 兼顾公平性：动态阈值 $\gamma_t$ 赋予了 GCC 极强的生命力，当它在基站遇到 Cubic 抢占时，它能自动调大 $\gamma_t$ ，表现得更加强硬，不会轻易被饿死。
劣势：
- 反馈环路依然存在延迟：它是通过接收端测出斜率后，通过 RTCP 慢速信道发回发送端的，属于“后知后觉”的反馈控制，在无线信道毫秒级突变（衰落跌落）时，常常来不及降速，导致短暂的卡顿。

3. WebRTC GCC (Loss-based)：基于丢包率的底线平衡流派

核心原理

既然是工业界成熟的流控算法，单靠延迟梯度是不安全的。因为如果网络中间经过了一个浅缓冲区且发生了严重的随机丢包，延迟梯度可能还没发生明显倾斜，包就已经丢光了。

因此，GCC 内部并存着第二个基于丢包率（Loss-based）的互补决策引擎。它直接在发送端监听 RTCP 反馈回来的实时丢包率（Fraction Lost），作为最终的降速和保护开关。

核心公式（基于丢包率区间的码率控制）

发送端在收到丢包率反馈后，将丢包率划分为三个硬编码的黄金区间，直接决定当前拥塞窗口或码率的增减：

使用场景

丢包率波动频繁的弱网环境、多径干扰严重的无线蜂窝网络。
优势与劣势
- 优势：对抗随机无线抖动的“安全安全网”：通过设置 2% - 10% 这个宽泛的“不动作维持区间”，GCC 天然对无线网络轻微的随机丢包具备了免疫力，不会像传统 Cubic 一样一看到丢包就立刻砍掉 30% 速度。
- 劣势：粗粒度与不确切性：这个区间的划分（2% 和 10%）是彻头彻尾的经验值。在 6G 智简网络多元化的业务中，有些高精细业务容忍不了 5% 的丢包，而有些鲁棒性强的业务甚至能承受 30% 的丢包，一刀切的硬编码区间限制了其更高级的意图自适应能力。

7. 意图与声明式控制

在拥塞控制的发展前沿，“意图与声明式控制（Intent-driven & Declarative Control）” 代表了从“网络适配应用”向“应用直接指挥网络”的范式转变。

传统的算法（包括 Mortise 挂载的 Copa）虽然灵活，但必须依赖控制论专家手动去推导目标速率或调节闭环。而声明式控制的核心逻辑是：应用层只需要像写宣言一样，直接抛出一个高维度的效用目标（如：我只要吞吐量，不在乎时延），底层的拥塞控制协议栈就会像智能生命体一样，自己通过在线实验或环境感知，自动去寻找最佳的发送速率。

1. PCC Vivace：效用函数在线微扰的“声明式控制”始祖

核心原理

PCC Vivace 彻底抛弃了传统 TCP 靠 RTT 或丢包来硬编码增减窗口的规则。它认为，网络传输的本质是一个黑盒最优化问题。

声明式接口：它允许上层应用直接声明一个任意的效用函数 $U$ （Utility Function）。
在线经验学习（Empirical Online Learning）：Vivace 的发送端不猜测路况，而是每隔一个很短的周期，故意执行“随机微扰实验”（比如先以速率 $\lambda + \epsilon$ 发一包，再以 $\lambda - \epsilon$ 发一包）。它收集这两次实验带来的实际效用回馈，通过计算在线经验梯度，自适应地向着让 $U$ 更高的方向滚动速率。

核心公式（在线梯度经验寻找）

假设应用层声明的意图效用函数为经典的 $U = T - k \cdot D - q \cdot L$ （吞吐量 - 惩罚权重 $\times$ 时延 - 惩罚权重 $\times$ 丢包）。

Vivace 在每个决策周期，通过微扰测出效用的经验导数（梯度） $\frac{\Delta U}{\Delta \lambda}$ ，并按照以下控制公式更新下一阶段的发送速率 $\lambda_{next}$ ：

$\lambda_{next} = \lambda_{current} + \gamma \cdot \frac{\Delta U}{\Delta \lambda}$

$\gamma$ （步长因子）：由 Vivace 内部的变步长控制论决定，防止冲过头。
物理意义：只要应用层通过修改 $k$ 或 $q$ 改变了它的“意图”，公式里的 $\frac{\Delta U}{\Delta \lambda}$ 符号就会瞬间发生反转，算法会自动、不需要任何人工重写规则地向着新意图的最优速率收敛。

使用场景

跨异构网络的复杂云端传输、上层 QoE 意图多变且无法用标准传统拥塞公式描述的极其复杂的音视频混传业务。

优势与劣势

优势：
- 天然的声明式意图支持：应用层可以定制极其古怪、非线性的效用目标，算法都能在线自动收敛。
- 极高的高带宽压榨率：在干净的高速链路下，其压榨带宽的效率逼近物理极限。
劣势：
- 微扰带来的“人工抖动”（Self-inflicted Jitter）：由于它必须通过“一快一慢”的微扰实验来测梯度，这导致它即使在完全空闲的网络中，发送速率和时延也会产生持续的、人为制造的轻微振荡。

2. Nimbus：基于网络“弹性检测”的意图防御流派

核心原理

在多用户共享基站的无线网络中，声明式控制最大的挑战是“劣币驱逐良母”——你的流声明了“低延迟意图”，表现得很温和；旁边一个流用的是激进的 BBR（比特流意图），疯狂灌包。温和的算法如果不做改变，就会被无情饿死。

Nimbus 首次引入了网络弹性检测（Elasticity Detection）。它的核心原理是：当网络发生排队、时延（RTT）爬升时，Nimbus 会主动去感知这个排队到底是由自己发包引起的，还是由竞争对手灌包引起的。

如果检测到对方是“没有弹性的恶意比特流（如 BBR、Cubic）”，Nimbus 的意图会立刻转为防御模式，变得极其强硬去对抢带宽，防止被饿死；
如果检测到对方是“具备弹性的温和实时流（如 WebRTC）”，Nimbus 会维持智简绅士模式，主动控排队，共享带宽。

核心公式（交错互相关弹性测算）

Nimbus 通过在发送速率 $\lambda$ 中故意注入一个极其微弱、人类无法察觉的正弦波波动信号 $\sin(\omega t)$ ，然后去测量返回的排队时延 $d(t)$ 的波动。

这个忽快忽慢的数据流冲进无线基站的共享缓冲区后，会强行改变缓冲区的积压状态。此时，由于竞争对手的动机（算法行为）不同，基站吐回给 Nimbus 的排队时延反馈 $d(t)$ 会呈现出截然不同的几何特征：

动机一：对手是“温和的延迟敏感流”（如 Copa MIT, Vegas, WebRTC）

这类流的动机是“只要网络排队，我就减速退让”。

微观对抗：当 Nimbus 运行到正弦波的波峰（加速）时，基站缓冲区刚想长高，旁边的温和流敏锐地察觉到了排队，立刻主动踩刹车减速。温和流空出来的空间，刚好把 Nimbus 多发的包容纳了进去。
回波特征：因为对方退让了，基站的排队时延 $d(t)$ 几乎没有跟随 Nimbus 的节奏长高。Nimbus 的发包速度在规律地扭动，但收到的时延反馈却是一条平落的直线。

动机二：对手是“死板的贪婪比特流”（如 BBR, Cubic）

这类流的动机是“不管时延多高，我必须把我的窗口/速率灌满”。

微观对抗：当 Nimbus 运行到正弦波的波峰（加速）时，多发的包在基站排队。旁边的 BBR/Cubic 逻辑极其死板，根本不理会这点排队，继续高歌猛进地灌包。
回波特征：因为对方寸步不让，基站缓冲区瞬间被强行堆高。Nimbus 什么时候加速（波峰），基站排队时延 $d(t)$ 就什么时候跟着飙升（波峰）；Nimbus 减速（波谷），时延就跟着下降（波谷）。排队时延 $d(t)$ 完美地复制了 Nimbus 发送速率的波形和频率！

它计算这两者的交错互相关函数（Cross-correlation, $X_{elasticity}$ ）：

$X_{elasticity} = \int_{t}^{t+\tau} \lambda_{pulsing}(t) \cdot d_{measured}(t) \,dt$

决策状态机：

使用场景

公网多租户竞争极其激烈的复杂有线/无线混合网络、对“带宽被抢占”零容忍的高安全级别业务。

优势与劣势

优势：
- 极强的生存和免疫能力：彻底解决了 Vegas、Copa MIT 这种温和算法在公网上遇到 Cubic/BBR 就会被无情饿死的悲剧宿命。
劣势：
- 算法感知存在周期滞后：计算互相关函数需要积累一定时间窗口的数据（通常需要几个到十几个 RTT），在无线信道突变速度极快（ms级）时，可能还没测出对方的“弹性类型”，信道就已经切换了。

3. Floo：多场景意图平滑自适应的“智简编排”流派

核心原理

Floo是自适应框架流派的集大成者。它认为，无论是让 AI 在线学（MOCC），还是端侧去算梯度（Mortise），在操作系统内核里的开销都太重了，不符合“智简”的原则。

Floo 的核心思想是“场景即意图，策略硬卡槽”。它在底层内核维持一个极其精简、经过工业界千锤百炼的高效规则引擎。Floo 不在运行期间去解复杂的偏导数方程，而是通过动态上下文（Context）感知（如 App 处于前台还是后台、当前是 Wi-Fi 还是 5G 弱网、并发连接数有多少），直接在意图管理面执行快照式（Snapshot）的参数和模式硬卡槽切换。

核心公式（多维上下文意图距离计算）

Floo 通过轻量级向量空间，计算当前网络与业务上下文状态 $\vec{S}_{current}$ 与预设意图卡槽模板 $\vec{M}_i$ 的最小马氏距离（Mahalanobis Distance）：

$\text{Intent\_Slot} = \arg\min_{i} \left( \sqrt{(\vec{S}_{current} - \vec{M}_i)^T \mathbf{\Sigma}^{-1} (\vec{S}_{current} - \vec{M}_i)} \right)$

映射执行：一旦匹配到最佳卡槽（例如匹配到 Slot_3: BACKSTAGE_BULK_DOWNLOAD 后台大文件下载意图），Floo 会直接通过高速内存通道（如 eBPF map）向底层拥塞控制注入一组黄金硬编码参数快照，瞬间跳过一切收敛探测阶段。

使用场景

超大规模移动端 App（如抖音、快手等各类混合了短视频点播、直播、后台缓存、IM 聊天的全能型 App）。

优势与劣势

优势：
- 工程开销极低，真正的“智简”：运行期间只有极其轻量的向量距离匹配和参数覆盖，CPU 消耗接近于零，极度适合手机等移动终端部署。
- 零收敛时延：匹配即切换，不需要像 Mortise 一样经历 2-3 个 RTT 的“试探和逼近”过程。
劣势：
- 对未定义的“灰色意图”缺乏泛化能力：由于其依赖预设的意图卡槽模板，如果遇到一种全新的、非典型的复合应用场景（例如用户一边跨国开视频会议一边后台用 P2P 下载），Floo 可能会在两个卡槽之间产生剧烈的“策略反复横跳（Oscillation）” 。

脑启社区

脑启社区是一个专注类脑智能领域的开发者社区。欢迎加入社区，共建类脑智能生态。社区为开发者提供了丰富的开源类脑工具软件、类脑算法模型及数据集、类脑知识库、类脑技术培训课程以及类脑应用案例等资源。

更多推荐

2.12ms 单步时延！北大相变忆阻器神经动力学芯片：可控存内计算如何突破半个世纪实时计算瓶颈

脑启社区

2026年CSDN年度技术趋势预测：AI原生、量子计算与开发者新范式

2026年技术趋势前瞻本文系统预测了2026年关键技术领域的发展方向。AI将完成从工具到基础设施的转变，量子计算步入实用化阶段，云原生与边缘计算深度融合。开发者工具迎来云化协作化革新，区块链、生物计算等新兴技术加速突破。同时，技术组织面临人才结构变革，需应对安全合规、伦理社会等新型挑战。报告建议决策者关注AI原生应用、量子-经典混合架构等核心领域，开发者需培养跨学科技能，把握云边端协同、可持续计