高清视频下如何节省带宽?-阿里云开发者社区

开发者社区> 阿里技术> 正文

高清视频下如何节省带宽?

简介: 数据显示,国内互联网流量每月被消耗 200EB,且 80% 的流量消耗来自于视频领域。随着 5G 的普及,云制播等得到快速发展,流量消耗会越来越大,而这背后是非常高昂的带宽成本。如何通过技术创新,让用户流畅看高清的同时,实现平均带宽成本的持续下降?本文为阿里文娱技术专家七甲的分享,将详解介绍文娱在云边端内容分发领域的最新探索,希望对音视频、泛内容分发领域的技术同学有所启发。(文末福利:下载《文娱音视频核心技术》电子书)

image.png

一 节省带宽成本的技术挑战

从实际业务场景出发,节省带宽成本这个命题,在技术上面临非常多的挑战。

第一,优酷服务的终端类型多,移动端有 Android,IPhone,IPad;PC 端有 Window 和 MAC,还有 Web 端,OTT 端等等。不同终端有不同特性,在处理机制上就会不同。即使同一类终端,针对特殊机型也需要做专门适配。
image.png

第二,视频业务的种类多。像直播业务,点播业务,缓存下载业务,短视频业务,每种业务所关注的指标都不相同,比如点播会关注播放是否流畅;直播还关注时延;缓存下载主要关注下载的速度。

第三,应用场景的多样化。即使同一业务,也有很多细分场景,处理策略也存在差异。比如直播和点播有智能档,缓存下载有边下边播,点播有倍速播放。不同的网络类型,在处理上也会有所区别。

第四,视频多,长尾视频更多。

  • 优酷有海量的资源,而边缘节点的存储是有限的,并不能所有资源都存,需要从中找最热的资源存储。
  • 视频格式多,不同的清晰度,会导致供源节点被稀释掉,导致供给不足。
  • 显著的长尾特征,大部分视频的单日的播放量少,也需要处理方案。

二 技术策略:云边端内容分发网络

云边端内容分发网络,简称 PCDN,它是以 P2P 技术为基础,通过挖掘海量的碎片化的闲置资源,构建高品质低成本的内容分发网络系统。

image.png

PCDN 是一个三级网络加速体系:

  • 一级是云,也就是 CDN。
  • 二级是边缘网络,包括边缘节点,路由设备,商业 WiFi 等。这些节点不会直接参与消费,主要是作为供源节点,为其它节点提供上行。
  • 三级是终端设备,这些设备是流量的主要消费者,其中一小部分能力强的节点,也可以为其它设备供源。

当有设备播放视频时,PCDN 网络就可以提供视频加速,保证视频稳定流畅的播放;通过合理地切换从不同节点的下载,让成本降到最低。

从 PCDN 系统架构可以看出,云边端内容分发网络分为三级网络,涵盖十多类节点,每类节点的上行能力,带宽成本,存储能力都各不相同。下面我们从带宽成本,上行能力,存储大小,节点规模,资源定位这五方面,对比一二三级各类节点的能力和特征,最后给每类节点做出定位。

image.png

一级节点的上传能力强、服务稳定,但带宽成本很高,所以用它来下载必要的,紧急的数据。

二级节点的上传能力比一级稍差,但 24 小时在线,能提供较稳定的服务,在某些条件下,可用来代替一级使用。

三级节点的上传能力弱,存储又小,也不能保证稳定在线。优势就是规模大,成本低。可以通过多点下载,就近下载,将成本大幅的降低。

所以,根据三种节点特征,扬长避短,最大化的利用每一类节点的优势。比如,三级节点存储小,要最大化利用它的上行带宽,缓存头部非常热的资源。二级节点存储大,能够稳定供源,可以存储中热和长尾的视频。

三 PCDN 底层基石:P2P 的基本原理

云边端内容分发网络,底层用到 P2P 网络技术,这张图是一个简单点的 P2P 模型:

image.png

节点 A 和节点 B 都看了《冰糖炖雪梨》的第 12 集,节点 A 先看的,观看后本地会存有一部分数据,当节点 B 在观看的时候,可以直接从节点 A,通过点对点数据传输的方式下载数据,不需要所有数据都从 CDN 下载。

在整个数据的分享过程,可以拆分成资源缓存、节点分配、下载调度和数据分享四个关键环节。

image.png

1 资源存储

第一个环节,资源存储。在这个环节中做了三事情:

  • 如何标识一个资源?
  • 将各类资源归一化,切成一个个固定大小的分片。
  • 决定哪些资源该存,哪些资源不该存?

资源标识

要标识一个资源,大家首先会想到的是 URL,但 URL 太长,在交互过程中不方便,并且会增加传输带宽的损耗;另外,URL 中的很多可变元素,比如时间戳,鉴权信息等干扰信息必须去掉,否则会导致同一个视频生成不同的资源 ID,不能相互分享。

优酷有一套资源 ID 的生成算法,会根据 URL 关键特征信息,生成全局唯一的资源 ID,且长度小于 URL 长度,便于交互。

资源分组

第一,优酷有海量的视频资源,有的文件很大,一旦超出缓存上限,就无法在本地缓存整个资源,无法做 P2P 分享,所以说要做切分。

第二,不同的视频格式,比如 HLS 格式,会先请求一个 TS 索引文件,再依次请求每一个 ts。不同的视频格式如果单独处理,逻辑复杂度,且维护成本非常高。所以我们会在下载入口将视频资源做分组,归一成固定大小的文件,统一下载内核,简化逻辑,减少维护成本。

第三,有助于提高分享效率。前面讲 P2P 原理,节点 A 无需等整个视频看完,前面的数据就可以分享。如果以整个视频为单位进行分享,必须等整个视频数据下载完成,效率就会非常低。

第四,提高缓存利用率。一个基本常识,如果将视频按时间切分,每个时间点的播放数并不相同。例如片头片尾,观看的人非常少;另外,细心的同学会留意到,在进度条上方有很多剧情提示,精彩剧情会被反复观看。特别在综艺节目中,当某位明星出现时,观看的次数会明显增多。而对不精彩的剧情呢,很多人会拖拽视频,跳过去播放。所以,在切片之后,我们可以对播放量多的视频多存储,对于播放量少的视频少存储,从而提高整体的资源利用率和 P2P 分享率。

资源存储

消费端在每个分片下载时,都会从服务端请求这个分片对应的节点列表,服务端就可以根据这个分片被请求的次数,来推算出大致的播放量。并且服务端有所有资源的被访问记录,就可以判断哪些分片是热门的,哪些是冷门的。边缘节点在和服务端交互时拿到这个信息,来决定哪些资源该存,哪些不该存。

image.png

2 节点分配

第二个环节,是节点分配。在这个环节中包括节点筛选,节点调度和智能分配。

节点筛选

第一个是根据 NAT 类型过滤。所谓的 NAT 就是地址映射,是为了解决 IPv4 地址短缺的问题而引入的。大部分家庭网络终端设备都是在路由下面,实际分配的是一个内网 IP 地址,访问外网会通过 NAT 映射出一个公网 IP 和端口,我们常见的 NAT 类型有四种:全锥形、地址受限型、端口受限型和对称型。其中“对称型和对称型节点”之前、“对称型和端口受限型节点”之间的连通性是非常差的。所以,我们会根据 NAT 类型,将无法连通的节点过滤掉,提供返回的有效节点比例。

第二个是节点质量过滤。在大规模的节点网络中,节点能力参差不齐,如果优质节点和质量差的节点混合在一起,就会增加端侧节点质量评估的成本。因此需要过滤掉质量差的节点,提高返回节点的整体质量。

节点调度

第一个是就近原则。在距离维度上将节点划分成 5 个范围,范围从小到大,依次是:邻近节点,本市,本省,本大区,全国。其中邻近节点主要,指同一个社区,企业,校园等。从数据上看,距离越近,速度越快,延迟会更低。

第二个是能力匹配原则。打个比方,节点 A 的上行能力是节点 B 的两倍,那么在分配次数上,按 2:1 的比例分配节点,这样就能将 A 和 B 节点的上行能力最大化的发挥出来。否则如果按 1:1 的比例分配,可能会出现,A 的上行跑不满,而节点 B 的负载过高等问题。

智能分配

前面的筛选和调度,主要是针对供给侧节点信息的。而动态分配主要是针对消费侧的信息的,就是消费节点在请求节点的时候,会上报一些当前请求的信息,动态计算出需要返回的节点个数,以及不同节点的比例。

第一个是清晰度,清晰度越高,需要的节点个数越多。

第二个是 buffer 水位,当 buffer 水位较低时,多分配一些高质量的节点,提高下载速度;当 buffer 水位较高时,多分配一些低成本的节点,降低带宽成本。

第三个是,不同的节点按一定的比例返回,保证每一种节点都能分配到,同时也给端侧一些决策空间。

3 下载调度

第三个环节,是下载调度。在这个环节中包括调度策略,节点管理和任务分配。

调度策略

在左边这个图形中,下面这个是播放进度条。这个点所在的位置就是播放点,播放点左边的数据,是已经播完的数据,是蓝色的线,播放点右边灰色的这段区间是本地有缓存数据的区间,再往右这段,是将要下载的数据区间,这个点也叫下载点。

image.png

在下载调度上,我们的基本原则是:体验优先,兼顾成本。

根据播放点后面,buffer 水位的高低,可以划分成几个区间,红色这个区间,是紧急区,说明当前的 buffer 数据比较少,如果不及时补充数据,可能会影响播放体验,这个区间内主要是从 CDN 节点下载,快速填满 buffer;中间这个区间是过渡区,buffer 数据没有那么紧急了,可以让一部分数据从二三级下载,如果,buffer 水位降低,可以继续用一级下,如果 buffer 水位升高,则可以用二三级接管下载。最右边的区间是安全区,可以全都走二级和三级下载。当然,这里面会有很多细节的策略,比如这两条水位线,并不是固定不变的,而会根据历史卡顿情况,当前网络质量,P2P 节点数和下载速度等,实时决策,动态调整的。

节点管理

首先是节点获取,这里为了节省和服务端交互的损耗,在上一个分片没下完的时候,可以提前获取下一个分片的节点,并且提前建立好一部分连接,等当前分片开始下载的时候,就可以直接发送任务请求。在每个节点的下载过程中,会根据节点的首包时间,下载速度,任务完成数量和质量等信息,给节点打分。最后任务会逐步收敛到质量好的节点上,而质量差的节点,就会被逐步淘汰掉。

任务分配

这里面我们遵循多劳多得的方式,给下载速度快,完成质量好的节点,优先分配任务和分配更多的任务。同时,会监测每个节点当前的下载速度,RTT,提前预判后面的数据,是否会超时,如果预判会超时,就会提前回收任务,再分配给其他节点,而不会死等改任务超时。

image.png

4 数据分享

第四个环节,是数据分享。数据分享的过程,其实就是两个节点之间建立连接,发送任务请求,供给端收到后,如果本地有数据,就会返回实际数据。最后在消费端会统一对数据数据做校验,判断是否被篡改,确保数据的一致性,这么一个过程。

节点连接
这里面重点讲一下节点之间的连接,这里说的连接主要指节点间的建立一种连通性,互相发包,对方能收到。节点间的连接主要有三种方式,有直连,反连和打洞三种方式,直连主要是用在对端是公网节点,可直接访问的,比如大部分边缘节点都在公网上,终端设备可以通过直连的方式访问;反连主要是用在,己方在公网,可以直接被访问,对端在 NAT 后面,这时候可以向对方的 Relay 发一个反连请求,由对端的 Relay 转发给这个节点,再由对端发起向自己的直连,这种在己方在公网上,或者是全锥地址类型的时候,可以用。最后是打洞,这种方式,常用在两个节点都在 NAT 后面。

数据传输

节点连通之后,主要就是协议交互和数据传输,这里我们也自研了一种可靠的 UDP 传输方式,同时优化了里面的拥塞控制算法,增加快速启动,丢包预判,快速重传等机制,让传输更加的高效。

数据校验

数据校验是为了保证数据的一致性。在 P2P 网络中,如果有脏数据是非常致命的,因为它会一传十,十传百,快速扩散到整个网络中,污染整个网络数据。针对此,我们也有一套非常完备的方案,从磁盘存储,上传链路,网络传输,下载链路等各环节都增加了校验机制。

常见的校验方法主要有 MD5,CRC 等。MD5 的安全性高,但性能开销大,Crc 的安全性较弱,但性能开销少。我们也采用了 MD5+Crc 相结合的技术方案,对关键数据做 MD5 校验,对非关键数据做 crc 校验,即保证数据一致性,又能最大化降低性能损耗。

image.png

通常情况下,剧集的热度越高,越节省成本。因为热剧的播放量大,供源节点多,分享效果好。但是,新片源并不适用这个规律。因为资源缓存需要一个时间窗口,很多热剧热综都会选择在晚间整点发布,用户也会在发布的第一时间观看,而新发布的片源在短时间内,并没有那么多供源节点。在这一时间窗口内,供需非常不平衡,P2P 分享率也比较低。

针对此,我们采用了智能预推和快速回源方案。所谓智能预推,是综合前几集的播放量,同类视频播放量的变化曲线,以及地区,运营商,清晰度等维度的播放信息,计算出需要往哪些地区的边缘节点,推送多少副本数,在新片上线前,提前推送下去。

所谓快速回源,主要是针对不容易预测的,短时间内访问量突然增加的资源,通过回源到边缘节点,让边缘节点快速下载整个视频,对之后再观看视频的节点进行加速。

通过这两个方法,热门剧集上线时,就不用担心没有供源节点,或者供源节点不足,导致分享率低。

image.png

大型直播主要指大型活动、体育赛事直播,比如像双11 猫晚、春晚,国庆阅兵直播、世界杯直播等。

直播和点播的场景差异较大,挑战也比点播大,主要表现在几个方面:

  • 首先是低延时。为了减少直播时延,在直播场景中实时能拿到的数据量非常有限,并且大家的播放点都是接近的,可供分享的数据非常少,所以会导致整体的供源节点不足。
  • 其次是 buffer 水位低。因为数据量有限,一般只能拿到 2-3 个 ts,时长只有几秒到十几秒,这对调度的要求非常高。前面提到的点播的紧急区水位,在几十秒用来抗网络抖动,但是直播不会有那么多 buffer。所以如果调度策略不合理就很容易造成卡顿。但前面让出的 buffer 水位过多,又会减少 P2P 分享。
  • 第三是高动态。对于点播来说,只要这个设备已经缓存了该资源,那么不需要用户在线看这个视频,也可以对外分享,和用户行为无关。但是,直播场景并不是这样的,在直播场景中一旦退出直播间,这路流的数据就断了,就不能再为其它节点供源。而在直播过程中,进出直播间是很常见的。

为了提高直播整体的分享率效率,这里我们重点引入了边缘节点。一是将边缘节点作为供给,边缘节点的服务相对是比较稳定的;其次,是边缘节点在数据内容的更新上,会和 CDN 保持高度同步,在大部分情况下用来代替一级。

四 实战经验分享

对于大型复杂的网络系统,需要学会从点线面体不同的视角去看系统,从大到小,层层深入,同时又能够跳出系统,看到系统整体的内外部环境,上下游交互。总体上,需要去理解整体系统的业务模式和运作原理。在面上,需要去熟悉系统各个面的划分和交互,比如 PCDN 里面就包含了调度面,管控面,业务面,基础服务等等。在线上,需要去拆解每个面上的基础功能模块,以及不同层级的划分,比如业务面上,有上传,下载,发布等等。在点上,需要深入了解每个技术点,算法策略等等。

首先,面对一个复杂的网络系统,第一步要做的就是拆解。将一个系统,拆分成几个子系统,明确每个子系统的职能,输入是什么,输出是什么。当然,光拆解还不够,要对每个子系统定义出指标,用来反应系统的优劣,并将所有的指标通过数据和报表展示出来。这样就能看到整个系统的全貌,以及哪里有瓶颈。

image.png

其次,技术一定要与业务深度融合,才能发挥最大价值。例如,前文提到的倍速播放,如果在下载调度决策时,不能准确获取播放的倍速信息,就可能误判,导致原来需要从 CDN 下载的时候,没有去下载,造成卡顿。

最后,建模和快速迭代。在整个 PCDN 网络系统中,有很多的场景和功能都可以抽象成日常生活中的模型,例如下载调度算就像一个蓄水池模型,节点调度其实是一个供需模型等等。当建立好模型后,还需要及时的反馈,这其中有很多方式,可以通过压测,用大量样本去训练,还有分桶验证等其他方式,通过这些方式去判断模型的优劣,以及找到模型当中各参数的最优解。

福利来了 | 电子书下载《文娱音视频核心技术》

image.png

2019 年,整个互联网的绝大部分流量来自于音视频服务。以优酷为例,每日承载了上亿用户的几十亿的视频观看,每日消耗的互联网流量更是高达 PB 级别。如何让用户体验“更清晰、更省流”,是阿里文娱的核心技术。本书将从媒资生产、播放技术、播控与版权出发,为你详细分析《阿里巴巴文娱音视频核心技术》。

识别下方二维码,或点击文末”阅读原文“立即下载:

image.png

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

关于阿里的技术创新均呈现于此.

官方博客
官网链接