[German]Microsoft has made a few mistakes in the TCP implementation of Windows 10 and Windows 11 that severely limit the possible performance of TCP/IP connections. A blog reader brought this to my attention and immediately pointed out ways to possibly optimize something like this. I'm going to present it in a blog post for interested administrators in enterprise environments.
Hintergrund TCP
The abbreviation TCP stands for Transmission Control Protocol, a network protocol that defines how data is exchanged between network components. Almost all current operating systems of modern computers are capable of TCP and use it for data exchange with other computers.
The protocol is a reliable, connection-oriented, packet-switched transport protocol in computer networks. It is part of the Internet protocol family, the foundation of the Internet. However, when implementing it, developers can specify numerous parameters to control the flow of TCP transmissions.
A discussion about RDP in Windows Server 2022
German blog reader Alexander Fuchs (appears online under the alias MysticFox) emailed me a few days ago about this topic and pointed me to the relevant sources where he gathered the information – thanks for that.
On German site administrator.de there is a thread Remote Desktop Services unter 2022 – Erfahrungen? from January 2023 in which an administrator talks about the performance of RDP connections under Windows Server 2022 and asked others for their opinion. According to his research, the RDP performance is supposed to be terrible.
The blog reader suffered from jerks and performance problems with remote desktop connections under Windows Server 2022 and then looked at both the documentation from Microsoft and the settings under Windows. In the course of the discussion, MysticFoxDE addresses the question of why RDP connection performance is so poor in this German comment.
Through the discussion, the topic then also comes up that RDP on Windows 10/11 clients, even with performant hardware, runs much more sluggishly than under Windows Server 2012 R2. MysticFox then points out in this comment that the TCP network connections in the Windows 10/11 clients are artificially slowed down by Microsoft's implementation.
TCP implementation mess
Alex then investigated the whole thing more closely and came across quite an implementation mishap with the Transmission Control Protocol under Windows 10 and Windows 11.
TCP profile Internet
- In Windows 10/11, all outgoing TCP connections are handled using the Internet TCP profile (see the figure above, which can be output using the PowerShell command Get-NetTCPConnection). Using the Internet profile artificially slows down TCP connections to the network (via the latency of ACK packets, among other things). Dan Cuomo from Microsoft confirmed this in this German article.
- The settings of the TCP profiles Internet and Datacenter of the current Windows versions, were defined at the time of Server 2012, adjusted to the Internet connection properties at that time.
In other words: It seems in 2023, that Microsoft is using two huge handbrakes in the Windows 10 and Windows 11 clients, by routing all TCP connections through the "Internet" profile, and by having the "optimization parameters" for this profile still tuned to Internet connection properties that were common well over 10 years ago.
Alex writes in his German summary Wie man das Windows 10 und 11 TCP-Handling wieder desuboptimieren kann (I've translated the summary): And instead of that Microsofts uses for today's Internet and or LAN speeds the more suitable "Datacenter TCP profile" as Default TCP profile, they decided to use the opposite and using within the current Windows versions (10 & 11), the slower Internet profile (even for internal networks). A normal user cannot change anything in these defaults …
Approach to TCP optimization
AAlexander F. has now gone and developed a Powershell script that solves the above handbrakes in Windows 10 and Windows 11 and optimizes the TCP parameters to reduce latencies and improve performance. As of the weekend (as of January 27, 2023), he has released the current version. Alex F. provides the current version of the PowerShell script W10ANDW11-NETWORK-TCP-DESUBOPTIMIZATION.ps1 on GitHub. Alexander writes about this:
Please run the script as administrator, otherwise it won't work and will only bring more errors.
Yes, even when run as administrator it will still spit out errors, but these are completely irrelevant and also not harmful. I just haven't had time to refine the error handling yet, hence V0.9.
!! Furthermore, this script is only meant for optimizing Windows 10 &11, please do not run it on a server operating system. !!
After running the computer must be restarted, so that all settings are cleanly adopted. And after that, you should already feel a significant performance improvement, especially in local applications, but also a performance improvement when accessing data on the Internet (eg faster surfing), as I said, is far from impossible. A deterioration, on the other hand, has not yet been seen at a single workstation that I have adjusted accordingly so far.
So it's not a point & click solution for end users or administrators that are not aware of the risks. But it could bee a good point to fine tune the TCP settings in Windows 10/11 clients.
Alexander has published some performance measurements on German site administrator.de in this thread, and there is also feedback from other administrators. Perhaps for one or the other administrator or power user of interest.
At this point, of course, the note that everyone is responsible for the use of the PowerShell script itself. It is recommended to make a backup before using it to be able to go back to the previous state if necessary.
This is the first article of a series about how to lift the performance brakes for TCP networking in Windows 10 / 11.
Article series:
Microsoft's TCP mess, how to optimize in Windows 10/11
Windows 10/11: Poor network transfer performance, high Windows 11 CPU load – Part 1
Windows 11: Optimize network transfer performance and CPU load – part 2