4. 传输层优化实践：基于RED的音频冗余传输、视频Simulcast与SVC分层编码、RTP over QUIC的探索、DTLS/SRTP加密性能调优
传输层优化，说白了就是在「网络不可靠」和「用户体验不能差」之间找平衡。我在WebRTC项目里摸爬滚打这些年，踩过最多的坑就在这一层。音频丢了一拍、视频卡成PPT、加密握手超时……每一个问题都能让用户直接摔手机。
这一章，我把传输层最核心的四个优化方向拆开来讲。每个方向我都亲手调过，有些坑至今记忆犹新。
4.1 基于RED的音频冗余传输
音频丢包是实时通信里最让人头疼的问题之一。人耳对音频断续极其敏感，哪怕丢一个包，听起来就像「咔」一声。RED（Redundant Audio Data）就是用来解决这个问题的。
RED的原理很简单：把当前音频包和前一两个包打包在一起发送。接收端如果丢了主包，可以从冗余包里恢复。代价是带宽消耗翻倍或翻三倍。
核心思路：用带宽换抗丢包能力。丢包率越高，冗余层数越多。
我在一个跨国会议项目中遇到过极端情况：跨太平洋链路丢包率高达15%。普通FEC根本扛不住，最后靠RED三层冗余才稳住。嗯，这里要注意——冗余不是越多越好，带宽有限，冗余多了反而加剧拥塞。
RED的典型配置参数：
| 丢包率范围 | 冗余层数 | 带宽增幅 | 推荐场景 |
|---|---|---|---|
| 0% - 3% | 0（不启用） | 0% | 局域网、有线网络 |
| 3% - 8% | 1层冗余 | +100% | 普通Wi-Fi、4G |
| 8% - 15% | 2层冗余 | +200% | 弱Wi-Fi、跨国链路 |
| 15%以上 | 3层冗余 | +300% | 卫星链路、极端弱网 |
我曾经踩过的坑：RED和Opus的DTX（不连续传输）一起用会出问题。静音期DTX不发送数据，但RED还在等冗余包，导致接收端解码异常。解决方案是：启用RED时强制关闭DTX，或者在RED头部标记静音帧。
RED的RTP负载格式其实不复杂。每个RED包包含一个主负载和若干冗余负载，每个负载前面有个1字节头部，标明负载类型和长度。接收端根据时间戳排序，如果主包丢了，就用冗余包填补。
// RED包结构示例（Opus编码，1层冗余）
// 头部: 负载类型=RED (127)
// 第一个块: 主Opus帧 (20ms, 320字节)
// 第二个块: 冗余Opus帧 (前一个20ms, 320字节)
// 总大小: 约640字节 + 头部开销
// 接收端伪代码
function handleRedPacket(packet):
blocks = parseRedBlocks(packet)
for block in blocks:
if block.timestamp == expectedTimestamp:
decode(block.payload)
break
// 如果主包没找到，用冗余包
if not decoded:
for block in blocks:
if abs(block.timestamp - expectedTimestamp) < 20ms:
decode(block.payload)
break
4.2 视频Simulcast与SVC分层编码
视频传输的优化比音频复杂得多。分辨率、帧率、码率三个维度互相制约。Simulcast和SVC是两种主流方案，我个人的经验是：没有绝对的好坏，看场景选。
Simulcast：同时发送多个独立编码流（比如720p、480p、360p）。接收端根据自身带宽选一个流来收。优点是解码简单，缺点是编码器压力大、带宽消耗高。
SVC：只发一个流，但流内部分层（时间层、空间层、质量层）。接收端可以丢弃部分层来降低码率。优点是带宽利用率高，缺点是解码复杂度高、编码效率略低。
我的选择建议：SFU架构下，Simulcast更实用。P2P场景下，SVC更灵活。为什么？SFU需要转发多个流，Simulcast让SFU直接选流转发，CPU开销小。P2P只有两端，SVC的动态调整更平滑。
我在一个大型直播项目中做过对比测试。30路视频同时推流，Simulcast的SFU CPU占用比SVC低40%，但总带宽高出25%。最终我们选了Simulcast，因为服务器成本比带宽成本更敏感。
Simulcast的RTP实现要点：
- 每个Simulcast流使用独立的SSRC
- 通过RTP头部中的RID（RTP Stream Identifier）扩展标识流层级
- 接收端通过RTCP反馈带宽估计，SFU决定转发哪个流
SVC的RTP实现要点：
- 使用单一SSRC，通过RTP头部扩展标识层ID
- 时间层通过RTP时间戳的间隔区分
- 空间层和质量层通过Dependency Descriptor描述依赖关系
避坑指南：Simulcast的码率分配不要平均分。我习惯按比例分配：720p占50%码率，480p占30%，360p占20%。这样高分辨率流的质量有保障，低分辨率流作为保底。
4.3 RTP over QUIC的探索
QUIC是Google搞出来的传输协议，基于UDP但实现了TCP的可靠传输、多路复用、0-RTT握手等特性。RTP over QUIC就是把RTP包塞进QUIC流里传输。
为什么有人想这么做？因为UDP在NAT穿透、拥塞控制、丢包重传方面太弱了。QUIC自带这些能力，而且比TCP快。你想想看，如果RTP能直接利用QUIC的可靠传输，那FEC和NACK都可以省掉不少。
但现实没那么美好。我在一个实验性项目中试过RTP over QUIC，遇到了几个问题：
- 延迟问题：QUIC的可靠重传会引入额外延迟，实时性要求高的场景（比如游戏语音）受不了
- 头部开销：QUIC头部 + RTP头部，一个包可能多出50字节以上
- 兼容性：很多中间设备（防火墙、负载均衡）不认识QUIC，直接丢包
目前RTP over QUIC还在探索阶段，WebRTC标准里没有正式采用。但我个人觉得，在非实时场景（比如直播、录播）里，QUIC的优势很明显。实时通话场景，还是老老实实用UDP + FEC + NACK吧。
当前共识：RTP over QUIC适合延迟容忍度在200ms以上的场景。实时通话（延迟要求<100ms）不建议用。
QUIC与UDP的对比：
| 特性 | UDP + RTP | QUIC + RTP |
|---|---|---|
| 传输可靠性 | 无（需FEC/NACK） | 有（内置重传） |
| 多路复用 | 无（需多个UDP端口） | 有（单连接多流） |
| 连接建立 | 无握手 | 0-RTT/1-RTT |
| 头部开销 | ~12字节（RTP） | ~50字节（QUIC + RTP） |
| NAT穿透 | 依赖STUN/TURN | 依赖QUIC的NAT穿透 |
| 实时性 | 高 | 中 |
4.4 DTLS/SRTP加密性能调优
WebRTC强制加密，这是底线。DTLS用于密钥协商，SRTP用于媒体加密。但加密是有代价的——CPU开销、延迟、握手时间。
我在一个嵌入式项目中吃过亏。ARM Cortex-A7的CPU，跑DTLS握手花了3秒，用户都挂断电话了还没连上。后来优化了参数，把握手时间压到500ms以内。
DTLS优化的几个关键点：
- 会话复用：DTLS支持Session ID和Session Ticket，复用后第二次握手只需1-RTT
- 密码套件选择：优先使用AEAD套件（如AES-GCM），减少计算量
- 握手超时：默认超时太长（30秒），我习惯调到5秒，失败后快速重试
SRTP优化的几个关键点：
- 加密算法：AES-GCM比AES-CM快，因为GCM同时提供加密和完整性校验
- 密钥派生：SRTP的密钥派生可以缓存，避免每帧都重新计算
- 硬件加速：现代CPU都有AES-NI指令集，一定要开启
我曾经踩过的坑：在Android低端机上，SRTP的AES-CM加密占用了30%的CPU。换成AES-GCM后降到10%。但GCM的初始化向量（IV）管理要小心，IV重复会导致加密被破解。
DTLS/SRTP性能调优参数表：
| 参数 | 默认值 | 优化值 | 说明 |
|---|---|---|---|
| DTLS握手超时 | 30秒 | 5秒 | 快速失败，减少等待 |
| DTLS会话复用 | 关闭 | 开启 | 减少握手次数 |
| SRTP加密算法 | AES-CM | AES-GCM | 性能更好，安全性相同 |
| SRTP密钥缓存 | 不缓存 | 缓存1000个 | 减少重复计算 |
| 硬件加速 | 自动检测 | 强制开启 | 利用AES-NI指令集 |
重要提醒：加密优化不能牺牲安全性。不要为了性能改用NULL加密或弱密码套件。WebRTC的安全性是底线，一旦被攻破，整个通信内容都会泄露。
最后，我用一张图总结本章的传输层优化体系：
传输层优化没有银弹。RED、Simulcast、SVC、QUIC、DTLS/SRTP，每个工具都有自己的适用场景。我个人的习惯是：先做基线测试，找到瓶颈在哪，再针对性地优化。不要一上来就全上，那样只会让系统变得复杂且难以调试。