La taxe TCP-sur-TCP : une autopsie architecturale

Votre tunnel n’est pas lent à cause de votre ISP ; il l’est parce que vos paquets sont bloqués dans une boucle de “double-retransmission”. Pour un ingénieur systèmes, la fibre à haute vitesse ressemble à une connexion dial-up dès que vous encapsulez un flux TCP dans un autre flux TCP. Ce phénomène, connu dans le monde du réseautage sous le nom de Taxe TCP-sur-TCP (ou plus dramatiquement, le Meltdown TCP), est un antipattern architectural classique.

Dans cette autopsie, nous disséquerons les raisons mathématiques et algorithmiques pour lesquelles les tunnels SSH, OpenVPN-TCP, et autres architectures TCP imbriquées échouent même avec peu de perte de paquets, et pourquoi des alternatives modernes comme WireGuard et QUIC sont les seules solutions pour des tunnels “lents”.

1. L’anatomie de l’encapsulation

Pour comprendre la taxe, il faut d’abord regarder la pile. Lorsqu’on lance un tunnel SSH ou un VPN basé sur TCP, on ne fait pas qu’envoyer des données ; on encapsule tout un État TCP Interne dans un État TCP Externe.

Dans une connexion standard sans tunnel, TCP gère le contrôle de flux et la fiabilité directement sur la couche IP (qui est “best-effort” et peu fiable). Mais, dans un tunnel :

Le TCP Interne (votre application) pense qu’il parle à un hôte distant. Il gère les numéros de séquence, ACK, et une fenêtre de congestion (cwnd).
Le TCP Externe (le tunnel) voit les paquets internes comme une charge utile brute. Il ajoute ses propres numéros de séquence, ACK, et son propre cwnd.

Sur un réseau parfait, cela fonctionne. Mais Internet n’est jamais parfait.

2. L’autopsie mathématique : pourquoi 1% de perte ressemble à 90%

Le cœur de la “Taxe” est la réaction des deux couches face à la perte de paquets. Dans une seule couche TCP, le débit est approximativement gouverné par l’Équation de Mathis :

Débit ≤ MSS / (RTT × √p)

Où : - MSS : Taille maximale du segment - RTT : Temps de round-trip - p : Probabilité de perte de paquet

Lorsque vous imbriquez TCP, la probabilité de perte p ne réduit pas simplement le débit de façon linéaire ; elle déclenche un conflit de synchronisation entre deux timers indépendants.

La boucle de double-retransmission

Imaginez qu’un seul paquet est perdu sur le câble physique :

Réponse du TCP Externe : le tunnel détecte le paquet manquant et arrête tout pour le retransmettre. Le cwnd du tunnel est réduit de moitié.
Perspective du TCP Interne : pendant que le tunnel retransmet, le paquet de l’application interne est “bloqué” dans le buffer du tunnel. Le TCP interne voit une augmentation massive du RTT.
Le Meltdown : si le temps que met le TCP Externe pour retransmettre avec succès dépasse le Retransmission Timeout (RTO) du TCP interne, ce dernier décide aussi que le paquet est perdu. Il déclenche sa propre retransmission.

Maintenant, vous avez deux couches envoyant la même donnée. Le tunnel est déjà congestionné, et l’application double la charge. Cela crée une boucle de rétroaction où les buffers se remplissent de retransmissions redondantes, poussant le RTT effectif dans les secondes.

Selon des recherches récentes, les boucles de contrôle dans les TCP internes et externes interfèrent de manière destructive, car le TCP externe masque la santé de la connexion au TCP interne. Cette interférence transforme une perte mineure en dégradation catastrophique des performances.

3. Le blocage Head-of-Line (HoL) : la prison séquentielle

TCP est un protocole fiable de flux de bytes. Il garantit que l’application reçoit les données dans l’ordre exact où elles ont été envoyées. C’est sa plus grande force, mais dans un tunnel, c’est aussi sa faille fatale.

La file d’attente séquentielle

Si le paquet #1 est perdu mais que les paquets #2, #3, et #4 arrivent en toute sécurité, la pile TCP ne peut pas remettre les paquets #2–4 à l’application. Ils doivent attendre que le paquet #1 soit retransmis et arrive.

Dans un tunnel SSH, cet effet est global. Si vous multiplexez plusieurs flux (par exemple, une connexion à une base de données et une requête web) via un seul tunnel SSH, un seul paquet perdu dans le flux de la base de données bloquera la requête web, même si les paquets web sont arrivés parfaitement.

La mathématique de l’attente

La probabilité qu’un paquet soit retardé par le blocage HoL dans un flux avec n paquets en attente et un taux de perte p est approximativement 1 - (1-p)^n. À mesure que n (la taille de la fenêtre) augmente pour remplir un tuyau à haute bande passante, la probabilité d’un blocage approche 100%, même avec p < 0.1%.

Ce problème devient encore plus critique dans les environnements modernes à haute bande passante où les tailles de fenêtres doivent être grandes pour remplir le produit bande-passante/délai.

4. Impact réel : études de cas et benchmarks récents

WireGuard vs VPNs traditionnels

Des études récentes apportent des preuves concrètes du tax TCP-sur-TCP. En environnement VMware, WireGuard a démontré un débit TCP supérieur à 210,64 Mbps contre 110,34 Mbps pour OpenVPN, avec une perte de paquets significativement plus faible (12,35% contre 47,01%).

Les tests sur le terrain ont montré des résultats encore plus spectaculaires. En conditions de benchmark pratiques, WireGuard était en moyenne 3,3 fois plus rapide qu’OpenVPN, illustrant le coût réel de l’architecture TCP-sur-TCP.

Performance à grande échelle

Les solutions VPN modernes ont énormément évolué. Sur des réseaux gigabit, Netmaker a atteint des débits constants moyens de 7,88 Gbits/sec, presque identiques à WireGuard en noyau à 7,89 Gbits/sec. Cette performance quasi-native n’est possible qu’en évitant le tax TCP-sur-TCP.

L’écart de performance s’accentue dans des conditions réseau difficiles. WireGuard atteint ses performances grâce à plusieurs facteurs clés : un design léger d’environ 4 000 lignes de code contre des dizaines de milliers pour OpenVPN, un chiffrement moderne ChaCha20-Poly1305 qui fonctionne efficacement sur tous les processeurs, et une intégration kernel qui traite les paquets sans coûteux changements de contexte.

Résultats en déploiement réel

Le matériel grand public montre des performances impressionnantes avec WireGuard. Des benchmarks récents sur des routeurs modernes montrent que WireGuard peut atteindre presque la pleine capacité du lien sur des connexions fibre gigabit symétriques, avec des performances autour de 1 080 Mbps même sur du matériel de gamme moyenne.

5. Le “Meltdown” et le conflit de contrôle de congestion

Les algorithmes TCP comme CUBIC ou NewReno sont conçus pour sonder la bande passante jusqu’à ce qu’ils détectent une baisse. Lorsqu’ils sont imbriqués, ils entrent en conflit pour la même ressource :

Le TCP Externe tente de remplir le tuyau.
Le TCP Interne tente aussi de remplir le tuyau.
Lorsqu’une baisse survient, les deux reculent.

Parce que le TCP Externe tamponne les ACK du TCP interne, l’estimation du RTT du TCP interne devient “bruyante”. Il ne peut pas calculer précisément le produit bande-passante/délai (BDP).

Ce “Compression d’ACK” empêche la connexion interne d’atteindre un état stable à haute vitesse. Ce design peut échouer lorsque l’on empile des connexions TCP, et ce type de ralentissement réseau est connu sous le nom de meltdown TCP, qui se produit lorsqu’une connexion externe plus lente cause une accumulation de retransmissions dans la couche supérieure.

6. Le “tueur silencieux” MTU/MSS

Même si votre perte de paquets est nulle, vous payez peut-être une “taxe de fragmentation”.

Une trame Ethernet standard fait 1500 octets. SSH et VPN ajoutent des en-têtes (chiffrement, encapsulation). Si le paquet résultant fait 1520 octets, il doit être fragmenté en deux paquets.

Fragmentation : - Double le nombre de paquets - Double la surcharge d’interruption sur le CPU - Si une seule fragment est perdue, tout le paquet original est rejeté

Pour un tunnel SSH, il faut “limiter” la taille MSS (Maximum Segment Size) pour que les segments TCP internes soient suffisamment petits pour tenir dans la charge utile du tunnel sans fragmentation.

Exemple : Clamp MSS avec IPTables

# Empêcher la fragmentation en limitant MSS à la MTU du chemin
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

7. La solution moderne : encapsulation basée sur UDP

Le consensus technique est clair : Les tunnels doivent être sans état.

Pourquoi WireGuard gagne

WireGuard utilise UDP. Si un paquet chiffré est perdu, WireGuard ne s’en soucie pas. Il ne retransmet pas. Il n’a pas de fenêtre de congestion. Il délègue simplement la “fiabilité” à l’Inner TCP.

Avantages :

Pas de double-retransmission : seule une couche (l’application) gère la récupération.
Pas de blocage HoL : le paquet #2 peut être déchiffré et livré même si le paquet #1 manque.
Intégration kernel : WireGuard vit dans le kernel Linux (depuis la version 5.6+), évitant le surcoût de changement de contexte que subissent les tunnels SSH en espace utilisateur.

UDP ne retransmet rien par lui-même, donc en UDP, seule la connexion TCP interne retransmet les paquets perdus, évitant ainsi l’empilement et le problème.

Pourquoi QUIC (HTTP/3) est l’avenir

QUIC construit essentiellement un “TCP plus intelligent” sur UDP. Il supporte les flux multiplexés sans blocage HoL. Si un flux dans un tunnel QUIC perd un paquet, les autres flux continuent sans problème.

Avancées de performance de QUIC

Des déploiements réels récents montrent les avantages de QUIC :

Le document original de Google décrivant les mécanismes de base de QUIC rapportait une réduction moyenne de 8% du temps de chargement des résultats de recherche Google sur desktop et 3,6% sur mobile, avec jusqu’à 16% de chargements plus rapides pour le 1% des utilisateurs les plus lents.

Pour la vidéo en streaming, l’impact est encore plus marqué. Lors de l’observation du streaming vidéo YouTube, des chercheurs ont constaté jusqu’à 20% de moins de mise en mémoire tampon.

Les grands CDN ont validé ces bénéfices à grande échelle. Lors d’un événement de streaming sportif européen populaire en Amérique Latine, environ 69% des connexions HTTP/3 atteignaient un débit de 5 Mbps ou plus contre seulement 56% pour HTTP/2.

Vitesse d’établissement des connexions

En utilisant QUIC, HTTP/3 peut établir des connexions jusqu’à 33% plus rapidement qu’HTTP/2 en combinant la poignée de main transport et TLS en une seule étape, réduisant le nombre de round-trips.

Adoption de HTTP/3 en 2024-2025

Le protocole est passé de expérimental à mainstream. D’ici 2024-2025, les principaux navigateurs web — Chrome, Firefox, Safari, Edge — supportent tous HTTP/3 par défaut, avec une croissance annuelle.

Les grandes entreprises internet mènent la charge. Google, Meta, et autres utilisent massivement HTTP/3, ce qui signifie qu’une grande partie du trafic internet actuel utilise déjà HTTP/3.

Performances réelles de HTTP/3

Les benchmarks montrent des améliorations constantes. HTTP/3 est plus rapide que ses prédécesseurs dans tous les cas testés, sa nature multiplexée évitant tout blocage HoL.

Les utilisateurs mobiles bénéficient particulièrement. Un rapport d’Akamai 2025 montre que HTTP/3 réduit la latence de 30% sur les réseaux mobiles, un environnement particulièrement difficile pour TCP traditionnel.

Pourquoi les grandes plateformes investissent dans le déploiement plus coûteux de QUIC/HTTP/3 ? Parce que QUIC et HTTP/3 sont plus coûteux en CPU et mémoire que TCP et HTTP/2, en raison d’un chiffrement plus étendu, mais ces coûts sont compensés par leurs bénéfices.

C’est pourquoi des outils comme cloudflared (Tunnels Cloudflare) ont migré vers QUIC comme transport par défaut.

8. La checklist de l’ingénieur : éviter la taxe

Si votre tunnel semble lent malgré votre fibre, faites cette autopsie architecturale :

1. Cessez d’utiliser des VPN basés sur TCP

Passez à WireGuard ou Tailscale. Si vous devez utiliser OpenVPN, changez le transport de TCP à UDP.

Pourquoi c’est important : Malgré sa réputation de protocole plus fiable, un VPN TCP ne fonctionne de manière fiable que si la ligne est presque parfaite, et même s’il ne se dégrade pas complètement, il y aura des retransmissions en double qui augmentent la latence et diminuent le débit.

2. Auditez vos tunnels SSH

Pour le développement, ssh -L suffit. En production, c’est un goulot d’étranglement. Envisagez socat sur UDP ou un proxy basé sur QUIC.

3. Vérifiez votre MTU

Utilisez cette commande pour trouver la plus grande taille de paquet sans fragmentation :

ping -M do -s 1472 <destination>

Si votre tunnel est actif, ce chiffre sera plus bas (habituellement 1420 ou 1380). Ajustez votre MTU en conséquence.

4. Vérifiez le “Bufferbloat”

Le TCP imbriqué aggrave le bufferbloat. Utilisez fq_codel ou CAKE comme discipline de file d’attente (qdisc) sur l’interface du tunnel pour réduire la latence :

# Appliquer CAKE sur l'interface du tunnel
tc qdisc replace dev wg0 root cake bandwidth 100mbit

5. Envisagez des alternatives modernes

Pour les applications web, privilégiez HTTP/3 quand c’est possible. Pour des tunnels personnalisés, évaluez des solutions basées sur QUIC plutôt que SSH ou OpenVPN-TCP.

9. Comprendre les compromis

Quand TCP-sur-TCP peut encore être utilisé

Malgré tous ses inconvénients, les tunnels TCP-sur-TCP persistent dans certains scénarios :

Traversée de pare-feu : certains réseaux d’entreprise n’autorisent que les connexions TCP sortantes sur le port 443.
Systèmes legacy : l’infrastructure existante ne supporte pas UDP.
Simplicité : les tunnels SSH sont omniprésents et ne nécessitent pas de logiciel supplémentaire.

Cependant, les développements récents ont résolu ces problèmes. La recommandation standard est claire : si votre VPN interne doit être TCP, faites-le passer par un tunnel externe basé sur UDP pour éviter la meltdown.

La réalité des performances

Comprendre dans quelles conditions TCP-sur-TCP échoue est crucial pour la conception des systèmes :

Un tunnel TCP est une technologie qui agrège et transfère des paquets envoyés entre hôtes comme une seule connexion TCP, mais puisque la majorité des applications utilisent TCP, deux contrôles de congestion TCP opèrent simultanément et interfèrent.

Résultat ? Un meltdown TCP, avec une fenêtre de congestion fortement réduite, un timeout de retransmission gonflé, et un buffer d’envoi plein, indiquant que le TCP interne ne peut pas écrire et que les ACK ne sont pas envoyés dans les deux sens.

10. L’avenir : Internet post-TCP

Le passage de TCP à des protocoles basés sur UDP représente une refonte fondamentale du transport internet :

Innovations architecturales de QUIC

QUIC s’intègre étroitement avec le protocole TLS, et avec QUIC, TLS chiffre aussi une grande partie du protocole lui-même, ce qui signifie que les métadonnées comme les numéros de paquet et les signaux de fermeture de connexion, visibles dans TCP, ne le sont plus dans QUIC, accessibles uniquement au client et au serveur.

Cette intégration offre à la fois sécurité et performance, réduisant la latence de connexion tout en augmentant la confidentialité.

Multiplexage des flux bien fait

Les flux sont connus de HTTP mais pas de TCP, et chaque trame de flux différent est numérotée et transmise comme segments ordonnés dans TCP. Si un segment est perdu, TCP le retransmet après un timeout, bloquant tous les autres.

QUIC résout cela en faisant des flux un concept de premier ordre au niveau transport, éliminant le blocage HoL qui affecte HTTP/2 sur TCP.

Réseaux mobiles et peu fiables

QUIC peut maintenir une connexion lors de changements de réseau, contrairement à TCP qui nécessite la même extrémité (IP et port) tout au long. Cela permet des handoffs transparents entre WiFi et données mobiles, un scénario que TCP n’a jamais été conçu pour gérer.

Conclusion

La Taxe TCP-sur-TCP est un conflit d’intérêts fondamental entre deux couches de fiabilité. En voulant être “trop fiable”, le tunnel devient inutilisable.

Les preuves sont accablantes : - WireGuard dépasse systématiquement les VPN basés sur TCP de 2 à 3 fois - HTTP/3 apporte des améliorations mesurables dans les déploiements réels - Les grandes plateformes internet ont adopté QUIC malgré des coûts CPU plus élevés - Les noyaux modernes intègrent WireGuard nativement, signe d’un consensus industriel

Dans le domaine de l’ingénierie dure, le chemin le plus rapide est souvent celui qui sait quand laisser passer un paquet. Utilisez UDP pour vos tunnels, laissez TCP gérer les données au niveau applicatif, et cessez de payer la taxe.

L’avenir du transport internet est clair : tunnels sans état avec des protocoles basés sur UDP comme WireGuard et QUIC. À mesure que les réseaux deviennent plus rapides et complexes, les leçons architecturales du problème TCP-sur-TCP deviennent encore plus pertinentes. Choisissez judicieusement vos protocoles, comprenez les compromis, et construisez des systèmes qui s’adaptent aux réalités du réseau plutôt que de lutter contre elles.

Ressources supplémentaires

Tester votre propre configuration

Pour mesurer la performance de votre VPN ou tunnel :

# Tester le débit avec iperf3
iperf3 -c <serveur> -t 30 -P 4

# Tester la latence
ping -c 100 <destination>

# Vérifier la perte de paquets
mtr -c 100 <destination>

Comparez les résultats avec et sans votre tunnel actif pour quantifier l’impact sur la performance.