atitit。浏览器缓存机制 and 微信浏览器防止缓存的设计 attilax 总结

atitit。浏览器缓存机制 and 微信浏览器防止缓存的设计 attilax 总结

1. 缓存的一些机制 1

1.1. http 304 1

1.2. 浏览器刷新的处理机制 1

1.3. Expires 2

1.4. Cache-Control 2

1.5. Last-Modified/E-tag 3

1.6. Etag 主要为了解决 Last-Modified 无法解决的一些问题。 4

2. 不同的页面打开方式产生的请求差别 5

3. html  meta法 5

4. http head 法 6

5. url 时间戳 6

6. 引导页入口法 6

7. 參考 6

1. 缓存的一些机制

1.1. http 304

，告诉浏览器。我没变过，你去读缓存吧。于是浏览器也不用从server拉数据了。然而，等待server响应也是一个非常要命的问题。在网速发达的今天，等一个响应，有时比下载还慢。

304是HTTP状态码。server用来标识这个文件没改动，不返回内容，浏览器在接收到个状态码后，会使用浏览器已缓存的文件

当然浏览器在推断到缓存过期后。请求中头部附带If-Modified-Since字段去拉取某一个文件，server会依据这个指定的时间去推断，假设这个时间点之后没有改动。也会返回304

作者:: 老哇的爪子 Attilax 艾龙。  EMAIL:1466519819@qq.com

转载请注明来源： http://blog.csdn.net/attilax

1.2. 浏览器刷新的处理机制

，和

读取过的文件在http header设置了expire(http 1.0) / max-age(http 1.1)，在正常浏览时。如未超时，而且浏览器也有缓存时。会直接从浏览器缓存取出，但假设你在当前页面按刷新button（F5）时，有的浏览器会再次向server发出请求，有些浏览器不会。

1.3. Expires

Expires 头部字段提供一个日期和时间。在该日期前的全部对该资源的请求都会直接使用浏览器缓存而不用向server请求（注意：cache-control max-age 和 s-maxage 将覆盖 Expires 头部。

）

Expires 字段接收下面格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。

可是使用Expires存在server端时间和浏览器时间不一致的问题。

1.4. Cache-Control

Cache-Control 是最重要的规则。

这个字段用于指定全部缓存机制在整个请求/响应链中必须服从的指令。该字段通常覆盖默认缓存算法。另外，缓存指令是单向的，即请求中存在一个指令并不意味着响应中将存在同一个指令。

简单地说，该字段用于控制浏览器在什么情况下直接使用本地缓存而不向server发送请求。

一般具有下面值：

· public: 全部内容都将被缓存

· private: 内容仅仅缓存到似有缓存中

· no-cache: 全部内容都不会被缓存

· no-store: 全部内容都不会被缓存到缓存或者internet暂时文件里

· must-revalidation/proxy-revalidation: 假设缓存的内容失效。请求必须发送到server/代理以进行又一次验证

· max-age=xxx( xxx is numeric ): 缓存的内容将在 xxx 秒后失效, 这个选项仅仅在HTTP 1.1可用, 并假设和Last-Modified一起使用时, 优先级较高

当中最经常使用的属性便是 max-age, 这个字段非常easy，就是浏览器在资源成功请求后的制定时间内，都将直接调用本地缓存和不会向server去请求数据。

1.5. Last-Modified/E-tag

Last-Modified和E-tag的作用都是向server确认当前缓存文件是否为最新。

抛开功能不看。这两个字段的表现例如以下：

· 若server在响应一个资源时加入了Last-Modified字段，那么当下一次浏览器再一次向server请求该资源时（前提是浏览器中上一次的资源被缓存过了），会在请求header中包括If-Modified-Since字段，且值与server第一次响应给浏览器的Last-Modified字段一致

· 若server在响应一个资源时加入了ETag字段，那么当下一次浏览器再一次向server请求该资源时（前提是浏览器中上一次的资源被缓存过了），会在请求header中包括If-None-Match字段。且值与server第一次响应给浏览器的ETag字段一致

那么上述是遵循了Http协议的浏览器会自己主动实现的，而要实现304的功能，就须要server（比方Apache对于静态资源会自己主动实现这两个字段的响应）或者我们手动在server端编写响应的逻辑来实现。

，发送新文件并更新Last-Modified字段）

。发送新文件，并更新ETag）

1.6. Etag 主要为了解决 Last-Modified 无法解决的一些问题。

· 一些文件或许会周期性的更改，可是他的内容并不改变(只改变的改动时间)，这个时候我们并不希望client觉得这个文件被改动了，而又一次GET。

这样的情况下能够将某个能用来表明文件内容是否被更改的值（比方md5）来作为ETag

· 某些文件改动很频繁，比方在秒下面的时间内进行改动，(比方说1s内改动了N次)。If-Modified-Since能检查到的粒度是s级的，这样的改动无法推断(或者说UNIX记录MTIME仅仅能精确到秒)

· 某些server不能精确的得到文件的最后改动时间

2. 不同的页面打开方式产生的请求差别

一般我们打开（或者更新）一个页面（或者资源）有几种方式：

· 在地址栏中输入地址。然后回车

· 激活当前页面地址，然后回车

· F5刷新页面

· 单机Back/Forwardbutton

上面几种方式对资源的请求，会产生不同的结果，而且各浏览器的表现并不一致。详细的差别能够參考鸟哥的《浏览器缓存机制》

逻辑。

最后, 概括下关键的结论:

关键结论
打开新窗体	假设指定cache-control的值为private、no-cache、must-revalidate,那么打开新窗体訪问时都会又一次訪问server。而假设指定了max-age值,那么在此值内的时间里就不会又一次訪问server,比如：Cache-control: max-age=5 表示当訪问此网页后的5秒内再次訪问不会去server.
在地址栏回车	假设值为private或must-revalidate,则仅仅有第一次訪问时会訪问server,以后就不再訪问。 假设值为no-cache,那么每次都会訪问。假设值为max-age,则在过期之前不会反复訪问。
按后退按扭	假设值为private、must-revalidate、max-age,则不会重訪问,而假设为no-cache,则每次都反复訪问.
按刷新按扭	不管为何值,都会反复訪问.

3. html  meta法

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache">

<META HTTP-EQUIV="Expires" CONTENT="0">

这个好像对wechat不起作用。

4. http head 法

JSP：

response.setHeader("Pragma","No-cache"); 

response.setHeader("Cache-Control","no-cache"); 

response.setDateHeader("Expires", 0);

覆盖getLastModified方法，响应消息中无LastModified头字段

5. url 时间戳

window.location="a-intro.html?"+Math.random();

这个对wechat起作用。。

6. 引导页入口法

rdm。html

<script>

window.location="a-intro.html?"+Math.random();

</script>

7. 參考

(3 条消息) 浏览器文件缓存和304的差别？ - 知乎.htm

[转载](转)浏览器缓存和304小结_hugh_新浪博客.htm

（very detail good）浏览器缓存机制   风雪之隅.htm