Świat serwerów WWW: Apache kontra Nginx

Wprowadzenie do Apache i Nginx

Serwery internetowe i protokoły są zaprojektowane tak, aby umożliwić użytkownikom przeglądanie stron internetowych. Wysyłają one żądanie wyświetlenia dokumentu, które jest akceptowane przez serwer. Następnie host zasadniczo udostępnia dokument lub informacje przeglądającemu. Serwer WWW odgrywa kluczową rolę w umożliwianiu przeglądania i uzyskiwania dostępu do stron internetowych w przeglądarce.

Istnieje wiele serwerów WWW, których można użyć w tym celu. Do najpopularniejszych należą Nginx i Apache. W rzeczywistości serwery te obsługują większość stron internetowych obecnie dostępnych w sieci.

Apache i Nginx są pod wieloma względami dość podobne. Na początek, oba serwery WWW są oprogramowaniem o otwartym kodzie źródłowym. Oznacza to, że każdy na świecie może z nich korzystać całkowicie bezpłatnie. Istnieje jednak wiele funkcji, które są unikalne dla każdego z tych serwerów. Te szczególne cechy sprawiają, że najlepiej nadają się one do różnych zastosowań i celów.

Aby pomóc Ci zdecydować, który serwer WWW jest lepszy lub idealny dla Ciebie, porównamy Nginx i Apache. Porównanie zostanie przeprowadzone pod kątem szeregu kluczowych parametrów, które są krytyczne dla użytkowników serwerów WWW. Zaczynajmy!

Podstawowy przegląd

Zaczniemy od ogólnego omówienia obu serwerów WWW. Zarówno Apache, jak i Nginx wyrobiły sobie świetną reputację w społeczności. Są cenione za swoją wydajność i używane przez wiele znanych organizacji na całym świecie.

Apache

Apache pojawił się w 1995 roku. Robert McCool opracował ten serwer HTTP w ramach the Apache Software Foundation, stąd też jego nazwa. Od momentu wydania setki tysięcy ludzi na całym świecie korzystają z Apache.

Jego ogromna popularność oznacza, że wiele oprogramowania i źródeł zewnętrznych często z nim współpracuje. Jeśli więc szukasz dobrej sieci wsparcia z wieloma integracjami, Apache jest dla Ciebie. Apache jest również preferowany przez wiele osób, ponieważ jest bardziej dynamiczny i elastyczny. Oferuje także szerszy zakres języków, które potrafi interpretować.

Nginx

Nginx to stosunkowo nowszy serwer WWW, który pojawił się w 2004 roku. Jest on wynikiem wysiłków Igora Syoseva mających na celu rozwiązanie problemu znanego obecnie jako problem C10K. Kwestia ta pojawiła się, gdy serwery zaczęły mieć trudności z obsługą dużego natężenia ruchu. W miarę jak coraz więcej osób zaczęło korzystać z internetu, serwery stron internetowych zaczęły być przeciążone. Brak możliwości obsługi kilku tysięcy połączeń jednocześnie przez te serwery powodował awarie i zawieszanie się witryn.

Nginx został wydany, aby spróbować rozwiązać ten problem. Dlatego jego architektura ma niezwykle lekką konstruję, która jest w stanie pracować przy ograniczonych zasobach i sprzęcie. Choć najlepiej nadaje się do pracy z treściami statycznymi, może również integrować się z oprogramowaniem, które odpowiednio obsługuje treści dynamiczne.

Możliwości obsługi ruchu

Skoro mamy już podstawowe pojęcie o każdym z serwerów, możemy zagłębić się w szczegóły. Pierwszą cechą, od której zaczniemy, są możliwości obsługi ruchu przez poszczególne serwery. Jest to jeden z głównych punktów różniących te dwie platformy. Ich architektury działają na różnych zasadach, jeśli chodzi o jednoczesną obsługę wielu połączeń.

Apache

Apache używa czegoś, co nazywa się MPM- Multi-Processing Modules. Administratorzy używają różnych modułów MPM do manipulowania i modyfikowania architektury obsługi połączeń. Częścią atrakcyjności serwera WWW Apache jest elastyczność, jaką oferuje jego architektura. Taka oparta na modułach infrastruktura, która dzieli przetwarzanie na pojedyncze wątki i grupy wątków, ułatwia skalowanie i dostosowywanie do różnych rodzajów połączeń.

Przyjrzyjmy się niektórym z poszczególnych modułów używanych w Apache:

• mpm_prefork

Pierwszym z nich jest mpm_prefork. Jest to moduł przetwarzania odpowiedzialny za obsługę żądań przychodzących od odwiedzających. Tworzy on jeden wątek lub proces potomny do obsługi jednego połączenia w danym momencie. Oznacza to, że jeśli liczba żądań jest mniejsza niż liczba procesów, mpm_prefork działa bardzo wydajnie.

Żądania są przetwarzane szybko, ponieważ osobny proces potomny przetwarza każde z nich indywidualnie. Oznacza to jednak również, że jeśli liczba żądań przekroczy liczbę procesów, może to znacznie spowolnić działanie. W rezultacie etap przetwarzania żądań zużywa dużo pamięci RAM.

• mpm_worker

Jak już wiemy, jeden wątek odpowiada za jedno połączenie. Ten moduł idzie o krok dalej i umożliwia zarządzanie wieloma wątkami jednocześnie. Jest to moduł znacznie bardziej skalowalny w porównaniu do mpm_prefork, który ma trudności po przekroczeniu określonego progu. Nowe połączenia mogą natychmiast połączyć się z wątkiem, zamiast czekać w kolejce.

• mpm_event

Mpm_event odpowiada za utrzymywanie połączeń typu keep-alive. Głównym celem tego modułu jest zapobieganie przeciążeniu systemu z powodu żądań keep-alive. Robi to poprzez przypisanie wątku do połączenia nawet przy braku aktywnego żądania. Wątek pozostanie dedykowany tak długo, jak długo połączenie będzie aktywne. Wszelkie przychodzące żądania są przekazywane do wolnych wątków.

Nginx

W przeciwieństwie do Apache, Nginx został stworzony z myślą o bardzo konkretnym celu. Znaliśmy już problemy, które pojawiały się z połączeniami i skalowalnością na tym poziomie. Dlatego korzysta on z algorytmu, który jest asynchroniczny i nieblokujący. Nie dedykuje on pojedynczych wątków dla każdego połączenia. Zamiast tego Nginx tworzy liczne procesy robocze, które są w stanie obsłużyć tysiące połączeń jednocześnie.

Zasadą działania architektury Nginx jest mechanizm szybkiej pętli. Algorytm ten stale przetwarza zdarzenia i je monitoruje. Oznacza to, że procesy są sterowane zdarzeniami, a każdy proces roboczy jest przypisany wyłącznie do własnych połączeń. Wszystkie połączenia procesu roboczego znajdują się w pętli zdarzeń. Tutaj współistnieją i są przetwarzane asynchronicznie wraz z innymi połączeniami w ramach tego konkretnego procesu roboczego.

Główną zaletą takiej architektury jest to, że pozwala ona na ogromną skalowalność. Staje się to szczególnie przydatne, jeśli dysponujesz ograniczonymi zasobami lub chcesz pracować na minimalnym sprzęcie. Nawet przy bardzo dużym natężeniu ruchu wpływ na zużycie pamięci RAM będzie niewielki. Dzieje się tak, ponieważ nie generujesz osobnych wątków dla każdego połączenia.

Obsługa zawartości statycznej i dynamicznej

Kolejnym parametrem, którego możemy użyć do porównania obu serwerów WWW, jest sposób, w jaki obsługują one statyczną i dynamiczną zawartość.

Apache

Apache używa metody opartej na plikach do obsługi statycznej zawartości. Jego system przetwarzania MPM pozwala mu na pracę z tą konwencjonalną metodą.

Jeśli chodzi o przetwarzanie dynamicznej zawartości, Apache może to robić bez pomocy jakichkolwiek zewnętrznych komponentów. Możesz włączyć procesory dynamiczne poprzez załadowanie modułu. Moduł ten przetworzy zawartość, analizując język, a następnie osadzając odpowiedni procesor w procesie roboczym.

Główna korzyść z braku konieczności używania zewnętrznych komponentów do przetwarzania dynamicznej zawartości jest widoczna podczas konfiguracji i koordynacji. O wiele łatwiej jest koordynować ze sobą wyłącznie komponenty wewnętrzne.

Nginx

Największą różnicą między sposobem, w jaki Apache i Nginx obsługują zawartość, jest to, że Nginx po prostu nie jest w stanie przetwarzać dynamicznej zawartości wewnętrznie. Musi być połączony z zewnętrznym komponentem w celu przetwarzania żądań dotyczących dynamicznej zawartości. Oznacza to, że będziesz musiał używać serwera Nginx w połączeniu z zewnętrznym procesorem. Komponent ten otrzyma żądanie dotyczące PHP/dynamicznej zawartości, przetworzy je, a następnie odeśle z powrotem do serwera.

Ponieważ informacje muszą być przekazywane między dwoma komponentami, konieczne będzie skoordynowanie komunikacji między nimi. Musisz określić, na ile połączeń chcesz zezwolić, i skonfigurować protokół. Musisz użyć protokołu, który może być odczytany i zrozumiany przez Nginx, takiego jak między innymi HTTP, FastCGI, SCGI, uWSGI lub memcache.

Z drugiej strony, Nginx radzi sobie naprawdę dobrze z obsługą treści statycznych. Wymaga pomocy z jakichkolwiek zewnętrznych źródeł, aby to zrobić. Aktywuje również interpreter tylko wtedy, gdy jest to potrzebne. Jest to jedna z zalet korzystania z Nginx. Interpreter nie jest osadzony w procesie. Oznacza to, że będzie obecny tylko przy przetwarzaniu treści dynamicznych.

Katalogi zawartości: konfiguracja rozproszona a scentralizowana

Każdy serwer WWW ma swój własny katalog zawartości. Jednym z najważniejszych parametrów, według których ocenia się Apache i Nginx, jest to, czy zezwalają one na konfigurację na poziomie katalogu.

Apache

W katalogach zawartości znajdują się pewne ukryte pliki, które zawierają dyrektywy. Są to pliki .htaccess. W przypadku Apache można interpretować te dyrektywy dla każdego katalogu z osobna. W ten sposób, gdy wysyłasz żądanie, Apache sprawdzi ścieżkę do pliku, aby znaleźć plik .htaccess. Gdy go znajdzie, natychmiast zinterpretuje i zastosuje zawarte w nim dyrektywy. Apache nie będzie restartować serwera w celu wdrożenia tych dyrektyw.

Zdefiniowany powyżej proces pozwala na zdecentralizowaną konfigurację katalogów na serwerze WWW. Zdecentralizowana konfiguracja jest przydatna do przepisywania adresów URL, wdrażania ograniczeń dostępu, potwierdzania autoryzacji i ustawiania reguł buforowania.

Jedną z zalet pliku .htaccess jest to, że użytkownik, który nie posiada uwierzytelnienia, może kontrolować i modyfikować przynajmniej niektóre aspekty zawartości, którą przegląda w swojej przeglądarce. Dlatego Apache jest często używany przez dostawców hostingu współdzielonego. Dostawcy usług mają autoryzowany dostęp do centralnej konfiguracji. Klienci mogą kontrolować określone katalogi bez dostępu do głównej konfiguracji.

Jeśli chcesz, możesz wyłączyć interpretację .htaccess w Apache.

Nginx

W przeciwieństwie do Apache, Nginx nie obsługuje plików .htaccess. Czyni go to stosunkowo mniej elastycznym. Jednak w zamian Nginx wprowadza szereg ulepszeń w swoim stylu konfiguracji. Po pierwsze, jest w stanie przetwarzać żądania znacznie szybciej niż Apache. Dzieje się tak, ponieważ nie wyszukuje, nie czyta, nie interpretuje, a następnie nie wdraża każdego pliku .htaccess, który znajdzie na swojej ścieżce. Zamiast przeszukiwać każdy katalog nadrzędny, Nginx wykonuje tylko jedno wyszukiwanie katalogu dla jednego żądania.

Dodatkowo Nginx ma ogromną przewagę pod względem bezpieczeństwa nad Apache. Nginx nie przekazuje żadnej części konfiguracji katalogów zawartości poszczególnym użytkownikom, w przeciwieństwie do Apache. Choć Ty możesz utrzymywać rygorystyczne środki bezpieczeństwa, kto powiedział, że poszczególni użytkownicy są w stanie zrobić to samo? Dzięki Nginx zachowujesz kontrolę nad stanem bezpieczeństwa i konfiguracją całej sieci katalogów.

Interpretacja żądań

Innym sposobem na rozróżnienie tych dwóch serwerów jest sposób, w jaki interpretują one żądania.

Apache

Gdy serwer otrzymuje żądanie, interpretuje je, a następnie łączy z odpowiednimi zasobami systemowymi. Interpretuje żądanie albo jako zasób fizyczny w systemie plików, albo jako lokalizację URI.

Podczas interpretacji jako zasób fizyczny, używa bloków <Directory> lub <Files>. Jest to domyślna metoda interpretacji dla serwera. Pobiera katalog główny dokumentu. Następnie podąża za hostem i numerem portu w żądaniu, aby znaleźć odpowiedni plik w drzewie dokumentów.

Z kolei lokalizacja URI wymaga abstrakcyjnej oceny. Dlatego Apache stosuje bloki <Location> dla zasobów abstrakcyjnych, zamiast pracować z systemem plików.

Istnieje szereg innych alternatyw dla korzystania z domyślnego systemu opartego na plikach, poza URI. Na przykład można użyć dyrektywy Alias, aby znaleźć alternatywną lokalizację do mapowania. Można również skorzystać z wariantów wyrażeń, aby uelastycznić konfigurację systemu plików.

Nginx

Podczas gdy Apache został stworzony, aby być serwerem WWW, Nginx pełni podwójną rolę – zarówno serwera WWW, jak i serwera proxy. Dlatego zamiast skłaniać się ku systemowi plików, Nginx woli pracować z adresami URI. Tę preferencję obrazuje fakt, że w Nginx nie ma możliwości określenia konfiguracji dla katalogu systemu plików. Może on jednak w razie potrzeby dokonać translacji na system plików.

Bloki konfiguracyjne server i location są głównymi elementami używanymi w Nginx. Pierwszy z nich interpretuje żądany host. Drugi dopasowuje części URI po hoście i porcie. W rezultacie serwer interpretuje żądanie jako lokalizację URI, a nie jako rzeczywisty plik w systemie.

Dzięki systemowi interpretacji opartemu na URI, Nginx może pełnić rolę serwera WWW, serwera proxy oraz serwera pocztowego. Ponieważ podczas interpretacji żądania nie odwołuje się do systemu plików, zrozumiałe jest, dlaczego nie obsługuje również plików .htaccess.

Systemy modułów

Choć zarówno Apache, jak i Nginx oferują obsługę systemów modułów w celu rozszerzenia funkcjonalności, istnieją istotne różnice w ich wewnętrznym działaniu.

Apache

W przypadku Apache można dynamicznie ładować i wyładowywać moduły podczas działania serwera. Rdzeń pozostaje w centrum procesów, a moduły służą do rozszerzania funkcjonalności. Możesz użyć tych dołączanych modułów do realizacji wielu zadań. Opcje są praktycznie nieograniczone dzięki ogromnej bibliotece Apache.

W rzeczywistości można nawet modyfikować działanie rdzenia serwera za pomocą modułów takich jak  mod_php. Jak wspomnieliśmy wcześniej, moduł ten pozwala na osadzenie interpretera PHP w poszczególnych procesach roboczych. Jest to przydatne, gdy zachodzi potrzeba przetwarzania dynamicznej zawartości.

Na tym jednak historia się nie kończy. Można również dodawać moduły umożliwiające realizację takich funkcji jak uwierzytelnianie klientów, zabezpieczanie serwera (hardening), buforowanie, przepisywanie adresów URL (URL rewriting), serwery proxy, ograniczanie liczby żądań (rate limiting), kompresja, a także szyfrowanie.

Nginx

System modułów w Nginx różni się tym, że nie można dynamicznie ładować modułów do głównego serwera. Zamiast tego muszą one zostać zebrane i skompilowane wraz z oprogramowaniem rdzenia. Pozostawia to wiele do życzenia pod względem elastyczności i łatwości użytkowania. Chociaż pakiety dystrybucyjne zawierają pewne popularne moduły, w przypadku innych modułów konieczne będzie samodzielne zbudowanie serwera. W związku z tym musisz wiedzieć, jak utrzymywać skompilowane oprogramowanie poza tradycyjnym systemem pakietów.

Niezależnie od tego, zaletą tego niestandardowego systemu modułów jest to, że zapewnia on wysoki stopień precyzji. Możesz dostosować swoje moduły, włączając tylko te funkcjonalności, których potrzebujesz. Pozwala to porzucić niepotrzebne komponenty i uchronić się przed ryzykiem związanym z bezpieczeństwem. Jednocześnie za pomocą modułów Nginx można realizować te same zadania, co w przypadku Apache. Obejmują one przepisywanie adresów URL, logowanie, uwierzytelnianie i tak dalej.

Ekosystem i wsparcie

Integracje i wsparcie dla oprogramowania są bardzo ważne, jeśli chodzi o serwery WWW. Następnie przyjrzymy się kompatybilności i wsparciu dostępnemu dla Apache i Nginx.

Apache

Apache to starsza i bardziej popularna platforma. Zrozumiałe jest więc, że posiada większą gamę narzędzi i oprogramowania wspierającego w porównaniu do Nginx. Do dyspozycji jest mnóstwo dokumentacji firm trzecich, która wspiera serwer główny. Co więcej, można go łączyć z innym oprogramowaniem w celu realizacji określonych zadań. Narzędzia te można dodać do swojego projektu lub pakietu. Są one w stanie łatwo zintegrować się i uruchomić w ekosystemie Apache.

Nginx

Choć Nginx ustępuje pod tym względem serwerowi Apache, z pewnością robi wszystko, co w jego mocy, aby go dogonić. Coraz więcej osób decyduje się na Nginx, gdy dostrzega jego pełny potencjał. Wsparcie dla tej platformy stale rośnie wraz z jej organicznym rozwojem jako użytecznego, szybko przetwarzającego serwera WWW.

Jedną z głównych przeszkód w zakresie wsparcia, z którymi musiał zmierzyć się Nginx, było znalezienie dokumentacji w języku angielskim. Wynikało to z faktu, że większość Nginx została pierwotnie napisana w języku rosyjskim, w tym większość jego dokumentacji. Jednak w miarę jak serwer zyskiwał popularność i stawał się coraz bardziej znany, w tym uniwersalnym języku pojawiło się mnóstwo zasobów zewnętrznych.

Wspólne rozwiązanie?

Teraz masz już znacznie lepsze wyobrażenie o kluczowych komponentach i wewnętrznym działaniu Apache i Nginx. Choć dość mocno się od siebie różnią, niektórzy użytkownicy wykorzystują ten fakt, aby połączyć to, co najlepsze w obu rozwiązaniach. To prawda – możliwe jest jednoczesne korzystanie z Apache i Nginx.

Zazwyczaj użytkownicy używają Nginx jako reverse proxy i umieszczają go przed Apache. Pozwala to zrekompensować brak szybkości w obsłudze i przetwarzaniu żądań przez Apache. Nginx odbiera i obsługuje wszystkie żądania z maksymalną prędkością. Umożliwia to również szybką obsługę dużej liczby jednoczesnych żądań bez konieczności inwestowania wielu zasobów.

Inną funkcją Nginx, którą wykorzystują użytkownicy, jest jego zdolność do wydajnej obsługi statycznej zawartości. Aby zrekompensować fakt, że Nginx wymaga zewnętrznego komponentu do przetwarzania dynamicznej zawartości, możemy przekierować PHP i inne odpowiednie żądania do Apache za pośrednictwem proxy. Apache wyrenderuje żądanie jako stronę internetową i odeśle je z powrotem do Nginx, aby ten mógł obsłużyć klienta.

Oto kilka zasobów, które można znaleźć na naszym blogu, które pomogą Ci zacząć pracę z obydwoma serwerami WWW:

Apache

• Instalacja serwera Apache na Ubuntu 18.04: Poradnik krok po kroku
• Konfiguracja wirtualnych hostów Apache na Ubuntu 20.04
• Jak zainstalować stos Linux, Apache, MySQL, PHP (LAMP) na CentOS 7
• Zabezpieczanie Apache za pomocą Let’s Encrypt na Ubuntu 18.04

Nginx

• Instalacja Nginx na Ubuntu 18.04
• Automatyzacja odnawiania certyfikatów SSL LetsEncrypt dla Nginx
• Jak zabezpieczyć Nginx za pomocą Let’s Encrypt na Ubuntu 20.04
• Jak zainstalować stos LEMP (Linux, Nginx, MySQL PHP) na Ubuntu 20.04

Podsumowanie

Koniec końców, zarówno Apache, jak i Nginx mają swoje mocne i słabe strony. Nie ma sztywnych reguł ani zaleceń dotyczących tego, którego serwera należy użyć w swoim projekcie. To Ty najlepiej ocenisz, co sprawdzi się najlepiej w przypadku Twojej aplikacji, w oparciu o swoje unikalne wymagania.

Musisz określić aspekty i funkcje, z których nie możesz zrezygnować, i dokonać odpowiedniego wyboru. Jeśli podjęcie decyzji jest trudne, zawsze możesz zdecydować się na korzystanie z obu serwerów jednocześnie w ramach spersonalizowanego rozwiązania.

Udanego korzystania!