chromium源碼閱讀--HTTP Cache

最近積累了一些關於HTTP緩存的知識，所以結合Chromium的實現總結一下，主要從以下2個分面：

    一、HTTP緩存的基礎知識

    二、Chromium關於HTTP緩存的實現分析

 

1、HTTP緩存的基礎知識

基本上每一個瀏覽器都啓用了HTTP緩存功能。

當服務器返回響應時，會響應一組HTTP頭，用於描述響應的內容類型、長度、緩存指令、驗證令牌等。

例如，在上圖的交互中，服務器返回一個 1024 字節的響應，指示客戶端將其緩存最多 120 秒，並提供一個驗證令牌（「x234dff」），可在響應過時後用來檢查資源是否被修改。

 

所以，瀏覽器能夠經過 ETag 驗證緩存的響應：

   一、服務器使用 ETag HTTP 標頭傳遞驗證令牌。

   二、驗證令牌可實現高效的資源更新檢查：資源未發生變化時不會傳送任何數據。

 

從性能優化的角度來講，最佳請求是無需與服務器通訊的請求：能夠經過響應的本地副本消除全部網絡延遲，以及避免數據傳送的流量費用。

爲實現此目的，HTTP 規範容許服務器返回 Cache-Control 指令，這些指令控制瀏覽器和其餘中間緩存如何緩存各個響應以及緩存多久。

注：Cache-Control 標頭是在 HTTP/1.1 規範中定義的，取代了以前用來定義響應緩存策略的標頭（例如 Expires）。全部現代瀏覽器都支持 Cache-Control，所以，使用它就夠了。

「no-cache」和「no-store」

「no-cache」表示必須先與服務器確認返回的響應是否發生了變化，而後才能使用該響應來知足後續對同一網址的請求。所以，若是存在合適的驗證令牌 (ETag)，no-cache 會發起往返通訊來驗證緩存的響應，但若是資源未發生變化，則可避免下載。

相比之下，「no-store」則要簡單得多。它直接禁止瀏覽器以及全部中間緩存存儲任何版本的返回響應，例如，包含我的隱私數據或銀行業務數據的響應。每次用戶請求該資產時，都會向服務器發送請求，並下載完整的響應。

「public」與「private」

若是響應被標記爲「public」，則即便它有關聯的 HTTP 身份驗證，甚至響應狀態代碼一般沒法緩存，也能夠緩存響應。大多數狀況下，「public」不是必需的，由於明確的緩存信息（例如「max-age」）已表示響應是能夠緩存的。

相比之下，瀏覽器能夠緩存「private」響應。不過，這些響應一般只爲單個用戶緩存，所以不容許任何中間緩存對其進行緩存。例如，用戶的瀏覽器能夠緩存包含用戶私人信息的 HTML 網頁，但 CDN 卻不能緩存。

「max-age」

指令指定從請求的時間開始，容許獲取的響應被重用的最長時間（單位：秒）。例如，「max-age=60」表示可在接下來的 60 秒緩存和重用響應。

  

2、Chromiun關於HTTP緩存的實現

代碼閱讀起來很是繁複，因此仍是按照本身的理解畫了一個類圖，畫完以後以爲果真是清晰不少。

 內容參考： https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn