http请求 --浏览器缓存

http 请求 – 浏览器缓存

基本介绍

• 在Chrome浏览器中的控制台Network中size栏通常会有三种状态:
  a. 资源本身的大小 (如下图：197B)
  b. from memory cache (如下图：idnex.js)
  c. from disk cache (如下图：css.js)
  
  from memory cache

代表使用内存中的缓存

• from memory cache 代表使用内存中的缓存，即请求的资源是直接从内存中拿到的，不会请求服务器。
• 一般已经加载过该资源且资源已经缓存在了内存当中，当关闭该页面时，此资源就被内存释放掉了，再次重新打开相同页面时不会出现 from memory cache 的情况。
• 内存缓存具有两个特点，分别是快速读取和时效性：
• 快速读取：内存缓存会将编译解析后的文件，直接存入该进程的内存中，占据该进程一定的内存资源，以方便下次运行使用时的快速读取。
• 时效性：一旦该进程关闭，则该进程的内存则会清空。

from disk cache

代表使用的是硬盘中的缓存

• from disk cache 表示此资源是从磁盘当中取出的，也是在已经在之前的某个时间加载过该资源，不会请求服务器。但此资源不会随着该页面的关闭而释放掉，因为是存在硬盘当中的，下次打开仍会出现 from disk cache的情况。
• 硬盘缓存(from disk cache)：硬盘缓存则是直接将缓存写入硬盘文件中，读取缓存需要对该缓存存放的硬盘文件进行 I/O 操作，然后重新解析该缓存内容，读取复杂，速度比内存缓存慢。
  浏览器读取命中强缓存资源顺序为 memory —> disk
• 先去 内存 看，如果有，直接加载；
• 如果内存没有，则取 硬盘 获取；
• 如果硬盘也没有，那么就进行 网络请求；
• 加载到的 资源缓存到硬盘和内存。
  资源本身大小
• 当HTTP状态码为 200 时，资源是实实在在从服务器请求后获取得到的（不是缓存数据），该数字是资源本身的大小；
• 当HTTP状态码为 304 时，该数字是 与服务端通信报文的大小，并 不是该资源本身的大小，该资源是从本地获取的（协商缓存）

Chrome 采取措施的准则

状态	类型	说明
200	from memory cache	不请求网络资源，资源在内存当中，一般脚本、字体、图片会存在内存当中
200	from disk cache	不请求网络资源，在磁盘当中，一般非脚本会存在内存当中，如CSS等
200	资源大小数值	从服务器下载最新资源
304	报文大小	请求服务端发现资源没有更新，使用本地资源（协商缓存）

所以 样式表 一般在磁盘中，不会缓存到内存中去，因为CSS样式加载一次即可渲染出网页。但是，脚本 却可能随时会执行，如果 脚本 在磁盘当中，在执行该 脚本 需要从磁盘中取到内存当中来。这样的IO开销是比较大的，有可能会导致浏览器失去响应。因此，脚本 一般在内存中。

2、强缓存相关的header字段

强缓存上面已经介绍了，直接从缓存中获取资源而不经过服务器；与强缓存相关的header字段有两个：

1. expires，这是 http1.0 时的规范；它的值为一个绝对时间的 GMT 格式的时间字符串，如Mon, 10 Jun 2015 21:31:12 GMT，如果发送请求的时间在 expires 之前，那么本地缓存始终有效，否则就会发送请求到服务器来获取资源
2. cache-control：max-age=number，这是 http1.1 时出现的 header 信息，主要是利用该字段的 max-age 值来进行判断，它是一个相对值；资源第一次的请求时间和 Cache-Control 设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行；cache-control 除了该字段外，还有下面几个比较常用的设置值：
   • no-cache：不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在 ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
   • no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
   • public：可以被所有的用户缓存，包括终端用户和 CDN 等中间代理服务器。

• private：只能被终端用户的浏览器缓存，不允许 CDN 等中继缓存服务器对其缓存。
  注意：如果cache-control与expires同时存在的话，cache-control的优先级高于expires

3、协商缓存相关的header字段

协商缓存都是由服务器来确定缓存资源是否可用的，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问，这主要涉及到下面两组header字段，这两组搭档都是成对出现的，即第一次请求的响应头带上某个字段（Last-Modified 或者 Etag），则后续请求则会带上对应的请求字段（If-Modified-Since 或者 If-None-Match），若响应头没有 Last-Modified 或者 Etag 字段，则请求头也不会有对应的字段。

1. Last-Modified/If-Modified-Since
   二者的值都是 GMT 格式的时间字符串，具体过程：

• 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在 respone 的 header 加上Last-Modified 的 header，这个 header 表示这个资源在服务器上的最后修改时间
• 浏览器再次跟服务器请求这个资源时，在 request的header 上加上 If-Modified-Since 的 header，这个 header 的值就是上一次请求时返回的 Last-Modified 的值
• 服务器再次收到资源请求时，根据浏览器传过来 If-Modified-Since 和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回 304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。当服务器返回 304 Not Modified 的响应时，response header 中不会再添加 Last-Modified (谷歌浏览器测也会有该字段) 的 header，因为既然资源没有变化，那么 Last-Modified 也就不会改变，这是服务器返回 304时 的 response header
• 浏览器收到 304 的响应后，就会从缓存中加载资源
• 如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified 的 Header在重新加载的时候会被更新，下次请求时，If-Modified-Since 会启用上次返回的 Last-Modified值

2. Etag/If-None-Match
   这两个值是由服务器生成的每个资源的唯一标识字符串，只要资源有变化就这个值就会改变；其判断过程与Last-Modified/If-Modified-Since 类似，与 Last-Modified 不一样的是，当服务器返回 304 Not Modified 的响应时，由于 ETag 重新生成过，response header 中还会把这个 ETag 返回，即使这个 ETag 跟之前的没有变化。

4、既生Last-Modified何生Etag

你可能会觉得使用 Last-Modified 已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要 Etag呢？HTTP1.1 中 Etag 的出现主要是为了解决几个 Last-Modified 比较难解决的问题：

• 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新 GET；
  -某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since 能检查到的粒度是 s 级的，这种修改无法判断(或者说 UNIX 记录 MTIME 只能精确到秒)；
• 某些服务器不能精确的得到文件的最后修改时间。
  这时，利用 Etag 能够更加准确的控制缓存，因为 Etag 是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。
  Last-Modified 与 ETag 是可以一起使用的，服务器会优先验证 ETag，一致的情况下，才会继续比对 Last-Modified，最后才决定是否返回 304。