kleiner Werbserver

andy_m4

Admiral
Registriert
Aug. 2015
Beiträge
8.699
Ich suche einen kleinen, stabilen und zuverlässigen Webserver für statische Seiten.
Die Betonung liegt auf klein. Ich will also nicht unbedingt zu Lösungen wie nginx oder Apache greifen.

Ich hab' auch schon ein paar Kandidaten ins Auge gefasst:
Vielleicht hat ja einer von euch noch andere Ideen oder Hinweise a-la "nimm xyz nicht, wegen ...".
 
Lösung
Ich würde nginx auch eher als leicht bezeichnen und dieser ist absolut ausgereift und man lernt was auch für eventuell komplexere Fälle, falls diese mal anstehen :)

Statische Seite hosten ist auch einfach, nginx installieren, server block aus der default config anpassen, restart nginx, fertig. Optional UFW entsprechend anpassen und Letsencrypt Cert hinzufügen, auch jeweils in ca. zwei Zeilen erledigt.
Libmicrohttpd, wenn du basteln willst
Tiny_httpd, wenn es minimum an komfort sein soll

Ich habe beide noch nicht genutzt. Meistlande ich bei lighthttpd, nginx oder caddy

OpenBSD httpd ist auch super, mit dem habe ich meine ersten Erfahrungen gemacht, ihn aber seit bestimmt 10 jahren nicht genutzt
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: andy_m4 und Alter_Falter
Ich würde hier nicht auf Exoten zurückgreifen, sondern auf etablierte Systeme. Lighttpd ist schon in Ordnung und wirklich ein Leichtgewicht.

Auch auch die Großen sind nicht per se Schwergewichte. Ein nginx(lite) kommt auch klein daher. Ich nutze mittlerweile auch fast überall nginx, selbst auf dem raspi.

Was ist denn der Anwendungszweck? Dann kann man ggf gezielter helfen.

PS: notfalls ginge sogar ein Einzeiler in Python oder sonstiges. Dann halt ohne Features/Sicherheit. Daher die Frage nach dem Anwendungszweck...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: prayhe, Spawn182 und madmax2010
  • Gefällt mir
Reaktionen: konkretor, andy_m4 und madmax2010
Ich würde nginx auch eher als leicht bezeichnen und dieser ist absolut ausgereift und man lernt was auch für eventuell komplexere Fälle, falls diese mal anstehen :)

Statische Seite hosten ist auch einfach, nginx installieren, server block aus der default config anpassen, restart nginx, fertig. Optional UFW entsprechend anpassen und Letsencrypt Cert hinzufügen, auch jeweils in ca. zwei Zeilen erledigt.
 
  • Gefällt mir
Reaktionen: Der Lord
Kleinste Webserver der Welt.
Bash:
$ echo -e "HTTP/1.1 200 OK\n\n\x41\x6c\x6c\x65\x20\x4d\x65\x6e\x73\x63\x68\x65\x6e\x20\x68\x61\x62\x65\x6e\x20\x77\x61\x73\x20\x6d\x69\x74\x20\x54\x68\x6f\x6d\x61\x73\x20\x41\x6e\x64\x65\x72\x73\x20\x67\x65\x6d\x65\x69\x6e\x73\x61\x6d\x2e\x20\x53\x69\x65\x20\x68\x65\x69\x73\x73\x65\x6e\x20\x65\x6e\x74\x77\x65\x64\x65\x72\x20\x54\x68\x6f\x6d\x61\x73\x20\x6f\x64\x65\x72\x20\x61\x6e\x64\x65\x72\x73\x2e" | nc -clp 1500
Code:
http://localhost:1500
 
  • Gefällt mir
Reaktionen: dasBaum_CH
Uridium schrieb:
Kleinste Webserver der Welt.
Ja. Mit netcat hab ich auch schon herum hantiert und ein kleines Shell-Skript geschrieben, welches Webserver-Aufgaben erfüllt. Das funktioniert sogar relativ gut. Auch Fileserving kann man im Prinzip machen. Aber ein "richtiger" Webserver bietet dann doch etwas mehr Komfort und Stabilität.
Denn Du musst ja dann auch den Request parsen und solche Sachen. Da brauchst Du neben den Parsing-Teil auch die Möglichkeit, die Anfrage vorher zu bearbeiten bevor Du die Antwort an nc weiter "pipst", weshalb Du dann mit einem FIFO-File herumhantieren musst. Insbesondere schnell hintereinander reinkommende Requests (die Du nun mal hast, wenn auf der Webseite weitere Ressourcen wie Images usw. sind) lassen das gerne mal außer Tritt geraten geraten.

Auf der anderen Seite hast Du dann so was wie micro_httpd was von der Größe her vergleichbar ist (und Du brauchst halt keine laufende Shell und sonstige Tools wie netcat oder awk zum parsen) und dann sparst Du über den netcat-Weg gar nichts.
 
Sorry für die Zwischenfrage, aber scheinbar gibt es hier Experten die mir das beantworten können.
Auf meinem Mail und auch Webserver sehe ich immer wieder diese Fehlermeldungen z.B.:
Code:
    warning: non-SMTP command from azpdws2tauwp.stretchoid.com[20.171.29.23]: \026\003\001\000\232\001\000\000\226\003\003\323\305\203X\313'\024\351\265A\240\335\203\312\213\323\
Webserver:
Code:
184.105.247.254 - - [27/Feb/2025:11:36:49 +0100] "\x16\x03\x01\x00{\x01\x00\x00w\x03\x03@\x9B\xE7\xB1\x89\xF1\x05\xFF>\x0E\xCB\x99_\x85\xAA\xECC$\xA6L\x04Ml\xFA\x0CA`\xEC\xCD\x88\x00\xE4\x00\x00\x1A\xC0/\xC0+\xC0\x11\xC0\x07\xC0\x13\xC0\x09\xC0\x14\xC0" 400 150 "-" "-"

Also sowas in der Art wie @Uridium beschreibt.

Was um alles in der Welt hat dieser Kauderwelsch zu bedeuten?

Ich weiß dass es Bots sind die irgendwelche Schwachstellen ausnutzen wollen nur was dahinter steckt wüsste ich gern.
 
Das sind Binärdaten. So etwas kommt in der Regel von Bots/Scannern, die nach verwundbaren Systemen suchen. Also immer schön patchen und die Angriffsfläche klein halten.

Zum Thema: Warum das Rad neu erfinden? Nginx mit möglichst wenig Erweiterungen (Bei Debian z.B. nginx-light) ist schlank und bewährt.
 
  • Gefällt mir
Reaktionen: dasBaum_CH und Der Lord
Pummeluff schrieb:
Wenig Lines-of-Code bedeuten ja nicht zwangsläufig, das die Lösung schlank ist. :-)
Allein der geladene Python-Interpreter ist um ein vielfaches Größer z.B. ein geladener OpenBSD httpd.

Pummeluff schrieb:
Vermutlich dürfte diese Lösung zu den schnellsten Webservern der Welt gehören:
LOA
Der Online-Artikel ist als How-To-program interessant.
 
Spawn182 schrieb:
Ich würde nginx auch eher als leicht bezeichnen und dieser ist absolut ausgereift und man lernt was auch für eventuell komplexere Fälle, falls diese mal anstehen
Um mal ein Update zu geben:
Deine Argumentation hat mich letztlich doch überzeugt. Also einmal das, das der ja eigentlich in der Basis-Version relativ schlank ist. Aber insbesondere das man damit ja perspektivisch mehr machen kann (wozu mir die letzten Tage auch noch Ideen gekommen sind).

Das einzige, weshalb ich zwischendurch auch OpenBSD httpd in Betracht gezogen hab, ist dessen eingebaute Möglichkeit chroot(), was dann eine zusätzliche Abkapslung (neben dem "run-as-user") bietet.
Das kriegt man allerdings auch (mit ein bisschen Bastelei) bei nginx hin.

Insofern bin ich da insgesamt ganz zufrieden mit und möchte mich daher bei Dir und allen anderen für eure Inspiration bedanken. Nicht zuletzt deshalb, weil ich es auch allgemein ganz interessant fand mal ein Überblick über die Webserver-Landschaft (abseits der üblichen Verdächtigen) zu bekommen.
 
  • Gefällt mir
Reaktionen: Spawn182
Wenn ich mich hier mal einklinken darf, mich würde mal interessieren warum hier keiner Apache erwähnt. Ich bin selbst absoluter Webserver Anfängern und würde mich da gern zukunftssicher orientieren nur bisher fehlen mir die Argumente warum man Apache ersetzen sollte? Auch hier im Sinne des Thread, was an Apache ist nicht "klein bzw. schlank", also anhand welcher Metriken wird hier verglichen?
 
Snakeeater schrieb:
Auch hier im Sinne des Thread, was an Apache ist nicht "klein bzw. schlank"
Das Apache-Package hat einen Umfang von über 5MB, das von nginx hat ein bisschen mehr als ein halbes MB.
Sicherlich kann man den Apache noch "downstrippen", aber das ist dann auch Gebastel.
Außerdem hat der Apache den Ansatz, einen Request mit einem eigenen Thread zu bearbeiten (wobei sich das auch ein konfigurieren lässt mit Multi-Processing-Modules). Im nginx kann man worker-Threads definieren, die ihrerseits dann aber wieder sich quasi parallel um mehrere Abfragen kümmern (so ein bisschen wie das event/async wie bei node.js) können (bei mir hab ich jetzt nur einen worker-Thread, was völlig ausreichend ist). Apaches Ansatz ist ein Tick robuster. Aber ressourcen-effizienter ist das, was nginx da macht.

Snakeeater schrieb:
Ich bin selbst absoluter Webserver Anfängern und würde mich da gern zukunftssicher orientieren nur bisher fehlen mir die Argumente warum man Apache ersetzen sollte?
Also zunächst ein mal muss man sagen, das der Apache nach wie vor ein guter, solider Webserver ist, der auch immer noch weit verbreitet ist. Wenn alles gut läuft, gibts also aus meiner Sicht keinen ernsthaften Grund den zu ersetzen. Ist ja jetzt nicht so als ob da nichts mehr passiert oder so, sondern es werden weiterhin regelmäßig Updates veröffentlicht (siehe Apache-Webseite).
Insofern ist auch eine Zukunftssicherheit gewährleistet (und die Apache Software Foundation ist auch nicht bekannt dafür, das sie Projekte kurzfristig fallen lässt).
Gut, was in 10 Jahren ist weiß man nicht und das kann auch niemand seriös voraussagen (was dann auch das Problem mitsich bringt, das man gar nicht weiß, auf was man denn besser setzen könnte).

Und man muss ja auch sagen, das der Apache recht umfangreich ist. Und dann sollte man gucken, ob man irgendwo nicht Apache-Features nutzt, die in anderen Webservern gar nicht so leicht umzusetzen sind (ich denk da so an in-Directory-Configuration a-la .htaccess).

Und um noch mal den Kreis zum Ressourcenverbrauch zu schließen:
Ist ja jetzt auch nicht so, das der Apache-httpd da wirklich schlecht ist. Wenn man also kein Performance-Problem hat, lohnt auch dafür nicht unbedingt ein Wechsel. Es sei denn, Du erwartest einen größeren Ansturm auf die Seite und willst das aber gleichzeitig mit schmaler Hardware wegarbeiten.

Kurzum: Wenn es keinen wirklichen Grund gibt von Apache wegzuwechseln, würde ich dabei bleiben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Snakeeater
Zurück
Oben