黑基Web安全攻防班
黑基网 首页 IT技术 网络管理 查看内容

阿里云CDN高级技术专家阙寒:Tengine直播最佳实践

2018-7-6 00:19| 投稿: xiaotiger |来自: 互联网

摘要: 在上周刚落幕的开源人盛会IT人也迎来了开源盛会LinuxCon + ContainerCon + CloudOpen中国(简称LC3)大会上,阿里云CDN团队的高级技术专家阙寒(花名),为大家分享CDN在使用Tengine构建直播系统的一些实践。Tengine ...

在上周刚落幕的开源人盛会IT人也迎来了开源盛会LinuxCon + ContainerCon + CloudOpen中国(简称LC3)大会上,阿里云CDN团队的高级技术专家阙寒(花名),为大家分享CDN在使用Tengine构建直播系统的一些实践。

Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上,针对大访问量网站的需求,提供更强大的流量负载均衡能力、全站HTTPS服务、安全防攻击、链路追踪等众多高级特性。团队的核心成员来自于淘宝、搜狗等互联网企业,从2011年12月开始,Tengine成为一个开源项目,团队在积极地开发和维护着它,最终目标是打造一个高效、稳定、安全、易用的Web平台。

阙寒分享的题目为Tengine直播最佳实践,整个分享分为三个部分,第一部分是对直播整体介绍和音视频知识普及,第二部分是系统软件的架构,第三部分是和服务质量相关的内容。以下为分享内容全文。

在分享的最初,阙寒简单介绍了阿里云直播的整体解决方案,覆盖了推流端、直播中心、CDN分发网络和播放端。推流端一般是通过DNS调度后访问就近的CDN节点,将直播流推到边缘节点,经过边缘节点加速后经过直播中心,在直播中心进行转码、截图、录制、水印、切片等直播处理,播放的时候也是先经过DNS调度,访问就近的边缘节点,当节点MISS的情况下,会访问直播中心将这路流拉到边缘。

对于推流来讲,一般都是RTMP协议,播放包括RTMP、FLV、HLS三种协议,前两种协议都是流式的播放,一般延时在3秒左右。HLS是文件的分发,延时在10秒左右。对于音视频格式,音频主要支持ACC,视频支持H264和H265。

流式直播

RTMP和FLV这两种协议是流式直播,它的特点就是长连接,一个推流或者一个播放连接可能会持续几十分钟、甚至几个小时,在长连接上传输的数据就是一帧一帧的帧数据,每一帧数据都是FLV tag形式封装的。

发布与订阅

对于直播来讲,推流和播放是一种非常典型的发布和订阅的关系。两台Tengine服务器,有两路流,第一路流是主播推流发布,两个播放端形成订阅关系。第二路流发布并不是主播推流,而是从另一台Tengine服务器拉流形成发布,三个播放端形成订阅。正是这种机器与机器,节点与节点之间的级联关系,就构成了CDN的分发网络。

音视频帧

对于音频来讲,音频帧一般是可以独立编解码的,播放端在得到任何一帧音频帧都可以直接渲染出声音来。但是视频就不太一样,视频帧分为关键帧和非关键帧,关键帧具备独立编解码的能力,而非关键帧就依赖于关键帧才可以进行渲染。关键帧携带的信息量比较多,几K甚至10几K大小,非关键帧只有几K,甚至1K以内。两个关键帧之间的间隔称之为1个GOP。对于视频播放来讲,一定先从视频关键帧开始发送,不然播放端就花屏,要么就需要等到下一个关键帧出现为止。

其实对于静态文件加速来讲,服务器上存储的都是静态文件的内容,内容的访问是不会变更的。但是对于直播来讲,服务器上缓存的数据会随着时间的推移而变化,永远缓存最近出现的视频关键帧序列。下图第一排描述了前一时刻,服务器缓存了这一部分视频关键帧,第二排就是当新的关键帧出现了,缓存的数据也向后移动,前面的数据会被删除掉。

比如一场直播有两个小时,从头到尾7200秒,假设这个视频流10秒一个关键帧,就意味着会出现720个关键帧,也就是服务器存储的数据会更换720次。

时间戳

对音视频来讲,另一个比较重要的属性就是时间戳。正常来讲,视频流的音频和视频的时间戳都是单调递增的。而且任意时刻,两者之间的时间戳不会相差太大。

线上比较多出现的异常情况有三种:第一是主播端推流,时间戳回退,直接跌零,第二是时间戳随时时间增长,四个字节表现不下,会出现回滚溢出,从零开始;第三是音频和视频的时间戳本身是单调递增,当把两者叠合在一个世界轴上的时候,就不是单调递增了,可能会出现各种回退的情况。

这三种情况都是对服务器对计算缓存大小的时候,出来一些异常,非常影响观看体验。所以建议在推流的时候,推流端时间戳尽量保持单调递增,尽量避免如上三种情况的发生。

音视频头

一般来讲,音视频头要先于其他音视频帧发送的,因为播放端会依赖它来进一步解析。服务器本身也支持推流端不断开重推的时候,切换音频头和视频头。

系统软件架构

这幅图大概列了一下阿里云CDN的网络架构,推流端会经过边缘节点、二级节点的加速,推到直播中心。对于播放来讲,也是就近访问边缘节点,MISS的话会访问二级节点,还是MISS会访问直播中心。

直播中心

直播中心有两个组件,一个是Tengine流媒体直播服务器,另一个是调度组件。因为直播中心可能会承载成千上万甚至十几万的路流,这里引入调度组件是为了做负载均衡,确保如此多路流能够平均负载在每台机器上,同时也能够进行流的查找。这样的话,在推流的时候,根据负载均衡去分配一台负载相对比较低的机器,播放的时候,也比较明确的知道这路流在哪台机器上,然后进行返回。

单机推流和播放

对于流媒体服务器来讲,一个核心要解决的问题就是单机的推流和播放的问题。在阿里云这边,Tengine主要使用多进程的工作模式,首先要解决的问题是:如果推流请求和播放请求不是一个进程处理的情况下,如何能让播放看到画面?

早期的架构比较简单,第一个进程接受到进程后,它会同时把这路流推给其他所有worker,这样保证其他worker都有这路流,播放到任何worker都无所谓。这个架构撑了一段时间,我们就发现缺点很明显,当这台机器出现两三百路流的时候,负载就会非常高,而且这个架构没办法通过增加CPU的个数来解决负载高的问题。所以我们进行了一段改进,把主动的push改成被动的pull。第一个worker接收到推流后,不主动推给其他任何worker,如果播放被其他worker捕获的话,处理播放请求的worker会从接受推流的worker处发起一次拉流,这里面worker之间通信使用Unix套接字,并使用共享内存记录每路流和每路worker之间的对应关系,当然也包括一些异常处理。

在这个模式下,我们进行常规压测,大约一台机器可以到两三千路流。

其次,每台机器也会提供和流操作的相关接口。包括单路流的查询,这台机器一共有哪些推流,和断开推流、断开播放等操作。

边缘节点

对于边缘节点或二层节点来讲,大概是下图的架构。右边是接受推流,Tengine接受到推流后,直接转给直播中心,对于播放来讲,需要先经过一致性hash,减少回源流量,再进行回源拉流。一致性hash,确保一个节点上对于一路流来讲,只有一台机器回源,节省了从L1节点到二层节点的流量。

拉流合并

在Tengine的多进程模式下,虽然有了一致性hash,但是这台机器可能有多个worker,早期模式是每个worker有多个播放的时候,各自回源。Worker数越多,回源数越多。所以我们做了一次拉流合并的操作,一个worker在回源的时候,会先进行共享内存的查找,如果没有的话会自己发起回源,如果有的话它会向已经回源的worker进行一次拉流,这样来确保最终回源机器只有一个进程在回源。这里也包括异常处理,和回源连接断开、重试等逻辑操作。经过一致性hash和拉流合并的处理,基本能确保一个节点上,对于一路流来讲只有一个回源连接。

另外,很多直播平台,都会要求各家CDN在自己分发的同时,也转推给其他家。阿里云主要在边缘节点完成这些动作,在回转推中心的同时,也会转推给友商或客户源站。这里使用了动态配置来支持功能,并且转推机制也支持重试和地址重新获取。

服务质量——首屏

第一个比较重要的就是首屏,播放端从点击播放到能看到画面的时间差。阿里云对于首屏做了这么几点优化,一个是各级的Tengine服务器保留这路流的gop cache,确保每一个播放都从关键帧立刻开始发送,同时这里还要减少各级之间无效数据的传输,如果节点之间传输了5M数据,推给客户端4M数据,1M数据对于客户播放是无效的,这块其实对首屏也有影响。其次,还要减少服务器以之间及节点之间的RTT交互。

其实对于首屏来讲,除了软件上要做性能调整外,更重要的一点还是服务器自身的数据收集。这里大概列了一下,服务器端针对一次播放,采集的一些数据,第一列是时间点,第二列是每秒发了多少视频帧,第三列从服务器角度来看,发送一定数量的视频帧大概花了多少时间。

这里面我们记录到这次播放是5毫秒,边缘命中了,在5毫秒内立刻发送200毫秒的时间戳,或者统计80帧的时间消耗。做这个采集是为了和客户端的打点日志进行匹配,有可能服务端记录的数据好得不得了,但是客户端打点日志首屏很差,所以可以进行匹配。这里面可以涉及其他问题,比如DNS解析时间,服务端统计不到,播放端和服务器行为不匹配,造成首屏渲染很差。

服务质量——卡顿

关于卡顿,从网络链路上来讲,有以下几个方面优化。

第一可以针对上行链路进行优化。主播一般会通过LOCAL DNS进行解析,获取就近边缘节点,其实我们更推荐用HTTPDNS,这样调度会更准确。第二针对下行覆盖,优先使用本地覆盖,在水位不够等情况下,退而求其次使用大区覆盖。对于内部传输可能出现的抖动,我们引入了各种切换和传输优化机制。

另外,对于音视频帧来讲,推流的码率可能也会造成卡顿,码率越高卡顿更严重,尤其是弱网客户对于高码率会有更高的卡顿。

在服务器端,会做链路监控和采集,来判断卡顿的原因,正常来讲音视频帧的每秒帧数是固定的。应该是一条平滑的直线,如果出现下图的突刺,一定是链路出现了抖动,播放的直观感受就是卡了一次。

我们也会采用全链路监控,来记录每一个链路服务质量,使用不同颜色标注出链路的好坏。红色那条一定是出现过严重抖动。同时我们也会在每条链路上收集比较详细的数据。媒体层会记录音频帧率、视频帧率,码率、时间戳等数据,从业务层,会记录首屏、卡顿、错误码等数据,传输层会记录RTT、重传、拥塞窗口等等。记录的信息越详细,问题越容易发现。

我们也会记录一些比较详细的访问日志,分析卡顿的原因。从服务器端角度来看,如果出现下行堆积,丢帧等等情况,可能是网络覆盖的问题。如果与客户的打点日志去匹配的时候,发现播放一切正常,还是报卡,那就需要对齐数据。


小编推荐:欲学习电脑技术、系统维护、网络管理、编程开发和安全攻防等高端IT技术,请 点击这里 注册黑基账号,公开课频道价值万元IT培训教程免费学,让您少走弯路、事半功倍,好工作升职加薪!

本文出自:https://www.toutiao.com/a6574703104799801863/

免责声明:本文由投稿者转载自互联网,版权归原作者所有,文中所述不代表本站观点,若有侵权或转载等不当之处请联系我们处理,让我们一起为维护良好的互联网秩序而努力!联系方式见网站首页右下角。


鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

最新

返回顶部