Reduce the size cost of unused protocol support

[adityamandaleeka]

We know there are use cases for Kestrel where things like HTTP/2 or /3, or even HTTPS, aren't necessary. For instance, you may not want HTTPS for a server that's run behind a TLS-terminated proxy.

Today, a published app that doesn't use TLS still carries around some extra dependencies that are used only for TLS support. We should explore what we can do to minimize this cost.

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.

[Tratcher]

Step 1: Measuring. Do we have a sense for how big each of these components might be?

[danmoseley]

I believe @eerhardt measured it for HTTPS

[eerhardt]

Here are the current published .exe size numbers for the dotnet new api -aot app using the Minimal API source generator:

Windows - 10.6 MB (11,178,496 bytes)
Linux - 13.5 MB (14,204,768 bytes)

Notice that Linux is ~30% bigger than Windows. This is because on Linux, in order to support HTTPS, we need to use System.Security.Cryptography. And in order for System.Security.Cryptography to validate certificates correctly, it needs to bring in the whole System.Net.Http.HttpClient stack. This isn't the case on Windows, because we use the OS crypto stack, and the .NET process doesn't need HttpClient.

Now, if I hack out HTTPS support using bffa15c, and publish the same app, the numbers drop to:

Windows - 8.97 MB (9,406,464 bytes)
Linux - 9.58 MB (10,049,136 bytes)

Now the difference in size is much smaller, only ~7%. This is because all of System.Security.Cryptography, and thus HttpClient is able to be trimmed. You can see that by analyzing the .mstat file produced by NativeAOT (following these instructions). When comparing the "current" (left size of below image) vs. the hack commit (right side), see all the larger namespaces that are removed:

You can even tell from this picture that HTTP2 and 3 code is still in the hacked app. We could get even smaller if we removed those as well, if we felt necessary.

[Leonardo-Ferreira]

I wonder how much performance we would get if we specialized the framework... like, you have a car and if get a flat, you're going to call AAA, but nevertheless you carry a jack, because one, "it came with the car" and two, "just in case you know"... but in the end of the day, your mileage/acceleration/tire-wear is worst because you are carrying that 25 pound thing...

kinda like the same way linux created ultra slimmed versions that enabled the virtualization revolution