Ciclo de vida de la conexión TCP: Handshake, Cierre y TIME_WAIT

Pregunta y alcance

Un cliente API en Linux no reutiliza conexiones y abre 5,000 conexiones TCP cortas por segundo hacia un único upstream. Luego, reporta tiempos de espera agotados de conexión (timeouts) y una gran cantidad de conexiones en TIME_WAIT. Explica cómo se abre y se cierra TCP, qué extremo entra en TIME_WAIT, por qué existe este estado y cómo diagnosticarías y solucionarías el incidente.

Utiliza supuestos base explícitos. El cliente tiene una única IP de origen, y la IP y puerto del upstream son fijos. El rango de puertos efímeros es el valor predeterminado documentado en Linux de 32768–60999, sin puertos reservados. Una captura de paquetes muestra que el cliente envía el primer FIN, y las entradas observadas en TIME_WAIT duran unos 60 segundos. Estos dos últimos hechos son evidencia suministrada por el escenario, no constantes universales del sistema operativo.

Esta pregunta es adecuada para entrevistas de backend, infraestructura, SRE, cliente e ingeniería de software en general. La tarea real no es recitar "handshake de tres vías y cierre de cuatro vías". Consiste en usar estados TCP, la capacidad de la 4-tupla y evidencia de paquetes para separar la limpieza normal del agotamiento de puertos efímeros, la pérdida de paquetes y la sobrecarga del upstream.

Qué evalúa el entrevistador

Primero, ¿puede el candidato explicar que el handshake sincroniza ambos números de secuencia iniciales? Un SYN consume un número de secuencia, y el acuse de recibo (acknowledgment) identifica el siguiente número de secuencia esperado. El tercer mensaje confirma que el iniciador recibió el número de secuencia inicial del par. Enumerar SYN, SYN+ACK y ACK sin este propósito es incompleto.

Segundo, ¿puede el candidato mapear la semántica de cierre full-duplex a los estados? Las dos direcciones pueden dejar de enviar de forma independiente, por lo que un cierre normal se muestra habitualmente como FIN → ACK → FIN → ACK. Un ACK puede combinarse con un FIN, por lo que una captura no siempre contiene cuatro paquetes separados. Una respuesta sólida explica qué están esperando FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, LAST-ACK y TIME-WAIT.

Tercero, ¿puede el candidato identificar al propietario de TIME_WAIT? Por lo general, es el extremo que cierra activamente y envía el ACK final. Ese extremo puede ser el cliente o el servidor. Si ambos extremos cierran activamente al mismo tiempo, ambos pueden entrar en TIME_WAIT. Las etiquetas de cliente y servidor por sí solas no determinan el estado.

Cuarto, ¿puede el candidato evitar diagnosticar cada conteo alto de TIME_WAIT como una falla? Muchas conexiones cortas producen naturalmente muchas entradas. El agotamiento de puertos requiere una relación entre el suministro de tuplas, la tasa de creación de conexiones, el comportamiento de los errores y la evidencia de paquetes.

Quinto, ¿puede el candidato proponer soluciones en orden creciente de riesgo? Reducir primero la creación de conexiones, inspeccionar después la capacidad y la ruta de red, y considerar las configuraciones del kernel al final. Truncar estados, reducir el límite del bucket o usar RST para eludir un cierre normal puede transformar un problema evidente de capacidad en fallas de corrección intermitentes.

Preguntas a aclarar primero

• ¿Qué extremo cierra activamente? El extremo que envía el primer FIN normalmente sigue la ruta de cierre activo. Si el upstream cierra primero, el TIME_WAIT del lado del cliente requiere otra explicación.
• ¿Qué significa “connection timeout” en los datos de error? La asignación de puertos locales puede fallar inmediatamente con errores como EADDRNOTAVAIL. Una conexión que permanece en SYN-SENT y retransmite apunta más hacia la ruta, un filtro, presión en el listen backlog o un upstream que no responde. El tipo de error y la duración cambian la investigación.
• ¿Puede el protocolo reutilizar conexiones? HTTP keep-alive, un pool de conexiones, multiplexación HTTP/2 u otro transporte persistente pueden eliminar la mayoría de los handshakes y cierres. La ampliación de capacidad se vuelve relevante solo cuando el comportamiento de una solicitud por conexión es estrictamente requerido.
• ¿Dónde está la restricción de puertos? El host tiene un rango de puertos efímeros. Un NAT, proxy o balanceador de carga tiene su propio pool de asignación de direcciones públicas y puertos. Que haya puertos libres en el host no demuestra que el dispositivo de salida tenga tuplas libres.
• ¿El destino es fijo? Una conexión TCP se identifica por dirección de origen, puerto de origen, dirección de destino y puerto de destino. El mismo puerto local puede usarse para diferentes destinos, por lo que la concentración en un upstream importa más que el total de conexiones de toda la máquina.
• ¿Cuál es la configuración real del sistema en vivo? Los rangos de puertos, puertos reservados, timestamps TCP, políticas de reutilización y versión del kernel afectan la capacidad. Los valores predeterminados del escenario sirven para una estimación inicial, mientras que una conclusión en producción requiere leer los valores reales.

Estructura de respuesta de 30 segundos

“El handshake de tres vías intercambia y confirma ambos números de secuencia iniciales. El cliente envía SYN, el SYN+ACK del servidor reconoce el número del cliente y suministra el suyo, y el cliente envía ACK para ese número. Un cierre normal tiene dos direcciones independientes, por lo que comúnmente es FIN, ACK, FIN, ACK. El extremo que cierra activamente y envía el ACK final normalmente entra en TIME_WAIT para poder acusar recibo de un FIN retransmitido y evitar que duplicados demorados de una conexión antigua interfieran con un nuevo uso de la misma tupla.

Un conteo elevado de TIMEWAIT no es automáticamente una fuga. Inspeccionaría el tipo de error, el conteo de SYN-SENT, la captura de paquetes y el rango de puertos. Una IP de origen hacia un único upstream tiene 28,232 puertos en el rango predeterminado indicado. A 5,000 conexiones nuevas por segundo con unos 60 segundos observados en TIMEWAIT, la demanda es de aproximadamente 300,000 tuplas recientes, muy por encima de la oferta. Primero agregaría pooling o multiplexación, luego inspeccionaría la capacidad de NAT y tuplas, y solo después consideraría un rango más amplio o más direcciones de origen. No comenzaría eliminando TIMEWAIT ni cambiando tcptw_reuse a ciegas.”

Análisis detallado paso a paso

Paso 1: Explicar el handshake con números de secuencia

Sea x el número de secuencia inicial del cliente y y el del servidor:

Un SYN consume un número de secuencia, razón por la cual el acuse de recibo es x+1 o y+1. Un ACK puro no consume espacio de secuencia. El handshake le da a cada extremo el número de secuencia inicial del par y la confirmación de que el propio fue recibido. También reduce la posibilidad de que una solicitud de conexión duplicada antigua se confunda con una nueva conexión.

Después de solo dos mensajes, el iniciador ha visto la confirmación del servidor, pero el servidor no ha recibido la confirmación de que el cliente aceptó su número de secuencia inicial. Decir que “comprueba que la red funciona en ambas direcciones” es un atajo impreciso. TCP está estableciendo un espacio de secuencias reconocido y retransmisible, además de un estado de conexión compartido.

Paso 2: Derivar el cierre a partir de dos direcciones independientes

TCP es un flujo de bytes full-duplex. Cerrar una dirección de envío significa “no tengo más datos para enviar”, mientras que ese extremo puede continuar recibiendo datos que el par aún no ha terminado de enviar. Por lo tanto, un cierre normal termina dos direcciones:

Una cantidad persistente de conexiones en CLOSE-WAIT generalmente significa que se le notificó a la aplicación sobre el cierre del par pero no cerró su propio socket de inmediato. Esa es una falla diferente a TIME_WAIT. Un FIN-WAIT-2 persistente significa que el FIN del cerrador activo fue reconocido, pero el par no ha enviado su FIN. Calificar todo esto simplemente como “conexiones que no se liberaron” le quita valor diagnóstico a la máquina de estados.

La descripción de cuatro mensajes es un caso normal útil, no un conteo fijo de paquetes. Un cerrador pasivo sin datos restantes puede combinar su ACK y FIN. El cierre activo simultáneo puede usar CLOSING y dejar a ambos extremos en TIME-WAIT.

Paso 3: Explicar las dos funciones de TIME_WAIT

El extremo que envía el ACK final no puede olvidar la conexión inmediatamente por dos razones principales.

Primero, el ACK final puede perderse. El cerrador pasivo permanece en LAST-ACK y retransmite su FIN. Un cerrador activo que todavía conserva el estado TIME_WAIT puede reconocer ese FIN nuevamente. Si el estado desapareciera de inmediato, el FIN retransmitido podría recibir un RST y el cierre normal perdería su propiedad de confiabilidad.

Segundo, es posible que todavía existan segmentos duplicados o demorados de la conexión anterior en la red. TCP identifica una conexión mediante su 4-tupla. Si la misma tupla se asigna inmediatamente a una nueva conexión, un segmento antiguo puede superponerse en el nuevo espacio de secuencia. El estándar TCP exige que una conexión cerrada activamente permanezca durante 2 × MSL, dando tiempo a que los segmentos antiguos expiren y preservando la capacidad de reconocer un FIN retransmitido. RFC 1337 explica cómo terminar esta protección antes de tiempo puede reintroducir la aceptación de datos antiguos, desincronización y riesgos de ACK erróneos.

TIME_WAIT es, por ende, un mecanismo de corrección, no un sinónimo de fuga de memoria. Las primeras preguntas deben ser por qué la aplicación crea tantas conexiones, si el suministro de tuplas es suficiente y qué extremo cierra activamente, no cómo hacer que el conteo sea cero.

Paso 4: Estimar la presión sobre los puertos efímeros

El valor predeterminado documentado en Linux para ip_local_port_range es 32768–60999. Con la suposición del escenario de que no hay puertos reservados, el pool de asignación automática contiene:

60999 - 32768 + 1 = 28232

Para una IP de origen, una IP de destino y un puerto de destino, existen alrededor de 28,232 slots de puertos de origen cuando las tuplas antiguas aún no se pueden reutilizar de forma segura. A 5,000 conexiones nuevas por segundo, la aplicación crea esa cantidad de tuplas en unos 5.65 segundos:

28232 / 5000 ≈ 5.65 seconds

El escenario también proporciona una duración observada de TIME_WAIT de aproximadamente 60 segundos. La demanda aproximada de cierres recientes es:

5000 × 60 = 300000 recent connections

Trescientos mil está muy por encima de 28,232, por lo que “una IP de origen, un upstream, sin reutilización de conexiones” representa un riesgo evidente de capacidad. Esto no prueba que la falla ocurra exactamente a los 5.65 segundos. La reutilización segura del kernel, las conexiones establecidas, los puertos reservados, la duración de la conexión y el comportamiento de NAT modifican el resultado real. La estimación demuestra un desajuste de orden de magnitud y le indica al investigador qué evidencia recopilar a continuación.

El mismo puerto de origen puede atender conexiones a diferentes destinos, por lo que el total de nuevas conexiones de toda la máquina no se puede dividir a ciegas entre el conteo de puertos. Con NAT, el recurso escaso puede ser en cambio las tuplas de mapeo de la dirección NAT pública hacia el destino.

Paso 5: Separar causas mediante estados, errores y paquetes

Comienza con evidencia que no modifique el comportamiento del sistema:

ss -s
ss -Htan state syn-sent | wc -l
ss -Htan state time-wait | wc -l
ss -Htan state close-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
cat /proc/sys/net/ipv4/ip_local_reserved_ports
sysctl net.ipv4.tcp_tw_reuse

Luego, ramifica el análisis según la evidencia:

Una captura debe responder tres preguntas: quién envía el primer FIN, si una conexión fallida llega a emitir un SYN y dónde ocurre la retransmisión. Un total obtenido de ss no puede probar el agotamiento de puertos, y un registro de aplicación que contiene la palabra “timeout” no puede probar la pérdida de paquetes.

Paso 6: Solucionar en orden creciente de riesgo

La primera solución es crear menos conexiones. Configura un pool de conexiones, HTTP keep-alive, multiplexación HTTP/2 u otro canal persistente adecuado para que las solicitudes compartan conexiones establecidas. Esto reduce la latencia de handshake, el consumo de CPU, el uso de puertos efímeros y TIME_WAIT de manera conjunta, abordando la causa en lugar del síntoma.

A continuación, corrige el ciclo de vida de la conexión. No cierres activamente una conexión saludable después de cada solicitud. Asigna al pool una concurrencia limitada, un tiempo de espera de inactividad (idle timeout) adecuado, una vida útil máxima y límites de concurrencia hacia el upstream. Si el servidor cierra de manera demasiado agresiva, inspecciona su configuración de keep-alive, el idle timeout del balanceador de carga y el comportamiento de despliegue. El objetivo es eliminar la rotación innecesaria de conexiones, no simplemente transferir el cierre activo al otro extremo.

Si la reutilización sigue siendo insuficiente, amplía la disponibilidad de tuplas. Tras revisar los puertos reservados, evalúa un rango efímero más amplio. Un cuello de botella hacia un único destino también puede mitigarse usando más IPs de origen o más direcciones de destino. Si hay NAT de por medio, amplía o particiona (shard) el pool de direcciones NAT públicas también; agregar IPs de origen dentro de la red de la aplicación puede no tener efecto después de la traducción.

Solo entonces evalúa las configuraciones de reutilización del kernel. Linux documenta tcp_tw_reuse como una opción para reutilizar sockets en TIME_WAIT únicamente cuando el protocolo lo considera seguro, y advierte contra cambiarlo sin asesoramiento experto. tcp_max_tw_buckets es un límite defensivo contra condiciones simples de denegación de servicio; la documentación dice explícitamente que no se debe reducir artificialmente. Excederlo destruye los sockets en time-wait de inmediato y registra una advertencia. Cualquier cambio requiere evidencia de la versión del kernel, timestamps, comportamiento del par, pruebas de carga y un plan de reversión.

No utilices RST como una optimización general. RST aborta la conexión y descarta el estado de inmediato; los datos que la aplicación no haya procesado de forma segura pueden perderse. "Hacer que el servidor cierre primero" tampoco es una solución universal. Solo traslada la presión de TIME_WAIT y puede generar presión de puertos, memoria o estados de conexión en el servidor.

Paso 7: Verificar la solución

La verificación debe cubrir capacidad, corrección y evidencia de red:

1. Reproduce el mismo tráfico y compara las nuevas conexiones TCP por segundo, la tasa de reutilización y el rendimiento de solicitudes.
2. Monitorea SYN-SENT, TIME_WAIT, CLOSE-WAIT, descriptores de archivo y uso de puertos locales a lo largo del tiempo en lugar de en un solo instante.
3. Captura muestras fallidas para confirmar si sale el SYN, si regresa el SYN+ACK y qué extremo cierra activamente.
4. Inspecciona métricas de transporte del cliente, NAT, balanceador de carga y upstream para no pasar por alto cuellos de botella de salida.
5. Ejecuta una prueba sostenida y verifica que no haya datos truncados, aumentos en el conteo de RST, peor latencia de cola (tail latency) o conexiones obsoletas en el pool.

El éxito significa que el mismo rendimiento de negocio genera muchas menos conexiones nuevas, los errores desaparecen, el margen de puertos se mantiene estable y la corrección de las solicitudes no sufre regresiones. Un menor conteo de TIME_WAIT es consecuencia de esas mejoras, no el único objetivo.

Respuesta de ejemplo sólida

“Primero establecería dos hechos a partir del incidente: qué extremo envía el primer FIN y si ‘timeout’ se refiere a un error local inmediato o a un SYN que no recibe respuesta. TIME_WAIT normalmente le corresponde al cerrador activo que envía el ACK final, mientras que varias fallas no relacionadas pueden parecer un tiempo de espera agotado de conexión.

Durante el establecimiento, el cliente envía SYN con el número de secuencia inicial x. El SYN+ACK del servidor reconoce x+1 y proporciona su propio número y. Luego, el cliente reconoce y+1. Ambos extremos han intercambiado y confirmado el espacio de secuencias, y el proceso puede rechazar intentos de conexión duplicados antiguos. El cierre finaliza las dos direcciones de envío de forma independiente, por lo que la secuencia común es FIN, ACK, FIN, ACK. El cerrador activo avanza por FIN-WAIT-1 y FIN-WAIT-2, envía ACK al FIN del par y entra en TIME_WAIT. Ese estado le permite responder con un nuevo ACK a un FIN retransmitido si el ACK final se perdió y evita que duplicados demorados de una conexión antigua contaminen la reutilización inmediata de la misma 4-tupla.

La capacidad en el escenario resulta sospechosa. Los puertos 32768 a 60999 brindan 28,232 puertos efímeros por defecto. Una IP de origen crea 5,000 conexiones por segundo hacia el mismo destino, y la duración observada de TIME_WAIT es de unos 60 segundos, lo que implica aproximadamente 300,000 cierres recientes, muy por encima de los slots de puertos disponibles. No me detendría en la estimación. Si connect falla de inmediato con un error de dirección local y sin emitir un SYN, investigaría el suministro de tuplas en el host y en el NAT. Si muchos sockets permanecen en SYN-SENT y retransmiten, investigaría la ruta, las ACL, el listen backlog y el upstream.

Primero agregaría pooling, keep-alive o multiplexación HTTP/2 para reducir la creación de nuevas conexiones. Luego revisaría los idle timeouts del pool, el comportamiento de cierre del upstream y la capacidad del NAT. Si la carga de trabajo aún necesita una tasa alta de establecimiento, consideraría ampliar el rango efímero, usar más direcciones de origen o distribuir los destinos. tcptwreuse solo es seguro bajo ciertas condiciones de protocolo y Linux advierte contra cambios arbitrarios. No empezaría acortando TIME_WAIT, reduciendo el límite de buckets ni forzando cierres con RST. Finalmente, validaría la tasa de nuevas conexiones, errores, cada estado TCP relevante, capturas de paquetes y métricas de NAT bajo la misma carga.”

Errores comunes

• Describir el handshake como un simple “saludo” → Omite la semántica de secuencias y acuses de recibo y no logra explicar por qué dos mensajes son insuficientes → derívalo a partir de ambos números de secuencia iniciales y la tercera confirmación.
• Asumir que el cliente siempre es dueño de TIME_WAIT → El rol de cierre activo determina el estado, no la etiqueta de cliente → identifica el primer FIN y el ACK final.
• Tratar el cierre como exactamente cuatro paquetes → ACK y FIN pueden combinarse y existe el cierre simultáneo → describe dos direcciones independientes y sus transiciones de estado.
• Calificar cada conteo alto de TIME_WAIT como una fuga → Las conexiones cortas generan este estado de manera natural → combina tasa de creación, rango, tipo de error y evidencia de paquetes.
• Culpar al agotamiento de puertos de cada timeout de conexión → La pérdida de SYN, ACLs, sobrecarga del upstream y presión en el listen backlog también pueden causar timeouts → separa la falla local inmediata de la retransmisión de SYN.
• Reducir tcpmaxtw_buckets como primera opción → Exceder el límite destruye el estado prematuramente y Linux advierte explícitamente contra reducirlo de forma artificial → reduce la rotación antes de expandir la capacidad.
• Usar RST en lugar de un cierre normal → La eliminación inmediata del estado puede descartar datos no entregados de forma segura → conserva el cierre basado en FIN para terminaciones normales y reserva RST para abortos genuinos.
• Limitarse a ampliar el rango de puertos de la aplicación → El límite real puede estar en el pool de mapeo público del NAT → verifica la capacidad de tuplas en el host de origen, el dispositivo de salida y el upstream.

Preguntas de seguimiento

Pregunta de seguimiento 1: ¿Cómo se recupera TIME_WAIT cuando se pierde el ACK final?

El cerrador pasivo permanece en LAST-ACK esperando el acuse de recibo de su FIN. Si el ACK final no llega, retransmite el FIN. El cerrador activo aún conserva el estado TIME_WAIT, reconoce el FIN retransmitido, envía el ACK nuevamente y reinicia el temporizador de espera. Si el extremo activo hubiera olvidado la conexión, ese FIN podría disparar un RST y ya no se preservaría el cierre normal confiable.

Pregunta de seguimiento 2: ¿En qué se diferencia una gran cantidad de conexiones en CLOSE_WAIT?

CLOSE-WAIT significa que el par envió FIN y la pila TCP local notificó a la aplicación, pero la aplicación no ha cerrado su propia dirección de envío; la aplicación local aún puede enviar datos restantes. Por lo general, apunta al ciclo de vida de la aplicación, manejo de excepciones o administración de descriptores de archivo. TIME_WAIT significa que el cerrador activo completó el intercambio y está protegiendo la recuperación del ACK final y el aislamiento de segmentos antiguos. Ambos aparecen durante el cierre, pero sus causas, la posibilidad de transportar datos restantes y sus soluciones difieren.

Pregunta de seguimiento 3: ¿Cómo puede un mismo puerto de origen pertenecer a múltiples conexiones?

La 4-tupla completa identifica una conexión. Si la dirección de destino o el puerto de destino difieren, el mismo puerto local puede identificar otra conexión. Por lo tanto, la presión sobre los puertos efímeros debe analizarse por IP de origen y concentración de destino. El tráfico distribuido entre muchos destinos puede admitir más conexiones totales de lo que sugiere un solo rango de puertos, mientras que la concentración en un único upstream agota las tuplas utilizables más rápidamente.

Pregunta de seguimiento 4: ¿Escalar el cliente a diez instancias resolverá el agotamiento?

No necesariamente. Direcciones IP de origen independientes aumentan el suministro de tuplas del lado del host, pero si todas las instancias comparten un NAT con solo unas pocas IPs públicas, las conexiones convergen en el pool de mapeo del NAT. El upstream también puede aplicar límites de tasa por IP de origen, y las conexiones concurrentes adicionales pueden exceder su listen backlog, descriptores de archivo o la capacidad del balanceador de carga.

Pregunta de seguimiento 5: ¿Cuándo vale la pena considerar tcptwreuse?

Primero demuestra que la reutilización de conexiones, la configuración del pool, el rango de puertos y la capacidad de NAT siguen siendo insuficientes. Luego, revisa la versión exacta del kernel, el comportamiento de los timestamps TCP y las características del par. Linux permite la reutilización únicamente cuando es segura desde la perspectiva del protocolo y advierte explícitamente contra modificar la opción de forma arbitraria. Prueba la reconexión y la corrección de datos bajo carga, monitorea RSTs, fallas y latencia, y prepara un plan de reversión. No es un sustituto de la reutilización de conexiones a nivel de aplicación.