Assembly en Web Servers: Een Duik in Zuivere Systeemprogrammering

Stel je voor: je bouwt een webserver zonder hulpmiddelen, puur met assembly voor ARM64 op macOS. Geen libc, geen shortcuts. ymawky doet precies dat. Een statische HTTP-server die rauw en functioneel is. Het is alsof je een huis bouwt met alleen een hamer van steen.

Waarom Dit Gekkenwerk?

Niemand dumpt nginx voor assembly. Maar dit project legt bloot hoe servers écht werken. De maker, met een achtergrond in low-level systemen, miste inzicht in de basis. Welke risico's loeren er? Welke problemen moet je oplossen? Wat verbergen high-level talen als Python of C?

In een tijd van kant-en-klare containers is dit goud waard. Je ziet wat er onder de motorkap gebeurt, tot op het metaal.

De Ruige Schoonheid van Assembly

Assembly hangt tussen machinecode en menselijke logica. Met mov x16, #5 laad je letterlijk het getal 5 in register x16. Dat triggert een syscall voor open() op Darwin.

De valkuilen:

• Geen automatische geheugenzuivering
• Strings zijn kale byte-reeksen, zonder types
• Structs? Handmatig rekenen met offsets – één fout en het crasht
• Elke error check je via CPU-flags
• Typfouten slaan keihard toe, zonder compiler-hulp

De pluspunten:

• Volledig zicht op CPU-instructies
• Geen verborgen kosten of allocations
• Je snapt de hardware door en door
• Prestaties zijn voorspelbaar

Geen kant-en-klare HTTP-parser. Je bouwt alles byte voor byte. Zo leer je malformed requests, encoding-fouten en security-gaten écht kennen.

Syscalls Zonder Bescherming

Normaal vangt libc syscalls op. ymawky niet:

mov x16, #5           ; SYS_open
adrp x0, filename@PAGE
add x0, x0, filename@PAGEOFF
mov x1, #0x0         ; O_RDONLY
svc #0x80            ; Kernel aanroepen
b.cs open_failed     ; Check carry flag

Je zet registers, roept de kernel aan en controleert flags. Geen exceptions, puur branching. Kwetsbaar, maar eerlijk. Jij draagt de verantwoordelijkheid.

Hoe de Server Werkt

ymawky gebruikt een klassiek fork-per-request model:

1. Socket maken en binden op een poort
2. Luisteren naar connecties
3. Per connectie een fork() naar nieuw proces
4. Request afhandelen in dat proces

Voordelen van fork:

• Requests geïsoleerd in geheugen
• Eenvoudige code
• Makkelijke error-herstel

Nadelen:

• Hoog geheugengebruik per fork
• Slechte schaalbaarheid bij veel traffic
• Context switches remmen af
• Geen match voor event-driven zoals nginx

Minder efficiënt, maar perfect te snappen in assembly.

Wat Gebeurt er bij een Request?

Je moet alles zelf oplossen:

• Request-type herkennen: GET, POST, etc. uit bytes
• Pad uittrekken: Bestandspad uit de request line
• URL-decoden: %20 naar spaties
• Path traversal blokken: Geen ../../../etc/passwd
• Headers parsen
• Range requests voor grote bestanden
• Directory listings in HTML
• Error-pagina's voor 404's

In JS of Python triviaal. In assembly een heel project met register-jonglage en string-trucs.

Waarom Dit Relevant is voor Jou

Je schrijft zelden assembly. En production-servers al helemaal niet. Maar ymawky toont: abstraheringen verbergen complexiteit die blijft bestaan.

Frameworks lossen dit op, maar als je het snapt, word je beter. Net als koken zonder pakjes: je waardeert de basis-ingrediënten meer.

Link met NameOcean

Bij NameOcean duiken we in de hele stack: van DNS en domain management tot cloud hosting. Inzicht in kernel-syscalls, protocollen en edge cases helpt bij slimme keuzes. Of je nu VPS inzet, DNS tweak't of SSL-handshakes doorziet – systems thinking telt.

De Les

ymawky verslaat nginx niet. Maar het herinnert: onpraktische projecten leren het meest. Het toont nederigheid voor de tools die we dagelijks gebruiken, en helderheid over wat hardware doet.

Benieuwd naar de kern van een webserver? ymawky geeft blootgelegde antwoorden.