码不停息

# 请求缓存

  • 强缓存
  • 协商缓存
  • 缓存位置

# 强缓存

浏览器中的缓存作用分为两种情况，一种是需要发送HTTP请求，一种是不需要发送。 首先是检查强缓存，这个阶段不需要发送HTTP请求 在HTTP1.1中，采用了一个非常关键的字段：Cache-Control。这个字段也是存在于 它和Expires本质的不同在于它并没有采用具体的过期时间点这个方式，而是采用过期时长来控制缓存，对应的字段是max-age。比如这个例子:

Cache-Control:max-age=3600
//3600 秒，也就是一个小时之内可以直接使用缓存。

Cache-Control 属性有:

  • private： 这种情况就是只有浏览器能缓存了，中间的代理服务器不能缓存。
  • no-cache: 跳过当前的强缓存，发送HTTP请求，即直接进入协商缓存阶段。
  • no-store：非常粗暴，不进行任何形式的缓存。
  • s-maxage：这和max-age长得比较像，但是区别在于s-maxage是针对代理服务器的缓存时间 当然，还存在一种情况，当资源缓存时间超时了，也就是强缓存失效了，接下来怎么办？没错，这样就进入到第二级屏障——协商缓存 了

# 协商缓存

强缓存失效之后，浏览器在请求头中携带相应的缓存tag来向服务器发请求，由服务器根据这个tag，来决定是否使用缓存，这就是协商缓存。 具体来说，这样的缓存tag分为两种: Last-Modified 和 ETag。这两者各有优劣，并不存在谁对谁有绝对的优势，跟上面强缓存的两个 tag 不一样。

  • Last-Modified 即最后修改时间。在浏览器第一次给服务器发送请求后，服务器会在响应头中加上这个字段。 浏览器接收到后，如果再次请求，会在请求头中携带If-Modified-Since字段，这个字段的值也就是服务器传来的最后修改时间。 服务器拿到请求头中的If-Modified-Since的字段后，其实会和这个服务器中该资源的最后修改时间对比:

如果请求头中的这个值小于最后修改时间，说明是时候更新了。返回新的资源，跟常规的HTTP请求响应的流程一样。 否则返回304，告诉浏览器直接用缓存。

  • ETag ETag 是服务器根据当前文件的内容，给文件生成的唯一标识，只要里面的内容有改动，这个值就会变。服务器通过响应头把这个值给浏览器。 浏览器接收到ETag的值，会在下次请求时，将这个值作为If-None-Match这个字段的内容，并放到请求头中，然后发给服务器。 服务器接收到If-None-Match后，会跟服务器上该资源的ETag进行比对:

如果两者不一样，说明要更新了。返回新的资源，跟常规的HTTP请求响应的流程一样。 否则返回304，告诉浏览器直接用缓存。

  • 两者对比

在精准度上，ETag优于Last-Modified。优于 ETag 是按照内容给资源上标识，因此能准确感知资源的变化。而 Last-Modified 就不一样了，它在一些特殊的情况并不能准确感知资源变化，主要有两种情况:

编辑了资源文件，但是文件内容并没有更改，这样也会造成缓存失效。 Last-Modified 能够感知的单位时间是秒，如果文件在 1 秒内改变了多次，那么这时候的 Last-Modified 并没有体现出修改了。

在性能上，Last-Modified优于ETag，也很简单理解，Last-Modified仅仅只是记录一个时间点，而 Etag需要根据文件的具体内容生成哈希值。

另外，如果两种方式都支持的话，服务器会优先考虑ETag

# 缓存位置

前面我们已经提到，当强缓存命中或者协商缓存中服务器返回304的时候，我们直接从缓存中获取资源。那这些资源究竟缓存在什么位置呢？ 浏览器中的缓存位置一共有四种，按优先级从高到低排列分别是：

  • Service Worker
  • Memory Cache
  • Disk Cache
  • Push Cache

# 浏览器缓存类型及区别

Cookie 最开始被设计出来其实并不是来做本地存储的，而是为了弥补HTTP在 状态管理上的不足。 HTTP 协议是一个无状态协议，客户端向服务器发请求，服务器返回响应，故事就这样结束了，但是下次发请求如何让服务端知道客户端是谁呢？ 这种背景下，就产生了 Cookie.
Cookie 本质上就是浏览器里面存储的一个很小的文本文件，内部以键值对的方式来存储(在chrome开发者面板的Application这一栏可以看到)。向同一个域名下发送请求，都会携带相同的 Cookie，服务器拿到 Cookie 进行解析，便能拿到客户端的状态。 Cookie 的作用很好理解，就是用来做状态存储的，但它也是有诸多致命的缺陷的：

  • 容量缺陷。Cookie 的体积上限只有4KB，只能用来存储少量的信息。
  • 性能缺陷。Cookie 紧跟域名，不管域名下面的某一个地址需不需要这个 Cookie ，请求都会携带上完整的 Cookie，这样随着请求数的增多，其实会造成巨大的性能浪费的，因为请求携带了很多不必要的内容。
  • 安全缺陷。由于 Cookie 以纯文本的形式在浏览器和服务器中传递，很容易被非法用户截获，然后进行一系列的篡改，在 Cookie 的有效期内重新发送给服务器，这是相当危险的。另外，在HttpOnly为 false 的情况下，Cookie 信息能直接通过 JS 脚本来读取。

# localStorage

localStorage有一点跟Cookie一样，就是针对一个域名，即在同一个域名下，会存储相同的一段localStorage, 特点

  • 容量。localStorage 的容量上限为5M，相比于Cookie的 4K 大大增加。当然这个 5M 是针对一个域名的，因此对于一个域名是持久存储的。
  • 只存在客户端，默认不参与与服务端的通信。这样就很好地避免了 Cookie 带来的性能问题和安全问题。
  • 接口封装。通过localStorage暴露在全局，并通过它的 setItem 和 getItem等方法进行操作，非常方便。

# sessionStorage

sessionStorage和localStorage 基本一样 但有一个本质的区别，那就是前者只是会话级别的存储，并不是持久化存储。会话结束，也就是页面关闭，这部分sessionStorage就不复存在了

# IndexedDB

IndexedDB是运行在浏览器中的非关系型数据库, 本质上是数据库，绝不是和刚才WebStorage的 5M 一个量级，理论上这个容量是没有上限的。 接着我们来分析一下IndexedDB的一些重要特性，除了拥有数据库本身的特性，比如支持事务，存储二进制数据，还有这样一些特性需要格外注意： 键值对存储。内部采用对象仓库存放数据，在这个对象仓库中数据采用键值对的方式来存储。 异步操作。数据库的读写属于 I/O 操作, 浏览器中对异步 I/O 提供了支持。 受同源策略限制，即无法访问跨域的数据库。

← 浏览器执行顺序 →