基于标准 WebRTC 低延迟直播的开源实践

自上世纪末，流媒体直播技术兴起以来，伴随着网络基础设施的发展脚步，直播也同频共振般地起势。而近年来 AI、云计算、音视频等技术日趋成熟，以及新冠肺炎疫情带来的“宅经济”刺激，使直播行业的发展势头被进一步激活。

通过网络直播，你可以轻松观看到大洋彼岸正在进行的紧张体育赛事，也可以足不出户就阅尽祖国的大好河山、日出日落，甚至与 6000 万陌生人一起“云监工”火神山医院建设进度，为疫情防控力量点赞。

直播是个好东西，但，直播延时并不是。

或许你曾熬夜守在电商直播间，在秒杀倒计时中，因延时被人捷足先登；也或许在上网课时，因延时错过了重要的知识点；还或许在体育比赛关键时刻，因延时被提前“剧透”了结果。

凡此种种的破坏性体验，皆是「延时」惹的祸，市场对低延时的直播方案提出了需求。

在介绍低延时直播方案前，我们先来看看当下典型的直播架构。

1、典型的直播架构

在典型直播架构中，左边是推流客户端，协议上才采用RTMP上行。右边是拉流客户端，支持不同的拉流协议拉流，比较常见的是：RTMP, FLV, HLS。

现有架构的优点

这套框架很好的利用了CDN厂商或者说云厂商的能力。尽管拉流协议没有统一，但由于rtmp/flv/hls等拉流协议是比较成熟的流媒体协议，经过多年的发展，各家CDN厂商广泛支持。在云端能力的支持下，服务端并发能力和拉流端加速能力大大增加了，直播行业蓬勃发展。

2、低延迟直播的现状

直播行业里卡顿和延迟就像是天平的两端。延迟做的越短，卡顿越高。延迟越长，卡顿越少。

一般场景下都是客户端用更大的buffer时长，牺牲延时来满足流畅性。随着行业的发展，在某一些应用场景对延时时间的要求越来越苛刻，比如体育比赛直播，教育场景下老师学生互动等，这时候现有常见的直播流媒体协议的缺点就体现出来了。

一般rtmp协议直播延时在3-10s，如果经过层层CDN的缓存和转发，超过10秒也是常有的事，flv和hls协议的延时更高。就拉流端来说，延迟很大一部分源自网络传输：

rtmp在传输媒体前的tcp 3次握手和c0/c1/c2握手协议，无端引入了好几个RTT的延迟；由于rtmp/flv/hls的传输层都是基于tcp协议的，在网络不稳定的情况下，受限于tcp协议的拥塞控制不能充分利用网络带宽，客户端为了保持流畅性，只能加大缓存时间，更进一步加大了延迟。

其实认识到现有流媒体直播协议的局限性，各大友商也纷纷推出了自己的低延时直播，也比较好的起到了对抗弱网和加快首屏的作用。

**但目前大家大都基于私有的信令协议和基于私有的UDP的流媒体传输协议，各大云厂商没法互相兼容，这就限制了低延迟直播的大规模发展。

3、基于标准 WebRTC 的低延迟直播的开源实践

我们在探索如何能做一个开放的低延时直播方案，将来各家云厂商也能够比较方便的实现，就像现有rtmp/hls协议一样，推动整个直播行业低延迟化。

要实现这种方案需要做两件事情：