文檔主要描述了 disk_cache API 的主要用途，以及三種 API 實現的簡單介紹，英文原文。
1、disk_cache API
The disk_cache API provides for caches that can store multiple random-access
byte streams of data associated with a key on disk (or in memory).
chromium 的網絡棧中，有些緩存對象可以存儲多個隨機訪問的字節 stream，這些字節 stream
通過一個 key 映射到磁盤（或內存）中的數據。disk_cache API 就是提供給這些緩存對象的。
There are two kinds of entries that can be stored: regular and sparse.
有兩種類型的入口對象可以被存儲：常規的和稀疏的
Regular entries contain up to 3 separate data streams. Usually stream 0
would be used for some kind of primary small metadata (e.g. HTTP headers);
stream 1 would contain the main payload (e.g. HTTP body); and stream 2 would
optionally contain some auxiliary metadata that's needed only some of the time
(e.g. V8 compilation cache). There is no requirement that these streams be used
in this way, but implementations may expect similar size and usage
characteristics.
常規入口對象包括三個獨立的數據 stream，stream 0 用於小的元數據（比如 HTTP 頭部）；
stream 1 用於負載數據（比如 HTTP body），stream 2 選擇性的包含某些時刻纔會用
到的輔助性的元數據（比如 V8 編譯緩存）。沒有要求說這些 stream 必須這樣使用，
但是在實際實現中，一般期望這些 stream 有相同的大小和相同的使用特徵。
Sparse entries have a stream 0 and a separate sparse stream that's accessed with
special methods that have `Sparse` in their names. It's an API misuse to try to
access streams 1 or 2 of sparse entries or to call `WriteSparseData` on entries
that have contents in those streams. Calling `SparseReadData` or
`GetAvailableRange` to check whether entries are sparse is, however, permitted.
An added entry becomes a regular entry once index 1 or 2 is written to, or it
becomes a sparse entry once the sparse stream is written to. Once that is done,
it cannot change type and the access/modification restrictions relevant to the
type apply. Type of an entry can always be determined using `SparseReadData` or
`GetAvailableRange`.
稀疏入口對象包括一個 stream 0 和 稀疏 stream（訪問的方法名都包含 Sparse 字樣），使用
帶 Sparse 字樣的方法去訪問 stream 1 和 stream 2 是錯誤的。但可以調用 SparseReadData 或
GetAvailableRange 來檢查入口對象是否是稀疏入口對象。新增的入口對象如果有數據要寫入 stream 1
或 stream 2，那麼這個入口對象是常規的，如果有數據要寫入稀疏 stream，那麼它就是稀疏入口對象。
一旦入口對象被確定了類型，那麼它的類型就無法被更改。入口對象的類型可以通過 SparseReadData
或 GetAvailableRange 來判斷。
The sparse streams are named as such because they are permitted to have holes in
the byte ranges of contents they represent (and implementations may also drop
some pieces independently). For example, in the case of a regular entry,
starting with an empty entry, and performing `WriteData` on some stream at
offset = 1024, length = 1024, then another `WriteData` at offset = 3072,
length = 1024, results in the stream having length = 4096, and the areas not
written to filled in with zeroes.
稀疏 stream 之所以這麼叫稀疏是因爲它的數據代表的一個字節流的某一個片段（相關實現
也會丟棄一些片段）。例如，一個空的常規入口對象，在某個 stream 中 offset = 1024 的
位置執行 WriteData，寫入的長度是 1024，另外一個 WriteData 在 offset = 3072 的位置
寫入長度爲 1024 的數據，那麼最後這個 stream 擁有的長度是 4096，中間未被寫入的部分
（2048-3071）被 0 值填充。
In contrast, after the same sequence of `WriteSparseData` operations, the entry
will actually keep track that [1024, 2048) and [3072, 4096) are valid, and will
permit queries with `GetAvailableRange`, and only allow reads of the defined
ranges.
與常規入口對象不同的是，稀疏入口對象的 stream 在經過上述同樣的操作後，它的 stream
中只有 [1024-2048]，[3072, 4096] 這兩個片段的數據是有效，是被允許讀取的。
[`net/disk_cache/disk_cache.h`](/net/disk_cache/disk_cache.h) is the only
include you need if you just want to use this API.
`disk_cache::CreateCacheBackend()` is the first method you'll need to call.
當需要使用 disk_cache API 時，只需引入 net/disk_cache/disk_cache.h 即可；
而 disk_cache::CreateCacheBackend() 是第一個需要調用的方法。
2、The implementations
disk_cache/blockfile directory
This implementation backs the HTTP cache on Windows and OS X. It tries to pack
many small entries caches typically have into "block" files, which can help
performance but introduces a lot of complexity and makes recovery from
corruption very tricky.
該實現在 Windows 和 OS X 平臺下支持 HTTP 緩存。它嘗試將許多小的緩存打包進一個 block
文件中以提升性能，但是引入了許多複雜性，並且使得恢復很困難。
disk_cache/memory directory
This contains the in-memory-only implementation. It's used for incognito
mode.
disk_cache/simple directory
This implementation backs the HTTP cache on Android, ChromeOS, and Linux, and
is used to implement some features like CacheStorage on all platforms. The
design is centered around roughly having a single file per cache entry (more
precisely for streams 0 and 1), with a compact and simple in-memory index for
membership tests, which makes it very robust against failures, but also highly
sensitive to OS file system performance.
該實現在 Android、Chrome OS 和 Linux 平臺下支持 HTTP 緩存，且被用於在所有平臺下實現
相關特性比如 CacheStorage。該設計的核心就是一個文件對應一個入口對象（準確來說是 stream 0 和 stream 1），
這使得它擁有很高的魯棒性，但同時也對文件系統的性能較爲敏感。