In iX 8/2000 war über die professionelle Nutzung von Caching-Proxies im Internet zu lesen. Dieser Beitrag soll hingegen zeigen, wie Website-Betreiber von Internet-Proxies profitieren können und was der Webmaster dafür an der eigenen Serverkonfiguration beachten sollte. Oberstes Ziel der Bemühungen ist einerseits eine möglichst schnelle Auslieferung der Daten an die anfragenden Clients, andererseits sollen trotz Zugriffen durch Proxies die Hits auf der eigenen Site zählbar bleiben. Zwar gilt das nachfolgend Beschriebene grundsätzlich für alle Webserver, bei den Konfigurationsbeispielen handelt es sich jedoch um Direktiven für den am weitesten verbreiteten Apache.
Fast alle Internet Service Provider, Netzbetreiber und Firmen setzen in großem Umfang Caching-Proxies mit dem Ziel ein, Content schneller zum Endbenutzer (Kunden) zu bringen. Ferner entlastet das Netze und senkt Leitungskosten. Aber auch für Content Provider, die Betreiber von Websites, können die für ihn in der Regel kostenlosen Proxies nützlich sein. Erstens kommen auch ihre Daten schneller zum Kunden und zweitens können sie ihre eigenen Server und Netze entlasten.
Mögliche Vorbehalte gegen Caching-Proxies rühren oft daher, dass man durch diese Proxy-Zugriffe nicht alle Hits auf den eigenen Seiten richtig zählen zu können glaubt. Diese Bedenken sind aber in der Regel unbegründet, sofern der eigene Webserver richtig konfiguriert ist. Es geht dabei vor allem darum, allen Objekten der eigenen Webseiten die richtige Lebensdauer in Form entsprechender HTTP-Header mit auf den Weg zu geben (dies ist übrigens nicht nur wegen der Existenz von Proxies wichtig, sondern auch wegen der in jedem modernen Browser vorhandenen lokalen Caches). Dafür bedarf es lediglich ein paar Überlegungen zur Klassifizierung der Objekte hinsichtlich ihrer Lebensdauer. Bildet man außerdem die Lebensdauerklassen möglichst 1 : 1 im Dateisystem ab, hat man bei der Konfiguration ein einfaches Spiel. Aber zunächst gilt es, sich anzuschauen wie Proxies mit Dokumenten umgehen beziehungsweise wie sie deren Lebensdauer ermitteln.
Ein wichtiger Header, den der Server grundsätzlich für jedes ausgelieferte Dokument im HTTP-Header mitsenden sollte, ist der Expires-Header. Ferner kann das Verhalten von Caches auch mit dem Cache-Control-Header beeinflusst werden. Ein Beispiel für eine Antwort von einem Webserver, der diese Header mitsendet, zeigt Listing 1.
Fügt der Webserver seiner Antwort den im Listing dargestellten Expires-Header mit, berücksichtigen Proxies dies in der Regel. Anfragen auf dieses Objekt werden solange aus dem Cache beantwortet, bis das aktuelle Datum größer ist als das im Expires-Header angegebene. In diesem Fall wird das Dokument beim Webserver erneut angefragt und zwar in der Regel mit einem HEAD-Request. Dabei fragt der Proxy den Webserver, ob sich das Dokument seit dem Datum im Last-Modified-Header geändert hat. Ist das Dokument inzwischen verändert worden, sendet der Server das neue Dokument an den Proxy. Andernfalls antwortet er mit dem Response-Code 304 not modified. In diesem Fall kann der Caching Proxy das Dokument erneut an den Client senden.
Schwierig wird die Sache erst, wenn der Webserver weder einen Expires noch einen Cache-Control-Header mitsendet (siehe unten, was dafür zu tun ist, damit der Webserver diese Direktiven mitsendet). In diesem Fall muss der Cache-Server ein Verfallsdatum berechnen. Das Ergebnis dieser Berechnung basiert auf konfigurierten Parametern des Cache und dem verwendeten Algorithmus. Diese Konfiguration liegt aber nicht in Händen des Content Provider - und je nachdem wie konservativ sie ist, können im ungünstigen Fall auch veraltete Dokumente ausgeliefert werden. Nebenstehende Abbildung zeigt, wie ein Proxy die Aktualität und Gültigkeit eines Objekts untersucht. Die für die Untersuchung notwendigen Parameter sind in der Tabelle beschrieben.
|
Durch mehrere Wenn-Dann-Abfragen prüft der Proxy die Aktualität eines Objekts. |
In der Abbildung ist zu erkennen, dass der Proxy zweifelsfrei die Aktualität eines Dokuments feststellen kann, wenn entweder Expires oder Cache-Control-Header (zum Beispiel mit Max-Age-Feld) vorhanden sind. Ist beides nicht der Fall, prüft der Proxy, ob die konfigurierte maximale Lebensdauer für diesen Objekttyp überschritten ist. Ist auch dies nicht der Fall, wird der Last-Modified-Header herangezogen. Mit dessen Hilfe sowie dem fest konfiguriertem Last-Modified-Factor (Lm-Factor) wird eine Expiry-Zeit ermittelt. Dem Algorithmus liegt der Gedanke zugrunde, dass ein vor kurzem verändertes Dokument vermutlich bald wieder geändert wird, ein älteres Dokument wahrscheinlich nicht.
Ein Beispiel (Rechnung mit ganzen Tagen zur besseren Verständlichkeit): angenommen, der Lm-Factor beträgt 0,5 (Proxy-Konfiguration). Das aktuelle Datum (Check-Time) ist der 30. Januar, das Last-Modified-Datum der 10. Januar. Dann ergibt sich
Exp-Time = Lm-Faktor * (Check-Time - Last-Modified) = 0,5 * (30. Januar - 10.Januar) = 10 Tage
Somit verfällt das Dokument am 20. Januar (10 Tage nach dem Last-Modified-Datum). Wäre dies hingegen der 28. Januar, dann wäre Exp-Time = 0,5 (30. Januar - 28. Januar) = 1 Tag. Das heißt das Dokument wäre einen Tag nach dem Last-Modified-Datum nicht mehr aktuell.
Der Algorithmus für die Berechnung der Aktualität eines Objekts mag je nach Proxy variieren und ist natürlich nie ganz korrekt. Damit es nicht dazu kommt, sollten also stets Expires und Cache-Control Header versendet werden (dann greift nämlich der in [[bild_url3] Abbildung 2] dargestellte grüne Pfad, die Berechnung beziehungsweise Abschätzung einer Gültigkeitsdauer im grau hinterlegten Bereich kann vermieden werden).
Damit der Apache Expires-Header in seine Antworten einfügt, sind folgende Dinge notwendig:
LoadModule expires_module libexec/mod_expires.c Ein Beispiel soll zeigen, welche Direktiven man zur Steuerung der jeweiligen Lebensdauer verwenden kann. Angenommen sei die Webseite eines Nachrichtendienstes. Die Regeln für die Lebensdauer von Dokumenten könnten hier wie folgt lauten.
Am einfachsten ist es, wenn man das Regelwerk - das sicherlich zusammen mit den Redakteuren erstellt wird - zumindest teilweise im Dateisystem abbilden kann. Für die Newssite hieße das, dass die Daten in einem Dateisystem mit folgenden Verzeichnissen abzulegen wären:
/documents /documents/topnews /documents/downloads /documents/images /documents/counters
Dann würden die Direktiven in der httpd.conf aussehen wie Listing 2.
Die Direktiven, die in einem Directory-Kontext stehen, überschreiben in der Regel solche, die mit ExpiresByType angegeben wurden. Man sollte also die Regeln so generell wie möglich machen und Ausnahmen dann im Directory-Kontext formulieren.
Das Wort access vor der Zahl für die Lebensdauer bedeutet, das die angegebene Lebensdauer ab dem Zeitpunkt des letzten Zugriffs (auf den Webserver) gerechnet wird. Alternativ kann man auch modified schreiben, in diesem Fall gilt die Lebensdauer ab dem Zeitpunkt der Erstellung beziehungsweise der letzten Modifizierung des Dokuments. Die Zeitangaben können übrigens auch in Sekunden erfolgen; access und modified lassen sich durch A und M abkürzen. Die Direktive für Regel 2 aus dem Beispiel könnte also auch wie folgt lauten:
# Regel 2:<Directory /documents/topnews/*>ExpiresDefault "A300"</Directory>
Neben den hier dargestellten Direktiven, die sich auf Objekttypen oder alle Objekte in einem bestimmten Verzeichnis beziehen, kann die DirectoryMatch-Direktive auch reguläre Ausdrücke angeben, beispielsweise
<DirectoryMatch "/documents/*/(archive|old)/*">... ...</DirectoryMatch>
Eine vollständige Aufstellung der möglichen Direktiven des Moduls mod_expires findet man in Eilebrechts Buch [[#literatur 3]], die Idee sollte hier deutlich geworden sein. Bleibt anzumerken, dass die Direktiven auch in .htaccess-Dateien stehen dürfen, sofern der Apache so konfiguriert ist, dass er diese Dateien liest. Die Direktiven gelten dann jeweils für das Verzeichnis, in dem sich die Datei .htaccess befindet. Dadurch lassen sich die Zuständigkeiten vom Webmaster delegieren. Das Öffnen und Lesen dieser Datei durch den http-Daemon geht aber auf Kosten der Performance, weshalb diese Funktion nur gezielt eingesetzt werden sollte.
Redakteure und Autoren haben ferner die Möglichkeit, in ihren HTML-Seiten die Werte des max-age-Feldes im Cache-Contol-Header zu manipulieren. Dies geschieht mit Hilfe von Meta-Tags der Form:
<META http-equiv="Cache-Control" content="proxy-revalidate">
Der Proxy wird in diesem Beispiel angehalten, bei jeder Anfrage des entsprechenden Dokumentes dessen Gültigkeit beim Content Server zu revalidieren. Oft wird fälschlicherweise angenommen, das der Proxy diese Direktive direkt aus dem HTML-Dokument liest. Das ist aber nicht der Fall, denn wenn der Proxy jede Datei parsen sollte, würde dies auf Kosten der Performance gehen. Die Direktiven in Meta-Tags werden lediglich vom Clients (Browser) gelesen. Proxies orientieren sich wie gesagt am HTTP-Header, den der Webserver generiert. Der dem obigen META-Tag entsprechende HTTP-Header hat die Form:
Cache-Control: proxy-revalidate
Meta-Tags stellen also lediglich eine Entscheidungshilfe für Browser-Caches dar. Deshalb sollten auf jeden Fall die oben beschriebenen Direktiven im HTTP-Header vorgezogen werden, diese berücksichtigen sowohl Proxies als auch Browser.
Eine Cache-konforme Konfiguration des eigenen Webservers kann das Cache-Verhalten von Proxies und Clients steuern. Sendet der eigene Webserver die richtigen Direktiven mit, berücksichtigen Proxies und Clients die Vorgaben hinsichtlich der Lebensdauer der Dokumente. Weist man den für die Zählung relevanten Objekten die Lebensdauer 0 zu, sind alle Zugriffe auf der eigenen Seite zählbar. (In der Praxis wird dafür oft ein Bild mit der Größe eines Pixels verwendet.) Für die meisten Objekte beziehungsweise Dokumente lässt sich eine längere Lebensdauer festlegen. Durch die aus dem Proxy- und Browser-Cache beantworteten Zugriffe wird die Last auf dem eigenen Webserver sowie der Verkehr im eigenen Netz reduziert und der User erhält in der Regel schnellere Antworten.
Neben der Cache-konformen Konfiguration des Webservers existieren weitere Möglichkeiten, die Auslieferungsgeschwindigkeit der Dokumente zu erhöhen. Eine Möglichkeit zur Performance-Steigerung ergibt sich durch die Nutzung des Fast Response Cache Accelerators im Apache (FRCA). Durch eine Kernelerweiterung können auszuliefernde Dokumente in privaten Hauptspeichersegmenten des Webservers zwischengespeichert und dadurch ohne Kontext-Switch noch schneller ausgeliefert werden. Über diese Möglichkeit berichten wir in einer der nächsten Ausgaben.
Dr. Stefan Radtke
arbeitet als Consulting IT-Spezialist bei IBM und ist für die technische Beratung und Realisierung von Lösungen für Internet Service Provider zuständig.
Literatur
[1] Stefan Radtke; Schneller durchs World Wide Web, Professioneller Einsatz von Caching Proxy Servern, iX 8/2000, S. 90
[2] Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Tim Berners-Lee; RFC 2068; Hypertext Transfer Protokoll - HTTP V.1.1, Januar 1997
[3] Lars Eilebrecht; Apache Web-Server, 3. überarbeitete Auflage; Bonn (MITP-Verlag) 2000
[4] Ari Luotonen; Web Proxy Servers, Upper Saddle River, NJ (Prentice Hall) 1998
[5] Mark Nottingham; Caching Tutorial for Web Authors and Webmasters; http://www.stars.com/ (Registrierung nötig), Juni 1999
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 11/2001 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
