Kenar katmanı: uygulamandan önceki son karar noktası
Ters vekil sunucu çoğu projede kopyalanıp yapıştırılan bir dosya. Ama iki farklı protokolü aynı porttan servis etmeye başlayınca, o dosyadaki her satırın bir sebebi olması gerekiyor.
Kenar katmanı, çoğu projede internetten kopyalanmış bir yapılandırma dosyası olarak yaşıyor. Çalışıyor, kimse dokunmuyor, ne yaptığı tam bilinmiyor.
Xaron'da bu lüksümüz olmadı — çünkü kenarda iki farklı protokol duruyor. Normal HTTP trafiği TCP üzerinden, gerçek zamanlı taşıma ise QUIC üzerinden, yani UDP'den. Aynı port numarası, iki farklı aktarım katmanı.
Bu, kenarı "trafiği arkaya at" kutusu olmaktan çıkarıp gerçek bir karar noktası hâline getirdi.
İki protokol, tek adres
QUIC'in UDP kullanması pratikte şu anlama geliyor: kenar sunucunun TCP 443'ü de UDP 443'ü de dinlemesi ve ikisini farklı arka uçlara yönlendirmesi gerekiyor.
Buradaki ilk tuzak sertifikalar. İki yol da geçerli bir sertifika istiyor ve gerçek zamanlı taşıma tarafında istemci uç sertifikanın parmak izini sabitliyor. Yani sertifika yenilendiğinde istemcinin beklediği parmak izi de değişiyor. Bu, otomatik yenilemeyi "kur ve unut" olmaktan çıkarıp koordine edilmesi gereken bir işe dönüştürüyor.
İkinci tuzak, sertifika olmadan üretimin açılmaması. Bunu bilinçli olarak sert bıraktık: eksik sertifikayla ayağa kalkan bir sunucu, sessizce güvensiz çalışan bir sunucu. Açılmaması daha iyi.
Kenar neyi bilmeli
Asıl karar şu: kenara ne kadar akıl koyacaksın?
Cazip olan şey her şeyi oraya taşımak. Kimlik doğrulaması, yönlendirme mantığı, başlık düzenlemeleri, yeniden yazma kuralları. Sonunda uygulamanın davranışının yarısı, sürüm kontrolünde bile olmayan bir yapılandırma dosyasında yaşıyor.
Bizde kural şu oldu: kenar kimin ne yapabileceğine karar vermiyor. Kenarın işi TLS'i sonlandırmak, protokolü doğru arka uca yöneltmek, kaba bir taşkın koruması uygulamak, gövde boyutunu sınırlamak ve zaman aşımlarını dayatmak.
Yetki kararı uygulamada. Çünkü yetki kuralı kodla birlikte sürümleniyor, testi var, incelemeden geçiyor. Yapılandırma dosyası için bunların hiçbiri geçerli değil.
Kenara koyduğun her mantık, testi olmayan koddur.
Zaman aşımı bir savunma aracı
Kenarın en az konuşulan ama en çok işe yarayan ayarı zaman aşımları.
Yavaş bir istemci, bağlantıyı açıp veriyi damla damla göndererek arka uçtaki bir işçiyi dakikalarca meşgul edebiliyor. Yüz tane böyle bağlantı, hiçbir uyarı üretmeden kapasitenin tamamını yiyor. Bu bir saldırı olabilir, ama çoğu zaman sadece kötü bir mobil bağlantı.
Okuma zaman aşımı, yazma zaman aşımı, boşta kalma süresi ve gövde boyutu sınırı — bunlar kenarın arka ucu koruduğu asıl yerler. Ve bir de şu: bu sınırlar aynı zamanda ürünün ne kabul ettiğini yazılı hâle getiriyor. Yüklenebilecek en büyük dosya boyutu bir ürün kararı, ama uygulanan yer kenar.
Neyi ölçüyorsun
Son parça: kenar, gerçekten ne olduğunu gördüğün tek yer.
Uygulama günlükleri sadece uygulamaya ulaşan istekleri görüyor. Reddedilenler, zaman aşımına uğrayanlar, TLS el sıkışmasında düşenler oraya hiç varmıyor. Bir kullanıcı "bağlanamıyorum" dediğinde cevabın çoğu zaman kenar metriklerinde duruyor.
Özellikle QUIC tarafında bu kritik. Bir kullanıcının ağı UDP 443'ü filtreliyorsa, uygulama tarafında hiçbir iz kalmıyor — bağlantı hiç kurulmuyor. Bunu yalnızca kenarda, kurulamayan oturumları sayarak görebiliyorsun.
Ve o sayı, transport yazısında anlattığım kararın gerçek maliyetini ölçtüğüm tek rakam. Fallback yazmamayı savunmanın koşulu, kaç kişinin bağlanamadığını biliyor olmak.