The Cable GuyAutomatische Optimierung des TCP-Empfangsfensters

Joseph Davies

Willkommen bei der ersten Ausgabe von The Cable Guy in TechNet Magazine. Fans der Kolumne auf der TechNet-Website wissen bereits, dass wir alle möglichen Netzwerkfragen behandeln. Diese Tradition werden wir hier jeden Monat fortsetzen. Falls Sie neu sind und ein Archiv der bisherigen Kolumnen suchen, gehen Sie zur Cable Guy-Site.

Nun zu unserem Thema hier: dem TCP-Empfangsfenster.

Der Durchsatz kann bei TCP-Verbindungen durch Senden und Empfang von Anwendungen, TCP-Implementierungen und dem Übertragungsweg zwischen den TCP-Peers beschränkt werden. In diesem Artikel werde ich das TCP-Empfangsfenster und seine Auswirkungen auf den TCP-Durchsatz, die Verwendung der TCP-Fensterskalierung und die neue Funktion zur automatischen Optimierung des TCP-Empfangsfensters in Windows Vista™ erläutern, die den TCP-Durchsatz für Empfangsdaten optimiert.

Das TCP-Empfangsfenster

TCP-Verbindungen haben einige wichtige Merkmale. Zunächst stellen sie logische Punkt-Punkt-Schaltungen zwischen zwei Anwendungsschicht-Protokollen dar. TCP unterstützt keinen zentralen Verteilungslieferdienst („One to Many“), sondern bietet nur Eins-zu-Eins-Lieferung („One to One“).

Zweitens sind TCP-Verbindungen verbindungsorientiert. Bevor Daten übertragen werden können, müssen zwei Anwendungsschicht-Prozesse formal eine TCP-Verbindung aushandeln. Dazu wird der Prozess zur TCP-Verbindungsherstellung verwendet. Auf ähnliche Weise werden TCP-Verbindungen nach der Aushandlung formal geschlossen, wozu der TCP-Verbindungsbeendigungs-Prozess eingesetzt wird.

Drittens werden zuverlässige Daten, die über eine TCP-Verbindung gesendet werden, sequenziert und eine positive Bestätigung durch den Empfänger wird erwartet. Wird keine positive Bestätigung empfangen, wird das Segment erneut übertragen. Beim Empfänger werden doppelte Segmente verworfen und Segmente, die nicht in der richtigen Reihenfolge eintreffen, wieder korrekt sortiert.

Viertes sind TCP-Verbindungen Vollduplex-Verbindungen. Für jeden TCP-Peer besteht die TCP-Verbindung aus zwei logischen Pipes: einer eingehenden und einer ausgehenden. Der TCP-Header enthält sowohl die Sequenznummer der ausgehenden Daten als auch eine Bestätigung (Acknowledgement oder ACK) der eingehenden Daten.

Darüber hinaus betrachtet TCP die über eingehende und ausgehende logische Pipes gesendeten Daten als kontinuierlichen Datenstrom. Die Sequenznummer und die Bestätigungsnummer in jedem TCP-Header werden zusammen mit den Byte-Grenzen definiert. TCP ist sich keiner Datensatz- oder Nachrichtengrenzen innerhalb des Datenstroms bewusst. Das Anwendungsschicht-Protokoll muss den eingehenden Datenstrom korrekt analysieren.

Um die Menge an Daten zu begrenzen, die zu einem bestimmten Zeitpunkt gesendet werden können und, um die empfängerseitige Flusssteuerung zu gewährleisten, verwenden TCP-Peers ein Fenster. Das Fenster ist die Datenspanne im Datenstrom, die der Empfänger dem Sender zu senden gestattet. Der Sender kann nur die Byte des Datenstroms senden, die innerhalb des Fensters liegen. Das Fenster folgt dem ausgehenden Datenstrom des Senders und dem eingehen Datenstrom des Empfängers.

Für eine bestimmte logische Pipe (eine Richtung der Vollduplex-TCP-Verbindung), pflegt der Sender ein Sende- und der Empfänger ein Empfangsfenster. Werden keine Daten oder ACK-Segmente übertragen, werden die Sende- und Empfangsfenster einer logischen Pipe in Übereinstimmung gebracht. Anders ausgedrückt: die Datenspanne im ausgehenden Datenstrom, die der Sender senden darf, wird mit der Datenspanne im eingehenden Datenstrom abgestimmt, die der Empfänger empfangen kann. Abbildung 1 illustriert diese Sende- und Empfangsbeziehung.

Abbildung 1 Sende- und Empfangsfenster abstimmen

Abbildung 1** Sende- und Empfangsfenster abstimmen **(Klicken Sie zum Vergrößern auf das Bild)

Um die Größe des Empfangsfensters anzugeben, enthält der TCP-Header ein 16-Bit-Fensterfeld. Wenn der Empfänger Daten erhält, sendet er ACKs zurück zum Sender und gibt darin die erfolgreich empfangenen Byte an. In jeder ACK gibt das Fensterfeld die Anzahl der Byte wieder, die im Empfangsfenster verbleiben. Wenn die Daten von der Anwendung gesendet, bestätigt und empfangen wurden, werden sowohl das Sende- als auch das Empfangsfenster nach rechts verschoben. Das Empfangsfenster steuert, wie viele unbestätigte Daten vom Sender zum Empfänger unterwegs sind.

Weil das Empfangsfenster Daten enthalten kann, die von der Anwendung nicht abgerufen werden, und solche, die empfangen, aber nicht bestätigt wurden, weist das TCP-Empfangsfenster eine zusätzliche Struktur auf, wie in Abbildung 2 dargestellt.

Abbildung 2 Datentypen im TCP-Empfangsfenster

Abbildung 2** Datentypen im TCP-Empfangsfenster **(Klicken Sie zum Vergrößern auf das Bild)

Beachten Sie den Unterschied zwischen dem maximalen und dem aktuellen Empfangsfenster. Das maximale Empfangsfenster hat eine feste Größe. Das aktuelle Empfangsfenster weist eine variable Größe auf und entspricht der restlichen Datenmenge, die der Empfänger dem Sender zu senden gestattet. Die Größe des aktuellen Empfangsfensters ist der Wert des Fensterfelds, der in ACKs mitgeteilt und an den Sender zurückgeschickt wurde. Dabei handelt es sich um die Differenz zwischen der maximalen Größe des Empfangsfensters und den Daten, die empfangen und bestätigt, von der Anwendung aber noch nicht abgerufen wurden.

Das TCP-Empfangsfenster und der TCP-Durchsatz

Um den TCP-Durchsatz zu optimieren (unter Voraussetzung eines einigermaßen fehlerfreien Übertragungswegs), sollte der Sender genug Pakete senden, um die logische Pipe zwischen Sender und Empfänger zu füllen. Die Kapazität der logischen Pipe kann mit der folgenden Formel berechnet werden:

Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds

Die Kapazität wird auch als Produkt aus Bandbreite und Verzögerung (Bandwidth Delay Product oder BDP) bezeichnet. Die Pipe kann dick (hohe Bandbreite), dünn (niedrige Bandbreite), kurz (geringe RTT) oder lang (hohe RTT) sein. Dicke, lange Pipes weisen das höchste BDP auf. Beispiele von Übertragungswegen mit hohem BDP sind z. B. solche über Satelliten oder unternehmensweite Wide Area Networks (WANs), die Interkontinental-Faseroptikverbindungen umfassen.

Verbesserung der senderseitigen Leistung für die Übertragung bei hohem BDP

Die neue Funktion zur automatischen Optimierung des TCP-Empfangsfensters bietet eine verbesserte Leistung für den Empfang von Daten über Hoch-BDP-Verbindungen. Wie sieht es aber mit der Senderleistung aus?

Die bestehenden Algorithmen, die verhindern, dass ein Sender-TCP-Peer das Netzwerk überlastet, werden als Slow Start und Congestion Avoidance bezeichnet. Diese Algorithmen vergrößern das Sendefenster (die Anzahl der Segmente, die der Sender senden kann), wenn Daten zum ersten Mal über die Verbindung gesendet und aus einem verlorenen Segment wiederhergestellt werden.

Slow Start vergrößert das Sendefenster um ein volles TCP-Segment für entweder jedes empfangene Bestätigungssegment (für TCP in Windows XP und Windows Server 2003) oder für jedes bestätigte Segment (für TCP in Windows Vista und Windows Server „Longhorn“). Congestion Avoidance vergrößert das Sendefenster um ein volles TCP-Segment für jedes bestätigte volle Datenfenster.

Diese Algorithmen funktionieren für kleine BDPs und kleinere Empfangsfenstergrößen einwandfrei. Wenn jedoch eine TCP-Verbindung mit großem Empfangsfenster und großem BDP vorliegt, z. B. Daten zwischen zwei Servern repliziert werden, die auf einer Hochgeschwindigkeits-WAN-Verbindung mit einer Round Trip Time von 100 ms zu finden sind, vergrößern diese Algorithmen das Sendefenster nicht schnell genug, um die Bandbreite der Verbindung voll zu nutzen.

Um die Bandbreite der TCP-Verbindungen in diesen Situationen besser zu nutzen, umfasst der TCP/IP-Stack der nächsten Generation Compound TCP (CTCP). CTCP vergrößert das Sendefenster für Verbindungen mit großen Empfangsfenstern und BDPs aggressiver. CTCP versucht, den Durchsatz bei diesen Verbindungstypen zu maximieren, indem Verzögerungsabweichungen und Verluste überwacht werden. CTCP stellt außerdem sicher, dass andere TCP-Verbindungen durch diese Anpassungen nicht negativ beeinflusst werden.

Bei intern von Microsoft durchgeführten Tests wurden lange Datei-Backup-Zeiten für eine 1-Gbit/s-Verbindung mit 50 ms RTT um fast die Hälfte reduziert. Bei Verbindungen mit einem größeren BDP kann sogar eine noch bessere Leistung erzielt werden. CTCP und automatische Optimierung des Empfangsfensters sorgen gemeinsam für eine verbesserte Ausnutzung der Netzwerkverbindung und können zu beträchtlichen Leistungssteigerungen für Verbindungen mit großen BDPs führen.

CTCP ist auf Computern mit Windows Server „Longhorn“ standardmäßig aktiviert, auf Windows Vista-Computern aber standardmäßig deaktiviert. CTCP kann mit dem Befehl „netsh interface tcp set global congestionprovider=ctcp“ aktiviert werden. CTCP kann mit dem Befehl „netsh interface tcp set global congestionprovider=none“ deaktiviert werden.

Die Größe des Fensterfelds im TCP-Header beträgt 16 Bit und ermöglicht einem TCP-Peer die Mitteilung einer maximalen Empfangsfenstergröße von 65.535 Byte. Der ungefähre Durchsatz für eine bestimmte TCP-Fenstergröße kann mit der folgenden Formel berechnet werden:

Throughput = TCP maximum receive windowsize / RTT

Beispiel: Bei einem Empfangsfenster von 65.535 Byte können Sie auf einem Übertragungsweg mit einer RTT von 100 ms nur einen ungefähren Durchsatz von 5,24 Megabit pro Sekunde (Mb/s) erzielen, egal, wie hoch die tatsächliche Bandbreite des Übertragungswegs ist. Bei den heutigen Hoch-BDP-Übertragungswegen wird die ursprünglich entwickelte TCP-Fenstergröße selbst bei ihrem Maximalwert zu einem Engpass.

TCP-Fensterskalierung

Um größere Fenstergrößen zu erhalten, die Hochgeschwindigkeits-Übertragungswege aufnehmen können, definiert RFC 1323 (ietf.org/rfc/rfc1323.txt) eine Fensterskalierung, die ermöglicht, dass ein Empfänger eine Fenstergröße von mehr als 65.535 Byte mitteilt. Eine TCP-Fensterskalierungsoption umfasst einen Fensterskalierungsfaktor, der in Kombination mit dem 16-Bit-Fensterfeld im TCP-Header die Empfangsfenstergröße auf einen Maximalwert von ca. 1 GB vergrößern kann. Die Fensterskalierungsoption wird während der Verbindungsherstellung nur in SYN-Segmenten gesendet. Beide TCP-Peers können unterschiedliche Fensterskalierungsfaktoren für ihre Empfangsfenstergrößen angeben. Indem einem Sender ermöglicht wird, mehr Daten über eine Verbindung zu senden, ermöglicht die TCP-Fensterskalierung die bessere Nutzung einiger Typen von Übertragungswegen mit hohen BDPs durch die TCP-Knoten.

Obgleich die Empfangsfenstergröße für den TCP-Durchsatz wichtig ist, besteht ein anderer wichtiger Faktor für die Bestimmung des optimalen TCP-Durchsatzes darin, wie schnell die Anwendung die angesammelten Daten im Empfangsfenster abruft (Anwendungsabrufrate). Ruft die Anwendung die Daten nicht ab, kann das Empfangsfenster gefüllt werden, was dazu führt, dass der Empfänger eine kleinere aktuelle Fenstergröße mitteilt. Im Extremfall wird das ganze maximale Empfangsfenster gefüllt und der Empfänger teilt eine Fenstergröße von 0 Byte mit. In diesem Fall muss der Sender die Datensendung stoppen, bis das Empfangsfenster freigemacht wurde. Um den TCP-Durchsatz zu optimieren, sollte daher das TCP-Empfangsfenster für eine Verbindung auf einen Wert eingestellt werden, der sowohl das BDP des Übertragungswegs der Verbindung als auch die Anwendungsabrufrate wiedergibt.

Selbst wenn Sie sowohl das BDP als auch die Anwendungsabrufrate korrekt bestimmen könnten, so können sie sich doch im Verlauf der Zeit ändern. Die BDP-Rate kann bei Überlastungen im Übertragungsweg variieren, und die Anwendungsabrufrate kann je nach Anzahl der Verbindungen, über die die Anwendung Daten empfängt, unterschiedlich sein.

Das Empfangsfenster in Windows XP

Für den TCP/IP-Stack in Windows XP (und Windows Server® 2003) weist die maximale Empfangsfenstergröße eine Reihe signifikanter Attribute auf. Zunächst basiert der Standardwert auf der Verbindungsgeschwindigkeit der Sendeschnittstelle. Der tatsächliche Wert wird automatisch auf gerade Inkremente der maximalen Segmentgröße (Maximum Segment Size oder MSS) angepasst, die während der TCP-Verbindungsherstellung ausgehandelt werden.

Zweitens kann die maximale Empfangsfenstergröße manuell konfiguriert werden. Die Registrierungswerte HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize and HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize können auf maximal 65.535 Byte (ohne Fensterskalierung) oder 1.073.741.823 (mit Fensterskalierung) eingestellt werden.

Drittens kann die maximale Empfangsfenstergröße die Fensterskalierung verwenden. Sie können die Fensterskalierung aktivieren, indem Sie den Registrierungswert HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts auf 1 oder 3 setzen. Standardmäßig wird die Fensterskalierung nur bei einer Verbindung verwendet, wenn das empfangene SYN-Segment die Fensterskalierungsoption enthält.

Schließlich kann die maximale Empfangsfenstergröße durch eine Anwendung mit Hilfe der SO_RCVBUF Windows Sockets-Option beim Einleitung einer Verbindung festgelegt werden. Für die Fensterskalierung muss die Anwendung eine Fenstergröße von mehr als 65.535 Byte festlegen.

Trotz der Unterstützung skalierbarer Fenster kann die maximale Empfangsfenstergröße in Windows XP den Durchsatz aufgrund der festen maximalen Größe für alle TCP-Verbindungen einschränken (außer von der Anwendung angegeben), wodurch der Durchsatz für einige Verbindungen gesteigert und für andere reduziert werden kann. Darüber hinaus variiert die feste maximale Empfangsfenstergröße für eine TCP-Verbindung nicht gemäß der Änderungen der Anwendungsabrufrate oder der Überlastung des Übertragungsweges.

Automatische Optimierung des Empfangsfensters in Windows Vista

Um den TCP-Durchsatz zu optimieren, besonders bei Übertragungswegen mit hohem BDP, unterstützt der TCP/IP-Stack der nächsten Generation in Windows Vista (und der nächsten Version von Windows Server mit dem Codenamen „Longhorn“) die automatische Optimierung des Empfangsfensters. Diese Funktion bestimmt die optimale Empfangsfenstergröße durch Messung des BDP und der Anwendungsabrufrate und Anpassung der Fenstergröße an den verwendeten Übertragungsweg und die Anwendungsbedingungen.

Die automatische Optimierung des Empfangsfensters ermöglicht standardmäßige TCP-Fensterskalierung bis zu einer maximalen Empfangsfenstergröße von 16 MB. Wenn die Daten über die Verbindung übertragen werden, überwacht der TCP/IP-Stack der nächsten Generation die Verbindung, misst das aktuelle BDP und die Anwendungsabrufrate und passt die Empfangsfenstergröße an, um den Durchsatz zu optimieren. Der TCP/IP-Stack der nächsten Generation verwendet den Registrierungswert TCPWindowSize nicht mehr.

Die automatische Optimierung des Empfangsfensters hat eine ganze Reihe von Vorteilen. Sie bestimmt automatisch die optimale Empfangsfenstergröße je nach der jeweiligen Verbindung. In Windows XP gilt der Registrierungswert TCPWindowSize für alle Verbindungen. Anwendungen müssen keine TCP-Fenstergrößen mehr mit Hilfe von Windows Sockets-Optionen festlegen. Außerdem müssen IT-Administratoren die TCP-Empfangsfenstergröße nicht mehr für spezifische Computer manuell konfigurieren.

Mit der automatischen Optimierung des Empfangsfensters teilt ein Windows Vista-basierter TCP-Peer in der Regel viel größere Empfangsfenster mit als ein Windows XP-basierter TCP-Peer. Dadurch kann der andere TCP-Peer die Pipe zum Windows Vista-basierten TCP-Peer füllen, indem mehr TCP-Datensegmente gesendet werden, ohne auf eine ACK (unterliegt TCP-Überlastungskontrolle) warten zu müssen. Für typischen Netzwerkverkehr auf Client-Basis wie z. B. Webpages oder E-Mail kann der Web- oder E-Mail-Server dann mehr TCP-Daten schneller an den Clientcomputer senden, was zu einer Gesamtsteigerung der Netzwerkleistung führt. Je höher BDP und Anwendungsabrufrate für die Verbindung, desto höher die Leistungssteigerung.

Die Auswirkungen auf das Netzwerk sind dahingehend, dass der Strom von TCP-Datenpaketen, der normalerweise bei niedrigerer Geschwindigkeit gesendet wird, viel schneller gesendet wird, was zu einer gesteigerten Netzwerkauslastung während der Datenübertragung führt. Für Windows XP- und Windows Vista-basierte Computer, die die gleiche Datenübertragung über eine lange, dicke Pipe durchführen, wird die gleiche Datenmenge übertragen. Die Datenübertragung ist aber für den Windows Vista-basierten Clientcomputer aufgrund des größeren Empfangsfensters und der Fähigkeit des Servers, die Pipe vom Server zum Client zu füllen, schneller.

Weil die automatische Optimierung des Empfangsfensters die Netzwerkauslastung von Hoch-BDP-Übertragungswegen verbessert, kann die Verwendung von Quality of Service (QoS)- oder Beschränkungen der Anwendungssendegeschwindigkeit für Übertragungswege wichtig werden, die mit oder fast mit voller Kapazität arbeiten. Um diesen möglichen Bedarf anzusprechen, unterstützt Windows Vista QoS-Einstellungen auf Gruppenrichtlinienbasis, mit denen Sie Beschränkungsraten für auf IP-Adress- oder TCP-Port-Basis gesendeten Verkehr definieren können. Weitere Informationen finden Sie in den Ressourcen zum richtlinienbasierten QoS.

Steigerung des TCP-Durchsatzes für Netzwerke mit hohen Verlustraten (High-Loss-Netzwerke)

High-Loss-Netzwerke können den TCP-Durchsatz aufgrund häufiger Zeitüberschreitungen und erneuter Übertragungen beträchtlich reduzieren. Beispiele für High-Loss-Netzwerke sind Drahtlosnetzwerke, z. B. solche, die auf IEEE 802.11, General Packet Radio Service (GPRS) oder Universal Mobile Telecommunications System (UMTS) basieren, die je nach Netzwerkbedingungen, Signaldämpfung, elektromagnetischer Interferenz und veränderten Standorten des Computers hohe Paketverluste aufweisen können.

Der TCP/IP-Stack der nächsten Generation unterstützt folgende vier RFCs, um den Durchsatz in Umgebungen mit hohen Verlustraten zu optimieren:

RFC 2582: Die NewReno-Änderung des TCP-Algorithmus für die schnelle Wiederherstellung

Der Algorithmus für die schnelle Wiederherstellung, der in RFC 2001 definiert ist, basiert auf dem Reno-Algorithmus, der die Datenmenge, die ein Sender senden kann, wenn ein Segment aufgrund eines Schnellneusendungs-Ereignisses erneut gesendet wird. Obgleich der Reno-Algorithmus für einzelne verlorene Segmente gut funktioniert, bietet er bei mehreren verlorenen Segmenten keine so gute Leistung. Der NewReno-Algorithmus bietet einen schnelleren Durchsatz, indem die Art und Weise geändert wird, mit der ein Sender seine Senderate bei der schnellen Wiederherstellung verbessern kann, wenn in einem Datenfenster mehrere Segmente verloren gehen und der Sender nur eine partielle Bestätigung erhält (eine Bestätigung lediglich für den Teil der Daten, der erfolgreich empfangen wurde).

RFC 2883: Eine Erweiterung der TCP-Option für selektive Bestätigung (Selective Acknowledgement, SACK)

SACK (definiert in RFC 2018) ermöglicht es dem Empfänger, bis zu vier nicht zusammenhängende, empfangene Datenblöcke mittels einer SACK TCP-Option anzuzeigen. RFC 2883 definiert eine zusätzliche Verwendung der Felder der SACK TCP-Option, um doppelte Pakete zu bestätigen. Dadurch kann der Sender bestimmen, wann er ein Segment unnötigerweise erneut übertragen hat und sein Verhalten anpassen, um in Zukunft unnötige erneute Übertragungen zu verhindern. Je weniger erneute Übertragungen gesendet werden, desto besser ist der Gesamtdurchsatz.

RFC 3517: Ein auf einer konservativen selektiven Bestätigung (SACK) basierender Verlustwiederherstellungsalgorithmus für TCP

Bei der Implementierung von TCP/IP in Windows Server 2003 und Windows XP werden SACK-Informationen lediglich verwendet, um zu ermitteln, welche TCP-Segmente ihr Ziel nicht erreicht haben. RFC 3517 definiert eine Methode zur Verwendung der SACK-Informationen für das Durchführen einer Verlustwiederherstellung, wenn doppelte Bestätigungen empfangen wurden. Dabei wird der ältere Algorithmus für eine schnelle Wiederherstellung ersetzt, wenn SACK für eine Verbindung aktiviert ist. Der TCP/IP-Stack der nächsten Generation verfolgt die SACK-Informationen für jede Verbindung und überwacht eingehende Bestätigungen und doppelte Bestätigungen, um Verluste rascher zu korrigieren, wenn mehrere Segmente am Ziel nicht empfangen wurden.

RFC 4138: Forward-RTO-Wiederherstellung (F-RTO): Ein Algorithmus zum Ermitteln von Zeitüberschreitungen bei vermeidbaren erneuten Übertragungen mit TCP und dem Stream Control Transmission Protocol (SCTP)

Vermeidbare erneute Übertragungen von TCP-Segmenten können auftreten, wenn ein plötzlicher, zeitweiliger Anstieg der RTT registriert wird, was dazu führt, dass Zeitüberschreitungen bei der erneuten Übertragung (Retransmission Timeouts oder RTOs) zuvor gesendeter Segmente abzulaufen beginnen und TCP beginnt, sie erneut zu übertragen. Tritt der Anstieg direkt vor dem Senden eines vollen Datenfensters auf, kann ein Sender das gesamte Datenfenster erneut übertragen. Der F-RTO-Algorithmus verhindert vermeidbare erneute Übertragungen von TCP-Segmenten wie folgt.

Wenn der RTO für mehrere Segmente abläuft, überträgt TCP nur das erste Segment erneut. Wird die erste Bestätigung empfangen, beginnt TCP mit dem Senden neuer Segmente (falls durch die mitgeteilte Fenstergröße zulässig). Wird durch die nächste Bestätigung bestätigt, dass bei den anderen Segmenten eine Zeitüberschreitung auftrat, diese aber noch nicht erneut übertragen wurden, bestimmt TCP, dass die Zeitüberschreitung vermeidbar war und überträgt die anderen Segmente mit Zeitüberschreitung nicht erneut.

In Umgebungen, in denen ein plötzliches, zeitweiliges Ansteigen der RTT, z. B. durch den Wechsel eines drahtlosen Clients zu einem anderen Wireless-Zugriffspunkt, verursacht wird, verhindert der F-RTO-Algorithmus erneute Segmentübertragungen und trägt damit zu einer schnellen Wiederherstellung der normalen Senderate bei. Die Verwendung der Verlustwiederherstellung auf SACK-Basis und von F-RTO sind am besten für GPRS-Verbindungen geeignet.

Joseph Davies arbeitet als technischer Autor bei Microsoft. Seit 1992 hält er Vorträge und schreibt zu Windows-Netzwerkthemen. Er hat fünf Bücher für Microsoft Press verfasst und ist der Autor der monatlichen TechNet Cable Guy-Kolumne.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.