Настройка HTTP/2 не ускорила сайт: где теряется скорость отдачи
Включённый HTTP/2 в конфигурации ещё не означает, что страница поедет быстрее. Протокол даёт мультиплексирование — десятки ресурсов идут в одном соединении, — но если на периметре стоит прокси или балансировщик, который терминирует шифрование и уходит к бэкенду отдельным каналом, вся выгода остаётся на бумаге. Внешне всё настроено, а медленная отдача страниц объясняется совсем другим участком.
Сначала смотрим на задержку первого байта от приложения. Мультиплексирование не спасает, когда ответ формируется долго: потоки уже открыты, но передавать нечего. Рядом обычно лежит блокировка очереди запросов — исчерпан лимит одновременных потоков, и часть обращений встаёт в очередь на сервере вместо того, чтобы идти параллельно.
Второй слой — переиспользование соединений. Если прокси разрывает длительные соединения или пересобирает заголовки без сжатия, клиент поднимает канал заново: рукопожатие, согласование шифрования, снова ожидание. Лишние соединения к серверу возвращают ту же картину рывками, от которой уходили от предыдущей версии протокола.
Третий слой — сам периметр: узкое место на периметре видно как ровный потолок по числу одновременных потоков и рост задержки под нагрузкой. Подкрутка флагов здесь не помогает — нужен разбор цепочки: где терминируется соединение, что происходит с приоритетами запросов, где оседает кэш. Дальше показываем, как это находится и что меняется в конфигурации.
Что даёт настройка HTTP/2: отдача страниц без очереди запросов
Настройка HTTP/2 меняет саму схему загрузки страницы: вместо нескольких параллельных соединений на домен браузер держит одно и мультиплексирует потоки внутри него. Очередь запросов перестаёт быть узким местом — ресурсы отдаются одновременно, а не порциями по шесть штук, и время отдачи страницы падает за счёт исчезнувшего простоя, а не за счёт роста канала.
Сжатие заголовков убирает второй скрытый расход: повторяющиеся куки, user-agent и заголовки безопасности передаются ссылками на таблицу соединения, а не полным текстом на каждый из сотни ресурсов. Приоритизация ресурсов расставляет вес запросам — стили и скрипты, блокирующие отрисовку, уходят вперёд, изображения ниже первого экрана уступают им место. Стандарт описан в IETF, и поведение серверов там же оговорено: без явных весов клиент угадывает сам, и картинка нередко обгоняет CSS.
Смотреть после включения стоит на две величины: время отдачи страницы под реальной нагрузкой и долю повторных соединений — если она растёт, где-то рвётся keep-alive или мешает промежуточный прокси. Настройка не сводится к галочке в конфиге: нужны лимиты одновременных потоков, размеры окон, разумные таймауты простоя, а также пересмотр старых приёмов — доменный шардинг и склейка файлов при мультиплексировании только вредят.
Корректная конфигурация даёт предсказуемую отдачу под пиком: страница не деградирует ступенями, когда десятки клиентов конкурируют за соединения. Отсюда — разбор, как это проверяется и закрепляется в инфраструктуре.
Сравнение подходов: HTTP/2, HTTP/3 и гибридная схема отдачи
Выбор версии протокола — не «включить новое и посмотреть», а вопрос совместимости с реальным парком клиентов. HTTP/2 поверх защищённого канала даёт мультиплексирование запросов и сжатие заголовков, но все потоки идут через один TCP-канал: потеря пакета останавливает загрузку всей страницы. HTTP/3 и QUIC переносят управление потоками в транспорт — на мобильных сетях с потерями догрузка заметно быстрее.
Гибридная схема отдачи снимает риск резкого перехода: транспорт объявляется клиенту, и он сам выбирает поддерживаемый вариант, а старые браузеры и корпоративные прокси продолжают работать по HTTP/2.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| HTTP/2 поверх защищённого канала | Неоднородный парк клиентов, узкое место — ответ бэкенда | Один TCP-канал: потери пакетов тормозят все потоки |
| Гибридная схема отдачи | Большинство проектов: новый транспорт основной, рабочий — резервный | Нужен контроль балансировщика и метрики с двух транспортов |
| Полный переход на HTTP/3 и QUIC | Высокая доля мобильного трафика и сетей с потерями | Часть корпоративных сетей блокирует UDP — без явного отката нельзя |
| Текущий HTTP/1.1 | Внутренние сервисы с малым числом параллельных запросов | Нет мультиплексирования, потолок по числу соединений |
План отката схемы дешевле, чем кажется: согласование протокола с клиентом оставляет выбор за ним, поэтому возврат объявления транспорта — одна правка конфигурации, а уже установленные соединения не рвутся. Проверяем вариант на копии боевого трафика и фиксируем, при каком профиле потерь выигрыш исчезает.
Порядок работ: от аудита соединений до передачи регламентов
Порядок работ выстроен так, чтобы изменения на периметре можно было измерить и откатить, а не проверять ощущением «стало быстрее». Каждый шаг заканчивается артефактом — замером, схемой, конфигурацией или регламентом, по которому результат проверяется независимо от того, кто вёл работы.
Семь шагов
- Аудит соединений — выясняем, какие версии протокола согласуются с реальными клиентами, где завершается шифрование и какие промежуточные узлы мешают мультиплексированию.
- Снятие замеров задержек — фиксируем базовую линию: время установления соединения, число сетевых обходов до первого ответа, доля запросов по новому протоколу.
- Схема прохождения трафика — путь запроса от клиента до приложения: балансировщик, обратный прокси, сеть доставки, кэш. Без неё настройка идёт вслепую.
- Настройка периметра — включаем протокол на входе, правим приоритеты потоков, лимиты одновременных запросов и таймауты; конфигурация версионируется.
- Проверка на копии трафика — зеркалируем поток и прогоняем нагрузочные сценарии, сравнивая с базовой линией: ошибки согласования видны до выпуска.
- Выпуск и наблюдение — включаем на доле трафика, следим за долей успешных соединений и временем ответа; откат — одной правкой конфигурации.
- Передача регламентов — схема, конфигурации в системе контроля версий, чек-лист диагностики и порядок отката остаются у вашей команды.
Замеры до и после переходят заказчику: по ним видно, что именно дал переход и есть ли смысл двигаться к третьей версии протокола.
Комплект передачи: конфигурации, схемы и регламент отката
После работ у заказчика остаётся не отчёт, а рабочий комплект: файлы, по которым живёт прод, и документы, по которым инженер сопровождения повторит или откатит любое изменение. Передаём его в репозитории с историей правок, а не набором вложений в переписке, и разбираем каждый пункт вместе с вашей командой.
- Карта соединений: какие домены и поддомены идут через какой узел, где терминируется шифрование, для каких клиентов включён новый протокол, а для каких осознанно оставлен предыдущий.
- Конфигурации серверов и обратного прокси: рабочие файлы с комментариями, вынесенные параметры приоритизации потоков, таймаутов и размеров буферов — с пометкой, под какой профиль трафика они подобраны.
- Схема балансировки: как распределяется нагрузка между узлами, как проверяется их доступность, что происходит при отказе одного из них и как быстро трафик уходит на резерв.
- Правила кеширования: что отдаёт периметр, что клиент, отдельные политики для статики и для API, чтобы раздача не спорила с новым протоколом.
- Регламент отката: по какой метрике считаем изменение вредным, кто принимает решение, какой командой возвращается предыдущий профиль и сколько это занимает по факту.
- Инструкция для сопровождения: типовые сбои, что смотреть в метриках, порядок действий и точки эскалации.
- Набор проверок и замеры до/после: скрипт подтверждает, что соединение поднимается нужным протоколом и время отклика не деградировало.
Кейс: время отдачи каталога сократилось втрое
Каталог мебели — несколько сотен тысяч позиций, страница категории собирается из десятков запросов к статике, шрифтам и данным. В спокойном режиме отдача занимала 2,4 с, а на распродаже, когда трафик вырастал в шесть раз, — до 9 с. До семи процентов запросов завершались ошибкой шлюза: пул соединений на периметре заканчивался, и очередь запросов не доходила до приложения.
Что меняли на периметре
Включили HTTP/2: запросы одной страницы идут по единственному соединению, сжатие заголовков убирает повторяющиеся куки и метаданные, приоритеты отдают полосу критичным ресурсам. Для мобильного сегмента добавили HTTP/3 поверх QUIC — потеря пакета больше не тормозит остальные потоки, а возврат в сессию не требует полного согласования шифрованного канала заново. Параллельно настроили пул соединений к приложению и keep-alive так, чтобы соединение переиспользовалось, а не пересоздавалось под каждый запрос.
Что получилось
Время отдачи каталога под пиковой нагрузкой — 0,8 с, втрое меньше. Доля ошибок шлюза упала до 0,1 %, и ушёл целый класс отказов: страница перестала зависеть от того, сколько соединений браузер держит на домен. Узкое место сместилось с транспорта на рендеринг карточек — это уже отдельная задача с другим бюджетом времени.
Когда переход на HTTP/3 даёт выигрыш, а когда нет
Отличие HTTP/3 от HTTP/2 — в транспорте, а не в заголовках. Второй работает поверх TCP, где одна потеря пакета останавливает доставку всех параллельных запросов до восстановления окна, а третий идёт поверх QUIC: потоки независимы друг от друга, рукопожатие и установка шифрованного канала совмещены. Отсюда правило — выигрыш тем заметнее, чем хуже канал.
На мобильных сетях и дальних маршрутах потери в 2–5% и лишние круговые обходы складываются в секунды ожидания. Сокращение рукопожатия и отсутствие блокировки очереди уменьшают время до первого байта и 95-й перцентиль загрузки, тогда как на стабильном канале внутри одного города разница уходит в шум, и настройка HTTP/2 даёт тот же результат при меньшей сложности.
Поддержка на стороне клиента неоднородна: актуальные браузеры умеют, а встроенные компоненты приложений, старые библиотеки и корпоративные прокси — часто нет, часть фильтров трафика блокирует UDP целиком. Поэтому HTTP/2 остаётся базовым уровнем, а HTTP/3 включается как надстройка и при неудаче откатывается автоматически.
Готовность инфраструктуры проверяем до включения: балансировщик и межсетевой экран пропускают UDP, корректно отдаётся Alt-Svc, метрики снимаются по перцентилям, а не по среднему. Cloudflare и другие сети доставки кешируют ответ одинаково для обеих версий — ускорение идёт только на пути до клиента, а не в подготовке страницы.
Итог: публичный сайт с мобильной аудиторией и распределённой географией выигрывает от HTTP/3 по умолчанию с автоматическим откатом на HTTP/2. Для сервисов внутри одного ЦОД и трафика по стабильному каналу прирост теряется в промежуточных узлах и кеше.
Технические сомнения перед сменой протокола отдачи
Перед сменой протокола отдачи задают одни и те же пять вопросов — от ответов зависит, пройдёт переход плавно или обернётся ночным разбором инцидентов.
Не сломается ли балансировка нагрузки?
Балансировщик должен работать на прикладном уровне и согласовывать протокол — иначе соединение уйдёт на HTTP/1.1. Мультиплексирование снижает число параллельных сессий, поэтому проверки живости и лимиты на узел перенастраивают.
Как это влияет на кеширование?
Правила кеша и заголовки валидации не меняются — меняется среда: CDN и промежуточные узлы должны поддерживать новый протокол, а объединение запросов к домену усложняет разделение кеша.
Что с промежуточными прокси?
Корпоративные прокси и системы инспекции трафика часто обрывают соединение при согласовании. Их проверяют на тестовом контуре, а на бою оставляют автоматический откат на HTTP/1.1.
Можно ли внедрять поэтапно?
Да. Протокол включают на отдельном узле или доле трафика, сравнивают время отдачи и только затем расширяют охват. Откат — переключение настройки на узле, без пересборки приложения.
Старые клиенты перестанут работать?
Нет. Версия согласуется при установке соединения, и клиент без поддержки получает HTTP/1.1. Условие одно — корректный сертификат и одинаковый набор ресурсов на обеих ветках.
Обсудим задачу: пришлите схему отдачи трафика
Чтобы разговор был предметным, а не про пожелания, начинаем с текущей картины отдачи трафика: что стоит перед приложением, где терминируется шифрование, какие домены и поддомены обслуживаются. По этим данным уже видно, где узкое место — в согласовании соединений, сжатии, кэшировании статики или в маршрутизации между сервисами, и что мешает перейти на HTTP/2 и HTTP/3. Пришлите то, что есть под рукой, — вычищенная документация не нужна:
- схема отдачи трафика: балансировщик, прокси, приложение, сервисы доставки статики, внешние интеграции;
- текущие конфигурации фронтального слоя и правила маршрутизации;
- список доменов и поддоменов с разделением, где отдаётся статика, а где динамика;
- статистика: доля повторных обращений, средний размер файлов, география аудитории;
- как выдаются и обновляются сертификаты, есть ли автоматизация продления;
- ограничения: требования безопасности, регламенты, окна на изменения, закрытые для правок зоны;
- выгрузка метрик или журналов за характерный период — по ним видно поведение под нагрузкой.
Дальше отвечаем в два шага. Сначала — короткий разбор: какие правки нужны на каждом слое и в каком порядке их безопасно вносить. Затем возвращаемся с планом внедрения: состав работ по этапам, оценка сроков, точки отката и способ проверки результата на живом трафике.
Опишите задачу и приложите то, что есть, — вернёмся с оценкой и планом работ.
