NGINX vs. Apache: Vergleich der beliebtesten Open-Source-Webserver (2023)

Die erste Version vonApache HTTP-Servererschien 1995. Noch heute, mehr als 20 Jahre später, ist Software die Nummer eins unter den Webhostern, aber nicht ohne Konkurrenz. Erstens der russische WebserverIch bin XGenericName(ausgesprochen "Engine-X"), ebenfalls ein Open-Source-Projekt, gewinnt Marktanteile, und das mit halsbrecherischer Geschwindigkeit. Besonders schmerzlich für die Apache Foundation: Die meisten Seiten, die auf derAlexa-Rankingfunktionieren gut, da sie über NGINX geliefert werden. Diese zeigt regelmäßig aktualisierte Statistiken ausW3Techs.

Nicht nur russische Internetgiganten wie die Suchmaschinen Rambler und Yandex, der E-Mail-Dienst Mail.RU oder das soziale Netzwerk VK setzen auf den leichtgewichtigen Webserver; Auch internationale Anbieter wie Dropbox, Netflix, WordPress und FastMail.com nutzen NGINX, um die Performance ihrer Dienste zu verbessern. Wird der Apache HTTP-Server bald veraltet sein?

Inhaltsverzeichnis

1. Die Web 2.0-Herausforderung
2. architektonische Unterschiede
   1. Verbindungsmanagement
   2. Statisches und dynamisches Web-Content-Management
   3. Interpretation von Kundenaufträgen.
   4. die Einstellungen
3. Erweiterungsmöglichkeiten
4. Dokumentation und Support
5. Kompatibilität und Ökosystem
6. NGINX vs. Apache: Die Unterschiede auf einen Blick
7. Fazit

o ApacheHTTPServer ist ein Softwareprojekt, das unter der Schirmherrschaft der Apache Foundation gefördert wird. Im Geschäftsjargon der Internetgemeinde wird der Name des Webservers oft mit „Apache“ abgekürzt.verkürzt. Auch wir halten uns an diese Konvention: Wenn im Folgenden von „Apache“ die Rede ist, ist immer die Software und nicht der Hersteller gemeint.

Owen Garrett, Produktmanager bei Nginx, Inc., verweist auf den Apache-Webserver in aBlogartikel vom 9. Oktober 2015als „Rückgrat“ derInternet 1.0und unterstreicht damit seine Bedeutung für die Entwicklung des Internets um die Jahrtausendwende. Der große Erfolg des Webservers ist vor allem auf die einfache Architektur der Software zurückzuführen. Dem liegen jedoch Designentscheidungen zugrunde, die auf einem World Wide Web basieren, das mit dem heutigen nicht zu vergleichen ist. Vor 20 Jahren waren Websites viel einfacher, Bandbreite war begrenzt und teuer, während CPU-Rechenzeit vergleichsweise billiger war.

Heute haben wir es mit einem World Wide Web der zweiten Generation zu tun, und das zeigt sich von einer ganz anderen Seite: Die Zahl der Nutzer und der weltweite Webverkehr haben sich vervielfacht. Das Gleiche gilt für die durchschnittliche Größe von Webseiten im Web und die Anzahl der Komponenten, die ein Webbrowser abfragt und abfragtbietenmüssen sie anzeigen. Ein zunehmender Teil der Internet-Community ist den Möglichkeiten von ausgesetztWeb 2.0aufgewachsen. Diese Benutzergruppe ist es nicht gewohnt, mehrere Sekunden oder sogar Minuten auf das Laden einer Website zu warten.

Diese Entwicklungen haben den Apache HTTP-Server in den letzten Jahren immer wieder vor Herausforderungen gestellt. Owen Garrett macht das wieder wettProzessbasierte Apache-Architekturverantwortlich, die angesichts des stark steigenden Verkehrsaufkommens nicht gut skaliert werden kann. Diese Schwäche war einer der Hauptgründe für die Entwicklung von NGINX im Jahr 2002, die mit a begannEreignisgesteuerte Architekturganz andere Wege gehen. NGINX geht auf den russischen Softwareentwickler Igor Sysoev zurück, der die Software entwickelt hat, die auch als Webserver verwendet wird,Reverse-Proxyund es kommt ein E-Mail-Proxy zum Einsatz, der speziell auf die Bedürfnisse der russischen Suchmaschine Rambler angepasst istangepasst.

Wir vergleichen die beiden Webhoster und gehen auf architektonische Unterschiede, Konfiguration, Erweiterungsmöglichkeiten sowie Kompatibilität, Dokumentation und Support ein.

Eine allgemeine Einführung zu den beiden Open-Source-Webhostern in unserem Vergleich und deren Installation und Konfiguration finden Sie in den grundlegenden Artikeln unterApachejIch bin XGenericName.

Der Hauptunterschied zwischen Apache- und NGINX-Open-Source-Webservern besteht darin, wie sie damit arbeiteneingehende Kundenanfragenweglaufen. Während Apache auf einer prozessbasierten Architektur basiert, basiert das Verbindungsmanagement von NGINX auf einem ereignisgesteuerten Verarbeitungsalgorithmus. Dadurch können Sie Anfragen ressourcenschonend bearbeiten, auch wenn sie von vielen Verbindungen gleichzeitig kommen. Dies wird von NGINX-Entwicklern und anderen als großer Vorteil gegenüber dem Apache-HTTP-Server genannt. Ab Version 2.4 bietet es jedoch auch die Möglichkeit, Events zu implementieren. Die Unterschiede liegen also im Detail.

Der Apache-Webserver verfolgt einen Ansatz, bei dem jede Client-Anfrage von einem separaten Prozess oder Thread behandelt wird. Das ist ineinzelner Strang– der ursprüngliche Betriebsmodus des Apache HTTP-Servers – früher oder späterProbleme mit der E/A-Blockierungverbunden: Prozesse, die Schreib- oder Leseoperationen erfordern, werden strikt nacheinander abgearbeitet. Eine nachfolgende Anforderung bleibt in der Warteschlange, bis die vorherige erfüllt ist. Dies kann vermieden werden, indem mehrere Singlethread-Prozesse gleichzeitig gestartet werden, eine Strategie, die mit einem hohen Ressourcenverbrauch verbunden ist.

alternativ kommenMulti-Threading-Mechanismusbenutzen. Im Gegensatz zum Single-Threading, bei dem in jedem Prozess nur ein Thread verfügbar ist, um auf Clientanforderungen zu reagieren, bietet Multithreading die Möglichkeit, mehrere Threads in einem einzigen Prozess auszuführen. Da Threads unter Linux weniger Ressourcen benötigen als Prozesse, bietet Multithreading die Möglichkeit, die großen Ressourcenanforderungen der prozessbasierten Architektur des Apache HTTP-Servers auszugleichen.

Mechanismen für die parallele Verarbeitung von Client-Anforderungen in Apache können mit einem von drei eingebaut werdenMehrfachverarbeitungsmodul (MPM):mpm_prefork,mpm_worker,mpm_event.

• mpm_prefork:Das Apache „Prefork“-Modul bietet Multi-Thread-Management basierend auf aEinzigartiger Einfädelmechanismus. Das Modul erzeugt einen übergeordneten Prozess, der eine Reihe von untergeordneten Prozessen bereitstellt. In jedem untergeordneten Prozess läuft ein Thread, der es ermöglicht, einzeln auf eine Client-Anfrage zu antworten. Solange es mehr Single-Thread-Prozesse als eingehende Client-Anforderungen gibt, werden die Anforderungen gleichzeitig verarbeitet.
  Die Anzahl der verfügbaren Singlethread-Prozesse wird durch die Serverkonfigurationsoptionen MinSpareServers und MaxSpareServers definiert. Freieres hat die oben erwähnten Leistungsnachteile von Single-Thread. Der Vorteil ist jedoch die große Unabhängigkeit von getrennten Prozessen: Geht eine Verbindung aufgrund eines fehlerhaften Prozesses verloren, hat dies in der Regel keine Auswirkungen auf Verbindungen, die in anderen Prozessen verarbeitet werden.

• mpm_worker: Mit dem "Worker"-Modul stellt Apache den Benutzern eineMultithreading-Mechanismuszur parallelen Bearbeitung von Kundenanfragen zur Verfügung. Mit der Serverkonfigurationsoption ThreadsPerChild können Sie festlegen, wie viele Threads pro Prozess gestartet werden können. Das Modul stellt einen Thread pro TCP-Verbindung bereit. Solange mehr Threads verfügbar sind als Clientanfragen empfangen werden, werden Anfragen parallel verarbeitet. Der übergeordnete Prozess (httpd).
  MinSpareThreads- und MaxSpareThreads-Befehle stehen Benutzern zur Verfügung, um die Anzahl der inaktiven Threads festzulegen, über der neue Threads erstellt oder laufende Threads aus dem Speicher entfernt werden. Das Arbeitsmodul hat adeutlich geringerer Ressourcenbedarfwie das Prefork-Modul. Da Verbindungen jedoch nicht in separaten Prozessen verarbeitet werden, kann ein fehlerhafter Thread den gesamten Multithread-Prozess und damit alle darin verarbeiteten Verbindungen beeinträchtigen. Außerdem unterliegt der Worker, wie auch der Prefork, einem Overhead, der durch sogenannte Keep-Alive-Verbindungen verursacht wird (siehe unten).

• mpm_evento:Seit Version 2.4 verfügt Apache HTTP Server über ein drittes Multiprocessing-Modul für den produktiven Einsatz: Event. Dies ist eine Variante des Worker-Moduls, das die Last auf die gestarteten Threads verteilt. Außerdem gibt es einen Aufruf für jeden Multithread-Prozess.Hördrahtfür Ihren Gebrauch, der eingehende Client-Anforderungen akzeptiert und zugehörige Aufgaben an Worker-Threads weiterleitet.
  Das Ereignismodul wurde entwickelt, um Anrufe abzuwickelnWartungsanschlüssezu optimieren, dh TCP-Verbindungen, die aufrechterhalten werden, um die Übertragung von mehr Anfragen von Clients oder Antworten von Servern zu ermöglichen. Wenn das klassische Worker-Modul verwendet wird, halten Worker-Threads normalerweise aufgebaute Verbindungen und blockieren daher auch, wenn keine weiteren Anfragen eingehen. Dies kann bei vielen Dauerverbindungen den Server überlasten. Das Ereignismodul hingegen verlagert die Wartung permanenter Verbindungen auf den separaten Listening-Thread. Daher werden Worker-Threads nicht blockiert und stehen für die Verarbeitung anderer Anforderungen zur Verfügung.

Die folgende Grafik zeigt eine schematische Darstellung der prozessbasierten Architektur des Apache-Webservers unter Verwendung des Worker-Moduls:

Je nachdem, welches Modul verwendet wird, löst Apache diesGleichzeitigkeitsproblem(auch "Parallelität", die gleichzeitige Beantwortung mehrerer Client-Anfragen) durch zusätzliche Prozesse oder Threads. Beide Lösungsstrategien sind mit dem Aufwand zusätzlicher Ressourcen verbunden. Dies wird zu einem einschränkenden Faktor bei der Skalierung eines Apache-Servers.

Der enorme Ressourcenbedarf des One-Process-per-Connection-Ansatzes liegt darin begründet, dass für jeden weiteren Prozess eine separate Laufzeitumgebung bereitgestellt werden muss. Dies erfordert separate CPU-Zeit und Speicherzuweisung. Außerdem muss jedes für einen Arbeitsprozess verfügbare Apache-Modul für jeden Prozess separat geladen werden. Threads hingegen teilen sich eine Ausführungsumgebung (das Programm) und einen Adressraum im Speicher. Daher ist der Overhead zusätzlicher Threads deutlich geringer als der von Prozessen. Allerdings ist selbst Multithreading rechenintensiv, wenn es sehr istKontextwechsel (Kontextwechsel)Er kommt an.

Kontextwechsel ist der Prozess, bei dem ein System von einem Prozess oder Thread zu einem anderen wechselt. Dazu müssen Sie den Kontext des beendeten Prozesses oder Threads speichern und den neuen erstellen oder wiederherstellen. Ein zeitaufwändiger Verwaltungsvorgang, bei dem CPU-Register und mehrere Tabellen und Listen geladen und gespeichert werden müssen.

das Modulmpm_eventda ist einEreignismechanismusan den Apache HTTP-Server, der die eingehende Verbindungsverarbeitung an einen lauschenden Thread auslagert. Dadurch können Sie nicht mehr benötigte Verbindungen (auch dauerhafte Verbindungen) beenden und so den Ressourcenverbrauch reduzieren. Es löst nicht das Problem des rechenintensiven Kontextwechsels, der auftritt, wenn der Listener-Thread Anforderungen an separate Worker-Threads über die von ihm unterhaltenen Verbindungen weiterleitet.

die NullEreignisbasierte NGINX-Architekturjedoch erledigtGleichzeitigkeit, ohne dass für jede neue Verbindung ein zusätzlicher Prozess oder Thread erforderlich ist. Ein einzelner NGINX-Prozess kann Tausende von HTTP-Verbindungen gleichzeitig verarbeiten. Dies geschieht durch einen Schleifenmechanismus namensEreignisschleife. Dadurch können Clientanforderungen asynchron in einem Thread verarbeitet werden.

Theoretisch kann NGINX Verbindungen mit einem einzigen Single-Threaded-Prozess verarbeiten. Um die Hardwarenutzung zu optimieren, beginnt der Webserver jedoch normalerweise mit einem Arbeitsprozess pro Prozessorkern (CPU) der zugrunde liegenden Maschine.

Im Gegensatz zum Apache-Webserver, bei dem die Anzahl der aktiven Prozesse oder Threads nur durch Minimal- und Maximalwerte begrenzt werden kann, bietet NGINX einevorhersagbares Prozessmodell, die genau zur zugrunde liegenden Hardware passt. Dazu gehören ein Masterprozess, der Hilfsprozess Cache Loader und Cache Manager sowie mehrere Worker-Prozesse, die auf die Anzahl der Prozessorkerne skalieren und per Konfiguration genau definiert werden.

• Meisterprozess:Der Master-Prozess ist ein Prozess der obersten Ebene, der alle grundlegenden Operationen ausführt. Dazu gehören das Lesen der Serverkonfiguration, die Portbindung und das Erstellen aller der folgenden Prozesstypen.

• Hilfsprozesse:NGINX verwendet zwei Hilfsprozesse für die Cache-Verwaltung: Cache Loader und Cache Manager.
  • Cache-Loader:Der Cache Loader ist für das Laden des festplattenbasierten Caches in den Arbeitsspeicher verantwortlich.
  
  
  • Cache-Manager: Die Aufgabe des Cache-Managers besteht darin, sicherzustellen, dass Einträge im Festplatten-Cache die vorkonfigurierte Größe haben, und sie gegebenenfalls zu kürzen. Dieser Prozess wird periodisch aufgerufen.

• Arbeitsprozess:Worker-Prozesse sind für die Verarbeitung von Verbindungen, das Schreiben und Lesen von Festplattenzugriffen und die Kommunikation mit Upstream-Servern (Servern, die Dienste für andere Server bereitstellen) verantwortlich. Dies sind die einzigen Prozesse im NGINX-Prozessmodell, die kontinuierlich aktiv sind.

Die folgende Grafik zeigt eine schematische Darstellung des NGINX-Prozessmodells:

Alle Worker-Prozesse, die vom NGINX-Master-Prozess als Teil der Konfiguration gestartet werden, teilen sich einen Satz vonhörende Anschlüsse(Kommunikationsendpunkte). Anstatt für jede eingehende Verbindung einen separaten Prozess oder Thread zu starten, verfügt jeder Arbeitsprozess über eineEreignisschleifeDies ermöglicht die asynchrone Behandlung von mehreren tausend Verbindungen innerhalb eines Threads, ohne den Prozess zu blockieren. Zu diesem Zweck warten Worker-Prozesse auf lauschenden Sockets kontinuierlich auf Ereignisse, die eingehende Verbindungen auslösen, akzeptieren sie und lesen und schreiben in den Socket, während sie HTTP-Anforderungen verarbeiten.

NGINX bietet keine eigenen Mechanismen zum Verteilen von Verbindungen zu Arbeitsprozessen. Stattdessen werden Kernelfunktionen des Betriebssystems verwendet. Die Schemata, wie eingehende Anforderungen verarbeitet werden, werden von separaten Zustandsmaschinen für HTTP, raw, implementiertTCPwie zum BeispielSMTP, IMAP und POP3 bereitgestellt.

Allgemein kann NGINX als Event-Handler bezeichnet werden, der Informationen über Ereignisse vom Kernel erhält und dem Betriebssystem mitteilt, wie die damit verbundenen Aufgaben zu bearbeiten sind. Die asynchrone Verarbeitung von Aufgaben innerhalb der Ereignisschleife basiert aufEreignisbenachrichtigungen, Callback-Funktionenjdie Stoppuhr. Diese Mechanismen ermöglichen es einem Arbeitsprozess, eine Operation nach der anderen an das Betriebssystem zu delegieren, ohne untätig auf das Ergebnis einer Operation oder auf eine Antwort von Client-Programmen warten zu müssen. NGINX fungiert somit als Orchestrator für das Betriebssystem, das Bytes liest und schreibt.

Diese Art der Verbindungsverwaltung erzeugt nur minimalen Overhead für zusätzliche Verbindungen. Alles, was es braucht, ist einszusätzlicher Dateideskriptor (FD)und ein Minimum an zusätzlichem Speicher im Arbeitsprozess. Rechenintensive Kontextwechsel hingegen treten nur auf, wenn keine anderen Ereignisse innerhalb einer Ereignisschleife auftreten. Diese Effizienz bei der Verarbeitung von Anfragen über mehrere Verbindungen macht NGINX ideal als Load Balancer für stark frequentierte Websites wie WordPress.com.

Mit seiner ereignisbasierten Architektur bietet NGINX eine Alternative zum prozessbasierten Verbindungsmanagement von Apache HTTP-Servern. Dieses Feature allein reicht jedoch nicht aus, um zu erklären, warum NGINX in Benchmark-Tests so gut abschneidet. Apache unterstützt seit Version 2.4 auch eine ereignisbasierte Verarbeitungs-Engine für Client-Anfragen. Achten Sie beim Vergleich von Webservern wie Apache und NGINX immer darauf, welche Module im Test verwendet werden, wie die Webserver konfiguriert sind und welche Aufgaben erledigt werden müssen.

Auch im Umgang mitdynamische WebinhalteNGINX verfolgt eine andere Strategie als der Apache HTTP-Server.

Um dynamische Webinhalte auszuliefern, muss ein Webserver grundsätzlich auf a zugreifenDolmetscherdas in der Lage ist, eine erforderliche Programmiersprache wie PHP, Perl, Python oder Ruby zu verarbeiten. Apache bietet mehrere Module wie zmod_php,mod_perl,mod_pythonÖmod_rubyverfügbar, die es ermöglichen, den entsprechenden Interpreter direkt auf den Webserver zu laden. Daher ist Apache selbst mit der Fähigkeit ausgestattet, dynamische Webinhalte zu verarbeiten, die mit der entsprechenden Programmiersprache erstellt wurden. Die Funktionen zur Bereitstellung statischer Inhalte sind bereits durch die oben genannten MPM-Module implementiert.

NGINX hingegen bietet nur Mechanismen zum Bereitstellen statischer Webinhalte. Die Bereitstellung dynamischer Inhalte wird an Experten gesendetAnwendungsserverausgelagert In diesem Fall fungiert NGINX nur als Proxy zwischen dem Client-Programm und dem Upsteam-Server. Die Kommunikation erfolgt über Protokolle wie HTTP, FastCGI, SCGI, uWSGI undSpeicher. Als möglicher AnwendungsserverWebSphere, JBoss oder Tomcat sind ideal für die Bereitstellung dynamischer Inhalte. Aber auch der Apache HTTP-Server kann für diesen Zweck verwendet werden.

Beide Strategien im Umgang mit statischen und dynamischen Inhalten sind confVorteile und Nachteilezusammengebunden. Ein Modul wiemod_phpermöglicht es dem Webserver, seinen eigenen PHP-Code auszuführen. Ein separater Anwendungsserver ist nicht erforderlich. Dadurch wird die Verwaltung dynamischer Websites sehr komfortabel. Allerdings müssen Interpreter-Module für dynamische Programmiersprachen in jedem Worker-Prozess, der für die Auslieferung der Inhalte zuständig ist, separat geladen werden. Bei einer großen Anzahl von Arbeitsprozessen kann dies mit einem erheblichen Aufwand erfolgenallgemeine Kosteneine lange. NGINX reduziert diesen Overhead, da der Drittanbieter-Interpreter nur bei Bedarf verwendet wird.

Obwohl NGINX so konfiguriert ist, dass es mit einem Drittanbieter-Interpreter interagiert, stehen Apache-Benutzern grundsätzlich beide Strategien offen. Apache kann auch vor einen Anwendungsserver gestellt werden, der dynamische Webinhalte interpretiert. In der Regel wird dafür das FastCGI-Protokoll verwendet. Eine entsprechende Schnittstelle kann mit dem Modul erstellt werdenmod_proxy_fcgigeladen.

Dynamische Webseiten können mit beiden Webhostern in unserem Vergleich ausgeliefert werden. Doch während Apache Module verwendet, um Programmcode zu interpretieren und auszuführen, lagert NGINX diesen Arbeitsschritt auf einen externen Anwendungsserver aus.

Um Anforderungen von Clientprogrammen (z. B. Webbrowsern oder E-Mail-Programmen) erfolgreich zu beantworten, muss ein Server bestimmen, welche Ressource angefordert wird und woher die Anforderung stammt.

Der Apache HTTP Server ist als Webserver konzipiert.Ich bin XGenericNamejedoch AngeboteWebserver und Proxy-Funktionen. Dieser unterschiedliche Ansatz spiegelt sich unter anderem darin wider, wie die jeweilige Software Client-Anfragen interpretiert und Ressourcen auf dem Server zuweist.

Auch der Apache HTTP-Server kann über das Modul konfiguriert werdenmod_proxyals Proxy-Server verwenden.

Apache HTTP Server und NGINX verfügen über Mechanismen, die es ermöglichen, eingehende Anfragen als zu sehenphysische Ressourcen im DateisystemDas WieURI(Uniform Resource Identifier) ​​zu interpretieren. Aber während Apache standardmäßig dateibasiert arbeitet, konzentriert sich NGINX auf die URI-basierte Anfrageverarbeitung.

Wenn der Apache HTTP-Server eine Anfrage von einem Client erhält, geht er standardmäßig davon aus, dass eine bestimmte Ressource aus dem Dateisystem des Servers abgerufen werden muss. weil Apache bedeutetVirtuelle Serverdie Möglichkeit bietet, unterschiedliche Webinhalte auf demselben Server unter unterschiedlichen Hostnamen, IP-Adressen oder Portnummern bereitzustellen, müssen Sie zunächst feststellen, auf welchen VirtualHost sich die Anfrage bezieht. Dazu gleicht der Webserver den Hostnamen, die IP-Adresse und die Portnummer am Anfang der Anforderungs-URI mit denen in der Hauptkonfigurationsdatei ab.httpd.confdefinierte virtuelle Hosts.

Das folgende Codebeispiel zeigt aApache-Konfiguration, wo die beiden Domänenwww.ejemplo.comjwww.otro-ejemplo.comunter derselben IP-Adresse betrieben:

das Sternchen (*) dient als Platzhalter für eine beliebige IP-Adresse. In welchemDokument Root(dem Home-Verzeichnis eines Webprojekts) die angeforderte Ressource gesucht wird, entscheidet Apache, indem er den in der Anfrage enthaltenen Hostnamen mit dem vergleichtServerName-Direktive.

Sobald Apache den gewünschten Server gefunden hat, wird der Anforderungs-URI standardmäßig auf das Dateisystem des Servers abgebildet (Mapping). Apache verwendet dazu die in der URI enthaltene Pfadangabe. In Kombination mit derDocumentRoot stellt den Pfad zur Ressource bereit.

Bei einer Anfrage mit einem Anfrage-URI von „http://www.example.org:80/public_html/images/logo.gif“ würde Apache (wie im obigen Beispiel) im folgenden Dateipfad nach der gewünschten Ressource suchen:

Da 80 der Standardport für HTTP ist, wird diese Angabe in der Praxis oft weggelassen.

Außerdem gleicht Apache den Anforderungs-URI mit Optionen abBlöcke von Dateien und Verzeichnissenin den Einstellungen. Damit können Sie spezielle Anweisungen für Anfragen definieren, die sich auf ausgewählte Dateien oder Verzeichnisse (einschließlich Unterverzeichnisse) beziehen.

Im folgenden Beispiel spezielle Direktiven für das Verzeichnispublic_html/imagesund die Dateiprivat.htmlSie sind definiert:

Wenn Apache Ressourcen abruft, die außerhalb des Dateisystems des Servers gespeichert wurden, wird dieDirektiven Standorttragen. Dadurch ist es möglich, Anweisungen für bestimmte URIs zu definieren.

Was bei Apache eine Ausnahme ist, ist bei NGINX der Standardfall. NGINX analysiert zuerst den Anforderungs-URI und vergleicht ihn mit den Server- und Standortblöcken in der Webserverkonfiguration. Erst dann erfolgt (falls erforderlich) eine Zuordnung zum Dateisystem und die Kombination mit derQuelle(entspricht dem DocumentRoot des Apache-Servers).

wie man hilftPolicy-ServerNGINX bestimmt, welcher Host für die Beantwortung der Anfrage des Clients verantwortlich ist. Der Server-Block entspricht also einem VirtualHost in der Apache-Konfiguration. Dazu werden Hostname, IP-Adresse und Portnummer der Anfrage-URI gegen alle in der Webserver-Konfiguration definierten Serverblöcke geprüft. Das folgende Codebeispiel zeigt drei Serverblöcke innerhalb derNGINX-Konfigurationsdateinginx.conf:

Jeder Serverblock enthält normalerweise eine Reihe vonOrt-Blöcke. Im aktuellen Beispiel wurden sie durch Platzhalter ersetzt (…) ersetzt.

Der Anforderungs-URI wird nicht mit Standortblöcken in einem Serverblock verglichen, bis der angeforderte Server gefunden ist. Dazu liest NGINX die aufgezählten Standortblöcke und sucht nach dem Standort, der am besten zum Anforderungs-URI passt. Jeder Standortblock enthält spezifische Anweisungen, die NGINX mitteilen, wie die entsprechende Anfrage bearbeitet werden soll.

Standorte können so definiert werden, dass sie es sindPräfixfür eine Route, als exakte Übereinstimmung oder alsregulärer Satz(Regulärer Ausdruck, RegEx) interpretiert werden. Die Serverkonfigurationssyntax umfasst FolgendesModifikatorenbenutzen:

Zunächst ermittelt NGINX die spezifischstenPräfix-Standort. Dazu liest der Webserver nacheinander alle Stellen ohne Modifier aus und stoppt an der ersten Stelle, die der Anfrage entspricht. Dann alle Standorte beginnend mit demRegEx-Modifikator (~)sie sind gekennzeichnet. Auch hier wird der Erstschlag verwendet. Wenn keine passende RegEx-Location gefunden wird, verwendet der Webserver die zuvor ermittelte Präfix-Locationkommen Sie als Alternative zurück.

Der Anforderungs-URIwww.ejemplo.org:80/logotipo.gifstimmt beispielsweise mit der Präfixposition überein/sowie den regulären Ausdruck\.(gif|jpg|png)$Spiel. NGINX würde also die Anfrage in Kombination mit root verarbeitenim Dateipfad/data/www/logotipo.gifzuordnen und die entsprechende Ressource an den Client liefern. Kopf verfälltzeigt an, wann eine Antwort als veraltet angesehen wird; im aktuellen Beispiel nach 30 Tagen:Ablauf 30d.

Die Anfrage für die PHP-Seite mit der URIwww.ejemplo.org:80/index.phpstimmt auch mit der Position des Präfixes überein/RegEx-Abgleich und -Lokalisierung~ \.php$,werden bevorzugt behandelt. Daher leitet NGINX die Anfrage an a weiterFastCGI-Server, die ZündungHost-Lokal: 9000überwacht die Verarbeitung dynamischer Webinhalte und verarbeitet diese. Die Richtlinie legt festfastcgi_paramder FastCGI-ParameterSCRIPT_FILENAMEnein/datos/www/index.php. Die Datei wird dann auf dem Upstream-Server abgespielt. Die Variable$document_rootentspricht der Root-Direktive, der Variable$fastcgi_script_nameder Teil des URI, der auf den Hostnamen und die Portnummer folgt:/index.php.

Dieses auf den ersten Blick etwas umständliche Vorgehen zur Interpretation von Kundenanfragen ist den unterschiedlichen Einsatzgebieten geschuldet, in denen NGINX zum Einsatz kommt. Im Vergleich zum hauptsächlich dateibasierten Ansatz von Apache HTTP Server ermöglicht die URI-basierte Anfrageinterpretationgrößere Flexibilität bei der Verarbeitung unterschiedlicher Anforderungsmuster. Dies ist zum Beispiel notwendig, wenn NGINX nicht als Web-, sondern als Proxy-Server oder Mail-Proxy agiert.

Apache wird hauptsächlich als Webserver verwendet und interpretiert Client-Anfragen hauptsächlich auf Dateibasis. NGINX hingegen arbeitet standardmäßig mit URIs und berücksichtigt daher auch andere Anfragemuster.

NGINX wird im Vergleich zu Apache HTTP Server riesigGeschwindigkeitsvorteilinformiert, wenn statische Webinhalte bereitgestellt werden. Dies liegt unter anderem an unterschiedlichen Konfigurationen.

Der Apache-Webserver stellt Handler zusammen mit der Hauptkonfigurationsdatei bereithttpd.confdie Möglichkeit einerVerwaltung auf Verzeichnisebene. Es gibt auch sog.htaccess-Dateien zu verwenden. Diese dezentralen Konfigurationsdateien können im Prinzip in jedem Verzeichnis auf dem Server bereitgestellt werden. Anleitung in einem.htaccessdefiniert beziehen sich auf das Verzeichnis, das die Konfigurationsdatei und ihre Unterverzeichnisse enthält. komm üben.htaccess-Dateien, die verwendet werden, um den Verzeichniszugriff auf bestimmte Benutzergruppen zu beschränken, einen Passwortschutz zu konfigurieren und Regeln für das Durchsuchen von Verzeichnissen, Fehlermeldungen, Weiterleitungen oder alternativen Inhalten festzulegen.

Beachten Sie, dass sich all dies auch zentral im befindethttpd.conf-Archivkann konfiguriert werdenrelevant wird.htaccessjedoch mit Webhosting-Vorlagen wie dieserShared Hosting, wobei der Zugriff auf die Hauptkonfigurationsdatei für den Hosting-Dienstanbieter reserviert ist. Die dezentrale Konfiguration durch.htaccessermöglicht Benutzern, bestimmte Bereiche des Dateisystems des Servers zu verwalten, beispielsweise für ausgewählte Projektverzeichnisse, ohne ihnen Zugriff auf die Hauptkonfiguration zu gewähren. Außerdem werden die Änderungen sofort wirksam, ohne dass ein Neustart erforderlich ist.

NGINX hingegen bietet nur anwichtigsten Konfigurationsoptionen. Alle Anweisungen sind in der Datei.nginx.confSie sind definiert. Mit dem Zugriff auf diese Datei erhält ein Benutzer die Kontrolle über den gesamten Server. Im Gegensatz zu Apache kann der administrative Zugriff nicht auf ausgewählte Verzeichnisse beschränkt werden. Dies hat Vor- und Nachteile. Die Kernkonfiguration von NGINX ist weniger flexibel als das Apache-HTTP-Server-Konzept, bietet aber einen klaren Sicherheitsvorteil: Änderungen an der Webserver-Konfiguration können nur von Benutzern mit Root-Rechten vorgenommen werden.

Wichtiger als das Sicherheitsargument ist jedoch dasPerformance-Nachteil einer dezentralen Einrichtungüber.htaccess. nicht mehr, nicht längerApache HTTP Server-Dokumentationberaten Entwickler bei der Verwendung von.htaccessVerzichten Sie auf den bereitgestellten Zugriff auf diehttpd.confes ist möglich. Grund dafür ist das Verfahren, bei dem Apache Konfigurationsdateien liest und interpretiert.

Wie oben erwähnt, folgt Apache standardmäßig einem dateibasierten Schema, um auf Client-Anfragen zu antworten. Da die Architektur von Apache eine dezentrale Konfiguration zulässt, durchsucht der Webserver alle Verzeichnisse entlang des Dateipfads nach der angeforderten Ressource..htaccess-Archiv. Alle Konfigurationsdateien, die Sie übergeben, werden gelesen und interpretiert, ein Schema, das den Webserver erheblich verlangsamt.

Grundsätzlich bleibt es Apache-Administratoren überlassen, ob sie die dezentralen Konfigurationsmöglichkeiten des Webservers nutzen und die damit verbundenen Kompromisse und Kompromisse in Kauf nehmen wollen. In der Dokumentation betonen die Entwickler das alles.htaccess-Einstellungen mit Verzeichnisblöcken auch in der Haupteinstellunghttpd.confKann gemacht werden.

Im Gegensatz zu NGINX, das nur zentral konfiguriert wird, bietet Apache auch.htaccessdie Möglichkeit einer dezentralen Konfiguration auf Basis von Verzeichnissen. Komm.htaccessDateien verwendet werden, verlangsamt sich der Webserver.

Beide Webserver in unserem Vergleich verwenden aModulares System, wobei die Kernsoftware bei Bedarf um zusätzliche Komponenten erweitert werden kann. Doch bis zur Version 1.9.10 verfolgte NGINX eine grundlegend andere Strategie im Umgang mit Modulen als das Konkurrenzprodukt.

Der Apache HTTP Server bietet zwei Möglichkeiten, die Kernsoftware zu erweitern. Module können während der Entwicklung in Apache-Binärdateien kompiliert oder dynamisch und damit zur Laufzeit geladen werden.

Es lassen sich drei Kategorien unterscheidenApache-Moduleunterscheiden:

• Grundmodule:Apache-Kernmodule umfassen alle Komponenten, die die Kernfunktionalität des Webservers bereitstellen.

• Erweiterungsmodule: Diese Erweiterungen sind Module der Apache Foundation, die Teil der Apache-Distribution sind. Eine Übersicht aller in der Standardinstallation von Apache 2.4 enthaltenen Module finden Sie unterApache-Dokumentation.

• Module von Drittanbietern:Diese Module werden nicht von der Apache Foundation bereitgestellt, sondern von Drittanbietern oder freiberuflichen Entwicklern.

Bei NGINX hingegen war die Modularität lange Zeit auf statische Erweiterungskomponenten beschränkt, die in die Binärdatei der Kernsoftware kompiliert werden mussten. Gerade für Anwender, die es nicht gewohnt waren, eigene Softwarekomponenten ohne den Paketmanager der jeweiligen Distribution zu verwalten, schränkte diese Art der Softwareerweiterung die Flexibilität des Webservers erheblich ein. An diesem Punkt hat das Entwicklerteam nachgebessert: Seit Version 1.9.11 (Veröffentlichung 09.02.2016) unterstützt NGINX-Mechanismen, die es ermöglichenKonvertieren Sie statische Module in dynamische, sodass sie zur Laufzeit über Konfigurationsdateien geladen werden können. In beiden Fällen wird die Servermodul-API verwendet.

Es ist zu beachten, dass nicht alle NGINX-Module in dynamische Module konvertiert werden können. Module, die den Quellcode der Serversoftware patchen, dürfen nicht dynamisch geladen werden. Darüber hinaus begrenzt NGINX die Anzahl der dynamischen Module, die gleichzeitig geladen werden können, standardmäßig auf 128. Um diese Grenze zu erhöhen, definieren Sie die KonstanteNGX_MAX_MODULOS_DYNAMICim NGINX-Quellcode auf den gewünschten Wert.

Zusätzlich zu den offiziellen Modulen in der NGINX-Dokumentation stehen Benutzern mehrere Module von Drittanbietern zur Verfügung.

• NGINX-Erweiterungsmodule
• Module von Drittanbietern für NGINX

Beide Webserver sind modular erweiterbar. Neben statischen Modulen stehen dynamische Module zur Verfügung, die bei Bedarf in das laufende Programm geladen werden können.

Beide Softwareprojekte sind gut dokumentiert und stehen den Benutzern zur Verfügung.Wikis und BlogsInformationen aus erster Hand verfügbar.

• Server Apache HTTP:wiki
• NGINX:wiki

Obwohl die NGINX-Dokumentation nur auf Englisch und Russisch zugänglich ist, zeichnet sich das Apache-Projekt durch informatives Material in mehreren Sprachversionen aus. Allerdings sind diese teilweise veraltet, sodass auch hier ein Blick in die englische Dokumentation unabdingbar ist.

Benutzer beider Open-Source-Projekte können Hilfe bei Problemen über die erhaltenGemeinschaft. Diskussionslisten fungieren als Diskussionsforen.

• Server Apache HTTP:Mailinglisten
• NGINX:Mailinglisten

Release-Pläne und transparente Roadmaps geben Anwendern die Möglichkeit, sich auf zukünftige Entwicklungen vorzubereiten. Software-Bugs und Sicherheitslücken werden bei beiden Projekten in einem öffentlichen Bug-Report protokolliert und aufbereitet.

• Server Apache HTTP:Fehlerbericht
• NGINX:Fehlerbericht

Neben dem Open-Source-Projekt NGINX bietet Nginx, Inc. bietet das Handelsprodukt anNGINX mehrBei der. Für eine jährliche Nutzungsgebühr erhalten Anwender zusätzliche Features und professionellen Support vom Hersteller. 1Vergleichsmatrixbeider Produkte finden Sie auf der NGINX-Website.

Es gibt keine kommerzielle Version von Apache HTTP Server. Mehrere Drittanbieter bieten jedoch kostenpflichtige Supportdienste an.

Sowohl Apache HTTP Server als auch NGINX sind für den professionellen Einsatz auf Produktionssystemen gut dokumentiert.

Der Apache HTTP Server prägt seit über zwei Jahrzehnten das World Wide Web und gilt aufgrund seines Marktanteils immer noch als De-facto-Standard für die Auslieferung von Webinhalten. Auch NGINX kann auf eine 15-jährige Erfolgsgeschichte zurückblicken. Beide Webserver sind gekennzeichnet durch abreite Plattformunterstützungdas Ende. Während Apache für alle Unix-ähnlichen Betriebssysteme sowie Windows empfohlen wird, listet die NGINX-Dokumentation die folgenden getesteten Systeme auf: FreeBSD, Linux, Solaris, IBM AIX, HP-UX, macOS und Windows.

Als Standardserver zeichnet sich Apache durch eine breiteKompatibilität mit Projekten von Drittanbieterndas Ende. Alle relevanten Webstandards sind über Module integrierbar. Darüber hinaus sind die meisten Netzwerkbeteiligten mit Apache-Konzepten vertraut. Webadministratoren und -entwickler stellen ihre ersten Projekte häufig auf kostengünstigen Shared-Hosting-Plattformen bereit. Diese wiederum basieren hauptsächlich auf Apache und auf der Möglichkeit der dezentralen Konfiguration via.htaccess. Darüber hinaus ist Apache HTTP Server Teil mehrerer Open-Source-Softwarepakete für Softwareentwicklung und -tests, wie zXAMPPGenerischerNameo AMPS.

NGINX bietet Benutzern auch ein großes Ökosystem von Modulen. Darüber hinaus unterhält das Entwicklungsteam Partnerschaften mit mehreren proprietären und Open-Source-Softwareprojekten sowie Infrastrukturdienstleistern wie Amazon Web Services, Windows Azure und HP.

Beide Webserver sind eingerichtet. Nutzer können auf ein großes Ökosystem zurückgreifen. Gegenüber NGINX hat Apache den Vorteil, dass sich über die Jahre eine große Nutzergemeinde die Grundlagen des Webservers durchgelesen hat. Die Tatsache, dass Tausende von Administratoren den Quellcode der Software überprüft und verbessert haben, spricht nicht nur für die Sicherheit von Webservern. Neue Benutzer profitieren zudem von der großen Zahl erfahrener Apache-Administratoren, die der Community bei Problemen in Foren oder über Mailinglisten zur Verfügung stehen.

Mit Apache und NGINX stehen Anwendern zwei sichere und stabile Open-Source-Projekte zur Verfügung. Keiner der beiden Webhoster ging in diesem Vergleich jedoch als klarer Gewinner hervor. beide Projekte liegengrundlegend unterschiedliche Designentscheidungendie je nach Verwendung der Software Vor- oder Nachteile haben.

aServer Apache HTTPbietet ein breites Repertoire an Modulen, die zusammen mit den flexiblen Konfigurationsmöglichkeiten zahlreiche Einsatzmöglichkeiten für die Software eröffnen. Der Webserver wird berücksichtigtStandardsoftware für Shared-Hosting-Szenarienund wird sich in diesem Geschäftsfeld weiterhin gegen leichtgewichtige Webhoster wie NGINX behaupten. Die Möglichkeit, Interpreter für Programmiersprachen wie PHP, Perl, Python oder Ruby über Module direkt in den Webserver zu integrieren, ermöglicht die Auslieferung dynamischer Webinhalte ohne separaten Applikationsserver. Dies macht Apache HTTP Server zu einer bequemen Lösung.für kleine und mittlere Websites, wo Inhalte bei Bedarf dynamisch generiert werden.

Ich bin XGenericNameAndererseits gibt es keine Möglichkeit, dynamische Webinhalte nativ zu rendern oder die jeweiligen Interpreter über Module einzubinden. Es wird also in jedem Fall ein separater Applikationsserver benötigt. Dies mag für kleine und mittelgroße Websites wie ein unnötiger Overhead erscheinen. Eine solche Struktur zeigt jedoch ihre Stärken.für große Webprojekteund zunehmendem Verkehr.

kommt meistensNGINX als Load Balancergegen eine Gruppe von Anwendungsservern. Der Load Balancer nimmt eingehende Anfragen entgegen und entscheidet je nach Art der Anfrage, ob er diese im Hintergrund an einen spezialisierten Server weiterleitet. Statische Webinhalte werden direkt von NGINX bereitgestellt. Fordert ein Client hingegen dynamische Inhalte an, leitet der Load Balancer die Anfrage an einen dedizierten Applikationsserver weiter. Er interpretiert die Programmiersprache, kompiliert die angeforderten Inhalte zu einer Webseite und übergibt sie an den Load Balancer zurück, der wiederum die Auslieferung an den Client übernimmt. Auf diese Weise kann ein hohes Verkehrsaufkommen effektiv bewältigt werden.

Darüber hinaus speichert NGINX bereits ausgelieferte Inhalte für eine gewisse Zeit im Cache, sodass neu angeforderte dynamische Inhalte direkt vom Load Balancer ausgeliefert werden können, ohne dass NGINX erneut auf einen Applikationsserver zurückgreifen muss.

Die Auslagerung des Interpreters auf einen oder mehrere separate Back-End-Server hat den Vorteil, dass das Netzwerk der Server einfach skaliert werden kann, indem zusätzliche Back-End-Server hinzugefügt oder unnötige Systeme heruntergefahren werden. In der Praxis verlassen sich viele Anwender auf dieKombination aus NGINX und Apacheund nutzen so die Stärken beider Webserver.