Pourquoi les vitesses du VPN WireGuard chutent avec une latence élevée

Introduction

De nombreux utilisateurs se connectent depuis l’étranger au serveur WireGuard de leur routeur GL.iNet et s’étonnent d’obtenir des débits bien inférieurs à ceux de leur connexion gigabit symétrique à domicile, voire à ceux de leur connexion locale à l’étranger (dans un Airbnb, par exemple). Le fournisseur d’accès à Internet, côté serveur ou côté client, peut être en cause. Mais on néglige souvent la latence, alors qu’elle influe fortement sur les débits descendant et montant. Cet article explique pourquoi une latence élevée, visible dans le résultat du ping, réduit les performances et quels débits vous pouvez raisonnablement attendre.

Qu’est-ce que la latence et pourquoi est-elle importante ?

La latence correspond au temps nécessaire aux données pour aller de votre appareil au serveur VPN et revenir. Elle se mesure généralement en millisecondes (ms). Par exemple, si votre routeur GL.iNet au Vietnam se connecte à un serveur VPN au Texas, le temps aller-retour (RTT) peut facilement atteindre 250-300 ms.

Même avec une connexion Internet « rapide », une latence élevée peut fortement limiter les débits descendants et montants réels, surtout avec les protocoles fondés sur TCP, comme HTTPS, les transferts de fichiers et la plupart des applications. WireGuard utilise lui-même UDP, mais le trafic qui traverse le tunnel VPN (navigation Web, streaming, etc.) repose souvent sur TCP. WireGuard encapsule alors ces données TCP dans UDP pour les transmettre sur Internet.

Le goulot d'étranglement TCP : le débit est lié à la latence

Voici la formule clé qui régit les performances TCP :

Taille de la fenêtre TCP = Débit x RTT
Voici d’abord quelques définitions :

• La taille de la fenêtre TCP est la quantité de données que votre système peut garder « en transit » avant de devoir recevoir un accusé de réception.
• Le débit est la quantité de données que vous pouvez envoyer ou recevoir chaque seconde.
• Le RTT (temps aller-retour) est le délai entre l’envoi des paquets et la réception de la réponse.

Un exemple concret partagé sur le subreddit GL.iNet

Imaginons que vous soyez au Vietnam et que vous vous connectiez au serveur VPN WireGuard de votre domicile au Texas, hébergé sur un routeur GL.iNet Flint 2.

• Emplacement du serveur : Texas, États-Unis
  
  • Débits locaux (fibre symétrique) 700 Mbps en téléchargement / 940 Mbps en envoi
• Emplacement du client : Vietnam
  
  • Débits locaux (sans VPN) : 455 Mbps en téléchargement / 634 Mbps en envoi
    
  • Débits locaux (avec le client VPN WireGuard activé) : 47.3 Mbps en téléchargement / 12.1 Mbps en envoi, ping de 288 ms

Commençons par deux facteurs qui peuvent limiter n’importe quelle connexion réseau :

1. Variation des performances du fournisseur d’accès et congestion du réseau dans votre quartier : les débits peuvent varier de plusieurs centaines de Mbps.
2. Performances Wi-Fi : elles varient fortement selon l’environnement physique, les interférences d’autres appareils sans fil, les capacités de l’appareil client et le fonctionnement intrinsèquement semi-duplex du Wi-Fi, contrairement à l’Ethernet full-duplex.
   • Pour une explication détaillée des débits Wi-Fi réellement possibles, consultez : https://www.wiisfi.com/ Vous ne pouvez pas agir sur le premier facteur. Le second dépend aussi largement de circonstances extérieures, mais vous pouvez l’éviter en utilisant une connexion Ethernet filaire lorsque c’est possible.

Le produit bande passante-délai

À première vue, les résultats du test de débit VPN côté client peuvent sembler décevants. Ils sont pourtant assez bons compte tenu de la latence. Reprenons la formule précédente :
Taille de la fenêtre TCP = 47.3 Mbps x 0.288 seconde
　 　 　 　    = 13.6 Mb, soit ~1.7 MB

Une fenêtre TCP de 1.7 MB est déjà assez grande. L’atteindre sur une connexion dont la latence est de 288 ms indique que TCP fonctionne relativement bien. Mais comment est-ce possible alors que le champ de taille de fenêtre TCP d’origine est limité à 65,535 octets (environ 64 KB) ?

Mise à l’échelle de la fenêtre TCP pour améliorer les performances

La réponse tient à la mise à l’échelle de la fenêtre TCP (TCP Window Scaling), conçue pour les réseaux modernes à haut débit et à forte latence. Comme l’explique Microsoft, le champ de taille de fenêtre TCP ne comporte que 16 bits : sans mise à l’échelle, la fenêtre est donc limitée à 65,535 octets. L’option définie dans la RFC 7323 permet de décaler cette valeur vers la gauche de 14 bits au maximum, ce qui porte la taille maximale de la fenêtre à 1 GB. Le facteur d’échelle est négocié lors de l’établissement de la connexion TCP en trois temps. Une fois cette option activée, les deux extrémités peuvent multiplier la taille de fenêtre initiale. Les algorithmes de contrôle de congestion du système d’exploitation de l’appareil client cherchent en permanence la bonne valeur. Dans certains cas, notamment sous Microsoft Windows, le réglage automatique de la fenêtre optimise très mal le débit descendant.

Exemple de taille de fenêtre TCP négociée par le système d'exploitation et d'effet de latence sur le débit Source : duckware.com/blog/how-windows-is-killing-internet-download-speeds

Pourquoi ne pas augmenter indéfiniment la taille de la fenêtre TCP ?

La taille de la fenêtre TCP dépend de la bande passante disponible et du temps aller-retour. Pour autant, l’agrandir ne suffit pas à augmenter le débit. Au-delà d’un certain seuil, une fenêtre plus grande exige davantage de mémoire et de puissance de calcul côté émetteur comme côté récepteur. Les appareils et le réseau risquent alors d’être surchargés, avec davantage de pertes de paquets et des performances en baisse.

Dans notre exemple, une fenêtre TCP d’environ 1.7 MB est donc normale et témoigne d’une connexion qui fonctionne bien malgré la forte latence. Une limite pratique d’environ 2 MB peut représenter un compromis entre débit et ressources consommées sur de nombreux systèmes modernes. Avec une fenêtre de 2 MB et une latence de 288 ms, le débit maximal théorique serait d’environ 55.5 Mbps. Cela explique pourquoi il est difficile d’aller au-delà, même si les connexions Internet du serveur et du client sont beaucoup plus rapides. En isolant le débit dans la formule précédente, on obtient théoriquement environ 200 Mbps avec une fenêtre de 2 MB et une latence de 80 ms. Mais la distance physique entre le Texas et le Vietnam rend cette latence impossible à atteindre (Texas <-> Vietnam).

Conclusion

Nous espérons que ces explications vous aideront à mieux estimer les débits descendants et montants que vous pouvez obtenir lorsque vous utilisez votre VPN WireGuard depuis l’étranger. N’oubliez pas non plus qu’un routeur gère de nombreuses sessions TCP en même temps. Le GL.iNet Flint 2 dispose de 1 GB de RAM DDR4, mais le routeur client qui s’y connecte peut avoir beaucoup moins de mémoire et limiter ainsi la mise à l’échelle de la fenêtre TCP.

Pour mieux comprendre votre configuration VPN WireGuard et résoudre d’éventuels problèmes, consultez cet article du forum GL.iNet : https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502

Présentation des routeurs domestiques GL.iNet