Analyse approfondie : comment fonctionne un réseau de proxies résidentiels ? L'architecture expliquée

C'est une question que se posent de nombreuses personnes dans le secteur des proxies. Voici une explication de l'architecture approximative qui sous-tend tout réseau de proxies résidentiels.

Commençons par définir ce qu'est un réseau résidentiel : un réseau de pairs capables d'acheminer des paquets vers des destinations.

En termes simples, un réseau de proxies résidentiels fait transiter vos requêtes internet par les appareils de vraies personnes. Ces appareils sont recrutés via des applications auxquelles les utilisateurs ont consenti ; le réseau sélectionne l'appareil le mieux adapté à chaque requête, et la réponse vous parvient comme si vous aviez navigué depuis cet emplacement. La complexité qui se cache sous la surface est ce qui distingue un réseau résidentiel rapide et fiable d'un réseau lent et peu fiable.

1. Le SDK

Les pairs sont recrutés via un SDK (Software Development Kit), intégré dans des applications grand public. Sur la base du consentement de l'utilisateur, le SDK permet au réseau de proxies résidentiels d'acheminer des paquets à travers l'appareil vers des destinations. C'est l'élément fondamental qui permet le proxying des requêtes via de véritables appareils résidentiels.

2. Requêtes standard et requêtes proxifiées

Voici comment une requête HTTPS standard est acheminée (de L4 à L7). Les valeurs RTT ci-dessous sont cumulatives ; chaque couche s'ajoute au total en cours, en supposant une connexion fraîche :

Établissement de la connexion TCP (Étape : 1 RTT | Cumulatif : 1 RTT)

1. L'utilisateur envoie un SYN à la destination

2. La destination envoie un SYN-ACK à l'utilisateur

3. L'utilisateur envoie un ACK à la destination (des données peuvent être transportées dans ce dernier segment)

Coût de l'étape : 1 RTT, portant le temps cumulatif total à 1 RTT. RFC 9293.

L5/L6 : (Étape : 1 RTT pour TLS 1.3 / 2 RTT pour TLS 1.2 | Cumulatif : 2 RTT avec TLS 1.3 / 3 RTT avec TLS 1.2)

1. L'utilisateur envoie un ClientHello à la destination

2. La destination envoie ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished à l'utilisateur

Coût de l'étape : 1 RTT pour le TLS 1.3 moderne (Cumulatif : 2 RTT), ou 2 RTT pour le TLS 1.2 historique (Cumulatif : 3 RTT)

Pris séparément, TLS 1.3 nécessite 1 RTT pour l'établissement de la connexion, et TLS 1.2 en nécessite 2 ; les totaux indiqués ici sont cumulatifs et incluent l'aller-retour TCP, si bien que TLS 1.2 ajoute un RTT complet supplémentaire (3 RTT au total). TLS 1.3 peut également effectuer une reprise de session en 0-RTT lors de connexions répétées, avec un compromis connu en matière de rejeu.

L7 : Couche applicative (Étape : 1 RTT | Cumulatif : 3 RTT avec TLS 1.3 / 4 RTT avec TLS 1.2)

1. L'utilisateur envoie la requête et les en-têtes à la destination

2. La destination envoie la réponse et les en-têtes à l'utilisateur

Coût de l'étape : 1 RTT, portant le temps total jusqu'au premier octet de données à 3 RTT avec TLS 1.3, ou 4 RTT avec TLS 1.2

Dès qu'un proxy est ajouté, il introduit toujours au moins un saut supplémentaire et une certaine latence : le chemin est plus long (utilisateur → proxy → destination, et retour), et le proxy ajoute son propre temps de traitement. L'ajout de RTT supplémentaires dépend quant à lui du type de proxy.

Un proxy terminant (un proxy HTTP forward utilisant CONNECT, ou une passerelle résidentielle qui ouvre sa propre connexion sortante) en ajoute effectivement : le client effectue d'abord l'établissement de la connexion avec le proxy, et pour HTTPS, la requête CONNECT et sa réponse « 200 Connection Established » constituent un aller-retour à part entière avant même que l'établissement de la connexion TLS de bout en bout ne commence ; le proxy effectue ensuite son propre établissement de connexion vers la destination.

Un relais transparent L3/L4 qui ne termine pas la connexion laisse les établissements de connexion de bout en bout et n'ajoute aucun aller-retour supplémentaire, seulement un chemin plus long. Dans tous les cas, plus la distance est grande et plus les intermédiaires sont nombreux, plus la latence est élevée — et c'est précisément ce que le reste de cet article cherche à minimiser.

3. Le problème des « embouteillages »

Les réseaux résidentiels sont extrêmement complexes, car il existe de nombreuses subtilités dans le routage intelligent des requêtes sans ralentir le réseau.

Une bonne analogie est celle du réseau routier. Si trop de voitures empruntent un même itinéraire, il devient congestionné. L'idéal est une absence totale de congestion sur chaque itinéraire, ce qui n'est réalisable qu'en acheminant intelligemment les requêtes en fonction de la capacité de chaque route.

Chaque pair dispose d'une capacité limitée avant d'être saturé. Les réseaux de proxies résidentiels doivent collecter en permanence des informations sur la capacité réseau de chaque appareil afin d'équilibrer la charge entre les pairs, en satisfaisant les clients sans saturer les pairs.

4. Optimisations côté fournisseur

4a. DNS et datacenters

Le réseau résidentiel devrait tirer parti du transport de qualité datacenter dans la mesure du possible. Par exemple, si un client en Europe occidentale achemine ses requêtes via des pairs en Europe orientale, le réseau devrait utiliser un équilibreur de charge DNS pour recevoir ces paquets en Europe occidentale et les transmettre via une route datacenter directe vers la passerelle la plus proche, minimisant ainsi significativement la surcharge de latence.

4b. Optimisation interne de la couche 4

Entre les nœuds de passerelles de datacenters, le réseau devrait utiliser des routes directes et distribuer les passerelles à l'échelle mondiale pour une bonne couverture. Entre les passerelles et les pairs, chaque passerelle devrait maintenir des connexions TCP préchauffées et utiliser le chiffrement TLS mutuel pour sécuriser à la fois l'appareil et la passerelle.

4c. Optimisation externe de la couche 4

Le SDK peut maintenir des connexions TCP préchauffées vers les destinations populaires afin d'économiser 1 RTT entre le pair et la destination, puisque la couche applicative peut toujours être reconstruite par-dessus une connexion TCP existante.

4d. Configurations de paramètres

Les paramètres TCP peuvent être ajustés en temps réel pour rendre la transmission des paquets plus efficace et réduire la consommation CPU/RAM du SDK. Minimiser la consommation de ressources est essentiel. Si le SDK dégrade l'expérience utilisateur sur l'appareil du pair, les éditeurs résilieront leur contrat avec le SDK.

4e. Algorithme de routage intelligent (basé sur les performances)

C'est l'optimisation la plus difficile à mettre en œuvre, mais aussi la plus efficace. Le réseau maintient une base de données en mémoire et en temps réel sur toutes les passerelles, interrogeable instantanément pour répondre à la question : « Quel appareil est le mieux adapté pour acheminer cette requête ? »

Sans cet algorithme, chaque seconde requête risque d'être acheminée vers un pair lent ou saturé, et le réseau s'effondrera sous une charge modérée.

4f. Algorithme de plafonnement d'IP (basé sur la réputation)

Les réseaux résidentiels ont intérêt à préserver la réputation des IP par destination. Si un tiers du pool est mis sur liste noire par les destinations A, B et C, les utilisateurs ciblant ces destinations constatent un taux d'erreur de 33 %. En n'acheminant les requêtes que via les 67 % restants et en plaçant les IP sur liste noire en période de repos, le réseau offre une expérience client nettement meilleure.

Les algorithmes de plafonnement d'IP sont complexes à construire et à maintenir, mais ils apportent des améliorations significatives à la qualité du réseau quand ils sont faits correctement.

5. Optimisations côté client

5a. Datacenters

Les clients devraient utiliser des serveurs dans des datacenters situés aussi près que possible de la passerelle la plus proche pour leur région de pairs cible. Pour des pairs aux Pays-Bas, les datacenters d'Amsterdam sont le choix logique. Vous pouvez également effectuer un traceroute vers la passerelle et choisir le fournisseur offrant le chemin le plus court.

5b. DNS

Transmettez le nom de domaine lui-même plutôt que son adresse IP résolue. Cela permet au pair d'effectuer la résolution DNS, ce qui peut conduire à un routage plus efficace. Incluez toujours le domaine dans le champ SNI afin que l'établissement de la connexion TLS puisse aboutir.

5c. Ciblage géographique

Bien que le ciblage géographique puisse réduire la latence vers les pairs cibles, il présente également des inconvénients. Si une zone géographique spécifique ne dispose pas de suffisamment de pairs pour satisfaire votre charge simultanée, les requêtes échoueront ou la latence s'envolera. Étudiez les limites de votre zone géographique cible et surveillez ses métriques de santé avant d'en dépendre exclusivement.

5d. Optimisations L4 et sessions persistantes

Conformément aux standards du secteur, l'authentification est transmise via un en-tête Proxy-Authorization encodé en Base64, accompagné de paramètres de requête tels que la session persistante et le ciblage géographique. Une fois les requêtes parvenues à la passerelle, ces paramètres sont décodés et appliqués.

Un utilisateur de proxy professionnel maintient une connexion par IP, surveille l'IP de sortie toutes les 10 à 20 secondes pour confirmer que le pair est toujours actif, et équilibre la charge entre les pairs en fonction des performances. Par exemple, si une cible applique une limitation de débit après 50 requêtes, réduisez l'activité à 25 ou 30, ou effectuez une rotation dès que la limite est atteinte.

Le principe fondamental : lorsque le nombre de pairs disponibles est insuffisant, maximisez la capacité de chaque pair, en termes de limites de débit, de vitesse réseau et de gestion de la congestion.

Publié par Alon Levi, PDG de FlashProxy

À propos de l'auteur : Alon Levi est le PDG de FlashProxy et possède une vaste expérience en infrastructure de proxies, en architecture réseau et en technologies de routage IP à grande échelle.  

Me contacter sur LinkedIn  ·  Contact : [email protected]

Questions fréquemment posées

Pourquoi les proxies résidentiels sont-ils plus lents que les proxies de datacenter ?

Les proxies résidentiels acheminent les requêtes via de véritables appareils grand public connectés à des réseaux internet domestiques. Cela ajoute au moins un saut réseau supplémentaire et, pour les passerelles terminantes, des allers-retours d'établissement de connexion additionnels, sans compter la variabilité des débits du haut débit domestique, ce qui les rend plus lents que les proxies hébergés directement en datacenter.

Qu'est-ce qu'une session persistante dans les proxies ?

Une session persistante maintient le routage des requêtes via la même adresse IP pendant une durée définie. Elle est utile pour les tâches nécessitant une continuité de session, comme le maintien d'un état de connexion ou la conservation d'un panier d'achat.

Pourquoi les IP de proxies résidentiels se retrouvent-elles sur liste noire ?

Lorsqu'une IP résidentielle envoie trop de requêtes vers une destination spécifique, ce site peut la signaler et la bloquer. Les réseaux sursaturés ou mal gérés accélèrent ce processus, réduisant le pool d'IP utilisables pour l'ensemble des utilisateurs.

Qu'est-ce qu'un pair proxy ?

Un pair proxy est un véritable appareil grand public (téléphone, ordinateur ou smart TV) dont la connexion internet est utilisée pour acheminer du trafic proxy, avec le consentement du propriétaire de l'appareil, via un SDK intégré dans une application qu'il a installée.

Sources et références

• IETF RFC 9293, Transmission Control Protocol : https://datatracker.ietf.org/doc/html/rfc9293

• IETF RFC 8446, TLS 1.3 (établissement de connexion en 1-RTT ; reprise en 0-RTT) : https://datatracker.ietf.org/doc/html/rfc8446

• IETF RFC 5246, TLS 1.2 (établissement de connexion en 2-RTT) : https://datatracker.ietf.org/doc/html/rfc5246

• IETF RFC 9110, HTTP Semantics (méthode CONNECT) : https://datatracker.ietf.org/doc/html/rfc9110

• IETF RFC 6066, TLS Server Name Indication (SNI) : https://datatracker.ietf.org/doc/html/rfc6066

• IETF RFC 7235, HTTP/1.1 Authentication (Proxy-Authorization) : https://datatracker.ietf.org/doc/html/rfc7235

• MDN Web Docs, méthode HTTP CONNECT : https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT

• Cloudflare, latence des proxies forward : https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/

• Cloudflare Learning Center, Qu'est-ce que le SNI ? : https://www.cloudflare.com/learning/ssl/what-is-sni/

• Ilya Grigorik, High Performance Browser Networking : https://hpbn.co/