Amikor az assembly találkozik a web szerverekkel: Utazás a tiszta rendszerprogramozás mélyére

Képzeld el, hogy úgy akarsz hotdogot enni, hogy előbb lemészarsz egy tehenet kőkésből faragott pengével. Na, valami ilyesmi a ymawky lényege: egy teljes értékű statikus HTTP szerver, amit kizárólag ARM64 assembly-ben írtak macOS-re. Semmi libc, semmi felesleges réteg – csak a nyers valóság.

Miért csinál ilyet bárki?

Senki sem cseréli le az nginx-et assembly-re holnap. De óriási tanulási érték van benne, ha nulláról építesz web szert. Minden modern kényelmet lehúzunk, amit az elmúlt 70 év hozott.

A készítő egyszerűen bevallja: alacsony szintű rendszerekkel foglalkozott, de rájött, hogy fogalma sincs, hogyan működik egy web szerver a gyakorlatban. Mik a valódi kockázatok? Milyen problémákat kell megoldani? Mit rejtenek el a Python vagy C absztrakciói?

Ma mindenki konténerben futtat nginx-et gondolkodás nélkül. Pedig megéri tudni, mi történik a fémben, a processzorban.

Assembly: Szép kegyetlenség

Az assembly ott van a gépi kód és az emberi ész között. Ha írsz egy mov x16, #5-öt, szó szerint a 5-ös számot pakolod az x16 regiszterbe. Ez a syscall szám a Darwin open() funkciójára utal.

Miért szörnyű és miért zseniális egyszerre?

Kihívások:

• Nincs automatikus memóriaigazgatás vagy takarítás
• A stringek sima bájtok sorozata, típusbiztonság nélkül
• Struktúrákhoz kézzel kell offseteket számolni – egy bájt hiba, és szemetet olvasol
• Minden hibát CPU zászlók alapján kell kezelni
• Egy elírás, és az egész rendszer összeomlik, compiler figyelmeztetés nélkül

Előnyök:

• Látod minden CPU utasítást
• Nincs rejtett költség vagy váratlan allokáció
• Pontosan tudod, mit csinál a hardver
• A teljesítmény kiszámítható, átlátható

Web szerverben nincs kész HTTP parser. Magad építed fel bájtról bájtra. Ez rákényszerít, hogy gondolkodj rosszul formázott inputon, kódolási hibákon és biztonsági réseken, amiket magasabb szinteken a keretrendszerek elrejtenek.

Nyers syscall-ek: Nincs korlát

A C programok libc-n keresztül beszélnek a kernellel. A ymawky ezt kihagyja:

mov x16, #5           ; SYS_open szám
adrp x0, filename@PAGE
add x0, x0, filename@PAGEOFF
mov x1, #0x0         ; O_RDONLY
svc #0x80            ; kernel hívás
b.cs open_failed     ; ugrás, ha carry flag be van állítva

Kézzel pakolod a regiszterekbe az argumentumokat, hívod a kernelt svc #0x80-zal, aztán ellenőrzöd a carry flaget. Nincs kivételkezelés, csak manuális ellenőrzés és ugrás hibakezelőre.

Ez törékenyebb, de őszinte. Nem hazudsz magadnak: a kernel állapotot ad vissza, neked kell kezelned.

A szerver felépítése

A ymawky klasszikus fork-on-request modellt használ:

1. Socket létrehozása és portra kötés
2. Figyelés bejövő kapcsolatokra
3. Új kapcsolatnál fork() egy új processzbe
4. Az új processzben feldolgozza a HTTP requestet

Miért fork minden requestre?

• Memóriaszeparáció requestek között
• Egyszerűbb kód és gondolkodás
• Könnyebb hibakezelés

Hátrányok?

• Nagy memóriafogyasztás (minden fork másolja a teljes processz teret)
• Gyenge párhuzamosítás, szemben az nginx event-driven modelljével
• Kontextusváltás bottleneck nagy terhelésnél
• Nem skáláz ezresekre egyszerre

Kevesebb hatékonyság, de assembly-ben érthető. És ez a lényeg.

Mi történik egy request alatt?

A request pipeline építése olyan problémákat hoz elő, amik keretrendszerekben láthatatlanok:

• Request típus felismerés: GET, HEAD, POST stb. kinyerése nyers bájtokból
• Útvonal kinyerés: A fájlpath kihúzása a request sorból
• URL dekódolás: %20-ból space, edge case-ekkel
• Path traversal blokkolás: Nincs ../../../etc/passwd
• Header feldolgozás: Minden header értelmezése
• Range requestek: Nagy fájlok bájt tartományai
• Könyvtár listázás: HTML generálás mappákhoz
• Saját hibaoldalak: 404 és társaikhoz értelmes válaszok

Pythonban vagy JS-ben ezek triviálisak. Assembly-ben mind mini-projekt: regiszterkezelés, string manipuláció beépített funkciók nélkül, explicit hibakezelés.

Miért fontos ez mai fejlesztőknek?

Soha nem írsz assembly-t élesben. Web szervert pláne ne. De a ymawky kódja megtanít valamire alapvetőre: minden absztrakció összetettséget rejt, ami valahol létezik.

Ha keretrendszer kezeli a HTTP parsert, valakire támaszkodsz, aki mélyen értette ezeket. Ha te is érted – még ha soha nem is oldod meg újra –, jobb mérnök leszel.

Mint a főzés nulláról. Nem őrölsz lisztet és sót mindennap, mert a bolti jobb. De ha egyszer megteszed, jobban érted az alapanyagokat.

NameOcean kapcsolata

Nálunk a NameOcean-nél a stack minden rétegén dolgozunk: DNS feloldástól domain kezelésen át cloud infrastruktúráig. Értjük, mi történik kernel szinten, hogyan működnek protokollok absztrakció nélkül, és hogyan kezeled az edge case-eket syscall szinten. Ez jobb döntéseket hoz infrastruktúrában.

Akár a cloud hosting platformunkra deployolsz, DNS-t állítasz be domainhez, vagy SSL handshake-et értesz bájt szinten – a rendszerismeret számít. Ezért tanuljuk meg, hogyan működnek a dolgok igazán, nem csak hogyan használjuk őket.

A lényeg

A ymawky nem üti ki az nginx-et. De gyönyörű emlékeztető: a legimpraktikusabb projektek tanítanak a legtöbbet. Alázatot ad – látod, mennyi munka van a mindennapi eszközeinkben –, és tisztánlátást – pontosan látod, mit művel a hardver, közvetítők nélkül.

Ha kíváncsi vagy, mi történik a motorháztető alatt egy web szerverben, a ymawky kemény, de világos válasz.