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
35.2k stars 9.95k forks source link

Consider increasing stream limits defaults for HTTP/3 #41831

Open ManickaP opened 2 years ago

ManickaP commented 2 years ago

Is there an existing issue for this?

Is your feature request related to a problem? Please describe the problem.

I already opened this idea with @JamesNK. We should also consider whether this change might have negative impact on contention and whether it might have security implication. I tested some of the externally available H/3 servers (the numbers are give or take): Server Bidi Unidi
https://quic.nginx.org/ 128 3
https://cloudflare-quic.com/ 256 3
https://www.litespeedtech.com/ 100 3
https://quic.tech:8443/ 100 100
https://quic.aiortc.org:443/ 128, 256, 512 128, 256, 512
https://h2o.examp1e.net/ 100 10
https://msquic.net 100 3

This idea comes mainly from @nibanks suggestion to use a single connection and many streams for the best perf results.

cc: @CarnaViire @wfurt @rzikm

Describe the solution you'd like

I'm opening this to start a discussion. This might also just lead to only a docs change recommending increasing stream limits for high perf scenarios.

Additional context

HttpClient supports only single H/3 connection at the moment. Issue to support more has been already filed: https://github.com/dotnet/runtime/issues/51775

wfurt commented 2 years ago

what is our current default?

ManickaP commented 2 years ago

what is our current default?

bi=100 uni=10 https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Transport.Quic/src/QuicTransportOptions.cs

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.