Comment mesurer la qualité d'un proxy mobile : 7 métriques, protocole et scripts

Introduction : pourquoi un seul chiffre de vitesse ne suffit pas

Imaginez que vous choisissez un proxy mobile et voyez un joli chiffre : vitesse 50 mégabits. Ça a l'air convaincant, n'est-ce pas ? Mais ce chiffre ne dit presque rien sur la façon dont le proxy se comportera dans la réalité. La vitesse n'est qu'une facette de la qualité, et loin d'être la plus importante. Ce qui laisse tomber les gens, ce n'est souvent pas un canal lent, mais l'instabilité : le proxy répond instantanément puis se bloque pendant plusieurs secondes.

Dans ce guide, vous apprendrez à mesurer la qualité d'un proxy mobile de manière honnête et systématique. Vous maîtriserez sept métriques clés, obtiendrez des scripts prêts à l'emploi en bash et Python, découvrirez un protocole de mesure unifié et saurez interpréter correctement les résultats. À la fin, vous pourrez synthétiser les données dans un tableau et comparer objectivement deux fournisseurs.

Ce que vous obtiendrez : votre propre méthodologie de vérification, des outils prêts à l'emploi et la compréhension de quels chiffres sont alarmants. Vous cesserez de croire aux chiffres publicitaires et commencerez à vous appuyer sur vos propres mesures.

Pour qui est ce guide : pour ceux qui achètent ou utilisent déjà des proxys mobiles et veulent comprendre ce pour quoi ils paient. Il convient aux débutants car chaque étape est expliquée en détail. Il contient aussi des éléments avancés : percentiles, longs tests, interprétation des distributions.

Ce qu'il faut savoir à l'avance : il suffit de savoir ouvrir un terminal et copier des commandes. L'expérience en programmation n'est pas obligatoire. Tout ce qui est nécessaire sera expliqué au fur et à mesure.

Temps nécessaire : les mesures de base prendront environ deux à trois heures. Un test complet sur 24 heures dure bien 24 heures, mais il fonctionne en arrière-plan et ne nécessite pas votre attention constante. Pour la lecture et la configuration, prévoyez une soirée calme.

Pourquoi un seul test ne prouve rien. Le réseau mobile vit sa vie. À un moment, l'antenne est libre, à un autre elle est surchargée. Si vous faites une seule requête et qu'elle est rapide, c'est le hasard. La véritable image n'est donnée que par une série de dizaines et de centaines de mesures réparties dans le temps. C'est pourquoi nous mesurons non pas ponctuellement, mais en séries, et nous regardons non pas la moyenne, mais la distribution.

Préparation préalable : outils et protocole unifié

Avant d'appuyer sur les boutons, rassemblons notre kit de travail. Une bonne préparation garantit que vos chiffres seront comparables entre eux.

Outils nécessaires

• curl - utilitaire pour envoyer des requêtes depuis la ligne de commande. Dans la plupart des systèmes, il est déjà installé.
• Python version 3.8 ou plus récent - pour le script qui calcule les métriques et les percentiles.
• Terminal - l'invite de commande de votre système d'exploitation.
• Éditeur de texte - pour enregistrer les scripts et les notes.
• Accès au proxy - adresse, port, identifiant et mot de passe de votre proxy mobile.

Comment vérifier que tout est installé

1. Ouvrez le terminal.
2. Tapez curl --version et appuyez sur Entrée.
3. Si vous voyez un numéro de version, curl est prêt.
4. Tapez python3 --version et appuyez sur Entrée.
5. Si vous voyez quelque chose comme Python 3.11, tout va bien.

Conseil : si python3 n'est pas trouvé, téléchargez Python depuis le site officiel. Lors de l'installation sous Windows, cochez obligatoirement l'option Add Python to PATH, sinon le terminal ne verra pas la commande.

Ensemble de points de terminaison de référence

Un point de terminaison est une adresse à laquelle nous envoyons des requêtes. Il est extrêmement important de choisir des cibles réelles, similaires à celles avec lesquelles vous travaillerez. Ne testez pas le proxy uniquement sur des serveurs spéciaux de test de vitesse - ils ne reflètent pas la charge réelle.

Préparez trois ou quatre adresses différentes. Par exemple, une page de vérification d'adresse IP, une page texte légère et une ou deux ressources avec lesquelles vous prévoyez de travailler. Des cibles différentes donnent des images différentes, et c'est normal.

⚠️ Attention : n'utilisez que des ressources dont l'accès est autorisé par leurs règles et qui ne violent pas la législation. N'utilisez pas les proxys et les scripts de test pour des actions contraires à la loi ou aux conditions d'utilisation des services.

Protocole de mesure unifié

Pour que la comparaison soit équitable, fixez les conditions et ne les modifiez pas entre les tests des différents fournisseurs.

• Heure de la journée fixe. Mesurez les deux proxys dans le même intervalle horaire. Le réseau mobile se comporte différemment à midi et la nuit.
• Nombre minimal de passages. Effectuez une série d'au moins plusieurs dizaines de requêtes pour chaque métrique. Plus il y a d'échantillons, plus le résultat est fiable.
• Mêmes points de terminaison. Testez les deux proxys sur le même ensemble d'adresses.
• Paramètres de timeout identiques. Fixez une limite d'attente unique pour toutes les requêtes.
• Même ordinateur et même canal. Ne changez pas d'appareil en cours de test.

Conseil : créez un dossier séparé pour chaque fournisseur et placez-y les logs. Ainsi, vous ne mélangerez rien lors de la comparaison.

✅ Vérification : vous avez installé curl et Python, préparé une liste de points de terminaison et noté le protocole des conditions. Vous pouvez maintenant passer à la théorie.

Concepts de base en termes simples

Décortiquons les termes que vous rencontrerez à chaque étape. Comprendre ces mots, c'est la moitié de la réussite.

Latence

La latence est le temps entre l'envoi d'une requête et la réception de la réponse. Elle se mesure en millisecondes. Plus elle est faible, mieux c'est. Imaginez que vous criez dans une montagne et attendez l'écho : la latence est la pause avant le premier son.

TTFB

TTFB signifie Time To First Byte. C'est le moment où le serveur commence à envoyer la réponse. C'est la partie la plus importante de la latence car elle montre à quelle vitesse le proxy et le serveur ont réagi à votre requête, avant même le transfert du contenu principal.

Bande passante

La bande passante est la quantité de données que le proxy peut transmettre par seconde. C'est cette fameuse vitesse que l'on aime mettre en avant dans la publicité. Elle est importante, mais seulement en combinaison avec les autres métriques.

Jitter

Le jitter est la variation de la latence d'une requête à l'autre. Si une réponse arrive en 100 millisecondes, la suivante en 105 et la troisième en 98, le jitter est faible et c'est bon. Si les valeurs oscillent entre 80 et 900, le jitter est énorme et le travail sera saccadé.

Taux de réponses réussies

C'est le pourcentage de requêtes terminées avec succès, sans erreur ni interruption. Cette métrique montre la fiabilité. Un proxy peut être rapide, mais si une requête sur dix échoue, son utilisation est pénible.

Percentiles p50, p95 et p99

C'est une manière de décrire la distribution des valeurs. Le percentile p50 est la médiane : la moitié des requêtes sont plus rapides que cette valeur, l'autre moitié plus lentes. Le p95 indique que 95 % des requêtes se sont situées dans ce temps, et 5 % ont été moins bonnes. Le p99 montre le comportement des cas les plus lents.

Conseil : retenez la règle principale. La moyenne trompe, les percentiles disent la vérité. Si vous avez neuf réponses rapides et une bloquée pendant dix secondes, la moyenne semble acceptable, mais le p99 révèle immédiatement le problème.

Ce qui différencie lent d'instable

Un proxy lent donne constamment des valeurs de latence élevées. C'est prévisible. Un proxy instable donne tantôt d'excellents résultats, tantôt de mauvais. Souvent, l'instabilité est plus nuisible qu'une lenteur constante, car elle est imprévisible.

✅ Vérification : vous comprenez ce que sont la latence, le TTFB, la bande passante, le jitter, le taux de réponses réussies et les percentiles. Parfait, passons à la pratique.

Étape 1 : mesurer la disponibilité et le taux de réponses réussies

Objectif de cette étape : savoir à quel point le proxy est fiable pour répondre aux requêtes et comprendre quelles erreurs se produisent.

Ce que nous faisons

Nous allons envoyer une série de plusieurs dizaines de requêtes identiques et compter combien d'entre elles se sont terminées avec succès. En parallèle, nous collecterons les erreurs par type : timeouts, interruptions de connexion, réponses avec codes d'erreur.

Instructions pas à pas

1. Ouvrez le terminal.
2. Préparez la chaîne d'accès au proxy au format identifiant, mot de passe, adresse et port.
3. Exécutez une série de requêtes avec une simple boucle, où la commande curl envoie une requête à votre point de terminaison via le proxy.
4. Pour chaque requête, enregistrez le code de réponse et le fait qu'elle soit réussie ou non.
5. Après la série, calculez le pourcentage de réponses réussies.

La commande de base pour une requête ressemble à ceci : curl avec le drapeau proxy, le drapeau timeout et l'adresse. Le drapeau --max-time limite le temps d'attente pour qu'une requête bloquée n'arrête pas toute la série.

Comment interpréter le résultat

Divisez les réponses en groupes. Les réussites sont les réponses avec des codes normaux. Comptez séparément les timeouts (le serveur n'a pas répondu à temps), les interruptions de connexion et les réponses avec des codes d'erreur serveur.

Attention : la répartition des erreurs est plus importante que leur nombre total. Si tous les échecs sont des timeouts, le problème vient de la vitesse ou de la surcharge du réseau. S'il s'agit d'interruptions de connexion, le proxy est peut-être instable au niveau du canal mobile.

Conseil : ne tirez pas de conclusions sur cinq requêtes. Une série minimale significative est de plusieurs dizaines. Pour une décision importante, prenez des centaines.

Problèmes possibles

• Toutes les requêtes échouent. Vérifiez l'exactitude de l'identifiant, du mot de passe, de l'adresse et du port. Une seule faute de frappe casse tout.
• Certaines requêtes se bloquent indéfiniment. Utilisez impérativement une limite de temps, sinon la série ne se terminera pas.
• Les codes d'erreur serveur varient. Il est possible que la ressource cible elle-même soit instable. Essayez un autre point de terminaison pour contrôle.

✅ Vérification : vous avez le nombre de réponses réussies, le nombre d'erreurs de chaque type et la compréhension de là où le proxy trébuche.

Étape 2 : mesurer la latence et le TTFB via les percentiles

Objectif de cette étape : obtenir une image honnête de la latence en se basant sur la distribution, et non sur la moyenne trompeuse.

Pourquoi la moyenne induit en erreur

Supposons que vous ayez dix requêtes. Neuf arrivent en cent millisecondes, une est bloquée cinq secondes. La moyenne montrera environ six cents millisecondes, et ce sera un mensonge dans les deux sens. En réalité, le proxy est presque toujours rapide, mais parfois catastrophiquement lent. Les percentiles montrent cela honnêtement.

Format de sortie de curl avec le drapeau -w

L'utilitaire curl peut fournir une répartition temporelle détaillée. Le drapeau -w permet de demander des indicateurs spécifiques. Les variables les plus utiles pour nous : time_starttransfer - c'est en fait le TTFB, le temps jusqu'au premier octet. Il y a aussi time_connect - le temps d'établissement de la connexion, et time_total - le temps total de la requête.

1. Composez la commande curl avec le drapeau -o pour rediriger le corps de la réponse vers /dev/null afin qu'il ne gêne pas.
2. Ajoutez le drapeau -s pour supprimer l'indicateur de progression.
3. Ajoutez le drapeau -w avec les variables de temps souhaitées.
4. Exécutez la commande en boucle le nombre de fois nécessaire via votre proxy.
5. Enregistrez toutes les valeurs TTFB dans un fichier, une valeur par ligne.

Comment calculer les percentiles

Triez les nombres collectés par ordre croissant. La valeur à la position médiane de la liste est le p50. La valeur à la position 95 % de la longueur de la liste est le p95. La valeur à la position 99 % est le p99. Dans le script Python à la fin du guide, cela se fait automatiquement.

Conseil : regardez toujours le couple p50 et p95 ensemble. S'ils sont proches, le proxy est stable. S'il y a un gouffre entre eux, le proxy a des rares mais douloureuses chutes.

Problèmes possibles

• Les valeurs TTFB sont suspectes petites. Peut-être que le cache a fonctionné. Désactivez la réutilisation de la connexion avec le drapeau qui désactive keep-alive et ajoutez un paramètre unique à l'adresse.
• Les valeurs varient fortement entre les exécutions. C'est normal pour un réseau mobile. C'est pourquoi nous faisons des séries et non des mesures ponctuelles.

✅ Vérification : vous avez un fichier avec les valeurs TTFB et trois chiffres de percentiles qui décrivent le comportement réel de la latence.

Étape 3 : mesurer honnêtement la bande passante

Objectif de cette étape : connaître la vitesse réelle de transfert des données sans auto-illusion.

Comment mesurer honnêtement

Téléchargez via le proxy un fichier de taille connue et mesurez combien de temps cela a pris. Divisez la taille par le temps pour obtenir la vitesse. Cela semble simple, mais il y a des nuances faciles à négliger.

1. Choisissez plusieurs fichiers de différentes tailles sur des ressources réelles.
2. Téléchargez chacun via le proxy avec curl, en mesurant le temps avec le drapeau -w avec la variable time_total et la variable size_download.
3. Répétez le téléchargement plusieurs fois pour chaque fichier.
4. Calculez la vitesse pour chaque passage et regardez la distribution.

Pourquoi plusieurs fichiers et points de terminaison

Un fichier provenant d'un seul serveur peut être limité par la capacité de ce serveur, et non par votre proxy. Différentes sources donnent des images différentes. Si la vitesse est également faible sur toutes les sources, le problème vient du proxy. Si elle varie, le goulot d'étranglement peut se situer sur un serveur spécifique.

Influence des limites du forfait

De nombreux forfaits mobiles ont des limites de vitesse ou de volume de données. Après un certain seuil, la vitesse peut chuter brusquement. Tenez-en compte : si vous avez téléchargé beaucoup de données d'affilée, le ralentissement peut être dû au forfait et non à la qualité du proxy.

⚠️ Attention : ne téléchargez pas des volumes gigantesques de données juste pour un test si votre forfait est limité. Vous risquez d'épuiser votre enveloppe de données. Utilisez des fichiers de taille modérée.

Conseil : mesurez la bande passante à la même heure de la journée que les autres métriques. La charge du réseau influence fortement le résultat.

Problèmes possibles

• La vitesse est instable. C'est typique des réseaux mobiles. Regardez la médiane de la vitesse, pas un résultat unique et excellent.
• La vitesse chute brusquement en cours de test. Peut-être que la limite du forfait a été atteinte ou que le mode réseau a changé.

✅ Vérification : vous avez des valeurs de vitesse sur plusieurs sources et la compréhension de l'endroit où se trouve le goulot d'étranglement.

Étape 4 : mesurer le jitter et la stabilité

Objectif de cette étape : comprendre à quel point le proxy fonctionne de manière régulière, et pas seulement rapidement.

Ce que nous faisons

Nous reprenons la série de mesures de latence des étapes précédentes et examinons la dispersion. Le jitter est essentiellement une mesure de l'écart entre les valeurs voisines.

1. Prenez le fichier avec les valeurs de latence collectées à l'étape 2.
2. Calculez la différence entre chaque mesure consécutive.
3. Faites la moyenne des valeurs absolues de ces différences - ce sera une estimation du jitter.
4. En complément, regardez l'écart type de toute la série.

Qu'est-ce qui est normal

Il n'existe pas de chiffres universels précis, car la norme dépend de la tâche. Le principe général est le suivant : plus le jitter est faible par rapport à la latence elle-même, mieux c'est. Si la latence est de cent millisecondes et le jitter de cinq, c'est excellent. Si le jitter est comparable à la latence, le travail sera saccadé.

Conseil : visualisez la série de mesures avec un simple graphique. Une ligne droite est un bon signe. Une scie avec des dents acérées est alarmante.

Dispersion des valeurs

Faites attention aux valeurs aberrantes rares. Un pic isolé une fois toutes les cent requêtes peut être tolérable. Des pics réguliers signifient que le proxy est plus sensible aux fluctuations du réseau mobile que la normale.

✅ Vérification : vous avez une estimation du jitter et la compréhension de si le proxy est stable ou saccadé.

Étape 5 : vérifier le comportement lors du changement d'IP

Objectif de cette étape : comprendre à quelle vitesse et avec quelle qualité le proxy change d'adresse IP.

Ce que nous mesurons

Les proxys mobiles peuvent changer d'adresse IP sur demande ou selon un planning. Nous nous intéressons à plusieurs choses : combien de temps prend le changement, si la nouvelle adresse reste dans le même réseau et la même ville, et combien d'adresses uniques sont obtenues en une heure.

1. Demandez l'adresse IP actuelle via un point de terminaison de vérification d'IP.
2. Déclenchez le changement d'IP selon la méthode fournie par votre prestataire.
3. Mesurez le temps jusqu'à ce que la nouvelle adresse soit disponible.
4. Demandez à nouveau l'IP et enregistrez-la.
5. Répétez ce cycle plusieurs fois pendant une heure.
6. Calculez le nombre d'adresses uniques et le temps de chaque changement.

Comment évaluer le résultat

Examinez plusieurs paramètres. La vitesse du changement montre à quelle vitesse vous obtenez une nouvelle adresse. Le nombre d'adresses uniques par heure indique la diversité du pool. L'appartenance au même réseau et à la même ville confirme que vous restez dans le segment attendu.

Conseil : enregistrez non seulement l'adresse elle-même, mais aussi les données sur son réseau et sa ville renvoyées par le point de terminaison de vérification. Ainsi, vous verrez si la géographie est stable lors du changement.

⚠️ Attention : n'utilisez le changement d'IP qu'à des fins légales et dans le respect des règles des services avec lesquels vous travaillez. Les capacités techniques du proxy n'annulent pas les exigences légales et les conditions d'utilisation.

Problèmes possibles

• Le changement prend trop de temps. Vérifiez que vous utilisez la bonne méthode. Renseignez-vous auprès du fournisseur sur la méthode standard.
• Les adresses se répètent. Une légère répétition est possible, mais des doublons constants indiquent un petit pool.

✅ Vérification : vous avez le temps de changement, le nombre d'adresses uniques par heure et des données sur leur géographie.

Étape 6 : vérifier la conformité de la géographie et du type de connexion

Objectif de cette étape : s'assurer que le proxy correspond vraiment aux caractéristiques annoncées.

Ce que nous vérifions

Le fournisseur indique généralement le pays, la région et le type de connexion, par exemple réseau mobile. Notre tâche est de comparer ce qui est annoncé avec la réalité.

1. Connectez-vous via le proxy à un point de terminaison qui renvoie des données sur votre adresse.
2. Enregistrez le pays et la région identifiés.
3. Enregistrez le type de connexion déterminé par le service.
4. Répétez la vérification plusieurs fois avec des adresses IP différentes.
5. Comparez les résultats avec ce que le fournisseur a promis.

Comment interpréter le résultat

Si la géographie et le type de connexion correspondent systématiquement aux annonces, c'est parfait. Si d'autres régions apparaissent périodiquement ou si le type de connexion ne correspond pas, c'est une raison de poser des questions au fournisseur.

Conseil : vérifiez la géographie via plusieurs sources indépendantes de géolocalisation. Les bases de données sur l'attribution des adresses divergent parfois, et une seule source peut se tromper.

✅ Vérification : vous avez confirmé ou infirmé la conformité de la géographie et du type de connexion avec les annonces.

Étape 7 : lancer un long test sur 24 heures

Objectif de cette étape : voir ce qui est impossible à remarquer en cinq minutes.

Pourquoi un test sur 24 heures

Un test court capture uniquement l'état actuel du réseau. Un test sur 24 heures montre le comportement du proxy à différents moments : le matin, à l'heure de pointe du déjeuner, la nuit. Vous verrez comment la latence, le taux de réponses réussies et la stabilité évoluent au cours de la journée.

1. Configurez un script pour des mesures périodiques, par exemple toutes les quelques minutes.
2. Exécutez-le en arrière-plan et laissez-le fonctionner pendant 24 heures.
3. Assurez-vous que les résultats sont écrits dans un fichier avec une horodatage.
4. Au bout de 24 heures, collectez les données et dressez un tableau heure par heure.

Ce que montre un long test

Vous verrez des baisses aux heures de pointe lorsque le réseau mobile est surchargé. Vous remarquerez des fenêtres de stabilité la nuit. Vous détecterez des pics d'erreurs rares qui n'auraient pas eu le temps d'apparaître en cinq minutes. C'est le test sur 24 heures qui distingue un bon proxy d'un médiocre.

⚠️ Attention : surveillez la consommation de données lors d'un test sur 24 heures. Faites des requêtes légères pour ne pas épuiser la limite de votre forfait en une journée de fonctionnement continu.

Conseil : ne lancez pas un test sur 24 heures sur un ordinateur qui pourrait passer en mode veille. Désactivez la mise en veille, sinon les mesures seront interrompues.

✅ Vérification : vous avez un journal de 24 heures avec des horodatages qui montre le comportement du proxy en dynamique.

Scripts prêts à l'emploi pour les mesures

Voici des squelettes qui calculent les métriques décrites. Adaptez-les à vos données d'accès et points de terminaison.

Script en bash

Ce script effectue une série de requêtes, collecte le TTFB et les codes de réponse, et les enregistre dans un fichier. La logique est la suivante : dans une boucle, curl est exécuté via le proxy, le drapeau -w affiche le temps jusqu'au premier octet et le code de réponse, et le résultat est ajouté au log.

Les éléments principaux du script : une variable avec l'adresse du proxy au format protocole, identifiant, mot de passe, adresse et port. Une variable avec le point de terminaison cible. Une boucle avec un nombre de répétitions défini. À l'intérieur de la boucle, un appel curl avec les drapeaux -s pour le silence, -o pour jeter le corps, --max-time pour limiter l'attente et -w avec les variables time_starttransfer et http_code. Chaque ligne de résultat est ajoutée à un fichier texte. Après la boucle, bash peut calculer une statistique simple ou passer le fichier à Python.

Pour désactiver le cache, ajoutez un paramètre de requête unique à l'adresse et utilisez le drapeau qui désactive la réutilisation de la connexion. Cela garantit que chaque mesure est honnête et non prise en mémoire.

Script en Python

Le script Python est plus pratique pour calculer les percentiles et le jitter. Il lit le fichier avec les valeurs ou effectue lui-même les requêtes via une bibliothèque HTTP supportant les proxys.

La logique du script est la suivante. D'abord, on définit les paramètres : adresse du proxy, liste de points de terminaison, nombre de répétitions et timeout. Ensuite, dans une boucle, on exécute les requêtes, pour chacune on enregistre le temps jusqu'au premier octet, le temps total et le code de réponse. Les réponses réussies et échouées sont comptées séparément. Toutes les valeurs de latence sont ajoutées à une liste.

Après la collecte des données, le script trie la liste des latences et calcule les percentiles. La médiane est prise au milieu de la liste triée. Le percentile p95 est à la position 95 % de la longueur. Le percentile p99 est à la position 99 %. Le jitter est calculé comme la moyenne des valeurs absolues des différences entre mesures consécutives. Le taux de réponses réussies est le nombre de succès divisé par le nombre total de requêtes.

À la fin, le script affiche un rapport final : taux de réponses réussies, percentiles de latence, estimation du jitter et répartition des erreurs par type. Pour un test sur 24 heures, ajoutez un horodatage à chaque entrée et encapsulez les mesures dans une boucle avec une pause entre les séries.

Conseil : conservez les données brutes, pas seulement les chiffres finaux. Si vous devez recalculer une métrique différemment plus tard, vous aurez les sources.

⚠️ Attention : stockez l'identifiant et le mot de passe du proxy dans un fichier de configuration séparé, pas directement dans le script que vous pourriez montrer accidentellement à quelqu'un.

Comment synthétiser les résultats dans un tableau

Une fois les données collectées, il est important de les présenter de manière visuelle. Un tableau unique permet de comparer honnêtement les fournisseurs.

Structure du tableau final

Créez un tableau où les lignes sont les métriques et les colonnes sont les fournisseurs. Pour chaque métrique, indiquez la valeur et, le cas échéant, les percentiles. Ainsi, vous verrez immédiatement qui est meilleur dans quoi.

• Taux de réponses réussies - pourcentage pour chaque fournisseur.
• TTFB - trois chiffres : p50, p95, p99.
• Bande passante - médiane de la vitesse.
• Jitter - estimation de la dispersion.
• Changement d'IP - temps de changement et nombre d'adresses uniques par heure.
• Géographie et type de connexion - correspond ou non à l'annonce.
• Comportement sur 24 heures - y a-t-il des baisses aux heures de pointe.

Tableau d'interprétation des métriques

Voici un tableau verbal de type métrique, comment elle est mesurée, ce qu'une mauvaise valeur signifie. Nous n'inventons pas de chiffres précis - les normes dépendent de la tâche.

• Taux de réponses réussies. Mesuré par une série de requêtes et le comptage des succès. Mauvaise valeur : une proportion notable d'erreurs, surtout des interruptions, ce qui signifie un manque de fiabilité.
• TTFB et percentiles. Mesuré via curl avec la variable de temps jusqu'au premier octet sur une grande série. Mauvaise valeur : un écart énorme entre p50 et p99, ce qui signifie des chutes rares mais douloureuses.
• Bande passante. Mesurée en téléchargeant des fichiers de taille connue. Mauvaise valeur : une vitesse qui ne couvre pas vos besoins ou qui chute brusquement.
• Jitter. Mesuré comme la dispersion des latences consécutives. Mauvaise valeur : un jitter comparable à la latence elle-même, ce qui signifie un travail saccadé.
• Changement d'IP. Mesuré par un cycle de changements avec mesure du temps. Mauvaise valeur : changement long et peu d'adresses uniques.
• Géographie et type de connexion. Mesuré par recoupement avec un point de terminaison de géolocalisation. Mauvaise valeur : non-conformité avec l'annonce.
• Stabilité sur 24 heures. Mesurée par un long test. Mauvaise valeur : fortes baisses des métriques aux heures de pointe.

Conseil : lors de la comparaison, ne tirez pas de conclusion sur une seule ligne. Pesez les métriques selon leur importance pour votre tâche. Pour certains, la stabilité est cruciale, pour d'autres, la vitesse de changement d'adresse.

Vérification du résultat : checklist de qualité de la mesure

Avant de faire confiance à vos chiffres, parcourez cette liste. Elle garantit que les mesures sont correctes.

• Chaque métrique a été mesurée en série, pas par une seule requête.
• Les deux fournisseurs ont été testés à la même heure de la journée.
• Les mêmes points de terminaison et timeouts ont été utilisés.
• Pour la latence, les percentiles ont été calculés, pas seulement la moyenne.
• Le cache et la réutilisation de la connexion ont été désactivés là où c'est important.
• Les tests ont été effectués sur des cibles réelles, pas seulement sur des serveurs de test de vitesse.
• Au moins un test sur 24 heures a été réalisé.
• Les données brutes sont conservées en cas de recalcul.

✅ Vérification : si tous les points sont cochés, vos résultats peuvent être considérés comme une base fiable pour une décision.

Erreurs typiques de mesure et leurs solutions

Voici les erreurs les plus courantes. Chacune est décrite comme un problème, une cause et une solution.

Erreur un : un seul passage

Problème : conclusion basée sur une ou deux requêtes. Cause : envie d'obtenir un chiffre rapidement. Solution : faites toujours une série de dizaines ou de centaines de requêtes et regardez la distribution.

Erreur deux : test uniquement à l'heure de pointe

Problème : les résultats semblent horribles ou au contraire parfaits. Cause : mesure effectuée à un moment de charge maximale ou minimale du réseau. Solution : mesurez à différents moments et effectuez impérativement un test sur 24 heures.

Erreur trois : mesure vers des serveurs de test de vitesse

Problème : les chiffres sont beaux, mais dans la réalité c'est différent. Cause : les serveurs spéciaux de test de vitesse ne reflètent pas les cibles réelles. Solution : testez sur les ressources avec lesquelles vous travaillerez.

Erreur quatre : ignorance du cache

Problème : la latence est suspecte faible et stable. Cause : les réponses proviennent du cache, pas du réseau. Solution : ajoutez un paramètre unique à l'adresse et interdisez la mise en cache.

Erreur cinq : keep-alive fausse l'image

Problème : la première requête est lente, les suivantes instantanées. Cause : la connexion est réutilisée et les mesures suivantes n'incluent pas l'établissement de la connexion. Solution : pour une mesure honnête, désactivez la réutilisation de la connexion si vous voulez voir la latence complète.

Erreur six : comparer la moyenne au lieu des percentiles

Problème : deux proxys semblent identiques en moyenne, mais en pratique l'un est nettement moins bon. Cause : la moyenne cache les baisses. Solution : comparez p95 et p99.

Erreur sept : conditions différentes pour différents fournisseurs

Problème : la comparaison est injuste. Cause : un proxy testé le jour sur un point de terminaison, l'autre la nuit sur un autre. Solution : respectez strictement le protocole unique.

Possibilités supplémentaires et optimisation

Une fois la méthodologie de base maîtrisée, vous pouvez approfondir.

Automatisation des vérifications régulières

Configurez le script pour qu'il s'exécute selon un planning, par exemple quotidiennement. Ainsi, vous verrez si le proxy se dégrade avec le temps. Accumulez l'historique et construisez une tendance.

Mesures parallèles

Les utilisateurs avancés peuvent lancer plusieurs threads simultanément pour évaluer le comportement sous charge. Faites-le avec prudence et dans le respect des règles du fournisseur.

Visualisation des données

Construisez des graphiques à partir des données collectées. Un graphique de la latence en fonction de l'heure de la journée montre clairement les heures de pointe. Un histogramme de la distribution de la latence montre s'il y a une longue traîne de réponses lentes.

Conseil : même un simple graphique dans un tableur rend les conclusions bien plus convaincantes qu'une colonne de chiffres.

Segmentation par point de terminaison

Calculez les métriques séparément pour chaque point de terminaison. Parfois, le proxy fonctionne parfaitement avec certaines cibles et moins bien avec d'autres. Ce détail aide à prendre des décisions ciblées.

FAQ : questions fréquentes sur la mesure de la qualité des proxys

Combien de requêtes sont nécessaires pour un résultat fiable ?

Le plus possible, mieux c'est. Une série minimale significative est de plusieurs dizaines. Pour une décision importante, prenez des centaines de requêtes et impérativement un test sur 24 heures.

Pourquoi ne pas faire confiance au chiffre publicitaire de vitesse ?

Parce que la vitesse n'est qu'une métrique parmi sept. Un proxy peut être rapide mais instable, avec une mauvaise disponibilité ou un changement d'IP lent. La publicité montre le meilleur cas, pas le cas typique.

Qu'est-ce qui est plus important : la latence ou la bande passante ?

Cela dépend de la tâche. Pour des requêtes légères et rapides, la latence et la stabilité sont plus importantes. Pour le transfert de gros volumes, la bande passante est plus importante. Regardez l'ensemble des métriques.

Pourquoi la valeur moyenne de latence est-elle trompeuse ?

Parce que de rares valeurs énormes gonflent la moyenne, et de rares valeurs très petites la diminuent. Les percentiles p50, p95 et p99 décrivent honnêtement la distribution et montrent le comportement des pires cas.

Comment savoir si un proxy est instable plutôt que simplement lent ?

Regardez le jitter et l'écart entre les percentiles. Un proxy lent donne des valeurs constamment élevées mais régulières. Un proxy instable passe d'excellentes à horribles.

Faut-il obligatoirement désactiver le cache lors des mesures ?

Pour une mesure honnête de la latence, oui. Sinon, vous mesurez la vitesse de la mémoire, pas du réseau. Ajoutez un paramètre unique à l'adresse et interdisez la réutilisation de la connexion.

Pourquoi un test sur 24 heures est-il nécessaire si un test de cinq minutes a déjà montré quelque chose ?

Un test de cinq minutes capture un instant. Un test sur 24 heures montre le comportement aux heures de pointe, la nuit et le matin, et détecte les pics d'erreurs rares. Lui seul distingue un proxy fiable d'un coup de chance.

Peut-on comparer deux fournisseurs en les testant à des moments différents ?

Non. Le réseau change au cours de la journée, et la comparaison deviendrait injuste. Testez les deux dans le même intervalle de temps selon un protocole unique.

Que faire si les résultats varient fortement d'une exécution à l'autre ?

C'est normal pour les réseaux mobiles. C'est pourquoi nous nous appuyons sur des séries et des percentiles, et non sur des mesures ponctuelles. Augmentez le nombre d'échantillons.

Faut-il tester le changement d'IP si je ne prévois pas de l'utiliser ?

Si cette fonction n'est pas importante pour vous, vous pouvez sauter cette étape. Mais la mesurer rapidement est utile pour la compréhension générale de la qualité du pool d'adresses.

Conclusion : des chiffres publicitaires à vos propres mesures

Vous avez parcouru le chemin depuis la croyance naïve en un seul chiffre de vitesse jusqu'à une méthodologie systématique d'évaluation de la qualité. Vous disposez maintenant de sept métriques, d'un protocole unique, de scripts prêts à l'emploi et de la compréhension de comment interpréter les résultats.

Ce que vous avez appris. Vous avez appris à mesurer le taux de réponses réussies, la latence via les percentiles, la bande passante, le jitter, le comportement lors du changement d'IP, la conformité géographique et la stabilité sur 24 heures. Vous savez pourquoi la moyenne trompe et pourquoi un seul passage ne prouve rien.

Que faire ensuite. Appliquez la méthodologie à votre proxy actuel et notez les chiffres de base. Testez ensuite un autre fournisseur selon le même protocole et comparez dans un tableau unique. La décision deviendra évidente.

Où aller plus loin. Automatisez les vérifications régulières, accumulez l'historique et construisez des graphiques. Avec le temps, vous remarquerez la dégradation avant qu'elle n'affecte votre travail. Rappelez-vous l'essentiel : ne faites pas confiance à la publicité, mais à vos propres mesures, effectuées honnêtement et systématiquement. C'est ce qui distingue un utilisateur confiant de celui qui paye à l'aveugle.