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.

ASP.NET Core est fourni avec les composants suivants :

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

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 ASP.NET Core Module (ANCM) pour IIS.

Kestrel vs. HTTP.sys

Kestrel présente les avantages suivants sur HTTP.sys :

  • Amélioration des performances et de l’utilisation de la mémoire.
  • Multiplateforme
  • Agilité, elle est développée et corrigée indépendamment du système d’exploitation.
  • Configuration du port et du protocole TLS par programmation
  • Extensibilité qui permet des protocoles tels que PPv2 et d’autres transports.

Http.Sys fonctionne en tant que composant en mode noyau partagé avec les fonctionnalités suivantes dont kestrel n’a pas :

Modèles d'hébergement

En utilisant l’hébergement in-process, une application ASP.NET Core s’exécute dans le même processus que son processus de travail IIS. L’hébergement in-process offre de meilleures performances que l’hébergement out-of-process parce que les requêtes n’ont pas de proxy sur l’adaptateur de bouclage, interface réseau qui retourne du trafic réseau sortant à la même machine. IIS s’occupe de la gestion des processus par l’intermédiaire du service d’activation des processus Windows (WAS).

Avec l’hébergement out-of-process, les applications ASP.NET Core s’exécutent dans un processus distinct du processus de travail IIS, et le module s’occupe de la gestion de 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 à partir du même pool d’applications.

Pour plus d’informations et pour obtenir de l’aide sur la configuration, consultez les rubriques suivantes :

Kestrel

Kestrel le serveur est l’implémentation par défaut du serveur HTTP multiplateforme. Kestrel fournit les meilleures performances et l’utilisation de la mémoire, mais il n’a pas certaines des fonctionnalités avancées dans HTTP.sys. Pour plus d’informations, consultez Kestrel vs 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.

    Kestrel communique directement avec Internet sans serveur proxy inverse

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

    Kestrel communique indirectement avec Internet via un serveur proxy inverse, tel que IIS, Nginx ou Apache

La configuration d’hébergement avec ou sans serveur proxy inverse est prise en charge.

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

ASP.NET Core est fourni avec les composants suivants :

Lorsque vous utilisez IIS ou IIS Express, l’application s’exécute dans un processus distinct du processus de travail IIS (hors processus) avec le Kestrel serveur.

Étant donné que les applications ASP.NET Core s’exécutent dans un processus distinct du processus de travail IIS, le module s’occupe de la gestion du 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).

Le schéma suivant illustre la relation entre IIS, le module ASP.NET Core et une application hébergée hors processus :

Module ASP.NET Core

Les requêtes arrivent du web au pilote HTTP.sys en mode noyau. Le pilote route les requêtes vers IIS sur le port configuré du site web, généralement 80 (HTTP) ou 443 (HTTPS). Le module transfère les demandes sur Kestrel un port aléatoire pour l’application, qui n’est pas le port 80 ou 443.

Le module spécifie le port via une variable d’environnement au démarrage, et le middleware d’intégration IIS configure le serveur à écouter http://localhost:{port}. Des vérifications supplémentaires sont effectuées, et les requêtes qui ne proviennent pas du module sont rejetées. Le module ne prend pas en charge le transfert HTTPS : les requêtes sont donc transférées via HTTP, même si IIS les reçoit via HTTPS.

Après Kestrel avoir récupéré la demande à partir du module, la requête est envoyée dans le pipeline d’intergiciel ASP.NET Core. Le pipeline de middlewares traite la requête et la passe en tant qu’instance de HttpContext à la logique de l’application. Middleware ajouté par IIS Integration met à jour le schéma, l’adresse IP distante et le chemin d’accès pour prendre en compte le transfert de la requête vers Kestrel. La réponse de l’application est ensuite repassée à IIS, qui la renvoie au client HTTP à l’origine de la requête.

Pour des conseils de configuration d’IIS et du module ASP.NET Core, consultez les rubriques suivantes :

Nginx avec Kestrel

Pour plus d’informations sur l’utilisation de Nginx sur Linux comme serveur proxy inverse pour Kestrel, consultez Host ASP.NET Core sur Linux avec Nginx.

Apache avec Kestrel

Pour plus d’informations sur l’utilisation d’Apache sur Linux comme serveur proxy inverse pour Kestrel, consultez Host ASP.NET Core sur Linux avec Apache.

HTTP.sys

Si ASP.NET Core applications 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 non disponibles dans Kestrel. Pour plus d’informations, consultez Implémentation du serveur web HTTP.sys dans ASP.NET Core.

HTTP.sys communique directement avec Internet

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

HTTP.sys communique directement avec le réseau interne

Pour obtenir des conseils de configuration HTTP.sys, consultez HTTP.sys implémentation de serveur web 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 uniquement une seule fonctionnalité, IServerAddressesFeaturemais différentes implémentations de serveur 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 :

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 launchSettings.json fichier fournit une configuration lors du lancement d’une application avec dotnet run ou avec un débogueur intégré à des outils, tels que Visual Studio. Si les profils de lancement sont présents dans un launchSettings.json fichier, utilisez l’option avec la --launch-profile {PROFILE NAME}dotnet run commande 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)
      • HTTP/2 sera pris en charge sur macOS dans une prochaine version.
    • 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 de serveur edge accessibles au public utilisent HTTP/2, mais la connexion de proxy inverse pour Kestrel utiliser HTTP/1.1.
    • Version cible de .Net Framework : non applicable aux déploiements IIS out-of-process.

Kestrel† a 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.

  • 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)
      • HTTP/2 sera pris en charge sur macOS dans une prochaine version.
    • 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 de serveur edge accessibles au public utilisent HTTP/2, mais la connexion de proxy inverse pour Kestrel utiliser HTTP/1.1.
    • Version cible de .Net Framework : non applicable aux déploiements IIS out-of-process.

Kestrel† a 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.

  • HTTP.sys
    • Windows Server 2016/Windows 10 ou version ultérieure
    • Version cible de .Net Framework : non applicable aux déploiements HTTP.sys.
  • IIS (out-of-process)
    • Windows Server 2016/Windows 10 ou version ultérieure ; IIS 10 ou version ultérieure
    • Les connexions de serveur edge accessibles au public utilisent HTTP/2, mais la connexion de proxy inverse pour Kestrel utiliser HTTP/1.1.
    • Version cible de .Net Framework : non applicable aux déploiements IIS out-of-process.

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