Zusammenfassung

  • Nagles Regel erlaubt ein erstes kleines Segment, wenn keine früheren Daten ausstehen, und puffert weitere kleine Schreibvorgänge, bis eine Bestätigung eintrifft oder ein vollständiges Segment entsteht.
  • Sie ist von verzögerten Bestätigungen, der Vermeidung des Silly Window Syndrome und der Staukontrolle getrennt; pro Verbindung muss sie abschaltbar sein.

RFC 896 wurde im Januar 1984 veröffentlicht und beschrieb das Kleinpaketproblem der frühen TCP/IP-Netze. Eine Anwendung, die Zeichen einzeln ausgab, konnte ein Nutzbyte zusammen mit vierzig Byte TCP- und IP-Headern übertragen. In heterogenen, stark belasteten Netzen beanspruchten viele kleine Pakete die Übertragungs- und Verarbeitungskapazität von Gateways, verstärkten Überlastung und konnten Verluste und erneute Übertragungen begünstigen.

Feste Sammelzeiten von 200 bis 500 Millisekunden waren über Netze mit sehr unterschiedlichen Bandbreiten und Round-Trip-Zeiten schwer abzustimmen. Ein lokaler Wert sammelte auf einem langen Pfad womöglich zu wenig; ein für den langen Pfad geeigneter Wert konnte die lokale Interaktion träge machen. Nagle verlegte die Entscheidung deshalb von der Uhr auf den Bestätigungszustand.

RFC 1122 formuliert den Zustand als SND.NXT > SND.UNA. Dann sind bereits gesendete Daten noch unbestätigt. Der Sender puffert neue Nutzdaten, unabhängig vom PSH-Bit, bis die ausstehenden Daten bestätigt sind oder die Warteschlange ein vollständiges Segment der Größe Eff.snd.MSS bilden kann. Ein vollständiges Segment ist somit eine eigene Freigabebedingung. Ist die Verbindung im Leerlauf und stehen keine Daten aus, darf die erste kleine Schreiboperation sofort gesendet werden.

RFC 1122 sagt, TCP solle Nagle implementieren, verlangt aber zugleich eine Möglichkeit, die Regel für eine einzelne Verbindung abzuschalten. RFC 9293 übernimmt diese normative Grenze und stellt klar, dass das Senden weiterhin dem Slow Start unterliegt. Nagle entscheidet über die Bildung eines weiteren kleinen Segments, nicht über eine allgemeine Sendefreigabe und nicht über Staukontrolle.

Auch den Zeitpunkt der Bestätigung durch den Empfänger legt Nagle nicht fest. RFC 9293 unterscheidet die Regel vom senderseitigen Verfahren zur Vermeidung des Silly Window Syndrome und warnt vor einer ungünstigen Wechselwirkung mit verzögerten Bestätigungen. Wartet der Sender auf ACK-Fortschritt, während der Empfänger sein ACK zurückhält, können zwei jeweils lokal sinnvolle Regeln an ihrer Grenze zusätzliche Verzögerung erzeugen.

Quellen