Apache vs Nginx: Praktische Überlegungen

Der Apache HTTP Server wurde 1995 von Robert McCool erstellt und seit 1999 unter der Leitung der Apache Software Foundation entwickelt. Da der HTTP-Webserver das ursprüngliche Projekt der Stiftung ist und bei weitem die beliebteste Software ist, wird er häufig einfach als "Apache" bezeichnet.

Der Apache-Webserver ist seit 1996 der beliebteste Server im Internet. Aufgrund dieser Beliebtheit profitiert Apache von einer hervorragenden Dokumentation und der integrierten Unterstützung anderer Softwareprojekte.

Apache wird häufig von Administratoren aufgrund seiner Flexibilität, Leistungsfähigkeit und umfassenden Unterstützung ausgewählt. Es ist durch ein dynamisch ladbares Modulsystem erweiterbar und kann eine große Anzahl von interpretierten Sprachen verarbeiten, ohne dass eine Verbindung zu separater Software hergestellt werden muss.

Im Jahr 2002 begann Igor Sysoev mit der Arbeit an Nginx als Antwort auf das C10K-Problem, das für Webserver eine Herausforderung darstellte, zehntausend gleichzeitige Verbindungen als Voraussetzung für das moderne Web zu behandeln. Die erste Veröffentlichung erfolgte im Jahr 2004. Dieses Ziel wurde durch die Verwendung einer asynchronen, ereignisgesteuerten Architektur erreicht.

Nginx hat seit seiner Veröffentlichung aufgrund seiner geringen Ressourcenauslastung und seiner Fähigkeit, sich leicht auf minimaler Hardware skalieren zu lassen, an Popularität gewonnen. Nginx zeichnet sich durch eine schnelle Bereitstellung statischer Inhalte aus und wurde entwickelt, um dynamische Anforderungen an andere Software weiterzuleiten, die für diese Zwecke besser geeignet ist.

Nginx wird häufig von Administratoren aufgrund seiner Ressourceneffizienz und Reaktionsfähigkeit unter Last ausgewählt. Befürworter begrüßen den Fokus von Nginx auf die wichtigsten Webserver- und Proxy-Funktionen.

Apache bietet eine Vielzahl von Multi-Processing-Modulen (Apache nennt diese MPMs), die bestimmen, wie Client-Anforderungen behandelt werden. Grundsätzlich können Administratoren auf diese Weise die Architektur für die Verbindungsverarbeitung einfach austauschen. Diese sind:

Wie Sie sehen, bietet Apache eine flexible Architektur für die Auswahl verschiedener Verbindungs- und Anforderungsbearbeitungsalgorithmen. Die zur Verfügung gestellten Optionen hängen hauptsächlich von der Entwicklung des Servers und dem zunehmenden Bedarf an Parallelität ab, da sich die Internetlandschaft geändert hat.

Nginx kam nach Apache auf die Bühne, mit mehr Bewusstsein für die Parallelitätsprobleme, mit denen Websites in großem Umfang konfrontiert wären. Aufgrund dieses Wissens wurde Nginx von Grund auf für die Verwendung eines asynchronen, nicht blockierenden, ereignisgesteuerten Verbindungsbehandlungsalgorithmus entwickelt.

Nginx erzeugt Worker-Prozesse, von denen jeder Tausende von Verbindungen verarbeiten kann. Die Worker-Prozesse führen dies durch, indem sie einen Fast-Loop-Mechanismus implementieren, der kontinuierlich nach Ereignissen sucht und diese verarbeitet. Durch das Entkoppeln der tatsächlichen Arbeit von Verbindungen kann sich jeder Mitarbeiter nur dann mit einer Verbindung befassen, wenn ein neues Ereignis ausgelöst wurde.

Jede vom Worker behandelte Verbindung wird in die Ereignisschleife eingefügt, in der sie mit anderen Verbindungen besteht. Innerhalb der Schleife werden Ereignisse asynchron verarbeitet, sodass die Arbeit nicht blockierend behandelt werden kann. Wenn die Verbindung getrennt wird, wird sie aus der Schleife entfernt.

Diese Art der Verbindungsverarbeitung ermöglicht es Nginx, mit begrenzten Ressourcen unglaublich weit zu skalieren. Da der Server Single-Threaded ist und Prozesse nicht für jede neue Verbindung erzeugt werden, bleibt die Speicher- und CPU-Auslastung auch in Zeiten hoher Auslastung relativ konstant.

Apache-Server können statische Inhalte mit ihren herkömmlichen dateibasierten Methoden verarbeiten. Die Durchführung dieser Operationen hängt hauptsächlich von den oben beschriebenen MPM-Methoden ab.

Apache kann dynamische Inhalte auch verarbeiten, indem ein Prozessor der betreffenden Sprache in jede seiner Worker-Instanzen eingebettet wird. Auf diese Weise können dynamische Inhalte auf dem Webserver selbst ausgeführt werden, ohne dass externe Komponenten erforderlich sind. Diese dynamischen Prozessoren können durch die Verwendung von dynamisch ladbaren Modulen aktiviert werden.

Die Fähigkeit von Apache, dynamische Inhalte intern zu verarbeiten, bedeutet, dass die Konfiguration der dynamischen Verarbeitung in der Regel einfacher ist. Die Kommunikation muss nicht mit einer zusätzlichen Software koordiniert werden, und Module können einfach ausgetauscht werden, wenn sich die inhaltlichen Anforderungen ändern.

Nginx kann keine dynamischen Inhalte nativ verarbeiten. Um PHP und andere Anforderungen für dynamischen Inhalt zu verarbeiten, muss Nginx zur Ausführung an einen externen Prozessor übergeben und warten, bis der gerenderte Inhalt zurückgesendet wird. Die Ergebnisse können dann an den Kunden weitergeleitet werden.

Für Administratoren bedeutet dies, dass die Kommunikation zwischen Nginx und dem Prozessor über eines der Protokolle konfiguriert werden muss, die Nginx spricht (http, FastCGI, SCGI, uWSGI, memcache). Dies kann die Dinge etwas komplizieren, insbesondere wenn versucht wird, die Anzahl der zulässigen Verbindungen vorherzusagen, da für jeden Anruf an den Prozessor eine zusätzliche Verbindung verwendet wird.

Dieses Verfahren hat jedoch auch einige Vorteile. Da der dynamische Interpreter nicht in den Arbeitsprozess eingebettet ist, ist sein Overhead nur für dynamischen Inhalt vorhanden. Statische Inhalte können auf unkomplizierte Weise bereitgestellt werden und der Dolmetscher wird nur bei Bedarf kontaktiert. Apache kann auch auf diese Weise funktionieren, ohne die Vorteile des vorherigen Abschnitts zu nutzen.

Apache enthält eine Option, die zusätzliche Konfiguration auf Verzeichnisbasis ermöglicht, indem Anweisungen in versteckten Dateien in den Inhaltsverzeichnissen selbst überprüft und interpretiert werden. Diese Dateien werden als "+ .htaccess +" - Dateien bezeichnet.

Da sich diese Dateien in den Inhaltsverzeichnissen selbst befinden, prüft Apache bei der Verarbeitung einer Anforderung jede Komponente des Pfads zur angeforderten Datei auf eine "+ .htaccess +" - Datei und wendet die darin enthaltenen Anweisungen an. Dies ermöglicht effektiv eine dezentrale Konfiguration des Webservers, der häufig zum Implementieren von URL-Umschreibungen, Zugriffsbeschränkungen, Autorisierung und Authentifizierung sowie zum Zwischenspeichern von Richtlinien verwendet wird.

Während die obigen Beispiele alle in der Apache-Hauptkonfigurationsdatei konfiguriert werden können, haben "+ .htaccess +" - Dateien einige wichtige Vorteile. Erstens werden sie sofort implementiert, ohne den Server neu zu laden, da sie jedes Mal interpretiert werden, wenn sie entlang eines Anforderungspfads gefunden werden. Zweitens ist es möglich, nicht privilegierten Benutzern die Kontrolle über bestimmte Aspekte ihres eigenen Webinhalts zu ermöglichen, ohne ihnen die Kontrolle über die gesamte Konfigurationsdatei zu geben.

Dies bietet eine einfache Möglichkeit für bestimmte Web-Software wie Content-Management-Systeme, ihre Umgebung zu konfigurieren, ohne Zugriff auf die zentrale Konfigurationsdatei zu gewähren. Dies wird auch von gemeinsam genutzten Hosting-Anbietern verwendet, um die Kontrolle über die Hauptkonfiguration zu behalten und den Clients gleichzeitig die Kontrolle über ihre spezifischen Verzeichnisse zu geben.

Nginx interpretiert keine "+ .htaccess +" - Dateien und bietet auch keinen Mechanismus zum Auswerten der Konfiguration pro Verzeichnis außerhalb der Hauptkonfigurationsdatei. Dies ist möglicherweise weniger flexibel als das Apache-Modell, hat jedoch seine eigenen Vorteile.

Die bemerkenswerteste Verbesserung gegenüber dem "+ .htaccess " - System der Konfiguration auf Verzeichnisebene ist die gesteigerte Leistung. Bei einem typischen Apache-Setup, das in einem beliebigen Verzeichnis " .htaccess " zulässt, sucht der Server bei jeder Anforderung in jedem der übergeordneten Verzeichnisse, die zur angeforderten Datei führen, nach diesen Dateien. Wenn bei dieser Suche eine oder mehrere ` .htaccess +` - Dateien gefunden werden, müssen diese gelesen und interpretiert werden. Wenn Verzeichnisüberschreibungen nicht zugelassen werden, kann + Nginx Anforderungen schneller bearbeiten, indem für jede Anforderung eine einzelne Verzeichnissuche und ein Dateilesevorgang durchgeführt wird (vorausgesetzt, die Datei befindet sich in der herkömmlichen Verzeichnisstruktur).

Ein weiterer Vorteil ist die Sicherheit. Durch das Verteilen des Konfigurationszugriffs auf Verzeichnisebene wird auch die Verantwortung für die Sicherheit auf einzelne Benutzer verteilt, denen möglicherweise nicht vertraut wird, dass sie diese Aufgabe gut ausführen. Wenn Sie sicherstellen, dass der Administrator die Kontrolle über den gesamten Webserver behält, können einige Sicherheitsfehler vermieden werden, die auftreten können, wenn anderen Parteien Zugriff gewährt wird.

Denken Sie daran, dass es in Apache möglich ist, die "+ .htaccess +" - Interpretation zu deaktivieren, wenn diese Bedenken bei Ihnen Anklang finden.

Apache bietet die Möglichkeit, eine Anforderung als physische Ressource im Dateisystem oder als URI-Speicherort zu interpretieren, für den möglicherweise eine abstraktere Auswertung erforderlich ist. Im Allgemeinen verwendet Apache für frühere Anwendungen die Blöcke + <Directory> + oder + <Files> +, während für abstraktere Ressourcen die Blöcke + <Location> + verwendet werden.

Da Apache von Grund auf als Webserver konzipiert wurde, werden Anforderungen normalerweise als Dateisystemressourcen interpretiert. Zunächst wird der Dokumentstamm verwendet und der Teil der Anforderung nach der Host- und Portnummer angehängt, um zu versuchen, eine tatsächliche Datei zu finden. Grundsätzlich wird die Dateisystemhierarchie im Web als verfügbarer Dokumentbaum dargestellt.

Apache bietet eine Reihe von Alternativen für den Fall, dass die Anforderung nicht mit dem zugrunde liegenden Dateisystem übereinstimmt. Beispielsweise kann eine Direktive "+ Alias ​​" verwendet werden, um eine alternative Position zuzuordnen. Die Verwendung von ` <Location> +` - Blöcken ist eine Methode, um mit dem URI selbst anstatt mit dem Dateisystem zu arbeiten. Es gibt auch Varianten für reguläre Ausdrücke, mit denen die Konfiguration im gesamten Dateisystem flexibler angewendet werden kann.

Während Apache sowohl auf dem zugrunde liegenden Dateisystem als auch auf dem Webspace arbeiten kann, neigt es stark zu Dateisystemmethoden. Dies ist in einigen Entwurfsentscheidungen zu sehen, einschließlich der Verwendung von "+ .htaccess +" - Dateien für die Konfiguration pro Verzeichnis. Die Apache docs warnen selbst davor, URI-basierte Blöcke zu verwenden, um den Zugriff einzuschränken, wenn die Anforderung das zugrunde liegende Dateisystem spiegelt.

Nginx wurde sowohl als Webserver als auch als Proxyserver erstellt. Aufgrund der für diese beiden Rollen erforderlichen Architektur wird hauptsächlich mit URIs gearbeitet, die bei Bedarf in das Dateisystem übersetzt werden.

Dies kann auf einige Arten gesehen werden, wie Nginx-Konfigurationsdateien erstellt und interpretiert werden. Nginx bietet keinen Mechanismus zum Angeben der Konfiguration für ein Dateisystemverzeichnis und analysiert stattdessen den URI selbst.

Beispielsweise sind die primären Konfigurationsblöcke für Nginx die Blöcke "+ server " und " location ". Der " server " - Block interpretiert den angeforderten Host, während die " location +" - Blöcke für die Zuordnung von Teilen der URI verantwortlich sind, die nach dem Host und dem Port kommen. Zu diesem Zeitpunkt wird die Anforderung als URI und nicht als Speicherort im Dateisystem interpretiert.

Bei statischen Dateien müssen alle Anforderungen schließlich einem Speicherort im Dateisystem zugeordnet werden. Zunächst wählt Nginx die Server- und Standortblöcke aus, die die Anforderung verarbeiten, und kombiniert dann den Dokumentstamm mit dem URI, wobei alle erforderlichen Anpassungen entsprechend der angegebenen Konfiguration vorgenommen werden.

Dies mag ähnlich erscheinen, aber das Parsen von Anforderungen in erster Linie als URIs anstelle von Dateisystempositionen ermöglicht es Nginx, einfacher sowohl in Web- als auch in Mail- und Proxyserverrollen zu funktionieren. Nginx wird einfach konfiguriert, indem festgelegt wird, wie auf verschiedene Anforderungsmuster reagiert werden soll. Nginx überprüft das Dateisystem erst, wenn es bereit ist, die Anfrage zu bearbeiten. Dies erklärt, warum es keine Form von "+ .htaccess +" - Dateien implementiert.

Mit dem Apache-Modulsystem können Sie Module dynamisch laden oder entladen, um Ihre Anforderungen während des Betriebs des Servers zu erfüllen. Der Apache-Core ist immer vorhanden, während Module ein- oder ausgeschaltet werden können, um zusätzliche Funktionen hinzuzufügen oder zu entfernen und sich an den Hauptserver anzuschließen.

Apache nutzt diese Funktionalität für eine Vielzahl von Aufgaben. Aufgrund des Reifegrads der Plattform steht eine umfangreiche Modulbibliothek zur Verfügung. Diese können verwendet werden, um einige der Kernfunktionen des Servers zu ändern, wie z. B. "+ mod_php +", das einen PHP-Interpreter in jeden ausgeführten Worker einbettet.

Module sind jedoch nicht auf die Verarbeitung dynamischer Inhalte beschränkt. Sie können unter anderem zum Umschreiben von URLs, Authentifizieren von Clients, Absichern des Servers, Protokollieren, Zwischenspeichern, Komprimieren, Proxys, Beschränken der Übertragungsrate und Verschlüsseln verwendet werden. Dynamische Module können die Kernfunktionalität ohne großen Mehraufwand erheblich erweitern.

Nginx implementiert auch ein Modulsystem, das sich jedoch stark vom Apache-System unterscheidet. In Nginx können Module nicht dynamisch geladen werden, daher müssen sie ausgewählt und in die Kernsoftware kompiliert werden.

Für viele Benutzer wird Nginx dadurch weniger flexibel. Dies gilt insbesondere für Benutzer, die es nicht mögen, ihre eigene kompilierte Software außerhalb des herkömmlichen Paketsystems ihrer Distribution zu warten. Während Distributionspakete in der Regel die am häufigsten verwendeten Module enthalten, müssen Sie den Server selbst aus dem Quellcode erstellen, wenn Sie ein nicht standardmäßiges Modul benötigen.

Nginx-Module sind jedoch nach wie vor sehr nützlich und ermöglichen es Ihnen, festzulegen, was Sie von Ihrem Server erwarten, indem Sie nur die Funktionen einbeziehen, die Sie verwenden möchten. Einige Benutzer halten dies möglicherweise auch für sicherer, da keine beliebigen Komponenten in den Server eingebunden werden können. Wenn Ihr Server jedoch jemals in eine Position gebracht wird, in der dies möglich ist, ist dies wahrscheinlich bereits gefährdet.

Nginx-Module ermöglichen viele der gleichen Funktionen wie Apache-Module. Zum Beispiel können Nginx-Module Proxy-Unterstützung, Komprimierung, Ratenbegrenzung, Protokollierung, Umschreiben, Geolokalisierung, Authentifizierung, Verschlüsselung, Streaming und E-Mail-Funktionalität bereitstellen.

Da Apache schon so lange beliebt ist, ist die Unterstützung für den Server ziemlich allgegenwärtig. Für den Core Server und für aufgabenbasierte Szenarien, in denen Apache mit anderer Software verbunden wird, steht eine große Bibliothek mit Erst- und Drittanbieter-Dokumentation zur Verfügung.

Neben der Dokumentation enthalten viele Tools und Webprojekte Tools, mit denen sie sich in einer Apache-Umgebung selbst booten können. Dies kann in den Projekten selbst oder in den Paketen enthalten sein, die vom Verpackungsteam Ihrer Distribution verwaltet werden.

Im Allgemeinen wird Apache aufgrund seines Marktanteils und der verfügbaren Zeit mehr Unterstützung durch Projekte von Drittanbietern erhalten. Administratoren haben wahrscheinlich auch etwas mehr Erfahrung mit Apache. Dies liegt nicht nur an seiner Verbreitung, sondern auch daran, dass viele Benutzer mit Shared-Hosting-Szenarien beginnen, die aufgrund der verteilten Verwaltungsfunktionen von "+ .htaccess +" fast ausschließlich auf Apache angewiesen sind.

Nginx erfährt eine zunehmende Unterstützung, da immer mehr Benutzer es für sein Leistungsprofil verwenden. In einigen Schlüsselbereichen besteht jedoch noch Nachholbedarf.

In der Vergangenheit war es schwierig, eine umfassende englischsprachige Dokumentation zu Nginx zu finden, da der größte Teil der frühen Entwicklung und Dokumentation auf Russisch erfolgte. Als das Interesse an dem Projekt zunahm, wurde die Dokumentation ausgefüllt, und auf der Nginx-Website und über Dritte stehen jetzt zahlreiche Verwaltungsressourcen zur Verfügung.

In Bezug auf Anwendungen von Drittanbietern werden Support und Dokumentation immer leichter verfügbar, und Paketbetreuer beginnen in einigen Fällen, zwischen der automatischen Konfiguration für Apache und Nginx zu wählen. Auch ohne Unterstützung ist die Konfiguration von Nginx für die Verwendung alternativer Software in der Regel unkompliziert, sofern das Projekt selbst seine Anforderungen (Berechtigungen, Header usw.) dokumentiert.