6.1 RTP 与 RTCP 协议实现

6.1 RTP 与 RTCP 协议实现

传输栈从打包层讲起。实时传输协议本身极其简单——一个带序号与时戳的轻量信封——真正的智慧全在打包策略与伴随它的反馈机制上。本节的目标很具体：读完你能徒手解开一个媒体包，并说清每个字段为什么存在。

包头十二字节，字段各司其职

媒体包的固定头部只有十二字节，布局如下。

图：RTP 固定头部的字节布局

三个字段的职责必须刻进脑子。序号每包加一、到顶环回，接收方靠它发现丢了什么——序号断档就是丢包，缺口大小就是丢失数量，重传请求与冗余恢复都以它为索引。时戳走的是采样时钟而非墙上时钟：音频按采样数走，视频按九万赫兹时钟走，同帧分片共享同一时戳——接收方靠它把分片归到同帧、把帧排到正确的播放节奏，跨流同步（音画对齐）也建立在它之上。同步源标识是流的数字身份，一条连接上音频、视频、共享、重传各持不同的身份号，复用同一线路时全靠它分流。

打包策略值得一提：编码帧通常大于网络包，必须切片。切片的颗粒度是工程权衡——片越小，丢一包的损失越小，但头部开销越大。引擎按路径最大传输单元探测动态决定片长，把每个包控制在探测上限内，这是"尽量别在 IP 层被二次分片"的务实选择。

反馈报文：控制面的轻声细语

与媒体相伴的反馈报文走另一族格式。最基础的是接收质量报告：按流汇报收到的最高序号、累计丢失、抖动估计与最近一次发送侧报告的往返时间。丢包清单报告则更精细，把缺失的序号区间逐条列出，接收方的重传请求由此生成。传输层反馈是较新的成员：它把每个包的到达时刻逐包回传，为第七章的精细带宽估计提供原料——正是它取代了旧的粗粒度带宽提示，让端侧拥塞控制从"凭感觉"升级为"有曲线"。

引擎对反馈的收发实现有一条值得注意的纪律：反馈报文合并成复合包周期发送，单报文有最小间隔，避免在高流数场景下反馈流量失控。排错时如果发现反馈迟迟不到，先看间隔配置与流量占比，再怀疑网络——反馈被自己挤掉是真实存在的故障形态。

扩展头：传输层的记事贴

固定头之外，扩展头是现代传输机制的挂载点，也是本书多个章节的伏笔所在。引擎按协商结果挂载的常用扩展包括：媒体段标识（复用时区分流归属）、绝对发送时刻（跨时钟域的延迟测量）、传输层拥塞序号（逐包反馈的索引）、音频电平（收端快速判静默）、画面旋转标记（渲染侧免转像素）。每个扩展占用几个字节，协商阶段双方用统一资源名对齐"哪个扩展用哪个编号"，上线后的报文里只出现编号。

扩展头对排错的价值怎么强调都不过分：它让加密后的报文仍可读出传输层语义。7.1 的逐包延迟测量依赖绝对发送时刻扩展，7.2 的重传与 7.3 的分配都依赖拥塞序号扩展——这些机制的原料全部在扩展头里。因此裁剪定制版引擎时，误删扩展支持是最危险的"优化"：省下每包几个字节，换来整套 QoS 闭环失明。

反馈节奏与综合排错视图

反馈报文的发送节奏由引擎自动调节，机制上按带宽的一定比例预留反馈额度，间隔随流数与带宽动态伸缩。这个设计的推论值得记住：反馈密度本身是一个诊断信号——带宽充裕时反馈细密，带宽枯竭时反馈稀疏，反馈迟迟不至往往先于媒体劣化出现。把反馈包的速率也纳入监控，等于给传输层加了一面后视镜。

把本节的字段知识组合起来，可以形成一张"抓包综合视图"的读法：先按同步源标识分流，再按时戳聚类成帧，然后看序号连续性找丢包、看分片标记看打包效率、看扩展头确认机制挂载是否齐全。一套流程走完，绝大多数传输层的疑点都会自己浮出来。熟练之后，这套视图的阅读速度可以做到接近实时——这也是传输层排错工程师的核心竞争力：不是记得住协议，而是看得快报文。

接收报告里的数字怎么读

把最常用的接收报告字段与读法收拢成一段，监控与抓包都能用上。累计丢失计数是"缺了几个"的总账，适合看趋势不适合看瞬时；抖动估计是到达间隔波动的平滑值，它的抬升几乎总是先于丢包出现——是线路劣化的前哨指标；最高序号与扩展序号一起构成"收到哪了"的基准，重传请求与丢包统计都以它为参照；往返时间由报告对（我上次发报告的时刻被你带回来）计算，它的健康度决定 7.2 重传武器的价值。这套读法的要点是组合判读：抖动抬升加丢包为零，是排队在涨；抖动平稳加丢包陡增，是链路层硬丢——两种形态的处置方向完全不同，前者压速率，后者查设备。

加密之后抓包还能看到哪些字段

安全层只加密载荷，固定头部与部分扩展头保持明文，因此序号、时戳、源标识、媒体段标识在密文里依然可读。这让加密会话的丢包定位、流归属、时序分析照常进行——这是协议设计对可运维性的自觉保留，也是第 6.2 节"加密不影响排错"的具体落点。

案例：徒手解开一个媒体包

背景。内训作业给出一小段加密前的抓包片段，要求在不借助任何工具的情况下读出：属于哪条流、是什么内容、丢了多大范围。

操作。逐字节对照头部布局读。首字节高位为十、版本号为二、无填充无扩展、贡献源数为零；第二字节的打包标识与协商的载荷表对上，是某视频编码；序号两字节读出为某个值，与同流相邻包比较；时戳四字节与前一包相同——同帧分片；同步源标识与会话描述里登记的视频流身份一致。再看首包分片标记，本包为某帧的第一片。

结果。读出的结论：这是视频流某帧的首个分片，时戳与上一帧差出标准间隔，说明帧序连续；假设下一包序号跳三，则中段缺两片，画面该帧无法重组，接收方将生成一条覆盖两个序号的丢包请求。

解读。这个练习的价值不在读包本身，而在建立"报文—机制"的映射直觉：看到时戳相同就知道是同帧分片，看到序号缺口就想到重传请求，看到源标识就想到多流分流。抓包排错时，这层直觉让你在成千上万个包里第一眼看到异常，而不是逐个翻。

变式。把练习换成加密后的抓包：载荷变成密文、头部仍部分可见——安全层只加密载荷不加密头（下一节展开）。此时能读的信息少了大半，但序号、时戳、源标识仍在，丢包统计与流归属照样可做——这就是为什么加密不影响传输层排错的关键设计。

要点回顾

本节要点：固定头部十二字节，序号、时戳、源标识三字段撑起丢包检测、播放同步、流归属三大机制；切片颗粒度随路径探测动态调整；反馈报文按周期合并发送，传输层反馈是精细带宽估计的原料；加密不遮头部，排错能力在加密后依然保留。下一节看信封上锁的全过程：握手、验身份、导密钥。