[English]Noch ein Nachtrag zum Thema "Microsofts TCP/IP-Implementierung in Windows und die Fallen". In der TCP-Implementierung von Windows 10 und Windows 11 hat Microsoft einige Klippen eingebaut, die die mögliche Leistung von TCP/IP-Verbindungen arg einschränken. Es kann Fälle geben, wo die TCP/IP-Einstellungen, die Windows intern vornimmt, so verschlimmbessert wurden, dass ein Reset des TCP/IP-Stack Wunder wirken und die Netzwerkleistung stark erhöhen kann.
Anzeige
Problem Windows TCP/IP-Optimierung
Das Kürzel TCP steht für Transmission Control Protocol, ein zuverlässiges, verbindungsorientiertes, paketvermitteltes Netzwerktransfer-Protokoll, das definiert, auf welche Art und Weise Daten zwischen Netzwerkkomponenten ausgetauscht werden sollen. Nahezu sämtliche aktuelle Betriebssysteme moderner Computer beherrschen TCP und nutzen es für den Datenaustausch mit anderen Rechnern.
Blog-Leser Alexander Fuchs (tritt online unter dem Alias MysticFox auf) hatte mich 2023 auf massive Probleme bei der TCP/IP-Implementierung unter Windows aufmerksam gemacht. Zusammenfassend ergibt sich folgendes Bild:
- In Windows 10/11 werden alle ausgehenden TCP-Verbindungen über das Internet TCP-Profil gehandhabt. Durch die Verwendung des Profils Internet werden TCP-Verbindungen ins Netzwerk (u.a. über die Latzenz der ACK-Pakete) künstlich verlangsamt (siehe diesen Artikel von Dan Cuomo, Microsoft).
- Hinzu kommt, dass die aktuell in Windows-Versionen verwendeten Einstellungen der TCP-Profile Internet und Datacenter zu Zeiten vom Server 2012, abgestimmt auf die damaligen Internetanschlusseigenschaften, definiert wurden.
Das führt mitunter dazu, dass der Netzwerkdurchsatz stark sinkt. Alexander hatte in diesem Zusammenhang einige Untersuchungen durchgeführt und im Anschluss PowerShell-Optimierungs-Scripte veröffentlicht, die die Einstellungen in den TCP-Profilen Internet und Datacenter optimieren. Ich hatte hier im Blog bereits mehrfach über diesen Sachverhalt und die Script berichtet. Die Details lassen sich in den am Artikelende verlinkten Blog-Beiträgen nachlesen.
Einen Punkt möchte ich noch nachtragen. Es kann Fälle geben, wo die TCP/IP-Einstellungen, die Windows intern vornimmt, so verschlimmbessert wurden, dass eine Optimierung nicht mehr greift und der Reset des TCP/IP-Stacks Wunder wirken und die Netzwerkleistung stark erhöhen kann.
Anzeige
Problem: Vermurkste TCP/IP-Einstellungen
Bei der Analyse der durch TCP/IP-Einstellungen verursachten Leistungsminderungen fiel Alexander auf, dass die Optimierung in bestimmten Fälle schlicht nichts brachte. Bereits im Januar 2023 stieß der Blog-Leser auf einen Tread One-sided Speed Problem – Layer 2 Bridge (Cambium V3000 – V5000) in der Spaceworks-Community, wo es ebenfalls um das Thema ging.
In seinen Tests zum Netzwerkdurchsatz zwischen einem Windows-Client und einem Windows-Server erreichte er bei einem 10 Gigabit-Netzwerk Werte zwischen 56,38 MB/s und 322,30 MB/s (je nach Paketgröße). Bei der Analyse des Problems, warum TCP/IP-Netzwerkverbindungen keinen optimalen Durchsatz erreichen, hat der Blog-Leser dann schlicht einen Reset des TCP/IP-Interface mittels des Kommandozeilenbefehls:
netsh interface tcp reset
versucht. Der Befehl setzt den TCP/IP-Stack samt den dort verwendeten Parametern zurück. Danach hat er sein Optimierungs-Script erneut ausgeführt und sein persönliches Wunder beim Netzwerkdurchsatz zwischen einem Windows Client und einem Windows Server erlebt. Getestet wurde eine 10 GBit-Verbindung, wobei der Durchsatz mittels des Tools psping64.exe ermittelt wurde. Dem Sysinternals Tool psping64.exe lässt sich über den Parameter l die Paketgröße vorgeben. Nach der Optimierung der TCP/IP-Parameter konnte er folgenden Durchsatz messen:
4K = 831,05 MB/s
8K = 1023,49 MB/s
16K = 1011,12 MB/s
32K = 1,05 GB/s
64K = 1,09 GB/s
Je nach Paketgröße ließen sich Transferraten von 1 GB/s erreichen. Das Ergebnis lag Welten über den Durchsätzen, die der Leser vor dem TCP-Reset erreichen konnte.
Versuch einer Erklärung
Alexander hat einige Experimente mit unterschiedlichen Windows-Versionen in virtuellen Maschinen durchgeführt und dann einige seiner Erkenntnisse auf administrator.de in die Diskussion eingebracht. Meine Interpretation kurz auf den Punkt gebracht: Windows versucht nach dem Setup bei TCP/IP-Verbindungen zu einer Gegenstelle seinen TCP-Stack bzw. die (Vor-)Einstellungen zu optimieren.
Je nach Gegenstelle kann dies dazu führen, dass Einstellungen wie Delayed ACK sehr ungünstig gesetzt werden. Da diese Parameter aber im TCP/IP-Profil stecken, wirkt sich dies auf alle Netzwerkverbindungen aus. Sind die Parameter irgendwann ungünstig ausgehandelt worden, kommt man auch bei den Verbindungen zu anderen Maschinen zu sehr schlechten Netzwerkdurchsatzraten.
Der Reset des TCP-/IP-Stacks samt anschließendem Neustart von Windows führt dazu, dass die internen Settings auf Werkseinstellungen gesetzt werden. Dann kann das Optimierungs-Script des Lesers den Durchsatz der TCP/IP-Verbindungen wieder auf vernünftige Werte bringen. Das dürfte vor allem für Administratoren von Interesse sein, die mit dem Netzwerkdurchsatz bei Hyper-V-Maschinen Probleme haben. Vielleicht das Ganze im Hinterkopf behalten – die Details lassen sich in den beiden Threads in der Spiceworks Community und auf administrator.de nachlesen.
Artikelreihe:
Optimierung von Microsofts TCP-Murks in Windows 10 und 11
Windows 10/11: Grottige Netzwerktransfer-Leistung, hohe Windows 11 CPU-Last – Teil 1
Windows 11: Netzwerktransfer-Leistung und CPU-Last optimieren – Teil 2
Anzeige
Das Script von Alexander findet ihr hier: https://www.der-windows-papst.de/download/Netzwerk-zu-DataCenter-optimieren.zip
Besser hier: https://github.com/MysticFoxDE/WINDOWS-OPTIMIZATIONS
(Falls das Script nochmal geändert werden sollte, gibt es dort die aktuellste Version. Außerdem liegt dort auch das Script um die Änderungen wieder rückgängig zu machen.)
Das ist mal interssant, ob wir das proaktiv bei all unsern Servern bzw. zumindest bei den Fileservern einmal durchführen sollten?`
WiFi Profile sind ja vom reset nicht betroffen?
Nein, das Skript vom Fuchs aka MysticFoxDE sollten, wie er es selbst mehrfach betont, nicht auf Servern laufen gelassen werden. Das sind ausschliesslich Win10/11 Client Optimierungen. Ein Blick in das PS zeigt auch, dass die relevanten Optimierung bei Vorhandensein von HyperV abbrechen.
Darüber hinaus sollte man schon die Feinheiten und Auswirkungen von RSC, RSS kennen. Ich würde da noch die IRQ Moderation mit ins Boot nehmen. Allen ist klar, dass ein App-Server, DB-Server, Terminalserver oder DCs andere Anforderungsprofile haben. Ist auch seit NT4 Workstation nichts Neues, dass Clients mit kaputten TCP/IP Einstellungen als Handbremse ausgeliefert werden (z.b. 10 Connection Limit) und diese im Jahr 2024 nicht zeitgemäß sind. Da gab es in den 90ern bereits Patches gegen.
Das 10 Connection Limit ist dafür, dass eine Workstation nicht als Server missbraucht wird. Ja, MS will ja auch Server verkaufen. Und betriebsablausf- und sicherheitstechnisch sollte eine Workstation sowieso keine Serverdienste anbieten. Bei uns z.B. sind deswegen in den per GPO verteilten Client-Firewallregeln dafür extra zusätzlich Denys auf den gängigen Ports wie SMB, Webserver, SQL usw. – damit kein Entwickler oder Admin auf so eine dumme Idee kommt – doppelt gemoppelt hält besser. Serverdienste gehören auf Serverbetriebssysteme auf Serverhardware.
Neee… das Connection Limit (es sind in the meantime 20, waren anfangs nur 10) ist genauso witzfrei wie eine Begrenzung auf Usern oder Devices. Es ist nichts weiter als eine willkürliche und künstliche Verkrüppelung zum Abkassieren. Eine zusätzliche Schikane, die Microsoft da seinen Nutzern auferlegt, zusätzlich zu der üblichen Notwendigkeit für Optimierungen. Diese Optimierungen sind nicht Windows-spezifisch. In Linux aktiviere ich zum Beispiel TCP BBR regelmäßig. Da versucht man halt möglichst viele UseCases mit einer Einstellung zu erschlagen.
Die strikte Trennung von Client-Servern so wie in den 90ern propagiert ist heute, 30 Jahre später noch mehr Humbug. Jeder größere Anwendung verteilt auf mehrere Threads und Cores besteht aus etlichen Servern und Clients. Jedes Smartphone verwaltet mehr als 20 Connections über mehrere Interfaces.
IMHO An solchen Ecken und Kanten lässt sich sehr gut erkennen, wie an längst überholten Konzepten der Vergangenheit festgehalten wird.
Einen Unterschied zwischen Server und Client Version zu machen, hat mit Schikane oder Abzocke überhaupt nichts zu tun.
Man kauft sich ja auch keinen Kleinwagen um am Ende sich zu beschweren, dass kein Lamborghini Motor verbaut ist oder? Will man mehr Leistung muss man mehr zahlen.
Nur ist im Fall "Windows" jener "Kleinwagen" ein 7-sitziger VW-Bus mit grossem TDI-Motor, bei dem Kofferraum und 3 Sitze unbenutztbar gemacht wurden und der Motor auf 65 PS gedrosselt.
Mit der Fahrsicherheit der frühen A-Klasse 😉.
Der Vergleich hinkt etwas, weil du ja auch auf einem Rackserver mit was weiß ich wievielen XEON Kernen quadrilliarden TB RAM und SAN-Anbindung Windows 10/11 installieren könntest.
Aber stell dir mal vor, ein Mitarbeiter installiert auf seinem Desktop-PC, auf dem er täglich arbeitet testweise eine Superduper Webapplikaktion, findet das brauchbar, zeigts nem Kollegen, der zeigts weiter und plötzlich benutzen alle es und es wird im Ablauf der Firma unverzichtbar. Und dann fährt der Kollege in den Urlaub und fährt den PC die nächsten 4 Wochen runter oder nimmt gar für Notfälle das Notebook mit in die Karibik.
Oder, der fängt sich mal per Email ne Ransomware ein und die Superduper-Webapp, von der nun alle abhängig sind, ist platt oder verteilt die Ransomware weiter an jeden der da vorbeikommt.
Achja, Workstations sind üblicherweise auch nicht im täglichen Backup drin, üblicherweise garnicht im Backup.
Das ist Schatten-IT par excellence!
SERVERDIENSTE GEHÖREN NICHT AUF WORKSTATIONS.
Zudem lassen sich viele Serverdienste auch gar nicht auf Workstations installieren.
Z.B. DNS Server, DHCP-Server, FMSO-Rollen, etc. etc.
Und bei den Server-BS fehlen auch die meisten Apps, mit denen Microsoft die Workstation-BS zumüllt.
Selbestverständlich kann ich einen eigenen DNS, DHCP, DBMS oder sonstigen Server auch auf einer Workstation installieren… nur halt die von Microsoft nicht…
(Ob ein DNS auf einer Workstation sinnvoll ist oder nicht, das sei mal dahingestellt, vielleicht sinnvoller statt dem häufig anzutreffenden rumdoktern von typischen Windows Admins an der Hosts Datei).
Melde Dich an einem typischen Windows-Clienten an und wirf einen Blick in die Dienste, was da so im Hintergrund für Server mitlaufen.
Der Kunde war glücklich mit seinem 35 Clients.
Es lief wie es sollte.
Eines Tages aber, gab es immer wieder Probleme.
Er hat lange gesucht Ehe3 er darauf kam, daß Microsoft in seinem Größenwahn die Anzahl der TCP Verbindungen auf 10 reduziert hatte… manchmal waren es halt mehr geworden.
Da hat er nie drauf geachtet.
Sag bitte nicht das Limit das technische Gründe hat.
Ebenso haben Windows Leute einfach akzeptiert, dass man von einem Client nur mit einem User auf einen anderen Rechner kann.
Will man mit den credentials eines anderen Users vom selben Client auf demselben Rechner geht es nicht.
(Trick: für die 2. Verbindung nimmt man die IP-Adresse)
Das verhindert sehr wirkungsvoll, dass man den Rechner mit mehreren Usern teilen könnte. Ein Problem, das in der Unix Welt undenkbar wäre.
wirklich? Also der VW Käfer gabe es sogar ganz offiziell mit Porsche Motor… Nachbar hat so ein Schätzchen sogar noch in der Garage stehen… ich steh ja lieber direkt auf US Muscle ;-P
b2t: das Problem ist doch schon seit Jahrzehnten bekannt und auch zig Lösungen wie man das umgehen kann wenn nötig… Urlaubsloch sollte eigentlich mittlerweilen auch rum sein.
Nichts anderes erwartet bei M$, war damals auch einer der Gründe warum wir nicht auf Hyper-V sondern auf VMWare gesetzt haben, dass ist sicherlich nicht nicht frei von Fehlern, aber wenn man in der Standardinstallation einen x8 höheren Datendurchsatz zum Storage hat, ist die Entscheidung recht einfach. Bei dem späteren Wechsel von iSCSI auf FibreChannel, haben wir M$ garnicht erst gestestet, da klar ist, dass die das auch versemmeln.
…von irgendwelchen Super CVEs wegen fehlerhafte oder selbst definierte "Standards" im IPv6 Stack reden wir jetzt besser nicht :-)
Hier laufen dutzende Hyper-V mit FC-SAN hochperformant. (Das Optimierungsscript von MysticFox ist ja auch garnicht für Server und HyperV gedacht!). VMWare war aber keine schlechte Wahl, und ist es auch heute nicht, wenn man es sich leisten will/kann.
Also wir haben schon vor Jahren alles von VMWare auf Hyper-V umgestellt und das sind ein paar dutzend Datacenter-Hosts und wir haben weder Performance-Probleme, noch Probleme mit iSCSI, FC-SAN oder sonstwas. Ja, gelegentlich die auftretenden Probleme mit Windows-Update im allgemeinen, aber auch VMware hat da ja schon gepatzt. Und vor Angriffen auf die ESXi-Server liest man ja auch regelmäßig, man ist damit nicht aus dem Schussfeld.
VMware ist keine schlechte Wahl, hat tolle Features, wenn man die braucht, man muss es sich nur leisten können/wollen und "Härtung" ist da auch ein Thema. Beim Datacenter-Hyper-V-Server sind eben die Lizenzkosten für die Windows-VMs schon drin, die kosten unter VMware nochmal extra. Das macht sich ab einer gewissen Größe schmerzhaft bemerkbar, insbesondere seit Broadcom die Fäden zieht. Und es ist etwas einfacher, gute Windows-Server-Experten zu finden, als wie VCPs, wenn man das Admin-Team mal vergrößern muss. Ich habe meinen VCP inzwischen nicht mehr verlängert.
Moin
habe es mal getestet auf einer NUC: 1340P – Intel I226-V – 2,5Gbit *Aktueller Treiber* Windows 11 Pro.
Switch Xyzel XGS1250 und Lancom UF-60
Google Speedtest
Vor der Optimierung Internet 500/125 – Download 60Mbits
nach der Optimierung Internet 280/90 – Download 22 – 29Mbits
Gleich mal Rückgängig gemacht.
Bitte beachten das üblicherweise mehrere TCP Verbindung zur gleichen Zeit bestehen und alle "gerecht" behandelt werden wollen. Man hat aber ein "shared medium": Den einen Ethernetadapter.
Durch ein evtl. einäugiges Optimieren einer einzelnen Verbindung kann man den gesamten Durchsatz herunterdrücken. delayed ACK lebt vom big-fat-pipe effekt, der bei einer einzelnen Verbindung nichts bringt, vermeintlich den Durchsatz sogar reduziert weil der Absender auf das ACK, weil er das Fenster schon ausgenutzt hat, warten muss. Im RL könnte diese Zeit von anderen genutzt werden. Aber datüber laßt sich trefflich streiten.
Ist es nun besser alle Daten innerhalb von 1sec zu übertragen, dabei andere zu benachteiligen, wenn die Daten zur Verarbeitung eh 5sec brauchen.
So etwas auszutesten ist sehr arbeitsaufwändig.
Natürlich möglich, das MS da Fehler unterlaufen oder es für den eigenen Einsatz genau nicht optimal ist.