一次有关 DNS 解析导致 APP 慢的问题探究

朴灿烈づ我的快乐病毒、 2024-03-16 14:53 58阅读 0赞

### 一、业务背景 ###

> HTTTPDNS
> 
> AWS Router53

`APP` 使用 `HTTPDNS`， 为解决 `DNS` 解析生效慢， `DNS` 劫持等问题。

我们 `IOS` 和安卓都是使用了 `HTTPDNS`。

域名托管在 `AWS` `Router53`。

域名有多个解析(基于延迟)，为了解决就近接入。

示例配置

ai.baidu.com	CNAME	延迟	亚太地区(香港)	alias-ai-hk.baidu.com
    ai.baidu.com	CNAME	延迟	默认值 	123455.baidu.com
    ai.baidu.com	CNAME	延迟	中国	alias-ai-zh.baidu.com
    alias-ai-zh.baidu.com  A - - 18.18.18.18(国内ip接入)

### 二、 问题 ###

很直观的体现就是, `APP` 打开很慢。反馈主要是国内的用户。`APP` 用户面向的群体是全球，所以我们有多个接入。背后通过专线打通。

### 三、问题排查 ###

不管是从前往后查，还是从后往前查。每个阶段都需要查下。

1.  用户访问到接入层的网络
2.  接入层到网关的网络。
3.  各个服务的耗时。看下链路追踪。

这里也就直接说下我们重点关注的问题的地方： DNS 解析。

#### 3.1、问题一： 基于DNS 延迟的解析 ####

因为我们发现由于是基于`DNS 延迟`的策略，我发现在深圳通过 `HTTPDNS` 接口获取对应域名的解析，有很大概率会解析到香港的节点。 我们发现这个并不准确。

然后我们调整为 基于 地理位置 的 路由策略。

ai.baidu.com	CNAME	地理位置	香港	 alias-ai-hk.baidu.com
    ai.baidu.com	CNAME	地理位置	默认值 	123455.awsglobalaccelerator.com
    ai.baidu.com	CNAME	地理位置	中国	alias-ai-zh.baidu.com
    alias-ai-zh.baidu.com  A - - 18.18.18.18(国内ip接入)

我们经过测试，发现这个对应的大陆请求都是解析到大陆的节点。 经过这次调整，我们几个`APP` 好像打开都快了点(不知道是不是心里作用)。 我们继续往下看。

#### 3.2、问题二：HTTPDNS侧 ####

HTTPDNS基础理论

![b305b8cc256654fb89475a44ef6181ae.png][]

`HTTPDNS` 的原理：

原本用户进行 `DNS` 解析是向运营商的 `DNS` 服务器发起 `UDP` 报文进行查询，而在 `HTTPDNS` 下，修改为用户带上待查询的域名和本机 `IP` 地址直接向 `HTTPDNS` 服务器发起 HTTP 请求，这个 `HTTPDNS` 服务将返回域名解析后的`IP`地址。那么这个 `HTTPDNS` 服务器会做什么？ 第一 `HTTPDNS` 获取到请求后，如果当前节点(`HTTPDNS` 有很多节点) 没有缓存，那么 `HTTPDNS` 当前节点会向 `DNS`权威服务器 发起请求获取对应的解析记录。

那么一个域名的 `DNS` 权威服务器是什么？ 我们可以找到我们的域名再对应的 `DNS` 管理可以看到。我们的 `DNS` 服务器信息。

![2f085027301b13ceaefa6cac110b2ebb.png][]

[root@185 ~]# dig xiaoaxiao.cn
    
    ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> xiaoaxiao.cn
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16195
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;xiaoaxiao.cn.			IN	A
    
    ;; AUTHORITY SECTION:
    xiaoaxiao.cn.		600	IN	SOA	dns27.hichina.com. hostmaster.hichina.com. 2022052002 3600 1200 86400 600
    
    ;; Query time: 261 msec
    ;; SERVER: ……
    ;; WHEN: Tue May 30 22:37:28 CST 2023
    ;; MSG SIZE  rcvd: 105

其中 `dns27.hichina.com` 和 `dns28.hichina.com` 就是我们这个域名的对应的权威服务器。

每个域名的`权威DNS服务器`是指该域名的`DNS服务器`，它负责管理该域名下的所有`DNS记录`，包括`IP地址`、邮件服务器、别名等。`权威DNS服务器`的作用是回答其他`DNS服务器`关于该域名的`所有DNS查询请求`。当用户访问该域名时，他们的计算机会向该域名的`权威DNS服务器`发送查询请求，以获取与该域名相关的`IP地址`和其他`DNS记录`。

相关问题

前面讲到 `HTTPDNS` 会请求 该域名的 `DNS 权威服务器`， 这里注意我们的域名是托管在`AWS` 的 `router53` 上的，也就是该域名对应的 `DNS` 服务器是 `AWS` 的在海外的。 注意是海外的。 那么这里有个链路就涉及到跨地域了，我们国内的用户访问 `HTTPDNS`，`HTTPDNS`服务端 再去访问 `AWS` 的`DNS` 服务器，这就涉及到跨地域。我询问了下 `httpdns` 的技术人员，并让他们给出对比数据。 `HTTPDNS`服务端 再去访问 `AWS` 的`DNS` 服务器 这个延迟会比访问国内的 `DNS服务器`慢很多。

北京：dp（35ms），aws（110ms）；
    上海：dp（3ms），aws（61ms）；
    广州：dp（5ms），aws（90ms）;

那么这也是一个慢的原因。

我们继续怀着疑问，那么 `HTTPDNS` 服务端的节点不会有缓存吗？ 如果有缓存的话那也只有第一次会慢。 `HTTPDNS`对应的技术人员告诉我们目前的策略是，是有缓存的，基于域名的 `ttl` 值来进行缓存的。当到达 `ttl` 值的 `30%` 剩余时间，如果剩余时间内有请求过来，那么会异步去再去请求权威服务器来刷新当前的缓存值。 如果没有请求，则到了`ttl` 值缓存失效。

*  ttl 值
 *  请求量。

> 实际测试并不是这个逻辑。 根本没有 30% 的阈值和 异步。说是后期会有。
> 
> ![b615cf61f581c029cf858360f7ae4f6f.png][]

也就是说，`HTTPDNS`， 服务端做的缓存只有存在一个基于TTL的缓存，如果你的请求是在TTL 过期的时间后，那么那一次请求 `HTTPDNS` 会耗时比较久。我测试了几次，第一次获取基本需要`400MS`左右。

### 四、优化方向 ###

#### 4.1、域名解析配置 ####

*  尽量只配置一层解析。或者使用 **CNAME 加速**。
    
    假设 `a.com`，`b.com`，`c.com` 都是在 解析的域名：
    
    <table> 
     <thead> 
      <tr> 
       <th>域名</th> 
       <th>记录类型</th> 
       <th>记录值</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>www.a.com</td> 
       <td>CNAME</td> 
       <td>www.b.com</td> 
      </tr> 
      <tr> 
       <td>www.b.com</td> 
       <td>CNAME</td> 
       <td>www.c.com</td> 
      </tr> 
      <tr> 
       <td>www.c.com</td> 
       <td>A</td> 
       <td>1.2.3.4</td> 
      </tr> 
     </tbody> 
    </table>
    
    只配置一层解析也就是 `www.a.com` 直接 A 记录到具体的 `IP`，

#### 4.2、靠近 HTTPDNS 服务端层 ####

*  缩减 `HTTPDNS` 到权威服务器之间的耗时。 把域名切到 `DNSPOD` 、万网等国内域名商。 `AWS`(非`AWS` 中国) `Router53` 不支持国内 `DNS` 节点。
 *  调整 `TTL` 值， 也就是增大 `TTL` 值，让它在 `HTTPDNS` 服务端缓存失效的时间变长，时间变长，在相同时间范围内，需要去请求权威服务器的次数也会变少。
 *  增加请求量， 像 `HTTPDNS` 某个运营商在国内有近 `100`多个节点。 如果我们的请求量达不到一个层级的话。那么请求到每个节点的请求去命中缓存的概率也会降低。 这样可以通过拨测实现，但是注意，不是直接拨测对应的域名，拨测的应该特定的接口(`HTTPDNS` 的接口)。 如果直接拨测域名的话，只是改变的公网解析的场景，而改变不了`HTTPDNS` 的场景。

#### 4.3、靠近用户层 ####

> 也就是APP 层

*  **减少请求HTTPDNS**
    
    尽量使用缓存的`DNS` ， 不要频繁请求 `HTTPDNS`。
 *  **预解析和乐观DNS**
    
    预解析： 绝大多数的 `APP` 在应用初始化阶段都有一个启动期，我们可以在这个启动期做一些`preflight`工作，即在初始化阶段我们可以针对业务的热点域名在后台发起异步的 `HTTPDNS` 解析请求。这部分预解析结果在后续的业务请求中可以直接使用，进而消除首次业务请求的 `DNS` 解析开销，提升 `APP` 首页的加载速度。
    
    乐观DNS： 乐观 `DNS`（`Optimistic DNS`）是一种基于缓存的 `DNS` 解析方法，它认为大多数 `DNS` 查询都会命中缓存，因此不需要每次都向上游 `DNS` 服务器发送查询请求，而是直接使用本地缓存中的结果。只有在缓存中没有找到对应的解析结果时，才会向上游 `DNS` 服务器发送请求。

### 五、扩展 ###

#### 5.1、如何测试本地到权威DNS服务器 获取域名的时间 ####

[root@185 ~]# time dig @ns4.dnsv4.com  www.a.com  
    ……
    
    real	0m0.074s
    user	0m0.006s
    sys	    0m0.008s

#### 5.2、 同地区不同网络，访问HTTPDNS 会不会命中缓存。 ####

比如同一个手机，不同的网络，切换 联通到电信 在TTL 时间范围内，访问 HTTPDNS(腾讯云) 会不会命中缓存？  
比如后面的 DNS 配置只配置了，基于地理位置的逻辑的配置。 比如 国内 到 A ， 国外到 B. 在这个场景下 会不会命中缓存？ 可以想一想？

经过确认， 腾讯云的`HTTPDNS` 是 同一个地域(省或者直辖市)+同一个运营商，会命中同一个缓存。 但是注意，同一个地域的 `HTTPDNS` 后端节点有多个，可能请求会到不同的节点，也可能命中不了缓存。

[b305b8cc256654fb89475a44ef6181ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/28af55e7351b4dff9e68c3485816aefd.png
[2f085027301b13ceaefa6cac110b2ebb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/3ecc67802a6144248e5ef5ac7858a6f7.png
[b615cf61f581c029cf858360f7ae4f6f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/6ab7665503c04da0ac26d957c6d327e6.png