aspnetcore
aspnetcore copied to clipboard
dotnet
Aspnet support for webtransport
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
On the server side, do websockets create more mux overhead than UDP? If so, does this make a good argument for having Blazor support Webtransport? It appears Webtransport just went GA in Chrome a couple weeks ago? Does this mean Edge will follow soon?
https://developer.chrome.com/blog/new-in-chrome-97/#webtransport
Describe the solution you'd like
In the same way client side websocket can be used in Blazor, I would also like to use Webtransport client side connections.
Additional context
No response
@unicomp21 thanks for contacting us.
We use SignalR, so we would only use this transport if SignalR supported it and we deemed worth it.
The very likely answer is that it is very unlikely that we would use something based on UDP. We rely on many TCP features like ordering and flow control which we would need to reimplement if we were using UDP.
I believe WebTransport also supports ordering? Isn't there an option for it? Starting to realize I could really use some help from @nibanks, on the quic team, to explain why there might be a compelling argument for supporting WebTransport. Correct me if I'm wrong, doesn't every tcp/websocket connection lock up resources (ie like memory for send/recv buffers) on the kernel side? I've also seen benchmarks where latency increases as the number of tcp connections, which the kernel must multiplex, moves into the thousands. With webtransport, as opposed to to websocket, I believe it's a single udp socket and the rest (ie per connection data structures) gets handled in user space. Incredibly efficient.
@javiercn WebTransport is based on HTTP/3, which is based on QUIC (for .NET, MsQuic), which is on UDP. IMO, any HTTP/3 stack should eventually support WebTransport, as it seems to be the way the industry is going.
https://developer.chrome.com/blog/new-in-chrome-97/#webtransport
I'm guessing this means Edge, which is based on chromium? Will follow shortly?
I'm guessing this means Edge, which is based on chromium? Will follow shortly?
Yes, Edge is generally in sync with Chrome for features like this.
@nibanks that's fair, but in the context of Blazor its completely abstracted by SignalR, so provided its exposed by SignalR and satisfies the ordering and reliability constraints Blazor Server requires, then it can be used, but in any case, this will be something transparent to Blazor, since it's configured on the SignalR Hub.
@unicomp21 Feel free to file a specific issue for support for this transport in SignalR instead.
@javiercn apologies, I was confused earlier. This isn't a Blazor specific feature. It would be for Aspnet in general, both server and client sides. Any place there is websocket support, the intention would be to also have webtransport support.
We released HTTP/3 support as an experimental feature in .NET 6 and are working to make it non-experimental in 7. As we do that, we should evaluate what, if any, support we'll need to add for WebTransport.
Moving this to the .NET 7 milestone just for that investigation/groundwork. We don't actually plan to ship WebTransport support in .NET 7.
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/#section-2
When an HTTP/3 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to indicate that they both support WebTransport over HTTP/3.
This would require support in our HTTP/3 implementation.
Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
For Blazor SignalR, it requires the browser runtime to use WebTransport and the server to enable that with HTTP Datagram support in the settings frame in the HTTP/3 control stream.
With a custom fork of .NET 6 exposing the QUIC API, I am able to make the server send new byte[]{0, 4, 10, 0x80, 0xFF, 0xD2, 0x77, 1, 0xAB, 0x60, 0x37, 0x42, 1} to enable WebTransport and HTTP Datagram. Then it needs to parse the QPACK-compressed CONNECT request in the request stream and responds with status 200.
The problem is, both QUIC API and QPACK helper classes are internal. I am dealing with the QUIC connection directly since there is no way to customize the one in Kestral. Moreover, I have to tweak the msquic wrapper to support older versions of Windows.
So, I wish .NET expose QUIC API and HTTP/3 helper classes as public APIs or separate nuget packages such that we don't have to wait until November and a big Visual Studio update for .NET 7.
@nibanks if we forked .net http/3 stack to make the webtransport changes, what are the downsides?
I am not familiar with building the SDK/runtime itself, so I am using the same namespace in my assembly to override the classes and add datagram support. There may be name conflicts when the official API becomes public in .NET 7.
The current QPACK handling seems incomplete. I hard-coded new byte[] { 1, 0x1F, 0, 0, 0xD9, 0x2F, 0x0D, 0x41, 0x48, 0xB7, 0x82, 0xC6, 0x9B, 0x07, 0x52, 0x2B, 0x3D, 0x89, 0x5A, 0x74, 0xA6, 0xB6, 0x56, 0x92, 0xC1, 0xCA, 0x9F, 0x85, 0x92, 0xC1, 0xCA, 0x90, 0x0B } to the request stream in response to the CONNECT request for :status 200 and sec-webtransport-http3-draft draft02 regardless of which draft versions are being negotiated by the user agent.
@unicomp21 I don't have the necessary expertise at the .NET layer to provide useful guidance, but ideally the best way forward would likely be to work with the .NET devs to add the functionality you need directly to .NET.
WebTransport is making great progress, but it's very unlikely SignalR will be able to make use of it in the short time left for 7.0. Moving to .NET 8 Planning.
An update on WebTransport status in .NET 7: https://devblogs.microsoft.com/dotnet/experimental-webtransport-over-http-3-support-in-kestrel/
Thx!
On Mon, Nov 14, 2022 at 5:12 PM Aditya Mandaleeka @.***> wrote:
An update on WebTransport status in .NET 7: https://devblogs.microsoft.com/dotnet/experimental-webtransport-over-http-3-support-in-kestrel/
— Reply to this email directly, view it on GitHub https://github.com/dotnet/aspnetcore/issues/39583#issuecomment-1314529378, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFL7M6JMVFT4DQI7X2EO3WILBOLANCNFSM5MFHAGSQ . You are receiving this because you were mentioned.Message ID: @.***>
.NET 8 is done, and the webtransport spec is still in draft mode. No updates.
No, webtransport is still in draft mode. And even if it wasn't, this would require a massive amount of work to "properly" make use of webtransport in SignalR.
There is the simpler approach of just adding it as another transport that works exactly like the other transports, but this wouldn't make use of webtransport streams, which is a great feature webtransport provides that we should make use of. e.g. Streaming hub methods on a separate stream.