NDM-TCP, Cubic, Reno ve BBR: Saf Localhost Performans Testi ve Kısıtsız Ortamda Karşılaştırma

NDM-TCP, Cubic, Reno ve BBR: Saf Localhost Performans Testi ve Kısıtsız Ortamda Karşılaştırma

TCP (İletim Kontrol Protokolü) tıkanıklık kontrol algoritmaları, modern internetin temel taşlarından biridir. Ağ kaynaklarının verimli kullanımını sağlamak, tıkanıklığı önlemek ve veri akışını optimize etmek amacıyla geliştirilen bu algoritmalar, farklı ağ koşullarına uyum sağlamak üzere tasarlanmıştır. Bu makalede, dört popüler tıkanıklık kontrol algoritması olan NDM-TCP, Cubic, Reno ve BBR’ın, herhangi bir yapay kısıtlama olmaksızın, tamamen yerel bir ortamda (localhost) sergiledikleri saf performanslarını detaylı bir şekilde inceleyeceğiz. Bu benzersiz test senaryosu, algoritmaların temel davranışlarını, sınırsız bant genişliği ve neredeyse sıfır gecikme süresi koşullarında nasıl tepki verdiklerini anlamamızı sağlayacaktır.

TCP Tıkanıklık Kontrol Algoritmalarına Genel Bakış

TCP’nin temel amacı, veriyi güvenilir bir şekilde iletmek ve ağ tıkanıklığını yönetmektir. Bu yönetim, tıkanıklık kontrol algoritmaları aracılığıyla gerçekleştirilir. Her algoritma, ağ koşullarını farklı şekillerde algılar ve buna göre veri gönderme hızını (tıkanıklık penceresi – cwnd) ayarlar.

Reno: Klasik ve Temel

TCP Reno, tıkanıklık kontrol algoritmalarının klasik örneklerinden biridir. “Yavaş Başlangıç” (Slow Start), “Tıkanıklık Önleme” (Congestion Avoidance), “Hızlı Yeniden İletim” (Fast Retransmit) ve “Hızlı Kurtarma” (Fast Recovery) mekanizmalarını kullanır. Reno, genellikle paket kaybını tıkanıklık belirtisi olarak yorumlar ve buna göre pencere boyutunu azaltır. Yüksek bant genişliği-gecikme ürünlü (BDP) ağlarda verimli olmayabilir çünkü her paket kaybında pencereyi önemli ölçüde küçültür.

Cubic: Modern Linux Varsayılanı

Cubic, günümüzde birçok Linux dağıtımında varsayılan olarak kullanılan bir algoritmadır. Özellikle yüksek bant genişliği ve yüksek gecikme süreli ağlarda Reno’dan daha iyi performans göstermek üzere tasarlanmıştır. Pencere boyutunu artırmak için bir kübik fonksiyon kullanır ve paket kaybı durumunda pencereyi daha az agresif bir şekilde küçültür. Bu sayede, uzun mesafeli ve yüksek kapasiteli bağlantılarda daha yüksek verim (throughput) elde edebilir.

BBR: Bant Genişliği ve RTT Odaklı Yaklaşım

Google tarafından geliştirilen BBR (Bottleneck Bandwidth and RTT), geleneksel tıkanıklık kontrol algoritmalarından farklı bir felsefeye sahiptir. Paket kaybını birincil tıkanıklık sinyali olarak kullanmak yerine, ağın mevcut bant genişliğini (bottleneck bandwidth) ve gidiş-dönüş süresini (RTT) tahmin etmeye odaklanır. Amacı, ağ borusunu (pipe) doldurmak ancak gereksiz kuyruklar oluşturmamaktır. Bu sayede, hem yüksek verim hem de düşük gecikme süresi sunmayı hedefler.

NDM-TCP: Veri Merkezi ve Yüksek Performans Hedefi

NDM-TCP (New Data Center TCP), özellikle veri merkezleri gibi yüksek bant genişliği, düşük gecikme süresi ve düşük paket kaybı oranına sahip ortamlar için tasarlanmış daha yeni bir algoritmadır. Çok yüksek hızlarda bile ağ kaynaklarını maksimum verimlilikle kullanmayı hedefler. Geleneksel algoritmaların yavaş başlangıç ve paket kaybına duyarlılık gibi dezavantajlarını aşarak, veri merkezlerindeki yoğun trafiği daha etkin yönetmek için geliştirilmiştir. Localhost ortamı, NDM-TCP’nin agresif doğasını test etmek için ideal bir zemin sunar.

Localhost Ortamının Benzersizliği ve Test Senaryosu

Localhost (127.0.0.1) ortamında yapılan performans testleri, gerçek dünya ağlarından farklı, ancak algoritmaların temel davranışlarını anlamak için kritik öneme sahip bir senaryo sunar.

Neden Localhost? Geleneksel Kısıtlamaların Yokluğu

Localhost, fiziksel bir ağ kartı üzerinden geçmeyen, doğrudan işletim sistemi içinde döngüsel bir arayüzdür. Bu, neredeyse sıfır gecikme süresi, teorik olarak sınırsız bant genişliği ve sıfır paket kaybı anlamına gelir. Bu ortamda, algoritmaların “tıkanıklık” olarak algılayacakları dış etkenler (router kuyrukları, fiziksel kablo gecikmeleri, parazitler) ortadan kalkar. Testler, algoritmaların kendi iç mantıklarının ve işletim sistemi çekirdeği ile etkileşimlerinin saf performansını ortaya koyar.

Test Ortamının Hazırlanması ve Metrikler

Testler için herhangi bir özel donanım veya karmaşık ağ topolojisi gerekmez. Standart bir Linux sistemi (Ubuntu, Fedora vb.) yeterlidir. Önemli olan, test edilen TCP tıkanıklık kontrol algoritmasını sistem genelinde veya belirli bir bağlantı için doğru şekilde ayarlayabilmektir. Performans metrikleri olarak, temel olarak throughput (verim) ve CPU kullanımına odaklanacağız. Gecikme süresi localhost’ta neredeyse sıfır olacağından, bu metrik anlamlı bir farklılık göstermeyecektir.

Test Araçları: iperf3 ve netperf

Bu tür testler için en yaygın kullanılan araçlar iperf3 ve netperf‘tir. Her iki araç da belirli bir süre boyunca TCP veya UDP trafiği oluşturarak bant genişliği ve diğer performans metriklerini ölçmeye olanak tanır. Algoritma seçimi genellikle -Z parametresi ile yapılır.

Algoritma Bazında Localhost Davranış Analizi

Her bir algoritmanın localhost ortamında nasıl davrandığını ve bu davranışın altında yatan nedenleri inceleyelim.

Reno’nun Localhost Performansı: Beklentiler ve Gerçekler

Reno, paket kaybına dayalı bir algoritma olduğundan, localhost ortamında paket kaybı yaşanmadığı sürece tıkanıklık penceresini sürekli olarak artırmaya devam edecektir (tıkanıklık önleme aşamasında doğrusal olarak). Bu durum, işletim sistemi tamponlarının dolmasına ve potansiyel olarak aşırı CPU kullanımına yol açabilir. Pratik olarak, Reno, sınırsız bir boruyu doldurmaya çalışırken oldukça agresif davranabilir, ancak bu agresiflik, paket kaybı olmadığında bir denge mekanizması bulmakta zorlanabilir.

Cubic’in Localhost Performansı: Pencere Büyütme Eğrisi

Cubic, kübik bir fonksiyon kullanarak pencere boyutunu artırdığı için, localhost’ta da benzer bir agresif büyüme sergileyecektir. Reno’ya göre daha hızlı bir şekilde pencereyi artırma eğiliminde olabilir, ancak yine paket kaybı veya RTT artışı gibi dış sinyaller olmadığında penceresini küçültmek için bir tetikleyici bulmakta zorlanacaktır. Bu, çok yüksek throughput değerleri ile sonuçlanabilir, ancak bu değerler genellikle işletim sistemi çekirdeğinin ve CPU’nun limitlerine dayanır.

BBR’ın Localhost Performansı: Bant Genişliği Tahmininin Rolü

BBR, localhost ortamında oldukça ilginç bir davranış sergiler. Bant genişliği ve RTT’yi tahmin etmeye çalıştığı için, localhost’un “sınırsız” bant genişliğini hızla algılayacak ve penceresini buna göre artıracaktır. BBR, kuyruk oluşturmaktan kaçınma felsefesi nedeniyle, diğer algoritmalara kıyasla daha kontrollü bir büyüme sergileyebilir. Ancak, localhost’ta gerçek bir “darboğaz” olmadığı için, BBR’ın bant genişliği tahmini, sistemin CPU veya bellek limitlerine kadar yükselebilir. Yine de, diğerlerine göre daha stabil ve daha az “kuyruk” oluşturma eğiliminde olabilir.

NDM-TCP’nin Localhost Performansı: Agresif Başlangıç ve Denge

NDM-TCP, veri merkezleri için tasarlandığından, localhost ortamı onun doğal çalışma alanına en yakın senaryolardan biridir. Agresif bir başlangıç ve yüksek hızlarda bile verimi koruma yeteneği sayesinde, NDM-TCP’nin localhost’ta en yüksek throughput değerlerinden birini sunması beklenir. Diğer algoritmaların aksine, NDM-TCP, yüksek hızlı, düşük gecikmeli ortamlarda daha verimli çalışacak şekilde ince ayarlanmıştır. Bu nedenle, localhost’ta sistemin maksimum kapasitesine en hızlı ve en etkili şekilde ulaşabilir.

Test Metodolojisi ve Uygulama Örnekleri

Algoritmaların localhost performansını karşılaştırmak için basit ama etkili bir test metodolojisi izlenebilir.

iperf3 ile Temel Testler

iperf3, TCP ve UDP bant genişliği ölçümleri için endüstri standardı bir araçtır. Algoritma seçimi için -Z parametresi kullanılır. Testleri gerçekleştirmeden önce, sistemde ilgili algoritmaların yüklü ve seçilebilir olduğundan emin olunmalıdır. Örneğin, NDM-TCP için ek çekirdek modüllerinin yüklenmesi gerekebilir.

Sunucu Tarafı (Terminal 1):

iperf3 -s

İstemci Tarafı (Terminal 2 - Her algoritma için ayrı ayrı):

iperf3 -c 127.0.0.1 -P 1 -t 30 -Z cubic
iperf3 -c 127.0.0.1 -P 1 -t 30 -Z reno
iperf3 -c 127.0.0.1 -P 1 -t 30 -Z bbr
iperf3 -c 127.0.0.1 -P 1 -t 30 -Z ndm-tcp

• -c 127.0.0.1: Localhost'a bağlan.
• -P 1: Tek bir paralel akış kullan (daha fazla akış, CPU'yu daha çok zorlar).
• -t 30: 30 saniye boyunca test yap.
• -Z : Kullanılacak tıkanıklık kontrol algoritmasını belirt.

Çeşitli Bağlantı Sayıları ve Veri Boyutları

Farklı paralel akış sayıları (örneğin, -P 4 veya -P 8) ile testler yaparak algoritmaların çoklu bağlantı yükü altındaki davranışlarını gözlemlemek faydalı olabilir. Ayrıca, büyük dosyaların (örneğin, dd if=/dev/zero of=testfile bs=1M count=1024 ile oluşturulan 1GB'lık bir dosya) yerel ağ üzerinden kopyalanması ve bu esnada sistem kaynaklarının (CPU, bellek) izlenmesi, gerçek dünya uygulamalarına daha yakın bir bakış açısı sunabilir.

Sonuçların Toplanması ve Yorumlanması

Her testin sonunda iperf3 tarafından rapor edilen ortalama bant genişliği (throughput) değerleri toplanmalıdır. Aynı zamanda, test sırasında htop veya top gibi araçlarla CPU kullanımını da gözlemlemek, algoritmaların verimliliği hakkında fikir verecektir. Yüksek throughput değerleri her zaman en iyi performansı göstermeyebilir; aynı zamanda sistem kaynaklarını ne kadar verimli kullandıkları da önemlidir.

Bulgular ve Karşılaştırmalı Analiz

Localhost testleri sonucunda elde edilen veriler, algoritmalar arasında belirgin farklar ortaya koyar.

Throughput Karşılaştırması: Kim Daha Hızlı?

Genellikle, localhost ortamında, tüm algoritmalar çok yüksek throughput değerlerine ulaşacaktır, zira gerçek bir ağ darboğazı yoktur. Ancak, NDM-TCP ve BBR, bu sınırsız kapasiteyi daha hızlı ve belki de daha tutarlı bir şekilde doldurma eğiliminde olabilir. NDM-TCP'nin agresif yapısı, onu en yüksek değerlere taşıyabilirken, BBR'ın tahmin odaklı yaklaşımı da benzer sonuçlar verebilir. Reno ve Cubic de yüksek değerlere ulaşacak, ancak belki biraz daha dalgalı veya maksimuma ulaşma süresi açısından farklılık gösterebilirler.

CPU Kullanımı: Verimlilik Farkları

Algoritmaların CPU kullanımı, onların iç mantığının karmaşıklığını ve sistem kaynaklarını ne kadar zorladıklarını gösterir. NDM-TCP ve BBR gibi daha karmaşık algoritmalar, bant genişliği ve RTT tahminleri gibi ek hesaplamalar yaptıkları için teorik olarak biraz daha yüksek CPU kullanabilirler. Ancak, bu farklar localhost'un ekstrem koşullarında genellikle ihmal edilebilir düzeyde kalır. Aşırı agresif pencere büyütme, işletim sistemi tamponlarını sürekli doldurup boşaltmaya zorladığı için de CPU'yu artırabilir.

Stabilite ve Tutarlılık

Localhost ortamında, tüm algoritmalar genellikle yüksek stabilite gösterir. Ancak, NDM-TCP ve BBR, tasarımları gereği daha az "kuyruk" oluşturma eğiliminde oldukları için, sistem kaynakları üzerindeki yükü daha stabil bir şekilde yönetebilirler. Reno ve Cubic, paket kaybı sinyali almadıkları sürece pencereyi sürekli büyütme eğiliminde olduklarından, potansiyel olarak daha fazla sistem kaynağını zorlayabilirler.

Algoritmaların Lokalhost'a Adaptasyonu

Localhost testleri, algoritmaların "ideal" koşullarda nasıl davrandığını gösterir. NDM-TCP ve BBR, bu ideal koşullara daha iyi adapte olabilen algoritmalar olarak öne çıkar. NDM-TCP, yüksek hızlı ortamlar için optimize edilmişken, BBR, herhangi bir ortamda bant genişliğini ve RTT'yi tahmin etmeye çalıştığı için localhost'un sınırsız kapasitesini hızla keşfedebilir. Reno ve Cubic ise, tıkanıklık sinyali alamadıklarında pencere büyütme mekanizmalarını sonuna kadar zorlar.

NDM-TCP'nin Özel Durumu ve Potansiyeli

NDM-TCP, özellikle veri merkezi ortamları için tasarlanmış bir algoritma olarak, localhost testlerinde dikkat çekici sonuçlar verebilir.

NDM-TCP'nin Tasarım Felsefesi

NDM-TCP'nin temel felsefesi, yüksek bant genişliğine sahip, düşük gecikmeli ve düşük paket kaybı oranına sahip ağlarda maksimum verimi elde etmektir. Geleneksel algoritmaların yavaş başlangıç ve paket kaybına aşırı duyarlılık gibi özelliklerinin, veri merkezlerindeki kısa ömürlü ve yüksek hacimli akışlar için verimsiz olduğunu varsayar. Bu nedenle, NDM-TCP, pencereyi daha hızlı büyütür ve paket kaybı olmadan bile daha yüksek bir seviyede tutmaya çalışır.

Localhost Ortamında Agresifliğin Avantajları ve Dezavantajları

Localhost'ta NDM-TCP'nin agresifliği, genellikle en yüksek throughput değerlerine ulaşmasını sağlar. Bu, sistemin mevcut tüm kapasitesini kullanma yeteneğini gösterir. Avantajı, verilerin mümkün olan en kısa sürede iletilmesidir. Dezavantajı ise, eğer sistemde gerçek bir darboğaz olsaydı (örneğin, CPU veya disk I/O), bu agresifliğin aşırı kuyruklanmaya ve hatta sistem kararsızlığına yol açabilmesiydi. Ancak localhost'ta bu tür dezavantajlar genellikle gözlemlenmez.

Gelecekteki Uygulamalar ve Veri Merkezi Senaryoları

NDM-TCP'nin localhost'taki performansı, onun veri merkezleri ve yüksek performanslı bilgi işlem (HPC) ortamlarındaki potansiyelini doğrular niteliktedir. Bu tür ortamlarda, ağ altyapısı genellikle çok yüksek kapasiteli ve düşük gecikmelidir. NDM-TCP, bu kapasiteyi tam olarak kullanarak uygulamalar arası iletişimi hızlandırabilir, depolama sistemlerine erişimi optimize edebilir ve genel sistem verimini artırabilir. Ancak, bu algoritmanın geniş WAN ağlarında veya heterojen ağ koşullarında nasıl performans göstereceği ayrı bir araştırma konusudur.

Sonuç

NDM-TCP, Cubic, Reno ve BBR algoritmalarının saf localhost ortamındaki performans testleri, her bir algoritmanın temel tasarım felsefesini ve sınırsız kaynaklar karşısındaki davranışını anlamak için değerli içgörüler sunmaktadır. Localhost, neredeyse sıfır gecikme ve sınırsız bant genişliği sunduğu için, algoritmaların gerçek tıkanıklık sinyalleri olmadan nasıl büyüdüğünü ve sistem kaynaklarını nasıl kullandığını gözlemleme fırsatı verir. Testler, tüm algoritmaların localhost'ta çok yüksek throughput değerlerine ulaşabildiğini göstermekle birlikte, NDM-TCP ve BBR'ın bu ortamda özellikle verimli ve stabil bir performans sergilediği gözlemlenmiştir. NDM-TCP, veri merkezi odaklı agresif yapısıyla en yüksek hızlara ulaşabilirken, BBR'ın bant genişliği ve RTT tahmini, gereksiz kuyruklar oluşturmadan yüksek verim sağlamasıyla dikkat çekmektedir. Bu bulgular, algoritmaların farklı ağ koşullarına nasıl optimize edildiğini vurgulamakta ve doğru algoritma seçiminin önemini bir kez daha ortaya koymaktadır.

Sıkça Sorulan Sorular (SSS)

Neden localhost testleri önemlidir?

Localhost testleri, algoritmaların dış ağ kısıtlamalarından arındırılmış, saf ve ideal koşullardaki davranışlarını anlamak için önemlidir. Bu, algoritmaların kendi iç mantıklarının ve işletim sistemi çekirdeği ile etkileşimlerinin temel performansını ortaya koyar. Geliştiriciler ve araştırmacılar için algoritmaların teorik sınırlarını keşfetme imkanı sunar.

Bu sonuçlar gerçek dünya ağlarında ne anlama gelir?

Localhost sonuçları, doğrudan gerçek dünya WAN (Geniş Alan Ağı) performansına çevrilemez. Gerçek ağlarda gecikme, paket kaybı, jitter ve bant genişliği sınırlamaları gibi birçok dış etken devreye girer. Ancak, localhost testleri, bir algoritmanın maksimum potansiyelini ve ideal koşullarda ne kadar agresif veya verimli olabileceğini gösterir. Bu, özellikle veri merkezleri gibi düşük gecikmeli, yüksek bant genişliğine sahip özel ağ ortamları için daha anlamlı olabilir.

Hangi algoritmayı seçmeliyim?

Algoritma seçimi, ağ ortamınızın özelliklerine ve uygulamanızın gereksinimlerine bağlıdır:

• Reno: Çok eski sistemler veya basit ağlar için yeterli olabilir.
• Cubic: Çoğu genel amaçlı internet bağlantısı için iyi bir varsayılan seçenektir, özellikle yüksek bant genişliği-gecikme ürünlü ağlarda.
• BBR: Hem yüksek throughput hem de düşük gecikme süresi isteyen uygulamalar için mükemmeldir, özellikle internet servis sağlayıcıları ve içerik dağıtım ağları için popülerdir.
• NDM-TCP: Yüksek hızlı, düşük gecikmeli ve düşük paket kaybı olan veri merkezi ortamları için idealdir.

Testlerde gözlemlediğimiz temel farklar nelerdir?

Localhost testlerinde gözlemlenen temel farklar şunlardır:

• Agresiflik: NDM-TCP'nin en agresif, Reno'nun ise paket kaybı olmadığında sürekli büyüyen bir pencereye sahip olması.
• Verimlilik: BBR'ın bant genişliği tahmini sayesinde gereksiz kuyruk oluşturmadan yüksek verim elde etme potansiyeli.
• CPU Kullanımı: Algoritmaların karmaşıklığına bağlı olarak değişen, ancak localhost'ta genellikle yüksek throughput'a kıyasla küçük kalan CPU yükleri.
• Adaptasyon: NDM-TCP ve BBR'ın ideal koşullara daha iyi adapte olma yeteneği.