HTTP/2 и HTTP/3: где выигрыш реальный, а где его нет — тесты 2026

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Включать HTTP/2 и HTTP/3 «по умолчанию» нельзя: на чистых каналах и внутри дата-центра они могут проигрывать HTTP/1.1, поэтому решение нужно принимать по замерам на своей нагрузке, а не по вендорским слайдам.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Включить HTTP/2 и HTTP/3 «на всякий случай» — привычка из той же серии, что ставить SSD в сервер, который упирается в сеть. Звучит правильно, стоит денег и времени, а на выходе может не дать ничего. Или дать минус.

Автор на Хабре собрал стенд и прогнал три версии протокола — HTTP/1.1, HTTP/2 и HTTP/3 — через шесть эмулированных сетей, от дата-центра до края мобильной соты. Результат отрезвляет: на чистых каналах HTTP/2 отстаёт от HTTP/1.1, а внутри дата-центра новые протоколы проигрывают старому в разы. Это не ошибка замера. Это свойство среды.

Для собственника и маркетолога вывод простой: вопрос «включать ли HTTP/2 и HTTP/3» не имеет универсального ответа. Он решается замерами на вашей нагрузке, а не чтением вендорских слайдов.

Что вообще обещают новые протоколы

Три тезиса кочуют из презентации в презентацию. Мультиплексирование — запросы идут параллельно по одному соединению, очередь за ресурсами исчезает. QUIC — транспорт под HTTP/3 — спокойнее переживает потерю пакетов, потому что не блокирует весь поток из-за одного потерянного сегмента. Рукопожатие — один круг вместо двух, соединение устанавливается быстрее.

Про HTTP/2 и HTTP/3 говорят одно и то же. Включаешь, и всё летает. Мультиплексирование убирает очередь запросов, QUIC держит удар при потере пакетов, рукопожатие складывается в один круг вместо двух.

Логика красивая. Проблема в том, что она выведена из условий, где эти плюсы вообще имеют шанс проявиться. Очередь запросов мешает, когда запросов много и они конкурируют за канал. Потеря пакетов бьёт по скорости, когда потери есть. Рукопожатие экономит время, когда задержка на круг заметна. Уберите эти условия — и преимущества испаряются.

Где выигрыш пропадает

Автор прогнал все три протокола через шесть сетей с разными характеристиками. Два сценария дали неожиданный результат.

Первый — чистый канал. Нет потерь, нет перегрузки, задержка минимальна. Здесь HTTP/2 отстаёт от HTTP/1.1. Причина в накладных расходах: мультиплексирование требует управлять потоками, а когда канал и так свободен, эта работа не окупается. Вы платите за инфраструктуру, которая решает проблему, которой у вас нет.

Второй — дата-центр. Внутренние сервисы, близкие друг к другу, быстрая сеть, предсказуемая нагрузка. Здесь новые протоколы проигрывают HTTP/1.1 в разы. Не на проценты — в разы.

На чистых каналах HTTP/2 отстаёт от HTTP/1.1, а в дата-центре новые протоколы проигрывают старому доброму предшественнику в разы.

Это ломает привычную картину. Мы привыкли думать, что новые версии протокола — это апгрейд, который всегда в плюс. На практике HTTP/2 и HTTP/3 — не апгрейд. Это другой инструмент под другие условия.

Почему чужие графики врут

Красивые кривые из блогов и презентаций сняты на чужих стендах. Они показывают лучший случай: медленный канал, потери, мобильный клиент. В этих условиях HTTP/3 действительно выигрывает, и график это честно отражает. Нечестно другое — умолчание о том, что за пределами этого сценария картина переворачивается.

Хуже того, получить недостоверно красивый результат в таком замере методически легко. Достаточно выбрать удачную конфигурацию сети, подобрать нагрузку, отбросить неудобные прогоны. Автор говорит об этом прямо.

А потом выяснилось, что и получить красивую неправду в таком замере до обидного легко.

Это не про недобросовестность конкретных людей. Это про то, что бенчмарк без указания условий — бесполезная картинка. Условия важнее результата.

Что с этим делать в вашем проекте

Первое. Не включайте новые протоколы «по умолчанию» на всём. Разделите трафик на категории: внешние пользователи на мобильных сетях, внешние на быстром интернете, внутренние сервисы, служебные вызовы между бэкендами. Для каждой категории ответ может быть разным.

Второе. Замеряйте на своей нагрузке. Не на синтетическом тесте из документации, а на реальном профиле запросов. Смотрите не только на среднее время ответа, но и на хвосты — p95 и p99. Именно там прячутся проблемы, которые не видны в среднем.

Третье. Держите возможность отката. Если после включения HTTP/2 или HTTP/3 метрики просели, вы должны вернуться назад за минуты, а не за неделю согласований.

Четвёртое. Для внутренних сервисов в дата-центре начинайте с HTTP/1.1 как baseline. Если замеры покажут выигрыш от перехода — переходите. Если нет — не тратьте время команды.

Подвох, о котором стоит помнить

Главный риск не в том, что вы включите HTTP/3 и станет хуже. Главный риск в том, что вы включите его, ничего не заметите, и будете считать, что сделали оптимизацию. А на самом деле — добавили сложности в инфраструктуру без измеримой пользы.

Второй подвох — доверие к чужому опыту. То, что сработало у крупного сервиса с миллионами пользователей на мобильных сетях, может не сработать у вас. У них другие условия. Их графики не переносятся на вашу нагрузку автоматически.

Брать или подождать

Брать — если у вас значимая доля мобильного трафика, потери пакетов в канале, заметная задержка на рукопожатии. HTTP/3 в этих условиях даёт реальный выигрыш, и замеры это подтвердят.

Подождать — если основная нагрузка идёт внутри дата-центра или по чистым быстрым каналам. Здесь новые протоколы не дают ничего, а в дата-центре могут проигрывать в разы. Включать их «на будущее» — трата ресурсов без отдачи.

Замерить — если не знаете, к какой категории относитесь. Это самый частый случай. Соберите стенд, прогоните свой профиль нагрузки, посмотрите на p95 и p99. Решение принимайте по цифрам, а не по слайдам.

Вопросы, которые задают чаще всего

HTTP/3 всегда быстрее HTTP/1.1?

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

Можно ли просто включить HTTP/2 и забыть?

Можно, но смысла мало. Если ваша нагрузка не страдает от очереди запросов, вы не получите выигрыша. А накладные расходы на управление потоками останутся.

Почему в дата-центре новые протоколы проигрывают в разы?

Потому что условия, под которые их оптимизировали, там отсутствуют. Нет потерь, нет высокой задержки, канал свободен. Остаются только накладные расходы, и они оказываются значительными.

Как понять, что мне нужен HTTP/3?

Замерить. Если у вас много мобильных пользователей и вы видите проблемы с задержками на плохих каналах — стоит проверить. Если трафик внутренний и каналы чистые — вряд ли.

Чужие бенчмарки вообще бесполезны?

Не бесполезны, но их нельзя переносить на свою нагрузку без проверки. Они показывают, что протокол может дать в определённых условиях. Ваши условия могут быть другими.

Что сделать на этой неделе

Определите, какая доля вашего трафика идёт через мобильные сети и нестабильные каналы. Если доля значимая — соберите простой стенд и прогоните свой профиль нагрузки на трёх протоколах. Посмотрите на p95 и p99, а не на среднее. Если выигрыша нет — не включайте. Если есть — включайте с возможностью отката.

И перестаньте верить графикам без подписанных условий замера. Ваш случай всё равно окажется другим.