Es imprescindible interpretar el código de forma correcta previamente a aplicarlo a tu trabajo si tdeseas aportar algo puedes compartirlo con nosotros.
Solución:
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 completamente administrado escrito en C# basado en
HttpListener. Por supuesto, dado que era solo para desarrollo, muchas funciones nunca se implementaron. A medida que Microsoft puso a disposición del público el código fuente de Cassini, hubo terceros que bifurcaron la base del código y agregaron más funciones, lo que dio inicio a la familia Cassini. - Compatibilidad con 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, usa 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.exequedó obsoleto y fue reemplazado poraspnet_isapi.dll. Eso puede verse como compatibilidad con ASP.NET en la revisión 2 de IIS. Por lo tanto, las aplicaciones de ASP.NET se alojan en procesos de trabajo de IIS.w3wp.exe. -
La introducción de canalización integrada en IIS 7 y superior requirió cambios adicionales, que reemplazaron
aspnet_isapi.dllconwebengine4.dll. Eso puede verse como compatibilidad con ASP.NET en la revisión 3 de IIS. Las canalizaciones 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 a IIS por su lentitud, 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ó teniendo en cuenta suficientes métricas de rendimiento (ya que WebForms se enfoca bastante en productividad y RAD).
Luego, en noviembre de 2014, se anunció ASP.NET 5 (más tarde renombrado como 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 (basado en libuv inicialmente, pero podría pasar a otra tecnología pronto). Inicialmente, es un servidor web liviano como Cassini, pero luego se agregan más funciones (como se comentó en otra respuesta, muchas más funciones, por lo que pueden tratarse como un servidor web completo). Aunque está completamente administrado (existen algunas dependencias nativas), ya no es un servidor web de juguete como Cassini.
Entonces, ¿por qué no puedes simplemente usar Kestrel? ¿Por qué aún se necesita 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 proxies inversos para recibir solicitudes de sus navegadores web y luego reenviarlas a los servidores de aplicaciones en segundo plano.
- IIS Express/IIS/nginx/Apache son los servidores proxy inversos
- Kestrel/NodeJS/Tomcat, etc. son los servidores de aplicaciones
Otra respuesta ya mostró un enlace a la documentación de Microsoft, para que pueda echar un vistazo.
Microsoft desarrolló HttpPlatformHandler inicialmente para hacer de IIS un proxy inverso suficientemente bueno para Java/Python, etc., por lo 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. Esa es la compatibilidad con 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 denomina “alojamiento en proceso de IIS”. Se puede considerar como soporte de ASP.NET en la revisión 5 de IIS.
Bueno, bastante largo, pero espero haber juntado todas las piezas necesarias y disfrutes leyéndolo.
¿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, sigo viendo el ícono de IIS Express en la bandeja del sistema
En su aplicación ASP.NET, probablemente en el wwwroot directorio, verá un web.config que contiene esto:
Este es HttpPlatformHandler. Esencialmente, lo que esto hace es avanzar todos peticiones a Kestrel. IIS Express (e IIS para el caso) ya no ejecutará ASP.NET. En cambio, actuarán como proxies que simplemente pasan solicitudes y respuestas de Kestrel. 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 de forma predeterminada en las plantillas de proyecto de 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 manejo preliminar.
ACTUALIZACIÓN: .net core 2.1, Kestrel usa sockets administrados en lugar de libuv
De documentos de asp.net core 2.1 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.
Si te ha sido provechoso este post, sería de mucha ayuda si lo compartes con otros seniors de esta manera contrubuyes a extender esta información.