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.

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

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

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.

Serwer Http.Sys działa jako współużytkowany składnik trybu jądra i oferuje następujące funkcje, których nie ma serwer Kestrel:

Modele hostingu

Dostępnych jest kilka modeli hostingu:

  • Kestrel self-hosting: Kestrel serwer internetowy działa bez konieczności używania żadnego innego zewnętrznego serwera internetowego, takiego jak 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 tematy:

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.

    Kestrel communicates directly with the Internet without a reverse proxy server

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

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

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.

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

W przypadku korzystania z usług IIS lub IIS Express aplikacja jest uruchamiana w procesie oddzielnym od procesu roboczego usług IIS (poza procesem), z serwerem Kestrel.

Ponieważ aplikacje ASP.NET Core są uruchamiane w procesie oddzielnym od procesu roboczego usług IIS, 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).

Na poniższym diagramie przedstawiono relację między usługami IIS, modułem ASP.NET Core Module i aplikacją hostowaną poza procesem:

ASP.NET Core Module

Żądania z Internetu docierają do sterownika HTTP.sys trybu jądra. Sterownik kieruje te żądania do usług IIS na skonfigurowanym porcie witryny internetowej, zazwyczaj 80 (HTTP) lub 443 (HTTPS). Moduł przekazuje żądania do serwera Kestrel na losowym porcie dla aplikacji, który nie jest portem 80 ani 443.

Moduł określa port za pośrednictwem zmiennej środowiskowej podczas uruchamiania, a oprogramowanie pośredniczące integracji usług IIS konfiguruje serwer do nasłuchiwania na porcie http://localhost:{port}. Wykonywane są dodatkowe kontrole, a żądania, które nie pochodzą z modułu, są odrzucane. Moduł nie obsługuje przekazywania HTTPS, dlatego żądania są przekazywane za pośrednictwem protokołu HTTP, nawet jeśli zostały odebrane przez usługi IIS za pośrednictwem protokołu HTTPS.

Żądanie z modułu odebrane przez serwer Kestrel jest wypychane do potoku oprogramowania pośredniczącego ASP.NET Core. Potok oprogramowania pośredniczącego obsługuje żądanie i przekazuje je jako wystąpienie obiektu HttpContext do logiki aplikacji. Oprogramowanie pośredniczące dodane przez integrację z usługami IIS aktualizuje schemat, zdalny adres IP i bazę ścieżek, aby uwzględnić przekazanie żądania do serwera Kestrel. Odpowiedź aplikacji jest przekazywana z powrotem do usług IIS, które wypychają ją z powrotem do klienta HTTP, który zainicjował żądanie.

Aby uzyskać wskazówki dotyczące konfiguracji usług IIS i modułu ASP.NET Core Module, zobacz następujące tematy:

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.

Serwer Apache z serwerem Kestrel

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

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.

HTTP.sys communicates directly with the Internet

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

HTTP.sys communicates directly with the internal network

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:

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

  • 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)
      • Protokół HTTP/2 będzie obsługiwany w systemie macOS w przyszłej wersji.
    • 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).

  • 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)
      • Protokół HTTP/2 będzie obsługiwany w systemie macOS w przyszłej wersji.
    • 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).

  • HTTP.sys
    • Windows Server 2016/Windows 10 lub nowszy
    • Platforma docelowa: nie dotyczy wdrożeń serwera HTTP.sys.
  • 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.

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