Chromium内核原理之网络栈HTTP Cache

《Chromium内核原理之blink内核工作解密》
《Chromium内核原理之多进程架构》
《Chromium内核原理之进程间通信(IPC)》
《Chromium内核原理之网络栈》
《Chromium内核原理之网络栈HTTP Cache》
《Chromium内核原理之Preconnect》
《Chromium内核原理之Prerender》
《Chromium内核原理之cronet独立化》

1.HTTP Cache概要
2.HTTP Cache操作
3.Sparse Entries
4.Truncated Entries
5.Byte-Range Requests
6.HttpCache::Transaction

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

大部分缓存逻辑由缓存事务实现。在实现的中心，有一个非常大的状态机（可能是网络堆栈中最常见的模式，考虑到问题的异步性质）。请注意，在主交换机实现之前，有一个注释块记录了状态机的最常见流模式。

这是状态机的一般（非详尽）图表：

 

http_cache_arch.png

此图不是为了跟踪代码的最新版本，而是提供状态机转换的大致概述。对于常规条目，流程相对简单，但是缓存可以生成大量网络请求来完成涉及稀疏条目的单个请求，这样就可以回到START_PARTIAL_CACHE_VALIDATION。请记住，每个单独的网络请求都可能失败，或者服务器可能具有更新版本的资源...尽管通常在我们处理请求时这种服务器行为将导致错误情况。

作者：木子一秋
链接：https://www.jianshu.com/p/e6fb8fddf656
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。