TCP (\u0130letim Kontrol Protokol\u00fc) t\u0131kan\u0131kl\u0131k kontrol algoritmalar\u0131, modern internetin temel ta\u015flar\u0131ndan biridir. A\u011f kaynaklar\u0131n\u0131n verimli kullan\u0131m\u0131n\u0131 sa\u011flamak, t\u0131kan\u0131kl\u0131\u011f\u0131 \u00f6nlemek ve veri ak\u0131\u015f\u0131n\u0131 optimize etmek amac\u0131yla geli\u015ftirilen bu algoritmalar, farkl\u0131 a\u011f ko\u015fullar\u0131na uyum sa\u011flamak \u00fczere tasarlanm\u0131\u015ft\u0131r. Bu makalede, d\u00f6rt pop\u00fcler t\u0131kan\u0131kl\u0131k kontrol algoritmas\u0131 olan NDM-TCP, Cubic, Reno ve BBR’\u0131n, herhangi bir yapay k\u0131s\u0131tlama olmaks\u0131z\u0131n, tamamen yerel bir ortamda (localhost) sergiledikleri saf performanslar\u0131n\u0131 detayl\u0131 bir \u015fekilde inceleyece\u011fiz. Bu benzersiz test senaryosu, algoritmalar\u0131n temel davran\u0131\u015flar\u0131n\u0131, s\u0131n\u0131rs\u0131z bant geni\u015fli\u011fi ve neredeyse s\u0131f\u0131r gecikme s\u00fcresi ko\u015fullar\u0131nda nas\u0131l tepki verdiklerini anlamam\u0131z\u0131 sa\u011flayacakt\u0131r.<\/p>\n
TCP’nin temel amac\u0131, veriyi g\u00fcvenilir bir \u015fekilde iletmek ve a\u011f t\u0131kan\u0131kl\u0131\u011f\u0131n\u0131 y\u00f6netmektir. Bu y\u00f6netim, t\u0131kan\u0131kl\u0131k kontrol algoritmalar\u0131 arac\u0131l\u0131\u011f\u0131yla ger\u00e7ekle\u015ftirilir. Her algoritma, a\u011f ko\u015fullar\u0131n\u0131 farkl\u0131 \u015fekillerde alg\u0131lar ve buna g\u00f6re veri g\u00f6nderme h\u0131z\u0131n\u0131 (t\u0131kan\u0131kl\u0131k penceresi – cwnd) ayarlar.<\/p>\n
TCP Reno, t\u0131kan\u0131kl\u0131k kontrol algoritmalar\u0131n\u0131n klasik \u00f6rneklerinden biridir. “Yava\u015f Ba\u015flang\u0131\u00e7” (Slow Start), “T\u0131kan\u0131kl\u0131k \u00d6nleme” (Congestion Avoidance), “H\u0131zl\u0131 Yeniden \u0130letim” (Fast Retransmit) ve “H\u0131zl\u0131 Kurtarma” (Fast Recovery) mekanizmalar\u0131n\u0131 kullan\u0131r. Reno, genellikle paket kayb\u0131n\u0131 t\u0131kan\u0131kl\u0131k belirtisi olarak yorumlar ve buna g\u00f6re pencere boyutunu azalt\u0131r. Y\u00fcksek bant geni\u015fli\u011fi-gecikme \u00fcr\u00fcnl\u00fc (BDP) a\u011flarda verimli olmayabilir \u00e7\u00fcnk\u00fc her paket kayb\u0131nda pencereyi \u00f6nemli \u00f6l\u00e7\u00fcde k\u00fc\u00e7\u00fclt\u00fcr.<\/p>\n
Cubic, g\u00fcn\u00fcm\u00fczde bir\u00e7ok Linux da\u011f\u0131t\u0131m\u0131nda varsay\u0131lan olarak kullan\u0131lan bir algoritmad\u0131r. \u00d6zellikle y\u00fcksek bant geni\u015fli\u011fi ve y\u00fcksek gecikme s\u00fcreli a\u011flarda Reno’dan daha iyi performans g\u00f6stermek \u00fczere tasarlanm\u0131\u015ft\u0131r. Pencere boyutunu art\u0131rmak i\u00e7in bir k\u00fcbik fonksiyon kullan\u0131r ve paket kayb\u0131 durumunda pencereyi daha az agresif bir \u015fekilde k\u00fc\u00e7\u00fclt\u00fcr. Bu sayede, uzun mesafeli ve y\u00fcksek kapasiteli ba\u011flant\u0131larda daha y\u00fcksek verim (throughput) elde edebilir.<\/p>\n
Google taraf\u0131ndan geli\u015ftirilen BBR (Bottleneck Bandwidth and RTT), geleneksel t\u0131kan\u0131kl\u0131k kontrol algoritmalar\u0131ndan farkl\u0131 bir felsefeye sahiptir. Paket kayb\u0131n\u0131 birincil t\u0131kan\u0131kl\u0131k sinyali olarak kullanmak yerine, a\u011f\u0131n mevcut bant geni\u015fli\u011fini (bottleneck bandwidth) ve gidi\u015f-d\u00f6n\u00fc\u015f s\u00fcresini (RTT) tahmin etmeye odaklan\u0131r. Amac\u0131, a\u011f borusunu (pipe) doldurmak ancak gereksiz kuyruklar olu\u015fturmamakt\u0131r. Bu sayede, hem y\u00fcksek verim hem de d\u00fc\u015f\u00fck gecikme s\u00fcresi sunmay\u0131 hedefler.<\/p>\n
NDM-TCP (New Data Center TCP), \u00f6zellikle veri merkezleri gibi y\u00fcksek bant geni\u015fli\u011fi, d\u00fc\u015f\u00fck gecikme s\u00fcresi ve d\u00fc\u015f\u00fck paket kayb\u0131 oran\u0131na sahip ortamlar i\u00e7in tasarlanm\u0131\u015f daha yeni bir algoritmad\u0131r. \u00c7ok y\u00fcksek h\u0131zlarda bile a\u011f kaynaklar\u0131n\u0131 maksimum verimlilikle kullanmay\u0131 hedefler. Geleneksel algoritmalar\u0131n yava\u015f ba\u015flang\u0131\u00e7 ve paket kayb\u0131na duyarl\u0131l\u0131k gibi dezavantajlar\u0131n\u0131 a\u015farak, veri merkezlerindeki yo\u011fun trafi\u011fi daha etkin y\u00f6netmek i\u00e7in geli\u015ftirilmi\u015ftir. Localhost ortam\u0131, NDM-TCP’nin agresif do\u011fas\u0131n\u0131 test etmek i\u00e7in ideal bir zemin sunar.<\/p>\n
Localhost (127.0.0.1) ortam\u0131nda yap\u0131lan performans testleri, ger\u00e7ek d\u00fcnya a\u011flar\u0131ndan farkl\u0131, ancak algoritmalar\u0131n temel davran\u0131\u015flar\u0131n\u0131 anlamak i\u00e7in kritik \u00f6neme sahip bir senaryo sunar.<\/p>\n
Localhost, fiziksel bir a\u011f kart\u0131 \u00fczerinden ge\u00e7meyen, do\u011frudan i\u015fletim sistemi i\u00e7inde d\u00f6ng\u00fcsel bir aray\u00fczd\u00fcr. Bu, neredeyse s\u0131f\u0131r gecikme s\u00fcresi, teorik olarak s\u0131n\u0131rs\u0131z bant geni\u015fli\u011fi ve s\u0131f\u0131r paket kayb\u0131 anlam\u0131na gelir. Bu ortamda, algoritmalar\u0131n “t\u0131kan\u0131kl\u0131k” olarak alg\u0131layacaklar\u0131 d\u0131\u015f etkenler (router kuyruklar\u0131, fiziksel kablo gecikmeleri, parazitler) ortadan kalkar. Testler, algoritmalar\u0131n kendi i\u00e7 mant\u0131klar\u0131n\u0131n ve i\u015fletim sistemi \u00e7ekirde\u011fi ile etkile\u015fimlerinin saf performans\u0131n\u0131 ortaya koyar.<\/p>\n
Testler i\u00e7in herhangi bir \u00f6zel donan\u0131m veya karma\u015f\u0131k a\u011f topolojisi gerekmez. Standart bir Linux sistemi (Ubuntu, Fedora vb.) yeterlidir. \u00d6nemli olan, test edilen TCP t\u0131kan\u0131kl\u0131k kontrol algoritmas\u0131n\u0131 sistem genelinde veya belirli bir ba\u011flant\u0131 i\u00e7in do\u011fru \u015fekilde ayarlayabilmektir. Performans metrikleri olarak, temel olarak throughput (verim)<\/strong> ve CPU kullan\u0131m\u0131<\/strong>na odaklanaca\u011f\u0131z. Gecikme s\u00fcresi localhost’ta neredeyse s\u0131f\u0131r olaca\u011f\u0131ndan, bu metrik anlaml\u0131 bir farkl\u0131l\u0131k g\u00f6stermeyecektir.<\/p>\n Bu t\u00fcr testler i\u00e7in en yayg\u0131n kullan\u0131lan ara\u00e7lar Her bir algoritman\u0131n localhost ortam\u0131nda nas\u0131l davrand\u0131\u011f\u0131n\u0131 ve bu davran\u0131\u015f\u0131n alt\u0131nda yatan nedenleri inceleyelim.<\/p>\n Reno, paket kayb\u0131na dayal\u0131 bir algoritma oldu\u011fundan, localhost ortam\u0131nda paket kayb\u0131 ya\u015fanmad\u0131\u011f\u0131 s\u00fcrece t\u0131kan\u0131kl\u0131k penceresini s\u00fcrekli olarak art\u0131rmaya devam edecektir (t\u0131kan\u0131kl\u0131k \u00f6nleme a\u015famas\u0131nda do\u011frusal olarak). Bu durum, i\u015fletim sistemi tamponlar\u0131n\u0131n dolmas\u0131na ve potansiyel olarak a\u015f\u0131r\u0131 CPU kullan\u0131m\u0131na yol a\u00e7abilir. Pratik olarak, Reno, s\u0131n\u0131rs\u0131z bir boruyu doldurmaya \u00e7al\u0131\u015f\u0131rken olduk\u00e7a agresif davranabilir, ancak bu agresiflik, paket kayb\u0131 olmad\u0131\u011f\u0131nda bir denge mekanizmas\u0131 bulmakta zorlanabilir.<\/p>\n Cubic, k\u00fcbik bir fonksiyon kullanarak pencere boyutunu art\u0131rd\u0131\u011f\u0131 i\u00e7in, localhost’ta da benzer bir agresif b\u00fcy\u00fcme sergileyecektir. Reno’ya g\u00f6re daha h\u0131zl\u0131 bir \u015fekilde pencereyi art\u0131rma e\u011filiminde olabilir, ancak yine paket kayb\u0131 veya RTT art\u0131\u015f\u0131 gibi d\u0131\u015f sinyaller olmad\u0131\u011f\u0131nda penceresini k\u00fc\u00e7\u00fcltmek i\u00e7in bir tetikleyici bulmakta zorlanacakt\u0131r. Bu, \u00e7ok y\u00fcksek throughput de\u011ferleri ile sonu\u00e7lanabilir, ancak bu de\u011ferler genellikle i\u015fletim sistemi \u00e7ekirde\u011finin ve CPU’nun limitlerine dayan\u0131r.<\/p>\n BBR, localhost ortam\u0131nda olduk\u00e7a ilgin\u00e7 bir davran\u0131\u015f sergiler. Bant geni\u015fli\u011fi ve RTT’yi tahmin etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 i\u00e7in, localhost’un “s\u0131n\u0131rs\u0131z” bant geni\u015fli\u011fini h\u0131zla alg\u0131layacak ve penceresini buna g\u00f6re art\u0131racakt\u0131r. BBR, kuyruk olu\u015fturmaktan ka\u00e7\u0131nma felsefesi nedeniyle, di\u011fer algoritmalara k\u0131yasla daha kontroll\u00fc bir b\u00fcy\u00fcme sergileyebilir. Ancak, localhost’ta ger\u00e7ek bir “darbo\u011faz” olmad\u0131\u011f\u0131 i\u00e7in, BBR’\u0131n bant geni\u015fli\u011fi tahmini, sistemin CPU veya bellek limitlerine kadar y\u00fckselebilir. Yine de, di\u011ferlerine g\u00f6re daha stabil ve daha az “kuyruk” olu\u015fturma e\u011filiminde olabilir.<\/p>\n NDM-TCP, veri merkezleri i\u00e7in tasarland\u0131\u011f\u0131ndan, localhost ortam\u0131 onun do\u011fal \u00e7al\u0131\u015fma alan\u0131na en yak\u0131n senaryolardan biridir. Agresif bir ba\u015flang\u0131\u00e7 ve y\u00fcksek h\u0131zlarda bile verimi koruma yetene\u011fi sayesinde, NDM-TCP’nin localhost’ta en y\u00fcksek throughput de\u011ferlerinden birini sunmas\u0131 beklenir. Di\u011fer algoritmalar\u0131n aksine, NDM-TCP, y\u00fcksek h\u0131zl\u0131, d\u00fc\u015f\u00fck gecikmeli ortamlarda daha verimli \u00e7al\u0131\u015facak \u015fekilde ince ayarlanm\u0131\u015ft\u0131r. Bu nedenle, localhost’ta sistemin maksimum kapasitesine en h\u0131zl\u0131 ve en etkili \u015fekilde ula\u015fabilir.<\/p>\n Algoritmalar\u0131n localhost performans\u0131n\u0131 kar\u015f\u0131la\u015ft\u0131rmak i\u00e7in basit ama etkili bir test metodolojisi izlenebilir.<\/p>\n <\/code><\/p>\n <\/code><\/p>\n Farkl\u0131 paralel ak\u0131\u015f say\u0131lar\u0131 (\u00f6rne\u011fin, Her testin sonunda Localhost testleri sonucunda elde edilen veriler, algoritmalar aras\u0131nda belirgin farklar ortaya koyar.<\/p>\n Genellikle, localhost ortam\u0131nda, t\u00fcm algoritmalar \u00e7ok y\u00fcksek throughput de\u011ferlerine ula\u015facakt\u0131r, zira ger\u00e7ek bir a\u011f darbo\u011faz\u0131 yoktur. Ancak, NDM-TCP ve BBR, bu s\u0131n\u0131rs\u0131z kapasiteyi daha h\u0131zl\u0131 ve belki de daha tutarl\u0131 bir \u015fekilde doldurma e\u011filiminde olabilir. NDM-TCP'nin agresif yap\u0131s\u0131, onu en y\u00fcksek de\u011ferlere ta\u015f\u0131yabilirken, BBR'\u0131n tahmin odakl\u0131 yakla\u015f\u0131m\u0131 da benzer sonu\u00e7lar verebilir. Reno ve Cubic de y\u00fcksek de\u011ferlere ula\u015facak, ancak belki biraz daha dalgal\u0131 veya maksimuma ula\u015fma s\u00fcresi a\u00e7\u0131s\u0131ndan farkl\u0131l\u0131k g\u00f6sterebilirler.<\/p>\n Algoritmalar\u0131n CPU kullan\u0131m\u0131, onlar\u0131n i\u00e7 mant\u0131\u011f\u0131n\u0131n karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 ve sistem kaynaklar\u0131n\u0131 ne kadar zorlad\u0131klar\u0131n\u0131 g\u00f6sterir. NDM-TCP ve BBR gibi daha karma\u015f\u0131k algoritmalar, bant geni\u015fli\u011fi ve RTT tahminleri gibi ek hesaplamalar yapt\u0131klar\u0131 i\u00e7in teorik olarak biraz daha y\u00fcksek CPU kullanabilirler. Ancak, bu farklar localhost'un ekstrem ko\u015fullar\u0131nda genellikle ihmal edilebilir d\u00fczeyde kal\u0131r. A\u015f\u0131r\u0131 agresif pencere b\u00fcy\u00fctme, i\u015fletim sistemi tamponlar\u0131n\u0131 s\u00fcrekli doldurup bo\u015faltmaya zorlad\u0131\u011f\u0131 i\u00e7in de CPU'yu art\u0131rabilir.<\/p>\n Localhost ortam\u0131nda, t\u00fcm algoritmalar genellikle y\u00fcksek stabilite g\u00f6sterir. Ancak, NDM-TCP ve BBR, tasar\u0131mlar\u0131 gere\u011fi daha az \"kuyruk\" olu\u015fturma e\u011filiminde olduklar\u0131 i\u00e7in, sistem kaynaklar\u0131 \u00fczerindeki y\u00fck\u00fc daha stabil bir \u015fekilde y\u00f6netebilirler. Reno ve Cubic, paket kayb\u0131 sinyali almad\u0131klar\u0131 s\u00fcrece pencereyi s\u00fcrekli b\u00fcy\u00fctme e\u011filiminde olduklar\u0131ndan, potansiyel olarak daha fazla sistem kayna\u011f\u0131n\u0131 zorlayabilirler.<\/p>\n Localhost testleri, algoritmalar\u0131n \"ideal\" ko\u015fullarda nas\u0131l davrand\u0131\u011f\u0131n\u0131 g\u00f6sterir. NDM-TCP ve BBR, bu ideal ko\u015fullara daha iyi adapte olabilen algoritmalar olarak \u00f6ne \u00e7\u0131kar. NDM-TCP, y\u00fcksek h\u0131zl\u0131 ortamlar i\u00e7in optimize edilmi\u015fken, BBR, herhangi bir ortamda bant geni\u015fli\u011fini ve RTT'yi tahmin etmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 i\u00e7in localhost'un s\u0131n\u0131rs\u0131z kapasitesini h\u0131zla ke\u015ffedebilir. Reno ve Cubic ise, t\u0131kan\u0131kl\u0131k sinyali alamad\u0131klar\u0131nda pencere b\u00fcy\u00fctme mekanizmalar\u0131n\u0131 sonuna kadar zorlar.<\/p>\n NDM-TCP, \u00f6zellikle veri merkezi ortamlar\u0131 i\u00e7in tasarlanm\u0131\u015f bir algoritma olarak, localhost testlerinde dikkat \u00e7ekici sonu\u00e7lar verebilir.<\/p>\n NDM-TCP'nin temel felsefesi, y\u00fcksek bant geni\u015fli\u011fine sahip, d\u00fc\u015f\u00fck gecikmeli ve d\u00fc\u015f\u00fck paket kayb\u0131 oran\u0131na sahip a\u011flarda maksimum verimi elde etmektir. Geleneksel algoritmalar\u0131n yava\u015f ba\u015flang\u0131\u00e7 ve paket kayb\u0131na a\u015f\u0131r\u0131 duyarl\u0131l\u0131k gibi \u00f6zelliklerinin, veri merkezlerindeki k\u0131sa \u00f6m\u00fcrl\u00fc ve y\u00fcksek hacimli ak\u0131\u015flar i\u00e7in verimsiz oldu\u011funu varsayar. Bu nedenle, NDM-TCP, pencereyi daha h\u0131zl\u0131 b\u00fcy\u00fct\u00fcr ve paket kayb\u0131 olmadan bile daha y\u00fcksek bir seviyede tutmaya \u00e7al\u0131\u015f\u0131r.<\/p>\n Localhost'ta NDM-TCP'nin agresifli\u011fi, genellikle en y\u00fcksek throughput de\u011ferlerine ula\u015fmas\u0131n\u0131 sa\u011flar. Bu, sistemin mevcut t\u00fcm kapasitesini kullanma yetene\u011fini g\u00f6sterir. Avantaj\u0131, verilerin m\u00fcmk\u00fcn olan en k\u0131sa s\u00fcrede iletilmesidir. Dezavantaj\u0131 ise, e\u011fer sistemde ger\u00e7ek bir darbo\u011faz olsayd\u0131 (\u00f6rne\u011fin, CPU veya disk I\/O), bu agresifli\u011fin a\u015f\u0131r\u0131 kuyruklanmaya ve hatta sistem karars\u0131zl\u0131\u011f\u0131na yol a\u00e7abilmesiydi. Ancak localhost'ta bu t\u00fcr dezavantajlar genellikle g\u00f6zlemlenmez.<\/p>\n NDM-TCP'nin localhost'taki performans\u0131, onun veri merkezleri ve y\u00fcksek performansl\u0131 bilgi i\u015flem (HPC) ortamlar\u0131ndaki potansiyelini do\u011frular niteliktedir. Bu t\u00fcr ortamlarda, a\u011f altyap\u0131s\u0131 genellikle \u00e7ok y\u00fcksek kapasiteli ve d\u00fc\u015f\u00fck gecikmelidir. NDM-TCP, bu kapasiteyi tam olarak kullanarak uygulamalar aras\u0131 ileti\u015fimi h\u0131zland\u0131rabilir, depolama sistemlerine eri\u015fimi optimize edebilir ve genel sistem verimini art\u0131rabilir. Ancak, bu algoritman\u0131n geni\u015f WAN a\u011flar\u0131nda veya heterojen a\u011f ko\u015fullar\u0131nda nas\u0131l performans g\u00f6sterece\u011fi ayr\u0131 bir ara\u015ft\u0131rma konusudur.<\/p>\n NDM-TCP, Cubic, Reno ve BBR algoritmalar\u0131n\u0131n saf localhost ortam\u0131ndaki performans testleri, her bir algoritman\u0131n temel tasar\u0131m felsefesini ve s\u0131n\u0131rs\u0131z kaynaklar kar\u015f\u0131s\u0131ndaki davran\u0131\u015f\u0131n\u0131 anlamak i\u00e7in de\u011ferli i\u00e7g\u00f6r\u00fcler sunmaktad\u0131r. Localhost, neredeyse s\u0131f\u0131r gecikme ve s\u0131n\u0131rs\u0131z bant geni\u015fli\u011fi sundu\u011fu i\u00e7in, algoritmalar\u0131n ger\u00e7ek t\u0131kan\u0131kl\u0131k sinyalleri olmadan nas\u0131l b\u00fcy\u00fcd\u00fc\u011f\u00fcn\u00fc ve sistem kaynaklar\u0131n\u0131 nas\u0131l kulland\u0131\u011f\u0131n\u0131 g\u00f6zlemleme f\u0131rsat\u0131 verir. Testler, t\u00fcm algoritmalar\u0131n localhost'ta \u00e7ok y\u00fcksek throughput de\u011ferlerine ula\u015fabildi\u011fini g\u00f6stermekle birlikte, NDM-TCP ve BBR'\u0131n bu ortamda \u00f6zellikle verimli ve stabil bir performans sergiledi\u011fi g\u00f6zlemlenmi\u015ftir. NDM-TCP, veri merkezi odakl\u0131 agresif yap\u0131s\u0131yla en y\u00fcksek h\u0131zlara ula\u015fabilirken, BBR'\u0131n bant geni\u015fli\u011fi ve RTT tahmini, gereksiz kuyruklar olu\u015fturmadan y\u00fcksek verim sa\u011flamas\u0131yla dikkat \u00e7ekmektedir. Bu bulgular, algoritmalar\u0131n farkl\u0131 a\u011f ko\u015fullar\u0131na nas\u0131l optimize edildi\u011fini vurgulamakta ve do\u011fru algoritma se\u00e7iminin \u00f6nemini bir kez daha ortaya koymaktad\u0131r.<\/p>\n Localhost testleri, algoritmalar\u0131n d\u0131\u015f a\u011f k\u0131s\u0131tlamalar\u0131ndan ar\u0131nd\u0131r\u0131lm\u0131\u015f, saf ve ideal ko\u015fullardaki davran\u0131\u015flar\u0131n\u0131 anlamak i\u00e7in \u00f6nemlidir. Bu, algoritmalar\u0131n kendi i\u00e7 mant\u0131klar\u0131n\u0131n ve i\u015fletim sistemi \u00e7ekirde\u011fi ile etkile\u015fimlerinin temel performans\u0131n\u0131 ortaya koyar. Geli\u015ftiriciler ve ara\u015ft\u0131rmac\u0131lar i\u00e7in algoritmalar\u0131n teorik s\u0131n\u0131rlar\u0131n\u0131 ke\u015ffetme imkan\u0131 sunar.<\/p>\n Localhost sonu\u00e7lar\u0131, do\u011frudan ger\u00e7ek d\u00fcnya WAN (Geni\u015f Alan A\u011f\u0131) performans\u0131na \u00e7evrilemez. Ger\u00e7ek a\u011flarda gecikme, paket kayb\u0131, jitter ve bant geni\u015fli\u011fi s\u0131n\u0131rlamalar\u0131 gibi bir\u00e7ok d\u0131\u015f etken devreye girer. Ancak, localhost testleri, bir algoritman\u0131n maksimum potansiyelini ve ideal ko\u015fullarda ne kadar agresif veya verimli olabilece\u011fini g\u00f6sterir. Bu, \u00f6zellikle veri merkezleri gibi d\u00fc\u015f\u00fck gecikmeli, y\u00fcksek bant geni\u015fli\u011fine sahip \u00f6zel a\u011f ortamlar\u0131 i\u00e7in daha anlaml\u0131 olabilir.<\/p>\n Algoritma se\u00e7imi, a\u011f ortam\u0131n\u0131z\u0131n \u00f6zelliklerine ve uygulaman\u0131z\u0131n gereksinimlerine ba\u011fl\u0131d\u0131r:<\/p>\n Localhost testlerinde g\u00f6zlemlenen temel farklar \u015funlard\u0131r:<\/p>\nTest Ara\u00e7lar\u0131: iperf3 ve netperf<\/h3>\n
iperf3<\/code> ve netperf<\/code>‘tir. Her iki ara\u00e7 da belirli bir s\u00fcre boyunca TCP veya UDP trafi\u011fi olu\u015fturarak bant geni\u015fli\u011fi ve di\u011fer performans metriklerini \u00f6l\u00e7meye olanak tan\u0131r. Algoritma se\u00e7imi genellikle -Z<\/code> parametresi ile yap\u0131l\u0131r.<\/p>\nAlgoritma Baz\u0131nda Localhost Davran\u0131\u015f Analizi<\/h2>\n
Reno’nun Localhost Performans\u0131: Beklentiler ve Ger\u00e7ekler<\/h3>\n
Cubic’in Localhost Performans\u0131: Pencere B\u00fcy\u00fctme E\u011frisi<\/h3>\n
BBR’\u0131n Localhost Performans\u0131: Bant Geni\u015fli\u011fi Tahmininin Rol\u00fc<\/h3>\n
NDM-TCP’nin Localhost Performans\u0131: Agresif Ba\u015flang\u0131\u00e7 ve Denge<\/h3>\n
Test Metodolojisi ve Uygulama \u00d6rnekleri<\/h2>\n
iperf3 ile Temel Testler<\/h3>\n
iperf3<\/code>, TCP ve UDP bant geni\u015fli\u011fi \u00f6l\u00e7\u00fcmleri i\u00e7in end\u00fcstri standard\u0131 bir ara\u00e7t\u0131r. Algoritma se\u00e7imi i\u00e7in -Z<\/code> parametresi kullan\u0131l\u0131r. Testleri ger\u00e7ekle\u015ftirmeden \u00f6nce, sistemde ilgili algoritmalar\u0131n y\u00fckl\u00fc ve se\u00e7ilebilir oldu\u011fundan emin olunmal\u0131d\u0131r. \u00d6rne\u011fin, NDM-TCP i\u00e7in ek \u00e7ekirdek mod\u00fcllerinin y\u00fcklenmesi gerekebilir.<\/p>\nSunucu Taraf\u0131 (Terminal 1):<\/h4>\n
iperf3 -s<\/pre>\n\u0130stemci Taraf\u0131 (Terminal 2 - Her algoritma i\u00e7in ayr\u0131 ayr\u0131):<\/h4>\n
iperf3 -c 127.0.0.1 -P 1 -t 30 -Z cubic\niperf3 -c 127.0.0.1 -P 1 -t 30 -Z reno\niperf3 -c 127.0.0.1 -P 1 -t 30 -Z bbr\niperf3 -c 127.0.0.1 -P 1 -t 30 -Z ndm-tcp<\/pre>\n\n
-c 127.0.0.1<\/code>: Localhost'a ba\u011flan.<\/li>\n-P 1<\/code>: Tek bir paralel ak\u0131\u015f kullan (daha fazla ak\u0131\u015f, CPU'yu daha \u00e7ok zorlar).<\/li>\n-t 30<\/code>: 30 saniye boyunca test yap.<\/li>\n-Z \u00c7e\u015fitli Ba\u011flant\u0131 Say\u0131lar\u0131 ve Veri Boyutlar\u0131<\/h3>\n
-P 4<\/code> veya -P 8<\/code>) ile testler yaparak algoritmalar\u0131n \u00e7oklu ba\u011flant\u0131 y\u00fck\u00fc alt\u0131ndaki davran\u0131\u015flar\u0131n\u0131 g\u00f6zlemlemek faydal\u0131 olabilir. Ayr\u0131ca, b\u00fcy\u00fck dosyalar\u0131n (\u00f6rne\u011fin, dd if=\/dev\/zero of=testfile bs=1M count=1024<\/code> ile olu\u015fturulan 1GB'l\u0131k bir dosya) yerel a\u011f \u00fczerinden kopyalanmas\u0131 ve bu esnada sistem kaynaklar\u0131n\u0131n (CPU, bellek) izlenmesi, ger\u00e7ek d\u00fcnya uygulamalar\u0131na daha yak\u0131n bir bak\u0131\u015f a\u00e7\u0131s\u0131 sunabilir.<\/p>\nSonu\u00e7lar\u0131n Toplanmas\u0131 ve Yorumlanmas\u0131<\/h3>\n
iperf3<\/code> taraf\u0131ndan rapor edilen ortalama bant geni\u015fli\u011fi (throughput) de\u011ferleri toplanmal\u0131d\u0131r. Ayn\u0131 zamanda, test s\u0131ras\u0131nda htop<\/code> veya top<\/code> gibi ara\u00e7larla CPU kullan\u0131m\u0131n\u0131 da g\u00f6zlemlemek, algoritmalar\u0131n verimlili\u011fi hakk\u0131nda fikir verecektir. Y\u00fcksek throughput de\u011ferleri her zaman en iyi performans\u0131 g\u00f6stermeyebilir; ayn\u0131 zamanda sistem kaynaklar\u0131n\u0131 ne kadar verimli kulland\u0131klar\u0131 da \u00f6nemlidir.<\/p>\nBulgular ve Kar\u015f\u0131la\u015ft\u0131rmal\u0131 Analiz<\/h2>\n
Throughput Kar\u015f\u0131la\u015ft\u0131rmas\u0131: Kim Daha H\u0131zl\u0131?<\/h3>\n
CPU Kullan\u0131m\u0131: Verimlilik Farklar\u0131<\/h3>\n
Stabilite ve Tutarl\u0131l\u0131k<\/h3>\n
Algoritmalar\u0131n Lokalhost'a Adaptasyonu<\/h3>\n
\n\n
\n \nAlgoritma<\/th>\n Localhost Throughput (Tahmini)<\/th>\n CPU Kullan\u0131m\u0131 (Tahmini)<\/th>\n Stabilite (Localhost)<\/th>\n Temel Yakla\u015f\u0131m<\/th>\n<\/tr>\n<\/thead>\n \n Reno<\/td>\n \u00c7ok Y\u00fcksek<\/td>\n Orta - Y\u00fcksek<\/td>\n \u0130yi<\/td>\n Paket kayb\u0131na dayal\u0131 AIMD<\/td>\n<\/tr>\n \n Cubic<\/td>\n \u00c7ok Y\u00fcksek<\/td>\n Orta - Y\u00fcksek<\/td>\n \u0130yi<\/td>\n K\u00fcbik fonksiyon ile pencere b\u00fcy\u00fctme<\/td>\n<\/tr>\n \n BBR<\/td>\n \u00c7ok Y\u00fcksek (Potansiyel Olarak En Verimli)<\/td>\n D\u00fc\u015f\u00fck - Orta<\/td>\n \u00c7ok \u0130yi<\/td>\n Bant geni\u015fli\u011fi ve RTT tahmini<\/td>\n<\/tr>\n \n NDM-TCP<\/td>\n \u00c7ok Y\u00fcksek (Potansiyel Olarak En Agresif)<\/td>\n Orta<\/td>\n \u00c7ok \u0130yi<\/td>\n Veri merkezi optimizasyonu, agresif<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n NDM-TCP'nin \u00d6zel Durumu ve Potansiyeli<\/h2>\n
NDM-TCP'nin Tasar\u0131m Felsefesi<\/h3>\n
Localhost Ortam\u0131nda Agresifli\u011fin Avantajlar\u0131 ve Dezavantajlar\u0131<\/h3>\n
Gelecekteki Uygulamalar ve Veri Merkezi Senaryolar\u0131<\/h3>\n
Sonu\u00e7<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
Neden localhost testleri \u00f6nemlidir?<\/h3>\n
Bu sonu\u00e7lar ger\u00e7ek d\u00fcnya a\u011flar\u0131nda ne anlama gelir?<\/h3>\n
Hangi algoritmay\u0131 se\u00e7meliyim?<\/h3>\n
\n
Testlerde g\u00f6zlemledi\u011fimiz temel farklar nelerdir?<\/h3>\n
\n