ALPN и согласование HTTP/2
ALPN HTTP/2 · согласование h2 · проверка ALPN
Почему ALPN решает, будет ли использован h2, и как искать причину отсутствия HTTP/2.
Автор: DN01 Network Team
ALPN — расширение TLS, с помощью которого клиент и сервер выбирают прикладной протокол до начала HTTP-обмена, поэтому отладка HTTP/2 часто начинается с TLS. Надежнее всего проверять тот же публичный hostname, scheme и redirect path, по которому идут пользователи, поисковые роботы или API-клиенты. Значок protocol в одной вкладке браузера полезен, но он не доказывает, что все hostname, CDN edge и backend route согласуют тот же протокол.
Хорошая проверка показывает, предлагал ли сервер h2, выбрал ли его клиент и не поменял ли proxy протокол между edge и origin. В DN01 начинайте с HTTP/2 Tester на /ru/http2-tester и держите рядом HTTP Header Checker и SSL Certificate Checker. HTTP/2 согласуется через TLS и часто скрывается за редиректами или proxy, поэтому один сигнал редко объясняет весь сбой.
Эта статья входит в набор руководств по HTTP/2 Tester. Для соседних сценариев откройте /ru/articles/trebovaniya-tls-dlya-http2 и /ru/articles/h2-protiv-http11, особенно если результат меняется во время deploy или миграции CDN.
Что проверить первым
Используйте /ru/http2-tester для проверки negotiated h2, а при отсутствии ALPN смотрите TLS и сертификат через /ru/ssl-certificate-checker. Используйте точный production hostname, а не удобный тестовый домен. Отдельно проверяйте apex, www, API, static assets и региональные hostnames, если TLS завершается в разных местах.
Проверьте финальный URL после редиректов. Сайт может перейти с HTTP/2-enabled hostname на legacy hostname или с современного CDN edge на origin path, который говорит только HTTP/1.1.
Фиксируйте время, target, финальный протокол и видимые TLS/header clues. Эти детали полезнее для incident review, чем скриншоты без контекста.
Как читать результат
Успешный h2 означает, что проверяемый клиент и публичный endpoint согласовали HTTP/2 для этого запроса. Это не доказывает автоматически, что каждый upstream hop, internal service или alternate hostname тоже использует HTTP/2.
HTTP/1.1 не всегда ошибка. Некоторые legacy clients, private origins, debugging endpoints и compatibility paths намеренно остаются на HTTP/1.1. Важно, совпадает ли результат с вашей архитектурой и ожиданиями пользователей.
Если ALPN выключен, вырезан прокси или не поддерживается старой TLS-библиотекой, страница может открываться нормально, но тихо работать по HTTP/1.1. Поэтому проверка протокола должна жить рядом с TLS и header checks, а не в отдельной таблице без контекста.
Связанные проверки
Откройте /ru/ssl-certificate-checker, если результат указывает на TLS, certificate, SNI или ALPN. Покрытие hostname в сертификате и политика TLS listener часто объясняют неожиданный fallback.
Откройте /ru/http-header-checker, когда redirects, cache behavior, Via headers, Alt-Svc, HSTS или server headers могут объяснить различия между путями.
Для launch review держите /ru/http2-tester в runbook рядом с DNS, SSL и header checks, чтобы команда проверяла одну и ту же публичную поверхность до и после релиза.
Операционный чеклист
Зафиксируйте ожидаемый список ALPN в runbook рядом с конфигом сервера, настройками load balancer и политикой CDN для origin. Не полагайтесь на один зеленый результат с локального ноутбука, если production traffic проходит через несколько регионов или провайдеров.
Проверяйте до изменения, сразу после rollout и еще раз после того, как CDN или DNS cache успели стабилизироваться. Если у провайдера региональные edges, сравните минимум две локации клиента или мониторинга.
Прикладывайте URL результата DN01 или скопированный вывод к тикету. Когда platform, security и frontend команды смотрят на одну evidence base, расследования HTTP/2 обычно становятся короче.
| Сигнал | Зачем он нужен |
|---|---|
| Negotiated protocol | Показывает, использовал ли запрос h2 или HTTP/1.1. |
| TLS и ALPN | Объясняет многие fallback до обмена HTTP-заголовками. |
| Redirect chain | Показывает смену протокола из-за canonical host или path rules. |
| Response headers | Дает clues по CDN, proxy, cache, HSTS и серверу. |
Частые вопросы
- HTTP/2 Tester заменяет browser devtools?
Нет. Он дает независимую внешнюю проверку, которой удобно делиться в тикетах. Для user-specific поведения используйте его вместе с devtools.
- Может ли сайт поддерживать HTTP/2 и все равно быть медленным?
Да. HTTP/2 снижает часть накладных расходов на соединения, но медленный origin, cache miss, тяжелые assets и blocking scripts могут оставаться главной причиной.
- Зачем дополнительно проверять SSL и headers?
Для большинства публичных сайтов HTTP/2 зависит от TLS negotiation, а headers и redirects часто показывают CDN или proxy behavior, который меняет финальный протокол.