Атака на веб-сервис под нагрузкой: что ломается первым

При атаке на веб-сервис первым часто ломается не сервер, а очередь перед ним: запросы приходят быстрее, чем приложение успевает их обрабатывать. Затем растёт задержка, заканчиваются соединения с базой или память воркеров — и обычные пользователи тоже начинают получать тайм-ауты. Ниже — разбор типичного сценария, а не описание конкретного подтверждённого инцидента: без названия сервиса, логов и замеров выдавать его за реальную атаку было бы выдумкой.

Сначала важно понять, что именно атакуют

«Атака под нагрузкой» может означать разные вещи: поток запросов на главную страницу, частые обращения к дорогому поиску, медленные соединения или заполнение канала трафиком. Нагрузка бывает распределённой, когда запросы идут с множества адресов, и целевой — когда злоумышленник бьёт по одному ресурсоёмкому маршруту. Для сервиса последствия похожи, но место отказа и меры защиты различаются.

Разбор ниже рассматривает веб-приложение за обратным прокси: прокси принимает соединения и передаёт запросы приложению, приложение обращается к базе данных. Это распространённая схема, но не описание конкретного стека или версии ПО. Если у вас сервернаяless-архитектура, CDN или очередь задач, точки отказа будут другими.

Цепочка отказа: от очереди до базы данных

1. Растёт число соединений

На первом этапе входящий поток приближается к пределу, который выдерживают сетевой канал, прокси или настройки числа одновременных соединений. Если значительная часть запросов держит соединение открытым, свободных слотов становится меньше даже без особенно большого объёма переданных данных. Пользователь может увидеть долгую загрузку, ошибку шлюза или сброс соединения.

Один график загрузки процессора здесь не спасёт. Сервис может отвечать медленно при умеренном CPU, если соединения заняты ожиданием приложения, диска или другого сервиса. Смотрите число активных соединений, их длительность, ошибки на прокси и долю запросов, завершившихся по тайм-ауту.

2. Заполняется очередь приложения

Прокси передаёт запросы, но обработчики заняты. Новые запросы ждут в очереди; время ответа растёт, а часть запросов не укладывается в тайм-аут клиента или шлюза. Повторные попытки могут усилить проблему: один исходный запрос превращается в несколько попыток, если клиенты повторяют вызовы без паузы и ограничения числа повторов.

Особенно уязвимы маршруты, где каждый запрос запускает дорогую работу: сложный поиск, генерацию отчёта, обработку большого файла. Десять разных страниц могут нагружать приложение неравномерно. Поэтому среднее время ответа по всему сайту скрывает то, что один маршрут уже лежит.

3. Приложение занимает ресурсы в ожидании

Если обработчики ждут базу данных или внешний API, они остаются занятыми, хотя почти не используют процессор. При исчерпании пула обработчиков запросы перестают приниматься, а запас по памяти сокращается. Если приложение создаёт слишком много процессов или удерживает большие ответы, нехватка памяти может привести к перезапускам.

В логах ищите не только сообщения об ошибках, но и последовательность событий: рост времени обработки, тайм-ауты обращений к зависимостям, отказ в выдаче соединения, перезапуск процесса. Одиночная ошибка не доказывает атаку. Важны совпадение во времени с аномальным трафиком и изменение показателей по конкретным маршрутам.

4. База данных получает вторую волну

Запросы приложения к базе могут быть короткими, но массовыми. Пул соединений исчерпывается, растёт число ожидающих запросов, блокировки дольше удерживают транзакции. Если каждый запрос к веб-сервису запускает несколько обращений к базе, рост входящего потока многократно увеличивает нагрузку на неё.

Увеличение числа соединений не всегда помогает: база получает ещё больше параллельной работы и может отвечать медленнее. Сначала выясните, что занимает соединения и какие запросы дольше всего выполняются. Без профиля запросов и метрик базы настройка «побольше соединений» — ставка наугад.

Первый симптом — не всегда место поломки. Тайм-аут на странице может быть следствием очереди в приложении, а очередь — следствием медленного запроса к базе.

Как локализовать первое узкое место

Сведите метрики по времени в одну картину. Минимальный набор — входящий трафик, задержка ответа, ошибки, активные соединения на прокси и в пуле приложения, память и перезапуски процессов, ожидание и длительность запросов к базе. Разбейте данные по маршрутам: общая средняя температура по сервису сглаживает локальный отказ.

Метрики p95 и p99¹ показывают задержку, которую превышают соответственно 5% и 1% запросов. Они лучше среднего времени ответа выявляют хвост медленных запросов, но сами по себе не указывают на виновный компонент.

Где диагностика ломается

• Смотрят только на общий график трафика. Небольшой поток запросов может быть дорогим, если каждый запускает тяжёлый поиск или отчёт.
• Сбрасывают очередь без проверки причины. Это может освободить ресурсы, но потерянные запросы и повторные попытки создадут новый всплеск.
• Увеличивают тайм-ауты. Если обработчик занят дольше, увеличение ожидания удерживает ресурсы и способно продлить перегрузку.
• Перезапускают приложение снова и снова. Перезапуск иногда снимает временный симптом, но не уменьшает входящий поток и не ускоряет медленную зависимость.
• Считают любой пик атаким. Релиз, сбой внешнего API, ошибка клиента или индексирование сайта тоже могут изменить профиль запросов. Нужны журналы и сопоставление метрик, а не догадка по одному графику.

Что измерять во время проверки

Если инцидента ещё нет, проведите контролируемый нагрузочный тест в среде, где он не затронет пользователей и соседние системы. Зафиксируйте исходную конфигурацию, профиль запросов, длительность теста и момент, когда показатели начинают ухудшаться. Не называйте результат прогнозом для продакшена, если отличаются данные, сеть, зависимости или настройки масштабирования.

Сравнивайте не только пропускную способность, но и задержки p95/p99, долю ошибок, глубину очередей, использование памяти и состояние базы. Для каждого прогона записывайте, какой компонент достиг своего ограничения первым. Так вы отличите нехватку мощности от запроса, который непропорционально дорог для приложения.

Что делать дальше

Начните с карты зависимостей одного критичного маршрута: прокси, приложение, база и внешние API. Добавьте для него раздельные метрики задержки и ошибок, затем проверьте, как система ведёт себя при постепенном росте запросов. Следующий практический шаг — настроить ограничение частоты и защиту от избыточных повторов там, где это поддерживает ваш стек; конкретные параметры сверяйте с документацией используемых компонентов.

При реальной атаке сохраняйте временную шкалу событий, журналы доступа и метрики до и во время отказа. Не ограничивайтесь снимком графика после восстановления: без данных о начале перегрузки трудно понять, какая очередь или зависимость сломалась первой. Настройка защиты от сетевых атак и расследование инцидента — смежные темы; здесь важнее установить порядок отказа внутри сервиса.

¹ Перцентиль — значение, ниже которого находится указанная доля измерений. Например, p95 — граница для 95% запросов, а не среднее время ответа.