A webszerverek világa: Apache vs. Nginx

Bevezetés az Apache és az Nginx használatába

A webszervereket és protokollokat arra tervezték, hogy lehetővé tegyék a felhasználók számára a weboldalak megtekintését. Kérést küldenek egy dokumentum megtekintésére, amelyet a szerver fogad. A kiszolgáló ezután lényegében kiszolgálja a dokumentumot vagy információt a nézőnek. A webszerver központi szerepet játszik abban, hogy Ön megtekinthesse és elérhesse a weboldalakat a böngészőjében.

Számos webszerver létezik, amelyet erre a célra használhat. A legnépszerűbbek közé tartozik az Nginx és az Apache. Valójában ezek a szerverek üzemeltetik az interneten jelenleg elérhető weboldalak többségét.

Az Apache és az Nginx sok szempontból meglehetősen hasonlóak. Kezdetnek mindkét webszerver nyílt forráskódú. Ez azt jelenti, hogy a világon bárki teljesen ingyen használhatja őket. Azonban számos olyan funkció létezik, amely egyedi az egyes szerverekre nézve. Ezek a különleges jellemzők teszik őket a legalkalmasabbá a különböző alkalmazásokhoz és célokra.

Hogy segítsünk Önnek eldönteni, melyik webszerver a jobb vagy az ideális az Ön számára, összehasonlítjuk az Nginx-et és az Apache-ot. Az összehasonlítást számos olyan alapvető paraméter alapján végezzük el, amelyek kritikusak a webszerverek felhasználói számára. Kezdjük el!

Alapvető áttekintés

A két webszerver általános áttekintésével kezdjük. Mind az Apache, mind az Nginx nagyszerű hírnevet szerzett a közösségben. Teljesítményükről híresek, és világszerte számos neves szervezet használja őket.

Apache

Az Apache 1995-ben jelent meg. Robert McCool fejlesztette ki ezt a HTTP-szervert a az Apache Software Foundation keretein belül, innen ered a név. Megjelenése óta emberek százezrei használják az Apache-ot szerte a világon.

Hatalmas népszerűsége azt jelenti, hogy rengeteg harmadik féltől származó szoftver és forrás működik együtt vele rendszeresen. Így ha egy jó, sok integrációval rendelkező támogatói hálózatot keres, az Apache a megfelelő választás az Ön számára. Az Apache sokak számára azért is előnyösebb, mert dinamikusabb és rugalmasabb. Emellett az általa értelmezhető nyelvek szélesebb skáláját kínálja.

Nginx

Nginx egy viszonylag újabb webszerver, amely 2004-ben jelent meg. Igor Syosev erőfeszítéseinek eredménye, hogy megoldást találjon az úgynevezett C10K problémára. Ez a probléma akkor merült fel, amikor a szerverek számára nehézséget okozott a nagy mennyiségű forgalom kezelése. Ahogy egyre többen kezdték használni az internetet, a weboldalak szerverei túlterheltté váltak. Mivel ezek a szerverek nem voltak képesek egyszerre több ezer kapcsolatot kezelni, az oldalak összeomlottak és leálltak.

Az Nginx-et azért adták ki, hogy megpróbálják megoldani ezt a problémát. Ezért van az, hogy az architektúrája hihetetlenül könnyű kialakítású, amely képes korlátozott erőforrásokkal és hardverrel is működni. Bár leginkább statikus tartalommal való működésre alkalmas, integrálható olyan szoftverekkel is, amelyek a dinamikus tartalmat is megfelelően tudják kezelni.

Forgalomkezelési képességek

Most, hogy már van egy alapvető elképzelésünk mindegyik szerverről, elmerülhetünk a részletekben. Az első funkció, amellyel kezdünk, az egyes szerverek forgalom- és kezelési képességei. Ez az egyik legfontosabb pont, amely megkülönbözteti ezt a két platformot. Architektúrájuk eltérő elveken működik, amikor több kapcsolat egyidejű kezeléséről van szó.

Apache

Az Apache az úgynevezett MPM- Multi-Processing Modules-et használja. A rendszergazdák különféle MPM-eket használnak a kapcsolatkezelési architektúra manipulálására és módosítására. Az Apache webszerver vonzerejének része az architektúrája által kínált rugalmasság. Az ilyen modulalapú infrastruktúra, amely a feldolgozást egyedi és csoportos szálakra osztja, megkönnyíti a skálázást és a különböző típusú kapcsolatokhoz való alkalmazkodást.

Nézzünk meg’ néhányat az Apache-ban használt egyedi modulok közül:

• mpm_prefork

Az első az mpm_prefork. Ez egy olyan feldolgozó modul, amely a látogatóktól érkező kérések kezeléséért felelős. Egy szálat vagy gyermekfolyamatot hoz létre egy kapcsolat kezelésére egy adott időben. Ez azt jelenti, hogy ha a kérések száma kevesebb, mint a folyamatok száma, az mpm_prefork meglehetősen hatékonyan működik.

A kérések feldolgozása gyorsan megtörténik, mivel egy különálló gyermekfolyamat dolgozza fel mindegyiket egyenként. Ez azonban azt is jelenti, hogy ha a kérések száma meghaladja a folyamatok számát, az jelentősen lelassíthatja a dolgokat. Ennek eredményeként a kérésfeldolgozási lépés rengeteg RAM-ot emészt fel.

• mpm_worker

Mint már tudjuk, egy szál felelős egy kapcsolatért. Ez a modul egy lépéssel továbbmegy, és lehetővé teszi több szál egyidejű kezelését. Ez egy sokkal jobban skálázható modul az mpm_prefork-hoz képest, amely egy bizonyos küszöbérték felett már küszködik. Az új kapcsolatok azonnal csatlakozhatnak egy szálhoz, ahelyett, hogy várakozniuk kellene.

• mpm_event

Az mpm_event felelős a keep-alive (életben tartott) kapcsolatok fenntartásáért. Ennek a modulnak az elsődleges célja, hogy megakadályozza a rendszer leterheltségét a keep-alive kérések miatt. Ezt úgy éri el, hogy egy szálat rendel egy kapcsolathoz még aktív kérés hiányában is. A szál mindaddig dedikált marad, amíg a kapcsolat él. A bejövő kérések a szabad szálakhoz kerülnek átirányításra.

Nginx

Az Apache-csal ellentétben az Nginx-et egy nagyon konkrét céllal hozták létre. Már ismertük azokat a problémákat, amelyek ezen a szinten a kapcsolatok és a skálázhatóság terén felmerültek. Ezért használ egy olyan algoritmust, amely aszinkron és nem blokkoló (non-blocking). Nem rendel külön szálakat minden egyes kapcsolathoz. Ehelyett az Nginx számos munkamenet-folyamatot (worker process) hoz létre, amelyek egyszerre több ezer kapcsolat kezelésére képesek.

Az Nginx architektúrájának működési elve a gyors hurokmechanizmus (fast looping mechanism). Ez az algoritmus folyamatosan dolgozza fel az eseményeket és figyeli azokat. Ez azt jelenti, hogy a folyamatok eseményvezéreltek, és minden munkamenet-folyamat (worker process) csak a saját kapcsolataihoz van hozzárendelve. Egy munkamenet-folyamat összes kapcsolata egy eseményhurokban (event loop) található. Itt egymás mellett léteznek, és aszinkron módon kerülnek feldolgozásra az adott munkamenethez tartozó többi kapcsolattal együtt.

Az ilyen architektúra legfőbb előnye, hogy kiváló skálázhatóságot tesz lehetővé. Ez különösen akkor válik hasznossá, ha korlátozott erőforrásokkal rendelkezik, vagy minimális hardverrel szeretne dolgozni. Még ha nagy forgalmat is tapasztal, az alig lesz hatással a RAM-használatra. Ez azért van, mert nem hoz létre külön szálakat minden egyes kapcsolathoz.

Statikus és dinamikus tartalom kezelése

Egy másik paraméter, amelyet a két webszerver összehasonlítására használhatunk, az az, hogyan kezelik a(z) statikus és a(z) dinamikus tartalmat.

Apache

Az Apache fájlalapú módszert használ a statikus tartalom kezelésére. MPM feldolgozó rendszere lehetővé teszi, hogy ezzel a hagyományos módszerrel működjön.

Amikor a dinamikus tartalom feldolgozásáról van szó, az Apache képes erre anélkül, hogy külső összetevők segítségére lenne szüksége. A dinamikus feldolgozókat egy modul betöltésével engedélyezheti. Ez a modul a nyelv elemzésével dolgozza fel a tartalmat, majd beágyazza a megfelelő feldolgozót a munkamenetbe (worker).

Annak a fő előnye, hogy nem kell külső összetevőket használni a dinamikus tartalom feldolgozásához, a konfiguráció és a koordináció során mutatkozik meg. Sokkal egyszerűbb csak a belső összetevőket koordinálni egymással.

Nginx

A legnagyobb különbség az Apache és az Nginx tartalomkezelési módja között az, hogy az Nginx egyszerűen képtelen a dinamikus tartalom belső feldolgozására. Egy külső összetevővel kell párosítani a dinamikus tartalomra vonatkozó kérések feldolgozásához. Ez azt jelenti, hogy az Nginx szervert egy külső feldolgozóval együtt kell használnia. Az összetevő megkapja a kérést a(z) PHP/dinamikus tartalomra vonatkozóan, feldolgozza azt, majd visszaküldi a szervernek.

Mivel az információt át kell adni a két komponens között, koordinálnia kell a köztük lévő kommunikációt. Meg kell határoznia, hogy hány kapcsolatot szeretne engedélyezni, és konfigurálnia kell a protokollt. Olyan protokollt kell használnia, amelyet az Nginx képes elolvasni és megérteni, mint például többek között a HTTP, FastCGI, SCGI, uWSGI vagy memcache.

Másrészt az Nginx nagyon jól teljesít a statikus tartalom kezelésében. Valóban szüksége van külső források segítségére ehhez. Az értelmezőt is csak akkor aktiválja, amikor szükség van rá. Ez az Nginx használatának egyik előnye. Az értelmező nincs beágyazva a folyamatba. Ez azt jelenti, hogy csak a dinamikus tartalom feldolgozásához lesz jelen.

Tartalomkönyvtárak: Elosztott vs. centralizált konfiguráció

Minden webszervernek megvan a saját tartalomkönyvtára. Az egyik legfontosabb paraméter, amely alapján az Apache-ot és az Nginx-et megítélhetjük, az, hogy engedélyezik-e a könyvtárszintű konfigurációt.

Apache

A tartalomkönyvtárakban vannak bizonyos rejtett fájlok, amelyek direktívákat tartalmaznak. Ezek a .htaccess fájlok. Az Apache segítségével ezeket a direktívákat könyvtáranként lehet értelmezni. Így amikor kérést küld, az Apache megvizsgálja a fájlhoz vezető utat, hogy megtalálja a .htaccess fájlt. Ha megtalálja, azonnal értelmezi és alkalmazza a benne lévő direktívákat. Az Apache nem indítja újra a szervert ezen direktívák végrehajtásához.

A fent meghatározott folyamat lehetővé teszi a webszerver könyvtárainak decentralizált konfigurálását. A decentralizált konfiguráció hasznos az URL-átírásokhoz, a hozzáférési korlátozások bevezetéséhez, a jogosultságok megerősítéséhez és a gyorsítótárazási szabályzatok beállításához.

A .htaccess fájl egyik előnye, hogy az a felhasználó, aki nem rendelkezik hitelesítéssel, a böngészőjében megtekintett tartalom legalább néhány aspektusát vezérelheti és módosíthatja. Ezért használják az Apache-ot gyakran az osztott tárhelyszolgáltatók. A szolgáltatók jogosult hozzáféréssel rendelkeznek a központi konfigurációhoz. Az ügyfelek képesek ellenőrzést gyakorolni bizonyos könyvtárak felett anélkül, hogy hozzáférnének a fő konfigurációhoz.

Ha szeretné, kikapcsolhatja a .htaccess értelmezést az Apache-ban.

Nginx

Az Apache-tól eltérően az Nginx nem működik .htaccess fájlokkal. Ez viszonylag kevésbé rugalmassá teszi. Azonban az Nginx számos fejlesztést hoz a konfigurációs stílusában. Kezdetnek sokkal gyorsabban képes feldolgozni a kéréseket, mint az Apache. Ez azért van, mert nem keresi, olvassa, értelmezi, majd hajtja végre az útvonalában talált összes .htaccess fájlt. Ahelyett, hogy minden szülőkönyvtárat átkutatna, az Nginx kérésenként csak egy könyvtárkeresést végez.

Emellett az Nginx jelentős biztonsági előnnyel rendelkezik az Apache-hoz képest. Az Nginx az Apache-tól eltérően nem adja át a tartalomkönyvtárak konfigurációjának semmilyen részét az egyes felhasználóknak. Bár Ön szigorú biztonsági intézkedéseket tarthat fenn, ki mondja, hogy az egyes felhasználók képesek ugyanerre? Az Nginx segítségével Ön megtartja az ellenőrzést a teljes könyvtárhálózat biztonsági állapota és konfigurációja felett.

Kérések értelmezése

A két szerver megkülönböztetésének másik módja a kérések értelmezésének módja.

Apache

Amikor a szerver kérést kap, értelmezi azt, majd összekapcsolja a megfelelő rendszererőforrásokkal. A kérést vagy a fájlrendszeren lévő fizikai erőforrásként értelmezi, vagy mint egy URI helyet.

Amikor fizikai erőforrásként értelmezi, a <Directory> vagy <Files> blokkokat használja. Ez a szerver alapértelmezett értelmezési módszere. Elveszi a dokumentum gyökerét. Ezután követi a kérésben szereplő gazdagép- és portszámot, hogy megtalálja a megfelelő fájlt a dokumentumfában.

Az URI hely ezzel szemben absztrakt értékelést igényel. Így az Apache a <Location> blokkokat alkalmazza az absztrakt erőforrásokhoz ahelyett, hogy a fájlrendszerrel dolgozna.

Az URI-n kívül számos más alternatíva is létezik az alapértelmezett fájlalapú rendszer használatára. Például használhatja az Alias direktívát egy alternatív hely megkeresésére a leképezéshez. Kifejezésváltozatokat is igénybe vehet, hogy rugalmasabbá tegye a fájlrendszer konfigurációját.

Nginx

Míg az Apache kifejezetten webszervernek született, az Nginx kettős szerepet tölt be: webszerverként és proxyszerverként is funkcionál. Ezért a fájlrendszer helyett az Nginx inkább az URI-kkal szeret dolgozni. Ezt a preferenciát jól szemlélteti az a tény, hogy az Nginx-ben nincs lehetőség fájlrendszer-könyvtárhoz tartozó konfiguráció megadására. Szükség esetén azonban képes lefordítani azt a fájlrendszerre.

A server és a location azok a konfigurációs blokkok, amelyeket elsősorban az Nginx-ben használnak. Az előbbi a kért hostot értelmezi. Az utóbbi a host és a port utáni URI-részekre illeszkedik. Ennek eredményeként a szerver a kérést URI-helyként értelmezi a rendszeren lévő tényleges fájl helyett.

Az URI-alapú értelmező rendszerének köszönhetően az Nginx képes betölteni webszerver, proxyszerver és levelezőszerver szerepét is. Mivel a kérés értelmezése során nem hivatkozik a fájlrendszerre, érthető, hogy miért nem támogatja a .htaccess fájlokat sem.

Modulrendszerek

Bár mind az Apache és az Nginx támogatja a modulrendszereket a bővítéshez, belső működésükben jelentős különbségek vannak.

Apache

Az Apache esetében a szerver futása közben dinamikusan tölthet be és távolíthat el modulokat. A mag (core) marad a folyamatok középpontjában, a modulok pedig a funkcionalitás bővítésére szolgálnak. Ezeket a csatlakoztatható modulokat számos feladat elvégzésére használhatja. A lehetőségek gyakorlatilag végtelenek az Apache hatalmas könyvtárának köszönhetően.

Sőt, a szervermag működését is módosíthatja olyan modulok használatával, mint a mod_php. Mint korábban említettük, ez a modul lehetővé teszi egy PHP-értelmező beágyazását az egyes worker folyamatokba. Ez akkor hasznos, ha dinamikus tartalmat kell feldolgoznia.

De a történet itt még nem ér véget. Olyan funkciók engedélyezéséhez is hozzáadhat modulokat, mint az ügyfél-hitelesítés, a szerver biztonságának megerősítése, a gyorsítótárazás, az URL-átírás, a proxyk, a sebességkorlátozás, a tömörítés, valamint a titkosítás.

Nginx

Az Nginx modulrendszere abban különbözik, hogy a modulokat nem lehet dinamikusan betölteni a fő szerverre. Ehelyett azokat össze kell gyűjteni és le kell fordítani a szoftver magjával együtt. Ez sok kívánnivalót hagy maga után a rugalmasság és a könnyű használat terén. Bár a disztribúciós csomagok tartalmaznak néhány gyakori modult, más modulokhoz magának kell felépítenie a szervert. Ezért tudnia kell, hogyan tartsa karban a lefordított szoftvert a hagyományos csomagkezelő rendszeren kívül.

Ettől függetlenül ennek a nem szabványos modulrendszernek az az előnye, hogy nagyfokú specifitást biztosít. Testreszabhatja moduljait úgy, hogy csak a szükséges funkciókat építi be. Ez lehetővé teszi, hogy elhagyja a felesleges összetevőket, és ezzel megóvja magát a biztonsági kockázatoktól. Ugyanakkor az Nginx modulokkal ugyanazokat a feladatokat hajthatja végre, mint az Apache-csal. Ide tartozik az URL-átírás, a naplózás, a hitelesítés és így tovább.

Ökoszisztéma és támogatás

Az integrációk és a szoftveres támogatás rendkívül fontosak a webszerverek esetében. A következőkben az Apache és az Nginx számára elérhető kompatibilitást és támogatást vizsgáljuk meg.

Apache

Az Apache egy régebbi és népszerűbb platform. Így érthető, hogy az Nginx-hez képest a támogató eszközök és szoftverek szélesebb tárházával rendelkezik. Rengeteg harmadik féltől származó dokumentáció áll rendelkezésre a magszerver támogatásához. Nemcsak ez, de más szoftverekkel is párosíthatja bizonyos feladatok elvégzéséhez. Ezeket az eszközöket hozzáadhatja a projektjéhez vagy a csomagjához is. Könnyen integrálhatók az Apache ökoszisztémába.

Nginx

Bár az Nginx e tekintetben elmarad az Apache mögött, minden bizonnyal mindent megtesz a felzárkózásért. Egyre többen választják az Nginx-et, ahogy felismerik a benne rejlő teljes potenciált. A platform támogatottsága folyamatosan növekszik a hasznos, gyors feldolgozású webszerverként való organikus növekedésével párhuzamosan.

Az egyik legnagyobb támogatási akadály, amelyet az Nginx-nek le kellett küzdenie, az angol nyelvű dokumentáció hiánya volt. Ez azért van, mert az Nginx nagy része eredetileg orosz nyelven íródott, beleértve a dokumentációjának nagy részét is. Azonban ahogy a szerver elterjedt és egyre ismertebbé vált, ma már rengeteg harmadik féltől származó erőforrás érhető el ezen az univerzális nyelven.

Együttműködésen alapuló megoldás?

Most már sokkal jobban átlátja az Apache és az Nginx alapvető összetevőit és belső működését. Bár meglehetősen különböznek egymástól, egyes felhasználók kihasználják ezt a tényt, hogy mindkét világból a legjobbat hozzák ki. Így van – lehetőség van az Apache és az Nginx együttes használatára is.

Hagyományosan a felhasználók az Nginx-et fordított proxyként (reverse proxy) szokták használni, és az Apache elé helyezik. Ez lehetővé teszi az Apache kéréskezelési és -feldolgozási sebességbeli hiányosságainak kompenzálását. Az Nginx fogadja és kezeli az összes kérést, miközben a leggyorsabb formáját hozza. Lehetővé teszi továbbá nagyszámú egyidejű kérés gyors kezelését anélkül, hogy sok erőforrást kellene befektetni.

Egy másik Nginx-funkció, amelyet a felhasználók kihasználnak, a statikus tartalmak hatékony kezelésének képessége. Annak kompenzálására, hogy az Nginx-nek külső összetevőre van szüksége a dinamikus tartalom feldolgozásához, a PHP- és egyéb releváns kéréseket egy proxyn keresztül átirányíthatjuk az Apache-hoz. Az Apache a kérést weboldallá alakítja, és visszaküldi az Nginx-nek, hogy az kiszolgálhassa az ügyfelet.

Íme néhány erőforrás, amelyet megtalálhat a(z) blogunkon, amelyek segítenek elindulni mindkét webszerverrel:

Apache

• Az Apache szerver telepítése Ubuntu 18.04-re: Útmutató lépésről lépésre
• Apache virtuális gazdagépek (Virtual Hosts) beállítása Ubuntu 20.04-en
• Hogyan telepítsük a Linux, Apache, MySQL, PHP (LAMP) szoftvercsomagot CentOS 7-re
• Az Apache biztosítása Let’s Encrypt segítségével Ubuntu 18.04-en

Nginx

• Az Nginx telepítése Ubuntu 18.04-re
• A LetsEncrypt SSL-tanúsítványok megújításának automatizálása Nginx-hez
• Hogyan biztosítsuk az Nginx-et Let’s Encrypt segítségével Ubuntu 20.04-en
• Hogyan telepítsük a LEMP szoftvercsomagot (Linux, Nginx, MySQL, PHP) Ubuntu 20.04-en

Összegzés

Végtére is, mind az Apache, mind az Nginx rendelkezik erősségekkel és gyengeségekkel. Nincsenek kőbe vésett szabályok vagy ajánlások arra vonatkozóan, hogy melyik szervert érdemes használnia a projektjéhez. Ön tudja a legjobban megítélni, hogy az egyedi igényei alapján mi működik a legjobban az alkalmazása számára.

Ki kell derítenie, melyek azok a szempontok és funkciók, amelyekből nem engedhet, és ezek alapján kell választania. Ha nehéz meghozni a döntést, bármikor dönthet úgy is, hogy a két szervert együtt használja egy testreszabott megoldásban.

Kellemes számítógép-használatot!