HTTP keep-alive e reutilização de conexões: pools, timeouts de inatividade e a condição de corrida da conexão obsoleta

O que é

A RFC 9112 estabelece que o HTTP/1.1 usa conexões persistentes por padrão, transportando várias requisições e respostas em uma única conexão. Uma conexão permanece aberta, a menos que uma mensagem traga a opção de conexão close ou que o outro lado fale HTTP/1.0 sem keep-alive; um cliente ou servidor que não suporta persistência deve enviar close em todas as mensagens. Para continuar persistente, cada mensagem precisa ter um comprimento definido por si mesma (Content-Length ou codificação chunked). Os servidores costumam fechar conexões inativas após um timeout cuja duração a especificação não limita; as conexões podem ser fechadas a qualquer momento, e os clientes deveriam limitar o número de conexões simultâneas com um mesmo servidor. A MDN descreve os mesmos modelos e observa que o pipelining, embora definido, não vem ativado por padrão nos navegadores modernos.

Por que importa

Cada nova conexão custa um handshake TCP e, com TLS, um handshake criptográfico adicional, além de um socket em TIME_WAIT depois. Um cliente que faz muitas requisições pequenas a um mesmo host pode gastar mais tempo estabelecendo conexões do que transferindo dados, e um servidor pode gastar mais CPU em handshakes TLS do que nas próprias requisições. A reutilização elimina esse custo em todas as requisições após a primeira.

Como aplicar

• Mantenha um único objeto de cliente com pool de conexões durante todo o ciclo de vida do processo (requests.Session, httpx.Client, um Agent do Node com keep-alive), em vez de criar um por chamada. A documentação do Requests afirma que o keep-alive é automático dentro de uma sessão.
• Consuma ou feche todo corpo de resposta. A mesma documentação observa que as conexões só voltam ao pool depois que todos os dados do corpo foram lidos; uma resposta em streaming não lida ocupa uma conexão.
• Defina o timeout de inatividade do cliente abaixo do do servidor e do proxy. Caso contrário, o cliente escolhe uma conexão que o servidor acabou de fechar, e a primeira requisição após um período ocioso falha com um reset. A RFC 9112 diz que as implementações deveriam prever esses fechamentos assíncronos e remete à RFC 9110 para saber quando uma requisição pode ser repetida automaticamente; tente novamente uma única vez, e apenas requisições idempotentes.
• Limite o pool por host ao que o servidor aceita e recicle as conexões após um certo número de requisições ou uma idade máxima, para que conexões de longa duração não prendam o cliente a um único backend atrás de um balanceador de carga.
• Verifique os cabeçalhos da resposta: um servidor que responde Connection: close anula o pool silenciosamente.

Armadilhas

Intermediários de rede descartam conexões ociosas sem avisar nenhuma das pontas; a pergunta em aberto sobre timeouts de inatividade em NAT trata disso. Uma conexão TLS autenticada com certificado de cliente fica vinculada a essa identidade; não compartilhe tal conexão entre tenants. O HTTP/2 multiplexa vários streams em uma única conexão, de modo que suas regras de pooling diferem das do HTTP/1.1.