Зачем использовать deflate вместо gzip для текстовых файлов, обслуживаемых Apache?

Какие преимущества предлагает любой метод для файлов html, css и javascript, обслуживаемых сервером LAMP. Есть ли лучшие альтернативы?

сервер предоставляет информацию для картографического приложения с помощью Json, поэтому большой объем небольших файлов.

см. также есть ли какой-либо хит производительности, связанный с выбором gzip над deflate для сжатия http?

9 ответов


зачем использовать deflate вместо gzip для текстовых файлов, обслуживаемых Apache?

простой ответ:не.


RFC 2616 определяет deflate как:

deflate формат "zlib", определенный в RFC 1950 в сочетании с механизмом сжатия "deflate", описанным в RFC 1951

формат zlib определен в RFC 1950 as :

     0   1
     +---+---+
     |CMF|FLG|   (more-->)
     +---+---+

       0   1   2   3
     +---+---+---+---+
     |     DICTID    |   (more-->)
     +---+---+---+---+

     +=====================+---+---+---+---+
     |...compressed data...|    ADLER32    |
     +=====================+---+---+---+---+

Итак, несколько заголовков и контрольная сумма ADLER32

RFC 2616 определяет gzip, как:

gzip формат кодирования, созданный программой сжатия файлов "gzip" (GNU zip), как описано в RFC 1952 [25]. Этот формат Кодирование Lempel-Ziv (LZ77) с 32-битным CRC.

RFC 1952 определяет сжатые данные как:

формат в настоящее время использует метод DEFLATE сжатие, но может быть легко расширено для использования других методов сжатия.

CRC-32 это медленнее, чем ADLER32

сравненный к циклической проверке дублирования такой же длины, оно торгует надежностью для скорости (предпочитая последнее).

Так ... у нас есть 2 механизма сжатия, которые используют то же самое алгоритм сжатия, но a разные для заголовков и контрольная сумма.

теперь базовые пакеты TCP уже довольно надежный, так что вопрос тут не в Адлере 32 vs CRC-32, который использует GZIP.


оказывается, многие браузеры за эти годы реализовали неправильный алгоритм дефляции. Вместо того, чтобы ожидать заголовок zlib в RFC 1950, они просто ожидали сжатую полезную нагрузку. Аналогично различные веб-серверы сделали ту же ошибку.

Итак, с годами браузеры начали реализации нечеткая логика выкачать реализацию, они пытаются для заголовка zlib и контрольной суммы adler, если это не удается, они пытаются для полезной нагрузки.

результатом наличия такой сложной логики является то, что она часто нарушается. Verve Studio есть пользователь внес тест раздел, который показывает, насколько плохая ситуация.

например: deflate работает в Safari 4.0, но сломан в Safari 5.1, он также всегда имеет проблемы с IE.


Итак, лучший дело в том, чтобы избежать дефляции в целом, незначительное повышение скорости (из-за adler 32) не стоит риска сломанных полезных нагрузок.


GZip просто выкачать плюс контрольная сумма и верхний / нижний колонтитул. Сдуть быстрее, а Я учился на горьком опыте.


вы, вероятно, не сможете фактически выбрать deflate в качестве опции. Вопреки тому, что вы можете ожидать mod_deflate не использует deflate, но gzip. Поэтому, хотя большинство сделанных замечаний являются обоснованными, они, вероятно, не актуальны для большинства.


основная причина заключается в том, что deflate быстрее кодируется, чем gzip, и на занятом сервере, что может иметь значение. Со статическими страницами это другой вопрос, так как они могут быть легко предварительно сжаты один раз.


Я думаю, что нет большой разницы между deflate и gzip, потому что gzip в основном является просто заголовком, обернутым вокруг deflate (см. RFCs 1951 и 1952).


mod_deflate требует меньше ресурсов на ваш сервер, хотя вы можете заплатить небольшой штраф, с точки зрения степени сжатия.

Если вы обслуживаете много небольших файлов, я бы рекомендовал бенчмаркинг и нагрузочное тестирование сжатых и несжатых решений - вы можете найти некоторые случаи, когда включение сжатия не приведет к экономии.


не должно быть никакой разницы в gzip & deflate для декомпрессии. Gzip просто сдувается с несколькими десятками байтовых заголовков, обернутых вокруг него, включая контрольную сумму. Контрольная сумма является причиной более медленного сжатия. Однако, когда вы предварительно сжимаете миллиарды файлов, вы хотите, чтобы эти контрольные суммы были проверкой здравомыслия в вашей файловой системе. Кроме того, вы можете использовать инструменты командной строки, чтобы получить статистику на файл. На нашем сайте мы precompressing кучу статических данных (все открыть каталог, 13,000 игр, автозаполнение для миллионов ключевых слов и т. д.) и мы занимаем 95% быстрее, чем все веб-сайты Alexa. Поиск Faxo. Тем не менее, мы используем домашний собственный веб-сервер. Apache и mod_deflate просто не вырезать его. Когда эти файлы сжимаются в файловую систему, вы не только принимаете удар для своего файла с минимальным размером блока файловой системы, но и все ненужные накладные расходы при управлении файлом в файловой системе, что веб-сервер может заботиться меньше о. Ваши заботы должны быть полным следом за диском и временем доступа/распаковки и вторично скоростью в мочь получить эти данные precompressed. След важен, потому что даже если дисковое пространство дешево, вы хотите как можно больше вписаться в кэш.


на Ubuntu с Apache2 и уже установленным модулем deflate (который по умолчанию) вы можете включить сдуется сжатие gzip в два простых шага:

a2enmod deflate
/etc/init.d/apache2 force-reload

и ты далеко! Я нашел страницы, которые я обслуживал через ADSL-соединение, загруженные намного быстрее.

Edit: согласно комментарию @GertvandenBerg, это позволяет сжатие gzip, а не сдувать.


Если я правильно помню

  • gzip будет сжимать немного больше, чем сдувать
  • сдуваться более эффективным!--4-->