Обновить

У nginx сжатие заголовков одностороннее

Уровень сложностиСложный
Время на прочтение24 мин
Охват и читатели8.6K
Всего голосов 2: ↑1 и ↓10
Комментарии2

Комментарии 2

а есть замеры по latency с включённым и выключенным сжатием? интересно насколько выигрыш на практике

Не-а, замеров latency нет, и я не стал их делать намеренно— объясню почему.

Во-первых, переключателя не существует: в этом и суть статьи. Чтобы получить "включено", нужен другой сервер — LiteSpeed на ls-qpack или что-нибудь на Google QUICHE (вроде Envoy). Тогда вы сравните два сервера целиком, а не наличие таблицы.

Во-вторых, мой стенд однопроцессный и на localhost: ни RTT, ни потерь. 385 лишних байт там утонут в джиттере измерения, и я получил бы красивый ноль, который ничего не значит.

По физике: на одиночном ответе разницы почти нет. И 131, и 516 байт спокойно влезают в один пакет, так что лишние 385 байт не стоят вам ни одного дополнительного RTT. Заметно становится там, где байты упираются в окно:

  1. Начальное окно перегрузки — порядка 14 КБ. Лишние 385 байт на ответ съедают около 3% первого флайта, и это чувствуется на мелких API-ответах, где тело меньше заголовков.

  2. Мультиплексирование. Пятьдесят ответов в одном соединении — это уже ~19 КБ одних только лишних байт, больше целого начального окна.

  3. Плохой канал. На мобильном каждый лишний ретрансмит стоит сотни миллисекунд.

Если хотите померить чисто, я бы изолировал переменную так: один и тот же nginx, но в одном варианте добавить add_header ровно на 385 байт, а в другом нет. Это воспроизводит дельту без смены сервера. Сверху tc netem с реальными RTT и потерями, дальше TTLB по сотне запросов на соединение. Стенд лежит тут, конфиги менять в две строки — если сделаете, принесите цифры, мне самому интересно)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации