Porque é que ligações curtas sobrecarregam um servidor auto-hospedado ocupado?

Conexões curtas sobrecarregam um servidor auto-hospedado ocupado quando o trabalho de configuração e desmontagem se torna maior do que o trabalho útil da requisição. Cada nova sessão pode exigir um handshake TCP, negociação TLS, alocação de socket, autenticação, registo e limpeza, mesmo que a resposta contenha apenas alguns bytes.

Uma transferência de ficheiro longa paga esses custos uma vez e depois move uma quantidade substancial de dados. Verificações de saúde, painéis, clientes móveis, recursos web e chamadas API mal agrupadas podem criar centenas de sessões pequenas, forçando o servidor a repetir custos fixos enquanto mantém o estado de conexões recentemente fechadas.

A Causa Principal: Cada Nova Conexão Repete Trabalho Fixo

Uma conexão TCP começa com um handshake antes que os dados da aplicação possam fluir. HTTPS adiciona negociação criptográfica, e a aplicação pode então criar uma sessão, verificar credenciais, abrir uma conexão de base de dados ou carregar o estado do utilizador. Para uma resposta pequena, estas etapas de configuração podem dominar tanto a latência como o tempo de CPU.

A sobrecarga de conexões de curta duração torna-se significativa quando o servidor a repete a uma taxa elevada. O resultado visível pode ser o aumento da média de carga e respostas mais lentas, mesmo que a taxa de transferência da rede permaneça muito abaixo da velocidade do link.

A reutilização de conexões altera essa proporção. Várias requisições podem partilhar um transporte estabelecido e, onde suportado, uma sessão encriptada. O servidor passa mais tempo a fazer trabalho de aplicação e menos tempo a alocar e retirar o estado da conexão.

Keep-Alive Reduz Handshakes mas Precisa de Limites Sensatos

O HTTP keep-alive permite que múltiplas requisições usem uma conexão TCP em vez de abrir uma nova conexão para cada objeto ou chamada API. Isto reduz as viagens de ida e volta e previne que a configuração repetida se multiplique à medida que uma página ou painel carrega muitos recursos.

As conexões HTTP keepalive reduzem a latência ao reutilizar transportes estabelecidos. O limite é o estado ocioso: tempos de espera excessivamente longos podem deixar muitos sockets não utilizados a ocupar memória e slots de conexão, por isso a reutilização precisa de um tempo limite e limite de requisições que correspondam ao padrão do cliente.

O agrupamento deve existir em ambos os lados de uma chamada de serviço interna. Um proxy reverso pode reutilizar conexões de clientes enquanto abre uma nova conexão upstream para cada requisição, movendo a rotatividade em vez de a eliminar. Drivers de base de dados e clientes API podem criar a mesma dispersão oculta dentro de uma aplicação auto-hospedada.

Conexões Fechadas Podem Deixar Estado no Kernel

Fechar uma sessão TCP nem sempre apaga imediatamente o seu estado. O ponto final que fecha ativamente pode manter uma entrada TIME_WAIT para que pacotes atrasados da conexão antiga não sejam confundidos com uma conexão posterior usando o mesmo endereço e tuplo de porta.

Uma grande população TIME_WAIT sinaliza, portanto, uma rotatividade frequente de conexões em vez de um servidor automaticamente avariado. A altas taxas, pode consumir memória, complicar a observabilidade ou esgotar as portas efémeras de um cliente antes que as entradas antigas expirem.

Mudar os temporizadores do kernel raramente é o primeiro passo. Identifique qual cliente ou serviço está a abrir conexões, confirme se a reutilização está ativada e verifique se as tentativas ou sondagens de saúde estão a multiplicar a taxa. Alterações agressivas nos temporizadores podem ocultar o padrão enquanto enfraquecem a proteção do TCP contra pacotes atrasados.

A Automação Pode Criar Rotatividade de Conexões num Servidor Aparente Ocioso

Um servidor doméstico pode receber pedidos de verificações de saúde de contentores, agentes de monitorização, separadores de navegador, widgets de telemóvel, clientes de media e proxies reversos mesmo quando nenhuma pessoa está a usá-lo ativamente. Se cada sonda abrir uma nova conexão encriptada, um intervalo curto transforma uma verificação leve num trabalho contínuo de configuração.

Medidas de conexões TCP de curta duração mostram como clientes automatizados e scripts podem favorecer sessões novas repetidas em vez de mantidas. Num pequeno servidor auto-hospedado, o mesmo comportamento é visível numa escala menor porque os limites de CPU, memória e trabalhadores são mais baixos.

Conte conexões aceites por segundo, CPU usada no handshake, sockets abertos, entradas TIME_WAIT e requisições por conexão. Se a taxa de conexões aumentar muito mais rápido do que o volume de requisições, inspecione o agrupamento e o comportamento de tentativas. Se o serviço estiver exposto à internet, confirme primeiro o limite de exposição com uma verificação de exposição do servidor doméstico para que varreduras indesejadas não sejam confundidas com clientes normais.

Perguntas Frequentes

Muitas conexões curtas são sempre um problema?

Não. Servidores modernos podem lidar com muitas conexões, e sessões curtas podem ser apropriadas para clientes pouco frequentes. Tornam-se um problema quando a taxa de conexões consome CPU, portas, trabalhadores ou memória mais rápido do que o servidor pode reciclar.

O HTTP/2 elimina a sobrecarga de conexões?

O HTTP/2 pode multiplexar muitas requisições sobre menos conexões, o que reduz a rotatividade. Clientes, proxies e serviços upstream devem realmente negociar e reutilizá-lo; saltos internos podem ainda usar conexões HTTP/1.1 separadas.

Devo reduzir o tempo de espera TIME_WAIT?

Não antes de identificar a fonte da rotatividade. TIME_WAIT é um comportamento normal do protocolo. Agrupamento de conexões, transportes persistentes, intervalos de sondagem e limites de tentativas geralmente resolvem a carga de trabalho de forma mais direta do que encurtar temporizadores de segurança do kernel.