Webserverimplementierungen in ASP.NET Core

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.

Windows

ASP.NET Core wird mit folgendem Umfang ausgeliefert:

• 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 Vergleich: Kestrel und HTTP.sys auf der Registerkarte „Windows“.
• IIS-HTTP-Server ist ein In-Process-Server für IIS.
• HTTP.sys Server ist ein nur für Windows verfügbarer HTTP-Server, der auf dem Http.sys-Kerneltreiber und der HTTP Server API basiert.

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

• Im gleichen Prozess wie im IIS-Workerprozess (das In-Process-Hostingmodell) mit dem IIS-HTTP-Server. In-Process ist die empfohlene Konfiguration.
• In einem anderen Prozess als dem IIS-Workerprozess (Out-of-Process-Hostingmodell) mit dem Kestrel-Server.

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:

• Portfreigabe
• Windows-Authentifizierung im Kernelmodus. Kestrel unterstützt nur die Authentifizierung im Benutzermodus.
• Schnelle Proxyfunktion über Warteschlangenübertragungen
• Direkte Dateiübertragung
• Zwischenspeichern von Antworten

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

• Vergleich: Kestrel und HTTP.sys
• Hosten von ASP.NET Core unter Windows mit IIS
• ASP.NET Core-Modul (ANCM) für IIS

macOS

ASP.NET Core wird mit einem Kestrel-Server ausgeliefert, bei dem es sich um den plattformübergreifenden HTTP-Standardserver handelt.

Linux

ASP.NET Core wird mit einem Kestrel-Server ausgeliefert, bei dem es sich um den plattformübergreifenden HTTP-Standardserver handelt.

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.

  

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

  

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.

Nginx mit Kestrel

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

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).

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

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:

• Visual Studio: Startprofile können verwendet werden, um App und Server mit IIS Express/ASP.NET Core-Modul oder mit der Konsole zu starten.
• Visual Studio Code: Die App und der Server werden von Omnisharp gestartet, wodurch der CoreCLR-Debugger aktiviert wird.
• Visual Studio für Mac: Die App und der Server werden durch Mono Soft-Mode Debugger gestartet.

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.

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

• Kestrel-Webserver in ASP.NET Core
• ASP.NET Core-Modul (ANCM) für IIS
• Hosten von ASP.NET Core unter Windows mit IIS
• Bereitstellen von ASP.NET Core-Apps in Azure App Service
• Hosten von ASP.NET Core unter Linux mit Nginx
• Implementierung des Http.sys-Webservers in ASP.NET Core