4、SRP流预留协议：Talker与Listener机制、流预留流程、带宽计算
好，我们进入SRP流预留协议。这个协议，说白了就是给音视频数据在以太网上「占座」用的。
你想想看，车载以太网不像传统AVB用的那种专用总线，它是个共享网络。如果所有节点都抢着发数据，那音视频流肯定卡成PPT。SRP就是来解决这个问题的——它让发送方（Talker）提前声明「我要发多少数据」，让接收方（Listener）确认「我能收下」，然后沿途的交换机预留好带宽和缓冲区。
我个人习惯把SRP理解成「网络版的会议室预约系统」。你开会前先订好房间、投影仪、麦克风，别人就不能占用了。SRP干的也是类似的事。
4.1 Talker与Listener：谁在说话，谁在听？
SRP里有两个核心角色：
- Talker（说话者）：音视频数据的发送方。比如座舱里的麦克风阵列、摄像头、媒体播放器。
- Listener（收听者）：音视频数据的接收方。比如功放、显示屏、DSP处理器。
一个Talker可以对应多个Listener，这叫「多播流」。比如一路麦克风音频，可以同时发给功放和语音识别模块。
嗯，这里要注意：Talker和Listener都是逻辑角色。同一个物理设备，可能既是Talker又是Listener。比如一个智能功放，它接收音频流（Listener），同时也发送诊断状态流（Talker）。
关键点：SRP只关心流的方向和资源需求，不关心数据内容。它就是个「交通调度员」，不是「快递员」。
4.2 流预留流程：三步走
SRP的流预留流程，我总结为三步：
- Talker宣告：Talker在网络上广播一个「Talker宣告」消息，里面包含流的特征信息——比如目标MAC地址、VLAN ID、数据帧大小、发送间隔、优先级等。
- 交换机注册：沿途的802.1Q桥（交换机）收到宣告后，检查自己是否有足够的资源（带宽、缓冲区）。如果有，就注册这条流，并继续转发宣告；如果没有，就回复一个「Talker失败」消息。
- Listener加入：Listener收到宣告后，如果愿意接收，就发送一个「Listener加入」消息。交换机收到后，正式为这条流分配资源，并建立转发路径。
整个过程是端到端的。Talker和Listener之间可能隔着好几层交换机，每一层都要确认资源。
我的经验：我曾经在一个项目中遇到「流预留成功但数据不通」的怪问题。查了两天才发现，是某个交换机的优先级队列配置错了。SRP只负责预留带宽，不负责配置队列优先级——这是两码事。所以调试时，一定要同时检查SRP状态和交换机QoS配置。
4.3 带宽计算：别被数字骗了
带宽计算是SRP里最容易出错的地方。很多人以为「我发一个192kHz/24bit的立体声音频，带宽就是192000×24×2 = 9.216Mbps」。错！
实际占用的带宽，要比这个高得多。为什么？因为以太网帧有开销。
一个标准的AVB音频流，通常用1722协议封装。每个以太网帧包含：
- 前导码 + 帧定界符：8字节
- MAC目标地址：6字节
- MAC源地址：6字节
- 802.1Q标签（含VLAN和优先级）：4字节
- 以太类型：2字节
- 1722头部：至少8字节
- 音频负载：N字节
- 帧校验序列（FCS）：4字节
- 帧间隙（IFG）：12字节
加起来，每个帧的固定开销大约是50字节。如果你的音频负载很小，那开销占比就很高。
举个例子：
| 参数 | 值 |
|---|---|
| 采样率 | 48 kHz |
| 位深 | 24 bit |
| 通道数 | 2 |
| 每帧采样数 | 6（常见于1722音频流） |
| 音频负载 | 6 × 2 × 3 = 36字节 |
| 总帧大小 | 36 + 50 = 86字节 |
| 发送间隔 | 125 µs（对应48kHz/6采样） |
| 实际带宽 | 86 × 8 / 0.000125 = 5.504 Mbps |
而纯音频数据只有 48k × 24 × 2 = 2.304 Mbps。你看，实际带宽是纯数据的2.4倍。
避坑指南：我曾经在项目初期用「纯数据带宽」做网络规划，结果上车实测时交换机频频丢包。后来才发现，SRP预留的带宽是基于「总帧大小」计算的，不是基于音频负载。所以做带宽预算时，一定要把以太网开销算进去。我建议你直接按「总帧大小 × 8 / 发送间隔」来算，别偷懒。
4.4 带宽预留的实战公式
好了，给你一个我常用的带宽计算公式：
实际带宽(Mbps) = (音频负载字节 + 50) × 8 / 发送间隔(秒) / 1000000其中：
- 音频负载字节 = 采样数 × 通道数 × (位深/8)
- 发送间隔 = 采样数 / 采样率
- 50 是固定开销（含前导码、MAC头、VLAN标签、1722头、FCS、IFG）
举个例子，如果你用48kHz、24bit、2通道，每帧放48个采样：
音频负载 = 48 × 2 × 3 = 288字节
发送间隔 = 48 / 48000 = 0.001秒 = 1ms
实际带宽 = (288 + 50) × 8 / 0.001 / 1000000 = 2.704 Mbps嗯，这个值才是你真正要在SRP里声明的带宽。
4.5 多流场景下的带宽叠加
实际座舱里不会只有一路流。麦克风、导航提示音、电话、媒体播放……可能同时有十几路流。这时候，所有流的带宽要累加。
但要注意：不是简单加法。因为不同流的发送间隔可能不同，峰值时刻可能重叠。我建议你按最坏情况算——假设所有流都在同一时刻发送一个帧。
举个例子：
- 流A：每125µs发一个86字节帧 → 5.504 Mbps
- 流B：每1ms发一个338字节帧 → 2.704 Mbps
- 流C：每1ms发一个188字节帧 → 1.504 Mbps
最坏情况总带宽 = 5.504 + 2.704 + 1.504 = 9.712 Mbps。这个值要小于交换机的端口带宽（通常是100Mbps或1000Mbps），并且要留出20%~30%的余量。
我的习惯：做带宽规划时，我会先列一个Excel表，把每路流的参数都填进去，自动算出实际带宽。然后留30%余量。如果超过端口带宽的70%，我就考虑用VLAN隔离或者降低流的质量。别等到上车再发现带宽不够，那时候改起来就痛苦了。
4.6 总结
SRP流预留协议，核心就是三件事：
- Talker宣告：告诉网络「我要发什么流」
- Listener加入：告诉网络「我要收这个流」
- 交换机注册：沿途预留带宽和缓冲区
带宽计算时，千万别忘了以太网帧的50字节固定开销。我见过太多工程师在这个坑里摔跟头了。
下一章，我们会讲FQTSS转发与排队算法——数据进了交换机之后，怎么保证音视频流不被其他流量干扰。嗯，那才是真正考验交换机性能的地方。