ymawky – direkt in ARM64-Assembler gebauter Webserver

• ymawky ist ein statischer Datei-Webserver, der ausschließlich in ARM64-Assembler geschrieben ist, ohne libc auskommt, nur Syscalls verwendet und mit einer Architektur arbeitet, die pro Verbindung fork ausführt
• Das Entwicklungsziel ist MacOS; lauffähig ist er nur auf Apple silicon arm64. Für den Build werden die Xcode Command Line Tools und make benötigt
• Standardmäßig startet er auf 127.0.0.1:8080. Ein Port kann angegeben werden, benutzerdefinierte Adressen werden derzeit jedoch nicht unterstützt, sodass er nur auf 127.0.0.1 läuft
• Das Document Root ist standardmäßig www/; GET / sucht nach www/index.html, und Fehlerseiten sind so konfiguriert, dass sie aus err/(code).html bereitgestellt werden
• Unterstützte HTTP-Methoden sind GET, PUT, DELETE, OPTIONS, HEAD; serverseitige Codeausführung oder erweitertes URL-Parsing wie /search?query=term werden nicht unterstützt
• PUT unterstützt standardmäßig Uploads bis 1GiB und schreibt zunächst in die temporäre Datei www/.ymawky_tmp_<pid>, die anschließend per Rename umbenannt wird, damit partielle Uploads keine vorhandenen Dateien überschreiben
• GET unterstützt Anfragen mit Range: bytes= und verarbeitet die Formate bytes=X-N, bytes=-N und bytes=X-; laut Beschreibung funktioniert auch Video-Seeking gut
• Auf Basis der Dateierweiterung erkennt der Server MIME-Typen und sendet den Response-Header Content-Type; erkannt werden zahlreiche Erweiterungen für Webdateien, Bilder, Schriftarten, Dokumente, Videos, Audiodateien und Archive
• Zu den Sicherheitsmaßnahmen für Pfade gehören die Ablehnung von Pfaden ab PATH_MAX, das Blockieren von Pfad-Ausbrüchen über .., das Voranstellen des Präfixes www/ bei allen Request-Pfaden sowie das Ablehnen von Pfaden mit Symlinks per O_NOFOLLOW_ANY
• Zur Abschwächung von Slowloris-artigen DoS-Angriffen wird die Verbindung geschlossen und 408 Request Timeout zurückgegeben, wenn zwischen zwei Lesevorgängen mehr als 10 Sekunden liegen oder der vollständige Header-Empfang länger als 10 Sekunden dauert
• Bei HTTP/1.1-Requests ist der Header Host: erforderlich; der Host-Wert selbst wird zwar nicht verwendet, aber die Existenz des Headers wird gemäß RFC 9112 Section 3.2 verlangt
• In config.S lassen sich Document Root, Fehlerseitenverzeichnis, Standarddatei, Empfangs-Timeout, Geschwindigkeits- und Größenlimits für PUT sowie die maximale Zahl gleichzeitiger Prozesse anpassen
• Für eine Portierung auf Linux oder andere Unix-Systeme müssten unter anderem die Register für Syscall-Aufrufe und svc, die Art der Fehler-Rückgabe, fork(), SO_NOSIGPIPE, O_NOFOLLOW_ANY, renameatx_np(), Struktur-Layouts, die Mach-O-Relocation-Syntax und das Signal-Handling angepasst werden

[GN⁺]

Hacker-News-Kommentare

• Wenn man tatsächlich große Programme in Assembly, insbesondere mit einem Makro-Assembler, schreibt, merkt man schnell, dass es im Grunde nicht fundamental anders ist als Programmierung auf höherem Niveau, nur ausführlicher
  Letztlich reicht es, sich daran zu gewöhnen, mit Prozeduren und Makros Abstraktionen zu schaffen, und oft ist es viel schwieriger, Assembly effektiv zu lesen, als sie zu schreiben

  • Genau das habe ich bei dieser Arbeit auch festgestellt. Man muss vieles sehr viel expliziter schreiben, aber die Art und Weise, wie einzelne Funktionen arbeiten, unterscheidet sich im Kern nicht
    strlen läuft am Ende in C, Rust, Assembly oder jeder anderen Sprache den String durch und sucht nach dem NULL-Byte. Weil man genau ausschreibt, was die CPU in welcher Reihenfolge tun soll, fühlt es sich manchmal sogar intuitiver an als in anderen Sprachen

• Das ist wirklich ein schönes und hervorragend gemachtes Projekt. In Anknüpfung an andere Kommentare ist so ein Projekt für mich eher wie eine Minecraft-Map
  Es gibt riesige, erstaunliche Maps, kleine Survival-Maps, Maps, die man lokal nur für sich und Freunde öffnet, und Server, die kommerziell groß werden wollen. Dank AI ist es sehr einfach geworden, auf dem Server Häuser zu bauen oder neue Wege zu entwerfen, aber der Wert, der in dieser Welt entsteht, hängt vom eigentlichen Zweck des Servers ab und davon, ob noch mehr Häuser und Straßen dort überhaupt sinnvoll sind
  Dass kommerzielle Server schneller wachsen und mehr Häuser und Straßen haben können, ist großartig, aber die Zuneigung, die ein Kunstprojekt erzeugt, ist damit nicht vergleichbar

• Es hat sich irgendwie warm angefühlt zu sehen, dass noch jemand so etwas von Hand direkt machen will. Ich bin also nicht der Einzige

  • Ich war eine ganze Weile von der Idee besessen, habe dann schließlich angefangen und mich für ein paar Wochen komplett darin verloren
    Ich würde gern ähnliche Projekte sehen und freue mich, dass ich nicht der Einzige bin. Ich glaube, wenn die meisten Programmierer ein paar Wochen oder Monate lang Assembly lernen würden, würde viel von der Mystik darum verschwinden, wie CPU und kompilierte Sprachen funktionieren

• Interessantes Projekt. Ich habe eine deutlich minimalere Version für x86 Linux gebaut; falls du sehen willst, wie die aussieht, hier ist sie: https://github.com/jcalvinowens/asmhttpd

  • Wow, dieses Projekt war tatsächlich eine große Inspiration für mich. Ich habe es vor einiger Zeit gelesen und war wirklich beeindruckt
    Ich wollte fragen, ob es für dich in Ordnung wäre, wenn ich den Link zu deinem Repository in mein README aufnehme

• Dieses gefälschte O'Reilly-Buchcover ist einfach großartig

  • Genau dieses Buch war überhaupt der konkrete Auslöser dafür, dass ich das gebaut habe. Der Untertitel des Buchs ergab das Akronym für den Projektnamen

• Der Vergleich ist zwar wenig sinnvoll, aber ich würde trotzdem gern wissen, wie die Performance im Vergleich zu voll ausgestatteten Webservern aussieht. Ich würde gern Kennzahlen wie maximale Requests pro Sekunde sehen

  • Ehrlich gesagt habe ich noch keine Benchmarks gemacht, aber ich vermute, dass ymawky deutlich langsamer ist als die meisten voll ausgestatteten Webserver
    ymawky nutzt ein Modell mit fork pro Verbindung und ist daher grundsätzlich langsamer als produktionsreife Server wie nginx oder Apache. nginx verwendet ereignisbasierte I/O mit kqueue/epoll und kann dadurch Tausende gleichzeitige Verbindungen ohne den Overhead eines Prozess-fork pro Request verarbeiten. Apache nutzt Thread-Pools und verarbeitet mehrere Verbindungen, ohne für jede Anfrage neu etwas zu erzeugen
    Ein direkter Vergleich mit anderen Webservern würde meist nur den Unterschied zwischen fork pro Verbindung und Event-Loop bzw. Thread-Pool messen und hätte mit Assembly nur wenig zu tun
    Wenn man stattdessen mit einem ähnlich aufgebauten, in C geschriebenen Server mit Fork pro Verbindung vergleicht, wäre der Durchsatz wahrscheinlich fast gleich. Der Flaschenhals dieses Modells ist nicht der eigentliche Code, sondern fork() selbst. Wahrscheinlich wirkt es sich stärker auf Binärgröße und Startzeit aus als auf Requests pro Sekunde. Trotzdem wäre ein echter Benchmark sicher interessant

• Gut gemacht. Ich arbeite auch an einem ähnlichen, aber kleineren Projekt mit RISC-V; das hier ist großartig

  • Wirklich cool. Wenn du es irgendwo veröffentlicht hast, würde ich es sehr gern sehen

• Ich habe Lust, bewusst gegen die Richtung anzuschwimmen, in die diese Welt des Vibe-Codings geht, und wieder das Gefühl zu haben, herausgefordert zu werden, deshalb versuche ich gerade, einen WebAssembly-Software-Renderer zu schreiben
  Ich weiß nicht, ob ich es zu Ende bringen werde, es ist verrückt und man kann nicht behaupten, dass es nützlich wäre. Aber es fühlt sich wirklich gut an
  Glückwunsch an den ursprünglichen Autor zu dieser Leistung

  • Ich habe exakt dasselbe gemacht und es hat wirklich Spaß gemacht. Es ging nicht darum, etwas Neues in die Welt zu setzen, sondern einfach um eine angenehme Herausforderung für mich selbst
    Danach baue ich damit ein Spiel, aber da der Reiz der Herausforderung jetzt weg ist, komme ich damit kaum noch voran. Macht aber nichts, denn es hat Spaß gemacht. Mit Vibe-Coding hätte ich dieses Vergnügen oder diese Zufriedenheit nicht gehabt
  • Meinst du einen 3D-Software-Renderer? In meiner Jugend und in den ersten Jahren meiner Karriere habe ich eine Menge solcher Dinge mit x86 und C gebaut und dabei viel gelernt
    Ich wollte sehen, wie gut ein LLM einen Renderer für CGA in reinem 8088-Assembler schreiben kann, also habe ich es ausprobieren lassen, und es hat auf Anhieb ein ziemlich ordentliches Demo erzeugt. In den Prompt habe ich die Vektoren eines Elite-Raumschiffs gegeben
    https://imgur.com/a/Dy5rUku

• Eines meiner ersten Assembly-Projekte war ein CGI-Skript, das zu 100 % in x86-Assembly geschrieben war
  Ein vollständiger Webserver ist natürlich noch deutlich beeindruckender. Trotzdem würde ich Anfängern empfehlen, sich zuerst CGI und mod_cgi in Apache anzusehen

  • Wow, ehrlich gesagt fände ich es einschüchternder, ein CGI-Skript in Assembly zu schreiben, als den Server selbst in Assembly zu schreiben
    Über CGI-Unterstützung denke ich schon seit ein paar Wochen nach, habe mich aber noch nicht ernsthaft damit beschäftigt. Falls es irgendwo gehostet ist, würde ich es gern sehen; das könnte später eine gute Referenz sein, wenn ich daran arbeite

• Wir wechseln gerade zu AI, hören auf, Code zu schreiben und uns den Kopf darüber zu zerbrechen, und hier schreibt jemand einen Webserver in Assembly
  Das macht einen demütig

  • Demütig macht es einen schon. Welche Richtung ich bevorzuge, ist für mich ziemlich klar
  • Wer ist hier eigentlich mit „wir“ gemeint? Mir fehlt nicht der Stolz, ordentliche Arbeit selbst zu machen, statt hingeschluderten maschinell erzeugten Code einzureichen