Kosten sparen mit HTTP-Kompression (Gastbeitrag tecCHANNEL)
Eine gut besuchte Website verursacht erhebliche Kosten für den entstehenden Datenverkehr. Wie Sie mittels HTTP-Kompression bei IIS bares Geld sparen können, zeigt dieser Beitrag.
Auf dieser Seite
 | Vorteil: Schneller surfen |
| Seite komprimiert ausliefern |
| Die Komprimierungsverfahren |
| HTML komprimieren mit dem IIS |
| Kompression bei IIS 6 |
| Probleme mit komprimierten Webseiten |
| Fazit |
Den größten und unkalkulierbarsten Kostenblock beim Betrieb einer Webseite macht der Traffic der jeweiligen Anbindung aus. Jedermann, der eine größere Webseite betreibt, versucht, das Datenvolumen und die Bandbreite möglichst gering zu halten: Sind die ausgelieferten Seiten klein, erscheinen sie dem Leser zum einen schneller - zum anderen bedeuten kleinere Seitengrößen auch geringere Kosten für den Traffic.
Der Umstand, dass die meisten Dateien auf einer lokalen Festplatte komprimiert werden können, ist kein Geheimnis. Natürlich gilt das aber auch für Webseiten auf der Platte des Servers. Nachdem es sich bei HTML-Dateien um reine Textdateien handelt - zudem noch um solche, in denen immer wieder identische Elemente in Form der HTML-Tags auftauchen -, eignen sich diese Dateien sogar besonders gut für eine Komprimierung. Allein auf der Festplatte des Servers bringt das nicht besonders viel, wenn die Platte nicht gerade ohnehin unterdimensioniert ist.
Aber auch die Übermittlung selbst von Webseiten kann in komprimierter Form an den Client geschehen, und das spart Bandbreite und Datenvolumen. HTML-Seiten lassen sich im Allgemeinen auf etwa ein Viertel schrumpfen, mit ein bisschen Glück sogar deutlich stärker.
Vorteil: Schneller surfen
Abgesehen von der eingesparten Bandbreite hat das Ausliefern von komprimierten Seiten einen weiteren Vorteil: Es geht nicht nur ums Geld. Komprimierte Seiten sind deutlich kleiner als ihre unkomprimierten Originale. Das bedeutet, dass weniger Daten pro Seite transportiert werden müssen. Und das wiederum heißt, dass die Seite schneller beim Client ist. Der Surfer sieht die Inhalte also viel eher und hat seinen ersten Eindruck von der Webseite deutlich früher. Denn wenn nur noch ein Viertel der Daten transportiert werden muss, ist die Seite auch vier Mal schneller im Browser geladen. Das stimmt natürlich nicht ganz, denn die anderen Elemente der Seite, zum Beispiel Bilder, müssen ja auch noch geladen werden. Allerdings: Die Bilder sind vielleicht schon beim Client - und wenn die Haltbarkeitszeiten für die Bilddaten richtig gesetzt sind, fällt die Ladezeit für die Bilder nicht weiter ins Gewicht.
Eine schneller ausgelieferte Seite freut aber nicht nur den Surfer, sondern ebenso den Site-Administrator. Denn sein Vorteil ist, dass der eigene Server mehr Surfer verkraften kann. Wird eine Seite schneller ausgeliefert, wird der zugehörige HTTP-Dämon (unter NT der zugehörige Thread) früher beendet, und die belegten Sockets werden schneller wieder frei. Das bedeutet letzten Endes je nach Zugriff, dass der Rechner auch weniger Last zu verkraften hat. Beim Ausliefern komprimierter Webseiten handelt es sich also um eine Tuning-Maßnahme für Webserver, die dem Betreiber nebenher noch Geld für die belegte Bandbreite spart.
So viel zur Theorie. Ob die Server-Last in der Praxis durch die Auslieferung komprimierter Seiten tatsächlich verringert wird, ist von einigen weiteren Faktoren abhängig. Aber selbst wenn man nur Geld für die Bandbreite spart und dem Surfer ein besseres Surfverhalten geboten wird: Das Komprimieren lohnt sich auf jeden Fall.
Damit wäre der erste Faktor angesprochen, von dem die tatsächliche Lastersparnis abhängt: Man darf nämlich nicht vergessen, das die Seiten erst einmal komprimiert werden müssen - und das erzeugt seinerseits zunächst einmal Last auf dem Rechner. Wie viel, hängt davon ab, ob einmal komprimierte Seiten zwischengespeichert werden können und nicht wieder komprimiert werden müssen. Ob das überhaupt geht, ist vom verwendeten Server beziehungsweise den verwendeten Zusatzprodukten abhängig.
Seite komprimiert ausliefern
Die Theorie ist klar: Komprimierte Webseiten sind offensichtlich ein Muss. Wie aber geschieht das? Einfach nur gzip oder WinZip anwerfen und Dateien vor dem Hochladen zum Webserver komprimieren, reicht nicht aus - zumal komprimiert ausgelieferte Seiten das eine oder andere Problem aufwerfen.
Zunächst einmal muss man wissen: Die Auslieferung von HTML-Seiten in kodierter Form stellt von Haus aus kein Problem dar. Dabei kann es sich im Prinzip um eine beliebige Kodierung handeln - die Kompression ist da nur eine Spezialform der Kodierung. Um genau zu sein, ist sogar die ganze normale "Plaintext"-Form lediglich eine Spezialform der Kodierung - nämlich die Spezialform "Ohne besondere Kodierung".
Beim Kodieren einer Webseite unterscheidet man zwischen dem "Content-Encoding" und dem "Transfer-Encoding". Bei Ersterem geht es darum, den Inhalt vor der Auslieferung zu kodieren, bei Letzterem darum, den Inhalt während der Übertragung zu kodieren. Für die Komprimierung von Webseiten hat diese Unterscheidung in der Praxis aber keine Auswirkung, da viele Webseiten ohnehin beim Abruf dynamisch erzeugt werden: Eine Unterscheidung zwischen dem Zustand vor und während der Auslieferung wird da schwierig.
Aus diesem Grund wird im Folgenden auch immer von "Transfer Encoding" gesprochen. Auch, wenn es sich in einigen der angesprochenen Fälle um "Content-Encoding" handelt.
Beim Transfer-Encoding ist es gleichgültig, ob die Kodierung nun eine Verschlüsselung, eine Komprimierung oder irgendein anderes Verfahren darstellt. Wichtig ist allerdings, dass der Client (also der Browser des Surfers) im Zuge des Request mitgeteilt hat, dass er eine bestimmte Form der Kodierung tatsächlich verarbeiten kann.
Die Komprimierungsverfahren
Für die Komprimierung gibt es ein extra standardisiertes Verfahren - eigentlich sogar zwei - die die Namen gzip beziehungsweise deflate tragen. Beide sind Teil des HTTP/1.1-Standards, und dieser Standard wird von allen gängigen Browsern unterstützt. Zumindest unterstützen alle gängigen Browser Transfer-Encoding im gzip-Format über HTTP/1.1. Wie das bei Browsern immer so ist, gibt es Probleme - zum Beispiel, dass einige ältere Browser zwar behaupten, HTTP/1.1 zu verstehen, das dann aber doch nicht können. Im Wesentlichen ist es aber so, dass praktisch alle Microsoft-Browser ab IE 4.0 und alle von Netscape ab Version 3.0 das Protokoll unterstützen. Um auch auf etwas ausgefallenere Browser einzugehen: Sogar der textbasierte Lynx-Browser kommt mit Transfer-Encoding in HTTP/1.1-Verbindungen klar.
Aktivieren: Beide HTTP/1.1-Optionen müssen im IE eingeschaltet sein.
Meldet sich ein Browser hingegen als HTTP/1.0-kompatibler Client am Server an, so muss der Server einfach nur weniger tun: Im Wesentlichen entfällt dann der Komprimierungsschritt, so dass die Seite in ihrer normalen Form ausgeliefert wird.
HTML komprimieren mit dem IIS
Beim IIS ab Version 5.0 können Sie das Transfer-Encoding deutlich einfacher einschalten. Hier müssen Sie nur ein paar Optionen aktivieren, und schon werden die Seiten komprimiert ausgeliefert. Allerdings hat man sich bei Microsoft reichlich Mühe gegeben, dieses Feature zu verstecken. Man findet die benötigten Optionen nämlich nicht ohne Weiteres. Das liegt daran, dass man diese Optionen nur Server-weit einstellen kann, und nicht dort, wo man sie normalerweise suchen würde, bei den Eigenschaften der virtuellen Verzeichnisse. Stattdessen erfolgt die Konfiguration über die allgemeinen Eigenschaften des Webservers. Des Weiteren steht dieses Feature nur bei den "echten" IIS-Varianten zur Verfügung. Die abgespeckten Versionen, wie sie zum Beispiel bei der XP Workstation vorliegen, bieten diese Möglichkeit nicht.
Eingebaut, aber versteckt: Beim IIS ist die Kompression von Haus aus dabei.
Folgende Schritte müssen bei IIS 5.x ausgeführt werden, um die Komprimierung zu aktivieren:
| • | Starten Sie den Internet-Dienste-Manager und öffnen Sie die "Eigenschaften" des Computers. |
| • | Es erscheint der Dialog zur Einstellung der Eigenschaften von IIS. Wechseln Sie auf die Seite "Internet-Informationsdienste". |
| • | Wählen Sie dort unter "Haupteigenschaft" den "WWW-Dienst" aus und klicken Sie auf "Bearbeiten". |
| • | Nun erscheint der Dialog "Haupteigenschaften des WWW-Dienstes". Wechseln Sie hier auf den Reiter "Dienste". |
| • | Hier finden Sie im Bereich "HTTP-Komprimierung" zwei Optionen. Die eine trägt den Namen "Anwendungsdateien komprimieren", die andere "Statische Dateien komprimieren". Schalten Sie die benötigten Optionen ein, je nachdem ob dynamische und/oder statische Seiten komprimiert werden sollen. |
Kompression bei IIS 6
Beim IIS 6 finden Sie die Optionen zum Einschalten der Kompression in den Eigenschaften des Ordners WebSites in der Management-Konsole von IIS. In der zugehörigen Dialogbox öffnen Sie den Reiter Service (Dienst) - dort können Sie die Komprimierung einschalten.
Für die "statischen" Dateien können Sie ein paar zusätzliche Parameter angeben. Dabei handelt es sich im Wesentlichen um einen Pfad zu einem Verzeichnis für die zwischengelagerten Dateien sowie die maximale Größe dafür. Der IIS legt dann einmal komprimierte Versionen von statischen Dateien in diesem Verzeichnis ab. Ändert sich die Originaldatei, so sorgt der IIS selbstständig dafür, dass die komprimierte Variante ebenfalls erneuert wird. Dabei ist es wichtig zu beachten, dass es ein lokales Verzeichnis ist und dass es sich auf einer NTFS-Partition befindet.
Der IIS hat noch eine ganze Reihe an weiteren Parametern, mit denen sich die Kompression von Dateien beeinflussen lässt. So ist es zum Beispiel möglich, eine maximale Dateigröße anzugeben - ist eine Datei größer, wird sie nicht komprimiert. Ebenso kann man eine minimale Dateigröße angeben. Diese und weitere Optionen stehen zwar zur Verfügung - aber nicht über die normale Benutzerschnittstelle. Stattdessen müssen diese Werte in der Metabase eingetragen werden. Eine ausführliche Erläuterung dazu finden Sie in der Metabase-Dokumentation, die zum Beispiel im IIS Resource Kit verfügbar ist.
Das Einschalten der Kompression beim IIS hat allerdings eine unangenehme Nebenwirkung: Alle Dokumente werden mit einem "Haltbarkeitsdatum" ausgeliefert, das bereits abgelaufen ist, und zwar mit dem 1. Januar 1997. Das hat aber einen mehr oder minder guten Grund - es vermeidet Probleme mit Proxies. Allerdings ist dadurch das Cachen von Inhalten nicht mehr möglich, denn kein Client behält eine solche Seite im Cache.
Probleme mit komprimierten Webseiten
So schön komprimierte Webseiten sind, so unangenehm ist der auftretende Seiteneffekt. Dieser betrifft Proxy-Server, die Seiten zwischenspeichern. Einige Proxy-Server haben Probleme mit komprimierten Seiten. Der Proxy nimmt die Seite an und speichert sie in der komprimierten Form ab. Wird die Seite dann allerdings von einem Client angefordert, der keine Komprimierung versteht, so liefert der Proxy dennoch die komprimierte Version aus, anstatt sie für den Client zu entpacken oder eine unkomprimierte Version der Seite vom Server anzufordern. Das Resultat besteht darin, dass der Benutzer nur kryptische Zeichen zu sehen bekommt und frustriert auf eine andere Webseite wechselt.
Zum Glück tritt dieses Problem aber in immer weniger Fällen auf - hauptsächlich gibt es bei einigen Versionen des Internet Explorer Schwierigkeiten: Dort muss der User zwei Optionen einschalten, um komprimierte Seiten richtig sehen zu können, die über einen Proxy ausgeliefert werden. Das wäre weiter nicht schlimm, wenn nicht eine dieser Optionen per Default ausgeschaltet wäre. Es handelt sich um die Optionen "HTTP 1.1 verwenden" und "HTTP 1.1 über Proxy verwenden". Generell können Sie davon ausgehen, dass die Auslieferung von komprimierten Webseiten nur Vorteile bringt und keine relevanten Probleme in sich birgt: Zumindest dann, wenn Sie nicht selbst einen Reverse-Caching Proxy einsetzen, um Ihren Webserver zu entlasten.
Fazit
Mit komprimierten HTML-Seiten sparen Sie nicht nur eine ganze Menge Geld, sondern bieten dem Surfer auch eine "schnellere" Website an. Und das ist wichtig, denn viele Surfer geben schnell entnervt auf, wenn das Laden der Seiten zu lange dauert.
Das können Sie natürlich noch verbessern, indem Sie die ursprünglichen HTML-Seiten kompakter gestalten, denn diese sind meist viel größer, als sie es für denselben Zweck sein müssten. Das gilt besonders dann, wenn Sie HTML-Editoren verwenden, die eine Menge unnützen Code in die HTML-Dokumente einbringen. Kleinere Bilder und das Entfernen nicht verwendeter Stylesheets hilft zusätzlich bei der Reduzierung des zu übertragenden Datenvolumens.