压缩

在varnish 3.0中我们原生支持压缩，使用gzip编码。在3.0之前版本，varnish是不会对内容进行压缩的。

在varnish 4.0中压缩是默认开启的，这意味着它更加聪明的去做应该做的事。

如果你不想用varnish压缩，你可以将http_gzip_support设置为false。具体可以看varnishd的内容。

默认行为

默认情况下，http_gzip_support是设置为on并开启压缩的。beresp.do_gzip和beresp.do_gunzip在vcl中默认都是不使用的。

除非从vcl_recv中返回pipe或者pass，varnish会修改req.http.Accept-Encoding：如果客户端支持gzip的话，req.http.Accept-Encoding将会被设置为gzip，否则的话头会被去除。

除非请求是一个pass，varnish会在vcl_backend_fetch运行之前将req.http.Accept-Encoding设置为gzip，因此在vcl中头信息会被改变。

如果服务器响应的是使用gzip压缩过的内容，它将会被存在内存中。Accept-Encoding头也会被加到Vary头中。

对于支持gzip的客户端，内容将会被直接发送，而不会做任何改变。

对于不支持gzip的客户端，压缩内容会在返回时被解压缩。Accept-Encoding头会被去掉。

对于Vary查找，Accept-Encoding会被忽略。

你可以在vcl_backend_response中通过设置beresp.do_gzip为true来告诉varnish在讲内容存到缓存之前对其进行压缩，就像这样：

sub vcl_backend_response {
    if (beresp.http.content-type ~ "text") {
        set beresp.do_gzip = true;
    }
}

当beresp.do_gzip被设置为true，varnish将会在插入缓存之前对结果的头信息做如下改变：

一般情况下，varnish不会占用太多的CPU资源，因此varnish循环使用CPU比使用直接你的web服务器更有意义一些。

请确保你不对不支持压缩的内容进行压缩，例如jpg，gif，mp3文件等。你只会浪费CPU资源。

你也可以将beresp.do_gunzip设置为true来让存入缓存之前对内容进行解压缩。一个使用案例是为了解决配置不当导致服务器白白压缩已经压缩过的内容，比如jpg。

当beresp.do_gunzip设置为true之后，varnish将会在内容存入缓存之前做一下改变：

如果你是用了ESI，你会高兴的发现ESI和GZIP配合工作是如此的完美。varnish将会魔法般解压缩内容，并对内容做ESI处理。然后重新压缩以方便存储和传输。

当http_gzip_support参数被设置为off之后，varnish将不会再对内容进行压缩。

参考Poul-Henning Kamp写的一篇关于在varnish中GZIP和GZIP+ESI是如何工作的的文章。