Credit-Based Shaper：用 credit 把突发压成节奏

解决什么问题

很多实时业务不是必须在某个精确微秒窗口发送，但需要稳定节奏和带宽保护。突发流量如果随到随发，会让队列压力忽高忽低，也会干扰其他业务。CBS 解决的就是“不要让某类流量以完全突发的方式占用链路”。

它常出现在音视频和周期性数据场景里。相比 Qbv 那种严格开关窗口，CBS 更像流量节拍器：允许发送，但要根据 credit 状态控制速度。

背景与直觉

credit 可以理解成队列的发送余额。当队列有数据但不能发送时，credit 按一定速度积累；当队列发送时，credit 会消耗。credit 低于某些条件时，队列就需要等待。这样一来，流量不会长期超出预留节奏。

这和普通优先级不同。优先级决定谁先发，CBS 还会问“你这类流量最近是不是已经发得太多”。它把竞争从纯抢占式顺序，变成带有速率约束的发送机会。

怎么解决

CBS 的核心参数和保留带宽相关。工程上你要知道某类流量大概需要多少带宽，允许多大突发，以及它和其他队列如何共存。credit 增减速率会影响队列等待和链路占用。

本节的辅助实验让你调节突发强度、保留带宽和 credit 恢复速度。你会看到：保留带宽越充分，突发越容易被吸收；credit 恢复太慢，关键队列会变得保守；突发太强，整形也会承受压力。

带来了什么新问题

CBS 不是严格时间表。它能降低突发和改善抖动，但不能像 Qbv 那样指定“第 100 到 140 微秒只允许某队列发送”。如果业务有非常硬的截止时间，CBS 可能需要和其他机制配合。

此外，CBS 参数配置也需要准确流量描述。保留过少会导致关键流排队，保留过多会浪费链路资源。多个 CBS 队列叠加时，还要分析相互影响。

本节掌握标准

学完后，你应该能不用公式解释 credit 为什么会限制发送节奏，能说清 CBS 适合平滑和带宽保护，不适合单独承诺严格发送时刻。看到队列延迟变大时，也应该能判断是保留带宽不足、突发太强，还是 credit 参数过于保守。