2020 双十一,阿里云 GRTN 拉开直播和 RTC 技术下半场的序幕
直播,已经成为了“剁手党”们最喜闻乐见的一种购物形式。对直播体验的极致追求,也是淘宝技术人们长期的努力方向。为了提升用户购物体验,让直播更加丝滑,让剁手更快一些,在 2020 双十一期间,淘宝首次启用了阿里云 CDN 的 GRTN 全球实时传输网络。数据显示,和传统的 HTTPFLV/RTMP 方式相比,在启用了 GRTN 后,直播端到端的延时降低了 83%。那么,GRTN 到底是什么?其背后究竟隐藏了哪些核心技术?
这篇文章会通过回顾互联网直播技术的发展历程,深度剖析直播延时的技术挑战,并解读阿里云全球实时传输网络 GRTN 的设计思路、技术原理、特质与应用实践,以及 GRTN 在摆脱传统直播技术所面临的内卷化(Involution)窘境所作出的尝试。GRTN 不单单是为互联网直播而设计,诸如实时音视频 RTC 等流媒体技术的使用者,比如云会议、云游戏、云桌面等,在将业务迁移至 GRTN 后可以有什么新玩法和创新机遇?本文将为您解答。
作者:子融,阿里云高级技术专家,负责阿里云视频直播产品和流媒体实时加速平台研发
互联网直播技术的进化趋势
互联网直播技术的发展大致可以被分为了 4 个阶段:分别是创新期、演进期、量产期和瓶颈期。
互联网上的第 1 场比较有名的直播还要追溯到 20 多年前,那是 20 世纪的最后一年,维多利亚秘密(Victoria Secret)在线上直播了她们的时尚走秀,也就是大家今天比较熟知的维密秀,尽管画面及其不清晰,但也吸引了数以百万级的观众,充分展现了直播这个新物种巨大的吸引力。
要知道今天全球著名的流媒体公司 Netflix 奈非当时还是在靠 DVD 租赁来维持生计。
这段时期我们称之为直播技术的创新期,它革命性的将观众的观影体验从离线文件下载和 DVD 租赁升级到了线上,但这个时期的直播体验还是比较差的,体现在时延和卡顿上就是分钟级的延时并且经常卡顿。
接下来,伴随着互联网的基础设施的演进,流媒体技术也得到了长足的发展,这其中典型的代表是流媒体技术演进出了一种对 CDN 非常友好的模式,即媒体流切片模式,媒体流被分割成 2-10s 不等的切片文件,并通过 CDN 来进行分发。
这种特性很好地适应了互联网延时抖动,从而提供了一种相对流畅的观影体验,并且将时延从数分钟压缩到了数十秒。这一时期我们称之为互联网直播的演讲期,这一时期的直播应用主要以电视台体育赛事为主。
时间来到 2016 年,随着移动互联网迎来 4G 时代,美女主播、游戏主播等应用的兴起,互动直播开始爆发,各种直播 App 如雨后春笋般涌现,这一时期,网红们已经可以通过自己的手机随时随地的开播,此时国内主流的协议有耳熟能详的 RTMP、HTTPFLV、HLS 等,由于底层的传输仍然采用 TCP,延时普遍在 5-10s 之间,但画面已经比较清晰和流畅了。
时至今日,互联网直播经历了 4 年的高速期发展,用户对体验的要求越来越高,传统的 5-10s 延时很难进行实时互动,比如时下很火的直播带货和在线教育业务,主播和观众、老师和学生的实时互动体验还是有很大的改进空间的,另外随着 5G 时代的到来,新的场景,比如 AR/VR 沉浸式直播、4K 全息投影远程直播都要求更高带宽和更低延时。
但直播技术近几年却未能有本质性的突破,各家直播 CDN 厂商都投入了大量的精力在对现有基于 TCP 的 RTMP/FLV 直播体系的质量优化上,主要优化手段有精细化的调度、精准的覆盖、优质的资源、优化缓存命中率、TCP 协议栈优化、直播业务行为分析等,质量优化系统做得越来越精致。
但在时延的提升上也就是在几百 ms 左右,甚至就是在扣那几十 ms,卡顿的降低也都是在几个百分点左右,对实际用户体验的提升已经是非常有限了,互联网直播技术开始遇到了瓶颈,这种内卷化的发展其实是一定程度上制约了业务的发展。
互联网直播延时分布和技术挑战
那么如何才能在延时上有所突破呢?要解决这个问题,首先需要剖析一下直播延时的整体分布,互联网直播全链路可以分为 7 个步骤:分别是采集、编码、发送、分发、接收、解码和渲染。
其中采集+编码,解码+渲染总体延时比较固定,共 100ms 左右,变动比较大的部分是分发和接收,从数十毫秒到数秒不等,主要取决链路时延抖动、协议栈的优化情况,以及 CDN 资源的覆盖情况。
在传统的架构里,这个 7 个环节相互独立,互不相干,这样做的好处是团队分工比较明确,但问题就是优化手段很难做到跨界融合,导致无法做到系统级优化。
比如,编码器如果可以考虑发送时的拥塞情况来实时调整码率就可以一定程度上缓解拥塞,从而降低延时;再比如传统的流媒体传输中媒体数据发送和底层的传输是相互独立的,底层 TCP 传输的拥塞控制算法是个通用算法,不会考虑媒体的特性。
这样的一个分层结构是很难形成即时反馈系统的,那么为了保障流畅度,缓存区的大小设计会相对保守,从而牺牲了端到端的时延,如果传输层和应用层是一体化的,QoS 控制针对媒体特性来专门设计,同时配合编码侧的码率控制,就能通过组合拳的方式,大大地降低延时。
所以上述各个环节应该是环环相扣,做到全链路相互感知才能将延时压缩到极致。
业界主流低延时直播方案对比
业界主流的 5 种流媒体协议和技术,其中包括 WebRTC、QUIC、SRT、CMAF、LLHLS。这里的对比从下述 8 个维度来展开:
提出时间:WebRTC 是最早被提出的,QUIC 紧随其后,最晚的是去年 Apple 新发布的 LLHLS。
完备度:这里的完备度主要关注这项技术是否涉及我们前面提到的直播全链路中的各个环节,比如 WebRTC 我们认为是全覆盖的,它涉及了从采集、编解码、传输和渲染的全部环节,所以严格来讲 WebRTC 并不是一个协议,而是一个开放的实时流媒体通信框架;那我们再来看 QUIC,它是一个正在被 IETF 标准化的新一代传输协议;SRT 在 2017 年刚开源的时候的只是一个视频传输协议,但随着很多编码器厂商的支持,也开始可以影响编码侧的码率,从而保持相对稳定的时延。
底层传输协议和类型:WebRTC、QUIC、SRT 都是基于 UDP 的而且都是流式的传输,而 CMAF 和 LLHLS 都是切片方式的,底层基于 HTTP。
标准和终端支持:WebRTC 已经是 W3C 标准,并且使用了大量的 IETF RFC 规范,目前几乎所有的浏览器以及手机操作系统都支持 WebRTC;QUIC 预计在今年年底会正式成为下一代 HTTP 标准即 HTTP/3,目前 Chrome 已经支持。
场景和延时:WebRTC 是为实时音视频通信场景设计,端到端延时是在 400ms 以内,250ms 左右;而其它几个协议要做到 2s 以内,都还需要很多的额外技术投入。
综合各方面因素,阿里云的新一代传输网络选择了 WebRTC 技术,不仅延时低,而且支持单通道全双工,可以做到真正意义上的低延时+互动。
GRTN 的定位
为了能够降低直播的端到端延时,阿里云 CDN 与视频云联合手淘技术、达摩院 XG 实验室在先后从直播、短延时直播拓展到 RTC 领域,并在 QoS 和 AAA 方面发力,最终成功构建了 GRTN(Global Realtime Transport Network)全球实时传输网。
GRTN 的定位是基于中心云和边缘云的异构节点,构建超低延时、全分布式下沉的通信级流媒体传输网络。
GRTN 目前融合了互联网直播和 RTC 等多种业务场景的音视频流传输和交换。基于 GRTN 的短延时直播 RTS 可以支持标准 H5 WebRTC 推播,在千万级并发情况下延时可以控制在 1s 以内;RTC 端到端延时可以控制在 250ms 左右。
GRTN 架构
下图是一个传统互动直播系统的典型架构,这个架构的特点是:
树状层级结构
上行推流主流协议:RTMP/WebRTC
下行播放主流协议:HTTPFLV/RTMP/HLS
直播分发和 RTC 推流系统分离
端到端延时~6s
传统架构的主要缺点是:
成本高,主要是媒体数据经过的链路长、直播分发和 RTC 推流系统孤立
延时大,因为采用基于 TCP 的 RTMP/HTTP-FLV 协议,而且媒体数据经过的链路长
扩展难,由于 RTMP/HTTP-FLV 协议在传输上不是全双工的,所以业务形态是只能支持单向直播,视频互动需要借助旁路的连麦系统。
相比于传统的直播架构,GRTN 架构的技术特点是:
混合组网:树状层级结构+对等图形网
能力下沉:协议边缘卸载+内部传输协议归一化
控制和数据分离:动态路径规划+全分布式 SFU
架构升级所带来的核心价值是:
降成本,GRTN 是一个多业务融合的网络,可以支持直播、RTC 和视频上云等多种场景,业务复用率高,另外 GRTN 内部链路更短,节点内的成本也更低。
提质量,GRTN 内部组网支持采用动态选路的方式来构建的网状结构,内部链路延时可以做到 20ms 左右,并且内部链路采用了私有协议来进行高效传输。另外客户端的推流和分发都是基于 WebRTC 来构建的,QoS 拥塞控制是专门针对流媒体特性来进行设计的,并且还在基于线上数据建设进行持续迭代和打磨。
易扩展,GRTN 支持了 WebRTC 协议,可以在单个连接通道上进行全双工的通信,从而可以很自由的进行发布和订阅媒体流,在业务的扩展性上带来了更大的想象空间。
GRTN 核心技术 – 对等组网和路径动态规划
传统的直播架构是一种层级的树状结构,由于媒体流的链路相对比较固定,这种结构的在产品初期可以把研发资源更多的投入在媒体协议的处理上,对于快速构建产品能力是相对风险可控的。
但随着业务的发展,这种架构的缺陷也会越发明显,比如延时高、成本高,而且扩展性也比较差等,在一定程度上是阻碍业务发展的,比如延时很难突破到 6s 以下,视频的互动只能借助旁路连麦系统等。
为了根本上解决这一系列问题,并结合层级结构有助于系统运维和容量评估,而网状结构有益于构建高质量和低成本的网络的特性,GRTN 采用了混合组网方式,即层级结构和对等图形方式相结合的组网的方式。
选路中心会周期性收集内部链路探测的结果,为了配合动态组网,流媒体大脑模块需要对流信息进行管理,同时还需要支持路径切换、容量规划以及在成本和质量之间做综合的调度。
GRTN 核心技术 – 多路径传输
为了能够提高 GRTN 内部链路传输的可靠性,以及考虑在成本和质量间的均衡,GRTN 支持如下 3 种内部链路多路径传输模式:竞速模式、备选模式和智能模式,可以在高可靠,质量,成本等诸多因素控制下进行适配和自适应的切换。
GRTN 核心技术 – 能力下沉
流媒体技术向来以协议多著称,主要是因为业务的多样性导致,下面是流媒体行业的技术进化趋势对比表:
上表中只整理了相对比较通用的协议,可以看到流媒体协议纷繁复杂,在传统的架构里这些协议的处理在中心完成,边缘主要做透传分发。
这样的问题就是协议处理的链路太长,不仅成本高而且延时大,那么很自然的一个想法就是将协议和媒体处理能力下沉到 CDN 的边缘,中心只是做管控,从而做到类似 Service Mesh 的设计思想,将控制与数据分离。
因为这些协议的本质都是在传输音视频的基本流 ES(Elementary Stream,比如常见的 H.264/H.265/AAC/OPUS/VP8/VP9/AV1 等),不同的协议解决的是不同的封装格式的传输问题。
比如有 TS(Transport Stream)、PS(Program Stream)、MP4、fMP4(fragment MP4)、FLV 等,而不同的封装格式本质上就是针对不同场景下如何封装 ES 流的问题。
因此在边缘设计一种通用的针对不同 ES 流的传输协议和缓存系统是完全可行的。GRTN 将协议处理能力下沉到了边缘节点,目前可以支持 RTMP、HTTP-FLV、WebRTC、GB28181 等流式协议。
GRTN 核心技术 – 双向实时信令网
前面提到 GRTN 核心价值之一是高质量,高质量除了延时低以外,还需要考虑快速容灾切换能力,以及提升首屏秒开率等核心指标。
在 RTC 场景下有一个比较常用的功能是客户端网络的 Mobility,比如用户在开会的过程中回家或是离开家的时候手机网络需要在 4G 和 wifi 之间切换,另外考虑客户端接入的 CDN 节点出现异常的时候。
这两种情况都会造成客户端在和 GRTN 通信过程中切换接入节点,GRTN 构建的双向的实时信令网能够做到切网消息的毫秒级传递,当有一个发布端的媒体流发生网络切换后,订阅的客户端对 GRTN 内部发生的切换行为是完全无感知的。
GRTN 核心技术 – 持续迭代的 QoS
GRTN 之所以能够做到在直播延时由 6s 降低到 1s 以内,RTC 通信延时做到 250ms 左右,除了图形网的结构的改造以及协议下沉等技术外,最核心的还是有采用了有媒体特性感知的 QoS,这和 TCP 或 QUIC 这类通用 QoS 策略在本质上是不一样。
WebRTC 的 QoS 是一个针对流媒体特性的多维决策体系,涉及到的算法和策略参数非常多,为了方便业务层对底层 QoS 算法和参数的择优,GRTN 设计了一套可插拔的的 QoS 集成框架,结合 GRTN 数据化的质量评估体系,可以做到一次集成持续迭代,不同的算法和参数都可以利用 GRTN 的 A/B 质量评估体系进行线上评估,形成赛马机制。
同时 QoS 和文章前面提到的动态路径规划也是有很多结合点的,QoS 研究中的一个很重要课题就是需要区分出网络的抖动和拥塞,如果是拥塞那就需要反馈给上游进行信源带宽调配(比如降码率,流切换等)。
但如果只是短暂的抖动,就可以启用相对激进的抗丢包策略,动态路径规划也面临类似的问题,如果是只是短暂的拥塞,可以保持当前链路并借助 QoS 的抗丢包策略来扛,但如果是链路拥塞了,则需要尽快切换链路。
GRTN 核心技术 – 流媒体孪生
GRTN 升级到网状结构后也会面临一些新的挑战。众所周知,在 618 和双 11 等大促活动期间确保 CDN 资源的充足供应是至关重要的,在传统的层级结构下可以通过业务命中率来分别对 L1/L2/中心分别进行评估,而在网状结构下内部链路是动态规划出来的,也就意味着流量的分布也是动态的。
这对于如何评估 CDN 的整体容量提出了新的挑战;再比如动态选路算法如何在质量和成本之间找到均衡点,以确保 GRTN 系统的低成本高质量?
为了解决此类问题,GRTN 借鉴数字孪生 (Digital Twin https://en.wikipedia.org/wiki/Digital_twin) 的思想设计了一个流媒体孪生(Streamimg Media Digital Twin)系统,用于容量评估、算法训练、事件复盘和模拟压测等。
GRTN 核心技术 – 可编程
流媒体技术的上层业务场景非常丰富,比如电商直播、视频会议、在线教育、企业直播、新零售等,因此有很多定制化开发的需求。
可编程化改造是 GRTN 在提升系统稳定性上的一次尝试,目前 GRTN 的中心流媒体大脑,节点侧的业务模块,媒体数据发送模块、媒体信令处理模块等都已经进行了可编程化改造,大部分情况下都可以避免二进制的发布。
阿里云超低延时直播产品 RTS
为了更加方便客户和行业拥抱 GRTN,阿里云基于 GRTN 打造了超低延时直播服务 RTS,其有四个技术特性:
一、秒级延时和卓越的抗弱网能力,在相同卡顿率下延时可以降低 80%,相比于传统的 RTMP 和 FLV 的 5-10s 延时,RTS 的延时可以达到 1s 以内,并且还在基于线上的大数据,在自我学习和持续迭代中。
二、成熟稳定,RTS 历经 2 年多时间的潜心研发,并经历了淘宝直播 618 大促的线上考验,目前已经在淘宝直播上线。
三、开放标准,为了能够方便自研播放器的客户使用我们的 RTS 服务,阿里云的 WebRTC 接入的信令协议的完全开放的、透明的。
四、广覆盖和高并发,RTS 服务是构建在阿里云 2800+边缘节点之上,可以支持千万级并发播放。
客户接入 RTS 的两种解决方案
一、对于使用云厂商播放 SDK 的客户,升级播放 SDK 后可根据业务灵活选择网络传输协议,打造更高性价比组合。
1.在现有的直播业务新增一个 RTS 播流域名,一个推流两种方式拉流。
2.主播端无需改造,仅升级播放 SDK,播放端自动识别不同 URL 参数。
二、对于自研播放器的客户,阿里云开放与标准 WebRTC 协议对接代码示范,客户自行升级网络模块,底层网络对接更透明。
1.在现有的直播业务新增一个 RTS 播流域名,一个推流两种方式拉流。
2.主播端不用改造,仅升级播放器网络模块,拉取超低延时流播放。
关于低延时+互动体验升级路径的未来展望
在流媒体业务的用户体验升级上,GRTN 今天所带来的不仅仅是延时的降低,另外一个很重要的能力就是 GRTN 所提供的灵活的互动能力,GRTN 让直播和 RTC 的边界模糊,让连麦和会议的界限模糊。在 GRTN 的世界里只有媒体流的发布和订阅关系。
直播:1 人发布多人订阅
1v1 客户端连麦+直播:3 人发布多人订阅,这里的第 3 个发布是来自主播侧的合屏流。
1v1 服务侧连麦+直播:3 人发布多人订阅,这里的第 3 个发布是来自于服务侧的合流发布,当合流发布上来的时候,可以利用 GRTN 的切流能力做到在连麦切换的时候观众无感。
视频会议:多人发布多人订阅,GRTN 的切流能力可以用于会议中的视频大小流(高清晰度和低清晰度)切换。
再配合 GRTN 基于成本和稳定性所提供的分级的时延能力 50ms/250ms/800ms/6s/…,就可以勾兑出不同的场景和产品化能力。
在线教育体验升级
在过去,在线教育比较典型的架构是旁路直播模式,即云端有个基于 WebRTC 的 RTC 媒体中心,老师以及需要实时互动的学员会接入到 WebRTC 频道中,然后由 RTC 媒体中心,转推一路 RTMP 流到直播 CDN,进行旁路直播。
由于直播时延大且协议的不一致性,在这种情况下观看直播的学员如果要切入到 RTC 频道中进行互动,体验是比较差的,有时还会有黑屏中断。
如果希望降低延时并完全解决黑屏问题,那就需要将云端的 WebRTC 双向通信频道的能力也下沉到 GRTN 上,由 GRTN 来承载,将互动和分发进行融合,从而形成一体化的超低延时互动大频道,通过业务层来控制 WebRTC 流的订阅关系,直播和互动频道间不再有明确的界限,可以灵活的根据业务情况按需在 2 种模式间进行切换,而且这种切换对学员和老师都是完全无感的。
电商直播体验的升级
当下的直播带货整体架构和上面讲的在线教育没有本质区别,在架构升级路径上也是可以采用上述同样的思路。这里值得一提的是在使用了 GRTN 后,业务方的技术团队可以将精力更多的集中在做很多创新的事情上。
比如在小主播的带货房间里,以前的互动只有文字或是 1v1 的连麦,接入到 GRTN 后,很容易就可以将这个单向带货介绍的房间改造成一个类似视频会议的多人互动讨论房间,用户互动体验提升后是否也能像时延降低一样带来 GMV 的转换呢?
本篇文章重点介绍的是 GRTN 的服务侧核心能力,希望能给做流媒体技术的同学带来些许启发。
感谢大家的阅读。
阿里云视频云技术公众号分享视频云行业和技术趋势,打造“新内容”、“新交互”。
版权声明: 本文为 InfoQ 作者【阿里云视频云】的原创文章。
原文链接:【http://xie.infoq.cn/article/4f1f578410143ac199677d8eb】。文章转载请联系作者。
评论