直播新架构升级:全量支撑淘宝双11直播

简介: 淘宝直播最近连续三年直播引导成交大幅增长,2020年以来,有100多种职业转战淘宝直播间,无论达人身份还是商家身份,都在新风口的驱动下大量入场。如何应对双十一这种高峰值用户直播需求,这无疑对淘宝直播提出了更高的技术要求和挑战。同时,电商直播有强互动诉求,主播对弹幕的回复越及时,对购买越有促进效果。

淘宝直播最近连续三年直播引导成交大幅增长,2020年以来,有100多种职业转战淘宝直播间,无论达人身份还是商家身份,都在新风口的驱动下大量入场。如何应对双十一这种高峰值用户直播需求,这无疑对淘宝直播提出了更高的技术要求和挑战。同时,电商直播有强互动诉求,主播对弹幕的回复越及时,对购买越有促进效果。


通过AB测试验证,延时对电商直播GMV有正向作用。但常规的HLS、FLV、RTMP等直播格式延时很难再降低,常规直播CDN也已经不再适合更低延时的直播,整个技术体系需要升级。为了降低直播延时,行业上有几种做法:

image.png

LHLS、CMAF甚至LLHLS方案的延时,基本都会超过2秒,暂不做比较。综合考虑,WEBRTC方案相对符合我们的需求。淘系技术部跟阿里云一起共建了一张基于WEBRTC低延时多媒体传输网。


通信、直播二网合一的低延时传输网

直播的延时始终是个老大难问题,很多团队都在考虑怎么降低延迟。低延迟传输是一个综合性的问题,要从整体入手,不仅要从设计上考虑,还需要客户端,服务器,数据系统紧密配合。最根本的传输协议不升级,延迟始终有一个天花板。

image.png

RTCP协议头

对于传统的rtmp,hls,http-flv基于tcp的协议来讲,tcp是可靠传输,在弱网下一定会等某些数据到达才能继续。但是对于音视频数据而言,有些数据是可以丢的,比如不被参考的帧。此外tcp的拥塞控制在内核层,在拥塞发生时,滑动窗口直接减半,造成数据吞吐量低。同时缺乏应用层控制,对于音视频场景不灵活,准确度低。还有tcp有重传聚合的功能,造成数据确认慢,延迟增大。


基于tcp这些原因,传统的播放器都会有5s以上的buffer来对抗网络抖动。所以常规的音视频通信基本都不使用TCP协议来实现,而使用UDP实现。


直播在降低延时后,在传输上也有很多跟通信相似的地方,方案上可以一并考虑。基于udp的webrtc半可靠传输,技术成熟,更加适合音视频场景。从信令设计上采用rtcp app私有协议,rtcp标准交互兼容,和音视频传输使用一个socket连接。建联协议更加精简,保证最快1RTT给出媒体数据,快速启播。


image.png

GRTN的设计理念是用通信的技术来传递直播多媒体数据,技术是一个技术,因此自然而然可以实现一张网同时支持音视频通信和直播两种业务。


统一架构后,只有一套代码,一套运维体系,减少维护成本。多种业务放到一起,每种业务的带宽峰值不同,加起来的整体峰值低于各个业务峰值之和,运营商对我们的带宽计费通常是看峰值或95峰,多个业务峰值错开后,成本也会有相应下降。未来规划点播、文件分发也都放到这张网里,起到更大的错峰降成本的效果。


在CDN下行的边缘节点上,实现协议转换,转成RTC协议,也能实现低延时直播。这是目前市面上较先进的系统实现低延时直播的思路。


然而,GRTN不仅仅是下行播放切换成RTC协议,而是全链路的RTC协议。全链路RTC也能解决主播侧的最后一公里质量问题,以及抗服务器间丢包,提升质量。降低了中间协议转换带来的损失,从而实现更低的传输延时。实现全链路RTC后,拥塞控制可以做到端到端,例如端到端的FEC抗丢包、大小流切换、SVC/丢GOP等策略一起配合,提升用户体验。而端到端低延时RTC传输后,观众连麦就变得非常简单,只需要观众侧再上行一路流,主播拉下来播放,即可实现连麦。


另外,有同学可能会问,端到端RTC系统,跟传统的会议系统有什么区别?这里区别在于,传统会议系统通常部署在中心机房,接入节点少,GRTN直接部署在CDN上,通过全球覆盖提升质量。


GRTN第三个特点是去中心化架构,动态路径规划。做直播CDN的同学都会有个很深的印象,小主播很多时,回源带宽是非常昂贵的。小主播由于命中率低,回源比例高,有些情况需要超过50%的带宽到L2(中间源)回源,产生大量的成本。


同时,由于L2(中间源)和中心机房的保障比L1(边缘节点)好,带宽价格通常高于L1,让回源带宽更加昂贵。各个直播CDN都在想方设法降低回源带宽,包括使用302重定向、建立冷流集群等等,但到L2回源是无法避免的。去中心化架构就是回源路径可以不经过L2或中心机房,直接从L1出,减少传输路径,不仅大大减少回源成本,还能提升传输质量。配合动态路径规划,寻找成本、质量之间的最优解。由于音视频流不是必须经过中心,中心故障带来的影响也就大大减小了。


GRTN大部分模块是各个业务相互通用的,但也有一些内容需要各个业务定制。业务定制主要包括三块:客户端、拥塞控制及传输策略、流媒体编辑。这三块在设计上都有统一的接入接口设计。跟传输质量相关性最大的,主要是拥塞控制及传输策略。


适配业务的拥塞控制算法

深度定制:强网推流稳定性

深度强网优化。首先,给出强网判定,针对强网用户提高推流画质稳定性,控制码率避免因偶然的丢包和延迟而降低;另外,优化 AIMD 的码率调控算法,快上慢下,提高强网带宽利用率;最后,限制弱网范围,原生的拥塞控制算法对于延迟的抖动过于敏感,平滑其调控码率的策略。

image.png

系统寻找最优解:自学习的参数优化

常规音视频传输优化,通常是需要专业的人才根据经验值调优,对人才的要求很高。但我们可以将人才调优的过程,由系统自动来实现。系统性调优 WebRTC 中拥塞控制算法的理论默认值,基于先验知识的参数范围梳理,赋能参数配置,基于先验知识的分批次参数探测,多角度评价算法设计。通过不断迭代,寻找拥塞控制参数的最优解。参数自学习系统带来的好处还包括,当环境变化时,系统可以自动更新最优解,而专业人才的经验,很难这么快速的适应新的环境。在推流端使用了自学习的参数优化后,推流卡顿率总体下降 40%,延迟下降 12% 。

image.png


前沿探索:基于强化学习的拥塞控制

受学术界最新研究方向 Pensieve[1] 的启发,我们和北京邮电大学合作,定制淘宝直播基于强化学习的拥塞控制算法,自研与传统拥塞控制算法相结合的策略,在平稳网络中,保持带宽利用率不降的情况下,可以降低 20% 的延迟,以及约 25% 的卡顿。

淘宝直播对于该方向的研究成果,已经受到学术界认可,连续两年在网络方向顶级会议 MobiCom 上发表论文(Concerto[2], OnRL[3])。

image.png

[1]. Hongzi Mao,Ravi Netravali, and Mohammad Alizadeh. 2017. Neural Adaptive Video Streaming with Pensieve. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication, SIGCOMM 2017, LosAngeles, CA, USA, August 21-25, 2017. 197–210.

[2]. Zhou, Anfu, et al. "Learning to coordinate video codec with transport protocol for mobile video telephony." The 25th Annual International Conference on Mobile Computing and Networking. 2019.

[3]. Zhang, Huanhuan, et al. "OnRL: improving mobile video telephony via online reinforcement learning." Proceedings of the 26th Annual International Conference on Mobile Computing and Networking. 2020.


适合直播的网络传输策略

拥塞控制算法主要反馈网络拥塞情况,并不能直接缓解网络拥塞。要缓解网络拥塞,必须配合网络传输策略,包括大小流切换、SVC、丢GOP、平滑发送、FEC、ARQ/NACK等。

image.png

拥塞控制算法从webrtc完整模块化剥离和重构,性能是webrtc原来实现的2倍以上,针对直播场景深度优化,同时兼顾秒开和延迟,支持GCC和BBR算法,追求最大吞吐率。在网络小范围抖动情况下不受影响,最大支持20%丢包和500ms内的抖动。和通信场景追求极低延迟和流畅性的方式还不一样,直播场景追求高画质,保证用户的观看体验。整个算法通过线上播放数据AB做反馈,系统不断优化迭代。


▐ 零转码的码率自适应系统

目前业界大多数直播系统,当用户网络较差时,用户可以切换更低的清晰度来保障播放流畅。


低清晰度的直播流需要云转码生成。云转码需要解码后编码,编解码是非常消耗计算资源的,因此会带来大量的转码成本。


通信技术里不需要转码,拥塞控制算法发现带宽拥塞时,会自动调整发送码率来缓解拥塞。然而这种拥塞控制算法,在直播系统里并不适用,因为部分用户网络差,会将所有观看者的质量拉低。所以直播系统的码控不能直接调整主播编码码率。需要分开来看,如果主播上行网络拥塞,确实需要调整主播编码码率,如果是部分观众下行网络拥塞,则不能调整主播编码码率,而是在CDN边缘上实现丢弃一些不重要的信息,来实现有损降码率。降码率的策略包括:SVC、丢GOP、大小流等。


SVC是一种可以丢掉部分视频内容,虽然降低一点观看质量,但能保证内容可看的一种技术,适应于相对静态的场景。这种场景下,由于动作不大,几乎看不出来,比如直播带货等。

SVC又分两种,空域SVC和时域SVC。空域SVC是指,丢掉一部分视频内容,帧率不变,但每一帧视频清晰度降低的技术。时域SVC是指,丢掉一部分视频内容,帧率下降,但每一帧清晰度跟原帧的清晰度几乎不变的技术。简而言之,时域SVC是保证清晰度损失流畅度,空域SVC是保证流畅度损失清晰度。目前行业大部分空域SVC的编码算法,压缩率都会下降,甚至效果不如同时编大小流,因此使用得较少。


image.png

行业上常用的结构是X265的单层金字塔结构。

image.png

淘宝直播使用S265编码器,支持多层金字塔结构。好处是参考帧更近,相关性更强。金字塔越上层的帧,优先级越低,在网络拥塞时丢弃的影响越小。

image.png

参考帧的选择很重要,选择质量更好的参考帧,解出来的质量也越好,选择越近的参考帧,帧的相似度越高,压缩的质量也就越好。因为每一层都会有质量损失,参考层级越高,质量越差,因此参考层级越高,越需要缩短参考距离,提升帧的质量。


因此,使用S265的时域SVC技术后,不仅能实现拥塞时在CDN边缘节点的丢帧降码率能力,降低卡顿率,还能实现不丢数据时有更高的压缩率,整体压缩率提升5~6个百分点。

不过在极度拥塞的情况下,这还是不够的。需要使用丢gop策略,快速解决拥塞。在一个gop中,需要按照gop纬度统计码率。如果带宽不足的情况下,需要丢弃后面的帧,直到I帧为止。这也带来一个问题,gop中后半程的数据只有音频,数据不足,拥塞控制带宽会降的好多。针对这种情况,算法层面做了一系列调整。


对抗丢包的策略

对抗丢包的策略,除了前面讲到的降码率,还包括FEC、ARQ/NACK、平滑发送等等。

FEC是前向纠错码,即,在编码的时候,多编一些冗余,使得解码侧丢失一些数据,仍能恢复出原始数据的一种技术。FEC以往通常用于广电系统,在单向传输系统中发挥了重要作用。后来的音视频通信技术,FEC也成为了标配。但直播系统即不同于广电系统,也不同与音视频通信系统。由于观众量巨大,如果编的FEC要对抗每一个观众的丢包,则有大量观众即使网络好也会收到冗余,带来带宽的消耗以及成本提升。如果在CDN边缘针对每个观众重新计算冗余,FEC矩阵计算量比较大,则CDN的计算成本又非常高昂。因此直播系统的FEC,是主播侧编入固定的冗余,CDN在边缘节点针对每个观众的网络,选择透传多少FEC比例,从而达到既能抗网络丢包,又节约成本的目的。


ARQ或者NACK,都是发现丢包时,请求重传的技术。但网络拥塞时,请求重传会加重拥塞情况,需要谨慎使用。


网络上发生卡顿的一大凶手,是网络抖动,例如wifi、4G信号被干扰,可能造成短时间网络中断,然后瞬间所有数据全部到达。瞬间所有数据全部发送,可能造成网络拥塞,导致卡顿,更严重的,如果是超大主播出现发送数据的尖峰,可能直接把CDN节点打满,造成更大范围的卡顿。


平滑发送算法策略防止网络突发,平滑网络流量,尤其是在大量用户同时进入直播间的情况下。同时针对秒开场景深度定制。并且重新设计发送机制和算法,发送性能大大提高,是原生webrtc性能1.4倍以上。平滑发送使用了udp多包发送机制sendmmsg,构造新的发送逻辑,大大提高发送效率。直播场景播放侧有秒开的需求,在启播的阶段服务器会根据配置发送多余gop数据,这个和通信场景的pacer有些不同。

image.png

针对直播场景,我们把平滑发送细分三个阶段

  • 秒开首帧
  • 主要是首个I帧的数据,在直播中这个通常很大。首个I帧的数据在配置最大速度下,快速发送给播放端。


  • 秒开gop缓存
  • 首个I帧发送完毕后,使用相对比较大的速度发送gop缓存数据。


  • 正常发送
  • 这个时候按照配置速度发送,或者按照拥塞控制给出的带宽来发送。


image.png

此外直播场景还有固定时间大的I帧的冲击。在通信场景中只有pli,fir请求I帧的时候才有大的I帧的发送,数据相对比较平稳。但是直播场景固定2-4s会有I帧的到来,类似下面图例右边的场景。大的I帧在网络带宽不足的情况下,可能会发送200-400ms。由于平滑发送队列中音视频同时存在,会阻塞音频发送。所以我们在秒开阶段是音视频按顺序交错发送,过了秒开阶段,优先发送音频。


总结

电商直播的快速崛起,怎么把直播内容做到高效可靠的传达,无论是算法、客户端、服务端,单点优化已经出现了瓶颈,想要做出突破,需要对直播系统进行整体设计改造。


目前淘宝直播已经开创性的完成了直播新架构的升级,对用户的第一公里和最后一公里完成RTC链路接入,低延时直播让直播时代从5~7秒延时进入1秒内。这种划时代的技术创新变革,跟淘宝直播拥塞控制算法和策略的优化创新,以及淘宝直播和阿里云媒体通信级链路GRTN系统的共建密不可分。


针对直播场景拥塞控制算法定制优化,强网推流稳定性,提高强网带宽利用率,平滑码率调控策略;自学习参数优化系统,基于先验知识的分批次参数探测,多角度评价算法设计,通过不断迭代,寻找拥塞控制参数的最优解。在推流端使用了自学习的参数优化后,推流卡顿率总体下降 40%,延迟下降 12%;基于强化学习的拥塞控制,我们和北京邮电大学合作,定制淘宝直播基于强化学习的拥塞控制算法,自研与传统拥塞控制算法相结合的策略,在平稳网络中,保持带宽利用率不降的情况下,可以降低 20% 的延迟,以及约 25% 的卡顿。淘宝直播对于该方向的研究成果,已经受到学术界认可,连续两年在网络方向顶级会议 MobiCom 上发表论文。


通信级直播系统的建设,GRTN的设计理念是用通信的技术来传递直播多媒体数据,实现一张网同时支持音视频通信和直播两种业务。运营商的带宽计费通常是看峰值或95峰,多个业务峰值错开后,可以起到很好的错峰降成本的效果。在CDN下行的边缘节点上,实现协议转换,转成RTC协议,实现低延时直播,然而,GRTN不仅仅是下行播放切换成RTC协议,而是全链路的RTC协议。同时GRTN是一个去中心化架构,配合动态路径规划,可以寻找成本、质量之间的最优解。在该系统上,实现网络传输优化策略,包括大小流切换、SVC、丢GOP、平滑发送、FEC、ARQ/NACK等。


目前淘宝直播双11已经全量跑在GRTN系统之上,相比去年双11,秒开率提升32%,卡顿率降低79%,卡顿vv降低44%。后面淘宝直播团队还会继续对该系统进行持续优化和更多创新玩法的探索,辅以电商直播的快速增长需求。


相关文章
|
3月前
|
存储 监控 安全
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
为了提供更好的日志数据服务,360 企业安全浏览器设计了统一运维管理平台,并引入 Apache Doris 替代了 Elasticsearch,实现日志检索与报表分析架构的统一,同时依赖 Doris 优异性能,聚合分析效率呈数量级提升、存储成本下降 60%....为日志数据的可视化和价值发挥提供了坚实的基础。
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
|
4月前
|
存储 缓存 关系型数据库
鱼和熊掌如何兼得?一文解析RDS数据库存储架构升级
阿里云RDS率先推出新型存储类型通用云盘,提供低延迟、低成本、高持久性的用户体验。
鱼和熊掌如何兼得?一文解析RDS数据库存储架构升级
|
4月前
|
Cloud Native 关系型数据库 分布式数据库
阿里云瑶池助力九州通B2B电商平台,完成100%云原生架构升级
九州通数字化转型,通过引入阿里云云原生数据库PolarDB,云原生内存数据库Tair等产品,完美支撑了医药电商平台数据库100%云原生化,实现了统一、高效、标准化和可跟踪的B2B医药平台。
385 4
|
4月前
|
自然语言处理 Cloud Native 开发者
【2023年度技术盘点】「年终盘点后端系列」探索服务架构体系的技术风向,构建微服务核心能力(升级版)
回顾过去的几年,我们目睹了科技界的快速发展,其势头如同一列驶向前方的高速列车。作为后端开发者,我们见证了每一次技术革新所带来的广阔前景。这些创新不仅深刻影响着我们的工作方式,而且不断引领我们走向未来。
66 1
|
5月前
|
消息中间件 架构师 算法
吊打98%的JAVA同行,这份阿里P8架构师升级手册登上天梯!
前言: 我们都是IT人,所以,我们注定了很像。 前段时间有个朋友去阿里面试,作为一个社招生,太多痛苦了。都知道进大厂最好的时机就是应届生的时候。作为社招生,太难了。 我这位朋友经历了五轮面试最后才上阿里做了P6的职位。我也不得不佩服这位朋友的社交能力,和阿里的一个P8熟悉后,那个大佬看他学习能力强,有上进心,于是把他的个人经验手册给了他学习。为了感谢我之前送给他的P6面试笔记,又把这份文档送给了我。所以今天我分享出来。 对于面试题想要的看我之前的文章:从GitHub火到头条!这份万众期待的阿里内部JAVA面试手册,开源了
|
5月前
|
运维 Kubernetes Cloud Native
冠赢互娱基于 OpenKrusieGame 实现游戏云原生架构升级
冠赢互娱基于 OpenKrusieGame 实现游戏云原生架构升级
|
5月前
|
存储 分布式计算 关系型数据库
云原生数据仓库AnalyticDB MySQL湖仓版架构升级,持续释放技术红利!
云原生数据仓库AnalyticDB MySQL湖仓版架降价23%!持续提供高性价比的产品服务
|
5月前
|
存储 分布式计算 关系型数据库
|
6月前
|
存储 人工智能 分布式计算
【云栖2023】张治国:MaxCompute架构升级及开放性解读
本文根据2023云栖大会演讲实录整理而成,演讲信息如下 演讲人:张治国|阿里云智能计算平台研究员、阿里云MaxCompute负责人 演讲主题:MaxCompute架构升级及开放性解读 活动:2023云栖大会
60134 9
|
7月前
|
安全
最新发布!阿里云卓越架构框架重磅升级
10月19日阿里云峰会·山东上,阿里云重磅升级《阿里云卓越架构白皮书》,助力企业在阿里云上构建更加安全、高效、稳定的云架构。
99362 0