Transmission Control Protocol

TCP/IP ereduren garraio mailako konexiora zuzendutako sare protokolo fidagarria dugu, nahiz eta IP protokoloaren sare ez-fidagarrian sostengatzen den.

Bere ezaugarririk nagusienak:

• Konexiora zuzenduta: Inongo daturik bidali aurretik konexioa ezartzea beharrezkoa da. Konexio honen bidez datuak hurrenkera egokian eta paketeak errepikatu gabe helduko dira helburuko aplikaziora
• Fidagarria: Helbururi heltzen zaion informazioa modu zuzenean heldu dela bermatzeko prozedurak ezartzen ditu

TCP entitate igorleak (erabiltzaileak) eta hartzaileak datuak segmentuetan (garraio mailako paketea) zatikatzen dituzte eta ondorengo baldintzak bete behar dituzte:

• Goiburukoa gutxienez 20 bytez osatuta dago, ondoren datuak datoz. Guztira (datuak + goiburukoa) 64K baino gehiagoko tamaina ezin du eduki, IP datagramaren formatuak ez bailuke onartuko.
• Sare guztiek gehienezko datu tamaina bat (MTU) dute, Kbyte batzuetakoa izaten dela. Segmentuaren tamaina muga honetara egokitzen da. Segmentuak zeharkatu behar duen azpisare baten trama tamaina, segmentuaren tamaina baino txikiagoa bada, bideratzaileek segmentua zatikietan banatzen dute.

Fluxu-kontrola kudeatzeko leiho labainkorreko protokoloa erabiltzen dute TCP entitateek. Protokolo honetan igorleak segmentu bat bidaltzean, kontagailu (erloju) bat martxan jartzen du. Kontagailu honek segmentuaren onespena jasotzeko gehienezko denbora tartea zehazten du. Denbora hau agortuz gero, segmentua berriz igortzen da hartzaileari. Segmentuen zatiak berreraikitzea eta arazoak antzematean segmentua berrigortzea dira garraio-mailaren eginkizunak.

Berton formatua (errenkada bakoitzak 32 bit du):

Aplikazio jakin batek sortutako datuak segmentu baten edo gehiagotan banatzen direla kontatu dugu. Segmentu hauek, IP datagramaren datu eremuan bidaiatzen dute,hots, kapsulatuta. Fluxu-kontrola kontrola kudeatzeko zenbakitzen dira segmentuak. Berton formatua (errenkada bakoitzak 32 bit du):

• TCP iturburuko portua (16 bit). Iturburuko makinaren portu-zenbakia.
• TCP helburuko portua (16 bit). Helburuko makinaren portu-zenbakia.
• Sekuentzia-zenbakia (32 bit). TCP informazioaren korrontearen barruan uneko datuen posizioa adierazten du.
• Onespen-zenbakia (32 bit). Eremu honekin aurretik jasotako byteak zuzen jaso direla adierazteko erabiltzen du helburuko makinak.
• HLEN (4 bit). Goiburuko luzera adierazten du. 32 bitetako multiploetan adierazita, segmentuaren tamaina. Gutxienekoa 5 (1001 bitarrean) litzateke, 20 bytetako datu gabeko segmentuari dagokiona.
• Erreserbatua (6 bit). Etorkizun batean erabiltzeko.
• Bit-kodeak (6 bit). Segmentuaren asmoa zehazten dute.
• • URG. Presazko erakuslearen datuak bilatu eta prozesatu behar dira.
  • ACK. Onespen-segmentua da, beraz onespen-zenbakia kontuan hartzen da. SYN eta FIN kodeekin konexioaren ezarpena eta askapena adierazten dute. Segmentu berberak noranzko baten datuak bidal ditzake eta komunikazioaren beste noranzkoaren onespenak.
  • PSH. Buffer osoa betetzen den arte segmentua buferretan ez gordetzeko erakuslea, honela iritsi ahala aplikazioari bidaliko zaio. Push eragiketa.
  • RST. Uneko konexioa etetea.
  • SYN. Konexio eskaera. Sekuentzia-zenbakia nondik hasiko den adierazten du. ACK kodearekin batera (ACK=1;SYN=1) konexio-eskaerari onespena ematen zaio.
  • FIN. Konexio amaitu nahi dela adierazteko, ez baitaude datu gehiagorik bidaltzeko.
• Leihoaren tamaina (16 bit). Konexio batentzako helburuko makinak onartuko duen buferren tamaina zehazten du.
• Kontroleko batura (24 bit). Uneko segmentuaren erroren kontroleko batura. Iturburuko eta helburuko IPren helbideak ere sartzen dira (sasigoiburua).
• Presazko erakuslea (8 bit). Presazko datuak non hasten diren zehazten du.
• Aukerak (aldakorrak). Aukera hau zehaztuta badago, onartuko den segmenturen gehienezko tamaina zehazten du.
• Betegarri. Eremu honekin segmentua 32 bitetako multiplokoa izatea behartuko litzateke.
• Datuak. Aplikazioari bidaltzen zaion informazioa.

TCP protokoloak datuen fluxu kontrola burutzeko mekanismoak erabiltzen ditu. Mekanismo hauen laguntzarekin igorleak bidalitako datuekin ez da sekula hartzailearen buffer-a saturatuko.

Hartzaileak, igorlearengandik datuak jaso eta baieztatu behar dituenean (datu gehiagorekin edo ACK-ren bitartez), RcvWindow eremuan bere buffer-aren momentu horretako kapazitatea adieraziko dio. Eremu honen balioa dinamikoki aldatzen da transmisio batetik bestera.

Igorleak, jarraian bidaliko dituen datu kopurua, hartzaileak RcvWindow eremuan adierazitako byte kopururaren azpitik mantenduko ditu.

Fluxu kontrola egiteko RcvWindow eremuak leiho irristakorra-ren balioa adierazten du:

• Leihoaren balioa handitu egingo da hartzailearen buffer-a libratzen den heinean.
• Leihoaren balioa txikitu egingo da hartzailearen buffer-a betetzen den heinean.

Hartzaileak igorleari lehioaren balio jakin bat ematen badio (kreditu bat) eta igorleak bidalitako datuek saturazio egoeratik gertu uzten badute ere, hartzaileak ezin dezake hasieran emandako kredituraren murrizketa bat burutu.

Egoera honetatik habiatuz, fluxu kontrolaren ondoriozko blokeo egoera aztertuko da.

Blokeoa eta Persist Timer-a

Blokeo egoera bat emateko bi baldintza eman behar dira ezinbestean:

• Igorle bizkorra – Hartzaile geldoa egoera eman behar da.
• Komunikazioa asimetrikoa da: mutur batean transmititu eta bestean bakarrik baieztatu egingo da.

Baldintza hauek ematen badira eta komunikazioaren uneren batean hartzaileak RcvWindow=0 adierazten badu, igorleak ezin izango dio ezer bidali, eta hartzaileak ezer baiztatzeko ez duenez, ezingo dio adierazi igorleari jasotzeko prest dagoela, beraz, blokeo egoera bat gertatutko da.

Egoera honetatik ateratzeko, igorlean, Persist Timer mekanismoa erabiliko da. Hartzailearen erantzun bat jasotzen denetik denbora tarte batera, 1 byteko segmentuak bidaliko ditu igorleak, hartzailearen buffer-aren egoera ezagutu ahal izateko.

Persist Timer-aren erabilerak, badu bere alde txarra ere, Silly Window Syndrome(SWS)-aren sortzailea baita.

Konexio ezarpena

Konexio kudeaketa TCPn garrantzitsua da, izan ere, TCP konexioaren ezarpenak, jasotako atzerapenak handitu ditzake. Demagun host (bezero) batean exekutatzen ari den prozesu batek beste host (zerbitzari) bateko prozesu batekin konexio bat ezarri nahi duela. Bezero aplikazio prozesuak TCP bezeroari adieraziko dio zerbitzariko prozesu batekin konexioa ezarri nahi duela. Bezeroko TCPak orduan konexioa ezarriko du zerbitzariko TCParekin, 3-way-handshake deritzon ondoko prozedura jarraituz:

• 1. pausoa. TCPren bezeroak TCP segmentu berezi bat bidaltzen dio TCPren zerbitzariari. TCPren zerbitzaria listen bezalako prozedura bat begiztan exekutatzen egongo da, konexioa ezartzeko eskaeren zain. Segmentu berezi honek ez du aplikazio mailako daturik, baina segmentuko goiburuko bit adierazgarrietako bat (flag), SYN bita, batera jarrita dago. Horregatik segmentu berezi honi SYN segmentua deritzo. Gainera bezeroak, sekuentzia hasierako zenbaki bat aukeratuko du (ISN Initial Secuency Number) eta zenbaki hau TCP goiburuko SYN segmentuko sekuentzia zenbakirako eremuan jarri egingo du. Segmentu hau IP datagrama baten enkapsulatu eta zerbitzarira bidali egiten da.

+2. pausoa. IP datagrama zerbitzarira heltzen denean, zerbitzariak SYN segmentua hartu egiten du eta bezeroari konexioaren baieztapenerako segmentu bat bidaliko dio. Segmentu honek ACK bit adierazgarria batera izango du, bezeroak bidalitako SYN segmentuaren baieztapenerako, eta baieztapen zenbakiaren eremuan bezeroaren sekuentzia zenbakia+1 idatziko da, itxaroten gauden hurrengo segmentua hain zuzen ere. Gainera, SYN bita ere batera izango du segmentu honek, zerbitzariak bere sekuentzia hasierako zenbakia ere bidaliko diolako bezeroari sekuentzia zenbakirako eremuan. Segmentu berezi honi SYNACK segmentua deritzo. Segmentu hau bidaltzearekin batera, zerbitzariak beharrezko lekua erreserbatu egiten du konexio aldagai eta bufferretarako.

• 3. pausoa. Zerbitzaritik konexioarekiko baieztapeneko segmentua jaso bezain laster, bezeroak buffer eta konexioko aldagaietarako lekua erreserbatu egiten du. Orduan, bezeroak zerbitzariari beste segmentu bat bidaliko dio, baieztapeneko zenbakitzat aurreko segmentuaren zenbakia+1 izango duena, zerbitzariak bidali berri duen konexiorako baieztapeneko segmentua baieztatuz. Bezeroarentzat konexioa jada ezarrita dago. Zerbitzariarentzat konexioa ezarrita egongo da hirugarren baieztapeneko segmentu hau jasotzen duenean.

Konexio askapena

Konexio askapena eraldaturiko 3-way-handshake deritzona, izatez 4 pauso baitauzka. Konexioaren askapena bezero edo zerbitzariak hasi dezake (edo biak aldi berean) bidaltzeko datu gehiagorik ez dutenean. Konexioa bukatzean host-etako errekurtsoak (buffer eta aldagaiak) askatu egiten dira. Demagun bezeroak hasten duela konexioa askatzeko prozesua:

• 1. pausoa: Bezeroak TCP goiburuko FIN bita batera duen kontroleko segmentua bidaltzen dio zerbitzariari konexioa bukatzeko prest dagoela adierazteko. Segmentu hau ere erabili dezake aurretiaz jasotako datuak baieztatzeko, kasu horretan ACK bita ere piztuta izango du eta dagokion sekuentzia zenbakia baieztapeneko zenbakiaren eremuan.

• 2. pausoa: Zerbitzariak ACK bita aktibatuta daukan segmentu baten bidez adieraziko dio bezeroari FIN segmentua ondo jaso duela. Ondoren, zerbitzaria konexioa ixteko prest badago, bidaltzeko datu gehiago ez baditu, FIN bita batera duen segmentua bidaliko dio bezeroari, bera ere konexioa askatzeko prest dagoela adieraziz. Prest ez badago eta bidaltzeko datu gehiago baditu, geroraturiko konexio askapena emango da.

• 3. pausoa: Bezeroak FIN segmentua jasotzean, ACK bita batera duen segmentu batez erantzungo du FIN segmentua ondo jaso duela adierazteko. Une honetan, bezeroa neurtutako itxaronaldi egoeran sartuko da. Itxaronaldi hau 2*MSL luzerakoa izaten da, MSL segmentuaren bizitza denbora maximoa delarik (Maximun Segment Life). Egoera honetan bezeroak ezin du daturik bidali, soilik berandu datozen datu segmentuak onartu eta baieztatu edota zerbitzariak galdutzat eman eta berriro bidali duen FIN segmentuetarako baieztapenak bidali. Itxarote honen arrazoia, berandu edo galduta ibili diren datu segmentuei heltzeko aukera ematea da, alde batetik. Eta bestetik, konexioa arinegi ez askatzea, beste konexio berri batek konexio honen socket berdina segituan erabili ez dezan eta berandu etor daitezkeen datu segmentu horiek konexio berri horretako datutzat har ez ditzan.

• 4. pausoa: Zerbitzariak bezeroak bidalitako azkeneko ACK segmentua hartu bezain laster konexioa bere partetik ere askatuta egongo da.

Geroraturiko konexio askapena

Konexio askapenerako kasuan, esan bezala, TCP konexioan datuak bi noranzkoetan bidali daitezkeenez, bi muturrek prest egon behar dute konexioa guztiz askatzeko. Bezeroak FIN segmenua bidaliz adierazten dio zerbitzariari konexioa askatzeko prest dagoela, ez dituela bidaltzeko datu gehiago. Zerbitzaria oraindik konexioa askatzeko prest ez badago, bidaltzeko datu gehiago dituelako, geroraturiko konexio askapena emango da.

Zerbitzariak bezeroaren FIN segmentua ACK bita batera duen segmentu bat bidaliz baieztatuko du, baina ez du jarraian FIN segmenturik bidaliko, baizik eta oraindik bidaltzeke dituen datu segmentuak. Bezeroa, konexioa ixteko erabakia hartu duen muturra izanik, datu hauek hartzean nahitaez erantzun beharko du dagozkien ACK segmentuak bidaliz ondo heldu zaizkiola egiaztatzeko, baina bere partetik informazio berririk ezingo du bidali. Izan ere, mutur honek bere half-close egin du jada, eta ez dago atzera egiterik.

Zerbitzariak bidaltzeke zituen datuak bidalitakoan, FIN segmentua bidaliko du, orain bai, konexioa ixteko prest dagoela adieraziz. FIN hori jasotzean bezeroak ACK baieztapen segmentua bidaliko dio zerbitzariari eta, konexio askapeneko kasu normalean bezala, neurtutako 2*MSL luzerako itxarote egoeran sartuko da. Denbora hori pasa eta gero konexioa askatutzat emango du bezeroak. Zerbitzariak, bestalde, bezeroaren azkeneko ACK segmentua jaso bezain laster konexioa askatuko du.

TCP-k kontagailu ezberdinak erabiltzen ditu datuen entrega ondo egiten dela kontrolatzeko. Horietariko bat birtrasmizio kontagailua da, igorleak bidaltzen duen segmentu bakoitzarekin erlazionaturiko kontagailu bat pizten du, kontagailu hau amaitzerakoan, berarekin erlazionatutako segmentuaren ACK-rik ez bada jaso, segmentu horren birtrasmizioa gertatuko da. Beraz, TCP-ren eraginkortasunari begira, kontagailu honen iraupenaren kalkulua oso garrantzitsua izango da. Kalkulu hau egiteko bi aldagai definituko ditugu:

• RTT (Round Trip Time):segmentu bat bidaltzen denetik baieztatua den arte pasa den denbora (dagokion ACK-a jaso arte).
• RTO (Retransmission Time Out):kontagailuaren luzera.

Argi dago RTO RTT baino txikiagoa ezin dela izan, bestela baieztapena heldu aurretik kontagailua amaituko delako, beharrezkoak ez diren bistransmizioak piztuz. Hasiera batean, pentsa dezakegu logikoena, RTO=RTT egitea dela, baina segmentuen atzerapena ez da konstante mantentzen, beraz, RTO aurreko transmisioaren RTT-ra berdintzen badugu, gerta daiteke gure oraingo RTT handiagoa izatea eta beharrezkoak ez diren birtransmizioak egotea. RTO-ren balioa handiegia bada, ordea, denbora asko pasako da galera eman denetik birtransmizioa piztu arte, eta horrek errekurtsoen galera suposatuko du. Beraz, egoera hauen arteko oreka bat bilatu beharko da, RTO RTT baino handiagoa izan behar da, baina beti ere ordena berekoa. RTO-ren kalkulua egiteko, hurrengo definizioak egingo ditugu:

• RTT (Round Trip Time):esan bezala, segmentua bidali denetik bere baieztapena jasotzen den momenturarte pasatako denbora izango da, neurtutako azken RTT-a M (measured ) izango da.
• RTT^s:Leundutako RTT, hasieran neurturiko lehenengo RTTarekin berdintzen da, M₀, RTT₀ ^s = M₀.
• RTT^d:Leundutako RTT-aren desbideraketa, hasieran RTT₀^d = M₀/2
• RTO₀ = RTT₀^s + max {G,4*RTT₀^d}, non G baseko kontagailuaren timeout tartea den.

Beraz, i iterazio ondoren RTO-ren balioa hurrengoa izango da: RTO_i = RTT_i^s + max {G, 4*RTTid}

Non; RTT_i^s = (1- α) * RTT_i-1^s + α * M_i

RTT_i^d= (1 - β) * RTT_i-1^d + β * |M_i – RTT_i-1^s|

Non, α = 1/8 eta β = 1/4

Aipatu beharrekoa da, RTO-ren balioa 1s baino txikiagoa ateratzen bada, 1s erabiliko dela.

Backoff exponential algoritmoa

Birtransmizioak ematen direnean, RFC 793-k dioenez, momentu horretan daukagun RTO-a erabili behar da. Kongestioa dagoenean berriz, metodo hau ez da ona izango, kongestioa RTT-an gorapenak eragiten baitditu. Horrela, beharrezkoak ez diren birtsansmizioak sortuko dira, birtsansmititutako segmentuak ez direnez kontuan hartzen RTO-ren balioa ez delako eguneratuko. Egoera hau ekiditzeko exponential Backoff algoritmoa erabiltzen da. Backoff mekanismoa ezartzen da, pakete beraren ondoz ondoko birtransmizioak denbora banatzeko, sareari kongestio egoera konpontzeko denbora emanez. Algoritmo honek, hasieran aurreko formulekin kalkulatutako balioa erabiltzen du. Birtransmizio bat ematen denean berriz, TCP-k birtransmizio denbora handitzen du, RTO bikoiztuz birtransmizio bakoitzeko. Parametro honek balio handiegi bat ez izateko, normalean RTO-ren balioa 64 s-ra mugatzen da.

Karn-EN algoritmoa

Bidalitako segmentu baten baieztapen bat jasotzen denean, ezin daiteke bereizi hau bidalitako segmentu originalaren baieztapena den edo birtsansmizioaren baieztapena den. Arazo hau ekiditzeko Karn-en algoritmoa erabiltzen da. Karn-en algoritmoaren arabera, birtsansmititutako segmentuentzat ez da RTT-ren neurketarik egingo, horrela ez dira RTTs eta RTTd-ren balioak eguneratuko eta beraz, RTO ere ez.

• Andrew S. Tanenbaum, Konputagailu-sareak (3. ed 2002), EHU ed.
• [RFC 793]
• KUROSE, J. F.; ROSS, K. W. REDES DE COMPUTADORES. Un enfoque descendente basado en Internet. Segunda edición. Pearson Educación, Madrid, 2004. ISBN 978-84-7829-061-1. Kurose/Ross Computer Networking

• IP helbide
• UDP
• TCP/IP eredu
• Sare protokolo
• OSI eredua
• Sare protokolo
• Azpisare-maskara
• Internet
• Intranet
• Estranet
• Atzipen protokoloak

• TCP/IP-ri buruzko liburua euskaraz