Quando um timeout é configurado incorretamente, a falha nem sempre é óbvia. Se um serverTimeout for fixado em 30 segundos, requisições de long-polling retornam 504. Se connectTimeout for muito longo, clientes esperando alcançar um backend fora do ar ficam parados por segundos antes de tentar novamente — desencadeando cascatas de retry. Se tunnelTimeout for muito curto, conexões WebSocket caem sem motivo e os usuários experimentam desconexões fantasmas.
A maioria dos sistemas apresenta configurações de timeout como uma lista plana. Os operadores não conseguem distinguir claramente qual valor controla a fase de requisição HTTP, qual governa o tempo de resposta do backend, qual se aplica a tunnels WebSocket e qual afeta a espera de FIN. O resultado é que todos os valores são definidos muito altos — criando vazamentos de conexão — ou todos definidos muito baixos, cortando tráfego legítimo de usuários.
WebSocket e conexões de longa duração são onde esse problema é mais visível. O HTTP keepalive é significativo no intervalo de 30–120 segundos, mas uma sessão WebSocket pode permanecer aberta por horas. Sem um tunnelTimeout gerenciado separadamente, aplicações em tempo real ficam constrangidas pelo comportamento normal de ociosidade HTTP.
O comportamento de teardown TCP também importa. Quando clientFIN e serverFIN não são controlados, conexões half-closed podem esgotar o pool de file descriptors. Em serviços públicos, isso se combina com padrões de ataque de slow-close e se torna um problema de esgotamento de recursos.
Os Perfis de Timeout do TR7 reúnem 9 eixos de timeout independentes em um único perfil nomeado, garantindo que cada pool aplique o comportamento correto de espera, drain e fechamento de conexão para seu tipo de tráfego.
O TR7 gerencia timeouts por meio de perfis nomeados reutilizáveis em vez de dispersar configurações individuais entre pools.
Um operador define um nome de perfil e agrupa 9 valores de timeout dentro dele. O mesmo perfil pode ser vinculado a múltiplos pools, dando a pools web, API ou WebSocket um padrão compartilhado consistente de timeout.
HTTP request, keepalive, connect, server, client, queue, tunnel, clientFIN e serverFIN são cada um gerenciados como um campo distinto. Cada campo é ajustado de acordo com sua própria semântica de tráfego; nenhum valor de timeout é usado como substituto de outro.
Conexões de longa duração como WebSocket e HTTP CONNECT são gerenciadas por meio de tunnelTimeout separadamente. Conexões de chat, live-streaming e event-stream não ficam constrangidas pelo timer de ociosidade HTTP e não fecham desnecessariamente.
Quanto tempo uma conexão é mantida após um sinal de fechamento TCP é configurado independentemente para os lados do cliente e do servidor. Isso reduz o risco de consumo de recursos estilo FIN-WAIT e permite políticas de drain mais agressivas em serviços públicos.
Os Perfis de Timeout permitem que os operadores ajustem o tempo de vida da conexão e o comportamento de espera com precisão em 9 campos independentes para corresponder a cada tipo de tráfego.
httpKeepaliveTimeout define por quanto tempo uma conexão keep-alive HTTP/1.1 permanece aberta entre requisições. O padrão é 120 segundos. Definir muito alto desperdiça recursos em conexões ociosas; muito baixo aumenta o custo de reconexão. É ajustado em relação ao orçamento de conexão ociosa do backend.
httpRequestTimeout é o tempo permitido para o cliente completar a linha de requisição e os headers. O padrão é 30 segundos. Clientes que enviam headers muito lentamente podem ser cortados nesse limite. É um ponto de defesa importante contra padrões estilo slowloris em serviços públicos.
connectTimeout define quanto tempo o TR7 espera ao estabelecer uma conexão TCP com um backend. O padrão é 20 segundos. Se definido muito longo, um backend fora do ar ou inacessível prende clientes desnecessariamente. Cenários de API que requerem respostas rápidas de falha se beneficiam de um connectTimeout menor.
serverTimeout é o tempo permitido para o backend produzir uma resposta. O padrão é 90 segundos. Pode ser definido baixo para APIs rápidas e aumentado para endpoints de relatórios pesados, long-polling ou de query lenta. Um valor incorretamente baixo faz requisições que funcionam mas são lentas receberem 504.
clientTimeout é o tempo de espera para que dados cheguem do cliente. Aplica-se ao upload de corpo de requisição, requisições em pipeline e cenários de cliente lento. O padrão é 90 segundos. Pode ser aumentado para grandes uploads de arquivo e reduzido para diminuir o risco de cliente lento em APIs públicas.
queueTimeout define por quanto tempo uma requisição aguarda na fila do pool quando a capacidade de conexão está cheia. O padrão é 60 segundos. Quando excedido, a requisição é retornada com um erro e o cliente não é mantido indefinidamente. Esse valor deve ser considerado junto com os limites de maxconn e os SLAs da aplicação.
tunnelTimeout define o tempo de ociosidade para conexões WebSocket e de tunnel HTTP CONNECT. O padrão é 120 segundos; para aplicações em tempo real, isso pode ser aumentado para 3.600 segundos ou mais. Como esse timeout é independente do HTTP keepalive, conexões de longa duração não ficam constrangidas pelas configurações de tráfego web. É crítico para aplicações de chat, notificação ao vivo e stream.
clientFIN define por quanto tempo a conexão é mantida após um sinal FIN do cliente. O padrão é 3 segundos. Valores menores impedem que conexões half-closed consumam file descriptors. Isso é especialmente importante em serviços públicos para reduzir a pressão de recursos FIN-WAIT.
serverFIN limita o comportamento de conexão após um sinal FIN do backend. O padrão é 6 segundos. Manter serverFIN mais alto do que clientFIN permite mais tolerância para drain gracioso durante o desligamento do backend. Essa configuração afeta diretamente a qualidade do fechamento de conexão em pools de backend de alto tráfego.
O modelo de vinculação perfil-pool permite que o mesmo padrão de timeout seja compartilhado entre múltiplos pools. Todos os pools web podem apontar para o perfil web, pools de API para o perfil api e pools WebSocket para o perfil websocket. Uma única mudança de perfil atualiza centralmente o comportamento de timeout de todos os pools vinculados a ele, reduzindo duplicação e desvio de configuração.
Os 9 campos de perfil são convertidos para as diretivas de timeout de runtime correspondentes — connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin e server-fin. Os operadores gerenciam os valores por meio do perfil em vez de escrever diretivas individuais, criando uma ponte consistente entre a interface gráfica e o comportamento de runtime.
O tempo de health check é gerenciado por meio de seu próprio campo de timeout e é independente do perfil de timeout de tráfego. Essa separação importa: a latência de probe e o comportamento de espera do tráfego de produção não se misturam. Um health check de backend pode ser mantido curto enquanto o serverTimeout real do endpoint permanece longo, permitindo que a saúde do serviço e o tráfego do usuário sejam monitorados com semânticas diferentes.
Os perfis de timeout são operados em conjunto com seu intervalo de valores, padrões, suporte a decimais, semânticas de tunnel, balanceamento de FIN e modelo de vinculação de pool.
Os campos de timeout são configuráveis de 0 a 60.000 segundos. Esse intervalo abrange desde configurações defensivas de subfração de segundo até sessões superiores a 16 horas, fornecendo flexibilidade suficiente para requisitos de long-poll e conexão persistente.
httpKeepaliveTimeout aceita valores decimais. Um valor como 0,5 segundos permite um comportamento de keepalive ocioso mais preciso. Os outros 8 campos de timeout são tratados como segundos inteiros.
Os valores padrão fornecem um ponto de partida seguro adequado para a maioria do tráfego web e de API. httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 e serverFIN 6 segundos são baselines apropriadas. Para tipos de tráfego especializados, esses valores devem ser ajustados por perfil.
tunnelTimeout se aplica a conexões em tunnel como WebSocket e HTTP CONNECT. Não é o mesmo que o timeout de requisição HTTP ou keepalive. Defini-lo muito baixo em conexões de longa duração produz problemas de desconexão.
No modelo padrão, serverFIN é mais tolerante do que clientFIN. Isso deixa mais espaço para drain gracioso durante o desligamento do backend. Em serviços públicos, ambos os valores podem ser definidos de forma mais agressiva para reduzir o consumo de recursos de conexões half-closed.
O TR7 não impõe presets prontos. Os operadores criam seus próprios perfis nomeados de acordo com seu cenário — web, api, websocket, longpoll ou upload podem ser definidos para corresponder aos padrões da organização. Vincular um pool ao perfil apropriado é preferível a sobrescritas individuais por serviço.
Um perfil web pode ser criado próximo dos valores padrão. O keepalive preserva a experiência do usuário enquanto os valores de timeout de request e FIN limitam conexões lentas ou half-closed. O mesmo perfil pode ser vinculado a múltiplos pools web.
Aplicações de chat precisam que as conexões WebSocket permaneçam abertas sem quedas frequentes. Dentro de um perfil websocket, tunnelTimeout é definido para um valor longo como 3.600 segundos enquanto outros timeouts HTTP permanecem nos padrões. Conexões de longa duração não ficam mais constrangidas pela janela de keepalive HTTP.
Um endpoint de long-polling pode aguardar vários minutos para o backend responder. Definir serverTimeout para 300 segundos em um perfil longpoll suporta uma janela de espera de 5 minutos. Sem isso, um timeout padrão de API corta as requisições muito cedo.
Os dados do cliente podem chegar lentamente durante grandes uploads de corpo POST ou de arquivo. Em um perfil upload, clientTimeout e, se necessário, httpRequestTimeout podem ser aumentados para 600 segundos. Isso impede que operações de upload legítimas mas lentas sejam cortadas.
Quando uma API bancária espera uma resposta rápida do backend, valores apertados como connectTimeout 2 segundos e serverTimeout 5 segundos podem ser usados. Um backend lento ou fora do ar não prende clientes por muito tempo. O comportamento de retry e failover é acionado mais cedo.
Um perfil defensivo pode usar valores baixos como httpRequestTimeout 5 segundos e clientFIN/serverFIN 1 segundo. Essa estrutura limita padrões de entrega lenta de headers e consumo de conexões half-closed. Reduz a superfície de ataque em serviços públicos.
Perfis de timeout nomeados com 9 eixos para seus pools web, API, WebSocket e upload. Vamos percorrer uma configuração ao vivo com sua própria configuração.