Pourquoi deux tests de débit VPN sur le même tunnel divergent

Deux exécutions, un seul tunnel, et des chiffres qui diffèrent d'un facteur trois. Le tunnel n'a pas changé entre les deux. Ce qui a changé, c'est la mesure : un site de test qui choisit un serveur d'après votre localisation apparente, un nombre de flux qui décide si un démarrage lent ou six remplissent le tuyau, et une durée assez courte pour se terminer avant même que le chemin soit correctement utilisé. Les tests de débit ne sont pas faux, mais ils répondent à une question plus étroite que celle qu'on leur pose.

Une nouvelle adresse de sortie change la destination du test

La plupart des sites de test choisissent automatiquement un serveur de mesure, et ils le choisissent en partie en regardant d'où votre connexion semble venir. Activez le tunnel et votre pays apparent change, donc le serveur choisi change, et la comparaison porte désormais sur deux routes différentes vers deux hôtes différents.

Le résultat n'est pas du tout une mesure du VPN. C'est une mesure de votre chemin vers un serveur que vous n'avez pas choisi, et l'écart entre les deux exécutions peut être dominé par le peering de ce serveur plutôt que par quoi que ce soit que le tunnel ait fait.

Fixez la destination avant de changer autre chose. Tout outil crédible vous laisse choisir un serveur explicitement, et quand ce n'est pas le cas, la page de résultats nomme en général celui utilisé, ce qui suffit pour remarquer que les deux exécutions ne sont pas comparables. Vérifiez ce que le site a vu avant de faire confiance à son choix :

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Si le pays a changé entre les exécutions, tout ce que le test a choisi ensuite a changé aussi. Notez la sortie observée à côté de chaque résultat et la confusion disparaît en grande partie.

Le démarrage lent se termine après la fin de la plupart des tests courts

Une connexion TCP ne commence pas au débit du lien. Elle commence avec une petite fenêtre de congestion, la double à peu près à chaque aller-retour, et n'atteint la capacité du chemin qu'après plusieurs allers-retours. Un test de dix secondes sur un chemin à forte latence peut passer une part substantielle de sa vie dans cette montée.

C'est pourquoi un tunnel plus latent obtient un moins bon score sur un test court qu'il ne le mériterait, et pourquoi une exécution plus longue rapporte souvent un chiffre plus élevé sans aucun changement de configuration. Le cadre de débit RFC 6349 traite cela explicitement, et c'est pourquoi les mesures sérieuses durent assez longtemps pour atteindre un régime stable. Une exécution de cinq secondes sur un chemin satellite mesure l'accélérateur, pas la route.

Regardez les phases de la connexion plutôt que de faire confiance à un seul chiffre. Curl rapporte chaque étape séparément, ce qui montre si le temps part dans la poignée de main, dans la montée ou dans le transfert :

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Lancez-le deux fois de suite vers la même destination. Si la seconde exécution est bien plus rapide, vous mesuriez la montée, pas le chemin, et toute comparaison qui n'a utilisé que la première est suspecte.

Un flux et six flux mesurent des choses différentes

Un seul flux TCP est limité par la fenêtre qu'il peut garder en vol, soit à peu près le temps d'aller-retour multiplié par le débit. Sur un long chemin, ce produit dépasse ce qu'un flux utilisera, donc un seul téléchargement sous-déclare la capacité existante. Six flux parallèles comblent l'écart et produisent un chiffre plus grand.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Les deux chiffres sont vrais. Celui d'un seul flux dit ce que fera un téléchargement, ce qu'un onglet de navigateur obtient généralement. Le chiffre parallèle dit ce que le chemin peut porter au total, ce qu'un torrent ou un téléchargement en plusieurs parties peut exploiter. Citer l'un comme s'il était l'autre, c'est ainsi qu'un tunnel sain se fait remplacer sans raison.

Comparer un résultat parallèle à un résultat mono-flux est la façon la plus courante de conclure qu'un VPN a divisé sa vitesse par deux. Alignez la méthode, puis comparez. La trace de la troisième commande ajoute le contexte manquant : un chemin à forte gigue donnera des résultats incohérents dans les deux modes, et aucun nombre de flux n'y remédie.

Le chiffrement coûte du temps processeur, l'encapsulation coûte des octets

Deux mécanismes s'exécutent sur chaque paquet, quelle que soit la vitesse du lien. Le chiffrement consomme du processeur par octet, et l'encapsulation ajoute des octets d'en-tête que le lien doit quand même transporter. Les deux se manifestent comme un plafond, et leurs symptômes diffèrent.

Le plafond processeur apparaît comme un plateau : le débit cesse de monter quel que soit le nombre de flux ajoutés, et le processeur de la machine est occupé alors que le lien ne l'est pas. Sur un petit routeur ou un téléphone, c'est souvent la vraie limite, et c'est pourquoi une ligne rapide peut tout de même donner un tunnel modeste.

Le coût en octets est plus faible mais constant. Des en-têtes supplémentaires signifient moins de charge utile par paquet, et sur un chemin à unité de transmission maximale fixe, ils peuvent aussi déclencher de la fragmentation ou un trou noir qui se manifeste par un blocage sur les gros transferts plutôt que par une moyenne lente.

Ces trois cas sont souvent confondus parce que les utilisateurs les décrivent tous comme « le VPN est lent ». Seul le premier réagit à une machine plus puissante, seul le second réagit à une MTU plus petite, et seul le troisième réagit à la gestion des files.

Mettez la méthode dans le dossier

Un résultat qui mérite d'être conservé nomme l'appareil, le réseau d'accès, la sortie, le serveur de mesure, le sens, le nombre de flux et la durée. Sans cela, deux chiffres ne peuvent pas être comparés, et un ticket qui contient un seul chiffre est en réalité une humeur.

Gardez aussi les mauvaises exécutions. Une série où une sortie provoque un blocage à chaque fois est bien plus instructive qu'une moyenne, et les blocages sont exactement ce que les moyennes cachent.

Testez ensuite ce qui vous importe vraiment. Si l'objectif est un gros téléchargement, téléchargez le fichier. Si l'objectif est un appel, mesurez la latence sous charge plutôt que le débit au repos, car un tunnel peut bien scorer sur un test de débit et rendre malgré tout chaque réunion inaudible.