引言

HTTP（Hypertext Transfer Protocol，超文本传输协议[插图]）是在万维网上进行通信时所使用的协议方案。HTTP有很多应用，但最著名的是用于Web浏览器和Web服务器之间的双工通信。

《HTTP权威指南》一书将HTTP中一些互相关联且常被误解的规则梳理清楚，并编写了一系列基于各种主题的章节介绍HTTP各方面的特性。纵观全书，对HTTP“为什么”这样做进行了详细的解释，而不仅仅停留在它是“怎么做”的。此外，这本书还介绍了很多HTTP应用程序正常工作所必需且重要的非HTTP技术。

这本书主要包括以下内容：

• 第一部分描述了Web的基础构件与HTTP的核心技术
• 第二部分重点介绍了Web系统的结构构造块：HTTP服务器、代理、缓存、网关以及机器人应用程序。
• 第三部分提供了一套用于追踪身份、增强安全性以及控制内容访问的技术和技巧。
• 第四部分涵盖HTTP报文主体和Web标准，前者包含实际内容，后者描述并处理主体内容。
• 第五部分介绍了发布和传播Web内容的技巧。
• 第六部分是一些很有用的参考附录，以及相关技术的教程。

缓存

Web缓存是可以自动保存常见文档副本的HTTP设备。当Web请求抵达缓存时，如果本地有“已缓存的”副本，就可以从本地存储设备而不是原始服务器中提取这个文档。

控制缓存的能力

服务器可以通过HTTP定义的几种方式来指定在文档过期之前可以将其缓存多长时间。

no-Store与no-Cache响应首部

HTTP/1.1提供了几种限制对象缓存，或限制提供已缓存对象的方式，以维持对象的新鲜度。no-store首部和no-cache首部可以防止缓存提供未经证实的已缓存对象：

Pragma: no-cache
Cache-Control: no-store
Cache-Control: no-cache

标识为no-store的响应会禁止缓存对响应进行复制。缓存通常会像非缓存代理服务器一样，向客户端转发一条no-store响应，然后删除对象。

标识为no-cache的响应实际上是可以存储在本地缓存区中的。只是在与原始服务器进行新鲜度再验证之前，缓存不能将其提供给客户端使用。这个首部使用do-not-serve-from-cache-without-revalidation这个名字会更恰当一些。

HTTP/1.1中提供Pragma: no-cache首部[插图]是为了兼容于HTTP/1.0+。除了与只理解Pragma: no-cache的HTTP/1.0应用程序进行交互时，HTTP 1.1应用程序都应该使用Cache-Control: no-cache。

max-age响应首部

Cache-Control: max-age首部表示的是从服务器将文档传来之时起，可以认为此文档处于新鲜状态的秒数。还有一个s-maxage首部（注意maxage的中间没有连字符），其行为与max-age类似，但仅适用于共享（公有）缓存：

Cache-Control: max-age=3600
Cache-Control: s-maxage=3600

服务器可以请求缓存不要缓存文档，或者将最大使用期设置为零，从而在每次访问的时候都进行刷新：

Cache-Control: max-age=0
Cache-Control: s-maxage=0

Expires响应首部

不推荐使用Expires首部，它指定的是实际的过期日期而不是秒数。HTTP设计者后来认为，由于很多服务器的时钟都不同步，或者不正确，所以最好还是用剩余秒数，而不是绝对时间来表示过期时间。可以通过计算过期值和日期值之间的秒数差来计算类似的新鲜生存期：

Expires: Fri, 05 Jul 2002, 05:00:00 GMT

有些服务器还会回送一个Expires:0响应首部，试图将文档置于永远过期的状态，但这种语法是非法的，可能给某些软件带来问题。应该试着支持这种结构的输入，但不应该产生这种结构的输出。

must-revalidate响应首部

可以配置缓存，使其提供一些陈旧（过期）的对象，以提高性能。如果原始服务器希望缓存严格遵守过期信息，可以在原始响应中附加一个Cache-Control: must-revalidate首部。

Cache-Control: must-revalidate

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

试探性过期

如果响应中没有Cache-Control:max-age首部，也没有Expires首部，缓存可以计算出一个试探性最大使用期。可以使用任意算法，但如果得到的最大使用期大于24小时，就应该向响应首部添加一个Heuristic Expiration Warning（试探性过期警告，警告13）首部。据我们所知，很少有浏览器会为用户提供这种警告信息。

LM-Factor算法是一种很常用的试探性过期算法，如果文档中包含了最后修改日期，就可以使用这种算法。LM-Factor算法将最后修改日期作为依据，来估计文档有多么易变。算法的逻辑如下所示。

• 如果已缓存文档最后一次修改发生在很久以前，它可能会是一份稳定的文档，不太会突然发生变化，因此将其继续保存在缓存中会比较安全。
• 如果已缓存文挡最近被修改过，就说明它很可能会频繁地发生变化，因此在与服务器进行再验证之前，只应该将其缓存很短一段时间。

实际的LM-Factor算法会计算缓存与服务器对话的时间跟服务器声明文档最后被修改的时间之间的差值，取这个间隔时间的一部分，将其作为缓存中的新鲜度持续时间。下面是LM-factor算法的Perl伪代码：

$time_since_modify = max(0, $server_Date - $server_Last_Modified);
$server_freshness_limit = int($time_since_modify ＊ $lm_factor);

客户端的新鲜度限制

Web浏览器都有Refresh（刷新）或Reload（重载）按钮，可以强制对浏览器或代理缓存中可能过期的内容进行刷新。Refresh按钮会发布一个附加了Cache-Control请求首部的GET请求，这个请求会强制进行再验证，或者无条件地从服务器获取文档。Refresh的确切行为取决于特定的浏览器、文档以及拦截缓存的配置。

客户端可以用Cache-Control请求首部来强化或放松对过期时间的限制。有些应用程序对文档的新鲜度要求很高（比如人工刷新按钮），对这些应用程序来说，客户端可以用Cache-Control首部使过期时间更严格。另一方面，作为提高性能、可靠性或开支的一种折衷方式，客户端可能会放松新鲜度要求。

注意事项

文档过期系统并不是一个完美的系统。如果发布者不小心分配了一个很久之后的过期日期，在文档过期之前，她要对文档做的任何修改都不一定能显示在所有缓存中。

因此，很多发布者都不会使用很长的过期日期。而且，很多发布者甚至都不使用过期日期，这样缓存就很难确定文档会在多长时间内保持新鲜了。

总结

按照优先级递减的顺序，服务器可以：

• 附加一个Cache-Control: no-store首部到响应中去；
• 附加一个Cache-Control: no-cache首部到响应中去；
• 附加一个Cache-Control: must-revalidate首部到响应中去；
• 附加一个Cache-Control: max-age首部到响应中去；
• 附加一个Expires日期首部到响应中去；
• 不附加过期信息，让缓存确定自己的过期日期。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。