web优化是http缓存（上）

解决在同时拥有很多客户对同一资源请求，服务器反复发送相同的东西，压力会很大，但是如果做了缓存，就会保留一份副本。这样减少了重 复流量。

宽带瓶颈

宽带瓶颈，很多网络为本地网络客户端提供宽带比原车的服务器宽带要宽。而客户端呢会以路径最慢的网速访问服务器，其实就是按最小的瓶颈。

如果有了缓存备份，那就不需要经过小口径，直接大口径用吧。这对于传输大文件非常有利，比如一个pdf大文件，如果每次都需要去服务器下载，那消耗是很大的。

距离问题

我老家从上海服务器下载个5mb库存文件可能要花几十秒，但是如果做了缓存，下次访问只需要几秒。本地以太网牛逼啊。距离越长宽带传输延迟越长。

每台路由都会增加流量延迟，就算没有路由，光速本身也有延迟。缓存可以很好的环境这种问题。

世界上最遥远的距离不是生与死，而是想上厕所却找不到厕所。

瞬间拥塞

多数因为爆炸性新闻，视频啊，热门的消息，很多人一起访问这个文档，就可能会出现瞬间拥塞。这个峰值达到最高时候，服务器可能会直接崩溃。 比如当年克林顿被调查的新闻，服务器在当时以每小时收到超过三百万的请求量，是其平均值50倍，能不瘫痪吗，头皮发麻。就像这汽车堵塞一样，看到就心烦，压根动不了了。

缓存命中和未命中

缓存无法保存世界上每一份文件的副本，那么可以用已有的副本来达到缓存请求服务的，这种叫做缓存命中，而相反的没用副本可用，进而转发到原始服务器的，叫做缓存未命中。

在验证

原始服务器内容可能会更新，发生变化，这时候就要进行更新缓存，所以缓存要不时的进行检测。为了有效的进行在验证，http定义了一些特殊请求，不用从服务器获取完整对象，就可以快速检测是不是最新的。在缓存对缓存副本在验证时候，向原始服务发送一次请求，如果内容没有变化，服务器返回一个304表示副本仍然有效。这种在验证命中比直接未命中还是要快一些。

对已缓存对象进行在验证的工具

http 中 If-Modified-Since 首部。将这个首部信息添加到get里，就可以告诉服务器如果内容更新了，才像客户端返回此对象。

• 服务器内容未修改 304未修改
• 服务器内容修改 200以修改并且发送完整内容 更新缓存副本
• 服务器资源以删除 删除 404 缓存副本以删除

命中率

缓存命中率是说缓存比例，40%的命中率比较合理。

字节命中率

此标准是数据很能反应一个服务的缓存性能优劣

缓存个人和共享

• 个人专业缓存称为私人缓存，私有缓存不需要多少存储空间，浏览器有内建缓存，或者个人电脑磁盘内存。
• 数千名用户共享团体缓存称为共享缓存，共有的被称为缓存代理服务器或者叫做代理缓存。

代理缓存的层级结构

核心思想就是在靠近客户端的地方使用小型廉价缓存，而高层次中，距离服务器越近的地方使用更大功能更强缓存更多用户共享的文档。所以如果url请求过程中可能要经历几级缓存的查找。如果一级没有命中缓存，那么二级查找可能会有。以此类推。这种层级有好处也有坏处，层级过深，那么可能每次查找信息，如果正好在最后一级才有命中文件，那就惨了，如果最后都没有，那更惨了。

网状缓存，内容路由以及对等缓存

网状缓存比层级缓存更复杂，下半部分在写，脑子有点累。

缓存的处理步骤

• 接收-缓存从网络中读取抵达的请求报文。
• 解析-对保温进行解析，提取url和各种首部
• 查询-查询是否有本地副本可用，如果有获取副本
• 新鲜度检测-缓存是否新鲜的检查如果不是九更新
• 创建想要-缓存用新的首部和以缓存的主体来构建一条响应报文、
• 发送-通过网络响应发挥给客户端
• 日志-创建一个日志文件夹来描述本次事务

1. 接收
   在第一步中，缓存检测到一条网络连接上的活动，读取输入数据。 高性能的缓存会同时从多条输入连接上读取数据，在整条报文抵达之前开始对事务进行处理。
2. 解析
   缓存将请求报文解析为片断，将首部的各个部分放入易于操作的数据结构中。这样，缓存软件就更容易处理首部字段并修改它们了。 解析程序还要负责首部各部分的标准化，将大小写或可替换数据格式之类不太重要的区别都看作等效的。而且，某些请求报文中包含有完整的绝对 URL，而其他一些请求中包含的则是相对 URL 和 Host 首部，所以解析程序通常都要将这些细节隐藏起来。
3. 查询
   缓存获取了 URL，查找本地副本。本地副本可能存储在内存、本地磁盘，甚至附近的另一台计算机中。 专业级的缓存会使用快速算法来确定本地缓存中是否有某个对象。如果本地没有这个文档，它可以根据情形和配置，到原始服务器或父代理中去取，或者返回一条错误信息。 已缓存对象中包含了服务器响应主体和原始服务器响应首部，这样就会在缓存命中时返回正确的服务器首部。 已缓存对象中还包含了一些元数据(metadata)，用来记录对象在缓存中停留了多长时间，以及它被用过多少次等。 复杂的缓存还会保留引发服务器响应的原始客户端响应首部的一份副本，以用于 HTTP/1.1 内容协商。
4. 新鲜度检测
   HTTP 通过缓存将服务器文档的副本保留一段时间。在这段时间里，都认为文档是“新鲜的”，缓存可以在不联系服务器的情况下，直接提供该文档。 一旦已缓存副本停留的时间太长，超过了文档的新鲜度限值(freshness limit)，就认为对象“过时”了，在提供该文档之前，缓存要再次与服务器进行确认，以查看文档是否发生了变化。 客户端发送给缓存的所有请求首部自身都可以强制缓存进行再验证，或者完全避免验证，这使得事情变得更加复杂了。 HTTP 有一组非常复杂的新鲜度检测规则，缓存产品支持的大量配置选项，以及与非 HTTP 新鲜度标准进行互通的需要则使问题变得更加严重了。
5. 创建响应
   我们希望缓存的响应看起来就像来自原始服务器的一样，缓存将已缓存的服务器响应首部作为响应首部的起点。然后缓存对这些基础首部进行了修改和扩充，以便与客户端的要求相匹配。 比如：服务器返回的可能是一条 HTTP/1.0 响应(甚至是 HTTP/0.9 响应)，而客户端期待的是一条 HTTP/1.1 响应，在这种情况下，缓存必须对首部进行相应的转换。 缓存还会向其中 插入新鲜度信息(Cache-Control、Age 以及 Expires 首部)，而且通常会包含一个 Via 首部来说明请求是由一个代理缓存提供的。 注意：缓存不应该调整 Date 首部。Date 首部表示的是原始服务器最初产生这个对象的日期。
6. 发送
   一旦响应首部准备好了，缓存就将响应回送给客户端。 和所有代理服务器一样，代理缓存要管理与客户端之间的连接。 高性能的缓存会尽力高效地发送数据，通常可以避免在本地缓存和网络 I/O 缓冲区之间进行文档内容的复制。
7. 日志
   大多数缓存都会保存日志文件以及与缓存的使用有关的一些统计数据。 每个缓存事 务结束之后，缓存都会更新缓存命中和未命中数目的统计数据(以及其他相关的度量值)，并将条目插入一个用来显示请求类型、URL 和所发生事件的日志文件。 最常见的缓存日志格式为 Squid 日志格式和网景的可扩展通用日志格式，但很多缓存产品都允许用户创建自定义的日志文件。
8. 缓存处理流程图
   以简化形式显示了缓存是如何处理请求以 GET 一个 URL 的：

   

参考：http权威指南，本着学习的目的记录下来，有时候写这些也是迫于经常有人问，而自己记忆又很差，很多时候确实想不起来了，本着以后可以翻翻看的想法记录下来。