Transportni sloj

Smeten izmeu aplikativnog i mrenog sloja,transportni sloj predstavlja centralni deo slojevite mrene arhitekture. Njegova najvanija uloga je neposredno obezbeivanje komunikacionih usluga procesima aplikacija koji se izvravaju na razliitim raunarima. Pedagoki pristup koji koristimo u ovom poglavlju podrazumeva da naizmenino govorimo o principima transportnog sloja i o tome kako se ti principi realizuju u postojeim protokolima; kao i obino, poseban naglasak se stavlja na protokole interneta, a posebno na protokole transportnog sloja TCP i UDP. Poinjemo opisivanjem odnosa izmeu transportnog i mrenog sloja. To nam omoguava da ispitamo jedan od kljunih zadataka transportnog sloja - proirivanje usluge isporuke izmeu dva krajnja sistema koja se obavlja u mrenom sloju tako da se ostvari usluga isporuke izmeu dva procesa u aplikativnom sloju koji se izvravaju na tim krajnjim sistemima. Ovaj zadatak transportnog sloja prikazaemo kada budemo opisivali transportni protokol interneta bez uspostavljanja veze, protokol UDP.

Potom se vraamo optijim temama i suoavamo se sa jednim od najosnovnijih problema umreavanja raunara - tako omoguiti pouzdanu komunikaciju preko medijuma na kojem moe doi do gubljenja ili oteenja podataka. Nizom sve sloenijih ( i stvarnih!) primera sklopiemo skup tehnika koje transportni protokoli koriste za reavanje ovih problema. Zatim emo prikazati kako su ova pravila ugrauju u TCP, transportni protokol interneta sa uspostavljanjem veze. Potom prelazimo na drugi osnovni problem umreavanja - kontrolu brzine prenosa u transportnom sloju kako bi se izbeglo zaguenje u mrei ili omoguio oporavak nakon zaguenja. Razmotriemo uzroke i posledice zaguenja, kao i uobiajene tehnike za kontrolu zaguenja. Poto ovladamo znanjima koja se tiu kontrole zaguenja, prouavamo reenje za kontrolu zaguenja koja se koristi u protokolu TCP.3.1 Uvod u usluge transportnog sloja

U predhodna dva poglavlja pomenili smo ulogu transportnog sloja i usluge koje on nudi. Ukratko emo ponoviti ono to smo o transportnom sloju ve nauili.

Protokol transportnog sloja obezbeuje logiku komunikaciju izmeu procesa aplikacija koje se izvravaju na razliitim raunarima. Pod logikom komunikacijom mislimo na to da sa stanovita aplikacije izgleda kao da su raunari na kojima se procesi izvravaju neposredno povezani, dok se, u stvarnosti, raunari mogu nalaziti na suprotnim krajevima planete, povezani preko niza rutera i razliitih vrsta linkova.

Procesi aplikacija koriste logiku komunikaciju koju obezbeuje transportni sloj za meusobnu razmenu poruka, osloboeni brige o detaljima fizike infrastrukture koja se prenosi za prenoenje tih poruka. Znaenje logike komunikacije prikazano je na slici 3.1. Kao to se vidi na slici 3.1, protokoli transportnog sloja ostvaruju se u krajnjim sistemima, a ne u mrenim ruterima. Na prednjoj strani, transportni sloj pretvara poruku koju dobija od procesa aplikacije poiljaoca u pakete transportnog sloja, u internet terminologiji poznate pod nazivom segmenti transportnog sloja. To se vri (po potrebi ) razbijanjem poruke aplikacije u manje delove i dodavanjem zaglavlja transportnog sloja u sve te delove tako da se dobiju segmenti transportnog sloja.Transportni sloj zatim prenosi te segmente do mrenog sloja predajnog krajnjeg sistema, gde se ti segmenti enkapusliraju u pakete mrenog sloja (datagrame) i alju na odredite. Vano je uoiti to da mreni ruteri obrauju samo polja datagrama mrenog sloja; to jest, ne ispituju polja segmenata transportnog sloja koja su enkapsulirana unutar datagrama. Na prijemnoj strani, mreni sloj iz datagrama izvlai segment transportnog sloja i prenosi ga do transportnog sloja. Transportnoi sloj zatim obrauje primljeni segment i podatke iz segmenta dostavlja prijemnoj aplikaciji. Mrenim aplikacijama dostupno je vie protokola transportnog sloja. Na primer, internet ima dva protokola - TCP i UDV. Svaki od ovih protokola obezbeuje drugaije usluge transportnog sloja aplikaciji koja ih koristi.

3.1.1 Odnos izmeu transportnog i mrenog sloja Seate se da u skupu protokola transportni sloj lei neposredno iznad mrenog sloja. Dok protokol transportnog sloja obezbeuje logiku komunikaciju izmeu procesa koji se izvravaju na razliitim raunarima, protokol mrenog sloja obezbeuje logiku komunikaciju izmeu raunara. Razlika je jedva primetna, ali veoma znaajna. Objasnimo ovu razliku slinou sa obinim domainstvima.

Uzmimo dve kue, jednu na Istonoj, a drugu na Zapadnoj obali, pri emu u svakoj od tih kua ivi po dvanaestoro dece. Deca u kui na Istonoj obali roaci su dece u kui na Zapadnoj obali. Deca vole da se dopisuju - svako dete svake nedelje pie po jedno pismo svakom roaku, a svako pismo se otprema u zasebnoj koverti, obinom potom. Tako se iz svake kue svake nedelje alje 144 pisma onoj drugoj kui. (Ova deca bi utedela silne novce kada bi imala e-potu!) U svakoj od ovih kua, po jedno dete - Ana na Zapadnoj obali i Bil na Istonoj - zadueno je prikupljanje i slanje pisama. Svake nedelje Ana obilazi svu svoju brau i sestre, prikuplja potu i predaje je potonoi, koji svakog dana obilazi kuu. Kada pisma stignu u kuu na Zapadnoj obali, Anin zadatak je da podeli potu svojoj brai i sestrama. Na Istonoj obali, iste te poslove obavlja Bil. U ovom primeru, potanska sluba obezbeuje logiku komunikaciju izmeu dve kue - potanska sluba prenosi pisma od kue do kue, a ne od osobe do osobe. S druge strane, Ana i Bil obezbeuju logiku komunikaciju izmeu roaka - Ana i Bil preuzimaju i isporuuju pisma svojoj brai i sestrama. Obratite panju na to da sa stanovita roaka, Ana i Bil jesu potanska sluba, iako su samo deo (krajnji deo) isporuke pisama s kraja na kraj. Ovaj primer predstavlja lepo poreenje kojim objanjavamo kako se transportni sloj odnosi prema mrenom sloju:

poruke aplikacije = pisma u kovertamaprocesi = roaci

raunari (ili krajnji sistem) = kue

protokol transportnog sloja = Ana i Bilprotokol mrenog sloja = potanska sluba (ukljuujui i potare)

Nastavimo li sa ovim poreenjem, uoavamo da Ana i Bil sav svoj posao obavljaju u vlastitim kuama; oni nisu ukljueni, na primer, u razvrstavanje pisama u nekom usputnom potanskom centru niti u prenoenju pisama iz jednog centra u drugi. Isto vai za protokole transportnog sloja koji se nalaze u krajnjim sistemima. Unutar krajnjeg sistema transportni protokol prenosi poruke od procesa aplikacija do ivice mree (tj. do mrenog sloja) i obratno, ali ni na koji nain ne utie na nain prenoenja poruke unutar same mree. U sutini, kao to se vidi na slici 3.1, usputni ruteri ne koriste, niti prepoznaju, informacije koje je transportni sloj dodao porukama aplikacije. Nastavimo nau porodinu sagu i pretpostavimo da kad Ana i Bil odu na odmor drugi par roaka - recimo, Suzan i Harvi - zamenjuje ih i skuplja i isporuuje pisma unutar njihovih kua. Naalost te dve porodice, Suzan i Harvi ne prikupljaju i ne isporuuju pisma ba kao Ana i Bil. Poto su mlai, Suzan i Harvi prikupljaju i dele pisma ree, a povremeno i izgube poneko pismo (koje izgrizu njihovi psi). Stoga, Suzan i Harvi ne pruaju iste usluge (tj. isti model usluga) kao Ana i Bil.Slino tome, raunarska mrea nudi razliite transportne protokole i svaki od tih protokola nudi aplikacijama drugaiji model usluga.

Usluge koje su Ana i Bil u stanju da ponude oigledno su ograniene moguim uslugama koje nudi potanska sluba. Na primer, ako potanska sluba ne garantuje za koliko e najdue da isporui pisama izmeu dve kue (na primer, tri dana), tada Ana i Bil ni na koji nain ne mogu garantovati koliko e roaci najvie ekati na isporuku. Slino tome, usluge koje transportni protokol moe da obezbedi obino su ograniene modelom usluga protokola mrenog sloja koji se nalazi ispod njega. Ako protokola mrenog sloja ne garantuje kanjenje ili prpusni opseg za segmente transportnog sloja koji se alju izmeu raunara, tada ni protokol transportnog sloja ne moe da garantuje kanjenje niti propusni opseg za poruke aplikacija koje se alju izmeu procesa. Meutim, transportni protokol moe da ponudi neke usluge ak i kada mreni protokol od koga zavisi ne nudi odgovarajuu uslugu u mrenom sloju. Na primer, kao to emo videti u ovom poglavlju, transportni protokol moe da ponudi aplikaciji uslugu pouzdanog prenosa podataka ak i kada mreni protokol nije naroito pouzdan, tj. ak i kada mreni protokol gubi, oteuje i duplira pakete. Drugi primer (koji obraujemo u poglavlju 8 kada razmatramo bezbednost mree) bio bi da transportni protokol moe koristiti ifrovanje kojim se garantuje da poruke aplikacija nee itati neovlaena lica, ak i ako mreni sloj ne moe da garantuje poverljivost za segmente transportnog sloja.3.1.2 Kratak pregled transportnog sloja na internetuSeate se da internet, kao i svaka TCP/IP mrea, aplikativnom sloju nudi dva potpuno razliita transportna protokola. Jedan od tih protokola je UDP (User Datagram Protocol) koji aplikaciji koja ga koristi nudi nepouzdanu uslugu bez uspostavljanja veze. Drugi protokol je TCP(Transmission Control Protocol), koji aplikaciji koja ga koristi nudi pouzdanu uslugu sa uspostavljanjem veze. Pri projektovanju mrene aplikacije, programmer mora da navede jedan od dva transportna protokola. Kao to smo videli u odeljcima 2.6 i 2.7, programer bira izmeu protokola UDP i TCP prilikom izrade soketa. Da bi terminologija bila jednostavnija, kada govorimo o internetu, pakete transportnog sloja nazivamo segmentima. Pomenuemo, meutim, da se u internet literature (na primer u RFC dokumentima) za pakete transportnog sloja za protokol TCP koristi izraz segmenti, dok se za pakete protokola UDP koristi izraz datagrami. Ista ta internet literatura takoe koristi izraz datagram i za paket mrenog sloja!Smatramo da emo u uvodnoj knjizi o umreavanju raunara, kakva je ova, spreiti zabunu ako pakete oba protokola, TCP i UDP, zovemo segment, a ostavimo izraz datagram za pakete mrenog sloja.Pre nego to preemo na kratak uvod u protokole UDP i TCP, koristie nam da kaemo nekoliko rei o mrenom sloju interneta. (Mreni sloj podrobno je obraen u poglavlju 4.) Protokol mrenog sloja interneta zove se IP - skraenica od Internet Protocol. Protokol IP obezbeuje logiku komunikaciju izmeu raunara. Model usluga koje nudi protokol IP je usluga najboljeg pokuaja isporuke. To znai da protokol IP ini sve to moe da isporui segmente izmeu raunara, ali ne daje nikakvu garanciju. Tanije, ne garantuje isporuku segmenata, ne garantuje redosled isporuke segmenata i ne garantuje integritet podataka u segmentima. Zato se za protokol IP kae da je nepouzdana usluga. Pomenuemo takoe da svaki raunar ima bar jednu adresu mrenog sloja, takozvanu IP adresu. U poglavlju 4 podrobno razmatramo IP adresiranje; za sada je jedino vano upamtiti da svaki raunar ima IP adresu. Nakon ovog kratkog prikaza modela usluga protokola IP, opisaemo ukratko modele usluga koje pruaju protokoli UDP i TCP. Najvaniji zadatak protokola UDP i TCP jeste da uslugu isporuke protokola IP izmeu dva krajnja sistema proire na uslugu isporuke izmeu dva procesa koji se izvravaju na krajnjim sistemima. Proirivanje isporuke od raunara do raunara na isporuku od procesa do procesa naziva se multipleksiranje i demultipleksiranje transportnog sloja. Multipleksiranje i demultipleksiranje transportnog sloja razmatramo u sledeem odeljku. Protokoli UDP i TCP takoe obezbeuju proveravanje integriteta tako to u zaglavljima segmenata sadre polja za otkrivanje greaka. Ove dve osnovne usluge transportnog sloja - isporuka podataka od procesa do procesa i provera greaka - jedine su dve usluge koje prua protokol UDP! Tanije, slino protokolu IP, i protokol UDP je nepouzdana usluga - ne garantuje da e podaci koje alje jedan proces stii neoteeni (ili stii uopte!) do odredita procesa. Protokol UDP podrobno razmatramo u odeljku 3.3. S druge strane, protokol TCP nudi aplikacijama nekoliko dodatnih usluga. Prvo i najvanije, nudi pouzdan prenos podataka. Koristei kontrole toka, redne brojeve, potvrda prijema i tajmera (tehnike koje podrobno obraujemo u ovom poglavlju), protokol TCP obezbeuje da se podaci od predajnog procesa do prijemnog procesa isporue tano i u ispravnom redosledu. Na ovaj nain, TCP pretvara nepouzdanu uslugu protokola IP izmeu krajnjih sistema u pouzdanu uslugu za prenos podataka izmeu procesa. Protokol TCP takoe obezbeuje kontrolu zaguenja. Kontrola zaguenja je pre svega usluga korisna internetu kao celini, kao usluga za opte dobro, a ne toliko usluga koja se prua aplikaciji koja je poziva. Slobodno govorei, TCP nastoji da svim TCP vezama koje prolaze preko zaguenja mrenog linka dodeli jednak deo propusnog opsega. Ovo se postie regulisanjem brzine kojom TCP veza na strani poiljaoca alje podatke u mreu. Nasuprot tome, protokol UDP ne upravlja brzinom slanja podataka. Aplikacija koja koristi UDP transport moe da alje proizvoljnom brzinom dokle god to hoe. Protokol koji obezbeuje pouzdan prenos podataka i kontrolu zaguenja mora da bude sloen. Bie nam potrebno nekoliko odeljaka za opisivanje pouzdanog prenosa podataka i kontrole zaguenja, kao i dodatni odeljci za opis samog protokola TCP. Ove teme obraene su u odeljcima od 3.4 do 3.8. U ovom poglavlju naizmenino izlaemo osnovne pojmove, a zatim njihovu primenu u protokolu TCP. Na primer, prvo razmatramo pouzdan prenos podataka u optem sluaju, a zatim nain na koji protokol TCP obezbeuje pouzdan prenos podataka. Slino tome, prvo razmatramo kontrolu zaguenja u optem sluaju, a zatim nain na koji se u protokolu TCP obavlja kontrola zaguenja. Ali pre nego to se upustimo u sve to, razmotrimo najpre multipleksiranje i

demultipleksiranje transportnog sloja.3.2 Multipleksiranje i demultipleksiranjeU ovom odeljku opisujemo multipleksiranje i demultipleksiranje transportnog sloja, to jest, proirivanje usluge isporuke od raunara do raunara koju prua mreni sloj, na uslugu isporuke od procesa do procesa za aplikacije koje se izvravaju na raunarima. Da bi nae razmatranje bilo jasnije, ovu osnovnu uslugu transportnog sloja razmatramo u okviru interneta. Naglaavamo, meutim, da je usluga multipjeksiranja i demultipleksiranja potrebna svim raunarskim mreama.

U odredinom raunaru, transportni sloj prima segmente od mrenog sloja koji se nalazi neposredno ispod njega. Transportni sloj zaduen je da isporui podatke iz tih segmenata odgovarajuem procesu aplikacije koja se izvrava na odreenom raunaru.

Pogledajmo jedan primer: uzmimo da sedite pred raunarom i da preuzimate veb stranice dok se istovremeno izvravaju jedna FTP sesija i dve Telnet sesije. Prema tome, pokrenuli ste etiri procesa mrenih aplikacija - dva Telnet procesa, jedan FTP proces i jedan HTTP proces. Kada transportni sloj u vaem raunaru primi podatke od mrenog sloja ispod, on mora da usmeri primljene podatke jednom od ova etiri procesa. Sada emo videti kako se to radi.

Pre svega, seate se iz odeljaka 2.6 i 2.7 da proces (kao deo mrene aplikacije) ima jedan ili vie soketa koji predstavljaju vrata kroz koja prolaze podaci iz mree prema procesu i obratno. Prema tome, kako je prikazano na slici 3.2, transportni sloj u prijemnom raunaru u sutini ne isporuuje podatke neposredno odreenom procesu, ve posrednom soketu. Poto u svakom trenutku u prijemnom raunaru moe da postoji vie soketa, svaki od njih ima jedinstven indentifikator. Format indetifikatora zavisi od toga da li je re o UDP soketu, o emu uskoro govorimo. Razmotrimo sada kako prijemni raunar usmerava dolazni segment transportnog sloja

u odgovarajui soket. Svi segmenti transportnog sloja u tu svrhu imaju skup polja.Na prijemnom kraju, transportni sloj ispituje ova polja da bi odredio prijemni soket i zatim usmerava segment u taj soket. Ovaj zadatak isporuivanja podataka iz segmenta

transportnog sloja u odgovarajui soket naziva se demultipleksiranje. Zadatak prikupljanja delova podataka u izvornom raunam sa razliitih soketa, enkapsuliranje svakog dela dodavanjem zaglavlja (koje e se kasnije koristiti za demultipleksiranje) da bi se napravili segmenti, i predavanje tih segmenata mrenom sloju, naziva se multipleksiranje. Obratite panju na to da transportni sloj u srednjem raunaru na slici 3.2 mora da demultipleksira segmente koje dobija iz mrenog sloja ispod sebe da bi ih predao procesu P1 ili P2 iznad njega; to se postie usmeravanjem podataka iz pristiglih segmenata na soket odgovarajueg procesa. Transportni sloj u srednjem raunaru mora takoe da prikuplja odlazne podatke iz tih soketa, da formira segmente transportnog sloja i te segmente preda nanie ka mrenom sloju. Mada smo multipleksiranje i demultipleksiranje upoznali u okviru transportnih protokola interneta, vano je da shvatite da su oni vani uvek kada jedan protokol u nekom sloju (u transportnom ili bilo kom drugom sloju) koristi vie protokola iz narednog vieg sloja.

Da bismo bolje pojasnili demultipleksiranje, setite se poreenja sa domainstvom iz

prethodnog odeljka. Svako dete prepoznajemo po imenu. Kada Bil primi gomilu pisama od potara, on postupak demultipleksiranja obavlja tako to utvruje kome su pisma upuena i lino uruuje pisma svojoj brai i sestrama. Ana obavlja multipleksiranje kada prikuplja pisma od brae i sestara i predaje ih potaru. Poto smo shvatili uloge multipleksiranja i demultipleksiranja u transportnom sloju, pogledajmo kako se to zaista odvija u raunaru. Iz prethodnog razmatranja znamo da je multipleksiranje u transportnom sloju potrebno (1) da soketi imaju jedinstvene identifikatore i (2) da svaki segment sadri posebna polja koja naznaavaju soket u koji odreeni segment treba isporuiti. Ta posebna polja, prikazana na slici 3.3, su polje broja izvornog porta i polje broja odredinog porta. (UDP i TCP segmenti sadre i druga polja koja razmatramo u sledeim odeljcima ovog poglavlja.) Broj porta je 16-bitni broj, u rasponu od 0 do 65535. Brojevi portova od 0 do 1023 nazivaju se dobro poznatim brojevima portova i njihova upotreba je ograniena, to znai da su rezervisani za protokole opte poznatih aplikacija, kao to su HTTP (koji koristi broj porta 80) i FTP (koji koristi broj porta 21.) Spisak dobro poznatih brojeva portova moe se nai u dokumentu RFC 1700, i aurnijoj verziji na adresi

http://www.iana.org [RFC 3232]. Kada razvijamo novu aplikaciju (kao to je to uinjeno u odeljcima od 2.7 i 2.8), toj aplikaciji moramo dodeliti broj porta.

Sada bi trebalo da je jasno kako transportni sloj moe da primenjuje uslugu

demultipleksiranja: svakom soketu u raunaru dodeljije se broj porta, a kada neki segment stigne u taj raunar transportni sloj ispituje broj odredinog porta u segmentu i taj segment usmerava na odgovarajui soket. Podaci iz segmenta prolaze kroz soket u odgovarajui proces. Kao to emo videti, UDP u sutini tako i radi. Meutim, kao to emo takoe videti, multipleksiranje i demultipleksiranje u protokolu TCP mnogo je sloenije.Multipleksiranje i demultipleksiranje bez uspostavljanja veze

Seate se iz odeljka 2.8 da Java program koji se izvrava na raunaru pravi UDP soket redom:DatagramSocket mvSocket = new DatagramSocket() ;

Kada se na ovaj nain napravi UDP soket, transportni sloj automatski dodeljuje broj porta. Tanije, transportni sloj dodeljuje broj porta u rasponu od 1024 do 65535 koji

trenutno ne koristi nijedan drugi UDP port u raunaru. Java program bi takoe mogao da napravi soket redom:DatagramSocket mySocket = new DatagramSocket (19157) ;U ovom sluaju, aplikacija dodeljuje odreeni broj porta - odnosno 19157 - UDP soketu. Kada programer pie kod za serversku stranu dobro poznatog protokola" treba da joj dodeli odgovarajui dobro poznati broj porta. Obino, klijentska strana aplikacije dozvoljava da transportni sloj automatski (i transparentno) dodeljuje broj porta, dok se na serverskoj strani aplikacije dodeljuje tano odreeni broj porta. Poto smo UDP soketima dodelili brojeve portova, moemo precizno da opiemo UDP multipleksiranje i demultipleksiranje. Pretpostavimo da proces u raunaru A, sa UDP brojem porta 19157, eli da poalje deo podataka iz neke aplikacije procesu sa UDP portom brojem 46428 u raunaru B. Transportni sloj u raunaru A pravi segment transportnog sloja koji obuhvata podatke iz odgovarajue aplikacije, broj izvornog porta (19157), broj odredinog porta (46428) i jo dve vrednosti (o kojima govorimo kasnije, ali su nevane za trenutnu priu). Transportni sloj zatim predaje dobijeni segment mrenom sloju. Mreni sloj enkapsulira ovaj segment u IP datagram i daje sve od sebe da taj segment isporui prijemnom raunaru. Ako segment stigne do prijemnog raunara B, transportni sloj u prijemnom raunaru ispituje broj odredinog porta u segmentu (46428) i isporuuje segment u svoj soket odreen portom 46428. Treba napomenuti da raunar B moda izvrava vie procesa od kojih svaki ima vlastiti UDP soket sa odgovarajuim brojem porta. Kako UDP segmenti pristiu sa mree, raunar B usmerava (demultipleksira) segmente do odgovarajueg soketa ispitujui brojeve odredinog porta u segmentima Vano je primetiti da se UDP soket potpuno odreen dvodelnim podatkom koji se sastoji od odredine IP adrese i broja odredinog porta. Prema tome, ako dva UDP segmenta imaju razliite izvorne IP adrese i/ili razliite brojeve izvornog porta, a istu odredinu IP adresu i isti broj odredinog porta, ta dva segmenta bie usmerena istom odredinom procesu preko istog odredinog soketa.

Moda se sada udite emu slui broja izvornog porta. Kao to je prikazano na slici

3.4, u segmentu A-ka-B broj izvornog porta slui kao deo povratne adrese" - kada raunar B eli da poalje segment raunaru A, odredini port u segmentu B-ka-A uzima vrednost izvornog porta iz segmenta A-ka-B. (Potpuna adresa za odgovor sastoji se od IP adrese raunara A i broja izvornog porta.) Kao primer za ovo moe posluiti program UDP servera koji smo prouavali u odeljku 2.8. U programu UDPServer.java, server koristi metod kojim izvlai broj izvornog porta iz segmenta koji je primio od klijenta; zatim alje klijentu novi segment u kojem se dobijeni broj izvornog porta koristi kao broj odredinog porta.Multipleksiranje i demultipleksiranje sa uspostavljanjem veze

Da bismo shvatili TCP demultipleksiranje, moramo bolje da upoznamo TCP sokete i

uspostavljanje TCP veze. Najoiglegnija razlika izmeu TCP soketa i UDP soketa je u

tome to se TCP soket prepoznaje pomou etvorodelne oznake (izvorna IP adresa, broj izvornog porta, odredina IP adresa i broj odredinog porta). Prema tome, kada TCP segment pristigne sa mree na neki raunar, taj raunar koristi sve etiri vrednosti da bi usmerio (demultipleksirao) taj segment na odgovarajui soket. Tanije, nasuprot UDP segmentima, dva pristigla TCP segmenta sa razliitim izvornim IP adresama ili razliitim brojevima izvornih portova usmerie se (izuzimajui TCP segmente koji nose poetni zahtev za uspostavljanje veze) na dva razliita soketa. Da bismo dobili jo bolji uvid, razmotrimo ponovo programski primer programiranja TCP klijenta/servera iz odeljka 2.7:

TCP serverska aplikacija ima prijemni soket " koji eka zahteve za uspostavljanje veze koji stiu od TCP klijenata (slika 2.31) na broju porta 6789. TCP klijent generie segment za uspostavljanje veze redom: Socket clientSocket = new Socket ("serverHostName", 6789) ;

Zahtev za uspostavljanje veze nije nita drugo nego TCP segment sa brojem

odredinog porta 6789 i posebnim bitom za uspostavljanje veze koji je postavljen u TCP zaglavlju (razmatramo u odeljku 3.5). Segment takoe sadri broj izvornog porta koji je izabrao klijent. Prethodni red takoe pravi TCP soket za klijentski proces, kroz koji podaci mogu da ulaze u ovaj proces i da izlaze iz njega.

Kada operativni sistem raunara na kome se izvrava serverski proces primi dolazni segment sa zahtevom za uspostavljanjem veze sa odredinim portom 6789, on pronalazi serverski proces koji eka uspostavljanje veze na portu broj 6789. Serverski proces tada pravi novi soket: Socket connectionSocket = welcomeSocket.accept ( ) . Takoe, transportni sloj na serveru belei sledee etiri vrednosti iz segmenta sa zahtevom za uspostavljanje veze: (1) broj izvornog porta iz segmenta, (2) IP adresu izvornog raunara, (3) broj odredinog porta iz segmenta i (4) vlastitu IP adresu. Novonapravljeni soket veze identifikuje se pomou te etiri vrednosti; svi ubudue pristigli segmenti iji se izvorni port, izvorna IP adresa, odredini port i odredina IP adresa poklapaju sa ove etiri vrednosti bie demultipleksirani na ovaj soket. Poto je sada uspostavljena TCP veza, klijent i server mogu da alju podatke jedan drugome.Serverski raunar moe da podri vie istovremenih TCP soketa, pri emu su svi soketi pridrueni nekom procesu, a svaki soket prepoznaje se po sopstvenoj etvorodelnoj oznaci. Kada TCP segment stigne u raunar, koriste se sva etiri polja (izvorna IP adresa, izvorni port, odredina IP adresa, odredini port) da bi se segment usmerio (demultipleksirao) u odgovarajui soket.

Ovakav sluaj prikazan je na slici 3.5, na kojoj je raunar C uspostavio dve HTTP veze sa serverom B, a raunar A je uspostavio jednu HTTP vezu sa serverom B. Raunari A i C i server B imaju vlastite jedinstvene IP adrese - A, C i B respektivno.

Raunar C dodeljuje dva razliita broja (26145 i 7532) izvornih portova svojim HTTP vezama. Poto raunar A bira brojeve izvornih portova nezavisno od raunara C, on takoe moe da dodeli broj izvornog porta 26145 svojoj HTTP vezi. Ali to nije problem - server B ipak moe pravilno da demultipleksira dve veze sa istim brojem izvornog porta poto te dve veze imaju razliite izvorne IP adrese.Veb serveri i TCPPre zakljuka treba rei jo neto o veb serverima i nainu na koji oni koriste brojeve

portova. Uzmimo na primer raunar na kome se izvrava veb server, kao to je veb server Apache, na portu 80. Kada klijenti (na primer, veb itai) alju serveru segmente, svi segmenti imaju 80 kao broj odredinog porta. Tanje, segment za poetno uspostavljanje veze i segmenti koji sadre HTTP poruke sa zahtevima imaju 80 broj odredinog porta. Kao to smo upravo rekli, server razlikuje segmente od razliitih klijenata po izvornim IP adresama i brojevima izvornih portova. Na slici 3.5 prikazan je veb server koji pravi novi proces za svaku vezu. Kao

to je prikazano na slici 3.5, svi ovi procesi imaju sopstvene sokete veza kroz koje pristiu HTTP zahtevi i alju se HTTP odgovori. Napominjemo, meutim, da broj soketa nije uvek jednak broju procesa.U stvari, savremeni veb serveri visokih performansi obino koriste samo jedan proces, a prave novu nit sa novim soketom veze za sve nove veze sa klijentima. (Nit se moe posmatrati kao oslabljeni potproces.) Ako ste uradili prvi programski zadatak u poglavlju 2, napravili ste veb server koji upravo tako radi. Sa takvim serverom, u bilo kom trenutku, mogue je imati vie soketa veze(sa razliitim identifikatorima) povezanih sa istim procesom. Ako klijent i server koriste postojanu HTTP vezu, tada tokom trajanja te postojane veze klijent i server razmenjuju HTTP poruke kroz isti soket servera. Meutim, ako klijent i server koriste nepostojanu HTTP vezu, tada se nova TCP pravi i zatvara za svaki zahtev i odgovor, tako da se novi soket pravi i kasnije zatvara za svaki zahtev i odgovor. To esto pravljenje i zatvaranje soketa moe veoma loe da utie na performanse optereenog veb servera (mada se za ublaavanje ovog problema moe koristiti niz trikova sa operativnim sistemom). itaoci koje zanimaju teme koje se tiu operativnog sistema u vezi sa postojanim i nepostojanim HTTP vezama trebalo bi da proitaju [Nielsen 1997; Nahum 2002]. Poto smo razmotrili multipleksiranje i demultipleksiranje transportnog sloja, prelazimo

na razmatranje jednog od transportnih protokola interneta, protokola UDP. U sledeem odeljku videemo da protokol UDP dodaje protokolu mrenog sloja maltene samo uslugu multipleksiranja i demultipleksiranja.3.3 Prenos bez uspostavljanja veze: protokola UDPU ovom odeljku podrobnije razmatramo protokol UDP, kako radi i ta radi. Poeljno je da ponovo proitate odeljak 2.1 u kome je dat prikaz modela usluga protokola UDP i odeljak 2.7 u kome se obrauje programiranje soketa korienjem protokola UDP.

Za poetak nae rasprave o protokolu UDP pretpostavimo da elite da projektujete ogoljeni transportni protokol, bez suvunih dodataka. Kako biste mogli to da uradite? Prvo biste mogli da razmotrite korienje naizgled besmislenog transportnog protokola. Tanije, ovaj protokol bi radio tako to bi se na strani poiljaoca poruke preuzimale iz procesa odreene aplikacije i prenosile pravo u mreni sloj, dok bi se na strani primaoca poruke pristigle iz mrenog sloja prenosile pravo u proces odgovarajue aplikacije. Meutim, kao to smo nauili u prethodnom odeljku, ipak moramo da uradimo bar neto vie od toga! Najmanje to transportni sloj mora da obezbedi jeste usluga multipleksiranja i demultipleksiranja za prenoenje podataka izmeu mrenog sloja i odgovarajueg procesa u aplikativnom sloju. Protokol UDP, definisan u dokumentu [RFC 768], obavlja najmanje to transportni protokol moe uopte da uradi. Osim poslova multipleksiranja i demultipleksiranja i najosnovnije provere greaka, on protokolu IP ne dodaje nita vie. U sutini, ako programer neke aplikacije izabere da koristi protokol UDP umesto protokola TCP mada se ta aplikacija skoro neposredno obraa protokolu IP. UDP uzima poruke od procesa aplikacije, pridruuje joj polja sa brojevima izvornog i odredinog porta koji se koriste za multipleksiranje i demultiplesksiranje, dodaje jo dva manja polja i tako dobijeni segment predaje mrenom sloju. Mreni sloj enkapsulira ovaj segment transportnog sloja u IP datagram i zatim na najbolji mogui nain nastoji da taj segment isporui prijemnom raunaru. Ako segment stigne do prijemnog raunara, UDP koristi broj odredinog porta kako bi podatke iz segmenta isporuio procesu odgovarajue aplikacije. Napominjemo da u protokolu UDP nema isklaivanja za uspostavljanja veze izmeu otpremnih i prijemnih entiteta transportnog sloja pre slanja segmenta. Zato se za UDP kae da je protokol bez uspostavljanja veze DNS je primer protokola aplikativnog sloja koji obino koristi UDP. Kada DNS

aplikacija u nekom raunaru eli da postavi upit, ona pravi DNS poruku sa upitom i tu poruku predaje protokolu UDP. Bez prethodnog isklaivanja sa UDP entitetom koji se izvrava u odredinom krajnjem sistemu, klijentska strana protokola UDP poruci sa upitom dodaje polja zaglavlja i tako dobijeni segment predaje mrenom sloju. Mreni sloj enkapsulira ovaj UDP segment u datagram i alje ga serveru imena. DNS aplikacija na raunaru koji je postavio upit zatim eka odgovor na upit. Ako ne dobije odgovor (moda zato to je mrea izgubila upit ili odgovor), DNS aplikacija pokuava da poalje upit drugom serveru imena ili obavetava aplikaciju koja ju je pozvala da ne moe da dobiti odgovor. Moda vas udi zato programeri uopte grade aplikacije koristei UDP umesto protokola TCP. Zar nije uvek bolje izabrati TCP, poto TCP nudi uslugu pouzdanog prenosa podataka, a UDP je ne nudi? Odgovor je ne, poto mnogim aplikacijama UDP vie odgovara iz sledeih razloga: Bolja kontrola na nivou aplikacije toga to se alje i kada se alje. Ako se koristi UDP, im proces aplikacije preda podatke protokolu UDP, UDP e spakovati podatke u UDP segment i taj segment odmah predati mrenom sloju. S druge strane, TCP ima mehanizam za kontrolu zaguenja koji zadrava TCP slanje u transportnom sloju kada linkovi izmeu izvorinog i odredinog raunara postanu preterano zagueni. TCP e takoe vie puta da alje isti segment dokle god od odredita ne dobije potvrdu da je segment primljen bez obzira na to koliko dugo takva pouzdana isporuka traje. Poto aplikacije u realnom vremenu obino zahtevaju najmanju brzinu slanja i ne ele preterano da odlau prenoenje segmenta, a mogu da podnesu manji gubitak podataka, model usluga protokola TCP nije naroito pogodan za potrebe takvih aplikacija. Kao to kasnije objanjavamo, ove aplikacije mogu da koriste UDP i da, u okviru same aplikacije, obave sve dodatne zadatke koji su im neophodni pored osnovne usluge isporuke segmenata koju nudi protokol UDP.

ema uspostavljanja veze. Kao to emo objasniti kasnije, TCP koristi

trostruko usaglaavanje pre nego to pone da sa prenoenjem podataka, UDP jednostavno kree bez ikakve ceremonijalne najave. Zato u protokolu UDP nema kanjenja zbog uspostavljanja veze. To je verovatno glavni razlog zbog kojeg se DNS usluga izvrava preko protokol UDP, a ne preko protokola TCP- DNS usluga bila bi mnogo sporiji ukoliko bi se izvravala preko protokola TCP. HTTP koristi TCP, a ne UDP poto je pouzdanost izuzetno znaajna veb stranicama sa tekstom. Ipak, kao to smo ukratko napomenuli u odeljku 2.2, kanjenje zbog uspostavljanja TCP veza u prokolu HTTP znaajno doprinosi ukupnom kanjenju koje postoji prilikom preuzimanja veb dokumenta. Nema stanja veze. TCP odrava stanje veze u krajnjim sistemima. Ovo stanje

veze obuhvata privremene memorije za primanje i slanje, parametre za kontrolu

zaguenja, redne brojeve i parametre rednih brojeva i brojeva potvrda prijema. Videemo u odeljku 3.5 da su ove informacije o stanju neophodne za primenu pouzdanog prenosa podataka i za obezbedenje kontrole zaguenja u protokolu TCP. Nasuprot tome, UDP ne odrava stanje veze i ne vodi rauna o bilo kom od ovih parametara. Zato server namenjen odreenoj aplikaciji moe obino da podri

mnogo vie aktivnih klijenata ako se aplikacija izvrava preko protokola UDP umesto preko protokola TCP. Manje dodatno zaglavlje paketa. TCP segment ima zaglavlje od 20 dodatnih

bajtova, dok UDP ima samo 8 dodatnih bajtova.

Na slici 3.6 navedene su popularne internet aplikacije i transportni protokoli koje one

koriste. Kao to bismo i oekivali, e-pota, pristup udaljenim terminalima, veb i prenosfajlova izvravaju se protokolom TCP - svim tim aplikacijama neophodna je usluga pouzdanog prenosa podataka protokola TCP. Ipak, mnoge vane aplikacije izvravaju se protokolom UDP, a ne protokolom TCP. UDP se koristi za auriranje RIP tabela rutiranja (proitajte odeljak 4.6.1). Poto se dopune RIP tabela alju povremeno (obino svakih 5 minuta), izgubljene dopune zamenjuju se sveijim dopunama, tako da su izgubljene i zastarele dopune beskorisne. UDP se takoe koristi za prenos

podataka za upravljanje mreom (SNMP; pogledajte poglavlje 9). U ovom sluaju UDP je bolji u odnosu na TCP poto aplikacije za upravljanje mreom obino moraju da se izvravaju kada je mrea u vanrednom stanju - upravo kako smo ve pomenuli, DNS se izvrava preko protokola UDP ime se izbegava kanjenja za uspostavljanje TCP veza. Kao to je prikazano na slici 3.6, oba protokola, i UDP i TCP danas se koriste za multimedijalne aplikacije, kao to su telefoniranje preko interneta, video konferencije u realnom vremenu i protok snimljenih audio i video zapisa. Ove aplikacije podrobnije razmotriti u poglavlju 7. Za sada samo napominjemo da sve te aplikacije mogu da podnesu manje gubitke paketa, pa pouzdani proces podataka nije apsolutno neophodan za uspean rad aplikacije. tavie, aplikacije u realnom vremenu, kao to su internet telefoniranje i video konferencije, veoma loe podnose kontrolu zaguenja protokola TCP. Zato programeri multimedijalnih aplikacija esto odluuju da im se aplikacije izvravaju korienjem protokola UDP umesto protokola TCP. Meutim, TCP se sve vie koristi za prenos multimedijalnih zapisa. Na primer, u radu [Sripanidkulchai 2004] se tvrdi da u skoro 75% protokola multimedijalnih zapisa uvio i na zahtev koristi TCP. U sluajevima kada je broj izgubljenih paketa mali i kada neke organizacije blokiraju UDP saobraaja iz bezbednosnih razloga (pogledajte poglavlje 8), TCP postaje sve zanimljiviji protokol za prenos multimedijalnih zapisa.

Mada se danas esto koristi, izvravanje multimedijalnih aplikacija preko protokola UDP je u izvesnoj meri sporno. Kao to smo ve pomenuli, UDP nema kontrolu zaguenja. Meutim, kontrola zaguenja je neophodna da bi se spreilo da mrea doe u stanje u kojem se malo ta korisno moe uraditi. Kada bi svi pokrenuli prenos video zapisa u realnom vremenu velikom brzinom protoka, bez ikakve kontrole zaguenja, ruteri bi bili preplavljeni paketima tako da bi samo manji broj paketa uspeno preao put od izvora do odredita. tavie, veliki broj izgubljenih paketa od strane nekontrolisanih UDP poiljaoca doveo bi do toga da TCP poiljaoci (koji, kao to emo videti, smanjiti svoje brzine prenosa suoeni sa zaguenjem) znaajno smanjenje svoje brzine. Prema tome, posledica nedostatka kontrole zaguenja u protokolu UDP moe da bude veliki broj izgubljenih paketa izmeu UDP poiljaoca i primaoca, kao i istiskivanje uspostavljenih TCP veza to predstavlja potencijalno veliki problem [Floyd 1999]. Mnogi istraivai predlau nove mehanizme kojima bi se svim izvorima, pa i UDP izvorima, nametnula prilagodljiva kontrola zaguenja [Mahdavi 1997; Floyd 2000; Kohler 2006; RFC 4340]. Pre nego to preemo na opis strukture UDP segmenta, napominjemo da jeste mogue da aplikacija dobije pouzdan prenos podataka kada koristi UDP. To se moe postii ako se pouzdanost ugradi u samu aplikaciju (na primer, dodavanjem mehanizama za potvrivanje prijema i ponovno slanje, poput onih koje prouavamo u sledeem odeljku). Ali, ovo nije prost zadatak i zadao bi programeru mnogo dodatnog posla. Ipak, ugraivanje pouzdanosti neposredno u samu aplikaciju omoguava da ona zadri ,,i jare i pare". Drugim reima, procesi aplikacije mogu da ostvare pouzdanu komunikaciju ne trpei ogranienja brzine slanja koje namee mehanizam za kontrolu zaguenja protokola TCP.3.3.1 Struktura UDP segmenta Struktura UDP segmenta, prikazana na slici 3.7, definisana je u dokumentu RFC 768. Podaci aplikacije zauzimaju polju podataka UDP segmenta. Na primer, za DNS, polje podataka sadri ili poruku sa upitom ili poruku sa odgovorom. Za audio aplikacije sa protokolom u realnom vremenu, polje podataka popunjava se audio zapisima. UDP zaglavlje ima samo etiri polja od kojih svako zauzima dva bajta. Kao to je reeno u prethodnom odeljku, brojevi portova omoguavaju odredinom raunaru da podatke aplikacije prosledi odgovarajuem procesu koji se izvrava na odredinom krajnjem sistemu (tj. da obavi demultipleksiranje). Kontrolni zbir slui prijemnom raunaru da proveri da li je u segmentu dolo do greaka. Iskreno govorei, kontrolni zbir izraunava se korienjem i nekoliko polja iz IP zaglavlja, a ne samo nad UDP segmentom.Zanemariemo ovu pojedinost kako bismo videli umu kroz drvee. U produetku opisujemo izraunavanje kontrolnog zbira. Osnovna pravila koja se primenjuju za otkrivanja greke opisana su u odeljku 5.2. Polje duine odreuje duinu UDP segmenta u bajtovima, ukljuujui i zaglavlje.

3.3.2 UDP kontrolni zbirUDP kontrolni zbir slui za otkrivanje greke. Drugim reima, kontrolni zbir se koristi kako bi se utvrdilo da li su bitovi unutar UDP segmenta promenjeni (na primer, zbog smetnji u linkovima ili dok se segment nalazio u ruteru) prilikom prenosa od izvora do odredita. UDP na strani poiljaoca izraunava komplement jedinice za sumu svih 16-bitnih rei u segmentu, pri emu se odbacuju sva prekoraenje do kojih doe prilikom sabiranja. Ovaj rezultat se stavlja u polje kontrolnog zbira UDP segmenta. Ovde dajemo jednostavan primer izraunavanja kontrolnog zbira. Podrobniji opis izraunavanja moete nai u dokumentu RFC 1071, a primer sa stvarnim podacima u [Stone 1998; Stone 2000]. Kao primer, pretpostavimo da imamo sledee tri 16-bitne rei:0110011001100000

0101010101010101

1000111100001100

Zbir prve dve rei je:

0110011001100110

0101010101010101

1011101110111011

Dodavanjem tree rei:

1011101110111011

0000111100001111

1100101011001010Obratite panju na to da poslednje sabiranje daje prekoraenje, koje je odbaeno. Komplement jedinice dobija se pretvaranjem svih 0 u 1, a svih 1 u 0. Prema tome, komplement zbira 010010101100010 je 1011010100111101, to se uzima kao kontrolni zbir. Na prijemnom kraju, sabirajui se sve etiri 16-bitne rei, ukljuujui i kontrolni zbir. Ako u paketu ne postoje greke, jasno je da e zbir kod primaoca biti 1111111111111111. Ako je neki od bitova jednak 0, znamo da je u paketu dolo do greke. Moda vas udi to UDP uopte koristi kontrolni zbir kada mnogi protokoli sloja veze (ukljuujui i popularni protokol Ethernet) takoe sadre proveru greaka. Razlog lei u tome to ne postoji garancija da svi linkovi od izvora do odredita obezbeuju proveru greaka; to jest, neki od linkova moda koristi protokol sloja veze koji ne nudi proveru greaka. tavie, ak i ukoliko se segment tano prenese du linkova, mogue je da se pogrean bit pojavi dok se segment nalazi u memoriji rutera. Poto se ne garantuju niti pouzdan prenos izmeu linkova niti otkrivanje greaka nastalih u memoriji, UDP mora da obezbedi otkrivanje greaka na transportnom sloju, od jednog do drugog kraja, ako usluga prenosa podataka treba da obezbedi otkrivanje greaka od jednog do drugog kraja. Ovo je primer primene slavnog principa od jednog do drugog kraja u projektovanju sistema [Saltzer 1984] koje kae da se izvesni zadatak (otkrivanje greaka, u ovom sluaju) mora primeniti od jednog do drugog kraja: poslovi koji se obavljaju na niim nivoima moda su suvini ili manje vredni kada se porede sa time to je potrebno uraditi da bi se ostvarili na viem nivou. Poto se smatra da protokol IP moe da se izvrava preko ma kog protokola sloja 2, korisno je da transportni sloj obezbedi proveru greaka za svaki sluaj. Mada UDP nudi proveru greaka, on nita ne preduzima da bi se nastala greka ispravila. U nekim verzijama protokola UDP, oteeni segment se jednostavno odbacuje; dok druge verzije aplikaciji prosleuju oteeni segment uz upozorenje. Ovim zakljuujemo opis protokola UDP. Uskoro emo videti da TCP nudi svojim

aplikacijama pouzdan prenos podataka kao i neke druge usluge koje UDP ne nudi. Naravno, protokol TCP je zato mnogo sloeniji od protokola UDP. Pre nego to preemo na razmatranje protokola TCP, bie korisno da se vratimo za jedan korak i prvo razmotrimo osnovne principe pouzdanog prenosa podataka.

Sadraj

2Transportni sloj

23.1 Uvod u usluge transportnog sloja

33.1.1 Odnos izmeu transportnog i mrenog sloja

63.1.2 Kratak pregled transportnog sloja na internetu

73.2 Multipleksiranje i demultipleksiranje

143.3 Prenos bez uspostavljanja veze: protokola UDP

173.3.1 Struktura UDP segmenta

183.3.2 UDP kontrolni zbir

POGLAVLJE 3 ~ TRANSPORTNI SLOJSrana 1