1. RTP协议概述：RTP/RTCP协议族介绍、RTP在流媒体中的位置、RTP与UDP的关系
各位同学，咱们今天正式开讲《RTP协议原理解析与音画同步》的第一章。说实话，RTP这个协议我接触了十几年，从最早做IP电话网关，到后来搞视频直播平台，几乎每天都在跟它打交道。你想想看，如果没有RTP，咱们现在刷抖音、看视频会议、打网络电话，全都得卡壳。
这一章咱们先把地基打牢。我会从三个角度切入：RTP/RTCP这对兄弟协议到底是个什么关系、RTP在整个流媒体链条里站在哪个位置、以及它为什么偏偏要骑在UDP这匹野马身上。嗯，咱们开始吧。
1.1 RTP/RTCP协议族：一对形影不离的搭档
RTP的全称是Real-time Transport Protocol，实时传输协议。它的兄弟RTCP，全称RTP Control Protocol，实时传输控制协议。这两个协议从来都是一起出现的，就像咱们做项目时的开发和测试——一个负责干活，一个负责盯着干活的质量。
RTP负责什么？说白了，就是把你采集到的音频数据、视频数据，打包成一个个小包，然后扔到网络里去。它不保证一定能送到，也不保证顺序不乱，但它保证一件事：实时性。我当年做第一个流媒体项目时，老板问我：“为什么不用TCP？TCP不是更可靠吗？”我跟他说，TCP重传一次，视频里那个人嘴都动完了声音才到，这谁受得了？
RTCP负责什么？它不传音视频数据，它传的是控制信息。比如：
- 这轮通话丢了多少包？
- 网络延迟有多大？
- 接收端缓冲区够不够用？
- 发送端该不该降码率？
我习惯把RTP比作快递员，RTCP就是快递公司后台那个监控系统。快递员只管送，监控系统告诉你“今天丢件率3%，建议加派人手”。
核心要点：RTP和RTCP共用同一个传输层端口号（RTP用偶数，RTCP用下一个奇数）。比如RTP用端口5004，RTCP就用5005。这个约定在RFC 3550里写得明明白白，千万别搞混。
咱们用一张图来直观看看这对兄弟的关系：
1.2 RTP在流媒体中的位置：承上启下的枢纽
咱们做流媒体，整个链条大概是这样的：
- 采集：摄像头、麦克风拿到原始音视频信号
- 编码：用H.264、AAC等压缩成码流
- 封装：把编码后的数据打包成RTP包
- 传输：通过UDP/IP网络发出去
- 接收：对端收到RTP包，解封装
- 解码：还原成音视频帧
- 渲染：显示在屏幕上、从喇叭放出来
RTP就站在第3和第4步之间。它不关心你的视频是用什么编码器压的，也不关心你的网络是WiFi还是5G。它只做一件事：把数据切成合适大小的包，加上时间戳和序号，然后交给UDP去发。
个人经验：我曾经在一个项目中遇到一个问题——编码器输出的H.264 NALU太大，超过了以太网MTU（1500字节）。如果不做RTP分片，一个包发出去就会被IP层拆成两个，接收端重组时很容易丢包。后来我按照RFC 3984的FU-A分片方案，在RTP层就把大NALU切成多个小包，每个包带一个分片偏移。从那以后，丢包率从5%降到了0.5%。
你想想看，如果没有RTP这一层，编码器直接往UDP里塞数据，接收端根本不知道哪个包是哪一帧的、该什么时候播放。RTP的时间戳和序号，就是给这些数据包贴上了“身份标签”。
1.3 RTP与UDP的关系：为什么非UDP不可？
这个问题我面试过很多人，十个有八个答不上来。他们知道RTP用UDP，但不知道为什么。
咱们先看一张对比表：
| 特性 | TCP | UDP | RTP的选择 |
|---|---|---|---|
| 可靠性 | 保证送达，自动重传 | 不保证送达 | UDP（实时优先） |
| 顺序性 | 保证有序 | 不保证有序 | UDP（RTP自带序号） |
| 延迟 | 高（重传导致） | 低 | UDP（低延迟优先） |
| 拥塞控制 | 有（慢启动、拥塞避免） | 无 | UDP（RTCP做拥塞控制） |
| 组播支持 | 不支持 | 支持 | UDP（组播场景必需） |
核心原因就一个：实时性。TCP为了保证数据不丢，会做重传。但重传意味着延迟。你想想看，视频通话里如果丢了一个包，TCP会停下来等重传，那画面就卡住了。而UDP丢了就丢了，RTP通过RTCP报告丢包率，发送端可以适当降低码率或者做前向纠错（FEC），但不会停下来等。
我记得有一次做跨国视频会议系统，客户坚持要用TCP，说“UDP不可靠”。结果测试时，跨太平洋链路延迟本来就高，再加上TCP的重传，画面延迟到了3秒以上。后来我改成UDP+RTP+FEC的方案，延迟降到了300毫秒以内。客户当场就服了。
避坑指南：UDP虽然延迟低，但它没有拥塞控制。如果发送端不管网络状况拼命发数据，很容易导致网络拥塞，甚至影响其他用户。我曾经在一个项目中遇到过——某个推流端码率设置过高，直接把公司内网打爆了，连隔壁部门的网页都打不开。后来我们在RTCP里加了带宽估计，动态调整发送码率，才解决了这个问题。
所以，RTP选择UDP，不是因为它完美，而是因为它在实时性这个维度上，是唯一的选择。RTP自己补上了UDP缺失的序号和时间戳功能，RTCP又补上了拥塞控制和质量监控。这三者配合起来，才构成了一个完整的实时传输方案。
1.4 本章小结
咱们这一章把RTP的底子打好了。记住三个关键点：
- RTP传数据，RTCP传控制，两者缺一不可
- RTP是流媒体链条里的封装和传输枢纽，不关心编码细节，只关心打包和定时
- RTP骑在UDP身上，因为实时性压倒一切，缺失的可靠性由RTP/RTCP自己补