Nginx

Nginx hat zwei Jobs:

1. Webserver: "Hier ist die index.html. Tschüss." (Statische Dateien).
2. Reverse Proxy: "Ah, du willst in den Shop? Ich leite dich weiter an den Shop-Server (Node.js), der hinter mir steht." Er schützt die Server dahinter und macht SSL-Verschlüsselung (das grüne Schloss).

Praxisbeispiel: Browser -> Nginx -> Backend. Nginx kann statische Dateien direkt ausliefern, TLS beenden und /api an eine Anwendung weiterreichen.

Praxisroutine

In der Praxis lernst du Nginx, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. C10k Problem

In den 90ern stürzten Server ab, wenn 10.000 (10k) Leute gleichzeitig kamen (Apache Problem). Jeder User brauchte einen eigenen Prozess (viel RAM). Nginx wurde erfunden, um das zu lösen. Es ist Event-Driven (Asynchron). Ein einziger Prozess bedient alle 10.000 User nacheinander in Millisekunden-Taktung. Extrem effizient.

2. Config File

Die Konfiguration (nginx.conf) ist mächtig. Du kannst Regeln bauen: "Blockiere alle Hacker aus China." "Komprimiere alle Bilder, bevor du sie sendest." "Wenn Server A kaputt ist, nimm Server B."

Technisch arbeitet Nginx als Webserver, Reverse Proxy und Load Balancer. Gute Konfiguration regelt Timeouts, Header, TLS, Weiterleitungen und maximale Request-Größen.

1. Asynchronous Non-Blocking Engine (Worker Model)

Warum Apache (Prefork) bei 10.000 Usern crashte: Er öffnete einen eigenen OS-Thread (3MB RAM) pro Verbindung. 10.000 x 3MB = 30 Gigabyte RAM, das Serverboard schmolz. Nginx nutzt die Event Loop (epoll in Linux). Ein Master-Prozess generiert wenige Worker-Prozesse (ideal: ein Worker pro CPU-Kern). Ein Worker wartet asynchron. Fragt User A ein 5MB Bild an, fädelt der Worker den Festplatten-Read an den OS-Kernel ein und dreht sich sofort weg. Er bedient User B. Meldet der Kernel "Bild ist geladen", wacht der File-Descriptor im Event-Loop auf und Nginx streamt die Datei los. Ein einziger 50MB Worker-Thread hält so hunderte parallele Keep-Alive-Sockets im Zustand ESTABLISHED, ohne auch nur eine CPU-Wait-Cycel zu blockieren.

2. Zero Copy (sendfile)

Wenn du ein statisches Image auslieferst, kostet das normalerweise irre viel CPU: Die Festplatte liest es ins Kernel-RAM, der Kernel kopiert es ins User-RAM (zu Nginx), Nginx formatiert es, und kopiert es zurück in den Kernel-Socket Puffer, von wo es die Netzwerkkarte versendet. Nginx macht sich die Linux-Option sendfile on; zunutze. Nginx bittet den Kernel: "Ich brauch hier nicht mitschauen. Nimm /var/www/logo.png und drücke es als rohen Bitstream direkt vom Festplatten-Controller in die Netzwerk-Hardware durch." Der User-Space von Nginx wird physikalisch übersprungen (Zero Copy). Die CPU-Auslastung bei statischen Files sinkt von 80% auf nahe 0%.

3. Load Balancing & Hashing

Neben Static-Hosting ist Nginx der mächtigste Reverse-Proxy. Nutzt du upstream { server node1; server node2; }, balanced Nginx standardmäßig Round-Robin. Für zustandsbehaftete Services (Session Tokens im RAM von Node 1) reicht das nicht. Hier nutzt du Consistent Hashing: ip_hash;. Nginx nimmt die IPv4 (192.168.1.5), hasht sie als String und verteilt sie strikt deterministisch. Der User landet heute, morgen und in 3 Jahren zwingend auf Server 1 (Sticky Session). Bei Skalierung (Server 3 dazu) wird die Ring-Theorie geformt, dass nur 33% der User umziehen müssen.