3. IEEE 802.1Qav 流预留：SRP协议基础、流预留流程、Talker与Listener交互
好，咱们今天聊聊流预留。说实话，AVB这套东西里，流预留是最核心的环节。没有它，你那些音视频数据在以太网上就是瞎跑，跟普通数据包没区别。
我刚开始接触车载以太网时，总觉得流预留不就是打个招呼嘛，Talker说我要发数据，Listener说我要收数据，完事了。后来在项目里被坑过一次才明白——这里面的门道多着呢。
3.1 SRP协议基础
SRP，全称是Stream Reservation Protocol。说白了，就是给数据流提前占座位的协议。
你想想看，一辆车上那么多ECU，摄像头要传视频，音响要传音频，控制信号也要跑。如果大家都抢着发数据，那不乱套了？SRP就是解决这个问题的——谁要发数据，先来登记，网络给你预留带宽。
我个人习惯把SRP理解成「预约系统」。就像你去餐厅吃饭，先打电话订位，到了直接入座。没预约的？那就排队等着吧。
SRP的核心要素：
- Talker：数据发送方，负责发起流预留请求
- Listener：数据接收方，负责响应流预留请求
- 流（Stream）：从Talker到Listener的单向数据通道
- 预留带宽：为每条流保证的最小传输速率
这里有个关键点——SRP工作在数据链路层，用的是IEEE 802.1Qat标准。它不依赖IP，不依赖TCP/UDP，直接在MAC层干活。为什么？因为音视频数据对延迟敏感，你跑到上层去折腾，黄花菜都凉了。
3.2 流预留流程
好，咱们看看流预留到底怎么走。我把它拆成几个步骤，这样好理解。
3.2.1 第一步：Talker宣告
Talker想发数据了，它先发一个叫Talker Advertise的报文。这个报文里写了什么？
- 流的ID（唯一标识这条流）
- 数据帧的大小和间隔
- 需要的带宽（算出来的）
- 优先级和VLAN ID
这个报文会沿着网络一路广播下去。每个交换机收到后，都会检查自己有没有足够的资源。如果有，就继续往下传；如果没有，就改成Talker Failed报文，告诉Talker这条路走不通。
避坑指南：我曾经在项目里遇到过一个问题——Talker宣告报文发出去后，Listener一直没响应。查了半天，发现是交换机的SRP功能没开。嗯，这种低级错误，犯一次就记住了。
3.2.2 第二步：Listener响应
Listener收到Talker Advertise后，如果它愿意接收这条流，就发一个Listener Ready报文。这个报文沿着原路返回，告诉沿途的交换机：我要收这个流，你们把资源留好。
如果Listener不想收，或者收不了（比如资源不够），就发Listener Asking Failed报文。
这里有个细节——Listener可以同时收到多个Talker Advertise（比如多个摄像头都在发视频流）。它可以选择接收其中几个，拒绝其他的。这个选择逻辑，由上层应用决定。
3.2.3 第三步：资源确认
当Talker收到Listener Ready后，它就知道网络已经准备好了。这时候，它就可以开始发数据了。
但注意——数据不是立刻就能发的。Talker要等一个「稳定时间」，确保所有交换机都完成了资源预留。这个时间一般是几百毫秒，具体看网络规模。
| 步骤 | 报文类型 | 方向 | 作用 |
|---|---|---|---|
| 1 | Talker Advertise | Talker → 网络 | 宣告流需求 |
| 2 | Talker Failed | 网络 → Talker | 资源不足 |
| 3 | Listener Ready | Listener → 网络 | 确认接收 |
| 4 | Listener Asking Failed | Listener → 网络 | 拒绝接收 |
3.3 Talker与Listener交互
Talker和Listener的交互，说白了就是「你情我愿」的过程。但这里面有几个坑，我踩过，跟大家说说。
3.3.1 一对多的情况
一个Talker可以对应多个Listener。比如车载摄像头，视频流要同时发给座舱域控制器和自动驾驶域控制器。这时候，Talker发一个Advertise，两个Listener分别回Ready，网络会为这条流预留两份带宽。
但注意——带宽是累加的。如果每个Listener需要10Mbps，两个就是20Mbps。交换机得算清楚这笔账。
3.3.2 多对一的情况
多个Talker对应一个Listener。比如四个环视摄像头，都往同一个域控制器发数据。这时候，Listener会收到四个Talker Advertise，它得决定收哪些。
我建议的做法是：Listener先评估自己的处理能力，再决定接收哪些流。如果处理不过来，就拒绝优先级低的流。
注意事项：SRP的流预留是单向的。如果你需要双向通信（比如控制指令+视频回传），那就得建立两条独立的流。别想着一条流搞定所有事，那不符合AVB的设计哲学。
3.3.3 流预留的撤销
流不是永远存在的。当Talker不想发了，或者Listener不想收了，就需要撤销预留。
撤销流程很简单：
- Talker发Talker Advertise，但把带宽设为0
- 或者Listener发Listener Ready，但把状态设为「不再需要」
- 交换机收到后，释放对应的资源
嗯，这里有个小细节——撤销报文可能会丢。所以协议里设计了超时机制。如果一段时间没收到心跳，交换机就自动释放资源。这个时间一般是3-5秒，具体看配置。
3.4 实战中的注意事项
说了这么多理论，咱们聊聊实际开发中容易踩的坑。
- 带宽计算要留余量——我习惯多算20%。因为实际传输中，帧间隔、前导码、CRC这些都会占用带宽。别卡得太死。
- 优先级别乱设——AVB有固定的优先级映射。SRP流一般用优先级3-5，别跟普通数据流混在一起。
- 交换机配置要一致——所有交换机上的SRP参数必须统一。我曾经遇到过两台交换机MSTP配置不同，导致流预留报文被丢弃，查了两天才找到原因。
- 测试要覆盖边界情况——比如所有Listener同时请求、网络拓扑变化、Talker突然掉线。这些场景在实车上都会遇到。
个人经验：调试SRP时，我建议先用抓包工具看看报文交互。Talker Advertise有没有发出去？Listener Ready有没有回来？交换机有没有改报文？一看就明白。别光靠猜，那效率太低了。
好了，关于SRP流预留，今天就聊这么多。下一章咱们会深入讲802.1Qav的转发和排队算法，那才是真正决定延迟的关键。到时候再细聊。