海外弱网下的在线视频平台优化实践

**
文 / 张亮**

整理 / LiveVideoStack

你们好，我是四达时代的研发总监张亮，本次分享的内容是基于四达时代在非洲作在线视频服务时所遇到的一些问题和一些优化的经验。你们都知道，非洲的网络环境很是复杂，甚至能够说几乎没有比非洲更差的网络环境了，所以咱们这里介绍的是一个比较极端的状况，仅供你们参考。

分享的内容主要分为三部分。首先是对StarTimes On App的简单介绍，由此引出咱们的产品到底应该关心哪些指标，优化必需要明确最核心的目的，想一块儿优化全部的指标确定是不可行的。第二部分会列出一些实际数据让你们了解非洲的实际网络状况。第三部分会重点和你们分享在如此极端的网络环境下咱们具体采用了哪些优化方式、方法，并最终取得了怎样的效果。

1 StarTimes On APP 简介

也许以前你们不太了解四达时代，由于咱们主要的业务是在非洲作电视运营。在非洲，四达时代能够说是一家家喻户晓的公司，咱们已经在非洲耕耘了十四年，在四十五个非洲国家作运营，目前已经拥有超过1000万的付费电视用户，因此咱们的总体收入规模和影响力仍是具有必定水平的。同时咱们也是“万村通”项目的实施方，这是咱们国家“一带一路”中的一个重要项目。

1.1 StarTimes On APP

StarTimes On 这个APP作的比较晚，直到2017年才上线，上线直接面临的就是2018年世界杯的考验。最初咱们对于非洲的网络环境有多差是没有做心理准备的，只是从APM厂商那里得到了一些数据，但实际真实的数据比拿到的数据还要差的多，所以在世界杯的转播过程当中仍是出现了一些问题，不过好在咱们都及时想办法解决掉了。

如今，StarTimes On 已经基本上具备必定的知名度，在Google Play娱乐板块上也一直是名列前茅。

1.2 商业模式与运营指标

从APP的商业模式上能够找到咱们的核心指标。首先，咱们的内容都是版权内容。用户分为两类，一类是免费用户，另外一类是付费用户。

免费用户观看视频须要看广告，广告会给咱们带来收入。免费用户看VIP内容则有限制，只能试看三分钟。因此咱们的运营指标就是免费用户看了多少视频，由于观看视频就意味着广告播放的增长，其次播放次数多则意味着更有潜力成为付费用户。

对于付费用户来讲咱们的收入来源是订阅费，付费用户不须要看广告，全部的内容权益也相应解锁。所以对于付费用户，咱们则重点关注用户观看视频的数量和观看的时长。看得多、看得久就表明满意度高，满意度高就会继续付费，因此这是咱们运营上的指标。

有了运营指标的要求，咱们就能够进一步拆解指标，从技术角度上进行分析，哪些地方须要优化。运营指标能够拆解成观看视频数量与观看视频时长。

观看视频数量很容易理解，若是视频启动失败了，观看数量天然也就会下降，而若是每次打开视频都能成功，都能顺利看到第一帧，那就是一个好的结果。因此QoE部分咱们就会关注用户的主动退出率，用户为何会主动退出，大部分状况都是由于等待的时间过久，好比用户等待的时间超过8秒钟，那可能大部分用户都会选择退出。QoS角度则会关注首屏时间，就是首屏时间越快、越小，主动退出率越低。

观看时长有两种度量方法。对于电视剧、电影，咱们会关注用户观看时长占视频总时长的比例。若是是直播频道，则关注观看的时间长度。影响用户观看时长最核心的QoS因素是卡顿。用户广泛会有一个心理预期，例如看一部电影，能够容忍视频卡三次，若是出现太屡次卡顿用户可能就会放弃观看。

通过以上分析，咱们能够导出此业务模式下最核心的两个QoS指标：首屏时间和卡顿比。以前和不少同窗交流，有不少作互动、RTC方面的同窗会更多关注延迟，可是在咱们这个业务模式下延迟并不须要特别关注。后面会介绍到，咱们还会有一些优化策略是经过牺牲延迟来得到其它收益。

2 非洲网络情况与挑战

接下来和你们说一下非洲网络的真实状况。

2.1 非洲网络基本状况

首先，你们看数据图中的南非，南非算得上是一个中等发达国家，网络状况还算能够。南非到欧洲CDN的延迟在闲时约为100多毫秒，忙时200毫秒，这其实还算能够。但若是往西边看，尼日利亚、加纳、科特等一些国家就糟糕多了。像尼日利亚，在忙时的RTT能超过600毫秒。这意味着咱们在作任何网络操做的时候，哪怕是下载一个字节的文件，也须要600毫秒的等待，由于网络一来一去硬指标就在那里。若是咱们业务上的后台放在欧洲，那么执行任何操做都须要600毫秒的延迟，很是影响用户的体验。

而东边像肯尼亚、乌干达、坦桑尼亚其实网络状况也不太好。在国内，若是最北边地区的用户访问最南边地区的机房花几十毫秒，已经能够算做比较慢了，而在非洲动辄就是几百毫秒，他们的网络状况相比国内差十倍甚至几十倍，这也就意味着咱们面临的是一个艰巨的挑战。

下面是丢包率，丢包问题如今更严重。近期咱们收集过一次数据，相比于疫情前，丢包率呈现翻倍的状况。受疫情影响，你们会更多使用手机流量，而非洲的带宽资源又很是不足，因此丢包状况变得更加严重。如图中所示，在高峰期丢包率会有24~25%左右，在这样的丢包率的状况下，下载速度是确定上不去的。

再来看其它的一些指标，建连的成功率有80%，指标相对比较稳定，5次里会失败1次。咱们会经过长链接缓解建连失败的影响，但长链接也会出现断连，因此不少时候仍然须要重连。DNS解析时间也很长，要1秒左右，数据都比较差劲。

视频封装咱们使用的是HLS协议，CDN上有大量M3U8索引文件和视频切片文件。索引文件大小几百个字节，下载这样一个文件可能须要10002000毫秒。视频切片下载速度在200400kbps左右。以上就是非洲目前的网络状况。

2.2 问题发生的缘由

接下来咱们简单梳理下非洲的网络问题究竟出如今哪里，只有定位了问题所在，才能够更好地探索优化的思路。

非洲网络丢包率很高，延迟很大。丢包的产生有不少缘由，这里我列了两个比较主要的：一个是无线接入网丢包，由于在非洲网络资源（接入网）是很是不足的，虽然你们都使用3G，也有部分的4G基站，可是基站数量太少，若是你们同一时段一块儿使用的话，基站资源明显是不够的。因此高峰期信号弱、小区切换会有不少问题，这就会致使数据包丢掉。另外一个缘由是拥塞，不论在非洲哪一个国家拥塞都是很是严重的，拥塞在运营商的出口方面会体现的很是明显。若是网络一直处于拥堵的状态，但你们还在大量发送包，或者去请求包，那最后大几率就是丢包。

延迟能够分为几类，像传输延迟和处理延迟等。排队延迟说到底仍是和拥塞有关系，若是网络拥塞的很厉害，那中间的交换机，路由器都要排队，排队会花费更多的时间。通过实际分析咱们发现：排队延迟是最主要的问题。重发延迟是指丢包以后从新发包带来的延迟，从应用层的角度看，这也是一种延迟。

在了解了非洲网络延迟与丢包的状况后，咱们想定位一下这些问题究竟发生在哪一个环节，随后再去寻找相应的解决办法。上图是从手机发送请求到最后IDC中的服务器收到并响应的过程。一开始用户的手机须要先链接基站，向基站发送无线信号，基站内部处理后，把网络的请求经过运营商的互联网出口传出，随后有一个更大的互联网，但其实这里面有不少层网络供应商，最终送到了IDC，以上全部的环节均可能发生问题。

最初咱们想经过MTR或者Ping这些工具来诊断问题，但在实际操做中发现，若是是在移动端上收集数据，基本上是采集不到数据的，有多是运营商对这些数据比较敏感。在国内作MTR能够看到不少的数据，但在非洲几乎全部的环节看到的数据都是“***”，表示它不容许探测。

2.3 肯定问题所在

最后咱们设计了几个实验来肯定网络问题的源头，总的来讲能够分红三组。

首先咱们要确认是否是真的存在十分严重的拥塞。咱们分别在闲时和忙时观测视频卡顿和启动时间这些指标，发现差异很大。相较于忙时，闲时的首屏能够减小30%，卡顿下降40%，这是很是显著的差别，这也说明了拥塞的存在，可是具体在哪一部分还不能肯定。

接下来咱们想验证用户接入网的差异是否为形成差别的因素。咱们知道4G网确定比3G网好不少，可是在非洲4G用户较少，咱们推测网络拥塞状况应该也相对良好，经过实验得以验证确实如此，使用4G网络的状况会比使用3G网络的状况好不少，但也没有像闲时与忙时的差别那样显著，所以接入网并非主要的问题所在。

接下来验证是否为运营商出口网络的问题。在运营商内部咱们也设置了一些服务器，经过它们来作测试。结果显示与欧洲的CDN相比，运营商网内设置服务器更具备收益，但并不显著。这也就说明了运营商的出口也存在问题，但不是主要问题。

在非洲还有一些IXP，国内IXP可能比较少。所谓IXP，简单来讲就是设置一个机房，各个运营商把它们的线路都拉到这个机房内，从这里能够很方便地连上各个运营商，运营商彼此间也能够交换流量。但实际上非洲IXP与运营商之间的网络也有拥塞，若是把CDN放在IXP的话，优化效果相比于放在运营商网络内会更差一些。

经过以上测试咱们得出了这样一个定性的判断：从手机到基站这部分的网络拥塞是最严重的，从运营商互联网出口出去后也存在必定的问题，由此以后的流程则没有太大的问题。在这种状况下，优化实际上是比较困难的。但至少咱们已经认识到了问题的所在，接下来就是思考具体的解决办法。

2.4 非洲网络状况总结

总地来讲，非洲的网络从链路和网络层来看，带宽严重不足，很是拥塞。

从传输层角度来看，不是传输层自己的问题，而是链路层和网络层影响了传输层，传出层的表现为丢包率高、RTT高。到应用层，解析域名很慢、下载速度很慢，并常常出现下载失败的问题。以上就是非洲的基本网络状况。

3 高延迟、高丢包视频体验优化

在有了对网络基本状况的判断后，接下来咱们须要肯定如何进行优化。

3.1 肯定优化目标

回到具体指标，由于咱们作的是版权长视频，因此会更关心首屏和卡顿的问题。延迟对咱们而言不是特别关键，由于直播电视频道并不涉及到互动环节，观众对延时不是太敏感。因此咱们的工做重心会放在解决首屏和卡顿的问题上。

用户体验和成本这部分，由于咱们的核心用户是付费用户，他们对视频质量是有必定要求的。但因为是在非洲，他们的要求确定没有中国或者美国用户的要求那么高，关键在于如何定义“必定的需求”。

最终咱们肯定的目标是：第一，下降卡顿比，第二，减小首屏时间。卡顿比高，用户主动退出率会增长，这是咱们不想看到的。首屏排在第二位是由于用户对首屏仍是有必定的耐受度的，长视频启动慢一点相对来讲能够接受。但若是短视频若是启动慢，用户应该会很难接受。所以咱们结合业务特色，但愿将首屏时间限定在不能超过5秒。至于延时，在业务模式下相对来讲是能够牺牲部分的。

针对画质咱们进行了市场调研，对一些关键的内容——例如球赛作了不少的调研，最后得出结论：对于球赛视频，用户的最低要求是能看到球。其实这个要求并非太容易知足，以非洲的网络下载速度，视频想要流畅播放就必须下降码率，而码率一旦下降，球就会模糊——球在天上飞的时候很是小，画面里就一两个像素那么大，编码的时候很是容易把球编没。因此常常的状况是：球在天上飞找不到位置，过一会又出现落在地上。对于这个问题咱们也是作了很是多的优化才使其达到用户可以接受的最低要求。而在其它方面包括新闻类节目，报道播出的时候须要清晰显示新闻人物的人脸，在国内这些都是不用担忧的事情，但在非洲则须要经过各类优化实现。以上就是咱们最终定下来的优化目标。

3.2 优化思路

具体的优化思路要从CDN层面提及。刚刚咱们提到非洲总体网络慢、差、拥塞，那么缘由到底是什么呢？咱们从IDC角度来看就能发现一些问题，非洲的ISP很是多，和东南亚以及印度相似，规模偏小，彼此间的互联互通作的也不好。打个比方，若是在非洲同一个国家两个不一样的运营商互相访问，由于运营商之间没有作互联，因此流量须要跑到欧洲绕一圈，或者跑到南非绕一圈。

由此咱们想到或许能够在非洲找一个IDC，或者经过云的方式来解决这个问题，但最后发现并不行。由于IDC只会和某些运营商之间有Peering或者购买了运营商的Transit，它没法和全部的运营商都作到彻底的互联。假如在IDC里设置服务器，某一个运营商的用户会很是开心，但相对应其它运营商的用户就很痛苦，这些用户的流量须要先转到欧洲，再绕回到非洲来，还不如直接使用欧洲的云服务。

最初咱们也不知道这些信息，使用的是欧洲的CDN和云服务来支持业务，后来尝试挪到非洲本地，发现效果更差。最终咱们制定的策略就是在较大的ISP网内自建CDN，再使用欧洲的CDN做为备份。

还有一个思路是找寻与ISP直连的第三方CDN，但实际上很难找到。所以第三方CDN只能做为备份和辅助，这是针对非洲网络特色设计的方案。

目前咱们自建CDN的部署规模已经相对比较大，图中四达时代logo的位置表明咱们在非洲的运营商中铺设的CDN服务器，这些CDN基本都是轻量级的，咱们在每一个机房里就设置一台服务器，服务器自己是高可用的，它看上去更像是普通的服务器，但内部全部的模块都有备份，好比电源、风扇、背板、交换、计算、存储等模块都是双份的，所以可靠性很是高。咱们经过大量铺设这一类服务器，做为边缘的缓存节点，供用户直接在网内访问、播放视频。

3.3 监控与调度系统

使用上面提到的自建CDN服务器，在调度上可能会遇到一些问题。

首先自建CDN仅能供内网用户访问，由于这些CDN没有公网IP，它们的IP地址是相似10.x这样的内网IP。若是调度出现错误，让用户去访问另一个运营商网内的自建CDN，则必然没法创建TCP链接，因此在调度上须要更加谨慎。

其次是运营商网内的出口不稳定，缘由是非洲的运营商运维水平有限。举个例子，咱们的一个CDN服务器链接到机房的交换机上，再从交换机出去，有时候机房交换机会丢包，如无任何征兆地丢包90%。运营商本身也没有监控，每次都是咱们发现问题后，联系重启交换机进行解决——这其实很影响用户体验。

另外就是一些球赛、演唱会场景，这些场景对于作视频的人来讲就和“秒杀”的性质是同样的，会瞬间进来一大批人，运营商的网内出口可能就直接被打爆了。

在发现这些问题后，对于CDN调度就须要作针对性处理，主要有如下3种策略：

**1. 基于用户体验的调度：**对于上述机房交换机的问题，即无征兆地出错并且也不报警，咱们在播放器中加了不少埋点，经过播放器实时上报卡顿、启动成功率、下载速度等指标，后台获取到这些信息进行实时分析，分析结果可做为调度策略的参考输入。假设运营商网内出口不稳定，尽管这种状况下CDN自己没问题，但用户体验极差，则用户体验指标会报警，调度系统就会将用户调至备用CDN。

**2. 基于CDN状态的调度：**这点比较基础，例如CDN服务器出现故障、机房网络不通、或者CDN的带宽已经打满，那流量就不能再往这里调度。

**3. 基于成本的调度：**咱们会优先将用户调往网内的CDN，网内CDN不可用时再转向第三方CDN。

3.4 音视频技术

音视频技术层面的内容会比较多，首先物理网络自己就不太好，铺设CDN后有必定的改善，但仅仅是少许的提高，并无质的飞跃，更多的优化须要从技术的角度进行。

具体能够总结为如下几个层面：

业务接口的异步化：在播放视频时，用户会认为点开视频的连接，视频就应该开始播放，但实际上业务后台还要作不少事情，好比鉴权，广告等一些策略，这些策略若是是串行执行的，会对首屏时间有很大影响。

网络层的优化指经过优化传输协议、拥塞控制算法等提高下载速度、下降建连时间对首屏时间的影响等。

视频封装优化能够减小播放器与CDN的交互次数，从而减小首屏时间、下降卡顿。

视频编码优化能够下降码率，一样能够减小首屏时间、下降卡顿率。

流媒体协议选择

在分析更具体的问题前，先来讲说流媒体协议的选择，咱们最终选择的是HLS封装。起初，咱们考虑过国内使用较多的HTTP FLV封装，它的延迟低、封装开销比较小，使用的人不少、技术也较为成熟。但就对比实际的需求，咱们发现使用HTTP FLV会存在不少问题，例如咱们有多音轨和多字幕的需求，不少电影有2个音轨（如英语和法语），有些还要加上当地语言，这样最终就可能会是四、5个音轨。若是咱们将全部的音轨打到同一个流里，那这个流的封装效率就很低，用户只会使用一个音轨，但却须要下载整个流。包括多字幕，也是一样的问题，所以咱们须要将这些不一样的流拆分开来。

除此以外，在音视频数据流分离、平滑的码率切换这些方面FLV作的都不太好。若是使用FLV，咱们还须要在它的基础上进行二次开发。再有就是海外第三方CDN的支持问题，大部分海外CDN厂商都表示不支持FLV协议。

另外，当时还有个选择就是DASH，不过咱们在2016年开始作研发的时候，DASH的开源工具还很是少，所以最终选择了HLS，各方面需求支持都比较好，技术成熟度也很高。

3.5 首屏时间问题

接下来到具体问题的分析，首先咱们要解决的是首屏问题。从用户点击视频到最后视频成功播放须要几个环节，如上面流程图所示。

第一，业务鉴权。像咱们这样的付费业务，用户是否有权益是须要校验的，而且校验过程相对复杂。例若有不少人盗流，那咱们就须要防黑产，即要判断当前用户是不是合法用户、是否有权限使用这个流。在这里咱们作了大量的数据模型来判断用户是否为机器人，只有真实用户才会得到CDN的token。其它业务逻辑还包括播放广告的策略、是否续播、选择用户喜爱的码率等，这些业务逻辑都是在用户点击播放按钮以后执行的。

接下来就是选择CDN。由于CDN的数量不少，算上第三方的大约有几十甚至更多，须要做出最为合适的选择，选择CDN后还要进行域名解析。解析域名后开始下载视频文件，由于咱们使用了HLS协议，因此播放器要下载M3U8文件，以及切片文件，最后才能够获得首帧的数据。

整条链路是比较长的，若是不作任何的优化，首屏时间基本上要超过十几个RTT。好比按照HLS的规范，m3u8和切片能够放到不一样的CDN上，可是这样就不能用同一个TCP链接去下载，须要各自创建链接再前后下载。并且建连次数多还会影响首屏成功率，由于TCP握手的成功率也只有80%，连续建两个链接都成功的几率就只有64%了。

咱们经过全流程再看几个数据，第一个是首屏的成功率，这是一个总体的指标。错误率指的是在任何一个环节都有可能出错，好比CDN可能会有错，下载文件时可能会返回404或者403，再或者建连的时候失败了，总之任何环节出错，都会记到错误率指标中。还有主动退出率，假设用户最终没有观看视频，要么是由于出错，要么是由于主动退出。若是是主动退出，咱们还要记录主动退出的环节和时间，这些信息对后面的优化有很强的指导意义。

图中展现的是咱们在定义指标后采集到的一些数据，上面的横条是启动时间的平均值，不一样的颜色表明不一样的环节。最左边深绿色为业务接口，蓝色为CDN选择，和刚刚介绍的流程一致。按照流程咱们进行了一段时间的采集，经过查看平均的数据，咱们发现用户花费了大量的时间在下载切片文件上，这个文件可能有几百k左右的大小，而前面一些环节可能就几十个字节，因此看起来也比较合理。

但实际上若是咱们须要优化首屏时间，咱们须要看下面的横条，这是85分位的首屏时间分析，下载仍然是耗时最长的，不过由于前面的一些环节会占到整个环节的2/3。若是咱们的目的是经过下降首屏时间来下降用户的主动退出率，仅仅优化下载切片的时间是不够的，就算优化成0，前面环节也须要5s左右的时间，用户仍然难以接受。因此在拿到这个数据后咱们再分析根本缘由，很明显是由于RTT很大，全部环节又都是串行执行，这就会致使首屏时间变得很是长。根据数据获得结论后咱们就能够定一个优化的思路。

首屏时间优化方案

首先看业务接口的优化，根据各企业业务的不一样，优化方式也多种多样。在咱们的业务中像鉴权、广告播发这样的逻辑均可以改成异步，好比向客户端下发一个策略，客户端异步执行，像续播、码率的选择，能够交由客户端本身实现，由于客户端能够记录播放历史，每次App启动时和服务器进行同步。具体视频开始播放时，是否续播由客户端自行决定。这些优化能够减小串行环节，总体流程上能够减小1-2个RTT，在非洲就能够体现为几百ms甚至1秒钟左右的时间节省。

CDN选择包括DNS的解析其实优化思路也是同样的。为节省CDN的选择时间，咱们直接在列表页上作CDN的选择，在列表页查看用户的位置，将数据提供给后台作快速选择。APP端也能够异步选择CDN，好比手机的网络有变化，从3G到4G或者切换到WIFI，有产生变化的时候，APP会作一个异步的选择解析，这样就能够保证视频的正常播放，同时在流程上也能够减小2个RTT。

而后就是M3U8下载的问题，要下载就必须先创建TCP链接，而TCP握手须要花1RTT。咱们有2种方式来节省建连时间，第一种是CDN选择结束后客户端直接创建链接，而后作心跳保活。在非洲作链接保活很不容易，链接一会就断了，发包发不过去，这时候重建链接就会浪费用户的流量，但不重建的话，等须要下载视频数据时从新建连会更浪费时间。总之要细调这个保活策略。

更理想的是使用QUIC，由于它具备0RTT快速链接的特性。QUIC也须要经过握手创建链接，但由于握手包和数据包是一块儿发出的，从用户的角度看，就至关于没有握手的时间。固然也一样会存在问题，它的生效比例不是特别高，在谷歌默认的策略里，IP变了0RTT也会失效，这实际上是一个很强的约束，由于移动网络的IP很容易就出现变化。根据实际测验，0RTT生效的比例只有50%，谷歌本身的数据是60%左右，固然这也要考虑到地区差别性。作到上述优化又能够节省1-2个RTT。

接下来是M3U8下载的问题。M3U8有master M3U8，也有子M3U8，并且咱们用到的是fragmented MP4的封装，没有用TS。封装会增长一个init.mp4文件，文件不大但须要独立地下载，独立下载意味着又会增长一个RTT。因而咱们就将这些文件的内容合并到视频的URL中，用户在访问URL时能够直接获取到文件内容，无需屡次单独下载。这些文件的内容都是文本或是字符串，咱们只须要把字符串传到客户端，由客户端在本地构造M3U8等文件后给到播放器，播放器就能够正常播放。这样作能够节省1~2个RTT。

最后是切片下载的TCP建连时间，有的公司可能会把切片和m3u8放到两个CDN上，这样也就必须分别创建链接，但若是切片和m3u8在同一个CDN上，咱们能够用同一个链接，至少在点播上是可行的，由于点播只须要下载一次M3U8，接着下切片文件。而直播可能就不行了，由于直播的M3U8的更新和切片的更新是独立的，它们是在两条线并行地更新，因此这时候必需要有两个链接去作并行的下载。而这种状况下咱们对于直播的优化策略就是建连的时候直接创建两个链接。固然若是有使用HTTP2或者QUIC的协议就会更简单一些，由于这些协议支持链接复用，HTTP2和QUIC的建连可能会更困难一些，由于他们建连的数据包更多，不过由于链接能够复用，整体上来讲又能够减小1-2个RTT。

因此总体的优化思路其实特别简单，目标也很明确，RTT高自己很难优化，那就直接减小RTT的个数。在全部的优化完成后，经过计算咱们发现大约减小有10个RTT，咱们在最差的基础上作优化，最终减小10个RTT。那在现实中10个RTT的提高到底是什么效果？用户在列表页点视频的时候，没有任何其余环节了，甚至链接都建好了，播放器直接去下载视频自己的数据，下载一点数据视频首帧就能出来，因此启动时间会有很是显著的改善。

这就是咱们优化的结果。以前首屏时间85分位能到7s多，这个时间对于非洲的用户来讲也是难以忍受的，但咱们优化完成之后，如今的时间不到3s。对于国内的标准，虽然仍是会比较长，但对于非洲用户来讲这个时间是能够接受的。

主动退出率这一块也很明显，以前是14%，100人看视频，有14我的由于不肯意等就退出了，这是一个很糟糕的数据。咱们作了优化之后它下降了一半大概能到7%左右。固然还有一些用户3s都不肯意等，咱们也分析这些用户的行为，发现这些用户可能本身在操做习惯上有问题，好比他们会在频道列表里“乱点”，1s点好几个视频，频繁退出，这样的操做在后台仍是会算成主动退出，因此整体上主动退出比例只下降了一半。但对于正常观看视频的用户来讲，这一首屏时间已经能够接受了。

3.6 卡顿问题

接下来是卡顿。卡顿这一块的指标体系会更简单一些。播放器先下载M3U8，而后下载切片。若是是直播的话就轮流下载，点播就下载一次M3U8，后面不停下载切片就能够了。再日后就是缓存、解码的过程。这一环节很是简单。

卡顿比这一块的优化思路主要是提高下载速度，下载速度只有250kbps，并且播放器还不能一直下载，这就致使直播的卡顿比要比点播高得多，缘由就是直播不能一直下切片，要频繁下载M3U8。

卡顿优化方案

这里的优化思路就是M3U8和切片要并行下载，有一个方法是把M3U8的内容放到切片里面去。这是一个比较有意思的改动，咱们直接将M3U8的文本放到切片的http response header中，由于m3u8自己就是个字符串，这样播放器就不用单独下载m3u8了，只须要不停地下载切片。由于每个切片里都自带了下一个m3u8，这样就节省了单独下载m3u8的时间，总体下载速度天然也就提高了。

而后是缓冲区的优化，由于咱们不关心延迟，因此就把缓存区加到了75s。

码率这一块，咱们用的fragmented MP4，这个封装的Overhead很低。你们若是是用HLS，就必定要注意这个问题，由于大部分状况下HLS用的是TS封装，而TS封装的Overhead很是高，在小码率下能到10%，好比音视频原始码流的码率是200kbps，封装出来就变成220kbps了，这是很不划算的。而fragmented MP4只有1%的overhead，但一样fMP4也有它本身的问题，它会把音频编在前面去，视频编在后面，这样就会影响启动的时间，因此咱们还须要本身去作一些交织的封装。

编码部分，刚刚有提到过咱们主要针对内容来进行优化，通过处理优化提高低码率下的画质以及播放流畅性。

CDN部分，经过自建CDN、优化CDN选择策略等，也能够明显提升下载速度。

最后，关于BBR/QUIC这部分仍是值得说一下，起初咱们使用BBR的拥塞控制算法，收益并不明显，与预期的差异很大，后面分析获得结论多是由于拥塞过于严重。总地来讲，BBR算是一个相对君子一点的算法，不像cubic同样疯狂发包直至丢包为止，BBR是检测到开始拥塞就中止发包，但因为非洲的网络自己拥塞就很严重，所以BBR的收益也就没那么显著，后面咱们还会进行一些其它的尝试。

卡顿优化以后的收益也是很是显著的，在85分位下，原来直播的卡顿比有15%，如今不到2%，就在非洲来讲这是个不错的结果。而对于点播，85分位播放卡顿比不到1%，也是个不错的结果。

这几件事情作完之后咱们的用户体验获得了很大的提高，促进了业务的发展。

3.7 优化思路总结

最后简单总结一下。首先，数据是改进的基础，想准确发现问题须要预先埋特别多的点。若是仅靠臆想问题所在，而后直接修改程序，那结果极可能是随机的。所以咱们甚至在网络协议栈中也埋了点把一部分用户的网络协议栈日志拉回来，好比每个IP包何时发，何时丢，为何重发，重发的是否及时，每个数据都拉回来作分析。至于播放器和业务埋点就更基本了，必定要埋全。

其次，要在分位线上看数据，不能只看平均值，平均值会掩盖极端的状况，结果把咱们导向错误的优化方向。

最后是抓核心指标，对于咱们来讲就是牺牲延迟，把其它指标作好。要能找到核心瓶颈并针对其进行优化，这样才能保证比较高的作事效率。