Edit

Share via


Web server implementations in ASP.NET Core

Note

This isn't the latest version of this article. For the current release, see the .NET 9 version of this article.

Warning

This version of ASP.NET Core is no longer supported. For more information, see the .NET and .NET Core Support Policy. For the current release, see the .NET 9 version of this article.

Important

This information relates to a pre-release product that may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

For the current release, see the .NET 9 version of this article.

By Tom Dykstra, Steve Smith, Stephen Halter, and Chris Ross

An ASP.NET Core app runs with an in-process HTTP server implementation. The server implementation listens for HTTP requests and surfaces them to the app as a set of request features composed into an HttpContext.

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

Kestrel

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 this document.

Use Kestrel:

  • By itself as an edge server processing requests directly from a network, including the Internet.

    Kestrel communicates directly with the Internet without a reverse proxy server

  • With a reverse proxy server, such as Internet Information Services (IIS), Nginx, or Apache. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel.

    Kestrel communicates indirectly with the Internet through a reverse proxy server, such as IIS, Nginx, or Apache

Either hosting configuration—with or without a reverse proxy server—is supported.

For Kestrel configuration guidance and information on when to use Kestrel in a reverse proxy configuration, see Kestrel web server in ASP.NET Core.

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

Nginx with Kestrel

For information on how to use Nginx on Linux as a reverse proxy server for Kestrel, see Host ASP.NET Core on Linux with Nginx.

HTTP.sys

If ASP.NET Core apps are run on Windows, HTTP.sys is an alternative to Kestrel. Kestrel is recommended over HTTP.sys unless the app requires features not available in Kestrel. For more information, see HTTP.sys web server implementation in ASP.NET Core.

HTTP.sys communicates directly with the Internet

HTTP.sys can also be used for apps that are only exposed to an internal network.

HTTP.sys communicates directly with the internal network

For HTTP.sys configuration guidance, see HTTP.sys web server implementation in ASP.NET Core.

ASP.NET Core server infrastructure

The IApplicationBuilder available in the Startup.Configure method exposes the ServerFeatures property of type IFeatureCollection. Kestrel and HTTP.sys only expose a single feature each, IServerAddressesFeature, but different server implementations may expose additional functionality.

IServerAddressesFeature can be used to find out which port the server implementation has bound at runtime.

Custom servers

If the built-in servers don't meet the app's requirements, a custom server implementation can be created. The Open Web Interface for .NET (OWIN) guide demonstrates how to write a Nowin-based IServer implementation. Only the feature interfaces that the app uses require implementation, though at a minimum IHttpRequestFeature and IHttpResponseFeature must be supported.

Server startup

The server is launched when the Integrated Development Environment (IDE) or editor starts the app:

When launching the app from a command prompt in the project's folder, dotnet run launches the app and server (Kestrel and HTTP.sys only). The configuration is specified by the -c|--configuration option, which is set to either Debug (default) or Release.

A launchSettings.json file provides configuration when launching an app with dotnet run or with a debugger built into tooling, such as Visual Studio. If launch profiles are present in a launchSettings.json file, use the --launch-profile {PROFILE NAME} option with the dotnet run command or select the profile in Visual Studio. For more information, see dotnet run and .NET Core distribution packaging.

HTTP/2 support

HTTP/2 is supported with ASP.NET Core in the following deployment scenarios:

  • Kestrel
    • Operating system
      • Windows Server 2016/Windows 10 or later†
      • Linux with OpenSSL 1.0.2 or later (for example, Ubuntu 16.04 or later)
      • macOS 10.15 or later
    • Target framework: .NET Core 2.2 or later
  • HTTP.sys
    • Windows Server 2016/Windows 10 or later
    • Target framework: Not applicable to HTTP.sys deployments.
  • IIS (in-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Target framework: .NET Core 2.2 or later
  • IIS (out-of-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Public-facing edge server connections use HTTP/2, but the reverse proxy connection to Kestrel uses HTTP/1.1.
    • Target framework: Not applicable to IIS out-of-process deployments.

†Kestrel has limited support for HTTP/2 on Windows Server 2012 R2 and Windows 8.1. Support is limited because the list of supported TLS cipher suites available on these operating systems is limited. A certificate generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) may be required to secure TLS connections.

  • Kestrel
    • Operating system
      • Windows Server 2016/Windows 10 or later†
      • Linux with OpenSSL 1.0.2 or later (for example, Ubuntu 16.04 or later)
      • HTTP/2 will be supported on macOS in a future release.
    • Target framework: .NET Core 2.2 or later
  • HTTP.sys
    • Windows Server 2016/Windows 10 or later
    • Target framework: Not applicable to HTTP.sys deployments.
  • IIS (in-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Target framework: .NET Core 2.2 or later
  • IIS (out-of-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Public-facing edge server connections use HTTP/2, but the reverse proxy connection to Kestrel uses HTTP/1.1.
    • Target framework: Not applicable to IIS out-of-process deployments.

†Kestrel has limited support for HTTP/2 on Windows Server 2012 R2 and Windows 8.1. Support is limited because the list of supported TLS cipher suites available on these operating systems is limited. A certificate generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) may be required to secure TLS connections.

  • Kestrel
    • Operating system
      • Windows Server 2016/Windows 10 or later†
      • Linux with OpenSSL 1.0.2 or later (for example, Ubuntu 16.04 or later)
      • HTTP/2 will be supported on macOS in a future release.
    • Target framework: .NET Core 2.2 or later
  • HTTP.sys
    • Windows Server 2016/Windows 10 or later
    • Target framework: Not applicable to HTTP.sys deployments.
  • IIS (in-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Target framework: .NET Core 2.2 or later
  • IIS (out-of-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Public-facing edge server connections use HTTP/2, but the reverse proxy connection to Kestrel uses HTTP/1.1.
    • Target framework: Not applicable to IIS out-of-process deployments.

†Kestrel has limited support for HTTP/2 on Windows Server 2012 R2 and Windows 8.1. Support is limited because the list of supported TLS cipher suites available on these operating systems is limited. A certificate generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) may be required to secure TLS connections.

  • HTTP.sys
    • Windows Server 2016/Windows 10 or later
    • Target framework: Not applicable to HTTP.sys deployments.
  • IIS (out-of-process)
    • Windows Server 2016/Windows 10 or later; IIS 10 or later
    • Public-facing edge server connections use HTTP/2, but the reverse proxy connection to Kestrel uses HTTP/1.1.
    • Target framework: Not applicable to IIS out-of-process deployments.

An HTTP/2 connection must use Application-Layer Protocol Negotiation (ALPN) and TLS 1.2 or later. For more information, see the topics that pertain to your server deployment scenarios.

Additional resources