Svět webových serverů: Apache vs. Nginx

Úvod do Apache a Nginx

Webové servery a protokoly jsou navrženy tak, aby uživatelům umožnily prohlížet webové stránky. Odesílají požadavek na zobrazení dokumentu, který server přijme. Hostitel pak v podstatě poskytne dokument nebo informace prohlížeči. Webový server hraje klíčovou roli v tom, že vám umožňuje prohlížet webové stránky a přistupovat k nim ve vašem prohlížeči.

Existuje mnoho webových serverů, které můžete pro tento účel použít. Mezi ty nejpopulárnější patří Nginx a Apache. Tyto servery ve skutečnosti hostují většinu webových stránek, které jsou v současné době na internetu dostupné.

Apache a Nginx jsou si v mnoha ohledech velmi podobné. Pro začátek, oba tyto webové servery jsou open-source. To znamená, že je může kdokoli na světě používat zcela zdarma. Existuje však mnoho funkcí, které jsou pro každý ze serverů jedinečné. Tyto speciální vlastnosti je činí nejvhodnějšími pro různé aplikace a účely.

Abychom vám pomohli rozhodnout se, který webový server je pro vás lepší nebo ideální, porovnáme Nginx a Apache. Porovnání bude provedeno na základě řady zásadních parametrů, které jsou pro uživatele webových serverů klíčové. Začněme!

Základní přehled

Začneme obecným přehledem obou webových serverů. Apache i Nginx si v komunitě vybudovaly skvělou pověst. Jsou oceňovány pro svůj výkon a používány řadou známých organizací po celém světě.

Apache

Apache vyšel v roce 1995. Robert McCool vyvinul tento HTTP server pod hlavičkou the Apache Software Foundation, odtud tedy ten název. Od jeho vydání používají Apache stovky tisíc lidí po celém světě.

Jeho obrovská popularita znamená, že s ním často spolupracuje spousta softwaru a zdrojů třetích stran. Pokud tedy hledáte dobrou síť podpory se spoustou integrací, Apache je pro vás ten pravý. Apache je pro mnoho lidí preferovaný také proto, že je dynamičtější a flexibilnější. Nabízí také širší škálu jazyků, které dokáže interpretovat.

Nginx

Nginx je relativně novější webový server, který vyšel v roce 2004. Je výsledkem úsilí Igora Syoseva vyřešit problém, který je dnes známý jako problém C10K. Tento problém vyvstal, když pro servery začalo být obtížné zvládat velké množství provozu. Jak internet začalo používat stále více lidí, servery webových stránek začaly být přetíženy. Neschopnost těchto serverů zpracovat několik tisíc připojení současně způsobovala pády a selhání webů.

Nginx byl vydán s cílem pokusit se tento problém vyřešit. Proto má jeho architektura neuvěřitelně lehký design, který dokáže pracovat s omezenými zdroji a hardwarem. I když je nejvhodnější pro práci se statickým obsahem, dokáže se integrovat i se softwarem, který dokáže vhodně zpracovat i dynamický obsah.

Schopnosti zpracování provozu

Nyní, když máme základní představu o každém ze serverů, můžeme se ponořit do dalších podrobností. První funkcí, kterou začneme, jsou schopnosti zpracování provozu a připojení u jednotlivých serverů. To je jeden z hlavních bodů, které tyto dvě platformy odlišují. Jejich architektury fungují na odlišných principech, pokud jde o souběžné zpracování více připojení.

Apache

Apache používá něco, co se nazývá MPM- Multi-Processing Modules. Administrátoři používají různé MPM k manipulaci a úpravě architektury zpracování připojení. Součástí přitažlivosti webového serveru Apache je flexibilita, kterou jeho architektura nabízí. Taková infrastruktura založená na modulech, která rozděluje zpracování do jednotlivých vláken a skupin vláken, usnadňuje škálování a přizpůsobení se různým typům připojení.

Pojďme se podívat na některé z jednotlivých modulů používaných v Apache:

• mpm_prefork

Prvním z nich je mpm_prefork. Jedná se o procesní modul, který je zodpovědný za zpracování příchozích požadavků od návštěvníků. Vytváří jedno vlákno nebo potomka pro obsluhu jednoho připojení v daném okamžiku. To znamená, že pokud je počet požadavků menší než počet procesů, je mpm_prefork ve své funkci poměrně efektivní.

Požadavky jsou zpracovávány rychle, protože každý z nich zpracovává samostatný potomek individuálně. To však také znamená, že pokud počet požadavků překročí počet procesů, může to věci značně zpomalit. V důsledku toho krok zpracování požadavků spotřebovává velké množství paměti RAM.

• mpm_worker

Jak již víme, jedno vlákno je zodpovědné za jedno připojení. Tento modul jde ještě o krok dále a umožňuje spravovat více vláken najednou. Jedná se o mnohem škálovatelnější modul ve srovnání s mpm_prefork, který má potíže po překročení určité prahové hodnoty. Nová připojení se mohou k vláknu připojit okamžitě, místo aby musela čekat.

• mpm_event

Mpm_event je zodpovědný za udržování keep-alive připojení. Primárním účelem tohoto modulu je zabránit zahlcení systému v důsledku keep-alive požadavků. Činí tak tím, že vyhradí vlákno pro připojení i bez přítomnosti aktivního požadavku. Vlákno zůstane vyhrazené po celou dobu, kdy je připojení aktivní. Jakékoli příchozí požadavky jsou přesměrovány na neobsazená vlákna.

Nginx

Na rozdíl od Apache byl Nginx vytvořen s velmi specifickým účelem. Již jsme věděli o problémech, které na této úrovni vznikaly s připojením a škálovatelností. Proto využívá algoritmus, který je asynchronní a neblokující. Nevyhrazuje jednotlivá vlákna pro každé připojení. Místo toho Nginx vytváří četné pracovní procesy, které jsou schopny zpracovat tisíce připojení najednou.

Pracovním principem architektury Nginx je mechanismus rychlé smyčky. Tento algoritmus neustále zpracovává události a monitoruje je. To znamená, že procesy jsou řízeny událostmi a každý pracovní proces je vyhrazen pouze pro svá vlastní připojení. Všechna připojení pracovního procesu se nacházejí v událostní smyčce. Zde koexistují a jsou zpracovávána asynchronně s ostatními připojeními pod tímto konkrétním pracovním procesem.

Hlavní výhodou takové architektury je, že umožňuje obrovskou kapacitu pro škálovatelnost. To platí zejména v případě, že máte omezené zdroje nebo chcete pracovat s minimálním hardwarem. I když se potýkáte s velkým množstvím provozu, dopad na využití paměti RAM bude minimální. Je to proto, že negenerujete samostatná vlákna pro každé připojení.

Zpracování statického a dynamického obsahu

Dalším parametrem, který můžeme použít k porovnání obou webových serverů, je to, jak zpracovávají statický a dynamický obsah.

Apache

Apache používá k práci se statickým obsahem metodu založenou na souborech. Jeho procesní systém MPM mu umožňuje pracovat s touto konvenční metodou.

Pokud jde o zpracování dynamického obsahu, Apache to dokáže bez pomoci jakýchkoli externích komponent. Dynamické procesory můžete povolit načtením modulu. Tento modul zpracuje obsah analýzou jazyka a následným vložením příslušného procesoru do pracovního procesu.

Hlavní výhoda toho, že pro zpracování dynamického obsahu nemusíte používat externí komponenty, je zřejmá při konfiguraci a koordinaci. Je mnohem snazší koordinovat pouze interní komponenty mezi sebou.

Nginx

Největší rozdíl mezi způsobem, jakým Apache a Nginx zpracovávají obsah, je ten, že Nginx jednoduše není schopen zpracovávat dynamický obsah interně. Pro zpracování požadavků na dynamický obsah musí být spárován s externí komponentou. To znamená, že budete muset používat svůj server Nginx ve spojení s externím procesorem. Tato komponenta přijme požadavek na PHP/dynamický obsah, zpracuje jej a poté jej odešle zpět na server.

Vzhledem k tomu, že informace musí být předávány mezi těmito dvěma komponentami, budete muset koordinovat komunikaci mezi nimi. Budete muset určit, kolik připojení chcete povolit, a nakonfigurovat protokol. Budete muset použít protokol, který dokáže Nginx přečíst a porozumět mu, jako je mimo jiné HTTP, FastCGI, SCGI, uWSGI nebo memcache.

Na druhou stranu Nginx si vede opravdu dobře při zpracování statického obsahu. K tomu sice potřebuje pomoc z jakýchkoli externích zdrojů. Interpret se také aktivuje pouze tehdy, když je potřeba. To je jedna z výhod používání Nginx. Interpret není součástí procesu. To znamená, že bude přítomen pouze pro zpracování dynamického obsahu.

Adresáře obsahu: Distribuovaná vs. centralizovaná konfigurace

Každý webový server má svůj vlastní adresář obsahu. Jedním z nejkritičtějších parametrů, podle kterých lze posuzovat Apache a Nginx, je to, zda umožňují konfiguraci na úrovni adresáře.

Apache

V adresářích obsahu se nacházejí určité skryté soubory, které obsahují direktivy. Jedná se o soubory .htaccess. V případě Apache můžete tyto direktivy interpretovat pro každý adresář zvlášť. Když tedy odešlete požadavek, Apache zkontroluje cestu k souboru, aby našel soubor .htaccess. Jakmile jej najde, okamžitě interpretuje a aplikuje direktivy, které obsahuje. Apache nebude kvůli implementaci těchto direktiv restartovat server.

Výše definovaný proces umožňuje decentralizovanou konfiguraci adresářů ve webovém serveru. Decentralizovaná konfigurace je užitečná pro přepisování URL, implementaci omezení přístupu, potvrzování autorizací a nastavování pravidel pro ukládání do mezipaměti.

Jednou z výhod souboru .htaccess je, že uživatel, který nemá autentizaci, může ovládat a upravovat alespoň některé aspekty obsahu, který si prohlíží ve svém prohlížeči. Proto je Apache často využíván poskytovateli sdíleného hostingu. Poskytovatelé služeb mají autorizovaný přístup k centrální konfiguraci. Klienti pak mohou mít kontrolu nad určitými adresáři, aniž by měli přístup k hlavní konfiguraci.

Pokud chcete, je možné interpretaci .htaccess v Apache vypnout.

Nginx

Na rozdíl od Apache Nginx nepracuje s žádnými soubory .htaccess. Díky tomu je poměrně méně flexibilní. Nginx však místo toho přináší řadu vylepšení ve svém stylu konfigurace. Pro začátek je schopen zpracovávat požadavky mnohem rychleji než Apache. Je to proto, že nevyhledává, nečte, neinterpretuje a následně neimplementuje každý soubor .htaccess, který najde na své cestě. Místo prohledávání každého nadřazeného adresáře provádí Nginx pro jeden požadavek pouze jedno vyhledání adresáře.

Nginx má navíc oproti Apache zásadní bezpečnostní výhodu. Na rozdíl od Apache nepředává Nginx žádnou část konfigurace adresářů obsahu jednotlivým uživatelům. I když vy sami možná dodržujete přísná bezpečnostní opatření, kdo říká, že totéž dokážou i jednotliví uživatelé? S Nginx si zachováváte kontrolu nad stavem zabezpečení a konfigurací celé sítě adresářů.

Interpretace požadavků

Dalším způsobem, jak oba servery odlišit, je způsob, jakým interpretují požadavky.

Apache

Když server přijme požadavek, interpretuje jej a poté jej propojí s příslušnými systémovými prostředky. Interpretuje požadavek buď jako fyzický prostředek v souborovém systému, nebo jako URI umístění.

Při interpretaci jako fyzického prostředku používá bloky <Directory> nebo <Files>  . Toto je výchozí metoda interpretace pro server. Vezme kořen dokumentu. Poté následuje hostitele a číslo portu v požadavku, aby našel příslušný soubor ve stromu dokumentů.

Umístění URI naopak vyžaduje abstraktní vyhodnocení. Apache proto pro abstraktní prostředky používá bloky <Location> namísto práce se souborovým systémem.

Kromě URI existuje celá řada dalších alternativ k použití výchozího souborového systému. Můžete například použít direktivu Alias k nalezení alternativního umístění pro mapování. Můžete také využít varianty výrazů, aby byla konfigurace souborového systému flexibilnější.

Nginx

Zatímco Apache byl stvořen k tomu, aby byl webovým serverem, Nginx plní dvojí roli – funguje jako webový i jako proxy server. Proto Nginx namísto příklonu k souborovému systému dává přednost práci s URI. Tuto preferenci si můžete představit na základě skutečnosti, že v Nginxu neexistuje způsob, jak specifikovat konfiguraci pro adresář souborového systému. V případě potřeby ji však dokáže na souborový systém převést.

Server a location jsou konfigurační bloky, které se v Nginxu používají především. První z nich interpretuje hostitele, který je požadován. Druhý odpovídá částem URI za hostitelem a portem. V důsledku toho server interpretuje požadavek jako umístění URI namísto skutečného souboru v systému.

Díky svému interpretačnímu systému založenému na URI je Nginx schopen plnit roli webového serveru, proxy serveru i poštovního serveru. Vzhledem k tomu, že při interpretaci požadavku neodkazuje na souborový systém, je pochopitelné, proč neimplementuje ani soubory .htaccess.

Modulární systémy

Ačkoli Apache i Nginx nabízejí podporu modulárních systémů pro rozšíření, v jejich vnitřním fungování existují zásadní rozdíly.

Apache

V Apache můžete moduly dynamicky načítat a odebírat za běhu serveru. Jádro zůstává v centru procesů a moduly slouží k rozšíření funkcionality. Tyto připojitelné moduly můžete použít k provádění řady úkolů. Možnosti jsou s rozsáhlou knihovnou Apache prakticky nekonečné.

Ve skutečnosti můžete dokonce upravit funkci jádra serveru pomocí modulů jako  mod_php. Jak jsme již zmínili dříve, tento modul umožňuje vložit PHP interpret do jednotlivých pracovních procesů. To je užitečné, když potřebujete zpracovávat dynamický obsah.

Tím ale příběh nekončí. Můžete také přidat moduly pro povolení funkcí, jako je autentizace klientů, zabezpečení serveru, ukládání do mezipaměti, přepisování URL, proxy, omezování rychlosti, komprese a také šifrování.

Nginx

Modulární systém Nginxu se liší v tom smyslu, že moduly nelze do hlavního serveru načítat dynamicky. Místo toho musí být shromážděny a zkompilovány přímo s jádrem softwaru. To ponechává mnoho přání nesplněných, pokud jde o flexibilitu a snadnost použití. Zatímco distribuční balíčky obsahují některé běžné moduly, pro ostatní moduly budete muset server sestavit sami. Proto musíte vědět, jak udržovat zkompilovaný software mimo tradiční balíčkovací systém.

Bez ohledu na to je výhodou tohoto nestandardního modulárního systému to, že vám poskytuje vysokou míru specifičnosti. Své moduly si můžete přizpůsobit tak, že do nich začleníte pouze ty funkce, které požadujete. To vám umožní opustit komponenty, které nepotřebujete, a vyhnout se tak bezpečnostnímu riziku. Zároveň můžete s moduly Nginxu provádět stejné úkoly jako s Apache. Patří mezi ně přepisování URL, protokolování, autentizace a tak dále.

Ekosystém a podpora

Integrace a softwarová podpora jsou u webových serverů velmi důležité. Dále prozkoumáme kompatibilitu a podporu, která je k dispozici pro Apache a Nginx.

Apache

Apache je starší a populárnější platforma. Je tedy pochopitelné, že má ve srovnání s Nginxem větší škálu podpůrných nástrojů a softwaru. K podpoře hlavního serveru máte k dispozici obrovské množství dokumentace od třetích stran. Nejen to, můžete jej také spárovat s jiným softwarem pro plnění specifických úkolů. Tyto nástroje můžete přidat buď do svého projektu, nebo do svého balíčku. V ekosystému Apache je lze snadno zprovoznit.

Nginx

Ačkoli Nginx v tomto ohledu za Apache zaostává, rozhodně dělá vše pro to, aby ho dohnal. Stále více lidí přechází na Nginx, jakmile si uvědomí jeho plný potenciál. Podpora této platformy nadále roste spolu s jejím přirozeným růstem jako užitečného a rychlého webového serveru.

Jednou z hlavních překážek v podpoře, kterou musel Nginx překonat, bylo nalezení dokumentace v anglickém jazyce. Je to proto, že většina Nginx byla původně napsána v ruském jazyce, včetně většiny jeho dokumentace. Jak se však server rozšířil a stal se známějším, v tomto univerzálním jazyce je nyní k dispozici spousta zdrojů třetích stran.

Společné řešení?

Nyní již mnohem lépe rozumíte základním komponentám a vnitřnímu fungování Apache a Nginx. Přestože se od sebe dosti liší, někteří uživatelé této skutečnosti využívají, aby získali to nejlepší z obou světů. Přesně tak – je možné používat Apache a Nginx společně.

Uživatelé obvykle používají Nginx jako reverzní proxy a umisťují jej před Apache. To umožňuje kompenzovat nedostatečnou rychlost Apache při zpracování požadavků. Nginx přijímá a zpracovává všechny požadavky v době, kdy je nejrychlejší. Umožňuje také rychle vyřídit velké množství souběžných požadavků, aniž byste museli investovat mnoho prostředků.

Další funkcí Nginx, které uživatelé využívají, je jeho schopnost efektivně zpracovávat statický obsah. Abychom kompenzovali skutečnost, že Nginx potřebuje k procesování dynamického obsahu externí komponentu, můžeme požadavky na PHP a další relevantní požadavky přesměrovat na Apache prostřednictvím proxy. Apache vykreslí požadavek do webové stránky a odešle jej zpět Nginx, aby jej mohl poskytnout klientovi.

Zde je několik zdrojů, které najdete na našem blogu, které vám pomohou začít s oběma webovými servery:

Apache

• Instalace serveru Apache na Ubuntu 18.04: Návod krok za krokem
• Nastavení Apache Virtual Hosts na Ubuntu 20.04
• Jak nainstalovat Linux, Apache, MySQL, PHP (LAMP) stack na CentOS 7
• Zabezpečení Apache pomocí Let’s Encrypt na Ubuntu 18.04

Nginx

• Instalace Nginx na Ubuntu 18.04
• Automatizace obnovy SSL certifikátů LetsEncrypt pro Nginx
• Jak zabezpečit Nginx pomocí Let’s Encrypt na Ubuntu 20.04
• Jak nainstalovat LEMP stack (Linux, Nginx, MySQL PHP) na Ubuntu 20.04

Závěr

Koneckonců, jak Apache, tak Nginx mají své silné a slabé stránky. Neexistují žádná pevná pravidla ani doporučení, který server byste měli pro svůj projekt použít. Vy sami nejlépe posoudíte, co pro vaši aplikaci funguje nejlépe na základě vašich jedinečných požadavků.

Musíte zjistit, u kterých aspektů a funkcí nemůžete dělat kompromisy, a podle toho se rozhodnout. Pokud je těžké se rozhodnout, můžete se vždy přiklonit k použití obou serverů společně v rámci přizpůsobeného řešení.

Příjemnou práci!