直播，已经成为了“剁手党”们最喜闻乐见的一种购物形式。对直播体验的极致追求，也是淘宝技术人们长期的努力方向。为了提升用户购物体验，让直播更加丝滑，让剁手更快一些，在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/VP8/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借鉴数字孪生的思想设计了一个流媒体孪生(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的服务侧核心能力，希望能给做流媒体技术的同学带来些许启发。感谢大家的阅读。
作者：子融，阿里云高级技术专家，负责阿里云视频直播产品和流媒体实时加速平台研发
本文为阿里云原创内容，未经允许不得转载。
