Внедрение HTTP-3 задерживается

Сетевой протокол HTTP/3 ^[1] в разработке с 2016 года, а его транспорт QUIC вышел в 2013-м. На сегодняшний день оба эти стандарта поддерживаются всеми ведущими браузерами ^[2] (кроме Samsung и Opera Mini) и составляют 32,5% HTTP-запросов на Cloudflare ^[3], что отражает актуальное состояние всего интернета. Но темпы внедрения HTTP/3 крайне медленные ^[4].

Что же мешает веб-мастерам перейти на современный стандарт и ускорить загрузку сайтов ^[5]? Основная причина в том, что ни QUIC, ни HTTP/3 до сих пор не включены в стандартные библиотеки популярных языков программирования Go, Rust, Python и Ruby. Они не активированы по умолчанию в Node.js, веб-серверах Nginx и Apache. Прошло более десяти лет, но протокол всё ещё считается экспериментальным! Удивительно.

Бенчмарки HTTP/3

HTTP/3 кардинально улучшает производительность сайтов в реальных условиях, особенно для мобильных пользователей и под большой нагрузкой. В бенчмарках ^[5] можно посмотреть, как переход с HTTP/2 на HTTP/3 влияет на скорость загрузки и количество сбоев.

На графиках ниже один и тот же браузер использовался для запроса трёх сайтов ^[6] через одну и ту же сеть, изменялась только версия HTTP. Каждый сайт загружался 20 раз, время отклика измерялось через API. В тестовой установке было три сайта (перечислены ниже).

Маленький сайт

• 10 JS-файлов от 2 до 100 КБ

• 10 картинок от 1 до 50 КБ

• 600 КБ в сумме, 20 блокирующих ресурсов

Контент-сайт

• 50 JS-файлов от 2 КБ до 1 МБ

• 55 картинок от 1 КБ до 1 МБ

• в сумме 10 МБ, 105 ресурсов

SPA

• 85 JS-файлов от 2 КБ до 1 МБ

• 30 картинок от 1 до 50 КБ

• в сумме 15 МБ, 115 ресурсов

Контент раздаётся веб-сервером Caddy ^[7], все ответы отправлялись с заголовком 'Cache-Control: "no-store" для отключения кэширования. Для HTTP/1.1 и HTTP/2 использовался TLS 1.2, для HTTP/3 — TLS 1.3 и 0-RTT ^[8].

На графиках ясно видно улучшение производительности с каждой новой версией HTTP при размещении сервера в дата-центрах Нью-Йорка, Лондона и Бангалора (Индия). Во всех случаях клиент находится в Миннесоте.

При загрузке с близкого сервера (1600 км между MN и NY) время загрузки уменьшается примерно на 40% для всех сайтов.

В случае Лондона ускорение гораздо заметнее: время загрузки при загрузке контента по HTTP/3 примерно в 2−2,5 раза меньше, чем по HTTP/2. Результаты HTTP/1.1 можно вообще не рассматривать — тот стандарт предусматривал последовательную передачу файлов с сервера клиенту по TCP, и любая задержка в одном файле блокирует все остальные.

Контент из Бангалора доставляется примерно в 2,5−3 раза быстрее по HTTP/3. Например, для маленького сайта задержка уменьшается с 2,4 до 1 секунды.

Основные преимущества HTTP/3

• Значительно увеличенная устойчивость к ненадёжным сетям. В новом протоколе отказались от строгого порядка пакетов в TCP, так что каждый поток полностью независим, а потерянный пакет в одном потоке не замедляет другой.

• Инициализация соединения с 0-RTT ^[8], который позволяет клиенту отправлять зашифрованные данные серверу в первом же пакете, устраняя задержку на установку соединения. В QUIC не нужно ждать рукопожатия TLS. То есть можно подключиться к серверу и сразу отправить HTTP-запрос, не дожидаясь ни одного пакета в ответ. Это и значит «нулевое время кругового обхода», то есть 0-RTT.

• Сокращение трафика, количества подключений и RTT. Всё это уменьшает энергопотребление на клиентах и серверах, ускоряет обработку запросов и увеличивает производительность серверов (например, на максимальное количество подключённых пользователей).

• Миграция соединений ^[9] позволяет клиенту сохранить соединение даже при смене IP-адреса и, теоретически, даже с нескольких IP-адресов (например, одновременно по Wi-Fi и сотовой связи для дополнительной скорости и надёжности).

• Улучшенное управление сетевыми заторами по уникальной технологии BBR ^[10] (Bottleneck Bandwidth and RTT), улучшенное восстановление после потери пакетов, коррекции будущих ошибок ^[11] (Forward Erasure Correction, FEC).

• Поддержка WebTransport ^[12] для двунаправленных полудуплексных соединений. Протокол устраняет многие ограничения WebSockets (как несовместимость с CORS) и обеспечивает более низкую задержку в потоковых соединениях.

Поддержка веб-сайтами

С 2022 года поддержка HTTP/3 выросла с 18% до 32%, но в последние месяцы по графикам рост не особенно заметен.

Хотя HTTP/3 десять лет в разработке, он до сих пор в стадии предложенного стандарта ^[13] (RFC 9114) и существует множество его реализаций.

Одна из причин медленного внедрения — кардинальная смена транспортного протокола, переход с TCP на QUIC. По этой причине браузер на практике будет использовать HTTP/3 только в том случае, если на 100% уверен, что сервер его поддержит. Иначе возникнет задержка на несколько секунд, чтобы откатиться на HTTP/2 и установить новое TCP-соединение, а это длительный процесс.

Как браузер может быть на 100% уверен? Только если сервер явно сообщит браузеру, что поддерживает HTTP/3 через заголовок HTTP Alt-Svc или через запись DNS HTTPS.

Даже если сервер поддерживает HTTP/3, но не сообщит браузеру об этом, тот просто не инициирует соединение HTTP/3, даже не попробует его использовать, потому что это слишком дорого стоит! Вот ещё одна причина замедления в принятии HTTP/3.

Запись DNS HTTPS — самый оптимальный способ объявления о поддержке HTTP/3, но он относительно новый — и не все веб-мастеры знают о нём.

По статистике Web Almanac ^[14], новый протокол поддерживали всего 28% сайтов в 2024 году.

Правда, эта статистика не совсем достоверна, потому что при использовании механизма Alt-Svc соединение по HTTP/3 обычно используется только со второй страницы сайта, а первая идёт по HTTP/2 или HTTP/1.1, даже если сервер поддерживает HTTP/3. И в этом заключается суть проблемы, так как Web Almanac измеряет только первую загрузку страницы.

Интересно, что мобильные главные страницы немного лучше поддерживают HTTP/3, чем страницы для десктопных браузеров. Это можно объяснить тем, что HTTP/3 в основном даёт преимущества в мобильных сетях.

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

Кроме того, многие популярные веб-серверы до сих пор не включили HTTP/3 «из коробки».

• В Nginx поддержка HTTP/3 добавлена в версии 1.25.0, но выключена по умолчанию. Чтобы активировать его, администратор должен вручную прописать в конфигурации директивы listen 443 quic и http3 on, см. инструкцию ^[15] и модуль ngx_http_v3_module ^[16].

• В Node.js функция находится в экспериментальном статусе.

• В Apache полноценная поддержка отсутствует, протокол признан экспериментальным.

Для включения HTTP/3 на Windows Server 2022 тоже требуются довольно эзотерические шаги ^[17], начиная с добавления двух ключей в реестр. Один для HTTP/3:

reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters" /v EnableHttp3 /t REG_DWORD /d 1 /f

Другой ключ для заголовков Alt-Svc:

reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters" /v EnableAltSvc /t REG_DWORD /d 1 /f

Под Windows Server работают миллионы сайтов ^[18]. Возможно, это один из факторов, которые замедляют всеобщий переход на HTTP/3.

В то же время некоторые крупные IT-компании полностью переходят на HTTP/3. Например, CDN Facebook (принадлежат Meta, чья деятельность признана экстремистской и запрещена в России) показывает HTTP/3 в 99,86% ответов, а CDN Automattic — 99,92%.

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

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

В целом, внедрение HTTP/3 идёт очень медленно ^[4]. Оказалось, что замена TCP на UDP (QUIC) требует значительной переделки стандартных библиотек, а продвинутые функции HTTP/3 оказались слишком сложными в реализации на клиентском уровне. Сложно найти хотя бы один популярный проект Open Source, который полностью поддерживает HTTP/3. Это просто поразительно, учитывая эффективность и все выгоды от внедрения новой технологии.

Похоже, большинство компаний решили, что проще поддерживать на уровне CDN, а не в своих приложениях. В итоге интернет разделился на две части: 1) технологические лидеры; 2) длинный хвост (две трети интернета).

1. Основные браузеры, крупные CDN (Cloudflare, Akamai, Fastly, CloudFront), облачная инфраструктура Google, Meta (признана экстремистской и запрещена в России), Amazon, Microsoft и отдельные мобильные приложения.

2. Все остальные: API-клиенты и серверы, мобильные приложения, маленькие CDN, большинство веб-сайтов, десктопные приложения, IoT, боты, приложения на самохостинге, консольные программы и скрипты и многое другое, что не поддерживает HTTP/3. Отсутствие поддержки HTTP/3 уже стало маркером небраузерных клиентов и ботов ^[19].

Пока ситуация такова, что преимуществами быстрого интернета пользуются лишь крупные IT-корпорации, а бóльшая часть населения фактически не имеет доступа к новой технологии, кроме как путём подписки на услуги CDN компаний из «продвинутой» части интернета.

Остальным же приходится работать на старом стеке без 0RTT, WebTransport и др. А ведь в будущем ожидается ещё больше технологий на базе HTTP/3 (как gRPC на HTTP/2). Очень печально, если эти преимущества будут доступны лишь небольшому числу организаций и их клиентам.

© 2026 ООО «МТ ФИНАНС»