HTTP Cache
在HTTP1.1中caching的作用一是在很多情况下消除向服务器发送请求，二是一些情况下消除发送完整response的需要。 前者减少了许多操作网络来回通信的数量，使用“过期”的机制来达到此目的；后者减少了网络带宽的需求，我们使用“确认”机制来达到此目的。
庆幸的是所有浏览器都有HTTP Cache的实现。 开发者只要保证每个服务器端的响应提供了正确的HTTP header指令去知道浏览器 响应可以被浏览器何时cache，cache多久。
**每个response的header的信息：**
Http 响应码：
Content-Length: 1024 表示这个response有1024字节的大小
Cache-Control: max-age=120 表示client可以cache这个response最长120秒
Etag: "x234dff" 这个确认记号可以在response过期之后来check这个资源是否被修改了。
举一个具体的例子，假设初始获取的response已经过了120秒，浏览器会发起一个对同样资源的新的请求。 首先，浏览器检查本地的cache并找到了之前的response，不幸的是它已经过期了。 这个时候可以简单地重新发起一个请求获得一个新的response，但这是没有效率的，因为如果response的内容没有改变那么我们就没有理由重新下载一个一样的文件。这是Validation token（即header中的Etag）所解决的问题：服务器生成并返回一个由文件内容独有的特征生成的一个记号。Client不需要知道这个记号是怎么生成的，只需要在下一次请求中把这个token发到服务器端。 如果记号一致，那么就是资源没有change，不需要重新下载。
那么作为一个web开发者所要做的就是确保服务器端提供了必要的Rtag tokens； 检查服务器文档和必要的配置项。
Cache-Control: 该指令控制谁可以cache响应，在什么情况下cache，cache多久。
最好的请求是不需要和服务器通信的：一个本地的复印件允许我们消除所有的网络延迟并避免了数据传输过程中的数据丢失风险。
“no-cache”: 指返回的response不能在没有首先检查服务器的response是否改变的情况用来满足后继的对同一url的请求
“no-store”: 指不允许浏览器或其他的中间cache用来存储任何版本的response，即每次请求都必须下载。
“public”: 指该response可以被cache，即使它有HTTP认证。 通常该指令是不需要的，因为现实的cache信息通常有“max-age”
“private”: 指responses只能被一个单独的用户cache，不能被任何其他中间cache缓存，比如不能被CDN缓存。
“max-age” 
具体的cache policy参见该文章。
Ref: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en Http caching byiLya Grigorik
HTML5 APPCache
Here we go. H5的AppCache的动机是为web应用提供离线体验，具体上有三个优势：
- 离线浏览，用户可以离线在你整个站点内跳转（navigate）；
- 速度，资源可以从硬盘上读取而不用联网；
- 可条件性(Resilience)， 如果你的维护时挂掉了，你哟农户可以获得离线体验。
使用Appcache需要定义一个cache mannifest文件，来指定浏览器哪些资源可以被缓存。
启用application cache需啊哟在每个想要缓存的页面的html标签上加上一个manifest属性，like this:
这意味着任何用户跳转到的页面包含manifest属性的都建隐式地被加入application cache。像这样的”/page-url/”, “/page-url/?something”, “/page-url/?something-else”会被当成单独的页面，所以AppCache更好地用在单独的url上，实际上这也成为了它一个缺陷。
But, Application Cache is a douchebag. 参见http://alistapart.com/article/application-cache-is-a-douchebag 这篇文章。
Service Worker Cache
Service worker是一种独立于broswer js线程的proxy server，可以拦截站点的请求并做一些处理，同时提供了单独管理的cache用来缓存response。SW设计的初衷也是为了解决web应用的离线体验的问题，解决H5 Appcache的弊端。
三者的区别和联系：
SW的cache完全独立于HTTP Cache，完全由开发者自己手动管理和更新；
区别于H5 AppCache，SW是可以作用于整个site的， 即是可以跨页面的；且也为了避免上文提到的AppCache的一系列弊端；
http://blog.csdn.net/u010875425/article/details/50037963