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

2019年12月07日 阅读数:20
这篇文章主要向大家介绍005-优化web请求一-gzip压缩、http缓存控制和缓存校验[Pragma、Expires、Cache-Control、max-age、Last-Modified、用户刷新访问、避免过分304],主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

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

1、模板缓存

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

2、Gzip压缩

  Gzip是一种可以被浏览器直接理解的压缩算法。服务器会提供压缩响应,会耗一些cpu,可是减小带宽css

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

  GZIP压缩时,WEB服务器与浏览器之间的协商过程以下:前端

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

2、WEB服务器接收到请求后判断浏览器是否支持GZIP压缩,若是支持就传送压缩后的响应内容,不然传送不通过压缩的内容;

三、浏览器获取响应内容后,判断内容是否被压缩,若是是压缩文件则解压缩,而后显示响应页面的内容。

在Springboot中配置gzipjava

# 是否启用压缩 默认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

测试一、未开启压缩web

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

客户端请求头ajax

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

测试二、开启压缩spring

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

客户端请求头不变chrome

服务端响应

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、缓存控制和缓存校验

3.一、使用chrome的开发者模式

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

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

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

一、通用首部字段

  

二、请求首部字段

  

三、响应首部字段

  

四、实体首部字段

  

3.二、Http 1.0 缓存控制方式

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

3.2.一、Pragma-禁用缓存

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

3.2.二、Expires-启用缓存和缓存时间

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

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

3.三、Http 1.1 缓存控制

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

  若是一个报文中同时出现Pragma和Cache-Control时,以Pragma为准。同时出现Cache-Control和Expires时,以Cache-Control为准。

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

3.3.一、Cache-Control

一、前提注意:

  符合缓存策略时,服务器不会发送新的资源,但不是说客户端和服务器就没有会话了,客户端仍是会发请求到服务器的。
  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

二、Http Status 304 说明

  Http status 304 当一个客户端(一般是浏览器)向web服务器发送一个请求,若是web服务器返回304响应,他不包含任何响应的内容,只是提示客户端缓存的内容是最新的,能够直接使用。这种方法能够节省带宽,避免重复响应。

三、做为请求首部时,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 自定义扩展值,若服务器器不识别该值将被忽略
   

四、做为响应首部时,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 自定义扩展值,若服务器器不识别该值将被忽略
   

五、no-store优先级最高

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

六、public和private的选择

  若是你用了CDN,你须要关注下这个值。CDN厂商通常会要求cache-control的值为public,提高缓存命中率。若是你的缓存命中率很低,而访问量很大的话,能够看下是否是设置了private,no-cache这类的值。若是定义了max-age,能够不用再定义public,它们的意义是同样的。

七、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.四、缓存校验

  在缓存中,咱们须要一个机制来验证缓存是否有效。好比服务器的资源更新了,客户端须要及时刷新缓存;又或者客户端的资源过了有效期,但服务器上的资源仍是旧的,此时并不须要从新发送。缓存校验就是用来解决这些问题的,在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格式,服务器应该都能处理。

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

二、etag

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

  If-None-Match和If-Match的区别是:
    If-None-Match:告诉服务器若是一致,返回状态码304,不一致则返回资源
    If-Match:告诉服务器若是不一致,返回状态码412

3.五、小结

  一、缓存开关是: pragma, cache-control。

  二、缓存校验有:Expires,Last-Modified,etag。须要兼容HTTP1.0的时候须要使用Expires,否则能够考虑直接使用Cache-Control。须要处理一秒内屡次修改的状况,或者其余Last-Modified处理不了的状况,才使用ETag,不然使用Last-Modified。

  三、缓存头部对比

头部 优点和特色 劣势和问题
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不匹配的状况。


  三、从状态码的角度来看,它们的关系以下图:

        

  四、cache-control的各个值关系以下图

    

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

3.六、用户刷新访问行为

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

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

二、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很少,网页很快就刷新了。

三、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.七、避免过分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)。