005-优化web请求一-gzip压缩、http缓存控制和缓存校验[Pragma、Expires、Cache-Control、max-age、Last-Modified、用户刷新访问、避免过度304]

　　优化Web应用的典型技术：缓存控制头信息、Gzip、应用缓存、ETag、反应型技术【异步方法调用和WebSocket】

一、模板缓存

spring.thymeleaf.cache=true
spring.messages.cache-duration=

二、Gzip压缩

　　Gzip是一种能够被浏览器直接理解的压缩算法。服务器会提供压缩响应，会耗一些cpu，但是减少带宽

　　GZIP压缩是一个经常被用到的WEB性能优化的技巧，它主要是对页面代码，CSS，Javascript，PHP等文件进行压缩，而且在压缩的前后，文件的大小会有明显的改变，从而达到网站访问加速的目的。

　　GZIP压缩时，WEB服务器与浏览器之间的协商过程如下：

1、首先浏览器请求某个URL地址，并在请求的开始部分头(head) 设置属性accept-encoding值为gzip、deflate，表明浏览器支持gzip和deflate这两种压缩方式（事实上deflate也是使用GZIP压缩协议，在之后的内容之我们会介绍二者之间的区别）；

2、WEB服务器接收到请求后判断浏览器是否支持GZIP压缩，如果支持就传送压缩后的响应内容，否则传送不经过压缩的内容；

3、浏览器获取响应内容后，判断内容是否被压缩，如果是压缩文件则解压缩，然后显示响应页面的内容。

在Springboot中配置gzip

# 是否启用压缩 默认false
server.compression.enabled=true
# 默认"text/html", "text/xml", "text/plain","text/css", "text/javascript", "application/javascript", "application/json",
#            "application/xml"
server.compression.mime-types=text/html,text/xml,text/plain,text/css,text/javascript,application/javascript\
  ,application/json,
#content-length 在压缩启用后。返回数据多大开始启用gzip，默认2048 为了测试添加为1
server.compression.min-response-size=1

测试1、未开启压缩

# 是否启用压缩 默认false
server.compression.enabled=false

客户端请求头

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:zh-CN,zh;q=0.9,en;q=0.8

服务端响应

Content-Length:60973
Content-Type:text/html;charset=UTF-8
Date:Wed, 30 Jan 2019 08:19:19 GMT

测试2、开启压缩

# 是否启用压缩 默认false
server.compression.enabled=true
#content-length 在压缩启用后。返回数据多大开始启用gzip，默认2048 为了测试添加为1
server.compression.min-response-size=1

客户端请求头不变

服务端响应

Content-Encoding:gzip
Content-Type:text/html;charset=UTF-8
Date:Wed, 30 Jan 2019 08:20:50 GMT
Transfer-Encoding:chunked
Vary:Accept-Encoding

三、缓存控制和缓存校验

3.1、使用chrome的开发者模式

首先浏览器请求某个URL地址，并在请求的开始部分头(head) 设置属性accept-encoding值为gzip、deflate，表明浏览器支持gzip和def

　　第一部分General是概要，包含请求地址，请求方式，状态码，服务器地址以及Referrer 策略。
　　第二部分是应答头部，是服务器返回的。
　　第三部分是请求头部，是客户端发送的。

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

1、通用首部字段

2、请求首部字段

3、响应首部字段

4、实体首部字段

3.2、Http 1.0 缓存控制方式

　　在 http1.0 时代，给客户端设定缓存方式可通过两个字段——Pragma和Expires来规范。虽然这两个字段早可抛弃，但为了做http协议的向下兼容，你还是可以看到很多网站依旧会带上这两个字段。例如在访问个别网站的时候，通过浏览器调试工具可以看到部分HTTP响应是包含Expires头部的。

3.2.1、Pragma-禁用缓存

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

3.2.2、Expires-启用缓存和缓存时间

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

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

3.3、Http 1.1 缓存控制

　　缓存控制由服务器端发送一组HTTP头信息，他将会控制用户浏览器如何缓存资源。

　　如果一个报文中同时出现Pragma和Cache-Control时，以Pragma为准。同时出现Cache-Control和Expires时，以Cache-Control为准。

　　即优先级从高到低是 Pragma -> Cache-Control -> Expires

3.3.1、Cache-Control

1、前提注意：

　　符合缓存策略时，服务器不会发送新的资源，但不是说客户端和服务器就没有会话了，客户端还是会发请求到服务器的。
　　Cache-Control除了在响应中使用，在请求中也可以使用。我们用开发者工具来模拟下请求时带上Cache-Control：勾选Disable cache，刷新页面，可以看到Request Headers中有个字段Cache-Control: no-cache。
　　同时在Response Headers中也能到Cache-Control字段，它的值是must-revalidate，这是服务端设置的。

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

"Cache-Control" ":" cache-directive

2、Http Status 304 说明

　　Http status 304 当一个客户端（通常是浏览器）向web服务器发送一个请求，如果web服务器返回304响应，他不包含任何响应的内容，只是提示客户端缓存的内容是最新的，可以直接使用。这种方法可以节省带宽，避免重复响应。

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

字段名称	说明
no-cache	告知（代理）服务器不直接使用缓存，要求向原服务器发起请求
no-store	所有内容都不会被保存到缓存或Internet临时文件中
max-age=delta-seconds	告知服务器客户端希望接收一个存在时间（age）不大于delta-seconds秒的资源
max-stale[=delta-seconds]	告知（代理）服务器客户端愿意接收一个超过缓存时间的资源，若有定义 delta-seconds则为delta-srconds秒，若没有则为任意超出的时间
min-freash=delta-seconds	告知（代理）服务器客户端希望接收一个在小于delta-seconds秒内被更新过的资源
no-transform	告知（代理）服务器客户端希望获取实体数据没有被转换（比如压缩）过的资源
only-if-cached	告知（代理）服务器客户端希望获取缓存的内容（若有），而不用向原服务器发去请求
cache-extension	自定义扩展值，若服务器器不识别该值将被忽略

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

字段名称	说明
public	表名任何情况下都得缓存该资源（即使是需要http认证的资源）
Private[="field-name"]	表明返回报文中全部或部分（若指定了field-name则为field-name的字段数据）仅开放给某些用户（服务器指定的share-user，如代理服务器）做缓存使用，其他用户则不能缓存这些数据
no-cache	不直接使用缓存，要求向服务器发起（新鲜度校验）请求
no-store	所有内容都不会被保存到缓存或Internet临时文件中
max-age=delta-seconds	告知客户端该资源在delta-seconds秒内是新鲜的，无需向服务器发请求
s-maxage=delta-seconds	同max-age，但仅应用于共享缓存（如代理）
no-transform	告知客户端缓存文件时不得对实体数据做任何改变
only-if-cached	告知（代理）服务器客户端希望获取缓存的内容（若有），而不用向原服务器发去请求
must-revalidate	当前资源一定是向原服务器发去验证请求的，若请求失败会返回504（而非代理服务器上的缓存）
proxy-revalidate	与must-revalidate类似，但仅能应用于共享缓存（如代理）
cache-extension	自定义扩展值，若服务器器不识别该值将被忽略

5、no-store优先级最高

　　在Cache-Control 中，这些值可以自由组合，多个值如果冲突时，也是有优先级的，而no-store优先级最高。本地不保存，每次都需要服务器发送资源。

6、public和private的选择

　　如果你用了CDN，你需要关注下这个值。CDN厂商一般会要求cache-control的值为public，提升缓存命中率。如果你的缓存命中率很低，而访问量很大的话，可以看下是不是设置了private，no-cache这类的值。如果定义了max-age，可以不用再定义public，它们的意义是一样的。

7、max-age

　　max-age：用来指定引用文档过期时间【如页面内引用的js文件等】。　　　　

　　　　max-age>0 时页面内引用的资源直接从游览器缓存中提取，此时http status是304，无论被引用的资源服务器端是否改变，可以查看

　　　　　　示例：第一次请求，test.html,test.js的http status均是200

　　　　　　第二次请求，test.html的http status是304，test.js[引用资源]的http status是200，但是数据来自缓存

　　　　　　第三次请求，修改服务端js，后请求，因为max-age=30000，test.html的http status是304，test.js[引用资源]的http status是200，但是数据来自缓存

　　　　max-age<=0 时页面或页面内引用的资源都会向server发送http请求，请求确认该资源是否有修改有的话返回200 ,无的话返回304。

　　　　　　第一次请求，test.html,test.js的http status均是200

　　　　　　第二次请求，test.html,test.js的http status均是304

　　　　　　第三次请求，修改远端js，客户端重新获取，test.html的http status是304，test.js[引用资源]的http status是200，数据来自服务端，size不是from cache

　　　　注意：无论max-age什么值，单独请求回车刷新是会发请求的如果服务器端的文件没有产生变化，那么会返回304，比如单独访问一个js

3.4、缓存校验

　　在缓存中，我们需要一个机制来验证缓存是否有效。比如服务器的资源更新了，客户端需要及时刷新缓存；又或者客户端的资源过了有效期，但服务器上的资源还是旧的，此时并不需要重新发送。缓存校验就是用来解决这些问题的，在http 1.1 中，我们主要关注下Last-Modified 和 etag 这两个字段。

　　HTTP提供了自带的缓存框架。你需要做的是在返回的时候加入一些返回头信息，在接受输入的时候加入输入验证。基本两种方法：

　　　ETag：当生成请求的时候，在HTTP头里面加入ETag，其中包含请求的校验和和哈希值，这个值和在输入变化的时候也应该变化。如果输入的HTTP请求包含IF-NONE-MATCH头以及一个ETag值，那么API应该返回304 not modified状态码，而不是常规的输出结果。

　　　Last-Modified：和etag一样，只是多了一个时间戳。返回头里的Last-Modified：包含了 RFC 1123 时间戳，它和IF-MODIFIED-SINCE一致。HTTP规范里面有三种date格式，服务器应该都能处理。

1、Last-Modified

　　服务端在返回资源时，会将该资源的最后更改时间通过Last-Modified字段返回给客户端。客户端下次请求时通过If-Modified-Since或者If-Unmodified-Since带上Last-Modified，服务端检查该时间是否与服务器的最后修改时间一致：如果一致，则返回304状态码，不返回资源；如果不一致则返回200和修改后的资源，并带上新的时间。

　　If-Modified-Since和If-Unmodified-Since的区别是：
　　　　If-Modified-Since：告诉服务器如果时间一致，返回状态码304
　　　　If-Unmodified-Since：告诉服务器如果时间不一致，返回状态码412

2、etag

　　单纯的以修改时间来判断还是有缺陷，比如文件的最后修改时间变了，但内容没变。对于这样的情况，我们可以使用etag来处理。
　　etag的方式是这样：服务器通过某个算法对资源进行计算，取得一串值(类似于文件的md5值)，之后将该值通过etag返回给客户端，客户端下次请求时通过If-None-Match或If-Match带上该值，服务器对该值进行对比校验：如果一致则不要返回资源。

　　If-None-Match和If-Match的区别是：
　　　　If-None-Match：告诉服务器如果一致，返回状态码304，不一致则返回资源
　　　　If-Match：告诉服务器如果不一致，返回状态码412

3.5、小结

　　1、缓存开关是： pragma， cache-control。

　　2、缓存校验有：Expires，Last-Modified，etag。需要兼容HTTP1.0的时候需要使用Expires，不然可以考虑直接使用Cache-Control。需要处理一秒内多次修改的情况，或者其他Last-Modified处理不了的情况，才使用ETag，否则使用Last-Modified。

　　3、缓存头部对比

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

　　3、从状态码的角度来看，它们的关系如下图：

　　4、cache-control的各个值关系如下图

　　原文参看地址：https://imweb.io/topic/5795dcb6fb312541492eda8c

3.6、用户刷新访问行为

1、在URI输入栏中输入然后回车/通过书签访问

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

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

　　F5的作用和直接在URI输入栏中输入然后回车是不一样的，F5会让浏览器无论如何都发一个HTTP Request给Server，即使先前的响应中有Expires头部。

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

3、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

3.7、避免过度304

　　可以通过标识文件版本名、加长缓存时间的方式来减少304响应。

　　如果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

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

posted @ 2019-02-11 11:16 bjlhx15 阅读(908) 评论(1) 编辑收藏举报

刷新页面返回顶部