産品推薦：阿裡雲物聯網開發者工具（ IoT Studio ）， 立刻免費體驗吧！
IoT物聯網時代，如何優化你的網絡- DNS域名解析服務
1.域名解析服務
裝置以通路指定域名和端口方式接入IoT物聯網平台時，遇到的第一個問題就是接入伺服器域名的DNS解析。
域名(Domain Name)，是由一串用點分隔的名字組成的網際網路上某台計算機或某組計算機的辨別，它的目的是為了友善人們更簡單便捷地通路網際網路上的服務。在實際的系統實作中，域名通過DNS（Domain Name System）系統轉化為伺服器的IP位址，以友善機器通過IP進行尋址和通信。上述行為，我們稱之為域名解析（Domain Name System）。
- 遞歸查詢
遞歸查詢時如果用戶端所詢問的本地域名伺服器不知道被查詢的域名的IP位址，那麼本地域名伺服器就以DNS客戶的身份，向其他頂級域名伺服器繼續發出查詢，直到查詢到結果後，再層層傳遞回來。
- 疊代查詢
疊代查詢時如果用戶端所詢問的本地域名伺服器不知道被查詢的域名的IP位址，那麼會告知下一級域名伺服器的清單，供用戶端詢問。
- 實際場景
實際上，在DNS查詢過程中，本地DNS伺服器會代理用戶端做疊代查詢。但本地DNS沒有域名解析結果的決定權，僅僅代理了使用者向權威DNS擷取域名解析結果的過程。本地DNS上有緩存子產品，當目标域名存在緩存解析結果并且TTL未過期時，本地DNS會傳回緩存結果，否則，本地DNS會一級一級地疊代查詢各個層級域名的權威DNS直至擷取最終完整域名的解析結果。同時用戶端也會根據TTL值做緩存的機制，這樣可以減少查詢的次數，加快域名解析過程。
我們以通路 pk.iot-as-mqtt.cn-shanghai.aliyuncs.com 為例，一次完整的域名解析流程包括：
1.裝置終端向本地DNS發起域名解析請求；
2.本地DNS在擷取到域名解析請求後首先從Root hints擷取根域名(.)伺服器的位址；
3.擷取了根域名伺服器位址後本地DNS向根域名伺服器發起DNS解析請求；
4.根域名伺服器傳回頂級域名(.com)伺服器位址；
5.随後本地DNS向頂級域名(.com)伺服器發起解析請求，并得到二級域名(aliyuncs.com)伺服器的位址；
6.本地DNS向二級域名(aliyuncs.com)伺服器發起解析請求，并最終獲得 pk.iot-as-mqtt.cn-shanghai.aliyuncs.com 的IP位址資訊；
7.本地DNS将遞歸查詢獲得的IP位址資訊根據TTL緩存并傳回給裝置終端；
8.裝置終端向目的IP發起網絡請求； 2.DNS域名解析實驗
2.1 DNS域名解析
如果你要通路域名 pk.iot-as-mqtt.cn-shanghai.aliyuncs.com，首先要通過DNS查出它的IP位址是139.196.135.135。
我們可以使用dig指令來檢視域名對應的IP清單，具體如下：
上圖展示了目前mac電腦從本地DNS伺服器擷取到域名的IP清單，TTL值（Time to live）是18s。
2.2 DNS解析完整過程
DNS伺服器根據域名的層級進行分級查詢，就是從根域名開始，依次查詢每一級域名的NS記錄，直到查到最終的IP位址，過程大緻如下：
1.從"根域名伺服器"查到"頂級域名伺服器"的NS記錄和A記錄（IP位址）
2.從"頂級域名伺服器"查到"二級域名伺服器"的NS記錄和A記錄（IP位址）
3.從"二級域名伺服器"查出"主機名"的IP位址 其中，每一級域名都有自己的NS記錄，NS記錄指向該級域名的域名伺服器。這些伺服器知道下一級域名的各種記錄。
我們通過dig +trace能了解完整解析過程，具體如下：
上圖展示了DNS完整過程，
1.首先Mac電腦從本地DNS伺服器擷取到根域名(.root)伺服器清單，
2.其次從其中一台根域名伺服器(198.41.0.4)擷取到頂級域名(.com)伺服器清單
3.再次從其中一台頂級域名伺服器(192.48.79.30)擷取到二級域名(aliyuncs.com)伺服器清單
4.最後從其中一台二級域名伺服器擷取到了目标域名的IP清單，共3個IP位址 3.物聯網場景DNS解析
3.1 域名解析潛在問題
當我們了解DNS域名解析服務完整過程後，會發現傳統域名解析存在以下問題：
- 域名劫持
域名劫持一直是困擾許多開發者的問題之一，其表現即域名A應該傳回的DNS解析結果IP1被惡意替換為了IP2，導緻A的通路失敗或通路了一個不安全的站點。
- 排程不精準
除了域名劫持問題，基于傳統Local DNS的域名解析還會帶來域名排程精準性的問題。對于類似CDN域名通路這類需要按地域、營運商進行智能解析排程的場景，精準排程的訴求是十分強烈的。
- 解析生效滞後
部分業務場景下開發者對域名解析結果變更的生效時間非常敏感（這部分變更操作是開發者在權威DNS上完成的），比如當業務伺服器受到攻擊時，我們需要最快速地将業務IP切換到另一組叢集上，這樣的訴求在傳統域名解析體系下是無法完成的。
- 延遲大
DNS首次查詢或緩存過期後的查詢，需要遞歸周遊多個DNS伺服器以擷取最終的解析結果，這增加了網絡請求的前置延時時間。特别是在移動網際網路場景下，移動網絡品質參差不齊，弱網環境的RTT時間可能高達數百毫秒，對于一次普通的業務請求而言，上述延時是非常沉重的負擔。另一方面，弱網環境下的解析逾時、解析失敗等現象屢見不鮮，如何合理優化DNS解析對于整體網絡通路品質的提升至關重要。
3.2 阿裡雲HTTPDNS服務
阿裡雲HTTPDNS服務正在這樣的背景下應運而生，為我們提供一個更安全、穩定、高效的遞歸DNS服務代理了域名解析的過程。
HTTPDNS使用HTTP協定進行域名解析，代替現有基于UDP的DNS協定，域名解析請求直接發送到HTTPDNS服務端，進而繞過營運商的本地DNS，将終端使用者的IP資訊直接傳遞給權威DNS，避免本地DNS的坐标幹擾，使用者在權威DNS變更的解析結果将快速同步給HTTPDNS，覆寫原有的緩存記錄，幫助使用者實作秒級的域名解析切換。
3.3 物聯網場景DNS實戰
但我們在IoT物聯網平台控制台建立産品後，會生成對應裝置接入指定域名，參考下圖：
接下來我們要在HTTPDNS的控制台，添加IoT物聯網裝置的接入域名解析服務，參考下圖：
然後，通過直接通路HTTPDNS的IP擷取裝置接入域名的IP清單，參考下圖：
最後，IoT裝置就可以直接通路IP清單中的一個IP，建立與IoT物聯網平台的MQTT長連接配接通道。
[]()