一次有關 DNS 解析導致 APP 慢的問題探究

一、業務背景
二、問題
三、問題排查
- 3.1、問題一：基于DNS 延遲的解析
- 3.2、問題二：HTTPDNS側
  - HTTPDNS基礎理論
  - 相關問題
四、優化方向
五、擴展
- 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記錄。

四、優化方向

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 解析記錄的情況下，加速效果更明顯。

域名	記錄類型	記錄值
www.a.com	CNAME	www.b.com
www.b.com	CNAME	www.c.com
www.c.com	A	1.2.3.4

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 后端節點有多個，可能請求會到不同的節點，也可能命中不了緩存。

posted @ 2023-06-07 11:57 自由早晚亂余生閱讀(1605) 評論(3) 收藏舉報

刷新頁面返回頂部