ASP.NET Core è stato progettato con un'architettura che ha moltissimi punti di estendibilità, a partire dal webserver stesso che può essere configurato o del tutto sostituito da altre implementazioni.

Di default, un'applicazione ASP.NET Core usa il webserver Kestrel, fornito con .NET Core. Questo webserver è open-source e in grado di funzionare ugualmente bene su Windows, Mac e Linux. Kestrel è un webserver estremamente performante ma la sua implementazione è ancora giovane e non possiede tutte le funzionalità o la robustezza di altri webserver più maturi. Microsoft raccomanda di non esporre Kestrel direttamente su internet ma di proteggerlo alle spalle di un altro webserver che agirà da reverse proxy, il cui scopo è quello di ricevere e filtrare le richieste dai client per poi inoltrarle a Kestrel, fornendo anche funzionalità aggiuntive in questo processo.

In alternativa, possiamo sfruttare HTTP.sys (noto come WebListener in ASP.NET Core 1.x), un server ricco di funzionalità e più maturo rispetto a Kestrel. Infatti, è in uso da molti anni sia su Windows che su Windows Server come componente fondamentale di IIS.

HTTP.sys si interfaccia con l'omonimo driver di Windows attraverso le [I]HTTP Server API e perciò, al contrario di Kestrel, non può funzionare sulle altre piattaforme supportate da .NET Core.

Data la sua comprovata robustezza, può essere esposto su internet senza la necessità di configurare un reverse proxy.

Sia Kestrel che HTTP.sys hanno i loro pregi e ambiti di utilizzo. Saper scegliere ci permetterà di creare un'applicazione ASP.NET Core che risponde più precisamente alle esigenze dei nostri committenti.

Vediamo in questa tabella riepilogativa quali sono le principali differenze tra i due webserver.

Per usare Kestrel con le sue impostazioni di default non dobbiamo apportare alcuna modifica al codice dell'applicazione. Tuttavia, se abbiamo bisogno di configurare le opzioni di Kestrel come in questo precedente script (https://www.aspitalia.com/script/1277/Impostare-Dimensione-Massima-Request-ASP.NET-Core.aspx), allora dovremo invocare esplicitamente l'extension method UseKestrel durante la costruzione del web host, che avviene nella classe Program del progetto.

public static IWebHost BuildWebHost(string[] args) =>
  WebHost.CreateDefaultBuilder(args)
    .UseKestrel(options =>
    {
      //Qui usiamo l'oggetto options per configurare Kestrel
    })
    .UseLibuv(options =>
    {
      //Qui usiamo l'oggetto options per configurare Libuv
    })
    .UseStartup<Startup>()
    .Build();

Il precedente esempio mostra anche l'extension method UseLibuv, che permette di configurare Libuv, una libreria di supporto usata da Kestrel operante a livello di trasporto. In altre parole, si occupa di gestire le operazioni di I/O con i client in maniera asincrona. Anche Libuv è open-source e multipiattaforma.

Quando invece preferiamo usare HTTP.sys, possiamo configurarlo usando l'extension method UseHttpSys.

public static IWebHost BuildWebHost(string[] args) =>
  WebHost.CreateDefaultBuilder(args)
    .UseHttpSys(options =>
    {
      //Qui usiamo l'oggetto options per configurare HTTP.sys
    })
    .UseStartup<Startup>()
    .Build();

ASP.NET Core non è limitato ai due webserver che abbiamo appena visto. Infatti, ASP.NET Core può lavorare con una qualsiasi implementazione dell'interfaccia IServer, che possiamo registrare con l'extension method UseServer. Costruire un web server non è un compito semplice, per via delle tematiche riguardanti la sicurezza delle applicazioni web. Tuttavia, non è escluso che in futuro si presentino nuove implementazioni di terze parti che offrono nuove peculiarità. Questo è uno dei grandi vantaggi di usare un framework estendibile e open-source come ASP.NET Core.