关于dns:vivo-短视频用户访问体验优化实践

作者：vivo 互联网运维团队 - Hu Tao

本文介绍了 vivo 短视频用户拜访体验优化的实际思路，并简略解说了实际背地的几点原理。

一、背景

咱们平时在看抖音快手视频的时候，如果滑动到某个视频画面始终几 s 不动的时候，大概率就会划走了，所以在短视频我的项目中，画面卡顿是十分影响用户体验的，启播速度越快，就越能留住用户。

启播速度简略来说就是从调用开始播放到首帧上屏的工夫，大抵可分为两局部：

• 视频文件下载耗时
• 视频解码耗时

本文次要从运维排查问题的角度，从网络这部分的各个环节动手，联合 vivo 短视频的具体案例，给大家分享下优化过程。

二、用户拜访链路

咱们先梳理下一次残缺的网络申请过程，以客户端视角为例，如下图所示：

在接入 CDN 的状况下，可分为几个阶段：

1. DNS 域名解析：获取服务器的 IP 地址。
2. TCP 连贯建设：与服务器 IP 建设连贯即 tcp 三次握手。
3. TLS 握手：客户端向服务器索要并验证服务器的公钥，单方协商生产「会话秘钥」并进行加密通信。
4. CDN 响应：将内容资源散发到位于多个地理位置机房中的服务器上并返回给客户端。

针对以上阶段，别离讲下 vivo 短视频是如何进行优化的。

三、DNS 域名解析

咱们在上网的时候，通常应用的形式域名，而不是 IP 地址，因为域名不便人类记忆。那么实现这一技术的就是 DNS 域名解析，DNS 能够将域名网址主动转换为具体的 IP 地址。

3.1 域名的层级关系

DNS 中的域名都是用 句点 来分隔的，比方 www.server.com，这里的句点代表了不同档次之间的 界线 。在域名中， 越靠右 的地位示意其层级 越高。根域是在最顶层，它的下一层就是 com 顶级域，再上面是 server.com。

所以域名的层级关系相似一个树状构造：

• 根 DNS 服务器
• 顶级域 DNS 服务器（com）
• 权威 DNS 服务器（server.com）

根域的 DNS 服务器信息保留在互联网中所有的 DNS 服务器中。这样一来，任何 DNS 服务器就都能够找到并拜访根域 DNS 服务器了。

因而，客户端只有可能找到任意一台 DNS 服务器，就能够通过它找到根域 DNS 服务器，而后再一路顺藤摸瓜找到位于上层的某台指标 DNS 服务器。

3.2 域名解析的工作流程

浏览器首先看一下本人的缓存里有没有，如果没有就向操作系统的缓存要，还没有就查看本机域名解析文件 hosts，如果还是没有，就会 DNS 服务器进行查问，查问的过程如下：

1. 客户端首先会收回一个 DNS 申请，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
2. 本地域名服务器收到客户端的申请后，如果缓存里的表格能找到 www.server.com，则它间接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大，能通知我 www.server.com 的 IP 地址吗？”根域名服务器是最高档次的，它不间接用于域名解析，但能指明一条路线。
3. 根 DNS 收到来自本地 DNS 的申请后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域治理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
4. 本地 DNS 收到顶级域名服务器的地址后，发动申请问“老二，你能通知我 www.server.com  的 IP 地址吗？”
5. 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
6. 本地 DNS 于是转向问权威 DNS 服务器：“老三，www.server.com 对应的 IP 是啥呀？”server.com 的权威 DNS 服务器，它是域名解析后果的原出处。为啥叫权威呢？就是我的域名我做主。
7. 权威 DNS 服务器查问后将对应的 IP 地址 X.X.X.X 通知本地 DNS。
8. 本地 DNS 再将 IP 地址返回客户端，客户端和指标建设连贯，同时本地 DNS 缓存该 IP 地址，这样下一次的解析同一个域名就不须要做 DNS 的迭代查问了。

至此，咱们实现了 DNS 的解析过程。当初总结一下，整个过程画成了一个图。

DNS 域名解析的过程蛮有意思的，整个过程就和咱们日常生活中找人问路的过程相似，只指路不领路。

3.3 vivo 短视频所做的优化

弄清了域名解析的工作流程，将 vivo 域名和头部厂商域名进行比照剖析，发现 vivo 短视频域名解析耗时不稳固，稳定范畴很大，狐疑是某些地区用户访问量少，本地 DNS 服务器缓存命中率低导致的，因而咱们的优化思路就是 进步本地 DNS 缓存命中率。

如上图所示，进步 DNS 缓存命中率一个简略的方法就是增加全国范畴内的拨测工作，来进行DNS 加热。

通过对调整前后的 DNS 解析工夫进行比拟，能够看到耗时升高了 30ms 左右。

四、HTTP 性能

这里简略比照下 HTTP/1、HTTP/2、HTTP/3 的性能。

HTTP 协定是基于 TCP/IP，并且应用了「 申请 – 应答 」的通信模式，所以性能的要害就在这 两点 里。

1. 长连贯

晚期 HTTP/1.0 性能上的一个很大的问题，那就是每发动一个申请，都要新建一次 TCP 连贯（三次握手），而且是串行申请，做了无谓的 TCP 连贯建设和断开，减少了通信开销。

为了解决上述 TCP 连贯问题，HTTP/1.1 提出了 长连贯 的通信形式，也叫长久连贯。这种形式的益处在于缩小了 TCP 连贯的反复建设和断开所造成的额定开销，加重了服务器端的负载。

长久连贯的特点是，只有任意一端没有明确提出断开连接，则放弃 TCP 连贯状态。

2. 管道网络传输

HTTP/1.1 采纳了长连贯的形式，这使得管道（pipeline）网络传输成为了可能。

即可在同一个 TCP 连贯外面，客户端能够发动多个申请，只有第一个申请收回去了，不用等其回来，就能够发第二个申请进来，能够 缩小整体的响应工夫。

举例来说，客户端须要申请两个资源。以前的做法是，在同一个 TCP 连贯外面，先发送 A 申请，而后期待服务器做出回应，收到后再收回 B 申请。管道机制则是容许浏览器同时收回 A 申请和 B 申请。

然而服务器还是依照程序，先回应 A 申请，实现后再回应 B 申请。要是 后面的回应特地慢，前面就会有许多申请排队等着。这称为「队头梗塞」。

3. 队头阻塞

「申请 – 应答」的模式加剧了 HTTP 的性能问题。

因为当程序发送的申请序列中的一个申请因为某种原因被阻塞时，在前面排队的所有申请也一起被阻塞了，会导致客户端始终申请不到数据，这也就是「队头阻塞 」。 好比下班的路上塞车。

4.1 HTTP/1.1 相比 HTTP/1.0 性能上的改良：

• 应用 TCP 长连贯的形式改善了 HTTP/1.0 短连贯造成的性能开销。
• 反对 管道（pipeline）网络传输，只有第一个申请收回去了，不用等其回来，就能够发第二个申请进来，能够缩小整体的响应工夫。

但 HTTP/1.1 还是有性能瓶颈：

• 申请 / 响应头部（Header）未经压缩就发送，首部信息越多提早越大。只能压缩 Body 的局部；
• 发送简短的首部。每次相互发送雷同的首部造成的节约较多；
• 服务器是按申请的程序响应的，如果服务器响应慢，会导致客户端始终申请不到数据，也就是队头阻塞；
• 没有申请优先级管制；
• 申请只能从客户端开始，服务器只能被动响应。

针对下面的 HTTP/1.1 的性能瓶颈，HTTP/2 做了一些优化。而且因为 HTTP/2 协定是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

4.2 HTTP/2 相比 HTTP/1.1 性能上的改良：

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时收回多个申请，他们的头是一样的或是类似的，那么，协定会帮你 打消反复的局部。

这就是所谓的 HPACK 算法：在客户端和服务器同时保护一张头信息表，所有字段都会存入这个表，生成一个索引号，当前就不发送同样字段了，只发送索引号，这样就 进步速度 了。

2. 二进制格局

HTTP/2 不再像 HTTP/1.1 里的纯文本模式的报文，而是全面采纳了 二进制格局。

头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

这样尽管对人不敌对，然而对计算机十分敌对，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是间接解析二进制报文，这 减少了数据传输的效率。

3. 数据流

HTTP/2 的数据包不是按程序发送的，同一个连贯外面间断的数据包，可能属于不同的回应。因而，必须要对数据包做标记，指出它属于哪个回应。

每个申请或回应的所有数据包，称为一个数据流（Stream）。

每个数据流都标记着一个举世无双的编号，其中规定客户端收回的数据流编号为奇数，服务器收回的数据流编号为偶数。

客户端还能够 指定数据流的优先级。优先级高的申请，服务器就先响应该申请。

4. 多路复用

HTTP/2 是能够在 一个连贯中并发多个申请或回应，而不必依照程序一一对应。

移除了 HTTP/1.1 中的串行申请，不须要排队期待，也就不会再呈现「队头阻塞」问题，升高了提早，大幅度提高了连贯的利用率。

举例来说，在一个 TCP 连贯里，服务器收到了客户端 A 和 B 的两个申请，如果发现 A 处理过程十分耗时，于是就回应 A 申请曾经解决好的局部，接着回应 B 申请，实现后，再回应 A 申请剩下的局部。

5. 服务器推送

HTTP/2 还在肯定水平上改善了传统的「申请 – 应答」工作模式，服务不再是被动地响应，也能够 被动 向客户端发送音讯。

举例来说，在浏览器刚申请 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等动态资源被动发给客户端，缩小延时的期待，也就是服务器推送（Server Push，也叫 Cache Push）。

4.3 那么 HTTP/2 有哪些缺点？HTTP/3 做了哪些优化？

HTTP/2 通过头部压缩、二进制编码、多路复用、服务器推送等新个性大幅度晋升了 HTTP/1.1 的性能，而美中不足的是 HTTP/2 协定是基于 TCP 实现的，于是存在的缺点有三个。

• TCP 与 TLS 的握手时提早；
• 队头阻塞；
• 网络迁徙须要从新连贯。

1. TCP 与 TLS 的握手时提早

对于 HTTP/1 和 HTTP/2 协定，TCP 和 TLS 是分层的，别离属于内核实现的传输层、openssl 库实现的表示层，因而它们难以合并在一起，须要分批次来握手，先 TCP 握手，再 TLS 握手。

发动 HTTP 申请时，须要通过 TCP 三次握手和 TLS 四次握手（TLS 1.2）的过程，因而共须要 3 个 RTT 的时延能力发出请求数据。

另外，TCP 因为具备「拥塞管制」的个性，所以刚建设连贯的 TCP 会有个「慢启动」的过程，它会对 TCP 连贯产生 ” 加速 ” 成果。

2. 队头阻塞

HTTP/2 实现了 Stream 并发，多个 Stream 只需复用 1 个 TCP 连贯，节约了 TCP 和 TLS 握手工夫，以及缩小了 TCP 慢启动阶段对流量的影响。不同的 Stream ID 才能够并发，即便乱序发送帧也没问题，然而同一个 Stream 里的帧必须严格有序。另外，能够依据资源的渲染程序来设置 Stream 的优先级，从而进步用户体验。

HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完满了，然而 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。

HTTP/2 多个申请是跑在一个 TCP 连贯中的，那么当 TCP 丢包时，整个 TCP 都要期待重传，那么就会阻塞该 TCP 连贯中的所有申请。

因为 TCP 是字节流协定，TCP 层必须保障收到的字节数据是残缺且有序的，如果序列号较低的 TCP 段在网络传输中失落了，即便序列号较高的 TCP 段曾经被接管了，应用层也无奈从内核中读取到这部分数据，从 HTTP 视角看，就是申请被阻塞了。

举个例子，如下图：

图中发送方发送了很多个 packet，每个 packet 都有本人的序号，能够认为是 TCP 的序列号，其中 packet 3 在网络中失落了，即便 packet 4-6 被接管方收到后，因为内核中的 TCP 数据不是间断的，于是接管方的应用层就无奈从内核中读取到，只有等到 packet 3 重传后，接管方的应用层才能够从内核中读取到数据，这就是 HTTP/2 的队头阻塞问题，是在 TCP 层面产生的。

3. 网络迁徙须要从新连贯

一个 TCP 连贯是由四元组（源 IP 地址，源端口，指标 IP 地址，指标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致须要 TCP 与 TLS 从新握手，这不利于挪动设施切换网络的场景，比方 4G 网络环境切换成 WIFI。

这些问题都是 TCP 协定固有的问题，无论应用层的 HTTP/2 在怎么设计都无奈逃脱。

要解决这个问题，HTTP/3 就将传输层协定从 TCP 替换成了 UDP，并在 UDP 协定上开发了 QUIC 协定，来保证数据的牢靠传输。

4.4 QUIC 协定的特点

• 无队头阻塞，QUIC 连贯上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协定限度，某个流产生丢包了，只会影响该流，其余流不受影响；
• 建设连贯速度快，因为 QUIC 外部蕴含 TLS1.3，因而仅需 1 个 RTT 就能够「同时」实现建设连贯与 TLS 密钥协商，甚至在第二次连贯的时候，利用数据包能够和 QUIC 握手信息（连贯信息 + TLS 信息）一起发送，达到 0-RTT 的成果。
• 连贯迁徙，QUIC 协定没有用四元组的形式来“绑定”连贯，而是通过连贯 ID 来标记通信的两个端点，客户端和服务器能够各自抉择一组 ID 来标记本人，因而即便挪动设施的网络变动后，导致 IP 地址变动了，只有仍保有上下文信息（比方连贯 ID、TLS 密钥等），就能够“无缝”地复用原连贯，打消重连的老本。

另外 HTTP/3 的 QPACK 通过两个非凡的单向流来同步单方的动静表，解决了 HTTP/2 的 HPACK 队头阻塞问题。

不过，因为 QUIC 应用的是 UDP 传输协定，UDP 属于“二等公民”，大部分路由器在网络忙碌的时候，会丢掉 UDP 包，把“空间”让给 TCP 包，所以 QUIC 的推广之路应该没那么简略。期待，HTTP/3 正式推出的那一天！

4.5 vivo 短视频所做的优化

随着 vivo 短视频倒退的不同期间，咱们做了不同的优化：

1. 应用 HTTP/1.1：客户端将首帧图片域名和评论头像域名进行合并，TCP 链接复用率进步 4%，均匀图片加载耗时降落 40ms 左右；

2. 应用 HTTP/2：客户端在局部域名上灰度应用 H2，卡顿率降落 0.5%

3. 应用 QUIC：客户端针对弱网场景，优先应用 QUIC 协定；同时针对短视频业务特点，专项优化 QUIC 性能。

五、CDN 减速

CDN 的全称叫 Content Delivery Network，中文名叫「内容散发网络」，它是解决因为长距离而网络拜访速度慢的问题。

简略来说，CDN 将内容资源散发到位于多个地理位置机房中的服务器上，这样咱们在拜访内容资源的时候，不必拜访源服务器。而是间接拜访离咱们最近的 CDN 节点，这样一来就省去了长途跋涉的工夫老本，从而实现了网络减速。

CDN 减速的是内容资源是动态资源。

所谓的「动态资源」是指数据内容动态不变，任何时候来拜访都是一样的，比方图片、音频。与之相同的「动静资源」，是指数据内容是动态变化的，每次拜访都不一样，比方用户信息等。不过，动静资源如果也想被缓存减速，就要应用动静 CDN，其中一种形式就是将数据的逻辑计算放在 CDN 节点来做，这种形式就被称为边缘计算。

CDN 减速策略有两种形式，别离是「推模式 」和「 拉模式」。

大部分 CDN 减速策略采纳的是「拉模式」，当用户就近拜访的 CDN 节点没有缓存申请的数据时，CDN 会被动从源服务器下载数据，并更新到这个 CDN 节点的缓存中。能够看出，拉模式属于被动缓存的形式，与之相同的「推模式」就属于被动缓存的形式。如果想要把资源在还没有用户拜访前缓存到 CDN 节点，则能够采纳「推模式」，这种形式也叫 CDN 预热。通过 CDN 服务提供的 API 接口，把须要预热的资源地址和须要预热的区域等信息提交下来，CDN 收到后，就会触发这些区域的 CDN 节点进行回源来实现资源预热。

5.1 如何找到离用户最近的 CDN 节点？

找到离用户最近的 CDN 节点是由 CDN 的 全局负载均衡器（Global Sever Load Balance，GSLB）负责的。那 GSLB 是在什么时候起作用的呢？在答复这个问题前，咱们先来看看在没有 CDN 的状况下，拜访域名时产生的事件。在没有 CDN 的状况下，当咱们拜访域名时，DNS 服务器最终会返回源服务器的地址。比方，当咱们在浏览器输出 www.server.com 域名后，在本地 host 文件找不到域名时，客户端就会拜访本地 DNS 服务器。

这时候：

• 如果本地 DNS 服务器有缓存该网站的地址，则间接返回网站的地址；
• 如果没有就通过递归查问的形式，先申请根 DNS，根 DNS 返回顶级 DNS（.com）的地址；再申请 .com 顶级 DNS 失去 server.com 的域名服务器地址，再从 server.com 的域名服务器中查问到 www.server.com 对应的 IP 地址，而后返回这个 IP 地址，同时本地 DNS 缓存该 IP 地址，这样下一次的解析同一个域名就不须要做 DNS 的迭代查问了。

但退出 CDN 后就不一样了。

会在 server.com 这个 DNS 服务器上，设置一个 CNAME 别名，指向另外一个域名 www.server.cdn.com，返回给本地 DNS 服务器。接着持续解析该域名，这个时候拜访的就是 server.cdn.com 这台 CDN 专用的 DNS 服务器，在这个服务器上，又会设置一个 CNAME，指向另外一个域名，这次指向的就是 CDN 的 GSLB。接着，本地 DNS 服务器去申请 CDN 的 GSLB 的域名，GSLB 就会为用户抉择一台适合的 CDN 节点提供服务，抉择的根据次要有以下几点：

• 看用户的 IP 地址，查表得悉地理位置，找绝对最近的 CDN 节点；
• 看用户所在的运营商网络，找雷同网络的 CDN 节点；
• 看用户申请 URL，判断哪一台服务器上有用户所申请的资源；
• 查问 CDN 节点的负载状况，找负载较轻的节点。

GSLB 会基于以上的条件进行综合剖析后，找出一台最合适的 CDN 节点，并返回该 CDN 节点的 IP 地址给本地 DNS 服务器，而后本地 DNS 服务器缓存该 IP 地址，并将 IP 返回给客户端，客户端去拜访这个 CDN 节点，下载资源。

5.2 vivo 短视频所做的优化

通过咱们剖析后发现，局部接入 CDN 的域名在全国一些省份没有就近拜访，CDN 边缘节点跨地区笼罩问题比较严重。于是咱们找 CDN 厂商针对性的做了调整，调整后均匀申请耗时降到 300ms 左右，首包耗时也降到 100 多。

六、总结与瞻望

随着业务的倒退，晋升用户体验也会变得越来越重要，用户拜访体验优化将是一个永无止境的过程，除了下面说的这些办法之外，还有一些优化也是咱们尝试过的，比方：

• 连贯优化：视频播放高低滑动会频繁的断开连接, 无奈复用连贯。
• 预缓存文件：缩小启动耗时。
• 内容优化：缩小文件传输大小。

心愿本文能为大家在日常工作中优化用户拜访体验问题带来帮忙。