WebKit和Chromium源码及原理剖析.pdf

HTTP Cache是完全按照IETF规范实现的，最新的RFC规范地址是

。它的作用就是保存可缓存的响应以备重新使用，在下次https://tools.ietf.org/html/rfc7234

请求时可减少响应时间和网络带宽。只有GET和HEAD method会缓存。

浏览器是过滤了部分没有意义进行缓存的响应头才保存到磁盘，例如Connection（keep-

alive）、www-authenticate等。这能减少耗时较多的磁盘IO时间。另外Cookie也不会保存在

HTTP Cache，而是存到专门的Cookie Storage。

新的规范允许先使用后验证（stale-while-revalidate）https://tools.ietf.org/html/rfc5861

，不确定GNUstep是否也是Apple的源码）。/blob/master/Source/NSURLCache.m

PC上的Chromium是以80MB为基准结合磁盘可用空间来考虑的，最大是320MB。算法是：

淘汰算法是一般是LRU，但在一些场景会结合文件大小、时间因素等做进一步优化。Cache的管理

模块会记录总的缓存大小，每次创建新的缓存时会判断是否缓存是否超出容量限制，满了就会按

LRU淘汰一定比例的缓存。

浏览器需要对缓存的文件进行索引，如果这个索引损坏，浏览器会删除所有的缓存。用户也可以

通过设置界面来删除。此外，第三方程序也会做清理。

用户点击刷新按钮，会强制走revalidate流程，其它的情况都按照规范来执行。

后端需要在响应中添加Cache-Control来利用浏览器缓存。

Expires不要超过一年。

稳定的文件应该加上max-age。max-age不要大于2^31，以免大于int32而变成负数。

Some HTTP/1.0 caches might not implement Cache-Control.对HTTP 1.0可以使用Pragma

没有任何与过期相关的指令的话，是由client端决定是否缓存的。Chromium有缓存，但再次请求

的时候并不会走Revalidate流程，还是会得到200 OK。

因为HTTP Cache以URL为key，所以不想用以前的缓存，则可以更换URL，例如加不同的query、改

文件名（如加上MD5或版本号）等。URL是忽略锚点的。

要做性能优化的同学，可以在协议文档里淘金。鉴于网上也有不少文章，这里不做整理了。

其中最老的规范RFC2109的6.3.1节中就有说明：