The document discusses HTTP/3 and QUIC support in .NET 7.0, with HTTP/3 providing benefits for unreliable networks and mobile scenarios. It also covers HTTP/2 WebSockets, which allow reusing the HTTP/2 connection at the client level but require an API change. Additionally, it introduces YARP as an open source reverse proxy library built on .NET, highlighting how reverse proxies are useful for load balancing and other scenarios in microservices architectures.
Advancing Engineering with AI through the Next Generation of Strategic Projec...
Networking in .NET 7.0 and YARP: HTTP/3, QUIC, and Reverse Proxies
1. Networking in .NET 7.0 and
YARP
WUG Days Brno 2022
Karel Zikmund – @ziki_cz
2. Agenda
• HTTP/3 and QUIC
• Evolution from HTTP/1.1 and HTTP/2 – key differences
• Advantages
• .NET 7.0 implementation
• Future in .NET 8.0+
• HTTP/2 WebSockets
• YARP – Yet Another Reverse Proxy
• What is Reverse Proxy
• When you need Reverse Proxy?
• YARP in production
5. HTTP/2
• Binary protocol (packets with frames)
• Multiplexing streams on 1 connection
• TCP-based
• 3 RTT (or 2 RTT with TLS 1.3)
• Can be technically without SSL, unencrypted
• Head of the line blocking
• Packet loss blocks all streams, not just the one with lost packet
6. HTTP/3
• Binary protocol (packets with frames)
• Multiplexing streams on 1 connection
• QUIC-based
• QUIC = UDP + TLS
• 1 RTT
• 25.1% of all websites
• Major browsers – https://caniuse.com/http3
7. HTTP/3 – Advantages
• Unreliable networks – last mile network
• No head of the line blocking
• Improved loss recovery
• 0-RTT
• Keys from previous connection
• Dangerous – replay attacks
• Idempotent requests (e.g. harmless GET)
• Connection ID
• Transfer between networks
• Requires server support – by default in .NET
8. QUIC – Pros and Cons
• Multi-path … also for HTTP/3
• RFC in progress
• Increase bandwidth (multiple routes)
• Decrease latency (duplicated traffic) – streaming
• Unreliable delivery
• Not in .NET yet
• Extensible and versioned
• Network appliances (routers, proxies) – problems with UDP
9. HTTP/3 & QUIC – .NET support
• msquic-based – http://github.com/microsoft/msquic
• OSS, x-plat
• HTTP/3
• .NET 7.0 – full support (client and server) on Windows and Linux
• Performance – on par with HTTP/2
• QUIC APIs
• .NET 7.0 – GA quality
• API shape is Preview (reserve right to change it in .NET 8.0)
• Looking for consumers to validate
11. .NET 8.0+
• HTTP/3 enabled by default in Kestrel
• More Performance work
• Finalize QUIC API shape
• Additional non-critical features
• 0-RTT (as opt-in)
• Support macOS, Mobile platforms (iOS, Android)
• Additional protocols and extensions
• gRPC over HTTP/3
• Multi-path
• WebTransport
• QUIC Datagram
12. HTTP/2 WebSockets
• Same WebSocket protocol, just over HTTP/2
• Pros:
• Reuse HTTP/2 connection – better perf
• Client:
13. HTTP/2 WebSockets
• Chrome and Edge – enabled by default
• Uses CONNECT word instead of GET – routes may need update
14. WebSockets Future
• HTTP/3 WebSockets
• WebTransport – WebSockets done right
• Session with multiple QUIC streams
• Multiple sessions on HTTP/3 connection
• Prototype in progress
15. YARP
• Yet Another Reverse Proxy
• https://microsoft.github.io/reverse-proxy
• OSS: https://github.com/microsoft/reverse-proxy
• Layer-7 proxy – terminates & re-issues requests
• Other popular reverse proxies: Nginx, HAProxy, Envoy, Ocelot, …
16. YARP and reverse proxies
• Who used YARP?
• Who used some Reverse Proxy?
• Who knows what a reverse proxy is?
17. What is a reverse proxy
• Public endpoint
• Load balancing between backend servers
• Can offload work from backend servers: Encryption, Auth, Compression, Caching
Reverse
proxy
contoso.com/orders
contoso.com/store
woodgrovebank.com
Public Internet Private Network
18. Reverse proxies – Why to use them?
• Load balancing
• A/B testing, or Version rollout
• Health checks, health status
• Indirection between URL-space and backend implementation
• API Management – consistent API surface for customers
• Offloading from backend
• Auth, compression, encryption, static files (like CDN)
• Authentication migration
• Cloud to On-prem reverse tunnel (*)
• Route local traffic to remote servers (single point of control and config)
• k8s and Service Fabric ingress control
• .NET Framework migration to .NET Core
19. YARP
• Library, not EXE
• 2 releases: 1.0 & 1.1
• .NET 5.0+ support
• Extensibility in C#, layered
• x-plat
• Great perf
• Latest protocols (gRPC , HTTP/3, HTTP/2 WebSockets)
• Drives innovation and perf improvements into .NET
21. YARP – Azure App Service
• Blog post
• 160B+ requests/day … 1.9M RPS
• 14M+ host names
• .NET 6.0 + YARP
• Why?
• Perf improvements
• 80% in throughput in perf tests
• Lower CPU usage
• More extensibility points
• New customer scenarios:
• gRPC, HTTP/3, per-host cipher suite config, custom error pages, …
22. YARP – Dynamics 365
• Announced 2021 November at .NET Conf
• >100B requests/month ... 38.5K RPS
• >7.5PB/month … transferred data
• ~700 instances of YARP
• Original authors
• Started on .NET Core 3.1
23. YARP – Architecture with pipeline
ASP.NET
Routing
TLS Termination
Auth2
Static Files
Other routes
Config
Session
Affinity
Load
Balancing
Request
Transformations
Http
Forwarder
Destination
Enumeration
HttpClient*
Health
checks
Specific
destination
server
http(s)
http(s)
Proxy process
Kestrel
Passive
Health
Checks
24. YARP – Architecture Http Forwarder
ASP.NET
Routing†
TLS Termination
Auth2
Static Files
Other routes
Http
Forwarder
HttpClient*
Specific
destination
server
http(s)
http(s)
Proxy process
Kestrel
Your custom
handler(s)
Request
Transformations
Site Information
/ Cache
Load balancing
Health checks
25. Summary
• HTTP/3 and QUIC support in .NET 7.0
• GA quality
• QUIC API shape may change in .NET 8.0
• Pro: Unreliable networks, Mobile scenarios
• HTTP/2 WebSockets
• Client needs new API call to reuse connection
• Server needs ConnectMethod change
• YARP
• Library, extensible via C#
• Micro-services world needs reverse proxies
@ziki_cz
Editor's Notes
About me:
Work on .NET team for 17y
For last 5 years Manager on Networking team and for YARP (cross-collaboration with ASP.NET team)
RTT = Round-Trip time
Between data centers, from Australia – matters a lot
Known headers not in textual form, custom headers are – built-in compression of repeating headers (HPACK)
100 streams default, technically ok to have multiple connections
TCP slow start, but less 2-3 RTT handshakes
Most major browsers
Akamai (CDN)
Azure Networking – some reverse proxies (not all)
Preview in .NET 6.0 – under a switch
Validation: Non-msquic implementation
You have to supply handler / HttpClient yourself to share HTTP/2 connection
Automatic pooling is bad (ServicePoint)
We throw for ConnectAsync without handler
Why build yet another one? – Extensibility & Customizability
Public endpoint to your sites & services, or as Service mesh
For example: Ingress for k8s and Service Fabric
API Management solution - consistent API surface for customers backed by multitude of micro-services (replace Azure API Management)
Routing local traffic to remote servers (single point of control and config)
Like forward proxy, but client does not have to be aware of it
YARP 1.0 – November 2021
YARP 1.1 – May 2022
Not Lua / C++ … Nginx
On Windows runs better than most other proxies
Can run in IIS and HTTP.sys
Public benchmarks
Community: Node.js migration – throughput was ~6-7x greater on ASP .NET Core; P99 latency was ~2-4x better on ASP .NET Core.
Also GH Discussions and Issues
Announced 8/24 (2022)
We are a library, not EXE
Config from json, but interface pluggable
Apply config change
Advanced mode for even higher customization (large services)