Lighttpd vs Nginx – który lekki serwer WWW wybrać? Porównanie

Wybór między tymi dwoma rozwiązaniami sprowadza się do prostego faktu: Nginx jest najlepszym wyborem dla zdecydowanej większości współczesnych aplikacji wymagających obsługi tysięcy jednoczesnych połączeń i zaawansowanego reverse proxy, podczas gdy Lighttpd wygrywa wyłącznie na skrajnie ograniczonych zasobowo urządzeniach wbudowanych i starych routerach. Jeśli szukałeś odpowiedzi na dylemat „Lighttpd vs Nginx – który lekki serwer WWW wybrać? Porównanie” z perspektywy standardowego serwera VPS, Nginx po prostu deklasuje rywala swoimi możliwościami. Kropka.

Zarządzanie infrastrukturą sieciową wymaga podejmowania twardych decyzji. Wielu administratorów zatrzymuje się na etapie wyboru oprogramowania obsługującego ruch HTTP. Instalują domyślnego Apache’a z przyzwyczajenia. To błąd. Odpowiednio dobrany lekki serwer WWW potrafi drastycznie obniżyć obciążenie procesora i zmniejszyć zapotrzebowanie na pamięć operacyjną maszyny. Nginx i Lighttpd powstały dokładnie w tym celu. Rozwiązują problem znany jako C10k, czyli wyzwanie polegające na jednoczesnej obsłudze dziesięciu tysięcy połączeń na jednym hoście. Osiągają to dzięki architekturze asynchronicznej.

Dlaczego w ogóle zestawiamy te dwa programy na jednym ringu?

Historia obu projektów sięga początków lat dwutysięcznych. Lighttpd (znany potocznie jako „lighty”) został napisany przez Jana Kneschke w 2003 roku. Miał być odpowiedzią na ociężałość ówczesnych serwerów. Nginx, stworzony przez Igora Sysoeva w 2004 roku, celował w ten sam problem u rosyjskiego giganta pocztowego Rambler. Oba systemy odrzuciły tradycyjny model tworzenia osobnego wątku lub procesu dla każdego nowego klienta. Zastosowały pętlę zdarzeń (event loop). Różnice pojawiają się jednak w sposobie, w jaki te pętle są zarządzane i skalowane na nowoczesnych procesorach wielordzeniowych.

Nginx rozdziela pracę na jeden proces główny (master) i kilka procesów roboczych (worker). Każdy worker działa jednowątkowo i asynchronicznie przetwarza tysiące żądań. Lighttpd opiera się na podobnym koncepcie, ale jego wewnętrzny mechanizm zarządzania deskryptorami plików bywa problematyczny przy bardzo dużej skali. Wdrażaliśmy to na starym sprzęcie w zeszłym kwartale. Szczerze mówiąc brakuje nam twardych danych z zeszłego tygodnia po aktualizacji systemu, ale padło wszystko na amen przy teście obciążeniowym z użyciem modułu FastCGI. Zmieniliśmy te zasady na robocie, przenieśliśmy ruch na Nginxa i cały backend ruszył od kopa. WKURZA mnie niesamowicie, gdy dokumentacja milczy na temat limitów deskryptorów plików przy specyficznych kompilacjach na architekturze ARM. Nginx ma to rozwiązane dużo lepiej na poziomie samej obsługi zdarzeń epoll.

Jakie są realne różnice w zużyciu pamięci RAM?

Lighttpd zadowoli się dosłownie kilkoma megabajtami pamięci RAM. Nginx na start potrzebuje bez mała prawie trzydzieści megabajtów w podstawowej konfiguracji z kilkoma workerami. Na starym Raspberry Pi pierwszej generacji albo na routerze z OpenWrt ta różnica decyduje o tym, czy urządzenie w ogóle wstanie po restarcie. Na serwerze w chmurze z 16 GB RAM nikt nie zauważy tej różnicy.

Przeprowadziliśmy własne pomiary w środowisku testowym. Wyniki prezentują się następująco:

Powyższa tabela wyraźnie wskazuje przewagę Lighttpd w kategorii absolutnego minimalizmu. Pytanie brzmi: czy ten minimalizm jest ci faktycznie potrzebny? Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Odpowiedź tkwi w obsłudze dynamicznych treści. Kiedy do gry wchodzi PHP-FPM lub aplikacje w Pythonie, sam serwer WWW przestaje być wąskim gardłem. Wąskim gardłem staje się interpreter języka i baza danych.

Lighttpd vs Nginx – który lekki serwer WWW wybrać do specyficznych wdrożeń? Porównanie funkcji proxy

Nginx jest potworem, jeśli chodzi o reverse proxy. To jego absolutnie największa zaleta. Pozwala na odbieranie ruchu z zewnątrz i płynne przekierowywanie go do wielu aplikacji backendowych działających na różnych portach. Ma wbudowane zaawansowane mechanizmy load balancingu, cachowania odpowiedzi z backendu oraz terminacji SSL. Lighttpd posiada moduł proxy, ale jego możliwości są drastycznie mniejsze. Brakuje mu opcji precyzyjnego zarządzania nagłówkami w locie i zaawansowanego routingu opartego na zawartości żądania.

Nginx potrafi:

• Rozdzielać ruch metodą Round Robin lub IP Hash bezpośrednio w bloku upstream.
• Zarządzać pamięcią podręczną FastCGI z dokładnością do pojedynczych ścieżek URI.
• Serwować przestarzały cache w przypadku awarii serwera backendowego (dyrektywa proxy_cache_use_stale).
• Zmieniać w locie nagłówki HTTP przed wysłaniem ich do klienta docelowego.

Lighttpd z kolei sprawdza się wybitnie dobrze przy serwowaniu małych, statycznych plików z dysku. Moduł mod_secdownload pozwala na generowanie tymczasowych linków do pobierania plików, co bywa przydatne w prostych systemach VOD lub archiwach. Nginx oferuje podobną funkcjonalność poprzez moduł secure_link, ale konfiguracja Lighttpd w tym konkretnym przypadku bywa dla niektórych czytelniejsza.

Czy składnia plików konfiguracyjnych ma znaczenie?

Konfiguracja Nginxa opiera się na blokach i kontekstach, przypominając nieco język C. Dziedziczenie dyrektyw potrafi być zdradliwe. Zdefiniowanie reguły w bloku `server` nie zawsze oznacza, że przejdzie ona automatycznie do zagnieżdżonego bloku `location`. Administratorzy często łapią się na tym błędzie, zostawiając otwarte luki w zabezpieczeniach lub psując nagłówki CORS. Lighttpd ma składnię przypominającą skrypty powłoki z instrukcjami warunkowymi IF/ELSE. Dla programisty starych skryptów bashowych plik `lighttpd.conf` jest bardzo czytelny.

Spójrzmy na prosty przykład przekierowania całego ruchu z HTTP na HTTPS w Nginx. Wymaga to stworzenia osobnego bloku serwera nasłuchującego na porcie 80 i użycia dyrektywy return 301. W Lighttpd załatwia się to prostym warunkiem sprawdzającym port docelowy żądania. Nginx wymusza na administratorze bardziej strukturalne myślenie o architekturze ruchu sieciowego.

Jak wygląda sprawa bezpieczeństwa i społeczności?

Społeczność skupiona wokół Nginxa jest gigantyczna. Setki tysięcy postów na forach, gotowe konfiguracje na GitHubie i natychmiastowe łatki na wykryte błędy podatności. Używamy go na większości naszych maszyn i nigdy nie czekaliśmy na patch bezpieczeństwa dłużej niż kilkanaście godzin. Lighttpd rozwija się znacznie wolniej. Projekt żyje i ma się dobrze, ale tempo wprowadzania innowacji jest nieporównywalnie mniejsze. Wdrożenie obsługi nowych protokołów, takich jak HTTP/3 czy QUIC, pojawia się w Nginx znacznie szybciej.

Zabezpieczenie Nginxa przed atakami typu Slowloris polega na odpowiednim dostrojeniu dyrektyw `client_body_timeout` i `client_header_timeout`. Ograniczenie liczby żądań na sekundę z jednego adresu IP to zaledwie dwie linijki z użyciem modułu limit_req. W Lighttpd podobne efekty uzyskuje się przez moduł evasi, ale jego elastyczność jest mniejsza. Z punktu widzenia komercyjnego środowiska produkcyjnego, Nginx daje po prostu narzędzia gotowe do walki z agresywnym ruchem z sieci.

Kiedy instalacja Lighttpd ma jeszcze jakikolwiek sens techniczny?

Zostawmy na chwilę potężne serwery w chmurze. Wyobraź sobie system monitoringu w magazynie oparty na kilkunastu terminalach z procesorami o taktowaniu 400 MHz i 64 MB pamięci operacyjnej. Wrzucenie tam Nginxa zabije te maszyny na starcie. Lighttpd wejdzie tam bez problemu, obsłuży prosty interfejs webowy przez FastCGI z lekkim skryptem w C lub Lua i zostawi jeszcze zasoby na właściwe działanie sprzętu. To jest jego naturalne środowisko. Sprzęt IoT, tanie routery domowe, systemy wbudowane w przemyśle. Tam „lighty” wciąż nie ma sobie równych.

Prawda jest zresztą absolutnie taka, że mało kto ma dzisiaj do czynienia z takimi ograniczeniami sprzętowymi w standardowej pracy web developera. Dlatego Nginx przejął rynek. Wszechobecność wirtualizacji i kontenerów Docker sprawiła, że narzut pamięciowy rzędu kilkudziesięciu megabajtów przestał mieć jakiekolwiek znaczenie operacyjne. Liczy się wygoda konfiguracji w środowiskach CI/CD. Nginx integruje się z Kubernetesem jako Ingress Controller. Lighttpd w tym ekosystemie praktycznie nie istnieje.

Optymalizacja pod kątem wyszukiwarek i szybkość ładowania

Szybkość serwowania pierwszego bajtu (TTFB) to twardy wskaźnik dla algorytmów Google. Nginx w połączeniu z odpowiednio skonfigurowanym mechanizmem FastCGI Cache potrafi skrócić TTFB do kilkunastu milisekund. Omija całkowicie interpreter PHP i serwuje gotowy plik HTML prosto z pamięci RAM. Lighttpd również obsługuje cache, ale zarządzanie zwalnianiem pamięci podręcznej (cache purging) w przypadku aktualizacji treści na stronie jest w nim o wiele trudniejsze do wdrożenia.

Kompresja w locie to kolejny punkt sporny. Obie aplikacje wspierają gzip. Nginx oferuje jednak natywne wsparcie dla algorytmu Brotli (poprzez oficjalny moduł), który zapewnia lepszy stopień kompresji plików tekstowych przy podobnym obciążeniu procesora. Dla dużej redakcji prasowej kompresja Brotli na Nginx oznacza oszczędności rzędu terabajtów transferu miesięcznie. Wymaga to rekompilacji Nginxa lub instalacji z odpowiedniego repozytorium, ale korzyści są wymierne.

Konfiguracja certyfikatów SSL/TLS

Wdrożenie HTTPS stało się standardem. Konfiguracja Let’s Encrypt z Nginxem sprowadza się do uruchomienia bota Certbot, który sam modyfikuje pliki konfiguracyjne i ustawia automatyczne odnawianie. Moduł SSL w Nginx jest niezwykle rozbudowany. Pozwala na włączenie OCSP Stapling, wymuszanie ścisłego bezpieczeństwa transportu (HSTS) oraz precyzyjny dobór krzywych eliptycznych dla szyfrów. Lighttpd radzi sobie z SSL, ale integracja z automatycznymi narzędziami bywa kapryśna. Wymaga ręcznego łączenia certyfikatów i kluczy w jeden plik `.pem`, co przy kilkudziesięciu wirtualnych hostach staje się koszmarem administracyjnym.

Zarządzanie logami i debugowanie błędów

Praca z logami to codzienność każdego administratora. Nginx pozwala na całkowicie dowolne formatowanie logów dostępu. Możesz zapisać w nich czas przetwarzania żądania, status trafienia w cache, a nawet wartość konkretnego ciasteczka wysłanego przez klienta. To nieocenione przy analizie ruchu. Zapisujemy logi w formacie JSON i wysyłamy bezpośrednio do ElasticSearch. Lighttpd ma sztywniejsze formaty logowania. Zmiana struktury wymaga często oparcia się na zewnętrznych narzędziach parsujących.

Debugowanie konfiguracji Nginxa odbywa się za pomocą komendy `nginx -t`. Serwer weryfikuje składnię i ostrzega o potencjalnych konfliktach przed przeładowaniem usługi. Lighttpd posiada podobny mechanizm `lighttpd -t -f config_file`, jednak komunikaty o błędach w Nginx potrafią precyzyjniej wskazać numer linii i rodzaj uszkodzonego znaku w pliku konfiguracyjnym. To oszczędza mnóstwo czasu podczas nocnych wdrożeń.

Podjęcie decyzji w dylemacie „Lighttpd vs Nginx – który lekki serwer WWW wybrać? Porównanie” jest zadaniem prostym z technicznego punktu widzenia. Nginx daje ci pełną kontrolę nad ruchem HTTP. Działa jako serwer statyczny, potężne proxy, load balancer i bufor chroniący aplikacje backendowe przed atakami DDoS. Lighttpd to świetne narzędzie, zjadające absolutne minimum zasobów, przeznaczone na maszyny, o których zapomniał czas i producenci podzespołów. Wybierz narzędzie dopasowane do sprzętu, którym dysponujesz. Postaw Nginxa na serwerze i spróbuj sam napisać konfigurację blokującą ruch z zagranicznych adresów IP za pomocą modułu GeoIP. Przekonasz się od razu, dlaczego reszta rynku korzysta właśnie z tego oprogramowania.

FAQ – Najczęściej zadawane pytania

• Czy Nginx zużywa dużo więcej RAM niż Lighttpd?
  Nginx zużywa bazowo około 15-30 MB RAM przy podstawowej konfiguracji wieloprocesowej. Lighttpd potrafi działać stabilnie zużywając zaledwie 3-5 MB. Różnica jest ogromna procentowo, ale na nowoczesnych serwerach z gigabajtami pamięci nie ma żadnego znaczenia operacyjnego.
• Który serwer lepiej sprawdza się jako Reverse Proxy?
  Nginx zdecydowanie wygrywa. Posiada wbudowane, zaawansowane mechanizmy proxy, load balancingu i modyfikacji nagłówków w locie. Lighttpd ma podstawowe wsparcie proxy, ale brakuje mu funkcji znanych ze środowisk enterprise.
• Czy Lighttpd obsługuje protokół FastCGI do uruchamiania PHP?
  Tak. Lighttpd od samego początku był projektowany z myślą o świetnej i lekkiej obsłudze FastCGI. Działa z PHP-FPM równie stabilnie co Nginx, choć jego konfiguracja bywa nieco inna.
• Czy konfiguracja Nginx jest trudna dla początkujących?
  Składnia oparta o bloki i dziedziczenie dyrektyw wymaga zrozumienia logiki działania serwera. Na początku potrafi być myląca, zwłaszcza przy zagnieżdżaniu bloków `location`. Społeczność dostarcza jednak tysiące gotowych przykładów.
• Który serwer jest bezpieczniejszy i szybciej łatany?
  Nginx ma znacznie większy udział w rynku, co przekłada się na szybsze wykrywanie i łatanie podatności. Oficjalne aktualizacje wychodzą bardzo szybko po zgłoszeniu problemów bezpieczeństwa.
• Czy warto instalować Lighttpd na zwykłym VPS-ie?
  W zdecydowanej większości przypadków nie. Nginx oferuje znacznie większe możliwości rozwoju środowiska w przyszłości, obsługę lepszych modułów cachujących i łatwiejszą integrację z automatycznymi systemami wdrażania certyfikatów Let’s Encrypt.

Bibliografia

1. Nginx – https://nginx.org
2. Lighttpd – https://www.lighttpd.net
3. W3Techs – https://w3techs.com
4. GitHub – https://github.com