Если вы запускаете curl -I https://www.google.com и видите alt-svc: h3=":443" — поздравляю, Google уже отдаёт вам HTTP/3. Большинство современных сайтов его поддерживают, браузеры умеют с ним работать, а вот разработчики по-прежнему часто не понимают, что конкретно изменилось и надо ли вообще что-то делать.
Разберём по-человечески.
Чем плох был TCP
HTTP/1.1, HTTP/2 — оба работают поверх TCP. На первый взгляд это звучит нормально: TCP надёжный, проверенный, везде поддерживается. Но у него есть структурная проблема — head-of-line blocking, или блокировка очереди.
Вот как это работает. TCP гарантирует, что пакеты придут в правильном порядке. Если один пакет потерялся — всё стоит и ждёт его повторной доставки. Даже если следующие десять пакетов уже пришли и лежат в буфере.
HTTP/2 решил часть проблемы: он добавил мультиплексирование — несколько запросов в одном TCP-соединении одновременно. Но блокировку очереди убрать не смог. Один потерянный пакет блокирует все параллельные потоки разом, потому что они все идут через одно TCP-соединение.
На хорошем проводном интернете потеря пакетов — редкость. Но на мобильных сетях, в метро, в аэропорту — это происходит постоянно. И именно там пользователи ждут дольше всего.
Что такое QUIC и почему он на UDP
QUIC — это транспортный протокол, разработанный в Google, а потом стандартизированный IETF. HTTP/3 — это HTTP поверх QUIC. Вот и вся связь.
Главное архитектурное решение: QUIC работает поверх UDP, а не TCP. Это кажется странным — UDP же ненадёжный? Да, UDP не гарантирует доставку и порядок. Но QUIC реализует надёжность сам, на своём уровне. И делает это умнее, чем TCP.
Конкретно:
- Каждый поток независим. Если один пакет потерялся, ждёт только тот поток, которому он принадлежит. Остальные продолжают работать. Это решает head-of-line blocking на уровне транспорта.
- TLS 1.3 встроен. В TCP вы сначала устанавливаете соединение (TCP handshake), потом договариваетесь о шифровании (TLS handshake). В QUIC всё происходит вместе, за один round-trip.
- 0-RTT для повторных подключений. Если клиент уже соединялся с сервером, при следующем подключении он может отправить данные сразу, без ожидания подтверждения. Для пользователей это ощущается как мгновенный отклик.
- Connection migration. Соединение идентифицируется не по IP-адресу и порту, а по уникальному ID. Вы переключились с Wi-Fi на мобильный интернет? Соединение не рвётся — оно просто мигрирует. Для веба это особенно важно: страница не перезагружается, загрузка не прерывается.
Цифры и реальность
Google публиковал результаты внутренних экспериментов с QUIC: на медленных или нестабильных соединениях время загрузки видео в YouTube сократилось на 15–18%, а количество «буферингов» (когда видео встаёт на паузу) — на 30%.
Akamai в своих тестах фиксировала улучшение Time to First Byte (TTFB) на 12–20% на мобильных сетях по сравнению с HTTP/2.
На десктопном Wi-Fi с хорошим сигналом разница может быть почти незаметна — 50–100 мс. Но чем хуже канал, тем ярче выигрыш QUIC.
Ещё одна цифра: по данным W3Techs на начало 2026 года, HTTP/3 поддерживает около 32% сайтов в интернете. Это уже не эксперимент — это реальность.
Что поддерживают браузеры
Все современные браузеры поддерживают HTTP/3:
- Chrome — с версии 87 (2020 год)
- Firefox — с версии 88 (2021 год)
- Safari — с версии 14 (2020 год)
- Edge — с версии 87
То есть если ваш сервер поддерживает HTTP/3 — пользователи уже получают его. Без обновлений, без плагинов, без настроек.
Браузер договаривается с сервером через заголовок alt-svc. Первый запрос обычно идёт по HTTP/2, сервер отвечает: «у меня есть HTTP/3 на порту 443», и следующие запросы уже идут через QUIC. На практике для пользователя это незаметно.
Как включить HTTP/3 на сервере
Nginx
HTTP/3 появился в Nginx 1.25.0 как модуль. Конфигурация выглядит примерно так:
server {
listen 443 ssl;
listen 443 quic reuseport;
ssl_certificate /etc/ssl/certs/example.crt;
ssl_certificate_key /etc/ssl/private/example.key;
ssl_protocols TLSv1.3;
add_header Alt-Svc 'h3=":443"; ma=86400';
# остальная конфигурация
}
Важные моменты:
listen 443 quic — это UDP, не TCPssl_protocols TLSv1.3 — QUIC требует TLS 1.3- Заголовок
Alt-Svc — без него браузер не узнает, что HTTP/3 доступен
Проверить, что всё работает, можно через curl --http3 https://yoursite.com -I или через онлайн-инструмент HTTP/3 Check.
Caddy
Если вы используете Caddy — HTTP/3 включён по умолчанию с версии 2.0. Буквально ничего делать не надо. Это одна из причин, по которой Caddy набирает популярность среди небольших проектов.
Apache
Поддержка через модуль mod_http3, экспериментальная. Для продакшена лучше пока не использовать.
Облачные провайдеры
Cloudflare включил HTTP/3 для всех пользователей ещё в 2020 году. Если ваш сайт за Cloudflare — вы уже раздаёте HTTP/3, даже если не знали об этом. AWS CloudFront, Google Cloud CDN, Fastly — аналогично.
Что нужно проверить в вашей инфраструктуре
Файрвол и UDP. Это частая проблема. TCP 443 обычно открыт, а UDP 443 — нет. QUIC работает на UDP, поэтому если порт закрыт, браузер молча откатится на HTTP/2. Проверьте правила iptables или security groups.
Балансировщик нагрузки. Не все балансировщики умеют проксировать UDP. HAProxy поддерживает QUIC с версии 2.6, но конфигурация нетривиальная. Если вы используете L4-балансировку, нужно явно настраивать UDP passthrough.
Логи. Убедитесь, что ваши логи умеют писать протокол запроса. В Nginx это переменная $server_protocol. Если видите HTTP/3.0 — всё работает.
Сертификат. Нужен современный сертификат с поддержкой TLS 1.3. Let's Encrypt подходит отлично.
Что это меняет в коде приложения
Для большинства разработчиков — почти ничего. HTTP/3 прозрачен для прикладного уровня. Ваши REST API, GraphQL, WebSocket (точнее, его аналог WebTransport) работают так же.
Но есть нюансы:
Connection pooling. В HTTP/1.1 держать пул соединений было важно — открытие нового стоило дорого. В HTTP/3 с 0-RTT стоимость нового соединения сильно снизилась. Это не значит, что пулинг стал бесполезным, но агрессивная оптимизация под HTTP/1.1 может быть уже избыточной.
Server Push. В HTTP/2 был Server Push — сервер мог превентивно отправить ресурсы, которые ещё не запросил клиент. HTTP/3 его поддерживает, но Chrome ещё в 2022 году отключил Server Push по умолчанию из-за сложности правильного использования. Если вы на него рассчитывали — пересмотрите подход в сторону preload hints.
WebTransport. Это новый API поверх HTTP/3, который позволяет двунаправленную передачу данных с низкой задержкой. Альтернатива WebSocket с лучшей производительностью на нестабильных каналах. Пока поддержка ограничена Chrome и Edge, но API стабилизируется.
Мониторинг и метрики
Если вы запустили HTTP/3 — проверьте, что он реально используется. Смотрите на долю запросов с HTTP/3.0 в логах. Если она меньше 5% при современной аудитории — скорее всего, что-то заблокировано.
Инструменты для проверки:
curl --http3-prior-knowledge https://yoursite.com — принудительно HTTP/3- Chrome DevTools → Network → Protocol — показывает протокол каждого запроса
https://http3check.net — онлайн-проверка
По метрикам стоит отслеживать TTFB отдельно для HTTP/2 и HTTP/3 пользователей — разница даст понять, насколько вы выигрываете на своей аудитории.
Стоит ли внедрять прямо сейчас
Если вы на Cloudflare или другом современном CDN — HTTP/3 уже работает. Делать ничего не нужно.
Если у вас свой VPS с Nginx — обновитесь до 1.25+ и добавьте listen 443 quic. Займёт полчаса, риски минимальны: если что-то пойдёт не так, браузер просто упадёт на HTTP/2.
Если у вас высоконагруженный сервис с балансировкой — тут внимательнее: нужно проверить поддержку UDP в вашем стеке и протестировать под нагрузкой.
Мы в REEXY при разработке корпоративных сайтов и интернет-магазинов сразу закладываем поддержку HTTP/3 в серверную конфигурацию — это не требует дополнительных затрат, зато клиенты получают лучшее время загрузки без каких-либо изменений в дальнейшем.
Что будет дальше
HTTP/3 — это не финальная точка. QUIC активно развивается: обсуждаются расширения для multipath (несколько сетевых путей одновременно), улучшения для IoT-сценариев, оптимизации для спутникового интернета с высокими задержками.
WebTransport может вытеснить WebSocket в тех случаях, где важна низкая задержка — игры, видеоконференции, real-time коллаборация.
Пока всё это в процессе стандартизации. Но базовую поддержку HTTP/3 стоит включить уже сейчас — тем более что это действительно просто.