【音视频】WebRTC-NACK

原文链接：https://blog.csdn.net/zhh157/article/details/140561904

一、Nack是什么？

WebRTC 中的 NACK（Negative Acknowledgment）机制是实时通信中处理网络丢包的关键组件。网络丢包是常见的现象，尤其是在无线网络或不稳定连接中。NACK 机制旨在通过请求重传丢失的数据包来减少这种影响，从而保持通信的连续性和质量，当接收端发现数据包丢失时，会主动告诉发送端 “哪个包丢了，请再发一次”，确保关键数据能完整到达

二、WebRTC NACK

2.1 总体架构

WebRTC NACK 总体架构如下图所示。

发送端

发送端的核心需求是：当收到 NACK 请求时，能快速找到并重新发送丢失的数据包。而RtpPacketHistory就是用来实现这个需求的 “临时仓库”。

具体工作流程：

1. 缓存新发送的 RTP 包：
   发送端每发一个 RTP 数据包（比如视频帧的分片），都会先复制一份存入RtpPacketHistory中（相当于 “存档”）。这个缓存会保留一段时间（通常几百毫秒，取决于网络延迟），确保有足够时间等待可能的 NACK 请求。

2. 收到 NACK 请求时重传：
   当发送端收到接收端的 NACK 消息（里面包含丢失的 RTP 包序列号，比如 “丢了序号 100 的包”），就会从RtpPacketHistory中查找序号 100 的包，找到后重新发送。

3. 收到 TransportFeedback 后清理缓存：
   接收端会定期发送TransportFeedback（传输反馈，属于 RTCP 消息的一种），里面会明确告诉发送端：“哪些序号的包我已经收到了（比如序号 99、101、102）”。
   发送端的RtpPacketHistory收到这个反馈后，会把 “已被确认收到” 的包从缓存中删除（比如删掉 99、101、102），只保留 “未确认” 的包（比如序号 100，因为还没收到确认，可能丢了）。

为什么要这么设计：

• 缓存是为了快速重传：如果不缓存，发送端发完包就扔了，收到 NACK 时根本无法重传。
• 及时清理是为了节省内存：缓存不需要永久保留，已确认收到的包再留着就是浪费空间。

RtpPacketHistory

RtpSenderEgress 负责报文发送，发送完后将报文缓存到 RtpPacketHistory。ModuleRtpRtcpImpl2 处理所有 RTCP 报文，NACK 请求交给 RTPSender 处理，RTPSender 从 RtpPacketHistory 获取请求重传的报文然后发送出去

重传条件

RtpSenderEgress 只会将满足条件的报文缓存到 RtpPacketHistory。正常的视频帧需要重传，但 FEC 报文不重传。另外，对于 simulcast 或 SVC，需要根据重传策略来决定，判断逻辑比较复杂，这里暂不分析

void RtpSenderEgress::CompleteSendPacket(const Packet& compound_packet,
  bool last_in_batch) {
  ...
 
  if (is_media && packet->allow_retransmission()) {
    packet_history_->PutRtpPacket(std::make_unique<RtpPacketToSend>(*packet), now);
  } else if (packet->retransmitted_sequence_number()) {
    packet_history_->MarkPacketAsSent(*packet->retransmitted_sequence_number());
  }
 
  ...
}

队列长度

• 缓存队列长度非常重要，太长的话，会引入较大延迟，太短的话，会导致重传 miss。因此，队列长度的设置需要在延迟和 miss 之间取得一个较好的平衡。

• WebRTC 从时间和数量两个维度来对队列长度进行限制，其中，kMaxCapacity 是一个硬性数量限制，不管缓存的报文是否新鲜，都不能超过这个限制。

// packet_duration = max(1 second, 3x RTT).
static constexpr TimeDelta kMinPacketDuration = TimeDelta::Seconds(1);
static constexpr int kMinPacketDurationRtt = 3;
 
// With kStoreAndCull, always remove packets after 3x max(1000ms, 3x rtt).
static constexpr int kPacketCullingDelayFactor = 3;
 
// number_to_store_ = min(kMaxCapacity, kMinSendSidePacketHistorySize)
static constexpr size_t kMaxCapacity = 9600;
static const int kMinSendSidePacketHistorySize = 600;

void RtpPacketHistory::CullOldPackets() 
{
  // 当前时间
  Timestamp now = clock_->CurrentTime();
  
	// 取 3 倍 RTT 和 1秒两者较大值，即不小于 1 秒
  TimeDelta packet_duration =
      rtt_.IsFinite()
          ? std::max(kMinPacketDurationRtt * rtt_, kMinPacketDuration)
          : kMinPacketDuration;
 
  while (!packet_history_.empty()) {
    // 队列中报文数量超过最大容量限制
    if (packet_history_.size() >= kMaxCapacity) {
      RemovePacket(0); // 移除最旧的报文
      continue;
    }
 
    // 取队列首报文进行判断
    const StoredPacket& stored_packet = packet_history_.front();
 
    // 正在重传中，退出
    if (stored_packet.pending_transmission_) {
      return;
    }
 
    // 还很新鲜（未超时），退出
    if (stored_packet.send_time() + packet_duration > now) {
      return;
    }
 
    // 首报文已经不新鲜，如果报文数量多或者首报文太老，才需要移除
    if (packet_history_.size() >= number_to_store_ ||
      stored_packet.send_time() + (packet_duration * kPacketCullingDelayFactor) <= now) {
      RemovePacket(0);
    } else {
      // No more packets can be removed right now.
      return;
    }
  }
}

PaddingMode

• RtpPacketHistory 还可以用来生成带宽探测所需的 padding 报文，用真实报文当 padding 报文，既填充了码率又实现了冗余，一石二鸟。

• RtpPacketHistory 中缓存了很多报文，挑选哪些报文做 padding 报文，支持三种 padding 模式：

enum class PaddingMode {
	// 选择最近缓存的报文作为 Padding 报文
	kDefault,
	// 基于发送时间、重传次数等因素选择更好的历史报文作为 Padding 报文
	kPriority,
	// 使用最近缓存的大包作为Padding报文
	kRecentLargePacket
};

对于 kPriority 模式，优先级定义如下：

bool RtpPacketHistory::MoreUseful::operator()(StoredPacket* lhs,
                                              StoredPacket* rhs) const {
  // 没有重传过的报文优先级更高
  if (lhs->times_retransmitted() != rhs->times_retransmitted()) {
    return lhs->times_retransmitted() < rhs->times_retransmitted();
  }
  // 时间越近的报文优先级越高
  return lhs->insert_order() > rhs->insert_order();
}

最新代码已经不再使用 kDefault 模式。

RtpPacketHistory::PaddingMode GetPaddingMode(const FieldTrialsView* field_trials) {
  if (!field_trials ||
      !field_trials->IsDisabled("WebRTC-PaddingMode-RecentLargePacket")) {
    return RtpPacketHistory::PaddingMode::kRecentLargePacket;
  }
  return RtpPacketHistory::PaddingMode::kPriority;
}

接收端

接收端的核心需求是：准确判断哪些包真的丢了（而不是暂时乱序），并及时请求重传。NackRequester就是干这个的，负责 “侦探丢包” 和 “发送 NACK 请求”。

具体工作流程：

1. 跟踪所有收到的 RTP 包序列号：
   接收端每收到一个 RTP 包，都会把它的序列号（比如 101）告诉NackRequester。NackRequester会维护一个 “已收到序列号” 的列表，通过这个列表判断是否有缺失。

2. 区分 “丢包” 和 “乱序”：
   网络中数据包经常会 “乱序到达”（比如发送顺序是 100→101→102，但接收顺序是 101→100→102）。这时如果看到序列号不连续（比如先收到 101，没收到 100），不能立刻判定 100 丢了，因为它可能只是来晚了。
   所以NackRequester不会 “看到断号就发 NACK”，而是会等一小段时间（比如 50ms），看看后面的包到达后，前面的缺失包是否会补上来。

3. 定时器驱动发送 NACK：
   NackRequester会启动一个定时器（比如每隔 20ms 检查一次）。每次检查时，它会对比 “已收到的序列号” 和 “预期应收到的序列号”，如果某个序列号（比如 100）在等待一段时间后仍未出现，就判定为 “真丢了”，然后生成 NACK 消息（包含 100 的序号）发送给发送端。

4. 极端情况请求关键帧：
   如果丢包非常严重（比如连续丢了 10 个包，且都是同一个视频帧的分片），即使重传这些包可能也来不及（因为视频帧已经过了解码时间），或者重传成功率低。这时NackRequester会触发 “关键帧请求”（通过 RTCP 的PictureLossIndication消息），直接让发送端重新发送一个完整的关键帧（视频中关键帧可以独立解码，不需要依赖其他帧），快速恢复画面。
   

NackRequester

每一个 RtpVideoStreamReceiver2 都持有一个 NackRequester，用来发起 NACK 请求。NackRequester 被 NackPeriodicProcessor 定时驱动，NACK 请求通过 NackSender 发送出去。如果丢包特别严重，NackRequester 会使用 KeyFrameRequestSender 发起关键帧请求。

NackList

NackList 是 NackRequester 内部的 NACK 请求队列。每次收到新的报文，与最近收到的报文 SN 进行比较，如果两个 SN 之间有空洞（SN 跳跃），认为有丢包，以空洞 SN 创建 NACK 请求项插入 NackList。

// 队列中首尾报文Sequence Number的最大跨度，适用于NackList、KeyFrameList和RecoveredList
constexpr int kMaxPacketAge = 10'000;
// 队列中最大报文数
constexpr int kMaxNackPackets = 1000;
// 最大重传次数
constexpr int kMaxNackRetries = 10;

因为空洞也可能是乱序导致，后续可能立即就会收到丢失报文，所以不能立即发送 NACK 请求。WebRTC 会启动一个定时器，确定 NackRequester 定时检查 NackList 中的 NACK 项，判断是否需要发送 NACK 请求。

决定选取哪些 NACK 项发起 NACK 请求，有不同筛选条件：

enum NackFilterOptions { kSeqNumOnly, kTimeOnly, kSeqNumAndTime };

1. kSeqNumOnly
   基于报文乱序情况，每个 NACK 项插入队列时都会计算一个触发重传的 SN，表示后续收到此 SN 报文时，如果NACK 项还在队列中，且还没有发起过 NACK 请求，则立即触发一次。
   每收到一个报文会检查此条件，当瞬时丢包比较严重的时候，能够比定时器更快触发 NACK 请求的发送，类似于 TCP 的快速重传机制。

2. kTimeOnly
   每次发送 NACK 请求都会更新 NACK 的最近请求时间，如果最近请求时间距当前时间超过一个 RTT，则会重新触发 NACK 请求。此条件由定时器驱动进行检查。

3. kSeqNumAndTime
   相当于“kSeqNumOnly || kTimeOnly”，只要一个条件满足就会触发 NACK 请求。（好像未使用）

KeyFrameList

KeyFrameList 存储每个I帧的第一个RTP报文序号，用于标记 GOP 的边界，协助 NackList 进行收缩。对于视频来说，GOP 中的帧是有依赖关系的，如果前面的帧没有恢复，恢复后面的帧没有意义。因此，当 NackList 请求项溢出需要移除一些腾出空间时，WebRTC 是按照 GOP 粒度去丢弃历史久远的 NACK 请求项。

下面举例说明。假设有一个视频流，每个 GOP 由 5 个非 I 帧 报文和 2 个 I 帧报文组成，报文序列如下所示：

1,2,3,4,5,6,7,8,9,10,11,12,13,14,...

如果没有及时收到 3、4、11、13 四个报文，NackList 和 KeyFrameList 状态如下：

此时，如果需要创建新的 NACK 项，但 NackList 空间不够，需要丢弃 GOP1（3和4两个Nack项），状态如下：

NackList 空出两个表项，如果空间还不够，则从 KeyFrameList 中弹出表项，直到 SN(Sequence Number) 比 NackList 中的大，然后重复删除过程。

RecoveredList

NackRequester 内部有一个 RecoveredList，如果收到的是通过 FEC 或 RTX 恢复的报文，不会用来生成 NACK 请求项，而是被保存到 RecoveredList 中。在创建 NACK 请求项时，如果此报文已经被恢复了，则需要跳过。

为什么不把恢复报文当成普通的报文来处理，目前看是如果那样做会影响乱序的统计，而乱序的统计，又会影响前面讲到的 kSeqNumOnly 快速重传序号的计算。

源码分析

OnReceivedPacket

这是 NackRequester 主函数，收到每个报文都需要调用此函数来生成或移除 NACK 请求项。

int NackRequester::OnReceivedPacket(uint16_t seq_num, bool is_keyframe,
	bool is_recovered) {
 
	bool is_retransmitted = true;
 
	// 初始化
	if (!initialized_) {
		newest_seq_num_ = seq_num;
		if (is_keyframe)
			keyframe_list_.insert(seq_num);
		initialized_ = true;
		return 0;
	}
 
	// 重复接收
	if (seq_num == newest_seq_num_)
		return 0;
 
	// 乱序包
	if (AheadOf(newest_seq_num_, seq_num)) {
		auto nack_list_it = nack_list_.find(seq_num);
		int nacks_sent_for_packet = 0;
 
		// 报文已经收到，移除 nack 项
		if (nack_list_it != nack_list_.end()) {
			nacks_sent_for_packet = nack_list_it->second.retries;
			nack_list_.erase(nack_list_it);
		}
 
		// 直方图统计乱序情况，重传报文的乱序不统计
		if (!is_retransmitted)
			UpdateReorderingStatistics(seq_num);
 
		return nacks_sent_for_packet;
	}
 
	// 保存关键帧报文序列号
	if (is_keyframe)
		keyframe_list_.insert(seq_num);
 
	// 关键帧报文太多了，清理下
	auto it = keyframe_list_.lower_bound(seq_num - kMaxPacketAge);
	if (it != keyframe_list_.begin())
		keyframe_list_.erase(keyframe_list_.begin(), it);
 
	// 经 FEC 或 RTX 恢复的报文
	if (is_recovered) {
		recovered_list_.insert(seq_num);
		// 恢复报文太多，清理下
		auto it = recovered_list_.lower_bound(seq_num - kMaxPacketAge);
		if (it != recovered_list_.begin())
			recovered_list_.erase(recovered_list_.begin(), it);
 
		// Do not send nack for packets recovered by FEC or RTX.
		return 0;
	}
 
	// 走到这里 seq_num 肯定比 newest_seq_num 大，newest_seq_num_ + 1, seq_num 之间
	// 可能存在 0 个或多个空洞，这些空洞就是需要发送nack的报文
	AddPacketsToNack(newest_seq_num_ + 1, seq_num);
 
	// 更新收到的最新序列号
	newest_seq_num_ = seq_num;
 
	// 这里仅发送基于序列号触发的 NACK 请求
	std::vector<uint16_t> nack_batch = GetNackBatch(kSeqNumOnly);
	if (!nack_batch.empty()) {
		nack_sender_->SendNack(nack_batch, /*buffering_allowed=*/true);
	}
 
	return 0;
}

AddPacketsToNack

当新收到报文与最近收的报文之间有空洞时，会调用此函数插入 NACK 请求项。这里要关注下，极端情况会清空 NACK 请求列表，直接发送关键帧请求。

void NackRequester::AddPacketsToNack(uint16_t seq_num_start, uint16_t seq_num_end) {
	// NACK 项太多了，清理下
	auto it = nack_list_.lower_bound(seq_num_end - kMaxPacketAge);
	nack_list_.erase(nack_list_.begin(), it);
 
	// 计算空洞数量
	uint16_t num_new_nacks = ForwardDiff(seq_num_start, seq_num_end);
 
	// 确保添加空洞 NACK 项后总 NACK 项不会超过最大限制
	if (nack_list_.size() + num_new_nacks > kMaxNackPackets) {
		// 先移除关键帧之前的 NACK 项
		while (RemovePacketsUntilKeyFrame() &&
			nack_list_.size() + num_new_nacks > kMaxNackPackets) {
		}
 
		// 还是腾不出足够的空间，则清空 NACK 队列，直接请求 I 帧
		if (nack_list_.size() + num_new_nacks > kMaxNackPackets) {
			nack_list_.clear();
			keyframe_request_sender_->RequestKeyFrame();
			return;
		}
	}
 
	// 遍历所有空洞创建 NACK 项
	for (uint16_t seq_num = seq_num_start; seq_num != seq_num_end; ++seq_num) {
		// 空洞报文可能已经被 FEC 或 RTX 恢复
		if (recovered_list_.find(seq_num) != recovered_list_.end())
			continue;
 
		// 使用乱序长度的中位数来计算触发重传的序列号
		NackInfo nack_info(seq_num, seq_num + WaitNumberOfPackets(0.5), 
			clock_->CurrentTime());
 
		nack_list_[seq_num] = nack_info;
	}
}

GetNackBatch

定时器驱动调用此函数，定时检查发送 NACK 请求项。

void NackRequester::ProcessNacks() {
	// 定时器驱动，只获取基于时间条件判断需要处理的 NACK 项
  std::vector<uint16_t> nack_batch = GetNackBatch(kTimeOnly);
  if (!nack_batch.empty()) {
    nack_sender_->SendNack(nack_batch, /*buffering_allowed=*/false);
  }
}
 
std::vector<uint16_t> NackRequester::GetNackBatch(NackFilterOptions options) {
  // 仅考虑序列号
	bool consider_seq_num = options != kTimeOnly;
	// 仅考虑时间
  bool consider_timestamp = options != kSeqNumOnly;
	// 当前时间
  Timestamp now = clock_->CurrentTime();
	// 筛选结果
  std::vector<uint16_t> nack_batch;
 
  auto it = nack_list_.begin();
  while (it != nack_list_.end()) {
		// 等待发送 NACK 的时间已经到了
    bool delay_timed_out = now - it->second.created_at_time >= send_nack_delay_;
		
		// 距离上一次发送 NACK 的时间也已经过去很久了
    bool nack_on_rtt_passed = now - it->second.sent_at_time >= rtt_;
		
		// 基于序列号的发送，只有在第一次发送Nack时生效
    bool nack_on_seq_num_passed =
        it->second.sent_at_time.IsInfinite() &&
        AheadOrAt(newest_seq_num_, it->second.send_at_seq_num);
 
		// 已经过了等待时间，基于时间和基于序列号两者满足其一
    if (delay_timed_out && ((consider_seq_num && nack_on_seq_num_passed) ||
                            (consider_timestamp && nack_on_rtt_passed))) {
      nack_batch.emplace_back(it->second.seq_num);
      
			++it->second.retries; // 更新发送 NACK 请求次数
      it->second.sent_at_time = now; // 更新最近发送 NACK 请求时间
      
			// 已经达到最大请求次数限制，从队列中移除，不再请求了
			if (it->second.retries >= kMaxNackRetries) {
        it = nack_list_.erase(it);
      } else {
        ++it;
      }
      continue;
    }
    ++it;
  }
  return nack_batch;
}

三、总结

WebRTC NACK 的实现简单明了，发送端缓存报文，接收端请求重传。但发送端和接收端实现关注重点不太一样。发送端是被动接收 NACK 请求，实现相对简单一些，重点关注缓存队列的长度。接收端需要主动发送发送 NACK 请求，实现会相对复杂一些，由于存在报文乱序，什么时候发起 NACK 请求是一个值得斟酌的事情。

除此之外，WebRTC 还考虑到了瞬间突发丢包的快速重传机制和基于关键帧的队列收缩等，这些都凸显了 WebRTC 对细节的掌控和重视。