Les solutions d’information Web de Microsoft comptent parmi les premières plates-formes de serveur Web. Initialement publié en 1995, il a été régulièrement mis à jour avec Windows Server. Cela fait un moment depuis la dernière version majeure, lorsque IIS 10 version 1809 est sortie en novembre 2018. Bien que Windows Server 2022 ait ajouté l’assistance QUIC et TLS 1.3, la plate-forme de serveur Web principale n’a pas changé.
Microsoft a a en fait mis en place discrètement 2 plates-formes de serveurs Web alternatives dans le cadre de.NET, en mettant l’accent sur la fourniture d’applications Web dynamiques modernes. Le tout premier d’entre eux, Http.sys est un serveur Windows uniquement, idéal pour exécuter à grande échelle des applications ASP.NET Core hébergées par Windows. Le 2e, Kestrel, est le serveur Web ASP.NET Core par défaut et fonctionne sur toutes les plates-formes .NET Core, y compris macOS. Il est développé pour fonctionner derrière des équilibreurs de charge tels que Nginx, en plus de prendre en charge les technologies Web modernes telles que gRPC.
Présentation de Kestrel
Kestrel est un choix intéressant pour quiconque crée des applications Web .NET . C’est un serveur raisonnablement léger par rapport à IIS, et comme il est multiplateforme, il rationalise la façon dont vous pouvez choisir une plate-forme d’hébergement. Il est également idéal comme outil de développement, fonctionnant sur du matériel de bureau pour les tests et l’expérimentation. Il existe une prise en charge de HTTPS, HTTP/2 et une version préliminaire de QUIC, de sorte que votre code est à l’épreuve du temps et fonctionnera fermement.
Le serveur s’installe dans le cadre d’ASP.NET Core et est le par défaut pour les sites qui ne sont pas clairement hébergés par IIS. Vous n’avez pas besoin d’écrire de code pour lancer Kestrel, au-delà de l’approche familière WebApplication.CreateBuilder. Microsoft a conçu Kestrel pour fonctionner avec très peu de configuration, soit en utilisant une soumission de paramètres qui est produite lorsque vous utilisez dotnet brand-new pour configurer un échafaudage d’application ou lorsque vous développez une nouvelle application dans Visual Studio.
Configuration de Kestrel
Les applications ont la possibilité de configurer Kestrel à l’aide des API dans WebApplication et WebApplicationBuilder, par exemple, en ajoutant des ports supplémentaires . Comme Kestrel ne s’exécute pas tant que votre code ASP.NET Core n’est pas exécuté, il s’agit d’une méthode relativement simple pour rendre dynamique la configuration du serveur, toute modification ne nécessitant que quelques lignes de code. Vous pouvez ajouter une nouvelle URL de point de terminaison à partir de la commande dotnet run ou en modifiant le fichier appsettings.json de votre application. De plus, une variable d’environnement ASP.NET Core peut être définie pour gérer les ports utilisés. Cette polyvalence rend Kestrel étonnamment facile à manipuler ; il vous suffit de sélectionner la méthode qui correspond le mieux à votre code.
D’autres choix contrôlent les adresses IP sur lesquelles un serveur écoute une connexion, avec la possibilité d’écouter toutes les interfaces disponibles. Si vous avez affaire à HTTPS et que vous avez besoin d’évaluer une application avant de la mettre en production, Kestrel est livré avec un certificat de test intégré pour vous aider à démarrer. Ceci est installé dans le cadre du SDK ASP.NET Core et peut être géré à partir de l’outil de ligne de commande dotnet . Une fois en production, utilisez les nombreux outils de configuration pour sélectionner un certificat approprié.
Grâce au support des sockets Unix, Kestrel est compatible avec la majorité des équilibreurs de charge, composés de Nginx. Cela le rend parfait pour une utilisation dans des conteneurs, que ce soit sous Linux ou dans un conteneur Windows. Ici, la prise en charge des sockets Unix vous permettra d’ajouter des fonctionnalités de mise en réseau et de sécurité à votre code via un maillage de services.
Personnalisez votre serveur, à votre façon
Avoir un site Web le serveur qui est configurable par programmation fonctionne ; vous pouvez ajouter des fonctionnalités selon vos besoins. Un serveur de production peut fonctionner avec très peu de journalisation. Si des problèmes surviennent, vous pouvez rapidement configurer Kestrel pour ajouter d’autres fournisseurs de journalisation afin d’obtenir plus d’informations sur les opérations. D’autres alternatives incluent l’ajout d’une assistance pour des services alternatifs, par exemple, la fourniture de contenu fixe à partir d’un système de fichiers.
Il existe de nombreuses options dans ASP.NET Core pour les services pris en charge, vous pouvez donc élargir au-delà de la valeur par défaut très peu de configuration d’API, par exemple, l’ajout d’outils de gestion de session ou la mise en cache d’actions. Il est nécessaire de se rappeler que l’ajout de nouveaux services inclut davantage d’API sur votre serveur, ce qui élargit la surface d’attaque. Il vous suffit donc d’ajouter des fonctionnalités que vous savez que vous allez utiliser et dont vous savez qu’elles seront protégées par votre plate-forme de sécurité.
Comme Kestrel est extrêmement personnalisable, vous pouvez gérer les verbes HTTP qui sont pris en charge lors de l’acceptation des requêtes des navigateurs Internet, ainsi que gérer la façon dont votre serveur réagit à des structures URI spécifiques. Ici, vous pouvez tirer parti des primitives .NET telles que les lambdas pour analyser les informations et les utiliser dans vos applications, réduisant ainsi la complexité de votre code en transférant les performances à un serveur. Cela peut faciliter l’utilisation du codage URI pour gérer l’état d’une application, en utilisant des chemins pour attraper les paramètres dans un URI. De cette manière, Kestrel et ASP.NET peuvent créer et exécuter des applications Web d’une seule page, en utilisant la structure URI pour identifier le contenu fourni aux utilisateurs.
Microsoft a en fait développé un serveur Web polyvalent et puissant qui est utile option à IIS pour les applications ASP.NET. En bénéficiant de sa technique d’API minimale, très peu de code est nécessaire pour créer un serveur Web qui peut utiliser des chemins et des paramètres pour servir du matériel fixe avec des fonctions ASP.NET Core, précisément ce qui est nécessaire pour créer des applications modernes pouvant évoluer dans le cloud. conteneurs natifs.
Comment Microsoft a changé IIS avec Kestrel
Comme toujours, il est fascinant de voir ce que Microsoft termine avec ses propres outils. Kestrel vient tout juste d’être associé au proxy inverse open source.NET YARP pour remplacer la plate-forme Web sous-jacente dans Azure App Solutions, une procédure décrite comme « un poids lourd ». Un article de blog fascinant a détaillé le processus utilisé pour gérer la migration, qui vaut la peine d’être examiné si vous envisagez de faire des comparaisons avec vos propres applications et services.
Bien qu’Azure App Services ait la demande supplémentaire d’être une plate-forme multi-locataire extrêmement évolutive, il y a des leçons dans la migration de Microsoft qui peuvent être utilisées pour tout passage à Kestrel. Ce n’est pas le premier service à effectuer ce changement : Bing, Azure Active Directory Site et Dynamics 365 utilisent déjà exactement le même serveur.
L’échelle des fournisseurs d’applications Azure est énorme, même pour les services hyperscale tels que Azur. Il prend actuellement en charge plus de 160 milliards de demandes HTTP par jour et héberge plus de 14 millions de noms de domaine. L’architecture sous-jacente est normale pour les services à l’échelle du cloud, avec la plate-forme derrière un ensemble d’équilibreurs de charge et avec le code App Service fonctionnant sur un ensemble de travailleurs, fourni via un serveur Web. Dans le monde, cela indique plus de 200 000 cœurs exécutant des serveurs Web.
Avant la mise à niveau, cela fonctionnait sur IIS et HTTP.sys. En passant à Kestrel et YARP, Microsoft pourrait utiliser pour ses utilisateurs un ensemble plus large de protocoles HTTP, renforcer ses options de connexion sûres et sécurisées, tout en permettant aux développeurs d’utiliser leur choix de plates-formes d’applications.
Le processus de migration un service frontal qui traite des navigateurs Internet traditionnels ainsi que des clients API REST et gRPC a révélé certains problèmes avec Kestrel qui ont été résolus, ce qui le rend meilleur pour les applications destinées aux utilisateurs. Le changement le plus intrigant a peut-être amené Kestrel à se comporter de manière moins stricte. Initialement composé pour se conformer à la spécification HTTP, il a refusé les demandes qui incluaient des caractères de saut de ligne en début de ligne. Le groupe Kestrel a maintenant annulé sa conformité et les nouvelles versions acceptent désormais cette catégorie de demande.
Le passage à une nouvelle plate-forme à partir d’une plate-forme en cours d’exécution étant donné que les premiers jours d’Azure nous permet d’obtenir des informations fascinantes normes : le débit a en fait augmenté de près de 80 % pour les demandes HTTP de base. Cela se traduit par une réduction significative de l’utilisation du processeur sur l’ensemble de la flotte d’hôtes de services frontaux, que le groupe continue de surveiller dans l’espoir de réduire à terme le nombre de cœurs qu’ils utilisent, économisant à la fois les dépenses et les ressources du centre de données.
Comme Kestrel est multiplateforme, le même code peut désormais prendre en charge le travail Linux, permettant à Azure d’éliminer les serveurs Nginx qui offraient les frontaux de travail Linux. Avoir exactement les mêmes installations pour Linux et Windows devrait réduire les frais de gestion, avec une base de code commune pour le service et un ensemble commun de fonctionnalités. Au fur et à mesure de la mise à niveau de Kestrel et YARP, de toutes nouvelles fonctionnalités seront disponibles pour tous les utilisateurs d’Azure App Service, et pas seulement pour un sous-ensemble spécifique au système d’exploitation.
Le travail effectué par Microsoft pour fournir Kestrel et YARP dans Azure App Service profitera à tous ceux qui utilisent Kestrel. Le placer au cœur de l’une des plates-formes les plus exigeantes d’Azure exposera rapidement les cas périphériques qui peuvent ne pas être visibles pour ASP.NET Core, du moins pas sans nécessiter un débogage substantiel.
C’est un gagnant-gagnant situation pour Kestrel et ASP.NET Core, ce qui rend très probable que votre prochain travail ciblera Kestrel plutôt que le IIS vieillissant. Le résultat doit être des serveurs Web plus simples à configurer et à gérer et qui fonctionnent sur de nombreuses plates-formes de serveurs typiques ou dans des conteneurs, sans le compromis entre simplicité et sécurité qui est souvent un problème lors d’une exécution à grande échelle.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
