HTTP/3 часто воспринимают как «включил в CDN — и стало быстрее». На практике миграция на HTTP/3 — это набор мелких решений: как клиент узнаёт про поддержку HTTP/3, как выбирается протокол (TLS 1.3 и ALPN), что происходит на уровне CDN/edge и как измерять эффект не «на глаз», а по метрикам (TTFB, RTT, p95/p99).
Ниже — рабочий план для админов и вебмастеров, которые ведут PHP‑сайт (WordPress, Laravel, Symfony или самописный) и хотят перейти на HTTP/3 контролируемо: с откатом, проверками и понятными критериями успеха.
Что такое HTTP/3 и почему он «про сеть», а не про PHP
HTTP/3 — это HTTP поверх QUIC. QUIC работает по UDP (вместо TCP) и шифруется на транспортном уровне: на практике это всегда TLS 1.3 (варианта «HTTP/3 без TLS» не существует). Для PHP‑приложения это важно не потому, что «PHP становится быстрее», а потому что меняется доставка запросов до фронтенда (CDN/балансировщик) и устойчивость к потерям пакетов.
Из-за чего QUIC часто даёт прирост:
Меньше задержек на установку соединения: в удачных сценариях снижается число RTT до первого полезного байта.
Меньше head-of-line blocking на уровне транспорта: потеря одного пакета не блокирует остальные потоки так, как это бывает при TCP.
Лучше в «плохих сетях» (мобильные сети, Wi‑Fi с потерями): чаще улучшаются «хвосты» (p95/p99), а не медиана.
Важно: если основная часть TTFB — это генерация страницы в PHP/БД, HTTP/3 не «вылечит» медленный бэкенд. Он уменьшает сетевую часть и делает её стабильнее. Поэтому в миграции держим в голове два слоя: транспорт (HTTP/3/QUIC) и приложение (PHP).
TLS 1.3 и ALPN: как клиент выбирает протокол
ALPN (Application-Layer Protocol Negotiation) — механизм, который позволяет в ходе TLS‑рукопожатия договориться, какой протокол использовать дальше. В вебе это обычно:
h2— HTTP/2http/1.1— HTTP/1.1h3— HTTP/3 (в QUIC‑соединении)
Практический нюанс: поддержка HTTP/3 «включается» не просто настройкой TLS на 443. Клиент должен понять, что сервер (или CDN) готов принимать QUIC. Для этого обычно используется механизм Alt-Svc.
Alt-Svc: как браузер узнаёт про HTTP/3
Alt-Svc (Alternative Services) — HTTP‑заголовок, которым сервер сообщает клиенту: «в следующий раз можешь прийти по другому протоколу/порту». Типовой сценарий:
первый заход клиента идёт по HTTP/2 или HTTP/1.1 на TCP/443;
в ответе edge добавляет
Alt-Svc: h3=":443"; ma=86400;последующие запросы клиент пробует отправить по HTTP/3 (QUIC/UDP/443), если сеть позволяет.
Ключевой вывод: «включить HTTP/3» — не одномоментный переключатель для всех клиентов. Это постепенное «обучение» через Alt-Svc, и часть пользователей всегда останется на HTTP/2 или HTTP/1.1 (совместимость, политики сети, блокировки UDP и т. п.).
В нормальной миграции HTTP/3 должен быть добавлением, а не заменой: HTTP/2 остаётся базовым рабочим протоколом, а HTTP/3 — ускоряющим путём для тех, кому он доступен.
CDN и HTTP/3: где реально происходит «включение»
Для большинства PHP‑сайтов HTTP/3 проще и безопаснее включать на уровне CDN/edge, а не на origin‑сервере. У CDN обычно уже есть зрелая QUIC‑терминация, быстрые обновления стеков, защита на периметре и наблюдаемость по протоколам. Origin при этом может продолжать жить на HTTP/1.1 или HTTP/2.
В этом месте чаще всего ломаются ожидания:
вы «перешли на HTTP/3», но на origin ничего не меняли — и это нормально: клиент общается по HTTP/3 с edge, а edge ходит до origin по своему протоколу;
TTFB может улучшиться на пути «к edge», но генерация ответа в PHP/БД остаётся прежней;
поведение CDN‑кеша (hit/miss, stale, revalidate) начинает влиять сильнее, чем выбор HTTP/2/HTTP/3.
Если вы планируете терминировать QUIC самостоятельно, заранее оцените сложность: поддержка HTTP/3 на балансировщиках/прокси и наблюдаемость могут быть нетривиальными. По теме терминации QUIC на прокси полезно почитать: как терминировать HTTP/3/QUIC на HAProxy и что проверить.
CDN cache и метрики: почему TTFB может «обмануть»
TTFB удобен, но он смешивает несколько составляющих: сеть, задержку на edge, путь до origin и время генерации ответа. После включения HTTP/3 вы можете увидеть:
Снижение TTFB на cache HIT: ответ отдаётся с edge, и сеть до edge стала стабильнее.
Почти нулевой эффект на cache MISS: если origin далеко, медленный или перегружен, вы упираетесь в него.
Рост разброса: если правила обхода кеша (cookies, авторизация, вариативность) заставляют чаще ходить на origin.
Для честного теста разделяйте минимум два сценария: статический объект, который гарантированно кешируется, и динамический PHP‑endpoint, который гарантированно не кешируется (или кешируется отдельно по вашей стратегии).
План миграции на HTTP/3: от диагностики до выката
Ниже — последовательность, которая обычно помогает не получить «стало хуже, но непонятно почему».
1) Проверьте сетевые и инфраструктурные предпосылки
UDP/443 должен быть доступен до edge или до вашего сервера (если терминируете QUIC сами).
TLS 1.3 должен быть включён (HTTP/3 практически всегда означает TLS 1.3).
Проверьте, что на вашей стороне нет правил/устройств, которые режут UDP или создают проблемы с MTU (фрагментация, дропы).
Если используете CDN — убедитесь, что HTTP/3 включается на стороне CDN, а не «где-то ниже» на origin, где это не увидит клиент.
2) Определите критерии успеха (и провала)
До изменений зафиксируйте baseline и решите, что именно измеряете:
TTFB: медиана и p95 отдельно для cache HIT и cache MISS.
RTT: по клиентским измерениям или косвенно через тайминги.
Доля трафика по HTTP/3: процент запросов, пришедших как
h3.Ошибки: рост 4xx/5xx, таймауты, ретраи, жалобы на «не открывается в корпоративной сети».
Если критерий только «ощущается быстрее», то результат будет спорным: HTTP/3 часто улучшает хвосты (p95/p99), а не медиану.
3) Включите HTTP/3 как дополнительный протокол
Безопасная стратегия: сначала включить HTTP/3 на небольшой доле (например, на поддомене со статикой) или на части трафика через настройки CDN. Смысл — убедиться, что:
корректно отдаётся
Alt-Svc;клиенты реально переходят на QUIC;
не ломаются WAF/anti-bot политики, завязанные на особенности TCP.
4) Проверьте заголовки и совместимость кеша
HTTP/3 не меняет HTTP‑семантику, но миграция часто совпадает с ревизией кеширования. На PHP‑сайтах типовые проблемы — не сам протокол, а то, что CDN‑кеш не срабатывает или кеш «взрывается» по вариантам.
Проверьте:
корректность
Cache-ControlиVary(особенноVary: Accept-EncodingиVary: Cookie);стабильные
ETag(или осознанный отказ от них на CDN);диагностические заголовки CDN (hit/miss), чтобы отличать эффект протокола от эффекта кеша.
Если параллельно оптимизируете статику и формат изображений, лучше разделять эксперименты: сначала протокол, затем статика (или наоборот), фиксируя метрики. По настройкам кеша под изображения и маппинг форматов может пригодиться материал: WebP/AVIF и кеширование через map в Nginx.
5) Наблюдаемость: логируйте протокол и делайте разрезы
Чтобы понимать реальный эффект, полезно иметь в логах/метриках:
протокол запроса (HTTP/1.1, h2, h3);
время до первого байта на edge (если CDN отдаёт метрики);
апстрим‑тайминги до origin (connect, header, response), если есть reverse proxy.
На стороне приложения (PHP) продолжайте измерять отдельно: время выполнения, запросы к БД, внешние API. Если после включения HTTP/3 медиана TTFB упала, но p95 вырос — это часто сигнал, что кеш стал чаще промахиваться или выросла нагрузка на origin из-за изменившегося поведения клиентов/правил кеша.
Практика тестирования: как сравнивать HTTP/2 и HTTP/3 честно
Чтобы сравнение было честным, нужно снизить «шум»:
Разделяйте прогрев кеша: первый прогон чаще всего не показателен.
Тестируйте из нескольких сетей: домашний интернет и мобильная сеть дают разный эффект QUIC.
Смотрите не только среднее: сравнивайте медиану, p95 (а иногда и p99) по TTFB.
Стабилизируйте приложение: на время тестов уберите фоновые задачи/деплои, которые меняют нагрузку.
Минимальный набор команд для проверки протокола
Даже без «тяжёлых» инструментов можно быстро понять, что edge объявляет поддержку HTTP/3 и что клиент её видит.
Проверка наличия Alt-Svc в ответе:
curl -I https://example.comИщите заголовок вида Alt-Svc: h3=":443"; ma=.... Если его нет — клиенту «не с чего» перейти на HTTP/3 (исключения существуют, но на них лучше не рассчитывать).
Проверка TLS 1.3 и ALPN на стороне TCP‑TLS (полезно для HTTP/2; для HTTP/3 это косвенно, так как QUIC не проходит через s_client):
openssl s_client -connect example.com:443 -alpn h2 -tls1_3В выводе смотрите, какой протокол согласован через ALPN.
Типовые проблемы при включении HTTP/3 (и что делать)
UDP/443 блокируется у части пользователей
Это нормальная реальность: корпоративные сети, некоторые провайдеры и часть «умных» роутеров фильтруют UDP. Решение — не «чинить UDP у клиентов», а обеспечить корректный fallback на HTTP/2. Поэтому важно:
не отключать HTTP/2;
не делать критичные функции сайта доступными только по HTTP/3;
следить за ростом ошибок/таймаутов после включения.
Миграция совпала с изменением кеш-логики
Частая ловушка: включили HTTP/3 и параллельно «подкрутили» кеширование, после чего стало непонятно, что дало эффект. По возможности разделяйте изменения: сначала протокол, потом кеш‑политики (или наоборот), фиксируя метрики после каждого шага.
TTFB не улучшился
Если большая часть времени уходит на PHP/БД, выигрыш от QUIC будет ограниченным. В таком случае HTTP/3 полезен как улучшение устойчивости и хвостов, а за TTFB нужно браться с другой стороны: профилирование, оптимизация запросов, кеш на приложении, настройка opcache и т. п. Для PHP‑кеша и ускорения динамики может быть полезен разбор: Memcached и Redis для кеша в PHP: что выбрать и как внедрять.
Как связаны HTTP/3 и PHP: практичные рекомендации
HTTP/3 меняет транспорт, но на уровне сайта есть несколько вещей, которые помогают «монетизировать» улучшенную сеть:
Сокращайте количество запросов: QUIC помогает, но меньше запросов всё равно лучше. Уберите лишние редиректы и цепочки 301/302.
Упорядочьте кеширование: статике — долгий TTL, динамике — ясные правила (либо приватный кеш, либо явный
no-cacheтам, где нужно).Контролируйте cold start: прогрев opcache и ключевых страниц часто даёт больший эффект, чем смена протокола.
Измеряйте хвосты: QUIC часто улучшает p95 при потерях. Это то, что замечают пользователи в мобильных сетях.
Если вы планируете менять сертификаты или включать/перевыпускать TLS 1.3 на фронте, следите за сроками и цепочками. Для публичных проектов удобнее держать процесс управления сертификатами предсказуемым; при необходимости можно оформить SSL-сертификаты под домен и спокойно катить изменения на edge.
Чеклист: готовы ли вы к HTTP/3
Есть TLS 1.3 и корректные сертификаты.
Понимаете, где терминируется HTTP/3: CDN/edge или ваш сервер.
UDP/443 не блокируется на вашей стороне (фаервол, балансировщик, хостинг‑сетап).
Отдаёте
Alt-Svcи оставляете fallback на HTTP/2.Есть baseline и план тестов: TTFB/RTT, p95, раздельно cache HIT/MISS.
Есть наблюдаемость по протоколам и ошибкам после выката.
Итог
HTTP/3 — это не «ускоритель PHP», а улучшение транспортного слоя: QUIC и TLS 1.3 дают выигрыш по задержкам и стабильности, особенно в мобильных и шумных сетях. Успешная миграция держится на трёх опорах: корректная сигнализация через Alt-Svc, согласование протокола (ALPN) и ясная стратегия CDN‑кеша. А чтобы понять, стало ли лучше, нужны измерения: TTFB и RTT, разрез по cache HIT/MISS и внимание к p95.
Если внедрять HTTP/3 как добавление к HTTP/2, с прозрачным откатом и аккуратным тестированием, это обычно даёт предсказуемый прирост и меньше «магии» в продакшене.
