Un VPN peut-il être plus rapide que la connexion directe ?

Un transfert qui rampe sur la connexion du bureau se termine parfois vite à travers le tunnel, et l'encapsulation supplémentaire rend cela apparemment impossible. Le paradoxe apparent vient de la comparaison des mauvaises choses. Le tunnel ajoute du travail, et il change aussi le chemin réseau que suit le trafic, l'adresse que voit la destination et parfois le serveur qui répond. Choisir entre les deux itinéraires exige de séparer ces trois effets avant toute conclusion sur le débit.

Trois choses que le tunnel peut changer

La première est le transit. Le routage Internet suit la politique de l'opérateur et les relations commerciales, pas la latence mesurée, donc le chemin via un fournisseur VPN peut traverser des réseaux différents de la route directe. Il peut éviter un point d'échange saturé ou atterrir sur un mieux apparié, et il peut tout aussi bien être pire.

La seconde est la destination. Un changement d'adresse de sortie modifie souvent la réponse DNS, et un réseau de contenu peut vous offrir un autre cache ou une autre région. Une partie de l'amélioration revient alors au nouveau serveur et non au tunnel. Le même nom d'hôte peut atterrir sur un serveur plus proche ou moins chargé sans que rien ne change côté client.

La troisième est le comportement du transport. L'encapsulation modifie la taille effective des paquets, et un tunnel qui évite un segment intermédiaire sujet aux pertes peut laisser un flux TCP agrandir sa fenêtre au lieu de reculer sans cesse. Aucun de ces effets n'est un mécanisme d'accélération universel ; chacun est une condition à observer. Les séparer, c'est ce qui transforme une curiosité en fait.

Ce qu'il ne peut pas changer

Rien dans le tunnel n'ajoute de capacité au lien entre l'appareil et le réseau. Un canal Wi-Fi saturé, un dernier kilomètre congestionné ou un forfait mobile plafonné limitent les deux chemins de la même manière, et un test de débit à travers le tunnel ne peut pas dépasser ce plafond. Le même lien transporte les paquets encapsulés, donc l'encapsulation peut consommer de la capacité mais jamais en créer. Ce qui change, c'est où vont les paquets après avoir quitté ce lien. C'est pourquoi un résultat rapide par le tunnel a toujours une explication en amont du premier saut.

Les limites côté serveur sont tout aussi indifférentes. Si l'hôte distant sert lentement, un meilleur chemin ne fait que livrer la réponse lente plus efficacement, et l'utilisateur attend toujours. Une origine partagée sous charge paraît lente sur les deux chemins au même moment.

Comparez les chemins correctement

Gardez l'application, le sens, la durée et la concurrence identiques, et ne changez que le chemin. Lancez chaque test plus d'une fois, à la même heure de la journée, et notez l'adresse de sortie et la réponse du résolveur à côté du débit. Une exécution est un échantillon et non une mesure, et un téléchargement rapide peut être un succès de cache qui ne dit rien de la route. Écrivez les conditions avant les résultats, car les chiffres sont difficiles à interpréter ensuite.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

La réponse du résolveur est le détail que la plupart des comparaisons omettent, et elle explique les « améliorations » qui disparaissent lorsqu'on force le même serveur. Si l'adresse diffère entre les exécutions, le test a comparé deux destinations et non deux chemins. Rapportez la latence et la perte à côté du débit, car un chemin plus rapide globalement mais qui ajoute du délai à chaque requête interactive n'est pas meilleur pour la charge de travail qui s'est plainte. Le temps aller-retour compte plus que le débit en masse pour tout ce qui demande et attend.

Quand la différence mérite d'être conservée

Si un tunnel approuvé améliore de façon fiable une charge de travail précise, c'est un choix d'exploitation légitime : documentez la charge, la mesure et la sortie utilisée. Un enregistrement utilisable nomme un hôte, l'adresse de sortie produite par le tunnel, la réponse du résolveur et les mêmes chiffres du chemin direct le même jour. Cela suffit au prochain ingénieur pour refaire la comparaison au lieu de la rediscuter. Ce n'est toujours pas la preuve que le fournisseur limite quoi que ce soit, et cela ne se transpose pas à d'autres applications ni à d'autres heures.

Conservez l'enregistrement de mesure avec la configuration. Il répond à la question suivante : l'amélioration existe-t-elle encore, et c'est la seule façon de savoir si le chemin ou la charge de travail a changé. Un enregistrement sans date ne peut pas répondre du tout à cette question.