The Cable Guy - November 2005

Verbesserungen im Next Generation TCP/IP-Stack im Bereich Leistung

Veröffentlicht: 01. Nov 2005

Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie unter http://www.microsoft.com/germany/technet/community/columns/cableguy/cgarch.mspx.

In diesem Artikel erfahren Sie mehr zu den Erweiterungen im Next Generation TCP/IP-Stack, die sich auf die Leistung auswirken. Zu diesen gehören zum Beispiel eine automatische Anpassung des Empfangsfensters, Verbesserungen für WLANs und eine bessere Erkennung von Routingpfaden.

Auf dieser Seite

	Einleitung
	Automatische Anpassung des Empfangsfensters
	Verbesserungen für WLAN-Netzwerke
	Verbesserte Erkennung und Wiederherstellung des Routingpfades
	Zusätzliche Informationen

Einleitung

Im TCP/IP-Stack von Microsoft Windows 2000 gab es einige Erweiterungen, die für eine bessere Leistung gesorgt haben - zum Beispiel die Fensterskalierung, selektive Empfangsbestätigungen und eine bessere Erkennung der Roundtrip Time (RTT). In den Jahren seit der Veröffentlichung von Windows 2000 hat sich beim Thema Netzwerkbandbreite jedoch viel geändert - es werden mehr Netze mit hoher Bandbreite und mehr WLANs genutzt. Der Next Generation TCP/IP-Stack von Windows Vista und Windows Server "Longhorn" umfasst Erweiterungen, die den Datendurchsatz in Netzen mit hoher Bandbreite, Latenz und hohen Verlustraten verbessern:

•	Automatische Anpassung des Empfangsfensters
•	Verbesserungen für WLAN-Netzwerke
•	Verbesserte Erkennung und Wiederherstellung des Routingpfades

Zum Seitenanfang

Automatische Anpassung des Empfangsfensters

Die Größe des TCP-Empfangsfensters legt fest, wie viele Bytes vom empfangenden Host zur Speicherung der über eine TCP-Verbindung eingehenden Daten verwendet werden. Nachdem die Verbindung aufgebaut wurde, wird die Fenstergröße mit jedem TCP-Segment übermittelt. Indem die Empfänger-Seite die Größe des noch freien Empfangsbuffers an den Sender übermittelt, kann sie verhindern, dass mehr Daten übermittelt werden, als gespeichert werden können. Der sendende Host kann nur maximal so viele Daten senden, wie vom Empfänger angegeben wurden. Dann muss er auf eine Empfangsbestätigung und die neue Angabe der Empfangsfenstergröße warten.

Empfangsfenster unter Windows Server 2003 und Windows XP

Für den TCP/IP-Stack von Windows Server 2003 und Windows XP gilt Folgendes für die Empfangsfenstergröße:

•	Es gibt einen Standardwert, der auf der Verbindungsgeschwindigkeit der sendenden Schnittstelle basiert. Um die während dem TCP-Verbindungsaufbau ausgehandelte maximale Segmentgröße (Maximum Segment Size - MSS) zu vergrößern, wird der Wert automatisch angepasst.
•	Sie kann manuell konfiguriert werden. Die Registrierungswerte HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize und HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\TCPWindowSize können Werte bis 65.535 Bytes (mit Fensterskalierung) oder 1.073.741.823 (ohne Fensterskalierung) annehmen. Ohne Fensterskalierung kann über einen Pfad mit einer RTT von 100 Millisekunden ein maximaler Durchsatz von 5 Megabit pro Sekunde (Megabit per second - Mbps) erreicht werden - unabhängig von der Bandbreite des verwendeten Pfades.
•	Sie kann mit Fensterskalierung bis zu 1 Gigabyte groß werden. Die Fensterskalierung wird in RFC 1323 definiert. Sie ermöglicht es TCP, während des Verbindungsaufbaus einen Skalierungsfaktor für die Fenstergröße auszuhandeln. Sie können die Fensterskalierung über den Registrierungswert HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts aktivieren. Setzen Sie seinen Wert auf 1 oder 3. Standardmäßig wird die Fensterskalierung nur dann verwendet, wenn die entsprechende Option in einem SYN-Segment (Synchronize) gesetzt ist.
•	Sie kann von einer Anwendung geändert werden. Eine Anwendung kann während der Verbindungsinitiierung mithilfe der Windows-Sockets-Option SO_RCVBUF die maximale Fenstergröße definieren. Damit die Fensterskalierung genutzt wird, muss die Anwendung eine Fenstergröße angeben, die über 65.535 Byte liegt.

Oft ist es schwer, die korrekte Größe des Empfangsfensters zu ermitteln. Damit die Netzwerkkapazität zwischen Sender und Empfänger auch ausgenutzt wird, sollte die Fenstergröße so groß sein, wie die Bandbreite multipliziert mit der RTT (Round-Trip Time) ist (das Bandbreitenprodukt). Wenn Sie diesen Wert korrekt gewählt haben, wissen Sie leider trotzdem nicht genau, wie schnell die empfangende Anwendung die Daten aus dem Empfangsbuffer holen kann.

Da keine skalierbaren Fenster unterstützt werden, kann es unter Windows Server 2003 und Windows XP auch bei einer maximalen Fenstergröße so sein, dass der Datendurchsatz nicht optimal ist. Es handelt sich nämlich um eine feste Größe, die für alle TCP-Verbindungen gilt. Diese ist vielleicht für manche Verbindungen passend (und verbessert deren Datendurchsatz), für andere Verbindungen jedoch nicht. Außerdem passt sich die feste Größe natürlich nicht an möglicherweise veränderte Bedingungen im Netzwerk an.

Empfangsfenster im Next Generation TCP/IP-Stack

Um die maximale Empfangsfenstergröße besser festzulegen (auf Basis der aktuellen Bedingungen im Netzwerk), unterstützt der Next Generation TCP/IP-Stack die automatische Anpassung des Empfangsfensters. Diese Funktionalität legt das optimale Empfangsfenster permanent neu fest. Hierzu werden das Bandbreitenprodukt und die Abfragerate der Anwendung ständig überprüft.

Die Funktionalität ermöglicht so eine standardmäßige Fensterskalierung und eine Fenstergröße von bis zu 16 MB. Beim Next Generation TCP/IP-Stack wird der Registrierungswert TCPWindowSize nicht mehr verwendet.

Durch den besseren Datendurchsatz wird die Netzwerkbandbreite während der Datenübertragung besser genutzt. Wenn alle Anwendungen für den Empfang von TCP-Daten optimiert sind, dann kann die Gesamtauslastung des Netzwerkes grundlegend gesteigert werden. Bei Netzwerken, die am Rande ihrer verfügbaren Kapazität arbeiten, wird daher die Verwendung von Quality of Service (QoS) deutlich wichtiger.

Zum Seitenanfang

Verbesserungen für WLAN-Netzwerke

WLANs, basierend zum Beispiel auf IEEE 802.11, GPRS (General Packet Radio Service) oder UMTS (Universal Mobile Telecommunications System), stellen nahtlose Konnektivität für tragbare Computer zur Verfügung. In WLANs kann es jedoch auch, abhängig von den Bedingungen im Netzwerk, den Signalstärken, elektromagnetischen Interferenzen und Standortveränderungen der mobilen Computer, zu hohen Paketverlusten kommen. Regelmäßige TCP-Timeouts und Neuübertragungen können den Datendurchsatz in solchen Umgebungen drastisch verschlechtern.

Der Next Generation TCP/IP-Stack optimiert den Datendurchsatz in solchen Umgebungen, indem die folgenden RFCs unterstützt werden:

•	RFC 2582: Die NewReno-Modifikation des TCP-Fast Recovery Algorithmus Der Fast Recovery-Agorithmus wurde in RFC 2001 definiert. Er basiert auf dem Reno-Algorithmus, der die Datenmenge, die ein Sender bei der Neuübermittlung eines Segments verschicken kann, verringert. Der Reno-Algorithmus funktioniert bei einzelnen verlorenen Segmenten zwar hervorragend, dies gilt jedoch nicht mehr, wenn mehrere Segmente verloren gehen. Der NewReno-Algorithmus ermöglicht einen schnelleren Datendurchsatz. Er ermöglicht Empfangsbestätigungen für Teile der erfolgreich empfangenen Daten.
•	RFC 2883: Eine Erweiterung der SACK-Option von TCP (Selective Acknowledgement - selektive Empfangsbestätigungen) SACK wurde in RFC 2018 definiert und ermöglicht es dem Empfänger, bis zu vier nicht aufeinander folgende Datenblöcke zu erkennen. RFC 2883 definiert eine weitere Verwendung der SACK-TCP-Felder. Mit ihr werden doppelte Pakete bestätigt. Der Sender kann so bei Paketen mit SACK-Option erkennen, wenn ein Segment unnötig neu übertragen wurde. Er kann dies dann bei zukünftigen Übertragungen berücksichtigen.
•	RFC 3517: Ein SACK-basierter Loss Recovery-Algorithmus für TCP Die aktuelle TCP/IP-Implementierung unter Windows Server 2003 und Windows XP nutzt die SACK-Informationen nur, um festzustellen, welche TCP-Segmente nicht beim Empfänger angekommen sind. RFC 3517 definiert ein Verfahren, bei dem Pakete bei doppelten Empfangsbestätigungen wiederhergestellt werden können. Der Next Generation TCP/IP-Stack verfolgt die SACK-Informationen auf Verbindungsbasis und überwacht eingehende Empfangsbestätigungen. So kann beim Verlust von mehreren Segmenten eine schnellere Wiederherstellung durchgeführt werden.
•	RFC 4138: Forward RTO-Recovery (F-RTO) - ein Algorithmus zur Erkennung von falschen Retransmission-Timeouts für TCP und SCTP (Stream Control Transmission Protocol) Falsche Neuübertragungen (Retransmissions) von TCP-Segmenten können zum Beispiel dann auftreten, wenn die RTT plötzlich und nur temporär steigt. Wenn dies passiert, dann fangen die RTOs (Retransmission Timeouts) bereits gesendeter Pakete an abzulaufen. TCP beginnt daher, sie neu zu übertragen. Wenn dies kurz vor dem Versenden von Daten mit der Größe eines kompletten Empfangsfensters passiert, kann der Sender das gesamte Fenster erneut versenden. Der F-RTP-Algorithmus verhindert falsche Neuübertragungen. Er geht dabei folgendermaßen vor: Wenn die RTO mehrerer Segmente abläuft, dann überträgt TCP nur das erste Segment neu. Wenn die erste Empfangsbestätigung eingeht, dann fängt TCP an, neue Segmente zu übertragen (wenn dies durch die angegebene Fenstergröße möglich ist). Wenn die nächste Empfangsbestätigung einen Timeout für weitere Segmente anzeigt und diese nicht neu übertragen wurden, dann erkennt TCP, dass der Timeout falsch ist und überträgt die Segmente auch nicht erneut. Dieses Verhalten führt dazu, dass ein plötzliches Steigen der RTT (zum Beispiel, wenn ein WLAN-Client von einem AP zu einem anderen wechselt) nicht zu unnötigen Neuübertragungen führt.

Zum Seitenanfang

Verbesserte Erkennung und Wiederherstellung des Routingpfades

Um bei der Neuübertragung von Segmenten automatisch einen neuen Routingpfad wählen zu können, unterstützt der TCP/IP-Stack von Windows Server 2003 und Windows XP die Dead-Gateway-Erkennung. Bei der Dead-Gateway-Erkennung handelt es sich um einen Failover-Mechanismus, der das Standardgateway eines Computers automatisch auf das sekundäre Gateway ändert (wenn dies konfiguriert ist). Bei der Dead-Gateway-Erkennung von Windows Server 2003 und Windows XP fehlt jedoch die folgende Funktionalität:

•	Sie kann nicht erkennen, ob das lokale Standardgateway oder ein Remotegateway (Router) ausgefallen ist.
•	Sie verfügt über kein Failback-Verfahren, um das Standardgateway zurück auf das primäre Gateway zu ändern (zum Beispiel, wenn der primäre Routingpfad wiederhergestellt wurde).

Der Next Generation TCP/IP-Stack berücksichtigt diese Aufgaben mit seiner Neighbor Unreachability Detection für IPv4 und der integrierten Unterstützung eines Failback.

Neighbor Unreachability Detection für IPv4

Neighbor Unreachability Detection ist ein Feature von IPv6, mit dem ein Knoten feststellen kann, ob ein Nachbarknoten erreichbar ist. Als erreichbar gilt ein Nachbarknoten dann, wenn dieser bestätigt hat, dass er an ihn gesendete IPv6-Pakete erhalten hat (über unicast Neighbor-Solicitation- und Neighbor-Advertisement-Nachrichten oder über Protokolle weiter oben liegender Schichten). Mit der Neighbor Unreachability Detection kann ein IPv6-Knoten feststellen, dass ein Nachbarknoten nicht mehr erreichbar ist, und dies anderen Komponenten und Anwendungen mitteilen.

Der Next Generation TCP/IP-Stack unterstützt Neighbor Unreachability Detection für IPv4-Netzwerkverkehr, indem er den Status der IPv4-Nachbarn im IPv4-Routing-Cache festhält. Dies geschieht mithilfe von unicast ARP-Request und ARP-Reply-Nachrichten oder durch ein Protokoll einer höheren Schicht (zum Beispiel TCP).

Beim Next Generation TCP/IP-Stack versucht der Stack, vor der Neuübertragung von Segmenten festzustellen, ob das aktuelle Standardgateway noch erreichbar ist. Wenn dieses nicht antwortet, dann wird das Standardgateway geändert.

Failback für Änderungen des Standardgateways

Beim TCP/IP-Stack von Windows Server 2003 und Windows XP wird ein einmal geändertes Standardgateway auch dann nicht wieder zurückgesetzt, wenn das ursprüngliche Gateway wieder verfügbar ist. Es gibt also eine Failover-Funktion, jedoch keine Failback-Funktion.

Das Fehlen dieser Failback-Funktion kann zu Problemen beim Datendurchsatz führen - zum Beispiel in einem Subnetz, in dem zwei Router vorhanden sind: ein primärer Router mit hoher Leistung und ein zweiter Backup-Router mit geringer Leistung.

Der Next Generation TCP/IP-Stack bietet nun ein Failback. Er sendet regelmäßig TCP-Anfragen an das ausgefallene Gateway. Wenn dies erfolgreich ist, dann wird das Standardgateway wieder gewechselt.

Zum Seitenanfang

Zusätzliche Informationen

Zusätzliche Informationen zu TCP/IP unter Windows finden Sie unter:

•	Next Generation TCP/IP-Stack unter Windows Vista und Windows Server Longhorn
•	Microsoft Windows Server 2003 TCP/IP Implementation Details (englischsprachig)

Zum Seitenanfang