压缩¶

在Varnish3.0中，我们引入了对压缩的本地支持，使用的是GZIP编码。 Before 3.0，Varnish永远不会压缩对象。

在Varnish 4.0中，压缩默认设置为“on”，这意味着它试图变得聪明并做明智的事情。

如果不希望对编码进行Varnish篡改，可以通过设置参数同时禁用压缩 http_gzip_support 变成假的。请看一看人华而不实了解更多细节。

默认行为¶

属性时，默认行为处于活动状态 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集 bereq.http.Accept-Encoding 到之前的“gZip” vcl_backend_fetch 运行，因此可以在VCL中更改标头。

如果服务器使用压缩后的内容进行响应，它将以压缩的形式存储在内存中 Accept-Encoding 将添加到 Vary 标题。

对于支持GZIP的客户端，压缩内容原封不动地提供。

对于不支持GZIP的客户，压缩后的内容在交付时会被动态解压。这个 Content-Encoding 响应头被移除，并且任何 Etag 变弱(通过前缀“W/”)。

对于不同的查找， Accept-Encoding 被忽略。

您可以告诉Varnish先压缩内容，然后再将其存储在 vcl_backend_response 通过设置 beresp.do_gzip 要“真”，就像这样：：

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或应用程序服务器上压缩内容更有意义，后者更有可能是CPU受限的。

请确保您不要试图压缩不可压缩的内容，如JPG、GIF和MP3文件。这样只会浪费CPU周期。

您还可以在将内容存储到缓存之前将其解压缩，方法为 beresp.do_gunzip 变成了“真”。此功能的一个用例是绕过配置不佳的后端，无用地压缩已经压缩的内容，如JPG图像(但修复行为不正常的后端总是更好的选择)。

使用 beresp.do_gunzip 设置为“true”时，在将结果对象插入缓存之前，Varnish将对结果对象的标头进行以下更改：

如果您正在使用Edge Side Includes(ESI)，您会很高兴地注意到ESI和GZIP可以很好地协同工作。Varnish将神奇地解压缩内容以进行ESI处理，然后重新压缩它以实现高效的存储和交付。

当 http_gzip_support 参数设置为“OFF”，则Varnish不会执行上面记录的任何标题更改、句柄 Vary: Accept-Encoding 就像对任何其他人一样 Vary 值并忽略 beresp.do_gzip 和 beresp.do_gunzip 。

保尔-亨宁·坎普写道 GZIP和GZIP+ESI在Varnish中的工作方式它更多地讲述了实现是如何工作的。