De wereld van webservers: Apache vs. Nginx

Inleiding tot Apache and Nginx

Webservers en protocollen zijn ontworpen om gebruikers in staat te stellen webpagina's te bekijken. Ze sturen een verzoek om een document te bekijken dat door de server wordt geaccepteerd. De host serveert vervolgens in feite het document of de informatie aan de bezoeker. De webserver speelt een centrale rol bij het bekijken en openen van webpagina's in uw browser.

Er zijn veel webservers die u voor dit doel kunt gebruiken. Tot de meest populaire behoren Nginx en Apache. In feite hosten deze servers de meeste websites die momenteel op internet beschikbaar zijn.

Apache en Nginx lijken in veel opzichten op elkaar. Om te beginnen zijn beide webservers open-source. Dit betekent dat iedereen ter wereld ze geheel gratis kan gebruiken. Maar er zijn veel functies die uniek zijn voor elk van de servers. Deze speciale eigenschappen maken ze het meest geschikt voor verschillende toepassingen en doeleinden.

Om u te helpen te beslissen welke webserver superieur of ideaal is voor u, vergelijken we Nginx en Apache. De vergelijking wordt uitgevoerd op basis van een aantal essentiële parameters die cruciaal zijn voor gebruikers van de webservers. Laten we beginnen!

Basisoverzicht

We beginnen met een algemeen overzicht van de twee webservers. Zowel Apache als Nginx hebben een geweldige reputatie opgebouwd in de community. Ze worden geprezen om hun prestaties en worden gebruikt door verschillende bekende organisaties over de hele wereld.

Apache

Apache kwam uit in 1995. Robert McCool ontwikkelde deze HTTP-server onder the Apache Software Foundation, vandaar de naam. Sinds de release gebruiken honderdduizenden mensen over de hele wereld Apache.

De enorme populariteit betekent dat veel software en bronnen van derden er regelmatig mee samenwerken. Dus als u op zoek bent naar een goed ondersteuningsnetwerk met veel integraties, is Apache de juiste keuze voor u. Apache heeft voor veel mensen ook de voorkeur omdat het dynamischer en flexibeler is. Het biedt ook een groter scala aan talen die het kan interpreteren.

Nginx

Nginx is een relatief nieuwere webserver, die in 2004 uitkwam. Het is het resultaat van de inspanningen van Igor Syosev om een probleem aan te pakken dat nu bekendstaat als het C10K-probleem. Dit probleem ontstond toen het voor servers moeilijk begon te worden om grote hoeveelheden verkeer te verwerken. Naarmate steeds meer mensen internet gingen gebruiken, raakten websiteservers overbelast. Het onvermogen van deze servers om duizenden verbindingen tegelijkertijd te verwerken, zorgde ervoor dat sites crashten en uitvielen.

Nginx werd uitgebracht om dit probleem te proberen op te lossen. Daarom heeft de architectuur een ongelooflijk lichtgewicht ontwerp, dat in staat is om te werken met beperkte middelen en hardware. Hoewel het 't meest geschikt is om met statische inhoud te werken, kan het ook worden geïntegreerd met software die dynamische inhoud op de juiste manier kan verwerken.

Capaciteiten voor verkeersverwerking

Nu we een basisidee hebben van elk van de servers, kunnen we dieper op de details ingaan. De eerste functie waarmee we beginnen, zijn de verkeers- en verwerkingscapaciteiten van de afzonderlijke servers. Dit is een van de belangrijkste punten die deze twee platforms van elkaar scheiden. Hun architecturen werken volgens verschillende principes als het gaat om het gelijktijdig verwerken van meerdere verbindingen.

Apache

Apache gebruikt iets dat MPM- Multi-Processing Modules wordt genoemd. Beheerders gebruiken verschillende MPM's om de architectuur voor verbindingsverwerking te manipuleren en aan te passen. Een deel van de aantrekkingskracht van de Apache-webserver is de flexibiliteit die de architectuur biedt. Een dergelijke op modules gebaseerde infrastructuur die de verwerking opdeelt in individuele en groepen threads, maakt het eenvoudiger om op te schalen en aan te passen aan verschillende soorten verbindingen.

Laten we eens kijken naar enkele van de individuele modules die in Apache worden gebruikt:

• mpm_prefork

De eerste is mpm_prefork. Dit is een verwerkingsmodule die verantwoordelijk is voor het afhandelen van de binnenkomende verzoeken van bezoekers. Het maakt één thread of child aan om één verbinding op een bepaald moment af te handelen. Dat betekent dat als het aantal verzoeken kleiner is dan het aantal processen, mpm_prefork behoorlijk efficiënt is in zijn werking.

Verzoeken worden snel verwerkt omdat een afzonderlijke child elk verzoek individueel verwerkt. Maar dit betekent ook dat als het aantal verzoeken het aantal processen overschrijdt, dit de boel aanzienlijk kan vertragen. Als gevolg hiervan slokt de verwerkingsstap van het verzoek veel RAM op.

• mpm_worker

Zoals we al weten, is één thread verantwoordelijk voor één verbinding. Deze module gaat nog een stap verder en stelt u in staat om meerdere threads tegelijk te beheren. Dit is een veel schaalbaardere module in vergelijking met mpm_prefork, die moeite heeft boven een bepaalde drempel. Nieuwe verbindingen kunnen direct aan een thread worden gekoppeld in plaats van te moeten wachten.

• mpm_event

Mpm_event is verantwoordelijk voor het onderhouden van de keep-alive-verbindingen. Het primaire doel van deze module is te voorkomen dat het systeem vastloopt door keep-alive-verzoeken. Dit gebeurt door een thread toe te wijzen aan een verbinding, zelfs zonder de aanwezigheid van een actief verzoek. De thread blijft gereserveerd zolang de verbinding actief is. Eventuele binnenkomende verzoeken worden overgedragen naar onbezette threads.

Nginx

In tegenstelling tot Apache is Nginx gebouwd met een heel specifiek doel voor ogen. We kenden de problemen al die zich voordeden met verbindingen en schaalbaarheid op dit niveau. Daarom maakt het gebruik van een algoritme dat asynchroon en non-blocking is. Het wijst geen individuele threads toe aan elke verbinding. In plaats daarvan produceert Nginx talloze worker-processen die in staat zijn om duizenden verbindingen tegelijk af te handelen.

Het werkingsprincipe achter de architectuur van Nginx is het snelle looping-mechanisme. Dit algoritme verwerkt voortdurend gebeurtenissen en bewaakt deze. Dit betekent dat de processen event-driven zijn en elk worker-proces alleen is toegewezen aan zijn eigen verbindingen. Alle verbindingen van een worker-proces bevinden zich in een event loop. Hier bestaan ze naast elkaar en worden ze asynchroon verwerkt met de andere verbindingen onder deze specifieke worker.

Het grote voordeel van een dergelijke architectuur is dat het een grote capaciteit voor schaalbaarheid biedt. Dit is met name van toepassing als u over beperkte middelen beschikt of met minimale hardware wilt werken. Zelfs als u veel verkeer ervaart, zal de impact op het RAM-gebruik minimaal zijn. Dit komt omdat u geen individuele threads genereert voor elke verbinding.

Statische en dynamische content afhandelen

Een andere parameter die we kunnen gebruiken om de twee webservers te vergelijken, is hoe ze omgaan met statische en dynamische content.

Apache

Apache gebruikt een bestandsgebaseerde methode om met statische content om te gaan. Dankzij het MPM-verwerkingssysteem kan het met deze conventionele methode werken.

Als het gaat om het verwerken van dynamische content, Apache kan dit doen zonder hulp van externe componenten. U kunt de dynamische processors inschakelen door een module te laden. Deze module verwerkt de content door de taal te analyseren en vervolgens de relevante processor in de worker in te sluiten.

Het grote voordeel van het niet hoeven gebruiken van externe componenten om dynamische content te verwerken, is duidelijk bij de configuratie en coördinatie. Het is veel eenvoudiger om alleen interne componenten met elkaar te coördineren.

Nginx

Het grootste verschil tussen de manier waarop Apache en Nginx met content omgaan, is dat Nginx simpelweg niet in staat is om dynamische content intern te verwerken. Het moet worden gekoppeld aan een externe component om verzoeken voor dynamische content te verwerken. Dit betekent dat u uw Nginx-server moet gebruiken in combinatie met een externe processor. De component ontvangt het verzoek voor PHP/dynamische content, verwerkt dit en stuurt het vervolgens terug naar de server.

Aangezien de informatie tussen de twee componenten moet worden doorgegeven, moet u de communicatie tussen beide coördineren. U moet bepalen hoeveel verbindingen u wilt toestaan en het protocol configureren. U moet het protocol gebruiken dat door Nginx kan worden gelezen en begrepen, zoals onder andere HTTP, FastCGI, SCGI, uWSGI of memcache.

Aan de andere kant is Nginx erg goed in het verwerken van statische inhoud. Het heeft wel hulp van externe bronnen nodig om dit te doen. Het zal de interpreter ook alleen activeren wanneer dat nodig is. Dit is een van de voordelen van het gebruik van Nginx. De interpreter is niet ingebed in het proces. Dit betekent dat deze alleen aanwezig is voor het verwerken van dynamische inhoud.

Contentdirectories: Gedistribueerde vs. gecentraliseerde configuratie

Elke webserver heeft zijn eigen contentdirectory. Een van de meest kritieke parameters om Apache en Nginx op te beoordelen, is of ze al dan niet configuratie op directoryniveau toestaan.

Apache

Er zijn bepaalde verborgen bestanden in contentdirectories die richtlijnen bevatten. Dit zijn de .htaccess-bestanden. Met Apache kunt u deze richtlijnen per directory interpreteren. Dus wanneer u een verzoek verzendt, inspecteert Apache het pad naar het bestand om een .htaccess-bestand te vinden. Als dat zo is, zal het de richtlijnen daarin onmiddellijk interpreteren en toepassen. Apache zal de server niet herstarten om deze richtlijnen te implementeren.

Het hierboven gedefinieerde proces maakt gedecentraliseerde configuratie van de directories in de webserver mogelijk. Gedecentraliseerde configuratie is handig voor URL-rewrites, het implementeren van toegangsbeperkingen, het bevestigen van autorisaties en het instellen van cachingbeleid.

Een van de voordelen van het .htaccess-bestand is dat de gebruiker, die geen authenticatie heeft, ten minste een deel van de inhoud die hij in zijn browser bekijkt, kan beheren en wijzigen. Daarom wordt Apache veelvuldig gebruikt door shared hosting providers. De serviceproviders hebben geautoriseerde toegang tot de centrale configuratie. De klanten kunnen controle uitoefenen over bepaalde directories zonder toegang te hebben tot de hoofdconfiguratie.

Als u wilt, is het mogelijk om de .htaccess-interpretatie in Apache uit te schakelen.

Nginx

In tegenstelling tot Apache werkt Nginx niet met .htaccess-bestanden. Dit maakt het relatief minder flexibel. Nginx brengt daarentegen echter een aantal verbeteringen in de configuratiestijl met zich mee. Om te beginnen is het in staat om verzoeken veel sneller te verwerken dan Apache. Dit komt omdat het niet zoekt naar, leest, interpreteert en vervolgens elk .htaccess-bestand implementeert dat het op zijn pad vindt. In plaats van elke bovenliggende directory te doorzoeken, voert Nginx slechts één directory-lookup uit voor één verzoek.

Bovendien heeft Nginx een groot veiligheidsvoordeel ten opzichte van Apache. Nginx draagt, in tegenstelling tot Apache, geen enkel deel van de configuratie van de contentdirectories over aan individuele gebruikers. Hoewel u misschien strikte beveiligingsmaatregelen handhaaft, wie zegt dat de individuele gebruikers hetzelfde kunnen doen? Met Nginx behoudt u de controle over de beveiligingsstatus en configuratie van het gehele directorynetwerk.

Verzoekinterpretatie

Een andere manier om onderscheid te maken tussen de twee servers is de manier waarop ze verzoeken interpreteren.

Apache

Wanneer de server een verzoek ontvangt, interpreteert deze het en koppelt het vervolgens aan de relevante systeembronnen. Het interpreteert het verzoek ofwel als een fysieke bron op het bestandssysteem of als een URI locatie.

Bij het interpreteren als een fysieke bron gebruikt het de <Directory>- of <Files> -blokken. Dit is de standaard interpretatiemethode voor de server. Het neemt de root van het document. Vervolgens volgt het de host en het poortnummer in het verzoek om het relevante bestand in de documentstructuur te vinden.

De URI-locatie daarentegen vereist een abstracte evaluatie. Dus gebruikt Apache de <Location>-blokken voor abstracte bronnen in plaats van te werken met het bestandssysteem.

Naast URI zijn er een aantal andere alternatieven voor het gebruik van het standaard op bestanden gebaseerde systeem. Je kunt bijvoorbeeld de Alias-richtlijn gebruiken om een alternatieve locatie te vinden om naar te mappen. Je kunt ook gebruikmaken van expressievarianten om de configuratie van het bestandssysteem flexibeler te maken.

Nginx

Waar Apache is geboren om een webserver te zijn, vervult Nginx een dubbelrol als zowel web- als proxyserver. Dat is de reden waarom Nginx, in plaats van te leunen op het bestandssysteem, de voorkeur geeft aan het werken met URI's. Je kunt deze voorkeur visualiseren door het feit dat er in Nginx geen manier is om een configuratie voor een bestandssysteemmap op te geven. Het kan echter, indien en wanneer dat nodig is, wel naar het bestandssysteem vertalen.

Server en location zijn de configuratieblokken die voornamelijk in Nginx worden gebruikt. De eerste interpreteert de host die wordt opgevraagd. De laatste matcht de URI-delen na de host en de poort. Als gevolg hiervan interpreteert de server het verzoek als een URI-locatie in plaats van een daadwerkelijk bestand op het systeem.

Vanwege het op URI gebaseerde interpretatiesysteem is Nginx in staat om zijn rol als webserver, proxyserver en mailserver te vervullen. Omdat het bij het interpreteren van het verzoek niet naar het bestandssysteem verwijst, is het begrijpelijk waarom het ook geen .htaccess-bestanden implementeert.

Modulesystemen

Hoewel zowel Apache als Nginx modulesystemen ondersteunen voor uitbreiding, zijn er enkele grote verschillen in hun interne werking.

Apache

Met Apache kun je modules dynamisch laden en weghalen terwijl de server draait. De core blijft het middelpunt van de processen en de modules dienen om de functionaliteit uit te breiden. Je kunt deze koppelbare modules gebruiken om een aantal taken uit te voeren. De opties zijn praktisch eindeloos met de enorme bibliotheek van Apache.

In feite kun je zelfs de werking van de server-core aanpassen door modules zoals  mod_php te gebruiken. Zoals we al eerder hebben vermeld, stelt deze module je in staat om een PHP-interpreter in de individuele worker-processen te integreren. Dit is handig wanneer je dynamische inhoud moet verwerken.

Maar daar houdt het verhaal niet op. Je kunt ook modules toevoegen om functies in te schakelen zoals clientauthenticatie, server hardening, caching, URL-rewriting, proxy's, rate limiting, compressie en encryptie.

Nginx

Het modulesysteem van Nginx is anders in die zin dat je de modules niet dynamisch op de hoofdserver kunt laden. In plaats daarvan moeten ze worden verzameld en gecompileerd op de core-software. Dit laat veel te wensen over op het gebied van flexibiliteit en gebruiksgemak. Hoewel de distributiepakketten enkele veelvoorkomende modules bevatten, zul je de server moeten bouwen voor andere modules. Daarom moet je weten hoe je je gecompileerde software buiten het traditionele pakketbeheersysteem om onderhoudt.

Desalniettemin is het voordeel van dit niet-standaard modulesysteem dat het je een hoge mate van specificiteit geeft. Je kunt je modules aanpassen door alleen de functionaliteiten op te nemen die je nodig hebt. Hierdoor kun je de componenten die je niet nodig hebt achterwege laten en jezelf in het proces behoeden voor beveiligingsrisico's. Tegelijkertijd kun je met Nginx-modules dezelfde taken uitvoeren als met Apache. Denk hierbij aan URL-rewriting, logging, authenticatie, enzovoort.

Ecosysteem en ondersteuning

Integraties en softwareondersteuning zijn erg belangrijk als het gaat om webservers. Vervolgens zullen we de compatibiliteit en ondersteuning verkennen die beschikbaar zijn voor Apache en Nginx.

Apache

Apache is een ouder en populairder platform. Het is dan ook begrijpelijk dat het een groter aanbod aan ondersteunende tools en software heeft in vergelijking met Nginx. Er staat een enorme hoeveelheid documentatie van derden tot je beschikking om de core-server te ondersteunen. Niet alleen dat, maar je kunt het ook koppelen aan andere software om specifieke taken uit te voeren. Je kunt deze tools toevoegen aan je project of aan je pakket. Ze kunnen eenvoudig bootstrappen binnen het Apache-ecosysteem.

Nginx

Hoewel Nginx in dit opzicht achterloopt op Apache, doet het zeker zijn best om een inhaalslag te maken. Steeds meer mensen kiezen voor Nginx naarmate ze het volledige potentieel ervan inzien. De ondersteuning voor het platform blijft groeien, hand in hand met de organische groei als een nuttige, snel verwerkende webserver.

Een van de grootste obstakels voor ondersteuning die Nginx moest overwinnen, was het vinden van documentatie in de Engelse taal. Dit komt omdat het merendeel van Nginx oorspronkelijk in het Russisch is geschreven, inclusief de meeste documentatie. Nu de server zich echter heeft verspreid en bekender is geworden, zijn er tal van bronnen van derden beschikbaar in de universele taal.

Een gezamenlijke oplossing?

Nu heb je een veel beter begrip van de essentiële componenten en de interne werking van Apache en Nginx. Hoewel ze behoorlijk van elkaar verschillen, profiteren sommige gebruikers hiervan om het beste van twee werelden te combineren. Dat’s juist - het is mogelijk om Apache en Nginx samen te gebruiken.

Traditioneel gebruiken gebruikers Nginx vaak als een reverse proxy en plaatsen ze deze vóór Apache. Hiermee kun je het gebrek aan snelheid in de verwerking van verzoeken door Apache compenseren. Nginx ontvangt en verwerkt alle verzoeken op zijn snelst. Het stelt je ook in staat om snel een groot aantal gelijktijdige verzoeken af te handelen zonder dat je veel resources hoeft te investeren.

Een andere functie van Nginx waar gebruikers van profiteren, is het vermogen om statische inhoud efficiënt te verwerken. Om te compenseren dat Nginx een externe component nodig heeft om dynamische inhoud te verwerken, kunnen we PHP- en andere relevante verzoeken via een proxy doorsturen naar Apache. Apache zal het verzoek omzetten in een webpagina en deze terugsturen naar Nginx, zodat deze aan de client kan worden geleverd.

Hier zijn enkele bronnen die je kunt vinden op onze blog om aan de slag te gaan met beide webservers:

Apache

• De Apache-server installeren op Ubuntu 18.04: een handleiding
• Apache Virtual Hosts instellen op Ubuntu 20.04
• Hoe installeer je de Linux, Apache, MySQL, PHP (LAMP) stack op CentOS 7
• Apache beveiligen met Let’s Encrypt op Ubuntu 18.04

Nginx

• Nginx installeren op Ubuntu 18.04
• Automatiseer LetsEncrypt SSL-certificaatverlengingen voor Nginx
• Nginx beveiligen met Let’s Encrypt op Ubuntu 20.04
• Hoe installeer je de LEMP-stack (Linux, Nginx, MySQL PHP) op Ubuntu 20.04

Conclusie

Uiteindelijk hebben zowel Apache als Nginx hun sterke en zwakke punten. Er zijn geen vaste regels of aanbevelingen voor welke server je voor je project moet gebruiken. Je kunt zelf het beste beoordelen wat het beste werkt voor jouw applicatie op basis van jouw unieke vereisten.

Je moet uitzoeken op welke aspecten en functies je geen concessies kunt doen en op basis daarvan je keuze maken. Als het moeilijk is om de beslissing te nemen, kun je er altijd voor kiezen om beide servers samen te gebruiken in een op maat gemaakte oplossing.

Veel plezier met computeren!