7.2 实时传输奠基：RTP/RTCP（The Foundation of Real-Time Transport）

7.1 节的三容器回答了 "装" 的问题，但它们都有一个共同的舒适区：数据要么躺在磁盘里，要么走在 TCP 这种 "迟到也要送到" 的可靠通道上。可实时场景根本不接受这个假设——视频会议里，一句迟到半秒才重传成功的语音，除了打断节奏没有任何价值。当 "按时到达" 比 "一定到达" 更重要时，传输协议必须换一套价值观。

这套价值观的奠基者，是 1996 年初版、2003 年定型至今的 RTP（Real-time Transport Protocol，RFC 3550）与它的孪生反馈协议 RTCP [7]。今天你能叫出名的实时音视频系统——从 SIP 电话到 WebRTC——几乎都站在这对兄弟的肩膀上。

本节按 "取舍 → 字段 → 反馈 → 伏笔" 的顺序递进：

• 7.2.1 实时传输的诞生与 UDP 的取舍：为什么实时场景宁可丢包也不重传；RTP 作为 "框架" 而非 "全家桶" 的分层定位
• 7.2.2 RTP 固定头：十二字节的自描述：序号、时间戳、SSRC、负载类型——恢复秩序所需的最小信息集
• 7.2.3 RTCP：质量反馈环与唇同步：SR/RR 报告、丢包与抖动统计、跨流时间对齐的标准机制
• 7.2.4 从 RTP 到 WebRTC：无连接设计的代价与馈赠，为 7.5 的现代互动埋下的伏笔

完成本节后，我们将拿到理解全部实时协议的钥匙：后续无论 RTMP、WebRTC 还是 SRT，都可以读作在 "可靠性 - 实时性" 天平上的不同配重。