Apache i Nginx to dwa najpopularniejsze na świecie serwery internetowe o otwartym kodzie źródłowym. Razem odpowiadają za obsługę ponad 50% ruchu w Internecie. Oba rozwiązania są w stanie obsługiwać różnorodne obciążenia i współpracować z innym oprogramowaniem, aby zapewnić kompletny stos sieciowy.
Chociaż Apache i Nginx mają wiele cech, nie powinny być uważane za całkowicie zamienne. Każdy wyróżnia się na swój własny sposób i ważne jest, aby zrozumieć sytuacje, w których może zajść konieczność ponownej oceny wybranego serwera WWW. Ten artykuł poświęcony będzie dyskusji na temat tego, jak każdy serwer zachowuje się w różnych obszarach.
Przegląd ogólny
Zanim przejdziemy do różnic między Apache i Nginx, rzućmy okiem na tło tych dwóch projektów i ich ogólną charakterystykę.
Apache
Serwer HTTP Apache został stworzony przez Roberta McCoola w 1995 roku i został opracowany pod kierunkiem Apache Software Foundation od 1999 roku. Ponieważ serwer HTTP jest oryginalnym projektem fundacji i jest zdecydowanie najpopularniejszym oprogramowaniem, często jest określany po prostu jako “Apache”.
Serwer WWW Apache jest najpopularniejszym serwerem w Internecie od 1996 roku. Ze względu na tę popularność Apache korzysta z doskonałej dokumentacji i zintegrowanego wsparcia z innych projektów oprogramowania.
Apache jest często wybierany przez administratorów ze względu na jego elastyczność, moc i szerokie wsparcie. Jest rozszerzalny przez dynamicznie ładowalny system modułów i może przetwarzać dużą liczbę interpretowanych języków bez podłączania się do oddzielnego oprogramowania.
Nginx
W 2002 r. Igor Sysoev rozpoczął pracę nad Nginx jako odpowiedzią na problem C10K, co było wyzwaniem dla serwerów internetowych, aby zacząć obsługiwać dziesięć tysięcy równoczesnych połączeń jako wymóg dla nowoczesnej sieci. Pierwsza publiczna wersja została wydana w 2004 roku aby osiągnąć ten cel, opierając się na asynchronicznej architekturze sterowanej zdarzeniami.
Nginx zyskał na popularności od czasu wydania ze względu na niewielkie wykorzystanie zasobów i możliwość skalowania na minimalnym sprzęcie. Nginx celuje w szybkim dostarczaniu statycznej zawartości i jest przeznaczony do przekazywania dynamicznych żądań do innego oprogramowania, które jest lepiej dostosowane do tych celów.
Nginx jest często wybierany przez administratorów, jeśli chodzi o efektywność zasobów i szybkość reagowania podczas obciążenia. Wydawcy z zadowoleniem przyjmują nacisk Nginx na podstawowe funkcje serwera sieciowego i proxy.
Architektura obsługi połączeń
Jedną dużą różnicą między Apache i Nginx jest faktyczny sposób obsługi połączeń i ruchu. Zapewnia to prawdopodobnie najbardziej znaczącą różnicę w sposobie, w jaki reagują na różne warunki ruchu.
Apache
Apache udostępnia wiele modułów przetwarzania danych (Apache wywołuje MPMy), które dyktują sposób obsługi żądań klientów. Zasadniczo umożliwia to administratorom łatwe zamienienie architektury obsługi połączeń. Są to:
- mpm_prefork : Ten moduł przetwarzania procesy z pojedynczym wątkiem do obsługi każdego żądania. Każde “dziecko” może obsługiwać pojedyncze połączenie naraz. Tak długo, jak liczba żądań jest mniejsza niż liczba procesów, ten MPM jest bardzo szybki. Jednak wydajność pogarsza się szybko, gdy liczba żądań przekracza liczbę procesów, więc nie jest to dobry wybór w wielu sytuacjach. Każdy proces ma znaczący wpływ na zużycie pamięci RAM, więc MPM jest trudny do skalowania. Może to być jednak dobry wybór, jeśli jest używany w połączeniu z innymi komponentami, które nie są zbudowane z myślą o wątkach. Na przykład, PHP nie jest bezpieczne dla wątków, więc MPM jest zalecany jako jedyny bezpieczny sposób pracy z modułem mod_php Apache do przetwarzania tych plików.
- mpm_worker : Ten moduł spawnuje procesy, z których każdy może zarządzać wieloma wątkami. Każdy z tych wątków może obsłużyć jedno połączenie. Wątki są znacznie wydajniejsze niż procesy, co oznacza, że ten MPM skaluje się lepiej niż mpm_prefork. Ponieważ istnieje więcej wątków niż procesów, oznacza to również, że nowe połączenia mogą natychmiast wziąć wolny wątek, zamiast czekać na wolny proces.
- mpm_event : W większości sytuacji moduł ten jest podobny do modułu worker , ale jest zoptymalizowany do obsługi połączeń utrzymywanych na bieżąco. Podczas używania worker połączenie będzie utrzymywać wątek niezależnie od tego, czy żądanie jest aktywnie tworzone, dopóki połączenie jest utrzymywane przy życiu. Event obsługuje utrzymywanie połączeń przy życiu przez odkładanie dedykowanych wątków do obsługi połączeń utrzymujących połączenie i przekazywania aktywnych żądań do innych wątków. Dzięki temu moduł nie będzie grzęznąć przez żądanie utrzymania aktywności, pozwalając na szybszą realizację. Został wydany jako stabily wraz z wydaniem Apache 2.4.
Jak widać, Apache zapewnia elastyczną architekturę do wyboru różnych algorytmów łączenia i obsługi żądań. Wybrane opcje są głównie funkcją ewolucji serwera i rosnącej potrzeby współbieżności w miarę zmiany pejzażu internetowego.
Nginx
Nginx pojawił się na scenie za Apache’em, z większą świadomością problemów związanych z współbieżnością, które napotykają strony o dużej skali. Wykorzystując tę wiedzę, Nginx został zaprojektowany od podstaw w celu użycia asynchronicznego, nie blokującego, sterowanego zdarzeniami algorytmu obsługi połączeń.
Każdy proces roboczy nginx może obsłużyć tysiące połączeń. Procesy robocze realizują to poprzez wdrożenie mechanizmu szybkiego zapętlania, który stale sprawdza i przetwarza zdarzenia. Oddzielenie rzeczywistej pracy od połączeń pozwala każdemu procesowi zająć się połączeniem tylko wtedy, gdy uruchomiono nowe zdarzenie.
Każde z obsługiwanych połączeń jest umieszczane w pętli zdarzeń tam, gdzie istnieją z innymi połączeniami. W pętli zdarzenia są przetwarzane asynchronicznie, co umożliwia pracę bez blokowania. Gdy połączenie zostanie zamknięte, zostanie usunięte z pętli.
Ten styl przetwarzania połączeń pozwala Nginxowi skalować się niesamowicie daleko przy ograniczonych zasobach. Ponieważ serwer jest jednowątkowy, a procesy nie są tworzone w celu obsługi każdego nowego połączenia, użycie pamięci i procesora ma tendencję do pozostawania stosunkowo spójnymi, nawet w przypadku dużego obciążenia.
Treści statyczne i dynamiczne
Jeśli chodzi o przypadki użycia w świecie rzeczywistym, jednym z najczęstszych porównań między Apache i Nginx jest sposób, w jaki każdy serwer obsługuje żądania zawartości statycznej i dynamicznej.
Apache
Serwery Apache mogą obsługiwać zawartość statyczną przy użyciu konwencjonalnych metod opartych na plikach. Działanie tych operacji jest głównie funkcją opisanych powyżej metod MPM.
Apache może także przetwarzać zawartość dynamiczną, osadzając procesor danego języka w każdej jego instancji “pracowniczej”. Pozwala to na wykonywanie dynamicznej zawartości w samym serwerze sieciowym bez konieczności polegania na komponentach zewnętrznych. Te dynamiczne procesory można włączyć za pomocą dynamicznie ładowanych modułów.
Zdolność Apache do wewnętrznego obsługiwania dynamicznej zawartości oznacza, że konfiguracja dynamicznego przetwarzania staje się prostsza. Komunikacja nie musi być skoordynowana z dodatkowym oprogramowaniem i moduły mogą być łatwo zamienione, jeśli zmieniają się wymagania dotyczące treści.
Nginx
Nginx nie ma żadnej zdolności do przetwarzania zawartości dynamicznej natywnie. Aby obsłużyć PHP i inne żądania dynamicznej zawartości, Nginx musi przejść do zewnętrznego procesora w celu wykonania i czekać na wysłaną treść. Wyniki można następnie przekazać do klienta.
Dla administratorów oznacza to, że komunikacja musi być skonfigurowana między Nginx a procesorem przez jeden z protokołów Nginx (http, FastCGI, SCGI, uWSGI, memcache). Może to nieco komplikować sytuację, zwłaszcza gdy próbuje się przewidzieć liczbę połączeń, na które można zezwolić, ponieważ dla każdego połączenia z procesorem będzie używane dodatkowe połączenie.
Jednak ta metoda ma również pewne zalety. Ponieważ interpreter dynamiczny nie jest osadzony w procesie roboczym, jego narzut będzie obecny tylko w przypadku zawartości dynamicznej. Treść statyczna może być obsługiwana w prosty sposób, i połączenia będą tylko wtedy, gdy będzie to potrzebne. Apache może również działać w ten sposób, ale w ten sposób usuwa korzyści z poprzedniej sekcji.
Konfiguracja rozproszona a scentralizowana
Dla administratorów jedną z najpewniej widocznych różnic między tymi dwoma programami jest to, czy w katalogach głównych dozwolona jest dodatkowa konfiguracja na poziomie katalogu.
Apache
Apache zawiera opcję zezwalania na dodatkową konfigurację dla poszczególnych katalogów poprzez inspekcję i interpretację dyrektyw w ukrytych plikach w samych katalogach. Te pliki są znane jako pliki .htaccess.
Ponieważ te pliki znajdują się w samych katalogach , podczas obsługi żądania Apache sprawdza każdy komponent ścieżki do żądanego pliku dla .htaccess i stosuje dyrektywy znalezione w tym pliku. Pozwala to na zdecentralizowaną konfigurację serwera internetowego, który jest często wykorzystywany do implementacji przeróbek URL, ograniczeń dostępu, autoryzacji i uwierzytelniania, a nawet reguł buforowania.
Chociaż powyższe przykłady można skonfigurować w głównym pliku konfiguracyjnym Apache, pliki .htaccess mają kilka ważnych zalet. Po pierwsze, ponieważ są one interpretowane za każdym razem, gdy są znalezione wzdłuż ścieżki żądania, są one implementowane natychmiast bez ponownego ładowania serwera. Po drugie, pozwala on nieuprzywilejowanym użytkownikom na kontrolowanie pewnych aspektów własnej zawartości internetowej bez nadawania im kontroli nad całym plikiem konfiguracyjnym.
Zapewnia to łatwy sposób dla niektórych programów internetowych, takich jak systemy zarządzania treścią, do konfigurowania ich środowiska bez zapewniania dostępu do centralnego pliku konfiguracyjnego. Jest to również używane przez współdzielonych dostawców hostingu do zachowania kontroli nad główną konfiguracją, dając jednocześnie klientom kontrolę nad ich określonymi katalogami.
Nginx
Nginx nie interpretuje plików .htaccess, ani nie dostarcza żadnego mechanizmu do oceny konfiguracji katalogu poza głównym plikiem konfiguracyjnym. Może to być mniej elastyczne niż model Apache, ale ma swoje zalety.
Najbardziej znaczącym usprawnieniem w stosunku do systemu konfiguracji na poziomie katalogu jest zwiększona wydajność. W przypadku typowej konfiguracji Apache, która może dopuszczać htaccess w dowolnym katalogu, serwer sprawdza te pliki w każdym katalogu nadrzędnym prowadzącym do żądanego pliku dla każdego żądania. Jeśli podczas wyszukiwania zostanie znaleziony jeden lub więcej plików, należy je odczytać i zinterpretować. Nie zezwalając na nadpisywanie katalogów, Nginx może szybciej obsługiwać żądania,
wykonując pojedyncze wyszukiwanie katalogu i odczytując plik dla każdego żądania (zakładając, że plik znajduje się w tradycyjnej strukturze katalogów).
Kolejną zaletą jest bezpieczeństwo. Dystrybucja dostępu do konfiguracji na poziomie katalogu rozdziela również odpowiedzialność za bezpieczeństwo na poszczególnych użytkowników, którzy mogą nie mieć odpowiedniej wiedzy aby dobrze wszystko skonfigurować. Zapewnienie, że administrator utrzymuje kontrolę nad całym serwerem www, może zapobiec niektórym błędom bezpieczeństwa, które mogą wystąpić, gdy dostęp jest udostępniany innym stronom.
Interpretacja plików względem interpretacji URL
Sposób, w jaki serwer WWW interpretuje żądania i odwzorowuje je na rzeczywiste zasoby w systemie, to kolejny obszar, w którym te dwa serwery się różnią.
Apache
Apache umożliwia interpretację żądania jako zasobu fizycznego w systemie plików lub jako lokalizację URI, która może wymagać bardziej abstrakcyjnej oceny. Ogólnie rzecz biorąc, Apache używa bloków <Directory>lub <Files>, oraz wykorzystuje <Location> do bardziej abstrakcyjnych zasobów.
Ponieważ Apache został zaprojektowany od podstaw jako serwer WWW, domyślnie interpretuje żądania jako zasoby systemu plików. Rozpoczyna się od pobrania katalogu głównego i dołączenia części żądania po numerze hosta i numeru portu, aby znaleźć rzeczywisty plik. Zasadniczo hierarchia systemu plików jest reprezentowana w Internecie jako dostępne drzewo dokumentów.
Apache udostępnia wiele alternatyw, gdy żądanie nie jest zgodne z podstawowym systemem plików. Na przykład dyrektywę Alias można zastosować do mapowania do alternatywnej lokalizacji. Używanie bloków <Location> to metoda pracy z samym identyfikatorem URI zamiast z systemem plików. Istnieją również warianty wyrażenia regularnego, które można wykorzystać do elastycznego zastosowania konfiguracji w całym systemie plików.
Apache ma zdolność operowania zarówno na bazowym systemie plików, jak i na przestrzeni internetowej, ale opiera się na metodach systemu plików. Widać to w niektórych decyzjach projektowych, w tym w przypadku plików .htaccess do konfiguracji na każdy katalog. Sama dokumentacja Apache ostrzega przed użyciem bloków opartych na URI, aby ograniczyć dostęp, gdy żądanie odzwierciedla podstawowy system plików.
Nginx
Nginx został stworzony, aby być zarówno serwerem WWW, jak i serwerem proxy. Ze względu na architekturę wymaganą dla tych dwóch ról, działa ona głównie z identyfikatorami URI, co w razie potrzeby przekłada się na system plików.
Widać to na niektórych sposobach konstruowania i interpretowania plików konfiguracyjnych Nginx. Nginx nie zapewnia mechanizmu do określania konfiguracji dla katalogu systemu plików, a zamiast tego analizuje sam URI.
Na przykład blok server interpretuje kataloggłówny i jest wymagany, natomiast bloki location są odpowiedzialne za dopasowanie części URI, który przychodzi po hosta i portu. W tym momencie żądanie jest interpretowane jako identyfikator URI, a nie jako lokalizacja w systemie plików.
W przypadku plików statycznych wszystkie żądania muszą być ostatecznie odwzorowane na lokalizację w systemie plików. Najpierw Nginx wybiera serwer i bloki lokalizacji, które będą obsługiwać żądanie, a następnie łączy główny dokument z identyfikatorem URI, dostosowując wszystko, co konieczne, zgodnie z określoną konfiguracją.
Może się to wydawać podobne, ale przetwarzanie zapytań głównie jako URI zamiast lokalizacji systemów plików pozwala Nginxowi na łatwiejsze funkcjonowanie zarówno w roli web, mail, jak i serwera proxy. Nginx jest konfigurowany po prostu przez ustawienie sposobu reagowania na różne wzorce żądań. Nginx nie sprawdza systemu plików, dopóki nie jest gotowy do obsługi żądania, co wyjaśnia, dlaczego nie implementuje formy plików .htaccess.
Moduły
Zarówno Nginx, jak i Apache można rozszerzyć za pomocą modułów, ale sposób ich działania znacznie się różni.
Apache
System modułowy Apache pozwala na dynamiczne ładowanie lub rozładowywanie modułów w celu zaspokojenia potrzeb w trakcie działania serwera. Rdzeń Apache jest zawsze obecny, a moduły można włączać i wyłączać, dodając lub usuwając dodatkowe funkcje i podpinania do głównego serwera.
Apache wykorzystuje tę funkcjonalność do wielu zadań. Ze względu na dojrzałość platformy dostępna jest bogata biblioteka modułów. Mogą one zostać użyte do zmiany niektórych podstawowych funkcji serwera, takich jak mod_php, które osadzają interpretera PHP w każdym działającym module roboczym.
Moduły nie są jednak ograniczone do przetwarzania zawartości dynamicznej. Wśród innych funkcji można je wykorzystać do przepisywania adresów URL, uwierzytelniania klientów, hartowania serwera, rejestrowania, buforowania, kompresji, proxy, ograniczania szybkości i szyfrowania. Moduły dynamiczne mogą znacznie rozszerzyć główną funkcjonalność bez dodatkowej pracy.
Nginx
Nginx implementuje również system modułów, ale jest zupełnie inny od systemu Apache. W Nginx, moduły nie są ładowane dynamicznie, więc muszą być wybrane i skompilowane do podstawowego oprogramowania.
Dla wielu użytkowników sprawia to że Nginx będzie mniej elastyczny. Dotyczy to szczególnie użytkowników, którzy nie są w stanie utrzymywać własnego skompilowanego oprogramowania poza konwencjonalnym systemem dystrybucji ich dystrybucji. Pakiety dystrybucyjne zwykle zawierają najczęściej używane moduły, ale jeśli potrzebujesz niestandardowego modułu, będziesz musiał sam zbudować serwer ze źródła.
Moduły Nginx są nadal bardzo przydatne i pozwalają na dyktowanie, czego chcesz od serwera, włączając tylko funkcje, których chcesz używać. Niektórzy użytkownicy mogą również uważać to za bezpieczniejsze, ponieważ dowolnych składników nie można podłączyć do serwera. Jeśli jednak twój serwer kiedykolwiek znajdzie się w miejscu, w którym jest to możliwe prawdopodobnie jest już zagrożony.
Moduły Nginx pozwalają na wiele takich samych możliwości jak moduły Apache. Na przykład moduły Nginx mogą zapewniać obsługę proxy, kompresję, ograniczanie szybkości, rejestrowanie, przepisywanie, geolokalizację, uwierzytelnianie, szyfrowanie, przesyłanie strumieniowe i funkcje poczty.
Wsparcie, zgodność, ekosystem i dokumentacja
Ważną kwestią, którą należy rozważyć, jest fakt, w jaki sposób faktyczny proces powstawania i działania oprogramowania zostanie udostępniony oraz dostępne formy pomocy i wsparcia między innym oprogramowaniem.
Apache
Ponieważ Apache jest popularny od tak dawna, obsługa serwera jest dość powszechna. Dostępna jest obszerna biblioteka dokumentacji dla podstawowego serwera i scenariuszy opartych na zadaniach obejmujących podłączanie Apache do innych programów.
Wraz z dokumentacją wiele narzędzi i projektów internetowych zawiera narzędzia do ładowania się w środowisku Apache. Może to być zawarte w samych projektach lub w pakietach obsługiwanych przez zespół zajmujący się tworzeniem twojej dystrybucji.
Ogólnie Apache będzie miał większe wsparcie z projektów stron trzecich, po prostu ze względu na swój udział w rynku i czas jego dostępności. Administratorzy są również nieco bardziej skłonni do doświadczenia w pracy z Apache nie tylko ze względu na jego rozpowszechnienie, ale także dlatego, że wiele osób zaczyna od scenariuszy dzielonego hostingu, które niemal wyłącznie opierają się na Apache ze względu na możliwości obsługi .htaccess przez klienta.
Nginx
Nginx ma narastającą obsługę, ponieważ coraz więcej użytkowników adoptuje go do zwiększenia wydajności, ale wciąż ma pewne zaległości w niektórych kluczowych obszarach.
W przeszłości trudno było znaleźć obszerną anglojęzyczną dokumentację dotyczącą Nginx ze względu na to, że większość wczesnego programowania i dokumentacji była w języku rosyjskim. Ponieważ zainteresowanie projektem wzrosło, dokumentacja została wypełniona, a na stronie Nginx i przez osoby trzecie jest mnóstwo zasobów administracyjnych.
Jeśli chodzi o aplikacje innych firm, wsparcie i dokumentacja stają się coraz bardziej dostępne, a opiekunowie pakietów zaczynają, w niektórych przypadkach, dokonywać wyboru między automatyczną konfiguracją Apache i Nginx. Nawet bez wsparcia, konfigurowanie Nginx do pracy z alternatywnym oprogramowaniem jest zwykle proste, o ile sam dokument zawiera jego wymagania (uprawnienia, nagłówki, itp.).
Używanie Apache i Nginx naprzemiennie
Po przejrzeniu korzyści i ograniczeń zarówno Apache, jak i Nginx, możesz podjąć decyzję, który serwer jest bardziej odpowiedni do twoich potrzeb. Jednak wielu użytkowników uważa, że możliwe jest wykorzystanie mocnych stron każdego serwera poprzez ich wspólne wykorzystanie.
Konwencjonalną konfiguracją dla tego partnerstwa jest umieszczenie Nginx przed Apache jako reverse proxy. Dzięki temu Nginx będzie mógł obsługiwać wszystkie żądania od klientów. Wykorzystuje to szybką prędkość przetwarzania Nginx i zdolność jednoczesnego obsługiwania dużej liczby połączeń.
W przypadku statycznych treści do których Nginx celuje, pliki będą dostarczane szybko i bezpośrednio do klienta. W przypadku treści dynamicznych, na przykład plików PHP, Nginx zaimportuje żądanie do Apache, które następnie może przetworzyć wyniki i zwrócić renderowaną stronę. Nginx może następnie przekazać zawartość z powrotem do klienta.
Ta konfiguracja działa dobrze dla wielu osób, ponieważ pozwala Nginxowi funkcjonować jako maszyna sortująca. Będzie obsługiwać wszystkie żądania, które może i przekazywać te, dla których nie ma natywnej zdolności do obsługi. Ograniczając żądania serwera Apache, które mają zostać obsłużone, możemy złagodzić niektóre blokady, które występują, gdy proces Apache lub wątek jest zajęty.
Ta konfiguracja pozwala również na skalowanie, dodając w razie potrzeby dodatkowe serwery zaplecza. Nginx można skonfigurować tak, aby łatwo przekazywał pulę serwerów, zwiększając odporność tej konfiguracji na awarię i wydajność.
Wniosek
Jak widać, zarówno Apache, jak i Nginx są potężne i elastyczne. Wybór odpowiedniego serwera jest w dużej mierze funkcją oceny konkretnych wymagań i testowania zgodnie z oczekiwanymi wzorcami.
Istnieją różnice między tymi projektami, które mają bardzo realny wpływ na wydajność, możliwości i czas potrzebny na dostrojenie i uruchomienie każdego z tych rozwiązań. Są one jednak zazwyczaj wynikiem serii kompromisów, których nie należy lekceważyć. W końcu nie ma jednego uniwersalnego serwera WWW, więc warto użyć rozwiązania które najlepiej pasuje do twoich celów.
