1. RTP协议基础：RTP/RTCP协议栈架构、RTP头部格式详解、RTP Payload类型、RTP会话建立流程
各位同学，咱们今天正式开讲《RTP流媒体性能优化完全指南》的第一章。说实话，RTP这玩意儿我接触了十几年，踩过的坑能写满一个笔记本。但别担心，我会把那些血泪教训都揉碎了讲给你们听。
先问个问题：为什么视频通话偶尔会卡成PPT，但语音却还能听？为什么直播延迟有时能到10秒？这些问题的根子，大多出在RTP协议上。咱们今天就把地基打牢。
1.1 RTP/RTCP协议栈架构
RTP全称是实时传输协议，RTCP是它的控制兄弟。我习惯把RTP比作快递员——他只管把包裹（媒体数据）送到，至于包裹有没有破损、送没送到，那是RTCP的事。
来看这张架构图，我亲手画的，能帮你一眼看清它们的位置：
看到没？RTP和RTCP都跑在UDP之上。为什么不用TCP？因为实时性。你想想看，TCP丢包重传那一套，等包重传完，视频早就卡成马赛克了。
我个人习惯把RTP/RTCP的关系总结成一句话：RTP负责送数据，RTCP负责反馈送得怎么样。RTCP会告诉你丢包率、抖动、往返时延，然后应用层根据这些信息调整码率或编码策略。
核心要点：
- RTP使用偶数UDP端口，RTCP使用下一个奇数端口
- RTCP的带宽通常限制在会话总带宽的5%以内
- RTCP报告周期随会话规模动态调整，避免风暴
1.2 RTP头部格式详解
RTP头部只有12字节的固定部分，但每个字段都有讲究。我当年调试一个视频卡顿问题，查了两天才发现是时间戳字段填错了——发送端和接收端的时钟频率没对齐。
来看这个头部结构，我建议你把它背下来：
这里我重点说几个容易踩坑的字段：
- 序列号（Sequence Number）：初始值是随机的，不是从0开始。我见过有新手写死从0开始，结果接收端把第一个包当乱序包丢了。
- 时间戳（Timestamp）：时钟频率取决于负载类型。音频通常是8000Hz或48000Hz，视频是90000Hz。频率不对，播放速度就全乱了。
- SSRC：每个同步源唯一标识。冲突时RTCP会通知你换一个。
我曾经踩过的坑：有一次线上视频会议，部分用户画面快进。查了两天，发现是时间戳增量计算错了——视频帧率是30fps，但有人把时间戳增量写成了3000（90000/30），而实际应该是3003（90000/29.97）。就差了3个时钟周期，播放器就疯了。
1.3 RTP Payload类型
PT字段（Payload Type）告诉接收端这包数据是什么格式。静态类型（0-95）由IANA分配，动态类型（96-127）由应用通过SDP协商。
我整理了一张常用表，建议收藏：
| PT值 | 编码格式 | 时钟频率（Hz） | 声道数 | 说明 |
|---|---|---|---|---|
| 0 | PCMU（μ-law） | 8000 | 1 | G.711，电话语音标准 |
| 8 | PCMA（A-law） | 8000 | 1 | 欧洲电话标准 |
| 9 | G.722 | 8000 | 1 | 宽带语音，7kHz |
| 10 | L16（立体声） | 44100 | 2 | CD音质线性PCM |
| 96 | H.264 | 90000 | — | 动态类型，最常用视频编码 |
| 97 | H.265 | 90000 | — | HEVC，4K/8K视频 |
| 98 | Opus | 48000 | 可变 | WebRTC首选音频编码 |
| 99 | VP8 | 90000 | — | WebRTC视频编码 |
| 100 | VP9 | 90000 | — | VP8后继，压缩率更高 |
个人建议：动态类型（96-127）的映射一定要在SDP里明确写清楚。我见过两个系统都用PT=96，一个以为是H.264，另一个以为是VP8，结果画面全是雪花。SDP里写一行 a=rtpmap:96 H264/90000 就能避免这种乌龙。
1.4 RTP会话建立流程
一个完整的RTP会话，说白了就是三步：信令协商 → 媒体传输 → 会话终止。信令层（SIP/RTSP/WebRTC的SDP）负责谈好用什么编码、什么端口，然后RTP才开始干活。
我画了个流程图，帮你理清整个建立过程：
实际项目中，我建议你重点关注几个细节：
- SSRC冲突处理：两个发送端用了相同SSRC，RTCP会发BYE包通知你换。我遇到过摄像头和编码器SSRC冲突，画面来回跳。
- 端口绑定：RTP和RTCP端口必须成对。防火墙只开了RTP端口，RTCP过不来，你就收不到质量反馈。
- CNAME：RTCP的规范名（CNAME）用于关联多个流。同一个人的音频和视频流应该用相同CNAME，播放器才能唇音同步。
调试小技巧：抓包时用Wireshark的RTP分析器，它能自动算出丢包率、抖动、序列号乱序情况。我每次排查卡顿问题，第一件事就是看RTP流的统计图——丢包率超过2%就该报警了。
好了，第一章的内容就到这儿。RTP的基础打牢了，后面讲性能优化、抗丢包、FEC、带宽估计这些硬核内容时，你才能跟得上。记住：协议栈的每一层都有它的设计哲学，理解了为什么这么设计，你才能知道怎么优化它。