其实弱网对策的RTC冗余策略的问题并不复杂，但是又很多的朋友都不太了解，因此呢，今天小编就来为大家分享弱网对策的RTC冗余策略的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

我们可以使用一些简单基础的工具来检测网络是否出现波动。例如，ping命令或Iperf工具可以帮助统计丢包、延迟和单向抖动。我们使用ping 命令向远程主机发送ICMP 消息，远程主机会回复你。在此过程中，如果您发送的ICMP 报文丢失，或者来自远程服务器的响应报文丢失，您可以使用命令行界面在屏幕上，相应的icmp_seq 会显示经过一段时间后还没有收到该数据包。暂停。这种情况直观地反映了丢包情况。

ping 与iPerf

带宽分配和冗余策略是弱网对策的核心模块。随着算法的演进和迭代，我们可以保证大多数在线场景下的高质量音视频体验。针对一些小概率或者特殊的场景，比如突然断网、拥塞恢复、PPT翻页等，我们也引入了多种冗余策略，兼顾流畅性、恢复效率、低延迟的要求。

2. 常用包恢复技术

通常，当数据包在网络传输链路中丢失时，恢复数据包的方式主要有两种：一是发送方利用接收端通知或超时机制重新发送数据包；二是发送方利用接收端通知或超时机制重新发送数据包；另一种是第一种是在接收端根据其他收到的冗余数据包来恢复该数据包。

首先是众所周知的自动重复请求ARQ技术。与TCP协议中的ACK响应机制不同，实时音视频场景采用NACK否定响应机制。接收端检查报文序列号的连续性，并主动通知发送端丢失的报文信息进行重发。该方法的优点是低时延场景下恢复效率高、带宽利用率好，但在高时延场景下效果比较差，存在重传风暴等情况。

第二个是前向纠错（FEC），这是一种通过冗余传输来对抗网络数据包丢失的技术。其主要技术原理是组编码和组内冗余恢复。假设每个数据包由k个媒体数据包和r个冗余数据包组成，则数据包中的k+r个数据数据包中的任意k个数据包都可以用来重建k个原始媒体数据包。该方法的优点是根据先验知识做出冗余决策，并且不受延迟的影响。

3. 冗余策略

在上述基本包恢复技术下，为了最大限度地发挥各种场景下的整体抗弱网能力，需要对带宽分配、防丢包技术组合配置等进行一系列优化，从而达到防丢包的目的。能力、端到端时延、滞后率、冗余率的平衡，实现“最低成本、最佳体验”。

下面详细介绍一下我们在这方面所做的几项优化。

3.1 自适应调整策略

冗余策略大致可以分为两类，一类是前向冗余，另一类是被动冗余。根据前面的描述，我们知道前向冗余的优点是不需要交互，更适合高延迟的环境。缺点是占用带宽过多。被动冗余的优点是按需发送，占用带宽较少。缺点是在高延迟场景下效果会急剧下降。

我们的裁员策略是找到一个平衡点。通过调整被动冗余和前向冗余策略的比例，可以在保证丢包恢复率（如99.5%）的情况下，尽量降低冗余比例。尽量减少防丢包恢复时间。因此，我们可以将当前问题抽象为以下数学场景：

假设有m个媒体包，经过k次重传，收到i个包的概率记为： P(m, i, k) 假设有n个冗余包，则接收端收到j个包的概率记为： P(n, j, 0) 根据目前的FEC算法，当这m+n个数据包重传k次时，接收端只需要接收任意m个数据包即可恢复所有媒体数据包。这个概率是：Nack FEC 算法根据大于99% 的恢复概率计算出需要配置的最小FEC 冗余n。基于上述模型，m（平均帧数据包大小）、k（允许时间范围内的重传次数）、i、j 是自变量。只要我们把n从0开始代入，上面的求和结果大于99%，我们就可以用这个n作为FEC的冗余率。

通过上述算法，我们定义一个防丢包恢复时间resend_delay，就可以得到被动重传次数k。通过参数k，可以得出达到99%恢复率所需的FEC比例。

以上是理论上最优冗余率的计算逻辑。通过这个算法逻辑，我们可以得到自适应的冗余调整策略，以获得最佳的冗余比、最合适的时延损失和最佳的丢包恢复率。

3.2 可靠重传策略

在接收端的媒体缓存中，对于在最新和最旧的seq范围内还没有收到的数据，接收端会发送Nack请求，然后发送端会收到Nack请求并传输相应的数据包。

正常工作状态下，Pacer先发送RTX重传数据，再发送媒体数据，这样接收端较旧的丢失数据包总能先恢复。

但在某些场景下，比如大丢包（丢包率70%以上），或者突然带宽受限（4M—300K），会导致大量数据包被丢弃。这个数据包中既包括原始数据包，也包括Nack重传数据包，这会导致如下所示的一些问题。

如图所示，如果丢包恢复效果比较差，比如上面的n+3帧已经发送，但是所有n帧都没有被接收端收到。此时，接收端生成的需要重传的数据包的nack_list将会很长。对于发送方来说，由于媒体数据不断发送，理论上接收端会请求越来越多的nack，从而形成nack风暴。

Nack风暴不仅会导致大量的重传流量占用媒体带宽，降低带宽分配模块分配给媒体的码率，还会造成Pacer拥塞，导致更大的端到端时延。同时，由于某个帧的媒体包没有被选择性地重传，因此接收端需要解码的帧能够从完全丢包中恢复的概率较低。

为了避免上述情况，我们引入了可靠重传模块：在检测到上述情况后，会及时暂停媒体传输，同时尽力保证已经发送的帧数据可以完全恢复。

我们利用TccAck和Nack请求的信息来判断某个数据包的状态，然后统计当前发送的数据中还没有完全ACK的帧数。如果这个数字太大，媒体发送将暂停（并且编码器将暂停）。暂停媒体传输后，按照帧从旧到新的顺序将pacer预算分配给优先级最高的帧，并主动发送这些帧中尚未ACKed的数据。

通过上述方法，我们有效解决了目标场景长时间卡顿或滞后过大的问题。

3.3 拥塞恢复场景下快速抑制FEC码率

我们的FEC使用损耗来计算FEC冗余率。为了防止抖动引起剧烈变化，对该损耗值进行平滑处理。但对于某些场景，比如带宽突然下降到较低水平时，当拥塞状态缓解后，网络丢包就会消失。这时候我们就需要快速抑制FEC码率，把带宽让给媒体，从而尽快提升画质。

利用上述状态机，在收到拥塞缓解信号后（拥塞状态缓解，瞬时tcc丢包变为0），如果平滑丢包没有变为0，则可以利用瞬时丢包快速取消FEC冗余。

3.4 空闲带宽利用率优化

在共享场景下，冗余策略遇到进一步的挑战。比如PPT不翻页的时候，就需要给视频免费带宽。但共享流在翻页时会很快占用带宽。这会导致翻页时视频码率波动较大。如果总体可用带宽较低，您会看到视频质量发生显着变化、—— 口吃率以及延迟增加。

如图所示，在PPT翻页场景下，视频会使用屏幕空闲且未使用的带宽。尽管如此，该视频还是使用了大部分最初共享的预算。一旦翻完PPT页面，共享码率瞬间升高，视频没有及时降低编码码率，就会导致pacer模块拥塞，导致丢帧、摄像机码流滞后。

针对该场景，我们优化了带宽分配策略：

在慢速和快降带宽分配过程中，各媒体流所使用的上层传输的空闲码率缓慢增加并快速下降，以防止高优先级码流过快放弃空闲带宽，导致在低优先级码流中。分配码率波动较大。

关键帧检测：当媒体流开始接收关键帧时，流放弃的空闲带宽量减少，从而减少整体输出码率的波动。

峰值检测使用300ms 的统计窗口来确定峰值。当出现大峰值数据时，流所放弃的带宽量减少，并且总体输出比特率的波动性降低。

4. 优化效果

在上述冗余策略的优化下，飞书会议整体冗余率大幅降低（增加部分是由于原算法冗余不足，存在大量滞后。算法优化后，整体冗余率调整为最大好值）。同时，在保证整体音视频效果的同时，整体端到端延迟进一步降低，提升了飞书会议的整体音视频体验。

算法优化大大降低了低时延场景下的冗余率，高时延场景下的冗余率也趋于理论上合理。解决了原算法在高丢包场景下的问题，大幅提升了高时延、高丢包率的弱网场景下的体验。解决场景，收敛网络状态变化时的速度，提升变化时的音视频体验。

与同类产品相比，我们的优化算法的冗余度明显低于同类产品，并且在流畅度一致的情况下消耗的带宽更少。尤其是在高丢包、高时延场景下，我们的冗余率仅相当于同类产品的40%。

5. 未来展望

通过这些优化的冗余策略，目前飞书会议在弱网场景下的滞后率、端到端时延、冗余率等指标都得到了大幅优化。在此基础上，未来我们将进一步加大在极弱网支持、带内冗余联动策略、智能场景识别等方面的投入，提升飞书会议在各种弱网场景下的客户端体验。

5.1 极端场景抗弱网能力支持

新增对极高丢包、极高时延、丢包+时延、低带宽+高丢包等场景的支持，结合冗余策略和带宽分配策略，在极弱网络场景下实现最佳音视频体验。

5.2 带内冗余联动下的抗弱网策略

冗余策略除了前面提到的非音视频编码内的带外冗余（Nack、FEC等）外，还包括音视频编码内的带内冗余。与带外冗余相比，带内冗余往往结合了编码本身的特点，用较少的冗余码率成本来达到较高的抗弱网络效果。

我们的冗余策略也将进一步结合并更多地利用带内冗余算法，进一步提高抵御弱网络的能力，降低整体延迟和带宽使用。

5.3 场景识别下的抗弱网络策略优化

后续我们还将识别当前的网络环境，获取当前的网络场景，以便进一步预判冗余策略和编码策略的策略下发。

用户评论

冷眼旁观i

这篇文章分析了RTC在弱网环境下的技术挑战真是到位，尤其是冗余策略的概念让我眼前一亮！ 感觉这能有效缓解网络抖动带来的延迟和丢包问题，对于实时视频通话来说可真是一大利器啊！

    有7位网友表示赞同！

将妓就计

做过项目优化知道 RTC 弱网的难题太大了，丢包延迟 echt 真让人头疼。这篇博文讲解冗余策略让我眼前一亮，感觉这确实是个思路，尤其对直播等交互性强应用效果应该更好吧。

    有7位网友表示赞同！

陌然淺笑

说的不错，实际开发中遇到很多弱网问题导致的 RTC 效果下滑，尤其是音频延迟影响体验，这篇博客分享的冗余策略很有启发！后续可以结合具体案例讨论一下不同拓扑结构下的冗余方案对比怎么样？

    有8位网友表示赞同！

呆檬

做直播和视频会议相关工作的朋友都知道，实时通信在弱网环境下简直是噩梦！这篇文章讲的“冗余策略”的确是个好思路，希望能看到更深入的文章来探讨具体的实现方式，比如常用的算法以及对性能的影响等等。

    有15位网友表示赞同！

盲从于你

RTC 弱网的问题我之前也遇到过，感觉很多时候解决方案都不很完善。这篇博客提出的冗余策略是很有新意的，希望能看到更多实操性的技术细节和案例分析！

    有13位网友表示赞同！

有阳光还感觉冷

虽然文章讲到冗余策略可以提高RTC在弱网环境下的稳定性，但我觉得这需要付出一定的性能代价。毕竟多重路径传输需要更多的资源计算。

    有11位网友表示赞同！

采姑娘的小蘑菇

对实时通话来说，延迟是绝对不能忍受的！ 感觉这个冗余策略在优化网络抖动方面效果应该有限。如果能结合智能编码、数据分组技术等其他手段，或许会更有效吧？

    有18位网友表示赞同！

遗憾最汹涌

文章提到冗余策略可以减少丢包，但我个人觉得这只是治标不治本的方法。 根本问题在于网络环境本身，真希望能够改善用户基础设施的质量！

    有18位网友表示赞同！

半梦半醒半疯癫

我觉得冗余策略在一些特定的场景下会更加有效，比如对于带宽有限的用户群体，或者一些对实时性要求极高的应用场景。

    有9位网友表示赞同！

棃海

这篇文章的内容很有价值，但是我认为它并没有深入探讨冗余策略的具体实施方案以及优缺点比较， 缺少实践操作层面的指导。

    有19位网友表示赞同！

灵魂摆渡人

文章内容清晰易懂，但对于RTC弱网对抗，我觉得除了冗余策略以外，还有很多其他方面的技术可以帮助解决问题，例如数据包重传机制、网络分段加速等。

    有8位网友表示赞同！

凝残月

感谢作者分享这篇文章， 让我对RTC弱网对抗有了更全面的认识。我正在做一项基于RTC的项目， 这篇文章的分析思路很有参考价值！

    有14位网友表示赞同！

微信名字

文章讲得比较全面，涵盖了RTC弱网对抗的一系列策略。 但我认为对每个策略的解释还是稍微浅一些，希望作者能提供更多的技术细节和案例分析。

    有20位网友表示赞同！

我一个人

我一直关注RTC相关的技术研究，这篇博文让我看到了新的思路。冗余策略是一个很有潜力的方法，相信它的应用会为提升用户体验做出积极贡献！

    有7位网友表示赞同！

不要冷战i

RTC 弱网的环境确实给我带来了很多困扰，尤其是在直播和视音频会议方面。希望这个冗余策略能够真正被广泛应用，让用户的实时通信体验更加流畅！

    有20位网友表示赞同！

荒野情趣

"RTC 弱网对抗之冗余策略" 文章很有针对性。我关注实时音视频传输技术好久了，一直苦恼于弱网环境下延迟问题。作者提出的冗余策略很有意思，能够有效缓解这个问题吗？希望后续可以分享具体的实现方案和案例分析。

    有6位网友表示赞同！

蹂躏少女

作为开发人员，我对这篇博文很感兴趣，因为在实际项目中经常遇到RTC弱点网络的问题。 文章提到冗余策略很有潜力，但同时也需要考虑其性能代价。 希望作者能进一步探讨不同类型冗余策略的优缺点以及在不同场景下的适用性。

    有10位网友表示赞同！

一笑抵千言

文章深入浅出地讲解了RTC弱网对抗中的冗余策略，让我对这个领域有了更清晰的认识。 作为一名视频分析爱好者，我很好奇这种策略能否应用于低带宽环境下的视频流畅度提高。

    有16位网友表示赞同！