zurück zum Artikel

Gut sechs Jahre nach dem letzten Major Update bringt Version 2.4 des meist genutzten Webservers eine ganze Reihe von Neuerungen: Das Multi-Processing-Modul Event verbessert Skalierbarkeit und Performance, die Konfiguration wurde vereinheitlicht und erweitert, das Logging ist deutlich flexibler.

Siebzehn Jahre nach dem ersten Release und mehr als sechs Jahre nach dem letzten Major Update hat die Apache Software Foundation [1] das lange erwartete erste Release des Apache HTTP Server 2.4 [2] zur generellen Benutzung freigegeben. Nachdem in den letzten Monaten bereits einige Beta-Releases veröffentlicht worden waren und das geplante erste Release 2.4.0 wegen einer notwendigen Fehlerkorrektur nicht zustande kam, stellt Version 2.4.1 das erste allgemein verfügbare Release von Apache 2.4 dar.

Es enthält nicht nur etliche neue Funktionen, sondern ist gleichzeitig auch performanter bei verringertem Ressourcenverbrauch. Darüber hinaus wurden auch einige Eigenschaften verbessert, die vor allem Systemadministratoren ansprechen werden.

Performance

Auch wenn Apache laut Netcraft nach wie vor mit Abstand der mit Abstand meist genutzte Webserver [3] ist, sind in den letzten Jahren doch zunehmend alternative Webserver aufgetaucht und in speziellen Anwendungsbereichen auch recht erfolgreich geworden – bekannte Beispiele sind nginx [4] und lighttpd [5]. Als Vorteile wird meist ihre Performance ins Feld geführt, insbesondere die bessere Skalierbarkeit. Apache hat nun – insbesondere unter Linux und den unterstützten Unix-Varianten – ebenfalls einen großen Schritt in Richtung bessere Skalierbarkeit getan.

Zu den bekannten Verarbeitungsmodellen Prefork (ein Prozess pro Client-Verbindung) und Worker (ein Thread pro Client-Verbindung) kommt das Muti-Processing-Modul (MPM) Event [6] hinzu. Das Event-MPM erlaubt das Freigeben von Verarbeitungs-Threads, wenn auf einer Verbindung keine Request-Daten zur Verarbeitung anstehen. Weiterhin implementiert das Event-MPM das asynchrone Senden von Content zum Client. Beide Verbesserungen sorgen dafür, dass Apache nun wesentlich weiter skaliert, insbesondere was TCP-Verbindungen angeht. Dies wird immer wichtiger, da neue Webanwendungen zunehmend Kommunikationsformen etablieren, die mit vielen – häufig aber inaktiven – Verbindungen arbeiten. Das Event-MPM ist aber auch im klassischen Web-Betrieb in Verbindung mit HTTP Keep-Alive sehr nützlich.

Das Event-MPM gab es zwar schon in Apache 2.2, dort galt es aber noch als experimentell. Es wurde für 2.4 stark überarbeitet und verbessert. Leider steht es auf der Plattform Windows nicht zur Verfügung. Eine weitere Einschränkung ist zur Zeit, dass die Vorteile des Event-MPM bei der Verarbeitung von HTTPS-Verbindungen nicht zum Tragen kommen.

Im Bereich Performance gibt es aber noch eine andere Verbesserung: Der Webserver benötigt nun in den meisten Anwendungsfällen deutlich weniger Speicher. Dies liegt vor allem daran, dass er allozierten Speicher schneller an das Betriebssystem zurück gibt. Das sehr aggressive Memory-Caching von Apache hatte in der Vergangenheit immer wieder zu Klagen über seinen hohen Speicherbedarf geführt. Dies sollte sich mit 2.4 deutlich verbessert haben.

Konfiguration

Viele Verbesserungen betreffen die Konfigurierbarkeit. Besonders hervorzuheben ist hier der neue Expression Parser [7], der die verschiedenen Optionen zum Arbeiten mit Ausdrücken in der Konfiguration vereinheitlicht und zugleich erweitert. Beispiele hierfür sind die Direktiven RewriteCond, SetEnvIf und SSLRequire, aber auch die Verwendung von Ausdrücken bei Zugriffsbeschränkungen. Wer hat sich nicht schon geärgert, dass man zwar in Allow und Deny als Bedingung Netzwerkadressen mit Netzmasken angeben konnte, nicht jedoch an anderen Stellen? Dies wurde nun komplett vereinheitlicht: Alle Ausdrücke stehen an allen Stellen zur Verfügung. Zudem sind neue Ausdrücke hinzugekommen, etwa Regular Expressions, File Globs und numerische Vergleiche.

Die Stärke des neuen Expression Parsers kommt besonders zum Tragen in Verbindung mit der neuen If [8]-Direktive [9], die es erlaubt, Konfigurationsblöcke abhängig von Eigenschaften einzelner Requests zu aktivieren. Die Eigenschaften sind beliebige Ausdrücke – die Zugehörigkeit der Client-IP zu einem bestimmten Netz beispielsweise oder das Vorhandensein eines bestimmten HTTP-Headers.

Schließlich erlaubt Apache 2.4 die Definition von Variablen innerhalb der Konfiguration mittels der Define [10]-Direktive [11]. Das erleichtert die Verwendung von Konfigurations-Templates, indem man Werte, die abhängig von der Umgebung angepasst werden müssen, in Variablen auslagert, die in einem separaten Include mittels Define definiert werden.

Module, Module, Module

Die eigentliche Stärke von Apache liegt in seiner Modularität. Im neuen Release sind rund 40 neue Module hinzugekommen. Insgesamt bringt der Apache-Webserver nun etwa 120 Module mit. Viele weitere Module stehen über die Module Registry [12] zur Verfügung.

Die meisten neuen Module erweitern die Proxy-Fähigkeiten des Apache. Hierzu gehören mod_sed [13] und mod_proxy_html [14]. Beide schreiben Antworten bei der Auslieferung dynamisch um, etwa wenn ein via Reverse Proxy angebundener Backend-Dienst in seinen Antworten URLs in Links verwendet, die von außen anders angesprochen werden müssen. Das Modul mod_sed unterstützt alle Möglichkeiten des aus der Unix-Welt bekannten Programms sed (Streamline Editor), von Suchen und Ersetzen bis zum Einfügen und Anhängen von Zeilen rund um ein gefundenes Muster. Das Modul mod_proxy_html benutzt einen HTML-Parser, um Ersetzungen auf der Ebene spezifischer HTML-Tags beschreiben zu können. Dieses Modul war schon länger extern verfügbar und liegt jetzt dem Webserver bei.

Zwei weitere Kommunikationsmuster mit Proxy-Backends werden unterstützt. Als Alternative zum großen Modul mod_fcgid wurde ein einfaches Proxy-Modul mod_proxy_fcgi [15] aufgenommen. mod_proxy_fdpass [16] reicht die rohe Client-Verbindung an einen externen Prozess zur Weiterverarbeitung weiter. Hier laufen die Antwortpakete direkt vom externen Prozess zum Client, nicht wie bei den anderen Proxy-Modulen erst zu Apache und von dort zum Client. Wie immer bei mod_proxy sind diese Protokoll-Module frei mit anderes Features wie dem schon seit Apache 2.2 verfügbaren Load Balancing kombinierbar.

Große IT-Landschaften

Die Unterstützung großer IT-Landschaften wurde in mod_proxy weiter verbessert. Die Implementierungen der verschiedenen Load-Balancing-Verfahren wurden als sogenannte Provider herausgelöst. Damit ist es sehr viel leichter möglich, weitere Implementierungen von dritter Seite bereitzustellen. Eine neue Implementierung ist die Lastverteilungsmethode Heartbeat [17]. Hierbei melden die Knoten einer Backend-Farm dem Webserver in regelmäßigen Abständen über das Heartbeat-Protokoll ihre Existenz und Auslastung. Der Webserver erfährt so dynamisch, welche Knoten verfügbar sind, und kann zugleich die aktuelle Auslastung bei der Lastverteilung berücksichtigen.

Das neue Modul mod_proxy_express [18] erlaubt sehr umfangreiche Proxy-Regeln, wie sie etwa auf einem HTTP-Router notwendig werden. Das Modul liest seinen Regelsatz aus einer DBM-Datei.

Bei Einsatz von HTTPS kann mod_ssl [19] erstmals per Online Certificate Status Protocol (OCSP [20]) Zertifikate online überprüfen. Weiterhin unterstützt mod_ssl nun auch die verteilte Nutzung von SSL-Sessions in Server-Farmen durch Replikation über Memcached.

Steht Apache hinter einem Proxy, sieht der Webserver als Client-IP-Adresse lediglich die des Proxies und nicht die des eigentlichen Clients, sodass die IP-Adresse des Clients nicht zur Zugriffsbeschränkung eingesetzt werden kann und bei Störungsanalysen in den Access-Logs fehlt. Das Modul mod_remoteip [21] ermöglicht Apache, die Proxy-IP transparent gegen die eigentliche Client-IP auszutauschen. Dabei ist es möglich, eine Liste von vertrauenswürdigen Proxies anzugeben.

Seite 2

AAA

AAA steht für "Authentication, Authorization and Accounting", also alle Module, die mit der Authentifizierung und Autorisierung von Benutzern zu tun haben. Hier gab es schon bei Apache 2.2 große Veränderungen und auch jetzt wieder wurde in diesem Bereich einiges umgestellt. Letzten Endes waren die Entwickler mit dem Grad der Bereinigung in Apache 2.2 nicht zufrieden, daher hat man hier noch einmal einen größeren Wurf gewagt.

In der Konfiguration werden nun alle Autorisierungseinstellungen über die gemeinsame Direktive Require [22] vorgenommen. Dabei registrieren die unterschiedlichen Autorisierungsmodule jeweils zusätzliche Syntax. So wird ein IP-basierter Zugangsschutz nicht mehr mittels "Allow from network/netmask", sondern via "Require ip network/netmask" ausgedrückt. In Require sind auch komplexe Ausdrücke unter Verwendung des allgemeinen neuen Expression Parsers möglich. Außerdem lassen sich Require-Directiven mittels RequireAll, RequireAny und RequireNone schachteln.

Störungsanalyse

Aber nicht nur Features zählen. Administratoren wissen, wie wichtig es ist, im Problemfall eine saubere Störungsanalyse durchführen zu können. Schwachpunkt bei Apache war hier bislang vor allem das Logging von Fehlern. Im normalen Log-Level "info" wurde sehr wenig geloggt, auf dem einzig verfügbaren höheren Log-Level "debug" schrieben einzelne Module, insbesondere mod_ssl und mod_proxy, extrem viel ins Log. Im neuen Apache wurde die Situation stark verbesserte: Der Log-Level [23] ist nun pro Modul konfigurierbar, aber sogar auch pro URL oder Verzeichnis. Gleichzeitig wurden die weiteren Log-Levels "trace1" bis "trace8" eingeführt und viele neue Log-Statements in den Apache-Kern und in die Module eingebaut. Damit ist es möglich, die Verarbeitung wesentlich präziser nachzuvollziehen. Die Entwickler haben darauf geachtet, dass durch die neuen Log-Statements kein Overhead entsteht, wenn sie nicht ausgeführt werden.

Zur besseren Korrelation zwischen Error-Log und Access-Log kann das Error-Log-Format konfiguriert werden und dabei insbesondere eine neue Korrelations-ID [24] aufgenommen werden, die auch im Access-Log protokolliert werden kann. Schließlich erlaubt das Access-Log nun auch die Ausgabe von Millisekunden-Zeitstempeln und das Loggen von Request-Anfang und Response-Ende.

Lust auf Experimente?

Einige Module sind noch als "experimentell" markiert. Bei einigen Modulen bedeutet das lediglich, dass sie noch sehr frisch und nicht so gut getestet sind wie die meisten anderen neuen Module. In diese Kategorie gehört mod_log_debug [25], das es erlaubt, eigene Meldungen in das Error-Log zu schreiben. Dies ist deshalb interessant, weil mod_log_debug in Verbindung mit dem neuen Expression Parser konditionell loggen kann, das heißt ob eine Meldung geschrieben wird, kann man von Detaileigenschaften eines Requests abhängig machen.

Ein anderes experimentelles Modul hat im Vorfeld für einiges Aufsehen gesorgt: mod_lua [26]. Lua ist eine Skriptsprache, die in den letzten Jahren in vielen Anwendungen für die Entwicklung von Plug-ins unterstützt wird. Die Sprache bietet eine sehr gute Integration mit C und ihr Interpreter ist sehr schlank. Eine Einbettung in Apache bot sich deshalb an. Über mod_lua können Lua-Skripte auf Apache-Interna zuzugreifen und die weitere Verarbeitung beeinflussen. Dabei ist der Overhead weitaus geringer als bei dem früher für ähnliche Zwecke genutzten mod_perl. Das Modul ist als experimentell eingestuft, weil die Details der Verzahnung mit dem Webserver noch nicht finalisiert wurden. Es kann also sein, dass Lua-Skripte, die man jetzt entwickelt, für zukünftige Apache 2.4-Versionen angepasst werden müssen.

Kompatibilität

Die Kompatibilität mit der Vorversion war den Entwicklern sehr wichtig. Auch wenn Apache 2.4 ein neues Major Release darstellt, ist die Konfiguration doch weitgehend kompatibel geblieben. Ein erster Einstieg sollte also mit geringem Aufwand möglich sein. Für den ernsthaften produktiven Einsatz empfiehlt sich aber dennoch die kritische Überarbeitung der Konfiguration.

Die wesentlichen Inkompatibilitäten liegen in den Bereichen AAA (abgefedert durch das Kompatibilitätsmodul mod_access_compat), bei mod_cache (Wegfall von mod_mem_cache, Umbenennung von mod_disk_cache in mod_cache_disk) und bei mod_ssl (Abhängigkeit zum neuen Modul mod_socache bei Benutzung eines SSL-Session-Caches). Weitere Details sind in der aktualisierten Dokumentation [27] enthalten.

Bauen

Als native Software müssen die Apache-Binaries für jede Plattform speziell bereitgestellt werden. Das Apache Webserver-Projekt veröffentlicht jedoch nur den Quellcode und bietet für einige wenige Plattformen als Service der Projektentwickler Binaries zum Download an. Das Gros der Nutzer bezieht seine Binaries jedoch aus Dritt-Distributionen oder baut die Binaries selbst.

Einiges hat sich beim Herstellen der Apache Binaries für Linux und Unix geändert. Zunächst einmal wurden einige Hilfsbibliotheken, die Apache verwendet, aus dem Release ausgegliedert, das heißt sie werden nicht mehr gebündelt bereitgestellt. Dies geschah zum einen, weil das Apache-Projekt in der Vergangenheit bei einigen dieser Bibliotheken die Pflege vernachlässigt hat, etwa bei der PCRE-Bibliothek (Perl Compatible Regular Expressions). Zum anderen stehen aber auch auf vielen Umgebungen die benötigten Bibliotheken bereits installiert zur Verfügung. Als Abhängigkeiten müssen vor dem Bau bereitgestellt werden:

• APR und APR-UTIL [28]
• PCRE [29]
• OpenSSL [30]

Die bislang fest in den Apache einkompilierten MPMs lassen sich nun als dynamisch ladbare Module bauen. Damit ist es jetzt möglich, alle unterstützten MPMs in einem Durchgang zu bauen. Zudem lassen sie sich alle parallel installieren, sodass die Konfiguration beim Start entscheiden kann, welches MPM genutzt werden soll. Hierzu fügt man dem Aufruf von configure den Schalter --enable-mpms-shared [31] hinzu.

Normale Module werden jetzt per Default als dynamisch ladbare Module übersetzt. Das alte Verfahren des statischen Linkens wird aber weiter unterstützt. Die Liste der Module, die standardmäßig gebaut werden, wurde ausgeweitet; es gehören jetzt zum Beispiel mod_ssl und mod_proxy dazu. Wer einmal alle Module inklusiv der experimentellen Module und der Module, die eigentlich nur für Entwickler interessant sind, bauen möchte, verwendet den Schalter "--enable-mods-shared=reallyall".

Ein altes Problem bei Apache war, dass viele Installationen so konfiguriert waren, dass alle enthaltenen Module auch geladen wurden, unabhängig davon, ob sie wirklich benutzt wurden. Gerade für einen exponierten Webserver ist dies nicht erwünscht; viele Administratoren unterzogen sich aber nicht der Mühe, die Liste der zu ladenden Module abzuspecken. Bei Apache 2.4 werden nun nicht mehr alle Module, die gebaut wurden, auch automatisch geladen: Die entsprechenden LoadModule-Direktiven für die nur selten verwendeten Module werden nun bei der Installation auskommentiert.

Aktuelle Probleme

Die letzten Tests vor dem Release haben noch ein Problem auf der Windows-Plattform ergeben. Apache ist auf dieser Plattform seit einigen Jahren populär, aber die Unterstützung durch die Entwickler im Projekt hinkt noch etwas hinterher. Die Direktive Win32DisableAcceptEx, die bei Apache 2.2 erforderlich sein konnte, ist in 2.4 weggefallen und wurde von AcceptFilter http none abgelöst. Dabei wird unter Windows jedoch gelegentlich das initiale Paket eines SSL-Handshakes nicht verarbeitet, sodass es zu Verbindungsfehlern kommt. Der aktuelle Status des Problems lässt sich im Störungsticket 52476 [32] verfolgen.

Fazit

Das neue Release ist eher als evolutionär zu bezeichnen. Die größte Änderung ist ohne Zweifel das MPM Event: Nach Messungen des Projektes hat Apache in Sachen Skalierbarkeit und Out-of-the-box-Performance nun zu nginx aufgeschlossen und ihn in einigen Szenarien überholt.

Performance ist aber häufig nicht ausschlaggebend. Gerade in großen produktiven Umgebungen spielen Stabilität und die Fähigkeit, komplexe Integrationsszenarien umzusetzen und dabei auftretende Probleme schnell analysieren zu können, eine weit größere Rolle. Hier setzt Apache 2.4 mit seinem deutlich flexibleren Logging neue Maßstäbe.

Für viele einfachere Szenarien reicht der bewährte Apache 2.2 weiter aus. Ein Umstieg auf Apache 2.4 im Laufe der nächsten beiden Jahre empfiehlt sich aber, da der Schwerpunkt der Produktpflege jetzt eindeutig bei 2.4 liegen wird. Apache 2.4 fühlt sich auf Anhieb sehr vertraut an, die Einstiegsschwelle ist also denkbar gering; und viele der neuen Features erleichtern Administratoren das Leben. Nicht zuletzt ist es aber auch ein feines Stück Technik, das zu ergründen Spaß macht. (odi) [33]

URL dieses Artikels:
https://www.heise.de/-1437812

Links in diesem Artikel:
[1] http://www.apache.org
[2] http://projects.apache.org/projects/http_server.html
[3] https://www.heise.de/news/Webserver-Nginx-ueberholt-IIS-1403664.html
[4] http://nginx.org/
[5] http://www.lighttpd.net/
[6] http://httpd.apache.org/docs/2.4/en/mod/event.html
[7] http://httpd.apache.org/docs/2.4/en/expr.html
[8] http://httpd.apache.org/docs/2.4/en/mod/core.html#if
[9] http://httpd.apache.org/docs/2.4/en/mod/core.html#if
[10] http://httpd.apache.org/docs/2.4/en/mod/core.html#define
[11] http://httpd.apache.org/docs/2.4/en/mod/core.html#define
[12] https://modules.apache.org/
[13] http://httpd.apache.org/docs/2.4/en/mod/mod_sed.html
[14] http://httpd.apache.org/docs/2.4/en/mod/mod_proxy_html.html
[15] http://httpd.apache.org/docs/2.4/en/mod/mod_proxy_fcgi.html
[16] http://httpd.apache.org/docs/2.4/en/mod/mod_proxy_fdpass.html
[17] http://httpd.apache.org/docs/2.4/en/mod/mod_heartmonitor.html
[18] http://httpd.apache.org/docs/2.4/en/mod/mod_proxy_express.html
[19] http://httpd.apache.org/docs/2.4/en/mod/mod_ssl.html
[20] http://de.wikipedia.org/wiki/Online_Certificate_Status_Protocol
[21] http://httpd.apache.org/docs/2.4/en/mod/mod_remoteip.html
[22] http://httpd.apache.org/docs/2.4/en/mod/mod_authz_core.html#require
[23] http://httpd.apache.org/docs/2.4/en/mod/core.html#loglevel
[24] http://httpd.apache.org/docs/2.4/en/mod/core.html#errorlogformat
[25] http://httpd.apache.org/docs/2.4/en/mod/mod_log_debug.html
[26] http://httpd.apache.org/docs/2.4/en/mod/mod_lua.html
[27] http://httpd.apache.org/docs/2.4/en/upgrading.html
[28] http://apr.apache.org/
[29] http://www.pcre.org/
[30] http://www.openssl.org/
[31] http://httpd.apache.org/docs/2.4/en/programs/configure.html
[32] https://issues.apache.org/bugzilla/show_bug.cgi?id=52476
[33] mailto:oliver.diedrich@heiseopen.de
[34] http://www.apache.org
[35] http://www.kippdata.de

Copyright © 2012 Heise Medien