浏览器/web-缓存知识点梳理

引言

Web 缓存 位于 内容 源 Web 服务器 和 客户 端 之间， 当 用户 访问 一个 URL 时， Web 缓存 服务器 会 去 后端 Web 源 服务器 取回 要 输出 的 内容， 然后， 当下 一个 请求 到来 时， 如果 访问 的 是 相同 的 URL， Web 缓存 服务器 直接 输出 内容 给 客户 端， 而 不是 向 源 服务器 再次 发送 请求。 Web 缓存 降低 了 内容 源 Web 服务器、 数据库 的 负载， 减少 了 网络 延迟， 提高 了 用户 访问 的 响应 速度， 增强 了 用户 体验。

缓存的整体工作流程可以简略的用下图表示：

1·强缓存和协商缓存

1.1·强缓存

      强缓存需要服务端设置expires和cache-control。

      强缓存作为性能优化中缓存方面最有效的手段，能够极大的提升性能。由于强缓存不会向服务端发送请求，对服务端的压力也是大大减小。

      在命中强缓存的情况下，进程初次渲染会从磁盘读取缓存资源。Chrome会将部分资源保存到内存中：

      强缓存命中一般都会出现：200 ok (from disk cache)(磁盘缓存)或者200 ok (from memory cache)(内存缓存)

1.2·协商缓存

      协商缓存是由服务器判断缓存是否过期，需要向服务器发送请求，也可以说是缓存校验，协商缓存有ETag和Last-Modified

      在强缓存没有命中的时候，就是协商缓存发挥的地盘了。协商缓存会根据[last-modified/if-modified-since]或者[etag/if-none-match]来进行判断缓存是否过期。

      协商缓存是无法减少请求数的开销的，但是可以减少返回的正文大小。一般来说，对于勤改动的html文件，使用协商缓存是一种不错的选择。

      协商缓存命中一般会出现：304 Not Modified

2·cache-control和Expires

cache-control的优先级比Expires高，同时存在的话看cache-control

Expries = 时间，HTTP 1.0 版本，缓存的时间，允许客户端在这个时间段之内不去检查(发送请求)

max-age = 秒，HTTP 1.1版本，资源在本地缓存多少秒

cache-control(max-age)缓存的是相对时间

Expries缓存的是绝对时间

max-age和Expries同时存在时，判断缓存是否过期的流程如下：

一个真实请求中的例子：

2.1·Cache-Control

Cache-Control是http1.1的产物，他可以看成是expries的补充。

2.1.1·可选参数

在请求中使用Cache-Control 时，它可选的值有：

在响应中使用Cache-Control 时，它可选的值有：

2.1.2·nginx中的配置

给响应头中加Cache-Control

server {
    listen 88;
    root /opt/ms;
    index index.php index.html index.htm index.nginx-debian.html;
    
    location ~* ^.+\.(css|js|txt|xml|swf|wav)$ {
        add_header Cache-Control no-store;
        add_header Cache-Control max-age=3600;
        add_header Cache-Control public;
        add_header Cache-Control only-if-cached;
        add_header Cache-Control no-cache;
        add_header Cache-Control must-revalidate;
    }
}
 

2.2·expires

expires是http1.0的标准，表明服务器的过期时间，是格林威治时间，当请求的时候客户端的时间超过expires标识的时间时，就会去请求服务器。

当请求的时候客户端的时间超过expires标识的时间时，就会去请求服务器，但是这个其实是存在问题的，当用户的系统时间改到这个标识的时间之后，就永远不会命中这个强制缓存。所以Cache-Control就诞生了。

2.2.1·nginx配置

location ~ \.(gif|jpg|jpeg|png|bmp|ico)$ {

     root /var/www/img/;

     expires 30d;

}

3·ETag与If-None-Match

      ETag是在响应头中，服务器返回给浏览器的

      If-None-Match是在请求头中，浏览器发起请求带给服务器的

      Etag是服务端的一个资源的标识，在 HTTP 响应头中将其传送到客户端。所谓的服务端资源可以是一个Web页面，也可以是JSON或XML等。

      当浏览器请求服务器的某项资源(A)时, 服务器根据A算出一个哈希值(5f704cc8-1fc2)并通过 ETag 返回给浏览器，浏览器把"5f704cc8-1fc2" 和 资源(A)同时缓存在本地，当下次再次向服务器请求资源(A)时，会通过If-None-Match: "5f704cc8-1fc2" 的请求头把ETag发送给服务器，服务器再次计算资源(A)的哈希值并和浏览器返回的值做比较：

      如果发现资源(A)发生了变化就把A返回给浏览器(200)，将资源返回，浏览器使用服务端返回的资源，并更新缓存

      如果发现A没有变化就给浏览器返回一个304未修改。不用返回资源，浏览器使用本地缓存的资源

      Apache中，Etag的值，默认是对文件的索引节（INode），大小（Size）和最后修改时间（MTime）进行Hash后得到的。

      注意：在服务器端实现中，很多情况下并不会用哈希来计算ETag，这会严重浪费服务器端资源，很多网站默认是禁用ETag的。有些情况下，可以把ETag退化，比如通过资源的版本或者修改时间来生成ETag。如果通过资源修改时间来生成ETag，那么效果和HTTP协议里面的另外一个控制属性(Last-Modified)就雷同了，使用 Last-Modified 的问题在于它的精度在秒(s)的级别，比较适合不太敏感的静态资源。

      nginx关闭etag方法：配置文件中加入FileETag off;

      

      etag的实际例子如下，浏览器带着etag去向后端请求，后端根据etag发现资源没有变化，就直接返回304 ，表示资源未改变

4·Last-Modified与If-Modified-Since

      Last-Modified是在响应头中，服务器返回给浏览器的

      If-Modified-Since是在请求头中，浏览器发起请求带给服务器的

      Last-Modified与etag类似，都是服务器端资源的标识，可以以此来判断资源是否更新过，不过Last-Modified是以资源更新时间来判断的

      第一次访问资源的时候，服务器返回资源，并带上类似为Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT的响应头，已标记资源最新更新的时间。浏览器将其缓存再本地，浏览器下次再访问该资源的时候会带上类似If-Modified-Since:Tue, 11 Jul 2000 18:23:51 GMT的请求头，服务端判断这个时间与服务器上该资源最后修改时间是否一致：

      如果发现时间不一致，就返回给浏览器200，将资源返回，浏览器使用服务端返回的资源，并更新缓存

      如果发现时间一致，就返回一个304未修改。不用返回资源，浏览器使用本地缓存的资源

5·from disk cache与from memory cache

我们经常会看到web使用本地缓存的时候，有的是from disk cache有的是from memory cache，如下面两个图

浏览器缓存存在磁盘还是内存主要决定因素是内存空闲情况，如果内存使用率很低就优先放入内存，反之则放入磁盘。

5.1·200 from memory cache

不访问服务器，直接读缓存，从内存中读取缓存。此时的数据时缓存到内存中的，当kill进程后，也就是浏览器关闭以后，数据将不存在。

5.2·200 from disk cache

不访问服务器，直接读缓存，从磁盘中读取缓存，当kill进程时，数据还是存在。