共计 5896 个字符，预计需要花费 15 分钟才能阅读完成。
Hi~ 这里是 25 万 + 社交，泛娱乐，出海开发者青眼的寰球互联网通信云·融云若你对国产化，协同办公解决方案感兴趣，欢送关注本号的【兄弟号】关注【融云 RongCloud】，理解协同办公平台更多干货。
明天，你刘畊宏女孩了吗？关注【融云寰球互联网通信云】理解更多
继续大热的“李佳琦女生”和近期大势的“刘畊宏女孩”都在证实着，直播行业仍然热度不减。通过多年倒退，直播曾经衍生出了越来越丰盛的玩法，比方连麦 PK、一起看等。而这些场景，都十分依赖 RTC 实时音视频技术的衰亡。
疫情重复，很多人又进入了居家时刻。把生存和工作转向线上成为大家反抗“停摆”焦虑的解决方案。除了直播、语聊房等娱乐社交场景，还有线上课堂、视频会议，乃至线上问诊征询。
在咱们把娱乐、社交和生存的方方面面搬到线上的过程中，RTC 实时音视频技术迅速倒退，一直打卡新利用，浸透新场景。
一体两面，当先进技术为线上场景带来微小增长的同时，也面临用户越来越高的体验要求，更低延时、更高画质、更加顺畅。
这三个用户体验的影响因素，对应着的也是 RTC 的三大外围指标，即实时性、清晰度、晦涩度。
三者之间，往往鱼与熊掌不可兼得。实时性要求较高的场景可能会就义清晰度来保障低延时；而清晰度要求高的场景则可能用肯定的延时换取高质量的音视频数据。
然而，小孩子才做抉择。为了做到“既要又要”，咱们通常须要通过网络传输优化来谋求更低的延时、更高的清晰度和流畅性。其中的大 BOSS 就是弱网，这是造成拥塞、丢包、延时抖动等影响用户体验问题的次要因素。
弱网反抗技术就是针对上述问题以及其余网络伤害问题的技术解决方案统称。本文分享 RTC 零碎音视频传输弱网反抗技术概览。
对于 TCP/IP 传输层协定的抉择
首先，简要介绍一下传输层协定。
传输层协定在 TCP/IP 分层协定中位于应用层之下，个别由操作系统外部提供实现，包含 TCP 和 UDP 两种协定。TCP 是面向连贯的牢靠传输协定，为数据传输的完整性和有序性提供了保障；UDP 是无连贯的不牢靠传输协定，数据传输的可靠性齐全交由应用层解决。
实时音视频利用场景下，UDP 作为优先选择曾经是业界宽泛共识。起因次要包含以下几点：
TCP 协定并非为音视频实时利用场景设计，其外部的拥塞管制和差错控制等机制为了可靠性和高吞吐量而导致延时的减少，在弱网环境下延时的好转更为显著。ITU StandardG.114 对延时的定义是，端到端延时大于 400ms 时，用户的交互体验将受到显著的影响。
TCP 的拥塞管制机制和差错控制机制位于操作系统外部实现，应用层无奈优化，无奈应答不同场景需要进行调整，重大不足灵活性。
UDP 协定自身开销比 TCP 小，传输控制策略齐全交由应用层来实现，具备足够的灵活性。
因而，本文后续探讨的弱网问题及相应的弱网反抗技术基于 UDP 协定以及运行在 UDP 之上的被音视频畛域广泛应用的 RTP/RTCP 协定来探讨。
弱网次要问题及其反抗技术
音视频传输弱网问题简略来说就是指影响音视频通信用户体验的网络环境问题，次要指网络拥塞、网络丢包、抖动等问题。
这些问题是造成音视频卡顿、实时性不佳的次要起因。因为网络环境具备较强复杂性、异构性，上述的弱网问题在不同环境下的重大水平也有很大差别。如何保障用户在简单网络环境下进行顺畅的沟通，始终是 RTC 畛域关注的重点问题。
拥塞问题
当网络中传输的数据流量超过网络瓶颈容量，就会产生拥塞问题。
拥塞的间接影响是突发丢包或者突发抖动，如果不及时预测拥塞的产生，及时升高发送数据量，接收端将会呈现卡顿、延时大、画质差等等问题。
反抗拥塞问题的次要计划是，通过设计拥塞控制算法对网络拥塞进行及时的探测，并从拥塞状态尽可能快地复原，尽量升高对用户体验的影响。
拥塞控制算法的需要思考
RFC8836 对实时交互式音视频利用的拥塞控制算法需要进行了较为全面的总结，简略概括如下：
- 延时：拥塞控制算法应该尽可能升高延时，尤其是算法自身引入的延时。与此同时依然须要提供可用的带宽程度。
- 吞吐率：在相应场景下吞吐率应尽可能高。
- 公平性：拥塞控制算法应该可能和其余实时流量和 TCP 流量偏心地共享链路带宽。
- 防止“饿死”：媒体流在与 TCP 流竞争中不应被“饿死”，也不能把 TCP 流“饿死”。
- 收敛速度：在媒体流启动阶段尽可能快地收敛到稳固状态。
- 网络反对：算法不应要求非凡网络个性反对。
- 稳定性：算法应该在媒体流变动时保持稳定，比方媒体流临时的传输中断。
- 疾速响应：算法应该疾速响应网络环境的变动，比方瓶颈带宽变动、链路延时变动等。
综合上述需要，拥塞控制算法要解决的问题可归类为两个方面，一是 如何疾速精确地进行网络拥塞探测 ；二是 采取适当的拥塞应答措施尽量避免拥塞以及尽可能快地从拥塞状态复原。
拥塞探测算法
拥塞探测算法依据观测数据的差别可用分为两类：
基于丢包的算法（Loss-based）：通过丢包事件来检测网络拥塞。
基于延时的算法（Delay-based）：通过对延时的测量来判断网络拥塞。
对于实时音视频交互式利用，基于延时的算法是更优的抉择，次要起因是基于延时的算法可能更早地发现网络拥塞，从而防止因为拥塞导致的丢包。
此外，基于丢包的算法往往为了探测链路容量而一直减少发送带宽，直至丢包事件产生。这种策略将导致无法控制的网络排队延时增长，尤其是网络节点的缓冲区较大时，甚至造成秒级延时的增长。
抉择基于延时的算法要重点思考需要总结中的 防止“饿死”问题。基于延时的算法对延时增长绝对要敏感，在与基于丢包的算法竞争网络资源时要采取适当的策略，绝对偏心地分享网络带宽资源。
基于延时的算法个别通过测量 RTT（round-trip time 往返延时）或者 OWD（one-way delay 单向延时）来判断拥塞。
RTT 测量比拟直观，然而因为是测量双向延时的总体状况，因而反向的延时变动会对媒体流方向的网络拥塞判断造成烦扰。OWD 延时观测则防止了这个问题。如下图所示：
（单向延时变动）
OWD 通过观测发送距离与接管距离的变动来判断网络排队延时的情况。
拥塞应答措施
简而言之，拥塞应答措施就是依据网络以后的拥塞情况计算出适合的发送速率来管制媒体发送端的总发送速率。依据发送端所采取的其余弱网反抗策略，可能的速率调节伎俩包含调节音视频编码器速率、调节重传速率、调节 FEC 冗余度等，详见本文后续介绍。如果发送端是两头转发节点，则调节伎俩还包含 SVC 码流适配、大小流码流适配等，如下图所示：
（SVC 码流散发示意图）
典型拥塞管制框架
典型的拥塞控制算法框架如下图所示：
（WebRTC 拥塞管制架构 1）
这是晚期 Google 在其 WebRTC 框架中采纳的拥塞管制框架。采纳发送端和接收端混合管制模式，发送端采纳基于丢包的算法，根本策略如下：
- 丢包率 <2%，减少发送带宽 8%；
- 丢包率 2% ~ 10%，发送带宽放弃不变；
- 丢包率 >10%，升高发送带宽（1-0.5* 丢包率）。
接收端采纳基于延时的算法。通过统计单向延时变动并通过卡尔曼滤波对以后的传输延时进行预计，再联合以后的理论接管带宽评估一个最佳的指标带宽，通过 RTCP 音讯反馈给发送端。发送端取两个算法后果的最小值作为最终的指标带宽。
下图是 WebRTC 改良后的拥塞管制框架。
（WebRTC 拥塞管制架构 2）
咱们能够看到整个拥塞管制机制都在发送端实现，接收端只是反馈相应的测量数据。
新的框架改良了网络延时预计算法，通过对单向延时变动数据进行线性回归剖析，评估以后网络排队延时变化趋势，即判断出延时正在减少、没有变动、正在升高三种趋势，再联合以后发送速率，给出最佳指标带宽预计。
除了改良拥塞探测算法，新的框架也引入了被动带宽探测机制，优化了整个拥塞控制算法的性能，通过比拟，在启动阶段收敛速度、网络环境变动的响应速度上都有比拟显著的改良。
丢包问题
如前所述，实时交互式媒体传输基于 RTP/UDP 协定，丢包问题由应用层解决。
网络传输方面（即信道侧）的抗丢包技术手段次要包含重传（ARQ）、前向纠错（FEC）。信源编码方面依据数据以及编码方的不同也能够提供某些特定的抗丢包能力，比方视频编码中采纳 B 帧升高丢包的影响。上面次要介绍网络传输方面的抗丢包技术。
丢包重传（ARQ）
在 RTP/RTCP 协定中，丢包重传技术简略来讲就是接收端依据包序列号的连续性判断是否丢包，通过向源端发送 RTCP 中的 NACK 申请，要求源端重传指定的数据包。丢包重传流程如下图所示：
（丢包重传流程）
重传流程有以下细节须要思考：
- 首次申请延时：应联合其余策略思考发现丢包时是否立刻申请，比方联合 FEC 策略思考。
- 反复申请距离思考：同一个数据包反复申请距离要大于以后 RTT。
- 申请次数限度：联合以后 RTT 与容忍的最大延时来计算。
- 发送端重传带宽限度：重传带宽作为总传输带宽的一部分，不能超出总体带宽限度。
- 重传包回传机制：倡议采纳独自的 RTP 码流发送，利于丢包率统计与重传带宽计算。
前向纠错（FEC）
在实时音视频利用中，前向纠错（FEC）技术在抗丢包方面因其实时性好而被广泛应用。
FEC 的基本思路粗略来讲就是发送端在发送音视频数据包之外，依据具体丢包情况再额定发送一定量的冗余数据包用于接收端进行丢包复原，根本流程如下图所示：
（FEC 解决流程，其中 D 为数据包，C 为修复包）
目前罕用的对于修复数据包的编码算法有基于异或的算法、基于矩阵的算法以及其余算法，本文不做具体论述。
上面介绍一下 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 编码包格局。
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 独自负责丢包修复。
（ARQ 与 FEC 机制配合）
抖动问题
概括而言，抖动问题就是网络传输延时变动问题，抖动越大示意网络传输延时变动越大。
抖动问题会造成接收端卡顿、播放快进等重大影响音视频沟通体验的问题。造成抖动问题的起因是多方面的，比方新的流退出造成网络资源竞争加剧、源端数据发送速率自身不安稳以及其余网络起因。
目前解决抖动的通用策略是接收端建设抖动缓冲区 (JitterBuffer) 来打消抖动，其原理如下图所示：
（抖动缓冲原理）
接收端通过减少抖动延时（JitterDelay）来排汇不平均的延时，达到平均播放的目标。
其中，抖动延时大小的计算是抖动缓冲区性能好坏的要害，过大的抖动延时会引入额定延时，这在实时交互式应用领域是竭力要防止的；过小又无奈排汇全副的抖动。
对于抖动延时的预计，Google 在其 WebRTC 框架中用了两种办法，在音频抖动解决中用直方图加忘记因子的形式进行预计，如下图所示：
（NetEQ 抖动延时统计）
WebRTC 的音频抖动延时预计在其外部的 NetEQ 模块中，图中的 Iat 意为距离达到工夫，WebRTC 通过对音频包达到距离用直方图进行统计，取 95 分位数的延时时长作为音频抖动延时。
为了跟踪延时变动，NetEQ 中采纳忘记因子对直方图中的历史数据进行忘记。当然，NetEQ 所提供的是一个综合的音频 QoS 保障技术，还有许多其余的技术参加解决音频抖动，如峰值抖动检测、语音变速等，这里不再详述。
视频抗抖动方面，WebRTC 采纳不同于音频的抖动延时预计算法，通过对理论的帧尺寸变动与延时变动数据的测量与统计，利用卡尔曼滤波器动静地进行最优抖动延时预计。
然而，WebRTC 次要为一对一实时沟通的利用场景设计，在如视频会议等一对多、多对多场景下，音视频流更多的是通过流媒体直达服务转发。通过实测，该算法对多节点转发场景下的全链路抖动延时预计成果有待改良。
融云的弱网反抗技术优化实际
融云的优化措施
- 拥塞管制方面，基于 Google GCC 算法进行改良。除了统计单向延时变动进行拥塞趋势判断之外，同时对丢包模式进行进一步剖析，晋升带宽预测的准确率。
- 抗丢包方面，基于 FlexFEC 框架，采纳高修复能力的 FEC 编码，并进行综合调优来晋升抗丢包能力。
- 优化 ARQ 与 FEC 机制的配合，力求抗丢包付出的代价最小。
- 抗抖动方面，采纳场景适应性更强的抖动延时预计办法，力求晋升晦涩度的同时缩小延时。
局部后果
下图展现了目前高丢包场景下弱网抗性测试后果。
（高丢包场景测试后果）
在 60%、70% 的高丢包场景下，Android 和 iOS 挪动端测试后果在晦涩度方面 MOS 值仍能够达到 4 分。
在具体弱网优化过程中，因为网络的复杂性、异构性，以及场景需要的多样性，实时音视频传输策略与弱网反抗技术充斥着各种抉择、均衡与取舍的考量，新的基于在线学习、强化学习的技术思路也在该畛域开始进行尝试。
咱们也将持续摸索实际，为晋升融云实时音视频 RTC 产品的综合用户体验而一直致力。