Зачем использовать 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 как:
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 плюс контрольная сумма и верхний / нижний колонтитулы. Дефлят быстрее, хотя, как я узнал, трудный путь.
Вы, вероятно, не в состоянии фактически выбрать дефлят в качестве опции. Вопреки тому, что вы можете ожидать, 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 сжимает чуть больше, чем выкачивает
- дефляция более эффективна