Webserverimplementierungen in ASP.NET Core

  • Artikel

Von Tom Dykstra, Steve Smith, Stephen Halter und Chris Ross

Eine ASP.NET Core-App wird über eine In-Process-Implementierung eines HTTP-Servers ausgeführt. Die Serverimplementierung lauscht auf HTTP-Anforderungen und leitet diese als Anforderungsfunktionen, die in einer HttpContext-Klasse zusammengefasst werden, an die App weiter.

ASP.NET Core wird mit folgendem Umfang ausgeliefert:

Wenn Sie IIS oder IIS Express verwenden, wird die App auf zwei unterschiedliche Arten ausgeführt:

Das ASP.NET Core-Modul ist ein natives IIS-Modul, das native IIS-Anforderungen zwischen IIS und dem In-Process-IIS-HTTP-Server oder Kestrel verarbeitet. Weitere Informationen finden Sie im Artikel ASP.NET Core-Modul (ANCM) für IIS:

Kestrel im Vergleich zu HTTP.sys

Kestrel bietet die folgenden Vorteile gegenüber HTTP.sys:

  • Bessere Leistung und Arbeitsspeicherauslastung
  • Plattformübergreifend
  • Agilität: Entwicklung und Patchen unabhängig vom Betriebssystem
  • Programmgesteuerte Port- und TLS-Konfiguration
  • Erweiterbarkeit mit Möglichkeit für Protokolle wie PPv2 und alternative Transporte

HTTP.sys fungiert als freigegebene Kernelmoduskomponente mit den folgenden Features, die Kestrel nicht besitzt:

Hostingmodelle

Es stehen mehrere Hostingmodelle zur Verfügung:

  • Kestrel-Selbsthosting: Der Kestrel-Webserver wird ausgeführt, ohne dass ein anderer externer Webserver wie IIS oder HTTP.sys erforderlich ist.

  • Das HTTP.sys-Selbsthosting ist eine Alternative zu Kestrel. Kestrel ist HTTP.sys vorzuziehen, es sei denn, die App benötigt Features, die in Kestrel nicht verfügbar sind.

  • IIS-In-Process-Hosting: Eine ASP.NET Core-App wird im gleichen Prozess wie ihr IIS-Workerprozess ausgeführt. Durch das IIS-In-Process-Hosting wird die Leistung des IIS-Out-of-Process-Hosting verbessert, da Anforderungen nicht per Proxy über den Loopbackadapter weitergeleitet werden. Dabei handelt es sich um eine Netzwerkschnittstelle, die ausgehenden Netzwerkdatenverkehr zum selben Computer zurück leitet. IIS erledigt das Prozessmanagement mit dem Windows-Prozessaktivierungsdienst (Process Activation Service, WAS).

  • IIS-Out-of-Process-Hosting: ASP.NET Core-Apps werden in einem Prozess getrennt vom IIS-Workerprozess ausgeführt, und das Modul führt die Prozessverwaltung durch. Das Modul startet den Prozess für die ASP.NET Core-App, wenn die erste Anforderung eingeht und startet die App neu, wenn sie heruntergefahren wird oder abstürzt. Dies ist im Prinzip das gleiche Verhalten wie bei Apps, die prozessintern ausgeführt und durch den Windows-Prozessaktivierungsdienst (WAS) verwaltet werden. Die Verwendung eines separaten Prozesses ermöglicht auch das Hosten von mehr als einer App aus demselben App-Pool.

Weitere Informationen finden Sie unter

Kestrel

Ein Kestrel-Server ist die plattformübergreifende Standardimplementierung von HTTP-Servern. Kestrel bietet die beste Leistung und Arbeitsspeicherauslastung, verfügt jedoch nicht über einige erweiterte Features in HTTP.sys. Weitere Informationen finden Sie unter Kestrel im Vergleich zu HTTP.sys in diesem Dokument.

Verwenden Sie Kestrel:

  • Eigenständig als Edge-Server zur Verarbeitung von Anforderungen, die direkt aus einem Netzwerk, auch über das Internet, kommen.

    Kestrel communicates directly with the Internet without a reverse proxy server

  • Mit einem Reverseproxyserver wie IIS (Internetinformationsdienste), Nginx oder Apache. Ein Reverseproxyserver empfängt HTTP-Anforderungen aus dem Internet und leitet diese an Kestrel weiter.

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

Beide Hostingkonfigurationen (mit oder ohne Reverseproxyserver) werden unterstützt.

Leitfäden zur Kestrel-Konfiguration und Informationen darüber, wann Kestrel in einer Reverseproxykonfiguration verwendet wird, finden Sie unter Kestrel-Webserver in ASP.NET Core.

ASP.NET Core wird mit folgendem Umfang ausgeliefert:

Wenn Sie IIS oder IIS Express verwenden, wird die App in einem anderen Prozess als dem IIS-Workerprozess (Out-of-Process) mit dem Kestrel-Server ausgeführt.

Da ASP.NET Core-Apps in einem Prozess getrennt vom IIS-Arbeitsprozess ausgeführt werden, führt das Modul die Prozessverwaltung durch. Das Modul startet den Prozess für die ASP.NET Core-App, wenn die erste Anforderung eingeht und startet die App neu, wenn sie heruntergefahren wird oder abstürzt. Dies ist im Prinzip das gleiche Verhalten wie bei Apps, die prozessintern ausgeführt und durch den Windows-Prozessaktivierungsdienst (WAS) verwaltet werden.

Das folgende Diagramm zeigt die Beziehung zwischen IIS, dem ASP.NET Core-Modul und einer Out-of-Process gehosteten App:

ASP.NET Core Module

Anforderungen gehen aus dem Internet an den Treiber „HTTP.sys“ ein, der im Kernelmodus betrieben wird. Der Treiber leitet die Anforderungen an IIS auf dem konfigurierten Port der Webseite weiter, normalerweise 80 (HTTP) oder 443 (HTTPS). Das Modul leitet die Anforderung über einen zufälligen Port für die App an Kestrel weiter, bei dem es sich nicht um Port 80 oder 443 handelt.

Das Modul gibt den Port über die Umgebungsvariable beim Start an. Die Middleware für die Integration von IIS konfiguriert den Server so, dass er auf http://localhost:{port} lauscht. Zusätzliche Überprüfungen werden durchgeführt. Anforderungen, die nicht vom Modul stammen, werden abgelehnt. Das Modul unterstützt die HTTPS-Weiterleitung nicht. Deshalb werden Anforderungen über HTTP weitergeleitet, selbst wenn sie von IIS über HTTPS empfangen wurden.

Nachdem Kestrel die Anforderung vom Modul empfangen hat, wird die Anforderung per Push an die Middlewarepipeline von ASP.NET Core weitergeleitet. Die Middleware-Pipeline behandelt die Anforderung und gibt sie als HttpContext-Instanz an die App-Logik weiter. Die durch die IIS-Integration hinzugefügte Middleware aktualisiert das Schema, die Remote-IP und die Pfadbasis, um die Anforderung an Kestrel weiterzuleiten. Die Antwort der App wird dann an IIS zurückgegeben, wo sie per Push an den HTTP-Client zurückgegeben wird, der die Anforderung initiiert hat.

In den folgenden Artikeln finden Sie Konfigurationsrichtlinien für IIS und ein ASP.NET Core-Modul:

Nginx mit Kestrel

Informationen dazu, wie Nginx unter Linux als Reverseproxyserver für Kestrel verwendet wird, finden Sie unter Hosten unter Linux mit Nginx.

Apache mit Kestrel

Informationen dazu, wie Apache unter Linux als Reverseproxyserver für Kestrel verwendet wird, finden Sie unter Hosten unter Linux mit Apache.

HTTP.sys

Wenn ASP.NET Core-Apps unter Windows ausgeführt werden, ist HTTP.sys eine Alternative zu Kestrel. Kestrel ist HTTP.sys vorzuziehen, es sei denn, die App benötigt Features, die in Kestrel nicht verfügbar sind. Weitere Informationen finden Sie unter HTTP.sys web server implementation in ASP.NET Core (HTTP.sys-Webserverimplementierung in ASP.NET Core).

HTTP.sys communicates directly with the Internet

Außerdem kann HTTP.sys auch bei Apss zum Einsatz kommen, die nur in einem internen Netzwerk verfügbar gemacht werden.

HTTP.sys communicates directly with the internal network

Eine Anleitung zur Konfiguration von HTTP.sys finden Sie unter Implementierung des HTTP.sys-Webservers in ASP.NET Core.

ASP.NET Core-Serverinfrastruktur

Die Schnittstelle IApplicationBuilder, die in der Startup.Configure-Methode vorhanden ist, macht die Eigenschaft ServerFeatures vom Typ IFeatureCollection verfügbar. Kestrel und HTTP.sys machen nur jeweils eine einzige Funktion verfügbar: IServerAddressesFeature. Andere Serverimplementierungen machen jedoch möglicherweise weitere Funktionalitäten verfügbar.

Mit IServerAddressesFeature kann ermittelt werden, an welchen Port die Serverimplementierung zur Laufzeit gebunden ist.

Benutzerdefinierte Server

Wenn die integrierten Server nicht den Anforderungen der App entsprechen, kann eine benutzerdefinierte Serverimplementierung erstellt werden. In der Anleitung zu Open Web Interface for .NET (OWIN) wird erläutert, wie eine auf Nowin basierende IServer-Implementierung erstellt wird. Nur die Schnittstellen von Funktionen, die von der App verwendet werden, erfordern Implementierung, wobei mindestens IHttpRequestFeature und IHttpResponseFeature unterstützt werden müssen.

Serverstart

Der Server wird gestartet, wenn die integrierte Entwicklungsumgebung (IDE) oder der Editor die App startet:

Wird die App über eine Eingabeaufforderung im Ordner des Projekts gestartet, startet dotnet run die App und den Server (nur Kestrel und HTTP.sys). Die Konfiguration wird durch die Option -c|--configuration angegeben, die entweder auf Debug (Standardwert) oder Release festgelegt ist.

Eine launchSettings.json-Datei bietet Konfiguration während des App-Starts mit dotnet run oder mit einem in Tools integrierten Debugger, z. B. Visual Studio. Sind in der Datei launchSettings.json Startprofile enthalten, verwenden Sie die Option --launch-profile {PROFILE NAME} mit dem Befehl dotnet run, oder wählen Sie das Profil in Visual Studio aus. Weitere Informationen hierzu finden Sie unter dotnet run und unter Verpacken einer Verteilung von .NET Core.

HTTP/2-Unterstützung

HTTP/2 wird mit ASP.NET Core in den folgenden Bereitstellungsszenarien unterstützt:

  • Kestrel
    • Betriebssystem
      • Windows Server 2016/Windows 10 oder höher†
      • Linux mit OpenSSL 1.0.2 oder höher (z.B. Ubuntu 16.04 oder höher)
      • macOS 10.15 oder höher
    • Zielframework: .NET Core 2.2 oder höher
  • HTTP.sys
    • Windows Server 2016/Windows 10 oder höher
    • Zielframework: Gilt nicht für HTTP.sys-Bereitstellungen.
  • IIS (In-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Zielframework: .NET Core 2.2 oder höher
  • IIS (Out-of-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Öffentlich zugängliche Edgeserververbindungen verwenden HTTP/2, aber die Reverseproxyverbindung mit Kestrel verwendet HTTP/1.1.
    • Zielframework: Gilt nicht für Out-of-Process-Bereitstellungen von IIS.

†Kestrel bietet eingeschränkte Unterstützung für HTTP/2 unter Windows Server 2012 R2 und Windows 8.1. Die Unterstützung ist eingeschränkt, weil die Liste der unterstützten TLS-Verschlüsselungssammlungen unter diesen Betriebssystemen begrenzt ist. Zum Sichern von TLS-Verbindungen ist möglicherweise ein durch einen Elliptic Curve Digital Signature Algorithm (ECDSA) generiertes Zertifikat erforderlich.

  • Kestrel
    • Betriebssystem
      • Windows Server 2016/Windows 10 oder höher†
      • Linux mit OpenSSL 1.0.2 oder höher (z.B. Ubuntu 16.04 oder höher)
      • HTTP/2 wird unter macOS in einem zukünftigen Release unterstützt.
    • Zielframework: .NET Core 2.2 oder höher
  • HTTP.sys
    • Windows Server 2016/Windows 10 oder höher
    • Zielframework: Gilt nicht für HTTP.sys-Bereitstellungen.
  • IIS (In-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Zielframework: .NET Core 2.2 oder höher
  • IIS (Out-of-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Öffentlich zugängliche Edgeserververbindungen verwenden HTTP/2, aber die Reverseproxyverbindung mit Kestrel verwendet HTTP/1.1.
    • Zielframework: Gilt nicht für Out-of-Process-Bereitstellungen von IIS.

†Kestrel bietet eingeschränkte Unterstützung für HTTP/2 unter Windows Server 2012 R2 und Windows 8.1. Die Unterstützung ist eingeschränkt, weil die Liste der unterstützten TLS-Verschlüsselungssammlungen unter diesen Betriebssystemen begrenzt ist. Zum Sichern von TLS-Verbindungen ist möglicherweise ein durch einen Elliptic Curve Digital Signature Algorithm (ECDSA) generiertes Zertifikat erforderlich.

  • Kestrel
    • Betriebssystem
      • Windows Server 2016/Windows 10 oder höher†
      • Linux mit OpenSSL 1.0.2 oder höher (z.B. Ubuntu 16.04 oder höher)
      • HTTP/2 wird unter macOS in einem zukünftigen Release unterstützt.
    • Zielframework: .NET Core 2.2 oder höher
  • HTTP.sys
    • Windows Server 2016/Windows 10 oder höher
    • Zielframework: Gilt nicht für HTTP.sys-Bereitstellungen.
  • IIS (In-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Zielframework: .NET Core 2.2 oder höher
  • IIS (Out-of-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Öffentlich zugängliche Edgeserververbindungen verwenden HTTP/2, aber die Reverseproxyverbindung mit Kestrel verwendet HTTP/1.1.
    • Zielframework: Gilt nicht für Out-of-Process-Bereitstellungen von IIS.

†Kestrel bietet eingeschränkte Unterstützung für HTTP/2 unter Windows Server 2012 R2 und Windows 8.1. Die Unterstützung ist eingeschränkt, weil die Liste der unterstützten TLS-Verschlüsselungssammlungen unter diesen Betriebssystemen begrenzt ist. Zum Sichern von TLS-Verbindungen ist möglicherweise ein durch einen Elliptic Curve Digital Signature Algorithm (ECDSA) generiertes Zertifikat erforderlich.

  • HTTP.sys
    • Windows Server 2016/Windows 10 oder höher
    • Zielframework: Gilt nicht für HTTP.sys-Bereitstellungen.
  • IIS (Out-of-Process)
    • Windows Server 2016/Windows 10 oder höher, IIS 10 oder höher
    • Öffentlich zugängliche Edgeserververbindungen verwenden HTTP/2, aber die Reverseproxyverbindung mit Kestrel verwendet HTTP/1.1.
    • Zielframework: Gilt nicht für Out-of-Process-Bereitstellungen von IIS.

Eine HTTP/2-Verbindung muss ALPN (Application-Layer Protocol Negotiation) und TLS 1.2 oder höher verwenden. Weitere Informationen finden Sie in den Themen, die Ihre Serverbereitstellungsszenarien betreffen.

Zusätzliche Ressourcen