一、浏览器缓存
1，第一次请求，无缓存请求过程
流程如下所示
第二次请求，有缓存请求的过程
流程如下图所示
浏览器的缓存分为二种，第一种的是强缓存，另外一种是协商缓存
2 ：强缓存
定义：强缓存在请求资源的时候，会从header里面读取是否是强缓存，在有效的时间时间期内，从缓存里读取不能从服务那里读取
介绍使用：
expires，这是http1.0时的规范；它的值为一个绝对时间的GMT格式的时间字符串，如Mon, 10 Jun 2015 21:31:12 GMT，如果发送请求的时间在expires之前，那么本地缓存始终有效，否则就会发送请求到服务器来获取资源
cache-control：的含义和使用
可缓存性属性说明
pubilc:http只要经过的地方都要进行缓存
privite：发出的浏览器端要进行缓存
no-cache:本地可以有缓存，需要服务器验证才可以使用
no-store:本地和服务器都没有缓存
max-age=<seconds> ：缓存的最大的时间
3，代码案例分析：
1，简单的创建一个服务
const http = require('http');
const fs = require('fs');
// 创建一个http服务
http.createServer((request, response) => {
console.log('request-url' + request.url);
if (request.url === '/') {
const html = fs.readFileSync('test.html', 'utf8');
response.writeHead(200, {
'Content-Type': 'text/html',
})
response.end(html);
}
if (request.url === '/script.js') {
// const html = fs.readFileSync('test.html', 'utf8');
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Cache-control': 'max-age=200 ',
})
response.end('ffff');
}
}).listen(8888);
4，解决的方法呢：
上面说到，使用强缓存时，浏览器不会发送请求到服务端，根据设置的缓存时间浏览器一直从缓存中获取资源，在这期间若资源产生了变化，浏览器就在缓存期内就一直得不到最新的资源，那么如何防止这种事情发生呢？
通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。
前端常常后面加上版本号和一些hash值重新的读取
二、介绍协商缓存
协商缓存都是由服务器来确定缓存资源是否可用的，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问，这主要涉及到下面两组header字段，这两组搭档都是成对出现的，即第一次请求的响应头带上某个字段（Last-Modified或者Etag），则后续请求则会带上对应的请求字段（If-Modified-Since或者If-None-Match），若响应头没有Last-Modified或者Etag字段，则请求头也不会有对应的字段。
Last-Modified/If-Modified-Since
二者的值都是GMT格式的时间字符串，具体过程：浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上Last-Modified的header，这个header表示这个资源在服务器上的最后修改时间
浏览器再次跟服务器请求这个资源时，在request的header上加上If-Modified-Since的header，这个header的值就是上一次请求时返回的Last-Modified的值
服务器再次收到资源请求时，根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。当服务器返回304 Not Modified的响应时，response header中不会再添加Last-Modified的header，因为既然资源没有变化，那么Last-Modified也就不会改变，这是服务器返回304时的response header
浏览器收到304的响应后，就会从缓存中加载资源
如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified的Header在重新加载的时候会被更新，下次请求时，If-Modified-Since会启用上次返回的Last-Modified值
Etag/If-None-Match
这两个值是由服务器生成的每个资源的唯一标识字符串，只要资源有变化就这个值就会改变；其判断过程与Last-Modified/If-Modified-Since类似，与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。
3、既生Last-Modified何生Etag
你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：
一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
某些服务器不能精确的得到文件的最后修改时间。
这时，利用Etag能够更加准确的控制缓存，因为Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。
Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。
4，代码案例
if (etag === '777') {
response.writeHead(304, {
'Content-Type': 'text/javascript',
'Cache-control': 'max-age=200000,no-cache',
'last-Modified': '123',
'Etag': '777',
})
response.end('');
} else {
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Cache-control': 'max-age=200000,no-cache',
'last-Modified': '123',
'Etag': '777',
})
response.end('fffff');
}
三、强缓存与协商缓存的区别，可以用下表来进行描述：
| 获取资源形式 | 状态码 | 发送请求到服务器 | |
| 强缓存 | 从缓存取 | 200（from cache） | 否，直接从缓存取 |
| 协商缓存 | 从缓存取 | 304（not modified） | 是，正如其名，通过服务器来告知缓存是否可用 |