Serwer WWW w czystym asemblerze ARM64: Powrót do korzeni programowania systemowego

Wyobraź sobie, że budujesz web serwer od zera, używając tylko asemblera. Bez bibliotek, bez frameworków. Tylko ty, procesor i surowy kod maszynowy. Tak właśnie powstał ymawky – prosty, statyczny serwer HTTP na macOS, napisany w ARM64 assembly. Zero libc, zero litości.

Po co komu taki szal?

Nikt przy zdrowych zmysłach nie zamieni nginx na asembler. Ale ten projekt ma sens edukacyjny. Autor, z doświadczeniem w niskopoziomowym programowaniu, chciał zrozumieć, jak naprawdę działają serwery WWW. Jakie są pułapki? Co kryją się za warstwami abstrakcji w C czy Pythonie?

W erze kontenerów i gotowych rozwiązań warto zajrzeć pod maskę. Zrozumieć, co dzieje się na poziomie metalu.

Asembler: Brutalna szczerość

Asembler to most między kodem maszynowym a naszymi umysłami. Polecenie jak mov x16, #5 po prostu ładuje 5 do rejestru x16. Bez magii, bez ukrytych sztuczek.

Co boli:

• Brak automatycznego sprzątania pamięci.
• Stringi to zwykłe bajty bez ochrony typów.
• Struktury wymagają ręcznych obliczeń offsetów – jeden błąd i masz śmieci.
• Każdy błąd sprawdzasz po flagach procesora.
• Literówka? Krach bez ostrzeżenia.

Co zachwyca:

• Widzisz każdą instrukcję CPU.
• Zero ukrytych kosztów.
• Wiesz dokładnie, co robi hardware.
• Przewidywalna wydajność.

Pisanie parsera HTTP od zera zmusza do myślenia o złych danych, kodowaniach i lukach bezpieczeństwa. To, co frameworki robią w tle, tu robisz sam, bajt po bajcie.

Syscall'e na surowo: Bez poduszek powietrznych

Zamiast libc, bezpośrednie wołanie do kernela. Przykład:

mov x16, #5           ; numer syscalla open
adrp x0, filename@PAGE
add x0, x0, filename@PAGEOFF
mov x1, #0x0         ; O_RDONLY
svc #0x80            ; wołaj kernel
b.cs open_failed     ; sprawdź flagę carry

Argumenty w rejestrach, svc i manualne sprawdzanie flag. Krucha metoda, ale pokazuje prawdę: kernel zwraca status, a ty go obsługujesz.

Jak działa architektura serwera?

Ymawky stosuje klasyczny model fork na żądanie:

1. Tworzy socket i binduje port.
2. Nasłuchuje połączeń.
3. Na każde nowe – fork w nowy proces.
4. Obsługuje request w izolowanym procesie.

Zalety fork:

• Izolacja pamięci.
• Prosty kod.
• Łatwe odzyskiwanie błędów.

Wady:

• Duże zużycie pamięci.
• Słaba skalowalność.
• Przełączanie kontekstów dusi wydajność.

W asemblerze prostota wygrywa z optymalizacją.

Co dzieje się z requestem?

Obsługa żądania to seria wyzwań:

• Rozpoznawanie metod: GET, POST, DELETE.
• Wyciąganie ścieżki z linii requestu.
• Dekodowanie URL (%20 na spację).
• Blokada traversal attacks (jak ../etc/passwd).
• Parsowanie headerów.
• Obsługa range requests.
• Listowanie katalogów w HTML.
• Strony błędów jak 404.

W Pythonie to banał. W asemblerze – każdy krok to walka z rejestrami i stringami.

Dlaczego to ważne dla dzisiejszych devów?

Nie musisz pisać w asemblerze. Ale ymawky pokazuje: każda abstrakcja ukrywa złożoność. Zrozumienie jej czyni cię lepszym inżynierem.

To jak gotowanie od podstaw. Nie robisz mąki codziennie, ale wiesz, co kupujesz w sklepie.

Połączenie z NameOcean

W NameOcean zajmujemy się całym stosem: od DNS i domainów po cloud hosting. Wiedza o syscallach, protokołach bez warstw i edge cases pomaga w lepszych decyzjach. Konfiguracja DNS, SSL handshake na bajtach czy deployment – systems thinking to podstawa.

Podsumowanie

Ymawky nie pokona nginx. Ale przypomina: najbardziej szalone projekty uczą najwięcej. Pokazują pokorę wobec narzędzi i jasność tego, co dzieje się w hardware. Jeśli chcesz zrozumieć serwery od środka – zacznij od tego kodu. Brutalny, ale genialny.