非HTTP协议定义的缓存机制
浏览器缓存机制，其实主要就是HTTP协议定义的缓存机制（如： Expires； Cache-control等）。但是也有非HTTP协议定义的缓存机制，如使用HTML Meta 标签，Web开发者可以在HTML页面的<head>节点中加入<meta>标签，代码如下：
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
上述代码的作用是告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取。使用上很简单，但只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。下面主要介绍HTTP协议定义的缓存机制。
大话浏览器缓存浏览器缓存一直是一个让人又爱又恨的存在，一方面极大地提升了用户体验，而另一方面有时会因为读取了缓存而展示了“错误”的东西，而在开发过程中千方百计地想把缓存禁掉。
那么浏览器缓存机制到底是如何工作的呢？核心就是把缓存的内容保存在了本地，而不用每次都向服务端发送相同的请求，设想下每次都打开相同的页面，而在第一次打开的同时，将下载的js、css、图片等“保存”在了本地，而之后的请求每次都在本地读取，效率是不是高了很多？真正的浏览器工作的时候并不是将完整的内容保存在本地，各种浏览器都有不同的方式，譬如firefox是一种类似innodb的方式存储的key value 的模式，在地址栏中输入 about:cache 可以看见缓存的文件，chrome会把缓存的文件保存在一个叫User Data的文件夹下。但是如果每次都读取缓存也会存在一定的问题，如果服务端的文件更新了呢？这时服务端就会和客户端约定一个有效期，譬如说服务端告诉客户端1天内我服务端的文件不会更新，你就放心地读取缓存吧，于是在这一天里每次遇到相同的请求客户端都开心地可以读取缓存里的文件。但是如果一天过去了，客户端又要读取该文件了，发现和服务端约定的有效期过了，于是就会向服务端发送请求，试图下载一个新的文件，但是很有可能服务端的文件其实并没有更新，其实还是可以读取缓存的。这时该怎么判断服务端的文件有没有更新呢？有两种方式，第一种在上一次服务端告诉客户端约定的有效期的同时，告诉客户端该文件最后修改的时间，当再次试图从服务端下载该文件的时候，check下该文件有没有更新（对比最后修改时间），如果没有，则读取缓存；第二种方式是在上一次服务端告诉客户端约定有效期的同时，同时告诉客户端该文件的版本号，当服务端文件更新的时候，改变版本号，再次发送请求的时候check一下版本号是否一致就行了，如一致，则可直接读取缓存。
而事实上真正的浏览器缓存机制大抵也是如此，接下来就可以分别对号入座了。
需要注意的是，浏览器会在第一次请求完服务器后得到响应，我们可以在服务器中设置这些响应，从而达到在以后的请求中尽量减少甚至不从服务器获取资源的目的。浏览器是依靠请求和响应中的的头信息来控制缓存的。
Expires与Cache-ControlExpires和Cache-Control就是服务端用来约定和客户端的有效时间的。
比如如上一个响应头，Expires规定了缓存失效时间（Date为当前时间），而Cache-Control的max-age规定了缓存有效时间（2552s），理论上这两个值计算出的有效时间应该是相同的（上图好像不一致）。Expires是HTTP1.0的东西，而Cache-Control是HTTP1.1的，规定如果max-age和Expires同时存在，前者优先级高于后者。Cache-Control的参数可以设置很多值，譬如（参考浏览器缓存机制）：
而Last-Modified/If-Modified-Since就是上面说的当有效期过后，check服务端文件是否更新的第一种方式，要配合Cache-Control使用。比如第一次访问我的主页simplify the life，会请求一个jquery文件，响应头返回如下信息：
然后我在主页按下ctrl+r刷新，因为ctrl+r会默认跳过max-age和Expires的检验直接去向服务器发送请求（下文再探讨各种刷新后如何读取缓存），我们看看请求截图：
