7.2.1 实时传输的诞生与 UDP 的取舍（Real-Time Transport & The UDP Trade-off）

一场价值排序的革命

文件下载的世界里，可靠性是铁律：少一个字节，压缩包就打不开。TCP 为这条铁律配齐了重传、排序、拥塞控制三件套，代价是——它从不承诺时效。网络一抖，重传的等待会以秒计。

实时音视频把这层关系整个翻了过来。一场语音会议里，每个数据包都有严格的 "保鲜期"：20 毫秒的语音帧，晚到 200 毫秒就一文不值——迟到的包补进播放队列，听感上不是 "完整"，而是一次突兀的卡顿。在实时世界里，迟到等价于丢失；为了等一个迟到的包而卡住后续一百个包，是最亏本的买卖。 RTP 的设计哲学由此而来：把可靠性从协议里请出去，把恢复秩序所需的工具交到接收方手上 [7]。

UDP 之上：一场各取所需的合作

RTP 最典型的搭档是 UDP。这个选择的逻辑链条很直白：

• 不重传：UDP 发出去就不回头，丢失的包由上层决定要不要追、怎么追——对实时流，答案通常是 "不追，继续走"
• 不保序：UDP 不做排序缓冲，包到了立刻上交，延迟只由网络决定，不为协议所累
• 无连接：没有三次握手、没有连接状态机，包带上自己的全部身份信息就走

当然，UDP 也不是白拿的：它没有拥塞控制，网络一旦过载， UDP 流不会自动降速——适应网络的责任被原封不动地推给了应用层。RTP 的答案是它的孪生兄弟 RTCP：周期性回传丢包率与抖动统计，发送端据此调整码率（7.2.3 详述）。反馈环的存在，让 "无拥塞控制" 从缺陷变成了可控的开放接口。

值得留意的是，RTP 并没有把自己焊死在 UDP 上。规范开宗明义：RTP 与底层传输解耦，TCP 或其他传输之上同样可以运行 [7]——UDP 只是实时场景下最常见的那个选择，而非绑定的前提。

一份协议，三层文档

初次接触 RTP 体系的读者常被它的文档结构绕晕：为什么 RFC 3550 里找不到 "H.264 怎么打包" 的答案？因为 RTP 从一开始就被设计成一个 框架（framework），纵向分三层：

本体只管 "所有实时流共享的骨架"；某类应用场景的公共约定放进 profile；每种编码的具体打包方式（怎么分片、怎么标记帧边界）则各有各的负载格式文档。本书第六章讲过的编码规格，在传输侧几乎都有对应的负载 RFC——7.5 节讲 VVC 时会再遇到 RFC 9328 [10]。分层的好处是本体三十年不动：1996 年的初版（RFC 1889）到 2003 年的现行版（RFC 3550），线上包格式一字未改，修订的只是机制描述 [7]——这份稳定性，正是框架化设计的回报。

从学术会议室到每个人的口袋

RFC 3550 的第 2 节用一个经典场景开篇：基于 IP 组播的简单音频会议——几十上百个参与者共享一个组播地址，新成员随时加入、随时离开，没有人维护 "谁在线" 的花名册 [7]。这解释了 RTP 一系列 "反常识" 设计的来由：没有连接概念，会话里的说话人靠 SSRC（同步源标识，32 位随机数）互相辨认；没有入会仪式，听到你的 SSRC 就算认识了你。松散、去中心、对规模友好——这些为学术组播会议而生的特质，日后恰好成了互联网实时通信的通行证。

骨架定了，接下来看它如何落在字节上。下一节我们拆开 RTP 的 12 字节固定头：区区十二个字段，如何同时回答 "这是第几包、属于谁、是什么、该何时播"。