Comparaison du processus de traitement des requêtes ASP.net d'IIS5 IIS6 IIS7 (1)

ASP.NET est une plate-forme très puissante pour créer des applications Web. Elle offre une grande flexibilité et des fonctionnalités afin que vous puissiez l'utiliser pour créer tous les types d'applications Web.

La plupart des gens ne connaissent que les frameworks de haut niveau tels que WebForms et WebServices, qui se situent au sommet de la hiérarchie ASP.NET.

Les informations contenues dans cet article sont collectées et compilées à partir de divers documents publics Microsoft. En comparant les processus de traitement des requêtes des trois générations d'IIS, IIS5, IIS6 et IIS7, nous pouvons nous familiariser avec le mécanisme sous-jacent d'ASP.NET et comprendre comment les requêtes sont traitées à partir du Web. Le serveur communique avec le runtime ASP.NET. En comprenant le mécanisme sous-jacent, nous pouvons avoir une compréhension plus approfondie d’ASP.net.

Une fonctionnalité notable d'IIS 5.x est la séparation du serveur Web et de la véritable application ASP.NET. En tant que serveur Web, IIS s'exécute sur un processus appelé InetInfo.exe. InetInfo.exe est un exécutif natif et n'est pas un programme géré. Notre véritable application ASP.NET s'exécute sur un processus de travail appelé aspnet_wp. le processus est initialisé, il s’agit donc d’un environnement géré.

ISAPI : fait référence aux applications capables de gérer différents suffixes. ISAPI est l'abréviation des mots suivants : Internet Server Application Programe Interface, Internet Server Application Programe Interface.

1. Premièrement, un seul processus aspnet_wp peut être exécuté sur le même hôte en même temps. Chaque application ASP.NET basée sur le répertoire virtuel correspond à un domaine d'application, ce qui signifie que chaque application s'exécute sur le même hôte. idem Dans Worker Process, l'isolation entre les applications est basée sur le domaine d'application et non sur le processus.

2. Deuxièmement, ASP.NET ISAPI est non seulement responsable de la création du processus de travail aspnet_wp, mais également de la surveillance du processus. S'il est détecté que les performances d'aspnet_wp chutent à une certaine limite inférieure définie, ASP.NET ISAPI sera responsable. pour mettre fin au processus. Lorsque aspnet_wp se termine, la requête suivante amènera ASP.NET ISAPI à recréer un nouveau processus de travail aspnet_wp.

3. Enfin, étant donné qu'IIS et Application s'exécutent dans leurs propres processus, la communication entre eux doit utiliser un mécanisme de communication spécifique. Essentiellement, la communication entre le processus InetInfo où se trouve IIS et le processus de travail est une communication entre différents processus sur la même machine (communications interprocessus locales) Pour des raisons de performances, un mécanisme de communication basé sur un canal nommé est utilisé entre eux. La communication entre ASP.NET ISAPI et Worker Process est implémentée via un ensemble de tuyaux entre eux. Également pour des raisons de performances, ASP.NET ISAPI transmet la requête au processus de travail de manière asynchrone et obtient la réponse, mais le processus de travail obtient certaines variables basées sur le serveur à partir d'ASP.NET ISAPI de manière synchrone.

IIS 5.x surveille Request via InetInfo.exe et distribue Request to Work Process. En d'autres termes, la surveillance et la distribution des requêtes dans IIS 5. : http.sys est responsable.

Remarque : Afin d'empêcher les applications utilisateur d'accéder ou de modifier les données critiques du système d'exploitation, Windows propose deux modes d'accès au processeur : le mode utilisateur et le mode noyau. Généralement, les programmes utilisateur s'exécutent en mode utilisateur, tandis que le code du système d'exploitation s'exécute en mode noyau. Le code du mode noyau permet d'accéder à toute la mémoire système et à toutes les instructions du processeur.

En mode utilisateur, http.sys reçoit une requête http basée sur aspx, puis il vérifiera à quel pool d'applications appartient l'application basée sur la requête en fonction de la métabase dans IIS. Si le pool d'applications n'existe pas, créez-le. Dans le cas contraire, la requête est envoyée directement dans la Queue correspondant au Pool d'Applications.

Chaque pool d'applications correspond à un Worker Process : w3wp.exe, qui s'exécute sans aucun doute en mode utilisateur. Le mappage du pool d'applications et du processus de travail est conservé dans la métabase IIS. Sur la base d'un tel mappage, WAS (service d'administration Web) transmet la requête qui existe dans une file d'attente du pool d'applications au processus de travail correspondant (sinon, créez un tel processus). Lorsque le processus de travail est initialisé, ASP.NET ISAPI est chargé et ASP.NET ISAPI charge ensuite le CLR. Le processus final est le même que celui d'IIS 5.x : créez un domaine d'application pour l'application via la méthode Create d'AppManagerAppDomainFactory ; traitez la demande via ProcessRequest d'ISAPIRuntime, puis entrez le processus dans le pipeline d'exécution HTTP ASP.NET.