作者| 阿里文娱高级技术专家 木暮
一、背景
2019 年，整个互联网的绝大部分流量来自于视频服务，优酷，每日承载了上亿用户的几十 亿的视频观看，每日消耗的互联网流量高达 Pb 级别。在如此高并发高流量的项目中，如何在保 障用户体验的前提条件下，有效的提升服务器以及带宽的利用效率，实现消峰填谷，降低服务 器和带宽成本，成为我们技术人的工作重心。
二、痛点与挑战
每天晚上，为了保障所有用户的流畅高清的观看体验，至少需要几十 Tb 的高峰期带宽， 这会带来哪些问题呢？
1. 服务器数量大
按照单台服务器万兆的输出来保守估算，至少需要几千台服务器，还不包括交换机等设备， 无论网络的搭建还是维护，成本非常高。
2. 带宽成本高
商业带宽成本非常昂贵，按照几十 Tb 来进行带宽采购，费用将是天文数字。
3. 资源利用效率低
白天使用的带宽，可能只有晚高峰的十分之一，将造成巨大的资源浪费。
三、PCDN 核心设计
PCDN 是阿里自研的以 P2P 技术为基础，通过挖掘、利用、整合边缘网络而构建的内容分发网络。通过 PCDN 的服务，能获得同等甚至高于 CDN 的内容分发质量，同时显著降低分发 成本，尤其适用于视频点播、直播、文件下载等业务场景。
接下来，我们分别来阐述一些系统核心模块的设计思路与实现方案。
1. 三级分发体系
整个 PCDN 分发网络，由云+边缘节点+端的三级网络组成。PCDN 采用同一套跨平台的代 码研发，消除了在不同终端上的差异性。另外在二级边缘节点和三级的端之间，协议可以互相通信。
云：包含 CDN 节点、播控、Tracker、Stun、Push 等服务。
边缘节点：包含类玩客云、类优酷路由宝、合作节点、矿机、运营商 MEC 等边缘节点。
端：包含 PC(Windows、Mac)、手机（iPhone，Android Phone）、平板(iPad，Android Pad)、
OTT 等日常使用设备。
2. 统一的资源编排
对于 PCDN 网络中的任何一个资源，无论是单一的视频、文件，还是一路直播流，又或者 是一个 HLS 的播放列表，制定一种统一的、超越文件格式的资源编排方式是高效分发的基础。 在优酷，我们提出了主资源ID+子资源 ID 的方式来构建资源的编排。
1）主资源 ID
对于任何的一个视频/文件/直播流来说，主要资源 ID 是一个唯一的类 guid 格式的字符串(例如EADCAB58E5664965A9C3201D72F816CF)。
2）子资源 ID
对于某个视频/文件/直播流来说，按照我们预定的规则（大小切分或者时间切分），逻辑切分出来的每个传输段落，我们在主资源 ID 后面加上 0001、0002 来顺序生成每个子资源 id(例如EADCAB58E5664965A9C3201D72F816CF0001)。子资源 ID 不仅可以独立作为 PCDN 网络中唯一标识进行索引，同时，在必要的时候，云端也有能力可以通过主资源 ID 来感知每个子资源ID 对应内容之间的联系和分布。
3. 运营商地域的节点调度
1）运营商隔离 当节点充足时，会完全隔离某个运营商，在该运营商内部进行地域优先调度；当节点不够时，依然会跨越运营商，尽可能的去寻找全网中所有的网络供源节点。
2）地域就近优先 地域优先的节点调度策略，不仅有效的提升了节点间的传输速度，降低了丢包，而且从宏观来看，降低了骨干网络传输压力和运营成本，也减少了因大量的跨运营商的流量而被封 P2P的流量，最终提升的整个 PCDN 网络的数据分发效率。
服务端会根据接入节点的地域，优先分配内网/社区等邻近节点，其次会选择同一个城市、 同省份、同区域（华东/华北等）、最后是相同国家的节点。
4. 连接机制
由于互联网的 Ipv4 地址紧缺，所以绝大多数设备会在路由器的背后，使用内网地址进行通 信。因此，为了实现较高的连接成功率，这里我们按照标准的 STUN 协议实现了点对点的 NAT 穿透，这里就不花较大的篇幅来阐述。但是由于视频播放属于多对一服务，即多个节点为一个 节点服务，因此，我们的思路重点放在了全局的连接成功率：
1）如端口受限型-对称型、对称型-对称型连接的情况，在 Tracker 服务端分配的时候，刻 意避开理论上无法连接、以及需要花费很大成本才能连接的情况；
2）客户端上报 ip 段到 ip 段的连接成功数据，后端大数据计算之后，排除掉成功率较低的ip 段连接；
3）实现 upnp；
4）对于判定可以直连的连接，tcp 和 udp 同时发起连接，哪个先连上用哪个。
5. 高效传输通道
PCDN 作为一个在线数据分发网络，最重要的就是点对点之间的传输通道，传输性能的好 坏直接决定了网络的效率的高低。作为整个网络中最基础最核心的链路传输，我们基于 UDP 协 议自研了可靠传输机制，并且作出了一些改进：
1）快速启动
根据连接过程的协议包，判断出 RTT 和两包间隔，从而快速的确定初始的发送窗口。例如 两包间隔在 50ms，那么窗口的初始值可以设定为 20（1000ms/50ms），如果两包间隔特别小只 有 1ms 的话，也可以设定一个上限阈值。在后续的传输过程中，速度越快，窗口越大。
2）丢包预判+快速重传
传统的丢包重传算法，会根据端到端的 RTT 来进行判断，当某个包在超过平均 RTT 或者 最大 RTT+阈值时，可以认为丢包，这时候会启用丢包重传。
在丢包重传的技术上，我们还做了一些丢包预判+快速重传，发送端发送了 1,2,3,4,5 几个包， 然后依次收到远端的 ACK1，ACK3 和 ACK4，当收到 ACK3 时，知道 2 被跳过 1 次，收到 ACK4 时，知道 2 被跳过了 2 次，此时可以认为 2 号丢失，不用等超时，直接重传 2 号包，大大改善 了丢包时的传输速度。
3）非延迟 ACK
TCP 为了充分利用带宽，延迟发送 ACK，这样超时计算会算出较大 RTT 时间，延长了丢 包时的判断过程，也延迟了发送窗口的移动。由于 ACK 包体积较小，我们采用了立即发送 ACK， 快速发现丢包，快速促使传输窗口移动。
6. 自适应调度状态机
在整个播放过程中，如何根据当前的播放状态、网络环境，作出使用一级 CDN，或者是二 级边缘节点、又或者是三级端侧下载的决策呢？这里，我们的最佳实践是依据可供播放的 buffer 水位来进行决策。
我们主要设定了 3 个区域，按照播放进度条上的当前播放位置的距离由近及远依次为紧急 区、过渡区和安全区：
1) 紧急区（红色区域）
当可供播放的 buffer 水位在这个区域时，网络的任何抖动都有可能造成用户的卡顿，因此 在这样的情况下，我们的调度状态机会使用一级 CDN 进行下载。
2) 过渡区（黄色区域）
当可供播放的 buffer 水位在这个区域时，网络的抗抖动能力略微增强，这时调度状态机会 倾向于同时使用二级边缘节点和三级端侧节点同时进行下载。
3) 安全区（绿色区域）
当可供播放的 buffer 水位过渡区时，抵抗网络抖动的能力已经比较强，对数据的时效性要求可以适当放低，这时调度状态机会完全使用三级端侧节点下载，分流服务器带宽。
7. 自适应的磁盘缓存算法
为了最高效的发挥出端侧供源能力，就必须保证所有的分布式的磁盘缓存的内容必需符合 流量的请求分布，即热门资源的副本数多，冷门资源的副本数少。我们定义了一个参数叫做稀 缺值，端侧的资源的存储、淘汰都会以稀缺值为依据，基本上可以大致的达到符合流量的请求分布状态。
当稀缺值<阈值时，请求数很多而副本数很小，这时会积极的去缓存文件，提高副本数； 当稀缺值>阈值时，副本数太多而请求数太少，这时就不在继续存储新的副本，同时会加速淘汰多余的缓存副本。
8. 精准的预先推送
利用非高峰时间离线分析用户行为等数据，并将分析预测后的结果推送至二级三级网络， 我们主要根据新上线的热度片源和基于用户观看行为进行预推：
1) 当日新上线热片的预推
热片的上线，往往会由于副本数小，请求量大而对PCDN 网络冲造成冲击，因此为了避免冲击，会在当日新上线之前，进行预推，使副本数达到一个预估合理值。
2) 基于用户观看行为的预推
a) 某用户观看连续观看某个节目，并且最后一次观看到第 N 分钟，则主动推送第 N 分钟 之后的内容；
b) 某用户观看某个电视剧的 1-N 集，则主动推送第 N+1 集。
9. 基于业务模式的配置变更
由于 PCDN 的业务涉及到播放和下载等业务，因此在不同的业务模式下，配置的参数、计算的算法，都应该是要有差异的：
1) 下载模式
对于下载来说，追求极限速度，因此会放大丢包超时，容忍乱序收包，降低重复包，达到最大的峰值下载速度。
2) 播放模式
在 buffer 水位比较短缺时，为了避免卡顿，追求下载数据的连续性，因此在下载数据由于 空洞造成不连续的时候，会采用丢包预判+快速重传，通过适当的增加重复率来换取数据的连续 性；当 buffer 水位充足的时候，这个时候其实又转化为了下载模式，追求极限的峰值下载速度。
四、技术成果与商业化
1. 优酷侧
大幅度降低服务器、带宽成本，接入 PCDN 平均可以降低 80%以上的服务器带宽成本，消 峰填谷效果明显(见下图，实际需要的服务器带宽与真实消耗的服务器带宽)。
2. 阿里云侧
将 PCDN 的能力对外部客户进行输出。用户通过集成 PCDN SDK 接入该服务后，能获得等 同或高于 CDN 的分发质量，同时显著降低分发成本，详细请参考阿里云官网。
五、思考总结
PCDN 是一个综合性强、庞大、复杂的系统，从业务来说，有点播，直播和文件下载，从架构看，服务器有网关、Tracker、Stun、推送、配置等服务，客户端不仅仅需要考虑全面跨终 端，而且还有连接、传输（下载、上传），存储等模块，从对开发人员的要求来说，PCDN 整套 系统也涵盖了大多数互联网从业者的技术栈，既有服务后端开发、也有客户端的底层技术、还 涉及移动端跨平台 SDK，音视频多媒体技术，网络技术等等，这件事情要做到极致，绝对不容易。
除了上述的这些刚需组件的开发，更多的是需要去考虑如果对分发数据的抽象、逻辑建模， 另外，整个系统的参数众多，每个模块都是牵一发而动全身，如何去保证整体的最优也是需要在一步一步摸索中才能悟出一些经验。
在实现细节上，并没有标准的做法，参数也没有绝对的好坏，在业界每家都需要根据自己 业务进行深度的考量和优化。评价优劣的指标维度众多，从宏观来说，通常以分享率和卡顿率 为参考，从微观来说，就涉及连接成功率，单点平均速度，缓存分布质量等等，而且每个指标， 也没有固定的标准。不同的业务形态，评价标准不尽相同，例如分享率指标，在 A 模式下，可 能 80%都算低，但是在 B 模式下，50%都很高。在这一点上，还是需要我们的开发同学不断去重构系统的每个链路，逐点提升。
未来随着 4K、5G、Ipv6 的来临，对 PCDN 来说，既是机会，也有挑战。以视频为载体的 网络流量会越来越大是机会，对清晰度、传输速度等要求不断提升是挑战。我们也在积极的探 索基于运营商基站、大型购物中心、地铁站、社区等更细粒度的流量调度服务，另外随着智能 硬件也越来越多的走入了千家万户，边缘节点正在逐步增多，如何更高效的去构建这样一张更 高密度的边缘计算网络也是我们正在研究的方向，同时，我们也会继续深挖新技术，在资源发 现、网络构建、任务分发、数据传输等各个环节不断去尝试、创新、突破，提供更高质量的 PCDN 服务。
