Когато Assembly се сблъсква с уеб сървъри: Пътуване в чистото програмиране на системи

Всички знаем какво значи да разбереш „как се прави наденицата“. Ами ако решиш да заклащаш крава с нож, издялан от камък? Това е духът на ymawky – пълен статичен HTTP сървър, написан изцяло на ARM64 assembly за macOS. Без libc, без компромиси, без пощада.

Защо някой би се захванал с това?

Никой няма да смени nginx с assembly утре. Но има нещо магично образователно в изграждането на уеб сървър, когато премахнеш всички удобства от 1950-те насам.

Създателят е директен: идва от ниско ниво в системното програмиране и осъзнава, че не разбира наистина как работят уеб сървърите. Какви са реалните рискове? Кои проблеми трябва да решиш? Какво се крие зад Python или C абстракциите?

В свят на контейнеризиран nginx без размисъл, разбиране на метала е злато.

Assembly: Красивата жестокост

Assembly е на границата между машинния код и човешкото разбиране. Когато напишеш mov x16, #5, директно слагаш 5 в регистъра x16. Това е syscall номер за open() на Darwin.

Ето защо е ад и просветление:

Предизвикателствата:

• Няма автоматично управление на паметта
• Стринговете са просто байтове без типова сигурност
• Структурите искат ръчни изчисления на офсети – грешка и четеш боклук
• Всяка грешка се хваща от CPU флагове
• Един правописен пропуск – и системата пада без предупреждение

Предимствата:

• Виждаш всяка CPU инструкция
• Няма скрити разходи или алокации
• Знаеш точно какво прави хардуера
• Производителността е прозрачна

В assembly няма HTTP библиотеки. Парсираш заявките байт по байт. Това те кара да мислиш за зле формирани данни, енкодинг и сигурност – неща, които фреймуърците крият.

Сурови Syscalls: Без оградки

Повечето C програми минават през libc към kernel. ymawky скача директно:

mov x16, #5           ; SYS_open
adrp x0, filename@PAGE
add x0, x0, filename@PAGEOFF
mov x1, #0x0         ; O_RDONLY
svc #0x80            ; kernel call
b.cs open_failed     ; провери carry flag

Слагаш аргументи в регистри, викаш kernel с svc #0x80, проверяваш флаг. Няма exceptions – само ръчно скачане към грешки.

По-крехко, но честно. Kernel връща статус, ти го обработваш.

Архитектурата на сървъра

ymawky използва класически fork-on-request:

1. Създай socket и bind на порт
2. Listen за връзки
3. За всяка – fork в нов процес
4. Обработи HTTP в изолирания процес

Защо fork?

• Изолация на паметта
• Просто мислене и код
• Лесно възстановяване

Минусите?

• Голям разход на памет
• Слаба конкурентност спрямо nginx
• Context switching боли под натоварване
• Не тича хиляди връзки

Не е ефективно, но в assembly е разбираемо. Това е целта.

Какво става при заявка

Обработката на заявки решава проблеми, които фреймуърците не показват:

• Тип заявка: Различи GET, POST, DELETE от байтове
• Път: Извлечи file path
• URL декодиране: %20 в space, с edge cases
• Блокиране на traversal: Няма ../../../etc/passwd
• Хедъри: Парс на клиентски полета
• Range: Байтове за големи файлове
• Директории: HTML за списък
• Грешки: Собствени 404 страници

В Python – три реда. В assembly – мини проекти с регистри, стрингове без функции и грешки.

Защо е важно за днешните разработчици

Никога няма да пишеш assembly на производство. Но ymawky показва: всеки abstraction крие сложност.

Фреймуъркът решава проблеми, които някой е разбрал дълбоко. Ако ги знаеш – ставаш по-добър инженер.

Като готвене от нулата. Не правиш собствена брашно, но веднъж го направиш – цениш готовото.

Свързаният с NameOcean свят

В NameOcean работим през всички слоеве – от DNS и domain management до cloud. Разбиране на kernel, протоколи без абстракции и edge cases помага за по-добри решения.

Дали deploy на нашия cloud hosting, DNS за domain или SSL handshake на байтово ниво – системното мислене е ключово. Затова учим как работи, не само как се ползва.

Заключение

ymawky няма да свали nginx. Но напомня: най-непрактичните проекти учат най-много. Унижение пред труда в инструментите ни. Яснота за хардуера без посредници.

Ако се чудиш какво става под капака на уеб сървъра, ymawky е жесток, но ясен отговор.