Leistungsoptimierung für Netzwerkadapter
Gilt für Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI (Version 21H2 und 20H2)
Mithilfe der Informationen in diesem Thema können Sie die Leistung von Netzwerkadaptern für Computer optimieren, auf denen Windows Server 2016 und höhere Versionen ausgeführt werden. Wenn Ihre Netzwerkadapter Optimierungsoptionen bereitstellen, können Sie mithilfe dieser Optionen den Netzwerkdurchsatz und die Ressourcennutzung optimieren.
Die richtige Abstimmung der Einstellungen für Ihre Netzwerkadapter hängt von den folgenden Variablen ab:
- Dem Netzwerkadapter und seiner festgelegten Features
- Der Typ der auf dem Server ausgeführten Workloads
- Der Serverhardware- und Softwareressourcen
- Von Ihren Leistungszielen in Bezug auf den Server
In den folgenden Abschnitten werden einige Ihrer Feineinstellungsoptionen beschrieben.
Aktivieren von Auslagerungsfeatures
Das Aktivieren von Netzwerkadapter-Auslagerungsfeatures ist für gewöhnlich nützlich. Möglicherweise ist der Netzwerkadapter jedoch nicht leistungsstark genug, um die Auslagerungsfunktionen mit hohem Durchsatz zu verarbeiten.
Wichtig
Verwenden Sie nicht die Auslagerungsfeatures IPsec-Aufgabenverlagerung oder TCP-Chimneyabladung. Diese Technologien sind in Windows Server 2016 veraltet und können negative Auswirkungen auf die Server- und Netzwerkleistung haben. Darüber hinaus werden diese Technologien in Zukunft möglicherweise von Microsoft nicht mehr unterstützt.
Betrachten Sie beispielsweise einen Netzwerkadapter, der über begrenzte Hardwareressourcen verfügt. In diesem Fall kann das Aktivieren von Segmentierungsauslagerungsfeatures den maximal aufrechterhaltenen Durchsatz des Adapters verringern. Wenn der geringere Durchsatz jedoch akzeptabel ist, sollten Sie die Segmentierungsauslagerungsfeatures aktivieren.
Hinweis
Bei einigen Netzwerkadaptern ist es erforderlich, Auslagerungsfeatures unabhängig für Sende- und Empfängerpfade zu aktivieren.
Aktivieren von RSS (Receive-Side Scaling, empfangsseitige Skalierung) für Webserver
RSS kann die Webskalierbarkeit und Leistung verbessern, wenn weniger Netzwerkadapter als logische Prozessoren auf dem Server vorhanden sind. Wenn der gesamte Webdatenverkehr die RSS-fähigen Netzwerkadapter durchläuft, können eingehende Webanforderungen von unterschiedlichen Verbindungen gleichzeitig über verschiedene CPUs hinweg verarbeitet werden.
Wichtig
Vermeiden Sie es, gleichzeitig RSS-fähige und Nicht-RSS-Netzwerkadapter auf demselben Server zu verwenden. Aufgrund der Lastenverteilungslogik in RSS und HTTP kann die Leistung erheblich sinken, wenn ein nicht RSS-fähiger Netzwerkadapter Webdatenverkehr auf einem Server akzeptiert, der über mindestens einen RSS-fähigen Netzwerkadapter verfügt. In diesem Fall sollten Sie RSS-fähige Netzwerkadapter verwenden oder RSS in den Netzwerkadaptereigenschaften auf der Registerkarte Erweiterte Eigenschaften deaktivieren.
Um zu bestimmen, ob ein Netzwerkadapter RSS-fähig ist, können Sie die RSS-Informationen in den Netzwerkadaptereigenschaften auf der Registerkarte Erweiterte Eigenschaften anzeigen.
RSS-Profile und RSS-Warteschlangen
Das vordefinierte RSS-Standardprofil ist NUMAStatic. Es unterscheidet sich von dem Standard, der in vorherigen Versionen von Windows verwendet wurde. Bevor Sie RSS-Profile verwenden, überprüfen Sie die verfügbaren Profile, um zu verstehen, wann sie hilfreich sind und wie sie Ihre Netzwerkumgebung und Hardware betreffen.
Wenn beispielsweise die im Task-Manager angezeigten logischen Prozessoren auf Ihrem Server anscheinend nicht ausreichend für den eingehenden Datenverkehr ausgelastet sind, können Sie versuchen, die Anzahl der RSS-Warteschlangen vom Standardwert 2 auf das unterstützte Maximum Ihres Netzwerkadapters zu erhöhen. Ihr Netzwerkadapter verfügt möglicherweise über Optionen zum Ändern der Anzahl der RSS-Warteschlangen als Bestandteil des Treibers.
Erhöhen von Netzwerkadapterressourcen
Bei Netzwerkadaptern, die die manuelle Konfiguration von Ressourcen wie Puffern zum Empfangen und Senden gestatten, sollten Sie die zugeordneten Ressourcen erhöhen.
Einige Netzwerkadapter legen ihre Puffer zum Empfangen auf niedrige Werte fest, um vom Host zugeordneten Arbeitsspeicher zu sparen. Der geringe Wert hat verworfene Pakete und eine verringerte Leistung zur Folge. Daher sollten Sie in Szenarien, die „empfangsintensiv“ sind, die Anzahl des Pufferwerts für das Empfangen auf das Maximum festlegen.
Hinweis
Wenn ein Netzwerkadapter die manuelle Ressourcenkonfiguration nicht zur Verfügung stellt, konfiguriert er die Ressourcen entweder dynamisch, oder die Ressourcen sind auf einen festen Wert festgelegt, der nicht geändert werden kann.
Aktivieren der Interruptüberprüfung
Zum Steuern der Interruptüberprüfung stellen einige Netzwerkadapter unterschiedliche Interruptüberprüfungsebenen oder Parameter zum Zusammenführen von Puffern (manchmal getrennt für Puffer zum Senden und Empfangen) zur Verfügung.
Sie sollten die Interruptüberprüfung für CPU-basierte Workloads in Betracht ziehen. Wenn Sie Interruptüberprüfung verwenden, sollten und einen Kompromiss zwischen CPU-Einsparungen und Latenz und erhöhten Host-CPU-Einsparungen in Betracht ziehen, da hier mehr Interrupts mit geringeren Latenzen vorliegen. Wenn der Netzwerkadapter keine Interruptüberprüfung ausführt, aber zusammengeführte Puffer zur Verfügung stellt, können Sie die Leistung verbessern, indem Sie die Anzahl zusammengeführter Puffer erhöhen und dadurch mehr Puffer zum Senden oder Empfangen ermöglichen.
Abstimmen der Verarbeitung von Paketen mit niedriger Latenz
Viele Netzwerkadapter bieten Optionen zum Optimieren der betriebssystembedingten Latenz. Latenz ist die Ablaufzeit, die zwischen der Netzwerktreiberverarbeitung eines eingehenden Pakets und dem Zurücksenden des Pakets durch den Netzwerktreiber vergeht. Diese Zeit wird für gewöhnlich in Mikrosekunden gemessen. Zum Vergleich wird die Übertragungszeit für Paketübertragungen über lange Distanzen hinweg normalerweise in Millisekunden (aufgrund der größeren Größe) gemessen. Diese Feineinstellung reduziert jedoch nicht die Zeit, die ein Paket übertragen wird.
Im Folgenden finden Sie einige Vorschläge zur Leistungsfeineinstellung für mikrosekundenbezogene Netzwerke.
Legen Sie das Computer-BIOS auf High Performance mit deaktivierten C-Status fest. Beachten Sie jedoch, dass dies system- und BIOS-abhängig ist, und einige Systeme bieten eine höhere Leistung, wenn das Betriebssystem die Energieverwaltung steuert. Sie können Ihre Energieverwaltungseinstellungen in den Einstellungen anzeigen und anpassen oder indem Sie den Befehl powercfg verwenden. Weitere Informationen finden Sie unter Powercfg-Befehlszeilenoptionen.
Legen Sie das Energieverwaltungsprofil des Betriebssystems auf Höchstleistung fest.
Hinweis
Diese Einstellung funktioniert nicht richtig, wenn die Betriebssystemsteuerung der Energieverwaltung im System-BIOS deaktiviert wurde.
Aktivieren Sie statische Auslagerungen. Aktivieren Sie beispielsweise die Einstellungen „UDP Checksums“, „TCP Checksums“ und „Send Large Offload (LSO)“.
Wenn der Datenverkehr mehrfach gestreamt wird, z. B. beim Empfangen von Multicastdatenverkehr mit hohem Volumen, aktivieren Sie RSS.
Deaktivieren Sie die Einstellung Interruptüberprüfung für Netzwerkkartentreiber, für die die geringstmögliche Latenz erforderlich ist. Denken Sie daran, dass diese Konfiguration mehr CPU-Zeit in Anspruch nehmen kann und einen Kompromiss darstellt.
Verarbeiten Sie Netzwerkadapterunterbrechungen und DPCs auf einem Kernprozessor, der CPU-Cache gemeinsam mit dem Kern verwendet, der durch das Programm verwendet wird (Benutzerthread), welches das Paket verarbeitet. Die CPU-Affinitätsfeineinstellung kann zum Lenken eines Vorgangs zu bestimmten logischen Prozessoren in Verbindung mit der RSS-Konfiguration verwendet werden. Das Verwenden des gleichen Kerns für den Interrupt, DPC und Benutzermodusthread zieht eine schlechte Leistung und eine erhöhte Last nach sich, da ISR, DPC und der Thread den Kern für sich beanspruchen.
Systemverwaltungsinterrupts
Viele Hardwaresysteme verwenden Systemverwaltungsinterrupts (System Management Interrupts, SMI) für verschiedene Verwaltungsoptionen wie Berichterstellung in Bezug auf ECC-Speicherfehler (Error Correction Code, Fehlerberichtigungscode), Legacy-USB-Kompatibilität, Lüftungssteuerung und BIOS-gesteuerte Energieverwaltung.
Der SMI ist der Interrupt mit der höchsten Priorität im System und versetzt die CPU in einen Verwaltungsmodus. In diesem Modus werden alle anderen Aktivitäten blockiert, während der SMI eine Interrupt Service Routine ausführt, die normalerweise im BIOS vorhanden ist.
Dies kann leider Latenzspitzenwerte von 100 Mikrosekunden und mehr zur Folge haben.
Wenn Sie die geringe Latenz erzielen müssen, sollten Sie eine BIOS-Version Ihres Hardwareanbieters beziehen, die die SMIs auf den kleinsten möglichen Grad reduziert. Diese BIOS-Versionen werden häufig als „BIOS mit niedriger Latenz“ oder „SMI-freies BIOS“ bezeichnet. In einigen Fällen ist es für eine Hardwareplattform nicht möglich, SMI-Aktivitäten vollständig zu beseitigen, da sie zur Steuerung wesentlicher Funktionen (z. B. Lüfter) verwendet wird.
Hinweis
Das Betriebssystem kann die SMIs nicht steuern, da der logische Prozessor in einem speziellen Wartungsmodus ausgeführt wird, der eine Einmischung des Betriebssystems verhindert.
TCP-Leistungsabstimmung
Sie können die TCP-Leistung über die folgenden Elemente optimieren.
Automatische Optimierung des TCP-Empfangsfensters
In Windows Vista, Windows Server 2008 und höheren Versionen von Windows nutzt der Windows-Netzwerkstapel ein Feature mit der Bezeichnung Automatische Optimierung des TCP-Empfangsfensters, um die Größe des TCP-Empfangsfensters auszuhandeln. Dieses Feature kann eine definierte Empfangsfenstergröße für jede TCP-Kommunikation während des TCP-Handshakes aushandeln.
In früheren Versionen von Windows wurde für den Windows-Netzwerkstapel ein Empfangsfenster mit fester Größe (65.535 Bytes) verwendet, das den gesamten möglichen Durchsatz für Verbindungen beschränkte. Der insgesamt erreichbare Durchsatz von TCP-Verbindungen kann eventuell die Szenarien der Netzwerknutzung einschränken. Die automatische Optimierung des TCP-Empfangsfensters ermöglicht es in diesen Szenarien, das Netzwerk vollständig zu nutzen.
Für ein TCP-Empfangsfenster mit einer bestimmten Größe können Sie den Gesamtdurchsatz einer einzelnen Verbindung mit der folgenden Gleichung berechnen.
Gesamter erreichbarer Durchsatz in Byte = TCP-Empfangsfenstergröße in Byte * (1 / Verbindungslatenz in Sekunden)
Bei einer Verbindung mit einer Latenz von 10 ms beträgt der gesamte erreichbare Durchsatz beispielsweise nur 51 MBit/s. Dieser Wert ist für eine große Unternehmensnetzwerkinfrastruktur angemessen. Durch die automatische Optimierung zum Anpassen des Empfangsfensters kann die Verbindung jedoch die volle Leitungsgeschwindigkeit einer Verbindung mit 1 GBit/s erreichen.
Einige Anwendungen definieren die Größe des TCP-Empfangsfensters. Wenn die Anwendung die Größe des Empfangsfensters nicht definiert, bestimmt die Verbindungsgeschwindigkeit die Größe wie folgt:
- Weniger als 1 MBit/s (Megabit pro Sekunde): 8 KB (Kilobyte)
- 1 MBit/s bis 100 MBit/s: 17 KB
- 100 MBit/s bis 10 GBit/s (Gigabit pro Sekunde): 64 KB
- 10 GBit/s oder höher: 128 KB
Auf einem Computer, auf dem ein Netzwerkadapter mit 1 GBit/s installiert ist, sollte die Fenstergröße beispielsweise 64 KB betragen.
Dabei werden auch andere Features genutzt, um die Netzwerkleistung zu verbessern. Diese Features umfassen die restlichen TCP-Optionen, die in RFC 1323 definiert sind. Mithilfe dieser Features können Windows-basierte Computer TCP-Empfangsfenstergrößen aushandeln, die kleiner sind, aber je nach Konfiguration mit einem definierten Wert skaliert werden. Durch dieses Verhalten sind die Größen für Netzwerkgeräte einfacher zu handhaben.
Hinweis
Möglicherweise tritt ein Problem auf, bei dem das Netzwerkgerät nicht mit der TCP-Fensterskalierungsoption entsprechend der Definition in RFC 1323 konform ist und daher den Skalierungsfaktor nicht unterstützt. In solchen Fällen finden Sie Informationen in KB 934430: Netzwerkkonnektivität schlägt fehl, wenn Sie versuchen, Windows Vista hinter einem Firewallgerät zu verwenden, oder Sie können sich an das Supportteam Ihres Netzwerkgeräteherstellers wenden.
Überprüfen und Konfigurieren der Ebene der automatischen Optimierung für das TCP-Empfangsfenster
Sie können die Ebene der automatischen Optimierung für das TCP-Empfangsfenster über netsh-Befehle oder Windows PowerShell-Cmdlets überprüfen oder ändern.
Hinweis
Im Gegensatz zu Windows-Versionen vor Windows 10 oder Windows Server 2019 können Sie die TCP-Empfangsfenstergröße nicht mehr in der Registrierung konfigurieren. Weitere Informationen zu den veralteten Einstellungen finden Sie unter Veraltete TCP-Parameter.
Hinweis
Ausführliche Informationen zu den verfügbaren Ebenen der automatischen Optimierung finden Sie unter Ebenen der automatischen Optimierung.
So überprüfen oder ändern Sie die Ebene der automatischen Optimierung mit netsh
Öffnen Sie zum Überprüfen der aktuellen Einstellungen ein Eingabeaufforderungsfenster, und führen Sie den folgenden Befehl aus:
netsh interface tcp show global
Die Ausgabe des Befehls sollte der folgenden ähneln:
Querying active state...
TCP Global Parameters
-----
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off
Führen Sie den folgenden Befehl an der Eingabeaufforderung aus, um die Einstellung zu ändern:
netsh interface tcp set global autotuninglevel=<Value>
Hinweis
Im vorstehenden Befehl steht <Value> für den neuen Wert der Autotuningebene.
Weitere Informationen zu diesem Befehl finden Sie unter Netsh commands for Interface Transmission Control Protocol (Netsh-Befehle für TCP an der Schnittstelle).
So überprüfen oder ändern Sie die Ebene der automatischen Optimierung über PowerShell
Öffnen Sie zum Überprüfen der aktuellen Einstellungen ein PowerShell-Fenster, und führen Sie das folgende Cmdlet aus.
Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal
Die Ausgabe des Cmdlets sollte der folgenden ähneln.
SettingName AutoTuningLevelLocal
----------- --------------------
Automatic
InternetCustom Normal
DatacenterCustom Normal
Compat Normal
Datacenter Normal
Internet Normal
Um die Einstellung zu ändern, führen Sie das folgende Cmdlet an der PowerShell-Eingabeaufforderung aus.
Set-NetTCPSetting -AutoTuningLevelLocal <Value>
Hinweis
Im vorstehenden Befehl steht <Value> für den neuen Wert der Autotuningebene.
Weitere Informationen zu diesen Cmdlets finden Sie in den folgenden Artikeln:
Ebenen der automatischen Optimierung
Sie können die automatische Optimierung des Empfangsfensters auf eine von fünf Ebenen festlegen. Die Standardebene lautet Normal. In der folgenden Tabelle werden die Ebenen beschrieben.
| Ebene | Hexadezimalwert | Kommentare |
|---|---|---|
| Normal (Standardeinstellung) | 0x8 (Skalierungsfaktor 8) | Das TCP-Empfangsfenster wird so festgelegt, dass es entsprechend nahezu allen Szenarien wächst. |
| Disabled | Kein Skalierungsfaktor verfügbar | Das TCP-Empfangsfenster wird auf den Standardwert festgelegt. |
| Eingeschränkt | 0x4 (Skalierungsfaktor 4) | Das TCP-Empfangsfenster wird so festgelegt, dass es über den Standardwert hinaus wächst, dieses Wachstum wird jedoch in einigen Szenarien eingeschränkt. |
| Stark eingeschränkt | 0x2 (Skalierungsfaktor 2) | Das TCP-Empfangsfenster wird so festgelegt, dass es über den Standardwert hinaus wächst, dies jedoch sehr konservativ. |
| Experimentell | 0xE (Skalierungsfaktor 14) | Das TCP-Empfangsfenster wird so festgelegt, dass es entsprechend extremen Szenarien wächst. |
Wenn Sie eine Anwendung zum Erfassen von Netzwerkpaketen verwenden, sollte die Anwendung für unterschiedliche Einstellungen der Ebene der automatischen Optimierung für das Fenster Daten ähnlich den folgenden melden.
Ebene der automatischen Optimierung: Normal (Standardzustand)
Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2667, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240 SrcPort: 60975 DstPort: Microsoft-DS(445) SequenceNumber: 4075590425 (0xF2EC9319) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x8 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 8 -----------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:Ebene der automatischen Optimierung: Deaktiviert
Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2576, Total IP Length = 48 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240 SrcPort: 60956 DstPort: Microsoft-DS(445) SequenceNumber: 2315885330 (0x8A099B12) AcknowledgementNumber: 0 (0x0) + DataOffset: 112 (0x70) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( ) = 64240 ----------------------------------------> TCP Receive Window set as 64K as per NIC Link bitrate. Note there is no Scale Factor defined. In this case, Scale factor is not being sent as a TCP Option, so it will not be used by Windows. Checksum: 0x817E, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + NoOption: + SACKPermitted:Ebene der automatischen Optimierung: Eingeschränkt
Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2319, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240 SrcPort: 60890 DstPort: Microsoft-DS(445) SequenceNumber: 1966088568 (0x75302178) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x4 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by AutoTuningLevel. + NoOption: + NoOption: + SACKPermitted:Ebene der automatischen Optimierung: Stark eingeschränkt
Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2388, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240 SrcPort: 60903 DstPort: Microsoft-DS(445) SequenceNumber: 1463725706 (0x573EAE8A) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x2 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:Ebene der automatischen Optimierung: Experimentell
Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet ID = 2490, Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240 SrcPort: 60933 DstPort: Microsoft-DS(445) SequenceNumber: 2095111365 (0x7CE0DCC5) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: ......S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0xe Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:
Veraltete TCP-Parameter
Die folgenden Registrierungseinstellungen von Windows Server 2003 werden nicht mehr unterstützt und in späteren Versionen ignoriert.
- TcpWindowSize
- NumTcbTablePartitions
- MaxHashTableSize
Alle diese Einstellungen befanden sich im folgenden Registrierungsunterschlüssel:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Windows-Filterplattform
In Windows Vista und Windows Server 2008 wurde die Windows-Filterplattform (WFP) eingeführt. WFP bietet APIs, mit denen nicht zu Microsoft gehörende unabhängige Softwareanbieter (Independent Software Vendors, ISVs) Paketverarbeitungsfilter erstellen können. Zu Beispielen zählen Firewall- und Antivirensoftware.
Hinweis
Ein schlecht geschriebener WFP-Filter kann die Netzwerkleistung eines Servers erheblich verringern. Weitere Informationen finden Sie unter Portieren von Paketverarbeitungstreibern und Apps zu WFP in Windows Dev Center.
Links zu allen Themen in diesem Leitfaden finden Sie unter Leistungsoptimierung für das Netzwerksubsystem.