Sticky Sessions

Eine Sticky Session weist den Proxydienst an, eine Ausgangs-IP-Adresse für zusammengehörige Anfragen beizubehalten. Ihre Anwendung kann über diese Adresse Seiten öffnen, Daten senden und Ergebnisse erhalten, solange die Zuweisung gültig und der Ausgang verfügbar bleibt. Nach Aufgabenabschluss kann sie eine getrennte Sitzung für die nächste Aufgabe starten.

Das ist häufig ein Zugangsmodus zu einem rotierenden Pool. Den grundsätzlichen Vergleich behandelt Statische und rotierende Proxies. Hier geht es darum, eine Adresse für eine Aufgabe zu halten, wie lange die Zuweisung gilt und was sie unterbrechen kann.

Wie der Dienst die ausgewählte IP-Adresse beibehält

Der Dienst muss erkennen, welche Verbindungen zu derselben Aufgabe gehören. Ein verbreitetes Verfahren ist eine Sitzungskennung in den Proxyeinstellungen. Bei der ersten Verbindung wählt er einen Ausgang und verknüpft ihn mit dieser Kennung. Spätere Verbindungen mit denselben Sitzungseinstellungen verwenden den zugewiesenen Ausgang während der aktiven Sitzung.

Ein Browsertest verwendet beispielsweise den Sitzungsnamen task1. Seine erste Verbindung erhält die beispielhafte Ausgangs-IP-Adresse 198.51.100.27. Das Öffnen der nächsten Seite und das Absenden eines Formulars über dieselbe aktive Zuweisung nutzen diese Adresse ebenfalls. Der Name kennzeichnet die Zuweisung; er codiert weder die IP-Adresse noch reserviert er sie dauerhaft.

Die Sitzungskennung kann dem Proxy-Benutzernamen hinzugefügt, über eine API ausgewählt oder durch einen eingerichteten Port dargestellt werden. Manche Dienste bieten außerdem eine Standardsitzung ohne eigenen Namen. Das sind verschiedene Verfahren der Zuweisungsverwaltung. Es gibt deshalb kein allgemeingültiges Benutzernamenformat und keine einheitliche Portnummer für Sticky-Zugang.

Eine Sticky Session kann mehrere Netzwerkverbindungen umfassen. Das unterscheidet sie vom bloßen Wiederverwenden einer offenen Verbindung: Anfragen innerhalb derselben gewöhnlichen TCP-Verbindung behalten ohnehin deren Ausgangs-IP-Adresse. Um die Adressbeibehaltung über Verbindungen hinweg zu prüfen, beobachten Sie eine neue Verbindung mit denselben Sitzungseinstellungen.

Wenn mehrere Anfragen eine IP-Adresse benötigen

Ein mehrstufiger Browsertest ist ein deutliches Beispiel. Er kann sich anmelden, eine Einstellungsseite öffnen, eine Änderung absenden und das Ergebnis prüfen. Eine gleichbleibende Quell-IP-Adresse vermeidet einen unnötigen Wechsel während des Tests, besonders wenn die Website die Adresse als Teil ihrer Sitzungsprüfungen verwendet.

Auch ein Einkaufs- oder Buchungstest kann auf eine einheitliche regionale Darstellung angewiesen sein. Die Anwendung sucht, wählt eine Option und prüft den nächsten Schritt über denselben Ausgang. So bleibt der Netzwerkstandort zwischen den Schritten gleich. Die Website kann zusätzlich Kontoeinstellungen, Lieferangaben oder Cookies zur Inhaltsauswahl verwenden.

Ein weiterer Fall ist eine Folge von API-Aufrufen, bei der der Zieldienst zusammengehörige Aktionen von derselben Quelladresse erwartet. Die Zuweisung sollte die ganze Folge einschließlich Pausen und Wiederholungsversuchen abdecken. Unabhängige öffentliche Seitenabrufe benötigen dagegen nicht zwangsläufig dieselbe IP-Adresse. Beibehaltung hilft, wenn die Aufgabe Kontinuität verlangt; sie verbessert für sich genommen weder den Ruf der Adresse noch garantiert sie die Anfrageannahme.

Eine Proxysitzung erhält keine Websiteanmeldung

Der Proxydienst kontrolliert die Ausgangsadresse. Die Website verwaltet ihre eigene Sitzung: Anmeldestatus, Warenkorb oder Formularfortschritt. Ein Browser oder HTTP-Client überträgt diesen Zustand gewöhnlich mit Cookies oder Authentifizierungstokens. Beide Systeme verwenden möglicherweise das Wort Sitzung, speichern aber unterschiedliche Informationen.

Eine Anmeldung kann deshalb ablaufen, obwohl die Ausgangs-IP-Adresse gleich bleibt. Das Löschen von Cookies kann die Nutzererkennung der Website entfernen, ohne die Proxyzuweisung zu beeinflussen. Umgekehrt kann eine Website eine gültige Anmeldung nach einem IP-Wechsel akzeptieren. Das hängt von ihren eigenen Regeln ab.

Ein Sitzungsobjekt einer HTTP-Bibliothek speichert häufig Cookies und verwendet Verbindungen erneut. Seine Erstellung aktiviert nicht automatisch Sticky-Zugang beim Proxydienst. Für einen vollständigen Ablauf muss die Anwendung Websitezustand und gewünschte Proxyzuweisung zusammenhalten. Sollen verschiedene Aufgaben keine Cookies teilen, sind weiterhin getrennte Browserprofile oder isolierte Clientzustände nötig.

Was die Sitzungsdauer tatsächlich bedeutet

Zwei unterschiedliche Zeitgeber können als Sitzungsdauer bezeichnet werden. Eine feste Laufzeit begrenzt das Bestehen der Zuweisung ab ihrem Beginn. Ein Inaktivitätslimit begrenzt die Pause seit der letzten berücksichtigten Anfrage. Neue Anfragen können den Inaktivitätszeitgeber neu starten, ohne eine separate feste Laufzeit zu verlängern.

Nehmen Sie zwei Beispielsitzungen mit zehnminütigem Limit. Beide beginnen um 14:00 und erhalten um 14:08 eine weitere Anfrage. Bei fester Laufzeit bleibt das Ende 14:10. Bei einem Inaktivitätslimit verschiebt diese Anfrage die Inaktivitätsgrenze auf 14:18. Dieselbe angegebene Dauer kann während aktiver Aufgaben daher sehr unterschiedliches Verhalten ergeben.

Ein Dienst kann beide Limits durchsetzen. Dann endet die Zuweisung, sobald eines erreicht wird. Der gewöhnliche Standardwert kann auch von der längsten einstellbaren Dauer abweichen. Laufender Datenverkehr kann Inaktivitätsablauf verhindern, hebt aber keine gesonderte maximale Laufzeit auf.

Beim Ablauf endet die Zuweisung zum alten Ausgang. Eine spätere Verbindung kann auch mit demselben Sitzungsnamen eine andere Adresse erhalten. Eine offene Verbindung darf je nach Dienst noch abschließen oder wird geschlossen. Der Zeitgeber überträgt keinen unvollständigen TCP-Austausch auf eine andere IP-Adresse.

Wählen Sie ein Zeitfenster für die gesamte Aufgabe einschließlich langsamer Antworten und erwarteter Pausen. Beginnt ein neuer Ablauf kurz vor dem Ende einer älteren Zuweisung, bleibt weniger Zeit als die eingestellte Dauer vermuten lässt. Anfragen, die nur eine ruhende Sitzung aktiv halten sollen, bleiben echter Datenverkehr und können zum Anfrage- oder Datenkontingent zählen.

Parallele Aufgaben getrennt halten

Benötigen unabhängige Aufgaben jeweils eine stabile Adresse, geben Sie jeder eine eigene Sitzungskennung und behalten Sie sie während ihrer Schritte bei. Ein Prozess, der die nächste Seite lädt, sollte die Aufgabensitzung wiederverwenden, statt pro Anfrage einen neuen Namen zu erzeugen. Auch ein Wiederholungsversuch darf nicht unbemerkt auf fremde Proxyeinstellungen wechseln.

Angenommen, zwei Browsertests laufen gleichzeitig. Der erste nutzt task1, der zweite task2, und jeder behält eigene Cookies. Derselbe Sitzungsname würde eine gemeinsame Zuweisung anfordern, wenn auch die übrigen Einstellungen übereinstimmen. Ein gewöhnlicher neuer Tab erstellt für sich genommen weder getrennte Proxyeinstellungen noch einen separaten Cookiespeicher.

Unterschiedliche Kennungen fordern getrennte Zuweisungen an, garantieren aber nicht allgemein unterschiedliche Ausgangs-IP-Adressen. Eine Zusage verschiedener Adressen ist eine separate Produkteigenschaft. Sticky-Zugang macht einen Ausgang auch nicht exklusiv für Ihr Konto: In einem gemeinsamen Pool können andere Kunden die Adresse weiterhin nutzen.

Sofern unterstützt, können mehrere Verbindungen gleichzeitig dieselbe Sitzung verwenden. Sie teilen deren Ausgang und unterliegen weiterhin den Verbindungs- und Nutzungslimits des Kontos. Zusätzliche Sitzungsnamen erhöhen diese Limits nicht. Prüfen Sie vor dem Gesamtdurchlauf sowohl die Anzahl paralleler Aufgaben als auch die Verbindungen je Aufgabe.

Warum die Adresse früher als erwartet wechseln kann

Ein gültiger Zeitgeber hält keinen ausgefallenen Ausgang funktionsfähig. Ein Residential-Gerät kann offline gehen, eine Mobilfunkverbindung eine andere öffentliche IP-Adresse erhalten oder ein Server unerreichbar werden. Die gewünschte Dauer beschreibt die Zeitregeln der Zuweisung. Sie garantiert allein keine durchgehende Verfügbarkeit des ursprünglichen Ausgangs.

Auf den Ausgangsverlust kann der Dienst auf zwei Arten reagieren: Er wählt Ersatz für spätere Anfragen oder gibt einen Fehler zurück und hält an der Anforderung des ursprünglichen Ausgangs fest. Manche Produkte erlauben die Wahl. Automatischer Ersatz priorisiert einen weiteren Verbindungsaufbau. Ein Fehler ermöglicht der Anwendung, vor dem Fortsetzen mit einer anderen Adresse anzuhalten.

Ein unveränderter Name beweist nicht, dass die übrigen Sitzungseinstellungen gleich geblieben sind. Ein anderes Gateway oder ein geänderter Länderfilter kann eine andere Zuweisung erzeugen. Der Geltungsbereich hängt vom Dienst ab: Eine Sitzung kann zu einem bestimmten Konto, Produkt oder Einstiegsserver gehören, statt unter dem Namen überall verfügbar zu sein.

Wechselt die Adresse während einer Aufgabe, muss der Zustand dieser Aufgabe bewertet werden. Ein rein lesender Schritt lässt sich möglicherweise gefahrlos wiederholen. Eine Bestellung oder Datenänderung verlangt größere Vorsicht: Eine verlorene Antwort beweist keinen Fehlschlag der Aktion. Klären Sie vor einem Neustart oder der Fortsetzung über einen anderen Ausgang, was abgeschlossen wurde.

Wann vorübergehende Kontinuität genügt

Sticky-Zugang passt zu einer Aufgabe mit klarem Anfang und Ende, die nur während dieses Durchlaufs dieselbe IP-Adresse benötigt. Prüfen Sie, ob die Zuweisung erwartete Pausen übersteht, für die ganze Aufgabe reicht und auf einen ausgefallenen Ausgang wie benötigt reagiert. Beziehen Sie eine neue Verbindung nach einer üblichen Pause ein. Aktivität innerhalb einer bereits offenen Verbindung beweist nicht, dass die Zuweisung bei der nächsten Verbindung erhalten bleibt.

Muss dieselbe Adresse auf der Zulassungsliste eines Servers bleiben oder morgen wieder verfügbar sein, verwenden Sie einen Dienst mit fester Zuweisung für diesen Zweck. Ein erneut verwendeter Sticky-Sitzungsname bringt nach Ablauf nicht zuverlässig die frühere Adresse zurück. Vorübergehende Beibehaltung und dauerhaft zugewiesene IP-Adresse erfüllen unterschiedliche Kontinuitätsanforderungen.