No modelo clássico de conexão, um grande número de clientes se traduz em um número igualmente grande de conexões TCP ou TLS no lado do backend. Cada nova conexão traz um handshake TCP de três vias, um handshake TLS, gerenciamento de socket e um custo de teardown. À medida que o tráfego cresce, os backends passam mais tempo com overhead de conexão do que com lógica real de aplicação.
Requisições de API curtas e frequentes tornam o problema mais visível. Aplicações móveis, chamadas B2B, microsserviços e fluxos de checkout geram muitas requisições pequenas. Quando cada requisição se torna uma nova conexão, CPU, memória, sockets e recursos de rede são consumidos desnecessariamente.
O comportamento HTTP/1.1 no frontend adiciona outra restrição. Uma requisição lenta em uma determinada conexão pode bloquear as outras atrás dela; a capacidade de stream paralelo é limitada. O tráfego de clientes modernos se move mais eficientemente com HTTP/2 e HTTP/3, e o gerenciamento de conexões de backend deve acompanhar esse ritmo.
A abordagem correta não é espelhar conexões de cliente um-a-um nos backends. É fazer pool e reutilizar conexões, e ajustar o comportamento de multiplexação por tipo de serviço. Operações não idempotentes exigem modos de reuso mais seguros; APIs de alto volume se beneficiam de modos mais agressivos.
A Multiplexação de Conexão do TR7 entrega esse modelo: multiplexação moderna de streams no frontend, um pool keepalive no backend e uma política gerenciável de reuso de conexão por serviço.
O TR7 implementa multiplexação de conexão por meio de um pool keepalive de backend, um modo de reuso por serviço, suporte a protocolos HTTP/2 e HTTP/3 e retomada de sessão TLS.
Conexões abertas para o backend não são fechadas imediatamente quando uma requisição é concluída — elas retornam ao pool para reuso. Isso reduz o overhead de handshake TCP e TLS no lado do backend.
O reuso de conexão pode ser gerenciado por meio de quatro modos: never, safe, aggressive e always. Os operadores selecionam o comportamento adequado para cada serviço equilibrando requisitos de segurança, restrições de idempotência e metas de throughput.
Com HTTP/2 ALPN, múltiplos streams paralelos são transportados sobre uma única conexão. Isso é especialmente eficaz para grande volume de requisições de API curtas, melhorando a eficiência de conexão do lado do cliente.
A retomada de sessão TLS permite que clientes recorrentes pulem o handshake completo. Em serviços com TLS intenso, isso reduz o consumo de CPU e a latência de estabelecimento de conexão.
A Multiplexação de Conexão reduz o overhead de conexões de backend por meio de reuso por serviço, keepalive, HTTP/2, HTTP/3 e perfis de timeout.
O TR7 gerencia o reuso de conexão como uma ação em nível de pool. O modo never se comporta próximo a um modelo de nova conexão por requisição. safe oferece reuso mais controlado. aggressive e always visam economias de conexão mais pesadas para serviços de alto volume. Os operadores escolhem o modo que reflete as necessidades de performance e segurança de cada serviço.
Com keepalive habilitado no lado do backend, as conexões retornam ao pool quando uma requisição é concluída. A próxima requisição usa uma conexão já disponível em vez de abrir uma nova. Isso reduz significativamente o custo de setup de conexão para requisições curtas e proporciona aos backends um perfil de conexão mais estável e previsível.
O TR7 suporta HTTP/2 ALPN no lado do cliente, transportando múltiplos streams sobre uma única conexão. Isso reduz o número de conexões que browsers e clientes móveis precisam abrir. A latência e o consumo de recursos se tornam mais previsíveis. O suporte a HTTP/2 é a camada base de performance para tráfego moderno de web e API.
O HTTP/2 no lado do backend é opt-in em nível de serviço. Quando um backend suporta HTTP/2, o ALPN negocia h2 ou http/1.1 de acordo. Serviços que não suportam HTTP/2 fazem fallback para HTTP/1.1 automaticamente. Isso permite que backends modernos se beneficiem do HTTP/2 sem quebrar serviços legados.
O TR7 transporta tráfego moderno de clientes via HTTP/3/QUIC no frontend. Em redes móveis e com perda de pacotes, o setup de conexão e a continuidade de stream melhoram. O fallback para HTTP/2 preserva a compatibilidade retroativa. O lado do backend é gerenciado de forma independente com base em suas próprias capacidades de protocolo.
O modo de reuso safe aplica comportamento mais conservador para operações arriscadas ou não idempotentes. Em APIs de bancário, pagamento ou com muitas escritas, a otimização de performance não deve ter custo sobre a integridade dos dados. Esse modo mantém o reuso dentro de limites seguros. Os operadores podem selecionar safe em vez de aggressive para serviços de alta sensibilidade.
O reuso de sessão TLS permite que o mesmo cliente se reconecte sem repetir o handshake completo. Os mecanismos de session tickets TLS 1.2 e PSK TLS 1.3 suportam esse comportamento. Sob tráfego HTTPS intenso, o uso de CPU do ADC é significativamente reduzido. Isso é especialmente valioso em cenários móveis e de API com muitas conexões de vida curta.
Os valores de timeout de HTTP keepalive, client-fin, server-fin, tunnel, connect, server, client e queue moldam como o pool de conexões se comporta. Timeouts muito curtos esgotam o pool e reduzem o reuso. Timeouts muito longos aumentam a contagem de conexões idle e o consumo de memória. O TR7 torna esse equilíbrio gerenciável por perfil de serviço.
Os limites de conexão podem ser definidos em nível de pool e de backend. Esses limites ajudam a proteger os serviços de backend de bursts repentinos de conexão. São especialmente importantes para aplicações com capacidade de conexão menor ou licenciada. Quando combinados com multiplexação de conexão, os limites maxconn fornecem comportamento de capacidade mais previsível.
A taxa de novas conexões por segundo pode ser limitada por um teto. Isso evita que os serviços de backend sejam sobrecarregados por ondas de bots, tempestades de reconexão de clientes móveis ou picos repentinos de tráfego. O pool keepalive gerencia o reuso enquanto a taxa de novas conexões é gerenciada separadamente. As equipes de operações podem restringir o comportamento de conexão não apenas pela contagem total, mas também pela taxa.
Os sinais de TCP keepalive nos lados do cliente e do backend podem evitar que dispositivos de rede intermediários fechem silenciosamente conexões idle. Conexões de longa duração são vulneráveis a timeouts de firewall e NAT. O keepalive ajuda a manter essas conexões. Isso é mais relevante para serviços com sessões longas ou tráfego de baixa frequência.
Quando a configuração muda, as conexões existentes são drenadas enquanto novas conexões são aceitas pelo novo worker com a configuração atualizada. Isso evita interrupção abrupta dos pools de conexão. Os operadores podem alterar valores de timeout, modos de reuso ou configurações de ALPN preservando a continuidade do serviço. Mudanças em produção têm menor risco operacional.
A multiplexação de conexão é operada junto com equilíbrio de timeout de keepalive, comportamento de drain, dimensionamento de cache TLS, concorrência de streams, bridging de protocolo e métricas de monitoramento.
Se o timeout de keepalive for muito curto, as conexões fecham antes de poderem ser reutilizadas e a utilização do pool cai. Se for muito longo, a contagem de conexões idle cresce e o consumo de memória aumenta. O valor deve ser ajustado para corresponder à densidade de tráfego e à capacidade do backend.
Durante um soft reload, o worker antigo drena as conexões existentes de forma controlada enquanto o novo worker aceita conexões com a nova configuração. Isso é crítico para mudanças sem interrupção em serviços que dependem de multiplexação de conexão. A duração do drain deve ser planejada separadamente para conexões de longa duração.
O tamanho do cache de sessão TLS importa para clientes que se reconectam frequentemente sob tráfego HTTPS intenso. Um cache muito pequeno reduz a taxa de retomada. Um cache muito grande precisa ser contabilizado no planejamento de memória.
O TCP keepalive em nível de SO sinaliza para camadas intermediárias que a conexão ainda está ativa. Isso reduz a chance de que dispositivos NAT, firewalls ou appliances de segurança stateful fechem conexões idle prematuramente. A configuração é mais valiosa para conexões de longa duração.
O número de streams paralelos sobre uma única conexão HTTP/2 pode ser limitado. Um valor muito baixo reduz o benefício da multiplexação; um valor muito alto corre o risco de sobrecarregar uma única conexão. A configuração correta depende do mix de tráfego.
Quando o lado do cliente usa HTTP/2 mas o backend executa HTTP/1.1, o comportamento de stream no lado do backend não espelha o mesmo paralelismo. Algumas requisições podem ser serializadas de acordo com o modelo de conexão do backend. Se o backend suporta HTTP/2, habilitar o toggle relevante deve ser considerado.
Quando o TLS é terminado pelo TR7 em vez do backend, a carga de handshake TLS do backend desaparece. O ADC assume o custo de processamento TLS no lugar. A retomada de sessão TLS e o pool de conexões juntos ajudam a compensar esse custo.
Totais de requisições, profundidade de fila, contagem de conexões, comportamento de reuso e métricas de erro refletem a saúde do pool de conexões. Baixo reuso justifica uma revisão das configurações de timeout ou do comportamento do backend. Uma fila crescente sinaliza que a capacidade de conexão do backend ou os limites maxconn podem precisar de ajuste.
APIs SaaS geram volumes de requisições curtos e densos. A multiplexação de conexão reduz o número de conexões de backend e elimina o custo repetido de estabelecimento TCP/TLS.
Clientes móveis abrem e fecham conexões com frequência. Keepalive, HTTP/2 e retomada TLS reduzem o custo de reconexão do lado do cliente.
Para backends que suportam HTTP/2, o toggle ALPN pode ser habilitado para avaliar a multiplexação de streams. Isso gera uso de conexão mais eficiente em chamadas inter-serviço de alta frequência.
Tráfego de borda ou de clientes denso pode usar um pool de conexões existentes para o backend de origem em vez de abrir novas conexões continuamente. Isso reduz a pressão de CPU e sockets na origem.
Para operações financeiras não idempotentes, o modo safe é preferido ao reuso agressivo. Isso busca ganhos de performance preservando a integridade das transações.
Serviços B2B frequentemente carregam requisições de alto valor e baixa frequência que ainda incorrem em custo significativo de TLS. Um pool de conexões e retomada de sessão reduzem o overhead de estabelecimento de conexão segura.
Pool keepalive, modos http-reuse, HTTP/2, HTTP/3 e retomada de sessão TLS — toda a otimização de conexão em uma única política ADC. Vamos fazer uma configuração ao vivo nos seus próprios serviços.