La fiabilité du protocole de contrôle de transmission (TCP) repose sur des mécanismes de détection de perte capables de dissocier un réordonnancement temporaire de paquets d'une véritable perte au niveau des routeurs intermédiaires. L'algorithme fondamental de retransmission rapide Fast Retransmit (RFC 5681) repose sur l'hypothèse qu'un pipeline réseau achemine un flot de données continu suffisant pour susciter un flux régulier d'accusés de réception (ACK) de la part du récepteur.

Lors de transferts de fichiers volumineux comportant des dizaines de segments en transit, Fast Retransmit opère avec une remarquable efficacité : la réception de trois ACK dupliqués consécutifs signale une perte isolée et déclenche immédiatement la réémission du segment manquant sans suspendre le flux global. Cependant, ce paradigme historique montre ses limites face aux modèles de trafic interactif contemporains, caractérisés par des flux légers (thin streams), de brèves salves de données ou des fenêtres de congestion réduites.

Lorsqu'une session TCP ne compte pas plus de trois paquets en transit simultané, les accusés de réception dupliqués ne peuvent physiquement atteindre le seuil réglementaire de trois. La communication s'interrompt alors jusqu'à l'expiration du temporisateur de retransmission (Retransmission Timeout, RTO), imposant une pénalité de latence allant de deux cents millisecondes à une seconde entière.

L'IETF a formalisé la spécification RFC 5827, Early Retransmit pour TCP et SCTP, afin d'éliminer ce goulet d'étranglement temporel. En adaptant dynamiquement le seuil d'ACK dupliqués lorsque le volume de données en vol est faible, Early Retransmit permet une reprise instantanée sur les liaisons VPN et proxys chiffrés exigeant une réactivité constante.

[Fast Retransmit standard : Exige au moins 4 paquets en transit]
Émetteur ──[P1]──[P2]──[P3]──[P4]──> Récepteur (P1 est perdu en chemin)
Émetteur <──[Ack 1]──[DupAck 1]──[DupAck 2]──[DupAck 3]── (3 DupACK déclenchent la réémission)

[Blocage en petite fenêtre sans RFC 5827 : Seulement 2 paquets en vol]
Émetteur ──[P1]──[P2]──────────────> Récepteur (P1 est perdu en chemin)
Émetteur <──[Ack 1]──[DupAck 1]──── (Seulement 1 DupACK reçu ! Fast Retransmit bloqué)
         └─── GEL DU CANAL ─────────> [Attente passive du temporisateur RTO de 200 à 1000 ms !]

[RFC 5827 Early Retransmit : Abaissement dynamique du seuil]
Émetteur ──[P1]──[P2]──────────────> Récepteur (P1 est perdu en chemin)
Émetteur <──[Ack 1]──[DupAck 1]──── (FlightSize < 4*SMSS -> Seuil abaissé intelligemment à 1)
Émetteur ──[Réémission de P1]──────> (Récupération immédiate ! Zéro latence parasite RTO)

Le dilemme de la fenêtre réduite : l'échec de Fast Retransmit en flux interactif

L'algorithme de retransmission rapide a été conçu en considérant que le désordre des paquets sur Internet est généralement transitoire et n'excède que très rarement un écart de trois positions. Exiger trois ACK dupliqués évite à l'émetteur de réexpédier à tort un paquet qui n'aurait subi qu'un léger retard induit par un routage à chemins multiples ou une parallélisation matérielle.

Si cette approche protège le débit lors de flux massifs, elle engendre une faille structurelle pour les flux applicatifs interactifs.

Pourquoi le protocole standard TCP Fast Retransmit requiert trois ACK dupliqués

D'après les règles de régulation de congestion de la RFC 5681, le récepteur génère sans délai un ACK dupliqué dès qu'il reçoit un segment dont le numéro de séquence est supérieur à celui attendu. Ce message d'accusé confirme le numéro de séquence contigu le plus élevé validé jusqu'alors.

Pour que l'émetteur puisse collecter trois ACK dupliqués, au moins trois segments de données postérieurs doivent parvenir au récepteur après le segment égaré :

$$\text{Paquets minimaux en transit} = 1\ (\text{Segment perdu}) + 3\ (\text{Segments suivants}) = 4\ \text{Segments}$$

Si la fenêtre de congestion ($\text{CWND}$) ou le total des octets non acquittés en transit ($\text{FlightSize}$) est inférieur à $4 \times \text{SMSS}$ (Sender Maximum Segment Size), il est mathématiquement impossible de réunir trois ACK dupliqués. Le récepteur émet un ou deux duplicatas puis cesse toute émission en l'absence de nouveaux paquets entrants.

La pénalité de latence du délai de retransmission RTO sur le trafic sporadique

Lorsque les ACK dupliqués sont insuffisants, la pile TCP classique bascule dans une attente passive. La transmission est suspendue pendant que le noyau attend l'expiration du temporisateur $RTO$, déterminé selon la formule de la RFC 6298 :

$$RTO = \text{SRTT} + \max(G, 4 \times \text{RTTVAR})$$

En production, la valeur plancher du paramètre $RTO$ est généralement fixée à $200\text{ ms}$ sous Linux et peut grimper jusqu'à $1000\text{ ms}$ sur d'autres systèmes.

Pour les communications interactives en temps réel — saisie au clavier via SSH, appels d'API RPC, signalisation WebRTC, résolutions DNS chiffrées ou flux multijoueurs — une interruption de $200\text{ ms}$ à $1000\text{ ms}$ dégrade nettement l'expérience d'utilisation. L'utilisateur constate un gel passager, suivi d'irrégularités de latence et de variations de gigue à l'intérieur du tunnel chiffré.

Architecture et principes protocolaires de la norme RFC 5827 Early Retransmit

La spécification RFC 5827 résout cette faiblesse structurelle en permettant à l'émetteur d'abaisser dynamiquement son seuil d'activation lorsqu'il constate que le volume de données en transit ne permettra pas d'obtenir trois ACK dupliqués.

Adaptation dynamique du seuil selon le volume de données en transit

Lorsqu'un acquittement arrive, l'émetteur évalue la quantité de données demeurant en cours d'acheminement. Si ce volume se situe sous le seuil critique, le mécanisme Early Retransmit recalcule la condition de déclenchement :

  1. Évaluation du transit : Si $\text{FlightSize} < 4 \times \text{SMSS}$, l'émetteur sait que trois ACK dupliqués ne pourront être générés.
  2. Ajustement dynamique : Le seuil de déclenchement requis ($ER\text{_threshold}$) est ajusté au nombre maximal de duplicatas que les paquets restants peuvent provoquer : $$ER\text{_threshold} = \left\lfloor \frac{\text{FlightSize} - 1}{\text{SMSS}} \right\rfloor$$
    • Pour $\text{FlightSize} = 3 \times \text{SMSS}$, le seuil $ER\text{_threshold} = 2$.
    • Pour $\text{FlightSize} = 2 \times \text{SMSS}$, le seuil $ER\text{_threshold} = 1$.
  3. Absence de nouvelles données en attente : Early Retransmit ne s'active que si la mémoire tampon du socket ne contient aucune nouvelle donnée prête à l'envoi. Si l'application dispose de nouvelles données, l'émetteur privilégie l'envoi de nouveaux segments selon le mécanisme Limited Transmit (RFC 3042) pour tenter une récupération classique.

Comparaison des approches Early Retransmit par segment et par octet

La RFC 5827 formalise deux variantes techniques :

  • Early Retransmit par segment : Conçu pour les sessions TCP n'ayant pas activé les acquittements sélectifs (SACK). L'émetteur décompte le nombre brut de segments en vol et déclenche la retransmission dès que les ACK dupliqués correspondent à ce nombre.
  • Early Retransmit par octet : Optimisé pour les piles réseau modernes avec option SACK activée (RFC 2018). L'émetteur vérifie précisément les plages d'octets décrites dans les blocs SACK. Lorsque ces blocs confirment que la totalité des octets suivant l'intervalle manquant est bien parvenue à destination, l'émetteur réémet le segment sans ambiguïté.

Les noyaux Linux modernes s'appuient sur la variante par octet, la négociation SACK étant conclue sur l'immense majorité des flux réseau.

Interaction avec SACK et protection contre les retransmissions superflues

L'abaissement du seuil de déclenchement soulève le risque d'interpréter un simple réordonnancement de paquets comme une perte définitive. Si un paquet est retardé de quelques millisecondes par des files d'attente parallèles de routeurs, réémettre dès le premier ACK dupliqué consommerait inutilement de la bande passante.

La RFC 5827 intègre des garde-fous rigoureux pour éviter ce gaspillage de ressources réseau.

Exploitation des accusés de réception sélectifs pour localiser les pertes

Lorsque l'option SACK est active, le destinataire transmet les étendues exactes des données reçues hors séquence. Prenons l'exemple d'un envoi de trois segments :

L'émetteur transmet : Seq 1000-2000, Seq 2000-3000, Seq 3000-4000
Le segment 1000-2000 est égaré.
Le récepteur reçoit 2000-3000 -> Réponse : Ack 1000, SACK [2000-3000]
Le récepteur reçoit 3000-4000 -> Réponse : Ack 1000, SACK [2000-4000]

Dès le second ACK dupliqué, l'émetteur constate grâce aux blocs SACK que 2000 octets situés au-delà du trou ont été délivrés. Étant donné que le volume total en transit n'était que de 3000 octets, il est certain qu'aucun autre paquet ne subsiste sur le réseau. Attendre un troisième ACK dupliqué n'apporterait aucune information : Early Retransmit réémet immédiatement le segment manquant.

Modération du désordre des paquets grâce au temporisateur de délai

Afin d'éviter toute réaction prématurée sur les liaisons sujettes à des micro-réordonnancements, les implémentations modernes arment une courte temporisation avant d'exécuter Early Retransmit.

Lorsque le seuil réduit est atteint, le noyau temporise brièvement selon une fraction du temps de propagation aller-retour lissé :

$$\text{ER_Delay} = \frac{\text{SRTT}}{4}$$

Si le paquet en retard parvient au destinataire et que l'ACK comblant la brèche revient avant l'échéance de $\text{ER_Delay}$, la réémission est annulée. Si le compte à rebours expire, la perte est confirmée et le paquet est réémis sur-le-champ. Ce procédé hybride élimine les retards RTO tout en conservant une bonne tolérance au désordre de routage.

Dynamique de latence et de débit à travers les tunnels réseau chiffrés

L'encapsulation du trafic dans des tunnels sécurisés — tels que WireGuard, IPsec ESP ou OpenVPN — modifie la dynamique de transport. L'ajout des en-têtes IP, UDP et ESP ampute la taille utile maximale de segment (MSS) et augmente le risque de fragmentation.

Élimination des pics de latence RTO sur les liaisons encapsulées en VPN

Sur les réseaux cellulaires, lors des transitions Wi-Fi ou sur les liaisons intercontinentales, les pertes de paquets surviennent par intermittence sous forme de brèves salves causées par des interférences ou la saturation momentanée des relais.

Contexte d'évaluation TCP conventionnel (Sans ER) RFC 5827 Early Retransmit Gain mesuré
Perte avec FlightSize = 2 Gel de 200 ms à 1000 ms (RTO) Récupération en 1 RTT (~35 ms) Réduction de 82 % à 96 % du délai
Perte avec FlightSize = 3 Gel de 200 ms à 1000 ms (RTO) Récupération en 1 RTT (~35 ms) Réduction de 82 % à 96 % du délai
Session interactive SSH Décalage marqué de saisie Frappe fluide sans blocage Préservation de la réactivité
Requête DNS via HTTPS Attente d'échéance et nouvel essai Correction locale au niveau TCP Résolution fluide et continue
Comportement de CWND Chute brutale à 1 SMSS (Slow Start) Réduction maîtrisée de moitié Restauration rapide du débit

Lorsqu'un flux TCP ordinaire subit une perte en petite fenêtre sur un tunnel chiffré, l'utilisateur ressent un net ralentissement. Le déclenchement du RTO ramène la fenêtre de congestion à un seul segment ($\text{CWND} = 1$), forçant la connexion à réapprendre le débit par un démarrage lent (Slow Start).

La norme RFC 5827 permet de rester en phase de reprise rapide (Fast Recovery), divisant la fenêtre par deux au lieu de la réinitialiser.

Architecture du noyau : optimisation de la pile de transport avec RiceGuard

Les solutions VPN grand public considèrent souvent la pile TCP du système comme une boîte noire immuable, laissant les flux encapsulés soumis aux réglages par défaut du noyau, généralement configurés pour les réseaux filaires de centres de données.

L'infrastructure VPNRice intègre le moteur de performance RiceGuard, chargé d'affiner les paramètres de transport sur les passerelles d'extrémité et les terminaux clients :

[Flux applicatif interactif]
   (SSH / HTTPS / API / Jeux en réseau)
                 │
                 ▼  (Salves sporadiques à petite fenêtre)
[Couche d'optimisation TCP RiceGuard]
   ├── Early Retransmit par octet selon RFC 5827
   ├── Harmonisation des envois SACK et repérage DSACK
   ├── Temporisateur dynamique ER Delay (SRTT/4 anti-désordre)
   └── Synchronisation de pacing sous BBRv3 et CUBIC
                 │
                 ▼  (Suppression des paliers d'attente RTO)
[Tunnel de transport chiffré]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)
  1. Application du standard RFC 5827 : Les passerelles RiceGuard activent Early Retransmit par octet avec temporisation adaptative, prévenant les latences de 200 ms provoquées par l'échéance du RTO.
  2. Harmonisation des accusés sélectifs : RiceGuard valide la conformité SACK (RFC 2018) et Duplicate SACK (RFC 2883) sur l'enveloppe chiffrée et la charge utile, aidant le noyau à faire le tri entre paquets égarés et réceptions multiples.
  3. Régulation de cadence et gestion des files : En associant Early Retransmit à une gestion active des files d'attente (FQ/CoDel), RiceGuard limite l'accumulation de paquets au niveau des relais radio, atténuant les pertes lors des basculements de bornes.

Audit et vérification diagnostique : contrôle d'Early Retransmit via socket

Les administrateurs système et ingénieurs réseau peuvent vérifier l'état d'activation de la RFC 5827 sur leurs serveurs Linux via les commandes du noyau.

Vérification du paramètre sysctl dédié à Early Retransmit :

# Consulter la configuration TCP Early Retransmit en cours
sysctl net.ipv4.tcp_early_retrans

# Valeurs possibles :
# 0 : Désactivé
# 1 : Early Retransmit par segment
# 2 : Early Retransmit par octet
# 3 : Mode par octet avec temporisateur de délai (Recommandé sous Linux)

Pour activer le mode par octet avec temporisateur adaptatif, exécutez la commande suivante :

# Activer la RFC 5827 avec temporisateur contre le réordonnancement
sudo sysctl -w net.ipv4.tcp_early_retrans=3

Pour analyser les connexions actives et vérifier le recours effectif à la retransmission anticipée, interrogez les métriques de sockets avec ss :

# Consulter les paramètres internes TCP et les statistiques de retransmission
ss -ti dst 198.51.100.1

Examinez les champs early_retrans et le ratio retrans. Une hausse du compteur early_retrans conjuguée à un nombre quasi nul d'expirations RTO atteste que la pile réseau compense proactivement les pertes sans dégrader la réactivité des services interactifs.

Télécharger VPNRice.