Сжатие текста уже давно стало стандартом в мире веб‑приложений. Сокращение объёма данных даёт сокращение времени передачи и снижение нагрузки на сетевой канал. Однако, часто настройка компрессии сводится к динамическому сжатию gzip и настройкам по умолчанию. В этой статье разберём вопрос сжатия более глубоко. Для начала вспомним основные технологии сжатия, доступные в вебе.

Навигация по циклу

1. Почему стоит переходить на Angie.

2. Установка Angie из пакетов и в докере.

3. Переезд с Nginx на Angie. Пошаговая инструкция.

4. Настройка location в Angie. Разделение динамических и статических запросов.

5. Перенаправления в Angie: return, rewrite и примеры их применения.

6. Сжатие текста в Angie: статика, динамика, производительность.

7. Серверное кэширование в Angie: тонкости настройки.

8. Настройка TLS в Angie: безопасность и скорость.

9. Настройка Angie в роли обратного HTTP-прокси.

10. Балансировка нагрузки для HTTP(S) в Angie.

11. Мониторинг Angie с помощью Console Light и API.

12. Балансировка и проксирование L4-трафика в Angie.

13. Клиентское кэширование в Angie.

14. Динамические группы проксируемых серверов в Angie.

15. Мониторинг Angie с Prometheus и Grafana.

16. Отказоустойчивый кластер Angie с VRRP и Keepalived.

17. Контроль доступа в Angie.

18. Аутентификация клиентов в Angie с помощью TLS-сертификатов.

19. Кастомизация Angie (njs, Lua, Perl).

20. Запуск CGI-скриптов в Angie.

21. Защита от DoS-атак в Angie стандартными модулями.

22. Защита от DoS-атак в Angie (дополнительные средства).

23. Автоматические TLS-сертификаты в Angie с модулем ACME.

24. HTTP/2 и HTTP/3: настройка, достоинства и недостатки.

25. Работа с картинками в Angie.

26. Инструменты для бенчмарка веб-сервера.

27. Тест современных компрессоров для HTTP.

Видеоверсия

Для вашего удобства подготовлена видеоверсия этой статьи, доступна на Rutube, VKVideo и YouTube.

Варианты компрессии для веба

Для решения задачи сжатия текстовых ресурсов существует несколько форматов, получивших достаточно широкую поддержку в браузерах и других клиентах:

• gzip, deflate — традиционный формат сжатия с максимальной поддержкой;

• brotli (br) — новый формат сжатия, оптимизирован для высоких коэффициентов компрессии;

• Zstandard (zstd) — новый формат, оптимизирован для высокой скорости сжатия и декомпрессии.

В контексте веб‑сервера Angie доступен штатный модуль для gzip и сторонние модули для brotli и zstd. Помимо алгоритмов сжатия есть два режима: динамический и статический. Динамическое сжатие означает компрессию ответа в реальном времени, во время обработки запроса. В таком режиме ресурсы процессора затрачиваются на каждый запрос. Статическое сжатие — это создание сжатых копий ресурсов на диске, которые при ответе нужно всего лишь прочитать с диска и отправить по сети. Таким образом, ресурс центрального процессора используется лишь один раз (при создании сжатой копии) и не во время обработки запроса, а при публикации ресурса (или сборки статики).

Выбор настроек для статического сжатия несложен: используем максимальные настройки компрессии (затраты процессорной мощности не важны) и формат, который обладает лучшим коэффициентом сжатия. Забегая вперёд, это будет brotli со степенью сжатия 11 (максимальная). Конечно, статическое сжатие стоит использовать везде, где это возможно. Также не стоит забывать про технику минификации файлов, где она применима. Использование минификации имеет положительный эффект на размер файла даже при использовании сжатия.

При использовании динамического сжатия выбор алгоритма сжатия и настроек компрессии не так очевиден. Сделать такой выбор нам поможет сравнительный тест.

Тестирование компрессоров

Ранее мы уже обращались к теме компрессоров для веба в статье про сжатие текстовых ресурсов. Основной акцент той статьи был на практике применения модулей сжатия в Angie. Сейчас стоит вернуться к вопросу выбора оптимальной степени сжатия и компрессора с учётом издержек на передачу, сжатие и декомпрессию текстового ресурса. Чтобы сделать обоснованный выбор, необходимо сравнить различные компрессоры в одинаковых условиях на наборе данных, приближённых к реальным. 

В качестве бенчмарка будем использовать открытый проект lzbench. Он позволяет удобно сравнить скорость работы всех интересующих нас вариантов (brotli, zstd, gzip) и предоставляет результаты в удобной форме. В качестве тестовых данных будем использовать файлы с HTML, CSS и JS‑кодом большого размера (от 1 МБ и больше). HTML‑файл использован из комплекта Silesia (файл webster, 40,5 МБ). CSS и JS файлы взяты с реального сайта и имеют размеры 1,0 МБ и 1,8 МБ соответственно. Бенчмарк lzbench даёт высокую повторяемость результатов и использует актуальные версии библиотек. Результаты хорошо согласуются с тестированием модулей сжатия в сервере Angie. Бенчмарк всегда использует одно ядро процессора, что также нас устраивает. При этом процессор обладает высокой тактовой частотой, поэтому на серверных системах стоит ожидать более низких абсолютных показателей.

Условия тестирования:

• lzbench актуальной версии (сборка из исходных кодов);

• zlib 1.3.1;

• brotli 1.2.0;

• zstd 1.5.7;

• ЦПУ: AMD Ryzen 5800x;

• ОС: Ubuntu 24.04.

• Виртуализация: KVM.

Запуск тестов производился следующей командой (изменялся только файл):

./lzbench -o4 -ezlib/brotli/zstd 1.css

В параметрах мы запросили тест трёх интересующих нас библиотек и активировали формат вывода в CSV для простого импорта в электронную таблицу, где будет проводиться анализ. На выходе мы получаем три набора данных (каждый для своего файла), которые необходимо проанализировать. Исходные файлы и результаты можно найти репозитории.

Результаты теста

Первый тест проведён с файлом в формате HTML webster (40,5 МБ). В первой колонке указан компрессор, его версия и степень сжатия. Вторая колонка показывает скорость сжатия контента в МБ/c, третья — скорость декомпрессии. Четвёртая колонка отвечает за результирующий коэффициент сжатия в процентах от исходного объёма файла. Изучим таблицу подробнее.

Таблица 1. Результаты теста для HTML.

Абсолютный лидер по скорости компрессии: zstd -1, за ним идёт brotli -0. При этом zstd с низкими настройками компрессии достигает хорошего коэффициента. В целом по результатам zlib (gzip) показывает полный провал: как по скорости, так и по степени сжатия. Высокие настройки сжатия для brotli (10–11) и zstd (14–22) однозначно не пригодны для динамического сжатия из‑за низкой скорости. Что касается декомпрессии, то она практически не меняется в рамках одной библиотеки и остаётся стабильно высокой, абсолютный лидер в этой категории — zstd. Стоит заметить, что скорее всего задачей декомпрессии ресурса будет заниматься клиент и используемая библиотека может отличаться.

Если рассматривать результаты для статической компрессии, то здесь нас ожидает сюрприз: победителем выходит zstd -22. Обычно в этой категории побеждает brotli, но для этого файла большого размера (более 40 МБ) лучшим оказался zstd.

Посмотрим, будет ли отличаться картина при сжатии CSS.

Таблица 2. Результаты теста для CSS.

Здесь на своё место встаёт максимальное сжатие с brotli — абсолютный лидер по степени компрессии. 

Для динамического режима (низкие степени) всё остаётся как и в прошлом тесте: zstd лидирует по скорости и качеству сжатия, за ним с заметным отрывом по скорости идёт brotli. 

Наконец, дополним картину результатами для JS‑файла.

Таблица 3. Результаты теста для JS.

Результаты теста с JS‑файлом подтверждают все выводы теста с CSS, расстановка вариантов сжатия не меняется.

Из приведённых данных можно сделать нужные выводы для использования тех или иных вариантов компрессии в статическом режиме, без ограничения процессорных ресурсов. Также не стоит забывать о старых клиентах, которые поддерживают только gzip/deflate. Наибольшую степень компрессии для gzip можно получить при использовании zopfli или утилиты zstd ‑format=gzip. Подробнее эти вопросы разобраны ранее в статье про текстовое сжатие. 

Но как выбрать оптимальную степень компрессии для реального применения в работе веб‑сервера? Для этого потребуется учесть несколько дополнительных факторов.

Выбор оптимальной степени динамической компрессии

Предварительно на основе результатов тестов мы определили лидера в динамической компрессии — zstd. Однако не ясно, какую степень разумно использовать для этого кодека?

С точки зрения минимизации использования процессорных ресурсов нужно использовать минимальные настройки для каждого компрессора. При этом мы получим неплохой коэффициент сжатия (около 3-х раз) и максимальную скорость компрессии.

Другой подход заключается в выборе компромиссного варианта между нагрузкой на процессор и размером передаваемого ресурса. Здесь мы уже не получим простого ответа, необходимы расчёты. Целевым параметром для оптимизации здесь может стать общее время обработки запроса, включая сжатие, декомпрессию и передачу по сети.

Представим модель процесса передачи ресурса с динамическим сжатием в виде следующих компонент, выраженных во времени:

• отправка запроса (RTT);

• сжатие ресурса (C);

• отправка сжатого ответа(T);

• декомпрессия ответа (D).

Очевидно, что для получения результирующего времени нужно ввести несколько переменных: размер файла (S), задержка в сети (RTT), и пропускная способность канала (BW). Из результатов теста нам известна скорость компрессии (Cs), декомпрессии (Ds) и коэффициент сжатия (R). Из этого можно составить формулу расчёта для полного времени обработки запроса:

Эта формула учитывает издержки на компрессию и декомпрессию ресурса, а также на передачу его по сети при заданных параметрах файла и сетевого канала.

Чтобы применить эту модель в рамках нашего теста возьмём следующие значения:

• RTT 10 мс;

• BW: 1 МБ/с;

• S: 1 МБ.

В файле с результатами параметры задаются на листе «Settings». Эти параметры эквиваленты передаче среднего комплекта JS‑кода для сайта по достаточно скоростному мобильному подключению (около 8 Мбит/с или 10 мс задержка). Добавим расчёт этого времени для каждого варианта сжатия в таблицы с результатами (колонка «Total time»).

Если отбросить варианты со скоростью компрессии менее 50 МБ/с (как слишком медленные), то получим следующее распределение (тест CSS):

То же самое в табличной форме: 

Таблица 4. Общее время для CSS.

Оптимальными с точки зрения общего времени обработки будут средние степени компрессии brotli (5-7) или zstd (7-9), при этом zstd немного обгоняет brotli. Основной вклад при наших условиях в общее время вносит компонента передачи файла, поэтому мы наблюдаем такую расстановку. Посмотрим на эти же расчёты для JS-файла:

И в табличном виде:

Таблица 5. Общее время для JS.

Общее распределение похоже на пример с CSS, но в лидеры за счет малого размера файла выбивается brotli 5–6. С небольшим отставанием следует zstd 7–8. Конечно, нужно учитывать, что тестирование проводилось на процессоре с высокой однопоточной производительностью. 

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

Для примера разберём ситуацию с низкой (примерно в 2 раза ниже) скоростью процессора (Intel Core i5-8300H на частоте около 2.0 Ghz) и высокой скоростью канала (12 МБ/c, около 100 Мбит/с), размер ресурса оставим 1 МБ. Результаты показаны на картинке ниже.

Для файла CSS получаем оптимальные настройки по общему времени передачи для zstd 3–4, для brotli оптимальный вариант 0–1. Дальнейшее увеличение скорости канала или снижение скорости процессора будет смещать настройки в сторону низких степеней компрессии еще больше.

Настало время подвести итоги статьи.

Итоги

По результатам проведённых тестов можно констатировать разгромное поражение gzip‑сжатия (zlib в тесте). Единственным преимуществом этого формата сжатия можно назвать совместимость: как со стороны клиентов, так веб‑серверов. В остальном brotli находится в жестком соревновании с zstd. В зависимости от набора данных вперёд выходит один из них. Для статического сжатия в большинстве случаев лучше подойдёт brotli 11.

Ситуация с выбором параметров динамического сжатия сложнее: оптимальный выбор зависит от пропускной способности канала и размеров ресурсов. Наиболее совместимая рекомендация: использовать средне‑низкие настройки сжатия с brotli и/или zstd (3–5). При наличии свободных процессорных ресурсов на сервере степени можно увеличить не несколько позиций.