Іноді проблема виглядає нелогічно. На сайті не видно різкого напливу відвідувачів, трафік у графіках не впирається в канал, кількість запитів не здається катастрофічною. Але сторінки відкриваються повільно, частина запитів відвалюється, вебсервер починає забирати більше пам’яті, а застосунок відповідає через раз. У таких випадках часто шукають важкий скрипт, помилку в базі даних або нестачу ресурсів на тарифі. І це справді треба перевіряти. Але є ще один сценарій, який легко пропустити: аномальне навантаження через HTTP/2. Зокрема атака, яку називають HTTP/2 Bomb.
Її небезпека не в тому, що на сервер летять мільйони запитів. Проблема в іншому: невелика кількість спеціально сформованих HTTP/2-з’єднань може змусити сервер витрачати непропорційно багато пам’яті та довше утримувати внутрішні ресурси. Зовні все виглядає не так страшно, а всередині вебсервер уже працює на межі.
У чому суть HTTP/2 Bomb
HTTP/2 сам по собі не є проблемою. Це нормальний протокол, який допомагає сайтам швидше працювати: він дозволяє передавати кілька запитів в одному з’єднанні, стискає заголовки, зменшує зайві підключення між браузером і сервером. Але саме ці можливості створюють простір для зловживання. Якщо сервер приймає HTTP/2 без достатніх обмежень, атакувальник може тримати з’єднання відкритими, створювати багато внутрішньої роботи для вебсервера і поступово забирати пам’ять. При цьому мережевий трафік може залишатися відносно невеликим.
Тобто HTTP/2 Bomb – це не “атака кількістю” у звичному сенсі. Це атака на те, як сервер обробляє з’єднання. Саме тому її важче помітити за простими графіками трафіку.
Чому VPS реагує на таку атаку швидше
У VPS ресурси обмежені тарифом: оперативна пам’ять, процесорний час, дискова підсистема. Якщо вебсервер починає різко споживати пам’ять через підозрілі HTTP/2-з’єднання, запас швидко закінчується.
На практиці це може виглядати як нестабільна робота всього сайту. Спочатку повільніше відповідає nginx або Apache. Потім починає “задихатися” PHP-FPM, Node.js, Python-застосунок або інший backend. Далі можуть з’явитися помилки 502, 503, 504. Якщо пам’яті зовсім не вистачає, система починає завершувати процеси або сервіси перезапускаються.
Найгірше, що атака на один сайт на VPS може зачепити все, що розміщено поруч. Наприклад, на сервері працює інтернет-магазин, тестовий проєкт, CRM і база даних. Формально атакують тільки публічний сайт, але ресурси забираються у всього середовища.
Що відбувається на виділеному сервері
Виділений сервер має більший запас потужності, але це не робить його невразливим. Якщо HTTP/2-з’єднання обробляє фронтовий вебсервер, reverse proxy або балансувальник, саме цей шар першим приймає удар.
На dedicated-сервері наслідки часто розтягуються в часі. Спочатку просто росте споживання пам’яті. Потім збільшується кількість відкритих з’єднань. Далі починають повільніше відповідати сайти, які взагалі не були прямою ціллю атаки. Якщо на машині багато віртуальних хостів або кілька клієнтських проєктів, проблема швидко стає не локальною, а серверною.
Окрема ситуація – коли виділений сервер використовується як проксі перед іншими серверами. У такому разі збій на HTTP/2-рівні може вплинути на всю схему: frontend перестає нормально передавати запити далі, хоча backend-сервери фізично ще живі.
Як зрозуміти, що проблема може бути саме в HTTP/2
Перший тривожний знак – серверу погано, але класичної картини DDoS немає. Канал не забитий, загальний трафік не виглядає рекордним, а пам’ять вебсервера росте швидше, ніж очікувалося.
Варто перевірити, скільки з’єднань відкрито до nginx, Apache, Envoy або іншого сервісу на вході. Потрібно подивитися, чи немає довгих підключень, які передають мало даних, але довго залишаються активними. Також важливі логи помилок, статистика 502/503/504, зміни у споживанні RAM і поведінка процесів після перезапуску вебсервера.
Якщо після рестарту все ненадовго стабілізується, а потім ситуація повторюється, це привід уважніше подивитися саме на рівень з’єднань. Не обов’язково винен HTTP/2 Bomb, але виключати його не варто.
Що перевірити в конфігурації
Почати краще з базових речей: версії вебсервера, системних пакетів і компонентів, які приймають HTTP/2-з’єднання. Старі версії nginx, Apache, Envoy, IIS або проміжних проксі можуть мати поведінку, яку вже виправили в оновленнях.
Після цього потрібно переглянути ліміти. Сервер не повинен безконтрольно приймати будь-яку кількість потоків, тримати з’єднання занадто довго або дозволяти одному клієнту споживати непропорційно багато ресурсів. Важливі обмеження на час очікування, кількість одночасних з’єднань, кількість HTTP/2-потоків, розмір заголовків і частоту запитів.
Для VPS це особливо критично, бо навіть невелика помилка в лімітах швидко перетворюється на падіння сервісу. Для виділеного сервера ліміти потрібні не менше, просто там проблема може довше залишатися непомітною.
Як зменшити ризик
Найпростіша профілактика – не залишати HTTP/2 “як є”, якщо сервер приймає публічний трафік. Потрібно оновлювати вебсервер, налаштовувати таймаути, вводити обмеження для підключень, використовувати rate limiting і стежити не тільки за трафіком, а й за пам’яттю та кількістю активних з’єднань.
Якщо використовується CDN або WAF, важливо не просто увімкнути його формально, а перевірити, як він працює з HTTP/2. Частина захисту може фільтрувати великі потоки трафіку, але не завжди добре бачить проблему на рівні довгих або “важких” з’єднань.
У критичній ситуації можна тимчасово вимкнути HTTP/2 на вхідному вебсервері, щоб стабілізувати роботу сайту. Це не універсальне рішення і не заміна нормального налаштування, але як аварійний крок воно іноді допомагає швидко повернути сервіс у робочий стан.
Що робити після інциденту
Після стабілізації не варто обмежуватися фразою “серверу не вистачило ресурсів”. Потрібно розібратися, чому саме вони закінчилися. Якщо причина була в HTTP/2-навантаженні, просте збільшення RAM або перехід на потужніший тариф лише відкладе повторення проблеми.
Правильна логіка інша: оновити компоненти, закрити слабкі місця в конфігурації, додати ліміти, перевірити логи, налаштувати моніторинг за з’єднаннями й пам’яттю. Для VPS це допомагає не доводити систему до різкого падіння. Для виділеного сервера – не допустити, щоб один проблемний вхідний шар поклав кілька сервісів одразу.
HTTP/2 Bomb варто сприймати не як рідкісну екзотику, а як нагадування: сервер може бути вразливим не тільки через слабкий пароль або старий застосунок. Іноді достатньо неправильно обмежених з’єднань, щоб стабільний VPS або потужний dedicated почав поводитися так, ніби його атакують набагато сильніше, ніж показують графіки трафіку.