Co to jest Nginx i dlaczego jest tak popularnym serwerem WWW?

Nginx to serwer WWW o otwartym kodzie źródłowym, który obsługuje ruch sieciowy, działa jako reverse proxy i zarządza obciążeniem aplikacji. Jego popularność wynika wprost z asynchronicznej architektury, która pozwala na jednoczesne utrzymywanie dziesiątek tysięcy połączeń przy minimalnym zużyciu pamięci RAM.

Kiedy w 2004 roku Igor Sysoev wypuścił pierwszą publiczną wersję tego oprogramowania, internet dławił się od nadmiaru jednoczesnych żądań. W tamtym czasie dominował Apache. Problem polegał na tym, że Apache tworzył nowy proces dla każdego użytkownika wchodzącego na stronę. Przy tysiącu osób na raz serwer po prostu umierał z braku pamięci. Nginx rozwiązał ten problem inaczej. Przeniósł obsługę połączeń na model oparty o zdarzenia (event-driven). Zamiast przypisywać jeden ciężki proces do jednego klienta, Nginx używa małej liczby procesów roboczych (worker processes), z których każdy potrafi asynchronicznie obsłużyć tysiące zapytań w tej samej sekundzie. To absolutnie zmienia zasady pracy z infrastrukturą.

Wdrażaliśmy to oprogramowanie w zeszłym miesiącu dla małego sklepu z częściami samochodowymi na obrzeżach Poznania. Mieli stary serwer VPS z 2 GB RAM. Stary system padał przy każdej kampanii reklamowej. Zmieniliśmy te zasady na robocie. Wyrzuciliśmy Apache, postawiliśmy Nginx z prostym proxy w stronę PHP-FPM. Zużycie pamięci spadło o blisko osiemdziesiąt procent w ciągu piętnastu minut. Sklep przetrwał Black Friday bez zadyszki. I działa bez problemu do dzisiaj.

Jak działa asynchroniczna architektura Nginx i dlaczego wygrywa z konkurencją?

Większość ludzi z IT instaluje serwery WWW z przyzwyczajenia. Wpisują komendę w terminalu, uruchamiają usługę i zapominają o sprawie. Nginx wymusza zrozumienie tego, co dzieje się pod spodem z ruchem sieciowym. Architektura tego rozwiązania opiera się na głównej pętli zdarzeń. Kiedy zapytanie HTTP trafia na port 80 lub 443, serwer nie czeka na wygenerowanie pełnej odpowiedzi przez aplikację bazową. Przyjmuje zapytanie, deleguje je dalej na przykład do bazy danych lub interpretera Pythona, i natychmiast wraca do nasłuchiwania kolejnych użytkowników.

Dzięki temu zjawisko blokowania wejścia i wyjścia (I/O blocking) praktycznie tu nie występuje. To jest powód, dla którego Nginx bez problemu radzi sobie z tak zwanym problemem C10K, czyli barierą dziesięciu tysięcy jednoczesnych połączeń. Prawda jest zresztą absolutnie taka, że połowa mniejszych firm używa Nginxa tylko dlatego, że ktoś inny skopiował plik konfiguracyjny z forum internetowego dekadę temu i nikt tego potem nie tyka. Ktoś wpisuje złą ścieżkę w bloku location i nagle CAŁY ruch idzie w próżnię. Wymaga to precyzji.

Serwer dzieli się na proces główny (master) i procesy robocze (workers). Główny proces czyta konfigurację z pliku i zarządza portami. Procesy robocze wykonują faktyczną pracę. Dobrym pomysłem jest ustawienie dyrektywy worker_processes auto; w pliku konfiguracyjnym. Oznacza to, że Nginx sam sprawdzi, ile rdzeni ma twój procesor i uruchomi dokładnie tyle procesów roboczych. Mniej rdzeni to mniej procesów. Prosta matematyka.

Do czego służy Nginx w codziennej pracy administratora sieci?

Rola zwykłego serwowania stron HTML odeszła w zapomnienie. Nginx to dzisiaj kombajn do zarządzania ruchem przed aplikacjami napisanymi w Node.js, Go lub Javie. Deweloperzy rzadko wystawiają swoje aplikacje bezpośrednio na świat. Stawiają przed nimi ścianę. Tą ścianą jest Nginx pełniący funkcję reverse proxy. Odbiera on żądania od klientów, modyfikuje nagłówki, sprawdza certyfikaty SSL/TLS i dopiero po weryfikacji przepuszcza ruch do aplikacji ukrytej w sieci wewnętrznej na porcie 3000 lub 8080.

Oto cztery najczęstsze zastosowania tego oprogramowania na produkcji:

• Reverse proxy i terminacja SSL. Nginx przyjmuje szyfrowany ruch HTTPS, odszyfrowuje go za pomocą podpiętych certyfikatów, a następnie wysyła czysty ruch HTTP do aplikacji lokalnej. Zdejmuje to potężny ciężar obliczeniowy z samej aplikacji, która nie musi już zajmować się kryptografią i zarządzaniem kluczami publicznymi.
• Równoważenie obciążenia (Load balancer).
• Cache dla plików i zapytań bazodanowych. Możesz wymusić na serwerze przetrzymywanie wygenerowanych stron w pamięci podręcznej. Kiedy drugi użytkownik prosi o ten sam adres URL, Nginx serwuje mu gotowy plik z dysku, w ogóle nie budząc aplikacji w tle.
• Mikroserwisy.

Zwróć uwagę na load balancing. Kiedy masz trzy serwery z tą samą aplikacją, Nginx decyduje, gdzie wysłać konkretnego użytkownika. Domyślnie używa algorytmu round-robin, czyli rozdaje ruch po kolei. Pierwszy klient idzie na serwer A, drugi na serwer B, trzeci na C. Ale my często na wdrożeniach zmieniamy to na metodę ip_hash. Wtedy klient o konkretnym adresie IP zawsze trafia na ten sam serwer pod spodem. To ratuje sytuację, kiedy aplikacja trzyma sesję logowania w lokalnej pamięci pojedynczej maszyny i nie współdzieli jej z resztą klastra.

Jak szybko skonfigurować Nginx jako reverse proxy dla Node.js?

Proces instalacji zajmuje minutę. W systemach opartych na Debianie wpisujesz apt install nginx i masz działającą usługę. Schody zaczynają się w katalogu /etc/nginx/sites-available/. Tam tworzysz pliki konfiguracyjne dla swoich domen. Struktura opiera się na blokach server i location.

Wyobraźmy sobie prosty scenariusz z życia. Masz napisaną w Express.js aplikację działającą na porcie 4000. Chcesz, żeby była widoczna pod główną domeną w internecie. W pliku konfiguracyjnym musisz otworzyć blok server, nakazać nasłuchiwanie na porcie 80 i zdefiniować proxy_pass. Wygląda to w dużym uproszczeniu tak, że każesz Nginxowi brać wszystko ze ścieżki / i przekierowywać na http://localhost:4000. Do tego dorzucasz dyrektywy proxy_set_header, żeby aplikacja w Node.js wiedziała, z jakiego prawdziwego adresu IP przyszedł klient. W przeciwnym razie twoje logi w aplikacji będą pokazywać, że każdy użytkownik to localhost.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj we wtorek konfigurując blok serwera w Dockerze. Jeśli nie przekażesz nagłówka Host, aplikacja pod spodem zgłupieje przy generowaniu linków absolutnych do obrazków. Jedna pominięta linijka w konfiguracji i cały interfejs graficzny sypie błędami 404.

Dlaczego Nginx miażdży konkurencję przy serwowaniu plików statycznych?

Aplikacje internetowe składają się w dużej mierze z obrazków, arkuszy CSS i skryptów JavaScript. To są pliki statyczne. Nie trzeba ich kompilować ani przetwarzać. Trzeba je tylko przeczytać z dysku twardego i wysłać kablem do użytkownika. W tym obszarze Nginx nie ma sobie równych.

Wszystko rozbija się o dwie dyrektywy systemowe: sendfile oraz tcp_nopush. Kiedy Nginx ma wysłać plik, nie kopiuje go z dysku do pamięci RAM przestrzeni użytkownika, a stamtąd do bufora sieciowego. To by było marnowanie zasobów. Zamiast tego, włączenie dyrektywy sendfile powoduje, że serwer instruuje jądro systemu operacyjnego Linux, aby przegrało plik bezpośrednio z systemu plików na kartę sieciową. Przeskok przez przestrzeń użytkownika zostaje całkowicie wyeliminowany.

Dodatkowo tcp_nopush sprawia, że serwer nie wysyła pakietów sieciowych po kawałku. Zbiera je w jeden duży pakiet i wysyła hurtem. To drastycznie zmniejsza narzut na protokół TCP. Kiedy postawisz zwykłego bloga i podepniesz pod niego Nginxa w roli serwera plików statycznych, zużycie procesora na maszynie spada niemal do zera, nawet przy setkach odwiedzających. To jest po prostu wydajność na poziomie sprzętowym wpisana w kod oprogramowania.

W jaki sposób serwer WWW chroni przed atakami DDoS i przeciążeniem?

Ataki typu Distributed Denial of Service to codzienność. Ktoś kieruje botnet na twoją domenę i wysyła pięćdziesiąt tysięcy zapytań na sekundę. Jeśli ten ruch dotrze do twojej bazy danych, system padnie. Nginx działa jak strefa buforowa. Pozwala odciąć złośliwy ruch jeszcze zanim dotknie on właściwej logiki biznesowej twojej firmy.

Wdrażamy to za pomocą modułu limit_req. Pozwala on na zdefiniowanie tak zwanej strefy pamięci współdzielonej (shared memory zone), w której serwer trzyma informacje o adresach IP i częstotliwości ich zapytań. Możesz napisać regułę, która mówi: ten konkretny adres IP ma prawo wejść na stronę logowania maksymalnie dwa razy na sekundę. Jeśli spróbuje wejść trzeci raz w tym samym czasie, Nginx odrzuci zapytanie i zwróci błąd 503 Service Unavailable.

Używamy też dyrektywy limit_conn, która ucina liczbę jednoczesnych połączeń z jednego adresu. Zwykły użytkownik przeglądarki otwiera kilka połączeń, żeby pobrać tekst i obrazki. Bot skanujący luki w zabezpieczeniach otwiera ich pięćset. Nginx odcina te anomalia na poziomie stosu sieciowego. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku ataków po wdrożeniu globalnych filtrów u dostawców chmury.

Do tego dochodzi ukrywanie informacji o wersji oprogramowania. Dyrektywa server_tokens off; usuwa z nagłówków HTTP numer wersji Nginxa. Skanery szukające podatności nie wiedzą, z jak starym systemem mają do czynienia, co utrudnia automatyczne ataki na konkretne luki w kodzie C.

Kiedy Nginx się nie sprawdza i czy ma jakieś słabe strony?

Nie ma technologii bez skaz. Zawsze znajdzie się przypadek użycia, w którym dane narzędzie po prostu przeszkadza. Nginx, pomimo swojej szybkości, przez wiele lat miał potężny problem z dynamicznym ładowaniem modułów. W Apache, jeśli potrzebujesz nowego modułu, po prostu ściągasz plik, dodajesz linijkę w konfiguracji i restartujesz usługę. W starszych wersjach Nginxa musiałeś rekompilować cały serwer z kodu źródłowego, żeby dodać jedną drobną funkcjonalność. Zmieniono to w nowszych wydaniach, ale wiele systemów legacy nadal na to cierpi.

Druga sprawa to środowisko Windows. Nginx został napisany z myślą o systemach uniksowych. Jego implementacja na systemach od Microsoftu działa, ale używa metody select() zamiast wydajnego epoll(), co całkowicie zabija jego asynchroniczną przewagę. Jeśli musisz postawić serwer produkcyjny na Windows Server, IIS jest jedynym sensownym wyborem. Nginx na Windowsie to zabawka dla programistów do testów lokalnych.

Kolejny aspekt to pliki .htaccess. Apache pozwala na wrzucenie pliku .htaccess do dowolnego katalogu ze stroną i natychmiastowe nadpisanie reguł serwera bez jego restartowania. To ulubiona funkcja twórców tanich hostingów współdzielonych. Nginx tego nie obsługuje wcale. Cała konfiguracja musi znajdować się w głównych plikach systemowych. Wynika to z faktu, że szukanie plików .htaccess po całym dysku przy każdym zapytaniu potwornie spowalnia dysk twardy. Nginx stawia na wydajność, więc zmusza administratora do trzymania porządku w jednym miejscu.

Porównanie Nginx i Apache w środowisku produkcyjnym

Zestawienie tych technologii obok siebie daje jasny obraz ich przeznaczenia. Zbudowaliśmy krótką tabelę z twardymi faktami, bez lania wody o ogólnej przydatności.

Wybór nie sprowadza się do rzutu monetą. Jeśli budujesz nowoczesną aplikację opartą o mikroserwisy w Dockerze, Nginx zjada konkurencję na śniadanie. Jeśli utrzymujesz stary portal w PHP, gdzie każdy dział marketingu chce mieć własne reguły przekierowań w ukrytych plikach tekstowych na FTP, Apache oszczędzi ci siwych włosów na głowie.

Wejdź na swój serwer, wyłącz stary proces, postaw Nginx na porcie 80 i puść z konsoli test obciążeniowy. Zobaczysz na własne oczy, jak spada użycie procesora. Zrób to dzisiaj i przestań przepalać zasoby na przestarzałe nawyki architektoniczne.

Często zadawane pytania (FAQ)

• Co to jest Nginx?
  Nginx to asynchroniczny serwer WWW o otwartym kodzie źródłowym. Służy do obsługi ruchu sieciowego, działa jako reverse proxy, load balancer oraz bardzo szybki serwer plików statycznych.
• Dlaczego Nginx jest szybszy od Apache?
  Nginx używa architektury opartej na zdarzeniach (event-driven). Zamiast przypisywać jeden ciężki proces do każdego użytkownika, przetwarza tysiące połączeń w jednym wątku roboczym, co oszczędza pamięć RAM i procesor.
• Do czego służy Nginx w roli reverse proxy?
  Odbiera ruch z internetu, weryfikuje certyfikaty SSL/TLS, a następnie przekazuje bezpieczne żądania do wewnętrznych aplikacji napisanych w technologiach takich jak Node.js, Python czy Java.
• Czy Nginx obsługuje pliki .htaccess?
  Nie. Nginx ze względów wydajnościowych nie obsługuje rozproszonych plików .htaccess. Cała konfiguracja musi znajdować się w głównym pliku konfiguracyjnym serwera.
• Jak Nginx radzi sobie z atakami DDoS?
  Serwer posiada wbudowane moduły do limitowania liczby zapytań (limit_req) oraz ograniczania jednoczesnych połączeń z jednego adresu IP (limit_conn), co skutecznie odcina ruch z botnetów.
• Czy warto używać Nginx na systemie Windows?
  Nie zaleca się tego na środowiskach produkcyjnych. Nginx na Windowsie nie wykorzystuje swojej asynchronicznej architektury z powodu ograniczeń systemowych API.

Bibliografia

1. Dokumentacja Nginx – https://nginx.org
2. Fundacja Apache Software – https://apache.org
3. Baza wiedzy Mozilla Developer Network – https://developer.mozilla.org
4. Serwis dla deweloperów Stack Overflow – https://stackoverflow.com