17.4 Kurzer Überblick über die Architektur des Webservers

Über die Architektur von komplexen Serversystemen kann man natürlich viele Seiten schreiben. Das möchte ich hier bewusst nicht tun, es gibt aber einige Fakten, die Sie einfach über den IIS wissen sollten. Weiterhin gibt es auch für diejenigen, die sich bereits mehr oder weniger intensiv mit dem Vorgänger-IIS beschäftigt haben, das ein oder andere Neue zu entdecken: Oder wissen Sie aus dem Stand, was der Windows-Prozessaktivierungsdienst tut?

17.4.1 Architektur

In Abbildung 17.18 ist die Architektur des Internet Information Servers zu sehen:

• http.sys ist der im Kernelmodus ausgeführte Protokolllistener. Sämtliche HTTP-Anforderungen gehen hier ein. Dies gilt übrigens auch für HTTPS-Anforderungen.
• Der WWW-Publishing-Dienst (W3SVC) verwaltet bzw. steuert die http.sys und ist für die Leistungsüberwachung zuständig.
• Der Windows-Prozessaktivierungsdienst (WAS) verwaltet die Arbeitsprozesse. Er startet und beendet die Anwendungspools.
• Im Konfigurationsspeicher werden die Einstellungen sowohl für den IIS als auch für ASP.NET gespeichert. Im Gegensatz zum IIS6 und dessen Metabase gibt es nicht eine zentrale Konfigurationsdatenbank, sondern es existiert eine Hierarchie aus verteilten XML-Dateien.
• Arbeitsprozess (w3wp.exe): Dieser Prozess verarbeitet die Anforderungen und generiert Antworten. Es können mehrere Arbeitsprozesse pro Anwendungspool existieren.

Abbildung 17.18 Architektur des IIS7/8-Webservers

17.4.2 Anforderungsverarbeitung

Die Funktion der einzelnen Bausteine ist natürlich nur sehr grob umrissen worden, etwas »mehr Leben« lässt sich dem Ganzen einhauchen, wenn man das Zusammenspiel anschaut oder – etwas wissenschaftlicher – gesprochen »die Anforderungsverarbeitung analysiert«. In Abbildung 17.19 sind die einzelnen Schritte eingetragen:

• Schritt 1: Die vom Client eingehende HTTP-Anforderung wird von http.sys entgegengenommen.
• Im Schritt 2 gibt es nun zwei Varianten:
  • Falls http.sys über die Konfigurationsinformationen für die Webanwendung verfügt, an die die Anforderung gerichtet ist, wird die Anforderung an den entsprechenden Arbeitsprozess weitergeleitet – und gelangt somit direkt zu Schritt 7.
  • Verfügt http.sys nicht über die Konfigurationsinformationen, wird der WWW-Publishing-Dienst kontaktiert, der wiederum den Windows-Prozessaktivierungsdienst (WAS) bemüht.
• Schritt 3: Der WAS ruft die Konfiguration aus dem Konfigurationsspeicher ab (application-host.config).
• Schritt 4: Der WAS prüft, ob innerhalb des für die Webanwendung zuständigen Anwendungspools bereits ein Arbeitsprozess läuft. Ist dieser nicht vorhanden, wird er gestartet.
• Schritt 5: Der WAS übergibt die Konfiguration (Anwendungspool- und Anwendungskonfiguration) an den WWW-Publishing-Dienst.
• Schritt 6: Der WWW-Publishing-Dienst passt, aufgrund der vom WAS übergebenen Konfigurationsinformationen, die Konfiguration von http.sys an.

  

  Abbildung 17.19 Die HTTP-Anforderungsverarbeitung

• Schritt 7: http.sys leitet die Anforderung an den Arbeitsprozess weiter.
• Schritt 8: Die Anforderungsverarbeitungspipeline wird von http.sys initiiert. Das Ergebnis ist eine Antwort auf die Webanforderung.
• Schritt 9: http.sys sendet das Ergebnis an den Client.

Man kann dem IIS übrigens recht komfortabel unter die Haube schauen, zumindest ein bisschen. Im Internetinformationsdienste-Manager steht ein Dialog zur Anzeige der aktiven Arbeitsprozesse zur Verfügung (Abbildung 17.20). Es gibt sogar noch eine detaillierte Anzeigemöglichkeit: Im Kontextmenü des jeweiligen Arbeitsprozesses existiert der Menüpunkt Aktuelle Anforderungen anzeigen. Sie werden beim »Selbst-Testen« erkennen, dass für jeden Anwendungspool, in dem eine Webanwendung gestartet wurde, ein oder mehrere Arbeitsprozesse gestartet worden sind. Wenn Sie die schematische Darstellung der HTTP-Anforderungsverarbeitung in Abbildung 17.19 konsultieren, ist das auch sofort verständlich.

Abbildung 17.20 Laufende Arbeitsprozesse können im Internetinformationsdienste-Manager angezeigt werden.

17.4.3 Anforderungsverarbeitung im Anwendungspool

Wenn Sie den Vor-Vorgänger, also IIS6 einigermaßen gut kennen, wird Ihnen in den Grundeinstellungen der Anwendungspools aufgefallen sein, dass Sie einen Verwalteten Pipelinemodus auswählen können (Abbildung 17.21). Richtig, hier geht es um die Verarbeitung von ASP.NET-Anfragen, die naturgemäß im IIS-Umfeld eine besonders wichtige Rolle spielen.

Um es gleich vorwegzunehmen: Wenn es nicht irgendwelche mehr oder weniger mysteriösen Kompatibilitätsprobleme im integrierten Modus gibt, sollten Sie diesen auswählen. Trotzdem kann es sicherlich nicht schaden, die beiden Modi ein wenig genauer anzuschauen.

Abbildung 17.21 Für die ASP.NET-Anforderungsverarbeitung in einem Anwendungspool können Sie zwischen zwei Pipelinemodi wählen.

Der klassische Modus

Die Vorteile des integrierten Modus lassen sich besonders einfach vermitteln, wenn man mit der Abarbeitung im klassischen Modus beginnt. Der klassische Modus ist aus Gründen der Abwärtskompatibilität vorhanden, denn es könnte durchaus ASP.NET-Anwendungen geben, die in dem modernen integrierten Modus nicht lauffähig sind.

In Abbildung 17.22 sehen Sie die (etwas verkürzte) Darstellung der Anforderungsverarbeitung im klassischen Modus. Die wesentlichen Aspekte:

• Im Arbeitsprozess wird eine Authentifizierung durchgeführt.
• Bei der Handlerausführung wird bestimmt, ob die Anforderung durch ASP.NET verarbeitet werden muss. Dies ist beispielsweise bei dem Aufruf von *.aspx oder *.asmx der Fall.
• Es wird dann die ASP.NET-ISAPI-Erweiterung aufgerufen, die sich unter anderem wieder um die Authentifizierung kümmern muss.
• Nach Abschluss der ASP.NET-Verarbeitung in der ISAPI-Erweiterung wird die Weiterverarbeitung wieder an den Arbeitsprozess zurückgereicht.

Es ergeben sich folgende Einschränkungen bzw. Nachteile:

• Von ASP.NET-Modulen bereitgestellte Funktionen sind für Nicht-ASP.NET-Anforderungen nicht verfügbar. Ein klassisches Beispiel ist die formularbasierte Authentifizierung.
• Es werden Verarbeitungsschritte doppelt ausgeführt. Wie Sie in Abbildung 17.22 sehen, trifft dies beispielsweise für die Authentifizierung zu.
• Die ASP.NET-Anwendungen können keinen Einfluss auf die sonstige IIS-Anforderungsverarbeitung nehmen. Das ist bei Betrachtung der Abbildung ebenfalls völlig einleuchtend, denn die ASP.NET-Verarbeitung erfolgt außerhalb der Verarbeitung im Arbeitsprozess.
• Etliche Einstellungen müssen sowohl für den Arbeitsprozess als auch für die ASP.NET-ISAPI-Erweiterung gespeichert werden, beispielsweise die Authentifizierung.

Abbildung 17.22 Die Anforderungsverarbeitung im klassischen Modus

Der integrierte Modus

Wenn Sie jetzt, mit dem soeben erworbenen Wissen über den klassischen Modus im Hinterkopf, raten müssten, was der Unterschied zwischen dem klassischen und dem integrierten Modus ist, würden Sie ohne Schwierigkeiten einen Treffer landen: Die ASP.NET-Verarbeitung ist nun nicht mehr in einer ISAPI-Erweiterung »ausgelagert«, sondern findet im Arbeitsprozess statt. Dies ist in Abbildung 17.23 zu erkennen. Die Skizze zeigt aber noch einen weiteren Aspekt:

• Bei der klassischen Anforderungsverarbeitung stehen im Arbeitsprozess bei der Authentifizierung lediglich die Standard-, die Windows- und die anonyme Authentifizierung zur Verfügung. Die in ASP.NET enthaltene Formular-Authentifizierung ist nicht vorhanden bzw. kann erst bei der ASP.NET-Verarbeitung in der ISAPI-Erweiterung angewendet werden.
• Die integrierte Anforderungsverarbeitung ermöglicht hingegen, dass die Formular-Authentifizierung im Rahmen der IIS-Anforderungsverarbeitung genutzt werden kann. Sie wird sozusagen gleichberechtigt mit den nativen IIS-Modulen eingesetzt.

Abbildung 17.23 Die Verarbeitungspipeline bei der integrierten Verarbeitung

Um nochmals auf die Vorteile des integrierten Modus zu sprechen zu kommen: Man kann sagen, dass die im vorherigen Abschnitt aufgeführten Nachteile des klassischen Modus allesamt behoben sind:

• Alle Anfordungen – egal ob ASP.NET, statische Dateien, ASP oder CGI – können alle Features des IIS und der ASP.NET-Welt (»verwaltet«) nutzen.
• Es gibt keine doppelt vorhandenen Features.
• Die Verwaltung erfolgt an einem Ort.
• Entwickler können den IIS mit ASP.NET-Modulen erweitern und mit diesen auch recht weitgehend in die Anforderungsverarbeitung eingreifen.

Reihenfolge der Verarbeitung

In den vorherigen Skizzen zur Anforderungsverarbeitung haben Sie gesehen, dass der Arbeitsprozess diverse Module in einer bestimmten Reihenfolge abarbeitet. Die Reihenfolge ist natürlich ganz entscheidend, denn es hätte beispielsweise wenig Sinn, zuerst die Module zur Autorisierung aufzurufen und erst danach die Authentifizierung durchzuführen: Was soll man autorisieren, wenn man gar nicht weiß, wer vor dem Browser sitzt?

Abbildung 17.24 In dieser Reihenfolge werden die Module in der Verarbeitungspipeline abgearbeitet. Bei Bedarf kann die Reihenfolge angepasst werden. Wenn Sie aber nicht ganz genau wissen, was Sie tun, ist das keine gute Idee!

Die Abarbeitungsreihenfolge können Sie einsehen, wenn Sie auf der Ebene des Servers den Konfigurationsdialog Module aufrufen und auf der Aktionen-Leiste (rechts) den Menüpunkt Sortierte Liste anzeigen wählen. Sie sehen dann die systemeigenen und verwalteten (d. h. ASP.NET-)Module in der Reihenfolge der Verarbeitung (Abbildung 17.24).

Es ist durchaus möglich, die Reihenfolge der Verarbeitung zu ändern – dabei sollten Sie aber ganz genau wissen, was Sie tun. Die Modifikation der Verarbeitungsreihenfolge ist insbesondere dann relevant, wenn eigene individuelle Module hinzugefügt werden.

17.4.4 Die »Modulbauweise«

Wenn Sie sich einige Minuten mit dem IIS7/8 beschäftigt haben, wird eines sofort klar: Es handelt sich um ein modulares System, bei dem die einzelnen Module genau den Anforderungen entsprechend hinzugefügt oder auch entfernt werden können.

Daraus ergeben sich drei Hauptvorteile, die jeder für sich und alle gemeinsam absolut signifikant sind:

• Sicherheit: Dies ist einer der wesentlichen Aspekte, wenn nicht sogar der wesentlichste Aspekt.
  • Durch die Modulbauweise wird die Angriffsfläche signifikant verringert, denn was nicht installiert ist, kann auch nicht angegriffen werden.
  • Der Pflege- und der Wartungsaufwand werden reduziert. Dies ist auch eindeutig ein Sicherheitsthema, denn es hat sich in der Vergangenheit gezeigt, dass die angegriffenen Lücken häufig dadurch entstanden sind, dass Systeme schlecht gepflegt waren oder den Administratoren gar nicht klar war, wo es überall Pflegebedarf gibt.
  • Das vereinheitlichte Sicherheitsmodell von IIS und ASP.NET trägt ebenfalls zur Verbesserung der Situation bei.
• Verbesserte Leistung: Je weniger Module geladen sind, desto weniger Schritte sind bei der Anforderungsverarbeitung zu durchlaufen (siehe Abbildung 17.22 und Abbildung 17.23). Weiterhin benötigen nicht geladene Module natürlich auch keinen Speicher etc.
• Erweiterbarkeit: Verständlichweise trägt eine konsequente Modulbauweise dazu bei, dass IIS sehr weitgehend erweitert werden kann. Dies ist sowohl mit nativen, also in C++ geschriebenen Modulen, als auch mit verwalteten (d. h. .NET-)Modulen möglich.

Die Konfiguration bzw. Aktivierung der Module ist nun zwar nicht unbedingt ein Thema, das man acht Semester lang studiert haben müsste, aber ein paar Hintergründe sollte man schon parat haben. Die grundlegende Konfiguration erfolgt in der applicationHost.config-Datei, also der »Zentralkonfiguration« des IIS (Pfad: C:\Windows\System32\inetsrv\config).

• Alle nativen (d. h. nicht auf .NET-Technologie basierenden) Module müssen im Abschnitt <globalModules> registiert werden. Dieser Abschnitt ist in Abbildung 17.25 gezeigt.
• Weiterhin müssen auf Serverebene und/oder Anwendungsebene die nativen Module aktiviert werden. Dies geschieht dadurch, dass diese zusätzlich im Abschnitt <modules> aufgeführt werden, allerdings ohne Pfadangaben.

  Verwaltete Module (d. h. .NET-Code) können direkt im Abschnitt <modules> eingetragen werden.

• Zu beachten ist noch der Abschnitt <handlers> (Abbildung 17.26), der sowohl in der applicationHost.config als auch auf Anwendungs- und URL-Ebene existieren kann. Dort wird festgelegt, welche Handler bei welchen Dateiextensionen und Verben (z. B. POST, GET) verwendet werden sollen.

Abbildung 17.25 Der Abschnitt <globalModules> der »applicationHost.config«-Datei

Ein Beispiel dafür, was auf Anwendungsebene, also in der web.config, so alles gemacht werden kann, sehen Sie auf Abbildung 17.27. Diese web.config wurde so ohne mein Zutun von Visual Studio 2012 (MVC4-Projekt) erstellt.

Abbildung 17.26 Der Abschnitt <handlers>

Abbildung 17.27 Eine von Visual Studio erzeugte »web.config«-Datei nimmt Modifikationen im Bereich der Module und Handler vor.

In dem durch die Pfeile markierten Bereich werden drei Handler entfernt und wieder hinzugefügt. Wenn Sie sich fragen, was das soll und ob Visual Studio irgendwie unter Drogen steht, ist hier die Antwort: Die Zielplattform des Projekts ist .NET Framework 4.5 gewesen. Durch das Entfernen und Wiederhinzufügen der »entscheidenden« Module und Handler wird sichergestellt, dass für diese Anwendung wirklich mit den Komponenten mit Versionsstand 4.5 gearbeitet wird. Es ist zwar auf der Abbildung nicht zu sehen, aber es wird genau diese Version referenziert.

Abbildung 17.28 Diese systemeigenen und verwalteten Module sind auf der Maschine installiert – das kann aber bei Ihnen durchaus anders aussehen.

Geschockt durch zu viel XML? Kein Problem, Sie können alles auch in der grafischen Oberfläche einstellen:

• Abbildung 17.28 zeigt die systemeigenen und verwalteten Module in der Ansicht. Im Kontextmenü des Moduls gibt es jeweils minimale Konfigurationsmöglichkeiten, insbesondere beim Dateipfad (bei systemeigenen Modulen) und bei den Typen (bei verwalteten Modulen) – also nichts, an dem man etwas einstellen müsste. Der auf der Abbildung gezeigte Bildschirm entspricht übrigens dem Abschnitt <globalModules> der applicationHost.config-Datei (siehe Abbildung 17.25).
• Der Dialog in Abbildung 17.29 zeigt die definierten Handlerzuordnungen auf Serverebene. Auch die hier gezeigten Einträge finden sich natürlich in der applicationHost.config-Datei. Der entsprechende Abschnitt heißt wenig überraschend <handlers>; in Abbildung 17.26 (oben) ist er in der Originalform zu sehen.

Abbildung 17.29 Die definierten Handlerzuordnungen

Die Abschnitte <handlers> und <modules> können, wie zuvor bereits erwähnt, sowohl auf Server- als auch auf Anwendungsebene definiert werden. Ein wenig weiter vorn in Abbildung 17.27 haben Sie gesehen, dass eine Anwendung mit »ihrer« web.config Handlerzuordnungen entfernen und hinzufügen kann (übrigens auch Module).

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.