Налаштування 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. Надішліть те, що є під рукою, — вичищена документація не потрібна:
- схема віддачі трафіку: балансувальник, проксі, застосунок, сервіси доставки статики, зовнішні інтеграції;
- поточні конфігурації фронтального шару й правила маршрутизації;
- список доменів і піддоменів із розділенням, де віддається статика, а де динаміка;
- статистика: частка повторних звернень, середній розмір файлів, географія аудиторії;
- як видаються й оновлюються сертифікати, чи є автоматизація продовження;
- обмеження: вимоги безпеки, регламенти, вікна на зміни, закриті для правок зони;
- вивантаження метрик або журналів за характерний період — за ними видно поведінку під навантаженням.
Далі відповідаємо у два кроки. Спочатку — короткий розбір: які правки потрібні на кожному шарі й у якому порядку їх безпечно вносити. Потім повертаємося з планом впровадження: склад робіт за етапами, оцінка строків, точки відкату й спосіб перевірки результату на живому трафіку.
Опишіть задачу й додайте те, що є, — повернемося з оцінкою та планом робіт.
