gzip和http1.1

奇怪的是：为什么squid不完全兼容http1.1?当然squid 3.0以后是完全支持了。

 

一般的过程：浏览器 ---请求---->squid -----请求----->apache
apache在 response header 中返回了一个vary:Accept-encoding ,则squid在存储缓存文件时需要将“浏览器”request header 信息中的Accept-encoding字段的值（gzip，deflate之类）作为缓存key的一部分，因此对于不同的Accept-encoding字段值，都需要保存不同的文件。（IE与firefox的请求头的Accept-encoding字段值中就有一个空格的差别）

下次请求到squid的时候，需要先找到一个缓存文件的索引文件，根据索引文件中的不同的Accep-encoding值再去找相应的缓存文件

IE : Accept-Encoding: gzip, deflate
Firefox: Accept-Encoding: gzip,deflate

 

    Squid支持对http1.0压缩内容的缓存,需要将cache_vary设置成on。使squid能够缓存带有vary头的内容，假如这里设为Off，会发现一个奇怪的现象，缓存命中率会比设为on降低很多，即使你调整refresh_pattern的参数，增大内容缓存时间，maximum_object_size_in_memory设的合适，加大内存等都没用。用用Cache Manager 仔细的查看各个统计数据，In-Memory and In-Transit Objects，html页面显示NOT_IN_MEMORY，而图片jpg等则缓存了。

原因:
{{{
# TAG: cache_vary
# Set to off to disable caching of Vary:in objects.
#Default: cache_vary on
}}}

       cache vary off,那么经过gzip压缩后含有vary头的，都不会被cache了，所以和上述缓存策略没什么影响，而jpg本来是被压缩过，不含vary,自然会被cache了。

curl -H "Accept-Encoding:gzip" -I
HTTP/1.1 200 OK
Date: Wed, 21 Nov 2012 03:54:44 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Wed, 21 Nov 2012 03:43:16 GMT
ETag: "235d3c-0-4cef926901d00"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Pragma: no-cache
Content-Length: 20
Connection: close
Content-Type: text/html; charset=UTF-8
从上面看，浏览器支持压缩，所以经过压缩的内容返回一个vary:accept-encoding ,那么假如Squid不打开这个选项，那么就导致压缩的内容不被cache住。

Nginx, 修改nginx.conf中的gzip_version配置项：

 gzip on;
 gzip_http_version 1.0;

 gzip_vary on;

由于早期的一些浏览器或者http客户端，可能不支持gzip自解压，用户就会看到乱码，所以做一些判断.
对于apache ,可以看官方docs :

 

    HTTP1.1协议中，Response头部可以指定Transfer-Encoding（以下简称TE）和Content-Encoding（以下简称CE）两种编码方式。TE和CE是出于两种完全不同的目的而设计的，TE是为无法预知Response内容大小而设计的，否则Web Server首先需要把所有内容缓冲在本地，然后通过Content-Length指明长度，常用于动态页面。CE是为节省网络流量设计的，压缩后Response内容更小，常用于纯文本内容。每得到一个TE的chunk分块完整内容，就对其进行CE解压处理，处理好的内容拼接起来就得到最终的内容，处理完所有chunk分块后页面就出来了。