Die wichtigsten Tools

• Firebug, Netzwerk Tab -> zeigt Ladezeiten und Cache Hits
• Firbug Add-Ons machen Performance Analyse und geben viele gute Hinweise:
  • Yahoo’s YSlow (Erläuterungen)
  • Google’s Page Speed (Erläuterungen)

Die relevanten HTTP Header

Quelle: HTTP/1.1 Header Field Definition

Expires

• Erklärt Ablaufdatum der Resource
• Browser macht keinen Request mehr vor Ablauf dieses Datums

Cache-Control

• public: Aktiviert Proxy Caching und Caching im Firefox bei SSL Verschlüsselung
• no-cache: Deaktiviert Caching
• no-store: Keinerlei Speicherung, noch härter als “no-cache” (gedacht für Backups etc…)
• max-age: Ablaufzeit in Sekunden, redundant zu Expires
• must-revalidate: Immer Server fragen, ob Resource abgelaufen ist
• (es gibt weitere, die vor allem für Proxies relevant sind)

Last-Modified

• Erklärt letztes Änderungsdatum
• Browser schickt einen If-Modified-Since Header beim nächsten Request
• Server kann ein 403 Not Modified zurückschicken, Browser nutzt Caching Daten

ETag

• “Entity Tag”
• Ist eindeutige ID bzw. Hash einer Resource
• Apache verwendet z.B. dafür Last-Modified-Timestamp, Dateigröße und iNode ID, kann aber beliebig gewählt werden
• Browser schickt einen If-None-Match Header beim nächsten Request
• Server kann ein 403 Not Modified zurückschicken, Browser nutzt Caching Daten

Erkenntnisse

• Expires und Cache-Control: max-age sind gut, um Anzahl der Requests zu drücken
• Last-Modified und ETag sind gut, um die Datenmenge zu reduzieren
• Expires und Cache-Control: max-age sind redundant, besser nur eins von beiden verwenden
  • Weniger HTTP Overhead
• Last-Modified und ETag sind redundant, besser nur eins von beiden
  • Weniger HTTP Overhead
  • Wenn beides verwendet wird, muß auch beides geprüft werden!
• Optimales Caching: Resource muß nur ein einziges Mal geladen werden, dann keine weiteren Requests mehr
  • Expires in Jahr in die Zukunft setzen
  • Wenn sich Resource ändert, URL ändern (z.B. mit Versionsnummer oder Hash)
  • Das geht nur, wenn das gesamte System (die Webapplikation) darauf ausgelegt ist!

Diskussion

ETags sind in Applikationen etwas leichter zu handhaben als Last-Modified Timestamps, da ein einfacher Stringvergleich ausreicht. Timestamps müssen erst umständlich in UNIX Epochen umgewandelt und verglichen werden, bzw. durch aufwändige Klassen gejagt werden.

Dabei sind sie flexibler zu handhaben – Ein ETag kann aus irgendwelchen Daten bestehen, nötigenfalls aus der Summe mehrerer Metadaten mehrerer Elemente.

Für einfache Szenarios (z.B. Bilder, die von der Applikation serviert werden) reicht als Seed für den ETag ironischerweise meist ein Timestamp einer Datei. Mehrere Seeds erhöhen den I/O oft unnötig, können jedoch im Zweifelsfall jederzeit leicht hinzugefügt werden.

Empfehlung von YSlow und Page Speed ist, immer ein Expires und/oder ein Cache-Control zu senden. Bei Resourcen, die sich jederzeit ändern könnten, fühlt sich das allerdings relativ nutzlos an. Der Selbstversuch bestätigt das erwartete Standardverhalten der Browser, immer beim Server nachzufragen, solange der Server nicht explizit ein Expires gesetzt hat. Von öminösen Heuristiken war nichts zu bemerken. Insofern verbrauchen diese Header bei derartigen Resourcen erst einmal nur Bandbreite.

Dennoch bin ich natürlich an guten Gründen interessiert, Expires und/oder Cache-Control bei Resourcen mit unbekanntem Ablaufdatum einzusetzen!

Robert Hansen hat ein neues Verfahren entwickelt, DoS Attacken auf Webserver (z.B. Apache) durchzuführen und dieses “Slowloris” genannt. Er beschreibt es ausführlich auf seiner Homepage http://ha.ckers.org/slowloris/

Dabei wird nicht ein übliches Flooding, also eine Überhäufung des Webservers mit Anfragen, durchgeführt, sondern im Gegenteil ein recht langsamer Angriff, der durch ein absichtliches Verlangsamen und Hinauszögern korrekter gültiger Anfragen dafür sorgt, daß er nach und nach sämtliche Requestlimits des Webservers belegt.

Das Gefährliche dabei ist, daß diese Art von Angriff kaum bemerkbar ist – in den Logdateien des Webservers tauchen keine merkwürdigen Einträge auf, denn die werden ja erst geschrieben, wenn die Anfrage fertig bearbeitet ist, bzw. fehlerhaft abbricht. Beides passiert hier aber nicht, es sind ja gültige Anfragen. Seeeehr langsaaaame.

Die Resourcen des Servers werden auch nicht übermäßig beansprucht, so daß in Monitoring Tools wie Munin und Cacti kaum Auffälligkeiten zu beobachten sind. Der Server muß im Gegenteil immer weniger tun, er wartet ja darauf, daß die Requests endlich einmal korrekt zu Ende gebracht werden.

Prozessorientierte Webserver wie Apache, dhttpd, GoAhead WebServer und Squid sind übrigens anfälliger: Sie erzeugen pro Request einen Prozess auf dem Server und limitieren die Anzahl derselben, um einen anderen Angriff zu verhindern: Daß der Webserver durch zu viele Requests die Resourcen der Hardware (v.a. RAM Speicher und Prozessorzeit) aufbraucht.

Außerdem scheint es einen Seiteneffekt zu geben: Bei Webapplikationen taucht zusätzlich das Problem auf, daß die Datenbank, die dort im Normalfall verwendet wird, noch weniger gleichzeitige Verbindungen akzeptiert, als der Webserver. Diese gibt also zuerst auf. Damit wird der Angriff noch effektiver, erzeugt dann allerdings schneller Fehlermeldungen, die denselben leichter identifizierbar machen.

Die gute Nachricht ist außerdem: Der Angriff wird durch geeignete Auswahl von Reverse Proxies, Load Balancern u.ä. Strukturen verhindert, da diese Systeme eben meist nicht prozessorientert arbeiten – das ist allerdings nichts, was man normalerweise in kleinen Umgebungen vorfindet. Es dürfte also eine Menge gute Ziele da draußen geben!