Алгоритмизация сжатия текстовых файлов. Методы сжатия, поддерживаемые браузерами. Обзор методов клиентской оптимизации
Методы сжатия, поддерживаемые браузерами
Браузер в каждом запросе к серверу, в поле Accept-Encoding может указать, какие методы сжатия он поддерживает. Сервер, отвечая на запрос, может выбрать один из указанных браузером методов и, высылая сжатое тело ответа, указать в заголовке (в поле «Content-Encoding») какой именно метод был выбран.
Вот, к примеру, поле «Accept-Encoding» браузера Opera 10.00:
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Браузер указал, что поддерживаются два метода сжатия: deflate и gzip. Названия с приставкой «x-» оставлены для совместимости, это историческое название, «gzip» и «x-gzip» (также как «compress» и «x-compress») эквивалентны. Метод «identity» («идентично») означает отсутствие сжатия, то есть данные передаются без изменений. Мы намеренно не рассматриваем остальные значения, подробнее на этом вопросе мы остановимся позже, в части про реализацию сжатия на стороне сервера.
На данный момент браузеры совокупно поддерживают следующие методы сжатия: gzip (x-gzip) —два метода gzip и deflate используют один и тот же алгоримт сжатия — DEFLATE (RFC 1951), использующий комбинацию алгоритма LZ77 и кодирования Хаффмана. В методе gzip (RFC 1952) перед сжатым потоком добавляется десять байт заголовка, а после —восемь байт, состоящие из контрольной суммы (CRC32) и длины несжатых данных. deflate (x-deflate) — представляет собой сжатый алгоритмом DEFLATE поток без заголовка и других метаданных compress (x-compress) — в данном случае тело ответа такое же, как если бы оно было сжато UNIX-программой compress. Compress использует алгоритм LZC, являющийся реализацией LZW (Lempel–Ziv–Welch) с указателями переменного размера, как в алгоритме LZ78. bzip2 (x-bzip, bzip) — тело ответа совпадает с результатом работы программы bzip2, алгоритм более эффективен, чем compress и семейство DEFLATE, но работает значительно медленнее. В bzip2 применяются преобразование Барроуза-Уилера, MTF-преобразование (move-to-front) и кодирование Хаффмана
sdch (Shared Dictionary Compression Over HTTP) — относительно новый, предложенный компанией Google в сентябре 2008 года метода уменьшения избыточной информации в вебе. Основная идея — не передавать дважды одинаковые куски документа (например, шапку, «подвал» страницы, общие CSS и JavaScript-файлы). Метод построен на алгоритме VCDIFF (RFC3284), ответ дополнительно может быть сжат любым другим поддерживаемым браузером методом сжатия (например, gzip)
Метод «sdch» сильно отличается от прочих и имеет смысл только для группы страницы, эффективность же остальных методов проще оценить на примере HTML-страницы, полученной склейкой первых страниц нескольких новостных изданий:
У архиваторов gzip и bzip2 есть параметр, управляющий эффективностью компрессии, его значение изменяется от единицы до девятки, чем выше значение, тем эффективнее сжатие и тем больше времени оно занимает. В тесте, провед?нном выше, этот параметр для обоих архиваторов был установлен в максимальное значение.
Худший результат типично показывает метод compress, по этой причине многие браузеры отказались от поддержки этого метода. Лучший результат — у bzip2, но этот метод, весьма требовательный к ресурсам, лишь недавно стал появляться в браузерах, на данный момент его поддерживают OmniWeb, w3m, lynx и ранние версии Google Chrome.
На сайте языка программирования PHP, в комментариях к описанию функции gzcompress есть результаты, иллюстрирующие, насколько может зависеть затраченное время и эффективность сжатия архиваторов gzip и bzip2 от параметра, задающего эффективность компрессии, а также разницу в требованиях к ресурсам этих архиваторов:
Кажущееся странным поведение архиватора bzip2 с параметром большим единицы (результат архивации не улучшается) объясняется очень просто: параметр от одного до девяти, в этом случае, зада?т размер блока — от 100КБ до 900КБ.
Что в точности означает этот параметр для нас маловажно, существенно то, что если выбранный файл (исходный размер — 184,5КБ) целиком помещается в блок, алгоритм bzip2 не улучшает результат при увеличении размера блока, но сжатие занимает больше времени.
Вывод — если вы настраиваете на сервере сжатие bzip2 в реальном времени, выбирайте размер блока чуть большим, чем средний размер страниц вашего сайта.
У gzip, как видно, зависимость однозначная, оптимальная стратегия, в данном случае — установить такой параметр эффективности сжатия, который ваш сервер выдержит, с некоторым запасом.
Существуют также аппаратные решения, позволяющие эффективно сжимать трафик алгоритмом gzip со скоростью вплоть до 10 гигабит в секунду, например, платы расширения фирмы Comtech AHA Corporation.