Zusammenfassung

  • Ein Empfangsfenster von null ist gültige Flusskontrolle. Es meldet momentan fehlende Kapazität, nicht den Ausfall von Peer, Pfad oder Anwendung.
  • Das reine ACK, das das Fenster wieder öffnet, wird nicht zuverlässig erneut übertragen. Eine kleine Probe fragt den aktuellen Wert neu ab; spätere Proben werden exponentiell ausgedünnt.
  • Solange der Empfänger antwortet, muss TCP die Verbindung offenlassen. Anwendung und Betriebssystem dürfen sie dennoch durch eine ausdrückliche Ressourcenentscheidung abbrechen.

Zwei korrekte Wartezustände erzeugten Stillstand

Die empfangende Anwendung liest nicht mehr, der Puffer füllt sich und TCP kündigt null an. Der Sender stoppt. Später wird Platz frei und ein ACK trägt ein positives Fenster. Geht es verloren, hält der Sender weiter die alte Sperre für gültig, während der Empfänger seine Änderung bereits gemeldet zu haben glaubt.

RFC 1122 nennt den Grund: ACKs ohne Daten werden von TCP nicht zuverlässig übertragen. Die Pause und die Wiederöffnung können beide korrekt sein; ein verlorenes Berechtigungs-Update hält die Verbindung trotzdem endlos fest.

Das Fenster war Kapazität, keine Diagnose

RFC 813 trennte das angebotene Fenster des Empfängers vom nutzbaren Fenster, das der Sender nach Abzug unbestätigter Daten berechnet. Es beantwortet, wie viel angenommen werden kann.

Null erklärt nicht, warum die Anwendung nicht liest. Der klassische Drucker ohne Papier kann auf einen Menschen warten, obwohl Host und Netz funktionieren. Ein Transportabbruch würde aus unbekannter Anwendungspolitik einen Fehler machen.

Empfangs- und Congestion Window sind ebenfalls verschieden. Das eine schützt den Endpuffer, das andere den Weg. Ein freier Weg kann zu einem vollen Empfänger führen; ein bereiter Empfänger über einen überlasteten Weg erreichbar sein.

Ein Ausnahme-Oktett fragte nach dem heutigen Stand

RFC 793 enthielt die Grundlage; RFC 9293 verlangt Zero-Window-Probing weiterhin. Trotz null sendet der Sender regelmäßig mindestens ein neues Oktett, sofern vorhanden, oder eine Wiederholung. Der Empfänger antwortet mit erwarteter Sequenz und aktuellem Fenster.

Die Probe hebt null nicht auf. Sie ist eine begrenzte Frage. Ein Null-ACK bestätigt die Pause; ein positiver Wert stellt die verlorene Erlaubnis wieder her.

Die erste Probe soll nach einer Retransmission Timeout Period folgen, spätere Abstände exponentiell wachsen. Das reagiert auf ein einzelnes verlorenes Update und belastet eine lange, legitime Pause wenig. Ein universelles Höchstalter schreibt der Standard nicht vor.

Bestätigte null war nicht dasselbe wie Schweigen

RFC 1122 erlaubt ein unbegrenzt geschlossenes angebotenes Fenster. Bestätigt der Empfänger die Proben weiter, muss das sendende TCP die Verbindung offenlassen.

Das ACK beweist nur eine Antwort des entfernten TCP über einen Rückweg. Es beweist weder Anwendungsfortschritt noch baldige Wiederaufnahme oder wirtschaftliche Tragbarkeit der lokalen Warteschlange. Dennoch ist es mehr als Schweigen: fehlende Antwort schafft Pfadunsicherheit; bestätigte null meldet anwesende, aber zurückgehaltene Kapazität.

Persistenz verlieh kein Eigentum an fremdem Speicher

„Unbegrenzt“ wurde als Verbot jeder Ressourcenfreigabe missverstanden. RFC 6429 zog die Grenze. TCP soll nicht allein wegen Persist schließen; fordert Anwendung oder Betriebssystem den Abbruch, muss TCP folgen.

Viele Clients können große Antworten anfordern, nicht mehr lesen, null ankündigen und jede Probe bestätigen. Der Server hält Sendepuffer und Verbindungsblöcke, bis legitime Nutzer keinen Platz mehr finden.

Ein versteckter Einheitstimeout erkennt Druckauftrag und Angriff ebenso wenig. Die Schicht mit Kenntnis von Dienst, Mandant, Kosten und Frist muss entscheiden. TCP erhält die gemeinsame Semantik; lokale Politik trägt die lokalen Folgen.

Eine Öffnung in Krümeln war die zweite Falle

RFC 813 beschrieb Silly Window Syndrome: kleine Fensterbewegungen erzeugen dauerhaft kleine Segmente, zusätzliche ACKs, CPU-Last, Verlust und Wiederholung. Seine Feldzahlen zeigen historische Extremfälle, keine allgemeine Konstante.

Der Empfänger kann kleine Freigaben zurückhalten, bis nützlicher Raum entstanden ist. Der Sender muss nicht jeder winzigen Bewegung folgen. RFC 9293 fordert beide SWS-Vermeidungen und ordnet Nagle als Ergänzung für kleine Anwendungsschreibvorgänge ein.

Persist verhindert, dass eine wesentliche Öffnung verschwindet. SWS-Vermeidung verhindert, dass jedes freie Stück zur ineffizienten Öffnung wird. Zustellung und Größe der Erlaubnis gehören zusammen.

Beständig blieb die Aufteilung der Verantwortung

RFC 793, RFC 813, RFC 1122, RFC 6429 und RFC 9293 hinterließen keinen heiligen Timerwert. Der Empfänger kontrolliert seine Kapazität. Das sendende TCP fragt Veränderungen sparsam ab. Anwendung und Betriebssystem wählen Speicher, Frist und Abbruch.

Bei null beharrlich zu bleiben erhält die Möglichkeit der Fortsetzung. Es ist kein Anspruch auf unbegrenzte Ressourcen des Gegenübers.

Quellen und Grenzen

Der geschlossene Satz umfasst RFC 793, RFC 813, RFC 1122, RFC 6429 und RFC 9293. Er belegt keine heutigen Timer aller Systeme, Angriffshäufigkeit oder Gesundheit eines bestimmten Dienstes.