Real-Time Backend
DDoS и Abuse
В 2016 году Dyn DNS подвергся DDoS через Mirai botnet - упали Twitter, Netflix, GitHub. WebSocket-серверы уязвимы по-особому: одно соединение держится часами, и злоумышленник платит за него один раз, а сервер - постоянно.
- **Cloudflare** ежедневно блокирует свыше 140 млрд угроз, используя connection rate limiting на уровне anycast-сети - до того как трафик доходит до origin-сервера клиента.
- **Discord** применяет многоуровневую защиту gateway: connection limit per IP, message rate limit (120/60s), и ML-детекцию спам-ботов в реальном времени на 26+ млн concurrent users.
- **Stripe** использует circuit breaker для изоляции платёжных провайдеров: сбой одного шлюза не каскадирует на остальные, SLA 99.99% поддерживается даже при частичных отказах downstream.
Connection Flooding
Connection flooding - атака, при которой злоумышленник открывает тысячи WebSocket-соединений без передачи полезных данных. Каждое соединение потребляет память (обычно 2-8 KB на сокет в Node.js) и файловый дескриптор. При 100 000 одновременных idle-соединений процесс занимает ~500 MB только под буферы - и это до обработки единственного сообщения.
Cloudflare в 2023 году отразила HTTP/2 Rapid Reset атаку мощностью 201 миллион rps - рекорд на момент публикации. Та же логика применима к WebSocket: cost открытия соединения на клиенте близок к нулю, cost на сервере - значителен.
Для production: connection limit per IP - первая линия, но не единственная. Добавляют backpressure на уровне Nginx/HAProxy (limit_conn), анализ TLS fingerprint (JA3) для блокировки ботов, и CAPTCHA challenge при аномальном росте.
Сервер получает 50 000 новых WebSocket-соединений за 10 секунд с разных IP. Большинство соединений не отправляют данных. Какой первый признак этой атаки отличает её от легитимного трафика?
Message Spam
Message spam - сценарий, при котором клиент с легитимным соединением шлёт сотни сообщений в секунду. Discord обрабатывает ~26 миллионов одновременных пользователей и применяет rate limiting на уровне gateway: не более 120 сообщений в 60 секунд на клиента. Превышение - immediate disconnect. Это защищает downstream сервисы от лавинообразной нагрузки.
Token bucket алгоритм - стандартный инструмент: bucket наполняется с фиксированной скоростью (например, 10 токенов/сек), каждое сообщение расходует токен. Преимущество перед fixed window: допускает burst до ёмкости bucket, но не позволяет систематически превышать средний rate.
Token bucket ёмкостью 20 токенов наполняется со скоростью 5 токенов/сек. Клиент молчит 4 секунды, затем разом отправляет 25 сообщений. Сколько сообщений пройдёт?
Circuit Breaker
Circuit breaker в контексте WebSocket-серверов - паттерн защиты downstream сервисов от каскадных отказов. Когда бэкенд (например, Redis или БД) начинает отвечать медленно или с ошибками, circuit breaker переходит в состояние OPEN и немедленно отклоняет новые запросы, не дожидаясь timeout. Netflix Hystrix популяризировал паттерн; сегодня его реализуют в Resilience4j (Java) и аналогах для Node.
Три состояния circuit breaker: CLOSED (нормальная работа), OPEN (быстрый отказ без обращения к downstream), HALF_OPEN (пробный запрос для проверки восстановления). Stripe использует circuit breaker для изоляции платёжных провайдеров - отказ Visa не роняет Mastercard.
Circuit breaker сконфигурирован: threshold=3 failures, timeout=10s. Три запроса подряд завершились ошибкой. Состояние стало OPEN. Через 15 секунд приходит новый запрос. Что произойдёт?
Abuse Detection
Abuse detection - поведенческий анализ поверх rate limiting. Rate limiting отвечает на вопрос "сколько", abuse detection - "как". Паттерны: сообщения с одинаковым payload (спам), быстрое enumerate roomId (сканирование), отправка невалидного JSON после N легитимных сообщений (fuzzing). Twilio и Stripe комбинируют rule-based и ML-модели для детекции в реальном времени.
Не следует банить по единственному сигналу. Комбинируют несколько: высокий duplicate ratio + рост invalidMessageCount = высокая вероятность абуза. Ложные срабатывания на легитимных клиентах (например, мобильный клиент с ретраями) обходятся дорого репутационно.
Rate limiting достаточно для защиты от abuse - если лимиты не превышены, всё в порядке
Rate limiting защищает от перегрузки по объёму, но не от поведенческих паттернов абуза в пределах лимитов
Клиент может систематически сканировать ресурсы, спамить дубликатами, или зондировать API - всё в рамках rate limit. Abuse detection анализирует паттерн, а не только количество.
Клиент за минуту отправил 200 сообщений. 180 из них - идентичный JSON {"type":"ping"}. Rate limit не превышен (300 msg/min). Как правильно классифицировать поведение?
Итоги
- **Connection flooding** атакует ресурсы сервера (FD, память) без передачи данных - защита: лимит соединений per IP на уровне сетевого слоя.
- **Token bucket** rate limiting допускает контролируемый burst и защищает downstream от message spam - стандарт в production WebSocket-серверах.
- **Circuit breaker** изолирует отказы downstream сервисов (CLOSED → OPEN → HALF_OPEN), а abuse detection выявляет поведенческие паттерны, невидимые rate limiter.
Связанные темы
DDoS и abuse protection пересекается с несколькими смежными областями:
- Authentication и JWT — Аутентификация при handshake - первая линия защиты от анонимных соединений
- Monitoring и Alerting — Метрики connection count и message rate - основа для детекции аномалий в реальном времени
- Load Balancing — Балансировщик может абсорбировать connection flood до достижения серверов приложений
Вопросы для размышления
- Как отличить легитимный мобильный клиент с агрессивными reconnect-retry от connection flood бота?
- При каких условиях circuit breaker в HALF_OPEN состоянии может усилить нагрузку на восстанавливающийся сервис?
- Какие поведенческие паттерны WebSocket-клиента указывают на автоматизированный скрейпинг, не нарушающий rate limit?