1. RTP协议概述：RTP/RTCP协议族介绍、RTP在流媒体中的位置、RTP与UDP的关系
各位同学好，我是老周。今天咱们正式开讲RTP协议。说实话，我做了十几年流媒体，跟RTP打了无数交道。每次带新人，我都会先问一个问题：你觉得视频通话里，数据是怎么从A端跑到B端的？很多人第一反应是TCP，但实际跑起来，你会发现完全不是那么回事。
嗯，咱们今天就把RTP协议这层窗户纸捅破。我会从协议族构成、它在流媒体体系里的定位，以及它为什么非要跟UDP绑在一起这三个角度来讲。别急，慢慢来。
1.1 RTP/RTCP协议族：一对孪生兄弟
RTP的全称是Real-time Transport Protocol，实时传输协议。但注意，它从来不是单打独斗的。标准里定义的是RTP/RTCP协议族，RTCP是RTP Control Protocol，实时传输控制协议。说白了，一个负责运数据，一个负责反馈质量。
我习惯把RTP比作快递员，RTCP就是快递公司的客服系统。快递员只管把包裹送到，客服系统告诉你包裹到哪了、有没有丢件、要不要重新派送。两者缺一不可。
核心要点：RTP负责媒体数据的实时传输，RTCP负责传输质量的监控与反馈。两者配合，才能构建一个可用的实时通信系统。
具体来说，RTP干了这些事：
- 时间戳：每个RTP包都带一个时间戳，接收端靠它来还原播放时序
- 序列号：用来检测丢包和排序，防止乱序导致画面错乱
- 负载类型标识：告诉接收端，这包数据是H.264还是AAC，还是别的什么
- SSRC标识：同步源标识，区分不同的媒体流
而RTCP呢，它主要做这几件事：
- 发送报告/接收报告：统计丢包率、抖动、往返时延
- 源描述：告诉对方你是谁，用的什么编码器
- 应用特定控制：比如视频会议里的画面切换指令
个人经验：我在做某款视频会议产品时，发现用户反馈画面经常卡住不动。查了半天，发现是RTCP报告周期设得太长，接收端一直没收到丢包反馈，也就没触发重传。后来我把RTCP间隔从5秒调到1秒，问题立刻解决了。所以RTCP的配置，真不是随便填个数字就行的。
1.2 RTP在流媒体中的位置：承上启下的枢纽
你想想看，一个完整的流媒体系统，从采集到播放，中间要经过多少层？我画个图你就明白了。
看到了吧？RTP不是最底层的，也不是最上层的。它夹在中间，像个翻译官——把上层应用产生的媒体数据，翻译成下层网络能理解的数据包格式。上层应用不用管网络细节，下层网络也不用管媒体格式，RTP就是那个桥梁。
举个例子，你用WebRTC做视频通话，流程是这样的：
- 摄像头采集视频帧
- 编码器压缩成H.264码流
- RTP把码流切片打包，加上时间戳和序列号
- UDP把RTP包发出去
- 对端收到后，RTP层根据时间戳排序，交给解码器
- 解码器还原成视频帧，渲染到屏幕上
你看，RTP就是第3步和第5步的主角。没有它，编码器和网络之间就是鸡同鸭讲。
1.3 RTP与UDP的关系：天生一对
这个问题我经常被问到：为什么RTP不用TCP，非要用UDP？
说白了，实时性要求决定的。你想想看，视频通话里，一帧画面晚到了200毫秒，用户就觉得卡了。如果这帧丢了，TCP会重传，但重传回来的数据已经过时了——画面早就该播下一帧了。重传回来的数据，反而成了累赘。
UDP就不一样了。它不保证送达，不保证顺序，但速度快、开销小。RTP正是利用了UDP的这些特性：
| 特性 | TCP | UDP | RTP的选择 |
|---|---|---|---|
| 可靠性 | 保证送达，自动重传 | 不保证送达 | UDP + 应用层选择性重传 |
| 有序性 | 保证顺序 | 不保证顺序 | UDP + RTP序列号排序 |
| 时延 | 高（重传导致） | 低 | UDP低时延 |
| 头部开销 | 20字节 | 8字节 | UDP + RTP 12字节 = 20字节 |
| 拥塞控制 | 内置 | 无 | 应用层实现（如GCC） |
注意：RTP虽然跑在UDP上，但并不意味着它完全放弃可靠性。RTP通过序列号检测丢包，RTCP报告丢包率，应用层可以决定是否重传。这叫「选择性可靠」，不是全盘可靠，也不是全盘不可靠。我曾经在一个项目中，把RTP直接跑在TCP上，结果延迟飙到500ms以上，用户直接骂娘。后来切回UDP，延迟降到100ms以内，问题解决。
另外，RTP的端口号也有讲究。RTP使用偶数端口，对应的RTCP使用下一个奇数端口。比如RTP用5004，RTCP就用5005。这是RFC 3550规定的，别搞反了。
避坑指南：我曾经在配置防火墙时，只开了RTP的端口，忘了开RTCP的端口。结果媒体流能通，但接收端一直收不到质量反馈，导致自适应码率算法失效，画面质量忽高忽低。所以配置防火墙时，一定要把RTP和RTCP的端口对都放开。
1.4 小结：RTP到底解决了什么问题？
咱们总结一下。RTP协议的核心价值，就是解决了实时媒体传输中的三个关键问题：
- 时序问题：通过时间戳，让接收端知道什么时候该播哪一帧
- 丢包检测：通过序列号，让接收端知道哪些包丢了
- 媒体类型识别：通过负载类型，让接收端知道怎么解码
而RTCP则解决了「我怎么知道传输质量好不好」的问题。两者配合，再加上UDP的低时延特性，构成了实时通信的基石。