‘壹’ APP中缓存、加载与刷新机制设计【转载】
1、为什么要加缓存？
场景一：【等待】，在向服务器请求新的数据时。我们让用户看到什么？第一种是漂亮的等待加载页面；第二种是缓存的内容。对于第二种，用户可以对页面进行操作，等待新数据时可以查看旧数据，更具有“可操作性”与“可用性”，从而减轻了从服务器获取数据这一动作的大小和时间长短，增强了用户体验。另一方面，如果内容更新的间隔较长或者用户刷新的间隔较短，在没有缓存的情况下，很多数据我们会多次重复的向服务器获取，增加了成本。
场景二：【结果】没有联网，或者在地铁上网络太差无法加载数据时，如果留给用户一个空白页面，实在是感觉有点不负责任啊。并且很多功能在没有联网的情况下也有使用的可能性，比如：APP中的通讯录，查看一些聊天记录，通知信息，文章列表等。因为用户打开APP不一定是要看新信息，说不定是回顾老信息（或许老信息里也有用户之前没看的），所以恰当的缓存可以满足更多的用户场景。
场景三：【金钱】有一天，一个用户发现自己装了某个APP后流量用的特别快，Ta可能永远将这个APP打入冷宫了，而增加缓存正是节省流量的一个方法。虽然节省的不多或者用户也察觉不到，但是作为一个有态度的产品经理，应该多做一些思考。
2、什么是缓存？
缓存可分为如下几类：
（1）app缓存。
（2）固定缓存。
（3）可手动清理的缓存。
（4）不可手动清理的缓存。
（5）临时缓存。
其中，临时缓存常用于一个功能页面内，保存各栏目的缓存。同一个功能里会把子功能分为多个栏目进行划分，每个标签栏目下的内容在本次使用中都可保存为临时缓存，在该功能里切换栏目，不需要重新加载数据，使用缓存显示。
对于用户来说，使用时达到了无缝切换浏览，对于服务器来说，在短时间内数据很少会有更新，所以在一般情况下能满足用户的正常需求，并达到体验优秀。
临时缓存的清理机制是：退出该功能模块就清除之前的缓存。也就是说下次进入该功能模块，需要重新获取一次数据。
很多时候我们都会用到临时缓存，因为那些信息真的不是那么重要，而且不需要经常反复查看，那对于那些我们经常使用而且经常需要反复查看的信息，马海祥建议采取固定缓存，保存在本地，方便下次翻阅时不需要再一次向服务器请求数据了。
对于固定缓存又会细分为可手动清理的缓存和不可手动清理的缓存。
第一种是我们最常见的缓存，几乎所有产品都采用这种缓存方式。平时用户浏览文章、图集加载的数据就以这种形式缓存在本地，下次看回这篇文章、图集时就不需要加载了。用户也可以手动把这些缓存清理了，释放空间。
而对于某些特殊场景，例如一些相对固定的数据，我们不愿意一开始就打包进App里，这样会占太大容量，造成产品包很大，也不愿意每次进入页面都向服务器加载这些信息，那怎么办？建议的解决方法就是我们可以只加载一次就永远存在本地了，这样安装包也不会大，以后也不用加载了。
3、如何清理缓存？
一般App都会在“设置”里提供一个清理缓存的功能，一键把空间释放。除此之外，App最好要设计自动清理机制，可以通过两个维度来设计这个机制。
（1）、时间
通过设定一个固定的时间，或者根据用户使用周期灵活设定时间来清理缓存。每个产品的场景不一，用户使用频率不一，设定这个机制的时候就需要结合实际情况考虑了。
（2）、容量
一般是设定一个容量上限，采用堆栈的设计原理进行缓存清理，溢出堆栈的旧数据将自动清除。
1、页面加载
方案1：单页面整体加载
这种加载比较简单，一般运用在页面内容比较单一的情况下，所以直接一次性加载完所有数据后再显示内容。其单页面加载失败的状态相对来说也比较好处理。
方案2：单页面分块加载
这种方案的特点是，能让用户逐步看到内容，在这个渐进的过程中降低用户的焦虑心理。
其中又可以分为，模块间有关联性的，先加载父内容，再加载子内容。如优酷，先把栏目加载出来，再加载各栏目的内容。
模块间没有绝对关联性的，可独自加载各自模块内容，根据请求的速度不同分别显示。这样处理有一定几率让用户在没完全刷出数据的情况下就能找到自己需要的功能，如大众点评、淘宝客户端等。
框架固定，内容更新的，可先把框架显示出来，再把各模块的数据各自加载显示，如各种iOS自带应用。
这种分模块加载的需要特别注意加载失败的状态，毕竟每个模块都提示加载失败，点击重试是很挫的一件事，可以根据信息的优先级来决定哪些数据失败了采用默认状态，哪些数据采用失败提示。
方案3：跨页面加载
父页面&子页面 or 同一app内，页面间字段可以复用的，在加载子页面时不需要重新加载新数据。
方案4：预加载
这种加载方式的特点是，在加载一个页面内容的同时，预测用户的下一步行为，并为他下一步需要使用的页面加载内容，使得他在下一步的操作中能立刻获取信息而不需要加载等待。
预加载提供给用户无缝的产品使用体验，使得用户在使用产品的过程中更直接流畅，没有被打断的感觉。
具体的例子有：
在浏览图集的时候，当看到第一张的图片时，就自动后台加载第二第三第四张图片，用户浏览完第一张图片切换到第二张时就不会有加载等待的过程。
在浏览新闻列表时，就把每篇新闻的内容在后台进行预加载，用户选择看某篇新闻时，能立刻阅读到内容。
但是这种方案也需要面临很多的问题，马海祥觉得最直接的就是流量问题，因为会自动跑掉很多用户可能根本用不上的数据流量，所以，一般情况下马海祥建议可以设定在wifi环境才采用这种加载模式。又或者设定加载规则，只把主要内容预加载，而部分次要内容可以在用户真的用到的时候才加载，例如预加载新闻正文的情况，可以只加载文本信息，图片信息等到用户进入内页才加载。这种预加载与分块加载结合的方式也普遍运用在各个场景。
另外，预加载也需要时间的，他只是不在客户端显示给用户，默默在后台运作而已，需要特殊考虑未加载完用户就使用到那些信息的情况，所以在做预加载设计时需要同时考虑另一种适合该情况的普通加载方式。
预加载需要根据具体的场景来进行设计，设定好信息优先级，综合考虑各种类型信息的具体大小流量，整体考虑预加载的方式，这些都是需要经过精心分析思考的。
随着网络环境的发展，预加载将成为以后产品普遍的加载方式，他提供给用户的无缝使用体验**地提升了产品的可用性。
2、操作加载
除了页面的信息需要加载，页面内的操作也是需要通过给服务器发送请求记录的。
方案1：加载层
进行一个操作后，弹出模态的提示层，告知用户正在加载。采用模态的提示主要是防止用户在该过程中进行其他操作，导致当前加载出错。由于采用模态的提示，并且有可能因为网络原因导致长时间处于加载状态，建议提供一个“关闭”的操作，中止本次加载，恢复App可用状态。加载失败时可在当前浮层变换为失败提示。模态提示层是最稳妥的方式，但他会使用户在使用过程中有打断的感觉。
方案2：控件自身加载状态
这种方式是把操作加载的状态与控件的样式结合起来了，对某个控件进行操作后，控件变换为加载状态，此时控件不能重复操作。由于这种加载方式是控件的自身状态，不影响其他操作，所以用户也可以对页面进行其他操作，可能会导致同时有多个请求的情况，增加了加载失败的风险，这也算是这种方式的弊端，不过这种极端情况很少出现。请求失败后，可配合Toast提示告知用户失败的原因。
方案3：后台加载
用户在操作后，客户端立刻反馈操作成功，然后把请求放到后台与服务器交互，这一过程用户不需要了解，不需要等待，在正常情况**验是非常棒的。
但是在极端情况下会出现一些莫名其妙的状况，由于是后台记录请求并与服务器交互，所以实际请求是否成功客户端是不说明的，全部以操作成功来显示，这就会导致用户误以为操作成功了，但实际上下次来看发现没有成功。
所以，这种加载方式是需要根据具体使用场景来权衡使用的，对于一些重要的操作，建议还是使用模态的方式加载，对于一些小操作，如点赞、订阅、关注，可采用后台加载的方式。
3、下一页加载还是当前也加载
用户进入首页，正式迈出体验的第一步，接下来迎接的就是基于用户目标的界面间跳转。完成界面的跳转，会有各种加载策略，但无论形式如何，我们都可以将其归为两大类：“下一页加载”、“当前页加载”。
（1）“下一页加载”满足了用户提前窥视的需求
我们把页面看成“点”，页面流是连接这些点的“线”，我们以“用户想买一条牛仔裤”这一场景作为案例做了简单的眼动研究，从应用启动到商品浏览再到商品确定最后进入下单页，用户所呈现的瞳孔梯次增大，即E>D>C>B>A，为了解释这一现象，通过与被试交流，我们发现相比于各种浏览，用户更期待看到他们想看到的东西。因此此时的”下一页加载“正好，满足了用户提前窥视的需求。
（2） Wait！I Need Think Think
我们以同样的方式又对“使用支付宝对手机充值”这一场景做了研究，从开始支付到二次确认支付，用户所呈现的瞳孔都比较大，即A与B近似相等，通过访谈，我们发现与“递增体验流”不同的是，当用户遇到判断逻辑的界面时，用户并非急于想看下一页面到底包含怎样的内容，而是非0即1的验证心态，即我的操作效成功了吗？因此在判断逻辑界面中，用户的内容窥视需求并不强，当然也没什么内容，要么仅是一个小小的Toast，再大一点就是一个简单的信息反馈界面（意味着“下一页加载”在这里就是个鸡肋），用户反而对非0即1的验证需求较为强烈，其中还伴随着等待结果过程中的紧张感、激动感，因此界面通过 当前页加载 表明系统正在努力地处理用户交代的指令**了用户的紧张感、激动感，直到结果显现——“处理成功”，完成了非0即1验证的满足感。
4、先加载还是先展示
当需加载的是功能时，可以先展示再加载，当需加载的是内容时，则反过来。
淘宝
打开APP的第一个页面是功能，所以先展示再加载的：
随便点击一个模块（不要点菜单），下面要展示的将要是内容（商品），所以是先加载再展示的，没有加载完都不展示：
京东
同样的，功能模块先展示后加载：
内容先加载，没加载完不展示：
两种方式各有利弊：
先展示，后加载：
优点：给用户0等待的错觉
缺点：当前数据有可能是错的，而且得等用户操作到最后一步才会发现
先加载，后展示：
优点：保证数据的质量和准确
缺点：网络不好时，造成等待
显然，功能模块对于一个产品来说是既有固定的，在短时间内几乎不会更新，所以这种数据出现错误或与当前状态不同的几率小得多，因此，可以使用先展示后加载的方式。
另一方面，内容（特别是商品数据）是最容易产生变动的，为了保证每一个消费者看到的数据都是最真实，最准确的，所以务必要先加载再展示。
1、空白页面刷新失败有提示
现在的应用都标榜以内容为中心，所以都会极力避免空白页面的出现。对于大部分的应用，最好的方法就是使用缓存，进入页面之后，先显示之前的缓存，然后再进行内容的刷新。其次，消灭空白页面的第二种方法就是提供系统推荐项进行替代。但是对于一些页面，页面内容跟用户的使用状态关系密切，无法避免会出现空白页面，这时候会使用一些引导类的提示，使得页面变得更加丰富，同时可以促进用户产生内容。
但是一些资讯类应用，比如读读日报，打开默认是空白页面，然后再加载内容（我不是很明白这种设定）。其他一些应用，比如：豆瓣一刻和MONO，每天第一次进入应用的时候也会出现空白页面。我猜想第二类应用的展示方式的原因是这样的。他们的内容**都是严格以天为单位的，每天固定时段**精选内容。他们会希望你每天只看并且看完当天的东西，所以一旦到了第二天，昨天的内容就是累赘了。所以每天第一次进入应用的时候会出现空白页面，象征着每天都是从新开始。此时就会对应一个“空白刷新”逻辑。
空白刷新对应的场景是这样子的：用户想要刷新出内容，并且用户知道这里可以刷出新内容，但是没有刷新成功，这时候需要给用户一个交待。所以需要提示用户。同时，提示完用户之后需要给用户一个解决方法，这就是“点击后重试”。
2、缓存页面刷新失败无提示
常见的应用比如知乎、网易新闻、好奇心日报、微信朋友圈等，这些应用都会采用缓存的形式，打开之后显示的是缓存内容，然后系统会给服务器发送请求，如果有内容更新的话就会自动更新一次内容，更新之后的内容直接覆盖当前的内容。更新失败之后是没有提示的。但是有一些应用，比如有道词典、企鹅FM、网易云音乐等，他们更新失败之后是有提示的。
我觉得这两种应用的区分点在于
应用的使用频率；
内容的时间连续性；
界面之间的关系紧密度。
比如说网易新闻，作为一个打发时间的工具，每天使用频率就会比较高，所以用户进来之后是想看看有没有更新。其次，网易新闻的内容是连续不断更新的，所以用户会知道当前显示的内容是我看看过并且处理过的。最后，新闻列表页面显示的是摘要，用户可以通过摘要快速进行判断是否要进入详情页，摘要有助于帮助用户回忆上一次的使用场景。
所以这就对应着一个这样的场景：用户只是想看看有没有更新，所以他们已经做好了“没有新内容”的心理预期，所以即使是更新不了内容，用户也不会想太多。反倒是，如果进行了错误提示，用户可能会有一种挫败感。因为他知道现在有内容，只是因为网络的原因而没有更新，他要进行的任务受到了外界因素的阻碍，由此产生一种细微的挫败感。
3、缓存页面刷新失败有提示
另一类应用，使用频率没那么高，或者内容不具备时间连续性的，又或者说当前界面无法唤起用户上一次的使用场景。那么就有必要进行率先你失败提示了。
比如说企鹅FM，音频类的应用注定使用不会那么频繁，因为通过视觉接收的信息会比通过听觉接收的信息更快更多，同时音频类对环境的要求较高（比如用耳机时要求环境不那么嘈杂，外放时要求在私人场所）。其次，此类应用都是实时推荐的，不存在时间连续性的问题，用户无法通过时间来判断内容是否被阅读过。再者，标题也无法帮你快速做出判断，你还是要进去听过才知道内容是什么。最后如果不提醒，用户进入到详情页再收到提醒，就会觉得应用浪费了用户的时间。所以，对于此类内容，刷新失败是有必要进行提醒的。
‘贰’ 北大青鸟设计培训：如何提高web页面的加载速度
在进行web前端网站设计的过程中，网站网页的加载速度是非常关键的，每1秒的页面加载时间，它将页面浏览量减少11％，客户满意度降低16％，转换率降低7％。
打开网页的速度与网站的直接收入息息相关，所以说时间就是金钱，减少网站的加载速渣虚闭度是非常关键的。
下面佳音电脑培训为大家介绍提高网站加载速度的方法。
1、图片优化一般情况下，用户倾向于放弃在3秒内未加载的网页。
因为加载图像占用了网页上可供下载的大部分字节空间，因此影响网页下载时间的关键来自图像优化。
佳音IT培训发现确保正确图像优化的最佳方法之一是使用正确的大小和格式，如JPEG，GIF或PNG格式。
我们的目标是在不影响图像质量的情况下尽可能减小文件大小。
2、缓存缓存是一种临时存储网页的机制，可以减少带宽并提高性能。
当访问者到达您的站点时，缓存模式誉掘开始。
这节省了服务器时间并提高了效率。
启用浏览器缓存后，访问者可以更快地访问网站。
3、压缩Gzip是一个文件压缩软件的应用程序，就像把你的网站变成一个zip文件。
大多数服务器和客户都支持Gzip。
佳音IT培训发现当兼容Gzip的浏览器请求服务器向浏览器资源发送响应时，它可以很快的减少网站的时间延迟。
4、简洁的代码代码的简洁性是非常关键的，这样能够很好的将HTML，JavaScipt和CSS文件打包并压缩为较小的文件以运行。
在进行网站运行的过程中，佳音电脑培训发现如果移动网站有五个JavaScript文件，浏览器将发出五个单独的HTTP请求来获取它们。
为了减少如裂拥塞和延迟，还有一种方法就是将五个文件缩小并连接在一起。
‘叁’ java web 项目启动时加载数据库的数据到缓存中，如何实现求思路和实例。谢谢高峰相送
可以使用servlet的init方法访问数据库加载数据到java集合中，java集合相当于一块缓存，适用于一般的数据。
‘肆’ 浏览器缓存机制
有dns的地方,就有缓存。浏览器、操作系统、Local DNS、根域名服务器，它们都会对DNS结果做一定程度的缓存。
DNS查询过程如下:
首先搜索浏览器自身的DNS缓存,如果存在，则域名解析到此完成。
如果浏览器自身的缓存里面没有找到对应的条目，那么会尝试读取操作系统的hosts文件看是否存在对应的映射关系,如果存在，则域名解析到此完成。
如果本地hosts文件不存在映射关系，则查找本地DNS服务器(ISP服务器,或者自己手动设置的DNS服务器),如果存在,域名到此解析完成。
如果本地DNS服务器还没找到的话,它就会向根服务器发出请求,进行递归查询。
浏览器本地缓存失效后，浏览器会向CDN边缘节点发起请求。类似浏览器缓存,CDN边缘节点也存在着一套缓存机制。CDN边缘节点缓存策略因服务商不同而不同，但一般都会遵循http标准协议，通过http响应头中的
Cache-control: max-age 的字段来设置CDN边缘节点数据缓存时间。
当浏览器向CDN节点请求数据时，CDN节点会判断缓存数据是否过期，若缓存数据并没有过期，则直接将缓存数据返回给客户端；否则，CDN节点就会向服务器发出回源请求，从服务器拉取最新数据，更新本地缓存，并将最新数据返回给客户端。 CDN服务商一般会提供基于文件后缀、目录多个维度来指定CDN缓存时间，为用户提供更精细化的缓存管理。
CDN 优势
CDN节点解决了跨运营商和跨地域访问的问题，访问延时大大降低。
大部分请求在CDN边缘节点完成，CDN起到了分流作用，减轻了源服务器的负载。
http请求报文（request）
请求行
请求方法 空格 URL 空格 协议版本 回车符 换行符
请求头（通用信息头、请求头、实体头）
头部字段名 冒号 值 回车键 换行符
...
头部字段名 冒号 值 回车键 换行符
空行
回车符 换行符
实体主体（只有post请求有）
主体
http响应报文（response）
状态行
协议版本 空格 状态码 空格 状态码描述 回车符 换行符
响应头部
头部字段名 冒号 值 回车符 换行符
...
头部字段名 冒号 值 回车符 换行符
空行
回车符 换行符
响应正文
正文
浏览器初次向服务器发起请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存返回的结果，是则将请求结果和缓存标识存入浏览器缓存中
浏览器每次发起请求，都会现在浏览器缓存中查找该请求的结果以及缓存标识
浏览器 浏览器缓存 服务器
——————第一次发起http请求——————>
<——没有该请求的缓存结果和缓存标识————
——————————————发起http请求——————————————>
<——————————返回该请求结果和缓存规则————————————
——将请求结果和缓存标识存入浏览器缓存——>
强制缓存就是向浏览器缓存查找结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程
强制缓存的情况分为三种：
1、不存在该缓存结果和缓存标识，强制缓存失效，直接向服务器发起请求
2、存在该缓存结果和缓存标识，但结果已经失效，强制缓存失效，使用协商缓存
3、存在该缓存结果和缓存标识，且该结果没有失效，强制缓存生效，直接返回该结果
控制强制缓存的字段：Expires，Cache-Control
Expires 是 HTTP/1.0 控制缓存的字段，值为服务器返回该请求的结果缓存时间
即再次发送请求是，客户端时间 小于 Expires的值，直接使用缓存结果
Cache-Control 是HTTP/1.1的规则，主要用于控制网页缓存，主要取值为：
public：所有的内容都缓存（客户端和代理服务器都可以缓存）
private：所有内容只有客户端可以缓存（默认值）
no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定
no-store：即不使用强制缓存，也不使用协商缓存
max-age=xxx：缓存内容将在xxx秒后失效
Expires 是一个绝对值
Cache-Control 中 max-age 是相对值，解决了 Expires时期 服务端与客户端 可能出现时间差的问题
注：Expires和Cache-Control同时存在时，只有Cache-Control生效
协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程
协商缓存的两种情况：
1、协商缓存生效，返回304，继续使用缓存
过程：
浏览器 浏览器缓存 服务器
————————发起http请求————————>
<——该请求的缓存结果失效，只返回缓存标识——
————————携带该资源的缓存标识，发起http请求————————>
<—————————————304，该资源无更新————————————
——————获取该请求的缓存结果——————>
<——————返回该请求的缓存结果——————
2、协商缓存失败，返回200和请求结果
过程：
浏览器 浏览器缓存 服务器
————————发起http请求————————>
<——该请求的缓存结果失效，只返回缓存标识——
————————携带该资源的缓存标识，发起http请求————————>
<————————200，资源已更新，重新返回请求和结果———————
——将该请求结果和缓存标识存入浏览器缓存中—>
协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的
控制协商缓存的字段：
(1) Last-Modified/If-Modified-Since：Last-Modified是服务器响应请求是，返回该资源文件在服务器最后被修改的时间；If-Modified-Since再次发起请求时，携带上次返回的Last-Modified的值，服务器将该字段值与该资源最后修改时间对比，决定是否用缓存
(2)Etag/If-None-Match：Etag服务器响应请求时，返回当前资源文件的一个唯一标识，由服务器生成之；If-None-Match是再次发起请求时，携带上次返回的唯一标识Etag的值，服务器收到后，将该字段值与该资源在服务器上的Etag对比，一致 则返回304，否则返回200
注：Etag/If-None-Match优先级高于Last-Modified/If-Modified-Since，同时存在时只有Etag/If-None-Match生效
浏览器缓存分为：内存缓存 和 硬盘缓存
内存缓存特性：
(1)快速读取：内存缓存会将编译解析后的文件，存入该进程的内存中，便于下次运行时快速读取
(2)时效性：一旦关闭进程，进程内存清空
硬盘缓存特性：
永久性：直接写入硬盘文件中
复杂、缓慢：读取缓存对该缓存存放的硬盘文件进行I/O操作，重新解析
from memory cache：使用内存中的缓存
from disk cache：使用硬盘中的缓存
浏览器读取顺序：memory ——> disk
浏览器将js和图片等文件解析执行后直接存入内存缓存中，F5刷新页面时，from memory cache(使用内存中的缓存)
css文件存入硬盘中，F5刷新页面时，from disk cache(使用硬盘中的缓存)
参考文章
https://segmentfault.com/a/1190000017962411
https://www.cnblogs.com/chengxs/p/10396066.html
‘伍’ 认识HTTP----缓存篇
本文内容大多参考 《图解HTTP》一书
所以讲缓存为什么要先扯代理服务器？别急，让我们看一下一个请求的简单示意图。
我们看到客户端(用户)发送了一个请求并不是直接发给源服务器的而是经过了代理服务器，然后经由代理服务器再发送给源服务器，响应也同样遵循这个顺序。
那么代理服务器在这中间担任了什么角色？
缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。
缓存服务器是代理服务器的一种，并归类在缓存代理类型中。换句话说，当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。
缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源。因此客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同的请求了。
即便缓存服务器和客户端内有缓存，也不能每次都给我返回缓存吧，如果是这样，源服务器更新了我也不知道，因为我每次都是看缓存的资源。
为了解决这个问题，针对缓存设计了时效性的概念：
即使存在缓存，也会因为客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效，缓存服务器将会再次从源服务器上获取“新”资源。
缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。以Internet Explorer 程序为例，把客户端缓存称为临时网络文件（Temporary Internet File）。
浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直接从本地磁盘内读取。
另外，和缓存服务器相同的一点是，当判定缓存过期后，会向源服务器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。
Pragma 是HTTP/1.1 之前版本的历史遗留字段，仅作为与HTTP/1.0的向后兼容而定义。
规范定义的形式唯一，如下所示。
Pragma: no-cache
该首部字段属于通用首部字段，但只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。
通过指定首部字段Cache-Control 的指令，就能操作缓存的工作机制。
可用的指令按请求和响应分类如下所示:
public指令
Cache-Control: public
当指定使用public 指令时，则明确表明其他用户也可利用缓存。
private指令
no-store指令
Cache-Control: no-store
当使用no-store 指令时，暗示请求（和对应的响应）或响应中包含机密信息。
因此，该指令规定缓存不能在本地存储请求或响应的任一部分。
ps:从字面意思上很容易把no-cache误解成为不缓存，但事实上no-cache代表不缓存过期的资源，缓存会向源服务器进行有效期确认后处理资源，也许称为do-not-serve-from-cache-without-revalidation更合适。no-store 才是真正地不进行缓存，请读者注意区别理解。
s-maxage指令
Cache-Control: s-maxage=604800 //（单位：秒）
s-maxage 指令的功能和max-age 指令的功能相同， 它们的不同点是s-maxage 指令只适用于供多位用户使用的公共缓存服务器(这里指代理服务器)。也就是说，对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。
另外，当使用s-maxage 指令后，则直接忽略对Expires 首部字段及max-age 指令的处理。
max-age指令
cache-extension token
Cache-Control: private, community="UCI"
通过 cache-extension 标记（token），可以扩展Cache-Control 首部字段内的指令。
如上例，Cache-Control 首部字段本身没有community 这个指令。借助extension tokens 实现了该指令的添加。如果缓存服务器不能理community 这个新指令，就会直接忽略。因此，extension tokens 仅对能理解它的缓存服务器来说是有意义的。
If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT
首部字段If-Unmodified-Since 和首部字段If-Modified-Since 的作用相反。它的作用的是告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。如果在指定日期时间后发生了更新，则以状态码412 Precondition Failed 作为响应返回。
ps:Last-Modified 存在一定问题，如果在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会因为Last-Modified时间匹配不上而返回了整个实体给客户端（即使客户端缓存里有个一模一样的资源）。
首部字段If-None-Match 属于附带条件之一。它和首部字段If-Match 作用相反。用于指定If-None-Match 字段值的实体标记（ETag）值与请求资源的ETag 不一致时，它就告知服务器处理该请求。
在GET 或HEAD 方法中使用首部字段If-None-Match 可获取最新的资源。因此，这与使用首部字段If-Modified-Since 时有些类似。
不与服务器确认，而是直接使用浏览器缓存的内容。其中响应内容和之前的响应内容一模一样，例如其中的Date时间是上一次响应的时间。
F5的作用和直接在URI输入栏中输入然后回车是不一样的，F5会让浏览器无论如何都发一个HTTP Request给Server，即使先前的响应中有Expires头部。
Ctrl+F5要的是彻底的从Server拿一份新的资源过来，所以不光要发送HTTP request给Server，而且这个请求里面连If-Modified-Since/If-None-Match都没有，这样就逼着Server不能返回304，而是把整个资源原原本本地返回一份，这样，Ctrl+F5引发的传输时间变长了，自然网页Refresh的也慢一些。
Cache-Control 是 HTTP1.1 才有的，不适用于 HTTP1.0，而 Expires 既适用于 HTTP1.0，也适用于 HTTP1.1，所以说在大多数情况下同时发送这两个头会是一个更好的选择，当客户端两种头都能解析的时候，会优先使用 Cache-Control。
二者都是通过某个标识值来请求资源， 如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed）状态码，内容为空，这样就节省了传输数据量。当资源变化后则返回新资源。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。
其中Last-Modified使用文件最后修改作为文件标识值，它无法处理文件一秒内多次修改的情况，而且只要文件修改了哪怕文件实质内容没有修改，也会重新返回资源内容；ETag作为“被请求变量的实体值”，其完全可以解决Last-Modified头部的问题，但是其计算过程需要耗费服务器资源。
Expires和Cache-Control都有一个问题就是服务端的修改，如果还在缓存时效里，那么客户端是不会去请求服务端资源的（非刷新），这就存在一个资源版本不符的问题，而强制刷新一定会发起HTTP请求并返回资源内容，无论该内容在这段时间内是否修改过；而Last-Modified和Etag每次请求资源都会发起请求，哪怕是很久都不会有修改的资源，都至少有一次请求响应的消耗。
对于所有可缓存资源，指定一个Expires或Cache-Control max-age以及一个Last-Modified或ETag至关重要。同时使用前者和后者可以很好的相互适应。
前者不需要每次都发起一次请求来校验资源时效性，后者保证当资源未出现修改的时候不需要重新发送该资源。而在用户的不同刷新页面行为中，二者的结合也能很好的利用HTTP缓存控制特性，无论是在地址栏输入URI然后输入回车进行访问，还是点击刷新按钮，浏览器都能充分利用缓存内容，避免进行不必要的请求与数据传输。
做法很简单，就是把可能会更新的资源以版本形式发布，常用的方法是在文件名或参数带上一串md5或时间标记符：
可以看到上面的例子中有不同的做法，有的在URI后面加上了md5参数，有的将md5值作为文件名的一部分，有的将资源放在特性版本的目录中。
那么在文件没有变动的时候，浏览器不用发起请求直接可以使用缓存文件；而在文件有变化的时候，由于文件版本号的变更，导致文件名变化，请求的url变了，自然文件就更新了。这样能确保客户端能及时从服务器收取到新修改的文件。通过这样的处理，增长了静态资源，特别是图片资源的缓存时间，避免该资源很快过期，客户端频繁向服务端发起资源请求，服务器再返回304响应的情况（有Last-Modified/Etag）。
‘陆’ 网站缓存功能什么意思
1.减少 HTTP 请求数：一个页面中包含的图片，JS，CSS等每一个资源都会生成一个 HTTP 下载请求，由浏览器发向网站服务器，如果减少这个请求数，会缩短网络传输的时间。
另外图片尽量采用压缩格式的，例如 jpg 就属于一种压缩图片格式，bmp属于无压缩无失真图片。这个需要网页/网站设计人员综合考虑这个因素。
优点：缩短网络传输事件，网络传输量小，减少服务器端负载；
缺点：减少HTTP请求，有时候无法满足网站发布信息的需求，盗链的出现也会增加HTTP请求；
2、采用缓存技术（webcache）：这个是目前网站加速最主要的方式。如果利用代理/缓存加速服务器去实现的话，网站在不需要做任何改动的情况下，就可实现大跨度的实现加速效果。实现的基本方式为：将指定的网站页面周期性的缓存起来，缓存时间可从几秒到几天，在缓存时间内，页面只需要生成一次，以后有用户访问这个页面的时候，网站服务器和数据库就不再需要重新生成相同的页面了，极大的减少了网站服务器和数据库负荷。我们做个简单的对比，假设一个新闻热点页面，在一个小时可被访问1万次，如果这个新闻页面每次被访问的时候，都会通过读取数据库后再一遍一遍的编译生成，在一个小时内将会重复性的生成1万次；如果这个页面被周期性的缓存10分钟，也就是每间隔10分钟才会被生成一次，一个小时内只会被生成6次，如果两种方式一对比，效果就超级明显，两种比较下服务器负荷的压力比差别1000倍以上，缓存技术将使得网站负载在高峰期游刃有余。Fikker网站加速软件实际上是一款代理服务器软件，通过Fikker网站加速服务器提供的页面缓存（webcache）功能，将需要缓存的网站URL配置到页面缓存中（支持正则表达式，通配符和精确地址匹配），并设定一定的缓存时间（几秒到几天），不需要重启Fikker立即生效，如果有重要页面变动，可通过清理缓存将指定的缓存页面清理出去。
优点：网站不需要做任何改动，大幅减少服务器和数据库的负荷。
3、使用gzip压缩：页面压缩主要是降低传输尺寸，提高传输效率。常用的 html，asp，php，jsp，txt，css，js等文本页面，通过gzip压缩可降低75%左右尺寸，也就是原来需要传输 100KB 的页面，gzip压缩后只需要 25KB 的传输数据了，加速的效果是非常明显的。Fikker内置了gzip模块，自动对压缩的文件压面进行压缩传输。
4、使用非阻塞网络技术（non-block）：提高网络响应速度，Linux 从 2.6 内核开始，专门引入 epoll 事件机制，相对于传统的 select 事件机制，效率大大的增强，尤其在高并发情况下越发的明显，几个线程即可并发支持上万并发连接，使用尽量少的线程除了减少内存开支还可减少频繁的线程切换的开销。Fikker软件的Linux版本全面支持epoll事件机制，支持从连接建立到连接结束，从域名解析开始到结束的全非阻塞网络设计。
5、提高带宽，加速页面传输：利用带宽加速方式常用是CDN，通过CDN运营商的网络将页面分发出去，用户访问时可就从最近的节点获取，达到加速目的。但这里面有一个前提，就是需要页面是静态的，或动态页面首先需要被生成出来，然后才能利用 CDN 的高速网络传输出去，从这个角度理解，CDN 与 缓存加速具有很强的互补性，即利用缓存技术加快页面生成，利用CDN加快传输，缺一不可。
希望对你有事帮助。
‘柒’ 北大青鸟设计培训：web服务器缓存基本定义
为了能够给用户一个良好的上网体验，大部分的网页和浏览器都配置了预加载以及缓存功能。
今天兰州电脑培训http://www.kmbdqn.cn/就通过案例分析来了解一下，关于web缓存的基本定义与类型介绍。
Web缓存是什么?为什么要使用缓存?Web缓存处于服务器(也称为源服务器)和客户端之间，监视请求并保存响应的副本，比如HTML页面，图片和文件等(统称为表述)。
如果之后有对同一个URL的新请求，它会使用自己保存的内容来响应，而不是再次请求源服务器来获取内容。
使用Web缓存主要有下面两个原因：减少延迟——因为响应请求的内容来自缓存(距客户端较近)而不是源服务器，它会花较少的时间来获得表述并将他们呈现出来。
这使得Web看起来具有良好的响应速度。
减少网络传输——由于复用了表述，它可以减少客户端使用的带宽总量。
如果客户需要为流量付费，这就意味着省钱。
缓存会降低对带宽的要求，也降低处理难度。
Web缓存的种类浏览器缓存你在查看现代Web浏览器(比如IE、Safari或Mazilla)选项的时候，可能会看到“缓存”设置。
这个选项让你配置一部分硬盘空间来保存你看过的表述。
浏览器缓存的规则相当简单。
它通常会在一次会话(即当前浏览器中一次调用)中检查表述是否新。
这个缓存在用户使用“回退”按钮或者点击一个浏览过的链接时会特别有用。
而且，如果你在网站缓悔数的各个页面中浏览相同的图片，他们几乎能马上从缓存中加载出来。
代理缓存Web代理缓存的工作原理相同，但规模更大。
代理以同样的方式为成百上千的用户服务;大公司和ISP常常把代码缓存建立在防火墙之上，也可能是以独立设备的形式存在(也称为中间设备)。
代理缓存即不是客户端的一部分，也不是服务器的一部分，而是在网络之外，必须以某种方式把请求路由过去。
其中一种方式是手工修改浏览器代理设备，指定要使用的代码;另一种方式是拦截。
拦截式代理会根据其自身的基础网络重定向Web请求，不需要前袜在客户端配置，客户端甚至不知道它们的存在。
代理缓存是一种共享缓存，通常不只是一个用户，而是大量用扰首户在使用代理缓存。
正因为如此，他们特别擅长降低延迟和网络传输量。
这是因为众人都需要的表述会被多次重复使用。
网关缓存网关缓存又名“反向代理缓存”或“替代缓存”。
网关缓存也是一种中介，它他们不是由网络管理员部署以节约带宽，而是由网站管理员自己部署，使其站点更具伸缩性、可靠性以及拥有更好的性能。
很多方法都可以把请求路由到网关缓存，但常见的方法是使用负载均衡器让他们对于客户来说，看起来就跟源服务器一样。
内容分发网络(CDN)在整个Internet(或它的一部分)中分发网关缓存，并将其出售给对此感兴趣的网站。
Web缓存对我有坏处么?我为什么要帮助它们?Web缓存是互联网中误解深的技术之一。
因为代理缓存可以隐藏使用网站的用户，所以网站管理员特别害怕失去对他们的站点的控制，这会使得他们很难去知道是谁在使用他们的站点。
然而不幸的是，即使没有Web缓存，网络上也有非常多的因素可以保证管理员精确的知道一个用户如何使用他们的站点。
如果这是你非常关注的问题的话，这篇手册将会指导你如何在站点没有不友好的缓存机制的情况下获取你需要的统计信息。
‘捌’ Glide ② — 缓存机制
阅读本文需要先了解 Glide加载流程
首先介绍一下Glide中对图片资源的封装类： EngineResource
在活动缓存中，使用了一个map用来存放EngineResource对象，这里需要注意一个操作，就是这个EngineResource对象是用WeakReference包裹的，并且通过ReferenceQueue监听了EngineResource的回收，在回收的时候会清理当前的活动缓存内容；
下面分析一下源码是如果实现的：
首先，自定义一个WeakReference类，将key和resource传进入（用于在WeakReference回收的时候释放），传入一个ReferenceQueue对象，用于监听WeakReference回收
开启一个子线程，在循环中监听ReferenceQueue的返回值，通过这个返回值，判断WeakReference有没有回收，监听的方法是ReferenceQueue.remove(),这是一个阻塞方法；所以要开子线程；
LruResourceCache继承了LruCache类，关于LruCache类，简单提一下，具体的可以参考我之前的博客 LruCache实现 ，LruCache继承了LinkedHashMap，LinkedHashMap有一个特点，就get后的数据会移动到队列，这就是Lru思想：固定一个容量，put的时候如果超过容量了，将最后一个节点删除，get的时候将get的这个节点移动到队列的头部；
onItemEvicted（）方法是LruCache的一个空方法，调用的时机是在put的时候判断是否超过容量，如果超过容量了，就淘汰最后一个节点，并调用这个方法；
活动缓存和内存缓存都是缓存在内存中的，活动缓存缓存的是正在使用的图片资源，当图片不使用时会放到内存缓存中，提出活动缓存的目的：单一的内存缓存由于Lru的淘汰机制会导致图片加载不稳定
首先介绍一个磁盘缓存方案DiskLruCache(非Google官方编写，但获得官方认证)，关于这个磁盘缓存方案的理解可以看郭林的这片文章：
Android DiskLruCache完全解析，硬盘缓存的最佳方案
从上一篇文章知道，Glide加载操作是通过 Engine 来驱动的
Engine的load()中，首先尝试从 活动缓存 和 内存缓存 获取缓存，如果没有缓存再启动EngineJob和DecodeJob； 上面介绍了缓存的获取，下面看一下缓存的存放，肯定是在获取到图片后的回调中存放的
在DecodeJob获取到图片数据后，会回调很多接口，在回调中会将其放入 活动缓存 ，当图片不在使用的时候，就会放入内存缓存，根据上面介绍的活动缓存规则，当 EngineResource 计数为0时就应该放入内存缓存；
当资源引用为0，回调onResourceReleased(),从活动缓存移除，放入内存缓存；
上面介绍了活动缓存和内存缓存的存放和获取，下面看一看磁盘缓存的存取；
还记得 DataFetcherGenerator 接口吗？这个接口是DecodeJob用于获取数据的，有三个具体的实现：
我们在上一篇具体介绍的是网络文件的获取，这里的磁盘缓存使用的就是 DataCacheGenerator（缓存文件） 这个Generator了
上篇文章知道DecodeJob是一个Runnable任务，在run()会调用runWrapped()，在runWrapped()中会做三种事情：
在runWrapped（）的解码操作中会执行decode()，在decode()中，会disk put操作;
Glide的磁盘缓存是基于DiskLruCache 实现的，Glide直接使用的是DiskLruCacheWrapper对象对DiskLruCache 的封装；