主页 / server / 问题 / 1140965
Accepted
Lumi
Asked: 2023-08-07 22:31:16 +0800 CST

用于图像的 Apache GZIP - 有什么原因吗？

  • 772

JPEG、GIF、PNG 和 WEBP 图像已被压缩。无论客户端是否表示可以接受 GZIP 压缩，是否有任何理由使用 GZIP 压缩来为它们提供服务？

curl -H "Accept-Encoding: gzip" -I ^
 https://www.nps.gov/articles/000/images/LATP_Article_TheCalutronGirls.jpg

此 HEAD 请求生成以下标头：

HTTP/1.1 200 OK
Content-Type: image/jpeg
…
Date: Sat, 05 Aug 2023 04:13:29 GMT
Server: Apache
…
Last-Modified: Wed, 04 Jan 2023 21:36:01 GMT
…
Content-Encoding: gzip
…

该服务器将以 GZIP 形式发送图像 - JPEG、PNG、WEBP。我认为这根本没有任何意义，是服务器配置错误，但也许时代已经改变，现在这是合法的……很快就会成为新常态？

（服务器时钟相差 58 小时这一事实似乎表明它管理不善。）

23 年 8 月 8 日：通过联系表向 NPS 报告。

web-server

1 个回答

  1. Best Answer

    1019174当我比较原始文件的字节与 gzip1001991压缩版本的字节时，向该特定文件添加 gzip 压缩（使用默认设置）确实会使其稍微变小（± 1.7%） 。在此基础上使用压缩当然没有害处，并且确实节省了“一些” 带宽。
    这种有限的好处是否超过了实现压缩所需的 CPU 周期？我不知道。

    不过，为 CSS、Javascript 和 HTML 内容添加压缩通常被认为更有益，例如以下数字所证明的那样：本文显示压缩可将传输的 HTML/CSS/JavaScript 数据量减少 60-80% 。

    但通常不会，压缩已压缩的数据（例如 JPEG、PNG 和大多数其他图像格式）是没有意义的，对于任何其他已经压缩的数据（例如实际的 ZIP 存档和 PDF 文档）也没有意义。
    正如这个例子已经表明的那样：您不应该能够通过添加第二层压缩来实现更多的额外压缩，并且（互联网共识是）在某些情况下，额外的压缩实际上可能会使文件稍大一些。

    这就是为什么mod_deflate的 Apache 手册包含仅对特定文件类型启用压缩和/或排除某些其他类型文件的示例。

    <Directory "/path/to/html/content">
    # enable compression only for the html files 
    AddOutputFilterByType DEFLATE text/html
</Directory>


<Directory "/path/to/html/content">
   # enable compression for all content 
   SetOutputFilter DEFLATE

   # exclude image files from compression by file extension 
   SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png)$" no-gzip
</Directory>
    • 4

相关问题