Wenn Assembly auf Webserver trifft: Ein Trip in die Tiefen der Systemprogrammierung

Stellt euch vor, ihr baut ein Haus ohne Hammer oder Säge – nur mit bloßen Händen und Steinwerkzeugen. Genau das Feeling hat ymawky: Ein simpler, statischer HTTP-Server, komplett in ARM64-Assembly für macOS. Ohne libc, ohne Gnade.

Warum sich das jemand antut

Kein Mensch ersetzt nginx durch Assembly. Aber genau das macht es spannend. Der Entwickler kommt aus der Low-Level-Welt und hat gemerkt: Er kennt Webserver nur oberflächlich. Welche Risiken lauern wirklich? Welche Probleme muss man lösen? Was verstecken Sprachen wie Python oder C vor uns?

In Zeiten von Docker und fertigen nginx-Containern zahlt es sich aus, bis zur Hardware vorzudringen.

Die rohe Kraft von Assembly

Assembly liegt genau zwischen Maschinencode und unserem Verstand. Mit mov x16, #5 schiebt ihr die 5 direkt in einen Register. Das ist Syscall 5 für open() auf Darwin – pur und ehrlich.

Die Hürden:

• Kein automatisches Speichermanagement
• Strings sind bloße Bytefolgen, ohne Typensicherheit
• Strukturen? Manuelle Offsets rechnen – ein Fehlpixel, und alles crasht
• Jeder Fehler braucht Flag-Checks
• Tippfehler? Sofortiger Absturz, kein Compiler-Alarm

Die Stärken:

• Volle Sicht auf jede CPU-Anweisung
• Kein versteckter Overhead
• Ihr wisst präzise, was die Hardware tut
• Performance ist glasklar

Kein fertiges HTTP-Parser-Bibliothek. Ihr baut alles byteweise selbst. Das zwingt euch, über kaputte Eingaben, Encodings und Sicherheitslücken nachzudenken – Sachen, die Frameworks im Dunkeln erledigen.

Direkte Syscalls ohne Sicherheitsnetz

C-Programme nutzen libc als Puffer zur Kernel. ymawky lässt das weg:

mov x16, #5           ; SYS_open
adrp x0, filename@PAGE
add x0, x0, filename@PAGEOFF
mov x1, #0x0         ; O_RDONLY
svc #0x80            ; Kernel aufrufen
b.cs open_failed     ; Bei Carry-Flag: Fehler

Register füllen, Kernel mit svc rufen, Flag prüfen. Keine Exceptions – nur brutales Branching zu Fehlern. Zerbrechlich, aber wahrheitsgemäß.

So tickt der Server

ymawky nutzt das alte Fork-pro-request-Schema:

1. Socket erstellen und binden
2. Auf Connections lauschen
3. Bei jeder: fork() in neuen Prozess
4. Request im isolierten Prozess bearbeiten

Warum fork?

• Requests isolieren sich selbst
• Code bleibt einfach
• Fehler einfach abfangen

Nachteile?

• Hoher Speicherverbrauch pro Fork
• Schlechte Skalierung bei vielen Nutzern
• Context-Switches bremsen
• Kein Massen-Handling

Weniger effizient als nginx, aber in Assembly nachvollziehbar. Darum geht's.

Was läuft bei einem Request ab

Ihr müsst alles selbst knacken, was Frameworks erledigen:

• Methoden erkennen: GET, POST & Co. aus Bytes fischen
• Pfad rausholen: Aus der Request-Zeile extrahieren
• URL-Decode: %20 zu Leerzeichen, mit Fallen
• Traversal blocken: Kein ../etc/passwd
• Header parsen: Jede Zeile analysieren
• Range-Requests: Teile von Dateien serven
• Verzeichnis-Listing: HTML für Ordner generieren
• Fehlerseiten: Schöne 404er

In Python easy. In Assembly? Jede Aufgabe ein Kampf mit Registern und Strings.

Warum das für Entwickler zählt

Assembly schreibt selten mal einer. Produktionsserver? Niemals. Aber ymawky zeigt: Jede Abstraktion kaschiert echte Komplexität.

Wenn Frameworks HTTP parsen, vertraut ihr auf Profis. Das selbst zu kapieren macht euch schärfer – auch ohne Wiederholung.

Wie beim Kochen: Mehl selber mahlen? Nur zum Lernen. Danach schmeckt Supermarktmehl besser.

Der NameOcean-Bezug

Bei NameOcean decken wir den Stack ab: DNS, Domains, Cloud-Hosting. Kernel-Wissen, rohe Protokolle und Syscall-Fälle helfen bei echten Entscheidungen.

Egal ob Cloud-Deployment, DNS-Setup oder SSL-Bytes: Tiefenverständnis zahlt sich aus. Deshalb graben wir tiefer.

Fazit

ymawky kickt nginx nicht vom Thron. Aber es mahnt: Die absurdsten Projekte lehren am meisten. Demut vor der Komplexität unserer Tools – und Klarheit über die Hardware.

Neugierig auf den Kern eines Requests? ymawky liefert die harte Wahrheit.