Monkey HTTP Daemon, Hiawatha, Lighttpd und Thttpd positionieren sich als schlanke, schnelle und pfiffige Alternativen zum Webserver-Monster Apache.

Im Schatten des scheinbar allmächtigen Webservers Apache tummeln sich weitaus mehr Konkurrenten, als man zunächst glauben mag. Um überleben zu können, besetzen sie verschiedene Nischen. Die Apache-Konkurrenz gibt sich durch die Bank weniger behäbig und ressourcenschonender, die Entwickler bewerben die Server meist als schnell und leichtgewichtig. Sie eignen sich daher besonders für den Betrieb auf einem schwachbrüstigen oder eigentlich schon ausgemusterten Rechner. In der freien Wildbahn liefern sie etwa die Informationsseiten von WLAN-Hotspots in Hotels oder Cafés aus und empfehlen sich als Grundlage für die Weboberfläche eines selbst gebastelten NAS. Unterwegs oder auf einer (LAN-)Party verwandeln sie vorübergehend ein Net- oder Notebook in einen vollwertigen Webserver. Genug Gründe, sich das Quartett Monkey HTTP Daemon, Hiawatha, Lighttpd und Thttpd einmal etwas näher anzuschauen.

Gemeinsamkeiten

In einem Schnellimbiss fertigt der Grillmeister hinter dem Tresen immer einen Kunden nach dem anderen ab. Zur Mittagszeit verlassen deshalb viele Wartende entnervt die Schlange. Wesentlich effizienter geht es da im Restaurant um die Ecke zu: Dort bedient ein Kellner gleich mehrere Tische auf einmal. Hat ein Gast die Vorspeise erhalten, bekommt danach erst ein anderer seinen Nachtisch, bevor der Garçon dem ersten wieder seinen Hauptgang bringt. Unter dem Strich fühlen sich alle prompt bedient.

Die hier vorgestellten Webserver arbeiten nach dem gleichen Prinzip und fertigen die eintrudelnden Anfragen asynchron ab: Jeder hungrige Browser bekommt reihum immer ein Stückchen seiner angefragten Webseite, bis alles vollständig ausgeliefert ist. Die entsprechenden Stichworte für Programmierer lauten “Non-Blocking Sockets”, poll() und epoll() – der große Apache kann das in der Version 2 übrigens nicht.

Monkey und Hiawatha beschäftigen sogar mehrere Kellner – der Programmierer bezeichnet sie als Threads – was die Abfertigung weiter beschleunigt. Lighttpd engagiert mittlerweile auf Multiprozessor-Systemen bei Bedarf ebenfalls mehrere Kellner. Er erzeugt dabei allerdings echte Prozesse statt Threads, was einige seiner Module aus dem Tritt bringt oder sogar ganz lahm legt.

Alle vier Probanden versprechen eine schnelle Konfiguration über leicht verständliche Konfigurationsdateien und kennen das Konzept der virtuellen Hosts: Wurden einer IP-Adresse mehrere Domainnamen zugeordnet, unterscheiden die Webserver diese auf Wunsch und bedienen jede Domain mit unterschiedlichen Internetauftritten.

Monkey HTTP Daemon

Der Webserver mit dem netten Affenmaskottchen (Abbildung 1) nutzt exzessiv die speziellen Möglichkeiten des Linux-Kernels und lässt sich daher auch nicht auf andere Betriebssysteme portieren. Der Betrieb von Monkey setzt einen Kernel in Version 2.6.28 oder höher sowie die pthreads und libc-Bibliotheken voraus. Der Server selbst kümmert sich ausschließlich um die Auslieferung von statischen Seiten – benötigen Sie mehr Funktionen, müssen Sie Monkey über Plugins ausbauen.

Abbildung 1: Der laufende und korrekt arbeitende Monkey-Webserver grüßt mit einem lustigen Affengesicht.

Eine Handvoll mehr oder weniger nützlicher Beispiel-Plugins liegt bei. So rüstet etwa das Cheetah-Plugin eine Shell-ähnliche Kommandozeile nach, während das Mandril-Plugin Anfragen von vorgegebenen IP-Adressen abweist. Diese Blockade beschränken Sie gegebenenfalls auf bestimmte Unterverzeichnisse beziehungsweise URLs. Sogar einige Kernfunktionen lagert Monkey in Plugin aus, darunter etwa die Ausgabe von Log-Dateien. Um die SSL-Unterstützung zu aktivieren, müssen Sie das Kern-Plugin Liana gegen seine Schwester Liana SSL austauschen.

Um dynamische Inhalte, wie etwa PHP-Skripte oder Python-Programme, kümmert sich seit Version 0.11.0 der externe Palm Application Server. Monkey nimmt die jeweiligen Browseranfragen nur noch entgegen und leitet sie über ein eigens zu diesem Zweck entwickeltes Protokoll an den in Python geschriebenen Palm Application Server weiter. Der führt dann das entsprechende CGI-Programm aus und schickt das Ergebnis an Monkey zurück, der es wiederum an den Browser ausliefert.

Die Konfiguration erfolgt über mehrere Textdateien. Neben der Hauptdatei monkey.conf gibt es unter anderem noch eine separate für jeden virtuellen Host sowie für jedes Plugin. Die Dateien gliedern sich in Abschnitte, die darin jeweils abgelegten Einstellungen gilt es mit Leerzeichen nach rechts einzurücken (Abbildung 2). Diese an die Programmiersprache Python angelegte Notation erfordert zunächst etwas Eingewöhnung. Davon abgesehen geht die Konfiguration einfach und rasch über die Bühne, zumal Monkey nicht besonders viele Einstellungen kennt und diese in den mitgelieferten Beispieldateien bereits sinnvoll vorbelegt.

[Server]. Die Einstellungen selbst sind dann eingerückt, gefolgt von einem Leerzeichen und ihrem Wert.” width=”300″ height=”219″ /> Abbildung 2: Die Konfigurationsdateien für Monkey bestehen aus Abschnitten, wie hier für die Konfiguration des [Server]. Die Einstellungen selbst sind dann eingerückt, gefolgt von einem Leerzeichen und ihrem Wert.

Die Dokumentation von Monkey ist vorbildlich und umfassend. Im krassen Gegensatz dazu fehlt jegliche Erklärung zu den mitgelieferten Plugins. Eine Readme-Datei mit dem Verwendungszweck muss ausreichen, alles Weitere darf der geneigte Administrator aus den Quellcode- und Beispielkonfigurationsdateien herausfischen.

Thttpd

Die letzte Version von Thttpd trägt das Release-Datum 23. Dezember 2003. Ungeachtet des hohen Alters kommt sie auch acht Jahre später immer noch zum Einsatz. Im Gegensatz zu Monkey arbeitet der Webserver der ACME Laboratories nur mit einem Thread und eignet sich damit besonders für eingebettete Systeme.

Das erste “T” in Thttpd steht für die Eigenschaften klein (“tiny”), schnell (“turbo”) und drosselnd (“throttling”). Letzteres weist auf die Möglichkeit hin, die Übertragungsrate für einzelne Dateien festzulegen beziehungsweise zu reduzieren. Auf diesem Weg räumen Sie beispielsweise HTML-Dateien den Vorrang ein, während sperrige PNG-Bilder mit nur 50 KByte pro Sekunde aus dem Webserver tröpfeln. Dieses sogenannte Traffic Throttling war früher ein Alleinstellungsmerkmal von Thttpd, mittlerweile beherrschen es auch Konkurrenten wie Lighttpd.

Die Dokumentation beschränkt sich im Wesentlichen auf eine äußerst umfangreiche Manpage und die thttpd notes auf der Homepage. Wer sich mit den Konzepten und Begrifflichkeiten von Webservern auskennt, für den sollten die dort gebotenen Informationen bereits ausreichen; einsteigen sollten Sie mit den Thttpd-Notes. Um Thttpd zu übersetzen, benötigt man neben dem C-Compiler nur die Basisbibliotheken. Die meisten Distributionen bieten den Webserver zudem in ihren Repositories an.

Die Konfiguration von Thttpd erfolgt meist auf der Kommandozeile über Aufrufparameter. Ist Ihnen das zu fummelig, stecken Sie die Einstellungen in eine einfach aufgebaute Konfigurationsdatei, für die Listing 1 ein Beispiel zeigt. Die ersten drei Einstellungen legen wichtige Speicherorte fest: Bei dir handelt es sich das Verzeichnis für die Webseiten (“Document Root”), bei pidfile um die Datei für die Prozess-ID und bei logfile um die Protokolldatei. Die letzten beiden Zeilen sichern CGI-Programme ab.

dir=/srv/www/htdocs
pidfile=/var/run/thttpd.pid
logfile=/var/log/thttpd.log
chroot
cgipat=/cgi-bin/*|**.cgi

Thttpd ist zwar für statische Inhalte optimiert, besitzt aber auch eine CGI-Schnittstelle. Diese lässt sich gleich mehrfach absichern. So führt der Webserver ausschließlich Programme aus, deren Dateinamen einem ganz bestimmten Muster entsprechen – die Konkurrenz achtet hier nur auf die Datei-Endungen. Zusätzlich vermag Thttpd die CGI-Programme in eine Chroot-Umgebung einzusperren. Sie befinden sich dann in einem Gefängnis, aus dem heraus sie die anderen Dateien und Programme des Systems nicht mehr erreichen. Ein bösartiges oder Amok laufendes CGI-Programm kann so nicht auch noch den Rest des Systems korrumpieren – vorausgesetzt, es verschafft sich nicht durch andere Tricks Root-Rechte.

Abbildung 3: Unter OpenSuse meldet sich der erfolgreich gestartete Thttpd-Webserver mit einer netten Seite.

Virtuelle Hosts richtet man auf eine etwas ungewöhnliche Weise ein: Nachdem Sie die Funktion scharf geschaltet haben, wechseln Sie ins Verzeichnis für die Webseiten, erstellt dort für jeden virtuellen Host einen Ordner mit dessen Domainnamen, in dem dann wiederum der zugehörige Internetauftritt verschwindet. Alles andere regelt Thttpd von alleine. Nach dem gleichen Prinzip binden Sie eigene Fehlerseiten ein: Für diesen vergeben Sie Dateinamen, die einem bestimmten Schema folgen, und speichern sie im Unterverzeichnis errors des Webauftritts. Eine eigene Fehlerseite für 404 (“nicht gefunden”) liegt beispielsweise in der Datei errors/err404.html. Auch hier ist keine explizite Konfiguration nötig.

Beim Einsatz von Thttpd sollten Sie im Hinterkopf behalten, dass Der Autor Jef Poskanzer und die ACME Labs ihn sehr wahrscheinlich nicht mehr weiterentwickeln werden. Damit bleiben auch noch einige Fehler offen, beispielsweise in der IPv6-Unterstützung oder beim Behandeln des X-Forwarded-For-Headers.

Hiawatha

Ein besonderes Augenmerk auf die Sicherheit legt Hugo Leisink bei seinem Webserver Hiawatha. So spendierte er ihm einen eingebauten Schutz vor bekannten Angriffstechniken wie SQL-Injection, Cross-Site-Scripting (XSS), Cross-Site Request Forgery (CSRF) und Denial-of-Service-Attacken. Damit überdimensionierte Anfragen nicht den Web-Server verstopfen, verwirft Hiawatha diese auf Wunsch ab einer einstellbaren Größe. Allerdings sollten Sie nicht einfach blind alle diese Sicherheitsoptionen einschalten: Um beispielsweise einer SQL-Injection vorzubeugen, setzt Hiawatha weitere Schrägstriche in URLs, POST-Daten und Cookies. Unter Umständen bringt dies die Web-Anwendung aus dem Tritt.

Erkannte Angreifer sperrt Hiawatha für eine festgelegte Zeitspanne aus. Wann diese Maßnahme greift, bestimmt der Administrator. So reagiert Hiawatha beispielsweise, wenn von einem Client eine SQL-Injection-Attacke ausging oder er mehr als eine bestimmte Zahl Anfragen in einem bestimmten Zeitraum gesendet hat. Zusätzlich gibt es noch ein Whitelisting, mit dem man bestimmten IP-Adressen immer den Zugriff auf ganz bestimmte virtuelle Hosts gestattet – bei Bedarf erst nach einer Authentifizierung per Passwort.

Web-Anwendungen lassen sich über eine CGI- oder FastCGI-Schnittstelle einbinden. Auf Wunsch startet Hiawatha die CGI-Anwendung unter einem anderen Benutzerkonto mit eingeschränkten Rechten. Ergänzend können Sie sowohl die CGI-Anwendungen als auch den Webserver in eine Chroot-Umgebung sperren. Für FastCGI gibt es obendrauf noch eine Lastverteilung (“Load Balancing”): Hiawatha teilt eingehenden Anfragen dann auf eine von mehreren gleichzeitig laufenden FastCGI-Anwendungen auf.

Die kryptischen URLs von Web-Anwendungen lassen sich mittels regulärer Ausdrücke durch einfachere ersetzen. Diese Technik hilft auch dabei, die wahre Verzeichnisstruktur auf dem Server zu verschleiern. Dieses bei Apache als URL-Rewrite bekannte Konzept firmiert hier als URL-Toolkit. Und das nicht ganz zu unrecht: Mit den flexiblen Übersetzungsregeln blockt Hiawatha Anfragen an bestimmte URLs sogar komplett ab oder leitet sie zumindest um. Das praktische, mitgelieferte Werkzeug Wigwam klopft die Regeln vor ihrem Einsatz auf Fehler ab.

Über einen separaten Port lässt sich der Webserver auf Wunsch mittels Telnet kontrollieren und fernsteuern. Ergänzend gibt es noch ein Remote Monitoring: Dabei überwacht eine spezielle Webanwendung namens Hiawatha Monitor mehrere andere Hiawatha-Server und präsentiert dem Administrator die gesammelten Informationen auf einer übersichtlichen Webseite. Abschließend darf man auch den Server-String, mit dem sich der Webserver gegenüber Webbrowsern identifiziert, ersetzen – und so beispielsweise verschleiern, dass auf dem Server Hiawatha werkelt.

Mithilfe des XSLT-Standards kann Hiawatha XML-Dokumente eigenständig vor der Auslieferung transformieren. Über diesen Weg erhalten auch Verzeichnislistings ein individuelles Aussehen. Auch Hiawatha drosselt auf Wunsch Übertragungsraten, allerdings nur für auf den Webserver hochgeladene Dateien. Ergänzend legen Sie die maximale Dateigröße fest, die Hiawatha entgegen nimmt. Beide Maßnahmen verhindern, dass Scherzkekse den Server mit mehreren GByte großen Videos beschäftigen oder Ähnliches.

Obwohl schon seit 2002 im regen Praxiseinsatz, fehlt Hiawatha in den Repositories vieler Distributionen. Somit gilt es in der Regel den Quellcode selbst zu übersetzen. Um den vollen Funktionsumfang zu erzielen, müssen Sie dabei neben dem C-Compiler und Make die Entwicklerpakete zu OpenSSL, Libxml2 und Libxslt1 hinzuholen.

Hiawatha funktioniert monolithisch, lässt sich also nicht über Module im Funktionsumfang erweitern. Die Dokumentation besteht aus 14 umfassenden Howtos sowie einer überdimensionalen Manpage. Bleiben nach deren Studium Fragen offen, darf man sie in einem Forum stellen. Hiawatha nutzt eine zentrale Konfigurationsdatei (in der Regel /etc/hiawatha/hiawatha.conf), aus der Abbildung 4 einen Ausschnitt zeigt. Einige zusammengehörende Einstellung rahmen spezielle Abschnitte in geschweiften Klammern ein – komplizierter wird es nicht. Dank der gut geschriebenen Howtos und der mitgelieferten, kommentierten Beispielkonfiguration geht die Einrichtung so schnell über die Bühne.

Binding { und }. Die Einstellungen selbst bestehen aus dem Namen, einem Gleichheitszeichen und dem entsprechenden Wert.” width=”229″ height=”300″ /> Abbildung 4: Die Einstellungen für die Bindungen stehen bei Hiawatha zwischen Binding { und }. Die Einstellungen selbst bestehen aus dem Namen, einem Gleichheitszeichen und dem entsprechenden Wert.

Lighttpd

Von allen vorgestellten Webservern bietet Lighttpd, ausgesprochen “Lighty”, den größten Funktionsumfang. Kein Wunder, dass er im Webserver-Survey vom letzten Herbst auf Platz Fünf der beliebtesten Webserver rangierte [1].

Mit Lighttpd wollte dessen Erfinder Jan Knesche ursprünglich nur beweisen, dass ein Webserver 10?000 Anfragen gleichzeitig abfertigen kann (das sogenannte C10K-Problem). Mittlerweile nutzen sogar bekannte Seiten mit hohem Benutzeraufkommen Lighttpd, wie das berühmt-berüchtigte The Pirate Bay oder Isohunt.com, aber auch seriöse Auftritte wie Chefkoch.de oder Teile von YouTube, MySpace und Sourceforge. Wie bei Monkey lassen sich Funktionen über sogenannte Module nachrüsten. Auf diesem Weg erhält Lighttpd auch eine CGI-, SCGI- und FastCGI-Schnittstelle. Besonderes Augenmerk legen die Entwickler dabei auf die Unterstützung von PHP: Lighttpd soll mit PHP über FastCGI genau so schnell arbeiten wie Apache mit dem Modul mod_php4. Für die FastCGI-Schnittstelle steht sogar ein Mechanismus zur Lastverteilung bereit.

Weitere Module versprechen Geschwindigkeitssteigerungen durch diverse Cache-Verfahren oder rüsten eine minimale WebDAV-Unterstützung nach. Mittels regulärer Ausdrücke verwandelt mod_rewrite die kryptischen URLs einer Webanwendung in lesbarere Internetadressen (URL-Rewrite), während man mit dem Magnet-Modul die Verarbeitung von Anfragen über die Scriptsprache Lua steuert. Als besonderes Schmankerl gibt es noch die Möglichkeit, Flash-Videos im FLV-Format zu streamen [2].

Lighttpd kann nicht nur wie Thttpd die Übertragungsrate künstlich einschränken, sondern auch Anfragen ab einer bestimmten Größe abweisen. Das Modul mod_auth schützt Verzeichnisse und Dateien mit einem Passwort. Die Authentifizierung erfolgt dabei wahlweise über die von Apache bekannten .htpasswd-Dateien oder einen LDAP-Server. Auf Wunsch sammelt das Modul mod_status Informationen über den Serverbetrieb, wie etwa die Uptime oder die aktiven Verbindungen, und gibt diese unter einer bestimmten URL als HTML-Datei aus (Abbildung 5). Über ein weiteres Modul lassen sich zudem RRDtool-Statistiken zur Visualisierung des Datenverkehrs abholen und in Webseiten integrieren.

mod_status Informationen über den inneren Zustand des Webservers.” width=”300″ height=”292″ /> Abbildung 5: In Lighttpd liefert das Modul mod_status Informationen über den inneren Zustand des Webservers.

Der große Funktionsumfang fordert allerdings auch seinen Tribut: Zunächst besitzt Lighttpd wesentlich mehr Abhängigkeiten zu anderen Softwarepaketen als die drei anderen Konkurrenten. Der “nackte” Lighttpd benötigt einen C-Compiler, Make sowie die Bibliotheken Libpcre und Zlib. Die Module erfordern unter Umständen weitere Softwarepakete, die das Wiki auf einer eigenen Seite verrät. Für den vollen Leistungsumfang sind auf einem Debian-System insgesamt 17 Pakete nötig. Aus diesem Grund packen die meisten Distributionen Lighttpd in ein Basis-Paket und lagern einige Module in eigene Pakete aus.

Neben der Installation gestaltet sich auch die Einrichtung etwas aufwendiger. Prinzipiell darf man die zahlreichen Einstellungen in eine einzige Konfigurationsdatei stopfen. Spätestens dann, wenn noch mehrere Module und virtuelle Hosts hinzukommen, freut man sich darüber, die Einstellungen auf mehrere Dateien verteilen zu dürfen. Abgesehen von den einfachen Grundeinstellungen, wie sie Abbildung 6 zeigt, geben sich die Konfigurationsdateien äußerst kryptisch. Schuld daran sind vor allem Listen, wie etwa bei der Definition von MIME-Typen mithilfe von mimetype.assign sowie die gerne und häufig genutzten Bedingungen. Damit kann man beispielsweise zunächst die Anzeige des Verzeichnisinhalts (Directory Listing) für alle Verzeichnisse abschalten und dann gezielt für einen oder mehrere Download-Ordner wieder aktivieren.

Abbildung 6: Die Grundeinstellungen von Lighttpd fallen noch einigermaßen verständlich aus – doch wehe, es kommen Module oder virtuelle Hosts hinzu.

Diese Flexibilität führt allerdings zu so unübersichtlichen Ungetümen wie dem aus Listing 2. Es aktiviert für den virtuellen Host www.example.org das Verzeichnislisting für das Unterverzeichnis /download. Die Bedingung betrifft den Host ($HTTP["host"]) namens www.example.org, dessen Webseiten unter /var/www/example.org lagern (Document Root). Trifft zudem zu, dass die URL ($HTTP["url"]) auf /download endet, ist das Directory Listing aktiviert.

$HTTP["host"] == "www.example.org" {
  server.document.root = "/var/www/example.org/"
  $HTTP["url"] =~ "^/download/" {
    dir-listing.activate = "enable"
  }
}

Hinzu kommen dann noch boolesche Operationen, die Werte aus mehreren anderen zusammensetzen, sowie selbst definierte Variablen. Unter dem Strich ist die Konfiguration damit fast ähnlich komplex und fehleranfällig, wie die von Apache. Aufgrund Der weiten Verbreitung von Lighttpd sprudelt das Web nur so vor Anleitungen, Tutorials und Hilfestellungen über. Das Wiki auf der Projektseite ist teilweise etwas unübersichtlich und primär als erschöpfende Referenz ausgelegt. Darüber hinaus gibt es ein Forum sowie gedruckten Lesestoff: Aus deutscher Sicht hervorzuheben ist das Buch “Lighttpd – kurz & gut” [3].

Fazit

Alle vier Kandidaten geben sich kompakt, arbeiten schnell und kommen mit virtuellen Hosts zurecht. Die durchweg nur englischsprachige Dokumentation ist ausreichend bis ausführlich.

Monkey lässt sich über Plugins erweitern und einfach konfigurieren. Der extrem schlanke Thttpd drosselt auf Wunsch den Datenstrom und lässt sich vollständig über die Kommandozeile konfigurieren – wenngleich seine Zukunft ungewiss ist. Den größten Funktionsumfang bietet Lighttpd, an dem besonders seine FastCGI-Schnittstelle mit ihrem Fokus auf PHP gefällt. Die hohe Flexibilität gilt es jedoch mit einer wesentlich komplexeren Konfiguration und einer längeren Einarbeitungszeit zu erkaufen. Hiawatha glänzt wiederum mit den umfassendsten Sicherheitsfunktionen, lässt sich aber im Gegensatz zu Lighttpd nicht erweitern.

Unter dem Strich hängt die Wahl des Webservers von den herrschenden Gegebenheiten und den eigenen Anforderungen ab. Wer besonders flexibel sein möchte, greift zu Lighttpd, Sicherheitsfanatiker zu Hiawatha. Monkey und Thttpd positionieren sich wiederum als schnell aufgesetzte, äußerst kompakte Allrounder.