IIS 5 und 6 funktionieren unterschiedlich.
Wenn eine Anfrage eingeht, überprüft IIS die Skriptzuordnung (Erweiterungszuordnung) und leitet die Anfrage an aspnet_isapi.dll weiter. Der Betrieb dieser DLL und die Art und Weise, wie Anforderungen in die ASP.NET-Laufzeit gelangen, unterscheiden sich in IIS5 und 6. Abbildung 2 zeigt einen groben Überblick über diesen Prozess.
In IIS5 wird aspnet_isapi.dll direkt im inetinfo.exe-Prozess gehostet. Wenn Sie die Isolationsstufe der Website oder des virtuellen Verzeichnisses auf „Mittel“ oder „Hoch“ festlegen, wird sie in einem separaten (isolierten) Arbeitsprozess von IIS gehostet. Wenn die erste ASP.NET-Anfrage eingeht, startet die DLL (aspnet_isapi.dll) einen weiteren neuen Prozess aspnet_wp.exe und leitet die Anfrage zur Verarbeitung an diesen Prozess weiter. Dieser Prozess wiederum lädt und hostet die .NET-Laufzeitumgebung. Jede an die ISAPI-DLL weitergeleitete Anfrage wird über einen Named-Pipe-Aufruf an diesen Prozess weitergeleitet.
Abbildung 2 – Eine allgemeine Ansicht des Anforderungsflusses von IIS zur ASP.NET-Laufzeit und durch die Anforderungsverarbeitungspipeline. IIS5 und IIS6 interagieren auf unterschiedliche Weise mit ASP.NET, aber sobald die Anforderung an die ASP.NET-Pipeline gelangt, ist der gesamte Verarbeitungsablauf derselbe.
Im Gegensatz zu früheren Versionen des Servers wurde IIS6 vollständig für ASP.NET optimiert.
IIS6 – Es lebe der Anwendungspool
IIS6 nimmt erhebliche Änderungen am Verarbeitungsmodell vor. IIS hostet externen ausführbaren Code wie ISAPI-Erweiterungen nicht mehr direkt. IIS erstellt immer einen separaten Arbeitsthread – einen Anwendungspool – und die gesamte Verarbeitung erfolgt in diesem Prozess, einschließlich der Ausführung von ISAPI-DLLs. Das Anwendungspooling ist eine große Verbesserung in IIS6, da es eine sehr detaillierte Kontrolle darüber ermöglicht, welcher Code in einem bestimmten Thread ausgeführt wird. Anwendungspools können auf jedem virtuellen Pfad oder auf der gesamten Website konfiguriert werden, sodass Sie jede Webanwendung in einem eigenen Prozess isolieren können, sodass jede Anwendung mit anderen Webanwendungen verbunden ist, die auf demselben Computer ausgeführt werden. Anwendungen sind vollständig isoliert. Wenn ein Prozess abstürzt, hat dies keine Auswirkungen auf andere Prozesse (zumindest aus Sicht der Webverarbeitung).
Darüber hinaus sind Anwendungspools in hohem Maße konfigurierbar. Sie können die Sicherheitsumgebung, in der Pools ausgeführt werden, konfigurieren, indem Sie deren Ausführungsidentitätsebene festlegen. Dadurch können Sie die einer Webanwendung gewährten Berechtigungen anpassen (auch hier mit sehr feiner Granularität). Eine große Verbesserung für ASP.NET besteht darin, dass der Anwendungspool die meisten Einstellungen im Abschnitt „ProcessModel“ in der Datei „machine.config“ überschreibt. Die Einstellungen in diesem Abschnitt sind in IIS5 sehr schwierig zu verwalten, da diese Einstellungen global sind und nicht in der web.config-Datei der Anwendung überschrieben werden können. Beim Ausführen von IIS6 werden ProcessModel-bezogene Einstellungen größtenteils ignoriert und stattdessen aus dem Anwendungspool gelesen. Beachten Sie, dass die meisten davon hier erwähnt werden – einige Einstellungen, wie die Größe des Thread-Pools und die Einstellungen des IO-Threads, werden immer noch aus machine.config gelesen, da sie keine entsprechenden Elemente in den Thread-Pool-Einstellungen haben.
Da es sich bei Anwendungspools um externe ausführbare Dateien handelt, können diese ausführbaren Dateien problemlos überwacht und verwaltet werden. IIS6 bietet eine Reihe von Systemstatusprüfungen, Neustarts und Timeout-Optionen, mit denen sich Programmprobleme in vielen Fällen problemlos überprüfen und sogar beheben lassen.
Schließlich ist derAnwendungspool
von IIS6 nicht wie der Isolationsmodus von IIS5 auf COM+ angewiesen. Dies kann die Leistung verbessern und die Stabilität verbessern (insbesondere für einige interne Anwendungen, die COM-Komponenten aufrufen müssen).
sind stark für HTTP-Operationen optimiert. Sie kommunizieren direkt mit dem Kernel-Modus-HTTP.SYS-Treiber. Empfangene Anfragen werden direkt an den entsprechenden Anwendungspool weitergeleitet. InetInfo ist im Grunde nur ein Hypervisor und ein Konfigurationsserver – der Großteil der Interaktion findet tatsächlich direkt zwischen HTTP.SYS und dem Anwendungspool statt, was IIS6 zu einer stabileren und effizienteren Umgebung als IIS5 macht. Dies gilt insbesondere für statische Inhalte und ASP.NET-Anwendungen.
Ein IIS6-Anwendungspool verfügt über ein angeborenes Verständnis von ASP.NET und kann mit ihm über die zugrunde liegende API interagieren. Dadurch kann das Caching auf ASP.NET-Ebene direkt an den Webserver übermittelt werden.
In IIS6 werden ISAPI-Erweiterungen im Arbeitsprozess des Anwendungspools ausgeführt. Die .NET-Laufzeit läuft ebenfalls im selben Prozess, sodass die Kommunikation zwischen der ISAPI-Erweiterung und der .NET-Laufzeit innerhalb des Prozesses erfolgt. Dies hat einen natürlichen Leistungsvorteil gegenüber der von IIS5 verwendeten Named Pipe. Obwohl das Hosting-Modell von IIS sehr unterschiedlich ist, ist die Schnittstelle zum verwalteten Code überraschend ähnlich – nur der Prozess der Nachrichtenweiterleitung unterscheidet sich geringfügig.