浏览器缓存知识

浏览器缓存，就是客户端缓存。

浏览器缓存基本认识

它分为强缓存和协议缓存

浏览器在加载资源时，先根据这个资源的一些http header判断它是否命中强缓存，强缓存如果命中，浏览器直接从自己的缓存汇总读取资源，不会发送请求到服务器。
当强缓存没有命中的时候，浏览器一定会发送i个请求到服务器，通过服务器端一句资源的另外一些http header验证这个资源是否命中协商缓存，如果协商缓存命中，服务器将这个请求返回，但是不会返回这个资源的数据，而是告诉客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中加载这个资源。
强缓存和协商缓存的共同点：如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；区别是：强缓存不发请求到服务器，协商缓存会发请求到服务器。
当协商缓存也没有命中的时候，浏览器直接从服务器加载资源数据。

强缓存的原理

当浏览器对某个资源的请求命中了强缓存时，返回的http状态为200，在chrome的开发者工具的network里面size会显示form cache。强缓存是利用expires或者Cache-Control 这两个http response header实现的，他们都用来表示资源在客户端缓存的有效期

Expries 是 http1.0 提出的一个表示资源过期时间的header，他描述的是一个绝对是间，由服务器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT；
它的缓存原理是：
- 浏览器第一个跟服务器请求一个资源，服务器在返回这个资源的同时，在response的header加上Expires的header，如果Expires:Thu, 31 Dec 2037 23:55:55 GMT；
- 浏览器在接受到这个资源后，会把这个资源连同所有的response header一起缓存下来（所以缓存命中的请求返回header并不是来自服务器，二十来自之前缓存的header）。
- 浏览器再请求这个资源是，先从缓存中寻找，找到这个资源后，拿出他的Expires跟当前的求情时间比较，如果请求时间在Expires指定的时间之前，就能命中缓存，否则不可以。
- 如果缓存没有命中，浏览器直接从服务器加载资源是，Expires header在重新加载的时候会被更新。

Expires是较老的强缓存管理header，由于他是服务器返回一个绝对是间，在服务器事件与客户段时间相差较大时，缓存管理容易出现问题。比如随意修改客户端时间，就能影响缓存命中的结果。所以在http1.1的时候，提出了一个新的header。就是Cache-Control。这是一个相对时间，在配置缓存的时候，以秒为单位，用数值表示。如：Cache-Control:max-age=315360000；
它的缓存原理是：
- 浏览器第一次跟服务器请求一个资源服务器在返回这个资源的同时，在response的header加上Cache-Control的header，格式如上。
- 浏览器在接收到这个资源后，会吧这个资源连同所有的response header一起缓存下来。
- 浏览器再请求这个资源是，先从缓存中寻找，找到这个资源后，根据他第一次的请求时间和Cache-Control设定的有效期，计算出一个时间，在拿这个过期时间跟当前的时间对比，如果请求时间在过期时间之前就能命中缓存，否则不能。
- 如果缓存没有命中，浏览器直接从服务器加载资源时，Cache-Control header在重新加载的时候会被更新。

Cache-Control 描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断，所以相对Expries，管理更有效，安全一些。
这两个header可以启用一个，也可以同时启用。当response header中同时存在Expires和Cache-Control的时候，Cache-Control的优先级高于Expries。

强缓存的管理

通过代码的方式，在web服务器返回响应中添加Expires和Cache-Control Header；
通过配置web服务器的方式，让web服务器在响应资源的时候，同一添加Expires和Cache-Control header。

get小技巧：
由于在开发的时候不会专门去配置强缓存，而浏览器又默认会缓存图片，css和js等静态资源，所以开发环境下经常会因为强缓存导致资源没有及时更新而看不到最新的效果，解决这个问题的方法有很多，常用的有以下几种：

直接使用Ctrl+f5，这个办法能解决页面直接引用的资源更新的问题。
使用浏览器的隐私模式开发；
如果是chrome，可以f12network那里把缓存给禁掉(这是非常有效的方法)
在开发阶段，给资源加上一个时间戳，由于每次资源的修改都要更新引用的位置，同时修改参数的值，所以操作起来不是很方便，除非你是在动态页面比如jsp里开发就可以用服务器变量来解决（v=${sysRnd}），或者你能用一些前端的构建工具来处理这个参数修改的问题；
如果资源引用的页面，被嵌入到了一个iframe里边，可以在iframe的区域邮件单机重新加载该页面。
如果缓存问题出现在ajax请求中，最有效的解决办法就是ajax的请求地址追加时间戳；
还有一种情况就是动态设置iframe的src时，有可能也会因为缓存问题，导致看不到最新的效果，这时候在要设置的src后面添加随机数也能解决问题；
如果你用的是grunt和gulp这种前端工具开发，通过它们的插件比如grunt-contrib-connect来启动一个静态服务器，则完全不用担心开发阶段的资源更新问题，因为在这个静态服务器下的所有资源返回的respone header中，cache-control始终被设置为不缓存：

强缓存的应用

强缓存是前端性能优化最有力的工具，没有之一。队医邮大量静态资源的网页，一定要利用强缓存提高响应速度。通常的做法是，为这些静态资源全部配置一个超时时间超长的Expries或Cache-Control，这样用户在访问网页时，只会在第一次加载时从服务器请求静态资源，其他的时候只要缓存设有失效并且用户没有强制刷新的条件下都会从自己的缓存中加载。
然而这种缓存配置方式会带来一个新的问题，就是发布时资源更新的问题，比如某一张图片，在用户访问第一个版本的时候已经缓存到了用户的电脑上，当网站发布新版本，替换了这个图片时，已经访问过第一个版本的用户由于缓存的设置，导致在默认的情况下不会请求服务器最新的图片资源，除非他清掉或禁用缓存或者强制刷新，否则就看不到最新的图片效果。

强缓存还有一点需要注意的是，通常都是针对静态资源使用，动态资源需要慎用，除了服务端页面可以看作动态资源外，那些引用静态资源的html也可以看作是动态资源，如果这种html也被缓存，当这些html更新之后，可能就没有机制能够通知浏览器这些html有更新，尤其是前后端分离的应用里，页面都是纯html页面，每个访问地址可能都是直接访问html页面，这些页面通常不加强缓存，以保证浏览器访问这些页面时始终请求服务器最新的资源。

协商缓存的原理

当浏览器对某个资源的请求没有命中强缓存，就会发送一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的http为304并且会显示一个not modified 的字符串。
单个请求的response header，也能看到304的状态吗和not modified的字符串，只要是看到这个就可说明这个资源是命中了协商缓存，然后客户端缓存中加载的，而不是服务器最新资源；
协商缓存利用的是【Last-Modified，if-Modified-Since】和【ET阿哥、if-Node-Match】这两对Header来管理的。
【Last-Modified，if-Modified-Since】的控制缓存原理是：

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

【Last-Modified，If-Modified-Since】都是根据服务器时间返回的header，一般来说，在没有调整服务器时间和篡改客户端缓存的情况下，这两个header配合起来管理协商缓存是非常可靠的，但是有时候也会服务器上资源其实有变化，但是最后修改时间却没有变化的情况，而这种问题又很不容易被定位出来，而当这种情况出现的时候，就会影响协商缓存的可靠性。所以就有了另外一对header来管理协商缓存，这对header就是【ETag、If-None-Match】

（1）浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在response的header加上ETag的header，这个header是服务器更具当前请求的资源生成一个唯一标识，这个唯一标识是一个字符串，只要资源有变化这个字符串就会不同，跟最后修改时间没有关系，所以能很好的补充Last-Modified的问题
（2）浏览器再次根据服务器请求这个资源时，在request的header上加上if-None-Match的header，这个header值就是上一次请求时返回的ETag的值
（3）服务器再次收到资源请求是，更具浏览器传来的if-None-Match和资源生成的一个新的Etag，如果这两个值相同就说明资源没有变化，否则就是有变化；如果没有变化则返回304 Not Modified，但是不会返回资源内容，如果有变化，就正常返回资源内容。与Last-Modified不一样的是，当服务器返回304 Not Modified的响应是，由Etag重新生成过，response header中还有这个ETag返回，即使这个rTag跟之前没有变化。
（4）浏览器收到304的响应后，就会从缓存中加载资源

协商缓存的管理

协商缓存跟强缓存不一样，强缓存不发请求到服务器，所以有时候资源更新了浏览器还不知道，但是协商缓存会发送请求到服务器，所以资源是否更新，服务器肯定知道。大部分web服务器默认开启协商缓存，而且是同时启用【Last-Modified，if-Modified-Since】和【ETag，if-None-Match】，如果没有协商缓存，每个服务器的请求就都返回资源内容，这样性能会极差。【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同时启用，这是为了处理Last-Modified不可靠的情况，但是有一种特殊情况，分布式系统尽量关闭掉ETag（每台机器生成的ETag都会不一样），协商缓存需要配合强缓存使用，你看前面这个截图中，除了Last-Modified这个header，还有强缓存的相关header，因为如果不启用强缓存的话，协商缓存根本没有意义。

浏览器行为对缓存的影响

如果资源已经被浏览器缓存下来，在缓存失效之前，再次请求时，默认会检查是否命中强缓存，如果强缓存命中则直接读取缓存，如果强缓存没有命中则发请求到服务器检查是否命中协商缓存，如果协商缓存命中，则高度浏览器还是可以从缓存中读取，否则才从服务器返回最新资源。这是默认的处理凡事，这个方式可以被浏览器以下行为改变：

当Ctrl+f5 强制刷新页面时，直接从服务器加载，跳过强缓存和协商缓存
当f5 刷新页面的时，跳过强缓存，但是会检查协商缓存