El «Recent Acknowledgment» (RACK) es un algoritmo de detección de pérdidas de TCP que determina si se ha perdido un segmento en función del tiempo transcurrido desde su envío, en lugar de contar los acuses de recibo duplicados, como hacen las pilas TCP más antiguas. Este cambio mejora la precisión de la detección de pérdidas durante la reordenación de paquetes y las pérdidas en la cola, y la optimización VOS TCP de Versaofrece RACK como método de detección de pérdidas seleccionable para acelerar la recuperación.
Puntos clave
- RACK detecta los segmentos TCP perdidos basándose en el tiempo transcurrido, y no en el recuento de ACK duplicados.
- Tolera la reordenación de paquetes en lugar de confundirla con una pérdida.
- La sonda de pérdida de cola (TLP) se utiliza junto con el sistema RACK para detectar caídas en la cola del avión.
- Estandarizado en el RFC 8985, el RACK-TLP es ahora habitual en las pilas TCP modernas.
- La optimización VOS TCP ofrece RACK como método seleccionable de detección de pérdidas.
En esta página: Por qué es importanteCómo funcionaComponentes de RACKRACK y VersaPreguntas frecuentes
¿Por qué es importante el RACK?
La detección clásica de pérdidas en TCP —un umbral fijo de ACK duplicados, posteriormente perfeccionado mediante la recuperación basada en SACK— funciona bien en rutas sencillas, pero comete errores en dos situaciones. Puede confundir la reordenación con una pérdida, retransmitiendo un segmento que solo sufrió un retraso. Además, no detecta lo que ocurre al final de un vuelo: una vez que ya no hay más datos en cola detrás de un segmento perdido, nada desencadena los ACK duplicados que necesita el antiguo algoritmo, por lo que la recuperación recurre a un tiempo de espera de retransmisión lento en lugar de a una retransmisión rápida casi instantánea.
RACK subsana ambas deficiencias basándose en el tiempo en lugar del recuento de ACK, junto con un mecanismo de sondeo para los casos extremos. Las « Networks » que combinan varios enlaces subyacentes —una situación que se da habitualmente en las estructuras SD-WAN— experimentan un mayor reordenamiento entre rutas, y la tolerancia de RACK ante este fenómeno permite que el rendimiento y la latencia sean más predecibles.
¿Qué es RACK?
Cada segmento transmitido recibe una marca de tiempo de envío. Cuando llega un bloque ACK o SACK, RACK comprueba cada segmento anterior que aún no haya sido confirmado y determina si ha transcurrido suficiente tiempo —medido en función de la muestra más reciente del tiempo de ida y vuelta de la conexión— como para considerar que se ha perdido, en lugar de simplemente reordenarse. Ese umbral es la ventana de reordenación: un intervalo sin confirmar que supere aproximadamente el RTT reciente se marca como perdido y se retransmite inmediatamente; un ACK tardío de un segmento reordenado dentro de la ventana no provoca ninguna retransmisión.
El uso de la muestra RTT más reciente, en lugar de una media a largo plazo, permite que RACK reaccione rápidamente ante los cambios de latencia. Por sí solo, RACK solo evalúa cuándo llega un ACK, por lo que sigue necesitando un mecanismo para los periodos de silencio; de ahí que el RFC 8985 lo combine con Tail Loss Probe en lugar de definir RACK por sí solo.
Componentes de RACK
RACK-TLP, tal y como se estandariza en el RFC 8985, consta de dos partes. El «Recent Acknowledgment» (RACK) es el detector basado en el tiempo descrito anteriormente: se activa cada vez que llega un bloque ACK o SACK y analiza el tiempo de transmisión transcurrido para determinar si se han perdido datos sin confirmar. La sonda de pérdida de cola (TLP) cubre lo que el RACK por sí solo no puede detectar: una conexión que ha dejado de enviar datos, por lo que no llegará ningún nuevo ACK que revele una pérdida. La TLP activa un temporizador de sonda corto y, si no llega ningún ACK antes de que se active, envía un segmento de sonda —nuevos datos si están disponibles; de lo contrario, una retransmisión del último segmento— con el único fin de generar información de retorno.
Esa respuesta confirma que los datos han llegado o indica a RACK que declare el segmento perdido, evitando así el tiempo de espera más lento que, de otro modo, tendrían que aguantar las pilas más antiguas.
RACK & Versa
VersaLa optimización VOS TCP ofrece RACK como método seleccionable de detección de pérdidas TCP: la configuración de detección de pérdidas TCP viene por defecto en el recuento clásico de ACK duplicados, siendo el «reconocimiento reciente» (RACK) la alternativa que el administrador puede habilitar, implementada con la prueba de pérdida de cola (Tail Loss Probe) complementaria según la especificación de la IETF. Las rutas SD-WAN suelen combinar múltiples enlaces subyacentes con diferentes latencias, por lo que la reordenación es más habitual que en una ruta única y directa; precisamente esto es lo que RACK tolera sin una retransmisión innecesaria. La recuperación de la pérdida de segmentos finales también es importante en las rutas WAN, donde un segmento final perdido bloquearía de otro modo un flujo hasta que expirara el tiempo de espera de la retransmisión completa.
Preguntas frecuentes
¿Qué problema resuelve RACK que no resolvían los antiguos sistemas de detección de pérdidas de TCP?
El recuento de ACK duplicados parte de la base de que un número fijo de ACK fuera de orden implica una pérdida, lo que falla en casos de reordenación habitual y no detecta nada cuando se pierde el último segmento de una ráfaga. RACK utiliza en su lugar el tiempo transcurrido, detectando ambos casos sin que se activen retransmisiones provocadas por la fluctuación normal.
¿En qué se diferencia el RACK de la retransmisión rápida basada en ACK duplicados?
La retransmisión rápida declara la pérdida tras un número fijo de ACK duplicados, independientemente del tiempo que haya transcurrido realmente. RACK, por el contrario, compara el tiempo transcurrido desde que se envió un segmento con el tiempo de ida y vuelta más reciente de la conexión, lo que le permite distinguir entre un paquete lento o reordenado y uno que se haya perdido realmente.
¿Qué es una sonda de pérdida de cola y qué relación tiene con el RACK?
TLP es el mecanismo complementario de RACK para los casos en los que una conexión deja de enviar datos, por lo que no puede llegar ningún nuevo ACK que revele una pérdida. TLP activa un temporizador corto y envía un segmento de sondeo si no aparece ningún ACK, generando así la información que RACK necesita para detectar la pérdida rápidamente.
¿Es RACK el algoritmo predeterminado de detección de pérdidas en los sistemas modernos?
RACK-TLP se estandarizó como RFC 8985 en 2021 y, desde entonces, se ha convertido en el mecanismo predeterminado de recuperación de pérdidas en las pilas de protocolos más habituales, incluido Linux. Coexiste con SACK en lugar de sustituirlo, ya que RACK sigue basándose en la información de SACK para identificar los segmentos que faltan.
¿Sustituye RACK a TCP SACK?
No. SACK (Confirmación selectiva) indica al remitente qué segmentos han llegado, y RACK utiliza esa información como dato de entrada. RACK es la capa de decisión que interpreta los datos de SACK y las marcas de tiempo de transmisión para determinar cuándo ha transcurrido el tiempo suficiente como para considerar que una interrupción en la transmisión es una pérdida; no es un sustituto del propio SACK.
Más información sobre RACK
Si quieres saber más, estas son algunas fuentes en las que confiamos.
| RFC 8985: Algoritmo de detección de pérdidas de RACK-TLP | RFC 6675: Recuperación de pérdidas basada en SACK |
|---|---|
| El estándar de la IETF que define conjuntamente RACK y TLP: los cálculos de la ventana de reordenación, la gestión del RTT y el funcionamiento del temporizador de sondeo. | El algoritmo de recuperación conservador RACK, basado en el envío de ACK y SACK duplicados, se diseñó para mejorar el rendimiento en casos de reordenación y pérdida de paquetes al final de la cola. |
Términos relacionados
Si estás leyendo sobre RACK, te conviene echar un vistazo a lo siguiente.
| Protocolo de puerta de enlace fronteriza | Seguridad de la capa de transporte | Protocolo de mensajes de control de Internet |
|---|---|---|
| El protocolo de enrutamiento que permite el intercambio de información sobre la accesibilidad entre sistemas autónomos; las sesiones de BGP se ejecutan sobre TCP, por lo que la recuperación ante pérdidas de TCP también les afecta. | El protocolo de «handshake y registro» que protege la mayor parte del tráfico web y de API a través de TCP, y que depende del propio mecanismo de recuperación de pérdidas de TCP para garantizar una entrega puntual. | El protocolo de la capa de red que se utiliza para el diagnóstico y la notificación de errores; a diferencia de RACK, el ICMP se sitúa por debajo del TCP y no interviene en la detección de pérdidas de este último. |