深入浅出WebRTC—Pacer

平滑发包（Pacer）是 WebRTC 实现高质量实时通信不可或缺的一部分。在视频通信中，单帧视频可能包含大量的数据，如果未经控制地立即发送，可能瞬间对网络造成巨大压力。Pacer 能够根据网络条件动态调整发送速率，确保数据包以均匀且可控的速度发送，避免突发的大批量数据造成网络拥塞和数据包丢失。这样可以提升传输的稳定性，减少延迟和抖动，从而改善视频和音频的流畅度与质量。

1. 总体架构

1.1. 静态结构

1）TaskQueuePacedSender

TaskQueuePacedSender 是 PacingController 的包装器，其大部分接口直接透传到 PacingController。同时，TaskQueuePacedSender 是平滑发包的驱动器，内部使用 TaskQueue 驱动不断循环发包。

2）PacingController

PacingController 是平滑发包的控制器，用来实现指定速率的平滑发包，包含较复杂的控制逻辑，其内部使用 PrioritizedPacketQueue 缓存待发送报文。

3）BitRateProber

BitRateProber 和带宽探测相关。其接受带宽探测任务，使用平滑发包机制，按照带宽探测任务要求，控制带宽探测发包速率、发包时长、发包数量等参数。

1.2. 调用流程

下图展示的是一个典型的发包调用流程，包含一长两短三条路径，这三条路径配合实现平滑发包和带宽探测功能。

1）长路径是由 TaskQueueBase 驱动将报文插入发送队列，然后调用 NextSendTime 和 ProcessPackets 发送到期该发送的报文，然后创建一个调度任务 Post 到 TaskQueueBase 驱动循环报文发送。

2）其中一条短路径，是外部模块调用 EnqueuePackets 发送报文，TaskQueuePacedSender 将其封装成一个任务，调用 PostTask 转换到内部线程执行。

3）另外一条短路径，是外部模块调用 CreateProbeCluster 向 BitrateProber 创建带宽探测任务。

1.3. 逻辑架构

下图展示的是平滑发包逻辑架构。

1）平滑发包以 TaskQueue 进行驱动，它接受 Controller 和 BitrateProber 的控制，从 packet_queue_ 抓取报文经 PacketSender 发送到网络。

2）Controller 主要控制发包时间和发包数量，即什么时候发包以及发多少包，其控制逻辑受多个方面影响，比如外部设置的发包间隔、平滑发送码率、网络缓冲区状态、发包队列长度以及平均排队时长等。

3）BitrateProber 接受创建的带宽探测任务，它可以控制 TaskQueue 优先发送探测报文，来实现带宽探测功能。探测报文可以是媒体报文，也可以是 Padding 报文，Padding 报文需要调用 PacketSender 接口生成。

WebRTC 平滑发包是一个典型的“发送-等待”模型，如下图所示。基本逻辑是，将发送时间切分成一段一段的时间片（时间片长度不一定相等），在每个时间片的开始按照指定码率发送一定数量的报文，等待网络管道排空，然后继续下一轮发送，循环往复。这样做可以尽量保持比较均匀的发送码率，不会对网络造成冲击，同时，可以获得尽可能低延迟。

以上发包模型最关键的是计算每个时间片发送多少数据。最简单的思路就是使用固定时间片长度，发送固定数量的报文。WebRTC 最新代码已经没有使用固定周期发包模式了，采用的是动态发包周期，原因可能是固定发包周期无法满足不同发包要求：

1）带宽探测需要使用更小的发送时间间隔，以实现更准确的带宽探测。

2）高优先级报文需要立即发送，不能等待平滑发送时间片。

3）如果平滑发送速率太大，要适当调低发送时间间隔，否则有可能导致网络缓冲区溢出。

4）没有报文发送的时候，发送 keep-alive 的时间间隔不需要像发送媒体报文那么小。

动态周期发包模式引入 media_debt_ 变量来控制发包节奏，如下图所示。media_debt_ 可以认为是存在于网络缓冲区中的报文数量的一个计算值而非测量值。每次发送报文都会增加 media_debt_，增加的大小等于发送报文的大小；每经过一段时间，都会减少 media_debt_，减少的大小等于adjusted_media_rate * delta_t。当 media_debt_ 为0时，认为网络管道已经排空。

1.4. 报文类型

平滑发包会发送三类报文，分别是媒体报文、保活（keep-alive）报文和探测报文。如果基于Payload Type划分，可以分为 Audio、Video、RTX、FEC、Padding 五种类型的报文。

Keep-alive 报文属于 Padding 报文；探测报文可能是 Padding 报文，也可能是 RTX 报文。Audio、Video、RTX、FEC 都属于媒体报文。

2. TaskQueuePacedSender

2.1. 静态结构

2.1.1. 重要属性

1）pacing_controller_

执行具体平滑发包控制，包括什么时候发包，发多少包。

2）task_queue_

单线程驱动 pacing_controller_ 循环发包。

3）packet_size_

一个指数加权平均算法，用于获取平滑后的报文大小。平滑后的报文大小主要用来计算保持窗口大小。

2.1.2. 重要方法

1）EnqueuePackets

外部模块调用此接口发送报文。

2）CreateProbeClusters

创建带宽探测簇，内部调用 PacingController 对应方法。

3）SetCongested

设置链路拥塞状态，内部调用 PacingController 对应方法。

4）SetPacingRates

设置平滑发送速率，内部调用 PacingController 对应方法。

5）SetSendBurstInterval

设置平滑发包间隔，内部调用 PacingController 对应方法。

6）SetQueueTimeLimit

设置报文最大排队时间，内部调用 PacingController 对应方法。

2.2. 源码分析

2.2.1. EnqueuePackets

创建一个任务 Post 到内部线程，循环遍历所有要发送的报文，调用 PacingController 接口将报文插入发送队列。报文入队列完毕后，可能有报文需要发送，立即触发一次发包处理。

void TaskQueuePacedSender::EnqueuePackets(
  std::vector<std::unique_ptr<RtpPacketToSend>> packets) {
    task_queue_->PostTask(
      SafeTask(safety_.flag(), [this, packets = std::move(packets)]() mutable {
        // 循环遍历所有报文
        for (auto& packet : packets) {
          // 计算报文大小：header + payload + padding
          size_t packet_size = packet->payload_size() + packet->padding_size();
          if (include_overhead_) {
            packet_size += packet->headers_size();
          }
          // 计算平滑后的报文大小：y(k) = 0.9 * y(k-1) + 0.1 * sample
          packet_size_.Apply(1, packet_size);
          // 调用 PacingController::EnqueuePacket
          pacing_controller_.EnqueuePacket(std::move(packet));
        }
        // 插入报文后立即触发一次处理
        MaybeProcessPackets(Timestamp::MinusInfinity());
      }));
}

2.2.2. MaybeProcessPackets

先检测是否有报文需要发送，如果有则循环发送这个时间片需要发送的报文，然后获取下一次报文发送时间，创建一个新的调度任务，继续下一轮报文发送，形成一个发包循环。