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