nginx(Das Programm, das deine Website ausliefert)

Willkommen beim Marketing Techie Podcast, dem Podcast über die Technik hinter dem Online-Marketing. Verständlich erklärt, auch für Non-Techies. Mit Emilian Buza von trace5.co. In dieser Folge: nginx. Das Programm, das deine Website ausliefert.

Wie viel kann ein Programm wert sein, das ein Systemadministrator nebenbei, in seiner Freizeit geschrieben hat? 670 Millionen Dollar. Und eine Hausdurchsuchung. Aber der Reihe nach.

Anfang der 2000er arbeitete ein Russe namens Igor Sysoev als Systemadministrator bei Rambler, damals eines der größten Internetportale Russlands. 2002 begann er, ein eigenes Programm zu entwickeln. Ein Programm, das Websites ausliefert, also die Anfragen der Browser entgegennimmt und die passenden Seiten zurückschickt. Nach eigener Aussage tat er das in seiner Freizeit. Er nannte es nginx. Gesprochen: Engine X.

Und dieses Programm wurde ein Riesenerfolg. 2011 gründete Sysoev mit einem Partner, Maxim Konovalov, eine eigene Firma darum herum. Und 2019 kaufte das amerikanische Unternehmen F5 diese Firma. Für 670 Millionen Dollar. Bis dahin eine klassische Erfolgsgeschichte. Doch dann kam der 12. Dezember 2019.

An diesem Donnerstag durchsuchte die russische Polizei das Moskauer Büro von nginx. Und auch die Wohnungen der beiden Gründer. Sysoev und Konovalov wurden stundenlang befragt. Die Welt erfuhr davon zuerst über einen Tweet eines Mitarbeiters.

Der Grund? Eine Anzeige. Eingereicht von einer Firma aus Zypern, die mit einem Miteigentümer von Rambler verbunden war. Der Vorwurf: Sysoev habe nginx als Angestellter von Rambler entwickelt. Deshalb gehöre das Programm eigentlich Rambler. Den Schaden bezifferte man auf über 51 Millionen Rubel. Nach damaligem Kurs rund 740.000 Euro.

Siebzehn Jahre, nachdem Sysoev die erste Zeile geschrieben hatte. Und wenige Monate nach dem Verkauf für 670 Millionen.

Konovalov nannte das Ganze öffentlich dumm und schlichte Schutzgelderpressung. Und sogar Ramblers früherer Chef bezeichnete die Vorwürfe als Unsinn: Sysoev sei bei Rambler nie damit beauftragt gewesen, einen Webserver zu entwickeln.

Vier Tage nach der Razzia ruderte Rambler zurück. Der Vorstand bat die Behörden, das Strafverfahren einzustellen, trennte sich von der Firma aus Zypern und kündigte an, den Streit stattdessen vor einem Zivilgericht auszutragen.

Doch warum war dieses Programm so viel wert, dass sich jemand nach siebzehn Jahren darum streiten wollte? Weil damals fast eine halbe Milliarde Websites damit liefen.

Auch heute noch ist nginx einer der wichtigsten Webserver der Welt. Laut dem Analyseunternehmen Netcraft läuft er auf rund 40 Prozent aller Computer, die im Netz Websites ausliefern.

Und unter den Websites, die damit laufen, sind wahrscheinlich auch einige, die du jeden Tag besuchst. Vielleicht sogar deine eigene.

Und weil nginx so bedeutend ist, klären wir heute, was es eigentlich ist. Was so ein Webserver macht. Und warum du als Marketer diesen Namen kennen solltest. Fangen wir mit einem Wort an, das du aus Folge 2 kennst: Server.

In Folge 2 haben wir gesagt: Ein Server ist ein Computer, der Anfragen beantwortet. Der Browser schickt eine Anfrage, der Server schickt eine Antwort.

Das stimmt. Aber es fehlt ein Detail. Denn auf diesem Computer muss ein Programm laufen, das diese Anfragen überhaupt entgegennimmt. Ein Programm, das darauf wartet, dass ein Browser etwas will. Das nachschaut, was genau gewünscht ist. Und das die passende Antwort zurückschickt. So ein Programm nennt man Webserver.

Und jetzt wird’s ein bisschen verwirrend, das gebe ich zu. Denn mit „Server“ meint man im Alltag beides: den Computer und das Programm, das darauf läuft. Wenn jemand sagt „Der Server ist down“, kann der Computer gemeint sein. Oder eben dieses Programm. nginx ist so ein Programm. Ein Webserver.

Und nginx war nicht der erste. Lange bevor es nginx gab, lief ein Großteil des Webs mit einem anderen Webserver namens Apache. Den gibt es seit Mitte der Neunziger, und es gibt ihn bis heute. Warum hat Igor Sysoev dann überhaupt einen neuen geschrieben? Weil das Web Anfang der 2000er ein Problem bekam.

Stell dir eine große Website vor. Ein Portal wie Rambler. Tausende Menschen rufen gleichzeitig Seiten auf. Und jeder dieser Besucher hält eine Verbindung zum Server offen, solange seine Seite übertragen wird.

Bei schnellen Verbindungen dauert das einen Wimpernschlag. Aber damals waren viele Menschen noch mit Modems unterwegs. Und eine langsame Verbindung bleibt eben lange offen. Der Server muss also sehr viele Verbindungen gleichzeitig betreuen, von denen die meisten gerade nur darauf warten, dass die nächsten Daten durchgehen. Und genau da hatte die klassische Arbeitsweise ein Problem.

Vereinfacht gesagt: Der Webserver hat für jede einzelne Verbindung einen eigenen Arbeitsablauf gestartet. Einen eigenen Prozess oder einen eigenen sogenannten Thread. Und jeder davon kümmert sich ausschließlich um seine eine Verbindung. Auch dann, wenn diese Verbindung gerade gar nichts tut.

Jeder dieser Abläufe braucht Arbeitsspeicher. Bei hundert Besuchern ist das kein Problem. Aber bei zehntausend gleichzeitigen Verbindungen geht dem Server irgendwann schlicht der Speicher aus.

Für dieses Problem gab es Ende der Neunziger sogar einen eigenen Namen: das C10K-Problem. C steht für Connections, also Verbindungen. Und 10K für zehntausend. Die Frage war: Wie schafft ein einziger Server zehntausend Verbindungen gleichzeitig?

Sysoevs Antwort war nginx. Und die Idee dahinter ist eine andere Arbeitsweise.

nginx startet nicht für jede Verbindung einen eigenen Ablauf. Sondern nur ein paar wenige, meistens so viele, wie der Computer Prozessorkerne hat. Und jeder dieser wenigen Abläufe betreut tausende Verbindungen gleichzeitig.

Wie geht das? Indem er nie auf eine einzelne Verbindung wartet. Er schaut ständig nach, bei welcher Verbindung gerade etwas zu tun ist. Ist bei einer Verbindung eine neue Anfrage angekommen, bearbeitet er sie. Sind bei einer anderen gerade Daten zum Verschicken fertig, schickt er sie los. Und alle Verbindungen, bei denen gerade nichts passiert, kosten ihn so gut wie nichts.

Das nennt man eine ereignisgesteuerte Arbeitsweise. nginx reagiert auf Ereignisse, statt zu warten.

Das Ergebnis: Auf derselben Hardware schafft nginx deutlich mehr gleichzeitige Besucher als die klassische Arbeitsweise. Und braucht dabei viel weniger Arbeitsspeicher.

Genau deshalb haben große Websites nginx so schnell übernommen. Und genau deshalb gehört nginx laut den gängigen Statistiken seit Jahren zu den meistgenutzten Webservern der Welt.

Zur Fairness: Apache hat inzwischen ebenfalls Arbeitsweisen bekommen, die mit vielen Verbindungen besser umgehen. Aber nginx war mit diesem Ansatz von Anfang an gebaut. Und hat dadurch seinen Ruf bekommen.

So. Jetzt weißt du, warum nginx entstanden ist. Aber was macht nginx heute eigentlich auf einer Website?

Da gibt es vor allem vier Aufgaben. Und die solltest du kennen, weil sie dich als Marketer direkt betreffen.

Die erste Aufgabe: Dateien ausliefern. Bilder, Schriftarten, CSS-Dateien, JavaScript-Dateien. Alles, was einfach so auf dem Server liegt und bei jedem Besucher gleich ist. Darin ist nginx extrem schnell.

Die zweite Aufgabe, und die ist heute die wichtigste: Vor einer Anwendung stehen.

Nehmen wir WordPress. WordPress ist kein Webserver. WordPress ist ein Programm, geschrieben in der Programmiersprache PHP. Es baut deine Seiten zusammen, holt Inhalte aus der Datenbank, kümmert sich um dein Kontaktformular.

Aber WordPress nimmt selbst keine Anfragen aus dem Internet entgegen. Das macht nginx.

Der Ablauf sieht dann so aus: Der Browser deines Besuchers schickt seine Anfrage an nginx. nginx schaut sich an, was gewünscht ist. Ist es ein Bild, liefert nginx es direkt selbst aus. Ist es eine Seite, die WordPress erst zusammenbauen muss, dann reicht nginx die Anfrage an WordPress weiter. WordPress baut die Seite und gibt sie an nginx zurück. Und nginx schickt sie an den Browser.

Der Besucher bekommt davon nichts mit. Für ihn gibt es nur eine einzige Adresse, deinshop.de. Dass dahinter zwei Programme zusammenarbeiten, sieht er nicht.

Wenn ein Webserver so vor einer Anwendung steht und Anfragen an sie weiterreicht, nennt man ihn einen Reverse Proxy. Den Begriff hörst du in Gesprächen mit Entwicklern öfter, deshalb lohnt es sich, ihn einmal gehört zu haben.

Und nginx kann Anfragen nicht nur an eine Anwendung weiterreichen, sondern auch auf mehrere verteilen. Erinnerst du dich an die Cloud-Folge, an den Black Friday mit zusätzlichen Servern? Irgendjemand muss die Besucher ja auf diese Server verteilen. Das kann zum Beispiel nginx übernehmen. In dieser Rolle nennt man ihn Load Balancer, also Lastverteiler.

Die dritte Aufgabe: HTTPS. Also die Verschlüsselung zwischen Browser und Server, die du am Schloss in der Adresszeile erkennst. Das Zertifikat dafür liegt sehr oft bei nginx. nginx verschlüsselt und entschlüsselt die Verbindung, und die Anwendung dahinter muss sich darum gar nicht kümmern.

Und die vierte Aufgabe: Weiterleitungen. Wenn jemand eine alte Adresse aufruft und automatisch auf die neue geschickt wird, dann steckt dahinter oft eine Regel in nginx.

Und damit sind wir bei den Stellen, an denen nginx dir als Marketer im Alltag begegnet. Auch wenn du den Namen bisher vielleicht gar nicht wahrgenommen hast.

Fangen wir mit einer Fehlermeldung an, die du garantiert schon gesehen hast. Oder sagen wir besser: die du sehr wahrscheinlich schon gesehen hast. Eine weiße Seite. Darauf steht „502 Bad Gateway“. Und darunter ganz klein: nginx. Was heißt das?

Erinnere dich an den Ablauf von eben. Browser, nginx, Anwendung. Eine 502 heißt: nginx läuft. nginx hat die Anfrage angenommen und an die Anwendung dahinter weitergereicht. Aber von dieser Anwendung kam keine brauchbare Antwort zurück.

Der Fehler liegt also meistens nicht bei nginx. Sondern dahinter. Bei WordPress, beim Shop-System, bei der Anwendung, die die Seite eigentlich bauen soll.

Und es gibt noch eine Verwandte: 504 Gateway Timeout. Da hat nginx auf die Antwort der Anwendung gewartet. Und gewartet. Und irgendwann aufgegeben, weil es zu lange gedauert hat.

Warum ist das für dich wichtig? Weil du damit der Technik sofort einen Hinweis geben kannst. Wenn deine Landingpage mitten in einer Kampagne „502 Bad Gateway“ zeigt, dann ist nicht der Server komplett weg. Dann hängt die Anwendung dahinter. Und genau dort muss man suchen.

Zweitens: Weiterleitungen und SEO. Bei einem Relaunch oder einer Umstellung auf neue Adressen sind Weiterleitungen entscheidend. Und die können an verschiedenen Stellen eingerichtet sein. In nginx. Oder in der Anwendung, zum Beispiel über ein WordPress-Plugin.

Das klingt nach einem technischen Detail. Aber es hat Folgen. Eine Weiterleitung in nginx wird erledigt, bevor WordPress überhaupt anfängt zu arbeiten. Das ist schnell. Eine Weiterleitung über ein Plugin dagegen startet erst WordPress und leitet dann weiter.

Und wenn an beiden Stellen Regeln liegen, die sich gegenseitig nicht kennen, entstehen schnell Ketten: Die alte Adresse leitet auf eine Zwischenadresse, die wieder weiterleitet, und erst dann kommt die richtige Seite. Das kostet Ladezeit. Und es macht Suchmaschinen das Leben schwerer.

Deshalb lohnt sich die Frage: Wo sind bei uns die Weiterleitungen eigentlich eingerichtet? An einer Stelle oder an mehreren?

Drittens: Ladezeit. nginx kann Dateien komprimieren, bevor es sie verschickt. Dann gehen weniger Daten über die Leitung, und die Seite ist schneller da. Und nginx kann dem Browser mitteilen, wie lange er Bilder und andere Dateien bei sich zwischenspeichern darf. Dann muss ein wiederkehrender Besucher sie gar nicht erst neu laden.

Beides ist eine Einstellung in nginx. Und beides wirkt sich direkt darauf aus, wie schnell deine Landingpages laden. Und damit auch auf deine Kampagnen.

Viertens: Logdateien. Erinnerst du dich an Folge 4? An Urchin, das ursprünglich nur die Logdateien von Servern ausgewertet hat? Genau solche Logdateien schreibt auch nginx. Jede Anfrage, die ankommt, landet dort mit Uhrzeit, Adresse, Statuscode, User-Agent und IP-Adresse.

Für dich kann das richtig wertvoll sein. In diesen Logdateien siehst du zum Beispiel, wie oft der Googlebot deine Seiten besucht. Welche Adressen ständig einen 404-Fehler erzeugen. Oder ob plötzlich massenhaft Bots auf deine Landingpage einprasseln. Und das alles unabhängig davon, ob im Browser ein Tracking-Skript läuft oder ein Cookie-Banner abgelehnt wurde.

Aber Achtung: In diesen Logdateien stehen auch IP-Adressen. Wie lange sie aufbewahrt werden und wer sie auswerten darf, ist deshalb auch eine Frage für deinen Datenschutz.

Und fünftens: Server-Side Tracking. In Folge 4 haben wir besprochen, dass der Browser beim Server-Side Tracking seine Daten erst an deinen eigenen Server schickt. Dafür braucht dieser Server eine Adresse unter deiner Domain, zum Beispiel eine eigene Subdomain. Und es gibt Setups, in denen nginx dabei mitspielt: Er nimmt Anfragen an einen bestimmten Pfad deiner Website entgegen und reicht sie an den Tagging-Server weiter. Genau wie bei WordPress, nur dass dahinter diesmal dein Tracking sitzt.

So. Das waren ziemlich viele Stellen, an denen dir ein Programm begegnet, das du vielleicht nie bewusst wahrgenommen hast.

Und wenn du nach dieser Folge eine Sache konkret machen willst, dann diese. Frag deine Entwicklung oder deinen Hoster vier Dinge.

Erstens: Welcher Webserver läuft bei uns? nginx, Apache oder etwas anderes?

Zweitens: Wo sind unsere Weiterleitungen eingerichtet? Im Webserver, in der Anwendung oder an beiden Stellen?

Drittens: Gibt es Logdateien, wie lange werden sie aufbewahrt, und kann ich die Auswertung für Googlebot und 404-Fehler bekommen?

Und viertens: Wer bekommt Bescheid, wenn unsere Seite einen 502 oder 504 zeigt?

Die Antworten passen auf eine halbe Seite. Aber danach weißt du, wo bei einem Problem zu suchen ist. Und du redest mit deiner Technik in ihrer Sprache.

Und falls du diese Dinge einmal selbst sehen willst: In meinem Kurs „Was passiert im Browser?“ lernst du, in den Entwicklertools deines Browsers die Antworten eines Servers zu lesen.

Den Statuscode, also ob da eine 200, eine 301 oder eine 502 zurückkommt. Weiterleitungen, Schritt für Schritt, inklusive aller Zwischenstationen. Und bei vielen Websites sogar, welcher Webserver dahinter antwortet, denn viele verraten das ganz offen mit der Angabe „Server: nginx“. Den Link findest du in den Shownotes.

Ok, ich weiß, das war jetzt eine Menge Zeug. Fassen wir darum noch einmal zusammen, was du jetzt weißt.

Du hat in dieser Folge erfahren, dass nginx ein Webserver ist. Also das Programm, das auf einem Server die Anfragen der Browser entgegennimmt und Antworten zurückschickt. Entstanden ist es, weil die klassische Arbeitsweise bei sehr vielen gleichzeitigen Verbindungen an ihre Grenzen kam. nginx betreut mit wenigen Abläufen tausende Verbindungen gleichzeitig und reagiert nur dort, wo gerade etwas zu tun ist.

Heute liefert nginx Dateien aus, steht als Reverse Proxy vor Anwendungen wie WordPress, verteilt Besucher auf mehrere Server, kümmert sich um HTTPS und um Weiterleitungen. Und genau deshalb begegnet er dir bei 502-Fehlern, bei Weiterleitungen, bei der Ladezeit, in den Logdateien und beim Server-Side Tracking.

Ein Programm, das ein Systemadministrator in seiner Freizeit angefangen hat. 670 Millionen Dollar wert. Und wahrscheinlich gerade in diesem Moment dabei, die Seiten auszuliefern, die deine Kampagnen bewerben. So, und das war’s auch schon wieder für heute. Hab einen schönen Tag und bis zur nächsten Folge.