- 一、业务背景
- 二、 问题
-
三、问题排查
- 3.1、问题一: 基于DNS 延迟的解析
-
3.2、问题二:HTTPDNS侧
- HTTPDNS基础理论
- 相关问题
-
四、优化方向
- 4.1、域名解析配置
- 4.2、靠近 HTTPDNS 服务端层
- 4.3、靠近用户层
-
五、扩展
- 5.1、如何测试本地到权威DNS服务器 获取域名的时间
- 5.2、 同地区不同网络,访问HTTPDNS 会不会命中缓存。
一、业务背景
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
用户面向的群体是全球,所以我们有多个接入。背后通过专线打通。
三、问题排查
不管是从前往后查,还是从后往前查。每个阶段都需要查下。
- 用户访问到接入层的网络
- 接入层到网关的网络。
- 各个服务的耗时。看下链路追踪。
这里也就直接说下我们重点关注的问题的地方: 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基础理论
HTTPDNS
的原理:
原本用户进行 DNS
解析是向运营商的 DNS
服务器发起 UDP
报文进行查询,而在 HTTPDNS
下,修改为用户带上待查询的域名和本机 IP
地址直接向 HTTPDNS
服务器发起 HTTP 请求,这个 HTTPDNS
服务将返回域名解析后的IP
地址。那么这个 HTTPDNS
服务器会做什么? 第一 HTTPDNS
获取到请求后,如果当前节点(HTTPDNS
有很多节点) 没有缓存,那么 HTTPDNS
当前节点会向 DNS
权威服务器 发起请求获取对应的解析记录。
那么一个域名的 DNS
权威服务器是什么? 我们可以找到我们的域名再对应的 DNS
管理可以看到。我们的 DNS
服务器信息。
[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% 的阈值和 异步。说是后期会有。
也就是说,HTTPDNS
, 服务端做的缓存只有存在一个基于TTL的缓存,如果你的请求是在TTL 过期的时间后,那么那一次请求 HTTPDNS
会耗时比较久。我测试了几次,第一次获取基本需要400MS
左右。
四、优化方向
4.1、域名解析配置
-
尽量只配置一层解析。或者使用 CNAME 加速。
假设
a.com
,b.com
,c.com
都是在 解析的域名:域名 记录类型 记录值 www.a.com CNAME www.b.com www.b.com CNAME www.c.com www.c.com A 1.2.3.4 只配置一层解析也就是
www.a.com
直接 A 记录到具体的IP
,如果我们设置的是
www.a.com
cname
到www.b.com
,www.b.com
cname
到www.c.com
,www.c.com
A 记录到具体的IP
,一般情况下,递归需要到授权服务器请求三次才能得到
www.a.com
的 IP 地址,如下图所示:
启用CNAME
加速功能,授权服务器会把CNAME
记录和最终的 A 记录一次返回给递归,递归服务器由请求三次授权服务器,减小到请求一次,如下图所示:
这样就极大地减少了请求和应答中网络通信消耗的时间,让解析变得更快,特别是在设置多条CNAME
解析记录的情况下,加速效果更明显。
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. 在这个场景下 会不会命中缓存? 可以想一想?文章来源:https://www.toymoban.com/news/detail-474314.html
经过确认, 腾讯云的HTTPDNS
是 同一个地域(省或者直辖市)+同一个运营商,会命中同一个缓存。 但是注意,同一个地域的 HTTPDNS
后端节点有多个,可能请求会到不同的节点,也可能命中不了缓存。文章来源地址https://www.toymoban.com/news/detail-474314.html
到了这里,关于一次有关 DNS 解析导致 APP 慢的问题探究的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!