本文浅谈了下http缓存
文中有任何错误，欢迎批评指正
前因
在通过HTTTP协议获取网页内容的时候，下载文件的速度开销是很大的，尤其是大型的网页，而且每次的响应都需要重复的往返通信。这就导致了浏览器处理内容时间加长，也增加了流量费用。
本文主要摘抄一部分理论，具体操作可以查看参考中的链接
什么是缓存
缓存是指存储指定资源的一份拷贝，并在下次请求该资源时提供该拷贝的技术。
缓存机制
缓存是跟HTTP协议有关的，所以通过设置HTTP的报文首部字段可以指定是否需要缓存和一些其他的缓存功能。
HTTP协议中与缓存相关的首部字段
1.通用首部字段
| 字段名称 | 说明 |
|---|---|
| Cache-Control | 控制缓存的行为 |
| Pragma | http1.0的旧社会遗物，值为“no-cache”时禁用缓存 |
2.请求首部字段
| 字段名称 | 说明 |
|---|---|
| If-Match | 比较ETag是否一致 |
| If-None-Match | 比较ETag是否不一致 |
| If-Modefied-Since | 比较资源最后更新的时间是否一致 |
| If-Unmodefied-Since | 比较资源最后更新的时间是否不一致 |
3.响应首部字段
| 字段名称 | 说明 |
|---|---|
| ETag | 资源的匹配信息 |
4.实体首部字段
| 字段名称 | 说明 |
|---|---|
| Expires | http1.0的遗留物，实体主题过期的时间 |
| Last-Modefied | 资源的最后一次修改的时间 |
使用Cache-Control
在http1.0时代，使用Pragma和Expires
到了http1.1的时候，现在网站基本都是用的http1.1，增加了Cache-Control来定义缓存过期时间，若报文中同时出现了 Pragma、Expires 和 Cache-Control，会以 Cache-Control 为准。所以，使用cache-control就够了。
Cache-Control 的格式为：
"Cache-Control" ":" cache-directive
作为请求首部时，cache-directive的可选值有：
| 字段名称 | 说明 |
|---|---|
| no-cache | 告知（代理）服务器不直接使用缓存，要求向原服务器发起请求 |
| no-store | 所有内容都不会被保存到缓存或Internet临时文件中 |
| max-age=delta-seconds | 告知服务器客户端希望接收一个存在时间（Age）不大于delta-second秒的资源 |
| max-stale[=delta-seconds] | 告知（代理）服务器，客户端愿意接收一个超过缓存时间的资源，若有定义delta-seconds则为delta-seconds秒，若没有则为任意超出的时间 |
| min-fresh=delta-seconds | 告知（代理）服务器，客户端希望接收一个在小于delta-seconds秒内被更新过的资源 |
| no-transform | 告知（代理）服务器，客户端希望获取实体数据没有被转换（比如压缩）过的资源 |
| only-if-cached | 告知（代理）服务器，客户端希望获取缓存的内容（若有），而不用向原服务器发送请求 |
| cache-extension | 自定义扩展值，若服务器不识别该值将被忽略掉 |
作为响应首部时，cache-directive的可选值有：
| 字段名称 | 说明 |
|---|---|
| public | 表明任何情况下都得缓存该资源（即使是需要HTTP认证的资源） |
| Private[="field-name"] | 表明返回报文中全部或部分（若指定了field-name则为field-name的字段数据）仅开放给某些用户（服务器指定的share-user，如代理服务器）做缓存使用，其他用户则不能换粗这些数据 |
| no-cache | 不直接使用缓存，要求向服务区发起（新鲜度校验）请求 |
| no-store | 所有内容都不会被保存到缓存或Internet临时文件中 |
| no-transform | 告知客户端缓存文件是不得对实体数据做任何改变 |
| only-if-cached | 告知（代理）服务器客户端希望获取缓存的内容（若有），而不用向原服务器发送请求 |
| must-revalidate | 当前资源一定是向原服务器发去验证请求的，若请求失败会返回504（而非代理服务器上的缓存） |
| proxy-revalidate | 与must-revalidate类似，但仅能应用于共享缓存（如代理） |
| max-age=delta-seconds | 告知客户端该资源在delta-sec秒内是新鲜的，无需向服务器发请求 |
| s-maxage=delta-seconds | 同max-age，但仅应用于共享缓存（如代理） |
| cache-extension | 自定义扩展值，若服务器不识别该值将被忽略掉 |
Cache-Control可以自由组合可选值，比如
Cache-Control: max-age=3600, must-revalidate
它意味着该资源是从原服务器上取得的，且其缓存（新鲜度）的有效时间为一小时，在后续一小时内，用户重新访问该资源则无须发送请求。 当然这种组合的方式也会有些限制，比如 no-cache 就不能和 max-age、min-fresh、max-stale 一起搭配使用。
缓存校验字段
Last-Modified和ETag
现在有一个问题就是，客户端向服务器发送了请求，那服务器是不是一定要发送所有请求的内容呢？
因为请求的内容可能还是与服务器上是一致的，所以Http1.1新增了几个首部字段来做这件事情。
1.Last-Modified
服务器将资源传递给客户端时，会将资源最后更改的时间以“Last-Modified: GMT”的形式加在实体首部上一起返回给客户端。
Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT
有两个请求报文字段来标记修改时间
⑴ If-Modified-Since: Last-Modified-value
If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
如果一致就返回304和响应报头
⑵ If-Unmodified-Since: Last-Modified-value
如果Last-Modified匹配不上（资源在服务端的最后更新时间改变了），则返回412(Precondition Failed) 状态码给客户端。
2.ETag
上文中的Last-Modified存在一个问题，在服务器上一个资源被修改了，但实际的内容却并没有修改，还是会返回整个请求的资源。
为了解决这个可能存在的不准确问题，HTTP1.1推出了ETag实体首部字段。ETag是缓存的一个强校验器。
客户端使用If-None-Match这个请求头字段来验证缓存。
⑴ If-None-Match: ETag-value
告诉服务端如果 ETag 没匹配上需要重发资源数据，否则直接回送304 和响应报头即可。
⑵ If-Match: ETag-value
若匹配不到ETag，或者收到了“*”值而当前并没有该资源实体，则应当返回412(Precondition Failed) 状态码给客户端。否则服务器直接忽略该字段。
参考文章
HTTP缓存控制小结
浅谈浏览器http的缓存机制
HTTP 缓存 | MDN
HTTP 缓存|Web|Google Developers
Cache-Control
