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

直播 , 已经成为了“剁手党”们最喜闻乐见的一种购物形式 。 对直播体验的极致追求 , 也是淘宝技术人们长期的努力方向 。 为了提升用户购物体验 , 让直播更加丝滑 , 让剁手更快一些 , 在2020双十一期间 , 淘宝首次启用了阿里云CDN的GRTN全球实时传输网络 。 数据显示 , 和传统的HTTPFLV/RTMP方式相比 , 在启用了GRTN后 , 直播端到端的延时降低了83% 。 那么 , GRTN到底是什么?其背后究竟隐藏了哪些核心技术?
这篇文章会通过回顾互联网直播技术的发展历程 , 深度剖析直播延时的技术挑战 , 并解读阿里云全球实时传输网络GRTN的设计思路、技术原理、特质与应用实践 , 以及GRTN在摆脱传统直播技术所面临的内卷化(Involution)窘境所作出的尝试 。 GRTN不单单是为互联网直播而设计 , 诸如时音视频RTC等流媒体技术的使用者 , 比如云会议、云游戏、云桌面等 , 在将业务迁移至GRTN后可以有什么新玩法和创新机遇?本文将为您解答 。
互联网直播技术的进化趋势互联网直播技术的发展大致可以被分为了4个阶段:分别是创新期、演进期、量产期和瓶颈期 。
2020双十一,阿里云GRTN拉开直播和RTC技术下半场序幕文章插图
互联网上的第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个步骤:分别是采集、编码、发送、分发、接收、解码和渲染 。
2020双十一,阿里云GRTN拉开直播和RTC技术下半场序幕文章插图
其中采集+编码 , 解码+渲染总体延时比较固定 , 共100ms左右 , 变动比较大的部分是分发和接收 , 从数十毫秒到数秒不等 , 主要取决链路时延抖动、协议栈的优化情况 , 以及CDN资源的覆盖情况 。
在传统的架构里 , 这个7个环节相互独立 , 互不相干 , 这样做的好处是团队分工比较明确 , 但问题就是优化手段很难做到跨界融合 , 导致无法做到系统级优化 。 比如 , 编码器如果可以考虑发送时的拥塞情况来实时调整码率就可以一定程度上缓解拥塞 , 从而降低延时;再比如传统的流媒体传输中媒体数据发送和底层的传输是相互独立的 , 底层TCP传输的拥塞控制算法是个通用算法 , 不会考虑媒体的特性 , 这样的一个分层结构是很难形成即时反馈系统的 , 那么为了保障流畅度 , 缓存区的大小设计会相对保守 , 从而牺牲了端到端的时延 , 如果传输层和应用层是一体化的 , QoS控制针对媒体特性来专门设计 , 同时配合编码侧的码率控制 , 就能通过组合拳的方式 , 大大地降低延时 。