Qu'est-ce que le RACK ?

Le « Recent Acknowledgment » (RACK) est un algorithme de détection des pertes TCP qui détermine si un segment a été perdu en se basant sur le temps écoulé depuis son envoi, plutôt qu’en comptant les accusés de réception en double comme le font les anciennes piles TCP. Ce changement rend la détection des pertes plus précise lors du réordonnancement des paquets et des « tail drops », et l’optimisation VOS TCP d’ Versapropose le RACK comme méthode de détection des pertes sélectionnable afin d’accélérer la récupération.

Points clés à retenir

• RACK détecte les segments TCP perdus en se basant sur le temps écoulé, et non sur le nombre d'ACK en double.
• Il tolère le réordonnancement des paquets au lieu de le confondre avec une perte.
• La sonde TLP (Tail Loss Probe) fonctionne en association avec le système RACK pour détecter les chutes de charge à l'arrière de l'appareil.
• Normalisé dans la RFC 8985, le protocole RACK-TLP est désormais couramment utilisé dans les piles TCP modernes.
• L'optimisation VOS TCP propose RACK comme méthode de détection des pertes sélectionnable.

Sur cette page : Pourquoi est-ce important ? · Comment ça marche · Les composants de RACK · RACK et Versa · FAQ

Pourquoi le RACK est-il important ?

La détection classique des pertes TCP – un seuil fixe de duplicata d’ACK, affiné par la suite par la récupération basée sur le protocole SACK – fonctionne bien sur des chemins simples, mais elle se trompe dans deux situations. Elle peut confondre le réordonnancement avec une perte, et retransmettre ainsi un segment qui n’a subi qu’un simple retard. De plus, elle est aveugle en fin de transmission : dès qu’il n’y a plus de données en file d’attente derrière un segment perdu, rien ne déclenche les ACK en double dont l’ancien algorithme a besoin, de sorte que la récupération se rabat sur un délai d’expiration de retransmission lent au lieu d’une retransmission rapide quasi instantanée.

RACK comble ces deux lacunes en s'appuyant sur le temps plutôt que sur le nombre d'ACK, tout en intégrant un mécanisme de sondage pour les cas limites. Les « Networks » qui combinent plusieurs liaisons sous-jacentes – une situation couramment rencontrée dans les structures SD-WAN – sont davantage sujettes au réordonnancement inter-chemins, et la tolérance de RACK à cet égard permet de maintenir un débit et une latence plus prévisibles.

Qu'est-ce que le RACK ?

Chaque segment transmis est muni d’un horodatage d’envoi. Lorsqu’un bloc ACK ou SACK arrive, le RACK vérifie chaque segment antérieur n’ayant pas encore fait l’objet d’un accusé de réception et détermine si un délai suffisant s’est écoulé – mesuré par rapport à l’échantillon de temps aller-retour (RTT) le plus récent de la connexion – pour considérer que ce segment doit être considéré comme perdu plutôt que simplement réorganisé. Ce seuil correspond à la fenêtre de réordonnancement : un segment non acquitté depuis une durée supérieure à environ le RTT récent est marqué comme perdu et retransmis immédiatement ; en revanche, l’ACK tardif d’un segment réordonnancé, s’il survient pendant cette fenêtre, n’entraîne pas de retransmission.

L'utilisation de l'échantillon RTT le plus récent, plutôt que d'une moyenne sur une longue période, permet à RACK de réagir rapidement aux variations de latence. En soi, RACK n'effectue une évaluation qu'à l'arrivée d'un ACK ; il lui faut donc un mécanisme pour gérer les périodes de silence. C'est pourquoi la RFC 8985 l'associe à la fonction « Tail Loss Probe » plutôt que de définir RACK seul.

Composants de RACK

Le protocole RACK-TLP, tel que normalisé dans la RFC 8985, comporte deux parties. Le « Recent Acknowledgment » (RACK) est le détecteur basé sur le temps décrit ci-dessus : il s’exécute chaque fois qu’un bloc ACK ou SACK arrive et évalue le temps de transmission écoulé pour déterminer si des données non acquittées ont été perdues. La fonction « Tail Loss Probe » (TLP) couvre ce que le RACK seul ne peut pas détecter : une connexion qui a cessé d’envoyer des données, et pour laquelle aucun nouvel ACK n’arrivera donc pour révéler une perte. Le TLP active un court temporisateur de sondage et, si aucun ACK n’arrive avant son déclenchement, envoie un segment de sondage – de nouvelles données si elles sont disponibles, sinon une retransmission du dernier segment – dans le seul but de générer un retour d’information.

Ce retour d'information confirme que les données sont bien arrivées, ou indique à RACK de déclarer le segment perdu, contournant ainsi le délai d'expiration plus long que les anciennes piles auraient autrement dû attendre.

RACK & Versa

VersaL’optimisation VOS TCP propose RACK comme méthode de détection des pertes TCP sélectionnable : le paramètre « TCP Loss Detection » (Détection des pertes TCP) utilise par défaut le comptage classique des ACK en double, tandis que la méthode « Recent acknowledgment » (RACK) constitue une alternative que l’administrateur peut activer ; celle-ci est mise en œuvre à l’aide de la fonction supplémentaire « Tail Loss Probe », conformément à la spécification de l’IETF. Les chemins SD-WAN combinent souvent plusieurs liaisons sous-jacentes présentant des latences différentes ; le réordonnancement est donc plus fréquent que sur un chemin unique et direct – ce que RACK tolère précisément sans retransmission inutile. La récupération après perte de segment final (Tail-drop recovery) est également importante sur les chemins WAN, où un segment final perdu bloquerait sinon un flux jusqu’à l’expiration du délai de retransmission complet.

Questions fréquentes

Quel problème RACK résout-il que les anciens systèmes de détection des pertes TCP ne parvenaient pas à résoudre ?

Le comptage des ACK en double part du principe qu’un nombre fixe d’ACK hors séquence correspond à une perte, ce qui conduit à des erreurs lors d’un réordonnancement classique, et ne fournit aucune indication lorsque le dernier segment d’un envoi est perdu. Le protocole RACK utilise plutôt le temps écoulé, ce qui permet de détecter ces deux cas sans déclencher de retransmissions dues à la gigue normale.

En quoi le protocole RACK diffère-t-il de la retransmission rapide basée sur les ACK dupliqués ?

La retransmission rapide signale une perte après un nombre fixe d'ACK en double, quel que soit le temps réellement écoulé. Le protocole RACK, quant à lui, compare le temps écoulé depuis l'envoi d'un segment au temps de aller-retour récent de la connexion, ce qui lui permet de distinguer un paquet lent ou réorganisé d'un paquet réellement perdu.

Qu'est-ce qu'une sonde de perte de queue (Tail Loss Probe) et quel est son lien avec le RACK ?

Le TLP est le mécanisme complémentaire du RACK utilisé lorsque, pour une connexion, l’envoi de données s’interrompt, empêchant ainsi l’arrivée d’un nouvel ACK qui permettrait de détecter une perte. Le TLP déclenche un compte à rebours de courte durée et envoie un segment de test si aucun ACK n’apparaît, générant ainsi le retour d’information dont le RACK a besoin pour détecter rapidement la perte.

RACK est-il l'algorithme de détection des pertes par défaut sur les systèmes modernes ?

Le protocole RACK-TLP a été normalisé sous la référence RFC 8985 en 2021 et est depuis devenu le mécanisme par défaut de récupération des pertes dans les piles réseau courantes, y compris sous Linux. Il coexiste avec le protocole SACK plutôt que de le remplacer, car RACK s'appuie toujours sur les informations fournies par SACK pour identifier les segments manquants.

Le protocole RACK remplace-t-il le protocole TCP SACK ?

Non. Le protocole SACK (Selective Acknowledgment) indique à l'expéditeur quels segments sont bien arrivés, et le protocole RACK utilise ces informations comme données d'entrée. RACK est la couche de décision qui interprète les données SACK et les horodatages de transmission afin de déterminer à quel moment un délai suffisant s'est écoulé pour considérer un intervalle comme une perte ; il ne remplace pas le protocole SACK lui-même.

En savoir plus sur RACK

Si vous souhaitez en savoir plus, voici des sources auxquelles nous faisons confiance.

Termes associés

Si vous vous intéressez à RACK, voici quelques liens qui pourraient vous intéresser.