{"id":55435,"date":"2025-02-06T10:05:00","date_gmt":"2025-02-06T18:05:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=55435"},"modified":"2025-02-21T09:18:59","modified_gmt":"2025-02-21T17:18:59","slug":"dotnet-9-networking-improvements","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/dotnet-9-networking-improvements\/","title":{"rendered":".NET 9 Networking Improvements"},"content":{"rendered":"

Continuing our tradition, we are excited to share a blog post highlighting the latest and most interesting changes in the networking space with the new .NET release<\/a>. This year, we are introducing updates in the HTTP<\/a> space, new HttpClientFactory<\/code><\/a> APIs, .NET Framework compatibility<\/a> improvements, and more.<\/p>\n

HTTP<\/h2>\n

In the following section, we’re introducing the most impactful changes in the HTTP space. Among which belong perf improvements in connection pooling, support for multiple HTTP\/3 connections, auto-updating Windows proxy, and, last but not least, community contributions.<\/p>\n

Connection Pooling<\/h3>\n

In this release, we made two impactful performance improvements in HTTP connection pooling.<\/p>\n

We added opt-in support for multiple HTTP\/3 connections. Using more than one HTTP\/3 connection to the peer is discouraged by the RFC 9114<\/a> since the connection can multiplex parallel requests. However, in certain scenarios, like server-to-server, one connection might become a bottleneck even with request multiplexing. We saw such limitations with HTTP\/2 (dotnet\/runtime#35088<\/a>), which has the same concept of multiplexing over one connection. For the same reasons (dotnet\/runtime#51775<\/a>), we decided to implement multiple connection support for HTTP\/3 (dotnet\/runtime#101535<\/a>).<\/p>\n

The implementation itself tries to closely match the behavior of HTTP\/2 multiple connections. Which, at the moment, always prefer to saturate existing connections with as many requests as allowed by the peer before opening a new one. Note that this is an implementation detail and the behavior might change in the future.<\/p>\n

As a result, our benchmarks<\/a> showed a nontrivial increase in requests per seconds (RPS), comparison for 10,000 parallel requests:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
client<\/th>\nsingle HTTP\/3 connection<\/th>\nmultiple HTTP\/3 connections<\/th>\n<\/tr>\n<\/thead>\n
Max CPU Usage (%)<\/td>\n35<\/td>\n92<\/td>\n<\/tr>\n
Max Cores Usage (%)<\/td>\n971<\/td>\n2,572<\/td>\n<\/tr>\n
Max Working Set (MB)<\/td>\n3,810<\/td>\n6,491<\/td>\n<\/tr>\n
Max Private Memory (MB)<\/td>\n4,415<\/td>\n7,228<\/td>\n<\/tr>\n
Processor Count<\/td>\n28<\/td>\n28<\/td>\n<\/tr>\n
First request duration (ms)<\/td>\n519<\/td>\n594<\/td>\n<\/tr>\n
Requests<\/td>\n345,446<\/td>\n4,325,325<\/td>\n<\/tr>\n
Mean RPS<\/td>\n23,069<\/td>\n288,664<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Note that the increase in Max CPU Usage<\/em> implies better CPU utilization, which means that the CPU is busy processing requests instead of being idle.<\/p>\n

This feature can be turned on via the EnableMultipleHttp3Connections<\/code> property on SocketsHttpHandler<\/code><\/a>:<\/p>\n

var client = new HttpClient(new SocketsHttpHandler\n{\n    EnableMultipleHttp3Connections = true\n});<\/code><\/pre>\n
We also addressed lock contention in HTTP 1.1 connection pooling (dotnet\/runtime#70098<\/a>). The HTTP 1.1 connection pool previously used a single lock to manage the list of connections and the queue of pending requests. This lock was observed to be a bottleneck in high throughput scenarios on machines with a high number of CPU cores. We resolved this problem (dotnet\/runtime#99364<\/a>) by replacing an ordinary list with a lock with a concurrent collection. We chose ConcurrentStack<\/code><\/a> as it preserves the observable behavior when requests are handled by the newest available connection, which allows collecting older connections when their configured lifetime<\/a> expires. The throughput of HTTP 1.1 requests in our benchmarks increased by more than 30%:<\/p>\n\n\n\n\n\n\n
Client<\/th>\n.NET 8.0<\/th>\n.NET 9.0<\/th>\nIncrease<\/th>\n<\/tr>\n<\/thead>\n
Requests<\/td>\n80,028,791<\/td>\n107,128,778<\/td>\n+33.86%<\/td>\n<\/tr>\n
Mean RPS<\/td>\n666,886<\/td>\n892,749<\/td>\n+33.87%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Proxy Auto Update on Windows<\/h3>\n
One of the main pain points when debugging HTTP traffic of applications using earlier versions of .NET is that the application doesn’t react to changes in Windows proxy settings (dotnet\/runtime#70098<\/a>). The proxy settings were previously initialized once per process with no reasonable ability to refresh the settings. For example (with .NET 8), HttpClient.DefaultProxy<\/code><\/a> returns the same instance upon repeated access and never refetch the settings. As a result, tools like Dev Proxy<\/a> or Fiddler, that set themselves as system proxy to listen for the traffic, weren’t able to capture traffic from already running processes. This issue was mitigated in dotnet\/runtime#103364<\/a>, where the HttpClient.DefaultProxy<\/code> is set to an instance of Windows proxy that listens for registry changes and reloads the proxy settings when notified.\nThe following code:<\/p>\n
while (true)\n{\n    using var resp = await client.GetAsync(\"https:\/\/httpbin.org\/\");\n    Console.WriteLine(HttpClient.DefaultProxy.GetProxy(new Uri(\"https:\/\/httpbin.org\/\"))?.ToString() ?? \"null\");\n    await Task.Delay(1_000);\n}<\/code><\/pre>\n
produces output like this:<\/p>\n
null\n\/\/ After Fiddler's \"System Proxy\" is turned on.\nhttp:\/\/127.0.0.1:8866\/<\/code><\/pre>\n
Note that this change applies only for Windows as it has a unique concept of machine wide proxy settings<\/a>. Linux and other UNIX-based systems only allow setting up proxy via environment variables, which can’t be changed during process lifetime.<\/p>\n
Community contributions<\/h3>\n
We’d like to call out community contributions.<\/p>\n
CancellationToken<\/code><\/a> overloads were missing from HttpContent.LoadIntoBufferAsync<\/code><\/a>. This gap was resolved by an API proposal (dotnet\/runtime#102659<\/a>) from @andrewhickman-aveva<\/a> and an implementation (dotnet\/runtime#103991<\/a>) was from @manandre<\/a>.<\/p>\n
Another change improves a units discrepancy for the MaxResponseHeadersLength<\/code> property on SocketsHttpHandler<\/code><\/a> and HttpClientHandler<\/code><\/a> (dotnet\/runtime#75137<\/a>). All the other size and length properties are interpreted as being in bytes, however this one is interpreted as being in kilobytes. And since the actual behavior can’t be changed due to backward compatibility, the problem was solved by implementing an analyzer (dotnet\/roslyn-analyzers#6796<\/a>). The analyzer tries to make sure the user is aware that the value provided is interpreted as kilobytes, and warns if the usage suggests otherwise.<\/p>\n
If the value is higher than a certain threshold, it looks like this:\n\"Analyzer<\/p>\n
The analyzer was implemented by @amiru3f<\/a>.<\/p>\n
QUIC<\/h2>\n
The prominent changes in QUIC space in .NET 9 include making the library public, more configuration options for connections and several performance improvements.<\/p>\n
Public APIs<\/h3>\n
From this release on, System.Net.Quic<\/code> isn’t hidden behind PreviewFeature<\/code><\/a> anymore and all the APIs are generally available without any opt-in switches (dotnet\/runtime#104227<\/a>).<\/p>\n
QUIC Connection Options<\/h3>\n
We expanded the configuration options for QuicConnection<\/code><\/a> (dotnet\/runtime#72984<\/a>). The implementation (dotnet\/runtime#94211<\/a>) added three new properties to QuicConnectionOptions<\/code><\/a>:<\/p>\n