SignalR support for webtransport

[unicomp21]

Is there an existing issue for this?

• 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

[javiercn]

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

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]

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

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]

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]

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

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

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

[campersau]

See also #12040