Est-ce que IIS 7.5 utilise un "AppDomain" distinct pour chaque sous-domaine?
Dans un processus de travail IIS, séparez des sites (par exemple, des domaines) exécutés dans leur propre domaine d'application .
J'ai un site example.com qui possède un enregistrement DNS générique (c.-à-d. *.example.com pointé sur une adresse IP.) Le traitement d'une ressource de sous-domaine z.example.com sera-t-il isolé dans un domaine distinct du traitement des demandes de www.abc.com? Je pense que la réponse doit être oui, mais je ne trouve rien de définitif
Non, je dirige plusieurs sites comme celui-ci. La liaison détermine quelle application prend les demandes et chaque application ne peut avoir qu'un seul pool d'applications. Un pool d'applications peut utiliser plusieurs processus (un jardin Web), mais cela n'a aucun lien avec les noms de domaine génériques (même un seul domaine est divisé en plusieurs processus dans ce scénario).
Un domaine d'application (une construction de sécurité au sein de .Net) isole les applications les unes des autres. Chaque application ne reçoit qu'un seul domaine d'application par processus, quel que soit le nombre de domaines qui y sont liés. Même en l'absence de DNS générique, si deux domaines complètement distincts sont liés à la même application, tels que www.abc.com et foo.xyz.net, ils sont tous deux gérés par le même domaine d'application dans la même application et dans le même processus. ) dans le même pool d'applications.
Voici un aperçu de la manière dont une demande entrante est traitée par IIS (en ignorant les filtres ISAPI, la réécriture d'URL, etc.), tirés de 15 années de recherche et d'expérience sur deux grandes applications multi-domaines sur IIS 5-8.5:
L'adresse IP et le numéro de port de la demande entrante (provenant de l'interface réseau) vérifient s'il existe un certificat SSL (TLS) lié au port. Si tel est le cas, la négociation SSL (TLS) commence. Cela se produit avant que IIS ne voie jamais la demande, car cette partie est gérée par le système d'exploitation lui-même. Les versions plus récentes de TLS peuvent autoriser le sniff du nom d’hôte (qui est envoyé dans les en-têtes d’une requête HTTP ou HTTPS) afin que différents certificats puissent être utilisés pour le chiffrement, même sur la même adresse IP et le même port. L’interface de gestion IIS permet d’afficher la configuration des certificats comme s’ils faisaient partie d’IIS, mais ce n’est pas le cas.
Ensuite, IIS reçoit la demande HTTP ou HTTPS du système d'exploitation. IIS examine les liaisons de chaque site (parfois appelé site Web par IIS outils) et recherche toutes les adresses dont l'adresse IP et le port correspondent. S'il en existe plusieurs, choisissez celui dont le nom d'hôte correspond (utilisez l'en-tête Host dans la requête, que le navigateur renseigne avec le nom d'hôte figurant dans l'URL). Le nom d'hôte ne peut pas contenir de caractères génériques. L'interface de gestion IIS ne les autorisera pas (même si vous pouvez les définir à l'aide d'outils de ligne de commande, ils ne fonctionneront probablement pas comme vous le pensez de toute façon. pour les éviter pour le moment). L’interface de gestion IIS ne vous permet pas de créer plusieurs liaisons avec les mêmes informations (bien que les outils de ligne de commande permettent parfois de laisser passer des choses comme celle-ci et que les résultats ne sont pas définis). Un site n'est en réalité qu'une structure organisationnelle dans IIS. Comme une liaison, il contient des informations de configuration, mais il n'y a pas de code directement associé à un site - le chemin spécifié dans la configuration du site est réellement le chemin de l'application par défaut du site.
Maintenant que le site a été déterminé, IIS doit décider à quelle application envoyer la demande. Lorsqu'un site est créé, une application par défaut est également créée pour le site. IIS commence par rechercher les applications autres que les applications par défaut sur le site. Chacune de ces applications sera identifiée de manière unique par un chemin (l'application par défaut n'a pas de chemin ou a le chemin "racine"). Si le chemin correspond au début de l'URL entrante, cette application est sélectionnée et le site correspondant le plus spécifique (le plus détaillé) est sélectionné. Si aucune application autre que celle par défaut ne correspond, c'est l'application par défaut qui est sélectionnée.
Maintenant que l'application a été déterminée, IIS doit gérer la demande directement ou l'acheminer de manière ou d'autre à l'application. Si la demande concerne un fichier statique et que vous n'avez pas system.webServer/modules/@runAllManagedModulesForAllRequests= "true" défini dans le fichier web.config de l'application, IIS (ou peut-être ASP.NET dans IIS) renvoie simplement le contenu du fichier avec le type de contenu approprié. Si la demande ne concerne pas un fichier statique (ou que vous avez défini le script web.config pour router toutes les demandes via votre code), IIS recherche le pool d'applications (ou le pool d'applications comme outils de ligne de commande). reportez-vous) le site est configuré pour utiliser. Il transmet ensuite la demande à votre code d'application dans un processus sélectionné de manière aléatoire (ou peut-être à tour de rôle) dans le "jardin Web" de ce pool d'applications. Le jardin Web par défaut ne comporte qu'un processus. (IIS lui-même n'utilise jamais le terme "jardin Web", mais il est utilisé dans les billets de blog par IIS membres de l'équipe - Consultez le paramètre "Nombre maximal de processus de travail" dans les paramètres du pool d'applications. ce qui contrôle le nombre de processus dans le jardin).
Dans le processus du jardin Web, chaque site réside dans son propre AppDomain (il s'agit d'un terme .NET faisant référence à un bac à sable au sein d'un processus .NET, bien qu'il soit souvent utilisé à tort pour désigner un IIS 'Site'. et le terme 'domaine d'application' est aussi parfois utilisé pour cela, bien que je n'ai jamais vu ce terme utilisé dans l'interface de gestion IIS ou dans les outils de ligne de commande). En raison du fonctionnement de AppDomains, chaque instance du site (chacune dans un processus différent du jardin Web) obtient ses propres variables statiques. Le code de votre site est libre de créer plus d'AppDomains en fonction des besoins, mais cela dépend de vous. IIS n'en crée qu'un dans chaque processus de jardin Web (pool d'applications). Techniquement, le service 'World Wide Web' transmet probablement la demande au processus de pool d'applications (w3wp.exe). Ce processus détermine le site et AppDomain auquel transmettre la demande, mais il s'agit d'un détail d'implémentation masqué par IIS, car le service 'World Wide Web' et le processus w3wp.exe font partie d'IIS. W3wp pourrait examiner les en-têtes à ce stade pour voir quel nom d'hôte a été spécifié et appeler un AppDomain différent pour chaque nom d'hôte unique à ce stade, mais ce n'est pas le cas - cela ralentirait simplement les choses. La demande peut même ne pas avoir de nom d’hôte, car elle n’aurait pu entrer qu’avec une adresse IP.
Une fois que nous arrivons à ce point, le cycle de vie de l'application ASP.NET prend le relais, mais cela n'a aucune pertinence pour votre question.
Notez que, lorsque votre demande suit ce processus, différents noms d’hôte peuvent les amener à accéder à AppDomains distincts dans des applications distinctes, mais ils ne le seront pas également, à moins que vous n'écriviez spécifiquement le code vous-même pour créer ces AppDomains et route. les demandes là-bas.