第一部分： 浏览器缓存如何控制？
最近在做网站，但是不知道缓存是什么东西怎么能行！ 如何实现HTTP缓存呢？ 下面我们来一步一步的探寻实现机制把。
方案一： 无缓存
说明： 浏览器向服务器请求资源m.png, 然后服务器响应请求--找到对应的m.png后发送给浏览器。 之后，浏览器再次向服务器请求m.png， 服务器又发回了同样的一张图片....循环往复.....
优点： 浏览器请求，服务器响应，思路清楚简单容易实现。
缺点 ： 每次我都请求同样的资源时， 服务器也在不断地响应，这是非常浪费带宽的。
方案二：有缓存-无更新
说明： 同样，浏览器向服务器请求资源ｍ.png,然后服务器找到后发送给浏览器，这时浏览器把m.png保存在本地（缓存）, 这样以后每次再请求m.png时就不需要向服务器要了，直接从本地取就行了，但是下次这个m.png的内容换了呢？
优点： 节省带宽（显然的，后续直接从本地取资源即可）。
缺点： 如果服务器上的m.png内容改变，我就不能得到改变后的资源了，而是始终拿到本地的资源。
方案三： 有缓存-有更新
说明： 浏览器向服务器请求资源m.png，然后服务器找到后发送给服务器，同时还附带额外信息---过期时间，如Expires: Friday,26 Feb 2017 10:11:22GMT。 然后浏览器将图片和过期时间同时保存在本地。
浏览器第二次向服务器请求资源，这时它会先查看过期事件是否已经达到，如果在过期事件之内，就直接使用本地缓存（状态304）； 如果超出了这个过期时间，就重新向服务器发送请求，服务器再次发回最新资源和最新的过期时间， 浏览器再次保存...
优点： 一方面可以在过期时间之内就可以不再重新请求资源，节省了带宽；另一方面也不会像第二种方案一样，而是可以得到新资源。
缺点： 在过期时间之后就要重新请求资源，但是如果资源内容没改变呢？ 这次拿回的资源不就浪费了带宽吗？除此之外，这种时间格式复杂，容易比对出错。
方案四： 有缓存-有更新-更新机制加强
说明： 刚才的更新机制是发送来过期时间，而现在服务器在发送资源给浏览器的时候不再发送具体的时间，而是发送一个Cache-Control,这里可以包含各种信息。如Cache-Control: max-age=300; 这种方式和上面方案类似， 只是时间过期使用数字，不容易出错。另外Cache-Control还可以是下面的一些值：
- Public---表示服务器发送的资源可以被任何中间节点缓存，如 Server -> proxy1 -> proxy2 -> Browser，proxy1 和 proxy2也可以缓存资源，这样，下次请求时proxy2就可以返回资源。
- Private---表示服务器发送的资源不可以被任何中间节点缓存。
- no-cache---表示不使用Cache-Control的缓存控制方式（强缓存），而是使用Etag 或者 Last-Modified（协商缓存）字段来控制缓存。
- no-store---表示真正地不用缓存方式（每次都请求最新的资源），Etah和Last-Modified也不用。
- max-age---表示当前资源的有效时间（就是强制缓存，用于替代HTTP1.0的Expires的方案）。
优点 ： 使用max-age更加容易比对，其他的几个值使得缓存机制更加强大。 缺点：同方案三，有可能导致浪费带宽。
方案五： 有缓存-有更新-更新机制完美
说明：为了解决方案四在300s后请求资源时得到了并未更新的资源而导致浪费带宽的情况，我们在给浏览器返回m.png图片时，不仅需要附加 Cache-Control: max-age=300; 再发送一个ETag字段,如 Etag:W/"e-dafdajio54fdaadf/q5w"。 然后浏览器将图片和两个附加信息都保存起来， 300s内请求资源时，就从本地取，300s后请求资源时就将之前拿到的ETag信息随着请求发出，服务器接受到请求后先比对得到的ETag和服务器处图片当前的ETag，如果相同，则表示图片内容没变，就发送消息（不包含图片，304）；如果ETag改变，就发送新的m.png并且再发送一个新的Etag给浏览器保存，那么这时的max-age应该也是同样需要更新的，如此循环往复......
与Etag功能类似的是Last-Modified/if-Modified-Since ，当资源过期时（max-age超时），发现资源具有Last-Modified声明（是浏览器接收到的资源最新被修改的时间），于是发送请求时带上If-Modified-Since（即刚才的Last-Modified的时间）,web服务器收到请求时，将If-Modeified-Since时间的资源与当前资源对比， 如果没变， 就响应HTTP304，让浏览器使用缓存， 如果不是，就发送新的资源。
第二部分： 在url框中回车、F5 和 Ctrl + F5的区别是什么？
不少同学问，不都是刷新吗？还有什么区别？其实，还是有的。不同的方式会控制不同的缓存策略。
其中，在地址栏按回车又分为两种情况。一是请求的URI在浏览器缓存中未过期，此时，使用Firefox的firebug插件在浏览器里显示的HTTP请求消息头如下：
Host 192.168.3.174:8080
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language zh-cn,zh;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7
Connection keep-alive
HTTP返回状态显示200
OK，但是，后台Nginx服务器的access.log并没有找到该请求的记录，说明请求并没有真正提交到HTTP服务器。而是被浏览器发现缓存中还有
未过期的文件，直接把请求拦截了，firebug里面显示所谓的“请求头消息”、“响应头消息”都是浏览器“伪造”的。这种刷新，使用的网络流量是最小
的，可以说完全没有，时间消耗也是最少的。就像你找到一盒没有过期的牛奶，觉得肯定没有问题，谁都没告诉就喝了。
二是请求的URI在浏览器缓存中已过期，此时，firebug显示的HTTP请求消息头如下：
Host 192.168.3.174:8080
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language zh-cn,zh;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7
Connection keep-alive
If-Modified-Since Mon, 04 Jul 2011 10:12:40 GMT
多了一行If-Modified-Since，后台Nginx服务器的access.log也找到了该请求的记录，说明浏览器对这种情况的处理方法是：再
问一下服务器，请求的URI在某个时间之后有没有被修改过，而这个时间是由上次HTTP响应的Last-Modified决定的。服务器鉴定之后，没有修
改的话，返回304 Not Modified，浏览器收到后，从缓存里读出内容；有修改的话，返回200 OK，并返回新的内容。这种情况，就像你找到一盒已经过期的牛奶，于是问别人，还能不能喝，如果别人说可以，你就把它喝了，如果别人说不行，那你得就另外
找一盒新鲜的牛奶。
至于F5刷新，其HTTP请求消息头如下：
Host 192.168.3.174:8080
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language zh-cn,zh;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7
Connection keep-alive
If-Modified-Since Mon, 04 Jul 2011 10:12:40 GMT
Cache-Control max-age=0
又多了一行Cache-Control: max-age=0，意思是说，我不管浏览器缓存中的文件过期没有，都去服务器询问一下，相当于上次HTTP响应的Expires暂时失效。服务器的响应 处理流程同上。这种情况，就像你找到一盒牛奶，没有看它的有效期，直接就问别人能不能喝。
最后是Ctrl+F5刷新，其HTTP请求消息头如下：
Host 192.168.3.174:8080
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language zh-cn,zh;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset GB2312,utf-8;q=0.7,*;q=0.7
Connection keep-alive
Pragma no-cache
Cache-Control no-cache
If-Modified-Since没有了，Cache-Control换成了no-cache，此外Pragma行是为了兼容HTTP1.0，作用与
Cache-Control:
no-cache是一样的。意思是，我不要缓存中的文件了，强制刷新，直接到服务器上重新下载，于是服务器的响应处理与首次请求这个URI一样，返回
200 OK和新的内容。这种刷新，使用的网络流量是最大的，也是最耗时的。这就像你虽然发现了一盒牛奶，但是把它扔掉了，直接去买一盒新的。