自建及商用CDN之间的多维度比较

在选择自建CDN或者商用CDN时，需要结合业务实践，从成本、质量、业务定制化能力等维度进行综合评判。本文来自欢聚时代直播部负责人林正显在LiveVideoStackCon 2017大会上的分享，并由LiveVideoStack整理而成。

大家好，我是来自欢聚时代的林正显。今天主要为大家分享的是自建或商用CDN的选择与发展。

以下是本次分享的内容大纲，我将会从这几个方面分享过去的一些开发经验与体会。

1、YY分发网络的发展历史

YY语音成立于2008年，初期主要是借助团队语音网络向游戏团战用户提供语音多播服务。起初实现的是应用层多播(ALM)，其特点是频道(房间)高度分散化，一个频道对应一个多播组。而同频道内不同用户分布在不同地域，不同运营商下。此时我们的主要任务是基于运营商网络开发一层封装并在其上叠加一个自己的分发网络而非基于IP多播。大家知道运营商对IP多播有诸多限制，且IP多播无法保证传输的可靠性。但由于频道分散化与多个地域运营商等问题，保证强语音实时交互必定需要做出很多努力;根据ITU标准，大于四百毫秒的延时体验显然是不及格的，我们期待将延时控制在较为理想的两百毫秒以内，由此需要解决的挑战有跨运营商的通讯问题、传输与分发延时问题和通信成本问题。

每个运营商都会布局自家服务器，而服务器之间的联络依靠运营商线路直连。这里需要解决的问题是，一些情况下一个频道可能只有几个人且分布在不同运营商;如果为了保证几个人的服务调用多台服务器，此时服务器之间的转发量可能大于下发量。不仅使成本激增，也难以保证数据在不同运营商之间传输的质量，可能会出现高达百分之几十的丢包。为了改变这种成本与质量的双重压力，我们需要对其作出进一步优化。

大约在2011年，我们就面临着有关视频分发的需求，当时为了快速实现秀场直播与游戏直播的产品形式，我们使用了一种现在看来问题明显的架构，也就是单独搭建一个视频分发网络。这样能够确保音频的优先级，保证音频业务的质量和稳定性，并赶上视频直播的时间点需求，但由于当时采取音视频分开上传的方案，客户端的音视频同步成为一个难以解决的问题。

此后我们出于成本和质量的双重考虑，对分发系统进行了两大改进：一是基于Overlay+智能路由网络，搭建一个“网中网”并对线路算法进行改进，从而实现多级中继的自适应算法;二是引入P2P，从而在保证数据传输质量的同时有效降低成本。

2、YY分发网络的发展现状

YY分发网络发展到现在，其本质是一个规模庞大的实时多播网络。传输对延时的影响较小，而终端编解码、去抖动等环节对延时的影响则更明显。根据2011年的数据，我们的全网平均传输延时仅为74毫秒，基于此网络，我们支持了很多实时业务如游戏语音、狼人杀、多人音视频会话等等。而对秀场的支持主要通过增大缓冲来实现。当然，现有的YY网络中纯音频分发用户仍然占很大比例，基于团队语音的团战场景较为普遍。即使我们正在实现音视频分发网络的逐渐融合，但音频优先级仍然是需要我们保证的。

3、自建与商用的多维度考量

介绍完YY分发网络的发展历史，下面我想谈一下自建与商用的考量维度。在选择自建或商用分发网络时我们主要从以上四个维度考量：质量是分发网络需要保证的首要条件;而业务定制能力主要为满足客户的个性化业务定制需求，如果CDN无法支持那么就需要我们自己构建，随之而来的大量成本投入显然不是我们期待的结果;紧接着的成本问题与安全问题也是需要我们重点考量的维度，不容忽视。

3.1 质量

卡顿率与延时是我们考量质量维度时最重要的两个参数。前者是指观众看不到视频或听不到声音的比例，后者是打开视频直播的速度。YY对卡顿率的定义和一般CDN厂商的定义有些许不同，我们以5分钟作为统计周期，如果在此周期内产生卡顿则定义此用户为坏用户;将一个周期内的坏用户数与此周期内所有种子用户数的比值定义为卡顿率，我们一直借助这样一个十分苛刻的指标衡量整个YY网络质量的好坏。而由于YY有大量的业务场景是连麦互动，我们对延时的统计包括两部分：主播与主播之间的延时和主播与观众之间的延时。主播与观众的传输处理基本一致，主要区别在于观众的抖动缓冲更长。

3.2 业务定制能力

第二个我们遇见的比较麻烦的问题是业务定制能力。与一般的由CDN纯文件分发切入的直播方案不同，YY通过实时多播系统切入直播。我们没有对RTMP或FLV的种种系统边界限定，业务场景也是千奇百怪。例如直播抓娃娃，用户通过手机控制抓娃娃机，通过直播画面确定爪子位置。一般在此应用场景中我们需要控制从开始点击到图像传递到客户端的延时不超过三百毫秒，并且希望用户抓到娃娃后在娃娃机端同步反馈一个用于确认抓取结果的状态码，同时保证此状态码的送达与直播画面的同步性,如果系统显示抓取成功而直播画面还停留在抓取阶段无疑是体验糟糕的。这种实时交互的场景在我们的核心业务中占比很大，提升此类场景用户体验的关键是确保控制流和媒体流之间的配合与同步，如在AI地图场景中主播走到的位置与地图呈现给观众的位置必须同步且统一，而向左或向右走的指示也需准确无误。总体而言，YY的这些玩法较少见于以CDN为基础的较为大众化领域，这就导致当我们尝试将系统迁至CDN时无法寻找到一个较为优质的解决方案。例如在过去的尝试中我们发现，CDN推的一路视频流难以与经由我们自己信令网络传输的控制流同步;或者面对在YY较为普遍的多人连麦实时语音应用场景，当直播间内用户同时进行发言时，CDN无法将同步显示每一个人的发言状态与混合多路语音的直播数据一起推给观众。可以说，简单的CDN无法满足我们的业务需求。

3.3 成本

想必对任何一家公司而言，成本都是无法逃避的关键命题。由于我们的整体业务较为单一，自建分发网络的带宽利用率偏低，实际应用中主要表现在白天流量处于低谷而晚上流量处于高峰;除此之外在2012年我们探索P2P时发现，国内用户的上行带宽远低于下行带宽，全国人均上行带宽为1～2mbps。如果一个视频流的码率高达8～9mbps，即便我们把用户上行带宽都榨光，也没法支撑全部流量。上行带宽有限的时候，码率越高，P2P的节省率越低。早期探索CDN时我们也犯了不少错误，例如开发第一版产品时我们将服务于主播的资源与服务于观众的资源混为一谈，相比于单纯使用CDN做观众流的分发，前者算出来的单用户成本偏高。我们需要将网络成本分为主播端网络成本和观众端网络成本;对主播网络而言由于转码、私有协议、HLS等都在主播端确定，其成本远高于观众端。除此之外我们也会考量每MB成本与每用户成本，如果以前者作为标准那么YY的成本计算值偏高，因为需要计算IDC、宽带、CDN等的采购成本;而如果以每个用户的成本作为标准那么一个2MB的下行视频仅需800K流量，其余数据则通过P2P，我们应当以每用户成本作为标准进行成本计算。除此之外，我们还发现，当通过YY网络将同一条流推送到不同的CDN，并让各CDN给出每个用户的下行流量时，其结果是有一定差距的，大家在进行成本计算时需要注意这一事项。

3.4 网络安全

安全问题不容忽视。根据上图我们可以看到自建机房受到的攻击的数量之多，类型之复杂触目惊心。其中syn攻击与UDP攻击的数量很大。在服务前期由于没有对整个网络进行很好的保护，服务质量得不到很好的保障。

4、YY分发网络的后续计划

我们的后续计划是在逻辑上将网络分割成主播网与观众网，主播连接到主播分发网并接入互动的数据;随后直播音视频数据通过一个可选的内容处理平台进行转码、超分辨率、广告插入等处理后再推至我们自建的观众分发网络或商用CDN，使得服务能够从容应对流量短时间激增的突发状况。我们显然不能单纯地为了应对突发流量而时时刻刻维护一个规模庞大的自建网络，使用CDN作为预备扩容的临时服务器可以合理的成本从容应对流量激增风险。除此之外，两个逻辑网络的维护与升级互相不影响，便利性更佳，有效避免观众分发网络的版本更新可能会为主播端带来的不利影响。当然此方案也有一定坏处，其一是从观众切到主播的体验尚待进一步优化，其二是多视频流的直播间推到CDN时，混流导致视频质量下降，且用户难以单独屏蔽单条流。对于现在的多主播连麦直播，数据通过多条未混合的流传输给观众，因为合流、混流等会导致媒体质量的下降。由此我们一直坚持多主播上行多条流下行的架构，而这在CDN是无法实现的，如果不进行混流操作就贸然使用CDN那么多条流的同步是十分糟糕的。

5、自建分发网络的经验与教训

5.1 成本

成本是一个永远绕不开的话题，也是我们除了质量最多考量的维度。我们可通过借助一些高效的音视频编解码方案在保证质量的同时显著控制成本，可通过使用更高效的音视频编解码解决方案如用H.265代替H.264，也可通过使用P2P或多业务互补从而提高业务带宽利用率等。除了以上的通用解决方案，在观众端的一些优化例如通过人工智能深度学习等技术将低分辨率视频转换成高分辨率视频的超采样分辨率技术或阿里正在探索的基于主观视觉感受的窄带高清编码等。自建网络存在一个边际成本问题，也就是随着自建网络规模的增大，每个用户的成本会随之降低。如果自有流量未达到500G～1T的水平则很难控制自建网络的成本，只有高于此水平才能有效平衡成本与其他要素的关系。我想对于包括YY在内的任何一家企业而言，质量第一，成本第二。我们期待的是使用可以控制的合理投入实现延时与卡顿率更低的高质量音视频传播技术保障。

5.2 机房节点选择

机房节点选择问题非常关键。YY的机房并非集中化部署而是分布在全国各地，集中化部署服务器的好处在于有效减少机房之间的通讯流量，但数据传输质量肯定是无法得到有效保证;而如果服务器部署过于分散，服务器分布在每个城市甚至每个小区，那么服务器间的通讯流量就会非常大并导致整体成本的进一步提升。我们需要尽可能避免这两种极端，也就是采取同省、同市接近用户部署的策略从而在控制机房间流量的同时保证接入的质量。我们尽可能以较为合适的密度在全国各地布置机房节点，并在机房落地前进行包括丢包、延时在内的严苛质量测试，以及上线之后对机房节点进行持续监控并统计质量数据的变化。有时某个机房会出现测试性能优良而在投入使用后出现很多问题的现象，这仍待我们进一步优化。早期YY选择IDC时IDC将我们的带宽与其他业务带宽混在一起，由于和其他客户共用带宽，带宽资源受到限制，一旦出现流量激增则传输质量无法得到保证。随着YY的业务日渐壮大我们淘汰了质量不佳的IDC，这也是我们在以往实践探索时收获到的教训。

5.3 网络容量规划

第三个需要强调的是网络容量规划问题。我们需要妥善处理业务的需求起落带来的网络流量伸缩问题，在弹性和成本之间保持动态平衡。如果使用完全自建的分发网络那么需要流出足够的缓冲支撑突发流量，从成本角度考量并不划算。因而我们思考，能否采用云主机的服务形式进行弹性部署，从而在确保面对突发流量增长时整体服务的稳定性的同时控制服务器采购、上下限的资源成本。除此之外，我们也希望实现自建平台与CDN、多CDN平台之间的分担与互备，进一步确保服务的稳定与可靠。

5.4 网络攻击

网络攻击是一件非常重大的事情。我们单个机房曾遭受上百Gbps级别的流量攻击以至于机房瘫痪，这也促成我们建立了包括DDOS攻击防御在内的全方面安全防卫系统，此系统对我们YY整个业务的茁壮成长起到了至关重要的作用。对于自建分发网络而言，安全系统是性命攸关的。

5.5 小运营商用户接入

覆盖性问题同样需要我们考虑。对三大运营商的覆盖毋庸置疑，但对类似于教育网等小运营商用户的覆盖与质量保证是需要我们优化的。保证小运营商用户的服务体验是一件很大的挑战，很多小运营商用户都是经过NAT后再接入大的运营商网络，其连接质量就难以获得保证。我们需要判断用户自身所处网络属性，也可使用BGP、多线机房等进行接入;除此之外，自建网络时利用CDN甚至第三方接入也是有可能的，这也是我们正在探索的方向;而为了给海外用户提供服务，YY使用公网环境进行传输，处理思路与小运营商接入相似

6、小结

我们在自建CDN或采用商用CDN时，需要结合质量、成本的综合考量、以及对业务个性化定制的支持能力来进行综合评判。