Implementacje serwera internetowego w środowisku ASP.NET Core

Autorzy: Tom Dykstra, Steve Smith, Stephen Halter i Chris Ross

Aplikacje ASP.NET Core działają z implementacją wewnątrzprocesowego serwera HTTP. Ta implementacja serwera nasłuchuje żądań HTTP i udostępnia je aplikacji jako zestaw funkcji na żądanie tworzących obiekt HttpContext.

Windows

Platforma ASP.NET Core jest dostarczana z następującymi elementami:

• Serwer Kestrel to domyślna, międzyplatformowa implementacja serwera HTTP. Serwer Kestrel zapewnia najlepszą wydajność i wykorzystanie pamięci, ale nie ma niektórych zaawansowanych funkcji serwera HTTP.sys. Aby uzyskać więcej informacji, zobacz Kestrel vs. HTTP.sys na karcie Windows.
• Serwer HTTP usług IIS jest serwerem wewnątrzprocesowym dla usług IIS.
• Serwer HTTP.sys to serwer HTTP tylko dla systemu Windows korzystający ze sterownika jądra HTTP.sys i interfejsu HTTP Server API.

W przypadku korzystania z usług IIS lub IIS Express aplikacja jest uruchamiana:

• W tym samym procesie co proces roboczy usług IIS (model hostingu wewnątrzprocesowego ) z serwerem HTTP usług IIS. Konfiguracja wewnątrzprocesowa jest zalecana.
• W procesie oddzielnym od procesu roboczego usług IIS (modelu hostingu poza procesem) z serwerem Kestrel.

Moduł ASP.NET Core Module to natywny moduł usług IIS, który obsługuje natywne żądania usług IIS przekazywane między usługami IIS a wewnątrzprocesowym serwerem HTTP usług IIS lub serwerem Kestrel. Aby uzyskać więcej informacji, zobacz Moduł ASP.NET Core Module (ANCM) dla usług IIS.

Porównanie serwera Kestrel i HTTP.sys

Serwer Kestrel ma następujące zalety w porównaniu z serwerem HTTP.sys:

• Poprawa wydajności i wykorzystania pamięci.
• Wiele platform.
• Elastyczność — jest tworzony i poprawiany niezależnie od systemu operacyjnego.
• Programowa konfiguracja portów i protokołu TLS.
• Rozszerzalność, która umożliwia korzystanie z protokołów takich jak PPv2 i alternatywnych metod transportu.

Http.Sys działa jako składnik trybu jądra współużytkowanego z następującymi funkcjami, które kestrel nie mają:

• Współużytkowanie portów
• Uwierzytelnianie systemu Windows w trybie jądra. Serwer Kestrel obsługuje uwierzytelnianie tylko w trybie użytkownika .
• Szybkie użycie serwera proxy za pośrednictwem transferów kolejek
• Bezpośrednia transmisja plików
• Buforowanie odpowiedzi

Modele hostingu

Dostępnych jest kilka modeli hostingu:

• Kestrel self-hosting: Kestrel serwer internetowy działa bez konieczności używania innych zewnętrznych serwerów sieci Web, takich jak usługi IIS lub HTTP.sys.

• HTTP.sys self-hosting jest alternatywą dla Kestrel. Zalecane jest użycie serwera Kestrel, a nie HTTP.sys, chyba że aplikacja wymaga funkcji niedostępnych w przypadku serwera Kestrel.

• Hostowanie procesów usług IIS: aplikacja ASP.NET Core działa w tym samym procesie co proces roboczy usług IIS. Hosting usług IIS w procesie zapewnia lepszą wydajność hostingu poza procesem usług IIS, ponieważ żądania nie są przekierowywane przez kartę sprzężenia zwrotnego, interfejs sieciowy, który zwraca wychodzący ruch sieciowy z powrotem do tej samej maszyny. Usługi IIS obsługują zarządzanie procesami za pomocą usługi aktywacji procesów systemu Windows (WAS).

• Hosting poza procesem usług IIS: aplikacje ASP.NET Core działają w procesie oddzielnym od procesu roboczego usług IIS, a moduł obsługuje zarządzanie procesami. Moduł uruchamia proces na potrzeby aplikacji ASP.NET Core po odebraniu pierwszego żądania i ponownie uruchamia aplikację, jeśli zostanie ona zamknięta lub ulegnie awarii. Jest to zasadniczo takie samo działanie jak w przypadku aplikacji uruchamianych wewnątrz procesu, zarządzanych przez usługę aktywacji procesów systemu Windows (WAS). Użycie oddzielnego procesu umożliwia również hostowanie więcej niż jednej aplikacji z tej samej puli aplikacji.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Kestrel a HTTP.sys
• Hostowanie aplikacji ASP.NET Core w systemie Windows przy użyciu usług IIS
• Moduł ASP.NET Core (ANCM) dla usług IIS

macOS

Platforma ASP.NET Core jest dostarczana z serwerem Kestrel, czyli domyślnym, międzyplatformowym serwerem HTTP.

Linux

Platforma ASP.NET Core jest dostarczana z serwerem Kestrel, czyli domyślnym, międzyplatformowym serwerem HTTP.

Kestrel

Serwer Kestrel to domyślna, międzyplatformowa implementacja serwera HTTP. Serwer Kestrel zapewnia najlepszą wydajność i wykorzystanie pamięci, ale nie ma niektórych zaawansowanych funkcji serwera HTTP.sys. Aby uzyskać więcej informacji, zobacz Porównanie serwera Kestrel i HTTP.sys w tym dokumencie.

Można używać serwera Kestrel:

• Samego, jako serwera brzegowego przetwarzającego żądania otrzymywane bezpośrednio z sieci, w tym z Internetu.

  

• Ze zwrotnym serwerem proxy, takim jak serwer usług Internet Information Services (IIS), Nginx lub Apache. Zwrotny serwer proxy odbiera żądania HTTP z Internetu i przekazuje je do serwera Kestrel.

  

Obie konfiguracje hostingu — ze zwrotnym serwerem proxy lub bez — są obsługiwane.

Aby uzyskać Kestrel wskazówki dotyczące konfiguracji i informacje na temat tego, kiedy należy używać Kestrel w konfiguracji zwrotnego serwera proxy, zobacz Kestrel serwer internetowy w ASP.NET Core.

Serwer Nginx z serwerem Kestrel

Aby uzyskać informacje na temat używania serwera Nginx w systemie Linux jako zwrotnego serwera proxy dla serwera Kestrel, zobacz Hostowanie aplikacji ASP.NET Core w systemie Linux z serwerem Nginx.

HTTP.sys

Jeśli aplikacje ASP.NET Core są uruchamiane w systemie Windows, można użyć serwera HTTP.sys jako alternatywy dla serwera Kestrel. Zalecane jest użycie serwera Kestrel, a nie HTTP.sys, chyba że aplikacja wymaga funkcji niedostępnych w przypadku serwera Kestrel. Aby uzyskać więcej informacji, zobacz Implementacja serwera internetowego HTTP.sys w środowisku ASP.NET Core.

Serwera HTTP.sys można również używać w przypadku aplikacji, które są uwidocznione tylko w sieci wewnętrznej.

Aby uzyskać wskazówki dotyczące konfiguracji serwera HTTP.sys, zobacz Implementacja serwera internetowego HTTP.sys w środowisku ASP.NET Core.

Infrastruktura serwera platformy ASP.NET Core

Interfejs IApplicationBuilder dostępny w ramach metody Startup.Configure uwidacznia właściwość ServerFeatures typu IFeatureCollection. Serwery Kestrel i HTTP.sys uwidaczniają tylko jedną funkcję, IServerAddressesFeature, ale różne implementacje serwerów mogą uwidaczniać dodatkowe funkcje.

Funkcja IServerAddressesFeature umożliwia określenie, który port został powiązany przez implementację serwera podczas uruchamiania.

Serwery niestandardowe

Jeśli wbudowane serwery nie spełniają wymagań aplikacji, można utworzyć niestandardową implementację serwera. Przewodnik po otwartym interfejsie internetowym dla platformy .NET (OWIN) przedstawia sposób pisania opartej na usłudze Nowin implementacji serwera IServer. Wymagana jest tylko implementacja interfejsów funkcji używanych przez aplikację, ale muszą być obsługiwane co najmniej funkcje IHttpRequestFeature i IHttpResponseFeature.

Uruchamianie serwera

Serwer jest uruchamiany po uruchomieniu aplikacji przez zintegrowane środowisko projektowe (IDE) lub edytor:

• Visual Studio: można używać profilów uruchamiania do uruchomienia aplikacji i serwera z użyciem usługi IIS Express/ i modułu ASP.NET Core Module lub konsoli.
• Visual Studio Code: aplikacja i serwer są uruchamiane przez narzędzie Omnisharp, które aktywuje debuger CoreCLR.
• Visual Studio dla komputerów Mac: aplikacja i serwer są uruchamiane przez debuger Mono Soft-Mode Debugger.

W przypadku uruchamiania aplikacji z poziomu wiersza polecenia w folderze projektu polecenie dotnet run uruchamia aplikację i serwer (tylko serwery Kestrel i HTTP.sys). Konfigurację określa opcja -c|--configuration, ustawiona na wartość Debug (domyślnie) lub Release.

Plik launchSettings.json wskazuje konfigurację w przypadku uruchamiania aplikacji za pomocą polecenia dotnet run lub debugera wbudowanego w narzędzie, na przykład program Visual Studio. Jeśli plik launchSettings.json zawiera profile uruchamiania, użyj opcji --launch-profile {PROFILE NAME} z poleceniem dotnet run lub wybierz profil w programie Visual Studio. Aby uzyskać więcej informacji, zobacz dotnet run i Tworzenie pakietów dystrybucji platformy .NET Core.

Obsługa protokołu HTTP/2

Protokół HTTP/2 jest obsługiwany w przypadku środowiska ASP.NET Core w następujących scenariuszach wdrażania:

• Kestrel
  • System operacyjny
    • Windows Server 2016/Windows 10 lub nowszy†
    • Linux z biblioteką OpenSSL w wersji 1.0.2 lub nowszej (na przykład Ubuntu 16.04 lub nowszy)
    • system macOS 10.15 lub nowszy
  • Platforma docelowa: .NET Core 2.2 lub nowsza
• HTTP.sys
  • Windows Server 2016/Windows 10 lub nowszy
  • Platforma docelowa: nie dotyczy wdrożeń serwera HTTP.sys.
• IIS (wewnątrzprocesowe)
  • Windows Server 2016/Windows 10 lub nowszy; usługi IIS 10 lub nowsze
  • Platforma docelowa: .NET Core 2.2 lub nowsza
• IIS (poza procesem)
  • Windows Server 2016/Windows 10 lub nowszy; usługi IIS 10 lub nowsze
  • Połączenia z publicznym serwerem brzegowym używają protokołu HTTP/2, ale połączenie zwrotnego serwera proxy z serwerem Kestrel używa protokołu HTTP/1.1.
  • Platforma docelowa: nie dotyczy wdrożeń usług IIS poza procesem.

†Serwer Kestrel zapewnia ograniczoną obsługę protokołu HTTP/2 w systemach Windows Server 2012 R2 i Windows 8.1. Obsługa jest ograniczona ze względu na ograniczenie listy obsługiwanych zestawów szyfrowania TLS dostępnych w tych systemach operacyjnych. Do zabezpieczenia połączeń TLS może być wymagany certyfikat wygenerowany przy użyciu algorytmu ECDSA (Elliptic Curve Digital Signature Algorithm).

Połączenie protokołu HTTP/2 musi używać negocjowania protokołu warstwy aplikacji (ALPN) i protokołu TLS w wersji 1.2 lub nowszej. Aby uzyskać więcej informacji, zobacz tematy dotyczące odpowiednich scenariuszy wdrażania serwera.

Dodatkowe zasoby

• Kestrel serwer internetowy w programie ASP.NET Core
• Moduł ASP.NET Core (ANCM) dla usług IIS
• Hostowanie aplikacji ASP.NET Core w systemie Windows przy użyciu usług IIS
• Wdrażanie aplikacji ASP.NET Core w usłudze Azure App Service
• Hostowanie aplikacji ASP.NET Core w systemie Linux z serwerem Nginx
• Implementacja serwera internetowego HTTP.sys w środowisku ASP.NET Core