揭秘|智慧树千万师生“停课不停学”背后的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服务。