Internet’i Nasıl Bozduk yada TCP’deki Sıkıntımız Ne?

Internet’in ilk tasarlandığı zamana geri gidip o zamanki ağ kavramlarını ele aldığımız zaman bugün yaşadığımız bazı önemli ve kaçınılmaz problemlerin köklerini daha iyi anlayabiliyoruz.

Öncelikle basit bir dizi kavramı görselleştirmeye çalışalım. Kanal ve bağlantı sözcüklerinden ne anlıyoruz?

Kanal fiziken gözümüzde canlandırabileceğimiz kadarı ile bir akışın oluştuğu bir ortam. Bu kanaldan akan maddenin türüne göre kanala farklı isimler verebiliriz. Akan şey kansa kanala kan damarı, yük gemileri ise su kanalı, ağ paketleri ise de ağ kanalı diyebiliyoruz. Kanal kapasitesi, kanalın fiziki koşullar nedeni ile o anda birim zamanda taşıyabileceği maddeye dair bir kapasite oluyor. Mililitre / saniye, gemi / gün, bayt / saniye cinsinden de bir birim ataması yapıyoruz. Ancak kanal kapasitesinin aslında olaylar olup bittikten sonra gözlenebilen bir şey olduğunu, geleceğe dair ise bir tahminde bulunabildiğimizi de göz ardı etmeyelim. Bu kapasiteye dair tahminlerimizi iyi yaparsak planlamamız ve kanaldan elde ettiğimiz fayda da en yüksek düzeyde oluyor. Gemilerin geçtiği bir kanalı işleten kişinin günde kaç gemi geçirebileceğini bilmesi çok önemli değil mi?

Elbette geleceğe dönük planlama her zaman gerçekçi sonuçlara yol açmaz. Dolayısı ile kanal kapasitesine dönük planlama, farklı faktörler nedeni ile geçersiz kılınmış ise, hızlı bir biçimde plan güncellemesi yapmak şart olacaktır. Kanalın yöneticisi sıfatı ile, kanalın önünde birikmiş gemilere “bekleyin” talimatı vererek, kapasitesi azalan kanaldan yavaş tavaş geçirmeniz gerekmektedir. Eğer kanal kapasitesi tekrar artarsa da bekleyen gemileri “yeniden hızlandırmanız,” gündelik deyim ile “gel gel” yapmanız gerekecektir. Eğer yeniden hızlandırmaz iseniz, artan kanal kapasitesinin farkına varmadığınız için elinizdeki kapasiteyi israf etmektesiniz demektir. Özetle kötü yönetim size para, zaman, itibar kaybettirir.

Kötü yönetim nedeni ile elinizdeki kanal ile artmakta olan gemi trafiğini taşıyamazsanız, hemen ikinci bir kanalın inşaatı için yatırım yapmanız gerekir. Yeni yatırımlar illa ki gerekli olacaktır ancak iyi yönetim bu yatırımları ötelemenizi, mevcut yatırımlarınızın ömrünü uzatmanızı sağlayacaktır.

Aynı örneği İnternet ağlarına uyguladığımız zaman görüntü hem iyi hem kötüdür. Kanal kapasitesi kullandığınız fiziki alt yapının koşullarına göre oldukça sabit olabilir. Bir bakır kablonun veya fiber kablonun, hatta iyi tasarlanmış ise bir wi-fi bağlantısının kanal kapasitesi hesaplanabilir ve oldukça dengelidir. Ancak İnternet tek bir kanaldan ibaret değildir. Biri diğerine bağlanmış sayısız kanal ve kanallar arasındaki hareketi yönlendiren sayısız yönetici vardır. Sizin bir noktadan öbür noktaya keyfi bir hızla yolladığınız paketler (gemiler) ilerideki bir geçiş noktasında bekletilirken (gemiler için bekleme havuzu, paketler için bellek) oradaki kapasite aşılırsa o zaman geri yollanırlar. Bu da sizin için pratikte kanal kapasitesinin aşılması ile eşdeğerdir ve yine hız kesmeniz gerekir.

Bu sorunu çözmenin ana yöntemi bu geçiş noktalarındaki davranışı iyileştirmektir. Ancak insan doğasının çeşitliliği ve bencilliği, sistemlerin tasarımına ve çalışmasına da yansımıştır. Bir su kanalında çok az türde gemi farklı farklı davranır: şilepler, yolcu gemileri, küçük yatlar, askeri gemiler deseniz farklı davranan belki on farklı türde gemi sayabilirsiniz. Ancak İnternet ağında akan paketlere baktığımız zaman davranış çok ama çok çeşitlidir. Çünkü uygulamalar çok çeşitlidir. Üstelik geçiş noktalarını yöneten aygıtların (ağ anahtarları, switch) davranışları da farklı olabilir.

İnternet ilk tasarlandığı zaman, sistemin aslında az sayıda merkezi sunucuya odaklanmış olacağı, çok farklı yerlerdeki kullanıcıların, çok sayıda anahtardan geçse bile eninde sonunda bu az sayıdaki merkezi sunucuya ulaşacağı öngörülmüştür. Bu o zaman için son derece mantıklı bir varsayımdır çünkü İnternet ilk önce askeri, arkasından da kamusal bilgiye erişim (özetle kütüphane) amaçlı kullanıma sunulmak üzere tasarlanmıştır. Böyle bir sistemde, ağ paketlerinin yönetimi göreceli olarak kolaydır. Dolayısı ile Paul Baran’ın 1962’de tasarladığı hali ile paket anahtarlama [1] oldukça sıradan bir işlemdir.

Ağın bir anahtarda tıkanması (congestion) çok basit bir sebepten olmaktadır: Anahtara değişik girişlerden gelen trafiğin ve aynı yöne gönderilmesi gereken trafik için hedefe giden çıkışın kapasitesi, girişlerin kapasitesi toplamından düşüktür. Bu durumun kısa süreli olması durumuna karşı ağ anahtarlarında bir kuyruk (ilk giren ilk çıkar) şeklinde organize edilmiş bir ön bellek (cache) bulunur. Büyük önbellekli anahtarlar, geçici ama daha uzun süreli tıkanıklıkları tolere edebilmektedir. Eğer tıkanıklık geçmiyorsa kuyrukta bulunan bazı paketler “düşer” yani özetle artık yollanmayacağı anlaşılacaktır. Hangi paketlerin düşürüleceğine karar vermenin değişik teknikleri bulunmaktadır, ancak bunlar bu yazının konusu değildir.

Tıkanmanın yönetilmesi aktarımın yönetilmesinin bir parçası olduğu için aktarıma dair parametreleri kullanarak kararlar alınan bir alan olmuştur. Günümüzde İnternet ile eş anlamlı saydığımız TCP/IP ikilisindeki TCP (Transimission Control Protocol – Aktarım Kontrolü Sözleşmesi) bu konudaki teknik kararların alınması için bir çerçeve sunar[2]. Bir TCP ağında yer alabilmek için protokolün size dayattığı gereksinimleri farklı şekillerde gerçekleştirebilirsiniz. İlerleyen yıllar içinde ki özellikle son 30 yıl içerisinde bu konuda belki az sayıda ama oldukça önemli değişiklikler gerçekleşmiştir.

TCP’nin ilk önemli kavramı kayan penceredir. Ağ tıkanıklığına dönük riskleri yönetmek için paketler gruplar halinde yollanır. Her grubun büyüklüğüne de pencere büyüklüğü denir. Bu nedenle bir penceredeki paketlerin ulaşma veya düşmesi olasılığı aynıdır, “aynı gemide” seyahat etmektedirler. Düşen paketler ise ARQ (Automatic Repeat Rwquest – Otomatik Tekrar İstemi) protokolü [3] ile tekrarlanır. Paketleri yollayan yazılımlar aynı yazılımlar olmak zorunda olmadığı için yazılımların bu sistemdeki paket düşmelerinden etkilenmeleri de değişebilir. Şans eseri bir yazılımın paketleri daha sık düşebilir ve o ağı daha yavaşmış gibi algılar. Paketleri önceliklendirmekle ilgili teknikler burada devreye girmektedir ama yine bu yazının konusu değildir.

TCP pencereler halinde yollanan verinin güvenilir biçimde yollanması için “gönder ve bekle” olarak özetleyebileceğimiz bir yaklaşım öngörmektedir. Pencere içindeki paketlerin bir sonraki anahtara ulaştığına dair onay geri geldiği zaman sıradaki pencere yollanmaktadır. Belirli bir zaman aşımı içinde alındı onayı gelmezse paketler tekrar yollanır. Ancak şunu unutmamak gerekmektedir: Alındı onayı da ağdan geçmektedir ve belki de başarı ile iletilen paketler için alındı onayının iletimi sorun yaşamış olabilir. Bu durumda aynı pencere içindeki paketlerin hatalı olarak birden fazla kez yollanması söz konusu olabilir. Özellikle ağ (kanal) kapasitesinin ve kalitesinin iletim yönüne göre asimetrik olduğu ağlarda bu sıklıkla karşılaşılabilen bir durum olmaktadır. Kuramsal olarak bu durum ağ aktarımındaki verimliliği yarıya kadar indirebilir. Zaman aşımsız bir çözümün de mümkün olamayacağını, bir kilitlenme (deadlock) yaratma riski taşıdığını dipnot olarak belirtmek gerekmektedir.

TCP bu süreci en iyi biçimde işletebilmek için pencerenin yollanması ile alındı onayının gelmesi arasında geçen gidiş-geliş süresi (Round-Trip Time, RTT) üzerine kurulu bir ağ kalitesi anlayışı geliştirmiştir. Teorik kanal kapasiteniz paket / süre cinsinden ifade edildiği için kanal kapasitesi çarpı RTT kadar verinin ağda akmakta olduğunu varsayabiliriz. Bu çarpıma zaman zaman aktarım kapasitesi (transit capacity) adı da verilmektedir. Aktarım kapasitesini bilmek, iyi bir pencere büyüklüğünün seçilmesini sağlamaktadır. Burada iki önemli soru mevcuttur.

  1. Teorik kanal kapasitesi gerçekçi bir tahmin olup olmadığı, önemli bir soru olmaktadır. Kanal kapasitesinin değişken olduğu durumlarda, değişkenliğin kendi doğasına dayanarak kanal kapasitesini doğru tahmin edebilmek, pencere büyüklüğünü doğru seçmek ve kanalı (ağı) en yüksek verimlilikte kullanmak anlamına gelmektedir.
  2. RTT bir pencerenin sıradaki hedefe ulaşması olarak tanımlanmıştır ancak anahtardan anahtara geçen, belki 20-30 kez anahtarlanan günümüz İnternet trafiğinde, bir paket farklı anahtarlarda farklı pencerelere dahil edilmektedir. Dolayısı ile bir kanalın RTT değeri, diğer kanalların trafik yoğunluğundan etkilenen dinamik, tamamen kontrol edilemeyen bir değer halini almaktadır.

Bu iki değeri mükemmel bir biçimde tahmin etmek mümkün olmamaktadır. Dolayısı ile pencere büyüklüğünü en doğru biçimde seçmek de mümkün olmamaktadır. Buna neden olan şey İnternet trafiğinin milyarlarca birey tarafından keyfi ve çok çeşitli biçimde yaratılmasıdır. Ancak, bu davranışın doğru analizi ile oldukça başarılı pencere büyüklükleri seçilebileceği göz ardı edilmemelidir.

Bir ağın yüksek performanslı olmasını bağlayabileceğimiz nedenler şöyle sıralanabilir:

  1. Ağın fiziki kanal kapasitesi, talebin çok üzerindedir; aşırı alt yapı yatırımı yapılmıştır.
  2. Ağın davranışı öngörülebilirdir; bu nedenle TCP pencere büyüklükleri kolayca en iyiye yakın değerde hesaplanmaktadır. Tıkanma ve paket düşme istatistikleri de düşüktür. Yüzde sıfıra yakındır.
  3. Ağın davranışı oldukça değişkendir ancak buna rağmen TCP pencere büyüklükleri nitelikli olarak hesaplanmaktadır. Tıkanmalar öngörüldüğü için tıkanmadan kaçınmak yolu ile engellenmektedir. Tıkanma ve paket düşme istatistikleri yine düşüktür.

Dikkat edecek olursanız, TCP bu süreci önemli ölçüde gönderen tarafın sorumluluğu olarak görmektedir. Bu prensipte bir değişiklik beklememek gerekir.

Nihayetinde TCP kendi mekanizmaları için kullanması gereken meta-verileri de içerecek şekilde paket tasarımını tamamlamış [4], olgun ve yaygın bir protokoldür. Gönderen merkezliliği sorgulamak istersek, TCP’nin önemli oranda değiştirilmesi değil, TCP’nin yerine geçecek bir protokolün sıfırdan tasarlanması, dolayısı ile TCP merkezli geliştirilmiş bütün ağ cihzaları ve yazılımların da yeniden tasarlanması ve yenilenmesinin maliyetine katlanılması gerekmektedir. IPV6’nın yaygınlaşma sürecini izleyecek olursak, TCP’nin yerine geçecek önemli bir değişikliğin de kısa sürede ortaya çıkmayacağı ve yaygınlaşmayacağını görebiliriz.

Ancak TCP’nin ana yapısını değiştirmeksizin akış içerisindeki belirli önemli noktalardaki değişiklikler yapılabilir, yaygınlaştırması göreceli kolaydır ve şu ana kadar da bu durum böyle gerçekleşmiştir. İnternet içindeki paketlerin davranışı değiştikçe yaygın TCP uyarlamasının sorunlar yaşadığı gözlenmiş, soruna dönük nokta atış değişiklikler ile ilerleme sağlanmıştır.

Bu ilerlemelerin olması beklenen normal bir şeydir. Ancak bilmemiz gerekir ki, TCP’deki sıkıntılar kaçınılmazdır. Kullanıcılar İnternet’i kendi keyfi amaçlarına göre kullanmakta özgür oldukları için öngörülenden farklı şekillerde kullanarak, bir anlamda İnternet’i bozmuştur. Mevcut kullanım yöntemlerine dönük harika bir “yeni TCP” yaratılacak olsa ve bir anda yaygınlaşsa bile kısa süre içerisinde yeni yeni kullanım yöntemleri ortaya çıkacak ve yeni TCP’yi de bozacaktır.

Var olmasını umabileceğimiz en iyi şey, TCP’nin yeni kullanım yöntemlerine “öğrenerek” adapte olabilecek şekilde güncellenmesini sağlayan, mükemmel olmasa da oldukça uzun ömürlü bir çözümün yaygınlaşmasıdır.

[1] Paul Baran, “On Distributed Computing Networks”, Rand Corporation P-2626, 1962.
[2] TCP – https://tools.ietf.org/html/rfc793
[3] ARQ – https://tools.ietf.org/html/rfc3366
[4] TCP Paket Yapısı – https://bit.ly/2TwxklZ

Menü