Transport Kontrol Protokolu(TCP)
TCP olmadigi takdirde sebekelerle baglanti kurmak cok zor olabilir. TCP’nin görevi, Bilgilerin (Verilerin) emin ve güvenli sekilde ilgili bilgisayarlara ulastirmaktir.
1.Giris
Devaminda, sebekeler arasinda en önemli Protokolyer aliyor: TCP. Gündemizde UDP’nin yanisira en cok kullanilan iki Iletisim-Protokolü arasinda yer almaktadir. Aradaki fark, UDP’nin hizli ama güvensiz Veri-transfei imkani saglamasidir, diger tarfta TCP-baglantilarinin cok güvenilir ve idare edilecek bir sekilde olmasidir. Günümüzde Uylugamalrin cogunlugu TCP kulanmaktadir, cünkü Veri-transferinin güvenli ve zorluksuz(kolay) yoludur.
Hatta TCP’nin ilk cikan sekli IP’den önce yazilmistir. Daha sonra, IP’nin TCP-Protkolünden cikartilip ayri ve kendi basina bir Protokol olarak calistirilmasi daha mantikli bir cözüm oldugunun farkina varildi. Böylece görevler bölüstürüldü, ve her Protokol en iyi yapabilecegi isi yapmaya agirligini koydu. Bundandirki günümüzde TCP/IP kelimesi bilgisayar dünyasinda bayagi cok kullanilmaktadir. Bu iki Protokol birbiriyle örgülü bir sekildei calismaktadirlar ve asiri derecede yayginlardir.
TCP ilk olarak RFC 793 icinde belirlenmis ve artik STD 7 olarak yeniden yayinlanmistir – Böylece TCP’de Internet Standard Protokollerinden sayilmaktadir. TCP’nin Ptotokol ID’si 6dir. Bir sistem, Protkol ID’si 6 olan bir IP-paketi aldigi takdirde bu paketi yerli TCP Servisine aktarmasi mecburiyetindedir.
1.2. TCP güvenilir ve baglanti yöneliklidir
Tüm Transport-Protokolleri fiziksel Medya vasitasiyla Veri-transferi icin IP kullanmaktadir. IP’nin asiri güvensiz oldugundan ve paketlerin kaybolma ihtimali büyük oldugundan, IP’nin yalniz olarak kullanilmasi bircok Programlar icin mantikli degildir. Telnet, e-Posta ve benzeri uygulamalar,iki sistem arasinda saglam ve öncelikli güvenilir bir baglanti gerektirmektedir.
Bu güvenceyi basda TCP saglayabilir. TCP, bir full-duplexe (tam-duplex) point-to-point (noktadan-noktaya) baglantiyi iki sistem arsinda yönetir, bu baglanti bir VIRTÜELL dair-baglantisi trafindan kurulmaktadir. Bu demektirki, TCP diger bir siteme veri göndermek istedigi vakit, bu iki sistem arasinda bir daire-baglantisi kurulur. Böylece baglantinin azami sekilde gözetlenme imkani saglanmis olur; iki sistemde diger sitemin hareketlerinden devamli haberdardir.
Bu VIRTÜEL daire-baglantisi TCP’nin UDP’den yavas olmasina neden olur. UDP, bu tür daire kurulmasina neden görmez, verileri direk olarak nakleder. Buda UDP’nin TCP’den daha az güvenli olmasina neden olur.
1.3. TCP Hizmetleri
Aslinda her Uygulama, sistemler arasindaki kendi baglantisini yönetebilir, kaybolmus paketleri farkedebilir, yeniden istekde bulunabilir ve saire (v.s.). Ama bu desavantajli olmaktadir. Bu görev Transport-Layer (tasima-tabakasi) icinde bulunan bir Protokol’e taksim edilmektedir. Ve böylece her Uygulama karli cikar ve isbirligi azami sekilde kolaylastirilmis olur.
Devaminda, TCP’nin, Uygulamarin kullannimina hazir hale koymus en önemli hizmetler yer aliyor:
Virtüel Circuits (VIRTÜEL devreler)
Iki sistem, TCP vasitasiyla veri alis-verisi yapmak istedigi her vakit, aralarinda bir VIRTÜEL daire-baglantisi kurulmaktdir. Bu her TCP baglantisinin cekirdegidir, bununla güvenlik, veri-akisi-kontrolü ve I/O idaresi imkani saglanilmaktadir. Iste TCP bu noktada UDP’den farkli olmaktadir.
Uygulama I/O idaresi
Uygulamalar aralarinda, ilgili verilerin lokal(yerel) TCP-servisine aktarip, TCP, verileri VIRTÜEL daire-baglantisi vasitasiyla gönderip, ve diger TCP’nin bu verilerin almasiyla, iletisimi saglar. TCP, verilerin devamli akisini saglamak icin, Uygulamara iki taraftada bir ara-hafiza imkani vermektedir.
Sebeke I/O idaresi
TCP, diger bir sisteme veriler göndermek istedigi takdirde – bu her Transport-Protokolü icin gecerlidir – IP’ye danisir. TCP, IP’ye karsilik, gönderilen verilerin anlamli sekilde IP’ye aktarilmasi icin, bir sistem sunar. Ve böylece verilerin en verimli sekilde transfer olunmasi saglanilmis olur. Bunada Sebeke I/O Idaresi adi verilimektedir.
Flow control (akis kontrolü)
Sebekeler icinde bulunan sistemlerin önsartlari ayni olmayabilirler. Farkli BROADBANDLAR (genis-bantlar), degisik hafiza kapasiteleri v.s.. Dolayisiyle, TCP veri-akisini ona göre ayarlayabilmesi icin bir imkana sahip olmalidir. TCP, Uygulamalardan etkilenmeden bunu yapabilmesi önemli bir hususdur.
Reliabulity (GÜVENIRLIK)
TCP veri-transferinin üst düzeyde güvenirlik sunar, cünkü gönderdigi verileri devamli olarak gözetmektedir. Adina sequence-numbers (parca-numaralari) verilmis numaralar verilerin her bir Byte’ini isaretler, Acknowledgement flags (Bilgilendirme bayragi) denilen isaret vasitasi bu Byte’lerden kaybolan olmusmu diye kontrol eder ve Checksums (kontrol-toplam) vasitasiyla Verilerin toplami dogru olup olmadigini kontrol eder.
Bu vasitalar/hizmetler birlikte TCP’nin güclü, emin ve güvenilir bir Transport-Protokolü olmasin saglamaktadirlar.
.
1.4. VIRTÜEL (devamli var olabilen) daire-baglantisi
TCP güvenli bir Veri-Transferi saglamak istediginden, IP’nin yetersizligini bir sekil kontol edebilmesi mecburiytindedir. Buda transferin iki nokta arasindaki bulunan virtüel daire-baglantisi üzeri olabilir. Iki TCP-sistem arasinda bir baglanti kurulursa, tüm veriler bu virtüel daire-baglantisi üzeri gönderilmektedirler. Devaminda bulunan Grafik 3.13.bu semayi aciklamaktadir
Grafik 3.13
TCP’yi biraz daha iyi kavramak icin, bir Telefon görüsmesiyle karsilastirmak, sik ve memnuniyetle kullanilan bir karsilastirmadir. Bir Uygulama diger br sistemle Veri alis-verisinde bulunmak istediginde, bir virtüel daire-baglantisi üzeri ilgili sisteme bir sorgu gönderir. Bu hareket telefonla birinin numarasini cevirmekle kiyaslanabilir. Eger diger tarfdaki ‘Alo’ derse bu transferin kurulmus olmasi demektir. Eger asil arayan kiside ‘Alo, ben Martin’ derse, iki tarafin baglantisi kurulmustur ve veriler (bizim verdigimiz örnekde konusulan Sözler) transfer ediliebilirler.
Hata düzeltmede buna benzer. Eger konusanlar arasinda biri digerini anlamazsa (her türlü nedenden), ‘özür dielrim, ne demistin?’ der ve oda ‘sunu, bunu....’ diye cevaplar. Iletsim birdenbire imkansiz hale gelirse, ikiside az bir zaman sonra telefonlari kapatir ve baglantiyi sona erdiriler (daha sonra belki tekrar denemek icin). Eger hersey yolunda giderse, iki taraf vedalasana kadar Veri transferi yapilir: ‘Oldu kendine iyi bak’ – ‘Güle güle!’. Böylece ikisde baglantiya son verirler.
.
Bu planlama 3.14 no.lu Grafikde tekrar cizilmistir. ‘Arama’ diger tarafa ulasir ulasmaz, mesafedeki sistemde ona göre cevaplarsa (‘Alo?’) ve arayan aranilani selamlarsa (‘Alo, ben Martin!’) bir handshake (tokalasma) uygulanmistir. Artik sistemler arsindaki baglanti kuruludur ve veri transferi mümkündür.
Grafik 3.14
Iki alet, arsinda TCP üzeri veri alis-verisi yapmak istedigi her zaman, virtüel daire - baglantisini her alis-veris icin yenilemesi geregini desavantaj olarak yorumlanabilir. Örnegin, bir web-Browser (kullanicisi) bir Web-Server’I dört ayri resim icin asagi yukari ayni zamanda sorgulamak isterse iki sistem arasinda dört farkli baglanti kurulmasi gereklidir. Böylece cok kullanilmakta olan bir Server devamli olarak farkli sistemler arasinda cok sayida virtüel daire-baglantilarin bagli kalmasini saglamak mecburiyetindedir.
Uygulama I/O Idaresi
Farkli Uygulamalr icin TCP cok büyük bir destektir. Tüm veri-transfer görevini ve bunlarin gözetlenmesini üstlenir. Böylece Uygulamalar bu tür görevlerin icermemesini gerektirmez, buda bütün sistemin basitlesmesine sebeb olur. Veri transferi gerektiginde, TCP uygulamalarin santral noktasidir (vis TCP!(TCP vasitasiyla!))
Burda cok önemli bir nokta Uygulama I/O Idaresidir. Bundan böyle,Uygulamalar teker teker verileri devamli bir akis icerisinde TCP’ye gönerbilirler ve ondanda alabilirler. Proglamlar Datagramlarin (veri-paketlerinin) fraglanmasiyla (bölük hale gelmesiyle) veya geri bir araya getirilmesiyle ugrasmazlar. Bu görevleri TCP, (IP’de olabilir) tamamen üstlenmistir.
.
TCP Uygulamalara Uygulama I/O Idaresi servisinin dört farkli hizmetini/görevini sunar, devamindaki bölümlerde bunlar izah edilecektir.
1.5.1. Icbölüm adresleme
UDP gibi (3.4.2. no.lu bölüme bakiniz) TCP’de Uygulamalara teker teker Portnumarasi (kapi no.su) taksim eder. Bu TCP’nin gelen/giren verilerin ilgili Uygulamalara aktarmasini mümküm etmektedir.
1.5.2. Virtüel daire-baglantisini acma
Uygulamalar, diger bir Sisteme virtüel daire-baglantisi gerektiginde yerel TCP-servisine haber verir. TCP’ baglanti kurmak icin gerekeni yapar.
Böyle bir baglantinin acilamsina iki degisik imkan bulunmaktadir. Birisine ‘active opens’(hareketde bulunan aciklar) adi verilmistir. Burda Uygulama diger bir sistemle baglanti kurmak ister – hareketdedir. Ikinci imkan ise ‘passive open’dir (harekede bulunmayan aciklar. Burda bir Uygulama gelen/giren active opens bekler (örnegin bir Web.Server olabilir) – hareketsizdir.
Devamindaki 3.15 no.lu grafik bir Internet-sitesinin sorgusunu aciklamaktadir. Client (müvekkil) baglanti kurmak icin active open kullnamaktadir. Serverde passive open halinde giris yapmak isteyen baglantilari beklediginden, baglanti kurulabilir.
Grafik 3.15
Burda önemli bir husus, iki sistem arasinda gönderilen ilk paketlerin bos olmamalaridir – bunlar önemli yönlendirme bilgileri icerlemektedirler. Ilk paketde, Clientden (müvekkilden) cikan, Synchronize Flag (esitleme bayragi/isareti) yerlestirilmistir, buda Server’i yeni bir bagalanti kurma müracaati oldugunu bilgisini verir. Bunun yaninda bu müracaat sequence number’i (parca numarasi) (=birinci Byte)’i icerir, bunuda Client (müvekkil), veri gönderilmesi mümkün oldugunda, kullancaktir.
Server baglanti kurulmasina iznini verdiginde, bir segment (paket) geri gönderir, bundada Synchronize Flag yerlestirilmistir (baglantini henüz kuruldugu icin). Devaminda Acknowledgement flag yerlestirilir ve Acknowledgement Identifier (Bilginlendirme taniyicisi) müvekkilinin bir sonra beklenilen Byte’ina yerlestirilir.
Müvekkil, Acknowledgement flag yerlestirilmis bir segmenle (parcayla) cevap verir, ve Acknowledgement Identifier Serverden beklenilen bir sonraki Byte’ina yerlestirilmistir. Bu segmende Synchronize Flag yerlestirimez, cünkü baglanti kurulmus halde bulunmaktadir.
1.5.3. Veri transfer etmek
Her ne zaman bir uygulama veri transfer etmek isterse, verileri TCP’ye aktarir, ve verilerin aliciya ulasmasi icin gerekenlerin TCP tarafindan uygulanacagi zanninda bulunmaktadir.
TCP, uygulamadan belli miktarda Veri aldiktan sonra, ilgili aliciya gönderir. Veriler bundan bir IP-Datagram’i (IP-veripaketi) icerisinde toplanilir ve IP vasitasiyla gönderilir. Alicinin Ip-servisi bu Datagram’i alir, protocol Identifier (protokol taniciyisi)’le bunun bir TCP-Datagram’i oldugunu farkeder ve TCP’ye aktarir. TCP, Portnumber (kapi/giris no.su)’den verilerin hangi uygulamaya gönderilmesi gerektigini tanimaktadir.
3.16 no.lu Grafik de bu sekil yeniden aciklanmistir. Önce kullandigimiz örnegi devam ediyoruz. Müvekkil, Serverde bulunan bir dokümani/dosyayi acmak istiyor – müracaatini TCP’ye gönderiyor, ve TCP IP vasitasiyla server’e gönderiyor. Müracaat, geregine uygun sekilde islem görüyor, ve veriler ayni sekilde geri gönderiliyor.
Uygulamalarin ilgili verileri ayri ayri TCP-segmenler(parca) icinde gönderildigini ver her biri teker teker onaylanmasinin gerektigini dikkat edilmesi önemli bir hususdur.
Grafik 3.16
1.5.4. Virtüel daire-baglantilarini kapama
Uygulamar veri-transferini bitirmisise, yerel TCP-servisini haberdar etmektedirler, bunlarda baglantiyi bitirmeketdirler. Baglantiyi bitirmek/kapamak kurmaya benzemektedir.
Burdada kullanilan iki farkli Imkan bulunmaktadir. Baglantiyi kapamak cagrisi yapan taraf, active close (hareket halinde kapama) kullanir. Bundan böyle diger sistem passive close (hareketsiz kapama) ile cevap vermeye mecburdur. Kapama cagrisinda bulunan bu onaylamayi tekrar onaylarsa baglanti iki taraf icind kesilir. Devaminda 3.17 no.lu Grafik bu simdiye kadar kullandigimiz örnege son verecektir:
Grafik 3.17
Virtüel daire-baglantisinin kurulmasinda oldugu gibi, yani burda Synchronize Flags kullaniliyor, baglantinin kapanmasi icin de ona göre Finish Flags (bitirme bayraklari) bulunur. Bunlarin diger sistemi bilgilendirmek icin yerlesmesi gerekir.
Ek olarak söylemek gerkir: öncelikle Serverlerde sadece virtüel daire-baglantisinin kapanir – Port(Kapi) kapanmaz. Port, sadece ilgili Uygulamanin yürümez hale getirildiginde kapanir (örnegin bir Webserver’i). Sonuc: Ferret Webserverle baglantisini bitirdikden sonra, Webserver Fungiden baska baglantilar kabul etme imkanina sahipdir.
1.6. Sebeke I/O Idaresi
TCP üzeri veri göndermek isteyen Uygulamalar, verileri TCP’ye teslim etmeleri mecburiyetindeler. TCP az bir zaman, yani yeterince Veri bir araya gelene kadar, bekler ve veriler toplu sekilde Segmen (parca paketi) olarak gönderme imkanina ulasir. Bir Sebekeyi en iyi sekilde degerlendirmek icin, Semenlerin büyüklükleri cok büyük önem tasir.
Her TCP 40 Byte (20 IP’den, 20 TCP’den) büyüklügünde bir Header’e (basliga) sahiptir. Örnegin tam 1 Byte büyüklügünde veri transfer edersek, aradaki alaka 41:1 olur – cok kötü bir degerlendirme olur. En uygun sekil veri-miktarinin dört kiloByte olamsidir, böylece aradaki alaka 1:101 olur.
Az bir veri-miktarinin bir TCP-segmenine yerlestirmenin desavantajli oldugu kolayca fark edilebilir, cünkü Header-(baslik)bilgi transferi asil veri transferine karsilik fazlaliktadir. Veri-miktarinin fazla büyük olamasida transfer-hizi icin kötüdür. Bir Segmene, fiziksel akim aracinin MTU’su kapasitesin izin verdidinden fazla veri yerlestirdiginzde, Segmenlerin fraglanmasi (bölünmesi) gerekir. Bunun bedelide fazla zaman ve cabadir. Segmen büyüklügünü dogru ayarlamak icin, bazi yöntemler gerekir. Devamindaki bölümde en önemli Faktörleri (hususlari) icermektedir:
1.6.1.Gönderme-ve alma-kalibi
Gönderme kalibinin dolu olmasi halinde, TCP-segmeni gönderilmesi gerekir, cünkü kaliba yeni veriler yerlestirilimesi icin bosalmasi lazimdir. Buda temel bir kuraldir.
Karsiligindada alici-kalibi icin bilinmesi gereken, o dolar dolmaz, baska veri karsilayamaz.
Ilgilgi Sisitemdeki menbalar bosalmasina izin verirse bosalir.
Anlasilan, Kalip büyüklükleri etikinlik icin cok önemli bir hususdur. Gönderme-kalibinin fazla kücük secildigi halde (veya büygüne imkan yoksa), fiziksel akis aracinin enbyük sahip oalbilicegi MTU’nun tam kapasitesi dolmamasina neden olabilir. Buda yukarida izah edildigi gibi etkinlige eksik verir. Öte tarafdan ayni zorluk Alici-kalibin kücük olmasiylada yasanbilir. Burdada MTU’nun gerektirdigi segmenler gerekenden kücükdürler ve normalinden eksik etkinlik olur, cünkü kalibi dolu oldugu icin alici segmen karsilayamaz (Gönderici büyük Segmen gönderebilsede)
Kalib büyüklügü alrtden alete degisktir. Cogu bilgisayar-sistemleri sekiz kiloBytelik Alici-kalibina sahipdirler – server-sistemleri bunlara karsilik 32,48 veya daha fazla kiloByte’a sahip olabilirler.
Demekki, Sisitemlerin alicilarin ilgili alici-kaliblarindan haberdar olmasi cok önemlidir.
Bu da her TCP-Header icinde bulunan window-cercevesi üzeri olur. Bunun icine her alet, gönderici yanlislikla fazla göndermesin diye, gündemindeki kalib büyüklügünü yerlestirir (Fazla gelen veriler ulasamaz)
1.6.2. MTU-/MRU(En büyük Transfer araci-/En büyük alici araci-) büyüklügü
Alici-verici-kalibinin önemi kadar MTU’nun ve MRU’nun büyüklükleri de o kadar önem tasimaktadirlar. Bir Segmen MTU’dan büyük ise caresi fragmanlastirmaktadir (parcalamak) – ve önce söylendigi gibi bedeli fazla zamandir.
Cogunlukla TCP-Segmeninin büyüklügü MTU/MRU’ya göre ayarlanilmistirlar. En düsük sistemlerin bile alici-ve verici kaliblari MTU/MRU’larindan büyüktürler.
Normal Ethernet-sistemindeki MTU ve MRU sabit oalrak 1500 Byte ayarlanmistir. Buda 1460 Bytelik bir TCP-Segmenine izin verir (40 Byte’i sabit olarak Header(baslik) icin ayarlanmistir). Bazi arama-baglantilari icin MTU yu MRU’dan düsük tutmak daha mantiklidir. Bunun sebebide cogu sistemlerin serverler’e sadece müracaatda bulunmalarindandir, onlardan da büyük miktarda veri alirlar. MTU’nun alcaltilmasiyla, sahislarin yeteneklerinin büyültülmesine imkanina yol acar.
Müvekkilin MTU’su byük olsun kücük olsun, Gönderici alicinin MRU’sun tanimiya mecburdur. Gönderici icn ikinci önemli hususda kendi MTU’sudur. Bu iki husus en büyük segmen-büyüklügünü sabitlestirirler.
Demekki, Gönderici icin alicinin MRU-büyüklügünü tanimasi önem tasimaktadir. Her transfre edilen segmen icerisinde MTU’da gönderilir – ona karsilik MRU’da virtüel daire-baglantisi esnasinda sabitlestirilir.
Gönderici sistem icin, bu iki sistem arasindaki sebekelerde bulunnan MTU/MRU’larin ayarlarini tanimak imkansizdir. Bu yüzden Segmenlerin tüm hesaplara ragmen fraglanlastirilmasi mümkündü (buda istenilmiyen durumdur). Bunun cözümü Path MTU Discovery adli bir modül. Bununla gönderici MTU’suna göre ayarlanmis mümküm olacak en büyük segmen’i göndermeye calisir ve fraglanlasmayi yasaklar (Bu Header’de DF’le sabitlestirilebilinir). Segmen, kücük MTU’su yüzünden fragmanlastirilmasi gereken bir Router(yönlendirici)’e rasladiginda, bir ICMP-hata uyarisi geri gönderilir ve gönderici segmen-büyüklügünü düsürür. Buda hata uyarisi bitnen kadar böyle tekrarlanir.
Bu yöntemin sorunu, Firewall gibi bazi aletler emniyet nedeniyle ICMP haberlerine geri göndermezler. Böylece Gönderici aldigi MTU’nun aliciya kadar mümkün oldugunu inancinda olabilir. Verilerin gelmemesi söz konusu degildir – am her cabaya ragmen fragmanlastirirlar.
1.6.3
Header-(baslik-)büyüklügü
Segmen-büyüklügündeki baska bir hususda Hader-büyüklügüdür. Normal sartlar altinda Header 40 Byte büyüklügündedir (20 Byte IP’den, 20 Byte TCP’den) Ama Header, kendisini büyülten cok sayida secenekler (örnegin Quality of service (servis kalitesi)v.s.) icerir. Headr’in en büyük olabilecegi büyüklük 120Byte’dir (IP’den ve TCP’den 60’ar). Bu ölcülerin büyümesi Segmen-büyüklügünün hesabina katilmasi gerekir.
1.6.4.
Veri-büyüklügü
Son hesaplanmasi gereken husus veri-miktarinin kendisidir. Uygulamalr cok sayida veri gönderme isteginde bulunmalari süresince, Segmen-büyüklügü icin fazla önem tasimaz. Veriler TCP’ye aktarilir, en büyük segmen-büyüklügü icin gereken önemli hususlar hesaba katilir, veriler paketlenir ve IP vasitasiyla gönerilirler.
Bir Uygulamanin az miktarda veri gönderme istegi sorun cikarabilir – TCP belli bir veri miktarinin bir araya gelmesini bekler. Buda, Telnet gibi uygulamalarda tek bir tus kullanimi gönderilmez demektir, bir kaci bir araya geldikten sonra gönderilirler. Telnet gibi bir Ugulamada bu mantikli degildir. Bu yüzden Push-funksiyonu(itme-görevi) mevcutdur. Bir Uygulama, daha fazla veri gelmiyecegini anlarsa, TCP push-göreviyle verilerin hemen gönderilmesinin haberini bildirir. Böylece bu sorunada bir cözüm bulunmaktadir.
1.7. Akis-kontrolü
TCP vasitasiyla iki sistem arasinda iletisim ve veri alis-verisi varsa, TCP’nin devamli veri akisini göndericinin, vericinin, araduraklarin veya fiziksel akis arclarinin özelliklerine göre ayarlayabilmesi imkani olmasi cok önemlidir. Sadece böyle Verilerin hatasiz ulasmasina emin olunabilir.
Iki önemli Modül – bilhassa Alici icin – devamindakilerdir:
Receive Window Sizing (Alis Cerceve ölcegi)
Gönderen bir sistem alicinin izin verdigi kadar veri gönderebilir. Alici, alici-kalibinin ayarlanmasiyla (buda her TCP-segmen’i icerisinde Receive window olarak gönderilir) göndericiden veri miktarini cogaltmasini veya azaltmasini isteyebilir. Alici her hangi bir sebebden dolayi fazla mesgulise, alici-kalibini oldugundan kücük gösterebilir – gönderici aninda gönderilen veri miktarini azaltir. Yeterince menbalar bos oldugunda, alici vericiye büyük alici-kalibini bildirir –gönderici Veri miktarini hemen cogaltabilir.
Burda önemli olan, alicinin alici-kalibinin ansiz bir sekilde kücültmemesidir, cünkü böylece segmenler kaybolabilir (göndericinin onaydan önce veri-transfer miktarinin azaltildigindan haberdar degildir).
Alici, alici-kalibini sifira indirir indirmez gönderici bu sisteme veri göndermez (gönderdigi takdide segmenler alicida silinir). Ve böylece bir zamanlama uygulamasi faaliyte gecer.
Belirli bir Zaman gectikden sonra gönderici yeniden veri göndermeye calisir – onay alamadigi takdirde, zaman belirlemsini ikiye katlar ve tekrar dener. Bu en büyük belirlenemis zaman ölcüsüne ulasilana kadar böyle devam eder (örnegin 64 veya128 saniye).
Alici-kalibini olabilecek en büyügü 65 635 Byte’dir, cünkü TCP-segmenin icerdigi window field (cerceve alani) 16 bit uzunlugundadir. Bu cogu Uygulamalar icin yeterlidir, ama hepsi icin degil (bilhassa cok hizli sebekeler icerisinde). Window scale option’la (cerceve ölcü secenegi) iki sistem aralarinda 30Bit büyüklügünde bir cerceve alanina anlasabilirler, ve böylece olabilecek en büyük (1 Gigabyte büyüklügünde) alici-kalibini kuallanima sahip olurlar.
TCP’nin baslangicinda bu modül Silly Window Syndromlara (aptal cerceve belirtileri) sebep olurdu. Alici sistemleri bazen alici-kalibinin icerdigi verilerin hep cok azini islemislerdi. Bu yüzden serbest alici-kalibi (yani Receive window) kücülüs, ve gönderici Transfer sayisin azaltma mecburiytinde bulunmustur. Bundandirki RFC 1122’de, bir alici, alici-kalibinin icinde olabilecek en büyük bir segmen icin yeri olursa (buda önceden belirlenir –yukariya bakin) sadece o zaman sifirdan büyük bir window field kullanma hakkina sahip olduguna dair, kayit edilmistir.
Buna benzer bir sorun gönderici-sistemlerinde meydana cikmistir. Uygulamarin gönderecegi veri miktari cok düsük oldugunda, cok band-genisligi israf edilmistir. Cünkü, 10Byte büyüklügünde veri 512Byte büyüklügünde bir segmene paketlendigi zaman (segmen-büyüklügü belirlenmis matematiksel bölme-uygulamarina uymasi gerekdiginden geri kalan kismi anlamsiz verilerle doldurulur) büyük bir israf olmus olur. RFC896’da, Nagle algorithmi belirlenmis, bunun verdigi ifadede bir gönderici böyle kücük bir veri miktarinin gönderme iznine sadece, simdiye kadar segmenler onaylanmis ise veya ‘dolu’ bir segmen icin yeterince Veri mevcut ise, sahip olabilir.
Sliding receive windows (kayici alis cerceveleri)
Bununla göndericinin verileri ‘önden gönderme’ imkanina sahiptir. Bu demek oluyorki, en son gönderilmis segmenin (segmen A) onayini almadan bir sonraki segmeni (segmen B) gönderir ve ilk segmenin (segmen A) onayini alacagina güvenir. Gönderici ücüncü bir segmeni ‘önden göndermesi’ icinher zaman iki onaylanmis segmeni bekler.
Bu husus 3.18 no.lu Grafikde aciklanilmistir:
Grafik 3.18
Bu iki modül veriakisindan daha fazla alicinin isine yarar. Öte tarfadan göndericinin veri-sayisini indirebilecek modüllere ihtiyac vardir. Asagi yukari bu dört imkan vardir:
Congestion window sizing (IZDIHAM cerceve ölcegi)
Alicinin alacagi veri miktarini beirleme imknina sahip oldugu gibi (mesguliyet veya fisiksel araci sebeplerinden), bu modül gönderici ve verici (örnegin yönlendirici A) arasindaki aletlerin karsiligidir. Sartlarin verimsiz hale geldiginde ve yönlendirici A aldigi verileri aldigi ayni hizla aktaramazsa, göndericiye bir ICMP Source Quench haberi geri gönderir (Bölüm 3.3.4.4.’e bakiniz). O zaman gönderici congestion cercevesini da düsük ölcekde belirlemesi mecburiyetinder – yani alicinin istikametine da az veri miktari göndermesi gerekir. Eger bunu yapmazsa yönlendirici A’daki sorunlar oldugundan daha cok olur. Congestion avoidance’le (IZDIHAM önleyici) ve slow Start’la (yavas baslama)(asagiya bakiniz) asil veri-transfer-miktarina ulasilmaya calisilir.
Slow Start (Yavas/Agir baslama)
Eger bir kullanici mesafeli bir sistemden örnegin büyük bir veri-miktari trnsfer veya yüklemek isterse, gönderici-sistem veri tüm hiziyla göndermek ister. Ama iki sistem arasinda dargecitler cikarsa, bu göndericiye mutlaka ICMP hata-uyarilarina yol acacaktir (önceki bölümdeki yönlendirici A örnegiyle karsilastirin). Bu Slow Start’la önlenir. Burda kücük bir veri.miktariyla baslanilir ve alicidan alinan her onaydan sonra verilir o sirada gönderilmis miktarda büyütülür. 3.19 no.lu Grafik buu aciklamak ister:
Grafik 3.19
Bu yöntem, ya Yönlendirici A sorun cikararana kadar ve ya gönderilen Veri-miktari Alici-kalibiyla esit olana kadar, uygulanir.
Congestion Avoidance (IZDIHAM önleyici)
Gönderibilinecek veri-miktari her hangi bir nedenden dolayi azalirsa (Congestion Window Sizing’e bak), bu modül devreye gecer ve asil Veri-transfer miktarini geri ayarlamaya calisir. Bu görev sekli Sloe Start’a benzer – farki, Congestion Window büyütülmeden önce bütün transfer edilmis segmenlerin onaylanmis olunmasi gerektigindedir.
Local blocking (Yerel kapama)
Bu en basit modüldür. Burda gönderici bir Uygulamadan aldigi verilerin bütününü red edebilir. TPC’nin ilgili veriler gönderemez hale geldiginde(mesela sebeke sorunu yüzünden), bunu yapmak zorundadir.
TCP (IP’den) giren veri transferini red edmiyecegini söylemekde fayda var. Tek baska yolu, dolu bir Alici-kalibini dolulugu yüzünden gelen Segmenlerin silinmesi ve böylece Uygulamalara aktarilmamasidir.
Bu doküman Martin Puaschitz tarafindan Eric. A Hall referans alinarak yazilmis olup, Haberci grubu adina KINALI_KOC tarafindan Türkçe’ye çevirilmistir.
