A month after unveiling the production release of .NET 7, Microsoft has introduced several networking enhancements that touch on issues including security, the HTTP transport layer, and APIs.
The updates reflect Microsoft’s belief, as articulated last year by Richard Lander – project manager for the .NET team – that networking is of enormous importance to modern applications.
“There [are] also a lot of new development and diversity of requirements across networking protocols and systems,” Lander wrote. “The networking team focuses on delivering high-performance APIs, primarily for HTTP.”
.NET also needed some networking improvements because it has previously offered weak handling of failed connection attempts. Engineers enhanced the capabilities in .NET 6.0, but those improvements came up short and sometimes produced unexpected request failures, or saw connections time out.
With .NET 7, a failed connection attempt won’t derail unrelated attempts at making other links. And if a request creates a new connection but then is handled by another connection from the pool, the pending connection attempt will time out in the background after a short time without affecting the user.
“With this change, stalled connections will not stall unrelated requests,” the engineers wrote. “Note that the failures of such ‘disowned’ pending connection attempts will happen in the background and never surface to the user, the only way to observe them is to enable telemetry.”
HttpHeaders are more thread-safe in .NET 7. With .NET 6, it was easier for users to inadvertently access the headers at the same time, which could lead to the header values being duplicated, malformed or worse. Header behavior in .NET is more intuitive, with the HttpHeaders matching thread-safety guarantees and concurrently supporting multiple reads – as long as they aren’t modified.
In addition, HTTP/3 is enabled by default in .NET 7 and Microsoft extended HTTP telemetry to HTTP/3.
Microsoft has also done more to support Quick UDP Internet Connections (QUIC), a transport layer tool that uses UDP as its underlying protocol and mandates TLS 1.3 use. QUIC is less chatty than other protocols, and more secure.
“Another interesting difference from well-known transport protocols such as TCP and UDP is that it has stream multiplexing built-in on the transport layer,” Microsoft’s engineers wrote. “This allows having multiple, concurrent, independent data streams that do not affect each other.”
Whether QUIC will replace TCP is a topic of considerable debate. Microsoft argues that QUIC is faster than TCP because it requires fewer round trips to establish and sustain a connection. But QUIC is also challenging to implement and Microsoft worries it has limited adoption so far and may be blocked by some networking components.
Microsoft brought QUIC into a .NET 5 library for internal use for its implementation of HTTP/3. With .NET 7, Microsoft is making the System.Net.Quic library public and exposing its APIs. The APIs are now a preview feature to give engineers a chance to make changes as needed. The APIs include QuicListener for servers for accepting incoming connections, as well as QuicConnection and QuicStream.
Security has also been addressed in .NET 7 with an API that runs authentication for low-level APIs. In previous .NET iterations, the technologies available in the Microsoft Authentication package were exposed in high-level APIs like HttpClient, SmtpClient, and ASP.NET Core, as well as SQL Server libraries. Now authentication can be done for other libraries, including Npgsql PostgreSQL client, MailKit, and Apache Kudu client.
The new API can work with such platforms as Linux, macOS, and iOS as well as Windows.
With .NET 7, IT administrators can see more details of response calls for the WebSocket protocol for such instances as handshake errors with a server. Information about HTTP response headers and status code can hold important information when a handshake success or error happens – such as details for handing the situation or the tokens tied to a session.
In addition, .NET 7 organizations can use WebSocket over HTTP/2, with a connection created over a single stream on an HTTP/2 connection. That allows for “a single TCP connection to be shared between several WebSocket connections and HTTP requests at the same time, resulting in more efficient use of the network,” the .NET engineers wrote. ®