What is Kestrel (vs IIS / Express)

I'd like to offer an alternative answer, with some history, so that you might understand why Kestrel comes, even if you only use Windows and IIS.

At the very beginning of ASP.NET development before year 2000, clearly Microsoft created two pieces to host ASP.NET WebForms apps,

• Cassini, later became ASP.NET Development Server in Visual Studio. It is a fully managed web server written in C# based on HttpListener. Of course, since it was for development only, many features were never implemented. As Microsoft made the source code of Cassini available for the public, there are third parties who forked the code base and added more features, which started the Cassini family.
• ASP.NET support on IIS (revision 1). Because IIS was 4.0 and 5.0/5.1 at that time, which has nothing like application pools, ASP.NET even has its own worker process (aspnet_wp.exe).

So to develop a web app, you use Cassini, and to deploy you use IIS.

• The introduction of application pools in IIS 6 required some changes on ASP.NET side, so aspnet_wp.exe became obsolete and replaced by aspnet_isapi.dll. That can be seen as ASP.NET support on IIS revision 2. So ASP.NET apps are being hosted in IIS worker processes w3wp.exe.

• The introduction of integrated pipeline in IIS 7 and above required further changes, which replaced aspnet_isapi.dll with webengine4.dll. That can be seen as ASP.NET support on IIS revision 3. ASP.NET and IIS pipelines are unified.

You can see ASP.NET has become much more complex and tightly integrated with IIS, so Cassini started to show its age, and gradually was replaced by IIS Express (a user mode lite IIS).

Thus, in many cases, when people blame that IIS is slow, they should blame ASP.NET in fact. IIS itself without ASP.NET is pretty fast and stable, while ASP.NET was not developed with enough performance metrics in mind (as WebForms focuses quite a lot of productivities and RAD).

Then in November 2014, ASP.NET 5 (later renamed to ASP.NET Core) was announced and became a cross platform technology. Obviously Microsoft needed a new design to support Windows, macOS, and Linux, where all major web servers, nginx/Apache (or other web servers) should be considered besides IIS.

I think many would agree that Microsoft learned quite a lot from NodeJS, and then designed and developed Kestrel (based on libuv initially but might move to other technology soon). It is a light-weight web server like Cassini initially, but later more features are being added (like another answer commented, much more features so can be treated as a full web server). Though fully managed (some native dependencies exist), it is no longer a toy web server like Cassini.

Then why cannot you just use Kestrel? Why IIS Express and potentially IIS, nginx, or Apache are still needed? That primarily is a result of today's internet practice. Most web sites use reverse proxies to take requests from your web browsers and then forward to the application servers in the background.

• IIS Express/IIS/nginx/Apache are the reverse proxy servers
• Kestrel/NodeJS/Tomcat and so on are the application servers

Another answer already showed a link to Microsoft documentation, so you can take a look.

Microsoft developed HttpPlatformHandler initially to make IIS a good enough reverse proxy for Java/Python and so on, so planned to use it for ASP.NET Core. Issues started to appear during development, so later Microsoft made ASP.NET Core Module specifically for ASP.NET Core. That's ASP.NET support on IIS revision 4.

Starting from ASP.NET Core 2.2, ASP.NET Core Module for IIS (version 2) can host .NET Core environment inside IIS worker process (w3wp.exe), quite similar to ASP.NET 2.x/4.x. This mode is called "IIS in-process hosting". It can be considered as ASP.NET support on IIS revision 5.

Well, quite lengthy, but I hope I put all necessary pieces together and you enjoy reading it.

1. Multiple apps on the same port is not supported in Kestrel.
2. Windows Authentication does not exist on Kestrel.
3. Request Filtering is much more fully featured in IIS.
4. Mime Type Mapping is much better in IIS.
5. HTTP access logs aren’t collected in Kestrel.

What is Kestrel

It's a full blown web server. You can run your ASP.NET Core application using just Kestrel.

But when I run my website, I still get the IIS Express icon in the system tray

In your ASP.NET application, probably in the wwwroot directory, you'll see a web.config that contains this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
    <handlers>
    <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/>
    </handlers>
    <httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogEnabled="false" startupTimeLimit="3600"/>
</system.webServer>
</configuration>

This is the HttpPlatformHandler. Essentially, what this does is forward all requests to Kestrel. IIS Express (and IIS for that matter) will not run ASP.NET themselves anymore. Instead, they will act as proxies that simply pass requests and responses back and forth from Kestrel. There is still advantages of using IIS, specifically it gives you security configuration, kernel-level caching, etc.

From ms docs at: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?tabs=aspnetcore2x

Kestrel is a cross-platform web server for ASP.NET Core based on libuv, a cross-platform asynchronous I/O library. Kestrel is the web server that is included by default in ASP.NET Core project templates.

You can use Kestrel by itself or with a reverse proxy server, such as IIS, Nginx, or Apache. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel after some preliminary handling.

---

UPDATE: .net core 2.1, Kestrel uses managed sockets instead of libuv

From asp.net core 2.1 docs at: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1#transport-configuration

With the release of ASP.NET Core 2.1, Kestrel's default transport is no longer based on Libuv but instead based on managed sockets.