Keep-alive HTTP

O que é keep-alive HTTP, em palavras simples?

Sempre que um sistema conversa com uma API, ele precisa primeiro estabelecer uma conexão com o servidor. Isso funciona como uma ligação telefônica: antes de falar, é preciso discar, esperar atender e confirmar que a linha está boa.

Sem keep-alive, o sistema desliga a ligação ao fim de cada pedido e precisa discar de novo para o próximo. Com keep-alive, a linha continua aberta por algum tempo, e os pedidos seguintes passam pela mesma conexão, sem repetir toda a preparação.

Como funciona o keep-alive no HTTP?

No HTTP/1.0, o cliente precisava pedir explicitamente a conexão persistente, usando o cabeçalho Connection: keep-alive. A partir do HTTP/1.1, as conexões passaram a ser persistentes por padrão, e quem quiser encerrá-las deve enviar Connection: close.

Alguns servidores também informam, pelo cabeçalho Keep-Alive, por quanto tempo uma conexão ociosa será mantida e quantas requisições ela aceita. No HTTP/2, a ideia vai além: uma única conexão transporta várias requisições ao mesmo tempo, recurso chamado multiplexação.

Na prática, quem cuida disso costuma ser a biblioteca HTTP usada pelo sistema, por meio de um pool de conexões: um conjunto de conexões abertas que são emprestadas e devolvidas a cada chamada.

Para que serve o keep-alive em uma API fiscal?

Chamadas a APIs fiscais usam HTTPS, o que exige, além da conexão de rede, uma negociação de segurança TLS. Essa etapa consome tempo e processamento. Reaproveitar a conexão evita repeti-la a cada documento emitido, consultado ou baixado.

O ganho aparece principalmente em volumes altos: um ERP que emite centenas de NF-e, um marketplace que gera NFS-e para muitos vendedores ou um sistema que consulta status de documentos com frequência. Menos tempo gasto abrindo conexões significa respostas mais rápidas e menor carga nos dois lados.

Quais cuidados são necessários ao usar keep-alive?

Conexões ociosas não ficam abertas para sempre. Servidores, balanceadores de carga e proxies encerram conexões paradas após um período. Se o cliente tentar usar uma conexão que já foi fechada do outro lado, pode receber erros como conexão reiniciada ou fechada inesperadamente.

Para evitar isso, recomenda-se configurar no cliente um tempo de ociosidade menor que o do servidor, limitar o tamanho do pool de conexões e ter uma política de retry segura. Em emissões fiscais, o retry deve vir acompanhado de idempotência, para que uma nova tentativa não gere documento duplicado.

Qual a diferença entre keep-alive HTTP e keep-alive TCP?

O keep-alive HTTP trata do reaproveitamento da conexão para várias requisições. Já o keep-alive TCP é um recurso da camada de rede que envia pequenos sinais periódicos para verificar se a outra ponta ainda está ativa em uma conexão parada.

Os nomes são parecidos, mas os objetivos são diferentes: um busca eficiência entre requisições; o outro detecta conexões que caíram sem aviso. Eles podem ser usados juntos.

Exemplos de Keep-alive HTTP

• Um ERP que emite notas em lote mantém um pool de conexões abertas com a API fiscal, enviando cada NF-e pela mesma conexão em vez de abrir uma nova para cada documento.
• Uma plataforma de serviços que gera NFS-e para vários prestadores reduz o tempo médio de resposta ao ativar keep-alive na biblioteca HTTP do seu backend.
• Um sistema que faz polling do status de documentos recebe erros intermitentes de conexão fechada e resolve o problema reduzindo o tempo de ociosidade do pool para um valor menor que o do servidor.
• Um serviço de transporte que emite CT-e e MDF-e ao longo do dia configura o cliente HTTP para reaproveitar conexões e repetir automaticamente chamadas que falham por conexão encerrada.