1.HTTP Cache概要
HTTP Cache是接收HTTP（S）請求并決定何時以及如何從磁盤高速緩存或從網絡獲取數據的模塊。緩存作為網絡堆棧的一部分存在于瀏覽器進程中。它不應該與Blink的內存緩存混淆，后者位于渲染器進程中，并且與資源加載器緊密耦合。
邏輯上，緩存位于內容編碼邏輯和傳輸編碼邏輯之間，這意味著它處理傳輸編碼屬性并使用服務器設置的內容編碼存儲資源。
緩存實現了HttpTransactionFactory接口，因此HttpCache :: Transaction（它是HttpTransaction的實現）將是與用于獲取大多數URLRequests的URLRequestJob相關聯的事務。
每個配置文件（以及每個隔離的應用程序）都有一個HttpCache實例。實際上，配置文件可能包含兩個緩存實例：一個用于常規請求，另一個用于媒體請求。
請注意，因為HttpCache是負責從磁盤或網絡提供請求的人，它實際上擁有創建網絡事務的HttpTransactionFactory，以及用于從磁盤提供請求的disk_cache :: Backend。當HttpCache被銷毀時（通常在配置文件數據消失時），磁盤后端和網絡層（HttpTransactionFactory）都會消失。
緩存外部可能有代碼，用于保存指向磁盤緩存后端的指針的副本。在這種情況下，要求始終保持真正的所有權，這意味著這些代碼必須由高速緩存傳遞地擁有（以便后端破壞與保留指針的代碼的銷毀同步發生）。
2.HTTP Cache操作
HTTP Cache負責：
- 創建和管理磁盤緩存后端。
這主要是初始化問題。創建緩存時沒有后端（但具有后端工廠），后端由第一個需要后端的請求按需創建。 HttpCache具有將請求排隊的所有邏輯，直到創建后端。
- 創建HttpCache :: Transactions。
- 建和管理HttpCache :: Transactions用于與磁盤后端交互的ActiveEntries。
- ActiveEntry是一個小對象，表示磁盤高速緩存條目以及有權訪問它的所有事務。 Writer，讀者列表和待處理事務列表（等待成為Writer或讀者）是ActiveEntry的一部分。
緩存具有用于創建或打開磁盤緩存條目的代碼，并將它們放在ActiveEntry上。它還具有連接和從ActiveEntry中刪除事務的所有邏輯。
- 強制執行緩存鎖定。
緩存實現單個寫入器 - 多個讀取器鎖定，以便在任何給定時間只有一個網絡請求同一資源在飛行中。
請注意，緩存鎖定的存在意味著沒有浪費帶寬同時重新獲取相同的資源。另一方面，它強制請求等待，直到先前的請求完成下載資源（Writer）才能開始讀取它，這對于長期存在的請求尤其麻煩。簡單地繞過緩存以用于后續請求不是一個可行的解決方案，因為當渲染器經歷回溯的影響時會引入一致性問題，如接收比其已經接收的版本更舊的資源版本（但是它跳過瀏覽器緩存）。
HTTP緩存的大部分邏輯實際上是由緩存事務實現的。
3.Sparse Entries
HTTP緩存支持對任何資源使用備用條目。稀疏條目通常由媒體資源使用（想想大型視頻或音頻文件），一般的想法是只能存儲資源的某些部分，并能夠從磁盤返回這些部分。
用于告訴緩存它應該創建稀疏條目而不是常規條目的機制是通過從調用者發出字節范圍請求。這告訴緩存調用者準備處理字節范圍，因此緩存可以存儲字節范圍。請注意，如果緩存已經為請求的URL存儲了資源，則發出字節范圍請求將不會將該資源“升級”為稀疏條目;實際上，通常無法將常規條目轉換為稀疏條目，反之亦然。
一旦HttpCache創建了稀疏條目，磁盤緩存后端將負責以有效的方式存儲字節范圍，并且它將能夠驅逐部分資源而不會丟棄整個條目。例如，當觀看長視頻時，后端可以丟棄電影的第一部分，同時仍然存儲當前正被接收的部分（并呈現給用戶）。如果用戶返回幾分鐘，則可以從緩存中提供內容。如果用戶尋找已經被驅逐的部分，那么該部分可以再次獲取視頻。
在任何給定時間，高速緩存都可能存儲了資源的一組部分（其不一定匹配用戶請求的任何實際字節范圍），其中散布有丟失的數據。為了滿足給定的請求，HttpCache可能必須為丟失的部分發出一系列字節范圍的網絡請求，同時根據需要從磁盤或網絡返回數據。換句話說，當處理稀疏條目時，HttpCache :: Transaction將根據需要合成網絡字節范圍請求。
4.Truncated Entries
緩存將生成字節范圍請求的第二種情況是在連接丟失之前未完全接收到常規條目（非稀疏）（或者調用者取消了請求）。在這種情況下，緩存將嘗試從磁盤提供資源的第一部分，并為資源的其余部分發出字節范圍請求。處理截斷條目的大部分邏輯與支持備用條目所需的邏輯相同。
5.Byte-Range Requests
如上所述，字節范圍請求用于觸發稀疏條目的創建（如果先前未存儲資源）。從用戶的角度來看，緩存將透明地實現字節范圍請求和來自稀疏，截斷或正常條目的常規請求的任何組合。毋庸置疑，如果客戶端使用字節范圍請求，則應準備好處理該請求的含義，因為必須確定何時可以將請求組合在一起，范圍適用于什么（通過線路字節）等。
6.HttpCache::Transaction
大部分緩存邏輯由緩存事務實現。在實現的中心，有一個非常大的狀態機（可能是網絡堆棧中最常見的模式，考慮到問題的異步性質）。請注意，在主交換機實現之前，有一個注釋塊記錄了狀態機的最常見流模式。
這是狀態機的一般（非詳盡）圖表：
此圖不是為了跟蹤代碼的最新版本，而是提供狀態機轉換的大致概述。對于常規條目，流程相對簡單，但是緩存可以生成大量網絡請求來完成涉及稀疏條目的單個請求，這樣就可以回到START_PARTIAL_CACHE_VALIDATION。請記住，每個單獨的網絡請求都可能失敗，或者服務器可能具有更新版本的資源...盡管通常在我們處理請求時這種服務器行為將導致錯誤情況。
| 
