with the net how for deploy asp asp.net iis asp.net-core kestrel-http-server

asp.net - the - ¿Qué es Kestrel(vs IIS/Express)



set up a hosting environment for asp net core on windows with iis (3)

¿Qué es el servidor web kestrel y cómo se relaciona con IIS / IIS Express?

Vengo de desarrollar aplicaciones en IIS Express y alojarlas en un servidor web IIS. Con ASP.NET Core tengo una dependencia en Microsoft.AspNetCore.Server.Kestrel y mi inicio tiene .UseServer("Microsoft.AspNetCore.Server.Kestrel") . Pero cuando ejecuto mi sitio web, sigo recibiendo el ícono IIS Express en la bandeja del sistema. ¡Alguien me preguntó si estaba usando IIS Express o Kestrel y no sabía qué decir!

No tengo ningún requisito multiplataforma a medida que desarrollo en una PC y host en Azure, así que estoy confundido si incluso need Kestrel, pero no parece que haya una alternativa, incluso las muestras más simples usan Kestrel.

¿Qué es el cernícalo?

Es un servidor web completo. Puede ejecutar su aplicación ASP.NET Core usando solo Kestrel.

Pero cuando ejecuto mi sitio web, aún aparece el ícono IIS Express en la bandeja del sistema

En su aplicación ASP.NET, probablemente en el directorio wwwroot , verá un web.config que contiene esto:

<?xml version="1.0" encoding="utf-8"?> <configuration> <system.webServer> <handlers> <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/> </handlers> <httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogEnabled="false" startupTimeLimit="3600"/> </system.webServer> </configuration>

Este es el HttpPlatformHandler. Esencialmente, lo que esto hace es reenviar todas las solicitudes a Kestrel. IIS Express (e IIS para el caso) ya no ejecutarán ASP.NET. En cambio, actuarán como representantes que simplemente pasan solicitudes y respuestas de Kestrel de un lado a otro. Todavía hay ventajas de usar IIS, específicamente le brinda configuración de seguridad, almacenamiento en caché a nivel de kernel, etc.

De ms docs en: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?tabs=aspnetcore2x

Kestrel es un servidor web multiplataforma para ASP.NET Core basado en libuv, una biblioteca de E / S asíncrona multiplataforma. Kestrel es el servidor web que se incluye por defecto en las plantillas de proyecto ASP.NET Core.

Puede usar Kestrel solo o con un servidor proxy inverso, como IIS, Nginx o Apache. Un servidor proxy inverso recibe solicitudes HTTP de Internet y las reenvía a Kestrel después de un tratamiento preliminar.

ACTUALIZACIÓN: .net core 2.1, Kestrel utiliza sockets administrados en su lugar si libuv

De asp.net core 2.1 docs en: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1#transport-configuration

Con el lanzamiento de ASP.NET Core 2.1, el transporte predeterminado de Kestrel ya no se basa en Libuv, sino en sockets administrados.

Me gustaría ofrecer una respuesta alternativa, con algo de historia, para que pueda entender por qué viene Kestrel, incluso si solo usa Windows e IIS.

Al comienzo del desarrollo de ASP.NET antes del año 2000, claramente Microsoft creó dos piezas para alojar aplicaciones ASP.NET WebForms,

  • Cassini, más tarde se convirtió en ASP.NET Development Server en Visual Studio. Es un servidor web totalmente administrado escrito en C # basado en HttpListener . Por supuesto, dado que era solo para desarrollo, muchas características nunca se implementaron. A medida que Microsoft puso a disposición del público el código fuente de Cassini, hay terceros que bifurcaron la base del código y agregaron más funciones, lo que inició la familia Cassini.
  • Soporte de ASP.NET en IIS (revisión 1). Debido a que IIS era 4.0 y 5.0 / 5.1 en ese momento, que no tiene nada que ver con los grupos de aplicaciones, ASP.NET incluso tiene su propio proceso de trabajo ( aspnet_wp.exe ).

Entonces, para desarrollar una aplicación web, utiliza Cassini, y para implementar usa IIS.

  • La introducción de grupos de aplicaciones en IIS 6 requirió algunos cambios en el lado de ASP.NET, por lo que aspnet_wp.exe volvió obsoleto y reemplazado por aspnet_isapi.dll . Eso puede verse como soporte de ASP.NET en la revisión 2 de IIS. Por lo tanto, las aplicaciones ASP.NET se alojan en procesos de trabajo de IIS w3wp.exe .

  • La introducción de la canalización integrada en IIS 7 y aspnet_isapi.dll posteriores requirió cambios adicionales, que reemplazaron aspnet_isapi.dll con webengine4.dll . Eso puede verse como soporte de ASP.NET en la revisión IIS 3. Las tuberías de ASP.NET e IIS están unificadas.

Puede ver que ASP.NET se ha vuelto mucho más complejo y está estrechamente integrado con IIS, por lo que Cassini comenzó a mostrar su edad y gradualmente fue reemplazado por IIS Express (un modo de usuario lite IIS).

Por lo tanto, en muchos casos, cuando las personas culpan que IIS es lento, deberían culpar a ASP.NET de hecho. IIS en sí sin ASP.NET es bastante rápido y estable, mientras que ASP.NET no se desarrolló con suficientes métricas de rendimiento en mente (ya que WebForms enfoca muchas productividades y RAD).

Luego, en noviembre de 2014, se anunció ASP.NET 5 (luego renombrado a ASP.NET Core) y se convirtió en una tecnología multiplataforma. Obviamente, Microsoft necesitaba un nuevo diseño para admitir Windows, macOS y Linux, donde todos los principales servidores web, nginx / Apache (u otros servidores web) deberían considerarse además de IIS.

Creo que muchos estarían de acuerdo en que Microsoft aprendió mucho de NodeJS, y luego diseñó y desarrolló Kestrel (inicialmente basado en libuv pero pronto podría pasar a otra tecnología). Es un servidor web liviano como Cassini inicialmente, pero luego se agregan más funciones (como comentó otra respuesta, muchas más funciones, por lo que se pueden tratar como un servidor web completo). Aunque totalmente administrado (existen algunas dependencias nativas), ya no es un servidor web de juguete como Cassini.

Entonces, ¿por qué no puedes usar Kestrel? ¿Por qué aún se necesitan IIS Express y potencialmente IIS, nginx o Apache? Eso es principalmente el resultado de la práctica actual de internet. La mayoría de los sitios web utilizan proxys inversos para recibir solicitudes de sus navegadores web y luego reenviarlos a los servidores de aplicaciones en segundo plano.

  • IIS Express / IIS / nginx / Apache son los servidores proxy inversos
  • Kestrel / NodeJS / Tomcat y demás son los servidores de aplicaciones

Otra respuesta ya mostró un enlace a la documentación de Microsoft, por lo que puede echar un vistazo.

Microsoft desarrolló HttpPlatformHandler inicialmente para hacer de IIS un proxy inverso lo suficientemente bueno para Java / Python, etc., así que planeó usarlo para ASP.NET Core. Los problemas comenzaron a aparecer durante el desarrollo, por lo que más tarde Microsoft creó el Módulo ASP.NET Core específicamente para ASP.NET Core. Ese es el soporte de ASP.NET en la revisión 4 de IIS.

A partir de ASP.NET Core 2.2, el Módulo ASP.NET Core para IIS (versión 2) puede alojar el entorno .NET Core dentro del proceso de trabajo de IIS ( w3wp.exe ), bastante similar a ASP.NET 2.x / 4.x. Este modo se llama "IIS en proceso de alojamiento" . Se puede considerar como soporte ASP.NET en la revisión 5 de IIS.

Bueno, bastante largo, pero espero juntar todas las piezas necesarias y que disfrutes leyéndolo.