{"id":8941,"date":"2022-05-23T23:35:08","date_gmt":"2022-05-23T21:35:08","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=8941"},"modified":"2022-12-12T14:42:31","modified_gmt":"2022-12-12T12:42:31","slug":"apache-und-nginx-im-vergleich-wo-liegen-die-unterschiede-welcher-webserver-ist-besser","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/apache-und-nginx-im-vergleich-wo-liegen-die-unterschiede-welcher-webserver-ist-besser\/","title":{"rendered":"Apache und Nginx im Vergleich: Wo liegen die Unterschiede? Welcher Webserver ist besser?"},"content":{"rendered":"

Je nach Statistik ist Apache der verbreitetste Webserver<\/a>, oder es steht Nginx auf Platz 1<\/a>. Solche Messungen sind durchaus mit Vorsicht zu genie\u00dfen: Sie erfassen oft nur einen Teil des Internets und nicht jede Seite gibt bekannt, welche Technologie sie einsetzt. Unbestritten ist dagegen, dass sowohl Apache als auch Nginx zu den verbreitetsten Webservern geh\u00f6ren und damit ein wesentlicher Bestandteil des heutigen Internets sind. Doch worin unterscheiden sie sich? Welcher davon ist besser? Nachdem ich beide \u00fcber Jahre hinweg eingesetzt habe, werden wir uns die Webserver genauer anschauen und die Fragen im Anschluss kl\u00e4ren.<\/p>\n

Apache: Das Urgestein des WWW<\/h2>\n

Die Entwicklung von Apache geht bis in die fr\u00fchen 1990er Jahre zur\u00fcck: Sie erweiterten den 1993 erschienenen NCSA HTTPd<\/a>. Er wurde am Nationalen Zentrum f\u00fcr Supercomputer-Anwendungen in den USA als einer der ersten Webserver entwickelt. Als einer der urspr\u00fcnglichen Entwickler das Zentrum mitte 1994 verl\u00e4sst, verlangsamt sich die Entwicklung stark. Im selben Jahr erweitern acht unabh\u00e4ngige Entwickler HTTPd und ver\u00f6ffentlichten ihre \u00c4nderungen 1995 unter dem Name Apache HTTP Server<\/strong>. Er war das Gr\u00fcndungsprojekt der 1999 gegr\u00fcndeten Apache Software-Stiftung, die bis heute eine Vielzahl an verbreiteten Open Source Projekten betreut. Sie haben f\u00fcr den Webserver ihre eigene Apache-Lizenz entwickelt.<\/p>\n

Nginx setzt den Fokus auf Leistung<\/h2>\n

Der Nginx-Webserver erschien dagegen erst im Jahre 2004. Er wurde f\u00fcr die russische Suchmaschine Rambler entwickelt, die bereits im Jahr 2000 mehr als eine Milliarde Suchanfragen erhielt. Wichtig war daher eine hohe Leistung bei geringem Ressourcenverbrauch. Hier schneidet er deutlich besser ab als Apache und ist zudem ebenfalls quelloffen unter der BSD-Lizenz – daher verliert Apache bereits seit einigen Jahren Marktanteile an Nginx. In den Top 1.000 Seiten mit dem h\u00f6chsten Datenvolumen<\/a> erreichte Nginx im Mai 2022 einen Marktanteil von \u00fcber 46%, Apache mehr als 31%.<\/p>\n

\n
\"\"<\/a><\/figure>\n<\/div>\n

Worin unterscheiden sich Nginx und Apache konkret?<\/h2>\n

Architektur<\/h3>\n

Apache besitzt eine prozessbasierte Architektur<\/a>, bei dem pro Anfrage ein Kindprozess (mpm_prefork<\/strong>) oder Thread (mpm_worker<\/strong>) gestartet wird. Threads verbrauchen weniger Ressourcen, allerdings kann sich hier ein fehlerhafter Prozess auch auf andere Verbinden auswirken. Dies ist bei mpm_prefork nicht der Fall, da jede Verbindung ihren eigenen Prozess erh\u00e4lt. Um den physischen Server nicht zu \u00fcberlasten, gibt es f\u00fcr beide Module Limits. Werden mehr Threads oder Prozesse ben\u00f6tigt als zur Verf\u00fcgung stehen, m\u00fcssen Anfragen warten. <\/p>\n

Das wird vor allem mit Keep-Alive zum Problem: Hier werden Verbindungen bewusst \u00fcber einen l\u00e4ngeren Zeitraum offen gehalten – belegen in dieser Zeit aber einen Thread bzw. Prozess. Dies kann bei hoher Anzahl zur \u00dcberlastung des Servers f\u00fchren. Seit Apache 2.4 gibt es mit mpm_event<\/strong> eine Alternative. Es bietet eine bessere Lastverteilung und lagert Keep-Alive Verbindungen in einen eigenen Thread aus, damit neue Anfragen nicht blockiert werden.<\/p>\n

Leistung<\/h3>\n

Am meisten Ressourcen ben\u00f6tigt mpm_prefork<\/strong>: F\u00fcr jede Verbindung muss ein eigener Prozess gestartet und in ihm jedes Apache-Modul geladen werden. Da ein Thread im Kontext des Programms l\u00e4uft, ist dies nicht notwendig – hier reicht einmaliges laden, damit alle Threads gemeinsam darauf zugreifen k\u00f6nnen. mpm_worker<\/strong> und mpm_event<\/strong> sind daher bereits deutlich effizienter. Allerdings m\u00fcssen beide Module zwischen den Threads wechseln. Diese Kontextwechsel sind rechenintensiv, da der bestehende Kontext gesichert und der neue geladen werden muss.<\/p>\n

Nginx setzt auf eine eventbasierte Architektur, hat mit dem mpm_event<\/strong> Modul von Apache jedoch wenig gemeinsam: Es gibt eine Schleife (Event-Loop), die mehrere tausend Anfragen gleichzeitig annehmen und verarbeiten kann. Dies erfolgt asynchron und kann daher in einem einzigen Thread ablaufen – Kontextwechsel entfallen daher komplett. <\/p>\n

Vereinfacht gesagt \u00fcbergibt Nginx Aufgaben an das Betriebssystem, etwa den Inhalt einer Datei auszulesen und merkt sich dies. Statt auf das Ergebnis zu warten (was relativ lange dauert) und dadurch blockiert zu sein, werden zeitgleich andere Aufgaben erledigt, etwa die n\u00e4chste Anfrage anzunehmen. Hat das Betriebssystem die zuvor delegierte Aufgabe (hier das auslesen einer Datei) erledigt, wird dies per R\u00fcckruffunktion (Callback) an Nginx gemeldet. Da Nginx sich dies gemerkt hat, sendet es den Dateiinhalt an die entsprechende Anfrage.<\/p>\n

Bei Apache m\u00fcsste zun\u00e4chst ein Thread bzw. Prozess gestartet werden. Dieser w\u00e4re blockiert, bis die Datei eingelesen und an den Client gesendet wurde. Beides ist bei Nginx nicht der Fall, sodass dieser Webserver mehr Durchsatz bei geringerem Ressourcenverbrauch erzielen kann.<\/p>\n

Dynamische Inhalte<\/h3>\n

Heutzutage m\u00fcssen Webserver nicht nur statische Inhalte wie HTML-Seiten, CSS, Bilder etc. ausliefern. Nahezu \u00fcberall werden Inhalte dynamisch mit PHP, Python, Java und anderen Technologien dynamisch generiert. Diese k\u00f6nnen in Apache mit Modulen wie mod_php<\/strong>, mod_python <\/strong>usw. integriert werden. Dies ist bequem, allerdings m\u00fcssen diese Module in jedem Arbeitsprozess geladen werden. Auch wenn dieser nur statische Inhalte ausliefert, wird z.B. das PHP-Modul geladen. Au\u00dferdem startet Apache f\u00fcr jede Anfrage einen eigenen PHP-Prozess.<\/p>\n

Nginx bietet keine solche Integration und kann nativ nur statische Inhalte ausliefern. F\u00fcr dynamische Inhalte gibt es Schnittstellen wie z.B. FastCGI, um diese an einen eigenen Server auszulagern. Bei PHP w\u00e4re dies beispielsweise PHP-FPM. Der Vorteil: Durch die Auslagerung steigt die Effizienz. PHP, Python oder was man nutzen m\u00f6chte wird nur f\u00fcr die Skripte geladen. Ein Prozessmanager wie PHP-FPM bietet dar\u00fcber hinaus weitere Optimierungen. Beispielsweise kann er X PHP-Prozesse gestartet halten. Damit entf\u00e4llt der Aufwand und die Verz\u00f6gerung, f\u00fcr jede Anfrage zun\u00e4chst einen eigenen Prozess starten zu m\u00fcssen.<\/p>\n

Apache hat hier allerdings bereits vor einiger Zeit nachgebessert: \u00dcber das Modul mod_proxy_fcgi <\/strong>kann man seit Version 2.3 auch einen externen Anwendungsserver per FastCGI anbinden. Somit hat man heutzutage bei Apache die Wahl, ob man die eingebetteten Module oder FastCGI verwenden m\u00f6chte.<\/p>\n

Module<\/h3>\n

Sowohl Apache als auch Nginx lassen sich \u00fcber verschiedene Module erweitern. Im Umgang damit gibt es aber einen gro\u00dfen Unterschied: Apache erlaubt es, Module jederzeit einfach zu installieren, zu aktivieren oder zu deaktivieren. Beispielsweise kann man ein Modul nur f\u00fcr eine bestimmte Seite laden. Bei Nginx m\u00fcssen Module dagegen einkompiliert werden. Wer ein Modul verwenden m\u00f6chte, dass nicht im Standard enthalten ist (z.B. Brotli), muss Nginx zusammen mit diesem kompilieren. Wie das funktioniert, habe ich in einem eigenen Beitrag bereits erkl\u00e4rt<\/a>. Das feste einkompilieren hat bei Nginx allerdings Performance-Vorteile gegen\u00fcber des dynamischen Ladens bei Apache.<\/p>\n

Der Nachteil: Man erh\u00e4lt keine zentralen Aktualisierungen mehr \u00fcber die Paketverwaltung oder Docker-Images. Bei jeder \u00c4nderung muss man sich den Quellcode herunterladen und Nginx neu kompilieren. Dynamische Module gibt es nur in Nginx Plus. Diese Version ist kostenpflichtig, enth\u00e4lt Support und einige Sonderfunktionen. Es lassen sich allerdings auch mit Nginx Plus nicht alle Module dynamisch laden.<\/p>\n

Konfiguration<\/h3>\n

Beide Webserver besitzen eine zentrale Konfigurationsdatei httpd.conf<\/strong> (Apache) bzw nginx.conf <\/strong>f\u00fcr Nginx. Apache bietet zus\u00e4tzlich die M\u00f6glichkeit, in jedem Verzeichnis einer Webseite (DocumentRoot<\/strong>) eine .htaccess<\/strong> Datei zu platzieren. Mit ihr kann man die zentrale Konfiguration erg\u00e4nzen, jeweils f\u00fcr das aktuelle Verzeichnis und ggf. auch die Unterverzeichnisse.<\/p>\n

Das kann praktisch sein, wenn sich mehrere Personen einen Server teilen. So kann jeder eigenst\u00e4ndig seine Seite konfigurieren, ohne dass der Administrator jede \u00c4nderung an der zentralen httpd.conf <\/strong>vornehmen muss. Allerdings ist dieser dezentrale Ansatz schlecht f\u00fcr die Leistung: Bei jeder Anfrage durchsucht Apache das Dateisystem nach m\u00f6glicherweise vorhandenen .htaccess<\/strong> Dateien. Das verursacht zus\u00e4tzliche Last und verz\u00f6gert die Auslieferung. Au\u00dferdem kann dies ein m\u00f6gliches Sicherheitsrisiko sein, weswegen empfohlen wird, dies mit AllowOverride None<\/strong> zu deaktivieren, sofern man die Funktionalit\u00e4t nicht zwingend ben\u00f6tigt.<\/p>\n

Unterst\u00fctzung<\/h3>\n

Nginx und Apache liefern eine solide Dokumentation, die allerdings bei Nginx nur in Englisch und Russisch verf\u00fcgbar ist. Apache liefert eine deutsche Dokumentation – vor allem f\u00fcr Neulinge kann dies sicher eine Hilfe sein. Allerdings ist die deutsche Variante teilweise nicht immer aktuell, sodass die englische Fassung tendenziell zu bevorzugen ist. Vereinzelt finde ich die Inhalte bei Nginx etwas knapp.<\/p>\n

Im Falle von Fragen oder Problemen existiert f\u00fcr beide Webserver eine gro\u00dfe Nutzergemeinde. Man findet zahlreiche Artikel, Forenbeitr\u00e4ge und andere Quellen, die verschiedene Szenarien beschreiben und wo man bei Bedarf auch selbst um Hilfe bitten kann.<\/p>\n

Kompatibilit\u00e4t und \u00d6kosystem<\/h3>\n

Die breiteste Kompatibilit\u00e4t findet man bei Apache: Der Webserver existiert seit etwa drei Jahrzehnten und hat sich bereits vor langem zum Quasi-Standard entwickelt. Vor allem auf gemeinsam genutzten Webspace-Paketen wird er oft eingesetzt. Viele Webanwendungen sind daher mit Apache kompatibel. Die Funktionen k\u00f6nnen \u00fcber zahlreiche Erweiterungen erg\u00e4nzt werden. Damit lassen sich nicht nur alle g\u00e4ngigen Standards umsetzen, sondern bei Bedarf auch kreativere Workarounds. So erlaubt das Modul mod_substitute<\/a> etwa bestimmte Muster zu ersetzen, bevor Apache diese ausliefert.<\/p>\n

Vor einigen Jahren genoss Nginx bei diesen Aspekten eher ein Nischendasein, wird aber auch zunehmend unterst\u00fctzt. Die Anzahl der Module hat ebenfalls zugenommen. F\u00fcr alle Erweiterungen die nicht zum Kern geh\u00f6ren, muss allerdings der gesamte Webserver neu kompiliert werden.<\/p>\n

Alternative: Apache und Nginx einsetzen<\/h2>\n

Man kann auch beide Webserver gemeinsam einsetzen. G\u00e4ngig ist beispielsweise, statische Inhalte von Nginx auszuliefern und nur (bestimmte) dynamische Anfragen an Apache weiterzuleiten. So lassen sich die Vor- und Nachteile beider Programme erheblich ausgleichen: Nginx liefert effizient statische Dateien aus, w\u00e4hrend Apache mit seiner vollen Flexibilit\u00e4t f\u00fcr den Rest zur Verf\u00fcgung steht. Nginx lauscht daf\u00fcr auf den Standartports 80\/443, w\u00e4hrend Apache einen anderen (ausschlie\u00dflich intern genutzten) Port erh\u00e4lt, etwa 81.<\/p>\n

Dies ist beispielsweise dann sinnvoll, wenn man f\u00fcr eine recht stark besuchte Seite spezielle Funktionen von Apache ben\u00f6tigt, aber Leistung und Ressourcenverbrauch optimieren m\u00f6chte. In den meisten F\u00e4llen reicht aber ein Webserver.<\/p>\n

Fazit und Entscheidungshilfe: Nginx oder Apache?<\/h2>\n

Nginx ist auf Leistung und Effizient optimiert – Apache dagegen eher auf Einfachheit, Flexibilit\u00e4t und breite Kompatibilit\u00e4t. So k\u00f6nnte man die Unterschiede grob in einem Satz zusammenfassen. Es ist daher schwer, pauschal einen als besser oder schlechter zu beurteilen. F\u00fcr welchen Webserver sollte man sich nun entscheiden? Ich w\u00fcrde folgende Kriterien zu Hilfe nehmen:<\/p>\n