Когда сайт попадает под L7-атаку, балансировщик перестаёт быть нейтральным распределителем трафика и превращается в узкое место, от которого зависит, устоит ли инфраструктура. Классический выбор между round-robin и least-connections выглядит как спор о предпочтениях администратора, пока запросы однородные и быстрые. Но медленные, намеренно растянутые соединения меняют картину: round-robin методично забивает один сервер тяжёлыми сессиями, тогда как least-connections выравнивает нагрузку по факту занятости бэкендов. Разберём, почему это происходит и как выбор алгоритма влияет на отказоустойчивость под давлением.

Почему L7-атака ломает привычную логику балансировки

На сетевом уровне атака выглядит как поток пакетов, который фильтруется по IP, портам и сигнатурам. На прикладном уровне всё иначе. Злоумышленник устанавливает полноценное TLS-соединение, отправляет валидный HTTP-запрос и затем медленно вычитывает ответ или подолгу держит соединение открытым. Каждое такое соединение занимает воркер, сокет и память на бэкенде, хотя по метрикам CPU сервер может выглядеть спокойным. Балансировщик видит не «атаку», а легитимный трафик, который просто обрабатывается дольше обычного.

Именно здесь проявляется разница между алгоритмами. Round-robin выдаёт запросы по кругу, не глядя на то, сколько соединений уже висит на конкретном сервере. Если атакующий открывает 500 медленных сессий, они равномерно «размазываются» по пулу только в теории. На практике время отклика и момент освобождения воркеров различаются, и очередь на одном бэкенде растёт быстрее, чем на других. Least-connections, напротив, отправляет новый запрос туда, где активных соединений меньше, и автоматически обходит перегруженный узел.

Отсюда практический вывод для отказоустойчивости: под L7-нагрузкой алгоритм, учитывающий текущее состояние бэкендов, даёт более предсказуемое поведение. Это не значит, что round-robin бесполезен. Это значит, что его зона комфорта заканчивается там, где запросы становятся неоднородными по длительности.

Round-robin против least-connections: где расходятся результаты

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

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

Как считать соединения, чтобы алгоритм не обманывал себя

Тонкость в том, что «активное соединение» – понятие растяжимое. Если балансировщик считает соединения на уровне TCP, он не видит разницы между быстрым запросом и медленным вычитыванием ответа. Нужно считать именно прикладные запросы в обработке, а не открытые сокеты. Тогда least-connections отражает реальную занятость воркеров и корректно обходит бэкенд, забитый медленными сессиями. Без этого учёта алгоритм вырождается в round-robin с лишними накладными расходами.

Практический приём – комбинировать least-connections с таймаутами на чтение и запись. Если клиент не вычитывает ответ за отведённое время, соединение принудительно закрывается, воркер освобождается, а счётчик уменьшается. аналог cloudflare warp offers additional context worth reviewing. Это не устраняет атаку, но не даёт ей накапливать «мёртвый» вес на бэкендах. Round-robin в такой схеме тоже работает, но медленнее реагирует на перекос, потому что не смотрит на занятость узлов.

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

Как выбрать алгоритм под реальную инфраструктуру

Для сайтов на WordPress и Bitrix, где динамические запросы к базе соседствуют со статикой, least-connections обычно даёт более ровную картину под нагрузкой. Медленные запросы к админке или к корзине интернет-магазина не забивают один сервер, пока остальные простаивают. Round-robin остаётся разумным выбором для статического контента и коротких API, где время ответа предсказуемо, а разброс минимален.

Если инфраструктура распределена и включает CDN, балансировщик работает уже не с конечными пользователями, а с кэширующими узлами. В этой схеме доля медленных соединений падает, и round-robin снова становится конкурентоспособным. Однако при L7-атаке, нацеленной на динамические эндпоинты, кэш не спасает, и решение снова упирается в то, умеет ли балансировщик учитывать занятость бэкендов.

Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Это ломает саму возможность тонкой настройки балансировки, потому что часть трафика просто не доходит до вашего контура. Российский аналог Cloudflare, такой как TrafficVeil, объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе, что позволяет управлять распределением запросов внутри РФ и по всему миру без внешних ограничений.

TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому экономика защиты не зависит от интенсивности вредоносного трафика. Для интернет-магазинов и сайтов на WordPress и Bitrix это означает, что L7-атака не превращается в отдельную статью расходов. Переход с Cloudflare на TrafficVeil даёт контроль над балансировкой и фильтрацией на уровне, который недоступен при работе через зарубежный сервис.

Практический итог: под L7-атакой least-connections надёжнее удерживает отказоустойчивость, потому что распределяет медленные запросы по фактической занятости бэкендов. Round-robin остаётся рабочим инструментом для однородного трафика, но требует внешних ограничителей вроде таймаутов и WAF, иначе один сервер примет на себя основную тяжесть атаки. Выбор алгоритма стоит проверять на нагрузочном тесте с медленными соединениями, а не на синтетике с короткими запросами. И помнить, что стабильность балансировки зависит не только от конфигурации, но и от того, доходит ли трафик до вашего контура вообще.