[http] 缓存

缓存(caching)

重用已获取的资源能够有效的提升网站与应用的性能。Web 缓存能够减少延迟与网络阻塞，进而减少显示某个资源所用的时间。借助 HTTP 缓存，Web 站点变得更具有响应性。

各种类型的缓存

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。这样带来的好处有：缓解服务器端压力，提升性能(获取资源的耗时更短了)。对于网站来说，缓存是达到高性能的重要组成部分。缓存需要合理配置，因为并不是所有资源都是永久不变的：重要的是对一个资源的缓存应截止到其下一次发生改变（即不能缓存过期的资源）。

缓存的种类有很多,其大致可归为两类：私有(private)与共享(shared)缓存。共享缓存存储的响应能够被多个用户使用。私有缓存只能用于单独用户。本文将主要介绍浏览器与代理缓存，除此之外还有网关缓存、CDN、反向代理缓存和负载均衡器等部署在服务器上，为站点和 web 应用提供更好的稳定性、性能和扩展性。

(私有)浏览器缓存
私有缓存只能用于单独用户。浏览器缓存拥有用户通过 HTTP 下载的所有文档。这些缓存为浏览过的文档提供向后/向前导航，保存网页，查看源码等功能，可以避免再次向服务器发起多余的请求。它同样可以提供缓存内容的离线浏览。

(共享)代理缓存
共享缓存可以被多个用户使用。例如，ISP 或你所在的公司可能会架设一个 web 代理来作为本地网络基础的一部分提供给用户。这样热门的资源就会被重复使用，减少网络拥堵与延迟。

缓存操作的目标

虽然 HTTP 缓存不是必须的，但重用缓存的资源通常是必要的。然而常见的 HTTP 缓存只能存储 GET 响应，对于其他类型的响应则无能为力。缓存的关键主要包括request method和目标URI（一般只有GET请求才会被缓存）。 普遍的缓存案例:

• 一个检索请求的成功响应: 对于 GET请求，响应状态码为：200，则表示为成功。一个包含例如HTML文档，图片，或者文件的响应.
• 不变的重定向: 响应状态码：301.
• 错误响应: 响应状态码：404 的一个页面.
• 不完全的响应: 响应状态码 206，只返回局部的信息.
• 除了 GET 请求外，如果匹配到作为一个已被定义的cache键名的响应.

针对一些特定的请求，也可以通过关键字区分多个存储的不同响应以组成缓存的内容。

缓存控制

Cache-control

HTTP/1.1定义的 Cache-Control 头用来区分对缓存机制的支持情况， 请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。

禁止进行缓存

缓存中不得存储任何关于客户端请求和服务端响应的内容。每次由客户端发起的请求都会下载完整的响应内容。

# 两种写法

Cache-Control: no-store

Cache-Control: no-cache, no-store, must-revalidate

强制确认缓存

如下头部定义，此方式下，每次有请求发出时，缓存会将此请求发到服务器（该请求应该会带有与本地缓存相关的验证字段），服务器端会验证请求中所描述的缓存是否过期，若未过期（实际就是返回304），则缓存才使用本地缓存副本。

Cache-Control: no-cache

私有缓存和公共缓存

"public" 指令表示该响应可以被任何中间人（比如中间代理、CDN等）缓存。若指定了"public"，则一些通常不被中间人缓存的页面（因为默认是private）（比如 带有HTTP验证信息（帐号密码）的页面 或 某些特定影响状态码的页面），将会被其缓存。

而 "private" 则表示该响应是专用于某单个用户的，中间人不能缓存此响应，该响应只能应用于浏览器私有缓存中。

Cache-Control: private
Cache-Control: public

缓存过期机制

过期机制中，最重要的指令是 max-age=<seconds>，表示资源能够被缓存（保持新鲜）的最大时间。
相对Expires而言，max-age是距离请求发起的时间的秒数。
针对应用中那些不会改变的文件，通常可以手动设置一定的时长以保证缓存有效，例如图片、css、js等静态资源。

Cache-Control: max-age=31536000

缓存验证确认

当使用了 "must-revalidate" 指令，那就意味着缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过期的缓存将不被使用。

Cache-Control: must-revalidate

Pragma 头

Pragma 是HTTP/1.0标准中定义的一个header属性，请求中包含Pragma的效果跟在头信息中定义Cache-Control: no-cache相同，但是HTTP的响应头不支持这个属性，所以它不能拿来完全替代HTTP/1.1中定义的Cache-control头。通常定义Pragma以向后兼容基于HTTP/1.0的客户端。

新鲜度(Freshness)

理论上来讲，当一个资源被缓存存储后，该资源应该可以被永久存储在缓存中。
由于缓存只有有限的空间用于存储资源副本，所以缓存会定期地将一些副本删除，这个过程叫做缓存驱逐。
另一方面，当服务器上面的资源进行了更新，那么缓存中的对应资源也应该被更新，由于HTTP是C/S模式的协议，服务器更新一个资源时，不可能直接通知客户端及其缓存，所以双方必须为该资源约定一个过期时间，在该过期时间之前，该资源（缓存副本）就是新鲜的，当过了过期时间后，该资源（缓存副本）则变为陈旧的。驱逐算法用于将陈旧的资源（缓存副本）替换为新鲜的，注意，一个陈旧的资源（缓存副本）是不会直接被清除或忽略的，当客户端发起一个请求时，缓存检索到已有一个对应的陈旧资源（缓存副本），则缓存会先将此请求附加一个If-None-Match头，然后发给目标服务器，以此来检查该资源副本是否是依然还是算新鲜的，若服务器返回了 304 (Not Modified)（该响应不会有带有实体信息），则表示此资源副本是新鲜的，这样一来，可以节省一些带宽。若服务器通过 If-None-Match 或 If-Modified-Since判断后发现已过期，那么会带有该资源的实体内容返回。

(这个图个人感觉不是太好)

对于含有特定头信息的请求，会去计算缓存寿命。比如Cache-control: max-age=N的请求头，相应的缓存的寿命就是N。通常情况下，对于不含这个属性的请求则会去查看是否包含Expires属性，通过比较Expires的值和头里面Date属性的值来判断是否缓存还有效。如果max-age和expires属性都没有，找找头里的Last-Modified信息。如果有，缓存的寿命就等于头里面Date的值减去Last-Modified的值除以10（Last-Modified的值除以10存疑）。

缓存失效时间计算公式如下：

expirationTime = responseTime + freshnessLifetime - currentAge

上式中，responseTime 表示浏览器接收到此响应的那个时间点。

加速资源

更多地利用缓存资源，可以提高网站的性能和相应速度。为了优化缓存，过期时间设置得尽量长是一种很好的策略。对于定期或者频繁更新的资源，这么做是比较稳妥的，但是对于那些长期不更新的资源会有点问题。这些固定的资源在一定时间内受益于这种长期保持的缓存策略，但一旦要更新就会很困难。特指网页上引入的一些js/css文件，当它们变动时需要尽快更新线上资源。

web开发者发明了一种 Steve Sounders里 称作加速(revving)的技术 。不频繁更新的文件会使用特定的命名方式：在URL后面（通常是文件名后面）会加上版本号。加上版本号后的资源就被视作一个完全新的独立的资源，同时拥有一年甚至更长的缓存过期时长。但是这么做也存在一个弊端，所有引用这个资源的地方都需要更新链接。web开发者们通常会采用自动化构建工具在实际工作中完成这些琐碎的工作。当低频更新的资源（js/css）变动了，只用在高频变动的资源文件（html）里做入口的改动。

这种方法还有一个好处：同时更新两个缓存资源不会造成部分缓存先更新而引起新旧文件内容不一致。对于互相有依赖关系的css和js文件，避免这种不一致性是非常重要的。

加在加速文件后面的版本号不一定是一个正式的版本号字符串，如1.1.3这样或者其他固定自增的版本数。它可以是任何防止缓存碰撞的标记例如hash或者时间戳。

缓存验证

用户点击刷新按钮时会开始缓存验证。如果缓存的响应头信息里含有"Cache-control: must-revalidate”，在浏览的过程中也会触发缓存验证。另外，在浏览器偏好设置里设置Advanced->Cache为强制验证缓存也能达到相同的效果。

当缓存的文档过期后，需要进行缓存验证或者重新获取资源。只有在服务器返回强校验器或者弱校验器时才会进行验证。

ETag

作为缓存的一种强校验器，ETag 响应头是一个对用户代理(User Agent, 下面简称UA)不可知的值。对于像浏览器这样的HTTP UA，不知道ETag代表什么，值是多少。如果资源请求的响应头里含有ETag, 客户端可以在后续的所有请求的头中带上 If-None-Match 头来验证缓存。

Last-Modified 响应头可以作为一种弱校验器。说它弱是因为它是一次性的。如果响应头里含有这个信息，客户端可以在后续的一次请求中带上 If-Modified-Since 来验证缓存。

当向服务端发起缓存校验的请求时，服务端会返回 200 ok表示返回正常的结果或者 304 Not Modified(不返回body)表示浏览器可以使用本地缓存文件。304的响应头也可以同时更新缓存文档的过期时间。

带Vary头的响应

Vary HTTP 响应头决定了对于后续的请求头，如何判断是请求一个新的资源还是使用缓存的文件。

当缓存服务器收到一个请求，只有当前的请求和原始（缓存）的请求头跟缓存的响应头里的Vary都匹配，才能使用缓存的响应。

使用vary头有利于内容服务的动态多样性。例如，使用Vary: User-Agent头，缓存服务器需要通过UA判断是否使用缓存的页面。如果需要区分移动端和桌面端的展示内容，利用这种方式就能避免在不同的终端展示错误的布局。另外，它可以帮助google或者其他搜索引擎更好地发现页面的移动版本，并且告诉搜索引擎没有引入Cloaking。

Vary: User-Agent

因为移动版和桌面的客户端的请求头中的User-Agent不同， 缓存服务器不会错误地把移动端的内容输出到桌面端到用户。

Cache-Control

Cache-Control 通用消息头被用于在http 请求和响应中通过指定指令来实现缓存机制。缓存指令是单向的, 这意味着在响应里设置的指令，在请求中不用包含相同的指令。

指令不区分大小写，并且具有可选参数，可以用令牌或者带引号的字符串语法。多个指令以逗号分隔。

request

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache 
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached

response

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>

可缓存性

public
    表明响应可以被任何对象（包括：发送请求的客户端，代理服务器，等等）缓存。

private
    表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。

no-cache
     强制所有缓存了该响应的缓存用户，在使用已存储的缓存数据前，发送带验证器的请求到原始服务器

only-if-cached
    表明如果缓存存在，只使用缓存，无论原始服务器数据是否有更新。

no-store
    缓存不应存储有关客户端请求或服务器响应的任何内容。

no-transform
    不得对资源进行转换或转变。Content-Encoding, Content-Range, Content-Type等HTTP头不能由代理修改。例如，非透明代理可以对图像格式进行转换，以便节省缓存空间或者减少缓慢链路上的流量。 no-transform指令不允许这样做。 

到期

max-age=<seconds>
    设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。与Expires相反，时间是相对于请求的时间。

s-maxage=<seconds>
    覆盖max-age 或者 Expires 头，但是仅适用于共享缓存(比如各个代理)，并且私有缓存中它被忽略。

max-stale[=<seconds>]
    表明客户端愿意接收一个已经过期的资源。 可选的设置一个时间(单位秒)，表示响应不能超过的过时时间。

min-fresh=<seconds>
    表示客户端希望在指定的时间内获取最新的响应。

重新验证和重新加载

must-revalidate
    缓存必须在使用之前验证旧资源的状态，并且不可使用过期资源。
proxy-revalidate
    与must-revalidate作用相同，但它仅适用于共享缓存（例如代理），并被私有缓存忽略。

ETag

HTTP协议规格说明定义ETag为“被请求变量的实体标记”(EntityTags)。简单点即服务器响应时给请求URL标记，并在HTTP响应头中将其传送到客户端。
这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web服务器不需要发送完整的响应。而如果内容发生了变化，使用ETag有助于防止资源的同时更新相互覆盖（“空中碰撞”）("mid-air collisions")。

如果给定URL中的资源更改，则一定要生成新的Etag值。 因此Etag类似于指纹，也可能被某些服务器用于跟踪。 比较Etag能快速确定此资源是否变化，但也可能被跟踪服务器永久存留。

ETag: W/"<etag_value>"
ETag: "<etag_value>"

W/ (可选)
W/(大小写敏感) 表示使用弱验证器。 弱验证器很容易生成，但不利于比较。 强验证器是比较的理想选择，但很难有效地生成。 相同资源的两个弱Etag值可能语义等同，但不是每个字节都相同。
<etag_value>
实体标签唯一地表示所请求的资源。 它们是位于双引号之间的ASCII字符串（如“675af34563dc-tr34”）。 没有明确指定生成ETag值的方法。 通常，使用内容的散列，最后修改时间戳的哈希值，或简单地使用版本号。 例如，MDN使用wiki内容的十六进制数字的哈希值。

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

Avoiding mid-air collisions

在ETag和 If-Match 头部的帮助下，可以检测到"空中碰撞"的编辑冲突。

例如，当编辑MDN时，当前的wiki内容被散列，并在响应中放入Etag：

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4

将更改保存到Wiki页面（发布数据）时，POST请求将包含有ETag值的If-Match头来检查新鲜度。

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

如果哈希值不匹配，则意味着文档已经被编辑，抛出412前提条件失败错误。

Caching of unchanged resources

ETag头的另一个典型用例是缓存未更改的资源。 如果用户再次访问给定的URL（设有ETag字段），显示资源过期了且不可用，客户端就发送值为ETag的If-None-Match header字段：

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

服务器将客户端的ETag（作为If-None-Match字段的值一起发送）与其当前版本的资源的ETag进行比较，如果两个值匹配（即资源未更改），服务器将返回不带任何内容的304未修改状态，告诉客户端缓存版本可用（新鲜）。

Expires

Expires 头指定了一个日期/时间， 在这个日期/时间之后，HTTP响应被认为是过时的；

无效的日期，比如 0, 代表着一个过去的事件，即该资源已经过期了。

如果还有一个 设置了 "max-age" 或者 "s-max-age" 指令的Cache-Control响应头，那么 Expires 头就会被忽略。

Expires: <http-date>

Expires: Sun, Oct 01 2017 08:00:00 GMT

If-Match

请求首部 If-Match 的使用表示这是一个条件请求。在请求方法为 GET 和 HEAD 的情况下，服务器仅在请求的资源满足此首部列出的 ETag 之一时才会返回资源。而对于 PUT 或其他非安全方法来说，只有在满足条件的情况下才可以将资源上传。

以下是两个常见的应用场景：

• For GET 和 HEAD 方法，搭配 Range首部使用，可以用来保证新请求的范围与之前请求的范围是对同一份资源的请求。如果 ETag 无法匹配，那么需要返回 416 (Range Not Satisfiable，范围请求无法满足) 响应。
• 对于其他方法来说，尤其是 PUT, If-Match 首部可以用来避免更新丢失问题。它可以用来检测用户想要上传的不会覆盖获取原始资源之后做出的更新。如果请求的条件不满足，那么需要返回 412 (Precondition Failed，先决条件失败) 响应。

If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-Match: W/"67ab43", "54ed21", "7892dd"

If-Match: *

If-None-Match

If-None-Match 是一个条件式请求首部。对于 GET 和 HEAD 请求方法来说，当且仅当服务器上没有任何资源的 ETag 属性值与这个首部中列出的相匹配的时候，服务器端会才返回所请求的资源，响应码为 200 。对于其他方法来说，当且仅当最终确认没有已存在的资源的 ETag 属性值与这个首部中所列出的相匹配的时候，才会对请求进行相应的处理。

对于 GET 和 HEAD 方法来说，当验证失败的时候，服务器端必须返回响应码 304 （Not Modified，未改变）。对于能够引发服务器状态改变的方法，则返回 412 （Precondition Failed，前置条件失败）。需要注意的是，服务器端在生成状态码为 304 的响应的时候，必须同时生成以下会存在于对应的 200 响应中的首部：Cache-Control、Content-Location、Date、ETag、Expires 和 Vary 。

当与 If-Modified-Since 一同使用的时候，If-None-Match 优先级更高（假如服务器支持的话）。

以下是两个常见的应用场景：

• 采用 GET 或 HEAD 方法，来更新拥有特定的ETag 属性值的缓存。
• 采用其他方法，尤其是 PUT，将 If-None-Match used 的值设置为 * ，用来生成事先并不知道是否存在的文件，可以确保先前并没有进行过类似的上传操作，防止之前操作数据的丢失。这个问题属于更新丢失问题的一种。

If-None-Match: <etag_value>
If-None-Match: <etag_value>, <etag_value>, …
If-None-Match: *

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-None-Match: W/"67ab43", "54ed21", "7892dd"

If-None-Match: *

If-Modified-Since

If-Modified-Since 是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 响应，而在 Last-Modified 首部中会带有上次修改时间。 不同于 If-Unmodified-Since, If-Modified-Since 只可以用在 GET 或 HEAD 请求中。

当与 If-None-Match 一同出现时，它会被忽略掉，除非服务器不支持 If-None-Match。

最常见的应用场景是来更新没有特定 ETag 标签的缓存实体。

If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

If-Modified-Since: Sun, Oct 01 2017 08:00:00 GMT

<day-name>
     "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" 或 "Sun" 之一 （区分大小写）。

<day>
    两位数字表示的天数, 例如"04" or "23"。

<month>
    "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 之一（区分大小写）。

<year>
    4位数字表示的年份, 例如 "1990" 或者"2016"。

<hour>
    两位数字表示的小时数, 例如 "09" 或者 "23"。

<minute>
    两位数字表示的分钟数，例如"04" 或者 "59"。

<second>
    两位数字表示的秒数，例如 "04" 或者 "59"。

GMT

    国际标准时间。HTTP中的时间均用国际标准时间表示，从来不使用当地时间。

Last-Modified

Last-Modified 是一个响应首部，其中包含源头服务器认定的资源做出修改的日期及时间。 它通常被用作一个验证器来判断接收到的或者存储的资源是否彼此一致。由于精确度比 ETag 要低，所以这是一个备用机制。包含有 If-Modified-Since 或 If-Unmodified-Since 首部的条件请求会使用这个字段。

Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

Last-Modified: Sun, Oct 01 2017 08:00:00 GMT

vary

Vary 是一个HTTP响应头部信息，它决定了对于未来的一个请求头，应该用一个缓存的回复(response)还是向源服务器请求一个新的回复。它被服务器用来表明在 content negotiation algorithm（内容协商算法）中选择一个资源代表的时候应该使用哪些头部信息（headers）.

在响应状态码为 304 Not Modified 的响应中，也要设置 Vary 首部，而且要与相应的 200 OK 响应设置得一模一样。

所有的请求都被视为唯一并且非缓存的，使用Cache-Control: private,来实现则更适用，这样用于说明不存储该对象更加清晰。

Vary: *

逗号分隔的一系列http头部名称，用于确定缓存是否可用。

Vary: <header-name>, <header-name>, ...

动态服务

对于User-Agent 头部信息，例如你提供给移动端的内容是不同的，可用防止你客户端误使用了用于桌面端的缓存。 并可帮助Google和其他搜索引擎来发现你的移动端版本的页面，同时告知他们不需要Cloaking。

Vary: User-Agent

这些乱七八糟的header的异同

Last-Modified

在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记(Http Response Header)此文件在服务期端最后被修改的时间，格式类似这样：

Last-Modified:Tue, 24 Feb 2009 08:01:04 GMT

客户端第二次请求此URL时，根据HTTP协议的规定，浏览器会向服务器传送If-Modified-Since报头(Http Request Header)，询问该时间之后文件是否有被修改过：

If-Modified-Since:Tue, 24 Feb 2009 08:01:04 GMT

如果服务器端的资源没有变化，则自动返回HTTP304（Not Modified）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。

注：如果If-Modified-Since的时间比服务器当前时间(当前的请求时间request time)还晚，会认为是个非法请求.

Etag

每一个机器都会产生一个不同的Etag，如果是负载均衡多台服务器架构，可能需要谨慎使用Etag。

查看百度的一张图片，第一次请求时

可以看到返回的是200 ok，说明此图片被成功的从服务器上取到。并且可以看到返回了一个Etag信息 ETag:"1ec5-502264e2ae4c0"

当第二次请求百度页面时，再去查看这两张图片的信息可以看到状态码为304。并且Request-headers返回了 If-None-Match:"1ec5-502264e2ae4c0"，与Etag里的数据相匹配。

通过匹配信息，返回304，让客户端继续使用本地缓存，不用再去请求服务器。

Etag 和 Last-Modified

Etag的出现就是要解决Last-Modified不能解决的一些问题，算是Last-Modified的升级版。

Last-Modified不能解决的下列问题：

1. 周期性更改的文件且内容并不改变(仅仅改变的修改时间)。
2. 有些文件修改极其频繁，也许1秒内修改了很多次，If-Modified-Since能检查到的最小单位是秒级的，所以这种修改无法判断
3. 不能精确得到文件的最后修改时间

HTTP1.1之后就出现了升级版的Etag来解决上述Last-Modified不能解决的问题。

Last-modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续对比Last-modified。最后才决定是否返回304.

Expires

给出的日期/时间后，被响应认为是过时。如Expires:Thu, 02 Apr 2009 05:14:08 GMT

需和Last-Modified结合使用？？。用于控制请求文件的有效时间，当请求数据在有效期内时客户端浏览器从缓存请求数据而不是服务器端.当缓存中数据失效或过期，才决定从服务器更新数据。

当把其值设置为0，则表示页面立即过期。并且若此属性在页面当中被设置了多次，则取其最小值。

Last-Modified 和 Expires??

Last-Modified标识能够节省一点带宽，但是还是逃不掉发一个HTTP请求出去，而且要和Expires一起用。而Expires标识却使得浏览器干脆连HTTP请求都不用发，比如当用户F5或者点击Refresh按钮的时候就算对于有Expires的URI，一样也会发一个HTTP请求出去??，所以一般Last-Modified要和Expires一起用。

Etag 和 Expires

Last-Modified 和 Etag

分布式系统里多台机器间文件的last-modified必须保持一致，以免负载均衡到不同机器导致比对失败.

分布式系统尽量关闭掉Etag(每台机器生成的etag都会不一样).

Last-Modified和ETag请求的http报头一起使用，服务器首先产生Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改，来决定文件是否继续缓存

过程如下:

1. 客户端请求一个页面（A）。
2. 服务器返回页面A，并在给A加上一个Last-Modified/ETag。
3. 客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。
4. 客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。
5. 服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。

注：
1、Last-Modified和Etag头都是由WebServer发出的HttpReponse Header，WebServer应该同时支持这两种头。

2、WebServer发送完Last-Modified/Etag头给客户端后，客户端会缓存这些头；

3、客户端再次发起相同页面的请求时，将分别发送与Last-Modified/Etag对应的HttpRequestHeader:If-Modified-Since和If-None-Match。可以看到这两个Header的值和WebServer发出的Last-Modified,Etag值完全一样；

4、通过上述值到服务器端检查，判断文件是否继续缓存；

Cache-Control 和 Expires

Expires = 时间，HTTP 1.0 版本，缓存的载止时间，允许客户端在这个时间之前不去检查（发请求）
max-age = 秒，HTTP 1.1版本，资源在本地缓存多少秒。
如果max-age和Expires同时存在，则被Cache-Control的max-age覆盖。

Expires 的一个缺点就是，返回的到期时间是服务器端的时间，这样存在一个问题，如果客户端的时间与服务器的时间相差很大，那么误差就很大，所以在HTTP 1.1版开始，使用Cache-Control: max-age=秒 替代。

Expires =max-age + “每次下载时的当前的request时间”
所以一旦重新下载的页面后，expires就重新计算一次，但last-modified不会变化.

对应

request	response
If-Match 、 If-None-Match	Etag
If-Modified-Since	Last-Modified

浏览器

打开新窗口
如果指定cache-control的值为private、no-cache、must-revalidate,那么打开新窗口访问时都会重新访问服务器。
而如果指定了max-age值,那么在此值内的时间里就不会重新访问服务器,例如：Cache-control: max-age=5 表示当访问此网页后的5秒内再次访问不会去服务器.

在地址栏回车
如果值为private或must-revalidate,则只有第一次访问时会访问服务器,以后就不再访问。如果值为no-cache,那么每次都会访问。如果值为max-age,则在过期之前不会重复访问。

按后退按扭
如果值为private、must-revalidate、max-age,则不会重访问,而如果为no-cache,则每次都重复访问.

按刷新按扭
无论为何值,都会重复访问.

强缓存：
不发送请求到服务器确认资源是否有效，直接从缓存中取得资源

协商缓存：
从缓存中取资源前，先向服务器发送请求，确认资源是否有效(过期)，如果资源有效(资源没有改动)，则服务器返回响应状态码304，告知浏览器本地缓存可以继续使用；如果资源失效(资源发生了改动)，则服务器返回新的资源和响应状态码200，此时不使用本地失效的资源。