本文主要是介绍HTTP Cache(转译)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
总览
HTTP缓存是接收HTTP（S）请求并确定何时以及如何从磁盘缓存或从网络中获取数据的模块。 缓存位于浏览器进程中，作为网络堆栈的一部分。 它不应与Blink的内存中缓存混淆，后者位于渲染器进程中，并且与资源加载器紧密耦合。
从逻辑上讲，缓存位于内容编码逻辑和传输编码逻辑之间，这意味着缓存处理传输编码属性，并使用服务器设置的内容编码来存储资源。
缓存实现了HttpTransactionFactory接口，因此HttpCache :: Transaction（这是HttpTransaction的实现）将是与URLRequestJob关联的事务，用于获取大多数URLRequests。
每个配置文件（以及每个隔离的应用程序）都有一个HttpCache实例。 实际上，配置文件可能包含两个缓存实例：一个实例用于常规请求，另一个实例用于媒体请求。
请注意，由于HttpCache是负责处理来自磁盘或来自网络的请求，因此它实际上拥有创建网络事务的HttpTransactionFactory和用于处理来自磁盘的请求的disk_cache :: Backend。 当HttpCache被销毁时（通常在配置文件数据消失时），磁盘后端和网络层（HttpTransactionFactory）都消失了。
缓存之外可能存在一些代码，这些代码保留指向磁盘缓存后端的指针的副本。 在这种情况下，要求始终保持真实所有权，这意味着此类代码必须由缓存以过渡方式拥有（以便后端销毁与保存指针的代码同步发生）。
运作方式
缓存负责：
- 创建和管理磁盘缓存后端。
这主要是初始化问题。 创建的缓存不包含后端（但具有后端工厂），并且后端是根据需要一个请求的第一个请求按需创建的。 HttpCache具有将请求排队的所有逻辑，直到创建后端为止。
- 创建 HttpCache::Transactions.
- 创建和管理由HttpCache :: Transactions与磁盘后端进行交互的ActiveEntries。
ActiveEntry是一个小对象，代表磁盘缓存项和有权访问它的所有事务。 Writer，Reader列表和未决事务列表（等待成为Writer或Reader）是ActiveEntry的一部分。缓存具有用于创建或打开磁盘缓存项并将其放置在ActiveEntry上的代码。 它还具有在ActiveEntry上附加事务或从ActiveEntry除去事务的所有逻辑。
- 强制执行缓存锁定。
缓存实现了一个写入器-多个读取器锁，因此在任何给定时间只有一个网络请求同一资源。请注意，缓存锁的存在意味着不会浪费带宽，同时重新获取同一资源。 另一方面，它迫使请求等待一个先前的请求完成下载资源（Writer）之后才能开始从中读取资源，这对于长期存在的请求特别麻烦。 简单地绕过缓存以处理后续请求不是一个可行的解决方案，因为当渲染器遇到时光倒流的影响时，它将引入一致性问题，例如，在接收到的资源版本早于已接收的版本时（但是 跳过了浏览器缓存）。
HTTP缓存的大部分逻辑实际上是由缓存事务实现的。
稀疏条目
HTTP缓存支持对任何资源使用备用条目。 稀疏条目通常由媒体资源（例如大的视频或音频文件）使用，并且一般的想法是只能存储资源的某些部分，并能够将这些部分从磁盘中送回。
通过从调用方发出字节范围请求来告知缓存应创建稀疏条目而不是常规条目的机制。 这告诉缓存，调用者已准备好处理字节范围，因此缓存可以存储字节范围。 请注意，如果缓存中已经存储了用于请求的URL的资源，则发出字节范围请求不会将该资源“升级”为稀疏条目； 实际上，通常没有办法将常规条目转换为稀疏条目，反之亦然。
一旦HttpCache创建了一个稀疏条目，磁盘缓存后端将负责以一种有效的方式存储字节范围，并且它将能够逐出资源的一部分而不会丢弃整个条目。 例如，当观看长视频时，后端可以丢弃电影的第一部分，同时仍存储当前正在接收（并呈现给用户）的部分。 如果用户返回几分钟，则可以从缓存中提供内容。 如果用户寻找已被逐出的部分，则可以再次获取视频。
在任何给定的时间，缓存都有可能存储了一组资源部分（不一定与用户请求的任何实际字节范围相匹配），并散布了丢失的数据。 为了满足给定的请求，HttpCache可能必须针对丢失的部分发出一系列字节范围的网络请求，同时根据需要从磁盘或从网络返回数据。 换句话说，当处理稀疏条目时，HttpCache :: Transaction将根据需要合成网络字节范围请求。
截断的条目
高速缓存将生成字节范围请求的第二种情况是，在丢失连接之前（或调用者取消了请求之前）没有完全接收到常规条目（非稀疏）。 在这种情况下，缓存将尝试从磁盘上服务资源的第一部分，并对资源的其余部分发出字节范围请求。 处理截断条目的大部分逻辑与支持备用条目所需的逻辑相同。
字节范围请求
如上所述，字节范围请求用于触发稀疏条目的创建（如果先前未存储资源）。 从用户的角度来看，缓存将透明地满足来自稀疏，截断或普通条目的字节范围请求和常规请求的任何组合。 毋庸置疑，如果客户端使用字节范围请求，则应准备处理该请求的含义，因为必须确定何时可以将请求组合在一起，范围适用于什么。
HttpCache::Transaction
大部分缓存逻辑由缓存事务实现。 在实现的中心有一个非常大的状态机（考虑到问题的异步性质，这可能是网络堆栈中最常见的模式）。 请注意，在主开关实现之前，有大量注释记录了状态机最常见的流模式。
这是状态机的一般图（并非详尽无遗）：
该图并不意味着跟踪代码的最新版本，而是提供状态机转换的大致概貌。 对于常规条目而言，该流程相对简单，但是高速缓存可以生成许多网络请求来满足涉及稀疏条目的单个请求，这一事实使得它可以追溯到START_PARTIAL_CACHE_VALIDATION。 请记住，每个单独的网络请求都可能失败，或者服务器可能具有资源的较新版本...尽管通常，当我们处理请求时，这种服务器行为将导致错误情况。
这篇关于HTTP Cache(转译)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
