Kestrel vs IIS+Kestrel (reverse proxy) vs Nginx

Question

When I researched hosting of .NET core mechanism I saw this comment at lots of forums and website "Microsoft suggests always using any web server in front of Kestrel for websites." Why? Because of security problem? I suprised because if kestrel is used singly requests/sec performance is better than IIS+ Kestrel?

Pebbly

The evolution of Kestrel is so fast, that I start to doubt if we still need a reverse proxy if your only goal is to host ASP.NET Core apps. Note that Microsoft no longer says a reverse proxy is a must (learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/… "You can use Kestrel by itself or with a reverse proxy server"). Again, it really depends on your own choice. – Salomesalomi

Answer 1

@RickStrahl has written this nice post ASP.NET Core In Process Hosting on IIS with ASP.NET Core 2.2 which discusses InProcess hosting in IIS which is available with ASP.NET 2.2.

There he has also mentioned, why it's good to have a Web Server for in front of Kestrel.

In a nutshell, the built in Kestrel Web server in ASP.NET core is not meant to be an Internet facing Web server, but rather act as an application server or Edge Server that handles very specific data processing tasks. Kestrel is optimized for application scenarios, but it's not optimized for other things like static file serving or managing the server's lifetime

For this reason you generally do not want to run Kestrel directly in a Web application. This is true on Windows with IIS and also on Linux where you tend to use a Web server nginx or ha-proxy to handle non-application concerns. I wrote about how to set up IIS rewrite rules to route common static files rather than letting Kestrel handle them. This is not only about speed but it lets your Web application focus on doing the dynamic things that it's designed to do, letting IIS do the work it was designed for.

Here are a few of many arguments on why you want to use a full Web Server rather than running your application directly connected to the Web:

• Port Sharing Kestrel currently can't do port sharing in the same way that IIS and http.sys can do on Windows. Currently that functionality is supported only through IIS on Windows. (AFAIK you can't even using the HttpSys Server to do this). Additionally although it's possible to use host header routing in ASP.NET Core, it's not exactly easy or maintainable to set this up currently.

• Lifetime Management If you run your app without any support infrastructure any crash or failure will shut down the application and take your site offline. No matter what, you need some sort of host monitor to ensure your app continues to run if it fails and IIS provides that out of the box. ASP.NET Core with the ASP.NET Core Module benefits directly by being able to restart application pools that can relaunch your application on failures.

• Static File Serving Kestrel is not very good with static file handling currently and compared to IIS's optimized static file caching and compression infrastructure, Kestrel is comparitively slow. IIS takes full advantage of Kernel mode caching, and built in compression infrastructure that is much more efficient than today's ASP.NET StaticFile handler (".UseStaticFiles()").

There are additional reasons: Security and server hardening, administration features, managing SSL certificates, full logging and Http Request tracing facilities and the list goes on. All good reasons to sit behind a dedicated Web server platform rather than running and managing a self-hosted server instance.

Santoyo

Could you explain what do you mean by support infrastructure? – Embry