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

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

Простой ответ: не надо.

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

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

Формат zlib определен в RFC 1950 как:

     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]. Этот формат представляет собой кодировку Лемпеля-Зива (LZ77) с 32-битным CRC.

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

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

CRC-32 медленнее, чем ADLER32

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

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

Теперь базовые TCP-пакеты уже довольно надежны, поэтому проблема здесь не в Adler 32. по сравнению с CRC-32, который использует GZIP.

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

Итак, с годами браузеры начали реализовывать реализацию deflate нечеткой логики, они пробуют использовать заголовок 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 (см. RFC 1951 и 1952).

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

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

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

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

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

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

Изменить: согласно комментарию @ GertvandenBerg, это включает сжатие gzip, а не дефляцию.

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

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