揭秘|智慧树千万师生“停课不停学”背后的URTC技术实践之路 | U刻
技术分享/

揭秘|智慧树千万师生“停课不停学”背后的URTC技术实践之路

  • 揭秘|智慧树千万师生“停课不停学”背后的URTC技术实践之路

    栏目:技术分享

    ​受疫情影响,在线教育迎来爆发式增长。智慧树作为教育部推荐的线上教学平台之一,为全国近2000所高校、30余万老师、1000多万大学生提供在线课程内容、在线教学平台以及全流程教学服务。自2020年4月开始, UCloud URTC实时音视频产品被智慧树正式接入使用,为其提供从音视频的采集、处理、编解码、传输以及云端的转码混流等系统服务。基于UCloud在全球部署的31个可用区、29条专线、500+加速节点,URTC可提供平均300ms的低延时稳定流畅的师生线上课程体验,且支持百万人级别的超高并发能力。


    为充分保障智慧树在线课堂的师生实时互动流畅体验,URTC在底层网络传输技术上做了大量的网络优化工作,通过全球就近接入点接入、自研HTTPDNS调度算法、丢包重传,实现了弱网高质量通信,即使在30%丢包下视频仍然流畅、70%丢包下音频仍可正常通信。


    接下来,本文将重点介绍URTC在解决网络传输路径、网络拥塞、丢包等问题过程中的质量优化实践之路。

    URTC 传输路径优化

    上图是URTC 媒体服务集群简单架构图,URTC通过服务器全球化部署,实现用户就近接入,下面着重介绍URTC在网络传输路径方面的优化实践。
    接入点选择传统直播经常采用DNS进行接入点的分配,DNS一是解析比较慢,第二是面临劫持的问题,并不能很好的进行接入。URTC采用Http-DNS进行接入点的选择和分配,为了保障请求的效率和准确性,URTC会同时向几个地址进行Http-DNS 地址请求,同时我们针对用户的历史接入数据对于大运营商联通、电信、移动会通过历史记录比对的方式进行分配,加快接入数据,非大运营商则采用ping 速的方式进行动态探测,并通过延时丢包进行拟合算法判断,判断最优接入点。
    传输的链路管理和分配

    我们采用一个中心式的路由管理系统,所有的relay节点都是对等的,不同中心的relay 节点进行相互连接,组成一张图,图中各点的连接平分为路径权重,转发控制中心通过实时计算规划最优路径,在用户请求时进行路径分配,并对传输的路径进行相应的监测,在故障时进行链路的切换。
    数据中心之间传输数据中心之间我们采用自研基于UDP的私有协议进行传输,降低数据中心之间的传输延时,并提高数据中心之间的传输吞吐量。
    通过上面的三个优化方案,URTC有效解决了用户就近接入、传输路径分配、故障转移等传输路径的问题,但是在传输中我们还面临传输数据内容的质量保障,尤其是用户的“最后一公里”。因此我们进一步对传输内容的质量问题进行了相关优化,主要解决网络拥塞和丢包恢复。

    URTC 传输质量优化

    一、网络拥塞算法优化

    目前有很多种解决网络拥塞的算法,比如CUBIC、LEBAT、SCReAM、BBR、GCC、PCC等,这些算法大体可以分为3个方向:基于丢包、基于延时和基于机器学习。URTC采用了GCC 算法,并结合不同的使用场景进行了相应的优化:

    • 直播转推场景

    直播转推场景,URTC 主要完成用户的上行推流任务,同时由于在转推场景中,用户对于延时(800ms — 2s)不是很敏感,但是对于传输内容的质量有比较高的要求,因此URTC 在此场景中更偏向于质量保证,而对抖动的敏感度下降。于是我们将 URTC的GCC 算法退化成基于丢包的拥塞控制算法,目标是在用户可接受的延时内尽量保证推流的质量。

    • 连麦场景

    连麦场景中强调实时的交互性,用户对于延时(低于400ms)的敏感度比较高,因此算法需要对网络的变化有更好的适应性,以保障更好的实时性。这里URTC的GCC 算法对抖动和延时的敏感度上升,我们便将其优化为基于延时的拥塞算法。

    二、丢包恢复方案

    再说到丢包问题,丢包产生原因包括传输通道误码、无线网络通信不稳定、信号衰减干扰、网络拥塞、数据包没有按时到达、系统抖动等。这里有几点必须强调下,由于RTC的目标是极低延时,因此我们在定义丢包的含义时,要考虑延时到达和抖动过大这两种情况。这两种情况下,采样值过大的样本在RTC中也应该定义为丢包,有了明确的丢包定义之后,才能对症下药解决丢包问题。

    传统抗丢包算法

    传统的的对抗丢包算法主要包含NACK(丢包重传请求)、FEC(前向纠错)、ACK(应答确认)。

    • NACK

    NACK是对没有收到的数据进行主动的传输请求,这样可以做到比较精确的丢包重传请求,但是NACK也会带来一些问题:
    1.太密集的NACK 请求容易形成大量的重传风暴,重传的成功率偏低,浪费带宽;2.即便重传不密集,但是当丢包率过大时,丢包重传请求以及传输反馈投递到源端的成功率也在降低,即反馈包也在面临丢包的问题;3.NACK必定带来额外的延时,最理想的情况下引入一个RTT 的延时;4.假设多人场景NACK 会大量吃掉用户的带宽,从而造成网络传输的波动。

    • FEC

    FEC 本质是通过冗余数据,比如最简单的冗余算法应该是数据倍数发送,一般可以设置3倍,来提高数据的正确完整到达,FEC算法有很多:异或计算、RS-FEC、喷泉码等等。FEC 好处是可以通过冗余数据减少端到端的时延,但是同时也带来额外的问题:1.FEC 会带来额外的冗余带宽消耗,控制不好将会带入更严重的拥塞和丢包问题;2.在多人场景中FEC包的过度转发也会引起观看用户的过度带宽消耗。

    • ACK

    ACK是通过对已经发送的数据进行相关的确认,发送端根据确认的序号,判断是否进行数据的重发或者新数据的发送,ACK目前是一种应用比较普遍的算法,但是为了提高网络效率,ACK 通常会采用合并确认或者延时确认的方案,这会引入额外的延时。

    URTC技术优化

    综合上述传统抗丢包算法的优缺点,URTC在丢包恢复算法上采用了NACK+FEC+ARQ的算法方案,但是在具体的实现上还做了很多技术优化。主要包括:

    • 上行推流端

    通过3种算法的动态智能联动,URTC可动态调整重传和冗余数据比例,当低丢包低RTT时,通过NACK 进行数据的的恢复;当高丢包低RTT时,且长时间没有收到反馈包,远端会自动进行动态的调整,调整冗余数据、重传数据和实际媒体数据的比例,进而得出新的目标码率;当高RTT 低丢包以及高RTT高丢包时,NACK 将被关闭,只进行FEC 的使用,当然FEC比例增加的同时,远端数据也会进行相应的降低。

    同时针对音频敏感场景,URTC会保证音频的首先传输,在出现竞争时视频质量逐渐降低直至挂起,以保证音频质量。

    • 服务端

    在服务端,URTC针对每个用户做了一个缓冲窗口。传统的媒体服务器一般采用纯转发的方式,由客户端进行相应的丢包和拥塞控制,这样带来的问题是在网络抖动时,服务端不能感知网络的变化,进而更早的发现拥塞。因此URTC 在服务端设计了一个网络拥塞模块,主要作用是感知网络状态,对抗网络抖动,减轻网络抖动引起的瞬间丢包和重传风暴。
    针对网络不好的终端用户,URTC采用先通知远端降低码率,码率达到下限,在缓存窗口进行数据的丢弃,以保证接收端的低延时。同时针对不同网络情况用户,服务端也根据当前网络状态进行冗余数据的下发。
    目前缓存窗口采取单一存储,每个只记录自己当前读取的位置,以减轻内存压力。

    • 下行拉流端

    URTC采用抖动缓冲策略去抖动,并采用智能播放策略,获取区采用状态机策略,分为填充、播放、慢放、等待、快放等,根据不同的状态机,对数据进行不同的处理逻辑,以此保证数据播放平稳和延时,同时NACK 变为和RTT相关的策略,根据投递的成功率进行投递间隔的改变,防止NACK 投递引起的重传风暴和带宽浪费。

    总结

    通过本文介绍的一些质量工程优化和算法工程优化,URTC将音频抗丢包能力从20%提高到70%,视频上行抗丢包从20% 提高到30%。未来,URTC还将不断优化提升实时音视频服务的稳定、低延时、流畅性,致力于为更多企业和开发者提供高质量、高可靠的SDK服务。