当前位置：文江博客话题详情

服务器端 GZipping 如何工作？

发布于 2024-07-30 11:52:54 字数 341 浏览 1 评论 0原文

您可能知道 HTML 相关文件格式是使用服务器端 GZip 压缩进行压缩的（通过 mod_gzip 在 Apache 服务器上），并由兼容的浏览器解压缩。（“内容编码”）

这仅适用于 HTML/XML 文件吗？假设我的 PHP/Perl 文件生成一些简单的逗号分隔数据，并将其发送到浏览器，默认情况下会对其进行编码吗？

像Silverlight或Flash这样的平台呢，当它们下载这些数据时，浏览器/运行时会自动压缩/解压缩吗？有什么方法可以测试这个吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

以酷 2024-08-06 11:52:54

这仅适用于 HTML/XML
文件？

不：例如，它经常用于 CSS 和 JS 文件——因为它们是网站构成的最大的东西之一（图像除外），由于 JS 框架和完整的 JS 应用程序，它代表了巨大的收获！

实际上，任何基于文本的格式都可以很好地压缩（相反，例如图像则不能，因为它们通常已经被压缩）；有时，从 Ajax 请求返回的 JSON 数据也会被压缩——毕竟它是文本数据;-)

假设我的 PHP/Perl 文件生成
一些简单的逗号分隔数据，以及
将其发送到浏览器，会吗
默认编码？

这是一个配置问题：如果您将服务器配置为压缩此类内容，那么它可能会被压缩:-)

（如果浏览器表示接受 gzip 编码数据）

以下是我在博客上使用的 Apache 2 配置示例（使用 mod_deflate）：

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/xml
</IfModule>

这里，我希望压缩 html/xml/css/JS。

这是同样的事情，加上/减去我在 Apache 1 (mod_gzip) 下使用过的一些配置选项：

<IfModule mod_gzip.c>
    mod_gzip_on                   Yes
    mod_gzip_can_negotiate        Yes

    mod_gzip_minimum_file_size    256
    mod_gzip_maximum_file_size    500000

    mod_gzip_dechunk              Yes

    mod_gzip_item_include         file       \.css$
    mod_gzip_item_include         file       \.html$
    mod_gzip_item_include         file       \.txt$
    mod_gzip_item_include         file       \.js$
    mod_gzip_item_include         mime       text/html

    mod_gzip_item_exclude         mime       ^image/
</IfModule>

这里可以注意到的是我不希望太小（增益不是很重要）或要压缩的文件太大（会占用太多 CPU 来压缩）；我希望压缩 css/html/txt/js 文件，但不压缩图像。

如果您希望以相同的方式压缩逗号分隔的数据，则必须将其内容类型或其扩展名添加到网络服务器的配置中，以为其激活 gzip 压缩。

有什么办法可以测试一下吗？

对于直接返回到浏览器的任何内容，Firefox 的扩展 Firebug 或 LiveHTTPHeaders 是必备的。

对于不通过浏览器标准通信方式的内容，可能会更困难；最后，您可能不得不使用 Wireshark 之类的东西来“嗅探”真正发生的事情管道...祝你好运！

Silverlight 或 Flash 等平台怎么样？
当他们下载这些数据时，它会被压缩/解压缩吗
由浏览器/运行时自动执行？

要回答有关 Silverlight 和 Flash 的问题，如果它们发送 Accept 标头表明它们支持压缩内容，Apache 将使用 mod_deflate 或 mod_gzip。如果他们不支持压缩，他们将不会发送标头。它会“正常工作”。 - 内特

Does this only work for HTML/XML
files?

No : it is quite often used for CSS and JS files, for instance -- as those are amongst the biggest thing that websites are made of (except images), because of JS frameworks and full-JS applications, it represents a huge gain!

Actually, any text-based format can be compressed quite well (on the opposite, images can not, for instance, as they are generally already compressed) ; sometimes, JSON data returned from Ajax-requests are compressed too -- it's text data, afterall ;-)

Lets say my PHP/Perl file generates
some simple comma delimited data, and
sends that to the browser, will it be
encoded by default?

It's a matter of configuration : if you configured your server to compress that kind of content, it'll probably be compressed :-)

(If the browser says it accepts gzip-encoded data)

Here's a sample of configuration for Apache 2 (using mod_deflate) that I use on my blog :

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/xml
</IfModule>

Here, I want html/xml/css/JS te be compressed.

And here is the same thing, plus/minus a few configuration options I used once, under Apache 1 (mod_gzip) :

<IfModule mod_gzip.c>
    mod_gzip_on                   Yes
    mod_gzip_can_negotiate        Yes

    mod_gzip_minimum_file_size    256
    mod_gzip_maximum_file_size    500000

    mod_gzip_dechunk              Yes

    mod_gzip_item_include         file       \.css$
    mod_gzip_item_include         file       \.html$
    mod_gzip_item_include         file       \.txt$
    mod_gzip_item_include         file       \.js$
    mod_gzip_item_include         mime       text/html

    mod_gzip_item_exclude         mime       ^image/
</IfModule>

Things that can be noticed here are that I don't want too small (the gain wouldn't be quite important) or too big (would eat too much CPU to compress) files to be compressed ; and I want css/html/txt/js files to be compressed, but not images.

If you want you comma-separated data to be compressed the same way, you'll have to add either it's content-type or it's extension to the configuration of your webserver, to activate gzip-compression for it.

Is there any way to test this?

For any content returned directly to the browser, Firefox's extensions Firebug or LiveHTTPHeaders are a must-have.

For content that doesn't go through the standard communication way of the browser, it might be harder ; in the end, you may have to end up using something like Wireshark to "sniff" what is really going through the pipes... Good luck with that!

What about platforms like Silverlight or Flash,
when they download such data will it be compressed/decompressed
by the browser/runtime automatically?

To answer your question about Silverlight and Flash, if they send an Accept header indicating they support compressed content, Apache will use mod_deflate or mod_gzip. If they don’t support compression they won’t send the header. It will “just work.” – Nate

回复收藏 0 原文

離人涙 2024-08-06 11:52:54

我认为 Apache 的 mod_deflate 更常见比 mod_gzip 更好，因为它是内置的并且做同样的事情。查看 mod_deflate 的文档（上面链接），您会发现根据 MIME 类型指定要压缩的文件类型很容易。一般来说，压缩 HTML、CSS、XML 和 JavaScript 是值得的。图像已经被压缩，因此它们不会从压缩中受益。

回复收藏 0 原文

〆凄凉。 2024-08-06 11:52:54

浏览器发送一个“Accept-Encoding”标头，其中包含它知道如何理解的压缩类型。服务器与用户代理一起查看此信息并决定如何对结果进行编码。有些浏览器会谎报它们可以理解的内容，因此这比仅仅在标头中搜索“deflate”要复杂得多。

从技术上讲，任何带有内容的 HTTP/2xx 响应都可以使用任何有效的内容编码（gzip、zlib、deflate 等）进行内容编码，但实际上，对常见图像类型应用压缩是浪费的，因为它实际上使它们变得更大。

您绝对可以压缩动态 PHP 页面的响应。最简单的方法是将：添加

<?php ob_start("ob_gzhandler"); ?>

到每个 PHP 页面的开头。当然，最好通过 PHP 配置来设置。

有很多测试页面，可以通过 Google< 轻松找到/a>:

The browser sends an "Accept-Encoding" header with the types of compression that it knows how to understand. The server looks at this, along with the user-agent and decides how to encode the result. Some browsers lie about what they can understand, so this is more complex than just searching for "deflate" in the header.

Technically, any HTTP/2xx response with content can be content-encoded using any of the valid content encodings (gzip, zlib, deflate, etc.), but in practice it's wasteful to apply compression to common image types because it actually makes them larger.

You can definitely compress the response from dynamic PHP pages. The simplest method is to add: