Web server implementations in ASP.NET Core
By Tom Dykstra, Steve Smith, Stephen Halter, and Chris Ross
An ASP.NET Core application runs with an in-process HTTP server implementation. The server implementation listens for HTTP requests and surfaces them to the application as sets of request features composed into an HttpContext.
ASP.NET Core ships two server implementations:
ASP.NET Core 2.x
Kestrel is a cross-platform HTTP server based on libuv, a cross-platform asynchronous I/O library.
HTTP.sys is a Windows-only HTTP server based on the Http.Sys kernel driver.
ASP.NET Core 1.x
Kestrel is a cross-platform HTTP server based on libuv, a cross-platform asynchronous I/O library.
WebListener is a Windows-only HTTP server based on the Http.Sys kernel driver.
Kestrel
Kestrel is the web server that is included by default in ASP.NET Core new-project templates.
ASP.NET Core 2.x
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.
Either configuration — with or without a reverse proxy server — can also be used if Kestrel is exposed only to an internal network.
For information about when to use Kestrel with a reverse proxy, see Introduction to Kestrel.
ASP.NET Core 1.x
If your application accepts requests only from an internal network, you can use Kestrel by itself.
If you expose your application to the Internet, you must use IIS, Nginx, or Apache as a reverse proxy server. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel after some preliminary handling, as shown in the following diagram.
The most important reason for using a reverse proxy for edge deployments (exposed to traffic from the Internet) is security. The 1.x versions of Kestrel don’t have a full complement of defenses against attacks. This includes, but isn’t limited to, appropriate timeouts, size limits, and concurrent connection limits.
For information about when to use Kestrel with a reverse proxy, see Introduction to Kestrel.
You can’t use IIS, Nginx, or Apache without Kestrel or a custom server implementation. ASP.NET Core was designed to run in its own process so that it can behave consistently across platforms. IIS, Nginx, and Apache dictate their own startup process and environment; to use them directly, ASP.NET Core would have to adapt to the needs of each one. Using a web server implementation such as Kestrel gives ASP.NET Core control over the startup process and environment. So rather than trying to adapt ASP.NET Core to IIS, Nginx, or Apache, you just set up those web servers to proxy requests to Kestrel. This arrangement allows your Program.Main and Startup classes to be essentially the same no matter where you deploy.
IIS with Kestrel
When you use IIS or IIS Express as a reverse proxy for ASP.NET Core, the ASP.NET Core application runs in a process separate from the IIS worker process. In the IIS process, a special IIS module runs to coordinate the reverse proxy relationship. This is the ASP.NET Core Module. The primary functions of the ASP.NET Core Module are to start the ASP.NET Core application, restart it when it crashes, and forward HTTP traffic to it. For more information, see ASP.NET Core Module.
Nginx with Kestrel
For information about how to use Nginx on Linux as a reverse proxy server for Kestrel, see Publish to a Linux Production Environment.
Apache with Kestrel
For information about how to use Apache on Linux as a reverse proxy server for Kestrel, see Using Apache Web Server as a reverse proxy.
HTTP.sys
ASP.NET Core 2.x
If you run your ASP.NET Core app on Windows, HTTP.sys is an alternative to Kestrel. You can use HTTP.sys for scenarios where you expose your app to the Internet and you need HTTP.sys features that Kestrel doesn’t support.
HTTP.sys can also be used for applications that are exposed only to an internal network.
For internal network scenarios, Kestrel is generally recommended for best performance; but in some scenarios, you might want to use a feature that only HTTP.sys offers. For information about HTTP.sys features, see HTTP.sys.
ASP.NET Core 1.x
HTTP.sys is named WebListener in ASP.NET Core 1.x. If you run your ASP.NET Core app on Windows, WebListener is an alternative that you can use for scenarios where you want to expose your app to the Internet but you can’t use IIS.
WebListener can also be used in place of Kestrel for applications that are exposed only to an internal network, if you need WebListener features that Kestrel doesn’t support.
For internal network scenarios, Kestrel is generally recommended for best performance, but in some scenarios you might want to use a feature that only WebListener offers. For information about WebListener features, see WebListener.
Notes about ASP.NET Core server infrastructure
The IApplicationBuilder available in the Startup class Configure method exposes the ServerFeatures property of type IFeatureCollection. Kestrel and WebListener both expose only a single feature, IServerAddressesFeature, but different server implementations may expose additional functionality.
IServerAddressesFeature can be used to find out which port the server implementation has bound to at runtime.
Custom servers
If the built-in servers don’t meet your needs, you can create a custom server implementation. The Open Web Interface for .NET (OWIN) guide demonstrates how to write a Nowin-based IServer implementation. You’re free to implement just the feature interfaces your application needs, though at a minimum you must support IHttpRequestFeature and IHttpResponseFeature.
Next steps
For more information, see the following resources:
ASP.NET Core 2.x
ASP.NET Core 1.x
)
|
|