TCP/IP protokol stek je skup protokola razvijen da omogući umreženim računarima da dele resurse putem mreže. Razvijen je od strane agencije DARPA u okviru ARPANET-a ranih 1970ih. Ovaj protokol je podržavao niz transportnih i prosleđujućih servisa i obezbeđivao je vrlo pouzdan transport podataka. Već u početcima se pokazao kao dobar pri transferu fajlova, ali pokazivao je nedostatke pri radu sa nekim mrežnim aplikacijama, a posebno pri radu sa packet voice-om iz 1970-te, što je pokazalo da u nekim slučajevima gubitci paketa ne bi trebali biti korigovani nego ostavljeni aplikaciji da se nosi sa njima. To je dovelo do reorganizacije originalnog TCP protkola, u tri nova, jedan jednostavan protokol IP koji bi bio zadužen za adresiranje i prosleđivnje pojedinih paketa, odvojenog TCP protokola koji bi podržavao servise kao što su kontrola toka i podrška u slučaju gubitka paketa.
TCP (engl. Transmition control protocol) je protokol koji pripada transportnom sloju OSI referentnog modela, ima za ulogu da obezbezbedi pouzdan transfer podataka u IP okruženju. Između ostalih servisa koje nudi, neki su: pouzdanost, efikasna kontrola toka podataka, operisanje u ful-dupleksu (istovremeno slanje i primanje podataka) i multipleksiranje koje omogućava istovremen rad niza procesa sa viših slojeva putem jedne konekcije. TCP vrši transver podataka kao nestrukturisan niz bajtova koji se identifikuju sekvencom. Ovaj protokol grupiše bajtove u segmente dodeli im broj sekvence, aplikacijama dodeli broj porta i prosledi ih IP protokolu.
TCP konekcija
Za TCP se kaže da je sa konekcijom zato što pre početka slanja podataka iz jedne aplikacije u drugu, ta dva procesa moraju prvo da se “upoznaju” – tj. moraju jedan drugom da pošalju neke uvodne segmente da bi se uspostavili parametri transfera podataka koji sledi. Prilikom uspostavljanja TCP konekcije obe strane će postaviti vrednosti za mnoge promenljive TCP stanja. TCP “konekcija” nije TDM ili FDM vod sa kraja na kraj kakvi postoje u mreži sa komutacijom vodova. Ona takođe nije ni virtuelno kolo, pošto se stanje konekcije u potpunosti čuva u krajnjim sistemima. Protokol TCP se izvršava samo u krajnjim sistemima ali ne i na usputnim delovima mreže kao što su ruteri i mostovi, na primer. Takođe, ti usputni elementi ne održavaju stanje TCP konekcije. U suštini, usputni ruteri nisu svesni postojanja TCP konekcije jer vide samo datagrame. TCP konekcija obezbeđuje transfer podataka u punom dupleksu. To znači sledeće: ako postoji TCP konekcija između dva procesa na različitim računarima, podaci iz aplikacionog sloja mogu da teku istovremeno u oba smera – od A ka B i suprotno.
Za TCP se kaže da je sa konekcijom zato što pre početka slanja podataka iz jedne aplikacije u drugu, ta dva procesa moraju prvo da se “upoznaju” – tj. moraju jedan drugom da pošalju neke uvodne segmente da bi se uspostavili parametri transfera podataka koji sledi. Prilikom uspostavljanja TCP konekcije obe strane će postaviti vrednosti za mnoge promenljive TCP stanja. TCP “konekcija” nije TDM ili FDM vod sa kraja na kraj kakvi postoje u mreži sa komutacijom vodova. Ona takođe nije ni virtuelno kolo, pošto se stanje konekcije u potpunosti čuva u krajnjim sistemima. Protokol TCP se izvršava samo u krajnjim sistemima ali ne i na usputnim delovima mreže kao što su ruteri i mostovi, na primer. Takođe, ti usputni elementi ne održavaju stanje TCP konekcije. U suštini, usputni ruteri nisu svesni postojanja TCP konekcije jer vide samo datagrame. TCP konekcija obezbeđuje transfer podataka u punom dupleksu. To znači sledeće: ako postoji TCP konekcija između dva procesa na različitim računarima, podaci iz aplikacionog sloja mogu da teku istovremeno u oba smera – od A ka B i suprotno.
TCP konekcija je uvek point-to-point (od tačke do tačke), tj. između pojedinačnog pošiljaoca i pojedinačnog primaoca. Nije moguće “višeznačno rutiranje”, odnosno slanje podataka od jednog pošiljaoca do više primalaca. Uzećemo za primer da proces koji se izvršava na jednom računaru želi da uspostavi konekciju sa procesom koji se izvršava na drugom računaru. Proces koji započinje konekciju naziva se klijent a proces koji odgovara naziva se server. Klijentski aplikacioni proces prvo obaveštava klijentski transportni sloj da želi da uspostavi konekciju sa procesom na serveru. Nakon toga, transportni sloj u klijentu prelazi na proces uspostavljanja TCP konekcije sa TCP-om na serveru. Klijent prvo šalje poseban TCP segment, server odgovara drugim posebnim TCP segmentom i na kraju klijent opet šalje poseban TCP segment. Prva dva segmenta ne sadrže nikakve “korisne podatke”, tačnije nikakve podatke aplikacijskog sloja. Treći segment već može da sadrži takve podatke. S obzirom da se odvija u tri koraka, ovaj postupak uspostavljanja konekcije se često naziva sinhronizovanjem u tri koraka (“3 way handshake”, popularniji naziv na engleskom jeziku). Na sledećoj slici možemo videti izgled sinhronizacije u tri koraka.
Klijentski proces šalje tok podataka kroz soket (engl. socket, vrata procesa). Nakon prolaska podataka kroz soket, oni se nalaze u rukama TCP-a koji se izvršava na klijentu. TCP usmerava ove podatke u otpremnu privremenu memoriju te konekcije, a ta memorija se rezerviše tokom početnog sinhronizovanja u tri koraka. S vremena na vreme, TCP zahteva delove podataka iz otpremne memorije, za šta čak ni u TCP specifikaciji ne postoje tačni podaci. Kaže se da TCP treba da “šalje podatke u segmentima prema sopstvenom nahođenju”. MSS (Maximum Segment Size) je maksimalna količina podataka koja može da se stavi u jedan segment i zavisi od implementacije TCP-a na određenom operativnom sistemu a može se i manuelno konfigurisati. Treba uočiti da je MSS maksimalna količina podataka aplikacionog sloja u segmentu, a ne i veličina segmenta u kom su uključena i zaglavlja.
TCP dopunjava svaki komad klijentskih podataka jednim TCP zaglavljem i tako pravi TCP segmente. Segmenti se predaju naniže mrežnom sloju gde se pojedinačno enkapsuliraju u IP datagrame mrežnog sloja, a zatim se IP datagrami šalju u mrežu. Iz ovoga vidimo da se TCP konekcija sastoji od privremene memorije, promenljivih i soketa konekcije za proces. Pri završetku slanja podataka, server šalje poruku sa podešenim kontrolnim bitom FIN=1 (engl. FINish). Veza od servera ka klijentu se prekida time što klijent na slanje ovakve poruke odgovara sa porukom sa podešenim kontrolnim bitom ACK=1 (potvrda o prijemu). Ukoliko i klijent želi zatvoriti konekciju on isto tako šalje poruku sa podešenim bitom FIN=1. Konačno obostrano prekidanjr veze se potvrđuje od strane servera koji odgovara sa porukom u čijem je zaglavlju podešen bit ACK=1.
Struktura TCP segmenta
TCP segment sastoji se od više polja zaglavlja i jednog polja podataka. Polje podataka sadrži jedan komad aplikacijskih podataka. Kada TCP šalje neku veliku datoteku, kao što je recimo slika na web stranici, on obično deli datoteku na jednake delove veličine MSS-a (osim poslednjeg paketa, koji je obično manji od veličine MSS, jer se automatski popunjava do velićine fajla). Interaktivne aplikacije često prenose delove podataka koji su manji od MSS, kao na primer Telnet. Na sledećoj slici možemo videti strukturu TCP segmenta.
TCP segment sastoji se od više polja zaglavlja i jednog polja podataka. Polje podataka sadrži jedan komad aplikacijskih podataka. Kada TCP šalje neku veliku datoteku, kao što je recimo slika na web stranici, on obično deli datoteku na jednake delove veličine MSS-a (osim poslednjeg paketa, koji je obično manji od veličine MSS, jer se automatski popunjava do velićine fajla). Interaktivne aplikacije često prenose delove podataka koji su manji od MSS, kao na primer Telnet. Na sledećoj slici možemo videti strukturu TCP segmenta.
Zaglavlje sadrži broj izvornog porta (source port) i broj odredišnog porta (destination port), koji se koriste za multipleksiranje i demultipleksiranje podataka iz aplikacija gornjeg sloja i prema njima, a sadrži i polje kontrolnog zbira. Zaglavlje TCP segmenta sadrži i sledeća polja:
1. Polje rednog broja (Sequence number, 32 bits) i polje broja potvrde (Acknowledgement number, 32 bits) koje TCP pošiljalac i primalac koriste za implementiranje usluge pouzdanog transfera podataka.
2. Polje prijemnog prozora (Window size, 16 bits) koje se koristi za kontrolu toka.
3. Polje dužine zaglavlja (TCP header length, 4 bits) koje sadrži dužinu TCP zaglavlja u 32-bitnim rečima. Zaglavlje može biti promenljive dužine zbog polja TCP opcija (ukoliko je polje opcija prazno, što je čest slučaj, dužina zaglavlja je 20 bajtova).
4. Polje opcija (Options, 0 ili više 32-bitnih reči) je promenljive dužine koje se koristi prilikom pregovaranja pošiljaoca i primaoca o maksimalnoj dužini segmenta (MSS) ili kao faktor za podešavanje prozora koji se koristi u mrežama velike brzine.
5. Polje oznaka sadrži 6 bitova (URG, ACK, PSH, RST, SYN, FIN). Ukoliko je ACK bit postavljen, označava da je vrednost broja potvrde važeća i da je u pitanju segment potvrde. RST, SYN i FIN se koriste prilikom uspostavljanja i prekidanja konekcije. Ukoliko je bit PSH postavljen, primalac bi trebao istog trenutka da podeli podatke gornjem sloju. URG (urgent) se koristi da bi se označilo da ima podataka koje je gornji sloj na strani pošiljaoca označio kao hitne. Lokacija poslednjeg bajta ovih poruka je određena 16-bitnim poljem pokazivača hitnih podataka (urgent pointer).
Dva najvažnija polja u zaglavlju TCP segmenta su redni broj i broj potvrde i ta polja predstavljaju bitan deo usluge pouzdanog transfera podataka. TCP posmatra podatke kao nestrukturisan ali uređen tok bajtova. Tako i koristi redne brojeve pa se oni odnose na tok prenetih bajtova a ne na niz prenetih segmenata. Iz toga zaključujemo da je redni broj segmenta u stvari redni broj prvog bajta u segmentu unutar toka bajtova.
1. Polje rednog broja (Sequence number, 32 bits) i polje broja potvrde (Acknowledgement number, 32 bits) koje TCP pošiljalac i primalac koriste za implementiranje usluge pouzdanog transfera podataka.
2. Polje prijemnog prozora (Window size, 16 bits) koje se koristi za kontrolu toka.
3. Polje dužine zaglavlja (TCP header length, 4 bits) koje sadrži dužinu TCP zaglavlja u 32-bitnim rečima. Zaglavlje može biti promenljive dužine zbog polja TCP opcija (ukoliko je polje opcija prazno, što je čest slučaj, dužina zaglavlja je 20 bajtova).
4. Polje opcija (Options, 0 ili više 32-bitnih reči) je promenljive dužine koje se koristi prilikom pregovaranja pošiljaoca i primaoca o maksimalnoj dužini segmenta (MSS) ili kao faktor za podešavanje prozora koji se koristi u mrežama velike brzine.
5. Polje oznaka sadrži 6 bitova (URG, ACK, PSH, RST, SYN, FIN). Ukoliko je ACK bit postavljen, označava da je vrednost broja potvrde važeća i da je u pitanju segment potvrde. RST, SYN i FIN se koriste prilikom uspostavljanja i prekidanja konekcije. Ukoliko je bit PSH postavljen, primalac bi trebao istog trenutka da podeli podatke gornjem sloju. URG (urgent) se koristi da bi se označilo da ima podataka koje je gornji sloj na strani pošiljaoca označio kao hitne. Lokacija poslednjeg bajta ovih poruka je određena 16-bitnim poljem pokazivača hitnih podataka (urgent pointer).
Dva najvažnija polja u zaglavlju TCP segmenta su redni broj i broj potvrde i ta polja predstavljaju bitan deo usluge pouzdanog transfera podataka. TCP posmatra podatke kao nestrukturisan ali uređen tok bajtova. Tako i koristi redne brojeve pa se oni odnose na tok prenetih bajtova a ne na niz prenetih segmenata. Iz toga zaključujemo da je redni broj segmenta u stvari redni broj prvog bajta u segmentu unutar toka bajtova.
PRIMER: proces u hostu A šalje niz podataka procesu u hostu B, npr. 500.000 byte. Host A će implicitno numerisati svaki byte. Ako je max veličina segmenta 1000 byte, biće 500 segmenata • Ako je brvi bajt numerisan sa 0, prvi segment dobija redni broj 0, drugi 1000, treći 2000 itd. • Ack polje sadrži redni broj bajta koji se sledeći očekuje da se primi (npr. ako je host primio sve bajtove od 0 do 999, ack će sadržati 1000
Procena vremena povratnog puta i tajm-aut
TCP za oporavak od izgubljenih segmenata koristi mehanizam tajm-aut/ponovljeno stanje. Iako je sama koncepcija ovog mehanizma vrlo jednostavna, prilikom implementiranja u protokolu dolazi do mnogih pitanja. Najočiglednije je pitanje dužine intervala za tajm-aut. Jasno je da tajm-aut mora biti veći od vremena povratnog puta konekcije (RTT), tj. Vremena od kad se segment pošalje dok ne stigne njegova potvrda. U suprotnom bi dolazilo do nepotrebnih ponavljanja.
TCP za oporavak od izgubljenih segmenata koristi mehanizam tajm-aut/ponovljeno stanje. Iako je sama koncepcija ovog mehanizma vrlo jednostavna, prilikom implementiranja u protokolu dolazi do mnogih pitanja. Najočiglednije je pitanje dužine intervala za tajm-aut. Jasno je da tajm-aut mora biti veći od vremena povratnog puta konekcije (RTT), tj. Vremena od kad se segment pošalje dok ne stigne njegova potvrda. U suprotnom bi dolazilo do nepotrebnih ponavljanja.
Procena vremena povratnog puta
Ono što bi trebali da znamo da bismo mogli da razumemo upravljanje TCP tajmerom je kako TCP procenjuje vreme povratnog puta između pošiljaoca i primaoca. Uzorak vremena povratnog puta RTT za jedan segment naziva se SampleRTT i predstavlja trajanje od trenutka slanja segmenta do prijema potvrde tog segmenta. Uglavnom se ne meri za svaki preneti segment i u svakom trenutku se pravi samo po jedan uzorak SampleRTT, tako da se dobija po jedna nova vrednost približno jedanput tokom svakog pojedinačnog povratnog puta. Takođe, nikada se ne izračunava SampleRTT za segment koji se šalje ponovo. Ono što se odmah zaključuje je da će se vrednost SampleRTT menjati od segmenta do segmenta, što zavisi od zagušenja na ruterima i od opterećenja krajnjih sistema. Da bi se procenio tipični RTT uzima se prosek dobijen od više vrednosti SampleRTT. TCP stalno izračunava taj prosek koji se naziva EstimatedRTT i ažurira ga svaki put kada dobije novi SampleRTT po sledećoj formuli:
Ono što bi trebali da znamo da bismo mogli da razumemo upravljanje TCP tajmerom je kako TCP procenjuje vreme povratnog puta između pošiljaoca i primaoca. Uzorak vremena povratnog puta RTT za jedan segment naziva se SampleRTT i predstavlja trajanje od trenutka slanja segmenta do prijema potvrde tog segmenta. Uglavnom se ne meri za svaki preneti segment i u svakom trenutku se pravi samo po jedan uzorak SampleRTT, tako da se dobija po jedna nova vrednost približno jedanput tokom svakog pojedinačnog povratnog puta. Takođe, nikada se ne izračunava SampleRTT za segment koji se šalje ponovo. Ono što se odmah zaključuje je da će se vrednost SampleRTT menjati od segmenta do segmenta, što zavisi od zagušenja na ruterima i od opterećenja krajnjih sistema. Da bi se procenio tipični RTT uzima se prosek dobijen od više vrednosti SampleRTT. TCP stalno izračunava taj prosek koji se naziva EstimatedRTT i ažurira ga svaki put kada dobije novi SampleRTT po sledećoj formuli:
EstimatedRTT = (1- a)*EstimatedRTT + a*SampleRTT
Vidimo da je nova vrednost EstimatedRTT jednaka zbiru prethodne vrednosti EstimatedRTT i nove vrednosti SampleRTT. Prema dokumenti RFC 2988, preporučena vrednost promenljive alfa je 0,125 pa se gornja formula može napisati na sledeći način:
EstimatedRTT = 0,875*EstimatedRTT + 0,125*SampleRTT
Osim procene trajanja povratnog puta RTT, važno je imati i kvantitativnu meru varijacije RTT-a. Već pomenuti dokument [RFC 2988] definiše varijaciju vremena povratnog puta, DevRTT, kao procenu standardne devijacije SampleRTT od EstimatedRTT.
DevRTT = (1-b)*DevRTT + b*|SampleRTT-EstimatedRTT|
Vidimo da je DevRTT eksponencijalno ponderisan klizni prosek razlike između vrednosti SampleRTT i EstimatedRTT. Preporučena vrednost za b je 0,25.
Nakon što smo izračunali vrednosti EstimatedRTT i DevRTT, sada ćemo videti koju bi vrednost trebalo uzeti kao TCP-ov interval za tajm-aut. Jasno je da bi taj interval trebao da bude veći ili jednak parametrima EstimatedRTT, ali ne bi smeo ni da bude mnogo veći jer TCP ne bi dovoljno brzo ponovo slao segment u slučaju gubitka, čime bi se u aplikaciji značajno povećalo kašnjenje usled gubitka podataka. Stoga, zaključujemo da interval za tajm-aut treba da bude jednak EstimatedRTT plus neka rezerva. Rezerva bi trebalo da bude velika ukoliko vrednosti SampleRTT mnogo variraju, a mala u slučaju male varijacije. Vidimo da će nam za ovo koristiti parametri DevRTT koji smo prethodno izračunali. Konačno, dobija se interval tajm-auta za ponovno slanje po sledećoj formuli:
TimeoutInterval = EstimatedRTT + 4*DevRTT
Postoje tri glavna događaja u vezi sa inicijalnim i ponovnim slanjem podataka:
1. Stizanje podataka odozgo od aplikacije
Nakon nastupanja prvog glavnog događaja, TCP prima podatke od aplikacije, enkapsulira ih u segment i predaje segment IP-u. Primećujemo da svaki segment sadrži redni broj, kao što je ranije objašnjeno. Takođe, vidimo da TCP pokreće tajmer (ukoliko već nije uključen) kada preda segment u IP i nakon toga setuje redni broj sledećeg segmenta, dodajući na postojeći redni broj dužinu segmenta. Interval ovog tajmera je TimeoutInterval, čija je vrednost izračunata na osnovu vrednosti parametara EstimatedRTT i DevRTT, po formuli u odeljku 4.
2. Tajm-aut
Drugi glavni događaj je tajm-aut, na koji TCP reaguje tako što ponovo šalje segment koji ga je izazvao i zatim ponovo pokreće tajmer, kao što se i može videti na slici.
3. Stizanje ACK-a
Treći važan događaj koji TCP pošiljalac mora da obezbedi je pristizanje segmenata potvrde (ACK) od primaoca (ovo je segment koji čija je vrednost 1 u ACK polju, odnosno setovan je). Kada nastupi ovaj događaj, TCP poredi ACK vrednost y sa svojom promenljivom SendBase (SendBase predstavlja redni broj najstarijeg nepotvrđenog bajta, pa je stoga SendBase-1 poslednji bajt kod primaoca za koji se zna da je primljen pravilno). Znamo da TCP koristi kumulativne potvrde pa tako y potvrđuje prijem svih bajtova pre bajta broj y. Ako je y > SendBase, taj ACK potvrđuje samo jedan ili više prethodno nepotvrđenih segmenata i tako se ažurira promenljiva SendBase. Na kraju, ponovo se pokreće tajmer ukoliko ima još nekih nepotvrđenih segmenata.
1. Stizanje podataka odozgo od aplikacije
Nakon nastupanja prvog glavnog događaja, TCP prima podatke od aplikacije, enkapsulira ih u segment i predaje segment IP-u. Primećujemo da svaki segment sadrži redni broj, kao što je ranije objašnjeno. Takođe, vidimo da TCP pokreće tajmer (ukoliko već nije uključen) kada preda segment u IP i nakon toga setuje redni broj sledećeg segmenta, dodajući na postojeći redni broj dužinu segmenta. Interval ovog tajmera je TimeoutInterval, čija je vrednost izračunata na osnovu vrednosti parametara EstimatedRTT i DevRTT, po formuli u odeljku 4.
2. Tajm-aut
Drugi glavni događaj je tajm-aut, na koji TCP reaguje tako što ponovo šalje segment koji ga je izazvao i zatim ponovo pokreće tajmer, kao što se i može videti na slici.
3. Stizanje ACK-a
Treći važan događaj koji TCP pošiljalac mora da obezbedi je pristizanje segmenata potvrde (ACK) od primaoca (ovo je segment koji čija je vrednost 1 u ACK polju, odnosno setovan je). Kada nastupi ovaj događaj, TCP poredi ACK vrednost y sa svojom promenljivom SendBase (SendBase predstavlja redni broj najstarijeg nepotvrđenog bajta, pa je stoga SendBase-1 poslednji bajt kod primaoca za koji se zna da je primljen pravilno). Znamo da TCP koristi kumulativne potvrde pa tako y potvrđuje prijem svih bajtova pre bajta broj y. Ako je y > SendBase, taj ACK potvrđuje samo jedan ili više prethodno nepotvrđenih segmenata i tako se ažurira promenljiva SendBase. Na kraju, ponovo se pokreće tajmer ukoliko ima još nekih nepotvrđenih segmenata.
Kontrola toka
Da bi se eliminisala mogućnost da pošiljalac preplavi primaočevu privremenu memoriju, TCP svojim aplikacijama obezbeđuje mogućnost kontrole toka. Kontrola toka je u stvari usluga usklađivanja brzine – usklađuje brzinu kojom pošiljalac šalje sa brzinom kojom aplikacija čita. TCP pošiljalac može se usporiti i zbog zagušenja unutar IP mreže i ta vrsta kontrole naziva se kontrola zagušenja. Cilj kontrole zagušenja je održavanje opterećenja mreže ispod kapaciteta mreže, tj. regulacija broja paketa u mreži ispod nivoa pri kome performanse mreže počinju naglo da padaju. TCP omogućava kontrolu toka tako što se kod pošiljaoca održava promenljiva zvana prijemni prozor. Ta promenljiva služi da pošiljalac može da nasluti koliko ima mesta u privremenoj memoriji primaoca.
Tokom života TCP konekcije, protokol TCP koji se izvršava na svakom računaru, prolazi kroz različita TCP stanja. Na slicici se vidi uobičajen niz stanja kroz koje prolazi TCP klijent. Početno stanje je Closed, zatim kada pošalje segment SYN prelazi u stanje SYN_SENT. Pošto primi segment ACK od servera, prelazi u stanje ESTABLISHED i tada šalje i prima segmente koji sadrže korisne podatke. Ukoliko želi da zatvori konekciju, šalje segment FIN i prelazi u stanje FIN_WAIT_1 i očekuje od servera potvrdu. Nakon primanja potvrde, ulazi u stanje FIN_WAIT_2 i čeka na segment od servera u kom je FIN bit jednak jedinici. Nakon primljenog FIN segmenta od servera, prelazi u stanje TIME_WAIT, koje zavisi od implementacije. Nakon toga, konekcija je i zvanično zatvorena.
O TCP-u bi verovatno moglo još dosta da se priča, ovo je veći deo mog seminarskog. Uskoro možda i nastavak. Do sledećeg čitanja, pozdrav!
Нема коментара:
Постави коментар