http浏览器缓存

目录

 

Header字段

通用header

RequestHeader

ResponseHeader

协商缓存：浏览器与服务器合作之下的缓存策略

协商缓存的实现：从 Last-Modified 到 Etag

Cache-Control

RequestHeader

ReponseHeader

Last-Modified

Etag

HTTP缓存机制

协商缓存阶段

总结

浏览器刷新

正常重新加载

强制重新加载

参考

---

 

Header字段

通用header

1. Cache-Control
2. Pragma http1.0的遗留物，值为‘no-cache’时禁用缓存

 

RequestHeader

1. If-Match 比较Etag是否一致
2. If-None-Match 比较Etag是否不一致
3. If-Modified-Since  比较资源最后更新的时间是否一致，如果一致返回状态码304
4. If-Unmodified-Since  比较资源最后更新的时间是否不一致，如果不一致返回状态码412

ResponseHeader

1. Etag 资源的匹配信息
2. Expires http1.0的遗留物，实体主题过期的时间
3. Last-Modified 资源的最后一次修改时间

 

chrome使用F5会强制加上“cache-control:max-age=0”

 

 

 

协商缓存：浏览器与服务器合作之下的缓存策略

协商缓存依赖于服务端与浏览器之间的通信。

协商缓存机制下，浏览器需要向服务器去询问缓存的相关信息，进而判断是重新发起请求、下载完整的响应，还是从本地获取缓存的资源。

如果服务端提示缓存资源未改动（Not Modified），资源会被重定向到浏览器缓存，这种情况下网络请求对应的状态码是 304（not modified）。

协商缓存的实现：从 Last-Modified 到 Etag

Last-Modified 是一个时间戳，如果我们启用了协商缓存，它会在首次请求时随着 Response Headers 返回：

Last-Modified: Fri, 27 Oct 2017 06:35:57 GMT

随后我们每次请求时，会带上一个叫 If-Modified-Since 的时间戳字段，它的值正是上一次 response 返回给它的 last-modified 值：

If-Modified-Since: Fri, 27 Oct 2017 06:35:57 GMT

服务器接收到这个时间戳后，会比对该时间戳和资源在服务器上的最后修改时间是否一致，从而判断资源是否发生了变化。如果发生了变化，就会返回一个完整的响应内容，并在 Response Headers 中添加新的 Last-Modified 值；否则，返回如上图的 304 响应，Response Headers 不会再添加 Last-Modified 字段。

使用 Last-Modified 存在一些弊端，这其中最常见的就是这样两个场景：

• 我们编辑了文件，但文件的内容没有改变。服务端并不清楚我们是否真正改变了文件，它仍然通过最后编辑时间进行判断。因此这个资源在再次被请求时，会被当做新资源，进而引发一次完整的响应——不该重新请求的时候，也会重新请求。

• 当我们修改文件的速度过快时（比如花了 100ms 完成了改动），由于 If-Modified-Since 只能检查到以秒为最小计量单位的时间差，所以它是感知不到这个改动的——该重新请求的时候，反而没有重新请求了。

这两个场景其实指向了同一个 bug——服务器并没有正确感知文件的变化。为了解决这样的问题，Etag 作为 Last-Modified 的补充出现了。

Etag 是由服务器为每个资源生成的唯一的标识字符串，这个标识字符串是基于文件内容编码的，只要文件内容不同，它们对应的 Etag 就是不同的，反之亦然。因此 Etag 能够精准地感知文件的变化。

Etag 和 Last-Modified 类似，当首次请求时，我们会在响应头里获取到一个最初的标识符字符串，举个例子它可以是这样的：

ETag: W/"2a3b-1602480f459"

那么下一次请求时，请求头里就会带上一个值相同的、名为 if-None-Match 的字符串供服务端比对了：

If-None-Match: W/"2a3b-1602480f459"

Etag 的生成过程需要服务器额外付出开销，会影响服务端的性能，这是它的弊端。因此启用 Etag 需要我们审时度势。正如我们刚刚所提到的——Etag 并不能替代 Last-Modified，它只能作为 Last-Modified 的补充和强化存在。 Etag 在感知文件变化上比 Last-Modified 更加准确，优先级也更高。当 Etag 和 Last-Modified 同时存在时，以 Etag 为准。

 

需要注意的就是no-cache与max-age=0的区别，no-cache是压根都不用缓存，直接请求服务器200，过期时间为0就会走Etag/Last-Modified缓存的判断

 

Cache-Control

RequestHeader

 

ReponseHeader

 

no-store优先级最高

Last-Modified

服务端在返回资源时，会将该资源的最后更改时间通过Last-Modified字段返回给客户端。客户端下次请求时通过If-Modified-Since或者If-Unmodified-Since带上Last-Modified，服务端检查该时间是否与服务器的最后修改时间一致：如果一致，则返回304状态码，不返回资源；如果不一致则返回200和修改后的资源，并带上新的时间。

 

Etag

单纯的以修改时间来判断还是有缺陷，比如文件的最后修改时间变了，但内容没变。对于这样的情况，我们可以使用etag来处理。
etag的方式是这样：服务器通过某个算法对资源进行计算，取得一串值(类似于文件的md5值)，之后将该值通过etag返回给客户端，客户端下次请求时通过If-None-Match或If-Match带上该值，服务器对该值进行对比校验：如果一致则不要返回资源。
If-None-Match和If-Match的区别是：
If-None-Match：告诉服务器如果一致，返回状态码304，不一致则返回资源
If-Match：告诉服务器如果不一致，返回状态码412

 

 

HTTP缓存机制

缓存行为主要由缓存策略决定，而缓存策略由内容拥有者设置。这些策略主要通过特定的HTTP头部来清晰地表达。

当一个用户发起一个静态资源请求的时候，浏览器会通过以下几步来获取资源：

• 本地缓存阶段：先在本地查找该资源，如果有发现该资源，而且该资源还没有过期，就使用这一个资源，完全不会发送http请求到服务器；
• 协商缓存阶段：如果在本地缓存找到对应的资源，但是不知道该资源是否过期或者已经过期，则发一个http请求到服务器,然后服务器判断这个请求，如果请求的资源在服务器上没有改动过，则返回304，让浏览器使用本地找到的那个资源；
• 缓存失败阶段：当服务器发现请求的资源已经修改过，或者这是一个新的请求(在本来没有找到资源)，服务器则返回该资源的数据，并且返回200， 当然这个是指找到资源的情况下，如果服务器上没有这个资源，则返回404。

 

协商缓存阶段

Last-Modified & if-modified-since

Last-Modified与If-Modified-Since是一对报文头，属于http 1.0。

last-modified是WEB服务器认为对象的最后修改时间，比如文件的最后修改时间，动态页面的最后产生时间。

ETag & If-None-Match

ETag与If-None-Match是一对报文，属于http 1.1。

ETag可以用来解决这种问题。ETag是一个文件的唯一标志符。就像一个哈希或者指纹，每个文件都有一个单独的标志，只要这个文件发生了改变，这个标志就会发生变化。

ETag机制类似于乐观锁机制，如果请求报文的ETag与服务器的不一致，则表示该资源已经被修改过来，需要发最新的内容给浏览器。

同时使用这两个报文头，在完全匹配If-Modified-Since和If-None-Match即检查完修改时间和Etag之后，如都与服务器的相符，服务器返回304，否则，发送最新内容给浏览器。

Etag/lastModified过程如下：

1.客户端请求一个页面（A）。

2.服务器返回页面A，并在给A加上一个Last-Modified/ETag。

3.客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。

4.客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。

5.服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。

304：通过If-Modified-Since If-Match判断资源是否修改，如未修改则返回304，发生了一次请求，但请求内容长度为0，节省了带宽。 如果有多台负载均衡的服务器，不同服务器计算出的Etag可能不同，这样就会造成资源的重复加载。

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

1、一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；

2、某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；

3、某些服务器不能精确的得到文件的最后修改时间。

其他标签

Content-Length：尽管并没有在缓存中明确涉及，Content-Length头部在设置缓存策略时很重要。某些软件如果不提前获知内容的大小以留出足够空间，则会拒绝缓存该内容。

Vary：缓存系统通常使用请求的主机和路径作为存储该资源的键。当判断一个请求是否是请求同样内容时，Vary头部可以被用来提醒缓存系统需要注意另一个附加头部。它通常被用来告诉缓存系统同样注意Accept-Encoding头部，以便缓存系统能够区分压缩和未压缩的内容。

总结

1. 缓存开关是： pragma， cache-control。
2. 缓存校验有：Expires，Last-Modified，etag。
3. 从状态码的角度来看，它们的关系如下图：

 

4，cache-control各个值的关系：

 

5.浏览器中的操作对缓存的影响:

• 强制刷新 – 当按下ctrl+F5来刷新页面的时候, 浏览器将绕过各种缓存(本地缓存和协商缓存), 直接让服务器返回最新的资源;
• 普通刷新 – 当按下F5来刷新页面的时候,浏览器将绕过本地缓蹲来发送请求到服务器, 此时, 协商缓存是有效的
• 回车或转向 – 当在地址栏上输入回车或者按下跳转按钮的时候, 所有缓存都生效

 

浏览器刷新

撰写这篇文章的过程中，Harttle 使用了很多 Chrome 浏览器的截图。 如果你使用浏览器调试，可能也需要了解刷新按钮的行为。

正常重新加载

按下刷新按钮或快捷键（在 MacOS 中是 Cmd+R）会触发浏览器的“正常重新加载”（normal reload）， 此时浏览器会执行一次 Conditional GET。 Cache-Control 等缓存头字段会被忽略，并且带If-None-Match, If-Modified-Since等头字段。 此时服务器总会收到一次 HTTP GET 请求。 在 Chrome 中按下刷新，浏览器还会带如下请求头：

Cache-Control:max-age=0

注意：在地址栏重新输入当前页面地址并按下回车也会当做刷新处理， 这意味着只有从新标签页或超链接打开时，才能观察到直接使用硬盘缓存的情况。

强制重新加载

在 Chrome 中按下 Cmd+Shift+R （MacOS）可以触发强制重新加载（Hard Reload）， 此时包括页面本身在内的所有资源都不会使用缓存。 浏览器直接发送 HTTP 请求且不带任何条件请求字段。

 

 

参考

• https://www.cnblogs.com/ysk123/p/13179562.html
• https://blog.csdn.net/u012375924/article/details/82806617
• https://zrysmt.github.io/2016/09/27/HTTP%E5%8D%8F%E8%AE%AE%E5%AE%9E%E8%B7%B5%E7%AF%87–%E6%B5%8F%E8%A7%88%E5%99%A8%E7%BC%93%E5%AD%98%E6%80%BB%E7%BB%93%E3%80%81%E5%88%A9%E7%94%A8Fiddler%E5%92%8Capache%E6%A8%A1%E6%8B%9F/
• https://cloud.tencent.com/developer/article/1015811
• https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control