11、RTP与RTCP：RTP协议基础与WebRTC中的实现

聊到WebRTC的传输层，RTP和RTCP是绕不开的两个核心协议。我刚开始接触WebRTC时，总觉得RTP不就是个封装音视频数据的协议吗？后来踩了不少坑才明白，RTP的设计远比我想象的精巧，而RTCP更是整个传输质量保障的"幕后英雄"。

说白了，RTP负责把音视频数据从A点搬到B点，而RTCP负责告诉你"搬得怎么样"。两者配合，才能实现流畅的实时通信。

RTP协议基础

RTP（Real-time Transport Protocol）是实时传输协议。它不像TCP那样可靠，但胜在低延迟。你想想看，视频通话如果等丢包重传，画面早就卡成PPT了。

RTP头部有12个字节的固定部分，其中三个字段最关键：

• 载荷类型（Payload Type, PT）：标识媒体编码格式。比如PT=96通常表示H.264视频，PT=0表示PCMU音频。WebRTC中常用动态PT值（96-127）。
• 序列号（Sequence Number）：16位递增计数器。接收端用它检测丢包和排序。我遇到过一个问题：序列号溢出后从0重新开始，如果没处理好，接收端会误判为乱序包。
• 时间戳（Timestamp）：32位值，表示媒体采样时刻。音频和视频的时间戳时钟频率不同，音频通常是8kHz或48kHz，视频是90kHz。

RTP头部结构可以用一张图来理解：

RTCP的作用

RTCP（RTP Control Protocol）是RTP的控制协议。它不传媒体数据，而是传控制信息。我习惯把RTCP比作"体检报告"——定期检查传输链路的状态。

RTCP有几种重要的报文类型：

RR报告中的几个关键指标：

• 丢包率（Fraction Lost）：最近一个周期内的丢包比例。WebRTC的拥塞控制算法会据此调整发送码率。
• 累计丢包数（Cumulative Lost）：从会话开始到现在的总丢包数。
• 到达间隔抖动（Interarrival Jitter）：RTP包到达时间的统计方差。抖动大说明网络不稳定。
• 最后SR时间戳（LSR）：最近一次收到SR的时间，用于计算RTT。

WebRTC中的RTP/RTCP实现

WebRTC对RTP/RTCP做了一些扩展和定制。我参与过一个WebRTC的P2P视频项目，当时需要深入理解这些实现细节才能调优。

WebRTC中RTP的实现特点：

• RTP头部扩展：WebRTC定义了（音频级别指示）和（传输序列号）等扩展头。这些扩展用于音频能量检测和带宽估计。
• RED（冗余编码）：WebRTC支持RED载荷格式，可以把多个RTP包封装到一个包中。说白了就是"鸡蛋不放在一个篮子里"。
• FEC（前向纠错）：WebRTC实现了FlexFEC（RFC 8627），通过发送冗余数据包来对抗丢包。我建议在丢包率超过5%的网络环境中启用FEC。

// WebRTC中NACK的典型流程
// 接收端检测到序列号gap
// 发送RTCP NACK报文
// 发送端收到后重传对应RTP包

// NACK报文格式（简化）
struct NackPacket {
    uint32_t ssrc;          // 发送端SSRC
    uint16_t pid;           // 丢失包的起始序列号
    uint16_t blp;           // 位掩码，标识后续丢失的包
};