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码流适配、大小流码流适配等，如下图所示：
典型拥塞操控结构
典型的拥塞操控算法结构如下图所示：
这是前期 Google 在其 WebRTC 结构中选用的拥塞操控结构。选用发送端和接纳端混合操控模式，发送端选用根据丢包的算法，根本战略如下：
- 丢包率<2%，添加发送带宽 8%；
- 丢包率 2% ~ 10%，发送带宽保持不变；
- 丢包率>10%，下降发送带宽（1-0.5*丢包率）。
接纳端选用根据延时的算法。经过核算单向延时改变并经过卡尔曼滤波对当时的传输延时进行估量，再结合当时的实际接纳带宽评价一个最佳的目标带宽，经过 RTCP 消息反馈给发送端。发送端取两个算法成果的最小值作为终究的目标带宽。
下图是 WebRTC 改善后的拥塞操控结构。
咱们能够看到整个拥塞操控机制都在发送端完成，接纳端仅仅反馈相应的丈量数据。
新的结构改善了网络延时估量算法，经过对单向延时改变数据进行线性回归剖析，评价当时网络排队延时改变趋势，即判别出延时正在添加、没有改变、正在下降三种趋势，再结合当时发送速率，给出最佳目标带宽估量。 除了改善拥塞勘探算法，新的结构也引进了主动带宽勘探机制，优化了整个拥塞操控算法的性能，经过比较，在启动阶段收敛速度、网络环境改变的响应速度上都有比较显着的改善。
丢包问题
如前所述，实时交互式媒体传输根据 RTP/UDP 协议，丢包问题由运用层处理。
网络传输方面（即信道侧）的抗丢包技能手段首要包含重传（ARQ）、前向 纠错（FEC） 。信源编码方面根据数据以及编码方的不同也能够供给某些特定的抗丢包才能，比方视频编码中选用 B 帧下降丢包的影响。下面首要介绍网络传输方面的抗丢包技能。
丢包重传（ARQ）
在 RTP/RTCP 协议中，丢包重传技能简略来讲便是接纳端根据包序列号的连续性判别是否丢包，经过向源端发送 RTCP 中的 NACK 恳求，要求源端重传指定的数据包。丢包重传流程如下图所示：
重传流程有以下细节需求考虑：
-
首次恳求延时： 应结合其他战略考虑发现丢包时是否当即恳求，比方结合FEC 战略考虑。
-
重复恳求距离考虑： 同一个数据包重复恳求距离要大于当时 RTT。
-
恳求次数约束： 结合当时 RTT 与容忍的最大延时来核算。
-
发送端重传带宽约束： 重传带宽作为总传输带宽的一部分，不能超出总体带宽约束。
-
重传包回传机制： 主张选用独自的 RTP 码流发送，利于丢包率核算与重传带宽核算。
前向纠错（FEC）
在实时音视频运用中，前向纠错（FEC）技能在抗丢包方面因其实时性好而被广泛运用。 FEC 的根本思路粗略来讲便是发送端在发送音视频数据包之外，根据具体丢包情况再额定发送必定量的冗余数据包用于接纳端进行丢包康复，根本流程如下图所示：
现在常用的关于修正数据包的编码算法有根据异或的算法、根据矩阵的算法以及其他算法，本文不做具体阐述。
下面介绍一下 FEC 在实时音视频系统中的根本运用结构，发送端运用结构如下图所示：
上图中的 ADU 为运用数据单元，在音视频 RTC 系统中也便是音视频数据包，作为源数据块输入到 FEC 编码器，FEC 编码器根据必定的修正比率产生 FEC 修正包（repair payloads），修正包和源包及其之间维护联系一同发送给接纳端。
接纳端的 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 独自担任丢包修正。
颤动问题
归纳而言，颤动问题便是网络传输延时改变问题，颤动越大表示网络传输延时改变越大。
颤动问题会形成接纳端卡顿、播放快进等严峻影响音视频交流体会的问题。形成颤动问题的原因是多方面的，比方新的流加入形成网络资源竞赛加剧、源端数据发送速率自身不平稳以及其他网络原因。
现在处理颤动的通用战略是接纳端建立颤动缓冲区(JitterBuffer)来消除颤动，其原理如下图所示：
接纳端经过添加颤动延时（JitterDelay）来吸收不均匀的延时，抵达均匀播放的目的。 其间，颤动延时大小的核算是颤动缓冲区性能好坏的要害，过大的颤动延时会引进额定延时，这在实时交互式运用范畴是极力要防止的；过小又无法吸收全部的颤动。
关于颤动延时的估量，Google 在其 WebRTC 结构顶用了两种办法，在音频颤动处理顶用直方图加忘记因子的方法进行估量，如下图所示：
WebRTC的音频颤动延时估量在其内部的 NetEQ 模块中，图中的 Iat 意为距离抵达时间，WebRTC 经过对音频包抵达距离用直方图进行核算，取 95 分位数的延时时长作为音频颤动延时。 为了跟踪延时改变，NetEQ 中选用忘记因子对直方图中的历史数据进行忘记。当然，NetEQ 所供给的是一个综合的音频 QoS保证技能，还有许多其他的技能参与处理音频颤动，如峰值颤动检测、语音变速等，这里不再详述。
视频抗颤动方面，WebRTC 选用不同于音频的颤动延时估量算法，经过对实际的帧尺度改变与延时改变数据的丈量与核算，利用卡尔曼滤波器动态地进行最优颤动延时估量。
然而，WebRTC 首要为1对1实时交流的运用场景规划，在如视频会议等一对多、多对多场景下，音视频流更多的是经过流媒体中转服务转发。经过实测，该算法对多节点转发场景下的全链路颤动延时估量效果有待改善。
融云的弱网对立技能优化实践
融云的优化办法
-
拥塞操控方面，根据 Google GCC 算法进行改善。除了核算单向延时改变进行拥塞趋势判别之外，一同对丢包模式进行进一步剖析，提高带宽预测的精确率。
-
抗丢包方面，根据 FlexFEC 结构，选用高修正才能的 FEC 编码，并进行综合调优来提高抗丢包才能。
-
优化 ARQ 与 FEC 机制的合作，力求抗丢包支付的价值最小。
-
抗颤动方面，选用场景适应性更强的颤动延时估量办法，力求提高流通度的一同减少延时。
部分成果
下图展示了现在高丢包场景下弱网抗性测验成果。
在 60%、70% 的高丢包场景下，Android 和 iOS 移动端测验成果在流通度方面 MOS 值仍能够抵达 4 分。 在具体弱网优化过程中，因为网络的杂乱性、异构性，以及场景需求的多样性，实时音视频传输战略与弱网对立技能充满着各种挑选、平衡与取舍的考量，新的根据在线学习、强化学习的技能思路也在该范畴开端进行尝试。
咱们也将持续探究实践，为提高融云实时音视频 RTC 产品的综合用户体会而不断努力。
