Zusammenfassung

  • Das Silly Window Syndrome war eine stabile Schleife: Kleine Fortschritte des Empfangsfensters lösten kleine Sendungen aus, die den angebotenen Platz sofort verbrauchten.
  • Die Abhilfe wurde geteilt: Der Empfänger kann marginale Kapazität zurückhalten, der Sender auf eine brauchbare Übertragungsgelegenheit warten.
  • Der Nagle-Algorithmus behandelt eine andere Quelle kleiner Segmente, nämlich kleine Schreibvorgänge der Anwendung, und ergänzt deshalb die fensterbasierte Zurückhaltung.

Aus Schutz wurde eine Paketfabrik

Das Empfangsfenster begrenzt, wie viel zusätzlichen Sequenzraum der Sender belegen darf. Es ist eine Obergrenze, aber kein Befehl, jedes positive Byte sofort auszugeben.

Ist der Empfangspuffer voll und die Anwendung liest ein Byte, kann der Empfänger genau dieses freie Byte ankündigen. Der Sender füllt es, der Puffer ist wieder voll, und der nächste Lesevorgang startet denselben Austausch. Beide Seiten halten die Flusskontrolle ein, doch die Verbindung bezahlt Header, Bestätigungen, Interrupts und Ablaufplanung für minimale Nutzlast.

RFC 813 nannte dieses stabile Muster Silly Window Syndrome. Die Diagnose ging über Leistungsoptimierung hinaus: Lokal korrekte Entscheidungen konnten gemeinsam ein systemisches Versagen bilden. Die Byte-Buchhaltung blieb exakt, während die nützliche Austauscheinheit zerfiel.

Der Empfänger veröffentlichte nicht mehr jede marginale Wahrheit

Der Empfänger kennt seinen eigenen Puffer unmittelbar. Gibt die Anwendung nur wenig Platz frei, kann er den rechten Rand des angekündigten Fensters festhalten. Die Kapazität ist vorhanden, bleibt aber unveröffentlicht, bis eine Öffnung für sinnvolle Arbeit zusammenkommt.

Das Warten verfälscht keinen Zustand und zieht keine frühere Erlaubnis zurück. Es trennt eine korrekte Messung von einer handlungsreifen Einladung. RFC 1122 und die moderne TCP-Spezifikation beschreiben empfangsseitige SWS-Vermeidung sowie einen praktischen Schwellenwert aus Puffergröße und effektiver maximaler Segmentgröße.

Der Sender behandelte die Grenze nicht mehr als Auftrag

Nicht jeder Empfänger wird kleine Aktualisierungen zurückhalten. Deshalb braucht auch der Sender eine eigene Entscheidung. Das Fenster verbietet die Überschreitung; es verpflichtet nicht dazu, jede positive Öffnung sofort auszunutzen.

Senderseitige SWS-Vermeidung wartet auf eine brauchbare Bedingung: Platz für ein volles Segment, den passenden Abschluss vorgemerkter Push-Daten, einen bedeutenden Anteil des größten beobachteten Fensters oder einen Ausweich-Timer, der schließlich Fortschritt erzwingt. Weil der Sender den entfernten Puffer nicht kennt, schätzt er ihn aus dem Verbindungsverlauf. Der Timer verhindert, dass eine falsche Schätzung zum dauerhaften Veto wird.

RFC 9293 behandelt Sender- und Empfängeralgorithmus in getrennten Abschnitten. Darin liegt der architektonische Kern: Der Empfänger entscheidet, wann Kapazität zum Angebot wird; der Sender entscheidet, wann das Angebot ein Segment rechtfertigt. Keiner verwaltet den Speicher des anderen.

Nagle bändigte einen anderen Datenstrom

Kleine Segmente können auch bei großem Fenster entstehen, wenn die Anwendung Zeichen einzeln übergibt. RFC 896 beschrieb die Kosten: Ein Byte Nutzlast reiste damals mit ungefähr vierzig Byte TCP/IP-Headern.

Nagels adaptive Regel sammelt neue kleine Schreibvorgänge, solange ein kleines Segment unbestätigt ist. Eine Bestätigung oder genügend Daten gibt die nächste Sendung frei. Die Regel folgt damit der Rückmeldung der Verbindung statt einer festen Verzögerung.

Die Eingangssignale unterscheiden sich. Nagle reagiert auf kleine Datenportionen aus der Anwendung; SWS-Vermeidung reagiert auf kleine Fenstergelegenheiten des Gegenübers. Eine latenzkritische Anwendung kann Nagle abschalten, ohne damit das Fensterproblem zu beseitigen.

Zurückhaltung brauchte einen Ausgang

Warten spart Arbeit, unbegrenztes Warten wäre jedoch ein neuer Fehler. Der Ausweich-Timer erhält den Fortschritt. Der Empfänger besitzt die Veröffentlichung seines Puffers, der Sender die Nutzung seiner Gelegenheit, die Anwendung ihre Latenzentscheidung. Enge Zuständigkeiten und ausdrückliche Ausgänge ermöglichen Koordination ohne zentralen Planer.

Quellen und Grenzen

Die Entwicklung dokumentieren RFC 793, RFC 813, RFC 896, RFC 1122 und RFC 9293. Sie messen nicht die heutige Häufigkeit in einzelnen TCP-Stacks. SWS ist außerdem nicht mit Überlastungsfenster-Steuerung oder Paketverlust gleichzusetzen.