CDN直播讲解

到处都在谈直播,直播技术目前越来越大众化,但也面临着更多的挑战。本次分享主要介绍直播的一般流程,cdn的技术原理及架构,CDN直播技术的难点和对应的解决方案。希望能够给大家带来帮助,更希望能推动实时直播技术的改进和改革。下面是本文的要点:

  • 直播的一般流程;

  • CDN的技术原理及架构;

  • CDN直播的技术难点和应对方案;

  • 基于SD-RTN的,针对低延迟、强互动场景的直播技术。

直播的流程

640?wx_fmt=png

正如上图所示,整个直播流程分为以下几个关键步骤:

  • 主播客户端,将本地采集的视频推送到CDN;

  • CDN对视频流进行缓存以及转发;

  • 观众客户端,拉取CDN中缓存视频流进行播放;

可以看到CDN在这里起到了关键的作用,2016也是一个CDN崛起的年代,网宿、快网、七牛、高升、蓝汛、观止云、腾讯云、百度云、阿里云等CDN纷纷表示对直播进行了支持,直播也逐渐成为了CDN的标配。

那么接下来了解一下CDN的技术原理。

CDN技术原理

CDN的全称为Content Delivery Network,即内容分发网络,是一个策略性部署的整体系统,主要用来解决由于网络带宽小、用户访问量大、网点分布不均匀等导致用户访问网站速度慢的问题。

640?wx_fmt=png

CDN的技术原理见上图,具体实现是通过在现有的网络中,增加一层新的网络架构,将网站的内容发布到离用户最近的网络节点上,这样用户可以就近获取所需的内容,解决之前网络拥塞、访问延迟高的问题,提高用户体验。

对于直播来说,则将Web服务器换作主播客户端,如下图所示。

640?wx_fmt=png

由于视频占用带宽较大,与普通的Web服务差别较大,这样CDN的优势更能体现出来:网络拥塞减少,访问延迟降低,带宽得到良好的控制等等。

另外,CDN直播中常用的流媒体协议包括RTMP、HLS、HTTP FLV等。

  • RTMP(Real Time Messaging Protocol)是基于TCP的,由Adobe公司为Flash播放器和服务器之间音频、视频传输开发的开放协议。

  • HLS(HTTP Live Streaming)是基于HTTP的,是Apple公司开放的音视频传输协议。

  • HTTP FLV则是将RTMP封装在HTTP协议之上的,可以更好的穿透防火墙等。

CDN的常用架构

CDN架构设计比较复杂,并且不同的CDN厂商,对其架构进行不断的优化,所以架构也不能统一而论。这里只是对一些基本的架构进行简单的剖析。

CDN主要包含源站、缓存服务器、智能DNS、客户端等几个主要组成部分。

源站是指发布内容的原始站点。添加、删除和更改网站的文件,都是在源站上进行的;另外缓存服务器所抓取的对象也全部来自于源站。对于直播来说,源站为主播客户端。

缓存服务器是直接提供给用户访问的站点资源,由一台或数台服务器组成;当用户发起访问时,他的访问请求被智能DNS定位到离他较近的缓存服务器。如果用户所请求的内容刚好在缓存里面,则直接把内容返还给用户;如果访问所需的内容没有被缓存,则缓存服务器向邻近的缓存服务器或直接向源站抓取内容,然后再返还给用户。

智能DNS是整个CDN技术的核心,它主要根据用户的来源,以及当前缓存服务器的负载情况等,将其访问请求指向离用户比较近且负载较小的缓存服务器。通过智能DNS解析,让用户访问同服务商下、负载较小的服务器,可以消除网络访问慢的问题,达到加速作用。

客户端即发起访问的普通用户。对于直播来说,就是观众客户端。

对于直播来说,CDN整体架构如下图:

640?wx_fmt=png

主要流程为:

  1. 主播开始进行直播,向智能DNS发送解析请求;

  2. 智能DNS返回最优CDN节点IP地址;

  3. 主播端采集音视频数据,发送给CDN节点,CDN节点进行缓存等处理;

  4. 观众端要观看此主播的视频,向智能DNS发送解析请求;

  5. 智能DNS返回最优CDN节点IP地址;

  6. 观众端向CDN节点请求音视频数据;

  7. CDN节点同步其他节点的音视频数据;

  8. CDN节点将音视频数据发送给观众端;

说了这么多CDN的技术和原理,不知道您看累了没,那么CDN直播是否万事大吉了呢?接下来分析一下CDN的难点和解决方案。

CDN难点:播放延时

一提到直播,大家肯定会想到播放延时的问题,那为什么会播放延时了?我们从以下几个方面分析:

1. 网络延时

网络延时这里指的是从主播端采集,到观众端播放,之间的时间差。这里不考虑主播段采集对视频进行编码的时间,以及观众端观看对视频进行解码的时间,仅考虑网络传输中的延时。例如说下图中的网络延时:

640?wx_fmt=png

假设在该链路上有缓存,时间为Tmax_cache ,那么从主播到观众的延时Tdelay为:

640?wx_fmt=png

另外,数据传输过程中还涉及到逻辑上的交互,例如包的重传以及确认,以及缓存上的一些逻辑等,会在这个基础上又增加很多。

那么来简单估算一下大概的网络延时。众所周知,光在真空中的速度约为300,000km/s,而在其他介质中光速会大大降低,所以在普通光纤中,工程上一般认为传输速度是200,000km/s。从现实上来说,可以参考如下:

路线 距离(km) 往返时延(ms)
北京到上海 1,200 12
北京到纽约 11,000 110
赤道周长 40,000 400

所以说,在节点较少、网络情况较好的情况下,那么网络延时对应也是最小,加上一定的缓存,可以控制延时在1s~2s左右。但是节点多、网络差的情况下,网络延时会对应增大,经验来说延时可以达到15s以上。

2. 网络抖动

0?wx_fmt=png

0?

如上图所示,主播端t3和t5发出的包,分别在t3'和t5'到达,但是中间延时增大,即发生了网络抖动。这样造成观众端观看视频的延时会不断增大。

3. 网络丢包

CDN直播中用到的RTMP、HLS、HTTP FLV等协议都是在TCP的基础之上。TCP一个很重要的特性是可靠性,即不会发生数据丢失的问题。为了保证可靠性,TCP在传输过程中有3次握手,见下图。首先客户端会向服务端发送连接请求,服务端同意后,客户端会确认这次连接。这就是3次握手。接着,客户端就开始发送数据,每次发送一批数据,得到服务端的“收到”确认后,继续发送下一批。TCP为了保证传到,会有自动重传机制。如果传输中发生了丢包,没有收到对端发出的“收到”信号,那么就会自动重传丢失的包,一直到超时。

640?wx_fmt=png

由于互联网的网络状况是变化的,以及主播端的网络状况是无法控制的。所以当网络中丢包率开始升高时,重传会导致延时会不断增大,甚至导致不断尝试重连等情况,这样不能有效的缓存,严重情况下会导致观众端视频无法观看。

解决方案

0?wx_fmt=png

CDN与SD-RTN对比情况如下:

  • 基本原理不同。CDN是存储转发结构,设计目的是在各个边缘节点缓存待分发内容,结构上从源站到观众是伞状多级缓存放大方式。SD-RTN本质上一个实时传输网络,用户的数据在网络单元内部和传输线路上都以实时交换方式传送,UDP实现的传输协议,不会因为前一个包的丢失或延迟导致下后续包的延迟送达,而丢包可以用对延迟更友好的方式修复或补偿出来,从而能够保证最低延迟。

  • 底层协议不同。SD-RTN采用了专为实时传输设计的UDP协议,避免了采用TCP的延时不可控缺点。能够大大缩短交互延时,延时可从CDN方案的数秒,降低到数百毫秒。

  • 内容分发机制不同。SD-RTN是基于自定义路由,选择最优传输路径,直接将内容端到端传输,数据在网络单元中从不缓存,从而最大可能的降低延迟,同时内容安全性也更好。CDN是将内容缓存于缓存服务器中,再将内容就近下发,所以CDN更适合做内容分发,一对多的场景。

  • 使用场景不同。SD-RTN适用于要求极低时延的实时互动场景,例如网络电话、视频会议、有主播与观众交互需求的互动直播等。CDN适用于对时延要求不高的场景,例如对延时要求不高、类似电视的单点直播、网站加速等。

SD-RTN的优势如下:

  • 时延大大缩短。直播延时可从基于TCP的方案的数秒,降低到数百毫秒。这一延迟范围,属于实时通信或准实时通信延迟的范畴。在这一级别上,主播和观众可以基本重现在现场活动中的交互体验,从而大大释放了内容制作者的潜力,也为业务运营者创造新业务形式打开了无限的空间和可能。

  • 抗丢包能力强。一般来说,SD-RTN中可以针对用户网络使用更多的策略模型和技术,这样在30%丢包时,依然能够进行正常直播。而基于TCP的直播方案在丢包2%时就明显卡顿,达到30%经常已断开连接,无法进行直播。

CDN难点:连麦

直播中,主播如果要与用户交互,常见有两种方式:

  • 第一种方式:文字,这种比较常见,实现也比较简单,这里不再进行分析;

  • 第二种方式:连麦,这样主播可以面对面与观众进行交互,增加了互动性;

由于连麦方式比较复杂,这里进行详细分析。

1. 多路RTMP流实现

前面提到,RTMP是目前主播中最常用的协议,使用RTMP协议,可以实现最简单的一种连麦方式,如下图。

640?wx_fmt=png

当有连麦者时,则主播端和连麦者端,都分别推一路RTMP流到CDN,CDN再将这两路RTMP流发送给观众端,观众端将两路RTMP流合成为一个画面。这种方式的优点是实现简单,但缺点比较多:

  • 主播与连麦者如果要进行交互,则考虑到上面分析的延时问题,在这里延时需要至少加大一倍,这样对于实时交互来说,完全无法接受;

  • 主播与连麦者交互时,声音会产生干扰,形成回音;

  • 观众端要接收两条视频流,带宽、流量消耗过大,并且两路视频流解码播放,耗费CPU等资源也非常多;

这样看来,这种方式弊大于利,基本不可取。

2. 主播端与连麦者P2P

第二种方式,是主播端与连麦者之间使用P2P方式进行交互,然后主播端将自己和连麦者的视频进行合并,再推到CDN上,CDN再发送给观众端,如下图:

0?

这种方式的优点有两个,一是主播和连麦者之间使用P2P,网络质量较好,延迟较小,保证了两者之间交互不会有非常大的延时;二是可以解决声音的干扰问题,消除回声。缺点是:

  • P2P在某些网络下无法穿透,有些观众根本无法与主播端进行交互;

  • 主播端需要上传两路视频:一路P2P与连麦者进行交互,一路使用RTMP推到CDN。还要下载一路视频:连麦者P2P发送过来的交互数据。所以主播端要求带宽需要较高,网络较差时无法进行主播;

  • 主播端要进行多路视频的编码、解码,要求主播端设备配置比较高,较差的设备也无法进行主播;

  • 只能支持一个连麦者,不能支持多个连麦者;

  • 由于主播端和连麦者经过CDN合并成一路,因此,不能实现主播端和连麦者视频大小窗口切换。

综合来说,P2P方式在一定程度上可以解决连麦的问题。

3. 服务器端合图

另外一种方式,是主播和连麦者都将视频推送到CDN中,然后CDN内部对这几路视频进行合图,再将其发送给观众端。如下图:

640?wx_fmt=png

这种方式的优缺点如下:

优点

  • 主播和连麦者各路视频都使用RTMP推送到CDN,可以保证延时较小;

  • 由于CDN进行视频合图和发送,所以主播不需要很高的带宽;

  • 由于CDN进行视频合图,所以主播的设备不需要配置非常高;

  • 没有声音干扰问题;

  • 可以支持多个连麦者连麦;

缺点

  • CDN需要进行视频的合图,需要额外开发工作,并且逻辑比较复杂;

  • CDN需要进行视频的合图,需要消耗较高服务器资源;

  • CDN合图后的布局难控制;

  • 据目前所知,还没有CDN支持这种方案;

解决方案

具体SD-RTN的架构可以参考下图:

640?wx_fmt=png

原文连接:https://blog.csdn.net/emprere/article/details/98858134

原创文章,作者:优速盾-小U,如若转载,请注明出处:https://www.cdnb.net/bbs/archives/31973

(0)
上一篇 2024年8月15日 10:52
下一篇 2024年8月15日

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

优速盾注册领取大礼包www.cdnb.net
/sitemap.xml