Qu'est-ce que Kestrel (vs IIS / Express)

Qu'est-ce que le serveur Web Kestrel et comment est-il lié à IIS / IIS Express?

Je viens de développer des applications sur IIS Express et de les héberger sur un serveur Web IIS. Avec ASP.NET Core, j'ai une dépendance sur Microsoft.AspNetCore.Server.Kestrelet mon démarrage l'a .UseServer("Microsoft.AspNetCore.Server.Kestrel"). Mais lorsque j'exécute mon site Web, j'obtiens toujours l'icône IIS Express dans la barre d'état système. Quelqu'un m'a demandé si j'utilisais IIS Express ou Kestrel et je ne savais pas quoi dire!

Je n'ai aucune exigence multiplateforme car je développe sur un PC et héberge dans Azure, donc je suis confus si je même needKestrel, mais il ne semble pas qu'il y ait une alternative - même les exemples les plus simples utilisent Kestrel.

Qu'est-ce que Kestrel

C'est un serveur Web à part entière. Vous pouvez exécuter votre application ASP.NET Core en utilisant uniquement Kestrel.

Mais lorsque j'exécute mon site Web, j'obtiens toujours l'icône IIS Express dans la barre d'état système

Dans votre application ASP.NET, probablement dans le wwwrootrépertoire, vous verrez un web.config qui contient ceci:

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

Il s'agit du HttpPlatformHandler. Essentiellement, cela transmet toutes les demandes à Kestrel. IIS Express (et IIS d'ailleurs) n'exécutera plus ASP.NET eux-mêmes. Au lieu de cela, ils agiront comme des mandataires qui transmettent simplement les demandes et les réponses de Kestrel. Il y a encore des avantages à utiliser IIS, en particulier il vous donne une configuration de sécurité, une mise en cache au niveau du noyau, etc.

Je voudrais proposer une réponse alternative, avec un peu d'histoire, afin que vous puissiez comprendre pourquoi Kestrel vient, même si vous n'utilisez que Windows et IIS.

Au tout début du développement ASP.NET avant l'an 2000, Microsoft a clairement créé deux pièces pour héberger les applications ASP.NET WebForms,

• Cassini, est devenu plus tard serveur de développement ASP.NET dans Visual Studio. Il s'agit d'un serveur Web entièrement géré écrit en C # basé sur HttpListener. Bien sûr, puisqu'il s'agissait uniquement de développement, de nombreuses fonctionnalités n'ont jamais été implémentées. Alors que Microsoft a rendu le code source de Cassini disponible pour le public, il existe des tiers qui ont bifurqué la base de code et ajouté plus de fonctionnalités, ce qui a lancé la famille Cassini.
• Prise en charge d'ASP.NET sur IIS (révision 1). Étant donné qu'IIS était à l'époque 4.0 et 5.0 / 5.1, qui n'a rien à voir avec les pools d'applications, ASP.NET a même son propre processus de travail ( aspnet_wp.exe).

Donc, pour développer une application Web, vous utilisez Cassini et pour déployer vous utilisez IIS.

• L'introduction de pools d'applications dans IIS 6 a nécessité quelques modifications du côté ASP.NET, et aspnet_wp.exeest donc devenue obsolète et remplacée par aspnet_isapi.dll. Cela peut être considéré comme la prise en charge d'ASP.NET sur IIS révision 2. Les applications ASP.NET sont donc hébergées dans les processus de travail IIS w3wp.exe.

• L'introduction du pipeline intégré dans IIS 7 et versions ultérieures a nécessité des modifications supplémentaires, qui ont été remplacées aspnet_isapi.dllpar webengine4.dll. Cela peut être considéré comme la prise en charge d'ASP.NET sur la révision 3 d'IIS. Les pipelines ASP.NET et IIS sont unifiés.

Vous pouvez voir qu'ASP.NET est devenu beaucoup plus complexe et étroitement intégré à IIS, donc Cassini a commencé à montrer son âge et a été progressivement remplacé par IIS Express (un mode utilisateur IIS léger).

Ainsi, dans de nombreux cas, lorsque les gens accusent IIS d'être lent, ils devraient blâmer ASP.NET en fait. IIS lui-même sans ASP.NET est assez rapide et stable, tandis que ASP.NET n'a pas été développé avec suffisamment de mesures de performances à l'esprit (car WebForms se concentre sur de nombreuses productivités et RAD).

Puis en novembre 2014, ASP.NET 5 (renommé plus tard ASP.NET Core) a été annoncé et est devenu une technologie multiplateforme. De toute évidence, Microsoft avait besoin d'une nouvelle conception pour prendre en charge Windows, macOS et Linux, où tous les principaux serveurs Web, nginx / Apache (ou autres serveurs Web) devraient être considérés en plus d'IIS.

Je pense que beaucoup conviendraient que Microsoft a beaucoup appris de NodeJS, puis a conçu et développé Kestrel (basé sur libuvinitialement mais pourrait bientôt passer à une autre technologie). C'est un serveur Web léger comme Cassini au départ, mais plus tard, d'autres fonctionnalités sont ajoutées (comme une autre réponse commentée, beaucoup plus de fonctionnalités peuvent donc être traitées comme un serveur Web complet). Bien qu'il soit entièrement géré (certaines dépendances natives existent), ce n'est plus un serveur Web jouet comme Cassini.

Alors pourquoi ne pouvez-vous pas simplement utiliser Kestrel? Pourquoi IIS Express et potentiellement IIS, nginx ou Apache sont toujours nécessaires? C'est principalement le résultat de la pratique Internet d'aujourd'hui. La plupart des sites Web utilisent des proxys inverses pour accepter les demandes de vos navigateurs Web, puis les transmettre aux serveurs d'applications en arrière-plan.

• IIS Express / IIS / nginx / Apache sont les serveurs proxy inverse
• Kestrel / NodeJS / Tomcat et ainsi de suite sont les serveurs d'applications

Une autre réponse a déjà montré un lien vers la documentation Microsoft, vous pouvez donc y jeter un œil.

Microsoft a initialement développé HttpPlatformHandler pour faire d'IIS un proxy inverse assez bon pour Java / Python, etc., donc prévu de l'utiliser pour ASP.NET Core. Des problèmes ont commencé à apparaître pendant le développement, c'est pourquoi Microsoft a créé plus tard le module ASP.NET Core spécifiquement pour ASP.NET Core. C'est la prise en charge d'ASP.NET sur IIS révision 4.

À partir d'ASP.NET Core 2.2, le module ASP.NET Core pour IIS (version 2) peut héberger l'environnement .NET Core à l'intérieur du processus de travail IIS ( w3wp.exe), assez similaire à ASP.NET 2.x / 4.x. Ce mode est appelé «hébergement en cours IIS» . Il peut être considéré comme une prise en charge ASP.NET sur IIS révision 5.

Eh bien, assez long, mais j'espère avoir rassemblé toutes les pièces nécessaires et vous apprécierez de le lire.

À partir de ms docs à l' adresse : https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?tabs=aspnetcore2x

Kestrel est un serveur Web multiplateforme pour ASP.NET Core basé sur libuv, une bibliothèque d'E / S asynchrones multiplateforme. Kestrel est le serveur Web inclus par défaut dans les modèles de projet ASP.NET Core.

Vous pouvez utiliser Kestrel seul ou avec un serveur proxy inverse, tel que IIS, Nginx ou Apache. Un serveur proxy inverse reçoit les requêtes HTTP d'Internet et les transmet à Kestrel après quelques manipulations préliminaires.

MISE À JOUR: .net core 2.1, Kestrel utilise à la place des sockets gérés si libuv

À partir de la documentation asp.net core 2.1 à l' adresse : https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1#transport-configuration

Avec la sortie d'ASP.NET Core 2.1, le transport par défaut de Kestrel n'est plus basé sur Libuv mais plutôt sur des sockets gérés.