Resumo

  • TCP keepalive pergunta se um par silencioso ainda responde no transporte; ele não comprova a saúde da aplicação remota.
  • O mecanismo ficou opcional, configurável e desligado por padrão porque o silêncio de uma conexão admite causas diferentes.
  • Uma resposta perdida não prova morte, e memória intermediária, user timeout e energia impedem um intervalo universal seguro.

A confiabilidade não observa o que não foi enviado

No RFC 793, o TCP tem uma obrigação bem definida quando existem dados: bytes ocupam posições de sequência, confirmações fazem o envio avançar e a falta delas provoca retransmissões. Em algum ponto, o transporte entrega, recebe um reset ou alcança a política local de abandono.

Uma conexão ociosa não oferece esse material. Não existe byte novo aguardando ACK nem byte antigo cujo temporizador possa denunciar um caminho rompido. Os dois lados podem estar saudáveis e quietos. Um host pode ter travado; uma rota, regra de firewall ou tradução de endereço pode ter desaparecido. Para o estado TCP local, todos esses mundos podem parecer idênticos.

Não é uma falha da entrega confiável. É o limite do que uma entrega pode revelar quando ninguém tentou realizá-la.

Uma pergunta feita atrás da fronteira

O RFC 1122 registrou o keepalive em 1989 como mecanismo controverso e opcional. A sonda tradicional usa SEG.SEQ = SND.NXT-1, imediatamente antes do próximo byte novo que o emissor poderia transmitir.

A posição estranha é intencional. O segmento não deve virar dado novo da aplicação, mas deve induzir o TCP que ainda mantém a conexão a responder com um ACK e declarar o que espera a seguir. Normalmente a sonda não leva dados e não move o fluxo. A variante com um byte “lixo” só permaneceu configurável para lidar com implementações incorretas da época.

O ACK responde a uma pergunta estreita: agora, um TCP remoto processou o segmento por um caminho de ida e volta utilizável. Não afirma que o processo remoto progride, que as credenciais valem, que o banco de dados responde ou que a próxima operação comercial dará certo.

A opcionalidade fazia parte da proteção

O RFC 1122 não obrigou toda implementação TCP a oferecer keepalive. Quando oferecido, a aplicação precisava poder ativá-lo ou desativá-lo em cada conexão, e o padrão precisava ser desligado. O intervalo ocioso deveria ser configurável e começar em pelo menos duas horas.

Assim, o transporte não escolhe silenciosamente a semântica de falha da aplicação. Uma sessão de terminal, uma adjacência de roteamento, um pool de banco e um sensor adormecido atribuem custos diferentes a encerramento falso, detecção lenta, tráfego e retenção de estado. A ausência de bytes não informa ao TCP qual custo domina.

Duas horas nunca significaram que um par morre aos 7.200 segundos. Eram um limite conservador: sem decisão explícita da aplicação, a sondagem não solicitada deveria ser rara. O texto consolidado moderno, RFC 9293, conserva essa distribuição de autoridade. Décadas de uso não converteram a sonda opcional numa definição automática de vida.

Uma pergunta perdida não encerra o caso

ACKs puros não recebem, isoladamente, a mesma promessa de retransmissão confiável oferecida aos dados. A sonda pode sumir; seu ACK também; congestionamento pode atrasar ambos. Por isso os RFCs 1122 e 9293 proíbem declarar uma conexão morta só porque uma sonda não teve resposta.

Encerrar é uma ação, não uma observação. Depois que o TCP local apaga o estado e comunica a falha, a aplicação pode abandonar uma transação, liberar um bloqueio, eleger um substituto ou abrir outra conexão. A consequência de uma inferência causada por perda passageira pode sobreviver à própria perda.

Repetições e um limiar tornam a falha mais plausível. Ainda exprimem uma decisão local de risco: depois de tanta evidência ausente, custa mais conservar a incerteza do que fechar. Não transformam ausência em testemunho direto.

O user timeout mede outra espera

O TCP já tinha o conceito de tempo limite do usuário para dados enviados e não confirmados. O RFC 5482 definiu depois uma opção para comunicar preferência de timeout. A pergunta é “por quanto tempo dados transmitidos podem ficar sem confirmação?”, não “há quanto tempo um par ocioso não fala?”.

Separar os relógios evita que políticas se contradigam. O RFC 5482 observa que certas configurações de keepalive encerram uma conexão que poderia atravessar uma indisponibilidade temporária. Quando usados juntos sob essa especificação, o temporizador de keepalive deve superar o user timeout adotado. Dado em trânsito, sonda ociosa e decisão de fechar pertencem a cadeias de evidência próximas, mas distintas.

O intermediário ganhou memória própria

A descrição de ponta a ponta supunha que os endpoints possuíam o estado. NATs e middleboxes com estado inseriram no caminho outro livro-caixa, também sujeito a expiração. A conexão pode continuar válida nas duas máquinas enquanto um intermediário apaga o mapeamento necessário ao próximo pacote.

O RFC 5382 converteu as duas horas num limite de compatibilidade. Um NAT incapaz de determinar a atividade dos endpoints estabelecidos não deve abandonar o mapeamento antes de duas horas e quatro minutos; os minutos extras acomodam pacotes em voo.

A regra protege expectativas das pontas, não entrega ao NAT a propriedade da conexão, nem prova que todo equipamento real a segue. Ao encontrar vidas mais curtas, operadores enviam sondas com mais frequência. Elas podem conservar o mapeamento, mas pagam um imposto do intermediário: a ponta produz tráfego para impedir que uma caixa privada esqueça, não porque a aplicação tenha algo a comunicar.

A bateria apresentou a conta inversa

Num servidor ligado à tomada, alguns pacotes parecem baratos. Num aparelho econômico, cada transmissão pode acordar o rádio e prolongar um período caro de atividade. O RFC 9006 registra a tensão: o padrão longo talvez não preserve o estado de certos intermediários, enquanto keepalives curtos podem gastar bateria.

Nenhuma constante do transporte resolve essa distribuição. A aplicação sabe se uma reconexão tardia é aceitável; o operador conhece os tempos observados do caminho; o dispositivo conhece seu orçamento energético. Às vezes, a política racional é não manter conexão alguma e refazê-la quando surgir trabalho.

Um coração que não escuta a aplicação

Chamar keepalive de batimento cardíaco costuma ampliar demais seu alcance. O kernel pode responder ACK enquanto o serviço está bloqueado. Um proxy pode manter o TCP e perder seu backend. Uma aplicação saudável pode estar suspensa de propósito.

Um heartbeat de aplicação pergunta algo mais forte: o serviço consegue interpretar uma requisição, consultar estado e produzir resposta válida? Essa força custa mais e ainda não garante toda operação futura. Os dois mecanismos só devem ser combinados depois de identificar qual falha cada um procura.

Keepalive tampouco é sonda de janela zero. Esta protege a reabertura de uma janela depois que o receptor declarou capacidade zero; aquele investiga uma conexão sem tráfego. Pacotes pequenos parecidos sustentam contratos diferentes.

O silêncio manteve a presunção de inocência

A escolha duradoura não foi apenas a manobra SND.NXT-1, mas a recusa de permitir que o transporte condenasse o silêncio por padrão.

Um ACK recebido evidencia resposta TCP recente, não saúde da aplicação. Um ACK ausente significa incerteza, não morte. Uma sequência configurada de ausências pode justificar o encerramento local porque a aplicação escolheu um orçamento de risco, não porque a Internet forneceu certeza.

O keepalive continuou opcional porque quem suporta a consequência deve conservar a decisão. O TCP ofereceu uma maneira de perguntar; nunca alegou autoridade para explicar por que ninguém respondeu.

Fontes e limites da evidência

O RFC 793 estabelece a conexão e o user timeout originais; o RFC 1122, o contrato de keepalive de 1989; o RFC 5382, tempos de NAT; o RFC 5482, a separação do user timeout; o RFC 9006, o custo energético; e o RFC 9293, as regras atuais consolidadas. Eles não determinam padrões de cada plataforma, todo timeout de middlebox nem o significado de saúde de cada aplicação.