在反向代理模式下，Squid可以caching先前由networking中的设备访问的网站的内容。
如果远程站点上的内容在某种程度上发生了变化，或者通过代码推送，会发生什么？ Squid如何知道它需要去原始网站获取新版本的资产，而不是caching？
现在，dynamic的基于JavaScript的（单个页面）网站会出现这个问题吗？
一个方面的问题：“反向代理”本质上与Squid的“加速器模式”是一回事吗？
是的，Squid将使用传统方法来caching来自后端服务器的响应，后者通过解释后端服务器发送每个响应的头文件。
不应caching的dynamic内容的典型响应如下所示：
Expires: Fri Jul 25 10:19:36 CEST 2014 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache 从技术上讲，这些标题本身已经足以宣布响应的内容是dynamic的，但传统的看法似乎仍然使用它们。 货物崇拜编程或向后兼容？
caching控制是您应该最关心的标题。 这些是针对您的Squid反向代理以及任何中间caching代理服务器（包括实际浏览器）的caching指令。 选项是：
private或public ; 私人响应是特定于用户的，不应该被caching，公共响应可以被caching。 no-cache主要是听起来像是一个指令，重新validation每个后续请求的资源。 虽然经过validationcertificate资源仍然有效，但caching的响应仍然可以提供。 no-store明确的指示，即响应必须被视为机密，而不是存储，比上面的no-cache选项要强一些。 max-age以秒为单位）覆盖Expires标题，并指示资产何时到期并应从caching中清除。
s-maxage与上述相同，但对于像内容交付networking这样的共享caching。 过期是设置caching指令的经典方式，将来不会超过1年的简单时间戳。
Pragma是一个真正老派的头文件，将它设置为no-cache将被任何最近的浏览器解释为Cache-Control: no-cache ，我认为它不再存在于更新的HTTP协议规范中，尽pipe仍然是历史后向兼容。
设置更多静态内容的标题应指示Squid（以及访问者的Web浏览器）可以caching这些响应。
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
问题是，除非你手动刷新Squidcaching的内容，否则对象将在其caching控制头期间被存储。 Squid没有像在Varnish中find的规定，或者软件CDN用来履行PURGE请求来使特定的caching对象无效。
解决方法是让您的内容pipe理解决scheme确保更新静态内容来与新的文件名，而不是覆盖现有的文件。
当然你的本地configuration可以覆盖头文件中设置的指令。
是的，在Squid环境下，反向代理和Web加速器是一回事 。