squid代理服务器怎么支持gzip压缩
这几天遇到几个客户反应源站gzip压缩的文件经过cdn-squid后压缩失败；
经过检查发现源站对gzip压缩只是http-1.1的没有对http-1.0进行压缩导致终端访问的无gzip压缩；
让客户在源站设置支持http-1.0压缩后，问题解决了！
具体的原因是（转）：
gzip压缩分为两种，http1.0和http1.1压缩，
这两种压缩的压缩方法和response header都一样，只是客户端和服务器通讯的http协议不同。
Squid2.7之前，是不支持http1.1的。在2.7版本开始，有限支持http1.1。从3.0版本开始，才完整的支持http1.1。但是因为squid3是完全重构的，很多2.7的功能并没有加到3.0当中，所以squid3并没有被大规模的应用在生产系统中，基本上都还是使用squid2.6或2.7来进行内容加速，所以需要搞定Squid支持各种Web服务器的HTTP1.0 GZIP压缩。
具体配置:
1, 配置Web服务器，支持HTTP1.0压缩
Apache, 默认就支持http1.0压缩,不需要特定配置
IIS, 通过修改MetaBase.xml第三段IIsCompressionSchemes中的
HcNoCompressionForHttp10="TRUE"
HcNoCompressionForProxies="TRUE"
HcNoCompressionForRange="FALSE"
将HcNoCompressionForHttp10="TRUE" 修改为FALSE
HcNoCompressionForProxies="TRUE"
HcNoCompressionForRange="FALSE"
将HcNoCompressionForHttp10="TRUE" 修改为FALSE
Nginx, 修改nginx.conf中的gzip_version配置项，修改为gzip_version http1.0;
配置后，再发http1.0的压缩请求到nginx，就能够获得压缩后的内容。
2, 配置Squid,支持对http1.0压缩内容的缓存
首先，将cache_vary设置成on。使squid能够缓存带有vary头的内容
然后，将broken_vary_encoding设置成all。squid.conf.default中，这个参数的示例是
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
broken_vary_encoding allow apache
这个挺有趣，我理解这个参数应该是很早加入的，那时候web服务器还是apache一家的天下。所以作者直接就写了一个allow apache，并一直沿用至今。
这个参数是针对那些压缩前和压缩后etag完全一致的web服务器，让squid通过vary头来区分压缩和未压缩的内容。事实上，现在apache已经不需要通过broken_vary_encoding来区分vary头了。Apache会修改经过压缩的内容的etag头, 在原来的etag后面加上-gzip。用来区分压缩和非压缩内容。而其他的web服务器都没有这样的功能。都需要通过配置broken_vary_encoding来支持。
Vary: WEB 服务器用该头部的内容告诉 Cache 服务器，在什么条件下才能用本响应所返回的对象响应后续的请求。 假如源 WEB 服务器在接到第一个请求消息时，其响应消息的头部为：Content-Encoding: gzip; Vary: Content-Encoding；那么 Cache服务器会分析后续请求消息的头部，检查其 Accept-Encoding，是否跟先前响应的 Vary 头部值一致，即是否使用 相同的内容编码方法，这样就可以防止 Cache 服务器用自己 Cache 里面压缩后的实体响应给不具备解压能力的浏览器。 例如：Vary：Accept-Encoding
通过配置上面两个参数，你就可以配置squid正确的缓存Apache,IIS,Nginx输出的压缩内容。
目录 返回
首页