技術文章 » 一次有關 DNS 解析導致 APP 慢的問題探究

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

2023-06-07 15:00:51

目錄

一、業務背景

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.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. 在這個場景下 會不會命中快取？ 可以想一想？

經過確認， 騰訊雲的HTTPDNS 是 同一個地域(省或者直轄市)+同一個運營商，會命中同一個快取。 但是注意，同一個地域的 HTTPDNS 後端節點有多個，可能請求會到不同的節點，也可能命中不了快取。