Partager via


Implémentations de serveurs web dans ASP.NET Core

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 8 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la Stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 8 de cet article.

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

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

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.

    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 en provenance d’Internet et les transmet à Kestrel.

    Kestrel communique indirectement avec Internet via un serveur proxy inverse, par exemple IIS, Nginx ou Apache

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.

ASP.NET Core est fourni avec les composants suivants :

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

É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 réachemine les requêtes vers Kestrel sur un port aléatoire pour l’application, qui n’est pas le port 80 ou le port 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 pour qu’il écoute sur 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.

Une fois que Kestrel a récupéré la requête en provenance du module, celle-ci est envoyée (push) vers le pipeline de middleware 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. Le middleware ajouté par l’intégration d’IIS met à jour le schéma, l’adresse IP distante et la base du chemin pour prendre en compte le réacheminement 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 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 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 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 :

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.

  • 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 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.

  • 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 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.

  • 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 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.

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