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