Resumen

  • TCP keepalive pregunta si un par silencioso aún responde en la capa de transporte; no demuestra la salud de su aplicación.
  • El mecanismo quedó opcional, configurable y apagado por defecto porque el silencio de una conexión admite causas diferentes.
  • Una respuesta perdida no prueba muerte, y la memoria intermediaria, el user timeout y la energía impiden un intervalo universal.

Sin byte no había testigo

RFC 793 organiza la fiabilidad alrededor de datos: secuencias, ACK, retransmisión y cierre. Cuando nada nuevo debe salir y nada antiguo espera confirmación, no existe un temporizador de entrega que pueda descubrir un fallo.

Dos extremos sanos y silenciosos se parecen a un host apagado, una ruta rota o un firewall sin estado. TCP no ha observado una entrega fallida; no se intentó ninguna.

Preguntar desde detrás del borde

El RFC 1122 documentó keepalive en 1989 como práctica discutida. La sonda habitual lleva SEG.SEQ = SND.NXT-1, justo detrás del próximo byte nuevo. El receptor debería responder con un ACK que muestre su frontera actual.

La sonda preferida no contiene datos ni modifica el flujo de aplicación. La variante con un byte basura existe sólo para compatibilidad con implementaciones erróneas.

La respuesta demuestra que un TCP y algún retorno funcionaron en ese instante. No demuestra que el proceso remoto avance, que una dependencia esté disponible o que la sesión de negocio siga autorizada.

El valor predeterminado protegió una decisión ajena

RFC 1122 permitió implementar la función sin exigirla. La aplicación debe poder activarla por conexión y el estado inicial debe ser apagado. El intervalo es configurable y su valor predeterminado no puede ser menor de dos horas.

Las dos horas no definen la muerte. Evitan que una capa común elija agresivamente entre detección rápida y cierre falso. Un terminal, un clúster, una base de datos y un sensor dormido valoran de forma distinta tráfico, energía, memoria y continuidad.

RFC 9293 mantiene hoy esos límites. La adopción no borró la autoridad de la aplicación.

Una ausencia no equivale a un veredicto

Un ACK puro no tiene retransmisión fiable propia. Pueden perderse la sonda o su respuesta. Por eso una sola falta de contestación no puede cerrar la conexión.

Cerrar puede causar failover, repetir trabajo, liberar un lock o mostrar un error al cliente. Varios intentos ausentes cruzan un umbral elegido localmente; hacen razonable actuar, no convierten el silencio en prueba directa.

User timeout no es el reloj de la quietud

El user timeout mide cuánto pueden permanecer sin ACK datos transmitidos. El RFC 5482 permitió comunicar esa preferencia y advirtió que ciertas políticas keepalive podían matar una conexión que sobreviviría una interrupción transitoria.

Si se combinan ambos mecanismos según esa especificación, el temporizador keepalive debe ser mayor que el user timeout adoptado. Una sonda ociosa no debe contradecir una política explícita sobre trabajo pendiente.

Un intermediario empezó a olvidar

Los NAT añadieron una tabla temporal a un contrato que los extremos creían conservar. Una entrada podía expirar mientras ambos TCP seguían en ESTABLISHED.

El RFC 5382 exige que un NAT conforme, cuando no sabe determinar actividad, no elimine una conexión establecida antes de dos horas y cuatro minutos. Así respeta el keepalive predeterminado y deja margen a paquetes en vuelo.

No todos los equipos cumplen. Acortar la sonda para conservar mappings puede ser necesario, pero obliga a los extremos a generar tráfico para sostener la memoria privada de un tercero.

La radio presentó otra factura

En un dispositivo limitado, cada sonda puede despertar la radio. El RFC 9006 enfrenta las dos pérdidas: dos horas pueden no salvar el estado de algunos middleboxes; una frecuencia alta consume batería.

La aplicación conoce el coste de reconectar, el operador conoce el camino y el dispositivo conoce su energía. Ninguna constante TCP posee esas tres informaciones.

El kernel puede latir mientras el servicio no responde

Keepalive observa transporte. Un kernel puede contestar con un proceso bloqueado; un proxy puede contestar con un backend caído. Un heartbeat de aplicación formula una pregunta más fuerte, aunque también cuesta más y no predice toda operación futura.

Tampoco debe confundirse con zero-window probing. Esa sonda preserva la noticia de una ventana que vuelve a abrirse; keepalive prueba una conexión sin trabajo pendiente.

Presunción de vida, decisión local

Un ACK aporta evidencia de alcance TCP reciente. Una ausencia aporta incertidumbre. Sólo una política elegida por quien soporta la consecuencia transforma ausencias repetidas en cierre.

TCP ofreció una manera de preguntar al silencio. Al dejarla opcional, rechazó la pretensión de explicar el silencio por todos.

Fuentes y límites

RFC 793, RFC 1122, RFC 5382, RFC 5482, RFC 9006 y RFC 9293 prueban diseño y requisitos, no la configuración de cada sistema ni la salud de una aplicación concreta.