Implémentations de serveurs web dans ASP.NET Core

De Tom Dykstra, Steve Smith, Stephen Halter et Chris Ross

Une application ASP.NET Core s’exécute avec une implémentation de serveur HTTP in-process. L’implémentation du serveur écoute les requêtes HTTP et les expose à l’application sous forme d’ensemble de fonctionnalités de requêtes composées dans un HttpContext.

Windows

ASP.NET Core est fourni avec les composants suivants :

• Le serveur Kestrel est l’implémentation de serveur HTTP multiplateforme par défaut. Kestrel offre les meilleures performances et la meilleure utilisation de la mémoire, mais il ne propose pas certaines fonctionnalités avancées de HTTP.sys. Pour plus d’informations, consultez Kestrel vs. HTTP.sys sous l’onglet Windows.
• Le serveur HTTP IIS est un serveur in-process pour IIS.
• Serveur HTTP.sys : serveur HTTP exclusivement Windows basé sur le pilote de noyau HTTP.Sys et l’API Serveur HTTP.

Lorsque vous utilisez IIS ou IIS Express, l’application s’exécute :

• dans le même processus que le processus de travail IIS (modèle d’hébergement in-process) avec le serveur HTTP IIS. In-process est la configuration recommandée.
• Dans un processus distinct du processus Worker IIS (le mode d’hébergement out-of-process) avec le serveur Kestrel.

Le module ASP.NET Core est un module IIS natif qui gère les requêtes IIS natives entre IIS et le serveur HTTP IIS in-process ou Kestrel. Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.

Comparaison entre Kestrel et HTTP.sys

Kestrel présente les avantages suivants par rapport à HTTP.sys :

• Amélioration des performances et de l’utilisation de la mémoire.
• Multiplateforme
• Agilité, car il est développé et corrigé indépendamment du système d’exploitation.
• Port programmatique et configuration TLS
• Extensibilité qui permet l’utilisation de protocoles comme PPv2 et d’autres transports.

Http.Sys fonctionne en tant que composant en mode noyau partagé avec les fonctionnalités suivantes que kestrel ne possède pas :

• Partage de port
• Authentification Windows en mode noyau. Kestrel prend uniquement en charge l’authentification en mode utilisateur.
• Proxy rapide via les transferts de file d’attente
• Transmission de fichier directe
• Mise en cache des réponses

Modèles d'hébergement

Plusieurs modèles d’hébergement sont disponibles :

• Kestrel auto-hébergement : le Kestrel serveur web s’exécute sans nécessiter d’autres serveurs web externes tels que IIS ou HTTP.sys.

• L’auto-hébergement HTTP.sys est une alternative à Kestrel. Kestrel est recommandé sur HTTP.sys, sauf si l’application nécessite des fonctionnalités qui ne sont pas disponibles dans Kestrel.

• Hébergement in-process IIS : une application ASP.NET Core s’exécute dans le même processus que son processus de travail IIS. L’hébergement in-process IIS offre des performances améliorées par rapport à l’hébergement hors processus IIS, car les requêtes ne sont pas proxiées sur la carte de bouclage, une interface réseau qui retourne le trafic réseau sortant vers la même machine. IIS s’occupe de la gestion des processus par l’intermédiaire du service d’activation des processus Windows (WAS).

• Hébergement hors processus IIS : ASP.NET applications principales s’exécutent dans un processus distinct du processus de travail IIS, et le module gère la gestion des processus. Le module démarre le processus pour l’application ASP.NET Core quand la première requête arrive, et il redémarre l’application si elle s’arrête ou se bloque. Il s’agit essentiellement du même comportement que celui des applications s’exécutant in-process, et qui sont gérées par le service d’activation des processus Windows (WAS). L’utilisation d’un processus distinct permet également d’héberger plusieurs applications issues du même pool d’applications.

Pour plus d’informations, consultez les rubriques suivantes :

• Kestrel vs. HTTP.sys
• Héberger ASP.NET Core sur Windows avec IIS
• Module ASP.NET Core (ANCM) pour IIS

macOS

ASP.NET Core est fourni avec le serveur Kestrel qui est le serveur HTTP multiplateforme par défaut.

Linux

ASP.NET Core est fourni avec le serveur Kestrel qui est le serveur HTTP multiplateforme par défaut.

Kestrel

Le serveur Kestrel est l’implémentation de serveur HTTP multiplateforme par défaut. Kestrel offre les meilleures performances et la meilleure utilisation de la mémoire, mais il ne propose pas certaines fonctionnalités avancées de HTTP.sys. Pour plus d’informations, consultez Comparaison entre Kestrel et HTTP.sys dans ce document.

Utilisez Kestrel :

• Par lui même, c’est-à-dire en tant que serveur de périphérie traitant les requêtes en provenance directe d’un réseau, notamment d’Internet.

  

• Avec un serveur proxy inverse, comme IIS (Internet Information Services), Nginx ou Apache. Un serveur proxy inverse reçoit les requêtes HTTP en provenance d’Internet et les transmet à Kestrel.

  

La configuration de l’hébergement, qu’elle soit avec ou sans serveur proxy inverse, est prise en charge.

Pour obtenir Kestrel conseils de configuration et des informations sur l’utilisation de Kestrel dans une configuration de proxy inverse, consultez Kestrel serveur web dans ASP.NET Core.

Nginx avec Kestrel

Pour plus d’informations sur l’utilisation de Nginx sur Linux en tant que serveur proxy inverse pour Kestrel, consultez Héberger ASP.NET Core sur Linux avec Nginx.

HTTP.sys

Si vos applications ASP.NET Core sont exécutées sur Windows, HTTP.sys est une alternative à Kestrel. Kestrel est recommandé sur HTTP.sys, sauf si l’application nécessite des fonctionnalités qui ne sont pas disponibles dans Kestrel. Pour plus d’informations, consultez Implémentation du serveur web HTTP.sys dans ASP.NET Core.

HTTP.sys peut également être utilisé pour les applications qui sont exposées seulement à un réseau interne.

Pour obtenir de l’aide sur la configuration de HTTP.sys, consultez Implémentation du serveur web HTTP.sys dans ASP.NET Core.

Infrastructure serveur d’ASP.NET Core

Le IApplicationBuilder disponible dans la méthode Startup.Configure expose la propriété ServerFeatures du type IFeatureCollection. Kestrel et HTTP.sys exposent une seule fonctionnalité chacun (IServerAddressesFeature), cependant, des implémentations serveur différentes peuvent exposer des fonctionnalités supplémentaires.

IServerAddressesFeature permet de déterminer quel est le port lié à l’implémentation serveur au moment de l’exécution.

Serveurs personnalisés

Si les serveurs intégrés ne répondent pas aux spécifications de l’application, vous pouvez créer une implémentation serveur personnalisée. Le guide OWIN (Open Web Interface pour .NET) montre comment écrire une implémentation IServer basée sur Nowin. Seules les interfaces des fonctionnalités utilisées par l’application nécessitent une implémentation, bien qu’au minimum IHttpRequestFeature et IHttpResponseFeature doivent être pris en charge.

Démarrage du serveur

Le serveur est lancé lorsque l’environnement de développement intégré (IDE) ou l’éditeur démarre l’application :

• Visual Studio : des profils de lancement peuvent être utilisés pour démarrer l’application et le serveur avec IIS Express/Module ASP.NET Core ou avec la console.
• Visual Studio Code : l’application et le serveur sont démarrés par Omnisharp, qui active le débogueur CoreCLR.
• Visual Studio pour Mac : l’application et le serveur sont démarrés par le débogueur Mono Soft-Mode.

Lors du lancement de l’application à partir d’une invite de commandes dans le dossier du projet, dotnet run lance l’application et le serveur (Kestrel et HTTP.sys uniquement). La configuration est spécifiée par l’option -c|--configuration, qui est définie sur Debug (par défaut) ou sur Release.

Un fichier launchSettings.json fournit une configuration lors du lancement d’une application avec dotnet run ou avec un débogueur intégré à un outil tel que Visual Studio. Si les profils de lancement sont présents dans un fichier launchSettings.json, utilisez l’option --launch-profile {PROFILE NAME} avec la commande dotnet run, ou sélectionnez le profil dans Visual Studio. Pour plus d’informations, consultez les rubriques dotnet run et Package de distribution de .NET Core.

Assistance HTTP/2

HTTP/2 est pris en charge avec ASP.NET Core dans les scénarios de déploiement suivants :

• Kestrel
  • Système d'exploitation
    • Windows Server 2016/Windows 10 ou version ultérieure†
    • Linux avec OpenSSL 1.0.2 ou version ultérieure (par exemple, Ubuntu 16.04 ou version ultérieure)
    • macOS 10.15 ou ultérieur
  • Version cible de .Net Framework : .NET Core 2.2 ou version ultérieure
• HTTP.sys
  • Windows Server 2016/Windows 10 ou version ultérieure
  • Version cible de .Net Framework : non applicable aux déploiements HTTP.sys.
• IIS (in-process)
  • Windows Server 2016/Windows 10 ou version ultérieure ; IIS 10 ou version ultérieure
  • Version cible de .Net Framework : .NET Core 2.2 ou version ultérieure
• IIS (out-of-process)
  • Windows Server 2016/Windows 10 ou version ultérieure ; IIS 10 ou version ultérieure
  • Les connexions au serveur de périphérie public utilisent HTTP/2, mais la connexion de proxy inverse à Kestrel utilise HTTP/1.1.
  • Version cible de .Net Framework : non applicable aux déploiements IIS out-of-process.

†Kestrel propose une prise en charge limitée de HTTP/2 sur Windows Server 2012 R2 et Windows 8.1. La prise en charge est limitée car la liste des suites de chiffrement TLS prises en charge sur ces systèmes d’exploitation est limitée. Un certificat généré à l’aide d’Elliptic Curve Digital Signature algorithme (ECDSA) peut être requis pour sécuriser les connexions TLS.

Une connexion HTTP/2 doit utiliser la négociation du protocole de la couche d’application (ALPN) et TLS 1.2 ou version ultérieure. Pour plus d’informations, consultez les rubriques qui se rapportent à vos scénarios de déploiement de serveur.

Ressources supplémentaires

• Serveur web Kestrel dans ASP.NET Core
• Module ASP.NET Core (ANCM) pour IIS
• Héberger ASP.NET Core sur Windows avec IIS
• Déployer des applications ASP.NET Core sur Azure App Service
• Héberger ASP.NET Core sur Linux avec Nginx
• Implémentation de serveur web HTTP.sys dans ASP.NET Core