• 减少网络传输的冗余信息量
• 缓解网络瓶颈的问题
• 降低对原始服务器的请求量
• 减少了传送距离，降低了因为距离而产生的时延

缓存基本处理过程包括七个步骤。

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

这里的缓存可以是本地客户端缓存，也可以是代理缓存之类的公共缓存。

HTTP缓存模型

HTTP缓存可以在不依赖服务器记住有哪些缓存拥有文档副本，而实现文档的一致。这些机制称为文档过期（document expiration）和服务器再验证（server revalidation），也可以称它们为截止模型和证实模型。

截止模型是HTTP请求中带上标记文档的过期时间，HTTP协议中使用如下两个字段标记过期时间：

• Expires字段 – 指定一个绝对的过期日期。
• Cache-control:max-age – 定义文档的最大使用期，从第一次生成文档到文档不再新鲜，无法使用为止，最大的合法生存时间（单位为s）

仅仅使用截止模型还不够，即使文档过期了，也并不意味着当前文档和原始服务器的文档不一致了。此时就到证实模型大显身手的时候了。证实模型需要询问原始服务器文档是否发生了变化。其依赖于HTTP协议的如下字段：

• If-Modified-Since字段 – 如果从指定日期之后文档被修改了，就执行请求的方法。可以与Last-modified服务器响应首部配合使用。它告诉服务器只有在客户端缓存了对象的副本后，又服务器对其进行了修改的情况下，才在回复中发送此对象。如果服务器对象没有修改，返回304 Not Modified。如果服务器修改了此对象，发送此对象，返回200 OK。如果服务器删除了些对象，返回404 Not Found。
• If-None-Match字段 – 服务器可以为文档提供特殊的标签（ETag），如果此标签与服务器的标签不一样，就会执行请求的方法。

如果服务器应答中包括一个ETag，又包括一个Last-Mofidied值，则客户端在发送请求时使用两种证实机制，并且只有当两种证实机制都满足时才会返回304 Not Modified。

缓存在新鲜度检测时，只需要计算两个值：已缓存副本的使用期和已缓存副本的新鲜生存期。

HTTP缓存使用期算法

响应的使用期是服务器发布响应（或通过证实模型再验证）之后经过的总时间。使用期包括了因特网中传输的时间，在中间节点缓存的时间，以及在本地缓存中的停留时间。

       /*
       * age_value 当代理服务器用自己的头部去响应请求时，Age标明实体产生到现在多长时间了。
       * date_value HTTP 服务器应答中的Date字段 原始服务器
       * request_time 缓存的请求时间
       * response_time 缓存获取应答的时间
       * now 当前时间
       */
 
      apparent_age = max（0, response_time - date_value）; //缓存收到响应时响应的年龄 处理时钟偏差存在时，可能为负的情况
 
      corrected_received_age = max（apparent_age, age_value）;  //  容忍Age首部的错误
 
      response_delay = response_time - request_time; // 处理网络时延，导致结果保守
 
      corrected_initial_age = corrected_received_age + response_delay;
 
      resident_time = now - response_time; // 本地的停留时间，即收到响应到现在的时间间隔
 
      current_age   = corrected_initial_age + resident_time;

因此，完整的使用期计算算法是通过查看Date首部和Age首部来判断响应已使用的时间，再记录其在本地缓存中的停留时间就是总的使用期。除此之外，HTTP协议对时钟偏差和网络时延进行了一补偿，特别是其对网络时延的补偿，可能会重复计算已使用的时间，从而使整个算法产生保守的结果。这种保守的效果时，如果出错了，算法只会使文档看起来比实际使用期要老，并引发再验证。

HTTP缓存新鲜度算法

通过已缓存文档的使用期，根据服务器和客户端限制来计算新鲜生存期，就可以确定已缓存的文档是否新鲜。已缓存文档的使用期在前面已经介绍过了，这小节我们来看看新鲜生存期的计算。

为了确定一条响应是保鲜的（fresh）还是陈旧的（stale），我们需要将其保鲜寿命（freshness lifetime)和年龄(age)进行比较。年龄的计算见13.2.3节，本节讲解怎样计算保鲜寿命，以及判定一个响应是否已经过期。在下面的讨论中，数值可以用任何适于算术操作的形式表示。

与此相关的首部字段包括（按优先级从高到低）： Cache-Control字段中“max-age”控制指令的值、Expires、Last-Modified、默认最小的生存期。用PHP代码体现如下：

    /**
     * $heuristic 启发式过期值应不大于从那个时间开始到现在这段时间间隔的某个分数
     * $Max_Age_value_set  是否存在Max_Age值  Cache-Control字段中“max-age”控制指令的值
     * $Max_Age_value  Max_Age值
     * $Expires_value_set 是否存在Expires值
     * $Expires_value Expires值
     * $Date_value Date头部
     * $default_cache_min_lifetime 
     * $default_cache_max_lifetime
     */
    function server_freshness_limit() {
        global $Max_Age_value_set, $Max_Age_value;
        global $Expires_value_set, $Expires_value;
        global $Date_value, $default_cache_min_lifetime, $default_cache_max_lifetime;
 
        $factor = 0.1; //典型设置为10%
 
        $heuristic = 0; //  启发式 默认为0
 
        if ($Max_Age_value_set) {   // 优先级一为 Max_Age
            $freshness_lifetime = $Max_Age_value;
        }elseif($Expires_value_set) {  //   优先级二为Expires
            $freshness_lifetime = $Expires_value - $Date_value;
        }elseif($Last_Modified_value_set) { //  优先级三为Last_Modified
            $freshness_lifetime = (int)($factor * max(0, $Last_Modified_value - $Date_value));
            $heuristic = 1; //  启发式
        }else{  
            $freshness_lifetime = $default_cache_min_lifetime;
            $heuristic = 1; //  启发式
        }
 
        if ($heuristic) {
            $freshness_lifetime = $freshness_lifetime > $default_cache_max_lifetime ? $default_cache_max_lifetime : $freshness_lifetime;
            $freshness_lifetime = $freshness_lifetime < $default_cache_min_lifetime ? $default_cache_min_lifetime : $freshness_lifetime;
        }
 
        return $freshness_lifetime;
 
    }

计算响应是否过期非常简单： response_is_fresh = (server_freshness_limit() > current_age)

以此为《HTTP权威指南》第七章读书笔记。

HTTP为提高性能，减少网络传输的信息量，从而使用了缓存。

HTTP协议缓存的目标是去除许多情况下对于发送请求的的需求和去除许多情况下发送完整请求的需求。

在http协议中使用截止模型和证实模型来实现缓存。

【截止模型】

目的：减少操作的大量网络来回奔波，或者说减少http的请求数。

避免请求的主要机制是服务器提供明确的在将来截止的时间，表示响应可满足后续请求，即可以在不联系服务器而返回更新的响应。

在服务器指定了截止时间，在截止时间之前实体不会改变，此时需要慎重考虑截止时间。

实现方式：服务器可以使用Expires头部，也可以使用Cache-Control头部的max-age指令来指定明确的截止时间。

其中max-age指令的优先级高于Expires

【证实模型】

目的：减少网络带宽的损耗

这里的证实是指在在请求与应答中存在一些缓存的条目，这些条目在请求与应答中传递，判断是否过期，从而判断是否重传内容。

与截止模型相关，这里还有一次请求，只是如果缓存有效，则不会重传内容。

实现方式：Last-Modified实体头部域经常用于证实模型，如果实体在Last-Modified值以来没有修改过，则可以认为此缓存有效。

ETag头部域提供“不透明”的证实。

【由过期时间想到的】

近来看协议，看源码，过期时间或者超时总会频繁出现。

思考，为什么在这种大型的架构中，过期时间这样一个限制是如此频繁的出现。又或者我们在cookie或session中所看到的expire，缓存中的时间限制等等。这些都是我们经常可以遇到的。

如果我们把这些东西赋予生命，那么我们所设置的这些都是他们的生命终止的时候。

为了保证程序或信息流的生命的完整性，我们希望他们在出生后，只能存活这样一段时间，在我们可以控制的范围内自然的消散？

那对于内存的分配和新的垃圾收集机制，PHP中使用了引用计数，如果使用过期时间，在某个特定的时间内有效，又或者我们无法控制用户所定义的变量的生命周期，所以我们无法以过期时间来实现？

前面提到了session，PHP的session存储方案中，以文件存储为例，设置了过期时间。以文件的最后修改时间为准。

一次http请求，如果缓存 在客户端的内容还没有过期，则直接使用客户端的内容，这是http协议的一种过期模型。这是一个纯粹的以过期时间缓存的模型。不存在再次的交互。

在应用中提到过期，也许我们会看到缓存这个东西。缓存，以一种更快的介质或更短的距离取代较慢的介质或较长的传输距离的优化方式。

如果一个生命没有了完结的时候，它永生了，又当如何？守护进程，我们希望他会一直运行，那如何我们需要时时的中断这样的守护进程，如何管理？我们在做设计的时候如何处理？对于一个永不过期的缓存，如果我们需要将其清除掉，如何处理？清除这一个？以相同 的key重新设置？

以上的http协议的过期模型来自 RFC2616

后面是乱想的…

从年前开始，一直在和朋友一起写TIPI系统文章…