Для сайта с посещаемостью 10 000 уникальных посетителей (UV) в сутки расчет потенциального количества запросов строится по принципу воронки: от посетителей к просмотрам страниц, а от них – к техническим HTTP-запросам.

Поскольку ваша цель – подготовка к защите от DDoS и ботов, нас интересуют не только «человеческие» запросы, но и коэффициент бот-трафика, а также перевод этих цифр в RPS (запросы в секунду), так как именно на эту метрику реагируют системы защиты.

Вот подробный расчет от базового сценария до атакующего.

Шаг 1. Расчет «человеческого» трафика (базовая линия)

Используем средние отраслевые метрики (вы можете скорректировать их под свою аналитику):

  1. Уникальные посетители (UV): 10 000 в сутки.
  2. Сеансы (Визиты): Обычно 1 UV делает чуть больше 1 визита. Возьмем коэффициент 1.2.
    10 000 × 1.2 = 12 000 сеансов в сутки.
  3. Глубина просмотра (Pageviews): В среднем пользователь просматривает 3–4 страницы за сеанс. Возьмем 3.
    12 000 × 3 = 36 000 просмотров страниц в сутки.
  4. HTTP-запросов на одну страницу: Современная веб-страница (HTML, CSS, JS, шрифты, картинки, вызовы API, счетчики аналитики) генерирует от 30 до 80 запросов. Возьмем среднее – 50 запросов.
    36 000 × 50 = 1 800 000 (1.8 млн) запросов в сутки.

Итого легитимных запросов:

  • В сутки: ~1.8 млн
  • В месяц (×30): ~54 млн

Шаг 2. Добавляем фактор ботов (Реальный трафик)

Даже без целенаправленной DDoS-атаки значительную часть трафика составляют боты: поисковые роботы (Google, Yandex), мониторинги, парсеры контента, сканеры уязвимостей.
Для сайтов среднего размера доля ботов в общем количестве запросов составляет от 40% до 70%.

Возьмем консервативную оценку: боты генерируют столько же запросов, сколько люди (коэффициент 1.0 к человеческому трафику, то есть 50% всего трафика – боты).

Реальный общий трафик (люди + обычные боты):

  • В сутки: 1.8 млн × 2 = ~3.6 млн запросов
  • В месяц: 54 млн × 2 = ~108 млн запросов

Шаг 3. Перевод в RPS (Запросы в секунду) – самое важное для защиты

Системы WAF и анти-DDoS не оперируют месячными цифрами, они смотрят на секундные пики.

  1. Средний RPS:
    3 600 000 запросов / 86 400 секунд в сутках = ~42 RPS (в среднем по больнице).
  2. Пиковый RPS (нормальная работа):
    Трафик неравномерен. Днем и вечером нагрузка выше, ночью – почти нулевая. Пиковая нагрузка обычно превышает среднюю в 4–6 раз.
    42 RPS × 5 = ~210 RPS (это ваш нормальный дневной пик).

Шаг 4. Моделирование DDoS-атаки или бот-нашествия

Злоумышленники не будут атаковать вас на уровне 210 RPS – это бесполезно. Атака будет кратной вашему пику, чтобы исчерпать ресурсы сервера (CPU, RAM, соединения БД).

  • Сценарий 1: Точечная L7-атака (HTTP-флуд, умные боты).
    Атакующий ботнет генерирует нагрузку, имитирующую реальных пользователей, но в 20–50 раз интенсивнее вашего пика.
    Ожидаемая мощность атаки: 210 RPS × 30 = ~6 000 – 10 000 RPS.
    Цель защиты: Ваш WAF/CDN должен уметь прозрачно фильтровать или отдавать JS-челленджи при превышении порога, например, в 500 RPS, не допуская достижения 6 000 RPS на вашем origin-сервере.
  • Сценарий 2: Атака на «тяжелые» эндпоинты (амплификация).
    Если боты долбятся не в главную страницу (которая, возможно, закэширована), а в поиск, фильтр товаров или форму авторизации, один HTTP-запрос превращается в 10–50 запросов к базе данных.
    Опасность: Даже 500 RPS таких запросов могут положить базу данных, если нет рейт-лимитов (Rate Limiting).
  • Сценарий 3: Сетевая атака (L3/L4, UDP/TCP флуд).
    Она не зависит от вашей посещаемости. Атакующему все равно, сколько у вас посетителей. Для сайта с каналом в 100 Мбит/с типичная атака для его полного «положения» составит 10–50 Гбит/с. Здесь спасает только фильтрация на уровне провайдера (Scrubbing Center).

Итоговая сводка для вашего ТЗ или разговора с провайдером защиты:

МетрикаОценка для 10 000 UV/суткиКомментарий
Запросов в месяц (всего)~90 – 120 млнВключая фоновых ботов и парсеров.
Средний RPS~40 – 50 RPSСредняя нагрузка на сервер 24/7.
Пиковый RPS (норма)~200 – 300 RPSМаксимум в часы пик без атак.
Целевой лимит WAF (L7)5 000 – 10 000 RPSЕмкость, которую должна выдержать система фильтрации.
Rate Limiting (защита)~5–10 запросов/сек с 1 IPПорог, после которого IP должен получать капчу или бан.

Как уточнить эти цифры для вашего конкретного сайта (за 5 минут):

Не гадайте, посмотрите точные цифры в ваших логах:

  1. Откройте access-лог Nginx/Apache за последний типичный день.
  2. Выполните команду: cat access.log | wc -l (получите точное число запросов за день).
  3. Разделите это число на 86 400, чтобы получить точный средний RPS.
  4. Чтобы найти пик, можно сгруппировать логи по минутам: awk '{print $4}' access.log | cut -d: -f1,2 | uniq -c | sort -nr | head -5 (покажет 5 самых нагруженных минут и количество запросов в них. Разделите число на 60, чтобы получить пиковый RPS).

Главный совет: Для сайта с такой посещаемостью покупка дорогого «железного» анти-DDoS избыточна. Оптимальная стратегия – подключение облачного WAF/CDN (например, Cloudflare, DDOS-Guard, Qrator, StormWall), который поглотит пиковые 10 000+ RPS на своей стороне, а на ваш сервер пропустит только очищенные 200–300 RPS. Обязательно настройте Rate Limiting на API и формы авторизации.