Vergleich des ASP.net-Anforderungsverarbeitungsprozesses von IIS5 IIS6 IIS7 (1)

ASP.NET ist eine sehr leistungsstarke Plattform zum Erstellen von Webanwendungen. Sie bietet große Flexibilität und Funktionen, sodass Sie damit alle Arten von Webanwendungen erstellen können.

Die meisten Menschen sind nur mit High-Level-Frameworks wie WebForms und WebServices vertraut – diese stehen an der Spitze der ASP.NET-Hierarchie.

Die Informationen in diesem Artikel wurden aus verschiedenen öffentlichen Dokumenten von Microsoft gesammelt und zusammengestellt. Durch den Vergleich der Anforderungsverarbeitungsprozesse der drei Generationen von IIS, IIS5, IIS6 und IIS7 können wir uns mit dem zugrunde liegenden Mechanismus von ASP.NET vertraut machen und verstehen, wie Anfragen werden aus dem Web verarbeitet. Der Server kommuniziert mit der ASP.NET-Laufzeit. Durch das Verständnis des zugrunde liegenden Mechanismus können wir ein tieferes Verständnis von ASP.net erlangen.

Ein bemerkenswertes Merkmal von IIS 5.x ist die Trennung von Webserver und echter ASP.NET-Anwendung. Als Webserver läuft IIS auf einem Prozess namens InetInfo.exe und ist kein verwaltetes Programm. Unsere echte ASP.NET-Anwendung wird auf einem Worker-Prozess namens aspnet_wp ausgeführt Der Prozess wird initialisiert, es handelt sich also um eine verwaltete Umgebung.

ISAPI: bezieht sich auf Anwendungen, die verschiedene Suffixe verarbeiten können. ISAPI ist die Abkürzung der folgenden Wörter: Internet Server Application Programe Interface, Internet Server Application Programming Interface.

1. Erstens kann nur ein aspnet_wp-Prozess gleichzeitig auf demselben Host ausgeführt werden. Jede auf dem virtuellen Verzeichnis basierende ASP.NET-Anwendung entspricht einer Anwendungsdomäne, was bedeutet, dass jede Anwendung auf demselben Host ausgeführt wird Gleiches gilt: Im Worker-Prozess basiert die Isolierung zwischen Anwendungen auf der Anwendungsdomäne und nicht auf dem Prozess.

2. Zweitens ist ASP.NET ISAPI nicht nur für die Erstellung des aspnet_wp-Arbeitsprozesses verantwortlich, sondern auch für die Überwachung des Prozesses. Wenn festgestellt wird, dass die Leistung von aspnet_wp auf eine bestimmte festgelegte Untergrenze fällt, ist ASP.NET ISAPI verantwortlich für die Beendigung des Prozesses. Wenn aspnet_wp endet, führt eine nachfolgende Anfrage dazu, dass ASP.NET ISAPI einen neuen aspnet_wp-Arbeitsprozess neu erstellt.

3. Da IIS und Anwendung schließlich in ihren eigenen Prozessen ausgeführt werden, muss die Kommunikation zwischen ihnen einen bestimmten Kommunikationsmechanismus verwenden. Im Wesentlichen handelt es sich bei der Kommunikation zwischen dem InetInfo-Prozess, auf dem sich IIS befindet, und dem Worker-Prozess um die Kommunikation zwischen verschiedenen Prozessen auf demselben Computer (lokale Interprozesskommunikation). Aus Leistungsgründen wird zwischen ihnen ein auf Named Pipe basierender Kommunikationsmechanismus verwendet. Die Kommunikation zwischen ASP.NET ISAPI und Worker Process wird über eine Reihe von Pipes zwischen ihnen implementiert. Auch aus Leistungsgründen überträgt ASP.NET ISAPI die Anfrage asynchron an den Worker-Prozess und erhält die Antwort, aber der Worker-Prozess ruft einige serverbasierte Variablen synchron von ASP.NET ISAPI ab.

IIS 5.x überwacht Request über InetInfo.exe und verteilt Request to Work Process. Mit anderen Worten: Für die Überwachung und Verteilung von Anfragen in IIS 5 ist http.sys verantwortlich.

Hinweis: Um zu verhindern, dass Benutzeranwendungen auf kritische Betriebssystemdaten zugreifen oder diese ändern, bietet Windows zwei Prozessorzugriffsmodi: Benutzermodus und Kernelmodus. Im Allgemeinen werden Benutzerprogramme im Benutzermodus ausgeführt, während Betriebssystemcode im Kernelmodus ausgeführt wird. Der Code des Kernel-Modus ermöglicht den Zugriff auf den gesamten Systemspeicher und alle CPU-Anweisungen.

Im Benutzermodus empfängt http.sys eine ASPX-basierte HTTP-Anfrage und prüft dann, zu welchem ​​Anwendungspool die auf der Anfrage basierende Anwendung gemäß der Metabasis in IIS gehört. Wenn der Anwendungspool nicht vorhanden ist, erstellen Sie ihn. Andernfalls wird die Anfrage direkt an die Warteschlange gesendet, die dem Anwendungspool entspricht.

Jeder Anwendungspool entspricht einem Arbeitsprozess: w3wp.exe, der zweifellos im Benutzermodus ausgeführt wird. Die Zuordnung von Anwendungspool und Arbeitsprozess wird in der IIS-Metabasis verwaltet. Basierend auf einer solchen Zuordnung leitet WAS (Web Administrative Service) die in einer Anwendungspoolwarteschlange vorhandene Anforderung an den entsprechenden Arbeitsprozess weiter (falls nicht, erstellen Sie einen solchen Prozess). Wenn der Arbeitsprozess initialisiert wird, wird ASP.NET ISAPI geladen und ASP.NET ISAPI lädt dann die CLR. Der letzte Prozess ist derselbe wie bei IIS 5.x: Erstellen Sie eine Anwendungsdomäne für die Anwendung über die Create-Methode von AppManagerAppDomainFactory; verarbeiten Sie die Anforderung über ProcessRequest von ISAPIRuntime und geben Sie den Prozess dann in die ASP.NET-HTTP-Laufzeitpipeline ein.