Entrevista de redes: ¿Cómo detecta y recupera TCP la pérdida de paquetes?

Planteamiento y alcance

Un emisor transmite cinco segmentos de datos TCP consecutivos de 1,000 bytes comenzando en el número de secuencia 1,000. El segundo segmento se pierde y los siguientes tres llegan al receptor. Deduzca la secuencia de ACK, SACK y retransmisión, y luego compare los límites del tiempo de espera, la retransmisión rápida y la detección moderna de pérdidas.

Asuma que la conexión está establecida, los cinco segmentos transportan datos, las ventanas de recepción y de congestión permiten que los cinco estén en tránsito, el receptor puede almacenar en búfer datos fuera de orden y SACK se negoció durante el protocolo de enlace (handshake). Los números de secuencia cuentan bytes y los rangos a continuación son semiabiertos. Sin SACK, el ACK acumulativo y el razonamiento clásico de retransmisión rápida siguen siendo válidos; el emisor simplemente pierde información sobre qué bytes con números de secuencia superiores han llegado.

La pregunta se adapta a roles de backend, infraestructura, SRE, cliente, redes e ingeniería de software en general. Su competencia central es deducir y validar el estado del protocolo de transporte, por lo que la categoría es general. No aborda el aislamiento entre flujos de HTTP/3 ni el establecimiento, cierre y TIME_WAIT de TCP.

Qué evalúa el entrevistador

Primero, ¿puede el candidato indicar las unidades correctamente? TCP numera bytes. El número de secuencia de un segmento identifica su primer byte de datos, y un ACK acumulativo nombra el siguiente byte que espera el receptor; no es un contador de paquetes.

Segundo, ¿puede el candidato deducir una línea de tiempo? Una vez que falta el segundo segmento, los segmentos posteriores fuera de orden no avanzan el ACK acumulativo, pero sí provocan ACK duplicados. El tercer ACK duplicado es la señal clásica de retransmisión rápida de RFC 5681. Contar el ACK que reconoce por primera vez el segmento A como duplicado genera un error de desfase por uno (off-by-one).

Tercero, ¿puede el candidato separar los mecanismos de recuperación? RTO cubre pérdidas que no producen suficiente retroalimentación de ACK. La retransmisión rápida utiliza ACK duplicados generados por datos posteriores para recuperarse antes. SACK describe bloques de bytes no contiguos recibidos para que el emisor pueda evitar reenviar datos entregados, pero ni reemplaza al ACK acumulativo ni controla de forma independiente la ventana de congestión.

Cuarto, ¿puede el candidato explicar la incertidumbre? El reordenamiento o la duplicación también pueden crear ACK duplicados, y un pico de RTT puede causar un tiempo de espera agotado sin una pérdida real. La entrega confiable, la detección de pérdidas y el control de congestión interactúan, pero son conceptos distintos.

Quinto, ¿puede la respuesta ir más allá de un eslogan de libro de texto? Un candidato sólido explica por qué un vuelo pequeño o una pérdida de cola puede no crear tres ACK duplicados y señala que las implementaciones pueden usar RACK-TLP para reducir la dependencia de un umbral fijo de conteo de paquetes y RTO combinando los tiempos de transmisión con la retroalimentación de SACK.

Preguntas aclaratorias

• ¿Los números de secuencia y las longitudes se expresan en bytes? Convierta primero las etiquetas relativas de paquetes en rangos de bytes. SYN y FIN también consumen espacio de secuencia, pero este problema contiene solo datos en una conexión establecida.
• ¿Se negoció SACK durante el handshake? Sin él, la recuperación depende de los ACK acumulativos y del algoritmo elegido por el emisor. Con él, los ACK duplicados pueden transportar bloques fuera de orden recibidos.
• ¿Es el vuelo lo suficientemente grande como para generar tres ACK duplicados? Deben llegar al menos tres segmentos nuevos después del hueco para suministrar la señal clásica. Un segmento de cola perdido normalmente no tiene datos posteriores para crear esos ACK.
• ¿Estamos explicando RFC 5681 o un kernel concreto? El umbral clásico es útil para la deducción. Una pila real puede usar un umbral configurable, recuperación SACK, RACK-TLP u otra extensión, por lo que las conclusiones de trazas de paquetes necesitan el sistema operativo y la versión.
• ¿El objetivo es la corrección del protocolo o el diagnóstico de rendimiento? La corrección explica la entrega ordenada final. El diagnóstico también necesita RTT, RTO, estado de congestión, reordenamiento, puntos de captura y comportamiento de offload de la NIC.

Estructura de respuesta de 30 segundos

“Los números de secuencia de TCP cuentan bytes y el ACK acumulativo es el siguiente byte esperado. El segmento A cubre de 1,000 a 1,999, por lo que recibirlo produce ACK 2,000. El segmento B, que cubre de 2,000 a 2,999, se pierde. Los siguientes tres segmentos se pueden almacenar en búfer, pero el hueco aún comienza en 2,000, por lo que cada uno produce otro ACK 2,000. Si se negoció SACK, esos ACK también informan los bytes recibidos de 3,000 a 5,999.

En la ruta clásica de RFC 5681, el tercer ACK duplicado activa la retransmisión rápida de los bytes 2,000 a 2,999 sin esperar a RTO. Una vez que se llena el hueco, el ACK acumulativo avanza directamente a 6,000. Si el vuelo es demasiado pequeño, se pierde la cola o se detiene la retroalimentación de ACK, el emisor puede necesitar RTO. RTO se deriva del RTT suavizado y la variación de RTT, luego se aplica un retroceso exponencial tras un tiempo de espera agotado, con una reducción más fuerte de la ventana de congestión. SACK mejora la precisión de recuperación para múltiples huecos. El RACK-TLP moderno también puede usar el tiempo de transmisión, la retroalimentación de SACK y una sonda para detectar la pérdida de cola o de retransmisión más rápido. En una traza, correlacionaría los ACK acumulativos, los bloques SACK, el tiempo de retransmisión y la pila TCP real en lugar de tratar el reordenamiento o una etiqueta del analizador como prueba de pérdida”.

Análisis paso a paso a profundidad

Paso 1: Fijar los rangos de bytes y el ACK acumulativo

Los cinco rangos de bytes lógicos son:

A: SEQ=1000, LEN=1000 -> [1000, 2000)  delivered
B: SEQ=2000, LEN=1000 -> [2000, 3000)  lost
C: SEQ=3000, LEN=1000 -> [3000, 4000)  delivered
D: SEQ=4000, LEN=1000 -> [4000, 5000)  delivered
E: SEQ=5000, LEN=1000 -> [5000, 6000)  delivered

Después de que llega A, el receptor tiene los bytes 1,000 a 1,999 de forma contigua, por lo que envía ACK=2000. Este ACK avanza el límite de confirmación por primera vez. Es un ACK nuevo, no un duplicado.

Después de que B se pierde, C es aceptable dentro de la ventana de recepción pero no puede llenar el hueco que comienza en 2,000. El receptor puede almacenar en búfer C, mientras que su confirmación acumulativa sigue siendo ACK=2000. Lo mismo se aplica a D y E. RFC 9293 define el campo ACK como el siguiente número de secuencia esperado por el par receptor, razón por la cual no salta al final de cada segmento fuera de orden.

Paso 2: Deducir los tres ACK duplicados y la retransmisión rápida

En la ruta clásica de RFC 5681, cada llegada de C, D y E provoca un ACK=2000 duplicado inmediato:

Receive A             -> ACK 2000                     new ACK
Receive C; B is absent -> ACK 2000 + SACK [3000,4000) duplicate ACK 1
Receive D; B is absent -> ACK 2000 + SACK [3000,5000) duplicate ACK 2
Receive E; B is absent -> ACK 2000 + SACK [3000,6000) duplicate ACK 3
Sender retransmits B   -> SEQ 2000, LEN 1000
Receiver gets B        -> ACK 6000                     gap closes

Cuando el tercer ACK duplicado llega al emisor, este infiere que B probablemente se perdió y retransmite de forma rápida [2000,3000) en lugar de esperar el temporizador de retransmisión. C, D y E ya están almacenados en búfer. Cuando llega B, el rango contiguo se extiende inmediatamente hasta el byte 5,999, por lo que el ACK acumulativo puede pasar directamente de 2,000 a 6,000.

Tres ACK duplicados son una heurística de pérdida, no una prueba matemática. El reordenamiento de la red puede entregar primero datos con números de secuencia más altos y producir el mismo patrón de ACK. Los segmentos de datos o ACK duplicados también pueden crearlo. El umbral equilibra una reparación más rápida frente a clasificar erróneamente el reordenamiento, y las pilas reales pueden añadir otros algoritmos.

Paso 3: Indicar qué aporta SACK y qué no

Un ACK acumulativo solo dice que todo lo anterior a 2,000 llegó de forma contigua. Una opción SACK puede informar adicionalmente bloques no contiguos retenidos en el búfer de recepción, como [3000,6000). Cierra una brecha de información: el emisor sabe que llegaron datos con números de secuencia más altos y puede omitir esos bloques mientras repara múltiples huecos.

SACK tiene tres límites importantes:

1. SACK-Permitted debe negociarse en el intercambio SYN antes de que el receptor pueda incluir bloques SACK en ACK posteriores.
2. Un bloque SACK no avanza el ACK acumulativo de 2,000 a 6,000. Solo llenar [2000,3000) avanza el límite contiguo.
3. SACK es información consultiva del receptor. Ayuda al emisor a mantener un registro de recuperación (scoreboard); el algoritmo del emisor sigue eligiendo el orden de retransmisión y la respuesta a la congestión.

Si se pierden tanto B como D, una retransmisión rápida repara inicialmente solo B. La recuperación clásica sin SACK tiene menos información sobre si D llegó. SACK puede informar los bloques separados C y E, lo que permite al emisor identificar ambos huecos con mayor precisión y evitar reenviar C y E ya almacenados en búfer.

Paso 4: Explicar por qué RTO sigue siendo necesario

La retransmisión rápida depende de la retroalimentación de ACK. Si el emisor transmite solo A y B y pierde el segmento de cola B, no llega ningún C, D o E para crear ACK duplicados. Si la ruta de ACK inversa también falla, el emisor tampoco puede recopilar tres duplicados. El temporizador de retransmisión es la red de seguridad final.

RFC 6298 mantiene el tiempo de ida y vuelta suavizado SRTT, la variación de ida y vuelta RTTVAR y la granularidad del reloj G:

For the first RTT sample R:
SRTT   = R
RTTVAR = R / 2
RTO    = SRTT + max(G, 4 * RTTVAR)

For a later sample R':
RTTVAR = (1 - 1/4) * RTTVAR + 1/4 * abs(SRTT - R')
SRTT   = (1 - 1/8) * SRTT   + 1/8 * R'
RTO    = SRTT + max(G, 4 * RTTVAR)

Por ejemplo, con una primera muestra de R=120 ms y G no mayor que 240 ms, SRTT=120 ms, RTTVAR=60 ms, y la fórmula sin procesar da 360 ms. RFC 6298 recomienda redondear un RTO inferior a un segundo hacia arriba a un segundo, y recomienda un RTO inicial de un segundo antes de que exista una muestra de RTT. Los kernels reales pueden usar algoritmos más nuevos y detalles de implementación, por lo que un intervalo que no sea exactamente de un segundo no refuta por sí mismo la recuperación por tiempo de espera.

Cuando el temporizador expira, el emisor retransmite los datos no reconocidos más antiguos y duplica el RTO antes de reiniciar el temporizador. El retroceso exponencial evita inyectar datos repetidamente en una ruta persistentemente congestionada o rota. Medir el RTT directamente a partir de un segmento retransmitido crea ambigüedad: ¿el ACK cubrió el original o la retransmisión? Sin marcas de tiempo que resuelvan esa ambigüedad, el algoritmo de Karn excluye esa muestra de las actualizaciones de RTT.

Paso 5: Separar la recuperación de confiabilidad de la respuesta a la congestión

La retransmisión responde "¿cómo reemplazamos los bytes faltantes?". El control de congestión responde "¿cuántos datos pueden permanecer en vuelo después?". Una señal de pérdida afecta a ambos, pero los dos trabajos son diferentes.

El RFC 5681 clásico trata el RTO como la señal más fuerte. ssthresh no es más que max(FlightSize/2, 2*SMSS), y cwnd cae a no más de un segmento de tamaño completo antes de que se reanude el inicio lento (slow start). Tres ACK duplicados muestran que los segmentos posteriores aún están llegando y el reloj de ACK sobrevive, por lo que el emisor entra en retransmisión rápida y recuperación rápida, reduciendo la ventana sin aplicar el mismo restablecimiento de RTO.

El control de flujo es otro límite independiente. La rwnd anunciada por el receptor protege la capacidad del búfer de recepción, mientras que la cwnd del emisor protege la red. Ambas restringen el envío real. SACK describe el estado de recepción; no amplía ni rwnd ni cwnd.

Paso 6: Agregar el límite de RACK-TLP moderno

Una regla fija de tres ACK duplicados tiene un rendimiento deficiente para vuelos cortos, pérdida de cola, retransmisiones perdidas y reordenamiento sustancial. RFC 8985 recomienda RACK-TLP como una alternativa al conteo tradicional de ACK duplicados. RACK combina el último tiempo de transmisión de cada segmento, el RTT y la retroalimentación de SACK para inferir si una transmisión anterior se perdió. TLP envía una sonda cuando la retroalimentación de ACK es escasa cerca de la cola, intentando restaurar el reloj de ACK antes de RTO.

La respuesta de la entrevista debe deducir primero el mecanismo clásico y luego establecer el límite de implementación. Una traza real puede mostrar recuperación con menos de tres ACK duplicados o una sonda de cola. Verifique el algoritmo y la versión de la pila. Decir que cada implementación “espera exactamente tres duplicados o siempre espera a RTO” confunde el modelo pedagógico con el comportamiento actual completo.

Paso 7: Validar con evidencia de paquetes, no con un conteo de retransmisiones

Construya una línea de tiempo que se pueda conciliar entre observaciones:

1. Capture en el emisor y en el receptor para ubicar dónde desaparece el segmento original en lugar de depender de un solo punto de observación.
2. Alinee SEQ, LEN, ACK acumulativo y bloques SACK para demostrar que existe un hueco de bytes.
3. Cuente los duplicados solo después del ACK nuevo anterior; no cuente el ACK de referencia en sí.
4. Compare el tiempo de retransmisión con el tercer ACK duplicado o el RTO esperado, luego verifique el estado de congestión, el RTT y el algoritmo de recuperación de la pila.
5. Correlacione el retraso de la aplicación con la pérdida en la interfaz, el reordenamiento y las señales de cola en lugar de asignar la causa raíz a partir de una sola etiqueta de Wireshark.

Los valores tcp.analysis.fast_retransmission, tcp.analysis.retransmission y tcp.analysis.duplicate_ack de Wireshark son inferencias del analizador a partir de la captura disponible, no indicadores transportados en el encabezado TCP. TSO y GRO también pueden hacer que los límites de los segmentos de captura del host difieran de los paquetes en el cable. Las conclusiones importantes necesitan una verificación cruzada con los espacios de secuencia y los tiempos de ambos extremos.

Ejemplo de respuesta de alta calidad

“Lo deduciría en el espacio de secuencia de bytes. A tiene SEQ=1000 y una longitud de 1,000, por lo que después de recibir A, el receptor espera a continuación el byte 2,000 y envía un nuevo ACK 2,000. B cubre los bytes 2,000 a 2,999 y se pierde. C, D y E cubren los bytes 3,000 a 5,999 y llegan, pero ninguno llena el hueco en 2,000. Por lo tanto, el ACK acumulativo permanece en 2,000. Cada segmento fuera de orden genera un ACK duplicado. Si se negoció SACK, el receptor también informa progresivamente que los bytes 3,000 a 5,999 están almacenados en búfer.

Bajo el comportamiento clásico de RFC 5681, C, D y E producen tres ACK duplicados para 2,000. El tercero hace que el emisor retransmita rápidamente B sin esperar a RTO. Cuando llega B, el búfer de recepción se vuelve contiguo y el ACK acumulativo salta directamente a 6,000. El error común de desfase por uno es contar el primer ACK 2,000 después de A como un duplicado; es el ACK nuevo que avanza el límite.

Si la pérdida está en la cola o el vuelo es demasiado pequeño, no existen tres segmentos posteriores, por lo que RTO es la red de seguridad final. RTO se estima a partir del RTT suavizado más cuatro veces la variación del RTT, y RFC 6298 aplica un retroceso exponencial después de un tiempo de espera agotado. RTO normalmente causa una reducción más fuerte de la ventana de congestión que la recuperación rápida porque el reloj de ACK puede haberse detenido. SACK le dice al emisor qué bytes superiores no contiguos llegaron, lo cual es especialmente útil para múltiples huecos. No avanza el ACK acumulativo por sí mismo y no es un algoritmo de control de congestión.

Las pilas reales también pueden usar RACK-TLP para inferir pérdidas a partir del tiempo de transmisión y la retroalimentación de SACK, y para sondear pérdidas de cola. Tres ACK duplicados son la deducción clásica requerida, no el único desencadenante posible en cada traza. En el diagnóstico, alinearía números de secuencia, longitudes, ACK acumulativos, bloques SACK y tiempos de retransmisión en ambos extremos, verificaría la pila y la configuración de offload, y luego distinguiría la pérdida real del reordenamiento, la pérdida en la ruta de ACK o la inferencia del analizador”.

Errores comunes

• Tratar el ACK como un número de paquete → TCP reconoce el espacio de bytes contiguo → deduzca el siguiente byte esperado con SEQ + LEN.
• Contar ACK 2,000 después de A como duplicado 1 → avanza el límite acumulativo por primera vez → comience a contar ACK posteriores con el mismo número que no lo avancen.
• Afirmar que C produce ACK 4,000 → el hueco de bytes en B permanece → mantenga el ACK acumulativo en 2,000 e informe C con SACK.
• Afirmar que SACK reemplaza al ACK acumulativo → TCP todavía avanza un límite contiguo acumulativamente → trate a SACK como información adicional de bloques no contiguos.
• Afirmar que tres duplicados prueban la pérdida → el reordenamiento y la duplicación pueden crear la misma señal → llámelo la heurística clásica de pérdida y verifique la línea de tiempo.
• Afirmar que cada pérdida se retransmite rápidamente → una pérdida de cola o un vuelo pequeño pueden no crear suficientes ACK duplicados → retenga el RTO y explique la mejora de RACK-TLP.
• Combinar retransmisión y control de congestión → reparar datos y limitar la tasa de envío resuelven problemas diferentes → establezca la acción de recuperación, cwnd y rwnd por separado.
• Tratar una etiqueta de Wireshark como un bit de protocolo en el cable → la etiqueta se infiere del contexto de captura y puede estar distorsionada por offload → verifique de forma cruzada los espacios de secuencia y los tiempos de ambos extremos.

Preguntas de seguimiento

Pregunta de seguimiento 1: Si solo se envían dos segmentos y el segundo se pierde, ¿ocurre una retransmisión rápida?

No en la ruta clásica. Ningún dato con número de secuencia más alto llega al receptor, por lo que no puede generar tres ACK duplicados. El emisor normalmente espera al RTO. Una pila con RACK-TLP puede enviar una sonda de pérdida de cola para solicitar retroalimentación, pero RTO sigue proporcionando el respaldo si la sonda falla.

Pregunta de seguimiento 2: ¿Qué pasa si C simplemente se reordena y B llega más tarde en su transmisión original?

Recibir C genera un ACK duplicado 2,000 y un bloque SACK correspondiente. Si B llega antes de que se alcance el umbral de pérdida, el ACK acumulativo avanza y se evita la retransmisión. Si el reordenamiento es lo suficientemente profundo como para activar primero tres duplicados, la retransmisión rápida clásica puede ser espuria. RACK utiliza una ventana de reordenamiento basada en el tiempo para reducir este modo de falla de umbral fijo de paquetes.

Pregunta de seguimiento 3: ¿Por qué SACK es más valioso cuando se pierden tanto B como D?

El receptor puede informar los bloques C y E entregados. El emisor utiliza esa información en un registro de huecos, omite los rangos con SACK y repara B y D. Sin SACK, el ACK acumulativo solo expone el hueco más a la izquierda. Reno clásico tiene menos información sobre múltiples pérdidas en una ventana y puede necesitar ACK parciales o eventualmente RTO.

Pregunta de seguimiento 4: Si la primera muestra de RTT es de 120 ms, ¿por qué no establecer RTO en 120 ms?

El RTT varía con las colas y los cambios de ruta. RFC 6298 inicializa RTTVAR a R/2; cuando G no es mayor que 4 × RTTVAR, el RTO sin procesar es R + 4 × R/2 = 3R. Eso es 360 ms aquí, y el RFC recomienda redondearlo hacia arriba a al menos un segundo. Usar un RTT directamente causaría que pequeñas variaciones provoquen tiempos de espera agotados espurios y retransmisiones innecesarias.

Pregunta de seguimiento 5: Una captura muestra una retransmisión pero no tres ACK duplicados. ¿Eso demuestra RTO?

No. La captura puede perder los ACK de la ruta inversa, el punto de observación puede estar antes o después del offload, y la pila puede usar RACK-TLP u otro algoritmo de recuperación. Compare la retransmisión con el tiempo del ACK anterior, inspeccione SACK y las sondas de cola, verifique el estado del kernel del lado del emisor y complete la evidencia con una captura del lado del receptor.

Pregunta de seguimiento 6: ¿Por qué la respuesta a la congestión después de un tiempo de espera agotado es normalmente más fuerte que después de una recuperación rápida?

Tres ACK duplicados muestran que los segmentos posteriores están saliendo de la red y llegando al receptor, por lo que el reloj de ACK sigue funcionando. RTO puede significar que un vuelo completo o una ruta de retroalimentación no avanzaron. Por lo tanto, el RFC 5681 clásico reduce cwnd a no más de un segmento de tamaño completo y reinicia el inicio lento después del tiempo de espera agotado, mientras que la recuperación rápida conserva una ventana de envío reducida.