Zusammenfassung

  • Eine Zero-Window-Probe veranlasst den Empfänger, einen möglicherweise in einem reinen ACK verlorenen Fensterstand erneut zu melden.
  • TCP hält die Fortsetzung technisch offen; Betriebssystem und Anwendung entscheiden weiterhin, wann Warten und Ressourcenbindung enden.

Der Stillstand kann entstehen, obwohl beide Seiten alles richtig machen. Die empfangende Anwendung liest vorübergehend keine Daten mehr, ihr Puffer füllt sich, und TCP meldet ein Empfangsfenster von null. Der Sender gehorcht der Flusssteuerung und stellt den normalen Versand ein. Später schafft die Anwendung wieder Platz. Der Empfänger schickt ein ACK mit einem größeren Fenster. Geht genau dieses Paket verloren, leben beide Endpunkte fortan mit verschiedenen Fassungen derselben Verbindung.

Für den Empfänger ist neuer Kredit verfügbar und bereits bekannt gegeben. Beim Sender ist weiterhin nur die letzte Meldung angekommen: null. Ein ACK ohne Nutzdaten wird nicht schon deshalb zuverlässig erneut übertragen. Der Empfänger hat möglicherweise nichts Weiteres zu sagen; der Sender darf jene Daten nicht senden, die eine natürliche Antwort auslösen würden. Die Verbindung besteht, doch das Wissen, mit dem sie fortgesetzt werden könnte, liegt nur auf einer Seite.

Die Zero-Window-Probe beseitigt diese Wissenslücke, ohne Empfangskapazität zu erfinden. Auch bei einem geschlossenen Fenster sendet oder wiederholt der Sender in Abständen eine kleine Menge, damit der Empfänger antworten muss. Das ACK nennt die nächste erwartete Sequenznummer und das gegenwärtige Fenster. Ist inzwischen Platz vorhanden, erfährt der Sender von der Öffnung. Bleibt der Wert null, erhält er lediglich eine aktuelle Bestätigung und muss die Grenze weiterhin einhalten.

Das Grundmuster stand bereits 1981 in RFC 793. Ein sendendes TCP sollte selbst bei einem Nullfenster regelmäßig wiederholen. Traf unter dieser Bedingung ein Segment ein, sollte der Empfänger mit seiner nächsten erwarteten Sequenznummer und dem aktuellen Fenster antworten. Der genannte Zweck war eng umrissen: Die spätere Öffnung eines Fensters musste dem anderen Endpunkt zuverlässig mitgeteilt werden. Die damalige Empfehlung für das Zeitintervall gehörte zur frühen Fassung; überdauert hat die Wiederholbarkeit einer sonst verlierbaren Zustandsmeldung.

RFC 1122 machte die Verpflichtung 1989 unmissverständlich. Hosts müssen das Sondieren von Nullfenstern unterstützen. Das Dokument beschreibt den Fehlerfall: ACK-Segmente ohne Daten werden von TCP nicht zuverlässig übertragen; fehlt die Probe, kann der Verlust des fensteröffnenden ACK eine Verbindung für immer aufhalten. Die erste Probe sollte nach einer Retransmission-Timeout-Periode erfolgen, spätere Abstände sollten exponentiell wachsen.

Diese Taktung löst zwei gegensätzliche Aufgaben. Eine Anfrage nach einem RTO begrenzt die Verzögerung, wenn lediglich ein einzelnes ACK verschwunden ist. Wachsende Abstände verhindern zugleich, dass eine berechtigte lange Pause einen gleichbleibenden Strom von Rückfragen erzeugt. Die Probe ist keine Erlaubnis, am Empfänger vorbeizusenden. Sie vergrößert das Fenster nicht, sondern lässt dessen Besitzer den aktuellen Wert nochmals aussprechen.

RFC 1122 zieht außerdem eine wichtige Grenze um die Bedeutung von null. Ein empfangendes TCP darf sein angebotenes Fenster unbegrenzt geschlossen halten. Solange es auf die Probes mit ACKs antwortet, muss der Sender die Verbindung offen lassen können; die User-Timeout-Politik der Anwendung bleibt davon unberührt. Das historische Beispiel ist ein Drucker-Daemon, der keine Daten mehr abnimmt, weil dem Drucker das Papier ausgegangen ist. TCP sieht weder das Papier noch den Zeitpunkt der Nachfüllung. Aus dem geschlossenen Fenster allein kann es keinen endgültigen Ausfall ableiten.

Auf der Senderseite heißt diese Lage gewöhnlich Persist-Zustand. RFC 6429 griff sie 2011 erneut auf, weil Protokollgeduld Kosten erzeugt, die TCP selbst nicht bewerten kann. Ein Gegenüber kann dauerhaft null anbieten und dennoch jede Probe bestätigen. Währenddessen bleiben Anwendungsdaten in der Sendewarteschlange, Puffer und Verbindungszustand belegt. Viele solche Verbindungen können einem stark beanspruchten Server Ressourcen entziehen, die legitime Verbindungen benötigen.

RFC 6429 erklärte deshalb nicht jedes Nullfenster zum Angriff und ersetzte das Sondieren nicht durch eine universelle Abbruchfrist. Es ordnete Zuständigkeiten. TCP sollte eine Verbindung nicht allein wegen ihres Persist-Zustands schließen. Das hindert Betriebssystem oder Anwendung jedoch nicht daran, die Verbindung nach ihrer normalen Ressourcenpolitik abzubrechen und Speicher zurückzugewinnen. Wiederherstellbarer Protokollzustand ist keine Verpflichtung zu unbegrenzter Ressourcenbindung.

Die heutige konsolidierte TCP-Spezifikation RFC 9293 bewahrt diese Aufteilung. Zero-Window-Probing bleibt verpflichtend. Der Empfänger meldet weiterhin das aktuelle Fenster und die nächste erwartete Sequenznummer. Der Sender sollte nach einem RTO beginnen und spätere Abstände exponentiell verlängern. Auch der Vorbehalt der Ressourcenverwaltung bleibt ausdrücklich bestehen. Garantiert wird nicht ewiges Warten, sondern die Möglichkeit, den Fensterstand erneut zu lernen, solange das System die Verbindung erhalten will.

Ein Probe-ACK ist somit ein begrenzter Protokollbeleg. Er zeigt, dass das entfernte TCP weiterhin seinen Sequenzraum und Empfangskredit meldet. Er beweist weder Fortschritt in der empfangenden Anwendung noch eine baldige Wiederaufnahme und auch nicht, dass die Verbindung ihren Aufwand noch rechtfertigt. Die Probe repariert eine verlorene Zustandsänderung; sie liefert keine Zukunftszusage.