En la mayoría de los diseños de balanceo de carga, el límite de conexión se trata como un único campo: ¿cuántas conexiones pueden estar abiertas a la vez? Ese modelo es incompleto. Diez mil conexiones keep-alive pendientes pueden ser baratas, mientras que 1.000 nuevos handshakes SSL simultáneos pueden agotar rápidamente la CPU del backend. El mismo número produce un coste completamente diferente según el tipo de tráfico.
El recuento de conexiones y la tasa de conexiones tampoco son lo mismo. «Hasta 20.000 conexiones pueden estar abiertas a la vez» es un techo de capacidad; «hasta 10.000 nuevas conexiones pueden abrirse por segundo» es control de bursts y tormentas de conexiones. Los sistemas que no separan estos dos valores o restringen innecesariamente el tráfico legítimo o no protegen el backend de una ola de ataque repentina.
El tráfico TLS debe considerarse por separado. Las operaciones de handshake SSL/TLS son costosas en términos de CPU, y cuando se gestionan bajo el mismo límite que las conexiones HTTP plain, la carga real se vuelve invisible. Especialmente durante el tráfico de web pública, API gateway y períodos de campaña, limitar de forma independiente la tasa de handshake mantiene bajo control el consumo de CPU del backend.
El comportamiento de cola también suele ser opaco. Cuando se supera un límite, ¿la conexión se descarta silenciosamente, agota el tiempo de espera, espera en una cola, o el cliente recibe un 503 limpio? Sin visibilidad sobre ese comportamiento, la causa raíz no está clara en el momento del incidente — los usuarios ven un timeout y el equipo de operaciones identifica la razón real demasiado tarde.
TR7 Pool Connection Limits protege los servicios backend mediante una gestión de capacidad predecible en lugar de sobrecarga silenciosa, controlando de forma independiente las conexiones totales, la tasa de conexión, la tasa de sesión, la carga SSL, el presupuesto de buffer y el comportamiento de retry.
TR7 gestiona la capacidad del pool no con un único campo sino con una estructura de perfil construida sobre ejes de conexión, tasa, SSL, retry y buffer.
Un único perfil define maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate y maxBufferSize. Esto permite que los límites de conexión, tasa, TLS y memoria del backend se ajusten de forma independiente.
Dado que los handshakes TLS son costosos en CPU, TR7 gestiona maxSslConn y maxSslRate como valores distintos. Esta separación ayuda a evitar que una tormenta de handshakes agote el backend incluso cuando el recuento total de conexiones parece bajo.
Un perfil de límites se define con un nombre único y puede adjuntarse a diferentes pools de servicio. Las políticas de capacidad de producción, staging, canary o por tenant se pueden gestionar todas con un único modelo de perfil.
maxRetries define cuántas veces se reintenta una conexión al backend ante un fallo transitorio. maxBufferSize controla el consumo de memoria por conexión en escenarios de cliente lento o backend lento.
TR7 Pool Connection Limits restringe los servicios backend de forma controlada frente a tormentas de conexiones, carga TLS, ráfagas de sesiones y presión de memoria.
maxConn establece el techo para las conexiones abiertas simultáneamente por pool, con un valor predeterminado de 20.000 y un límite superior de 1.000.000. Este valor codifica en la capa ADC exactamente cuántas conexiones puede transportar el backend a la vez. Cuando se alcanza el límite, las nuevas conexiones quedan sujetas al comportamiento de cola o a un flujo de rechazo.
maxConnRate limita el número de nuevas conexiones TCP que pueden abrirse por segundo, con un valor predeterminado de 10.000. A diferencia de las conexiones totales, este campo gobierna la tasa a la que se abren las conexiones. Ayuda a evitar que el backend se vea desbordado en un único burst durante tormentas de conexiones, escaneos agresivos o pruebas de carga con mal comportamiento. Es un control crítico de protección contra bursts para los servicios orientados al público.
maxSessRate aplica un techo por segundo a las nuevas sesiones, con un valor predeterminado de 10.000. Reutilizar conexiones keep-alive y abrir nuevas sesiones repetidamente tienen costes diferentes. Esta distinción es útil especialmente frente a tormentas de apertura de sesiones basadas en cookies o comportamiento de bots que agota las sesiones de la aplicación. El tráfico se restringe no solo por recuento de conexiones sino también por la tasa a la que se producen las sesiones.
rateLimitSessions proporciona un control por segundo independiente para la asignación de nuevos slots de conexión, con un valor predeterminado de 5.000. Se usa para gestionar el comportamiento de aceptación de nuevas conexiones con mayor granularidad. Ayuda al pool a avanzar con una capacidad controlada durante ráfagas repentinas de conexiones. La relación entre la capacidad del backend y la tasa de aceptación del ADC se ajusta con mayor precisión.
maxSslConn define un límite de conexiones simultáneas separado para las conexiones SSL/TLS activas, con un valor predeterminado de 5.000. Las conexiones TLS deben tratarse de forma diferente a las conexiones plain debido al coste de CPU, memoria y procesamiento criptográfico. Este límite refleja con mayor precisión la capacidad real del backend en el lado TLS. Simplifica la planificación de capacidad SSL, especialmente para el tráfico web público y de API.
maxSslRate limita el número de handshakes SSL/TLS que pueden iniciarse por segundo, con un valor predeterminado de 2.000. Las operaciones de handshake pueden tener un coste elevado según el uso de RSA o ECDSA, el tamaño de clave y la capacidad de CPU. Este campo ayuda a evitar que las tormentas de handshakes TLS agoten la CPU del backend. Proporciona una protección más significativa que un límite de conexiones plain durante ataques DDoS o tráfico agresivo de bots.
maxBufferSize establece el tamaño de buffer disponible por conexión en KB, con un valor predeterminado de 128 KB y un rango de 16–256 KB. El consumo de memoria se controla mediante este valor para clientes lentos, lectores lentos o solicitudes que transportan cuerpos de gran tamaño. El campo proporciona protección operacional frente al comportamiento tipo Slowloris y la presión de memoria.
maxRetries define cuántas veces se reintenta la conexión al backend ante un fallo, con un valor predeterminado de 3 y un límite superior de 1.000. Un valor más bajo proporciona retorno de error rápido; un valor más alto puede mejorar la resiliencia durante perturbaciones transitorias de la red. Sin embargo, los reintentos excesivos pueden añadir carga a un backend ya sobrecargado y deben elegirse con cuidado.
Un perfil de límites se define con un nombre único y puede asignarse a múltiples pools. Editar un único perfil cambia el comportamiento de conexión de todos los pools vinculados a él. Este modelo reduce la necesidad de configurar cada pool de servicio individualmente. Los perfiles de producción, prueba, campaña o por tenant se pueden gestionar cada uno de forma independiente.
Cuando se supera un límite, las conexiones pueden esperar en una cola hasta una profundidad definida. Cuando la cola se llena, el cliente recibe un error claro en lugar de un timeout silencioso. Los equipos de operaciones pueden identificar cuándo se alcanza un techo de capacidad más rápidamente a través de señales de error explícitas como 503. El problema se convierte en un evento de capacidad medible en lugar de una espera ambigua en el lado del usuario.
Los límites de conexión de pool deben planificarse junto con los valores predeterminados, el comportamiento de desactivación con cero, la generación global/frontend/pool y el presupuesto de memoria.
El modelo predeterminado usa maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K y maxBufferSize 128 KB. Estos son puntos de partida. El ajuste real debe realizarse según la capacidad del backend, el coste TLS y el patrón de tráfico.
Todos los campos de límites aceptan 0 como valor mínimo. Esto puede usarse para escenarios donde un control dado debe desactivarse o comportarse como ilimitado. En producción, sin embargo, un valor de 0 debe establecerse de forma deliberada — de lo contrario, la protección esperada se elimina.
maxConn puede establecerse hasta 1.000.000. Esto proporciona flexibilidad para escenarios de keep-alive de muy alta densidad o pools de conexiones. Aún así, la capacidad real no está determinada solo por este número — los descriptores de archivo, la memoria, la CPU, el coste TLS y los límites del backend deben tenerse en cuenta todos juntos.
maxBufferSize afecta directamente al consumo de memoria por conexión. Un valor más bajo aumenta la protección de memoria, pero puede introducir problemas de compatibilidad para aplicaciones con cuerpos de gran tamaño o flujos lentos. El rango de 16–256 KB permite un equilibrio controlado entre seguridad y necesidades de la aplicación.
Los valores del perfil se reflejan en el comportamiento de conexión a nivel global, frontend y pool. Esta separación permite gestionar de forma independiente la capacidad total del dispositivo y la capacidad de un pool específico. En despliegues grandes, la capacidad total del ADC y la capacidad de un único pool no deben confundirse.
Los límites de conexión SSL están vinculados al comportamiento de bind TLS. Valores como maxSslConn permiten gestionar las conexiones TLS de forma separada a las conexiones plain. Esto es importante para proteger el presupuesto de CPU en los servicios orientados al público donde el tráfico TLS es intenso.
Una plataforma de e-commerce que usa un perfil de 20K conexiones en días normales puede cambiar a un perfil de conexiones más alto durante un período de campaña. El mismo pool se mantiene; solo se cambia el perfil de límites para prepararse para el tráfico de campaña.
Un banco puede permitir un recuento total de conexiones alto en su pool de API interno mientras mantiene más estrecha la tasa de conexión y handshake SSL. Esta estructura controla el coste TLS y protege la CPU del backend de cargas repentinas de handshakes.
En una aplicación web orientada a Internet, el escaneo de bots o clientes con mal comportamiento pueden abrir grandes cantidades de conexiones en poco tiempo. TR7 limita la tasa de nuevas conexiones mediante maxConnRate y rateLimitSessions, protegiendo el backend de una tormenta de conexiones.
Los clientes que leen lentamente pueden aumentar el uso de buffer por conexión. TR7 restringe el consumo de memoria de este tráfico con un perfil maxBufferSize más bajo, permitiendo que otros usuarios sigan recibiendo servicio.
Perfiles de límites de conexión de 8 ejes para tormentas de conexiones, carga TLS y presión de memoria por clientes lentos. Permítanos mostrarle una configuración en vivo sobre sus propios servicios.