📚 课程目录第1章课程导入

1. 课程导入

实时音视频已经渗透到会议、直播、云游戏、远程操控、在线教育等几乎所有实时交互场景。这些场景背后，绝大多数都依赖同一套基础协议栈：RTP/RTCP 负责媒体封装与传输反馈，SRTP 负责加密，RTCPeerConnection / SDP 负责协商，jitter buffer、NACK、FEC、PLI/FIR 负责抗丢包与恢复。RTP 流媒体性能优化，本质上是在带宽、时延、抖动、丢包、CPU/内存开销这五个约束之间寻找动态平衡。本课程的目标，是让你从“能跑通”进阶到“跑得稳、跑得省、跑得清”。

学习本课程后，你应当能够：独立定位 RTP 卡顿、花屏、回声、延迟累积等问题的根因；读懂 Wireshark 抓包中的 RTP/RTCP 关键字段；根据网络质量动态调整码率、FEC、jitter buffer 与重传策略；在 WebRTC、SRS、Janus、Mediasoup、FFmpeg 等常见系统中落地优化参数；并建立一套可复用的性能度量与回归验证方法。

一、核心价值：为什么 RTP 优化值得系统学习

RTP 的性能问题往往不是单点故障，而是链路、协议、编码、缓冲、渲染多环节耦合的结果。一个典型的“画面卡顿”可能来自 Wi-Fi 重传、上行带宽不足、NACK 风暴、jitter buffer 过深、解码器丢帧，甚至渲染线程阻塞。若只凭经验调参，很容易按下葫芦浮起瓢：降低码率缓解了拥塞，却导致清晰度下降；增大缓冲降低了抖动，却抬高了端到端延迟；开启 FEC 提升了抗丢包能力，却占用了额外带宽。

系统学习 RTP 优化的价值在于：第一，建立端到端性能模型，知道每个指标由谁决定、能被谁影响；第二，掌握可观测性手段，用 RTCP RR、TWCC、抓包、统计日志把“感觉卡”变成“数据卡”；第三，形成分层优化策略，从网络层、传输层、媒体层到应用层逐级排查，而不是盲目改参数。

二、整体知识框架：从协议到落地的五层结构

本课程的知识框架可以概括为五层：协议基础层、传输控制层、抗弱网层、媒体处理层、工程落地层。协议基础层关注 RTP/RTCP 报文结构、时间戳、序列号、SSRC、PT 与扩展头；传输控制层关注 GCC、TWCC、REMB、带宽估计与码率分配；抗弱网层关注 NACK、FEC、RTX、PLC、jitter buffer 与拥塞控制；媒体处理层关注编码器码控、关键帧请求、分辨率与帧率自适应；工程落地层关注 SFU/MCU 架构、SRS/Janus/Mediasoup 参数、监控告警与压测回归。

三、方法流程：从“感觉卡”到“数据卡”的排查路径

优化 RTP 性能，推荐遵循“观测—定位—假设—验证—固化”的闭环。第一步，采集基线数据：在客户端和服务端同时记录 RTCP RR 中的 fraction lost、cumulative lost、jitter、RTT，以及 TWCC 反馈的到达时间差。第二步，定位瓶颈层级：若丢包集中在最后一公里，优先考虑 FEC 与 NACK；若 RTT 高且带宽估计偏低，优先检查拥塞控制与发送队列；若解码端频繁请求关键帧，则要检查编码器 GOP 与丢包恢复策略。第三步，提出可验证假设，例如“将 jitter buffer 从 200 ms 降到 80 ms 可降低延迟且不增加卡顿”。第四步，用 A/B 压测验证，观察 P95 时延与卡顿率是否同时改善。第五步，把有效参数固化为配置模板并纳入监控。

# 典型排查命令示例：查看 RTP 流统计与丢包
ffprobe -v error -show_packets -select_streams v:0 input.sdp
# Wireshark 过滤 RTP 与 RTCP
rtp && !rtcp
rtcp
# 查看 WebRTC 统计（浏览器控制台）
pc.getStats().then(stats => {
  stats.forEach(r => {
    if (r.type === 'inbound-rtp') console.log(r.packetsLost, r.jitter, r.framesDropped);
  });
});

四、案例场景：一次会议卡顿的优化复盘

某在线会议系统在弱网下频繁卡顿。初始配置为：视频码率 2.5 Mbps、jitter buffer 固定 200 ms、仅开启 NACK、无 FEC。抓包发现上行丢包 8%，NACK 重传导致有效带宽被挤占，接收端 jitter 达到 90 ms，端到端延迟超过 400 ms。优化措施：第一，启用 TWCC 驱动的带宽估计，将码率上限动态压到 1.2 Mbps；第二，开启 20% 冗余的 FEC，降低 NACK 触发频率；第三，将 jitter buffer 改为自适应，目标 60~120 ms；第四，对关键帧请求做限频，避免 PLI 风暴。优化后，丢包恢复时间从 1.8 s 降到 0.6 s，P95 端到端延迟从 420 ms 降到 210 ms，卡顿率下降约 70%。这个案例说明：RTP 优化不是单参数调优，而是带宽估计、抗丢包、缓冲策略的协同设计。

五、学习清单与实战准备

阶段	核心任务	关键产出
第1~6章	掌握 RTP/RTCP/SRTP 报文与字段语义	能独立解析抓包中的序列号、时间戳、SSRC
第7~14章	理解带宽估计、拥塞控制与码率自适应	能配置 GCC/TWCC 并解释码率变化曲线
第15~22章	掌握 NACK、FEC、RTX、PLC 与 jitter buffer	能针对不同丢包模式选择抗弱网组合
第23~30章	落地 SFU/MCU、监控、压测与调优复盘	形成可复用的性能优化 checklist 与看板

建议在学习过程中同步搭建一套最小实验环境：一台运行 SRS 或 Mediasoup 的服务器、一个 WebRTC 推流页面、一个 Wireshark 抓包点，以及一个可注入丢包/抖动的网络模拟工具（如 tc netem）。每学一个参数，就动手改一次、抓一次包、看一次统计，把知识转化为可验证的经验。

不要在没有基线数据的情况下直接修改生产参数。RTP 优化最危险的误区是“凭感觉调参”：码率、FEC 冗余、jitter buffer 深度、NACK 重传上限之间相互影响，任何单点改动都可能在其他指标上产生副作用。务必先观测、再假设、后验证。

本章建立了 RTP 流媒体性能优化的整体认知：以五层知识框架为骨架，以“观测—定位—假设—验证—固化”为方法，以端到端 KPI 为度量，以真实案例为参照。接下来，课程将逐层深入协议细节、传输控制、抗弱网机制与工程落地，帮助你把每一次卡顿都变成可解释、可修复、可回归的工程问题。