Pourquoi un téléchargement via VPN peut battre votre connexion directe

Connectez le tunnel, lancez un gros téléchargement, et il avance à environ deux fois la vitesse que le même fichier atteignait sans lui. Cela ressemble à de la publicité, mais il peut s’agir d’une mesure réelle sur une ligne grand public. La cause habituelle est une limite de débit attachée à un port : le tunnel transporte votre transfert là où le régulateur ne regarde pas, et la capacité réelle de la ligne apparaît pour la première fois.

Ce qui signifie que le chiffre intéressant n’est pas la vitesse du VPN. C’est la part de votre ligne que vous n’obteniez jamais, et pourquoi.

Un plafond qui suit le port, pas la route

Un fournisseur d’accès peut limiter le débit par abonné selon le protocole ou le port de destination, et le port 80 est une cible favorite parce qu’une grande partie de la navigation ordinaire l’utilise. La limite n’est souvent pas appliquée dès le premier paquet : le transfert démarre près du débit de la ligne, consomme une franchise de rafale, puis se stabilise sur le chiffre plafonné. Les premières secondes paraissent saines et le reste du transfert non.

Envoyez les mêmes octets par un autre port et le régulateur du 80 ne les voit jamais. Le tunnel semble battre la connexion directe alors qu’il a ajouté un saut, du chiffrement et ses propres frais. Ce qui s’est amélioré n’est pas le chemin mais l’absence d’une règle.

C’est aussi pourquoi l’effet est si constant d’un fichier et d’une destination à l’autre. Si le plafond est sur le port, tout ce qui passe par ce port se comporte de la même façon, quelle que soit la taille du fichier et quel que soit l’hôte. Une destination qui attire une autre règle montre une autre courbe, et cette différence est diagnostique en soi.

Mesurez le plateau, pas le pic

Un pic est la partie la moins informative d’un transfert, car toute connexion paraît bonne pendant que ses tampons se remplissent. Notez où le débit se stabilise et combien de temps il y reste.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Exécutez la paire coup sur coup sur la même machine, à la même heure, vers des hôtes de réseaux comparables. Un seul échantillon ne prouve rien ; la forme de la courbe sur deux exécutions de chacun est ce qui distingue une franchise de rafale d’un plafond stable. Notez où le débit s’aplatit plutôt que ce qu’a montré la première seconde, car la rafale est précisément ce qu’un régulateur vous accorde avant de commencer à limiter. Un plateau calme qui tient jusqu’à la fin du transfert est le chiffre à comparer.

Gardez le fichier déjà compressé pour que la compression de transport ne puisse pas être proposée comme explication. Un PDF ou une archive supprime cette variable, et empêche aussi quiconque d’affirmer que le tunnel a comprimé la charge utile. Si les deux transferts utilisent le même fichier, la seule différence restante est le chemin et le port. Notez l’outil et le port à côté de chaque chiffre, sinon la seconde exécution n’est pas comparable à la première.

Trois comparaisons qui isolent la cause

Faites-les dans l’ordre et arrêtez-vous dès que le schéma est clair, car chacune écarte une histoire différente.

1. Répétez le même téléchargement par le chemin web ordinaire et par un outil de transfert sur un autre port, depuis un hôte de capacité comparable.
2. Répétez les deux avec un fichier incompressible, pour que la compression cesse d’être candidate.
3. Si vous administrez vous-même le serveur du tunnel, reliez-le au port 80, ajustez le profil du client pour que les deux extrémités s’accordent, et transférez à nouveau. Si le tunnel se tient désormais au débit web plafonné, la restriction suit le port et non le VPN.

La troisième étape est la décisive, et c’est aussi celle que les gens sautent parce qu’elle exige un changement de configuration. Sans elle, vous avez montré que deux choses diffèrent, pas que le port est la raison.

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, ni que d’autres ports de la ligne soient sans restriction. Elle décrit ce transfert, sur cette ligne, à cette heure. Les limites peuvent s’appliquer par session, par abonné ou selon l’heure de la journée, et elles peuvent changer sans préavis.

Elle ne prouve pas non plus que le chemin direct est cassé. Un chemin plafonné fonctionne encore ; il est limité exprès, et une politique délibérée n’est pas une panne en attente de réparation.

Et elle ne justifie certainement pas de tout router par le tunnel. Chaque application sur le port 80 reste plafonnée, tandis que tout ce que vous détournez dépend désormais d’un saut supplémentaire et d’un mode de défaillance supplémentaire.

Transformez la constatation en quelque chose d’actionnable

Écrivez l’observation comme une mesure et non comme un verdict : les gros transferts sur le port 80 se stabilisent près de la moitié du débit que le même fichier atteint sur un autre port, à ces heures, sur cette ligne, avec ces échantillons en pièce jointe. C’est une demande de support que quelqu’un peut examiner.

« Le VPN est plus rapide » ne l’est pas. Cela invite une réponse sur les frais de chiffrement, et cette réponse est techniquement correcte tout en n’apprenant rien d’utile à personne. Joignez le nombre d’échantillons, l’heure et le port, pour que le lecteur puisse reproduire le schéma.

Si vous décidez de continuer à utiliser un autre port pour les transferts massifs, notez la réserve dans vos propres relevés : déplacer un écouteur sur le port 80 entre en collision avec tout serveur web déjà lié là, et la panne qui en résulte ressemble à un tunnel cassé plutôt qu’à un conflit de ports.