直播新架构升级:全量支撑淘宝双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%。后面淘宝直播团队还会继续对该系统进行持续优化和更多创新玩法的探索,辅以电商直播的快速增长需求。


相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
相关文章
|
2月前
|
存储 SQL 缓存
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
快手 OLAP 系统为内外多个场景提供数据服务,每天承载近 10 亿的查询请求。原有湖仓分离架构,由离线数据湖和实时数仓组成,面临存储冗余、资源抢占、治理复杂、查询调优难等问题。通过引入 Apache Doris 湖仓一体能力,替换了 Clickhouse ,升级为湖仓一体架构,并结合 Doris 的物化视图改写能力和自动物化服务,实现高性能的数据查询以及灵活的数据治理。
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
|
1月前
|
分布式计算 大数据 Serverless
云栖实录 | 开源大数据全面升级:Native 核心引擎、Serverless 化、湖仓架构引领云上大数据发展
在2024云栖大会开源大数据专场上,阿里云宣布推出实时计算Flink产品的新一代向量化流计算引擎Flash,该引擎100%兼容Apache Flink标准,性能提升5-10倍,助力企业降本增效。此外,EMR Serverless Spark产品启动商业化,提供全托管Serverless服务,性能提升300%,并支持弹性伸缩与按量付费。七猫免费小说也分享了其在云上数据仓库治理的成功实践。其次 Flink Forward Asia 2024 将于11月在上海举行,欢迎报名参加。
159 1
云栖实录 | 开源大数据全面升级:Native 核心引擎、Serverless 化、湖仓架构引领云上大数据发展
|
19天前
|
存储 消息中间件 人工智能
ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用
本文整理自2024年云栖大会阿里云智能集团高级技术专家金吉祥的演讲《ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用》。
|
26天前
|
存储 消息中间件 运维
架构升级的救星!流量回放自动化测试的必备指南
大家好,我是小米,一名29岁的技术宅。今天分享一个物联网领域的实用技能——流量回放自动化测试。系统重构后,测试工作量巨大,本文介绍如何通过日志收集和数据回放进行自动化测试,包括离线、实时和并行回放模式,帮助快速定位Bug,提升测试效率和系统稳定性。欢迎关注我的微信公众号“软件求生”,获取更多技术干货!
31 3
|
24天前
|
存储 SQL 缓存
Apache Doris 3.0 里程碑版本|存算分离架构升级、湖仓一体再进化
从 3.0 系列版本开始,Apache Doris 开始支持存算分离模式,用户可以在集群部署时选择采用存算一体模式或存算分离模式。基于云原生存算分离的架构,用户可以通过多计算集群实现查询负载间的物理隔离以及读写负载隔离,并借助对象存储或 HDFS 等低成本的共享存储系统来大幅降低存储成本。
Apache Doris 3.0 里程碑版本|存算分离架构升级、湖仓一体再进化
|
2月前
|
缓存 物联网 数据库
如何帮助我们改造升级原有架构——基于TDengine 平台
一、简介 TDengine 核心是一款高性能、集群开源、云原生的时序数据库(Time Series Database,TSDB),专为物联网IoT平台、工业互联网、电力、IT 运维等场景设计并优化,具有极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等系统功能,能大幅减少系统设计的复杂度,降低研发和运营成本,是一个高性能、分布式的物联网IoT、工业大数据平台。 二、TDengine 功能与组件 TDengine 社区版是一开源版本,采用的是 AGPL 许可证,它具备高效处理时序数据所需要的所有功能,包括: SQL 写入、无模式写入和通过第三方工具写入 S标准 SQL 查
74 13
|
3月前
|
安全 网络安全 网络虚拟化
优化大型企业网络架构:从核心到边缘的全面升级
大型企业在业务运作中涉及多种数据传输,涵盖办公应用、CRM/ERP系统、数据中心、云环境、物联网及安全合规等多个方面。其复杂的业务生态和全球布局要求网络架构具备高效、安全和可靠的特性。网络设计需全面考虑核心层、汇聚层和接入层的功能与冗余,同时实现内外部的有效连接,包括广域网连接、远程访问策略、云计算集成及多层次安全防护,以构建高效且可扩展的网络生态系统。
优化大型企业网络架构:从核心到边缘的全面升级
|
3月前
|
消息中间件 存储 Java
图解Kafka:Kafka架构演化与升级!
图解Kafka:Kafka架构演化与升级!
86 0
图解Kafka:Kafka架构演化与升级!
|
3月前
|
存储 缓存 Cloud Native
阿里云EMR数据湖文件系统问题之JindoFS架构升级后的问题如何解决
阿里云EMR数据湖文件系统问题之JindoFS架构升级后的问题如何解决
|
4月前
|
消息中间件 Java 测试技术
Java中的软件架构重构与升级策略
Java中的软件架构重构与升级策略

热门文章

最新文章