转载

squid 对gzip压缩请求的过程 （转贴）

转载：http://squidcn.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=amonth%3d4%26ayear%3d2008

Squid 能否正确的处理gzip，完全取决于realserver会否发送正确的Vary:头部。一般来说，反向代理环境里，自己能控制realserver。而 采用Apache这样的标准web服务器，可配置mod_deflate让它发送正确的Vary:头部。这个头部的作用，就是指示squid，应该根据客 户端的请求方式不同，返回不同的压缩或非压缩目标。

浏 览器请求squid上的某个目标，假设该目标在squid上有压缩过的缓存，该缓存同时包括一个”Vary:”头部（按照RFC 2616协议，对压缩过的内容Apache必须返回该头部给squid）。Squid会根据缓存里的Vary头部的值和请求头部进行匹配，如果请求头部里 包含了Accept-Encoding相应值，则squid返回压缩过的目标给浏览器。相反，如果请求头部里没有包含Accept-Encoding字段 （通常是http/1.0方式），则squid会将请求转发给realserver。按照标准，Squid不允许发送压缩过的目标拷贝给不接受 Encoding的浏览器。

Squid的请求到了realserver，mod_deflate返回非压缩的内容给Squid。这个响应也包含Vary头部，但不 是压缩的。squid拿到这个响应后，更新自己的缓存（squid的缓存目标存储结构是以url为key的哈希，就是同一个url下只能存储一份 cache目标），并将响应返回给客户端。
下一次如果客户的请求又包含了Accept-Encoding字段，squid会根据缓存目标的Vary头部，再去realserver取一份压缩的内容返回给客户端，并更新自己的缓存。

所以，在上述机制下，squid对gzip的兼容没有问题。
但是，这里有2个明显的问题：

1. 对某个cache住的目标，一个http/1.0请求可能会导致squid强制更新其缓存。但接下来的另一个http/1.1请求又会导致squid再次更新缓存。这就极大的降低了cache命中率。
2. 某些客户端，如IE6及以下，如果发送http/1.0的请求，realserver会返回没有压缩过的内容，同时包含一个Vary:头部。这些客户端不能处理这个头部，结果就导致目标无法下载。这是IE的bug，我们做不了什么。但碰到这种情况，用户会投诉你。