HTTP/3 простыми словами: становятся ли сайты реально быстрее

В сетевом слое за последние пять лет произошло больше изменений, чем за предыдущие двадцать. Главное из них — HTTP/3, новый базовый протокол веба. Если HTTPS — это про защиту, то HTTP/3 — про скорость и стабильность. Главное отличие не в синтаксисе запросов: GET / остался GET /. Изменился транспорт под ним.

Для пользователя это звучит технически, но проявляется очень предметно: некоторые сайты быстрее открываются после потерь пакетов, лучше переживают переход из Wi-Fi в LTE и реже «залипают» на одной картинке, тормозящей всю страницу.

Где HTTP/3 помогает заметно (улучшение в %):

Мобильный интернет в метро       ████████████████  +30..50%
Дальний сервер (RTT 200+ мс)     ████████          +15..25%
Wi-Fi в кафе с потерями          ███████████       +25..40%
Сайт с десятками ресурсов        █████             +5..15%
Домашний оптик, RTT 5 мс         ▏                 +0..2%
Тяжёлый JavaScript-сайт          ▏                 ~0%

HTTP/1.1, HTTP/2, HTTP/3 — что в чём разница

Три поколения протокола живут параллельно прямо сейчас:

• HTTP/1.1 (1997). Один запрос — один ответ, всё в открытом тексте. Браузер открывает 6 параллельных соединений к одному домену, чтобы загружать страницу быстрее. На современном вебе с десятками доменов это уже не справляется.
• HTTP/2 (2015). Бинарный протокол с мультиплексированием: одно соединение, много параллельных потоков. Заголовки сжимаются HPACK. Работает поверх TCP+TLS. Главная боль — head-of-line blocking на уровне TCP: один потерянный пакет блокирует все потоки.
• HTTP/3 (2022). Те же фреймы, что в /2, но поверх QUIC и UDP. Каждый поток независим от других. Соединение не привязано к IP, поэтому переживает смену сети.

Между /2 и /3 заметная пропасть. Между /1.1 и /2 — ещё больше. Современные сайты обычно общаются с CDN по /2 или /3, а с устаревшими бэкендами — по /1.1.

Где разница реально видна

HTTP/3 ощущается там, где плохо работает TCP. Конкретные сценарии:

• Метро, поезд, машина. Сигнал прыгает, IP может меняться. На HTTP/2 это означает рестарт соединений — спиннер на 1–2 секунды на каждом ресурсе. На HTTP/3 connection migration вытягивает страницу почти без задержки.
• Wi-Fi в кафе с потерями. Один пакет потерян — на TCP вся очередь стоит до retransmit. На QUIC лежит только тот поток, к которому пакет относился. Видео продолжает крутиться, а страница продолжает грузиться.
• Сайт за океаном. 1-RTT handshake вместо 3-RTT (TCP + TLS) — это 400 мс быстрее на маршруте Москва ↔ Сан-Франциско. Если у вас 0-RTT (повторное подключение) — ещё быстрее.
• Стриминг-видео и звонки. Discord, Zoom, YouTube включают QUIC и получают -10..20% rebuffering на мобильных.

Где HTTP/3 ничего не меняет

Маркетинг любит обещать ускорение всегда. На практике есть классы сценариев, где HTTP/3 не помогает:

• Стабильный домашний оптик. RTT 5 мс, потерь нет. На таких условиях HTTP/2 и /3 почти неотличимы.
• Сайты, упирающиеся в JavaScript. Если страница рендерится 3 секунды из-за тяжёлого фреймворка, ускорение сети на 100 мс не заметит никто.
• API с одним коротким запросом. Время handshake одинаково важно, но если запрос всего один и без повторов, разница минимальна.
• Статика с короткими TTL. Если CDN рядом и кэш холодный — узкое место в самом CDN, не в транспорте.

Как браузер вообще узнаёт, что есть HTTP/3

Хорошая новость: пользователю ничего настраивать не нужно. Browser сам находит лучшую версию. Есть два механизма:

• Alt-Svc заголовок. Сервер при первом ответе по HTTP/2 присылает заголовок alt-svc: h3=":443"; ma=86400. Это значит «у меня есть HTTP/3 на порту 443, можешь использовать сутки». Следующий запрос пойдёт по HTTP/3.
• HTTPS DNS-запись (RFC 9460). Современный способ: рядом с обычной A-записью домена в DNS лежит запись типа HTTPS со списком ALPN, IP-подсказками и (опционально) ECH-ключом. Браузер видит её при первом DNS-запросе и сразу идёт по нужному протоколу. Это убирает один RTT по сравнению с Alt-Svc.

Как проверить вручную

Самый простой способ — открыть DevTools в любом браузере (F12 в Chrome/Firefox/Edge), вкладка Network, по правому клику на заголовках столбцов включить колонку Protocol. Там будут значения:

• h3 — HTTP/3 поверх QUIC.
• h2 — HTTP/2 поверх TCP+TLS.
• http/1.1 — старый HTTP/1.1, ещё встречается.

Из командной строки: curl -I --http3 https://www.cloudflare.com — если curl собран с поддержкой ngtcp2, увидите ответ. Из Chrome: chrome://net-internals/#quic покажет активные QUIC-сессии в реальном времени.

Когда HTTP/3 не работает и что происходит

Сценарий, когда UDP/443 заблокирован:

• Корпоративные файрволлы старого поколения иногда режут UDP по умолчанию.
• Часть отельных и аэропортовых Wi-Fi сетей блокирует UDP, кроме DNS.
• Некоторые мобильные тарифы зачем-то режут UDP/443.
• На старых домашних роутерах NAT забывает UDP-сессии слишком быстро.

Во всех этих случаях браузер пробует HTTP/3, не получает ответа за разумный таймаут (~3 секунды) и автоматически переключается на HTTP/2. Пользователь обычно не замечает, кроме возможного небольшого замедления на первом подключении. После одного fallback браузер запоминает домен как «HTTP/2 only» на сессию и не пробует HTTP/3 повторно.

Почему мобильные сети любят HTTP/3 особенно сильно

Мобильная сеть — это длинная цепочка: радиоканал, базовая станция, ядро оператора (PGW/UPF), peering, дальний сервер. Где-то в этой цепочке всегда что-то плохое: то RAN перегружен, то ядро шейпит, то peering вечером перегружен. Connection migration QUIC и независимость потоков сглаживают именно эти неровности — поэтому Cloudflare, Google и Meta видят на мобильных самый большой эффект от HTTP/3.

Подробнее устройство мобильного транспорта — в статье про скачки скорости мобильного интернета.

Итого

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