淺談域名發散與域名收斂

性能優化一直是前端工做中十分重要的一環，都說從 10 到 1 容易，從 1 到 0 很難。而隨着前端技術的飛速發展，沒有什麼技術或者法則是金科玉律一成不變的。

很佩服那些敢於挑戰權威，推陳出新的勇者，是他們讓咱們的技術不斷的變革更加的卓越。好像扯遠了，本文主要想談談兩個名詞，域名發散和域名收斂。

 

   域名發散

這個很好理解，前端er都知道，PC 時代爲了突破瀏覽器的域名併發限制，遵循這樣一條定律：

· http 靜態資源採用多個子域名

嗯，爲何要這樣作呢，目的是充分利用現代瀏覽器的多線程併發下載能力。

因爲瀏覽器的限制，每一個瀏覽器，容許對每一個域名的鏈接數通常是有上限的，附圖一枚：

上圖展現了各瀏覽器的並行鏈接數（同域名），能夠看到在一些現代瀏覽器內每一個 hostname 的最大鏈接數基本都是6個，IE 稍顯傲嬌，整體而言併發數不高。

因此 PC 時代對靜態資源優化時，一般將靜態資源分佈在幾個不一樣域，保證資源最完美地分域名存儲，以提供最大並行度，讓客戶端加載靜態資源更爲迅速。

 

另外，爲何瀏覽器要作併發限制呢？

一、究其根本緣由，在之前，服務器的負載能力差，稍微流量大一點服務器就容易就崩潰。 因此爲了保護服務器不被強暴到崩潰，瀏覽器要對 max connections（最大併發數）進行限制。若是每一個用戶的最大併發數不限制的話，服務器的負載能力會大幅降低。 
二、另外還有一個方面就是, 防止 DDOS 攻擊。最基本的 DoS 攻擊就是利用合理的服務請求來佔用過多的服務資源，從而使合法用戶沒法獲得服務的響應。若是不限制併發請求數量，後果，啊哦，你懂的。（有讀者指出說這一點並不合理，沒人發DDOS是經過瀏覽器去發的。查找文獻後，我我的得出的結論是在一個 http 請求過程當中的任何一步均可以被利用來進行 DDOS 攻擊，那麼放開併發限制，會不會間接致使被人利用進行 DDOS 攻擊呢，我的觀點，但願有人能繼續提出指正！）

 

   域名收斂

本文的重點是想談談域名收斂，顧名思義，域名收斂的意思就是建議將靜態資源只放在一個域名下面，而非發散狀況下的多個域名下。

上面也說到了，域名發散能夠突破瀏覽器的域名併發限制，那麼爲要反其道而行之呢？由於因地制宜，不一樣狀況區別對待，域名發散是 PC 時代的產物，而如今進入移動互聯網時代，經過無線設備訪問網站，App的用戶已佔據了很大一部分比重，而域名收斂正是在這種狀況下提出的。且聽我一步步分析。

 

  http 請求過程

首先要知道，使用一個 http 請求去請求一個資源時，會經歷些什麼。簡單而言：

一、DNS 域名解析 --> 

二、發起 TCP 的 3 次握手 --> 

三、創建 TCP 鏈接後發起 http 請求 --> 

四、服務器響應 http 請求

五、......略

在這裏第一步，也是關鍵的第一步 DNS 解析，在移動端的 http 請求耗時中，DNS 解析佔據了大部分時間。

說 DNS 域名解析過程前，再科普一下域名結構。

 

  域名結構

域名的結構（或者叫命名空間）是一個樹狀結構，有樹就得有根，這個根是一個點‘.’（dot）。

以 www.example.com 爲例，完整的形式應該是 www.example.com. ，注意最後一個點，就是根結點 root ，只不過平時是瀏覽器或者系統的解析器自動幫咱們補全了。咱們要想獲取根域都有那些，能夠在終端下直接使用 dig 命令（須要安裝 dig 指令），以下:

能夠看到有 13 個，大部分都是在國外，根節點以後就是頂級域名，就是.cn .com .gov 這些，頂級域劃分爲通用頂級域 （com、org、net 等）和國家與地區頂級域（cn、hk、us、tw 等）。咱們能夠繼續使用 dig 查看一下 頂級域名的解析路徑，加上 +trace 參數選項，意思是追蹤 DNS 解析過程，以下：

能夠看到是先到根節點，再查找到 com ，就是根結點會告知下一個結點 com 在哪：就是 com. 172800 IN NS [a-m].gtld-servers.net。

ok，頂級域以後就是咱們熟知的一級域名，譬如 www.example.com 中的 example 就是一級域 。有興趣的能夠本身試着用 dig 指令再追蹤一下：dig example.com. +trace ，能夠看到是從根節點從右向左逐步查找的。

 

  NS 爲什麼

上面兩張 dig 命令貼圖中間出現了不少次 NS ，NS 便是 NameServer，大部分狀況下又叫權威名稱服務器簡稱權威。
什麼是權威呢，通俗點講實際上是某些域的權威，也就是權威上面有這些域的最新，最全的數據，全部這些域的數據都應該以此爲準（只有權威能夠增刪改這些域的數據），就像上面  dig com +trace 的結果能夠看到，com 的權威是上面的 13 個根域。同理，全部的頂級域（cn、org、net 等等）的權威都是根域。

 

  DNS 解析

其實上面就是 DNS 解析的一個大體過程，即迭代解析，可是不是很詳盡，一個完整的 DNS 解析過程以下：（下面一段摘自這裏： 域名收斂--前端優化）
）

Step1: 首先拿到 URL 後，瀏覽器會尋找本地的 DNS 緩存，看看是否有對應的 IP 地址，若是緩存中存在那就行了，若是沒有，那就得向 DNS Server 發送一個請求，找到你想要的 IP 地址。

Step2: 首先他會向你的 ISP(互聯網服務提供商) 相關的 DNS servers 發送 DNS query。而後這些 DNS 進行遞歸查詢(recursive)。所謂的遞歸查詢，就是可以直接返回對應的IP地址，而不是其餘的 DNS server 地址。

Step3: 若是上述的 DNS Servers 沒有你要的域名地址，則就會發送迭代查詢，即會先從 root nameservers 找起。 便是假如你要查詢 www.example.com ，會先從包含根結點的 13 臺最高級域名服務器開始。

Step4: 接着，以從右向左的方式遞進，找到 com.  而後向包含 com 的 TLD(頂級域名) nameservers 發送 DNS 請求。接着找到包含 example 的 DNS server。

Step5: 如今進入到了example.com 部分，便是如今正在詢問的是權威服務器，該服務器裏面包含了你想要的域名信息，也就是拿到了最後的結果 record 。

Step6: 遞歸查詢的 DNS Server 接受到這 record 以後, 會將該record 保存一份到本地。 若是下一次你再請求這個 domain 時，我就能夠直接返回給你了。因爲每條記錄都會存在 TLL ，因此 server 每隔一段時間都會發送一次請求，獲取新的 record，

Step7: 最後，再經由最近的 DNS Server 將該條 record 返回。 一樣，你的設備也會存一份該 record 的副本。 以後，就是 TCP 的事了，下面是一張萌萌的簡化圖：

到這裏，咱們大體就能夠梳理一下，迭代查詢的過程以下：

流程: . => com. => .exampl.com. => www.example.com. => IP adress

 

  TTL 爲什麼

TTL 是 Time To Live 的縮寫，該字段指定 IP 包被路由器丟棄以前容許經過的最大網段數量。TTL 是 IPv4 包頭的一個 8 bit 字段。

簡單的說它表示 DNS 記錄在 DNS 服務器上緩存時間。

 

扯了這麼多 http 請求， DNS 解析，回到正題域名收斂上，從上面能夠看到，DNS 解析實際上是一個很複雜的過程，在 PC 上，咱們採用域名發散策略，是由於在 PC 端上，DNS 解析一般而言只須要幾十 ms ，能夠接受。而移動端，2G 網絡，3G網絡，4G網絡/wifi 強網，並且移動 4G 容易在信號不理想的地段降級成 2G ，經過大量的數據採集和真實網絡抓包分析（存在DNS解析的請求），DNS的消耗至關可觀，2G網絡大量5-10s，3G網絡平均也要3-5s（數據來源於淘寶）。 下面附上在 2G，3G，4G， WIFI 狀況下 DNS 遞歸解析的時間 （ms）：

由於在增長域的同時，每每會給瀏覽器帶來 DNS 解析的開銷。因此在這種狀況下，提出了域名收斂，減小域名數量能夠下降 DNS 解析的成本。

下圖是手機端頁面加載數和域名分散數的關係（from Mobify Developer）:

在 2 個域名分散條件下，網頁的加載速度提高較大，而第 3 個之後就比較慢了。 因此，通常來講，域名分散的數量最好在 3 如下。

 

 

  SPDY 

原本至此，本文應該結束了，談了下域名發散與域名收斂。

可是，單純的在移動端採用域名收斂並不能很大幅度的提高性能，很重要的一點是，在移動端建連的消耗很是大，而 SPDY 協議能夠完成多路複用的加密全雙工通道，顯著提高非wifi環境下的網絡體驗。

俗話說，好刀配好鞘，好馬配好鞍，當域名收斂配合 SPDY 才能最大程度發揮他們的效用，達到事半功倍。

 

那麼什麼是 SPDY？

SPDY，一種 開放的網絡傳輸協議，由Google開發，用來發送網頁內容。基於傳輸控制協議（TCP）的應用層協議 ，是 HTTP/2 的前身。

SPDY 的做用就是，在不增長域名的狀況下，解除最大鏈接數的限制。主要的特色就是多路複用，他的目的就是致力於取消併發鏈接上限。

那麼相比 http， SPDY 具體的優點在哪裏呢：

1. 多路複用 請求優化

SPDY 規定在一個 SPDY 鏈接內能夠有無限個並行請求，即容許多個併發 HTTP 請求共用一個 TCP會話。這樣 SPDY 經過複用在單個 TCP 鏈接上的屢次請求，而非爲每一個請求單獨開放鏈接，這樣只需創建一個 TCP 鏈接就能夠傳送網頁上全部資源，不只能夠減小消息交互往返的時間還能夠避免建立新鏈接形成的延遲，使得 TCP 的效率更高。

此外，SPDY 的多路複用能夠設置優先級，而不像傳統 HTTP 那樣嚴格按照先入先出一個一個處理請求，它會選擇性的先傳輸 CSS 這樣更重要的資源，而後再傳輸網站圖標之類不過重要的資源，能夠避免讓非關鍵資源佔用網絡通道的問題，提高 TCP 的性能。

2. 支持服務器推送技術

服務器能夠主動向客戶端發起通訊向客戶端推送數據，這種預加載可使用戶一直保持一個快速的網絡。

3. SPDY 壓縮了 HTTP 頭

捨棄掉了沒必要要的頭信息，通過壓縮以後能夠節省多餘數據傳輸所帶來的等待時間和帶寬。

4. 強制使用 SSL 傳輸協議

Google 認爲 Web 將來的發展方向一定是安全的網絡鏈接，所有請求 SSL 加密後，信息傳輸更加安全。

看看 SPDY 的做用圖：

SPDY 協議在性能上對 HTTP 作了很大的優化，其核心思想是儘可能減小鏈接個數，而對於 HTTP 的語義並無作太大的修改。

具體來講是，SPDY 使用了 HTTP 的方法和頁眉，可是刪除了一些頭並重寫了 HTTP 中管理鏈接和數據轉移格式的部分，因此基本上是兼容 HTTP 的。

 

  SPDY 兼容性

• Google Chrome 和 Chromium 已經支持 SPDY。
• Mozilla Firefox 自11.0開始內嵌支持 SPDY 。從 Firefox 13 開始默認開啓對 SPDY 的支持。
• Opera 從12.10開始支持 SPDY。
• Internet Explorer 11 開始支持 SPDY。

從上面能夠看到，IE 從 IE11 開始才支持 SPDY，因此 SPDY 發展的路還很長，現階段運用在移動端較好。

寫到這裏，好想繼續往下寫 HTTP/2 ，由於 HTTP/2 的前身便是 SPDY 協議，可是感受本文的內容已經很充實了，內容也不少，就再也不繼續往下，內容不少，但願有人可以耐心讀完，對一些網絡基礎知識很好的鞏固效果。