筆記： 移動互聯網時代 , 如何優化你的網絡 —— HttpDNS
-
1.域名解析是什麼？
- 域名通過DNS（Domain Name System）系統轉化爲服務器的IP地址，以方便機器通過IP 進行尋址和通信
-
2.專用名詞
-
根域、頂級域、二級域 :DNS系統一般採用樹狀結構進行組織，以ru.wikipedia.org爲例，org爲頂級域名，wikipedia爲二級域名，ru爲三級域名
-
權威DNS:權威DNS即最終決定域名解析結果的服務器，開發者可以在權威DNS上配置、變更、刪除具體域名的對應解析結果信息。阿里云云解析（https://wanwang.aliyun.com/domain/dns ）即權威DNS服務提供商。
-
遞歸DNS：遞歸DNS又稱爲Local DNS，它沒有域名解析結果的決定權，但代理了用戶向權威DNS獲取域名解析結果的過程,遞歸DNS上有緩存模塊(結果緩存的時間超過TTL，即過期)，遞歸DNS會一級一級地查詢各個層級域名的權威DNS直至獲取最終完整域名的解析結果
-
公共DNS：公共DNS是遞歸DNS的一種特例，它是一種全網開放的遞歸DNS服務，而傳統的遞歸DNS信息一般由運營商分發給用戶。一個比較典型的公共DNS即Google的8.8.8.8，我們可以通過在操作系統配置文件中配置公共DNS來代替Local DNS完成域名解析流程
-
-
3.解析流程
-
以訪問www.taobao.com爲例，一次完整的域名解析流程包括：
- 終端向Local DNS發起域名解析請求；
- Local DNS在獲取到域名解析請求後首先從Root hints獲取根域名服務器的地址（Root hints包含了互聯網DNS根服務器的地址信息）；
- 獲取了根域名服務器地址後Local DNS向根域名服務器發起DNS解析請求，根域名服務器返回com頂級域名服務器地址；
- 隨後Local DNS向com域名服務器發起解析請求，並得到taobao.com二級域名服務器的地址；
- Local DNS向taobao.com二級域名服務器發起解析請求，並最終獲得了www.taobao.com的IP地址信息；
- Local DNS將遞歸查詢獲得的IP地址信息緩存並返回給客戶端；
-
-
4.傳統的域名解析面臨的問題
-
域名劫持
-
例如域名A應該返回的DNS解析結果IP1被惡意替換爲了IP2，導致A的訪問失敗或訪問了一個不安全的站點,常見的域名劫持場景
-
黑客侵入了寬帶路由器並對終端用戶的Local DNS進行篡改，指向黑客自己僞造的Local DNS，進而通過控制Local DNS的邏輯返回錯誤的IP信息進行域名劫持
-
由於DNS解析主要是基於UDP協議，攻擊者還可以監聽終端用戶的域名解析請求，並在Local DNS返回正確結果之前將僞造的DNS解析響應傳遞給終端用戶，進而控制終端用戶的域名訪問行爲
-
最常碰到的域名劫持現象是緩存污染
- 在接收到域名解析請求時，Local DNS首先會查找緩存，如果緩存命中則返回緩存結果，不再進行遞歸DNS查詢。如果Local DNS針對部分域名的緩存進行更改，比如將緩存結果指向第三方的廣告頁，就會導致用戶的訪問請求被引導到這些廣告頁地址上
-
備註: Https並不能避免域名劫持的問題，域名解析是發生在網絡加密請求交互之前，得先進行域名解析，之後纔會有網絡加密請求交互， https = http + ssl，SSL只是對服務端進行身份確認，而域名解析是發生在ssl握手之前，所以https並不能解決域名劫持的問題
-
-
-
調度不精準
-
解析轉發
- Local DNS供應商將請求到自己Local DNS的域名解析請求轉發給其他供應商的Local DNS節點，而最終的權威DNS在進行域名解析時會根據Local DNS的IP信息進行智能調度(分配於請求方最近最優相同運營商的CDN節點)，導致Local DNS分配的不是最佳的CDN節點,由於請求是被轉發的，從而也延遲用戶業務訪問時間
-
Local DNS的佈署情況
- 由於Local DNS的資源有限，Local DNS的分配甚至並非遵循就近原則。比如有實際案例顯示西藏的用戶甚至被分配了北京的Local DNS節點C，導致西藏的用戶在進行CDN資源訪問時被調度到了北京的CDN節點C上，類似的由於調度精度的缺失帶來的訪問體驗的影響是非常嚴重的
-
-
解析生效滯後
- 權威DNS變更的解析結果生效滯後: Local DNS的部署是由各個地區的各個運營商獨立部署的, 因此各個Local DNS的服務質量參差不齊. 在對域名解析緩存的處理上，各個獨立節點的實現策略也有區別，比如部分節點爲了節省開支忽略了域名解析結果的TTL時間限制，導致用戶在權威DNS變更的解析結果全網生效的週期非常漫長。這類延遲生效可能直接導致用戶業務訪問的異常
-
延遲大
- DNS首次查詢或緩存過期後的查詢，需要遞歸遍歷多個DNS服務器以獲取最終的解析結果，這增加了網絡請求的前置延時時間。特別在弱網環境下，往往導致解析超時、解析失敗
-
-
5.HTTPDNS
通過HTTPDNS服務，我們可以實現包括防止域名劫持、精準調度、實時解析生效等功能，但在DNS解析開銷的優化上，我們需要客戶端一起配合
-
防域名劫持
-
HTTPDNS使用HTTP協議進行域名解析，代替現有基於UDP的DNS協議，域名解析請求直接發送到HTTPDNS服務端，從而繞過運營商的Local DNS
-
商業化的HTTPDNS服務（https://www.aliyun.com/product/httpdns）緩存管理有嚴格的SLA保障，避免了類似Local DNS的緩存污染的問題
-
-
精準調度
- HTTPDNS在遞歸解析實現上優化了與權威DNS的交互，通過edns-client-subnet協議（https://datatracker.ietf.org/doc/rfc7871）將終端用戶的IP信息直接交付給權威DNS，這樣權威DNS就可以忽略Local DNS IP信息，根據終端用戶的IP信息進行精準調度，避免LocalDNS的座標干擾
-
實時生效
商業化的HTTPDNS服務上不會存在解析變更全網生效滯後的問題
- HTTPDNS在快速生效方面有專有的方案，配合阿里雲的權威DNS服務雲解析（https://wanwang.aliyun.com/domain/dns），用戶在權威DNS變更的解析結果將快速同步給HTTPDNS，覆蓋原有的緩存記錄，幫助用戶實現秒級的域名解析切換
-
備註： 在DNS解析延遲方面，由於HTTPDNS基於HTTP協議，而HTTP基於TCP協議，對比傳統的UDP傳輸多了一些冗餘的握手環節，因此從原理上而言網絡請求方面的開銷並沒有降低。但在實際使用過程中，我們可以通過端上的策略來實現一個零延遲DNS解析的方案,下面從客戶端角度實現零延遲DNS解析
-
-
6.域名解析最佳實踐
-
預解析
在App啓動時，針對業務的熱點域名在後臺發起異步的HttpDNS解析請求，這部分預解析結果在後續的業務請求中可以直接使用，進而消除首次業務請求的DNS解析開銷，提升APP首頁的加載速度
-
智能緩存
通過預解析獲取的IP有一定的TTL有效時間，我們需要合理地緩存下來進行管理。操作系統本身的DNS緩存粒度比較粗，在客戶端我們可以應用更細粒度的緩存管理來提升解析效率.
比如當手機網絡切換不同的運營商時(比如移動/聯通/電信)，對CDN域名的解析結果會發生變化(返回就近的運營商CDN節點IP). 由於本地有緩存，可以避免在網絡切換時減少DNS解析帶來的額外開銷. 當下一次APP啓動時直接讀取緩存用於網絡訪問，以提升首屏加載的速度
-
懶加載
-
核心的實現思路: 業務層的域名解析請求只和緩存進行交互，不實際發生網絡解析請求。如果緩存中存在記錄，不論過期與否，先返回業務層緩存中的記錄,如果緩存中的記錄已過期，則異步網絡請求進行HttpDNS解析結果並刷新緩存
-
業務場景： 後端IP是固定的若干個節點，因此連續的解析結果在環境不變的情況下有很大概率是保持一致的
-
不適用場景：業務場景下IP變化頻繁，並且TTL過期的IP訪問不可用，是不建議應用懶加載策略的
-
提個問題，如何快速將權威DNS變更的解析結果同步給HttpDNS
HTTPDNS在快速生效方面有專有的方案，配合阿里雲的權威DNS服務雲解析（https://wanwang.aliyun.com/domain/dns），用戶在權威DNS變更的解析結果將快速同步給HTTPDNS，覆蓋原有的緩存記錄，幫助用戶實現秒級的域名解析切換( 查看上面HttpDNS功能 ---- 實時生效 )
-
-
-
7.HttpDNS接入的注意點
- 客戶端接入HttpDNS的過程中，要注意手動設置http請求頭的host值，原因是HttpDNS中需要將請求的URL的Host值替換爲HttpDNS解析獲得的ip,而一般網絡庫(例如HttpUrlConnection)都會將URL中的Host值賦值給Http請求頭中的host頭，由於服務端會將http請求頭的host值作爲請求的域名信息進行處理，這將導致服務器解析出現問題
-
8.學習鏈接: