如何在网络带宽和设备性能有限的环境下实现流畅直播，减少卡顿、提升清晰度。

RTC 实时音视频技术迅速发展，不断打卡新应用，渗透新场景。先进技术为线上场景带来巨大增长的同时，用户也对体验提出了更高要求，希望应用更低延时、更高画质、更加顺畅。

用户的体验需求，对应着 RTC 的三大核心指标，即实时性、清晰度、流畅度。三者之间，往往鱼与熊掌不可兼得。实时性要求较高的场景可能需要牺牲清晰度来保障低延时；而清晰度要求高的场景则可能不得不用一定的延时换取高质量的音视频数据。

为了达到更好的效果，我们需要持续进行网络传输优化来追求更低的延时、更高的清晰度和流畅性。尤其是解决弱网，这是造成拥塞、丢包、延时抖动等影响用户体验的主要问题。

关于 TCP/IP 传输层协议的选择

进入正题前，我们先简要介绍一下传输层协议。

传输层协议在 TCP/IP 分层协议中位于应用层之下，一般由操作系统内部提供实现，包括 TCP 和 UDP 两种协议。TCP 是面向连接的可靠传输协议，为数据传输的完整性和有序性提供了保障；UDP 是无连接的不可靠传输协议，数据传输的可靠性完全交由应用层处理。

实时音视频应用场景下，UDP 优先选择 UDP 协议已经是业界广泛共识。原因主要包括以下几点：

● TCP 协议并非为音视频实时应用场景设计，其内部为了可靠性和高吞吐量而设计的拥塞控制和差错控制等机制会导致延时的增加，在弱网环境下延时的恶化更为明显。根据 ITU StandardG.114 对延时的定义，端到端延时大于 400ms 时，用户的交互体验就将受到明显的影响。

● TCP 的拥塞控制机制和差错控制机制在操作系统内部实现，应用层无法优化，无法针对不同场景需求进行调整，缺乏灵活性。

● UDP 协议本身开销比 TCP 小，传输控制策略完全交由应用层来实现，更为灵活。

因此，本文后续讨论的弱网问题及相应的弱网对抗技术均基于 UDP 协议以及运行在 UDP 之上的被音视频领域广泛应用的 RTP/RTCP 协议来讨论。

弱网主要问题及其对抗技术

音视频传输弱网问题简单来说就是指影响音视频通信用户体验的网络环境问题，主要指网络拥塞、网络丢包、抖动等问题。这些问题是造成音视频卡顿、实时性不佳的主要原因。由于网络环境具有较强复杂性、异构性，上述的弱网问题在不同环境下的严重程度也有很大差异。如何保障用户在复杂网络环境下进行顺畅的沟通，一直是 RTC 领域关注的重点问题。问

题

拥塞问题

当网络中传输的数据流量超过网络瓶颈容量时，就会产生拥塞问题。拥塞的直接影响是突发丢包或突发抖动。如果不能提前预测拥塞的发生，及时降低发送数据量，那么接收端将会出现卡顿、延时大、画质差等问题。

对抗拥塞问题的主要方案是通过设计拥塞控制算法对网络拥塞进行及时的探测，并从拥塞状态尽可能快地恢复，尽量降低对用户体验的影响。

1）拥塞控制算法的需求考虑

RFC8836 对实时交互式音视频应用的拥塞控制算法需求进行了较为全面的总结，简单概括如下：

● 延时：拥塞控制算法应该尽可能降低延时，尤其是算法本身引入的延时。与此同时仍然需要提供可用的带宽水平。

● 吞吐率：在相应场景下吞吐率应尽可能高。

● 公平性：拥塞控制算法应该能够和其他实时流量和 TCP 流量公平地共享链路带宽。

● 避免“饿死”：媒体流在与 TCP 流竞争中不应被“饿死”，也不能把 TCP 流“饿死”。

● 收敛速度：在媒体流启动阶段尽可能快地收敛到稳定状态。

● 网络支持：算法不应要求特殊网络特性支持。

● 稳定性：算法应该在媒体流变化时保持稳定，比如媒体流暂时的传输中断。

● 快速响应：算法应该快速响应网络环境的变化，比如瓶颈带宽变化、链路延时变化等。

综合上述需求，拥塞控制算法要解决的问题可归类为两个方面，一是如何快速准确地进行网络拥塞探测；二是采取适当的拥塞应对措施尽量避免拥塞以及尽可能快地从拥塞状态恢复。

2）拥塞探测算法

拥塞探测算法根据观测数据的差异可用分为两类：

基于丢包的算法（Loss-based）：通过丢包事件来检测网络拥塞。

基于延时的算法（Delay-based）：通过对延时的测量来判断网络拥塞。

对于实时音视频交互式应用，基于延时的算法是更优的选择，主要原因是基于延时的算法能够更早地发现网络拥塞，从而避免由于拥塞导致的丢包。此外，基于丢包的算法往往为了探测链路容量而不断增加发送带宽，直至丢包事件发生。这种策略将导致无法控制的网络排队延时增长，尤其是网络节点的缓冲区较大时，甚至造成秒级延时的增长。

选择基于延时的算法要重点考虑需求总结中的避免“饿死”问题。基于延时的算法对延时增长相对要敏感，在与基于丢包的算法竞争网络资源时要采取适当的策略，相对公平地分享网络带宽资源。

基于延时的算法一般通过测量 RTT（round-trip time 往返延时）或者 OWD（one-way delay 单向延时）来判断拥塞。RTT 测量比较直观，但是由于是测量双向延时的总体情况，因此反向的延时变化会对媒体流方向的网络拥塞判断造成干扰。OWD 延时观测通过观测发送间隔与接收间隔的变化来判断网络排队延时的状况则避免了这个问题。如下图所示：

3）拥塞应对措施

简而言之，拥塞应对措施就是根据网络当前的拥塞状况计算出合适的发送速率来控制媒体发送端的总发送速率。根据发送端所采取的其他弱网对抗策略，可能的速率调节手段包括调节音视频编码器速率、调节重传速率、调节 FEC 冗余度等，详见本文后续介绍。如果发送端是中间转发节点，则调节手段还包括 SVC 码流适配、大小流码流适配等，如下图所示：

4）典型拥塞控制框架

典型的拥塞控制算法框架如下图所示：

这是早期 Google 在其 WebRTC 框架中采用的拥塞控制框架。采用发送端和接收端混合控制模式，发送端采用基于丢包的算法，基本策略如下：

● 丢包率<2%，增加发送带宽 8%；

● 丢包率 2% ~ 10%，发送带宽保持不变；

● 丢包率>10%，降低发送带宽（1-0.5*丢包率）。

接收端采用基于延时的算法。通过统计单向延时变化并通过卡尔曼滤波对当前的传输延时进行估计，再结合当前的实际接收带宽评估一个最佳的目标带宽，通过 RTCP 消息反馈给发送端。发送端取两个算法结果的最小值作为最终的目标带宽。

下图是 WebRTC 改进后的拥塞控制框架。

我们可以看到整个拥塞控制机制都在发送端实现，接收端只是反馈相应的测量数据。

新的框架改进了网络延时估计算法，通过对单向延时变化数据进行线性回归分析，评估当前网络排队延时变化趋势，即判断出延时正在增加、没有变化、正在降低三种趋势，再结合当前发送速率，给出最佳目标带宽估计。除了改进拥塞探测算法，新的框架也引入了主动带宽探测机制，优化了整个拥塞控制算法的性能，经过比较，在启动阶段收敛速度、网络环境变化的响应速度上都有比较明显的改进。

丢包问题

如前所述，实时交互式媒体传输基于 RTP/UDP 协议，丢包问题由应用层处理。

网络传输方面（即信道侧）的抗丢包技术手段主要包括重传（ARQ）、前向纠错（FEC）。信源编码方面根据数据以及编码方的不同也可以提供某些特定的抗丢包能力，比如视频编码中采用 B 帧降低丢包的影响。下面主要介绍网络传输方面的抗丢包技术。

1）丢包重传（ARQ）

丢包重传流程如下图所示：在 RTP/RTCP 协议中，丢包重传技术简单来讲就是接收端根据包序列号的连续性判断是否丢包，通过向源端发送 RTCP 中的 NACK 请求，要求源端重传指定的数据包。丢包重传流程如下图所示：

重传流程有以下细节需要考虑：

● 首次请求延时：应结合其他策略考虑发现丢包时是否立即请求，比如结合 FEC 策略考虑。

● 重复请求间隔考虑：同一个数据包重复请求间隔要大于当前 RTT。

● 请求次数限制：结合当前 RTT 与容忍的最大延时来计算。

● 发送端重传带宽限制：重传带宽作为总传输带宽的一部分，不能超出总体带宽限制。

● 重传包回传机制：建议采用单独的 RTP 码流发送，利于丢包率统计与重传带宽计算。

2）前向纠错（FEC）

在实时音视频应用中，前向纠错（FEC）技术在抗丢包方面因其实时性好而被广泛应用。

FEC 的基本思路粗略来讲就是发送端在发送音视频数据包之外，根据具体丢包状况再额外发送一定量的冗余数据包用于接收端进行丢包恢复，基本流程如下图所示：

目前常用的关于修复数据包的编码算法有基于异或的算法、基于矩阵的算法以及其他算法，本文不做详细阐述。

下面介绍一下 FEC 在实时音视频系统中的基本应用框架，发送端应用框架如下图所示：

（FEC 发送端框架）

上图中的 ADU 为应用数据单元，在音视频 RTC 系统中也就是音视频数据包，作为源数据块输入到 FEC 编码器，FEC 编码器根据一定的修复比率产生 FEC 修复包（repair payloads），修复包和源包及其之间保护关系一起发送给接收端。

接收端的 FEC 处理框架如下图所示：

（FEC 接收端框架）

接收端收到 FEC 源包和修复包后送到 FEC 解码器。如果源包丢失，解码器根据包组的保护关系以及收到的包组状况进行解码修复，最后将修复完成的音视频包交由上层进一步处理，完成音视频解码与显示播放。

上述中的修复包与源包的保护关系简而言之就是哪些源包被哪些修复包保护，这个保护关系由发送端通过一定的封包格式通知到接收端。

在 RTP/RTCP 协议框架下，ULPFEC（RFC5109）和 FlexFEC（RFC8627）两个标准定义了两种不同的策略和包格式：

● ULPFEC：ULP（Uneven Level Protection，不均等保护）根据数据包重要程度使用不同级别的保护策略。

● FlexFEC：Flexible Forward Error Correction，此标准在 RTP 协议框架下定义了交织与非交织的奇偶校验 FEC 编码包格式。

3）ARQ 与 FEC 的配合

相较于 FEC，ARQ 的缺点是会引入延时，优点是有较高的带宽利用率。抗丢包技术的优化目标概括来讲就是在满足延时要求的前提下，尽量以最小的额外带宽与计算成本，获得足够的保护力度。

因此，在考虑 ARQ 与 FEC 的配合策略时应考虑以下原则：

● 在延时限制容许的前提下尽可能使用 ARQ，可根据当前 RTT 和最大延时限制计算最大重传次数；

● 如果最大重传次数可以将丢包率降低到一定程度以下（<%1)，则不必开启 FEC 保护；

● 如果需开启 FEC，FEC 的保护程度要依据应用 ARQ 修复之后剩余的丢包概率来计算，进行兜底保护。

下图是在一定场景下的 FEC 与 ARQ 配合示意图，RTT 在 20ms 内，如果传输延时要求在 100ms 以内，在丢包 30% 的弱网链路上，则 ARQ 可以将丢包率降低到 1% 以下，则由 ARQ 负责丢包修复。随着 RTT 的上涨，FEC 的保护占比增加，最终由 FEC 单独负责丢包修复。

抖动问题

概括而言，抖动问题就是网络传输延时变化问题，抖动越大表示网络传输延时变化越大。

抖动问题会造成接收端卡顿、播放快进等严重影响音视频沟通体验的问题。造成抖动问题的原因是多方面的，比如新的流加入造成网络资源竞争加剧、源端数据发送速率本身不平稳以及其他网络原因。目前处理抖动的通用策略是接收端建立抖动缓冲区(JitterBuffer)来消除抖动，其原理如下图所示：

接收端通过增加抖动延时（JitterDelay）来吸收不均匀的延时，达到均匀播放的目的。其中，抖动延时大小的计算是抖动缓冲区性能好坏的关键，过大的抖动延时会引入额外延时，这在实时交互式应用领域是极力要避免的；过小又无法吸收全部的抖动。

关于抖动延时的估计，Google 在其 WebRTC 框架中用了两种方法，在音频抖动处理中用直方图加遗忘因子的方式进行估计。

WebRTC 的音频抖动延时估计在其内部的 NetEQ 模块中，图中的 Iat 意为间隔达到时间，WebRTC 通过对音频包到达间隔用直方图进行统计，取 95 分位数的延时时长作为音频抖动延时。为了跟踪延时变化，NetEQ 中采用遗忘因子对直方图中的历史数据进行遗忘。当然，NetEQ 所提供的是一个综合的音频 QoS 保障技术，还有许多其他的技术参与处理音频抖动，如峰值抖动检测、语音变速等，这里不再详述。

视频抗抖动方面，WebRTC 采用不同于音频的抖动延时估计算法，通过对实际的帧尺寸变化与延时变化数据的测量与统计，利用卡尔曼滤波器动态地进行最优抖动延时估计。

然而，WebRTC 主要为一对一实时沟通的应用场景设计，在如视频会议等一对多、多对多场景下，音视频流更多的是通过流媒体中转服务转发。通过实测，该算法对多节点转发场景下的全链路抖动延时估计效果有待改进。

腾讯云实时音视频 TRTC 的弱网对抗技术优化实践

TRTC 在抗弱网能力方面表现突出，其核心技术优化和实际测试数据均体现了在复杂网络环境下的高性能表现。以下是其抗弱网能力的详细分析：

1）音频抗弱网能力

● 高丢包与高抖动容忍度

○ 在 50%丢包率的下行场景中，TRTC 音频 MOS 值（主观语音质量评分）可达 4.485（Android 到 iOS）和 4.5（iOS 到 iOS），延迟分别为 856.9ms 和 805.7ms，显著优于竞品。

○ 即使在 70%丢包率的极端条件下，TRTC 仍能保持 MOS 值 4.03（下行）和 4.08（iOS 到 iOS），延迟控制在 552ms 以内。

○ 对于混合损伤场景（如 55%丢包+1200ms 抖动），MOS 值仍维持在 3.59 以上，延迟约 1570ms，表现稳定。

● 低延迟优化

○ 在正常网络环境下，TRTC 音频延迟可低至 189ms（Android 到 iOS）。

○ 采用自研的 cFEC（前向纠错）和 cPLC（丢包补偿）技术，结合私有 UDP 协议，减少弱网对实时通话的影响。

2）视频抗弱网能力

● 复杂网络场景下的表现

○ 场景 1（600kbps 带宽+10%丢包+100ms 延迟）：TRTC 视频秒开速度与清晰度均优于竞品，尤其适合实际受限网络环境。

○ 场景 2（50%丢包+200ms 延迟）：TRTC 在视频清晰度和流畅度上显著领先，分辨率与帧率更稳定。

○ 场景 3（下行 50%丢包）：TRTC 通过动态编码参数调整（如高 Profile 编码）保障画面质量，清晰度优势明显。

● 极限网络抗性

○ 支持上行 55%丢包+1200ms 抖动和下行 70%丢包+1700ms 抖动，仍能保持流畅通话。

○ 在混合损伤条件（如 40%丢包+800ms 抖动）下，视频通话最低带宽需求仅需 250kbps。

3）核心技术优化

● 传输层优化

○ 采用私有 UDP 协议，结合智能 QoS 算法，精准识别网络状态并动态调整码率、帧率等参数。

○ 支持高 Profile 编码和高性能模式，降低内存与 CPU 占用，提升弱网下的编码效率。

● 跨平台一致性

○ iOS 设备在相同分辨率下内存占用显著低于 Android，优化资源利用效率。

○ 客户端 SDK 在 1v1 通话场景中，CPU 占用率仅 0.11%~0.13%，内存占用低至 64MB（iOS）。

4）性能数据总结

TRTC 通过自研协议、动态编码优化及混合云部署，在极端弱网环境下仍能保障音视频的高质量与低延迟，适用于金融、教育、直播等高要求场景。如果您需要更详细的测试参数和技术细节，或想要快速创建高质量的音视频应用，欢迎前往腾讯云官网（实时音视频_腾讯RTC_低延时互动直播_音视频通话-腾讯云）了解更多详细内容。