Inhalt des Artikels

Kennen Sie das? Kurze Anfragen fliegen wie Schwalben dahin, aber sobald Sie eine große Übertragung starten oder eine gewichtige Datei über einen mobilen Proxy herunterladen, bricht die Verbindung mittendrin ab. Die Datei steht bei 40 Prozent, dann Stille. Den Request erneut zu senden hilft manchmal, manchmal nicht. Und das Ärgste: Die Logs schweigen, der Server scheint zu leben, aber die Daten kommen nicht an. Wenn Sie das kennen, sind Sie hier genau richtig.

Dieser Artikel befasst sich nicht mit Antwortcodes oder der Wiederholungslogik auf HTTP-Ebene (zu 429 und exponentiellem Backoff gibt es separates Material, auf das wir verweisen werden). Hier untersuchen wir die Transportebene: Warum TCP reißt, wer die Verbindung genau abreißt, wie drei verschiedene Timeouts auf dem Weg eines Pakets funktionieren, was MTU und Fragmentierung in Mobilfunknetzen sind und warum ein Basisstationswechsel lange Sitzungen tötet. Und vor allem bauen wir einen Client, der all das übersteht.

Einführung: Download bricht mittendrin ab, kurze Anfragen kommen durch

Warum ist das Thema gerade im Jahr 2026 so aktuell? Weil mobile Proxys zum Arbeitswerkzeug für Scraping, Automatisierung, Tests und die Arbeit mit Marktplätzen geworden sind. Das Mobilfunknetz ist von Natur aus instabiler als eine kabelgebundene Verbindung. Es wurde für einen Menschen mit einem Telefon entwickelt, der eine Seite öffnet, liest und wieder schließt. Es wurde nicht für eine Maschine entwickelt, die eine einzelne TCP-Verbindung zehn Minuten offen hält und darüber ein Gigabyte überträgt.

Daher kommt das Paradoxon, das in der Überschrift dieses Abschnitts steht. Kurze Anfragen kommen durch, weil sie es schaffen, abgeschlossen zu werden, bevor einer der Timeouts greift oder ein Handover (Wechsel zwischen Basisstationen) stattfindet. Lange Operationen leben länger und erhöhen daher die Wahrscheinlichkeit, auf jedes dieser Probleme zu stoßen: Timeout-Leerlauf, Abbruch beim Zellenwechsel, Verlust großer Pakete aufgrund falscher MTU.

Was Sie bis zum Ende erfahren werden:

  • Wie Sie in fünf Minuten herausfinden, wer genau die Verbindung abgerissen hat: Ihr Client, der Proxy, der Betreiber oder der Zielserver.
  • Worin sich TCP Keepalive grundlegend von HTTP Keep-Alive unterscheidet und warum beide Einstellungen nötig sind.
  • Wie Sie die drei Timeouts auf dem Weg messen und den kürzesten finden, der über das Schicksal der Verbindung entscheidet.
  • Warum die MTU in Mobilfunknetzen unter den Standard-1500 Byte liegt und wie ein PMTUD-Fehler aussieht (Symptom: Hänger bei großen Antworten).
  • Fertiger Client-Code in Python und Node mit Range-Download, Aufteilung der Übertragung und korrekten Timeouts.

Wir werden technische Sprache verwenden, aber jeden Begriff verständlich erklären. Los geht's.

Grundlagen: Wie eine Verbindung über einen mobilen Proxy aufgebaut ist

Bevor wir uns mit den Störungen befassen, sollten wir uns auf ein gemeinsames Weltbild einigen. Wenn Sie eine Anfrage über einen mobilen Proxy senden, durchläuft das Paket eine lange Kette. Diese Kette zu verstehen, ist die halbe Miete für die Diagnose.

Der Weg des Pakets vom Client zum Server

Stellen Sie sich den Weg eines Pakets vor. Es geht durch mehrere Stationen, und an jeder Station kann es aufgehalten oder verloren gehen:

  1. Ihr Client – das Programm, das die Anfrage stellt. Es hat eigene Timeouts und Socket-Einstellungen.
  2. Proxy-Server – nimmt Ihre Verbindung an und öffnet eine eigene zum Ziel. Oft sind das zwei verschiedene TCP-Verbindungen, die zusammengeklebt sind.
  3. Mobiles Modem und Funkschnittstelle – der schmale und launische Abschnitt. Hier fliegt das Paket per Funkwelle zur Basisstation.
  4. Kernnetz des Betreibers – NAT, Gateways, Systeme zur Priorisierung von Datenverkehr.
  5. Öffentliches Internet – die Backbone-Kanäle bis zum Rechenzentrum des Ziels.
  6. Zielserver – der Endpunkt, der ebenfalls eigene Limits für die Verbindungsdauer hat.

Die wichtigste Erkenntnis: Eine Verbindung über einen Proxy ist keine einzelne Röhre, sondern mindestens zwei. Der Client hält die Verbindung zum Proxy, der Proxy hält die Verbindung zum Ziel. Ein Bruch kann auf jedem dieser Segmente auftreten, und die Symptome werden unterschiedlich sein.

Was ist eine Session und warum ist sie fragil?

Eine TCP-Verbindung ist ein virtueller Kanal. Physisch gibt es kein Kabel zwischen Ihnen und dem Server: Es ist eine Vereinbarung zwischen zwei Parteien, dass sie nummerierte Bytes austauschen. Solange sich beide Seiten die Nummern und den Zustand merken, lebt die Verbindung. Sobald eine Seite den Zustand vergisst (NAT neu gestartet, Timeout abgelaufen, Zelle gewechselt), ist die Verbindung faktisch tot, auch wenn die andere Seite das möglicherweise noch lange nicht weiß.

Genau das erzeugt die tückischen halboffenen Verbindungen (Half-Open): Eine Seite hält den Kanal für lebendig und wartet auf Daten, während die zweite längst alles vergessen hat. Der Client hängt fest, keine Fehlermeldung kommt, die Zeit vergeht. Kommt Ihnen das bekannt vor?

Drei Ebenen, auf denen Probleme auftreten

  • Funkebene – Paketverluste, Verzögerungen, Zellenwechsel. Die Natur des Mobilfunks.
  • Netzwerkebene – NAT-Timeouts des Betreibers, MTU, Fragmentierung.
  • Anwendungsebene – HTTP-Server-Timeouts von Proxy und Ziel, Limits für die Größe des Antwortkörpers.

Im Folgenden gehen wir jede Ebene durch und lernen, die eine von der anderen zu unterscheiden.

Tiefer Einstieg: Wer kann die Verbindung abbrechen und wie erkennen Sie, wer es ist?

Dies ist der wichtigste Diagnoseabschnitt. Solange Sie den Übeltäter nicht kennen, schießen Sie im Dunkeln. Die gute Nachricht: Jeder Übeltäter hat seine eigene Handschrift.

Die vier Verdächtigen

1. Ihr Client. Der häufigste und am meisten unterschätzte Übeltäter. HTTP-Bibliotheken haben Standard-Timeouts, die Sie möglicherweise nicht bemerkt haben. Zum Beispiel Timeout für die Gesamtzeit der Anfrage, Timeout für das Lesen vom Socket, Timeout für Inaktivität. Wenn Ihr Client die Verbindung selbst abgerissen hat, erscheint im Log ein Fehler wie read timeout oder socket timeout mit einem Hinweis auf Ihren Code im Stacktrace.

2. Proxy-Server. Der Proxy hat seine eigenen Limits: maximale Lebensdauer der Verbindung, Idle-Timeout, maximale Antwortgröße. Wenn der Proxy die Verbindung abreißt, erhalten Sie oft einen plötzlichen connection reset oder ein Schließen ohne Antwort mitten in der Übertragung des Rumpfes. Dabei funktioniert der Ping zum Proxy und kurze Anfragen funktionieren.

3. Mobilfunkbetreiber. Der unsichtbarste. Die NAT-Tabellen des Betreibers haben eine Lebensdauer für jeden Eintrag. Wenn über eine Verbindung lange kein Datenverkehr fließt, löscht der Betreiber den NAT-Eintrag, und nachfolgende Pakete haben keinen Zielort mehr. Symptom: Die Verbindung hängt genau während Pausen, nicht während aktiver Übertragung. Auch beim Basisstationswechsel ist der Betreiber der Übeltäter.

4. Zielserver. Er hat seine eigenen Keep-Alive-Einstellungen und Limits. Viele Server schließen die Verbindung nach N Anfragen oder nach T Sekunden. Symptom: Der Server sendet den Header Connection: close oder beendet die Verbindung sauber (FIN) statt sie abzureißen (RST).

Diagnose anhand von Symptomen: Tabelle der Handschriften

Wir gehen die charakteristischen Anzeichen durch, damit Sie den Übeltäter in Minuten identifizieren können.

  • Abbruch genau in Pausen, während aktiver Übertragung ist alles gut – fast sicher ein NAT-Timeout des Betreibers oder ein Idle-Timeout des Proxys. Behandelbar durch Keepalive-Traffic.
  • Abbruch immer bei ungefähr derselben Datenmenge (z.B. um die 8 oder 10 Megabyte) – Limit für die Antwortgröße beim Proxy oder Server. Behandelbar durch Teilung per Range.
  • Abbruch immer nach ungefähr derselben Zeit (z.B. genau 60 oder 300 Sekunden) – ein hartes Limit für die Verbindungsdauer. Suchen Sie den kleinsten der Timeouts.
  • Hänger genau bei großen Antworten, kleine gehen durch – klassischer PMTUD-Fehler und MTU-Problem. Dazu weiter unten ein ganzer Abschnitt.
  • Zufällige Abbrüche ohne Bezug zu Volumen und Zeit, häufiger bei Bewegung – Basisstationswechsel, Handover, Verschlechterung des Funksignals.
  • Sofortiges RST beim Versuch, Daten zu senden – die Verbindung ist auf einer Seite bereits tot (half-open) oder der Proxy setzt aktiv zurück.

Werkzeuge für die erste Diagnose

Um FIN (höfliches Schließen) von RST (grobem Zurücksetzen) zu unterscheiden und zu verstehen, auf welchem Segment es reißt, setzen Sie Folgendes ein:

  • Logging auf Socket-Ebene – notieren Sie den genauen Zeitpunkt des Abbruchs, die Anzahl der übertragenen Bytes und den Ausnahmetyp.
  • Verkehrsanalyse – ein Paket-Erfassungstool zeigt, wer RST oder FIN gesendet hat. Wenn RST von der Proxy-Adresse kommt, ist der Proxy schuld. Wenn die Verbindung einfach ohne Pakete verstummt, ist ein Zwischenknoten (Betreiber) schuld.
  • Kontrollmessungen – wiederholen Sie denselben Vorgang direkt über eine kabelgebundene Verbindung. Wenn alles stabil ist und über den mobilen Proxy reißt, liegt das Problem im mobilen Segment.

Eine Beobachtung des Autors: In 70 Prozent der Fälle, die wir analysiert haben, war der Übeltäter ein NAT-Timeout des Betreibers oder ein Standard-Idle-Timeout, keineswegs der Proxy oder der Server. Die Leute geben dem Proxy die Schuld, dabei liegt die Lösung in ein paar Zeilen Socket-Konfiguration.

Keep-alive und Idle-Timeout: Drei Timeouts auf dem Weg, der kleinste gewinnt

Hier ist ein grundlegendes Prinzip, das Sie sich einprägen sollten: Auf dem Weg eines Pakets gibt es mehrere unabhängige Inaktivitäts-Timeouts, und der kürzeste davon entscheidet über das Schicksal der Verbindung. Es ist wie bei einer Kette: Sie reißt an der schwächsten Stelle.

Wo die Timeouts leben

  1. Idle-Timeout Ihres Clients. Wie lange Ihr Programm bereit ist, auf Daten zu warten, ohne etwas zu empfangen. Standardmäßig reicht das bei verschiedenen Bibliotheken von 30 Sekunden bis unendlich.
  2. Idle-Timeout des Proxys. Wie lange der Proxy eine inaktive Verbindung offen hält. Typische Werte sind 60 bis 300 Sekunden.
  3. NAT-Timeout des Betreibers. Wie lange das Netzwerk einen Adressumsetzungs-Eintrag ohne Verkehr speichert. Für TCP sind das oft 300-600 Sekunden, aber für UDP und in Stoßzeiten auch 30-60 Sekunden.
  4. Keep-alive-Timeout des Zielservers. Wie lange der Server eine Verbindung zwischen Anfragen hält. Oft 5-75 Sekunden.

Stellen Sie sich vor, der Client ist bereit, 120 Sekunden zu warten, der Proxy reißt nach 90, und der Betreiber räumt NAT nach 60 auf. Wer gewinnt? Der Betreiber. Die Verbindung stirbt in der 60. Sekunde der Inaktivität, und weder Client noch Proxy erfahren es sofort.

So messen Sie den kleinsten Timeout

Die Methode ist einfach und zuverlässig. Wir stellen eine Verbindung her, machen eine Anfrage, dann schweigen wir und warten, wobei wir die Zeit bis zum Abbruch messen. Wir wiederholen das mehrere Male, um Zufälle auszuschließen.

  1. Öffnen Sie eine Verbindung über den Proxy zu einem Testserver, der Keep-alive unterstützt.
  2. Machen Sie eine kurze Anfrage und erhalten Sie die Antwort.
  3. Schließen Sie die Verbindung nicht. Starten Sie den Timer.
  4. Prüfen Sie regelmäßig (einmal pro Sekunde), ob die Verbindung lebt, indem Sie versuchen, im nicht blockierenden Modus aus dem Socket zu lesen.
  5. Notieren Sie den Moment, in dem RST, FIN eintrifft oder der Socket nicht mehr lesbar ist.

Führen Sie die Messung dreimal durch. Wenn der Abbruch stabil bei etwa 60 Sekunden erfolgt, ist das Ihre Inaktivitätsgrenze. Das bedeutet, Sie müssen Keepalive-Traffic häufiger senden als einmal pro 60 Sekunden, mit gutem Puffer – zum Beispiel alle 20-25 Sekunden.

Strategie, um den Idle-Timeout zu besiegen

Da der kleinste Timeout alles entscheidet, ist unsere Aufgabe, die Verbindung nicht länger als dieses Limit untätig zu lassen. Zwei Ansätze:

  • Die Verbindung mit nützlichem Datenverkehr füllen – bei aktiver Datenübertragung greifen die Idle-Timeouts nicht, weil es keine Untätigkeit gibt. Deshalb leidet ein kontinuierlicher Download selten unter Idle-Timeout, dafür aber unter Limits für Größe und Lebensdauer.
  • Keepalive-Proben in Pausen senden – wenn keine nützlichen Daten anstehen (z.B. wenn Sie auf die Generierung eines Berichts auf dem Server warten), müssen Sie die Verbindung mit künstlichem Traffic am Leben halten. Hier kommen die beiden Keep-alive-Mechanismen ins Spiel, die wir uns gleich getrennt ansehen.

TCP Keepalive versus HTTP Keep-Alive: verschiedene Mechanismen, beide nötig

In der Branche entsteht enormes Durcheinander wegen der ähnlichen Namen. TCP Keepalive und HTTP Keep-Alive sind völlig verschiedene Dinge, die auf verschiedenen Ebenen arbeiten. Und für einen stabilen mobilen Client brauchen Sie beide.

HTTP Keep-Alive: Wiederverwendung der Verbindung

HTTP Keep-Alive (auch persistente Verbindung genannt) bedeutet, nicht für jede Anfrage eine neue TCP-Verbindung öffnen zu müssen. Stattdessen bedient eine Verbindung mehrere Anfragen nacheinander. Das ist die Anwendungsebene.

Warum ist das für Mobilfunknetze wichtig? Eine neue TCP-Verbindung über ein Mobilfunknetz aufzubauen ist teuer. Der Drei-Wege-Handshake plus, wenn Verschlüsselung verwendet wird, noch ein TLS-Handshake. Über den Funkkanal mit hohen Latenzen kann das Hunderte von Millisekunden dauern. Durch die Wiederverwendung der Verbindung sparen Sie diese Zeit bei jeder weiteren Anfrage.

Aber! HTTP Keep-Alive hilft in keiner Weise gegen den NAT-Timeout des Betreibers in Pausen. Es erlaubt nur, die Verbindung für die nächste Anfrage offen zu halten, erzeugt aber selbst keinen Verkehr in den Zwischenzeiten.

TCP Keepalive: Puls auf Transportebene

TCP Keepalive ist ein Mechanismus des TCP-Protokolls selbst. Das Betriebssystem sendet regelmäßig ein leeres Dienstpaket (Keepalive-Probe), um zu prüfen, ob die Gegenseite lebt, und gleichzeitig die Einträge in den NAT-Tabellen unterwegs aufzufrischen. Das ist die Ebene des OS-Kerns.

Genau TCP Keepalive ist Ihre wichtigste Waffe gegen NAT-Timeouts des Betreibers und Idle-Timeouts von Zwischenknoten. Jede Probe ist Verkehr, der den Inaktivitätszähler auf dem gesamten Pfad zurücksetzt.

TCP Keepalive hat drei Schlüsselparameter:

  • Keepalive idle (auch keepalive time) – nach wie vielen Sekunden Inaktivität beginnen, Proben zu senden. Standard in den meisten Betriebssystemen sind 7200 Sekunden, also zwei Stunden. Eine Katastrophe für Mobilfunknetze.
  • Keepalive interval – Intervall zwischen den Proben, wenn keine Antwort kommt.
  • Keepalive count (probes) – wie viele unbeantwortete Proben in Folge als Zeichen für eine tote Verbindung gewertet werden.

Empfohlene Werte für Mobilfunknetze

Die Standard-Zwei-Stunden sind absolut ungeeignet. Der Betreiber räumt NAT lange vor der ersten Probe auf. Hier sind praxisbewährte Werte:

  • Keepalive idle: 15-25 Sekunden. Wir beginnen nach kurzer Pause mit Proben, um den aggressivsten NAT-Timeout garantiert zu übertreffen.
  • Keepalive interval: 10-15 Sekunden. Wenn eine Probe nicht ankommt, wiederholen wir nach kurzem Intervall.
  • Keepalive count: 3-4. Nach drei bis vier unbeantworteten Proben erklären wir die Verbindung für tot und bauen sie neu auf, statt endlos zu hängen.

Diese Kombination bringt einen doppelten Vorteil: Die Verbindung reißt in Pausen nicht durch den Betreiber, und falls sie doch stirbt (z.B. wegen eines Handovers), erfährt der Client das nach 45-70 Sekunden statt nach Stunden. Die schnelle Erkennung einer toten Verbindung ist die halbe Robustheit.

Warum beide Einstellungen nötig sind

Eine Analogie: HTTP Keep-Alive ist, als würden Sie den Konferenzraum für den ganzen Tag reservieren, um nicht jedes Mal neu buchen zu müssen. TCP Keepalive bedeutet, regelmäßig in den Raum zu gehen, damit der Hausmeister nicht denkt, er sei leer, und ihn abschließt. Reserviert, aber nicht reingegangen – wird abgeschlossen. Gehen Sie rein, buchen aber jedes Mal neu – verlieren Sie Zeit. Sie brauchen beides.

MTU und Fragmentierung: Warum Pakete in Mobilfunknetzen kleiner sind

Kommen wir zur am meisten unterschätzten Ursache von Hängern. Wenn bei Ihnen kleine Antworten durchkommen, große aber komplett hängen bleiben, liegt das mit 90-prozentiger Wahrscheinlichkeit an MTU und defektem PMTUD.

Was ist MTU einfach erklärt?

MTU (Maximum Transmission Unit) ist die maximale Größe eines einzelnen Pakets, das ohne Aufteilung in ein Netzwerk gesendet werden kann. Im klassischen Ethernet sind das 1500 Byte. Stellen Sie sich das als Breite einer Tür vor: Möbel, die breiter als die Tür sind, müssen auseinandergenommen werden, um sie durchzubekommen.

Das Problem: In Mobilfunknetzen liegt die effektive MTU oft unter 1500. Der Grund ist Einkapselung. Mobilfunkverkehr wird in zusätzliche Protokoll-Hüllen im Netz des Betreibers verpackt. Jede Hülle fügt eigene Header-Bytes hinzu, sodass für die Nutzdaten weniger Platz bleibt. Die tatsächlich nutzbare MTU liegt in Mobilfunknetzen häufig im Bereich von 1400-1480 Byte, manchmal auch darunter.

Was ist PMTUD und warum bricht es?

PMTUD (Path MTU Discovery) ist ein Mechanismus zur automatischen Ermittlung der maximalen Paketgröße auf dem gesamten Pfad. So funktioniert es: Der Client sendet ein großes Paket mit dem Flag Don't Fragment (nicht fragmentieren). Wenn unterwegs ein Knoten mit kleinerer MTU auftaucht, verwirft dieser Knoten das Paket und sendet eine spezielle ICMP-Nachricht mit dem Hinweis 'Fragmentierung erforderlich' und der zulässigen Größe zurück. Der Client erhält den Hinweis und verkleinert die Pakete.

Ein schönes Schema. Aber es hält an einer zerbrechlichen Bedingung: Die ICMP-Nachrichten müssen zum Client zurückkommen. In der Realität blockieren viele Netzwerke, Firewalls und Sicherheitseinstellungen ICMP komplett. Und genau hier passiert die Katastrophe namens PMTUD-Black-Hole (schwarzes Loch).

Wie ein PMTUD-Fehler aussieht: Anatomie eines Hängers

Das Szenario ist klassisch und sehr charakteristisch:

  1. Der Client stellt eine Verbindung her. Der Handshake läuft mit kleinen Paketen – alles gut.
  2. Der Client sendet eine kurze Anfrage – das kleine Paket kommt durch, die Antwort kommt. Kleine Antworten funktionieren.
  3. Der Server beginnt, eine große Antwort mit voll großen Paketen von 1500 Byte und dem Flag Don't Fragment zu senden.
  4. Irgendwo auf dem Weg verwirft ein Knoten mit MTU 1400 diese Pakete, weil sie zu groß sind und nicht fragmentiert werden dürfen.
  5. Der Knoten sendet ICMP 'fragmentation needed' zurück, aber dieses ICMP wird von einer Firewall blockiert und kommt nicht an.
  6. Der Server erhält keinen Hinweis, sendet weiterhin dieselben großen Pakete, die wieder verworfen werden. Eine Endlosschleife.
  7. Ergebnis: Kleine Pakete (Header, ACKs) kommen durch, aber die Antwortdaten nicht. Die Verbindung hängt mitten in einer großen Antwort fest.

Wie Sie das MTU-Problem behandeln

Es gibt mehrere Lösungsebenen, von der Anwendung bis zum Netzwerk:

  • MSS Clamping. Die zuverlässigste Methode auf Netzwerkebene. MSS (Maximum Segment Size) ist die maximale TCP-Segmentgröße, über die sich die Parteien ganz zu Beginn beim Handshake einigen. Wenn Sie MSS explizit so begrenzen, dass das resultierende Paket in die reale MTU passt (z.B. MSS 1360-1400), sendet der Server von Anfang an Pakete in der richtigen Größe, und es ist kein ICMP nötig. Das heilt das schwarze Loch an der Wurzel.
  • MTU des Interfaces verringern. Wenn Sie das Modem oder die Maschine verwalten, über die der Verkehr läuft, können Sie die MTU des Interfaces auf 1400 oder niedriger setzen. Dann sind alle ausgehenden Pakete von vornherein nicht größer als die sichere Größe.
  • ICMP erlauben. Wenn Sie Kontrolle über die Firewalls auf dem Pfad haben, erlauben Sie ICMP-Nachrichten vom Typ 'fragmentation needed'. Dann funktioniert das reguläre PMTUD wie vorgesehen.
  • Anwendungsebene. Wenn Sie eine große Datei herunterladen, teilen Sie sie über Range-Anfragen in Teile. Jeder Teil ist eine separate kurze Übertragung, die mit geringerer Wahrscheinlichkeit auf Probleme mit großen Strömen stößt. Dazu später mehr im praktischen Abschnitt.

Wichtige Erkenntnis: Selbst wenn Sie das Netzwerk nicht verwalten, können Sie fast immer über die Verbindungseinstellungen oder die Parameter des Proxy-Dienstes Einfluss auf MSS nehmen. Ein guter mobiler Proxy-Anbieter konfiguriert bereits korrektes MSS Clamping auf seiner Seite und erspart Ihnen schwarze Löcher. Das ist eines der Qualitätskriterien eines Dienstes.

Basisstationswechsel und Netzübergänge: Warum TCP das nicht übersteht

Jetzt zur grundlegendsten Inkompatibilität. Das Mobilfunknetz wurde für Mobilität geschaffen, TCP nicht. Und das ist ein Konflikt auf Architekturebene.

Warum TCP an die Adresse gebunden ist

Eine TCP-Verbindung wird eindeutig durch ein Vierer-Tupel definiert: Quelladresse, Quellport, Zieladresse, Zielport. Das ist wie die Postanschrift der Verbindung. Wenn sich auch nur ein Element ändert, ist es bereits eine andere Verbindung und die alte wird ungültig.

Und was passiert in einem Mobilfunknetz? Bei einigen Szenarien des Basisstationswechsels oder beim Übergang zwischen Technologien (z.B. zwischen verschiedenen Generationen oder zwischen Netzen) kann sich die externe IP-Adresse des mobilen Endpunkts ändern. Und hier ist TCP machtlos: Es kann eine Verbindung mit einer neuen Adresse nicht fortsetzen. Die alte Verbindung ist einfach tot. Alle Daten, die unterwegs waren, sind verloren.

Handover: nicht immer fatal, aber immer riskant

Fairerweise muss man sagen: Moderne Netze versuchen, das Handover nahtlos zu gestalten und beim Zellenwechsel dieselbe IP beizubehalten. Oft gelingt das, und Sie merken den Wechsel nicht. Aber manchmal kommt es zu einem IP-Wechsel, einem kurzen Funkabriss von ein bis zwei Sekunden oder einem Anstieg von Paketverlusten. Bei einer kurzen Anfrage merken Sie das nicht. Bei einer zehnminütigen Sitzung ist es eine Lotterie, an der Sie jedes Mal teilnehmen.

Symptome eines Abbruchs beim Handover

  • Die Abbrüche haben zufälligen Charakter und sind weder an die Datenmenge noch an die Zeit gebunden.
  • Die Abbruchhäufigkeit steigt, wenn sich das Gerät physisch bewegt (typisch für mobile Proxys auf echten SIM-Karten).
  • Nach einem Abbruch lässt sich problemlos eine neue Verbindung aufbauen – das Netz lebt ja, nur die konkrete alte Verbindung ist gestorben.

Was tun: Akzeptieren und Robustheit aufbauen

Den IP-Wechsel auf TCP-Ebene zu bekämpfen ist unmöglich. Aber Sie können einen Client bauen, für den ein Verbindungsabbruch ein normaler Zustand ist und kein Notfall. Die Philosophie ist einfach: Eine Verbindung über ein Mobilfunknetz ist per Definition ephemer, und der Client muss in der Lage sein, sie nahtlos neu aufzubauen und dort weiterzumachen, wo er aufgehört hat.

Konkrete Techniken, die wir im Code umsetzen:

  • Idempotente Operationen. Gestalten Sie Anfragen so, dass sie sicher wiederholt werden können. Ein Download per Range ist idempotent: Eine erneute Anfrage desselben Byte-Bereichs liefert dasselbe Ergebnis.
  • Weiterladen statt neu laden. Bei einem Abbruch starten Sie die Datei nicht neu, sondern machen beim letzten empfangenen Byte weiter. Das spart Datenvolumen und Zeit.
  • Schnelle Erkennung toter Verbindungen. Mit aggressivem TCP Keepalive, wie oben beschrieben, erfahren Sie innerhalb von Sekunden von einer toten Verbindung, nicht nach Minuten.
  • Kurze Transaktionen. Je kürzer eine einzelne Übertragung ist, desto geringer die Chance, dass genau sie von einem Handover erwischt wird. Eine große Übertragung in Teile aufzuteilen ist eine direkte Folge dieses Prinzips.

Praxis in Python: Stabiler Client mit Weiterladen und Timeouts

Genug Theorie, lasst uns bauen. Wir beginnen mit Python. Wir erstellen einen Client, der: TCP Keepalive konfiguriert, sinnvolle Timeouts setzt, eine Datei über Range in Teilen herunterlädt und nach einem Abbruch weiterladen kann.

Schritt 1: TCP Keepalive am Socket konfigurieren

Standard-HTTP-Bibliotheken setzen aggressives Keepalive nicht von Haus aus. Sie müssen bis zum Socket vordringen. In der requests-Ökosphäre geschieht das über einen eigenen Transport-Adapter, der die Socket-Optionen setzt: Keepalive aktivieren, Idle 20 Sekunden, Interval 10 Sekunden, Count 3. Auf Beschreibungsebene sieht die Logik so aus: Wir registrieren einen Adapter, der beim Aufbau der Verbindung die gewünschten Parameter auf niedriger Ebene setzt.

Der sinnvolle Teil der Konfiguration in Pseudocode ausgedrückt: Option SO_KEEPALIVE aktivieren, dann TCP_KEEPIDLE auf 20, TCP_KEEPINTVL auf 10 und TCP_KEEPCNT auf 3 setzen. Die Namen der Optionen unterscheiden sich leicht zwischen Betriebssystemen, deshalb werden sie im Produktionsbetrieb je nach Plattform ausgewählt.

Schritt 2: Sinnvolle Timeouts

Die wichtigste Regel: Setzen Sie Timeouts immer explizit und trennen Sie Verbindungs-Timeout und Lese-Timeout. Ein Standard ohne Timeout ist eine Falle, bei der der Client auf einer halboffenen Verbindung für immer hängen bleibt.

  • Connect-Timeout: 10 Sekunden. Der Verbindungsaufbau über ein Mobilfunknetz ist langsamer, aber 10 Sekunden reichen mit Puffer.
  • Read-Timeout: 30 Sekunden. Das ist ein Timeout für Inaktivität zwischen Datenportionen, nicht für die gesamte Übertragung. Wenn in 30 Sekunden kein Byte ankommt, betrachten wir die Verbindung als problematisch.
  • Gesamtbudget der Operation kontrollieren Sie separat auf der Ebene der Weiterladen-Logik, nicht mit einem einzigen riesigen Timeout für die gesamte Anfrage.

Schritt 3: Download per Range mit Weiterladen

Die Idee des Algorithmus: Wir öffnen die Zieldatei zum Schreiben. Wir ermitteln die Größe des bereits Heruntergeladenen (falls die Datei teilweise existiert). Wir fordern den verbleibenden Bereich über den Header Range: bytes von der aktuellen Position bis zum Ende an. Wir schreiben den Stream in die Datei, während er eintrifft. Wenn wir einen Abbruch fangen (Leseausnahme, Verbindungsabbruch), geraten wir nicht in Panik: Wir schauen erneut nach, wie viele Bytes bereits auf der Platte liegen, und wiederholen die Anfrage mit einer neuen Startposition. Das machen wir so lange, bis die Datei vollständig angekommen ist.

Schritt für Schritt die Logik in Worten:

  1. Ermitteln Sie die Gesamtgröße der Datei über eine Header-Anfrage (HEAD oder GET mit Range: bytes=0-0, um Content-Range zu lesen).
  2. Prüfen Sie die lokale Größe des bereits heruntergeladenen Teils.
  3. Wenn die lokale Größe der Gesamtgröße entspricht, ist die Datei fertig – wir beenden.
  4. Andernfalls erstellen Sie eine Anfrage mit Range ab der lokalen Größe.
  5. Lesen Sie die Antwort in Portionen von 64-256 Kilobyte und schreiben Sie sie in die Datei.
  6. Bei erfolgreichem Abschluss prüfen Sie die Integrität (Größe, wenn möglich Prüfsumme).
  7. Bei einem Abbruch erhöhen Sie den Versuchszähler, machen eine kurze Pause und kehren zu Schritt 2 zurück.
  8. Begrenzen Sie die maximale Anzahl der Versuche auf Transportebene (z.B. 5-8), um bei einem systemischen Problem nicht endlos zu rotieren.

Ein wichtiger Punkt: Stellen Sie sicher, dass der Server Range unterstützt. Anzeichen sind der Header Accept-Ranges: bytes in der Antwort und der Code 206 Partial Content bei einer Range-Anfrage. Wenn der Server 200 liefert und Range ignoriert, ist kein Weiterladen möglich, und Sie müssen komplett laden – dann sind Keepalive und korrektes MSS besonders wichtig.

Schritt 4: Große Uploads aufteilen

Wenn Sie nicht herunterladen, sondern eine große Menge hochladen (z.B. Daten senden oder einen großen Bericht empfangen), wenden Sie dasselbe Prinzip der Aufteilung an. Teilen Sie die Aufgabe in Seiten oder Chunks fester Größe. Jeder Chunk ist eine separate kurze Transaktion mit eigener Fehlerbehandlung. Führen Sie ein Fortschrittsprotokoll: Welche Chunks bereits bestätigt sind. Bei einem Abbruch wiederholen Sie nur die nicht bestätigten. Das macht aus einer einzigen fragilen zehnminütigen Operation eine Serie robuster kurzer Vorgänge.

Was die Wiederholungsstrategien bei Server-Antwortcodes betrifft, betrachten wir sie hier nicht, weil das das Thema eines separaten Artikels über 429 und exponentiellen Backoff ist, den Sie sich nach diesem hier ansehen sollten. Unser Fokus liegt auf dem Transport: Abbruch, Timeout, Größe.

Praxis in Node.js: Stabiler HTTP-Agent und Streaming

Jetzt dieselben Prinzipien im Node.js-Ökosystem. Hier spielt das Agent-Objekt, das den Verbindungspool verwaltet, eine zentrale Rolle.

Schritt 1: Agent mit Keep-Alive konfigurieren

In Node wird ein HTTP- oder HTTPS-Agent mit aktiviertem KeepAlive erstellt. Der Parameter keepAlive: true zwingt den Agenten, Verbindungen wiederzuverwenden (das ist die HTTP-Ebene). Zusätzlich wird keepAliveMsecs gesetzt – das Intervall, in dem TCP-Keepalive-Proben auf Socket-Ebene gesendet werden. Für Mobilfunknetze setzen Sie keepAliveMsecs auf etwa 15000-20000 Millisekunden, um den NAT-Timeout des Betreibers zu übertreffen. Begrenzen Sie außerdem maxSockets und maxFreeSockets, um keine unnötigen Verbindungen zu erzeugen.

Schritt 2: Timeouts auf verschiedenen Ebenen

In Node werden Timeouts an mehreren Stellen gesetzt, und es ist wichtig, keinen zu vergessen:

  • Timeout für den Verbindungsaufbau – über eine Option an der Anfrage oder über den Event-Handler der Socket-Verbindung.
  • Socket-Idle-Timeout – eine Methode, die einen Socket-Timeout setzt. Wenn er auslöst, müssen Sie den Socket explizit zerstören und das als Abbruch behandeln. Node schließt den Socket bei einem Timeout nicht automatisch, sondern sendet nur ein Event – das wird oft vergessen, und die Verbindung hängt weiter.
  • Behandlung der Events error und close an Anfrage und Socket – jedes davon sollte zu einer kontrollierten Wiederholungslogik führen.

Die empfohlenen Werte sind analog zu Python: Connect etwa 10 Sekunden, Socket-Idle etwa 30 Sekunden, Keepalive-Proben alle 15-20 Sekunden.

Schritt 3: Download-Streaming mit Weiterladen

In Node arbeitet man natürlich mit Streams. Die Weiterladen-Logik ist dieselbe wie in Python: lokale Dateigröße prüfen, Schreibstream im Anhängemodus öffnen, Anfrage mit Range-Header ab der aktuellen Größe erstellen, Handler für die Events data, end und error registrieren. Bei data schreiben wir den Chunk in die Datei. Bei end prüfen wir, ob die Datei vollständig erhalten wurde. Bei error oder vorzeitigem close, wenn weniger als erwartet empfangen wurde, initiieren wir einen erneuten Versuch ab der neuen Position.

Der Schlüsselpunkt zur Robustheit in Node ist die korrekte Behandlung des vorzeitigen Stream-Endes. Das end-Event kann auch dann kommen, wenn nicht alles empfangen wurde, weil die Verbindung abgebrochen ist. Gleichen Sie daher immer die tatsächlich empfangene Menge mit der erwarteten aus dem Header Content-Length oder Content-Range ab. Verlassen Sie sich nicht nur auf das Auslösen von end.

Schritt 4: Wrapper für Wiederholungsversuche auf Transportebene

Verpacken Sie die gesamte Download-Operation in eine Schleife mit begrenzter Anzahl von Versuchen. Zwischen den Versuchen liegt eine kurze Pause (bei Transportabbrüchen reichen 1-3 Sekunden, weil die Ursache keine Serverüberlastung ist, sondern ein Netzwerkereignis). Zählen Sie die Versuche. Wenn das Limit erschöpft ist, werfen Sie den Fehler nach oben mit diagnostischen Informationen: wie viele Bytes empfangen wurden, welche Art von Fehler auftrat, wie viele Versuche gemacht wurden. Diese Diagnose ist bei der Incident-Analyse unbezahlbar.

Häufige Fehler: Was Sie nicht tun sollten

Wir gehen Anti-Pattern durch, die wir regelmäßig in fremdem Code sehen. Vermeiden Sie sie – und die Hälfte der Probleme verschwindet.

Fehler 1: Keine expliziten Timeouts

Der häufigste und schmerzhafteste Fehler. Ein Client ohne Timeout hängt auf einer halboffenen Verbindung für immer. Der Thread ist blockiert, die Ressource wird nicht freigegeben, und Sie denken, die Operation läuft noch. Setzen Sie Timeouts immer explizit. Kein Timeout ist nicht unendliche Geduld, sondern eine versteckte Bombe.

Fehler 2: Sich auf das Standard-TCP-Keepalive verlassen

Die Standard-Zwei-Stunden machen TCP Keepalive für Mobilfunknetze nutzlos. Viele aktivieren SO_KEEPALIVE und beruhigen sich, ohne zu ahnen, dass die erste Probe erst nach 7200 Sekunden rausgeht, wenn der Betreiber längst alles aufgeräumt hat. Setzen Sie idle, interval und count explizit.

Fehler 3: Nach jedem Abbruch die ganze Datei neu laden

Ein Abbruch bei 95 Prozent und ein kompletter Neustart von null ist nicht nur verlorene Zeit, sondern auch unnötiger Verbrauch von mobilem Datenverkehr, der bei Proxys in der Regel abgerechnet wird. Das Weiterladen per Range ist für alle größeren Downloads Pflicht.

Fehler 4: MTU und MSS ignorieren

Menschen kämpfen monatelang mit Hängern bei großen Antworten, probieren Timeouts und Proxys durch, dabei ist die Ursache ein PMTUD-Schwarzes-Loch. Wenn große Antworten hängen und kleine durchgehen, prüfen Sie zuerst MTU und konfigurieren Sie MSS Clamping. Das spart Ihnen Wochen.

Fehler 5: Transportabbrüche mit Serverantworten verwechseln

Ein Transportabbruch (RST, Lese-Timeout, toter Socket) und eine Serverantwort mit Fehlercode sind verschiedene Situationen mit unterschiedlichen Reaktionsstrategien. Bei Transportabbrüchen sind schnelle Wiederholungen mit kurzer Pause und Weiterladen angebracht. Bei Serverantworten mit Codes wie 429 ist exponentieller Backoff nötig – und das ist Thema eines eigenen Artikels. Vermischen Sie diese zwei Ebenen nicht in einem einzigen Handler.

Fehler 6: Zu aggressive Wiederholungen

Eine Endlosschleife von Wiederholungen ohne Limit wird bei einem systemischen Problem (z.B. wenn der Proxy gar nicht erreichbar ist) zu parasitärem Last. Setzen Sie immer eine Obergrenze für die Anzahl der Versuche und beenden Sie die Operation sinnvoll mit Diagnose.

Fehler 7: Die Integrität des Ergebnisses nicht prüfen

Die Tatsache, dass ein Download abgeschlossen ist, ist nicht gleichbedeutend mit korrekt empfangenen Daten. Ein Abbruch kann eine abgeschnittene Datei hinterlassen, die formal wie abgeschlossen aussieht. Gleichen Sie immer die Größe ab, und bei wichtigen Daten die Prüfsumme.

Fehler 8: Eine Verbindung zu lange halten

Je länger eine Verbindung über ein Mobilfunknetz lebt, desto höher ist die kumulative Wahrscheinlichkeit, auf ein Handover, einen IP-Wechsel oder einen NAT-Timeout zu treffen. Eine regelmäßige Neuverbindung ist keine Schwäche, sondern vernünftige Hygiene. Haben Sie keine Angst davor, Verbindungen neu aufzubauen.

Werkzeuge und Ressourcen für Diagnose und Robustheit

Das richtige Werkzeug spart Stunden. Hier ist ein Arsenal, das Sie griffbereit halten sollten.

Netzwerk- und Paketdiagnose

  • Paketerfassung und -analyse. Ein Paket-Tool ist Ihr Mikroskop. Es zeigt, wer RST gesendet hat, ob ICMP 'fragmentation needed' angekommen ist, welche Größe die Pakete tatsächlich haben und wo der Strom abreißt. Ohne das wird die MTU-Diagnose und die Bestimmung des Abbruchverursachers zum Rätselraten.
  • Tools zur Pfadprüfung. Route-Tracing- und MTU-Prüf-Tools helfen zu verstehen, wo auf dem Pfad die Paketgröße abfällt. Es gibt Modi, die gezielt die maximale durchgehende Paketgröße suchen – genau das, was Sie für die MSS-Konfiguration brauchen.
  • Test-Echo-Server. Ein einfacher Server, der Keep-alive halten kann und Daten in einer bestimmten Größe liefert, ist unverzichtbar, um Idle-Timeouts zu messen und Probleme mit großen Antworten unter kontrollierten Bedingungen zu reproduzieren.

Bibliotheken und Ansätze für den Client

  • HTTP-Clients mit flexibler Socket-Konfiguration. Wählen Sie Bibliotheken, die Zugriff auf die Verbindungsparameter bieten und das Setzen von Timeouts und Keepalive auf niedriger Ebene erlauben.
  • Streaming-Mechanismen. Die Verarbeitung des Antwortkörpers als Stream ist für große Downloads Pflicht – Sie sollten nicht die gesamte Antwort im Speicher halten.
  • Fortschrittsprotokollierung. Ein einfacher Zustandsspeicher (welche Chunks empfangen wurden, wie viele Bytes auf der Platte liegen) macht das Weiterladen zur trivialen Aufgabe.

Qualität der Proxy-Infrastruktur

Eines möchten wir noch betonen: Ein großer Teil der Transportprobleme wird auf der Seite eines qualitativ hochwertigen Proxy-Anbieters gelöst. Korrekt konfiguriertes MSS Clamping, angemessene Idle-Timeouts, stabiler IP-Erhalt beim Handover, transparente Arbeit mit Keep-alive – all das sind Zeichen eines reifen Dienstes. Dienste wie MobileProxy.space entwerfen ihre Infrastruktur unter Berücksichtigung dieser Transport-Nuancen, was dem Client einen Teil des Kopfzerbrechens erspart. Aber selbst mit einem idealen Proxy muss der Client robust sein – denn der Funkkanal ist grundsätzlich unberechenbar.

Fallbeispiele und Ergebnisse: So funktioniert es in der Praxis

Wir gehen einige verallgemeinerte Fälle durch, die typische Situationen und deren Lösungen widerspiegeln. Die Zahlen sind Durchschnittswerte, spiegeln aber reale Größenordnungen wider.

Fall 1: Katalog-Export blieb mitten in der Übertragung hängen

Situation. Ein Team exportierte einen großen Produktkatalog über einen mobilen Proxy mit einer einzigen Anfrage. Die Antwort war etwa 15 Megabyte groß. Sie hing stabil bei etwa 6-8 Megabyte, ohne Fehler, einfach Stille, bis nach einigen Minuten der Gesamt-Timeout auslöste.

Diagnose. Kleine Anfragen funktionierten einwandfrei. Der Paket-Mitschnitt zeigte, dass große Pakete mit dem Flag Don't Fragment gesendet wurden und ICMP 'fragmentation needed' nicht zurückkam. Ein klassisches PMTUD-Schwarzes-Loch.

Lösung. Wir stellten MSS Clamping auf einen Wert ein, der ein Paket innerhalb der realen MTU des Mobilfunknetzes garantiert, und teilten den Export zusätzlich in seitenweise Anfragen zu je 2 Megabyte auf.

Ergebnis. Die Hänger verschwanden vollständig. Die Exportdauer wurde berechenbar, und bei seltenen Abbrüchen wurde nur eine Seite wiederholt, nicht der gesamte Katalog. Die Erfolgsquote der Exporte stieg von rund 40 Prozent auf praktisch 100 Prozent.

Fall 2: Verbindung starb in Wartepausen

Situation. Der Client sendete eine Anfrage zur Generierung eines schweren Berichts. Der Server dachte 90-120 Sekunden nach und sollte dann das Ergebnis liefern. Doch die Verbindung war bereits tot, als der Bericht fertig war.

Diagnose. Die Messung des Idle-Timeout zeigte einen stabilen Abbruch nach etwa 60 Sekunden Inaktivität. Der Übeltäter war der NAT-Timeout des Betreibers: Während des Wartens gab es überhaupt keinen Verkehr.

Lösung. Wir aktivierten TCP Keepalive mit Idle 20 Sekunden und Interval 10. So wurde die Verbindung während des Wartens alle 20 Sekunden durch Dienst-Proben aufgefrischt.

Ergebnis. Die Verbindung überlebte, bis der Bericht fertig war. Abbrüche in Pausen hörten auf. Ein zusätzlicher Bonus: Der Client erkannte wirklich tote Verbindungen nach 45-60 Sekunden statt nach Minuten des Hängens.

Fall 3: Zufällige Abbrüche beim aktiven Scraping

Situation. Langlebige Scraping-Sessions brachen chaotisch ab, ohne Bezug zu Volumen oder Zeit. Besonders häufig zu bestimmten Stunden.

Diagnose. Die Anzeichen deuteten auf einen IP-Wechsel beim Handover hin. Nach einem Abbruch wurde eine neue Verbindung sofort aufgebaut – das Netz lebte.

Lösung. Wir haben den Client auf die Philosophie ephemerer Verbindungen umgestellt: kurze idempotente Transaktionen, Fortschrittsprotokoll, schneller Verbindungsaufbau nach einem Abbruch, begrenzte Wiederholungen mit kurzer Pause.

Ergebnis. Die Abbrüche waren physisch immer noch da (einen IP-Wechsel kann man nicht bekämpfen), aber sie waren kein Problem mehr. Jeder Abbruch kostete nur die Wiederholung einer kurzen Transaktion – Bruchteile einer Sekunde. Die Gesamtzuverlässigkeit des Prozesses stieg dramatisch, und Ingenieure mussten nachts nicht mehr an den Logs wachen.

Allgemeine Schlussfolgerung aus den Fällen

Beachten Sie das Muster: In jedem Fall lag die Lösung nicht in einem Proxy-Wechsel, sondern im Verständnis der Transportebene und der korrekten Client-Konfiguration. Die Diagnose anhand der Symptome führte zum konkreten Übeltäter, und die Behandlung war dann gezielt und schnell.

FAQ: Häufige Fragen zu Verbindungsabbrüchen in Mobilfunknetzen

Warum funktionieren kurze Anfragen über einen mobilen Proxy, aber lange reißen ab?

Weil lange Operationen länger leben und es schaffen, jedes der Transportprobleme zu treffen: Idle-Timeout in Pausen, Limit für die Antwortgröße, Limit für die Lebensdauer der Verbindung, Handover mit IP-Wechsel und das PMTUD-Schwarze-Loch bei großen Paketen. Kurze Anfragen werden abgeschlossen, bevor irgendetwas davon greift. Lösung: Keepalive, MSS konfigurieren und Weiterladen per Range implementieren.

Wie erkenne ich, wer die Verbindung reißt – Proxy, Betreiber oder Server?

Achten Sie auf die Handschrift. Abbrüche in Pausen: NAT-Timeout des Betreibers oder Idle des Proxys. Abbruch bei fester Datenmenge: Größengrenze bei Proxy oder Server. Abbruch nach fester Zeit: Lebensdauerlimit. Hänger bei großen Antworten: MTU und PMTUD. Zufällige Abbrüche bei Bewegung: Handover. Für eine genaue Antwort nutzen Sie den Paket-Mitschnitt: Er zeigt, von welcher Adresse das RST kam und ob ICMP angekommen ist.

Was ist der Unterschied zwischen TCP Keepalive und HTTP Keep-Alive?

HTTP Keep-Alive arbeitet auf der Anwendungsebene und erlaubt es, eine Verbindung für mehrere Anfragen wiederzuverwenden, was den Aufbau einspart. TCP Keepalive arbeitet auf der Ebene des OS-Kerns und sendet regelmäßig Dienst-Proben, die die Verbindung in Pausen am Leben halten und NAT auffrischen. Ersteres spart Zeit bei neuen Anfragen, Letzteres rettet vor Abbrüchen bei Inaktivität. Beide werden benötigt.

Welche TCP-Keepalive-Werte für Mobilfunknetze einstellen?

Ausgangspunkt: Idle 15-25 Sekunden, Interval 10-15 Sekunden, Count 3-4. Diese Kombination übertrifft aggressive NAT-Timeouts der Betreiber und sorgt gleichzeitig für eine schnelle Erkennung toter Verbindungen. Passen Sie die genauen Werte an, indem Sie Ihren Idle-Timeout bei dem konkreten Betreiber und Proxy messen.

Was ist ein PMTUD-Schwarzes-Loch und wie erkenne ich es?

Das ist eine Situation, in der ein Knoten auf dem Pfad zu große Pakete verwirft, seine ICMP-Benachrichtigung über die notwendige Größenreduzierung aber blockiert wird und den Absender nicht erreicht. Dadurch gehen große Pakete endlos verloren, während kleine durchkommen. Erkennbar am Symptom: Handshake und kleine Antworten funktionieren, aber große Antworten hängen komplett. Behandelbar durch MSS Clamping oder Verringerung der MTU.

Kann man eine TCP-Verbindung beim Basisstationswechsel erhalten?

Wenn das Netz beim Handover dieselbe externe IP hält – ja, die Verbindung überlebt den Wechsel, möglicherweise mit einer kurzen Verzögerung. Wenn sich die IP ändert – nein, die alte TCP-Verbindung ist endgültig tot, weil TCP fest an das Adress-Port-Paar gebunden ist. Die richtige Strategie ist nicht, die Verbindung um jeden Preis zu erhalten, sondern einen Client zu bauen, der die Verbindung nahtlos neu aufbaut und am Abbruchpunkt weitermacht.

Wie lade ich eine Datei nach einem Abbruch korrekt weiter?

Prüfen Sie, ob der Server Range unterstützt (Header Accept-Ranges: bytes und Code 206 bei einer Range-Anfrage). Ermitteln Sie dann bei einem Abbruch die Größe des bereits empfangenen Teils und fordern Sie per Range-Header den Rest ab diesem Byte an, während Sie in dieselbe Datei schreiben. Wiederholen Sie das, bis alles vollständig ist, und begrenzen Sie die Anzahl der Versuche. Gleichen Sie am Ende unbedingt die endgültige Größe mit der erwarteten ab.

Welche Timeouts setze ich im HTTP-Client für mobile Proxys?

Trennen Sie das Timeout für den Verbindungsaufbau (ca. 10 Sekunden) und das Lese-Idle-Timeout (ca. 30 Sekunden, als Pause zwischen Datenportionen, nicht für die gesamte Übertragung). Das Gesamtbudget der Operation steuern Sie auf der Ebene der Weiterladen-Logik, nicht mit einem einzigen riesigen Timeout. Lassen Sie Timeouts niemals unbegrenzt.

Muss ich etwas ändern, wenn Wiederholungsstrategien für Antwortcodes bereits eingerichtet sind?

Ja. Wiederholungen nach Antwortcodes (z.B. die Behandlung von 429 mit exponentiellem Backoff) sind die Anwendungsebene, ein eigenes Thema. Transportabbrüche – RST, Lese-Timeouts, tote Sockets – erfordern ihre eigene Logik: schnelle Wiederholungen mit kurzer Pause, Weiterladen, Keepalive und korrektes MSS. Diese beiden Ebenen ersetzen einander nicht, sondern müssen im Client nebeneinander existieren.

Beeinflusst die Wahl des Proxy-Anbieters die Transportstabilität?

Erheblich. Ein reifer Anbieter konfiguriert MSS Clamping, angemessene Idle-Timeouts, versucht, die IP beim Handover zu halten, und arbeitet korrekt mit Keep-alive. Das nimmt einen Teil der Probleme bereits vor Ihrem Code weg. Aber selbst ein idealer Proxy macht die Notwendigkeit nicht überflüssig, einen robusten Client zu bauen, denn der Funkkanal ist grundsätzlich unberechenbar.

Fazit: Die Verbindung ist ephemer, aber die Daten müssen ankommen

Wir sind den Weg vom Symptom zum robusten Client gegangen. Lassen Sie uns das Wichtigste festhalten, damit dieser Artikel Ihr Lesezeichen wird.

Erstens. Ein Abbruch einer langen Verbindung über einen mobilen Proxy ist keine Mystik, sondern die Folge ganz konkreter Mechanismen: Idle-Timeouts auf drei Ebenen, Größen- und Zeitlimits, MTU-Probleme und Handover. Jeder hat seine eigene Handschrift, und die Diagnose anhand der Symptome führt fast immer zum Übeltäter.

Zweitens. Der kleinste Timeout auf dem Weg entscheidet über das Schicksal der Verbindung. Messen Sie ihn und konfigurieren Sie TCP Keepalive aggressiver als dieses Limit – Idle 15-25 Sekunden für Mobilfunknetze. Vergessen Sie nicht, dass TCP Keepalive und HTTP Keep-Alive verschiedene Mechanismen sind und Sie beide brauchen.

Drittens. Wenn große Antworten hängen und kleine durchkommen, ist das fast sicher ein PMTUD-Schwarzes-Loch. Behandelbar mit MSS Clamping und korrekter MTU. Verschwenden Sie keine Wochen mit dem Durchprobieren von Timeouts, sondern prüfen Sie zuerst die Paketgröße.

Viertens. Den IP-Wechsel beim Handover kann man nicht besiegen, aber man kann ihn ungefährlich machen. Bauen Sie den Client um die Ephemerität der Verbindung herum: kurze idempotente Transaktionen, Weiterladen per Range, Fortschrittsprotokoll, schneller Verbindungsaufbau, begrenzte Wiederholungen und obligatorische Integritätsprüfung.

Ihre nächsten Schritte sind einfach. Messen Sie den Idle-Timeout bei Ihrem Proxy und Betreiber. Aktivieren und konfigurieren Sie TCP Keepalive. Prüfen Sie das Verhalten bei großen Antworten und konfigurieren Sie bei Bedarf MSS. Implementieren Sie das Weiterladen per Range. Und lesen Sie sich unbedingt das verwandte Material zu Wiederholungsstrategien auf Antwortcode-Ebene durch – 429 und exponentieller Backoff –, um auch die Anwendungsschicht abzudecken, nicht nur den Transport.

Das Mobilfunknetz ist von Natur aus unberechenbar. Aber ein Client, der mit Respekt vor dieser Natur gebaut wurde, verwandelt diese Unberechenbarkeit von einer Quelle nächtlicher Bereitschaften in routiniertes Hintergrundrauschen. Die Verbindung ist ephemer – und das ist in Ordnung. Hauptsache, die Daten kommen trotzdem an. Jetzt wissen Sie, wie Sie das erreichen.