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

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

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

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

Зачем использовать 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, они просто ожидали сжатую полезную нагрузку. Аналогичным образом различные веб-серверы допустили одну и ту же ошибку.

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

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

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

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

GZip - это просто deflate плюс контрольная сумма и верхний / нижний колонтитулы. Дефлят быстрее , хотя, как я узнал, трудным путем.

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

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

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

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 сжимает чуть больше, чем выкачивает
• дефляция более эффективна