Quels sont les signes d’alerte indiquant qu’un relais de tunnel limite le débit ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

What Are the Warning Signs That a Tunnel Relay Is Limiting Throughput? - Zima Store Online

Un relais limite probablement le débit lorsque la connexion reste relayée et s'améliore nettement sur un chemin direct ou plus proche alors que les deux points terminaux sont sous-utilisés.

Les VPN en superposition et les tunnels sortants basculent souvent vers un relais partagé ou auto-hébergé lorsque le NAT traversal ne peut pas établir un chemin pair-à-pair. Le relais peut préserver la connectivité mais ajoute une étape réseau supplémentaire, une file d'attente, une couche TCP ou TLS, un détour géographique, une limite d'équité et un point de traitement. Un diagnostic fiable compare le statut du relais, la latence, le jitter, la direction, le CPU des points terminaux et un contrôle du chemin direct au lieu d'accuser le chiffrement ou le NAS à cause d'une seule copie de fichier lente.

Confirmer que le chemin des données est réellement relayé

Vérifiez le statut du pair du client tunnel pendant que le trafic est actif. Notez si le chemin est direct, relayé, proxifié ou en changement de mode, ainsi que la région ou l'hôte relais sélectionné.

Un problème Tailscale documente des clients cellulaires restant sur DERP avec une latence allant de 200 à 900 millisecondes. Un statut connecté prouve donc la joignabilité, pas un chemin de données efficace.

Si le client rapporte une connectivité directe tout au long du test lent, ne désignez pas le relais comme cause. Poursuivez avec les tests CPU des points terminaux, déchargements du tunnel, MTU, upload ISP, Wi-Fi et stockage.

Comparer les chemins relayés et directs avec les mêmes points terminaux

Effectuez un test de débit réseau uniquement entre le même client et le serveur domestique en mode relayé, puis répétez après avoir établi un chemin pair direct ou un réseau de test temporaire accessible par port. Gardez le protocole, la direction et le matériel des points terminaux inchangés.

Un cas publié de relais pair a mesuré à la fois une grande réduction de latence et une augmentation du débit par 12,5 fois après avoir changé uniquement la topologie du relais.

Une amélioration importante et répétable après suppression ou déplacement du relais est une preuve solide. Un petit changement signifie que le relais n'est peut-être pas le goulot d'étranglement dominant, surtout lorsque l'upload domestique ou le Wi-Fi distant fixe déjà un plafond inférieur.

Surveillez la latence élevée, le jitter et les détours géographiques

Mesurez la latence minimale, médiane et aux percentiles élevés vers le pair et vers la région relais. Notez le jitter et la perte de paquets pendant les périodes d'inactivité et lors d'un transfert soutenu.

Un rapport de diagnostic indépendant a capturé un chemin relayé avec une latence moyenne supérieure à 400 ms, un jitter important et une perte de paquets mesurable, une combinaison qui peut faire échouer les transferts de fichiers TCP et l'accès interactif même lorsque le tunnel reste établi.

Si le relais est géographiquement éloigné des deux points terminaux ou si la latence varie fortement sous charge, testez une région plus proche, un relais auto-hébergé ou un relais pair. Une latence relais stable et basse avec un débit faible indique plutôt une capacité, une équité, un CPU ou un comportement de transport limitant.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

Vérifiez si le relais a un plafond de débit constant

Effectuez plusieurs transferts importants à différents moments et dans les deux sens. Une limite de relais apparaît souvent comme un plateau stable qui ne monte pas lorsque la vitesse internet des points terminaux, le stockage NAS ou le Wi-Fi client s'améliorent.

Les travaux de benchmark sur les implémentations de relais montrent que la capacité de transfert, l'efficacité CPU et la charge concurrente affectent matériellement le débit du tunnel. Un projet DERP-compatible actuel publie des benchmarks multi-charge de relais selon la taille du CPU et les niveaux de trafic.

Si un flux plafonne, ajoutez un second flux contrôlé et observez le débit total. Un plafond partagé fixe suggère une capacité du relais ou du chemin ; un débit faible inchangé avec un CPU relais inactif suggère RTT, perte, contrôle de congestion ou contraintes des points terminaux.

Distinguer les limites du relais du CPU des points terminaux et de l'upload ISP

Surveillez le CPU, les interruptions logicielles, l'utilisation du processus de chiffrement, l'utilisation de la carte réseau et l'activité disque aux deux points terminaux et au relais auto-hébergé. Comparez la direction lente avec la capacité mesurée d'upload et de download de la connexion domestique.

Un relais ne peut transférer aussi vite que sa jambe entrante ou sortante la plus lente. Faire tourner le relais sur un VPS bas de gamme, une région éloignée, un conteneur contraint ou une liaison montante domestique partagée peut reproduire le même symptôme qu'un plafond de relais géré.

Si le CPU du point terminal ou du relais atteint la saturation, optimisez ou mettez à niveau ce nœud avant de changer la géographie du relais. Si le CPU est faible mais qu'une direction ISP est saturée, le relais expose la limite du lien d'accès plutôt que de la créer.

Changez la conception du relais à la limite d'arrêt

Remplacez le chemin relais lorsqu'il reste sélectionné pour le trafic normal, crée une latence ou un jitter inacceptables, plafonne le débit soutenu en dessous des besoins de la charge de travail, et qu'un contrôle direct ou un relais plus proche prouve que le reste du chemin peut mieux performer.

Le guide ZimaSpace sur les alternatives d'accès à distance CGNAT explique pourquoi un relais peut être nécessaire même s'il n'est pas le chemin le plus rapide.

Choisissez un relais pair plus proche, un VPS mieux positionné, une meilleure traversée NAT ou un flux de travail à bande passante réduite plutôt que de désactiver le seul chemin accessible sans remplacement. Validez la nouvelle conception avec la charge de travail originale de fichiers distants, médias ou synchronisation, pas seulement un ping court.