Aplikazio geruza | DNS, FTP, HTTP, HTTPS, IMAP, IRC, NFS, NNTP, NTP, POP3, SMB/CIFS, SMTP, SNMP, SSH, Telnet, SIP, gehiago |
Aurkezpen geruza | ASN.1, MIME, SSL/TLS, XML, gehiago |
Saio geruza | NetBIOS, gehiago |
Garraio geruza | SCTP, SPX, TCP, UDP, gehiago |
Sare geruza | AppleTalk, IP, IPX, NetBEUI, X.25, gehiago |
Lotura geruza | ATM, Ethernet, Frame Relay, HDLC, PPP, Token Ring, Wi-Fi, STP, gehiago |
Geruza fisikoa | Kable ardazkide, Zuntz optiko, Pare kordatu, Mikrouhin-sarea, Irrati bidezko sarea, RS-232, gehiago |
*OSI ereduaren arabera |
TCP Transmission Control Protocol-ren siglak dira (euskaraz: Transmisiorako Kontrol Protokoloa).
TCP/IP ereduren garraio mailako konexiora zuzendutako sare protokolo fidagarria dugu, nahiz eta IP protokoloaren sare ez-fidagarrian sostengatzen den.
Bere ezaugarririk nagusienak:
TCP entitate igorleak (erabiltzaileak) eta hartzaileak datuak segmentuetan (garraio mailako paketea) zatikatzen dituzte eta ondorengo baldintzak bete behar dituzte:
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):
0 |
10 |
20 |
30 | ||||||||||||||||||||||||||||
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
3 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
TCP iturburuko portua |
TCP helburuko portua | ||||||||||||||||||||||||||||||
Sekuentzia-zenbakia | |||||||||||||||||||||||||||||||
Onespen-zenbakia | |||||||||||||||||||||||||||||||
HLEN |
Erreserbatua |
Bit-kodeak |
Leihoaren tamaina | ||||||||||||||||||||||||||||
Kontroleko batura |
Presazko portua | ||||||||||||||||||||||||||||||
Aukerak (baldin badaude) |
Betegarri | ||||||||||||||||||||||||||||||
Datuak | |||||||||||||||||||||||||||||||
... |
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 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:
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.
Blokeo egoera bat emateko bi baldintza eman behar dira ezinbestean:
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 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:
+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.
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:
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:
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:
Beraz, i iterazio ondoren RTO-ren balioa hurrengoa izango da: RTOi = RTTis + max {G, 4*RTTid}
Non; RTTis = (1- α) * RTTi-1s + α * Mi
RTTid= (1 - β) * RTTi-1d + β * |Mi – RTTi-1s|
Non, α = 1/8 eta β = 1/4
Aipatu beharrekoa da, RTO-ren balioa 1s baino txikiagoa ateratzen bada, 1s erabiliko dela.
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.
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.