Backconnect Residential Proxies: Wie rotierende Gateways funktionieren

„Backconnect” ist einer dieser Begriffe, die in der Proxy-Dokumentation auftauchen, ohne je definiert zu werden, meist weil diejenigen, die darüber schreiben, vergessen haben, dass er einmal unbekannt war. Er beschreibt eine Architektur, und sobald man diese Architektur versteht, ergibt der Rest des Produkts einen Sinn: warum es nur eine Adresse zu konfigurieren gibt, warum das Targeting in einem Benutzernamen steckt, und warum der HTTP-Client die Rotation stillschweigend unterbrechen kann, ohne dass etwas offensichtlich falsch aussieht.

Woher der Name kommt

Das ältere Modell war eine Liste. Man kaufte eine Reihe von Proxys und erhielt eine Datei mit Adressen und Ports, und der eigene Code verband sich direkt mit jedem einzelnen. Die Verwaltung war die eigene Aufgabe: welche noch laufen, welche für welches Ziel gesperrt sind, wie man die Last verteilt, was zu tun ist, wenn sich die Liste ändert.

Backconnect kehrt das um. Man verbindet sich mit einer einzigen Gateway-Adresse, und das Gateway stellt in ihrem Namen die ausgehende Verbindung über einen der vielen Knoten in seinem Netzwerk her. Man erfährt die Ausgangsadresse nie im Voraus und verwaltet nie eine Liste, weil die Routing-Entscheidung auf Seiten des Anbieters im Moment der Anfrage getroffen wird. Das ist der ganze Grundgedanke: eine stabile Vordertür, viele rotierende Hintertüren.

In der Praxis werden „Backconnect-Proxy”, „Rotating-Proxy” und „Gateway-Proxy” heute mehr oder weniger synonym verwendet, wobei Backconnect die Architektur betont und Rotation das Verhalten, das daraus entsteht.

Was bei einer einzelnen Anfrage passiert

Konkret geschieht Folgendes, wenn der Client eine Anfrage über ein Backconnect-Gateway sendet:

1. Der Client öffnet eine Verbindung zum Gateway, p.shifter.io:443, und authentifiziert sich mit Benutzername und Passwort.
2. Das Gateway wertet den Benutzernamen aus, der mehr als nur die Identität trägt. Alle Targeting-Flags für Land, Region, Stadt oder ASN sowie jede Sitzungskennung und TTL sind dort kodiert.
3. Es wählt aus dem aktuell verfügbaren Pool einen Ausgangsknoten aus, der diesen Einschränkungen entspricht. Verfügbar ist dabei das entscheidende Wort, denn der Pool ist eine sich ständig verändernde Population, wie in wie Anbieter Pools aufbauen und erneuern beschrieben.
4. Es leitet die Anfrage über diesen Knoten weiter, sodass das Ziel die Wohnadresse des Knotens sieht und nicht die eigene oder die des Gateways.
5. Die Antwort kommt auf demselben Weg zurück.

Wurde eine Sitzungskennung angegeben, merkt sich das Gateway die Zuordnung und leitet nachfolgende Anfragen mit dieser Kennung über denselben Knoten, bis die TTL abläuft oder der Knoten ausfällt. Wurde keine angegeben, erhält die nächste Anfrage einen unabhängig ausgewählten Ausgang.

Deshalb steckt das Targeting im Benutzernamen. Es gibt nur einen Endpunkt, also müssen anfragespezifische Anweisungen in dem einzigen anfragespezifischen Feld übertragen werden, das das Proxy-Protokoll vor dem Aufbau des Tunnels zur Verfügung stellt.

# gleicher Host und Port, unterschiedliches Verhalten, vollständig im Benutzernamen ausgedrückt
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/json

Was sich dadurch im eigenen Code ändert

Aus dieser Architektur ergeben sich drei praktische Konsequenzen, und die erste davon sorgt für mehr Verwirrung als alles andere bei diesem Produkt.

Die Rotation erfolgt pro Verbindung, nicht pro Anfrage. Der Ausgang wird beim Aufbau des Tunnels zum Gateway gewählt. Moderne HTTP-Clients halten Verbindungen offen und verwenden sie erneut. Sendet der Client also zehn Anfragen über eine einzige gepoolte Verbindung, verlassen alle zehn das Netzwerk über denselben Ausgang, und es sieht genau so aus, als sei die Rotation defekt. Ist sie nicht: Der Client tut lediglich das, wofür er entworfen wurde. Diagnose und Lösung finden sich unter IP rotiert nicht, kurz gesagt: eine curl-Schleife in getrennten Prozessen rotiert, ein gemeinsam genutztes Session-Objekt nicht.

Es gibt keine IP-Liste zu verwalten und keine IP, der man die Schuld geben könnte. Gesundheit ist eine Eigenschaft einer Route, also von Ziel plus Geografie, und einer Sitzung, nicht einer Adresse, die man auf eine Sperrliste setzen könnte. Das verändert Monitoring und Fehlerbehandlung grundlegend, siehe Überwachung der Proxy-Gesundheit im großen Maßstab.

Die Konfiguration ist statisch, das Verhalten dynamisch. Host und Port ändern sich nie, sodass das Umstellen eines Jobs von rotierenden US-Ausgängen auf feste deutsche Ausgänge eine Textänderung ist und keine Neubereitstellung. Genau das macht die Datenerfassung über mehrere Märkte hinweg zu einer Konfigurationsfrage statt zu einem Infrastrukturprojekt.

Backconnect im Vergleich zum Port-Listen-Modell

Das ältere Modell existiert noch, und der Vergleich ist aufschlussreich, weil er erklärt, warum die Branche sich weiterentwickelt hat.

Bei einer Port-Liste kannte man seine Adressen, was nach einem Vorteil klingt, es aber meist nicht ist: Man übernahm die Arbeit der Verfügbarkeitsprüfung, der Lastverteilung und des Ersatzes, und die Kapazität war eine feste Anzahl von Ports statt etwas, das sich mit der Nachfrage anpasste. Die Preisgestaltung folgte demselben Muster, pro Port statt pro Arbeitseinheit, wie in warum die Ära der Port-Preisgestaltung vorbei ist besprochen.

Bei Backconnect gibt man das Wissen über den Ausgang im Voraus auf und gewinnt dafür, dass man ihn nicht verwalten muss. Kapazität wird zu einer Frage von Bandbreite und Nebenläufigkeit statt davon, wie viele Ports man gekauft hat, und Rotation ist ein Parameter statt einer selbst geschriebenen Implementierung.

Wo sich das ältere Modell noch auszahlt, ist, wenn tatsächlich dieselbe Adresse dauerhaft bestehen bleiben muss, wofür statische ISP-Proxys gedacht sind, siehe ISP versus Residential.

Sticky Sessions innerhalb eines Backconnect-Gateways

Sticky Sessions sollte man als das verstehen, was sie sind: eine Zuordnung, die das Gateway vorhält, keine Zuweisung, die man besitzt.

Man wählt eine Kennung, das Gateway ordnet ihr einen Ausgangsknoten zu, und Anfragen mit dieser Kennung folgen derselben Route, bis die TTL abläuft. Da es sich beim Knoten um ein echtes Haushaltsgerät handelt, kann er auch vor Ablauf der TTL verschwinden, weshalb eine Sticky Session eher ein Best-Effort-Versuch als eine Zusicherung ist. Code, der einen Adresswechsel mitten in einer Sequenz als Fehler statt als normales Ereignis behandelt, wird aus Gründen instabil sein, die nichts mit dem Anbieter zu tun haben. Das Verhalten wird in Sticky versus Rotating behandelt, der zugrunde liegende Wechsel in wie Rotation funktioniert.

Fazit

Backconnect bedeutet, dass man sich mit einem einzigen Endpunkt verbindet, der wiederum über viele weitere Verbindungen nach außen herstellt und dabei den Ausgang pro Anfrage aus dem jeweils verfügbaren Bestand wählt. Diese Architektur ist der Grund, warum es einen einzigen Host und Port gibt, warum Land, Stadt, Sitzung und TTL im Benutzernamen kodiert sind, und warum man nie eine Adressliste verwaltet. Sie erklärt auch die häufigste Quelle von Verwirrung bei diesem Produkt: Die Rotation wird beim Aufbau einer Verbindung entschieden, sodass ein HTTP-Client, der eine gepoolte Verbindung wiederverwendet, jede Anfrage über denselben Ausgang sendet und den Eindruck erweckt, die Rotation funktioniere nicht. Wer Ausgänge als vergänglich betrachtet, Sitzungen als Zuordnung statt als Zuweisung und Gesundheit als Eigenschaft von Routen, den überrascht diese Architektur nicht mehr.

Dieses Gateway ist die gesamte Schnittstelle zu Residential Proxies: ein Host, ein Zugangsdatenpaar, mit Rotation, Geografie und Sitzungsverhalten, die pro Anfrage ausgedrückt und pro GB statt pro Port abgerechnet werden. Wer mit der Terminologie noch nicht vertraut ist, findet im Glossar den Rest davon.