前端网络高级篇（三）浏览器缓存

浏览器缓存有多种形式，持久化或者会话存储。以chrome为例，打开调试面板，找到Application选项卡，就可以看到它所支持的各种缓存模式 缓存方式 详解 使用情况 http缓存 分为强缓存（200）和协商缓存（304），文章后面有详细介绍 强烈推荐 localstorge 本地缓存单个域名下有大小限制（最大5M）同一域名多个页面共享 推荐 sessionstorage 本地缓存页面关闭时清空 - cookie 不支持跨域（同localstorge）可通过设置domain和path实现共享域名分为session cookie（关闭浏览器清空）和持久性cookie（定义有效期）httponly设置为true时，JS无法获取cookie值常用于身份验证（逐渐被token替代） - webSQL 非HTML5规范，是一种特定的浏览器特性集成在浏览器中的本地数据库类似NoSQL数据库 不推荐 indexDB HTML5规范50M限制浏览器支持情况不佳 推荐-还需等等 Application Cache 通过manifest配置文件在本地有选择性的存储JS/CSS/图片等静态资源存储大小：5M静态资源必须和HTML文件同源逐渐被Service Worker替代 不推荐 Cache Storage ServiceWorker 规范中定义的离线方案设置window全局内置对象caches浏览器兼容性较差 推荐-还需等等 下面，重点介绍HTTP缓存。 1. HTTP缓存 一般，浏览器只对GET请求开启缓存。HTTP缓存存在于浏览器和Web代理中。当然在服务器内部，也存在着各种缓存。代理缓存和服务器缓存不予关心。 image HTTP缓存分为两大类： 强缓存：浏览器直接从自己的缓存中读取资源，不会发请求到服务器； 协商缓存：当强缓存没有命中的时候，浏览器一定会发送一个请求到服务器，通过服务器端依据资源的另外一些http header验证这个资源是否命中协商缓存，如果协商缓存命中，服务器会将这个请求返回，但是不会返回这个资源的数据，而是告诉客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中去加载这个资源； 两者的区别：强缓存不发请求到服务器，协商缓存会发请求到服务器。 两者的共同点：都是从客户端缓存中加载资源。 我们经常会刷新浏览器，不同的刷新方式对缓存有不同影响： 当ctrl+f5强制刷新网页时，直接从服务器加载，跳过强缓存和协商缓存； 当f5刷新网页时，跳过强缓存，但是会检查协商缓存； 协商缓存并非是一种被强缓存“低级”的策略，对于一些特殊的应用场景或资源，协商缓存优于强缓存。 比如，单页面项目中，每次发布JS和CSS文件都可能发生变化（通过在文件名上加hash来指定变化），那么，必须保证每次请求到的HTML文件必须是最新的。为了便于服务器解析和网站地址的唯一性，我们又不能在HTML文件上应用hash指纹。在这种场景下，就只能使用协商缓存了。 2. 强缓存 强缓存是利用Expires或者Cache-Control这两个http response header实现的，它们都用来表示资源在客户端缓存的有效期。 当浏览器对某个资源的请求命中了强缓存时，返回的http状态为200。在chrome的开发者工具的network里面size会显示为from cache。 image 问题：如何管理强缓存呢？ 答案：可以在在web服务器上配置，或者通过代码方式，在web服务器返回响应中配置。 问题：如何清除强缓存呢？ 答案：有几种方案可以选。 ctrl+F5 浏览器隐身模式 chrome在network标签下禁止缓存 在开发阶段，给资源加上一个动态的参数，如css/index.css?v=0.0001，由于每次资源的修改都要更新引用的位置，同时修改参数的值。 如果缓存问题出现在ajax请求中，最有效的解决办法就是ajax的请求地址追加随机数； 2.1 强缓存：Expires Expires是http1.0提出的一个表示资源过期时间的header，它描述的是一个绝对时间，由服务器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，它的缓存原理是: 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone header加上Expires属性，如： image 浏览器在接收到这个资源后，会把这个资源连同所有response header一起缓存下来； 浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，拿出它的Expires跟当前的请求时间比较，如果请求时间在Expires指定的时间之前，就能命中缓存，否则就不行。 如果缓存没有命中，浏览器直接从服务器加载资源时，Expires Header在重新加载的时候会被更新。 缺点: 由于它是服务器返回的一个绝对时间，在服务器时间与客户端时间相差较大时，缓存管理容易出现问题。 比如随意修改下客户端时间，就能影响缓存命中的结果。 2.2 强缓存：Cache-Control:max-age http1.1的时候，提出了一个新的header：Cache-Control，这是一个相对时间，在配置缓存的时候，以秒为单位，用数值表示，如：Cache-Control:max-age=315360000，它的缓存原理是： 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone header加上Cache-Control属性，如： image 浏览器在接收到这个资源后，会把这个资源连同所有response header一起缓存下来； 浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，根据它第一次的请求时间和Cache-Control设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行。 如果缓存没有命中，浏览器直接从服务器加载资源时，Cache-Control Header在重新加载的时候会被更新。 优点： Cache-Control描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断， 所以相比较Expires，Cache-Control的缓存管理更有效，安全一些。 如果同时启用Expires和Cache-Control， Cache-Control优先级高于Expires。 [图片上传失败...(image-617dee-1591709109797)] 3. 协商缓存 当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的http状态为304并且会显示一个Not Modified的字符串。 image image 协商缓存是利用的是Last-Modified，If-Modified-Since或者ETag、If-None-Match这两对Header来管理的。 3.1 协商缓存 Last-Modified,If-Modified-Since 1). 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone header加上Last-Modified属性（表示这个资源在服务器上的最后修改时间）： image 2). 浏览器再次跟服务器请求这个资源时，在request header上加上If-Modified-Since属性（该值就是上一次请求时返回的Last-Modified的值）： image 3). 服务器再次收到资源请求时，根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。 当服务器返回304 Not Modified的响应时，response header中不会再添加Last-Modified，因为既然资源没有变化，那么Last-Modified也就不会改变，这是服务器返回304时的response essay-header： image 4). 浏览器收到304的响应后，就会从缓存中加载资源。 5). 如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified Header在重新加载的时候会被更新，下次请求时，If-Modified-Since会启用上次返回的Last-Modified值。 缺点: 和Expire类似，一般来说，在没有调整服务器时间和篡改客户端缓存的情况下，这两个essay-header配合起来管理协商缓存是非常可靠的， 但是有时候也会服务器上资源其实有变化，但是最后修改时间却没有变化的情况，就会影响协商缓存的可靠性。 3.2 协商缓存 ETag, If-None-Match 1). 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone header加上ETag。 ETag是服务器根据当前请求的资源生成的一个唯一标识。 这个唯一标识是一个字符串，只要资源有变化这个串就不同，跟最后修改时间没有关系。 image 2). 浏览器再次跟服务器请求这个资源时，在request header上加上If-None-Match（值就是上一次请求时返回的ETag的值）。 3). 服务器再次收到资源请求时，根据浏览器传过来If-None-Match和然后再根据资源生成一个新的ETag，如果这两个值相同就说明资源没有变化，否则就是有变化； 如果没有变化则返回304 Not Modified，但是不会返回资源内容； 如果有变化，就正常返回资源内容。 与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。 image 如上例中所示，在使用了If-None-Match之后，可以更加准确的更新文件缓存时间。 但是，Etag 的生成过程需要服务器额外付出开销，会影响服务端的性能，这是它的弊端。因此启用 Etag 需要我们审时度势。 Etag 并不能替代 Last-Modified，它只能作为 Last-Modified 的补充和强化存在。 Etag 在感知文件变化上比 Last-Modified 更加准确，优先级也更高。当 Etag 和 Last-Modified 同时存在时，以 Etag 为准。 4. 响应头Cache-Control 每个资源都可以通过Http头Cache-Control来定义自己的缓存策略，Cache-Control控制谁在什么条件下可以缓存响应以及可以缓存多久。 最快的请求是不必与服务器进行通信的请求：通过响应的本地副本，我们可以避免所有的网络延迟以及数据传输的数据成本。为此，HTTP 规范允许服务器返回一系列不同的 Cache-Control 指令，控制浏览器或者其他中继缓存如何缓存某个响应以及缓存多长时间。 Cache-Control 头在 HTTP/1.1 规范中定义，取代了之前用来定义响应缓存策略的头（例如 Expires）。当前的所有浏览器都支持 Cache-Control，因此，使用它就够了。 Cache-Control中设置的常用指令如下： max-age：该指令指定从当前请求开始，允许获取的响应被重用的最长时间（单位为秒。例如：Cache-Control:max-age=60表示响应可以再缓存和重用 60 秒。需要注意的是，在max-age指定的时间之内，浏览器不会向服务器发送任何请求，包括验证缓存是否有效的请求，也就是说，如果在这段时间之内，服务器上的资源发生了变化，那么浏览器将不能得到通知，而使用老版本的资源。所以在设置缓存时间的长度时，需要慎重。 public和private：如果设置了public，表示该响应可以在浏览器或者任何中继的Web代理中缓存，public是默认值，即Cache-Control:max-age=60等同于Cache-Control:public, max-age=60。 no-cache：如果服务器在响应中设置了no-cache，即Cache-Control:no-cache，那么浏览器在使用缓存的资源之前，必须先与服务器确认返回的响应是否被更改，如果资源未被更改，可以避免下载。这个验证之前的响应是否被修改，就是通过上面介绍的请求头If-None-match和响应头ETag来实现的。 设置了no-cache之后，并不是说浏览器就不再缓存数据，只是浏览器在使用缓存数据时，需要先确认一下数据是否还跟服务器保持一致。 no-store：如果服务器在响应中设置了no-store，即Cache-Control:no-store，那么浏览器和任何中继的Web代理，都不会存储这次相应的数据。当下次请求该资源时，浏览器只能重新请求服务器，重新从服务器读取资源。 5. HTTP缓存小结 在HTTP1.1协议下，HTTP缓存流程如下所示。 image 微信公众号：

本文章由javascript技术分享原创和收集