前端必须知道的http缓存

相关字段简述

RFC2616规定的47种http报文首部字段中与缓存相关的字段。

通用头部字段

请求头部字段

响应头部字段

实体头部字段

Pragma与Expires

在 http1.0 时代，给客户端设定缓存方式可经过两个字段——Pragma和Expires来规范。虽然这两个字段早可抛弃，但为了作http协议的向下兼容，你仍是能够看到不少网站依旧会带上这两个字段。

Pragma

当该字段值为no-cache的时候（事实上如今RFC中也仅标明该可选值），会知会客户端不要对该资源读缓存，即每次都得向服务器发一次请求才行。

Expires

有了Pragma来禁用缓存，天然也须要有个东西来启用缓存和定义缓存时间，对http1.0而言，Expires就是作这件事的首部字段。 Expires的值对应一个GMT（格林尼治时间），好比Mon, 22 Jul 2002 11:12:01 GMT来告诉浏览器资源缓存过时时间，若是还没过该时间点则不发请求。

Tips

若是Pragma头部和Expires头部同时存在，则起做用的会是Pragma，有兴趣的同窗能够本身试一下。

须要注意的是，响应报文中Expires所定义的缓存时间是相对服务器上的时间而言的，其定义的是资源“失效时刻”，若是客户端上的时间跟服务器上的时间不一致（特别是用户修改了本身电脑的系统时间），那缓存时间可能就意义了。

Cache-Control

针对上述的“Expires时间是相对服务器而言，没法保证和客户端时间统一”的问题，http1.1新增了 Cache-Control 来定义缓存过时时间。注意：若报文中同时出现了 Expires 和 Cache-Control，则以 Cache-Control 为准。

也就是说优先级从高到低分别是 Pragma -> Cache-Control -> Expires 。

Cache-Control也是一个通用首部字段，这意味着它能分别在请求报文和响应报文中使用。在RFC中规范了 Cache-Control 的格式为：

"Cache-Control" ":" cache-directive

做为请求首部时，cache-directive 的可选值有：

做为响应首部时，cache-directive 的可选值有：

Cache-Control 容许自由组合可选值，例如：

Cache-Control: max-age=3600, must-revalidate

它意味着该资源是从原服务器上取得的，且其缓存（新鲜度）的有效时间为一小时，在后续一小时内，用户从新访问该资源则无须发送请求。 固然这种组合的方式也会有些限制，好比 no-cache 就不能和 max-age、min-fresh、max-stale 一块儿搭配使用。

缓存校验字段

上述的首部字段均能让客户端决定是否向服务器发送请求，好比设置的缓存时间未过时，那么天然直接从本地缓存取数据便可（在chrome下表现为200 from cache），若缓存时间过时了或资源不应直接走缓存，则会发请求到服务器去。

咱们如今要说的问题是，若是客户端向服务器发了请求，那么是否意味着必定要读取回该资源的整个实体内容呢？

咱们试着这么想——客户端上某个资源保存的缓存时间过时了，但这时候其实服务器并无更新过这个资源，若是这个资源数据量很大，客户端要求服务器再把这个东西从新发一遍过来，是否很是浪费带宽和时间呢？

答案是确定的，那么是否有办法让服务器知道客户端如今存有的缓存文件，其实跟本身全部的文件是一致的，而后直接告诉客户端说“这东西你直接用缓存里的就能够了，我这边没更新过呢，就再也不传一次过去了”。

为了让客户端与服务器之间能实现缓存文件是否更新的验证、提高缓存的复用率，Http1.1新增了几个首部字段来作这件事情。

Last-Modified

服务器将资源传递给客户端时，会将资源最后更改的时间以“Last-Modified: GMT”的形式加在实体首部上一块儿返回给客户端。

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

客户端会为资源标记上该信息，下次再次请求时，会把该信息附带在请求报文中一并带给服务器去作检查。

• 若传递的时间值与服务器上该资源最终修改时间是一致的，则说明该资源没有被修改过，直接返回304状态码，内容为空。

• 若是两个时间不一致，则服务器会发回该资源并返回200状态码，和第一次请求时相似。

这样保证不向客户端重复发出资源，也保证当服务器有变化时，客户端可以获得最新的资源。一个304响应比一个静态资源一般小得多，这样就节省了网络带宽。

If-Modified-Since: Last-Modified-value

示例为 If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
该请求首部告诉服务器若是客户端传来的最后修改时间与服务器上的一致，则直接回送304 和响应报头便可。
当前各浏览器均是使用的该请求首部来向服务器传递保存的 Last-Modified 值。

If-Unmodified-Since: Last-Modified-value

该值告诉服务器，若Last-Modified没有匹配上（资源在服务端的最后更新时间改变了），则应当返回412(Precondition Failed) 状态码给客户端。 Last-Modified 存在必定问题，若是在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会由于Last-Modified时间匹配不上而返回了整个实体给客户端（即便客户端缓存里有个如出一辙的资源）。

Etag

为了解决上述Last-Modified可能存在的不许确的问题，Http1.1还推出了 ETag 实体首部字段。 服务器会经过某种算法，给资源计算得出一个惟一标志符（好比md5标志），在把资源响应给客户端的时候，会在实体首部加上“ETag: 惟一标识符”一块儿返回给客户端。例如：

Etag: "5d8c72a5edda8d6a:3239"

客户端会保留该 ETag 字段，并在下一次请求时将其一并带过去给服务器。服务器只须要比较客户端传来的ETag跟本身服务器上该资源的ETag是否一致，就能很好地判断资源相对客户端而言是否被修改过了。

• 若是服务器发现ETag匹配不上，那么直接以常规GET 200回包形式将新的资源（固然也包括了新的ETag）发给客户端

• 若是ETag是一致的，则直接返回304知会客户端直接使用本地缓存便可。

那么客户端是如何把标记在资源上的 ETag 传回给服务器的呢？请求报文中有两个首部字段能够带上 ETag 值：

If-None-Match: ETag-value

示例为 If-None-Match: "5d8c72a5edda8d6a:3239"

• 告诉服务端若是 ETag 没匹配上须要重发资源数据

• 不然直接回送304和响应报头便可。 当前各浏览器均是使用的该请求首部来向服务器传递保存的 ETag 值。

If-Match: ETag-value

• 告诉服务器若是没有匹配到ETag，或者收到了“*”值而当前并无该资源实体，则应当返回412(Precondition Failed) 状态码给客户端。

• 不然服务器直接忽略该字段。

须要注意的是，若是资源是走分布式服务器（好比CDN）存储的状况，须要这些服务器上计算ETag惟一值的算法保持一致，才不会致使明明同一个文件，在服务器A和服务器B上生成的ETag却不同。

缓存头部对比

几种字段的对比：

头部	优点和特色	劣势和问题
Expires	一、HTTP 1.0 产物，能够在HTTP 1.0和1.1中使用，简单易用。二、以时刻标识失效时间。	一、时间是由服务器发送的(UTC)，若是服务器时间和客户端时间存在不一致，可能会出现问题。二、存在版本问题，到期以前的修改客户端是不可知的。
Cache-Control	一、HTTP 1.1 产物，以时间间隔标识失效时间，解决了Expires服务器和客户端相对时间的问题。二、比Expires多了不少选项设置。	一、HTTP 1.1 才有的内容，不适用于HTTP 1.0 。二、存在版本问题，到期以前的修改客户端是不可知的。
Last-Modified	一、不存在版本问题，每次请求都会去服务器进行校验。服务器对比最后修改时间若是相同则返回304，不一样返回200以及资源内容。	一、只要资源修改，不管内容是否发生实质性的变化，都会将该资源返回客户端。例如周期性重写，这种状况下该资源包含的数据实际上同样的。二、以时刻做为标识，没法识别一秒内进行屡次修改的状况。三、某些服务器不能精确的获得文件的最后修改时间。
ETag	一、能够更加精确的判断资源是否被修改，能够识别一秒内屡次修改的状况。二、不存在版本问题，每次请求都回去服务器进行校验。	一、计算ETag值须要性能损耗。二、分布式服务器存储的状况下，计算ETag的算法若是不同，会致使浏览器从一台服务器上得到页面内容后到另一台服务器上进行验证时发现ETag不匹配的状况。

用户刷新/访问行为

咱们能够把刷新/访问界面的手段分红三类,在浏览器中，有时候你会发现经过不一样的手段访问/刷新界面页面的呈现速度是不同的，那么它们到底有什么区别呢?

在URI输入栏中输入而后回车/经过书签访问

返回响应码是 200 OK (from cache)，浏览器发现该资源已经缓存了并且没有过时（经过Expires头部或者Cache-Control头部），没有跟服务器确认，而是直接使用了浏览器缓存的内容。其中响应内容和以前的响应内容如出一辙，例如其中的Date时间是上一次响应的时间。

F5/点击工具栏中的刷新按钮/右键菜单从新加载

F5的做用和直接在URI输入栏中输入而后回车是不同的，F5会让浏览器不管如何都发一个HTTP Request给Server，即便先前的响应中有Expires头部。因此，当我在当前 腾讯课堂 网页中按F5的时候，浏览器会发送一个HTTP Request给Server，可是包含这样的Headers:

Cache-Control: max-age=0
If-Modified-Since: Fri, 15 Jul 2016 04:11:51 GMT

其中Cache-Control是Chrome强制加上的，而If-Modified-Since是由于获取该资源的时候包含了Last-Modified头部，浏览器会使用If-Modified-Since头部信息从新发送该时间以确认资源是否须要从新发送。 实际上Server没有修改这个index.css文件，因此返回了一个304(Not Modified)，这样的响应信息很小，所消耗的route-trip很少，网页很快就刷新了。

上面的例子中没有ETag，若是Response中包含ETag，F5引起的Http Request中也是会包含If-None-Match的。

Ctl+F5

Ctrl+F5要的是完全的从Server拿一份新的资源过来，因此不光要发送HTTP request给Server，并且这个请求里面连If-Modified-Since/If-None-Match都没有，这样就逼着Server不能返回304，而是把整个资源原本来本地返回一份，这样，Ctrl+F5引起的传输时间变长了，天然网页Refresh的也慢一些。咱们能够看到该操做返回了200，并刷新了相关的缓存控制时间。

实际上，为了保证拿到的是从Server上最新的，Ctrl+F5不只是去掉了If-Modified-Since/If-None-Match，还须要添加一些HTTP Headers。

按照HTTP/1.1协议，Cache不光只是存在Browser终端，从Browser到Server之间的中间节点(好比Proxy)也可能扮演Cache的做用，为了防止得到的只是这些中间节点的Cache，须要告诉他们，别用本身的Cache敷衍我，往Upstream的节点要一个最新的copy吧。

在Chrome 51 中会包含两个头部信息， 做用就是让中间的Cache对这个请求失效，这样返回的绝对是新鲜的资源。

Cache-Control: no-cache
Pragma: no-cache

缓存实践

综上对各类HTTP缓存控制头部的对比以及用户可能出现的浏览器刷新行为的讨论，当咱们在一个项目上作http缓存的应用时，咱们实际上仍是会把上述说起的大多数首部字段均使用上。

Expires / Cache-Control

Expires用时刻来标识失效时间，难免收到时间同步的影响，而Cache-Control使用时间间隔很好的解决了这个问题。 可是 Cache-Control 是 HTTP1.1 才有的，不适用于 HTTP1.0，而 Expires 既适用于 HTTP1.0，也适用于 HTTP1.1，因此说在大多数状况下同时发送这两个头会是一个更好的选择，当客户端两种头都能解析的时候，会优先使用 Cache-Control。

Last-Modified / ETag

两者都是经过某个标识值来请求资源， 若是服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed）状态码，内容为空，这样就节省了传输数据量。而当资源发生比那话后，返回和第一次请求时相似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端可以获得最新的资源。

其中Last-Modified使用文件最后修改做为文件标识值，它没法处理文件一秒内屡次修改的状况，并且只要文件修改了哪怕文件实质内容没有修改，也会从新返回资源内容；ETag做为“被请求变量的实体值”，其彻底能够解决Last-Modified头部的问题，可是其计算过程须要耗费服务器资源。

from-cache / 304

Expires和Cache-Control都有一个问题就是服务端做为的修改，若是还在缓存时效里，那么客户端是不会去请求服务端资源的（非刷新），这就存在一个资源版本不符的问题，而强制刷新必定会发起HTTP请求并返回资源内容，不管该内容在这段时间内是否修改过；而Last-Modified和Etag每次请求资源都会发起请求，哪怕是好久都不会有修改的资源，都至少有一次请求响应的消耗。

对于全部可缓存资源，指定一个Expires或Cache-Control max-age以及一个Last-Modified或ETag相当重要。同时使用前者和后者能够很好的相互适应。

前者不须要每次都发起一次请求来校验资源时效性，后者保证当资源未出现修改的时候不须要从新发送该资源。而在用户的不一样刷新页面行为中，两者的结合也能很好的利用HTTP缓存控制特性，不管是在地址栏输入URI而后输入回车进行访问，仍是点击刷新按钮，浏览器都能充分利用缓存内容，避免进行没必要要的请求与数据传输。

避免304

同窗们是否还记得咱们在讨论用户刷新页面行为中体积的index.css文件，它实际上被命名为index.03d344bd.css。而细心的同窗也会发现它的Expires和Cache-Control时间出奇的长，这难道不会致使用户没法获得其最近的内容吗？

其作法实际上很简单，它把服务侧ETag的那一套理论搬到了前端来使用。 页面的静态资源以版本形式发布，经常使用的方法是在文件名或参数带上一串md5或时间标记符：

https://hm.baidu.com/hm.js?e23800c454aa573c0ccb16b52665ac26
http://tb1.bdstatic.com/tb/_/tbean_safe_ajax_94e7ca2.js
http://img1.gtimg.com/ninja/2/2016/04/ninja145972803357449.jpg

能够看到上面的例子中有不一样的作法，有的在URI后面加上了md5参数，有的将md5值做为文件名的一部分，有的将资源放在特性版本的目录中。

那么在文件没有变更的时候，浏览器不用发起请求直接可使用缓存文件；而在文件有变化的时候，因为文件版本号的变动，致使文件名变化，请求的url变了，天然文件就更新了。这样能确保客户端能及时从服务器收取到新修改的文件。经过这样的处理，增加了静态资源，特别是图片资源的缓存时间，避免该资源很快过时，客户端频繁向服务端发起资源请求，服务器再返回304响应的状况（有Last-Modified/Etag）。

Tips

• 须要兼容HTTP1.0的时候须要使用Expires，否则能够考虑直接使用Cache-Control

• 须要处理一秒内屡次修改的状况，或者其余Last-Modified处理不了的状况，才使用ETag，不然使用Last-Modified。

• 对于全部可缓存资源，须要指定一个Expires或Cache-Control，同时指定Last-Modified或者Etag。

• 能够经过标识文件版本名、加长缓存时间的方式来减小304响应。

总结

参考

• HTTP缓存小结

• HTTP/1.1: Caching in HTTP