Squid 如何知道它的缓存是否经过验证

Squid 如何知道它的缓存是否经过验证

在反向代理模式下,Squid 可以缓存网络内的设备先前访问过的网站的内容。

如果远程站点上的内容以某种方式发生变化(例如通过代码推送),会发生什么情况?Squid 如何知道它需要前往原始站点而不是其缓存来获取资产的新版本?

对于基于动态 javascript(单页)的网站来说,这是否是一个更大的问题?

附带一个问题:“反向代理”本质上是否与 Squid 的“加速器模式”相同?

答案1

是的,Squid 将使用传统方法解释后端服务器随每个响应发送的标头,从而缓存来自后端服务器的响应。

对于不应缓存的动态内容的典型响应如下所示:

Expires: Fri Jul 25 10:19:36 CEST 2014 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

从技术上讲,每个标头本身已经足以声明响应的动态内容,但传统观点似乎仍然使用它们。货物崇拜编程还是向后兼容?

Cache-Control是您最应该关注的标头。这些是 Squid 反向代理以及任何中间缓存代理服务器(包括实际浏览器)的缓存指令。选项包括:

  • private或者public;私人回应特定于用户并且不应被缓存,但公共回应可能会被缓存。
  • no-cache基本上就是字面意思,是一条指令,要求对每个后续请求重新验证资源。尽管验证后证明资源仍然有效,但仍然可以提供缓存的响应。
  • no-store明确的指示是,响应必须被视为机密,根本不可存储,比上面的无缓存选项更强一些。
  • max-age以秒为单位覆盖 Expires 标头并指示资产何时过期并应从缓存中清除。
    • s-maxage以秒为单位,与上面相同,但适用于内容传送网络等共享缓存。

Expires是设置缓存指令的经典方式,带有未来不超过 1 年的简单时间戳。

Pragma是一个非常老式的标头,将其设置为no-cache将被任何最近的浏览器解释为,Cache-Control: no-cache并且我认为它不再存在于较新的 HTTP 协议规范中,尽管仍然尊重历史向后兼容性。

为更多静态内容设置的标头应该指示 Squid(以及访问者的 Web 浏览器)可以缓存这些响应。

Cache-Control: no-transform,public,max-age=300,s-maxage=900
Content-Type: text/html; charset=UTF-8
Date: Fri Jul 25 10:19:36 CEST 2014 GMT
Expires: Sat Jul 26 10:19:36 CEST 2014 GMT

问题是,除非您手动刷新 Squid 缓存内容,否则对象将在其缓存控制标头的持续时间内存储。Squid 没有像 Varnish 或软件 CDN 那样的配置来遵守 PURGE 请求以使特定缓存对象无效。

解决方法是让您的内容管理解决方案确保静态内容的更新带有新文件名,而不是覆盖现有文件。

当然你的本地配置可以覆盖标题中设置的指令。

是的,在 Squid 上下文中,反向代理和 Web 加速器是一样的东西

相关内容