La plupart des descriptions d’un pool de proxies résidentiels le font ressembler à un entrepôt : un grand nombre d’adresses posées sur une étagère, attendant d’être distribuées. Ce modèle mental est erroné d’une manière qui produit de vraies surprises opérationnelles, car un pool n’est pas un inventaire. C’est une population de connexions domestiques réelles qui rejoignent et quittent le réseau en continu, et presque tout ce qui déconcerte les équipes avancées à propos du comportement des pools découle de ce seul fait.
Voici comment un pool est réellement constitué, ce que signifie mécaniquement le renouvellement, et les conséquences autour desquelles vous devriez concevoir votre architecture.
Comment un pool est constitué
Les adresses d’un pool résidentiel appartiennent aux connexions internet domestiques de personnes réelles, ce qui signifie qu’un fournisseur ne peut pas simplement les acheter comme on achète des plages datacenter. Elles doivent être fournies volontairement.
Le mécanisme le plus courant est la participation via un logiciel. Une personne installe une application, ou un SDK intégré à celle-ci, qui offre quelque chose en échange du partage d’une partie de sa connexion : une offre sans publicité, une fonctionnalité payante, un petit paiement, l’accès à un service. Lorsque cet appareil est en ligne et suffisamment inactif, il peut acheminer une requête pour le compte du réseau. Le fournisseur entretient des relations avec les développeurs qui intègrent ce SDK, et ces relations déterminent la forme géographique et réseau du pool, ce qui explique pourquoi deux fournisseurs affichant des totaux similaires peuvent différer sensiblement dans un pays donné. L’éthique de cet arrangement, et la manière de l’auditer, font l’objet de comment les fournisseurs sourcent leurs IP de manière éthique.
La conséquence à retenir : la composition du pool dépend des applications populaires selon les endroits. Elle n’est pas répartie uniformément, elle n’est pas planifiée de manière centralisée, et elle évolue à mesure que ces applications gagnent ou perdent des utilisateurs.
Ce que « renouvellement » signifie réellement
Les pools se renouvellent constamment, pour des raisons qui n’ont rien à voir avec le fournisseur.
Les appareils se déconnectent lorsque les gens ferment une application, mettent un téléphone dans leur poche, quittent leur domicile, ou vont dormir. Les connexions domestiques obtiennent de nouvelles adresses lorsque les routeurs redémarrent ou que le bail d’un FAI expire, si bien que le même foyer peut apparaître demain sous une adresse différente. Des participants se retirent. D’autres rejoignent. En plus de cela, les fournisseurs eux-mêmes retirent les adresses qui se sont dégradées, que ce soit à cause d’une mauvaise réputation ou d’un comportement peu fiable.
Rien de tout cela n’est une fenêtre de maintenance. C’est l’état stable, qui se produit en continu en arrière-plan, ce qui explique pourquoi un pool résidentiel se modélise mieux comme un flux que comme un stock.
La taille du pool n’est pas la disponibilité
C’est le cœur pratique du sujet, et c’est là que les chiffres affichés induisent en erreur.
Un chiffre de pool publié est généralement cumulatif : les adresses que le réseau a vues sur une certaine période. Ce qui détermine votre expérience, c’est la disponibilité concurrente, c’est-à-dire combien d’adresses distinctes peuvent vous servir à cet instant précis, dans le pays que vous avez demandé, avec les filtres que vous avez appliqués. Ces deux chiffres diffèrent d’ordres de grandeur, et seul le second contraint votre tâche.
Trois facteurs le réduisent davantage. La géographie : un chiffre global ne dit rien sur votre marché, ce qui est l’argument développé dans disponibilité par pays. Les filtres : ajouter une ville ou un ASN réduit fortement l’ensemble éligible, puisque seules les adresses correspondant à tous les critères sont qualifiées. Et le temps : parce que le pool suit l’activité humaine, le même pays est plus fourni en soirée locale qu’à quatre heures du matin.
La conclusion est que « quelle est la taille du pool » est une question quasiment sans réponse utile, tandis que « combien d’adresses distinctes est-ce que j’obtiens réellement pour mon filtre, à ma concurrence, à l’heure où je m’exécute » est mesurable en vingt minutes et constitue le chiffre qui compte.
Les cinq comportements que l’attrition explique
Une fois que l’on modélise le pool comme une population plutôt qu’un inventaire, une série de comportements autrement déroutants devient évidente.
Les sessions persistantes se terminent parfois plus tôt. Vous avez demandé une session de dix minutes et elle n’a duré que quatre minutes, parce que l’appareil sous-jacent s’est déconnecté. Une session persistante est un effort raisonnable pour maintenir une adresse pendant une durée, pas un bail sur une infrastructure, et le code qui suppose le contraire échoue par intermittence. Traitez-le comme un événement normal : détectez le changement et redémarrez la séquence plutôt que de le traiter comme une erreur, selon sticky versus rotating.
La même adresse revient. La rotation sélectionne indépendamment à chaque fois plutôt que de parcourir une liste sans répétition, donc les répétitions sont attendues, et elles deviennent fréquentes lorsqu’un filtre restrictif réduit l’ensemble éligible. C’est de l’arithmétique plutôt qu’un défaut, et c’est l’une des causes traitées dans IP qui ne tourne pas.
Les performances varient d’une adresse à l’autre. Ce sont des connexions grand public avec leur propre bande passante, leur propre congestion et leur propre usage domestique, si bien que la latence a une distribution bien plus large que sur une infrastructure datacenter. Les percentiles sont la façon honnête de la décrire ; les moyennes cachent la queue de distribution qui affecte réellement votre planification.
La disponibilité évolue au fil de la journée. Une tâche qui réussit à 20h00 et peine à 04h00 sur le même marché constate généralement une profondeur de pool diurne plutôt qu’un changement de cible.
Les résultats diffèrent entre deux exécutions de la même tâche. Adresses différentes, réseaux différents, réputations différentes. Une certaine variance est inhérente, et traiter chaque fluctuation comme une régression gaspille beaucoup d’efforts d’investigation.
Concevoir pour une population
Conséquences pratiques pour quiconque construit sur cette base.
Traitez les adresses comme jetables et les routes comme l’unité que vous gérez. Vous n’avez jamais choisi une adresse et ne pouvez pas la conserver, donc le suivi de la santé doit se faire au niveau de la route et de la session, ce qui est le modèle décrit dans surveiller la santé des proxies à grande échelle et construire un gestionnaire de proxies.
Rendez les tâches reprenables et idempotentes. Si une session peut disparaître en cours de séquence, la séquence doit pouvoir redémarrer sans dupliquer le travail ni corrompre un enregistrement.
Choisissez les TTL délibérément. Un TTL long est une demande, pas une garantie, et demander une heure sur une connexion grand public vous expose à des interruptions en plein flux. Demandez ce dont le flux a réellement besoin.
Mesurez votre pool effectif plutôt que de lire un chiffre marketing : échantillonnez quelques centaines de sorties sous votre filtre réel, comptez les adresses et organisations distinctes, et répétez aux heures où vous vous exécutez. Ce chiffre, et non le chiffre affiché, doit éclairer vos décisions de concurrence et de distribution, en complément du raisonnement présenté dans combien d’IP proxy vous faut-il réellement.
Et planifiez en tenant compte de la population, car exécuter une tâche lourde pour un petit marché pendant ses heures nocturnes revient à lutter contre le pool sans raison.
À quoi ressemble une bonne gestion de pool vue de l’extérieur
Vous ne pouvez pas auditer les mécanismes internes d’un fournisseur, mais les effets sont observables. Des taux de réussite constants aux heures où vous vous exécutez suggèrent que le pool est suffisamment profond sur vos marchés plutôt que simplement volumineux en agrégat. Une large diversité d’organisations FAI grand public dans votre échantillon de sortie suggère une véritable offre résidentielle plutôt qu’une offre diluée, ce qui constitue la vérification décrite dans repérer les IP datacenter vendues comme résidentielles. Une géolocalisation qui correspond à ce que les cibles croient réellement, plutôt qu’uniquement à ce que rapporte un service de lookup, suggère que l’étiquetage géographique est bien maintenu. Et un fournisseur capable de décrire son sourcing sans gêne vous dit quelque chose sur la façon dont le pool est géré en général.
L’essentiel à retenir
Un pool résidentiel est une population, pas un inventaire. Il est constitué par la participation plutôt qu’acheté, sa forme suit les logiciels que les gens utilisent réellement, et il se renouvelle en continu à mesure que les appareils se déconnectent, que les adresses sont réattribuées, et que les participants vont et viennent. Cette propriété unique explique les sessions persistantes qui se terminent tôt, les adresses qui reviennent, la latence qui varie fortement, la disponibilité qui évolue au fil de la journée, et deux exécutions identiques qui produisent des résultats différents. Concevez en conséquence : traitez les adresses comme jetables, suivez la santé par route, rendez les séquences reprenables, choisissez des TTL adaptés au flux, et mesurez votre pool effectif sous vos propres filtres à vos propres heures plutôt que de faire confiance à un chiffre affiché qui décrit autre chose que ce qui vous contraint réellement.
Ce pool est ce sur quoi reposent les proxies résidentiels, couvrant 195 pays avec des filtres par pays, région, ville et ASN, et une tarification au GB permettant de mesurer votre propre disponibilité effective en ne coûtant que la bande passante utilisée par le test.