Sessions persistantes

Une session persistante demande à un service de proxys de conserver une même IP de sortie pour des requêtes liées. Votre application peut ouvrir des pages, envoyer des données et recevoir un résultat par cette adresse tant que l’attribution reste valide et que la sortie reste disponible. Une fois la tâche terminée, votre application peut démarrer une session distincte pour la suivante.

Il s’agit généralement d’un mode d’accès à un pool rotatif. La comparaison plus générale est traitée dans Proxys statiques ou rotatifs. Ici, il s’agit de comprendre comment conserver une adresse pour une tâche, combien de temps cette attribution dure et ce qui peut l’interrompre.

Comment le service conserve l’IP sélectionnée

Le service doit reconnaître les connexions qui appartiennent à la même tâche. Une méthode courante utilise un identifiant de session dans les paramètres du proxy. À la première connexion, le service choisit une sortie et l’associe à cet identifiant. Les connexions ultérieures avec les mêmes paramètres de session utilisent la sortie attribuée tant que la session reste active.

Par exemple, un test dans un navigateur utilise le nom de session task1. Sa première connexion reçoit l’IP de sortie d’exemple 198.51.100.27. L’ouverture de la page suivante et l’envoi d’un formulaire avec la même attribution active utilisent aussi cette adresse. Le nom désigne l’attribution ; il n’encode pas l’IP et ne la réserve pas définitivement.

L’identifiant de session peut être ajouté au nom d’utilisateur du proxy, sélectionné par une API ou représenté par un port configuré. Certains services fournissent aussi une session par défaut sans nom distinct. Ce sont différentes façons de gérer l’attribution : il n’existe donc pas de format de nom d’utilisateur ni de numéro de port universel pour l’accès persistant.

Une session persistante peut couvrir plusieurs connexions réseau. Cela diffère de la simple réutilisation d’une connexion ouverte : les requêtes au sein d’une même connexion TCP ordinaire conservent déjà son IP de sortie. Pour déterminer si une session maintient l’adresse entre les connexions, il est utile d’observer ce qui se passe lorsqu’une nouvelle connexion s’ouvre avec les mêmes paramètres de session.

Quand plusieurs requêtes ont besoin d’une seule IP

Un test en plusieurs étapes dans un navigateur en est un exemple clair. Il peut consister à se connecter à un compte, à ouvrir une page de paramètres, à envoyer une modification et à vérifier le résultat. Maintenir l’IP source évite un changement superflu pendant le test, surtout si le site utilise l’adresse comme l’un de ses contrôles de session.

Un test d’achat ou de réservation peut aussi dépendre d’une expérience régionale cohérente. L’application effectue une recherche, choisit une option et vérifie l’étape suivante par la même sortie. Cela aide à conserver la même localisation réseau entre les étapes, même si le site peut aussi utiliser les paramètres du compte, les informations de livraison ou les cookies pour décider de ce qu’il affiche.

Un autre cas est une séquence d’appels API pour laquelle le service de destination attend des actions liées depuis une adresse source constante. L’attribution doit couvrir toute la séquence, pauses et nouvelles tentatives comprises. À l’inverse, des consultations de pages publiques sans lien entre elles n’ont pas nécessairement besoin d’une même IP. Conserver une adresse est utile lorsque la continuité compte pour la tâche ; cela n’améliore pas en soi sa réputation et ne garantit pas que le site acceptera une requête.

Une session proxy ne préserve pas la connexion à un compte web

Le service de proxys contrôle l’adresse de sortie. Le site web contrôle sa propre session : votre état de connexion, votre panier ou votre progression dans un formulaire. Un navigateur ou un client HTTP conserve normalement cet état au moyen de cookies ou de jetons d’authentification. Les deux systèmes peuvent employer le mot « session », mais ils conservent des informations différentes.

Une connexion à un compte peut donc expirer alors que l’IP de sortie reste identique. Effacer les cookies peut aussi empêcher le site de reconnaître l’utilisateur sans affecter l’attribution du proxy. L’inverse est également possible : un site web peut accepter une connexion valide après un changement d’IP. Son comportement dépend de ses propres règles.

Un objet de session dans une bibliothèque HTTP stocke souvent les cookies et réutilise les connexions. Créer cet objet n’active pas automatiquement l’accès persistant chez le service de proxys. Pour un processus complet, l’application doit maintenir ensemble l’état de sa session web et l’attribution proxy souhaitée. Des profils de navigateur distincts ou des états client isolés restent nécessaires lorsque différentes tâches ne doivent pas partager de cookies.

Ce que signifie réellement la durée de session

Deux minuteries peuvent être décrites comme une durée de session. Une durée de vie fixe limite la durée d’existence de l’attribution depuis son point de départ. Un délai d’inactivité limite la pause après la dernière requête prise en compte. De nouvelles requêtes peuvent relancer le délai d’inactivité sans prolonger une durée de vie fixe distincte.

Prenons deux sessions d’exemple avec une limite de dix minutes. Toutes deux commencent à 14:00 et reçoivent une autre requête à 14:08. Avec une durée de vie fixe, l’échéance reste 14:10. Avec un délai d’inactivité, cette requête repousse l’échéance d’inactivité à 14:18. Une même durée annoncée peut donc produire des comportements très différents pendant une tâche active.

Un service peut imposer les deux limites. Dans ce cas, l’attribution se termine dès que l’une est atteinte. La durée par défaut peut aussi différer de la durée maximale disponible dans les paramètres. Maintenir le trafic peut éviter une expiration pour inactivité, mais ne supprime pas une durée de vie maximale distincte.

L’expiration met fin à l’attribution de l’ancienne sortie. Une connexion ultérieure peut recevoir une autre adresse, même avec le même nom de session. Une connexion ouverte peut être autorisée à se terminer ou être fermée, selon le service. La minuterie ne transfère pas un échange TCP inachevé vers une autre IP.

Choisissez une période qui couvre toute la tâche, les réponses lentes et les pauses prévues. Commencer un nouveau processus vers la fin d’une attribution plus ancienne laisse moins de temps que ne le suggère la durée configurée. Les requêtes destinées uniquement à garder une session inactive ouverte restent du trafic réel et peuvent être décomptées du quota de requêtes ou de données du service.

Séparer les tâches parallèles

Lorsque des tâches indépendantes ont chacune besoin d’une adresse stable, donnez à chaque tâche son propre identifiant de session et conservez-le pendant toutes ses étapes. Un processus qui charge la page suivante doit réutiliser la session de la tâche, plutôt que générer un nouveau nom pour chaque requête. Une nouvelle tentative au sein de cette tâche ne doit pas basculer silencieusement vers des paramètres proxy sans rapport.

Supposons que deux tests dans un navigateur s’exécutent en même temps. Le premier utilise task1, le second task2, et chacun conserve ses propres cookies. Donner aux deux tests le même nom de session reviendrait à demander au service de partager une attribution si les autres paramètres concordent aussi. Ouvrir un nouvel onglet ordinaire ne crée pas, à lui seul, des paramètres proxy distincts ni un stockage de cookies séparé.

Des identifiants différents demandent des attributions distinctes, mais ne garantissent pas systématiquement des IP de sortie différentes. La promesse d’adresses distinctes est une caractéristique séparée du produit. L’accès persistant ne rend pas non plus une sortie exclusive à votre compte : d’autres clients peuvent encore utiliser l’adresse si elle appartient à un pool partagé.

Lorsque le service le permet, plusieurs connexions peuvent utiliser la même session en même temps. Elles partagent sa sortie et restent soumises aux limites de connexions et d’utilisation du compte. Multiplier les noms de session n’augmente pas ces limites. Avant une exécution complète, vérifiez à la fois le nombre de tâches parallèles et le nombre de connexions ouvertes par chacune.

Pourquoi l’adresse peut changer plus tôt que prévu

Une minuterie encore valide ne peut pas maintenir le fonctionnement d’une sortie indisponible. Un appareil résidentiel peut se déconnecter, une connexion mobile recevoir une autre IP publique ou un serveur devenir inaccessible. La durée demandée décrit les règles temporelles de l’attribution ; elle ne garantit pas, à elle seule, que la sortie initiale restera disponible.

La perte de cette sortie peut entraîner deux réponses. Le service peut choisir une sortie de remplacement pour permettre aux requêtes suivantes de continuer, ou renvoyer une erreur en maintenant l’exigence d’utiliser la sortie initiale. Certains produits vous laissent choisir. Le remplacement automatique privilégie l’établissement d’une autre connexion ; une erreur donne à l’application la possibilité de s’arrêter avant de continuer depuis une autre adresse.

Un nom inchangé ne prouve pas que les autres paramètres de session sont restés identiques. Passer à une autre passerelle ou modifier un filtre par pays peut créer une autre attribution. Le périmètre concerné dépend du service : une session peut appartenir à un compte, à un produit ou à un serveur d’entrée précis plutôt qu’être disponible partout sous ce nom.

Si l’adresse change pendant une tâche, la décision suivante concerne l’état de cette tâche. Une étape en lecture seule peut être répétée sans risque. Une action qui a envoyé une commande ou modifié des données demande plus de prudence : la perte d’une réponse ne prouve pas l’échec de l’action. Déterminez ce qui a été accompli avant de recommencer ou de continuer par une autre sortie.

Quand une continuité temporaire suffit

L’accès persistant convient à une tâche dont le début et la fin sont définis, lorsqu’une même IP n’est nécessaire que pendant cette exécution. Testez trois points : l’attribution résiste-t-elle aux pauses prévues, dure-t-elle pendant toute la tâche et gère-t-elle la perte d’une sortie comme vous le souhaitez ? Incluez dans le test une nouvelle connexion après une pause normale ; l’activité dans une connexion déjà ouverte ne prouve pas que l’attribution sera conservée pour la suivante.

Si la même adresse doit rester sur la liste des IP autorisées d’un serveur ou être de nouveau disponible demain, utilisez un service qui fournit une attribution fixe à cette fin. Réutiliser un nom de session persistante après son expiration ne permet pas de récupérer son ancienne adresse de manière fiable. Le maintien temporaire et une IP attribuée durablement répondent à des besoins de continuité différents.