Web Sunucuları Kodlamanın Derinliklerine: Assembly Dilinin Gizli Dünyası
Assembly ile Web Sunucusu: Sistem Programlaması Yolculuğu
"İşin nasıl yapıldığını bilmek" diye bir söz vardır. Ama ya siz taş bıçakla kendi elinizle hayvan kesmeye karar verseniz? İşte ymawky projesi tam olarak böyle bir şey—ARM64 assembly dilinde, hiçbir kütüphane yardımı olmadan, tamamen sıfırdan yazılmış, macOS'te çalışan gerçek bir HTTP sunucusu.
Neden Biri Bunu Yapıyor?
Açıkçası söyleyelim: nginx'i assembly ile değiştireceğimiz bir gün gelecek değil. Ama işin ilginç yanı, 1950'lerden beri yazılım geliştirmeyi kolaylaştıran bütün araçları bir kenara bırakıp web sunucusu yazmayı denemiş olmak. Böyle bir proje gerçekten neyi öğretiyor?
ymawky'nin yaratıcısı açıkça söylüyor: düşük seviye sistemlerle çalıştığı halde, web sunucularının aslında nasıl çalıştığını anlamıyormuş. Gerçek riskler neler? Çözmesi gereken sorunlar hangileri? Python ya da C'de yazarken gizli kalan şeyler neler?
Herkesin düşünmeden nginx containerı kullandığı bir dünyada, en temel seviyede neler olup bittiğini anlamak değerli bir bilgi.
Assembly: Güzel ve Gaddar
Assembly, ham makine kodu ile insan anlayışı arasındaki dar bir çizgide duruyor. mov x16, #5 yazarken sihirli bir şey çağırmıyorsunuz—5 sayısını doğrudan CPU'nun x16 registerına taşıyorsunuz. Bu sayı Darwin sisteminde open() fonksiyonuna karşılık geliyor.
Assembly'i hem zorlu hem de öğretici yapan şey budur:
Zorluklar:
- Bellekte otomatik temizlik yok
- Stringler sadece sıralı bayt dizileri, tür güvenliği yok
- Yapılar manuel hesaplamalarla tanımlanır—bir bayt hatalı olsa garbage okuyorsunuz
- Her hata durumu CPU flagları üzerinden elle yönetilir
- Bir yazım hatası hiç uyarı gelmeden sistemi çökertiyor
Avantajlar:
- Her CPU komutunu görebilirsiniz
- Gizli operasyonlar ya da beklenmedik bellek tahsisleri yok
- Donanım tam olarak ne yaptığını bilirsiniz
- Performans davranışları şeffaf ve tahmin edilebilir
Assembly'de web sunucusu yazarken, HTTP parsing kütüphanesi yoktur. İsteği bayt bayt sıfırdan yazmakla uğraşırsınız. Bu bayt seviyesi çalışma, yanlış formatlanmış girdileri, encoding problemlerini ve yüksek seviye framework'lerin sessizce çözdüğü güvenlik meselelerini düşünmeye zorlayır.
Ham Syscalllar: Koruma Bariyeri Yok
Çoğu C programı libc'yi kernel syscallları ile kullanıcı kodu arasında dostane bir aracı olarak kullanır. ymawky bunu tamamen atlar:
mov x16, #5 ; SYS_open syscall numarası
adrp x0, dosya@PAGE
add x0, x0, dosya@PAGEOFF
mov x1, #0x0 ; O_RDONLY
svc #0x80 ; kerneli çağır
b.cs acik_hata ; carry flag ayarlandıysa dallan
Parametreleri registerlar içine koyar, kernel'i svc #0x80 ile çağırır, sonra CPU'nun carry flagını kontrol ederek başarılı olup olmadığını anlar. İstisna yönetimi falan yok—sadece flag kontrolü ve hata işleyicilerine dallanma.
Bu hem daha kırılgan hem de daha dürüst. Syscallları exception handling'e sarılı güvenli işlemler gibi göstermüyorsunuz. Gerçekle yüzleşiyorsunuz: kernel bir durum döndürüyor, bunu ele almak sizin sorumluluğunuz.
Web Sunucusu Mimarisi
ymawky klasik fork-on-request modelini uyguluyor:
- Socket açıp bir porta bağla
- Gelen bağlantıları dinle
- Yeni her bağlantı için fork() ile yeni process oluştur
- O process'te HTTP isteğini işle
Neden fork-on-request?
- İstekler arasında bellek izolasyonu
- Daha basit akıl yürütme ve kod yapısı
- Hata kurtarması daha kolay
Ödünleşmeler?
- Yüksek bellek maliyeti (her fork bütün process'i çoğaltır)
- nginx gibi event-driven sistemlere kıyasla zayıf eşzamanlılık
- Context switching yük altında darboğaz olur
- Binlerce eş zamanlı bağlantıya ölçeklenemiyor
Daha az verimli ama assembly'de anlaşılması kolay. İşte bu önemli.
İstekte Neler Oluyor
İstek işleme pipeline'ı kurmak, framework'lerde hiç karşılaşmayacağınız sorunları çözmek demek:
- İstek türünü belirlemek: GET, HEAD, POST, PUT, DELETE, OPTIONS'ı raw baytlardan ayırıştırmak
- Yolunu çekmek: HTTP istekinden istenen dosya yolunu almak
- URL decode etmek: %20'yi boşluğa dönüştürmek ve kenar durumları yönetmek
- Path traversal engelleme:
../../../etc/passwdtarzı oyunları önlemek - Header parsing: İstemcinin her header alanını anlamak
- Range istekleri: Büyük dosyalar için bayt aralığı indirmeleri desteklemek
- Klasör listesi: Folder browsing için HTML oluşturmak
- Özel hata sayfaları: 404 ve diğer hatalar için anlamlı yanıtlar vermek
Her biri Python ya da JavaScript'te basittir. Assembly'de her biri, register yönetimi, built-in metot olmayan string işlemi ve açık hata yönetimi gerektiren küçük bir proje.
Modern Geliştiriciler İçin Neden Önemli?
Asla assembly yazmazsınız. Muhtemelen production web sunucusu da yazmamalısınız. Ama ymawky'nin kodunu incelemek size fundamental bir şey öğretiyor: her soyutlama bir yerlerde karmaşıklık gizler.
HTTP parsing'i otomatik olarak yapan bir framework kullandığınızda, bu sorunları yeterince iyi anlayan ve doğru çözen birine güveniyorsunuz. Bu sorunları kendiniz anlamak—hatta çözmemiş olsanız bile—sizi daha iyi bir mühendis yapıyor.
Tıpkı sıfırdan yemek yapmak gibi. Ununu ve tuzu evde yapmıyorsunuz çünkü daha kötü. Ama ara sıra yapıyorsunuz çünkü prosesi anlamak, satın aldığınız ürünleri daha iyi kullanmanızı sağlıyor.
NameOcean Perspektifi
NameOcean'da stack'in farklı seviyelerinde çalışıyoruz—DNS çözünürlüğünden domain yönetimine, bulut altyapısına kadar. Sistemlerin kernel seviyesinde nasıl çalıştığını, protokollerin soyutlamalar olmadan nasıl işlediğini, ham syscall seviyesinde kenar durumlarını nasıl ele alacağını anlamak, altyapı kararlarında etkilidir.
Hosting platformumuzda dağıtım yapar, domain'inizin DNS ayarlarını yapılandırır ya da SSL anlaşmalarını bayt seviyesinde anlarsanız, bu sistem-level düşünme önemli olur. İşte bu yüzden araçları sadece nasıl kullanacağını değil, aslında nasıl çalıştığını anlamaya yatırım yapıyoruz.
Sonuç
ymawky muhtemelen nginx'in yerini almayacak. Ama bazen en pratik olmayan projeler en çok öğreten şeyler olduğunu gözlememizi sağlıyor. Günlük kullandığımız araçların arkasında ne kadar emek olduğunu fark etmek ve donanımın aracılar olmadan tam olarak ne yaptığını görmek—işte bu değerlidir.
Web sunucunuz bir isteği işlerken arka planda neler olup bittiğini merak ettiyseniz, ymawky gaddar ama aydınlatıcı bir cevap sunuyor.