HTTP快取是怎樣的一種存在

原文：http://blog.poetries.top/2019/01/02/browser-cache/

情景再現

在某次介面測試中，發現這樣一種情況：

產品功能需求是這樣的：點選APP頁面上的某個按鈕，客戶端會向服務端傳送一個URL請求。

然而Charles抓包發現，第一次點選該按鈕時可以正常傳送請求，後來再多次點選時就不傳送該請求了。

What?。。。不科學呀!

原因排查

首先檢視了相關程式碼，的確是每次執行該點選操作都會傳送請求的，沒有任何問題。可是為什麼後來不再傳送請求了呢?

經過深入瞭解，原來是http快取導致的。

下面跟著小編學習一下http快取的相關知識，你就明白是怎麼回事了~

知識科普

1. http快取是怎樣的一種存在

1)什麼是快取

我們平時說的快取，通常指的是Web快取，它存在於伺服器和客戶端之間，是一種儲存資源副本並在下次請求時直接使用該副本的技術。當Web快取發現請求的資源已經被儲存，它會攔截請求，返回該資源的複製，而不會去源伺服器重新下載。

2)為什麼要使用快取技術

這是因為，通常情況下透過網路獲取內容速度慢成本高，有些響應需要在客戶端和伺服器之間進行多次往返通訊，這就拖延了瀏覽器可以使用和處理內容的時間，同時也增加了訪問者的資料成本。透過快取，使用資源副本，大大減少獲取資源時間，能夠減少網路頻寬消耗、減少延遲與網路阻塞，同時降低伺服器壓力，提高伺服器效能。

3)http快取又是怎麼回事呢

Web快取從實現方式大致可以分以下幾種型別：

資料庫資料快取;伺服器端快取(包括代理伺服器快取和CDN快取);

瀏覽器端快取;Web應用層快取。

http快取就是Web快取中的瀏覽器端快取中的基於http協議實現的那一種，也是平時最常見的一種快取。

2.http快取是如何工作的

在這一小節我們先了解下http請求資源快取的工作流程，然後對流程中細節進行解釋說明，你就會對http快取的工作原理有更深入的認識。

1)http請求資源的工作流程

第一次請求伺服器資源時，沒有快取檔案，直接向伺服器傳送請求。流程如下：

第一次請求流程圖

第二次及以後再請求伺服器資源時，本地已有快取，請求端會進行資源是否過期及更新等相關判斷，決定是否傳送請求，或傳送帶哪些條件式判斷欄位的請求，服務端視判斷結果決定返回的響應狀態及是否返回資源。具體流程如下：

非第一次請求流程圖

以上是http快取請求資源的工作流程圖，http快取是透過 HTTP 協議頭裡的Cache-Control(或 Expires)和 Last-Modified(或 Etag)等欄位來控制檔案快取的機制，下面對流程中的各個欄位及過程進行詳細說明：

1)控制快取的相關欄位

Pragma 設定頁面是否快取，為Pragma則快取，no-cache則不快取。它http1.0遺留的欄位，當它和cache-control同時存在的時候，會被cache-control覆蓋。

Expires 定義快取過期時間，這個時間相對伺服器上的時間而言的，它也是http1.0遺留的欄位。如Expires:Thu, 30 Aug 2018 08:14:36 GMT。

Cache-Control 也是定義快取過期時間，針對“Expires時間是相對伺服器而言，無法保證和客戶端時間統一”的問題而在http1.1協議中新增的，若報文中同時出現了Expires 和Cache-Control，則以Cache-Control 為準。Cache-Control欄位的指令說明如下：

no-cache特別注意，這個不是不被快取的意思!!是會被快取的，只不過每次在向客戶端提供響應資料時，快取都要向伺服器評估快取響應的有效性;

no-store響應不被快取;

max-age設定快取的存在時間，相對於傳送請求的時間，單位為s。在快取時間內，如果有請求這個資源，瀏覽器不會發出 http請求，而是直接使用本地快取的檔案。如Cache-Control: max-age=604800。

2)控制協商快取的欄位

Last-Modified/If-Modified-Since

Last-Modified 標示這個響應資源的最後修改時間，如Last-Modified:Tue, 20 Dec 2016 05:01:10 GMT;

If-Modified-Since 當帶著If-Modified-Since頭訪問伺服器請求資源時，伺服器會檢查Last-Modified，如果Last-Modified的時間早於或等於If-Modified-Since則會返回一個不帶主體的304響應，否則返回200並重新返回資源。

ETag/If-None-Match

ETag 是一個響應首部欄位，它是根據實體內容生成的一段hash字串，作為資源的唯一標識，由服務端產生，如：ETag:"0q9QPk4kQr2st/XMvRW8yqEt2iw=";

If-None-Match 是一個條件式的請求首部。web伺服器收到請求後發現有頭If-None-Match則與被請求資源的相應校驗串Etag進行比對,如果匹配伺服器才會返回帶有所請求資源實體的200響應，否則伺服器會返回不帶實體的304響應，流程見下圖。如：If-None-Match:"eOM1rC2lomM4oUbYNn0QD/Y4WLg="。

注：ETag優先順序比Last-Modified高，同時存在時會以ETag為準。

協商快取流程

學以致用

最後，回到文章開頭的情景進行分析，根據下圖中請求的Response 頭部資訊中Expires欄位得知，http請求的資源有3個小時的快取時間，而報文中同時也出現了Cache-Control: max-age=10800，也表示資源在本地快取3個小時，此時無論二者時間是否一致，以Cache-Control為準。這也就解釋了後來(3個小時以內)再次點選按鈕時不再傳送請求的原因。