Zusammenfassung

  • TCP Keepalive fragt, ob ein stiller Peer auf der Transportschicht antwortet; die Gesundheit seiner Anwendung beweist es nicht.
  • Weil Verbindungsschweigen mehrere Ursachen hat, blieb der Mechanismus optional, konfigurierbar und standardmäßig ausgeschaltet.
  • Eine fehlende Antwort beweist keinen Tod, und Mittelspeicher, User Timeout sowie Energiebedarf verbieten ein sicheres Universalintervall.

Zuverlässigkeit braucht etwas, das gesendet wurde

RFC 793 gibt TCP eine klare Aufgabe, sobald Daten vorliegen. Bytes erhalten Sequenzpositionen, Bestätigungen lassen den Versand fortschreiten, fehlende Bestätigungen führen zu Wiederholungen. Am Ende gelingt die Zustellung, ein Reset trifft ein oder eine konfigurierte Abbruchpolitik greift.

Eine untätige Verbindung liefert keinen solchen Stoff. Kein neues Byte wartet auf ein ACK, und kein unbestätigtes Byte betreibt einen Timer, der einen verschwundenen Pfad sichtbar machen könnte. Beide Enden können gesund und absichtlich still sein. Ebenso kann ein Rechner abgestürzt, eine Route abgebaut, eine Firewallregel oder Adressabbildung verfallen sein. Für den lokalen TCP-Zustand sehen diese Welten womöglich gleich aus.

Das ist kein Versagen zuverlässiger Übertragung. Es ist die Erkenntnisgrenze einer Lieferung, die gar nicht versucht wurde.

Die Frage knapp hinter der Grenze

RFC 1122 hielt Keepalive 1989 als umstrittenen, optionalen Mechanismus fest. Der klassische Probe setzt SEG.SEQ = SND.NXT-1, also die Position unmittelbar vor dem nächsten neuen Byte des Senders.

Diese unbequeme Stelle ist Absicht. Das Segment soll nicht als neue Anwendungsnutzlast voranschreiten, wohl aber ein fernes TCP mit vorhandenem Verbindungszustand dazu bringen, per ACK seine nächste Erwartung zu nennen. Meist trägt es keine Daten. Eine Form mit einem „Müll“-Byte blieb nur für fehlerhafte Altimplementierungen konfigurierbar.

Die Antwort belegt wenig, aber präzise: Ein TCP-Endpunkt hat dieses Segment gerade über einen nutzbaren Hin- und Rückweg verarbeitet. Sie belegt weder Fortschritt des Prozesses noch gültige Anmeldedaten, Datenbankzugriff oder Erfolg der nächsten fachlichen Anfrage.

Optionalität war eine Sicherheitsgrenze

RFC 1122 verlangte Keepalive nicht von jeder TCP-Implementierung. Falls vorhanden, musste die Anwendung es je Verbindung ein- und ausschalten können; die Voreinstellung musste aus sein. Das Ruheintervall sollte konfigurierbar sein und standardmäßig mindestens zwei Stunden betragen.

Damit wählt die Transportschicht nicht heimlich die Fehlersemantik der Anwendung. Terminalsitzung, Routing-Nachbarschaft, Datenbankpool und schlafender Sensor bewerten Fehlabschaltung, späte Erkennung, Verkehr und gebundenen Zustand völlig verschieden. Aus der Abwesenheit von Bytes kann TCP diese Kosten nicht ableiten.

Zwei Stunden behaupteten nie, dass ein Gegenüber nach 7.200 Sekunden tot sei. Sie bildeten eine konservative Grenze für seltene, unaufgeforderte Prüfungen. Die heutige Konsolidierung RFC 9293 bewahrt diese Ordnung. Jahrzehnte Betrieb machten aus dem optionalen Probe keine automatische Lebensdefinition.

Warum eine unbeantwortete Frage nichts beweist

Reine ACKs genießen nicht dieselbe eigenständige zuverlässige Wiederholung wie Nutzdaten. Der Probe kann verloren gehen, sein ACK ebenso, und Überlastung kann beide verzögern. Darum untersagen RFC 1122 und RFC 9293 ausdrücklich, eine Verbindung nach einer einzigen fehlenden Antwort für tot zu erklären.

Schließen ist eine Handlung, keine Beobachtung. Löscht das lokale TCP den Zustand, kann eine Anwendung eine Transaktion aufgeben, eine Sperre freigeben, Ersatz wählen oder eine zweite Verbindung eröffnen. Die Folgen einer aus kurzem Paketverlust gewonnenen Vermutung können den Verlust lange überdauern.

Mehrere Probes und ein Grenzwert erhöhen die Plausibilität eines Ausfalls. Sie bleiben eine örtliche Risikoentscheidung: Nach so viel fehlendem Beleg kostet das Bewahren der Ungewissheit mehr als das Schließen. Aus Abwesenheit wird dadurch kein Augenzeugenbericht.

Der User Timeout stellt eine andere Frage

TCP besaß bereits einen User Timeout für gesendete, aber unbestätigte Daten. RFC 5482 definierte später eine Option, um eine Timeout-Präferenz mitzuteilen. Sie fragt: Wie lange dürfen übertragene Daten unbestätigt bleiben? Sie fragt nicht, wie lange ein ruhender Partner geschwiegen hat.

Die Trennung verhindert widersprechende Uhren. RFC 5482 bemerkt, dass manche Keepalive-Regeln eine Verbindung abbrechen können, die eine vorübergehende Störung sonst überstanden hätte. Bei gemeinsamer Verwendung unter jener Spezifikation muss der Keepalive-Timer länger als der angenommene User Timeout sein. Nutzdaten, Ruheprobe und Schließentscheidung gehören zu verwandten, nicht identischen Belegketten.

Auch der Vermittler bekam ein Gedächtnis

Das Ende-zu-Ende-Bild sah den Zustand bei den Endpunkten. NATs und zustandsbehaftete Middleboxes fügten unterwegs ein weiteres, ablaufendes Register ein. Beide Rechner können die Verbindung korrekt halten, während ein Vermittler die für das nächste Paket benötigte Abbildung löscht.

RFC 5382 machte aus dem Zwei-Stunden-Wert eine Kompatibilitätsgrenze. Kann ein NAT die Aktivität etablierter Endpunkte nicht bestimmen, darf es deren Abbildung nicht vor zwei Stunden und vier Minuten verwerfen. Der Zuschlag berücksichtigt Pakete unterwegs.

Die Regel schützt die Erwartung der Endpunkte, überträgt dem NAT aber nicht die Herrschaft über die Verbindung und garantiert keine Befolgung durch jedes Gerät. Bei kürzeren realen Laufzeiten senden Betreiber häufiger. Das kann die Abbildung erhalten, zahlt aber eine Middlebox-Steuer: Datenverkehr entsteht nicht für die Anwendung, sondern damit eine private Kiste die Verbindung nicht vergisst.

Die Batterie stellt die Gegenrechnung

Auf einem netzbetriebenen Server wirken einige Kleinpakete billig. Bei einem sparsamen Gerät kann jede Übertragung das Funkmodul wecken und eine teure Aktivphase verlängern. RFC 9006 beschreibt den Konflikt: Der lange TCP-Standard hält manche Middlebox-Zustände nicht, kürzere Keepalives können dafür Akkus leeren.

Keine Transportkonstante verteilt diese Kosten richtig. Die Anwendung kennt ihre Toleranz für verzögertes Wiederverbinden, der Betreiber die Zustandsdauer des Pfads und das Gerät sein Energiebudget. Mitunter ist es vernünftiger, die Verbindung gar nicht lebendig zu halten, sondern bei neuer Arbeit aufzubauen.

Ein Herzschlag unterhalb der Anwendung

Der Name Herzschlag überschätzt leicht, was Keepalive hört. Ein Kernel kann ACKs senden, während der Dienstprozess festhängt. Ein Proxy kann TCP beantworten, obwohl sein Backend ausfällt. Eine gesunde Anwendung kann bewusst pausieren.

Ein Herzschlag auf Anwendungsebene stellt die stärkere Fachfrage: Kann der Dienst eine Anfrage verstehen, Zustand lesen und eine gültige Antwort erzeugen? Das kostet mehr und garantiert noch immer nicht jede künftige Operation. Beide Verfahren sollten nur gemeinsam laufen, wenn klar ist, welchen Fehler jedes erkennen soll.

Keepalive ist auch kein Zero-Window-Probe. Dieser schützt die Wiederöffnung eines Fensters, nachdem der Empfänger ausdrücklich keine Kapazität gemeldet hat. Keepalive beginnt bei sonstiger Ruhe. Ähnlich kleine Pakete schützen verschiedene Verträge.

Das Schweigen behielt die Unschuldsvermutung

Die dauerhafte Designentscheidung war nicht allein der Trick mit SND.NXT-1. Es war die Weigerung, Schweigen durch die Transportschicht standardmäßig schuldig zu sprechen.

Ein ACK belegt jüngste TCP-Erreichbarkeit, nicht Anwendungsgesundheit. Ein fehlendes ACK ist Ungewissheit, nicht Tod. Erst eine konfigurierte Serie von Ausfällen kann lokales Schließen rechtfertigen, weil die Anwendung ihr Risikobudget gewählt hat, nicht weil das Netz Gewissheit lieferte.

Keepalive blieb optional, weil der Träger der Folgen die Entscheidung behalten muss. TCP lieferte eine Art zu fragen. Es beanspruchte nicht zu wissen, warum niemand antwortete.

Quellen und Beleggrenzen

RFC 793 beschreibt ursprüngliche Verbindung und User Timeout; RFC 1122 den Keepalive-Vertrag von 1989; RFC 5382 NAT-Zeiten; RFC 5482 die Trennung vom User Timeout; RFC 9006 den Energiehandel; RFC 9293 die konsolidierten aktuellen Regeln. Sie beweisen nicht jede Plattformvorgabe, Middlebox-Laufzeit oder fachliche Gesundheitsdefinition.