Pourquoi la pénalité du VPN paraît pire en réseau mobile qu’en Ethernet

Le même ordinateur portable, le même serveur et le même tunnel peuvent perdre un cinquième de leur débit en Ethernet et trois quarts en réseau mobile, et aucun des deux chiffres ne signifie que le VPN est cassé. Chaque réseau d’accès fournit un chemin différent, et le tunnel en ajoute un second par-dessus. Comparer un chiffre tunnelisé à un chiffre non tunnelisé ne répond à rien, car les deux chiffres décrivent des dénominateurs différents. Quatre cellules et une fraction de rétention par ligne vous diront quelle question poser ensuite.

Quatre cellules, pas une seule pénalité

Mesurez la référence directe et le résultat tunnelisé sur chaque réseau d’accès, et conservez-les sous forme de matrice plutôt que de verdict unique. La référence est la même tâche effectuée sur ce réseau sans le tunnel ; le résultat tunnelisé est la même tâche avec lui.

Utilisez une charge de travail autorisée pour les tests directs et maintenez les contrôles de confidentialité exigés par l’environnement. Un test qui enfreint la politique produit un chiffre que vous ne pouvez pas publier et que vous ne devriez pas répéter.

Gardez les variables fixes

Gardez l’appareil, l’application, la destination, le sens du transfert et le point de terminaison VPN fixes sur les quatre cellules. Si un service change silencieusement de serveur de test entre deux exécutions, notez le changement et traitez la paire comme non contrôlée au lieu de lisser l’écart par une moyenne.

Répétez la matrice dans les deux sens et à des heures comparables. Les conditions d’une radio mobile et la charge de sa cellule changent en quelques minutes, si bien qu’une seule référence exceptionnellement bonne peut exagérer la pénalité apparente. Notez la dispersion des résultats à côté d’une valeur représentative, et précisez si les exécutions tunnelisées étaient entrelacées avec les références ou réalisées en bloc.

L’entrelacement compte plus que la plupart des gens ne l’imaginent. Une référence mesurée avant le déjeuner et une exécution tunnelisée mesurée après sont deux réseaux différents portant le même nom.

Gardez le dénominateur visible

Rapportez la fraction de rétention ainsi que le débit absolu : E1 divisé par E0, et C1 divisé par C0. Une liaison rapide qui conserve une petite part de son débit et une liaison lente qui en conserve la majeure partie sont des constats différents, et seule la fraction montre la différence.

Le débit absolu décide encore de ce qu’un utilisateur peut faire. La fraction décide où regarder. Quand Ethernet conserve la majeure partie de sa référence et que le mobile en conserve beaucoup moins, la variable intéressante se trouve sur le chemin mobile plutôt que dans le chiffrement.

Les deux chiffres appartiennent au rapport, car chacun seul soutient une conclusion que les données ne soutiennent pas.

Lisez le schéma avant de changer quoi que ce soit

Des plafonds tunnelisés similaires sur les deux réseaux pointent vers quelque chose de partagé : le point de terminaison, son processeur, une limite de débit ou un seul saut congestionné. Une baisse qui n’apparaît qu’en mobile pointe vers la route de ce réseau, la perte, la latence et la taille effective des paquets.

Ce sont des pistes, pas des diagnostics, et la différence compte quand vous rédigez le ticket. Un plafond partagé ne s’améliorera pas si vous changez le modem mobile, et une baisse propre au mobile ne s’améliorera pas si vous redimensionnez le point de terminaison. Indiquez lequel des deux schémas vous avez observé avant de proposer un changement. Ainsi le changement porte une prédiction, et la mesure suivante peut la confirmer ou l’anéantir.

Les propres recommandations de performance d’OpenVPN séparent les contraintes de bande passante, de processeur, de transport et de taille de paquet selon les mêmes lignes, ce qui rappelle utilement que le tunnel est rarement une seule variable.

Quand la taille de paquet est le suspect

L’encapsulation consomme de l’espace de paquet, si bien que la taille effective sur un chemin mobile peut être inférieure à celle annoncée par l’interface. Conservez des preuves de taille de paquet pour le chemin que vous comparez au lieu de supposer une valeur à partir du nom de la technologie d’accès.

Datagram packetization-layer path MTU discovery décrit la découverte de la taille effective plutôt que son codage en dur. Utilisez les observations prises en charge par l’implémentation, et n’imposez pas un MTU bas arbitraire à chaque client par précaution, car cela échange un problème contre un pire sur des chemins qui allaient bien.

Une hypothèse de taille a besoin de ses propres preuves : le même transfert à deux tailles, avec le schéma de perte enregistré.

Ajoutez une variable à la fois

Ne comparez un transport alternatif qu’une fois la matrice de référence enregistrée. Cela maintient une variable délibérée en jeu et vous permet d’attribuer le changement au lieu de le deviner.

Gardez le dimensionnement de la charge utile TCP distinct du comportement des datagrammes UDP, car les deux réagissent différemment à la perte et à la taille du chemin. Une amélioration issue d’un changement de transport est une preuve sur ce transport, pas la preuve que le chiffrement ou la couverture étaient la cause d’origine.

Ordre du travail : remplir les quatre cellules, calculer les deux fractions, entrelacer les exécutions, puis choisir une hypothèse et la tester par un seul changement. Tout le reste est une comparaison de deux inconnues.