« Backconnect » est un de ces termes qui apparaissent dans la documentation des proxys sans jamais être définis, généralement parce que les personnes qui l’écrivent ont oublié qu’il ait pu un jour être inconnu. Il décrit une architecture, et une fois cette architecture comprise, le reste du produit s’explique naturellement : pourquoi il n’y a qu’une seule adresse à configurer, pourquoi votre ciblage réside dans un nom d’utilisateur, et pourquoi votre client HTTP peut interrompre silencieusement la rotation sans que rien ne paraisse anormal.
D’où vient ce nom
L’ancien modèle était une liste. Vous achetiez un ensemble de proxys et receviez un fichier d’adresses et de ports, et votre code se connectait directement à chacun d’eux. Les gérer était votre problème : lesquels sont actifs, lesquels sont bloqués sur quelle cible, comment répartir la charge entre eux, que faire quand la liste changeait.
Backconnect inverse cette logique. Vous vous connectez à une seule adresse de passerelle, et la passerelle se reconnecte en sortie via l’un des nombreux nœuds de son réseau, en votre nom. Vous ne connaissez jamais l’adresse de sortie à l’avance et vous ne gérez jamais de liste, car la décision de routage se fait du côté du fournisseur au moment de la requête. C’est toute l’idée : une porte d’entrée unique et stable, de nombreuses portes de sortie en rotation.
En pratique, « backconnect proxy », « rotating proxy » et « gateway proxy » sont aujourd’hui utilisés plus ou moins de manière interchangeable, backconnect mettant l’accent sur l’architecture et rotating sur le comportement qu’elle produit.
Ce qui se passe lors d’une seule requête
Concrètement, quand votre client envoie une requête via une passerelle backconnect :
- Votre client ouvre une connexion à la passerelle,
p.shifter.io:443, et s’authentifie avec un nom d’utilisateur et un mot de passe. - La passerelle analyse votre nom d’utilisateur, qui porte plus qu’une simple identité. Tout indicateur de ciblage pour le pays, la région, la ville ou l’ASN, ainsi que tout identifiant de session et sa durée de vie (TTL), y sont encodés.
- Elle sélectionne un nœud de sortie correspondant à ces contraintes parmi le pool actuellement disponible. « Disponible » est le mot clé, car le pool est une population qui se renouvelle en continu, comme expliqué dans comment les fournisseurs constituent et renouvellent leurs pools.
- Elle transmet votre requête via ce nœud, de sorte que la cible voit l’adresse résidentielle du nœud plutôt que la vôtre ou celle de la passerelle.
- La réponse revient par le même chemin.
Si vous avez fourni un identifiant de session, la passerelle mémorise l’association et achemine les requêtes suivantes portant cet identifiant via le même nœud jusqu’à l’expiration du TTL ou la déconnexion du nœud. Si vous ne l’avez pas fait, la requête suivante obtient une sortie choisie indépendamment.
C’est pourquoi le ciblage réside dans le nom d’utilisateur. Il n’y a qu’un seul point de terminaison, donc les instructions propres à chaque requête doivent transiter par le seul champ propre à chaque requête que le protocole proxy vous offre avant l’établissement du tunnel.
# même hôte et même port, comportement différent, exprimé entièrement dans le nom d'utilisateur
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonCe que cela change dans votre code
Trois conséquences pratiques découlent de cette architecture, et la première est la source de confusion la plus courante de tout le produit.
La rotation se fait par connexion, pas par requête. La sortie est choisie au moment où le tunnel vers la passerelle est établi. Les clients HTTP modernes maintiennent les connexions ouvertes et les réutilisent, donc si votre client envoie dix requêtes via une connexion mise en pool, les dix sortent par la même sortie, et cela ressemble exactement à une rotation défaillante. Ce n’est pas le cas : votre client fait ce pour quoi il a été conçu. Le diagnostic et la solution se trouvent dans IP qui ne tourne pas, et pour résumer, une boucle curl exécutée dans des processus séparés effectuera une rotation, tandis qu’un objet de session partagé ne le fera pas.
Il n’y a pas de liste d’IP à gérer, et pas d’IP à blâmer. La santé est une propriété d’une route, c’est-à-dire d’une cible combinée à une géographie, ainsi que d’une session, plutôt qu’une propriété d’une adresse que vous pourriez ajouter à une liste noire. Cela redéfinit entièrement le suivi et la gestion des échecs, comme expliqué dans surveiller la santé des proxys à grande échelle.
La configuration est statique, le comportement est dynamique. L’hôte et le port ne changent jamais, donc faire passer une tâche de sorties américaines en rotation à des sorties allemandes fixes revient à modifier une chaîne de caractères plutôt qu’à redéployer quoi que ce soit. C’est ce qui fait de la collecte multi-marchés une question de configuration plutôt qu’un projet d’infrastructure.
Backconnect face au modèle de liste de ports
L’ancien modèle existe toujours, et la comparaison est utile car elle explique pourquoi le secteur a évolué.
Avec une liste de ports, vous connaissiez vos adresses, ce qui semble être un avantage et ne l’est en réalité presque jamais : vous héritiez du travail de vérification de disponibilité, de répartition de charge et de remplacement, et votre capacité était un nombre fixe de ports plutôt qu’une capacité s’ajustant à la demande. La tarification suivait la même logique, par port plutôt que par unité de travail, ce qui correspond au modèle abordé dans pourquoi l’ère du tarif par port est révolue.
Avec backconnect, vous renoncez à connaître la sortie à l’avance mais vous n’avez plus à en gérer une. La capacité devient une question de bande passante et de concurrence plutôt que du nombre de ports achetés, et la rotation est un paramètre plutôt qu’une implémentation que vous devez écrire vous-même.
L’ancien modèle conserve son intérêt lorsque vous avez véritablement besoin qu’une même adresse persiste, ce à quoi servent les proxys ISP statiques, comme expliqué dans ISP contre résidentiel.
Les sessions persistantes au sein d’une passerelle backconnect
Il est utile de comprendre les sessions persistantes pour ce qu’elles sont réellement : une association que la passerelle conserve, et non une allocation que vous possédez.
Vous choisissez un identifiant, la passerelle l’associe à un nœud de sortie, et les requêtes portant cet identifiant suivent la même route jusqu’à l’expiration du TTL. Comme le nœud est un véritable appareil domestique, il peut également disparaître avant l’expiration du TTL, ce qui explique pourquoi une session persistante fonctionne au mieux, sans garantie, plutôt que comme un bail. Un code qui traite un changement d’adresse en cours de séquence comme une erreur plutôt que comme un événement normal sera instable pour des raisons qui n’ont rien à voir avec le fournisseur. Ce comportement est traité dans persistant contre rotatif et le renouvellement sous-jacent dans comment fonctionne la rotation.
En résumé
Backconnect signifie que vous vous connectez à un seul point de terminaison qui se reconnecte en sortie via de nombreux autres, en choisissant la sortie à chaque requête parmi ce qui est actuellement disponible. Cette architecture explique pourquoi il n’y a qu’un seul hôte et un seul port, pourquoi le pays, la ville, la session et le TTL sont encodés dans le nom d’utilisateur, et pourquoi vous ne gérez jamais de liste d’adresses. Elle explique aussi la source de confusion la plus fréquente dans ce produit : la rotation est décidée au moment où une connexion est établie, donc un client HTTP réutilisant une connexion mise en pool enverra toutes ses requêtes via la même sortie et donnera l’impression de ne pas parvenir à effectuer de rotation. Considérez les sorties comme éphémères, les sessions comme une association plutôt qu’une allocation, et la santé comme une propriété des routes, et l’architecture cessera de vous surprendre.
Cette passerelle constitue l’interface complète vers les proxys résidentiels : un seul hôte, une seule paire d’identifiants, avec la rotation, la géographie et le comportement de session exprimés par requête et facturés par GB plutôt que par port. Si vous découvrez cette terminologie, le glossaire couvre le reste.