在 WebRTC 的浩瀚协议栈中，如果你问我哪一个协议最"忙碌"，那非 RTP (Real-time Transport Protocol) 莫属。
所有的编码器压缩出来的音视频数据，最终都要打包进 RTP 报文中，才能在复杂的互联网中穿梭。对于应用层开发者来说，WebRTC 似乎把传输细节封装得很完美；但当你面对花屏、卡顿、音画不同步这些棘手问题时，读不懂 RTP 包，你就等于失去了"现场证据"。
今天，我们基于 webrtc.mthli.com 的核心知识体系，深入解构一下 RTP 协议的设计哲学与实战细节。
一、 为什么我们需要 RTP？
可能有同学会问："TCP 太慢，UDP 不可靠，那我们直接用 UDP 传数据不就行了吗？为什么要多套一层 RTP？"
原生 UDP 确实快，但它太"糙"了。它只负责把数据扔出去，不管对方收没收到、顺不顺序、这是第几帧。实时音视频传输（RTC）虽然容忍少量丢包，但必须解决以下问题：
-
时序问题：先发的数据后到怎么办？（乱序）
-
同步问题：声音和画面怎么对齐？（音画同步）
-
流识别：这究竟是视频包还是音频包？是哪个用户的？（多路复用）
RTP 就是为了解决这些问题而生。它通常运行在 UDP 之上，虽然它不保证传输质量（那是 RTCP 的事），但它为接收端提供了重组媒体流所需的所有元信息。
二、 解剖 RTP 报文头：寸土寸金
RTP 的头部设计非常经典，标准长度只有 12 字节，每一个 Bit 都被安排得明明白白。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Contributing Source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+关键字段解析
-
V (Version, 2 bits): 协议版本，WebRTC 中固定为 2。
-
X (Extension, 1 bit) : 非常重要！ 如果置为 1，说明头部后面紧跟一个扩展头。WebRTC 极度依赖这个特性来实现带宽估计、音量显示等高级功能。
-
M (Marker, 1 bit): 标记位。
-
在视频中 ：通常标记一帧图像的最后一个包。接收端收到 M=1 的包，就知道"这一帧凑齐了，可以送去解码了"。
-
在音频中：通常标记一段通话（Talkspurt）的开始。
-
-
PT (Payload Type, 7 bits): 载荷类型。告诉接收端"肚子里装的是什么"。
-
例如：
111代表 Opus 音频，96代表 VP8 视频。 -
注意：在 WebRTC 中，PT 值通常是动态协商的（96-127 范围），不固定。
-
-
Sequence Number (16 bits): 序列号。每发一个包 +1。接收端靠它来发现丢包（Gap）和进行抗抖动处理（Jitter Buffer）。
-
Timestamp (32 bits) : 时间戳。决定了媒体的播放时间。
-
SSRC (32 bits): 同步源标识符。随机生成的 ID，用来区分不同的流（比如麦克风流和屏幕共享流）。
三、 时间戳与序列号：RTP 的心脏
理解 Sequence Number (SN) 和 Timestamp (TS) 的区别，是理解 RTP 的门槛。
-
Sequence Number 是包的计数器。
-
主要用于网络传输层面。
-
视频拆包示例：一张大的 I 帧被拆成了 10 个 UDP 包，这 10 个包的 SN 是连续递增的（如 1001, 1002 ... 1010）。
-
-
Timestamp 是媒体采样时刻。
-
主要用于播放和同步层面。
-
视频拆包示例 ：上述那 10 个包，属于同一帧画面，所以它们的 TS 完全相同！
-
单位：TS 的单位不是毫秒，而是采样点。
-
音频（Opus 48kHz）：每 20ms 发一个包，TS 增加 48000 \\times 0.02 = 960。
-
视频（90kHz 时钟）：每秒 90000 个滴答。
-
-
工程师笔记 ：
假如你抓包发现收到的包 SN 是连续的，但 TS 乱跳，那说明发送端编码器出问题了；
假如 SN 不连续，TS 正常，那说明网络发生了丢包。
四、 Header Extension：WebRTC 的秘密武器
标准的 RTP 头是几十年前定义的，为了适应现代 WebRTC 的需求（如 BWE 带宽估计），我们大量使用了 RTP Header Extension （即头部 X=1 时启用的区域）。
在 SDP 协商中，你经常会看到这样的字段：
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
这意味着 ID 为 3 的扩展头存放的是 abs-send-time。
常见的 WebRTC 扩展包括：
-
Audio Level: 携带音量信息。这样即便不解码音频，SFU 也能知道是谁在说话（绘制光圈）。
-
Absolute Send Time: 绝对发送时间。用于更精准的带宽探测。
-
Transport-wide Sequence Number: 全局序列号。这是现代 WebRTC 抗拥塞控制的核心，配合 Transport-cc 使用。
-
MID / RID: 在一个连接传输多路流（Simulcast/Bundle）时，用来区分流的 ID。
五、 RTCP：RTP 的最佳拍档
RTP 负责闷头干活（发数据），RTCP (RTP Control Protocol) 负责汇报工作（质量反馈）。
WebRTC 中常见的 RTCP 报文：
-
SR (Sender Report) : 发送端发出的。告诉对方"我对应 NTP 时间发了多少包"。这是实现音画同步的关键（将 RTP 时间戳映射到真实墙钟时间）。
-
RR (Receiver Report): 接收端发出的。告诉发送端"我丢包率是多少，RTT 是多少"。
-
NACK: "喂，第 1005 号包丢了，重传一下！"
-
PLI / FIR: "画面碎了/卡死了，请立刻发一个关键帧（Key Frame）给我救急！"
RTP 和 RTCP 就像左手和右手，缺一不可。
六、 总结与实战建议
RTP 协议看似简单，实则包含了实时通信最底层的智慧。在 WebRTC 开发中，理解 RTP 能帮你解决 80% 的疑难杂症。
最后给出几条实战建议：
-
MTU 限制：尽量控制 RTP 包大小在 1200 字节以内，避免 IP 层分片。分片是 UDP 传输的噩梦。
-
动态负载类型：不要硬编码 Payload Type（比如认为 111 就是 Opus），一定要解析 SDP 中的动态映射。
-
安全强制 ：WebRTC 强制使用 SRTP 。你在 Wireshark 里直接抓到的 RTP 内容是加密的乱码，调试时记得配置密钥解密（或者在
chrome://webrtc-internals看解密后的统计）。 -
关注 Marker 位 ：如果你在做流媒体服务器，收到视频包时一定要积攒直到收到
Marker=1的包，再拼装成帧送给解码器，否则会花屏。
希望这篇博客能帮你揭开 RTP 的神秘面纱。