Implementazioni di server Web in ASP.NET Core

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.

Windows

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 funziona come componente in modalità kernel condiviso con le funzionalità seguenti che kestrel non ha:

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

• L'self-hosting HTTP.sys è 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 vs. HTTP.sys
• Host ASP.NET Core in Windows con IIS
• Modulo ASP.NET Core (ANCM) per IIS

macOS

ASP.NET Core viene fornito con il server Kestrel, ovvero il server HTTP multipiattaforma predefinito.

Linux

ASP.NET Core viene fornito con il server Kestrel, ovvero il server HTTP multipiattaforma predefinito.

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.

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.

Apache con Kestrel

Per informazioni su come usare Apache in Linux come server proxy inverso per Kestrel, vedere Host ASP.NET Core in Linux con Apache.

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

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.

Risorse aggiuntive

• Kestrel server Web in ASP.NET Core
• Modulo ASP.NET Core (ANCM) per IIS
• Host ASP.NET Core in Windows con IIS
• Distribuire le app ASP.NET Core in Servizio app di Azure
• Ospitare ASP.NET Core in Linux con Nginx
• Ospitare ASP.NET Core in Linux con Apache
• Implementazione del server Web HTTP.sys in ASP.NET Core