文档主要描述了 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），
这使得它拥有很高的鲁棒性，但同时也对文件系统的性能较为敏感。