1.1、浏览器在加载资源时，先根据这个资源的一些http header判断它是否命中强缓存，强缓存如果命中，浏览器直接从自己的缓存中读取资源，不会发要求到做事器。比如某个css文件，如果浏览器在加载它所在的网页时，这个css文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个css，连要求都不会发送到网页所在做事器。
1.2、当强缓存没有命中的时候，浏览器一定会发送一个要求到做事器，通过做事器端依据资源的其余一些http header验证这个资源是否命中协商缓存，如果协商缓存命中，做事器会将这个要求返回，但是不会返回这个资源的数据，而是见告客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中去加载这个资源；
1.3、强缓存与协商缓存的共同点是：如果命中，都是从客户端缓存中加载资源，而不是从做事器加载资源数据；差异是：强缓存不发要求到做事器，协商缓存会发要求到做事器。
1.4、当协商缓存也没有命中的时候，浏览器直接从做事器加载资源数据。
2、强缓存的事理
当浏览器对某个资源的要求命中了强缓存时，返回的http状态为200，如在chrome的开拓者工具的network里面size会显示为from cache，淘宝的首页里就有很多静态资源配置了强缓存，用浏览器打开几次往后就可以看到有不少要求便是从缓存中加载的，强缓存是利用Expires或者Cache-Control这两个http response header实现的，它们都用来表示资源在客户端缓存的有效期。
2.1、Expires是http提出的一个表示资源过期韶光的header，它描述的是一个绝对韶光，由做事器返回，用GMT格式的字符串表示，如Expires:Thu, 31 Dec 2037 23:55:55 GMT，它的缓存事理是：
浏览器第一次跟做事器要求一个资源，做事器在返回这个资源的同时，在respone的header加上Expires的header如：
浏览器在吸收到这个资源后，会把这个资源连同所有response header一起缓存下来（以是缓存命中的要求返回的header并不是来自做事器，而是来自之前缓存的header）。
浏览器再要求这个资源时，先从缓存中探求，找到这个资源后，拿出它的Expires跟当前的要求韶光比较，如果要求韶光在Expires指定的韶光之前，就能命中缓存，否则就弗成。
如果缓存没有命中，浏览器直接从做事器加载资源时，Expires Header在重新加载的时候会被更新。
2.2、Expires是较老的强缓存管理header，由于它是做事器返回的一个绝对韶光，在做事器韶光与客户端韶光相差较大时，缓存管理随意马虎涌现问题，比如随意修正下客户端韶光，就能影响缓存命中的结果。以是提出了一个新的header，便是Cache-Control，这是一个相对韶光，在配置缓存的时候，以秒为单位，用数值表示，如Cache-Control:max-age=315360000，它的缓存事理是：
浏览器第一次跟做事器要求一个资源，做事器在返回这个资源的同时，在respone的header加上Cache-Control的header，如图：
浏览器在吸收到这个资源后，会把这个资源连同所有response header一起缓存下来；
浏览器再要求这个资源时，先从缓存中探求，找到这个资源后，根据它第一次的要求韶光和Cache-Control设定的有效期，打算出一个资源过期韶光，再拿这个过期韶光跟当前的要求韶光比较，如果要求韶光在过期韶光之前，就能命中缓存，否则就弗成。
如果缓存没有命中，浏览器直接从做事器加载资源时，Cache-Control Header在重新加载的时候会被更新。
Cache-Control描述的是一个相对韶光，在进行缓存命中的时候，都是利用客户端韶光进行判断，以是比较较Expires，Cache-Control的缓存管理更有效，安全一些。这两个header可以只启用一个，也可以同时启用，当response header中，Expires和Cache-Control同时存在时，Cache-Control优先级高于Expires
3、强缓存的管理
在实际运用中会碰到须要强缓存的场景和不须要强缓存的场景，常日有2种办法来设置是否启用强缓存：
通过代码的办法，在web做事器返回的相应中添加Expires和Cache-Control Header；
通过配置web做事器的办法，让web做事器在相应资源的时候统一添加Expires和Cache-Control Header。
在开拓的时候不会专门去配置强缓存，而浏览器又默认会缓存图片，css和js等静态资源，以是开拓环境下常常会由于强缓存导致资源没有及时更新而看不到最新的效果，办理这个问题的方法有很多，常用的有以下几种：
直接ctrl+f5，这个办法能办理页面直接引用的资源更新的问题。
利用浏览器的隐私模式开拓。
如果用的是chrome，可以f12在network那里把缓存给禁掉（这是个非常有效的方法）。
在开拓阶段，给资源加上一个动态的参数，如css/index.css?v=0.0001，由于每次资源的修正都要更新引用的位置，同时修正参数的值，以是操作起来不是很方便，除非你是在动态页面比如jsp里开拓就可以用做事器变量来办理（v=${sysRnd}），或者你能用一些前真个构建工具来处理这个参数修正的问题。
如果资源引用的页面，被嵌入到了一个iframe里面，可以在iframe的区域右键单击重新加载该页面，以chrome为例。
还有一种情形便是动态设置iframe的src时，有可能也会由于缓请安题，导致看不到最新的效果，这时候在要设置的src后面添加随机数也能办理问题。
如果用的是grunt和gulp这种前端工具开拓，通过它们的插件比如grunt-contrib-connect来启动一个静态做事器，则完备不用担心开拓阶段的资源更新问题，由于在这个静态做事器下的所有资源返回的respone header中，cache-control始终被设置为不缓存。
4、强缓存的运用
强缓存是前端性能优化最有力的工具，对付有大量静态资源的网页，一定要利用强缓存，提高相应速率。常日的做法是为这些静态资源全部配置一个超时时间超长的Expires或Cache-Control，这样用户在访问网页时，只会在第一次加载时从做事器要求静态资源，其它时候只要缓存没有失落效并且用户没有逼迫刷新的条件下都会从自己的缓存中加载。
强缓存常日都是针对静态资源利用，动态资源须要慎用，除了做事端页面可以看作动态资源外，那些引用静态资源的html也可以看作是动态资源，如果这种html也被缓存，当这些html更新之后，可能就没有机制能够关照浏览器这些html有更新，尤其是前后端分离的运用里，页面都是纯html页面，每个访问地址可能都是直接访问html页面，这些页面常日不加强缓存，以担保浏览器访问这些页面时始终要求做事器最新的资源。
5、协商缓存的事理
当浏览器对某个资源的要求没有命中强缓存，就会发一个要求到做事器，验证协商缓存是否命中，如果协商缓存命中，要求相应返回的http状态为304并且会显示一个Not Modified的字符串，如你打开京东的首页，查看network，可以看到有不少要求便是命中了协商缓存的。
查看单个要求的Response Header，也能看到304的状态码和Not Modified的字符串，只要看到如下图就可解释这个资源是命中了协商缓存，然后从客户端缓存中加载的，而不是做事器最新的资源。
协商缓存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，它们是用Header来管理的，事理是：
1）浏览器第一次跟做事器要求一个资源，做事器在返回这个资源的同时，在respone的header加上Last-Modified的header，这个header表示这个资源在做事器上的末了修正韶光。
2）浏览器再次跟做事器要求这个资源时，在request的header上加上If-Modified-Since的header，这个header的值便是上一次要求时返回的Last-Modified的值。
3）做事器再次收到资源要求时，根据浏览器传过来If-Modified-Since和资源在做事器上的末了修正韶光判断资源是否有变革，如果没有变革则返回304 Not Modified，但是不会返回资源内容；如果有变革，就正常返回资源内容。当做事器返回304 Not Modified的相应时，response header中不会再添加Last-Modified的header，由于既然资源没有变革，那么Last-Modified也就不会改变，这是做事器返回304时的response header。
4）浏览器收到304的相应后，就会从缓存中加载资源。
5）如果协商缓存没有命中，浏览器直接从做事器加载资源时，Last-Modified Header在重新加载的时候会被更新，下次要求时，If-Modified-Since会启用上次返回的Last-Modified值。
【Last-Modified，If-Modified-Since】都是根据做事器韶光返回的header，一样平常来说，在没有调度做事器韶光和修改客户端缓存的情形下，这两个header合营起来管理协商缓存是非常可靠的，但是有时候也会做事器上资源实在有变革，但是末了修正韶光却没有变革的情形，而这种问题又很不随意马虎被定位出来，而当这种情形涌现的时候，就会影响协商缓存的可靠性。以是就有了其余一对header来管理协商缓存，这对header便是【ETag、If-None-Match】。它们的缓存管理办法是：
1）浏览器第一次跟做事器要求一个资源，做事器在返回这个资源的同时，在respone的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返回，纵然这个ETag跟之前的没有变革。
4）浏览器收到304的相应后，就会从缓存中加载资源。
6、协商缓存的管理
协商缓存跟强缓存不一样，强缓存不发要求到做事器，以是有时候资源更新了浏览器还不知道，但是协商缓存会发要求到做事器，以是资源是否更新做事器肯定知道。大部分web做事器都默认开启协商缓存，而且是同时启用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:
如果没有协商缓存，每个到做事器的要求，就都得返回资源内容，这样做事器的性能会极差，【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一样平常都是同时启用，这是为了处理Last-Modified不可靠的情形。
分布式系统里多台机器间文件的Last-Modified必须保持同等，以免负载均衡到不同机器导致比对失落败，分布式系统只管即便关闭掉ETag(每台机器天生的ETag都会不一样）。
协商缓存须要合营强缓存利用，除了Last-Modified这个header，还有强缓存的干系header，如上图，由于如果不启用强缓存的话，协商缓存根本没故意义。
7. 浏览器行为对缓存的影响
如果资源已经被浏览器缓存下来，在缓存失落效之前，再次要求时，默认会先检讨是否命中强缓存，如果强缓存命中则直接读取缓存，如果强缓存没有命中则发要求到做事器检讨是否命中协商缓存，如果协商缓存命中，则见告浏览器还是可以从缓存读取，否则才从做事器返回最新的资源，这是默认的处理办法。
