grtn 2020双十一 阿里云GRTN拉开直播和RTC技术下半场的序幕

栏目:历史 2021-09-19 02:31:30
分享到:

直播已经成为“菜鸟”们最喜欢的购物形式。对直播体验的终极追求,也是淘宝科技人的长期努力。为了提升用户购物体验,让直播更流畅、剁手更快捷,淘宝在2020双十一期间首次推出了阿里巴巴云CDN GRTN全球实时传输网。数据显示,与传统的httplv/RTMP模式相比,启用GRTN后,直播端到端时延降低了83%。那么,GRTN到底是什么?背后隐藏着哪些核心技术?

本文将回顾互联网直播技术的发展,深入分析直播延时的技术挑战,解读阿里巴巴云全球实时传输网络GRTN的设计思路、技术原理、特点和应用实践,以及GRTN试图摆脱传统直播技术面临的内卷困境。GRTN不仅仅是为网络直播而设计的。实时音视频RTC等流媒体技术的用户,如云会议、云游戏、云桌面等。,将业务迁移到GRTN后,他们可以拥有哪些新游戏和创新机会?这篇文章将为你解答。

互联网直播技术的演进趋势

互联网直播技术的发展大致可以分为四个阶段:创新期、演进期、量产期和瓶颈期。

第一次知名的网络直播可以追溯到20多年前,也就是20世纪的最后一年。维多利亚在网上偷偷播出了他们的时尚走秀,也就是今天大家都很熟悉的薇咪秀。虽然画面不清晰,但也吸引了数百万观众,充分展示了直播作为一个新物种的巨大吸引力。需要知道的是,当时世界著名的流媒体公司网飞奈飞还在靠租影碟为生。这一时期被称为直播技术创新期,从线下文件下载、DVD租赁到线上,彻底改变了观众的观看体验。但是这一时期的直播体验还是比较差的,体现在分钟级的延迟和频繁的干扰。

接下来,随着互联网基础设施的演进,流媒体技术也取得了长足的进步。这方面的典型代表就是流媒体技术演变成了一种CDN友好模式,即媒体流切片模式,将媒体流分割成2-10s不等的切片文件,通过CDN进行分发。这一特性很好地适应了互联网延迟抖动,从而提供了相对平滑的观看体验,并将延迟从几分钟减少到几十秒。这一时期我们称之为互联网直播的发言期,这一时期的直播应用主要集中在电视台的体育赛事上。

时间来到了2016年。随着移动互联网迎来4G时代,美女主播、游戏主播等应用崛起,互动直播开始爆发,各种直播应用如雨后春笋般涌现。在此期间,在线名人已经可以使用他们的手机。随时随地播出。这时,国内主流协议是大家熟悉的RTMP、HTTPFLV、HLS等。因为底层传输还是用TCP,延迟一般在5-10s之间,但是图片已经对比过了

如今,互联网直播经历了4年的高速发展,用户对体验的要求越来越高。传统的5-10s延时很难实时互动,比如火热的直播和在线教育业务。主播与观众、老师、学生的实时互动体验得到了很大提升空。此外,随着5G时代的到来,出现了AR/VR沉浸式直播等新场景,然而近年来,直播技术一直没有本质的突破。所有直播CDN厂商都在现有的基于TCP的RTMP/FLV直播系统的质量优化上投入了大量精力。主要优化方法有精细调度、精准覆盖、优质资源、缓存命中率优化、TCP协议栈优化、直播业务行为分析等。质量优化体系越来越精细化。但是在时延的提升方面,大概是几百ms,甚至在扣除几十ms,卡顿的减少也在几个百分点左右,所以实际用户体验的提升已经非常有限,互联网直播技术也开始遇到瓶颈,这其实在一定程度上制约了业务的发展。

网络直播的时延分布与技术挑战

那么如何才能在延迟上有所突破呢?要解决这个问题,需要分析直播延时的整体分布情况。互联网直播的整个环节可以分为采集、编码、发送、分发、接收、解码、渲染七个步骤。

其中采集+编码、解码+渲染的整体延迟相对固定,总共约100ms,主要变化是分发和接收,从几十毫秒到几秒不等,主要取决于链路延迟抖动、协议栈的优化和CDN资源的覆盖。

在传统的架构中,这七个环节是独立的、不相关的。这样做的好处是团队分工相对明确,但问题是很难实现优化方法的跨界融合,导致无法实现系统级优化。例如,如果编码器能够考虑到传输时的拥塞情况,实时调整比特率,就可以在一定程度上缓解拥塞,从而降低时延;比如在传统的流媒体传输中,媒体数据传输和底层传输是相互独立的,底层TCP传输的拥塞控制算法是通用算法,没有考虑媒体的特性。这样的分层结构很难形成即时反馈系统,所以为了保证流畅度,缓冲区的大小会相对保守,从而牺牲端到端的时延。如果传输层和应用层融合,QoS控制是专门针对媒体特性设计的,同时在编码端有码率控制,可以通过组合拳。

所以以上所有环节都要互锁,这样只有整个环节互相感应,才能把延迟压缩到极致。

行业主流低延时直播方案比较

业界主流的流媒体协议和技术有五种,包括WebRTC、QUIC、SRT、CMAF和LLHLS。这里的比较从以下八个维度展开:

拟定时间:最早提出WebRTC,其次是QUIC,最新的是苹果去年新发布的LLHLS

完备性:这里的完备性主要集中在这项技术是否涉及到前面提到的直播环节中的所有环节。比如WebRTC被认为是全覆盖的,它涉及到从采集、编码解码、传输到渲染的所有环节。因此,严格来说,WebRTC不是一个协议,而是一个开放的实时流媒体通信框架;然后我们来看看QUIC,它是IETF正在标准化的新一代传输协议;2017年SRT刚开通时,还只是一个视频传输协议,但在很多编码器厂商的支持下,开始影响编码端的比特率,从而保持相对稳定的延迟。

底层传输协议和类型:WebRTC、QUIC、SRT都是基于UDP和流传输,而CMAF和LLHLS都是基于切片,底层基于HTTP。

标准和终端支持:WebRTC已经是W3C标准,大量使用IETF RFC规范。目前几乎所有的浏览器和手机操作系统都支持WebRTCQUIC有望在今年年底正式成为下一代HTTP标准,也就是HTTP/3,目前已经得到Chrome的支持。

场景和延时:WebRTC针对实时音视频通信场景设计,端到端延时在400ms以内,约250ms然而,其他协议需要大量额外的技术投资才能在2s内实现。

综合考虑各种因素,阿里巴巴云新一代传输网络选择了WebRTC技术,不仅延迟低,还支持单通道全双工,可以实现真正的低延迟+交互。

GRTN的位置

为了降低直播端到端时延,阿里巴巴云CDN和视频云结合手淘技术,达摩院XG Lab从直播和短时延直播拓展到RTC领域,在QoS和AAA方面下功夫,最终成功打造GRTN全球实时传输网络。

GRTN定位基于中心云和边缘云的异构节点,构建超低时延、全分布式下沉的通信级流媒体传输网络。GRTN目前整合了互联网直播、RTC等各种业务场景下音视频流的传输和交换。基于GRTN的短时延直播RTS可以支持标准H5 WebRTC的推播,在千万并发的情况下,延迟可以控制在1s以内;RTC端到端延迟可以控制在250ms左右。

GRTN建筑

下图是传统交互式直播系统的典型架构,其特点是:

树形层次结构

上游推送主流协议:RTMP/WebRTC

下行广播的主流协议:httplv/RTMP/HLS

直播分发与RTC推流系统分离

端到端延迟约6s

传统建筑的主要缺点是:

成本高,主要是由于媒体数据链接长、直播分发多、RTC推流系统隔离

延迟大,是因为采用了基于TCP的RTMP/HTTP-FLV协议,媒体数据经过的链路长

很难扩展,因为RTMP/HTTP-FLV协议在传输上不是全双工的,所以服务模式只能支持单向直播,视频交互需要旁路系统的帮助。

与传统直播架构相比,GRTN架构的技术特点是:

混合网络:树形层次结构+对等图形网络

容量下沉:协议边缘卸载+内部传输协议规范化

控制和数据分离:动态路径规划+全分布式SFU

架构升级带来的核心价值是:

为降低成本,GRTN是一个多业务融合网络,可以支持直播、RTC、视频上云等多种场景,业务复用率高。此外,GRTN内部链接更短,节点内成本更低。

为提高质量,GRTN内网支持动态路由构建的网状结构,内部链路时延可达20毫秒左右,内部链路采用私有协议高效传输。此外,客户端的推送和分发是基于WebRTC构建的,QoS拥塞控制是针对流媒体的特点专门设计的,并基于在线数据构建不断迭代和打磨。

很容易扩展。GRTN支持WebRTC协议,可以在单个连接通道上进行全双工通信,从而可以自由发布和订阅媒体流,在业务扩展性空方面带来了更大的想象空间。

GRTN核心技术-点对点网络和路径动态规划

传统的直播架构是分层树形结构。由于媒体流的链路相对固定,这种结构可以在产品早期阶段的媒体协议处理上投入更多的R&D资源,对于快速构建产品能力来说风险相对可控。但是随着业务的发展,这种架构的缺陷会越来越明显,比如延迟高、成本高、扩展性差,一定程度上阻碍了业务的发展。比如延迟在6s以下很难打破,视频交互只能依靠旁路系统。

为了从根本上解决这一系列问题,结合分层结构有助于系统运行和容量评估,网状结构有利于构建高质量低成本网络的特点,GRTN采用混合组网模式,即分层结构和对等图形模式相结合的组网模式。路由中心定期收集内部链路检测的结果。为了配合动态组网,流媒体大脑模块需要管理流媒体信息,还需要支持路径切换、容量规划以及成本和质量之间的综合调度。

GRTN核心技术——多径传输

为了提高GRTN内联传输的可靠性,考虑成本和质量的平衡,GRTN支持以下三种内联多径传输模式:竞速模式、替代模式和智能模式,可以在高可靠性、高质量和高成本等多种因素的控制下自适应、自适应切换。

GRTN核心技术——能力下沉

流媒体技术一直以其协议著称,主要是因为服务的多样性。以下是流媒体行业技术演进趋势对照表:

上表只整理了比较常见的协议,可以看出流媒体协议比较复杂。在传统架构中,这些协议的处理是在中心完成的,透明分发主要是在边缘完成的。这个问题是协议处理的链路太长,不仅成本高而且耗时。所以一个自然的想法就是把协议和媒体处理能力下沉到CDN的边缘,中心只做控制。因此,将控制和数据分开,类似于Service MESh的dESign思路,因为这些协议的本质是传输音视频的基本流es,不同的协议解决了不同封装格式的传输问题,如TS、PS、MP4、fMP4、FLV等。,而不同的封装格式本质上是不同场景下如何封装es流的问题,因此在边缘为不同的es流设计通用的传输协议和缓存系统是完全可行的。GRTN已经将协议处理能力下沉到边缘节点,目前可以支持RTMP、HTTP-FLV、WebRTC、GB28181等流媒体协议。

GRTN核心技术——双向实时信令网

如上所述,GRTN的核心价值观之一是高质量。除了低延迟,高质量还需要考虑快速容灾切换能力、提高第一屏二开率等核心指标。

RTC场景中的一个常见功能是客户端网络的移动性。比如用户开会回家或者离开家,手机网络需要在4G和wifi之间切换。此外,当客户端访问的CDN节点异常时,两种情况都会导致客户端在与GRTN通信时切换访问节点。GRTN建设的双向实时信令网可以在几毫秒内传递网络切换的消息。当发布端的媒体流被切换时,订阅客户端完全不知道在GRTN发生的切换行为。

GRTN核心技术——持续迭代服务质量

GRTN之所以能把直播时延从6s降低到1s以内,RTC通信时延能达到250ms左右,除了图形网络结构转换和协议下沉技术之外,核心是采用具有媒体特征感知的QoS,这与TCP或QUIC等一般QoS策略有本质区别。

WebRTC的QoS是一个针对流媒体特性的多维决策系统,涉及到很多算法和策略参数。为了方便业务层选择最佳的QoS算法和参数,GRTN设计了一个可插拔的QoS集成框架。结合GRTN的基于数据的质量评估系统,可以实现集成的连续迭代,不同的算法和参数可以通过GRTN的A/B质量评估系统进行在线评估,形成赛马机制。

同时,文章中提到的QoS和动态路径规划也有很多集成点。服务质量研究中一个非常重要的课题是区分网络抖动和拥塞。如果拥塞,需要反馈给上游进行源带宽分配。但是,如果只是短暂的抖动,可以启用相对激进的防丢包策略。动态路径规划也面临类似的问题。如果只是短暂的拥塞,可以保留当前链路,依靠QoS防丢包策略,但如果是拥塞,需要尽快进行。

GRTN核心技术——流媒体双胞胎

GRTN升级为网状结构后也将面临一些新的挑战。众所周知,在618、双11等推广活动中,保证CDN资源的充足供应是非常重要的。在传统的分层结构中,L1/L2/中心可以通过服务命中率来评估,而在网状结构中,内部链路是动态规划的,这意味着流量分布也是动态的,这对如何评估CDN的整体容量提出了新的挑战。例如,动态路由算法如何在质量和成本之间找到平衡,以确保GRTN系统的低成本和高质量?为了解决这些问题,GRTN基于数字孪生的思想设计了一个流媒体孪生系统,用于容量评估、算法训练、事件回放和模拟压力测量。

GRTN核心技术–可编程

流媒体技术的上层业务场景非常丰富,如电商直播、视频会议、在线教育、企业直播、新零售等。,所以对定制开发有很多需求。可编程改造是GRTN提高系统稳定性的一次尝试。目前,GRTN的中央流媒体大脑,业务模块在节点端,媒体数据传输模块,媒体信令处理模块等。都经历了可编程转换,在大多数情况下,二进制发布是可以避免的。

阿里巴巴云超低延迟直播产品RTS

为了让客户和行业更容易拥抱GRTN,阿里巴巴云打造了基于GRTN的超低延迟直播服务RTS,该服务具有四大技术特点:

1.二级时延和优秀的抗弱网络能力,在相同的干扰率下,时延可降低80%。与传统的RTMP和FLV的5-10s延迟相比,RTS延迟可以达到1s以内,而且还是基于在线大数据,在自学习和不断迭代。

二是成熟稳定。经过两年多的潜心研发,RTS经历了淘宝直播618的线上测试,已经在淘宝直播上线。

三是开放标准,为了方便自研玩家客户使用我们的RTS服务,阿里巴巴云的WebRTC接入信令协议是完全开放透明的。

第四,RTS服务覆盖面广、并发度高,构建在阿里巴巴云2800+边缘节点上,可支持数千万并发广播。

客户访问即时战略的两种解决方案

1.对于使用云厂商玩转SDK的客户,升级玩转SDK后,可以根据业务灵活选择网络传输协议,打造更高性价比的组合。

1.在现有的直播服务中添加一个RTS广播盆名,分两种方式推送流。

2.锚端不需要修改,只升级播放SDK,播放端自动识别不同的URL参数。

二是对于自行开发播放器的客户,阿里巴巴云以标准WebRTC协议开启对接代码演示,客户自行升级网络模块,使得底层网络对接更加透明

1.在现有的直播服务中添加一个RTS广播盆名,分两种方式推送流。

2.不需要修改主播端,只升级播放器的网络模块,播放超低延迟流。

低延迟+互动体验升级路径的未来展望

在流媒体服务的用户体验升级中,GRTN带来的不仅仅是延时的降低,还有GRTN提供的灵活交互能力。GRTN模糊了直播和RTC的界限,连麦和会议的界限。在GRTN的世界里,只有媒体流的发布和订阅关系,

直播:1人发布多人订阅

1v1客户端的连播+直播:3人发布多人订阅,这里的第三个发布是来自主播端的组合屏流。

1v1服务端连麦+直播:3人发布多人订阅,这里的第三个发布来自服务端的合流发布。汇流释放上来的时候,可以利用GRTN的流量切割能力,让观众在连续换麦的时候感觉毫无意义。

视频会议:多人发布多人订阅,GRTN的切流能力可以用来在会议中切换视频流和视频流。

结合GRTN基于成本和稳定性提供的分级延迟能力,50ms/250ms/800ms/6s/…,可以融合不同的场景和产品化能力。

在线教育体验升级

过去在线教育的典型架构是旁路直播模式,即云中有一个基于WebRTC的RTC媒体中心,需要实时互动的师生会接入WebRTC频道,然后RTC媒体中心将所有RTMP流推送到直播CDN进行旁路直播。由于直播延时大,协议不一致,在这种情况下,如果观看直播的同学切入RTC频道进行互动,体验会很差,有时会出现黑屏中断的情况。

要想降低延迟,彻底解决黑屏问题,就需要将云上WebRTC双向通信通道的能力下沉到GRTN承载的GRTN,将交互和分发融为一体,形成一体化的超低延迟交互通道。WebRTC流的订阅关系是通过业务层控制的。直播和互动频道没有明确的界限,可以根据业务情况灵活切换两种模式,这种切换对学生和老师完全不敏感。

电子商务直播体验升级

上述直播和在线教育的整体结构没有本质区别,在结构升级的路径上可以采用上述同样的思路。这里值得一提的是,使用了GRTN之后,业务端的技术团队可以更加专注于做很多创新的事情。比如在小主播的加载室,之前的交互只有文字或者1v1的小麦。进入GRTN后,很容易将这个单向加载室改造成类似视频会议的多人互动讨论室。用户交互体验的提升能否带来像时延降低这样的GMV转换?

本文聚焦GRTN服务端的核心竞争力,希望能给做流媒体技术的同学带来一些启发。感谢阅读。