1

Računarske mreže PREDAVANJE 6

Transportni sloj TCP / IP modela – Transport Layer

Transportni sloj u OSI modelu omgudava peer entitetima na izvorišnom i odredišnom hostu odvijanje

konverzacije. Osnovna funkcija transportnog sloja je da prihvata podatke sloja iznad sebe, razdvaja ih u

manje jedinice ako je potrebno, proslijeđuje ih mrežnom sloju, i osigurava da svi dijelovi stignu ispravno

na drugi kraj. Sve ovo mora biti urađeno efikasno i na način koji izolira više slojeve od neizbježnih

promjena u hardware-skoj tehnologiji tokom vremena.

Slika. Transportni sloj u OSI modelu

Transportni sloj, također, odlučuje koji tip usluge de pružiti sesijskom sloju, i u konačnici korisnicima

mreže. Najpopularniji tip transportne konkcije je point-to-point (konkcija tačka-tačka), error-free

(pouzdan) kanal koji dostavlja poruke, odnosno bajte, u onom redu u kojem su poslani. Međutim,

postoje i drugi tipovi transportne usluge, kao što je transport izoliranih poruka bez garancije o

redoslijedu njihovog pristizanja, kao i broadcast poruka na više odredišta. Tip usluge se određuje pri

uspostavi konekcije.

Transportni sloj je pravi end-to-end sloj jer prenosi podatke od izvora skroz do odredišta. Drugim

riječima, program na izvorišnoj mašini komunicira sa programom na odredišnoj mašini, koristedi

zaglavlja poruke i kontrolne poruke. U nižim slojevima, svaki protokol je između mašine i njenog

direktnog susjeda, a ne između krajnjih izvorišnih i odredišnih mašina koje mogu biti odvojene sa više

rutera. Transportni sloj ima specifikacije koje kontrolišu maksimalnu brzinu kojom primalac može

prihvatati podatke, te mehanizme za izbjegavanje mrežnog zagušenja. Transportni sloj ima zadatak i da

identificira aplikaciju čiji se podaci prenose. To se omogudava pomodu polja u zaglavlju koja se zove

2

„port number“. Svakom procesu kojem je potreban pristup na mrežu dodjeljuje se broj porta jedinstven

za tog hosta. Transportni sloj sadrži tu informaciju u zaglavlju da bi se znalo kojoj aplikaciji pripadaju

podaci koji se prenose.

Podatkovne mreže i internet omogudavaju komunikaciju između ljudi, kako na lokalnom, tako i na

globalnom nivou. Na jednom uređaju ljudi mogu koristiti više usluga, kao što su naprimjer: e-mail, Web,

Instant messaging za razmjenjivanje informacija. Aplikacije kao što su e-mail klijent, Web browser,

Instant messaging klijent, omogudavaju ljudima da koriste računare i mreže za slanje poruka i

informacija. Podaci iz svake od ovih aplikacija su upakovani, transportovani i dostavljeni na odgovarajudi

server ili aplikaciju na odredišnom uređaju. Procesi opisani u transportnom sloju OSI modela primaju

podatke sa aplikacijskog sloja i pripremaju ih za adresiranje na mrežnom sloju. Transportni sloj je

zaslužan za end-to-end transfer aplikacijskih podataka. Transportni sloj uključuje i sljedede funkcije:

omogudava vedem broju aplikacija da komuniciraju u mreži u isto vrijeme na jednom uređaju,

osigurava sigurnu dostavu podataka na odredište u odgovarajudem redoslijedu u tačno

određenu aplikaciju,

koristi mehanizme za ispravljanje grešaka.

Protokoli transpotnog sloja su:

TCP (Transmission Control Protocol),

UDP (User Datagram Protocol),

ATP (AppleTalk Transaction Protocol),

CUDP (Cyclic UDP),

DCCP (Datagram Congestion Control Protocol),

FCP (Fiber Channel Protocol),

NBF (NetBIOS Frames Protocol),

SCTP (Stream Control Transmission Protocol),

SPX (Sequenced Packet Exchange),

SST (Structured Stream Transport).

TCP je pouzani, konekcijski orjentiran protokol koji omogudava da podaci s izvorišta do odredišta stignu

bez greške i to je najviše korišteni protokol transportnog sloja na internetu. Vrši segmentiranje bita i

proslijeđuje ih internet sloju, a na odredištu vrši reasembliranje poruke. TCP vrši i kontrolu toka (eng.

flow control), kako bi spriječio da brzi pošiljalac uguši sporog primaoca. TCP može dovesti do dodatnog

opteredenja pri izvršavanju svojih funkcija. Dodate funkcije specificirane u TCP –u su: pravilan redoslijed

isporuke, pouzdana isporuka i kontrola toka. Svaki TCP segment ima dodatnih 20 bajta u zaglavlju koja se

dodaju u procesu enkapsulacije, za razliku od UDP segmenta koji ima samo 8 bajta. Primjer aplikacija

koje koriste TCP su: Web Browsers, E-mail, File Transfe, itd.

UDP je nepouzdan, nekonekcijski orjentiran protokol kojeg koriste aplikacije koje ne žele TCP

segmentiranje i kontrolu toka, ved pružaju svoje. Koristi se za one-shot, client-server-type request-reply

3

queries i aplikacije u kojima je važnije da nešto stigne na vrijeme nego tačnost, kao što je slučaj sa

prenosom videa ili govora.

Slika. TCP i UDP zaglavlja

Prednost UDP protokola je osiguravanje malog opteredenja mreže pri isporuci podataka. Ovaj protokol

koristi „best effort“ princip za slanje datagrama. Primjer aplikacija koje koriste UDP su DNS (Domain

Name System), Video Streaming, VoIP (Voice over IP), itd.

Uloga transportnog sloja u OSI modelu

Transportni sloj omogudava segmentaciju podataka i potrebnu kontrolu za ponovno spajanje ovih

dijelova podataka (segmenata). Primarne funkcije koje svakog protokola transportnog sloja uključuju:

Segmentaciju i reasembliranje – vedina mreža ima ograničenu količinu podataka koja može biti

uključena u jedan PDU (Protocol Data Unit). Transportni sloj dijeli informacije u blokove

podataka odgovarajude veličine. Na odredištu, transportni sloj reasemblira podatke prije nego ih

proslijedi na odgovarajudu odredišnu aplikaciju ili uslugu.

Multipleksiranje komunikacija – u istoj mreži, na istom čvoru može biti pokrenuto više aplikacija.

Svakoj od ovih aplikacija je dodjeljen broj porta na osnovu kojeg transportni sloj može odrediti

kojoj aplikaciji je podatak namjenjen.

Kako bi koristili informacije sadržane u zaglavlju, za osnovne funkcije segmentiranja i reasembliranja

podataka, neki protokoli na transportnom sloju omogudavaju:

konekcijski-orjentiranu komunikaciju,

pouzdanu isporuku,

spajanje dijelova podataka tačnim redoslijedom i

kontrolu toka podataka.

4

Praćenje individualne komunikacije, segmentiranje podataka i reasembliranje segmenata

Bilo koji host može imati više aplikacija koje komuniciraju kroz mrežu. Svaka od ovih aplikacija

komunicira sa jednom ili više aplikacija na drugom hostu. Uloga transportnog sloja je da održava

višestruku komunikaciju između ovih aplikacija. Kao što svaka aplikacija stvara podatke koji se šalju na

neku udaljenu aplikaciju, ovi podaci moraju biti spremni da budu poslani preko medija u odgovarajudim

dijelovima. Protokoli transportnog sloja opisuju usluge koje segmentiraju ove podatke sa aplikacijskog

sloja. Ovo uključuje enkapsuliranje svakog dijela podataka koji zahtjevaju dodavanje odgovarajudeg

zaglavlja na transportnom sloju da bi se utvrdilo na koju komunikaciju se odnosi. Na odredišnom čvoru

svaki dio podataka mora biti proslijeđen na odgovarajudu aplikaciju. Naravno, svi ovi dijelovi podataka se

moraju spojiti u kompletiran podatak koji de samo takav biti koristan aplikacijskom sloju. Protokoli

transportog sloja opisuju kako se informacije u zaglavlju na transportnom sloju koriste za reasembliranje

(ponovno spajanje) dijelova u kompletiran podatak koji de biti proslijeđen aplikacijskom sloju.

Identificiranje različitih aplikacija

Kako bi podatak stigao do odgovarajude aplikacije, transportni sloj mora identificirati ciljnu aplikaciju. Da

bi ovo izvršio, transportni sloj svaku aplikaciju identificira brojem porta. Svaki softverski proces koji mora

pristupiti mreži je označen brojem porta jedinstvenim u tom hostu. Ovaj broj porta se koristi u zaglavlju

transportnog sloja da ukaže na koju aplikaciju se odnosi taj podatak. Transportni sloj je veza između

aplikacijskog sloja i nižih slojeva koji su zaduženi za transmisiju. Ovaj sloj prima podatke od različitih

aplikacija i prosljeđuje ih na niže slojeve kao manje dijelove koji mogub biti poslani kroz medij.

Aplikacije ne moraju poznavati operacijske detalje mreže koja se koristi. Aplikacije samo generišu

podatke koji su poslani od određene aplikacije ka nekoj drugoj, bez razmatranja tipa čvora na odredištu,

medija preko kojeg se podaci prenose, puta kojim se prenose, zagušenja na linku i bez razmatranja o

veličini mreže. Niži slojevi nisu svjesni činjenice da više aplikacija šalje podatke kroz mrežu. Njihova uloga

je da dostave podatke na odgovarajudi uređaj. Na odredišnom uređaju transportni sloj sortira i spaja

podatke prije nego što ih proslijedi ka odgovarajudoj aplikaciji.

Raznolikost potreba za podacima

Pošto različite aplikacije imaju različite potrebe, postoji više protokola transportnog sloja. Za neke

aplikacije, segmenti moraju stidi u tačno određeno vrijeme kako bi bili uspješno procesirani. U nekim

slučajevima svi podaci moraju biti primljeni kako bi bili korisni aplikaciji. U nekim drugim slučajevima

aplikacije mogu tolerisati gubitak podataka za vrijeme transmisije kroz mrežu.

5

Slika. Prikaz omogudavanja komuniciranja aplikacija na različitim uređajima

U današnjim konvergiranim mrežama, aplikacije sa veoma različitim transportnim potrebama mogu

komunicirati na istoj mreži. Različiti transportni protokoli imaju različita pravila i tako dozvoljavaju

uređajima da savladavaju različite zahtjeve.

Neki protokoli omogudavaju samo osnovne funkcije za efikasno dostavljanje dijelova podataka između

odgovarajudih aplikacija. Ovi tipovi protokola su korisni za aplikacije čiji podaci su osjetljivi na kašnjenje.

Drugi protokoli transportnog sloja opisuju procese koji omogudavaju dodatne usluge kao što je

osiguravanje pouzdane isporuke između aplikacija. Ove dodatne usluge omogudavaju robusniju

komunikaciju, ali i dovode do dodatnog zasidenja i stvaraju vede zahtjeve prema mreži.

Razdvajanje podataka iz više različitih aplikacija

Neka je računar koji povezan na mrežu i simultantno prima i šalje e-mailove, instant messages, pregleda

web stranice i provodi VoIP poziv. Svaka od ovih aplikacija šalje i prima podatke preko mreže u isto

vrijeme. Međutim, podaci iz poziva nisu usmjereni ka web browseru, niti se tekst iz instant messages

prikazuje u e-mailu.

Nadalje, korisnici zahtjevaju da e-mail i web stranica budu primljene u cjelini kako bi se informacije

mogle na odgovarajudi način prezentovati i biti korisne. Manja kašnjenja su prihvatljiva kako bi se

osiguralo da informacija bude primljena i prikazana u kompletnom obliku. S druge strane, propuštanje

manjih dijelova telefonskog razgovora može biti prihvatljivo. Korisnik može zaključiti propušteni dio

razgovora iz konteksta priče ili jednostavno zatražiti od drugog korisnika da ponovi onaj dio koji je

izgubljen. Ovo je mnogo efikasnije od kašnjenja koje bi nastalo ukoliko bi se od mreže tražilo da upravlja

ponovnim slanjem paketa razgovora koji su izgubljeni i upravo zbog toga su određeni gubici prihvatljivi.

6

Slika. Transpotni sloj dijeli podatke u segmente radi lakšeg upravljanja i transporta

Kao što je ved opisano, slanje jednog tipa podataka, npr. video podatka preko mreže kao jedne

kompletne cjeline podataka bi moglo spriječiti ostale aplikacije da prenose svoje podatke preko mreže u

isto vrijeme. To ,također, dovodi do težeg ispravljanja grešaka i teže retransmisije oštedenih podataka.

Dijeljenje podataka u manje dijelove i slanje ovih dijelova od izvorišta ka odredištu omogudava da više

komunikacija funkcioniše istovremeno na istoj mreži.

Segmentiranje podataka, u skladu sa protokolima transportnog sloja, pruža sredstva za slanje i primanje

podataka kada je potrebno da više aplikacija komunicira u isto vrijeme. Bez segmentacije samo jedna

aplikacija, npr. video komunikacija, bi mogla primati i slati podatke. Ne bi bilo mogude primiti e-mail,

instant messages ili pregledati web stranice u isto vrijeme kada je u toku video komunikacija. Na

transportnom sloju svaki posebni dio podataka koji se krede od izvorišta ka odredištu predstavlja

komunikaciju. Da bi se identificirao svaki segmenat podataka, transportni sloj dodaje zaglavlje koji sadrži

polja bita. Vrijednost ovih bita u određenim poljima omogudava protokolima transportnog sloja da

izvode različite funkcije.

7

Slika. Segmentiranje podataka

Uspostavljanje sesije, pouzdana isporuka i dostava u tačnom rasporedu

Transportni sloj omogudava konekcijski orjentiranu komunikaciju stvaranjem sesije između aplikacija.

Ove sesije pripremaju aplikacije da komuniciraju međusobno prije nego se bilo kakav podatak pošalje.

Unutar ovih sesija mogude je upravljati podacima za komunikaciju između dvije aplikacije.

Iz više razloga, mogude je da podatak bude ošteden ili potpuno izgubljen za vrijeme transmisije kroz

mrežu. Transportni sloj osigurava prispjede svih dijelova podataka na njihovo odredište jer vrši ponovno

slanje (retransmisiju) podataka koji se izgube.

Pošto mreže omogudavaju više ruta za transmisiju od istog izvorišta ka istom odredištu, podaci mogu

dolaziti u pogrešnom redoslijedu. Numerisanjem i dodjeljivanjem brojeva sekvence svakom segmentu,

transportni sloj osigurava da su ovi segmenti pravilno reasemblirani na odredištu.

Kontrola toka podataka

Mrežni uređaji imaju ograničene resurse, kao npr. memoriju ili propusni opseg. Kada transportni sloj

primjeti da su resursi prezasideni, neki protokoli mogu zahtjevati od aplikacije da smanji količinu

podataka koju šalje. Ovo se radi na transportnom sloju regulisanjem količine podataka. Kontrola toka

podataka može spriječiti gubitak segmenata na mreži i izbjegavati potrebu za ponovnom transmisijom.

8

Osiguravanje pouzdane komunikacije

Kao što je ved navedeno, primarna svrha transportnog sloja je upravljanje aplikacijskim podacima za

komunikaciju između hostova. Različite aplikacije imaju i različite zahtjeve za svoje podatke, a samim

time su razvijeni i različiti protokoli transportnog sloja da bi se osiguralo zadovoljenje ovih zahtjeva.

Transportni sloj i njegovi protokoli mogu implementirati metode za osiguravanje pouzdane dostave

podataka. U smislu mreže, pouzdanost podrazumijeva osiguravanje da svaki dio informacije uspješno

stigne na odredište.

Na transportnom sloju osnovne operacije vezane za pouzdanost su:

pradenje poslanih podataka,

potvrda primljenih podataka,

ponovno slanje podataka za koje nije primljena potvrda.

Zatjeva se od procesa na transportnom sloju na izvorištu da vodi računa o tome svakom dijelu

komunikacije, kao i da vrši retransmisiju svih izgubljenih dijelova za koje nisu stigle potvrde o prijemu.

Na odredištu, uloga procesa transportnog sloja je da isto tako prate svaki dio komunikacije koji prime i

da šalju potvrdu o primitku.

Ovi procesi kojima se osigurava pouzdanost,prenosa uzrokuju dodatno opteredenje mrežnih resursa

zbog potvrda koje se moraju slati, pradenja komunikacije i retransmisije. Za osiguravanje pouzdanosti

komunikacije šalje se više kontrolnih informacija između izvorišta i odredišta. To su informacije sadržane

u zaglavljima četvrtog sloja. Stručnjaci za razvoj aplikacija moraju izabrati koji je protokol transportnog

sloja prikladan za njihovu aplikaciju bazirano na zahtjevima aplikacije.

Na transportnom sloju postoje protokoli koji ili specifiraju metode za pouzdanu, garantovanu isporuku ili

za „best-effort“ isporuku. U kontekstu mreže, „best-effort“ dostava se smatra nepouzdanom dostavom

jer ne postoje potvrde koje garantuju da je dio informacije dostavljen na odredište. Ovakve mogudnosti

dovode do situacije kada je potrebno procijeniti i odmjeriti potrebe za pouzdanosti komunikacije i

opteredenja koji ovakva pouzdanost donosi mreži.

9

Slika. Pouzdana i „best effort“ isporuka

Određivanje potrebe za pouzdanošću

Apikacije, kao što su baze podataka, web stranice, e-mail, zahtjevaju da svi podaci koji se šalju pristignu

na odredište u normalnom stanju kako bi pristigli podaci imali vrijednost za odredište. Bilo koji podatak

koji se izgubi može uzrokovati greške u komunikaciji i poruka može biti nepotpuna ili je mogude da se ne

može pročitati. Zato su ove aplikacije dizajnirane da koriste protokol transportnog sloja koji

implementira pouzdanost. Dodatno opteredenje mreže se smatra neophodnim kako bi se osiguralo

uspješno funkcionisanje ovih aplikacija.

Druge aplikacije su više tolerantne prema manjim gubicima podataka. Naprimjer, ako jedan ili dva

segmenta video prenosa ne stignu na odredište, to de prouzrokovati samo trenutni, kratkotrajni zastoj

slike. Ovo može rezultovati degradacijom slike, ali može i da bude potpuno neprimjedeno ili zanemareno

od strane korisnika koji gleda neki video prenos.

Uvođenje opteredenja mreže koje izaziva osiguranje pouzdanosti za ove vrste aplikacija moglo bi da

smanji korisnost aplikacije. Slika u video prenosu bi bila značajno degradirana kada bi odredišni uređaj

morao detektovati izgubljene podatke i odgađati prikazivanje slike čekajudi da izgubljeni dio bude

ponovo poslan. Bolje je prikazati sliku najboljm mogudim kvalitetom koji je mogud u određenom

trenutku sa segmentima koji su ved pristigli nauštrob pouzdanosti. Ako se pouzdanost ipak razmatra iz

nekih razloga, aplikacija ipak može provjeravati greške i slati zahtjeve za retransmisijom.

10

Slika. Osobine protokola transportnog sloja

Na slici prikazane su karakteristike različitih protokola transportnog sloja. U slučaju IP telefonije i video

komunikacije potrebne su sljedede osobine protokola:

brzina,

malo zaglavlje,

ne zahtijeva potvrde o prispjedu,

ne vrši transmisiju izgubljenih podataka i

dijelove podataka dostavlja aplikaciji onako kako stižu.

u slučaju e-maila i web pretraživanja potrebne su sljedede osobine protokola:

pouzdanost,

potvrda o prispjedu podataka,

ponovno slanje izgubljenih podataka i

dijelove podataka dostavlja aplikaciji onako kako su poslani.

Osnovni protokoli transportnog sloja u IP mrežama

Dva najčešde korištena protokola transportnog sloja u TCP/IP slojevitom modelima su Transmission

Control Protocol (TCP) i User Datagram Protocol (UDP). Oba ova protokola upravljaju komunikacijom

više aplikacija. Razlikuju se u specifičnim funkcijama koje implementiraju.

11

Slika. TCP i UDP zaglavlja

UDP je jednostavan beskonekcijski protokol opisan u RFC-u 768. Prednost mu je osiguravanje malog

opteredenja mreže pri isporuci podataka. Dijelovi komunikacije u UDP-u se nazivaju datagrami. Ovaj

protokol koristi „best effort“ princip za slanje datagrama. Aplikacije koje koriste UDP uključuju:

Domain Name System (DNS),

Video Streaming,

Voice over IP (VoIP).

TCP je konekcijski orjentiran protokol opisan u RFC–u 793. On može dovesti do dodatnog opteredenja pri

izvršavanju svojih funkcija. Dodate funkcije specificirane u TCP –u su: pravilan redoslijed isporuke,

pouzdana isporuka i kontrola toka. Svaki TCP segment ima dodatnih 20 bajta u zaglavlju koja se dodaju u

procesu enkapsulacije, za razliku od UDP segmenta koji ima samo 8 Bajta. Aplikacije koje koriste TCP su:

Web Browsers,

E-mail,

File Transfer.

Razmotrimo primjer kompjutera koji simultano šalje i prima e-mail poruke, instan messaging poruke,

pregleda web stranice i obavlja VoIP poziv. Da bi se razlikovali segmenti i datagrami za svaku aplikaciju, i

TCP i UDP zaglavlja sadrže polja koja mogu jedinstveno identificirati ove aplikacije. Ovaj jedinstveni

identifikator se naziva broj porta.

12

U zaglavlju svakog segmenta ili datagrama nalazi se broj porta izvorišnog i odredišnog čvora. Izvorišni

broj porta je broj za ovu komunikaciju povezan sa izvorišnom aplikacijom na lokalnom hostu. Odredišni

broj porta je broj za ovu komunikaciju koji predstavlja aplikaciju na odredištu, tj. na udaljenom hostu.

Broj porta se dodjeljuje na različite načine, zavisno od toga da li je poruka zahtjev ili odgovor. Dok

serverski procesi imaju dodjeljene statične brojeve porta, klijentski port brojevi se dinamički određuju za

svaku konverzaciju.

Kada klijentska aplikacija pošalje zahtjev ka serverskoj aplikaciji, broj porta sadržan u zaglavlju se odnosi

na aplikaciju koja je pokrenuta na izvorišnom uređaju. Klijent na izvorištu mora poznavati broj porta na

serveru ili udaljenom čvoru, tj. odredištu. Broj porta na odredištu je konfigurisan po defaultu ili ručno.

Naprimjer, kada web browser aplikacija šalje zahtjev prema web serveru, browser koristi TCP i port 80

ukoliko nije drugačije specificirano. To je zato jer je broj porta 80 dodjeljen ovakvoj vrsti web aplikacija.

Mnoge uobičajene aplikacije imaju predefinisan broj porta.

Broj porta izvorišne aplikacije se u drugim slučajevima slučajno bira od brojeva iznad 1024. Sve dok se ne

preklapa sa drugim brojevima portova koji se koriste, klijent ima slobodu određivanja bilo kojeg

slučajnog broja porta za neku aplikaciju, ili se može koristiti broj porta automatski dodjeljen od strane

korištenog operativnog sistema.Ovaj broj porta se prati, kao i aplikacija koja je pokrenula komunikaciju

kako bi se u slučaju odgovora on mogao poslati na adresu odgovarajude aplikacije. Broj porta se, u

skladu sa ovim, smatra i povratnom adresom.

Kombinacija broja porta i IP adrese identificira tačnu aplikaciju koja je pokrenuta na odredišnom

uređaju. Ova kombinacija se naziva Socket. Npr. zahtjev za prikazivanjem HTTP web stranice koji se šalje

ka web serveru (port 80) koji se pokrede na host računaru sa IPv4 adresom tredeg sloja 192.168.1.20 de

imati socket 192.168.1.20:80.

Slika. Adresiranje aplikacija brojevima porta

13

Brojeve porta određuje Internet Assigned Numbers Authority (IANA). To je tijelo koje propisuje standare

vezane za adresiranje portova. Postoje različite vrste brojeva porta:

Well Known (dobro poznati) port-ovi od 0 do 1023 – ovi brojevi su rezervisani za servise i aplikacije.

Najčešdce se koriste za aplikacije kao što su: HTTP (web server), POP3/SMTP (e-mail server) i Telnet.

Definisanjem ovih well-known portova za serverske aplikacije, klijentske aplikacije mogu biti

programirane da zahtijevaju konekciju ka tom specificiranom portu i povezanoj usluzi.

Registrovani portovi (od 1024 do 49151) – ovi brojevi portova se dodjeljeni korisničkim procesima ili

aplikacijama. Ovi procesi su primarno individualne aplikacije koje je korisnik izabrao da instalira radije

nego uobičajene aplikacije koje imaju well-known portove. Kada se ne koriste za serverske resurse, ovi

brojevi portova mogu se ,također, izabrati dinamički od strane klijenta kao njegov izvorišni port.

Slika. Registrovani i well-known TCP i UDP portovi

Dinamički ili privatni portovi od 49152 do 65535 – također poznati i kao „ephemeral ports“. Ovi brojevi

porta se dinamički dodjeljuju korisničkim procesima ili aplikacijama koje iniciraju konekciju. Nije previše

14

česta situacija da se klijent konektuje na uslugu koristedi dinamički ili privatni port, iako postoje neki

peer-to-peer programi koji to rade.

Vrijednost portova obično je u skladu s preporukama međunarodne organizacije za standarde IANA

(Internet Assigned Numbers Authority). Dio preporuka prikazan je u narednoj tabeli. Uz vrijednost porta

prikazan je i protokol koji ga podržava, te u nastavku pojam i opis pojma na koji se port odnosi.

Ponekad je potrebno poznavati koje su aktivne TCP konekcije na određenom hostu. Netstat je važna

mrežna mogudnost koja se koristi za verificiranje tih konekcija. Netstat izlistava protokole u upotrebi,

lokalnu adresu i broj porta, adresu udaljenog računara i broja porta, kao i stanje konekcije.

Neobjašnjene TCP konekcije mogu predstavljati vede sigurnosne prijetnje. To može indicirati da je neko

ili nešto konektovano nelegitimno na lokalni host. Dodatno, nepotrebne TCP konekcije mogu trošiti

vrijedne sistemske resurse i tako usporavati performanse host uređaja. Netstat bi se trebao koristiti da

se ispitaju otvorene konekcije na hostu kada se čini da su performanse kompromitovane.

Slika. Rezultat komande netstat u command prompt-u

Neke aplikacije šalju velike količine podataka, u nekim slučajevima i više gigabajta. Bilo bi nepraktično

slati ove podatke u jednom velikom dijelu. Ovaj veliki dio bi onemogudio slanje bilo kakvog drugog

podataka u isto vrijeme. Samo slanje bi trajalo nekoliko minuta ili čak sati. U slučaju greške cijeli podatak

bi se izgubio, a ponovno slanje bi zahtjevalo više vremena i stvaralo bi ponovno zagušenje. Mrežni

uređaji ne bi imali dovoljno memorije da pohrane ovolike količine podataka dok se prenose ili primaju.

15

Slika. Funkcije transportnog sloja

Djeljenje podataka u dijelove omogudava da se podaci šalju u skladu sa granicama medija i

multipleksiranje podataka različitih aplikacija. TCP i UDP protokoli segmentiraju podatke na različite

načine.

U TCP – u svako zaglavalje segmenta sadrži broj sekvence. Ovaj broj sekvence služi za reasembliranje

segmenata u pravilnom redoslijedu na odredištu. Ovo osigurava da odredišna aplikacija primi podatak

tačno onako kako ga je izvorišna aplikacija poslala.

Iako aplikacije koje koriste UDP također prate komunikaciju između aplikacija, nisu osjetljive na

redoslijed informacija ili na održavanje konekcije. Ne postoji broj sekvence u UDP zaglavlju. UDP je

jednostavniji i stvara manje zasidenja od TCP-a, što rezultira bržom razmjenom podataka. Informacije

mogu stidi u nepravilnom redoslijedu jer postoje različiti putevi u mreži od izvorišta do odredišta, na što

aplikacije koje koriste UDP nisu osjetiljive.

TCP (Transmition Control Protocol)

Usluga koju TCP (Transmission Control Protocol) protokol daje aplikaciji ima sedam osnovnih osobina:

Konekcijski orjentisana usluga. TCP pruža konekcijski orjentisanu usluga u kojoj aplikacija mora

prvo uspostaviti konekciju sa aplikacijom na odredištu, a zatim koristiti tu konekciju za slanje

podataka. Uspostavljanje konekcije se vrši pomodu procesa koji se zove “three way handshake”.

Point to point komunikacija. Svaka TCP konecija ima tačno dvije krajnje tačke.

16

Potpuna pouzdanost. TCP garantuje da de podaci poslani preko uspostavljene konekcije biti

dostavljeni tačno onako kako su poslani, kompletni i tačno onim redoslijedom kojim su poslani.

TCP traži potvrdu o prijemu paketa od strane odredišta. Ta potvrda se zove acknowledgement.

Full Duplex komunikacija. TCP konekcija dozvoljava podacima da idu u oba smijera, i dozvoljava

za oba aplikacijska programa slanje u bilo kojem trenutku.

Stream interface. TCP pruža stream interface u kojem aplikacija šalje kontinualnu sekvencu

okteta preko konekcije. TCP ne grupira podatke u zapise ili poruke, i ne garantuje da de dostaviti

podatke u dijelovima iste veličine kako su poslani od strane aplikacije.

Pouzdano uspostavljanje konekcije.

Raskidanje konekcije se vrši nakon što se utvrdi da su svi podaci ispravno primljeni i da obje

strane žele raskinuti konekciju.

TCP je zadužen i za kontrolu toka podataka. Pomodu mehanizma kliznog prozora (sliding

window), TCP određuje “window size” koji su pošiljalac i primalac programirani da koriste.

Window size je veličina prozora, odnosno maksimalni broj paketa koje pošiljalac može da pošalje

bez prijema potvrde o njihovom prispjedu na odredište.

TCP podržava i kontrolu zagušenja. Koristi kašnjenje kao mjeru zagušenja i odgovara na

zagušenje smanjujudi brzinu kojom šalje podatke podešavajudi veličinu prozora.

Zaglavlje TCP protokola

Polja TCP zaglavlja su:

Source port Number: Broj TCP sesije otvorene na izvorišnom računara koja označava kojoj

aplikaciji pripadaju podaci koji se prenose. Obično je slučajan broj preko 1024.

Destination Number: Identificira protokol višeg sloja ili aplikaciju na odredišnoj strani.

Sequence Number: Specificira broj posljednjeg okteta u segmentu.

Acknowledgement Number: Specificira broj sljededeg okteta koji prijemnik očekuje da primi.

Header Length: Dužina zaglavlja u bajtima.

Flags: Koristi se u upravljanju sesijom i tretiranju segmenata.

Window size: Koliko okteta može biti poslano prije nego se primi potvrda.

TCP Checksum: Kontrolni zbroj; računa se kao 16-bitni komplement jedinice komplementa zbira

svih 16-bitnih riječi u zaglavlju i podacima; pokriva i 96 bitova pseudo zaglavlja koje sadrži

izvorišnu i odredišnu adresu, protokol i dužinu TCP zaglavlja i podataka. Koristi se za provjeru

grešaka u zaglavlju i podacima.

Urgent Pointer: Koristi se samo sa URG (urgent) zastavicom.

Options: Options mogu, a ne moraju biti uključene; ako postoje, veličine su x×8 bita, Padding je

dopuna nulama do 32 bita. Izbori (više njih) prenose se na kraju TCP-a zaglavlja i uvijek imaju

dužinu koja je sastavljena od broja pomnoženog sa 8 bita. Svi izbori uključeni su u kontrolni zbir.

Svaki pojedini izbor mora započeti na granici između okteta. Dvije su mogude forme za neki od

izbora: Opcija veličine jednog okteta i izbor značaja okteta, izbor dužine okteta i izbor podataka

u oktetu. U dužini okteta uključuje se tip okteta i podaci koji mu pripadaju. Ako su izbori kradi od

17

vrijednosti koja je proizvod skupine jednog redka zaglavlja, ostatak po izboru mora se ispuniti

nulama. TCP mora sadržavati sve raspoložive opcije.

Data: Aplikacijski podaci.

16 32

Source port Destination port

Sequence number

Acknowledgement number

Offset Resrvd U A P R S F Window

Checksum Urgent pointer

Option + Padding

Data

Struktura TCP zaglavlja u 32b redovima

Slika. Zaglavlje TCP protokola

Pouzdana komunikacija

Osnovna razlika između TCP-a i UDP-a je pouzdanost. Pouzdanost TCP-a se osigurava koristedi

konekcijski orjetirane sesije. Prije nego host koji koristi TCP pošalje podatke drugom hostu, transportni

sloj inicira proces koji uspostavlja konekciju sa odredištem. Ova konekcija omogudava pradenje sesije, ili

toka komunikacije između hostova. Ovo znači da je svaki host svjestan komunikacije i pripremljen.

Kompletna TCP komunikacja zahtjeva uspostavljanje sesije između hostova u oba smjera.

Nakon što je sesija uspostavljena, odredište šalje potvrdu pošiljaocu za one segmente koji su primljeni.

Ove potvrde čine osnovu pouzdanosti jedne TCP sesije. Kada izvorište primi potvrdu, zaključuje kako je

određeni segment podataka primljen i ne mora više da ga prati. Ako izvor ne primi potvrdu unutar nekog

predefinisanog vremenskog perioda, ponovo šalje taj podatak odredištu.

Dio dodatnog opteredenja i nekorisnog dijela informacije koji TCP generiše na mreži otpada na potvrde i

ponovna slanja izgubljenih podataka. Uspostavljanje sesije ,također, dodatno optereduje mrežu u vidu

novih segmenata koji se razmjenjuju. Dodatno opteredenje se manifestira i u vidu potrebe da se prate

koji segmenti čekaju na potvrdu i retransmisijske procese. Pouzdanost je postignuta poljima u TCP

segmentu, od kojih svako ima posebnu funkciju.

18

Serverski procesi

Kao što je ved opisano u radu, aplikacijski procesi rade na serveru. Ovi procesi „čekaju“ da klijent inicira

komunikaciju zahtjevom za informacijom ili uslugom.

Svaki aplikacijski proces koji je radi na serveru je konfigurisan port brojem, automatski ili manuelno od

strane administratora sistema. Jedan server ne može imati dvije usluge dodjeljene istom port broju u

istoj usluzi transportnog sloja. Host koji ima pokrenutu web server aplikaciju i aplikaciju razmjene

podataka ne može biti konfigurisan da koristi isti broj porta (npr. TCP port 8080). Kada se aktivnoj server

aplikaciji dodjeli određeni broj porta, taj broj se smatra otvorenim na serveru. Ovo znači da transportni

sloj prima i procesira segmente adresirane na taj port. Bilo koji dolazedi klijentski zahtjev, adresiran na

tačan socket se prihvata i podaci se proslijeđuju serverskoj aplikaciji. Mogude je da simultano bude

otvoreno više portova na serveru, po jedan za svaku aktivnu serversku aplikaciju. Uobičajano je da

server nudi više od jedne usluge, kao što je web server i FTP server u isto vrijeme. Jedan način za

poboljšanje sigurnosti na severu je da se zabrani pristup, osim onim portovima koji su dodijeljeni

aplikacijama koje se mogu koristiti od strane autorizovanih korisnika.

Slika ispod prikazuje tipičnu alokaciju izvorišnog i odredišnog porta u TCP klijent/server operacijama.

Slika. Klijentski zahtjevi i brojevi portova

Uspostavljanje i prekid konekcije

Kada dva hosta komuniciraju koristedi TCP, konekcija se uspostavlja prije nego se podaci razmjene.

Nakon što se završi komunikacija, sesija se zatvori i konekcija prekine. Konekcijski i sesijski mehanizmi

omogudavaju TCP-u funkciju poudanosti.

Host prati svaki segment podataka u sesiji i razmjenjuje informacije o tome koji je podatak primljen na

svakom hostu koristedi informacije sadržane u TCP zaglavlju.

19

Svaka konekcija uključuje jednosmjernu komunikaciju, ili sesiju za uspostavljanje i raskidanje TCP

procesa između kranjih uređaja. Za uspostvljanje ove konekcije, host izvršava proces „three-way

handshake“. Kontrolni biti u TCP zaglavlju indiciraju status i odvijanje konekcije. Three-way handshake:

Ustanovljava da je odredišni uređaj u mreži.

Verificira da odredišni uređaj ima aktivnu usluga i prihvata zahtjeve na odredišni broj porta koji

klijent koji inicira komunikaciju namjerava koristiti za sesiju.

Informiše odredišni uređaj da izvorište namjerava uspostaviti konekciju sa tim brojem porta.

U TCP konekcijama, host koji je klijent inicira sesiju prema serveru. Za razumijevanje procesa three-way

handshake i njegovog funkcionisanja u TCP-u, bitno je razmotriti različite vrijednosti koje dva hosta

razmjenjuju. Tri koraka u uspostavljanju TCP konekcije su:

1. Klijent koji inicira konekciju šalje segment koji sadržava inicijalnu vrijednost sekvence, što služi

kao zahtjev serveru za započinjanje komunikacijske sesije.

2. Server odgovara segmentom koji sadrži vrijednost potvrde koja je jednaka zbiru primljnog broja

sekvence i broja jedan, kao i svoju vlastitu vrijednost sinhronizacijske sekvence. Vrijednost je za

jedan veda od broja sekvence jer je potvrda uvijek sljededi byte ili oktet. Vrijednost potvrde

omogudava klijentu da poveže odgovor sa originalnim segmentom koji je poslan na server.

3. Klijent koji je inicirao konekciju odgovara vrijednošdu potvrde jednakom vrijednosti sekvence

koju je primio plus jedan. Ovo okončava proces uspostavljanja konekcije.

TCP three-way handshake

Koristedi program wireshark i analiziranjem paketa možemo ispitati i objasniti proces three-way

handshake uspostavnja konekcije u TCP protokolu.

Slika. Uspostavljanje TCP konekcije

20

Korak 1.

TCP klijent započinje three-way handshake slanjem segmenta sa SYN (Synchronize Sequence Number)

postavljenom zastavicom, indiciraju inicijalnu vrijednost polja broja sekvence u zaglavlju. Ova inicijalna

vrijednost broja sekvence, poznata kao ISN (Initial Sequence Number), se bira slučajno i koristi se za

započinjanje pradenja toka podataka od klijanta ka serveru za ovu sesiju. ISN u zaglavlju svakog

segmenta se poveda za jedan za svaki byte podatak koji klijent šalje na server dok se komunikacija

odvija. SYN kontrolna zastavica je postavljena, a broj sekvence je 0. Iako je u analizi protokola vrijednost

sekvence i potvrde prikazana kao decimalni, stvarna vrijednost je 32-bitni binarni broj.

Korak 2.

TCP server mora da potvrdi prijem SYN segmenta od klijenta da bi se uspostavila sesija između klijenta i

servera. Da bi to uradio, server šalje segment nazad do klijenta sa postavljenom ACK zastavicom i tako

ukazuje da je broj potvrde značajan. Sa ovom zastavicom postavljenom u segmentu, klijent prepoznaje

segment kao potvrdu da je server primio njegov segment sa SYN zastavicom.

Vrijednost polja u kome se nalazi broj potvrde je jednak inicijalnoj vrijednosti klijentskog broja sekvence

uvedanog za jedan. Sesija između klijenta i servera je na ovaj način uspostavljena. ACK zastavica de ostati

postavljena za potrebe sesije. Razgovor između klijenta i servera je dvosmjerna sesija, od klijenta do

servera i od servera do klijenta. U drugom koraku three-way handshake uspostave konekcije, server

mora inicirati odgovor od servera prema klijentu. Za započinjanje ove sesije, server koristi SYN zastavicu

na isti način kako je to radio i klijent. Postavlja SYN kontrolnu zastavicu u zaglavlje kako bi uspostavio

sesiju od servera ka klijentu. SYN zastavica indicira da je se u zaglavlju nalazi inicijalna vrijednost broja

sekvence. Vrijednost de biti korištena za pradenje toka podataka u ovoj sesiji od servera nazad ka

klijentu.

Korak 3.

Konačno, TCP klijent odgovara segmentom koji sadrži ACK koji je odgovor na TCP SYN poslan od strane

servera. Nema korisničkih podataka u segmentu. Vrijednost u polju koje sadrži broj sekvence je za jedan

veda od inicijalnog broja sekvence primljenog od servera. Jednom kada su obje sesije uspostavljene

između klijeta i servera, svi dodatni segmenti razmjenjeni u ovoj komunikaciji de imati postavljenu ACK

zastavicu. Za zatvaranje konekcije potrebno je postaviti FIN kontrolnu zastavicu u zaglavlju segmenta. Za

zatvaranje svake jednosmjerne TCP sesije, koristi se two-way handshake koji se sastoji od FIN segmenta i

ACK segmenta. Stoga, za prekidanje jednog razgovora podržanog TCP-om, potrebno je da se izvrše četiri

razmjene segmenta.

21

Slika. Rasidanje TCP konekcije

Pri objašanjavanju koriste se pojmovi klijent i server radi pojednostavljivanja, ali prekidanje sesije može

biti inicirano od strane bilo koja dva hosta koja su završila sesiju:

Kada klijent nema više podataka za slanje on šalje segment sa postavljenom FIN zastavicom.

Server šalje ACK kako bi potvrdio prijem FIN segmenta za prekidanje sesije od klijenta ka

serveru.

Server šalje FIN klijentu kako bi prekinuo sesiju od servera ka klijentu.

Klijent odgovara ACK potvrdom kako bi potvrdio serveru prijem njegovog FIN segmenta.

Kao što je prikazano na slici, FIN i ACK kontrolne zastavice su postavljene u zaglavlju segmenta,

tako zatvarajudi HTTP sesiju.

Mogude je i zatvoriti sesiju pomodu procesa three-way handshake. Kada klijent nema više podataka za

poslati, on šalje FIN serveru. Ako server također nema više podataka za poslati, mogude je da odgovori i

sa FIN i sa ACK postavljenim zastavicama, tako kombinirajudi dva koraka u jedan. Još je samo ostalo da

klijent odgovori sa ACK.

TCP reasembliranje (ponovno spajanje) segmenata

Kada usluge šalju podatke koristedi TCP, segmenti mogu stidi na odredište u nepravilnom redoslijedu.

Kako bi primatelj mogao da razumije originalnu poruku, podaci u ovim segmentima se reasembliraju u

originalan raspored. Brojevi sekvence su dodjeljeni u zaglavlju svakog paketa kako bi vradanje u

originalni redoslijed bilo mogude. Tokom uspostavljanja sesije, postavlja se ISN (Initial Sequence

Number). ISN predstavlja početnu vrijednost za ovu sesiju za bajte koji de biti prenešeni do aplikacije

koja prima podatke. Dok se podaci šalju tokom trajanja sesije, broj sekvence se povedava za broj bita koji

su bili prenešeni. Ovo pradenje podataka omogudava da se svaki segmet može jedinstveno identificirati i

potvrditi, samim tim se mogu ustanoviti i segmenti koji su izgubljeni. Brojevi sekvence segmenta

omogudavaju pouzdanost tako što pokazuju kako reasemblirati i poredati segmente u pravilan red, što je

prikazano na slici.

22

Slika. TCP vrada segmente u originalni redoslijed

TCP proces na prijemnoj strani stavlja podatke iz segmena u prijemni buffer. Segmenti se pomodu

brojeva sekvecne stavljaju u pravilan redoslijed i nakon reasembliranja proslijeđuju aplikacijskom sloju.

Svi segmenti koji dolaze sa brojem sekvence koji nije kontinualan (ne može se nastaviti na segmente koji

su do tada pristigli) zadržava se radi kasnijeg procesiranja. Onda, kada segmenti sabajtima koji su

nedostajali pristignu, ti segmenti se procesiraju na odgovarajudi način.

TCP potvrde (acknowledgement) i prozori

Jedna od funkcija TCP-a je da se pobrine da svaki segment stigne do svog odredišta. TCP usluge na

odredišnom hostu potvrđuju prijem podataka. Broj sekvence segmenta u zaglavlju i broj potvrde se

koriste za potvrdu prijema bajta podatka sadržanih u segmentu. Broj sekvence je broj bita koji su

prenešeni u sesiji uvedan za jedan (što predstavlja broj prvog bajt podataka u trenutnom segmentu).

TCP koristi broj potvrde u segmentima poslanim natrag ka izvorištu da ukaže na slijededi bajt u ovoj sesiji

koji primatelj očekuje da primi. Ovo se naziva očekivana potvrda.

Izvorište se informiše da je odredište primilo sve bajte u ovom toku podatka do, ali ne i uključujudi bajte

na koje ukazuje broj potvrde. Svaka konekcija je, kao što je ved ranije rečeno, dvosmjerna sesija. Brojevi

sekvence i potvrde se razmjenjuju u oba smjera.

23

Slika. TCP prozor i moguda stanja segmenata pri slanju

U primjeru na slici ispod, host sa lijeve strane šalje podatke hostu sa desne strane. Šalje segment koji

sadrži 10 bajta podataka ove sesije i broj sekvence jednak broju u zaglavlju. Host na desnoj strani prima

segmente na sloju 4 i zaključuje da je broj sekvence 1 i da ima 10 bajta podataka. Host zatim šalje

segment natrag do hosta na lijevoj stranida bi potvrdio prijem podataka. U ovom segmentu host

postavlja broj potvrde na vrijednost 11 da bi ukazao kako je sljededi broj bajta koji očekuje da de primiti

11. Primjedujemo da vrijednost ACK potvrde na izvorištu ostaje 1 da bi ukazala da je segment dio

konverzacije koja se trenutno odvija i broj u polju Acknowledgment Number je validno. Kada host na

lijevoj strani koji šalje podatke primi ovu potvrdu, može poslati slijededi segment koji sadrži podatke ove

sesije počevši sa brojem bajta 11.

Gledajudi kroz ovaj primjer, kada bi host koji šalje podatke morao čekati na potvrdu prijema svakih 10

bajta, mreža bi imala mnogo dodatnog opteredenja. Kako bi se smanjila količina potvrda koje se šalju,

više segmenata može biti poslano u jednom smjeru, a samo jedan segment sa potvrdom o prijemu tih

segmenata u drugom smjeru. Ova potvrda sadrži broj potvrde koji predstavlja konačnu sumu

bajtaprimljenih u sesiji. Npr., ako je početni broj sekvence 2000, i ako ima 10 segmenata po 1000 bajta

od kojih su svi ispravni primljeni, broj potvrde 12000 bi bio poslan ka izvorištu. Količina podataka koju

izvor može da prenese prije nego što se primi potvrda o njihovom prijemu na odredištuse naziva veličina

prozora (window size).

Slika. Potvrde o prijemu TCP segmenata

24

TCP retransmisija – rješavanje problema izgubljenih segmenata

Bez obzira koliko je dobro mreža dizajnirana gubici podataka de se svejedno povremeno dešavati. Zbog

toga TCP pruža metode upravljanja ovim izgubljenim segmentima. Među tim metodama je i mehanizam

retransmisije segmenata za koje nije primljena potvrda. Usluga na odredišnom hostu koja koristi TCP

obično potvrđuje podatke za kontinualne sekvence bajta. Ukoliko jedan ili više segmenata izostane,

odnosno izgubi se, samo se potvrđuju prijemi podataka koji kompletiraju kontinualan tok podatka. Npr.

ako su segmenti sa brojem sekvence 1500 do 3000 i 3400 do 3500 primljeni, broj potvrde bi bio 3001,

zato što segmenti sa brojem sekvence od 3001 do 3399 nisu primljeni. Kada TCP na izvorišnom hostu ne

primi potvrdu nakon nekog predefinisanog vremenskog perioda, vratiti de se na broj posljednje

primljene potvrde i poslati ponovo podatke od te tačke pa nadalje. Ponovno slanje podataka

(retransmisija) je proces koji nije secificiran u RFC-u, nego je ostavljno da se prilagođava različitim

implementacijama TCP-a.

Za tipičnu TCP implementaciju, host može prenositi segment, staviti kopiju segmenta u retransmisijski

red i startovati vremenski tajmer. Kada se primi potvrda segment se briše iz reda. Ako potvrda nije

primljena prije nego istekne definisano vrijeme, segment se ponovo šalje.

Današnji host uređaji mogu, također, imati i opciju zvanu selektivne potvrde (Selective

Acknowledgements). Ako oba hosta podržavaju selektivne potvrde, mogude je da odredište potvrdi

prijem nekontinuiranih segmenata i host koji šalje bi u ovom slučaju mogao da pošalje samo one

segmente koji nedostaju.

TCP kontrola zagušenja – minimiziranje gubitka segmenata

TCP pruža, također, i mehanizme kontrole toka. Kontrola toka asistira pouzdanosti TCP prenosa

podešavajudi efektivnu brzinu protoka podataka između dvije usluge u sesiji. Kada je izvor obaviješten

da je određena količina segmenata primljena, može nastaviti slati više podataka za ovu sesiju. Polje

window size (veličina prozora) u TCP zaglavlju označava količinu podataka koja može biti prenešena prije

nego se primi potvrda. Inicijalna veličina prozora se određuje tokom započinjanja sesije kroz proces

three-way handshake. TCP feedback mehanizam podešava efektivnu brzinu prenosa podataka do

maksimalnog toka koji mreža i odredišni uređaj mogu podržati bez gubitaka. TCP pokušava upravljati

brzinom prenosa tako da svi podaci budu primljeni i retransmisije budu minimizirane.

Na slici ispod je prikazana pojednostavljena reprezentacija veličine prozora i potvrda. U ovom primjeru,

inicijalna veličina prozora za TCP sesiju koja je predstavljena na slici je postavljena na 3000 bajta. Kada je

pošiljalac poslao 3000 bajta on čeka na potvrdu prijema ovih bajta prije nego pošalje jos podataka u toj

sesiji. Kada pošiljac dobije potvrdu od primaoca on može slati slijededih 3000 bajta. Tokom kašnjenja u

čekanju potvrde, pošiljac nede slati dodatne segmente za ovu sesiju. U periodima mrežnog zagušenja ili

kada su iscrpljeni resursi primatelja, kašnjenje se može povedati. Kako ovo kašnjenje raste, efektivna

brzina prenosa podataka se smanjuje. Usporavanje brzine podataka pomaže u smanjivanju nadmetanja

za resursima.

25

Slika. TCP potvde o prijemu i veličina prozora

UDP (User Datagram Protocol)

UDP – Odmjeravanje između opterećenja i pouzdanosti

UDP je jednostavan protokol koji pruža osnovne funkcije protokola transportnog sloja. Ima mnogo

manje podataka koji nisu korisni dio informacije nego što je to slučaj kod TCP protokola. UDP nije

konekcijski orjetiran i ne pruža sofisticiranu retransmisiju, sekvenciranje i mehanizme kontrole toka. Ovo

ne znači da su aplikacije koje koriste UDP protokol nepouzdane, ved samo da ove funkcije nisu pružene

od strane protokola transportnog sloja i da se moraju implementirati negdje drugo ako je to potrebno.

Iako je količina saobradaja koji se prenosi mrežom, a koji koristi UDP protokol relativno mala, ključni

protokoli aplikacijskog sloja koji koriste usluge UDP protokola su:

Domain Name System (DNS),

Simple Network Management Protocol (SNMP),

Dynamic Host Configuration Protocol (DHCP),

Routing Information Protocol (RIP),

Trivial File Transfer Protocol (TFTP),

Online igre.

Neke aplkacije, kao što su online igre ili VoIP, mogu tolerisati manje gubitke nekih podataka. Ako bi ove

aplikacije koristile TCP, moglo bi dodi do vedih kašnjenja jer TCP mora vršiti detekciju izgubljenih

podataka i vršiti retransmisiju. Ova kašnjenja bi bila mnogo više neprihvatljiva za aplikaciju nego što su

to mali gubici informacija. Neke aplikacije, kao što je DNS, de jednostavno ponovo poslati zahtjev za koji

26

nisu dobile odgovor, i zato ne moraju imati TCP garanciju o pristizanju poruke. Malo dodatno

opteredenje koje UDP pravi čini ga veoma poželjnim nekim vrstama aplikacija.

Slika. UDP – beskonekcijski protokol

Zaglavlje UDP datagrama

Značenja polja zaglavlja UDP datagrama su:

Source port - Izvorišni broj porta usluge je opcionalno polje. Kada se koristi, označava broj porta

procesa koji šalje podatke. Na nju de dodi odgovor kada ne postoji druga informacija. Ako se

polje ne koristi popuni se nulama.

Destination port – Odredišni broj porta usluge.

Length - Dužina UDP datagrama u oktetima uključujudi zaglavlje i podatke. Minimalna dužina

UDP datagrama je 8 okteta.

Checksum - Kontrolni zbroj zaglavlja, računa se na osnovu pseudo zaglavlja iz IP i UDP zaglavlja i

podataka. Ako je polje ispunjeno nulama znači da predajnik nije računao zbir, a ako je zbir

jednak nuli, prenosi se kao niz jedinica

Data – Podaci.

16 32

Source port Destination port

Length Checksum

Data

Struktura UDP zaglavlja u 32b redovima

Slika. UDP zaglavlje

27

Multipleksiranje podataka različitih aplikacija

UDP omogudava aplikacijama direktno korištenje usluga mrežnog sloja, multipleksira promet različitih

aplikacija. Demultipleksiranje na granici transportne i aplikacijske razine prikazano je na slici.

Slika. Demultipleksiranje UDP prometa pojedinih aplikacija

Demultipleksiranje se obavlja pomodu sljedede četvorke:

(𝐼𝑃𝑆, 𝐼𝑃𝐷,𝑃𝑆,𝑃𝐷)

gdje je:

𝐼𝑃𝑆– 𝐼𝑃𝑎𝑑𝑟𝑒𝑠𝑎 𝑖𝑧𝑣𝑜𝑟𝑖š𝑡𝑎,

𝐼𝑃𝐷– 𝐼𝑃 𝑎𝑑𝑟𝑒𝑠𝑎 𝑜𝑑𝑟𝑒𝑑𝑖š𝑡𝑎,

𝑃𝑆–𝐵𝑟𝑜𝑗 𝑝𝑜𝑟𝑡𝑎 𝑖𝑧𝑣𝑜𝑟𝑖š𝑡𝑎,

𝑃𝐷–𝐵𝑟𝑜𝑗 𝑝𝑜𝑟𝑡𝑎 𝑜𝑑𝑟𝑒𝑑𝑖š𝑡𝑎.

Pomodu IP adrese izvorišta i broja porta izvorišta identificirana je jedna aplikacija (npr. APP2), dok je

pomodu IP adrese odredišta i broja porta odredišta omogudeno paralelno ostvarivanje više UDP veza na

istu aplikaciju. Drugim riječima, neka aplikacija, preko jednog broja porta može istovremeno

komunicirati s više aplikacija na udaljenim računarima.

Reasembliranje UDP datagrama

Zato što je beskonekcijski protokol, UDP sesije se ne uspostavljaju prije početka komunikacije kao što je

to slučaj sa TCP-om. UDP se još naziva i prenosno orjetiranim protokolom. Drugim riječima, kada

28

aplikacija ima podatke za slanje, ona jednostavno odmah pošalje te podatke. Mnoge aplikacije koje

koriste UDP šalju male količine podataka koje mogu da stanu u jedan segment. Međutim, neke aplikacije

de poslati vede količine podataka koji moraju biti podjeljeni u više segmenata. Osnovna jedinici

transpotnog sloja kada je u upotrebi UDP protkol naziva se datagram, iako se ponekad oba termina i

datagram i segment koriste za opis bilo koje osnovne jedinice transportnog sloja.

Kada se pošalje više datagrama na odredište, mogude je da do njega dođu različitim putevima kroz

mrežu i tako stignu u pogrešnom redoslijedu. UDP nema način za ponovno vradanje prvobitnog

redoslijeda datagrama.

Slika. UDP kao nepouzdan i beskonekcijski protokol

Zbog te činjenice, UDP jednostavno reasemblira podatke redoslijedom kojim su stigli i takve proslijeđuje

aplikaciji. Ako je redoslijed podataka bitan aplikaciji, ona de morati da odredi pravilan redoslijed

podataka i da odredi kako podaci trebaju biti procesirani.

UDP serverski procesi i zahtjevi

Kao i TCP bazirane aplikacije, i UDP bazirane aplikacije imaju dodjeljene well-known ili registrovane

brojeve porta. Kada ove aplikacije ili procesi rade, oni de prihvatati podatke koji su adresirani na broj

porta koji im je pridružen. Kada UDP primi datagram za neki od ovih portova, proslijeđuje aplikacijske

podatke odgovarajudoj aplikaciji bazirano na broju porta.

29

Slika. UDP zahtjevi prema serveru

UDP klijentski procesi

Kao i TCP, klijent/server komunikacija je inicirana od strane klijentske aplikacije koja traži podatke od

serverskog procesa. UDP klijentski proces odabire slučajni broj porta unutar dinamičkog opsega brojeva

potrova i koristi taj broj kao izvorišni broj porta za komunikaciju. Odredišni port de obično biti well-

known port ili registrovani broj porta dodjeljen serverskom procesu.

Slika. Slanje zahtjeva na odgovarajudi port i odgovor servera

30

Slučajni brojevi porta, također, su dobri i za sigurnost na mreži. Ako postoji predvidiva shemanačina na

koji se izabiraju brojevi portova, napadač može lako simulirati pristup klijentu pokušavajudi povezivanje

na broj porta za koji postoji dobra vjerovatnoda da je ispravan. Kako nema uspostavljana sesije ukoliko

se koristi UDP, čim podaci budu spremni za slanje i brojevi portova budu definisani, UDP može formirati

datagram i proslijediti ga mrežnom sloju na adresiranje i slanje na mrežu.

Kada su jednom brojevi izvorišnog i odredišnog porta izabrani, isti par portova de se koristi u zaglavljima

svih datagrama korištenih u transakciji. Za podatke koji se vradaju od servera ka klijentu, brojevi porta

izvorišta i odredišta su obrnuti.

Pogodnosti UDP-a

Nekada je bolje za prenos poruka koristiti UDP protokol umjesto TCP protokola. Neki od tih slučajeva su:

Prenos podataka aplikacija koje same osiguravaju pouzdani prenos, ili kada aplikacija dopušta

manje gubitke.

Slanje upita jednog računara drugom računaru, uz mogudnost ponavljanja upita ako odgovor ne

stigne nakon isteka određenog vremenskog intervala.

Kada je potrebno poslati manji blok podataka, jednostavnije i brže je prenositi samo podatke,

bez dodatnih kontrola, a u slučaju pogrešnog prijema podatke poslati ponovno.

Neke aplikacije koriste i TCP i UDP. Npr., malo dodatnih podataka omogudava DNS-u da posluži mnoge

klijentske zahtjeve vrlo brzo. Ponekad ipak slanje tražene informacije može zahtjevati pouzdanost TCP-a.

U ovom slučaju, well-known broj porta 53 se koristi od strane oba protokola sa ovom uslugom.