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?
The main difference between IIS and Kestrel is that Kestrel is a cross-platform server. It runs on Linux, Windows, and Mac, whereas IIS is Windows-specific. Another essential difference between the two is that Kestrel is fully open-source, whereas IIS is closed-source and developed and maintained only by Microsoft.
The ASP.NET Core Module is a native IIS module that handles native IIS requests between IIS and the in-process IIS HTTP Server or Kestrel.
Kestrel can be used by itself or with a reverse proxy server. A reverse proxy server receives HTTP requests from the network and forwards them to Kestrel. Examples of a reverse proxy server include: Internet Information Services (IIS)
According to this post with benchmarks, IIS consistently outperforms nginx in speed. Specifically, IIS uses 2.3x less CPU power than nginx, processes more than double the requests, and responds in less than half the time.
@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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With