浅聊 HTTP Cache

概述

所谓的 HTTP Cache 机制，其实是服务端和客户端之间的一套约定，需要依靠客户端和服务端程序来具体实现。

现代浏览器以及一些高抽象层次对服务端 web 框架一定程度上实现了对这套约定的支持。但是，当我们使用一些较底层的 http 工具来收发请求时，这些工具通常不包含这些逻辑，需要人工合理实现。

大致流程

• 客户端首次向服务端请求某个数据，没有任何缓存可用，因此服务端总是会发回所请求的数据
• 服务端通过 Response 中的相关 Header，指导客户端对内容进行缓存
• 当客户端再次请求该数据时，会首先对本地缓存版本进行检查
  • 如果缓存没有过期，则直接使用本地缓存的版本
  • 如果缓存已经过期，则会对缓存进行重新校验
    • 客户端会将缓存的指纹发送到服务端，请求服务端对数据进行校验
    • 如果匹配成功，则表示当前数据并没有更新，服务端不会重发数据，客户端为本地缓存续期并继续使用
    • 如果匹配失败，则表示当前数据已经更新了，服务端发送新数据给客户端，客户端弃用旧缓存，并缓存新数据

技术细节

服务端主要通过 Response 中的 Cache-Control Header 来指导客户端对数据进行缓存。

例如，如果服务端希望客户端将数据缓存一天，则可以设置 Cache-Control: max-age: 86400。注意 max-age 的参数是秒。额外地，服务端还会附带一个 ETag Header，携带该数据的指纹。

如果客户端发现本地缓存过期后，向服务端再次请求数据时，会带上 If-None-Match Header，其值为这份数据的指纹，即服务端传回数据时携带的 ETag，以便于服务端对数据进行校验。

在客户端缓存的有效期内，数据请求会直接读取本地缓存，而不会真实地向服务端进行发送。如果客户端要强制更新一波本地缓存，则可以带上 Cache-Control: no-cache Header，告诉服务端，不看缓存了，直接进入校验环节吧。

以上例子只是列举了一些常规用法。还有一些参数如 no-store, smaxage, must-reinvalidate 等，可以帮助实现更精细化的控制，就不在这里展开了。

最后，感谢并推荐希望更进一步的读者阅读以下参考链接。

参考

• HTTP Caching