Ler en inglés

Compartir por


Implementaciones de servidores web en ASP.NET Core

Nota

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión de .NET 9 de este artículo.

Aviso

Esta versión de ASP.NET Core ya no se admite. Para obtener más información, consulte la directiva de compatibilidad de .NET y .NET Core. Para la versión actual, consulte la versión de .NET 9 de este artículo.

Importante

Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

Para la versión actual, consulte la versión de .NET 9 de este artículo.

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

    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 Servidor web Kestrel en ASP.NET Core.

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

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.

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

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 basada en IServer. 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 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.

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

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

  • HTTP.sys
    • Windows Server 2016/Windows 10 o posterior
    • Plataforma 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.
    • Plataforma 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.

Patrones de aplicaciones web empresariales

Para obtener instrucciones sobre cómo crear una aplicación ASP.NET Core confiable, segura, eficaz, comprobable y escalable, consulte patrones empresariales de aplicación web. Hay disponible una aplicación web de ejemplo de calidad de producción completa que implementa los patrones.

Recursos adicionales