程序員關於CDN相關事項你瞭解多少？（下篇）

做者：老顧

轉載請聲明出處！

前言

上一篇老顧介紹了CDN相關的知識，最後留了一下問題，就是緩存控制，今天老顧介紹一下如何控制緩存？

Cache Control響應頭

首先咱們先來看一下Cache Control這個概念，咱們先看一下訪問一個網站，觀察一下響應頭部

咱們發現cache-control的值爲max-age=31536000，從字面上面就可以猜出它的含義，就是服務端告訴客戶端此信息可不能夠緩存，以什麼樣的策略進行緩存；cache-control有哪些類型的值呢？

一、private：客戶端能夠緩存

二、public：客戶端和代理服務器能夠緩存

小夥伴們會疑惑什麼是代理服務器能夠緩存？咱們用戶電腦訪問web站點之間，頗有可能會通過相似nginx的反向代理服務器，也有可能會通過咱們正向代理的服務器，也有可能會通過CDN網絡；

所以咱們中間層的服務節點，發現cache-control的值爲private時，就承認只有發起請求的客戶端可以緩存，做爲代理服務節點是不可以緩存的。如爲public時，代理服務器也能夠緩存。

三、max-age：緩存的內容將在xxx秒後失效

這個意思就是在客戶端收到信息後，信息會緩存xxx秒；過了xxx秒客戶端必須從新獲取信息。

四、no-store：不緩存請求的任何返回內容

不緩存請求返回的任何內容

五、no-cache：強制向服務器端再驗證一次

no-cache和no-store的區別就是，no-cache會緩存請求返回的內容，而no-store不緩存；但no-cache時，在下次用緩存的內容時，須要向服務器驗證一下，緩存到底能不能用。

邏輯流程圖

流程圖中，服務根據自身的業務，設置cache-control的值爲：no-store、no-cache等，如：

Cache-Control: public, max-age=86400

在邏輯流程圖中，有一個環節就是從新驗證，就是驗證緩存內容是否有效，那驗證邏輯是什麼，怎麼驗證？

ETag驗證

ETag：資源惟一標識

通常會把請求的內容作md5加密，返回惟一的標識；會把ETag的值一塊兒返回給瀏覽器；瀏覽器會把ETag存儲下來。

Etag: "5d8c72a5edda83343d6aere"

下一次請求時將Etag一併帶過去給服務器，服務器只須要比較客戶端傳來的ETag跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。

若是服務器發現ETag匹配不上，那麼直接以常規GET 200狀態碼形式將新的資源（固然也包括了新的ETag）發給客戶端；若是ETag是一致的，則直接返回304狀態碼客戶端直接使用本地緩存便可。

那麼客戶端是**如何把標記在資源上的ETag傳回給服務器的呢？**請求報文中有兩個首部字段能夠帶上ETag值：

一、If-None-Match: ETag-value

If-None-Match: "5d8c72a5edda83343d6aere" 告訴服務端若是ETag沒匹配上須要重發資源數據，不然直接回送304和響應報頭便可。

當前各瀏覽器均是使用的該請求首部來向服務器傳遞保存的ETag值。

二、If-Match: ETag-value

告訴服務器若是沒有匹配到ETag，或者收到了「*」值而當前並無該資源實體，則應當返回412(Precondition Failed) 狀態碼給客戶端。不然服務器直接忽略該字段。

須要注意的是，若是資源是走分佈式服務器（好比CDN）存儲的狀況，須要這些服務器上計算ETag惟一值的算法保持一致，纔不會致使明明同一個文件，在服務器A和服務器B上生成的ETag卻不同。

ETag優勢：

一、能夠更加精確的判斷資源是否被修改，能夠識別一秒內屢次修改的狀況。

二、不存在版本問題，每次請求都回去服務器進行校驗。

缺點：

一、計算ETag值須要性能損耗。

二、分佈式服務器存儲的狀況下，計算ETag的算法若是不同，會致使瀏覽器從一臺服務器上得到頁面內容後到另一臺服務器上進行驗證時發現ETag不匹配的狀況。

Last-Modified驗證

服務器將資源傳遞給客戶端時，會將資源最後更改的時間以「Last-Modified: GMT」的形式加在實體首部上一塊兒返回給客戶端。

Last-Modified: Sun, 28 Apr 2019 02:23:05 GMT

客戶端會爲資源標記上該信息，下次再次請求時，會把該信息附帶在請求頭中一併帶給服務器去作檢查，若傳遞的時間值與服務器上該資源最終修改時間是一致的，則說明該資源沒有被修改過，直接返回304狀態碼，內容爲空。

若是兩個時間不一致，則服務器會發回該資源並返回200狀態碼，和第一次請求時相似。這樣保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端可以獲得最新的資源。

也相似ETag，客戶端請求報文頭，兩種參數

一、If-Modified-Since: Last-Modified-value

If-Modified-Since: Sun, 28 Apr 2019 02:23:05 GMT

該請求首部告訴服務器若是客戶端傳來的最後修改時間與服務器上的一致，則直接回送304 和響應報頭便可。

當前各瀏覽器均是使用的該請求參數來向服務器傳遞保存的 Last-Modified 值。

二、If-Unmodified-Since: Last-Modified-value

該值告訴服務器，若Last-Modified沒有匹配上（資源在服務端的最後更新時間改變了），則應當返回412(Precondition Failed) 狀態碼給客戶端。

Last-Modified 存在一個問題，若是在服務器上，一個資源被修改了，但其實際內容根本沒發生改變，但修改時間變化了，會致使Last-Modified時間匹配不上而返回了整個實體給客戶端（跟客戶端緩存裏有個如出一轍的資源）；就是錯誤的判斷內容改變了。

請求流程圖

上面的圖就是總結了一下以前所講的，比較容易理解，不理解回頭從新看。

瀏覽器刷新方式

一、在URI輸入欄中輸入而後回車

看cache-control對應的max-age是否有效，根據上面的流程圖，進入協商機制

二、F5/點擊工具欄中的刷新按鈕/右鍵菜單從新加載

去掉max-age或設置max-age=0，進入上面的流程圖，進入協商機制

三、Ctl+F5/commond+shift+R

去掉cache-control和協商頭，無論有沒有緩存，強制刷新，都要到Server服務器上面獲取數據，返回200狀態碼

協商機制再次說明：比較ETag和Last-Modified到服務端，若服務端一致，沒有變化，則返回狀態碼304，不返回數據；不然返回狀態碼200，返回數據。

動態數據

根據上面的知識，咱們去取動態數據時（如：ajax動態請求），服務端就能夠利用上面的規則控制客戶端不要緩存，設置cache-control爲max-age=0；且不設置**ETag和Last-Modified就能夠達到不緩存；反之若是要緩存數據，設置相關的值就好了 。

CDN自定義緩存策略

一、可自定義目錄的過時時間

無論源服務器的緩存過時是什麼規則，CDN服務自定義目錄過時時間，假如1個小時，那1個小時後，CDN設置的緩存目錄裏面的內容會過時，會再去源服務器那邊獲取新的信息（簡稱回源）。

二、可自定義後綴名過時時間

可根據後綴名設置緩存策略，如：html、js、css等

三、可自定義對應權重

如設置了後綴名的權重比目錄過時高，那麼就遵循後綴名過時規則

四、可經過界面或API強制CDN對應的目錄進行刷新（不必定會成功）

總結

如今的CDN產品已經比較成熟，有後臺控制檯管理進行緩存的配置，若是需要程序控制相關的緩存過時規則，能夠用上面介紹的知識點配合使用。今天老顧就介紹到這裏，謝謝！！！

你的贊和關注是我繼續創做的動力~