Proxy Ask.com : estimation de localisation, personnalisation et protocole de mesure

Quel usage correspond à quel point de sortie ?

Partir de l'usage pour décider du type de point de sortie est plus juste que de partir du produit. Les surfaces de recherche n'exigeant pas de connexion, il reste trois variables déterminantes : le volume, le besoin de comparaison et le caractère régional de ce que l'on vérifie. Une fois ces trois points clarifiés, le type s'impose de lui-même.

Pour un usage qui consulte ponctuellement des pages de résultats ouvertes, un point de sortie datacenter est à la fois rapide et économique. Pour valider une surface fortement régionale comme le bloc d'entreprises locales, un point de sortie proche d'un profil d'abonné résidentiel offre une vue plus représentative. Dans une série de suivi qui s'étend sur plusieurs semaines, la propriété la plus précieuse est la stabilité de l'adresse, car la valeur de la comparaison vient du faible nombre de variables.

Les points de sortie mobiles occupent une place particulière dans ce tableau. Si vous mesurez l'interface desktop, un pool mobile est un coût inutile ; si vous testez spécifiquement la disposition des blocs de l'interface mobile, c'est un choix pertinent. Pour situer les différents types dans la couche réseau et comparer leurs coûts, la comparaison entre residential et datacenter est un bon point de départ ; quant à la place des pools ISP dans ce tableau, évaluez-la selon le nombre de semaines sur lesquelles s'étend votre besoin d'adresse fixe.

Un rappel : le choix du type n'est pas la seule entrée qui influence la façon dont la requête est classifiée. Le système autonome auquel appartient l'adresse et l'historique de cette adresse entrent aussi en jeu ; dans un pool partagé, l'usage qui en a été fait avant vous peut se répercuter sur votre mesure. N'attribuez donc pas systématiquement un écran de vérification inattendu à votre propre rythme ; l'historique de l'adresse peut produire le même résultat.

Séparer la personnalisation de l'état de session

Une mesure comporte deux variables indépendantes : l'endroit depuis lequel vous vous connectez et ce que votre navigateur mémorise. La seconde est le plus souvent négligée. Les interfaces de recherche conservent dans des cookies des préférences comme la région, la langue ou la recherche sécurisée ; même si vous changez de pays, l'ancienne préférence peut subsister et façonner le résultat indépendamment du point de sortie.

La façon de séparer les deux est de partir d'une base propre. Ouvrez chaque tour de mesure avec un profil sans préférences accumulées, exécutez une seule requête, enregistrez la sortie et réinitialisez le profil. Si vous exécutez vingt requêtes à la suite avec le même profil, le résultat de la vingtième sera produit dans un contexte différent de celui de la première. Cet écart peut être minime, mais il compromet la fiabilité de la comparaison.

Vous pouvez aussi aborder la relation entre session et point de sortie dans l'autre sens : accumulez délibérément des préférences et exécutez la même requête depuis le même point de sortie avec deux profils différents. L'écart relève entièrement de l'état de session, puisque le point de sortie est fixe. Ce protocole simple répond en un seul tour à la question « ce changement vient-il de la personnalisation ? ».

• Tenez un profil distinct pour chaque pays ; les cookies ne doivent pas circuler d'un pays à l'autre.
• Limitez le tour de mesure non par le nombre de requêtes, mais par la durée de vie du profil.
• Notez à chaque tour le réglage de région et de recherche sécurisée de l'interface.
• N'utilisez pas simultanément un VPN et un proxy ; deux couches rendent le diagnostic impossible.
• Conservez les résultats sous forme de liste de liens plutôt que de captures d'écran.

Saisie sous forme de question, encadré de réponse et comportement des opérateurs

La méthode générale pour tester si les opérateurs fonctionnent est la même sur cette surface et repose sur l'exécution de la même requête avec et sans opérateur ; la mise en place pas à pas de la méthode est expliquée dans la section opérateurs de la page AOL Search . Ici, l'enjeu est autre : cette interface classe la saisie selon sa forme, et ce classement est le premier seuil qui détermine si l'opérateur sera pris en compte ou non.

Une question rédigée en langage naturel et la version « empilement de mots-clés » du même sujet peuvent produire sur cette page des dispositions de blocs différentes. Une saisie sous forme de question tend à ouvrir un encadré de réponse en haut de page ; un empilement de mots-clés mène directement à la liste de liens, l'encadré supérieur n'apparaissant pas du tout ou sous une forme plus réduite. Exécuter les deux formes à la suite depuis le même point de sortie et noter l'ordre des blocs montre en quelques minutes dans quelle famille l'interface range votre requête.

Lorsque l'encadré de réponse s'ouvre, le comportement de l'opérateur change également. L'encadré est conçu pour répondre, non pour restreindre la requête ; c'est pourquoi des signes comme les guillemets ou l'exclusion peuvent ne pas se refléter dans son contenu. Que la liste de liens en dessous respecte l'opérateur alors que l'encadré supérieur ne le fait pas n'est pas une contradiction, mais la conséquence naturelle de deux chaînes de production distinctes. Dans votre tableau de mesure, gardez l'encadré et la liste sur des lignes séparées ; sinon, ce que vous consignez comme « l'opérateur n'a pas fonctionné » est en réalité le comportement de l'encadré.

Mesurez donc les deux familles de requêtes dans des tours distincts. Menez le test d'opérateurs uniquement avec des requêtes de type mots-clés, et le comportement en langage naturel avec des questions sans opérateur ; si vous mélangez les deux dans le même tour, vous ne pourrez pas isoler la variable qui fait bouger le résultat. Noter au début de chaque tour la famille avec laquelle vous travaillez est le seul moyen de pouvoir relire le tableau deux semaines plus tard.

Protocole, configuration et contrôle des fuites

Dans une mesure effectuée depuis un navigateur, la différence entre un proxy HTTP et SOCKS5 passe le plus souvent inaperçue ; les deux font le travail. La distinction commence hors du navigateur : le proxy HTTP se situe dans la couche applicative et ouvre un tunnel CONNECT pour HTTPS, tandis que SOCKS5 reste dans la couche transport et n'interprète pas les données qu'il transporte. Si vous écrivez votre propre client, choisissez selon ce qu'il prend en charge ; le guide de choix de protocole distingue cette décision selon le type d'outil et la charge de travail.

Effectuer la configuration non pas à l'échelle du système mais dans un profil de navigateur dédié est presque toujours préférable pour des travaux de mesure, et cela pour trois raisons distinctes. La première est la séparation : votre trafic quotidien ne se mêle pas au trafic de mesure, et tout, de la banque en ligne au streaming vidéo, continue d'emprunter sa propre route. La deuxième est la réinitialisation ; supprimer un profil efface en une seule opération les cookies, le cache et les préférences de site, alors qu'une définition au niveau du système laisse subsister l'état du navigateur. La troisième est la clarté du périmètre : sachant dans quel profil vous avez défini le proxy, la question de savoir quelle requête passe par le proxy ne prête pas à discussion. Firefox conservant la définition du proxy dans ses propres paramètres de connexion, il est facile d'isoler le profil de mesure ; côté Windows, en revanche, une définition au niveau système affecte toutes les applications à la fois et achemine aussi votre trafic quotidien vers le même point de sortie.

Après la configuration, répondez en particulier à une question sur cette page : de quel côté la résolution du nom de domaine est-elle effectuée ? Si le client résout le nom sur son propre réseau et ne transmet qu'une IP au proxy, votre cible apparaît sur le serveur DNS de votre fournisseur d'accès ; de plus, un endpoint géographiquement proche de vous est retourné alors que la connexion est établie depuis le pays du proxy, et les blocs locaux se comportent comme un mélange de deux régions. C'est la cause la plus fréquente des situations interprétées après coup comme « le point de sortie ne fonctionne pas ». Test de DNS leak répond directement à la question ; si vous souhaitez que la résolution soit effectuée côté proxy, activez l'option de DNS distant dans votre client — côté SOCKS5, ce réglage s'appelle généralement résolution de nom à distance.

Incidents typiques et question des coûts

L'incident le plus fréquent lors des tours de mesure est le changement silencieux du point de sortie. Si le pool est rotatif ou si la durée sticky est plus courte que votre tour de travail, vous effectuerez la seconde moitié depuis une autre adresse sans vous en apercevoir. Choisissez une fenêtre sticky plus longue que le tour et notez l'adresse au début et à la fin du tour ; si vous ignorez la durée de la fenêtre, travailler par tours courts vaut toujours mieux que de rapporter un long tour coupé en deux.

Le deuxième cas fréquent est la réponse 407 : soit les identifiants ne sont pas envoyés, soit le fournisseur vous reconnaît par autorisation d'IP et votre propre adresse a changé. Sur une ligne à IP dynamique, la méthode par whitelist se rompt à chaque reconnexion ; pour les utilisateurs nomades, le couple nom d'utilisateur–mot de passe est plus pratique. Le troisième cas concerne les écrans de vérification qui apparaissent quand le rythme augmente : lorsque vous rencontrez cet écran, ralentissez, espacez le plan de mesure et ne cherchez pas à le contourner.

Côté coûts, les pages de recherche constituent une surface confortable ; les données transférées sont majoritairement du texte. Cela dit, si vous travaillez avec de l'automatisation de navigateur, l'ensemble des ressources de la page est téléchargé et, sur des centaines de requêtes, le total grimpe vite. Mesurez une fois le coût d'une page et multipliez-le par le nombre de requêtes prévues ; désactiver le chargement des ressources graphiques et des scripts dans l'automatisation réduit sensiblement ce total.

Il faut poser les bonnes attentes en matière de latence : un relais supplémentaire étant intercalé, le proxy augmente la latence dans la plupart des configurations, il ne la réduit pas. Planifiez vos tours de mesure en conséquence ; si vous avez un objectif de temps de chargement, prenez la référence non pas sur le tour sans proxy, mais sur le tour avec proxy. Lors du choix du point de sortie, opter pour une localisation relativement proche de la cible et de vous évite un aller-retour intercontinental inutile ; même la latence de deux points de sortie situés dans le même pays peut différer sensiblement.