WebRTC与RTP协议实战：从原理到优化
1. RTP协议基础解析：实时传输的核心骨架
RTP（Real-time Transport Protocol）作为互联网实时音视频传输的基石协议，其设计哲学体现在头部结构的每个bit中。协议头前12字节是固定部分，其中我最常关注的几个关键字段：
- 时间戳（Timestamp）：32位无符号整数，记录采样时刻。在视频场景中，相邻帧的时间戳差值取决于帧率。例如30fps视频中，这个差值应该是90000/30=3000（RTP时间戳以Hz为单位）。
- 序列号（Sequence Number）：16位循环计数器。每次发送数据包+1，用于检测丢包。我在排查问题时发现，超过1%的序列号不连续就会明显影响体验。
- 同步源标识（SSRC）：32位随机数，用于区分同一会话中的不同流。实践中遇到过SSRC冲突的情况，需要实现冲突检测和解决机制。
关键技巧：Wireshark的RTP流分析功能可以直观显示时间戳和序列号的连续性，是排查同步问题的利器。
2. WebRTC中的RTP魔改实践
WebRTC虽然基于RTP，但做了许多针对性优化。通过chrome://webrtc-internals可以看到这些细节：
- 动态码率调整：通过RTCP RR报文反馈网络状况，算法会根据丢包率动态调整VP8/VP9的量化参数。实测在20%丢包环境下，好的实现仍能保持可接受的画质。
- 头部扩展（Header Extensions）：WebRTC添加了abs-send-time等扩展头，精确到微秒级的发送时间戳，这对拥塞控制算法至关重要。
- FlexFEC前向纠错：在RTP包中携带冗余信息，可以恢复特定程度的丢包。配置时需要权衡冗余度和带宽开销，一般建议在移动网络启用。
3. 回声消除（AEC）的工程实现
"回音壁"问题本质是声学回声，WebRTC的AEC模块采用：
- 自适应滤波算法（NLMS）建立回声路径模型
- 双端检测（需要音频发送流作为参考）
- 非线性处理抑制残留回声
调试时要注意：
- 采集设备要有足够的采样率（至少16kHz）
- 避免系统自带的软件降噪干扰AEC工作
- 延迟要控制在100ms以内，否则算法收敛困难
4. 最简WebRTC配置实践
实现基础视频通话需要这些模块协同工作：
| 模块 | 必备功能 | 推荐实现方案 |
|---|---|---|
| 信令 | SDP交换/ICE协商 | Socket.io/SIP |
| 传输 | UDP通道建立 | libdatachannel/自有实现 |
| 编解码 | VP8/H.264编码 | libvpx/OpenH264 |
| 网络穿透 | ICE/STUN/TURN | coturn服务器 |
| 抖动缓冲 | 动态延迟调整 | 基于序列号的缓冲算法 |
在树莓派上实测的最低配置：
- 单核1GHz CPU
- 128MB内存
- 带宽≥512kbps（QCIF分辨率）
5. 典型问题排查手册
案例1：RTP包持续丢失
- 检查防火墙UDP端口开放情况
- 用tcptdump确认包是否到达网卡
- 调整ICE候选策略优先使用中继
案例2：视频卡顿但网络良好
- 检查编码器输出帧率是否稳定
- 确认没有启用软件编码（chrome://flags禁用）
- 调整RTCP反馈间隔为500ms
案例3：回声消除失效
- 确认参考音频流正确送达AEC模块
- 检查音频设备采样率是否匹配
- 尝试调整AEC aggressiveness参数
6. 性能优化实战记录
在4G网络下的优化经验：
- 启用transport-cc拥塞控制
- 设置DSCP标记（CS3用于语音，AF41用于视频）
- 使用ULPFEC替代FlexFEC降低CPU占用
- 关键帧请求间隔调整为2秒
移动端特别注意事项：
- 屏幕旋转时触发SDP重新协商
- 后台运行时切换为音频-only模式
- 使用硬件编码器节省电量