.NET 10 brings a focused set of networking improvements that matter specifically to teams running high-throughput ASP.NET Core services: a cleaner WebSocket API, reduced TLS overhead in WinHttpHandler, macOS TLS 1.3 support, a new HTTP verb, unified cipher suite reporting, and a long-awaited Server-Sent Events formatter. None of these are cosmetic. Each addresses a real friction point - buffering complexity, certificate validation overhead, cross-platform TLS gaps, and SSE production workflows. This article walks through what changed, what it means for production systems, and what your team should prioritise adopting now versus later.
Most of these networking changes matter only under specific load. The full set of examples is on Patreon, ready to benchmark against your own workload.
WebSocketStream: The Missing Abstraction Your Team Has Needed
Raw WebSocket code has always been painful to write correctly in .NET. Every team ends up building the same three things: a receive buffer, an EndOfMessage check loop, and some kind of wrapper to pipe data into a JSON deserializer or text parser. It is error-prone, verbose, and mostly boilerplate.
.NET 10 introduces WebSocketStream - a stream-based abstraction over WebSocket connections that eliminates all of that plumbing. Instead of managing receive loops and memory buffers manually, you work with standard stream primitives that compose naturally with JsonSerializer, StreamReader, compressors, and anything else in the .NET I/O ecosystem.
Why Does This Matter for Enterprise ASP.NET Core Teams?
Enterprise systems tend to have long-lived WebSocket connections serving real-time data feeds, event streams, or binary protocol bridges. The old pattern required teams to own the message framing logic, which meant subtle bugs around buffer sizing and EndOfMessage sequencing were always lurking. WebSocketStream transfers that responsibility to the framework.
Three core patterns you need to know:
- Message-oriented reads (JSON payloads): Use
CreateReadableMessageStream with JsonSerializer.DeserializeAsync. The stream ends precisely at the message boundary - no manual loop, no intermediate MemoryStream, no EndOfMessage flag tracking.
- Continuous text protocols (STOMP, line-based): Use
Create to get a raw transport stream, then layer a StreamReader on top. UTF-8 handling is automatic; reads compose cleanly with standard text parsers across frames.
- Binary writes (AMQP, custom binary frames): Use
CreateWritableMessageStream, write chunk-by-chunk, and Dispose the stream - this sends the EOM marker for you, removing the need for explicit EndOfMessage coordination.
Adoption decision: If your team has any ASP.NET Core service with raw WebSocket handling, this is a high-priority upgrade. The migration is mechanical: swap the receive loop for CreateReadableMessageStream and delete the boilerplate. Gains include improved readability, fewer buffer-related bugs, and better integration with existing stream-aware libraries.
What to skip for now: WebSocketStream is not relevant if your team uses SignalR - SignalR manages the WebSocket layer internally. This is for teams using raw WebSocket directly.
If your ASP.NET Core services run on Windows (common in on-premise enterprise deployments or Azure Windows VMs) and you use a custom ServerCertificateValidationCallback on WinHttpHandler, .NET 10 offers a measurable performance improvement: certificate validation result caching.
What Changed
Previously, WinHttpHandler invoked the custom ServerCertificateValidationCallback on every single outbound request. Building the full certificate chain on each request is expensive - it involves native WinHTTP calls, chain building, and your custom validation logic. Under high-throughput conditions (microservices making hundreds of outbound API calls per second), this adds up fast.
.NET 10 adds opt-in certificate caching keyed by server IP address. Once a certificate is validated for a given server, subsequent requests skip the chain-building and callback invocation entirely. The cache is cleared on connection recreation, so it does not bypass re-validation when the underlying connection changes.
Is This Safe?
Yes, with a caveat. The caching is deliberately opt-in behind an AppContext switch (System.Net.Http.UseWinHttpCertificateCaching). The team chose this approach because custom callbacks vary widely - some teams use them for certificate pinning, mTLS validation, or custom revocation logic. The opt-in ensures existing behaviour is unchanged unless you explicitly enable it.
For enterprise teams with high-throughput outbound HTTP on Windows, the benchmark impact is significant - cumulative time savings scale linearly with request volume, which makes this particularly relevant for internal service-to-service communication where you own both ends and certificate rotation is controlled.
Adoption decision: Enable this if you are on Windows, using WinHttpHandler with a custom ServerCertificateValidationCallback, and seeing CPU spikes during burst traffic. It is a one-line change and fully reversible.
TLS 1.3 on macOS: The Long-Awaited Gap Is Closed
TLS 1.3 on macOS was one of the most-requested .NET networking issues - open for several releases. The core problem was architectural: Apple's newer TLS APIs combine TLS and TCP into a single unified stack, while .NET exposes SslStream and Socket as independent layers. Bridging that mismatch took significant engineering effort.
What .NET 10 Delivers
.NET 10 adds opt-in client-side TLS 1.3 support on macOS via AppContext or environment variable (DOTNET_SYSTEM_NET_SECURITY_USENETWORKFRAMEWORK=1). The opt-in model exists because enabling it switches the underlying SslStream backend on macOS, which means only TLS 1.2 and TLS 1.3 are supported on that path - older (deprecated) protocol versions are not available.
Impact areas:
- Developer machines running macOS that target services requiring TLS 1.3
- macOS-based CI runners performing integration tests against TLS 1.3-only endpoints
- Cross-platform .NET services deployed on macOS edge nodes
Adoption decision: If your team runs any .NET services on macOS - including developer laptops or CI pipelines - this closes a meaningful compatibility gap. It is particularly relevant if you are hardening outbound TLS requirements across your service mesh and needed macOS parity with Linux and Windows for TLS 1.3.
What Is the HTTP QUERY Verb and Should Your Team Use It Yet?
.NET 10 adds HttpMethod.Query - the first new standardised HTTP verb in years. The QUERY method is designed for safe, idempotent requests that need to include a body, solving a practical problem: complex search or filter queries that exceed URL length limits and cannot use GET (which technically allows a body, but many servers and intermediaries reject it).
The Practical Use Case
Think of search APIs where the query parameters are complex enough to exceed the ~2,000 character URL limit. Today, teams typically work around this with a POST endpoint that has GET semantics - which breaks idempotency expectations and confuses caching layers. QUERY gives you a semantically correct solution: safe, idempotent, body-capable.
Should You Use It Now?
The short answer is: not yet in production. .NET 10 ships only the HttpMethod.Query string constant - the full helper methods are intentionally deferred until the underlying IETF RFC is finalised. Server-side middleware support is also not standardised yet.
Adoption timeline:
- Now: Understand the intent and start designing APIs that could benefit from QUERY semantics.
- When the RFC publishes: .NET will ship the full implementation. At that point, evaluate adoption for internal APIs where you control both client and server.
- For external-facing APIs: Wait until major API gateways and reverse proxies (nginx, YARP, Azure API Management) add native QUERY support.
Unified Cipher Suite Reporting: A Quiet But Important Security Change
.NET 10 obsoletes three SslStream properties - KeyExchangeAlgorithm, HashAlgorithm, and CipherAlgorithm - in favour of the single NegotiatedCipherSuite property backed by TlsCipherSuite, which follows the IANA TLS Cipher Suite specification directly.
Why This Matters
The obsoleted properties had been stale for years. The underlying enums mapped multiple modern algorithms into single enum values, losing important differentiation. Teams relying on those properties for security logging, audit trails, or compliance reporting were getting imprecise data - potentially missing the distinction between different AES-GCM variants, for example.
NegotiatedCipherSuite gives you the exact IANA-defined cipher suite identifier, which is unambiguous and maps directly to security policy documents. The same property has also been added to QuicConnection for consistency.
Adoption decision: If your team logs or audits TLS cipher suite details for compliance (PCI-DSS, SOC 2, ISO 27001), migrate your code from the obsoleted properties to NegotiatedCipherSuite. The old properties will trigger compiler warnings. This is a low-risk, high-value migration for any team with TLS audit requirements.
.NET 9 added a Server-Sent Events parser. .NET 10 completes the picture with SseFormatter - a server-side formatter for emitting SSE streams.
Why This Was Missing
Without a standard formatter, every .NET team implementing real-time push notifications via SSE had to write their own serialisation logic: formatting data: prefixes, handling multi-line payloads, managing id: and event: fields, and streaming the output to the response body. It was repetitive, and subtly inconsistent implementations caused client-side parsing issues.
SseFormatter.WriteAsync accepts an IAsyncEnumerable<SseItem<T>> and a target stream, handles all formatting, and writes the correctly structured SSE payload. For non-string data types, a delegate handles the serialisation step.
What This Enables for Enterprise ASP.NET Core Teams
- Event-driven dashboards: Long-polling endpoint replacements become cleaner - emit a proper SSE stream with event IDs and types without custom formatting.
- AI streaming responses: Streaming LLM output to browser clients is a natural use case -
SseFormatter pairs directly with IAsyncEnumerable<string> response streams.
- Notification pipelines: Replace complex SignalR setups in scenarios where unidirectional push is sufficient, reducing infrastructure overhead.
Internal links: If you are evaluating whether SSE is the right real-time transport for your use case, see our deep-dive on Server-Sent Events vs SignalR vs WebSockets in ASP.NET Core.
Adoption decision: If you build any server-push feature in ASP.NET Core - notification feeds, progress updates, AI streaming endpoints - adopt SseFormatter immediately. It removes boilerplate, ensures correct SSE formatting, and integrates cleanly with ASP.NET Core's streaming response pattern.
Migration Impact: What Breaks, What Needs Attention
Most of .NET 10's networking changes are additive and opt-in. However, teams upgrading from .NET 8 or 9 should be aware of:
- Compiler warnings on
SslStream properties: If your code references KeyExchangeAlgorithm, HashAlgorithm, or CipherAlgorithm, expect [Obsolete] warnings. Migrate to NegotiatedCipherSuite before the next major release.
- macOS TLS behaviour change when opt-in is enabled: Enabling
UseNetworkFramework restricts SslStream on macOS to TLS 1.2 and 1.3 only. If any integration test or legacy connection requires older TLS versions on macOS, do not enable this switch.
WebSocketStream ownership semantics: Pay attention to ownsWebSocket and leaveOpen parameters when constructing WebSocketStream. Incorrect ownership setup leads to premature connection closure in long-lived streaming scenarios.
What to Adopt Now vs. Later
| Feature |
Adopt Now |
Defer |
| WebSocketStream |
✅ - if using raw WebSocket |
- |
| WinHttpHandler cert caching |
✅ - if Windows + custom callback + high throughput |
- |
| TLS 1.3 on macOS (opt-in) |
✅ - if macOS CI/dev + TLS 1.3 required |
- |
| NegotiatedCipherSuite migration |
✅ - fix compiler warnings, compliance logging |
- |
| SseFormatter |
✅ - any SSE endpoint |
- |
| HTTP QUERY verb |
- |
✅ - wait for RFC + server support |
Should Your Team Prioritise the .NET 10 Networking Upgrade?
If your team runs ASP.NET Core services with any of the following, .NET 10 networking improvements deliver concrete production value:
- Real-time WebSocket endpoints handling JSON or binary payloads
- Windows-hosted services with high-volume outbound HTTP and custom TLS validation
- SSE push endpoints (notifications, AI streaming, live dashboards)
- Compliance requirements around TLS cipher suite audit logging
- macOS-based development or CI pipelines connecting to TLS 1.3-only services
For teams already on .NET 10 LTS, these improvements are available today - most require only a targeted code change, not an architectural refactor. For teams still on .NET 8, note that .NET 8 LTS support continues until November 2026, so migration planning can be deliberate rather than rushed.
Frequently Asked Questions
What is WebSocketStream in .NET 10 and when should I use it?
WebSocketStream is a new stream-based abstraction over raw WebSocket connections introduced in .NET 10. Use it when your ASP.NET Core service communicates via raw WebSockets - it eliminates manual buffer management, EndOfMessage tracking, and framing logic. It is not needed if you use SignalR, which handles the WebSocket layer internally.
Is WinHttpHandler certificate caching safe to enable in production?
Yes, when used correctly. The caching is opt-in, keyed by server IP, and cleared on connection recreation. It is safe for services with stable certificate configurations. Teams using dynamic certificate pinning or environments with frequent IP-based certificate rotation should validate behaviour carefully before enabling the System.Net.Http.UseWinHttpCertificateCaching switch in production.
Does .NET 10 support TLS 1.3 on macOS for server-side workloads?
No. The .NET 10 TLS 1.3 support on macOS is client-side only. Server-side usage of SslStream on macOS is not affected by the UseNetworkFramework opt-in. Teams running ASP.NET Core servers on macOS should not enable this switch expecting server-side TLS 1.3 behaviour changes.
What is the HTTP QUERY method and how is it different from GET with a body?
QUERY is a new HTTP verb being standardised by the IETF. Like GET, it is safe and idempotent - it does not modify server state and can be safely retried. Unlike GET, it officially supports a request body, making it the correct choice for complex query payloads that exceed URL length limits. .NET 10 ships only the method constant (HttpMethod.Query); the full implementation awaits RFC publication.
Why were SslStream's KeyExchangeAlgorithm, HashAlgorithm, and CipherAlgorithm deprecated?
Those properties mapped modern TLS cipher suite components to stale enums that did not keep pace with evolving cryptographic standards. Multiple distinct algorithms were collapsed into single enum values, making it impossible to distinguish between them. NegotiatedCipherSuite, backed by the IANA-aligned TlsCipherSuite enum, provides precise, unambiguous cipher suite identification suitable for security logging and compliance reporting.
What is SseFormatter and how does it simplify ASP.NET Core push endpoints?
SseFormatter is a new helper in .NET 10 that handles the server-side formatting of Server-Sent Events streams. Previously, developers had to manually format data:, event:, id:, and retry fields. With SseFormatter.WriteAsync, you pass an IAsyncEnumerable<SseItem<T>> and a target stream, and the formatter handles all serialisation and framing. This makes SSE push endpoints significantly simpler to implement correctly.
Should I upgrade to .NET 10 just for the networking improvements?
Not necessarily. The networking improvements are compelling for teams with specific use cases (raw WebSocket services, Windows WinHttpHandler deployments, SSE endpoints, macOS TLS compliance). However, .NET 10 as a whole - its LTS status until November 2028, runtime performance gains, ASP.NET Core 10 additions, and EF Core 10 improvements - is a strong upgrade case on its own. Evaluate the full platform, not just networking.
About the Author
Celin Daniel is Co-founder of Coding Droplets with 13+ years of hands-on experience building, shipping, and operating .NET and ASP.NET Core systems in production. The guidance here comes from real projects and production incidents, not theory.
