Комментарии 2
а есть замеры по latency с включённым и выключенным сжатием? интересно насколько выигрыш на практике
Не-а, замеров latency нет, и я не стал их делать намеренно— объясню почему.
Во-первых, переключателя не существует: в этом и суть статьи. Чтобы получить "включено", нужен другой сервер — LiteSpeed на ls-qpack или что-нибудь на Google QUICHE (вроде Envoy). Тогда вы сравните два сервера целиком, а не наличие таблицы.
Во-вторых, мой стенд однопроцессный и на localhost: ни RTT, ни потерь. 385 лишних байт там утонут в джиттере измерения, и я получил бы красивый ноль, который ничего не значит.
По физике: на одиночном ответе разницы почти нет. И 131, и 516 байт спокойно влезают в один пакет, так что лишние 385 байт не стоят вам ни одного дополнительного RTT. Заметно становится там, где байты упираются в окно:
Начальное окно перегрузки — порядка 14 КБ. Лишние 385 байт на ответ съедают около 3% первого флайта, и это чувствуется на мелких API-ответах, где тело меньше заголовков.
Мультиплексирование. Пятьдесят ответов в одном соединении — это уже ~19 КБ одних только лишних байт, больше целого начального окна.
Плохой канал. На мобильном каждый лишний ретрансмит стоит сотни миллисекунд.
Если хотите померить чисто, я бы изолировал переменную так: один и тот же nginx, но в одном варианте добавить add_header ровно на 385 байт, а в другом нет. Это воспроизводит дельту без смены сервера. Сверху tc netem с реальными RTT и потерями, дальше TTLB по сотне запросов на соединение. Стенд лежит тут, конфиги менять в две строки — если сделаете, принесите цифры, мне самому интересно)

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