Welche TCP/IP-Registry-Parameter steuern Windows wirklich – und welche Performance-Auswirkungen haben Änderungen?

Parameterlandkarte des Windows-TCP/IP-Stacks: Persistenz (Registry), Laufzeitkonfiguration und Versionsunterschiede

Der Windows-TCP/IP-Stack wird gleichzeitig über persistente Einstellungen (vorrangig Registry und teils Gruppenrichtlinien), über laufzeitwirksame Konfigurationsschichten (Netsh/PowerShell, NDIS-Adaptereigenschaften) sowie über dynamische Heuristiken gesteuert. Eine belastbare Parameterlandkarte trennt diese Ebenen strikt, weil identische Begriffe je nach Schicht unterschiedliche Semantik besitzen: Ein Registry-Wert kann als „Default“ dienen, durch Richtlinien überschrieben werden oder im Betrieb durch Autotuning/Heuristics graduell übersteuert werden, ohne dass ein einzelner Schalter dies sichtbar macht.

Versionsunterschiede entstehen weniger durch neue Schlüsselpfade als durch veränderte Default-Werte, zusätzliche Zustandsautomaten (z. B. beim Receive Window Autotuning) und geänderte Interaktionen mit Offloading-Funktionen. Seit Windows 10/11 und Windows Server 2016+ verschieben sich Performance- und Latenzprofile zudem stärker in Richtung „policy-driven“ Verhalten (z. B. QoS/DSCP, Virtualisierungspfade wie vSwitch/VMQ/VMMQ) und in Richtung „flow-aware“ Anpassungen im TCP-Stack, während klassische statische Tuning-Ansätze zunehmend Risiko tragen.

Persistenzebenen: Registry, Richtlinien und Treibereigenschaften

Persistente TCP/IP-Parameter finden sich schwerpunktmäßig unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters sowie für IPv6 unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters. Zusätzlich existieren adapter- oder interface-spezifische Schlüssel, etwa unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}, die bevorzugt werden, wenn sie gesetzt sind (beispielsweise statische MTU oder DNS-Optionen). Offload- und Queueing-Eigenschaften liegen demgegenüber typischerweise in der NDIS-Schicht und werden über den Adaptertreiber exponiert; ihre Persistenz erfolgt über Treibereinstellungen und ist nicht zuverlässig über einen einzigen zentralen Registry-Pfad ablesbar.

Gruppenrichtlinien wirken als weitere Persistenzebene, insbesondere für QoS/DSCP sowie für bestimmte Netzwerk- und Sicherheitsvorgaben. Für die Parameterlandkarte zählt deshalb nicht nur „wo steht der Wert“, sondern „welche Ebene gewinnt“: Richtlinie vor lokaler Konfiguration, Interface-spezifisch vor global, Treiber-/Feature-Default vor generischem Stack-Default. Ohne diese Priorisierung entstehen Fehlschlüsse, etwa wenn ein globaler Registry-Wert gesetzt wird, der von einem Interface-Wert oder einer Richtlinie wirkungslos gemacht wird.

• Globaler IPv4-Parameterpfad: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
• Interface-spezifischer IPv4-Pfad: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface-GUID}
• Globaler IPv6-Parameterpfad: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
• Treiber-/NDIS-Ebene prüfen: Get-NetAdapterAdvancedProperty -Name "Ethernet"
Get-NetAdapterRss -Name "Ethernet"
Get-NetAdapterRsc -Name "Ethernet"
• Laufzeitstatus TCP/Global: netsh int tcp show global
Get-NetTCPSetting

Laufzeitkonfiguration: Netsh/PowerShell versus effektiver Zustand

Windows trennt konfigurierbare TCP-Profile (TCP Settings) von der effektiven Verbindungsausprägung. Befehle wie netsh int tcp set global oder Set-NetTCPSetting ändern Profilparameter, die bei neuen Verbindungen in Kraft treten; bestehende Flows behalten häufig ihren Zustand. Der effektive Zustand hängt außerdem von Heuristics ab, die je nach Version und Rollenkontext (Client/Server) bestimmte Optimierungen aktivieren oder begrenzen können. Daher ist eine Landkarte ohne „Ist-Zustand“-Abfrage unvollständig.

Praktisch relevant ist diese Differenz bei Receive Window Autotuning und Congestion Control: Ein Profil kann ein aggressives Autotuning zulassen, aber QoS-Policy, VPN-/Filtertreiber oder bestimmte Middleboxes können Window Scaling oder große Fenster faktisch unbrauchbar machen. Ebenso können Offloads den CPU-Pfad entlasten, aber durch zusätzliche Latenz (Coalescing) die Paketverarbeitung verzögern; die Laufzeitdiagnose muss deshalb Adapter- und Stack-Ebene zusammenführen.

Registry-Werte im Feld: Erkennbar, aber nicht immer maßgeblich

Ein Teil klassischer TCP-Registry-Parameter wird in modernen Windows-Versionen weiterhin gelesen, dient jedoch primär als Fallback oder Kompatibilitätsschicht. Beispiele sind ausgewählte PMTUD-/Fragmentierungsoptionen oder bestimmte IPv4/IPv6-Parameter. Dagegen werden zentrale Leistungsmerkmale wie Autotuning, Congestion Control oder ECN heute überwiegend über TCP-Profile und den zustandsbehafteten Stack gesteuert, nicht über frei kombinierbare Registry-„Tweaks“. Für eine Parameterlandkarte ist deshalb entscheidend, welche Werte als „Quelle der Wahrheit“ gelten und welche nur den Startpunkt der Heuristik definieren.

Gleichzeitig bleibt die Registry als Persistenzanker relevant, etwa für systemweite IP-Optionen, für bestimmte Schnittstellenparameter oder in Umgebungen, in denen Konfigurationsmanagement Registry-basierte Baselines durchsetzt. Risiko entsteht, wenn Registry-Werte ohne Berücksichtigung von Offloads, MTU-Pfaden (LAN/VPN/Tunnel) und QoS-Policies gesetzt werden: Das Ergebnis kann von unauffälligem Durchsatzverlust bis zu schwer diagnostizierbaren Verbindungsabbrüchen reichen, insbesondere bei MTU/PMTUD-Problemen in Kombination mit großen TCP-Fenstern.

Versionsunterschiede: Defaults, Profile und Offload-Interaktionen

Windows 10/11 und Windows Server 2016/2019/2022/2025 verwenden standardmäßig profilbasierte TCP-Einstellungen mit aktivem Receive Window Autotuning und Window Scaling, während die konkreten Default-Profile (z. B. für Internet-, Datacenter- oder Custom-Szenarien) über die Zeit angepasst wurden. In der Praxis sind die Unterschiede häufig indirekt: geänderte Congestion-Control-Implementierungen, angepasste Grenzwerte für Coalescing und andere Heuristics. Eine reine Registry-Diff-Liste reicht daher nicht, weil sich die wirksame Charakteristik aus Profil, NIC-Offloads und Netzpfad ergibt.

Offloading-Funktionen verschieben die CPU-Kosten, verändern aber auch das Timing der Paketbereitstellung. RSS verteilt Empfangslast auf mehrere Kerne und beeinflusst damit indirekt Jitter und Latenz unter Last; RSC fasst eingehende Segmente zusammen und reduziert Interrupt-/DPC-Last, kann aber bei latenzsensitiven Mikrobursts oder bei bestimmten Capture-/Monitoring-Setups als „Verzögerung“ wahrgenommen werden. Checksum Offload reduziert CPU-Arbeit, ist aber bei Treiber-/Firmware-Fehlern eine klassische Quelle für schwer reproduzierbare Störungen. Die Parameterlandkarte muss deshalb immer vermerken, ob ein Stack-Parameter in einem Offload-Szenario überhaupt noch den erwarteten Hebel besitzt.

• Autotuning/Window Scaling Status: netsh int tcp show global (Felder Receive Window Auto-Tuning Level und Window Scaling heuristics)
• MTU/MSS-Pfade sichtbar machen: Get-NetIPInterface | Select-Object InterfaceAlias,NlMtu,InterfaceMetric
ping -f -l 1472 <Ziel> (IPv4, Pfad-MTU-Test über DF)
• RSS/RSC im Kontext prüfen: Get-NetAdapterRss und Get-NetAdapterRsc (Queue-/Coalescing-Effekte korrelieren häufig mit Latenz unter Last)
• QoS-Policy als Overwrite-Faktor: Get-NetQosPolicy (DSCP/Throttling kann Durchsatzprofile trotz identischer TCP-Einstellungen verändern)

Referenztabellen: Registry-Pfade, Datentypen und Default-Werte (Windows 10/11, Server 2016/2019/2022) mit Funktions- und Risikoanalyse

Die nachfolgenden Referenztabellen bündeln verbreitete TCP/IP- und NDIS-/Treiber-nahe Schalter, die unter Windows in der Praxis regelmäßig geprüft werden. Viele Parameter werden nicht mehr primär über die Registry, sondern über netsh, PowerShell oder NIC-Advanced-Properties verwaltet; dennoch bleiben die zugehörigen Registry-Schlüssel als Persistenz- und Diagnoseebene relevant. Default-Werte können sich durch kumulative Updates, Rollen (Client/Server) und Hardware-Offload-Fähigkeiten verschieben. Wo Microsoft keine stabilen, versionierten Registry-Defaults garantiert, wird dies ausdrücklich gekennzeichnet.

TCP-Parameter (Tcpip): Pfade, Datentypen, Default-Logik, Performance und Risiken

Die TCP-Implementierung liegt unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters (global) sowie je Schnittstelle unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}. Viele Werte werden nur ausgewertet, wenn sie explizit gesetzt sind; fehlt ein Eintrag, greift die interne Default-Logik des Stacks. Insbesondere Fensterverwaltung, Zeitgeber und Wiederholungslogik interagieren stark mit Autotuning, Pfad-MTU-Ermittlung und Offloads.

NDIS-/NIC-Advanced-Properties: Treiberpfade und Variabilität der Defaults

Viele Offload- und Queueing-Eigenschaften liegen nicht im Tcpip-Zweig, sondern in treiberspezifischen Parametern pro Netzadapter unter HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\####. Namen, Datentypen und Defaults sind NIC- und Treiberabhängig; selbst bei gleicher Windows-Version sind keine globalen Default-Werte garantiert. Für Referenzen eignen sich daher eher die kanonischen Feature-Bezeichnungen aus PowerShell und ihre Abbildung auf Treiber-Settings.

• Abfrage RSS: Get-NetAdapterRss | Select-Object Name,Enabled,NumberOfReceiveQueues,MaxProcessors
• Abfrage RSC: Get-NetAdapterRsc | Select-Object Name,IPv4Enabled,IPv6Enabled
• Abfrage Checksum Offload/LSO: Get-NetAdapterAdvancedProperty -Name "NIC-Name"
Get-NetAdapterChecksumOffload -Name "NIC-Name"
Get-NetAdapterLso -Name "NIC-Name"
• Treiber-Registry-Lokalisierung: HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\#### (Zuordnung über DriverDesc, NetCfgInstanceId)

Für Risikoanalysen ist entscheidend, dass Offload-Deaktivierungen oft symptomorientiert erfolgen, dabei aber die CPU-Last erhöhen und Paketverarbeitung in Filtertreibern verschieben. Umgekehrt können aggressive Offloads (z. B. großflächig aktiviertes RSC) bei bestimmten Workloads (hochfrequente, kleine Nachrichten; IDS/Packet-Capture; einige VPN-Stacks) die Observability und Latenz-Jitter verschlechtern, ohne dass ein reiner Durchsatztest den Effekt zeigt.

Interaktionsmatrix: Autotuning, MTU, Window Scaling und QoS (praktische Konfliktfelder)

Einzelparameter wirken selten isoliert. Besonders konfliktträchtig sind Kombinationen aus falscher MTU, eingeschränktem Receive Window und Policy-basiertem Traffic-Shaping. Die Matrix fasst typische Wechselwirkungen zusammen; sie dient als Prüfliste für Ursachenketten, nicht als Empfehlung zur pauschalen Anpassung.

Validierung und Change-Kontrolle: belastbare Nachweise statt “Tuning”

Für Windows 10/11 und Windows Server 2016/2019/2022 ist eine revisionssichere Dokumentation wichtiger als vermeintlich „optimale“ Werte. Änderungen sollten als Delta gegen den Ist-Zustand erfasst werden, inklusive Treiberversion, NIC-Firmware, Virtualisierungspfad (z. B. Hyper-V/vSwitch) und aktivem Security-Stack. Die schnellsten Fehlinterpretationen entstehen, wenn Registry-Werte gesetzt werden, die der Stack ignoriert, oder wenn per GPO/MDM andere Werte wieder zurückgerollt werden.

• TCP-Globalzustand prüfen: netsh int tcp show global
• Per-Interface MTU verifizieren: netsh interface ipv4 show subinterfaces
netsh interface ipv6 show subinterfaces
• Effektive NIC-Features prüfen: Get-NetAdapter | Select-Object Name,InterfaceDescription,DriverVersion
Get-NetAdapterRss
Get-NetAdapterRsc
• Risikoindikator bei Fehlkonfiguration: Get-NetTCPConnection | Group-Object State (auffällige Anteile SynSent/TimeWait können auf Zeitgeber-/Loss-/MTU-Probleme hinweisen)

Interaktionen und Tuning-Fallstricke: Autotuning, MTU/PMTUD, Window Scaling, QoS/DSCP und Offloading (RSS, RSC, Checksum/LSO) in Matrixform

TCP-Leistungsprobleme unter Windows entstehen häufig nicht durch einen einzelnen „falschen“ Wert, sondern durch unglückliche Kombinationen: ein aggressives Receive Window (via Autotuning) trifft auf eine zu kleine MTU, PMTUD wird durch Filter gestört, QoS markiert Traffic anders als erwartet, und parallel verändern Offloads die Segmentierung. Die Symptome wirken dann widersprüchlich: gute Bandbreite bei einzelnen Downloads, aber schlechte Interaktivität; oder stabile Latenz, aber unerklärlich niedriger Durchsatz.

Die folgende Darstellung fokussiert bewusst auf Interaktionen. Genannte Schalter und Statuswerte sind so gewählt, dass sie mit Bordmitteln reproduzierbar überprüft werden können, insbesondere über netsh, PowerShell und Adapter-Eigenschaften. Die Bewertung „Latenz“ versus „Durchsatz“ ist als Tendenz zu verstehen; reale Effekte hängen stark von RTT, Paketverlust, CPU-Last, Treiberqualität und Middleboxes (Firewall, Proxy, VPN, WAN-Optimierer) ab.

Prüf- und Referenzpunkte (Ist-Zustand, ohne Wertung)

Vor jeder Anpassung empfiehlt sich eine konsistente Bestandsaufnahme auf Host, NIC und Pfad. Besonders relevant sind: globales TCP-Tuning (inklusive Autotuning-Heuristiken), Offload-Status pro Adapter, effektive MTU entlang des Pfads sowie DSCP/Policy-Effekte. Ohne diese Basis werden Wechselwirkungen leicht übersehen, etwa wenn ein VPN-Adapter die MTU reduziert, während RSS/LSO am physischen Adapter korrekt aktiviert sind.

• TCP-Globalparameter: netsh int tcp show global
• TCP-Verbindungssicht (RTT, CWND, RWIN je Flow): Get-NetTCPConnection (Zuordnung)
  Get-NetTCPStatistics (Zähler)
  netsh int tcp show supplemental (Profile/Heuristics, sofern vorhanden)
• Adapter-Offloads und RSS: Get-NetAdapterRss
Get-NetAdapterAdvancedProperty -Name "NIC-Name"
Get-NetAdapterChecksumOffload
Get-NetAdapterLso
Get-NetAdapterRsc
• MTU je Interface und IP-Schicht: Get-NetIPInterface
netsh interface ipv4 show subinterfaces
• PMTU/Fragmentierungs-Indikatoren (Pfadtest): ping -f -l 1472 ziel.example (IPv4, schrittweise anpassen)
  ping -l 1452 ziel.example (typischer Ausgangspunkt bei VPN/PPPoE-Overhead)

Interaktionsmatrix: Autotuning, MTU/PMTUD und Window Scaling

Autotuning steuert, wie Windows die Receive Window-Größe dynamisch an BDP (Bandwidth-Delay Product) und aktuelle Bedingungen anpasst. In modernen Windows-Versionen ist Window Scaling für performantes TCP über höhere RTT und Bandbreiten praktisch zwingend, weil das klassische 65.535-Byte-Fenster sonst schnell limitiert. Eine reduzierte MTU oder gestörtes PMTUD kann jedoch bewirken, dass größere Segmente/Frames in Fragmentierung, Blackholing oder Retransmits laufen. Das wirkt wie „Autotuning schadet“, obwohl die Ursache der Pfad ist.

Interaktionsmatrix: QoS/DSCP versus Staukontrolle, Puffer und Paketverlust

DSCP-Markierungen beeinflussen nicht TCP an sich, sondern die Behandlung im Netz: Queue-Auswahl, Drop-Profile, Shaping/Policing. Daraus ergeben sich indirekt Effekte auf Latenz (Queueing Delay) und Durchsatz (verlustinduzierte Congestion Control). Häufige Fallstricke entstehen, wenn Markierungen am Host gesetzt, aber am ersten Hop gelöscht oder anders gemappt werden, oder wenn Policer „bursty“ TCP-Starts (Initial Window) hart abschneiden. Bei VPN/Overlay kann DSCP zudem im äußeren Header verloren gehen, sofern nicht explizit übernommen.

Interaktionsmatrix: Offloading (RSS, RSC, Checksum, LSO) versus Autotuning und MTU

Offloads verschieben Arbeit zwischen CPU, NDIS und NIC. RSS verteilt Receive-Last auf mehrere CPU-Cores; RSC coalesct eingehende Segmente zu größeren Einheiten; Checksum Offload und LSO/TSO entlasten beim Senden, indem große TCP-Payloads später segmentiert werden. Diese Mechanismen erhöhen typischerweise den Durchsatz bei niedriger CPU-Last, können aber in Kombination mit Treiberfehlern, Virtualisierungspfaden, Capture/Filter-Treibern oder inkonsistenter MTU unerwartete Nebeneffekte erzeugen. Besonders LSO reagiert empfindlich, wenn der effektive Pfad kleinere MTU erzwingt und PMTUD nicht zuverlässig funktioniert.

Tuning-Fallstricke, die in der Praxis häufig verwechselt werden

Mehrere Muster treten wiederholt auf: Autotuning wird deaktiviert, weil Durchsatz auf einer einzelnen Strecke schlecht ist; tatsächlich blockiert eine Middlebox ICMP „Fragmentation Needed“ oder ein Tunnel reduziert die MTU, ohne dass Endpunkte es erkennen. Ebenso werden Offloads global abgeschaltet, um „stabile“ Captures zu erhalten, obwohl damit nur CPU-Headroom verloren geht und die Ursache im Pfad bestehen bleibt. QoS-Probleme werden als TCP-Problem interpretiert, obwohl DSCP-Mapping oder Policing die Drops erzeugt.

• Autotuning nicht als Allzweck-Schalter verwenden: netsh int tcp set global autotuninglevel=disabled kaschiert oft nur MTU/PMTUD- oder Queue-Probleme und limitiert dann auf „langen“ Strecken strukturell den Durchsatz.
• MTU-Fehler zuerst pfadbezogen klären: Eine lokale MTU-Reduktion ohne Verständnis des Overheads (z. B. Tunnel) verschiebt Symptome; belastbar ist der Nachweis per DF-Ping (ping -f -l) und konsistenter MTU/MSS-Konfiguration an den relevanten Übergängen.
• Offloads selektiv und messbar ändern: Für Treiber-/Interop-Diagnosen Offloads nur temporär und pro betroffenem Adapter ändern, begleitend mit CPU- und Retransmit-Zählern (Get-NetTCPStatistics, PerfCounter). Pauschales Abschalten von RSS/LSO verschlechtert häufig die Situation unter Last.
• QoS als Netzpfad-Eigenschaft behandeln: DSCP-Markierung am Host garantiert keine Priorisierung. Validierung erfordert Sicht auf dem ersten Hop und am WAN-Edge; ohne diese Messpunkte bleiben Schlussfolgerungen aus Endhost-Metriken unsicher.