瀏覽器緩存原理以及本地存儲

說白了就是利用本地存儲，把一部分數據保存在客戶端，減小對服務器的請求，下降服務器壓力，提高網頁加載速度，

做爲一名前端工做人員，前端的緩存知識是必須掌握的，由於一個網站打開網頁的速度直接關係到用戶體驗，用戶粘度，而提升網頁的打開速度有不少方面須要優化，其中比較重要的一點就是利用好緩存，緩存文件能夠重複利用，還能夠減小帶寬，下降網絡負荷。

1 緩存

緩存從宏觀上分爲私有緩存和共享緩存，共享緩存就是那些能被各級代理緩存的緩存。私有緩存就是用戶專享的，各級代理不能緩存的緩存

緩存從微觀上能夠分爲如下幾類：

• 瀏覽器緩存
• 代理服務器緩存
• CDN緩存
• 數據庫緩存
• 應用層緩存

這裏主要對瀏覽器的緩存進行說明：

 

2 http緩存

2.1 強緩存

• 不會向服務器發送請求，直接從緩存中讀取資源
• 請求返回200的狀態碼
• 在chrome控制檯的network選項中能夠看到size顯示from disk cache或from memory cache。

from memory cache表明使用內存中的緩存，from disk cache則表明使用的是硬盤中的緩存，瀏覽器讀取緩存的順序爲memory –> disk。在瀏覽器中，瀏覽器會在js和圖片等文件解析執行後直接存入內存緩存中，那麼當刷新頁面時只需直接從內存緩存中讀取(from memory cache)；而css文件則會存入硬盤文件中，因此每次渲染頁面都須要從硬盤讀取緩存(from disk cache)。

 

Expires和Cache-Control二者對比：其實這二者差異不大，區別就在於 Expires 是http1.0的產物，Cache-Control是http1.1的產物，二者同時存在的話，Cache-Control優先級高於Expires

 

2.2 協商緩存

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程

2.2.1 Last-Modified和If-Modified-Since

瀏覽器在第一次訪問資源時，服務器返回資源的同時，在response header中添加 Last-Modified的header，值是這個資源在服務器上的最後修改時間，瀏覽器接收後緩存文件和header；

瀏覽器下一次請求這個資源，瀏覽器檢測到有 Last-Modified這個header，因而添加If-Modified-Since這個header，值就是Last-Modified中的值；服務器再次收到這個資源請求，會根據 If-Modified-Since 中的值與服務器中這個資源的最後修改時間對比，若是沒有變化，返回304和空的響應體，直接從緩存讀取，若是If-Modified-Since的時間小於服務器中這個資源的最後修改時間，說明文件有更新，因而返回新的資源文件和200

 

缺點：一、某些服務端不能獲取精確的修改時間 二、文件修改時間改了，但文件內容卻沒有變

 

2.2.2 ETag和If-None-Match

Etag是上一次加載資源時，服務器返回的response header，是對該資源的一種惟一標識，只要資源有變化，Etag就會從新生成。瀏覽器在下一次加載資源向服務器發送請求時，會將上一次返回的Etag值放到request header裏的If-None-Match裏，服務器只須要比較客戶端傳來的If-None-Match跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端；若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

     

2.2.3 協商緩存兩種方式的對比

1. 首先在精確度上，Etag要優於Last-Modified，Last-Modified的時間單位是秒，若是某個文件在1秒內改變了屢次，那麼他們的Last-Modified其實並無體現出來修改，可是Etag每次都會改變確保了精度；若是是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。
2. 性能上，Etag要遜於Last-Modified，畢竟Last-Modified只須要記錄時間，而Etag須要服務器經過算法來計算出一個hash值。
3. 優先級上，服務器校驗優先考慮Etag

3 緩存機制

appcache優先於強緩存，強制緩存優先於協商緩存進行，若強制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進行協商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協商緩存由服務器決定是否使用緩存，若協商緩存失效，那麼表明該請求的緩存失效，返回200，從新返回資源和緩存標識，再存入瀏覽器緩存中；生效則返回304，繼續使用緩存。具體流程看下圖：

無論是瀏覽器緩存，仍是代理服務器緩存，CDN緩存都遵循客戶端與服務端之間的緩存機制

四、本地存儲

本地存儲主要有如下幾種，localStorage，sessionStorage和cookie，WebSql和IndexDB主要用在前端有大容量存儲需求的頁面上，例如，在線編輯瀏覽器或者網頁郵箱。他們均可以將數據存儲在瀏覽器，應該根據不一樣的場景進行使用。

4.1 Cookie

Cookie主要是由服務器生成，且前端也能夠設置，保存在客戶端本地的一個文件，經過response響應頭的set-Cookie字段進行設置，且Cookie的內容自動在請求的時候被傳遞給服務器。在客戶端和服務器之間來回傳遞，耗性能，以下：

Cookie包含的信息：

它能夠記錄你的用戶ID、密碼、瀏覽過的網頁、停留的時間等信息。當你再次來到該網站時，網站經過讀取Cookies，得知你的相關信息，就能夠作出相應的動做，如在頁面顯示歡迎你的標語，或者讓你不用輸入ID、密碼就直接登陸等等。一個網站只能讀取它本身放置的信息，不能讀取其餘網站的Cookie文件。所以，Cookie文件還保存了host屬性，即網站的域名或ip。 

這些屬性以名值對的方式進行保存，爲了安全，它的內容大多進行了加密處理。Cookie文件的命名格式是：用戶名@網站地址[數字].txt

Cookie的優勢：

• 給用戶更人性化的使用體驗，如記住「密碼功能」、老用戶登陸歡迎語
• 彌補了HTTP無鏈接特性
• 站點統計訪問人數的一個依據

Cookie的缺點：

• 它沒法解決多人共用一臺電腦的問題，帶來了不安全因素
• Cookie文件容易被誤刪除
• 一人使用多臺電腦
• Cookies欺騙。修改host文件，能夠非法訪問目標站點的Cookie
• 容量有限制，不能超過4kb
• 在請求頭上帶着數據安全性差
•  

 

4.2 localStorage

localStorage主要是前端開發人員，在前端設置，一旦數據保存在本地後，就能夠避免再向服務器請求數據，所以減小沒必要要的數據請求，減小數據在瀏覽器和服務器間沒必要要地來回傳遞。

 

能夠長期存儲數據，沒有時間限制，一天，一年，兩年甚至更長，數據均可以使用。 

localStorage中通常瀏覽器支持的是5M大小，這個在不一樣的瀏覽器中localStorage會有所不一樣

優勢：

• localStorage拓展了cookie的4k限制
• localStorage能夠將第一次請求的5M大小數據直接存儲到本地，相比於cookie能夠節約帶寬
• localStorage的使用也是遵循同源策略的，因此不一樣的網站直接是不能共用相同的localStorage

缺點：

• 須要手動刪除，不然長期存在
• 瀏覽器大小不一，版本的支持也不同
• localStorage只支持string類型的存儲，JSON對象須要轉換
• localStorage本質上是對字符串的讀取，若是存儲內容多的話會消耗內存空間，會致使頁面變卡

4.3 sessionStorage

sessionStorage主要是前端開發人員，在前端設置，sessionStorage（會話存儲），只有在瀏覽器被關閉以前使用，建立另外一個頁面時同時可使用，關閉瀏覽器以後數據就會消失

存儲上限限制：不一樣的瀏覽器存儲的上限也不同，但大多數瀏覽器把上限限制在5MB如下

 

4.4 websql

Web SQL 是在瀏覽器上模擬數據庫，可使用JS來操做SQL完成對數據的讀寫。它使用 SQL 來操縱客戶端數據庫的 API，這些 API 是異步的，規範中使用的方言是SQLlite。數據庫仍是在服務端，不建議使用，已廢棄

4.5 indexDB

隨着瀏覽器的功能不斷加強，愈來愈多的網站開始考慮，將大量數據儲存在客戶端，這樣能夠減小從服務器獲取數據，直接從本地獲取數據。

現有的瀏覽器數據儲存方案，都不適合儲存大量數據：Cookie 的大小不超過4KB，且每次請求都會發送回服務器；LocalStorage 在 2.5MB 到 10MB 之間（各家瀏覽器不一樣），並且不提供搜索功能，不能創建自定義的索引。因此，須要一種新的解決方案，這就是 IndexedDB 誕生的背景。

通俗地說，IndexedDB 就是瀏覽器提供的本地數據庫，它能夠被網頁腳本建立和操做。IndexedDB 容許儲存大量數據，提供查找接口，還能創建索引。這些都是 LocalStorage 所不具有的。就數據庫類型而言，IndexedDB 不屬於關係型數據庫（不支持 SQL 查詢語句），更接近 NoSQL 數據庫。

 

5.CDN的定義

CDN：Content Delivery Network/Content Ddistribute Network，即內容分發網絡

客戶端訪問網站的過程：

沒有CDN：

一、用戶在瀏覽器訪問欄中輸入要訪問的域名；

二、瀏覽器向DNS服務器請求對該域名的解析；

三、DNS服務器返回該域名的IP地址給瀏覽器

四、瀏覽器使用該IP地址向服務器請求內容。

五、服務器將用戶請求的內容返回給瀏覽器。

使用了CDN：

一、用戶在瀏覽器中輸入要訪問的域名。

二、瀏覽器向DNS服務器請求對域名進行解析。因爲CDN對域名解析進行了調整，DNS服務器會最終將域名的解析權交給CNAME指向的CDN專用DNS服務器。

三、CDN的DNS服務器將CDN的負載均衡設備IP地址返回給用戶。

四、用戶向CDN的負載均衡設備發起內容URL訪問請求。

五、CDN負載均衡設備會爲用戶選擇一臺合適的緩存服務器提供服務。

選擇的依據包括：根據用戶IP地址，判斷哪一臺服務器距離用戶最近；根據用戶所請求的URL中攜帶的內容名稱，判斷哪一臺服務器上有用戶所需內容；查詢各個服務器的負載狀況，判斷哪一臺服務器的負載較小。

基於以上這些依據的綜合分析以後，負載均衡設置會把緩存服務器的IP地址返回給用戶。

六、用戶向緩存服務器發出請求。

七、緩存服務器響應用戶請求，將用戶所需內容傳送到用戶。

若是這臺緩存服務器上並無用戶想要的內容，而負載均衡設備依然將它分配給了用戶，那麼這臺服務器就要向它的上一級緩存服務器請求內容，直至追溯到網站的源服務器將內容拉取到本地。

 

2、關於緩存

沒有CDN：瀏覽器緩存

使用了CDN：瀏覽器緩存+CDN緩存

在用戶第一次訪問網站後，網站的一些靜態資源如圖片等就會被下載到本地，做爲緩存，當用戶第二次訪問該網站的時候，瀏覽器就會從緩存中加載資源，不用向服務器請求資源，從而提升了網站的訪問速度，而若使用了CDN，當瀏覽器本地緩存的資源過時以後，瀏覽器不是直接向源站點請求資源，而是向CDN邊緣節點請求資源，CDN邊緣節點中也存在緩存，若CDN中的緩存也過時，那就由CDN邊緣節點向源站點發出回源請求來獲取最新資源。

 

瀏覽器緩存以及CDN緩存都有一套判斷文件是否須要更新的機制：

瀏覽器在加載資源時，先根據這個資源的一些http header判斷它是否命中強緩存，若是命中，瀏覽器直接從本身的緩存中讀取資源，不會發請求到服務器，當強緩存沒有命中的時候，瀏覽器必定會發送一個請求到服務器，服務器端依據資源的另一些http header驗證這個資源是否命中協商緩存，若是命中，服務器會將這個請求返回，可是不會返回這個資源的數據，而是告訴客戶端能夠直接從緩存中加載這個資源，因而瀏覽器仍是從本身的緩存中加載資源，當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。

CDN節點緩存機制在不一樣服務商中是不一樣的，但通常都遵循HTTP協議，經過http響應頭中的Cache-Control:max-age的字段來設置CDN節點文件緩存時間。當客戶端向CDN節點請求數據時，CDN會判斷緩存數據是否過時，若沒有過時，則直接將緩存數據返回給客戶端，不然就向源站點發出請求，從源站點拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。CDN服務商通常會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，爲用戶提供更精細化的緩存管理。CDN緩存時間會對「回源率」產生直接的影響，若CDN緩存時間短，則數據常常失效，致使頻繁回源，增長了源站的負載，同時也增大了訪問延時；若緩存時間長，數據更新時間慢，所以須要針對不一樣的業務需求來選擇特定的數據緩存管理。

瀏覽器緩存刷新：

一、在地址欄中輸入網址後按回車或者點擊轉到按鈕

瀏覽器以最少的請求來獲取網頁的數據，瀏覽器會對全部沒有過時的內容直接使用本地緩存即便用強緩存，從而減小了對服務器的請求，Expires、max-age標誌只對這種方式有效。

二、按F5或瀏覽器刷新按鈕

瀏覽器會在請求中附加必要的緩存協商，但不容許瀏覽器直接使用本地緩存即跳過強緩存的判斷，直接進行協商緩存的判斷，Last-Modified、ETag在這種方式發揮做用。

三、按Ctrl+F5或按Ctrl並點擊刷新按鈕

強制刷新，徹底不使用緩存

CDN緩存刷新：

CDN節點對開發者時透明的，能夠經過CDN服務商提供的「刷新緩存」接口來達到清理CDN節點緩存的效果，強制使數據過時，從而獲取到最新的數據。

3、瀏覽器緩存

這一點主要解析瀏覽器緩存以及緩存機制的詳細過程。

1.1強緩存：

當瀏覽器對某個資源的請求命中了強緩存時，返回的http狀態碼爲200，在chrome開發者工具中的network中的size會顯示from cache

強緩存時利用Expires或者Cache-Control這兩個http header實現的，都用來表示資源在客戶端緩存的有效期

Expires是http1.0提出的一個header，描述的是一個絕對時間，由服務器返回，用GMT格式的字符串表示，如Exprires：Thu，31 Dec 2037 23：55：55 GMT

緩存過程：

一、瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Expires的header

二、瀏覽器在接收到這個資源後，會把這個資源連同全部的response header一塊兒緩存下來，因此緩存命中的請求返回的header並非來自服務器，而是來自以前緩存的header

三、瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源後，拿出Expires跟當前的請求時間比較，若是請求時間在Expires指定的時間以前，就能命中緩存，不然就不行。

四、若是緩存沒有命中，瀏覽器直接從服務器加載資源時，Expires Header在從新加載的時候會被更新

Expires是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，好比隨意修改下客戶端時間，就能影響緩存命中的結果，因此在http1.1的時候，提出了一個新的header，也就是Cache-Control，這是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，所以更有效安全一些，在配置緩存的時候，以秒爲單位，用數值表示：如：Cache-Control：max-age=315360000，它的緩存過程是：

一、瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上Cache-Control的header

二、瀏覽器在接收到這個資源的時候，會把這個資源連同全部response header一塊兒緩存下來

三、瀏覽器再次請求這個資源的時候，先從緩存中尋找，找到這個資源以後，再拿這個過時時間跟當前的請求時間比較，若是請求時間在過時時間以前，就能命中緩存，不然就不行。

四、若是緩存沒有命中，瀏覽器直接從服務器加載資源時，Cache-Control在從新加載的時候會被更新

這兩個header能夠只用一個，也能夠同時用兩個，同時存在時，Cache-Control優先級高於Expires

1.2 強緩存的管理

兩種方式來設置是否啓用強緩存：

一、經過代碼的方式，在web服務器返回的響應中添加Expires和Cache-Control Header

二、經過配置web服務器的方式，讓web服務器在響應資源的時候統一添加Expires和Cache-Control Header

1.3 強緩存的應用

強緩存是前端性能優化最有力的工具，對於有大量靜態資源的網頁，必定要利用強緩存，提升響應速度，一般是爲這些靜態資源所有配置一個超時時間超長的Expires或Cache-Control，這樣用戶只會在第一次訪問網站時加載靜態資源，其餘時間只要緩存沒有失效而且用戶沒有強制刷新的條件下都會從緩存中加載。

然而這種緩存配置方式會帶來一個問題，就是當資源更新時，客戶端因爲有緩存不會向服務器請求最新的資源，這個問題已有解決方案：

經過更新頁面中引用的資源路徑，讓瀏覽器主動放棄緩存，加載新資源。

但要實現有更新的文件才須要瀏覽器從新加載，所以必須讓url的修改與文件內容相關聯，利用數據摘要算法對文件求摘要信息，摘要信息與文件內容一一對應，這一點許多前端構建工具都作到了，如webpack

1.4 瀏覽器默認緩存使開發環境下常由於資源沒有及時更新而看不到效果

解決方法：

一、ctrl+F5

二、瀏覽器隱私模式開發

三、chrome開發者工具裏將Disable cache選項打勾，阻止緩存

四、在開發階段，給資源加上一個動態的參數，因爲每次資源的修改都要更新引用的位置，同時修改參數的值，因此操做起來不是很方便，除非是在動態頁面好比jsp裏開發就能夠用服務器變量來解決，或者用前端構建工具來處理這個參數修改的問題。

五、若是資源引用的頁面被嵌入到了一個iframe裏面，能夠在iframe的區域右鍵從新加載該頁面

六、若是緩存問題出如今ajax請求中，最有效的解決辦法就是ajax的請求地址追加隨機數

七、動態設置iframe的src時，有可能由於緩存問題致使看不到最新效果，在src後面添加隨機數便可

八、經過前端開發工具grunt gulp等的插件來啓動一個靜態服務器，則在這個服務器下全部資源返回的response header中，Cache-Control始終被設置爲不緩存

1.5 發佈問題

發佈問題：若頁面和它引用的資源路徑同時更新了，無論是先部署頁面仍是先部署資源都會帶來各類問題，這是因爲資源是覆蓋式發佈的，即用待發布資源覆蓋已發佈資源。

解決辦法就是實現非覆蓋式發佈：把有修改的資源文件做爲一個新的文件發佈，不對已有的資源文件進行覆蓋，這樣用戶還能夠請求舊的資源文件，不至於發生頁面錯亂的問題，這樣先部署靜態資源，再覆蓋式部署頁面，等到用戶訪問新頁面的時候，新的資源文件也已發佈，就能夠正確請求，便可解決問題。

2.1 協商緩存

若是命中協商緩存，請求響應返回的http狀態爲304以及一個Not Modified字符串，協商緩存利用的是【Last-Modified、If-Modified-Since】、【ETag、If-None-Match】這兩對header來管理的。

【Last-Modified、If-Modified-Since】：

一、瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源時，在response的header加上Last-Modified的header，表示這個資源在服務器上的最後修改時間

二、瀏覽器再次向服務器請求這個資源時，在request的header加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值

三、服務器再次收到資源請求時，根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最後修改時間判斷資源是否有變化，若是沒有變化則返回304 Not Modified，可是不會返回資源內容，若是有變化就返回資源內容，當服務器返回304 Not Modified的響應時，response header中不會再添加Last-Modified的header，由於資源沒有變化，Last-Modified的值也不變

四、瀏覽器收到304的響應後，就會從緩存中加載資源

五、若是協商緩存沒有命中，瀏覽器直接從服務器加載資源時，Last-Modofied header在從新加載的時候會被更新，下次請求時，If-Modified-Since會採用上一次返回的Last-Modified的值

這一對header都是根據服務器時間返回的，有時候會有服務器資源有變化，但最後修改時間卻沒有變化的狀況，所以有了

【Etag、If-None-Match】：

一、瀏覽器第一次向服務器請求一個資源，服務器在返回這個資源的同時，在response的header加上ETag的header，這個header是服務器根據當前請求的資源生成的一個惟一標識，是一個字符串，只要資源內容發生改變，這個字符串也會改變，跟時間沒有關係

二、瀏覽器再次請求這個資源的時候，在request的header上加上If-None-Match的header。這個header的值是上一次請求返回的ETag的值

三、服務器再次收到資源請求時，根據客戶端傳過來的If-None-Match和從新生成的該資源的新的ETag作比較，相同則返回304 Not Modified，不會返回資源內容，若是不一樣則返回資源內容，但這裏即便資源沒有發生變化，也會返回ETag，由於這個ETag從新生成過，即便沒有ETag沒有變化

四、瀏覽器收到304響應後，就從緩存中加載資源

2.2 協商緩存的管理

通常服務器上的【Last-Modified、If-Modified-Since】和【Etag、If-None-Match】會同時啓用，協商緩存須要配合強緩存使用

 

 

 

什麼是DNS？

Domain Name System，域名系統做用是將用戶輸入的域名解析爲IP地址所對應得網站資源，使得用戶能夠訪問到網站。 它是由解析器和域名服務器組成的。域名服務器是指保存有該網絡中全部主機的域名和對應IP地址，並具備將域名轉換爲IP地址功能的服務器。其中域名必須對應一個IP地址，而IP地址不必定有域名。

 DNS本質是用於TCP/IP應用程序的數據庫，該數據庫中記錄了域名和IP的對應關係。  DNS相似 「翻譯官」

DNS就是把域名和IP地址聯繫在一塊兒的服務，有了DNS服務器，你就不用輸入IP地址來訪問一個網站，能夠經過輸入網址訪問。

DNS 是域名系統 (Domain Name System) 的縮寫，是因特網的一項核心服務，它做爲能夠將域名和IP地址相互映射的一個分佈式數據庫，可以令人更方便的訪問互聯網，而不用去記住可以被機器直接讀取的IP數串。這也是DNS的官方說法。

DNS的做用：在互聯網中，其實沒有相似於 www.xxx.com這種域名方式，而替代的是以IP地址，如222.222.222.222，那咱們在IE地址欄中應當輸入222.222.222.222才能打開網站 www.xxx.com。

但咱們細想一下，互聯網上的網站成千上萬，若是每一個網站登錄都須要記住一大串數字，那是否是特別不方便，對於記憶力不強的人，根本沒法記住這麼煩瑣的數字。這個時候DNS就出現了，它的做用就是將222.222.222.222解析爲 www.xxx.com，那麼咱們登錄的時候就直接輸入域名就能夠了。  每一個ip對應的就是資源所在的位置

二：DNS重要知識點

 

        首先了解域名的組成，域名由好幾部分組成，首先是根 . 根是一個點，寫在com等頂級域名後邊，如今通常省略。

 

        域名構成以下：

 

        一級域名：.com  .org  .cn  .edu等。頂級域名通常有含義，如學校、國家、政府機構等。

 

        二級域名：baidu  qq  csdn等。通常能夠本身進行申請。

 

        三級域名：可行定製。如www  blog等。

 

        例子： www.alita99.com解析：1、前邊DNS服務器均沒有該域名信息，會來到根服務器，根服務器發現你一級域名是com，就會給一個專門解析com的DNS服務器地址，而後來到該DNS服務器，而後該服務器就會給你 alita99.com對應的域的ip地址，你電腦拿到ip地址去訪問該域名下的www這臺主機（可能配置有其餘三級域名主機，www只是一個經常使用的）。2、DNS服務器通常會先到緩存中去查詢域名，若緩存中沒有才會去上一級DNS服務器請求，且拿到新的域名ip後會保存在緩存中，在必定時間內其餘主機訪問該域名能夠快速給出ip地址。

 

域名解析完整過程：

 

        1：用戶向localDNS發起請求查詢輸入域名對應的IP地址（如有緩存直接返回，不然去rootDNS查詢）；

        2：localDNS迭代向rootDNS查詢，逐級迭代,rootDNS=>頂級DNS=>次級DNS；

        3：得到次級DNS後，localDNS向次級DNS發起域名解析請求；

        4：次級DNS一般會將域名CNAME【若是有有CNAME則解析CNAME對應的CDN服務，不然的話默認爲普通請求，直接返回解析到的IP】到另外一個域名，這個域名最終會被指向CDN網絡中的智能DNS負載均衡系統；

        5：DNS負載均衡系統經過一些智能算法，將最合適的CDN節點IP地址返回給localDNS；

        6：localDNS將得到的IP地址返回給用戶；

        7：用戶獲得節點的IP地址後，向該節點發起訪問請求；

        8：CDN節點返回請求文件，若是該節點中請求的文件不存在，就會再回到源站獲取這個文件，而後返回給用戶。

 

   DNS查詢方式

 

        DNS查詢方式主要有迭代和遞歸，遞歸是主機等待，其餘DNS服務器進行詢問。迭代是DNS每次將結果給主機，讓主機本身起詢問下一級DNS服務器。主要有幾個區分方式：

 

        1.遞歸就是：問問問問問----答答答答答       迭代就是：問答問答問答問答問答

 

        2.遞歸是問的人一直在變化，迭代就是問的人不變。