Zusammenfassung

  • TCPs User Timeout ist eine lokale Grenze pro Verbindung: Bleiben gesendete Daten zu lange unbestätigt, darf der Endpunkt die Verbindung abbrechen. Er ist nicht der Timer, der den nächsten Sendeversuch bestimmt.
  • RFC 5482 definierte eine vier Oktett lange Option, mit der ein Endpunkt seinen aktuellen Wert ankündigt. Die Angabe ist ein Rat, keine bindende Verhandlung; die Gegenstelle darf sie ignorieren, lokal begrenzen oder von einem expliziten Anwendungswert fernhalten.
  • Langes Warten kann eine Verbindung durch eine Unterbrechung retten, hält aber Warteschlangen und Zustand länger vor. Kurzes Warten gibt Ressourcen früher frei, kann jedoch vorübergehenden Verlust oder Verzögerung zum endgültigen Fehler machen.

Zwei Uhren für ein unbestätigtes Byte

Die Verbindung steht, ein Byte ist noch nicht bestätigt. Läuft der Retransmission Timer ab, sendet TCP das Segment erneut und startet die nächste Frist. Der User Timeout beantwortet eine andere Frage: Wie lange ist die ausstehende Arbeit für die Anwendung noch wertvoll genug, um den gesamten Verbindungszustand zu behalten?

RFC 793 behandelte diese Grenze als lokalen Parameter der Verbindung. Läuft USER TIMEOUT ab, folgt kein weiterer Versuch. TCP leert die Warteschlangen, meldet den Abbruch, löscht den Transmission Control Block und wechselt nach CLOSED. RFC 9293 erhält diese Trennung: RETRANSMISSION TIMEOUT sendet erneut, USER TIMEOUT beendet den Zustand.

Die Anwendung durfte diese Geduld schon 1981 bestimmen. Die abstrakte Schnittstelle nahm beim OPEN einen Wert an und erlaubte eine Änderung beim SEND. RFC 1122 ordnete übermäßige Wiederholungen mit R1 und R2. Bei R1 erscheinen Warnsignale, bei R2 schließt TCP. Eine Anwendung muss R2 für eine einzelne Verbindung setzen können; die Empfehlung von mindestens hundert Sekunden für Daten ist kein universeller Pflichtwert.

Diese Macht blieb einseitig. Ein mobiles System konnte seine Frist für einen Netzwechsel verlängern, während die Gegenstelle früher aufgab. Ein ausgelasteter Server konnte stillen Zustand rasch freigeben wollen, ohne dem Client dieses Budget im TCP-Protokoll mitzuteilen.

Vier Oktette ohne Vertragsabschluss

RFC 5482 veröffentlichte 2009 UTO als TCP-Option Kind 28 mit Length 4. Ein G-Bit wählt Sekunden oder Minuten, die übrigen fünfzehn Bit tragen den Vorschlag. Null ist reserviert. Das Feld bezeichnet Zeit, nicht die Zahl der Wiederholungen und keine RTT-Schätzung.

Wird UTO vor dem Öffnen aktiviert, kann es in SYN und SYN-ACK stehen. Auch das erste Paket ohne SYN sollte die Option tragen. Ein TCP ohne Unterstützung muss sie still ignorieren. Geht das Segment verloren, verpasst die Gegenstelle lediglich die Gelegenheit zur Anpassung. Ein eigener Zuverlässigkeitshandschlag existiert nicht, und die Zustellung darf nicht vorausgesetzt werden.

Die Zuständigkeiten sind benannt. ADV_UTO ist der angekündigte Wert, REMOTE_UTO der zuletzt empfangene Rat, USER_TIMEOUT die lokale Entscheidung. ENABLED schaltet die Erweiterung ein; CHANGEABLE entscheidet, ob der entfernte Vorschlag den lokalen Wert beeinflussen darf.

Setzt die Anwendung USER_TIMEOUT ausdrücklich, muss CHANGEABLE false werden. Ein Paket der Gegenstelle kann den Anwendungswunsch nicht heimlich überschreiben. Ist Anpassung erlaubt, empfiehlt RFC 5482 den größeren der beiden angekündigten Werte und danach lokale Unter- und Obergrenzen. Trotzdem können beide Seiten bei verschiedenen Fristen landen und unabhängig schließen.

Längeres Überleben bindet Zustand

Eine lange Frist hilft bei Mobilitätswechseln, Routingstörungen und vorübergehender Unerreichbarkeit. Währenddessen hält der Host Speicher, Warteschlangen und Kontext vor. Wer viele Handshakes abschließt und sehr lange Werte vorschlägt, kann die Kosten wegwerfbarer Verbindungen auf dem Server erhöhen.

Deshalb verlangt RFC 5482 Grenzen. Die Untergrenze muss größer als das aktuelle RTO sein; sonst kann Verlust oder hohe Latenz abbrechen, bevor eine Wiederholung realistisch wirken kann. Die Obergrenze darf von Authentisierung, Verbindungen pro Gegenstelle, Ressourcenverbrauch oder Angriffslage abhängen. Ein langer angenommener Rat nimmt dem lokalen Endpunkt nicht das Recht, Zustand abzubauen.

Keep-alive hat eine andere Aufgabe. Sind beide Mechanismen aktiv, muss sein Timer größer als der angenommene User Timeout sein, damit nicht eine abweichende Abbruchregel zuerst greift. Eine zustandsbehaftete Firewall darf den Fluss nach ihrer eigenen Leerlauffrist vergessen. UTO prüft den Pfad nicht, authentisiert die Gegenstelle nicht und garantiert kein Überleben bis zum angekündigten Zeitpunkt.

Auch der Optionsraum ist knapp: vierzig Oktette. Andere Erweiterungen können keinen Platz für UTO lassen. Seine Abwesenheit beweist daher keine Ablehnung.

Was RFC 5482 tatsächlich änderte

RFC 5482 erfand nicht das Recht der Anwendung, ihre Wartezeit zu wählen. Die Spezifikation machte eine lokale Präferenz hörbar, ohne die Entscheidungsgewalt zu übertragen. Damit unterscheidet sie sich von Window Scale, das nach dem Handshake eine Feldinterpretation festlegt, von PAWS, das mit Zeitstempeln alte Bedeutung im Sequenzraum verwirft, und von SACK, das bereits empfangene Blöcke hinter einer Lücke meldet.

Dieses RFC-Paket belegt weder heutige Verbreitung noch Betriebssystem-APIs oder konkrete Standardwerte. Es belegt eine engere Geschichte: TCP lernte, eine Grenze der Geduld mitzuteilen, ohne sie zur gegenseitigen Pflicht zu erklären.

Quellen