5.2 RTP与RTCP传输内幕

5.2 RTP 与 RTCP 传输内幕

本节摘要：RTP（Real-time Transport Protocol）是媒体数据的集装箱：给每一包标上序号、时间戳与载荷类型，让不可靠的 UDP 上的音视频流可以被对端检测丢包、对齐播放、挑对解码器。RTCP 则是它的对讲机，把接收质量定期送回来。本节拆解包头关键字段、讲清抖动缓冲的取舍，并动手写一个 RTP 包头解析器——看懂这一节，第 6 章的抗弱网机制对你就不再是黑盒。

学习目标

阅读完本节，你应当能够：

1. 说出 RTP 包头核心字段的作用：版本、载荷类型、序号、时间戳、同步源；
2. 解释序号与时间戳为什么缺一不可：一个管完整性、一个管播放节奏；
3. 描述 RTCP 的两类报文：接收报告（RR）与反馈包（nack、pli、remb）；
4. 解释抖动缓冲的工作方式与延迟代价，理解「卡顿换流畅」的权衡；
5. 手写一个基于 DataView 的 RTP 包头解析函数；
6. 从「声音断续但画面正常」类现象反推是哪路媒体、哪种问题。

一、问题与直觉：UDP 只管发，谁来管「对」

UDP 把包尽力送出去，丢了不补、乱序不管、节奏不问。这对文件传输是灾难，可以交给 TCP；对实时媒体却反而合适——重传一个已经过时的视频帧毫无意义。但「不补救」不等于「不管理」：对端还是需要知道丢了什么、先播哪个、用什么解码。这些管理信息被塞进每个包的固定头部——那就是 RTP。

RTP 的设计哲学是把状态放在包头里、把控制放在伴生协议里。包头轻（通常十二字节），每包都带，承担「这包是什么、第几个、什么时候播」；RTCP 不常发，承担「我收得怎么样」的反馈。两者配合，UDP 上的实时传输才有了秩序。

二、核心原理：包头字段与反馈机制

RTP 包头的关键字段一览：

序号与时间戳的分工最值得咀嚼。序号是包的身份证号码，加一发一：对端靠它发现「中间少了一个」，第 6 章的 nack 重传靠它点名要包。时间戳是内容的拍子：一帧视频的时间戳跨度对应它的展示时长（30 帧率下相邻帧差约 33 毫秒对应的时钟刻度），音频按采样数走。对端把「包到达的时刻」与「内容该播的时刻」对照，就能算出网络抖动，决定缓冲多少。

RTCP 每隔零点几秒到几秒发一次，两样东西最重要。接收报告：丢包率、抖动、往返延迟的统计，是第 6 章带宽估计的原料。反馈包：nack（这个序号的包我没收到，请重发）、pli（我这边解码崩了，请补一个关键帧）、remb（我估算出的可用带宽，请按这个发）。这三样分别对应第 6 章的三件套——重传、关键帧恢复、带宽自适应。

图：从采集到播放的媒体打包与反馈闭环

抖动缓冲是接收端最精巧的部件：包到的时快时慢，播放必须匀速。缓冲区先把早到的包攒一会儿，晚到的包等一会儿，输出端按时间戳匀速取用。缓冲深度的调节就是延迟与流畅的跷跷板：网络越抖需要越深的缓冲，代价是端到端延迟上升。现代实现的缓冲深度是自适应的——平稳网络里收窄到几十毫秒，抖动一来立刻放深。

理解了包头，就可以动手解析。下面这个函数在抓包分析、自研网关、媒体录制工具里都会用到：

// RTP 包头解析：input 为去掉 SRTP 层后的 RTP 包字节流
function parseRtpHeader(buf) {
  const view = new DataView(buf);
  const b0 = view.getUint8(0), b1 = view.getUint8(1);
  const version = b0 >> 6;                       // 应为 2
  const hasPadding = (b0 >> 5) & 1;
  const hasExtensions = (b0 >> 4) & 1;
  const csrcCount = b0 & 0x0f;
  const payloadType = b1 & 0x7f;                 // 最高位是_marker_标志
  const marker = (b1 >> 7) & 1;                  // 视频里常表示一帧的最后一包
  let offset = 12 + csrcCount * 4;               // 固定头 12 字节
  if (hasExtensions) {
    offset += 4 + view.getUint16(offset + 2) * 4; // 跳过扩展段
  }
  return {
    version, payloadType, marker,
    sequenceNumber: view.getUint16(2),
    timestamp: view.getUint32(4),
    ssrc: view.getUint32(8),
    payloadOffset: offset,
  };
}
// 用法：对端进入 onmessage 前抓包得到字节，先解 SRTP 再调本函数
// 打印 sequenceNumber 的缺口即可直观看到丢包位置
​

三、工程实践要点：从现象反推传输问题

把字段语义变成排障语言。「声音断续但画面正常」：音频丢包对耳朵更敏感，先看音频流的接收报告丢包率；若视频流同网络却正常，多半是音频被路由策略挤占或音频包尺寸过大分片丢失。「画面定格几秒后跳变」：典型是解码链断裂后收到关键帧恢复——中间发生了连续丢包或解码错误，pli 生效但关键帧生成耗时，定格时长等于关键帧等待时间。「音画不同步」：时间戳基准问题，多出现在自研网关改写时间戳却没保持音视频时钟对齐的场景。

⚠️ 常见坑：自研服务器转发媒体时改写 SSRC 或序号却不改写对应的 RTCP，反馈就对不上号——nack 要的包对端根本没发过。媒体转发必须把 RTP 与 RTCP 当作一个整体维护。

完整案例：网关转发的「花屏 increasing」

背景：某自研媒体网关把浏览器与会议终端互通，浏览器侧画面偶发花屏，且网络越差花屏越频繁，终端侧却正常。

操作：在网关侧抓包解析 RTP 头（就是本节的解析函数），发现网关为适配终端改写了载荷类型与序号，但浏览器发来的 pli 反馈被原样转给了终端——终端补的关键帧用的是它自己的序号体系，浏览器的 nack 按改写后的序号要包，两边对不上。修复：网关维护双向序号映射，RTCP 反馈按映射翻译后再转发；pli 则在本网关内消化（网关自己有能力生成关键帧请求时直接作用于浏览器侧）。

结果：花屏频率从「每场必现」降到可忽略；该映射模块沉淀为网关的标准组件。

解读：RTP 序号与 SSRC 是「流内坐标系」，RTCP 反馈的每个数字都定义在这个坐标系里。任何介入媒体流的中间设备，都必须承担坐标系转换的完整责任——只改一半，反馈机制就从恢复手段劣化成噪音来源。

变式：如果网关要做录制，本节知识直接可用：解析包头即可按时间戳把 RTP 包还原成可送解码器的帧序列，marker 位标识帧边界，载荷类型区分音视频。很多媒体录制工具的核心其实就是「一边转发一边把解析出的帧落盘」。

本节要点回顾

• RTP 给 UDP 立规矩：序号管完整性、时间戳管节奏、载荷类型管解码、SSRC 管流身份。
• RTCP 是对讲机：接收报告喂带宽估计，nack、pli、remb 三种反馈分别驱动第 6 章的三件套。
• 抖动缓冲是延迟与流畅的跷跷板：自适应深度让它该深则深、该浅则浅，是「卡不卡」的仲裁者。
• 中间设备要维护坐标系：改写序号与 SSRC 的同时必须翻译 RTCP，否则反馈机制失灵。
• 现象可以反推字段：断续、定格、不同步各有对应的字段级病因，排障从包头看起。