24 Temmuz 2026 — Eren'in Mühendislik Gazetesi

İnternetin yolları neden beklendiği gibi çalışmıyor: BGP ORIGIN bulgusu

BGP ORIGIN attribute manipulation and its impact on the Internet · Iliana Xygkou, Bryton Herdes

BGP (Border Gateway Protocol) internetin fiili yönlendirme protokolü. Otonom Sistemler (AS) — yani internet servis sağlayıcıları, bulut sağlayıcıları, büyük şirketler — trafiği nasıl gönderip almak istediklerini bu protokolle ifade eder. Bunun için yol nitelikleri (path attributes) kullanılır; yol seçim algoritması bu nitelikleri belirli bir sırayla işleyip en iyi yolu hesaplar.

Cloudflare bu niteliklerden birine, zorunlu olan ORIGIN'e bakmış. ORIGIN her BGP duyurusunda bulunmak zorunda ve kural şu: onu duyuran yönlendirici bir kez ayarladıktan sonra hiçbir yönlendirici bunu değiştirmemeli.

Bulgu çarpıcı: çok sayıda gözlem noktasında görülen yolların yaklaşık %70'inde ORIGIN değeri, onu duyuran otonom sistemin ayarladığından farklı. Yani spesifikasyonun "değiştirilmemeli" dediği alan, pratikte yaygın olarak değiştiriliyor.

Bunun somut bir sonucu var. BGP yol seçiminde iki yolun Local Preference değeri ve AS_PATH uzunluğu eşitse, yönlendirici daha düşük ORIGIN değerine sahip yolu seçer. Yani sessizce değiştirilen bu alan, trafiğin internette hangi yoldan aktığını doğrudan etkiliyor.

Öne çıkanlar

ORIGIN üç değer alır: IGP (0), EGP (1, artık kullanılmayan eski protokol), INCOMPLETE (2).
Halka açık BGP toplayıcılarında dağılım: %89,8 IGP, %3,5 EGP, %6,7 INCOMPLETE.
Spesifikasyonun "değiştirilmemeli" dediği bir alanın %70 oranında değiştirilmesi, standart ile pratik arasındaki mesafenin iyi bir örneği.
Etki teorik değil: eşitlik durumunda yol seçimini bu alan belirliyor.

Neden önemli?

Bu yazı bir mühendislik alışkanlığı öğretiyor: spesifikasyonun ne dediğine değil, sistemin ne yaptığına bak. Cloudflare'in avantajı özel bir zekâ değil, ölçüm yapabildiği bir konum — internetin geniş bir kesitini görebiliyorlar ve bu kesite bakmayı akıl ettiler. Kendi sistemlerinde de en değerli bulgular genelde "herkesin doğru varsaydığı şeyi ölçtüm" cümlesiyle başlar.

Sende karşılığı

Doğrudan BGP ile çalışmayacaksın, ama iki şey işine yarar. Birincisi kavram: internet trafiğinin yolu tek bir otoritenin kararı değil, binlerce bağımsız sistemin tercihlerinin bileşimi — "neden bu sunucuya gecikme yüksek?" sorusunun cevabı bazen senin kodunda değil burada. İkincisi yöntem: Tradebot'ta bir varsayımın ("borsa verisi her zaman sıralı gelir", "timestamp'ler hep artan") doğru olduğunu test etmeden kabul ediyorsan, Cloudflare'in yaptığını küçük ölçekte yap — ölç ve dağılıma bak. Sistemlerdeki en pahalı hatalar, doğrulanmamış varsayımlardan çıkar.

Sözlük

BGP (Border Gateway Protocol) sınır ağ geçidi protokolü: İnternetteki bağımsız ağların birbirine hangi yolların üzerinden ulaşılacağını duyurduğu yönlendirme protokolü.
Autonomous System (AS) otonom sistem: Tek bir kurumun yönettiği, kendi yönlendirme politikası olan ağ; internet bunların birleşimidir.
path attribute yol niteliği: Bir BGP duyurusuna eklenen ve yol seçimini etkileyen metadata alanı.

Arşivden Seçmeler

Bugün az yayın çıktı. Bu yazılar daha eski tarihli ama hâlâ öğretici — her birinin gerçek yayın tarihi başlığın üstünde yazıyor.

Arşivden Uber Engineering 7 Mayıs 2026 8 dk ileri

Go'da yığın büyümesini engelleyerek %10 CPU kazanmak

Zero-Growth Stack, Real Gains: How Stack Allocation Can Save 10% CPU in Go

Uber'de servislerin yaklaşık %65'i Go ile çalışıyor ve bu 2 milyondan fazla çekirdeğe denk geliyor. Bu ölçekte genel bir %1 verimlilik iyileşmesi birkaç milyon dolar demek. Yazı bir servisin kullanımını %10 iyileştirmelerini anlatıyor.

Problem Go çalışma zamanının bir takasından geliyor. Goroutine'ler (thread'lerin hafif alternatifi) küçük bir yığınla (stack) başlar — OS thread'lerinden çok daha fazla eşzamanlılık sağlamak için. Ama ayrılan boyut yetmezse Go özel bir kontrol yapar: iki katı büyüklükte yeni bir yığın oluşturur ve eskisinin içeriğini kopyalar (runtime.morestack). Bellek kullanımını düşük tutan bu mekanizma, ölçekte CPU'ya pahalıya patlıyor.

Go 1.19 uyarlanabilir yığın boyutu getirmiş: ortalama yığın kullanımını takip edip başlangıç boyutunu ona göre ayarlıyor. Kısmen iyileştirmiş ama hâlâ pahalı olabiliyor. Uber'in denediği alternatiflerden biri goroutine havuzlama — tek sorumluluğu olan worker havuzlarında çok iyi çalışıyor.

Bellek ile CPU arasındaki takas: küçük başlayan yığın belleği korur ama tekrarlanan genişleme CPU yakar.
Çözüm yığını istenen boyutta önceden ayırmak (preallocation) — tekrarlanan kopyalamayı ortadan kaldırıyor.
Ölçek argümanı net: %1 verimlilik = milyonlarca dolar. Optimizasyonun değeri her zaman ölçeğe bağlı.

Sende karşılığı

Java tarafında bunun birebir karşılığı var ve senin işine daha yakın: JVM'de thread stack boyutu (-Xss), heap boyutu ve GC seçimi de aynı türden varsayılanlardır. Spring Boot uygulaman ölçeklenmeye başladığında "neden bu kadar CPU yiyor?" sorusunun cevabı kodda değil, çalışma zamanı ayarlarında olabilir. Ama yazının asıl dersi sıralama: Uber önce profilledi, sonra optimize etti. Sen de async-profiler ya da JFR ile alev grafiği (flame graph) çıkarmadan hiçbir şeyi optimize etme — tahminle yapılan optimizasyon genelde yanlış yeri düzeltir.

Sözlük

goroutine goroutine: Go'nun hafif eşzamanlılık birimi; işletim sistemi thread'inden çok daha ucuz.
stack growth yığın büyümesi: Fonksiyon çağrı yığını ayrılan alanı aşınca daha büyük bir alan ayrılıp içeriğin kopyalanması.
preallocation önceden ayırma: İhtiyaç duyulacak alanı baştan ayırarak sonradan büyütme maliyetinden kaçınma.
flame graph alev grafiği: CPU zamanının hangi fonksiyonlarda geçtiğini gösteren, profilleme çıktısını görselleştiren grafik.

Orijinali oku