1. RTP协议概述：RTP在WebRTC中的角色、RTP与RTCP的区别、RTP协议栈架构
各位好，欢迎来到《WebRTC实战：RTP协议深度解析》的第一章。咱们开门见山，聊聊RTP协议在WebRTC里到底扮演什么角色。
做WebRTC开发，说白了就是在跟实时音视频数据打交道。你采集到的一帧帧画面、一段段音频，最终都要变成网络上的比特流，飞到对方那里。这个过程中，RTP协议就是那个负责“运输”的核心角色。
一句话总结：RTP（Real-time Transport Protocol）是WebRTC实时通信的数据载体，它负责把音视频数据打包、传输、并在接收端还原。
1.1 RTP在WebRTC中的角色
我个人习惯把WebRTC的通信链路比作一条快递流水线。采集设备是发货方，网络是运输通道，播放设备是收货方。而RTP，就是那个贴着运单的包裹。
具体来说，RTP在WebRTC里干了这几件事：
- 数据封装：把编码后的音视频帧切成合适大小的包，加上头部信息（时间戳、序列号、SSRC等）。
- 时序还原：接收端根据RTP时间戳，把乱序到达的包重新排好队，按正确节奏播放。
- 丢包检测：通过序列号，接收端能发现哪些包丢了，然后触发重传或FEC（前向纠错）。
- 多流复用：同一个WebRTC连接里，音频、视频、屏幕共享可以走不同的RTP流，互不干扰。
我记得有一次调试一个视频通话卡顿的问题，抓包一看，RTP时间戳居然跳变不连续。排查了半天，发现是编码器配置的帧率跟RTP发送间隔没对齐。嗯，这种细节，光看文档是学不到的。
小提示：WebRTC中RTP的SSRC（同步源标识符）是随机生成的，但同一个流在整个会话中保持不变。如果你看到SSRC变了，说明对端重新协商了媒体流。
1.2 RTP与RTCP的区别
很多初学者容易把RTP和RTCP搞混。其实它们俩是“搭档”关系——一个干活，一个汇报。
RTP负责运数据，RTCP（RTP Control Protocol）负责传控制信息。你可以这样理解：RTP是快递员，RTCP是快递公司的监控系统。
| 对比维度 | RTP | RTCP |
|---|---|---|
| 主要功能 | 传输音视频数据 | 传输控制与统计信息 |
| 数据方向 | 双向实时流 | 双向周期性报告 |
| 带宽占比 | 通常占95%以上 | 通常不超过5% |
| 可靠性 | 不可靠（UDP承载） | 不可靠，但会重试 |
| 关键字段 | 序列号、时间戳、SSRC | 丢包率、往返时延、抖动 |
| 典型报文 | RTP数据包 | SR（发送方报告）、RR（接收方报告） |
你想想看，如果没有RTCP，发送方根本不知道网络状况怎么样。丢包了？延迟高了？带宽不够了？全靠RTCP报告来感知。我曾经在一个弱网环境下测试，RTCP报告显示丢包率飙升到15%，但RTP流还在拼命发数据。这时候如果不根据RTCP调整码率，视频就会卡成幻灯片。
注意：RTCP的发送间隔是有讲究的。WebRTC默认每5秒发一次复合RTCP包，但实际项目中建议根据场景调整。太频繁浪费带宽，太稀疏又无法及时感知网络变化。
1.3 RTP协议栈架构
聊完角色和区别，咱们看看RTP在协议栈里到底处在什么位置。我画了一张图，帮你快速建立整体认知。
从上往下看，应用层产生的音视频数据，经过SDP协商、ICE连接建立、DTLS握手加密，最终交给RTP层打包。RTP包再往下走，通过UDP发送到对端。
这里有个关键点：RTP本身不保证可靠传输。它依赖UDP，丢包了不会自动重传。那怎么办？WebRTC在RTP之上做了很多补偿机制，比如NACK（否定确认重传）、FEC（前向纠错）、码率自适应等。这些我们后面章节会逐一拆解。
另外，RTP头部虽然只有12字节的固定部分，但扩展头（Header Extension）在WebRTC里用得很多。比如用于拥塞控制的Transport-wide CC扩展、用于绝对时间同步的绝对发送时间扩展。这些扩展头，说白了就是给RTP包“加料”，让接收方能做更精细的控制。
核心要点：RTP协议栈的每一层都有明确分工。应用层只管产生数据，RTP层只管打包和时序，传输层只管收发。这种分层设计，让WebRTC的媒体传输既灵活又高效。
1.4 一个简单的RTP包结构
光说不练假把式。咱们看看RTP包长什么样。下面是一个典型的RTP头部结构：
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（版本）：固定为2，当前RTP版本。
- P（填充）：如果为1，包尾有填充字节。
- X（扩展）：如果为1，头部后面跟着扩展头。
- CC（CSRC计数）：表示后面有多少个CSRC标识符。
- M（标记）：用于标记帧边界，比如视频帧的最后一包。
- PT（负载类型）：标识编码格式，比如H264、Opus。
- 序列号：每个RTP包递增，用于检测丢包和排序。
- 时间戳：采样时刻，用于播放同步。
- SSRC：同步源标识，唯一标识一个RTP流。
我曾经在调试一个多路混音的场景时，发现音频不同步。抓包一看，两个音频流的SSRC居然冲突了。嗯，这种问题在单对单通信中很少见，但到了多人会议里，SSRC管理就成了必修课。
实战建议：如果你用Wireshark抓RTP包，可以设置过滤条件 rtp，然后查看每个包的序列号和时间戳是否连续。这是排查音视频卡顿的第一步。
1.5 本章小结
这一章我们聊了RTP在WebRTC中的核心角色——它是音视频数据的运输载体。RTP和RTCP的区别也很清楚：一个运货，一个汇报。最后我们看了RTP在协议栈中的位置，以及它的头部结构。
说白了，RTP就是WebRTC的“血管”。血管堵了，整个系统就瘫痪。后面的章节，我们会深入每个细节：时间戳怎么算？序列号怎么管理？扩展头怎么用？NACK和FEC怎么配合？