Pourquoi un téléchargement est plus rapide par le VPN que directement

Vous lancez un gros téléchargement, les premières secondes semblent normales, puis le débit se stabilise autour de la moitié de ce que la ligne devrait fournir. Vous connectez le tunnel, répétez le même téléchargement, et il tient un débit plus élevé sur tout le fichier. C’est à la fois une mesure réelle et une conclusion trompeuse, car le tunnel n’a pas rendu le chemin plus rapide. Il a seulement sorti votre trafic d’un port que quelque chose sur le trajet limitait.

La forme de la courbe le trahit

Observez le transfert plutôt que le chiffre final. Un chemin bridé commence généralement près du débit de la ligne, consomme son allocation de rafale puis se stabilise à la limite, si bien que la moyenne dépend de la durée de votre observation. Un tunnel qui aurait réellement amélioré le chemin afficherait un meilleur débit dès la première seconde et le maintiendrait. Le plateau est l’empreinte, et il est facile de le manquer si vous ne notez que le pic.

Deux passages du même fichier, l’un direct et l’autre par le tunnel, suffisent à voir s’il existe un plateau.

Notez quand le plateau commence, combien de temps il dure et quel débit il tient. Ces trois valeurs distinguent un limiteur d’un chemin congestionné, car la congestion laisse le débit varier alors qu’un limiteur le fixe à un seul chiffre. Si le passage direct se dégrade progressivement et que le passage par le tunnel reste stable, vous regardez une politique et non de la physique.

Trois comparaisons, une variable chacune

Ne changez qu’une chose par passage, sinon vous n’apprenez rien. Récupérez le même fichier par le chemin web ordinaire, puis par un outil de transfert qui utilise un autre port, depuis un hôte de capacité comparable et à la même heure. Gardez la machine cliente fixe, car un portable qui change de réseau ajoute une variable que vous ne contrôlez pas.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Utilisez un fichier déjà compressé, comme une image disque, afin que la compression de transport ne puisse pas expliquer la différence. Ensuite, si vous contrôlez le serveur, déplacez son écouteur vers le port que vous soupçonnez d’être bridé, mettez à jour le profil client et recommencez. Si le tunnel tombe maintenant au débit bridé, la limite suit le port et non le tunnel, et la question est tranchée. Faites chaque comparaison deux fois et conservez les chiffres du plateau, pas les pics.

Notez aussi l’heure, car un limiteur peut être horaire et un test du soir peut contredire un test du matin. Deux passages à la même heure valent plus que dix répartis sur la journée.

Ce que cette mesure ne peut pas étayer

Elle ne montre pas que le tunnel est plus rapide en général, qu’il compresse quoi que ce soit ou que d’autres ports ne sont pas bridés. Elle décrit un transfert sur une ligne pendant une heure. Les limites peuvent être par session, par abonné ou horaires, et un opérateur peut les modifier sans l’annoncer.

Elle ne montre pas non plus que le chemin direct est défectueux. Un chemin bridé fonctionne exactement comme prévu, il est simplement limité par une politique.

Cette distinction compte quand vous rédigez le compte rendu. Une panne appelle un ticket de réparation, tandis qu’une politique appelle une question sur le contrat ou une décision de la contourner. Appeler un plafond une panne produit une conversation avec le support qui part d’une prémisse fausse. L’appeler une politique vous permet de poser une question précise qui a une réponse précise.

Transformez la constatation en demande d’assistance

Utilisez les chiffres et laissez la conclusion de côté. Une demande indiquant que les gros transferts sur le port 80 restent autour de la moitié du débit attendu pendant ces heures, avec les chiffres du plateau joints, est exploitable. Une demande disant que le VPN est plus rapide ne l’est pas, car elle se lit comme une affirmation sur le tunnel plutôt que comme une observation sur la ligne. Joignez les deux passages et leurs horodatages, puis laissez l’opérateur décrire la politique.

Ne poussez pas chaque application dans le tunnel uniquement pour courir après ce chiffre.

Le tunnel vous coûte encore un saut supplémentaire, du chiffrement et un nouveau lot de modes de défaillance, tandis que le port limité le reste pour tout ce qui d’autre l’utilise. Quand de gros transferts doivent aboutir de manière fiable, tenez votre propre note du port qui porte la limite. Déplacer un écouteur sur le port 80 entre aussi en collision avec tout serveur web déjà lié à ce port, et cela produit une nouvelle panne au lieu d’un correctif.