数据显示，国内互联网流量每月被消耗 200EB，且 80% 的流量消耗来自于视频领域。随着 5G 的普及，云制播等得到快速发展，流量消耗会越来越大，而这背后是非常高昂的带宽成本。如何通过技术创新，让用户流畅看高清的同时，实现平均带宽成本的持续下降?本文为阿里文娱技术专家七甲的分享，将详解介绍文娱在云边端内容分发领域的最新探索，希望对音视频、泛内容分发领域的技术同学有所启发。
一 节省带宽成本的技术挑战
从实际业务场景出发，节省带宽成本这个命题，在技术上面临非常多的挑战。
第一，优酷服务的终端类型多，移动端有 Android，IPhone，IPad;PC 端有 Window 和 MAC，还有 Web 端，OTT 端等等。不同终端有不同特性，在处理机制上就会不同。即使同一类终端，针对特殊机型也需要做专门适配。
第二，视频业务的种类多。像直播业务，点播业务，缓存下载业务，短视频业务，每种业务所关注的指标都不相同，比如点播会关注播放是否流畅;直播还关注时延;缓存下载主要关注下载的速度。
第三，应用场景的多样化。即使同一业务，也有很多细分场景，处理策略也存在差异。比如直播和点播有智能档，缓存下载有边下边播，点播有倍速播放。不同的网络类型，在处理上也会有所区别。
第四，视频多，长尾视频更多。
- 优酷有海量的资源，而边缘节点的存储是有限的，并不能所有资源都存，需要从中找最热的资源存储。
- 视频格式多，不同的清晰度，会导致供源节点被稀释掉，导致供给不足。
- 显著的长尾特征，大部分视频的单日的播放量少，也需要处理方案。
二 技术策略：云边端内容分发网络
云边端内容分发网络，简称 PCDN，它是以 P2P 技术为基础，通过挖掘海量的碎片化的闲置资源，构建高品质低成本的内容分发网络系统。
PCDN 是一个三级网络加速体系：
- 一级是云，也就是 CDN。
- 二级是边缘网络，包括边缘节点，路由设备，商业 WiFi 等。这些节点不会直接参与消费，主要是作为供源节点，为其它节点提供上行。
- 三级是终端设备，这些设备是流量的主要消费者，其中一小部分能力强的节点，也可以为其它设备供源。
- 当有设备播放视频时，PCDN 网络就可以提供视频加速，保证视频稳定流畅的播放;通过合理地切换从不同节点的下载，让成本降到最低。
从 PCDN 系统架构可以看出，云边端内容分发网络分为三级网络，涵盖十多类节点，每类节点的上行能力，带宽成本，存储能力都各不相同。下面我们从带宽成本，上行能力，存储大小，节点规模，资源定位这五方面，对比一二三级各类节点的能力和特征，最后给每类节点做出定位。
一级节点的上传能力强、服务稳定，但带宽成本很高，所以用它来下载必要的，紧急的数据。
二级节点的上传能力比一级稍差，但 24 小时在线，能提供较稳定的服务，在某些条件下，可用来代替一级使用。
三级节点的上传能力弱，存储又小，也不能保证稳定在线。优势就是规模大，成本低。可以通过多点下载，就近下载，将成本大幅的降低。
所以，根据三种节点特征，扬长避短，最大化的利用每一类节点的优势。比如，三级节点存储小，要最大化利用它的上行带宽，缓存头部非常热的资源。二级节点存储大，能够稳定供源，可以存储中热和长尾的视频。 三 PCDN 底层基石：P2P 的基本原理
云边端内容分发网络，底层用到 P2P 网络技术，这张图是一个简单点的 P2P 模型：
节点 A 和节点 B 都看了《冰糖炖雪梨》的第 12 集，节点 A 先看的，观看后本地会存有一部分数据，当节点 B 在观看的时候，可以直接从节点 A，通过点对点数据传输的方式下载数据，不需要所有数据都从 CDN 下载。 在整个数据的分享过程，可以拆分成资源缓存、节点分配、下载调度和数据分享四个关键环节。
1 资源存储
第一个环节，资源存储。在这个环节中做了三事情：
- 如何标识一个资源?
- 将各类资源归一化，切成一个个固定大小的分片。
- 决定哪些资源该存，哪些资源不该存?
资源标识
要标识一个资源，大家首先会想到的是 URL，但 URL 太长，在交互过程中不方便，并且会增加传输带宽的损耗;另外，URL 中的很多可变元素，比如时间戳，鉴权信息等干扰信息必须去掉，否则会导致同一个视频生成不同的资源 ID，不能相互分享。
优酷有一套资源 ID 的生成算法，会根据 URL 关键特征信息，生成全局唯一的资源 ID，且长度小于 URL 长度，便于交互。
资源分组
第一，优酷有海量的视频资源，有的文件很大，一旦超出缓存上限，就无法在本地缓存整个资源，无法做 P2P 分享，所以说要做切分。
第二，不同的视频格式，比如 HLS 格式，会先请求一个 TS 索引文件，再依次请求每一个 ts。不同的视频格式如果单独处理，逻辑复杂度，且维护成本非常高。所以我们会在下载入口将视频资源做分组，归一成固定大小的文件，统一下载内核，简化逻辑，减少维护成本。
第三，有助于提高分享效率。前面讲 P2P 原理，节点 A 无需等整个视频看完，前面的数据就可以分享。如果以整个视频为单位进行分享，必须等整个视频数据下载完成，效率就会非常低。
第四，提高缓存利用率。一个基本常识，如果将视频按时间切分，每个时间点的播放数并不相同。例如片头片尾，观看的人非常少;另外，细心的同学会留意到，在进度条上方有很多剧情提示，精彩剧情会被反复观看。特别在综艺节目中，当某位明星出现时，观看的次数会明显增多。而对不精彩的剧情呢，很多人会拖拽视频，跳过去播放。所以，在切片之后，我们可以对播放量多的视频多存储，对于播放量少的视频少存储，从而提高整体的资源利用率和 P2P 分享率。
资源存储
消费端在每个分片下载时，都会从服务端请求这个分片对应的节点列表，服务端就可以根据这个分片被请求的次数，来推算出大致的播放量。并且服务端有所有资源的被访问记录，就可以判断哪些分片是热门的，哪些是冷门的。边缘节点在和服务端交互时拿到这个信息，来决定哪些资源该存，哪些不该存。
2 节点分配
第二个环节，是节点分配。在这个环节中包括节点筛选，节点调度和智能分配。
节点筛选
第一个是根据 NAT 类型过滤。所谓的 NAT 就是地址映射，是为了解决 IPv4 地址短缺的问题而引入的。大部分家庭网络终端设备都是在路由下面，实际分配的是一个内网 IP 地址，访问外网会通过 NAT 映射出一个公网 IP 和端口，我们常见的 NAT 类型有四种：全锥形、地址受限型、端口受限型和对称型。其中“对称型和对称型节点”之前、“对称型和端口受限型节点”之间的连通性是非常差的。所以，我们会根据 NAT 类型，将无法连通的节点过滤掉，提供返回的有效节点比例。
第二个是节点质量过滤。在大规模的节点网络中，节点能力参差不齐，如果优质节点和质量差的节点混合在一起，就会增加端侧节点质量评估的成本。因此需要过滤掉质量差的节点，提高返回节点的整体质量。
节点调度
第一个是就近原则。在距离维度上将节点划分成 5 个范围，范围从小到大，依次是：邻近节点，本市，本省，本大区，全国。其中邻近节点主要，指同一个社区，企业，校园等。从数据上看，距离越近，速度越快，延迟会更低。
第二个是能力匹配原则。打个比方，节点 A 的上行能力是节点 B 的两倍，那么在分配次数上，按 2:1 的比例分配节点，这样就能将 A 和 B 节点的上行能力最大化的发挥出来。否则如果按 1:1 的比例分配，可能会出现，A 的上行跑不满，而节点 B 的负载过高等问题。
智能分配
前面的筛选和调度，主要是针对供给侧节点信息的。而动态分配主要是针对消费侧的信息的，就是消费节点在请求节点的时候，会上报一些当前请求的信息，动态计算出需要返回的节点个数，以及不同节点的比例。
第一个是清晰度，清晰度越高，需要的节点个数越多。
第二个是 buffer 水位，当 buffer 水位较低时，多分配一些高质量的节点，提高下载速度;当 buffer 水位较高时，多分配一些低成本的节点，降低带宽成本。
第三个是，不同的节点按一定的比例返回，保证每一种节点都能分配到，同时也给端侧一些决策空间。
3 下载调度
第三个环节，是下载调度。在这个环节中包括调度策略，节点管理和任务分配。
调度策略
在左边这个图形中，下面这个是播放进度条。这个点所在的位置就是播放点，播放点左边的数据，是已经播完的数据，是蓝色的线，播放点右边灰色的这段区间是本地有缓存数据的区间，再往右这段，是将要下载的数据区间，这个点也叫下载点。
在下载调度上，我们的基本原则是：体验优先，兼顾成本。
根据播放点后面，buffer 水位的高低，可以划分成几个区间，红色这个区间，是紧急区，说明当前的 buffer 数据比较少，如果不及时补充数据，可能会影响播放体验，这个区间内主要是从 CDN 节点下载，快速填满 buffer;中间这个区间是过渡区，buffer 数据没有那么紧急了，可以让一部分数据从二三级下载，如果，buffer 水位降低，可以继续用一级下，如果 buffer 水位升高，则可以用二三级接管下载。最右边的区间是安全区，可以全都走二级和三级下载。当然，这里面会有很多细节的策略，比如这两条水位线，并不是固定不变的，而会根据历史卡顿情况，当前网络质量，P2P 节点数和下载速度等，实时决策，动态调整的。
节点管理
首先是节点获取，这里为了节省和服务端交互的损耗，在上一个分片没下完的时候，可以提前获取下一个分片的节点，并且提前建立好一部分连接，等当前分片开始下载的时候，就可以直接发送任务请求。在每个节点的下载过程中，会根据节点的首包时间，下载速度，任务完成数量和质量等信息，给节点打分。最后任务会逐步收敛到质量好的节点上，而质量差的节点，就会被逐步淘汰掉。 任务分配
这里面我们遵循多劳多得的方式，给下载速度快，完成质量好的节点，优先分配任务和分配更多的任务。同时，会监测每个节点当前的下载速度，RTT，提前预判后面的数据，是否会超时，如果预判会超时，就会提前回收任务，再分配给其他节点，而不会死等改任务超时。
4 数据分享
第四个环节，是数据分享。数据分享的过程，其实就是两个节点之间建立连接，发送任务请求，供给端收到后，如果本地有数据，就会返回实际数据。最后在消费端会统一对数据数据做校验，判断是否被篡改，确保数据的一致性，这么一个过程。
节点连接
这里面重点讲一下节点之间的连接，这里说的连接主要指节点间的建立一种连通性，互相发包，对方能收到。节点间的连接主要有三种方式，有直连，反连和打洞三种方式，直连主要是用在对端是公网节点，可直接访问的，比如大部分边缘节点都在公网上，终端设备可以通过直连的方式访问;反连主要是用在，己方在公网，可以直接被访问，对端在 NAT 后面，这时候可以向对方的 Relay 发一个反连请求，由对端的 Relay 转发给这个节点，再由对端发起向自己的直连，这种在己方在公网上，或者是全锥地址类型的时候，可以用。最后是打洞，这种方式，常用在两个节点都在 NAT 后面。
数据传输
节点连通之后，主要就是协议交互和数据传输，这里我们也自研了一种可靠的 UDP 传输方式，同时优化了里面的拥塞控制算法，增加快速启动，丢包预判，快速重传等机制，让传输更加的高效。 数据校验
数据校验是为了保证数据的一致性。在 P2P 网络中，如果有脏数据是非常致命的，因为它会一传十，十传百，快速扩散到整个网络中，污染整个网络数据。针对此，我们也有一套非常完备的方案，从磁盘存储，上传链路，网络传输，下载链路等各环节都增加了校验机制。
常见的校验方法主要有 MD5，CRC 等。MD5 的安全性高，但性能开销大，Crc 的安全性较弱，但性能开销少。我们也采用了 MD5+Crc 相结合的技术方案，对关键数据做 MD5 校验，对非关键数据做 crc 校验，即保证数据一致性，又能最大化降低性能损耗。
通常情况下，剧集的热度越高，越节省成本。因为热剧的播放量大，供源节点多，分享效果好。但是，新片源并不适用这个规律。因为资源缓存需要一个时间窗口，很多热剧热综都会选择在晚间整点发布，用户也会在发布的第一时间观看，而新发布的片源在短时间内，并没有那么多供源节点。在这一时间窗口内，供需非常不平衡，P2P 分享率也比较低。
针对此，我们采用了智能预推和快速回源方案。所谓智能预推，是综合前几集的播放量，同类视频播放量的变化曲线，以及地区，运营商，清晰度等维度的播放信息，计算出需要往哪些地区的边缘节点，推送多少副本数，在新片上线前，提前推送下去。
所谓快速回源，主要是针对不容易预测的，短时间内访问量突然增加的资源，通过回源到边缘节点，让边缘节点快速下载整个视频，对之后再观看视频的节点进行加速。
通过这两个方法，热门剧集上线时，就不用担心没有供源节点，或者供源节点不足，导致分享率低。
大型直播主要指大型活动、体育赛事直播，比如像双11 猫晚、春晚，国庆阅兵直播、世界杯直播等。 直播和点播的场景差异较大，挑战也比点播大，主要表现在几个方面：
- 首先是低延时。为了减少直播时延，在直播场景中实时能拿到的数据量非常有限，并且大家的播放点都是接近的，可供分享的数据非常少，所以会导致整体的供源节点不足。
- 其次是 buffer 水位低。因为数据量有限，一般只能拿到 2-3 个 ts，时长只有几秒到十几秒，这对调度的要求非常高。前面提到的点播的紧急区水位，在几十秒用来抗网络抖动，但是直播不会有那么多 buffer。所以如果调度策略不合理就很容易造成卡顿。但前面让出的 buffer 水位过多，又会减少 P2P 分享。
- 第三是高动态。对于点播来说，只要这个设备已经缓存了该资源，那么不需要用户在线看这个视频，也可以对外分享，和用户行为无关。但是，直播场景并不是这样的，在直播场景中一旦退出直播间，这路流的数据就断了，就不能再为其它节点供源。而在直播过程中，进出直播间是很常见的。
为了提高直播整体的分享率效率，这里我们重点引入了边缘节点。一是将边缘节点作为供给，边缘节点的服务相对是比较稳定的;其次，是边缘节点在数据内容的更新上，会和 CDN 保持高度同步，在大部分情况下用来代替一级。
四 实战经验分享
对于大型复杂的网络系统，需要学会从点线面体不同的视角去看系统，从大到小，层层深入，同时又能够跳出系统，看到系统整体的内外部环境，上下游交互。总体上，需要去理解整体系统的业务模式和运作原理。在面上，需要去熟悉系统各个面的划分和交互，比如 PCDN 里面就包含了调度面，管控面，业务面，基础服务等等。在线上，需要去拆解每个面上的基础功能模块，以及不同层级的划分，比如业务面上，有上传，下载，发布等等。在点上，需要深入了解每个技术点，算法策略等等。
首先，面对一个复杂的网络系统，第一步要做的就是拆解。将一个系统，拆分成几个子系统，明确每个子系统的职能，输入是什么，输出是什么。当然，光拆解还不够，要对每个子系统定义出指标，用来反应系统的优劣，并将所有的指标通过数据和报表展示出来。这样就能看到整个系统的全貌，以及哪里有瓶颈。
其次，技术一定要与业务深度融合，才能发挥最大价值。例如，前文提到的倍速播放，如果在下载调度决策时，不能准确获取播放的倍速信息，就可能误判，导致原来需要从 CDN 下载的时候，没有去下载，造成卡顿。 最后，建模和快速迭代。在整个 PCDN 网络系统中，有很多的场景和功能都可以抽象成日常生活中的模型，例如下载调度算就像一个蓄水池模型，节点调度其实是一个供需模型等等。当建立好模型后，还需要及时的反馈，这其中有很多方式，可以通过压测，用大量样本去训练，还有分桶验证等其他方式，通过这些方式去判断模型的优劣，以及找到模型当中各参数的最优解。
