Implementaciones de servidores web en ASP.NET Core

Por Tom Dykstra, Steve Smith, Stephen Halter y Chris Ross

Una aplicación ASP.NET Core se ejecuta con una implementación de servidor HTTP en proceso. La implementación del servidor realiza escuchas de solicitudes HTTP y las muestra en la aplicación como un conjunto de características de solicitud compuestos en un HttpContext.

Windows

ASP.NET Core se suministra con los siguientes componentes:

• El servidor Kestrel es la implementación de servidor HTTP multiplataforma predeterminada. Kestrel proporciona el mejor rendimiento y uso de memoria, pero carece de algunas de las características avanzadas de HTTP.sys. Para más información, consulte Kestrel frente a HTTP.sys en la pestaña Windows.
• El servidor HTTP de IIS es un servidor en proceso de IIS.
• El servidor HTTP.sys es un servidor HTTP solo de Windows basado en el controlador del kernel HTTP.sys y la API de servidor HTTP.

Cuando se usa IIS o IIS Express, la aplicación se ejecuta:

• En el mismo proceso que el proceso de trabajo de IIS (el modelo de hospedaje dentro de proceso) con el servidor HTTP de IIS. La configuración recomendada es En proceso.
• En un proceso distinto al del proceso de trabajo de IIS (el modelo de hospedaje fuera de proceso) con el Kestrel.

El módulo ASP.NET Core es un módulo nativo de IIS que controla las solicitudes de IIS nativas entre IIS y el servidor de IIS en proceso o Kestrel. Para obtener más información vea Módulo de ASP.NET Core (ANCM) para IIS.

Diferencias entre Kestrel y HTTP.sys

Kestrel tiene las ventajas siguientes con respecto a HTTP.sys:

• Mejor rendimiento y uso de memoria
• Multiplataforma
• Agilidad, ya que se desarrolla y se revisa de forma independiente al sistema operativo
• Configuración de puertos y TLS mediante programación
• Extensibilidad que permite protocolos como PPv2 y transportes alternativos

HTTP.sys funciona como un componente de modo de kernel compartido con las siguientes características de las que carece Kestrel:

• Uso compartido de puertos
• Autenticación de Windows de modo de kernel; Kestrel solo admite la autenticación de modo usuario.
• Proxy rápido mediante transferencias de colas
• Transmisión directa de archivos
• Almacenamiento en caché de respuestas

Modelos de hospedaje

Hay varios modelos de hospedaje disponibles:

• Autohospedaje de Kestrel: el servidor web Kestrel se ejecuta sin necesidad de ningún otro servidor web externo, como IIS o HTTP.sys.

• El autohospedaje http.sys es una alternativa a Kestrel. Se recomienda Kestrel antes que HTTP.sys, salvo si la aplicación necesita características que no están disponibles en Kestrel.

• Hospedaje en proceso de IIS: una aplicación ASP.NET Core se ejecuta en el mismo proceso que su proceso de trabajo de IIS. El hospedaje en proceso de IIS proporciona un rendimiento mejorado con respecto al hospedaje fuera de proceso de IIS porque las solicitudes no se realizan mediante proxy en el adaptador de bucle invertido, una interfaz de red que devuelve el tráfico saliente a la misma máquina. IIS controla la administración de procesos con el Servicio de activación de procesos de Windows (WAS).

• Con el hospedaje fuera de proceso de IIS, las aplicaciones ASP.NET Core se ejecutan en un proceso independiente del proceso de trabajo de IIS, y el módulo se encarga de la administración de procesos. El módulo inicia el proceso de la aplicación ASP.NET Core cuando entra la primera solicitud y reinicia la aplicación si esta se apaga o se bloquea. Este comportamiento es básicamente el mismo que el de las aplicaciones que se ejecutan en proceso y se administran a través del Servicio de activación de procesos de Windows (WAS). El uso de un proceso independiente también permite hospedar más de una aplicación del mismo grupo de aplicaciones.

Para obtener más información, vea lo siguiente:

• Kestrel frente a HTTP.sys
• Hospedaje de ASP.NET Core en Windows con IIS
• Módulo ASP.NET Core (ANCM) para IIS

macOS

ASP.NET Core se distribuye con el servidor Kestrel, que es el servidor HTTP multiplataforma predeterminado.

Linux

ASP.NET Core se distribuye con el servidor Kestrel, que es el servidor HTTP multiplataforma predeterminado.

Kestrel

El servidor Kestrel es la implementación de servidor HTTP multiplataforma predeterminada. Kestrel proporciona el mejor rendimiento y uso de memoria, pero carece de algunas de las características avanzadas de HTTP.sys. Para más información, consulte Diferencias entre Kestrel y HTTP.sys en este documento.

Use Kestrel:

• Por sí solo como un servidor perimetral que procesa solicitudes directamente desde una red, incluida Internet.

  

• Con un servidor proxy inverso, tal como Internet Information Services (IIS), Nginx o Apache. Un servidor proxy inverso recibe las solicitudes HTTP de Internet y las reenvía a Kestrel.

  

Se admite cualquiera de las configuraciones de hospedaje, con o sin un servidor proxy inverso.

Si quiere obtener instrucciones e información sobre la configuración de Kestrel y cuándo usar Kestrel en una configuración de proxy inverso, consulte Servidor web Kestrel en ASP.NET Core.

Nginx con Kestrel

Para información sobre cómo usar Nginx en Linux como servidor proxy inverso para Kestrel, consulte Hospedaje de ASP.NET Core en Linux con Nginx.

Apache con Kestrel

Para información sobre cómo usar Apache en Linux como servidor proxy inverso para Kestrel, consulte Hospedaje de ASP.NET Core en Linux con Apache.

HTTP.sys

Si las aplicaciones ASP.NET Core se ejecutan en Windows, HTTP.sys es una alternativa a Kestrel. Se recomienda Kestrel antes que HTTP.sys, salvo si la aplicación necesita características que no están disponibles en Kestrel. Para más información, vea HTTP.sys web server implementation in ASP.NET Core (Implementaciones del servidor web de HTTP.sys en ASP.NET Core).

HTTP.sys también se puede usar para las aplicaciones que solo se exponen a una red interna.

Si necesita una guía de configuración de HTTP.sys, consulte Implementación del servidor web HTTP.sys en ASP.NET Core.

Infraestructura de servidores de ASP.NET Core

El elemento IApplicationBuilder disponible en el método Startup.Configure expone la propiedad ServerFeatures del tipo IFeatureCollection. Kestrel y HTTP.sys solo exponen una característica cada uno, IServerAddressesFeature, pero otras implementaciones de servidor pueden exponer funcionalidades adicionales.

Se puede usar IServerAddressesFeature para averiguar a qué puerto se ha enlazado la implementación del servidor en tiempo de ejecución.

Servidores personalizados

Si los servidores integrados no cumplen los requisitos de la aplicación, se puede crear una implementación de servidor personalizado. En la guía de Open Web Interface for .NET (OWIN) se muestra cómo escribir una implementación de IServer basada en Nowin. Solo las interfaces de la característica que usa la aplicación requieren implementación, aunque como mínimo se debe admitir IHttpRequestFeature y IHttpResponseFeature.

Inicio del servidor

El servidor se inicia cuando el entorno de desarrollo integrado (IDE) o editor inicia la aplicación:

• Visual Studio: se pueden usar perfiles de inicio para iniciar la aplicación y el servidor con IIS Express/el módulo de ASP.NET Core o la consola.
• Visual Studio Code: la aplicación y el servidor se inician mediante Omnisharp, con lo que se activa el depurador CoreCLR.
• Visual Studio para Mac: la aplicación y el servidor se inician mediante Mono Soft-Mode Debugger.

Al iniciar la aplicación desde un símbolo del sistema en la carpeta del proyecto, dotnet run inicia la aplicación y el servidor (solo Kestrel y HTTP.sys). La configuración se especifica mediante la opción -c|--configuration, que está establecida en Debug (valor predeterminado) o Release.

Un archivo launchSettings.json proporciona la configuración al iniciar una aplicación con dotnet run o un depurador integrado en las herramientas, como Visual Studio. Si hay perfiles de inicio en un archivo launchSettings.json, use la opción --launch-profile {PROFILE NAME} con el comando dotnet run o seleccione el perfil en Visual Studio. Para más información, vea dotnet run y Empaquetado de distribución de .NET Core.

Compatibilidad con HTTP/2

HTTP/2 es compatible con ASP.NET Core en los escenarios de implementación siguientes:

• Kestrel
  • Sistema operativo
    • Windows Server 2016 o Windows 10 o posterior†
    • Linux con OpenSSL 1.0.2 o posterior (por ejemplo, Ubuntu 16.04 o posterior)
    • macOS 10.15 o posterior
  • Plataforma de destino: .NET Core 2.2 o posterior
• HTTP.sys
  • Windows Server 2016/Windows 10 o posterior
  • Plataforma de destino: no aplicable a implementaciones de HTTP.sys.
• IIS (en proceso)
  • Windows Server 2016/Windows 10 o posterior; IIS 10 o posterior
  • Plataforma de destino: .NET Core 2.2 o posterior
• IIS (fuera de proceso)
  • Windows Server 2016/Windows 10 o posterior; IIS 10 o posterior
  • Las conexiones de servidor perimetral de acceso público usan HTTP/2, pero la conexión de proxy inverso al Kestrel usa HTTP/1.1.
  • Plataforma de destino: no aplicable a implementaciones fuera de proceso de IIS.

†Kestrel tiene compatibilidad limitada con HTTP/2 en Windows Server 2012 R2 y Windows 8.1. La compatibilidad es limitada porque la lista de conjuntos de cifrado TLS admitidos y disponibles en estos sistemas operativos está limitada. Se puede requerir un certificado generado mediante Elliptic Curve Digital Signature Algorithm (ECDSA) para proteger las conexiones TLS.

Una conexión HTTP/2 debe usar Application-Layer Protocol Negotiation (ALPN) y TLS 1.2 o posterior. Para más información, vea los temas que pertenecen a los escenarios de implementación de servidor.

Recursos adicionales

• Servidor web Kestrel en ASP.NET Core
• Módulo ASP.NET Core (ANCM) para IIS
• Hospedaje de ASP.NET Core en Windows con IIS
• Implementar aplicaciones de ASP.NET Core en Azure App Service
• Hospedar ASP.NET Core en Linux con Nginx
• Hospedar ASP.NET Core en Linux con Apache
• Implementación del servidor web HTTP.sys en ASP.NET Core