Pourquoi Tor semble plus lent qu’un VPN : clics contre téléchargements

Les pages qui semblent collantes alors que les téléchargements vont à un rythme normal décrivent des allers-retours, pas de la bande passante. Un VPN ajoute un saut chiffré et un circuit Tor en ajoute plusieurs, et chaque saut supplémentaire coûte une poignée de main avant qu’un seul octet utile ne bouge. Ce coût se voit sur une page qui ouvre beaucoup de connexions courtes et disparaît presque lors d’un seul gros transfert. Une fois le schéma visible, le débat cesse de porter sur l’outil le plus rapide.

Le symptôme pointe le coût d’installation, pas la capacité

Le chargement d’une page est une chaîne d’échanges dépendants : une recherche de nom, une poignée de main de transport, une poignée de main TLS, puis la première requête. Chaque saut du chemin insère son propre aller-retour dans cette chaîne avant que quoi que ce soit ne s’affiche. Un gros téléchargement paie le même coût d’installation une fois puis débite en flux, et c’est exactement pourquoi les deux charges de travail ne sont pas d’accord.

Lisez dans le panneau réseau le temps d’attente avant le premier octet, pas le total. Une longue attente avec un téléchargement de contenu court désigne les allers-retours, tandis qu’un long téléchargement avec une attente courte désigne le débit. Répétez vers une seconde destination, car un seul hôte derrière un relais occupé ne prouve rien. Quand le transfert est bon et le clic lent, soupçonnez le coût d’installation bien avant la bande passante.

Le délai et la capacité échouent de manières différentes

Prenez deux mesures et l’essentiel de la confusion se dissipe. La latence est un coût fixe par échange et la capacité est un débit dans le temps, si bien qu’un chemin peut être bon sur la première et mauvais sur la seconde. Un point de sortie lointain avec un processeur au repos répond vite à une petite requête et plafonne tout de même un transfert soutenu à ce que son lien montant permet. Les utilisateurs vivent cette séparation comme un clic vif suivi d’une barre de progression qui bouge à peine.

Testez la capacité avec un transfert soutenu et regardez si le débit reste stable ou en dents de scie. Testez la latence avec une petite requête répétée de nombreuses fois et lisez la dispersion plutôt que le meilleur échantillon, car une dispersion large se ressent plus mal que sa moyenne ne le suggère. Notez les deux chiffres avant et après chaque changement, sinon vous créditerez plus tard la mauvaise variable.

Traiter les deux comme un seul chiffre produit des correctifs qui ne bougent jamais la mesure qui vous importe. C’est la façon la plus courante de répondre à une plainte de latence par une augmentation de bande passante.

Le routage en oignon ajoute des sauts que vous n’avez pas choisis

Un circuit Tor utilise normalement trois relais — un garde, un nœud intermédiaire et une sortie — et le client les choisit dans un consensus, pas sur une carte. Le chemin peut donc être bien plus long que la ligne directe vers la destination. Chaque relais transporte aussi le trafic des autres, donc votre flux partage la capacité qui reste à ce relais.

Réutiliser le circuit adoucit le coût, car un nouveau flux peut chevaucher un circuit existant au lieu de payer une autre construction. Un client qui construit un circuit neuf à chaque requête paie l’installation encore et encore et se ressent bien plus mal qu’un client qui réutilise. Le choix de la sortie compte aussi, car certaines sorties portent une charge plus lourde et rien dans l’interface ne vous dit sur laquelle vous avez atterri. Ce partage est l’intérêt de la conception et la raison pour laquelle la latence ne peut pas être réglée sur une valeur fixe, donc une sortie lente est une mauvaise raison d’abandonner l’arrangement.

Changer l’ordre de la chaîne change l’expérience

VPN d’abord et Tor ensuite est une expérience différente de Tor d’abord et VPN ensuite. Dans le premier arrangement le point de sortie du VPN porte tout le circuit, donc votre réseau d’accès n’apprend que l’adresse du VPN. Dans le second, la connexion VPN est elle-même transportée dans le chemin en oignon, et la sortie voit le trafic VPN. Les deux sont des conceptions légitimes, et comparer l’une ou l’autre à un VPN nu mesure autre chose, ce qui explique pourquoi la page du projet Tor sur la combinaison des deux le présente comme une question sur ce que vous cherchez à cacher avant d’être une question de minutage.

Gardez l’appareil, le réseau d’accès et la destination fixes, et changez exactement un élément entre les exécutions. Déplacer serveurs, circuits et hôtes de test ensemble produit une différence que personne ne peut attribuer. Notez ce que chaque arrangement cache à qui avant de l’optimiser, car une chaîne rapide qui expose ce que vous vouliez cacher n’est pas une amélioration.

Une comparaison qui survit à une seconde exécution

Choisissez deux ou trois destinations que vous utilisez vraiment et chronométrez la même interaction sur chacune, dont une page qui tire beaucoup de petites ressources et un gros transfert. Répétez l’ensemble à une autre heure de la journée.

Rapportez la médiane et le pire cas plutôt que le meilleur échantillon, car le travail interactif se juge à ses mauvais moments. Notez le client, le point de sortie ou la sortie, et si le circuit ou le tunnel a été réutilisé pour cette exécution. Si un changement améliore la médiane tout en aggravant la queue, c’est un compromis et non une victoire, et décider si les utilisateurs le remarqueront est la vraie décision.