Какие преимущества предлагает какой-либо метод для файлов html, css и javascript, обслуживаемых сервером LAMP. Есть ли лучшие альтернативы?
Сервер предоставляет информацию в приложении карты с помощью Json, поэтому большой объем небольших файлов.
См. также Есть ли какой-либо удар производительности при выборе gzip для дефляции для сжатия 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 быстрее, тем не менее, поскольку Я усвоил трудный путь.
Вероятно, вы не сможете выбрать дефляцию в качестве опции. Вопреки тому, что вы можете ожидать, mod_deflate не использует deflate, а gzip. Таким образом, хотя большая часть сделанных баллов действительна, скорее всего, это не относится к большинству.
Основная причина заключается в том, что дефляция быстрее кодируется, чем gzip и на занятом сервере, что может иметь значение. С статическими страницами это другой вопрос, так как их можно легко предварительно предварительно сжать.
Я думаю, что нет большой разницы между deflate и gzip, потому что gzip в основном представляет собой только заголовок, обернутый вокруг deflate (см. RFC 1951 и 1952).
mod_deflate требует меньше ресурсов на вашем сервере, хотя вы можете заплатить небольшой штраф за количество сжатия.
Если вы обслуживаете множество небольших файлов, я бы рекомендовал бенчмаркинг и загрузку ваших сжатых и несжатых решений - вы можете найти некоторые случаи, когда включение сжатия не приведет к экономии.
Не должно быть никакой разницы в gzip и deflate для декомпрессии. Gzip просто сбрасывается с несколькими десятками байт-заголовков, обернутых вокруг него, включая контрольную сумму. Контрольная сумма является причиной более медленного сжатия. Однако, когда вы предварительно сжимаете zillions файлов, вы хотите, чтобы эти контрольные суммы были проверкой на работоспособность в вашей файловой системе. Кроме того, вы можете использовать инструменты командной строки для получения статистики по файлу. Для нашего сайта мы прекомпрессируем массу статических данных (весь открытый каталог, 13 000 игр, автозаполнение для миллионов ключевых слов и т.д.), И мы оцениваем себя на 95% быстрее, чем все веб-сайты Alexa. Поиск факсов. Тем не менее, мы используем домашний веб-сервер. Apache/mod_deflate просто не сократил его. Когда эти файлы сжимаются в файловую систему, вы не только получаете удар для своего файла с минимальным размером блока файловой системы, но и все ненужные накладные расходы при управлении файлом в файловой системе, о котором веб-сервер может заботиться меньше. Ваши проблемы должны быть общими дисками и временем доступа/декомпрессии и, во-вторых, скоростью, позволяющей предварительно сжать эти данные. Отпечаток очень важен, потому что хотя дисковое пространство дешево, вы хотите как можно больше поместиться в кеш.
В Ubuntu с Apache2 и уже установленным модулем deflate (который используется по умолчанию) вы можете включить сжатие gzip deflate в два простых шага:
a2enmod deflate
/etc/init.d/apache2 force-reload
И ты далеко! Я обнаружил, что страницы, которые я обслуживал по моей связи с ADSL, загружались намного быстрее.
Редактировать: в соответствии с комментарием @GertvandenBerg, это включает сжатие gzip, а не выкачивание.
если я правильно помню