1. Pregunta y contexto
Un cliente de larga duración se conecta a través de un NAT, un balanceador de carga y un servidor. Tras una interrupción de la red, el sistema operativo todavía reporta el socket como establecido. El equipo debate si TCP Keepalive por sí solo es suficiente o si el protocolo debería agregar mensajes de ping/pong. Compara ambos mecanismos y propón un comportamiento de detección, timeout, proxy y reconexión. Asume que el negocio necesita saber si la sesión aún puede procesar solicitudes, y no simplemente si una interfaz de red es alcanzable.
2. Lo que el entrevistador está evaluando
- Si distingues el sondeo de transporte del sondeo de disponibilidad a nivel de aplicación.
- Si sabes que TCP Keepalive utiliza temporizadores del kernel, por lo que los valores predeterminados y el comportamiento de los middleboxes no constituyen un SLA de negocio.
- Si puedes diseñar una máquina de estados acotada para heartbeat, timeout, cierre y reconexión sin falsos positivos ni tormentas.
- Si incluyes NAT, timeouts de inactividad de proxies, redes móviles y carga del servidor en un diseño de extremo a extremo.
3. Preguntas aclaratorias para hacer primero
- ¿Necesitamos detectar la ruta de red, el proceso par TCP o la disponibilidad de la sesión de aplicación?
- ¿Qué timeout de inactividad aplica en el NAT, la pasarela (gateway) y el balanceador de carga?
- ¿La conexión transporta lecturas reintentables o comandos y transacciones que requieren confirmación?
- ¿Cuántos clientes hay, qué ancho de banda adicional es aceptable y cuántas reconexiones pueden ejecutarse de manera concurrente?
4. Estructura de respuesta de 30 segundos
El kernel envía el TCP Keepalive y descubre principalmente un par TCP semiabierto e inactivo o una ruta interrumpida. Un heartbeat de aplicación está definido por el protocolo y puede verificar que la aplicación par aún lee, escribe y devuelve un acuse de recibo de negocio. Yo definiría los estados healthy, suspect, closed y backoff, y luego establecería el intervalo de heartbeat a partir del timeout de inactividad más corto de los middleboxes. Keepalive es el respaldo a nivel de transporte; el heartbeat de aplicación es el dueño del SLA de negocio. Al agotarse el timeout, se cierra el socket antiguo, se reconecta con retroceso exponencial con jitter (jittered exponential backoff) y se limita la concurrencia.
5. Respuesta detallada paso a paso
Paso 1: Definir qué observa cada mecanismo
TCP Keepalive opera en la capa de sockets. En Linux, tcp(7) expone un período de inactividad, un intervalo de sondeo y un recuento de sondeos; un ACK solo demuestra que la pila TCP puede responder. No demuestra que la aplicación esté autenticada, que su arrendamiento (lease) sea válido o que pueda procesar una solicitud. Keepalive es útil para descubrir conexiones semiabiertas silenciosas y liberar recursos del kernel.
Un heartbeat de aplicación es un mensaje de protocolo, como ping que transporta datos de sesión o de capacidad, respondido mediante un pong o una respuesta con estado. Puede detectar un bucle de eventos bloqueado, un arrendamiento expirado, una autenticación no válida o un servicio sobrecargado que TCP no puede percibir. Tiene un costo en CPU de la aplicación, ancho de banda y capacidad de conexiones.
Paso 2: Establecer parámetros a partir de un presupuesto de tiempo de extremo a extremo
Encuentra el timeout de inactividad más corto entre los middleboxes T_idle y luego elige un intervalo de heartbeat inferior a este con margen de jitter, por ejemplo T_hb <= T_idle / 2. Mantén el plazo límite de respuesta de la aplicación por debajo del tiempo de desconexión permitido por el negocio; exige N fallos consecutivos antes de declarar la caída para que un solo paquete perdido no destruya una sesión sana. TCP Keepalive puede usar un período de inactividad más largo como respaldo de transporte durante el silencio de la aplicación; no puede reemplazar el SLA de la aplicación.
Paso 3: Diseñar estados y acciones
Tras conectarse, entra en healthy. El envío de un heartbeat pasa al estado suspect; una respuesta de la aplicación antes del plazo límite regresa a healthy. Los fallos consecutivos cierran el socket y entran en backoff. Utiliza un incremento exponencial con jitter aleatorio y un límite máximo; pausa los intentos de marcación mientras se esté fuera de línea o mientras una página esté oculta, y luego ejecuta una verificación de salud antes de reanudar. Cierra el socket antiguo primero para que dos conexiones no puedan consumir un único flujo de comandos.
Paso 4: Recuperar según la semántica de los mensajes
Las notificaciones pueden descartarse y volverse a suscribir tras la reconexión. Un comando de escritura no debe depender de la confirmación del heartbeat: adjunta una clave de idempotencia o número de secuencia, recibe una confirmación explícita y registra el último punto de confirmación contiguo. Tras la reconexión, retransmite a partir de un cursor o consulta el estado. Si la ejecución es incierta, lee el estado del servidor antes de decidir si reintentar.
Paso 5: Verificar middleboxes y señales operativas
Utiliza captura de paquetes o registros de conexión para confirmar que los heartbeats atraviesen el NAT, el proxy y el balanceador de carga. Registra el RTT del heartbeat, la tasa de timeouts, los sondeos Keepalive fallidos, la antigüedad de la conexión, los intentos de reconexión, la duración del backoff y los picos de concurrencia. Realiza simulacros de desconexión de red, liberación por NAT, bucle de eventos del servidor bloqueado, autenticación expirada y desconexión sincronizada. Un estado TCP ESTABLISHED por sí solo no demuestra disponibilidad a nivel de negocio.
6. Ejemplo de respuesta de alta calidad
Separo ambos mecanismos por capa. TCP Keepalive es un sondeo del kernel que puede encontrar una conexión TCP semiabierta silenciosa, pero un ACK no significa que la aplicación pueda procesar una solicitud. Un heartbeat de aplicación puede verificar el estado del protocolo, la autenticación y el arrendamiento, por lo que es el dueño de la decisión de negocio. Mido el timeout de inactividad más corto del NAT o balanceador de carga, configuro el heartbeat aproximadamente a la mitad de ese valor y agrego un plazo límite de respuesta y un umbral de fallos consecutivos. Una máquina de estados de conexión transita entre healthy, suspect, closed y backoff con jitter; un timeout cierra el socket antiguo antes de reconectar. Las notificaciones se vuelven a suscribir tras la recuperación, mientras que los comandos utilizan claves de idempotencia y cursores de confirmación. Keepalive es un respaldo durante el silencio de la aplicación, no un sustituto de un heartbeat ni un bucle de reintentos ilimitado.
7. Errores comunes
- Tratar un ACK de TCP como prueba de salud del negocio → el kernel puede responder mientras el hilo de la aplicación está bloqueado → utilizar un heartbeat de solicitud-respuesta a nivel de aplicación.
- Adoptar los valores predeterminados de Keepalive del sistema sin cambios → el período de inactividad puede superar el timeout de un proxy → configurar a partir del presupuesto de tiempo de extremo a extremo.
- Reconectar tras perder un solo heartbeat → una pérdida breve de paquetes genera una tormenta → utilizar un plazo límite, un umbral de fallos consecutivos y retroceso con jitter.
- Ajustar únicamente el heartbeat del cliente → un NAT o balanceador de carga aún puede recuperar recursos antes → inspeccionar cada middlebox.
- Retransmitir a ciegas comandos de escritura tras la reconexión → genera cobros o crea recursos por duplicado → utilizar claves de idempotencia, puntos de confirmación y lecturas de estado.
8. Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Si el heartbeat de aplicación es más robusto, ¿por qué mantener TCP Keepalive?
La aplicación puede permanecer en silencio durante mucho tiempo o el código de su protocolo puede tener fallos. Keepalive puede descubrir un transporte caído durante ese silencio y liberar el socket. Es un respaldo de capa inferior, no un acuse de recibo de negocio.
Pregunta de seguimiento 2: ¿Debería el intervalo de heartbeat ser lo más corto posible?
No. Los intervalos más cortos detectan fallos con mayor rapidez, pero consumen más CPU, ancho de banda, batería en dispositivos móviles y concurrencia en el servidor. Primero satisface el presupuesto de inactividad de los middleboxes y luego usa simulacros de fallos para medir falsos positivos y retrasos de detección, estableciendo niveles según los distintos tipos de conexión.
Pregunta de seguimiento 3: ¿Cómo se evita una tormenta de reconexión tras un reinicio de toda la flota?
Los clientes utilizan retroceso exponencial con jitter aleatorio. El servidor aplica limitación de tasa (rate limiting) por inquilino o tipo de conexión y puede proveer un tiempo de reintento. Los clientes sin conexión dejan de marcar; cuando la conectividad regresa, se reconectan en lotes y exponen el pico para su monitoreo.