Pourquoi un téléchargement VPN est limité par l’upload du serveur

Le client affiche une liaison descendante rapide, le serveur est sur une connexion fibre, et le transfert rampe quand même. Le chiffre que les gens comparent est généralement celui imprimé sur l’offre du client, alors que le paquet traverse d’abord la liaison d’accès sortante du serveur. Cette liaison est le budget dans lequel le transfert doit tenir. Sur une petite connexion domestique, c’est le plus petit chiffre du chemin.

Le chiffre que vous avez lu était dans la mauvaise direction

Un téléchargement vers un client distant consomme de la capacité d’upload à l’extrémité serveur du tunnel. Les débits descendants annoncés du serveur décrivent la direction opposée et ne disent rien de celle-ci. La même asymétrie s’inverse quand le client envoie, ce qui explique qu’une direction peut sembler correcte alors que l’autre est inutilisable.

Le surcoût d’encapsulation et tout trafic concurrent dépensent une partie de ce même budget. Ni l’un ni l’autre n’est visible dans un test de débit qui ne mesure que le client.

Écrivez le chemin comme un budget

Listez chaque frontière que le paquet doit franchir et donnez à chacune un nombre dans la même unité. La livraison depuis la source, le traitement du serveur, la liaison montante du serveur, le chemin intermédiaire, la liaison descendante du client et le traitement du client s’appliquent tous. Le débit utilisable est le plus petit d’entre eux moins le surcoût, et aucun réglage au-dessus de ce plafond ne change le résultat. Écrivez la liste avant de mesurer, car elle vous dit à quel chiffre ne pas croire.

Avec une liaison montante serveur de 20 Mbit/s et une liaison descendante client de 100 Mbit/s, le serveur plafonne le transfert bien avant que le client ne le remarque. Le surcoût et tout transfert simultané prennent une part supplémentaire, et une liaison montante saturée retarde aussi les accusés de réception, ce qui ralentit un transfert TCP sous le plafond brut. Aucun des deux effets n’apparaît dans une comparaison d’offres.

Gardez les mégabits et les mégaoctets séparés, et précisez si chaque chiffre mesure le trafic de la liaison chiffrée ou la charge utile applicative. Mélanger les deux est la raison la plus courante pour laquelle un budget semble ne pas s’additionner. Étiquetez chaque chiffre avec son unité et son point de mesure.

Où la carte vous coûte réellement

Une fois la liaison d’accès suffisamment grande, le matériel du point d’extrémité devient visible, et c’est seulement alors que le processeur compte. Identifiez le modèle, l’agencement des interfaces et l’implémentation utilisée. Une observation sur le bus partagé d’une carte ancienne ne décrit pas chaque révision ultérieure.

Comparez des chemins de traitement individuels plutôt qu’une moyenne CPU unique. Une charge globale modérée peut masquer un cœur saturé qui fait tout le travail par paquet, et la fréquence d’horloge ne se transpose pas entre conceptions de processeurs comme une note de performance. Le débit en paquets compte autant que le débit, car les petits paquets coûtent plus par octet que les gros. Mesurez avec les tailles de paquets que votre charge de travail utilise réellement.

Les limites thermiques et de puissance décident aussi du comportement soutenu. Une courte rafale peut sembler excellente alors qu’un transfert de dix minutes bride, ce qui explique qu’un benchmark de quelques secondes soit un mauvais guide pour une sauvegarde nocturne.

Les recommandations de performance du fournisseur séparent la bande passante d’accès, le CPU, le traitement des paquets, le transport et la taille des paquets en contraintes distinctes. Cela vaut la peine de les lire avant de changer de chiffrement, car un changement de chiffrement déplace rarement une frontière qui n’a jamais été la limite.

Mesurez avant de changer de chiffrement

Lancez un test directionnel qui rapporte le débit réellement atteint à travers le tunnel, puis lancez le même test sur l’interface brute pour comparer. La différence entre ces deux chiffres est le coût du tunnel, et le plus petit des deux plafonds vous dit quelle frontière attaquer.

Gardez la politique de sécurité intacte pendant la comparaison. Un ancien résultat obtenu avec un chiffrement faible ou une carte overclockée n’est pas un plan pour le déploiement actuel.

iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speed

Conservez les résultats directionnels à côté des observations du point d’extrémité de la même exécution. Le prochain changement devrait viser le plafond mesuré plutôt que le composant qui semble le plus petit sur la fiche technique.