TCP SACK (Selective Acknowledgment) (RFC 2018)

Windows 2000 unterstützt eine wichtige Leistungsfunktion, die als SACK (Selective Acknowledgement) bezeichnet wird. SACK ist besonders wichtig für Verbindungen, die große TCP-Fenstergrößen verwenden. Vor SACK konnte ein Empfänger nur die letzte Sequenznummer von fortlaufenden Daten bestätigen, die bei ihm eingegangen waren, oder den linken Rand des Empfangsfensters. Wenn SACK aktiviert ist, verwendet der Empfänger weiterhin die ACK-Nummer, um den linken Rand des Empfangsfensters zu bestätigen, kann aber auch andere nicht fortlaufende Blöcke von erhaltenen Daten einzeln bestätigen. SACK arbeitet mit TCP-Headeroptionen, wie unten dargestellt. Dieser Text wurde direkt aus der RFC 2018 übernommen:

"Sack-Permitted Option

"This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the SACK option once the connection has opened. It MUST NOT be sent on non-SYN segments.

TCP Sack-Permitted Option:
Kind: 4
+---------+---------+
| Kind=4 |Length=23shift.cnt|
+---------+---------+

"Format SACK-Option

"The SACK option is to be used to convey extended acknowledgment information from the receiver to the sender over an established TCP connection.

TCP SACK Option:

Wenn SACK aktiviert ist (die Standardeinstellung), kann ein Paket oder eine Reihe von Paketen verworfen werden, und der Empfänger kann dem Sender genau mitteilen, welche Daten er erhalten hat und wo die Lücken in den Daten sind. Der Sender kann die fehlenden Daten gezielt erneut übertragen, ohne die Datenblöcke noch einmal übertragen zu müssen, die bereits erfolgreich empfangen worden sind. SACK wird mit dem Registrierungsparameter SackOpts gesteuert. Die Aufzeichnung von Netzwerkmonitor unten zeigt einen Host, der alle Daten bis zu einer Sequenznummer 54857341 bestätigt, dazu die Sequenznummern 54858789-54861685.

+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x1A0D; Proto = TCP; Len: 64
TCP: .A...., len:0, seq:925104-925104, ack:54857341, win:32722,
src:1242 dst:139
TCP: Source Port = 0x04DA
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 925104 (0xE1DB0)
TCP: Acknowledgement Number = 54857341 (0x3450E7D)
TCP: Data Offset = 44 (0x2C)
TCP: Reserved = 0 (0x0000)
+ TCP: Flags = 0x10 : .A....
TCP: Window = 32722 (0x7FD2)
TCP: Checksum = 0xD55A
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
+ TCP: Timestamps Option
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
TCP: SACK Option
TCP: Option Type = 0x05
TCP: Option Length = 10 (0xA)
TCP: Left Edge of Block = 54858789 (0x3451425)
TCP: Right Edge of Block = 54861685 (0x3451F75)

TCP-Zeitstempel (RFC 1323)

Eine weitere Funktion der RFC 1323, die in Windows 2000 eingeführt wird, ist die Unterstützung von TCP-Zeitstempeln. Wie SACK sind Zeitstempel wichtig für Verbindungen, die mit großen Fenstergrößen arbeiten. Zeitstempel wurden entwickelt, um TCP bei der genauen Messung der RTT (Round-trip Time) zu unterstützen, damit die Zeitüberschreitungen für die Neuübertragung angepasst werden können. Die TCP-Headeroption für Zeitstempel wird hier gemäß RFC 1323 dargestellt:

Kind: 8
Length: 10 bytes

"The Timestamps option carries two four-byte time stamp fields. The time-stamp value field (TSval) contains the current value of the time-stamp clock of the TCP sending the option.

"The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echoes a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below.

"A TCP may send the Timestamps option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial segment for the connection."

Das Feld der Zeitstempeloption kann in einer Netzwerkmonitor-Aufzeichnung durch Erweitern des Feldes für die TCP-Optionen angezeigt werden, wie unten dargestellt:

TCP: Timestamps Option

Die Verwendung von Zeitstempeln ist standardmäßig deaktiviert. Sie kann mit dem Registrierungsparameter Tcp1323Opts aktiviert werden, wie in Anhang A erläutert.

Die PMTU-Suche wird in RFC 1191 beschrieben. Wenn eine Verbindung aufgebaut wird, tauschen die beiden daran beteiligten Hosts ihre Werte für die maximale TCP-Segmentgröße (maximum segment size, MSS) aus. Der kleinere der beiden MSS-Werte wird für die Verbindung verwendet. In der Vergangenheit war die MSS für einen Host die MTU in der Verbindungsschicht minus 40 Bytes für die IP- und TCP-Header. Durch die Unterstützung zusätzlicher TCP-Optionen, wie Zeitstempel, ist jedoch der typische TCP+IP-Header auf 52 und mehr Bytes gewachsen.

Wenn TCP-Segmente für ein nicht lokales Netzwerk bestimmt sind, wird das Bit "Keine Fragmentierung" im IP-Header gesetzt. Jeder Router oder jedes Medium entlang des Pfades kann eine MTU haben, die von der der beiden Hosts abweicht. Wenn ein Mediensegment eine MTU hat, die für das zu routende IP-Datagramm zu klein ist, versucht der Router, das Datagramm entsprechend zu fragmentieren. Er stellt dann fest, dass das Bit "Keine Fragmentierung" im IP-Header gesetzt ist. An diesem Punkt sollte der Router den sendenden Host informieren, dass das Datagramm nicht ohne Fragmentierung weitergeleitet werden kann. Dies erfolgt mit der Meldung ICMP Destination Unreachable Fragmentation Needed and DF Set. Die meisten Router geben auch die MTU für den nächsten Abschnitt an, indem sie den Wert dafür in die unteren 16 Bits des ICMP-Header-Feldes schreiben, der in RFC 792 nicht verwendet wird. Informationen zum Format dieser Meldung finden Sie in RFC 1191, Abschnitt 4. Nach dem Erhalten dieser ICMP-Fehlermeldung passt TCP seine MSS für die Verbindung an die angegebene MTU abzüglich der Größe der TCP- und IP-Header an, so dass alle weiteren Pakete, die über diese Verbindung versendet werden, nicht mehr die maximale Größe überschreiten, die den Pfad ohne Fragmentierung durchqueren kann.

Einige nicht kompatible Router können IP-Datagramme, die nicht fragmentiert werden können, stillschweigend verwerfen oder melden unter Umständen die MTU für den nächsten Abschnitt nicht korrekt. Wenn dies geschieht, kann es erforderlich sein, die Konfiguration des PMTU-Erkennungsalgorithmus zu ändern. Es gibt zwei Änderungen an der Registrierung, die an dem TCP/IP-Stapel in Windows 2000 vorgenommen werden können, um diese problematischen Geräte zu umgehen. Diese Registrierungseinträge werden ausführlich in Anhang A erläutert:

• 
  EnablePMTUBHDetect - Passt den Algorithmus zur PMTU-Suche so an, dass er Black Hole-Router erkennt. Das Erkennen von schwarzen Löchern ist standardmäßig deaktiviert.
  
• 
  EnablePMTUDiscovery - Aktiviert oder deaktiviert den Mechanismus zur PMTU-Suche vollständig. Wenn die PMTU-Suche deaktiviert ist, wird eine MSS von 536 Bytes für alle nicht lokalen Zieladressen verwendet. Die PMTU-Suche ist standardmäßig aktiviert.
  

ping -f -n -l

Wie in dem Beispiel unten dargestellt, kann der Parameter Größe variiert werden, bis die MTU gefunden wurde. Der Parameter Größe, der von dem Ping verwendet wird, ist die Größe des zu sendenden Datenpuffers, die Header sind darin nicht berücksichtigt. Der ICPM-Header belegt 8 Bytes und der IP-Header beträgt normalerweise 20 Bytes. In dem Fall unten (Ethernet) ist die maximale Übertragungseinheit der Verbindungsschicht der maximale Pingpuffer plus 28 oder 1500 Bytes:

C:\>ping -f -n 1 -l 1472 10.99.99.10

Pinging 10.99.99.10 with 1472 bytes of data:

Reply from 10.99.99.10: bytes=1472 time<10ms TTL=128

Ping statistics for 10.99.99.10:

Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging 10.99.99.10 with 1473 bytes of data:

Packet needs to be fragmented but DF set.

Ping statistics for 10.99.99.10:

Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

Approximate round trip times in milliseconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

In dem Beispiel oben hat die IP-Schicht eine ICMP-Fehlermeldung zurückgegeben, die Ping interpretiert hat. Wenn der Router ein Black Hole-Router gewesen wäre, würde Ping einfach keine Antwort erhalten, sobald die Größe des Datenpakets die maximale Übertragungseinheit übersteigt, die der Router verarbeiten kann. Ping kann auf diese Weise zum Erkennen eines solchen Routers verwendet werden.

Unten sehen Sie ein Beispiel für eine ICMP-Fehlermeldung Ziel nicht erreichbar:

******************************************************************************

Diese Fehlermeldung wurde unter Verwendung von Ping -f –n 1 -l 1000 auf einem ethernetbasierten Host generiert, um ein großes Datagramm über eine Routerschnittstelle zu senden, die nur eine MTU (maximale Übertragungseinheit) von 576 Bytes unterstützt. Als der Router versuchte, den großen Rahmen in das Netzwerk mit der kleineren MTU abzulegen, stellte er fest, dass die Fragmentierung nicht zulässig war. Daher gab er eine Fehlermeldung zurück, mit der er mitteilte, dass das größte Datagramm, das weitergeleitet werden kann, 0x240 oder 576 Bytes groß sein konnte.

Die Identifizierung deaktivierter Gateways wird verwendet, um TCP das Erkennen eines Ausfalls des Standardgateways zu ermöglichen und um die IP-Routingtabelle für die Verwendung eines anderen Standardgateways anzupassen. Der Microsoft TCP/IP-Stapel verwendet die in RFC 816 beschriebene Methode zur ausgelösten Neuauswahl leicht abgeändert aufgrund von Kundenerfahrung und Feedback.

Wenn eine über das Standardgateway geroutete TCP-Verbindung einige Male versucht hat, ein TCP-Paket an das Ziel zu senden (die Hälfte des Registrierungswertes TcpMaxDataRetransmissions gibt die genaue Anzahl von Versuchen an) und dabei keine Antwort erhält, ändert der Algorithmus den RCE (Route-Cache-Eintrag) für diese Remote-IP-Adresse, so dass das nächste Standardgateway in der Liste verwendet wird. Wenn 25 Prozent der TCP-Verbindungen zum nächsten Standardgateway verlagert worden sind, weist der Algorithmus IP an, das Standardgateway des Computers auf jenes zu ändern, das die Verbindungen nun verwenden.

Nehmen wir beispielsweise an, dass es gegenwärtig TCP-Verbindungen zu 11 verschiedenen IP-Adressen gibt, die über das Standardgateway geroutet werden. Nehmen wir nun einmal an, dass das Standardgateway ausfällt, dass ein zweites Standardgateway konfiguriert ist und dass der Wert für TcpMaxDataRetransmissions der Standardwert 5 ist.

Wenn die erste TCP-Verbindung versucht, Daten zu senden, erhält sie keine Bestätigungen. Nach der dritten Neuübertragung wird der RCE für diese Remote-IP-Adresse auf das nächste Standardgateway in der Liste geschaltet. Zu diesem Zeitpunkt haben alle TCP-Verbindungen zu dieser bestimmten Remote-IP-Adresse das Standardgateway gewechselt, aber die verbleibenden Verbindungen versuchen noch immer, das ursprüngliche Standardgateway zu verwenden.

Wenn die zweite TCP-Verbindung versucht, Daten zu senden, geschieht dasselbe noch einmal. Jetzt verweisen zwei der 11 RCEs auf das neue Gateway.

Wenn die dritte TCP-Verbindung versucht, Daten zu senden, haben nach dem dritten erneuten Versuch drei der 11 RCEs auf das zweite Standardgateway umgeschaltet. Da zu diesem Zeitpunkt über 25 Prozent der RCEs geändert wurden, wird nun das Standardgateway für den gesamten Computer auf das neue Standardgateway umgestellt.

Dieses Standardgateway bleibt das primäre für den Computer, bis Probleme auftreten (die den Algorithmus zur Identifizierung deaktivierter Gateways dazu veranlassen wieder das nächste in der Liste zu versuchen) oder bis der Computer neu gestartet wird.

Wenn die Suche das letzte Standardgateway erreicht, beginnt sie erneut am Anfang der Liste.

TCP-Verhalten bei Neuübertragungen

TCP startet einen Zeitgeber für die Neuübertragung, wenn ein ausgehendes Segment an IP weitergegeben wird. Wenn für die Daten in einem gegebenen Segment keine Bestätigung erhalten wird, bevor der Zeitgeber abläuft, wird das Segment erneut übertragen. Für neue Verbindungsanforderungen wird der Zeitgeber für die Neuübertragung auf 3 Sekunden initialisiert (steuerbar mit dem Registrierungsparameter pro Adapter TcpInitialRtt), und die Anforderung (SYN) wird maximal so oft erneut versendet, wie der Wert vonTcpMaxConnectRetransmissions angibt (in Windows 2000 standardmäßig zweimal). In bestehenden Verbindungen wird die Anzahl der Neuübertragungen von dem Registrierungsparameter TcpMaxDataRetransmissions gesteuert (standardmäßig 5). Die Zeitüberschreitung für die Neuübertragung wird "on the fly" angepasst, so dass sie den Charakteristika der Verbindung entspricht. Dazu werden die SRTT-Berechnungen (Smoothed Round Trip Time) verwendet, die in dem Whitepaper mit dem Titel "Congestion Avoidance and Control" von Van Jacobson beschrieben werden. Der Zeitgeber für ein gegebenes Segment wird nach jeder Neuübertragung dieses Segments verdoppelt. Mit diesem Algorithmus stellt TCP sich auf die normale Verzögerung einer Verbindung ein. Bei TCP-Verbindungen über Verbindungen mit hoher Verzögerung dauert es wesentlich länger, bis sich ein Zeitüberlauf ergibt, als bei solchen über Verbindungen mit niedriger Verzögerung.⁴

Der folgende Ausschnitt aus einer Ablaufverfolgung zeigt den Algorithmus der Neuübertragung für zwei Hosts, die über Ethernet auf demselben Subnetz verbunden sind. Es wurde gerade eine FTP-Dateiübertragung durchgeführt, als der empfangende Host vom Netzwerk getrennt wurde. Da die SRTT für diese Verbindung sehr gering war, erfolgte die erste Neuübertragung nach ca. einer halben Sekunde. Der Zeitgeber wurde dann für jede der folgenden Neuübertragungen verdoppelt. Nach der fünften Neuübertragung wurde der Zeitgeber noch einmal verdoppelt. Wenn keine Bestätigung erhalten wurde, bevor der Zeitgeber abläuft, wird die Verbindung abgebrochen.

delta source ip dest ip pro flags description

Es gibt gewisse Umstände, unter denen TCP Daten erneut überträgt, bevor der Zeitgeber für die Neuübertragung abgelaufen ist. Am häufigsten passiert dies aufgrund eines Funktion mit dem Namen fast retransmit (beschleunigte Neuübertragung). Wenn ein Empfänger, der fast retransmit (beschleunigte Neuübertragung) unterstützt, Daten mit einer Sequenznummer erhält, die über der erwarteten liegt, nimmt er an, dass einige Daten verloren gingen. Um den Sender über dieses Ereignis zu informieren, sendet der Empfänger unverzüglich eine ACK, bei der die ACK-Nummer auf die Sequenznummer festgelegt ist, die erwartet wurde. Der Empfänger wiederholt dies für jedes weitere ankommende TCP-Segment, das Daten enthält, die auf die fehlenden Daten in dem Eingangsstrom folgen. Wenn der Sender beginnt, einen Datenstrom von ACKs zu erhalten, die dieselbe Sequenznummer bestätigen und diese Sequenznummer vor der Sequenznummer liegt, die aktuell versendet wird, kann er davon ausgehen, dass ein Segment (oder mehrere) verloren gegangen sein müssen. Sender, die den Algorithmus für fast retransmit(beschleunigte Neuübertragung) unterstützen, senden das Segment, das der Empfänger erwartet, unverzüglich erneut, um die Datenlücke zu schließen. Sie warten nicht ab, bis der Zeitgeber für die Neuübertragung für dieses Segment abläuft. Diese Optimierung verbessert die Leistung in einer Netzwerkumgebung mit hohem Datenaufkommen ganz erheblich.

Standardmäßig sendet Windows 2000 ein Segment erneut, wenn es drei ACKs für dieselbe Sequenznummer erhält und die Sequenznummer hinter der aktuellen liegt. Dies läßt sich mit dem Registrierungsparameter TcpMaxDupAcks steuern. Weitere Informationen dazu finden Sie in dem Abschnitt "TCP SACK (Selective Acknowledgment) (RFC 2018)" dieses Whitepapers.

TCP-Keepalive-Meldungen

Ein TCP-Keepalive-Paket ist einfach eine ACK mit der Sequenznummer, die eine unter der aktuellen Sequenznummer für diese Verbindung liegt. Ein Host, der eine dieser ACKs erhält, antwortet mit einer ACK für die aktuelle Sequenznummer. Keepalives können verwendet werden, um zu überprüfen, ob der Computer an dem anderen Ende einer Verbindung noch erreichbar ist. TCP-Keepalives können einmal pro KeepAliveTime (Standardwert 7.200.000 Millisekunden oder zwei Stunden) gesendet werden, wenn keine Daten oder Keepalives einer höheren Ebene über die TCP-Verbindung transportiert wurden. Wenn keine Antwort auf ein Keepalive kommt, wird es alle KeepAliveInterval-Sekunden wiederholt. Der KeepAliveInterval -Standardwert ist 1 Sekunde. NetBT-Verbindungen, die von vielen Microsoft-Netzwerkkomponenten verwendet werden, senden NetBIOS-Keepalives häufiger, so dass normalerweise keine TCP-Keepalives in NetBIOS-Verbindungen versendet werden. TCP-Keepalives sind standardmäßig deaktiviert, aber Windows Sockets-Anwendungen können diese mit der Funktion setsockopt aktivieren.

Wenn eine Verbindung hergestellt wird, beginnt TCP zunächst langsam, um die Bandbreite der Verbindung zu ermitteln und einen Überlauf des empfangenden Hosts oder anderer Geräte oder Verbindungen in dem Pfad zu vermeiden. Das Sendefenster ist auf zwei TCP-Segmente festgelegt und wenn dies bestätigt wird, wird es auf drei Segmente erhöht.⁵ Wenn diese bestätigt werden, wird dieser Wert erneut erhöht usw., bis die Menge der versendeten Daten pro Burst die Größe des Empfangsfensters auf dem Remotehost erreicht. An diesem Punkt wird der Algorithmus für den langsamen Start nicht mehr verwendet, und die Steuerung des Datenflusses erfolgt über das Empfangsfenster. Dennoch kann es bei einer Verbindung während der Übertragung jederzeit zu einem Datenstau kommen. Wenn dies geschieht (ersichtlich aus der Notwendigkeit einer Neuübertragung), wird ein Algorithmus zur Vermeidung der Überlastung verwendet, um die Sendefenstergröße vorübergehend herabzusetzen und sie wieder an die Größe des Empfangsfensters anzupassen. Der langsame Start und die Vermeidung der Überlastung werden ausführlicher in RFC 1122 und RFC 2581 behandelt.

Das SWS wird in RFC 1122 folgendermaßen beschrieben:

"In brief, SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data [TCP:5]. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection."

In Windows 2000 TCP/IP wurde die Vermeidung des SWS implementiert, wie in RFC 1122 spezifiziert, indem keine weiteren Daten gesendet werden, bis ausreichend Fenstergröße vom Empfänger gemeldet wird, um ein ganzes TCP-Segment zu senden. Es wurde auch die Vermeidung des SWS beim Empfänger implementiert, indem das Empfangsfenster für Inkremente von weniger als einem TCP-Segment nicht geöffnet wird.

Windows NT und Windows 2000 TCP/IP implementieren den in RFC 896 beschriebenen Nagle-Algorithmus. Der Zweck dieses Algorithmus besteht darin, die Anzahl der sehr kleinen versendeten Segmente zu verringern, insbesondere bei (Remote)-Verbindungen mit hoher Verzögerung. Der Nagle-Algorithmus lässt nur zu, dass zu einem gegebenen Zeitpunkt ein kleines Segment ohne Bestätigung offen ist. Wenn mehr kleine Segmente generiert werden, während noch auf die ACK für das erste gewartet wird, werden diese Segmente zu einem größeren Segment zusammengefügt. Jedes Segment in voller Größe wird immer sofort übertragen, da davon ausgegangen wird, dass ein ausreichendes Empfangsfenster verfügbar ist. Der Nagle-Algorithmus ist effektiv beim Verringern der Anzahl der Pakete, die von interaktiven Anwendungen, wie z. B. Telnet, versendet werden, insbesondere im Falle von langsamen Verbindungen.

Der Nagle-Algorithmus kann in der folgenden Ablaufverfolgung beobachtet werden, die mit Microsoft Netzwerkmonitor aufgezeichnet wurde. Die Ablaufverfolgung wurde unter Verwendung von PPP zur Einwahl bei einem Internetdienstanbieter mit einer Übertragungsrate von 9600 aufgezeichnet. Eine Telnet-Sitzung (Zeichen-Modus) wurde aufgebaut, und dann wurde an der Windows NT Workstation die Taste Y gedrückt gehalten. Es wurde ständig ein Segment gesendet, und weitere Y-Zeichen wurden von dem Stapel zurückgehalten, bis eine Bestätigung für das vorherige Segment empfangen wurde. In diesem Beispiel wurden jedes Mal drei bis vier Y-Zeichen gepuffert und zusammen in einem Segment versendet. Der Nagle-Algorithmus führte zu enormen Einsparungen bei der Zahl der versendeten Pakete. Die Anzahl der Pakete wurde ungefähr um einen Faktor drei verringert.

Time Source IP Dest IP Prot Description

Jedes Segment enthielt mehrere der Y-Zeichen. Das erste Segment wird unten ausführlicher analysiert dargestellt, und der Datenteil wird in der Hexadezimalanzeige am unteren Rand dargestellt.

***********************************************************************
Time Source IP Dest IP Prot Description
0.644 204.182.66.83 199.181.164.4 TELNET To Server Port = 1901
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xEA83; Proto = TCP; Len: 43
+ TCP: .AP..., len: 3, seq:1032660278, ack: 353339017, win: 7766,
src: 1901 dst: 23 (TELNET)
TELNET: To Server From Port = 1901
TELNET: Telnet Data
D2 41 53 48 00 00 52 41 53 48 00 00 08 00 45 00 .ASH..RASH....E.
00 2B EA 83 40 00 20 06 F5 85 CC B6 42 53 C7 B5 .+..@. .....BS..
A4 04 07 6D 00 17 3D 8D 25 36 15 0F 86 89 50 18 ...m..=.%6....P.
1E 56 1E 56 00 00 79 79 79 .V.V..yyy
^^^
data

Windows Sockets-Anwendungen können den Nagle-Algorithmus für ihre Verbindungen deaktivieren, indem die Socketoption TCP_NODELAY eingestellt wird. Wenn dies nicht unbedingt erforderlich ist, ist jedoch davon abzuraten, da diese die Netzwerklast erhöht. Einige Netzwerkanwendungen können nicht ordnungsgemäß arbeiten, wenn sie nicht für die Auswirkungen der Übertragung großer Zahlen von kleinen Paketen und den Nagle-Algorithmus ausgelegt sind. Der Nagle-Algorithmus wird aus Leistungsgründen nicht auf Loopback-TCP-Verbindungen angewendet. Windows 2000 Netbt deaktiviert die Anwendung des Nagle-Algorithmus für NetBIOS über TCP-Verbindungen sowie für direkt gehostete Redirector-/Serververbindungen, was die Leistung für Anwendungen, die zahlreiche kleine Befehle zur Dateiverarbeitung ausgeben, verbessern kann. Als Beispiel wäre eine Anwendung zu nennen, die häufig Dateien sperrt/entsperrt.