TCP Window Scale RFC 7323 : saturation du BDP, PAWS et débit VPN

Lorsque le protocole de contrôle de transmission (TCP) a été standardisé dans la RFC 793 en septembre 1981, les liaisons du réseau ARPANET fonctionnaient sur des lignes en cuivre à 56 kbit/s et les délais d'aller-retour se mesuraient en dizaines de millisecondes. À cette époque, attribuer un entier de 16 bits au champ de fenêtre de réception TCP (rcv_wnd) paraissait très confortable. Ce champ limitait la quantité maximale de données en vol non acquittées à $2^{16} - 1 = 65 535$ octets (64 Ko).

Plusieurs décennies après, la réalité physique du transit mondial a radicalement changé. Les cœurs de réseaux d'entreprise, les liaisons fibre optique multi-gigabits et les réseaux superposés VPN chiffrés parcourent des distances intercontinentales avec des temps d'aller-retour (RTT) dépassant fréquemment 100 millisecondes. Dans ce contexte, la limite rigide des 64 Ko se transforme en un goulot d'étranglement artificiel qui bride le débit réel à une fraction minime de la bande passante physique.

La RFC 7323 (qui a rendu obsolète la RFC 1323) standardise l'option TCP Window Scale associée au mécanisme PAWS (Protection Against Wrapped Sequence Numbers). En étendant la fenêtre de réception effective jusqu'à 1 gigaoctet et en exploitant des horodatages à la microseconde, la RFC 7323 permet aux tunnels réseau et aux infrastructures VPN réparties d'atteindre le débit maximal de leurs liaisons.

Le plafond des 64 Ko : mécanique de fenêtre TCP classique et crise du LFN

Dans le protocole TCP classique, le contrôle de flux repose sur une fenêtre glissante. Le récepteur informe en continu l'émetteur de l'espace mémoire disponible pour accueillir de nouveaux paquets via le champ Window de 16 bits du segment :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Port Source         |       Port Destination        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Numéro de Séquence                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Numéro d'Acquittement                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Décal.|           |U|A|P|R|S|F|                               |
|Données|  Réservé  |R|C|S|S|Y|I|     Fenêtre de Réception      |
|       |           |G|K|H|T|N|N|           (16 Bits)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ce champ étant strictement limité à 16 bits, l'émetteur ne peut envoyer que 65 535 octets au maximum avant de devoir marquer un temps d'arrêt pour attendre un acquittement (ACK).

Sur les réseaux à haut débit et forte latence — qualifiés de Long Fat Networks (LFN) dans la RFC 7323 — le temps nécessaire au trajet aller-retour bride sévèrement les performances. Si une ligne présente un RTT de 100 millisecondes, l'émetteur passe 100 ms à attendre l'ACK de chaque bloc de 64 Ko. Le débit maximal théorique s'effondre à :

$$\text{Débit}_{\max} = \frac{\text{Taille de Fenêtre}}{\text{RTT}} = \frac{65 535 \text{ octets}}{0,100 \text{ s}} \approx 5,24 \text{ Mbit/s}$$

Même sur une liaison optique dédiée de 10 Gbit/s, une session TCP sans mise à l'échelle ne dépassera jamais 5,24 Mbit/s sur un trajet de 100 ms. Plus de 99,9 % de la capacité physique reste inexploitée.

Produit bande passante-délai (BDP) : la physique des données en transit

Pour exploiter la pleine capacité d'une liaison, l'émetteur doit injecter en permanence un volume de paquets non acquittés suffisant pour remplir tout le canal physique entre les deux extrémités. Ce volume correspond au produit bande passante-délai (Bandwidth-Delay Product, BDP) :

$$\text{BDP} = \text{Capacité (bits/seconde)} \times \text{Temps d'aller-retour RTT (secondes)}$$

Examinons trois scénarios d'infrastructures courantes :

Dès que le BDP dépasse 65 535 octets, le protocole TCP historique ne peut plus saturer la liaison. Sans échelle de fenêtre, une autoroute informatique à plusieurs voies se retrouve exploitée comme une voie unique bloquée par un seul véhicule lent.

+-----------------------------------------------------------------------------+
|               MODÈLE DE SATURATION DU CANAL PAR LE BDP                      |
+-----------------------------------------------------------------------------+
Émetteur ======[ Paquets en transit (Doit égaler la valeur BDP) ]=====> Récepteur
         <=====[ Flux continu d'acquittements ACK de retour ]==========

Architecture de TCP Window Scale : mécanismes du protocole RFC 7323

La RFC 7323 surmonte la contrainte des 16 bits sans altérer la structure du paquet de base de 20 octets grâce à l'utilisation des options TCP (TCP Options).

Négociation lors du handshake à trois voies et encodage Shift Count

L'option TCP Window Scale est transmise exclusivement dans les segments dont le drapeau SYN est activé, lors de l'établissement initial de la connexion :

+----------------------------------------------------+
|  Kind = 3 (1 Octet)  | Longueur Length = 3 (1 Octet|
+----------------------------------------------------+
|  Facteur de décalage Shift Count : S (Plage : 0-14)|
+----------------------------------------------------+

Le champ Shift Count $S$ de 1 octet spécifie un facteur de décalage binaire. Pour tous les paquets non-SYN ultérieurs, la taille réelle de la fenêtre de réception s'obtient en décalant vers la gauche la valeur du champ d'en-tête de $S$ bits :

$$\text{Fenêtre Effective} = \text{Valeur de l'En-tête} \times 2^S$$

Puisque la norme plafonne le décalage à $S = 14$, la fenêtre initiale de 16 bits s'étend vers un équivalent de 30 bits :

$$\text{Fenêtre}_{\max} = 65 535 \times 2^{14} = 1 073 725 440 \text{ octets } (\approx 1,07 \text{ Go})$$

Une capacité d'un gigaoctet permet de saturer sans difficulté des liaisons à 100 Gbit/s à l'échelle planétaire.

Mise à l'échelle asymétrique et risques d'altération par les boîtiers intermédiaires

La négociation de l'option est bidirectionnelle et asymétrique. L'hôte A peut proposer un décalage $S = 7$ selon sa mémoire, tandis que l'hôte B propose $S = 9$. Chaque extrémité gère un coefficient distinct pour ses réceptions.

Cependant, si un pare-feu obsolète ou un équipement NAT supprime l'option Window Scale lors du passage du paquet SYN, la session retombe en mode 16 bits restreint. Pire encore, si un boîtier intermédiaire réécrit le champ de fenêtre sans tenir compte du décalage convenu, la connexion subit un étranglement sévère ou des réinitialisations inopinées.

Protection contre le chevauchement des numéros de séquence (PAWS) et RTTM

Porter la fenêtre au-delà de 64 Ko expose le protocole à un risque d'épuisement rapide des numéros de séquence.

Les numéros de séquence TCP sont codés sur 32 bits, offrant un espace total de $2^{32} = 4 294 967 296$ octets (~4,29 Go). À très haute vitesse, ce cycle de numérotation se renouvelle en quelques secondes :

• À 1 Gbit/s : L'espace est parcouru en 34,3 secondes.
• À 10 Gbit/s : Le rebouclage s'effectue en 3,4 secondes.
• À 40 Gbit/s : Le cycle complet ne dure que 0,86 seconde.

Selon les règles TCP standards, un ancien paquet retardé dans les files d'attente d'Internet pourrait arriver pendant le cycle suivant avec un numéro de séquence valide, altérant silencieusement les données sans que l'application ne s'en aperçoive.

Ancien paquet retardé (Séquence : 10 000) -----------------\
                                                          \
Flux actuel (Séquence rebouclée : 10 000) ===> Tampon ---> [ CORRUPTION DE DONNÉES ! ]

Mécanismes de l'option d'horodatage et cycle de rebouclage à haut débit

La RFC 7323 écarte ce risque grâce à l'algorithme PAWS (Protection Against Wrapped Sequence Numbers), appuyé sur l'option d'horodatage TCP (Kind=8, Length=10) :

+----------------------------------------------------+
|  Kind = 8 (1 Octet)  | Longueur = 10 (1 Octet)     |
+----------------------------------------------------+
|  Valeur d'horodatage : TSval (4 Octets)            |
+----------------------------------------------------+
|  Écho d'horodatage : TSecr (4 Octets)              |
+----------------------------------------------------+

L'algorithme PAWS traite le champ TSval de 32 bits comme un compteur temporel strictement croissant. Lorsqu'un paquet arrive, le récepteur vérifie que son horodatage est supérieur ou égal au dernier horodatage valide enregistré :

$$\text{TSval} \ge \text{TS.Recent}$$

Si un paquet fantôme issu d'un cycle antérieur surgit, son horodatage périmé le trahit aussitôt. Le récepteur l'écarte silencieusement, protégeant l'intégrité du transfert. En parallèle, la fonction RTTM fournit des mesures précises du RTT pour adapter les algorithmes de congestion.

Ajustement automatique des tampons de sockets du noyau Linux et mémoire

L'activation de la RFC 7323 demeure sans effet si le système d'exploitation bride la mémoire de ses sockets sous le niveau du BDP calculé. Le noyau Linux moderne intègre un mécanisme d'auto-ajustement dynamique (autotuning) qui dimensionne les tampons selon les besoins jusqu'aux plafonds fixés par l'administrateur.

Configuration des paramètres tcp_rmem, tcp_wmem et limites SO_RCVBUF

La pile réseau de Linux gère les tampons de réception et d'émission via des tableaux à trois valeurs [minimum, défaut, maximum] :

# Vérifier les paramètres TCP en vigueur
sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Sur les serveurs disposant d'accès à très haut débit, relevez ces plafonds :

# Activer les extensions RFC 7323
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_timestamps=1

# Configurer les tampons de sockets jusqu'à 64 Mo
sysctl -w net.ipv4.tcp_rmem="4096 131072 67108864"
sysctl -w net.ipv4.tcp_wmem="4096 65536 67108864"

# Ajuster les plafonds mémoire globaux
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864

Il est recommandé d'éviter de figer manuellement la taille des tampons avec setsockopt(..., SO_RCVBUF, ...), car cette pratique désactive l'auto-ajustement du noyau et bride la connexion à une taille rigide.

Encapsulation dans les tunnels VPN et collisions de fenêtres TCP

Lorsqu'une application achemine des flux TCP à travers un tunnel VPN chiffré (comme WireGuard ou IPsec), l'encapsulation engendre plusieurs contraintes :

1. Surcoût des en-têtes d'encapsulation : L'ajout des en-têtes IP et UDP externes ainsi que des balises d'authentification réduit le MTU effectif (par exemple de 1500 à 1420 octets). Sans ajustement adapté du MSS, les segments TCP subissent une fragmentation qui détruit l'efficacité de la fenêtre.
2. Bufferbloat et gigue de latence : Si les passerelles VPN accumulent les paquets dans des files d'attente trop profondes, le RTT subit des hausses brutales. TCP interprète cette instabilité comme une congestion et réduit sa fenêtre (cwnd).
3. Phénomène de blocage TCP-dans-TCP : Transporter du trafic TCP dans un tunnel lui-même basé sur TCP provoque des retransmissions en cascade en cas de perte, entraînant l'effondrement du débit.

Les architectures modernes privilégient une encapsulation sur UDP couplée à un dimensionnement des tampons aligné sur le BDP réel.

Mesures de performance : débit sur les liaisons transocéaniques à fort RTT

L'avantage opérationnel apporté par la RFC 7323 ressort clairement lors des tests de débit :

Sans la RFC 7323, souscrire à des liaisons internationales multi-gigabits n'apporte que peu d'avantages pour les flux TCP uniques.

Comment RiceGuard optimise les tampons de sockets et la mise à l'échelle à débit de ligne

Le réseau Anycast de VPNRice s'étend sur plus de 40 points de présence dans le monde. Les utilisateurs peuvent à tout moment auditer leur routage et leur latence via l'outil de détection d'adresse IP VPNRice.

Pour assurer un débit optimal sur de grandes distances lors de l'accès à des ressources distantes, le protocole RiceGuard intègre des optimisations avancées :

1. Tampons circulaires zéro-copie : RiceGuard met en œuvre des structures de mémoire en espace utilisateur capables de gérer des enveloppes BDP de plusieurs mégaoctets sans solliciter inutilement le noyau.
2. Fixation dynamique du MSS : Chaque passerelle Anycast intercepte les paquets TCP SYN internes et ajuste automatiquement le MSS au MTU effectif du tunnel pour bannir toute fragmentation.
3. Protection des en-têtes d'options : RiceGuard normalise les options TCP sur ses routes de transit, évitant que des équipements intermédiaires défectueux ne suppriment Window Scale ou Timestamps.
4. Synergie avec l'infrastructure Anycast : La combinaison de tampons optimisés avec le routage multi-chemins BGP ADD-PATH et la détection rapide BFD garantit un flux stable sans gigue excessive.

Les applications clientes sont disponibles pour toutes les plateformes sur la page de téléchargement VPNRice, garantissant un transport fluide et sécurisé.

+-----------------------------------------------------------------------------+
|             ARCHITECTURE DE TRANSPORT HAUT DÉBIT RICEGUARD                  |
+-----------------------------------------------------------------------------+
[ Équipement Client ]
       | (Tampon socket calibré sur le BDP)
       v
[ Tunnel RiceGuard (Encapsulation WireGuard UDP) ]
       |
       +---> TCP Interne : Échelle de fenêtre RFC 7323 (Facteur S=7)
       +---> TCP Interne : Protection PAWS active (Horodatages)
       +---> Passerelle : Fixation dynamique du MSS (Zéro fragmentation)
       v
[ Serveur d'Entreprise / Cloud Distant ] (Saturation intégrale du BDP)

Associée à une gestion rigoureuse des flux—notamment la régulation des sockets TCP TIME-WAIT—cette architecture maintient des transferts stables sur Internet.

Liste de contrôle pour l'optimisation de TCP et des tunnels VPN en production

Pour tirer le meilleur parti des liaisons à forte latence, suivez ces recommandations de contrôle :

• Vérifier l'activation du Window Scaling : Contrôlez sysctl net.ipv4.tcp_window_scaling pour vous assurer que la valeur affichée est 1.
• Activer les horodatages TCP : Vérifiez que net.ipv4.tcp_timestamps est réglé sur 1 pour maintenir la protection PAWS.
• Calculer le BDP de la liaison : Multipliez la bande passante cible par le RTT pour déterminer le volume minimal en octets.
• Adapter les plafonds de tampons : Réglez les valeurs maximales de net.ipv4.tcp_rmem et net.ipv4.tcp_wmem au-delà du BDP calculé.
• Inspecter les paquets avec tcpdump : Vérifiez lors du handshake que l'option Window Scale est bien présente sur les paquets SYN et SYN-ACK.
• Mettre en place la fixation du MSS : Ajoutez sur les concentrateurs VPN une règle de pare-feu ajustant le MSS à la taille du PMTU.
• Surveiller le taux de retransmission : Analysez les retransmissions pour distinguer une réelle congestion physique d'un manque de mémoire de socket.