也说浏览器缓存

今天看到了一篇文章关于缓存和 Chrome 的“新版刷新" 然后在群里引为了关于浏览器缓存的讨论。 下面说一下浏览器缓存之我见

HTTP cache-control的策略

缓存可以降低网络请求，提升用户体验。所以对于一个有很好用户体验的客户端来讲，必然需要一定的缓存， 然而如何进行缓存，就需要有一定的缓存策略， （比如所有的资源全部5分钟内有效， 再如 所有资源全部都不进行缓存）。 对于浏览器，或者通用的webview 来讲， 因为不知道所要承载的资源，所以需要允许由不同的资源本身设置自己的缓存策略。 这就用到了HTTP的cache-control header。

浏览器（包含webview 下同）向server端请求一个资源时，比如a.html 同时在Response header 中可能会带有 Cache-Control的header， 浏览器将根据Cache-control 的内容，设着这个资源的缓存策略。 当然，如果没有Cache-Control字段，浏览器也可能有自己的一些默认行为， 这些默认行为将会随浏览器不同而不同。（比如firefox 默认的缓存策略是no-conrol, 而对于新版的chrome来讲，默认的缓存策略就变成了immutable）

举个栗子

我们以请求 http://www.domob.cn/ 为例。

 ○ curl -v http://www.domob.cn
* Rebuilt URL to: http://www.domob.cn/
*   Trying 124.250.50.9...
* TCP_NODELAY set
* Connected to www.domob.cn (124.250.50.9) port 80 (#0)
> GET / HTTP/1.1
> Host: www.domob.cn
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 23 Feb 2017 03:35:37 GMT
< Server: Apache
< Set-Cookie: PHPSESSID=r1gtnrhdkmqd1vnhilv8ndj3j3; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Transfer-Encoding: chunked
< Content-Type: text/html
<

对于这个资源来讲， Cache-Control的策略为 no-store, no-cache, must-revalidate, post-check=0, pre-check=0 然后浏览器就会根据server 端的返回来控制缓存

 ○ curl -v http://meirisuoping.com/index.html
*   Trying 124.250.50.48...
* TCP_NODELAY set
* Connected to meirisuoping.com (124.250.50.48) port 80 (#0)
> GET /index.html HTTP/1.1
> Host: meirisuoping.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.6.0
< Date: Thu, 23 Feb 2017 03:39:03 GMT
< Content-Type: text/html
< Content-Length: 4648
< Last-Modified: Fri, 22 Jul 2016 10:26:20 GMT
< Connection: close
< ETag: "5791f4cc-1228"
< Accept-Ranges: bytes

对于这个请求 服务端没有返回Cache-Control 这时浏览器可能会有自己的默认缓存策略。 对于不同的浏览器，对于不同的资源，缓存策略都是不同的。 这个稍后讨论。

不同的缓存策略

对于不同的caching 可以参看MDN文档 https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
以下是对这个文档的摘录

The Cache-Control HTTP/1.1 general-header field is used to specify directives for caching mechanisms in both requests and responses. Use this header to define your caching policies with the variety of directives it provides.

No cache storage at all

The cache should not store anything about the client request or server response. A request is sent to the server and a full response is downloaded each and every time.

Cache-Control: no-store
Cache-Control: no-cache, no-store, must-revalidate

No caching

A cache will send the request to the origin server for validation before releasing a cached copy.

Cache-Control: no-cache

Private and public caches

The “public" directive indicates that the response may be cached by any cache. This can be useful, if pages with HTTP authentication or response status codes that aren’t normally cacheable, should now be cached. On the other hand, “private" indicates that the response is intended for a single user only and must not be stored by a shared cache. A private browser cache may store the response in this case.

Cache-Control: private
Cache-Control: public

Expiration

The most important directive here is max-age= which is the maximum amount of time a resource will be considered fresh. Contrary to Expires, this directive is relative to the time of the request. For the files in the application that will not change, you can usually add aggressive caching. This includes static files such as images, CSS files and JavaScript files, for example.

Cache-Control: max-age=31536000

Validation

When using the “must-revalidate" directive, the cache must verify the status of the stale resources before using it and expired ones should not be used. For more details, see the Validation section below.

Cache-Control: must-revalidate

缓存的刷新策略

对于一个资源来说， 可以Cache再浏览器内，浏览器Cache的资源有两种状态， 未过期的资源 fresh 和已经过期的资源 stale 。当浏览器请求stale的资源时， 浏览器将向server端发送一个资源验证请求， 服务端根据浏览器的请求返回304 或者是200。
如下图

资源验证请求

当Server端返回的资源有Etag或者Last-Modified头时，浏览器会在资源stale的时候， 向服务端重新发送请求。当服务端认为资源可以继续用的时候就返回304， 当服务端认为资源不可再用的时候就要返回 200 加资源。

生产环境中的具体使用

在生产环境中， 我们当然希望资源cache的越多越好， 但是又希望资源能在我们需要过期的时候立即过期。

对于css，js， 或图片文件来讲， 我们可以用webpack之类的前端工具，对css文件， js文件，命名成hash值的形式， 这样就可以一直缓存在浏览器端， 当发布新资源的时候， hash值改变了， 浏览器就会立即更新过来。

但对于 index.html 这样的文件， 我们就不能一直缓存， 对于这种文件有两种处理方式，

1. 缓存可接受的时间 如 5分钟
2. 将缓存策略设置为 no-cache

因为不同浏览器或webview对于不设着缓存策略的资源有着不同甚至比较诡异的行为，所以为了保险起见，一定要设着Cache-Control

最后以夺宝吧的nginx配置为例，仅供参考

    # 静态图片缓存30天
    location  ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
        expires 30d;
    add_header Cache-Control "public";

    }


    # h5资源缓存30分钟
    # 因为对于夺宝来说css,js没有取hash值， 所以就缓存一个可接受的时间范围。
    location ~ ^/(html|js|css) {
        expires 30m;
        add_header Cache-Control "public";
    }