Présentation des architectures IIS
par l’équipe IIS, Reagan Templin
Compatibilité
| Version | Notes |
|---|---|
| IIS 7.0 et versions ultérieures | Les fonctionnalités décrites dans cet article ont été introduites dans IIS 7.0. |
| IIS 6.0 et versions antérieures | Les fonctionnalités décrites dans cet article n’ont pas été prises en charge avant IIS 7.0. |
Introduction
Internet Information Services (IIS) 7 et versions ultérieures fournissent une architecture de traitement des demandes qui inclut :
- Le service d’activation de processus Windows (WAS), qui permet aux sites d’utiliser des protocoles autres que HTTP et HTTPS.
- Moteur de serveur web qui peut être personnalisé en ajoutant ou en supprimant des modules.
- Pipelines de traitement des demandes intégrés à partir d’IIS et de ASP.NET.
Composants dans IIS
IIS contient plusieurs composants qui exécutent des fonctions importantes pour les rôles d’application et de serveur web dans Windows Server® 2008 (IIS 7.0) et Windows Server 2008 R2 (IIS 7.5). Chaque composant a des responsabilités, telles que l’écoute des demandes adressées au serveur, la gestion des processus et la lecture des fichiers de configuration. Ces composants incluent des écouteurs de protocole, tels que des HTTP.sys et des services, tels que le service WWW (World Wide Web Publishing Service) et le service WAS (Windows Process Activation Service).
Écouteurs de protocole
Les écouteurs de protocole reçoivent des demandes spécifiques au protocole, les envoient à IIS pour traitement, puis retournent des réponses aux demandeurs. Par exemple, lorsqu’un navigateur client demande une page Web à partir d’Internet, l’écouteur HTTP, HTTP.sys, récupère la requête et l’envoie à IIS pour traitement. Une fois que IIS traite la requête, HTTP.sys retourne une réponse au navigateur client.
Par défaut, IIS fournit HTTP.sys en tant qu’écouteur de protocole qui écoute les requêtes HTTP et HTTPS. HTTP.sys a été introduit dans IIS 6.0 en tant qu’écouteur de protocole spécifique à HTTP pour les requêtes HTTP. HTTP.sys reste l’écouteur HTTP dans IIS 7 et versions ultérieures, mais inclut la prise en charge du protocole SSL (Secure Sockets Layer).
Pour prendre en charge les services et applications qui utilisent des protocoles autres que HTTP et HTTPS, vous pouvez utiliser des technologies telles que Windows Communication Foundation (WCF). WCF dispose d’adaptateurs d’écouteur qui fournissent les fonctionnalités d’un écouteur de protocole et d’un adaptateur d’écouteur. Les adaptateurs d’écouteur sont abordés plus loin dans ce document. Pour plus d’informations sur WCF, consultez Windows Communication Foundation sur MSDN.
Pile de protocole de transfert hypertexte (HTTP.sys)
L’écouteur HTTP fait partie du sous-système de mise en réseau des systèmes d’exploitation Windows et est implémenté en tant que pilote de périphérique en mode noyau appelé pile HTTP (HTTP.sys). HTTP.sys écoute les requêtes HTTP du réseau, transmet les requêtes à IIS pour traitement, puis retourne les réponses traitées aux navigateurs clients.
Dans IIS 6.0, HTTP.sys remplacé l’API Windows Sockets (Winsock), qui était un composant en mode utilisateur utilisé par les versions précédentes d’IIS pour recevoir des requêtes HTTP et envoyer des réponses HTTP. IIS 7 et versions ultérieures continuent de s’appuyer sur HTTP.sys pour les requêtes HTTP.
HTTP.sys offre les avantages suivants :
- Mise en cache en mode noyau. Les demandes de réponses mises en cache sont traitées sans passer au mode utilisateur.
- Mise en file d’attente de requête en mode noyau. Les requêtes entraînent moins de surcharge dans le basculement de contexte, car le noyau transfère les requêtes directement au processus de travail approprié. Si aucun processus de travail n’est disponible pour accepter une demande, la file d’attente de demandes en mode noyau contient la demande jusqu’à ce qu’un processus de travail le récupère.
- Prétraitement des demandes et filtrage de sécurité.
Service de publication World Wide Web (service WWW)
Dans IIS 7 et versions ultérieures, les fonctionnalités qui ont été précédemment gérées par le service WWW (Service de publication World Wide Web) sont désormais réparties entre deux services : le service WWW et un nouveau service, le service d’activation des processus Windows (WAS). Ces deux services s’exécutent en tant que LocalSystem dans le même processus Svchost.exe et partagent les mêmes fichiers binaires.
Remarque
Vous pouvez également voir le service WWW appelé W3SVC dans la documentation.
Fonctionnement du service WWW dans IIS 6.0
Dans IIS 6.0, le service WWW gère les principaux domaines suivants dans IIS :
- Administration et configuration HTTP
- Gestion des processus
- Monitoring des performances
Administration et configuration HTTP
Le service WWW lit les informations de configuration de la métabase IIS et utilise ces informations pour configurer et mettre à jour l’écouteur HTTP, HTTP.sys. En outre, le service WWW démarre, arrête, surveille et gère les processus de travail qui traitent les requêtes HTTP.
Monitoring des performances
Le service WWW surveille les performances et fournit des compteurs de performances pour les sites Web et pour le cache IIS.
Process Management
Le service WWW gère les pools d’applications et les processus de travail, tels que le démarrage, l’arrêt et le recyclage des processus de travail. En outre, le service WWW surveille l’intégrité des processus de travail et appelle une détection rapide des échecs pour empêcher le démarrage de nouveaux processus lorsque plusieurs processus de travail échouent dans un délai configurable.
Fonctionnement du service WWW dans IIS
Dans IIS, le service WWW ne gère plus les processus de travail. Au lieu de cela, le service WWW est l’adaptateur d’écouteur pour l’écouteur HTTP, HTTP.sys. En tant qu’adaptateur d’écouteur, le service WWW est principalement chargé de configurer HTTP.sys, de mettre à jour HTTP.sys lorsque la configuration change et de notifier WAS lorsqu’une demande entre dans la file d’attente de la demande.
En outre, le service WWW continue de collecter les compteurs pour les sites Web. Étant donné que les compteurs de performances font toujours partie du service WWW, ils sont propres à HTTP et ne s’appliquent pas à WAS.
Windows Process Activation Service (WAS)
Dans IIS 7 et versions ultérieures, le service d’activation des processus Windows (WAS) gère la configuration du pool d’applications et les processus de travail au lieu du service WWW. Cela vous permet d’utiliser le même modèle de configuration et de processus pour les sites HTTP et non HTTP.
En outre, vous pouvez exécuter WAS sans le service WWW si vous n’avez pas besoin de fonctionnalités HTTP. Par exemple, vous pouvez gérer un service Web via un adaptateur d’écouteur WCF, tel que NetTcpActivator, sans exécuter le service WWW si vous n’avez pas besoin d’écouter les requêtes HTTP dans HTTP.sys. Pour plus d’informations sur les adaptateurs d’écouteur WCF et sur la façon d’héberger des applications WCF dans IIS 7 et versions ultérieures à l’aide de WAS, consultez Hébergement dans WCF sur MSDN.
Gestion de la configuration dans WAS
Au démarrage, WAS lit certaines informations du fichier ApplicationHost.config et transmet ces informations aux adaptateurs d’écouteur sur le serveur. Les adaptateurs d’écouteur sont des composants qui établissent la communication entre les écouteurs WAS et les écouteurs de protocole, tels que HTTP.sys. Une fois que les adaptateurs d’écouteur reçoivent des informations de configuration, ils configurent leurs écouteurs de protocole associés et préparent les écouteurs à écouter les demandes.
Dans le cas de WCF, un adaptateur d’écouteur inclut les fonctionnalités d’un écouteur de protocole. Par conséquent, un adaptateur d’écouteur WCF, tel que NetTcpActivator, est configuré en fonction des informations de WAS. Une fois NetTcpActivator configuré, il écoute les requêtes qui utilisent le protocole net.tcp. Pour plus d’informations sur les adaptateurs d’écouteur WCF, consultez l’architecture d’activation WAS sur MSDN.
La liste suivante décrit le type d’informations lues par WAS à partir de la configuration :
- Informations de configuration globales
- Informations de configuration de protocole pour les protocoles HTTP et non HTTP
- Configuration du pool d’applications, par exemple les informations du compte de processus
- Configuration de site, telle que des liaisons et des applications
- Configuration de l’application, telle que les protocoles activés et les pools d’applications auxquels appartiennent les applications
Si ApplicationHost.config change, WAS reçoit une notification et met à jour les adaptateurs de l’écouteur avec les nouvelles informations.
Process Management
WAS gère les pools d’applications et les processus de travail pour les requêtes HTTP et non HTTP. Lorsqu’un écouteur de protocole récupère une demande cliente, WAS détermine si un processus de travail est en cours d’exécution ou non. Si un pool d’applications dispose déjà d’un processus de travail qui traite les demandes, l’adaptateur d’écouteur transmet la demande au processus de travail pour traitement. S’il n’existe aucun processus de travail dans le pool d’applications, WAS démarre un processus de travail afin que l’adaptateur de l’écouteur puisse lui transmettre la demande pour traitement.
Remarque
Étant donné que WAS gère les processus pour les protocoles HTTP et non HTTP, vous pouvez exécuter des applications avec différents protocoles dans le même pool d’applications. Par exemple, vous pouvez développer une application, telle qu’un service XML, et l’héberger sur HTTP et net.tcp.
modules dans IIS
IIS fournit une nouvelle architecture différente des versions précédentes d’IIS. Au lieu de conserver la majorité des fonctionnalités au sein du serveur lui-même, IIS inclut un moteur de serveur web dans lequel vous pouvez ajouter ou supprimer des composants, appelés modules, en fonction de vos besoins.
Les modules sont des fonctionnalités individuelles que le serveur utilise pour traiter les demandes. Par exemple, IIS utilise des modules d’authentification pour authentifier les informations d’identification du client et les modules de cache pour gérer l’activité du cache.
La nouvelle architecture offre les avantages suivants par rapport aux versions précédentes d’IIS :
- Vous pouvez contrôler les modules souhaités sur le serveur.
- Vous pouvez personnaliser un serveur en fonction d’un rôle spécifique dans votre environnement.
- Vous pouvez utiliser des modules personnalisés pour remplacer des modules existants ou introduire de nouvelles fonctionnalités.
La nouvelle architecture améliore également la sécurité et simplifie l’administration. En supprimant les modules inutiles, vous réduisez la surface d’attaque du serveur et l’encombrement mémoire, qui est la quantité de mémoire utilisée par le worker serveur sur l’ordinateur. Vous éliminez également la nécessité de gérer les fonctionnalités inutiles pour vos sites et applications.
Modules natifs
Les sections suivantes décrivent les modules natifs disponibles avec une installation complète d’IIS 7 et versions ultérieures. Vous pouvez les supprimer ou les remplacer par des modules personnalisés, en fonction de vos besoins.
Modules HTTP
Plusieurs modules dans IIS 7 et versions ultérieures effectuent des tâches spécifiques au protocole HTTP (Hypertext Transfer Protocol) dans le pipeline de traitement des demandes. Les modules HTTP incluent des modules pour répondre aux informations et aux demandes envoyées dans les en-têtes du client, pour retourner des erreurs HTTP, pour rediriger les demandes, etc.
| Nom du module | Description | Ressource |
|---|---|---|
| CustomErrorModule | Envoie les messages d’erreur HTTP par défaut et configurés lorsqu’un code d’état d’erreur est défini sur une réponse. | Inetsrv\Custerr.dll |
| HttpRedirectionModule | Prend en charge la redirection configurable pour les requêtes HTTP. | Inetsrv\Redirect.dll |
| ProtocolSupportModule | Effectue des actions liées au protocole, telles que la définition d’en-têtes de réponse et la redirection d’en-têtes en fonction de la configuration. | Inetsrv\Protsup.dll |
| RequestFilteringModule | Ajouté dans IIS 7.5. Filtre les requêtes comme configurées pour contrôler le comportement du protocole et du contenu. | Inetsrv\modrqflt.dll |
| WebDAVModule | Ajouté dans IIS 7.5. Permet une publication plus sécurisée du contenu à l’aide du protocole HTTP via SSL. | Inetsrv\WebDAV.dll |
Modules de sécurité
Plusieurs modules dans IIS effectuent des tâches liées à la sécurité dans le pipeline de traitement des demandes. En outre, il existe des modules distincts pour chacun des schémas d’authentification, ce qui vous permet de sélectionner des modules pour les types d’authentification souhaités sur votre serveur. Il existe également des modules qui effectuent une autorisation d’URL et un module qui filtre les demandes.
| Nom du module | Description | Ressource |
|---|---|---|
| AnonymousAuthenticationModule | Effectue l’authentification anonyme lorsqu’aucune autre méthode d’authentification ne réussit. | Inetsrv\Authanon.dll |
| BasicAuthenticationModule | Effectue l’authentification de base. | Inetsrv\Authbas.dll |
| CertificateMappingAuthenticationModule | Effectue l’authentification de mappage de certificats à l’aide d’Active Directory. | Inetsrv\Authcert.dll |
| DigestAuthenticationModule | Effectue l’authentification Digest. | Inetsrv\Authmd5.dll |
| IISCertificateMappingAuthenticationModule | Effectue l’authentification de mappage de certificats à l’aide de la configuration de certificat IIS. | Inetsrv\Authmap.dll |
| RequestFilteringModule | Effectue des tâches URLScan telles que la configuration des verbes autorisés et des extensions de nom de fichier, la définition des limites et l’analyse des séquences de caractères incorrectes. | Inetsrv\Modrqflt.dll |
| UrlAuthorizationModule | Effectue l’autorisation d’URL. | Inetsrv\Urlauthz.dll |
| WindowsAuthenticationModule | Effectue l’authentification intégrée NTLM. | Inetsrv\Authsspi.dll |
| IpRestrictionModule | Limite les adresses IPv4 répertoriées dans la liste ipSecurity dans la configuration. | Inetsrv\iprestr.dll |
Modules de contenu
Plusieurs modules d’IIS effectuent des tâches liées au contenu dans le pipeline de traitement des demandes. Les modules de contenu incluent des modules pour traiter les demandes de fichiers statiques, pour retourner une page par défaut lorsqu’un client ne spécifie pas de ressource dans une demande, pour répertorier le contenu d’un répertoire, etc.
| Nom du module | Description | Ressource |
|---|---|---|
| CgiModule | Exécute des processus CGI (Common Gateway Interface) pour générer la sortie de réponse. | Inetsrv\Cgi.dll |
| DefaultDocumentModule | Tente de renvoyer un document par défaut pour les demandes adressées au répertoire parent. | Inetsrv\Defdoc.dll |
| DirectoryListingModule | Copier le contenu d’un répertoire. | Inetsrv\dirlist.dll |
| IsapiModule | Héberge des DLL d’extension ISAPI. | Inetsrv\Isapi.dll |
| IsapiFilterModule | Prend en charge les DLL de filtre ISAPI. | Inetsrv\Filter.dll |
| ServerSideIncludeModule | Les processus côté serveur incluent du code. | Inetsrv\Iis_ssi.dll |
| StaticFileModule | Sert des fichiers statiques. | Inetsrv\Static.dll |
| FastCgiModule | Prend en charge FastCGI, qui offre une alternative haute performance à CGI. | Inetsrv\iisfcgi.dll |
Compression Modules
Deux modules dans IIS effectuent la compression dans le pipeline de traitement des demandes.
| Nom du module | Description | Ressource |
|---|---|---|
| DynamicCompressionModule | Compresse les réponses et applique le codage de transfert de compression Gzip aux réponses. | Inetsrv\Compdyn.dll |
| StaticCompressionModule | Effectue la pré compression du contenu statique. | Inetsrv\Compstat.dll |
Mise en cache des modules
Plusieurs modules dans IIS effectuent des tâches liées à la mise en cache dans le pipeline de traitement des demandes. La mise en cache améliore les performances de vos sites web et applications web en stockant des informations traitées, telles que des pages Web, en mémoire sur le serveur, puis en réutilisant ces informations dans les demandes suivantes pour la même ressource.
| Nom du module | Description | Ressource |
|---|---|---|
| FileCacheModule | Fournit la mise en cache en mode utilisateur pour les fichiers et les descripteurs de fichiers. | Inetsrv\Cachfile.dll |
| HTTPCacheModule | Fournit le mode noyau et la mise en cache en mode utilisateur dans HTTP.sys. | Inetsrv\Cachhttp.dll |
| TokenCacheModule | Fournit la mise en cache du mode utilisateur des paires nom d’utilisateur et jetons pour les modules qui produisent des principaux d’utilisateur Windows. | Inetsrv\Cachtokn.dll |
| UriCacheModule | Fournit la mise en cache en mode utilisateur des informations d’URL. | Inetsrv\Cachuri.dll |
Modules de journalisation et de diagnostic
Plusieurs modules dans IIS effectuent des tâches liées à la journalisation et aux diagnostics dans le pipeline de traitement des demandes. Les modules de journalisation prennent en charge le chargement de modules personnalisés et le passage d’informations à HTTP.sys. Les modules de diagnostic suivent et signalent les événements pendant le traitement des demandes.
| Nom du module | Description | Ressource |
|---|---|---|
| CustomLoggingModule | Charge des modules de journalisation personnalisés. | Inetsrv\Logcust.dll |
| FailedRequestsTracingModule | Prend en charge la fonctionnalité de suivi des demandes ayant échoué. | Inetsrv\Iisfreb.dll |
| HttpLoggingModule | Transmet les informations et l’état de traitement à HTTP.sys pour la journalisation. | Inetsrv\Loghttp.dll |
| RequestMonitorModule | Effectue le suivi des demandes en cours d’exécution dans les processus de travail et signale des informations avec l’interface de programmation d’application d’état et de contrôle du runtime (RSCA). | Inetsrv\Iisreqs.dll |
| TracingModule | Signale des événements à Suivi d'événements pour Windows (ETW). | Inetsrv\Iisetw.dll |
Modules de support managé
Quelques modules dans IIS prennent en charge l’intégration managée dans le pipeline de traitement des demandes IIS.
| Nom du module | Description | Ressource |
|---|---|---|
| ManagedEngine | Fournit l’intégration des modules de code managé dans le pipeline de traitement des demandes IIS. | Microsoft.NET\Framework\v2.0.50727\webengine.dll |
| ConfigurationValidationModule | Valide les problèmes de configuration, par exemple lorsqu’une application s’exécute en mode intégré, mais a des gestionnaires ou des modules déclarés dans la section system.web. | Inetsrv\validcfg.dll |
Modules managés
En plus des modules natifs, IIS vous permet d’utiliser des modules de code managé pour étendre les fonctionnalités IIS. Certains des modules managés, tels que UrlAuthorization, ont un équivalent de module natif qui fournit une alternative native au module managé.
Remarque
Les modules managés dépendent du module ManagedEngine.
Le tableau suivant répertorie les modules managés disponibles avec une installation complète d’IIS 7 et versions ultérieures. Pour plus d’informations sur les modules managés, consultez le Kit de développement logiciel (SDK) .NET Framework 2.0 sur MSDN.
| Nom du module | Description | Ressource |
|---|---|---|
| AnonymousIdentification | Gère les identificateurs anonymes, qui sont utilisés par les fonctionnalités qui prennent en charge l’identification anonyme, telles que le profil ASP.NET. | System.Web.Security.AnonymousIdentificationModule |
| DefaultAuthentication | Garantit qu’un objet d’authentification est présent dans le contexte. | System.Web.Security.DefaultAuthenticationModule |
| FileAuthorization | Vérifie qu’un utilisateur a l’autorisation d’accéder au fichier demandé. | System.Web.Security.FileAuthorizationModule |
| FormsAuthentication | Prend en charge l’authentification à l’aide de l’authentification par formulaire. | System.Web.Security.FormsAuthenticationModule |
| OutputCache | Prend en charge la mise en cache de sortie. | System.Web.Caching.OutputCacheModule |
| Profil | Gère les profils utilisateur à l’aide du profil ASP.NET, qui stocke et récupère les paramètres utilisateur dans une source de données telle qu’une base de données. | System.Web.Profile.ProfileModule |
| RoleManager | Gère une instance RolePrincipal pour l’utilisateur actuel. | System.Web.Security.RoleManagerModule |
| Session | Prend en charge la maintenance de l’état de session, qui permet le stockage de données spécifiques à un seul client au sein d’une application sur le serveur. | System.Web.SessionState.SessionStateModule |
| UrlAuthorization | Détermine si l’utilisateur actuel est autorisé à accéder à l’URL demandée, en fonction du nom d’utilisateur ou de la liste des rôles dont un utilisateur est membre. | System.Web.Security.UrlAuthorizationModule |
| UrlMappingsModule | Prend en charge le mappage d’une URL réelle à une URL plus conviviale. | System.Web.UrlMappingsModule |
| WindowsAuthentication | Définit l’identité de l’utilisateur pour une application ASP.NET lorsque Authentification Windows est activée. | System.Web.Security.WindowsAuthenticationModule |
Traitement des demandes dans IIS
Dans IIS, les pipelines de requêtes IIS et ASP.NET se combinent pour traiter les demandes avec une approche intégrée. La nouvelle architecture de traitement des demandes se compose d’une liste triée de modules natifs et managés qui effectuent des tâches spécifiques en réponse aux demandes.
Cette conception offre plusieurs avantages par rapport aux versions précédentes d’IIS. Tout d’abord, tous les types de fichiers peuvent utiliser des fonctionnalités qui étaient initialement disponibles uniquement pour le code managé. Par exemple, vous pouvez désormais utiliser l’authentification ASP.NET par formulaire et l’autorisation URL (Uniform Resource Locator) pour les fichiers statiques, les fichiers ASP (Active Server Pages) et tous les autres types de fichiers dans vos sites et applications.
Deuxièmement, cette conception élimine la duplication de plusieurs fonctionnalités dans IIS et ASP.NET. Par exemple, lorsqu’un client demande un fichier managé, le serveur appelle le module d’authentification approprié dans le pipeline intégré pour authentifier le client. Dans les versions précédentes d’IIS, cette même demande passe par un processus d’authentification dans le pipeline IIS et dans le pipeline ASP.NET.
Troisièmement, vous pouvez gérer tous les modules dans un emplacement, au lieu de gérer certaines fonctionnalités dans IIS et certaines dans la configuration ASP.NET. Cela simplifie l’administration des sites et des applications sur le serveur.
Pools d’applications dans IIS
Les pools d’applications séparent les applications par limites de processus pour empêcher une application d’affecter une autre application sur le serveur. Dans IIS 7 et versions ultérieures, les pools d’applications continuent d’utiliser le mode d’isolation des processus de travail IIS 6.0. En outre, vous pouvez désormais spécifier un paramètre qui détermine comment traiter les demandes qui impliquent des ressources managées : mode intégré ou mode Classique.
Remarque
Dans IIS 6.0, le mode d’isolation des processus de travail et le mode d’isolation IIS 5.0 sont définis au niveau du serveur. Cela rend impossible l’exécution des deux modes d’isolation sur le même serveur. Toutefois, dans IIS 7 et versions ultérieures, le mode intégré et le mode Classique sont définis au niveau du pool d’applications, ce qui vous permet d’exécuter des applications simultanément dans des pools d’applications avec différents modes de processus sur le même serveur.
Mode de pool d’applications intégré
Lorsqu’un pool d’applications est en mode intégré, vous pouvez tirer parti de l’architecture de traitement des demandes intégrée d’IIS et de ASP.NET. Lorsqu’un processus de travail dans un pool d’applications reçoit une demande, la demande passe par une liste ordonnée d’événements. Chaque événement appelle les modules natifs et managés nécessaires pour traiter les parties de la demande et générer la réponse.
Il existe plusieurs avantages pour exécuter des pools d’applications en mode intégré. Tout d’abord, les modèles de traitement des demandes d’IIS et de ASP.NET sont intégrés à un modèle de processus unifié. Ce modèle élimine les étapes précédemment dupliquées dans IIS et ASP.NET, telles que l’authentification. En outre, le mode intégré permet la disponibilité des fonctionnalités managées pour tous les types de contenu.
Mode pool d’applications classique
Lorsqu’un pool d’applications est en mode Classique, IIS 7 et versions ultérieures gèrent les requêtes de la même façon que dans le mode d’isolation des processus de travail IIS 6.0. ASP.NET les requêtes passent d’abord par des étapes de traitement natives dans IIS, puis sont routées vers Aspnet_isapi.dll pour le traitement du code managé dans le runtime managé. Enfin, la demande est routée via IIS pour envoyer la réponse.
Cette séparation des modèles iis et ASP.NET de traitement des demandes entraîne la duplication de certaines étapes de traitement, telles que l’authentification et l’autorisation. En outre, les fonctionnalités de code managé, telles que l’authentification par formulaire, sont uniquement disponibles pour ASP.NET applications ou applications pour lesquelles vous avez mappé toutes les requêtes à gérer par aspnet_isapi.dll.
Veillez à tester vos applications existantes pour la compatibilité en mode intégré avant de mettre à niveau un environnement de production vers IIS 7 et versions ultérieures et d’affecter des applications aux pools d’applications en mode intégré. Vous devez uniquement ajouter une application à un pool d’applications en mode Classique si l’application ne parvient pas à fonctionner en mode intégré. Par exemple, votre application peut s’appuyer sur un jeton d’authentification passé d’IIS au runtime managé et, en raison de la nouvelle architecture dans IIS 7 et versions ultérieures, le processus interrompt votre application.
Traitement des requêtes HTTP dans IIS
IIS 7 et versions ultérieures ont un flux de traitement des requêtes HTTP similaire à IIS 6.0. Les diagrammes de cette section fournissent une vue d’ensemble d’une requête HTTP en cours.
La liste suivante décrit le flux de traitement des demandes présenté dans la figure 1 :
- Lorsqu’un navigateur client lance une requête HTTP pour une ressource sur le serveur Web, HTTP.sys intercepte la requête.
- HTTP.sys contacte WAS pour obtenir des informations à partir du magasin de configuration.
- WAS demande des informations de configuration à partir du magasin de configuration, applicationHost.config.
- Le service WWW reçoit des informations de configuration, telles que le pool d’applications et la configuration du site.
- Le service WWW utilise les informations de configuration pour configurer HTTP.sys.
- WAS démarre un processus de travail pour le pool d’applications auquel la demande a été effectuée.
- Le processus de travail traite la requête et retourne une réponse à HTTP.sys.
- Le client reçoit une réponse.
Figure 1 : Vue d’ensemble d’une requête HTTP
Dans un processus de travail, une requête HTTP passe par plusieurs étapes ordonnées, appelées événements, dans Web Server Core. À chaque événement, un module natif traite une partie de la requête, comme l’authentification de l’utilisateur ou l’ajout d’informations au journal des événements. Si une demande nécessite un module managé, le module ManagedEngine natif crée un AppDomain, où le module managé peut effectuer le traitement nécessaire, comme l’authentification d’un utilisateur avec l’authentification par formulaire. Lorsque la requête passe par tous les événements dans Web Server Core, la réponse est retournée à HTTP.sys. La figure 2 ci-dessous montre une requête HTTP entrant dans le processus de travail.
Figure 2 : Détail d’une requête HTTP à l’intérieur du processus de travail