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

这篇具有很好参考价值的文章主要介绍了一次有关 DNS 解析导致 APP 慢的问题探究。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录
  • 一、业务背景
  • 二、 问题
  • 三、问题排查
    • 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 用户面向的群体是全球,所以我们有多个接入。背后通过专线打通。

三、问题排查

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

  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基础理论

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.comdns28.hichina.com 就是我们这个域名的对应的权威服务器。

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

相关问题

前面讲到 HTTPDNS 会请求 该域名的 DNS 权威服务器, 这里注意我们的域名是托管在AWSrouter53 上的,也就是该域名对应的 DNS 服务器是 AWS 的在海外的。 注意是海外的。 那么这里有个链路就涉及到跨地域了,我们国内的用户访问 HTTPDNSHTTPDNS服务端 再去访问 AWSDNS 服务器,这就涉及到跨地域。我询问了下 httpdns 的技术人员,并让他们给出对比数据。 HTTPDNS服务端 再去访问 AWSDNS 服务器 这个延迟会比访问国内的 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.comb.comc.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 cnamewww.b.com, www.b.com cnamewww.c.comwww.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: 乐观 DNSOptimistic 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 后端节点有多个,可能请求会到不同的节点,也可能命中不了缓存。文章来源地址https://www.toymoban.com/news/detail-474314.html

到了这里,关于一次有关 DNS 解析导致 APP 慢的问题探究的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 基于WebRTC构建的程序因虚拟内存不足导致闪退问题的排查以及解决办法的探究

    目录 1、WebRTC简介 2、问题现象描述 3、将Windbg附加到目标进程上分析

    2024年02月08日
    浏览(53)
  • ES:一次分片设计问题导致的故障

    1. 单节点CPU持续高  2.写入骤降 3.线程池队列积压,但没有reject  4.使用方没有记录日志 1.ES监控 只能看到相应的结果指标,无法反应出原因。 2.ES日志:大量日志打印相关异常(routate等调用栈) 3.查询CPU的使用,GET _nodes/hot_threads “CPU高” 和写入、日志打印相关,无法获取更

    2024年02月11日
    浏览(39)
  • 【现网】记一次并发冲突导致流量放大的生产问题

    目录 事故现象 转账 业务背景介绍 背景一:转账流程 转账流程 转账异常处理 转账异常处理流程图 背景二:账户系统合并 实际全流程: 背景三:扣内存数据库逻辑 背景四:调用方重试逻辑 问题定位 总结  资料获取方法 生产环境,转账相关请求失败量暴增。 直接原因 现网

    2024年02月14日
    浏览(47)
  • 【复盘】记录一次类型不一致导致的Kafka消费异常问题

    业务主要是通过A系统向B系统写入Kafka,然后B系统消费Kafka 将结果写到Kafka中,A进行消费最终结果。 在整个流程中,A写入Kafka会写入一张 record1表记录,然后在A消费最终结果的时候也记录一张record2表。主要改动的话 只是B系统内进行写入数据,但是没有想到用的同一个Map导致

    2024年02月16日
    浏览(38)
  • 记一次BootCDN被黑产挂马导致站点跳转博彩网站的问题

      近期发现公司某些站点出现偶尔跳转博彩网站的现象,经过排查发现该现象为供应链投毒攻击,BootCDN上的静态资源无一例外均被污染, 当外站引入BootCDN的静态资源时,如果请求携带的Referer头为指定值(涉及公司隐私不便透露),User-Agent头为手机浏览器UA,触发恶意代码注

    2024年02月08日
    浏览(38)
  • Android 10(Q) 以上普通 APP 隐藏应用图标问题探究及解决方案

    aosp 版本 10.0 系统 aosp 版本 13.0 系统 APP AndroidManifest.xml 中通过 activity-alias 配置带 LAUNCHER 属性 category,并且 android:enabled=“true” 10.0 系统中可安装后正常显示 icon,通过 setComponentEnabledSetting 隐藏 icon 成功,桌面上不留下 app 相关任何图标 13.0 系统中可安装后正常显示 icon,通过

    2024年01月22日
    浏览(40)
  • 记一次dlopen使用问题导致Framework重启,tombstones、pmap与反汇编分析(上)

    :Android Framework 动态库 动态链接 Binder Android Studio一次更新后发现install App,设备就重启了,跑了一遍开机动画但不是从开机第一屏开始重启,tombstones内容查看发现是 surfaceflinger 挂在 libbinder.so ,那install app做了什么这个不得而知,理论上有问题应该挂的是PackageManager

    2024年04月08日
    浏览(43)
  • DNS解析常见问题:如何为网站配置负载均衡?

    早期的互联网应用,由于用户流量比较小,业务逻辑也比较简单,往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大,系统功能也越来越复杂,单台服务器就算将性能优化得再好,也不足以支撑太大流量的访问压力了,这个时候就需要使用多台机器,设计

    2024年02月15日
    浏览(50)
  • Unity - 记一次非正规变体优化带来的兼容性导致部分手机卡死的问题

    在 2023.4.6 我们的 角色展示界面 就遇到了 华为手机,red mi note 11 的测试手机上的 后 2023.5.24 再次遇到类似的问题,但是这次重现的地方很多,不单止 角色展示界面 遇到 排除过: 模型 特效 场景 人物 材质 后来多次排查,发现是 PBR 所有的 变体拆分优化 的文件导致阴影部分

    2024年02月08日
    浏览(47)
  • 【生产问题记录】一次简单的 Http 请求异常处理 (请求的 url 太长, Nginx 直接返回 400, 导致请求服务异常)

    按照惯例直接说结论。 后台服务 A 有一个 Http 接口, 代码如下: 没错, 一个 Get 请求, 入参是一个 List 。 同时有另一个后台服务 B, 里面有段逻辑会通过 RestTemplate 调用服务 A 的这个接口, 代码如下: 在服务 B 中, 通过 batchGetUserInfo 方法请求服务 A 时, 传入了一个长度为 122 的 List

    2024年01月16日
    浏览(56)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包