Implementazioni di server Web in ASP.NET Core
Nota
Questa non è la versione più recente di questo articolo. Per la versione corrente, vedere la versione .NET 9 di questo articolo.
Avviso
Questa versione di ASP.NET Core non è più supportata. Per altre informazioni, vedere Criteri di supporto di .NET e .NET Core. Per la versione corrente, vedere la versione .NET 8 di questo articolo.
Importante
Queste informazioni si riferiscono a un prodotto non definitive che può essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.
Per la versione corrente, vedere la versione .NET 9 di questo articolo.
Di Tom Dykstra, Steve Smith, Stephen Halter e Chris Ross
Un'app ASP.NET Core viene eseguita con un'implementazione del server HTTP in-process. L'implementazione del server attende le richieste HTTP e le rende visibili all'app come un set di funzionalità di richiesta combinate in un HttpContext.
ASP.NET Core include quanto segue:
- Il server Kestrel è l'implementazione di server HTTP multipiattaforma predefinita. Kestrel offre le prestazioni e l'utilizzo della memoria migliori, ma non dispone di alcune delle funzionalità avanzate in HTTP.sys. Per altre informazioni, vedere Kestrel vs. HTTP.sys nella scheda Windows.
- Il server HTTP IIS è un server in-process per IIS.
- Il server HTTP.sys è un server HTTP solo per Windows basato sul driver del kernel HTTP.sys e l'API HTTP Server.
Quando si usa IIS oppure IIS Express, l'app viene eseguita:
- Nello stesso processo del processo di lavoro IIS (modello di hosting in-process) con il server HTTP IIS. In-process è la configurazione consigliata.
- In un processo separato dal processo di lavoro IIS (modello di hosting out-of-process) con il server Kestrel.
Il modulo ASP.NET Core è un modulo IIS nativo che gestisce le richieste IIS native tra IIS e il server HTTP IIS in-process o il server Kestrel. Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.
Confronto tra Kestrel e HTTP.sys
Kestrel offre i vantaggi seguenti rispetto a HTTP.sys:
- Prestazioni e utilizzo della memoria migliori.
- Multipiattaforma
- Agilità, sviluppo e patch sono indipendenti dal sistema operativo.
- Configurazione di porte e TLS a livello di codice
- Estendibilità che consente protocolli come PPv2 e trasporti alternativi.
Http.Sys opera come componente in modalità kernel condiviso con le funzionalità seguenti che kestrel non hanno:
- Condivisione delle porte
- Autenticazione di Windows in modalità kernel. Kestrel supporta solo l'autenticazione in modalità utente.
- Proxy rapido tramite trasferimenti di code
- Trasmissione diretta dei file
- Memorizzazione nella cache delle risposte
Modelli di hosting
Sono disponibili diversi modelli di hosting:
Kestrel self-hosting: il Kestrel server Web viene eseguito senza richiedere altri server Web esterni, ad esempio IIS o HTTP.sys.
HTTP.sys self-hosting è un'alternativa a Kestrel. Kestrel è consigliato rispetto a HTTP.sys a meno che l'app non richieda funzionalità non disponibili in Kestrel.
Hosting in-process di IIS: un'app ASP.NET Core viene eseguita nello stesso processo del processo di lavoro IIS. L'hosting in-process di IIS offre prestazioni migliorate rispetto all'hosting out-of-process iis perché le richieste non vengono trasmesse tramite proxy sulla scheda di loopback, un'interfaccia di rete che restituisce il traffico di rete in uscita allo stesso computer. Per gestire il processo, IIS usa il servizio Attivazione processo Windows (WAS).
Hosting out-of-process di IIS: ASP.NET le app Core vengono eseguite in un processo separato dal processo di lavoro IIS e il modulo gestisce la gestione dei processi. Il modulo avvia il processo per l'app ASP.NET Core quando arriva la prima richiesta e riavvia l'app se viene arrestata o si arresta in modo anomalo. Si tratta essenzialmente dello stesso comportamento delle app eseguite in-process e gestite dal servizio Attivazione processo Windows. L'uso di un processo separato consente anche l'hosting di più di un'app dallo stesso pool di app.
Per altre informazioni, vedere gli argomenti seguenti:
Kestrel
Il server Kestrel è l'implementazione di server HTTP multipiattaforma predefinita. Kestrel offre le prestazioni e l'utilizzo della memoria migliori, ma non dispone di alcune delle funzionalità avanzate in HTTP.sys. Per altre informazioni, vedere Confronto tra Kestrel e HTTP.sys in questo documento.
Usare Kestrel:
Da solo come server perimetrale che elabora le richieste direttamente da una rete, inclusa Internet.
Con un server proxy inverso, ad esempio Internet Information Services (IIS), Nginx o Apache. Il server proxy inverso riceve le richieste HTTP da Internet e le inoltra a Kestrel.
Sono supportate entrambe le configurazioni di hosting, con o senza un server proxy inverso.
Per Kestrel indicazioni sulla configurazione e informazioni su quando usare Kestrel in una configurazione del proxy inverso, vedere Kestrel Server Web in ASP.NET Core.
ASP.NET Core include quanto segue:
- Il serverKestrel è il server HTTP multipiattaforma predefinito.
- Il server HTTP.sys è un server HTTP solo per Windows basato sul driver del kernel HTTP.sys e l'API HTTP Server.
Quando si usa IIS o IIS Express, l'app viene eseguita in un processo separato dal processo di lavoro IIS (out-of-process) con il server Kestrel.
Poiché le app ASP.NET Core vengono eseguite in un processo distinto dal processo di lavoro IIS, il modulo esegue la gestione dei processi. Il modulo avvia il processo per l'app ASP.NET Core quando arriva la prima richiesta e riavvia l'app se viene arrestata o si arresta in modo anomalo. Si tratta essenzialmente dello stesso comportamento delle app eseguite in-process e gestite dal servizio Attivazione processo Windows.
Il diagramma seguente illustra la relazione tra IIS, il modulo ASP.NET Core e un'app ospitata out-of-process:
Le richieste arrivano dal Web al driver HTTP.sys in modalità kernel. Il driver instrada le richieste a IIS sulla porta configurata per il sito Web, in genere 80 (HTTP) o 443 (HTTPS). Il modulo inoltra le richieste a Kestrel su una porta casuale per l'app non corrispondente alla porta 80 o 443.
Il modulo specifica la porta tramite una variabile di ambiente all'avvio e il middleware di integrazione IIS configura il server per l'ascolto su http://localhost:{port}
. Vengono eseguiti controlli aggiuntivi e le richieste che non provengono dal modulo vengono rifiutate. Il modulo non supporta l'inoltro HTTPS, pertanto le richieste vengono inoltrate tramite HTTP anche se sono state ricevute da IIS tramite HTTPS.
Dopo che Kestrel ha prelevato la richiesta dal modulo, viene eseguito il push della richiesta nella pipeline middleware di ASP.NET Core. La pipeline middleware gestisce la richiesta e la passa come istanza di HttpContext
alla logica dell'app. Il middleware aggiunto dall'integrazione di IIS aggiorna lo schema, l'IP remoto e la base del percorso per l'account per l'inoltro della richiesta a Kestrel. La risposta dell'app viene quindi passata a IIS, che ne esegue di nuovo il push al client HTTP che ha avviato la richiesta.
Per indicazioni sulla configurazione di IIS e del modulo ASP.NET Core, vedere gli argomenti seguenti:
Nginx con Kestrel
Per informazioni su come usare Nginx in Linux come server proxy inverso per Kestrel, vedere Host ASP.NET Core in Linux con Nginx.
HTTP.sys
Se si eseguono app ASP.NET Core in Windows, HTTP.sys è un'alternativa a Kestrel. Kestrel è consigliato rispetto a HTTP.sys a meno che l'app non richieda funzionalità non disponibili in Kestrel. Per altre informazioni, vedere l'introduzione all'implementazione del server Web HTTP.sys in ASP.NET Core.
HTTP.sys può essere usato anche per le app che vengono esposte solo a una rete interna.
Per indicazioni sulla configurazione di HTTP.sys, vedere Implementazione del server Web HTTP.sys in ASP.NET Core.
Infrastruttura del server ASP.NET Core
L'oggetto IApplicationBuilder disponibile nel metodo Startup.Configure
espone la proprietà ServerFeatures del tipo IFeatureCollection. Kestrel e HTTP.sys espongono una singola funzionalità ciascuno, IServerAddressesFeature, ma implementazioni server diverse potrebbero esporre funzionalità aggiuntive.
È possibile usare IServerAddressesFeature
per individuare la porta a cui è associata l'implementazione server in fase di esecuzione.
Server personalizzati
Se i server predefiniti non soddisfano i requisiti dell'app, è possibile creare un'implementazione server personalizzata. La guida a Open Web Interface for .NET (OWIN) spiega come scrivere un'implementazione Nowin di IServer. È necessario implementare solo le interfacce delle funzionalità usate dall'app, anche se è richiesto come minimo il supporto di IHttpRequestFeature e IHttpResponseFeature.
Avvio del server
Il server viene avviato quando l'editor o l'ambiente di sviluppo integrato (IDE) avvia l'app:
- Visual Studio: è possibile usare i profili di avvio per avviare l'app e il server con IIS Express/Modulo ASP.NET Core o la console.
- Visual Studio Code: l'app e il server vengono avviati da Omnisharp, che attiva il debugger CoreCLR.
- Visual Studio per Mac: l'app e il server vengono avviati dal debugger in modalità Mono Soft.
All'avvio dell'app dal prompt dei comandi nella cartella del progetto, dotnet run avvia l'app e il server (solo Kestrel e HTTP.sys). La configurazione viene specificata dall'opzione -c|--configuration
, impostata su Debug
(valore predefinito) o su Release
.
Un file launchSettings.json
fornisce la configurazione quando si avvia un'app con dotnet run
o con un debugger integrato negli strumenti, ad esempio Visual Studio. Se i profili di avvio sono presenti in un file launchSettings.json
, usare l'opzione --launch-profile {PROFILE NAME}
con il comando dotnet run
o selezionare il profilo in Visual Studio. Per altre informazioni, vedere dotnet run e Creazione di pacchetti di distribuzione di .NET Core.
Supporto HTTP/2
HTTP/2 è supportato con ASP.NET Core negli scenari di distribuzione seguenti:
- Kestrel
- Sistema operativo
- Windows Server 2016/Windows 10 o versioni successive†
- Linux con OpenSSL 1.0.2 o versioni successive (ad esempio, Ubuntu 16.04 o versioni successive)
- macOS 10.15 o versione successiva
- Framework di destinazione: .NET Core 2.2 o versioni successive
- Sistema operativo
- HTTP.sys
- Windows Server 2016/Windows 10 o versioni successive
- Framework di destinazione: non applicabile alle distribuzioni HTTP.sys.
- IIS (in-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Framework di destinazione: .NET Core 2.2 o versioni successive
- IIS (out-of-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Le connessioni server perimetrali pubbliche usano HTTP/2, mentre la connessione con proxy inverso a Kestrel usa HTTP/1.1.
- Framework di destinazione: non applicabile alle distribuzioni IIS out-of-process.
†Kestrel ha un supporto limitato per HTTP/2 in Windows Server 2012 R2 e Windows 8.1. Il supporto è limitato perché l'elenco di suite di crittografia TLS supportate disponibili in questi sistemi operativi è limitato. Un certificato generato con un algoritmo ECDSA potrebbe essere necessario per proteggere le connessioni TLS.
- Kestrel
- Sistema operativo
- Windows Server 2016/Windows 10 o versioni successive†
- Linux con OpenSSL 1.0.2 o versioni successive (ad esempio, Ubuntu 16.04 o versioni successive)
- HTTP/2 verrà supportato in macOS in una versione futura.
- Framework di destinazione: .NET Core 2.2 o versioni successive
- Sistema operativo
- HTTP.sys
- Windows Server 2016/Windows 10 o versioni successive
- Framework di destinazione: non applicabile alle distribuzioni HTTP.sys.
- IIS (in-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Framework di destinazione: .NET Core 2.2 o versioni successive
- IIS (out-of-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Le connessioni server perimetrali pubbliche usano HTTP/2, mentre la connessione con proxy inverso a Kestrel usa HTTP/1.1.
- Framework di destinazione: non applicabile alle distribuzioni IIS out-of-process.
†Kestrel ha un supporto limitato per HTTP/2 in Windows Server 2012 R2 e Windows 8.1. Il supporto è limitato perché l'elenco di suite di crittografia TLS supportate disponibili in questi sistemi operativi è limitato. Un certificato generato con un algoritmo ECDSA potrebbe essere necessario per proteggere le connessioni TLS.
- Kestrel
- Sistema operativo
- Windows Server 2016/Windows 10 o versioni successive†
- Linux con OpenSSL 1.0.2 o versioni successive (ad esempio, Ubuntu 16.04 o versioni successive)
- HTTP/2 verrà supportato in macOS in una versione futura.
- Framework di destinazione: .NET Core 2.2 o versioni successive
- Sistema operativo
- HTTP.sys
- Windows Server 2016/Windows 10 o versioni successive
- Framework di destinazione: non applicabile alle distribuzioni HTTP.sys.
- IIS (in-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Framework di destinazione: .NET Core 2.2 o versioni successive
- IIS (out-of-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Le connessioni server perimetrali pubbliche usano HTTP/2, mentre la connessione con proxy inverso a Kestrel usa HTTP/1.1.
- Framework di destinazione: non applicabile alle distribuzioni IIS out-of-process.
†Kestrel ha un supporto limitato per HTTP/2 in Windows Server 2012 R2 e Windows 8.1. Il supporto è limitato perché l'elenco di suite di crittografia TLS supportate disponibili in questi sistemi operativi è limitato. Un certificato generato con un algoritmo ECDSA potrebbe essere necessario per proteggere le connessioni TLS.
- HTTP.sys
- Windows Server 2016/Windows 10 o versioni successive
- Framework di destinazione: non applicabile alle distribuzioni HTTP.sys.
- IIS (out-of-process)
- Windows Server 2016/Windows 10 o versioni successive; IIS 10 o versioni successive
- Le connessioni server perimetrali pubbliche usano HTTP/2, mentre la connessione con proxy inverso a Kestrel usa HTTP/1.1.
- Framework di destinazione: non applicabile alle distribuzioni IIS out-of-process.
Una connessione HTTP/2 deve usare ALPN (Application-Layer Protocol Negotiation) e TLS 1.2 o versioni successive. Per altre informazioni, vedere gli argomenti relativi agli scenari di distribuzione server.