HTTP/2 и HTTP/3: что реально изменилось и что это значит для вашего сайта

Почему HTTP/1.1 должен был уйти

Современной странице нужны десятки ресурсов — HTML, CSS, скрипты, изображения, шрифты. HTTP/1.1 обрабатывал по одному запросу на соединение, поэтому браузеры открывали около шести параллельных соединений на хост, а остальное ставили в очередь. Каждое соединение платило собственным рукопожатием TCP и TLS, а один медленный ответ задерживал всё, что стояло за ним в очереди на этом соединении. Ухищрения той эпохи — спрайты, доменный шардинг, инлайнинг — были трюками, чтобы протащить больше ресурсов через слишком узкие трубы.

Что исправил HTTP/2

HTTP/2 (2015) заменил эти трубы одной: единственное соединение, несущее множество параллельных потоков. Любое число запросов и ответов перемежается без очередей друг за другом на уровне HTTP; заголовки сжимаются вместо повторения целиком в каждом запросе; цена рукопожатия платится один раз.

Для реальных сайтов это и был большой скачок — жонглирование шестью соединениями исчезло, а страницы с множеством мелких ресурсов стали радикально быстрее. Именно этот протокол сегодня отдаёт большая часть веба и большинство CDN. Одна честная сноска: HTTP/2 не устранил проблему блокировки очереди, а сдвинул её на уровень ниже. Все эти параллельные потоки по-прежнему едут по одному TCP-соединению, а TCP настаивает на доставке байтов по порядку — поэтому один потерянный пакет ставит на паузу *все* потоки до его повторной передачи. В чистых сетях это редкость; на слабом мобильном сигнале — налог, который вы платите.

Что HTTP/3 меняет под капотом

HTTP/3 (2022) атакует этот оставшийся налог, заменяя TCP на QUIC — транспорт поверх UDP со встроенным TLS 1.3. Реально меняются три вещи. Рукопожатия дешевеют: транспорт и шифрование согласуются вместе, поэтому новое соединение стоит один круговой обход вместо двух-трёх, а повторное подключение к известному серверу может стоить ноль. Потеря пакетов перестаёт быть заразной: QUIC отслеживает потоки независимо, поэтому потерянный пакет останавливает только тот поток, которому принадлежал, а не всё остальное в полёте. И соединения переживают смену сети: переход с Wi-Fi на мобильные данные мигрирует соединение, а не убивает его.

Обратите внимание на закономерность — каждый из этих выигрышей про несовершенные сети. Именно там HTTP/3 и блистает: каналы с высокой задержкой, Wi-Fi с потерями, мобильные пользователи в движении, большие расстояния до сервера.

Честная оценка: сколько стоит каждый шаг

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

Тем временем то, что доминирует во времени загрузки, не сдвинулось: насколько контент близко (edge-кеширование), насколько он тяжёл (изображения, сжатие) и какая его часть блокирует рендеринг. Закешированная, сжатая Brotli, с оптимизированными изображениями страница по HTTP/2 всегда обгонит неоптимизированную страницу по HTTP/3 — протоколы решают миллисекунды, доставка решает секунды. Наш edge сегодня отдаёт HTTP/2 — именно там живёт решающий протокольный выигрыш; рычаги доставки поверх него — вот куда уходит остальной бюджет вашей скорости.

Проверьте, на чём реально говорит ваш сайт

Гадать не нужно. В браузере откройте DevTools → Network, включите колонку Protocol и прочитайте: h2 — это HTTP/2, h3 — HTTP/3. Из терминала curl отвечает одной строкой. Заодно посмотрите в заголовках ответа статус кеша — апгрейд протокола на некешированном круговом обходе до origin это полировка не того слоя.

Проверить согласованный протокол через curl

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

Разумный порядок действий

Относитесь к протоколу как к одному рычагу на панели, а не ко всей панели. Сначала возьмите решающие выигрыши: отдавайте через edge-кеш, чтобы контент был близко, сжимайте текст Brotli, переводите изображения в WebP/AVIF в честных размерах — это сдвигает секунды, и выигрывает каждый посетитель. Мультиплексирование HTTP/2 — это базовая ставка, и оно уже несёт ваши запросы параллельно. Затем, если полевые данные показывают, что вы страдаете именно на мобильных хвостовых задержках, протокольные усовершенствования заслуживают внимания — измеренные на ваших собственных цифрах, а не на бенчмарке вендора.

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