Zusammenfassung

  • Der Retransmission-Timer bestimmt den nächsten Versuch; USER TIMEOUT bestimmt den Abbruch der Verbindung.
  • RFC 5482 übermittelt eine Peer-Präferenz, während lokale Grenzen und CHANGEABLE die Entscheidung schützen.

Zwei Uhren mit unterschiedlichen Aufgaben

Bleibt ein Segment ohne brauchbare Bestätigung, kann der Retransmission-Timer ablaufen. TCP sendet dann das erste Segment der Warteschlange erneut und startet den Timer neu. Daraus folgt jedoch nicht, wie lange die Anwendung den Verbindungszustand behalten will.

USER TIMEOUT beantwortet die andere Frage: Wie lange dürfen übertragene Daten erfolglos auf ihre Zustellung warten? RFC 793 beschrieb diesen Wert als eine lokale Vorgabe für TCP. RFC 9293 trennt die Ereignisse ausdrücklich. Beim Ablauf des Retransmission-Timeouts wird das erste Segment erneut gesendet und der Retransmission-Timer neu initialisiert. Beim USER-TIMEOUT-Ereignis werden die Warteschlangen geleert, der Abbruch gemeldet, der TCB gelöscht und der Zustand CLOSED erreicht.

Deshalb können die Uhren unterschiedliche Entscheidungen treffen. Ein weiterer Wiederholungsversuch kann noch möglich sein, obwohl das lokale Budget für die Persistenz bereits erschöpft ist. RTO passt den Abstand zwischen Versuchen an beobachtete Umlaufzeiten und Verlustunsicherheit an. USER TIMEOUT legt fest, wie lange Zustand, Speicher und Ungewissheit für die Anwendung noch vertretbar sind.

Das ist auch kein Timeout einer einzelnen Anwendungsanfrage. Eine Anwendung kann eine Operation aufgeben und die Verbindung behalten oder bei nicht zustellbaren ausstehenden Daten die Verbindung selbst beenden lassen.

Ein Vorschlag in Sekunden oder Minuten

Ursprünglich war der Timeout lokal. Ein Endpunkt konnte nicht wissen, wie lange der andere eine gestörte Verbindung behalten wollte. RFC 5482 führte die TCP-User-Timeout-Option ein, um diese Erwartung sichtbar zu machen.

Die Option hat Kind 28 und Länge 4. Ein Granularitätsbit wählt Sekunden oder Minuten; die übrigen 15 Bit tragen das vorgeschlagene Intervall. Damit lassen sich Werte von einer Sekunde bis zu mehr als neun Stunden oder von einer Minute bis zu mehr als 22 Tagen ausdrücken.

Der Wert berät den Peer, erteilt ihm aber keinen entfernten Abbruchbefehl. Der abstrakte Zustand umfasst USER_TIMEOUT, ADV_UTO, ENABLED und CHANGEABLE. ENABLED ist standardmäßig deaktiviert und steuert Senden und Verarbeiten der Option. CHANGEABLE bestimmt, ob ein empfangener Vorschlag den lokalen Timeout verändern darf.

Hat die Anwendung einen Wert festgelegt und ist CHANGEABLE falsch, darf der Peer diesen Wert nicht überschreiben. TCP soll die Anwendung dennoch über den Vorschlag informieren. Die Information wird geteilt, die Zuständigkeit nicht.

Grenzen gehören zum Protokolldesign

Implementierungen müssen lokale Unter- und Obergrenzen setzen. Ein zu kurzer Wert kann Verbindungen auf einem langsamen oder vorübergehend gestörten Pfad voreilig beenden. Ein zu langer Wert hält Puffer und Zustand vor und erhöht das Risiko der Ressourcenerschöpfung. Authentifizierung und Grenzen pro Peer können dagegen helfen.

Das Fehlen von UTO beweist nicht, dass kein USER TIMEOUT existiert. Nicht unterstützende TCP-Implementierungen ignorieren die Option möglicherweise stillschweigend, und der begrenzte Optionsraum kann bereits belegt sein. Ein zustandsbehaftetes Firewall-System kann seinen Zustand ebenfalls früher löschen. Ein Mitschnitt zeigt nur einen Vorschlag an dieser Beobachtungsstelle, nicht dessen Übernahme oder die Lebensdauer eines Zwischenmittels.

Sind Keepalives und UTO aktiv, muss der Keepalive-Timer größer als der angenommene USER_TIMEOUT sein. Keepalive prüft die Erreichbarkeit einer ansonsten inaktiven Verbindung; USER TIMEOUT begrenzt die Dauer unzugestellter Daten.

RFC 5482 machte somit eine lokale Policy als begrenzten Vorschlag sichtbar, ohne die endgültige Abbruchentscheidung an den Peer zu übertragen.

Quellen