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.

ASP.NET Core se suministra con los siguientes componentes:

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

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 más información, consulte Módulo ASP.NET Core.

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:

Modelos de hospedaje

Con el hospedaje en proceso, una aplicación ASP.NET Core se ejecuta en el mismo proceso que su proceso de trabajo de IIS. El hospedaje en proceso proporciona un rendimiento mejorado con respecto al hospedaje fuera de proceso 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, 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).

Para obtener más información e instrucciones de configuración, vea los temas siguientes:

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.

    Kestrel se comunica directamente con Internet sin ningún servidor proxy inverso.

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

    Kestrel se comunica indirectamente con Internet a través de un servidor proxy inverso, como IIS, Nginx o Apache.

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 Implementación del servidor web Kestrel en ASP.NET Core.

ASP.NET Core se suministra con los siguientes componentes:

Al usar IIS o IIS Express, la aplicación se ejecuta en un proceso distinto al del proceso de trabajo de IIS (fuera de proceso) con el servidor Kestrel.

Dado que las aplicaciones ASP.NET Core se ejecutan en un proceso independiente del proceso de trabajo de IIS, 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).

En el siguiente diagrama se muestra la relación entre IIS, el módulo ASP.NET Core y una aplicación hospedada fuera de proceso:

Módulo ASP.NET Core

Las solicitudes llegan procedentes de Internet al controlador HTTP.sys en modo kernel. El controlador enruta las solicitudes a IIS en el puerto configurado del sitio web, que suele ser el puerto 80 (HTTP) o 443 (HTTPS). El módulo reenvía las solicitudes a Kestrel en un puerto aleatorio de la aplicación, que no es ni 80 ni 443.

El módulo especifica el puerto a través de la variable de entorno en el inicio, y el middleware de integración de IIS configura el servidor para que escuche en http://localhost:{port}. Se realizan más comprobaciones y se rechazan las solicitudes que no se hayan originado en el módulo. El módulo no admite el reenvío de HTTPS, por lo que las solicitudes se reenvían a través de HTTP, aunque IIS las reciba a través de HTTPS.

Una vez que Kestrel toma la solicitud del módulo, la envía a la canalización de middleware de ASP.NET Core. La canalización de middleware controla la solicitud y la pasa como una instancia de HttpContext a la lógica de la aplicación. El middleware agregado por la integración de IIS actualiza el esquema, la dirección IP remota y PathBase para responder del reenvío de la solicitud a Kestrel. La respuesta de la aplicación se vuelve a pasar a IIS, que la envía de nuevo al cliente HTTP que inició la solicitud.

Para obtener instrucciones de configuración para IIS y el módulo ASP.NET Core, consulte los temas siguientes:

Nginx con Kestrel

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

Apache con Kestrel

Para más información sobre cómo usar Apache en Linux como servidor proxy inverso para Kestrel, consulte Hospedar 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 obtener más información, vea Implementación del servidor web HTTP.sys en ASP.NET Core.

HTTP.sys se comunica directamente con Internet

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

HTTP.sys se comunica directamente con la red interna

Para obtener instrucciones de configuración de HTTP.sys, vea 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:

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 con 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/Windows 10 o posterior†
      • Linux con OpenSSL 1.0.2 o posterior (por ejemplo, Ubuntu 16.04 o posterior)
      • HTTP/2 se admitirá en una versión futura en macOS.
    • Plataforma de destino: .NET Core 2.2 o posterior
  • HTTP.sys
    • Windows Server 2016/Windows 10 o posterior
    • Marco 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.
    • Marco de destino: No aplicable a implementaciones fuera de proceso de IIS.

†Kestrel tiene compatibilidad limitada para 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.

  • Kestrel
    • Sistema operativo
      • Windows Server 2016/Windows 10 o posterior†
      • Linux con OpenSSL 1.0.2 o posterior (por ejemplo, Ubuntu 16.04 o posterior)
      • HTTP/2 se admitirá en una versión futura en macOS.
    • Plataforma de destino: .NET Core 2.2 o posterior
  • HTTP.sys
    • Windows Server 2016/Windows 10 o posterior
    • Marco 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.
    • Marco de destino: No aplicable a implementaciones fuera de proceso de IIS.

†Kestrel tiene compatibilidad limitada para 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.

  • HTTP.sys
    • Windows Server 2016/Windows 10 o posterior
    • Marco de destino: No aplicable a implementaciones de HTTP.sys.
  • 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.
    • Marco de destino: No aplicable a implementaciones fuera de proceso de IIS.

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