HTTP个人总结（五）

今天主要来讲HTTP中的缓存。
首先看一张在不同网络下的传输速度：

现在介绍几个概念：

先说下瞬间拥塞的概念：
是指突发事件使很多人几乎同时去访问一个Web文档时出现瞬间拥塞，由此造成过多流量峰值可能会使网络和Web服务器造成灾难性的崩溃。

接下来再来介绍下距离时延概念：
如果服务器位于长距离外，在最好的情况下，以光速传输（186000英里/秒）传输的信号时延会变成毫秒级，但是更加复杂的Web页面会带来几秒钟的光速时延。

然后介绍什么是命中和未命中的：
可以用已有的副本为某些到达缓存的请求提供服务。这被称为缓存命中。其他一些到达缓存的请求可能会由于没有副本可用，而被转发给原始服务器，这被称为缓存未命中。

之后介绍再验证概念：
原始服务器的内容可能会发生变化，缓存要不时对其进行检测。这种“新鲜度检测”被称为HTTP再验证。为了有效进行再验证，HTTP定义了一些特殊的请求，不用从服务器上获取整个对象，就可以快速检测出是否是最新的。
缓存可以再任意时刻，以任意的频率对副本进行再验证。但由于缓存中通常会包含数百万的文档，而且网络带宽是很珍贵的，所以大部分缓存只有在客户端发起请求，并且副本旧的足以需要检测的时候，才会对副本进行再验证。
缓存对缓存的副本进行再验证时，会向原始服务器发送一个小的再验证请求。如果内容没有变化，服务器会以一个小的304Not Modified进行响应。只要缓存知道副本仍然有效，就会再次将副本标识为暂时新鲜的，并将副本提供给客户端。这被称作再验证命中或缓慢命中，这种方式确实要与原始服务器进行核对，所以会比单纯的缓存命中要慢，但它没有从服务器中获取对象数据，所以要比缓存未命中快一些。
HTTP为我们提供了几个用来对已缓存对象进行再验证的工具，但最常用的是If-Modified-Since首部。将这个首部添加到GET请求中去，就可以告诉服务器，只有在缓存了对象的副本之后，又对其进行修改的情况下，才发送此对象。下面列出三种情况：
1.再验证命中：如果服务器对象未被修改，服务器会向客户端发送一个小的HTTP 304 Not Modified响应。
2.再验证未命中：如果服务器对象与缓存副本不同，服务器向客户端发送一条普通的、带有完整内容的HTTP 200 OK响应。
3.对象被删除：如果服务器对象已经被删除了，服务器就回送一个404 Not Found响应，缓存也会将其副本删除。

接下来介绍命中率概念：
由缓存提供服务的请求所占的比例被称为缓存命中率，有时也被称为文档命中率。

字节命中率概念：
由于文档并不全是同一尺寸的，所以文档命中率并不能说明一切。有些大型对象呗访问的次数可能较少，但由于尺寸的原因，对整个数据流量的贡献却更大，因此有些人更愿意使用字节命中率作为度量值。字节命中率表示的是缓存提供的字节在传输的所有字节中所占的比例。

怎么区分命中和未命中的情况？
HTTP没有为用户提供一种手段来区分响应是缓存命中的，还是访问原始服务器得到的。有些商业代理缓存会在Via首部附加一些额外信息，以描述缓存中发生的情况。
客户端有一种方法可以判断响应是否来自缓存，就是使用Date首部。将响应中Date首部的值与当前时间进行比较，如果响应中的日期值比较早，客户端通常就可以认为这是一条缓存的响应。客户端也可以通过Age首部来检测缓存的响应，通过这个首部可以分辨出这条响应的使用期。

什么是私有缓存？
Web浏览器中有内建的私有缓存——大多数浏览器都会将常用文档缓存在你个人电脑的磁盘和内存中，并且允许用户去配置缓存的大小和各种设置。还可以去看看浏览器的缓存中有些什么内容。

什么是公有代理缓存？
公有缓存是特殊的共享代理服务器，被称为缓存代理服务器或者更常见地被称为代理缓存。

介绍下代理缓存的层次结构：

我们希望大部分用户都能在附近的第一级缓存中命中。如果没有命中，较大的父缓存可能能够处理它们的请求。在缓存层次结构很深的情况下，请求可能要穿过很长一溜缓存，但每个拦截代理都会添加一些性能损耗，当代理链路变得很长的时候，这种性能损耗会变得非常明显。

那么就会出现网状缓存、内容路由以及对等缓存：
有些网络结构会构建复杂的网状缓存，网状缓存中的代理缓存之间会以更加复杂的方式进行对话，做出动态的缓存通信决策，决定于哪个父缓存进行对话，或者决定彻底绕开缓存，直接连接原始服务器。这种代理缓存会决定何种路由对内容进行访问、管理和传送，因此可将其称为内容路由器。
网状缓存中为内容路由设计的缓存要完成下列所有功能：
1.根据URL在父缓存或原始服务器之间进行动态原则
2.根据URL动态地选择一个特定的父缓存
3.前往父缓存之前，在本地缓存中搜索已缓存的副本
4.允许其他缓存对其缓存的部分内容进行访问，但不允许因特网流量通过它们的缓存。

缓存之间这些更为复杂的关系允许不同的组织互为对等实体，将它们的缓存连接起来以实现共赢。提供可选的对等支持的缓存被称为兄弟缓存。HTTP并不支持兄弟缓存，所以人们通过一些协议对HTTP进行了扩展，比如因特网缓存协议（ICP）和超文本缓存协议。

接下来将要介绍缓存的处理步骤：
先概览：
1.接收——缓存从网络中读取抵达的请求报文
2.解析——缓存对报文进行解析，提取出URL和各种首部
3.查询——缓存查看是否有本地副本可用，如果没有，就获取一份副本并将其保存在本地。
4.新鲜度检测——缓存查看已缓存副本是否足够新鲜，如果不是，就询问度武器是否有任何更新。
5.创建响应——缓存会用新的首部和已缓存的主体来构建一条响应报文。
6.发送——缓存通过网络将响应发回给客户端
7.日志——缓存可选地创建一个日志文件条目来描述这个事务。

接下来进行较为详细的介绍：
第一步——接收：
缓存检测到一条网络连接上的活动，读取输入数据，高性能的缓存会同时从多条输入连接上读取数据，在整条报文到达之前开始对事务进行处理。
第二步——解析：
缓存将请求报文解析为片段，将首部的各个部分放入易于操作的数据结构中。
第三步——查找：
缓存获取了URL，查找本地副本。本地副本可能存储在内存中、本地磁盘、甚至附近的另一台计算机中。专业级的缓存会使用快速算法来确定本地缓存中是否有某个对象。如果本地没有这个文档，它可以根据情形和配置，到原始服务器或父代理中去取，或者返回一条错误信息。
已缓存对象中包含了服务器响应主体和原始服务器响应首部，这样就会在缓存命中时返回正确的服务器首部。已缓存对象中还包含了一些元数据，用来记录对象在缓存中停留了多长时间，以及它被用过多少次等。
第四步——新鲜度检测：
HTTP通过缓存将服务器文档的副本保留一段时间。在这段时间里，都认为文档是”新鲜的“，缓存可以在不联系服务器的情况下，直接提供该文档。但一旦已缓存副本停留时间太长，超过了文档的新鲜度限值，那么缓存要再次与服务器进行确认，以查看文档是否发生了变化。客户端发送给缓存的所有请求首部自身都可以强制缓存进行再验证，或者完全避免验证。
第五步——创建响应：
缓存将已缓存的服务器响应首部作为响应首部的起点。然后缓存对这些基础首部进行了修改和扩充。缓存负责对这些首部进行改造，以便与客户端的要求相匹配。比如修改HTTP协议版本，日期等。注意不应该调整Date首部，这个表示原始服务器最初产生这个对象的日期。
第六步——发送：
缓存就将响应回送给客户端。和所有代理服务器一样，代理缓存要管理与客户端之间的连接。高性能的缓存会尽力高效地发送数据，通常可以避免在本地缓存和网络I/O缓冲区之间进行文档内容的复制。
第七步——日志：
大多数缓存都会保存日志文件以及与缓存的使用有关的一些统计数据。每个缓存事务结束之后，缓存都会更新缓存命中和未命中数目的统计数据，并将条目插入一个用来显示请求类型、URL和所发生事件的日志文件。

接下里讲文档过期？
通过特殊的HTTP Cache-Control首部和Expires首部让原始服务器向每个文档附加了一个”过期日期“。

在缓存文档过期之前，缓存可以以任意频率使用这些副本，而无需与服务器联系——除非客户端请求中包含有阻止提供已缓存或未验证资源的首部。但一旦已缓存文旦过期，缓存就必须与服务器进行核对，询问文档是否被修改过，如果被修改过，就要获取一份新鲜（带有新的过期日期）的副本。

服务器用HTTP/1.0+的Expires首部或HTTP/1.1的Cache-Control：max-age响应首部来指定过期日期。但由于Cache-Control首部使用的是相对时间而不是绝对日期，所以我们更倾向于新的Cache-Control首部

之后介绍服务器再验证？

仅仅是已缓存文档过期了并不意味着它和原始服务器上目前处于活跃状态的文档有实际的区别，这只是意味着到了要进行核对的时间。这种情况被称为”服务器再验证“，有两种情况：
1.如果再验证显式内容发生了变化，缓存会获取一份新的文档副本，并将其存储在旧文档的位置上，然后将文档发送给客户端
2.如果再验证显式内容没有发生变化，缓存只需要获取新的首部，包括一个新的过期日期，并对缓存中的首部进行更新就行了。
HTTP协议要求行为正确的缓存返回下列内容之一：
1.”足够新鲜“的已缓存副本
2.与服务器进行过再验证，确认其仍然新鲜的已缓存副本
3.如果需要与之进行再验证的原始服务器出故障了，就返回一条错误报文
4.附有警告信息说明内容可能不正确的已缓存副本。

HTTP定义了5个条件请求首部。对缓存再验证来说最有用的2个首部是If-Modified-Since和If-None-Match

先介绍If-Modified-Since:Date再验证：
If-Modified_Since再验证请求通常被称为IMS请求，只有自某个日期之后资源发生了变化的时候，IMS请求才会指示服务器执行请求：
1.如果自指定日期后，文档被修改了，If-Modified-Since条件为真，通常GET就会成功执行。携带新首部的新文档会被返回给缓存，新首部除了其他信息之外，还包含了一个新的过期日期。
2.如果自指定日期后，文档没被修改过。条件就为假，会向客户端返回一个小的304Not Modified响应报文，为了提高有效性，不会返回文档的主体，一般会发送一个新的过期时间。

If-Modified-Since首部可以与Last-Modified服务器响应首部配合工作。原始服务器会将最后的修改日期附加到所提供的文档上去。当缓存要对已缓存文档进行再验证时，就会包含一个If-Modified-Since首部，其中携带有最后修改已缓存副本的日期，如果在此期间内容被修改了，最后的修改日期就会有所不同，原始服务器就会回送新的文档。否则，服务器会注意到缓存的最后修改日期与服务器文档当前的最后修改日期相符，会返回一个304 Not Modified响应。例如：

If-None-Match：实体标签再验证：
有些情况下仅使用最后修改日期进行再验证是不够的：
1.有些文档可能会被周期性地重写，但实际包含的数据常常是一样。尽管内容没有变化，但修改日期会发生变化。
2.有些文档可能被修改了，但所做修改并不重要，不需要让世界范围内的缓存都重装数据。
3.有些服务器无法准确地判定其页面的最后修改日期
4.有些服务器提供的文档会在亚秒间隙发生变化，对这些服务器来说，以一秒为粒度的修改日期可能就不够用了。
为了解决这些问题，HTTP允许用户对被称为实体标签（Etag）的”版本标识符“进行比较。实体标签是附加到文档上的任意标签（引用字符串）。它们可能包含了文档的序列号或版本号，或者是文档内容的校验和其他信息。如：

强弱验证器？
强验证器就是上面指的那些。但有时服务器希望在对文档进行一些非实质性或不重要的修改时，不要使所有的已缓存副本都失效。HTTP/1.1支持”弱验证器“，如果只对内容进行了少量修改，就允许服务器声明那是”足够好“的等价体。一般服务器会用前缀”W/“来标识弱验证器。

控制缓存的能力？

服务器可以通过HTTP定义的几种方式来指定在文档过期之前可以将其缓存多长时间。安装优先级递减的顺序：
1.附加一个Cache-Control：no-store首部到响应中去
2.附加一个Cache-Control：no-cache首部到响应中去
3.附加一个Cache-Control：must-revalidate首部到响应中去
4.附加一个Cache-Control：max-age首部到响应中去
5.附加一个Expires日期首部到响应中去
6.不附加过期信息，让缓存确定自己的过期日期

标识为no-store的响应会禁止缓存对响应进行复制。缓存通常会像非缓存代理服务器一样，向客户端转发一条no-store响应，然后删除对象。
标识为no-cache的响应实际上是可以存储在本地缓存区中的。只是在于原始服务器进行新鲜度再验证之前，缓存不能将其提供给客户端使用。
HTTP/1.1中提供Pragma：no-cache首部是为了兼容与HTTP/1.0+

max-age响应首部表示的是从服务器将文档传来时起，可以认为此文档处于新鲜状态的描述。还有一个s-maxagesho0ubu，但仅适用于共享缓存。

Expires响应首部不推荐使用，它指定的是实际的过期日期而不是描述，由于很多服务器的时钟都不同步，或者不正确，所以做好还是用剩余描述。

must-revalidate响应首部告诉缓存，在事先没有跟原始服务器进行再验证的情况下，不能提供这个对象的陈旧副本。缓存仍然可以随意提供新鲜的副本，如果在缓存进行must-revalidate新鲜度检查时，原始服务器不可用，缓存就必须返回一条504Gateway Timeout错误。

试探性过期？

LM-Factor算法是一种很常用的试探性过期算法，如果文档中包含了最后修改日期，就可以使用，逻辑如下：
1.如果已缓存文档最后一次修改发生在很久以前，它可能会使一份稳定的文档，不太会突然发生变化，因此将其继续保存在缓存中会比较安全
2.如果已缓存文档最近被修改过，就说明它很可能会频繁地发生变化，因此在此服务器进行再验证事前，只应该将其缓存很短一段时间。