HTTP缓存策略

http协议是什么？

HTTP协议（超文本传输协议）,简单来说就是一种网络传输协议， 浏览器请求服务器获取内容就是基于http协议或者https协议。 使得计算机可以在浏览器和服务器之间传输文字、图片、二进制、音频、视频等资源。

既然http负责传输资源，那么缓存是必不可少的

http缓存策略主要分为两种方式：

• 强缓存 （浏览器端执行）
• 协商缓存（服务器端执行）

优先级: 强缓存 > 协商缓存

所谓强缓存就是第一次请请求服务器的时候获取的两个字段【Expires】、【Cache-Control】.

强缓存【Expires】、【Cache-Control】

Expires

【Expires】：该字段是HTTP1.0版本提出的，是浏览器访问服务器时，由服务器在ResponseHeader字段中设置该资源过期时间：

Expires:Mon, 29 Jun 2020 11:10:23 GMT
复制代码

上面表示该请求在 29 Jun 2020 11:10:23 前使用缓冲资源，过后再次请求则请会请求服务器获取新的资源。 所以每次请求前浏览器都会判断Expires字段来决定使用缓存资源还是重新请求服务器。

但是Expires的时间是在服务器的ResponseHeader中生成的，所以时间是相对于服务器时间的，一旦服务器时间跟浏览器本地时间不一致则会出现问题，所以Expores并不是一个很好的缓存方法，所以在HTTP1.1提出了【Cache-Control】字段。

Cache-Control

【Cache-Control】：该字段是HTTP1.1提出的，该字段的值是 过期时长（类似一种倒计时的功能），这样即使 服务器和浏览器日期时间不一致也不会导致Expires的问题，到了时间自动过期。

Cache-Control:max-age=6000
复制代码

上面代码代表的是该请求的资源在6000秒后过期, 6000秒前使用缓存资源。

注意事项：

• 当Expires和Cache-Control同时存在时，优先使用HTTP1.1的Cache-Control
• 当强缓存的【Expires】、【Cache-Control】都不命中时，则进入协商缓存。

协商缓存

协商缓存原理：浏览器第一次请求服务器时，服务器会判断Request Headers是否带有缓存标识，若不存在缓存标识，则在Response Headers添加缓存标识，并且返回新的资源。

缓存标识分为两种：【Last-Modified】、【ETag】

Last-Modified

这个字段表示最后修改时间，是指请求的资源的最后修改时间，在浏览器第二次访问服务器时，会在Request Headers的If-Modified-Since中带上该字段的值（值来自服务器），服务器接到请求后，会对If-Modified-Since的值与该请求资源的最后修改时间进行对比，若请求的资源最后修改时间大于If-Modified-Since的值，则返回新的资源，并重新设置Last-Modified字段的值。

以上就是协商缓存：【Last-Modified】的整个执行过程。

ETag

ETag是对请求资源的内容进行MD5算法，生成一个唯一的标识（hash值）。只要资源文件有所改动，改值就会发生改变。 过程：

浏览器第一次请求服务器的时候，服务器会判断Request Headers中的【If-None-Match】是否包含值，若没有该字段则返回新资源，并在Response Headers增加ETag字段，ETag值为请求对应资源的内容生成的hash值。

浏览器第二次请求时，会在Request Headers上添加【If-None-Match】字段，值为服务器返回的ETag的值，服务器接受到请求后，会与请求资源的MD5算法生成的hash值做对比，若相同则返回304告知浏览器使用缓存的资源，若不相同则返回全新的资源给浏览器，并且把新的资源hash值通过Response Headers的ETag字段返回给浏览器，浏览器在下次请求时带上。

ETag 和 Last-Modified 对比

• 性能上，Last-Modified > ETag，因为Last-Modified记录的是资源最后修改时间，而ETag则是记录MD5算法生成的文件内容的hash值。
• 精度上，ETag > Last-Modified，因为ETage是根据内容生成的hash值，对内容极其敏感，而Last-Modified只是记录资源最后一次修改时间。

协商缓存 总结

• Last-Modified： 在服务器生成，存在Response Headers的【Last-Modified】中，浏览器通过RequestHeaders中的【If-Modified-Since】字段把Last-Modified的值带给服务器。
• ETag ： 在服务器中生成，存在Response Headers的【ETag】字段给带浏览器，浏览器通过Request Headers中的【If-None-Match】字段把【ETag】的值带给服务器。

HTTP队头阻塞

众所周知，服务器和客户端是经过三次握手创建TCP通道进行交流的，最后通过四次回收告别的。

所以一次TCP通道的创建是需要消耗一定资源和时间的。

那么在HTTP0.9之前，每发送一次请求就必须创建一次TCP通道，但是一个网站往往都需要发送几十个请求，那么就需要创建几十个TCP通道，那样岂不是很消耗资源？有没有什么方法可以解决呢？

有的！ 在HTPP1.0开始增加了Connection: Keep-Alive字段，可以让TCP链接持续打开。这样就可以节省了一个请求创建一次TCP通道的性能消耗。

在HTTP1.1引入了持久连接 和 管道机制

持久连接

持久连接：即不用声明Connection: keep-alive字段，TCP连接默认不关闭，并且可以被多个请求复用。长连接的连接时长可以通过请求头中的 keep-alive 来设置。

当客户端请求中含有Connection: Keep-Alive首部，服务器响应中也有Connection: Keep-Alive首部时，双方才会成功建立持久连接。

在服务器返回【Connection: Keep-Alive】字段时，还可以追加【Keep-Alive: max=5, timeout=120】字段

Connection: Keep-Alive
Keep-Alive: max=5, timeout=120
复制代码

上面个例子说明，服务器最多还会为另外5个事务保持TCP连接的打开状态，或者将打开状态保持到连接空闲了2分钟之后。

管道机制

HTTP1.1 允许在持久连接上可选择使用请求管道。这是相对于keep-alive连接的又一性能优化。在相应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二第三条请求也可以开始发送了，在高延时网络条件下，这样做可以降低网络的环回时间，提高性能。

持久连接 + 管道机制 引发 HTTP队头阻塞

前面提到HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

HTTP队头阻塞 的解决方法

利用HTTP2的多路复用解决：

对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞，可以使用HTTP2的多路复用解决。

HTTP2不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后再组装成消息，这样就避免了请求/响应阻塞。

当然，即使使用HTTP2，如果HTTP2底层使用的是TCP协议，仍可能出现TCP队头阻塞。

并发连接

我们知道对于一个域名而言，是允许分配多个长连接的，那么可以理解成增加了任务队列，也就是说不会导致一个任务阻塞了该任务队列的其他任务，在RFC规范中规定客户端最多并发2个连接，不过实际情况就是要比这个还要多，举个例子，Chrome中是6个。

域名分片

顾名思义，我们可以在一个域名下分出多个二级域名出来，而它们最终指向的还是同一个服务器，这样子的话就可以并发处理的任务队列更多，也更好的解决了队头阻塞的问题。 举个例子，比如TianTian.com，可以分出很多二级域名，比如Day1.TianTian.com，Day2.TianTian.com, Day3.TianTian.com, 这样子就可以有效解决队头阻塞问题。

HTTP2

• 二进制分帧 这是一次彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"：头信息帧和数据帧。
• 头部压缩 HTTP 1.1版本会出现 「User-Agent、Cookie、Accept、Server、Range」 等字段可能会占用几百甚至几千字节，而 Body 却经常只有几十字节，所以导致头部偏重。HTTP 2.0 使用 HPACK 算法进行压缩。
• 多路复用 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，这样子解决了队头阻塞的问题。
• 服务器推送 允许服务器未经请求，主动向客户端发送资源，即服务器推送。
• 请求优先级 可以设置数据帧的优先级，让服务端先处理重要资源，优化用户体验。