{"id":1708,"date":"2025-02-06T18:13:18","date_gmt":"2025-02-06T18:13:18","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/02\/06\/net-9-networking-improvements\/"},"modified":"2025-02-06T18:13:18","modified_gmt":"2025-02-06T18:13:18","slug":"net-9-networking-improvements","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/02\/06\/net-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<\/a> APIs, .NET Framework compatibility<\/a> improvements, and more.<\/p>\n

HTTP<\/h2>\n

In the following section, we\u2019re 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

client
\nsingle HTTP\/3 connection
\nmultiple HTTP\/3 connections<\/p>\n

Max CPU Usage (%)
\n35
\n92<\/p>\n

Max Cores Usage (%)
\n971
\n2,572<\/p>\n

Max Working Set (MB)
\n3,810
\n6,491<\/p>\n

Max Private Memory (MB)
\n4,415
\n7,228<\/p>\n

Processor Count
\n28
\n28<\/p>\n

First request duration (ms)
\n519
\n594<\/p>\n

Requests
\n345,446
\n4,325,325<\/p>\n

Mean RPS
\n23,069
\n288,664<\/p>\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 property on SocketsHttpHandler<\/a>:<\/p>\n

var client = new HttpClient(new SocketsHttpHandler
\n{
\n EnableMultipleHttp3Connections = true
\n});<\/p>\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<\/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

Client
\n.NET 8.0
\n.NET 9.0
\nIncrease<\/p>\n

Requests
\n80,028,791
\n107,128,778
\n+33.86%<\/p>\n

Mean RPS
\n666,886
\n892,749
\n+33.87%<\/p>\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\u2019t 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<\/a> returns the same instance upon repeated access and never refetch the settings. As a result, tools like Fiddler, that set themself as system proxy to listen for the traffic, weren\u2019t able to capture traffic from already running processes. This issue was mitigated in dotnet\/runtime#103364<\/a>, where the HttpClient.DefaultProxy is set to an instance of Windows proxy that listens for registry changes and reloads the proxy settings when notified.<\/p>\n

The 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}<\/p>\n

produces output like this:<\/p>\n

null
\n\/\/ After Fiddler’s “System Proxy” is turned on.
\nhttp:\/\/127.0.0.1:8866\/<\/p>\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\u2019t be changed during process lifetime.<\/p>\n

Community contributions<\/h3>\n

We\u2019d like to call out community contributions.<\/p>\n

CancellationToken<\/a> overloads were missing from HttpContent.LoadIntoBufferAsync<\/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 property on SocketsHttpHandler<\/a> and HttpClientHandler<\/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\u2019t 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<\/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 isn\u2019t hidden behind PreviewFeature<\/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<\/a> (dotnet\/runtime#72984<\/a>). The implementation (dotnet\/runtime#94211<\/a>) added three new properties to QuicConnectionOptions<\/a>:<\/p>\n

HandshakeTimeout<\/a> \u2013 we were already imposing a limit on how long a connection establishment can take, this property just enables the user to adjust it.
\nKeepAliveInterval<\/a> \u2013 if this property is set up to a positive value, PING frames<\/a> are sent out regularly in this interval (in case no other activity is happening on the connection) which prevents the connection from being closed on idle timeout<\/a>.
\nInitialReceiveWindowSizes<\/a> \u2013 a set of parameters to adjust the initial receive limits for data flow control sent in transport parameters<\/a>. These data limits apply only until the dynamic flow control algorithm starts adjusting the limits based on the data reading speed. And due to MsQuic<\/a> limitations, these parameters can only be set to values that are power of 2.<\/p>\n

All of these parameters are optional. Their default values are derived from MsQuic defaults<\/a>. The following code reports the defaults programmatically:<\/p>\n

var options = new QuicClientConnectionOptions();
\nConsole.WriteLine($”KeepAliveInterval = {PrettyPrintTimeStamp(options.KeepAliveInterval)}”);
\nConsole.WriteLine($”HandshakeTimeout = {PrettyPrintTimeStamp(options.HandshakeTimeout)}”);
\nConsole.WriteLine(@$”InitialReceiveWindowSizes =
\n{{
\n Connection = {PrettyPrintInt(options.InitialReceiveWindowSizes.Connection)},
\n LocallyInitiatedBidirectionalStream = {PrettyPrintInt(options.InitialReceiveWindowSizes.LocallyInitiatedBidirectionalStream)},
\n RemotelyInitiatedBidirectionalStream = {PrettyPrintInt(options.InitialReceiveWindowSizes.RemotelyInitiatedBidirectionalStream)},
\n UnidirectionalStream = {PrettyPrintInt(options.InitialReceiveWindowSizes.UnidirectionalStream)}
\n}}”);<\/p>\n

static string PrettyPrintTimeStamp(TimeSpan timeSpan)
\n => timeSpan == Timeout.InfiniteTimeSpan ? “infinite” : timeSpan.ToString();<\/p>\n

static string PrettyPrintInt(int sizeB)
\n => sizeB % 1024 == 0 ? $”{sizeB \/ 1024} * 1024″ : sizeB.ToString();<\/p>\n

\/\/ Prints:
\nKeepAliveInterval = infinite
\nHandshakeTimeout = 00:00:10
\nInitialReceiveWindowSizes =
\n{
\n Connection = 16384 * 1024,
\n LocallyInitiatedBidirectionalStream = 64 * 1024,
\n RemotelyInitiatedBidirectionalStream = 64 * 1024,
\n UnidirectionalStream = 64 * 1024
\n}<\/p>\n

Stream Capacity API<\/h3>\n

.NET 9 also introduced new APIs to support multiple HTTP\/3 connections<\/a> in SocketsHttpHandler<\/a> (dotnet\/runtime#101534<\/a>). The APIs were designed with this specific usage in mind, and we don\u2019t expect them to be used apart from very niche scenarios.<\/p>\n

QUIC has built-in logic for managing stream limits<\/a> within the protocol. As a result, calling OpenOutboundStreamAsync<\/a> on a connection gets suspended if there isn\u2019t any available stream capacity. Moreover, there isn\u2019t an efficient way to learn whether the stream limit was reached or not. All these limitations together didn\u2019t allow the HTTP\/3 layer to know when to open a new connection. So we introduced a new StreamCapacityCallback<\/a> that gets called whenever stream capacity is increased. The callback itself is registered via QuicConnectionOptions<\/a>. More details about the callback can be found in the documentation<\/a>.<\/p>\n

Performance Improvements<\/h3>\n

Both performance improvements in System.Net.Quic are TLS related and both only affect connection establishing times.<\/p>\n

The first performance related change was to run the peer certificate validation asynchronously in .NET thread pool (dotnet\/runtime#98361<\/a>). The certificate validation can be time consuming on its own and it might even include an execution of a user callback. Moving this logic to .NET thread pool stops us blocking the MsQuic thread, of which MsQuic has a limited number, and thus enables MsQuic to process higher number of new connections at the same time.<\/p>\n

On top of that, we have introduced caching of MsQuic configuration (dotnet\/runtime#99371<\/a>). MsQuic configuration is a set of native structures containing connection settings from QuicConnectionOptions<\/a>, potentially including certificate and its intermediaries. Constructing and initializing the native structure might be very expensive since it might require serializing and deserializing all the certificate data to and from PKS #12<\/a> format. Moreover, the cache allows reusing the same MsQuic configuration for different connections if their settings are identical. Specifically server scenarios with static configuration can notably profit from the caching, like the following code:<\/p>\n

var alpn = “test”;
\nvar serverCertificate = X509CertificateLoader.LoadCertificateFromFile(“..\/path\/to\/cert”);<\/p>\n

\/\/ Prepare the connection option upfront and reuse them.
\nvar serverConnectionOptions = new QuicServerConnectionOptions()
\n{
\n DefaultStreamErrorCode = 123,
\n DefaultCloseErrorCode = 456,
\n ServerAuthenticationOptions = new SslServerAuthenticationOptions
\n {
\n ApplicationProtocols = new List<SslApplicationProtocol>() { alpn },
\n \/\/ Re-using the same certificate.
\n ServerCertificate = serverCertificate
\n }
\n};<\/p>\n

\/\/ Configure the listener to return the pre-prepared options.
\nawait using var listener = await QuicListener.ListenAsync(new QuicListenerOptions()
\n{
\n ListenEndPoint = new IPEndPoint(IPAddress.Loopback, 0),
\n ApplicationProtocols = [ alpn ],
\n \/\/ Callback returns the same object.
\n \/\/ Internal cache will re-use the same native structure for every incoming connection.
\n ConnectionOptionsCallback = (_, _, _) => ValueTask.FromResult(serverConnectionOptions)
\n});<\/p>\n

We also built it an escape hatch for this feature, it can be turned off with either environment variable:<\/p>\n

export DOTNET_SYSTEM_NET_QUIC_DISABLE_CONFIGURATION_CACHE=1
\n# run the app<\/p>\n

or with an AppContext<\/a> switch:<\/p>\n

AppContext.SetSwitch(“System.Net.Quic.DisableConfigurationCache”, true);<\/p>\n

WebSockets<\/h2>\n

.NET 9 introduces the long-desired PING\/PONG Keep-Alive strategy to WebSockets (dotnet\/runtime#48729<\/a>).<\/p>\n

Prior to .NET 9, the only available Keep-Alive strategy was Unsolicited PONG. It was enough to keep the underlying TCP connection from idling out, but in a case when a remote host becomes unresponsive (for example, a remote server crashes), the only way to detect such situations was to depend on the TCP timeout.<\/p>\n

In this release, we complement the existing KeepAliveInterval setting with the new KeepAliveTimeout setting, so that the Keep-Alive strategy is selected as follows:<\/p>\n

Keep-Alive is OFF<\/strong>, if<\/p>\n

KeepAliveInterval is TimeSpan.Zero or Timeout.InfiniteTimeSpan<\/p>\n

Unsolicited PONG<\/strong>, if<\/p>\n

KeepAliveInterval is a positive finite TimeSpan, -AND-
\nKeepAliveTimeout is TimeSpan.Zero or Timeout.InfiniteTimeSpan<\/p>\n

PING\/PONG<\/strong>, if<\/p>\n

KeepAliveInterval is a positive finite TimeSpan, -AND-
\nKeepAliveTimeout is a positive finite TimeSpan<\/p>\n

By default, the preexisting Keep-Alive behavior is maintained: KeepAliveTimeout default value is Timeout.InfiniteTimeSpan, so Unsolicited PONG remains as the default strategy.<\/p>\n

The following example illustrates how to enable the PING\/PONG strategy for a ClientWebSocket:<\/p>\n

var cws = new ClientWebSocket();
\ncws.Options.KeepAliveInterval = TimeSpan.FromSeconds(10);
\ncws.Options.KeepAliveTimeout = TimeSpan.FromSeconds(10);
\nawait cws.ConnectAsync(uri, cts.Token);<\/p>\n

\/\/ NOTE: There should be an outstanding read at all times to
\n\/\/ ensure incoming PONGs are promptly processed
\nvar result = await cws.ReceiveAsync(buffer, cts.Token);<\/p>\n

If no PONG response received after KeepAliveTimeout elapsed, the remote endpoint is deemed unresponsive, and the WebSocket connection is automatically aborted. It also unblocks the outstanding ReceiveAsync with an OperationCanceledException.<\/p>\n

To learn more about the feature, you can check out the dedicated conceptual docs<\/a>.<\/p>\n

.NET Framework Compatibility<\/h2>\n

One of the biggest hurdles in the networking space when migrating projects from .NET Framework to .NET Core is the difference between the HTTP stacks. In .NET Framework, the main class to handle HTTP requests is HttpWebRequest<\/a> which uses global ServicePointManager<\/a> and individual ServicePoints<\/a> to handle connection pooling. Whereas in .NET Core, HttpClient<\/a> is the recommended way to access HTTP resources. On top of that, all the classes from .NET Framework are present in .NET, but they\u2019re either obsolete, or missing implementation, or are just not maintained at all. As a result, we often see mistakes like using ServicePointManager to configure the connections while using HttpClient to access the resources.<\/p>\n

The recommendation always was to fully migrate to HttpClient, but sometimes it\u2019s not possible. Migrating projects from .NET Framework to .NET Core can be difficult on its own, let alone rewriting all the networking code. Expecting customers to do all this work in one step proved to be unrealistic and is one of the reasons why customers might be reluctant to migrate. To mitigate these pain points, we filled in some missing implementations of the legacy classes and created a comprehensive guide to help with the migration.<\/p>\n

The first part is expansion of supported ServicePointManager and ServicePoint properties that were missing implementation in .NET Core up until this release (dotnet\/runtime#94664<\/a> and dotnet\/runtime#97537<\/a>). With these changes, they\u2019re now taken into account when using HttpWebRequest<\/a>.<\/p>\n

For HttpWebRequest<\/a>, we implemented full support of AllowWriteStreamBuffering<\/a> in dotnet\/runtime#95001<\/a>. And also added missing support for ImpersonationLevel<\/a> in dotnet\/runtime#102038<\/a>.<\/p>\n

On top of these changes, we also obsoleted a few legacy classes to prevent further confusion:<\/p>\n

ServicePointManager<\/a> in dotnet\/runtime#103456<\/a>. Its settings have no effect on HttpClient and SslStream while it might be misused in good faith for exactly that purpose.
\nAuthenticationManager<\/a> in dotnet\/runtime#93171<\/a>, done by community contributor @deeprobin<\/a>. It\u2019s either missing implementation or the methods throw PlatformNotSupportedException.<\/p>\n

Lastly, we put up together a guide for migration from HttpWebRequest to HttpClient in HttpWebRequest to HttpClient migration guide<\/em><\/a>. It includes comprehensive lists of mappings between individual properties and methods, e.g., Migrate ServicePoint(Manager) usage<\/em><\/a> and many examples for trivial and not so trivial scenarios, e.g., Example: Enable DNS round robin<\/em><\/a>.<\/p>\n

Diagnostics<\/h2>\n

In this release, diagnostics improvements focus on enhancing privacy protection and advancing distributed tracing capabilities.<\/p>\n

Uri Query Redaction in HttpClientFactory Logs<\/h3>\n

Starting with version 9.0.0 of Microsoft.Extensions.Http<\/a>, the default logging logic of HttpClientFactory prioritizes protecting privacy<\/em>. In older versions, it emits the full request URI in the RequestStart and RequestPipelineStart events. In cases where some components of the URI contain sensitive information, this can lead to privacy incidents by leaking such data into logs.<\/p>\n

Version 8.0.0 introduced the ability to secure HttpClientFactory usage by customizing logging<\/a>. However, this doesn\u2019t change the fact that the default behavior might be risky for unaware users.<\/p>\n

In the majority of the problematic cases, sensitive information resides in the query component. Therefore, a breaking change<\/a> was introduced in 9.0.0, removing the entire query string from HttpClientFactory logs by default. A global opt-out switch<\/a> is available for services\/apps where it\u2019s safe to log the full URI.<\/p>\n

For consistency and maximum safety, a similar change<\/a> was implemented for EventSource<\/a> events in System.Net.Http.<\/p>\n

We recognize that this solution might not suit everyone. Ideally, there should be a fine-grained URI filtering mechanism, allowing users to retain non-sensitive query entries or filter other URI components (e.g., parts of the path). We plan to explore such a feature for future versions (dotnet\/runtime#110018<\/a>).<\/p>\n

Distributed Tracing Improvements<\/h3>\n

Distributed tracing<\/a> is a diagnostic technique for tracking the path of a specific transaction across multiple processes and machines, helping identify bottlenecks and failures. This technique models the transaction as a hierarchical tree of Activities<\/a>, also referred to as spans<\/a> in OpenTelemetry terminology.<\/p>\n

HttpClientHandler and SocketsHttpHandler are instrumented to start an Activity for each request and propagate the trace context<\/a> via standard W3C headers when tracing is enabled.<\/p>\n

Before .NET 9, users needed the OpenTelemetry .NET SDK to produce useful OpenTelemetry-compliant traces. This SDK was required not just for collection and export but also to extend the instrumentation<\/a>, as the built-in logic didn\u2019t populate the Activity with request data.<\/p>\n

Starting with .NET 9, the instrumentation dependency (OpenTelemetry.Instrumentation.Http) can be omitted unless advanced features like enrichment are required. In dotnet\/runtime#104251<\/a>, we extended the built-in tracing to ensure that the shape of the Activity is OTel-compliant<\/a>, with the name, status, and most required tags populated according to the standard.<\/p>\n

Experimental Connection Tracing<\/h4>\n

When investigating bottlenecks, you might want to zoom into specific HTTP requests to identify where most of the time is spent. Is it during a connection establishment or the content download? If there are connection issues, it\u2019s helpful to determine whether the problem lies with DNS lookups, TCP connection establishment, or the TLS handshake.<\/p>\n

.NET 9 has introduced several new spans to represent activities around connection establishment in SocketsHttpHandler. The most significant one HTTP connection setup span which breaks down to three child spans for DNS, TCP, and TLS activities.<\/p>\n

Because connection setup isn\u2019t tied to a particular request in SocketsHttpHandler connection pool, the connection setup span can\u2019t be modeled as a child span of the HTTP client request span. Instead, the relationship between requests and connections is being represented using Span Links<\/a>, also known as Activity Links.<\/p>\n\n

\n

Note<\/strong><\/p>\n

The new spans are produced by various ActivitySources matching the wildcard Experimental.System.Net.*. These spans are experimental because monitoring tools like Azure Monitor Application Insights<\/a> have difficulty visualizing the resulting traces effectively due to the numerous connection_setup \u2192 request backlinks. To improve the user experience in monitoring tools, further work is needed. It involves collaboration between the .NET team, OTel, and tool authors, and may result in breaking changes in the design of the new spans.<\/p><\/div>\n

The simplest way to set up and try connection trace collection is by using .NET Aspire<\/a>. Using Aspire Dashboards<\/a> it\u2019s possible to expand the connection_setup activity and see a breakdown of the connection initialization.<\/p>\n\n

If you think the .NET 9 tracing additions might bring you valuable diagnostic insights, and you want to get some hands-on experience, don\u2019t hesitate to read our full article about Distributed tracing in System.Net libraries<\/a>.<\/p>\n

HttpClientFactory<\/h2>\n

For HttpClientFactory, we\u2019re introducing the Keyed DI support, offering a new convenient consumption pattern, and changing a default Primary Handler to mitigate a common erroneous usecase.<\/p>\n

Keyed DI Support<\/h3>\n

In the previous release, Keyed Services<\/a> were introduced to Microsoft.Extensions.DependencyInjection<\/a> packages. Keyed DI allows you to specify the keys while registering multiple implementations of a single service type\u2014and to later retrieve a specific implementation using the respective key.<\/p>\n

HttpClientFactory and named HttpClient instances, unsurprisingly, align well with the Keyed Services idea. Among other things, HttpClientFactory was a way to overcome this long-missing DI feature. But it required you to obtain, store and query the IHttpClientFactory instance\u2014instead of simply injecting a configured HttpClient\u2014which might be inconvenient. While Typed clients attempted to simplify that part, it came with a catch: Typed clients are easy to misconfigure<\/a> and misuse<\/a> (and the supporting infra can also be a tangible overhead in certain scenarios<\/a>). As a result, the user experience in both cases was far from ideal.<\/p>\n

This changes as Microsoft.Extensions.DependencyInjection<\/a> 9.0.0 and Microsoft.Extensions.Http<\/a> 9.0.0 packages bring the Keyed DI support into HttpClientFactory (dotnet\/runtime#89755<\/a>). Now you can have the best of both worlds: you can pair the convenient, highly configurable HttpClient registrations with the straightforward injection of the specific configured HttpClient instances.<\/p>\n

As of 9.0.0, you need to opt in<\/em> to the feature by calling the AddAsKeyed()<\/a> extension method. It registers a Named HttpClient as a Keyed service for the key equal to the client\u2019s name\u2014and enables you to use the Keyed Services APIs (e.g., [FromKeyedServices(…)]<\/a>) to obtain the required HttpClients.<\/p>\n

The following code demonstrates the integration between HttpClientFactory, Keyed DI and ASP.NET Core 9.0 Minimal APIs:<\/p>\n

var builder = WebApplication.CreateBuilder(args);<\/p>\n

builder.Services.AddHttpClient(“github”, c =>
\n {
\n c.BaseAddress = new Uri(“https:\/\/api.github.com\/”);
\n c.DefaultRequestHeaders.Add(“Accept”, “application\/vnd.github.v3+json”);
\n c.DefaultRequestHeaders.Add(“User-Agent”, “dotnet”);
\n })
\n .AddAsKeyed(); \/\/ Add HttpClient as a Keyed Scoped service for key=”github”<\/p>\n

var app = builder.Build();<\/p>\n

\/\/ Directly inject the Keyed HttpClient by its name
\napp.MapGet(“\/”, ([FromKeyedServices(“github”)] HttpClient httpClient) =>
\n httpClient.GetFromJsonAsync<Repo>(“\/repos\/dotnet\/runtime”));<\/p>\n

app.Run();<\/p>\n

record Repo(string Name, string Url);<\/p>\n

Endpoint response:<\/p>\n

> ~ curl http:\/\/localhost:5000\/
\n{“name”:”runtime”,”url”:”https:\/\/api.github.com\/repos\/dotnet\/runtime”}<\/p>\n

By default, AddAsKeyed() registers HttpClient as a Keyed Scoped<\/em> service. The Scoped lifetime can help catching cases of captive dependencies:<\/p>\n

services.AddHttpClient(“scoped”).AddAsKeyed();
\nservices.AddSingleton<CapturingSingleton>();<\/p>\n

\/\/ Throws: Cannot resolve scoped service ‘System.Net.Http.HttpClient’ from root provider.
\nrootProvider.GetRequiredKeyedService<HttpClient>(“scoped”);<\/p>\n

using var scope = provider.CreateScope();
\nscope.ServiceProvider.GetRequiredKeyedService<HttpClient>(“scoped”); \/\/ OK<\/p>\n

\/\/ Throws: Cannot consume scoped service ‘System.Net.Http.HttpClient’ from singleton ‘CapturingSingleton’.
\npublic class CapturingSingleton([FromKeyedServices(“scoped”)] HttpClient httpClient)
\n\/\/{ …<\/p>\n

You can also explicitly specify the lifetime by passing the ServiceLifetime parameter to the AddAsKeyed() method:<\/p>\n

services.AddHttpClient(“explicit-scoped”)
\n .AddAsKeyed(ServiceLifetime.Scoped);<\/p>\n

services.AddHttpClient(“singleton”)
\n .AddAsKeyed(ServiceLifetime.Singleton);<\/p>\n

You don\u2019t have to call AddAsKeyed for every single client\u2014you can easily opt in \u201cglobally\u201d (for any client name) via ConfigureHttpClientDefaults. From Keyed Services perspective, it results in the KeyedService.AnyKey<\/a> registration.<\/p>\n

services.ConfigureHttpClientDefaults(b => b.AddAsKeyed());<\/p>\n

services.AddHttpClient(“foo”, \/* … *\/);
\nservices.AddHttpClient(“bar”, \/* … *\/);<\/p>\n

public class MyController(
\n [FromKeyedServices(“foo”)] HttpClient foo,
\n [FromKeyedServices(“bar”)] HttpClient bar)
\n\/\/{ …<\/p>\n

Even though the \u201cglobal\u201d opt-in is a one-liner, it\u2019s unfortunate that the feature still requires it, instead of just working \u201cout of the box\u201d. For full context and reasoning on that decision, see dotnet\/runtime#89755<\/a> and dotnet\/runtime#104943<\/a>.<\/p>\n

You can explicitly opt out from Keyed DI for HttpClients by calling RemoveAsKeyed()<\/a> (for example, per specific client, in case of the \u201cglobal\u201d opt-in):<\/p>\n

services.ConfigureHttpClientDefaults(b => b.AddAsKeyed()); \/\/ opt IN by default
\nservices.AddHttpClient(“keyed”, \/* … *\/);
\nservices.AddHttpClient(“not-keyed”, \/* … *\/).RemoveAsKeyed(); \/\/ opt OUT per name<\/p>\n

provider.GetRequiredKeyedService<HttpClient>(“keyed”); \/\/ OK
\nprovider.GetRequiredKeyedService<HttpClient>(“not-keyed”); \/\/ Throws: No service for type ‘System.Net.Http.HttpClient’ has been registered.
\nprovider.GetRequiredKeyedService<HttpClient>(“unknown”); \/\/ OK (unconfigured instance)<\/p>\n

If called together, or any of them more than once, AddAsKeyed() and RemoveAsKeyed() generally follow the rules of HttpClientFactory configs and DI registrations:<\/p>\n

If used within the same name, the last setting wins: the lifetime from the last AddAsKeyed() is used to create the Keyed registration (unless RemoveAsKeyed() was called last, in which case the name is excluded).
\nIf used only within ConfigureHttpClientDefaults, the last setting wins.
\nIf both ConfigureHttpClientDefaults and a specific client name were used, all defaults are considered to \u201chappen\u201d before all per-name settings for this client. Thus, the defaults can be disregarded, and the last of the per-name ones wins.<\/p>\n

You can learn more about the feature in the dedicated conceptual docs<\/a>.<\/p>\n

Default Primary Handler Change<\/h3>\n

One of the most common problems HttpClientFactory users run into is when a Named or a Typed client erroneously gets captured in a Singleton service<\/a>, or, in general, stored somewhere for a period of time that\u2019s longer than the specified HandlerLifetime. Because HttpClientFactory can\u2019t rotate such handlers, they might end up not respecting DNS changes<\/a>. It is, unfortunately, easy and seemingly \u201cintuitive\u201d to inject a Typed client into a singleton, but hard to have any kind of check\/analyzer to make sure HttpClient isn\u2019t captured when it wasn\u2019t supposed to. It might be even harder to troubleshoot the resulting issues.<\/p>\n

On the other hand, the problem can be mitigated<\/a> by using SocketsHttpHandler, which can control PooledConnectionLifetime. Similarly to HandlerLifetime, it allows regularly recreating connections to pick up the DNS changes, but on a lower level. A client with PooledConnectionLifetime set up can be safely used as a Singleton.<\/p>\n

Therefore, to minimize the potential impact of the erroneous usage patterns, .NET 9 makes the default Primary handler a SocketsHttpHandler (on platforms that support it; other platforms, e.g. .NET Framework, continue to use HttpClientHandler). And most importantly, SocketsHttpHandler also has the PooledConnectionLifetime property preset<\/em> to match the HandlerLifetime value (it reflects the latest value, if you configured HandlerLifetime one or more times).<\/p>\n

The change only affects cases when the client was not<\/em> configured to have a custom Primary handler (via e.g. ConfigurePrimaryHttpMessageHandler<T>()).<\/p>\n

While the default Primary handler is an implementation detail, as it was never specified in the docs, it\u2019s still considered a breaking change<\/a>. There could be cases in which you wanted to use the specific type, for example, casting the Primary handler to HttpClientHandler to set properties like ClientCertificates, UseCookies, UseProxy, etc. If you need to use such properties, it\u2019s suggested to check for both HttpClientHandler and SocketsHttpHandler in the configuration action:<\/p>\n

services.AddHttpClient(“test”)
\n .ConfigurePrimaryHttpMessageHandler((h, _) =>
\n {
\n if (h is HttpClientHandler hch)
\n {
\n hch.UseCookies = false;
\n }<\/p>\n

if (h is SocketsHttpHandler shh)
\n {
\n shh.UseCookies = false;
\n }
\n });<\/p>\n

Alternatively, you can explicitly specify a Primary handler for each of your clients:<\/p>\n

services.AddHttpClient(“test”)
\n .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler() { UseCookies = false });<\/p>\n

Or, configure the default Primary handler for all clients using ConfigureHttpClientDefaults:<\/p>\n

services.ConfigureHttpClientDefaults(b =>
\n b.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler() { UseCookies = false }));<\/p>\n

Security<\/h2>\n

In System.Net.Security, we\u2019re introducing the highly sought support for SSLKEYLOGFILE, more scenarios supporting TLS resume, and new additions in negotiate APIs.<\/p>\n

SSLKEYLOGFILE Support<\/h3>\n

The most upvoted issue in the security space was to support logging of pre-master secret (dotnet\/runtime#37915<\/a>). The logged secret can be used by packet capturing tool Wireshark to decrypt the traffic. It\u2019s a useful diagnostics tool when investigating networking issues. Moreover, the same functionality is provided by browsers like Firefox (via NSS<\/a>) and Chrome and command line HTTP tools like cURL<\/a>.
\nWe have implemented this feature for both SslStream<\/a> and QuicConnection<\/a>. For the former, the functionality is limited to the platforms on which we use OpenSSL as a cryptographic library. In the terms of the officially released .NET runtime, it means only on Linux operating systems. For the latter, it\u2019s supported everywhere, regardless of the cryptographic library. That\u2019s because TLS is part of the QUIC protocol (RFC 9001<\/a>) so the user-space MsQuic has access to all the secrets and so does .NET. The limitation of SslStream on Windows comes from SChannel using a separate, privileged process for TLS which won\u2019t allow exporting secrets due to security concerns (dotnet\/runtime#94843<\/a>).<\/p>\n

This feature exposes security secrets and relying solely on an environmental variable could unintentionally leak them. For that reason, we\u2019ve decided to introduce an additional AppContext switch necessary to enable the feature (dotnet\/runtime#100665<\/a>). It requires the user to prove the ownership of the application by either setting it programmatically in the code:<\/p>\n

AppContext.SetSwitch(“System.Net.EnableSslKeyLogging”, true);<\/p>\n

or by changing the {appname}.runtimeconfig.json next to the application:<\/p>\n

{
\n “runtimeOptions”: {
\n “configProperties”: {
\n “System.Net.EnableSslKeyLogging”: true
\n }
\n }
\n}<\/p>\n

The last thing is to set up an environmental variable SSLKEYLOGFILE and run the application:<\/p>\n

export SSLKEYLOGFILE=~\/keylogfile<\/p>\n

.\/<appname><\/p>\n

At this point, ~\/keylogfile will contain pre-master secrets that can be used by Wireshark to decrypt the traffic. For more information, see TLS Using the (Pre)-Master-Secret<\/a> documentation.<\/p>\n

TLS Resume with Client Certificate<\/h3>\n

TLS resume enables reusing previously stored TLS data to re-establish connection to previously connected server. It can save round trips during the handshake as well as CPU processing. This feature is a native part of Windows SChannel, therefore it\u2019s implicitly used by .NET on Windows platforms. However, on Linux platforms where we use OpenSSL as a cryptographic library, enabling caching and reusing TLS data is more involved. We first introduced the support in .NET 7 (see TLS Resume<\/a>). It has its own limitations that in general are not present on Windows. One such limitation was that it was not supported for sessions using mutual authentication by providing a client certificate (dotnet\/runtime#94561<\/a>). It has been fixed in .NET 9 (dotnet\/runtime#102656<\/a>) and works if one these properties is set as described:<\/p>\n

ClientCertificateContext<\/a>
\nLocalCertificateSelectionCallback<\/a> returns non-null certificate on the first call
\nClientCertificates<\/a> collection has at least one certificate with private key<\/p>\n

Negotiate API Integrity Checks<\/h3>\n

In .NET 7, we added NegotiateAuthentication<\/a> APIs, see Negotiate API<\/a>. The original implementation\u2019s goal was to remove access via reflection to the internals of NTAuthentication. However, that proposal was missing functions to generate and verify message integrity codes from RFC 2743<\/a>. They\u2019re usually implemented as cryptographic signing operation with a negotiated key. The API was proposed in dotnet\/runtime#86950<\/a> and implemented in dotnet\/runtime#96712<\/a> and as the original change, all the work from the API proposal to the implementation was done by a community contributor filipnavara<\/a>.<\/p>\n

Networking Primitives<\/h2>\n

This section encompasses changes in System.Net namespace. We\u2019re introducing new support for server-side events and some small additions in APIs, for example new MIME types.<\/p>\n

Server-Sent Events Parser<\/h3>\n

Server-sent events is a technology that allows servers to push data updates on clients via an HTTP connection. It is defined in living HTML standard<\/a>. It uses text\/event-stream MIME type and it\u2019s always decoded as UTF-8. The advantage of the server-push approach over client-pull is that it can make better use of network resources and also save battery life of mobile devices.<\/p>\n

In this release, we\u2019re introducing an OOB package System.Net.ServerSentEvents. It\u2019s available as a .NET Standard 2.0 NuGet package<\/a>. The package offers a parser for server-sent event stream, following the specification<\/a>. The protocol is stream based, with individual items separated by an empty line.<\/p>\n

Each item has two fields:<\/p>\n

type \u2013 default type is message
\ndata \u2013 data itself<\/p>\n

On top of that, there are two other optional fields that progressively update properties of the stream:<\/p>\n

id \u2013 determines the last event id that is sent in Last-Event-Id header<\/a> in case the connection needs to be reconnected
\nretry \u2013 number of milliseconds to wait between reconnection attempts<\/p>\n

The library APIs were proposed in dotnet\/runtime#98105<\/a> and contain type definitions for the parser and the items:<\/p>\n

SseParser<\/a> \u2013 static class to create the actual parser from the stream, allowing the user to optionally provide a parsing delegate for the item data
\nSseParser<T><\/a> \u2013 parser itself, offers methods to enumerate (synchronously or asynchronously) the stream and return the parsed items
\nSseItem<T><\/a> \u2013 struct holding parsed item data<\/p>\n

Then the parser can be used like this, for example:<\/p>\n

using HttpClient client = new HttpClient();
\nusing Stream stream = await client.GetStreamAsync(“https:\/\/server\/sse”);<\/p>\n

var parser = SseParser.Create(stream, (type, data) =>
\n{
\n var str = Encoding.UTF8.GetString(data);
\n return Int32.Parse(str);
\n});
\nawait foreach (var item in parser.EnumerateAsync())
\n{
\n Console.WriteLine($”{item.EventType}: {item.Data} [{parser.LastEventId};{parser.ReconnectionInterval}]”);
\n}<\/p>\n

And for the following input:<\/p>\n

: stream of integers<\/p>\n

data: 123
\nid: 1
\nretry: 1000<\/p>\n

data: 456
\nid: 2<\/p>\n

data: 789
\nid: 3<\/p>\n

It outputs:<\/p>\n

message: 123 [1;00:00:01]
\nmessage: 456 [2;00:00:01]
\nmessage: 789 [3;00:00:01]<\/p>\n

Primitives Additions<\/h3>\n

Apart from server sent event, System.Net namespace got a few small other additions:<\/p>\n

IEquatable<Uri> interface implementation for Uri<\/a> in dotnet\/runtime#97940<\/a><\/p>\n

Which allows using Uri in functions that require IEquatable like Span.Contains<\/a>-0)) or SequenceEquals<\/a>-system-readonlyspan((-0))))<\/p>\n

span-based (Try)EscapeDataString<\/a>)) and (Try)UnescapeDataString<\/a>)) for Uri in dotnet\/runtime#40603<\/a><\/p>\n

The goal is to support low-allocation scenarios and we now take advantage of these methods in FormUrlEncodedContent<\/a>.<\/p>\n

new MIME types for MediaTypeNames<\/a> in dotnet\/runtime#95446<\/a><\/p>\n

These types were collected over the course of the release and implemented in dotnet\/runtime#103575<\/a> by a community contributor @CollinAlpert<\/a>.<\/p>\n

Final Notes<\/h2>\n

As each year, we try to write about the interesting and impactful changes in the networking space. This article can\u2019t possibly cover all the changes that were made. If you are interested, you can find the complete list in our
\ndotnet\/runtime<\/a>
\nrepository where you can also reach out to us with question and bugs. On top of that, many of the performance changes that are not mentioned here are in Stephen\u2019s great article Performance Improvements in .NET 9<\/a>. We\u2019d also like to hear from you, so if you encounter an issue or have any feedback, you can file it in our GitHub repo<\/a>.<\/p>\n

Lastly, I\u2019d like to thank my co-authors:<\/p>\n

@antonfirsov<\/a> who wrote Diagnostics<\/a>.
\n@CarnaViire<\/a> who wrote HttpClientFactory<\/a> and WebSockets<\/a>.<\/p>\n

The post .NET 9 Networking Improvements<\/a> appeared first on .NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

Continuing our tradition, we are excited to share a blog post highlighting the latest and most interesting changes in the […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-1708","post","type-post","status-publish","format-standard","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1708"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1708\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}