search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
34.82k stars 9.84k forks source link

SignalR support for webtransport #39583

Open unicomp21 opened 2 years ago

unicomp21 commented 2 years ago

Is there an existing issue for this?

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

javiercn commented 2 years ago

@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.

unicomp21 commented 2 years ago

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.

nibanks commented 2 years ago

@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.

unicomp21 commented 2 years ago

https://developer.chrome.com/blog/new-in-chrome-97/#webtransport

I'm guessing this means Edge, which is based on chromium? Will follow shortly?

nibanks commented 2 years ago

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.

javiercn commented 2 years ago

@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.

unicomp21 commented 2 years ago

@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.

unicomp21 commented 2 years ago

I renamed the issue "Blazor" -> "Aspnet".

campersau commented 2 years ago

See also https://github.com/dotnet/aspnetcore/issues/12040

adityamandaleeka commented 2 years ago

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.

Tratcher commented 2 years ago

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.

unicomp21 commented 2 years ago

@nibanks ^

nibanks commented 2 years ago

@unicomp21 that's a job for the .NET HTTP/3 folks, not MsQuic 😄

unicomp21 commented 2 years ago

Lol, so many new layers, I get confused! 😄

ghost commented 2 years ago

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.

wegylexy commented 2 years ago

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.

unicomp21 commented 2 years ago

@wegylexy does anything prevent us from simply forking the repo?

unicomp21 commented 2 years ago

@nibanks if we forked .net http/3 stack to make the webtransport changes, what are the downsides?

wegylexy commented 2 years ago

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.

nibanks commented 2 years ago

@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.

BrennanConroy commented 2 years ago

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.

adityamandaleeka commented 1 year ago

An update on WebTransport status in .NET 7: https://devblogs.microsoft.com/dotnet/experimental-webtransport-over-http-3-support-in-kestrel/

unicomp21 commented 1 year ago

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: @.***>

JohnGalt1717 commented 8 months ago

Any updates on this for .net 8?

BrennanConroy commented 8 months ago

.NET 8 is done, and the webtransport spec is still in draft mode. No updates.

wave9d commented 1 month ago

Any updates on this ?

BrennanConroy commented 1 month ago

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.