Возможность

Лимиты соединений пула

Кодируйте реальную ёмкость backend-сервиса на уровне ADC — управляйте лимитами соединений, скорости, SSL и памяти из единого профиля.

TR7 Pool Connection Limits определяют, сколько трафика пул сервисов может безопасно нести по 8 независимым осям. Одновременные соединения, скорость новых соединений, скорость сессий, SSL-соединения, скорость SSL-handshake, размер буфера и поведение при повторных попытках — всё это управляется в рамках одного профиля лимитов. Этот подход не полагается на единственное поле «максимальное количество соединений» — потому что 20 000 простаивающих соединений и 2 000 новых TLS-handshake в секунду несут разные затраты. TR7 отдельно оценивает обычные и SSL/TLS-нагрузки, обеспечивая backend более точную защиту от CPU, памяти и connection storm. Профиль лимитов определяется один раз и может быть привязан к нескольким пулам. Можно создавать отдельные профили для production, staging, периодов кампаний, публичного web, внутренних API или требований конкретного тенанта. Обновление профиля централизованно меняет поведение ёмкости всех привязанных к нему пулов. Результат: TR7 превращает лимит соединений из голого числа в операционный профиль защиты, который явно кодирует ёмкость backend-сервиса, стоимость TLS, поведение очереди и бюджет памяти на уровне ADC.

Независимых осей лимитов в одном профиле: соединения, скорость, сессии, SSL, буфер, retry

Максимально настраиваемое количество одновременных соединений на пул (верхний предел maxConn)

Дефолтная скорость SSL-handshake в секунду (maxSslRate) — защищает CPU backend-сервиса

Единственное значение максимального количества соединений недостаточно для защиты ёмкости современного приложения.

В большинстве архитектур балансировки нагрузки лимит соединений трактуется как единственное поле: сколько соединений может быть открыто одновременно? Эта модель неполна. Десять тысяч ожидающих keep-alive соединений могут быть дешёвыми, тогда как 1 000 одновременных новых SSL-handshake способны быстро исчерпать CPU backend-сервиса. Одно и то же число производит совершенно разные затраты в зависимости от типа трафика.

Количество соединений и скорость соединений — также не одно и то же. «До 20 000 соединений могут быть открыты одновременно» — это потолок ёмкости; «до 10 000 новых соединений могут открываться в секунду» — это контроль burst и connection storm. Системы, не разделяющие эти два значения, либо излишне ограничивают легитимный трафик пользователей, либо не защищают backend от внезапной волны атак.

TLS-трафик необходимо рассматривать отдельно. Операции SSL/TLS-handshake дорогостоящи с точки зрения CPU, и когда они управляются в рамках того же лимита, что и обычные HTTP-соединения, реальная нагрузка становится невидимой. Особенно в периоды публичного web-трафика, трафика API-шлюза и кампаний независимое ограничение скорости handshake удерживает потребление CPU backend-сервиса под контролем.

Поведение очереди зачастую также непрозрачно. Когда лимит превышен, соединение молча сбрасывается, истекает по таймауту, ожидает в очереди или клиент получает чистый 503? Без видимости этого поведения причина происходящего непонятна во время инцидента — пользователи видят таймаут, а операционная команда слишком поздно выясняет реальную причину.

TR7 Pool Connection Limits защищают backend-сервисы через предсказуемое управление ёмкостью вместо молчаливой перегрузки, независимо контролируя общее число соединений, скорость соединений, скорость сессий, SSL-нагрузку, бюджет буфера и поведение при повторных попытках.

Наш подход

TR7 управляет ёмкостью пула не единственным полем, а структурой профиля, выстроенной по осям соединений, скорости, SSL, retry и буфера.

8-мерный профиль лимитов кодирует ёмкость в деталях

Один профиль определяет maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate и maxBufferSize. Это позволяет настраивать лимиты соединений, скорости, TLS и памяти backend-сервиса независимо друг от друга.

SSL-соединения ограничиваются отдельно от обычного трафика

Поскольку TLS-handshake дорогостоящи по CPU, TR7 управляет maxSslConn и maxSslRate как отдельными значениями. Это разделение помогает предотвратить исчерпание backend handshake storm даже при низком общем числе соединений.

Именованные профили разделяются между несколькими пулами

Профиль лимитов определяется с уникальным именем и может быть привязан к разным пулам сервисов. Production, staging, canary или политики ёмкости конкретного тенанта — всё можно управлять единой моделью профилей.

Настройки retry и буфера определяют поведение back-pressure

maxRetries определяет, сколько раз повторяется попытка соединения с backend при временном сбое. maxBufferSize контролирует потребление памяти на соединение в сценариях с медленными клиентами или медленными backend-сервисами.

Возможности

TR7 Pool Connection Limits контролируемо ограничивают backend-сервисы от connection storm, TLS-нагрузки, всплесков сессий и давления на память.

maxConn ограничивает общее число одновременных соединений на уровне пула

maxConn устанавливает потолок одновременно открытых соединений на пул, с дефолтным значением 20 000 и верхним пределом 1 000 000. Это значение кодирует на уровне ADC точное количество соединений, которое backend-сервис способен нести одновременно. При достижении лимита новые соединения подпадают под поведение очереди или поток отклонения.

maxConnRate контролирует connection storm в секунду

maxConnRate ограничивает количество новых TCP-соединений, которые могут открываться в секунду, по умолчанию 10 000. В отличие от общего числа соединений, это поле управляет скоростью открытия соединений. Оно помогает предотвратить захлёстывание backend за один burst во время connection storm, агрессивного сканирования или некорректно работающих нагрузочных тестов. Это критический контроль burst-защиты для публично доступных сервисов.

maxSessRate отдельно отслеживает интенсивность новых HTTP-сессий

maxSessRate применяет потолок в секунду к новым сессиям, по умолчанию 10 000. Повторное использование keep-alive соединений и постоянное открытие новых сессий несут разные затраты. Это различие особенно полезно против cookie-based session-opening storm или поведения ботов, исчерпывающих сессии приложения. Трафик ограничивается не только числом соединений, но и скоростью создания сессий.

rateLimitSessions ограничивает новые слоты соединений с гранулярностью по секундам

rateLimitSessions предоставляет отдельный per-second контроль для выделения новых слотов соединений, по умолчанию 5 000. Используется для более тонкого управления поведением принятия новых соединений. Помогает пулу продвигаться с контролируемой ёмкостью при внезапных всплесках соединений. Соотношение между ёмкостью backend-сервиса и скоростью принятия ADC настраивается точнее.

maxSslConn отделяет активные TLS-соединения от обычных

maxSslConn определяет отдельный лимит одновременных соединений для активных SSL/TLS-соединений, по умолчанию 5 000. TLS-соединения необходимо рассматривать иначе, чем обычные, из-за стоимости CPU, памяти и криптографической обработки. Этот лимит точнее отражает реальную ёмкость backend-сервиса на стороне TLS. Упрощает планирование SSL-ёмкости, особенно для публичного web- и API-трафика.

maxSslRate удерживает нагрузку TLS-handshake в секунду под контролем

maxSslRate ограничивает количество SSL/TLS-handshake, которые могут инициироваться в секунду, по умолчанию 2 000. Операции handshake могут нести высокую стоимость в зависимости от использования RSA или ECDSA, размера ключа и мощности CPU. Это поле помогает предотвратить исчерпание CPU backend-сервиса от TLS handshake storm. Обеспечивает более значимую защиту, чем лимит обычных соединений, при DDoS или агрессивном трафике ботов.

maxBufferSize ограничивает потребление памяти на соединение

maxBufferSize устанавливает доступный размер буфера на соединение в КБ, по умолчанию 128 КБ с диапазоном 16–256 КБ. Потребление памяти контролируется этим значением для медленных клиентов, медленных читателей или запросов с большими телами. Поле обеспечивает операционную защиту от Slowloris-подобного поведения и давления на память.

maxRetries настраивает поведение повторных попыток при временных сбоях соединения

maxRetries определяет, сколько раз повторяется попытка соединения с backend при сбое, по умолчанию 3 с верхним пределом 1 000. Низкое значение обеспечивает быстрый возврат ошибки; высокое может улучшить устойчивость при временных сетевых сбоях. Однако избыточные retry могут создавать нагрузку на уже испытывающий затруднения backend и должны выбираться с осторожностью.

Привязка профиль–пул делает политику ёмкости централизованно управляемой

Профиль лимитов определяется с уникальным именем и может назначаться нескольким пулам. Редактирование одного профиля изменяет поведение соединений всех привязанных к нему пулов. Эта модель снижает необходимость настройки каждого пула сервисов индивидуально. Production, test, campaign или профили конкретных тенантов можно управлять независимо.

Поведение очереди производит видимые ошибки вместо молчаливого сброса

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

Операционная глубина

Лимиты соединений пула должны планироваться вместе с дефолтными значениями, поведением при отключении нулём, генерацией global/frontend/pool и бюджетом памяти.

Дефолтные значения профиля

Дефолтная модель использует maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K и maxBufferSize 128 КБ. Это начальные точки. Реальная настройка должна выполняться в соответствии с ёмкостью backend-сервиса, стоимостью TLS и паттерном трафика.

Отключение нулём

Все поля лимитов принимают 0 в качестве минимального значения. Это можно использовать для сценариев, где данный контроль должен быть отключён или вести себя как неограниченный. Однако в production значение 0 должно устанавливаться намеренно — иначе ожидаемая защита снимается.

Верхний предел для высокой плотности

maxConn можно установить до 1 000 000. Это обеспечивает гибкость для сценариев с очень высокой плотностью keep-alive или connection pool. Тем не менее реальная ёмкость определяется не только этим числом — файловые дескрипторы, память, CPU, стоимость TLS и лимиты backend-сервиса должны учитываться совокупно.

Бюджет буферной памяти

maxBufferSize напрямую влияет на потребление памяти на соединение. Низкое значение увеличивает защиту памяти, но может создавать проблемы совместимости для приложений с большими телами или медленными потоками. Диапазон 16–256 КБ позволяет контролируемо балансировать между безопасностью и нуждами приложения.

Многоуровневая генерация лимитов

Значения профиля отражаются на поведении соединений на global, frontend и pool уровнях. Это разделение позволяет независимо управлять общей ёмкостью устройства и ёмкостью конкретного пула. В крупных развёртываниях общая ёмкость ADC и ёмкость одного пула не должны смешиваться.

Лимиты SSL bind

Лимиты SSL-соединений связаны с поведением TLS bind. Значения такие как maxSslConn позволяют управлять TLS-соединениями отдельно от обычных. Это важно для защиты бюджета CPU в публично доступных сервисах с интенсивным TLS-трафиком.

Когда применять

Временный профиль ёмкости в дни e-commerce кампаний

E-commerce платформа, работающая с профилем 20K соединений в обычные дни, может переключиться на профиль с более высоким числом соединений в период кампании. Тот же пул сохраняется; меняется только профиль лимитов для подготовки к трафику кампании.

Разделение SSL-ёмкости во внутреннем API-трафике банка

Банк может разрешить высокое общее число соединений на своём пуле внутренних API, сохраняя более узкий лимит скорости SSL-соединений и handshake. Эта структура контролирует стоимость TLS и защищает CPU backend-сервиса от внезапной handshake-нагрузки.

Защита от connection storm на публичных web-сервисах

В интернет-доступном веб-приложении сканирование ботами или некорректно работающие клиенты могут открывать большое количество соединений за короткое время. TR7 ограничивает скорость новых соединений через maxConnRate и rateLimitSessions, защищая backend от connection storm.

Ограничение потребления памяти при трафике медленных клиентов

Медленно читающие клиенты могут увеличивать использование буфера на соединение. TR7 ограничивает потребление памяти этим трафиком с помощью профиля с низким maxBufferSize, позволяя другим пользователям продолжать получать обслуживание.

Часто задаваемые вопросы

В чём разница между maxConn и maxConnRate?

maxConn — это потолок ёмкости, максимальное количество соединений, которые могут быть одновременно открыты на пуле. maxConnRate — это контроль скорости, максимальное количество новых TCP-соединений, которые могут открываться в секунду. Первое защищает от перегрузки из-за накопленных соединений; второе защищает от connection storm и burst-атак.

Почему лимиты SSL-соединений определяются отдельно от лимитов обычных соединений?

Операции TLS-handshake дорогостоящи по CPU по сравнению с обычными соединениями. Управление ими в рамках того же лимита, что и обычные HTTP-соединения, делает реальную нагрузку невидимой. maxSslConn и maxSslRate дают независимый контроль над TLS-стороной, что особенно важно для публичного web- и API-трафика, где бюджет CPU ограничен.

Что происходит при превышении лимита соединений?

При превышении лимита новые соединения могут ждать в очереди до настраиваемой глубины. Когда очередь заполняется, клиент получает чёткий сигнал ошибки вместо молчаливого сброса. Это делает события ёмкости видимыми для операционной команды через метрики и явные сигналы ошибок, например 503.

Можно ли использовать один профиль лимитов на нескольких пулах?

Да. Профиль определяется с уникальным именем и может быть привязан к любому количеству пулов. Централизованное обновление профиля применяет изменение ко всем привязанным пулам. Эта модель снижает ручные усилия по настройке в крупных развёртываниях с множеством пулов сервисов.

Что означает установка поля лимита в 0?

Значение 0 отключает соответствующий контроль или заставляет его вести себя как неограниченный. Это полезно в конкретных сценариях, где лимит намеренно не применяется. В production-окружениях значение 0 должно устанавливаться намеренно — иначе защита, которая считалась активной, молча снимается.

Как следует настраивать maxBufferSize для больших тел запросов?

maxBufferSize управляет буферной памятью на соединение и варьируется от 16 КБ до 256 КБ, по умолчанию 128 КБ. Приложениям с большими телами запросов, например загрузка файлов или тяжёлые POST-нагрузки, может потребоваться более высокое значение. Приложениям, требующим защиты от давления памяти медленных клиентов, может быть полезно более низкое значение. Правильная настройка зависит от конкретного паттерна трафика и поведения backend-сервиса.

Защищайте ёмкость backend-сервиса точно — не одним числом

8-осевые профили лимитов соединений для connection storm, TLS-нагрузки и давления памяти медленных клиентов. Давайте разберём живую настройку на ваших собственных сервисах.