Když se assembly setká s webovými servery: Cesta do hlubin systémového programování

Představte si, že byste stavěli webový server od nuly. Bez knihoven, bez frameworků, jen vy a čisté assembly pro ARM64 na macOS. Žádné libc, žádné zkratky. To je přesně ymawky – funkční statický HTTP server, který vás donutí pochopit hardware na úrovni bitů.

Proč to vůbec dělat?

Nikdo v praxi nenahradí nginx assembly kódem. Ale takový projekt má obrovskou vzdělávací hodnotu. Odhaluje, co se skrývá pod vrstvami abstrakcí, které používáme v Pythonu nebo C.

Autor přišel z low-level světa a uvědomil si, že si podrobnosti webových serverů vůbec nepamatuje. Jaké jsou skutečné rizika? Co řeší ty nejpokročilejší nástroje? V éře kontejnerizovaného nginxu je super znát základy na úrovni kovu.

Assembly: Krása i peklo

Assembly je most mezi strojovým kódem a lidskou logikou. Když napíšete mov x16, #5, přesně víte, co se děje – číslo 5 jde do registru x16. To je syscall pro open() na Darwinu.

Nevýhody:

• Žádný garbage collector, paměť si spravujete ručně
• Řetězce jsou jen bajty bez type safety
• Struktury? Počítejte offsety na jednotlivé bajty
• Každou chybu kontrolujete přes CPU flagy
• Jedna chyba a crash bez varování

Výhody:

• Vidíte každou instrukci procesoru
• Žádné skryté alokace nebo overhead
• Přesně víte, co hardware dělá
• Výkon je transparentní

Bez HTTP parserů musíte requesty rozkládat bajt po bajtu. To vás naučí o malformed datech, kódováních a bezpečnostních pastích.

Přímé syscaly bez ochrany

libc normálně zjemňuje komunikaci s jádrem. Ymawky to přeskakuje:

mov x16, #5           ; syscall pro open
adrp x0, filename@PAGE
add x0, x0, filename@PAGEOFF
mov x1, #0x0         ; O_RDONLY
svc #0x80            ; volání jádra
b.cs open_failed     ; skok při chybě (carry flag)

Argumenty do registrů, volání jádra, kontrola flagů. Žádné výjimky – jen ruční handling. Je to křehké, ale upřímné.

Architektura serveru

Ymawky používá klasický fork na každý request:

1. Socket, bind na port
2. Poslouchání připojení
3. Pro každé fork do nového procesu
4. Zpracování requestu v izolaci

Proč fork?

• Izolace paměti mezi requesty
• Jednoduchý kód
• Snadné obnovy po chybách

Mínusy:

• Velká spotřeba paměti (kopíruje celý proces)
• Špatná konkurence oproti event-loop modelům jako nginx
• Context switching brzdí pod zátěží
• Ne pro tisíce souběžných klientů

V assembly je to pochopitelné. A o to jde.

Co se děje uvnitř requestu

Musíte řešit detaily, které frameworky schovají:

• Rozpoznání GET, POST, PUT atd. z raw bajtů
• Extrakce cesty k souboru
• Dekódování URL (%20 na mezery)
• Blokování path traversal (žádné ../../../etc/passwd)
• Parsování hlaviček
• Range requesty pro velké soubory
• Výpisy adresářů v HTML
• Chybové stránky pro 404

V Pythonu to jde na pár řádků. V assembly je to celý projekt s registr managementem a ručním handlingem.

Proč to moderní developery potřebují

Assembly nebudete psát v produkci. Web server v něm taky ne. Ale ymawky ukáže, že každá abstrakce skrývá složitost.

Když framework parsuje HTTP, spoléhejte se na někoho, kdo to pochopil do detailu. Samostatné porozumění vás udělá lepším inženýrem.

Je to jako vaření od nuly. Nemusíte mít vlastní mouku, ale vědět, jak se dělá, vám pomůže s hotovými surovinami.

Souvislost s NameOcean

V NameOcean řešíme celý stack – od DNS a domén po cloud hosting. Znalost kernelu, protokolů bez abstrakcí a syscallů pomáhá s lepšími rozhodnutími.

Ať nastavujete DNS pro domain, SSL handshake nebo hosting na našem cloudu – systémové myšlení rozhoduje. Proto se učime základy, ne jen povrch.

Závěr

Ymawky nginx nepřeválcuje. Ale připomíná, že nejužitečnější projekty nás učí nejvíc. Naučí pokoru před složitostí nástrojů a jasnost toho, co hardware opravdu dělá.

Chcete vědět, co se děje pod kapotou web serveru? Ymawky je brutální, ale osvětlující odpověď.