通過HTTP Header控制快取

　　我們經常通過快取技術來加快網站的訪問速度，從而提升使用者體驗。HTTP協議中也規定了一些和快取相關的Header，來允許瀏覽器或共享快取記憶體快取資源。這些Header包括：

• Last-Modified 和 If-Modified-Since
• ETag 和 If-None-Match
• Expires
• Cache-Control

　　以上Header又可以分成兩種型別：

• 協商快取：瀏覽器傳送驗證到伺服器，由伺服器決定是否從快取中讀取，如 1 和 2 。
• 強快取：瀏覽器驗證快取的有效性，然後決定是否從快取中讀取資料，如 3 和 4 。

　　本文將會分別介紹這四種配置的作用以及可能產生的影響。

　　1、Last-Modified 和 If-Modified-Since

　　Last-Modified：伺服器在響應請求時，告知瀏覽器資源的最後修改時間。

　　If-Modified-Since：瀏覽器再次傳送請求時，會通過此Header通知伺服器在上次請求時所得到的資源最後修改時間。伺服器會將If-Modified-Since與被請求資源的最後修改時間進行比對。若資源的最後修改時間晚於If-Modified-Since，表示資源已被改動，則響最新的資源，返回200狀態碼；若資源的最後修改時間早於或等於If-Modified-Since，表示瀏覽器端的資源已經是最新版本，響應304狀態碼，通知瀏覽器繼續使用快取中的資源。

　　2、ETag 和 If-None-Match

　　ETag：伺服器分配給資源的唯一識別符號，資源被修改後，ETag也會隨之發生變化。

　　If-None-Match：瀏覽器再次傳送請求時，會通過此Header通知伺服器已快取資源的ETag。伺服器會將If-None-Match與被請求資源的最新ETag進行比對。若不相同，表示資源已被改動，則響應最新的資源，返回200狀態碼；若值相同，則直接響應304狀態碼，通知瀏覽器繼續使用快取中的資源。

　　3、Expires

　　伺服器可以通過此Header向瀏覽器傳遞一個具體的時間（格林威治格式，例如：Thu, 19 Jul 2018 07:43:05 GMT） ，來明確地宣告資源的有效期。在資源過期之前，瀏覽器不再傳送請求，而是直接從快取中讀取資料。只有當資源過期之後，瀏覽器才會再次向伺服器請求該資源。

　　4、Cache-Control

　　伺服器使用此Header來向客戶端建議快取策略，它有一下幾個可選值：

　　max-age=秒：告知瀏覽器快取的有效時長，在該時間內瀏覽器將直接從快取中讀取資料。

　　s-maxage=秒：作用同max-age，但是隻對共享快取記憶體（如CDN）有效，對瀏覽器無效。

　　no-cache：告知瀏覽器不要直接使用快取，而是必須向伺服器傳送請求。

　　no-store：告知瀏覽器不要快取本次請求和響應的任何資訊。

　　public：宣告任何快取媒介都可以快取該響應。

　　private：宣告該響應只允許個體客戶端（如瀏覽器）去快取，而不允許共享快取記憶體（如CDN）去快取。

　　在上面的介紹中我們瞭解到瀏覽器會根據max-age設定的時間進行快取。而通過研究發現CDN也會識別源站響應頭中Cache-Control屬性，根據max-age設定的時間進行快取，但是，如果源站同時設定了s-maxage和max-age，那麼CDN會優先採用s-maxage。

　　下面通過圖例來展示一下這些可選值的效果。

　　首先了解一下瀏覽器是怎樣根據max-age進行快取的：

　　從上圖不難發現，伺服器在Header中返回了Cache-Control: max-age=100後，瀏覽器成功快取100秒，該時間段內的請求都從直接以本地快取來響應。

　　那麼，伺服器在Header中返回Cache-Control:s-maxage=100時，又會對瀏覽器產生什麼樣的影響呢？

　　如上圖所示，瀏覽器沒有采取任何快取策略，這是因為s-maxage面向的是共享高速緩。

　　上面這兩個例子很容易理解，在現實世界中，為了加快網站響應速度，我們可能會在瀏覽器和伺服器之間引入CDN服務。瀏覽器的請求會先到達CDN，然後CDN判斷是從快取中讀取資料還是回源到伺服器。接下來，讓我們看看max-age和s-maxage會對CDN的快取策略帶來哪些影響。

　　可以看出CDN也會利用max-age來快取，所以在100秒內強制重新整理瀏覽器時，CDN會直接用快取來響應。

　　如果伺服器使用了s-maxage又會如何呢？

　　不難發現CDN對max-age和s-maxage採取了同樣的快取策略，但瀏覽器並不會根據s-maxage來進行快取。

　　CDN供應商的特殊規則

　　我們分別測試了阿里雲和騰訊雲的CDN對Cache-Control的支援情況，發現他們都有一些獨特的規則。

　　阿里雲CDN可以在控制檯裡設定Cache-Control，該設定會覆蓋源伺服器的Cache-Control。

　　騰訊雲CDN雖然沒有再控制檯提供覆蓋Cache-Control的功能，但其規則卻一點也不簡單，在使用的時候一定要特別注意：

• 伺服器和CDN均不對快取進行配置時，CDN會採用預設的快取機制（靜態檔案快取30天，動態請求不快取）；
• CDN配置快取機制（但並未開啟高階快取配置）且伺服器設定Cache-Control: s-maxage=200,max-age=100時，CDN會按照其控制檯設定的規則進行快取，瀏覽器則按照max-age進行快取；
• 伺服器不設定Cache-Control時，CDN會自動在響應的Header中新增Cache-Control: max-age=600，這就會讓瀏覽器將該資源快取600秒；
• 伺服器設定為禁用快取時，CDN和瀏覽器均不進行快取；
• 伺服器設定Cache-Control: s-maxage=200,max-age=100並開啟CDN的高階快取配置時，CDN會從s-maxage和控制檯中設定的快取時間中選擇最小值來作為快取時間，而瀏覽器則始終使用max-age；
• 伺服器設定Cache-Control:max-age=100並開啟CDN的高階快取配置時，CDN會從max-age和控制檯中設定的快取時間中選擇最小值來作為快取時間，不影響瀏覽器的快取策略。

　　組合使用

　　如果同時設定了這些Header，瀏覽器和高速共享快取會按照下面的優先順序進行快取：

　　Cache-Control > Expires > ETag > Last-Modified

　　也就是說，Cache-Control不僅是強快取，而且擁有最高的優先順序，我們可以為不經常發生變化的資源應用該Header來提升響應時間。

　　在Ada中使用快取

　　Ada提供了UI腳手架和API腳手架，這兩類腳手架的伺服器端入口檔案分別為index.server.js和index.js，我們只需要在入口檔案的請求處理函式中為響應新增適當的Header，即可通知客戶端進行響應的快取，比如：

　　// 設定CDN快取300秒，瀏覽器快取200秒

　　ctx.response.headers.set('Cache-Control', public,s-maxage=300,max-age=200)

　　在為請求新增快取Header之前，應該先為其制定適當的快取策略，需要考慮該URL是否適合快取（資料是否特定於使用者）以及需要快取的時長等等。

　　總結

　　通過使用這些HTTP Header，我們可以主動影響瀏覽器甚至CDN的快取策略，從而減少請求數量，提升網頁效能，減輕伺服器壓力。

　　Ada的靈活機制能讓我們為不同的URL設定不同的快取策略，能夠更有針對性地進行主動快取。