關於CDN與緩存（瀏覽器和CDN）

本文目錄：1、引入

　　　　　2、CDN定義

　　　　　3、關於緩存

　　　　　4、瀏覽器緩存

1、引入

客戶端直接從源站點獲取數據，當服務器訪問量大時會影響訪問速度，進而影響用戶體驗，且沒法保證客戶端與源站點間的距離足夠短，適合傳輸數據。

CDN解決的正是如何將數據快速可靠地從源站點傳遞到客戶端，經過CDN對數據的分發，用戶能夠從一個距離較近的服務器獲取數據，而不是源站點，從而達到快速訪問、且能減小源站點負載壓力的目的。

2、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地址返回給用戶。

 

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

 

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

 

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

3、關於緩存

沒有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節點緩存的效果，強制使數據過時，從而獲取到最新的數據。

4、瀏覽器緩存

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

第三點說到強緩存與協商緩存，下面從這兩點提及：

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】會同時啓用，協商緩存須要配合強緩存使用

 

 參考文章：

http://www.javashuo.com/article/p-tfhkkfir-ex.html

http://www.javashuo.com/article/p-sqrtakmh-gh.html

 

https://www.zhihu.com/question/20790576

http://www.cnblogs.com/lyzg/p/5125934.html