RTP 实时传输协议

2025年12月21日

前言

在音视频传输领域，RTP（Real-time Transport Protocol）是一个绕不开的核心协议。无论是 WebRTC、RTSP 还是 SIP，底层都依赖 RTP 来传输媒体数据。本文将从协议设计、实际应用和性能优化三个维度，深入解析 RTP 的工作原理和最佳实践。

概述

实时传输协议（Real-time Transport Protocol, RTP）是一种用于处理互联网实时流量（如音频和视频）的协议。RTP 必须与 UDP 协议配合使用，不包含多播或端口号等传输机制。RTP 支持多种文件格式，例如 MPEG 和 MJPEG。它对数据包延迟高度敏感，但对数据包丢失的容忍度较高。

为什么选择 UDP 而不是 TCP？

这是我在学习 RTP 时第一个疑问。答案是：实时性优先于可靠性。

  • TCP 的问题：丢包会触发重传，导致延迟累积，对于实时视频来说，过时的数据包比丢失更糟糕
  • UDP 的优势：不保证顺序和可靠性，但延迟低、开销小，适合实时流媒体
  • RTP 的补偿：通过序列号检测丢包，通过时间戳同步，上层应用可以处理丢包（如插帧、降码率）

历史

RTP 由互联网工程任务组（IETF）开发，核心团队包括以下四名成员：

  • S. Casner（包装设计）
  • V. Jacobson（包装设计）
  • H. Schulzrinne（哥伦比亚大学）
  • R. Frederick（Blue Coat Systems Inc.）

RTP 首次于 1996 年以 RFC 1889 的形式发布，随后在 2003 年更新为 RFC 3550。

应用场景

RTP 主要用于以下场景：

  • 媒体混合、排序和时间戳：帮助处理实时数据的顺序和同步。
  • 互联网协议语音（VoIP）：支持实时语音通信。
  • 视频电话会议：通过互联网进行视频通话。
  • 互联网音频和视频流：支持流媒体传输。

实际应用中的思考

在我实现的 P2P 视频直播方案中，RTP 扮演了关键角色：

  1. H.264 NALU 封装：将编码后的 NALU 单元封装成 RTP 包，每个包包含序列号和时间戳
  2. 丢包处理：接收端通过序列号检测丢包，对于关键帧（IDR）丢失，需要请求重传或等待下一个 IDR
  3. 时间戳同步：音频和视频使用不同的 RTP 流，通过 RTCP 的 SR（Sender Report）包同步时间戳，实现音画同步

经验总结：RTP 本身不保证可靠性，但通过合理的上层设计（如 FEC、重传策略），可以在实时性和可靠性之间找到平衡。

RTP 报头格式

![协议头][1]

RTP 数据包的报头格式简洁，适用于所有实时应用。以下是报头中各字段的说明：

  • 版本（Version）：2 位，定义协议版本号，当前版本为 2。
  • 填充（P）：1 位，值为 1 表示数据包末尾有填充，值为 0 表示无填充。
  • 扩展（X）：1 位，值为 1 表示在数据和基本报头之间存在扩展报头，值为 0 表示无扩展报头。
  • 贡献者数量（CC）：4 位，表示贡献者数量，最大值为 15（由 4 位字段限制，范围为 0 到 15）。
  • 标记（M）：1 位，应用程序使用此字段作为数据结束的标记。
  • 有效载荷类型（Payload Type）：7 位，指示有效载荷的类型，用于区分不同的数据格式（如音频、视频等）。
  • 序列号（Sequence Number）：16 位，为每个 RTP 数据包分配序列号，用于排序和检测数据包丢失或顺序错误。首个数据包的序列号为随机值，后续数据包序列号依次加 1。
  • 时间戳（Timestamp）：32 位，用于表示不同 RTP 数据包之间的时间关系。首个数据包的时间戳为随机值，后续数据包的时间戳为前一时间戳加上生成当前数据包第一个字节所用的时间之和。时间戳的时钟周期因应用程序而异。
  • 同步源标识符（SSRC）：32 位，标识数据包的源，由源随机生成，用于解决多个源使用相同序列号的冲突。
  • 贡献者标识符（CSRC）：32 位，用于在会话中存在多个源时标识贡献者。混音器源使用 SSRC，其余源（最多 15 个）使用 CSRC。

RTP 协议头格式

深入理解：序列号和时间戳

序列号（Sequence Number）

序列号是 16 位无符号整数，范围 0-65535。关键点：

  • 初始值随机：防止重放攻击，也避免不同会话的包混淆
  • 循环使用：65535 后会回到 0，需要上层处理回绕
  • 丢包检测：接收端通过序列号间隔判断丢包数量

实际应用：在我的实现中，序列号用于统计丢包率，当丢包率超过阈值（如 5%）时，主动降低码率。

时间戳（Timestamp）

时间戳是 32 位无符号整数，表示采样时刻。关键点：

  • 时钟频率：音频通常 8000Hz（每 125μs 增 1），视频通常 90000Hz（每 11.1μs 增 1）
  • 初始值随机：同样是为了安全性
  • 相对时间：时间戳的差值表示时间间隔，而不是绝对时间

音画同步：通过 RTCP SR 包中的 NTP 时间戳和 RTP 时间戳的映射关系，可以实现跨流的同步。

RTCP：RTP 的控制协议

RTP 通常与 RTCP（RTP Control Protocol）配合使用，RTCP 提供：

  • SR（Sender Report）：发送端报告，包含发送统计和 NTP 时间戳
  • RR（Receiver Report）：接收端报告，包含丢包率、延迟抖动等
  • BYE：会话结束通知
  • APP：应用特定数据

实际价值：RTCP 报告帮助上层应用进行自适应码率控制（ABR），根据网络状况动态调整编码参数。

性能优化实践

1. 包大小优化

  • 太小：头部开销占比高（12 字节固定头），效率低
  • 太大：UDP 包超过 MTU（通常 1500 字节）会分片，增加丢包风险
  • 最佳实践：RTP 包大小控制在 1200-1400 字节，平衡效率和可靠性

2. 时间戳精度

  • 使用 90kHz 时钟（视频）可以获得 11.1μs 的时间精度
  • 对于 30fps 视频，每帧间隔约 3000 个时钟单位
  • 时间戳增量 = 采样率 / 帧率

3. 序列号回绕处理

# 伪代码：处理序列号回绕
def is_sequence_newer(s1, s2):
    # 考虑 16 位回绕
    diff = (s1 - s2) & 0xFFFF
    return diff < 32768  # 小于一半范围认为是新的

总结

RTP 作为实时传输的基础协议，设计简洁但功能强大。理解其工作原理对于开发音视频应用至关重要：

  1. 协议层面：理解序列号、时间戳、SSRC 的作用
  2. 应用层面：合理封装媒体数据，处理丢包和同步
  3. 优化层面：根据网络状况调整包大小和码率

在实际项目中，RTP 往往与 RTCP、SDP、ICE 等协议配合使用，共同构建完整的实时通信系统。希望这篇文章能帮助大家更好地理解和使用 RTP。

更新时间：2025年12月24日