Http缓存机制

时间  2019-11-10
标签 http 缓存 机制 栏目 HTTP/TCP 繁體版
原文   原文链接

前言

Http简介

浏览器和服务器之间通讯是经过HTTP协议，HTTP协议永远都是客户端发起请求，服务器回送响应。模型以下：html

clipboard.png

HTTP报文就是浏览器和服务器间通讯时发送及响应的数据块。浏览器向服务器请求数据，发送请求(request)报文；服务器向浏览器返回数据，返回响应(response)报文。报文信息主要分为两部分：前端

报文头部：一些附加信息（cookie，缓存信息等），与缓存相关的规则信息，均包含在头部中
数据主体部分：HTTP请求真正想要传输的数据内容数据库

缓存的做用

咱们为何使用缓存，是由于缓存能够给咱们的 Web 项目带来如下好处，以提升性能和用户体验。express

加快了浏览器加载网页的速度；
减小了冗余的数据传输，节省网络流量和带宽；
减小服务器的负担，大大提升了网站的性能。浏览器

因为从本地缓存读取静态资源，加快浏览器的网页加载速度是必定的，也确实的减小了数据传输，就提升网站性能来讲，可能一两个用户的访问对于减少服务器的负担没有明显效果，但若是这个网站在高并发的状况下，使用缓存对于减少服务器压力和整个网站的性能都会发生质的变化。缓存

原始模型（不是用缓存）

搭建一个Express的服务器，不加任何缓存信息头：服务器

const express = require('express');
const app = express();
const port = 8080;
const fs = require('fs');
const path = require('path');

app.get('/',(req,res) => {
    res.send(`<!DOCTYPE html>
    <html lang="en">
    <head>
        <title>Document</title>
    </head>
    <body>
        Http Cache Demo
        <script src="/demo.js"></script>
    </body>
    </html>`)
})

app.get('/demo.js',(req, res)=>{
    let jsPath = path.resolve(__dirname,'./static/js/demo.js');
    let cont = fs.readFileSync(jsPath);
    res.end(cont)
})

app.listen(port,()=>{
    console.log(`listen on ${port}`)    
})

咱们能够看到请求结果以下：cookie

clipboard.png

请求过程以下：网络

  1. 浏览器请求静态资源demo.js
  2. 服务器读取磁盘文件demo.js，返给浏览器
  3. 浏览器再次请求，服务器又从新读取磁盘文件 demo.js，返给浏览器。

循环请求。。并发

  看得出来这种请求方式的流量与请求次数有关，同时，缺点也很明显：

  • 浪费用户流量
  • 浪费服务器资源，服务器要读磁盘文件，而后发送文件到浏览器
  • 浏览器要等待js下载而且执行后才能渲染页面，影响用户体验

缓存规则

为了方便理解，咱们认为浏览器存在一个缓存数据库，用于存储缓存信息（实际上静态资源是被缓存到了内存和磁盘中），在浏览器第一次请求数据时，此时缓存数据库没有对应的缓存数据，则须要请求服务器，服务器会将缓存规则和数据返回，浏览器将缓存规则和数据存储进缓存数据库。

clipboard.png

当浏览器地址栏输入地址后请求的 index.html 是不会被缓存的，但 index.html 内部请求的其余资源会遵循缓存策略，HTTP 缓存有多种规则，根据是否须要向服务器发送请求主要分为两大类，强制缓存和协商缓存。

Http缓存的分类

Http缓存能够分为两大类，强制缓存（也称强缓存）和协商缓存。两类缓存规则不一样，强制缓存在缓存数据未失效的状况下，不须要再和服务器发生交互；而协商缓存，顾名思义，须要进行比较判断是否可使用缓存。
  两类缓存规则能够同时存在，强制缓存优先级高于协商缓存，也就是说，当执行强制缓存的规则时，若是缓存生效，直接使用缓存，再也不执行协商缓存规则。

强制缓存

强制缓存是第一次访问服务器获取数据后，在有效时间内不会再请求服务器，而是直接使用缓存数据，强制缓存的流程以下:

clipboard.png

强制缓存分为两种状况，Expires和Cache-Control。

Expires

Expires的值是服务器告诉浏览器的缓存过时时间（值为GMT时间，即格林尼治时间），即下一次请求时，若是浏览器端的当前时间尚未到达过时时间，则直接使用缓存数据。下面经过咱们的Express服务器来设置一下Expires响应头信息。

//其余代码...
const moment = require('moment');

app.get('/demo.js',(req, res)=>{
    let jsPath = path.resolve(__dirname,'./static/js/demo.js');
    let cont = fs.readFileSync(jsPath);
    res.setHeader('Expires', getGLNZ()) //2分钟
    res.end(cont)
})

function getGLNZ(){
    return moment().utc().add(2,'m').format('ddd, DD MMM YYYY HH:mm:ss')+' GMT';
}
//其余代码...

咱们在demo.js中添加了一个Expires响应头，不过因为是格林尼治时间，因此经过momentjs转换一下。第一次请求的时候仍是会向服务器发起请求，同时会把过时时间和文件一块儿返回给咱们；可是当咱们刷新的时候，才是见证奇迹的时刻：

clipboard.png

能够看出文件是直接从缓存（memory cache）中读取的，并无发起请求。咱们在这边设置过时时间为两分钟，两分钟事后能够刷新一下页面看到浏览器再次发送请求了。

  虽然这种方式添加了缓存控制，节省流量，可是仍是有如下几个问题的：

  • 因为浏览器时间和服务器时间不一样步，若是浏览器设置了一个很后的时间，过时时间一直没有用
  • 缓存过时后，无论文件有没有发生变化，服务器都会再次读取文件返回给浏览器

不过Expires 是HTTP 1.0的东西，如今默认浏览器均默认使用HTTP 1.1，因此它的做用基本忽略。

Cache-Control

针对浏览器和服务器时间不一样步，加入了新的缓存方案；此次服务器不是直接告诉浏览器过时时间，而是告诉一个相对时间Cache-Control=10秒，意思是10秒内，直接使用浏览器缓存。

Cache-Control各个值的含义：

**private**：客户端能够缓存；
**public**：客户端和代理服务器均可以缓存（对于前端而言，能够认为与 private 效果相同）；
**max-age=xxx**：缓存的内容将在 xxx 秒后过时（相对时间，秒为单位）；
**no-cache**：须要使用协商缓存（后面介绍）来验证数据是否过时；
**no-store**：全部内容都不会缓存，强制缓存和协商缓存都不会触发。
app.get('/demo.js',(req, res)=>{
    let jsPath = path.resolve(__dirname,'./static/js/demo.js');
    let cont = fs.readFileSync(jsPath);
    res.setHeader('Cache-Control', 'public,max-age=120') //2分钟
    res.end(cont)
})

clipboard.png

其实缓存的储存是内存和磁盘两个位置，由当前浏览器自己的策略决定，比较随机，从内存的缓存中取出的数据会显示 (from memory cache)，从磁盘的缓存中取出的数据会显示 (from disk cache)。

协商缓存

强制缓存的弊端很明显，即每次都是根据时间来判断缓存是否过时；可是当到达过时时间后，若是文件没有改动，再次去获取文件就有点浪费服务器的资源了。

协商缓存又叫对比缓存，设置协商缓存后，第一次访问服务器获取数据时，服务器会将数据和缓存标识一块儿返回给浏览器，客户端会将数据和标识存入缓存数据库中，下一次请求时，会先去缓存中取出缓存标识发送给服务器进行询问，当服务器数据更改时会更新标识，因此服务器拿到浏览器发来的标识进行对比，相同表明数据未更改，响应浏览器通知数据未更改，浏览器会去缓存中获取数据，若是标识不一样，表明服务器更改过数据，因此会将新的数据和新的标识返回浏览器，浏览器会将新的数据和标识存入缓存中，协商缓存的流程以下:

clipboard.png

协商缓存和强制缓存不一样的是，协商缓存每次请求都须要跟服务器通讯，并且命中缓存服务器返回状态码再也不是 200，而是 304。

协商缓存有两组报文结合使用：

  1. Last-Modified和If-Modified-Since
  2. ETag和If-None-Match

clipboard.png

Last-Modified

HTTP 1.0 版本中：
为了节省服务器的资源，再次改进方案。浏览器和服务器协商，服务器每次返回文件的同时，告诉浏览器文件在服务器上最近的修改时间。请求过程以下：

  1. 浏览器请求静态资源demo.js
  2. 服务器读取磁盘文件demo.js，返给浏览器，同时带上文件上次修改时间 Last-Modified（GMT标准格式）
  3. 当浏览器上的缓存文件过时时，浏览器带上请求头If-Modified-Since（等于上一次请求的Last-Modified）请求服务器
  4. 服务器比较请求头里的If-Modified-Since和文件的上次修改时间。若是果一致就继续使用本地缓存（304），若是不一致就再次返回文件内容和Last-Modified。
  5. 循环请求。。

代码实现过程以下：

app.get('/demo.js',(req, res)=>{
    let jsPath = path.resolve(__dirname,'./static/js/demo.js')
    let cont = fs.readFileSync(jsPath);
    let status = fs.statSync(jsPath)

    let lastModified = status.mtime.toUTCString()
    if(lastModified === req.headers['if-modified-since']){
        res.writeHead(304, 'Not Modified')
        res.end()
    } else {
        res.setHeader('Cache-Control', 'public,max-age=5')
        res.setHeader('Last-Modified', lastModified)
        res.writeHead(200, 'OK')
        res.end(cont)
    }
})

clipboard.png

虽然这个方案比前面三个方案有了进一步的优化，浏览器检测文件是否有修改，若是没有变化就再也不发送文件；可是仍是有如下缺点：

  • 因为Last-Modified修改时间是GMT时间，只能精确到秒，若是文件在1秒内有屡次改动，服务器并不知道文件有改动，浏览器拿不到最新的文件
  • 若是服务器上文件被屡次修改了可是内容却没有发生改变，服务器须要再次从新返回文件。

ETag

HTTP 1.1 版本中：
为了解决文件修改时间不精确带来的问题，服务器和浏览器再次协商，此次不返回时间，返回文件的惟一标识ETag。只有当文件内容改变时，ETag才改变。请求过程以下：

  • 浏览器请求静态资源demo.js
  • 服务器读取磁盘文件demo.js，返给浏览器，同时带上文件的惟一标识ETag
  • 当浏览器上的缓存文件过时时，浏览器带上请求头If-None-Match（等于上一次请求的ETag）请求服务器
  • 服务器比较请求头里的If-None-Match和文件的ETag。若是一致就继续使用本地缓存（304），若是不一致就再次返回文件内容和ETag。
  • 循环请求。。
const md5 = require('md5');

app.get('/demo.js',(req, res)=>{
    let jsPath = path.resolve(__dirname,'./static/js/demo.js');
    let cont = fs.readFileSync(jsPath);
    let etag = md5(cont);

    if(req.headers['if-none-match'] === etag){
        res.writeHead(304, 'Not Modified');
        res.end();
    } else {
        res.setHeader('ETag', etag);
        res.writeHead(200, 'OK');
        res.end(cont);
    }
})

请求结果以下：

clipboard.png

总结

为了使缓存策略更加健壮、灵活，HTTP 1.0 版本 和 HTTP 1.1 版本的缓存策略会同时使用，甚至强制缓存和协商缓存也会同时使用，对于强制缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接使用缓存，超出有效时间，执行协商缓存策略，对于协商缓存，将缓存信息中的 Etag 和 Last-Modified 经过请求头 If-None-Match 和 If-Modified-Since 发送给服务器，由服务器校验同时设置新的强制缓存，校验经过并返回 304 状态码时，浏览器直接使用缓存，若是协商缓存也未命中，则服务器从新设置协商缓存的标识。

关于Pragma

当该字段值为no-cache的时候，会告诉浏览器不要对该资源缓存，即每次都得向服务器发一次请求才行：

res.setHeader('Pragma', 'no-cache') //禁止缓存
res.setHeader('Cache-Control', 'public,max-age=120') //2分钟

经过Pragma来禁止缓存，经过Cache-Control设置两分钟缓存，可是从新访问咱们会发现浏览器会再次发起一次请求，说明了Pragma的优先级高于Cache-Control

缓存的优先级

Pragma > Cache-Control > Expires > ETag > Last-Modified
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程