Nginx vs IIS – który serwer WWW wybrać dla aplikacji .NET?

Dla nowoczesnych aplikacji ASP.NET Core najlepszym wyborem jest Nginx działający jako reverse proxy na systemie Linux. Z kolei serwer IIS powinieneś wybrać wyłącznie wtedy, gdy utrzymujesz starsze systemy oparte na .NET Framework, które mocno integrują się ze specyficznym środowiskiem Windows Server.

Rozstrzygnięcie tego dylematu zależy bezpośrednio od architektury twojego kodu. Skompilowaliśmy setki projektów i prawda jest absolutnie taka, że czasy ślepego instalowania Windowsa pod każdą aplikację od Microsoftu minęły. Mamy rok, w którym .NET działa wszędzie. Więc wybór hostingu definiuje twoje koszty i szybkość odpowiedzi API. Zmieniliśmy te zasady na robocie. My od lat przenosimy wszystko, co się da, na lekkie kontenery linuksowe, zostawiając stare maszyny wirtualne z IIS tylko tam, gdzie zmusza nas do tego dług technologiczny.

Dlaczego w ogóle porównujemy Nginx i IIS w kontekście .NET?

Przez kilkanaście lat sprawa była prosta. Pisałeś kod w C#, pakowałeś go w biblioteki DLL, a potem wrzucałeś na serwer z systemem Windows i konfigurowałeś Internet Information Services (IIS). To było jedyne środowisko, które rozumiało ten język. Microsoft trzymał cały ekosystem pod kluczem. Kod był mocno związany z systemem operacyjnym.

Wszystko wywróciło się do góry nogami, gdy Microsoft wypuścił .NET Core (obecnie po prostu .NET od wersji 5 wzwyż). Przepisali silnik od zera. Narzucili nową filozofię. Wbudowali w framework własny, niesamowicie szybki wieloplatformowy serwer WWW o nazwie Kestrel. Kestrel potrafi bezpośrednio nasłuchiwać żądań HTTP. Ale sam Kestrel nie nadaje się do wystawienia go bezpośrednio do brutalnego internetu bez osłony. Potrzebuje serwera pośredniczącego, czyli reverse proxy. I tu na scenę wchodzi Nginx lub IIS. My decydujemy, co postawimy przed Kestrelem. Decyzja ta pociąga za sobą gigantyczne konsekwencje dla budżetu IT.

W zeszłym roku na wdrożeniu w firmie logistycznej próbowaliśmy przenieść starą paczkę z systemem magazynowym na Linuksa. Zawiesiło się uwierzytelnianie Active Directory, a moduły raportujące odwoływały się do rejestru Windows. Zostawiliśmy IIS przed weekendem. Po prostu się nie dało. To twardy dowód na to, że technologia nie zawsze poddaje się modzie na konteneryzację.

Kiedy IIS to jedyny racjonalny wybór dla aplikacji .NET?

Zacznijmy od technologii starszej, by mieć ją z głowy. IIS (Internet Information Services) to potężny kombajn wbudowany w systemy z rodziny Windows Server. Jeżeli twój zespół programistów nadal rozwija lub utrzymuje aplikację napisaną w starym .NET Framework (wersje 4.8 i niżej), nie masz absolutnie żadnego wyboru. Musisz użyć IIS. Linux nie uruchomi tego kodu bez karkołomnych i wadliwych protez typu projekt Mono. Zresztą prawda jest taka, że nikt przy zdrowych zmysłach nie stawia produkcji na Mono.

IIS ma głębokie powiązania z jądrem systemu Windows. To ułatwia życie korporacjom. Jeśli masz w firmie domenę Active Directory i chcesz, aby pracownicy logowali się do aplikacji intranetowej bez wpisywania haseł (Single Sign-On), IIS załatwia to dwoma kliknięciami w interfejsie graficznym za pomocą Windows Authentication. Nginx na Linuksie wymagałby zestawiania skomplikowanych mostów Kerberos, co przeważnie kończy się frustracją i błędami w logach.

Jakie konkretnie funkcje wymuszają pozostanie na Windows Server?

Istnieją cztery wyraźne sytuacje, w których instalacja IIS jest koniecznością biznesową i techniczną:

• Uwierzytelnianie zintegrowane z Windows (Windows Auth): Kiedy aplikacja B2B musi automatycznie rozpoznawać użytkowników zalogowanych do komputerów w biurze bez pytania ich o poświadczenia.
• Wykorzystanie starych bibliotek COM/DCOM: Wiele systemów księgowych i ERP napisanych dekadę temu opiera się na komponentach systemowych Windowsa, których Kestrel na Ubuntu zwyczajnie nie widzi.
• Technologie WCF (Windows Communication Foundation) i WebForms: Związane nierozerwalnie z pełnym .NET Frameworkiem. Nie da się ich przenieść na Kestrel bez przepisania tysięcy linii kodu na gRPC lub REST API.
• Brak kompetencji linuksowych w zespole: Jeżeli cały dział administracji od dwudziestu lat klika w okienka i zarządza serwerami przez RDP, wrzucenie im Nginxa w konsoli skończy się awarią przy pierwszym przedawnieniu certyfikatu SSL.

To jest bez mała najgorsza opcja z wszystkich z perspektywy nowoczesnego rozwoju, ale często narzuca ją proza życia. Zostajesz z tym, co znasz.

Dlaczego Nginx zyskał dominację przy hostowaniu ASP.NET Core?

Jeżeli tworzysz nowy projekt w najnowszym .NET (wersja 8 lub wyższa), Kestrel domyślnie odpala twoje API. Microsoft zoptymalizował Kestrela do granic możliwości. Bije on rekordy w testach TechEmpower. Ale Microsoft sam oficjalnie odradza wystawianie Kestrela jako serwera brzegowego (edge server) bez osłony. Kestrel świetnie radzi sobie z szybkim parsowaniem kodu, ale brakuje mu mechanizmów obronnych przed atakami DDoS, powolnymi klientami czy zaawansowanego cachowania.

Dlatego przed Kestrelem stawia się Nginx. Nginx to serwer napisany w C, stworzony do pracy pod gigantycznym obciążeniem. Działa jako reverse proxy. Przyjmuje uderzenie ruchu z zewnątrz, filtruje je, zarządza certyfikatami SSL i przekazuje czyste żądania HTTP do aplikacji .NET działającej w tle na porcie lokalnym (np. 5000). To tandem idealny.

(Szczerze mówiąc, nienawidzę utrzymywać maszyn z Windowsem. W zeszłym miesiącu Windows Server na produkcji zrestartował mi się o 3 nad ranem, bo uznał, że musi pilnie zainstalować łatkę bezpieczeństwa i zignorował reguły blokujące. Nginx na Ubuntu działa u nas bez restartu od ponad 400 dni. Stabilność pingwina w warstwie webowej to inna liga).

Jak fizycznie Nginx komunikuje się z Kestrel?

Mechanika jest prosta. Konfigurujesz plik tekstowy na Linuksie. Mówisz Nginxowi, żeby nasłuchiwał na porcie 80 i 443 (HTTP/HTTPS). Następnie tworzysz blok lokalizacji, który przekierowuje ten ruch na `http://localhost:5000`. Aplikacja .NET Core działa jako usługa systemowa (daemon) zarządzana przez `systemd`. Jeśli proces aplikacji z jakiegoś powodu zginie, `systemd` natychmiast go podnosi.

Ważne jest przekazywanie nagłówków. Ponieważ Nginx przejmuje żądanie, Kestrel myśli, że wszystkie zapytania pochodzą z adresu `127.0.0.1`. Aby aplikacja .NET widziała prawdziwe adresy IP użytkowników, Nginx musi doklejać nagłówki `X-Forwarded-For` oraz `X-Forwarded-Proto`. W kodzie C# dodajesz middleware `UseForwardedHeaders()`. I gotowe. Całość zamyka się w kilkunastu linijkach kodu i konfiguracji.

Nginx vs IIS – co wygrywa pod kątem wydajności i zużycia RAM?

Przejdźmy do twardych danych. Różnica w zużyciu zasobów to przepaść. Nginx został zaprojektowany z myślą o architekturze opartej na zdarzeniach (event-driven). Zjada na start około 50 megabajtów pamięci RAM i potrafi obsłużyć dziesiątki tysięcy jednoczesnych połączeń bez zauważalnego wzrostu apetytu na pamięć. Proces roboczy Nginxa jest niesamowicie lekki.

IIS działa w oparciu o pule aplikacji (Application Pools) i procesy robocze `w3wp.exe`. Pusta pula aplikacji w IIS potrafi zablokować na starcie od 100 do 200 megabajtów RAM. Jeśli hostujesz na jednym serwerze Windows dwadzieścia małych mikroserwisów, sam narzut pamięciowy IIS zje ci połowę dostępnych zasobów maszyny. Do tego dochodzi ciężar samego systemu Windows Server, który po uruchomieniu, z włączonym interfejsem graficznym, potrzebuje minimum 2-3 gigabajtów RAM, żeby w ogóle oddychać.

Ubuntu Server działający w trybie tekstowym z zainstalowanym Nginxem i jednym procesem aplikacji .NET zadowoli się maszyną wirtualną z 1 GB RAM. Zmniejszasz koszty infrastruktury chmurowej o ułamek. Płacisz mniej w AWS, Azure czy Google Cloud.

Jakie są koszty utrzymania serwerów WWW dla aplikacji .NET?

Pieniądze dyktują warunki na rynku IT. Wybór między Nginx a IIS to bezpośredni wybór między modelem Open Source a płatnym licencjonowaniem korporacyjnym.

Nginx w swojej podstawowej, potężnej wersji jest całkowicie darmowy. Instalujesz go na darmowej dystrybucji Linuksa (np. Ubuntu, Debian, AlmaLinux). Płacisz wyłącznie za fizyczną maszynę lub instancję chmurową. Jeśli potrzebujesz wsparcia technicznego i zaawansowanych paneli, możesz kupić Nginx Plus, ale w zdecydowanej większości przypadków zwykły, darmowy Nginx zaspokaja 100% potrzeb firm.

IIS jest wbudowany w Windows Server. A licencje na Windows Server są drogie. Płacisz za rdzenie procesora (Core-based licensing). Każda kolejna maszyna wirtualna z Windowsem to dodatkowy koszt w arkuszu kalkulacyjnym. Jeśli zamierzasz skalować aplikację poziomo i postawić dziesięć serwerów WWW za load balancerem, koszt licencji Microsoftu szybko przewyższy koszty pracy programistów utrzymujących ten system.

Czy darmowy IIS na Windows 10 nadaje się na produkcję?

Absolutnie nie. Microsoft sztucznie i celowo ogranicza możliwości IIS w klienckich wersjach systemu Windows. W Windows 10 lub 11 IIS ma nałożony twardy limit jednoczesnych połączeń (zazwyczaj 10). Służy on wyłącznie programistom do lokalnego testowania kodu. Wystawienie tego na zewnątrz spowoduje, że po wejściu kilku użytkowników serwer zacznie odrzucać kolejne żądania. Musisz kupić Windows Server. Z Nginxem nie ma tego problemu – wersja na deweloperskim laptopie z Linuksem ma te same limity co wersja na serwerze produkcyjnym (czyli ogranicza ją tylko sprzęt).

Konteneryzacja i Docker – który serwer WWW pasuje tu lepiej?

Branża przeszła na architekturę mikroserwisów. Pakujemy aplikacje w kontenery Dockerowe i orkiestrujemy je za pomocą Kubernetes. W tym świecie IIS wygląda jak dinozaur.

Kontenery linuksowe z .NET i Nginxem ważą ułamek tego, co obrazy oparte na Windowsie. Typowy obraz kontenera z aplikacją ASP.NET Core oparty na Alpine Linux ma rozmiar rzędu 100-150 megabajtów. Pobiera się w kilka sekund. Skaluje się błyskawicznie. Nginx działa w kontenerach natywnie, jako mały, jednorazowy proces.

Kontenery Windows z zainstalowanym IIS (oparte na Windows Server Core) potrafią ważyć po kilka gigabajtów. Samo pobranie obrazu na nowy węzeł w klastrze trwa minuty. Uruchamianie kontenera z IIS jest powolne. W środowiskach chmurowych, gdzie kontenery żyją krótko i muszą szybko reagować na skoki ruchu, ciężar Windowsa dyskwalifikuje go z gry. Dlatego nawet sam Microsoft promuje uruchamianie .NET Core na Linuksie w swoich oficjalnych poradnikach dotyczących Dockera.

Bezpieczeństwo i zarządzanie certyfikatami – Nginx czy IIS?

Bezpieczeństwo ruchu w sieci opiera się dzisiaj na szyfrowaniu SSL/TLS. Wystawianie nieszyfrowanych portów 80 to błąd w sztuce. Zarządzanie certyfikatami to codzienna praca administratorów.

Nginx ma tu gigantyczną przewagę dzięki społeczności Open Source. Darmowe certyfikaty od Let’s Encrypt można zautomatyzować na Linuksie za pomocą narzędzia Certbot. Instalujesz demona, wykonujesz jedną komendę `certbot –nginx`, a skrypt sam modyfikuje plik konfiguracyjny, pobiera certyfikat i ustawia zadanie w systemie `cron`, które odnawia certyfikat co 60 dni. Zapominasz o problemie na zawsze.

W IIS obsługa darmowych certyfikatów Let’s Encrypt wymaga zewnętrznych narzędzi (np. Win-ACME lub Posh-ACME). Działają one dobrze, ale ich integracja z graficznym menedżerem IIS bywa kapryśna. Co gorsza, konfiguracja szyfrowania w IIS, wyłączanie starych protokołów (jak TLS 1.0 czy 1.1) i ustawianie bezpiecznych szyfrów (cipher suites) wymaga edytowania kluczy w rejestrze Windows lub używania zewnętrznych programów typu IIS Crypto. W Nginx robisz to dodając po prostu dwie linijki tekstu do pliku `nginx.conf`.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku, że Microsoft w końcu przepisze interfejs zarządzania SSL w Windows Server. Na razie jednak tkwią w architekturze z 2012 roku. Zmieniliśmy te zasady na robocie i po prostu wpinamy ruch przez Nginxa lub Cloudflare, zdejmując problem z Windowsa.

Wdrażanie zmian i ciagła integracja (CI/CD)

Zespoły programistyczne wypuszczają nowe wersje aplikacji codziennie. Procesy CI/CD (Continuous Integration / Continuous Deployment) wymagają narzędzi, które nie rzucają kłód pod nogi.

Podczas wdrażania nowej wersji aplikacji na IIS, często napotykasz problem zablokowanych plików (File locking). Ponieważ `w3wp.exe` trzyma biblioteki DLL w pamięci, próba ich nadpisania w trakcie działania aplikacji kończy się błędem „Plik jest używany przez inny proces”. Musisz skryptem zatrzymać pulę aplikacji, podmienić pliki i uruchomić ją ponownie. To powoduje przerwę w dostępie dla użytkowników (downtime).

Na Linuksie, przy użyciu Nginxa i Kestrela, pliki nie są rygorystycznie blokowane w systemie plików w taki sam sposób. Wdrażanie w modelu Blue/Green deployment jest trywialne. Uruchamiasz nową wersję aplikacji na innym porcie (np. 5001), a potem w ułamku sekundy każesz Nginxowi przeładować konfigurację (`nginx -s reload`). Nginx płynnie kończy obsługiwać stary ruch na starym procesie i kieruje nowe żądania na nowy port. Zero przerw w dostępie. Zero zablokowanych plików.

Krótkie pytania i odpowiedzi (FAQ)

• Czy mogę uruchomić ASP.NET Core bezpośrednio na Kestrel bez Nginx?
  Tak, technologicznie to możliwe i wspierane od .NET Core 2.1, jednak Microsoft zaleca wystawianie Kestrela bezpośrednio do internetu tylko w specyficznych, dobrze chronionych środowiskach wewnętrznych. Nginx dodaje niezbędną warstwę bezpieczeństwa i zarządzania obciążeniem.
• Co jest szybsze: Nginx czy IIS dla aplikacji C#?
  W testach syntetycznych Kestrel ukryty za Nginxem na systemie Linux osiąga wyższą przepustowość i mniejsze opóźnienia niż aplikacja hostowana w procesie na serwerze IIS. Nginx zużywa też znacznie mniej pamięci RAM.
• Czy muszę znać Linuksa, żeby używać Nginx z .NET?
  Tak. Utrzymanie Nginxa wymaga podstawowej znajomości terminala Linux, edycji plików konfiguracyjnych i zarządzania usługami systemowymi przez systemd.
• Jak przenieść starą aplikację z IIS na Nginx?
  Aplikacji napisanych w starym .NET Framework (np. WebForms) nie da się bezpośrednio przenieść. Musisz najpierw przepisać kod do nowoczesnego .NET (wcześniej .NET Core), usunąć zależności od Windows, a dopiero potem hostować na Linuksie z Nginxem.
• Czy Nginx jest całkowicie darmowy?
  Tak, Nginx Open Source jest darmowy i wystarcza do większości zastosowań produkcyjnych. Istnieje płatna wersja Nginx Plus oferująca dodatkowe panele analityczne i wsparcie techniczne.
• Dlaczego IIS blokuje pliki podczas aktualizacji aplikacji?
  Wynika to z architektury systemu Windows i sposobu, w jaki serwer IIS ładuje biblioteki DLL do pamięci procesu roboczego. Aby nadpisać pliki, należy zatrzymać pulę aplikacji lub użyć mechanizmu App_Offline.htm.

Odpal terminal. Zainstaluj Ubuntu na tanim VPS-ie. Skonfiguruj Nginxa i wrzuć tam swoje pierwsze API w .NET 8. Sam zobaczysz, jak szybko i lekko to działa, bez ciężaru okienek i licencji liczących rdzenie twojego procesora. Jeżeli twój biznes nie jest uwiązany starymi systemami ERP w piwnicy, nie masz żadnej technicznej wymówki, żeby nadal płacić haracz za serwery z Windowsem. Wybierz wolność i wydajność.

Bibliografia

1. Microsoft – https://microsoft.com
2. NGINX – https://nginx.org
3. Canonical (Ubuntu) – https://ubuntu.com
4. Stack Overflow – https://stackoverflow.com
5. TechEmpower – https://techempower.com