HTTP/2 против HTTP/3 Что действительно изменилось (и важно ли это для вашего API)

Краткий ответ: если вы находитесь за CDN, то HTTP/3, вероятно, уже настроен для вас и ничего не нужно настраивать. Если вы запускаете свой собственный сервер, то HTTP/2 охватывает 95% случай, а HTTP/3 — это оправданное, но несрочное обновление.

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

Что HTTP/2 на самом деле исправило

HTTP/1.1 имел две проблемы, которые были решены правильно в HTTP/2.

Слишком много TCP-соединений для загрузки одной страницы. Браузеры открывали 6–8 TCP-соединений на источник только для параллельной загрузки ресурсов. Каждое соединение имеет расходы на настройку (TCP-рукопожатие, переговоры по TLS), и такой подход был неэффективным на больших масштабах. HTTP/2 заменил это на мультиплексирование: одно TCP-соединение, несколько потоков запросов и ответов, работающих параллельно. Больше не нужно переключаться между соединениями.

Повторяющиеся заголовки на каждом запросе. В HTTP/1.1 каждый запрос отправлял полный набор заголовков — User-Agent, Accept-Encoding, Authorizationвсе это — даже если ничего не изменилось по сравнению с предыдущим запросом. В HTTP/2 сжатие HPACK устраняет дублирование заголовков, поддерживая общий справочник между клиентом и сервером. На API, где вы отправляете одинаковый Authorization: Bearer ... токен на каждый вызов, это значительно снижает расходы при высокой нагрузке.

Серверный прорыв (server push) должен был быть третьим успехом (предварительная отправка ресурсов, которые клиенту нужны, до того как он их запросил), но в реальности он не работал. Chrome отказался от поддержки в 2022 году. Рассматривайте его как устаревший и не создавайте ничего вокруг него.

Проблема, которую HTTP/2 не смог решить

Вот часть, которая часто пропускается: мультиплексирование на TCP имеет жесткий предел. Когда TCP-пакет теряется в пути, TCP останавливает всю связь, пока пакет не будет пересылаться и подтверждён. Все ваши параллельные потоки HTTP/2 — независимо от того, к какому потоку относится потерянный пакет — остаются бездействующими. Это проблема TCP-уровня «заголовок впереди» (HOL), и это не баг в HTTP/2 — это то, как работает TCP.

На надежной проводной сети вероятность потери пакетов достаточно низка, чтобы это редко мешало. Но на мобильных сетях, спутниковых связях или любом пути с существенной потерей пакетов, преимущество мультиплексирования HTTP/2 исчезает. Вы можете иметь 20 потоков, мультиплексированных на одно соединение, и потерянный пакет останавливает все 20. 😬

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

Что на самом деле изменилось в HTTP/3

HTTP/3 не просто изменяет формат рамок или добавляет новый флаг. Он заменяет TCP на QUIC — транспортный протокол, работающий над UDP.

QUIC обрабатывает мультиплексирование на уровне транспорта, поэтому потеря пакета блокирует только поток, к которому он относится, а не все остальные потоки на соединении. Проблема «заголовок впереди» решается на правильном уровне стека. Это основа всего.

Несколько других вещей, которые приносит QUIC:

• Миграция соединений. QUIC идентифицирует соединения по идентификатору соединения, а не по 4-кортежу из исходного IP, исходного порта, назначаемого IP и назначаемого порта. При переключении с Wi-Fi на сеть мобильного телефона во время передачи соединение сохраняется. Это важно для мобильных приложений; для серверных вызовов API это в основном не имеет значения.
• 0-RTT-рукопожатия. Для соединений с известными серверами QUIC может пропустить ручной переговор по TLS и сразу отправить данные. Реальное снижение задержки при повторном подключении. Примечание: 0-RTT имеет ограничение по повторному использованию — не используйте его для неидемпотентных конечных точек без понимания компромиссов.
• Обязательное использование TLS 1.3. QUIC не поддерживает нешифрованные соединения. Без TLS нет HTTP/3, полностью.

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

Сравнение функций

Особенность	HTTP/1.1	HTTP/2	HTTP/3
Протокол транспорта	TCP	TCP	QUIC (UDP)
Мультиплексирование запросов	Нет (множество соединений)	Да	Да
Блокировка на уровне заголовка	На уровне запроса	На уровне TCP (присутствует)	Никто
Сжатие заголовков	Никто	HPACK	QPACK
Требуется TLS	Нет	Нет (в спецификации), да (в браузерах)	Да (обязательно)
0-RTT-рукопожатие	Нет	Нет	Да
Миграция соединений	Нет	Нет	Да
Серверный прорыв	Нет	Да (устаревший)	Нет (удалено)

Что это означает для задержки API

HTTP/3 помогает в определённых условиях. Он не улучшает всё универсально.

Потерянные сети. Мобильные клиенты, обращающиеся к вашему API через нестабильные LTE или 5G с неоптимальным покрытием, увидят измеримое улучшение. Вызовы между данными-центрами на надежной частной сети, где потери пакетов практически отсутствуют, — разница будет незначительной.

Холодные соединения и повторные подключения. Если ваши клиенты API часто переподключаются — кратковременные функции на сервере, перезапуск мобильных приложений, временные контейнеры — 0-RTT снижает стоимость настройки. Долгосрочные соединения, которые остаются открытыми на несколько минут, не получают выгоды от этого.

Объём запросов имеет значение. HTTP/2 и HTTP/3 отлично справляются, когда клиент делает много параллельных запросов. Браузер, загружающий 80 ресурсов параллельно, получает значительные выгоды от мультиплексирования. REST API, отправляющий 3 последовательных запроса, получает гораздо меньшую выгоду. Чем больше параллельных запросов делает ваш клиент, тем больше важны улучшения транспорта.

Как CDNs обрабатывают это

Cloudflare поддерживает HTTP/3 с 2019 года и включает его по умолчанию. AWS CloudFront добавил поддержку в 2022 году. Fastly, Akamai, BunnyCDN — все поддерживают его.

Важна архитектура: ваш CDN заканчивает клиентское соединение на его краю. Даже если клиент подключается к вашему CDN по HTTP/3 с использованием QUIC, часть CDN-к_ORIGIN, скорее всего, будет HTTP/1.1 или HTTP/2 над TCP. Поэтому включение HTTP/3 на вашем CDN не требует изменений на вашем исходном сервере.

Если вы на Cloudflare, проверьте настройки Speed → Optimization — HTTP/3 (с QUIC) включён по умолчанию для большинства зон. Другие CDN могут отличаться. Это самое высокое влияние, которое может сделать большинство команд: без изменений на исходном сервере, немедленная польза для клиентов на мобильных устройствах или на высокой задержке.

Нужно ли вам что-то делать?

За CDN: Проверьте, включено ли HTTP/3, и перейдите к следующему шагу. Это занимает 30 секунд.

Запускаете свой собственный nginx: HTTP/3 требует nginx 1.25+ (основная ветвь — стабильная ветвь отстаёт по QUIC). Вам нужно будет использовать --with-http_v3_module флаг компиляции и директиву вместе с вашим существующим слушателем TCP. Убедитесь, что порт UDP 443 открыт на вашем фаерволе — в некоторых сетевых настройках он блокируется. Значимо, если вы обслуживаете пользователей на мобильных устройствах; не стоит делать обновление, если вы только обрабатываете сервер-к-серверные вызовы. listen 443 quic reuseport Используете Caddy:

HTTP/3 включён по умолчанию без настройки. Нечего делать. Разработка клиента, обращающегося к третьим сторонам:

То, получаете ли вы HTTP/3, зависит от сервера, к которому обращаетесь, а не от вашего кода. curl поддерживает HTTP/3 начиная с версии 7.86.0 с совместимым backend (nghttp3 или quiche). Большинство клиентских библиотек на Python и Node пока не поддерживают HTTP/3 по умолчанию. В Go стандартная библиотека не поддерживает его; существует отдельная net/http библиотека, если вам нужно. quic-go Одна практическая заметка: если вы проверяете, какая версия HTTP сервер действительно договаривается, или создаете команды curl с

флагами, --http3 на iotools.cloud полезно для построения правильной команды без поиска точной синтаксиса флага каждый раз. Конструктор cURL команд HTTP/2 против HTTP/3: Что на самом деле изменилось (и важно ли это для вашего API) 2

Вам также может понравиться