短视频秒播优化实践（一）

短视频迎合了人们时间碎片化下的精神娱乐需求，或者现在追求“短平快”的大环境，我也有点短视频中毒，没事经常光顾某几个短视频APP，以至于冷落了某头条和某易新闻基本很少点开了，这些时间加起来holy bible估计都能读好几遍了。当然这是一篇技术文章，其他心理学，社会学问题，产品问题就不在这里讨论了，咱也没那个水平。

言归正传，我们也推出了短视频相关的产品。

在短视频的体验中，起播速度无疑是最影响体验的指标之一，因为短视频很短，十几秒到几分钟不等，如果一个十几秒的视频，加载时间都要3秒，肯定是一个很坏的体验；所以在产品定义之初，起播速度就设定了控制在1秒左右，大部分在1秒内，也就是业内说的“秒播”，这需要对播放流程进行优化。艾玛，终于绕到主题上了。

谈具体的优化之前我们先看下一个短视频播放的大概流程是怎样的？

再通过拆解流程，找到可以优化的模块或点，最终才能连成线，并给出优化方案。

如上图所示，移动设备的播放器通过某个视频url的域名，通过DNS服务请求到IP地址，通过这个IP地址与视频服务器建立TCP连接，然后在连接之上建立http协议，最终请求到数据，给到播放器进行解析音视频解码显示，用户看到画面听到声音，一个起播流程结束了。

为了更好的发现可优化的地方，我们对上图进行了拆解，结合实际情况给出了下边这张图

图中蓝色的部分是可以优化的，但由于实际情况是，flyme只在客户端接入了内容，内容都是放在CP的服务器上的，虽然有优化空间但是flyme这边优化不到，但在后边我们也会介绍有哪些优化空间可以操作。这个是行业现状，不过可以多接入几家内容选择岂不是更好。图中灰色部分是不能优化的，在流程上没有优化空间，而且这部分容易受到网络情况的影响，所以我们后续提到的优化，是基于大多数normal的网络情况的，虽然部分逻辑对极端网络情况也适用，但是这不是我们讨论的重点。图中绿色的部分是可以优化并且在项目现实中可以实施的。

下面对这些项目逐一进行介绍。

一、Domain name: 域名解析

耗时原因：

DNS请求包会先发到本地DNS服务器，如果查不到，会递归到根域名服务器，这个过程是比较耗时的，当然如果你请求过了，或者期间有其他人请求过相同的域名，那域名服务器就会有缓存，再次请求的时候就很快了；但是一般缓存的周期很短，需要有人不停地请求才能保持更新，所以具有很大的不确定性。

解决方案：

1.注意请求使用的IP协议版本，做播放的肯定都绕不过ffmpeg，在ffmpeg里为了兼容性，DNS请求的IP协议版本设置为AF_UNSPEC，这样在请求的时候会先请求IPv6的地址，如果没有再请求IPv4的地址，是很保险，但是在实际的项