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

解决什么问题

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

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

背景与直觉

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

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

怎么解决

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

可以把 CBS 的行为拆成三段。

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

带来了什么新问题

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

此外，CBS 参数配置也需要准确流量描述。保留过少会导致关键流排队，保留过多会浪费链路资源。多个 CBS 队列叠加时，还要分析相互影响。理论上更严谨的最坏情况延迟分析也会把 shaper 纳入模型，而不是只看平均效果。

检查点

• 为什么 CBS 可以减少突发，却不能像 Qbv 一样指定某个窗口发送？
• 如果一个 CBS 队列延迟持续变大，你会检查保留带宽、突发强度还是 credit 参数？为什么？