brotli Google делала не как ещё один универсальный архиватор, а конкретно под HTTP-ответы — отсюда главное отличие от zstd и gzip: встроенный статический словарь примерно на 122 КБ, порядка 13 с половиной тысяч слов и фраз из HTML, JS и нескольких живых языков (включая русский). zstd и gzip строят словарь с нуля по ходу сжатия конкретного файла, brotli же стартует с готовым набором типичных для веба последовательностей — на маленьких текстовых файлах это даёт заметную фору, которую окно скользящего сжатия само наверстать не успевает.
Базовый вызов — через -q, уровень от 0 (быстро, слабое сжатие) до 11 (максимум, он же по умолчанию для CLI):
brotli -q 11 app.js -o app.js.br # максимальное сжатие, медленно
brotli -q 4 -f access.log -o access.log.br # быстрее, для разовой задачи
За счёт этого brotli и стал стандартным Content-Encoding: br у Cloudflare и других CDN: статика (JS, CSS, HTML) сжимается один раз при деплое на максимальном уровне, а дальше отдаётся уже готовым файлом без затрат на пережатие на лету. В nginx это не штатная возможность — нужен отдельно собираемый модуль ngx_brotli, в отличие от gzip он в ядро nginx не встроен.
На произвольных бинарных данных без текстовых паттернов (дампы БД, бинарные логи) преимущество словаря исчезает, и на максимальном качестве brotli заметно медленнее zstd при сравнимом или чуть лучшем сжатии — для таких задач словарь, заточенный под веб-тексты, просто нечем занять.
#linux #архиваторы