Web server implementations in ASP.NET Core

ASP.NET Core ships with the following:

• Kestrel server is the default, cross-platform HTTP server implementation. Kestrel provides the best performance and memory utilization, but it doesn't have some of the advanced features in HTTP.sys. For more information, see Kestrel vs. HTTP.sys in the Windows tab.
• IIS HTTP Server is an in-process server for IIS.
• HTTP.sys server is a Windows-only HTTP server based on the HTTP.sys kernel driver and HTTP Server API.

When using IIS or IIS Express, the app either runs:

• In the same process as the IIS worker process (the in-process hosting model) with the IIS HTTP Server. In-process is the recommended configuration.
• In a process separate from the IIS worker process (the out-of-process hosting model) with the Kestrel server.

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. For more information, see ASP.NET Core Module (ANCM) for IIS.

Kestrel vs. HTTP.sys

Kestrel has the following advantages over HTTP.sys:

• Better performance and memory utilization.
• Cross platform
• Agility, it's developed and patched independent of the OS.
• Programmatic port and TLS configuration
• Extensibility that allows for protocols like PPv2 and alternate transports.

Http.Sys operates as a shared kernel mode component with the following features that kestrel does not have:

• Port sharing
• Kernel mode windows authentication. Kestrel supports only user-mode authentication.
• Fast proxying via queue transfers
• Direct file transmission
• Response caching

Hosting models

Several hosting models are available:

• Kestrel self-hosting: The Kestrel web server runs without requiring any other external web server such as IIS or HTTP.sys.

• HTTP.sys self-hosting is an alternative to Kestrel. Kestrel is recommended over HTTP.sys unless the app requires features not available in Kestrel.

• IIS in-process hosting: An ASP.NET Core app runs in the same process as its IIS worker process. IIS in-process hosting provides improved performance over IIS out-of-process hosting because requests aren't proxied over the loopback adapter, a network interface that returns outgoing network traffic back to the same machine. IIS handles process management with the Windows Process Activation Service (WAS).

• IIS out-of-process hosting: ASP.NET Core apps run in a process separate from the IIS worker process, and the module handles process management. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS). Using a separate process also enables hosting more than one app from the same app pool.

For more information, see the following:

• Kestrel vs. HTTP.sys
• Host ASP.NET Core on Windows with IIS
• ASP.NET Core Module (ANCM) for IIS

ASP.NET Core ships with Kestrel server, which is the default, cross-platform HTTP server.

ASP.NET Core ships with Kestrel server, which is the default, cross-platform HTTP server.

ASP.NET Core ships with the following:

• Kestrel server is the default, cross-platform HTTP server.
• HTTP.sys server is a Windows-only HTTP server based on the HTTP.sys kernel driver and HTTP Server API.

When using IIS or IIS Express, the app runs in a process separate from the IIS worker process (out-of-process) with the Kestrel server.

Because ASP.NET Core apps run in a process separate from the IIS worker process, the module handles process management. The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS).

The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:

Requests arrive from the web to the kernel-mode HTTP.sys driver. The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443.

The module specifies the port via an environment variable at startup, and the IIS Integration Middleware configures the server to listen on http://localhost:{port}. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS.

After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. The middleware pipeline handles the request and passes it on as an HttpContext instance to the app's logic. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request.

For IIS and ASP.NET Core Module configuration guidance, see the following topics:

• Host ASP.NET Core on Windows with IIS
• ASP.NET Core Module (ANCM) for IIS

ASP.NET Core ships with Kestrel server, which is the default, cross-platform HTTP server.

ASP.NET Core ships with Kestrel server, which is the default, cross-platform HTTP server.