当前位置： 首页 > news >正文

WebRTC服务质量（08）- 重传机制（05) RTX机制

news 2024/12/25 20:45:45

WebRTC服务质量（01）- Qos概述
WebRTC服务质量（02）- RTP协议
WebRTC服务质量（03）- RTCP协议
WebRTC服务质量（04）- 重传机制（01) RTX NACK概述
WebRTC服务质量（05）- 重传机制（02) NACK判断丢包
WebRTC服务质量（06）- 重传机制（03) NACK找到真正的丢包
WebRTC服务质量（07）- 重传机制（04) 接收NACK消息
WebRTC服务质量（08）- 重传机制（05) RTX机制
WebRTC服务质量（09）- Pacer机制（01) 流程概述
WebRTC服务质量（10）- Pacer机制（02) RoundRobinPacketQueue
WebRTC服务质量（11）- Pacer机制（03) IntervalBudget
WebRTC服务质量（12）- Pacer机制（04) 向Pacer中插入数据

一、前言：

RTX协议（Retransmission，即重传协议）是 WebRTC 中用于处理丢包恢复的一部分。由于网络通信中的丢包不可避免，WebRTC RTP协议栈支持多种丢包恢复机制，其中之一便是通过RTX协议实现的重传机制。

RTX协议会根据 RTP 丢包检测机制（具体由 RTCP 的 NACK 包触发），将数据包重传给接收端。RTX 的核心思想是发送端将丢失的数据包重新封装并发送，而接收端根据识别重新封装的数据包进行补偿处理，从而还原完整的流媒体内容。

二、RTX协议的工作原理:

RTX 的工作紧密依赖于 RTP 和 RTCP 协议。以下是 RTX 的通信流程：

  1. 发送端发送数据包： 发送端按照 RTP 协议发送音视频流，每个 RTP 数据包都有唯一的序列号（sequence number），用于接收端检测是否丢包。
  2. 接收端检测丢包： 接收端通过接收 RTP 包的序列号，以及 RTP/RTCP 的统计信息，检测数据是否丢失。一旦丢包，接收端会发送 RTCP NACK（Negative Acknowledgment）反馈包给发送端，并指定丢失数据包的序列号。
  3. 发送端重新发送丢失的数据包： 发送端根据接收到的 RTCP NACK 请求，使用 RTX 流重传对应的丢失数据包。RTX 流不同于主流（primary stream），通常会有独立的 SSRC（Synchronization Source Identifier）用于区分两者。
  4. 接收端合并重传包： 接收端接收到 RTX 包后，根据 RTX 的特殊封装格式提取出原始 Payload（数据载荷）并通过序列号将其合并到主流中。

RTX 的核心点在于：

  • 独立的 SSRC：RTX 使用独立的 SSRC，和主流区分开，这样可以识别重传流。
  • 修改过的 RTP 包头：RTX 包在 RTP 层修改了一些元信息，用于兼容重传流和主流的处理。
  • RTX包有自己的payload type
  • RTX包是按照自己的Sequence Number进行排序的。

三、如何找到RTX包：

  • 找到Offer/Answer这种SDP信息。
  • 从SDP中找到RTX的SSRC。
  • 然后抓包，根据SSRC过滤出RTX包。

四、RTX协议格式：

在这里插入图片描述

  1. RTP Header：和前面介绍协议时候的RTP Header是一样的；
  2. OSN：重传的是哪个原始数据的序列包，注意我们RTX属于RTP协议，这儿的Original指的是RTP包；
  3. 可以看出RTX就是普通的RTP协议加了2字节的OSN，注意不是RTCP；

五、抓取RTX包：

5.1、获取本机的RTX流：

在这里插入图片描述

看看RTX的seq：

在这里插入图片描述

seq独立可以更好的统计出丢包。

5.2、看看原始流哪些包丢失了:

在这里插入图片描述

BLP是0x0001。知道BLP是什么吗？

1）NACK PID和NACK BLP:

1）概念：

在 NACK 中，NACK PID 和 NACK BLP 是两个关键的字段，用于标识和管理需要重传的数据包。

  • NACK PID：NACK PID（Packet ID）是 NACK 报文中的一个字段，用于指示需要重传的丢失数据包的序列号。当接收端检测到数据包丢失时，会发送 NACK 报文，其中 NACK PID 指示了具体丢失的数据包的序列号。
  • NACK BLP：NACK BLP（Bitmask of Lost Packets）是 NACK 报文中的另一个字段，用于指示一连串连续丢失的数据包。NACK BLP 是一个比特掩码，每个比特位对应一个数据包序列号，用于表示一段连续的丢失数据包范围。

2）举个例子：

假设在一个 WebRTC 实时通信会话中，发送端发送了一系列 RTP 数据包给接收端，序列号分别为 10、11、12、13、14、15。接收端在接收过程中发现数据包 11 和 13 丢失了。接收端会发送 NACK 报文给发送端，请求重传这两个丢失的数据包。

在这个例子中，NACK 报文中的 NACK PID 和 NACK BLP 可能会被设置如下：

  • NACK PID：11, 13
    • NACK PID 指示需要重传的具体丢失数据包的序列号，即数据包 11 和数据包 13。
  • NACK BLP：010010
    • 在这个二进制掩码中，每个比特位对应一个数据包序列号。接收端标记了丢失的数据包范围，从 10 到 15 中的第 2 和第 4 个数据包丢失。
    • 这表示数据包 11 和数据包 13 丢失，而其他数据包正常接收。

3）本文丢包情况：

NACK 报文中 NACK PID 的值为 6806，而 NACK BLP 的值为 0x0001，可以解释如下：

  • NACK PID：6806
    • NACK PID 表示需要重传的具体丢失数据包的序号，即数据包序号为 6806 的数据包需要进行重传。
  • NACK BLP：0x0001
    • NACK BLP 是一个十六进制数，转换为二进制为 0000 0000 0000 0001。
    • 在这个二进制掩码中，每个比特位对应一个数据包序号。由于只有一个比特位为 1，表示只有一个数据包丢失。
    • 在这种情况下，第一个（最低位）的 1 表示序号为 6806 的数据包丢失，其它数据包接收正常。

5.3、使用RTX进行重传:

如果你在抓包软件中找不到RTX包，记得使用时间戳来找。

在这里插入图片描述

因此发送的RTX一定在这个点之后；

在这里插入图片描述

  1. 可以看出872691小于收到NACK的时间点876269，肯定不是。
  2. 881999大于收到NACK的时间点，可能是。
  3. 通过前面协议我们知道RTX的前2个字节是OSN，表示原始数据的序列号，因此，我们将0x1a96转换为十进制看是多少；

在这里插入图片描述

看到没有，重传的额就是6806这个数据包。

六、发送RTX的过程：

我们得先看下NACK接收流程：

在这里插入图片描述

会来到这里：

void RTPSender::OnReceivedNack(const std::vector<uint16_t>& nack_sequence_numbers,int64_t avg_rtt) {packet_history_->SetRtt(5 + avg_rtt);// 遍历nack中每个需要重传的seq，进行重传for (uint16_t seq_no : nack_sequence_numbers) {// 发送RTXconst int32_t bytes_sent = ReSendPacket(seq_no);if (bytes_sent < 0) {// Failed to send one Sequence number. Give up the rest in this nack.RTC_LOG(LS_WARNING) << "Failed resending RTP packet " << seq_no<< ", Discard rest of packets.";break;}}
}

看看具体怎么重传的：

int32_t RTPSender::ReSendPacket(uint16_t packet_id) {absl::optional<RtpPacketHistory::PacketState> stored_packet =packet_history_->GetPacketState(packet_id);if (!stored_packet || stored_packet->pending_transmission) {return 0;}const int32_t packet_size = static_cast<int32_t>(stored_packet->packet_size);const bool rtx = (RtxStatus() & kRtxRetransmitted) > 0;std::unique_ptr<RtpPacketToSend> packet =packet_history_->GetPacketAndMarkAsPending(packet_id, [&](const RtpPacketToSend& stored_packet) {std::unique_ptr<RtpPacketToSend> retransmit_packet;if (retransmission_rate_limiter_ &&!retransmission_rate_limiter_->TryUseRate(packet_size)) {return retransmit_packet;}if (rtx) {retransmit_packet = BuildRtxPacket(stored_packet);} else {retransmit_packet =std::make_unique<RtpPacketToSend>(stored_packet);}if (retransmit_packet) {retransmit_packet->set_retransmitted_sequence_number(stored_packet.SequenceNumber());}return retransmit_packet;});if (!packet) {return -1;}packet->set_packet_type(RtpPacketMediaType::kRetransmission);packet->set_fec_protect_packet(false);std::vector<std::unique_ptr<RtpPacketToSend>> packets;packets.emplace_back(std::move(packet));paced_sender_->EnqueuePackets(std::move(packets));return packet_size;
}

我们根据代码逻辑发现，并不一定要使用RTX：

  1. 如果启用了 RTX（Retransmission），则构造并发送独立的 RTX 包。
  2. 如果没有启用 RTX，则直接从包历史记录中取出丢失的原始 RTP 包并重传。

代码比较负责，关键部分展开说明下：

1）构造重传包：

  • 匿名函数：

    std::unique_ptr<RtpPacketToSend> packet =packet_history_->GetPacketAndMarkAsPending(packet_id, [&](const RtpPacketToSend& stored_packet) {std::unique_ptr<RtpPacketToSend> retransmit_packet;// 检查重传速率限制if (retransmission_rate_limiter_ &&!retransmission_rate_limiter_->TryUseRate(packet_size)) {return retransmit_packet;}if (rtx) {// 如果支持 RTX，构造一个 RTX 包retransmit_packet = BuildRtxPacket(stored_packet);} else {// 否则直接使用原始 RTP 包retransmit_packet =std::make_unique<RtpPacketToSend>(stored_packet);}if (retransmit_packet) {retransmit_packet->set_retransmitted_sequence_number(stored_packet.SequenceNumber());}return retransmit_packet;});

    这段代码的核心是获取丢失的历史包并将其打包为重传包：

    1. 调用 packet_history_->GetPacketAndMarkAsPending：
      • 从历史记录中取出丢失的 RTP 包，并标记该包已进入待发送状态（防止重复重传）。
    2. 使用匿名函数对包进行加工处理：
      • 重传速率限制：
        • 如果当前重传速率超出了允许的带宽，则直接丢弃该重传包，不做进一步处理。
      • RTX 构造：
        • 如果启用了 RTX，通过调用 BuildRtxPacket 方法，将原始包封装为 RTX 包。
        • 关键点：RTX 包的特殊结构包含原始包的 OSN（Original Sequence Number），用于表示其原始 RTP 包的序列号。
      • 普通重传包：
        • 如果没有启用 RTX，则直接复制原始 RTP 包来重发。
      • 设置序列号：
        • 调用 set_retransmitted_sequence_number，设置重传包所对应的原始序列号。

2）重传包的最终处理：

if (!packet) {return -1;
}packet->set_packet_type(RtpPacketMediaType::kRetransmission);
packet->set_fec_protect_packet(false);
std::vector<std::unique_ptr<RtpPacketToSend>> packets;
packets.emplace_back(std::move(packet));// 将重传包加入到 paced sender 的发送队列
paced_sender_->EnqueuePackets(std::move(packets));
  1. 检查是否成功获取重传包：
    • 如果没有生成有效的重传包（可能被带宽限制丢弃），返回 -1。
  2. 设置包类型：
    • 通过 set_packet_type 设置为 kRetransmission，标明这是一个重传包。
    • set_fec_protect_packet(false)：通知不对重传包应用 FEC（前向纠错）保护，因为 RTX 本身是另一个冗余机制。
  3. 插入发送队列：
    • 将重传包添加到 paced_sender_（节奏发送器）模块中，以有节奏地发送包，避免瞬时大量重传耗尽带宽。

3）小结：

  1. RTX 重传的实现流程：
    • RTX 重传包通过函数 BuildRtxPacket 生成。
    • RTX 中包含一个特殊的字段 OSN，用于恢复原始包的序列号。
    • 通过独立的 SSRC 和 Payload Type 区分 RTX 包与普通主流包。
  2. 带宽管理和速率控制：
    • retransmission_rate_limiter_ 限制了重传包的发送速率，防止网络因重传过载。
  3. 灵活处理重传策略：
    • 支持两种模式：RTX 和普通 RTP 重传。
    • RTX 是更成熟的丢包恢复机制，但需要双方支持；否则退回到简单的 RTP 重传方式。

七、总结：

RTPSender::ReSendPacket 函数是 WebRTC 中 RTP 协议层实现丢包恢复的重要部分。它利用 RtpPacketHistory 记录和 RTX 协议实现高效的重传机制，同时考虑到带宽管理、速率限制和两种重传策略（RTX 和普通 RTP）的兼容性。在具体代码实现中，它通过灵活的封装和严格的速率控制，保证了无损恢复的同时避免了网络拥塞情况。


http://www.mrgr.cn/news/81405.html

相关文章：

  • PaginationInnerInterceptor，spring中pojo
  • 专栏二十三：Python读取和分析空间数据的经验杂谈
  • 安卓多渠道apk配置不同签名
  • MySQL什么情况下会导致索引失效
  • 数据结构经典算法总复习（上卷）
  • 基于openEuler22.09部署OpenStack Yoga云平台（一）
  • 用VBA将word文档处理成支持弹出式注释的epub文档可用的html内容
  • 【RAII | 设计模式】C++智能指针，内存管理与设计模式
  • 51c自动驾驶~合集42
  • Hot100刷题计划-Day3 二分查找专题【持续更新】
  • lodash常用函数
  • 路由器做WPAD、VPN、透明代理中之间一个
  • Git使用经历
  • 06 - Django 视图view
  • Avalonia实例实战五：Carousel自动轮播图
  • 【linux】 unshare -user -r /bin/bash命令详解
  • JdbcTemplate、NamedParameterJdbcTemplate 执行数据插入后返回主键写法
  • Pytorch | 利用I-FGSSM针对CIFAR10上的ResNet分类器进行对抗攻击
  • acme ssl证书自动续签 nginx
  • Android U 多任务启动分屏——system_server流程（更新中）
  • 【Linux】ChatGLM-4-9B模型之All Tools
  • 【目标跟踪综述及关键技术】
  • 重温设计模式--2、设计模式七大原则
  • 人工智能ACA（六）--计算机视觉基础
  • js版本之ES6特性简述【Proxy、Reflect、Iterator、Generator】(五)
  • 时钟芯片入门指南：从原理到实践