為什麼要 dns 解析？
因為 http 是基於 tcp 連線的，而 tcp 則是通過 ip 位址去識別訪問的。dns 解析就是網域名稱轉化成 ip 位址的過程。
dns解析過程：
參考文章：地圖
當我們在瀏覽器的位址列輸入**（譬如： www.linux178.com） ，然後回車，回車這一瞬間到看到頁面到底發生了什麼呢？
網域名稱解析 –> 發起tcp的3次握手 –> 建立tcp連線後發起http請求 –> 伺服器響應http請求，瀏覽器得到html** –> 瀏覽器解析html**，並請求html**中的資源（如js、css、等） –> 瀏覽器對頁面進行渲染呈現給使用者。
網域名稱解析是頁面載入的第一步，那麼網域名稱是如何解析的呢？以chrome為例：
1.chrome瀏覽器 會首先搜尋瀏覽器自身的dns快取（快取時間比較短，大概只有1分鐘，且只能容納1000條快取），看自身的快取中是否有www.linux178.com 對應的條目，而且沒有過期，如果有且沒有過期則解析到此結束。
注：我們怎麼檢視chrome自身的快取？可以使用 chrome://net-internals/#dns 來進行檢視。
2.如果瀏覽器自身的快取裡面沒有找到對應的條目，那麼chrome會搜尋作業系統自身的dns快取,如果找到且沒有過期則停止搜尋解析到此結束.
注：怎麼檢視作業系統自身的dns快取，以windows系統為例，可以在命令列下使用 ipconfig /displaydns 來進行檢視。
3.如果在windows系統的dns快取也沒有找到，那麼嘗試讀取hosts檔案（位於c:\windows\system32\drivers\etc），看看這裡面有沒有該網域名稱對應的ip位址，如果有則解析成功。
4.如果在hosts檔案中也沒有找到對應的條目，瀏覽器就會發起乙個dns的系統呼叫，就會向本地配置的首選dns伺服器（一般是電信運營商提供的，也可以使用像google提供的dns伺服器）發起網域名稱解析請求（通過的是udp協議向dns的53埠發起請求，這個請求是遞迴的請求，也就是運營商的dns伺服器必須得提供給我們該網域名稱的ip位址），運營商的dns伺服器首先查詢自身的快取，找到對應的條目，且沒有過期，則解析成功。
如果沒有找到對應的條目，則有運營商的dns代我們的瀏覽器發起迭代dns解析請求，它首先是會找根域的dns的ip位址（這個dns伺服器都內建13臺根域的dns的ip位址），找打根域的dns位址，就會向其發起請求（請問www.linux178.com這個網域名稱的ip位址是多少啊？），根域發現這是乙個頂級域com域的乙個網域名稱，於是就告訴運營商的dns我不知道這個網域名稱的ip位址，但是我知道com域的ip位址，你去找它去，於是運營商的dns就得到了com域的ip位址，又向com域的ip位址發起了請求（請問www.linux178.com這個網域名稱的ip位址是多少?）,com域這台伺服器告訴運營商的dns我不知道www.linux178.com這個網域名稱的ip位址，但是我知道linux178.com這個域的dns位址，你去找它去，於是運營商的dns又向linux178.com這個網域名稱的dns位址（這個一般就是由網域名稱註冊商提供的，像萬網，新網等）發起請求（請問www.linux178.com這個網域名稱的ip位址是多少？），這個時候linux178.com域的dns伺服器一查，誒，果真在我這裡，於是就把找到的結果傳送給運營商的dns伺服器，這個時候運營商的dns伺服器就拿到了www.linux178.com這個網域名稱對應的ip位址，並返回給windows系統核心，核心又把結果返回給瀏覽器，終於瀏覽器拿到了www.linux178.com對應的ip位址，該進行一步的動作了。
注：一般情況下是不會進行以下步驟的
如果經過以上的4個步驟，還沒有解析成功，那麼會進行如下步驟：
5.作業系統就會查詢netbios name cache（netbios名稱快取，就存在客戶端電腦中的），那這個快取有什麼東西呢？凡是最近一段時間內和我成功通訊的計算機的計算機名和ip位址，就都會存在這個快取裡面。什麼情況下該步能解析成功呢？就是該名稱正好是幾分鐘前和我成功通訊過，那麼這一步就可以成功解析。
6.如果第5步也沒有成功，那會查詢wins 伺服器（是netbios名稱和ip位址對應的伺服器）。
7.如果第6步也沒有查詢成功，那麼客戶端就要進行廣播查詢。
8.如果第7步也沒有成功，那麼客戶端就讀取lmhosts檔案（和hosts檔案同乙個目錄下，寫法也一樣）
如果第八步還沒有解析成功，那麼就宣告這次解析失敗，那就無法跟目標計算機進行通訊。只要這八步中有一步可以解析成功，那就可以成功和目標計算機進行通訊。
dns也是開銷，通常瀏覽器查詢乙個給定網域名稱的ip位址要花費20~120毫秒，在完成網域名稱解析之前，瀏覽器不能從伺服器載入到任何東西。那麼如何減少網域名稱解析時間，加快頁面載入速度呢？
當客戶端dns快取（瀏覽器和作業系統）快取為空時，dns查詢的數量與要載入的web頁面中唯一主機名的數量相同，包括頁面url、指令碼、樣式表、、flash物件等的主機名。減少主機名的 數量就可以減少dns查詢的數量。
dns查詢過程：
1. 檢視瀏覽器內部快取
檢測網域名稱是否存在於瀏覽器快取中，如果有快取直接使用，沒有則下一步。開啟 chrome://net-internals/#dns 即可檢視本機瀏覽器的 dns 快取。
2. 系統快取
瀏覽器會呼叫乙個類似 gethostbyname 的庫函式，此函式會先去檢測本地 hosts 檔案，檢視是否有對應 ip。
ps： 這裡有乙個點，localhost 預設 ip 是 172.0.0.1，這是乙個回路段，也叫換回介面。也就是不會發往伺服器，是直接在本地開啟的。
3. 路由器快取、isp 快取
如果瀏覽器和系統快取都沒有，系統的 gethostname 函式就會像 dns 伺服器傳送請求。而網路服務一般都會先經過路由器以及網路服務商（電信），所以會先查詢路由器快取，然後再查詢 isp 的 dns 快取。
4. 本地 dns 伺服器
通常為自己計算機搭建的小型 dns 伺服器，自我使用，屬於 dns 優化的一部分。
5. 網域名稱伺服器
到此處的過程為：根域伺服器（.） -> 頂級網域名稱伺服器（eg: .com，.org）->
主網域名稱伺服器（eg: google.com）
如果網域名稱正常，應該就會返回 ip 位址，如果沒有瀏覽器就會提示找不到伺服器位址。
dns優化
dns 查詢的過程經歷了很多的步驟，如果每次都如此，是不是會耗費太多的時間，資源。所以我們應該盡早的返回真實的 ip 位址，減少查詢過程，也就是 dns 快取。瀏覽器獲取到 ip 位址後，一般都會加到瀏覽器的快取中，本地的 dns 快取伺服器，也可以去記錄。另外，每天幾億網名的訪問需求，一秒鐘幾千萬的請求網域名稱伺服器如何滿足？就是 dns 負載均衡。
通常我們的**應用各種雲服務，或者各種服務商提供類似的服務，由他們去幫我們處理這些問題。dns 系統根據每台機器的負載量，地理位置的限制
（長距離的傳輸效率）等等，去提供高效快速的 dns 解析服務。
參考文章（從瀏覽器輸入乙個 url 到頁面渲染，涉及的知識點及優化點）：
DNS查詢過程
dns domain name system 將網域名稱和ip位址相互對映的乙個分布式資料庫服務。dns使用的是網路查詢，使用的埠是53號埠 通常dns是以udp資料傳輸協議來查詢的，當沒有查詢到完整的資訊時，就會再次以tcp這個協議來重新查詢。所以在啟動dns時，會同時啟動tcp和udp的53號埠...
DNS查詢過程
dns查詢過程 假設www.abc.com的主機要查詢www.xyz.abc.com的伺服器ip位址。知識點2 域 abc.com是乙個域，它可以劃分為多個區域，如abc.com和xyz.abc.com 步驟遞迴查詢 第二步 上一步無法找到，去dns本地伺服器 即域伺服器 查詢，其本質是去區域伺服器...
DNS 客戶端查詢過程
dns客戶端的註冊資訊在dns伺服器中是以記錄的方式體現出來的，那麼客戶端就可以用一些方式進行查詢各類記錄。相對應的，伺服器會對這些查詢進行響應，我們稱之為解析，至於dns內部的工作機制，我們不得而知，但可以通過一些命令和方法間接地了解dns查詢過程。為了更好的描述這個問題，我做了一張簡單的topo...