Im Internet gibt es für alles und jeden Statistiken, auch für die Marktanteile der eingesetzten Webserver. Jedoch solltest du diese mit extremer Vorsicht genießen. Denn wo „Cloudflare“ dransteht, ist nur ganz am Ende der Kette Cloudflare drin – und das macht die Statistiken beinahe nutzlos.
Sterben Apache und nginx aus?
Wenn du dir die Marktanteile von Webservern über die Zeit anschaust und kurz Google bemühst, landest du wahrscheinlich bei Webseiten wie W3Techs. Dort gibt es aktuelle Zahlen und sogar ein Verlaufsdiagramm über die Zeit. Es fällt nicht schwer, aus dem Diagramm herauszulesen, dass Apache und nginx zwar noch weit oben stehen, aber dass „Cloudflare Server“ offenbar drauf und dran ist, Marktanteile wie Pac-Man aufzufressen.
Aber das ist nur die halbe Wahrheit. Was die Statistik verschweigt (fairerweise: weil sie es von außen oft nicht besser wissen kann), ist die Tatsache, dass Cloudflare gar kein „echter“ Webserver im klassischen Sinne des Hostings ist. Tatsächlich ist es nur das Ende der Kette und hat zunächst nichts damit zu tun, was eine Webseite tatsächlich auf ihrem Origin-Server installiert hat.
Wie kommen die Statistiken zusammen?
Die Statistiken werden meist simpel erhoben, indem ein Bot eine Webseite aufruft (Crawling). Dabei werden allerlei Header-Daten ausgetauscht. Einer davon ist üblicherweise der Server-Header, bei dem sich die Software zu erkennen gibt. Das ist also so etwas wie:
Server: Apache/2.4.58Server: nginx
Je nach Konfiguration ist das Ganze noch gewürzt mit der Versionsnummer und/oder den geladenen Modulen (was man aus Sicherheitsgründen übrigens abschalten sollte, Stichwort ServerTokens Prod). Der Inhalt dieses Headers landet in einer Datenbank – voilà: Statistik.
Was uns diese Zahlen nicht sagen
Mit einiger Wahrscheinlichkeit sicher sein können wir uns höchstens bei den Daten von „nackten“ Webservern, die direkt am Netz hängen. Allerdings können wir wegen Cloudflare (und ehrlicherweise ähnlichen Stunts, die sich mit nginx und anderen Loadbalancern veranstalten lassen) nicht sicher sein, was genau die Zahlen bedeuten.
- Sinkt die Beliebtheit von IIS wirklich, oder verstecken sich immer mehr Windows-Admins nur hinter der Cloudflare-WAF?
- Wollen Apache-Admins nur an HTTP/3 kommen, ohne den Server zu wechseln, und schalten deshalb den orangen Proxy davor?
- Und natürlich: Knabbert Cloudflare auch am Marktanteil von nginx, oder sehen wir die Software bloß nicht mehr, weil sie jetzt in der zweiten Reihe steht?
Die Antwort ist: Wir wissen es nicht. Der Origin-Server ist eine Blackbox.
Was uns diese Zahlen aber sagen
Das Einzige, was uns diese Zahlen mit ziemlicher Sicherheit sagen können, ist etwas über die Infrastruktur-Abhängigkeit: Wenn Cloudflare eine vollständige Downtime erlebt – wie das in der Vergangenheit durchaus schon vorkam –, dann ist buchstäblich ein Viertel des Internets auf einen Schlag down. Wie bei einem globalen Stromausfall.
Denn dass sich ein Server als cloudflare meldet, bedeutet, dass letztendlich die CF-Infrastruktur den Request ausliefert. Im Falle einer Downtime … dann eben nicht mehr.
Wie ist das technisch möglich?
Die Antwort ist simpel und heißt Reverse Proxy. Das bedeutet, dass eine Instanz, z. B. der Cloudflare-Edge-Server, „intern“ den echten Webserver (Origin) um den Request bittet. Der echte Webserver gibt die Antwort an Cloudflare und Cloudflare liefert die Antwort an dich aus.
Da Cloud-Dienste ihre Server überall auf der Welt haben (Anycast), ergibt sich daraus ein Performance-Vorteil für den Client (Latenz). Da zwischen echtem Server und Cloudflare meist stabile Peerings bestehen, sind die Nachteile von TCP auf dem Weg zum Reverse Proxy zu vernachlässigen. Cloudflare nimmt die Daten, verschlüsselt sie neu per SSL und liefert sie via HTTP/3 aus.
Dabei passiert der Statistik-Mord: Cloudflare überschreibt den Server-Header gnadenlos mit sich selbst.
Docker & Co: Der Hausgebrauch
So etwas Ähnliches bekommt man auch „für den Hausgebrauch“ hin, etwa, wenn du nicht auf die .htaccess vom Apache verzichten möchtest, aber dennoch modernes HTTP/3 oder sauberes Caching verwenden willst. In dem Fall könntest du nginx einfach als Terminator (Frontend) laufen lassen, der sich um SSL und die Übertragung zum Client kümmert, während die Logik vom Apache kommt. Das ist in Docker-Setups absolut üblich (nginx-proxy container etc.).
Auch hier würde ein Bot von außen nur „nginx“ sehen, obwohl die eigentliche Arbeit vielleicht von einem Apache, einem Node.js-Prozess oder einem Python-Skript erledigt wird.
Performance-Puristen und jene, die keine Kunden auf ihren Servern haben, würden diesen Zwischenschritt vielleicht überspringen („Ein Webserver für alles“). Denn auch wenn die Performance-Einbußen (Overhead) sehr gering sind, sind sie vorhanden – und in jedem Fall ist es ein Puzzleteil mehr im Stack, das kaputtgehen kann und dann debuggt werden will.
Fazit: Die Statistik ist ein Blindflug
Ich sage nicht, dass es keine legitimen Anwendungsfälle für Cloudflare oder nginx als Reverse Proxy gibt. Allerdings ist die „gute, alte Zeit“ vorbei, in der man dem Header des Servers glauben und daraus saubere Marktanteile ableiten konnte.
Wer tatsächlich im Hintergrund die PHP-Skripte parst oder die HTML-Dateien ausliefert, kann von außen niemand mehr mit Sicherheit sagen. Insofern: Wenn jemand sagt, dein Lieblingsserver sei tot oder auf dem absteigenden Ast, nur weil eine Kurve nach unten zeigt: Sichere Beweise gibt es dafür nicht.