Na maioria dos designs de balanceamento de carga, o limite de conexão é tratado como um único campo: quantas conexões podem estar abertas ao mesmo tempo? Esse modelo é incompleto. Dez mil conexões keep-alive pendentes podem ser baratas, enquanto 1.000 novos handshakes SSL simultâneos podem exaurir rapidamente a CPU do backend. O mesmo número produz custos completamente diferentes dependendo do tipo de tráfego.
Contagem de conexões e taxa de conexão também não são a mesma coisa. "Até 20.000 conexões podem estar abertas ao mesmo tempo" é um teto de capacidade; "até 10.000 novas conexões podem ser abertas por segundo" é controle de burst e tempestade de conexão. Sistemas que não separam esses dois valores ou restringem desnecessariamente o tráfego legítimo de usuários ou não conseguem proteger o backend de uma onda de ataque repentina.
O tráfego TLS deve ser considerado separadamente. As operações de handshake SSL/TLS são dispendiosas em termos de CPU e, quando gerenciadas sob o mesmo limite que as conexões HTTP plain, a carga real fica invisível. Especialmente durante tráfego de web pública, gateway de API e períodos de campanha, limitar independentemente a taxa de handshake mantém o consumo de CPU do backend sob controle.
O comportamento da fila também costuma ser opaco. Quando um limite é excedido, a conexão é descartada silenciosamente, gera timeout, aguarda em fila ou o cliente recebe um 503 claro? Sem visibilidade desse comportamento, a causa raiz não fica clara no momento do incidente — os usuários veem um timeout e a equipe de operações identifica a razão real tarde demais.
Os Limites de Conexão do Pool do TR7 protegem os serviços de backend por meio de gerenciamento previsível de capacidade em vez de sobrecarga silenciosa, controlando independentemente o total de conexões, a taxa de conexão, a taxa de sessão, a carga SSL, o orçamento de buffer e o comportamento de retry.
O TR7 gerencia a capacidade do pool não com um único campo, mas com uma estrutura de perfil construída nos eixos de conexão, taxa, SSL, retry e buffer.
Um único perfil define maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate e maxBufferSize. Isso permite que os limites de conexão, taxa, TLS e memória do backend sejam ajustados de forma independente.
Como os handshakes TLS são dispendiosos em termos de CPU, o TR7 gerencia maxSslConn e maxSslRate como valores distintos. Essa separação ajuda a evitar que uma tempestade de handshakes esgote o backend mesmo quando a contagem total de conexões parece baixa.
Um perfil de limite é definido com um nome único e pode ser atribuído a diferentes pools de serviço. Políticas de capacidade para produção, staging, canary ou por tenant podem ser gerenciadas com um único modelo de perfil.
maxRetries define quantas vezes uma conexão ao backend é retentada em caso de falha transitória. maxBufferSize controla o consumo de memória por conexão em cenários de cliente lento ou backend lento.
Os Limites de Conexão do Pool do TR7 restringem os serviços de backend de forma controlada contra tempestades de conexão, carga TLS, bursts de sessão e pressão de memória.
maxConn define o teto para conexões abertas simultaneamente por pool, com padrão de 20.000 e limite superior de 1.000.000. Esse valor codifica na camada ADC exatamente quantas conexões o backend pode carregar ao mesmo tempo. Quando o limite é atingido, novas conexões ficam sujeitas ao comportamento de fila ou a um fluxo de rejeição.
maxConnRate limita o número de novas conexões TCP que podem ser abertas por segundo, com padrão de 10.000. Ao contrário do total de conexões, este campo governa a taxa em que as conexões são abertas. Ele ajuda a evitar que o backend seja sobrecarregado em um único burst durante tempestades de conexão, varreduras agressivas ou testes de carga com comportamento inadequado. É um controle crítico de proteção contra burst para serviços voltados ao público.
maxSessRate aplica um teto por segundo para novas sessões, com padrão de 10.000. Reutilizar conexões keep-alive e abrir novas sessões repetidamente têm custos diferentes. Essa distinção é útil especialmente contra tempestades de abertura de sessão baseadas em cookie ou comportamento de bots que esgotam sessões da aplicação. O tráfego é restringido não apenas pela contagem de conexões, mas também pela taxa de produção de sessões.
rateLimitSessions fornece um controle separado por segundo para alocação de novos slots de conexão, com padrão de 5.000. É usado para gerenciar o comportamento de aceitação de novas conexões com maior granularidade. Ajuda o pool a avançar com capacidade controlada durante bursts repentinos de conexão. A relação entre a capacidade do backend e a taxa de aceitação do ADC é ajustada com mais precisão.
maxSslConn define um limite separado de conexões simultâneas para conexões SSL/TLS ativas, com padrão de 5.000. As conexões TLS devem ser tratadas de forma diferente das conexões plain por causa do custo de CPU, memória e processamento criptográfico. Esse limite reflete com mais precisão a capacidade real do backend no lado TLS. Simplifica o planejamento de capacidade SSL, especialmente para tráfego de web pública e API.
maxSslRate limita o número de handshakes SSL/TLS que podem ser iniciados por segundo, com padrão de 2.000. As operações de handshake podem ter custo elevado dependendo do uso de RSA ou ECDSA, do tamanho da chave e da capacidade da CPU. Este campo ajuda a evitar que tempestades de handshake TLS esgotem a CPU do backend. Proporciona proteção mais significativa que um limite de conexão plain durante DDoS ou tráfego agressivo de bots.
maxBufferSize define o tamanho do buffer disponível por conexão em KB, com padrão de 128 KB e intervalo de 16–256 KB. O consumo de memória é controlado por este valor para clientes lentos, leitores lentos ou requisições com bodies grandes. O campo oferece proteção operacional contra comportamentos similares ao Slowloris e pressão de memória.
maxRetries define quantas vezes a conexão ao backend é retentada em caso de falha, com padrão de 3 e limite superior de 1.000. Um valor menor proporciona retorno rápido de erro; um valor maior pode melhorar a resiliência durante instabilidades transitórias de rede. No entanto, retries excessivos podem adicionar carga a um backend já sobrecarregado e devem ser escolhidos com cuidado.
Um perfil de limite é definido com um nome único e pode ser atribuído a múltiplos pools. Editar um único perfil altera o comportamento de conexão de todos os pools vinculados a ele. Esse modelo reduz a necessidade de configurar cada pool de serviço individualmente. Perfis de produção, teste, campanha ou por tenant podem ser gerenciados de forma independente.
Quando um limite é excedido, as conexões podem aguardar em fila até uma profundidade definida. Quando a fila fica cheia, o cliente recebe um erro claro em vez de um timeout silencioso. As equipes de operações podem identificar quando um teto de capacidade é atingido mais rapidamente por meio de sinais de erro explícitos como 503. O problema se torna um evento de capacidade mensurável em vez de uma espera ambígua do lado do usuário.
Os limites de conexão do pool devem ser planejados em conjunto com valores padrão, comportamento de desativação por zero, geração global/frontend/pool e orçamento de memória.
O modelo padrão usa maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K e maxBufferSize 128 KB. Esses são pontos de partida. O ajuste real deve ser feito de acordo com a capacidade do backend, o custo de TLS e o padrão de tráfego.
Todos os campos de limite aceitam 0 como valor mínimo. Isso pode ser usado em cenários onde um controle específico deve ser desativado ou se comportar como ilimitado. Em produção, no entanto, um valor de 0 deve ser definido deliberadamente — caso contrário, a proteção esperada é removida.
maxConn pode ser definido até 1.000.000. Isso proporciona flexibilidade para cenários de keep-alive de muito alta densidade ou de pool de conexões. Mesmo assim, a capacidade real não é determinada apenas por esse número — descritores de arquivo, memória, CPU, custo de TLS e limites do backend devem ser todos considerados juntos.
maxBufferSize afeta diretamente o consumo de memória por conexão. Um valor menor aumenta a proteção de memória, mas pode introduzir problemas de compatibilidade para aplicações com bodies grandes ou streams lentos. O intervalo de 16–256 KB permite uma troca controlada entre segurança e necessidades da aplicação.
Os valores do perfil são refletidos nos comportamentos de conexão em nível global, frontend e pool. Essa separação permite que a capacidade geral do dispositivo e a capacidade de um pool específico sejam gerenciadas de forma independente. Em implantações grandes, a capacidade total do ADC e a capacidade de um único pool não devem ser confundidas.
Os limites de conexão SSL estão vinculados ao comportamento de bind TLS. Valores como maxSslConn permitem que as conexões TLS sejam gerenciadas separadamente das conexões plain. Isso é importante para proteger o orçamento de CPU em serviços voltados ao público onde o tráfego TLS é intenso.
Uma plataforma de e-commerce com perfil de 20K conexões em dias normais pode mudar para um perfil de maior capacidade durante um período de campanha. O mesmo pool é mantido; apenas o perfil de limite é alterado para preparar o tráfego da campanha.
Um banco pode permitir um alto total de conexões em seu pool de API interna enquanto mantém a taxa de conexão e handshake SSL mais restrita. Essa estrutura controla o custo de TLS e protege a CPU do backend de carga repentina de handshakes.
Em uma aplicação web voltada para a internet, varreduras de bots ou clientes com comportamento inadequado podem abrir grande número de conexões em pouco tempo. O TR7 limita a taxa de novas conexões via maxConnRate e rateLimitSessions, protegendo o backend de uma tempestade de conexão.
Clientes com leitura lenta podem aumentar o uso de buffer por conexão. O TR7 restringe o consumo de memória desse tráfego com um perfil de maxBufferSize menor, permitindo que outros usuários continuem recebendo o serviço.
Perfis de limite de conexão em 8 eixos para tempestades de conexão, carga TLS e pressão de memória por clientes lentos. Vamos fazer uma configuração ao vivo nos seus próprios serviços.