首先附上前面提到的一张图：
根据上面的这张图，来说http协议中的缓存，也就是cache-control将会格外清晰。
Cache-Control包括哪些特性呢？
第一，可缓存性：public private no-cache。可缓存性指http的response进过的哪些地方可以进行缓存。public指在response返回经过的任何地方都可以缓存，包括代理服务器，客户端等，这样下次请求将不会到达服务端而直接返回response；private则表示只有返回的浏览器才可以进行缓存；no-cache则表示不可直接用缓存，而是先要到服务器端进行验证。
第二，到期：max-age=<seconds>，代表缓存的时间(秒)；s-maxage=<seconds>,专门为代理服务器设置，如果与max-age同时返回，则浏览器会读取max-age，而代理服务器则会读取s-maxage这个设置；max-stale=<seconds>，代表在max-age过期后，如果存在max-stale，而且其时间没有过期，则表示仍然可以用缓存，max-stale只在request发起端设置是有用的，又因为浏览器不会帮助我们带上这个头，所以客户端是浏览器的时候这个max-stale是用不到的。
第三，重新验证：must-revalidate和proxy-revalidate，这两个表示缓存过期时间到达以后，必须要到服务端重新请求和重新验证，这两个属性在浏览器也不怎么出现。
第四，其他，no-store，表示本地和代理服务器都不可以用缓存，必须去重新获取；no-transform，告诉代理服务器不要对返回的body进行处理，比如压缩等（代理服务器比如nginx等可以不遵守，但是这个是规范，最好遵守）。
下面附上做的几个简单的例子来加深对上面的理解。例子中通过查看对文件script.js的缓存情况说明问题。
执行node server.js，观察浏览器network如下图（这里注意，浏览器的Disable cache没有勾选，否则会默认忽略Cache-Control的设置）：
立刻重新刷新浏览器，则network中出现下图：
此时我们可以看见这事size一栏是from memory cache，因为我们设置max-age为20s，在这个期间即使我改变script.js的内容，浏览器仍然会用memory里面的内容，而得不到更新。很显然实际开发中，如果出现这样的问题，是很可怕的。同时如果每次去后端请求response，又会使网页很慢，实际中max-age往往要设置很大，表示在本地保存很久的时间，那么下次请求的Time为0。那么实际开发中，如何去解决这两者的矛盾呢？就是通过改变url的方法，在请求的文件名后面加上根据内容生成的哈希值（刷新浏览器缓存的方案），这样实际请求的url将会改变，那么自然就会去重新请求，如果后端的文件没有更新，也就是url没有变，则自然会在缓存中读取，则不需要经过网络传输，则速度是很快的，用户体验是很好的。network一栏中，这里Size的两个值，上面表示传输时候的大小，下面表示实际的大小（上面的可进行压缩Gzip传输，但是不晓得header可不可以压缩，貌似http2中支持头压缩），传输时的大小比实际的大，因为加上了头信息。Time的两个值，上面一行表示从请求开始到接受完最后一个byte为止的时间。下面一行是Latency，代表从请求接受完到读取该资源第一个byte之间的等待时间。
上图是查找缓存的过程。
如果Cache-Control中max-age的值设置很大，那么一直用本地的缓存肯定是不可取的。所以除了给文件名后面加上哈希码之外的方法，我们可以通过每次去后端询问是否文件有所改动？那么如何来实现这个过程呢？首先在Cache-Control中设置no-cache，同时遵从实际情况我们把max-age设置很大。更改servr.js如下：
打开network，多次刷新仍然如下：
说明此时已经不在缓存中读取了，即使我们的max-age设置很大，这是因为我们设置了no-cache。所以每次我们都不会直接使用缓存了。那么如何发挥no-cache的作用呢，还需要配合资源验证，资源验证在http中主要有两个头:Last-Modified和Etag。这个内容介绍在-资源验证Last-Modified和Etag中介绍。
