Implementacje serwera internetowego w środowisku ASP.NET Core
Uwaga
Nie jest to najnowsza wersja tego artykułu. Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.
Ostrzeżenie
Ta wersja ASP.NET Core nie jest już obsługiwana. Aby uzyskać więcej informacji, zobacz .NET i .NET Core Support Policy (Zasady obsługi platformy .NET Core). Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.
Ważne
Te informacje odnoszą się do produktu w wersji wstępnej, który może zostać znacząco zmodyfikowany, zanim zostanie wydany komercyjnie. Firma Microsoft nie udziela żadnych gwarancji, jawnych lub domniemanych, w odniesieniu do informacji podanych w tym miejscu.
Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.
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:
- 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.
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:
- 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
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.
Platforma ASP.NET Core jest dostarczana z następującymi elementami:
- Serwer Kestrel to domyślny, międzyplatformowy serwer HTTP.
- 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 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:
Żą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.
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
- System operacyjny
- 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
- System operacyjny
- 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
- System operacyjny
- 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
- 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