IEEE 802.1Qav 与 Qbv：一对儿搭档
做 TSN 时间敏感网络，你早晚要面对两个协议——Qav 和 Qbv。很多人把它们混着讲，或者干脆只盯着 Qbv 的门控列表。说实话，刚开始我也犯过这个错。
Qav 的全称是 Forwarding and Queuing Enhancements for Time-Sensitive Streams，说白了就是「流预留 + 整形」。而 Qbv 是 Enhancements for Scheduled Traffic，核心就是「门控列表 + 时间槽」。它们不是替代关系，而是前场和后场的关系。
我习惯这么比喻：Qav 是交通管制员，确保每个流有专用的车道和限速；Qbv 是红绿灯调度中心，精确告诉每辆车「绿灯在哪个时刻亮、亮多久」。没有 Qav，Qbv 的调度就是空架子；没有 Qbv，Qav 只能提供统计意义上的保证，做不到硬实时。
Qav 到底干了什么？
Qav 的机制其实不复杂，就两件事：
- 流预留（SRP / Stream Reservation Protocol）：终端站或桥设备通过 MRP 协议注册一个流，告诉网络「这个流需要多少带宽、多大帧、延迟上限是多少」。
- 信用整形（CBS / Credit-Based Shaper）：把流量分成两类——SR 类（A/B 等级）和 BE（尽力而为）。SR 类用信用值控制发送速率，信用够了就发，不够就等。这样能平滑突发流量。
我曾在一条生产线上遇到过一个问题：摄像头流用 Qav 预留了 100 Mbps，可交换机的 SR 队列只有 200 个缓冲区。当两个摄像头同向发流时，信用整形不违规，但队列填满后就开始丢帧。嗯，这里的坑是：Qav 只管整形，不管缓冲区，你得手动算好队列深度。
所以 Qav 能做到的是：在统计上限制每个流的带宽和最大延迟。但它给不了「确定性的时隙」，因为 CBS 的信用积累和消耗仍然有随机性。
Qbv 的定位：把时间切成片
Qbv 的思路更直接：把时间轴切成周期性的时间切片，每个切片对应一组门控打开（比如只发 Class A 的帧）。门控列表定义了每个 Gate 的状态（开/关）和持续时间。
为什么需要 Qbv？因为 TSN 的终极目标是抖动 < 1 μs，Qav 做不到。举个例子：控制帧必须在 50 μs 内到达执行器，可业务流量不时有个大突发。Qav 的信用整形只能压低平均，但峰值仍然可能挤走控制帧。Qbv 直接把时间槽隔离了——控制帧专属槽，谁都不许抢。
Qav 与 Qbv 的协同模型
两者在交换机内部是如何协作的？我画了一张图来解释：
流程图里能看到：帧进来后先按 802.1Q 分类，SRP 做准入控制（Qav 部分）。然后丢到各自的队列——SR 队列做 CBS 整形，BE 不做。最后所有队列汇聚到 Qbv 门控，由门控列表决定哪个队列的帧能在当前时间槽发送。
两者的核心差异
| 维度 | IEEE 802.1Qav | IEEE 802.1Qbv |
|---|---|---|
| 核心机制 | 信用整形 + 流预留 | 时间感知门控列表 |
| 延迟保证 | 统计上限（概率性） | 严格确定性（硬实时） |
| 抖动控制 | 依赖于整形参数，通常数十 μs | 可达 < 1 μs（配合时钟同步） |
| 实现复杂度 | 低，大部分交换芯片原生支持 | 高，需要精确时间触发 |
| 配置依赖 | SRP 注册 + CBS 参数（idleslope, sendslope） | 门控列表（周期长度、每个 Gate 的开启时刻） |
| 适用场景 | 音视频流、非实时控制 | 运动控制、工业以太网、汽车 ADAS |
| 与另一协议关系 | 为 Qbv 提供平滑流量，避免队列溢出 | 依赖 Qav 分类和整形结果 |
实战中的「联合配置」要点
- 先配 Qav，再配 Qbv。我建议先把 SR 流的带宽预留好、CBS 参数算通，让网络在无调度时能正常运行；然后再设计 Qbv 门控时间槽，把关键流放到受保护的槽里。
- CBS 的 idleslope 必须小于等于 Qbv 门控为该队列分配的有效带宽。举个例子：如果 Qbv 给 Class A 的槽占比是 30%，线速 1 Gbps，那么 idleslope 最多设 300 Mbps，否则门控关闭时 CBS 信用溢出，开门瞬间会猛发，破坏调度。
- 不要忽略保护带（Guard Band）。Qbv 切换门控时，如果当前正在发送一个长帧，必须等到该帧发送完成才能切槽。这个保护带时长需要结合 Qav 的最大帧长来算。我踩过的坑：没加保护带，结果门控切时丢了一个巨帧，整个控制周期乱了。
- SRP 注册流和 Qbv 门控列表必须同步更新。如果新增一个流，但门控没调整，这个流可能在预留的时间槽里撞到其他流量。我在项目中用 YANG 模型统一管理 SRP 和 Qbv，避免手动漏配。
一个小结
Qav 和 Qbv 是一对好搭档，但不是孪生兄弟。Qav 解决的是「流怎么排好队」，Qbv 解决的是「什么时候发」。你可以只用 Qav 做软实时，但硬实时场景必须加上 Qbv。反过来，只配 Qbv 却不做流预留，可能导致低优先级流饿死或高优先级流超出带宽。
我记得刚做第一个 TSN 项目时，图省事只配了 Qbv，结果运动控制帧倒是准时了，但音视频流大片花屏——因为 Qbv 把它们的槽压得太小，而流又没有预留保护。后来把 Qav 的 SRP 加上，CBS 按实际码率配好，问题就解决了。所以，理解两者的关系，比背协议条文重要得多。