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

一、業務背景

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基礎理論

img

HTTPDNS 的原理:

原本用戶進行 DNS 解析是向運營商的 DNS 服務器發起 UDP 報文進行查詢,而在 HTTPDNS 下,修改爲用戶帶上待查詢的域名和本機 IP 地址直接向 HTTPDNS 服務器發起 HTTP 請求,這個 HTTPDNS 服務將返回域名解析後的IP地址。那麼這個 HTTPDNS 服務器會做什麼? 第一 HTTPDNS 獲取到請求後,如果當前節點(HTTPDNS 有很多節點) 沒有緩存,那麼 HTTPDNS 當前節點會向 DNS權威服務器 發起請求獲取對應的解析記錄。

那麼一個域名的 DNS 權威服務器是什麼? 我們可以找到我們的域名再對應的 DNS 管理可以看到。我們的 DNS 服務器信息。

image-20230530223820806

[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% 的閾值和 異步。說是後期會有。

image-20230531181616551

也就是說,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 地址,如下圖所示:
    img
    啓用 CNAME 加速功能,授權服務器會把 CNAME 記錄和最終的 A 記錄一次返回給遞歸,遞歸服務器由請求三次授權服務器,減小到請求一次,如下圖所示:
    img
    這樣就極大地減少了請求和應答中網絡通信消耗的時間,讓解析變得更快,特別是在設置多條 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 後端節點有多個,可能請求會到不同的節點,也可能命中不了緩存。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章