Bei den hier gelisteten Handlungsempfehlungen handelt es sich lediglich um eine kleine Auswahl von Empfehlungen, die bereits exemplarisch für eine Verbreitung über die "S3C Knowledge Base" aufbereitet wurden.
Handlungsempfehlungen "Green Web" zusammengefasst:
Für Entwickler
Für Aministratoren
Für Anwender
HTTP-Caching auf der Server-Seite unterstützen
Die Caching-Möglichkeiten, die im HTTP-Protokoll definiert sind, sind so entworfen, dass sie sowohl die Anzahl der versendeten HTTP-Anfragen als auch das übertragene Datenvolumen signifikant verringern können.
Web-Inhalte, die von serverseitigen Skripten und Programmen dynamisch erzeugt werden, werden aber üblicherweise nicht als Cache-bar behandelt. Dementsprechend werden die zugehörigen Meta-Informationen häufig ganz weggelassen oder so eingestellt, dass sie ein Caching verbieten.
Es kann aber auch Fälle geben, in denen sich die dynamisch erstellten Inhalte weniger häufig ändern, sodass sie nicht für jede HTTP-Anfrage erneut generiert werden müssen. Hier ist dann ein Caching möglich, ohne dass man Gefahr läuft den Besuchern ungültige Daten zu präsentieren.
Dabei sind insbesondere die folgenden Aktivitäten zu betrachten:
In Bezug auf den ersten Punkt ist festzustellen, dass ausgewachsene Content Management Systeme (CMS) ein HTTP-Caching unterstützen. Sie sollten deshalb so konfiguriert werden, dass diese Caching-Strategien auch angewendet werden. D. h., dass eine Unterstützung für Expires sowie Last-Modified Header und oder ETags aktiviert wird.
Eine entsprechende Caching-Unterstützung fehlt aber häufig in Webseiten bzw. Webanwendungen, die direkt in Skripten und Programmen selbst implementiert wurden und nicht über ein CMS betrieben werden. Ein Beispiel dafür ist eine webbasierte Anwendung, die Stromzählerstände eines Einfamilienhauses abruft, die Verbräuche täglich berechnet und als Grafik auf einer Webseite präsentiert. Anstatt bei jeder Anfrage die Grafik neu zu berechnen könnte auch eine Strategie gewählt werden, bei der die Daten nur dann neu berechnet und die Grafik übertragen werden, wenn neue Daten vom System erfasst worden sind. So wäre es z. B. möglich, das Last-Modified-Datum im HTTP-Header auf das Datum bzw. die Uhrzeit zu setzen, zu dem/zu der der jüngste Verbrauchswert in die Datenbasis eingefügt worden ist.
Wir empfehlen Webentwicklern daher in ihren Webanwendungen und Skripten eine Unterstützung für Expires und Last-Modified Header zu implementieren, um das übertragene Datenvolumen gering zu halten und dadurch elektrische Energie einzusparen, soweit das möglich ist. Das folgende Beispiel zeigt, wie eine solche Unterstützung prinzipiell mit der Skriptsprache PHP umgesetzt werden könnte. Ausführlichere Beispiele auch für anderer Programmiersprachen gibt Nottingham (2010).
HTTP-Caching-Unterstützung konfigurieren
Die Konfiguration der Webbrowser kann im Allgemeinen nicht von den Designern und Administratoren verändert werden. Deshalb muss hier die serverseitige Unterstützung des Caching näher in den Blick gerückt werden. Etwa 80% der Webnutzer haben das Caching in ihrem Webbrowser konfiguriert, die übrigen 20% haben immer einen leeren Cache (vgl. Theurer 2007). Durch das Einbinden Caching-bezogener Metadaten durch den Webserver kann die Anzahl der HTTP-Anfragen und HTTP-Antworten signifikant verringert werden. In HTTP/1.1 ist das Caching dazu bestimmt,
zu verringern.
Der "expiration mechanism" verringert die Zahl der an den Server gesendeten HTTP-Anfragen. Der "validation mechanism" verringert hingegen die Nutzlast der an den Client zurückgesendeten HTTP-Antworten und befasst sich somit mit der Reduktion der Netzwerkbandbreite (vgl. Fielding 1999, S. 74).
Um den "expiration mechanism" von HTTP-Servern zu unterstützen, können Administratoren einen Expires- oder Cache-Control-Header für Serverantworten definieren bzw. konfigurieren. Der in HTTP/1.0 (vgl. Berners-Lee 1996, S. 41) beschriebene Expires-Header legt das Datum fest, nach dem die Antwort als ungültig betrachtet wird. Ein geringeres Problem mit dem Expires-Header ist, dass ausdrücklich Zeichenketten mit Datums- bzw. Zeitangaben verwendet werden. Für eine korrekte Funktionsweise müssen deshalb die Uhren von Client und Server synchronisiert sein, was i. A. nicht der Fall ist (vgl. Crocker 1982, S. 26; Souders 2007, S. 22). Diese Beschränkung des Expires-Header wurde mit HTTP/1.1 aufgehoben. Hier wird die Direktive Max-Age verwendet, um die Dauer in Sekunden festzulegen, die die angefragte Ressource im Cache verbleiben soll. Um mit älteren HTTP-Clients, die HTTP/1.1 nicht unterstützen, kompatibel zu bleiben, darf weiterhin der Expires-Header zusammen mit dem Cache-Control-Header verwendet werden. In diesem Fall überschreibt der Cache-Control-Header den Expires-Header.
Der "validation mechanism" wird von HTTP-Clients verwendet, die einen bereits abgelaufenen Ressourceneintrag in ihrem Cache haben. In diesem Fall darf der Client eine bedingte HTTP-Anfrage an den Server senden. Diese bedingte Anfrage sieht genauso aus wie eine normale Anfrage, außer, dass sie einen sogenannten Validator mitführt, der vom Server verwendet werden kann, um zu entscheiden, ob die vom Client verwendete Ressource immer noch aktuell ist oder ob sie aktualisiert werden muss. Für den Fall, dass sie aktualisiert werden muss, werden die aktuellen Daten an den Client zurück gesandt. Andernfalls antwortet der Server mit dem HTTP-Status "304 Not modified". Es können zwei Cache-Validatoren verwendet werden: "Last-Modified" oder "Entity-Tag" (auch: "ETag"). Im Falle einer Last-Modified-Datumsangabe wird ein Eintrag im Cache als gültig betrachtet, falls die angeforderte Ressource seit dem angegebenen Zeitpunkt auf dem Server nicht mehr verändert wurde. Ein Entity-Tag ist ein eindeutiger Bezeichner für eine bestimmte Version (Entität/entity) einer Ressource (vgl. Fielding 1999, S. 85). Die Berechnung der Entity-Tags wird allerdings nicht von der Spezifikation festgelegt, sondern der Implementierung des Webservers überlassen. Die HTTP/1.1-Spezifikation legt fest, dass Server beide Werte, Entity-Tag und Last-Modified, zusammen in ihren Antworten senden dürfen. HTTP/1.1 Clients werden jedoch von der Spezifikation dazu gezwungen, Entity-Tags in bedingten HTTP-Anfragen zu senden, sofern der Server diese bereitgestellt hat. Zusätzlich können Clients auch die Last-Modified-Datumsangabe übertragen, falls diese gesetzt wurde (vgl. Fielding 1999, S. 86).
Um die Zahl der HTTP-Anfragen und die Größe der Nutzlast in den HTTP-Antworten zu verringern, empfehlen wir die serverseitige Unterstützung der Client-Caches richtig zu konfigurieren. Das heißt:
Ein einfaches Konfigurationsfragment für den weit verbreiteten Apache Webserver könnte z. B. so aussehen:
Installation und Konfiguration des Web-Browsers
Die vorherigen Abschnitte fokussierten auf die Möglichkeiten der Administratoren, Web-Designer und Programmierer um den Datentransfer und damit den Energieverbrauch zu reduzieren. Wie bereits erwähnt wurde, haben Web-Server-Administratoren im Allgemeinen keine Möglichkeiten, um die Konfiguration des Web-Browsers direkt zu beeinflussen, sodass dieser z. B. die ausgelieferten Inhalte entsprechend den Werten im HTTP-Header zu cachen. Es obliegt somit der Verantwortung der Anwender, das von der Server-Seite unterstützte HTTP-Caching mit einer entsprechenden Konfiguration des Web-Browsers zu unterstützen. Die Anwender leisten somit einen großen Beitrag zur Verringerung des Datenverkehrs und folglich des Stromverbrauchs, indem Sie den Browser-Cache entsprechend konfigurieren und indem sie einen Web-Browser verwenden, der HTTP-Kompression mittels GZIP unterstützt (alle aktuellen Versionen moderner Web-Browser). Außerdem befinden sich heute viele unnötige Werbeinformationen im Netz bzw. auf Webseiten, die Datentransfer verursachen, der aber vermeidbar wäre.
Wir empfehlen daher,
Anzeigen, ob Webseiten mit Ökostrom betrieben werden
Web-Browser-Erweiterungen, wie z. B. der "Green Power Indicator" können Benutzer beim selektiven Browsen unterstützen, indem sie anzeigen ob eine Webseite auf einem mit Ökostrom betriebenen Web-Server "gehostet" wird (vgl. Naumann et al. 2008).
Green IT auf der Client-Seite anwenden
Web-Anwender können einen weiteren Beitrag leisten, indem sie selbst mit ihren Organisationen und Haushalten auf Ökostrom umsteigen. Daneben können die klassischen Möglichkeiten moderner Computer, wie z. B. das Energiemanagement so eingestellt werden, dass der Computer wenig Strom verbraucht.
Quellen- und Literaturverzeichnis
Danksagung
Teile dieses Textes wurden durch INSTICC Press veröffentlicht:
Sie verlassen die offizielle Website der Hochschule Trier
