Umrezavanje Racunara III Izdanje

P R E V O D T R E E G
I Z D A N J A
Umreavanje raunara
Od vrha ka dnu sa
Internetom u fokusu

James F. Kurose
Univerzitet Masausets, Amherst
Keith W. Ross
Politehniki univerzitet, Bruklin

Umreavanje raunara
Od vrha ka dnu sa Internetom u fokusu
O autorima
ISBN 86-7991-267-0
Autorizovan prevod sa engleskog jezika prvog ir.danja knjige Computer Networking: A Top-Down
Approach Featuring the Internet
Original Copyright
c
2005. by Pearson Education, Inc. Copyright
prevoda, 2005. RAF Raunarski fakultet, Beograd i CET Computer
Equipraeot and Trade, Beograd
Sva prava zadrana. Nijedan deo ove knjige ne moe biti reprodukovan, snimljen, ili emitovan na bilo
koji nain: elektronski, mehaniki, fotokopiranjem, ili drugim vidom, bez pisane dozvole izdavaa.
Informacije koricene u ovoj knjizi nisu pod patentnom zatitom. U pripremi ove knjige uinjeni su
svi napori da se ne pojave greke. Izdava i autori ne preuzimaju bilo kakvu odgovornost za
eventualne greke i omake, kao ni za njihove posledice.
Prevodioci
Jasna Gonda, Stanislav Kocal, dr Radomir Jankovi
Recenzent
prof, dr Stevan Milinkovi
Lektor
Milanka Stojanovi-Vorkapi
Urednik
Radmila Ivanov
Izvrni urednik
Aleksandra Dimic
Tehniki urednik
Duan ai
Organizator projekta
Vladan Mirkovi
Prelama
Predrag Stanisavljevi
Izdava
RAF Raunarski fakultet, Beograd, Knez Mihailova 6A/[ tel.
011 627-613, 633-321; http://www.raf.edu.yu
CET Computer Etjuipment and Trade, Beograd, Skadarska 45
tel/fax: 011 3243-043, 3235-139, 3237-246; http:/fw\vw.cet.co.yu
Za izdavaa
Dragan Stojanovi, direktor
Obrada korica Predrag
Stanisavljevi
Tira
1000
tampa
Svetlost", aak
Jim Kurose
jim Kurose je profesor raunarskih nauka no Masauselskom
univerzitetu u Amherslu.
Dr Kurose je dobio brojna priznanja za svoj prosvefni rad;
izmeu ostalog, osam pula je nagraivan za dostignua u nastavi
samo od strane Nacionalnog tehnikog univerziteta, a slina
priznanja je dobio i od Masauselskog univerziteta i Severoistonog
udruenja visokokolskih ustanovo. Dobitnik je medalje Taylor
Boolh za obrazovanje koju dodeljuje IEEE, a poznat je i po
uspenom voenju Masauselske savezne inicijative za informatiku
lehnologiju. Dobitnik je stipendije GE [General Engineering) koju
dodeljuje CIC {Commiltee on Insfilutional Corpoiotion), IBM-ove nagrade zo dostignua u .
nastavi, kao i stipendije Lilly koja se dodeljuje za unapreenje predavackih sposobnosti.
Dr Kurose je bivi glavni urednik asopisa IEEE Transactions on Communicalions, kao i IEEE
Tron&aciiom on Netvsotking. Dugi niz godina bio je aklivan u programskim, odborima IEEE Infocom, ACM
SIGCOMM i ACM SIGMETRICS i obavljao funkciju
:
' kopredsedavajueg u tehnikim programima na
tim konferencijama. lan je organizacija IEEE i ACM. U istraivanjima se bavi mrenim protokolima i
arhitekturom, mrenim merenjima, senzorskim mreama, multimedijskom komunikacijom, modeliranjem i
procenama performansi. Doktorat iz oblasti raunarskih nauka odbranio je na Kolumbijskom univerzitetu. .
Keith Ross
Keilh Ross je profesor raunarskih nauka na Poiitehnikom univerzitetu u
Bruklinu, koji je stao na elo fondacije LeonardaJ. Shusleka za raunarske nauke.
Od 1985. do 1998. godine bio je profesor na Odeljenju za sistemski inenjering no
Pensilvanijskom univerzitetu. Od 1998. do 2003. godine bio je profesor na
Odeljeû zo multimedijske komunikacije no insiiiulu Eurecom u Francuskoj. Keilh
Ross je lokode glavni osniva i prvi direktor organizacije VVimba koja se bavi
razvojem tehnologija za prenos govora preko IP-a za trite elektronskog uenja.
Dr Ross je objavio brojne istraivake izvelaje i dve knjige.
Bio je lan izdavakih saveta mnogih asopisa, ukljuujui i IEEE/ACM Transactions on \ Netv/orking, i
mnogih programskih odbora, koo to su ACM SIGCOMM i IEEE Infocom.;' Bio je mentor za 1-5
doktorskih teza. Njegova predavaka i istraivaka interesovanja ; obuhvalaju P2P sisteme, multimedijsko
umreavanje, mrene protokole i slahastike mree. Doktorat je odbranio na Miigenskom univerzitetu.

Uvod
Dobrodoli u tree izdanje knjige Umreavanje raunara: Od vrha ka dnu sa Internetom u
fokusu. Od kada se pre otprilike dve godine pojavilo prvo izdanje, ova knjiga je prihvaena na
stotinama koleda i univerziteta, prevedena je na vie od ]0 jezika i koristile su je hiljade
studenata, ali i strunjaka irom sveta. Od veoma velikog broja italaca dobili smo povratne
informacije i to su najee bile pohvale.
Jedan od osnovnih aduta ove knjige, po naem ubedenju, jeste njen sve pristup
problematici umreavanja raunara. Zbog ega insistiramo na sveem pristupu? Zbog toga to
smo poslednjih godina svedoci dve revolucionarne promene u oblasti umreavanja kojima
nije posveena odgovarajua panja u radovima o umreavanju objavljivanim tokom 1980-ih
i 1990-ih. Najpre, Internet je potpuno osvojio oblast raunarskih mrea. Svaka iole ozbiljnija
rasprava o umreavanju mora da ima Internet u fokusu. Zatim, u poslednjih nekoliko godina
izuzetan pomak dogodio se na polju mrenih usluga i aplikacija, to se moe zakljuiti na
osnovu pojave Weba, sveopte prisutnosti elektronske pote, protoka audio i video signala u
realnom vremenu, Internet telefona, trenutne razmene poruka, aplikacija za mree
ravnopravnih raunara, kao i onlajn kupovine i prodaje.
Staje novo u treem izdanju?
Iako su u ovom, treem, izdanju knjige nainjene mnoge izmene, u knjizi je ipak zadrano
ono to smatramo njenim najznaajnijim aspektima, a predavai i studenti koji su koristili
prvo izdanje potvrdili su daje zaista tako. Ukratko, to su: pristup od vrha ka dnu, fokus na
Internetu, ravnopravnost teorijskih principa i vebanja, pristupaan stil i karakteristino
objanjenje umreavanja.
Meutim, u treem izdanju napravili smo i neke znaajnije izmene - primera radi, ubacili
smo potpuno novo poglavlje o beinim i mobilnim mreama. Danas smo svedoci velikih
promena u nainu na koji korisnici pristupaju Internetu i njegovim uslugama. Korisnici sada
ostvaruju beini pristup Internetu iz svojih kancelarija, domova i javnih ustanova. itav niz
ureaja, kao to su laptop i PDA raunari i telefoni, omoguavaju vam da pristupite Internetu
dok ste na putu ili u pokretu. U poglavlju koje smo posvetili beinim i mobilnim
tehnologijama pronai ete detaljan prikaz standarda 802.11, zatim prikaz pristupa Internetu
putem mobilnih telefona, kao i iscrpno razmatranje mobilnosti u kontekstu Interneta i mrea
mobilne telefonije. Sa dodavanjem ovog novog poglavlja, u udbeniku sada postoje etiri
napredna i specijalizovana poglavlja ija su tema beine i mobilne mree, zatim
multimedijalne mree, mrena bezbednost i upravljanje mreama.
Drugi znaajan dodatak predstavlja skup praktinih Ethereal laboratorijskih vebi.
Ethereal je besplatna alatka za pregledanje i analizu paketa koja se nalazi u javnom domenu i
moe da sc koristi pod svim popularnim operativnim sistemima,

v
i
Uvod Uvod vii
ukljuujui tu i najrasprostranjenije operativne sisteme tipa Wind6ws. Iz izuzetno bogate
funkcionalnosti ove alatke izdvajamo intuitivni korisniki interfejs i mogunost analize blizu
400 protokola. Osim starih i novih programerskih zadataka u knjizi sada postoji i est Ethereal
laboratorijskih vebanja koja su usklaena sa gradivom i koja svaki student moe da proveba
na svom raunam. (U budunosti emo dodati jo ovakvih laboratorijskih vebanja.) Tokom
ovih vebanja studenti mogu da posmatraju mrene protokole na delu i da prate interakciju
izmeu entiteta protokola koji se izvravaju na njihovim raunarima i drugih takvih entiteta koji
se izvravaju negde na Internetu. Dakle, ove vebe omoguavaju uenje kroz praktian rad.
Osim toga, dodali smo i dva nova programerska zadatka: zadatak u vezi sa protokolom UDP i
zadatak u vezi sa proksi veb serverom.
Ovo nije sve. Auriranjem treeg izdanja pokuali smo da obuhvatimo sve znaajne i brze
promene koje su se dogodile u oblasti umreavanja u proteklih nekoliko godina. U pitanju su
novi ili dopunjeni sadraji o mreama ravnopravnih raunara, protokolima BGP i MPLS,
mrenoj bezbednosti, o rutiranju sa difuznim emitova-njem i adresiranju i prosleivanju na
Internetu. Poglavlje 4 sada ima malo izmenjenu strukturu zato to smo eleli da to jasnije
izloimo uloge prosledivanja i rutiranja, kao i njihovu interakciju sa mrenim slojem.

Ciljna grupa
Ovaj udbenik zamiljen je kao prva nastavna jedinica o umreavanju raunara i moe se
koristiti i u raunarstvu i u elektrotehnici. U pogledu programskih jezika u ovoj knjizi se
pretpostavlja da student ima iskustva u radu sa programskim jezicima C, C++ ili Java. Polaznik
koji je programirao samo u programskim jezicima C ili C++, a nije u Javi, nee imati nikakvih
problema u praenju ovog materijala i pored toga stoje on predstavljen upravo u kontekstu
programskog jezika Java. Iako se ova knjiga odlikuje veom preciznou i analitinou u
odnosu na mnoge druge uvodne udbenike o umreavanju, u njoj neete nai mnogo
matematikih koncepata sa kojima se ve niste sreli u gimnaziji. Namerno smo se potrudili da
izbegnemo sve naprednije proraune, verovatnou i koncepte stohastikih procesa. Prema tome,
ova knjiga odgovarae studentima na redovnim studijama kao i onima koji su na poetku
postdiplomskih studija. Isto tako, ona bi mogla da bude izuzetno korisna strunjacima koji ve
rade u telekomunikacionoj industriji.

Sta je jedinstveno u ovoj knjizi?
Umreavanje raunara je izuzetno sloena tema koja obuhvata mnotvo koncepata, protokola i
tehnologija, kao i njihove nita manje sloene interakcije. Da bi mogli da se izbore sa ovom
izuzetnom sloenou, razni autori su svoje tekstove o umreavanju raunara organizovali oko
slojeva" mrene arhitekture. Slojevita organizacija omoguava studentima da uoe svu
sloenost umreavanja raunara. Drugim recima, uei o konkretnim konceptima i protokolima
u jednom delu arhitekture oni i dalje mogu da vide itavu sliku i nain na koji se sve
komponente uklapaju u nju.
Primera radi, veliki broj tekstova organizovan je oko sedmoslojne arhitekture referentnog
modela OSI. Gledano iz pedagoke perspektive, ovakav slojevit pristup je veoma poeljan u
nastavi. Meutim, uoili smo da tradicionalni pristup od dna ka vrhu, odnosno od fizikog sloja
ka aplikativnom, u savremenoj nastavi iz oblasti umreavanja raunara nije najpodesniji.
Pristup od vrha ka dnu
Pre otprilike 4 godine ovaj udbenik je doneo jednu veoma bitnu novinu - pristup od vrha ka
dnu. To znai da emo ovde poeti od aplikativnog sloja i zatim ii nanie ka fizikom. Ovakav
pristup ima nekoliko vanih prednosti. Pre svega, u njemu je naglasak na aplikativnom sloju koji
je u umreavanju predstavljao segment sa najveom ekspanzijom. Mnoge od nedavnih
revolucionarnih pojava u oblasti umreavanja - ukljuujui Web, protok audio i video signala u
realnom vremenu (striming), i distribuciju sadraja - odigrale su se upravo na aplikativnom
sloju. Naglasak na aspektima aplikativnog sloja od samog poetka izlaganja, razlikuje se od
pristupa u drugim tekstovima sline tematike, u kojima je mrenim aplikacijama, njihovim
zahtevima, paradigmama aplikativnog sloja (odnosu klijent/server) i programskim interfejsima
aplikacije posveeno veoma malo (ili nimalo) vremena.
Zatim, kao predavai, uverili smo se da izlaganje o mrenim aplikacijama na poetku
obrade ove nastavne oblasti znaajno motivie studente za druge nastavne jedinice. Studente
veoma zanima na koji nain funkcioniu mrene aplikacije (na primer, aplikacije za elektronsku
potu ili Web) sa kojima se svakodnevno susreu. Onog trenutka kada studenti razumeju nain
rada ovih aplikacija, sa njima se moe priati i o mrenim uslugama koje podravaju ove
aplikacije. Nakon toga oni mogu da razmiljaju i o razliitim nainima na koje se ove usluge
obezbeduju i implementiraju na niim slojevima. Dakle, rani prikaz aplikacija deluje kao jak
motivacioni faktor za itanje ostatka teksta.
Konano, pristup od vrha ka dnu omoguava predavaima da uvedu razvoj mrenih
aplikacija na samom poetku nastave iz ove oblasti. Pored toga to mogu da naue na koji nain
funkcioniu popularne aplikacije i protokoli, studenti mogu da vide i koliko je jednostavno da se
naprave vlastite mrene aplikacije i protokoli aplikativnog sloja. Dakle, pristupom od vrha ka
dnu postignuto je da se studenti veoma rano u nastavi upoznaju sa pojmovima kao to su
programski interfejs aplikacije (API), modeli usluga i protokoli - veoma vanim konceptima na
koje emo se vraati u svim narednim poglavljima. Primerima o programiranju soketa u Javi
pokuali smo da istaknemo centralne koncepte, a da pri tom ne zbunimo studente, previe
sloenim kodom. Studenti elektrotehnike i raunarstva ne bi trebalo da imaju problema u pra-
enju ovog koda.

Fokus na Internetu
Kao to moete da zakljuite iz naslova ove knjige, u njoj emo se u znaajnoj meri baviti
Internetom, iji su arhitektura i protokoli iskorieni kao sredstvo za prouavanje nekih
fundamentalnijih koncepata umreavanja. Naravno, ovde ete pronai

Uvod
Uvod

koncepte i protokole koji pripadaju drugim mrenim arhitekturama, ali je naglasak oigledno
na Internetu, to se vidi i iz organizacije same knjige koja prati petoslojnu arhitekturu
Interneta (aplikativni, transportni, mreni sloj, zatim sloj veze i, na kraju, fiziki sloj).
Druga prednost isticanja Interneta jeste to to je veina studenata elektrotehnike i
raunarstva prilino nestrpljiva da sazna to vie o Internetu i njegovim protokolima. Oni
svakodnevno koriste Internet (makar za slanje elektronske pote i krstarenje po Webu) i
sasvim sigurno su mnogo puta uli daje Internet revolucionarna tehnologija koja menja svet.
Imajui u vidu ogroman znaaj Interneta, prirodno je da su studenti veoma nestrpljivi da
proniknu u njegove tajne. Zahvaljujui tome, predavau je sasvim jednostavno da panju
studenata vee za neke osnovne principe kada kao primer koristi Internet.

Insistiranje na principima
Dva jedinstvena aspekta ove knjige - pristup od vrha ka dnu i fokus na Internetu -pojavljuju se
u njenom podnaslovu. Da smo u podnaslov mogli da uklopimo i treu kljunu re, to bi
svakako bila re principi. Polje umreavanja je ve dovoljno zrelo daje u njemu mogue
identifikovati nekoliko fundamentalnih aspekata. Primera radi, u fundamentalne aspekte
transportnog sloja ubrajaju se pouzdana komunikacija kroz nepouzdani mreni sloj, zatim
uspostavljanje/raskidanje veze i sinhroni-zacija, zaguenje mree i kontrola toka, kao i
muftipleksiranje. U mrenom sloju, dva fundamentalno vana aspekta su pronalaenje
dobrih" putanja izmeu dva rutera i rukovanje vezama izmeu veeg broja heterogenih
sistema. U sloju povezivanja podataka, fundamentalni problem predstavlja zajedniko
korienjc kanala za viestruki pristup. Na polju mrene bezbednosti, tehnike za
obezbeivanje tajnosti, proveru autentinosti i integriteta poruka zasnivaju se na osnovnim
principima ifro-vanja. U ovoj knjizi identifikovani su fundamentalni aspekti umreavanja,
kojima je zatim posveena odgovarajua panja. Kada ih savladaju, studenti e stei znanje
koje e biti relevantno i u budunosti, onda kada aktuelni protokoli i standardi postanu deo
prolosti. Verujemo da e kombinacija korienja Interneta za motivi-sanje studenata, zatim
isticanja odreenih aspekata i traenje reenja. omoguiti studentima da veoma brzo steknu
znanja pomou kojih e moi da razumeju praktino svaku mrenu tehnologiju.

Veb lokacija
Svim itaocima ove knjige skreemo panju i na sveobuhvatnu prateu veb lokaciju
http://www.aw.com/kurose-ross na kojoj e moi da pronau:
Materijal xa interaktivno uenje. Na ovoj lokaciji ete pronai interaktivne Java aplete koji
ilustruju kljune mrene koncepte. Osim toga, ova veb lokacija (preko pretraivaa)
obezbeuje direktan pristup programima kao stoje, na primer,
Traceroute koji pokazuje putanje kojima se paketi kreu kroz Internet. Profesori ovaj
interaktivni materijal mogu da iskoriste kao svojevrsne mini-laboratorije. Ova veb lokacija
takode obezbeuje direktan pristup mehanizmima za pretraivanje dokumenata o Internetu
{Internet Drafts), kao i elektronskoj konferenciji na kojoj se razmatraju teme koje su
obraene u oVoj knjizi. Konano, na ovoj veb lokaciji postoje i interaktivni testovi koji
omoguavaju studentima da pro-vere svoje osnovno razumevanje izloene problematike.
Vie od pet stotina veza sa relevantnim materijalom. Kao to svi mi Internet entuzijasti
znamo, veliki deo materijala koji opisuje Internet nalazi se upravo na Internetu. Potrudili
smo se da na ovu veb lokaciju postavimo URL-ove za najvei mogui broj referenci za ovu
knjigu. Bibliografija je onlajn i bie aurirana onako kako se adrese budu menjale i kako se
bude pojavljivao novi materijal. U pitanju su adrese RFC dokumenata, asopisa i lanaka
sa konferencija, ali i lokacija vie pedagokog karaktera, ukljuujui i neke stranice o
pojedinim aspektima Internet tehnologije i lanke koji izlaze u asopisima za onlajn
trgovinu. Materijal koji se krije iza ovih adresa profesori mogu da preporue kao dodatnu
ili ak obaveznu literaturu.
Laboratorijski zadaci. Na pomenutoj veb lokaciji pronai ete puno detaljnih
programerskih zadataka, kao i Ethereal laboratorijska vebanja. U programer-ske zadatke
spadaju pravljenje vienitnog veb servera, pravljenje klijenta za elektronsku potu sa GUI
interfejsom, programiranje predajne i prijemne strane protokola za pouzdani prenos
podataka, programiranje algoritma distribuiranog rotiranja, kao i mnogi drugi. Na veb
lokaciji ete pronai i uputstva za Ethereal laboratorijske vebe o kojima smo govorili
ranije.

Pedagoki aspekti
Svaki od nas dvojice predaje umreavanje raunara ve skoro 20 godina. U ovu knjigu
ugraeno je, ukupno, preko 30 godina predavakog iskustva sa vie od 3 000 studenata. Osim
toga, u navedenom periodu bavili smo se i aktivnim istraivakim radom na polju umreavanja
raunara. (U stvari, Dim i Kit su se upoznali na magistarskim studijama o umreavanju, na
predmetu koji je na Univerzitetu Kolumbija 1979. godine drao Mia varc.) Upravo zato
mislimo da nam sve to zajedno daje precizan pogled na to gde se umreavanje trenutno nalazi i
kako e se razvijati u budunosti. Trudili smo se da izbegnemo pribliavanje ove knjige
vlastitim istraivakim projektima, a ukoliko vas oni zanimaju, uvek moete da posetite nae
veb lokacije. Dakle, pred vama je knjiga o savremenom umreavanju raunara - o
savre-menim protokolima i tehnologijama, kao i o principima na kojima se ti protokoli i
tehnologije zasnivaju. Ubeeni smo da uenje (i predavanje!) o umreavanju moe biti i te
kako zabavno. Nadamo se da su ale, korienje analogija i primeri iz stvarnosti uinili ovu
knjigu zabavnijom i lakom za itanje.

Uvod x
Uvod

Istorijski osvrti i principi u praksi
Oblast umreavanja raunana, poev od kraja 1960-ih godina, ima bogatu i fascinantnu istoriju,
i mi smo se potrudili da vam je kroz ovaj tekst ukratko ispriamo. U poglavlju 1 nalazi se
poseban odeljak o istoriji, dok ete u ostalim poglavljima pronai kratke istorijske osvrte. U
ovim odeljcima spominjemo pronalazak komuti-ranja paketa, evoluciju Interneta, pojavljivanje
svojevrsnih mrenih giganata kao to su kompanije Cisco i 3Com, kao i mnoge druge znaajne
dogaaje. Za veinu studenata ove informacije bie podsticajne. U svakom od poglavlja koja
slede postoje izdvojeni segmenti u kojima su istaknuti vani principi iz oblasti umreavanja
rau-nara. Pomou ovih informacija studenti e lake savladati neke od fundamentalnih
koncepata savremenog umreavanja.

Intervjui
U ovoj knjizi postoji jo jedna originalna stvar koja bi trebalo da inspirie i motivie studente, a
to su intervjui sa priznatim inovatorima na polju umreavanja kao to su Leonard Klajnrok, Tim
Berners-Li, Seli Flojd, Vint Serf, Sajmon Lam, arli Per-kins, Hening ulcrin, Stiven Belovin i
Def Kejs.

Dodatak za predavae
Kako bismo pomogli profesorima da io lake prebrode prelaz, obezbedili smo dodatni komplet
za kvalifikovane predavae. Sav ovaj materijal nalazi se u de!u veb lokacije koji je namenjen
profesorima - hUp://www.aw.com/kurose-ross. Da biste pristupili ovom segmentu nae veb
lokacije, obratite se odeljenju za prodaju kompanije Addison-Wesley ili to uinite putem
elektronske pote na adresu aw.cse@aw. com.
PowerPomt slajdovi. Na veb lokaciji koja prati ovu knjigu nalaze se PowerPo-int slajdovi
koji veoma detaljno pokrivaju svako od osam poglavlja ove knjige. U njima su (umesto
monotonih tekstualnih nabrajanja) upotrebljeni grafiki elementi i animacije to ih ini
zanimljivim i vizuelno prijemivim. Ove Power-Point slajdove profesori mogu da menjaju i
tako prilagode svojim konkretnim potrebama. Veliki broj ovih slajdova upravo i potie od
drugih predavaa koji su drali nastavu koristei nau knjigu.
Reenja domaih zadataka. Na pomenutoj veb lokaciji postoje i reenja domaih zadataka
zadatih u ovoj knjizi. Ova reenja su namenjena iskljuivo predavaima.
Diskusione grupe i doprinos drugih predavaa. Na veb lokaciji postoji i deo u kome
predavai mogu da postavljaju svoje komentare, pitanja i odgovore. Na ovom mestu
pronai ete i materijal prikupljen od drugih predavaa koji takoe koriste nau knjigu.

Meuzavisnosti poglavlja
Prvo poglavlje ove knjige predstavlja zaokrueni prikaz umreavanja raunara.
Predstavljanjem mnogih kljunih koncepata i termina, ovo poglavlje e vas pripremiti za sve
ono to sledi u ostatku knjige. Drugim recima, sva ostala poglavlja knjige direktno se
nadovezuju na materiju prvog poglavlja. Profesorima preporuujemo da, nakon poglavlja 1,
redom ispredaju poglavlja od 2 do 5 i na taj nain podvuku filozofiju od vrha ka dnu. Svako od
ovih prvih pet poglavlja oslanja se na ona poglavlja koja su ispred njega.
Nakon to ispredaje prvih pet poglavlja, profesor e imati daleko vize slobode. Izmeu
poslednja etiri poglavlja ne postoje nikakve meuzavisnosti, to znai da mogu da se predaju
bilo kojim redosledom. S druge strane, svako od njih oslanja se na materiju iz prvih pet
poglavlja. Ustanovili smo da veliki broj predavaa najpre predaje prvih pet poglavlja,
ostavljajui poslednja etiri kao svojevrsnu poslasticu.

Poslednja napomena: eleli bismo da ujemo i va glas
Predavae i studente elimo da podstaknemo u pravljenju novih Java apleta koji bi ilustrovali
koncepte i protokole predstavljene u ovoj knjizi. Ukoliko imate aplet za koji mislite da bi bio
zgodan za ovaj tekst, molimo vas da ga poaljete autorima. One aplete (zajedno sa notacijom i
terminologijom) koji su zaista podesni veoma rado emo postaviti na prateu veb lokaciju za
ovu knjigu, zajedno sa odgovarajuim preporukama njihovih autora. Takoe elimo da
podstaknemo predavae da nam poalju nove probleme (i reenja) za domae zadatke koje
emo objaviti u segmentu veb lokacije koji je namenjen predavaima.
Konano, i studenti i predavai mogu da nam se obrate putem elektronske pote i poalju
svoje komentare o ovoj knjizi. Izuzetno su nas obradovale reakcije iz svih delova sveta koje su
pratile prvo izdanje ove knjige. Takoe moete da nam poaljete i zanimljive URL-ove,
ukaete na tipografske greke, moete da se suprotstavite bilo kojoj naoj tvrdnji i kaete nam
ta, prema vaem miljenju, funkcionie, a ta ne. Vai komentari i sugestije e nam svakako
pomoi u izboru tema za sledee izdanje ove nae knjige. Svu elektronsku potu moete da
nam poaljete na adrese kurose@cs.umass.edu i ross@poly.edu.

7

Sadraj
Poglavlje 1 Raunarske mree i Internet 1
I.l Staje Internet?
1.1.1 Osnovne komponente Interneta 2
1.1.2 Opis iz aspekta usluga 5
1.1.3 Staje protokol? 6 1 .2 Periferija mree

1.2.1 Krajnji sistemi - klijenti i serveri 9
1.2.2 Usluge sa konekcijom i bez nje ] 1
1.3 Jezgro mreel4
1.3.1 Komutiranje vodova i komutiranje paketa 14
1.3.2 Mree sa komutiranjem paketa: mree sa datagramima i mree sa virtuelnim
kolima 21
1.4 Pristup mrei i fiziki medjjumi
1.4.1 Pristupne mree 25
1.4.2 Fiziki medijumi 3!

1.5 Posrednici za Internet usluge i okosnice Interneta 34
1.6 Kanjenje i gubitak paketa u mreama sa komutiranjem paketa 37

1.6.1 Tipovi kanjenja 37
1.6.2 Kanjenje usled stajanja u redu i gubljenje paketa 40
1.6.3 Kanjenja i rute na Internetu 43
1.7 Slojevi protokola i njihovi modeli usluga
1.7.1 Slojevita arhitektura 45
1.7.2 Slojevi, poruke, segmenti, datagrami i okviri 50
1.8 Istorijski pregled umreavanja i Interneta
1.8.1 Razvoj komutiranja paketa: 1961 - 1972 52
1.8.2 Specijalne mree i meusobno povezivanje mrea: 1972 - 1980 53
1.8.3 Veliki porast broja mrea: 1980- 1990 56
1.8.4 Eksplozija Interneta: poslednja decenija prolog veka 56
1.8.5 Aktuelni trendovi 58
1.9 Rezime 59
Mapa knjige 60
Domai zadatak: problemi i pitanja 61
Problemi 62

XI V Sa dr a j
Sa dr a j 8

Teze za diskusiju 68
Ethereal laboratorijska vebanja 69
Intervju: Leonard Klajnrok 71

Poglavlje 2 Aplikativni sloj 73
2.1 Principi rada mrenih aplikacija 74
2.1.1 Arhitektura mrenih aplikacija 75
2.1.2 Komunikacija procesa 78
2.1.3 Protokoli aplikativnog sloja 81
2.1.4 Koje su usluge potrebne aplikaciji? 82
2.1.5 Usluge koje obezbeduju Internet transportni protokoli 84
2.1.6 Mrene aplikacije o kojima emo govoriti u ovoj knjizi 87
2.2 Web i HTTP 87
2.2.2 Nepostojane i postojane veze 90
2.2.3 Format HTTP poruke 93
2.2.4 Interakcija izmeu korisnika i servera: kolaii 98
2.2.5 HTTP sadraj 100
2.2.6 Web keiranje 101
2.2.7 Uslovno preuzimanje 105

2.3 Transfer datoteka: protokol FTP 106
2.4 Elektronska pota na Internetu 109

2.4.2 Poredenje sa protokolom HTTP 115
2.4.3 Formati elektronske pote i MIME 115
2.4.4 Protokoli za prijem elektronske pote 118
2.5 DNS - Internetova usluga direktorijuma 123
2.5.1 Usluge koje obezbeduje DNS 123
2.5.2 Prikaz naina rada usluge DNS 126
2.5.3 DNS zapisi i poruke 132

2.6 P2P razmena datoteka 136
2.7 Programiranje soketa za protokol TCP 146

2.7.1 Programiranje soketa za protokol TCP 147
2.7.2 Primer klijentsko-serverske aplikacije u Javi 149

2.8 Programiranje soketa za protokol UDP 156
2.9 Pravljenje jednostavnog veb servera 164
2.9.1 Funkcije veb servera 164
2.10 Rezime 169
Problemi 171
Zadaci sa programiranjem soketa 178
Ethereal laboratorijske vebe 180
Intervju: Tim Bemers-Li 181
Poglavlje 3 Transportni sloj 183
3.1 Usluge transportnog sloja
3.1.1 Odnos izmeu transportnog i mrenog sloja 184
3.1.2 Kratak pregled transportnog sloja u Internetu 187

3.2 Mulripleksiranje i demultipleksiranje 189
3.3 Prenos bez uspostavljanja konekcije: UDP 196

3.3.1 Struktura UDP segmenta 199:
3.3.2 UDP kontrolni zbir 200
3.4 Principi pouzdanog transfera podataka
3.4.1 Pravljenje protokola za pouzdan transfer podataka 203;
3.4.2 Cevovodni pouzdani protokoli za transfer podataka 214
3.4.3 GBN 217.
3.4.4 Selektivno ponavljanje 221
3.5 Transport sa konekcijom: TCP
3.5.1 TCP konekcija 228
3.5.2 Struktura TCP segmenta 231
3.5.3 Procena vremena povratnog puta i tajm-aut 236
3.5.4 Pouzdani transfer podataka239 3.5.6 Upravljanje TCP konekcijom
249
3.6 Principi kontrole zaguenja
3.6.1 Uzroci i posledice zaguenja 254
3.6.2 Pristupi kontroli zaguenja 260
3.6.3 Primer kontrole zaguenja pomou mree:
Kontrola zaguenja ATM ABR 261
3.7 TCP kontrola zaguenja264 3.7.2 Modeliranje TCP kanjenja
275
3.8 Rezime284 Domai zadatak: problemi i pitanja
285 Problemi
287 Teze za diskusiju
294 Programerski zadatak
295 Laboratorija Ethereal: Istraite TCP
295
Intervju: Sali Flojd 297

Poglavlje 4 Mreni sloj 299
4.1 Uvod 300
4.1.1 Prosleivanje i rutiranje 301
4.1.2 Modeli mrene usluge 304
4.2 Mree sa virtualnim kolima i sa datagramima
4.2.1 Mree sa virtuelnim kolima 307
4.2.2 Mree sa datagramima 310

xvi Sadraj
Sadraj 9

4.1.3 Poreklo usluga datagrama i virtualnog kola 313
4.3 ta ima u ruteru?
4.3.1 Ulazni portovi 315
4.3.2 Komutatorska mrea 318
4.3.3 Izlazni portovi 320
4.3.4 Gde dolazi do ekanja u redu? 320
4.4 Internet protokol (IP): Prosledivanje i adresiranje na Internetu
4.4.1 Format datagrama 325
4.4.2 IPv4 adresiranje 331
4.4.3 ICMP: Internet Control Message Protocol 342
4.5 Algoritmi rutiranja
4.5.1 Algoritam rutiranja prema stanju linkova 354
4.5.2 Algoritam rutiranja sa vektorom rastojanja 358
4.6 Rutiranje na Internetu
4.6.1 Unutranji protokoli rutiranja autonomnih
sistema na Internetu: R1P 371
4.6.2 Unutranji protokoli rutiranja autonomnih sistema
na Internetu: OSPF 374
4.6.3 Rutiranje medu autonomnim sistemima: BGP 378
4.7 Difuzno i vieznano rutiranje
4.7.1 Algoritmi difuznog rutiranja 385
4.7.2 Vieznano upuivanje 391
4.8 Rezime 400
Problemi 404
Programerski zadatak 412
Laboratorija Ethereal 413
Intervju: Vinion G. Cerf 414

Poglavlje 5 Sloj veze podataka i lokalne mree raunara 417
5.1 Sloj veze podataka: uvod i usluge 419
5.1.1 Usluge koje obezbeuje sloj veze 419
5.1.2 Komuniciranje adaptera 422
5.2 Tehnike za otkrivanje i ispravljanje greaka
5.2.1 Provere parnosli 425
5.2.2 Metode kontrolnog zbira ' 427
5.2.3 Ciklina provera redundantnosti (CRC) 428
5.3 Protokoli viestrukog pristupa
5.3.1 Protokoli sa deljenjem kanala 433
5.3.2 Protokoli sa sluajnim pristupom 435
5.3.4 Protokoli tipa na koga je red" 442
5.3.5 Lokalne raunarske mree (LAN-ovi) 443
5.4 Adresiranje sloja linka
5.4.1 MAC adrese 445
5.4.2 Protokol razreavanja adresa (ARP)447 . 5.4.3 Protokol za dinamiko
konfigurisanje glavnog raunara 451
5.5 Ethernet
5.5.1 Struktura Ethemetovog okvira 455
5.5.2 CSMA/CD: Ethemetov protokol sa viestrukim pristupom 460
5.5.3 Ethernet tehnologije 453
5.6 Meusobne veze: liabovi i komutatori
5.6.1 Habovi 455
5.6.2 Komutatori sloja linka 457
5.7 PPP: protokol od take to take
5.7.1 PPP uokvirivanje podataka 479
5.7.2 PPP protokol kontrole linka (LCP) i protokoli kontrole mree 480
5.8 Vizuelizacija Jinka: mrea kao sloj veze482 5.8-1 Asinhroni reim prenosa (ATM)
483 5.8.2 Vieprotokolna komutacija na osnovu oznaka (MPLS)
488
5.9 Rezime49J Domai zadatak: problemi i pitanja
493 Problemi
498 Ethereal Lab
499
Intervju: Simon S. Lam 500

Poglavlje 6 Beine i mobilne mree 503
6.1 Uvod 504
6.2 Beini linkovj i mrene karakteristike508 6.2.1 CDMA
509
6.3 Wi-Fi: Beini LAN-ovi tipa 802.11 513
6.3.1 Arhitektura 802.11 514
6.3.2 MAC protokol 802. II 517
6.3.4 Mobilnost unutar iste IP podmree 526
6.3.5 802.15 i Bluetooth 528
6.4 Celularni pristup Internetu 529
6.4.1 Opti pregled celularne arhitekture 531
6.4.2 Celularni standardi i tehnologije: kratak pregled 532
6.5 Upravljanje mobilnou: principi536 6.5.) Adresiranje
533 6.5.2 Rutiranje prema mobilnom voru 540
6.6 Mobilni IP 546

xviii Sadraj
Sadraj 10

6.7 Upravljanje mobilnocu u celularnim mreama
6.7.1 Rutiranje poziva prema mobilnom korisniku 552
6.7.2 Predavanje u GSM-u 553

6.8 Beine mree i mobilnost: posledice po protokole viih nivoa 556
6.9 Rezime559 Domai zadatak: problemi i pitanja
559 Problemi
562 Laboratorija Ethereal
562
Intervju: arli Perkins 563

Poglavlje 7 Multimedijsko umreavanje 565
7.1 Multimedijske aplikacije umreavanja 566
7.1.1 Primeri multimedijskih aplikacija 566
7.1.2 Prepreke za multimedije na dananjem Internetu 569
7.1.3 Kako bi Internet trebalo da se razvija da bi bolje
podrao multimedije?
7.1.4 Kompresija zvuka i videa 572
7.2 Protok memorisanog zvunog signala i video signala u
realnom vremenu 574
7.2.1 Pristupanje zvuku i videu kroz veb server 576
7.2.2 Slanje multimedija iz servera za protok signala u
realnom vremenu ka pomonoj aplikaciji 578
7.2.3 Protokol za protok signala u realnom vremenu
(Real-Time Streaming Protocol, RTSP) 580
7.3 Najbolja od najbolje mogue usluge: primer Internet telefona
7.3.1 Ogranienja najbolje mogue usluge 585
7.3.2 Uklanjanje treperenja kod primaoca zvuka 587
7.3.3 Oporavljanje od gubitaka paketa 590
7.3.4 Protok memorisanog zvunog signala i video signala u
realnom vremenu
7.4 Protokoli za interaktivne aplikacije u realnom vremenu
7.4.1 RTP 594
7.4.2 RTP kontrolni protokol (RTCP) 599
7.4.3 SIP 602
7.4.4 H.323 608

7.5 Distribuiranje multimediju ma: mree za distribuciju sadraja 610
7.6 Dalje od najbolje mogueg614 7.6.1 Scenario 1: Zvuna aplikacija od 1 Mb/s i FTP
prenos 615
7.6.2 Scenario 2: Zvuna aplikacija od I Mb/s i FTP prenos
visokog prioriteta 616
7.6.3 Scenario 3: Zvuna aplikacija koja se loe ponaa i
FTP prenos 617
7.6.4 Scenario 4: Dve zvune aplikacije od 1 Mb/s preko
preoptereenog linka od 1,5 Mb/s 619
7.7 Mehanizmi za rasporeivanje i upravljanje
7.7.1 Mehanizmi rasporeivanja ' 621
7.7.2 Upravljanje: uplja kofa 625
7.8 Integrisane usluge
7.8.1 Intserv 62$
7.8.2 Diferencirane usluge 631
7.9.1 Ponaanja po skoku 634
7.9 RSVP
7.9.1 Sutina RSVP-a 637
7.5.1 Nekoliko jednostavnih primera 639
7.10 Rezime 643
Domai zadatak: problemi i pitanja 64^4
Problemi 645
Programerski zadatak 649
Intervju: Hening ulcrine 651

Poglavlje 8 Bezbednost u raunarskim mreama 653
8.1 ta je bezbednost mree 654
8.2 Principi kriptografije 657

8.2.1 Kriptografija simetrinog kljua 658
8.2.2 ifrovanje javnim kljuem " 664
8.3 Autentifikacija
8.3.1 Autentifikacioni protokol apl.O 670
8.3.2 Autentifikacioni protokol ap2.0 671
8.4 Integritet 678
8.4.1 Stvaranje digitalnih potpisa 678
8.4.2 Izvodi poruka 679
8.4.3 Algoritmi he funkcija 681

11 Sadraj

8.5 Distribucija i overavanje kljueva
8.5.1 Centar za distribuciju kljueva 686
8.5.2 Overa javnog kljua 687
8.6 Kontrola pristupa: mrene barijere
8.6.1 Filtriranje paketa 692
8.6.2 Aplikacioni mreni prolaz 695
8.7 Napadi i kontramere
8.7.1 Preslikavanje 697
8.7.2 Uhoenje paketa 698
8.7.3 Varanje 699
8.7.4 Napadi odbijanja usluge i distribuiranog odbijanja usluge 700
8.7.5 Pljakanje 701
8.8 Bezbednost u mnogo slojeva: studije primera
8.8.1 Bezbedna elektronska pota 703
8.8.2 Sloj bezbednih soketa (SSL) i bezbednost transportnog
sloja (TLS)
8.8.3 Bezbednost mrenog sloja: IPsec 712
8.8.4 Bezbednost u IEEE 802.11 716
8.9 Rezime 721
Problemi 723
Intervju: Stiven M. Belovin 651

Poglavlje 9 Upravljanje mreom 729
9.1 Sta je upravljanje mreom? 730
9.2 Infrastruktura za upravljanje mreom 734
9.3 Standardni upravljaki radni okvir za Internet 738

9.3.1 Komponenta SMI 740
9.3.2 Upravljaka informaciona baza: MIB 743
9.3.3 Funkcionisanje protokola SNMP i transportna preslikavanja 745
9.3.4 Bezbednost i administracija 749

9.4 ASN.l 753
9.5 Zakljuak757 Domai zadatak: problemi i pitanja
758 Problemi
760
Intervju: Jeff Case
Reference 763
Indeks 797
Umreavanje raunara
Od vrha ka dnu sa
Internetom u fokusu
Prevod treeg izdanja

1
Raunarske
mree i
Internet
Sveopta prisutnost raunarskih mrea neprekidno se poveava pronalaenjem novih atraktivnih
aplikacija - priineri su mnogobrojni - itai Weba u mobilnim telefonima, kafei sa javnim
beinim pristupom Internetu, kune mree irokopojasnog pristupa, zatim tradicionalna IT
radna infrastruktura sa umreenim raunarom na svakom stolu svake kancelarije. Umreavaju se
automobili, ali i senzori za praenje stanja ivotne sredine. Konano, Internet sada ve ima
interplanetarm znaaj. Izgleda da su raunarske mree svuda oko nas! Ova knjiga pruie vam
savremeni uvod u veoma dinamino polje umreavanja raunara i ponuditi principe i praktina
znanja koji e vam pomoi da razumete ne samo aktuelne mree, ve i one koje e postojati u
budunosti.
Ovo prvo poglavlje zamiljeno je kao svojevrstan prikaz umreavanja raunara i Interneta.
U njemu smo eleli da iscrtamo konture umreavanja i da ovu pojavu posmatramo uopteno.
Videete da smo u ovom uvodnom poglavlju obradili mnogo tema, neke ak i veoma detaljno, a
da pri tome nismo gubili iz vida optu sliku. Zahvaljujui tome, ovo poglavlje predstavlja
osnovu na koju se nadovezuju sva naredna poglavlja.
Evo kako e izgledati na prikaz raunarskih mrea u ovom prvom poglavlju. Nakon to
vam predstavimo neke osnovne termine i koncepte, ispitaemo osnovne hardverske i softverske
komponente koje ine raunarsku mreu. Poeemo od periferije" raunarske mree i
prikazati vam krajnje sisteme i mrene aplikacije

13 13 13 13 POGLAVLJE 1 RAUNARSKE MREE I INTERNET
1.1 STAJE INTERNET? 3 33 3

koje se izvravaju u okviru mree. Govoriemo takoe o transportnim uslugama koje ove aplikacije
koriste. Nakon toga prei emo na .jezgro" raunarskih mrea i ispitati linkove i komutatore kojima
se podaci prenose, zatim pristup mreama i same fizike medijume koji krajnje sisteme povezuju sa
jezgrom mree. Videete da Internet predstavlja mreu koja objedinjuje mnogo drugih mrea i
nauiti na koji nain su sve te mree povezane.
Nakon prikaza periferije" i Jezgra" raunarskih mrea, zauzeemo poziciju koja e nam
omoguiti sagledavanje neto uoptenije slike. Ispitaemo uzroke kanjenja i gubitka podataka u
raunarskim mreama i ponuditi vam jednostavne kvantitativne modele za odreivanje kanjenja od
jednog do drugog kraja mree. Ovi modeli prilikom izraunavanja u obzir uzimaju kanjenje u
prenosu, putovanju i formiranju redova. Potom emo vam predstaviti i neke kljune principe u
arhitekturi umreavanja raunara kao to su, na primer, slojevitost protokola ili modeli usluga.
Konano, ovo poglavlje emo zavriti kratkim istorijskim prikazom raunarskih mrea.

1.1 St aj e Internet?
U ovoj knjizi kao osnovno sredstvo za razmatranje naina funkcionisanja mrenih protokola
koristimo javni Internet - konkretnu raunarsku mreu. Ali ta je Internet? Zaista bismo eleli da vam
pruimo odgovor u jednoj reenici - definiciju koju biste mogli da koristite u razgovoru sa lanovima
porodice i prijateljima. Naalost, Internet je, u pogledu hardverskih i softverskih komponenti, kao i
usluga koje prua, veoma sloen, tako da jednostavno nije mogue dati toliko kratku definiciju.
1.1.1 Osnovne komponente Interneta
Umesto da pokuamo da definiemo Internet u jednoj reenici, opredelili smo se za neto
deskriptivniji pristup, u kome postoje dva razliita puta. Prvi bi podrazumevao opisivanje onoga to
se nalazi ispod haube" Interneta, a to su osnovne hardverske i softverske komponente od kojih
se on sastoji. Iz druge perspektive, Internet moe da se opie u smislu mrene infrastrukture koja
obezbeuje usluge distribuiranim aplikacijama. Poeemo od prvog opisa i kao ilustraciju upotrebiti
sliku 1.1.
Javni Internet predstavlja svetsku raunarsku mreu koja se sastoji od miliona raunara
rasporeenih irom sveta. Donedavno su veinu ovih ureaja inili tradicionalni stoni PC raunari,
UNIX radne stanice i tzv. serveri koji uvaju i prenose informacije kao to su veb stranice i
elektronska pota. Meutim, osim njih, danas se sa Internetom povezuje i sve vei broj
netradicionalnih krajnjih sistema (ureaja), kao to su PDA {Personal Digital Assisiant) raunari,
televizori, prenosivi raunari, mobilni telefoni, automobili, senzori za praenje stanja ivotne
sredine, okviri za slike, kuni elektronski i bezbednosni sistemi, veb kamere, pa ak i tosteri [BBC
2001]. Stavie, imajui u vidu broj netradicionalnih ureaja koji se danas povezuju sa Internetom,
termin raunarska mrea ve poinje da zvui pomalo arhaino. U intemetskom argonu, svi ovi
ureaji nazivaju se raunari ili krajnji sistemi.
U januaru 2003. godine Internet je koristilo oko 233 miliona krajnjih sistema i taj broj se veoma brzo
poveava [ISC 2004].
Krajnji sistemi su izmeu sebe povezani komunikacionim linkovima. U odeljku 1.4 videete
da postoji veliki broj tipova komunikacionih linkova koji se prave od razliitih fizikih medij uma, kao
to su koaksijalni kablovi, bakarni provodnici, optiki kablovi i spektar radio talasa.

14 POGLAVLJE 1 RAUNARSKE MREE I INTERNET
1. 1 STAJE INTERNET? 5 55 5

Razliiti linkovi imaju i razliitu brzinu prenosa podataka koja se izraava brojem bitova
u sekundi.
Krajnji sistemi obino nisu direktno meusobno povezani jednim komunikacionim linkom.
Ta veza najee je indirektna i vodi preko posrednikih ureaja za komutiranje koji se nazivaju
komutatori paketa. Komutator paketa preuzima odreenu koliinu informacija koje stiu
nekim od ulaznih komunikacionih linkova i prosleuje ih nekim od svojih izlaznih
komunikacionih linkova. U argonu raunarskog umreavanja za ovu odreenu koliinu
informacija" koristi se termin paket. Danas ima mnogo razliitih oblika i modela komutatora
paketa, a najrasprostranjeniji su ruteri i komutatori sloja veze. Zajednika karakteristika obe
ove vrste komutatora jeste to da pakete prosleuju do njihovih konanih odredita. 0 ruterima
emo detaljnije govoriti u poglavlju 4, a o komutatorima sloja veze u poglavlju 5.
Put kojim paket putuje od krajnjeg sistema koji ga je poslao, kroz niz komunikacionih
linkova i rutera, do krajnjeg sistema kome je namenjen, naziva se ruta ili putanja. Umesto da
za komunikaciju krajnjih sistema obezbedi namensku putanju, Internet koristi tehniku
komutiranja paketa, koja omoguava da vei broj krajnjih sistema u isto vreme i zajedniki
koristi celu putanju ili neki njen deo. Prve mree sa komutiranjem paketa koje su se pojavile
1970-ih godina predstavljaju najranije pretke dananjeg Interneta. Taan iznos obima saobraaja
dananjeg Interneta predmet je sporenja [Odvlsko 2003], ali po nekim konzervativnim
procenama meseno kroz amerike meugradske mree proe oko 100 000 terabajta
informacija. Ovome treba dodati i podatak da se obim saobraaja svake godine udvostruava.
Krajnji sistemi pristupaju Internetu preko posrednika za Internet usluge {Internet Service
Provider, ISP) i to mogu biti kuni posrednici, kao to su AOL ili telefonske kompanije i
kablovski operateri, zatim korporativni posrednici, univerzitetski posrednici, kao i posrednici
kakav je, na primer, kompanija T-Mobile koja obezbeduje beini pristup na aerodromima, u
hotelima, kafeima i na drugim javnim mestima. Svaki posrednik za Internet usluge, u stvari,
predstavlja mreu rutera i komunikacionih linkova. Razliiti posrednici obezbeuju krajnjim
korisnicima i razliite naine za pristup mrei, kao to su, primera radi, modemski pristup
brzine 56 Kb/s, rezidencijalni irokopojasni pristup kablovskom ili DSL vezom, zatim LAN
pristup velike brzine ili beini pristup. Ovi posrednici takoe obezbeuju pristup Internetu
onim kompanijama koje obezbeuju sadraje, povezujui veb lokacije direktno sa Internetom.
Da bi omoguili komunikaciju korisnika Interneta i pristup sadrajima irom sveta, ovi
posrednici nieg reda povezani su sa nacionalnim i internacionalnim posrednicima vieg reda,
kao to su AT&T ili Sprint. ISP-ovi vieg reda, u stvari, predstavljaju odreeni broj rutera velike
brzine koji su izmeu sebe povezani takoe veoma brzim optikim kablovima. Svakom ISP
mreom, bez obzira na to da li je vieg ili nieg reda, upravlja se nezavisno i u svakoj se koriste
protokol IP (videti u produetku), kao i odreene konvencije imenovanja i adresiranja. U
odeljku 1.5 detaljnije emo ispitati posrednike za Internet usluge i njihove meusobne veze.
Krajnji sistemi, ruteri, kao i ostali delovi Interneta, koriste protokole koji kon-troliu slanje
i prijem informacija u okviru Interneta. TCP (Transmission Control Protocol) i IP (Internet
Protocol) predstavljaju dva najvanija Internet protokola.
Protokolom IP precizira se format paketa koje razmenjuju ruteri i krajnji sistemi. Glavni Internet
protokoli kolektivno se nazivaju TCP/IP. Ve u ovom uvodnom poglavlju pozabaviemo se
mrenim protokolima, ali to je samo poetak. U nastavku ove knjige emo se veoma esto
vraati ovoj temi.
Imajui u vidu znaaj protokola na Internetu, veoma je vano da postoji opti konsenzus o
tome za Staje svaki od tih protokola zaduen. Upravo zato i postoje standardi. Internet
standarde je razvila Tehnika radna grupa za Internet {Internet Engineering Task Force, IETF)
[IETF 2004]. Dokumenti sa standardima grupe IETF nazivaju se RFC (reguestfor comments,
zahtevi za komentarima) dokumenti. RFC dokumenti pojavili su se kao uopteni zahtevi za
komentarima (otuda i njihov naziv) koji bi omoguili reavanje problema u vezi sa arhitekturom
mree koja je prethodila Internetu. Ovi dokumenti su puni tehnikih pojedinosti, veoma su
detaljni, i defmiu protokole kao to su TCP, IP, HTTP (za Web) i SMTP (za elektronsku
potu). Tehnika radna grupa za Internet takode je standardizovala protokole koji se izvravaju
na matinim raunarima [RFC 1122; RFC 1123] i ruterima [RFC 1812]. Trenutno ima vie od
3500 razliitih RFC dokumenata. Postoje jo neka tela koja se bave standardizacijom mrenih
komponenti, posebno kada su u pitanju mreni linkovi. Primera radi, grupa IEEE 802
LAN/MAN Standards Committee [IEEE 802 2004] bavi se standardizacijom Ethernet i beinih
Wi-Fi standarda.
Javni Internet (dakle, globalna mrea koja povezuje mnogo drugih mrea, kako smo ga
nedavno definisali) jeste mrea za koju ljudi obino vezuju termin Internet. Meutim, ima jo
mnogo drugih privatnih mrea kao to su razne korporativne ili vladine mree, iji raunan ne
mogu da razmenjuju poruke sa raunarima izvan njih (osim ukoliko te poruke ne prou kroz tzv.
mrene barijere koje kontroliu tok poruka ka mrei i iz nje). Budui da se u ovim privatnim
mreama koriste iste vrste raunara, rutera, linkova i protokola kao i u javnom Internetu, za njih
se esto vezuje termin intranet.
1.1.2 Opis i z aspekta usluga
U prethodnom odeljku identilikovali smo mnoge delove od kojih se sastoji Internet. Za trenutak
emo napustiti ovaj pristup i pokuati da ga sagledamo iz perspektive usluga.
Internet omoguava razmenu podataka izmeu distribuiranih aplikacija koje se izvravaju
na krajnjim sistemima. Meu ovim aplikacijama su daljinska prijava, elektronska pota,
krstarenje Webom, trenutna razmena poruka, protok audio i video signala u realnom
vremenu, intemetska telefonija, distribuirane igre, deoba datoteka izmeu ravnopravnih
korisnika (P2P) i mnoge druge. elimo da naglasimo da ,,Web" nije posebna mrea, ve pre
jedna od mnogih distribuiranih aplikacija koje koriste komunikacione usluge koje Internet
obezbeduje.
Internet obezbeduje dve usluge svojim distribuiranim aplikacijama: pouzdanu uslugu sa
konekcijom i nepouzdanu uslugu bez konekcije. Uopteno govorei, pouzdana usluga sa
konekcijom garantuje da e podaci koji se prenose od poiljaoca do primaoca u krajnjoj
liniji biti isporueni primaocu i to u potpunosti. Kod nepouzdanih usluga bez konekcije
nema nikakvih garancija u vezi sa kona-

6 6 6 6 POGLAVLJE 1 RAUNARSKE MREE I INTERNET 1.1 . TA JE INTERNET? 15 15 15 15

nom isporukom. Distribuirane aplikacije obino koriste jednu (nikada obe) od ove dve usluge.
U ovom trenutku Internet ne obezbeduje uslugu kojom bi mogao da garantuje trajanje
putovanja paketa od poiljaoca do primaoca. Izuzev poveanja propusne moi kod vaeg
posrednika za Internet usluge, trenutno ne postoji drugi nain za obezbedivanje boljih usluga
(recimo, u smislu ogranienja kanjenja), ak ni dodatnim plaanjem, to je mnogim ljudima
(naroito Amerikancima) prilino udno. Ipak, u poglavlju 7 emo vam prikazati vrhunsko
istraivanje o Internetu koje bi moglo da promeni ovu situaciju.
Ovaj drugi nain definisanja Interneta - u smislu usluga koje obezbeduje distribuiranim
aplikacijama - nije uobiajen, ali je veoma vaan. Napredak sastavnih deSova Interneta u sve veoj
meri proistie iz potreba novih aplikacija. Stoga je veoma vano imati u vidu daje Internet
svojevrsna infrastruktura u kojoj se nove aplikacije neprekidno pronalaze i putaju u rad.
Upravo smo vam ponudili dve mogue definicije Interneta - jednu iz aspekta hardverskih i
softverskih komponenti i drugu, iz aspekta usluga koje Internet prua distribuiranim aplikacijama.
Ipak, sasvim je mogue da se jo uvek pitate ta Internet, u stvari, predstavlja. ta su komutiranje
paketa, TCP/IP i usluge sa konekcijom? ta su ruteri? Koje vrste komunikacionih linkova postoje u
ovoj mrei? ta je distribuirana aplikacija? Ukoliko jo nemate odgovore na ova pitanja, ne brinite.
Cilj ove knjige jeste da vam predstavi i sastavne delove Interneta i principe koji njime upravljaju. U
poglavljima koja slede, objasniemo vam sve ove vane termine i dati odgovore na pitanja koja vas
moda jo uvek mue.

1.1.3 Staje protokol?
Sada, kada ste stekli makar osnovnu predstavu o tome ta je Internet, razmotriemo jo jednu
veoma vanu re u oblasti umreavanja raunara - protokol. Staje protokol? ta on radi? Kako biste
ga prepoznali kada biste se suoili sa njim?

Analogija sa ljudima
Verovatno najjednostavniji nain za objanjenje pojma mrenog protokola jeste razmatranje nekih
analogija sa ljudima, budui da kod nas uvek postoje nekakvi protokoli. Zamislite situaciju u kojoj
nekoga treba da pitate koliko je sati. Uobiajena razmena rei prikazana je na slici 1.2.
Ljudski protokol (ili makar, dobri maniri) nalae da se komunikacija sa drugom osobom
zapone pozdravom (prvo Zdravo"). Tipian odgovor bi takode glasio Zdravo", s tim to bi ova
poruka imala srdaan prizvuk, stoje znak da prva osoba moe da nastavi i postavi pitanje. Drugaiji
odgovor na inicijalno Zdravo" (recimo, Ostavi me na miru!" ili Ne govorim srpski!", ili moda
neto nepristojno) ukazivao bi na to da druga osoba ne eli ili ne moe da odgovori na
komunikaciju. U tom
sluaju, u skladu sa ljudskim protokolom, prva osoba ne bi upitala koliko je sati. Deava se da na
svoj pozdrav prva osoba ne dobije nikakav odgovor i u tom sluaju ona takode ne nastavlja sa
svojim drugim pitanjem. Skreemo vam panju na to da u ljudskom protokolu postoje konkretne
poruke koje aljemo i konkretne akcije koje su odgovor na primljene poruke Hi druge dogaaje
(kao to je ignohsanje). Jasno je da poslate i primljene poruke, kao i akcije koje se preduzimaju
nakon slanja i prijema tih poruka imaju kljunu ulogu u ljudskom protokolu. Ukoliko ljudi imaju
razliite protokole (na primer, jedna osoba ima dobre manire, a druga ne, ili jedna razume pojam
vremena, a druga ne), njihova interakcija nije mogua, to znai da se ne moe postii nita korisno.
Isti principi vae i u umreavanju - za postizanje bilo ega i izvravanje bilo kakvog zadatka potrebno
je da dva (ili vie) ureaja u meusobnoj komunikaciji koriste isti protokol.
Razmotrimo sada drugu analogiju sa ljudima. Pretpostavimo, primera radi, da se nalazite u
jednoj studijskoj grupi (to moe da bude i kurs o umreavanju!) i da predava na veoma nezanimljiv
nain govori o umreavanju. Nakon zavretka svog predavanja, on postavlja uobiajeno pitanje:
Ima li nekih pitanja?" (poslatu poruku

8 8 8 8 POGLAVLJE 1 RAUNARSKE MREE l INTERNET 1.2 PERIFERIJA MREE 9 99 9

primaju svi studenti koji nisu zaspali). Vi diete ruku (aljui implicitnu poruku predavau), on se
nasmei, izgovarajui: Da..." (poruka koja vas ohrabruje da postavite pitanje), vi postavljate
pitanje (aljete svoju novu poruku) i, konano, on slua vae pitanje (prima poruku) i odgovara na
njega (alje vam svoj odgovor). I iz ovog primera moete da zakljuite da kljuni segment protokola
pitanja i odgovora predstavljaju prenos i prijem poruka, ukljuujui i sve one akcije koje se
preduzimaju nakon prijema ili slanja poruka.

Mreni protokoli
Mreni protokol je veoma slian primeru sa ljudima, osim to su entiteti koji razmenjuju poruke i
preduzimaju akcije u ovom sluaju hardverske i softverske komponente nekog ureaja (recimo,
raunara, rutera ili nekog drugog ureaja koji moe da se umrei). Svakom aktivnou na Internetu
koja podrazumeva komunikaciju dva ili vie udaljenih entiteta upravlja protokol. Na primer, protokoli
u ruterima odreuju putanju paketa od njegovog izvora pa do njegovog odredita; hardverski
implementirani protokoli u mrenim interfejsima dva fiziki povezana raunara kontroliu tok bitova
kroz icu" izmeu ova dva interfejsa; protokoli za kontrolu zaguenja saobraaja u krajnjim
sistemima kontroliu brzinu prenosa paketa izmeu poiljaoca i primaoca. Internet je prepun
protokola i upravo zato je dobar deo ove knjige i posveen protokolima raunarskih mrea.
Kao primer protokola koji vam je verovatno poznat, zamislite ta se deava kada poaljete
zahtev veb serveru, odnosno, kada u svoj ita upiete URL neke veb strane. Ova situacija opisana
je u desnoj polovini slike 1.2. Dakle, va raunar naj-pre alje zahtev za povezivanje" veb serveru
i zatim eka njegov odgovor. Server u krajnjoj liniji prima ovaj zahtev i odgovara porukom daje
povezivanje mogue. Znajui da moe da zatrai dokument, va raunar zatim u poruci tipa GET"
alje ime veb stranice koju eli da preuzme sa veb servera. Na kraju, veb server alje traenu
stranicu vaem raunaru.
Imajui u vidu i primer sa ljudima i primer iz prave mree, kljuni elementi koje definie svaki
protokol jesu razmena poruka i akcije koje se preduzimaju nakon slanja ili prijema ovih poruka:
Protokol definie format i redosled poruka koje se razmenjuju izmeu dva ili vie
komunicirajui/! entiteta, kao i akcije koje se preduzimaju nakon slanja ili prijema poruke
ili nekog drugog dogaaja.
U okviru Interneta, ali i svih drugih raunarskih mrea, protokoli se koriste u znaajnoj meri i to
za postizanje razliitih zadataka u sferi komunikacije. itajui' ovu knjigu saznaete da postoje
sasvim jednostavni, ali i veoma sloeni protokoli. Ovladavanje oblau umreavanja raunara
praktino bi moglo da se poistoveti sa razumevanjem svih aspekata mrenih protokola.
1.2 Periferija mree
U prethodnim odeljcima predstavili smo vam Internet i mrene protokole na uop-teniji nain, a sada
sledi detaljniji prikaz komponenti raunarske mree (i posebno Interneta). Poeemo od periferije
mree i od onih komponenti koje su nam svima najpoznatije, a to su raunari koje svakodnevno
koristimo. Nakon toga emo od periferije mree da se uputimo ka njenom centru i objasnimo
pojmove komutiranja i rutiranja u raunarskim mreama. Konano, u odeljku 1.4 pozabaviemo se i
samim fizikim linkovima koji prenose signale izmeu raunara i komutatora.
1.2.1 Krajnji sistemi - klijenti i serveri
U terminologiji umreavanja, za raunare koji su povezani sa Internetom esto se koristi i termin
krajnji sistemi. Oni se smatraju krajnjim sistemima zato to se nalaze na samom obodu Interneta
(slika 1.3). Kategorija krajnjih sistema Interneta obuhvata nekoliko razliitih tipova raunara. Krajnji
korisnici nalaze se u neposrednom kontaktu sa ovim raunarima u koje spadaju stoni (PC, Mac ili
UNIX radne stanice) i prenosivi raunari (laptop i PDA raunari i telefoni sa beinim pristupom
Internetu). Pored toga, sve je vei broj alternativnih ureaja poput jednostavnih klijenata i ureaja za
domainstvo [Thinplanet 2002], veb televizora, ureaja koji se povezuju sa televizorima [Nesbitt
2002], digitalnih kamera, ureaja za domainstvo, fabrikih postrojenja ili senzora za praenje stanja
ivotne sredine, koji se kao krajnji sistemi povezuju sa Internetom (obavezno proitajte i istorijski
osvrt koji sledi).
Za krajnje sisteme koristi se termin matini raunari, ili domaini (engl. hosts), zato to se na
njima izvravaju aplikacije kao to su programi za itanje vebova, , itai elektronske pote,
programi za prosledivanje elektronske pote i veb serveri. U nastavku ove knjige emo ravnopravno
koristiti tennine (matini) raunar i krajnji sistem, to znai da im je znaenje identino. Matini
raunari se esto dalje dele na kategorije klijenata i servera. Uopteno govorei, klijenti su stoni,
laptop i PDA raunari, dok su serveri neto monije maine koje se koriste za skladitenje i
distribuiranje veb strana, protok video materijala u realnom vremenu, prosledivanje elektronske
pote i slino.
U kontekstu mrenog softvera postoji jo jedna definicija klijenta i servera na koju emo se
pozivati u ovoj knjizi. Klijentski program se izvrava najednom krajnjem sistemu koji zahteva i
dobija usluge od serverskog programa koji se izvrava na drugom krajnjem sistemu. Ovakav
klijentsko/serverski model (koji emo detaljno ispitati u poglavlju 2) nesumnjivo predstavlja
najrasprostranjeniju strukturu kada su u pitanju aplikacije za Internet. Web, elektronska pota,
transfer datoteka, daljinsko prijavljivanje (na primer, Telnet), elektronske konferencije..., samo su
neki od primera aplikacija u kojima je primenjen model klijent/server. S obzirom na to da se klijentski
program po pravilu izvrava najednom raunaru, a serverski na drugom, klijentsko/serverske Internet
aplikacije su, po definiciji, distribuirane. Klijentski i serverski program ostvaruju interakciju
uzajamnim slanjem poruka putem Interneta. Na ovom nivou apstrakcije, ruteri, linkovi i ostali
delii" Interneta imaju ulogu crne kutije" za prenos poruka izmeu distribuiranih komponenti
intemetskih

10 10 10 10 POGLAVLJE 1 RAUNARSKE MREE I I I I INTERNET 1.2 PERIFERIJA MREE 17 17 17 17

aplikacija, koje su u meusobnoj komunikaciji. Upravo ovaj nivo apstrakcije moete uoiti na slici 1.3.
Meutim, nemaju sve savremene Internet aplikacije iste klijentske programe koji ostvaruju
interakciju sa istim serverskim programom. Primera radi, kod aplikacija za razmenu datoteka u
mreama ravnopravnih raunara (kao Stoje KaZaA) aplikacija na oba krajnja sistema ponaa se i kao
klijentski i kao serverski program. Kada zahtevaju podatke sa drugog raunara ovi programi se
ponaaju kao klijenti, a kada ib alju drugom raunam onda imaju ulogu servera. U Internet telefoniji
dve komunicirajue strane su takoe ravnopravne; drugim recima, ovde se ne dogaa da jedna strana
zahteva neku uslugu od druge. U poglavlju 2 ove knjige nalazi se detaljno poreenje
klijentsko-serverske i P2P arhitekture.
NEVEROVATAN SPEKTAR KRAJNJIH SISTEMA NEVEROVATAN SPEKTAR KRAJNJIH SISTEMA NEVEROVATAN SPEKTAR KRAJNJIH SISTEMA NEVEROVATAN SPEKTAR KRAJNJIH SISTEMA
Ne tako davno, jedini krajnji sistemi koji su se povezivali sa Internetom bili su tradicionalni sloni
raunari i moni serveri. Meutim, krajem 1990-ih poeo je trend povezivanja najrazliilijih
ureaja sa ovom globalnom mreom. Za sve ove ureaje zajednika je potreba razmene digitalnih
informacija sa nekim drugim ureajima. Kada se uzmu u obzir sveopto prisutnost Interneta,
zatim njegovi dobro definisani (i standardizovani) protokoli, kao i pristupanost ureaja koji se
sa njim povezuju, sasvim je prirodno to to se ova mrea koristi za povezivanje svih pomenutih
ureaja. Za neke od ovih ureaja mogli bismo da kaemo da su napravljeni iskljuivo radi
zabave. Tako, na primer, stoni ram za sliku koji podrava protokol IP [Ceivo 2004] preuzima
digitalne fotografije sa udaljenog servera i prikazuje ih kao da su uramljene na klasian nain;
Interne! toster preuzima meteoroloke podatke sa servera i odgovarajuu sliku dnevne vremenske
prognoze (recimo, sliku promenljivog oblanog i sunanog vremena) vam prikazuje na ispeenom
paretu hleba [BBC 2001 ]. Ipak, postoje i ureaji koji mogu do nam obezbede korisne
informacije - veb kamere na monitoru ili neem drugom prikazuju aktuelne saobraajne i
vremenske uslove; razvijene su ok i moine za pranje vesa koje su povezane sa Internetom. Rad
ovakvih maina moe da se prati preko itaa Weba, a one same generiu elektronsku poIu
kojom obavetavaju korisnike o zavretku svog rada. Mobilni telefoni sa ugraenim protokolom
IP doneli su novu dimenziju pretraivanja VVeba, elektronske pote i trenutne razmene poruka.
Nova klaso umreenih senzorskih sislema donosi revoluciju u nainu praenja ivotne sredine.
Ovi umreeni senzori koji su ugroeni u fizike objekte omoguavaju praenje zgrada, mostova i
ostalih objekata koje su ljudi napravili [Elgamal 2001], alim praenje seizmike aktivnosti [CISN
2004], ivog sveta na Zemlji [Moimvaring 2002], esluora reka [Baptista 2003], biomedicinskih
funkcija [Schwiebert 2001], vetrova i meteorolokih opasnosti u donjim slojevima atmosfere
[ASA 2004]. Sve prikupljene informacije dostupne su odmah svim zainteresovanim udaljenim
korisnicima. Cilj centra CENS [Center for Embedded Nehvorked Sensing) pri Univerzitetu UCLA
upravo je primena tehnologije umreenih, ugraenih senzora, u vanim naunim i drutvenim
oblastima.
1.2.2 Usluge sa konekcijom i bez nje
Krajnji sistemi svoju meusobnu komunikaciju ostvaruju preko Interneta. Konkretno, programi na
krajnjim sistemima koriste usluge Interneta za meusobno slanje poruka. Linkovi, ruteri i ostali
sastavni delovi Interneta obezbeuju sredstva za transport ovih poruka izmeu programa na
krajnjim sistemima. Meutim, koje su karakteristike komunikacionih usluga koje Internet prua
svojim krajnjim sistemima?
TCP/IP mree, a to znai i Internet, obezbeuju dve vrste usluga aplikacijama krajnjih sistema:
usl uge sa konekcijom i usl uge bez konekci je. Programer koji

1.2 PERIFERIJA MREE 13 13 13 13

pravi aplikaciju za Internet (recimo, aplikaciju za elektronsku potu, aplikaciju za transfer
datoteka, aplikaciju za Web ili za Internet telefoniju) mora da je napravi tako da koristi jednu od
ove dve usluge. U nastavku emo ukratko da vam opiemo svaku od njih. (Vie informacija o
ovim uslugama pronai ete u poglavlju 3 u kome emo se baviti protokolima transportnog
sloja.)

Usluga sa konekcijom
Kada neka aplikacija koristi uslugu sa konekcijom, klijentski i serverski programi (koji se
nalaze na razliitim krajnjim sistemima), pre slanja samih podataka (recimo, elektronske pote),
najpre jedan drugom alju kontrolne pakete. Ovaj postupak sin-hronizacije upozorava klijenta i
servera da treba da se pripreme za slanje paketa. Nakon zavretka procedure sinhronizacije kae
se daje izmeu dva krajnja sistema uspostavljena konekcija.
Zanimljivo je daje ova procedura inicijalne sinhronizacije veoma slina protokolu koji ljudi
koriste u svojim odnosima. Razmena poruka Zdravo" sa slilê 1.2 predstavlja primer ljudskog
protokola sinhronizacije - rukovanja" (mada izmeu dva oveka ne mora da doe i do samog
ira rukovanja). U vebovskoj interakciji, koja je takoe prikazana na slici 1.2, prve dve
razmenjene poruke takoe su poruke sinhronizacije. Dve naknadne poruke - poruka GET i
poruka sa odgovorom u kojoj se nalazi i datoteka - smatraju se samim podacima i alju se tek
nakon uspostavljanja konekcije.
Moda se pitate zbog ega se kae usluga sa konekcijom", a ne usluga konekcije". Ova
terminoloka razlika proistie iz injenice da su dva krajnja sistema u stvari povezana veoma
labavo. Konkretno, jedino sami krajnji sistemi znaju za postojanje ove konekcije - komutatori
paketa (ruteri) na Internetu nemaju pojma o njenom postojanju. tavie, konekcija preko
Interneta nije nita vie od dodeljene privremene memorije i promenljivih stanja na krajnjim
sistemima. Posredniki komutatori paketa ne odravaju nikakve informacije u vezi sa stanjem
konekcije.
Usluga sa konekcijom obino dolazi u paketu sa nekoliko drugih usluga, kao to su
pouzdani transfer podataka, kontrola toka podataka i kontrola zaguenja. Pod pouzdanim
transferom podataka podrazumeva se to da aplikacija, u smislu isporuke svih podataka bez
greaka i njihovog pravilnog redosleda, moe da se osloni na konekciju. Pouzdanost se na
Internetu postie korienjem potvrda i ponovnih pre-nosa. Da biste stekli najosnovniju
predstavu o nainu na koji Internet implementira pouzdanu transportnu uslugu, zamislite
aplikaciju koja je uspostavila vezu izmeu krajnjih sistema A i B.
Kada krajnji sistem B primi paket od sistema A, on mu alje poruku kojom to i potvruje.
Zahvaljujui toj poruci, krajnji sistem A zna daje odgovarajui paket definitivno primljen.
Ukoliko sistem A ne primi poruku o potvrdi, on pretpostavlja da krajnji sistem B nije primio
poslati paket, pa ga zato alje ponovo. Kontrolom toka izbegava se da jedna strana preoptereti
onu drugu prebrzim slanjem prevelikog broja paketa. U poglavlju 3 ete videti da se Internet
usluga za kontrolu toka imple-
mentira korienjem privremene memorije za slanje i prijem na krajnjim sistemima.
Usluga za kontrolu zaguenja Interneta pomae u spreavanju da ova mrea dospe u
stanje potpunog zastoja. Kada na nekom ruteru doe do zaguenja, mogua su pre-
koraenja njegove privremene memorije i gubitak paketa. Kada bi u ovakvim okolnostima
svaki par krajnjih sistema nastavio da upumpava" podatke u mreu najbre to moe,
dolo bi do zastoja i samo mali broj paketa bi zaista dospeo do svog odredita. Na
Internetu se ovaj problem izbegava tako to se krajnji sistemi prinuuju na smanjivanje
brzine emitovanja paketa u periodima zaguenja. Onog trenutka kada prestanu da
primaju potvrde o prispeu paketa koje su poslali, krajnji sistemi postaju svesni
postojanja ozbiljnijeg zaguenja.
Ovde elimo da naglasimo da, iako usluge sa konekcijom dolaze u paketu sa
pouzdanim transferom podataka, kontrolom toka i kontrolom zaguenja, ove tri
komponente ni u kom sluaju ne bi mogle da se nazovu osnovnim komponentama ove
vrste usluga. Postoje raunarske mree koje svojim aplikacijama obezbeuju usluge sa
konekcijom bez ijedne od ovih komponenti. S druge strane, svaki protokol koji pre
prenosa podataka sinhronizuje entitete koji komuniciraju, pripada uslugama sa
konekcijom.
lntemetska usluga sa konekcijom ima svoje ime: TCP (Transmission Control Protocof).
Osnovna verzija protokola TCP definisana je dokumentom RFC 793 [RFC 793]. U usluge
koje protokol TCP obezbeduje aplikacijama spadaju apstrakcija toka podataka, pouzdani
transport, kontrola toka i kontrola zaguenja. Veoma je vano naglasiti da aplikacija treba
da brine samo o obezbedenim uslugama; za nju uopste nije bitno na koji nain protokol
TCP implementira pouzdanost, kontrolu toka ili kontrolu zaguenja. Naravno, za nas su
ova pitanja vana, tako da emo vam u poglavlju 3 pruiti detaljne odgovore na njih.

Usluga bez konekcije
Kod usluge bez konekcije ne postoji procedura sinhronizacije (rukovanja). U ovom
sluaju, kada jedna strana aplikacije eli da poalje pakete drugoj strani, program za
slanje paketa to jednostavno i uini. S obzirom na to da ovde prenosu podataka ne
prethodi procedura sinhronizacije, isporuka podataka je neto bra. S druge strane, ovde
ne postoji ni pouzdani transfer podataka, tako da poiljalac nikada ne moe da bude
siguran koji su paketi zaista stigli do svog odredita. tavie, u internetskoj usluzi bez
konekcije nema mesta ni za kontrolu toka ni za kontrolu zaguenja: Inter-netska usluga
bez konekcije naziva se UDP (User Datagram Protocot), a definisana je dokumentom RFC
768.
Najvei deo popularnih aplikacija za Internet koristi uslugu sa konekcijom (TCP).
Meu ovim aplikacijama su Tebet (za daljinsko prijavljivanje), SMTP (za elektronsku
potu), FTP (za transfer datoteka) i HTTP (za Web). Meutim, i uslugu bez konekcije
(UDP) koristi sasvim solidan broj aplikacija, naroito neke novije multimedijalne
aplikacije kao to su, na primer, internetska telefonija i video konferencije.

1 4 POGLAVLJE 1 RAUNARSKE MREE 1 INTERNET
1.3 JEZGRO MREE 1 9

1.3 Jezgro mree
Poto smo ispitali krajnje sisteme Interneta i njihov transportni model usluga, u nastavku teksta prei
emo na unutranjost" ove mree. U ovom odeljku naa tema bie samo jezgro ove mree,
odnosno mrea rutera koji povezuju krajnje sisteme. Na slici i .4 jezgro mree je prikazano
korienjem debljih zelenih linija.

1.3.1 Komutiranje vodova i komutiranje paketa
U formiranju mrenog jezgra postoje dva osnovna pristupa i to su komutiranje vodova i komutiranje
paketa.
U mreama sa komutiranjem vodova, neophodni resursi koji obezbeuju komunikaciju izmeu
dva krajnja sistema (privremena memorija, propusna mo linka) na celoj duini putanje paketa
ostaju rezervisani sve vreme trajanja komunikacione sesije. U mreama sa komutiranjem paketa,
pomenuti resursi nisu rezervisani ve ih poruke tokom sesije koriste na zahtev, i zato poneka
moraju da ekaju (stanu u red) na pristup komunikacionom linku. Kao jednostavnu analogiju
zamislite sada dva restorana - jedan u kome su rezervacije neophodne i drugi u kome se one ne
prihvataju. U restoranu u kome su rezervacije neophodne imamo jedino taj zahtev: da se najavimo
pre nego to krenemo. Ali kada doemo u restoran, praktino istog trenutka moemo da
komuniciramo sa konobarom i poruimo obrok. U restoranu koji ne prihvata rezervacije ne moramo
prethodno da se najavljujemo i rezervierno sto. Ali kada stignemo u restoran, najpre emo morali
da saekamo na red za sto i tek potom moemo da komuniciramo sa konobarom.
Opteprisutne telefonske mree predstavljaju primere mrea sa komutiranjem vodova.
Zamislite situaciju u kojoj jedna osoba telefonskom mreom eli da poalje informaciju (glasovnu ili
faksimil) drugoj osobi. Da bi poiljalac mogao da poalje svoje informacije, telefonska mrea najpre
mora da uspostavi vezu izmeu poiljaoca i primaoca. Nasuprot TCP vezi o kojoj smo priali u
prethodnom odeljku, ovo je bona jide veza u kojoj komutatori na putanji izmeu poiljaoca i
primaoca odravaju njen status povezanosti. U argonu telefonije ovakva veza naziva se vod (kolo).
Kada uspostavi vod, mrea za daru vezu rezervie i konstantnu brzinu pre-nosa tokom celog njenog
trajanja. S obzirom na to da ova veza izmeu poiljaoca i primaoca ima rezervisanu propusnu mo,
poiljalac moe da prenosi podatke garan-tovanom konstantnom brzinom.
Dananji Internet u osnovi predstavlja mreu sa komutiranjem paketa. Zamislite sada situaciju
u kojoj jedan raunar eli da poalje paket nekom drugom raunaru preko Interneta. Kao i kod
mrea sa komutiranjem vodova, dati paket treba da proe kroz seriju komunikacionih linkova. Ali u
mreama sa komutiranjem paketa, dati paket alje se kroz mreu bez ikakve rezervacije propusne
moi. Ukoliko je neki od linkova zaguen zato to njime u tom trenutku ve prolaze drugi paketi, na
paket e morati da saeka u privremenoj memoriji na predajnom kraju prenosnog linka, a to znai
daje kanjenje neizbeno. Internet daje sve od sebe" kako bi se obezbedila pravovremena
isporuka paketa, ali ne postoje nikakve garancije u tom pogledu.
Konano, ne mogu sve telekomunikacione mree da se uklope u ovu podelu na mree sa
komutiranjem vodova i mree sa komutiranjem paketa. Meutim, ovakva osnovna klasifikacija
predstavlja odlinu polaznu taku za razumevanje tehnologije telekomunikacionih mrea.

Komutiranje vodova
Ova knjiga je posveena raunarskim mreama, Internetu i komutiranju paketa, a ne telefonskim
mreama i komutiranju vodova. Ipak, veoma je vano da razumete zato Internet i ostale
raunarske mree koriste komutiranje paketa, a ne postojeu

20 20 20 20 POGLAVLJE 1 RAUNARSKE MREE 1 INTERNET
1.3 JEZGRO MREE 17 17 17 17

tehnologiju komutiranja vodova koja je prisutna u telefonskim mreama. Upravo zato sledi kratak
prikaz tehnologije komutiranja vodova.
Na slici 1.5 prikazana je mrea sa komutiranjem vodova. U ovoj mrei etiri komutatora vodova
meusobno su povezana putem etiri linka. Svaki od ovih linkova ima n vodova, to znai da svaki
link moe da podri n simultanih veza. Svi raunari (PC-ji i radne stanice) direktno su povezani sa
jednim od komutatora. Kada dva raunara ele da komuniciraju, mrea izmeu njih uspostavlja
namensku vezu sa kraja na kraj. (Konferencijski pozivi izmeu vie od dva ureaja takoe su
mogui, ali emo, da bi sve bilo to jednostavnije, pretpostaviti da u svakoj vezi postoje samo po dva
raunara.) Prema tome, da bi raunar A mogao da poalje poruke raunani B, mrea najpre mora da
rezervie jedan vod na svakom od dva linka. S obzirom na to da svaki link ima n vodova, za svaki
upotrebljeni link ova veza sa kraja na kraj dobija l/n ukupne propusne moi linka i to tokom itavog
trajanja veze.
Multipleksiranje u mreama sa komutiranjem vodova
U okviru linka, vod se realizuje ili frekventnim multipleksiranjem (Frequency-Division Multiplexing,
FDM) ili vremenskim multipleksiranjem (Time-Division Multiplexing, TDM). U FDM tehnologiji, sve
veze koje su uspostavljene du linka dele njegov frekventni spektar. Konkretno, link dodeljuje
odreeni frekventni opseg svakoj vezi tokom itavog njenog trajanja. U telefonskim mreama ovaj
frekventni opseg obino ima irinu od 4 kHz (4 000 herca ili 4 000 ciklusa u sekundi). irina ovog
opsega se, nimalo iznenaujue, naziva propusni opseg (propusna mo). FM radio stanice takoe
koriste tehnologiju FDM kako bi zajedniki mogle da koriste raspoloivi frekventni spektar izmeu 88
i 108 MHz.
1
U TDM linkovima, vreme je podeljeno na okvire fiksne duine, a svaki od njih podeljen je na
fiksni broj vremenskih odseaka. Kada mrea uspostavi vezu du odreenog linka, toj vezi se
namenjuje po jedan vremenski odseak u svakom okviru. Ovi vremenski odseci su namenski -
moe da ih koristi samo data veza, a svaki od njih (u svakom okviru) moe da prenosi podatke.
Na slici 1.6 ilustrovane su tehnologije FDM i i i i TDM na konkretnom mrenom linku koji podrava
do etiri voda. U FDM pristupu, frekventni spektar podeljen je na etiri opsega od kojih svaki ima
propusni opseg od po 4 kHz. U verziji TDM, vremenski spektar podeljen je na okvire sa po etiri
slota u svakom od njih; svakom vodu dodeljuje se isti namenski vremenski odseak u rotirajuim
TDM okvirima. U ovom sluaju, brzina prenosa voda jednaka je brzini prenosa okvira podeljenoj sa
brojem bitova u odseku. Na primer, ukoliko link prenosi 8 000 okvira u sekundi, a svaki vremenski
odseak ini osam bitova, brzina prenosa voda tada iznosi 64 kb/s.
Pristalice komutiranja paketa uvek su tvrdile da komutiranje vodova predstavlja rasipnitvo zato
to su namenski vodovi u stanju mirovanja tokom tihih perioda. Na primer, kada jedna osoba u
telefonskom razgovoru prestane da pria, druga aktvina veza ne moe da upotrebi mrene resurse
koji tada prelaze u stanje mirovanja (frekventne opsege ili vremenske odseke u linkovima du
putanje veze). Drugi primer neiskorienosti resursa bio bi, recimo, radiolog koji putem mree sa
komutiranjem vodova dolazi do serije rendgenskih snimaka. Dakle, on uspostavlja vezu, zahteva
snimak koji zatim analizira, i na kraju zahteva novi snimak. Tokom perioda analiziranja snimaka
mreni resursi su potpuno neiskorieni. Zagovornici komutiranja paketa takoe sa neskrivenim
zadovoljstvom istiu da su uspostavljanje vodova od kraja do kraja i rezervisanje propusnog opsega
komplikovani i za njih je neophodan sloen softver za signalizaciju koji treba da koordinira radom
komutatora du ovakve putanje.
Pre nego to zavrimo razmatranje komutiranja vodova, naveemo ijedan numeriki primer
koji e vam dodamo ilustrovati razlike izmeu navedenih tehnologija. Dakle, pogledajmo koliko je
vremena potrebno za slanje datoteke od 6 400 00 bitova od raunara A do raunara B kroz mreu
sa komutiranjem vodova. Pretpostavimo da svi linkovi u mrei koriste tehnologiju TDM i i i i da imaju
brzinu od 1,536 Mb/s. Takoe emo pretpostaviti daje za uspostavljanje voda od kraja do kraja
potrebno 500 ms, nakon ega raunar A poinje emitovanje podataka. Koliko
Ovo koriste i AM stanice i lo mnogo oiglednije, npr. TV. Generalno, FDM u ovom kontekstu je AM! (prim. rec.)

21 21 21 21 POGLAVLJE 1 RAUNARSKE MREE I INTERNET 1.3 JEZGRO MREE 19 19 19 19

Slika 1.6 Slika 1.6 Slika 1.6 Slika 1.6 U tehnologiji FDM svaki vod stalno ima na raspolaganju deo ukupne propusne
moi. U tehnologiji TDM svaki vod periodino, tokom kratkih vremenskih
intervala (odseaka), dobija celokupnu propusnu mo.
je vremena potrebno da datoteka stigne do svog odredita? Svaki vod ima brzinu prenosa od
(1,536 Mb/s)/24 = 64 kb/s, to znai da je za prenos datoteke potrebno (640 000 bitova)/(64
kbps) = 10 sekundi. Kada ovome dodamo i vreme potrebno za uspostavljanje veze, dobijamo 1
0.5 sekundi. Skreemo vam panju na to da vreme prenosa ne zavisi od broja linkova - prenos
traje 10 sekundi bez obzira na to da li vod prolazi kroz jedan ili sto linkova. (Stvarno kanjenje u
vezama od kraja do kraja zavisi od kanjenja usled propagacije; proitajte odeljak 1.6.)
Komutiranje paketa
U odeljku 1.1 videli ste da aplikacije svoje zadatke obavljaju razmenom poruka. U porukama
moe da se nalazi sve to je dizajner protokola zamislio. One mogu imati kontrolnu funkciju
(poruke Zdravo" iz primera o sinhronizaciji) ili mogu da sadre podatke - na primer,
elektronsku potu, JPEG sliku ili MP3 muziku datoteku. U savremenim raunarskim mreama
poiljalac dugake poruke razbija na manje skupine podataka koje se nazivaju paketi. Svaki od
ovih paketa, od svog izvora pa do svog odredita, treba da proe kroz komunikacione linkove i
komutatore paketa (ili kroz rutere, ili kroz komutatore sloja veze). Paketi se kroz svaki
komunikacioni link prenose brzinom koja je jednaka njegovoj punoj brzini prenosa. Najvei broj
komutatora paketa koristi prenos tipa memorisanje i prosleivanje. Pod ovim se podrazumeva
da komutator poinje da prenosi prvi bit nekog paketa kroz svoj
izlazni link tek kada primi itav taj paket. Stoga kod komutatora sa memorisanjem i
prosleivanjem postoji izvesno kanjenje na svakom ulaznom linku i to na itavoj putanji datog
paketa. Ovo kanjenje je proporcionalno duini paketa u bitovima. Konkretno, kada bi se paket
sastojao od L bitova i kada bi trebalo da se poalje izlaznim linkom brzine R bitova u sekundi,
kanjenje memorisanja i prosleivanja komutatora iznosilo bi L/R sekundi.
Svaki ruter je povezan sa veim brojem linkova. Za svaki od svojih linkova ruter ima
izlaznu privremenu memoriju (naziva se i izlazni red ekanja) u koju se smetaju paketi koje
ruter tek treba da poalje kroz dati link. Upravo ova izlazna privremena memorija ima kljunu
ulogu u komutiranju paketa. Ukoliko je link kroz koji neki paket treba da se poalje trenutno
zauzet, pristigli paket mora da saeka u izlaznoj privremenoj memoriji. Zbog toga, osim
kanjenja usled memorisanja i prosleivanja, pakete pogaa i kanjenje usled ekanja u redu.
Ova kanjenja variraju i zavise od nivoa zaguenosti mree. Budui daje koliina prostora u
privremenoj memoriji konana, pristigli paket moe da se suoi i sa situacijom daje ova memo-
rija ve popunjena drugim paketima koji ekaju u redu za prenos. U tom sluaju dolazi do
gubljenja paketa - isputa se ili upravo pristigli paket ili jedan od onih koji su ve u redu. Ako se
za trenutak vratimo analogiji sa restoranom, ekanje u redu moglo bi da se poistoveti sa
vremenom koje provedete ekajui da se neki sto oslobodi, dok bi gubljenje paketa bilo
jednako obavetenju da morate da odete zato to previe ljudi ve eka na oslobaanje nekog od
stolova.
Na slici 1.7 prikazana je jednostavna mrea sa komutiranjem paketa. Na ovoj, kao i na
sledeim slikama, paketi su predstavljeni trodimenzionalnim ploicama. irina ploica
predstavlja duinu paketa. Na ovoj slici sve ploice imaju jednaku irinu, to znai da su svi
paketi jednake duine. Pretpostavimo da raunari A i B alju pakete raunaru E. Ovi paketi
najpre putuju Ethernet linkovima brzine 10 Mb/s, a zatim ih komutator preusmerava na link ija
je brzina 1,5 Mb/s. Ukoliko se dogodi daje brzina kojom paketi pristiu vea od one kojom
komutator moe da ih prosledi kroz izlazni link brzine 1,5 Mb/s, paketi e, pre slanja kroz ovaj
link, morati da stoje u redu u njegovoj izlaznoj privremenoj memoriji.
Pogledajmo sada koliko je vremena potrebno za slanje paketa od L bitova od jednog do
drugog raunara, kroz mreu sa komutiranjem paketa. Pretpostavimo da izmeu njih postoji Q
mrea od kojih svaka ima brzinu od R bitova u sekundi. Pre-ipostaviemo i da su kanjenja
usled stajanja u redu, propagacije s kraja na kraj i uspostavljanja veze neznatna. Dakle, paket se,
nakon izlaska iz raunara A, najpre prenosi kroz prvi link i za to je potrebno L/R sekundi. Nakon
toga, paket mora da proe i kroz svaki od preostalih Q-\ linkova; odnosno, on mora da se
memorie i prosledi Q- \ puta. Prema tome, ukupno kanjenje iznosi QL/R.

Poreenje komutiranja paketa i komutiranja vodova: statistiko multipleksiranje
Sada kada smo vam opisali i komutiranje vodova i komutiranje paketa, uporediemo ove dve
tehnologije. Protivnici komutiranja paketa uvek su tvrdili da ono, zbog svog

1.3 JEZGRO MREE 2 }

nepredvidivog i promenljivog kanjenja izmeu krajnjih taaka (usled nepredvidivog i
promenljivog trajanja ekanja u redu), nije podesno za usluge u realnom vremenu (na primer,
za telefonske pozive i video konferencije). S druge strane, zagovornici komutiranja paketa tvrde
da ova tehnika (1) obezbeduje bolju eobu propusne moi i daje (2) jednostavnija, efikasnija i
jeftinija za implementiranje od komutiranja vodova. Veoma zanimljivo poreenje komutiranja
paketa i komutiranja vodova moete pronai kod autora [Molinero-Femandez], Uopteno
govorei, ljudi koji ne vole da razmiljaju o rezervacijama u restoranu prednost daju
komutiranju paketa.
Zastoje komutiranje paketa efikasnije? Evo jednostavnog primera. Pretpostavimo da
korisnici zajedniki koriste link od 1 Mb/s i da svaki korisnik ima period vee aktivnosti u kome
generie 100 kb/s i period mirovanja u kome ne generie nikakve podatke. Pretpostavimo, dalje,
daje svaki korisnik aktivan oko 10 procenata vremena (ostalih 90 procenata pije kafu i ne
generie nikakav saobraaj). Kod komutiranja vodova 100 kb/s mora da bude rezervisano za
svakog korisnika i to sve vreme. Ukoliko bi, primera radi, u tehnologiji TDM komutiranja
vodova okvir od 1 sekunda bio podeljen na 10 vremenskih odseaka od po 100 ms, svakom
korisniku bi tada bio dodeljen jedan vremenski odseak po okviru.
To znai da link u jednom trenutku moe da podri samo 10 ( = 1 Mb/s/100 kb/s)
korisnika. Kod komutiranja paketa verovatnoa da je odreeni korisnik aktivan iznosi 0,1 (ili 10
procenata). Kada bi u mrei bilo 35 korisnika, verovatnoa da njih 11 ili vie u istom trenutku
budu aktivni iznosi 0,0004. (U domaem zadatku 8 videete na koji nain smo dobili ovaj
rezultat.) Kada je istovremeno aktivno 10 ili manje korisnika (verovatnoa je 0,9996) prosena
brzina prenosa jednaka je ukupnoj propusnoj moi od 1 Mb/s, ili je neto manja od nje. Prema
tome, kada je u
mrei aktivno 10 ili manje korisnika, njihovi paketi se kroz link kreu praktino bez ikakvog
kanjenja, kao stoje sluaj u komutiranju vodova. U situacijama kada je istovremeno aktivno 10
ili vie korisnika, prosean broj prispelih paketa prevazilazi izlazni kapacitet linka i red na izlazu
poinje da raste. (On raste sve dok prosena ulazna brzina ne padne ispod 1 Mb/s, kada izlazni
red poinje da se smanjuje.) Imajui u vidu to daje u ovom primeru verovatnoa da vie od 10
korisnika bude istovremeno aktivno izuzetno mala, komutiranje paketa obezbeduje praktino
jednake performanse kao i komutiranje vodova, ali za tri puta vei broj korisnika.
Preimo sada na drugi jednostavan primer. Pretpostavimo da jedan od nekih deset korisnika
iznenada generie hiljadu paketa od po 1 000 bitova, a da ostalih devet miruje i ne generie
nikakav saobraaj. Kod TDM komutiranja vodova sa 10 slotova od po 1 000 bitova po svakom
okviru, aktivni korisnik moe da koristi za prenos podataka samo jedan (svoj) vremenski
odseak u okviru; preostalih devet vremenskih odseaka bie neiskorieno. Za prenos jednog
miliona korisnikovih bitova bie potrebno 10 sekundi. Kod komutiranja paketa aktivni korisnik
moe kontinuirano da alje svoje podatke kroz link koristei njegovu punu brzinu od I MB/s, s
obzirom na to da nijedan drugi korisnik ne alje pakete koje bi trebalo mul-tipleksirati sa
paketima aktivnog korisnika. U ovom sluaju svi korisnikovi podaci bili bi preneti za jedan
sekund.
Prethodnim primerima pokuali smo da vam ilustrujemo dve situacije u kojima su
performanse komutiranja paketa superiorne u odnosu na performanse komutiranja vodova.
Istovremeno, ovim primerima istakli smo i najznaajniju razliku izmeu ova dva naina deljenja
propusne moi linka. Kod komutiranja vodova unapred se rezervie deo propusne moi linka,
to znai da onaj deo koji nije rezervisan ostaje neiskorien. Nasuprot tome, kod komutiranja
paketa link se koristi na zahtev. Pre-nosni kapacitet linka, u smislu paket po paket" dele samo
oni korisnici koji imaju pakete za prenos kroz link. Ovakva deoba resursa na zahtev (nasuprot
dodeljivanju unapred) nekada se naziva i statistiko multipleksiranje resursa.
Iako u dananjim telekomunikacionim mreama postoji i komutiranje vodova i komutiranje
paketa, trend se ipak sve vie okree ka komutiranju paketa. Mnoge telefonske mree sa
komutiranjem vodova lagano prelaze na komutiranje paketa. Konkretno, mnoge telefonske
kompanije esto koriste komutiranje paketa za skupe prekomorske telefonske veze.

1.3.2 Mree sa komutiranjem paketa: mree sa
datagramima i mree sa virtuelnim kolima
Postoje dve vrste mrea sa komutiranjem paketa - mree sa datagramima i mree sa virtuelnim
kolima. Ove dve vrste mrea razlikuju se po tome da li njihovi komutatori za prosledivanje
paketa do njihovog odredita koriste odredine adrese ili tzv. brojeve virtuelnih kola. Sve mree
u kojima se za prosledivanje paketa koriste adrese odredinih raunara svrstaemo u kategoriju
mrea sa datagramima. Ruteri prosleuju pakete upravo na ovaj nain - dakle, Internet je
mrea sa datagramima.

23 23 23 23 POGLAVLJE 1 RAUNARSKE MREE I I I I INTERNET
1.3 JEZGRO MREE 23 23 23 23

S druge strane, sve mree u kojima se za prosleivanje paketa koriste brojevi vir-tuelnih kola
nazivamo mreama sa virtuelnim kolima. U tehnologije komutiranja paketa u kojima se
koriste virtuelna kola spadaju X-25, Frame Relay i ATM {Asynchronous Transfer Mode). Iako
je razlika izmeu mrea u kojima se koriste odredine adrese i onih u kojima se koriste brojevi
virtuelnih kola na prvi pogled gotovo beznaajna, od izbora jednog od ova dva standarda zavisi
nain podeavanja i administrirani a rutera.
Mree sa virtuelnim kolima
Kao to iz samog imena moete da zakljuite, virtuelno kolo (VC) predstavlja vir-tuelnu
konekciju izmeu izvornog i odredinog raunara. Meutim, uspostavljanje i odravanje
virtuelnog kola podrazumeva i odgovarajue podeavanje apsolutno svakog rutera na putanji
izmeu ova dva raunara. Identifikator virtuelnog kola (VC ID) dodeljuje se virtuelnom kolu
prilikom inicijalnog uspostavljanja veze izmeu izvora i odredita. Svaki paket koji je deo
virtuelnog kola u svom zaglavlju mora imati VC ID broj. Svaki komutator paketa poseduje
tabelu u kojoj su VC 1D brojevi povezani sa odgovarajuim izlaznim linkovima. Kada neki
paket stigne do komutatora paketa, komutator ispituje njegov VC ID broj, indeksira svoju
tabelu i prosle-duje dati paket ka odgovarajuem izlaznom linku. Skreemo vam panju na to
da se izvor i odredite virtuelnog kola samo indirektno identifiktiju putem VC ID broja; za
izvoenje komutiranja nisu neophodne stvarne adrese izvornog i odredinog krajnjeg sistema.
To znai da komutiranje paketa moe da se izvede brzo (kontrolom VC ID broja pristiglog
paketa u maloj tabeli za VC prevoenje, umesto da se odredina adresa trai u potencijalno
velikoj tabeli sa adresama).
Ukoliko se u nekoj mrei koriste virtuelna kola, njeni komutatori moraju da odravaju
informacije o stanju aktivnih veza. Konkretno, kad god se u nekom komu-tatoru uspostavi
nova veza, dodaje se novi zapis njegovoj tabeli prevoenja VC brojeva; svako prekidanje veze
povlaci brisanje odgovarajueg zapisa iz ove labelc. Skreemo vam panju i na to daje
neophodno evidentirati informacije o stanju koje povezuju VC brojeve sa brojevima izlaznih
imerfejsa. ak i kada ne postoji nikakvo prevoenje VC ID brojeva. Evidentiranje informacija
o stanju u komutatori ma paketa predstavlja kljuni aspekt ove tehnologije i na njega emo se
ubrzo vratili.
Mree sa datagramima
Mree sa datagramima po mnogo emu podseaju na potansku slubu. Kada poiljalac eli da
poalje pismo na odreenu adresu, on ga najpre stavlja u kovertu na kojoj pie adresu
primaoca. Ova odredina adresa ima hijerarhijsku strukturu. Pri-mera radi, na pismima koja se
alju u Sjedinjene Amerike Drave potrebno je napisati naziv zemlje (SAD), drave (recimo,
Pensilvanija), grada (recimo, Filadelfija), ulice (Volnat Strit) i broja kue u daloj ulici (na
primer, 421). Potanska sluba koristi adresu na koverti za usmeravanje pisma ka njegovom
odreditu. Na primer, ukoliko se pismo alje iz Francuske, onda e potanska sluba ove zemlje
najpre da ga prosledi do potanskog centra u SAD, koji e, dalje, da ga prosledi potanskom
centru u
Filadelfiji, da bi ga potar koji radi u ovom gradu na kraju doneo do njegovog konanog
odredita.
U mreama sa datagramima, svaki paket koji putuje kroz mreu sadri adresu svog
odredita u svom zaglavlju. Kao i kod potanske slube, ova adresa ima hijerarhijsku strukturu.
Kada do njega stigne odreeni paket, komutator paketa ispituje deo njegove odredine adrese i
prosleuje ga susednom komutatoru. Konkretno, svaki komutator paketa ima tabelu
prosledivanja u kojoj se odredina adresa (ili njeni delovi) preslikava u neki izlazni link. Kada
paket dospe do komutatora, ovaj odmah ispituje njegovu adresu i u svojoj tabeli pokuava da
pronae odgovarajui izlazni link, kojim ga i usmerava dalje.
Proces rutiranja s kraja na kraj mogao bi da se uporedi i sa vozaem koji ne koristi
auto-mape, ve vie voli da lino pita za put. Na primer, pretpostaviemo da Do iz Filaelfije
treba da stigne do adrese I56Lejksajd Drajv u Orlandu na Floridi. Dakle, Do se najpre dovezao
do benzinske pumpe i pitao kako da stigne do navedene adrese. Radnik na pumpi je iz cele
adrese izvukao deo Florida i uputio naeg Doa na autoput 1-95 Jug, u koji moe da se ukljui
odmah pored pumpe. Takoe mu je rekao da im stigne do drave Floride odmah od nekoga
zatrai pomo. Do se vozio putem 1-95 Jug sve dok nije stigao do Deksonvila u Floridi gde je
ponovo svratio do benzinske pumpe i zainiio pomo. Radnik na pumpi je iz cele adrese izvukao
segment Orlando i rekao Dou da nastavi putem 1-95 Jug sve do Dejtona Bia i da tamo ponovo
potrai pomo. U Dejtona Biu se ovek na sledeoj pumpi ponovo vezao za segment Orlando i
uputio Doa na put 1-4 koji vodi direktno u Orlando. Do se vozio ovim putem sve dok nije
stigao do ulaska u Orlando. Na ulasku u Orlando Do je ponovo stao na pumpi i zamolio za
pomo. Radnik na ovoj pumpi je iz cele adrese izvukao ulicu Lejksajd Drajv i objasnio Dou
kako da stigne do nje. Konano, kada je pronaao ovu ulicu, Do je upitao jednog deka na
biciklu gde je broj 156. Ovaj deko je iz cele adrese izvukao broj 156 i pokazao Dou gde se
nalazi njegovo konano odredite.
U nastavku ove knjige, veoma detaljno emo razmatrati prosleivanje paketa u mreama sa
datagramima. Na ovom mestu emo rei samo to da se, nasuprot VC mreama, u rulerima mrea
sa datagramima ne odravaju informacije o stanju veze. tavie, u istoj mrei sa datagramima,
komutator paketa je potpuno nesvestan saobraaja koji prolazi kroz njega. Komutator paketa
donosi sve odluke o prosleivanju na osnovu odredine adrese paketa, a ne na osnovu veze kojoj
dati paket pripada. S obzirom na to da je u VC mreama neophodno odravati informacije o
stanju veze - informacije koje moraju da se instaliraju i uklanjaju zajedno sa svakim novim
virtuelnim kolom i sreuju (briu) u sluaju njegovog prisilnog kraja, ove mree zahtevaju
postojanje relativno sloenih protokola za odravanje stanja, koji nisu neophodni u mreama sa
datagramima.
Da li biste eleli da vidite putanju s kraja na kraj paketa na Internetu? Sada emo da vas
pozovemo da malo zasuete rukave" i poigrate se sa programom Tra-ceroute koji ete nai na
veb lokaciji http://www.traceroule.org. (Obavezno proitajte i odeljak 1.6 koji je posveen ovom
alatu.)

24 24 24 24 POGLAVLJE 1 RAUNARSKE MREE l INTERNET 1.4 PRISTUP MREI I FIZIKI MEDIJUMI 2^ 2^ 2^ 2^

Taksonomija mree
Do sada smo vam predstavili nekoliko veoma vanih koncepata umreavanja kao to su
komutiranje vodova, komutiranje paketa, virtuelna kola, usluge bez konekcije i usluge sa
konekcijom. Pogledajmo sada kako se svi ti koncepti uklapaju u jednu celinu.
Najpre, u naem pojednostavljenom primeru, u telekomunikacionoj mrei pri-menjuje se ili
komutiranje vodova ili komutiranje paketa (slika 1.8). Zatim, na linku mree sa komutiranjem
vodova koristi se ili tehnologija FDM ili tehnologija TDM. Mree sa komutiranjem paketa su ili
mree sa virtuelnim kolima ili mree sa datagramima. Komutatori u mreama sa virtuelnim
kolima prosleduju pakete u skladu sa VC brojevima paketa i odravaju informacije o stanju
veze. Komutatori u mreama sa datagramima prosleduju pakete u skladu sa njihovim odredinim
adresama i ne odravaju informacije o stanju veze.

1.4 Pristup mrei i fiziki medij umi
U odeljcima 1.2 i 1.3 ispitali smo uloge krajnjih sistema i rutera u raunarskim mreama, a u
odeljku koji sledi baviemo se mrenim pristupom - odnosno, fizikim vezama koje povezuju
jedan krajnji sistem sa njegovim perifernim ruterom, to je, u stvari, prvi ruter na putanji izmeu
dva udaljena krajnja sistema. Pristupna mrea, dakle, obezbeduje infrastrukturu za povezivanje
potroaa sa mrenom infrastrukturom.
Na slici 1.9 prikazano je nekoliko tipova pristupnih linkova koji povezuju krajnji sistem sa
perifernim ruterom; ove veze iscrtane su debljim linijama. S obzirom na to da je tehnologija
mrenog pristupa tesno povezana sa tehnologijama fizikih medijuma (optiki i koaksijalni
kablovi, telefonski kablovi sa upredenim paricama ili spektar radio talasa), u ovom odeljku emo
se baviti i jednom i drugom temom.
1.4.1 Pristupne mree
Naini pristupa raunarskim mreama uopteno govorei mogu da se podele na tri sledee
kategorije:
pristup od kue - koji povezuje kune krajnje sisteme u zajedniku mreu;-
poslovni pristup - koji povezuje krajnje sisteme u poslovnim i obrazovnim institucijama u
zajedniku mreu;
beini pristup - koji povezuje mobilne krajnje sisteme u zajedniku mreu.
Ove kategorije, meutim, ne treba shvatiti previe striktno. Krajnji sistemi nekih
kompanija, primera radi, mogu da koriste tehnologiju pristupa koju smo pripisati kunom
pristupu, i obratno. U tom smislu, opisi koji slede odnose se na najuobiajenije situacije.

25 25 25 25 POGLAVLJE 1 RAUNARSKE MREE l INTERNET 1.4 PRISTUP MREI I FIZIKI MEDUUMI 27 27 27 27

Pristup od kue
Pod pristupom od kue podrazumeva se povezivanje kunog krajnjeg sistema (najee PC
raunara, ali i Web TV-a, pa ak i nekog drugog ureaja) sa perifernim ruterom. Za pristup od
kue najee se koriste standardni modem i obina analogna telefonska finija preko kojih se
povezujemo sa posrednikom za kune Internet usluge (kao to je, na primer, America Online).
Modemi slue za pretvaranje digitalnih signala iz raunara u analogni format, koji je podesan za
prenos telefonskim linijama. U pomenutim analognim telefonskim linijama koriste se bakarni
provodnici sa upredenim paricama i to su iste one linije koje koristimo i za obine telefonske
razgovore. (O kablovima sa upredenim paricama govoriemo u nastavku ovog odeljka.) Na
drugoj strani analogne telefonske linije, modem posrednika za Internet usluge ove analogne
signale vraa u digitalni format podesan za prosledivanje ruteru. Prema tome, pristup mrei u
ovom sluaju ini par modema na modemskoj telefonskoj liniji tipa od take do take. Dananji
modemi omoguavaju brzine prenosa do 56 kb/s, ali je, zbog loeg stanja linija izmeu kunog
sistema i posrednika za Internet usluge, stvarna brzina prenosa esto daleko manja.
Za mnoge korisnike koji pristupaju od kue, modemski pristup brzine 56 kb/s je previe
spor. Primera radi, za preuzimanje jedne trominutne pesme u MP3 formatu potrebno je oko
osam minuta. Pored toga, modemski pristup blokira telefonsku liniju korisnika - dok ovu liniju
koristi za krstarenje VVebom, korisnik ne moe da koristi telefon. Sreom, nove tehnologije za
irokopojasni pristup donele su kunim korisnicima vee brzine prenosa, uz istovremeno
oslobaanje telefonske linije. Za irokopojasni pristup od kue obino se koriste dve tehnologije
- digitalna pretplatnika linija (DSL) [DSL 2004] i hibridni optiko-koaksijalni kabl (HFC)
[Cable Labs 2004].
Do 2003. godine, irokopojasni pristup od kue bio je mnogo manje zastupljen od
standardnog modemskog (56 kb/s) pristupa. Procentualni udeo domainstava sa irokopojasnim
pristupom Internetu tada je iznosio 23% u Junoj Koreji, 13% u Kanadi i 7% u SAD, dok je u
Evropi bilo oko 10 procenata takvih domainstava [Point Topic 2003]. Meutim tehnologije
DSL i HFC veoma brzo osvajaju svet - u SAD dominira tehnologija HFC, a u Evropi i Aziji
DSL.
DSL pristup obino obezbeuju telefonske kompanije (na primer, Verizon ili France
Telecom), nekada i u saradnji sa nekim nezavisnim posrednikom za Internet usluge, lako je
konceptualno slian standardnim modemima, DSL predstavlja novu modemsku tehnologiju koja
i dalje koristi standardne telefonske linije sa upredenim bakarnim paricama. Meutim, ovde se
postiu daleko vee brzine prenosa, ograniavanjem udaljenosti izmeu korisnikovog i
ISP-ovog modema. Brzina prenosa obino je asimetrina - neto bra od ISP-ovog rutera do
korisnika nego u obrnutom smeru. Ova asimetrija brzine prenosa utemeljena je na koncepciji
daje kuni korisnik pre konzument nego proizvoa informacija (zato je vea brzina na putu
informacija ka njemu). U teoriji, tehnologija DSL moe da obezbedi brzine do 10 Mb/s od ISP-a
do korisnika, i neto vie od 1 Mb/s u obrnutom smeru. Meutim, u praksi su te brzine ipak
znaajno manje. Godine 2004, uobiajene brzine prenosa kretale su se izmeu 1 i 2 Mb/s ka
korisniku, i nekoliko stotina kb/s ka posredniku za Internet usluge.
Tehnologija DSL koristi frekventno multipleksiranje koje smo opisali u prethodnom
odeljku. Konkretno, ovde se komunikacioni link izmeu ISP-a i domova deli na tri
nepreklapajua frekventna opsega:
veoma brzi kanal ka korisniku u opsegu od 50 kHz do 1 MHz;
srednje brzi kanal ka ISP-u u opsegu od 4 kHz do 50 kHz i
standardni dvosmerni telefonski kanal u opsegu od 0 do 4 kHz.
Stvarni nizvodni i uzvodni propusni opseg koji potencijalno stoji na raspolaganju datom
korisniku zavisi od udaljenosti izmeu njegovog i ISP-ovog modema, prenika kabla sa
upredenim paricama i stepena elektrinih smetnji. U stvari, za razliku od standardne modemske
veze, tehnologija DSL je upravo i napravljena za male udaljenosti izmeu kunih modema i
modema posrednika za Internet usluge, zahvaljujui emu se postiu znaajno vee brzine
prenosa.
Dok DSL i standardni modemi koriste obine telefonske linije, HFC pristupne mree
predstavljaju proirenje mrea koje se koriste za emitovanje kablovske televizije. U dananjim
kablovskim sistemima, kablovska glavna stanica emituje ka domovima kroz distribucionu
mreu koju ine koaksijalni kablovi i pojaivai. Kao to moete da vidite na slici 1.10, glavna
stanica je optikim kablovima povezana sa raskrsnicama u pojedinim delovima grada, od kojih
vode klasini koaksijalni kablovi ka pojedinanim domovima. Svaka ovakva raskrsnica obino
podrava izmeu 500 i 5 000 domova.
Poput tehnologije DSL, HFC takoe zahteva korienje posebnih modema koji se nazivaju
kablovski modemi. Kompanije koje obezbeuju kablovski pristup Internetu obino zahtevaju da
njihovi korisnici ili kupe ili iznajme jedan ovakav ureaj. Kablovski modem je najee eksterni
ureaj koji se sa raunarom povezuje preko 10-BaseT Ethernet porta. (U poglavlju 5 emo se
detaljnije pozabaviti Ethernetom.) Kablovski modemi dele HFC mreu na dva kanala - nizvodni
i uzvodni. Kao i kod tehnologije DSL, nizvodnom kanalu se obino dodeljuje vei propusni
opseg, tako daje za njega karakteristina i vea brzina prenosa.
Veoma vana karakteristika tehnologije HFC jeste to to predstavlja deljeni emisioni
medijum. Konkretno, svaki paket koji glavna stanica poalje putuje istim nizvodnim linkovima
do svakog doma; isto tako, svaki paket koji poalje krajnji korisnik putuje istim uzvodnim
kanalom do glavne stanice. Zbog toga, ukoliko vie korisnika istovremeno preuzima MP3
datoteke putem nizvodnog kanala, stvarna brzina preuzimanja svakog od njih bie manja od
maksimalne brzine nizvodnog kanala. S druge strane, ukoliko je samo nekoliko korisnika
aktivno i svi oni krstare Webom, najverovatnije e svi dobijati traene stranice punom brzinom
zato to se retko dogaa da vie korisnika zatrai neku stranicu u apsolutno istom trenutku. S
obzirom na to da se i uzvodni kanal deli, koristi se protokol za distribuirani istovremeni pristup
koji koordinira prenos i izbegava kolizije. (O kolizijama emo takoe govoriti u poglavlju 5, u
vezi sa Ethernet mreama.) Zagovornici DSL mrea esto istiu da DSL veze izmeu domova i
ISP-ova pripadaju tipu tipa taka-taka, to znai daje celokupna propusna mo na raspolaganju
i da nije deljena. Pristalice

1.4 . PRISTUP MREI I FIZIKI MED1JUMI 29 29 29 29

Slika 1.10 Slika 1.10 Slika 1.10 Slika 1.10 Hibridni optiko-koaksijalni pristup mrei

kablovskih mrea, s druge strane, tvrde da HFC mree razumnih dimenzija obezbeuju vei
propusni opseg od DSL mrea. Borba izmeu tehnologija DSL i HFC za veoma brzi pristup od
kue tek se zahuktava.
Jedno izuzetno privlano svojstvo DSL i HFC mrea jeste to Sto su njihove usluge uvek
dostupne. To znai da korisnik moe da ostavi svoj raunar ukljuen i povezan sa posrednikom
za Internet usluge, a da istovremeno prima telefonske pozive ili sam nekoga poziva.
Poslovni pristup
U preduzeima i na univerzitetima, za povezivanje krajnjeg sistema i perifernog rutera obino se
koristi lokalna raunarska mrea (LAN). Kao to ete videti u poglavlju 5, postoji mnogo
razliitih tipova LAN tehnologija. Ipak, tehnologija Ethernet je trenutno ubeljivo
najrasprostranjenija tehnologija pristupa u ovakvim mreama. Brzina Ethemetaje 10 Mb/s ili 100
Mb/s (sada ak i 1 Gb/s i 10 Gb/s). Za meusobno povezivanje veeg broja korisnika, kao i za
njihovo povezivanje sa perifernim ruterom koriste se bakarni kablovi sa upredenim paricama ili
koaksijalni kablovi. Periferni ruter je zaduen za rutiranje paketa ije je odredite izvan LAN-a.
Poput tehnologije HFC, Ethernet podrava deljivi pristup medijumu, tako da krajnji korisnici
izmeu sebe dele propusnu mo LAN-a. Odnedavno Ethemet polako postaje komutirana
tehnologija. U komutiranom Ethernetu koristi se vie Ethernet segmenata sa upredenim paricama
koji su povezani preko komutatora" ime se omoguava istovremena isporuka punog
propusnog opsega razliitim korisnicima LAN-a. O deljenom i komutiranom Ethernetu detaljnije
emo govoriti u poglavlju 5.
Beini pristup
Osim aktuelne internetske revolucije, revolucija u oblasti beinih tehnologija takoe je imala
izuzetan uticaj na ivot i rad savremenog oveka. Godine 2000, u Evropi je vie ljudi imalo
mobilni telefon nego raunar ili automobil. Mobilni trend se i dalje nastavlja, tako da se
predvia da e beini (i esto mobilni) runi ureaji kao to su, na primer, mobilni telefoni ili
PDA raunari, preuzeti dominaciju od umreenih raunara kada je u pitanju pristup Internetu.
Danas postoje dve iroke kategorije beinog pristupa Internetu. U beinim LAN-ovima
mobilni korisnici emituju podatke ka baznoj stanici (poznatoj i kao beina taka pristupa) ili ih
primaju od nje i to u preniku od nekoliko desetina metara. Bazna stanica je obino povezana sa
standardnom ianom vezom sa Internetom i slui za povezivanje beinih korisnika sa delom
mree u kome postoje kablovi. U regionalnim beinim pristupnim mreama baznom stanicom
upravlja posrednik za telekomunikacione usluge i ona obino moe da usluzi korisnike u
preniku od nekoliko desetina kilometara.
Beini LAN-ovi koji su zasnovani na tehnologiji IEEE 802. 11 (poznatoj po imenima
beini Ethernet i Wi-Fi) trenutno doivljavaju pravu ekspanziju na univerzitetima, zatim u
preduzeima, kafeima i domovima. Primera radi, na univerzitetima na kojima rade autori ove
knjige instalirane su bazne stanice IEEE 802.11. Ova beina LAN infrastruktura omoguava
studentima slanje i prijem elektronske pote i krstarenje Webom iz bilo kog dela studentskog
grada (iz biblioteke, spavaonice, uionice ili dvorita). Tehnologija 802.11, o kojoj emo takoe
govoriti u poglavlju 6, obezbeduje deljeni propusni opseg od 11 Mb/s.
2
Danas su u mnogim domovima, kombinacijom irokopojasnog kunog pristupa
(kablovskih ili DSL modema) sa jeftinom beinom LAN tehnologijom, dobijene mone kune
mree. Slika 1.11 predstavlja ematski prikaz prosene kune mree (u stvari, to je upravo
postavka mree oba autora). Ovu kunu mreu ine jedan prenosivi laptop i tri stacionarana
raunara (dva su povezana kablovima, jedan nije), zatim bazna stanica (beina pristupna taka)
koja komunicira sa pokretnim rauna-rom, kablovski modem koji obezbeduje pristup Internetu i
ruter koji povezuje baznu stanicu i stacionarni raunar sa kablovskim modemom. Ovakva mrea
omoguava lanovima domainstva da ostvare irokopojasni pristup Internetu, a da se jedan od
njih, pri tom, slobodno kree kroz kuu. Ukupna fiksna cena ovakve mree iznosi manje od 250
dolara (ukljuujui i kablovski /DSL modem).
Kod pristupa Internetu putem beine LAN tehnologije obino treba da budete na nekoliko
metara od bazne stanice. To je ostvarivo kada se nalazite u stanu, ili u Internet kafeu ili,
uopteno govorei, kada ste u nekoj zgradi. Ali ta ako se nalazite na plai ili u kolima, a
potreban vam je pristup Internetu? Za ovakav regionalni pristup pokretni korisnici Interneta
koriste infrastrukturu mobilnih telefona i preko nje pristupaju baznim stanicama koje mogu da
se nalaze i nekoliko desetina kilometara od njih.
2
Ovo vai za 802.11b dok 802.1 Ig ima 54 MB/s! {prim. rec.)

30 30 30 30 POGLAVLJE 1 RAUNARSKE MREE I INTERNET 1.4 - PRISTUP MREI l FIZIKI MEDIJUMI 27 27 27 27

WAP (H'ireless Access Protocol, version 2) [WAP 2004] koji je rasprostranjen u Evropi,
kao i i-mode koji je rasprostranjen u Japanu, predstavljaju dve tehnologije koje omoguavaju
pristup Internetu putem infrastrukture mobilnih telefona. WAP telefoni, koji podseaju na
standardne beine telefone sa neto krupnijim ekranom, omoguavaju relativno dobar pristup
Internetu, male i srednje brzine, kao i beinu telefonsku uslugu. Umesto jezika HTML, WAP
telefoni koriste poseban marker-ski jezik - WML {WAP Markup Language) - koji je
optimiziran za manje ekrane i manju brzinu pristupa. U Evropi protokol WAP funkcionie
preko izuzetno uspene GSM infrastrukture za beinu telefoni ju, pri emu se WAP 2.0
oslanja na TCP/IP protokole. S druge strane, zatiena tehnologija i-mode, koja je konceptualno
i funkcionalno veoma slina tehnologiji WAP, u Japanu je doivela veliki uspeh.
Telekomunikacione kompanije trenutno preduzimaju velika ulaganja u beinu tehnologiju
3G (Third Generation) koja bi trebalo da obezbedi regionalni beini pristup Internetu uz brzine
koje prelaze 384 kb/s [Kaaranen 2001][Korhonen 2003], 3G sistemi bi trebalo da obezbede
pristup velike brzine Webu i interaktivnom videu, kao i kvalitet glasa koji je superioran u
odnosu na klasinu telefoniju. Prvi 3G sistemi su primenjeni u Japanu. Imajui u vidu ogromna
ulaganja u 3G tehnologiju, njenu infrastrukturu i licence, mnogi analitiari (i investitori) pitaju
sc da li e ova tehnologija zaista biti toliko uspena koliko se pretpostavlja, ili e moda
izgubiti bitku od neke druge tehnologije kao Stoje, na primer, IEEE 802.11? ili e se, moda,
kombinacijom ove dve tehnologije dobiti sveopti ali heterogeni pristup. (Proitajte
[VVeinstein 2002] i istorijski osvrt u odeljku 6.2.) O tehnologijama 802.11 i 3G detaljnije emo
govoriti u poglavlju 6.
1.4.2 Fiziki medij umi
U prethodnom odeljku prikazali smo vam neke od najvanijih tehnologija za ostvarivanje
mrenog pristupa koje se koriste na Internetu..Opisujui ove tehnologije, naveli smo i fizike
medijume koji se u njima koriste. Na primer, rekli smo da se u tehnologiji HFC koristi
kombinacija optikih i koaksijalnih kablova, dok standardni modemi brzine 56 kb/s i tehnologija
ADSL koriste bakarne kablove sa upredenim paricama. Rekli smo i to da se u mreama sa
mobilnim pristupom kao medijum koristi spektar radio talasa. U ovom odeljku emo ukratko
opisati ove i druge preno-sne medijume koji se esto koriste u okviru Interneta.
Da bismo definisali ta se podrazumeva pod fizikim medijumom, zamisli-emo kako
izgleda kratak ivot jednog bita. Dakle, zamislite jedan bit koji putuje od jednog krajnjeg
sistema, kroz seriju linkova i rutera, do drugog krajnjeg sistema. Taj bit mora da se prenese
nebrojeno mnogo puta. Izvorni krajnji sistem emituje ovaj bit i ubrzo zatim njega prima prvi
ruter u nizu. Zatim ga taj prvi ruter dalje emituje da bi ga nakon toga primio drugi ruter i tako
redom. Prema tome, na bit, putujui od svog izvora da svog odredita, mora da proe kroz
seriju primopredajnih parova. Izmeu svih ovih primopredajnih parova bit putuje u vidu
elektromagnetnog talasa, elektrinog ili optikog impulsa, kroz fizike medijume. Fiziki
medijumi imaju mnogo razliitih oblika i ne moraju biti istog tipa izmeu svakog
primopredajnog para na putanji. U primere fizikih medijuma ubrajaju se bakarni kablovi sa
upredenim paricama, zatim koaksijalni kablovi, multimodna optika vlakana, zemaljski spektar
radio talasa i satelitski spektar radio talasa. Postoje dve kategorije fizikih medijuma - voeni i
nevoeni medijumi. Kod voenih fizikih medijuma signali se vode kroz vrst medijum kao to
su, na primer, kablovi od optikih vlakana, bakarni kablovi sa upredenim paricama ili
koaksijalni kablovi. Kod nevoenih medijuma talasi se ire kroz atmosferu ili kroz vasionski
prostor, kao stoje to sluaj u beinim LAN-ovima ili kod digitalnih satelitskih kanala.
Pre nego to preemo na karakteristike razliitih tipova medijuma, recimo nekoliko rei i o
njihovim cenama. Stvarna cena fizikog linka (bakarnog ili optikog kabla) esto je praktino
zanemarljiva u poreenju sa ostalim trokovima za mreu. Na primer, trokovi vezani za radnu
snagu kod naknadne instalacije fizikih linkova esto premauju cenu samog materijala. Iz tog
razloga, u mnogim novijim zgradama su u svakoj prostoriji instalirani i kablovi sa upredenim
paricama i optiki i koaksijalni kablovi. ak i ako se u startu koristi samo jedan od ovih
medijuma, velike su anse da e u bliskoj budunosti zatrebati i neki drugi, tako da se na ovaj
nain smanjuju trokovi naknadnog postavljanja kablova.
Bakarni kablovi sa upredenim paricama
Najjeftiniji i najrasprostranjeniji voeni prenosni medijum jesu bakami kablovi sa upredenim
paricama. Ove kablove ve vie od 100 godina koriste telefonske mree. U stvari, na vie od 99
procenata oienih veza izmeu telefonskog aparata i lokalnog telefonskog komutatora koriste
se upravo bakami kablovi sa upredenim paricama. Ove kablove ste sasvim sigurno mnogo puta
videli u svom domu. Sastoje se

28 28 28 28 POGLAVLJE ) RAUNAR5KE MREE I INTERNET 1.4 PRISTUP MREI I r\ZiCKi MEDIJUM) 33 33 33 33

od dva izolovana bakama provodnika debljine oko 1 mm koji su spiralno upredeni. Upredanjem
provodnika smanjuju se elektromagnetne smetnje drugog para provodnika koji bi mogao da se
nalazi u blizini. Obino se ovaj par provodnika grupie u kabl tako to se uvija u zatitni oklop.
Jedan par provodnika ini jedan komunikacioni link. Neoklopljene upreene parice
(Unshielded TwistedPairs, UTPs) veoma esto se koriste u lokalnim raunarskim mreama u
okviru iste zgrade. Brzina prenosa podataka kroz ovakve kablove kree se izmeu 10 Mb/s i 1
Gb/s i zavisi od debljine kablova i udaljenosti izmeu predajnika i prijemnika.
Kada se 1980-ih pojavila tehnologija optikih vlakana, mnogi ljudi su poeli da
omalovaavaju kablove sa upredenim paricama zbog njihove relativno male brzine prenosa.
Neki su ak ili toliko daleko da su predviali da e tehnologija optikih vlakana potpuno
potisnuti kablove sa upredenim paricama. Meutim, upreene parice se nisu tako lako predale.
Savremena tehnologija upredenih parica, kao to su kablovi kategorije 5, omoguava brzine
prenosa od 100 Mb/s na udaljenostima od nekoliko stotina metara. Na kraim udaljenostima
mogue su ak i vee brzine prenosa. Danas kablovi sa upredenim paricama i dalje
predstavljaju dominantno reenje za lokalne raunarske mree velike brzine.
Kao to smo ve napomenuli u odeljku o pristupnim mreama, kablovi sa upredenim
paricama veoma esto se koriste za pristup Internetu od kue. Videli ste da tehnologija
telefonskih modema omoguava brzine prenosa do 56 kb/s kroz kablove sa upredenim
paricama. Ali, takode ste videli i to je da tehnologija DSL {Digital Subscriber Line) omoguila
kunim korisnicima pristup Internetu brzinom od oko 6 Mb/s preko istih tih kablova sa
upredenim paricama (ukoliko ive blizu ISP-ovog modema).
Koaksijalni kablovi
Poput kablova sa upredenim paricama, koaksijalni kablovi se takoe sastoje od dva bakarna
provodnika, s tom razlikom to oni ovde nisu postavljeni paralelno, ve koncentrino.
Zahvaljujui ovakvoj konstrukciji, posebnoj izolaciji i oklopu, ovi kablovi omoguavaju vee
brzine prenosa. Ova vrsta kablova veoma esto se koristi u kablovskim televizijskim sistemima.
Kao to smo ve rekli, odnedavno proirenje ovih sistema predstavljaju kablovski modemi koji
kunim korisnicima omoguuju pristup Internetu koji moe da bude bri od 1 Mb/s. Kod
irokopojasnih koaksijalnih kablova predajnik podie signal u neki konkretan frekventni opseg,
a zatim se rezultujui analogni signal alje ka jednom prijemniku ili ka vie njih. Obe varijante
koaksijalnih kablova mogu da se koriste kao voeni deljeni medij u m. To, konkretno, znai da
sa istim kablom moe da bude povezan vei broj krajnjih sistema i svi oni tada primaju sve ono
to alju svi drugi krajnji sistemi.
Kablovi od optikih vlakana
Optiki kablovi su tanki i fleksibilni medijumi koji provode svetlosne impulse, a svaki svetlosni
impuls predstavlja jedan bit. Jedan optiki kabl moe da podri
izuzetno velike brzine prenosa, ak do nekoliko desetina pa i stotina gigabita po sekundi. Ovi
kablovi su imuni na elektromagnetne smetnje, imaju neznatno slabljenje signala do razdaljine od
100 kilometara i veoma teko se prislukuju. Zahvaljujui ovim karakteristikama, optiki kablovi
su najbolji voeni prenosni medijumi za due relacije, posebno kada su u pitanju prekomorske
veze. U mnogim meugradskim telefonskim mreama u SAD, ali i u drugim krajevima sveta,
sada se koriste iskljuivo kablovi od optikih vlakana. U okosnici Interneta takoe dominira ova
vrsta kablova. Meutim, visoka cena optikih ureaja kao to su predajnici, prijemnici i
komutatori ograniila je njihovu primenu u transportu na kraim relacijama - recimo, u
LAN-ovima ili domovima. U radovima [IEC Optical 2003], [Goralski 2001], [Ramasvvami
1998] i [Mukherjee 1997] pronai ete veoma detaljan prikaz raznih aspekata optikih mrea. U
linkovima od optikih vlakana brzine prenosa obino se mere desetinama gigabajta u sekundi.

Zemaljski radio talasi
Radio stanice prenose signale koristei elektromagnetni spektar. Oni predstavljaju veoma
zanimljiv medijum zato to ne zahtevaju instaliranje kablova, mogu da prou i kroz zidove,
obezbeuju povezivost mobilnim korisnicima i prenose signale na velike daljine. Karakteristike
radio kanala u velikoj meri zavise od karakteristika sredine kroz koju se prenose, kao i
udaljenosti koje treba da premoste. Sredina kroz koju se signali prenose moe na njih da utie u
smislu gubitka putanje i slabljenja zbog senke (jaina signala se smanjuje sa poveanjem
udaljenosti i na putu oko prepreka ili kroz njih), slabljenja usled viestrukih putanja (signali se
odbijaju o objekte koji im se nadu na putu) i smetnji (koje stvaraju drugi radio kanali ili
elektromagnetni signali).
Zemaljski radio kanali mogu grubo da se podele u dve grupe - one koji pokrivaju lokalne
oblasti (od nekoliko desetina pa do stotinak metara) i one koji pokrivaju vee oblasti (nekoliko
desetina kilometara). Beini ureaji za LAN koje smo pomenuli u odeljku 1.4.1 koriste radio
talase lokalnog dometa; s druge strane, tehnologije WAP, i-mode i 3G koje smo takode
pominjali u odeljku 3.4.3, koriste radio kanale regionalnog dometa. Detaljno istraivanje ove
tehnologije i prateih proizvoda pronai ete u radu [Doman 2001]. O radio talasima detaljnije
emo govoriti u poglavlju 6.

Satelitski radio kanali
Komunikacioni sateliti povezuju dva ili vie zemaljskih predajnika i prijemnika koji se nazivaju
zemaljskim stanicama. Satelit prima emisije u jednom frekventnom opsegu, zatim regenerie
primljeni signal pomou repetitora (objanjen u nastavku teksta) i onda emituje signal u drugoj
frekvenciji. Propusni opseg koji omoguavaju sateliti meri se gigabitima po sekundi. Za potrebe
komunikacija koriste se dve vrste satelita - geostacionarni i niski sateliti.
Geostacionarni sateliti trajno ostaju iznad iste take na Zemlji. Nepromenlji-vost pozicije
postie se postavljanjem satelita u orbitu na visini od 36 000 kilometara iznad povrine Zemlje.
Zbog ogromne udaljenosti koju signal treba da prede od
3
Ovo u praksi nikada nije sluaj, (prim. rec.)

1.5 POSREDNICI ZA INTERNET USLUGE I OKOSNICE INTERNETA 35 35 35 35
zemaljske stanice do satelita i natrag do druge zemaljske stanice, javlja se kanjenje od 250
milisekundi. Meutim, i pored ovog kanjenja, satelitski linkovi koji obezbeuju brzine od
nekoliko stotina Mb/s, esto se koriste u telefonskim mreama i intemetskim okosnicama.
Niski sateliti postavljaju se na mnogo manjoj udaljenosti od Zemlje. Oni ne ostaju sve
vreme iznad iste take na Zemljinoj povrini ve, poput Meseca, rotiraju oko nae planete. Za
kontinuiranu pokrivenost odreene oblasti potrebno je mnogo satelita koji su postavljeni u
orbitu. Trenutno ima mnogo niskih komunikacionih sistema koji su u fazi razvoja. Lojdova veb
stranica o konstelaciji satelita [Wood 2004] predstavlja dobar izvor informacija o poloaju
satelitskih komunikacionih sistema. Mogue je da_ e se u budunosti za pristup Internetu
koristiti upravo tehnologija niskih satelita.

1.5 Posrednici za Internet usluge i internetske okosnice
Ve smo rekli da se krajnji korisnici (PC i PDA raunari, veb serveri, serveri za elektronsku
potu, itd.) povezuju sa Internetom putem pristupne mree. Podseamo vas da ta pristupna
mrea moe biti oiena ili beina lokalna raunarska mrea (na primer, u nekoj kompaniji,
koli ili biblioteci) ili mrea ISP-a (na primer. AOL ili MSN) do koje se dolazi putem
standardnog, kablovskog ili DSL modema. Meutim, povezivanje krajnjih korisnika i
obezbeivaa raznih sadraja u pristupne mree predstavlja samo mali deo slagalice koju ine
stotine miliona korisnika i stotine hiljada mrea od kojih se sastoji Internet. Internet moe da se
definie kao mrea svih mrea i razumevanje ove fraze je klju za reavanju ove velike
slagalice.
U javnom Internetu, pristupne mree koje se nalaze na njegovoj periferiji povezane su sa
ostatkom Interneta kroz slojevitu hijerarhiju posrednika za Internet usluge (ISP), kao to je to
prikazano na slici 1.12. Pristupni ISP-ovi (na primer, rezidencija]ni posrednici za Internet usluge
kao to je AOL i kompanijski posrednici koji koriste LAN-ove) nalaze se na dnu ove
hijerarhije. Na njenom .vrhu nalazi se relativno mali broj tzv. ISP-ova prvog reda. ISP prvog
reda bi u mnogo emu mogao da se poistoveti sa bilo kojom drugom mreom - on ima linkove i
rutere i povezan je sa drugim mreama. S druge strane, ISP-ovi prvog reda imaju i neke
jedinstvene karakteristike. Brzine njihovih linkova esto prelaze 622 Mb/s, a vei posrednici
prvog reda imaju ak i linkove brzine 2,5 do 10 Gb/s; njihovi ruteri su, u skladu sa tim, sposobni
za prosledivanje paketa veoma velikom brzinom. Posrednici za Internet usluge prvog reda se,
pored onoga to smo ve rekli, prepoznaju po sle-deim karakteristikama:
direktno se povezuju sa svim drugim posrednicima prvog reda;
povezani su sa velikim brojem posrednika drugog reda, kao i sa ostalim komercijalnim
mreama;
pokrivaju vei broj zemalja.
Posrednici za Internet usluge prvog reda obino se nazivaju intemetskim okosnicama.
Meu najveim kompanijama okosnicama nalaze se Sprint, MCI (nekadanji
UUNetAVorldCom), AT&T, Level3 (koji je kupio Genuitv), Qwest i Cable and Wireless.
Sredinom 2002. godine kompanija Wor]dCom bila je ubedljivo najvei internetski posrednik
prvog reda - po mnogim parametrima ak dva puta vei od najblieg rivala [Teleographv 2002].
Veoma je zanimljivo i to da nijedna grupa nije zvanino zaduena za posrednike prvog reda;
ukoliko treba da pitate da li ste lan grupe, onda to najverovatnije niste.
Posrednici za Internet usluge drugog reda obino imaju regionalni ili nacionalni znaaj i
(stoje veoma znaajno) povezani su samo sa nekoliko posrednika prvog reda (slika 1.32). Prema
tome, da bi mogao da stigne do svih delova globalnog Interneta, ISP drugog reda mora da rutira
svoj saobraaj kroz mreu posrednika prvog reda sa kojim je povezan. U meusobnoj hijerarhiji
ISP drugog reda je korisnik, dok je ISP prvog reda dobavlja. Mnoge velike kompanije
povezuju svoje mree direktno sa posrednicima prvog ili drugog reda i na taj nain postaju
njihove mute-

36 36 36 36 POGLAVLJE 1 RAUNARSKE MREE I I I I INTERNET 1.6 KANJENJE l GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA 37 37 37 37
rije. ISP u poziciji dobavljaa naplauje svojim muterijama odreenu naknadu ija je visina
obino povezana sa propusnim opsegom linka koji ih povezuje. Posrednik drugog reda moe i
direktno da se povee sa mreom drugog posrednika drugog reda i u tom sluaju saobraaj
izmeu njih ne mora da ide kroz mreu posrednika prvog reda. Ispod posrednika drugog reda
nalaze se posrednici nieg reda koji se sa ostatkom Interneta povezuju preko jednog posrednika
drugog reda. Na dnu ove hijerarhije nalaze se pristupni posrednici za Internet usluge. Da
situacija bude jo sloenija pobrinuli su se neki posrednici prvog reda koji su istovremeno i
porednici za Internet usluge drugog reda (vertikalno su integrisani) i prodaju pristup Internetu
direktno krajnjim korisnicima i obezbeivaima sadraja, ali i posrednicima nieg reda. Za dva
ISP-a koji su direktno povezani kae se da su u ravnopravnom odnosu. Autori veoma
zanimljive studije [Subramanian 2002] pokuali su preciznije da definiu slojevitost Interneta
analizom njegove topologije u smislu termina kori-snik-dobavlja i ravnopravnih odnosa.
U okviru mree posrednika za Internet usluge, take u kojima se dati posrednik povezuje sa
drugim posrednicima (svejedno da lije to u hijerarhiji na istom nivou, iznad ili ispod) nazivaju se
prikljunim takama (Point o/Presence, POP). Prikljunu taku'ini grupa rutera mree jednog
posrednika za Internet usluge sa kojima su povezani ruteri nekog drugog posrednika. Posrednik
prvog reda obino ima mnogo prikljunih taaka koje se nalaze na razliitim geografskim
lokacijama i sa kojima je obino povezano vie posrednika u rangu korisnika. Posrednici u
rangu korisnikao-bino za povezivanje sa posrednikom ranga dobavljaa koriste linkove velike
brzine koje iznajmljuju od dobavljaa telekomunikacionih usluga. Dva ISP-a prvog reda mogu
da ostvare ravnopravan odnos meusobnim povezivanjem svojih prikljunih taaka.
Pored meusobnog povezivanja u privatnim ravnopravnim takama, posrednici za Internet
usluge se esto povezuju u mrenim pristupnim takama (Network Access Point, NAP) koje su
u vlasnitvu neke nezavisne telekomunikacione kompanije koja njima upravlja ili pripadaju
intemetskim okosnicama. Kroz ove take cir-kulie velika koliina saobraaja izmeu veeg
broja posrednika za Internet usluge. Ipak, posrednici prvog reda u sve veoj meri zaobilaze NAP
take i direktno se povezuju u privatnim ravnopravnim takama [Kende 2000]. Trenutno je trend
takav da se ISP-ovi prvog reda meusobno direktno povezuju u privatnim takama, a da se
posrednici drugog reda izmeu sebe i sa posrednicima prvog reda povezuju preko NAP taaka.
S obzirom na to da NAP take prenose i komutiraju ogromne koliine saobraaja, one same po
sebi predstavljaju sloene i veoma brze mree sa komutiranjem, koje se esto koncentriu u
jednoj zgradi.
Dakle, mogli bismo da zakljuimo daje topologija Interneta izuzetno sloena i da je ine
desetine ISP-ova prvog i drugog reda, kao i hiljade posrednika nieg reda. Ovi posrednici se
izmeu sebe razlikuju prema oblasti koju pokrivaju - neki se prostiru na vie kontinenata, dok su
drugi prisutni samo u veoma malim delovima sveta. Posrednici nieg reda povezuju se sa
posrednicima vieg reda, koji za meusobno
povezivanje (obino) koriste privatne ravnopravne take i NAP take. Korisnici i kompanije
koje obezbeuju sadraj na Internetu predstavljaju korisnike posrednika nieg reda, koji su,
opet, korisnici ISP-ova vieg reda.
Ovaj odeljak emo zavriti napomenom da svako ko ostvari vezu sa Internetom moe da
postane ISP. Potrebno je samo kupiti neophodnu opremu (recimo, ruter i odgovarajui broj
modema) i omoguiti ostalim korisnicima da se povezu sa njom. To znai daje ukljuivanje
novih posrednika niih redova onoliko jednostavno koliko i dodavanje Lego kockica u neku
postojeu Lego konstrukciju.
1.6 Kanjenje i gubitak paketa u mreama sa
komutiranjem paketa
Poto smo ukratko prikazali osnovne delove strukture Interneta - aplikacije, krajnje sisteme,
transportne protokole sa kraja na kraj mree, rutere i linkove, pogledajmo ta se deava sa
paketom na njegovom putu od izvora do odredita. Podseamo vas da putovanje paketa
zapoinje u (izvornom) raunam, da on zatim prolazi kroz seriju rutera i zavrava u drugom
(odredinom) raunam. Na putu od jednog (raunar ili ruter) do drugog vora (opet, raunar ili
ruter), paket moe da zadesi nekoliko razliitih tipova kanjenja i to na svakom od vorova na
njegovoj putanji. Meu ovim kanjenjima najznaajnija su: kanjenje usled obrade na voru,
kanjenje usled stajanja u redu, kanjenje usled prenosa i kanjenje usled propagacije.
Sabiranjem svih ovih kanjenja dobija se ukupno kanjenje vora. Da biste mogli da razumete
proces komutiranja paketa, kao i raunarske mree u celini, veoma je vano da shvatite prirodu
i znaaj pomenutih kanjenja.
1.6.1 Tipovi kanjenja
Razmotrimo sva pomenuta kanjenja u kontekstu slike 1.13. Kao deo sopstvene putanje izmeu
izvornog i odredinog raunara, paket se alje iz vora koji emituje uzvodno kroz ruter A do
rutera B. U ovom sluaju cilj nam je da ustanovimo kanjenje vora na ruteru A. Skreemo vam
panju na to da ruter A ima izlazni link koji vodi ka ruteru B. Ispred ovog linka nalazi se red (ili
privremena memorija rutera). Kada paket iz uzvodnog toka stigne do rutera A, ruter ispitivanjem
zaglavlja paketa ustanovljava odgovarajui izlazni link za dati paket i odmah ga usmerava ka
tom linku. U ovom primeru to je link koji vodi ka ruteru B. Prenos paketa linkom mogu je
samo ako se tim linkom trenutno ne prenosi nijedan drugi paket i ako u redu za prenos nema
drugih paketa. Ukoliko je link trenutno zauzet ili ukoliko postoje paketi koji trenutno ekaju u
redu za prenos, novopristigli paket mora da stane u red.

1.6 KANJENJE I GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA 31 31 31 31

Kanjenje usled obrade
Vreme koje je potrebno za ispitivanje zaglavlja paketa i donoenje odluke o njegovom
usmeravanju naziva se kanjenje usled obrade. Na kanjenje usled obrade mogu da utiu i
drugi faktori, na primer, trajanje provere greaka na nivou bitova u paketima do kojih je dolo
prilikom uzvodnog prenosa od raunara do rutera A. Kanjenje usled obrade se u veoma brzim
ruterima meri mikrosekundama, pa ak i manjim jedinicama.
Nakon ove obrade, ruter usmerava paket u red koji se nalazi ispred linka ka rutem B. (U
poglavlju 4, detaljno emo vam prikazati nain rada rutera.)
Kanjenje usled stajanja u redu
U redu u kome paket mora da saeka na upuivanje na link nastaje kanjenje usled stajanja u
redu. Ovo kanjenje uvek zavisi od broja paketa koji su pre datog paketa ve stali u red i
ekaju na prenos. Ukoliko je red prazan i na linku nema nijednog drugog paketa, onda je
kanjenje usled stajanja u redu datog paketa jednako nuli. S druge strane, ukoliko je saobraaj
obiman i mnogo paketa stoji u redu, kanjenje usled stajanja u redu bie znaajno. Uskoro ete
videti da broj paketa koje novopristigli paket moe da oekuje da e zatei predstavlja funkciju
intenziteta i prirode saobraaja koji stie u red. U praksi, ovaj vid kanjenja meri se
mikrosekundama ili milisekundama.
Kanjenje usled prenosa
Ukoliko pretpostavimo da se paketi opsluuju i prenose onim redom kojim su pristigli, Stoje i
praksa u mreama sa komutiranjem paketa, prenos naeg paketa moe da se nastavi tek nakon
prenosa svih paketa koji su stigli pre njega. Duinu paketa izra-ziemo brojem L bitova, a
brzinu prenosa linka koji povezuje rutere A i B brojem R bitova u sekundi. Brzinu R odreuje
brzina prenosa linka do rutera B. Primera radi, u linku tipa 3 0 Mb/s Ethernet, R iznosi 10 Mb/s;
u linku 100 Mb/s Ethernet, brzina R iznosi 100 Mb/s. Kanjenje usled prenosa (naziva se jo i
kanjenje memorisanja i
prosleivanja, o emu je bilo rei u odeljku 1.3) dobija se kada se L podeli sa R. To je vreme
koje je potrebno da se svi bitovi paketa izbace (prenesu) na link. U praksi je ovo kanjenje
obino reda veliine mikrosekundi ili milisekundi.

Kanjenje usled propagacije
Kada bit dospe na link, njega je potrebno transportovati do rutera B. Vreme potrebno za
transport paketa od poetka linka do rutera B naziva se kanjenje usled propagacije. Bitovi
paketa transportuju se brzinom propagacije linka koja zavisi od fizikog medijuma linka (to
mogu biti optiki ili bakami kablovi) i kree se u opsegu:
2 10*metara u sekundi do 3 IO
8
metara u sekundi.
Ova brzina je praktino jednaka brzini svetlosti. Kanjenje usled propagacije izraunava se
tako to se udaljenost izmeu dva rutera podeli sa brzinom propagacije (d/s, gde d predstavlja
udaljenost rutera A i B, a s brzinu propagacije lirika). im se i poslednji bit paketa transporiuje
do rutera B, on i svi ostali bitovi datog paketa se memoriu u ovom ruteru. Zatim se ceo proces
ponavlja, s tom razlikom to sada ruter B prosleuje paket. U regionalnim raunarskim mreama
kanjenje usled propagacije meri se milisekundama.
Poreenje kanjenja usled prenosa i kanjenja usled propagacije Ljudi koji nemaju mnogo
iskustva u oblasti umreavanja esto ne mogu da naprave razliku izmeu kanjenja usled
prenosa i kanjenja usled propagacije. Ova razlika je, dodue, mala, ali veoma znaajna.
Kanjenje usled prenosa predstavlja vreme koje je ruteru potrebno da izgura paket; ono zavisi od
duine paketa i prenosne brzine linka, ali nema nikakve veze sa udaljenou dva rutera.
Kanjenje usled propagacije, s druge strane, predstavlja vreme za koje se bit transportuje od
jednog do drugog rutera; ono zavisi od udaljenosti izmeu rutera ali nema nikakve veze sa
duinom paketa niti sa brzinom prenosa datog linka
4
.
Da bismo vam pomogli u razlikovanju ovih pojmova, napraviemo jednu analogiju.
Zamislite autoput koji na svakih 100 kilometara ima naplatnu rampu. Segmente autoputa izmeu
ovih naplatnih rampi moete da poistovetite sa linkovima, a same naplatne rampe sa ruterima.
Pretpostavimo da automobili putuju (odnosno, propagiraju) ovim autoputem brzinom od 100
km/h (i da, im napuste naplatnu rampu, trenutno dostignu ovu brzinu koju odravaju sve do
sledee naplatne rampe). Pretpostavimo, dalje, da putuje karavan od 10 vozila koja su postrojena
jedno za drugim u fiksnom redosledu. Svaki pojedinani automobil bi, u ovom sluaju, mogao
da se poistoveti sa bitom, a ceo karavan sa paketom. Takoe emo pretpostaviti da svaka
naplatna rampa svaki automobil opsluuje (prenosi) tano 12 sekundi, a poto se to deava
kasno nou, ovi automobili su jedini automobili na putu. Konano, pretpostaviemo i to da
automobil koji prvi stigne do naplatne rampe, mora na ulazu da saeka dolazak svih 9 preostalih
automobila. (Dakle, ceo karavan najpre mora
" Propagacijn zavisi iskljuivo od elektrinih ili elekiromagnelnili osobina medijuma (prim. rec.)

40 40 40 40 POGLAVLJE 1 RAUNARSKE MREE I I I I INTERNET 1.6 KANJENJE I I I I GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA 32 32 32 32

da se memorie" da bi se tek nakon toga prosledio".) Vreme koje je potrebno da naplatna
rampa propusti ceo karavan na autoput iznosi: (IO automobila)/(5 automobila/min) = 2 minuta.
Ovo vreme bi moglo da se poistoveti sa kanjenjem usled prenosa na ruterima. Za prelazak puta
izmeu dve naplatne rampe automobilima je potrebno: 100 km/(100 km/as) = 1 as. Ovo
vreme bi, s druge strane, moglo da se poistoveti sa kanjenjem usled propagacije. Prema tome,
vreme od trenutka kada se karavan memorie" ispred naplatne rampe do trenutka kada se to isto
dogodi ispred sledee naplatne rampe predstavlja sumu kanjenja usled prenosa" i kanjenja
usled propagacije" - u ovom primeru to iznosi 62 minuta.
Zadrimo se jo malo na ovoj analogiji. Sta bi se dogodilo kada bi opsluivanje karavana
na naplatnoj rampi trajalo due od putovanja automobila izmeu dve rampe? Primera radi,
pretpostavimo da se automobili kreu brzinom od 1 000 km/h, a da naplatna rampa opsluuje
jedan automobil u minutu. U tom sluaju putovanje automobila trajalo bi 6 minuta, a
opsluivanje itavog karavana 10 minuta. To znai da bi prvih nekoliko automobila stiglo do
druge naplatne rampe u trenutku kada poslednji automobili naputaju prvu rampu. Ova situacija
se dogaa u mreama sa komutiranjem paketa - prvi bitovi nekog paketa mogu da stignu do
drugog rutera, a da poslednji bitovi istog paketa jo uvek ekaju na prenos u prethodnom.
Ukoliko sa t/obrada, d^, </pionos, d oznaimo kanjenja usled obrade, stajanja u redu, prenosa i
propagacije, onda se ukupno kanjenje vora izraunava na sledei nain:
^Cvor
=
ôbrada
+
^red
+
^prenos
+
^prop
Pojedinani doprinos svakog sabirka u ukupnom kanjenju na voru moe prilino da
varira. Primera radi, sabirak dp(op moe da bude beznaajan (svega nekoliko mikrosekundi)
ukoliko je re o linku koji povezuje dva rutera u istom studentskom gradu. Isto tako, ovo
kanjenje moe da iznosi i stotine milisekundi, ukoliko je re o dva rutera koji su povezani
geostacionamim satelitskim linkom i onda je ono najkrupniji sabirak u ukupnom zbiru dtvof
Slino tome, i sabirak dpnnm takoe moe da varira od sasvim beznaajnih, pa do prilino
znaajnih vrednosti. Njegov doprinos je obino beznaajan pri brzinama prenosa od 10 Mb/s i
veim (na primer, u LAN-ovima). Meutim, kod velikih intemetskih paketa koji se alju sporim
telefonskim modemskim linkovima, u pitanju su ve stotine milisekundi. Kanjenje usled obrade
ôbrada esto je beznaajno ali, s druge strane, znaajno utie na maksimalnu ukupnu propusnu
mo rutera, odnosno maksimalnu brzinu kojom ruter moe da prosledi pakete.

1.6.2 Kanjenje usled stajanja u redu i gubljenje paketa
Najsloenija i najzanimljivija komponenta ukupnog kanjenja na voru jeste kanjenje usled
stajanja u redu - dred. Ovaj vid kanjenja je toliko vaan i zanimljiv aspekt umreavanja, da su
mu posveeni brojni radovi i veliki broj knjiga [Bertsekas 1991; Daigle 1991; Kleinrock 1975,
1976; Ross 1995]. Mi smo vam ponudili samo intuitivno razmatranje visokog nivoa kanjenja
usled stajanja u redu; za bolji uvid u pro-
blematiku, moete da prelistate neke od knjiga koje se bave ovom temom. Za razliku od ostala
tri kanjenja (<ôbrada. dpKTIOS, dptop), trajanje kanjenja usled stajanja u redu razlikuje se od paketa
do paketa. Na primer, ako u istom trenutku u prazan red stigne deset paketa, kod prvog prenetog
paketa nee uopte biti kanjenja, dok e kod poslednjeg ono biti najvee (on mora da saeka
prenos prethodnih devet paketa). Otud, kada se govori o kanjenju usled stajanja u redu, obino
se koriste statistiki parametri kao to su prosena vrednost kanjenja, varijansa kanjenja ili
verova-tnoa da e kanjenje usled stajanja u redu premaiti neku naznaenu vrednost.
Kada je kanjenje usled stajanja u redu osetno, a kada beznaajno? Odgovor na ovo pitanje
u velikoj meri zavisi od obima saobraaja koji stie u red, brzine prenosa linka i prirode
pristiglog saobraaja (da li on stie periodino ili u naletima). Da bismo vam malo pribliili ovaj
problem, uveemo novu promenljivu i slovom a oznaiti prosenu brzinu kojom paketi stiu u
red (meri se brojem paketa u sekundi). Kao i ranije, R je brzina prenosa, odnosno brzina (u
bitovima u sekundi) kojom se bitovi guraju iz reda. Da bi sve bilo to jednostavnije,
pretpostaviemo da se svi paketi sastoje od L bitova. U tom sluaju, prosena brzina kojom
bitovi stiu u red iznosi La bitova u sekundi. Konano, pretpostaviemo i to da je red veoma
dugaak, to znai da u njemu moe da se nalazi beskonaan broj paketa. Odnos La/R koji se
naziva i intenzitet saobraaja esto igra veoma vanu ulogu u proceni kanjenja usled stajanja u
redu. Ukoliko je La/R > I, I, I, I, onda prosena brzina kojom bitovi dospevaju u red premauje brzinu
kojom oni mogu da se prenesu iz tog reda. U ovakvoj nesrenoj situaciji red bi se bezgranino
produavao, a vrednost kanjenja usled stajanja u redu pribliila bi se beskonanosti. Dakle,
jedno od zlatnih pravila u vezi sa dimenzioniranjem saobraaja glasi: Dizajnirajte svoj sistem
tako da vrednost intenziteta saobraaja nikada ne bude I .
Sada zamislite situaciju u kojoj je La/R < 1. U ovom sluaju priroda pristiu-eg saobraaja
utie na vrednost kanjenja usled stajanja u redu. Na primer, ukoliko paketi stiu periodino
(jedan na svakih L/R sekundi), svaki od njih e zatei prazan red i nikakvog ekanja nee biti.
Ali, ukoliko paketi stiu u periodinim naletima, proseno kanjenje usled ekanja u redu moe
biti znaajno. Pretpostavimo, na primer, da broj od N paketa stie istovremeno svakih {L/R)N
sekundi. Tada prvi preneti paket nema kanjenje, drugi ima kanjenje od L/R sekundi, a -ti
paket kanjenje od ( n - l)L/R sekundi. Ostaviemo vam da, kao svojevrsno vebanje, za ovaj
primer izraunate proseno kanjenje usled stajanja u redu.
Za dva opisana primera o periodinom pristizanju paketa moglo bi da se kae da su pomalo
akademski. Paketi obino u red stiu nasumino, bez ikakvog ablona i u razliitim vremenskim
intervalima. U ovom, neto realnijem primeru, vrednost La/R obino nije dovoljna za puno
defmisanje statistike kanjenja. Ipak, ovo intuitivno razumevanje duine kanjenja usled stajanja
u redu moe samo da vam koristi. Konkretno, ako je vrednost intenziteta saobraaja bliska nuli,
to znai da paketi stiu retko i sa dugim pauzama izmeu njih, tako da su anse da pristigli paket
u redu zatekne neki drugi paket veoma male. Zbog toga e prosena vrednost kanjenja u redu
biti bliska nuli. Nasuprot tome, kada je vrednost intenziteta saobraaja bliska broju 1, to znai da
postoje periodi u kojima brzina kojom paketi pristiu prevazilazi

33 33 33 33 POGLAVLJE 1 RAUNARSKE MREE I INTERNET 1.6 KANJENJE I I I I GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA 43 43 43 43

prenosni kapacitet (zbog intervala sa naletima;, sto povlaci formiranje reda. Kako se vrednost
intenziteta saobraaja pribliava broju 1, prosena duina kanjenja usled stajanja u redu postaje
sve vea. Na slici 1.14 prikazana je kvalitativna zavisnost prosenog kanjenja usled stajanja u
redu od intenziteta saobraaja.
Veoma vaan aspekt slike 1.14 predstavlja injenica da sa pribliavanjem vre-dnosti
intenziteta saobraaja vrednosti 1, prosena vrednost kanjenja usled stajanja u redu veoma brzo
raste. Mali procenat poveanja prvog parametra povlai procentualno mnogo vei porast
drugog. Ovaj fenomen ste najverovatnije upoznali na pute-vima. Ukoliko se redovno vozite
putem koji je esto zaguen, to znai da je vrednost intenziteta saobraaja blizu 1. Ukoliko neki
dogaaj prouzrokuje makar i neznatno poveanje saobraaja, kanjenja koja iz toga proistiu
mogu biti veoma duga.

Gubitak paketa
U prethodnom razmatranju pretpostavili smo da se u redu moe nalaziti beskonano mnogo
paketa. U stvarnosti red koji prethodi izlaznom linku ima ogranien kapacitet, u zavisnosti od
dizajna i cene komutatora. S obzirom na to daje kapacitet reda konaan, u stvarnosti, kanjenje
paketa se ne pribliava beskonanosti sa pribliavanjem intenziteta saobraaja vrednosti 1.
Upravo suprotno, moe se dogoditi da pristigli paket naie na popunjen red..Ukoliko nema
mesta za njegovo memorisanje, ruter jednostavno isputa (odbacuje) dati paket; drugim recima,
paket je izgubljen. Iz perspektive krajnjeg sistema, to izgleda kao da je paket emitovan u jezgro
mree, ali se nije pojavio na svom odreditu. Procenat izgubljenih paketa poveava se sa
poveanjem intenziteta saobraaja. Prema tome, performanse odreenog vora mere se, ne
samo duinom kanjenja, ve i verovatnoom gubljenja paketa. Kao to ete videti u
poglavljima koja slede, izgubljeni paketi mogu da se emituju ponovo, za ta su zadueni ili
aplikacija ili protokol transportnog sloja.
Kanjenje na putu sa kraja na kraj mree
Sve do sada razmiljali smo samo o kanjenju na nivou vora, odnosno najednom ruteru.
Upravo zato emo nau priu o razliitim vidovima kanjenja zavriti kratkim razmatranjem
ukupnog kanjenja od izvora do odredita. Da biste lake stekli predstavu o ovom konceptu,
pretpostaviemo da izmeu izvornog i odredinog raunara postoji A'-l rutera. Takoe emo
pretpostaviti da u mrei nema zaguenja (kanjenja usled stajanja u redu su zanemarljiva), zatim
da kanjenje usled obrade na svakom ruteru iznosi dobraa, da brzina kojom svi ruteri i izvomi
raunar prenose informacije iznosi R bitova u sekundi i da je kanjenje usled propagacije na
svakom linku d Dakle, akumuliranjem kanjenja na nivou vorova dobiemo ukupno kanjenje
od jedne do druge krajnje take prenosa.

^kraj-kiaj ~ ^ ôbrado
+
^prenos
+
^pfop)
I u ovom sluaju d Q% = L/R, gde L predstavlja veliinu paketa. Uoptavanje ove formule za
sluaj heterogenih kanjenja na vorovima i za postojanje prosenog kanjenja usled stajanja u
redu ostaviemo vama.
1.6.3 Kanjenja i rute na Internetu
Za sticanje konkretnije slike o kanjenju u raunarskim mreama moe da poslui dijagnostiki
program Traceroute, Re je o jednostavnom programu koji se moe izvravati na svakom
raunani koji je deo Interneta. Kada korisnik navede ime odredinog raunara, program u
izvornom raunaru odmah ka njemu alje niz posebnih paketa. Putujui ka svom odreditu ovi
paketi prolaze kroz seriju rutera. im primi neki od ovih posebnih paketa, ruter odmah alje
kratku poniku izvornom raunaru u kojoj su najee navedeni njegovo ime i adresa.
Konkretno, ponovo emo pretpostaviti da izmeu izvornog i odredinog raunara postoji
AM rutera. Izvorni raunar u mreu alje W posebnih paketa od kojih je svaki adresiran na
konano odredite. Ovi paketi su obeleeni brojevima od 1 do N, tako da prvi paket nosi broj 1,
a poslednji N. Kada -ti ruter primi n-ti paket, on taj paket unitava'i alje poruku izvornom
raunaru. Kada odredini raunar primi A^-ti paket on ga takoe unitava i takoe alje poruku
izvornom raunaru. Od trenutka kada poalje pakete, izvorni raunar meri vreme do prijema
odgovarajuih poruka, beleei i ime i adresu rutera (ili odredinog raunara) od koga je poruka
stigla. Na ovaj nain, izvorni raunar moe da rekonstruie rutu kojom paketi putuju od izvora
do odredita, i da odredi kanjenja na povratnim putevima do svih rutera koji uestvuju u
prenosu. Program Traceroute ponavlja opisani eksperiment tri puta, tako da izvomi raunar ka
odredinom, u stvari, alje 3-N paketa. Program Traceroute detaljno je opisan u dokumentu RFC
1393.
Evo jednog primera rezultata programa Traceroute u kome je trasirana ruta izmeu
izvornog raunara gaia.cs.umass.edu (na Univerzitetu Masausets) i odredinog raunara
cis.poly.edu (na Politehnikom univerzitetu u Bruklinu). Ovaj listing

1.7 SLOJEVI PROTOKOLA I NJIHOVI MODELI USLUGA 34 34 34 34

ima est kolona. Prvu kolonu ini vrednost rt koju smo upravo opisali i koja predstavlja broj
rutera na datoj ruti. U drugoj koloni navedeno je ime rutera, a u treoj njegova adresa (u formi
xxx.xxx.xxx.xxx). Poslednje tri kolone predstavljaju kanjenja povratnih puteva za tri
eksperimenta. Ukoliko (usled gubitka paketa) primi manje od tri poruke od svakog rutera na
putanji, program Traceroute postavlja zvezdicu odmah iza broja rutera i za dati ruter
prijavljuje manje od tri vremena odziva.
1 cs-gw (128.119.240.254) 1.009 ms 0.899 ms 0.993 ms
2 128.119.3.151 (128.119.3.154) 0.931 ms 0.441 ms 0.651 ms
3 border4~rt-gi-l-3.gw.umass.edu (128.119.2.194) i.032 ms 0.484 ms 0.4S1 ms
4 acrl-ge-2-l-0.Boston.cw.net (208.172.51.129) 10.006 ms 8.150 ms 8.460 ms
5 agr4-loopback,NewYork.cw.net (206.24.194.104) 12.272 ms 14.344 ms 13.267 ms
6 acr2-loopback.NewYork.cw.net (206.24.194.62) 13.225 ms 12.292 ms 12.148 ms
1 poslO-2.core2.NewYockl.Level3.net (209.244.160.133) 12.218 ms 11.823 ms 11.793 ms
8 gige9-l-52.hsipaccessl.NewYorkl.Level3.net (64.159.17.39) 13.081 ms 11.556 ms 13.297 ms
9 pO-0.polyu.bbnplanet.net (4.25.109.122) 12,116 ms 13.052 ms 12.786 ms
10 cis.poly.edu (128.238.32.126) 14.080 ms 13.035 ms 12.802 ms

U trasi koja je prikazana ovim listingom, postoji 9 rutera izmeu izvora i odredita.
Veina ovih rutera ima ime i svi imaju adrese. Na primer, ime rutera 3 je border4-rt-gi-l-3 . gw
. umass . edu, a njegova adresa je 128.11-9.2.194. Gledajui podatke koje je ovaj ruter poslao
vidimo da je kanjenje na povratnom putu u prvom od tri pokuaja bilo 1,03 msec. Kanjenje
na povratnom putu za sledea dva pokuaja iznosilo je 0,48 i 0,45 msec. Ova kanjenja
obuhvataju sva ve pomenuta kanjenja - kanjenje usled prenosa, kanjenje usled propagacije,
kanjenje usled obrade u ruteru i kanjenje usled stajanja u redu. S obzirom na to da kanjenje
usled stajanja u redu varira, kanjenje na povratnom putu za paket n koji je poslat ruteru n
moe biti due od istog tog kanjenja za paket n+1 na ruteru n+1. U vezi sa tim, skreemo vam
panju na to da su kanjenja u ruteru 6 vea od kanjenja u ruteru 7. Ovo je posledica samog
postupka merenja, bez obzira na injenicu da svaki paket upuen ruteru 7 mora da proe i kroz
ruter 6.
Ukoliko elite da i sami isprobate program Traceroute, preporuujemo vam da posetite
veb lokaciju http://www.traceroute.org na kojoj ete pronai iscrpnu listu izvora za trasiranje
ruta. Dovoljno je da izaberete izvor i upiete ime bilo kog odredinog raunara, a program
Traceroute e uiniti ostalo.

1.7 Slojevi protokola i modeli njihovih usluga
Iz dosadanjeg izlaganja oigledno je daje Internet Izuzetno sloen sistem. Kao to ste videli,
on se sastoji iz mnotva sastavnih delova - brojnih aplikacija i protokola, raznih tipova krajnjih
sistema i veza izmeu njih, zatim rutera, kao i razliitih tipova
medijuma koji se koriste kao linkovi. Imajui u vidu ovu izuzetnu sloenost, postavlja se pitanje
da lije uopte mogue zamisliti njegovu mrenu arhitekturu i da lije to mogue uiniti u ovoj
knjizi. Sreom, odgovor na oba ova pitanja je potvrdan.
1.7.1 Slojevita arhitektura
Pre nego to pokuamo da zamislimo arhitekturu Interneta, napraviemo jo jednu analogiju sa
svetom koji nas okruuje. U stvari, mi u svakodnevnom ivotu praktino sve vreme imamo posla
sa veoma sloenim sistemima. Zamislite, primera radi, da neko od vas zatrai da opiete sistem
avionskog prevoza. Kako biste osmislili strukturu koja bi mogla da opie ovaj izuzetno sloeni
sistem, koji obuhvata prodaju karata, proveru prtljaga, osoblje na terminalima, pilote, same
avione, kontrolu leta i svetski sistem za usmeravanje aviona? Jedan od naina za opisivanje ovog
sistema bio bi da pokuate da opiete sve to treba da uinite (ili to drugi treba da uine za vas)
prilikom putovanja avionom. Dakle, najpre kupujete kartu, zatim proveravate prtljag, odlazite na
odreeni izlaz i konano se ukrcavate u avion. Avion uzlee i zatim se usmerava ka svom
odreditu. Kada sleti, vi se iskrcavate, opet prolazite kroz terminal i podiete svoj prtljag.
Ukoliko je let bio neprijatan, aliete se agentu od koga ste kupili kartu. Ovaj scenario opisan je
na slici 1.15.
Pretpostavljamo da ve uoavate neke slinosti sa raunarskim mreama - avion vas
prevozi od mesta iz koga polazite do eljene destinacije; paket se prenosi od izvornog do
odredinog raunara na Internetu. Ipak ovo nije ba ona analogija koju traimo. Nama je
potrebna odreena struktura i nju emo potraiti na slici 1.15. Skreemo vam panju na to da na
oba kraja linije postoji funkcija u vezi sa kartama; osim toga postoji i funkcija za prtljag putnika
koji su kupili karte, kao i funkcija

1.7 SLOJEVI PROTOKOLA I NJIHOVI MODELI USLUGA 47 47 47 47

izlaza za putnike sa kupljenom kartom i predatim prtljagom. Za putnike koji su proli kroz izlaz
(kupili su kartu, predali prtljag i proli kroz izlaz) ostale su jo funkcije uzletanja i sletanja, a
tokom trajanja leta i funkcija usmeravanja aviona. Iz ovoga sledi da funkcije sa slike 1.15 mogu
da se posmatraju u smislu horizontalne povezanosti, kao to je to i prikazano na slici 1.16.
Na slici 1.16, funkcije avionskog prevoza podelili smo na slojeve i na taj nain dobili
globalni okvir unutar kojeg moemo razgovarati o avionskom prevozu. Skreemo vam panju
na to da svaki sloj, u kombinaciji sa slojevima koji se nalaze ispod njega, obezbeduje neku
funkcionalnost, odnosno neku uslugu. Na sloju prodaje karata i niim slojevima, obavlja se
transfer putnika od aerodroma do aerodroma. Na sloju koji se bavi prtljagom i niim slojevima,
odvija se transfer putnika i njihovog prtljaga, od provere do preuzimanja prtljaga. Skreemo
vam panju na injenicu da sloj zaduen za prtljag svoje usluge prua samo putnicima koji su
ve kupili kartu. Na sloju izlaza, obavlja se transfer putnika i njihovog prtljaga, od odlaznog
terminala do dolaznog terminala, dok se na sloju uzletanja i sletanja obavlja transfer putnika i
njihovog prtljaga od jedne piste do druge. Svaki sloj obezbeduje svoje usluge (1) izvravanjem
odreenih akcija u okviru tog sloja (primera radi, na sloju terminala vri se ukrcavanje ljudi u
avion i iskrcavanje iz njega) i (2) korienjem usluga koje se nalaze u slojuispod njega (sloj
terminala koristi uslugu transfera putnika od piste do piste koji pripada sloju uzletanja i
sletanja).
Kao to smo ve rekli, slojevita arhitektura omoguava izdvajanje pojedinih dobro
defmisanih segmenata iz velikog i sloenog sistema. Pojednostavljenje koje se na taj nain
postie sasvim je konkretno i znaajno. Osim toga, kada sistem ima slojevitu strukturu mnogo
je lake izmeniti implementaciju usluga koje odreeni sloj obezbeduje. Sve dok neki sloj
obezbeduje usluge koje prua i sloj iznad njega i koristi usluge iz sloja koji je ispod njega,
izmena njegove implementacije ne odraava se na ostatak sistema. (Skreemo vam panju na to
da se izmena implementacije usluge znaajno razlikuje od izmene same usluge.) Ukoliko,
primera radi, izmenimo nain rada terminala (recimo, tako da se ljudi ukrcavaju i iskrcavaju po
visini), to se nee odraziti na ostatak sistema avionskog prevoza zato to izlaz i dalje prua
neizmenjenu funkciju (ukrcavanje i iskrcavanje putnika); ona se samo implementira malo
drugaije. U velikim i sloenim sistemima koji se neprekidno auriraju, slojevitost donosi jo
jednu prednost, a to je mogunost izmene implementacije usluge bezposledica po ostale
komponente sistema.

Slojevitost protokola
Poto smo se dovoljno pozabavili avionskim prevozom, okrenimo se sada mrenim
protokolima. U cilju smanjenja sloenosti dizajna, mreni dizajneri organizuju protokole - ali i
mreni hardver i softver koji te protokole implementira - u slojeve. U slojevitoj arhitekturi
protokola svaki protokol pripada jednom sloju, isto kao to svaka funkcija avionskog prevoza
prikazanog na slici 1.16 takode pripada nekom
sloju. I u ovom sluaju zanimaju nas usluge koje odreeni sloj prua slojevima koji se nalaze
iznad njega - takozvani usluni model sloja. Ba kao i u primeru sa avionskim prevozom, svaki
sloj prua svoje usluge (1) izvravanjem odreenih radnji i (2) korienjem usluga sloja koji sc
nalazi direktno ispod njega. Na primer, pod uslugom koju obezbeduje sloj n mogla bi da se
podrazumeva pouzdana dostava poruka sa jednog kraja mree na drugi. Ova usluga mogla bi da
se implementira korienjem usluge za nepouzdanu dostavu poruka sa kraja na kraj sloja -1 i
dodavanjem funkcionalnosti za prepoznavanje i ponovno emitovanje izgubljenih poruka sloju n.
Sloj protokola moe da se implementira u softveru, hardveru ili kombinaciji ova dva
okruenja. Protokoli aplikacijskog sloja kao to su, na primer, HTTP i SMTP gotovo uvek su
implementirani u softveru krajnjih sistema; isti je sluaj i sa protokolima transportnog sloja. S
obzirom na to da su fiziki sloj i sloj veze podataka odgovorni za rukovanje komunikacijom
preko konkretnog linka, oni se obino implementiraju u kartici mrenog interfejsa (na primer,
kartice Ethernet ili Wi-Fi) koja je povezana sa datim linkom. Mreni sloj obino se
implementira kombino-vano - i u hardveru i u softveru. Skreemo vam panju i na to da se,
poput funkcija slojevitog avionskog prevoza koje su distribuirane izmeu raznih aerodroma i
centara za kontrolu leta od kojih se sastoji ceo ovaj sistem, protokol sloja n takoe distribuira
izmeu krajnjih sistema, komutatora paketa i ostalih komponenti koje ine mreu. To znai da
se u svakoj od ovih mrenih komponenti esto nalazi i deo protokola sloja n.
Kada se posmatraju u celini, protokoli svih slojeva zajedno nazivaju se familija protokola.
Familija Internet protokola sastoji se od pet slojeva i to su: fiziki sloj, sloj veze podataka,
mreni sloj, transportni sloj i aplikacijski sloj (slika 1.17).

1.7 - SLOJEVI PROTOKOLA I NJIHOVI MODELI USLUGA 36 36 36 36

Aplikacijski sloj
U aplikacijskom sloju nalaze se mrene aplikacije i njihovi protokoli aplikacijskog sloja. U
Internetovom aplikacijskom sloju ima mnogo razliitih protokola kao to su protokoli HTTP
(podrka za zahtevanje i transfer veb strana), SMTP (podrka za transfer elektronske pole) i
FTP (podrka transfera datoteka izmeu dva krajnja sistema). Pored toga, videete i da se
odreene mrene funkcije kao stoje, na primer, prevoenje ljudima razumljivih Internet imena
krajnjih sistema (recimo, gaia. cs.umass.edu) u 32-bitne mrene adrese, takoe izvravaju
pomou protokola aplikacijskog sloja, DNS-a (sistema imena domena). U poglavlju 2 videete
daje veoma Iako napraviti i sopstvene nove protokole aplikacijskog sloja.
Podseamo vas na definiciju protokola iz odeljka 1.1, kada smo rekli da distribuirani
entiteti koji implementiraju neki protokol izmeu sebe razmenjuju poruke. U ovoj knjizi emo
te vrste poruka nazivati porukama aplikacijskog sloja.

Transportni sloj
Transportni sloj obezbeduje usluge transporta poruka aplikacijskog sloja izmeu klijentske i
serverske strane aplikacije. Na Internetu postoje dva transportna protokola - TCP i UDP i oba
mogu da transportuju poruke aplikacijskog sloja. Protokol TCP svojim aplikacijama obezbeduje
uslugu sa konekcijom. Ova usluga podrazumeva garantovanu isporuku poruka aplikacijskog
sloja do odredita i kontrolu toka (usa-glaavanje brzina poiljaoca i primaoca). Pored toga,
protokol TCP segmentira duge poruke na krae segmente i obezbeduje mehanizme za kontrolu
zaguenja tako to izvor smanjuje brzinu prenosa u periodima zaguenja mree. Nasuprot tome,
protokol UDP svojim aplikacijama obezbeduje uslugu bez konekcije koja je (kao to ste videli
u odeljku 1.2), u velikoj meri, usluga bez suvinih detalja. Pakete transportnog sloja emo u
ovoj knjizi nazivati segmentima.
Mreni sloj
Mreni sloj odgovoran je za rutiranje paketa mrenog sloja - datagrama od jednog raunara do
drugog. Intemetski protokol transportnog sloja (TCP ili UDP) izvornog raunara prosleuje
segment transportnog sloja i odredinu adresu mrenom sloju, na isti nain kao to mi
potanskoj slubi predajemo pismo sa njegovom odredinom adresom. Nakon toga, o isporuci
segmenta transportnom sloju odredinog raunara brine mreni sloj.
Intemetski mreni sloj ima dve osnovne komponente. Prva komponenta je protokol koji
definie polja u datagramu, kao i nain reagovanja krajnjih sistema i rutera na sadraj ovih polja.
Re je o uvenom protokolu IP. Postoji samo jedan protokol IP i sve intemetske komponente
koje imaju mreni sloj moraju da ga koriste. Mreni sloj takoe sadri protokole za rutiranje koji
odreuju rute kojima se datagrami kreu od izvora do odredita. Na Internetu ima mnogo
protokola za rutiranje. Kao to smo rekli u odeljku 1.5, Internet predstavlja mreu svih mrea, a
u okviru svoje mree administrator ima slobodu korienja bilo kog protokola za rutiranje. Iako
se u mrenom sloju nalaze i protokol IP i brojni protokoli za rutiranje, on se esto naziva samo
IP sloj, to govori o injenici daje protokol IP komponenta koja ceo Internet dri na okupu.

Sloj veze podataka
Mreni sloj rutira datagram kroz seriju komutatora paketa (na Internetu se nazivaju ruterima)
koji se nalaze izmeu izvora i odredita. Da bi mogao da prenese paket od jednog vora
(raunara ili komutatora paketa) do prvog sledeeg, mreni sloj mora da se osloni na uslugu sloja
veze podataka. Konkretno, na svakom voru mreni sloj predaje datagram nanie sloju veze
podataka, koji treba da ga isporui sledeem voru na putanji (ruti). Na tom sledeem voru sloj
veze podataka predaje datagram navie, mrenom sloju.
Usluge koje obezbeduje sloj veze podataka zavise od konkretnog protokola veze podataka
koji je primenjen na datom linku. Primera radi, neki protokoli obezbeuju pouzdanu isporuku na
nivou linka, odnosno od emitujueg vora, kroz link, do prijemnog vora. Skreemo vam panju
na to da se ova usluga pouzdane isporuke razlikuje od jednog krajnjeg sistema do drugog. U
primere sloja veze podataka spadaju Ethernet i PPP. S obzirom na to da datagrami na svom putu
od izvornog do odredinog raunara moraju da prou kroz nekoliko'linkova, njima u razliitim
linkovima mogu da rukuju razliiti protokoli sloja veze podataka. Recimo, u jednom linku
datagramom moe da rukuje Ethernet, a ve u sledeem protokol PPP. Mreni sloj od svakog
protokola sloja veze podataka moe da dobije razliite usluge. U ovoj knjizi pakete sloja veze
podataka nazivaemo okvirima.

1.7 SLOJEVI PROTOKOLA I NJIHOVI MODELI U5LUGA 37 37 37 37

Fiziki sloj
Dok je sloj veze podataka zaduen za prenoenje celih okvira od jednog mrenog elementa do
drugog, posao" fizikog sloja jeste prenoenje pojedinanih bitova istih tih okvira izmeu
susednih vorova. Protokoli ovog sloja zavise od sloja veze podataka, ali i od samog prenosnog
medijuma linka (bakarni kablovi sa upredenim paricama, monomodna optika vlakna). Primera
radi, standard Ethernet ima mnogo protokola fizikog sloja - jedan za bakarne kablove sa
upredenim paricama, drugi za koaksijalne kablove, trei za optike kablove, itd. U svakom
konkretnom sluaju pojedinani bit se prenosi kroz link na drugaiji nain.
Ukoliko prelistate sadraj, uoiete da je ova knjiga organizovana upravo kori-enjem
slojeva familije Internet protokola. Pri tom smo se opredelili za pristup od vrha ka dnu,
odnosno od aplikacijskog sloja nanie.
1.7.2 Slojevi, poruke, segmenti, datagrami i okviri
Na slici 1.18 prikazana je stvarna fizika putanja kojom se podaci kreu nanie kroz familiju
protokola predajnog sistema, navie i nanie kroz familije protokola posredujueg komutatora
sloja veze podataka ili rutera i zatim navie kroz familiju protokola prijemnog sistema. Kao to
ete videti u nastavku knjige, i ruteri i komutatori sloja veze podataka pripadaju komutatorima
paketa. Poput krajnjih sistema, i kod njih je hardver i softver za umreavanje slojevito
organizovan. Meutim, kod rutera i komutatora sloja veze ne implementiraju se svi slojevi
familije protokola; obino se na njima implementiraju samo donji slojevi. Kao to moete da
vidite na slici 1.18, komutatori sloja veze implementiraju slojeve 1 i 2, a ruteri slojeve od 1 do 3.
To, primera radi, znai da internetski ruteri mogu da implementiraju protokol IP (protokol treeg
sloja), a da komutatori sloja veze podataka to ne mogu. Neto kasnije videete da, iako ne
prepoznaju IP adrese, komutatori sloja veze mogu da prepoznaju adrese drugog sloja kao to su,
recimo, Ethemet adrese. Podvlaimo injenicu da krajnji sistemi implementiraju svih pet
slojeva, to potvruje konstataciju daje periferija Interneta previe sloena,
Na slici 1.18 ilustrovan je i veoma vaan koncept enkapsulacije. U predajnom raunaru
poruka aplikacijskog sloja (M na slici 1.18) predaje se transportnom sloju. U
najjednostavnijem scenariju transportni sloj preuzima poruku i dodaje joj dopunske informacije
(informacije zaglavlja transportnog sloja; Ht na slici 1.18) koje su namenjene prijemnoj strani
transportnog sloja. Poruka aplikacijskog sloja i zaglavlje transportnog sloja zajedno ine
segment transportnog sloja. Segment transportnog sloja, prema tome, enkapsulira poruku
aplikacijskog sloja. Meu dodatnim informacijama mogu se nalaziti informacije na osnovu kojih
prijemna strana transportnog sloja isporuuje ovu poruku odgovarajuoj aplikaciji, i mogu se
nalaziti bitovi za prepoznavanje greaka koji prijemnoj strani omoguavaju da ustanovi da li su
bitovi poruke usput promenjeni. Transportni sloj zatim prosleuje segment mrenom sloju, koji
ovom segmentu dodaje svoje zaglavlje (Hn na slici 1.18) sa podacima kao to su, na primer,
adrese izvornog i odredinog sistema, formirajui
na taj nain dntagram mrenog sloja. Ovaj datagram se zatim prosleuje sloju veze podataka
koji mu sada dodaje svoje zaglavlje i pravi okvir sloja veze podataka.
Ovaj koncept emo vam dodatno ilustrovati korienjem analogije sa internim dopisom u
firmi koji se alje javnom potanskom slubom. Sam dopis predstavlja poruku aplikacijskog
sloja. On se stavlja u odgovarajui koveral na ijoj su prednjoj strani ispisani ime i odeljenje
primaoca. Ova informacija slui arhivi u zgradi prijemne kancelarije da primljeni dopis isporui
onome kome je poslat. Koverat za interni dopis koji sadri zaglavlje (ime i odeljenje primaoca) i
enkapsulira poruku aplikacijskog sloja (dopis), mogao bi da se poistoveti sa segmentom
transportnog sloja. Arhiva predajne sirane uzima ovaj dopis i stavlja ga u koverat koji je
podesan za prenos kroz javnu potansku slubu, upisuje potansku adresu predajne i prijemne
strane i dodaje marku. Ovaj potanski koverat odgovara datagramu - on enkapsulira segment
transportnog sloja (koverat za slanje dopisa i sam sadraj) koji enkapsulira originalnu poruku
(dopis). Arhiva predajne strane isporuuje koverat arhivi prijemne strane koja otvara koverat i iz
njega vadi koverat za interni dopis, koji se, zatim, prosleuje primaocu koji otvara ovaj drugi
koverat i iz njega vadi sam dopis.
Proces enkapsuliranja moe biti i sloeniji od ovog koji smo upravo opisali. Primera radi,
neka velika poruka moe da se podeli na vie segmenata transportnog

38 38 38 38 POGLAVLJE V RAUNARSKE MREE I INTERNET
1.8 ISTORIJSKI PREGLED UMREAVANJA I INTERNETA 53 53 53 53

sloja (koji dalje mogu da se podele na vie datagrama mrenog sloja). Na prijemnoj strani, takav
segment bi onda morao da se rekonstruie od datagrama na koje je razbijen.
1.8 Istorijski pregled umreavanja i Interneta
U odeljcima od 1.1 do 1.7 napravili smo prikaz tehnologija raunarskih mrea i Interneta. Iz
njega ste mogli da nauite dovoljno da biste impresionirali porodicu i prijatelje. Meutim,
ukoliko elite da zaista zadivite nekoga svojim znanjem, proitajte paljivo deo koji sledi, u
kome smo pokuali da prikaemo fascinantnu istoriju Interneta.

1.8.1 Razvoj komutiranja paketa: 1961 - 1972
Koreni raunarskih mrea i dananjeg Interneta mogu se pratiti sve do poetka 1960-ih kada je
telefonska mrea bila dominantna svetska komunikaciona mrea. Podseamo vas da smo u
odeljku 1.3 rekli da se u telefonskim mreama za prenos informacija od poiljaoca do primaoca
koristi komutiranje vodova - to predstavlja adekvatan izbor s obzirom na to da se glas od jedne
do druge krajnje take prenosi konstantnom brzinom. Imajui u vidu sve vei znaaj (i cenu)
raunara u to vreme, kao i pronalazak raunara sa deobom vremena, bilo je sasvim prirodno (ili
bar to tako izgleda iz dananje perspektive) razmiljati o nainima njihovog povezivanja kako bi
mogli da ih koriste korisnici na razliitim geografskim lokacijama. Saobraaj koji bi generisali
takvi korisnici imao bi karakteristike naleta" - intervali aktivnosti kao stoje, na primer, slanje
komande udaljenom raunaru, bili bi praeni intervalima neaktivnosti u ekanju na odgovor ili
razmiljanju o primljenom odgovoru.
Tri istraivake grupe u razliitim delovima sveta, potpuno nezavisno jedna od druge
[Leiner 1998], dole su do tehnologije komutiranja paketa kao efikasne alternative za
komutiranje vodova. Prvi objavljen rad o tehnikama komutiranja paketa bio je rad Leonarda
Klajnroka [Kleinrock 1961; Kleinrock 1964], u to vreme studenta postdiplomca na MIT-u.
Koristei teoriju stvaranja redova, Klajnrok je u svom radu elegantno demonstrirao efikasnost
pristupa sa komutiranjem paketa i njegovu primerenost situacijama sa naletima saobraaja.
Godine 1964. Pol Baran'[Baran 1964] iz Instituta Rand zapoeo je istraivanje o korienju
komutiranja paketa za bezbedan prenos glasa u vojnim mreama. Istovremeno, Donald Dejvis i
Roder Skantlberi iz Nacionalne fizike laboratorije u Velikoj Britaniji razvijali su vlastite ideje
o komutiranju paketa.
Istraivakim radom ove tri grupe postavljeni su temelji dananjeg Interneta. Ali, Internet
ima i dugu istoriju praktinog pristupa iji poeci takoe seu u rane 1960. godine. J. C. R.
Liklider [DEC 1990] i Lorens Roberts, inae obojica Klaj-
nrokove kolege na MIT-u, pokrenuli su istraivaki program u okviru Agencije za napredne
istraivake projekte (Advanced Research Project Agency, ARPA). Roberts je objavio sveukupni
plan za tzv. ARPAnet [Roberts 1967], prvu raunarsku mreu sa komutiranjem paketa, koja je
direktan predak savremenog Interneta. Prvi komutatori paketa bili su poznati pod nazivom
procesori interfejsnih poruka (Interface Message Processor, IMP), a ugovor za pravljenje ovih
komutatora dobila je kompanija BBN. Za Praznik rada 1969. godine, pod supervizijom Leonarda
Klajnroka, na Univerzitetu UCLA, instaliranje prvi IMP komutator. Nedugo zatim, instalirana su
jo tri IMP komutatora - u Istraivakom institutu Stanford (SRI), na Univerzitetu Santa Barbara
i na Univerzitetu Juta (slika 1.19). Ovaj predak Interneta je tako krajem 1969. godine imao
ukupno etiri vora. Prema Klajnrokovim recima, prva upotreba mree u cilju daljinskog
prijavljivanja iz Univerziteta UCLA na Institutu SRJ dovela je do pada sistema [Kleinrock
2004].
Do 1972. godine mrea ARPAnet se proirila na otprilike 15 vorova i imala prvu javnu
demonstraciju koju je izveo Robert Kan na Meunarodnoj konferenciji o raunarskim
komunikacijama (International Conference on Computer Communi-cation). Tada je zavren i
prvi protokol od raunara do raunara za komunikaciju izmeu krajnjih sistema ARPAneta
[RFC 001], po imenu NCP (Network Control Protocol). Sa uspostavljanjem protokola koji je
mogao da spoji krajnje korisnike, moglo se otpoeti sa pisanjem aplikacija, tako da je Rej
Tomlinson iz kompanije BBN prvi program za elektronsku potu napisao ve 1972. godine.

1.8.2 Specijalne mree i meusobno povezivanje mrea: . 1972- 1980
Inicijalni ARPAnet predstavljao je zaokruenu i zatvorenu mreu. Da bi mogao da komunicira
sa ARPAnet raunarom, korisnik je morao da se povee sa IMP komu-tatorom ove mree. U
ranim i srednjim 1970-im pojavile su se i dodatne mree sa komutiranjem paketa:
ALOHAnet - mikrotalasna mrea koja je povezivala univerzitete na Havajskim ostrvima
[Abramson 1970], kao i paketne satelitske [RFC 829] i paketne radio mree [Kahn 1978]
agencije DARPA.
Telenet - komercijalna mrea sa komutiranjem paketa kompanije BBN koja se zasnivala na
ARPAnet tehnologiji.
Cyclades - francuska mrea sa komutiranjem paketa koju je osmislio Luj Puzan [Think
2002].
Mree sa deobom vremena kao to su, recimo, Tvmnet ili mrea kompanije GE Information
Services kasnih 1960-ih i ranih 1970-ih [Schwartz 1977].
IBM-ova mrea SNA (1969-1974), takoe uraena po uzoru na ARPAnet [Schvvartz 1977].

54 54 54 54 POGLAVLJE 1 RAUNARSKE MREE i INTERNET
1.8 ISTORIJ5KI PREGLED UMREAVANJA I INTERNETA 39 39 39 39

Slika 1.19 4 Slika 1.19 4 Slika 1.19 4 Slika 1.19 4 Prvi procesor interfejsnih poruka (1MP) i L. Klajrtrok (Mork j. Teril, AP/Wide
VVorld Phofos)

Broj mrea nezadrivo se poveavao. Opel iz perspektive sadanjeg iskustva, moglo bi se rei
daje upravo tada sazreo trenutak za razvijanje arhitekture koja bi obuhvatila sve ove mree.
Pionirski rad na temu meusobnog povezivanja mrea, opet pod sponzorstvom agencije
DARPA (Defense Advanced Research Projects Agencv), obavili su Vinton Serf i Robert Kan
[Cerf 1974]; za opisivanje povezivanja mrea upotrebljen je termin internetnng.
Ovi arhitektonski principi ugraeni su u protokol TCP. Meutim, prve verzije protokola
TCP bitno su se razlikovale od dananje verzije ovog protokola. U tim prvim verzijama,
pouzdana, sekvencijalna isporuka podataka putem ponovnog pre-
nosa krajnjeg sistema (i dalje je deo protokola TCP) kombinovana je sa funkcijama za
prosledivanje (to danas ini protokol IP). Prvi eksperimenti sa protokolom TCP, kao i
sagledavanje znaaja koji za aplikacije ima transportna usluga nepouzdanog prenosa s kraja na
kraj bez kontrole toka (kao Stoje to sluaj sa paketiranjem glasa), doveli su do izdvajanja
protokola IP iz protokola TCP, kao i do pojave protokola UDP. Tri kljuna protokola
savremenog Interneta - TCP, UDP i IP - konceptualno su definisana krajem 1970-ih.
Osim istraivanja koje je sprovodita DARPA, odvijale su se i mnoge druge vane
aktivnosti u vezi sa mreama. Na Havajima, Norman Abramson razvijao je
ALOHAnet-radio-mreu zasnovanu na paketima, koja je omoguavala meusobnu
komunikaciju udaljenih lokacija na Havajskim ostrvima. Protokol ALOHA [Abramson 1970]
bio je prvi protokol za tzv. viestruki pristup koji je omoguio da korisnici sa razliitih lokacija
zajedniki koriste isti medijum za komunikaciju difuznom emisijom (radio-frekvencija).
Abramsonov rad na protokolu za viestruki pristup nastavili su Metkalf i Bogs, i razvili protokol
Ethernet [Metcalfe 1976] namenjen kablovskim mreama sa zajednikom difuznom emisijom
(slika 1.20). Veoma zanimljivo jeste to da je pravljenje ovog protokola bilo motivisano
potrebom povezivanja veeg broja raunara, tampaa i zajednikih diskova [Perkins 1994].
Dakle, pre vie od 25 godina, znatno pre revolucije personalnih raunara i eksplozije mrea,
Metkalf i Bigs postavili su temelje dananjih LAN-ova. Tehnologijom Ethernet napravljen je
veoma znaajan korak i u smislu povezivanja mrea. Svaki Ethernet LAN predstavljao je
zaokruenu mreu, a kako je broj ovakvih mrea rastao, rasla je i potreba za njihovim
meusobnim povezivanjem. U poglavlju 5 detaljnije emo se bavili tehnologijama Ethernet,
ALOHA i mnogim drugim LAN tehnologijama.

56 56 56 56 POGLAVLJE 1 RAUNARSKE MREE I INTERNET 1.8 ISTORIJSKI PREGLED UMREAVANJA I INTERNETA 40 40 40 40

1.8.3 Veliki porast broja mrea: 1980 - 1990
Do kraja 1970-ih sa ARPAnetom je bilo povezano oko 200 matinih raunara. Svega desetak
godina kasnije, krajem 1980-ih, broj raunara povezanih sa javnim Internetom - konfederacijom
mrea u kojoj se nazirao dananji Internet - dostigao je 100 000, Dakle, 1980. oznaavaju
period intenzivnog razvoja pojave umreavanja.
Dobar deo te ekspanzije umreavanja poetkom ove decenije proistekao je iz odvojenih
nastojanja da se oforme raunarske mree koje bi povezivale univerzitete. Tako je mrea
BITNET omoguila razmenu elektronske pote i transfer datoteka izmeu univerziteta u
severoistonom delu SAD. Mrea CSNET (Computer Science Network) napravljena je sa ciljem
povezivanja univerzitetskih istraivaa koji nisu imali pristup ARPAnetu. Godine 1986.
napravljena je i mrea NSFNET koja je omoguavala pristup superraunarskim centrima pod
sponzorstvom kompanije NSF. Okosnica ove mree, ija je brzina na poetku iznosila 56 kb/s,
a krajem decenije ve 1,5 Mb/s, posluila je kao okosnica za povezivanje veeg broja
regionalnih mrea.
Istovremeno, u ARPAnet zajednici mnogi elementi arhitekture dananjeg Interneta su
lagano zauzimali svoje mesto. Prvog januara 1983. godine zvanino je puten u rad protokol
TCP/IP koji je time postao standardni protokol ove mree (zamenivi protokol NCP). Prelazak
[RFC 801] sa protokola NCP na protokol TCP/IP predstavljao je svojevrstan tafetni" dogaaj
- tog dana svi raunari ove mree morali su da se prebace na protokol TCP/IP. Krajem 1980-ih
nainjena su proirenja ovog protokola kojima su u njega implementirani mehanizmi kontrole
zaguenja na strani raunara [Jacobson 1988]. Veoma brzo razvijen je i sistem imena domena
(Doma'm Name Svstem, DNS) koji je omoguio preslikavanje izmeu ljudima razumljivih
Internet imena i odgovarajuih 32-bitnili IP adresa [RFC 1034].
Uporedo sa razvojem ARPAneta (koji je predstavljao glavninu napora ove vrste u SAD),
poetkom 1980-ih u Francuskoj je predstavljen projekat Minitel - veoma ambiciozan plan
uvoenja mrea u sve domove. Sistem Minitel, koji je sponzorisala francuska vlada, sastojao se
od javne mree sa komutiranjem paketa (zasnovane na familiji protokola X.25 koja koristi
virtuelna kola), Minitel servera i jeftinih terminala sa ugraenim modemima male brzine. Mrea
Minitel je zabeleila veliki uspeh 1984. godine, kada je francuska vlada besplatno delila Minitel
terminale svim porodicama koje su izrazile elju da ih poseduju. U ovoj mrei postojale su
besplatne (recimo, lokacija sa telefonskim imenikom) i privatne lokacije ije su korienje
korisnici morali da plate. Sredinom 1990-ih, na vrhu svoje popularnosti, mrea Minitel je nudila
vie od 20 000 razliitih usluga - od kunog bankarstva, pa do specija-lizovanih istraivakih
baza podataka. Ovu mreu koristilo je vie od 20 procenata populacije Francuske; ona je
generisala vie od milijarde dolara prihoda godinje i 10 000 radnih mesta. Moglo bi se rei da
se Minitel naao u mnogim francuskim domovima deset godina pre nego to je veina
Amerikanaca ula za Internet.
1.8.4 Eksplozija Interneta: poslednja decenija prolog veka
Ulazak u 1990. godine obeleen je nizom dogaaja koji su simbolizovali kontinuiranu evoluciju
sve prisutnije komercijalizacije Interneta. Mrea ARPAnet, praktino direktan predak Interneta,
prestala je da postoji. Mree MILNET i Defense Data
Network toliko su se razvile tokom 1980-ih da su mogle da prihvate najvei deo saobraaja
amerikog Ministarstva odbrane, dok je mrea NSFNET dobila ulogu mree okosnice koja je
povezivala regionalne mree u SAD i nacionalne prekooke-anske mree. Godine 1991. prestala
su da vae ogranienja u smislu komercijalnog korienja NSFNET-a. Godine 1995. mrea je
prela u ruke komercijalnih posrednika za Internet usluge, koji su tada poeli da upravljaju
saobraajem kroz ovu internetsku okosnicu.
Ipak, glavni dogaaj 1990-ih predstavljala je pojava World Wide \Veba koji je doneo
Internet u domove i firme miliona ljudi irom sveta. Web je posluio i kao platforma koja je
omoguila putanje u rad stotina novih aplikacija kao to su, na primer, onlajn trgovina akcijama
i bankarstvo, protok multimedijalnih usluga u realnom vremenu ili informacione usluge. Kratku
istoriju poetaka Weba moete potraiti u knjizi [W3C 1995].
Sam Web je izmeu 1989. i 1991. godine u istraivakom centru CERN izmislio Tim
Berners-Li [Bemers-Lee 1989] i zasnovao ga na idejama koje su proistekle iz prvih radova o
hipertekstu: Bua iz 1940-ih [Bush 1945] i Teda Nelsona iz 1960-ih [Ziff-Davis 1998].
Bemers-Li i njegovi saradnici su razvili prve verzije HTML-a, HTTP-a, servera i itaa Weba -
inae njegove etiri kljune komponente. Prvobitni CERN-ovi itai imali su samo linijski
interfejs. Krajem 1992. godine u funkciji je bilo ve oko 200 servera i to je bio samo vrh ledenog
brega onoga to je, na tom polju, tek trebalo da se dogodi. U tom trenutku je ve veliki broj
istraivaa razvijao itae sa GUI interfejsima. Medu njima bio je i Mark Andrisen koji je
predvodio programiranje popularnog GUI itaa po imenu Mosaic. Andrisen i njegovi saradnici
su 1993. godine objavili alfa verziju svog itaa, a godine 1994. on i Dim Klark su osnovali
kompaniju Mosaic Communications, iz koje je kasnije nastala kompanija Netscape
Communications Corporation [Cusumano 1998; Cjuittner 1998]. Ve 1995. godine studenti su
koristili itae Mosaic i Netscape za svakodnevno krstarenje Webom. Otprilike u to vreme, male
i velike kompanije su poele da koriste veb servere i onlajn trgovinu. Godine 1996. kompanija
Microsoft je poela da pravi svoje itae, to je oznailo poetak rata izmeu kompanija
Netscape i Microsoft koji je, nekoliko godina kasnije, kompanija Microsoft okonala u svoju
korist [Cusumano 1998].
Druga polovina 1990-ih predstavljala je period izuzetne ekspanzije Interneta, kao i
mnogobrojnih inovacija za koje su zaslune velike korporacije, ali i hiljade malih, koje su pravile
proizvode i usluge za Internet. Nastavljena je evolucija elektronske pote dodavanjem adresara,
mogunosti prilaganja dokumenata, brzih veza i transporta multimedijalnih sadraja u programe
za itanje elektronske pote. Krajem prolog veka Internet je podravao stotine popularnih
aplikacija, meu kojima i etiri enormno popularne'.
elektronsku potu, ukljuujui prilaganje dokumenata i pristup poti na Webu;
Web, ukljuujui pretraivanje Weba i elektronskutrgovinu;
trenutnu razmenu poruka sa kontakt listama" koju je razvio ICQ i
razmenu MP3 datoteka izmeu ravnopravnih korisnika koju je razvio Napster.

REZIME 59 59 59 59

Veoma zanimljivo je i to da su prve dve aplikacije razvili istraivaki timovi, dok su druge dve
delo nekolicine mladih entuzijasta.
Za period izmeu 1995. i 2001. karakteristini su usponi i padovi Interneta u smislu
finansijskih trita. I pre nego to su postale komercijalne kompanije, stotine malih intemetskih
preduzea poelo je da se kotira na berzi. Vrednost mnogih kompanija je procenjena na
milijarde dolara bez ikakvih znaajnih izvora prihoda. Nagli pad intemetskih akcija dogodio se
2000-2001. kada je mnogo preduzea zatvoreno. S druge strane, kompanije kao to su
Microsoft, Cisco, AOL, Yahoo, e-Bay i Ama-zon su ojaale u ovim dogaajima i iz njih i izale
kao pobednici (i pored toga to su vrednosti njihovih akcija takoe pale).
Tokom 1990-ih u istraivanju i razvoju mrea postignut je znaajan napredak na poljima
rutera i rutiranja velike brzine (poglavlje 4) i lokalnih raunarskih mrea (poglavlje 5). Tehnika
zajednica je imala problema sa definisanjem i implementira-njem modela intemetskih usluga za
saobraaj za koji je nuno odvijanje u realnom vremenu, kao to su striming aplikacije
(poglavlje 7). Potreba za bezbednou i upravljanjem Intemetovom infrastrukturom (poglavlja 8
i 9) takoe je izbila u prvi plan zato to su aplikacije za elektronsku trgovinu doivele veliku
ekspanziju, dok je Internet postao centralna komponenta svetske telekomunikacione
infrastrukture.

1.8.5 Aktuelni trendovi
Sfera umreavanja raunara razvija se veoma brzim tempom. Napredak se postie na svim
poljima - u razvoju novih aplikacija, bezbednosti. distribuciji sadraja, Internet telefoniji,
brzinama prenosa u LAN-ovima i brzini rutera. Ipak, tri pojave zasluuju posebnu panju -
irokopojasni kuni pristup Internetu, beini pristup Internetu i P2P umreavanje.
Kao to smo rekli u odeljku 1.4, sve rasprostranjeniji irokopojasni pristup Internetu iz
domova putem kablovskih modema i DSL veza pripremio je teren za nove multimedijalne
aplikacije kao to su, na primer, protok visokokvalitetnog video materijala u realnom vremenu
na zahtev i interaktivne video konferencije visokog kvaliteta. Sve vea prisutnost veoma brzih ()
1 Mb/s i brih) javnih Wi-Fi mrea i pristupa Internetu srednje brzine (brzine od nekoliko
stotina kb/s) mrea za mobilnu telefoniju omoguavaju, ne samo neprekidnu povezanost sa
Internetom, ve i itav niz usluga vezanih za trenutnu lokaciju korisnika. O beinim i
mobilnim mreama govoriemo u poglavlju 6.
Nakon serije napada tipa uskraivanja usluga koji su pogodili neke vane veb servere
krajem 3 990-ih i sve eih napada parazitskim programima (na primer, Blasterom) koji
inficiraju krajnje sisteme i optereuju mree saobraajem, mrena bezbednost postala je
izuzetno znaajna tema. U odgovor na ove napade pojavili su se sistemi za prepoznavanje uljeza
koji na vreme obavetavaju o njihovom prisustvu, zatim mrene barijere koje filtriraju saobraaj
pre nego to ga propuste u mreu, kao i sistemi koji mogu da pronau IP adresu sa koje napadi
potiu. O ovim i mnogim drugim aspektima bezbednosti govoriemo u poglavlju 8.
Poslednja inovacija kojoj emo ovde posvetiti panju jeste pojava P2P umreavanja.
Aplikacije za P2P umreavanje koriste resurse u raunarima korisnika - prostor na disku,
sadraj, CPU i prisustvo samog korisnika - i ima znaajnu autonomiju u odnosu na centralne
servere. Raunari (ravnopravnih) korisnika najee su samo povremeno povezani. U vreme
pisanja ovog udbenika, program KaZaA predstavljao je najpopularniji sistem za P2P razmenu
datoteka.

1.9 Rezime
U ovom poglavlju obuhvatili smo zaista irok spektar tema. Najpre smo naveli razliite
hardverske i softverske komponente od kojih se sastoje Internet i raunarske mree u celini.
Poli smo od periferije" mree i najpre vam prikazali krajnje sisteme i aplikacije, kao i
transportne usluge koje su ovim aplikacijama potrebne. Koristei mrene distribuirane aplikacije
kao primer, predstavili smo vam pojam protokola, inae kljunog koncepta u umreavanju.
Nakon toga, uli smo dublje u unutranjost mree i stigli do njenog jezgra. Ovde smo
identifikovali komutiranje paketa i komutiranje vodova kao dva osnovna pristupa prilikom
transporta podataka kroz telekomunikacione mree i prikazali vam prednosti i mane oba
pristupa. Potom smo se bavili i najniim (u smislu arhitekture) delovima mree - tehnologijama
povezivanja podataka i fizikim medijumima koji se esto sreu u pristupnim mreama. Ispitali
smo strukturu globalnog Interneta i tu videli daje Internet mrea koja objedinjuje veliki broj
drugih mrea. Videli ste da Internet ima hijerarhijsku strukturu koja omoguava postojanje
hiljada mrea i sastoji se od posrednika za Internet usluge vieg i nieg reda.
U drugom delu ovog uvodnog poglavlja ispitali smo nekoliko tema koje se mogu smatrati
centralnim temama umreavanja raunara. Najpre smo ispitali uzroke kanjenja i gubitka paketa
u mreama sa komutiranjem paketa. Razvili smo jednostavne kvantitativne modele za kanjenja
u vezi sa prenosom, propagacijom i ekanjem u redu; u domaim zadacima koje emo vam
postavljati u ovoj knjizi koristiemo ove modele u znaajnoj meri. Zatim smo ispitali slojevitost
protokola i modele usluga - kljune arhitektonske principe umreavanja na koje emo se takoe
vraati u nastavku knjige. Ovaj uvod u umreavanje zavrili smo kratkim istorijskim prikazom
raunarskih mrea. Dakle, ovo prvo poglavlje samo za sebe moe da se posmatra kao
svojevrstan mini-kurs o umreavanju raunara.
Kao to vidite, u prvom poglavlju smo vam zaista ponudili veoma mnogo informacija.
Ukoliko mislite daje to previe, nita ne brinite. U poglavljima koja slede vratiemo se na sve
ove teme i istraiti ih mnogo detaljnije (ovo shvatite kao obeanje, ne kao pretnju). U ovom
trenutku vano je da imate samo najosnovnija intuitivna znanja o elementima raunarske mree,
da u solidnoj meri poznajete terminologiju umreavanja i da imate elju za daljim uenjem (na
ovo poglavlje uvek moete da se vratite). Sve drugo e doi na svoje mesto kako budete
napredovali itajui ovu knjigu.

DOMAI ZADATAK: PROBLEMI 1 PITANJA 42 42 42 42

Mapa knjige
Uvek je dobro da, pre nego to krenete na neki put, bacite pogled na mapu, kako biste se
upoznali sa glavnim putevima i raskrsnicama koje vas ekaju. Konani cilj naeg puta jeste
duboko razumevanje svih aspekata raunarskih mrea. Nau mapu ine poglavlja ove knjige:
1. Raunarske mree i Internet
2. Aplikacijski sloj
3. Transportni sloj
4. Mreni sloj
5. Sloj veze podataka i lokalne raunarske mree
6. Beino i mobilno umreavanje
7. Multimedijalno umreavanje
8. Bezbednost u raunarskim mreama
9. Upravljanje mreama
Gledajui ovu mapu, rekli bismo da poglavlja od 2 do 5 predstavljaju etiri kljune celine
knjige. Verovatno primeujete da je svakom od etiri gornja sloja familije protokola za Internet
posveeno po jedno poglavlje. Skreemo vam panju i na to da nae putovanje poinje od vrha
ove familije protokola - dakle, od aplikacijskog sloja, i da se zatim nastavlja nanie. Ovakav
pristup od vrha ka dnu usvojen je zato to ete, kada upoznate aplikacije, mnogo lake razumeti
mrene usluge koje treba da podre rad tih aplikacija. Dakle, upoznavanje aplikacija motivisae
vas za ostatak teksta.
U drugoj polovini knjige (poglavlja od 6 do 9) usredsredili smo se na etiri veoma vane (i
na neki nain nezavisne) teme savremenih raunarskih mrea. U poglavlju 6, bavimo se
beinim i mobilnim tehnologijama, ukljuujui Wi-Fi LAN-ove, GSM i mobilni IP. U
poglavlju 7, Multimedijalno umreavanje" ispita-emo aplikacije za audio i video kao to su
Internet telefonija, video konferencije i protok uskladitenih medija u realnom vremenu. Osim
toga, videete i na koji nain se dizajniraju mree sa komutiranjem paketa ukoliko se eli
dosledan kvalitet usluga audio i video aplikacija. U poglavlju 8, Bezbednost u raunarskim
mreama", najpre emo se baviti osnovama ifrovanja i mrene bezbednosti, a zatim emo
videti na koji se nain te osnovne teorijske postavke konkretizuju u velikom broju razliitih
situacija na Internetu. U poslednjem poglavlju, Upravljanje mreama", ispita-emo kljune
aspekte upravljanja mreama, kao i primarne Internet protokole koji se za to koriste.
Domai zadatak: problemi i pitanja Poglavlje 1
Kontrolna pitanja ODEUCI 1 . 1 - 1 .5
1. U emu je razlika izmeu raunara" i krajnjeg sistema"? Navedite razliite tipove
krajnjih sistema. Da lije veb server krajnji sistem?
2. Re protokol esto se u medijima povezuje sa'diplomatijom. Navedite jedan primer
diplomatskog protokola.
3. Staje klijentski program? Staje serverski program? Da li serverski program zahteva i
dobija usluge od klijentskog programa?
4. Navedite dva tipa usluga koje Internet prua svojim aplikacijama. Navedite neke njihove
karakteristike.
5. Reeno je da su kontrola toka i kontrola zaguenja ekvivalentni pojmovi. Da li to vai i za
Internet usluge sa konekcijom? Da li su ciljevi kontrole toka i kontrole zaguenja
identini?
6. Ukratko ispriajte na koji nain Internet usluga sa konekcijom obezbeduje pouzdan
transport.
7. U emu je prednost mrea sa komutiranjem vodova u odnosu na mree sa komutiranjem
paketa? U emu je prednost tehnologije TDM u odnosu na FDM tehnologiju u mreama sa
komutiranjem vodova?
8. Zbog ega se kae da komutiranje paketa primenjuje statistiko multipleksira-nje?
Uporedite statistiko multipleksiranje sa multipleksiranjem koje se odvija u okviru TDM
tehnologije.
9. Pretpostavimo da se izmeu izvornog i odredinog raunara nalazi tano jedan komutator
paketa. Brzine prenosa izmeu izvornog raunara i komutatora, i komutatora i odredinog
raunara, su Ri i R2. Ukoliko pretpostavimo daje re o komutatora sa memorisanjem i
prosledivanjem, koliko iznosi ukupno kanjenje paketa duine L od jednog do dragog kraja
njegovog puta? (Zanemariti kanjenja usled stajanja u redu, propagacije i obrade.)
10. ta se u mrei sa virtuelnim kolima podrazumeva pod informacijom o statusu veze?
Ukoliko se u komutatora jedne virtuelne mree veze uspostavljaju i raskidaju brzinom od
jedne veze po milisekundi (proseno), kojom brzinom treba da se aurira tabela za
prosleivanje ovog komutatora?
11. Pretpostavimo da razvijate standard za novu vrstu mree i da treba da se opre-delite ili za
virtuelna kola ili za rutiranje datagrama. ta su prednosti, a ta mane virtuelnih kola?
12. Navedite est razliitih tehnologija mrenog pristupa. Klasiftkujte svaku od njih u
kategorije kunog, poslovnog i mobilnog pristupa.
13. ta predstavlja kljunu razliku izmeu ISP-a prvog reda i ISP-a dragog reda?
14. U emu je razlika izmeu POP i NAP take?

62 62 62 62 POGLAVLJE 1 RAUNARSKE MREE I I I I INTERNET
PROBLEMI 43 43 43 43

16. Da li je propusna mo HFC mrea namenska ili deljena izmeu korisnika? Da li su na
nizvodnom HFC kanalu mogue kolizije? Zato jesu ili zato nisu?
17. Koja je brzina prenosa Ethernet LAN-ova? Da li data brzina znai da svaki korisnik
LAN-a moe daje ostvaruje u kontinuitetu?
18. Koji fiziki medijumi mogu da se koriste u Ethernet mreama?
19. Za kuni pristup Internetu koriste se telefonski modemi, HFC i ADSL veze. Za svaku od
ovih tehnologija navedite mogue brzine prenosa, kao i to da li je propusna mo
namenska ili deljena.

ODEUCI 1.6-1.8
19. Zamislite slanje serije paketa od izvornog do odredinog raunara fiksnom rutom, a zatim
navedite sve pojedinane komponente celokupnog kanjenja paketa od jednog do drugog
kraja. Koja su kanjenja konstantna, a koja pro-menljiva?
20. Navedite pet zadataka koje sloj moe da izvri. Da lije mogue da neki od tih zadataka
izvre neka dva druga sloja (ili vie njih)?
21. Navedite pet slojeva familije Internet protokola i osnovne nadlenosti svakog od njih.
22. ta je poruka aplikacijskog sloja? ta je segment transportnog sloja? ta je datagram
mrenog sloja? ta je okvir veze podataka?
23. Koji su slojevi u familiji Internet protokola zadueni za proces rutiranja, koji za proces
komutiranja sloja veze, a koji za serverske usluge?
Problemi _____________________________________
1. Dizajnirajte i opiite protokol aplikacijskog nivoa koji e se koristiti izmeu automatskog
bankomata i centralnog raunara banke. Ovaj protokol treba da omogui proveru
korisnikove kartice i lozinke, zatim proveru njegovog rauna (koji se uva u centralnom
raunaru), kao i povlaenje odreenog novanog iznosa sa datog rauna'(odnosno, isplatu
novca korisniku). Elementi vaeg protokola treba da budu u stanju da izau na kraj sa
veoma estom pojavom da je traeni iznos vei od onog koji je na raunu. Svoj protokol
uobliite navoenjem poruka koje e biti razmenjene kao i akcija koje bankomai i
centralni raunar treba da preduzmu kada dobiju ove poruke. Skicirajte rad svog protokola
za sluaj jednostavnog povlaenja bez ikakvih greaka i nacrtajte dijagram koji je slian
slici 1.2. Eksplicitno navedite pretpostavke koje postavlja va protokol u vezi sa
transportnom uslugom od jednog do drugog kraja, koja se nalazi ispod njega.
2. Zamislite aplikaciju koja svoje podatke prenosi ustaljenom brzinom (primera
radi, poiljalac generie N bitova svakih k vremenskih jedinica, gde je k kratak
i fiksni vremenski period). Nakon pokretanja, ova aplikacija treba da bude aktivna
relativno dug vremenski period, Odgovorite na sledea pitanja i ukratko obrazloite svoje
odgovore:
a) Da li bi za ovu aplikaciju bila podesnija mrea sa komutiranjem paketa ili mrea sa
komutiranjem vodova? Zato?
b) Pretpostavimo da se koristi mrea sa komutiranjem paketa i da sav njen saobraaj
stvara opisana aplikacija. Pored toga, pretpostavi emo da je zbir brzine prenosa
aplikacije manji od kapaciteta svakog linka. Da lije u mrei potreban neki mehanizam
za kontrolu zaguenja? Zato?
3. Vratimo se za trenutak na mreu sa komutiranjem paketa sa slike 1.5. Podse-
amo vas da u njoj svaki link ima n vodova.
a) Koji je maksimalan broj istovremenih aktivnih veza u bilo kom trenutku u ovoj mrei?
b) Pretpostavimo da se sve veze nalaze izmeu komutatora u levom gornjem uglu i
komutatora u desnom donjem uglu slike. Koji je maksimalan broj istovremenih
aktivnih veza?
4. Vratimo se sada na analogiju sa povorkom automobila iz odeljka 1.6. I u ovom
sluaju pretpostaviemo da brzina propagacije iznosi 100 km/h.
a) Pretpostavimo sada da karavan treba da putuje 200 kilometara - da krene od jedne
naplatne rampe, samo proe kroz drugu i svoj put zavri na treoj naplatnoj rampi.
Koliko iznosi ukupno kanjenje od jedne do druge krajnje take?
b) Ponovo odgovorite na pitanja pod a), ali sada sa sedam automobila umesto sa deset.
5. Zamislite slanje paketa od F bitova putanjom od Q linkova brzine prenosa R
b/s. Mrea je samo blago optereena tako da nema kanjenja usled stajanja u
redu. Kanjenje usled propagacije je beznaajno.
a) Pretpostavimo daje u pitanju mrea sa komutiranjem paketa i virtuelnim kolima. Neka
trajanje pripreme virtuelnih kola bude ts sekundi. Pretpostaviemo i to da izvorni slojevi
dodaju ukupno h bitova zaglavlja svakom paketu. Koliko je vremena potrebno za slanje
ove datoteke od izvora do odredita?
b) Pretpostavimo daje u pitanju mrea sa datagramima i komutiranjem paketa, da se
koristi usluga bez konekcije, kao i to da svaki paket ima zaglavlje duine 2h. Koliko je
vremena sada potrebno za slanje paketa?
c) Konano, pretpostavimo daje re o mrei sa komutiranjem vodova i da brzina prenosa
izmeu izvora i odredita iznosi R b/s. Ukoliko je is trajanje pripreme veze, a h broj
bitova zaglavlja koje se dodaje itavom paketu, koliko je vremena potrebno za slanje
ovog paketa?

64 64 64 64 POGLAVLJE 1 RAUNARSKE MREE l INTERNET

6. Ovim elementarnim problemom zapoinjemo istraivanje kanjenja usled pro-
pagacije i kanjenja usled prenosa, inae dva centralna aspekta umreavanja.
Zamislite dva raunara A i B koji su povezani jednim linkom ija je brzina
prenosa R b/s. Pretpostavimo da su ova dva raunara meusobno udaljena m
metara i da je brzina propagacije linka s metara u sekundi. Raunar A treba da
poalje paket duine L bitova raunani B.
a) Izrazite kanjenje usled propagacije dprop u funkciji m i s.
b) Odredite trajanje prenosa paketa dpfenas u odnosu na L i R.
c) Zanemarujui kanjenja usled obrade i stajanja u redu, napiite izraz za kanjenje
od jednog do drugog kraja.
d) Pretpostavimo da raunar A pone da emituje paket u trenutku / = 0. Gde se u trenutku t
= dprenos nalazi poslednji bit paketa?
e) Pretpostavimo daje dprop vee od dprenox. Gde se u trenutku t = dprcnos nalazi prvi bit
paketa?
f) Pretpostavimo daje dprop manje od dprenos. Gde se u trenutku t = dprenos nalazi prvi bit
paketa?
g) Pretpostavimo da je s = 2,5 10
8
, L = 100 bitova, a R = 28 kb/s. Odredite udaljenost m
tako da dprop bude jednako sa dprcags.

7. U ovom problemu baviemo se slanjem glasa od raunara A do raunara B kroz mreu sa
komutiranjem paketa (na primer, Internet telefonija). Raunar A u hodu pretvara analogni
signal glasa u digitalni niz bitova od 64 kb/s, a zatim ove bitove grupie u 48-bitne pakete.
Izmeu raunara A i raunara B je jedan link ija je brzina prenosa 1 Mb/s, a kanjenje
usled prenosa 2 ms. im napravi paket, raunar A ga odmah alje raunam B. im raunar
B primi itav paket, on njegove bitove pretvara u analogni signal. Koliko vremena prolazi
od trenutka nastajanja bita (originalni analogni signal na raunam A) pa do trenutka
njegovog dekodovanja (kao dela analognog signala na raunam B)?
8. Pretpostavimo da neki korisnici zajedniki koriste link brzine 1 Mb/s i da je svakom od njih
za emitovanje potrebna propusna mo od 100 kb/s, ali da to ine samo 10 procenata
ukupnog vremena. (Proitajte odeljak 1.3 u kome smo govorili o komutiranju paketa i
komutiranju vodova.)

a) Koliko korisnika moe da bude podrano komutiranjem vodova?
b) U nastavku ovog zadatka pretpostaviemo da se koristi komutiranje paketa. Odredite
verovatnou emitovanja za odreenog korisnika.
c) Pretpostavimo da u mrei ima 40 korisnika. Odredite verovatnou istovremenog
emitovanja tano n korisnika. (Savet: Koristite binomnu raspodelu.)
d) Odredite verovatnou istovremenog emitovanja 11 ili vie korisnika.
9. Vratimo se za trenutak na odeljak 1.3 u kome smo poredili komutiranje paketa i
komutiranje vodova i naveli primer sa linkom kapaciteta 1 Mb/s. Kada su kori-
snici aktivni, oni stvaraju saobraaj od 100 kb/s, ali verovatnoa njihove akti-
vnosti je samo p = 0,1. Pretpostavimo sada da se link od 1 Mb/s zameni linkom
od I Gb/s.
a) Koliko je N, tj. maksimalan broj korisnika koje komutiranje vodova moe da podri
istovremeno?
b) Pretpostavimo sada da je u pitanju mrea sa komutiranjem paketa od M korisnika.
Napiite formulu (u funkciji p, M, N) za izraunavanje verova-tnoe da vie od N
korisnika istovremeno alje svoje podatke.

10. Zamislite sada stajanje u redu u privremenoj memoriji rutera (koja prethodi izlaznom
linku). Pretpostavimo da je duina svih paketa L bitova, brzina prenosa R b/s i da //paketa
istovremeno stie u privremenu memoriju svakih LM/ R sekundi. Odredite proseno
kanjenje paketa usled stajanja u redu. (Savet: Kanjenje usled stajanja u redu prvog paketa
je nula, drugog L/R, treeg 2L/R. M-X\ paket je ve prenet kada u ruter dospe druga serija
paketa.)
11. Ponovo zamislite stajanje u redu u privremenoj memoriji nekog rutera. Slovom /
oznaiemo intenzitet saobraaja; / = La/R. Pretpostavimo da je kanjenje usled stajanja u
redu ILIR (1 - I ) za/< 1.

a) Napiite formulu za ukupno kanjenje koje se dobija sabiranjem kanjenja usled
stajanja u redu i kanjenja usled prenosa.
b) Nacrtajte ukupno kanjenje u funkciji L/R.
12. a) Generalizujte formulu za kanjenje od jednog do drugog kraja mree iz
odeljka 1.6 za razliite brzine obrade i prenosa, kao i za razliito kanjenje
usled propagacije.
b) Ponovite postupak pod a) ali sada pretpostavite da na svakom voru proseno kanjenje
usled stajanja u redu iznosi dred.
13. Programom Traceroule u tri razliita doba dana testirajte vezu izmeu izvor-
nog i odredinog raunara na istom kontinentu.
a) Odredite prosenu vrednost i standardnu devijaciju kanjenja povratnog puta u
svakom od tri doba dana.
b) Ustanovite broj rutera na putanji u svakom od tri doba dana. Da li se putanje menjaju
tokom dana?
c) Pokuajte da identifikujete broj ISP mrea kroz koje paketi programa Tra-ceroute
prolaze na svom putu od izvora do odredita. Rutere slinih imena i (ili) slinih IP
adresa treba smatrati delom mree istog ISP-a. Da li se u vaim eksperimentima
najdua kanjenja javljaju na takama vezivanja susednih posrednika za Internet
usluge?
d) Ponovite prethodne zadatke, ali sada za izvorne i odredine raunare na razliitim
kontinentima, a zatim uporedite kontinentalne i interkontinentalne rezultate.
14. Pretpostavimo da su dva raunara meusobno udaljena 10 000 kilometara i da
su povezani direktnim linkom brzine R = 1 Mb/s. Takoe emo pretpostaviti i
to da brzina propagacije linka iznosi 2,5 10
8
metara u sekundi.
a) Izraunajte proizvod propusni opseg-kanjenje", R tpnp.
b) Od raunara A do raunara B treba poslati datoteku od 400 000 bitova. Pretpostavimo
da se ova datoteka alje kao jedna velika kontinuirana poruka. Koji je maksimalan broj
bitova koji u bilo kom trenutku moe da se nade na linku?

45 45 45 45 POGLAVLJE 1 RAUNARSKE MREE ! INTERNET

d) Objasnite rezultat proizvoda propusne moi i kanjenja.
e) Koja je irina bitova (u metrima) u linku? Da li su dui od fudbalskog igralita?
f) Izvedite uopteni izraz za izraunavanje irine bitova na osnovu brzine propagacije s,
propusnog opsega R i duine linka m.

15. Vraajui se na prethodni problem, pretpostavimo da moemo da izmenimo parametar
R. Za koju vrednost ovog parametra je duina bita jednaka duini linka?
16. Ponovo se vraamo na problem pod rednim brojem 14, ali e sada propusna mo linka
biti R = 1 Gb/s.

a) Izraunajte proizvod propusne moi i kanjenja, R iprop.
b) Uzmimo da od raunara A do raunara B treba da se poalje datoteka duine 400 000
bitova i to ponovo kao jedinstvena poruka. Koji je maksimalan broj bitova koji u bilo
kom trenutku moe da se nade na linku?
c) Koja je irina (u metrima) bitova u linku?
17. Ponovo se vratite na problem pod rednim brojem 14.
a) Koliko je vremena potrebno za slanje datoteke pod pretpostavkom da se ona alje
kontinuirano?
b) Pretpostavimo sada daje datoteka razbijena na deset paketa od po 40 000 bitova, da
svaki paket primalac treba da potvrdi, kao i to daje trajanje prenosa paketa sa potvrdom
zanemarljivo. Konano, pretpostavimo i to da poiljalac ne moe da poalje sledei
paket sve dok ne dobije potvrdu o prijemu prethodnog. Koliko je vremena potrebno za
slanje ove datoteke?
c) Uporedite rezultate pod a) i b).
18. Pretpostavimo da se izmeu geostacionarnog satelita i njegove bazne stanice
na Zemlji nalazi mikrotalasni link propusnog opsega 10 Mb/s. Svakog minuta
satelit snima po jednu digitalnu fotografiju koju zatim alje baznoj stanici. Pre-
tpostaviemo da brzina propagacije iznosi 2,4 10
8
metara u sekundi.
a) Koliko iznosi kanjenje usled propagacije ovog linka?
b) Izraunajte proizvod propusne moi i kanjenja, R tprop
c) Uzmimo da je x veliina fotografije, Koja je minimalna veliina x sa kojom
mikrotalasni link emituje u kontinuitetu?

19. Vratimo se sada na analogiju sa avionskim transportom iz odeljka 1.7 i dodavanje
zaglavlja jedinicama podataka protokola na njihovom putu nanie kroz familiju protokola.
Postoji li ekvivalentan pojam ovom dodavanju zaglavlja kod putnika i prtljaga kod
njihovog kretanja nanie kroz protokol avionskog transporta?
20. U savremenim mreama sa komutiranjem paketa izvorni raunar segmentira duge poruke
aplikacijskog sloja (recimo, sliku ili muziku datoteku) na manje
pakete i alje ih kroz mreu. Primalac zatim ponovo sastavlja ove pakete i od njih dobija
originalnu poruku. Ovaj proces nazvali smo segmentiranjem. Na slici 1.21 ilustrovan je
transport sa kraja na kraj mree sa segmentiranjem i bez njega. Zamislite da od izvornog
do odredinog raunara sa slike 1.21 treba poslati poruku duine 7,5 IO
6
bitova.
Pretpostaviemo da svaki link ima brzinu prenosa od 1,5 Mb/s, a zanemariti kanjenja
usled propagacije, stajanja u redu i obrade.
a) Zamislite slanje poruke od izvora do odredita bez njenog segmentiranja. Koliko je
vremena potrebno da ona stigne do prvog komutatora? Imajui u vidu injenicu da
svaki komutator memorie i prosleuje pakete, koliko je ukupno vremena potrebno za
prebacivanje poruke od izvornog do odredinog raunara?
b) Pretpostavimo sada daje ista poruka segmentirana na 5 000 paketa od po 1 500 bitova.
Koliko je vremena potrebno za prenos prvog paketa od izvornog raunara do prvog
komutatora? im se prvi paket poalje iz prvog komutatora ka drugom, drugi paket se
alje od izvornog raunara ka prvom komutatoru. U kom trenutku e drugi paket
dospeti do prvog komutatora?
c) Koliko je vremena potrebno za prenos cele datoteke od izvornog do odredinog
raunara ukoliko se koristi segmentiranje? Uporedite ovaj rezultat sa odgovorom pod
(a) i obrazloite.
d) Raspravljajte o nedostacima segmentiranja poruka.
21. Eksperimentiite malo sa Java apletom za segmentaciju poruka koju ete pronai na veb
lokaciji ove knjige. Da li kanjenja u ovom apletu odgovaraju kanjenjima iz prethodnog
pitanja? Na koji nain kanjenja usled propagacije utiu na ukupno kanjenje od jednog
do drugog kraja u komutiranju paketa (sa segmentacijom poruka), a na koji u komutiranju
poruka?

ETHEREAL LABORATORIJSKA VEBANJA 69 69 69 69 I

22. Pretpostavimo da od raunara A do raunara B treba poslati veliku datoteku od F bitova.
Izmeu raunara A i B postoje dva linka (ijedan komutator) koji nisu zagueni (dakle,
nema stajanja u redu). Raunar A segmentira datoteku na segmente od po S bitova i
svakom segmentu dodaje zaglavlje od 40 bitova, ime se dobijaju paketi duine L = 40 +
S bitova. Brzina prenosa svakog linka iznosi R b/s. Pronaite vrednost parametra S koja
minimizira kanjenje prilikom premetanja datoteke sa raunara A na raunar B.
Zanemarite kanjenje usled propagacije.
Teze za diskusiju
1. Koje vrste beinih mobilnih usluga postoje u vaem kraju?
2. Korienjem beine LAN tehnologije 802.1 lb dizajnirajte mreu koja bi povezala va
dom i dom vaih roditelja. Navedite ureaje koje biste upotrebili i njihove cene.
3. Staje od PC-ja do telefona"? Pronaite veb lokacije koje se bave ovim poslom.
4. ta se podrazumeva pod uslugom SMS (Short Message Service)? Da li je ova usluga
popularna u svim delovima sveta? Gde je najpopularnija? Da li je mogue sa veb lokacije
poslati SMS poruku mobilnom telefonu?
5. ta se podrazumeva pod protokom uskladitenog audio materijala u realnom vremenu?
Opiite neke od postojeih proizvoda za internetski protok audio signala u realnom
vremenu. Pronaite neke veb lokacije kompanija koje se time bave.
6. ta su Internet video konferencije? Opiite neke od postojeih proizvoda za Internet video
konferencije, Pronaite veb lokacije kompanija koje se time bave.
7. Navedite pet kompanija koje obezbeuju uslugu P2P razmene datoteka i za svaku od njih
navedite vrstu datoteka iju razmenu podravaju.
8. Staje trenutna razmena poruka? Postoje li PDA ili slini ureaji koji bi mogli da vam
omogue pristup uslugama za trenutnu razmenu poruka?
9. Ko je izmislio ICQ, inae prvu uslugu za trenutnu razmenu poruka? Kada je ova usluga
izmiljena i koliko su bili stari njeni pronalazai? Koje izmislio uslugu Napster? Kada je
ova usluga izmiljena i koliko su bili stari njeni pronalazai?
10. Uporedite beini pristup Internetu tehnologijama Wi-Fi i 3G. Koje brzine prenosa
omoguavaju ove dve usluge? Koja je njihova cena? Razgovarajte o romingu i sveoptoj
prisutnosti pristupa Internetu.
11. Zato je Napster prestao da postoji. ta je RIAA i koje mere ovo telo predu-zima u cilju
spreavanja P2P razmene sadraja zatienog autorskim pravima? Objasnite razliku izmeu
direktnog i indirektnog krenja autorskih prava.
12. Da li mislite da e za deset godina i dalje biti razmene zatienog materijala kroz
raunarske mree? Obrazloite svoj odgovor.
Ethereal laboratorijska vebanja
Kai mi i zaboraviu. Pokai mi i zapamtiu.< Ukljui i mene u rad i
razumeu."
Kineska poslovica

Razumevanje mrenih protokola esto zavisi od toga da li ste bili u prilici da ih vidite na delu i
poigrate se sa njima - pratei razmenu poruka izmeu dva mrena entiteta, ulazei dublje u
naine njihovog rada, iniciranje odreenih njihovih akcija i praenje tih akcija i njihovih
posledica. Ovo se moe uiniti u simuliranim scenarijima ili u stvarnom mrenom okruenju
kao to je, na primer, Internet. U Java apletima koje ete pronai na prateoj veb lokaciji ove
knjige primenjen je prvi princip, dok smo se u Ethereal laboratorijskim vebanjima pridravali
drugog. Koristei mrene aplikacije na svom raunaru kod kue, na poslu ili u laboratoriji, nai
ete se u najrazliitijim situacijama. Pratiete rad mrenih protokola, ali i razmenjivati poruke sa
entitetima protokola koji se izvravaju u nekom drugom kraju Interneta. Prema tome, vi i va
raunar biete integralni delovi ovih pet laboratorijskih vebi. Posmatraete i, u krajnjoj liniji,
nauiti radei praktino.
Osnovna alatka za praenje razmene poruka izmeu aktivnih entiteta protokola naziva se
sakuplja paketa (engl. packet sniffer). Kao to iz naziva ove alatke moete da zakljuite ona
pasivno kopira (uvlai) poruke koje se alju iz vaeg raunara ili ka njemu. Osim toga, ova
alatka prikazuje sadraj razliitih polja protokola ovako uhvaenih poruka. Na slici 1.22 moete
da vidite snimak ekrana sakupljaa paketa Ethereal. U pitanju je besplatan program koji moe
da se izvrava na rauna-rima pod operativnim sistemima Windows, Linux/Unix i Mac. U
poglavljima od I do 5 pronai ete Ethereal laboratorijska vebanja pomou kojih ete istraiti
veliki broj protokola pomenutth u ovom poglavlju. U prvom vebanju najpre ete da nabavite i
instalirate kopiju programa Ethereal. Nakon toga pristupiete nekoj veb lokaciji kako biste
uhvatili i ispitali poruke protokola koje razmenjuju va ita Weba i odgovarajui veb server.
Sve detalje u vezi sa ovim prvim Ethereal vebanjem (ukljuujui i instrukcije o
nabavljanju i instaliranju ovog programa) nalaze se na veb lokaciji http://www.
awl.com/kurose-ross.

47 47 47 47
71 71 71 71
INTERVJU
Leonard Klajnrolc Leonard Klajnrolc Leonard Klajnrolc Leonard Klajnrolc
Leonard Klajnrok je profesor raunarskih nauka na Univerzifelu UCLA. Godine 1
969. njegov raunar na ovom univerzitetu postao je prvi vot Interneta.
Tehnologijo komutiranja paketa koju je izumeo 196]. godine posiaia je okosnica
Interneta. Leonard je i predsednik i osniva kompanije Nomadix, Inc. ija
tehnologija obezbeduje boiju pristupanost irokopojasnih Interne! uslugo.
Diplomirao je na Gradskom koledu u Njujorku [CCNY], dok je magistarske i
doktorske studije u oblasti inenjerstva elektrotehnike zavrio na MIT-u.
Zbog Zbog Zbog Zbog ega ste se opredelili za specijalizaciju u oblasti tehnologije umre ega ste se opredelili za specijalizaciju u oblasti tehnologije umre ega ste se opredelili za specijalizaciju u oblasti tehnologije umre ega ste se opredelili za specijalizaciju u oblasti tehnologije umreavanja i Interneta? avanja i Interneta? avanja i Interneta? avanja i Interneta?
Na doktorskim studijama na MIT-u 1959. godine primetio sam da se veina mojih kolega opredelila za informatiku i
teoriju kodiranja. Na MIT-u je radio Klod anon, izuzetan istraiva, koji je pokrenuo ove oblasti i sam ve reSio mnoge
znaajne probleme. Preostali istraivaki problemi bili su teki i nisu bili toliko znaajni. Zato sam odluio da sam pokre-
nem novu oblast - neto ime se do tada niko nije bavio. Podseam vas da sam na MIT-u bio okruen velikim brojem
raunara i ubrzo mi jc postalo jasno da svi ti raunari treba da komuniciraju. U to vreme jednostavno nije postojao
nain da se ta komunikacija ostvari, tako da sam odluio da razvijem tehnologiju koja bi omoguila stvaranje efikasnih
mrea za protok podataka.
Sta je bio va Sta je bio va Sta je bio va Sta je bio va prvi posao u ra posao u ra posao u ra posao u raunarskoj Industriji? Kako je on izgledao? unarskoj Industriji? Kako je on izgledao? unarskoj Industriji? Kako je on izgledao? unarskoj Industriji? Kako je on izgledao?
Izmeu 1951. i 1957. sam kao student poseivao veernja predavanja na Siti koledu u Njujorku. Tada sam radio, najpre
kao tehniar, a zatim i kao inenjer, u maloj firmi za industrijsku elektroniku po imenu Photobell. Radei za tu firmu u
njihovu proizvodnu liniju uveo sam digitalnu tehnologiju. U osnovi, koristili smo fotoeleklrine ureaje za detektova-nje
prisustva odreenih objekata {kutija, ljudi i i i i slino). Elektrina kola poznata pod nazivom bisiabihu multivibiatori bila su
upravo ona vrsta tehnologije koja nam je bila potrebna za uvoenje digitalne obrade u ovo polje. Ispostavilo se da su ova
kola postala osnovni delovi raunara, a u dananjem argonu se nazivaju ,,flip-flopovi" ili prekidai (preklopnici).
O O O O emu ste razmi emu ste razmi emu ste razmi emu ste razmiljali ljali ljali ljali prilikom slanja prve poruk slanja prve poruk slanja prve poruk slanja prve poruke od ra e od ra e od ra e od raunara do ra unara do ra unara do ra unara do raunara (iz Univerziteta unara (iz Univerziteta unara (iz Univerziteta unara (iz Univerziteta
UCLA ka Istra UCLA ka Istra UCLA ka Istra UCLA ka Istraiva iva iva ivakom institutu Stanford]? kom institutu Stanford]? kom institutu Stanford]? kom institutu Stanford]?
Prva ponika izmeu dva raunara predstavljala je svojevrstan antiktimaks. Mnogo impre-sivniji trenutak za mene bio je
2. septembar 1969. godine kada je prvi deli mrene opreme (IMP) povezan sa prvim spoljnim operativnim sistemom
(bio je to moj raunar na Univerzitetu UCLA). Tada je roen Internet. Neto ranije iste godine, u jednom saoptenju za
javnost Univerziteta UCLA rekao sam da e odmah nakon podizanja i putanja u rad raunarskih mrea, biti mogu
prismp raunarima iz naih domova ili kancelarija i da e to biti isto onoliko jednostavno koliko i ulazak u elektrinu ili
telefonsku mreu. Dakle, jo

72
tada sam imao viziju o tome da e Internet biti sveobuhvatan, uvek prisutan i uvek dostupan
svakome ko ima neki ureaj za povezivanje. Ipak, nikada ne bih mogao da pretpostavim da e
danas ak i moja 94-godinja majka koristiti Internet, to ona zaista ini.

Kako Izgleda vaa vizija budunosti umreavanja?
Najjasniji deo moje vizije predstavljaju nomadsko raunarstvo i inteligentan prostor.
Dostupnost lakih, jeftinih i monih prenosivih raunara, sa jedne strane, kao i sveobuhva-tnost
Interneta, s druge, omoguili su nam da postanemo nomadi. Pojam nomadsko raunarstvo
odnosi se na tehnologiju koja omoguava krajnjim korisnicima da putujui od jednog do drugog
mesta na jednostavan nain ostvaruju pristup Internet uslugama bez obzira na to gde putuju.
Meutim, nomadsko raunarstvo je samo prvi korak. Sledei korak e nam omoguiti iskorak iz
paklenog virtuelnog prostora u fiziki svet inteligentnog prostora. Nae okruenje (stolovi,
zidovi, vozila, satovi, kaievi) oivee kroz tehnologiju aktuatora, senzora, logike, obrade,
skladitenja, kamera, mikrofona, zvunika, ekrana i komunikacije. Ova ugraena tehnologija e
omoguiti naem okruenju da nam obezbedi IP usluge koje elimo. Kada udem u sobu, soba e
znati da sam to uinio. Moi u da komuniciram sa svojim okruenjem prirodno, sluei se pri
tom engleskim jezikom; moji zahtevi e generisati odgovore koji e mi biti predstavljeni u vidu
veb stranica na zidnim ekranima, u mojim nao-arima, kao govor, ili u obliku holograma.
Gledajui jo dalje u budunost, umreavanje vidim sa jo nekim dodatnim kompo-
nentama. Vidim inteligentne softverske mrene agente iji su zadaci skupljanje podataka,
reagovanje na prikupljene podatke, praenje trendova i adaptivno i dinamiko izvravanje
zadataka. Vidim mnogo vei obim mrenog saobraaja koji ne generiu ljudi, ve ti ugraeni
ureaji i softverski agenti. Ovu ogromnu mreu konirolisae veliki skupovi
samoor-ganiznjuih sistema. Kroz ovu mreu trenutno e se kretati ogromna koliina
informacija koje e prolaziti kroz izuzetno obimnu obradu i filtriranje. Internet e u osnovi
predstavljati proimajui nervni sistem. Sve ove i mnoge druge stvari vidim u naem putu kroz
21. vek.

Ko vas je u profesionalnom smislu najvie impresionirao?
Bez konkurencije Klod anon sa MIT-a - briljantan istraiva koji je posedovao dar da
svoje matematike ideje povee sa fizikim svetom na krajnje intuitivne naine. On je bio lan
komisije pred kojom sam branio doktorsku tezu.

Da li imate savet za studente koji tek zakorauju u polje umreavanja i Interneta?
Internet i sve ono to on omoguava predstavlja ogroman front pun neverovatnih izazova.
U njemu i te kako ima prostora za inovacije. Ne dozvolite da vas ogranii dananja tehnologija.
Zakoraite u njega, zamislite ta bi moglo da bude i zatim uinite da se to i ostvari.
Aplikacijski
sloj
Mrene aplikacije predstavljaju raison d'eire raunarskih mrea. Bez korisnih aplikacija ne bi
bilo razloga ni za dizajniranje mrenih protokola koji ih podravaju. Sreom, u proteklih 35
godina napravljene su mnoge izvrsne mrene aplikacije. Pokuajmo da se prisetimo makar onih
najvanijih. Najpre, to su klasine aplikacije zasnovane na tekstu koje su postale popularne
1980-ih, kao to su bili elektronska pota, daljinski pristup raunarima, transfer datoteka,
elektronske konferencije i interaktivni razgovor, svi zasnovani na tekstu. Zatim, tu je i
najpopularnija aplikacija 1990-ih - Web. Nedugo zatim, pojavile su se i mnoge multimedijalne
aplikacije, kao Stoje protok video signala u realnom vremenu (striming), Internet radio, Internet
telefonija i video konferencije. Konano, pomenuemo i dve izuzetne aplikacije s kraja
milenijuma - instantna razmenu poruka sa kontakt listama i P2P razmenu datoteka.
U ovom poglavlju baviemo se konceptualnim aspektima mrenih aplikacija, kao i
aspektima njihove implementacije. Poeemo definisanjem kljunih koncepata aplikacijskog
sloja, kao to su njegovi protokoli, zatim klijenti i serveri, procesi, soketi i interfejsi transportnog
sloja. Zatim emo detaljno ispitati i nekoliko mrenih aplikacija, kao to su Web, elektronska
pota, DNS i P2P razmena datoteka.
Nakon toga prikazaemo vam i proces programiranja mrenih aplikacija, bez obzira na to da
li koriste protokol TCP ili protokol UDP. Zadraemo se na soketima i proi kroz neke
jednostavne klijentsko-serverske aplikacije koje su uraene u programskom jeziku Java.
Konkretno, videete na koji nain u Javi moe da se napravi jednostavan veb server. Osim toga,
na kraju poglavlja nalazi se i nekoliko zanimljivih zadataka u vezi sa programiranjem soketa.
7 77 7
k kk k

74 74 74 74 POGLAVLJE 2 APLIKATIVNI SLOJ 2.1 - PRINCIPI RADA MRENIH APLIKACIJA 49 49 49 49

Aplikacijski sloj predstavlja odlino mesto za poetak naeg prouavanja protokola, pre
svega zato to je u pitanju poznati teren. Sigurno su vam ve dobro poznate mnoge aplikacije
koje se oslanjaju na protokole o kojima emo govoriti. Preko aplikacijskog sloja stei ete tanu
predstavu o protokolima i upoznati se sa mnogim aspektima na koje emo se vratiti kada
budemo govorili o protokolima transportnog i mrenog sloja, kao i sloja veze podataka.

2.1 Principi rada mrenih aplikacija
U najpopularnije mrene aplikacije spadaju:
elektronska pota;
Web;
instantna razmena poruka;
prijavljivanje na udaljene raunare (na primer, Telnet ili SSH);
P2P razmena datoteka;
transfer datoteka izmeu dva naloga na dva raunara (na primer, FTP);
mrene igre sa velikim brojem korisnika;
protok uskladitenog video materijala u realnom vremenu; ' Internet
telefonija;
video konferencije u realnom vremenu.
Na veinu ovih aplikacija vratiemo se, manje ili vie detaljno, u nastavku knjige. Primera
radi, u ovom poglavlju govoriemo o elektronskoj poti, Webu i P2P razmeni datoteka. U
poglavlju 7 u kome e biti rei o multimedijalnom umreavanju vratiemo se na protok video
signala u realnom vremenu, kao i Internet telefoniju.
Pretpostavimo sada da imate izuzetnu ideju za novu mrenu aplikaciju. Sasvim je nevano
da li e ona predstavljati dobrobit za oveanstvo, izvor materijalne koristi za vas ili samo
zanimljiv izazov u smislu programiranja. Dakle, ne ulazei u vae razloge, pogledajmo na koji
nain biste mogli da ostvarite ovu svoju ideju.
Bez sumnje najvaniji deo procesa programiranja mrene aplikacije predstavlja pisanje
programa koji e se izvravati na razliitim mrenim sistemima i meusobno komunicirati kroz
mreu. Primera radi, u aplikaciji za Web postoje dva razliita programa koji komuniciraju jedan
sa drugim: program za itanje koji se izvrava na korisnikovom raunaru (stonom, laptop, PDA,
mobilnom telefonu) i serverska veb aplikacija koja se izvrava na raunaru koji ima ulogu veb
servera. Kao drugi ovakav primer mogla bi da nam poslui P2P razmena datoteka u kojoj, na
svakom raunaru koji uestvuje u ovom sistemu, postoji odgovarajui program. U ovom sluaju
sasvim je mogue da su ti programi slini ili ak isti.
Dakle, programirajui svoju novu aplikaciju moraete da napiete softver koji e se
izvravati na razliitim raunarima. U ovoj situaciji veoma je vano to to prilikom pisanja
programa ne morate da razmiljate o njegovom radu na kljunim mrenim ureajima, kao to su
ruteri ili Ethernet komutatori. ak i kada biste eleli da napiete softver za ove ureaje, to
jednostavno ne bi bilo mogue. Kao to ste mogli da vidite u poglavlju 1 i posebno na slici 1.18,
kljuni mreni ureaji ne funkcioniu na aplikacijskom sloju, ve samo na niim slojevima - na
mrenom i onima koji se nalaze ispod njega. Upravo ovo zadravanje aplikativnog softvera
samo na nivou krajnjih sistema (slika 2.1) zasluno je za izuzetno brz razvoj iroke lepeze
aplikacija za Internet,

2.1.1 Arhitektura mrenih aplikacija
Prilikom pravljenja nove mrene aplikacije najpre morate da odluite kakva e biti njena
arhitektura. Stavie, samom programiranju uvek treba da prethodi globalni arhitektonski plan
aplikacije. Uvek imajte u vidu to da se arhitektura aplikacije bitno razlikuje od mrene
arhitekture (podseamo vas na petoslojnu arhitekturu Interneta
0 kojoj smo govorili u poglavlju 1). Iz perspektive programera aplikacije, mrena arhitektura je
fiksna i ona aplikacijama obezbeduje konkretan skup usluga. Arhitekturu aplikacije, s druge
strane, dizajnirao je njen programer i njome je defini-san nain na koji se aplikacija organizuje
na razliitim krajnjim sistemima. Prilikom izbora arhitektonskog reenja, programer se
opredeljuje za jednu od tri dominantne arhitekture savremenih mrenih aplikacija. To moe da
bude klijentsko-serverska arhitektura, zatim P2P arhitektura, ili hibridna arhitektura koja ima
osobine obe koje su prethodno pomenute.
U klijentsko-serverskoj arhitekturi mora da postoji uvek dostupan server, raunar koji
opsluuje zahteve mnogo drugih raunara koji se nazivaju klijentima. Klijentski raunari mogu
biti povremeno ili stalno ukljueni. Klasian primer ovakve arhitekture predstavlja veb
aplikacija u kojoj neprekidno dostupni serveri opsluuju zahteve itaa koji se izvravaju na
klijentskim raunarima. Kada od nekog klijentskog raunara primi zahtev za odreeni objekat,
veb server odmah odgovara slanjem traenog objekta. Skreemo vam panju na to da u
klijentsko-serverskoj arhitekturi ne postoji direktna komunikacija klijenata; recimo, u veb
aplikaciji ne postoji direktna komunikacija dva itaa. Drugu vanu karakteristiku ove arhite-
kture predstavlja injenica da server ima fiksnu, dobro poznatu IP adresu (uskoro emo se
pozabaviti ovim adresama). S obzirom na to da server ima nepromenljivu
1 dobro poznatu adresu i daje uvek dostupan, klijent u svakom trenutku moe da kontaktira sa
njim aljui odgovarajui paket na ovu adresu. U poznatije klijentsko-serverske aplikacije
spadaju Web, transfer datoteka, prijavljivanje na daljinu i elektronska pota. Na slici 2.2(a)
moete da vidite kako izgleda ova arhitektura.
U klijentsko-serverskim aplikacijama deava se da server jednostavno ne moe da
odgovori na sve zahteve svojih klijenata. Na primer, na popularnim veb lokacijama za vesti
mogui su zastoji u situacijama kada samo jedan server treba da odgo-

76 76 76 76 POGLAVLJE 2 APLIKATIVNI SLOJ
2.1 PRINCIPI RADA MRENIH APLIKACIJA 50 50 50 50

vori na sve zahteve klijenata. Upravo zato se, u klijentsko-serverskoj arhitekturi, koriste klasteri
servera (za koje se nekada koristi i termin serverska farma) da bi se dobio moan virtuelni
server.
U istoj P2P arhitekturi u samom centru aplikacije ne postoji uvek dostupan server.
Umesto toga, parovi ravnopravnih raunara {sng\.peers) direktno komuniciraju izmeu sebe.
Budui da se komunikacija ravnopravnih raunara odvija bez posredovanja nekog servera, ova
arhitektura se naziva arhitekturom ravnopravnih
korisnika (engl. peer-to-peer), U ovoj arhitekturi nijedan ravnopravni korisnik ne mora sve
vreme da bude ukljuen; osim toga, mogue je da raunar koji uestvuje u P2P razmeni datoteka
svaki put ima drugu IP adresu. Dobar primer aplikacije sa istom P2P arhitekturom predstavlja
Gnutella [Gnutella 2004], otvorena aplikacija za P2P razmenu datoteka. U ovoj aplikaciji svaki
raunar moe da zahteva i alje datoteke, upitom trai datoteke, odgovara na upite drugih
raunara i prosleuje tue upite. O programu Gnutella neto detaljnije emo govoriti u odeljku
2.6, a P2P arhitekturu smo ihistrovali na slici 2.2 (b).
Jedna od najznaajnijih dobrih strana P2P arhitekture jeste njena skalabilnost. Primera radi,
kod ovakvih aplikacija mogue je da u razmeni datoteka uestvuju milioni ravnopravnih
korisnika i da svaki od njih funkcionie i kao server doprinosei na taj nain resursima
zajednice. Prema tome, osim to generie optereenje zahtevajui odreene datoteke, svaki
ravnopravni raunar takoe doprinosi sveukupnom obimu usluge odgovarajui na zahteve
drugih korisnika. To znai daje P2P razmena datoteka sutinski podesive veliine - svaki
korisnik poveava, ne samo potranju, ve i usluni kapacitet. U dananjem Internetu P2P
razmena datoteka ini veoma znaajan deo sveukupnog saobraaja [Saroiu 2002].
S druge strane, visok nivo distribuiranosti i decentralizovana priroda P2P aplikacija ini ih
veoma tekim zaupravljanje. Ovde je sasvim mogue da se jedina kopija neke vane datoteke
nalazi na raunaru koji u svakom trenutku moe da se iskljui. Zbog toga jejo uvek veliko
pitanje da lije mogue napraviti industrijska P2P reenja za enterprajz aplikacije [Adya 2004].


Klijentsko-serverska i P2P su dve uobiajene arhitekture mrenih aplikacija. Ipak, postoje i
aplikacije koje su koncipirane kao hibridi ove dve arhitekture. Dobar primer ovakvih aplikacija
predstavlja, sada ve zaboravljeni, Napster koji je predstavljao prvu aplikaciju za razmenu MP3
muzike. Napster pripada P2P aplikacijama u tom smislu to korisnici direktno razmenjuju MP3
datoteke, bez posredovanja nekog servera koji bi sve vreme morao da bude dostupan. Meutim,
Napster pripada i klijentsko-serverskim aplikacijama zato to ravnopravni korisnici
ispitivanjem centralnog servera dolaze do informacija o MP3 pesmama koje trae. (Arhitekturu
aplikacije Napster detaljnije smo prikazali u odeljku 2.6.) Druga aplikacija koja takoe ima
hibridnu arhitekturu jeste instantna razmena poruka. Kod instantne razmene poruka interaktivni
razgovor izmeu dva korisnika je obino P2P; poruke koje oni razmenjuju ne prolaze kroz
posredniki server koji je stalno dostupan. Meutim, kada Alisa pokrene svoju aplikaciju za
instantnu razmenu poruka, ona se automatski registruje na centralnom serveru. Isto tako, kada
Bob poeli da razgovara sa nekim sa svoje liste prijatelja njegov klijent za instantnu razmenu
poruka na centralnom serveru odmah proverava koji su njegovi prijatelji trenutno dostupni.

2.1.2 Komunikacija izmeu procesa
Pre nego to ponete da programirate svoju mrenu aplikaciju potrebno je da, bar u
najosnovnijim crtama, znate na koji nain komuniciraju programi koji se nalaze na razliitim
krajnjim sistemima. U argonu operativnih sistema ova komunikacija se, u stvari, ne odvija
izmeu programa, ve izmeu procesa. S druge strane, proces moete da zamislite i kao
program koji se izvrava na krajnjem sistemu. Ukoliko se komunicirajui procesi izvravaju na
istom krajnjem sistemu, re je o medupro-cesnoj komunikaciji. Pravilima meuprocesne
komunikacije upravlja operativni sistem krajnjeg sistema. Meutim, u ovoj knjizi neemo se
baviti komuniciranjem izmeu procesa na istom raunani, ve nainima na koje komuniciraju
procesi koji se izvravaju na razliitim krajnjim sistemima (to moe da bude i u okviru razliitih
operativnih sistema).
Komunikacija izmeu dva procesa koji se odvijaju na dva razliita krajnja sistema odvija
se razmenom poruka koje se alju kroz raunarsku mreu. Predajni proces formira poruke i
upuuje ih u mreu; prijemni proces prima poruke i eventualno odgovara sopstvenim porukama.
Na slici 2.1 ilustrovana je komunikacija procesa na aplikacijskom sloju petoslojne familije
protokola.

Klijentski i serverski procesi
Mrene aplikacije sastoje se od parova procesa koji jedni drugima alju poruke kroz mreu. Na
primer, u veb aplikaciji, proces klijentskog itaa razmenjuje poruke sa procesom veb servera.
U sistemu P2P razmene, datoteke se prenose od procesa jednog ravnopravnog korisnika do
procesa drugog ravnopravnog korisnika. U svakom paru komunicirajuih procesa jedan od njih
naziva se klijent, a drugi server.
Kod Weba, ita je klijentski proces, a veb server serverski proces. U P2P razmeni datoteka,
ravnopravni korisnik koji preuzima datoteku naziva se klijent, dok predajni ravnopravni
korisnik ima ulogu servera.
Verovatno ste primetili da u nekim aplikacijama, kao stoje, recimo, P2P razmena datoteka,
isti proces moe biti i klijent i server, Zaista, u sistemu za P2P razmenu datoteka isti proces
moe i da preuzima i da predaje datoteke. Ipak, u kontekstu komunikacione sesije izmeu dva
procesa uvek jedan od njih moemo da nazovemo klijentskim a drugi serverskim. Evo na koji
nain definiemo ova dva procesa.
U kontekstu komunikacione sesije izmeu dva procesa, proces koji inicira komunikaciju
(zapoinje kontakt sa drugim procesom na poetku sesije) oznaava se kao klijent. Proces
koji eka na kontakt i tek nakon toga preduzima odreenu akciju zove se server.
NaWebu, ita inicira kontakt sa serverskim procesom; itaev proces je klijentski, a proces sa
veb servera je serverski. Kada u P2P razmeni datoteka ravnopravni korisnik A zatrai od
korisnika B da mu poalje neku konkretnu datoteku, on je tada klijent, dok korisnik B, u
kontekstu date komunikacione sesije, ima ulogu servera. U situacijama u kojima nema sumnje u
pogledu ove podele uloga nekada emo koristiti i terminologiju klijentska i serverska strana
aplikacije". Na kraju poglavlja proi emo kroz jednostavan kod klijentske i serverske strane
mrene aplikacije.
Postoji jo jedan terminoloki aspekt koji je potrebno dublje razjasniti. U odeljku 2.1.1
arhitekturu mrenih aplikacija smo podelili na klijentsko-serversku, P2P i hibridnu. Ova
klasifikacija je korisna budui da nam prua uopteni okvir za planiranje arhitekture mrenih
aplikacija. Ipak, moramo imati u vidu i injenicu da veina mrenih aplikacija, ukljuujui tu i
aplikacije sa P2P arhitekturom, u stvari obuhvata vei broj parova procesa koji su u meusobnoj
komunikaciji. Meutim, u okviru jedne sesije u kojoj uestvuju dva procesa, jedan je uvek
klijent, a dmgi server.

Soketi
Kao to smo ve rekli, aplikacije u veini sluajeva imaju dva procesa na dva razliita raunara
i ti procesi izmeu sebe komuniciraju korienjem mree. Procesi svoje poruke alju u mreu i
primaju poruke iz nje preko soketa. Najjednostavnije je da soket procesa zamislite kao
svojevrsna vrata dalog procesa, koji bi, opet, mogao da se poistoveti sa kuom. Kada neki
proces eli da poalje poruku drugom procesu, on tu poruku izbacuje u mreu kroz svoja vrata
(soket). Pri tom, on pretpostavlja da s druge strane njegovih vrata postoji transportna
infrastruktura koja e poruku preneti kroz Internet sve do vrata odredinog procesa. Kada dospe
do odredinog raunara, poruka prolazi kroz vrata primajueg procesa (soket), koji zatim moe
da preduzme traenu akciju.


Na slici 2.3 ilustrovano je komuniciranje soketa dva procesa preko Interneta. (Na ovoj slici
pretpostavlja se da se u osnovi ove komunikacije nalazi protokol TCP, iako to na Internetu moe
da bude i protokol UDP.) Kao to moete da vidite, soket je interfejs koji se nalazi izmeu
aplikacijskog i transportnog sloja raunara. Naziva se jo i aplikacijski programski interfejs
(Application Programming Interface, API) i slui za posredovanje izmeu aplikacije i mree,
budui da su upravo kori-enjem ovog programskog interefejsa napravljene mrene aplikacije
na Internetu. Programer aplikacije moe da kontrolie sve ono to se dogaa na strani aplikacij-
skog sloja soketa, ali ne i ono to se dogaa sa njegove druge strane - u transportnom sloju.
Jedino na ta programer moe da utie u transportnom sloju jesu 1) izbor transportnog protokola
i 2) eventualno postavljanje nekoliko parametara transportnog sloja, kao to su maksimalan
iznos privremene memorije ili maksimalna veliina segmenta. Onog trenutka kada se programer
opredeli za odreeni transportni protokol (ukoliko uopte ima mogunost izbora), on pravi
aplikaciju imajui u vidu usluge transportnog sloja datog protokola. O soketima emo detaljnije
govoriti u odeljcima 2.7 i 2.8.

Adresiranje procesa
Da bi jedan proces mogao da poalje poruku procesu na drugom raunaru, on najpre mora da
prepozna taj prijemni proces. Za prepoznavanje prijemnog procesa obino
su potrebne dve informacije: 1) ime ili adresa raunara i 2) identifikator kojim se u odredinom
raunaru naznaava prijemni proces.
Zadrimo se najpre na adresi raunara. U intemetskim aplikacijama odredini raunar se
identifikuje svojom IP adresom. O IP adresama emo detaljnije govoriti u poglavlju 4. Zasad,
dovoljno je da znate samo to da IP adresa predstavlja 32-bitni broj koji jedinstveno identifikuje
raunar. (Najpreciznije je rei da ona jedinstveno identifikuje mreni interfejs kojim je raunar
povezan sa Internetom.) S obzirom na to da IP adresa svakog raunara koji je povezan' sa
Internetom mora biti globalno jedinstvena, dodeljivanjem IP adresa upravlja se izuzetno
paljivo, o emu emo takoe govoriti u poglavlju 4.
Osim poznavanja adrese raunara kome se poruka upuuje, otpremna aplikacija mora da
obezbedi i informacije koje e odredinom raunaru omoguiti da usmeri poruku ka pravom
procesu. Na Internetu se u tu svrhu koriste brojevi portova. Popularnim protokolima
aplikacijsknog sloja dodeljeni su odreeni brojevi portova. Primera radi, veb serverski procesi
identifikuju se brojem porta 80, dok se serverski procesi za elektronsku potu (pod protokolom
SMTP) identifikuju brojem 25. Spisak poznatih brojeva portova za sve standardne Internet
protokole nalazi se na adresi http://www.iana.org. Kada neki programer napravi neku novu
mrenu aplikaciju, ona mora da dobije* i novi broj porta. Vie detalja o brojevima portova
pronai ete u poglavlju 3.

2.1.3 Protokoli aplikacijskog sloja
Upravo ste videli da se meusobna komunikacija mrenih procesa odvija slanjem poruka kroz
sokete. Ali kakva je struktura ovih poruka? Koje je znaenje njihovih pojedinih polja? Kada
procesi alju poruke? Sva ova pitanja dovode nas u oblast protokola aplikacijskog sloja.
Protokoli aplikacijskog sloja definiu nain razmene poruka izmeu aplikacijskih procesa koji
se izvravaju na razliitim raunarima. Konkretnije, protokoli aplikacijskog sloja odreuju:
tipove poruka koje se razmenjuju (poruke zahteva ili poruke odgovora);
sintaksu razliitih tipova poruka, kao to su polja poruke i nain njihovog interpretiranja;
semantiku polja, odnosno, znaenje informacija u njima;
pravila za odreivanje vremena i naina na koje proces alje poruke i odgovara na njih.
Specifikacije nekih protokola aplikacijskog sloja navedenesu u RFC dokumentima, to znai da
se nalaze u javnom domenu. To je, primera radi, sluaj sa protokolom HTTP (Hypertext
Transfer Protocol [RFC 2616J). Ukoliko se programer itaa pridrava pravila o protokolu
HTTP iz RFC dokumenta, njegov ita e moi da prima veb strane sa bilo kog veb servera koji
je takoe napravljen u skladu sa tim pravilima.

53 53 53 53 POGLAVLJE 2 APLIKATIVNI SLOJ 2.1 PRINCIPI RADA MRENIH APLIKACIJA 83 83 83 83

Mnogi drugi protokoli aplikacijskog sloja vlasnitvo su pojedinaca ili organizacija i namerno se
ne nalaze u javnom domenu. Na primer, mnogi postojei proizvodi za Internet telefoniju
predstavljaju vlasnike protokole aplikacijskog sloja.
Veoma je vano napraviti razliku izmeu mrenih aplikacija i protokola aplikacijskog sloja.
Protokol aplikacijskog sloja predstavlja samo jedan (ali izuzetno znaajan) deo mrene
aplikacije. Pogledajmo nekoliko primera. Web je mrena aplikacija koja omoguava korisnicima
da, na svoj zahtev, preuzmu dokumente sa veb servera. Veb aplikacija se sastoji od velikog broja
komponenti medu kojima su standard za formatiranje dokumenata (HTML), itai vebova
(Netscape Navigator ili Microsoft Internet Exp!orer), veb serveri (za Apache, Microsoftovi i
Netscape-ovi serveri) i protokol aplikacijskog sloja. Protokol Webovog aplikacijskog sloja,
HTTP (Hypertext Transfer Protocol) [RFC 2616], definie format i redosled poruka koje
razmenjuju veb ita i veb server. Prema tome, protokol Webovog aplikacijskog sloja
predstavlja samo jedan deli veb aplikacije. Kao drugi primer mogla bi da nam poslui
aplikacija za elektronsku potu. Internetska elektronska pota takoe ima mnogo komponenti.
To su odgovarajui serveri na kojima se nalaze potanski sanduii, itai elektronske pote koji
omoguavaju korisnicima da itaju i prave poruke, standard za defmisanje strukture poruke i
protokoli aplikacijskog sloja koji definiu nain razmene poruka meu serverima, i izmeu
servera i itaa, kao i nain interpretacije odreenih segmenata (na primer, zaglavlja) date
poruke. SMTP (Simple Mail Transfer Protocol) je osnovni protokol aplikacijskog sloja za
elektronsku potu [RFC 2821]. Dakle, i kod elektronske pote, protokol aplikacijskog sloja je
samo jedna (ali veoma znaajna) komponenta itave aplikacije.

2.1.4 Koje su usluge potrebne aplikaciji?
Poseamo vas da soket predstavlja interfejs izmeu aplikacijskih procesa i transportnog
protokola. Predajna aplikacija alje poruke kroz ova vrata. Sa druge strane vrata, transportni
protokol preuzima odgovornost za prenos poruke kroz mreu, sve do istih takvih vrata
prijemnog procesa.
U mnogim mreama, a takav je sluaj i sa Internetom, postoji vie transportnih protokola.
Upravo zato je prilikom programiranja aplikacija neophodno izabrati jedan od raspoloivih
mrenih protokola. Na koji nain se donosi ova odluka? Najee tako to se paljivo proue
usluge koje obezbeuju raspoloivi transportni protokoli i onda izabere ona koja najvie
odgovara potrebama vae aplikacije. Ova situacija podsea na izbor izmeu voza i aviona za
putovanje izmeu dva grada. Svaki od ova dva naina transporta nudi razliite usluge, a vi
birate onaj koji vam vie odgovara. (Na primer, pogodnost voza je to polazite iz centra i stiete
u centar grada, dok je pogodnost aviona mnogo krae trajanje transporta.)
Koje su usluge transportnog protokola potrebne jednoj aplikaciji? Uopteno govorei,
zahtevi jedne aplikacije mogli bi da se svrstaju u tri kategorije: gubitak podataka, propusni
opseg i vreme.
Pouzdani transfer podataka
Aplikacijama, kao to su elektronska pota, instantna razmena poruka, transfer datoteka,
daljinski pristup raunaru, transfer vebovskih dokumenata i finansijskih aplikacija, potreban je
apsolutno pouzdan prenos podataka, dakle transfer bez ikakvog gubljenja podataka. Konkretno,
gubitak podataka neke datoteke ili neke finansijske transakcije mogao bi da ima katastrofalne
posledice (u drugom sluaju, po tediu ili banku). Ostale aplikacije za koje se kae da su
tolerantne na gubitak - recimo, multimedijalne aplikacije za reprodukciju ivog audio ili video
materijala, ili snimljenih audio i video materijala, mogu da podnesu izvestan gubitak podataka.
U ovim multimedijalnim aplikacijama posledica gubitka podataka moe da bude samo mali
poremeaj u reprodukciji, to ne mora da bude strano. Uticaj ovakvog gubitka na kvalitetu
aplikacije i tolerancija koliine izgubljenih paketa zavisie od aplikacije i primenjenog naina
kodiranja.
Propusni opseg
Efikasnost nekih aplikacija uslovljena je prenosom podataka odreenom brzinom. Ukoliko, na
primer, aplikacija za Internet telefoniju kodira glas u kvalitetu od 32 kb/ s, onda je neophodno da
se slanje podataka kroz mreu i njihova isporuka odredinoj aplikaciji odvijaju upravo ovom
brzinom. Ukoliko nema na raspolaganju ovaj propusni opseg, aplikacija moe ili da kodira
drugom brzinom (i dobije dovoljno propusnog opsega za novu brzinu kodiranja) ili da odustane,
budui da propusna mo upola manja od neophodne aplikacijama zavisnim od propusne moi
jednostavno nita ne znai. Danas mnoge multimedijalne aplikacije zavise od propusnog opsega,
dok se za one budue pretpostavlja da e koristiti adaptivne tehnike kodiranja, koje e im
omoguiti kodiranje sa onom brzinom bitova koja odgovara raspoloivom propusnom opsegu.
Dok aplikacije zavisne od propusne moi zahtevaju tano odreeni propusni opseg, elastine
aplikacije mogu da funkcioniu koristei onoliko koliko im je dostupno. Elektronska pota,
transfer datoteka i veb transfer predstavljaju takve elastine aplikacije. Naravno, to vie
propusnog opsega, tim bolje! Ne kae se uzalud da ovek ne moe biti previe bogat, previe
vitak i imati previe propusnog opsega!
Vreme
Poslednja kategorija usluga koje neophodne aplikacijama odnosi se na vreme. Efikasnost
interaktivnih aplikacija u realnom vremenu poput Internet telefonije, virtu-elnog okruenja,
telekonferencija i igara za vie igraa, direktno zavisi od veoma tane isporuke podataka.
Primera radi, mnoge od ovih aplikacija zahtevaju da ukupno kanjenje od jednog do drugog
kraja bude u okvirima od nekoliko stotina mili-sekundi ili ak krae. (Proitajte poglavlje 7
[Gauthier 1999; Ramjee 1994].) Duga kanjenja u Internet telefoniji, recimo, stvaraju neprirodne
pauze u komunikaciji; kod igara za vie igraa ili virtuelnih interaktivnih okruenja, duge pauze
izmeu akcije i reakcije okruenja (recimo, od igraa na drugom kraju veze) umanjuju rea-
listinost date aplikacije. I kod aplikacija koje ne funkcioniu u realnom vremenu uvek je bolje
daje kanjenje to krae, ali tu ne postoje nikakvi striktni zahtevi.

54 POGLAVLJE 2 APLIKATIVNI SLOJ
2.1 PRINCIPI RADA MRENIH APLIKACIJA 54

U tabeli sa slike 2.4 sumirane su potrebe u pogledu pouzdanosti, propusnog opsega i
vremena za neke poznate i novije Internet aplikacije. Meutim, ovde su navedeni samo neki kljuni
zahtevi nekoliko popularnijih Internet aplikacija. Nije nam bio cilj ovde da ponudimo iscrpnu
klasifikaciju, ve samo da identilikujemo neke od najznaajnijih kategorija mrenih aplikacija.

2.1.5 Usluge koje obezbeuju Internet transportni protokoli
Internet (i jo uoptenije, TCP/IP mree) obezbeduje aplikacijama dve transportne usluge - UDP
(User Datagram Prolocol) i TCP (Transmission Control Protocol). Prilikom pravljenja nove
aplikacije za Internet, programer mora da se opredeli za jedan od ova dva protokola. Svaki od njih
obezbeduje neto drugaije usluge aplikacijama koje ga koriste.
TCP usluge
U model TCP usluga spadaju usluga konekcije i usluga pouzdanog transfera podataka. Kada neka
aplikacija pozove protokol TCP kao svoj transportni protokol, ona od njega dobjja obe ove usluge.
, Usluga konekcije: Kod protokola TCP tok poruka aplikacijskog sloja poinje pre razmene poruka
na aplikacijskom nivou izmeu klijenta i servera. Ovaj postupak poetne sinhronizacije
upozorava klijenta i server i omoguava im da se pripreme za razmenu paketa. Po okonanju
sinhronizacije kae se daje uspostavljena TCP konekcija izmeu soketa dva procesa. Re je o
punoj dupleksnoj vezi u kojoj oba procesa mogu istovremeno da alju svoje poruke. Kada zavri
sa slanjem
poruka, aplikacija mora da raskine konekciju. Ova usluga opisuje se kao usluga sa konekcijom a
ne usluga konekcije", zato to su dva procesa povezana na veoma neobavezujui nain. U
poglavlju 3 emo detaljno istraiti usluge konekcije i vidett na koji nain se one implementiraju.
Usluga pouzdanog transporta: Procesi koji komuniciraju mogu slobodno da se oslone na
protokol TCP i da budu sigurni da e svi podaci biti isporueni bez greke i pravilnim
redosledom. Kada jedna strana aplikacije prosledi niz bajtova u soket, ona moe da rauna da
e protokol TCP isporuiti isti taj niz prijemnom soketu, bez gubitaka ili dupliranja bajtova.
U okviru protokola TCP postoji i mehanizam za kontrolu zaguenja - usluga koja pre donosi
direktnu korist samom Internetu nego komunicirajuim procesima. Ukoliko doe do zaguenja u
mrei izmeu klijenta i servera, ovaj mehanizam za kontrolu zaguenja dozira intenzitet saobraaja
koji emituje (klijenta ili servera). Kao to ete videti u poglavlju 3, mehanizam za kontrolu zaguenja
kod protokola TCP nastoji da ogranii svaku TCP konekciju na onaj deo ukupne propusne moi
mree za koji smatra daje fer.
Doziranje brzine prenosa moe da ima veoma loe posledice po audio i video aplikacije u
realnom vremenu zato to ove aplikacije imaju ogranienje po pitanju minimalne brzine prenosa. Pri
tom, aplikacije ove vrste su tolerantne na gubitak podataka i nije im potrebna potpuno pouzdana
transportna usluga. Iz tih razloga, programeri aplikacija u realnom vremenu obino daju prednost
protokolu UDP u odnosu na TCP.
Budui da smo skicirali usluge koje prua protokol TCP, recimo nekoliko reci i o uslugama koje
on ne prua. Najpre, protokol TCP ne prua garancije u pogledu minimalne brzine transporta.
Konkretno, emitujuem procesu nije dozvoljeno da to ini onom brzinom kojom eli, ve kontrola
zaguenja regulie brzinu slanja kod protokola TCP. Ona moe da prinudi otpremnu stranu da to ini
veoma malom prose-nom brzinom. Zatim, protokol TCP ne prua nikakve garancije ni u pogledu
kanjenja paketa. Kada odailjui proces prosledi svoje podatke TCP soketu, on moe da bude
siguran da e ti podaci stii do svog odredita, ali protokol TCP pri tom ne precizira apsolutno nita u
pogledu trajanja tog puta. Kao to su mnogi od nas iskusili na ,,World Wide Waitu", nekada je
potrebno ekati desetine sekundi, pa ak i itave minute da TCP isporui poruku (sa, na primer,
HTML datotekom) od veb servera do veb klijenta. Dakle, protokol TCP garantuje isporuku svih
podataka, ali ne prua nikakve garancije u pogledu brzine isporuke kao ni u pogledu eventualnih
kanjenja.
UDP usluge
Protokol UDP je pojednostavljeni transportni protokol sa minimalistikim modelom usluge. To je
protokol bez konekcije, kod koga sinhronizacija ne prethodi poetku komunikacije izmeu dva
procesa. UDP obezbeduje nepouzdan transfer podataka, to znai da nakon predaje paketa UDP
soketu, ne postoje garancije da e poruka zaista stii do prijemnog procesa. Osim toga, mogue je
da u porukama koje stignu do odredita bude poremeen redosled.

55 POGLAVLJE 2 * APLIKATIVNI SLOJ
2.2 WEB I HTTP 55

Kod protokola UDP ne postoji mehanizam za kontrolu zaguenja, tako da emi-tujui proces
moe da ubacuje podatke u UDP soket onom brzinom kojom eli (iako uvek postoji mogunost da
deo tih podataka ne stigne do odredita). S obzirom na to da aplikacije u realnom vremenu obino
mogu da toleriu odreeni gubitak podataka, ali istovremeno zahtevaju odreenu minimalnu brzinu
prenosa, njihovi programeri najee daju prednost protokolu UDP. Poput protokola TCP, ovaj
protokol ne prua nikakve garancije u pogledu kanjenja.
Na slici 2.5 navedeni su transportni protokoli koje koriste neke popularne Internet aplikacije.
Vidimo da aplikacije za elektronsku potu, pristup udaljenim terminalima, Web i transfer datoteka
koriste TCP. Programeri ovih aplikacija izabrali su ovaj protokol prvenstveno zato to on obezbeduje
pouzdanu transportnu uslugu, garantujui da e svi podaci stii do svog odredita. Isto tako, vidimo
da aplikacije za Internet telefoniju obino koriste UDP. Obe strane ove aplikacije moraju da alju
podatke kroz mreu brzinom koja je vea od neke minimalne brzine (slika 2.4), a to je pre mogue
uz upotrebu protokola UDP nego uz protokol TCP.
Kao to smo ranije napomenuli, ni jedan od ova dva protokola ne prua nikakve garancije u
pogledu trajanja transporta. Da li to znai da vremenski osetljive aplikacije ne mogu da se
izvravaju preko Interneta? Naravno da mogu - ve godinama se veliki broj ovakvih aplikacija
izvrava pod okriljem Interneta. Ove aplikacije funkcioniu relativno dobro zato to su napravljene
tako da se nose (koliko god je to mogue) sa ovim nepostojanjem garancija. U poglavlju 7 emo
vam prikazati nekoliko takvih programerskih trikova. Ipak, ni veoma pametan dizajn ne moe nita
da uini kod izuzetno dugotrajnih kanjenja koja pogaaju javni Internet.
Dakle, dananji Internet moe da obezbedi zadovoljavajue usluge vremenski osetljivim
aplikacijama, ali ne i garancije u pogledu vremena i propusne moi. U poglavlju 7 govoriemo i o
nekim novim uslugama, ukljuujui upravo uslugu sa garantovanim kanjenjem koja je neophodna
vremenski osetljivim aplikacijama.
2.1.6 Mrene aplikacije o kojima emo govoriti u ovoj knjizi Nove Internet
aplikacije pojavljuju se praktino svakodnevno - neke od njih su u javnom domenu, dok su druge
vlasnike. Umesto da vam, poput neke enciklopedije, prikaemo veliki broj Internet aplikacija, mi
emo se usredsrediti na manji broj vanih i popularnih aplikacija. U ovom poglavlju detaljno emo
vam prikazati pet veoma popularnih aplikacija - Web, transfer datoteka, elektronsku potu, usluge
direktorijuma i P2P razmenu datoteka. Poeemo od Weba - ne samo zato to je u pitanju enormno
popularna aplikacija, ve i zato stoje njen protokol aplikacijsknog sloja, HTTP, relativno jednostavan
i moe da poslui kao dobra ilustracija mnogih kljunih principa kod mrenih protokola. Zatim emo
prei na transfer datoteka koji predstavlja dobar kontrast protokolu HTTP i takoe omoguava
rasvetljavanje jo nekoliko principa. Nakon toga, govoriemo o elektronskoj poti, prvoj izuzetno
popularnoj Internet aplikaciji. Videete da savremene aplikacije za elektronsku potu ne koriste
jedan protokol aplikacijskog sloja, ve nekoliko njih. Govoriemo i
0 sistemu imena domena (Domain Name Svstem, DNS) koji obezbeduje uslugu direktorijuma za
Internet. Mnogi korisnici nemaju nikakav direktan kontakt sa sistemom imena domena jer se ova
usluga poziva indirektno, preko aplikacija (ukljuujui Web, transfer datoteka i elektronsku
potu).'Usluga DNS veoma lepo ilustruje nain implementiranja distribuirane baze podataka na
Internetu. Konano, govoriemo i o P2P razmeni datoteka koja, po nekim merenjima (recimo, po
obimu mrenog saobraaja) spada u grupu popularnih programa na Internetu.

2.2 Web i HTTP
Do 1990-ih Internet su za prijavljivanje na udaljene raunare, transfer datoteka sa lokalnih na
udaljene raunare i obratno, prijem i slanje vesti i elektronske pote, koristili prvenstveno istraivai,
akademski krugovi i studenti, lako su ove aplikacije bile (i jo uvek su) veoma korisne, izvan ovih
akademskih i istraivakih zajednica Internet je bio praktino nepoznat. Meutim, ranih 1990-ih
godina pojavila se nova aplikacija - World Wide Web [Bemers-Lee 1994]. Web predstavlja prvu
Internet aplikaciju koja je privukla iroku javnost. Ova aplikacija je dramatino izmenila nain
interakcije ljudi unutar njihovih radnih okruenja i izvan njih. Web je podigao Internet od samo jedne
od mnogih mrea za razmenu podataka (poput onlajn mrea, kao to su Prodigy, America Online i
CompuServe, nacionalne francuske mree Minitel/ Transpac, privatne mree X.25 i Frame Relay
mrea) do pozicije neprikosnovene i najvee mree za razmenu podataka.
Kroz istoriju ima mnogo primera elektronskih i komunikacionih tehnologija koje su imale
krupne socijalne posledice. Prvu ovakvu tehnologiju predstavljao je telefon koji je izmiljen 1870-ih.
Telefon je prvi put omoguio dvema osobama koje se nalaze na razliitim lokacijama da
komuniciraju u realnom vremenu. Sledeu znaajnu tehnologiju za elektronsku komunikaciju
predstavljalo je emitovanje radio
1 televizijskih signala 1920-ih i 1930-ih. Radio i televizijske emisije su omoguile ljudima da primaju
ogromne koliine zvunih i video informacija. Sledea komuni-

2.2 WEB I HTTP 56 56 56 56

kaciona tehnologija koja je bitno izmenila ivot i rad velikog broja ljudi bio je Internet. Dve
njegove najpopularnije aplikacije - elektronska pota i Web - iz korena su izmenile nae ivote.
O elektronskoj poti govoriemo u odeljku 2.4, a o Webu i njegovim protokolima aplikacijskog
sloja ve u ovom.
Veini ljudi najvie se svia to to Web funkcionie na zahtev. To znai da korisnici
primaju one informacije koje ele i onda kada to ele. Ovo se razlikuje od radio i televizijskih
emisija u kojima se od korisnika trai da se ukljue" onda kada stanica odreene sadraje stavi
na raspolaganje. Pored toga to funkcionie na zahtev, Web ima i mnoge druge izuzetne funkcije
koje su ga uinile veoma popularnim. Svaki pojedinac na krajnje jednostavan nain moe da
ponudi neku informaciju putem Weba; dakle, svi mogu da postanu izdavai uz minimalne
izdatke. Zatim, hiperveze i pretraivai olakavaju navigaciju kroz pravi okean veb lokacija.
Grafiki elementi stimuliu naa ula. Obrasci, jezik JavaScript, Java apleti i Active X, kao i
mnoge druge komponente, omoguavaju interakciju sa veb stranicama i veb lokacijama. Dalje,
Web obezbeduje interfejs za pristup ogromnim koliinama zvunog i video materijala koji se
uva na Internetu. Ovim i drugim multimedijalnim sadrajima pristupa se takoe na zahtev.
2.2.1 Prikaz protokola HTTP
U samom srcu Weba nalazi se protokol HTTP {HyperText Transfer Protocol) - protokol
njegovog aplikacijsknog sloja. HTTP je defmisan dokumentima [RFC 1945] i [RFC 2616], a
implementira se u dva programa - klijentskom i serverskom. Klijentski i serverski programi, koji
se izvravaju na dva razliita raunara, komuniciraju razmenom HTTP poruka. Protokol HTTP
definie strukturu tih poruka i naina na koji ih klijent i server razmenjuju. Pre nego to detaljno
objasnimo protokol HTTP, ne bi bilo loe da najpre usvojimo vebovsku terminologiju.
Veb strana (ili dokument) sastoji se od objekata. Objekat je jednostavno datoteka - HTML
datoteka, JPEG slika, GIF slika, Java aplet, zvuna datoteka - koju je mogue adresirati jednim
uniformnim lokatorom resursa (Uniform Resource Loca-tor, URL). Veb stranice se u veini
sluajeva sastoje od osnovne HTML datoteke i nekoliko referenciranih objekata. Ukoliko,
primera radi, veb strana sadri HTML tekst i pet JPEG slika, onda ona ima est objekata:
osnovnu HTML datoteku i pet slika. Osnovna HTML datoteka referencira ostale objekte na
strani putem njihovih URL-ova. Svaki URL ima dve komponente: ime servera na kome se dati
objekat nalazi i putanju na kojoj se on nalazi na tom serveru. Na primer, u URL-u
www.someSchool.edu/someDepartment/picture.gif
deo www . someSchool. edu predstavlja ime raunara, dok je /someDepar-tment/picture . gif
putanja do objekta. ita je korisniki agent za Web; on prikazuje traene veb strane i
obezbeduje razne navigacione i konfiguracione funkcije. Pored toga, veb itai implementiraju i
klijentsku stranu protokola HTTP. Prema tome, u kontekstu Weba ravnopravno emo koristiti
termine ita i klijent. U popularne itae Weba spadaju Netscape Communicator i
Microsoftov Internet Explorer. Veb server je raunar u kome se nalaze veb objekti koji se
adresiraju
navoenjem URL-a. Osim toga, veb serveri implementiraju serversku stranu protokola HTTP. U
popularne servere spadaju Apache i Microsoftov Internet Information Server. Netcraft je dobar
izvor gde ete pronai lepo istraivanje posveeno veb ser-verima [Netcraft 2004].)
Protokol HTTP definie nain na koji veb klijenti (recimo, itai) trae veb strane od veb
servera, kao i nain na koji veb serveri alju traene strane klijentima. Kasnije emo posvetiti
vie panje interakciji izmeu klijenta i servera; sada emo o tome dati samo nekoliko
najosnovnijih informacija (slika 2.6). Kada korisnik zatrai neku veb stranicu (miem izabere
hipervezu), ita alje serveru HTTP poruke zahtevajui objekte sa date stranice. Server prima
ove zahteve i odgovara HTTP porukama u kojima se nalaze traeni objekti. Do 1997. godine
praktino svi itai i serveri implementirali su protokol HTTP/1.0 - verziju koja je definisana
dokumentom RFC 1945. Od 1998. godine, neki serveri i itai poeli su da implementiraju
HTTP/1.1 - verziju koja je definisana u dokumentu RFC 2616. Protokol HTTP/1.1 je
kompatibilan unazad sa verzijom HTTP/1.0, to znai da veb server pod verzijom 1.1 moe da
komunicira sa itaem pod verzijom 1.0, a ita pod verzijom 1.1 moe da komunicira sa
serverom pod verzijom 1.0. S obzirom na to da je protokol HTTP/1.1 sada dominantan, u ovoj
knjizi emo pod protokolom HTTP uvek misliti upravo na ovu, noviju verziju.
Protokol HTTP kao osnovni transportni protokol koristi TCP (koji se ne izvrava povrh
protokola UDP). Evo kako ova komunikacija izgleda. HTTP klijent najpre treba da inicira TCP
konekciju sa serverom. Nakon uspostavljanja konekcije, procesi itaa i klijenata pristupaju
TCP-u kroz svoje sokete. Kao to smo rekli u odeljku 2.1, na klijentskoj strani soket predstavlja
vrata izmeu klijentskog procesa i TCP konekcije; na serverskoj strani to su vrata izmeu
serverskog procesa i TCP konekcije,

2.2 . WEB I HTTP 57 57 57 57

Klijent alje svoje HTTP poruke sa zabtevima preko svog soketa i preko njega prima sve
HTTP odgovore. Slino tome, HTTP server iz svog soketa prima poruke i svoje odgovore
ponovo alje kroz soket. Onog trenutka kada klijent poalje svoju poruku ka svom soketu, ona
vie nije u njegovim rukama, ve u rukama protokola TCP. Podseamo vas na odeljak 2.1 u
kome smo rekli da protokol TCP obezbeduje pouzdanu uslugu transfera podataka protokolu
HTTP. To znai da svaka poruka sa HTTP zahtevom koju emituje neki klijent mora
neizmenjena da stigne do servera. Isto tako, svaka poruka sa HTTP odgovorom koju server
poalje mora neizmenjena da stigne do klijenta. I upravo ovde naziremo jednu od velikih
prednosti slojevite arhitekture - protokol HTTP uopte ne mora da razmilja o gubitku podataka i
nainima na koje ih protokol TCP obnavlja ili ispravlja greke u vezi sa njihovim redosle-dom.
To je posao protokola TCP i protokola u niim slojevima familije protokola.
Veoma je vano naglasiti da server alje traene datoteke klijentu bez ikakvog evidentiranja
informacija o statusu klijenta. Ukoliko neki klijent u roku od nekoliko sekundi dvaput zatrai isti
objekat, server nee odgovoriti obavetenjem da gaje upravo usluio. On e traeni objekat
poslati ponovo, nesvestan toga daje to ve jednom uinio. S obzirom na to da HTTP server ne
odrava nikakve informacije o klijentima, za ovaj protokol se kae daje protokol bez
nadgledanja stanja.
Na ovom mestu elimo da vas podsetimo na odeljak 2.1 u kojem smo rekli da Web koristi
klijentsko-serversku arhitekturu. Veb server je uvek dostupan, ima nepromenljivu IP adresu i
svojim uslugama odgovara na zahteve nekada i miliona razliitih itaa.
2.2.2 Nepostojane i postojane konekcije
Protokol HTTP moe da koristi i nepostojane i postojane konekcije. Iako ovaj protokol u svom
podrazumevanom reimu koristi postojane veze, HTTP klijenti i serveri mogu da se konfiguriu
i tako da koriste nepostojane konekcije. U ovom odeljku ispitaemo ijednu i drugu vrstu
konekcija.
Nepostojane konekcije
Proimo sada kroz postupak prenoenja veb stranice od servera do klijenta putem nepostojanih
konekcija. Pretpostavimo da se data stranica sastoji od osnovne HTML datoteke i deset JPEG
slika i da se svih 11 objekata nalazi na istom serveru. Pretpostaviemo i daje URL osnovne
HTML datoteke
www.someSchool.edu/someDepartment/home.index
Evo ta se deava:
1. HTTP klijent inicira TCP konekciju sa serverom www. someSchool. edu na portu 80 stoje
podrazumevani broj porta za protokol HTTP.
2. HTTP klijent alje serveru poruku sa HTTP zahtevom preko soketa koji je povezan sa TCP
konekcijom koja je uspostavljena u prvom koraku. U okviru ove poruke nalazi se i ime
putanje /sorneDepartment/home . index. (Uskoro emo neto detaljnije govoriti o HTTP
porukama.)
4. HTTP server prima poruku sa zahtevom preko soketa i njemu pridruene konekcije,
uitava objekat /someDepartment/home. index iz svog prostora za skladitenje (RAM
memorija ili disk) i zatim ga enkapsulira u poruku sa HTTP odgovorom koju, preko svog
soketa, alje klijentu.
5. HTTP server potom nalae protokolu TCP da zatvori TCP konekciju. (Protokol TCP ovu
konekciju, meutim, ne prekida sve dok se sasvim ne uveri u to daje poruka neizmenjena
stigla do klijenta.)
6. HTTP klijent prima poruku sa odgovorom i TCP konekcija se prekida. U poruci je
naznaeno da je enkapsulirani objekat HTML datoteka. Klijent izvlai traenu HTML
datoteku iz poruke, zatim je ispituje i pronalazi reference do deset JPEG objekata.
7. Potom se za svaki od referenciranih JPEG objekata ponavljaju prva etiri koraka
ovog postupka.
ita prikazuje korisniku primljenu veb stranicu. Uvek postoji mogunost da dva razliita
itaa interpretiraju (odnosno, prikau) veb stranicu na dva razliita naina. To, meutim, nema
nikakve veze sa protokolom HTTP koji ne definie nain na koji ita prikazuje veb strane.
HTTP specifikacijama ([RFC 1945] i [RFC 2616]) definisan je samo komunikacioni protokol
izmeu klijentskog HTTP programa i ser-verskog HTTP programa.
U prethodnom postupku koriene su nepostojane veze budui da je svaka TCP konekcija
zatvarana nakon Stoje server poslao objekat - ona ne traje (ne postoji) za ostale objekte.
Skreemo vam panju na to da svaka TCP konekcija prenosi tano jednu poruku sa zahtevom i
jednu poruku sa odgovorom. Prema tome, u ovom primeru, od trenutka kada je korisnik zatraio
veb stranu uspostavljeno je 11 TCP konekcija.
U koracima koje smo upravo naveli namerno smo bili nedovoljno konkretni u pogledu toga
da li je deset JPEG slika klijent dobio putem deset serijskih TCP konekcija, ili su neke od njih
dobijene putem paralelnih konekcija. U stvari, korisnici savremenih itaa mogu razliitim
nainima konfigurisanja da kontroliu stepen paralelizma. U svojim podrazumevanim reimima
veina itaa otvara pet do deset paralelnih TCP konekcija i svakom od njih odvija se jedna
transakcija tipa zahtev-odgovor. Ukoliko korisnik to eli, on moe da ogranii broj paralelnih
konekcija na samo jednu i u tom sluaju u ovom primeru bi bilo uspostavljeno deset serijskih
konekcija. Kao to ete videti u sledeem poglavlju, korienje paralelnih konekcija ubrzava
odziv.
Pre nego to nastavimo, pokuaemo da procenimo koliko vremena proe od trenutka kada
klijent zatrai osnovnu HTML datoteku pa do trenutka kada se prenese cela traena datoteka na
stranu klijenta. Za potrebe ovog rauna definisaemo vreme povratnog puta (round-trip time,
RTT) kao vreme koje je potrebno malom paketu za put od klijenta do servera i natrag. RTT
vreme obuhvata kanjenja usled prostiranja paketa, zatim kanjenja usled stajanja u redu u
posredujuim ruterima i komulatorima, kao i kanjenja usled obrade paketa (o ovim
kanjenjima govorili smo u odeljku 1.6). Zamislite sada ta se deava kada korisnik izabere
neku hiper-

92 92 92 92 POGLAVLJE 2 APLIKATIVNI SLOJ 2.2 WEB I HTTP 58 58 58 58

vezu. Kao to moete da vidite na slici 2.7, ita odmah inicira TCP konekciju sa veb serverom.
Ovo uspostavljanje konekcije obuhvata trodelnu sinhronizaciju" - klijent alje mali TCP
segment serveru, server potvruje i odgovara malim TCP segmentom i, konano, klijent serveru
alje potvrdu o prijemu. Jedan RTT ciklus istie nakon zavretka prva dva dela sinhronizacije.
Nakon zavretka prva dva dela sinhronizacije, klijent kombinuje HTTP poruku (koja sadri
zahtev) sa treim delom trodelne sinhronizacije (sa potvrdom) i alje ih istom TCP konekcijom.
Kada poruka sa zahtevom stigne do servera, on alje HTML datoteku TCP konekcijom. Ovom
HTTP komunikacijom tipa zahtev/odgovor zatvara se jo jedan RTT ciklus. Dakle, uopteno
govorei, ukupno vreme odziva dobija se sabiranjem dva RTT ciklusa i trajanja prenosa HTML
datoteke od servera do klijenta.
Postojane veze
Nepostojane veze imaju svoje nedostatke. Najpre, za svaki traeni objekat mora da se uspostavi i
odrava nova konekcija. Svakoj od ovih konekcija dodeljuje se privremena TCP memorija, a uz
to, na klijentu i serveru moraju da se odravaju parametri date konekcije. Sve ovo moe u
znaajnoj meri da optereti veb server koji nekada
mora istovremeno da usluzi zahteve nekoliko stotina razliitih klijenata. Zatim, kao to smo
upravo opisali, svaki objekat ima kanjenje isporuke od dva RTT ciklusa -jedan se potroi za
uspostavljanje TCP konekcije, a drugi prilikom traenja i prijema objekta.
Kod postojanih konekcija, server nakon slanja svog odgovora klijentu ostavlja TCP
konekciju otvorenom i njome mogu da se poalju i svi naknadni zahtevi i odgovori koje razmene
klijent i server. Konkretno, to znai da istom, postojanom TCP konekcijom moe da se poalje
itava veb stranica - u naem prethodnom primeru to su osnovna HTML datoteka i svih deset
slika. tavie, istom postojanom TCP konekcijom klijentu moe da se poalje i vie veb stranica
ukoliko se one nalaze na istom serveru. Obino HTTP server prekida ovakvu vezu nakon isteka
odreenog vremena njenog nekorienja (ovaj vremenski interval moe da se podesi).
Postoje dve verzije postojanih konekcija - konekcije bez cevovodne obrade i veze sa
cevovodnom obradom. U verziji bez cevovodne obrade klijent moe da izda novi zahtev tek
nakon prijema odgovora na prethodni zahtev. U ovom sluaju klijent se suoava sa jednim RTT
ciklusom za traenje i prijem svakog referencira-nog objekta (deset slika u prethodnom
primeru). Iako ovo predstavlja poboljanje u odnosu na nepostojane veze u kojima su za svaki
pojedinani objekat potrebna dva RTT ciklusa, RTT kanjenje moe jo vie da se skrati
cevovodnom obradom. Druga mana konekcija bez cevovodne obrade jeste to to nakon slanja
objekta sa servera, postojana konekcija miruje - ne radi ba nita - ekajui dolazak novog
zahteva. U ovom stanju mirovanja ne koriste se na optimalan nain serverski resursi.
U svom podrazumevanom reimu protokol HTTP/1.1 koristi postojane cevovodne veze.
Kod cevovodnih konekcija HTTP klijent izdaje zahtev im naie na neku referencu. To znai da
on moe da izda uzastopne zahteve za referencirane objekte - dnigim recima, moe da poalje
novi zahtev pre nego to dobije potvrdu o prijemu prethodnog. Kada primi uzastopne zahteve,
server na isti nain (uzastopno) alje traene objekte. Kod cevovodne obrade mogue je da samo
jedan RTT ciklus bude potreban za prijem svih referenciranih objekata (kod konekcija bez
cevovodne obrade potreban je po jedan RTT ciklus za svaki referencirani objekat). Konano,
cevovodna TCP konekcija se i krae nalazi u stanju mirovanja. U domaim zadacima ovog i
narednog poglavlja izvriemo i kvantitativno poredenje performansi nepostojanih i postojanih
konekcija. itaoce koje ova tema posebno zanima upuujemo na dela [Heidemann 1997;Nielsen
1997].

2.2.3 Format HTTP poruke
Specifikacije protokola HTTP [RFC 2616] obuhvataju i definicije formata HTTP poruka.
Postoje dve vrste HTTP poruka - poruke sa zahtevima i poruke sa odgovorima i o obema emo
govoriti u odeljcima koji slede.
HTTP poruka sa zahtevom
Evo kako izgleda uobiajena HTTP poruka sa zahtevom:

59 POGLAVLJE 2 APLIKATIVNI SLOJ
2.2 . WEB 1 HTTP 59

Posmatrajui ovu jednostavnu poruku sa zahtevom mogli bismo mnogo toga da nauimo. Pre
svega, ona je napisana u standardnom ASCII tekstu, tako da i korisnik koji je proseno
raunarski pismen moe da je proita. Zatim, ona se sastoji od pet redova iza kojih dolazi znak
za povratak na poetak reda i znak za novi red. Iako ova poruka sa zahtevom ima pet redova,
poruke ove vrste mogu imati i mnogo vie redova, ali i samo jedan red. Prvi red HTTP poruke
sa zahtevom naziva se red zahteva; svi ostali redovi su redovi zaglavlja. Red zahteva ima tri
polja - polje za metod, URL polje i polje sa HTTP verzijom. U polju za metod moe da se nade
nekoliko razliitih metoda, kao to su, na primer, GET, POST i HEAD. Velika veina HTTP
poruka sa zahtevom koristi metod GET. Ovaj metod se koristi kada ita trai objekat koji je
identifikovan u URL polju. U ovom primeru ita od servera zahteva objekat /somedir/page .
html. to se polja sa verzijom tie, ono samo sebe dovoljno dobro objanjava - ita u ovom
primeru implementira protokol HTTP/1.1.
Pogledajmo sada redove zaglavlja naeg primera. Linijom zaglavlja Host: www .
someschool. edu navodi se raunar na kome se traeni objekat nalazi. Moda vam se ini da
ovaj red zaglavlja nije neophodan, budui daje ve uspostavljena TCP konekcija sa raunarom.
Meutim, kao to ete videti u odeljku 2.2.6 informacija o zaglavlju neophodna je veb ke
serverima. Redom Connection : close ita dalje govori serveru da ne eli da koristi postojane
veze, ve da se veza prekida im server poalje traeni objekat. Dakle, i pored toga to
implementira protokol HTTP/1.1, ita ne eli postojanu vezu. Redom zaglavlja User-agent:
navodi se korisniki agent, odnosno, vrsta itaa koji je poslao zahtev. U ovom sluaju to je
program Mozilla/4.0, Netscapeov ita. Ovaj red zaglavlja je veoma koristan zato to
omoguava serveru da razliitim tipovima korisnikih agenata poalje razliite verzije istog
objekta. (Svaka verzija adresirana je istim URL-om.) Konano, zaglavljem Accept-language :
navodi se da bi korisnik voleo da primi francusku verziju objekta, ukoliko takva postoji na
serveru; u suprotnom, server e da poalje podrazumevanu verziju traenog objekta. Zaglavlje
Accept-language : je samo jedno od mnogih kojima se u okviru protokola HTTP pregovara o
sadraju.
Poto smo zavrili sa primerom, pogledajmo kako izgleda opti format zahteva (slika 2.8).
Ve na prvi pogled vidi se da opti format striktno prati na prethodni primer. Ipak, moda ste
primetili da nakon redova zaglavlja (i dodatnih znakova za prelazak u novi red i povratak na
poetak reda) sledi telo poruke". Ono je, dodue, prazno kod metoda GET, ali se koristi kod
metoda POST. HTTP klijent esto koristi metod POST kada korisnik ispunjava neki obrazac -
primera radi, kada u odgovara-
jue polje pretraivaa upisuje kljune rei. Kod poruke tipa POST korisnik jo uvek od veb
servera trai odreenu veb stranicu, ali e njen konkretan sadraj zavisiti od onoga stoje korisnik
upisao u poljima obrasca. Ukoliko je kao metod izabran POST, onda se u telu poruke nalazi
ono Stoje korisnik upisao u poljima obrasca.
Bili bismo zbilja nemarni kada ne bismo rekli i to da zahtev koji je generisan obrascem ne
mora uvek da koristi metod POST. HTML obrasci esto koriste i metod GET i tako prenose
unete podatke (u polja obrasca) do datog URL-a. Na primer, ako obrazac koristi metod GET,
ima dva polja u koja je upisano monkeys i bananas, onda e URL imati strukturu www .
somesite . com/animalsearch?monke-ys&bananas. U vaem svakodnevno krstarenju Webom
verovatno ste mnogo puta videli ovakav URL.
Metod HE AD veoma je slian metodu GET. Kada primi zahtev sa metodom HEAD,
server odgovara HTTP porukom, ali izostavlja traeni objekat. Programeri aplikacija esto
koriste ovaj metod prilikom identifikovanja i uklanjanja problema.
Verzija HTTP/1.0 dozvoljava korienje samo tri metoda - GET, POST i HEAD. Nasuprot
tome, specifikacija HTTP/1.1 dozvoljava korienje jo nekoliko dodatnih metoda, kao to su,
recimo, PUT i DELETE. Metod PUT esto se koristi u kombinaciji sa alatkama za objavljivanje
na Webu. On omoguava korisniku ili aplikaciji da prebaci konkretan objekat na konkretnu
putanju (direktorijum) veb servera. Metod DELETE omoguava korisniku ili aplikaciji da obrie
neki objekat sa veb servera.

60 60 60 60 POGLAVLJE 2 POGLAVLJE 2 POGLAVLJE 2 POGLAVLJE 2 APLIKATIVNI SLOJ APLIKATIVNI SLOJ APLIKATIVNI SLOJ APLIKATIVNI SLOJ 2.2 2.2 2.2 2.2 WEB l HTTP 60

HTTP poruka sa odgovorom HTTP poruka sa odgovorom HTTP poruka sa odgovorom HTTP poruka sa odgovorom
U nastavku mo U nastavku mo U nastavku mo U nastavku moete da vidite kako izgleda uobi ete da vidite kako izgleda uobi ete da vidite kako izgleda uobi ete da vidite kako izgleda uobiajena HTTP poruka sa odgo ajena HTTP poruka sa odgo ajena HTTP poruka sa odgo ajena HTTP poruka sa odgovorom. Ova poruka koju smo naveli mogla bi da predstavlja odgovor na poruku vorom. Ova poruka koju smo naveli mogla bi da predstavlja odgovor na poruku vorom. Ova poruka koju smo naveli mogla bi da predstavlja odgovor na poruku vorom. Ova poruka koju smo naveli mogla bi da predstavlja odgovor na poruku
sa zahtevom o kojoj smo pr sa zahtevom o kojoj smo pr sa zahtevom o kojoj smo pr sa zahtevom o kojoj smo prethodno govorili. ethodno govorili. ethodno govorili. ethodno govorili.
Pogledajmo malo pa Pogledajmo malo pa Pogledajmo malo pa Pogledajmo malo paljivije ovu poruku. Ona ima tri dela: inicijalni ljivije ovu poruku. Ona ima tri dela: inicijalni ljivije ovu poruku. Ona ima tri dela: inicijalni ljivije ovu poruku. Ona ima tri dela: inicijalni statusni red, est est est est redova zaglavlja i zaglavlja i zaglavlja i zaglavlja i telo poruke. Telo poruke Telo poruke Telo poruke Telo poruke
predstavlja najva predstavlja najva predstavlja najva predstavlja najvaniji deo poruke niji deo poruke niji deo poruke niji deo poruke - -- - ovde se nalazi tra ovde se nalazi tra ovde se nalazi tra ovde se nalazi traeni objek eni objek eni objek eni objekat (podaci podaci podaci podaci podaci . . .). Statusni red ima tri polja at (podaci podaci podaci podaci podaci . . .). Statusni red ima tri polja at (podaci podaci podaci podaci podaci . . .). Statusni red ima tri polja at (podaci podaci podaci podaci podaci . . .). Statusni red ima tri polja - -- - polje sa verzijom protokola, polje sa verzijom protokola, polje sa verzijom protokola, polje sa verzijom protokola,
statusni kod i odgovaraju statusni kod i odgovaraju statusni kod i odgovaraju statusni kod i odgovarajuu poruku sa statusom. U ovom primeru statusnim redom navedeno je da server koristi protokol HTTP u poruku sa statusom. U ovom primeru statusnim redom navedeno je da server koristi protokol HTTP u poruku sa statusom. U ovom primeru statusnim redom navedeno je da server koristi protokol HTTP u poruku sa statusom. U ovom primeru statusnim redom navedeno je da server koristi protokol HTTP/ 1 .1 i daje sve u redu (OK), .1 i daje sve u redu (OK), .1 i daje sve u redu (OK), .1 i daje sve u redu (OK),
odnosno, daje server prona odnosno, daje server prona odnosno, daje server prona odnosno, daje server pronaao i poslao tra ao i poslao tra ao i poslao tra ao i poslao traeni objekat. eni objekat. eni objekat. eni objekat.
Pre Pre Pre Preimo sada na redove zaglavlja. Server pomo imo sada na redove zaglavlja. Server pomo imo sada na redove zaglavlja. Server pomo imo sada na redove zaglavlja. Server pomou reda Connection : close , govori klijentu da u reda Connection : close , govori klijentu da u reda Connection : close , govori klijentu da u reda Connection : close , govori klijentu da e nakon slanja tra e nakon slanja tra e nakon slanja tra e nakon slanja traenog objekta prekinuti TCP konekciju. enog objekta prekinuti TCP konekciju. enog objekta prekinuti TCP konekciju. enog objekta prekinuti TCP konekciju.
Redom Date : navode Redom Date : navode Redom Date : navode Redom Date : navode se datum i vreme kada je server generisao i poslao HTTP odgovor. Skre se datum i vreme kada je server generisao i poslao HTTP odgovor. Skre se datum i vreme kada je server generisao i poslao HTTP odgovor. Skre se datum i vreme kada je server generisao i poslao HTTP odgovor. Skreemo vam pa emo vam pa emo vam pa emo vam panju na to da to nije vreme kada je tra nju na to da to nije vreme kada je tra nju na to da to nije vreme kada je tra nju na to da to nije vreme kada je traeni objekal eni objekal eni objekal eni objekal
napravljen ili poslednji put promenjen, ve napravljen ili poslednji put promenjen, ve napravljen ili poslednji put promenjen, ve napravljen ili poslednji put promenjen, ve vreme kada gaje server u vreme kada gaje server u vreme kada gaje server u vreme kada gaje server uitao iz svog sistema datoteka, stavio u poruku sa odgov itao iz svog sistema datoteka, stavio u poruku sa odgov itao iz svog sistema datoteka, stavio u poruku sa odgov itao iz svog sistema datoteka, stavio u poruku sa odgovorom i poslao klijentu. Redom Server : orom i poslao klijentu. Redom Server : orom i poslao klijentu. Redom Server : orom i poslao klijentu. Redom Server :
nazna nazna nazna naznaeno je daje poruku generisao veb server Apache; ovaj red odgovara redu User eno je daje poruku generisao veb server Apache; ovaj red odgovara redu User eno je daje poruku generisao veb server Apache; ovaj red odgovara redu User eno je daje poruku generisao veb server Apache; ovaj red odgovara redu User- -- -agent: HTTP poruke sa zahtevom. U redu Last agent: HTTP poruke sa zahtevom. U redu Last agent: HTTP poruke sa zahtevom. U redu Last agent: HTTP poruke sa zahtevom. U redu Last- -- -Modif ied: navodi se kada je Modif ied: navodi se kada je Modif ied: navodi se kada je Modif ied: navodi se kada je
tra tra tra traeni objekat napravljen ili poslednji put izrnenjen. Zaglav eni objekat napravljen ili poslednji put izrnenjen. Zaglav eni objekat napravljen ili poslednji put izrnenjen. Zaglav eni objekat napravljen ili poslednji put izrnenjen. Zaglavlje Last lje Last lje Last lje Last- -- -Modif ied :, kome Modif ied :, kome Modif ied :, kome Modif ied :, kome emo uskoro posvetiti ne emo uskoro posvetiti ne emo uskoro posvetiti ne emo uskoro posvetiti neto vi to vi to vi to vie pa e pa e pa e panje, izuzetno je va nje, izuzetno je va nje, izuzetno je va nje, izuzetno je vano za ke no za ke no za ke no za keiranje objekta iranje objekta iranje objekta iranje objekta - -- -
kako na lokalnom klijentu, tako i na mre kako na lokalnom klijentu, tako i na mre kako na lokalnom klijentu, tako i na mre kako na lokalnom klijentu, tako i na mrenim serverima za ke nim serverima za ke nim serverima za ke nim serverima za keiranje (oni se nazivaju i proksi serveri). U zaglavlju Content iranje (oni se nazivaju i proksi serveri). U zaglavlju Content iranje (oni se nazivaju i proksi serveri). U zaglavlju Content iranje (oni se nazivaju i proksi serveri). U zaglavlju Content- -- -Length: navodi se broj Length: navodi se broj Length: navodi se broj Length: navodi se broj bajtova objekta koji se bajtova objekta koji se bajtova objekta koji se bajtova objekta koji se
alje. Kona alje. Kona alje. Kona alje. Konano, redom zaglavlja Content no, redom zaglavlja Content no, redom zaglavlja Content no, redom zaglavlja Content- -- -Type: nazna Type: nazna Type: nazna Type: naznaava se tip datoteke koja se nalazi u telu poruke (u ovom slu ava se tip datoteke koja se nalazi u telu poruke (u ovom slu ava se tip datoteke koja se nalazi u telu poruke (u ovom slu ava se tip datoteke koja se nalazi u telu poruke (u ovom sluaju to je HTML tekst). (Tip objekta se zvani aju to je HTML tekst). (Tip objekta se zvani aju to je HTML tekst). (Tip objekta se zvani aju to je HTML tekst). (Tip objekta se zvanino no no no
nazna nazna nazna naznaava zaglavljem Content ava zaglavljem Content ava zaglavljem Content ava zaglavljem Content- -- -Type:, a ne oznakom tipa datoteke.) Type:, a ne oznakom tipa datoteke.) Type:, a ne oznakom tipa datoteke.) Type:, a ne oznakom tipa datoteke.)
Po Po Po Poto smo zajedno analizirali ovaj primer, pogledajmo kako izgleda opsti for to smo zajedno analizirali ovaj primer, pogledajmo kako izgleda opsti for to smo zajedno analizirali ovaj primer, pogledajmo kako izgleda opsti for to smo zajedno analizirali ovaj primer, pogledajmo kako izgleda opsti format poruke sa odgovorom (slika 2.9). Kao mat poruke sa odgovorom (slika 2.9). Kao mat poruke sa odgovorom (slika 2.9). Kao mat poruke sa odgovorom (slika 2.9). Kao to vidite, op to vidite, op to vidite, op to vidite, opti format ove poruke se ti format ove poruke se ti format ove poruke se ti format ove poruke se
u potpunosti poklapa sa na u potpunosti poklapa sa na u potpunosti poklapa sa na u potpunosti poklapa sa naim primerom. Recimo pone im primerom. Recimo pone im primerom. Recimo pone im primerom. Recimo poneto i o statusnim kodovima i njihovim opisima. Stat to i o statusnim kodovima i njihovim opisima. Stat to i o statusnim kodovima i njihovim opisima. Stat to i o statusnim kodovima i njihovim opisima. Statusnim kodom i odgovaraju usnim kodom i odgovaraju usnim kodom i odgovaraju usnim kodom i odgovarajuim opisom navodi se rezultat im opisom navodi se rezultat im opisom navodi se rezultat im opisom navodi se rezultat
zahteva. Evo nekih uobi zahteva. Evo nekih uobi zahteva. Evo nekih uobi zahteva. Evo nekih uobiajenih statusnih kodova i odgovaraju ajenih statusnih kodova i odgovaraju ajenih statusnih kodova i odgovaraju ajenih statusnih kodova i odgovarajuih opisa. ih opisa. ih opisa. ih opisa.
200 OK : Komanda je uspe : Komanda je uspe : Komanda je uspe : Komanda je uspeno izvr no izvr no izvr no izvrena i zahtevana informacija se vra ena i zahtevana informacija se vra ena i zahtevana informacija se vra ena i zahtevana informacija se vraa u odgovoru. a u odgovoru. a u odgovoru. a u odgovoru.
301 Moved Permanently: Tra Moved Permanently: Tra Moved Permanently: Tra Moved Permanently: Traeni objekat je trajno uklonjen; novi URL se navodi u zaglavlju Location: poruke sa odgovorom. Klijentski softver tako eni objekat je trajno uklonjen; novi URL se navodi u zaglavlju Location: poruke sa odgovorom. Klijentski softver tako eni objekat je trajno uklonjen; novi URL se navodi u zaglavlju Location: poruke sa odgovorom. Klijentski softver tako eni objekat je trajno uklonjen; novi URL se navodi u zaglavlju Location: poruke sa odgovorom. Klijentski softver tako
automatski dolazi do novog URL automatski dolazi do novog URL automatski dolazi do novog URL automatski dolazi do novog URL- -- -a. a. a. a.
400 Bad Request: Uop Bad Request: Uop Bad Request: Uop Bad Request: Uopteni kod sa gre teni kod sa gre teni kod sa gre teni kod sa grekom kojim se nazna kom kojim se nazna kom kojim se nazna kom kojim se naznaava da server ni ava da server ni ava da server ni ava da server nije razumeo primljeni zahtev. je razumeo primljeni zahtev. je razumeo primljeni zahtev. je razumeo primljeni zahtev.
404 Not Found: Tra Not Found: Tra Not Found: Tra Not Found: Traeni dokument ne postoji na serveru. eni dokument ne postoji na serveru. eni dokument ne postoji na serveru. eni dokument ne postoji na serveru.
505 HTTP Version Not Supported: Server ne podr HTTP Version Not Supported: Server ne podr HTTP Version Not Supported: Server ne podr HTTP Version Not Supported: Server ne podrava tra ava tra ava tra ava traenu ver enu ver enu ver enu verziju protokola HTTP. ziju protokola HTTP. ziju protokola HTTP. ziju protokola HTTP.
Da li biste Da li biste Da li biste Da li biste eleli da sada vidite pravu HTTP poruku sa odgovorom? Osim stoje veoma preporu eleli da sada vidite pravu HTTP poruku sa odgovorom? Osim stoje veoma preporu eleli da sada vidite pravu HTTP poruku sa odgovorom? Osim stoje veoma preporu eleli da sada vidite pravu HTTP poruku sa odgovorom? Osim stoje veoma preporuljivo, to je i krajnje jednostavno. Dakle, uspostavite Telnet ljivo, to je i krajnje jednostavno. Dakle, uspostavite Telnet ljivo, to je i krajnje jednostavno. Dakle, uspostavite Telnet ljivo, to je i krajnje jednostavno. Dakle, uspostavite Telnet
sesiju sa svojim omiljenim veb serverom. Zatim upi sesiju sa svojim omiljenim veb serverom. Zatim upi sesiju sa svojim omiljenim veb serverom. Zatim upi sesiju sa svojim omiljenim veb serverom. Zatim upiite poruku sa zahtevom du ite poruku sa zahtevom du ite poruku sa zahtevom du ite poruku sa zahtevom duine jednog reda kojom ine jednog reda kojom ine jednog reda kojom ine jednog reda kojom ete tra ete tra ete tra ete traiti neki iti neki iti neki iti neki objekat koji se nalazi na serveru. Primera radi, u objekat koji se nalazi na serveru. Primera radi, u objekat koji se nalazi na serveru. Primera radi, u objekat koji se nalazi na serveru. Primera radi, u
koman koman koman komandnoj liniji mo dnoj liniji mo dnoj liniji mo dnoj liniji moete da upi ete da upi ete da upi ete da upiete: ete: ete: ete:
telnet telnet telnet telnet cis.poly.edu cis.poly.edu cis.poly.edu cis.poly.edu 80

GET / GET / GET / GET /- -- -ross/ HTTP ross/ HTTP ross/ HTTP ross/ HTTP/1.1 Host: Host: Host: Host: c i s c i s c i s c i s .poly.edu .poly.edu .poly.edu .poly.edu
(Nakon upisivanja poslednjeg reda dvaput pritisnite tast (Nakon upisivanja poslednjeg reda dvaput pritisnite tast (Nakon upisivanja poslednjeg reda dvaput pritisnite tast (Nakon upisivanja poslednjeg reda dvaput pritisnite taster Enter.) Ovim se uspostavlja TCP konekcija sa portom er Enter.) Ovim se uspostavlja TCP konekcija sa portom er Enter.) Ovim se uspostavlja TCP konekcija sa portom er Enter.) Ovim se uspostavlja TCP konekcija sa portom 80 ra ra ra raunara www. eurecom. f r i unara www. eurecom. f r i unara www. eurecom. f r i unara www. eurecom. f r i alje alje alje alje
HTTP poruka sa zahtevom. U poruci sa odgovorom trebalo bi da ugledate osnovnu HTML HTTP poruka sa zahtevom. U poruci sa odgovorom trebalo bi da ugledate osnovnu HTML HTTP poruka sa zahtevom. U poruci sa odgovorom trebalo bi da ugledate osnovnu HTML HTTP poruka sa zahtevom. U poruci sa odgovorom trebalo bi da ugledate osnovnu HTML

2.2 WEB I HTTP 61 61 61 61

datoteku poetne strane profesora Rosa. Ukoliko biste, umesto samog objekta, vie voleli da
vidite redove HTTP poruke, metod GET zamenite metodom HEAD. Konano, zamenite i
/-ross/ reju /-banana/i pogledajte kako e izgledati odgovor.
U ovom odeljku govorili smo o raznim redovima zaglavlja koji mogu da se koriste u
HTTP porukama sa zahtevima i odgovorima. Specifikacijom protokola HTTP definisani su i
mnogi drugi redovi zaglavlja koje mogu da ubace itai, veb serveri i serveri za keiranje, a mi
smo ovde prikazali samo mali deo njihovog ukupnog broja. Vrlo brzo emo pomenuti jo neke
od njih, dok emo o nekim drugim govoriti na kraju poglavlja u odeljku 2.2.6 koji je posveen
mrenom keiranju Weba. Iscrpnu i itku diskusiju o protokolu HTTP moete da pronaete i u
delu [Krishnamurty 2001], a pogled iz perspektive programera u delu [Luotonen 1998].
Konano, preporuujemo vam i jedno odlino uvodno razmatranje Weba [Yeager 1996].
Na koji nain ita odluuje koji e se redovi nai u poruci sa zahtevom? Na koji nain
server odluuje koji e redovi zaglavlja ui u poruku sa odgovorom? Redovi zaglavlja koje
ita generie predstavljaju funkciju tipa i verzije itaa (na primer, ita tipa HTTP/1.0 nee
generisati zaglavlja tipa 1.1), zatim naina na koji gaje korisnik podesio (recimo, eljeni jezik),
kao i toga da li ita ima keiranu, ali zastarelu verziju objekta. Veb serveri se ponaaju na
slian nain - postoje razliiti proizvodi, verzije i konfiguracije, to sve utie na redove
zaglavlja koji e se nai u poruci sa odgovorom.

2.2.4 Interakcija izmeu korisnika i servera: kolaii
Neto ranije napomenuli smo da su HTTP serveri aplikacije bez nadgledanja stanja. Ova
injenica je pojednostavila njihov dizajn i omoguila programerima da razviju veoma brze veb
servere koji mogu da rukuju sa hiljadama istovremenih TCP konekcija. Ipak, postoje i situacije
u kojima je poeljno identifikovati korisnike, bilo zato to server eli da ogranii pristup
odreenim sadrajima, bilo zato to se sadraj nudi zavisno od toga koji je korisnik u pitanju.
Protokol HTTP u ovim situacijama koristi kolaie.
Kolaii, koji su definisani dokumentom RFC 2109, predstavljaju alternativan mehanizam
pomou koga veb lokacije mogu da prate korisnike. Kolaie ne koriste sve veb lokacije ve,
pre svega, veliki portali (na primer, Yahoo), kao i lokacije za elektronsku trgovinu (Amazon)
ili oglaavanje (DoubleCIick) koji ih, s druge strane, koriste u veoma velikoj meri.
Tehnologija kolaia ima etiri komponente - (1) red zaglavlja kolaia u HTTP poruci sa
odgovorom, (2) red zaglavlja kolaia u HTTP poruci sa zahtevom, (3) datoteku kolaia koja
se uva u korisnikovom krajnjem sistemu, a kojom upravlja njegov ita i (4) pozadinsku bazu
podataka koja se nalazi na veb lokaciji. Proimo sada zajedno kroz primer korienja kolaia
na koji se esto moe naii. Pretpostavimo daje Suzan, koja iz svog doma uvek pristupa Webu
putem Internet Explo-rera, prvi put kontaktirala sa nekom lokacijom za elektronsku trgovinu
koja koristi
kolaie. Odmah nakon prijema zahteva, veb server pravi jedinstveni identifikacioni broj, kao i
zapis u pozadinskoj bazi podataka koji se indeksira upravo napravljenim identifikacionim
brojem. Server e zatim da poalje odgovor Suzaninom itau u kome e se nai i zaglavlje
Set-cookie : zajedno sa identifikacionim brojem. Primera radi, ovaj red zaglavlja mogao bi da
izgleda ovako:
Set-cookie: 1678453
Kada Suzanin ita primi HTTP poruku sa odgovorom, on e ugledali i zaglavlje Set-cookie :.
ita zatim dodaje jedan red specijalnoj datoteci kolaia kojom on sam upravlja. U ovaj red
upisuju se ime servera i identifikacioni broj iz zaglavlja Set-cookie:. Dok Suzan bude
pretraivala ovu lokaciju, prilikom svakog traenja neke nove veb stranice, njen ita e
konsultovati datoteku sa kolaiem, izvui njen identifikacioni broj za ovu lokaciju i staviti ga u
zaglavlje kolaia koje se dodaje HTTP poruci sa zahtevom. Konkretno, svaki njen HTTP
zahtev upuen serveru za elektronsku trgovinu imae i red zaglavlja:
Cookie: 1678453
Na ovaj nain veb lokacija moe da prati Suzaninu aktivnost. Iako veb lokacija ne zna Suzanino
ime, ona tano zna koje je stranice posetio korisnik broj 1678453, kojim redom i u koje vreme!
Pomou kolaia ova lokacija za elektronsku trgovinu zatim moe da obezbedi uslugu kolica za
kupljenu robu - tokom odreene sesije na datoj lokaciji, server odrava listu svih Suzaninih
kupovina u cilju objedinjenog plaanja na kraju sesije.
Ukoliko se Suzan, na primer, nedelju dana kasnije vrati na ovu lokaciju, njen ita e
nastaviti da u poruke sa zahtevom stavlja zaglavlje Cookie: 1 678453. Zavisno od toga koje je
stranice Suzan posetila, lokacija za elektronsku trgovinu moe da joj preporui odreene
proizvode. Ukoliko odlui da se na ovoj lokaciji i registruje - odnosno, da upie puno ime i
prezime, e-adresu, obinu potansku adresu i informacije u vezi sa svojom kreditnom karticom,
lokacija za elektronsku trgovinu e ove informacije takoe da ubaci u svoju bazu podataka i tako
Suzanino ime povee sa njenim identifikacionim brojem (i svim stranama koje je u prolosti
posetila na daloj lokaciji!). Upravo na ovaj nain lokacije za elektronsku trgovinu obezbeuju
kupovinu jednim potezom miem" - kada Suzan u nekoj narednoj poseti odlui da neto kupi,
nee morati ponovo da upisuje svoje ime, broj kreditne kartice i adresu.
Iz ovoga moemo da zakljuimo da kolaii mogu da se koriste za identifikaciju korisnika.
Kada prvi put poseti neku lokaciju, korisnik moe da se identifikuje (recimo, navoenjem svog
imena). Nakon toga ita e proslediti zaglavlje kolaia serveru prilikom svake budue posete i
tako identifikuje korisnika na serveru. i z prethodne prie takoe moemo da zakljuimo da
kolaii mogu da se koriste za pravljenje sloja korisnikove sesije povrh protokola HTTP koji
nema nadgledanje stanja. Kada se, primera radi, korisnik prijavi na veb aplikaciji za e-potu,
ita alje

2.2 VVEBIHTTP 62 62 62 62

serveru informaciju o kolaiu, omoguavajui serveru da identifikuje korisnika tokom njegove
sesije sa aplikacijom.
Iako znaajno olakavaju i pojednostavljuju kupovinu preko Interneta, kolaii su
istovremeno i veoma kontroverzni zato to na neki nain zadiru u privatnost korisnika. Kao to
smo upravo rekli, kombinacijom kolaia i informacija o korisniku iz njegovog naloga, veb
lokacija moe da sazna dosta toga o njemu i svoja saznanja eventualno proda nekoj
zainteresovanoj kompaniji. tavie, kolaii mogu da se upotrebe i za prikupljanje informacija o
korisnikovom ponaanju na veoma velikom broju veb lokacija. Veb lokacije koje objavljuju
reklame na svojim stranicama koriste upravo HTTP zahteve da bi uzele reklame (u formatima
GIF ili JPEG) sa HTTP servera reklamne agencije. Svaki od zalueva HTTP serveru reklamene
agencije moe da sadri i kolai kojim upravlja ta agencija. S obzirom na to da reklamne
agencije na Internetu isporuuju reklame mnoigm veb lokacijama, one mogu da saine profil
neijeg ponaanja prilikom pretraivanja veb lokacija.
Na kraju ovog odeljka uputiemo vas na Persistant Client State HTTP Cookies [Netscape
Cookie 1999] u kome ete nai iscrpne i lako razumljive uvodne informacije o kolaiima.
Takode vam preporuujemo i Cookie Central [Cookie Central 2004] u kome ete pronai dosta
informacija o kontroverznim stranama kolaia.

2.2.5 HTTP sadraj
Kroz celo ovo poglavlje uzeli smo da su podaci koji se prenose u HTTP odgovorima u stvari
objekti sa veb strana - HTML, GIF i JPEG datoteke, Java apleti itd. Protokol HTTP smo
namerno predstavili u kontekstu Weba zato to smo eleli da vam damo primer koji vam je
poznat. Meutim, bio bi veliki propust ne rei da se protokol HTTP esto koristi i za transfer
mnogih drugih tipova datoteka.
Na primer, protokol HTTP se u savremenim aplikacijama za elektronsku trgovinu esto
koristi za prenos XML datoteka sa jednog raunara na drugi, a da ni na jednom od tih raunara
ne postoji ita ili korisnik. Banke esto koriste XML dokumente za strukturi sanje bankovnih
informacija (recimo, informacija o raunu korisnika), a njihovi raunari za razmenu ovih
strukturisanih informacija esto koriste upravo protokol HTTP. (Diskusija o XML dokumentima
ne spada u domen ove knjige. Ovde emo rei samo to da uobiajen XML dokument sadri
strukturisane podatke i indikaciju znaenja tih podataka; ovde obino nema indikacija o
formati-ranju kao u HTML dokumentima). Protokol HTTP se takoe koristi za transfer
Voi-ceXML, WML (markerski jezik WAP-a) i ostalih tipova XML dokumenata. tavie,
protokol HTTP esto se koristi i u P2P razmeni datoteka, to ete videti na kraju ovog poglavlja,
dok ete u poglavlju 6 videti da se veoma esto koristi i za protok audio i video sadraja u
realnom vremenu.
2.2.6 Web keiranje
Veb ke ili proksi server jeste mreni entitet koji izlazi u susret HTTP zahtevima u ime
servera porekla. Veb ke ima sopstvene diskove za skladitenje na kojima uva kopije
nedavno traenih objekata. Kao to moete da vidite na slici 2,10, ita moe da se konfigurie
tako da se svi korisnikovi HTTP zahtevi najpre usmeravaju ka veb kesu. Primera radi,
pretpostavimo da odreeni ita trai objekat http: //www. someschool. edu/campus .gif. Evo
ta se deava:
1. ita uspostavlja vezu sa veb kesom i alje mu HTTP poruku zahtevajui odreeni objekat.
2. Veb ke zatim proverava da li, moda, poseduje lokalnu kopiju traenog objekta. Ukoliko
traeni objekat postoji u veb kesu, on se, zajedno sa HTTP odgovorom, alje klijentovom
itau.
3. Ukoliko ne poseduje traeni objekat, veb ke uspostavlja TCP konekciju sa serverom
porekla (u ovom sluaju, to je server www. someschool. edu) i od njega trai dati objekat.
Nakon prijema ovog zahteva, server porekla alje traeni objekat u okviru svog HTTP
odgovora veb kesu.
4. Kada primi ovaj objekat, veb ke ga skladiti na svom disku i potom njegovu kopiju
prosleduje klijentovom itau u okviru HTTP poruke sa odgovorom (postojeom TCP
konekcijom izmeu klijentovog itaa i veb kesa).
Skreemo vam panju na to da se veb ke istovremeno ponaa i kao server i kao klijent. U
razmeni zahteva i odgovora sa klijentovim itaem, veb ke ima ulogu servera, a u razmeni
zahteva i odgovora sa serverom porekla, on je klijent.

2.2 - WE8 I HTTP
63 63 63 63

Veb ke obino kupuje i instalira posrednik za Internet usluge. Primera radi, jedan
univerzitet bi mogao da instalira veb ke u svojoj mrei, nakon ega bi svi itai u studentskom
gradu svojom konfiguracijom bili usmereni ka njemu. Isto lako, veliki rezidencija Ini posrednik
za Internet usluge (recimo AOL) mogao bi n svojoj mrei da instalira jedan ili vie ovakvih
servera i da zatim svoje iiae unapred konfigurie da ga koriste.
Postoje dva razloga zbog kojih je veb keiranje uobiajena pojava na Internetu, Najpre,
ono znaajno skrauje vreme odziva na zahtev klijenta, naroito ukoliko je usko grlo izraenije
izmeu klijentovog raunara i servera porekla nego izmeu klijentovog raunara i veb kesa.
Ako izmeu klijentovog raunara i veb kesa postoji veza velike propusne moi, a najee je
tako, i ukoliko se traeni objekat ve nalazi u vebovskoj ke memoriji, isporuka objekta
klijentovom raunaru bie mnogo bra. Zatim, kao to ete, uostalom, i videti u naem primeru,
veb keiranje znaajno smanjuje intenzitet saobraaja na pristupnom linku neke institucije
(univerziteta ili kompanije) ka Internetu. Ovo smanjivanje intenziteta saobraaja znai da
nadgradnje propusnog opsega ne moraju biti toliko este, ime se smanjuju i trokovi. tavie,
veb keiranje znaajno smanjuje intenzitet saobraaja i kada se Internet posmatra u celini, to
donosi poboljanje performansi svih njegovih aplikacija.
Da biste na najbolji mogui nain shvatili sve prednosti veb keiranja, evo jednog primera
ilustrovanog na slici 2.11. Na ovoj slici prikazane su dve mree -institucionalna mrea i javni
Internet. Institucionalna mrea je LAN velike brzine. Ruter ove mree i ruter u okviru Interneta
povezani su linkom brzine 1,5 Mb/s. Serveri porekla su povezani sa Internetom, a nalaze se
irom svela. Pretpostavimo da je veliina prosenog objekta 100 000 bitova i da institucijini
itai svake sekunde upute proseno 15 zahteva serverima porekla. Pretpostaviemo i da su
HTTP poruke zanemarljivo male tako da ne prave nikakav saobraaj u mreama ili pristupnom
linku (od institucijinog rutera do rutera u okviru Interneta). Konano, pretpostaviemo i to da od
trenutka kada ruter na strani pristupnog linka ka Internetu (slika 2.11) prosledi HTTP zahtev (u
okviru IP datagrama) do trenutka kada dobije odgovor (obino u nekoliko IP datagrama) prou
proseno dve sekunde. Potpuno neformalno, ovo kanjenje emo nazivati Internet kanjenje".
Ukupno vreme odziva - vreme koje protekne od trenutka kada ita poalje zahtev za
objekat pa do njegovog prijema - predstavlja zbir kanjenja LAN-a, kanjenja pristupnog
linka'(kanjenje izmeu dva rutera) i kanjenja Interneta. Sada emo napraviti grubu procenti
ovog kanjenja. Intenzitet saobraaja LAN-a (odeljak 1.6) iznosi:
(15 zahteva/sekundi) (100 kilobita/zahtev)/(10 Mb/s) = 0,15
gde je intenzitet saobraaja u pristupnom linku (od rutera na Internetu do rutera institucije):
(]5 zahteva/sekundi) (100 kilobita/zahtev)/(l,5 Mb/s) = 1
Intenzitet saobraaja od 0,15 u LAN-u obino povlai ekanje koje se, u najgorem sluaju,
meri desetinama milisekundi; prema tome kanjenje LAN-a moemo
da zanemarimo. Meutim, kao to smo rekli u odeljku 1.6, kako se intenzitet saobraaja
pribliava 1 (kao Stoje to sluaj na pristupnom linku na slici 2.11), kanjenje postaje due i
poveava se neogranieno. To znai da e se proseno vreme odziva na zahteve korisnika meriti
minutima, to je iz perspektive korisnika ove institucije neprihvatljivo. Sasvim je oigledno da
neto treba uiniti.
Jedno od moguih reenja bilo bi da se brzina pristupa sa 1,5 Mb/s povea na, recimo, 10
Mb/s. Ovim e se intenzitet saobraaja u pristupnom linku smanjiti na 0,15, to znai da e
kanjenja izmeu dva rutera postati zanemarljiva. U ovom sluaju ukupno vreme odziva
iznosie oko dve sekunde, koliko je i kanjenje u okviru Interneta. Meutim, ovo reenje
podrazumeva nadgradnju pristupnog linka sa 1,5 Mb/s na 10 Mb/s, to moe biti i veoma skupo.
ta bi se dogodilo kada bismo se, umesto za nadgradnju pristupnog linka, opre-delili za
instaliranje servera za veb keiranje u mrei ove institucije? Ovo reenje ilustrovano je na slici
2.12.

64 64 64 64 POGLAVLJE 64 APLIKATIVNI SLOJ 2.2 . V/EBIHTTP 105 105 105 105

Udeo pribavljenih dokumenata - broj zahteva koje zadovolji server za veb keiranje - u
praksi se obino kree izmeu 0,2 i 0,7. Za potrebe primera pretpostaviemo da veb keiranje
za ovu instituciju pribavlja dokumente u udelu od 0,4. S obzirom na to da su klijenti i server za
veb keiranje povezani istim LAN-om velike brzine, to znai da e veb keiranje 40 procenata
zahteva zadovoljiti praktino trenutno, sa vremenom odziva od, recimo, 10 milisekundi.
Preostalih 60 procenata zahteva, ipak, moraju da zadovolje serveri porekla. Meutim, kako kroz
pristupni link sada prolazi samo 60 procenata zahtevanih objekata, intenzitet saobraaja se sa
1,0 smanjio na 0,6. U praksi, intenzitet saobraaja koji je manji od 0,8 u linku brzine 1,5 Mb/s
obino rezultira kanjenjima od desetak milisekundi, to nije mnogo. Ovo kanjenje je
zanemarljivo ukoliko se uporedi sa kanjenjem Interneta od dve sekunde. Imajui u vidu sve
navedene pretpostavke, prosena vrednost kanjenja iznosi
0,4 (0,01 sekundi) + 0,6 (2,01 sekundi)

stoje tek neto malo vie od 1,2 sekunde. Prema tome, ovo drugo reenje donosi krae vreme
odziva od prvog, a ne zahteva nadgradnju linka ka Internetu. Naravno, institucija mora da kupi i
instalira server za veb keiranje, ali to je jeftinije - mnogi serveri za veb keiranje koriste softver
koji se nalazi u javnom domenu i izvrava na jeftinim personalnim raunarima.

2.2.7 Uslovno preuzimanje
Iako keiranjem moe da se skrati vreme koje korisnik primeuje, ono uvodi i jedan novi
problem - kopija objekta u ke memoriji moe da bude zastarela. Drugim recima, mogue je daje
objekat koji se nalazi na veb serveru izrnenjen nakon to je njegova kopija keirana u
klijentskom raunam. Sreom, HTTP ima mehanizam koji omoguava korienje keiranja uz
istovremenu proveru akmelnosti svih objekata koji su predati itau. Ovaj mehanizam naziva se
uslovno preuzimanje. HTTP zahtev bi mogao da se nazove uslovnim preuzimanjem ukoliko (1)
on sadri metod GET i (2) ako se u odgovoru nalazi red zaglavlja If-Modified-Since:.
Da bismo vam ilustrovali nain rada uslovnog preuzimanja, posluiemo se jednim
primerom. Najpre ita sa nekog servera trai objekat koji nema u svojoj ke memoriji.
Veb ke prosleuje traeni objekat itau koji ga je traio, ali ga i lokalno memo-rie. to je jo
vanije, veb ke zajedno sa ovim objektom keira i datum njegove poslednje izmene.
Pretpostavimo, dalje, daje korisnik nakon nedelju dana ponovo zatraio ovaj keirani objekat. S
obzirom na to daje u toku tih nedelju dana traeni objekat moda izrnenjen na veb serveru, ita
proverava njegovu aktuelnost putem uslovnog preuzimanja. Konkretno, veb ke alje sledeu
poruku:

2.65 TRANSFER DATOTEKA; PROTOKOL FTP
65 65 65 65

Skreemo vam panju na to daje vrednost zaglavlja If-modified-since: identina vrednosli
zaglavlja Last-Modif ied : iz poruke koju je server poslao pre nedelju dana. Ovim uslovnim
metodom GET serveru se govori da traeni objekat poalje samo ukoliko je on u meuvremenu
izmenjen. Pretpostavimo da objekat nije menjan od trenutka 2 Jul 2003 0 9 : 23 : 24. U lom
sluaju, veb server odgovara sledeom porukom:
Vidimo daje, kao odgovor na poruku sa uslovnim metodom GET. veb server odgovorio, ali
da u toj poruci nije bilo traenog objekta. Njegovim stavljanjem u poruku bespotrebno bi se
troila propusna mo, a odziv bi bio sporiji, naroito ukoliko je re o veem objektu. Skreemo
vam panju i na to da se u poslednjoj poruci nalazi i statusni red 304 Not Modified, kojim se
veb kesu saoptava da moe da prosledi svoju keiranu kopiju objekta.

2.3 Transfer datoteka: protokol FTP
U uobiajenoj FTP sesiji korisnik sedi ispred jednog (lokalnog) raunara i pokuava da prebaci
neke datoteke na udaljeni raunar ili sa njega. Da bi mogao da pristupi nalogu na udaljenom
raunam, korisnik mora da se identifikuje i upie svoju lozinku. Nakon upisivanja ovih
informacija za ovlaivanje, korisnik moe da pone sa transferom datoteka iz lokalnog sistema
datoteka na udaljeni ili obratno. Kao to moete da vidite na slici 2.13, korisnikova interakcija
sa protokolom FTP odvija se preko FTP korisnikog agenta. Korisnik u ovom sluaju najpre
upisuje ime udaljenog raunara, nakon ega FTP klijentski proces uspostavlja TCP konekcijom
sa FTP serverskim procesom udaljenog raunara. Nakon toga, korisnik treba da upie svoje
korisniko ime i svoju lozinku koji se zatim alju TCP konekcijom kao deo FTP komandi. im
ga server ovlasti, korisnik moe da pone da prebacuje jednu i!i vie datoteka sa lokalnog
sistema na udaljeni (ili obratno).
Protokoli HTTP i FTP pripadaju grupi protokola za transfer datoteka tako da imaju mnogo
zajednikih osobina; primera radi, oba protokola funkcioniu povrh protokola TCP. Ipak,
izmeu ova dva protokola aplikacijskog sloja postoje i neke bitnije razlike. Najoiglednija
razlika jeste to to protokol FTP za transfer datoteka koristi dve paralelne TCP konekcije -
kontrolnu konekciju i konekciju za podatke.
Kontrolna konekcija koristi se za razmenu kontrolnih informacija izmeu dva raunara. U
ovu vrstu informacija spadaju identifikacija i lozinka korisnika, komande
za izmenu udaljenog direktorijuma i komande za stavljanje" i uzimanje" datoteka. Konekcija
za podatke obino se koristi za prenos datoteka. S obzirom na to da kod protokola FTP postoji
posebna kontrolna konekcija, kae se da ovaj protokol svoje kontrolne informacije alje izvan
opsega. U poglavlju 7 videete da protokol RTSP, koji se koristi za kontrolu transfera
kontinuiranih medija, kao stoje audio ili video materijal, takoe svoje kontrolne informacije
alje izvan opsega. Podseamo vas da protokol HTTP redove zaglavlja zahteva i odgovora alje
istom TCP konekcijom kojom se prenosi i sama datoteka. Zato se za protokol HTTP kae da
svoje kontrolne informacije alje u opsegu. U sledeem odeljku videete da protokol SMTP,
koji se koristi za prenos elektronske pote, takoe svoje kontrolne informacije alje u opsegu.
Na slici 2.14 ilustrovali smo kontrolnu vezu i vezu za podatke protokola FTP.
Kada korisnik pokrene FTP sesiju sa udaljenim raunarom, klijentska strana protokola FTP
(korisnik) najpre inicira kontrolnu TCP konekciju sa serverskom stranom (udaljeni raunar) i to
na serverovom portu broj 21. Klijentska strana protokola FTP ovom kontrolnom vezom potom
alje identifikaciju i lozinku korisnika, kao i komande za izmenu udaljenog direktorijuma. Kada
serverska strana ovom kontrolnom vezom primi komande za transfer datoteka (sa tog raunara
ili na njega), ona inicira uspostavljanje TCP konekcije za podatke do klijentske strane. Protokol
FTP ovom konekcijom za podatke alje samo jednu datoteku i odmah zatim je prekida. Ukoliko,
tokom iste sesije, korisnik eli da prebaci jo neku datoteku, protokol FTP uspostavlja novu
vezu za podatke. Dakle, kod protokola FTP kontrolna konekcija ostaje otvorena tokom cele
korisnikove sesije, dok se za svaku novu datoteku uspostavlja i nova konekcija za podatke
(konekcije za podatke nisu postojane).
Tokom sesije FTP server mora da odrava statusne informacije o korisniku. Konkretno,
server mora da povee kontrolnu vezu sa konkretnim korisnikim nalogom, ali i da prati
njegovo kretanje kroz stablo direktorijuma. Neophodnost praenja ovih informacija za svaku
korisniku sesiju znaajno ograniava ukupan broj sesija

2.4 - ELEKTRONSKA POTA NA INTERNETU 109 109 109 109

koje protokol FTP moe da odrava istovremeno. Podseamo vas da, nasuprot tome, protokol
HTTP nema nadgledanje stanja - odnosno, on ne evidentira nikakve informacije o statusu
korisnika.
2.3,1 FTP komande i odgovori
Ovaj odeljak zavriemo kratkom priom o FTP komandama koje se esto koriste. Komande
(od klijenta do servera) i odgovori (od servera ka klijentu) alju se kontrolnom vezom u
sedmobitnom ASCII formatu. To znai da, poput HTTP komandi, ove komande ljudi mogu da
proitaju. Da bi se susedne komande razdvojile, iza svake komande nalazi se znak za povratak
na poetak reda i znak za prelazak u novi red. Svaka komanda ispisana je pomou etiri ASCII
znaka (velika slova) uz dodatak nekih opcionih argumenata. Evo nekih komandi koje se
najee upotrebljavaju:
USER username: Koristi se za slanje korisnikove identifikacije serveru.
PASS password: Koristi se za slanje korisnikove lozinke serveru.
LIST: Koristi se za traenje liste svih datoteka koje se nalaze u aktuelnom dire-ktorijumu
udaljenog servera. Lista datoteka alje se (novom i nepostojanom) konekcijom za podatke, a
ne kontrolnom TCP konekcijom.
RETR f ilename: Koristi se za prijem (odnosno, dobijanje) datoteke iz aktu-elnog
direktorijuma udaljenog raunara. Podstie udaljeni raunar da inicira konekciju za podatke
i njom poalje traenu datoteku.
STOR f ilename: Koristi se za skladitenje (odnosno, stavljanje) datoteke u aktuelni
direktorijum udaljenog raunara.
Komande koje korisnik izda i FTP komande koje se poalju kontrolnom vezom, obino
stoje u odnosu jedan na jedan. Iza svake komande dolazi i odgovor koji server poalje klijentu.
Ovi odgovori su obino trocifreni brojevi iza kojih se nalazi opciona poruka. Po svojoj strukturi
oni podseaju na statusne kodove i opise u statusnom redu HTTP odgovora; kreatori protokola
su namerno insistirali na ovoj slinosti. Evo nekih uobiajenih odgovora zajedno sa opcionim
porukama:
331 Username OK, password required
125 Data connection already open; transfer starting
425 Can't open data connection
452 Error writing file
itaoce koji ele da upoznaju i druge FTP komande i odgovore upuujemo na dokument RFC
959.

2. 4 Elektronska pota na Internetu
Elektronska pota postoji od samog poetka Interneta i u njegovim najranijim danima
predstavljala je njegovu najpopularniju aplikaciju [Segaller 1998], Kako su godine prolazile,
e-pota se sve vie razvijala, postajala sve monija i taj trend se zadrao sve do danas, kada je
ona i dalje jedna od nekoliko najpopularnijih aplikacija Interneta.
Poput standardne potanske slube, e-pota je asinhroni komunikacioni medi-jum - ljudi
alju i itaju poruke onda kada im to odgovara a da ne moraju da usklauju svoje aktivnosti. Ali,
za razliku od standardne potanske slube, e-pota je brza, jeftina i jednostavno se distribuira.
Savremena e-pota ima mnogo korisnih osobina. Korienjem diskusionih lista poruke e-pote,
ali isto tako i neeljena pota mogu istovremeno da sc upute hiljadama razliitih primalaca.
tavie, u porukama savre-mene e-pote esto se nalaze priloeni dokumenti, hiperveze, tekst u
HTML formatu ili slike. Iako moe da se iskoristi i kao platforma za asinhroni prenos glasovnih
i video poruka, e-pota se jo uvek najvie koristi za razmenu klasinih tekstualnih poruka [Ross
2003],
U ovom odeljku ispitaemo protokole aplikacijskog sloja koji se nalaze u srcu internetske
e-pote. Ipak, pre nego to se pozabavimo detaljima ovih protokola, pogledajmo kako globalno
izgleda ovaj sistem.
Slika 2.15 predstavlja opti prikaz Intemetovog sistema za e-potu. Dakle, sa ovog
dijagrama vidimo da ovaj sistem ima tri osnovne komponente - korisnike agente, servere
elektronske pote i protokol SMTP (Simple Mail Transfer Protocol). Sada emo svaku od ovih
komponenti da opiemo na primeru poiljaoca, devojke Alise koja alje e-potu primaocu Bobu.
Korisniki agenti omoguavaju itanje poruka, odgovaranje na njih, kao i njihovo prosleivanje,
snimanje i sastavljanje. (Korisniki agenti za elektronsku potu nekada se nazivaju i itai
elektronske pote, ali emo mi u ovoj knjizi izbegavati ovaj termin.) KadaAlisa sastavi svoju
poruku, njen korisniki agent e posiati ovu poruku njenom serveru za e-potu, gde e ona biti
smetena u izlazni red sa porukama. Kada Bob bude eleo da proita ovu poruku, njegov
korisniki agent e je preuzeti iz njegovog potanskog sandueta na serveru za elektronsku
potu. Krajem 1990-ih postali su veoma popularni korisniki agenti sa grafikim korisnikim
interfejsom (GUI), koji su korisnicima omoguili da pregledaju i sastavljaju multimedijalne
poruke. U ovom trenutku Eudora, Microsoft Outlook i Netscape Messenger predstavljaju
najpopularnije korisnike agente

67 67 67 67 POGLAVLJE 2 APLIKATIVNI SLOJ 2.4 - ELEKTRONSKA POTA NA INTERNETU 111 111 111 111

ove vrste. U javnom domenu ima i mnogo tekstualnih korisnikih interfejsa za elektronsku
postu, kao to su, recimo, mail,pine i elm.
Serveri za elektronsku potu ine jezgro infrastrukture elektronske pote. Svaki primalac,
poput Boba, ima svoje potansko sanduee koje se nalazi na jednom serveru. Uobiajena poruka
svoj ivot zapoinje u korisnikom agentu poiljaoca, zatim putuje do primaoevog servera za
elektronsku potu, na kome se smeta u pri-maoevo potansko sandue. Kada Bob poeli da
pristupi porukama koje se nalaze u njegovom potanskom sanduetu, njegov server za
elektronsku potu najpre treba da proveri Bobovu autentinost (korisniko ime i lozinka). Alisin
server za elektronsku potu takode mora da prevazie i eventualne probleme na Bobovom
serveru. Ukoliko njen server ne uspe da isporui potu Bobovom serveru, on e poruku zadrati
u redu za poruke i pokuati da je isporui kasnije. Ovi pokuaji se ponavljaju otprilike na svakih
tridesetak minuta. Ako ni nakon nekoliko dana ne uspe da isporui poruku, server je uklanja i o
tome obavetava poiljaoca (Alisu) jednom porukom.
Protokol SMTP predstavlja osnovni protokol aplikacijskog sloja za Internet elektronsku
potu. Prilikom prenosa pote od poiljaoevog do primaoevog potanskog servera, ovaj
protokol koristi uslugu pouzdanog transfera podataka protokola TCP. Poput veine protokola
aplikacijskog sloja, protokol SMTP ima dve strane - klijentsku, koja se izvrava na
poiljaoevom serveru za e-potu, i serversku, koja se izvrava na primaoevom serveru za
e-pofu. 1 klijentska i serverska strana ovog protokola izvravaju se na svakom serveru. Kada
neki server za elektronsku potu alje poruke drugim serverima, on se ponaa kao SMTP klijent.
Nasuprot tome, kada isti taj server prima poruke od drugih servera, on se ponaa kao SMTP
server.
KRATAK OSVRT
HOTMAIL HOTMAIL HOTMAIL HOTMAIL
U decembru 1995. godine Sobir Bhotio i Dek Smit poseltli su Draper Fier Jurvetsono,
kapitalistu iji su poslovi bili vezoni sa Inlernelom i predloili mu razvoj besplatnog sistema za
elektronsku poslu zasnovanog na VVebu. Ideja je bila da se svakom ko lo eli omogui
pravljenje besplatnog naloga za elektronsku potu kome je mogue pristupiti so bilo kog
mesra. Kod elektronske poste zasnovane na VVebu svako ko ima pristup VVebu - recimo, iz
biblioteke ili kole - moe da prima i alje elektronsku potu. Sto je jo vanije, elektronska
pota zasnovana na VVebu omoguava veliku pokretljivost svojim korisnicima. Za vlasnitvo
nad 15 procenata kompanije, Draper Fier Jurvetson je finansirao kompaniju koju su Sabir
Bhatio i Dek Smit nazvali Hotmaii. Sa ukupno tri stalno zaposlene osobe i 12 do 14 povre-
meno zaposlenih koji su rodili samo za mogunost da kupe akcije u neko kasnije vreme, oni su
uspeli da razviju i lansiraju ovu uslugu jula 1996. godine. Samo mesec dana nakon pokretanja
imali su ve 500000 lanova. Broj lanova se veoma brzo uveavao, i svi oni su, itajui svoju
elektronsku postu, morali da i itaju reklamne natpise. U decembru 1997. godine, samo 18
meseci nokon pokretanja usluge, kompaniju Hotmail koja je tada imala 12 miliona lanova,
otkupio je Microsoft, po nekim procenama za 400 miliona dolara.
Uspeh usluge Hotmail najee se vezuje za prednost prvog poteza", kao i za virusni
marketing" elektronske pote. Kompanija Hotmail je imala prednost prvog poteza zato to je
bila prva kompanija koja je nudila usluge elektronske pote zasnovane na VVebu. Ostale
kompanije su, naravno, sledile ovaj put, ali sa bor est meseci zakanjenja. Ova prednost
prvog poteza postie se originalnom idejom i njenom brzam i tajnom realizacijom. Za uslugu ili
proizvod se koe da ima potencijal virusnog marketinga ukoliko reklamira samog sebe.
Elektronska pota predstavlja klasian primer ovakve usluge - poiljalac alje poruku jednom
primaocu ili veem broju primalaca i onda svi oni postaju svesni dote usluge. Primer Hotmaila
je pokazao da se kombinacijom prednosti prvog poteza i virusnog marketinga moe stii do
izuzetno popularne aplikacije. Mogue je da e ba meu itaocima ove knjige biti novih
pronalazaa koji e uspeti da uine neto slino.

2.4 - ELEKTRONSKA POTA NA INTERNETU 113 113 113 113

2.4.1 Protokol SMTP
Protokol SMTP, koji je definisan dokumentom RPC 2821, je sama sr intemetske elektronske
pote. Kao to smo ve rekli, SMTP prenosi poruke izmeu poiljao-evog i primaocevog
servera za e-potu. Protokol SMTP je znatno stariji od protokola HTTP. (Originalni SMTP RFC
dokument datira iz 1982. godine, ali se sam SMTP pojavio znatno ranije.) Iako se protokol
SMTP odlikuje mnogim izuzetnim osobinama, o emu svedoi i njegova opta prisutnost na
Internetu, ipak je tu re o nasleenoj tehnologiji koja ima i neke arhaine" karakteristike. Na
primer, ovaj protokol ograniava telo (ne samo zaglavlje) svih poruka na sedmobitni ASCII kod.
Ovo ogranienje je imalo smisla: poetkom 1980-ih kada je prenosni kapacitet bio skroman i
niko nije slao velike slike ili audio i video datoteke. Ali u dananjoj multimedijalnoj eri,
ogranienje na sedmobitni ASCII kod predstavlja problem. Binarni multimedijalni podaci
moraju da se kodiraju u ASCII kako bi mogli da se prenose protokolom SMTP; nakon SMTP
transporta ASCII poruka mora da se dekodira i vrati u prvobitni binarni oblik. Podseamo vas na
odeljak 2.2 u kome smo rekli da protokol HTTP ne zahteva ovu vrstu kodiranja pre transfera.
Da bismo vam ilustrovali nain rada protokola SMTP, posluiemo se jednim uobiajenim
scenarijom. Pretpostavimo da Alisa eli da poalje Bobu jednostavnu ASCII poruku.
1. Alisa aktivira svog korisnikog agenta za e-potu, upisuje Bobovu adresu (na primer,
bob@someschool. edu), sastavlja poruku i zatim nalae korisnikom agentu daje poalje.
2. AHsin korisniki agent alje poruku njenom serveru za epotu, na kome se ona smeta u
red za poruke.
3. Kada klijentska strana protokola SMTP koja se izvrava na Alisinom serveru za e-potu
uoi ovu poruku, ona uspostavlja TCP konekciju sa serverskom stranom protokola SMTP
koja se izvrava na Bobovom serveru za e-potu.
4. Nakon inicijalnog SMTP rukovanja (sinhronizovanja), klijentska strana protokola SMTP
alje Alisinu poruku TCP konekcijom.
5. Na Bobovom serveru za e-potu, serverska strana protokola SMTP prima poruku koju
Bobov server zatim smeta u Bobovo potansko sandue.
6. Bob pokree svog korisnikog agenta onda kada on eli da proita svoju potu.
Ovaj scenario ilustrovali smo na slici 2.16.
Veoma je vano da primetite da se protokol SMTP prilikom isporuke epote obino ne
oslanja na posrednike servere, ak i kada se dva servera nalaze na drugim krajevima sveta.
Kada bi se Alisin potanski server nalazio u Hong Kongu, a Bobov u Sent Luisu, izmeu njih bi
se uspostavila direktna TCP konekcija. Ukoliko bi Bobov server bio privremeno u kvaru,
poruka ne bi bila smetena u nekom posre-dujuem serveru, ve bi ostala u Alisinom serveru i u
njemu saekala na neki novi pokuaj,
Pogledajmo sada izbliza na koji nain protokol SMTP prebacuje poruku sa poiljaoevog
servera na primaoev server za elektronsku potu. Uskoro ete videti da protokol SMTP ima
mnogo slinosti sa protokolima koji se koriste u direktnoj komunikaciji ljudi.
Najpre, klijentska strana protokola SMTP (koja se izvrava na poilj a oevom potanskom
serveru) treba da na svom portu 25 uspostavi TCP konekciju sa serverskom stranom protokola
SMTP (koja se izvrava na primaoevom serveru za e-potu). Ukoliko je server u kvaru, klijent
pokuava ponovo. Nakon uspostavljanja veze, klijentska i serverska strana protokola prelaze na
proces sihronizacije aplikacijskog sloja, slino kao to se ljudi jedni drugima predstavljaju pre
nego to ponu da razmenjuju informacije. Tokom faze sinhronizacije, SMTP klijent navodi
adresu e-pote poiljaoca (osobe koja je napravila i poslala poruku) i odgovarajuu adresu
primaoca. Nakon ove faze meusobnog upoznavanja, klijentska strana protokola SMTP
zapoinje slanje poruke. Protokol SMTP se, kada je u pitanju isporuka poruke do drugog servera
bez greaka, oslanja na uslugu pouzdanog transfera podataka protokola TCP. Ukoliko ima jo
poruka koje treba da poalje, klijentska strana ponavlja ovaj postupak istom TCP konekcijom;
ako nema, ona nalae protokolu TCP da prekine konekciju.
Pogledajmo sada kako izgleda primer transkripta razmene poruka izmeu SMTP klijenta
(C) i SMTP servera (S). Ime raunara klijenta glasi crepes . f r, a ime raunara servera
hamburger. edu. Redovi ASCII teksta ispred kojih stoji C: su upravo oni redovi koje je klijent
poslao u svoj TCP soket, dok je ASCII redove ispred kojih stoji S: upravo takve u svoj soket
poslao SMTP server. Transkript koji sledi zapoinje odmah nakon uspostavljanja TCP
konekcije.

69 69 69 69 POGLAVLJE 2 APLIKATIVNI SLOJ 2.4 ELEKTRONSKA POTA NA INTERNETU 69 69 69 69

U ovom primeru, klijent sa servera crepes . f r alje poruku ( Do you like ketchup? How about
pickles?") serveru hamburger . edu. Kao deo dijaloga klijent je izdao pet komandi: HELO (skraenica
od HELLO), MAIL FROM, RCPT TO, DATA i QUIT. Ove komande u dovoljnoj meri same sebe
objanjavaju. Osim toga, klijent je poslao i red u kome se nalazi samo jedna taka, kojom se
naznaava kraj poruke upuene serveru. (U ASCII argonu svaka poruka se zavrava sa CRLF.
CRLF, gde se slova CR odnose na povratak na poetak reda, a LF na prelazak u novi red.) Server
no svaku od ovih komandi daje odgovore koji imaju odgovarajui kod i neko (opciono) objanjenje na
engleskom jeziku. Na ovom mestu rei emo i to da protokol SMTP koristi postojane veze - ukoliko
poiljaoev server za elektronsku potu treba da poalje primaoevom serveru nekoliko poruka, on
e ih sve poslali istom TCP konekcijom. Za svaku pojedinanu poruku klijent zapoinje proces sa
MAIL FROM: crepes . f r. dok njen kraj oznaava izolovanom takom; komandu QUIT izdaje tek
nakon to poalje sve poruke.
Veoma je preporuljivo da za direktan dijalog sa SMTP serverom koristite program Telnet. Da
biste to uinili, potrebno je da izdate sledeu komandu:
telnet serverName ; 25
gde parametar serverName predstavlja ime lokalnog servera za elektronsku potu. inei ovo vi,
jednostavno, uspostavljate TCP konekciju izmeu vaeg lokalnog raunara i servera za elektronsku
potu. Odmah nakon upisivanja ovog reda, trebalo bi da od servera primite odgovor 2 2 0. Zatim,
pravovremeno izdajte SMTP komande HELQ; MAIL FROM, RCPT TO, DATA, CRLF . CRLF i QUIT.
Na kraju ovog poglavlja obavezno provebajte programerski zadatak 2 u kome treba da napravite
jednostavnog korisnikog agenta koji implementira klijentsku stranu protokola SMTP. Pomou ovog
korisnikog agenta moi ete da aljete poruke bilo kom primaocu putem lokalnog servera za
elektronsku potu.
2.4.2 Poreenje sa protokolom HTTP
U nastavku teksta ukratko emo uporediti protokole SMTP i HTTP. Dakle, oba ova protokola koriste
se za transfer datoteka sa jednog raunara na drugi; HTTP prenosi datoteke (nazivaju se i
objektima) od veb servera do veb klijenta (najee itaa); SMTP prenosi datoteke (elektronsku
potu) od jednog servera za elektronsku potu do drugog. Prilikom transfera datoteka postojani
protokol HTTP i SMTP koriste postojane veze. Prema tome, moglo bi se rei da ova dva protokola
imaju neke zajednike karakteristike. Meutim, izmeu njih postoje i veoma znaajne razlike. Najpre,
protokol HTTP je u najveoj meri prijemni protokol - neko postavlja odreene informacije na veb
serveru, korisnici pomou protokola HTTP primaju te informacije sa servera onda kada oni to
ele. Konkretno, TCP konekciju inicira onaj raunar koji eli da primi podatke. S druge strane,
protokol SMTP je prvenstveno predajni protokol - poiljaoev server za elektronsku potu predaje
datoteku primaoevom serveru za elektronsku potu. U ovom sluaju TCP konekciju inicira onaj
raunar koji eli da poalje (preda) svoju datoteku.
Druga razlika, koju smo ve pomenuli, jeste to to protokol SMTP zahteva da svaka poruka,
ukljuujui tu i telo svake poruke, bude u sedmobitnom ASCII formatu. Ako poruka sadri znake koji
nisu sedinobitni ASCII kod (na primer, francuska slova sa akcentima), ili sadre binarne podatke
(recimo, slike), onda ona mora da se kodira u sedmobitni ASCII kod. Protokol HTTP ne namee ovo
ogranienje.
Trea bitna razlika tie se naina rukovanja dokumentima koji sadre tekst i slike (i neke druge
tipove medija). Kao to ste videli u odeljku 2.2, protokol HTTP enkapsulira svaki objekat u
sopstvenu poruku sa odgovorom. Internetska elektronska pota, kao to ete uskoro videti, sve
objekte poruke objedinjuje u jednu poruku.

2.4.3 Formati elektronske pote i M1ME
Kada Alisa napie Bobu standardno pismo, ona na njegovom vrhu moe da upie sve vrste
perifernih informacija, kao to su Bobova adresa, njena povratna adresa i datum. Slino tome,
prilikom slanja elektronske pote od jedne drugoj, zaglavlje sa perifernim informacijama prethodi telu
same poruke. Ove periferne informacije nalaze se u seriji redova zaglavlja koja su definisana
dokumentom RFC 822. Redovi zaglavlja odvojeni su od tela poruke jednim praznim redom
(odnosno, kontrolnim znakovima CRLF). Dokument 822 precizira taan format redova zaglavlja, kao
i njihove semantike interpretacije. Poput protokola HTTP, svaki red zaglavlja sadri neki itljiv tekst
koji ini kljuna re praena znakom dve take i vrednou. Neke kljune rei su obavezne, dok su
druge samo opcione. Svako zaglavlje mora imati redove From: i To :, a u njemu se moe nai i red
Subject:, kao i neki drugi opcioni redovi. Ovde elimo da naglasimo da se ovi redovi zaglavlja
razl i kuj u od SMTP komandi o kojima smo govorili u odeljku 2.4. 1 (i pored toga to se i kod jednih i
kod drugih javljaju rei , /rom" i to"). Komande o kojima smo govorili u ovom odeljku bile su deo
sinhronizacije protokola SMTP; redovi zaglavlja o kojima sada priamo ine deo same poruke
elektronske pote.

70 70 70 70 POGLAVLJE 2 APLIKATIVNI SLOJ 2.4 ELEKTRONSKA POTA NA INTERNETU 70 70 70 70

Nakon zaglavlja poruke sledi prazan red, pa zatim telo poruke (u ASCII kodu). Preporuujemo
vam da pomou programa Telnet poaljete serveru za elektronsku potu poruku koja sadri neke
redove zaglavlja, ukljuujui i red Sub ject:. U tu svrhu izdajte komandu telnet serverName 25.
MIME proirenja za podatke koji nisu u ASCII kodu
Zaglavlja koja su opisana u dokumentu RFC 822 pogodna su za slanje obinog ASCII teksta, ali
nisu dovoljno bogata za multimedijalne poruke (na primer, poruke sa slikama, audio i video
materijalom) ili za prenos teksta koji nije u ASCII kodu (na primer, znaci koji se koriste u nekim
jezicima). Za slanje sadraja koji se razlikuje od ASCII teksta, korisniki agent poiljalac mora u
poruku da ubaci dodatna zaglavlja. Ova dodatna zaglavlja su definisana dokumentima RFC 2045
i RFC 2046 - vienamenskim proirenjima Internet poste (Multipurpose Internet Mail
Extensi-ons, MIME) koji su proirenja dokumenta RFC 822.
Dva kljuna MIME zaglavlja za podravanje multimedijalnog sadraja jesu zaglavlja
Content-Type : i Content-Transf er-Encoding :. Zaglavlje Ccmtent-Type : omoguava
primajuem korisnikom agentu da preduzme odgovarajuu akciju u vezi sa porukom. Primera
radi. naznaavanjem da se u telu poruke nalazi JPEG slika, korisniki agent primaoca moe da
uputi telo poruke ka funkciji za dekomprimovanje JPEG formata. Da biste razumeli neophodnost
zaglavlja Con-tent-Transfer-Encoding: podseamo vas da sve poruke koje nisu u formatu ASCII
moraju da se prebace u ovaj format kako ne bi zbunile protokol SMTP.
ZaglavljeContent-Transfer-Encoding: upozoravaprimajuegkorisnikog agenta daje telo poruke
kodirano u ASCII format i navodi vrstu primenjenog kodiranja. Kada korisniki agent primi
poruku sa ova dva zaglavlja, on najpre, korienjem vrednosti zaglavlja Content-Transf
er-Encoding : pretvara telo poruke u njegov prvobitni (ne-ASCII) oblik, a zatim, pomou
zaglavlja Content~Type :, odreuje koje akcije treba da preduzme u vezi sa datim telom poruke.
Preimo sada na jedan konkretan primer. Pretpostavimo da Alisa eli da poalje JPEG sliku
Bobu. Dakle, ona otvara svog korisnikog agenta za elektronsku potu, navodi Bobovu adresu
elektronske pote, naznaava temu poruke i umee JPEG sliku u njeno telo. (Zavisno od toga
koji je korisniki agent u pitanju, mogue je da e slika biti umetnuta kao priloeni dokument.)
Kada zavri sastavljanje svoje poruke, Alisa e pritisnuti dugme Send" svog korisnikog
agenta. Odmah zatim, njen korisniki agent e generisati MIME poruku koja bi mogla da izgleda
otprilike ovako:
Iz ove MIME poruke moemo da zakljuimo daje Alisin korisniki agent kodirao JPEG
sliku korienjem kodiranja tipa base64. To je jedna od nekoliko standardizo-vanih MIME [RFC
2045] tehnika za kodiranje u prihvatljivi sedmobitni ASCII format. Drugu popularnu tehniku za
kodiranje predstavlja tehnika za kodiranje sadraja tipa quoted-printable koja se obino koristi
za pretvaranje osmobitnih ASCII poruka (na primer, sa karakteristinim slovima nekih jezika) u
sedmobitni ASCII format.
Kada Bob bude eleo da proita svoju elektronsku potu, njegov korisniki agent e se
suoiti sa istom ovom MIME porukom. im uoi zaglavlje Content-Transf er-Encoding :
base64, Bobov korisniki agent prelazi na dekodiranje tela poruke. Sledee zaglavlje,
Content-Type : image/jpeg, govori Bobovom korisnikom agentu da telo poruke treba da
dekomprimuje funkcijom za dekomprimovanje JPEG formata. Konano, u poruci stoji i
zaglavlje MIME-Vers ion: koje, naravno, naznaava verziju upotrebljenog MIME proirenja.
Skreemo vam panju na to da u svim drugim aspektima poruka sledi standardni RFC
822/SMTP format. Na primer, nakon zaglavlja poruke sledi prazan red, pa zatim telo poruke.
Primljena poruka
Napravili bismo veliki propust ukoliko ne bismo pomenuli jo jednu klasu redova zaglavlja -
onu koja u poruku umee prijemni SMTP server. Nakon to primi poruku sa redovima zaglavlja
tipa RFC 822 i MIME, ovaj server na njen sam vrh dodaje red zaglavlja Received: u ovom
redu navodi se ime SMTP servera koji je poslao poruku (from"), ime SMTP servera koji je
primio (by"), kao i vreme kada je poruka primljena. Prema tome, kada stigne do svog konanog
odredita, poruka izgleda ovako:
Uobiajeno zaglavlje poruke izgleda ovako:

2.4 ELEKTRONSKA POTA NA INTERNETU 119 119 119 119

Gotovo svako koje koristio elektronsku potu bio je u prilici da vidi red zaglavlja
Received : (i ostale redove) koji prethodi poruci. (Ovaj red esto moe da se vidi na ekranu ili
prilikom tampanja poruka.) Isto tako, moda ste primetili da jedna poruka moe imati vie
zaglavlja Received: i komplikovamje zaglavlje Peturn-Path :. To je znak daje, na putu izmeu
poiljaoca i primaoca, poruka prosledena veem broju SMTP servera. Kada bi, primera radi,
Bob od svog servera hamburger . edu traio da se sve njegove poruke proslede serveru sushi .
jp, sve njegove poruke bi poinjale otprilike ovako:
Received: from hamburger.edu by sushi.jp; 3 Jul 01 15:30.01 GMT GMT GMT GMT Received: from crepes.fr by
hamburger.edu; 3 Jul 01 15:17:39 GMT GMT GMT GMT
Ovi redovi zaglavlja omoguavaju prijemnom korisnikom agentu da prati koji su SMTP
serveri poseeni i kada.
2.4.4 Protokoli za prijem elektronske pote
Kada protokol SMTP isporui poruku sa Alisinog potanskog servera Bobovom serveru,
poruka se smeta u Bobovo potansko sandue. U elom ovom izlaganju podrazumevali smo
da Bob do svoje elektronske pote dolazi tako to se prijavljuje odreenom serveru, a zatim se
njegov ita elektronske pote izvrava na tom serveru. Sve do 1990-ih ovo je bio i standardni
nain za dolaenje do elektronske pote. Meutim, dananji tipini korisnik do svoje pote
dolazi tako to se njegov korisniki agent izvrava na njegovom krajnjem sistemu, to moe
da bude njegov PC u kancelariji, ili kuni Mac, ili moda PDA raunar. Izvravanje
korisnikih agenata na lokalnim raunarima donelo je krajnjim korisnicima itav niz novih
funkcija, ukljuujui i pregledanje multimedijalnih poruka i priloenih dokumenata.
Ukoliko se Bobov korisniki agent izvrava na njegovom raunaru, onda bi, valjda, bilo
oekivano da se i server za elektronsku potu takoe nalazi na Bobovom lokalnom raunaru.
Sledei ovakav pristup, Alisin potanski server morao bi da ostvaruje direktan dijalog sa
Bobovim raunarom. Meutim, ovde postoji ijedan problem. Ako se seate, rekli smo da server
za elektronsku potu upravlja potanskim sanduiima i da se na njemu izvravaju klijentska i
serverska strana protokola SMTP. Kada bi se Bobov server za e-potu nalazio na njegovom
lokalnom raunaru, taj raunar bi morao da bude neprekidno ukljuen i povezan sa Internetom,
jer bi jedino tako mogao da primi potu koja moe da pristigne u svakom trenutku. Ovakva
koncepcija je zato nepraktina i neprihvatljiva za veliku veinu savremenih korisnika Interneta.
Umesto toga, prosean korisnik pokree korisnikog agenta na lokalnom raunaru, ali pristupa
potanskom sanduetu preko zajednikog servera za e-potu -onog koji je uvek ukljuen i uvek
povezan sa Internetom. Ovakve servere zajedniki koristi vei broj korisnika, a obino ih
odrava njihov posrednik za Internet usluge (recimo, univerzitet ili neka kompanija).
Pogledajmo sada kako izgleda putanja kojom elektronska pota putuje od Alise do Boba.
Upravo ste nauili da u nekom delu ove putanje poruka mora da se sauva u Bobovom serveru
za elektronsku potu. Ovaj cilj se postie veoma jednostavno - tako to Alisin korisniki agent
direktno poalje poruku Bobovom serveru za elek-
tronsku potu. Kao to ve verovatno pretpostavljate, za ovo je zaduen protokol SMTP, koji je
upravo i napravljen za predaju (guranje) elektronske pote od jednog raunara do drugog.
Meutim, Alisin korisniki agent ne ostvaruje direktnu komunikaciju sa Bobovim serverom za
elektronsku potu, ve pomou protokola SMTP predaje elektronsku potu Alisinom serveru za
elektronsku potu koji zatim, opet pomou protokola SMTP (njegove klijentske strane), predaje
poruku Bobovom serveru za elektronsku potu (slika 2.17). Verovatno se sada pitate emu
ovakva dvofazna procedura. Pre svega zato to, bez posredovanja njenog servera za e-potu,
Alisin korisniki agent ne bi mogao nita da zna o eventualnom kvaru odredinog potanskog
servera. Kada Alisin server primi njenu e-potu, on moe svakih 30 minuta da pokuava da je
poalje sve dok se Bobov server ne vrati u funkciju. (U sluaju kvara njenog potanskog servera,
ona uvek moe da se ali administratoru sistema.) RFC dokumentima o protokolu SMTP
ureenje nain korienja SMTP komandi za prosledivanje poruke izmeu veeg broja servera.
Ipak, u celoj ovoj zagonetki nedostaje nam jo jedan detalj. Na koji nain primalac (poput
Boba) sa korisnikim agentom koji se izvrava na njegovom lokalnom raunaru stie do poruka
koje se nalaze na serveru za e-potu njegovog posrednika za Internet usluge? Skreemo vam
panju na to da Bobov korisniki agent ne moe do ovih poruka da stigne pomou protokola
SMTP zato to je preuzimanje poruka operacija prijema (povlaenja), a protokol SMTP je
protokol predaje (guranja). Upravo tu na scenu stupa i poslednji detalj ove nae slagalice -
poseban protokol za pristup elektronskoj poti koji e da prebaci poruke od Bobovog servera za
elektronsku potu do njegovog lokalnog raunara. Trenutno je popularno vie ovakvih
protokola, ukljuujui i POP3 (Post Office Protocol - Version 3), IMAP (Internet Mail Access
Protocol) i HTTP.
Na slici 2.17 moete da vidite koji protokoli uestvuju u razmeni internetske elektronske
pote: SMTP se koristi za prebacivanje pote od poiljaoevog korisnikog agenta do njegovog
potanskog servera, kao i od njegovog servera do servera primaoca. Za prebacivanje pote od
primaoevog servera za e-potu do njegovog korisnikog agenta koriste se protokoli za pristup
elektronskoj poti, kao stoje, na primer, protokol POP3.

POP3
Protokol POP3 je izuzetno jednostavan protokol za pristup elektronskoj poti. Defi-nisan je u
dokumentu RFC 1939, koji je veoma kratak i razumljiv. Zbog ove jednostavnosti,
funkcionalnost ovog protokola prilino je ograniena. Protokol POP3 stupa na scenu onog
trenutka kada korisniki agent (klijentska strana) otvori TCP konekciju sa serverom za
elektronsku potu (serverska strana) na portu 110. Nakon uspostavljanja TCP konekcije, POP3
prolazi kroz tri faze - ovlaivanje, transakciju i auriranje. Tokom prve faze - ovlaivanja -
korisniki agent slanjem korisnikog imena i lozinke identifikuje korisnika koji eli da preuzme
svoju potu. U fazi transakcije koja je sledea, korisniki agent preuzima poruke, ali i markira
one koje su za brisanje, uklanja oznake za brisanje i preuzima statistike podatke. Trea faza -
auriranje - nastupa nakon to klijent izda komandu quit, kojom se zavrava

2.72 ELEKTRONSKA POTA NA INTERNETU 121

POP3 sesija; u ovom trenutku server za elektronsku postu brie poruke koje su markirane za
brisanje.
U POP3 transakciji korisniki agent izdaje komande na koje server odgovara. U ovom smislu
postoje dva mogua odgovora: +OK (nekada odmah iza slede podaci koje server alje klijentu),
kojom server odgovara da je sa prethodnom komandom sve u redu i -ERR, kojom ukazuje na
postojanje nekog problema u vezi sa prethodnom komandom.
Faza ovlaivanja ima dve osnovne komande: user <korisniko ime> i pass <password>. Da
biste sc upoznali sa ovim komandama, preporuujemo vam da, koristei port 110, uspostavite
direktnu Telnet sesiju sa POP3 serverom i da ih zatim zadate. Kada bi ime vaeg potanskog
servera glasilo mail Server, videli biste otprilike ovakvu razmenu komandi:
telnet mailServer 110 +OK POP3 server
ready user bob +OK
pass hungry
+OK user successfully logged on
Ukoliko neku komandu napiete pogreno, POP3 server e odgovoriti porukom -
ERR.
Usredsredirno se sada na fazu transakcije. Korisniki agent koji koristi protokol POP3 moe da
se podesi (to ini korisnik) tako da preuzme i brie" ili preuzme i zadri" poruke. Konkretan sled
komandi koje izdaje POP3 korisniki agent zavisi od toga za koji se od ova dva reima korisnik
opredelio. U reimu preuzmi i brii" korisniki agent izdaje komande list, retr i dele. Primera radi,
pretpostavimo da neki korisnik u svom potanskom sanduetu ima dve poruke. U dijalogu koji sledi
C: (od klijent) je korisniki agent, a S: (od server) server za elektronsku potu. Cela transakcija
izgleda otprilike ovako:
C:list S: 1
498 S: 2 912
S: .
C: retr 1
S: (bla bla ...
S: ..................
S: ........................... bla)
S: .
C: dele 1 C: retr
2 S: (bla bla
...
S: ..................
S: .......... bla)
S: .
C: dele 2 C:
quit
S:+OK POP3 server se odjavljuje
Korisniki agent najpre od servera za elektronsku potu trai da navede veliinu svake sauvane
poruke. Nakon toga, korisniki agent najpre preuzima, a zatim brie sve poruke sa servera.
Skreemo vam panju na to daje, nakon faze ovlaivanja, korisniki agent izdao samo etiri
komande: list, retr, dele i quit. Sintaksa ovih komandi definisana je u dokumentu RFC
1939. Nakon izdavanja komande quit, POP3 server prelazi u fazu auriranja i iz potanskog
sandueta uklanja poruke ! i 2.
Problem u vezi sa ovim pristupom preuzimanja i brisanja jeste to to bi primalac Bob mogao da
bude stalno u pokretu, a da pri tom eli da sa svih raunara koje koristi (u kui, na poslu i sa
prenosivog raunara) moe da pristupi svojoj elektronskoj poti. Kod preuzimanja i brisanja Bobove
poruke bi se u tom sluaju nalazile razdeljene na tri raunara: konkretno, ako je neku poruku prvo
proitao na raunani u kancelariji, on ne bi mogao uvee ponovo daje proita na svom prenosivom
raunaru. U reimu preuzimanja i zadravanja, korisniki agent, nakon preuzimanja, ostavlja poruke
na serveru za elektronsku potu. Ovaj reim, dakle, omoguava Bobu da ponovo proita svoju
elektronsku potu na nekom drugom raunaru; moe prvo daje proita na poslu, a onda i kod kue,
nedelju dana kasnije.
Tokom POP3 sesije izmeu korisnikog agenta i servera za elektronsku potu, POP3 server
odrava neke statusne informacije. Konkretno, on evidentira koje je poruke korisnik markirao za
brisanje. Meutim, POP3 server ove statusne informacije ne prenosi iz jedne sesije u drugu, to
znaajno pojednostavljuje njegovu implementaciju.
IMAP
Kod POP3 pristupa Bob, nakon to preuzme poruke na svoj lokalni raunar, moe da napravi
direktorijume za elektronsku potu i u njih premesti preuzete poruke. On potom moe da ih brie,
premeta iz jednog direktorijuma u drugi i pretrauje (prema imenu poiljaoca ili temi). Ali, ova
paradigma direktorijuma i poruka na lokalnom raunaru predstavlja problem za korisnike koji su u
pokretu i kojima bi

2.5 . DNS -INTERNETOVA USLUGA DIREKTORIJUMA 73 73 73 73

vie odgovaralo da se ovakva hijerarhija direktorijuma napravi i odrava na udaljenom serveru,
kako bi onda mogli da joj pristupe sa bilo kog raunara koji koriste. Ovo, meutim, nije
mogue postii sa protokolom POP3 u okviru koga ne postoje nikakva sredstva koja bi
omoguila pravljenje direktorijuma na udaljenim serverima i rasporeivanje poruka u njih.
Da bi se otklonio ovaj nedostatak, izmiljen je protokol IMAP (Internet Mail Access
Protocol) koji je definisan u dokumentu RFC 2060. Poput protokola POP3, IMAP je takoe
protokol za pristup elektronskoj poti. Meutim, on ima daleko vie funkcija i znatno je
sloeniji, tako daje i implementacija njegove klijentske i server-ske strane sloenija.
IMAP server svaku poruku povezuje sa odreenim direktorij um om; im poruka dospe u
server, ona se povezuje sa primaoevim direktorijumom INBOX. Nakon toga primalac moe
daje premesti i u neki drugi svoj direktorijum, daje proita, izbrie itd. U okviru protokola
IMAP postoje komande koje korisnicima omoguavaju da prave direktorijume i prebacuju
poruke iz jednog svog direktorijuma u drugi. Protokol IMAP takoe obezbeduje komande koje
omoguavaju korisnicima da pretrauju udaljene direktorijume (poruke) prema nekim
konkretnim kriteriju-mima. Skreemo vam panju i na to da, za razliku od protokola POP3,
IMAP server prenosi statusne informacije iz jedne sesije u drugu - primera radi, imena direkto-
rijuma i veze poruka sa odreenim direktorijumima. Druga znaajna osobina protokola IMAP
jesle to to u njemu postoje komande koje omoguavaju korisnicima da preuzmu samo delove
poruke. Primera radi, korisniki agent moe da preuzme samo njeno zaglavlje ili jedan deo
viedelne MIME poruke. Ova osobina dolazi do punog izraaja kod konekcije niske propusne
moi (na primer, kod beine ili spore modemske veze) izmeu korisnikog agenta i njegovog
servera za elektronsku potu. Kod ovakvih konekcija sasvim je mogue da korisnik ne eli da
preuzme sve poruke u svoje potansko sandue, naroito ne dugake poruke sa zvunim ili
video materijalom. Dodatne informacije o protokolu IMAP moete da potraite na zvaninoj
veb lokaciji ovog protokola [IMAP 2004].
Elektronska pota zasnovana na Webu
Svakim danom sve je vei broj korisnika koji svoju elektronsku potu alju i primaju kroz itae
Weba, Ovu mogunost pokrenula je kompanija Hotmail sredinom 1990-ih, a danas ona postoji
na veini portala, univerziteta i veih kompanija. Kod ove usluge korisniki agent je obian
ita Weba, a korisnik sa svojim udaljenim potanskim sanduetom komunicira preko protokola
HTTP. Kada primalac, kao io je Bob, eli da pristupi svojoj elektronskoj poti, poruka se iz
njegovog potanskog sandueta, umesto protokolima POP3 ili IMAP, alje protokolom HTTP.
Isto tako, kada poiljalac kao stoje, na primer, Alis, eli da poalje elektronsku potu, ponika se
iz njenog itaa ka serveru za elektronsku potu takoe alje protokolom HTTP (umesto
protokolom SMTP).
Ovakav nain pristupa elektronskoj poti posebno je podesan za korisnike koji su u
stalnom pokretu. Dovoljno je da pristupe nekom itau Weba i moi e da proitaju svoje
poruke. Ovaj ita moe da se nalazi u Internet kafeu, kod prijatelja, na
PDA raunaru, u hotelskoj sobi koja ima Web TV itd. Kao i kod protokola IMAP, korisnici
elektronske pote zasnovane na Webu mogu da organizuju svoje poruke u hijerarhiji
direktorijuma na udaljenom serveru. U stvari, mnoge implementacije ovakve elektronske pole
koriste upravo IMAP servere kako bi omoguile funkcionalnost direktorijuma. U ovom sluaju,
pristup direktorijumima i porukama ostvaruje se pomou skriptova koji se izvravaju na HTTP
serveru; ovi skriptovi za komunikaciju sa IMAP serverima koriste upravo protokol IMAP.
2. 5 DNS - Internetova usluga direktorijuma
Ljudi se meusobno identifikuju na mnogo naina. Primera radi, moemo se iden-tifikovati na
osnovu imena na naim krtenicama, zatim na osnovu jedinstvenih matinih brojeva ili, recimo,
na osnovu brojeva registarskih tablica naih automobila, lako svaki od ovih identifikatora moe
da se koristi za identifikovanje ljudi, u odreenim kontekstima neki od njih su podesniji od
drugih. Raunari u agenciji IRS (poreska agencija u SAD) daju prednost brojevima osiguranja
graana koji su fiksne duine, u odnosu na njihova imena na krtenicama. Nasuprot tome,
ljudima su, od raznih identifikacionih brojeva, mnogo zgodnija imena. (Moete li da zamislite da
neko kae Zdravo, ja sam 132-67-9875. Ovo je moj suprug - 178-87-1146.")
Poput ljudi i raunari na Internetu mogu da se identifikuju na vie naina. Jedan od naina
za njihovo identifikovanje predstavljaju imena matinih raunara. Imena raunara - cnn . com,
www.ydlioo. com, ga i a . cs . umass. edu i surf . eurecom . f r - su mnemonika, tako da ih ljudi
razumeju i daju im prednost. Meutim, imena raunara pruaju veoma ture ili gotovo nikakve
informacije o lokaciji datog raunara u okviru Interneta. (Ime surf . eurecom . f r koje se
zavrava sa .f r govori nam satno to da se raunar verovatno nalazi u Francuskoj i nita vie.)
Osim toga, budui da imena raunara mogu da se sastoje od alfanumerikih znakova
promenljive duine, ruteri bi imali velike tekoe prilikom njihove obrade. Upravo zato, raunari
se identifikuju i IP adresama.
O IP adresama emo neto detaljnije govoriti u poglavlju 4, a sada samo nekoliko korisnih
informacija. IP adresa ima etiri bajta i striktnu hijerarhijsku struktuni. U uobiajenoj IP adresi
(na primer, 121.7.106.83) izmeu bajtova koji su izraeni decimalnim brojevima od 0 do 255
nalaze se take. Za IP adrese se kae da su hijerarhijske zato to itajui je sleva udesno
dolazimo do sve konkretnijih informacija o lokaciji nekog raunara u okviru Interneta (u kojoj je
mrei). Na isti nain, itajui potansku adresu odozdo navie, stiemo do sve konkretnijih
informacija o primaocu.
2.5.1 Usluge koje obezbeduje DNS
Upravo ste videli da matini raunar moe da se identifikuje na dva naina - imenom i IP
adresom. Ljudima su bliskija mnemonika imena raunara, dok ruterima vie odgovaraju
hijerarhijski ureene IP adrese fiksne duine. Ova dva suprotstavljena zahteva pomirena su
uslugom direktorijuma koji imena raunara prevodi u IP adrese. Upravo to je i osnovni zadatak
Internetove usluge DNS (Domain Name Svstem). Usluga DNS moe da se definie kao (1)
distribuirana baza podataka koja

124 124 124 124 POGLAVLJE 2 APLIKATIVNI SLOJ 2.5 DNS-INTERNETOVA USLUGA DIREKTORIJUMA 74 74 74 74

se implementira u hijerarhiju DNS servera i (2) protokol aplikacijsknog sloja koji omoguava
raunarima pretraivanje distribuirane baze podataka. DNS serveri su obino UNIX raunari
pod Berkeiev Internet Name Domain (BIND) softverom [BDND 2004]. Protokol DNS
funkcionie preko protokola UDP i koristi port 53.
DNS uslugu obino upotrebljavaju drugi protokoli aplikacijskog sloja - HTTP, SMTP i
FTP - i to za prevoenje imena raunara koje upisuju korisnici u odgovarajue IP adrese. Kao
primer zamisliemo situaciju u kojoj ita (odnosno, HTTP klijent) koji se izvrava na raunaru
nekog korisnika zatrai URL www. someschool . edu/index. html. Da bi mogao da poalje
HTTP zahtev veb serveru www . someschool. edu, korisniki raunar najpre mora da doe do
njegove IP adrese. To se dogaa na sledei nain.
1. Na raunaru ovog korisnika istovremeno se izvrava i klijentska strana DNS aplikacije.
2. ita iz URL-a izvlai ime raunara www. someschool. edu i predaje ga klijentskoj strani
DNS aplikacije.
3. DNS klijent alje ime raunara ija je adresa potrebna DNS serveru.
4. Nakon toga DNS klijent u odgovoru dobija traenu IP adresu.
5. Korisnikov ita zatim uspostavlja TCP konekciju sa procesom HTTP servera koji se nalazi
na daloj IP adresi.
Iz ovog primera vidimo da DNS usluga u sve Internet aplikacije koje je koriste uvodi dodatno
(nekada i prilino znaajno) kanjenje. Sreom, kao to ete ubrzo i sami videti, traena IP
adresa najee se nalazi u ke memoriji oblinjeg" DNS servera, to i te kako pomae u
smanjivanju intenziteta DNS saobraaja i skraenju kanjenja koje prouzrokuje ova usluga.
Pored prevoenja imena matinih raunara u adrese, DNS obezbeduje i sledee usluge:
Dodeljivanje pseudonima. Raunar komplikovanog imena moe imati jedan pseudonim ili
vie njih. Primera radi, ime raunara relayl .west-coast. enterprise . com moglo bi da ima,
recimo, dva pseudonima kao to su enterprise. com i www .enterprise. com. U ovom sluaju
za ime raunara relayl.west-coast.enterprise.com kae se da predstavlja kanoniko ime.
Pseudonimi imena raunara, ukoliko postoje, obino su u veoj meri mnemonika od
kanonikih imena. DNS uslugu moe da aktivira i aplikacija koja iz pseudonima i IP adrese
raunara eli da izvue kanoniko ime.
Pseudonimi servera za elektronsku potu. Iz sasvim oiglednih razloga bitno je da adrese
elektronske pote budu mnemonike. Kada bi, primera radi, Bob imao korisniki nalog na
Hotmailu, njegova adresa elektronske pote mogla bi da glasi samo bob@hotmail. com.
Meutim ime Hotmailovog potanskog servera je mnogo sloenije i mnogo manje
mnemoniko od imena hotmail. com (njegovo kanoniko ime moglo bi, recimo, da glasi
relayl. west-coast .hotmail. com). DNS usluga moe, dakle, da pozove i aplikaciju za
elektronsku potu kojoj su potrebni kanoniko ime i IP adresa matinog raunara
PRINCIPI U PRAKSI
DNS: KRITI DNS: KRITI DNS: KRITI DNS: KRITINE MRE NE MRE NE MRE NE MRENE FUNKCIJE PUTEM KLUENTSKO NE FUNKCIJE PUTEM KLUENTSKO NE FUNKCIJE PUTEM KLUENTSKO NE FUNKCIJE PUTEM KLUENTSKO- -- -SERVERSKE PARADIGME SERVERSKE PARADIGME SERVERSKE PARADIGME SERVERSKE PARADIGME
Poput protokola HTTP, FTP i SMTP, DNS je takoe protokol aplikacijskog sloja s obzirom no to da
se (1) izvrava izmeu komunicirajuih krajnjih toaka oslanjajui se na klijen-tsko-serversku
paradigmu i da se [2] u transportu DNS poruka izmeu komunicirajuih krajnjih sistema oslanja na
transportni protokol koji se nalazi u njegovoj osnovi. Meutim, u drugom smislu uloga DNS usluge
je potpuno razliita od uloge VVeba, transfera datoteka ili aplikacija za eleklronsku potu. Za razliku
od navedenih aplikacija, DNS usluga nije aplikacija sa kojom korisnik ostvaruje direktnu interakciju.
Umeslo toga, DNS usluga obezbeduje jednu od kljunih funkcija u vezi sa Internetom - za potrebe
korisnikih aplikacija i ostalog softvera no Internetu ona prevodi imena matinih raunara u
odgovarajue IP adrese. Podseamo vas da smo u odeljku 1.2 rekli da se najvei deo sloenosti
arhitekture Interneta nalazi na periferiji" ove mree. Usluga DNS, koja implementira izuzetno
vaan proces prevoenja imena u adrese koristei klijente i servere koji se nalaze na periferiji
mree, predstavlja jo jednu potvrdu izreene tvrdnje.
iji pseudonim ima. tavie, zapis MX (objanjen u nastavku) omoguava da server za
elektronsku potu i veb server neke kompanije imaju ista imena (pseudonime); primera radi,
i jedan i drugi server neke kompanije mogu imati pseudonim enterprise. com.
Distribucija optereenja. DNS usluga se u sve veoj meri koristi za distribuiranje optereenja
izmeu nekoliko rezervnih servera, Stoje est sluaj kod veb servera. Veoma poseene
lokacije, kao to je, recimo cnn . com, imaju kopije na nekoliko servera od kojih se svaki
izvrava na drugom krajnjem sistemu sa drugaijom IP adresom. Kod rezervnih veb servera,
skup IP adresa se, prema tome, vezuje zajedno kanoniko ime. Ovaj skup IP adresa nalazi se
u bazi podataka DNS-a. Kada klijent uini DNS upit za ime koje je preslikano na ovaj skup
adresa, server odgovara sa itavim skupom IP adresa, s tim to u svakom svom odgovoru
rotira njihov redosled. S obzirom na to da klijent obino svoju HTTP poruku sa zahtevom
alje na prvu IP adresu na spisku, DNS usluga na ovaj nain obezbeduje raspodelu
saobraaja izmeu servera sa kopijama. DNS rotacija se koristi i kod elektronske pote kako
bi vei broj servera za elektronsku potu mogao da ima isto ime. Odnedavno neke
kompanije, meu kojima i Akamai [Akamai 2004], sofisticiranim korienjem DNS usluge
ostvaruju distribuciju veb sadraja (proitajte poglavlje 7).
Usluga DNS definisana je u dokumentima RFC 1034 i RFC 1035, a njena auriranja nalaze
se u jo nekoliko dodatnih RFC dokumenata. Re je o veoma sloenom sistemu ije smo
kljune aspekte samo dotakli na ovom mestu. Dodatne informacije o njemu moete potraiti u
navedenim RFC dokumentima, zatim u knjizi koju su napisali Abic i Liu [Abitz 1993], kao i u
radu [Mockapetris 1988].

126 126 126 126 POGLAVLJE 2 APLIKATIVNI SLOJ 2.5 . DNS - INTERNETOVA USLUGA DIREKTORIJUMA 75 75 75 75

2.5.2 Prikaz naina rada usluge DNS
Sada emo vam iz neto uoptenije perspektive prikazati nain rada usluge DNS. U izlaganju
koje sledi usredsrediemo se na uslugu prevoenja imena raunara u IP adrese.
Pretpostavimo da neka aplikacija (recimo, ita Weba ili elektronske pote) koja se
izvrava na raunaru nekog korisnika treba da prevede ime raunara u IP adresu. Ova aplikacija
e najpre da pozove klijentsku stranu usluge DNS, navodei joj ime matinog raunara koje
treba da se prevede. (Na veini raunara pod UNlX-om proces prevoenja se pokree tako to
aplikacija upuuje funkcijski poziv gethost-byname (). U odeljku 2.7 pokazaemo vam na koji
nain Java aplikacija moe da pozove uslugu DNS.) Klijentska strana usluge DNS u
korisnikovom raunaru zatim preuzima inicijativu i alje poruku sa upitom u mreu. Sve DNS
poruke - i upiti i odgovori - alju se u okviru UDP datagrama kroz port 53. Nakon izvesnog
vremena, to mogu da budu milisekunde, ali i desetine sekundi, DNS u korisnikovom raunaru
prima poruku sa odgovorom u kojoj je navedeno traeno preslikavanje. Ovo preslikavanje se
potom prosleuje aplikaciji koja ga je i zatraila. Dakle, iz perspektive aplikacije koja ga
poziva, DNS je crna kutija koja obezbeduje jednostavnu uslugu prevoenja. Meutim, ova crna
kutija je, u stvari, veoma sloena i obuhvata veliki broj DNS servera koji su rasporeeni irom
sveta, ali i protokol aplikacijskog sloja kojim se precizira komunikacija izmeu DNS servera i
raunara koji alju upite.
U pojednostavljenoj varijanti, DNS uslugu inio bi jedan DNS server u kome bi se nalazila
sva preslikavanja. U ovakvom centralizovanom dizajnu klijenti bi sve upite upuivali jednom
serveru koji bi direktno odgovarao svim svojim klijentima. Iako je jednostavnost ovakve
koncepcije privlana, ona je jednostavno nepodesna za potrebe dananjeg Interneta i sve veeg
broja raunara. U nastavku navodimo razloge koji objanjavaju zato ovakav centra 1 i zo van i
dizajn nije poeljan.
Mrea se oslanja na jednu taku. U sluaju kvara DNS servera, cela mrea (Internet) postaje
neupotrebljiva.
Intenzitet saobraaja. Jedan DNS server morao bi da se nosi sa svim DNS upitima (svi
HTTP zahtevi i elektronska pota stotina miliona raunara).
Udaljena centraltzovana baza podataka. Jedan DNS server ne bi mogao da bude blizu" svih
klijenata. Ukoliko bismo ga postavili u Njujorku, svi upiti iz Australije bi morali da putuju
na drugi kraj sveta - moda sporim i zaguenim vezama. Kanjenja bi u tom sluaju bila
zaista znaajna.
Moemo zakljuiti da centralizovana baza podataka najednom serveru imena nema mogunost
jednostavnog i pouzdanog proirivanja. Zato je usluga DNS samim svojim dizajnom
distribuirana i predstavlja veoma lep primer implementiranja distribuirane baze podataka na
Internetu.
Odravanje. Jedan DNS server morao bi da uva zapise za sve raunare na Internetu.
Ovakva centralizovana baza podataka bi bila ogromna i morala bi veoma esto da se aurira
(za svaki novi raunar u mrei).
Distribuirana, hijerarhijska baza podataka
Da bi mogla da se izbori sa svim zabtevima, DNS usluga koristi veliki broj DNS servera
koji su hijerarhijski organizovani i rasporeeni irom sveta. Nijedan od ovih servera nema sva
preslikavanja za sve raunare na Internetu. Umesto toga, preslikavanja su distribuirana na veem
broju DNS servera. Uopteno govorei, postoje tri tipa DNS servera - lokalni DNS serveri, DNS
serveri domena najvieg nivoa (top-level domain, TLD) i DNS serveri od autoriteta koji su
organizovani u hijerarhiju koja je prikazana na slici 2.18. Da biste razumeli interakciju ove tri
klase servera, pretpostaviemo daje DNS klijentu potrebna IP adresa za ime www. amazon.
com. Evo ta se u ovoj situaciji deava. Klijent najpre kontaktira sa nekim od osnovnih DNS
servera koji mu vraaju IP adrese TLD servera na vrhu domena .com. Nakon toga, klijent se
obraa jednom od ovih TLD servera koji mu vraa IP adresu servera od autoriteta za domen
amazon . com, od koga e u treem koraku dobiti IP adresu za ime www. amazon . com. Ovaj
postupak DNS pretraivanja emo vam uskoro prikazati malo detaljnije, ali pre toga pogledajmo
izbliza ove tri klase DNS servera.
Osnovni DNS serveri. Na Internetu postoji trinaest osnovnih DNS servera (imaju oznake od
A do M), od kojih se veina nalazi u Sevemoj Americi. Na slici 2.19 moete da vidite mapu
osnovnih DNS servera iz februara 2004. godine, a aktuelnu listu osnovnih DNS servera
moete da potraite u dokumentu [Root-servers 2004]. Iako smo svaki od trinaest osnovnih
DNS servera oznaili kao da je u pitanju jedan raunar, server" u stvari predstavlja klaster
servera formiran zbog bolje bezbednosti i pouzdanosti.
Serveri domena najvieg nivoa (TLD serveri). Ovi serveri odgovorni su za domene najvieg
nivoa, kao to su domeni .com, .org, .net, .edu i .gov, kao i za sve domene najvieg nivoa
raznih zemalja - ,uk, .fr, .ca i jp. U vreme pisanja ove knjige (leto 2004), kompanija Net\vork
Solutions vodila je rauna o TLD serverima domena najvieg nivoa .com, dok je kompanija
Educause bila zaduena za TLD servere domena najvieg nivoa .edu.

128 128 128 128 POGLAVLJE 2 APLIKATIVNI SLOJ 2.5 DNS - INTERNETOVA USLUGA DIREKTORIJUMA 76 76 76 76

DNS serveri od autoriteta. Svaka organizacija koja ima javno dostupne raunare (recimo, veb
servere ili servere za elektronsku potu) na Internetu, mora da obezbedi javno dostupne DNS
zapise u kojima se imena ovih raunara preslikavaju u IP adrese. Ovi DNS zapisi uvaju se
upravo na DNS serverima od autoriteta tih organizacija, Jedna organizacija moe da ima
sopstveni DNS server od autoriteta, ili moe da plati da se ovi zapisi uvaju na takvom DNS
serveru nekog posrednika za Internet usluge. Univerziteti i velike kompanije najee imple-
mentiraju i odravaju sopstvene primarne i sekundarne (rezervne) DNS servere od autoriteta.
Osnovni, TLD i DNS serveri od autoriteta pripadaju hijerarhiji DNS servera koja je
prikazana na slici 2.18. Meutim, postoji jo jedan veoma vaan tip DNS servera - re je o
lokalnim DNS serverima. Lokalni DNS serveri se ne uklapaju sasvim u navedenu hijerarhiju
servera, ali bez sumnje zauzimaju centralno mesto u DNS arhitekturi. Svaki posrednik za
Internet usluge (ISP) - to moe da bude univerzitet, neka akademska ustanova, kompanija ili
rezidencijalni ISP - ima svoj lokalni DNS server (naziva se i podrazumevani DNS server). Kada
se neki raunar povee sa posrednikom za Internet usluge datog korisnika, on od njega dobija IP
adrese jednog ili vie lokalnih DNS servera (obino kroz protokol DHCP o kome emo govoriti
u odeljku 5.4.3). IP adresu svog lokalnog DNS servera moete da vidite u prozoru za praenje
mrenog statusa operativnih sistema Windows ili UNIX. Lokalni DNS server obino se nalazi
blizu" klijenta. Kod pristupa Internetu kroz
mreu neke kompanije, ovaj server moe da se nalazi i u istom LAN-u kao i raunar koji alje
upit. Kod rezidencijalnog pristupa Internetu DNS server je od klijentskog raunara udaljen
svega nekoliko rutera.
Kada klijent izvri DNS upit, taj upit se alje lokalnom DNS serveru koji se ponaa kao
proksi server i prosleuje ga u DNS hijerarhiju.
Preimo sada na jedan jednostavan primer. Pretpostavimo daje raunaru cis . poly.edu
potrebna IP adresa raunara gaia . cs .umass . edu. Takoe emo pretpostaviti i to daje lokalni
DNS server Politehnikog univerziteta dns .poly. edu, a daje, za raunar gaia . cs . umass . edu,
DNS server od autoriteta dns . umas .edu. Kao to moete da vidite na slici 2.20, raunar cis
.poly. edu najpre alje DNS poruku sa upitom svom lokalnom serveru imena - serveru dns . pol
y. edu. U ovom upitu navedeno je ime raunara (gaia.cs.umass. edu) koje treba da se prevede u
IP adresu. Lokalni DNS server prosleuje ovaj upit osnovnom serveru imena koji, videvi
sufiks .edu, vraa lokalnom DNS serveru listu

2.5 - DNS - INTERNETOVA USLUGA DIREKTORIJUMA 77 77 77 77

IP adresa TLD servera koji su odgovorni za domen .edu. Nakon loga, lokalni DNS server
poruku sa upitom alje jednom od ovih TLD servera.
TLD server zatim obraa panju na sufiks umass. edu i odgovara IP adresom DNS servera
od autoriteta na Univerzitetu u Masausetsu - dns . umass . edu. Konano, lokalni DNS server
istu poruku sa upitom alje direktno serveru dns . umass .edu od koga dobija IP adresu raunara
gaia . cs . umass .edu. Skreemo vam panju na to daje za dobijanje IP adrese jednog raunara
poslalo ak osam DNS poruka - etiri upita i etiri odgovora. Ipak, uskoro ete videti na koji
nain to moe da se smanji DNS keiranjem.
U ovom primeru pretpostavili smo da TLD DNS server zna IP adresu DNS servera od
autoriteta za imena traenog matinog raunara. Ova pretpostavka, meutim, ne mora da bude
tana. Mogue je da TLD DNS server zna samo IP adresu posredujueg DNS servera koji e
znati IP adresu DNS servera od autoriteta za traeno ime. Pretpostavimo sada da Univerzitet u
Masausetsu ima DNS server univerziteta po imenu dns. umass. edu. Pretpostavimo i to da
svaki departman ovog univerziteta ima vlastiti DNS server i da svaki od njih ima autoritet za
one raunare koji se nalaze u datom departmanu. U ovom sluaju, kada posredujui DNS server
dns . umass . edu primi upit za raunar ije se ime zavrava sa cs . umass . edu, on DNS serveru
dns .poly. edu vraa IP adresu DNS servera dns . cs . umass . edu koji je zaduen za upite koji se
odnose na raunare ije se ime zavrava sa . cs . umass . edu. Lokalni DNS server dns . poly .
edu zatim alje upit DNS serveru od autoriteta, koji mu odgovara traenim preslikavanjem. U
ovom sluaju razmeni se ukupno deset DNS poruka.
U primeru sa slike 2.20 korieni su rekurzivni i iterativni upiti. Upit koji je klijent cis
.poly. edu poslao serveru dns . poly. edu je rekurzivan s obzirom na to daje klijent od servera
zatraio da u njegovo ime pronae traeno preslikavanje. Meutim, sledea tri upita su
iterativna zato to se svi odgovori alju direktno serveru dns . poly. edu. U teoriji, svaki DNS
upit moe da bude iterativan ili rekurzivan. Primera radi, na slici 2.21 prikazanje lanac DNS
upita u kome su svi oni rekurzivni. U praksi, meutim, upiti obino prate ablon koji je
ilustrovan na slici 2.20: prvi upit je rekurzivan, a svi ostali iterativni,

DNS keiranje
Dosadanjim razmatranjem jo uvek nismo dotakli jednu veoma vanu funkciju DNS usluge -
DNS keiranje. U stvarnosti ova usluga se u izuzetnoj meri oslanja na keiranje koje skrauje
kanjenja i smanjuje broj DNS poruka u mrei. Sam koncept keiranja je krajnje jednostavan.
Kada u lancu upita DNS server primi DNS odgovor (na primer, preslikavanje imena nekog
matinog raunara u IP adresu), server ovu informaciju skladiti u svojoj lokalnoj memoriji.
Primera radi, lokalni DNS server dns . poly. edu sa slike 2.20 moe da keira sve informacije
koje primi od nekog drugog DNS servera u lancu upita. Ukoliko ponovo dobije upit koji se
odnosi na keirano preslikavanje imena raunara u IP adresu, DNS server moe odmah da
odgovori, ak i ako on nije autoritet za dati matini raunar. Keirani zapis se nakon isteka
odreenog vremena (najee dva dana) obino brie, zato to raunari i preslikavanja imena u
IP adrese nisu trajni.
Primera radi, pretpostavimo da je raunar apricot.poly.edu serveru dns . poly . edu poslao
DNS upit traei IP adresu raunara cnn . com. Takoe emo pretpostaviti i to daje nekoliko sati
kasnije jedan drugi raunar sa Poliiehni-kog univerziteta, recimo kiwi , poly. f r, ponovo poslao
isti DNS upit. Zahvaljujui keiranju, lokalni DNS server moe odmah da poalje IP adresu
raunara cnn . com bez prethodnog kontakta sa drugim DNS serverima. Lokalni DNS server
takode moe da keira IP adrese TLD servera, to mu omoguava da u lancu upita preskoi
osnovne DNS servere (ovo se esto deava),

2.5 . DNS - INTERNETOVA USLUGA DIREKTORIJUMA 133 133 133 133

2.5.3 DNS zapisi i poruke
DNS serveri koji zajedno implementiraju distribuiranu DNS bazu podataka uvaju zapise o
resursu (resource record, RR) koji se odnose na preslikavanja imena raunara u IP adrese. U
svakoj DNS poruci sa odgovorom nalazi se jedan ili vie ovakvih zapisa o resursu. U ovom i
sledeem odeljku nalazi se saet prikaz zapisa o resursu i poruka DNS usluge. Detaljnije
informacije moete pronai u knjizi [Abitz 1993] ili u RFC dokumentima koji se odnose na
uslugu DNS [RFC 1034; RFC 1035], Zapis o resursu ima sledea etiri polja:
(Name, Value, Type, TTL)
Polje TTL predstavlja rok trajanja zapisa; ovim poljem se odreuje kada se dati zapis o resursu
uklanja iz keirane memorije. U primerima zapisa koje navodimo u produetku zanemarili smo
polje TTL. Znaenja polja Name i Value zavise od polja Type:
Ukoliko je Type=A, onda je Name ime matinog raunara, a Value njegova IP adresa.
Dakle, zapis tipa A obezbeduje standardno preslikavanje imena raunara u IP adresu.
Primera radi, zapis (relayl. bar. f oo . com, 145.37.93.126, A) pripada zapisima tipa A.
Ako je Type=NS, onda je polje Name domen (na primer, f oo. com), a Value ime DNS
servera od autoriteta koji moe da obezbedi IP adrese raunara u tom domenu. Ovaj zapis se
koristi za rutiranje DNS upita kroz komunikacioni lanac. Na primer, zapis (f oo . com, dns .
f oo. com, NS) pripada tipu NS.
Ukoliko je Type=CNAME, polje Value je kanoniko ime raunara iji je pseudonim Name.
Dakle, pomou ovog zapisa raunari mogu da dodu do kanonikog imena za ime odreenog
raunara. Primera radi, zapis (f oo . com, relayl. bar. foo. com, CNAME) predstavlja zapis
tipa CNAME.
Ukoliko je Type=MX, polje Value predstavlja kanoniko ime servera elektronske pote iji
je pseudonim Name. Zapis (foo. com. mail. bar. foo. com, MX) pripada zapisima tipa MX.
Ovaj tip zapisa omoguava da serveri elektronske pote imaju jednostavne pseudonime.
Skreemo vam panju na to da koritenje MX zapisa omoguava jednoj kompaniji da koristi
isti pseudonim za svoj server elektronske pote i za neki drugi server (recimo, veb server),
Kada mu je potrebno kanoniko ime servera elektronske pote, DNS klijent u upitu trai MX
zapis, a kada mu je potrebno kanoniko ime nekog drugog servera, klijent trai zapis tipa
CNAME.
DNS server od autoriteta u svojoj bazi podataka ima zapise tipa A za sve raunare koji su u
njegovoj nadlenosti. (ak i ako on nije autoritet za neki raunar, DNS server u svojoj keiranoj
memoriji moe da sadri zapis tipa A koji se odnosi na dati' raunar,) Ukoliko DNS server nije
autoritet za odreeni raunar, on e u svojoj bazi
podataka imati zapis tipa NS koji se odnosi na domen u kome se dati raunar nalazi; osim toga,
on e imati i zapis tipa A sa IP adresom DNS servera koji je naveden u polju Va 1 ue zapisa NS.
Primera radi, pretpostavimo da edu TLD server nije autoritet za raunar gaia. cs .umass . edu. U
tom sluaju ovaj server imae zapis koji se odnosi na domen kome pripada ovaj raunar - cs .
umass . edu - na primer, (umass . edu, dns . umass . edu, NS). Osim toga, edu TLD DNS server
imae i zapis tipa A koji preslikava ime DNS servera dns . umass . edu u IP adresu - na primer,
(dns . umass . edu, 128.119.40.111, A).

DNS poruke
Na poetku ovog dela pomenuli smo DNS upite i odgovore. Ovo su ujedno i jedine vrste poruka
u okviru DNS-a. Kao'to moete da vidite na slici 2.22, DNS upiti i odgovori imaju isti format.
U nastavku objanjavamo znaenje polja DNS poruka.
Prvih 12 bajtova predstavljaju odeljak zaglavlja, koji ima nekoliko polja. Prvo polje je
16-bitni broj koji identifikuje upit. Ovaj identifikator se kopira u odgovor, to omoguava
klijentu da uporedi poslate upite sa primljenim odgovorima. U polju za oznake stoji nekoliko
oznaka. Jednobitnom oznakom lipa upit/odgovor naznaava se da lije u pitanju upit (0) ili
odgovor (t). Jednobitna oznaka autoriteta stavlja se u odgovor ukoliko je DNS server server
od autoriteta za traeno ime. Jednobitna oznaka poeljnosti rekurzivnog upita postavlja se
kada klijent (raunar ili DNS server) eli da DNS server, ukoliko nema traeni zapis, izvri
rekurzivni upit. Ako podrava rekurzivne upite, DNS server u odgovoru postavlja jednobitnu
oznaku o ostvarivosti rekurzivnog upita. U zaglavlju postoje i etiri polja tipa number of"
kojima se naznaava broj pojavljivanja etiri tipa odeljaka za podatke" koji slede iza
zaglavlja.
Odeljak za pitanje sadri informacije o aktuelnom upitu. U ovom odeljku se nalaze (I) polje
sa imenom na koje se upit odnosi i (2) polje za tip u kome se navodi tip pitanja - na primer,
adresa raunara povezuje se sa tipom A, dok se ime servera za elektronsku potu povezuje sa
tipom MX.
U odgovoru DNS servera odeljak za odgovor sadri zapise o resursu koji se odnose na
traeno preslikavanje. Podseamo vas da svaki zapis o resursu ima polja Type (na primer, A,
NS, CNAME ili MX), Value i TTL. Budui da isto ime matinog raunara moe da ima vie
IP adresa, u odeljku za odgovor jedne poruke moe da se nae vie zapisa o resursu
(podseamo vas na veb servere sa kopijama o kojima smo govorili ranije).
Odeljak za autoritet sadri zapise ostalih servera od autoriteta.
U dodatnom odeljku nalaze se ostali korisni zapisi. Primera radi, u polju za odgovor u
uzvratnoj poruci na MX upit nalazi se zapis o resursu u kome je navedeno kanoniko ime
raunara ili servera za elektronsku potu.

79 79 79 79 POGLAVLJE 2 . APLIKATIVNI SLOJ
2.5 DNS - INTERNETOVA USLUGA DIREKTORIJUMA 135 135 135 135
i-

Da li biste eleli da poruku saT)NS upitom poaljete nekom DNS serveru direktno sa raunara
na kome radite? Ovo je prilino jednostavno ukoliko koristite program nslookup koji je
sastavni deo veine Wtndows i UNIX platformi. Primera radi, na raunaru pod operativnim
sistemom Windows otvorite komandni prozo i upisivanjem nslookup" pokrenite ovaj program.
Nakon toga DNS upit moete da poaljete bilo kom DNS serveru (osnovnom, TLD ili serveru
od autoriteta). Kada od DNS servera primi poruku sa odgovorom, nslookup prikazuje zapise
koji su dobijeni u odgovoru (u formatu koji moe da se ita). Osim to ovaj program moete da
pokrenete sa svog raunara, isto to moete da uinite sa neke od mnogih veb lokacija koje
omoguavaju njegovo daljinsko korienje. (U bilo kom pretraivau upiite nslookup" i nai
ete se na nekoj od ovih lokacija.)
Ubacivanje zapisa u DNS bazu podataka
U elom ovom izlaganjugovorili smo samo o nainima pribavljanja informacija iz DNS baze
podataka, tako daje mogue da se sada pitate na koji nain te informacije uopte dospevaju u
nju. Pogledajmo kako to izgleda na konkretnom primeru. Pretpostavimo da ste upravo oformili
kompaniju po imenu Netvvork Utopia. Prvo to ete sasvim sigurno eleti da uinite jeste da u
registraru registrujete ime domena networkutopia . com. Registrar je komercijalni entitet koji
proverava jedinstvenost imena domena, unosi ime u DNS bazu podataka (uskoro ete videti
kako) i za sve svoje usluge dobija malu nadoknadu. Do 1999. godine registrar Netvvork
Solutions imao je monopol na registraciju domena .com, .net i .org.
Meutim, danas postoji mnogo registrara koji se bore da pridobiju korisnike, a sve njih
akrediluje korporacija ICANN (Internet Corporation for Assigned Names and Numbers).
Kompletnu listu akreditovanih registrara moete da potraite na lokaciji http:
//www.internic.net.
Prilikom registracije domena networkutopia . com kod nekog registrara potrebno je da im
date imena i IP adrese primarnog i sekundarnog DNS servera. Pretpostavimo da su imena dnsl.
networkutopia . com, dns2 . networku-topia.com, a adrese 212. 212. 212.1 i 212 . 212 . 212 . 2.
Za svaki od ova dva DNS servera od autoriteta registrar ubacuje NS i A zapis u TLD servere
domena .com. Konkretno, za primarni server od autoriteta za domen networkutopia . com
registrar ubacuje sledea dva zapisa u DNS sistem:
(networkutopia.com, dnsl.netwprkutopia.com, NS)
{dnsl.networkutopia.com, 212.212.212.1, A)
Pored toga, neophodno je i da se zapis tipa A za veb server www. networkuto-pia . com i zapis
tipa MX za server elektronske pote mail. networkutopia. com unesu u DNS servere od
autoriteta. (Sve donedavno sadraj svakog DNS servera konfigurisan je statiki - recimo,
pomou konfiguracione datoteke koja je dobi-jena u Sistem Manageru. Meutim, protokol DNS
sada ima opciju UPDATE koja omoguava dinamiko dodavanje i brisanje podataka iz baze
podataka putem DNS poruka. Ovakvo dinamiko auriranje opisano je u dokumentu RFC
2136,)
Kada uradite sve to smo ovde naveli, ljudi e moi da posete vau veb lokaciju i poalju
elektronsku potu zaposlenima u vaoj kompaniji. Izlaganje o DNS-u zavr-iemo proverom
istinitosti upravo izreene tvrdnje. Osim toga, ova provera e vam pomoi da utvrdite znanja o
ovoj usluzi. Pretpostavimo da Alisa iz Australije eli da poseti veb lokaciju www.
networkutopia . com. Kao to smo ve rekli, njen raunar e najpre da poalje DNS upit njenom
lokalnom DNS serveru. Ovaj lokalni DNS server se odmah zatim obraa TLD .com serveru.
(Ukoliko nema ketranu adresu TLD .com servera, lokalni DNS server e najpre morati da se
obrati nekom osnovnom DNS serveru.) U TLD serveru nalazie se zapisi o resursima tipa A i
NS budui da ih je registrar ve uneo u sve TLD .com servere. TLD server zatim u svom
odgovoru Alisinom lokalnom DNS serveru alje dva zapisa o resursima. Nakon toga lokalni
DNS server alje DNS upit na adresu 212.212.212.1 traei zapis tipa A koji odgovara imenu
www. networkutopia. com. U ovom zapisu nalazi se IP adresa eljenog veb servera - recimo,
212.212.71.4 koju lokalni DNS server vraa Alisinom raunaru. Nakon toga ita sa Alisinog
raunara moe da inicira TCP konekciju sa raunarom 212.212.71.4 i poalje mu HTTP zahtev.
Eto, izgleda da krstarenje Webom i nije toliko jednostavno koliko na prvi pogled izgleda.

136 136 136 136 POGLAVLJE 2 APLIKATIVNI SLOJ 2.80 P2P RAZMENA DATOTEKA 137 137 137 137

2. 6 P2P razmena datoteka
U vreme pisanja ove knjige (poetak 2004. godine) P2P razmena datoteka pravila je vie saobraaja
na Internetu od svih drugih aplikacija, ukljuujui tu i sam Web. Prema tome, kada se ima u vidu
iskljuivo obim saobraaja, P2P razmena datoteka moe se smatrati najvanijom Internet
aplikacijom. Savremeni sistemi za P2P razmenu datoteka koriste se, ne sama za razmenu MP3
muzike (datoteke obino imaju izmeu 3 i 8 MB), ve i za razmenu video materijala (od 10 do 1000
MB), softvera, dokumenata i slika. U nastavku teksta baviemo se komunikacijom i aspektima
umreavanja P2P razmene datoteka. Meutim, ovde ima i mnogo drugih zanimljivih aspekata
vezanih za bezbednost, privatnost, anonimnost, krenje autorskih prava i intelektualnu svojinu.
Radoznale itaoce upuujemo na autore Lohraana i Klarka [Lohmann 2003; Clarke 2002] u ijim e
knjigama pronai informacije o ovim i nekim drugim aspektima ovakvog naina umreavanja,
Pre nego to opiemo unutranju grau sistema za razmenu datoteka izmeu ravnopravnih
korisnika, pogledajmo kako jedan tipian korisnik, recimo Alisa, moe da ga upotrebi. Ona koristi
P2P aplikacije za preuzimanje MP3 datoteka i to tako to na svom kunom ( ravnopravnom")
raunaru aktivira softver za P2P razmenu datoteka a zatim se, korienjem ADSL veze, povezuje
sa Internetom. Alisa obino nou iskljuuje svoj raunar. Njen raunar nema ime, tako da, prilikom
svakog povezivanja, od ISP-a dobije novu IP adresu.
Pretpostavimo da je Alisa u ovom trenutku povezana sa Internetom i da je upravo pokrenula
svoju P2P aplikaciju. Pomou ove aplikacije ona namerava da potrai pesmu ,,Network Love".
Ubrzo nakon zadavanja komande za poetak pretraivanja, aplikacija e joj prikazati listu svih
ravnopravnih korisnika koji su trenutno povezani sa Internetom, imaju kopiju ove pesme i spremni
su daje razmene. Najee su to obini korisnici, poput nje, koji imaju obine raunare. Za svakog
korisnika na ovoj listi, aplikacija moe da prikae i neke pomone informacije, kao to su. na
primer,.njegova propusna mo i procena trajanja preuzimanja datoteke, Nakon toga, Alisa e od
nekog korisnika, recimo od Boba, zatraiti MP3 datoteku koja je zanima. Izmeu njenog i Bobovog
raunara uspostavie se direktna TCP konekcija kojom e datoteka biti prebaena sa jednog
raunara na drugi, Ukoliko Bob tokom preuzimanja iz nekog razloga prekine svoju vezu sa
Internetom, Alisin P2P softver moe da pokua da ostatak datoteke preuzme od nekog drugog
korisnika koji je ima. Isto tako, dok ona od Boba preuzima pesmu ,,Network Love", mogue je da
neki trei korisnik, na primer, Kler sa njenog raunara preuzima pesmu ,,Network 'n' Roll", Dakle, u
mreama ravnopravnih korisnika svaki uesnik je i konzument i dobavlja sadraja.
P2P razmena datoteka zasniva se na paradigmi direktne distribucije sadraja zato to se sav
saobraaj prenosi direktno izmeu obinih ravnopravnih korisnika, bez uea servera treih lica. To
znai da se u P2P umreavanju distribucija sadraja ostvaruje iskoriavanjem resursa (propusna
mo, skladini prostor i procesori)
ogromnog broja ravnopravnih korisnika - nekada i miliona. Drugim recima, mogunosti proirivanja
ovde su praktino neograniene.
Iako transfer ovde nije centralizovan, u njemu uestvuju i serveri treih lica. Veoma je vano
rei da se u P2P razmeni datoteka ipak koristi paradigma klijent-server koja je toliko prisutna na
Internetu (proitajte odeljak 2,1.2). U ovom sluaju, korisnik koji trai datoteku ponaa se kao
klijent, a korisnik sa ijeg raunara se vri transfer - kao server. Datoteka se, putem protokola za
prenos datoteka, prebacuje sa raunara koji se ponaa kao server na raunar koji se ponaa kao
klijent, S obzirom na to da ovde svaki raunar moe biti izabran, svi ravnopravni raunari treba da
budu sposobni za izvravanje i klijentske i serverske strane protokola za transfer datoteka.
Zamislite sada situaciju u kojoj se kao protokol za P2P transfer datoteka koristi protokol
HTTP (obino je zaista tako), Nadovezujui se na na prethodni primer, kada Alisa izabere Boba za
preuzimanje pesme ,,Network Love", njen raunar alje Bobovom HTTP zahtev za ovu pesmu, na
koji Bobov raunar odgovara HTTP porukom u kojoj se ova pesma nalazi. Skreemo vam panju
na to da se sada Bobov raunar ponaa i kao veb klijent i kao privremeni veb server. Za ovaj
raunar kaemo da je veb server zato to, na HTTP zahteve, obezbeduje odreene sadraje.
Atribut privremeni" upotrebljen je zato to ovaj raunar nije neprekidno povezan sa Internetom i
mogue je da pri svakom novom povezivanju ima drugaiju IP adresu.
Do sada smo vam objasnili samo laki deo razmene datoteka izmeu ravnopravnih raunara,
a to je nain na koji se sadraj direktno prebacuje sa jednog raunara na drugi. Meutim, jo nita
nismo rekli o nainu na koji jedan raunar ustanovljava da neki drugi raunari poseduju traeni
sadraj. U P2P sistemu razmene datoteka obino postoji veoma veliki broj povezanih jaunara od
kojih svaki ima objekte za razmenu - MP3 muziku, video materijal, slike i programe. Ukoliko je
ravnopravni raunar X zainteresovan za preuzimanje nekog konkretnog objekta, on mora da zna
kako da ustanovi [P adrese svih povezanih ravnopravnih raunara na kojima postoji kopija datog
objekta. Imajui u vidu to do se u ovakvoj mrei raunari esto ukljuuju i iskljuuju, to nije nimalo
jednostavan problem. U nastavku teksta pomenu-emo tri arhitekture za lociranje sadraja koje se
koriste u razliitim sistemima za P2P razmenu datoteka. itaocima koje ova tema posebno zanima
preporuujemo da proitaju i istraivake radove [Stoica 2001; Rowstron 2001; Ratnasamy 2001;
Zhao 2004; Mavmounkov 2002; Garces-Erce 2003] u kojima su ponuena inovativna reenja za
problem lociranja sadraja,
Centralizovani direktorijum
Jedan od najjednostavnijih pristupa u lociranju sadraja jeste postojanje centrali-zovanog
direktorijuma - onako kako je to uinila kompanija Napster, inae prva komercijalna kompanija koja
je napravila P2P aplikaciju za razmenu MP3 muzike u veim razmerama. U ovoj koncepciji sistem
za P2P razmenu datoteka koristi veliki server (ili grupu servera) koji je zaduen za uslugu
direktorijuma. Kao to moete da vidite na slici 2.23, kada korisnik pokrene svoju P2P aplikaciju,
ona odmah uspostavlja kontakt sa serverom direktorijuma. Konkretno, ona ga obavetava o svojoj

138 138 138 138
POGLAVLJE 2 APLIKATIVNI SLOJ
2.6 P2P RAZMENA DATOTEKA 81 81 81 81

IP adresi i nazivima objekata na lokalnom disku koji su spremni za razmenu (na primer, o
nazivima svih MP3 datoteka). Na ovaj nain server direktorijuma moe da zna koje je objekte
dati korisnik spreman da razmenjuje. Sakupljajui ove informacije od svih aktivnih korisnika,
server direktorijuma pravi centralizovanu dinamiku bazu podataka koja svaki objekat
preslikava na skup IP adresa. Ukoliko neki korisnik obezbedi novu datoteku ili ukloni neku
staru, on o tome obavetava server direktorijuma koji odmah aurira svoju bazu podataka.
Da bi mu baza podataka bila uvek aurna, server direktorijuma treba da zna kako da
ustanovi kada se neki korisnik iskljuio. Korisnik se iskljuuje ili zatvaranjem P2P aplikacije ili
jednostavnim prekidanjem veze sa Internetom.
Periodinim slanjem poruka na koje korisnici treba da odgovore server moe da ustanovi
koji su korisnici trenutno povezani. Kada ustanovi da odreeni klijent vie nije u mrei, server
direktorijuma uklanja njegovu IP adresu iz svoje baze podataka.
U P2P razmeni datoteka sa centralizovanim direktorijumom upotrebljena je hibridna
klijentsko-serverska P2P arhitektura koju smo pominjali u odeljku 2.1.1. Korienje
centralizovanog direktorijuma za lociranje sadraja predstavlja jednostavan koncept koji ima i
brojne nedostatke.
Oslanjanje na jednu taku. Kvar servera direktorijuma onesposobljuje itavu aplikaciju.
ak i ako se koristi grupa redundantnih servera, uvek postoji mogunost kvara na vezi tih
servera sa Internetom, to takoe povlai za sobom pad itave aplikacije,
Postojanje uskog grla u pogledu performansi. U velikim P2P sistemima sa stotinama hiljada
povezanih korisnika centralizovani server mora da odrava ogro-
mnu bazu podataka i odgovara na hiljade upita u sekundi. Godine 2000. kada je bio bez
premca najpopularnija P2P aplikacija, Napster je imao mnogo problema sa saobraajem na
svom centralizovanom serveru.
Krenje autorskih prava. Iako ova tema prevazilazi tematiku ove knjige, kratko emo
pomenuti i to daje diskografska industrija, blago reeno, zabrinuta zbog toga to sistemi za
P2P razmenu datoteka omoguavaju korisnicima da besplatno dou do sadraja koji su
zatieni autorskim pravima. Ukoliko P2P kompanija ima centralizovani server
direktorijuma, pravni postupak protiv nje moe da rezultira zabranom rada i iskljuivanjem
ovog servera, Decentralizovanu arhitekturu je, meutim, mnogo tee iskljuiti.
Prema tome, osnovnu manu korienja centralizovanog servera direktorijuma predstavlja
to stoje P2P aplikacija u tom sluaju samo delimino decentralizovana. Sam transfer datoteka
izmeu ravnopravnih korisnika jeste decentralizovan, ali je proces lociranja sadraja visoko
centralizovan, to predstavlja veliki problem kada su u pitanju pouzdanost i performanse.
Poplava upita ->
Gnutella je aplikacija za P2P razmenu datoteka iz javnog domena u kojoj se sadraj locira kroz
potpuno distribuirani pristup. Za razliku od Napstera, ovoj aplikaciji za traenje sadraja za
razmenu nije potreban centralizovani server. tavie, u Gnutelli je problem lociranja sadraja
reen na dijametralno suprotan nain.
Gnutella klijent (koji ima i korisniki interfejs) implementira protokol Gnutella i izvrava
se kao obian ravnopravni korisnik, Specifikacija ovog protokola je minimalna, to ostavlja
znaajnu slobodu programerima Gnutella klijenta. Kao to postoji veliki broj itaa Weba koji
podravaju protokol HTTP, isto tako postoji i dosta Gnutella klijenata koji implementiraju
istoimeni protokol.
U Gnutelli ravnopravni korisnici formiraju apstraktnu, logiku mreu za koju se koristi
termin preklopljena mrea, koja se u grafiko-teorijskom pogledu definie na sledei nain:
Ukoliko ravnopravni korisnik X odrava TCP konekciju sa ravnopravnim korisnikom Y, onda
kaemo da izmeu njih postoji grana (engl. edge). Grafikon koji ine svi aktivni ravnopravni
korisnici i njihove meusobne TCP konekcije definie aktuelnu Gnutella mreu. Skreemo
vam panju na to da grana ne predstavlja fizike komunikacione linkove. Primera radi, mogue
je da se ona odnosi na TCP konekciju izmeu ravnopravnih korisnika u Litvaniji i Brazilu.
Iako mrea Gnutella moe imati stotine hiljada ravnopravnih korisnika, svaki od njih je
obino povezan sa manje od deset drugih vorova preklopljene mree (slika 2.24). Neto
kasnije videete na koji nain se mrea Gnutella formira i odrava u kontekstu ulaska
ravnopravnih lanova u mreu i izlaska iz nje. Za sada, pretpostaviemo da je preklopljena
mrea ve formirana i pogledati na koji nain ravnopravni korisnici lociraju i pribavljaju
sadraj,
U Gnutelli ravnopravni korisnici alju poruke svojim susedima u preklopljenoj mrei
putem unapred postojeih TCP konekcija. Kada Alisa eli da locira pesmu Netvvork Love",
njen Gnutella klijent svim svojim susedima alje poruku sa upitom (Query) u kojoj su
navedene kljune rei Netvvork Love". Svi Alisini susedi zatim

82 82 82 82 POGLAVLJE 2 APLIKATIVNI SLOJ 2.6 P2P RAZMENA DATOTEKA 14ll 14ll 14ll 14ll

prosleuju ovaj upit svojim susedima i tako redom. Ovaj proces, koji smo ilustrovali na slici
2.24, naziva se poplava upita. Kada primi upit, svaki ravnopravni korisnik proverava da li se
kljune rei poklapaju sa datotekama koje je ponudio za deobu. Ukoliko se ustanovi
poklapanje, korisnik odgovara Alisi potvrdnom porukom (Que-ryHit) zajedno sa imenom
datoteke i njenom veliinom. Ova poruka kree se istom onom putanjom kojom je pristigao i
upit, pa se zato ove veze i nazivaju unapred postojeim TCP konekcijama.
Alisin Gnutella klijent moe da primi potvrdne poruke i od vie korisnika. U tom sluaju
Alisa bira nekog od njih - u ovom sluaju to e biti Bob. Njen klijent zatim uspostavlja direktnu
TCP konekciju sa Bobovim, i alje mu HTTP GET poruku sa nazivom konkretne datoteke.
Nakon toga, Bobov klijent, u svom HTTP odgovoru, alje Alisi datoteku koju je zatraila. Iako
upiti i potvrdne poruke (Query i QueryHit) putuju kroz preklopljenu mreu, poruka HTTP GET
i odgovor ne idu kroz ovu mreu, ve direktno od korisnika do korisnika (slika 2.24). im Alisa
primi itavu datoteku, TCP konekcija izmeu nje i Boba se prekida.
Decentralizovani dizajn aplikacije Gnutella je elegantan i atraktivan ali se kri-tikuje, pre
svega, zbog toga to ova mrea nije proiriva. Konkretno, kod poplave upita, upit jednog
ravnopravnog korisnika se alje svakom drugom lanu mree. To znai da se u mreu isputa
ogromna koliina saobraaja i da se svaki lan prosto zasipa upitima. Dizajneri mree Gnutella
pokuali su da ovaj problem ree ograniavanjem dometa poplave upita. Drugim recima,
kada Alisa poalje svoj inicijalni upit, u polju za brojanje vorova ove poruke upisuje se
odreena vrednost
(recimo, 7). Svaki put kada poruka stigne do nekog novog ravnopravnog korisnika, on
smanjuje vrednost ovog polja za jedan, a zatim prosleduje poruku dalje, svojim susedima.
Kada neki ravnopravni korisnik primi poruku u kojoj je vrednost polja za brojanje vorova
nula, on je vie ne prosleduje. Na ovaj nain poplava upita loka-iizuje se na odreeni region
preklopljene mree, ime se zaista smanjuje obim saobraaja, ali po cenu nepronalaenja svih
ravnopravnih korisnika koji imaju eljeni sadraj. U Gnutelli, dakle, uvek postoji mogunost
da neki sadraj ne moete da locirate samo zato to se nalazi izvan dometa vae poplave upita.
Najvaniji aspekt distribuiranih P2P aplikacija jeste nain na koji one rukuju ulascima
novih korisnika u mreu, kao i izlascima iz nje. Sada emo vam opisati ta se dogaa kada
ravnopravni korisnik X eli da ue u Gnutella mreu. Akcije koje Gnutella preduzima prilikom
izlaska ravnopravnog korisnika iz mree opisane su u domaim zadacima.
1. Ravnopravni korisnik X najpre mora da pronae nekog drugog ravnopravnog korisnika
koji je veu mrei. Klijent X ovaj problema podizanja moe da prevazie tako to e da
odrava listu ravnopravnih korisnika (njihove IP adrese) koji su esto u Gnutella mrei;
isto tako, korisnik X moe da poseti i Gnutellinu veb lokaciju na kojoj postoji takva lista.
2. Kada doe do ove liste korisnik X redom pokuava da uspostavi TCP konekciju sa
korisnicima sa liste sve dok sa nekim korisnikom Y ne uspe u tome.
3. Kada se izmeu ravnopravnih korisnika X i Y uspostavi TCP konekcija, ravnopravni
korisnik X alje Gnutella Ping poruku korisniku Y. U okviru ove poruke nalazi se i polje za
brojanje ravnopravnih korisnika. Kada primi ovu Ping poruku korisnik Y je dalje
prosleduje svim svojim susedima u preklopljenoj mrei. Ostali ravnopravni korisnici
nastavljaju da prosleuju ovu poruku na isti nain sve dok vrednost polja za brojanje
ravnopravnih lanova ne postane nula.
4. im korisnik Z primi Gnutella Ping poruku, on na nju odgovara Gnutella Pong porukom
koju kroz preklopljenu mreu vraa korisniku X. U okviru Pong poruke nalaze se IP adresa
ravnopravnog korisnika Z, zatim broj datoteka koje su spremne za razmenu, kao i njihova
ukupna veliina.
5. Nakon prijema Pong poruka, uz korisnika Y sada i korisnik X zna IP adrese mnogih drugih
ravnopravnih korisnika Gnutella mree. Sa nekima od njih on moe da uspostavi TCP
konekcije i tako od sebe formira nekoliko grana. Osim toga, ravnopravni korisnik X moe
da pokua da uspostavi TCP konekcije i sa mnogim drugim vorovima za podizanje. U
specifikaciji mree Gnutella, ne precizira se sa koliko ravnopravnih korisnika korisnik X
moe da se povee, tako daje tu ostavljena izvesna sloboda programerima Gnutella
klijenata.
U ovom delu govorili smo o svim najvanijim karakteristikama protokola Gnutella, a u
domaim zadacima emo im posvetiti jo malo panje. Dakle, Gnutella predstavlja jednostavan
distribuiran P2P sistem koji omoguava traenje datoteka koje se nalaze kod susednih korisnika
(susedni korisnici su oni koji su u preklopljenoj mrei udaljeni nekoliko skokova).

2.6 P2P RAZMENA DATOTEKA 143 143 143 143
i-

Korienje heterogenosti
Do sada ste videli da aplikacije Napster i Gnutella prilikom lociranja sadraja koriste dva
dijametralno suprotna pristupa. Napster koristi centralizovani server direktorijuma i moe da
locira sav sadraj bilo kog ravnopravnog korisnika. Gnutella koristi potpuno distribuiranu
arhitekturu, ali locira samo onaj sadraj koji se nalazi kod susednih ravnopravnih korisnika u
preklopljenoj mrei, U aplikaciji po imenu KaZaA [KaZaA 2004] pozajmljene su ideje iz oba
prethodno pomenuta pristupa, a kao krajnji rezultat dobijen je izuzetno moan sistem za P2P
razmenu datoteka koji je u vreme pisanja ove knjige stvarao vie saobraaja na Internetu od bilo
koje druge aplikacije [Gummadi 2003] [Saroiu 2003].
Tehnologija aplikacije KaZaA je vlasnika, Uz to, ova aplikacija sav svoj saobraaj (osim
samih datoteka koje se razmenjuju) alje u ifrovanom obliku. Meutim, iz osnovnih opisa koji
mogu da se pronau na veb lokaciji KaZaA, kao i iz nekih njihovih merenja [Liang 2004]
mogue je zakljuiti na koji nain ovaj protokol funkcionie. Prvo to bi moglo da se kae o
ovoj aplikaciji jeste to da KaZaA koristi heterogenost na veoma intuitivan i prirodan nain.
Poput Gnutelle, KaZaA prilikom traenja i lociranja sadraja za razmenu ne koristi
namenski server (ili grupu servera). Meutim, ovde, za razliku od Gnutelle, nisu svi
ravnopravni korisnici isti. Moniji korisnici - oni sa linkovima vee propusne moi i veom
mogunou povezivanja - imaju ulogeyoa grupa i uz to vee odgovornosti. Kada neki
ravnopravni korisnik nije voa grupe, on postaje obian korisnik i dodeljuje se nekom voi
grupe (slika 2.25). Voa grupe najee moe imati i nekoliko stotina podreenih ravnopravnih
korisnika.
Nakon pokretanja aplikacije KaZaA, ravnopravni korisnik uspostavlja TCP konekciju sa
nekim vodom grupe i informie ga o tome koje datoteke nudi za deobu. Ove informacije slue
voi grupe za odravanje baze podataka u kojoj se nalaze identifikatori svih lanova njegove
grupe, zatim metapodaci o samim datotekama, kao i odgovarajue IP adrese lanova grupe kod
kojih se te datoteke nalaze. Na ovaj nain svaki voa grupe postaje mini (Napster) hab. Ali, za
razliku od Napstera, voa grupe nije namenski server, ve i dalje obian korisnik.
Kada bi svaki od ovih mini-habova, zajedno sa svojim lanovima, predstavljao izolovan
entitet, mrea KaZaA bi se, u osnovi, sastojala od hiljada izolovanih mini-Napster mrea u
kojima ulogu haba ima ravnopravni korisnik a ne namenski server. Ovakav izolovani pristup bi,
sa svoje strane, znaajno ograniio obim sadraja koji moe da stoji na raspolaganju svakom
ravnopravnom korisniku. Ovo ogranienje otklonjeno je meusobnim TCP konekcijama
izmeu voa grupe i stvaranjem pre-klopljene mree izmeu njih samih. To znai da voe
grupe formiraju mreu koja podsea na mreu aplikacije Gnutella. U mrei KaZaA informacije
o dostupnom sadraju razmenjuju se izmeu grupa. Ova meusobna razmena informacija moe
da se postigne na nekoliko naina. Primera radi, hab jedne grupe moe da se obrati habovima
drugih grupa i od njih dobije kopije njihovih baza podataka, koje zatim moe da objedini sa
sopstvenim informacijama, ime se postie praenje sadraja daleko veeg broja korisnika. Isto
tako, svaki hab bi mogao da prati samo sadraj lanova sopstvene grupe, ali da, kada primi neki
upit, taj upit prosledi svim ostalim habovima sa kojima je povezan. (Ovaj pristup podsea na
poplavu upita protokola Gnutella, sa tom razlikom to u preklopljenoj mrei voa grupe
poplava ima sasvim ograniene razmere.)
U mrei KaZaA svaka datoteka identifikuje se he identifikatorima na koje emo se vratiti
za koji trenutak. Osim toga, ovde svaki objekat ima i svoj deskriptor koji obuhvata ime
datoteke, kao i njegov nestrukturisani tekstualni opis. Ravnopravni korisnici u upitima koriste
kljune rei, to podsea na nain korienja pretraivaa, Prilikom traenja kljunih rei, dati
ravnopravni korisnik alje svom voi grupe upit sa kljunim recima. Na ovaj upit voda grupe
odgovara listom na kojoj su navedeni ravnopravni korisnici (unutar svoje grupe ili izvan nje)
koji imaju datoteke iji se deskriptori poklapaju sa kljunim recima, kao i identifikatori tih
datoteka. Voa grupe zatim moe da prosledi dobijeni upit i voama drugih grupa sa kojima je
povezan. Njihovi odgovori vraaju se obrnutom putanjom kroz preklopljenu mreu.
Dakle, u arhitekturi mree KaZaA postoji heterogenost ravnopravnih korisnika u tom
smislu to mali broj monijih korisnika dobija ulogu voa grupe koji, dalje, formiraju najvii
sloj hijerarhije preklopljene mree (slika 2.25). U poreenju sa dizajnom mree Gnutella koji se
odlikuje ravnim preklapanjem i ogranienim opsegom poplave upita, hijerarhijski dizajn
omoguava proveru znaajno veeg broja korisnika, bez preobimnog saobraaja. (Ubedljivo
najvei deo dananjeg saobraaja mree aplikacije KaZaA odlazi na transfer samih datoteka,)
U aplikaciji KaZaA koristi se itav niz tehnika koje poboljavaju njene performanse. U
ove tehnike koje mogu da se pfimene u skoro svim sistemima za P2P razmenu datoteka
spadaju:

2. . P2P RAZMENA DATOTEKA 145 145 145 145

1. Stavljanje zahteva u red. Svaki korisnik moe u svom programu da ogranii broj
istovremenih preuzimanja sa svog raunara. (Podrazumevane vrednosti kreu se od tri do
sedam.) Ukoliko Alisa u svom programu ogranii broj preuzimanja sa njenog raunara na
tri i ukoliko su sva tri preuzimanja ve u toku, Bobov zahtev za preuzimanje neke
datoteke, kao i svi sledei zahtevi smetaju se u lokalni red. Ovakvim lokalnim
ograniavanjem obezbeduje se da svaka datoteka koja se preuzima od vora koji je nekome
predaje dobije adekvatan deo propusne moi.
2. Podsticanje prioriteta. Prilikom stavljanja drugih ravnopravnih korisnika u red, Alisa e
dati prednost onima koji su do tada predali vie datoteka nego to su preuzeli. Primera radi,
ako su u njenom redu Bob i Kler, a Bob je preuzeo vie nego stoje predao, dok je Kler
predala vie nego stoje preuzela, Alisa
e najpre izai u susret zahtevu koji joj je stigao od Kler. Ovim mehanizmom korisnici se
podstiu da predaju vie datoteka ime se poveava sveukupna proirivost sistema KaZaA.
3. Paralelno preuzimanje. Kada Kler potrai pesmu ,,Network Love" KaZaA
joj najee vraa listu sa nekoliko korisnika kod kojih je ustanovljeno pokla-
panje kljune rei. Neka od ovih poklapanja odnosie se na istu datoteku to
se proverava identifikatorima datoteka. Njen klijent moe korienjem HTTP zaglavlja
da zahteva razliite delove datoteke od razliitih korisnika, odnosno da paralelno preuzima
delove datoteke od razliitih korisnika. Ukoliko, primera radi, Alisa i Bob imaju datoteku
koju Kler trai, njen KaZaA klijent moe od Alise da zatrai prvu polovinu datoteke, a od
Boba drugu. Ova mogunost znaajno ubrzava transfer datoteka u najrazliitijim
okolnostima,
Ukratko emo pomenuti i injenicu da se za aplikaciju KaZaA vezuju i mnogi pokuaji
reverznog inenjeringa; tavie, u nekim projektima razvijene su modifiko-vane verzije KaZaA
klijenata koje omoguavaju korisnicima pristup mrei KaZaA bez apsolutno oslednog praenja
ovog protokola. Trenutno je veoma popularan klijent po imenu kazaa-lite koji, pored toga Sto
eliminie ugraeno oglaavanje i daje svim korisnicima najvii prioritet, izvrava i skakanje od
jednog do drugog super-vora, odnosno trai kljune rei redom od jednog do drugog voe
grupe.
Poput svoje prethodnice Napstera, KaZaA se razvio u izuzetno popularnu Internet
aplikaciju koja je za samo nekoliko meseci privukla milione korisnika. Neve-rovatno brzo
irenje aplikacija za P2P razmenu datoteka, kao i Weba i trenutne razmene poruka pre njih,
svedoi o kvalitetu dizajna sveukupne arhitekture Interneta prilikom ijeg dizajniranja nije bilo
mogue zamisliti kakve e se aplikacije razviti u narednih 25 godina. Mrene usluge koje se
stavljaju na raspolaganje internetskim aplikacijama - transport datagrama bez konekcije,
pouzdani transport datagrama sa konekcijom, interfejs soketa, zatim usluge adresiranja i
imenovanja (DNS) - pokazale su se dovoljno uspenim za razvoj hiljada novih aplikacija. S
obzirom na to da su sve ove aplikacije smetene povrh postojea etiri sloja Internet familije
protokola, za njih je bilo potrebno samo razviti nov klijentsko-serverski softver za krajnje
sisteme. Upravo zahvaljujui tome ove aplikacije se brzo prave i putaju u rad,
SiiilS- KRATAK OSVRT
KaZaA
U vreme pisanja ove knjige (april 2004. godine) u mrei KaZaA svakodnevno je uestvovalo
vre od 3 miliona korisnika koji su izmeu sebe razmenjivali 5.000 rerobajto raznog sadraja.
S obzirom na to da najvei deo ovog sadraja predstavljaju zatiene pesme i filmovi, KaZaA
je veliki neprijatelj i muzike i filmske industrije. Osim toga, saobraaj iz ove mree izuzetno
optereuje razliite posrednike za Internet usluge. Primera radi, u mrei Univerziteta u
Vaingtonu juna 2002. godine oko 37 procenata celokupnog TCP saobraaja pravila je
upravo ova aplikacija - to je bilo dva pufa vie od saobraaja koji je stvarao VVeb [Saroiu
2002]. Verovatno se sada pitate gde se ova fantastina aplikacija pojavila i koji su njeni krajnji
dometi.
Privatna, holandska kompanija po imenu FastTrack je aprila 2000, godine objavila prvu
verziju programa KaZaA, Ve ova prva verzija imala je.hijerarhijsku arhitekturu sa
supervorovima koja je i danas zatitni znak ove aplikacije. U nekoliko narednih godina
kompanije kao to su, MusicCity (Morpheus), Grokster i iMesh su licencirale softver kompanije
FastTrack. Nakon tube Diskografske asocijacije SAD [Recordi ng Indusl r/ Associ ati on of
Ameri ca, RIAA) i holandskih sudova, februara 2002. godine najvei deo kompanije FastTrack
preao je u ruke kompanije Sharman Netv/orks. Struktura ove novonastale kompanije je
veoma zamrena i sloena. Kompanija Sha rman Networks zvanino je prijavljena na malom
pacifikom oslrvu Vonuatu, sedite joj je u Australiji, a veliki broj njenih programera ivi i radi u
Estonrjil Ovako sloena i zamreno struktura znaajno oteava posao amerikim kompanijama
i udruenjima koji bi eleli da je tue.
Veoma je zanimljivo i pitanje budueg rasta mree KaZaA, ok i u sluaju da se kompanije
koje stoje iza nje zatvore (iz pravnih ili finansijskih razloga). Kao to ste ve videli, mrea
KaZaA odlikuje se veoma decentralizovanom arhitekturom koja se ne oslanja na servere.
Prema tome, vrlo je verovatno da bi i bez kompanijo koje stoje iza nje ova mrea nastavila
da.postoji u nekom obliku. Diskografsko industrija na sve mogue naine pokuava da ogranii
ovakvu razmenu datoteka preduzimajui mere, kao to su tube protiv individualnih korisnika
aplikacije KaZaA ili putanje lanih datoteka u mreu [Overpeer 2004],
Konano, mi [autori ove knjige) predviamo pojavu beinih P2P sistema zo razmenu
datoteka u kojima e pojedinci - recimo, studenti - imoti PDA raunare sa gigabajtima prostora
i Wi-Fi (beine) mogunosti komunikacije. Ovi Wi-Fi BSIO sakriveni u kolskim torbama
funkcionisae u takozvanom ad hoc reimu to e im omoguili diskretnu razmenu datoteka
beinim putem. Jgsno je do e kompanijama i udruenjima kao to je, na primer, RIAA biti
veoma teko da prate i eventualno ometu ovakve P2P sisteme.
Ipak, nisu sve nove Internet aplikacije imale toliko uspeha kao VVeb, trenutna razmena
poruka i P2P razmena datoteka, Multimedijalne konferencije i protok multimedijalnih sadraja
u realnom vremenu su, recimo, dve aplikacije koje jo uvek nisu doivele toliki uspeh, Vreme
e pokazati da lije kod njih ograniavajui faktor predstavljao nedovoljan skup usluga aktuelne
arhitekture Interneta (o predlozima za njeno proirivanje u smislu podrke ovih aplikacija
govoriemo u poglavlju 7) ili su to bili drutveni i ekonomski faktori.

2,7 PROGRAMIRANJE SOKETA ZA PROTOKOL TCP 147 147 147 147

2. 7 Programiranje soketa za protokol TCP
Sada kada smo vam pokazali nekoliko vanih mrenih aplikacija, pogledajmo na koji nain se
ovakvi programi piu. U ovom odeljku napisaemo aplikacije koje koriste protokol TCP, dok
e u sledeem odeljku to biti aplikacije za protokol UDP.
Ako se seate, u odeljku 2,1 rekli smo da jezgro mrene aplikacije ine dva programa -
klijentski i serverski. Izvravanje ova dva programa dovodi do stvaranja klijentskog i
serverskog procesa koji izmeu sebe komuniciraju itanjem iz soketa i pisanjem u njih.
Prilikom programiranja mrene aplikacije, osnovni zadatak programera je da napie kod za
klijentski i serverski program.
Postoje dve vrste klijentsko-serverskih aplikacija. Prvu vrstu ine klijentsko-serverske
aplikacije koje predstavljaju implementaciju standarda protokola koji je definisan RFC
dokumentom. Kod ovakvih implementacija klijentski i serverski program moraju da budu u
skladu sa pravilima koja diktiraju RFC dokumenti. Primera radi, klijentski program bi mogao
da predstavlja implementaciju FTP klijenta (ode-Ijak 2.3) koji je definisan u dokumentu RFC
959, dok bi serverski program mogao da bude implementacija FTP servera koji je takoe
definisan u dokumentu RFC 959. Ukoliko jedan programer napie kod za klijentski program, a
neki drugi, potpuno nezavisno, za serverski i pri tom se obojica dosledno pridravaju pravila
koja diktiraju RFC dokumenti, dva programa e biti interoperabilna. U stvari, u velikom broju
savremene mrene aplikacije podrazumevaju komunikaciju izmeu klijentskih i ser-verskih
programa koje su potpuno nezavisno napravili razliiti programeri (situacije ove vrste su kada,
na primer, Netscape ita komunicira sa Apache veb serverom, ili kada FTP klijent na nekom
personalnom raunaru predaje neku datoteku UNIX FTP serveru). Kada klijentski ili serverski
program implementira protokol koji je definisan u RFC dokumentu, on treba da koristi onaj
broj porta koji je povezan sa datim protokolom. (O brojevima portova smo ukratko govorili u
odeljku 2.1. U poglavlju 3 pruiemo vam vie informacija o njima.)
Drugu vrstu klijentsko-serverskih aplikacija ine specijalne (vlasnike) aplikacije. U ovom
sluaju ni klijentski ni serverski programi ne moraju biti u skladu sa bilo kojim RFC
dokumentom. Njih pravi jedan programer (ili jedan tim) i on ima apsolutnu kontrolu nad svime
to se deava unutar koda. Ali, budui da ovakvi programi ne implementiraju protokol koji se
nalazi u javnom domenu, drugi nezavisni programeri ne mogu da razviju kod koji bi bio
interoperabilan sa njima. Prilikom programiranja vlasnikih aplikacija programeri treba da
izbegnu korienje brojeva dobro poznatih portova koji su definisani u RFC dokumentima.
U ovom i u sledeem odeljku baviemo se kljunim aspektima programiranja vlasnikih
klijentsko-serverskih aplikacija. U fazi programiranja jedna od prvih pro-gramerovih odluka
odnosi se na to da li e njegova aplikacija koristiti protokol TCP ili protokol UDP. Podseamo
vas da su TCP veze sa konekcijom i obezbeuju pouzdane kanale za protok podataka izmeu
dva krajnja sistema. Kod UDP veza, nasuprot lome, nema konekcije i njima se nezavisni paketi
podataka alju od jednog do drugog krajnjeg sistema bez ikakvih garancija u pogledu isporuke.
U ovom odeljku razviemo jednostavnu klijentsku aplikaciju koja koristi TCP, a u
sledeem isto tako jednostavnu klijentsku aplikaciju koja koristi UDP. Ove jednostavne TCP i
UDP aplikacije predstavljene su u programskom jeziku Java, Programe smo mogli da napiemo
i u programskim jezicima C ili C++, ali smo se opredelili za Javu iz vie razloga, Najpre,
aplikacije napisane u Javi imaju jednostavniji i istiji kod, sa manje redova od kojih svaki, bez
ikakvih tekoa, moe da se objasni i programeru poetniku. Zatim, programiranje
klijentsko-serverskih aplikacija u Javi je sve popularnije i moe se oekivati da u narednim
godinama postane standard. Ukoliko vam ovaj programski jezik nije poznat, ne oajavajte.
Programersko iskustvo u bilo kom drugom programskom jeziku pomoi e vam da ovaj kod
pratite bez ikakvih problema.
Za itaoce koje posebno zanima programiranje klijentsko-serverskih aplikacija u
programskom jeziku C postoji nekoliko dobrih referenci [Donahoo 2000; Stevens 1997; Frost
1994; Kurose 1996].

2.7.1 Programiranje soketa za protokol TCP
Ukoliko se seate, u odeljku 2.1 rekli smo da procesi koji se izvravaju na razliitim raunarima
meusobno komuniciraju slanjem poruka u sokete. Rekli smo i to da su soketi za procese ono
to su vrata za kue. Kao to moete da vidite na slici 2.26, soket predstavlja vrata izmeu
procesa aplikacije i protokola TCP, Programer aplikacije ima kontrolu nad svime to se deava
sa strane soketa ka aplikaciji, dok na ono to se deava sa njihove druge strane, ka transportnom
sloju, nema skoro nimalo uticaja. (U najboljem sluaju programer aplikacije moe da podesi
nekoliko TCP parametara, kao to su, na primer, maksimalna veliina privremene memorije ili
maksimalna veliina segmenata.)

2.7 . PROGRAMIRANJE SOKETA ZA PROTOKOL TCP 149 149 149 149

Pogledajmo sada izbliza kako izgleda interakcija klijentskog i serverskog programa. Klijent je
taj koji treba da inicira komunikaciju sa serverom. Da bi mogao da odgovori na klijentov
inicijalni kontakt, server mora biti spreman, Sto podrazumeva dve stvari. Najpre, serverski
program ne moe da bude neaktivan; on mora da bude aktivan kao proces pre nego to klijent
uopte pokua da uspostavi inicijalni kontakt. Zatim, serverski program mora imati neku vrstu
vrata (odnosno, soket) koji e da reaguje na klijentov inicijalni kontakt. Vraajui se za trenutak
analogiji sa kuom i vratima, ovaj klijentov inicijalni kontakt esto se naziva kucanjem na
vrata".
Dakle, ako je serverski proces aktivan, klijentski proces moe da inicira TCP konekciju sa
serverom. Ovo se postie tako to klijentski program pravi soket. Kada napravi svoj soket,
klijent navodi adresu serverskog procesa, odnosno, IP adresu servera i broj porta procesa.
Odmah nakon pravljenja soketa, protokol TCP klijentskog procesa inicira trodelnu
sinhronizaciju i uspostavlja TCP konekciju sa serverom. Ova trodelna sinhronizacija je potpuno
transparentna i za klijentski i za serverski program.
Tokom trodelne sinhronizacije, klijentski proces kuca na vrata" serverskog procesa. Kada
uje" ovo kucanje, serverski proces pravi nova vrata (odnosno, soket) koja su namenjena samo
tom klijentu. U primerima koji slede, vrata na koja klijent kuca bie objekat ServerSocket koji
emo nazvati imenom welcomeSocket. Kada klijent zakuca na ova vrata, program priziva
metod accept () objekta wel-comeSocket koji za datog klijenta pravi nova vrata. Na kraju faze
sihronizacije izmeu klijentovog soketa i novog soketa na serveru postoji TCP konekcija, tako
da emo ovaj novi soket nazvati serverovim soketom povezivanja,
Iz perspektive aplikacije TCP konekcija je direktna virtuelna linija izmeu klijentovog
soketa i soketa povezivanja na serveru. Odmah nakon toga klijentski proces moe da pone sa
slanjem podataka u soket; protokol TCP garanruje da e serverski proces primiti (kroz soket
povezivanja) svaki poslati bajt, tavie, kao to ljudi kroz ista vrata mogu i da ulaze i da izlaze,
klijentski proces putem svog soketa moe da prima podatke, a serverski proces kroz soket
povezivanja moe da ih alje. Ovaj koncept ilustrovan je na slici 2.27. S obzirom na to da soketi
imaju kljunu ulogu u klijentsko-serverskim aplikacijama, za programiranje ovakvih aplikacija
esto se koristi termin programiranje soketa.
Pre nego to preemo na na primer klijentsko-serverske aplikacije, ne bi bilo loe da
razjasnimo i pojam tok. Tok predstavlja seriju znakova koji ulaze u neki proces ili iz njega
izlaze. Svaki tok je ili ulazni tok procesa ili njegov izlazni tok. Ukoliko je re o ulaznom toku,
on je uvek povezan sa nekim izvorom ulaza za dati proces, kao to je, na primer, standardni
ulaz (putem tastature) ili soket u koji podaci ulaze sa Interneta. Ako je, s druge strane, re o
izlaznom toku, on je uvek povezan sa nekim izvorom izlaza za dati proces, to moe biti
standardni izlaz (monitor) ili soket iz koga podaci idu na Internet.
2.7.2 Primer klijentsko-serverske aplikacije u Javi
Za ilustraciju programiranja soketa za protokole TCP i UDP koristiemo ledeu jednostavnu
klijentsko-serversku aplikaciju:
1. Klijent ita red teksta iz standardnog ulaza (tastature) i iz svog soketa alje ovaj red
serveru.
2. Server ita red iz svog konekcijskog soketa.
3. Server pretvara ovaj red teksta u velika slova.
4. Server iz svog konecijskog soketa alje izmenjeni red teksta klijentu.
5. Klijent ita primljeni red teksta iz svog soketa i izbacuje ga na svom standardnom izlazu
(monitor).
Na slici 2,28 ilustrovane su glavne aktivnosti klijenta i servera u vezi sa soketima.
Zatim emo vam prikazati klijentsko-serverski par programa za TCP implementaciju
aplikacije. Red po red, detaljno emo analizirati oba ova programa. Klijentski program nazvali
smo TCPClient. j ava, a serverski TCPServ^r. jave. Da bismo naglasili kljune aspekte,
namerno smo ponudili kd koji je taan, ali ne i apsolutno stabilan. Pravi kod" bi svakako
imao jo nekoliko pomonih redova.


Nakon kompajliranja ovih programa na njihovim matinim raunanma, serverski program se
prvi izvrava ime se na serveru stvara proces. Kao to smo ve rekli, serverski proces eka na
inicijalni kontakt klijentskog procesa. U ovom sluaju, nakon pokretanja klijentskog programa stvara
se klijentski proces koji kontaktira sa serverom i sa njim uspostavlja TCP konekciju. Odmah zatim,
korisnik klijentskog raunara moe da upotrebi aplikaciju i poalje red teksta i potom primi isti taj red
ispisan velikim slovima.
TCPCIient.java
Evo kako izgleda kod klijentske strane aplikacije:
import java.io. * ; import
java.net. * ; class TCPClient {
public static void main(String argvfj) throws Exception
{
String sentence;
String modifiedSentence;
BufferedReader inFromUser = new BufferedReader( new
InputStreamReader(System.i n ) ) ;
Socket clientSocket = new Socket("hostname", 6 7 8 9 ) ;
DataOutputStream outToServer = new DataOutputStream{
clientSocket.getOutputStream( ) ) ;
BufferedReader inFromServer =
new BufferedReader(new InputStreamReader(
clientSocket.getlnputStream ( ) ) ) ;
sentence = inFromUser.readLine ( ) ;
outToServer.writeBytes(sentence +
x
\ n ' } ;
modifiedSentence = inFromServer.readLine( ) ;
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close( ) ;
}
)
Kao to moete da vidite na slici 2.29, program TCPClient pravi tri toka i jedan soket. Ime soketa je
clientSocket. Tok inFromUser predstavlja ulazni tok programa; on je povezan sa standardnim
ulazom (tastaturom). Znaci koje korisnik upie pomou tastature ulaze u tok inFromUser. Tok
inFromServer je drugi ulazni tok programa i on je povezan sa soketom. Znaci koji stiu iz mree
ulaze u tok InFromServer. Konano, tok outToServer je izlazni tok programa i on je takoe povezan
sa soketom. Znaci koje klijent poalje u mreu ulaze u tok outToServer.
Obratimo sada panju na neke redove ovog koda.
import j a v a . i o . * ; import
java.net. * ;

Objekti java.ioijava.net predstavljaju Java pakete. Paket java . io sadri klase za ulazne i
izlazne tokove. Konkretno, paket java . io sadri klase Buf f erReader i DataOutputStream koje
program koristi za pravljenje tri prethodno ilustrovana toka. Paket j ava. net obezbeduje klase za
mrenu podrku. Konkretno, on sadri klase Socket i ServerSocket. Objekat clientSocket ovog
programa izvodi se iz klase Socket.
class TCPClient (
public static void main(String argvf]) throws Exception
( (( ( .............. .............. .............. .............. 1 11 1
}
Sve to ste do sada videli predstavlja standardni nain na koji zapoinje veine Java programa.
Prvi red predstavlja poetak bloka koji definie klasu. Kljunom reju class poinje definicija
klase po imenu TCPClient. Klasa sadri promen-ljive i metode koji su ogranieni velikim
zagradama na poetku i na kraju bloka za definiciju klase. Klasa TCPClient nema promenljive
i ima samo jedan metod - main (). Metodi programskog jezika Java podseaju na funkcije ili
procedure programskog jezika C; metod main programskog jezika Java veoma je slian istoi-
menoj funkciji programskih jezika C i C++. Kada Java interpreter aktivira aplikaciju
(pozivanjem putem klase za kontrolu aplikacije), ona odmah poziva klasni metod main. Ovaj
metod zatim poziva sve ostale metode koji su potrebni za izvravanje aplikacije. Budui daje
ovo uvod u programiranje soketa u programskom jeziku Java, na ovom mestu emo da
zanemarimo kljune rei public, static, void, main i thxows Exceptions (ove rei ipak moraju
da budu u kodu).
String sentence;
String modifiedSentence;
Dva prethodna reda deklariu objekte tipa String. Objekat sentence jeste string koji korisnik
upisuje i koji se zatim alje serveru. Objekat modif iedSentence jeste string koji se dobija od
servera i alje ka standardnom izlazu korisnika.
BufferedReader inFromUser = new BufferedReader( new
InputStreamReader(System.in));
Prethodni red koda pravi objekat toka inFromUser tipa Buf f eredReader, Ovaj ulazni tok
inicijalizuje se objektom System. in koji ga povezuje sa standardnim ulazom. Ova komanda
omoguava klijentu da proita tekst koji je upisan njegovom tastaturom.

Socket clientSocket = new Socket("hostname", 6789);
Ovim redom koda pravi se objekat clientSocket tipa Socket. Pored toga, ovaj red inicira TCP
konekciju izmeu klijenta i servera. String "hostname" mora da se zameni imenom servera
(recimo, "apple . poly. edu"). Pre same inicijaliza-cije TCP konekcije, klijent izvrava
pretraivanje DNS baze podataka kako bi doao do potrebne IP adrese datog matinog
raunara. Broj 6789 jeste broj porta. Uvek moete da upotrebite i neki drugi broj porta, ali isti
taj broj morate da koristite i na serverskoj strani aplikacije. Kao to smo ve rekli, serverski
proces se identifikuje IP adresom i brojem porta aplikacije.

154 154 154 154 POGLAVLJE 2 APLIKATIVNI SLOJ 2.7 PROGRAMIRANJE SOKETA ZA PROTOKOL TCP 155 155 155 155

DataOutputStream outTo Server =
new DataOutputStream(clientSocket.getOutputStream(}); BufferedReader inFromServer =
new BufferedReader(new inputStreamReader(
clientSocket.getlnputStream()));
Pomou ova dva reda koda prave se objekti tokova koji se povezuju sa sokelom. Tok
outToServer obezbeduje izlaz procesa ka soketu, dok tok inFromServer obezbeduje ulaz
procesa iz soketa (slika 2.29).
sentence = inFromUser.readLine();
Ovaj red koda zaduenje za smetanje korisnikovog teksta u string sentence. String sentence
nastavlja da prima znakove sve dok korisnik ne zavri red znakom za povratak na poetak reda.
Korisnikov tekst iz standardnog ulaza (tastature), preko toka inFromUser prelazi u string
sentence.
outToServer.writeBytes(sentence +
x
\n');
Ovaj red koda alje string sentence koji je proiren znakom za povratak na poetak reda u tok
outToServer. Ovaj proireni string protie kroz klijentov soket i ulazi u TCP. Nakon toga,
klijent eka na prijem znakova od servera.
modifiedSentence = inFromServer.readLine{);
Kada tekst stigne iz servera, on prolazi kroz tok inFromServer i smeta se u string modif
iedSentence. Znaci se sakupljaju punei string modif iedSentence sve do zavretka teksta koji
je oznaen znakom za povratak na poetak reda.

System.out .println ("FROM SERVER " 4- modif iedSentence) ;
Prethodni red koda zaduenje za ispisivanje na monitoru stringa modif iedSentence koji je
dobijen od servera.
clientSocket.close ();
Ovim poslednjim redom koda zatvara se soket, a to znai i TCP konekcija izmeu klijenta
i servera. To dalje znai da TCP klijentske strane alje TCP poruku serverskoj strani TCP
(proitajte odetjak 3,5).
TCPServer.java
Pogledajmo sada kako izgleda serverski program.
import java.io.*; import java.net.*;
class TCPServer {
public static void main(String argvf]} throws Exception (
String clientSentence; String capitalizedSentence;
ServerSocket welcomeSocket - new ServerSocket_
(6789); ' while
(true) {
Socket connectionSocket = welcomeSocket._
accept(); BufferedReader inFromClient =
connectionSocket.getlnputStream()) ) ; DataOutputStream outToClient = new
DataOutputStream(
connectionSocket.getOutputStream()); clientSentence ~
inFromClient.readLine(}; capitalizedSentence =
clientSentence . toUpperCase () +
1
\n' ;.
outToClient.writeBytes(capitalizedSentence);
I II I
}
Program TCPServer ima mnogo slinosti sa programom TCPClient. Da vidimo kako ovaj
program izgleda izbliza. U nastavku neemo komentarisati one delove koda koji su identini ili
slini sa kodom programa TCPClient. java.
Prvi red programa TCPServer veoma se razlikuje od onoga to ste videli u programu
TCPClient i glasi:
ServerSocket welcomeSocket = new ServerSocket(6789};
Ovim redom koda pravi se objekat welcomeSocket tipa ServerSocket. Ovaj objekat predstavlja
svojevrsna vrata koja oslukuju kucanje" klijenta i to ine na portu broj 6789. Sledei red
koda je:
Socket connectionSocket = welcomeSocket.accept();

156 156 156 156 , POGLAVLJE 2 APLIKATIVNI SLOJ 2.8 PROGRAMIRANJE SOKETA ZA PROTOKOL UDP 157 157 157 157

Ovaj red pravi novi soket po imenu connectionSocket im se klijent obrati objektu
welcomeSocket. I ovaj soket ima broj porta 6789. (U poglavlju 3 obja-sniemo zato oba soketa
imaju isti broj porta.) Protokol TCP zatim uspostavlja direktan virtuelni vod izmeu objekta
clientSocket na klijentskoj strani i objekta connectionSocket na serverskoj strani. Klijent i
server nakon toga mogu da zaponu meusobnu razmenu podataka, a svi bajtovi stiu
predvienim redosle-dom na drugu stranu. Nakon uspostavljanja objekta connectionSocket,
server pomou objekta welcomeSocket nastavlja da oslukuje eventualne zahteve drugih
klijenata. (Ova verzija programa, u stvari, ne oslukuje zahteve drugih klijenata, ali dodavanjem
programskih niti to moe da se izmeni.) Program zatim pravi nekoliko objekata tokova koji su
veoma slini odgovarajuim objektima napravljenim u clientSocket. Preimo sada na sledei
znaajan red;
capitalizedSentence = clientSentence.toUpperCase() + *\n';
Ova komanda predstavlja srce aplikacije. Ona uzima red teksta koji je poslao klijent, pretvara
ga u velika slova i dodaje znak za povratak na poetak reda. Komanda koristi metod
toUpperCase (). Sve druge komande programa mogle bi da se nazovu perifernim; one slue
samo za komuniciranje sa klijentom.
Da biste testirali ovaj par programa, program TCPClient. java ete instalirati i kompajlirati
najednom raunam, a program TCPServer . j ava na drugom. Nemojte zaboraviti da u programu
TCPClient. j ava tano navedete ime matinog raunara-servera. Nakon toga ete na serveru da
pokrenete kompajlirani program TCPServer. class. Ovaj program na serveru pravi proces koji
miruje sve dok sa njim ne kontaktira neki klijent. Potom ete na klijentskom raunaru da
pokrenete kompajlirani program TCPClient. class koji e na tom raunaru da napravi proces i
uspostavi TCP konekciju izmeu klijentskog i serverskog procesa. Konano, da biste upotrebili
napravljenu aplikaciju, upisaete jednu reenicu pra-enu znakom za povratak na poetak reda.
Programiranje sopstvenih klijentsko-serverskih aplikacija moete da zaponete malim
izmenama ovog programa. Primera radi, umesto pretvaranja teksta u velika slova, server bi
mogao da prebroji koliko se puta u tekstu pojavljuje slovo ,,s" i da vam vrati samo taj broj.
2. 8 Programiranje soketa za protokol UDP
U prethodnom odeljku rekli smo da komunikacija dva procesa preko protokola TCP iz
perspektive tih procesa izgleda kao da izmeu njih postoji vod koji je tu sve dok ga jedan od
njih ne zatvori. Kada jedan od procesa eli da poalje neke informacije drugom, on jednostavno
puta svoje bajtove u ovaj vod. Predajni proces ne mora uz bajtove da prilae i odredinu
adresu, budui daje vod logiki povezan sa odreditem. tavie, ovaj vod obezbeduje kanal za
pouzdani tok podataka - redosled primljenih bajtova u prijemnom procesu identian je sa
redosledom bajtova koje je poiljalac stavio u vod.
Protokol UDP takoe omoguava komunikaciju dva (ili vie) procesa koji se izvravaju na
razliitim raunarima. Meutim, protokol UDP se po mnogo emu sutinski razlikuje od
protokola TC.P. Najpre, protokol UDP je usluga bez konekcije - ovde ne postoji inicijalna faza
sinhronizacije tokom koje se izmeu dva procesa uspostavlja vod za podatke. S obzirom na to
da kod protokola UDP ne postoji nikakav vod, predajni proces uz svaki paket podataka mora da
prilae odredinu adresu. I to mora da se uini za svaku grupu bajtova koju predajni proces
poalje. Kao analogiju, zamislite grupu od 20 ljudi koja u pet taksi vozila treba da doe do zaje-
dnikog odredita. Kada ovi ljudi uu u taksije, svakog vozaa pojedinano treba da obaveste u
kom pravcu da vozi. Dakle, moglo bi se rei da protokol UDP ima slinosti sa taksijem.
Odredina adresa predstavlja zapis koga ine IP adresa odredinog raunara i broj porta
odredinog procesa. U nastavku teksta celinu koju ine paket sa informacijama, odredina IP
adresa j broj porta nazivaemo samo paket". Protokol UDP obezbeduje nepouzdani model
usluge orijentisan na poruke u tom smislu to preduzima sve to moe u cilju isporuke paketa
bajtova na odredite, ali u tom pogledu ne prua nikakve garancije. Usluga UDP se bitno
razlikuje od pouzdanog modela usluge sa tokovima bajtova protokola TCP.
Nakon to napravi paket, predajni proces ga, putem svog soketa, ubacuje u mreu.
Nadovezujui se na analogiju sa taksijem, mogli bismo da kaemo da se na drugoj strani soketa
nalazi taksi koji eka na paket. Meutim, ovaj taksi ne moe da garantuje da e paket zaista
stii do svog odredita; taksi bi mogao da se pokvari ili bi mogao da mu se dogodi neki
neoekivani problem. Drugim recima,protokol UDP svojim komuniciraj uim procesima
obezbeduje nepouzdanu transportnu uslugu - on ne prua nikakve garancije da e datagram
stii do svoje odredine adrese.
U ovom odeljku ilustrovaemo vam programiranje soketa tako to emo da preradimo
aplikaciju iz prethodnog odeljka i daje prilagodimo protokolu UDP. Videete da je Java kod za
protokol UDP bitno drugaiji od koda za protokol TCP. Konkretno, videete da ovde (1) nema
inicijalne sinhronizacije izmeu procesa, pa samim tim ni potrebe za postojanjem soketa za
dobrodolicu, zatim da (2) nema tokova koji se povezuju sa soketima, da (3) predajni raunar
pravi pakete tako to svakoj skupini podataka prilae odredinu IP adresu i broj porta i da (4)
prijemni proces mora da otvori svaki paket kako bi iz njega izvukao bajtove sa informacijama.
Jo jednom vas podseamo na nau jednostavnu aplikaciju:
1. Klijent ita red teksta iz standardnog ulaza.
2. Server ita red teksta iz svog soketa.
3. Server prebacuje ovaj tekst u sva velika slova.
4. Server, kroz svoj soket, alje izmenjeni tekst klijentu.
5. Klijent ita izmenjeni tekst kroz svoj soket i prikazuje ga na standardnom izlazu
(monitoru).

2.8 . PROGRAMIRANJE SOKETA ZA PROTOKOL UDP 159 159 159 159

Na slici 2.30 istaknute su osnovne aktivnosti vezane za sokete u situaciji kada klijent i server
komuniciraju putem transportne usluge bez konekcije (UDP).

UDPCHent.java
Evo kako izgleda kod klijentske strane aplikacije;
import java.io.*; import
java.net.*; class UDPClient {
public static void main'(String args[J) throws Exception
1 11 1
BufferedReader inFromUser =
new BufferedReader(new InputStreamReader (System.in) ) ;
DatagramSocket clientSocket = new DatagramSocket() ; InetAddress IPAddress
InetAddress.getByName("hostname") ; byte[] sendData =
new byte[1024]; byte{] receiveData = new byte[1024]; String sentence =
inFromUser.readLine(); sendData = sentence.getBytes(} ; DatagramPacket
sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket) ; DatagramPacket receivePacket =
new DatagramPacket(receiveData, . receiveData.length);
clientSocket.receive(receivePacket); String modifiedSentence
=
new String(receivePacket.getData());
System.out.println("FROM SERVER:" +
modifiedSentence) ;
clientSocket.close() ;
)
1 11 1
Kao to moete da vidite na slici 2.31, program UDPClient .java pravi jedan tok i jedan soket. Naziv
soketa je clientSocket i on pripada tipu DatagramSocket. Skreemo vam panju na to da protokol UDP
na klijentskoj strani koristi razliitu vrstu soketa od protokola TCP. Konkretno, u UDP verziji klijent
koristi soket DatagramSocket, dok je u TCP verziji to bio soket Socket. Tok inFromUser je ulazni tok
programa; povezan je sa
standardnim ulazom, odnosno sa tastaturom. Podseamo vas da smo u TCP verziji programa
imali ekvivalentan tok. Sve to korisnik upie pomou tastature ulazi u tok inFromUser. Ali, za
razliku od protokola TCP, ovde nema tokova (ni ulaznih ni izlaznih) koji su povezani sa
soketom. Umesto da bajtove sa informacijama alje u tok koji bi bio povezan sa objektom
Socket, protokol UDP sve pojedinane pakete aije kroz objekat DatagramSocket.
Obratimo sada panju na one redove koda koji se bitnije razlikuju od programa
TCPClient. java.

DatagramSocket- clientSocket = new -DatagramSocket ();
Ovim redom koda pravi se objekat clientSocket tipa DatagramSocket. Nasuprot programu
TCPClient. java, ovaj red ne inicira TCP konekciju. Konkretno, nakon izvrenja ovog reda
programa klijentski raunar ne kontaktira sa serverom,

160 160 160 160 POGLAVLJE 2 APLIKATIVNI SLOJ 2,8 PROGRAMIRANJE SOKETA ZA PROTOKOL UDP 161! 161! 161! 161!

Iz tog razloga konstruktor DatagramSocket ( ) ne uzima ime servera i broj porta kao svoje
argumente. Ukoliko se, za trenutak, vratimo analogiji sa vratima i vodom, mogli bismo da
kaemo da se izvravanjem ovog reda stvaraju vrata za klijentski proces, ali ne i vod izmeu
klijentskog i serverskog procesa,
InetAddress IPAddress = InetAddress. . getBvName("hostname") ;
Da bi slanje bajtova sa informacijama odredinom procesu bilo mogue, potrebna nam je
njegova adresa. Deo ove adrese predstavlja IP adresa odredinog raunara. Prethodnim redom
programa aktivira se pretraivanje DNS baze podataka u kome se ime raunara (u ovom sluaju
naveo gaje sam programer) prevodi u odgovarajuu IP adresu. I kod TCP verzije klijentskog
programa postojalo je pozivanje usluge DNS, s tom razlikom to je to tada uinjeno implicitno
a ne eksplicitno. (Metod
getBvName {) kao svoj argument uzima ime raunara-servera, a vraa njegovu IP adresu i,
zatim, tu adresu smeta u objekat IP Address tipa InetAddress.
byte[] sendData = new byte[1024]; byte[] receiveData =
new byte[1024];
Nizovi bajtova sendData i receiveData uvaju podatke koje klijent poalje i primi.

sendData = sentence . getBytes ( ) ,-
Ovaj red koda, u osnovi, .izvrava konverziju tipa. On uzima reenicu u vidu stringa i menja joj
ime u sendData, tj. u objekat koji predstavlja niz bajtova.
DatagramPacket sendPacket = new DatagramPacket( sendData, sendData.length,
IPAddress, 9876);
Ovim redom koda pravi se paket sendPacket koji klijentski raunar ubacuje u mreu putem
svog soketa. U paketu se nalaze sami podaci, zatim njihova duina, IP adresa servera i broj
porta aplikacije (u ovom sluaju,. 9876). Skreemo vam panju na to da objekat sendPacket
pripada tipu DatagramPacket.

clientSocket.send(sendPacket) ;
U ovom redu metod send {) objekta clientSocket uzima upravo konstruisani paket i ubacuje ga
u mreu putem soketa clientSocket. I na ovom mestu vam skreemo panju na to da protokol
UDP alje ovaj red teksta na drugaiji nain od protokola TCP. Protokol TCP jednostavno
ubacuje string znakova u tok koji ima direktnu logiku konekciju sa serverom. Nasuprot tome,
protokol UDP pravi paket u kome je navedena adresa servera. Nakon to poalje svoj paket,
klijent eka na prijem paketa od servera.

DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData-length);
ekajui na prijem paketa od servera, klijent, ovim redom, rezervie mesto za paket i to je
objekat receivePacket tipa DatagramPacket.
clientSocket.receive(receivePacket);
Sve do prijema paketa, klijent se nalazi u stanju mirovanja; pristigli paket klijent smeta u
objekat receivePacket.

162 162 162 162 POGLAVLJE 2 APLIKATIVNI SLOJ 2.8 PROGRAMIRANJE SOKETA ZA PROTOKOL UDP 163 163 163 163

String modifiedSentence =
new String(receivePacket.getData{ ) ) ;
Ovaj red programa izvlai podatke iz objekta receivePacket i izvrava konverziju
tipa, pretvarajui niz bajtova u string modif iedSentence.
System. out.println("FROM SERVER: " + modifiedSentence) ;
Ovaj red, koji postoji i u programu TCPClient ispisuje string modif iedSentence na
klijentovom monitoru.
clientSocket.close( ) ;
Poslednjim redom koda soket se zatvara. Budui da kod UDP veza nema konekcije,
klijent serveru nakon ovog reda ne alje poruku transportnog sloja (nasuprot pro-
gramu TCPClient).

UDPServer.java
Pogledajmo sada kako izgleda serverska strana ove aplikacije.
import java.io.*; import
java.net. * ; class UDPServer
{
public static void main(String a r g s U) throws Exception {
DatagramSocket serverSocket ~ new
DatagramSocket( 9 8 7 6 ) ; byte[ ]
receiveData = new b y t e [ 1 0 2 4 ] ; byte[ ] sendData = new
b y t e [ 1 0 2 4 ] ; while(true) {
DatagramPacket receivePacket =
new DatagramPacket(receiveData,
receiveData.l e n g t h ) ;
serverSocket.receive(receivePacket); String sentence =
new String(
receivePacket.getData{ ) ) ;
InetAddress IPAddress =
receivePacket.getAddress( ) ; int port =
receivePacket.getPort( ) ; String capitalizedSentence =
sentence.toUpperCase( ) ;
sendData = capitalizedSentence.getBytes( ) ; DatagramPacket
sendPacket = new DatagramPacket(sendData,
sendData.length, IPAddress, p o r t ) ;
serverSocket.send(sendPacket);
}
}
}
Kao to moete da vidite na slici 2.32, program UDPServer . java kreira jedan soket
ije je ime serverSocket i pripada tipu DatagramSocket (takav soket postoji i na
klijentskoj strani aplikacije). Ni u ovom sluaju sa soketom se ne povezuju nikakvi
tokovi.
Obratimo sada panju na one redove koda koje se razlikuju od programa
TCPServer. java.
DatagramSocket serverSocket = new DatagramSocket( 9 8 7 6 ) ;
Ovaj red koda kreira soket serverSocket tipa DatagramSocket na portu 9876. Svi
poslati i primljeni podaci prolaze kroz ovaj soket. S obzirom na to da kod protokola
UDP nema konekcije, ovde ne moramo da pravimo nov soket i osluku-

2.9 . PRAVLJENJE JEDNOSTAVNOG VEB SERVERA 16$ 16$ 16$ 16$
jemo zahteve za konekcijom kao Stoje to bio sluaj kod programa TCPServer . java. Ukoliko
ovoj aplikaciji pristupi vei broj klijenata, svi oni svoje pakete alju kroz ova vrata -
ServerSocket.
String sentence = new String(receivePacket.getData()) ; InetAddress IPAddress =
receivePacket.getAddress() ; int port = receivePacket.getPort();
Ova tri reda programa slue za raspakivanje klijentovog paketa. Prvi red izvlai podatke iz
paketa i smeta ih u objekat Stringsentence; veoma slian red postoji i u programu UDPClient.
Drugi red izvlai IP adresu, a trei klijentov broj porta koji je izabrao sam klijent i koji se
razlikuje od serverovog porta broj 9876. (0 klijentskim brojevima portova detaljnije emo
govoriti u sledeem poglavlju.) Server mora da doe do klijentove adrese (IP adrese i broja
porta) kako bi mogao da mu vrati reenicu koja je prebaena u velika slova.
Ovim ujedno i zavravamo nau analizu programskog para aplikacije za protokol UDP.
Aplikaciju moete da proverite tako to ete program UDPC1 ient. j ava instalirati i
kompajlirati najednom raunaru, a program UDPServer . j ava na drugom, (Kod programa
UDPClient. java obavezno treba da navedete ime servera.) Nakon toga pokrenite oba ova
programa. Za razliku od TCP verzije programa, ovde moete prvo da pokrenete klijentsku
stranu aplikacije zato to ona, kada je pokrenete, nee pokuavati da uspostavi konekciju sa
serverom. Kada pokrenete i klijentski i serverski program, upisivanjem jednog reda teksta na
klijentskom raunan^ isprobajte ovu aplikaciju.

2. 9 Pravljenje jednostavnog veb servera
Sada kada ve prilino detaljno poznajete protokol HTTP, a znate i kako se programiraju
jednostavne klijentsko-serverske aplikacije u Javi, iskoristiemo ova vaa znanja i njihovim
kombinovanjem napraviti jednostavan veb server. Videete da je to u stvari veoma jednostavno.

2.9.1 Funkcije veb servera
U ovom sluaju cilj nam je da napravimo server koji moe da uini sledee:
rukuje samo jednim HTTP zahtevom;
prihvata i parsira HTTP zahtev;
uzima traenu datoteku iz svog sistema datoteka;
pravi HTTP poruku sa odgovorom koju ine zaglavlje i traena datoteka;
alje svoj odgovor direktno klijentu.
Potrudili smo se da kod koji sledi bude to jednostavniji, kako vam ne bi smetao ]
da se koncentriete na aspekte umreavanja. Naravno, on, zbog toga, nije savreno
stabilan. Primera radi, ovde se uopte nismo pozabavili rukovanjem izuzecima, a i
pretpostaviemo i to da se datoteka koju klijent trai zaista nalazi u serverovom i
sistemu datoteka. ]
j
Vv'ebServer.java j
Evo kako izgleda kod jednostavnog veb servera. j
import java.io,*; import
java.net.*;
import java.util.*;
1
class MebServer ( i
public static void main(String argv[]) throws Exception {<
String requestMessageLine;
String fileName;
ServerSocket listenSocket = new ServerSocket(6789); l
Socket connectionSocket = listenSocket.accept{); l
BufferedReader inFromClient = i
connectionSocket.getlnputstream{)));
DataOutputStream outToClient =
new DataOutputStream(
connectionSocket.getOutputStream()); . i
requestMessageLine = inFromClient.readLine();
StringTokenizer tokenizedLine =
new StringTokenizer(requestMessageLine); if
(tokenizedLine.nextToken().equals("GET")){
fileName - tokenizedLine.nextToken();
if (fileName.startsWith<"/") == true ) j
fileName ~ fileName.substring(1);
File file = new File(fileName); j
int numOfBytes = (int) file.length() ; j
FilelnputStream inFile = new FilelnputStream ( !
fileName);
byte[] fileInBytes = new byte[numOfBytes]; \
inFile.read(fileInBytes) ; '
outToClient.writeBytes(
"HTTP/1.0 200 Document Follows\r\n");
i f (fileName.endsWith(".jpg")) \
outToClient.writeBytes("Content-Type:
image/jpeg\r\n") ;
if (fileName.endsWithC.gif"))

2,9 . PRAVLJENJE JEDNOSTAVNOG VEB SERVERA 95 95 95 95

outToClient.writeBytes{"Content-Type: image/gif\r\n");
outToClient.writeBytes("Content-Length: " +
numOBytes + "\r\n") ; outToClient.writeBytes("\r\n") ;
outToClient.write(file!nBytes, 0, numOfBytes); connectionSocket.close{); }
else System.out.println("Bad Request Message"); }
}

Pogledajmo sada izbliza ovaj kod. Kao to verovatno i sami primeujete, njegova prva
polovina gotovo je identina sa programom TCPServer. j ava. Kao i u programu TCPServer
.java, ovde smo takoe uveli pakete java . io i java . net. Pored ova dva paketa uveli smo i paket
java .util koji sadri klasu StringTo-kenizer, koja se koristi za parsiranje HTTP poruka sa
zahtevima, U redovima u okviru klase WebServer defmisali smo dva string objekta.
String requestMessageLine; S-ring fileName;
Objekat requestMessageLine jeste string u kome e se nalaziti prvi red HTTP poruke sa
zahtevom. Objekat f ileName je takoe string u kome e se nalaziti ime traene datoteke.
Sledei skup komandi identian je sa odgovarajuim delom programa TCPServer. j ava,
ServerSocket listenSocket = new ServerSocket(678S); Socket connectionSocket =
listenSocket.accept(); BufferedReader inFromClient =
new BufferedReader(new InputStreamReader
(connectionSocket.getInputStream()}); DataOutputStream
outToClient =
nevi DataOutputStream (connectionSocket getOutputStream{));
Ovim delom programa napravljena su dva objekta iz kategorije soketa. Prvi ovakav objekat je
listenSocket koji pripada tipu ServerSocket. Serverski program pravi objekat listenSocket pre
nego to od klijenta dobije zahtev za TCP konekcijom. Ovaj objekat oslukuje port 6789 i na
zahtev nekog klijenta uspostavlja TCP konekciju. Kada zahtev za uspostavljanjem konekcije
stigne, metod accept () objekta listenSocket pravi novi objekat, connectionSocket,
tipa Socket, Zatim se prave dva toka - Buf f eredReader inFromClient i DataOutputStream
outToClient. HTTP poruka sa zahtevom klijenta stie iz mree i, kroz soket connectionSocket,
dolazi do toka inFromClient; HTTP poruka sa odgovorom servera ide u tok outToClient i
potom kroz soket connectionSocket izlazi u mreu. Ostatak ovog koda se, meutim, bitno razli-
kuje od programa TCPServer. java.

requestMessageLine = inFromClient.readLine();
Ova komanda ita prvi red HTTP poruke sa zahtevom koja bi trebalo da bude u obliku:

GET file_name HTTP/1.0

Nakon toga, na server treba da izvue ime datoteke parsiranjem reda.
StringTokenizer tokenizedLine =
new StringTokenizer(requestMessageLine); if
(tokenizedLine.nextToken(}.equals("GET")){ ' fileName =
tokenizedLine.nextToken(); if (fileName.startsWith("/") == true ) fileName =
fileName.substring(1);
Ove komande parsiraju prvi red poruke sa zahtevom i iz njega vade ime traene datoteke.
Objekat tokenizedLine moete da zamislite kao originalan'red sa zahtevom u kome su rei"
GET, f ile_name i HTTP/1. 0 smetene u odvojeni prostor, koji se zove token. Server zna, na
osnovu RFC-a za protokol HTTP, da se ime traene datoteke nalazi u tokenu koji se nalazi iza
tokena "GET", Ovo ime datoteke se potom stavlja u string po imenu fileName. U prethodnom
segmentu koda, poslednji iskaz if slui za uklanjanje kose crte koja bi mogla da prethodi imenu
datoteke.

FilelnputStream inFile = new FilelnputStream (fileName);
Ova komanda povezuje tok inFile sa stringom fileName.
byte[] fileInBytes = new byte[numOfBytes]; inFile.read(fileInBytes);
Ove komande slue za odreivanje veliine datoteke i konstruisanje niza bajtova te veliine,
Ime ovog niza je f ileInBytes. Poslednja komanda ovog segmenta ita iz niza inFile i zapisuje u
niz f ilelnBvtes. Program mora da izvri ovu

2.10 REZIME 169 169 169 169
.-1-,

konverziju u bajtove zato to izlazni tok outToClient moe da se puni iskljuivo bajtovima.
Sada smo potpuno spremni za sastavljanje HTTP poruke sa odgovorom. Ali, pre toga, moramo
da poaljemo zaglavlje HTTP poruke sa odgovorom u tok DataOutputStream outToClient.
outToClient.writeBytes("HTTP/1.0 200 Document
Follows\r\n"); if
(fileName.endsWithC.jpg") )
outToClient.writeBytes("Content-Type: image/jpeg\r\n"); if
{fileName.endswith(".gif"))
outToClient.writeBytes("Content-Type: _ image/gif\r\n"};
outToClient.writeBytes("Content-Length: " + numOfBytes + "\r\n");
outToClient.writeBytes ("\r\n");
Ovaj skup komandi je posebno zanimljiv. Inae, ove komande slue za pripremu zaglavlja
HTTP poruke sa odgovorom i njihovo slanje u izlaznu privremenu memoriju protokola TCP.
Prva komanda alje obavezni statusni red: HTT P /1. 0 2 00 Document FOIIOVJS, koju prate
znak za povratak na poetak reda i znak za prelazak u novi red. Sledea dva reda pripremaju
zaglavlje. Ukoliko bi slao sliku u GIF formatu, server bi tada pripremio zaglavlje tipa Content
Type : image/ gif. Kada bi to bila slika u JPEG formatu, zaglavlje bi glasilo Content Type :
image / j peg. (Kod ovog naeg jednostavnog veb servera ne postoji red za tip sadraja zato to
objekat nije ni GIF ni JPEG slika.) Server zatim priprema i alje red zaglavlja koji se odnosi na
duinu sadraja, kao i obavezan prazan red koji prethodi samom objektu koji se alje. U ovom
trenutku datoteka FileName alje se u tok DataOutputStream outToClient.
outToClient.write(fileInBytes, 0, numOfBytes);
Ova komanda alje traenu datoteku f ileInBytes u predajnu memoriju protokola TCP koji e,
zatim, daje pridrui upravo napravljenom zaglavlju, segmentira (ukoliko je potrebno) i poalje
TCP segmente klijentu. Nakon usluivanja klijentovog zahteva slanjem datoteke, server zatvara
soket connectionSocket,
connectionSocket.close();
Da biste testirali ovaj vebserverski program, instalirajte ga najednom raunaru, a zatim na taj
raunar snimite i nekoliko datoteka. Nakon toga, sa nekog drugog raunara itaem zatraite
neku od ovih datoteka. Prilikom traenja datoteke moraete
da koristite onaj broj porta koji ste naveli u serverskom programu (na primer, 6789). Dakle,
ako pretpostavimo da se va server nalazi na raunaru somehost. some-where . edu, daje u
pitanju datoteka somef ile. html i daje naveden port broj 6789, zahtev vaeg itaa treba da
izgleda ovako:

http://somehost.somewhere.edu:6789/somefile.html
2. 10 Rezime
U ovom poglavlju govorili smo o konceptualnim i implementacionim aspektima mrenih
aplikacija. Upoznali ste se sa sveprisutnom klijentsko-serverskom paradigmom Internet
aplikacija, a zatim ste videli i na koji nain ovu paradigmu koriste protokoli HTTP, FTP,
SMTP, POP3 i DNS. Govorei o ovim veoma vanim protokolima aplikacijsknog sloja,
detaljno smo vam predstavili aplikacije sa kojima su oni povezani (Web, transfer datoteka,
elektronska pota i sistem imena domena). Nastavili smo pregledom savremenih tehnika za
distribuciju sadraja u mrei u koje spadaju proksi serveri za veb keiranje, mree sa
distribucijom sadraja i P2P razmena datoteka. Zatim ste videli na koji nain soket API moe
da se iskoristi za pravljenje mrenih aplikacija. Detaljno smo proli kroz proces korienja
soketa u transportnim uslugama sa konekcijom (TCP), kao i u onim transportnim uslugama bez
konekcije (UDP), da bismo zatim, korienjem soketa, napravili jednostavan veb server. Na
prvi korak u putovanju od vrha slojevite mrene arhitekture ka njenom dnu ovim je zavren.
Na samom poetku knjige, u odeljku 1.1 ponudili smo relativno nepreciznu i
pojednostavljenu definiciju protokola rekavi da on odreuje format i redosled poruka koje
razmenjuju dva ili vie komunicirajuih entiteta, kao i akcije koje oni preduzimaju nakon
prijema ovih poruka". Ono to smo u ovom poglavlju rekli o protokolima HTTP, FTP, SMTP,
POP3 i DNS, dodalo je znaajnu teinu ovoj definiciji. Protokoli predstavljaju kljune aspekte
umreavanja; prikaz protokola aplikacijskog sloja e vam zasigurno pomoi da razvijete neto
intuitivniji oseaj za najznaajnije aspekte samih protokola.
U odeljku 2.1 opisali smo modele usluga koje protokoli TCP i UDP nude aplikacijama
koje ih pozovu. Razvijajui jednostavne aplikacije za protokole TCP i UDP (odeljci 2.7 - 2.9)
videli smo kako ti modeli usluga uzgledaju izbliza. Ipak, rekli smo veoma malo o tome kako
ovi protokoli obezbeuju pomenute modele usluga. Primera radi, gotovo da nita nismo rekli o
nainu na koji protokol TCP obezbeduje pouzdani transport svojim aplikacijama, U sledeem
poglavlju emo zato obratiti panju ne samo na pitanje ta, ve i na aspekte kako i zato kod
transportnih protokola. Naoruani znanjima o strukturi Internet aplikacija i protokolima
aplikacijskog sloja, spremni ste za nastavak naeg puta nanie kroz familiju protokola i
ispitivanje transportnog sloja, o kome emo govoriti u poglavlju 3.

PROBLEMI 171 171 171 171

Domai zadatak; problemi i pitanja
Poglavlje 2 Kontrolna pitanja

ODEUAK 2.1
1. Navedite pet nevlasnikih Internet aplikacija, kao i protokole aplikacijskog sloja koje one
koriste.
2. V emu je razlika izmeu arhitekture mree i arhitekture aplikacije?
3. U kom smislu instantna razmena poruka predstavlja hibridnu varijantu
klijent-sko-serverske i P2P arhitekture?
4. U komunikacionoj sesiji izmeu dva raunara, ko je klijent, a ko server?
5. Da li se slaete sa siedeom izjavom: ,,U komunikacionim sesijama aplikacija za P2P
razmenu datoteka ne postoje pojmovi klijenta i servera". Obrazloite svoj odgovor,
6. Pomou kojih informacija proces koji se izvrava najednom raunaru prepoznaje proces
koji se izvrava na drugom raunaru?
7. Navedite nekoliko korisnikih agenata aplikacijskog sloja koje svakodnevno koristite.
8. Vraajui se za trenutak na sliku 2.4 moemo da zakljuimo da nijedna od navedenih
aplikacija nije istovremeno osetljiva i na gubljenje podataka i na vreme. Moete li da
zamislite aplikaciju koja bi zahtevala nepostojanje gubljenja podataka uz istovremenu
vremensku osetljivost?
ODEUC12.2-2.6
9. ta se podrazumeva pod protokolom za sinhronizaciju?
10. Zbog ega se u podlozi protokola HTTP, FTP, SMTP, POP3 i IMAP nalazi protokol TCP
a ne protokol UDP?
11. Zamislite veb lokaciju za elektronsku trgovinu koja eli da uva podatke o svakom svom
korisniku. Opiite kako je to mogue uiniti pomou kolaia,
12. U emu je razlika izmeu postojanih HTTP veza sa cevovodnom obradom i postojanih
HTTP veza bez cevovodne obrade? Koju varijantu koristi verzija HTTP/I.l?
13. Objasnite na koji nain veb keiranje moe da skrati vreme potrebno za prijem traenog
objekta. Da li ono skrauje kanjenje svih zatraenih objekata ili samo nekih od njih?
Obrazloite svoj odgovor.
14. Uspostavite Telnet sesiju sa veb serverom i poaljite vieredni zahtev. U zahtev ubacite
zaglavlje If-moclif ied~since : kako biste u odgovoru dobili statusnu poruku 304 Not
Modified.
16. Zbog ega se kae da protokol FTP alje kontrolne informacije izvan opsega"?
17. Pretpostavimo da Alisa sa svog naloga za elektronsku potu koji je otvoren na Webu
(recimo, Hotmail) eli da poalje poruku Bobu koji svom serveru za elektronsku potu
pristupa protokolom POP3. Opiite put ove poruke od Ali-sinog do Bobovog raunara.
Obavezno navedite seriju protokola aplikacijskog sloja koji se koriste za prenos poruke sa
jednog na drugi raunar.
18. Odtampajte zaglavlje neke poruke koju ste nedavno primili. Koliko zaglavlja tipa
Received: ima u njoj? Analizirajte svako zaglavlje poruke.
19. U emu je, gledano iz perspektive korisnika, razlika izmeu reima preuzmi i brii" i
reima preuzmi i zadri" protokola POP3?
20. Da li je^mogue da veb server i server za .elektronsku potu neke organizacije imaju
identini pseudonim kao svoje ime (recimo, foo. com)? Kog tipa bi bio RR zapis koji bi
sadrao ime servera za elektronsku potu?
21. ta u sistemu za P2P razmenu datoteka predstavlja preklopljena mrea? Da li u njoj
postoje ruteri? ta su njene grane? Na koji nain se formira i odrava Gnu-tellina
preklopljena mrea?
22. Pronaite tri kompanije koje se bave P2P razmenom datoteka. Koju vrstu sadraja one
distribuiraju? Na koji nain svaki od njihovih dizajna omoguava korisnicima da lociraju
odreeni sadraj?
ODEUCI 2.7-2.9
22. UDP serveru koji je opisan u odeljku 2.S bio je potreban samo jedan soket, dok su TCP
serveru iz odeljka 2.7 bila potrebna dva. Zato? Kada bi TCP server morao da podri n
istovremenih veza, koliko bi mu soketa bilo potrebno?
23. Zbog ega u klijentsko-serverskoj aplikaciji koja koristi protokol TCP iz odeljka 2.7
serverski program mora da se pokrene pre klijentskog? Zbog ega u klijentsko-serverskoj
aplikaciji za protokol UDP (odeljak 2.8) klijentski program moe da se pokrene pre
serverskog?
Problemi _________________________________
1, Tani ili netano?
a) Pretpostavimo da je neki korisnik zatraio veb stranu koja se sastoji od tekstualnog
dela i dve slike. Za ovu stranu klijent alje jednu poruku a prima tri.
b) Istom postojanom vezom mogu da se poalju ve razliite veb strane (na primer,
www. mit. edu/research. htmL i www .mit .edu/stu-dents. html).
c) Kada se izmeu itaa i servera porekla uspostavi nepostojana konekcija, jedan TCP
segment moe da prenese dve razliite HTTP poruke sa zahtevima.

PROBLEMI 173 173 173 173

d) Zaglavlje Date: u HTTP odgovoru pokazuje kada je objekat koji se nalazi u odgovoru
poslednji put izmenjen.
2. Proitajte RFC dokument 959 koji se odnosi na protokol FTP, a zatim navedite sve
klijentske komande koje su podrane ovim dokumentom.
3. Posetite veb stranu http: //www. iana. org, a zatim navedite dobro poznate brojeve portova
za protokole SFTP (Simple File Transfer Protocol) i NNTP (NetworkNews Transfer
Protocol).
4. Zamislite HTTP klijenta koji putem odreenog URL-a treba da primi dokument sa Weba.
IP adresa HTTP servera je inicijalno nepoznata. Veb dokument na datom URL-u ima
jednu ugraenu sliku u GIF formatu koja se nalazi na istom serveru na kome je i originalni
dokument. Koji su protokoli transportnog i aplikacijskog sloja (osim protokola HTTP)
potrebni u ovom scenariju?
5. Pronaite specifikaciju HTTP/1.1 (RPC 2616) i zatim odgovorite na sledea pitanja:

a) Objasnite mehanizme za signaliziranje kojima se klijent i server obave-tavaju da je
trajna konekcija zatvorena. Da li klijent moe da signalizira zatvaranje veze? Moe li
to da uini server i mogu li i jedan i drugi to da uine?
b) Koje usluge za ifrovanje obezbeduje protokol HTTP?
6. Pretpostavimo da ste u svom itau izborom hiperveze otvorili neku veb
stranu ija IP adresa nije keirana u vaem lokalnom raunaru tako daje za
njeno pribavljanje neophodno pretraivanje DNS baze podataka. Takoe emo
pretpostaviti i to da je dobijanju IP adrese prethodila poseta DNS servera;
za sukcesivne posete potrebno je RTT vreme, od RTTp RTTn. Zatim, ova veb strana je
povezana sa linkom koji se odnosi na samo jedan objekat - malo HTML teksta, Sa RTT0
oznaiemo RTT vreme izmeu lokalnog raunara i servera na kome se ovaj objekat
nalazi. Ukoliko zanemarimo trajanje prenosa objekta, koliko vremena protekne od
trenutka kada korisnik izabere hipervezu do trenutka kada klijent primi traeni objekat?
7. Vraajui se na problem 6, pretpostaviemo da HTML datoteka referencira
tri veoma mala objekta na istom serveru. Ako zanemarimo trajanje prenosa,
koliko je vremena potrebno kod:
a) nepostojanih HTTP veza bez para/efnih TCP konekcija,
b) nepostojanih HTTP veza sa paralelnim TCP konekcijama i
c) postojanih HTTP veza sa cevovodnom obradom?

8. Dva HTTP metoda za traenje objekata su GET i POST. Da li u verziji HTTP/ 1.0
postoje jo neki metodi? Ukoliko postoje, za ta se koriste? Da li postoje u verziji
HTTP/1.1?
9. Vratimo se sada na sliku 2.11 na kojoj je nacrtana mrea jedne institucije koja je
povezana sa Internetom. Pretpostavimo da je prosena veliina objekta
900 000 bitova i da prosena uestalost zahteva koje itai ove institucije alju
serverima porekla iznosi 1,5 zahteva u sekundi. Takoe emo pretpostaviti da od
trenutka kada ruter na strani pristupnog linka ka Internetu prosledi HTTP zahtev pa do
trenutka kada primi odgovor, proseno proteknu dve sekunde (odeljak 2.2,6). Modelujte
ukupno proseno trajanje odziva kao sumu prosenog kanjenja kod pristupa (kanjenje
od rutera na rntemetu do rutera institucije) i prosenog kanjenja na Internetu. Prilikom
izraunavanja prosenog kanjenja pristupa koristite formulu A/(l - A/?), gde A
predstavlja proseno trajanje slanja objekta pristupnim linkom, a /? brzinu pristizanja
objekata u pristupnom linku.
a) Odredite ukupno proseno vreme odziva.
b) Pretpostavimo, za trenutak, daje ke instaliran u LAN-u institucije i daje indeks
pronaenih objekata 0,4. Odredite sada ukupno trajanje odziva.

10. Napiite jednostavan TCP program za server koji treba da prihvati nekoliko redova teksta
koji je upisan na klijentskom raunaru i izbacuje ih na svom standardnom izlazu. (Ovo
moete da uradite i menjanjem programa TCPServer. j ava koji smo naveli u tekstu,)
Kompajlirajte i pokrenite svoj program. Zatim na bilo kom drugom raunaru koji ima
ita Weba podesite opciju za proksi server itaa i usmerite ga na server na kome se
izvrava va program; ne zaboravite i da na odgovarajui nain konfiguriete broj porta,
Va ita bi nakon toga trebalo da poalje svoje poruke tipa GET vaem serveru na ijem
standardnom izlazu bi trebalo da vidite ispisane poruke. Pomou ove platforme usta-
novite da li va ita generie uslovne GET poruke za objekte koji se nalaze u lokalnoj
ke memoriji.
11. Proitajte RFC dokument 1939 koji se odnosi na protokol POP3. Koja je uloga komande
UIDL POP3?
12. Zamislite da treba da proverite svoju elektronsku potu putem protokola POP3. a)
Pretpostavimo da ste svog POP klijenta za elektronsku potu konfigurisali
tako da radi u reimu preuzmi i obrisi". Izvrite sledeu transakciju:
C: list
S : S : S : S : 1 498
. .. . S : S : S : S : 2 912
S: S: S: S: . .. .
C: retr L
S : S : S : S : bla bla . . .
S : S : S : S : ........................ bla
S: .
?

PROBLEMI 175 175 175 175

b) Pretpostavimo da ste svog POP klijenta za elektronsku potu konfigurisali
tako da radi u reimu preuzmi i zadri". Izvrite sledeu transakciju:
C: list S: 1
498 S: 2 912
S: .
C: retr 1
S: bla bla . . .
S: ...................... bla
S: . ?

c) Pretpostavimo da ste svog POP klijenta za elektronsku potu konfiguri-
sali za rad u reimu preuzmi i zadri". Pretpostavimo da ste korienjem
transkripta u delu pod (b) primili poruke 1 i 2, da ste, zatim, izali iz POP
klijenta i da ste nakon pet minuta ponovo proverili svoju potu. Pretposta-
viemo da u tih pet minuta niste dobili nijednu novu poruku. Ispiite tran-
skript ove druge POP sesije.
13. a. Staje whois baza podataka?
b. Pomou raznih whois baza podataka na Internetu pronaite imena dva DNS
servera. Navedite koje ste whois baze podataka koristili.
c. Pomou programa nslookup sa svog lokalnog raunara poaljite DNS upite
ka tri DNS servera - svom lokalnom DNS serveru i DNS serverima koje ste
pronali u delu (b). Pokuajte da ispitate izvetaje tipa A, NS i MX. Rezimi-
rajte rezultate.
d. Programom nslookup pronaite veb server koji ima vie IP adresa. Da li
veb server vae institucije (kole ili kompanije) ima vie IP adresa?
e. Pomou ARIN whois baze podataka odredite opseg IP adresa koji koristi
va univerzitet.
f. Opiite nain na koji napada pomou whois baza podataka i alatke nsloo-
kup moe da prikupi obavetenja o instituciji pre samog napada.
g. Obrazloite opravdanost javne dostupnosti whois baza podataka.
14. Pretpostavimo da pomou neke P2P aplikacije upravo preuzimate odreene
MP3 datoteke. Usko grlo vae veze sa Internetom predstavlja va pristupni
link koji ima brzinu od 128 kb/s u punom dupleksnom reimu. Tokom vaeg
preuzimanja, 10 korisnika poelo je da preuzima MP3 muziku sa vaeg rau-
nara. Ukoliko pretpostavimo daje va raunar dovoljno jak da ga istovremeno
preuzimanje i slanje podataka ne optereuju (procesor, disk, itd), da li e isto-
vremeno slanje podataka koji takoe moraju da prou kroz usko grlovae veze
sa Internetom usporiti vae preuzimanje? Obrazloite svoj odgovor, Sta bi se
dogodilo kada biste kao deo ADSL veze imali nizvodni kanal od 512 kb/s i uzvodni od
128 kb/s?
15. Pretpostavimo da u Gnutella mrei ima aktivnih korisnika i da izmeu svakog para
korisnika postoji aktivna TCP konekcija. Pretpostaviemo i to da TCP konekcije prolaze
kroz ukupno JW rutera. Koliko vorova i grana ima u ovoj preklopljenoj mrei?
16. Govorei o mrei Gnutella u odeljku 2.6 detaljno smo vam opisali na koji nain novi
ravnopravni korisnici ulaze u ovu mreu. U ovom problemu zanima nas ta se dogaa kada
neki ravnopravni korisnik izae iz ove mree. Pretpostavimo da svaki uestvujui vor sve
vreme odrava TCP konekcije sa najmanje etiri druga korisnika, Pretpostaviemo i to da
korisnik Peer X, koji odrava TCP konekcije sa pet drugih korisnika, eli da istupi iz
mree.

a) Najpre razmislite o elegantnom izlasku pri kome Peer A'eksplicitno zatvara svoju
aplikaciju, odnosno prekida svih pet svojih TCP konekcija. ta u tom sluaju
preduzima pet ravnopravnih korisnika sa kojima je on prethodno bio povezan.
b) Sada pretpostavimo da je îznenada prekinuo svoju vezu sa Internetom a da nije
obavestio svojih pet suseda. ta se u ovom sluaju dogaa?
17. U ovom problemu istraiemo rutiranje unazad QueryHit poruka u Gnutellinoj
mrei. Pretpostaviemo daje Alisa izdala komandu Query i daje vie takvih
poruka stiglo do Boba (od nekoliko posredujuih ravnopravnih korisnika) koji
ima datoteku koja odgovara upitu.
a) Podseamo vas da ravnopravni korisnik koji ima traenu datoteku alje svoju QueryHit
poruku obrnutim smerom iste putanje kojom je i dobio Query poruku. Alternativni
dizajn bio bi da Bob sa Alisom uspostavi direktnu TCP konekciju i preko nje poalje
poruku QueryHit. ta su prednosti, a ta nedostaci ovakvog alternativnog dizajna?
b) Kada Alisa poalje poruku Query, protokol Gnutella u njeno polje Messa-gelD ubacuje
jedinstveni ID broj. Ukoliko ravnopravni korisnik Bob ima traenu datoteku, njegov
program generie QueryHit poruku sa identinim poljem MessagelD. Opiite nain na
koji ravnopravni korisnici pomou ovih MessagelD polja i lokalnih tabela rutiranja
izvode rutiranje u obmu-tom smeru.
c) Postoji i alternativni pristup u kome se ne koriste identifikatori poruke. Kada poruka sa
upitom stigne do datog korisnika on joj, pre nego stoje prosledi, dodaje i svoju IP
adresu. Objasnite kako se korienjem ovog mehanizma izvodi rutiranje obrnutim
smerom.
18. Ponovite problem 17, ali na pitanja odgovorite tako da se, umesto na poruke
Query i QueryHit, odnose na Gnutelline poruke Ping i Pong.

A-.
176 176 176 176 POGLAVUE 2 APLIKATIVNI SLOJ TEZE ZA DISKUSIJU 177 177 177 177
19. U ovom problemu ispitaemo dizajn sistema koji podsea na mreu KaZaA u
kome postoje obini vorovi, vode grupe i voe supergrupa.
a) Pretpostavimo daje svaki voa supergrupe odgovoran za otprilike 200 voa grupa od
kojih je svaki, dalje, odgovoran za otprilike 200 obinih lanova, Koliko je voda
supergrupe potrebno za mreu u kojoj bi bilo etiri miliona korisnika?
b) Koje informacije moe da uva svaki voa grupe, a koje svaki voa supergrupe? Na
koji nain se izvodi pretraivanje u ovakvom troslojnom dizajnu.

20. Vratimo se sada na poplavu upita u P2P razmeni datoteka iz odeljka 2,6. Pretpostavimo
daje svaki ravnopravni korisnik preklopljene mree povezan sa A^suseda i da je u polju za
brojanje vorova inicijalno podeena vrednost K. Takoe emo pretpostaviti da Alisa treba
da izvri upit. Odredite gomju granicu broja upita koji se alju u preklopljenu mreu.
21. Instalirajte i kompajlirajte Java programe TCPClient i UDPClient na jednom
raunaru i TCPServer i UDPServer na drugom.

a) Pretpostavimo da ste program TCPClient pokrenuli pre programa TCPServer. ta se
dogaa i zato?
b) Pretpostavimo da ste program UDPClient pokrenuli pre programa UDPServer. ta se
dogaa i zato?
c) ta se dogaa ukoliko na klijentskoj i serverskoj strani upotrebite razliite brojeve
porta?

22. Promenite program TCPServer . j ava tako da moe da prihvati vie veza. (Savet:
Moraete da koristite niti.)
23. Pretpostavimo da u programu UDPClient. java red
DatagramSocket clientSocket = new DatagramSocket( }; zamenimo redom
DatagramSocket clientSocket = new DatagramSocket(5432) ;
Da li emo morati dapromenimo i program UDPServer .java? Koji se brojevi portova
koriste za sokete u programima UDPClient i UDPServer? Kako je bilo pre ove promene?
Teze za diskusiju
1. ta mislite, zbog ega su aplikacije za P2P razmenu datoteka toliko popularne? Da li zato
to se putem njih (prilino ilegalno) distribuira muzika i video materijal ili, moda, zato
to kod njih ogroman broj servera efikasno odgovara na masivnu potranju?
2. Postoji li neki aktivan projekat u smislu pravljenja otvorenog sistema za P2P razmenu
datoteka koji bi primenio heterogenost ravnopravnih korisnika (kao to je sluaj u
vlasnikoj tehnologiji KaZaA)?
3. Proitajte rad The Darknet and tlie Future of Content Distribution" autora Biddle,
England, Peinado i VVillman [Biddle 2003] i nakon toga kaite da li se slaete sa svim
idejama ovih autora. Obrazloite svoj odgovor.
4. Lokacije za elektronsku trgovinu, ali i druge veb lokacije esto imaju pozadinske baze
podataka. Na koji nain HTTP serveri komuniciraju sa ovim bazama podataka?
5. Staje dinamiki HTML? Navedite primere veb lokacija koje koriste dinamiki HTML.
6. Navedite neke popularne serverske skript jezike. Staje svrha serverskihskript jezika?
7. Na koji nain biste svoj ita konfigurisali za lokalno keiranje? Koje opcije vam u tom
smislu stoje na raspolaganju?
8. Da li biste svoj ita mogli da konfiguriete tako da istovremeno otvara vie konekcija sa
odreenom veb lokacijom? Navedite prednosti i nedostatke postojanja veeg broja
istovremenih TCP konekcija.
9. U odeljku 2.4.4 rekli smo da se usluga elektronske pote bazirane na Webu esto
implementira korienjem veb i IMAP servera. Na koji nain HTTP server komunicira sa
IMAP serverom?
10. Videli ste da TCP soketi podatke koji se prenose tretiraju kao niz bajtova, dok UDP soketi
prepoznaju granice izmeu poruka. Koja je prednost a koji nedostatak ovakvog bajtovski
orijentisanog API-ja u odnosu na API koji eksplicitno podrava granice poruka definisanih
od strane aplikacije?
11. Pretpostavimo da imate bazu sa astrolokim podacima koju elite da uinite dostupnom za
itae Weba na personalnim raunarima, WAP telefone i obine telefone (korienjem
konverzije teksta u govor). Na koji nain biste mogli to da uinite?
12. Objasnite odnos izmeu instantne razmene poruka i protokola SIP.
13. Na koji nain funkcioniu liste kontakata servera za instantnu razmenu poruka?
14. ta je Apache veb server, koliko kota i koje funkcije trenutno poseduje?

ZADACI SA PROGRAMIRANJEM SOKETA 179 179 179 179

16. Pretpostavimo da su organizacije za standardizaciju Weba odluile da promene
konvenciju imenovanja tako da se svaki objekat naziva i referencira jedinstvenim
imenom koje je nezavisno od lokacije (tzv. ,,URN"). Izloite neke aspekte koji bi pratili
ovakvu promenu.
17. Analizirajte sistem kojim aplikacija KaZaA podstie korisnike da u to veoj meri
predaju svoje datoteke. Na koji nain bi to jo moglo da se uini?
Zadaci sa programiranjem soketa Zadatak 1:
Vienitni veb server
Kada zavrite ovaj programerski zadatak, imaete vienitni veb server u program-, skom
jeziku Java koji istovremeno moe da opslui vie zahteva. U ovom sluaju implementiraete
verziju 1.0 protokola HTTP, onako kako je on definisan u dokumentu RFC 1945.
Podseamo vas da protokol HTTP/1.0 uspostavlja posebnu TCP konekciju za svaki par
zahtev-odgovor. Svakom od ovih konekcija rukuje posebna nit. U programu postoji i glavna
nit u kojoj server oslukuje klijente koji ele da uspostave konekciju, Da bismo va zadatak
pojednostavili, program emo razviti u dve etape. U prvoj etapi napisaete kod vienitnog
servera koji samo prikazuje sadraj HTTP zahteva koje dobija. Kada ustanovite da ovaj deo
programa ispravno funkcionie, dodactc mu i deo koda koji treba da generie eljeni
odgovor.
Tokom razvijanja koda svoj server uvek moete da proverite pomou itaa Weba.
Skreemo vam panju na to da ete u okviru URL-a koji dajete svom itau morati da
naznaite broj porta zato to, u ovom sluaju, neete ii kroz standardni port 80. Primera radi,
ukoliko pretpostavimo daje ime raunara host. someschool . edu, zatim da va server
oslukuje port 6789 i da elite da preuzmete datoteku index. html, u itau biste morali da
navedete sledei URL:
http://host.someschool.edu:6789/index.html
Kada se suoi sa grekom,"'va server bi trebalo da vam poalje poruku sa odgo-
varajuom HTML datotekom kako bi informacija o greci mogla da se prikae u prozoru
itaa. Sve detalje, u vezi sa ovim zadatkom, kao i vane delove Java koda moete da
pronaete na veb lokaciji http://www.awl.com/kurose-ross.

Zadatak 2: Klijent za elektronsku potu
U ovom zadatku ete, takoe u programskom jeziku Java, razviti korisnikog agenta za
elektronsku potu koji ima sledee karakteristike:
* Obezbeduje grafiki interfejs za poiljaoca sa poljima za adrese poiljaoca i primaoca, temu
poruke i samu poruku.
Uspostavlja direktnu TCP konekciju sa serverom za elektronsku potu, alje i prima SMTP
komande od lokalnog servera za elektronsku potu.
Evo kako va interfejs treba da izgleda:
Korisniki agent koji ete razviti moi e da alje poruku samo jednom primaocu u datom
trenutku u vremenu. Osim toga, va korisniki agent treba da pretpostavi
daje deo adrese primaoca koji se odnosi na domen identian sa imenom SMTP servera koji rukuje
pristiglom potom datog primaoca. (Korisniki agent ne izvrava DNS pretraivanje MX zapisa,
tako da poiljalac mora da obezbedi i ime servera za elektronsku potu.) Kompletne detalje u vezi sa
ovim zadatkom, kao i vane delove Java koda moete da pronaete na veb lokaciji
http://www.awl.com/kurose-ross.

Zadatak 3: Laboratorijsko vebanje UDP Ping
U ovom laboratorijskom vebanju implementiraete jednostavnog Ping klijenta i servera zasnovanog
na protokolu UDP. Po svojim funkcijama ovi programi su veoma slini standardnom programu Ping
koji je deo savremenih operativnih sistema. Standardni Ping alje ICMP (Internet Control Message
Protocol) ECHO poruku koju udaljeni raunar treba da vrati poiljaocu. Poiljalac na osnovu
dobijenih informacija zatim moe da odredi vreme povratnog puta izmeu sebe i raunara kome je
poslao poruku.
U Javi ne postoji funkcionalnost za slanje ili prijem ICMP poruka. Upravo zato ete Ping u
ovom vebanju da implementirate na aplikacijskom sloju sa standardnim UDP soke-tima i
porukama, Kompletne informacije u vezi sa ovim zadatkom, kao i vane segmente Java koda moete
da pronaete na veb lokaciji http.7Avww.awl.com/kurose-ross.

I NTERVJU
102 102 102 102

Zadatak 4: Veb proksi server
U ovom vebanju ete razviti jednostavan veb proksi server koji treba da keira veb strane.
Ovaj server od itaa prihvata GET poruke i prosleuje ih odredinom veb serveru, od koga, s
druge strane, prihvata HTTP odgovore i prosleuje ih itau, Re je o veoma jednostavnom
proksi serveru koji razume samo jednostavne GET zahteve. Ipak, ovaj server treba da rukuje
svim objektima - ne samo HTML stranicama, ve i slikama. Sve detalje o ovom zadatku, kao i
relevantne segmente Java koda moete da pronaete na veb lokaciji
http://www.awl.com/kurose-ross.
Tim Berners Tim Berners Tim Berners Tim Berners- -- -Li Li Li Li

Tim Berners-Li je direktor Konzorijurria VVorld Wide VVeba (W3C) i Glavni
istraiva MIT laboratorije zo raunarske nauke. ' Godine 1989, radei za
Eufopeon Particle'Physics Laboralorv CERN, Tim je pokrenuo hiperrh'edijolnu
inicijativu za globalnu-razmenu informacijo zasnovanu na Internetu ôjo je
mnogo poznatija kao VVorld Wide Web. Godinu dona kasnije napisoo je
program za prvi veb klijent i veb server. Diplomirao, je.fiziku na Oksfordu.
Ethereal laboratorijske vebe
Ethereal veba: HTTP
Budui da ste se u prvom laboratorijskom vebanju upoznali sa programom Ethereal, ovu
alatku sada emo da upotrebimo kako biste videli protokole na delu. U ovom vebanju
ispitaemo nekoliko aspekata protokola HTTP, kao to su:.osnovna interakcija izmeu poruka
GET i odgovora, formati HTTP poruka, prijem velikih HTML datoteka, prijem HTML
datoteka sa ugraenim URL-ovima, postojane i nepostojane veze i provera autentinosti i
bezbednost ovog protokola,
Kao i kod svih drugih Ethereal laboratorijskih vebi, pun opis ove vebe pronai ete
na'veb lokaciji koja prati ovu knjigu - http://www.awl.com/kurose-ross.
Ethereal veba: DNS
U ovom vebanju anaiiziraemo izbliza klijentsku stranu protokola DNS koji imena matinih
raunara na Internetu prevodi u IP adrese. Podseamo vas na odeljak 2.5 u kome smo rekli da
je uloga klijenta u sistemu DNS relativno jednostavna - on alje upit svom lokalnom DNS
serveru i od njega prima odgovor, Ono to se dogaa u okviru hijerarhije DNS servera koji
rekurzivno ili iterativno reavaju dobijeni zahtev, DNS klijent ne moe da vidi. Iz njegove
perspektive ovaj protokol je sasvim jednostavan - lokalnom DNS serveru se alje upit i zatim
se od njega oekuje odgovor. Dakle, u ovom laboratorijskom vebanju pratiemo rad
protokola DNS.
Detaljan opis ove vebe pronai ete na prateoj veb lokaciji za ovu knjigu -
http;//www. aw 1 .com/kurose-ross.
5tudirali ste fiziku. Da li postoje slinosti izmeu fizike i umreavanja? Studirajui fiziku
polazite od pravila ponaanja lokalnih razmera i razmiljate o tome koja bi od njih mogla da
se uzdignu na svetske razmere. Prilikom dizajniranja globalnog sistema, kao to je Web,
pokuavate da definiete pravila ponaSatija veb strana, linkova i ostalih elemenata koji bi,
posmatrani u celini, mogli da formiraju svet irokih razmera, onakav kakav biste ieieli. Jedno
je analiza, drugo sinteza, ali su na neki nain prilino slini.

ta je uticalo da kao svoju specijalnost izaberete umreavanje?
Nakon to sam diplomirao fiziku, kompanije koje su se bavile telekomunikacionim istrai-
vanjem uinile su mi se najzanimljivije. Mikroprocesor se upravo pojavio i oblast teleko-
munikacija je veoma brzo poela da prelazi sa oienih sistema na sisteme zasnovane na
procesorima. Bilo je to veoma zanimljivo.
ta je najizazovniji deo vae posla?
Kada se dve grupe izuzetno snano razilaze u svojim miljenjima, iako im je krajnji cilj isti
pronalaenje tanog znaenja njihovih pozicija i toga u emu je nesporazum moe biti izu-'
zetno zahtevno. Svako ko je ikada vodio neku radnu grupu zna na ta mislim. Meulim to je
veoma vana uloga za napredovanje ka konsenzusu na nekom viem nivou
Kako zamiljate budunost umreavanja i Interneta?
Kao to sam napisao u mojoj knjizi, sanjam VVeb... i taj san ima dva dela.
U prvom delu Web e postati mnogo monije sredstvo za zajedniki rad ljudi.
Informacijski prostor sam uvek zamiljao kao neto emu svi mogu da pristupe odmah i
intuitivno - ne samo da bi pretraivali, ve i da bi stvarati.,. tavie, elektronska komunika-
cija ljudi kroz zajednika znanja mora biti mogua u svim razmerama i onoliko jednostavna
koliko je danas lina komunikacija,

i-

U drugom delu sna ova saradnja se proiruje i na raunare. Raunari e postati sposobni
da analiziraju sve podatke na Webu - sadraj, veze i transakcije izmeu ljudi i raunara.
Semantiki V/eb", koji to treba da omogui, tek treba da se pojavi, ali kada ga dobijemo,
svakodnevnim mehanizmima trgovine, birokratije i naSih ivota upravljae raunari koji
komuniciraju sa drugim raunarima; na ljudima e bili samo da obezbede. inspiraciju i intu-
iciju... Web koji maine mogu da razumeju dobiemo kroz implementaciju serije tehnikih,
pronalazaka i drutvenih sporazuma koji su sada na samom poetku svog razvoja.
Kada se ostvari ovaj dvodelni san, imaemo VVeb koji predstavlja idealnu i monu sim-
biozu ljudskih bia i mainskog naina razmiljanja.
Koji su vas ljudi najvie inspirirali u profesionalnom smislu?
Moji roditelji, koji su uestvovali u prvim danima raunarstva, trajno su me fascinirali
itavom ovom temom, Majk Sendal i Pegi Rimer od kojih sam mnogo nauio na CERN-u,
takode su meu onim ljudima koji su me uili i ohrabrili. Kasnije sam nauio da potujem
ljude, kao to su Vanevar Bu, Dag Englebart i Ted Nelzon koji su svojevremeno imali veoma
sline snove, ali nisu imali na raspolaganju personalne raunare i Internet da ih i ostvare.

Misija Konzordjuma World Wide VVeb jeste da vodi VVeb ka ostvarivanju njegovog punog
potencijala". Ja je, prema vaSem miljenju, pun potencijal Weba i na koji nain on moe da
se ostvari?
Mi pokuavamo da ga vodimo u dva smera koja sam pomenuo - ka saradnji i ka semantikom
Webu,,Sve vreme pokuavamo da proiirimo univerzalnost VVeba u tom smislu da postoji
samo jedan Web - bez obzira na va5 ita - Web koji je uvek dostupan i kome svako moe da
pristupi bez obzira na razlike u pogledu hardverskih ureaja, softvera, geografskog poloaja,
hendikepiranosti, jezika i kulture.
TRANSPORTNI
SLOJ
Kako se nalazi izmeu aplikacijskog sloja i mrenog sloja, transportni sloj predstavlja
centralni deo slojevite mrene arhitekture. On igra presudnu ulogu u direktnom povezivanju
aplikacijskih procesa koji se izvravaju na razliitim raunarima. U ovom poglavlju,
naizmenino emo izlagati principe transportnog sloja i primenu tih principa u postojeim
protokolima; kao i obino, poseban naglasak se stavlja na Internet protokole, naime,
protokole transportnog sloja: TCP i UDP.
Poeemo sa opisivanjem odnosa izmeu transportnog i mrenog sloja. Pozabaviemo
se jednom od kljunih funkcija transportnog sloja, koja se ogleda u sledeem: usluga
isporuivanja - koja se izmeu dva krajnja sistema obavlja u mrenom sloju - nastavlja se u
transportnom sloju, pa se dobija isporuivanje izmeu dva procesa iz aplikaciskih slojeva tih
krajnjih sistema. Ovu funkciju ilu-strujemo prikazom Intemetovog transportnog protokola bez
UDP konekcije.
Zatim se vraamo izlaganju jednog od najosnovnijih problema umreavanja raunara -
kako omoguiti pouzdanu komunikaciju preko medijuma na kojem moe doi do gubitaka i
oteenja podataka, Nizom sve sloenijih (a realnih!) scenarija izgradiemo tehnike koje
transportni protokoli koriste u reavanju ovih problema. Zatim emo prikazati kako su ovi
principi ugraeni u TCP, Internetov transportni protokol sa konekcijom.
182 182 182 182
183

184 184 184 184 POGLAVLJE 3 TRANSPORTNI SLOJ
3.1 USLUGE TRANSPORTNOG SLOJA
104 104 104 104

Nakon toga, prelazimo na drugi osnovni problem umreavanja - kontrolu brzine prenosa
entiteta 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
njegovu kontrolu. Kada dobro savladamo pitanja kontrole zaguenja, prouiemo TCP-ov
pristup toj problematici.
obezbeduje logiku komunikaciju izmeu raunara. Ova razlika je suptilna, ali znaajna.
Objasnimo ovu razliku pomou analogije iz svakodnevnog ivota.
Uzmimo dve kue, jednu na Istonoj, a drugu na Zapadnoj obali. U svakoj od tih kua
stanuje po dvanaestoro dece. Deca u kui na Istonoj obali su roaci dece u kui na Zapadnoj
obali. Deca se dopisuju - svako dete svake nedelje pie po
3.1 Usluge transportnog sloja
U prethodna dva poglavlja pomenuli smo ulogu transportnog sloja i usluge koje pn
obezbeduje. Ukratko emo ponoviti ono to smo o transportnom sloju ve nauili.
Protokol transportnog sloja obezbeduje logiku komunikaciju izmeu aplika-cionih
procesa koji se izvravaju na razliitim raunarima. Pod logikom komunikacijom
podrazumevamo da, iz perspektive aplikacije, izgleda kao da su raunari na kojima se procesi
izvravaju direktno povezani; u praksi, raunari se mogu nalaziti na suprotnim krajevima
planete, povezani preko niza rutera i razliitih vrsta linkova. Za meusobno slanje poruka,
aplikacijski procesi koriste logiku komunikaciju koju obezbeduje transportni sloj, osloboeni
brige o detaljima fizike infrastrukture koja se koristi za prenos tih poruka. Na slici 3.1
prikazan je pojam logike komunikacije.
Kao to se vidi na slici 3.1, protokoli transportnog sloja implementirani su u krajnjim
sistemima, ali ne i na mrenim ruterima. Mreni ruteri koriste jedino polja mrenog sloja u
jedinici podataka PDU-3 (tj. jedinici podataka u protokolu mrenog sloja); oni he koriste polja
transportnog sloja. Na otpremnoj strani, transportni sloj konvertuje poruke dobijene od
aplikacionog procesa poiljaoca u PDU-4 (tj. jedinicu podataka u protokolu transportnog
sloja). Ovo se postie (eventualnom) podelom aplikacione poruke na manje komade i
dodavanjem zaglavlja transportnog sloja na svaki takav deo da bi se napravio PDU-4.
Transportni sloj zatim predaje PDU-4, mrenom sloju gde se svaki PDU-4 enkapsulira u
PDU-3. Na prijemnom kraju, transportni sloj prima PDU-4 od mrenog sloja ispod njega,
uklanja transportno zaglavlje sa jedinice podataka PDU-4, ponovo sastavlja poruku i
prosleduje je aplikacijskom procesu koji je prima.
Mrenim aplikacijama je esto dostupno vie protokola transportnog sloja. Na primer,
Internet ih ima dva - TCP i UDP. Svaki od ovih protokola obezbeduje drugaije usluge
transportnog sloja pozivnoj aplikaciji.

3.1.1 Odnos izmeu transportnog i mrenog sloja
Verovatno znate da se u familiji protokola transportni sloj nalazi tano iznad mrenog sloja.
Dok protokol transportnog sloja obezbeduje logiku komunikaciju izmeu procesa koji se
izvravaju na razliitim raunarima, protokol mrenog sloja

3.1 USLUGE TRANSPORTNOG SLOJA 187 187 187 187

jedno pismo svakom roaku, a svako pismo se otprema u zasebnoj koverti, obinom potom.
Tako svaka kua svake nedelje aije 144 pisma onoj drugoj kui. (Koliko bi samo ova deca
utedela kada bi imala e-potu!) U svakoj od ovih kua, po jedno dete -Ana na Zapadnoj
obali i Bil na Istonoj - zadueno je za prikupljanje i distribuciju pote. Svake nedelje Ana
obilazi svu svoju brau i sestre, prikuplja potu i predaje je potanskom slubeniku, koji
svakoga dana obilazi kuu. Kada pisma stignu u kuu na Zapadnoj obali, Antn zadatak je da
podeii potu svojoj brai i sestrama. Na Istonoj obali, iste te poslove obavlja Bil.
U ovom primeru, potanska sluba obezbeduje logiku komunikaciju izmeu dve kue -
potanska sluba prenosi potu 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
potu svojoj brai i sestrama. Obratite panju na to da iz perspektive roaka, Ana i Bil jesu
potanska sluba, iako oni obavljaju samo jedan deo isporuke s kraja na kraj (deo unutar
krajnjeg sistema). Ovaj primer predstavlja lepu analogiju kojom emo opisati odnos
transportnog i mrenog sloja:
poruke iz aplikacija = pisma u kovertama procesi
= roaci
raunari (ili krajnji sistemi) = kue protokol
transportnog sloja = Ana i Bil
protokol mrenog sloja = potanska sluba (ukljuujui i potare)
Ako pratimo dalje ovu analogiju, uoavamo da Ana i Bil sav svoj posao obavljaju u
vlastitim kuama; oni nisu ukljueni, na primer, u sortiranje pote u nekom tranzitnom
potanskom centru niti u prenoenje pote 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 aplikacijskih procesa do mree (tj. do mrenog sloja) i obratno,
ali ni na koji nain ne utie na nain prenoenja poruke preko mree. U sutini, kar> to se
vidi na slici 3.1, usputni ruteri ne koriste, niti prepoznaju, informacije koje je transportni sloj
dodao poruci iz aplikacije.
Vratimo se naoj analogiji, i pretpostavimo da Ana i Bil idu na odmor, pa drugi par
roaka - na primer, Suzan i Harvi - preuzimaju njihove uloge prikupljanja i isporuivanja
pote unutar kue. Na alost te dve porodice, Suzan i Harvi ne prikupljaju i ne isporuuju
tano na isti nain kao Ana i Bil. Poto su mlai, Suzan i Harvi prikupljaju i dele potu rede,
a povremeno i gube pisma (ponekad ih savae njihovi psi). Prema tome, Suzan i Harvi ne
pruaju iste usluge (tj, isti model usluge) kao Ana i Bil. Analogno tome, raunarska mrea
obezbeduje razliite transportne protokole i svaki od tih protokola nudi aplikacijama
drugaiji model usluga.
Usluge koje su Ana i Bil u stanju da ponude jasno su ograniene mogunostima
potanske slube. Na primer, ako potanska sluba ne garantuje maksimalno vreme isporuke
izmeu dve kue (na primer 3 dana), 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 esto su ograniene modelom usluga svojstvenim protokolu mrenog sloja. Ako
protokol mrenog sloja ne garantuje kanjenje ili propusni opseg za slanje jedinice podataka
PDU-4 od raunara do raunara, ni protokol transportnog sloja ne moe da garantuje
kanjenje niti propusni opseg za poruke koje se alju od procesa do procesa.
Meutim, transportni protokol moe da ponudi neke usluge ak i kada mreni protokol
u osnovi ne nudi odgovarajuu uslugu u mrenom sloju. Na primer, kao to emo videti u
ovom poglavlju, transportni protokol moe da ponudi aplikaciji uslugu pouzdanog transfera
podataka ak i kada mreni protokol nije naroito pouzdan, tj. ak i kada mreni protokol
gubi, oteuje i duplira pakete. Drugi primer (koji emo detaljnije obraditi u poglavlju 7
kada budemo izlagali o bezbednosti u mrei) bio bi da transportni protokol moe koristiti
ifrovanje kojim se garantuje da aplikacijske poruke nee itati neovlaena lica, ak i ako
mreni sloj ne moe da garantuje poverljivosl za PDU-4.

3.1.2 Kratak pregled transportnog sloja u Internetu
Verovatno znale da Internet, pa i svaka TCP/IP mrea, aplikacijskom sloju nudi dva razliita
transportna protokola. Jedan od tih protokola je UDP (User Datagram Protocol) koji
pozivajuoj aplikaciji obezbeduje nepouzdanu uslugu bez konekcije. Drugi protokol je TCP
(Transmission Control Protocol), koji pozivajuoj aplikaciji nudi pouzdanu uslugu sa
uspostavljanjem konekcije. Pri projektovanju mrene aplikacije programer mora da navede
jedan od ova dva transportna protokola. Kao to smo videli u odeljcima 2.6 i 2.7, programer
bira protokol UDP ili TCP kada pravi soket.
Da bi terminologija bila jednostavnija, u kontekstu Interneta PDU-4 emo zvati
segmentom. Pomenuemo, meutim, da se u internetskoj literaturi (na primer, u RFC-ovima)
PDU za TCP takoe naziva segmentom, ali se PDU za UDP naziva datagramom. Ista ta
internetska literatura koristi izraz datagram i za PDU mrenog sloja! Smatramo da emo u
uvodnoj knjizi o umreavanju raunara, kakva je ova, spreiti zabunu ako PDU za TCP i
UDP zovemo segment, a ostavimo izraz datagram za PDU mrenog sloja.
Pre nego to preemo na kratak uvod u UDP i TCP, dodaemo nekoliko rei o
mrenom sloju Interneta. (Mreni sloj je detaljno obraen u poglavlju 4.) Inter-netski
protokol mrenog sloja je IP to je skraenica od Internet Protocol. IP obezbeduje logiku
komunikaciju izmeu raunara. Model usluge IP-a je najbolji

188 188 188 188 POGLAVLJE 3 TRANSPORTNI SLOJ 3.2 . MULTIPLEKSIRANJE I I I I DEMULTIPLEKSIRANJE . 189 189 189 189
mogui pokuaj isporuke. To znai da IP ini sve to moe" da isporui segmente izmeu
raunara, ali ne prua nikakvu garanciju. Konkretno, ne garantuje isporuku segmenta, ne
garantuje redosled isporuke segmenata i ne garantuje integritet podataka u segmentima. Zato
se za IP kae daje nepouzdana usluga. Pomenuemo takoe da svaki raunar ima bar jednu
adresu mrenog sloja, takozvanu IP adresu. U poglavlju 4 detaljno emo razmotriti
IPadresiranje; ovde je jedino vano imati naumu da svaki raunar ima IP adresu.
Nakon ovog kratkog prikaza IP modela usluga, opisaemo ukratko modele usluga koje
pruaju UDP i TCP. Njihova osnovna uloga je da proire IP uslugu ispo-ruivanja izmeu
dva krajnja sistema i na uslugu isporuivanja 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 demultiple-ksiranje transportnog sloja. Multipleksiranje i
demultjpleksiranje transportnog sloja predstavlja temu sledeeg odeljka. UDP i TCP takode
obezbeuju proveravanje integriteta tako to u svojim zaglavljima sadre polja za otkrivanje
greaka. Ove dve osnovne usluge transportnog sloja - isporuka podataka od procesa do
procesa i pro-vera greaka-jedine su usluge koje prua UDP! Konkretno, kao i IP, UDP je
nepouzdana usluga - on ne garantuje da e podaci koje alje jedan proces, stii neoteeni (ili
stii uopte!) do odredinog procesa. UDP je detaljno opisan u odeljku 3.3.
S druge strane, TCP nudi aplikacijama nekoliko dodatnih usluga. Pre svega, on nudi
pouzdan transfer podataka. Pomou kontrole toka, rednih brojeva, potvrda prijema i tajmera
(tehnika koje emo detaljno obraditi u ovom poglavlju), TCP obezbeduje da se podaci
isporue pravilno i u ispravnom redosledu od izvornog procesa do prijemnog procesa. Na
ovaj nain, TCP pretvara nepouzdanu uslugu IP izmeu krajnjih sistema u pouzdanu uslugu
za prenos podataka izmeu procesa. TCP takoe obezbeduje kontrolu zaguenja. Kontrola
zaguenja je pre usluga za Internet kao celinu, usluga za opte dobro, a ne toliko usluga koja
se prua aplikaciji koja je inicira. Slobodno govorei, TCP kontrola zaguenja spreava da
neka TCP konekcija zatrpa preteranom koliinom saobraaja linkove i komutatore koji se
nalaze izmeu raunara u komunikaciji. U principu, TCP obezbeduje jednak deo propusnog
opsega svim TCP konekcijama koje prelaze preko zaguenog mrenog linka. Ovo se postie
regulisanjem brzine kojom TCP na strani poiljaoca alje saobraaj u mreu. Nasuprot tome,
UDP saobraaj nije regulisan. Aplikacija koja koristi UDP transport moe da alje
proizvoljnom brzinom dokle god to hoe.
Protokol koji obezbeduje pouzdan transfer podataka i kontrolu zaguenja mora da bude
sloen. Bie nam potrebno nekoliko odeljaka za opis principa pouzdanog transfera 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 principe i
njihovu primenu u protokolu TCP. Na primar, prvo opisujemo pouzdan transfer podataka u
optem smislu, a zatim konkretan
nain na koji TCP obezbeduje pouzdan transfer podataka. Slino tome, prvo opisu-jenw
kontrolu zaguenja u optem smislu, a nakon toga nain na koji TCP kontrolie zaguenje.
Ali pre nego to se upustimo u sve to, razmotrimo najpre multipleksiranje i
demultipleksiranje transportnog sloja.
3. 2 Multipleksiranje i demultipleksiranje
U 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
izlaganje ostalo konkretno, opisaemo osnovnu uslugu transportnog sloja u kontekstu
Interneta. Naglaavamo, meutim, daje usluga multipjeksiranja i demultipleksiranja potrebna
u svim raunarskim mreama.
U odredinom raunaru, transportni sloj prima segmente (tj. PDU transportnog sloja) od
mrenog sloja koji se nalazi neposredno ispod njega, Transportni sloj zaduen je da isporui
podatke iz tih segmenata odgovarajuem aphkacionom procesu koj i se izvrava na raunaru.
Pogledajmo jedan primer. Uzmimo da sedite pred rau-narom i da preuzimate veb stranice
dok se izvravaju jedna FTP sesija i dve Telnet sesije. Prema tome, izvravaju se etiri
mrena aplikaciona procesa - dva Telnet procesa, jedan FTP proces i jedan HTTP proces.
Kada transportni sloj u vaem raunaru primi podatke od mrenog sloja nieg nivoa, on mora
da usmeri primljene podatke jednom od ova etiri procesa. Sada emo videti kako se to radi.
Pre svega, setite se iz odeljaka 2.6 i 2.7 da proces (kao deo mrene aplikacije) ima soket
koji predstavlja vrata kroz koja podaci iz mree prolaze prema procesu i obratno. Prema
tome, kako je prikazano na slici 3.2, transportni sloj u prijemnom raunaru u sutini ne
isporuuje podatke direktno procesu, ve posrednikom soketu, Poto u svakom
pojedinanom trenutku u prijemnom raunaru postoji vie soketa, svaki od njih ima
jedinstven indentifikator. Format indetifikatora zavisi od toga da li je re o UDP soketu ili
TCP soketu, to emo obraditi malo kasnije.
Razmotrimo sada kako prijemni raunar usmerava dolazni segment iz transportnog sloja
u odgovarajui soket. Svaki segment transportnog sloja ima za ovu svrhu jedan skup polja u
segmentu. 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 i2vomom raunam sa razliitih soketa, enkapsuliranje svakog dela
zaglavljem (koje e se kasnije koristiti za demultipleksiranje) da bi se napravio segment, i
predavanje segmenata mrenom sloju, naziva se multipleksiranje. Obratite panju na to da
transportni sloj u

190 190 190 190 POGLAVLJE 3 TRANSPORTNI SLOJ 3.2 MULTIPLEKSIRANJE 1 DEMULTIPLEKSIRANJE 191 191 191 191

srednjem raunaru na slici 3.2 mora da demultipleksira segmente koje dobija iz nieg
mrenog sloja da bi ih predao procesu Pj ili P2 iznad njega; to se postie usmerava-njem
podataka dolaznog segmenta na odgovarajui soket za tnj proces. Transportni sloj u srednjem
raunaru mora takoe da prikuplja odlazne podatke sa tih soketa, da formira segmente
transportnog sloja i preda te segmente nanie, mrenom sloju.
Da bismo ilustrovali demultipleksiranje, setite se metafore sa domainstvom iz
prethodnog odeljka. Svako dete prepoznajemo po imenu. Kada Bil primi gomilu pote od
potara, on je demulcipieksira tako to utvruje na koga su pisma adresirana i uruuje pisma
svojoj brai i sestrama. Ana multipleksira potu 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 opisa nam je jasno daje za
multipleksiranje u transportnom sloju potrebno da (1) soketi imaju jedinstvene identifikatore i
da (2) svaki segment sadri posebna polja koja odreuju soket u koji treba taj'segment
isporuiti. Ta posebna polja su polje broja izvornog porta i polje broja odredinog porta
(slika 3.3). (UDP i TCP segmenti sadre i druga polja o kojima emo govoriti u sledeim
odeljcima ovog poglavlja.) Svi brojevi portova su 16-bitni, u rasponu od 0 do 65535. Brojevi
portova od 0 do 1023 nazivaju se dobro poznatim brojevima portova i rezervisani su za
dobro poznate aplikacijske protokole, 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 RFC-u 1700, i
u njegovoj aurnijoj verziji na adresi http://www.iana.org [RFC 3232]. Kada razvijamo
novu aplikaciju (kao Stoje to uinjeno u odeljcima od 2.6 do 2.8), moramo dodeliti
aplikaciji broj porta.
Sada bi trebalo da je jasno kako bi transportni sloj mogao da implementira uslugu
demultipleksiranja: svakom soketu u raunaru dodelio bi se broj porta, a kada segment
stigne u raunar transportni sloj bi ispitao broj odredinog porta u segmentu i usmerio
segment na odgovarajui soket, Podaci iz segmenta proli bi kroz soket u odgovarajui
proces. Kao to emo videti, UDP u osnovi tako i funkci-onie. Meutim, kao to emo
takoe videti, multipleksiranje i demultipleksiranje u TCP-u ipak je sloenije.

Multipleksiranje i demultipleksiranje bez uspostavljanja konekcije
Setite se iz odeljka 2.7 da Java program koji se izvrava na raunani moe da napravi UDP
soket pomou nitredbe:

DatagramSocket mvSocket = nevi DatagramSocket();
Kada se na ovaj nain napravi UDP soket, transportni sloj automatski dodeljuje soketu broj
porta. Konkretno, transportni sloj dodeljuje broj porta u rasponu od 1024 do 65535 koji
trenutno ne koristi nijedan drugi UDP port u launaru. Java program bi takoe mogao da
napravi soket pomou naredbe:
DatagramSocket mvSocket = new DatagramSocket(19157);
U ovom sluaju, aplikacija dodeljuje UDP soketu odreeni broj soketa - 19157. Ako
programer pie kod za serverski deo dobro poznatog protokola", on mora da dodeli

3.2 MULTIPLEKSIRANJE I I I I DEMULTIPLEKSIRANJE 193 193 193 193
odgovarajui dobro poznati broj porta. Obina klijentska strana aplikacije dozvoljava da
transportni sloj automatski (i transparentno) dodeli broj porta, dok se na serverskoj strani
aplikacije dodeljuje tano odreeni broj porta.
Poto srao UDP soketima dodelili brojeve portova, moemo precizno da opiemo UDP
multipleksiranje i demultipleksiranje. Uzmimo da, u raunam A, proces sa UDP soketom
19157 eli da poalje aplikacijski podatak procesu sa UDP soketom 46428 u raunaru B.
Transportni sloj u raunani A napravie segment transportnog sloja koji obuhvata
aplikacijske podatke, izvorni broj porta (19157), odredini broj porta (46428) i jo dve
vrednosti (koje emo kasnije opisati, a nisu vane za sadanje izlaganje). Transportni sloj
zatim predaje dobijeni segment mrenom sloju. Mreni sloj enkapsulira segment u IP
datagram i daje sve od sebe da isporui segment prijemnom raunaru, Ako segment stigne
prijemnom raunaru B, ovaj 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 stiu sa mree, raunar B usmerava (demultipleksira) svaki segment
odgovarajuem soketu na osnovu broja odredinog porta u segmentu.
Vano je primetiti da se UDP soket potpuno identifikuje 2-torkom koja se sastoji od
odredine IP adrese i odredinog broja porta. Prema tome, ako dva UDP segmenta imaju
razliite izvorne IP adrese i/ili razliite izvorne brojeve portova, a istu odredinu IP adresu i
odredini broj porta, ta dva segmenta e se usmeriti istom odredinom procesu kroz isti
odredini soket.
Moda se sada pitate koja je svrha broja izvornog porta. Kao to je prikazano na slici
3.4, u segmentu A-prema-B broj izvornog porta slui kao deo adrese za odgovor" - kada B
eli da vrati segment raunaru A, odredini port u segmentu B-prema-A uzima vrednost
izvornog porta iz segmenta A-prema-B. (Potpuna adresa za odgovor sastoji se od IP adrese
raunara A i izvornog broja porta.) Kao primer za ovo moe posluiti program UDP servera
koji smo radili u odeljku 2.7. U programu UDPServer.java, server koristi metod kojim vadi
broj izvornog porta iz segmenta koji je primio od klijenta; zatim aije klijentu novi segment
u kojem se dobijeni broj izvornog porta koristi kao broj odredinog porta u novom segmentu.

Multipleksiranje i demultipleksiranje pri uspostavljenoj konekciji
Da bi se shvatilo TCP demultipleksiranje, moramo bolje da razmotrimo TCP sokete i
uspostavljanje TCP konekcije. Jedna suptilna razlika izmeu TCP soketa i UDP soketa je u
tome to se TCP soket identifikuje pomou 4-tvorke: izvoma IP adresa, izvorni broj porta,
odredina IP adresa i odredini broj porta. Prema tome, kada TCP segment stigne sa mree
na raunar, raunar koristi sve etiri vrednosti da bi usmeno (demultipleksirao) segment na
odgovarajui soket. Konkretno, a za razliku od
UDP-a, dva dolazna TCP segmenta sa razliitim IP adresama izvora, ili razliitim izvornim
brojevima portova, usmerie se na dva razliita soketa. Da bismo dobili jo bolji uvid,
razmotrimo ponovo programski primer sa TCP klijentom/serverom iz odeljka 2.6:
Aplikacija TCP servera ima soket dobrodolice" koji eka zahteve za uspostavljanje
konekcije koji stiu od TCP klijenata (slika 2.22) na broju porta 6789.
TCP klijent proizvodi segment za uspostavljanje konekcije naredbom:
Socket clientSocket = new Socket {"serverHostName", 6789);
Zahtev za uspostavljanje konekcije nije nita drugo nego TCP segment sa brojem
odredinog porta 6789 i ukljuenim posebnim bitom za uspostavljanje konekcije u TCP
zaglavlju (opisan u odeljku 3.5). Segment takoe sadri izvorni broj porta koji je izabrao
klijent, Prethodna naredba takoe proizvodi TCP soket za klijentski proces, kroz koji
podaci mogu da ulaze u ovaj proces i da ga naputaju.
Kada server primi od klijenta dolazni segment sa zahtevom za konekciju, on o tome
obavetava serverski proces koji zatim pravi soket konekcije:

195 195 195 195
Socket connectionSocket = welcomeSocket.accept ( ) .

Osim toga, server belei sledee etiri vrednosti iz segmenta za zahtevanje konekcije: (1)
broj izvornog porta iz segmenta, (2) IP adresu izvornog raunara, (3) odredini broj porta
iz segmenta i (4) vlastitu IP adresu. Novonapravljeni sokei konekcije identifikuje se
pomou te etiri vrednosti; svi sledei dolazni segmenti iji se izvomi port, izvorna IP
adresa, odredini port i odredina IP adresa poklapaju sa ove etiri vrednosti, bie
demultipleksirani u ovom soketu. Postoje sada uspostavljena TCP konekcija, klijent i
server mogu da alju podatke jedan drugome.
Serverski raunar moe da podri vie istovremenih TCP soketa tako da svaki soket bude
pridruen nekom procesu, a da se svaki soket identifikuje vlastitom 4-torkom. 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 (demulti-pleksirao) u
odgovarajui soket.
Ova situacija ilustrovana je na slici 3.5, na kojoj raunar C inicira dve HTTP sesije na
serveru B, a raunar A inicira jednu HTTP sesiju na serveru B. Raunari A i C i server B
imaju svi vlastite IP adrese - A, C, odnosno B.
Raunar C u svojim dvema HTTP konekcijama dodeljuje dva razliita broja (26145 i
7S32) za izvorne portove. Poto raunar A bira brojeve izvornih portova nezavisno od
raunara C, on bi takoe mogao da dodeli svojoj HTTP konekciji izvomi port 26145. Bez
obzira na to, server B e ipak moi pravilno da demultiple-ksira dve konekcije sa istim
izvornim brojem porta poto te konekcije imaju razliite izvorne IP adrese.

Veb serveri i TCP
Pre zakljuka treba rei jo neto o veb serverima i nainu na koji oni koriste brojeve
portova. Uzmimo raunar na kome se izvrava veb server, na primer Apache veb server na
portu 80. Kada klijenti (na primer, itai) alju serveru segmente, svi segmenti e imati
odredini port 80. Konkretno, i segment za poetno uspostavljanje konekcije i segmenti koji
sadre poruke sa HTTP zahtevima imae odredini port 80. Kao to smo upravo rekli, server
razlikuje segmente od razliitih klijenata po izvornim IP adresama i izvornim brojevima
portova.
Veb serveri obino proizvode novi proces ili prave novu nit za svaku novu klijentsku
konekciju. Na slici 3.5 prikazanje veb server koji pravi novi proces za svaku konekciju. Kao
to se vidi na slici 3.5, svaki od ovih procesa ima vlastiti soket kroz koji stiu HTTP zahtevi i
alju se HTTP odgovori. Napominjemo, meutim, da ne postoji uvek odnos 1:1 izmeu
soketa i procesa. U stvari, dananji veb serveri visokih performansi esto koriste arao jedan
proces, ali prave novu nit sa novim soke-tom za svaka novu'klijentsku konekciju, (Nit se
moe smatrati potprocesom lake
kategorije".) Ako ste uradili prvi programski zadatak u poglavlju 2, napravili ste veb server
koji upravo to radi. Za takav server, u jednom trenutku moe da postoji mnogo soketa (sa
razliitim identifikatorima) za isti proces.
Ako klijent i server koriste postojani HTTP, tada e tokom cele postojane konekcije
klijent i server razmenjivati HTTP poruke kr02 kr02 kr02 kr02 isti serverski soket. Meutim, ako klijent i
server koriste nepostojani HTTP, tada se za svaki zahtev i odgovor pravi i zatvara nova TCP
konekcija, i zato se za svaki zahtev i odgovor pravi i kasnije zatvara novi soket. To esto
pravljenje i zatvaranje soketa moe veoma loe da utie na performanse optereenog veb
servera (mada se za izbegavanje ovog problema moe koristiti niz trikova sa operativnim
sistemom). itaoci koje zanimaju pitanja operativnog sistema u vezi sa postojanim i
nepostojanim HTTP-om trebalo bi da proitaju [Nielsen 1997],
Poto smo opisali multipleksiranje i demultipleksiranje transportnog sloja, prelazimo
na opis jednog od intemetskih transportnih protokola, UDP U sledeem odeljku videemo
da UDP dodaje gotovo jedino uslugu multipleksiranja i demultipleksiranja protokolu
mrenog sloja.
3.2 . MULTIPLEKSIRANJE 1

196 196 196 196 POGLAVLJE 3 TRANSPORTNI SLOJ 3.3 PRENOS BEZ USPOSTAVUANJA KONEKCIJE: UDP 197;
3. 3 Prenos bez uspostavljanja konekcije; UDP
U ovom odeljku detaljnije razmatramo UDP, kako funkcionie i ta radi. Bilo bi poeljno da
italac ponovo proui odeljak 2. i gde se nalazi pregled modela usluge UDP-a, i odeljak 2.7
gde je opisano programiranje soketa preko UDP-a.
Da bi opis UDP-a bio konkretniji, pretpostavimo da elimo da projektujemo goli
transportni protokol, bez ikakvih dodataka. Kako bismo to uradili? Prvo razmotrimo
korienje praznog transportnog protokola. Konkretno, na strani poiljaoca poruke bi se
uzimale od aplikacijskog procesa i predavale direktno mrenom sloju, a na primajuoj strani
bi se poruke dobijene od mrenog sloja direktno predavale aplikacijskom procesu. Meutim,
kao to smo videli u prethodnom odeljku, mora se uraditi neto vie od toga! Najmanje to
transportni sloj mora da prui jesu multipleksiranje i demultipleksiranje, da bi podatke
dobijene iz mrenog sloja preneo ispravnom procesu u aplikacijskom sloju,
UDP, definisan u RFC-u 768, izvrava minimum koji se oekuje od transportnog
protokola. Osim funkcije multipleksiranja i demultipleksiranja i veoma ograniene provere
greaka, on nita ne dodaje IP-u, U sutini, ako programer izabere UDP umesto TCP-a,
aplikacija e se skoro direktno obraati IP-u. UDP uzima poruke od aplikacijskog procesa,
dodaje polja sa brojevima izvornog i odredinog porta za multipleksiranje i
demultiplsksiranje, dodaje jo dva mala polja i predaje dobijeni segment mrenom sloju.
Mreni sloj enkapsulira segmentu IP datagram i zatim na najbolji mogui nain nastoji da
isporui segment prijemnom raunaru. Ako segment stigne do prijemnog raunara, UDP
koristi broj odredinog porta kako bi isporuio podatke iz segmenta ispravnom aplikacijskom
procesu. Napominjemo da u UDP-u nema meusobne sinhronizacije izmeu entiteta
otpremnog i prijemnog transportnog sloja pre slanja segmenta. Zato se za UDP kae da je on
bez uspostavljene konekcije.
DNS je primer protokola aplikacijskog sloja koji obino koristi UDP, Kada neka DNS
aplikacija u raunaru eli da postavi upit,'ona pravi DNS upit i uruuje ga UDP-u. Bez
prethodnog sinhronizovanja sa UDP entitetom koji se izvrava u odredinom sistemu, UDP
dodaje upitu polja zaglavlja i predaje dobijeni segment mrenom sloju. Mreni sloj
enkapsulira UDP segment u datagram i alje ga serveru za imena. Zatim DNS aplikacija
raunara, koji je postavio upit, eka odgovor na upit. Ako ne dobije odgovor (moda zato to
je mrea izgubila upit ili odgovor), aplikacija pokuava da poalje upit drugom serveru za
imena ili obavetava pozivnu aplikaciju da ne moe dobiti odgovor.
Moda vas udi zato bi neki programer ikada gradio aplikaciju na UDP-u, a ne na
TCP-u. Zar nije uvek bolje izabrati TCP, kad TCP obezbeduje uslugu pouzdanog transfera
podataka, to UDP ne omoguava? Odgovor je da za mnoge aplikacije UDP vie odgovara iz
sledeih razloga:
Bolja kontrola na nivou aplikacije nad sadrajem i vremenom slanja. Ako se koristi UDP,
im aplikacijski proces preda podatke UDP-u, UDP e spakovati podatke u UDP segment
i odmah predati segment mrenom sloju. Nasuprot tome, TCP sadri 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 podataka dokle god od odredita ne primi potvrdu daje segment
primljen, bez obzira na to koliko takva pouzdana isporuka traje. Poto aplikacije u
realnom vremenu esto zahtevaju garantovanu frekvenciju slanja i ne ele preterano da
odlau prenoenje segmenta, a mogu da toleriu mali gubitak podataka, model TCP
usluge nije naroito pogodan za potrebe takvih aplikacija. Kao to emo objasniti, ove
aplikacije mogu da koriste UDP i da svu dodatnu funkcionalnost koja im'je potrebna
povrh UDP-ove osnovne usluge (isporuke segmenata od jednog procesa drugom),
implementiraju kao deo aplikacije.
Nema uspostavljanja konekcije. Kao to emo objasniti kasnije, TCP koristi
sin-hronizovanje u tri koraka pre nego to pone da alje podatke, UDP jednostavno
kree bez ikakvog formalnog uvoda. Zato kod UDP-a nema kanjenja prilikom
uspostavljanja konekcije. To je verovatno glavni razlog zbog kojeg se DNS izvrava
preko UDP-a, a ne preko TCP-a. DNS bi inae bio mnogo sporiji. HTTP koristi TCP
poto je pouzdanost znaajna za veb stranice sa tekstom. Ali, kako smo ukratko
napomenuli u odeljku 2.2, odlaganje zbog uspostavljanja TCP konekcije za HTTP
znaajno doprinosi sveukupnom ekanju na svetskoj mrei".
Nema stanja konekcije. TCP odrava stanje konekcije u krajnjim sistemima. Ovo stanje
konekcije obuhvata privremene memorije za primanje i slanje, parametre za kontrolu
zaguenja i parametre za redne brojeve i brojeve potvrda. Videemo u odeljku 3.5 da su
ove informacije o stanju potrebne za primenu pouzdanog transfera podataka u TCP i za
obezbedenje kontrole zaguenja. Nasuprot tome, UDP ne prati stanje konekcije, a ni sve
ove ostale parametre. Zato server namenjen odreenoj aplikaciji moe obino da podri
mnogo vie aktivnih klijenata ako se aplikacija izvrava preko UDP-a, a ne preko TCP-a.
Manje dodatno optereenje zaglavljem paketa. TCP segment ima zaglavlje od 20
bajtova, dok UDP ima samo 8.
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, Web i transfer
datoteka izvravaju se preko TCP-a. Svim tim aplikacijama potrebna je usluga pouzdanog
transfera podataka, koju on i obezbeduje. Ipak, mnoge vane aplikacije se izvravaju preko
UDP-a, a ne preko TCP-a. UDP se koristi za auriranje RIP tabela rutiranja (proitajte
poglavlje 4 o mrenom sloju) poto se auriranja alju povremeno (obino svakih 5 minuta),
pa se izgubljena auriranja zamenjuju sveijim auriranjem. UDP se takode koristi za prenos
podataka za upravljanje mreom (SNMP, poglavlje 8). U ovom sluaju, UDP je bolji, jer
aplikacije za upra-

3.3 PRENOS BEZ USPOSTAVLJANJA KONEKCIJE: UDP 199 199 199 199

vijanje mreom esto moraju da se izvravaju kada je mrea u napregnutom stanju - upravo
kada je teko postii pouzdan transfer podatakai kontrolu zaguenja. Osim toga, kako smo ve
pomenuli, DNS se izvrava preko UDP-a i tako izbegava kanjenja za uspostavljanje TCP
konekcije.
Kao to se vidi na slici 3.6, UDP se takoe danas esto koristi 2a multimedijalne aplikacije,
kao to su telefoniranje preko Interneta, video konferencije u realnom vremenu i protok audio j
video datoteka. Ove aplikacije emo blie razmotriti u poglavlju 6. Sada samo napominjemo da
sve te aplikacije mogu da toleriu male gubitke paketa, pa pouzdani transfer podataka nije
apsolutno neophodan za uspeh aplikacije, tavie, aplikacije u realnom vremenu, kao to su
Internet telefoniranje i video konferencije, veoma loe podnose TCP-ovu kontrolu zaguenja.
Zato programeri multimedijalnih aplikacija esto odluuju da im se aplikacije izvravaju preko
UDP-a, a ne preko TCP-a.
Mada se danas esto koristi, izvravanje multimedijalnih aplikacija preko UDP-a predstavlja
izvesnu kontroverzu. Kao to smo ve pomenuli, UDP nema nikakvu kontrolu zaguenja.
Meutim, bez kontrole zaguenja mrea bi dola u stanje u kojem se postie sve manje korisnog
rada. Kada bi svi pokrenuli protok video signala u realnom vremenu, koji ima veliku brzinu
protoka, bez ikakve kontrole zaguenja, na ruterima bi bilo toliko mnogo paketa da niko ne bi
nita mogao da
vidi. Prema tome, nedostatak kontrole zaguenja u UDP-u predstavlja potencijalno veliki
problem [Floyd 1999], Mnogi istraivai predlau nove mehanizme kojima bi se svim izvorima,
pa i izvorima UDP-a, nametnula prilagodljiva kontrola zaguenja [Mahdavi 1997; Floyd 2000],
Pre nego to preemo na opis strukture UDP segmenta, napominjemo da jeste mogue da
aplikacija ima pouzdan transfer podataka, i ako koristi UDP. To se moe postii ako se
pouzdanost ugradi u samu aplikaciju (na primer, dodavanjem mehanizama za potvrivanje i
ponovno slanje, koje emo videti u sledeem odeljku). Ali, ovo nije trivijalan zadatak i zadao bi
programeru mnogo dodatnog posla. Ipak, ugraivanje pouzdanosti direktno u aplikaciju
omoguava da ona zadri ,,i jare i pare". To jest, aplikacijski procesi mogu da ostvare pouzdanu
komunikaciju ne podleui ogranienjima brzine slanja koje namee TCP-ov mehanizam za
kontrolu zaguenja. Mnoge dananje aplikacije za protok signala u realnom vremenu upravo to i
rade - izvravaju se preko UDP-a, alt da bi se smanjio gubitak paketa, ugrauju potvrdu prijema i
ponavljanje slanja u samu aplikaciju; videti primer u [Rhee 1998].

3.3.1 Struktura TJDP segmenta
Struktura UDP segmenta, prikazana na slici 3.7, defmisana je u RFC-u 76S, Aplikacijski podaci
nalaze se u polju podataka UDP segmenta. Na primer, za DNS, polje podataka sadri poruku
upita ili poruku odgovora. Kod aplikacije sa protokom audio signala u realnom vremenu, polje
podataka popunjava se audio uzorcima. UDP zaglavlje ima samo etiri polja od kojih svako
zauzima dva bajta. Kao stoje reeno u prethodnom odeljku, brojevi portova omoguavaju
odredinom raunaru da prosledi aplikacijske podatke odgovarajuem procesu koji se izvrava
na odredinom krajnjem sistemu (tj. da obavi demultipleksiranje). Kontrolni zbir slui prijemnom
raunani da proveri da li je u segmentu dolo do greaka. U sutini, kontrolni zbir se izraunava i
nad nekoliko polja IP zaglavlja, a ne samo nad UDP segmentom. Ovaj
Sl i ka Sl i ka Sl i ka Sl i ka 3.7 Struktura UDP segmente

3.4 PRINCIPI POUZDANOG TRANSFERA PODATAKA 201 201 201 201
detalj emo zanemariti da nam ne bi drvo zaklonilo Sumu. Sada emo opisati izraunavanje
kontrolnog zbira. Osnovni principi otkrivanja greke opisuju se u odeljku 5.1. Polje duine
navodi duinu UDP segmenta u bajtovima, ukljuujui i zaglavlje.

3.3.2 UDP kontrolni zbir
UDP kontrolni zbir slui za otkrivanje greke. To jest, kontrolni zbir se koristi da bi se
utvrdiio da li su promenjeni bitovi u UDP segmentu (na primer, zbog uma u lin-kovima ili
uvanja u ruteru), prilikom prenosa od izvora do odredita. UDP na strani poiljaoca
izraunava komplement jedinice za sumu svih 16-bitnih rei u segmentu, gde se odbacuje
svako prekoraenje do kojeg doe prilikom sabiranja. Ovaj rezultat se stavlja u polje
kontrolnog zbira UDP segmenta. Ovde dajemo jednostavan primer izraunavanja kontrolnog
zbira. Detalje o efikasnom implementiranju izraunavanja moete nai u RFC-u 1071, a o
performansama kada se radi sa stvarnim podacima u [Stone 1998; Stone 2000]. Kao primer,
uzmimo da imamo sledee tri 16-bitne rei;
0110011001100110
0101010101010101
0000111100001111
Zbir prve dve od ovih 16-bitnih rei je:
0110011001100110
0101010101010101
1011101110111011
Ako na ovu sumu dodamo treu re, dobijamo:
1011101110111011
0000111100001111
1100101011001010
Komplement jedinice dobija se pretvaranjem svih 0 u 1, a svih 1 u 0. Prema tome,
komplement jedinice za sumu 1100101011001010 je: 0011010100110101 to se uzima kao
kontrolni zbir. Na prijemnom kraju, sabiraju se sve etiri 16-bitne rei, ukljuujui i kontrolni
zbir. Ako u paketu ne postoje greke, jasno je da e zbir kod primaoca biti 1UIII1111111UI.
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
sa podacima (ukljuujui i popularni protokol Ethernet) takoe sadre proveru greaka.
Razlog lei u tome to ne postoji garancija da e svi linkovi od izvora do odredita
obezbediti proveru greaka - neki od linkova moda koristi protokol koji ne sadri proveru
greaka. Poto se smatra da IP moe da se izvrava povrh ma kog protokola sloja 2, korisno
je da transportni sloj obezbedi proveru greaka za svaki sluaj. Mada UDP sadri proveru
greaka, on nita ne preduzima da bi se greka ispravila. U nekim implementacijama UDP-a,
oteeni segment se jednostavno odbacuje; dok druge implementacije prosleuju aplikaciji
oteeni segment uz upozorenje.
Ovim zakljuujemo opis protokola UDP. Uskoro emo videti da TCP nudi svojim
aplikacijama pouzdan transfer podataka kao .i neke druge usluge koje UDP ne sadri.
Naravno, TCP je zato sloeniji od UDP-a. Pre nego to preemo na opis protokola TCP, bie
korisno da se vratimo za jedan korak i prvo opiemo osnovne principe pouzdanog transfera
podataka pa emo to uraditi u sledeem odeljku. Nakon toga, istraiemp TCP u odeljku 3.5,
pa emo videti da je TCP zasnovan na ovim osnovnim principima.
3. 4 Principi pouzdanog transfera podataka
U ovom odeljku, razmotriemo problem pouzdanog transfera podataka u optem smislu. To
je zato to se problem implementirani a pouzdanog transfera podataka ne javlja samo u
transportnom sloju ve takoe i u sloju veze i u aplikacionom sloju. Taj problem je prema
tome od kljunog znaaja za umreavanje. Zaista, kada bi trebalo napraviti spisak prvih 10"
fundamentalno znaajnih problema za celo umreavanje, ovo bi bio kandidat za prvo mesto.
U sledeem odeljku istraiemo TCP i konkretno pokazati da TCP primenjuje mnoge
principe koje emo sada opisati.
Na slici 3.8 prikazanje radni okvir za nau studiju pouzdanog transfera podataka.
Apstrakcija usluge u entitetima gornjeg sloja je pouzdani kanal kroz koji se mogu prenositi
podaci. Ako postoji pouzdani kanal, ne dolazi do oteenja prenetih bitova podataka
(pretvorenih iz 0 u 1 ili obmuto) niti do gubitaka, i sve se isporuuje redosledom kojim je
poslato. To je upravo model usluge koju TCP prua Internet aplikacijama koje ga pozivaju.


Protokol pouzdanog transfera podataka ima zadatak da implementira tu apstrakciju usluge.
Zadatak je otean injenicom da sloj ispod protokola pouzdanog transfera podataka moe da bude
nepouzdan. Na primer, TCP je protokol pouzdanog transfera podataka koji se implementira povrh
nepouzdanog (IP) mrenog sloja s kraja nakraj. U stvari, sloj ispod dve krajnje take koje pouzdano
komuniciraju moe da se sastoji od jednog jedinog fizikog linka (kao u sluaju protokola za prenos
podataka u sloju veze), ili od globalne medumree (kao u sluaju protokola transportnog sloja). Za
sada je, meutim, dovoljno da taj sledei nii sloj posmatramo jednostavno kao nepouzdan kanal od
take do take.
U ovom odeljku postepeno emo razvijati otpremnu i prijemnu stranu pouzdanog protokola za
transfer podataka, uzimajui u obzir sve sloenije modele kanala koji se nalazi u sloju ispod. Na slici
3.8(b) prikazani su interfejsi naeg protokola za transfer podataka. Otpremna strana protokola za
transfer podataka aktivirae se odozgo pozivom rdt_send ( ) . Podaci koji treba da se isporue bie
predati gornjem
sloju na prijemnoj strani. (Ovde rdt znai reliable data transfer ~ pouzdani transfer podataka, a
_send znai da se poziva deo za slanje protokola rdt. U razvoju svakog protokola, prvi korak je
biranje dobrog imena!) Na prijemnoj strani, pozvae se rdt_rcv () kada paket stigne od prijemne
strane kanala, Kada protokol rdt eli da isporui podatke gornjem sloju, to e uraditi pozivom deliver
data ( ) . U sledeem tekstu emo umesto izraza segment za protokolsku jedinicu podataka koristiti
izraz paket". Poto se teorija koju razvijamo u ovom odeljku odnosi uop-teno na sve raunarske
mree, a ne samo na transportni sloj Interneta, primereniji je optiji izraz paket".
U ovom odeljku, razmatraemo samo sluaj jednosmernog transfera podataka, tj. transfera
podataka od otpremne do prijemne strane. Sluaj pouzdanog dvosmer-nog (puni dupleks)
transfera podataka u sutini nije nita tei, ali gaje znatno tee opisati. Mada razmatramo samo
jednosmerni transfer podataka, vano je napomenuti da e otpremna i prijemna strana naeg
protokola ipak morati da prenose pakete u oba smera, kao stoje naznaeno na slici 3.8. Uskoro
emo videti da osim razmene paketa koji sadre podatke koje treba preneti, otpremna i prijemna
strana protokola rdt moraju takoe da razmenjuju i kontrolne pakete u oba smera. Obe strane proto-
kola alju pakete drugoj strani pozivanjem udt_send ( ) (gde udt znai unrelia-ble data transfer -
nepouzdan transfer podataka).

3. 4. 1 Pravljenje protokola za pouzdan transfer podataka
Sada emo razmotriti niz protokola, svaki sloeniji od prethodnog, dok ne stignemo do besprekomo
pouzdanog protokola za transfer podataka.

Pouzdan transfer podataka preko savreno pouzdanog kanala: rdtl.O
Prvo razmotrimo najjednostavniji sluaj, kada je kanal u osnovi potpuno pouzdan. Sam
protokol, koji emo nazvati rdtl. 0, je trivijalan. Na slici 3.9 prikazane su definicije konanog
automata (finite-state maehine, FSM) za otpremni i prijemni r dt l . 0. FSM na slici 3.9(a) definie
rad poiljaoca, dok FSM 3.9(b) definie rad primaoca. Vano je primetiti da za primaoca i poiljaoca
postoje zasebni FSM-ovi. FSM-ovi poiljaoca i primaoca na slici 3.9 imaju samo po jedno stanje.
Strelice u FSM opisu oznaavaju prelaz protokola iz jednog stanja u drugo. (Poto svaki FSM na
slici 3.9 ima samo po jedno stanje, imamo prelaz iz jednog stanja nazad u to isto stanje; uskoro
emo videti i sloenije dijagrame stanja.) Dogaaj koji izaziva prelaz prikazan je iznad horizontalne
linije u oznaci prelaza, a ispod horizontalne linije prikazana je aktivnost koja se preduzima kada
dogaaj nastupi. Kada se povodom nekog dogaaja ne preduzima nikakva aktivnost, ili ako se
aktivnost preduzima a dogaaj nije nastupio, koristiemo simbol A ispod, odnosno iznad,
horizontalne linije da bi se eksplicitno naglasilo da nema aktivnosti ili dogaaja. Poetno stanje
FSM-a oznaeno je isprekidanom strelicom. Mada FSM-ovi na slici 3.9 imaju samo po jedno stanje,
uskoro emo prikazati FSM-ove sa vie stanja, pa e biti vano da se prepozna poetno stanje
svakog od njih.

3.4 . PRINCIPI POUZDANOG TRANSFERA PODATAKA 205| 205| 205| 205|

Otpremna strana protokola rclt jednostavno prihvata podatke iz gornjeg sloja pomou
dogaaja, pravi paket koji sadri te podatke (upotrebom funkcije make_ pkt (podaci)) i alje
paket u kanal. U praksi, dogaaj rdt_send (podaci) bi potekao od poziva procedure (na primer,
rdt_send {)) u aplikaciji iz gornjeg sloja.
Na prijemnoj strani, rdt prima paket iz donjeg sloja putem dogaaja rdt_rcv (paket) , vadi
podatke iz paketa (upotrebom funkcije extract (paket, podaci)) i predaje podatke gornjem sloju
(pomou funkcije deli-ver_data (podaci)). U praksi, dogaaj rdt_rcv (paket) bi potekao od poziva
procedure (na primer, rdt_rcv ()) iz protokola nieg sloja.
U ovom jednostavnom protokolu, nema razlike izmeu jedinice podataka i paketa. Osim
toga, sav protok paketa je od poiljaoca prema primaocu; sa savreno pouzdanim kanalom nema
potrebe da prijemna strana alje povratnu informaciju poiljaocu poto do greke ne moe doi!
Obratite panju na to da smo takoe pretpostavili daje primalac u stanju da prihvata podatke
istom brzinom kojom ih poiljalac alje. Prema tome, nema potrebe da primalac zahteva od
poiljaoca da uspori"!
Pouzdan transfer podataka preko kanala sa grekama: rdt2 . 0
Realniji model kanala u osnovi bio bi kanal u kojem moe doi do oteenja bitova u paketu.
Takve greke obino se javljaju u fizikim komponentama mree prilikom prenosa,
umnoavanja ili privremenog memorisanja paketa. I dalje emo, za sada, pretpostaviti da su svi
paketi primljeni onim redom kojim su i poslati (mada neki bitovi mogu biti oteeni).
Pre nego to razvijemo protokol za pouzdanu komunikaciju preko takvog kanala,
razmotrimo prvo kako bi ljudi postupili u takvoj situaciji. Zamislite da diktirate dugaku poruku
preko telefona. U tipinoj situaciji primalac poruke bi mogao da kae ,,u redu" nakon svake
reenice koju je uo, razumeo i zapisao. Ako primalac uje nerazgovetnu reenicu, zatraie
daje ponovite. Ovaj protokol za diktiranje poruka sastoji se od pozitivnih potvrda (,,u redu") i
negativnih potvrda (molim, ponovite"). Te kontrolne poruke omoguavaju primaocu da
saopti poiljaocu Staje primljeno pravilno, a staje primljeno nepravilno pa ga treba ponoviti. U
raunarskoj mrei, pouzdani protokoli za transfer podataka, zasnovani na takvom ponovnom sla-
nju, poznati su kao ARQ {Automatic Repeat reQuest) protokoli.
U sutini, da bi se u ARQ protokolima uklonilo prisustvo greaka zbog oteenih bitova,
potrebne su tri dodatne mogunosti:
Otkrivanje greaka. Prvo, potreban je mehanizam kojim e primalac utvrditi da postoje
greke. Setite se iz prethodnog odeljka da UDP koristi Intemetovo polje kontrolnog zbira ba
u ovu svrhu. U poglavlju 5 detaljnije emo razmotriti tehnike za otkrivanje i ispravljanje
greaka; te tehnike omoguavaju primaocu da otkrije i eventualno ispravi greke u bitovima u
paketu. Za sada, dovoljno je da znatno da je za te tehnike potrebno od poiljaoca poslati
primaocu dodatne bitove (pored bitova podataka koje treba preneti); ti bitovi e se smestitiu
polje kontrolnog zbira u paketu podataka protokola rdt 2 . 0.
Povratna informacija poiljaocu. Poto se poiljalac i primalac obino izvravaju na
razliitim krajnjim sistemima i moda su razdvojeni hiljadama kilometara, jedini nain da
poiljalac sazna kako primalac gleda na stvari (u ovom sluaju, da li je paket ispravno
primljen) jeste da mu primalac poalje eksplicitnu povratnu informaciju. Pozitivne (ACK) i
negativne (NAK) potvrde iz malopreanjeg primera (diktiranje poruke telefonom) su u
stvari takve povratne informacije. Slino tome, na protokol rdt2 . 0 e vraati ACK i NAK
pakete od primaoca ka poiljaocu. U principu, ti paketi treba da sadre samo jedan bit; na
primer, vrednost 0 bi znaila NAK, a vrednost 1 ACK.
Ponovno slanje. Poiljalac e ponovo poslati paket koji je kod primaoca primljen sa grekom.
Na slici 3.10 dat je FSM prikaz rdt 2 . 0 protokola za transfer podataka u kojem se koriste
otkrivanje greaka i pozitivne i negativne potvrde.

1206 1206 1206 1206 POGLAVLJE 3 TRANSPORTNI SLOJ 3.4 . PRINCIPI POUZDANOG TRANSFERA PODATAKA 115 115 115 115

Otpremna strana protokola rdt 2 . 0 ima dva stanja. U stanju prikazanom na levoj strani,
protokol za slanje eka podatke iz gornjeg sloja, koje treba da poalje dole. Kada nastupi dogaaj
rdt_send (podaci), poiljalac e napraviti paket (sndpkt) sa podacima koji se alju i kontrolni zbir
paketa (na primer, onako kako je u odeljku 3.3.2 opisano za sluaj UDP segmenta), a zatim e
poslati taj paket operacijom udt_send (sndpkt). U stanju prikazanom na desnoj strani, protokol za
slanje' eka od primaoca paket ACK ili NAK. Ako stigne paket ACK (na slici 3.10 ovom
dogaaju odgovara notacija rdt_rcv (rcvpkt )-&& isACK (rcvpkt)), poiljalac zna da je poslednji
preneti paket ispravno primljen, pa se protokol vraa u stanje ekanja podataka iz gornjeg sloja.
Ako se primi NAK, protokol ponovo alje
poslednji paket i eka da primalac vrati ACK ili NAK u odgovor na ponovljeno slanje paketa
podataka. Vano je primetiti da kada je poiljalac u stanju ekanja na ACK ili NAK, on ne moe
da primi jo podataka za slanje iz gornjeg sloja; do toga e doi tek poto poiljalac dobije ACK
i napusti ovo stanje. Prema tome, poiljalac nee poslati nove podatke sve dok se ne uveri daje
primalac ispravno primio tekui paket. Zbog ovakvog ponaanja, protokoli kakav je rdt2 . 0,
poznati su kao protokoli stani i ekaj".
FSM prijemne strane za rdt2 . 0 i dalje ima samo jedno stanje. Po prijemu paketa primalac
odgovara sa ACK ili NAK, u zavisnosti od toga da lije primljeni paket oteen ili ne. Na slici
3.10 iskaz rdt_rcv (rcvpkt) & & corru-pt (rcvpkt) odgovara dogaaju kada se primi paket i
utvrdi da on sadri greku.
Protokol rdt2 . 0 moda izgleda kao da funkcionie ali, naalost, on ima fatalni nedostatak.
Konkretno, nismo uzeli u obzir mogunost da ACK ili NAK paket moe takoe da bude
oteen! (Pre nego to nastavimo, trebalo bi da razmislite o nainima da se ova greka ispravi.)
Naalost, ovaj mali previd nije tako bezopasan kao to moda izgleda. U najmanju ruku,
moraemo paketima ACK i NAK da dodamo kontrolni zbir da bismo otkrili takvu greku.
Mnogo je tee pitanje kako da se protokol oporavi od greaka u ACK i NAK paketima. Problem
je u tome to u sluaju greke u ACK ili NAK paketu, poiljalac nema naina da sazna da li je
primalac ispravno primio poslednji deo prosleenih podataka.
Pogledajmo tri mogunosti za obradu neispravnih ACK ili NAK paketa:
Kao prvo, da vidimo ta bi ovek mogao da uradi u situaciji iz primera sa diktiranjem
poruke. Ako govornik nije razumeo odgovor ,,u redu" ili molim ponovite", on bi verovatno
pitao ta ste rekli?" (i na taj nain bi uveo u na protokol novu vrstu paketa od poiljaoca ka
primaocu). Sagovoraik bi zatim ponovio odgovor. Meutim, ta ako se oteti pitanje ta ste
rekli?"? Primalac, ne moe da zna da li oteeno pitanje spada u diktat ili je to zahtev da se
ponovi poslednji odgovor, te bi verovatno rekao ta ste vi rekli?". Naravno, i taj odgovor
moe da bude oteen, Jasno je, krenuli smo tekim putem.
Druga alternativa je da se doda dovoljno bitova kontrolnog zbira tako da poiljalac ne samo
otkrije, ve moe i da ispravi bitske greke. Time se neposredno reava problem za kanal u
kojem moe doi do oteenja paketa, ali ne i do njihovog gubitka.
Trei pristup je da poiljalac jednostavno ponovo poalje paket podataka ako primi oteeni
ACK ili NAK paket. Ovim pristupom se, meutim, u kanal od poiljaoca ka primaocu uvode
duplikati paketa. Osnovni problem sa duplikatima paketa je u tome to primalac ne zna da
lije poslednji poslati ACK il i NAK ispravno primljen kod poiljaoca. Prema tome, on ne
moe a priori da zna da li paket koji stie sadri nove podatke ili ponovljene prethodne.
Jednostavno reenje ovog novog problema (koje je prihvaeno skoro u svim postojeim
protokolima za transfer podataka, ukljuujui i TCP) jeste da se paketu


doda jo jedno polje u kojem poiljalac numerie pakete tako to u ovo polje stavlja redni broj.
Primalac zatim samo treba da proveri taj redni broj i utvrdi da li primljeni paket predstavlja
ponavljanje. U ovom jednostavnom primeru protokola stani i ekaj", bie dovoljan redni broj
od jednog bita, poto e omoguiti primaocu da utvrdi da li poiljalac ponovo alje jednom ve
poslat paket (redni broj novopri-mljenog paketa je isti kao i redni broj poslednjeg paketa
primljenog pre toga) ili je to nov paket (redni broj se promenio, nastavlja se aritmetikom
modulo-2). Poto trenutno koristimo pretpostavku da kanal ne gubi pakete, ACK i NAK paketi
ne moraju sami da navode redni broj paketa iji prijem potvruju. Poiljalac zna daje primljeni
ACK ili NAK paket (ispravan ili neispravan) nastao kao odgovor na poslednji predati paket
podataka.
Na slikama 3.11 i 3.12 prikazanje FSM opis za rdt 2.1, nau fiksnu verziju protokola rdt2 .
0. U protokolu rdt2 .1, FSM poiljaoca i primaoca sada imaju dva puta vie stanja nego ranije.
Ovo je zato to stanje protokola sada mora da odraava da li paket koji se trenutno alje (iz
poiljaoca) ili oekuje (kod primaoca) treba da ima redni broj 1 ili 0. Primetiete da su aktivnosti
u stanju kada se oekuje ili
alje paket sa brojem 0, slika u ogledalu aktivnosti iz stanja kada se oekuje ili alje paket sa
brojem 1; jedina razlika se odnosi na rad sa rednim brojem.
Protokol rdt 2 .1 koristi i pozitivne i negativne potvrde od primaoca ka poiljaocu. Kada se
primi paket izvan redosleda, poiljalac alje pozitivnu potvrdu za primljeni paket. Kada se primi
oteeni paket, poiljalac alje negativnu potvrdu prijema. Mogue je postii isti efekat ako se
umesto NAK poalje ACK za poslednji ispravno primljeni paket. Poiljalac koji primi dva
ACK-a za isti paket (tj. primi duplikat ACK-a) zna da primalac nije ispravno primio paket koji je
usledio za paketom sa dve potvrde prijema. Ovakav pouzdani protokol za transfer podataka bez
NAK-ova za kanal sa grekama u bitovima nazvali smo rdt2 . 2 i prikazali, ga na slikama 3,13 i
3.14. Suptilna razlika izmeu protokola rdt2 .1 i rdt2 . 2 jeste u tome to primalac sada mora da
doda u ACK poruku i redni broj paketa iji prijem potvruje (to se postie ukljuivanjem
argumenta ACK,0 ili ACK,1 u aktivnost make__pkt ( ) u FSM primaoca), a poiljalac mora sada
da proveri redni broj paketa iji je prijem potvren primljenom ACK porukom (ovo se postie
dodavanjem argumenta 0 ili 1 u isACK {) u FSM poiljaoca).

210 210 210 210 POGLAVLJE 3 TRANSPORTNI SLOJ 3.4 PRINCIPI POUZDANOG TRANSFERA PODATAKA 117 117 117 117
-i-

Pouzdan transfer podataka preko kanala sa grekama u bitovima i gubicima paketa: rdt3 . 0
- Pretpostavimo sada da, pored toga to oteuje bitove, kanal kroz koji se vri prenos podataka
moe i da gubi pakete, to u dananjim raunarskim mreama (ukljuujui i Internet) nije
neuobiajeno. Sada u protokolu treba resiti jo dva dodatna problema: kako otkriti gubitak paketa
i ta uraditi u sluaju gubitka. Kontrolni zbirovi, redni brojevi, ACK paketi i ponovna slanja -
tehnike razvijene za protokol rdt2 .2
- omoguie nam da resimo ovo drugo pitanje. Reavanje prvog pitanja zahtevae da se doda
jedan novi protokolski mehanizam.
Reavanju gubitka paketa moe se prii na vie naina (u vebama na kraju poglavlja
videemo ih jo nekoliko). Ovde emo za otkrivanje i reavanje problema izgubljenih paketa
zaduiti poiljaoca. Pretpostavimo da poiljalac poalje paket podataka i da se izgubi bilo sam
paket, bilo primaoev ACK za taj paket. U oba sluaja poiljalac nee od primaoca dobiti vie
nikakav odgovor. Ako poiljalac dovoljno dugo saeka da bi bio siguran da se paket izgubio,
tada prosto moe ponovo da poalje isti paket podataka,
Koliko dugo treba poiljalac da eka da bi bio siguran da se neto izgubilo? Jasno je da
mora da eka bar onoliko koliko traje put do poiljaoca i nazad (gde moe biti ukljueno i
privremeno uvanje na usputnim ruterima), plus vreme potrebno za obradu paketa kod
primaoca. U mnogim mreama se maksimalno odlaganje u najgorem sluaju veoma teko
procenjuje, a jo tee precizno odreuje. tavie, protokol bi u idealnom sluaju trebalo da se
oporavi od gubitka paketa Stoje pre mogue; zato bi bilo preterano ekati sa poetkom
ispravljanja greke dok ne proe vreme potrebno u najgorem sluaju. U praksi je zato usvojen
princip da poiljalac izabere neko razumno" vreme u kojem je najverovatnije dolo do gubitka
paketa, mada ne i stopostotno. Ako se ne primi ACK u tom vremenu, paket se alje ponovo.
Ako paket izuzetno mnogo kasni, poiljalac e ga ponovo poslati iako nije izgubljen ni sim
paket podataka, ni njegov ACK. Tako se u kanalu od poiljaoca do primaoca javlja mogunost
dupliranih paketa podataka. Sreom, protokol rdt2 .2 ve sadri funkcionalnost (redne brojeve)
kojom se reava sluaj dupliranih paketa.
Iz aspekta poiljaoca, ponovno slanje je lek za sve. Poiljalac ne zna da li je izgubljen paket
podataka, ili je izgubljen ACK, ili jednostavno isuvie kasni paket ili ACK. U svim tim
sluajevima reenje je isto: ponovno slanje. Da bi se primenio mehanizam ponovnog slanja
zasnovan na vremenu, bie potreban tajmer koji moe da upozori poiljaoca po isteku zadate
koliine vremena, Poiljalac e morati da bude u stanju da ( 1 ) pokrene tajmer kad god alje
paket (bilo daje re o prvom ili


ponovljenom slanju), (2) da reaguje na upozorenje od strane tajmera (odgovarajuim
aktivnostima) i (3) da zaustavi tajmer.
Postojanje duplih paketa koje pravi poiljalac i gubitak paketa (podataka ili ACK) takoe
uslonjava obradu ACK paketa koje prima poiljalac. Ako stigne ACK, pitanje je kako e
poiljalac znati da li gaje primalac poslao kao odgovor na poslednji upueni paket ili je to
zakasneli ACK koji predstavlja odgovor na neko ranije slanje nekog drugog paketa? Reenje ove
dileme je da se ACK paket proiri poljem potvrde. Kada primalac pravi ACK, on e u ovo polje
potvrde kopirati redni broj paketa podataka iji prijem potvruje. Ispitivanjem sadraja polja
potvrde poiljalac moe da utvrdi redni broj paketa koji je pozitivno potvren.
Na slici 3.15 prikazanje FSM poiljaoca za rdt3 . 0, protokol koji pouzdano prenosi podatke
preko kanala koji moe da oteti i gubi pakete. Na slici 3.16 prikazano je kako protokol radi bez
gubitka i kanjenja paketa, t kako postupa u sluaju gubitka paketa. Na slici 3.16 vreme se kree
od vrha dijagrama prema dnu; obratite panju na to da je vreme prijema paketa obavezno kasnije
od vremena slanja zbog kanjenja u prenosu i propagaciji. Na na slici 3.16, u ilustracijama odb.
do d., uglaste

214 214 214 214
POGLAVLJE 3 TRANSPORTNI SLOJ 3.4 PRINCIPI POUZDANOG TRANSFERA PODATAKA 119 119 119 119

zagrade na strani poiljaoca oznaavaju vreme na koje je postavljen tajmer i u kojem dolazi do
tajm-auta. Malo suptilniji aspekti ovog protokola ispituju se u vebama na kraju ovog poglavlja.
Poto redni brojevi paketa naizmenino imaju vrednost 0 i 1, protokol rdt3 . 0 se ponekad naziva
protokol naizmeninih bitova.
Sada smo sklopili kljune elemente protokola za transfer podataka. Kontrolni zbirovi, redni
brojevi, tajmeri i pozitivne i negativne potvrde prijema paketa imaju kljunu i neophodnu ulogu
u radu protokola. Dobili smo funkcionalan i pouzdan protokol za transfer podataka!

3.4.2 Cevovodni pouzdam protokoli za transfer podataka
Protokol rdt3 . 0 je funkcionalno ispravan protokol, ali malo je verovatno da bi iko bio
zadovoljan njegovim performansama, pogotovo u dananjim mreama velike brzine. Klju
problema performansi protokola rdt3 . 0 je injenica daje to protokol stani i ekaj".
Da biste shvatili do koje mere to stajanje i ekanje utie na performanse, pogledajmo
idealan sluaj sa dva krajnja raunara od kojih se jedan nalazi na Zapadnoj obali SAD, a drugi na
Istonoj obali, kao stoje prikazano na slici 3.17. Vreme potrebno za propagaciju tamo i nazad
brzinom svetlosti izmeu ova dva krajnja sistema, RTT priblino iznosi 30 milisekundi. Uzmimo
da su povezani kanalom sa brzinom prenosa R od 1 Gb/s (IO
9
bitova u sekundi). Sa veliinom
paketa I, od 1 000 bajtova (8 000 bitova) u svakom paketu, ukljuujui polja zaglavlja i podatke,
vreme potrebno da se paket zaista prenese linkom od 1 Gb/s je:
Na slici 3.18(a) prikazano je da sa naim protokolom stani i ekaj", ako poiljalac pone
slanje paketa u t = 0, tada e poslednji bit ui u kanal na strani poiljaoca za t - L/R = 8
mikrosekundi. Paket zatim putuje kroz celu zemlju za 15 milisekundi, s tim to poslednji bit
paketa stie primaocu za t = RTT/2 + L/R = 15,008 milisekundi.
Radi jednostavnosti, pretpostaviemo da su ACK paketi izuzetno mali (da bismo mogli
zanemariti vreme potrebno za njihov prenos) i da primalac moe da poalje ACK im primi
poslednji bit iz paketa podataka. U tom sluaju se ACK pojavljuje kod poiljaoca nakon / =
RTT+ L/R = 30,008 milisekundi. U tom trenutku poiljalac moe da pone sa prenosom sledee
poruke. Prema tome, od 30,008 milisekundi poiljalac se bavio slanjem samo tokom 0,008
milisekundi. Ako definiemo iskorienje poiljaoca (ili kanala) kao procenat vremena u kome
poiljalac zaista alje bitove u kanal, analiza slike 3.18(a) pokazuje da iskorienje protokola
stani i ekaj" nije ba za pohvalu. Ono iznosi:
To jest, poiljalac je uposlen samo 2,7 stotih delova jednog procenta vremena. Drugaije
posmatrano, poiljalac je bio u stanju" da za 30,008 milisekundi poalje samo 1 000 bajtova, to
znai efektivno samo 267 kb/s - mada je na raspolaganju imao link od 1 Gb/s! Zamislite
nesrenog menadera mree koji je upravo platio celo bogatstvo za link kapaciteta od 1 gigabita,
a kroz njega uspeva da postigne protok od samo 267 kb/s! Ovo je oigledan primer kako mreni
protokoli mogu da ogranie mogunosti koje prua hardverski sloj mree. Osim toga, zanemarili
smo vremena obrade protokola niih slojeva kod poiljaoca i primaoca, kao i kanjenje zbog
obrade i ekanja u redu do kojeg moe doi na bilo kojem usputnom ruteru izmeu poiljaoca i
primaoca. Da smo ukljuili i te efekte, ukupno kanjenje bilo bi jo vee a loe performanse jo
izraenije.
Reenje ovog konkretnog problema sa performansama je sasvim jednostavno: umesto da
radi po principu stani i ekaj", poiljaocu se dozvoljava da alje vie paketa bez ekanja na
potvrde, kako je prikazano na slici 3.17(b). Na slici 3.18(b) prikazano je da se iskorienje
poiljaoca u sutini utrostruava ako poiljalac moe da poalje tri paketa bez ekanja na
potvrde. Poto mnotvo paketa u tranzitu od poiljaoca do primaoca moe da se zamisli kao
popunjavanje cevi, ova tehnika se naziva cevovodnom obradom. Cevovodna obrada ima sledee
posledice na protokole pouzdanog transfera podataka:
Mora se poveati raspon rednih brojeva, poto svaki paket u tranzitu (ne raunajui ponovna
slanja) mora da ima jedinstven redni broj, a moe da postoji vie tranzitnih paketa koji jo
nisu potvreni.
Na otpremnoj i prijemnoj strani protokola moe se javiti potreba da se privremeno uva vie
paketa. U najmanju ruku, poiljalac e morati privremeno da uva pakete koji su poslati, a
da jo nije potvren njihov prijem. Privremeno uvanje primljenih paketa ponekad je
potrebno i kod primaoca, kao to emo opisati u daljem izlaganju.

3.4 - PRINCIPI POUZDANOG TRANSFERA PODATAKA 120 120 120 120

Potreban raspon rednih brojeva i zahtevi privremenog uvanja zavisie od naina na koji
protokol za transfer podataka reaguje na izgubljene i oteene pakete, i na pakete koji
previe kasne. Dva osnovna pristupa ispravljanju greaka cevovodne obrade moemo
nazvati: Vrati-se-za-N (Go-Back-N - GBN) i selektivno ponavljanje.
3.4.3 GBN
U GBN protokolu, poiljaocu se dozvoljava da poalje vie paketa (ako su dostupni) bez
ekanja na potvrdu, ali se ograniava maksimalan dozvoljeni broj N nepotvrenih paketa u cevi.
Na slici 3.19 prikazan je raspon rednih brojeva u GBN protokolu iz aspekta poiljaoca. Ako
definiemo base kao redni broj najstarijeg nepotvrenog paketa, a nextseqnum kao najmanji
neupotrebljeni redni broj (tj. redni broj sledeeg paketa za slanje), moemo uoiti etiri intervala
u rasponu rednih brojeva. Redni brojevi u intervalu [0,base-1] odgovaraju paketima koji su ve
preneti i prijem potvren. Interval [base,nextseqnum-l] odgovara paketima koji su poslati, ali
nisu jo potvreni. Redni brojevi u intervalu [nextseqnum, base+N-1 ] koriste se za pakete koji
mogu odmah da se alju im podaci stignu iz gornjeg sloja. Na kraju, redni brojevi vei ili
jednaki base+N ne mogu se koristiti sve dok ne stigne potvrda prijema za neki nepotvreni
paket koji se trenutno nalazi u cevi (konkretno, paket sa rednim brojem base).
Kako je nagoveteno na slici 3.19, raspon dozvoljenih rednih brojeva za otpremljene, a jo
nepotvrene pakete moe se smatrati prozorom" veliine nad rasponom rednih brojeva. Tokom
rada protokola, ovaj prozor klizi unapred nad prostorom rednih brojeva. Zbog toga, A^se esto
naziva veliinom prozora, a sam GBN protokol kliznog prozora. Moda se udite zato se
broj nepotvrenih paketa ograniava na neku vrednost N. Zato se ne bi dozvolio neogranien
broj takvih paketa? Videemo u odeljku 3.5 daje kontrola toka jedan od razloga da se poiljaocu
nametne granica. Drugi razlog emo ispitati u odeljku 3.7 gde se opisuje TCP kontrola
zaguenja,

i l 8 i l 8 i l 8 i l 8 POGLAVLJE 3 TRANSPORTNI SLOJ 3.4 . PRINCIPI POUZDANOG TRANSFERA PODATAKA 121 121 121 121

U praksi, redni broj paketa stavlja se u polje fiksne duine u zaglavlju paketa. Ako je k broj
bitova u polju rednog broja paketa, raspon rednih brojeva je [0,2*-!]. Sa konanim rasponom
rednih brojeva, sve raunanje vezano za redne brojeve mora se vriti aritmetikom po modulu 2
k
.
(To jest, prostor rednih brojeva moe se posma-trati kao prsten veliine 2
k
, gde za rednim
brojem 2
k
-l neposredno sledi redni broj 0.) Setite se da je protokol rdt3 . 0 imao redne brojeve od
1 bita i raspon rednih brojeva [0,1]. Nekoliko problema na kraju ovog poglavlja istrauje
posledice konanog raspona'rednih brojeva. Videemo u odeljku 3.5 da TCP ima 32-bitno polje
rednog broja gde TCP redni brojevi numeriu bajtove u toku, a ne pakete.
Na slikama 3.20 i 3.23 dat je proiren FSM opis poiljaoca i primaoca jednog GBN
protokola zasnovanog na ACK potvrdama i bez NAK potvrda. Ovaj FSM opis nazivamo
proirenim zato to smo dodali promenljive (slino promenljivama programskog jezika) za
brojeve base i nextseqnum i takoe dodati operacije nad tim promenljivama i uslovne aktivnosti
vezane za te promenljive. Primetiete da proirena FSM specifikacija poinje donekle da lii na
specifikaciju u programskom jeziku. [Bochman 1984] sadri izvrstan pregled dodatnih proirenja
FSM tehnika kao i drugih tehnika za defmisanje protokola zasnovanih na programskim jezicima.
GBN poiljalac mora da reaguje na tri vrste dogaaja:
Poziv odozgo. Kada se odozgo pozove rdt__send ( ) , poiljalac prvo proverava da li je
prozor pun, tj. da li postoji N nepotvrenih paketa. Ako prozor nije pun, paket se pravi i
alje, i promenljive se auriraju na odgovarajui nain. Ako je prozor pun, poiljalac
jednostavno vraa podatke gornjem sloju, to implicitno znai da je prozor pun. Pretpostavka
je da bi gornji sloj trebalo ponovo da pokua kasnije. U stvarnim implementacijama,
verovatnije je da e poiljalac sauvati te podatke u privremenoj memoriji (nee ih slati
odmah), ili moda ima mehanizam sinhronizacije (na primer, semafor ili zastavicu) koji
gornjem sloju dozvoljava da pozove rdt_send ( ) samo ako prozor nije pun.
Prijem ACK-a. U naem GBN protokolu, potvrda za paket sa rednim brojem n smatrae se
kumulativnom potvrdom, koja oznaava da su svi paketi sa rednim brojevima manjim od h i
jednakim rt pravilno primljeni kod primaoca. Vratiemo se uskoro ovom pitanju prilikom
opisa prijemne strane GBN protokola.
Dogaaj lajm-aui. Ime GBN protokola potie od ponaanja poiljaoca u sluaju izgubljenih
paketa ili paketa koji previe kasne. Kao i u protokolu stani i ekaj", koristie se tajmer za
oporavak od gubitka paketa sa podacima ili paketa sa potvrdom. Ako nastupi tajm-aut,
poiljalac ponovo alje sve pakete koji su prethodno poslati, a nisu jo potvreni. Na
poiljalac na slici 3.20 koristi samo jedan tajmer, koji moemo shvatiti kao tajmer najstarijeg
predatog a jo nepotvrenog paketa. Ako stigne ACK, a ima jo predatih i nepotvrenih
paketa, tajmer se ponovo pokree. Ako nema vie nepotvrenih paketa, tajmer se zaustavlja.
Aktivnosti primaoca u GBN protokolu takoe su jednostavne. Ako se paket sa rednim
brojem n primi ispravno i pravim redosledom (tj. poslednji podaci isporueni gornjem sloju bili
su iz paketa sa rednim brojem >i-l), primalac alje ACK za

3.4 . PRINCIPI POUZDANOG TRANSFERA PODATAKA 221 221 221 221

paket sa rednim brojem n i predaje podatke iz paketa gornjem sloju. U svim ostalim sluajevima,
primalac odbacuje paketi ponovo alje ACK za poslednji paket primljen ispravnim redosledom.
Obratite panju na to da poto se paketi isporuuju gornjem sloju jedan po jedan, ako je paket k
primljen i isporuen, to znai i da su svi paketi sa rednim brojevima manjim od k takoe isporueni.
Prema tome, korienje kumulativnih potvrda je prirodno u GBN protokolu.
U naem GBN protokolu, primalac odbacuje pakete koji ne idu ispravnim redosledom. Mada
izgleda glupo i rasipno da se odbaci paket koji je pravilno primljen (iako nije po redu), za takav
postupak postoji opravdanje. Ne zaboravite da primalac mora redom da predaje pakete gornjem
sloju. Pretpostavimo sada da se oekuje paket n, a stie n+\. Poto podaci moraju da se isporue po
redu, primalac bi mogao da sauva paket M MM M+1 i isporui ga gornjem sloju posle prijema i isporuke
paketa . Meutim, ako se paket n izgubio, i on i paket n+l bie kasnije ponovo poslati zbog GBN
pravila ponovnog slanja na strani poiljaoca. Prema tome, primalac moe jednostavno da odbaci
paket n+l. Prednost ovakvog pristupa je jednostavnije privremeno uvanje kod primaoca - primalac
ne mora privremeno da uva nijedan paket izvan redosteda. Prema tome, dok poiljalac mora da
odrava gornju i donju granicu svog prozora i poloaj nextseqnum unutar tog prozora, jedino to
primalac mora da odrava je redni broj sledeeg oekivanog paketa. Ova vrednost uva se u
promenljivoj expectedseqnum prikazanoj u FSM opisu primaoca na slici 3.21. Naravno, nedostatak
odbacivanja ispravno primljenog paketa jeste da i ponovno poslati paket moe da se izgubi ili oteti,
to e zahtevati jo ponovnih slanja.
Na slici 3.22 prikazanje rad GBN protokola za prozor veliine 4 paketa. Zbog ogranienja ove
veliine prozora, poiljalac alje pakete od 0 do 3, ali zatim mora da eka potvrdu prijema jednog ili
vie tih paketa, da bi mogao da nastavi sa slanjem. Sa prijemom svakog sledeeg ACK-a (na primer,
ACKO i ACK1), prozor klizi una-pred i poiljalac moe da prenese nove pakete (pkt4 odnosno pkt5).
Na strani primaoca, paket 2 je izgubljen i zato se paketi 3,4 i 5 odbacuju, jer su van redosleda.
Na kraju opisa GBN protokola treba primetiti da bi implementacija ovog protokola u familiji
protokola verovatno imala strukturu slinu proirenom FSM opisu iz slike 3.20. Implementacija bi
takoe verovatno bila u obliku razliitih procedura za implementiranje aktivnosti koje treba preduzeti
povodom razliitih dogaaja koji nastupaju. U takvom programiranju zasnovanom na
dogaajima razliite procedure se pozivaju (aktiviraju) bilo iz drugih procedura u familiji protokola ili
kao rezultat prekida. Kod poiljaoca, ti dogaaji bi bili (1) poziv entiteta iz gornjeg sloja da se aktivira
rdt_send (), (2) tajmerski prekid i (3) poziv iz donjeg sloja da se pozove rdt_rcv () kada stigne paket.
Programerski zadaci na kraju poglavlja dae vam priliku da implementirate te rutine u simuliranom,
ali realnom mrenom okruenju.
Ovde primeujemo da GBN protokol obuhvata skoro sve tehnike na koje emo naii u
razmatranju komponenti pouzdanog transfera podataka u protokolu TCP, u odeljku 3.5. U ove
tehnike spadaju upotreba rednih brojeva, kumulativnih potvrda, kontrolnih zbirova i ponovnog slanja
zbog tajm-auta.
3.4.4 Selektivno ponavljanje
GBN protokol dozvoljava poiljaocu da potencijalno popuni cevi" sa slike 3.17 paketima, i
tako izbegne probleme nedovoljnog korienja kanala koje smo spominjali u vezi sa protokolom
stani i ekaj". Meutim, ima situacija u kojima i sam GBN protokol ima probleme sa performansama.
Konkretno, kada imamo veliku irinu prozora i kanjenje zbog propusnog opsega, u cevi moe da se
nae mnogo paketa, Jedna greka u paketu moe da dovede do toga da GBN ponovo alje velik broj
paketa, od kojih mnoge nepotrebno. Sa poveanjem verovatnoe za nastajanje

1222 POGLAVLJE 3 TRANSPORTNI SLOJ
3.4 PRINCIPI POUZDANOG TRANSFERA PODATAKA 123

greaka u kanalu, cev moe da se zagui tim nepotrebnim ponovnim slanjima. Zamislite da, u
primeru sa diktiranjem poruke, za svaku nerazgovetnu re treba ponoviti okolnih hiljadu rei
(ako je, na primer, veliina prozora hiljadu rei). Diktiranje bi se usporilo zbog toliko
ponavljanja.
Kao to ime govori, protokoli sa selektivnim ponavljanjem (selective repeai, SR)
izbegavaju nepotrebna dodatna slanja tako to poiljalac ponovo alje samo one pakete za koje
sumnja da su pogreno primljeni (tj. izgubljeni ili oteeni). Da bi se omoguilo pojedinano
ponovno slanje prema potrebi, primalac mora pojedinano da potvruje ispravno primljene
pakete. Veliina prozora A' i ovde se koristi da bi se ograniio broj zaostalih nepotvrenih
paketa u cevi. Meutim, za razliku od GBN-a, poiljalac je ve dobio ACK za neke pakete u
prozoru. Na slici 3.23 prikazanje prostor rednih brojeva iz aspekta SR poiljaoca. Na slici 3.24
opisane su razliite aktivnosti koje preduzima SR poiljalac.
SR primalac e potvrditi ispravno primljeni paket bez obzira na to da li je stigao u
pravilnom redosledu. Paketi izvan redosleda se uvaju dok ne stignu nedostajui
. 1. Podaci'primljeni odozgo. Kada se odozgo prime; podaci, SR.poiljalaQprb-
veravasledcislobodni redni broj a paket; Akoje^ .
poiij'aoca,:pbdacj'se.palcuju:i alju; inae se privremeno
1
uVaju ili'vraaju
. gornjem, sloj u'radi kasnijeg slanja'kao u GBN-u. : " \;? ':
- 2. Tajmaut. tajmeri se koriste kao zatita odgubitJa paketa; Meut^ .
paket sada.mora da iina vlastiti; logiki tajmer,.pbt'6-e "se prilikom taj'mauta
slati samo jedan paket. Za imitiranje rada vie logikih lajmera.moe e'kori-
titi samo jedan hardverski tajmer [Varghes'e 1997]. " \
3-. Primljen je A CK. Ako stigne ACK, Sli poiljalac oznaava paket kao prim- . Ijen, ukoliko
se oh nalazi u prozoru.Ukoliko je redni broj paketa jednak send_base, poetak prozora se
pomera unapred do ncpotvrdehog paketa' ' sa najmanjim rednim brojem. Ako se
prilikom.ppmeranja prozora otkriju . neposlati paketi iji se redni brojevi sada nalaze u
prozoru.ti paketi.se alju..

Slika 3.24 Slika 3.24 Slika 3.24 Slika 3.24 Dogaaji i aktivnosti SR poiljaoca

paketi (tj. paketi sa niim rednim brojevima), a tada se gornjem sloju redom isporuuje grupa
paketa. Na slici 3.25 navedene su razliite aktivnosti koje preduzima SR primalac. Na slici 3.26
dat je primer SR rada u sluaju izgubljenih paketa. Obratite panju na to da na slici 3.26
primalac prvo smeta pakete 3, 4 i 5 u privremenu memoriju , pa ih isporuuje gornjem sloju
zajedno sa paketom 2 kada paket 2 konano stigne.
Vano je primetiti da u koraku 2 na slici 3.25 primalac ponovo potvruje (ume-sto da
zanemaruje) ranije primljene pakete sa rednim brojevima manjim od trenutne osnove prozora.
Budite sigurni daje ovo ponovno potvrivanje zaista potrebno. Ako uzmemo prostore rednih
brojeva poiljaoca i primaoca na slici 3.23, kad ne bi bilo ACK potvrde za paket send_base koju
primalac alje poiljaocu, poiljalac bi kasnije ponovo poslao paket send_base, mada je jasno
(nama, ali ne i poiljaocu!) daje primalac ve dobio taj paket. Kada primalac ne bi potvrdio taj
paket, prozor poiljaoca ne bi se nikad pomerio! Ovaj primer ilustruje jedan vaan aspekt SR
protokola (kao i mnogih drugih protokola). Poiljalac i primalac nee uvek imati identino
saznanje o tome staje pravilno primljeno, a ta nije. Kod SR protokola, ovo znai da prozori
poiljaoca i primaoca nee uvek biti identini.
Neusklaenost izmeu prozora poiljaoca i primaoca ima znaajne posledice u situaciji sa
konanim rasponom rednih brojeva, Pogledajte ta bi se dogodilo, na primer, sa konanim
rasponom od 4 redna broja (0, 1, 2, 3) i veliinom prozora 3. Pretpostavimo da su poslati paketi
od 0 do 2 pravilno primljeni, i da ih je primalac potvrdio. U tom trenutku se prozor primaoca
nalazi na etvrtom, petom i estom paketu iji su redni brojevi 3, 0 i 1. Uzmimo sada dva
scenarija. U prvom scenariju, prikazanom na slici 3.27(a), ACK-ovi za prva tri paketa su se
izgubili i poiljalac

124 124 124 124 POGLAVUE 3 TRANSPORTNI SLOJ 3.4 . PRINCIPI POUZDANOG TRANSFERA PODATAKA 124 124 124 124! !! !

ih ponovo alje. Primalac, znai, dobija paket sa rednim brojem 0 - kopiju prvog poslatog paketa.
U drugom scenariju prikazanom na slici 3.27(b), ACK-ovi za prva tri paketa su svi pravilno
isporueni. Poiljalac, znai, pomera svoj prozor unapred i alje etvrti, peti i esti paket sa
rednim brojevima 3, 0 i 1. Paket sa rednim brojem 3 se gubi, ali paket sa rednim brojem 0 stie -
paket koji sadri nove podatke.
Na slici 3.27 razmotriemo situaciju iz aspekta primaoca pred kojim se nalazi virtuelna
zavesa, poto on ne moe da vidi" ta se deava na strani poiljaoca. Primalac jedino vidi
redosled poruka koje prima iz kanala i koje alje u kanal. Iz njegovog aspekta, dva scenarija
prikazana na slici 3.27 su identina. Ne postoji nain da primalac razlikuje ponovno slanje prvog
paketa od prvog slanja petog paketa. Jasno je da veliina prozora, koja je za jedan manja od
veliine prostora rednih brojeva, rfije dobra. Kolika bi trebalo da bude veliina prozora? U
jednom problemu na kraju poglavlja imaete zadatak da pokaete da za SR protokole veliina
prozora mora biti manja ili jednaka polovini veliine prostora rednih brojeva.
Ovim zakljuujemo opis protokola za pouzdani transfer podataka. Obradili smo dosta i
uveli niz mehanizama kojima se obezbeuje pouzdani transfer podataka. U tabeli 3.1 nalazi se
rekapitulacija ovih mehanizama. Poto ste videli njihovu pri-menu i moete da razumete celinu,
predlaemo da ponovo pregledate ovaj odeljak da biste videli kako smo ove mehanizme
postupno dodavali da bismo objasnili sve sloenije (i realnije) modele kanala koji povezuju
poiljaoca i primaoca, ili poboljane performanse protokola.
Zakljuimo na opis protokola za pouzdani transfer podataka razmatranjem jedine preostale
pretpostavke za model kanala preko koga se vri prenos. Setite se da smo pretpostavili da se
unutar kanala izmeu poiljaoca i primaoca paketima ne moe menjati redosled. To je uglavnom
realna pretpostavka kada su poiljalac i primalac povezani jednim jedinim fizikim kablom.
Meutim, kada je kanal" u stvari mrea, moe doi do izmenjenog redosleda paketa. Jedna
manifestacija izmenje-nog redosleda paketa je pojava starog primerka paketa sa rednim brojem
ili brojem potvrde x, iako prozori poilj aoca i primaoca ne sadre x. Ako ima promene u redo-

1226 POGLAVLJE 125 - TRANSPORTNI SLOJ
3.4 . PRINCIPI POUZDANOG TRANSFERA PODATAKA 125

sledu paketa, moe se smatrati da kana! privremeno smeta pakete u privremenu memoriju i
spontano ih emituje u bilo kom kasnijem trenutku. Poto redni brojevi mogu da se koriste vie puta,
potrebno je posebno paziti na takve duplikate paketa. U praksi se obino kao zatita koristi zabrana
da se redni broj ponovo upotrebi sve dok poiljalac ne bude siguran" da u mrei nema vie
nijednog ranije posla-tog paketa sa rednim brojem x. To se postie pretpostavkom da paket ne
moe da ivi" u mrei'due od nekog fiksnog maksimalnog vremena. U TCP proirenjima za
mree velike brzine [RFC 1323] prihvaen je maksimalni ivotni vek paketa od priblino 3 minuta, U
knjizi [Sunshine 1978] opisan je metod korienja rednih brojeva na takav nain da se potpuno
izbegmi problemi izmenjenog redosleda.

228 228 228 228 POGLAVLJE 3 TRANSPORTNI SLOJ 3.5 TRANSPORT SA KONEKCIJOM: TCP 229 229 229 229
3. 5 Transport sa konekcijom: TCP
Poto smo upoznali osnovne principe pouzdanog transfera podataka, prei emo na TCP -
Internetov protokol transportnog sloja sa konekcijom. U ovom odeljku vide-emo da se za
obezbeenje pouzdanog transfera podataka TCP oslanja na mnoge osnovne principe koje smo
opisali u prethodnom odeljku, ukljuujui otkrivanje greaka, ponovno slanje, kumulativne
potvrde, tajmere i polja u zaglavlju za redne brojeve paketa i redne brojeve potvrda. TCP je
definisan u dokumentima RFC 793, RFC 1122, RFC 1323, RFC 2018 i RFC 2581.

3.5.1 TCP konekcija
Za TCP se kae da je sa konekcijom zato to pre poetka slanja podataka iz jedne aplikacije u
drugu, ta dva procesa moraju prvo da se upoznaju" - tj. moraju jedan drugom da poalju neke
uvodne segmente da bi se uspostavili parametri transfera podataka koji sledi. Prilikom
uspostavljanja TCP konekcije obe strane e postaviti poetne vrednosti za mnoge promenljive
TCP stanja (nekoliko njih opisujemo u ovom odeljku i u odeljku 3.7) koje se odnose na TCP
konekciju.
TCP konekcija" nije TDM ili FDM vod sa kraja na kraj kakvi postoje u mrei sa
komutacijom vodova. Ona takode nije ni virtuelno kolo (proitati poglavlje 1), poto se stanje
konekcije u potpunosti uva u krajnjim sistemima. Protokol TCP se izvrava samo u krajnjim
sistemima, a ne na usputnim elementima mree (ruterima i mostovima). Usputni elementi mree
ne odravaju stanje TCP konekcije. U sutini, usputni ruteri uopte nisu svesni TCP konekcije;
oni vide samo datagrame.
TCP konekcija obezbeduje transfer podataka u punom dupleksu. Ako postoji TCP
konekcija izmeu procesa A najednom raunam i procesa B na drugom raunam, tada podaci iz
aplikacionog sloja mogu da teku od A do B a u isto vreme i od B do A. TCP konekcija je takode
uvek od take o take tj. izmeu pojedinanog poiljaoca i pojedinanog primaoca. Takozvano
vieznano rutiranje" (proitati odeljak 4.7>- transfer podataka od jednog poiljaoca do vie
primalaca u istoj operaciji slanja - nije mogua sa TCP-om. Za TCP su dva raunara drutvo, a
trei je viak!
Pogledajmo sada kako se uspostavlja TCP konekcija. Uzmimo da proces koji se izvrava
najednom raunaru eli da uspostavi konekciju sa drugim procesom na drugom raunam.
Verovatno se seate da proces koji pokree konekciju nazivamo klijentskim procesom, a dmgi
proces serverskim. Klijentski aplikacioni proces prvo obavetava klijentski transportni sloj da
eli da uspostavi konekciju sa procesom na serveru. U odeljku 2.6 nauili smo da Java klijentski
program to postie izdavanjem komande:
Socket clientSocket = new Socket("hostname", portNumber);
gde je hostname ime servera, a portNumber oznaava proces na serveru. Transportni sloj u
klijentu zatim prelazi na uspostavljanje TCP konekcije sa TCP-om na serveru. Na kraju ovog
odeljka opisaemo relativno detaljno postupak uspostavljanja konekcije. Za sada je dovoljno da
znamo da klijent prvo alje poseban TCP segment; server odgovara drugim posebnim TCP
segmentom; a na kraju klijent ponovo odgovara treim posebnim segmentom. Prva dva
segmenta ne sadre nikakve korisne podatke", tj. nikakve podatke aplikacijskog sloja; trei
segment ve moe da sadri korisne podatke. Poto se medu raunarima razmenjuju tri
segmenta, ovaj postupak uspostavljanja konekcije esto se naziva sinhronizovanjem u tri
koraka.
Poto se TCP konekcija uspostavi, dva aplikaciona procesa mogu jedan drugom da alju
podatke. Razmotrimo slanje podataka od klijentskog procesa serverskom procesu. Klijentski
proces alje tok podataka kroz.soket (vrata procesa), kao to je opisano u odeljku 2.6. Poto
podaci prou kroz ta vrata, oni se nalaze u rukama TCP-a koji se izvrava na klijentu. Kao stoje
prikazano na slici 3.28, TCP usmerava ove podatke u otpremnu privremenu memoriju te
konekcije, a to je jedna od privremenih memorija koje se rezerviu tokom poetnog
sinhrontzovanja u tri koraka. S vremena na vreme, TCP e zahvatati" delove podataka iz
otpremne privremene memorije. Zanimljivo je da u TCP specifikaciji [RFC 793] nema strogog
pravila
KRATAK OSVRT
VINTON SERF, ROBERT KAN I TCP/IP VINTON SERF, ROBERT KAN I TCP/IP VINTON SERF, ROBERT KAN I TCP/IP VINTON SERF, ROBERT KAN I TCP/IP
Poetkom sedamdesetih godina poele su da se mnoe mree sa komutiranjem paketa, od
kojih je samo jedna bila ARPAnet - pretea Interneta. Svaka od ovih mrea imala je vlastiti
protokol. Dva istraivaa, Vinton Serf i Robert Kan, uvidela su znaaj meusobnog povezivanja
Hh mrea i izmislila meumreni protokol po imenu TCP/IP io je skraenica za Transmission
Contro! Protocol/lnternet Protocol. Mada su Serf i Kan na poetku posmatrali taj protokol kao
celinu, on je kasnije podeljen na dva dela, TCP i IP, koji funkcioniu odvojeno. SerF i Kan
objavili su izvetaj o protokolu TCP/IP u maju 1974 u IEEE Transaclions on Communications
Technology.
Protokol TCP/IP koji predstavlja osnovu dananjeg Interneta, smiljen je pre PC-ja i radnih
stanica, pre irenja Etherneta i drugih tehnologija za lokalne mree, pre Weba, pre protoka
audio signala u realnom vremenu i pre askanja. SerF i Kan uvideli su potrebu za mrenim
protokolom koji sa jedne strane obezbeduje iroku podrku za primene koje e se tek definisati,
a s druge strane omoguava zajedniki rad svih raunara i protokola u sloju veze.

3.127 . TRANSPORT SA KONEKCIJOM: TCP 127 127 127 127

o lome kada bi TCP trebalo da poalje podatke iz privremene memorije; kae se da TCP treba da
alje podatke u segmentima prema vlastitom nahoenju". Maksimalna koliina podataka koja moe
da se zahvati i stavi u jedan segment ograniena je vrednosu promenljive MSS (Maximum Segment
Sie). MSS zavisi od TCP implementacije (koja zavisi od operativnog sistema) i esto moe da se
konfigu-rie; uobiajene vrednosti su 1 460 bajtova, 536 bajtova i 512 bajtova. (Ove veliine
segmenata esto se biraju tako da se izbegne IP fragmentiranje koje emo opisati u sledeem
poglavlju.) Obratite panju na to daje MSS maksimalna koliina podataka aplikacionog sloja u
segmentu, a ne maksimalna veliina TCP segmenta gde su ukljuena i zaglavlja. (Ovi nazivi malo
zbunjuju, ali moramo ih prihvatiti jer su ve veoma ustaljeni.)
TCP dopunjava svaki komad klijentskih podataka jednim TCP zaglavljem i tako pravi TCP
segmente. Segmenti se predaju nanie mrenom sloju gde se pojedinano enkapsuliraju u IP
datagrame mrenog sloja. IP datagrami se zatim alju u ' mreu. FCada TCP na drugom kraju primi
segment, podaci segmenta stavljaju se u prijemnu privremenu memoriju TCP konekcije, kao stoje
prikazano na slici 3.28. Aplikacija ita tok podataka iz ove privremene memorije. Svaka strana
konekcije ima svoju otpremnu i svoju prijemnu privremenu memoriju. (Predlaemo itaocu da pogleda
onlajn aplet kontrole toka na adresi http://www.awi.com/kurose-ross koji sadri animaciju otpremne i
prijemne privremene memorije.)
Iz ovog opisa vidimo da se TCP konekcija sastoji od privremene memorije, pro-menljivih i
soketa konekcije za proces najednom raunaru i druge grupe privremene memorije, promenljivih i
soketa konekcije za proces na drugom raunaru. Kao to je ranije spomenuto, u mreriim elementima
(ruterima, komutatorima i repetitorima) konekciji se ne dodeljuju nikakve privremene memorije niti
promenljive.
3.5.2 Struktura TCP segmenta
Poto smo ukratko pogledali TCP konekciju, prouimo sada strukturu TCP segmenta. TCP segment
se sastoji od vie polja zaglavlja i jednog polja podataka. Polje podataka sadri jedan komad
aplikacijskih podataka. Kao to je ve pomenuto, maksimalna veliina polja podataka u segmentu je
MSS. Kada TCP alje veliku datoteku, kao to je slika sa neke veb stranice, on obino deli datoteku
na komade veliine MSS (osim poslednjeg komada, koji e esto bili manji od parametra MSS).
Interaktivne aplikacije, meutim, esto prenose komade podataka koji su manji od parametra MSS;
na primer, u aplikacijama za daljinsko prijavljivanje kao stoje Telnet, polje podataka u TCP
segmentu esto je dugako samo 1 bajt, Poto je TCP zaglavlje obino dugako 20 bajtova (12
bajtova vie od UDP zaglavlja), segmenti koje alje Telnet ponekad su dugaki samo 21 bajt.
Na slici 3.29 prikazana je struktura TCP segmenta. Kao i kod UDP segmenta, zaglavlje sadri
broj izvornog i odredinog porta, koji se koriste za multipleksira-nje i demultipleksiranje podataka iz
aplikacija gornjeg sloja i prema njima. Takoe, kao i u UDP segmentima, zaglavlje sadri i polje
kontrolnog zbira. Zaglavlje TCP segmenta sadri jo i sleea polja:
32-bitno polje rednog broja i 32-bitno polje broja potvrde koje TCP poiljalac i primalac koriste
za implementiranje usluge pouzdanog transfera podataka to emo kasnije opisali.

232 232 232 232 POGLAVLJE 3 TRANSPORTNI SLOJ 3. 1 28 . TRANSPORT SA KONEKCIJOM: TCP 233 233 233 233

16-bitno polje prijemnog prozora koristi se za kontrolu toka. Uskoro emo videti da se ono
koristi da bi se saoptilo koliko bajtova primalac pristaje da prihvati.
4-bitno polje duine zaglavlja navodi duinu TCP zaglavlja u 32-bitnim recima. TCP
zaglavlje moe biti promenljive duine zbog polja TCP opcija koje emo kasnije opisati.
(Obino je polje opcija prazno, pa je duina uobiajenog TCP zaglavlja jednaka 20 bajtova.)
Opciono polje opcija promenljive duine koje se koristi kada poiljalac i primalac
pregovaraju o maksimalnoj duini segmenta (MSS) ili kao faktor za podeavanje prozora
koji se koristi u mreama velike brzine. Definisana je takoe i opcija vremenskog peata.
Vie detalja moete nai u dokumentima RFC 845 i RFC 1323.
Polje oznaka sadri 6 bitova. Bit ACK, ukoliko je postavljen, oznaava da je vrednost broja
potvrde vaea i daje u pitanju segment potvrde. Bitovi RST, SYN i FIN koriste se prilikom
uspostavljanja i prekidanja konekcije to emo opisati na kraju ovog odeljka. Kada je bit PSH
postavljen, to znai da bi primalac trebalo istog trenutka da prosledi podatke gornjem sloju.
Na kraju, bit URG se koristi da bi se oznailo da u ovom segmentu ima podataka koje je
gornji sloj na strani poiljaoca oznaio kao hitne" (urgentne). Lokacija poslednjeg bajta ovih
hitnih podataka odreena je 16-bitnim poljem pokazivaa hitnih podataka. TCP mora da
obavesti entitet gornjeg sloja na prijemnoj strani da postoje hitni podaci i da mu preda
pokaziva na kraj tih hitnih podataka. (U praksi se PSH, URG i pokaziva hitnih podataka ne
koriste. Meutim, ta polja pominjemo da bi opis bio potpun.)

Redni brojevi i brojevi potvrda
Dva najvanija polja u zaglavlju TCP segmenta su redni broj i broj potvrde. Ta polja
predstavljaju bitan deo TCP usluge pouzdanog transfera podataka. Ali, pre nego to opiemo na
koji nain ova polja obezbeuju pouzdan transfer podataka, prvo emo objasniti ta tano TCP
stavlja u njih.
TCP posmatra podatke kao nestrukturisan, ali ureen tok bajtova. TCP tako i koristi redne
brojeve, pa se oni odnose na tok prenetih bajtova, a ne na niz pre-netih segmenata. Redni broj za
segment je, prema tome, redni broj prvog bajta u segmentu unutar toka bajtova. Pogledajmo
jedan primer. Uzmimo da proces na raunaru A eli preko TCP konekcije da poalje tok
podataka u proces na raunaru B. TCP u raunaru A implicitno e numerisati svaki bajt u toku
podataka. Uzmimo da se tok podataka sastoji od jedne datoteke koja ima 500 000 bajtova, da
MSS iznosi 1 000 bajtova, a da prvi bajt toka podataka ima redni broj 0. Kao to je prikazano na
slici 3.30, TCP od tog toka podataka pravi 500 segmenata. Prvom segmentu dodeljuje se redni
broj 0, drugom segmentu redni broj I 000, treem redni broj 2 000
i tako dalje. Redni broj se stavlja u polje rednog broja u zaglavlju odgovarajueg TCP segmenta.
Razmotrimo sada brojeve potvrda. Oni su neto sloeniji od rednih brojeva, Znate da je
TCP potpuni dupleks, tako da raunar A moe da prima podatke od raunara B u isto vreme dok
i sam alje podatke raunaru B (u okviru iste TCP konekcije). Svaki segment koji stigne od
raunara B ima redni broj za podatke koji se alju od B prema A. Broj potvrde koji raunar A
stavlja u svoj segment je redni broj sledeeg bajta koji oekuje od raunara B. Dobro je
pogledati nekoliko primera da bi se shvatilo ta se ovde dogaa. Uzmimo daje raunar A primio
od raunara B sve bajtove numerisane od 0 do 535 i uzmimo da se sprema da poalje jedan
segment raunaru B. Raunar A oekuje bajt 536 i sve naredne bajtove iz toka podataka rau-
nara B. Zato raunar A stavlja broj 536 u polje za broj potvrde sledeeg segmenta koji e poslati
raunaru B.
Kao drugi primer, uzmimo da je raunar A primio od raunara B jedan segment koji sadri
bajtove od 0 do 535 i drugi segment koji sadri bajtove od 900 do 1 000. Iz nekog razloga
raunar A jo nije primio bajtove 536 do 899. U ovom primeru, raunar A i dalje eka bajt 536
(i sledee) da bi ponovo napravio tok podataka iz raunara B. Prema tome, sledei segment koji
raunar A alje raunaru B imae u polju za broj potvrde vrednost 536. Poto TCP potvruje
samo bajtove do prvog nedostajueg bajta u toku, za TCP se kae da daje kumulativne potvrde.
U ovom poslednjem primeru pojavilo se jedno vano, ali suptilno pitanje. Raunar A je
primio trei segment (bajtove 900 do I 000) pre nego stoje primio drugi segment (bajtove 536 do
899). Prema tome, trei segment je stigao van redosleda. Suptilno pitanje glasi: ta e raunar
uraditi kada u TCP konekciji primi segment van redosleda? Zanimljivo je da RFC dokumenti za
TCP po ovom pitanju ne definiu nikakva pravila i preputaju odluku programerima TCP
implementacije. U osnovi postoje dve mogunosti: ili e (1) primalac odmah odbaciti segmente
primljene van redosleda (kao to smo rekli, to moe da pojednostavi dizajn primaoca) ili e (2)
primalac zadrati bajtove primljene van redosleda i ekati da nedostajui bajtovi pristignu i
popune praznine. Jasno je daje druga varijanta efikasnija to se tie propusnog opsega mree i
zato je prihvaena u praksi.

234 234 234 234 POGLAVUE 3 TRANSPORTNI SLOJ 3.5 TRANSPORT SA KONEKCIJOM: TCP
235 235 235 235

Na slici 3.30 pretpostavili smo daje poetni redni broj jednak 0. U praksi, obe sirane TCP
konekcije biraju sluajni poetni redni broj. To se radi da bi se na minimum svela verovatnoa
da se segment iz neke ranije, ve prekinute, konekcije izmeu dva raunara pogreno ne shvati
kao vaei segment u kasnijoj konekciji ta ista dva raunara (gde se sluajno koriste isti brojevi
portova kao u staroj konekciji) [Sunshine 1978],

Telnet: Kratak osvrt na redne brojeve i brojeve potvrda
Telnet, definisan u RFC-u 854, je popularan protokol aplikacijskog sloja koji se koristi za
daljinsko prijavljivanje. On se izvrava preko TCP-a i projektovan je za rad izmeu bilo koja dva
raunara. Za razliku od aplikacija za paketski prenos podataka opisanih u poglavlju 2, Telnet je
interaktivna aplikacija. Ovde emo opisati jedan primer Telneta, poto on lepo ilustruje redne
brojeve i brojeve potvrda u TCP-u. Napominjemo da mnogi korisnici sada radije koriste protokol
ssh umesto Telneta, poto podaci koji se alju preko Telnet konekcije (ukljuujui i lozinke!)
nisu ifro-vani, zbog ega je Telnet osetljiv na prislukivanje (to emo opisati u odeljku 8.7).
Uzmimo da raunar A pokrene Telnet sesiju sa raunarom B. Poto raunar A pokree
sesiju on e se smatrati klijentom, a raunar B serverom. Svaki znak koji korisnik otkuca (kod
klijenta) poslae se udaljenom raunaru; udaljeni raunar e vratiti kopiju znaka i ona e se
prikazati na ekranu korisnika Telneta. Ovaj vraeni eho" slui kao potvrda da su znakovi koje
korisnik Telneta vidi ve primljeni i obraeni na udaljenoj lokaciji. Svaki znak tako dva puta
prelazi celu mreu od trenutka kada korisnik pritisne taster do trenutka kada se znak pojavi na
njegovom monitoru.
Uzmimo sada situaciju da korisnik upie jedno jedino slovo, ,,C", a zatim ode na kafu.
Pogledajmo TCP segmente koji se alju izmeu klijenta i servera. Kao to se vidi na slici 3.31,
mi pretpostavljamo daje poetni redni broj kod klijenta 42, a kod servera 79. Znate da redni broj
u segmentu predstavlja redni broj prvog bajla u polju podataka. Prema tome, prvi segment koji
klijent poalje imae redni broj 42; prvi segment koji poalje server imae redni broj 79. Znate
daje broj potvrde redni broj sledeeg bajta podataka koji raunar oekuje. Poto se uspostavi
TCP konekcija, a pre slanja podataka, klijent oekuje bajt 79, a server oekuje bajt 42.
Kao to je prikazano na slici 3.31, alju se tri segmenta. Prvi segment se alje od klijenta ka
serveru, i u polju podataka sadri jednobajtni ASCII prikaz slova ,,C". Ovaj prvi segment sadri
jo i vrednost 42 u polju rednog broja, kao to smo upravo opisali. Isto tako, poto klijent jo
nije primio nikakve podatke od servera, ovaj prvi segment e u polju broja potvrde imati 79.
Drugi segment ide od servera ka klijentu. On ima dvostruku svrhu. Prvo, on slui kao
potvrda podataka koje je server primio. Stavljanjem 43 u polje potvrde, server obavetava
klijenta da je uspeno primio sve do bajta 42 i da sada oekuje bajtove od 43 na dalje. Druga
svrha ovog segmenta je da se vrati nazad slovo ,,C". Prema tome, drugi segment ima u polju
podataka ASCII prikaz slova ,,C". Ovaj drugi segment nosi redni broj 79, poetni redni broj toka
podataka od servera ka
klijentu u ovoj TCP konekciji, postoje u pitanju prvi bajt podataka koji alje server. Obratite
panju na to da se potvrda podataka koji su stigli od klijenta ka serveru alje u istom segmentu
koji prenosi podatke od servera ka klijentu; za takvu potvrdu kaemo da se lepuje na segmentu
podataka od servera ka klijentu.
Trei segment se alje od klijenta ka serveru. Njegova jedina svrha je da se potvrde podaci
primljeni od servera. (Verovatno se seate daje drugi segment sadravao podatke ~ slovo ,,C" -
od servera ka klijentu.) Trei segment ima prazno polje podataka (tj. potvrda se ne lepuje ni na
kakvim podacima od klijenta ka serveru). Segment sadri 80 u polju broja potvrde zato to je
klijent primio tok podataka sve do rednog broja 79 i sada oekuje bajtove od 80 na dalje. Moda
vas udi to ovaj segment takoe sadri redni broj iako u njemu nema podataka, ali poto TCP
ima polje rednog broja u njemu mora da bude neki redni broj.

3.5 TRANSPORT SA KONEKCIJOM: TCP 237 237 237 237
3.5.3 Procena vremena povratnog puta i tajm-aut
Uskoro emo videti da TCP, kao i na protokol rdt iz odeljka 3.4, za oporavak od izgubljenih
segmenata koristi mehanizam tajm-aut/ponovljeno slanje. Mada je koncepcija ovog mehanizma
jednostavna, prilikom implementiranja u stvarnom protokolu kakav je TCP javljaju se mnoga
suptilna pitanja. Moda je najoiglednije pitanje duine intervala za tajm-aut. Jasno je da
tajm-aut mora biti vei od vremena povratnog puta konekcije (RTT), tj. vremena od kad se
segment poalje dok ne stigne njegova potvrda. Inae bi dolazilo do nepotrebnih ponavljanja. Ali
koliko vei treba da bude interval? Kako, pre svega, da se procent RTT? Da li bi svakom nepo-
tvrenom segmentu trebalo pridruiti zaseban tajmer? Toliko pitanja! Na opis u ovom odeljku
zasnovan je na tekstu o TCP-u u knjizi [Jacobson 1988] i vaeim preporukama IETF-a za
upravljanje TCP tajmerima [RFC 2988].

Procena vremena povratnog puta
Da bismo shvatili upravljanje TCP tajmerom najpre treba da prouimo nain na koji TCP
procenjuje vreme povratnog puta izmeu poiljaoca i primaoca. To se postie na sledei nain.
Uzorak vremena povratnog puta RTT za jedan segment, koji se naziva SampleRTT, jeste trajanje
od trenutka slanja segmenta (tj. predavanja u IP) do prijema potvrde tog segmenta. Uglavnom se
ne meri SampleRTT za svaki pre-neti segment. U veini TCP implementacija se u svakom
trenutku pravi samo po jedan uzorak SampleRTT. To jest, u svakom trenutku se procenjuje samo
jedan SampleRTT za jedan preneti ali trenutno jo nepotvreni segment, tako da se dobija po
jedna nova vrednost SampleRTT priblino jedanput tokom svakog pojedinanog povratnog puta.
Osim toga, TCP nikad ne izraunava SampleRTT za segment koji se alje ponovo; SampleRTT
se meri samo za segmente koji su poslati jednom. (U jednom zadatku pri kraju poglavlja traie
se da odgovorite zato.) Oigledno je da e se vrednost SampleRTT menjati od segmenta do
segmenta zavisno od zaguenja na ruterima i od razliitog optereenja krajnjih sistema. Zbog
ovih razlika, svaka pojedinana vrednost SampleRTT ne mora biti uobiajena. Da bi se procenio
tipini RTT prirodno je da se uzme neki proek dobijen od vie vrednosti SampleRTT. TCP
stalno izraunava jedan proek izmerenih vrednosti SampleRTT po imenu EstimatedRTT. im
dobije novi SampleRTT, TCP aurira promenljivu EstimatedRTT prema sledeoj formuli:

EstimatedRTT = (1 - a ) EstimatedRTT + a SampleRTT
Gornja fonnula napisana je u obliku rekurzivne naredbe u programskom jeziku - nova
vrednost za EstimatedRTT jc ponderisana kombinacija prethodne vrednosti EstimatedRTT i
nove vrednosti SampleRTT. Preporuena vrednost za o: je 0,125 (tj. 1/8) [RFC 2988], pa u tom
sluaju gornja formula postaje:
EstimatedRTT = 0.875 EstimatedRTT + 0.125 SampleRTT
Obratite panju na to da je EstimatedRTT ponderisani proek vrednosti SampleRTT. Kao
stoje opisano u domaem zadatku na kraju poglavlja, ovaj ponderisani proek daje vei znaaj
novijim uzorcima nego starijim. To je prirodno poto noviji uzorci bolje odraavaju trenutno
zaguenje mree. U statistici se ovakav proek naziva eksponencijalno ponderisani klizni proek
(exponential \veighted moving average, EWMA). Ovaj proek je eksponencijalan" zato to
teinski faktor (ponder) pojedinane vrednosti SampleRTT eksponencijalno opada sa svakim
sle-deim auriranjem. U domaim zadacima e se traiti da izvedete eksponencijalni izraz za
EstimatedRTT.
Na slici 3.32 prikazane su vrednosti SampleRTT i EstimatedRTT za vrednost a = J/8 za
jednu TCP konekciju izmeu raunara gaia.cs.umass.edu (u gradu Amherst u Masausetsu) i
raunara fantasia.eurecom.fr (na jugu Francuske). Jasno je da se varijacije u vrednosti
SampleRTT izravnavaju izraunavanjem vrednosti EstimatedRTT.


Obratite panju na to daje DevRTT eksponencijalno ponderisani klizni proek razlike
izmeu vrednosti SampleRTT i EstimatedRTT. Ako vrednosti SampleRTT malo variraju,
DevRTT e biti malo; a kada su ove fluktuacije vee, DevRTT e biti veliko. Preporuena
vrednost za (3 je 0.25.

Upravljanje intervalom tajm-auta za ponovno slanje
Sada kada imamo vrednosti EstimatedRTT i DevRTT, koju bi vrednost trebalo uzeti kao
TCP-ov interval za tajm-aut? Jasno je da bi interval trebalo da bude vei ili jednak vrednosti
parametra EstimatedRTT, inae bi dolazilo do nepotrebnih ponovnih slanja. Ali, ne bi smeo da
bude ni mnogo vei od parametra EstimatedRTT; inae, TCP ne bi dovoljno brzo ponovo poslao
segment u sluaju
PRINCIPI U PRAKSI
TCP obezbeduje pouzdan transfer podataka pomou tajmero i pozitivnih potvrda uglavnom no
nain koji smo opisali u odeljku 3.4. TCP potvruje podatke koji su primljeni pravilno, a ponovo
alje segmente kada se smatra da su segmenti ili njihove odgovarajue potvrde izgubljene ili
oteene. Neke verzije TCP-a fakoe sodre i implicitni mehanizam NAK (negativna potvrda,
prim. prev.), Tri ACK-a za isti segment igraju ulogu implicitnog NAK-a za sledei segment,
ime se pokree ponovno slanje tog segmenta pre nego to . nastupi lajm-aul. TCP koristi redne
brojeve da bi primalac mogao da utvrdi do su segmenti izgubljeni ili dupli. Kao i u sluaju naeg
protokola rdt3 zo pouzdani transfer podolako, TCP ne moe sam pouzdano da utvrdi da li je
segment ili njegov ACK izgubljen, oteen ili on jednostavno mnogo kasni. TCP-ov odgovor e
kod poiljaoca biti isti: segment o kome je re poslae se ponovo.
TCP takoe koristi cevovodnu obradu, u kojoj poiljalac moe u istom trenutku da ima vie
poslatih, a jo nepotvrenih segmenata. Videli smo ranije da cevovona obrada moe znaajno
da unapredi propusnu mo sesije ako je veliina segmenta mala u odnosu na trajanje povratnog
puta. Konkretan broj zaostalih nepotvrenih segmenata koje poiljalac moe da dri utvruje se
TCP-ovim mehanizmima za kontrolu toka i kontrolu zaguenja. TCP-ova kontrola toka opisano
je no kraju ovog odeljka; TCP-ova kontrola zaguenja opisana je u odeljku 3.7. Za sado,
dovoljno je da budemo svesni da TCP poiljalac koristi cevovodnu obradu.
gubitka, ime bi se u aplikaciju uvelo znaajno kanjenje zbog transfera podataka. Zato je
poeljno da interval za tajm-aut bude jednak EstimatedRTT plus neka rezerva. Rezerva bi
trebalo da bude velika ako vrednosti parametra SampleRTT mnogo variraju, a mala u sluaju
male varijacije. Zato emo ovde upotrebiti vrednost parametra DevRTT. Sva ova razmatranja
ukljuena su u TCP-ov metod kojim se odreuje interval tajm-auta za ponovno slanje:

TimeoutInterval = EstimatedRTT + 4 DevRTT
3.5.4 Pouzdani transfer podataka
Verovatno znate da je Internetova usluga mrenog sloja, EP, nepouzdana. IP ne garantuje
isporuku datagrama, ne garantuje pravilan redosled datagrama i ne garantuje integritet podataka
u datagramima. Kada se koristi usluga IP, datagrami mogu da preliju privremene memorije
rutera i da nikada ne stignu na odredite; mogu da stignu izvan redosleda, a bitovi u datagramu
mogu da se otete (da se promene iz 0 u 1 i obratno). Poto se segmenti transportnog sloja
prenose preko mree u IP datagramima, svi ti problemi mogu da se jave i u segmentima
transportnog sloja.
TCP prua uslugu pouzdanog transfera podataka preko IP-ove nepouzdane usluge najboljeg
pokuaja. TCP-ova usluga pouzdanog transfera podataka obezbeduje da tok podataka koji
proces ita iz prijemne privremene memorije TCP-a bude neoteen, bez prekida, bez duplikata i
u pravilnom redosledu; tj. da tok bajtova bude tano onakav kakav je poslao krajnji sistem na
drugoj strani konekcije. U ovom pododeljku dajemo pregled naina na koji TCP obezbeduje
pouzdani transfer podataka. Videemo da TCP-ova usluga pouzdanog transfera podataka koristi
mnoge principe koje smo prouili u odeljku 3.4.
Kada smo razmatrali tehnike pouzdanog transfera podataka, bilo je najlake pretpostaviti
da se svakom predatom, a jo nepotvrenom segmentu pridruuje zaseban tajmer. Mada je ovo
teoretski odlino, upravljanje veim brojem tajmera predstavljalo bi znaajno programsko
optereenje. Zbog toga se u preporuenim procedurama za upravljanje tajmerima za TCP [RFC
2988] predlae samo jedan tajmer za ponovno slanje, iako ima vie poslatih, a jo nepotvrenih
segmenata. Protokol TCP koji opisujemo u ovom odeljku zasnovan je na ovoj preporuci sa samo
jednim taj-merom.
Nain na koji TCP obezbeduje pouzdani transfer podataka opisaemo u dva uzastopna
koraka. Prvo predstavljamo krajnje pojednostavljeni opis TCP poiljaoca gde se za oporavak od
izgubljenih segmenata koristi samo tajmer; zatim dajemo potpuniji opis u kojem se osim tajmera
koriste i duplikati potvrivanja. U sledeem opisu, polazimo od pretpostavke da se podaci alju
samo u jednom smeru, od raunara Ado raunara B i da raunar A alje jednu veliku datoteku.
Na slici 3.33 prikazanje krajnje pojednostavljeni opis TCP poiljaoca. Vidimo da u TCP
poiljaocu postoje tri glavna dogaaja u vezi sa inicijalnim i ponovnim sla-
Osim procene trajanja povratnog puta, RTT, vredno je posedovati i kvantitativnu raeru
varijacije RTT-a. [RFC 2988] definie varijaciju vremena povratnog puta, DevRTT, kao
procenu standardne devijacije SarapleRTT od EstimatedRTT:


njem podataka: stizanje podataka odozgo od aplikacije, tajm-aut i stizanje ACK-a. Kada nastupi
prvi glavni dogaaj, TCP prima podatke od aplikacije, enkapsulira ih u segment i predaje
segment IP-u. Obratite panju na to da svaki segment sadri redni broj koji predstavlja broj
prvog bajta podataka tog segmenta u toku bajtova, kao stoje opisano u odeljku 3.5.2. Takoe
obratite panju na to da TCP pokree tajmer kada preda segment u IP ako tajmer nije ve
ukljuen zbog nekog drugog segmenta.

/* Pretpostavlja se da poiljaoca ne ograniava TCP-ova kontrola toka niti kontrola zaguenja, da su
podaci dobijeni od aplikacionog sloja manji od MSS-a i da se transfer podataka obavlja samo u jednom
smeru */

NextSeqNum=InitialSeqNumber
SendBase=InitialSeqNumber
loop (forever) (
switch(event)
event:podaci dobijeni odozgo od aplikacije
create TCP segment with secuence number MextSeqNum if (timer currently not
running)
start timer pass segment to IP
NextSeqNum=NextSeqNum+length(data) break; event: timer
timeout
retransmit not-yet-acknowledged segment with
smallest sequence number start timer
break;
event: primljen ACK, sa vrednou y u polju ACK if (y > SendBase) {
SendBase=y
if (there are currently any not-yet-acknowl-edged segments) start timer
1 11 1
break;
} /* kraj beskonane petlje */ Slika 3.33 Slika 3.33 Slika 3.33 Slika 3.33
Pojednostavljen TCP poiljalac
(Moe se zamisliti daje tajmer pridruen najstarijem nepotvrenom segmentu.) Interval ovog
tajmera je Timeoutlnterval, koji se izraunava na osnovu vrednosti parametara EstimatedRTT i
DevRTT, kao stoje opisano u odeljku 3.5.3.
Drugi glavni dogaaj je tajm-aut. TCP reaguje na dogaaj tajm-aut tako to ponovo alje
segment koji gaje izazvao. TCP zatim ponovo pokree tajmer. Trei vaan dogaaj koji TCP
poiljalac mora da obradi je pristizanje segmenta potvrde (ACK) od primaoca (tanije, segment
koji sadri vaeu vrednost u polju ACK). Kada nastupi ovaj dogaaj, TCP poredi ACK
vrednost y sa svojom promen-Ijivom SendBase. Promenljiva TCP stanja SendBase je redni broj
najstarijeg nepotvrenog bajta. (Prema tome, SendBase-1 je redni broj poslednjeg bajta za koji
se zna daje kod primaoca primljen pravilno i u ispravnom redosledu.) Kao to je ranije
napomenuto, TCP koristi kumulativne potvrde, pa tako y potvruje prijem svih bajtova pre bajta
broj y. Ako je y > .SendBase, taj ACK potvruje jedan ili vie prethodno nepotvrenih
segmenata. Na taj nain poiljalac aurira promen-ljivu SendBase; on takoe ponovo pokree
tajmer ako ima nekih jo nepotvrenih segmenata.

Nekoliko zanimljivih scenarija
Upravo smo opisali krajnje pojednostavljenu verziju naina na koji TCP obezbeduje pouzdani
transfer podataka. Ali, ta krajnje pojednostavljena verzija - iako uproena - ipak sadri mnoge
suptilnosti. Da biste bolje osetili kako ovaj protokol funkci-onie, pogledajmo nekoliko
jednostavnih scenarija. Na slici 3.34 prikazanje prvi scenario u kojem raunar A alje jedan
segment raunaru B'. Uzmimo da segment ima redni broj 92 i da sadri osam bajtova podataka.
Poto poalje ovaj segment, raunar A eka od raunara B segment sa brojem potvrde 100.
Mada je segment iz A stigao u raunar B, potvrda od B prema A se gubi. U ovom sluaju,
nastupa dogaaj tajm-aut i raunar A ponovo alje isti segment. Naravno, kada raunar B
ponovo primi isti segment, on e iz rednog broja zakljuiti da taj segment sadri podatke koji su
ve primljeni. Prema tome, TCP u raunaru B e odbaciti bajtove iz ponovo poslatog segmenta,
U drugom scenariju, prikazanom na slici 3.35, raunar A alje dva segmenta jedan za
drugim, Prvi segment ima redni broj 92 i osam bajtova podataka, a drugi segment ima redni broj
100 i 20 bajtova podataka. Uzmimo da oba segmenta stignu neoteena do raunara B i da B
alje dve zasebne potvrde, za svaki od tih segmenata. Prvi broj potvrde je 100 a drugi 120.
Uzmimo sada da nijedna od ovih potvrda ne stigne do raunara A pre isteka tajm-auta. Kada
nastupi dogaaj tajm-aut, raunar A ponovo alje prvi segment sa rednim brojem 92 i ponovo
pokree tajmer. Ako ACK za drugi segment stigne pre novog tajm-auta, drugi segment se nee
ponovo poslati.
U treem i konanom scenariju, uzmimo da raunar A poalje dva segmenta, isto kao u
drugom primeru. Potvrda prvog segmenta se gubi u mrei, ali neposredno

3.5 TRANSPORT SA KONEKCIJOM: TCP 243

pre dogaaja tajm-aut, raunar A prima potvrdu sa brojem 120. Raunar A prema tome zna daje
raunar B primio sve zakljuno sa bajtom 119, pa ne alje ponovo nijedan od prva dva segmenta.
Ovaj scenario prikazanje na slici 3.36.

Dupliranje intervala za tajm-aut
Sada emo opisati nekoliko modifikacija koje se koriste u veini TCP implementacija. Prva se
odnosi na duinu intervala za tajm-aut kada tajmeru istekne vanost. Kao to je gore opisano, kad
god nastupi dogaaj tajm-aut, TCP ponovo alje nepotvreni segment sa najmanjim rednim
brojem. AH, svaki put kada TCP ponovo alje neki segment, on udvostruava interval za
tajm-aut u odnosu na prethodni umesto da ga ponovo izrauna od ranijeg EstimatedRTT i
DevRTT (kao stoje opisano u odeljku 3.5.3). Na primer, uzmimo da Timeoutlnterval pridruen
najstarijem jo nepotvrenom segmentu iznosi 0,75 sekunde kada tajmeru prvi put istekne vreme.
TCP e tada ponovo poslati ovaj segment i odrediti ndvi interval tajmera od 1,5 sekundi. Ako
tajmer opet istekne nakon 1,5 sekundi, TCP e opet ponoviti slanje
tog segmenta, ali e sada odrediti da interval bude 3,0 sekunde. Na ovaj nain, interval nakon
svakog ponovnog slanja raste eksponencijalno. Meutim, ako se tajmer ponovo pokree nakon
bilo kojeg od druga dva dogaaja (tj. ako su podaci primljeni odozgo iz aplikacije ili je primljen
ACK), vrednost Timeoutlnterval izraunava se od najnovijih vrednosti parametara
EstimatedRTT i DevRTT.
Ova modifikacija obezbeduje ogranieni oblik kontrole zaguenja. (Potpunije oblike TCP
kontrole zaguenja prouiemo u odeljku 3.7.) Do isteka tajmera dolo je najverovatnije zbog
zaguenja na mrei, tj. prevelikog broja paketa koji stiu na jedan (ili vie) redova za ekanje u
ruterima na putanji od izvora do odredita, zbog ega se paketi odbacuju ili dugo ekaju u
redovima. Ako tokom zaguenja izvori uporno nastave da ponavljaju slanje paketa, zaguenje
moe da postane jo gore. Umesto toga, TCP postupa uviavnije, tako to svaki poiljalac
ponavlja slanje u sve duim i duim intervalima. Kada budemo razmatrali CSMA/CD u
poglavlju 5, videemo da Ethernet koristi slian pristup.


Brzo ponovno slanje
Jedan od problema ponovnog slanja koje se pokree nakon tajm-auta je u tome stoje tajm-aut
interval esto prilino velik. Kada se segment izgubi, poiljalac mora dugo da eka pre nego to
ponovo poalje paket, pa tako produava ukupno kanjenje s kraja na kraj. Sreom, poiljalac esto
moe da uoi gubitak paketa mnogo pre isteka vremena tajmera kada primi takozvane duple
ACK-ove. Dupli ACK je ACK koji ponovo potvruje segment za koji je poiljalac ve ranije primio
potvrdu, Da bismo shvatili reagovanje poiljaoca na dupli ACK, moramo da razmotrimo zato
primalac uopte alje dupli ACK, U tabeli 3;2 data je rekapitulacija politike po kojoj TCP primalac
pravi ACK [RFC 1122, RFC 2581]. Kada TCP primalac dobije segment sa rednim brojem veim od
sledeeg oekivanog rednog broja, on primeuje prazninu u toku podataka - tj. primeuje da neki
segment nedostaje. Ova praznina moe da potie od toga to su segmenti izgubljeni u mrei ili od
toga to im se poremetio redosled. Primalac ne moe da vrati poiljaocu eksplicitnu negativnu
potvrdu zato
to TCP ne koristi negativne potvrde. Umesto toga, on jednostavno ponovo potvruje (tj. pravi dupli
ACK) za poslednji bajt podataka koji je primio u pravilnom redosledu. (Obratite panju na to daje u
tabeli 3.2 prikazan sluaj kada primalac ne odbacuje segmente van redosleda.)
Poto poiljalac esto alje vie segmenata jedan za drugim, kada se jedan segment izgubi
verovatno je da e biti mnogo uzastopnih istovetnih ACK-ova. Ako TCP poiljalac primi tri ACK-a za
iste podatke, on to prihvata kao signal da se izgubio segment iza onog koji je tri puta potvren. (U
problemima za domai zadatak razmatramo pitanje zato poiljalac eka da dobije tri istovetna
ACK-a i ne reaguje na prvi duplirani ACK.) U sluaju da primi tri istovetna ACK-a, TCP preduzima
brzo ponovno slanje [RFC 2581], tako to alje nedostajui segment pre nego to istekne njegov
tajmer. U TCP-u sa brzim ponovnim slanjem, sledei odlomak koda zamenjuje dogaaj primljenog
ACK-a sa slike 3.33:
event: primljen ACK, sa vrednou y u polju ACK if (y > SendBase) {
SenBase=y
if (there are currently any not yet _ acknowledged segments) start
timer
}
else { /* dupli ACK za ve potvreni segment *7 increment number of duplicate ACKs
_
received for y if (number of duplicate ACKS received _
for y==3) {
/* TCP brzo ponovno slanje */
resend segment with sequence number y
}
break;

2/46 2/46 2/46 2/46 POGLAVLJE 3 TRANSPORTNI SLOJ

Ve smo primetili da se javlja mnogo suptilnih pitanja kada se u stvarnom protokolu kakav je
TCP implementira mehanizam za tajm-aut i ponovno slanje. Gore pome-nuti postupci koji su
nastali kao rezultat vie od 15 godina iskustva sa TCP-ovini tajmerima trebalo bi da ubede
itaoca daje zaista tako!

GBN ili selektivno ponavljanje?
Nae prouavanje TCP-ovog mehanizma za oporavak od greaka zakljuiemo sledeim
pitanjem: da li je TCP protokol tipa GBN ili SR? Znale da su TCP-ove potvrde kumulativne i da
pimalac ne potvruje pojedinano segmente koji su primljeni ispravno, ali izvan redosleda. Zato,
kao stoje prikazano na slici 3.33 (pogledajte takoe sliku 3.19), TCP poiljalac mora da uva
samo najnii redni broj poslatog a nepotvrenog bajta (SendBase) i redni broj sledeeg bajta koji
treba da se poalje (NextSeqNum). U tom pogledu, TCP dosta lii na GBN protokol, ali ipak
postoje i velike razlike. U mnogim implementacijama TCP-a pravilno primljeni segmenti izvan
redosleda ipak se uvaju [Stevens 1994]. Uzmimo takoe situaciju kada poiljalac poalje niz
segmenata 1, 2,N i svi oni stignu primaocu ispravni i u pravilnom redosledu. Pretpostavite da se
zatim izgubi potvrda za paket < A', a da preostalih N- 1 potvrda stigne poiljaocu pre
tajm-auta. U takvom sluaju, GBN protokol bi ponovo poslao ne samo paket n, ve i sve naredne
pakete n + 1, n + 2, N. S druge strane, TCP bi ponovo poslao najvie jedan segment, segment .
tavie, TCP ne bi poslao ak ni segment n ako bi potvrda za segment n + 1 stigla pre tajm-auta
za segment n.
Predloena modifikacija protokola TCP, takozvano selektivno potvrivanje [RFC 2581],
omoguava TCP primaocu da selektivno potvruje segmente primljene izvan redosleda umesto
da kumulativno potvruje poslednji pravilan segment primljen u ispravnom redosledu. Kada se
kombinuje sa selektivnim ponovnim slanjem
- gde se izostavlja ponovno slanje segmenata koje je primalac selektivno potvrdio
- TCP veoma lii na na opti protokol tipa SR. Prema tome, TCP-ov mehanizam za oporavak
od greaka bi najbolje bilo razvrstati kao meavinu GBN protokola i protokola sa selektivnim
ponavljanjem.

3.5.5 Kontrola toka
Verovatno se seate da raunari na svakoj strani TCP konekcije rezervisti prijemne privremene
memorije za tu konekciju. Kada TCP konekcija primi bajtove koji su ispravni i u pravilnom
redosledu, ona ih stavlja u prijemnu privremenu memoriju. Pridrueni aplikacioni proces e itati
podatke iz ove privremene memorije, ali to ne mora biti im podaci stignu. Zaista, prijemna
aplikacija moe da bude zauzeta nekim drugim zadatkom pa stoga i ne pokua da ita podatke
odmah po njihovom pristizanju. Ako aplikacija relativno sporo ita a poiljalac suvie brzo alje
preveliku koliinu podataka, prijemna privremena memorija konekcije moe vrlo iako da se
preplavi.
Da bi se eliminisala mogunost da poiljalac preplavi primaoevu privremenu memoriju,
TCP svojim aplikacijama obezbeduje uslugu kontrole toka. Kontrola toka je prema tome usluga
usklaivanja brzine - jer usklauje brzinu kojom poiljalac alje sa brzinom kojom prijemna
aplikacija ita. Kao stoje ve napomenuto, TCP poiljalac moe se usporiti i zbog zaguenja
unutar IP mree; ta vrsta kontrole naziva se kontrola zaguenja. Nju emo detaljno obraditi u
odeljcima 3.6 i 3.7. Mada su aktivnosti koje preduzimaju kontrola toka i kontrola zaguenja
sline (usporavanje poiljaoca), one se oigledno preduzimaju iz veoma razliitih razloga.
Naalost, mnogi autori meaju ove izraze, pa bi mudar italac trebalo paljivo da ih razlui. Sada
emo opisati kako TCP prua uslugu kontrole toka. Da ne bi drvee zaklonilo umu, u elom
ovom odeljku polazimo od pretpostavke da je TCP implementacija takva da TCP primalac
odbacuje segmente koji nisu u pravilnom redosledu.
TCP omoguava kontrolu toka tako to se kod poiljaoca odrava promenljiva zvana
prijemni prozor. Nezvanino objanjenje je da se prijemni prozor koristi kako bi poiljalac
mogao da nasluti koliko ima mesta u privremenoj memoriji primaoca. Poto TCP radi u punom
dupleksu, poiljalac na svakoj strani konekcije odrava zaseban prijemni prozor. Razmotrimo
prijemni prozor u kontekstu transfera datoteke. Uzmimo da raunar A alje raunaru B veliku
datoteku preko TCP konekcije. Raunar B dodeljuje toj konekciji prijemnu privremenu
memoriju; oznaite njenu veliinu sa RcvBuf f er. S vremena na vreme, aplikacioni proces u
raunani B ita iz ove privremene memorije. Definiite sledee promenljive:
LastByteRead: broj poslednjeg bajta u toku podataka koji je aplikacioni proces u raunaru B
proitao iz privremene memorije.
LastByteRcvd: broj poslednjeg bajta u toku podataka koji je stigao sa mree i tavljenje u
prijemnu privremenu memoriju raunara B.

Poto TCP ne srne da prelije dodeljenu privremenu memoriju, uvek mora biti:
LastByteRcvd - LastByteRead < RcvBuffer
Prijemnom prozoru, oznaenom sa RcvWindow, dodeljuje se preostala koliina prostora u
privremenoj memoriji:

RcvWindow = RcvBuffer - [LastByteRcvd - LastBvteRead]
Poto se preostali prostor menja u vremenu, RcvWindow je dinamian. Promenljiva
RcvWindow prikazana je na slici 3.37.
Kako konekcija koristi promenljivu RcvWindow u pruanju usluge kontrole toka? Raunar
B obavetava raunar A o slobodnom prostoru u privremenoj memoriji konekcije tako to
stavlja trenutnu vrednost RcvWindow u polje prijemnog prozora svakog segmenta koji alje
raunaru A. Na poetku, raunar B stavlja

248 248 248 248 POGLAVLJE 3 TRANSPORTNI SLOJ 3.5 TRANSPORT SA KONEKCIJOM: TCP 24? 24? 24? 24?

RcvWindow = RcvBuf fer. Obratite panju na to da za uspeh ovakvog postupka raunar B mora
da prati nekoliko promenljivih vezanih za konekciju.
Raunar A odrava dve promenljive, LastByteSent (poslednji poslati bajt) i LastByteAcked
(poslednji potvren bajt). Obratite panju na to da je razlika izmeu te dve promenljive,
LastByteSent - LastByteAcked, jednaka koliini nepotvrenih podataka koje je A poslao u
konekciju. Ako pazi da koliina nepotvrenih podataka ostane manja od vrednosti RcvWindow,
raunar A moe biti siguran da ne preplavljuje prijemnu privremenu memoriju raunara B.
Prema tome, raunar A tokom celog ivota konekcije obezbeduje da bude
LastByteSent - LastByteAcked ^ RcvWindow
Kod ovog reenja postoji jedan mali tehniki problem. Da biste ga sagledali, pretpostavimo
da se prijemna privremena memorija raunara B popuni tako da bude RcvWindow = 0. Posto se
objavi raunaru A da je RcvWindow = 0, pretpostavimo takode da raunar B nema vie nita da
alje raunaru A. Pogledajmo sada ta se dogaa. Poto aplikacioni proces u B isprazni
privremenu memoriju, TCP nee poslati raunaru A novi segment sa novom vrednou
RcvWindow poto on to radi samo ako ima podatke za slanje ili ako treba da poalje neku
potvrdu. Prema tome, raunar A nikada ne bi saznao da se pojavio prostor u prijemnoj
privremenoj memoriji raunara B - raunar A bi bio blokiran i ne bi mogao vie da alje
podatke! Da bi se resio ovaj problem TCP specifikacija zahteva da ako je prijemni prozor
raunara B jednak nuli, raunar A nastavi da alje segmente sa po jednim bajtom podataka. Te
segmente e primalac potvrivati. U jednom trenutku, privremena memorija e poeti da se
prazni, pa e potvrde preneti raunaru A vrednost RcvWindow razliitu od nule.
Onlajn lokacija na adresi http://www.awl.com/kurose-ross sadri interaktivni Java aplet
koji ilustruje rad prijemnog prozora TCP-a.
Poto smo opisali TCP -ovu uslugu kontrole toka, ukratko ovde pominjemo da UDP ne
obezbeduje kontrolu toka. Da bi se shvatio problem, razmotrimo slanje niza UDP segmenata od
jednog procesa u raunaru A drugom procesu u raunaru B. U uobiajenoj implementaciji
UDP-a, UDP dodaje segmente u privremenu memoriju konane veliine pre upotrebe
odgovarajueg soketa (tj. vrata prema procesu). Proces ita iz privremene memorije cele
segmente, jedan po jedan. Ako proces ne ita segmente dovoljno brzo, privremena memorija e
se preliti i segmenti e biti izgubljeni.

3.5.6 Upravljanje TCP konekcijom
U ovom pododeljku preciznije emo razmotriti kako se TCP konekcija uspostavlja i raskida.
Mada ova tema ne izgleda posebno uzbudljiva, ona je vana poto uspostavljanje TCP konekcije
moe znaajno da utie na opaeno kanjenje (na primer, prilikom etanja po VVebu).
Pogledajmo sada kako se uspostavlja TCP konekcija. Uzmimo da proces koji se izvrava
najednom raunaru (klijent) eli da pokrene konekciju sa drugim procesom na drugom raunaru
(server). Klijentski aplikacioni proces prvo obavetava klijentski TCP da eli da uspostavi
konekciju sa procesom na serveru. TCP u klijentu zatim kree u uspostavljanje TCP konekcije
sa TCP-om u serveru na sledei nain:
Korak 1. TCP na klijentskoj strani prvo alje poseban TCP segment TCP-u na serverskoj
strani. Ovaj poseban segment ne sadri podatke aplikaciohog sloja, ali jedan od bitova
oznaka u zaglavlju segmenta (slika 3.29), bit SYN, ima vrednost 1. Zbog toga se ovaj
poseban segment naziva segmentom SYN. Osim toga, klijent bira poetni redni broj
(client_isn) i stavlja taj broj u polje rednog broja poetnog TCP segmenta SYN. Ovaj
segment se enkapsulira u IP datagram i alje serveru. Pravilnom izboru sluajne vrednosti
client_isn posveena je
. znaajna panja da bi se izbegli neki bezbednosni rizici [CERT 2001-09].
Korak 2. Kada IP datagram koji sadri TCP segment SYN stigne serverskom raunaru (ako
uopte stigne!), server vadi TCP segment SYN iz datagrama, dodeljuje TCP konekciji
privremene memorije i promenljive i alje klijentskom TCP-u segment odobrenja konekcije.
Ovaj segment odobrenja konekcije takoe ne sadri podatke aplikacijskog sloja. Meutim,
on u zaglavlju sadri tri znaajne informacije. Prvo, bit SYN ima vrednost I. Drugo, polje
potvrde u zaglavlju TCP segmenta ima vrednost client_isn+l. Na kraju, server bira i vlastiti
poetni redni broj (server_isn) i stavlja tu vrednost u polje rednog broja u zaglavlju TCP
segmenta, Ovaj segment odobrenja konekcije u sutini saoptava: Primio sam va paket
SYN za pokretanje konekcije sa vaim poetnim rednim brojem


client_isn. Pristajem na uspostavljanje ove konekcije. Moj poetni redni broj je server_isn."
Segment odobrenja konekcije ponekad se naziva i segment SYNACK.
Korak 3. Poto primi segment SYNACK, klijent takode dodeljuje konekciji privremene
memorije i promenljive. Klijentski raunar tada alje serveru jo jedan segment; ovaj
poslednji segment potvruje serverov segment odobrenja konekcije (klijent to postie
stavljanjem vrednosti server__isn+l u polje potvrde u zaglavlju TCP segmenta). Bit SYN
ima vrednost 0, postoje konekcija uspostavljena.
Poto se izvre prethodna tri koraka, klijentski i serverski raunar mogu jedan drugom da
alju segmente koji sadre podatke. U svakom od ovih buduih segmenata, bit SYN imae
vrednost nula. Obratite panju na to da se za uspostavljanje konekcije izmeu dva raunara alju
tri paketa, kao to je prikazano na slici 3.38. Zbog toga se ova procedura uspostavljanja
konekcije esto naziva i sinhroniza-cija u tri koraka. U problemima za domai zadatak istrauje
se nekoliko aspekata TCP-ove sinhronizacije u tri koraka (Zato su potrebni poetni redni
brojevi? Zato je potrebna sinhronizacija u tri koraka, a ne u dva?). Zanimljivo je da alpinista i
uvar (koji stoji ispod alpiniste i iji je posao da rukuje bezbednosnim uzetom alpiniste), da bi
bili sigurni da su obojica spremni pre nego to alpinista pone da se penje, koriste komunikacioni
protokol sa sinhronizacijom u tri koraka identian TCP-u.
Sve dobre stvari se jednom zavre, pa isto vai i za TCP konekciju. Bilo koji od dva
procesa koji uestvuju u TCP konekciji moe da prekine konekciju. Kada se konekcija zavri,
resursi" (tj. privremene memorije i promenljive) u raunarima se oslobaaju. Na primer,
pretpostavimo da klijent odlui da zatvori konekciju kao stoje prikazano na slici 3.39. Klijentski
aplikacioni proces izdaje komandu zatvaranja. Tada klijentski TCP alje serverskom procesu
poseban TCP segment. Ovaj poseban segment sadri vrednost 1 u bitu oznake FIN u zaglavlju
segmenta (slika 3.39). Kada server primi ovaj segment, on vraa klijentu segment potvrde.
Server zatim alje vlastiti segment prekida u kome bit FIN ima vrednost 1. Na kraju, klijent
potvruje serverov segment'prekida. U tom momentu su svi resursi na oba raunara osloboeni.
Tokom ivota TCP konekcije, protokol TCP koji se izvrava na svakom raunaru prolazi
kroz razliita TCP stanja. Na slici 3.40 prikazanje uobiajen niz TCP stanja kroz koja prolazi
TCP klijent. Klijentski TCP na poetku se nalazi u stanju CLOSED. Aplikacija na klijentskoj
strani inicira novu TCP konekciju (pravljenjem objekta Socket u naim Java primerima iz
poglavlja 2). Zbog toga TCP u klijentu alje TCP-u na serveru segment SYN. Poto poalje
segment SYN, klijentski TCP prelazi u stanje SYN_SENT. Dok je u stanju SYN_SENT,
klijentski TCP oekuje od serverskog TCP-a segment koji sadri potvrdu za klijentov prethodni
segment i u bitu SYN sadri vrednost 1. Poto primi takav segment, klijentski TCP prelazi u sta-
nje ESTABUSHED. Dok je u stanju ESTABLISHED, klijentski TCP moe da alje i prima
TCP segmente koji sadre korisne podatke (tj. podatke iz aplikacije).
Uzmimo da klijentska aplikacija resi da zatvori konekciju (mada i server moe da odlui da
prekine konekciju). Tada klijentski TCP alje TCP segment sa bitom FIN jednakim I i prelazi u
stanje FINJVAITJ. Dok je u stanju FIN_WAIT 1, klijentski TCP oekuje od servera TCP
segment sa potvrdom. Kada primi taj segment, klijentski TCP prelazi u stanje FlN_WArT_2.
Dok je u stanju FFN_WAIT_2, klijent eka na drugi segment sa servera gde je bit FIN jednak 1;
kada primi taj segment, klijentski TCP potvruje serverov segment i prelazi u stanje
TIME_WAIT. Stanje TIME_WAIT omoguava TCP klijentu da ponovo poalje konanu
potvrdu u sluaju da se ACK izgubi. Vreme provedeno u stanju TIME_WAIT zavisi od
implementacije, ali uobiajene vrednosti su 30 sekundi, 1 minut ili 2 minuta. Nakon ekanja,
konekcija se zvanino zatvara i svi resursi na klijentskoj strani (ukljuujui i brojeve portova) se
oslobaaju.


Na slici 3.41 prikazanje niz stanja kroz koja prolazi TCP na serverskoj strani, pod
pretpostavkom da klijent pokrene postupak za prekid konekcije. Prelasci iz stanja u stanje su
oigledni. Na ova dva dijagrama prikazali smo samo kako se TCP konekcija normalno
uspostavlja i prekida. Nismo opisali ta se dogaa u nekim neuobiajenim situacijama, na
primer, kada obe strane jedne konekcije u isto vreme zahtevaju prekid. Ako vas zanima da
prouite to i neka druga napredna pitanja u vezi sa TCP-om, predlaemo da proitate Stivensovu
sveobuhvatnu knjigu [Stevens 1994].
Pre nego to zakljuimo ovaj odeljak, razmotrimo ta se dogaa kada raunar primi TCP
segment iji se broj porta ili izvorna IP adresa ne uklapaju ni sa jednim postojeim soketom u
raunaru. Na primer, pretpostavite da raunar primi TCP SYN paket sa odredinim portom 80 ali
da raunar ne prihvata konekcije na portu 80 (tj. na portu 80 se ne izvrava nijedan veb server).
Raunar e tada poslati izvoru poseban segment za resetovanje. Ovaj TCP segment sadri
postavljen bit RST (proitajte odeljak 3.5.2). Kada raunar poalje takav segment, on poruuje
izvoru Ja nemam soket za taj segment. Molim nemojte ponavljati slanje segmenta." Kada
raunar primi UDP paket iji se broj odredinog porta ne uklapa ni sa jednim od aktivnih UDP
soketa, poslae poseban ICMP datagram kao to je opisano u poglavlju 4.

254 POGLAVLJE 3 TRANSPORTNI SLOJ
3.6 . PRINCIPI KONTROLE ZAGUENJA 139 139 139 139

Ovim zakljuujemo uvod u kontrolu greaka i kontrolu toka u TCP-u. U odeljku 3.7
vratiemo se na TCP i donekle detaljno razmotriti njegovu kontrolu zaguenja. Pre toga se,
meutim, vraamo na opti kontekst gde razmatramo pitanja kontrole zaguenja.

3. 6 Principi kontrole zaguenja
U prethodnim odeljcima ispitali smo opte principe i konkretne mehanizme koje TCP koristi da
bi obezbedio uslugu pouzdanog transfera podataka u situaciji kada se paketi gube. Ve smo
pomenuli da u praksi do tih gubitaka obino dolazi zbog prelivanja privremene memorije u
ruterima kada je mrea zaguena. Ponovno slanje paketa leci simptom zaguene mree (gubitak
konkretnog segmenta u transportnom sloju) ali ne lei uzrok zaguenja mree - previe izvora
koji alju podatke prevelikom brzinom. Da bi se uticalo na uzrok zaguenja potrebni su
mehanizmi koji e da uspore poiljaoce kada preti zaguenje mree.
U ovom odeljku razmotriemo problem kontrole zaguenja u optem smislu. Pokuaemo
da shvatimo zato je zaguenje loe", kako ono utie na performanse aplikacija gornjeg sloja,
kao i da prouimo razliite pristupe izbegavanju zaguenja i reagovanju na zaguenje mree.
Ovo opte izlaganje o kontroli zaguenja je vano jer predstavlja znaajnu stavku na listi prvih
deset" najznaajnijih problema umreavanja ako elimo da postignemo pouzdani transfer
podataka. Ovaj odeljak zakljuujemo opisom kontrole zaguenja u usluzi ABR (available
bit-rate) u ATM (asynchronous transfer mode) mreama. Sledei odeljak sadri detaljan opis
algoritma za kontrolu zaguenja u TCP-u.

3.6.1 Uzroci i posledice zaguenja
Opti opis kontrole zaguenja poinjemo ispilijui redom tri sve sloenija scenarija u vezi
sa pojavom zaguenja. U svakom od ovih sluajeva videemo zato uopte dolazi do zaguenja i
koje su njihove posledice(u smislu resursa koji se nedovoljno koriste i loih performansi u
krajnjim sistemima). Neemo (za sada) razmatrati kako treba reagovati ili izbe; zaguenje ve
samo elimo da objasnimo ta se dogaa kada raunari poveaju brzine prenosa, pa mrea
postane zaguena.

Scenario 1: Dva poiljaoca, jedan ruter sa beskonanim privremenim memorijama
Poinjemo sa moda najjednostavnijim scenarijom zaguenja: dva raunara (A i B) od kojih
svaki ima konekciju sa jednim skokom izmeu izvora i odredita kao to je prikazano na slici
3.42.
Uzmimo da aplikacija u raunaru A alje podatke u konekciju (na primer, tako to predaje
podatke protokolu transportnog sloja kroz soket) prosenom brzinom
od
K\=z bajtova/sekundi.
Ti podaci su originalni" u smislu da se svaka jedinica podataka alje u soket samo jednom.
Protokol transportnog sloja ispod aplikacije je jednostavan. Podaci se enkapsuliraju i alju; ne
primenjuje se nikakvo ispravljanje greaka (na primer, ponovno stanje), kontrola toka niti
kontrola zaguenja. Ako zanemarimo dodatno optereenje koje potie od dodavanja infonnacija
u zaglavlja transportnog sloja i niih slojeva, brzina kojom raunar A nudi saobraaj ruteru
iznosi Khz bajtova/sekundi. Raunar B funkcionie na slian nain, pa radi jednostavnosti
pretpostavljamo da i on alje brzinom od X
UVM
bajtova/sekundi. Paketi iz raunara A i B prolaze
kroz ruter i preko zajednikog izlaznog linka kapaciteta R. Ruter ima privremene memorije
koje mu omoguavaju uvanje pristiglih paketa kada je brzina pristizanja vea od kapaciteta
izlaznog linka. U ovom prvom scenariju pretpostavi-emo da ruter ima beskonanu koliinu
privremene memorije.
Na slici 3.43 prikazane su performanse konekcije raunara A po tom prvom scenariju. Levi
grafikon prikazuje propusnu mo po konekciji (broj bajtova u sekundi kod primaoca) u funkciji
brzine slanja u konekciju. Za brzinu slanja izmeu 0 i R/2, propusna mo kod primaoca jednaka
je brzini slanja kod poiljaoca - to god poiljalac poalje prima se kod primaoca uz konano
kanjenje. Meutim, ako je brzina slanja vea od R/2, propusna mo iznosi samo R/2. Ova
gornja granica propusne moi potie od toga to kapacitet linka dele dve konekcije. Link
jednostavno ne moe primaocu da isporui pakete stalnom brzinom veom od R/2. Bez obzira
na to koliko raunari A i B poveavaju brzine slanja, nijedan od njih nee nikada postii
propusnu mo veu od R/2.

140 POGLAVLJE 3 TRANSPORTNI SLOJ 3.6 PRINCIPI KONTROLE ZAGUENJA 257j

Postizanje propusne moi od R/2 po konekciji moe ak da izgleda uspeno" poto je link
potpuno iskorien isporukom paketa na njihova odredita. Meutim, desni grafikon na slici 3.43
prikazuje ta se dogaa kada link radi blizu maksimalnog kapaciteta. Kako se brzina slanja
pribliava vrednosti R/2 (sa leve strane), proseno kanjenje postaje sve vee i vee. Kada brzina
slanja pree R/2 prosecan broj paketa u redu za ekanje na ruteru je beskonaan, a proseno
kanjenje od izvora do odredita postaje neogranieno (pod pretpostavkom da konekcije rade pri
istim brzinama slanja tokom beskonanog vremenskog intervala), Prema tome, mada rad sa
ukupnom propusnom moi blizu R moe da bude idealan to se tie same propusne moi, daleko
je od idealnog to se tie kanjenja. ak i u ovom (krajnje) idealizovanom scenariju, ve smo
pronali jednu posledicu zaguene mree - kada se brzina pristizanja paketa pribliava
kapacitetu linka, javlja se veliko kanjenje u redovima za ekanje.

Scenario 2: Dva poiljaoca, jedan ruter sa konanim privremenim memorijama
Sada emo malo promeniti prvi scenario na sledea dva naina (slika 3.44). Prvo, uzeemo daje
koliina privremene memorije na ruteru konana. Posledica ove realne pretpostavke je da e se
paketi odbacivati ako stignu u privremenu memoriju koja je ve puna. Drugo, pretpostaviemo
daje svaka konekcija pouzdana. Ako se kod rutera ispusti paket koji sadri segment transportnog
sloja, njega e poiljalac kad-tad ponovo da poalje. Poto paketi mogu ponovo da se alju,
moramo sada paljivije da koristimo izraz brzina slanja". Konkretno, oznaimo ponovo brzinu
kojom aplikacija alje originalne podatke u soket sa >.u|a2 bajtova/sekundi. Brzinu kojom
transportni sloj alje segmente (sa originalnim podacima kao i sa podacima
koji se ponovo alju) u mreu oznaiemo sa ^'ulaz bajtova/sekundi. X'ulaj se ponekad naziva
ponueno optereenje za mreu.
Performanse ostvarene po scenariju 2 e sada u velikoj meri zavisiti od naina ponovnog
slanja. Prvo, uzmimo nestvarni sluaj da raunar A bude u stanju da nekako (volebno!) utvrdi
da li je privremena memorija u ruteru slobodna i da alje paket samo kad je tako. U ovom
sluaju ne bi bilo gubitaka, Xu|az bilo bijednako A,'u|az, a propusna mo konekcije bila bi jednaka
A.u|az. Ovaj sluaj prikazan je gornjom krivom na slici 3.45(a). to se tie propusne moi,
performanse su idealne - to god se poalje biva i primljeno. Obratite panju na to da po ovom
scenariju prosena brzina slanja ne moe prei R/2, poto smo pretpostavili da nikad ne dolazi
do gubitka paketa.
Razmotrimo sledei malo realniji sluaj kada poiljalac ponovo alje samo onaj paket za
koji se pouzdano zna daje izgubljen. (I ova je pretpostavka malo nategnuta. Meutim, otpremni
raunar moe da postavi dovoljno velik interval za tajm-aut pa e biti praktino siguran da se
paket, koji u tom intervalu nije potvren, izgubio.) U ovom sluaju, performanse bi izgledale
priblino kao na slici 3,45(b). Da biste shvatili ta se ovde dogaa, razmotrite sluaj kada
ponueno optereenje *.'uIaz (brzina slanja originalnih podataka i ponavljanja), iznosi R/2. Prema
slici 3.45(b), za tu vrednost ponuenog optereenja, brzina kojom se podaci isporuuju
prijemnoj aplikaciji iznosi R/3. Prema tome, od predatih 0,5 R jedinica podataka, (proseno)
0,333 R baj tova/sekundi predstavlja originalne podatke, dok (proseno) 0,166 i?
baj-tova/sekundi predstavlja ponovo poslate podatke. Ovde vidimo jo jednu posledicu zaguene
mree - poiljalac mora ponovo da alje podatke da bi nadoknadio pakete isputene (izgubljene)
zbogprelivanja privremene memorije.

3.6 PRINCIPI KONTROLE ZAGUENJA 259 259 259 259
i
( (( ( 141 141 141 141 POGLAVLJE 3 TRANSPORTNI

Na kraju, razmotrimo sluaj kada kod poiljaoca pre vremena nastupi tajm-aut i on ponovo
poalje paket koji kasni zbog ekanja u redu, a nije stvarno izgubljen. U tom sluaju, moe se
dogoditi da do primaoca stignu i originalni paket i paket koji je ponovo poslat. Naravno,
primaocu treba samo jedan primerak ovog paketa, pa e on odbaciti paket koji je ponovo poslat.
U ovom sluaju, rad" koji je ruter uloio u prosleivanje ponovno poslate kopije originalnog
paketa bie uzaludan" poto je primalac ve dobio originalni primerak ovog paketa. Ruter bi
bolje iskoristio prenosni kapacitet linka daje umesto toga poslao neki drugi paket. Ovde vidimo
jo jednu posledicu zaguene mree - nepotrebno ponovno slanje izazvano velikim kanjenjem
dovodi do toga da ruter troi propusni opseg linka za prosleivanja nepotrebnih kopija paketa.
Slika 3.45(c) prikazuje propusnu mo prema ponuenom optereenju ako se pretpostavi da ruter
svaki paket prosleuje (u proeku) dva puta. Poto se svaki paket prosleuje dva puta, ostvarena
propusna mo imae asimptotnu vrednost R/4 kada ponueno optereenje dostigne R/2.

Scenario 3: etiri poiljaoca, ruteri sa konanim privremenim memorijama i
putanja od vie skokova
U naem zavrnom scenariju zaguenja, etiri raunara alju pakete putanjama koje se
preklapaju i od kojih svaka ima po dva skoka, kao to je prikazano na slici 3.46. Ponovo
pretpostavljamo da u implementaciji usluge pouzdanog transfera podataka svi raunari koriste
mehanizam ponovnog slanja na osnovu tajm-auta, da svi rau-nari imaju istu vrednost \l]zz, a da
svi linkovi rutera imaju kapacitet od R bajtova/ sekundi.
Razmotrimo konekciju od raunara A do raunara C koja prolazi kroz rutere Rl i R2.
Konekcija A-C deli ruter Rl sa konekcijom D-B, a ruter R2 sa konekcijom B-D. Za ekstremno
male vrednosti prelivanje privremene memorije je retko (kao u scenarijima zaguenja 1 i 2), a
propusna mo je priblino jednaka ponude-
nom optereenju. Kod neto veih vrednosti X
LI[AZ
, odgovarajua propusna mo je takoe vea
poto se vie originalnih podataka prenosi u mreu i isporuuje na odredite, a prelivanja su
takoe retka. Prema tome, kod malih vrednosti X
UIN
poveanje vrednosti X
UIAZ
dovodi do
poveanja vrednosti X
IZ]OZ
.
Poto smo razmotrili sluaj izuzetno malog saobraaja, pogledajmo sada sluaj kada je \ln
(pa tako i X'u|M) izuzetno veliko. Pogledajmo ruter R2: Saobraaj A-C koji stie do rutera R2 (a
dolazi do rutera R2 tako stoje prosleen sa Rl) moe da pristie brzinom od najvie J?, koliko
iznosi kapacitet linka od Rl do R2, bez obzira na vrednost X
A]AZ
. Ako je X\
]AZ
izuzetno veliko za
sve konekcije (ukljuujui konekciju B-D), brzina pristizanja saobraaja B-D na ruter R2 moe
da bude mnogo vea od brzine saobraaja A-C. Poto saobraaj A-C i saobraaj B-D moraju da
se takmie na ruteru R2 za ogranieni prostor privremene memorije, koliina saobraaja A-C
koja uspeno proe kroz R2 (tj. koja se ne izgubi zbog prelivanja pri-

142 142 142 142 POGLAVLJE 3 TRANSPORTNI SLOJ 3.6 PRINCIPI KONTROLE ZAGUENJA 261 261 261 261

vremene memorije) postaje sve manja i manja kako raste ponueno optereenje od B~D. U
graninom sluaju, poto ponueno optereenje tei beskonanosti, prazna privremena memorija
u R2 odmah se puni paketom B-D, a propusna mo konekcije A-C na ruteru R2 tei nuli. Ovo
zatim dovodi do toga da propusna mo A-C sa kraja na kraj tei nuli u situaciji velikog
saobraaja, Ova razmatranja dovode nas do zakljuka da ponueno optereenje ima negativne
posledice na propusnu mo, kao to je prikazano na slici 3.47.
Razlog za opadanje propusne moi kod poveanja ponuenog optereenja oigledan je kada
se razmotri koliina uzaludnog rada" na mrei. U scenariju sa velikim saobraajem koji smo
upravo opisali, kad god se na ruteru prilikom drugog skoka ispusti paket, rad" koji je prvi ruter
uloio u prosleivanje paketa drugom ruteru na kraju ostaje uzaludan". Mrea bi isto tako dobro
prola (tanije, isto bi tako loe prola) daje prvi ruter jednostavno odbacio paket i ostao
besposlen. U stvari, kapacitet prenosa koji je prvi ruter upotrebio za prosleivanje paketa drugom
ruteru mnogo bi korisnije bio upotrebljen daje prenet neki drugi paket. (Na primer, kada se bira
paket za slanje, bilo bi bolje da ruter da prednost paketima koji su ve preli odreen broj rutera.)
Ovde vidimo jo jednu posledicu isputanja paketa zbog zaguenja - kada se paket ispusti negde
na putanji, ispada da je uzaludno utroen kapacitet prenosa koji je upotrebljen za prosleivanje
paketa na svakom od uzvodnih rutera do momenta isputenja paketa.

3.6.2 Pristupi kontroli zaguenja
U odeljku 3.7 emo veoma detaljno opisati kako TCP pristupa kontroli zaguenja. ' Ovde emo
ukazati na dva pristupa kontroli zaguenja koji se koriste u praksi i opisati konkretne arhitekture
mree i protokole za kontrolu zaguenja koji oliavaju te pristupe.
dJ najirem smislu, pristupe kontroli zaguenja moemo da razvrstamo na osnovu toga da li
mreni sloj daje transportnom sloju ikakvu eksplicitnu pomo u svrhu kontrole zaguenja:
Kontrola zaguenja sa kraja na kraj. U pristupu kontrole zaguenja sa kraja na kraj mreni sloj
ne daje transportnom sloju nikakvu eksplicitnu podrku u svrhu kontrole zaguenja. ak i
samo prisustvo zaguenja na mrei mora da se utvrdi u krajnjim sistemima jedino
posmatranjem ponaanja mree (na primer, gubljenje paketa i kanjenje). U odeljku 3.7
videemo da TCP obavezno mora da prihvati ovaj pristup sa kraja na kraj poto sloj IP ne
obezbeduje krajnjim sistemima nikakvu povratnu informaciju o zaguenju mree. Gubitak
TCP segmenta (koji se otkriva pomou tajm-auta ili trostruke potvrde) uzima se kao znak da
je dolo do zaguenja mree, pa TCP na odgovarajui nain smanjuje veliinu prozora. Vide-
emo takoe da se, u novim predlozima za TCP, kao znak da zaguenje mree raste koriste
poveane vrednosti kanjenja povratnog puta.
Kontrola zaguenja pomou mree. Kod kontrole zaguenja pomou mree, mrene
komponente (tj. ruteri) daju poiljaocu eksplicitne povratne informacije o stanju zaguenja
na mrei. Ova povratna informacija moe da bude jednostavno samo jedan bit koji ukazuje
na zaguenje linka. Takav pristup bio je prihvaen u ranim arhitekturama IBM SNA
[Schvvartz 1982] i DEC DECnet [Jain 1989; Ramakrishnan 1990], nedavno je predloen za
TCP/IP mree [Floyd TCP 1994; RFC 2481], a takode se koristi i u kontroli zaguenja ATM
ABR (avaiiable bit-rate), koju emo kasnije opisati. Mogue su i savrenije povratne
informacije o mrei. Na primer, jedan oblik kontrole zaguenja ATM ABR koji emo uskoro
prouiti omoguava ruteru da eksplicitno obavesti poiljaoca o brzini prenosa koju ruter
moe da podri na izlaznom linku.
Kod kontrole zaguenja pomou mree, informacija o zaguenju od mree ka poiljaocu
obino se prosleduje na jedan od dva naina prikazana na slici 3.48. Direktna povratna
informacija se alje sa mrenog rutera poiljaocu. Ova vrsta oba-vetenja obino je u obliku
paketa guenja (koji u sutini kae, zaguen sam!"). Drugi oblik obavetavanja je kada ruter u
paketu koji putuje od poiljaoca ka primaocu oznaava ili aurira polje koje ukazuje na
zaguenje. Kada primi oznaeni paket, primalac zatim obavetava poiljaoca daje dobio
upozorenje o zaguenju. Obratite panju na to da ovaj poslednji oblik obavetavanja zahteva
najmanje vreme jednog punog povratnog puta.

3.6.3 Primer kontrole zaguenja pomou mree: Kontrola zaguenja
ATM ABR
Ovaj odeljak zakljuujemo kratkim opisom algoritma za kontrolu zaguenja u usluzi ATM ABR
- protokol u kojem se za kontrolu zaguenja koristi pomo mree. Naglaavamo da nam ovde
nije cilj da detaljno opiemo aspekte arhitekture ATM, ve da

262 262 262 262 POGLAVLJE 3 TRANSPORTNI SLOJ 3.6 . PRINCIPI KONTROLE ZAGUENJA 143 143 143 143

prikaemo protokol sa znaajno drugaijim pristupom kontroli zaguenja od inter-netskog
protokola TCP. Prikazaemo samo onih nekoliko aspekata ATM arhitekture koji su potrebni za
shvatanje ABR kontrole zaguenja.
U osnovi, ATM za komutiranje paketa koristi princip virtuelnih kola (VC). Sigurno se
seate iz poglavlja 1 da to znai da svaki komutator na putanji od izvora do odredita vodi stanje
virtuelnog kola od izvora do odredita. To stanje virtuel-nog kola omoguava komutatoru da
prati ponaanje pojedinanih poiljalaca (npr. da prati njihovu prosenu brzinu slanja) i da
preduzima aktivnosti za kontrolu zaguenja zavisno od izvora (npr. da eksplicitno signalizira
poiljaocu da smanji brzinu kada komutator postaje zaguen). ATM je, zbog tih stanja virtuelnih
kola u mrenim komutatorima, idealno prilagoen kontroli zaguenja pomou mree.
ABR je projektovan kao fleksibilna usluga transfera podataka koja podsea na TCP. Kada
mrea nije optereena ABR usluge bi trebalo da budu u stanju da iskoriste dostupan slobodan
propusni opseg; kada je mrea zaguena on bi trebalo da prigui brzinu prenosa na neki unapred
postavljeni minimum, Detaljan udbenik za kontrolu zaguenja i upravljanje saobraajem ATM
ABR moe se nai [Jain 1996].
Na slici 3.49 prikazano je radno okruenje za kontrolu zaguenja ATM ABR. U sledeem
opisu draemo se ATM terminologije (na primer, koristiemo izraz komutator" umesto ruter"
i elija" umesto paket"). U usluzi ATM ABR, elije podataka prenose se od izvora do
odredita kroz niz usputnih komutatora. Izmeu elija podataka nalaze se takozvane elije za
upravljanje resursima, RM (Resource Management) elije; ubrzo emo videti a se te RM elije
mogu upotrebiti za razme-njivanje informacija o zaguenju meu raunarima i komutatorima.
Kada se RM elija nae na odreditu ona se okree" i vraa poiljaocu (nakon to odredite
even-
tualno promeni njen sadraj). I sam komutator moe da napravi RM eliju i poalje je direktno
izvoru. Tako se RM elije koriste i za direktne povratne informacije od mree i za povratne
informacije o mrei preko primaoca kao stoje prikazano na slici 3.49.
Kontrola zaguenja ATM ABR koristi pristup zasnovan na brzini. To jest, poiljalac
eksplicitno izraunava maksimalnu brzinu kojom moe da alje i tome se pri-lagoava. ABR
predvia tri mehanizma za signalizaciju zaguenja od komutatora prema primaocu:
EFCI bit. Svaka elija podataka sadri eksplicitnu indikaciju zaguenja unapred, EFCI
(explicitfonvardcongestion indication) bit. Zagueni mreni komutator moe da ukljui EFCI
bit u eliji podataka na 1 i tako upozori odredini raunar na zaguenje. Odredite mora da
proverava EFCI bit u svim primljenim elijama podataka. Kada na odredite stigne RM
elija a u prethodno primljenoj eliji podataka EFCI bit je bio jednak 1, tada odredite
ukljuuje bit za oznaavanje zaguenja (CI) u RM eliji na 1 i vraa RM eliju poiljaocu.
Pomou EFCI bita u elijama podataka i CI bita u RM elijama poiljalac moe da se
upozori na zaguenje u mrenom komutatoru.
Bitovi CI i NI. Kao stoje ve reeno, RM elije od poiljaoca ka primaocu nalaze se izmeu
elija podataka. Uestalost pojavljivanja RM elija moe da se podeava parametrom ija je
podrazumevana vrednost jedna RM elija na svake 32 elije podataka. Te RM elije sadre
bitove koje moe da ukljui zagueni mreni komutator: bit indikacije zaguenja, Cl
(congestion indication) i bit ne poveavaj", NI (no increase). Konkretno, komutator moe u
sluaju blagog zaguenja da ukljui na 1 bit NI u RM eliji koja prolazi, a u sluaju velikog
zaguenja, bit CI. Kada odredini raunar primi RM eliju, on e je vratiti poiljaocu sa
nedirnutim bitovima CI i NI (osim to se CI moe na odreditu promeniti u I kao rezultat
gore opisanog mehanizma EFCI).

144 144 144 144 POGLAVLJE 3 TRANSPORTNI SLOJ 3.7 . TCP KONTROLA ZAGUENJA 265 265 265 265

Postavljanje vrednosti ER. Svaka RM elija takoe sadri dvobajtno polje eksplicitne brzine
ER (explicit rate). Zagueni komutator moe da smanji vrednost u polju ER svake RM elije
u prolazu. Na taj nain, polje ER e sadrati minimalnu brzinu koju mogu da podre svi
komutatori na putanji od izvora do odredita.
ATM ABR izvor prilagoava brzinu kojom alje elije zavisno od vrednosti u poljima CI,
NI i ER u vraenoj RM eliji. Pravila za to podeavanje brzine su dosta sloena i pomalo
dosadna za objanjavanje. italac koga to zanima moe nai detalje u knjizi [Jain 1996],
3. 7 TCP kontrola zaguenja
U ovom odeljku vraamo se prouavanju TCP-a. Kako smo saznali u odeljku 3.5, TCP
obezbeduje uslugu pouzdanog transporta izmeu dva procesa koji se izvravaju na razliitim
raunarima. Jo jedna kljuna komponenta TCP-a je njegov mehanizam kontrole zaguenja. Kao
to je napomenuto u prethodnom odeljku, TCP mora da koristi kontrolu zaguenja sa kraja na
kraj, a ne kontrolu zaguenja pomou mree, poto sloj IP ne daje krajnjim sistemima nikakve
eksplicitne povratne informacije o zaguenju na mrei.
Pristup koji prihvata TCP je da se svaki poiljalac primora da ogranii brzinu kojom alje
saobraaj u svoju konekciju zavisno od uoenog zaguenja mree. Ako TCP poiljalac uoi daje
na putanji izmeu njega i odredita zaguenje malo, on poveava brzinu slanja; ako uoi da
postoji zaguenje, on je smanjuje. Ovaj pristup, meutim, otvara tri pitanja. Prvo, kako da TCP
poiljalac ogranii brzinu slanja saobraaja u svoju konekciju? Drugo, kako da TCP poiljalac
prepozna da postoji zaguenje na putanji izmeu njega i odredita? I tree, koji bi algoritam
poiljalac trebalo da koristi za menjanje brzine slanja zavisno od uoenog zaguenja sa kraja na
kraj? Sada emo ispitati ta tri pitanja u kontekstu algoritma TCP Reno za kontrolu zaguenja koji
se koristi u veini savremenih operativnih sistema [Padhye 2001]. Da bi opis bio to konkretniji
pretpostaviemo da TCP poiljalac alje veliku datoteku.
Pogledajmo prvo kako TCP poiljalac ograniava brzinu kojom alje saobraaj svoju
konekciju. U odeljku 3.5 videli smo da se svaka strana TCP konekcije sastoji od prijemne
privremene memorije, otpremne privremene memorije i nekoliko pro-menljivih (LastByteRead,
RcvWindow itd). TCP mehanizam za kontrolu zaguenja zahteva od svake strane u konekciji da
odrava jo jednu promenljivu, prozor zaguenja. Prozor zaguenja, oznaen sa CongWin
(congestion window), namee ogranienje za brzinu kojom TCP poiljalac moe da alje
saobraaj mreu. Konkretno, koliina nepotvrenih podataka kod poiljaoca ne srne da pree
manju od vrednosti CongWin i RcvWindow, to jest:
LastByteSent - LastByteAcked < min{CongWin, RcvWindow}
Da bismo se usredsredili na kontrolu zaguenja (za razliku od kontrole toka), sada emo
pretpostaviti daje prijemna TCP privremena memorija tako velika da se ogranienje prijemnog
prozora moe zanemariti; pa se tako koliina nepotvrenih podataka kod poiljaoca ograniava
jedino pomou vrednosti CongWin.
Navedena granica ograniava koliinu nepotvrenih podataka kod poiljaoca i tako
indirektno ograniava njegovu brzinu slanja. Da biste to videli, razmotrite konekciju sa
zanemarljivim gubicima i kanjenjem u prenosu paketa. Tada na poetku svakog povratnog puta
(RTT) gornje ogranienje dozvoljava poiljaocu da poalje u konekciju priblino CongWin
bajtova podataka, a na kraju RTT-a stiu mu potvrde za te podatke. Na taj nain brzina slanja
poiljaoca iznosi priblino Con-gWin/RTT- bajtova/sekundi. Prema tome, poiljalac moe da
podesi brzinu slanja podataka u konekciju podeavanjem vrednosti CongNin.
Razmotrimo sada kako TCP poiljalac utvruje da postoji zaguenje na putanji izmeu
njega i odredita. Definiimo dogaaj gubitka" kod TCP poiljaoca kao nastupanje tajm-auta ili
primanje tri istovetna ACK-a od primaoca (dogaaj tajm-aut opisali smo u odeljku 3.5.4 na slici
3.33 i kasnije dopunili taj opis na strani 245 dodavanjem brzog ponovnog slanja kada stignu tri
istovetna ACK-a). Kada postoji izuzetno zaguenje, doi e do prelivanja jedne ili vie
privremenih memorija u rute-rima na putanji, to e dovesti do isputanja datagrama. Isputeni
datagram zatim dovodi do dogaaja gubitka kod poiljaoca - bilo da doe do tajm-auta ili stignu
tri istovetna ACK-a - a poiljalac e to uzeti kao znak da postoji zaguenje na putanji od njega
do primaoca.
Poto smo razmotrili kako se zaguenje otkriva, razmotrimo sada povoljniji sluaj kada u
mrei nema zaguenja, tj. kada ne dolazi do gubitaka. U tom sluaju, TCP poiljalac e primiti
potvrde za prethodno nepotvrene segmente. Kao to emo videti, TCP e prihvatiti prispee
ovih potvrda kao znak daje sve u redu - da se segmenti poslati u mreu uspeno isporuuju na
odredite - pa e iskoristiti potvrde za poveanje prozora zaguenja (pa tako i brzinu slanja).
Obratite panju na to da e i poveanje prozora zaguenja biti relativno sporo ako potvrde stiu
relativno sporo (npr. ako putanja sa kraja na kraj ima veliko kanjenje ili sadri link malog
propusnog opsega). S druge strane, ako potvrde stiu brzo, prozor zaguenja e se poveavati
bre. Poto TCP koristi potvrde za pokretanje (ili za takt) poveanja prozora zaguenja, za TCP
kaemo da ima vlastiti takt.
Sada moemo da razmotrimo algoritam koji TCP poiljalac koristi da bi upravljao brzinom
slanja u funkciji uoenog zaguenja. To je uveni TCP algoritam za kontrolu zaguenja. Taj
algoritam ima tri glavne komponente: (1) aditivno uveanje, multiplikativno smanjenje, (2) sporo
pokretanje i (3) reagovanje na dogaaj tajm-aut.

266 266 266 266
POGLAVLJE 3 TRANSPORTNI SLOJ 3.7 . TCP KONTROLA ZAGUENJA 145 145 145 145

Aditivno uveanje, multiplikativno smanjenje
Osnovna zamisao na kojoj se zasniva TCP kontrola zaguenja jeste da poiljalac smanji brzinu
slanja (smanjenjem veliine prozora zaguenja, CongWin) kada doe do gubitka. Poto se
ostalim TCP konekcijama koje prolaze kroz iste zaguene rutere verovatno takoe dogaaju
gubici, i one e verovatno smanjiti svoje brzine slanja smanjenjem vlastitih vrednosti CongWin.
Sveukupni efekat bie da izvori putanja koje prolaze kroz zaguene rutere smanje brzinu kojom
alju saobraaj u mreu to bi trebalo da smanji ukupno zaguenje tih rutera. Ali, za koliko bi
trebalo da TCP poiljalac smanji prozor zaguenja kada nastupi dogaaj gubitka? TCP koristi
takozvani pristup multiplikativnog smanjenja" tako to prepolovi trenutnu vrednost CongWin
svaki put kada nastupi gubitak. Prema tome, ako je vrednost CongWin trenutno 20 kilobajtova,
pa se otkrije gubitak, CongWin se smanjuje na pola, tj. na 10 kilobajtova. Ako doe do jo
jednog gubitka, CongWin se dalje smanjuje na 5 kilobajtova. Vrednost CongVJin moe i dalje
da pada, ali se ne dozvoljava da padne ispod jednog MSS. (Ovo je gruba slika" naina na koji
se prozor zaguenja menja nakon dogaaja gubitka. U sutini, stvari su malo sloenije. Kao to
emo uskoro videti, vrednost CongWin nakon tajm-auta pada na 1 MSS, a zatim se brzo pove-
ava do polovine svoje prethodne vrednosti.)
Poto smo opisali kako TCP poiljalac smanjuje brzinu slanja kada uoi zaguenje,
prirodno je nakon toga razmotriti kako da TCP povea brzinu slanja ako uoi da nema
zaguenja, tj. ako ne dolazi do gubitaka. Obrazloenje za poveanje brzine je da ako nije uoeno
zaguenje, znai da verovatno postoji dostupna (neupotrebljena) propusna mo koju bi TCP
konekcija jo mogla da upotrebi. U takvim uslovima, TCP polako poveava prozor zaguenja,
obazrivo istraujui" da li postoji dodatna propusna mo na putanji sa kraja na kraj. TCP
poiljalac to postie poveanjem vrednosti CongWin po malo svaki put kada primi ACK, tako da
povea CongWin pribliilo za po jedan MSS za svaki vrednosni interval povratnog puta [RFC
2581]. To moe da se postigne na nekoliko naina; uobiajeno je da TCP poiljalac povea
CongVJin za MSS-(MSS/ CongWin) bajtova kad god primi novu potvrdu. Na primer, ako MSS
iznosi 1460 bajtova a CongVJin 14 600 bajtova, znai da se u jednom RTT-u alje 10
segmenata. Svaki put kada stigne ACK (pretpostavlja se po jedan ACK za svaki segment) prozor
zaguenja poveava se za 1/10 MSS, tako da e nakon potvrda za svih 10 segmenata vrednost
prozora zaguenja biti vea za 1 MSS, kao to se i elelo.
Sve u svemu, TCP poiljalac aditivno uveava brzinu kada uoi da na putanji s kraja na
kraj nema zaguenja, a multiplikativno smanjuje brzinu kada uoi (po dogaaju gubitka) da je
putanja zaguena. Iz tog razloga, TCP kontrola zaguenja esto se naziva algoritmom AIMD
(additive-increase, multiplicative-decrease). U TCP-ovom protokolu kontrole zaguenja faza
linearnog poveanja poznata je kao izbegavanje zaguenja. Vrednost CongVJin stalno prolazi
kroz cikluse tokom kojih se linearno poveava, a zatim naglo smanjuje na polovinu trenutne
vrednosti (ako nastupi dogaaj gubitka), pa u dugotrajnim TCP konekcijama prati ablon zubaca
na testeri, kao stoje prikazano na slici 3.50.
Sporo pokretanje
Na poetku TCP konekcije, vrednost CongVJin obino se postavlja na jedan MSS [RFC 3390],
to daje poetnu brzinu slanja od priblino MSS/RTT. Na primer, ako je MSS = 500 bajtova, a
RTT = 200 ms, imaemo poetnu brzinu slanja od priblino svega 20 kb/s. Poto propusni opseg
dostupan konekciji moe da bude mnogo vei od MSS/RTT, bilo bi teta da se brzina uveava
samo linearno jer bi se tako previe ekalo da ona doe do nekog znatnijeg nivoa. Zato u toj
poetnoj fazi umesto linearnog poveanja brzine, TCP poiljalac poveava brzinu
eksponencijalno tako to za svaki RTT udvostruava vrednost CongWin. TCP poiljalac
nastavlja sa eksponencijalnim poveavanjem brzine slanja dok ne nastupi dogaaj gubitka kada
se CongVJin smanjuje na polovinu, a nakon toga raste linearno kao to smo ranije opisali. Prema
tome, tokom ove inicijalne faze, koja se naziva sporim poetkom (shw staru SS), TCP poiljalac
poinje slanje malom brzinom (otuda naziv ,jpori poetak"), ali eksponencijalno poveava brzinu
slanja. Poiljalac postie eksponencijalni rast tako to uveava vrednost CongVJin za jedan MSS
za svaku primljenu potvrdu poslatog segmenta. Konkretno, TCP alje prvi segment u mreu i
eka na potvrdu. Ako se taj segment potvrdi pre dogaaja gubitka, TCP poiljalac poveava
prozor zaguenja za jedan MSS i alje dva segmenta maksimalne veliine. Ako se ti segmenti
potvrde pre dogaaja gubitka, poiljalac poveava prozor zaguenja za po jedan MSS za svaki
potvreni segment, ime se dobija prozor zaguenja od etiri MSS-a pa se alju etiri segmenta
maksimalne veliine. Taj postupak se nastavlja sve dok potvrde stiu pre dogaaja gubitka. Na
taj nain se vrednost CongVJin u fazi sporog poetka udvostruava za svaki RTT.

1 11 146 46 46 46 POGLAVLJE 3 TRANSPORTNI SLOJ
3.7 . TCP KONTROLA ZAGUENJA 269J

Reagovanje na dogaaj tajm-aut
Do sada smo opisali ponaanje TCP-ovog prozora zaguenja tako to on od 1 MSS raste
eksponencijalno (tokom sporog poetka) dok ne nastupi dogaaj gubitka kada poinje ablon AIMD
testere. Mada je taj prikaz prilino precizan, ne bi bilo u redu da izostavimo injenicu kako TCP
kontrola zaguenja razliito reaguje na dogaaj gubitka koji nastupa zbog tajm-auta, a drugaije na
gubitak otkriven prijemom tri istovetna ACK-a. Kada primi tri istovetna ACK-a, TCP se ponaa kao
to smo upravo opisali - prozor zaguenja se prepolovi, a zatim se linearno poveava. Ali, ako
nastupi dogaaj tajm-aut, TCP poiljalac se vraa u fazu sporog poetka - tj. podeava prozor
zaguenja na 1 MSS, a zatim ga eksponencijalno poveava. Prozor i dalje eksponencijalno raste sve
dok CongWin ne dostigne polovinu vrednosti koju je imao pre tajm-auta. Od tog trenutka, CongvJin
raste linearno, kao to bi nastavio nakon tri identina ACK-a.
TCP upravlja tom sloenijom dinamikom pomou jedne promenljive po imenu Threshold (prag)
koja odreuje veliinu prozora na kojoj e se prekinuti spori poetak i poeti izbegavanje zaguenja.
Promenljivoj Threshold se daje velika poetna vrednost (u praksi 65 kilobajtova [Stevens 1994]),
tako da na poetku nema efekta. Kad god nastupi dogaaj gubitka, Threshold poprima polovinu
trenutne vrednosti CongMin. Na primer, ako je neposredno pre dogaaja gubitka prozor zaguenja
bio 20 kilobajtova, vrednost Threshold postaje 10 kilobajtova i ostaje tolika sve do sledeeg dogaaja
gubitka.
Poto smo opisali promenljivu Threshold, sada moemo tano da opiemo kako se ponaa
CongWin nakon dogaaja tajm-aut. Kao stoje upravo napomenuto, nakon tajm-auta TCP poiljalac
prelazi u fazu sporog poetka. Dok se nalazi u toj fazi on eksponencijalno poveava vrednost
CongWin sve dok CongWin ne dostigne vrednost Threshold. Kada CongWin dostigne Threshold,
TCP prelazi u fazu izbegavanja zaguenja kada CongWin raste linearno, kao to smo ranije opisali.
Sve u svemu, TCP-ov algoritam za kontrolu zaguenja ukratko je prikazan u tabeli 3.3. Sada je
prirodno da se razmotri zato se TCP-ova kontrola zaguenja drugaije ponaa nakon dogaaja
tajm-aut nego nakon primanja tri istovetna ACK-a. Konkretno, zato se TCP poiljalac ponaa
drastino nakon dogaaja tajm-aut kada smanjuje prozor zaguenja na 1 MSS, dok nakon primanja
tri istovetna ACK-a smanjuje prozor zaguenja samo na polovinu? Zanimljivo je da u staroj verziji
TCP-a, poznatoj kao TCP Tahoe, nakon svake vrste dogaaja gubitka, prozor zaguenja se
bezuslovno smanjivao na 1 MSS i prelazilo u fazu sporog poetka. Kao to smo videli, u novijoj
verziji TCP-a, poznatoj kao TCP Reno, izbacuje se faza sporog poetka nakon tri istovetna ACK-a.
Obrazloenje za ukidanje sporog poetka u tom sluaju jeste da mada je paket izgubljen, pristizanje
tri istovetna ACK-a ukazuje na to da su neki segmenti (konkretno, ta tri dodatna segmenta nakon
izgubljenog) ipak primljeni na strani poiljaoca. Prema tome, za razliku od tajm-auta, mrea je u
stanju da isporuuje bar neke segmente, iako su neki izgubljeni zbog zaguenja. Ovo izbacivanje
faze sporog poetka nakon tri istovetna ACK-a naziva se brzi oporavak.
Tabela 3.3 Tabela 3.3 Tabela 3.3 Tabela 3.3 Kontrola zaguenja TCP poiljaoca [RFC 2581], pod pretpostavkom da poetna vrednost
CongVVin iznosi MSS, da je poetna vrednost Threshold velika (npr. 65 kilobajta
[Stevens 1 11 1994]) i da TCP poiljalac kree iz stanja sporog poetka. Prikazuje se stanje
TCP poiljaoca neposredno pre nastupanja dogaaja. Ostale detalje nai ete u [RFC
2581].
Na slici 3.51 prikazane su promene TCP prozora zaguenja u verzijama Reno i Tahoe. Na ovoj
slici, prag na poetku iznosi 8 MSS. Prozor zaguenja se poveava eksponencijalno tokom
sporog poetka i dostie prag pri etvrtom povratnom putu. Nakon toga, prozor zaguenja raste
linearno dok ne doe do tri istovetna ACK-a, malo nakon povratnog puta broj 8. Obratite panju na to
daje u trenutku ovog gubitka prozor zaguenja jednak 12 - MSS. Prag zatim dobija vrednost 0,5
CongWin = 6 MSS. U verziji TCP Reno, prozor zaguenja dobija vrednost CongWin = 6 MSS
i nakon toga raste linearno. U verziji TCP Tahoe; prozor zaguenja dobija vrednost 1 MSS i raste
eksponencijalno dok ne dostigne prag. Ovaj algoritam za kontrolu zaguenja uspostavio je V.
Jakobson [Jacobson 1988]; niz modifikacija Jackbsonovog poetnog algoritma opisan je u knjigama
[Stevens 1994] i [RFC 2581].
Kao stoje gore napomenuto, veina TCP implementacija trenutno koristi algoritam Reno. Za
algoritam Reno predloeno je mnogo varijanti [RFC 2582; RFC 2018], Predloeni algoritam TCP
Vegas [Brakmo 1995; Ahn 1995] pokuava da izbegne zaguenje, a da istovremeno odri dobra
propusnu mo. Osnovna zamisao algoritma Vegas je da se (1) zaguenje u ruterima izmeu izvora i
odredita otkrije


pre nego to doe do gubitka paketa i da se (2) brzina smanji linearno kada se otkrije da preti
gubitak paketa. Gubitak paketa predvia se posmatranjem trajanja povratnog puta. to je vei
RTT paketa, znai da je vee i zaguenje rutera.

Grubi opis TCP propusne moi
S obzirom na testerasti grafikon ponaanja TCP-a, prirodno je razmotriti kolika bi bila prosena
propusna mo (tj. prosena brzina) dugotrajne TCP konekcije. U ovoj analizi zanemariemo faze
sporog poetka do kojih dolazi nakon dogaaja tajm-aut. (Te su faze obino veoma kratke poto
poiljalac izlazi iz njih eksponencijalnom brzinom.) Tokom pojedinanog intervala povratnog
puta brzina kojom TCP alje podatke zavisi od prozora zaguenja i od trenutnog RTT-a. Kao to
je ve reeno, kada prozor iznosi w bajtova, a trenutno vreme povratnog puta je RTT sekundi,
brzina prenosa TCP-a je priblino w/RTT. TCP tada pokuava da upotrebi dodatni propusni
opseg poveavanjem vrednosti w za jedan MSS kod svakog RTT-a dok se ne pojavi gubitak.
Oznaite sa W vrednost w u trenutku gubitka. Pod pretpostavkom da su RTT i W priblino
konstantni tokom cele konekcije, brzina TCP prenosa kree se od Wl(2 RTT) 6 0 WIRTT.
Ove pretpostavke daju nam krajnje pojednostavljeni grubi model ponaanja TCP-ovog
stacionarnog stanja. Mrea isputa paket iz konekcije kada brzina dostigne WiRTT\ brzina se tada
smanjuje na pola i ponovo poveava za jedan MSSIRTT kod svakog RTT-a dok ponovo ne
dostigne WIRTT. Ovaj proces se stalno ponavlja. Poto se propusni opseg TP-a (tj. njegova
brzina) poveava linearno izmeu dve krajnje vrednosti, imamo:
Pomou ovog potpuno idealizovanog modela dinamike stacionarnog stanja TCP-a,
moemo takoe da izvedemo jedan zanimljiv izraz koji povezuje uestalost gubitaka u jednoj
konekciji sa njenim dostupnim propusnim opsegom [Mahdavi 1997]. Ovo izvoenje skicirano
je u problemima za domai zadatak. Jedan sloeniji model koji se empirijski slae sa izmerenim
podacima je [Padhve 2000],
Budui TCP
Vano je shvatiti da se TCP kontrola zaguenja tokom godina razvijala i da se jo uvek razvija.
Prikaz TCP kontrole zaguenja kakva je bila krajem 1990-ih godina moe se nai u knjizi [RFC
2581]; opis najnovijeg razvoja u domenu TCP kontrole zaguenja moete nai u knjizi [Floyd
2001]. To stoje bilo dobro za Internet dok je veina TCP konekcija prenosila SMTP, FTP i
Telnet saobraaj ne mora biti dobro za dananji Internet u kojem dominira HTTP ili za Internet
u budunosti koji e podravati ko zna kakve vrste usluga.
Potrebu da se TCP stalno razvija moemo da ilustrujemo razmatranjem TCP konekcija
velike brzine koje su potrebne aplikacijama u "grid" raunarskim sistemima [Foster 2002]. Na
primer, razmotrite TCP konekciju sa segmentima od 1500 bajtova gde RTT iznosi 100 ms i
pretpostavimo da kroz tu konekciju hoemo da aljemo podatke brzinom od 10 Gb/s. S obzirom
na [RFC 3649], primeujemo da prema gornjem obrascu za propusni opseg u TCP-u, da bi se
postigao propusni opseg od 10 Gb/s, prosena veliina prozora zaguenja bi morala da iznosi 83
333 segmenata. To je veoma mnogo segmenata pa je velika verovatnoa da se neki od njih ne
izgubi. ta bi se dogodilo u sluaju gubitka? Ili, drugaije reeno, koji deo preneiih segmenata
moe da se izgubi a da TCP algoritam kontrole zaguenja opisan u tabeli 3.3 ipak omogui
eljenu brzinu od 10 Gb/s? U domaim zadacima za ovo poglavlje izveden je obrazac za
propusni opseg TCP konekcije u funkciji uestalosti gubitaka (l), trajanja povratnog puta (RTT)
i maksimalne veliine segmenta (MSS):
Iz ovog obrasca se vidi da za postizanje propusnog opsega od 10 Gb/s algoritam za
kontrolu zaguenja dananjeg TCP-a ne moe da tolerie verovatnou gubitka segmenata veu
od 2 10'
10
(to odgovara jednom dogaaju gubitka na svakih 5 000 000 000 segmenata) a to je
veoma mala verovatnoa. Ta injenica je mnoge istraivae usmerila na istraivanje novih
verzija TCP-a specifino projektovanih za takva okruenja sa veoma velikim brzinama; opise
tih pokuaja moete pronai u knjizi [Jin 2004; Kellz 2003].

3 . 7 . 1 Fer ponaanje
Razmotrimo KTCP konekcija od kojih svaka ima drugaiju putanju sa kraja na kraj, ali sve
prolaze kroz link koji predstavlja usko grlo sa brzinom prenosa od R b/s. (Link smatramo uskim
grlom ako taj link ima najmanji kapacitet prenosa za sve

148 148 148 148 POGLAVLJE 3 TRANSPORTNI SLOJ 3.7 TCP KONTROLA ZAGUENJA 273 273 273 273

konekcije, a svi ostali linkovi u poreenju sa njim nisu zagueni i imaju dovoljan kapacitet
prenosa.) Pretpostavimo da svaka konekcija prenosi veliku datoteku i da kroz link koji
predstavlja usko grlo ne prolazi nikakav UDP saobraaj. Za mehanizam kontrole zaguenja
kaemo daje fer ako je prosena brzina prenosa svake konekcije priblino R/K; tj. ako svaka
konekcija dobija podjednak deo propusnog opsega linka.
Da lije TCP-ov algoritam aditivnog uveanja i multiplikativnog smanjenja fer, pogotovo
ako uzmemo u obzir da se razliite TCP konekcije pokreu u razliito vreme i u nekom
odreenom trenutku mogu da imaju razliite veliine prozora? Knjiga [Chiu 1989] sadri
elegantno i lako shvatljivo objanjenje o tome kako TCP-ova kontrola zaguenja tei da svim
TCP konekcijama koje se nadmeu za propusni opseg linka koji predstavlja usko grlo obezbedi
jednak udeo tog propusnog opsega.
Razmotrimo jednostavan sluaj kada dve TCP konekcije dele jedan jedini link sa brzinom
prenosa R, kao to je prikazano na slici 3.52. Pretpostaviemo da obe konekcije imaju istu
vrednost MSS i RTT (pa tako imaju istu veliinu prozora zaguenja i takoe istu propusnu mo),
da treba da alju velike koliine podataka, a da kroz taj zajedniki link ne prolaze druge TCP
konekcije niti UDP datagrami. Osim toga, zanemariemo TCP-ovu fazu sporog poetka i
pretpostaviti da TCP konekcije stalno tunkcioniu u reimu izbegavanja zaguenja (aditivno
poveavanje, multipli-kativno smanjivanje).
Na slici 3.53 ucrtane su propusne moi koje su ostvarile dve TCP konekcije. Ako TCP treba
da deli propusni opseg linka podjednako na obe konekcije, ostvarena propusna mo nala bi se
oko simetrale od 45 stepeni (jednaki delovi propusnog opsega) koja poinje iz koordinatnog
poetka. U idealnom sluaju, zbir obe propusne moi trebalo bi da iznosi R. (U svakom sluaju,
nije ba poeljno da obe konekcije dobijaju podjednake delove kapaciteta linka a da ti delovi
budu jednaki nuli!) Prema tome, cilj bi trebalo da bude da se ostvarene propusne moi nau
negde blizu
preseka linije .jednaki delovi propusnog opsega" i linije korienje celog propusnog opsega" na
slici 3.53.
Pretpostavimo da su veliine TCP prozora takve da u datom trenutku konekcije 1 i 2
ostvaruju propusne moi oznaene takom A na slici 3.53. Postoje koliina propusnog opsega
linka koju ukupno troe te dve konekcije manja od R, nee doi do gubitaka i obe konekcije e,
prema TCP-ovom algoritmu za izbegavanje zaguenja, poveati svoje prozore za 1 MSS kod
svakog RTT-a. Prema tome, sveukupna propusna mo obe konekcije se kree uz liniju od 45
stepeni (jednako poveanje kod obe konekcije), poevi od take A.. U jednom trenutku,
propusni opseg linka koji ukupno troe obe konekcije prei e R, pa e doi do gubitka paketa.
Uzmimo da u konekcijama 1 i 2 doe do gubitka paketa kada one ostvare propusne moi
oznaene takom B. Konekcije 1 i 2 zatim smanjuju svoje prozore za faktor 2. Tako dobijene
ostvarene propusne moi oznaene su takom C, na polovini vektora koji poinje u taki B i
zavrava se u koordinatnom poetku. Poto je ukupno utroeni propusni opseg u taki C manji
od R, obe konekcije ponovo poveavaju propusne moi du linije pod uglom od 45 stepeni koja
poinje od take C. U jednom trenutku, ponovo e doi do gubitka, na primer u taki D, pa e
obe konekcije ponovo smanjiti prozore za faktor 2, i tako dalje. Propusni opseg koji ostvaruju
obe konekcije u krajnjoj liniji kree se du linije jednakih delova propusnog opsega. Obe
konekcije e teiti tom ponaanju bez obzira na to gde se one nalaze u dvodimenzionalnom
prostoru! Mada

3.7 . TCP KONTROLA ZAGUENJA 149
i
J149 POGLAVUE 3 TRANSPORTNI SLOJ

se ovaj scenario zasniva na nizu ideaiizovanih pretpostavki, on ipak daje oseaj o tome kako
TCP postie da konekcije dobiju podjednake delove propusnog opsega.
U naem idealizovanom scenariju pretpostavili smo da kroz link koji predstavlja usko grlo
prolaze samo TCP konekcije, da konekcije imaju istu vrednost RTT i da je jednom paru raunara
i odredita pridruena samo jedna TCP konekcija. U praksi se ti uslovi obino ne ostvaruju, pa
aplikacije klijent/server mogu da dobiju veoma razliite delove propusnog opsega linka.
Konkretno, pokazalo se da kada vie konekcija deli zajedniko usko grlo, sesije sa manjim
RTT-om bre uspevaju da prigrabe dostupni propusni opseg na tom linku im se on oslobodi (tj.
bre otvaraju svoje prozore zaguenja) i tako ostvaruju veu propusnu mo od konekcija sa
veim RTT-om [Lakshman 1997].
Fer ponaanje i UDP
Upravo smo videli kako TCP kontrola zaguenja ureuje brzinu prenosa putem mehanizma sa
prozorom zaguenja. Mnoge multimedijalne aplikacije, kao to je Internetovo telefoniranje ili
video konferencije, se upravo iz tog razloga ne izvravaju preko TCP-a - one ne ele da se
njihova brzina prenosa gui, ak i kada je mrea veoma zaguena. Umesto toga, ove aplikacije
vie vole da se izvravaju preko UDP-a, koji nema ugraenu kontrolu zaguenja. Kada se
izvravaju preko UDP-a, aplikacije mogu da ubacuju audio i video konstantnom brzinom u
mreu i povremeno gube pakete, a ne da smanjuju brzinu na fer" nivo u trenucima zaguenja da
ne bi gubile pakete. Iz perspektive TCP-a, multimedijalne aplikacije koje se izvravaju preko
UDP-a nisu fer - one ne sarauju sa drugim konekcijama niti podeavaju svoju brzinu prenosa na
odgovarajui nain. Danas veliko podruje istraivanja predstavlja razvoj mehanizama za
kontrolu zaguenja na Internetu kojim bi se spreilo da UDP saobraaj potpuno blokira propusnu
mo Interneta [Floyd 1999; Floyd 2000; Kohler2004].
. Fer ponaanje i paralelne TCP konekcije
Ali, ak i kada bismo mogli da primoramo UDP saobraaj na fer ponaanje, problem fer
ponaanja jo ne bi bio potpuno reen zato to nita ne spreava TCP aplikacije da koriste vie
paralelnih konekcija. Na primer, itai Weba esto koriste vie paralelnih TCP konekcija za
prenos vie objekata jedne veb stranice. (U veini itaa se taan broj viestrukih konekcija
moe konfigurisati.) Kada jedna aplikacija koristi vie paralelnih konekcija, ona u zaguenom
linku dobija vei deo propusnog opsega. Na primer, razmotrite link brzine R koji podrava devet
aktivnih klijent/server aplikacija, tako da svaka aplikacija koristi jednu TCP konekciju. Ako se
prikljui jedna nova aplikacija i takoe koristi jednu TCP konekciju, svaka e aplikacija dobijati
priblino istu brzinu slanja od R/10. Ali, ako ova nova aplikacija koristi 11 paralelnih TCP
konekcija, tada e njoj biti dodeljeno vie od R/2, to nije fer. Poto je veb saobraaj veoma
prisutan na Internetu, viestruke paralelne konekcije nisu neuobiajene.
3 . 7 . 2 Modeliranje TCP kanjenja
Ovo poglavlje zakljuujemo nekim jednostavnim modelima za izraunavanje vremena
potrebnog da TCP poalje neki objekat (kao to je slika, tekstualna datoteka ili MP3). Za dati
objekat definie se vreme ekanja kao vreme od trenutka kada klijent inicira TCP konekciju do
trenutka kada primi zatraeni objekat u celosti. Modeli koji su ovde predstavljeni pruaju
znaajan uvid u kljune komponente vremena ekanja, ukljuujui poetno TCP
sinhronizovanje, TCP-ov spori poetak i vreme za prenos objekta.
Ova jednostavna analiza poinje od pretpostavke da mrea nije zaguena, tj. da TCP
konekcija koja prenosi objekat ne mora da deli propusni opseg linka sa drugim TCP ili UDP
saobraajem. Isto tako, da se ne bi zamagljivala glavna pitanja, analizu vrimo u kontekstu
jednostavne mree sa jednim linkom, kao stoje prikazano na slici 3.54. (Ovaj link bi mogao biti
model jednog uskog grla na putanji sa kraja na kraj. Pogledajte takoe probleme za domai
zadatak gde se nalazi eksplicitno proirenje na sluaj sa vie linkova.)
Takoe polazimo od sledeih pretpostavki koje pojednostavljuju sluaj:
Koliina podataka koju poiljalac alje ograniava se jedino veliinom njegovog prozora
zaguenja. (Prema tome, prijemne TCP privremene memorije su velike.)
Paketi se ne gube niti se oteuju, pa nema ponovnih slanja.
Sva dodatna preoptereen)'a protokolskim zaglavljima - ukljuujui zaglavlja TCP-a, IP-a i
sloja veze - zanemarljiva su pa ih ignoriemo.
Objekat (tj. datoteka) koji treba preneti sastoji se od celog broja segmenata veliine MSS
(maksimalna veliina segmenta).
Jedini paketi ije se vreme prenosa ne zanemaruje su paketi koji prenose TCP segmente
maksimalne veliine. Poruke sa zahtevima, potvrde i segmenti za uspostavljanje TCP
konekcije su mali, pa imaju zanemarljivo vreme prenosa.
Poetni prag u TCP mehanizmu za kontrolu zaguenja ima veliku vrednost koju prozor
zaguenja nikada ne dostie.


Takoe uvodimo sledee oznaavanje:
Veliina objekta koji treba preneti je O bitova.
MSS (maksimalna veliina segmenta) iznosi S bitova (na primer, 536 bajta).
Brzina prenosa na linku od servera do klijenta iznosi R b/s.
Pre nego to ponemo stvarnu analizu, pokuajmo donekle da steknemo oseaj za problem.
Razmotrimo koliko bi bilo vreme ekanja da nema ogranienja prozora zaguenja, tj. kada bi
serveru bilo dozvoljeno da alje segmente jedan za drugim sve dok ne poalje ceo objekat. Da
bismo odgovorili na ovo pitanje, prvo obratimo panju na to daje za iniciranje TCP konekcije
potreban jedan RTT. Nakon toga, klijent alje zahtev za objekat (koji se lepuje na treem
segmentu TCP-ovog sinhroni-zovanja u tri koraka). Posle ukupno dva RTT-a, klijent poinje da
prima podatke od servera. Klijent prima podatke od servera u periodu od O/R, vreme potrebno
serveru da poalje ceo objekat. Prema tome, u sluaju kada prozor zaguenja ne ograniava
brzinu, ukupno vreme ekanja je 2 RTT+ O/R. Ovo predstavlja donju granicu; procedura sporog
poetka sa njenim dinamikim prozorom zaguenja svakako e produiti ovo vreme ekanja.

Statiki prozor zaguenja
Mada TCP koristi dinamiki prozor zaguenja, pouno je prvo analizirati sluaj sa statikim
prozorom zaguenja. Neka W, pozitivan ceo broj, oznaava statiki prozor zaguenja fiksne
veliine. Kod statikog prozora zaguenja serveru se ne dozvoljava da ima vie od W
nepotvrenih zaostalih segmenata. Kada server primi zahtev od klijenta, on odmah alje klijentu
W segmenata jedan za drugim. Server nakon toga alje u mreu po jedan segment za svaku
potvrdu koju primi od klijenta. Server nastavlja da alje po jedan segment za svaku potvrdu dok
ne poalje sve segmente iz . objekta. Potrebno je razmotriti dva sluaja:
1. WS/R > RTT + S/R. U ovom sluaju, server prima potvrdu za prvi segment prvog prozora
pre nego to dovri prenos prvog prozora.
2. WS/R < RTT + S/R. U ovom sluaju, server napre prenese koliinu segmenata dovoljnu za
prvi prozor pa tek potom primi potvrdu za prvi segment tog prozora.
Razmotrimo najpre prvi sluaj,.prikazan na slici 3.55. Na ovoj slici je veliina prozora W=
4 segmenata, Jedan RTT je potreban za iniciranje TCP konekcije. Nakon toga, klijent alje
zahtev za objekat (koji se lepuje na treem segmentu TCP-ovog sinhronizovanja u tri koraka).
Nakon ukupno dva RTT-a, klijent poinje da prima podatke od servera. Segmenti dolaze
povremeno od servera svakih S/R sekundi, a
klijent potvruje svaki segment koji primi. Kada server primi prvu potvrdu pre nego to dovri
slanje onoliko segmenata koliko staje u prozor, server nastavlja da alje segmente i nakon to
popuni prvi prozor. S obzirom na to da potvrde stiu do servera svakih S/R sekundi od trenutka
kada stigne prva potvrda, server neprekidno alje segmente dok ne poalje ceo objekat. Prema
tome, poto server pone da alje objekat brzinom R, on i nastavlja da ga alje istom brzinom
dok ne prenese ceo objekat. Znai, vreme ekanja iznosi 2 RTT+ O/R.

1 151 151 151 151 POGLAVLJE 3 TRANSPORTNI SLOJ 3.7 . TCP KONTROLA ZAGUENJA 151 151 151 151

Razmotrimo sada drugi sluaj koji je prikazan na slici 3.56. Na ovoj slici je veliina prozora
W~ 2 segmenta. I opet, nakon ukupno dva RTT-a klijent poinje da prima segmente sa servera.
Ti segmenti stiu svakih S/R sekundi, a klijent potvruje svaki segment koji primi od servera.
Ali, sada server zavrava prenos prvog prozora pre nego to od klijenta stigne prva potvrda.
Prema tome, poto poalje prozor, server mora da se zaustavi i saeka neku potvrdu da bi
nastavio sa slanjem. Kada potvrda na kraju stigne, server alje klijentu novi segment. Nakon prve
potvrde dolazi pun prozor potvrda u razmacima od po S/R sekundi. Za svaku od ovih potvrda
server alje tano jedan segment. Prema tome, server se naizmenino nalazi u dva stanja: stanju
slanja tokom kojeg prenosi W segmenata i stanju ekanja, kada nita ne alje
i eka na potvrde. Vreme ekanja jednako je 2 RTT plus vreme potrebno serveru da prenese
objekat, O/R, plus vreme koje server provede u stanju ekanja. Da bismo odredili vreme koje
server provodi u stanju ekanja neka K bude broj prozora podataka koji pokrivaju objekat; tj. K
= 0/WS (ako O/IVS nije ceo broj treba zaokruiti K navie do prvog celog broja). Server se
nalazi u stanju ekanja izmeu prenosa pojedinanih prozora, tj. K- 1 puta a svako ekanje traje
RTT - (W-1)S/R (slika 3.56). Prema tome, za drugi sluaj je
Sastavljanjem oba izraza dobijamo
gde je [xy = max(A-,0). Obratite panju na to da vreme ekanja ima tri komponente: 2RTT za
uspostavljanje TCP konekcije, za zahtev i poetak primanja objekta; O/R, vreme potrebno
serveru da prenese objekat; i, na kraju, ( K - } ) {S/R + RTT - WSf R]
+
, vreme koje server
provede u ekanju.
Ovim zakljuujemo analizu statikih prozora. Analiza za dinamike prozore koja sledi je
sloenija, ali postoji paralela sa ovom analizom statikih prozora.

Dinamiki prozor zaguenja
Sada emo u modelu vremena ekanja uzeti u obzir TCP-ov dinamiki prozor zaguenja. Znate
da server poinje sa prozorom zaguenja od jednog segmenta i alje klijentu jedan segment.
Kada primi potvrdu za taj segment, on poveava prozor zaguenja na dva segmenta i alje
klijentu dva segmenta (u razmaku od S/R sekundi). Kada primi potvrde za ta dva segmenta,
poveava prozor zaguenja na etiri segmenta i alje klijentu etiri segmenta (opet u razmaku od
S/R sekundi), Postupak se nastavlja tako to se prozor zaguenja udvostruava za svaki RTT.
Dijagram vremenskog rasporeda za TCP prikazan je na slici 3.57.
Obratite panju na to daje O/S broj segmenata u objektu; u gornjem dijagramu je O/S = 15.
Razmotrite broj segmenata u svakom prozoru. Prvi prozor sadri jedan segment, drugi prozor
sadri dva segmenta, a trei prozor sadri etiri segmenta. U optem sluaju, k-ti prozor sadri
2
k
-' segmenata. Neka K bude broj prozora koji pokrivaju objekat; u prethodnom dijagramu, K =
4 . U optem sluaju moemo izraziti K zavisno od O/S na sledei nain:

3.7 . TCP KONTROLA ZAGUENJA 2Bl \

= min [ k : 2* - 1 > 0/S)
= min { k : k > \og2 (0/S+1 ) }
= Tlog2 (0/S + 1)1

Poto prenese pun prozor podataka, server moe da stane (tj. prestane da prenosi) dok eka
na potvrdu. Na slici 3,57 server staje nakon to prenese prvi i drugi prozor, ali ne i nakon treeg.
Sada emo izraunati ukupno vreme stajanja nakon prenosa /c-tog prozora. Od trenutka kada
server pone da prenosi /c-ti prozor do trenutka kada primi potvrdu za prvi segment u prozoru,
protekne S/R + RTT. Vreme za prenos k-tog prozora iznosi (S/R)2
k
~'. Vreme stajanja je razlika
izmeu te dve vrednosti, to jest
Server moe eventualno da stoji nakon prenosa svakog od prvih K~\ prozora. (Server
zavrava zadatak nakon prenosa AT-tog prozora.) Sada moemo izraunati vreme ekanja za
prenos cele datoteke. Vreme ekanja ima tri komponente: 2RTT za uspostavljanje TCP
konekcije i zahtevanje datoteke; O/R, vreme za prenos objekta; i zbii svih vremena stajanja.
Prema tome,
italac bi trebalo da uporedi gornju jednainu sa jednainom za vreme ekanja kod
statikog prozora zaguenja; svi elementi su potpuno jednaki, osim to se WS/R iz statikog
prozora zamenjuje sa2*"'(o7#) za dinamiki prozor. Da bismo dobili sve-deniji izraz za vreme
ekanja, neka Q predstavlja broj intervala stajanja na serveru kada bi se objekat sastojao od
beskonanog broja segmenata. Da bismo napravili izvoenje slino onome za K (proitajte
probleme za domai zadatak), dobijamo:
Stvarni broj ekanja kod servera je P = min {Q,K-\}. Na slici 3.57 to je P = Q=- 2 .
Kombinovanjem gornjih jednaina (proitajte probleme za domai zadatak) dobijamo sledei
izraz za vreme ekanja u zatvorenom obliku:

282 POGLAVLJE 3 TRANSPORTNI SLOJ 3.8 . TCP KONTROLA ZAGUENJA 153 153 153 153

Prema tome, da bi se izraunato vreme ekanja, moramo jednostavno da izraunamo Ki Q,
odredimo P = min {Q,K-\} i tako dobijeno P uvrstimo u gornji obrazac.
Zanimljivo je uporediti TCP vreme ekanja sa vremenom ekanja do kojeg bi dolo kada ne bi
postojala kontrola zaguenja (tj. kada ne bi bilo ogranienja koje namee prozor zaguenja). Ako
nema kontrole zaguenja, vreme ekanja je 2 RTT + O/R, koje definiemo kao minimalno vreme
ekanja. Sada se lako moe pokazati daje:
Iz gornjeg obrasca vidimo da TCP-ov spori poetak nee znaajno poveati vreme ekanja ako je
RTT O/R tj. ako je vreme povratnog puta mnogo manje od vremena potrebnog da se prenese
objekat.
Pogledajmo sada neke primere scenarija. U svim primerima uzimamo daje S = 536 bajtova to
je uobiajena podrazumevana vrednost za TCP. Koristiemo RTT od 100 ms to nije neobina
vrednost kanjenja unutar kontinenta ili medu kontinentima preko umereno zaguenih linkova. Prvo
razmotrite slanje relativno velikog objekta veliine O = 100 kilobajta. Broj prozora za ovaj objekat je
K = 8. U sledeoj tabeli ispitujemo efekat koji mehanizam sporog poetka ima na vreme ekanja za
razliite brzine prenosa.
Iz gornje tabele vidimo da za veliki objekat spori poetak dodaje znaajno kanjenje samo kod velike
brzine prenosa. Ako je brzina prenosa mala, potvrde se relativno brzo vraaju i TCP ubrzo dostie
maksimalnu brzinu. Na primer, kada je i? = 100 kb/s broj ekanja je P= 2 dok je broj prozora koje
treba prenetiii> 8; prema tome, server stoji samo nakon prva dva od ukupno 8 prozora. S druge
strane, kada je R = 10 Mb/s server eka nakon svakog prozora, to znaajno produava kanjenje.
Razmotrimo sada slanje jednog malog objekta od O = 5 kilobajta. Broj prozora za ovaj objekat
je K = 4. U sledeoj tabeli ispitujemo efekat mehanizma sporog poetka za razliite brzine prenosa.
I ovde spori poetak dodaje znaajno kanjenje kada je brzina velika. Na primer, kada je R = 1
Mb/s, server stoji nakon svakog prozora, pa je vreme ekanja vee od dvostrukog minimuma.
Za vei RTT, efekat sporog poetka postaje znaajan za male objekte kod malih brzina
prenosa. U sledeoj tabeli ispitujemo efekat mehanizma sporog poetka za RTT = 1 sekund i 0 = 5
kilobajta (K= 4).
Zakljuak bi bio da spori poetak moe znaajno da povea vreme ekanja kada je veliina objekta
relativno mala a RTT relativno veliko. Naalost, to se esto dogaa na Webu.
Jedan primer: HTTP
Da bismo primenili analizu vremena ekanja, izraunajmo sada vreme odgovora za veb stranicu
koja se alje preko nepostojanog HTTP-a. Pretpostavimo da se stranica sastoji od jedne osnovne
HTML stranice i Mreferenciranih slika. Da bi primer ostao jednostavan, pretpostavimo da svaki od
M+ 1 objekata sadri tano O bitova.
Kada se koristi nepostojani HTTP, svaki objekat se prenosi nezavisno, jedan po jedan. Vreme
odgovora za veb stranicu je, prema tome, zbir vremena ekanja pojedinanih objekata. Prema
tome,

154 POGLAVLJE 3 TRANSPORTNI SLOJ DOMAI ZADATAK: PROBLEMI I PITANJA 2851

Obratite panju na to da vreme odgovora za nepostojani HTTP ima oblik:
Vreme odgovora = (M + 1) O/R + 2(M + !) RTT + vreme ekanja zbog sporog poetka
TCP-a za svaki od M + 1 objekata.

Jasno je da ako na veb stranici ima mnogo objekata i ako je RTT veliko, nepostojani HTTP e
imati loe vreme odgovora. U problemima za domai zadatak istraiemo vreme odgovora za
druge transportne eme HTTP-a. italac bi mogao da pogleda i [Heidemann 1997; Cardv/ell
2000] gde se mogu nai odgovarajue analize.
3. 8 Rezime
Ovo poglavlje poeli smo razmatranjem usluga koje protokoli transportnog sloja mogu da
obezbede mrenim aplikacijama. TJ jednom krajnjem sluaju, protokol transportnog sloja moe
biti veoma jednostavan i nuditi aplikacijama samo osnovne usluge, tj.
multipleksiranje/demultipleksiranje za procese koji komuniciraju. Internetov protokol UDP je
primer takvog osnovnog protokola transportnog sloja. U suprotnoj krajnosti, protokol
transportnog sloja moe aplikacijama da obezbedi niz garancija kao to su pouzdana isporuka
podataka, garantovanje vremena ekanja i garantovanje propusnog opsega. I pored toga, usluge
koje transportni protokol moe da ponudi esto su ograniene protokolom mrenog sloja koji se
nalazi ispod njega. Ako protokol mrenog sloja ne moe segmentima transportnog sloja da
garantuje vreme ekanja iii propusni opseg, tada ni protokol transportnog sloja ne moe da
garantuje vreme ekanja ili propusni opseg za poruke koje razmenjuju procesi.
U odeljku 3.4 nauili smo da protokol transportnog sloja moe da obezbedi pouzdan
transfer podataka ak i kada mreni sloj ispod njega nije pouzdan. Videli smo da obezbedivanje
pouzdanog transfera podataka sadri mnoge suptilne elemente, ali da se zadatak moe obaviti
paljivim kombinovanjem potvrda, tajmera, ponovnih slanja i rednih brojeva.
Mada smo u ovom poglavlju obradili pouzdani transfer podataka, trebalo bi imati na umu da
pouzdani transfer podataka moe da obezbedi i protokol sloja veze ili protokol mrenog,
transportnog ili aplikacijskog sloja. Bilo koji od navedena etiri sloja u familiji protokola moe
da implementira potvrde, tajmere, ponovna slanja i redne brojeve i tako obezbedi pouzdani
transfer podataka za sloj iznad sebe, U stvari, tokom godina su naunici i inenjeri raunarstva
nezavisno projektovali i implementirali protokole sloja veze, mrenog, transportnog i
aplikacijskog sloja koji obezbeuju pouzdani transfer podataka (mada su mnogi od tih protokola
neprimetno nestali).
U odeljku 3.5 detaljno smo pregledali TCP, Internetov pouzdani protokol transportnog sloja
sa konekcijom. Nauili smo daje TCP sloen, da obuhvata upravljanje konekcijom, kontrolu toka
i procenu vremena povratnog puta, kao i pouzdani transfer podataka. TCP je u sutini sloeniji
od naeg opisa - namerno nismo opi-
ivali niz TCP ispravki, prepravki i poboljanja koji su implementirani u razliitim verzijama
TCP-a. Sva ta sloenost, meutim, sakrivena je za mrenu aplikaciju. Ako klijent eli da sa
jednog raunara pouzdano poalje podatke serveru na drugom raunaru, on jednostavno otvara
TCP soket prema serveru i ubacuje podatke u taj soket. Aplikacija klijent/server ivi u blaenom
neznanju o sloenosti TCP-a.
U odeljku 3.6 ispitali smo kontrolu zaguenja u optem sluaju, a u odeljku 3.7 smo
pokazali kako TCP implementira kontrolu zaguenja. Nauili smo daje kontrola zaguenja
obavezna za dobrobit mree. Kad ne bi bilo kontrole zaguenja, na mrei bi lako nastao zastoj
saobraaja tako da bi malo ili nimalo podataka moglo da se prenese sa kraja na kraj. U odeljku
3.7 nauili smo da TCP implementira mehanizam kontrole zaguenja s kraja na kraj koji aditivno
poveava brzinu prenosa kada se oceni da je putanja TCP konekcije prohodna, a multiplikativno
smanjuje brzinu prenosa kada doe do gubitaka. Taj mehanizam takoe tei da svakoj TCP
kone-kciji koja prolazi kroz zagueni link dodeli podjednak deo propusnog opsega linka. Takode
smo donekle detaljno prouili uticaj uspostavljanja TCP konekcije i sporog poetka na ukupno
vreme ekanja. Primetili smo da u mnogim vanim scenarijima samo uspostavljanje konekcije i
spori poetak znaajno doprinose kanjenju s kraja na kraj. Ponovo naglaavamo da iako se TCP
kontrola zaguenja godinama razvijala, ona ostaje podruje intenzivnog istraivanja i verovatno
e se i dalje razvijati tokom sledeih godina.
U poglavlju 1 smo rekli da se raunarska mrea moe podeliti na periferija mree" i na
Jezgro mree". Rub mree obuhvata sve to se dogaa u krajnjim sistemima. Poto smo obradili
aplikacijski sloj i transportni sloj, na opis periferije mree je zavren. Vreme je da istraimo
jezgra mree! To putovanje poinje u sledeem poglavlju gde emo istraivati mreni sloj, a
nastavlja se u poglavlju 5 gde emo istraiti sloj veze,
Kontrolna pitanja ODEUCI 3.1-3.3
1. Uzmimo TCP konekciju izmeu raunara A i raunara B. Pretpostavimo da TCP segmenti
koji putuju od raunara A prema raunaru B imaju broj izvornog porta x, a broj odredinog
porta y. Koji su brojevi izvornog i odredinog porta za segmente koji putuju od raunara B
prema raunaru A?
2. Opiite zato bi programer odluio da e aplikacija da se izvrava preko UDP-a, a
ne preko TCP-a.
3. Da li je mogue da aplikacija dobije pouzdani transfer podataka ak i kada se izvrava
preko UDP-a? Ako jeste, na koji nain?

286 286 286 286 POGLAVLJE 3 TRANSPORTNI SLOJ PROBLEMI 155 155 155 155

ODEUAK 3.5
4. Tano ili netano?
a. Raunar A alje raunaru B veliku datoteku preko TCP konekcije.
Pretpostavimo da raunar B nema podataka koje bi slao raunaru A.
Raunar B nee raunaru A slati potvrde jer ne moe da ih lepuje na
podatke.
b. Veliina TCP prijemnog prozora RcvWindow se nikada ne menja tokom
cele konekcije.
c. Pretpostavimo da raunar A alje raunaru B veliku datoteku preko TCP
konekcije. Broj nepotvrenih bajtova koje A alje ne moe prei veliinu
prijemne privremene memorije.
d. Pretpostavimo da raunat A alje veliku datoteku raunam B preko TCP
konekcije. Ako je redni broj jednog segmenta u ovoj konekciji m, tada e
redni broj sledeeg segmenta obavezno biti m + 1.
e. TCP segment ima u svom zaglavlju polje za RcvWindow.
f. Pretpostavimo daje poslednji SampleRTT u jednoj TCP konekciji jednak
1 sekund. Tada e trenutna vrednost Timeoutlnterval za tu konekciju
svakako biti > 1 sekund.
g. Pretpostavimo da raunar A alje preko TCP konekcije raunaru B jedan
segment sa rednim brojem 38 i 4 bajta podataka. U tom segmentu broj
potvrde mora biti 42.
5. Pretpostavimo da raunar A alje raunaru B dva TCP segmenta jedan za
drugim preko TCP konekcije. Prvi segment ima redni broj 90; drugi ima redni
broj 110.
a. Koliko podataka sadri prvi segment?
b. Uzmimo da se prvi segment izgubi, ali da drugi segment stigne do B. Koji
je broj potvrde koju e raunar B poslati raunani A?
6. Razmotrite primer sa Telnetom opisan u odeljku 3.5. Nekoliko sekundi nakon
slova ,,C" korisnik upie slovo ,,R" Koliko e se segmenata slati nakon
upisivanja slova ,,R" i ta se stavlja u polja rednog broja i broja potvrde ovih
segmenata?
ODEUAK 3.7
7. Pretpostavimo da u nekom linku koji predstavlja usko grlo sa brzinom R b/s postoje dve
TCP konekcije. Svaka od njih alje veliku datoteku (u istom smeru, preko linka koji
predstavlja usko grlo). Prenos datoteka poinje u isto vreme. Kakvu brzinu prenosa bi TCP
pokuao da dodeli svakoj od ovih konekcija?
8. Tano ili netano? Razmotrite kontrolu zaguenja u TCP-u. Kada kod poiljaoca istekne
tajmer, prag se postavlja na jednu polovinu njegove prethodne vrednosti.
Problemi
1. Pretpostavimo da klijent A inicira Telnet sesiju sa serverom S. Priblino u isto
vreme klijent B takoe inicira Telnet sesiju sa serverom S. Obezbcdite mogue
brojeve izvornih i odredinih portova za:
a. segmente koji se alju iz A prema S;
b. segmente koji se alju iz B prema S;
c segmente koji se alju iz S prema A;
d. segmente koji se alju iz S prema B.
e. Ako su A i B razliiti raunari, da lije mogue da broj izvornog porta u
segmentima iz A prema S bude isti kao u segmentima iz B prema S?
f. A kako stvar stoji ako su oni na istom raunaru?
2. Analizirajte sliku 3.5. Koje su vrednosti izvornog i odredinog porta u segmentima koji
teku od servera prema klijentskim procesima? Koje su IP adrese u datagramima mrenog
sloja koji prenose segmente transportnog sloja?
3. UDP i TCP za svoje kontrolne zbirove koriste komplement jedinice. Pretpostavimo da
imate sledea tri 8-bitna bajta: 0I01010I, 01110000, 01001100. Koji jc komplement
jedinice za zbir ovih 8-bitnih bajtova? (Obratite panju na to da iako UDP i TCP koriste
16-bitne rei kada izraunavaju kontrolni zbir, za ovaj problem se zahteva da radite sa
sabirnima od 8-bitova.) Prikaite ceo postupak. Zato UDP koristi komplement jedinice za
zbir; tj. zato jednostavno ne koristi sam zbir? Kako primalac otkriva greke u emi
sa komplementom jedinice? Da lije mogue da greka u jednom bitu ostane neprimeena?
A greka u dva bita?
4. Analizirajte motivaciju za izmenu protokola rtd2 .1. Pokaite da primalac,
ako radi sa poiljaocem prikazanim na slici 3.11, moe dovesti poiljaoca
i primaoca u stanje mrtve petlje u kojoj svaki od njih eka na dogaaj koji nikada
nee nastupiti.
5. U protokolu rdt 3 . 0, ACK paketi koji idu od primaoca ka poiljaocu nemaju redne brojeve
(mada imaju ACK polje koje sadri redni broj paketa koji potvruju). Zbog ega u ACK
paketima nisu potrebni redni brojevi?
6. Skicirajte FSM za prijemnu stranu protokola rdt3 . 0.
7. Opiite rad protokola rdt 3.0 kada su paketi podataka i paketi potvrda oteeni. Opis bi
trebalo da bude slian onome to vidite na slici 3.16.
8. Analizirajte kanal u kome moe doi do gubitka paketa, ali je maksimalno kanjenje
poznato. Dopunite protokol rdt2 .1 tajm-autom kod poiljaoca i ponovnim slanjem.
Objasnite svojim recima zbog ega va protokol moe pravilno da komunicira preko ovog
kanala.
t

156 156 156 156 POGLAVLJE 3 TRANSPORTNI SLOJ PROBLEMI 289| 289| 289| 289|

9. Strana poiljaoca u protokolu rdt3. 0 jednostavno zanemaruje (tj. nita
ne preduzima za) sve primljene pakete koji su pogreni, ili ako je u paketu
potvrde pogrena vrednost u polju za broj potvrde. Pretpostavimo da u takvom
sluaju rdt3 . 0 ponavlja slanje trenutnog paketa podataka. Da li bi protokol
i dalje funkcionisao? (Napomena: Ispitajte ta bi se dogodilo u sluaju da postoje samo
greke sadraja; da nema gubitaka paketa, ali da moe doi do prevremenog tajm-auta.
Razmotrite koliko puta bi se slao n-ti paket u graninom sluaju kada n tei
beskonanosti.)
10. Razmotrite protokol naizmeninih bitova (poznat kao stani i ekaj").
Napravite dijagram u kojem e se videti da u sluaju kada mrena konekcija
izmeu poiljaoca i primaoca moe da promeni redosled poruka (tj. da dve
poruke koje se kreu po medijumu izmeu poiljaoca i primaoca mogu da
zamene mesta), tada protokol naizmeninih bitova nee pravilno funkcionisati
(potrudite se da jasno pokaete u emu se sastoji taj nepravilan rad). U
dijagramu bi poiljalac trebalo da bude na levoj, primalac na desnoj strani,
a vremenska osa da ide vertikalno nanie. Prikaite razmenu podataka (D) i potvrda (A).
Obavezno oznaite redni broj pridruen svakom segmentu podataka i potvrde.
11. Analizirajte protokol za pouzdani transfer podataka koji koristi samo negativne
potvrde. Pretpostavite da poiljalac retko alje podatke. Da li bi protokol samo
sa NAK-ovima bio poeljniji od protokola koji koristi ACK? Zato? Sada
pretpostavite da poiljalac ima mnogo podataka za slanje, a da u konekciji sa
kraja na kraj retko dolazi do gubitaka. Da li bi u ovom drugom sluaju poeljniji bio protokol
samo sa NAK-ovima od protokola koji koristi ACK? Zato?
12. Analizirajte primer sa velikom razdaljinom prikazan na slici 3.17. Kolika bi morala biti veliina
prozora da bi iskorienost kanala bila vea od 90%?
13. Projektujte pouzdani protokol za transfer podataka sa cevovodnom obradom koji koristi samo
negativne potvrde. Kojom brzinom bi va protokol reagovao na gubitak paketa kada je brzina
pristizanja podataka do poiljaoca mala? A kada je velika?
14. U optem protokolu sa selektivnim ponavljanjem koji smo razmatrali u odeljku 3.4.4, poiljalac
prenosi poruku im je ona dostupna (ako je unutar prozora) bez ekanja na potvrde.
Pretpostavimo sada da elimo protokol sa selektivnim ponavljanjem koji alje poruke dve po
dve. To jest, poiljalac e poslati par poruka, a sledei par e poslati tek kada sazna da su obe
poruke iz prvog para pravilno primljene.
Pretpostavimo da kanal moe da gubi poruke, ali da ih ne oteuje niti im menja redosled.
Projektujte protokol sa kontrolom greaka za jednosmemi pouzdani transfer poruka. Napravite
opis poiljaoca i primaoca upotrebom konanog automata. Opiite format paketa koji se alju od
poiljaoca ka primaocu i obratno.-Ako koristite pozive procedura osim onih iz odeljka 3.4 (na
primer, udt_send ( ) , start_timer ( ) , rdt_rcv ( ) itd), jasno opiite njihove aktivnosti. Prikaite
jedan primer (vremenski raspored kod poiljaoca i primaoca) gde e se videti na koji nain se
va protokol oporavlja od gubitka paketa.
15. Analizirajte scenario u kojem raunar A eli istovremeno da alje poruke
raunarima B i C. Aje povezan sa B i C kanalom za difuzno emitovanje
- kanal e preneti raunarima B i C paket poslat iz raunara A. Pretpostavite da kanal za difuzno
emitovanje koji povezuje A, B i C moe nezavisno da gubi i oteuje poruke (na primer, da
poruka poslata iz A bude pravilno primljena u B, ali ne i u C). Projektujte protokol za kontrolu
greaka u stilu stani i ekaj" za pouzdani prenos paketa od A do B i C, takav da A nee
prihvatati nove podatke od gornjeg sloja, sve dok ne utvrdi da su i B i C pravilno primili trenutni
paket. Napravite konane automate za A i C. (Napomena: Konani automat za B trebalo bi u
osnovi da bude isti kao za C.) Osim toga, napravite i opis upotrebljenih formata paketa.
16. Uzmimo GBN protokol sa veliinom prozora poiljaoca od 3 i rasponom
rednih brojeva 1024. Pretpostavimo da u trenutku t sledei paket po redu koji
primalac oekuje ima redni broj k. Pretpostavite da medijima ne menja redosled
poruka. Odgovorite na sledea pitanja:
a. Koji su mogui skupovi rednih brojeva u prozoru poiljaoca u trenutku ti
Objasnite odgovor.
b. Koje su sve mogue vrednosti polja ACK u svim moguim porukama koje
se u trenutku / vraaju poiljaocu? Objasnite odgovor.

PROBLEMI 157 157 157 157

17. Pretpostavimo da imamo dva mrena entiteta, A i B. B ima na raspolaganju
poruke podataka koje e se slati prema A u skladu sa sledeim konvencijama:
Kada A primi zahtev od gornjeg sloja da pribavi sledeu poruku sa podacima
(D) od B, A mora da poalje poruku zahteva (R) prema B kroz kanal od A do
B. Tek kada B primi poruku R on moe da poalje poruku podataka (D) prema
A kroz kanal od B do A. A bi trebalo da isporui tano jedan primerak svake
poruke D gornjem sloju. Poruke R mogu da se izgube (ali ne i da se otete)
u kanalu od A do B; jednom poslate poruke D, uvek se pravilno isporuuju. Kanjenje u oba
kanala je nepoznato i promenljivo.
Projektujte protokol (napravite konani automat) koji obuhvata odgovarajue mehanizme za
kanal od A do B gde moe doi do gubitaka i koji implementira predavanje poruka gornjem
sloju u entitetu A, kao to je gore opisano. Upotrebite samo mehanizme koji su apsolutno
neophodni.
18. Razmotrimo GBN protokole sa selektivnim ponavljanjem. Uzmimo daje prostor rednih
brojeva veliine k. Odredite za svaki od ovih protokola najvei dozvoljeni prozor poiljaoca
koji e izbei pojavljivanje problema kakvi se javljaju na slici 3.27.
19. Odgovorite na sledea pitanja sa tano ili netano, i ukratko obrazloite odgovor:
a. Da lije u protokolu za selektivno ponavljanje mogue da poiljalac primi
ACK za paket van njegovog trenutnog prozora.
b. Da li je u GBN protokolu mogue da poiljalac primi ACK za paket van
njegovog trenutnog prozora.
c. Protokol sa naizmeninim bitovima isto je to i protokol sa selektivnim
ponavljanjem gde je veliina prozora poiljaoca i primaoca jednaka 1.
d. Protokol sa naizmeninim bitovima isto je to i GBN protokol gde je
veliina prozora poiljaoca i primaoca jednaka 1.
20. Razmotrite prenoenje ogromne datoteke od L bajtova sa raunara A na raunar
B. Pretpostavite da MSS iznosi 1460 bajtova.
a. Koja je najvea vrednost i takva da se ne utroe svi TCP-ovi redni brojevi?
Imajte na umu da polje iednih brojeva u TCP-u ima etiri bajta.
b. Za L koji ste dobili pod (a), utvrdite koliko traje prenoenje datoteke.
Pretpostavite da se na svaki segment pre slanja dodaje ukupno 66 bajtova
zaglavlja transportnog, mrenog i sloja veze podataka pre nego to se
dobijeni paket poalje preko linka od 10 Mb/s. Zanemarite kontrolu toka
i kontrolu zaguenja kao da raunar A moe bez prekida da izbacuje segmente
jedan za drugim.
21. Razmotrite TCP proceduru za procenu RTT-a. Pretpostavite da je a = 0,1. Neka
SampleRTT
1
bude najnoviji uzorak RTT-a, SampleRTT
2
prvi prethodni
uzorak RTT-a itd.
a. Za daru TCP konekciju, pretpostavite da su primljene etiri potvrde
sa odgovarajuim uzorcima RTT-a: SampleRTT^, SampleRTT ,
SampleRTT2 i SampleRTTr Izrazite procenjeni EstimatedRTT
pomou etiri uzorka RTT-a.
b. Napravite obrazac za opti sluaj sa n uzoraka povratnih puteva.
c. Neka u obrascu (b) n tei beskonanosti. Objasnite zato se taj postupak za
pronalaenje proeka naziva eksponencijalni klizni proek.
22. U odeljku 3.5.3 opisati smo TCP-ovo procenjivanje vremena povratnog puta. ta mislite
zbog ega TCP ne meri SampleRTT za ponovo poslate segmente?
23. Koji je odnos promenljive SendBase u odeljku 3.5.4 i promenljive
LastByteRcvd u odeljku 3.5.5?
24. Koji je odnos promenljive LastByteRcvd u odeljku 3.5.5 i promenljive y u odeljku 3.5.4?
25. U odeljku 3.5.4 videli smo da TCP eka da dobije tri identina ACK-a da bi pokrenuo brzo
ponovno slanje. ta mislite zbog ega su projektanti TCP-a odluili da se brzo prenoenje
ne pokree ve nakon prvog dupliranog ACK-a za segment?
26. Posmatrajte sliku 3.45(b). Ako \\lm prede R/2, moe li \z|az prei R/31 Objasnite. Posmatrajte
sada sliku 3.45(c). Ako X\[az pree R/2, moe li X M a z da pree R/4 pod pretpostavkom da
e se paket u proeku dva puta prosledit? od rutera ka primaocu? Objasnite.
27. Razmotrite sledei dijagram veliine TCP prozora u funkciji vremena.
Pod pretpostavkom da se prikazano ponaanje dogaa u protokolu TCP Reno, odgovorite
na sledea pitanja (trebalo bi za svaki odgovor da dodate kratko obrazloenje):

PROBLEMI 293 293 293 293

a. Oznaite vremenske intervale u kojima TCP vri spori poetak.
b. Oznaite vremenske intervale u kojima TCP izvrava izbegavanje zaguenja.
c. Da li je gubitak segmenta nakon 16. povratnog puta otkriven na osnovu tri
identina ACK-a ili na osnovu tajm-auta?
d. Da lije gubitak segmenta nakon 22. povratnog puta, otkriven na osnovu tri
identina ACK-a ili na osnovu tajm-auta?
e. Koja je poetna vrednost praga Threshold tokom prve povratne putanje?
f. Koja je vrednost praga Threshold tokom 18. povratne putanje?
g. Koja je vrednost praga Threshold tokom 24. povratne putanje?
h. Tokom koje putanje se alje 70. segment?
i. Pod pretpostavkom da se gubitak paketa otkrije nakon 26. putanje na
osnovu tri identina ACK-a, koje e biti vrednosti prozora zaguenja i praga
Threshold?
28. Prouite sliku 3.53 na kojoj je prikazana konvergencija TCP-ovog algoritma aditivnog
poveanja i multiplikativnog smanjenja. Pretpostavite da umesto multiplikativnog
smanjenja TCP umanjuje veliinu prozora za konstantan iznos. Da li bi za tako dobijeno
aditivno poveanje, aditivno smanjenje teilo algoritmu jednakih delova? Obrazloite svoj
odgovor dijagramom slinim onom koji je dat na slici 3.53.
29. U odeljku 3.5,4 opisali smo udvostruavanje intervala za tajm-aut nakon dogaaja tajm-aut.
Ovaj mehanizam predstavlja jednu vrstu kontrole zaguenja. Zastoje TCP-u pored ovog
mehanizma dvostrukog intervala za tajm-aut" potreban i mehanizam kontrole zaguenja
zasnovan na veliini prozora (kao stoje reeno u odeljku 3.7)?
30. Raunar A alje ogromnu datoteku raunaru B preko TCP konekcije. U toj konekciji nikad
ne dolazi do gubitka paketa i tajmeri nikad ne isteknu. Oznaite sa R b/s brzinu prenosa
linka koji povezuje raunar A sa Internetom. Pretpostavite da proces u raunaru A moe da
alje podatke u svoj TCP soket brzinom od S b/s, gde je 5= 10 R. Zatim pretpostavite daje
TCP-ova prijemna privremena memorija dovoljna da primi celu datoteku, a da otpremna
privremena memorija moe da primi samo jedan procenat datoteke. Kako
se moe spreiti da proces u raunaru A stalno predaje podatke u TCP soket brzinom
od S b/s? TCP kontrolom toka? TCP kontrolom zaguenja? Neim drugim? Objasnite.
31. Vratite se na idealizovani model za dinamiku stacionarnih stanja TCP-a. U
vremenskom intervalu kada se brzina konekcije kree od W/(2 RTT) do Wl
RTT, izgubio se samo jedan paket (pri samom kraju tog intervala).
a. Pokaite da je uestalost gubitaka jednaka:
1
L = uestalost gubitaka = i ------------ ,
8 4
b. Upotrebite dobijeni rezultat i pokaite da kada konekcija ima uestalost gubitaka paketa i
tada njena prosena brzina iznosi priblino:
1, 2 2 2 2 2 2 2 2 - -- -MSS MSS MSS MSS
RTT RTT RTT RTT-JI
32. U naem opisu budueg TCP-a u odeljku 3.7 napomenuli smo da bi za postizanje
propusnog opsega od 10 Gb/s TCP tolerisao verovatnou gubitka segmenata
od najvie 2 10"
i0
(to odgovara jednom dogaaju gubitka na svakih 5 000 000 000
segmenata). Pokaite kako se izvode vrednosti 2 10"
!0
i jedan Dd 5 000 000 000 polazei
od vrednosti RTT i MSS datih u odeljku 3.7. Koji bi bili podnoljivi gubici kada bi TCP
morao da podri konekciju od 100 Gb/s?
33. U naem opisu TCP kontrole zaguenja u odeljku 3.7 pretpostavili smo da TCP poiljalac
uvek ima podatke za slanje. Razmotrite sada sluaj da TCP poiljalac alje veliku koliinu
podataka a zatim ostane besposlen (jer nema vie podataka za slanje) u trenutku t y TCP
ostaje besposlen relativno due vreme a zatim hoe ponovo da alje podatke u trenutku t2.
Kakve su prednosti i mane ako TCP, kada pone da alje podatke u trenutku t2 upotrebi
vrednosti CongWin i Treshold iz trenutka :,? Koju alternativu biste preporuili? Zato?
34. Razmotrite slanje objekta veliine O = 100 kilobajta od servera ka klijentu. Neka bude S =
536 bajta i RTT= 100 ms. Pretpostavite da transportni protokol koristi statine prozore
veliine W. (Odeljak 3.7.2.)
a. Za brzinu prenosa od 28 kb/s odredite najmanje mogue vreme ekanja.
Odredite minimalnu veliinu prozora kojom se postie to vreme ekanja.
b. Ponovite (a) za 100 kb/s,
c. Ponovite (a) za 1 Mb/s.
d. Ponovite (a) za 10 Mb/s.
35. Pretpostavite da TCP tokom sporog poetka kod svake primljene potvrde
poveava prozor zaguenja za dva umesto za jedan. Tako bi se prvi prozor
sastojao od jednog segmenta, drugi od tri, trei od devet segmenata itd.
Postupkom prikazanim u odeljku 3.7.2:
a. Izrazite K pomou O i S.
b. Izrazite Q pomou RTT, S i R.
c; Izrazite vreme ekanja pomou P - mm.(K - 1 ,Q), O, R i RTT.
36. Uzmimo sluaj kada je RTT= 1 sekund, a O = 100 kbajta. Napravite dijagram (slian
dijagramima iz odeljka 3.7.2) u kojem se minimalno vreme ekanja (01 R = 2 RTT) poredi
sa vremenom ekanja uz spori poetak za R = 28 kb/s, 100 kb/s, 1 Mb/s i 10 Mb/s.
37. Tano ili netano?
a. Ako se veb stranica sastoji od tano jednog objekta, tada nepostojane i postojane
konekcije imaju tano isto vreme odgovora.

3.1 * LABORATORIJA ETHEREAL: ISTRAITE TCP 295 295 295 295
b. Uzmimo slanje jednog objekta veliine 0 od servera u ita preko TCP-a.
Ako je O > S, gde je S maksimalna veliina segmenta, server e bar jednom
morati da eka.
c. Pretpostavite da se veb stranica sastoji od deset objekata od kojih je svaki
veliine O bitova. Za postojani HTTP, deo vremena odgovora koji otpada
na RTT iznosi 20 RTT.
d. Pretpostavite da se veb stranica sastoji od deset objekata od kojih je svaki
veliine O bitova. Za nepostojani HTTP sa pet paralelnih konekcija, deo
vremena odgovora koji otpada na RTT iznosi 12 RTT.
38. U ovom problemu emo dopuniti neke od detalja u izvoenju obrasca za vreme ekanja iz
odeljka 3.7.2. a. Izvedite formulu
2. Primenite prethodno pitanje na Microsoftove proizvode za protok signala u realnom
vremenu.
3. U odeljku 3.7 napomenuli smo da klijent/server moe neuviavno" da napravi mnogo
istovremenih paralelnih konekcija. ta se moe uiniti da bi Internet bio zaista fer?
4. Prouite u istraivakoj literaturi pojam TCP friendlv". Proitajte takoe intervju sa
Sali Flojd na kraju ovog poglavlja. Napiite na jednoj stranici rezime o pojmu TCP
friendlv.
5. Na kraju odeljka 3.7.3 razmatrali smo injenicu da aplikacija moe da otvori vie TCP
konekcija i tako postigne veu propusnu mo (odnosno bri prenos podataka). ta mislite,
zato vie aplikacija ne pokuava da unapredi svoje performanse korienjem vie
konekcija? ta bi se dogodilo kada bi sve aplikacije pokuale da unaprede svoje
performanse korienjem vie konekcija? Na koje tekoe bi naiao mreni element koji bi
pokuao da utvrdi da li neka aplikacija koristi vie TCP konekcija?
b. Upotrebite jednakost
za izvoenje obrasca
39. U analizi dinamikih prozora u odeljku 3.7.2 pretpostavlja se da izmeu servera i klijenta
postoji jedan link. Ponovite analizu za T linkova izmeu servera i klijenta. Pretpostavite
da na mrei nema zaguenja, tako da paketi nemaju kanjenje zbog redova ekanja.
Postoji, meutim, kanjenje zbog uvanja i prosledivanja. Definicija za RTT ista je kao i
ona koja je dara u odeljku o TCP kontroli zaguenja. (Napomena: Vreme od kad server
poalje prvi segment dok ne dobije potvrdu iznosi TS/R + RTT.)
40. Seate li se diskusije na kraju odeljka 3.7.2 o vremenu odgovora za veb stranicu? Za
sluaj nepostojanih konekcija utvrdite opti izraz za deo vremena odgovora koji potie od
TCP-ovog sporog poetka.
JU Programerski zadatak
Implementiranje jednostavnog protokola za pouzdani transfer
podataka
U ovom laboratorijskom programerskom zadatku pisaete kod za poiljaoca i primaoca
transportnog sloja kojim se implementira jednostavan protokol za pouzdani transfer podataka.
Postoje dve verzije ove vebe, verzija protokola sa naizmeninim bitovima i GBN verzija. Ova
veba e verovatno biti zanimljiva poto e vaa implementacija veoma malo da se razlikuje od
onog to bi se zahtevalo u realnoj situaciji.
Poto verovatno nemate samostalne maine (sa operativnim sistemom koji moete da
menjate), va kod e morati da se izvrava u simuliranom hardver-sko-softverskom okruenju.
Meutim, programski interfejs za vae rutine, tj. kod koji poziva vae entitete odozgo i odozdo
veoma lii na ono to se zaista dogaa u okruenju UNIX. (Zaista, softverski interfejsi, opisani
u ovom programerskom zadatku, mnogo su realniji od poiljalaca i primalaca sa beskonanim
petljama koji se koriste u drugim tekstovima.) Simulira se takoe zaustavljanje i pokretanje taj-
mera, a tajmerski prekidi aktivirae vau rutinu za njegovu obradu.
Teze za diskusiju
Laboratorija Ethereal: Istraite TCP
1. Razmotrite protok memorisanog audio sadraja u realnom vremenu. Da li je logino da
se aplikacija izvrava preko UDP-a ili TCP-a? Koji transportni protokol koristi
RealNetworks? Zato?
U ovoj vebi ete upotrebiti svoj ita Weba da biste pristupili datoteci sa veb servera. Kao i u
prethodnim Ethereal vebama, koristiete Ethereal za hvatanje paketa koji stiu do vaeg
raunara. Za razliku od prethodnih vebi, biete takoe. u stanju

297 297 297 297

296 296 296 296 POGLAVUE 3 TRANSPORTNI SLOJ
INTERVJU
da preuzmete trag paketa koji moe da se ita u laboratoriji Ethereal sa veb servera sa kojeg ste
preuzeli datoteku. U tom serverskom tragu videete pakete koji su nastali od vaeg pristupa veb
serveru. Analiziraete tragove sa klijentske i server-ske strane i tako istraiti oba aspekta TCP-a.
Posebno ete proceniti performanse TCP konekcije izmeu vaeg raunara i veb servera.
Pratiete ponaanje TCP-ovog prozora i izvoditi zakljuke o gubljenju paketa, ponovnim
slanjima, kontroli toka i kontroli zaguenja, kao i o procenjenom trajanju povratnog puta.
Kao i kod svih vebi sa laboratorijom Ethereal, potpuni opis ove vebe dostupan je na veb
lokaciji ove knjige na adresi http://www.awl.com/kurose-ross.
Sali Sali Sali Sali Flojd Flojd Flojd Flojd
Sali Flojd je nauni istraiva u AT&T Centru za Internet istraivanja u ICSI
(ACIRI), institutu posveenom Internetu i pitanjima' umreavanja. Ona je
poznata u raunarskoj delatnosti po svom radu naprojektovanju intemetskih
protokola, pogotovo pouzdanih i vieznonih, no projektovanju kontrole
zoguenja [TCP), vremenskog rasporeivanja paketa (RED) i na analizi
protokola. Sali je diplomirala sociologiju na Ka 1 ifornijskom univerzitefu
Berkli, a magistrirala i doktorirala iz raunarskih nauka na istom univerzitetu.

Kako ste odluili da studirate raunarske nauke?
Nakon diplome iz sociologije trebalo je da odluim od ega u iveti: Na kraju sam dve
godine uila elektroniku na lokalnom koledu, a zatim deset godina radiia u toj oblasti i u
raunarskoj nauci. To obuhvata i osam godina koje sam provela kao sistemski inenjer za
raunare koji upravljaju eleznicom Bay Area Rapid Transit. Kasnije sam odluila da
steknem vie kolskog znanja iz raunarskih nauka i prijavila se na lokalne postdiplomske
studije na Berkliju, na odeljenju za raunarske nauke.
Zato ste se odluili na specijalizaciju iz oblasti umreavanja?
Na postdiplomskim studijama sam se zainteresovala za teorijsku raunarsku nauku. Prvo sam
radila na analizi verovatnoe za algoritme, a kasnije na teoriji uenja raunara. Takoe sam
jedan dan meseno radila u laboratoriji LBL (Lawrence Berkeley Laboraiory), a moja
kancelarija je bila preko puta kancelarije Vana Jakobsona koji je tada radio na TCP algoritmima
za kontrolu zaguenja. Van me je pitao da li bih preko leta radila na analizama algoritama za
neki mreni problem vezan za smhronizaciju periodinih poruka rutiranja. To me je
zainteresovalo, pa sam tog leta to i radila.
Kada sam zavrila doktorsku tezu, Van mi je ponudio posao sa punim radnim vremenom
na umreavanju. Nisam tada planirala da 10 godina ostanem u umreavanju, ali mi istraivanje
mrea predstavlja vee zadovoljstvo od teorije raunarskih nauka. Nalazim vee zadovoljstvo u
svetu primene gde su posledice mog rada opipljivjje.
Koji je bio va prvi posao u raunarskoj industriji? Do ega je fo dovelo?
Moj prvi posao na raunarima bio je u eleznicama BART (Bay Area Rapid Transit), od 1975. do
1982. gde sam radila na raunarima koji upravljaju BART vozovima. Poela sam kao tehniar,
odravala sam i popravljala razliite distribuirane raunarske sisteme vezane za upravljanje
BART sistemom.
Tu je spadao jedan centralni raunarski sistem i distribuirani sistemi mini-raunara za
kontrolu kretanja vozova; sistem DEC raunara za prikazivanje reklama i odredita vozova na
tablama u stanicama; kao ijedan sistem Modcomp raunara za prikupljanje informacija sa
naplatnih rampi. Poslednjih nekoliko godina u BART-u provela sam na zajednikom projektu
BART i laboratorija LBL na projektovanju i zameni zastarelog BART-ovog raunarskog
sistema za kontrolu vozova.

Koji je najizazovniji deo vaeg posla?
Samo istraivanje predstavlja najizazovniji deo. Trenutno, radi se o projektovanju i istraivanju
jednog novog mehanizma za kontrolu zaguenja sa kraja na kraj, na osnovu kontrole zaguenja
zasnovane na jednaini. To je planirano ne kao zamena za TCP, ve za jednoznano emitovanje
saobraaja, kao stoje saobraaj u realnom vremenu sa prilagodljivom brzinom kako bi se izbegle
drastine promene brzine kada se brzina slanja prepolovi zbog toga to je isputen samo jedan
paket. Kontrola zaguenja zasnovana na jednaini takode je zanimljiva kao potencijalna osnova
za kontrolu zaguenja vieznanog emitovanja. Vie informacija se moe nai na veb stranici
http://www.psc.edu/networking/tcp_friendly.html.

Kako vi vidite budunost umreavanja i Interneta?
Jedna mogunost je da uobiajeno zaguenje na koje nailazi saobraaj na Internetu, postane
manje izraeno kada se ukljue mehanizmi sa cenama, a dostupni propusni opseg pone da raste
bre od potraivanja. Mislim da je trend smanjenje zaguenja, mada ne izgleda nemogue ni
srednjorono poveanje zaguenja sa povremenim kolapsima.
Budunost samog Interneta ili Intemetove arhitekture nije mi sasvim jasna. Ima mnogo
inilaca koji bi mogli da utiu na brze promene, pa je teko predvideti kako e se razvijati
Internet ili njegova arhitektura, pa ak i predvideti koliko e laj razvoj moi uspeno da izbegne
mnoge potencijalne zamke na tom putu.

Koji su vas ljudi profesionalno inspirisali?
Riard Karp, moj mentor na postdiplomskim studijama u sutini me je nauio ta je to istra-
ivanje, a Van Jakobson, moj voda grupe" u LBL-u, zasluan je za moj interes za umreavanje i
za vei deo mog shvatanja infrastrukture Interneta. Dejv Klark me je inspirisao jasnom vizijom
arhitekture Interneta i svojom ulogom u razvoju te arhitekture putem istraivanja, pisanja i
uea u IETF-u i drugim javnim forumima. Debora Estrin me je inspirisala svojom
koncentracijom i efikasnou, kao i sposobnou da svesno donese odluku o tome ta radi i
zato.
Jedan od razloga to sam uivala da radim na istraivanju mrea ovih 10 godina jeste to to
ima toliko ljudi na tom polju koji mi se dopadaju, koje cenim i koji me inspiriu. Oni su
inteligentni, vredno rade i veoma su posveeni razvoju Interneta, obavljaju zadivljujui posao, a
mogu da budu i dobro drutvo za pivo i prijateljsko neslaganje (ili slaganje) na kraju dana punog
sastanaka.
Mreni sloj
U prethodnom poglavlju smo videli da transportni sloj obezbeduje razliite vidove
komunikacije od procesa do procesa oslanjajui se na uslugu komunikacije ,od raunara do
raunara koju obezbeduje mreni sloj. Nauili smo takoe da transportni sloj koristi uslugu
mrenog sloja ne znajui na koji nain mreni sloj implementira tu uslugu. Zato se moda pitate
kakva je ta komunikacija od raunara do raunara, kako ona funkcionie?
Predmet ovog poglavlja je upravo nain na koji mreni sloj implementira uslugu
komunikacije od raunara do raunara. Videemo da, za razliku od transportnog sloja, po deo
mrenog sloja postoji u svakom raunaru i ruteru na mrei. Zato protokoli mrenog sloja
spadaju u najizazovnije (stoga i najzanimljivije!) u familiji protokola.
Mreni sloj je ujedno jedan od najsloenijih slojeva u familiji protokola i zato je ovo
obimna materija. Prouavanje poinjemo ispitivanjem mrenog sloja i usluga koje on moe da
prui. Zatim emo ponoviti dva ira pristupa strukturisanju isporuke paketa u mrenom sloju -
model datagrama i model virtualnih kola - koje smo ve pomenuli u poglavlju 1 da bismo
shvatili sutinsku ulogu adresiranja u isporuci paketa od izvora do odredita.
U ovom poglavlju povlaimo znaajnu razliku izmeu dve funkcije mrenog sloja:
prosleivanja i rutiranja. Prosledivanje podrazumeva transfer paketa od ulaznog do izlaznog
linka istog rutera. Rutiranje podrazumeva sve mrene rutere, ijim
298 299

4.1 . UVOD 301!
162 POGLAVLJE 4 MRENI SLOJ

se zajednikim radom pomou protokola rutiranja odreuju putanje (ili rute) kojima paketi
putuju od izvornog do odredinog vora. Ako prilikom obrade ovog poglavlja imate uvek na
umu ovu znaajnu razliku, lake ete shvatiti mnoge teme.
Da bismo produbili poznavanje prosleivanja paketa zaviriemo unutar" rutera - u njegovu
hardversku arhitekturu i organizaciju. Zatim emo pogledati prosledivanje na Internetu
ukljuujui i slavni IP (Internet Protokol). Razmotriemo adresiranje u mrenom sloju i format
datagrama IPv4. Zatim istraujemo prevoenje mrenih adresa (network address translation,
NAT), fragmentaciju datagrama, inter-netski protokol za kontrolne poruke (Internet Control
Message Protocol, ICMP) i IPv6.
Nakon toga panju posveujemo funkciji rutiranja u mrenom sloju. Videemo da se posao
rutiranja sastoji od pronalaenja dobrih putanja (odnosno, ruta) od poiljalaca do primalaca. Prvo
emo prouiti teoriju algoritama rutiranja, a koncentri-emo se na dve preovlaujue klase
algoritama: rutiranje prema stanju linkova i rutiranje vektorima rastojanja. Poto sloenost
algoritama rutiranja znaajno raste sa porastom broja rutera u mrei, obradiemo i hijerarhijsko
rutiranje. Zatim emo videti kako se ova teorija sprovodi u praksi kada preemo na protokole
rutiranja meu autonomnim sistemima (RIP, OSPF i IS-IS) i unutranji protokol rutiranja, BGP-
Poglavlje zakljuujemo opisom difuznog i vieznanog rutiranja.
Sve u svemu, ovo poglavlje ima tri dela. Prvi deo, odeljci 4.1 i 4.2 sadre opise funkcija i
usluga mrenog sloja. Drugi deo, odeljci 4.3 i 4.4 posveeni su proslei-vanju. Na kraju, u
treem delu, u odeljcima od 4.5 do 4.7 opisujemo rutiranje.
4. 1 Uvod
Na slici 4,1 prikazana je jednostavna mrea sa dva raunara, Hl i H2 i nekoliko rutera na putanji
izmeu raunara Hl i H2. Pretpostavimo da Hl alje informacije u H2 i razmotrimo ulogu
mrenog sloja u ovim raunarima i u tranzitnim ruterima. Mreni sloj u raunam Hl uzima
segmente od transportnog sloja raunara Hl, enkapsulira svaki segment u datagram (tj. PDU
mrenog sloja) i zatim alje datagrame na put prema njihovom odreditu; tj. alje datagrame na
najblii ruter R1 . U prijemnom raunam, H2, mreni sloj prima datagrame od najblieg rutera (u
ovom sluaju od rutera R2), Vadi iz datagrama segmente transportnog sloja i isporuuje ih navie
transportnom sloju u raunar H2. Prvenstvena uloga rutera je da prosleduju" datagrame sa
ulaznih linkova na izlazne. Obratite panju na to da su ruteri na slici 4.1 prikazani sa skraenom
familijom protokola tj. bez slojeva iznad mrenog sloja, zato to (osim u svrhu kontrole) ruteri ne
izvravaju protokole aplikacijskog i transportnog sloja kakve smo razmatrali u poglavljima 2 i 3.
4.1.1 Prosledivanje i rutiranje |
Uloga mrenog sloja je naizgled jednostavna - da prenosi pakete od otpremnog do i
prijemnog raunara. U tom poslu mogu se uoiti dve znaajne funkcije mrenog j
sloja: j

163 163 163 163 POGLAVLJE 4 MRENI SLOJ
i -
4.1 UVOD 303 303 303 303
Prosleivanje. Kada paket stigne na ruterov ulazni link, ruter mora da ga pre-mesti na
odgovarajui izlazni link. Na primer, paket koji od raunara Hl stigne u ruter Rl mora da se
prosledi sledeem ruteru na putanji prema H2. U odeljku 4.3 zaviriemo u ruter i ispitati
kako se paket u stvari prosleduje od ruterovog ulaznog linka do izlaznog linka.
Rutiranje. Mreni sloj mora da utvrdi rutu ili putanju kojom paketi idu od poiljaoca do
primaoca. Algoritme koji izraunavaju te putanje nazivamo algoritmima rutiranja. Algoritam
rutiranja bi, na primer, utvrdio putanju kojom paketi teku od raunara Hl do H2.
Prilikom opisivanja mrenog sloja autori esto meaju izraze rutiranje i prosleivanje. Mi
emo ih koristiti mnogo preciznije. Prosleivanje znai lokalnu aktivnost rutera prilikom
prenosa datagrama sa interfejsa ulaznog linka u odgovarajui interfejs izlaznog linka. Rutiranje
znai sveukupni proces odreivanja putanje sa kraja na kraj kroz celu mreu kojom e datagrami
ii, od izvora do odredita. Upo-trebimo analogiju iz automobilizma i vratimo se primeru
putovanja od Pensilva-nije do Floride iz odeljka 1.3.2. Tokom ovog putovanja na voza mora
da prede niz raskrsnica. Prosleivanje moemo posmatrati kao prolazak kroz pojedinanu
raskrsnicu - automobil ulazi u raskrsnicu, dobija uputstvo kako da stigne do sledee raskrsnice
na putu prema konanom odreditu i zatim se upuuje izlaznim drumom prema sledeoj
raskrsnici. Rutiranjem moemo smatrati proces planiranja puta od Pensilvanije do Floride: pre
nego to krene na put, voza je prouio kartu i izabrao jednu od vie moguih putanja, gde se
svaka putanja sastoji od niza segmenata koji se spajaju na raskrsnicama. U prvom delu ovog
poglavlja usredsredujemo se na teme vezane za prosleivanje; nakon toga se posveujemo
rutiranju.
Svaki ruter ima tabelu prosleivanja. Ruter prosleduje paket tako to ispituje vrednost
jednog polja u zaglavlju pristiglog paketa i tu vrednost koristi kao indeks za ruterovu tabelu
prosleivanja. Rezultat dobijen iz tabele prosleivanja ukazuje na interfejs ruterovog linka na
koji treba proslediti paket. Zavisno od protokola mrenog sloja, ova vrednost iz zaglavlja paketa
moe da bude adresa odredita tog paketa ili indikacija konekcije kojoj paket pripada. Na slici
4.2 dalje jedan primer. U tom primeru, u ruter stie paket koji u polju zaglavlja ima vrednost
0111. Ruter koristi tu vrednost kao indeks za tabelu prosleivanja i utvruje da je interfejs izla-
znog linka za ovaj paket interfejs 2. Ruter tada interno prosleduje paket interfejsu 2. U odeljku
4.3 zaviriemo u ruter i prouiti funkciju prosleivanja daleko detaljnije.
Sada se moda pitate kako se konfiguriu tabele prosleivanja u ruterima. Ovo je presudno
pitanje iz kojeg se vidi znaajno meudejstvo rutiranja i prosleivanja. Kao to se vidi na slici
4.2, algoritam rutiranja odreuje vrednosti koje se stavljaju u ruterske tabele prosleivanja.
Algoritam rutiranja moe da bude centralizovan (kada se algoritam izvrava na jednoj centralnoj
lokaciji a informacije za rutiranje se preuzimaju na svim ruterima) ili decentralizovan (kada se na
svakom ruteru izvrava
deo distribuiranog algoritma rutiranja). U oba sluaja, ruter prima poruke protokola rutiranja
koje se koriste za kon figu risanje tabele prosleivanja. Zasebne i razliite svrhe funkcija
prosleivanja i rutiranja mogu se bolje ilustrovati jo jednim hipote-tikim (nerealnim ali
tehniki izvodljivim) primerom mree u kojoj sve tabele prosleivanja direktno konfiguriu
mreni operateri fiziki prisutni kod rutera. U tom sluaju ne bi bio potreban nikakav protokol
rutiranja! Naravno, operateri bi morali da se dogovaraju oko konfigurisanja tabela prosleivanja
kako bi paketi stizali na svoja odredita. Takoe je verovatno da bi takvo konfigurisanje bilo
podlonije grekama nego protokol rutiranja i mnogo bi se sporije prilagoavalo promenama
mrene topologije. Prema tome, moemo da budemo zadovoljni to sve mree imaju i funkciju
prosleivanja i funkciju rutiranja!
Dok se bavimo terminologijom, treba pomenuti jo dva izraza koja se esto meaju a koja
emo mi koristiti paljivije. Izraz komutator paketa nameniemo

164 164 164 164 POGLAVLJE 4 . MRENI SLOJ
4.1 UVOD 305 305 305 305

optem ureaju za kom'utiranje paketa koji prenosvpaket iz interfejsa ulaznog linka u interfejs
izlaznog linka, zavisno od vrednosti u polju zaglavlja paketa. Neki komutatori paketa, koje
zovemo komutatori sloja veze (koji se ispituju u poglavlju 5), zasnivaju odluku na vrednosti u
polju sloja veze. Drugi komutatori paketa, koje nazivamo ruterima, zasnivaju odluku o
prosleivanju na vrednosti u polju mrenog sloja. (Da biste sasvim shvatili ovu vanu razliku,
bilo bi dobro da ponovo proitate odeljak 1.7.2 gde se opisuju datagrami mrenog sloja i okviri
sloja veze kao i njihovi odnosi.) Poto se_u ovom poglavlju bavimo mrenim slojem,
koristiemo izraz ruter umesjo izraza komutator paketa. Izraz ruter emo koristiti ak i kada
budemo govorili o komutatorima paketa u mreama sa'virtuelnim kolima (o kojima e uskoro
biti rei).

Podeavanje konekcije
Upravo smo rekli da mreni sloj ima dve vane funkcije, prosleivanje i rutiranje. Ali uskoro
emo videti da u nekim raunarskim.mreama postoji i trea znaajna funkcija mrenog sloja, a
to'je podeavanje konekcije. Verovatno se seate iz izlaganja o TCP-u da je potrebno
sinhronizovanje u tri koraka pre slanja podataka od poiljaoca ka primaocu. Tako poiljalac i
primalac podeavaju potrebne informacije
0 stanju (na primer, redni broj i poetnu veliinu prozora za kontrolu toka). Analogno tome,
unekim arhitekturama mrenog sloja (kao to su, ATM, Frame Relay, X.25, ali ne i Internet)
obavezno je da se ruteri du izabrane putanje od izvora do odredita meusobno sinhronizuju i
podese stanje, pre nego to paketi podataka mrenog sloja ponu da teku. U mrenom sloju se ovaj
postupak naziva podeavanje konekcije. * Podeavanje konekcije emo istraiti u odeljku 4.2.

4.1.2 Modeli mrene usluge
Pre nego to se detaljnije upustimo u mreni sloj, prvo emo pogledati optu sliku
1 razmotriti kakve sve vrste usluga nudi ovaj sloj. Kada transportni sloj u otpremnom raunaru
preda paket na mreu (tj. prenese ga nanie mrenom sloju u tom raunaru) da li transportni sloj
moe da rauna da e mreni sloj isporuiti paket, na odredite? Kada se alje vie paketa, da li
e oni biti isporueni transportnom sloju prijemnog raunara istim redom kako su poslati? Da li
e razmak izmeu slanja dva paketa biti jednak razmaku izmeu njihovih primanja? Da li e
mrea obezbediti ikakvu povratnu informaciju o zaguenju na mrei? Kakav je apstraktan prikaz
(tj. koja su svojstva) kanala koji povezuje transportne slojeve u otpremnom i prijemnom
raunaru? Odgovori na ova pitanja! na mnoga druga zavise od modela usluge koju prua mreni
sloj. Model mrene usluge definie karakteristike prenosa podataka sa jednog kraja periferije
mree na drugi, tj. izmeu krajnjeg sistema koji alje i onog koji prima.
Razmotrimo sada neke usluge koje bi mreni sloj mogao da prua. Na otpremnoj strani,
kada transportni sloj preda paket mrenom sloju, mreni sloj bi mogao da nudi.sledee usluge:
Garantovana isporuka. Ova usluga garantuje da e paket kad-tad stii na odredite.
Garantovana isporuka sa ogranienim kanjenjem. Ova usluga ne samo to garantuje
isporuku paketa ve i isporuku sa navedenim odreenim kanjenjem od raunara do raunara
(npr. kroz najvie 100 ms).
Osim toga, u vezi sa tokom paketa izmeu datog izvora i odredita mogle bi se nuditi i sledee
usluge:
Isporuka u ispravnom redosledu. Ova usluga garantuje da e paketi stizati na odredite onim
redom kako se i alju.
Garantovanipropusni opseg. Ova usluga mrenog sloja emulira ponaanje pre-nosnog linka
odreene brzine (npr. 1 Mb/s) od otpremnog do prijemnog raunara (iako stvarna putanja sa
kraja na kraj moe da obuhvata vie fizikih linkova). Sve dok otpremni raunar predaje
bitove (kao delove paketa) brzinom manjom od specifikovane, paketi se nee gubiti i svaki
paket stie od raunara do raunara u unapred odreenom intervalu (npr. 40 ms).
Garantovana maksimalna promenljivost kanjenja. Ova usluga garantuje da e vreme
izmeu predaje dva uzastopna paketa kod poiljaoca biti jednako vremenu izmeu njihovog
uzastopnog pristizanja kod primaoca (ili da taj razmak nee varirati vie od neke navedene
vrednosti).
Ovo je samo delimian spisak usluga koje bi mreni sloj mogao da nudi - tu su mogue
bezbrojne varijacije.
Dananja arhitektura Interneta prua samo jedan model usluge, takozvanu uslugu najboljeg
pokuaja. Iz tabele 4.1 mogao bi se stei utisak daje usluga najboljeg pokuaja eufemizam za bez
ikakve usluge. U usluzi najboljeg pokuaja ne garantuje se ouvanje vremenskog razmaka meu
paketima, ne garantuje se da e paketi stii redosledom kojim su poslati, niti se uopte garantuje
isporuka posla-tih paketa. Ako posmatramo samu definiciju, mrea koja ne bi isporuivala
nijedan paket na odredite zadovoljila bi definiciju usluge najboljeg pokuaja. (Zaista, dananji
zagueni javni Internet ponekad izgleda kao primer ba takve mree!) Meutim, kao to emo
uskoro objasniti, za tako minimalistiki model usluge na mrei postoje valjani razlozi. Internetov
model usluge najboljeg pokuaja trenutno se proiruje, pa e ukljuiti i takozvane integrisane
usluge i diferencirane usluge. Te modele usluga koji se jo razvijaju obradiemo kasnije u
poglavlju 7.
Druge mrene arhitekture definisale su i implementirale modele usluga koji prevazilaze
internetsku uslugu najboljeg pokuaja. Na primer, mrena arhitektura ATM [ATM Forum 2004,
Black 1995] predvia vie modela usluga, tj. da razliite konekcije dobijaju na istoj mrei
razliite klase usluga. Objanjenje naina na koji ATM mrea obezbeduje takve usluge
prevazilazi okvire ove knjige; ovde nam je cilj samo da napomenemo da za internetsku uslugu
najboljeg pokuaja postoje altema-

i -

306 306 306 306 POGLAVLJE 4 MRENI SLOJ 4.2 . MREE SA VIRTUALNIM KOLIMA I SA DATAGRAMIMA 307 307 307 307
tive. Dva najvanija modela ATM usluge su usluga konstantne bitske brzine i usluga dostupne
bitske brzine:
ATM mrena usluga konstantne bitske brzine (constant bit rate, CBR). Ovo je bio prvi
standardizovan model ATM usluge u kojem se ogleda tadanja zain-teresovanost telefonskih
kompanija za ATM i pogodnost CBR usluge za prenos audio i video saobraaja u realnom
vremenu konstantnom bitskom brzinom. Cilj CBR usluge je po zamisli jednostavan - postii
da mrena konekcija izgleda kao iznajmljena linija sa paricama ili optikim vlaknima izmeu
poiljaoca i primaoca. Sa CBR uslugom, ATM paketi (koji se u ATM argonu nazivaju
elijama) prenose se preko mree tako da se garantuju maksimalne vrednosti kanjenja elija
sa kraja na kraj, promenljivosti kanjenja elije sa kraja na kraj (koje se esto naziva
treperenjem") i procenat elija koje se izgube ili se prekasno isporue. Otpremni raunar i
ATM mrea dogovaraju se o tim vrednostima prilikom uspostavljanja CBR konekcije.
4 ATM mrena usluga dostupne bitske brzine (available bit rate, ABR). Kako Internet nudi
takozvanu uslugu najboljeg pokuaja, najbolji opis za ABR bio bi usluga neznatno bolja
odmajboljeg pokuaja". Kao i u internetskom modelu usluge, u ABR usluzi elije mogu da se
izgube. Meutim, za razliku od Interneta, elijama ne moe da se promeni redosled (mada
mogu da se izgube), a konekciji koja koristi ABR uslugu garantuje se minimalna brzina
prenosa elije (minimum cell transmission rate, MCR). Ako u odreenom trenutku mrea ima
dovoljno slobodnih resursa, poiljalac e moi uspeno da alje saobraaj brzinom veom od
MCR-a. Osim toga, kao to smo videli u odeljku 3.6, ATM usluga ABR moe poiljaocu da
obezbedi povratne informacije (u vidu bita upozorenja o zaguenju ili obavetenja o manjoj
brzini kojom treba slati) koje reguliu nain na koji poiljalac podeava brzinu izmeu
MCR-a i dozvoljene maksimalne brzine elija.
4.2 Mree sa virtualnim kolima i sa datagramima
Sigurno se iz treeg poglavlja seate da transportni sloj moe aplikacijama da ponudi uslugu bez
konekcije ili uslugu sa konekcijom. Na primer, transportni sloj svakoj aplikaciji nudi izbor
izmeu dve usluge: UDP, usluge bez konekcije i TCP, usluge sa konekcijom. Slino tome,
mreni sloj moe da ponudi uslugu bez konekcije i uslugu sa konekcijom. Usluge sa konekcijom
i bez nje u mrenom sloju imaju mnoge slinosti sa uslugama sa konekcijom i bez nje u
transportnom sloju. Na primer, usluga mrenog sloja sa konekcijom poinje od sinhronizovanja
izmeu izvornog i odredinog raunara, a usluga mrenog sloja bez konekcije nema nikakvog
poetnog usaglaavanja.
Iako usluge sa konekcijom i bez nje u mrenom sloju imaju neke slinosti sa uslugama sa
konekcijom i bez nje u transportnom sloju, postoje i bitne razlike:
U mrenom sloju, to su usluge'koje mreni sloj prua transportnom sloju od raunara do
raunara. U transportnom sloju, re je o uslugama koje transportni sloj prua aplikacijskom
sloju od procesa do procesa.
U svim glavnim arhitekturama raunarskih mrea do danas (Internet, ATM, Frame Relay
itd.), mreni sloj prua uslugu sa konekcijom od raunara do raunara ili uslugu bez
konekcije od raunara do raunara, ali ne i obe. Raunarske mree koje u mrenom sloju
daju samo uslugu sa konekcijom nazivamo mree sa virtuelnim kolima (VC); raunarske
mree koje u mrenom sloju daju samo uslugu bez konekcije nazivamo mree sa
datagramima.
Implementacije usluge sa konekcijom u transportnom sloju i usluge sa konekcijom u
mrenom sloju se bitno razlikuju. U prethodnom poglavlju smo videli da se usluga sa
konekcijom u transportnom sloju implementira na periferiji mree u krajnjim sistemima;
uskoro emo videti da se usluga sa konekcijom u mrenom sloju implementira u jezgru
mree kao i u krajnjim sistemima.
Mree sa virtuelnim kolima i sa datagramima su dve osnovne klase raunarskih mrea. One
zasnivaju svoje odluke o prosleivanju na veoma razliitim informacijama. Pogledajmo sada
njihove implementacije.

4 . 2 . 1 Mree sa virtuelnim kolima
Nauili smo da je Internet mrea sa datagramima. Meutim, mnoge alternativne mree (ATM,
Frame Relay i X.25) su mree sa virtuelnim kolima i, prema tome, koriste konekcije u mrenom
sloju. Ove konekcije u mrenom sloju nazivaju se virtuelnim kolima (virtual circuit, VC).
Razmotrimo sada kako se u raunarskoj mrei moe implementirati usluga VC.

308 308 308 308 POGLAVLJE 4 . MRENI-SLOJ
4.2 . MREE SA VIRTUALNIM KOLIMA I SA DATAGRAMIMA 309; 309; 309; 309;

Virtuelno kolo (VC) sastoji se od ( 1 ) putanje (tj. niza linkova i rutera) izmeu izvornog i
odredinog raunara, (2) VC brojeva, po jedan broj za svaki link na putanj i i (3) stavki u. tabeli
prosledivanja svakog rutera na putanji. Paket koji pripada jednom virtuelnom kolu imae u
zaglavlju VC broj. Poto virtuelno kolo moe u svakom linku da ima drugaiji VC broj, svaki
ruter na putu mora u paketima koji kroz njega prolaze da zameni stari VC broj novim. Novi VC
broj dobija se iz tabele prosledivanja.
Za ilustrovanje ovog koncepta uzeemo mreu prikazanu na slici 4.3. Brojevi pored linkova
rutera Rl na slici 4.3 su brojevi interfejsa linkova. Pretpostavimo sada da raunar A zatrai da
mrea uspostavi VC izmeu njega i raunara B. Pretpostavimo takode da mrea izabere putanju
A-RI-R2-B i dodeli brojeve 12, 22 i 32 linkovima u putanji ovog virtuelnog kola. U ovom
sluaju, kada paket ovog virtuelnog kola naputa raunar A, u njegovom zaglavlju se u polju VC
broja nalazi vrednost 12; kada naputa ruter Rl, vrednost je 22; a kada naputa R2, vrednost je
32.
Kako ruter utvruje kojim'brojem treba zameniti VC broj u paketu koji prolazi kroz ruter?
U VC mrei tabela prosledivanja svakog rutera sadri prevoenje VC brojeva: na primer, tabela
prosledivanja u Rl .mogla bi da izgleda ovako:
'Kad god se kroz ruter uspostavi novo virtuelno kolo, dodaje se nova stavka u tabelu
prosledivanja. Slino tome, kad god se neko virtuelno kolo zavri, uklanjaju se odgovarajue
stavke iz svih tabela du putanje.
Moda se pitate zato paket prosto ne zadri isti VC broj na svim linkovima du putanje.
Postoje dva razloga. Prvo, zamenom broja za svaki link smanjuje se potre-
ban broj cifara u polju VC broja u zaglavlju paketa. Drugo, jo vanije, podeavanje VC brojeva
je znaajno jednostavnije kada se dozvole razliiti VC brojevi na linko-vima du putanje
virtuelnog kola. Konkretno, kada se koristi vie VC brojeva svaki link na putanji moe da bira
VC broj bez obzira na VC brojeve koje su izabrali drugi linkovi te putanje. Kada bi se zahtevao
VC broj zajedniki za sve linkove putanje, ruteri bi morali da razmene i obrade osetnu koliinu
poruka da bi se usaglasili oko zajednikog VC broja za novu konekciju (tj. broja koji u tim
ruterima trenutno ne koristi nijedno drugo virtualno kolo).
U VC mrei, mreni ruteri moraju da odravaju informacije o stanju konekcije za aktivne
konekcije. Konkretno, kad god se uspostavi nova konekcija, u tabelu pro-sledivanja svakog
rutera mora da se doda nova stavka konekcije; a svaki put kada se neka konekcija prekine, iz
tabela treba izbaciti njenu stavku. Obratite panju na to da i kada nema prevoenja VC brojeva,
ipak treba odravati informacije o stanju konekcije u kojima se VC broju pridruuje broj
izlaznog interfejsa. Pitanje da li ruteri odravaju informacije o stanju konekcija ili ne je od
presudnog znaaja, i mi emo mu se vraati vie puta u ovoj knjizi.
U virtuelnom kolu prepoznaju se tri faze:
Podeavanje virtuelnog kola. U fazi podeavanja, transportni sloj poiljaoca kontaktira
mreni sloj, navodi adresu primaoca i eka da mrea uspostavi virtuelno kolo. Mreni sloj
utvruje putanju izmeu poiljaoca i primaoca, tj. niz linkova i rutera kroz koji e prolaziti
svi paketi virtuelnog kola. Na kraju, mreni sloj dodaje po jednu stavku u tabelu
prosleivanja svakog rutera na putanji. Tokom podeavanja virtuelnog kola mreni sloj moe
takoe da rezervie resurse (na primer, propusni opseg) za virtuelno kolo na putanji.
Transfer podataka. Kao to se vidi na slici 4.4, poto se virtuelno kolo uspostavi, kroz njega
mogu da teku podaci.
Raskidanje virtuelnog kola. Ovo poinje kada poiljalac (ili primalac) obavesti mreni sloj'O
svojoj elji da prekine virtuelno kolo. Mreni sloj tada obino oba-vetava krajnji sistem na
drugoj strani mree o prekidanju poziva i aurira tabele prosleivanja u svim ruterima paketa
na putanji da bi se znalo da virtuelno kolo vie ne postoji.
Postoji jedna suptilna, ali vana razlika izmeu uspostavljanja virtuelnog kola u mrenom
sloju i uspostavljanja konekcije u transportnom (na primer, TCP-ovo sinhronizovanje u tri
koraka koje smo opisali u poglavlju 3). Uspostavljanje konekcije u transportnom sloju tie se
samo dva krajnja sistema. Dva krajnja sistema pristaju da komuniciraju i zajedniki utvruju
parametre (na primer, poetni redni broj i veliinu prozora za kontrolu toka) njihove konekcije u
transportnom sloju pre nego to podaci ponu da teku po njoj. Krajnji sistemi su svesni konekcije
transportnog sloja, ali je ruteri u mrei uopte ne primeuju, S druge strane, u mrenom sloju sa
virtuelnim kolom, ruteri na putanji izmeu dva krajnja sistema ukljueni su u uspostavljanje
virtuelnog kola i svaki ruter je sasvim svestan svih virtuetnih kola koja prolaze kroz njega.

J310 J310 J310 J310 POGLAVLJE 4 . MRENI SLOJ
4.2 MREE SA VIRTUALNIM KOLIMA I SA DATAGRAMIMA 311 311 311 311
Poruke koje krajnji sistemi alju na mreu da bi ukazali na iniciranje ili raskidanje virtuelnog kola
i poruke koje razmenjuju ruteri radi uspostavljanja virtuelnog kola (tj. za menjanje ruterskih tabela sa
stanjima konekcija) poznate su kao poruke signalizacije a protokoli koji se koriste za razmenu tih
poruka esto se nazivaju protokolima signalizacije. Uspostavljanje virtuelnog kola prikazano je na
slici 4.4. U ovoj knjizi ne obraujemo protokole signalizacije; opti opis signalizacije u mreama sa
konekcijama nai ete u knjizi [Black 1997] a specifikaciju ATM-ovog protokola signalizacije Q.2931
u knjizi [ITU-T Q.2931 1994].

4.2.2 Mree sa datagramima
U mreama sa datagramima, kad god krajnji sistem hoe da poalje paket, on stavi u njega adresu
krajnjeg odredinog sistema i zatim ubaci paket u mreu. Kao to se vidi na slici 4.5, to se postie
bez ikakvog uspostavljanja virtuelnog kola. Ruteri u mrei sa datagramima ne odravaju nikakve
informacije o stanju virtuelnili kola (poto i nema virtuelnih kola!).
Tokom prenosa od izvora do odredita, paket prolazi kroz niz rutera. Svaki od ovih rutera
koristi adresu odredita u paketu za njegovo prosleivanje. Konkretno, svaki ruter ima tabelu
prosleivanja u kojoj se adrese odredita preslikavaju u inter-fejse linkova; kada paket stigne u ruter,
ruter koristi adresu odredita paketa da bi u tabeli prosleivanja pronaao odgovarajui interfejs
izlaznog linka. Ruter zatim prosleduje paket na taj interfejs izlaznog linka.
Da biste bolje shvatili postupak pretraivanja tabele, pogledaemo jedan konkretan primer.
Pretpostavite da sve adrese odredita imaju 32 bita (to je sluajno upravo duina odredine adrese
u IP datagramu). U gruboj implementaciji, tabela prosleivanja bi imala po jednu stavku za svaku
moguu adresu odredita. Poto
postoji vie od 4 milijarde moguih adresa, ta opcija nikako ne dolazi u obzir -tabela prosleivanja bi
bila stravina.
Pretpostavimo zatim da na ruter ima etiri linka, mimerisana od 0 do 3 i da pakete treba
proslediti na interfejse linkova na sledei nain:
Raspon odredinih adresa Interfejs linka
11001000 000101I I 00010000 00000000
do o
i i ooi ooooooi oi n oooi oi n mi i ni
11001000 00010111 00011000 00000000
do i
11001000 00010111 00011000 11111111
i i ooi ooooooi oi n oooiiooi oooooooo
do 2
i i ooi ooooooi oi n 00011111 mi nu

inae 3
Sasvim je jasno da u ovom sluaju nije potrebno imati 4 milijarde adresa prosleivanja u ruterovoj
tabeli prosleivanja. Mogli bismo, na primer, da imamo tabelu prosleivanja sa samo etiri stavke:

i -

312 312 312 312 POGLAVLJE 4 MRENI 5LOJ 4.2 . MREE 5A VIRTUALNIM KOLIMA I SA DATAGRAMIMA
313 313 313 313
Prefiks Interfejs linka
i i ooi ooooooi oi n 00010 o
i i ooi ooooooi oi n 00011000 i
i i ooi ooooooi oi n ooon 2
inae 3
Sa ovakvom vrstom tabele prosleivanja, ruter meu stavkama u tabeli trai prefiks odredine
adrese paketa; ako postoji jednakost, ruter prosleduje paket na link pridruen toj vrednosti. Na
primer, pretpostavimo da je odredina adresa paketa 11001000 00010111 00010110 10100001;
poto je prefiks od 21 bita ove adrese jednak prvoj stavci u tabeli, ruter prosleduje paket na
interfejs linka 0. Ako prefiks nije jednak ni jednoj od prve tri stavke, ruter e prosiediti paket na
interfejs 3. Mada ovo izgleda prilino jednostavno, tu postoji jedna znaajna suptilnost. Moda
ste primetili daje mogue da odredinoj adresi odgovara vie stavki. Na primer, prvih 24 bita
adrese 11001000 00010111 00011000 10101010 jednako je drugoj stavci tabele, a prvih 21
bitova je jednako treoj stavci. U sluaju vie jednakosti ruter primenjuje pravilo jednakosti
najdueg prefiksa; tj. pronalazi najduu jednaku stavku tabele i prosleduje paket na interfejs linka
pridruen najduem odgovarajuem prefiksu.
Naravno, da bi pravilo jednakosti najdueg prefiksa moglo da se koristi, svaki interfejs
izlaznog linka treba da bude zaduen za prosleivanje velikog bloka susednih odredinih adresa.
U odeljku 4.4 videemo da se internetske adrese obino dodetjuju hijerarhijskim principom tako
da u tabelama prosleivanja veine rutera preovlauje to svojstvo susednosti. I pored toga, u
zajednici istraivaa Interneta postoji briga da se u adresnom prostoru pojavljuje sve vie i'vie
prekida tako da neprekidni blokovi susednih adresa postaju sve manji i manji a tabele
prosleivanja sve vee. (Proitajte [Maennel 2002], [RFC 3221] i opis Principi u praksi iz
odeljka 4.4.)
Mada ruteri u mreama sa datagramima ne odravaju nikakve informacije o stanju
konekcija, oni ipak u svojim tabelama odravaju informacije o stanju prosleivanja. Meutim,
ove informacije o stanju prosleivanja menjaju se relativno sporo. Zaista, algoritmi rutiranja
auriraju tabele prosleivanja u mrei sa datagramima, u intervalima od priblino jednog do pet
minuta. U VC mrei, tabela prosleivanja u ruteru se menja kad god se uspostavi nova konekcija
kroz taj ruter i kad god se raskine neka postojea konekcija kroz njega. To se u ruteru okosnice
nivoa 1 lako moe dogaati u intervalima koji se mere mikrosekundama.
Poto se tabele prosleivanja mogu menjati u bilo kad, niz paketa koji se alju od jednog
krajnjeg sistema u drugi mogu da prou razliitim putanjama kroz mreu i mogu da stignu izvan
redosleda. [Paxson 1997] i [Jaiswal 2003] predstavljaju jednu zanimljivu studiju merenja izmena
u redosledima paketa i drugih fenomena u javnom Internetu.
4.1.3 Poreklo usluga datagrama i virtualnog kola
Razvoj modela usluga datagrama i virtuelnog kola ukazuje na njihovo poreklo. Pojam virtuelnog
kola kao glavnog organizacionog principa potie iz sveta telefo-nije u kojoj se koriste realna"
kola. Kako se u mrei sa virtuelnim kolima uspostavljaju pozivi i stanje svakog poziva odrava u
ruterima unutar mree, ona je znatno sloenija od mree sa datagramima (mada u knjizi
[Molinero 2002] moete nai zanimljivo poreenje sloenosti mrea sa komutacijom vodova i
mrea sa komutacijom paketa). I to je naslee iz telefonije. U telefonskim mreama, sama mrea
je morala da bude sloena poto je kao krajnje sisteme povezivale glupe ureaje, kao to su
telefoni sa rotacionim brojanikom (za mlade itaoce koji moda ne znaju, to je analogni telefon
koji nema dugmadi - ima samo kruni brojanik).
S druge strane, Internetov model usluge sa datagramom. potekao je iz potrebe da se povezu
raunari. Poto su kao krajnje sisteme imali sloenije ureaje, arhitekti Interneta su odluili da u
mrenom sloju model usluge bude to jednostavniji. Kao to smo ve videli u poglavljima 2 i 3,
dodatna funkcionalnost (na primer, isporuka u redosledu, pouzdani transfer podataka, kontrola
zaguenja i DNS razreava-. nje imena) se zatim implementira u viem sloju, u krajnjim
sistemima. Ovaj model suprotnost telefonskoj mrei, pa imamo i neke zanimljive konsekvence:
Model mrene usluge na Internetu koji daje minimalne (nikakve!) garancije usluga (i zato
mrenom sloju postavlja minimalne zahteve), takoe olakava meusobno povezivanje mrea
koje koriste veoma razliite tehnologije u sloju veze (na primer, satelitske mree, Ethernet,
optika vlakna ili radio veze) i koje imaju veoma razliite brzine prenosa i karakteristike
gubitaka. Meusobno povezivanje IP mrea detaljno emo obraditi u odeljku 4.4.
Kao to smo videli u poglavlju 2, aplikacije kao to su e-pota, VVeb, pa ak i usluga
aplikacijskog sloja koju koristi mreni sloj kao to je DNS, implementiraju se u raunarima
(serverima) na periferiji mree. Mogunost da se nova usluga doda prostim prikljuivanjem
raunara na mreu i definisanjem novog protokola aplikacijskog sloja (kao stoje HTTP)
omoguila je da se veoma brzo prihvate nove usluge na Internetu, na primer VVeb.
Meutim, kao to emo videti u poglavlju 7, u internetskoj zajednici se vode une rasprave
o pravcu razvoja arhitekture Internetovog mrenog sloja koja e moi da podri usluge u
realnom vremenu kao to je multimedija. U [Crowcroft 1995] datoje zanimljivo poreenje ATM
mrene arhitekture sa virtuelnim kolima i predlae se arhitektura za sledeu generaciju Interneta.

314 314 314 314 POGLAVLJE 4 MRENI SLOJ 4.3 . TA IMA U RUTERU? 169 169 169 169

4. 3 ta ima u ruteru?
Poto smo videli opti pregled funkcija i usluga mrenog sloja obratimo panju na funkciju
prosledivanja mrenog sloja - samo prenoenje paketa iz ulaznog linka rutera na odgovarajui
izlazni link. U odeljku 4.2 ve smo ukratko pomenuli nekoliko pitanja u vezi sa prosledivanjem,
tj. adresiranje i jednakost najdueg prefiksa. U ovom odeljku razmotriemo konkretne
arhitekture rutera za prenoenje paketa iz ulaznih linkova na izlazne linkove. Prikaz smo morali
da skratimo poto je temeljna obrada dizajniranja rutera oblast za sebe. Zato emo se ovde
posebno potruditi da ukaemo na literaturu koja detaljnije pokriva ovu temu. Usput, ovde
napominjemo da istraivai i praktiari umreavanja raunara esto naizmenino koriste izraze
prosledivanje i komutiranje. U ovoj knjizi koristiemo oba izraza.
Na slici 4.6. dat je opti pregled ruterske arhitekture. Mogu se uoiti etiri komponente
rutera.
Ulazni port. Ulazni port izvrava nekoliko funkcija. On izvrava funkcije fizikog sloja
(sasvim levi okvir ulaznog porta i sasvim desni okvir izlaznog porta na slici 4.6) zavravajui
fiziki link koji ulazi u ruter. Dalje, on vri funkcije sloja veze podataka (prikazane srednjim
okvirom ulaznog i izlaznog porta), potrebne za saradnju sa funkcijama sloja veze podataka
na drugoj strani ulaznog linka. On takode izvrava funkciju pretraivanja tabele i
prosledivanja (sasvim desni okvir ulaznog porta i sasvim levi okvir izlaznog porta) tako da
paket prosleden kroz komutatorsku mreu rutera izae na odgovarajuem izlaznom portu.
Kontrolni paketi (na primer, paketi koji prenose informacije protokola rutiranja) prosleduju
se od ulaznog porta prema procesoru rutiranja. U praksi se esto vie portova grupie na
jednu linijsku karticu u ruteru.
Komutatorska mrea. Komutatorska mrea povezuje ulazne portove rutera sa njegovim
izlaznim portovima. Ta komutatorska mrea se cela nalazi u ruteru - mrea u mrenom
ruteru!
Izlazni portovi. Izlazni port uva pakete koji su mu prosleeni kroz komutatorsku mreu, a
zatim ih predaje na izlazni link. Izlazni port, znai, izvrava funkcije sloja veze podataka i
fizikog sloja inverzne u odnosu na ulazni port. Ako je link dvosmeran (tj. prenosi saobraaj
u oba smera) izlazni port tog linka obino e se nalaziti na istoj linijskoj kartici na kojoj je i
ulazni port za taj link.
Procesor rutiranja. Procesor rutiranja izvrava protokole rutiranja (na primer, protokole
koje emo razmotriti u odeljku 4.6), odrava informacije o rutiranju i tabele proslevanja i
obavlja funkcije upravljanja mreom u ruteru (proitati poglavlje 9).

U sleeirri odeljcima detaljnije emo razmotriti ulazne portove, komutatorsku mreu i
izlazne portove. Dokumenti [Chao 2002; Turner 1988; Giacopelli 1990; McKeown 1997a;
Partridge 1998] sadre opis nekih specifinih arhitektura rutiranja. Dokument [McKeown
1997b] sadri lepo napisan pregled modernih arhitektura rutera u kojem se kao primer koristi
ruter Cisco 12000. Da bi opis koji sledi bio kon-kretniji, uzeemo daje re o paketskoj mrei i
da se odluke o prosledivanju zasnivaju na odredinoj adresi paketa (a ne na VC broju u mrei sa
virtuelnim kolima). Meutim, koncepti i tehnike su sline i u mrei sa virtuelnim kolima.

4.3.1 Ulazni portovi
Na slici 4.7 dat je detaljniji prikaz funkcija ulaznog porta. Kao stoje ve reeno, fiziki sloj i sloj
veze podataka implementirani su u ruteru elektrinim zavretkom linije i obradom okvira
ulaznog linka. Funkcija pretraivanja tabele i prosledivanja u ulaznom portu kljuna je za
funkciju prosledivanja u ruteru. U mnogim ruterima, ovde se utvruje izlazni port na koji e se
pristigli paket proslediti kroz komutatorsku mreu. Izbor izlaznog porta vri se pomou
informacija iz tabele prosledivanja. Mada tabelu prosledivanja izraunava procesor rutiranja,
njene kopije se obino uvaju u svakom ulaznom portu i procesor rutiranja ih, po potrebi,
aurira. Poto se lokalne kopije tabele prosledivanja nalaze u svakom ulaznom portu, oni mogu
da donose odluke o prosledivanju bez pomoi centralizovanog procesora rutiranja. Takvim
decentralizovanim prosledivanjem izbegava se da nastane usko grlo na jednom mestu u ruteru.

4.3 TA IMA U RUTERU? 170 170 170 170

Ako je ruter sa ogranienim mogunostima obrade u ulaznom portu, on e jednostavno
prosjediti paket centralnom procesoru rutiranja koji e zatim pretraiti tabelu prosleivanja i
proslediti paket odgovarajuem izlaznom portu. Taj pristup se koristi kada radna stanica ili server
slui kao ruter; tu je procesor rutiranja u stvari CPU radne stanice, a ulazni port je prosto kartica
mrenog interfejsa (na primer, Ethernet kartica).
CISCO SISTEMI: DOMINACIJA JEZGROM MRE CISCO SISTEMI: DOMINACIJA JEZGROM MRE CISCO SISTEMI: DOMINACIJA JEZGROM MRE CISCO SISTEMI: DOMINACIJA JEZGROM MREE EE E
Dok ovo piemo (mart 2004) Cisco zapoljava vie od 30.000 ljudi i ima dohodak od 150
milijardi dolara. Cisco trenutno dominira tritem rutera za Internet, a tokom poslednjih godina
preao je na trite Internet lelefonije gde se takmii sa kompanijama za telefonsku opremu kao
to su Lucent, Alcatel, Nortel i Siemens. Kako je nastala ova ogromna kompanija koja se bavi
umreavanjem? Sve je poelo 1984. godine [pre samo 20 godina] u dnevnoj sobi jednog stana
U Silikonskoj dolini. Len Bosak i njegova ena Sandi Lerner radili su na univerzitetu Stanford
kada im je palo na pamet da prave internetske rutere i prodaju ih istraivakim i akademskim
ustanovama. Sandi Lerner je predloila ime Cisco" (skraenica za San Francisco), i takode
je projektovala zatitni znak kompanije u vidu mosta. Uprava korporacije je prvo bila u njihovoj
dnevnoj sobi, a projekat su na poetku finansirali kreditnim karticama i honorarnim
konsultantskim poslovima. Krajem 1986. godine Ciscovi prihodi dostigli su 250.000 dolara
meseno - to nije loe za preduzee finansirano kreditnim karticama i bez ikakvog uloenog
kapitala. Krajem 1987. godine Cisco je konano uspeo da privue ulaganje kapitala - 2 miliona
dolara od Sequoia Capital za jednu treinu vlasnitva kompanije. U sledeih nekoliko godina
Cisco je nastavio da raste i osvajao je sve vei deo Irita. Istovremeno, odnosi izmeu branog
para Bosak/Lerner i uprave Ciscoa su se kvarili. Cisco je poeo da se kotira na berzi 1990.
godine, ali te iste godine su Lerner i Bosak napustili kompaniju.
Ako imamo tabelu prosleivanja, njeno pretraivanje je u sutini jednostavno - samo se po
tabeli pretraivanja trai stavka koja ima najdui prefiks mree jednak odredinoj adresi paketa,
kao to je objanjeno u odeljku 4.2.2. U praksi, meutim, ivot nije tako jednostavan. Verovatno
je najznaajnija komplikacija to to ruteri okosnice moraju da rade velikom brzinom i da budu u
stanju da izvre na milione pretraivanja u sekundi. Zaista, poeljno je da obrada u ulaznom
portu moe da se obavlja brzinom linije, tj. da se pretraivanje izvri u kraem vremenu nego to
je potrebno da se paket primi u ulazni port. U takvom sluaju obrada primljenog paketa moe da
se dovri pre nego to se zavri sledea operacija prijema, Da biste stekli predstavu o zahtevima
performansi za pretraivanje, uzmite u obzir da takozvani link OC48 funkcionie brzinom od 2,5
Gb/s. Sa paketima duine 256 bajtova to znai da brzina pretraivanja mora biti priblino milion
pretraivanja u sekundi.
Ako se uzmu u obzir dananje potrebe za linkovima velike brzine, linearno pretraivanje
velike tabele prosleivanja je nemogue. Pametnije je stavke tabele prosleivanja uvati u
strukturi stabla podataka. Za svaki nivo stabla moe se smatrati da odgovara jednom bitu u
odredinoj adresi. Da bi se pronala adresa, jednostavno se poinje od osnovnog vora u stablu.
Ako je prvi bit u adresi 0, stavku tabele prosleivanja za odredinu adresu sadri levo podstablo;
inae e adresa biti u desnom podstablu. Kroz odgovarajue podstablo se zatim prelazi pomou
ostalih bitova u adresi - ako je sledei bit u adresi 0, bira se levo podstablo prvog podstabla;
inae se bira desno. Na taj nain stavke tabele prosleivanja pronalaze se u Nkoraka, gde je //broj
bitova u adresi. (italac e primetiti daje to u sutini binarno pretraivanje adresnog prostora
veliine 2
N
.) Jedno unapreenje tehnika za binarno pretraivanje opisano je u [Srinivasan 1999],
a opti pregled algoritama za klasifikaciju paketa moe se nai u [Gupta 2001 ].
AH, ak i za N = 32 koraka (na primer, za 32-bitnu IP adresu), brzina binarnog
pretraivanja nije dovoljna za zahteve rutiranja u dananjim okosnicama. Na primer, ako
pretpostavimo daje potreban po jedan pristup memoriji u svakom koraku, sa vremenom pristupa
memoriji od 40 ns, moglo bi se izvriti manje od milion traenja adresa u sekundi. Zato je bilo
potrebno da se istrai nekoliko tehnika da bi se dobila vea brzina pretraivanja. CAM (Content
Adressable Memories) memorije omoguavaju da im se predstavi 32-bitna IP adresa a one
zatim sutinski konstantnom brzinom vraaju sadraj tabele prosleivanja za tu adresu. Ruter iz
serije Cisco 8500 [Cisco 8500 1999] ima na svakom ulaznom portu CAM od 64 K.
Drugi nain da se ubrza pretraivanje je da se stavke iz tabele prosleivanja kojima je
nedavno pristupano uvaju u kesu [Feldmeier 1988], Potencijalni problem ovde predstavlja
veliina kesa. Predloene su i bre strukture podataka koje omoguavaju da se stavke tabele
prosleivanja pronau u \og(N) koraka [Waldvogel 1997] ili koje komprimuju tabelu
pretraivanja na novi nain [Brodnik 1997]. U [Gupta 1998] opisano je pretraivanje zasnovano
na hardveru optimizirano za opti sluaj u kojem traena adresa ima najvie 24 znaajna bita.
Stl*-?' KRATAK OSVRT

318 318 318 318 POGLAVLJE 4 MRENI SLOJ 4.3 TA IMA U RUTERU? 171 171 171 171

Kada se jednom utvrdi izlazni port paketa, on se prosleuje u komutator. Meutim, paket
moe privremeno da se blokira pre ulaska u komutator (zbog toga to je on trenutno zauzet
paketima iz drugih ulaznih portova). Blokirani paket zato mora da eka u redu ulaznog porta i da
kasnije pree u komutatorsku mreu. U odeljku 4.3.4 poblie emo razmotriti blokiranje,
ekanje u redu i rasporeivanje paketa (u ulaznim i izlaznim portovima) u ruteru.

4.3.2 Komutatorska mrea
Komutatorska mrea se nalazi u samom srcu rutera. Paketi se upravo kroz komutator zaista i
komutiraju (tj. prosleduju) iz ulaznog porta u izlazni. Komutiranje se moe obaviti na vie
naina kao stoje prikazano na slici 4.8.
Komutiranje preko memorije. Najjednostavniji prvi ruteri esto su bili tradicionalni raunari u
kojima se komutiranje izmeu ulaznih i izlaznih portova obavljalo pod direktnom kontrolom
procesora (procesora rutiranja). Ulazni i izlazni portovi fuukcionisali su kao uobiajeni U/I
ureaji u uobiajenom operativnom sistemu. Ulazni port je generisao prekid procesoru
rutiranja uvek kada bi pn-
stigao paket. Paket se tada kopirao iz ulaznog porta u procesorsku memoriju. Procesor
rutiranja je zatim izdvajao odredinu adresu iz zaglavlja, traio odgovarajui izlazni port u
tabeli prosledivanja i kopirao paket u privremene memorije izlaznog porta, Obratite panju
na to da ako je memorijski propusni opseg takav da u memoriju moe da se upie ili iz nje
proita B paketa u sekundi, tada e ukupna propusna mo komutatora (ukupna brzina kojom
se paketi prenose iz ulaznih u izlazne portove) biti manja od S/2.
Mnogi savremeni ruteri takoe komutiraju putem memorije. Meutim, glavna razlika u
odnosu na stare rutere je to to traenje odredine adrese i smeta-nje paketa na
odgovarajue mesto u memoriji izvravaju procesori na ulaznoj linijskoj kartici. Na neki
nain, ruteri koji komutiraju putem memorije veoma lie na multiprocesore sa eljenom
memorijom jer procesori na linijskoj kartici smetaju pakete u memoriju odgovarajueg
izlaznog porta. Ciscovi komutatori serije Catalyst 8500 [Cisco 8500 1999] i ruteri serije Bay
Networks Accelar 1200 komutiraju pakete putem deljene memorije. Apstraktan model za
prouavanje komutiranja putem memorije i poreenja sa ostalim vrstama komutiranja moe
se nai u [lyer 2002].
Komutiranje putem magistrale. Kod ovog reenja ulazni portovi prenose paket direktno u
izlazni port preko zajednike magistrale, bez intervencije procesora rutiranja (obratite panju
na to da kada se komutira preko memorije, paket takoe mora da proe kroz sistemsku
magistralu kada ulazi i kada izlazi iz memorije). Mada se procesor rutiranja ne ukljuuje u
transfer na magistrali, poto se magistrala deli po njoj se moe prenositi samo jedan po jedan
paket, Ako paket stigne na ulazni port dok je magistrala zauzeta transferom drugog paketa,
on se blokira ispred komutatora i ostaje u redu ekanja ulaznog porta. Poto svaki paket mora
da proe kroz tu jednu magistralu, propusni opseg komutiranja u ruleni ogranien je brzinom
magistrale.
Poto dananja tehnologija omoguava propusne opsege magistrale vee od jednog gigabita
u sekundi, komutiranje putem magistrale esto je dovoljno za rutere koji rade u mreama za
pristup i mreama preduzea (na primer, lokalnim i korporacijskim mreama). Komutiranje
putem magistrale koristi se u nizu dananjih rutera ukljuujui i Cisco 1900 [Cisco Switches
1999] koji komutira pakete preko magistrale za razmenu paketa od jednog Gb/s, Sistem
CoreBuilder 5000 kompanije 3Com [Kapoor 1997] meusobno povezuje portove koji se
nalaze na razliitim modulima komutatora preko magistrale podataka PackctChannel sa
propusnim opsegom od 2 Gb/s.
Komutiranje putem viestruko povezane mree. Jedan od naina da se prevazide ogranienje
na propusni opseg jedne jedine zajednike magistrale je upotreba jedne sloenije viestruko
povezane mree kakve su se u prolosti koristile za meusobno povezivanje procesora \i
vieprocesorskoj arhitekturi raunara. Komutator sa unakrsnim linijama je viestruko
povezana mrea koja se sastoji od 2n magistrala koje povezuju n ulaznih portova sa n
izlaznih portova, kao to

172 172 172 172 POGLAVUE 4 . MRENI SLOJ 4.3 TA IMA U RUTERU?
321 321 321 321

je prikazano na slici 4.8. Paket koji stigne na ulazni port putuje po horizontalnoj magistrali
vezanoj za ulazni port, dok se ne ukrsti sa vertikalnom magistralom koja ide do eljenog
izlaznog porta. Ako je vertikalna magistrala koja ide ka izlaznom portu slobodna, paket se
prenosi u izlazni port. Ako je vertikalna magistrata zauzeta transferom paketa iz nekog
drugog ulaznog porta u ovaj isti izlazni port, pristigli paket se blokira i mora da ostane u redu
ekanja ulaznog porta. Delta i Omega komutatorske mree takoe se predlau kao viestruko
povezane mree izmeu ulaznih i izlaznih portova. U knjizi [Tobagi 1990] nai ete pregled
komutatorskih arhitektura. Komutatori familije Cisco 12000 [Cisco 12000 1998] koriste
viestruko povezanu mreu koja omoguava ak 60 Gb/s kroz komutatorsku mreu. Trenutni
trend u dizajnu viestruko povezanih mrea [Keshav 1998] je da se IP datagram promenljive
duine fragmentira u elije fiksne duine, pa se te elije fiksne duine oznae i komutiraju
kroz viestruko povezanu mreu. Od tih elija se zatim u izlaznom portu ponovo sklapa
prvobitni datagram. Fiksna duina elije i oznaavanje znaajno pojednostavljuju i ubrzavaju
komutiranje paketa kroz viestruko povezanu mreu.

4.3.3 Izlazni portovi
Obrada u izlaznom portu, prikazana na slici 4.9, uzima pakete koji su se uvali u memoriji
izlaznog porta i prenosi ih preko izlaznog linka. Obrada protokolom veze podataka i zavretak
linije su funkcije sloja veze i fizikog sloja koje sarauju sa ulaznim portom na drugom kraju
izlaznog linka kao to je opisano u odeljku 4.3.1. Redovi ekanja i upravljanje privremenom
memorijom potrebni su kada komutatorska mrea predaje pakete izlaznom portu brzinom veom
od brzine izlaznog linka. Sada emo obraditi ekanje u redu na izlaznom portu.

4.3.4 Gde dolazi do ekanja u redu?
Ako pogledamo funkcije ulaznih i izlaznih portova i konfiguraciju prikazanu na slici 4.8,
oigledno je da se redovi paketa mogu stvoriti i na ulaznim i na izlaznim porto-vima. Vano je
malo detaljnije razmotriti ove redove ekanja jer kako ti redovi rastu
privremena memorija rutera e se na kraju potroiti i doi e do gubitka paketa. Moda se
seate da smo u prethodnim opisima rekli da se paketi gube u mrei ili isputaju na ruteru.
Upravo ovde u tim ruterovim redovima ekanja se takvi paketi isputaju i gube. Tano mesto
gde se paket gubi (u redu ekanja ulaznog porta ili u redu ekanja izlaznog porta) zavisie od
optereenja saobraajem, relativne brzine komutatorske mree i brzine linija, to emo detaljno
opisati.
Uzmimo da su brzine ulazne i izlazne linije identine i da postoji n ulaznih i n izlaznih
portova. Brzinu komutatora definiemo kao brzinu kojom komutatorska mrea moe da
prenese pakete od ulaznih do izlaznih portova. Ako je brzina komutatora bar n puta vea od
brzine ulazne linije, u ulaznom portu nee doi do ekanja u redu. To je zato to ak i u
najgorem sluaju da svih n ulaznih linija prima pakete komutator e moi da prenese svih n
paketa iz ulaznog porta u izlazni port u vremenu potrebnom da svaki od n ulaznih portova
(istovremeno) primi pojedinani paket. Ali, ta se moe dogoditi na izlaznim portovima?
Pretpostavimo opet daje komutatorska mrea bar n puta bra od linija. U najgorem sluaju,
paketi koji su stigli na svaki od n ulaznih portova bie namenjeni u isti izlazni port. U tom slu-
aju, u vremenu potrebnom da se primi (ili poalje) samo jedan paket, na izlazni port e stii n
paketa. Poto izlazni port moe u tom vremenu da poalje samo jedan paket (vreme prenosa
paketa), n pristiglih paketa morae da eka u redu za prenos preko izlaznog linka. Tada, tokom
vremena potrebnog da se prenese samo jedan od n paketa koji su ve bili u redu za ekanje,
moe da stigne jo n paketa. I tako dalje. U jednom trenutku, broj paketa u redu za ekanje moe
da postane tako veliki da se utroi sav memorijski prostor izlaznog porta i tada se paketi
isputaju.
ekanje u redu izlaznog porta prikazano je na slici 4.10. U trenutku / na svaki od ulaznih
portova stigao je po jedan paket i svi su namenjeni za gornji izlazni port. Ako pretpostavimo da
su brzine linija identine, a da komutator radi tri puta veom brzinom od linija, nakon jedne
jedinice vremena (tj. u vremenu potrebnom da se primi ili poalje jedan paket) sva tri prvobitna
paketa su preneta na izlazni port i ekaju u redu da se prenesu. U sledeoj jedinici vremena jedan
od ta tri paketa bie prenet preko izlaznog linka. U naem primeru, na ulaznu stranu komutatora
stiu dva nova paketa; jedan od njih namenjen je za gornji izlazni port.
Jedna posledica ekanja u redu u izlaznom portu je da rasporeiva paketa u izlaznom
portu mora da izabere jedan od paketa koji ekaju u redu za prenos. Taj izbor moe biti sasvim
jednostavan, kao stoje redosled pristizanja (first-come-Jirst-served, FCFS) ili sloenije
rasporeivanje, kao stoje ponderisano fer ekanje (weig-htedfair queuing, WFQ) u kojem se
izlazni link deli na fer nain izmeu razliitih konekcija sa kraja na kraj iji paketi ekaju na
prenos. Rasporeivanje paketa igra kljunu ulogu u obezbeivanju garancija kvaliteta usluge.
Ova tema bie opirno obraena u poglavlju 7. Opis disciplina u rasporeivanju paketa na
izlaznom portu moete nai u [Cisco Queue 1995].
Slino tome, ako nema dovoljno memorije da se ulazni paket smesti u privremenu
memoriju potrebno je doneti odluku da li da se ispusti paket koji stie (politika poznata pod
imenom ispustiti poslednji) ili da se ukloni jedan ili vie paketa

POGLAVLJE 4 MRENI SLOJ
J322
173 4.4 INTERNET PROTOKOL (IP)

iz reda ekanja i napravi mesto za paket koji upravo stie. U nekim sluajevima korisnije je da se
ispusti paket (ili stavi oznaka u zaglavlje) pre nego to se privremena memorija napuni da bi se
poiljaocu dao signal da postoji zaguenje. U dokumentima [Labrador 1999, HolJot 2002]
predloen je i analiziran niz politika za isputanje i oznaavanje paketa (koje imaju zajedniki
naziv algoritma za aktivno upravljanje redovima ekanja (active queue management, AQM).
Jedan od AQM algoritama koji je najee prouavan i implemetiran je algoritam RED (Random
Early Detection). Ako se koristi RED, izraunava se ponderisani proek duine izlaznog reda
ekanja. Ako je u trenutku kada paket stie prosena duina reda za ekanje manja od praga za
minimum minlh, on se prima u red za ekanje. Obrnuto, ako je u trenutku kada paket stigne red za
ekanje pun ili je prosena duina reda vea od praga za maksimum maxlh, on se oznaava ili
isputa. Na kraju, ako paket stigne i zatekne prosenu duinu reda u intervalu [minlh, maxlh], on
se oznaava ili isputa po verovatnoi koja obino zavisi od prosene duine reda, od minlh i od
maxlh. Do sada je predloen niz funkcija za izraunavanje verovatnoe oznaavanja i isputanja, a
razliite verzije algoritma RED su analitiki modelirane, simulirane i
implementirane. U [Christiansen 2001] i [Floyd 2002] dati su pregledi i predloi za dodatno
itanje.
Ako komutator nije dovoljno brz (u odnosu na brzinu ulazne linije) da bi se svi pristigli
paketi preneli bez zastoja kroz komutator, doi e do redova ekanja i u ulaznim portovima gde
e paketi ekati da budu preneti kroz komutator u izlazni port. Kao ilustraciju jedne vane
posledice ovog ekanja u redu razmotrite komutator sa unakrsnim linijama i pretpostavite (1) da
su brzine svih linkova identine, (2) da se jedan paket moe preneti iz bilo kog ulaznog porta do
datog izlaznog porta u vremenskom intervalu potrebnom da se jedan paket primi na ulaznom
linku i (3) da se paketi prenose iz datog ulaznog reda ekanja u eljeni izlazni red ekanja po
principu FCFS. Istovremeno prenoenje vie paketa mogue je samo ako su im razliiti izlazni
portovi. Meutim; ako su na poetku dva ulazna reda dva paketa namenjena za isti izlazni red
ekanja, jedan od njih e se blokirati i morae da eka u ulaznom redu - komutator moe u isto
vreme da prenosi samo jedan paket u dati izlazni port.
Na slici 4.11 dat je primer u kojem su dva paketa (tamnozelena) na poetku svojih ulaznih
redova ekanja namenjena za isti gornji desni izlazni port. Pretpostavimo da komutator odlui
da prenese paket sa poetka gornjeg levog reda ekanja. U tom sluaju tamnozeleni paket u
donjem levom redu mora da eka. Ali, ne samo to ovaj tamnozeleni paket mora da eka, ve
mora da eka i svetlozeleni paket koji se u donjem levom redu nalazi iza njega, iako nema
nikakvog nadmetanja za srednji desni izlazni port (odredite svetlozelenog paketa). Ovaj
fenomen poznat jc kao HOL (head-of-the-line) blokiranje u komutatoru sa ulaznim redom
ekanja - paket u ulaznom redu mora da eka na prenos kroz komutator (ak i kada je njegov
izlazni port slobodan) jer ga blokira drugi paket u redu ispred njega. Karol u knjizi [Karol 1987]
objanjava da zbog HOL blokiranja ulazni red ekanja dostie neogranienu duinu (to znai da
e doi do znaajnog gubitka paketa) pod odreenim pretpostavkama im brzina pristizanja
paketa na ulazne linkove dostigne samo 58 procenata njihovog kapaciteta. U knjizi [McKeov/n
1997b] opisan je niz reenja za HOL blokiranje.
4. 4 Internet protokol (IP): Prosleivanje i
adresiranje na Internetu
Do sada smo u ovom poglavlju opisivali prosleivanje i adresiranje mrenog sloja ne pominjui
nijednu konkretnu raunarsku mreu. U ovom odeljku obratiemo panju na to kako se
prosleivanje i adresiranje vre na Internetu. Videemo da su prosleivanje i adresiranje
znaajne komponente Internet Protocola (IP). Danas su u upotrebi dve verzije protokola IP. Prvo
emo ispitati opteprihvaeni Internet protokol verzije 4, poznat kao IPv4 [RFC 791]. Na kraju
odeljka ispitaemo IP verziju 6 [RFC 2373; RFC 2460] za koji se predlae da tokom narednih
godina zameni IPv4.

4.4 . INTERNET PROTOKOL (IP) 325 325 325 325

Ali pre nego to krenemo u pohod na IP, vratimo se za jedan korak i razmotrimo komponente
od kojih se sastoji mreni sloj Interneta. Kao to je prikazano na slici 4.13, mreni sloj Interneta ima tri
glavne komponente. Prva komponenta je protokol IP, tema ovog odeljka. Druga vana komponenta
mrenog sloja je komponenta za rutiranje koja utvruje putanju kojom e datagram ii od izvora do
odredita. Videli smo ranije da protokoli rutiranja izraunavaju tabele prosledivanja koje se koriste za
prosledivanje paketa kroz mreu. U odeljku 4.6 prouiemoTnternetove protokole rutiranja. Poslednja
komponenta mrenog sloja je sredstvo za prijavljivanje greaka u datagramima i reagovanje na
zahteve za odreenim informacijama u mrenom sloju. U odeljku 4.4.3 obradiemo ICMP (Internet
Control Message Protocol), Internetov protokol mrenog sloja za izvetavanje o grekama i davanje
informacija.
4. 4. 1 Format datagrama
Sigurno se seate da se paket mrenog sloja naziva datagramom. Prouavanje IP-a poinjemo
pregledom sintakse i semantike datagrama IPv4. Moda mislite da nema nieg suvoparnijeg od
sintakse i semantike bitova nekog paketa. I pored toga, datagram igra centralnu ulogu na Internetu -
svaki student i profesionalac u umreavanju mora da ga vidi, sagleda i savlada. Format datagrama
IPv4 prikazanje na slici 4.13. Kljuna polja 1PV4 datagrama su sledea:
Broj verzije. Ova etiri bita navode verziju protokola IP za taj datagram. Prema broju verzije
ruter moe da odredi kako treba protumaiti ostatak IP datagrama. Razliite verzije protokola IP
koriste razliite formate datagrama. Format datagrama za trenutnu verziju IP-a, IPv4, prikazanje
na slici 4.13. Format datagrama za novu verziju IP-a (IPv6) opisan je pri kraju ovog odeljka.
Duina zaglavlja. Poto datagram IPv4 moe da sadri promenljivi broj opcija (koje su
ukljuene u zaglavlje datagrama IPv4) ova etiri bita su potrebna da bi se odredilo mesto u IP
datagramu gde poinju sami podaci. Veina IP datagrama ne sadri opcije, pa tipini IP
datagram ima zaglavlje od 20 bajtova.
Vrsta usluge. Bitovi za vrstu usluge (type of service, TOS) ukljueni su u IPv4 zaglavlje da bi
se omoguilo prepoznavanje razliitih tipova" IP datagrama (na primer, datagrami koji
zahtevaju to manje kanjenje, veliki propusni opseg ili pouzdanost). Na primer, moglo bi da
bude korisno razlikovati datagrame u real-

175 175 175 175 POGLAVLJE A MRENI SLOJ 4.4 INTERNET PROTOKOL (IP) 175 175 175 175
- i

nom vremenu (na primer, iz neke aplikacije za IP telefoniju) od saobraaja koji nije u
realnom vremenu (na primer, FTP). Nedavno je jedan od glavnih proizvoaa opreme za
rutiranje (Cisco) uveo pravilo da prva tri bita u vrsti usluge definiu nivo usluga koje ruter
moe da obezbedi. Konkretan nivo usluge koja se prua je pitanje politike koju utvruje
administrator rutera. Pitanje diferenciranih usluga detaljno emo obraditi u poglavlju 7.
Duina datagrama. Ovo je ukupna duina IP datagrama (zaglavlje plus podaci), merena u
bajtovima. Poto je ovo polje duine 16 bitova, teoretski maksimalna veliina IP datagrama
je 65.535 bajtova. Meutim, retko se deava da su data-grami vei od 1.500 bajtova.
Sdeniifikator, oznake i ofset fragmentacije. Ova tri polja vezana su za takozvanu IP
fragmentaciju, temu koju emo uskoro detaljno obraditi. Zanimljivo je da nova verzije IP-a,
IPv6, ne dozvoljava da se fragmentiranje vri u ruterima.
Vreme vaenja. Vreme vaenja {time-to-iive, TTL) je polje koje slui da bi se spreilo veno
kruenje datagrama u mrei (na primer, zbog dugotrajne petlje rutiranja). Ovo polje se
smanjuje za 1 u svakom ruteru gde se datagram obrauje. Ako polje TTL dostigne vrednost
0, datagram mora da se odbaci.
Protokol. Ovo polje se koristi samo kada IP datagram stigne do konanog odredita.
Vrednost u ovom polju ukazuje na konkretan protokol transportnog sloja kojem bi trebalo
predati podatke iz IP datagrama, Na primer, vrednost 6 znai da podatke treba predati
protokolu TCP, dok vrednost ] 7 znai da podatke treba predati protokolu UDP. Spisak svih
moguih brojeva moete nai u knjigama [RFC 1700; RFC 3232]. Obratite panju na to da
broj protokola u IP datagramu ima ulogu potpuno analognu broju porta u segmentu
transportnog sloja. Broj protokola je Iepak koji vezuje mreni i transportni sloj, dok je broj
porta lepak koji vezuje transportni i aplikacijski sloj. U poglavlju 5 emo videti da okvir sloja
veze takoe sadri posebno polje koje povezuje sloj veze sa mrenim slojem.
Kontrolni zbir zaglavlja. Kontrolni zbir zaglavlja pomae ruteru u otkrivanju bil-skih
greaka u primljenom IP datagramu. Kontrolni zbir zaglavlja izraunava se tako to se svaka
dva bajta u zaglavlju uzmu kao broj, pa se ti brojevi saberu aritmetikom
komplementajedinice. Kao stoje opisano u odeljku 3.3, komplement jedinice za ovaj zbir,
poznat kao Internetski kontrolni zbir, uva se u polju kontrolnog zbira. Ruter izraunava
kontrolni zbir zaglavlja za svaki primljeni IP datagram i otkriva greku ako kontrolni zbir u
zaglavlju datagrama nije jednak izraunatom kontrolnom zbiru. Ruteri obino odbacuju
datagrame u kojima otkriju greku. Obratite panju na to da kontrolni zbir mora da se
ponovo izrauna i sauva u svakom ruteru zato to se polje TTL i eventualna polja opcija
mogu promeniti. Zanimljiv opis brzih algoritama za izraunavanje Internetskog kontrolnog
zbira nalazi se u knjizi [RFC 1071]. Ovde se esto postavlja pitanje zbog ega TCP/IP vri
proveravanje greaka i u transportnom i u mrenom sloju? Ima mnogo razloga za to
dupliranje. Prvo, primetiete da se u IP sloju kontrolni zbir pravi samo za zaglavlje, dok se
kontrolni zbir TCP/UDP izraunava nad celim TCP ili UDP segmentom. Drugo, TCP/UDP i
IP ne moraju biti iz iste familije protokola. TCP moe u principu da se izvrava i preko
drugih protokola (na primer, ATM-a), a IP moe da prenosi podatke koji nee biti predati u
TCP/UDP.
IP adrese izvora i odredita. Kada izvor napravi datagram, stavlja svoju IP adresu u polje IP
adrese izvora a adresu krajnjeg odredita u polje IP adrese odredita. esto izvomi raunar
utvruje adresu odredita pomou DNS pretraivanja kao to je opisano u poglavlju 2. IP
adresiranje detaljno obraujemo u odeljku 4.4.2.
Opcije. Polje opcija omoguava proirivanje IP zaglavlja. Namera je bila da se opcije
zaglavlja koriste retko - otud i odluka da se smanji optereenje tako to se informacije u
poljima opcija ne ukljuuju u svako zaglavlje datagrama. Meutim, ve samo postojanje
opcija komplikuje stvari - poto zaglavlja datagrama mogu da budu promenljive duine, ne
moe se a priori utvrditi gde poinje polje podataka. Osim toga, poto neki datagrami
zahtevaju obradu opcija a drugi ne, vreme potrebno za obradu IP datagrama u ruteru moe
biti veoma razliito. Ova razmatranja postaju posebno znaajna za IP obradu u ruterima i
raunarima visokih performansi. Zbog tih i jo nekih razloga, IP opcije su izbaene iz IPv6
zaglavlja, kao to se opisuje u odeljku 4.4.4.

176 176 176 176 POGLAVLJE 4 - MRENI SLOJ
4.4 . INTERNET PROTOKOL (IP) 329! 329! 329! 329!

Podaci (korisni podaci). Na kraju, dolazimo do poslednjeg i najvanijeg polja - razloga to
datagram uopte postoji! U veini sluajeva, polje podataka u IP datagramu sadri segment
transportnog sloja (TCP ili UDP) koji treba isporuiti na odredite. Meutim, polje podataka
moe da sadri i druge vrste podataka, kao to su ICMP poruke (koje opisujemo u odeljku
4.4.3).
Obratite panju na to da IP datagram sadri ukupno 20 bajtova zaglavlja (pod
pretpostavkom da nema opcija). Ako datagram prenosi TCP segment, tada svaki
(nefragmentirani) datagram pored poruke iz aplikacijskog sloja prenosi ukupno 40 bajtova
zaglavlja (20 bajtova IP zaglavlja i 20 bajtova TCP zaglavlja).

Fragmentacija IP datagrama
U poglavlju 5 emo videti da ne mogu svi protokoli sloja veze da prenose pakete iste veliine.
Neki protokoli mogu da nose velike" pakete, dok drugi protokoli mogu da nose samo male".
Na primer, Ethernet paketi ne mogu da prenesu vie od 1.500 bajtova podataka, dok paketi
mnogih regionalnih linkova ne mogu da prenose vie od 576 bajtova. Maksimalna koliina
podataka koju moe da prenosi paket sloja veze naziva se maksimalna jedinica za transfer
(maximum transfer unit,. MTU), Poto se svaki IP datagram radi prenosa od jednog rutera do
sledeeg enkapsulira u paket sloja veze, MTU protokola u sloju veze postavlja strogo ogranienje
na duinu IP datagrama. Stroga granica za veliinu IP datagrama nije veliki problem. Problem je
to linkovi na ruti izmeu poiljaoca i odredita moda koriste razliite protokole sloja veze i
svaki od tih protokola moe da ima drugaiji MTU.
Da biste bolje razumeli ovaj problem, zamislite da ste vi jedan ruter koji povezuje nekoliko
linkova od kojih svaki izvrava drugaiji protokol sloja veze sa razliitim MTU-ovima.
Pretpostavimo da ste primili IP datagram od jednog linka, proverili u svojoj tabeli prosleivanja
koji je izlazni link i utvrdili da taj izlazni link ima MTU manji od duine primljenog IP
datagrama. Nastupa panika - kako da stisnete veliki IP paket u polje korisnih podataka paketa
sloja veze? Reenje ovog problema je da se podaci iz IP datagrama fragmentiraju" na dva ili vie
manjih IP datagrama, a zatim se ti manji datagrami poalju preko izlaznog linka. Svaki od ovih
manjih datagrama naziva se fragment.
Fragmenti moraju ponovo da se sastave pre nego to se predaju transportnom sloju na
odreditu. Zaista, i TCP i UDP oekuju da od mrenog sloja prime kompletne nefragmentirane
segmente. Projektanti protokola IPv4 smatrali su da bi ponovno sastavljanje (i eventualno
ponovno fragmentiranje) datagrama u ruterima uvelo znaajnu komplikaciju u protokol i
umanjilo performanse rutera. (Da ste vi'ruter, da li biste pored svog ostalog posla koji imate
voleli jo i da sastavljate fragmente?) Drei se principa da mreni sloj treba da ostane
jednostavan, projektanti IPv4 odluili su da zadatak ponovnog sastavljanja datagrama prepuste
krajnjim sistemima, a ne mrenim ruterima.
Kada odredini raunar primi niz datagrama sa istog izvora, on mora da utvrdi da li su neki
od tih datagrama fragmenti nekog prvobitno veeg datagrama. Ako utvrdi da su neki datagrami u
stvari fragmenti, on mora da utvrdi kada je primio poslednji fragment i kako bi primljene
fragmente trebalo ponovo sastaviti da bi se dobio prvobitni datagram. Da bi odredini raunar
mogao da obavi te zadatke ponovnog sastavljanja, projektanti IP-a (verzija 4) stavili su u IP
datagram polja identifikacija, oznake i ofseta fragmentacije. Kada se datagram pravi, otpremni
raunar mu osim izvorne i odredine adrese dodeljuje i identifikacioni broj. Otpremni raunar
poveava identifikacioni broj za svaki poslati datagram. Kada ruter mora da fragmentira
datagram, svaki novi datagram (tj. fragment) oznaava se izvornom adresom, odredinom
adresom i identifikacionim brojem prvobitnog datagrama. Kada odredite primi niz datagrama
od istog otpremnog raunara, on moe da ispita identifikacione brojeve datagrama i utvrdi koji
su datagrami u stvari fragmenti jednog istog veeg datagrama. Postoje IP nepouzdana usluga,
jedan ili vie fragmenata moda nee ni stii na odredite. Zbog toga, da bi odredini raunar bio
potpuno siguran daje primio poslednji fragment prvobitnog datagrama, poslednji fragment ima u
bitu oznake vrednost 0, dok svi ostali fragmenti imaju vrednost 1. Osim toga, da bi odredini
raunar mogao da utvrdi da li neki fragment nedostaje (i takoe da bi bio u stanju da ponovo
sastavi fragmente u pravilnom redosledu), on koristi polje ofseta da odredi lokaciju fragmenta u
prvobitnom IP datagramu.
Na slici 4.14 dat je jedan primer. Datagram od 4.000 bajtova (20 bajtova IP zaglavlja plus
3.980 bajtova IP korisnih podataka) stie na ruter i mora da se prosledi na link iji MTU iznosi
1.500 bajtova. To znai da 3.980 bajtova podataka iz prvobitnog datagrama treba podeliti u tri
fragmenta (od kojih je svaki takoe IP datagram), Pretpostavite da prvobitni datagram ima
identifikacioni broj 777. Karakteristike tri dobi-jena fragmenta prikazane su u tabeli 4,2.
Vrednosti u tabeli 4.2 odraavaju zahtev da broj bajtova prvobitnih korisnih podataka u svim
fragmentima osim poslednjeg mora biti deljiv sa 8 i da se vrednost ofseta navodi u jedinicama od
po 8 bajtova.
Korisni podaci iz datagrama predaju se transportnom sloju na odreditu tek poto IP sloj
potpuno rekonstruie prvobitni IP datagram. Ako jedan ili vie fragmenata ne stigne do
odredita, datagram se odbacuje i ne predaje se transportnom sloju. Ali, kao to smo nauili u
prethodnom poglavlju, ako se u transportnom sloju koristi TCP, tada e TCP obaviti oporavak
od ovog gubitka tako to e zahtevati da izvor ponovo poalje podatke iz prvobitnog datagrama.
Na veb lokaciji ove knjige pripremili smo Java aplet koji pravi fragmente. Vi zadate
veliinu pristiglog datagrama, MTU i identifikaciju pristiglog datagrama. Aplet vam automatski
generie fragmente. Potraite adresu http://wvAV.awl.com/kurose-ross.

I 177 177 177 177 POGLAVLJE 4 MRENI SLOJ
4.4 INTERNET PROTOKOL (IP) 331 331 331 331

4,4.2 IPv4 adresiranje
Sada skreemo panju na adresiranje protokola IPv4. Mada adresiranje moe da izgleda kao
jednostavna i moda dosadna tema, nadamo sc da ete do kraja ovog poglavlja uvideti da
adresiranje na Internetu nije samo sona, suptilna i zanimljiva tema ve i daje sutinski vano za
Internet. IPv4 adresiranje odlino je obraeno u [Semeria 1996] i prvom poglavlju knjige [Stewart
1999].
Meutim, pre nego to preemo na IP adresiranje, moramo neto rei o nainu na koji su
raunari i ruteri povezani u mreu. Raunar obino ima samo jedan link prema mrei. Kada IP u tom
raunaru hoe da poalje datagram, on e to uraditi preko ovog linka. Granica izmeu raunara i
fizikog linka naziva se interfejs. Razmotrite sada ruter i njegove interfejse. Postoje ruterov zadatak
da prima datagrame u jednom linku i prosledi ga na neki drugi link, ruter obavezno mora biti
povezan sa dva ili vie linkova. Granica izmeu rutera i bilo kojeg od njegovih linkova takode se
naziva interfejs. Ruter znai ima vie interfejsa, po jedan za svaki link, Poto svaki raunar i ruter
moe da alje i prima IP datagrame, IP zahteva da svaki interfejs raunara i rutera ima vlastitu IP
adresu. Prema tome, IP adresa je tehniki pridruena interfejsu, a ne raunaru ili ruteru koji sadri taj
interfejs.
Svaka IP adresa dugaka je 32 bita (etiri bajta), pa tako postoji ukupno 2
n
moguih IP adresa.
Kako je 2
31
priblino 4,3 * IO
3
, evidentno je da postoji oko 4 milijarde moguih IP adresa. Te adrese
se obino piu u takozvanoj decimalnoj notaciji sa ta-kama, u kojoj se svaki bajt adrese zapisuje u
decimalnom obliku a od ostalih bajtova n adresi se razdvaja takama. Uzmite kao primer IP adresu
193.32.216.9. Broj 193 je decimalna vrednost prvih osam bitova u adresi; broj 32 je decimalna
vrednost drugih osam bitova u adresi itd. Prema tome, adresa 193.32.216.9 vi binarnom obliku bi
bila

11000001 00100000 11011000 00001001
Svaki interfejs u svakom raunaru i ruteru u globalnom Internetu mora da ima IP adresu koja je
globalno jedinstvena (osim interfejsa iza NAT-ova koje opisujemo na kraju ovog odeljka). Ove
adrese, meutim, ne mogu da se biraju na proizvoljan nain. Jedan deo IP adrese interfejsa
odreuje podmrea na koju je povezan.
Na slici 4.15 5 5 5 imamo jedan primer IP adresiranja i interfejsa. Na ovoj slici, jedan ruter (sa tri
interfejsa) povezuje sedam raunara. Pogledajte bolje IP adrese dodeljene interfejsima raunara i
rutera; treba obratiti panju na nekoliko stvari. Tri raunara u gornjem levorn delu slike 4.15 i
interfejs rutera sa kojim su povezani imaju IP adrese u obliku 223.1.1.xxx. To jest, svi imaju ista 24
bita IP adrese. Oni su takoe meusobno povezani jednim jedinim fizikim linkom bez ikakvih
posrednih rutera. (Ta mrea bi mogla da bude, na primer, Ethernet LAN pa bi u tom sluaju
inter-fejsi bili povezani Ethernet habom ili Ethernet komutatoroin; videti poglavlje 5.) U IP argonu,
interfejsi \i ta tri raunara i gornji levi interfejs u mieru ine jednu podmreu [RFC 950]. (Podmrea
se u internetskoj literaturi naziva i I P mreom ili prosto mreom.) IP adresiranje dodeljuje adresu
ovoj podmrei: 223.1.1,0/24, gde

4.4 - INTERNET PROTOKOL (IP) 333 333 333 333
- 1

oznaka /24", koja se ponekad naziva maska podmree, znai da levih 24 bita 32 bitne veliine
predstavljaju adresu podmree. Podmrea 223.1.1.0/24 se znai sastoji od tri interfejsa raunara
(223.1.1.1, 223.1.1.2 i 223.1.1.3) i jednog interfejsa rutera (223.1.1.4). Svaki novi raunar koji se
povee na podmreu 223.1.1.0/24 morao bi da ima adresu u obliku 223.1.1.xxx. Na slici 4.15
prikazane su jo dve podmree: podmrea 223.1.2.0/24 i podmrea 223.1.3.0/24. Na slici 4.16
prikazane su tri IP podmree sa slike 4.15.
IP definicija podmree nije ograniena na Ethernet segmente koji povezuju vie raunara sa
jednim interfejsom na ruteru. Da biste to bolje shvatili, razmotrite sliku 4.17 na kojoj su
prikazana tri rutera meusobno povezana linkovima od vora do vora. Svaki ruter ima tri
interfejsa, po jedan za svaki link od vora do vora i jedan za link za difuzno emitovanje koji
direktno povezuje ruter sa parom raunara. Koje IP podmree imamo ovde? Tri podmree,
223.1.1.0/24, 223.1.2.0/24 i 223.1.3.0/24 sline su podmreama koje smo videli na slici 4.15. Ali,
obratite panju na to da u ovom primeru postoje jo tri podmree: jedna podmrea 223.1.9.0/24
za interfejse koji povezuju rutere Rl i R2; jo jedna podmrea 223.1.8.0/24 za interfejse koji
povezuju rutere R2 i R3; i trea podmrea 223.1.7.0/24 za interfejse koji povezuju rutere R3 i Ri,
Za opti meusobno povezani sistem rutera i raunara moemo upo-trebiti sledee pravilo za
definisanje podmrea u sistemu.
Da bi se odredile podmree, prvo razdvajamo svaki interfejs od svog raunara ili rutera i
lako dobijamo ostrva izolovanih mrea na kom se interfejsi nalaze na krajevima izolovanih
mrea. Svaku takvu izolovanu mreu tada nazivamo podmreom.
Ako primenimo ovaj postupak na meusobno povezani sistem sa slike 4.17, dobiemo est
ostrva ili podmrea.
Iz gornjeg opisa je jasno da e organizacija (kompanija ili akademska ustanova) sa vie
Ethernet segmenata i linkova od vora do vdra imati vie podmrea, tako da e svi ureaji u
datoj podmrei imati istu adresu podmree. U principu, razliite podmree mogu da imaju
sasvim razliite adrese podmree. U praksi, meutim, njihove adrese podmrea imaju dosta
zajednikog. Da biste shvatili zato, recimo neto o adresiranju na globalnom Internetu.
Strategija dodeljivanja adresa na Internetu poznata je kao besklasno meudo-mensko
rutiranje CIDR (Classless Interdomain Routing - akronim se izgovara ,,sai-der") [RFC 1519].
CIDR uoptava pojam adresiranja podmree. Kao kod adresiranja podmree, 32-bitna IP adresa
se deli na dva dela opet u decimalnom obliku sa takama a.b.c.d/x, gde x oznaava broj bitova u
prvom delu adrese.
Najznaajnijih x bitova u adresi oblika a.b.c.d/x, ini mreni deo IP adrese i esto se naziva
prefiksom (ili mrenim prefiksom) adrese. Organizaciji se obino dodeljuje blok susednih adresa,
tj. raspon adresa sa zajednikim prefiksom (proitajte opis: Principi u praksi). U ovom sluaju,
IP adrese ureaja u organizaciji imae


zajedniki prefiks. Kada u odeljku 4.6 budemo obraivali Internetov protokol mtira-nja BGP,
videemo da ruteri izvan mree ove organizacije uzimaju u obzir samo tih vodeih x bitova prefiksa.
To jest, kada ruter van organizacije prosleuje datagram ija je odredina adresa u organizaciji,
dovoljno je da uzme u obzir samo vodeih x bitova adrese. To znaajno smanjuje veliinu tabela
prosledivanja u ruterima, poto e satno jedna stavka u obliku a.b.c.d/x biti dovoljna za
prosledivanje paketa u svako odredite unutar organizacije.
Preostalih 32 - x bitova adrese moe se posmatrati kao razlikovanje ureaja unutar
organizacije, koji svi imaju isti mreni prefiks. Ti e bitovi biti u igri kada se paketi prosleduju u
ruterima unutar organizacije. Ove bitove nieg reda organizacija bi mogla (ali ne mora) dalje da deli
postupkom poznatim kao podmree. Na primer, pretpostavite da prvih 21 bitova CIDR adrese
a.b.c.dlll prvih 21 bitova znae mreni prefiks organizacije i zajedniki su za IP adrese svih raunara
te organizacije. Preostalih 11 bitova zatim odreuju konkretne raunare u organizaciji. Unutranja
struktura organizacije bi mogla da bude takva da se tih 11 desnih bitova upotrebi za
podmree unutar organizacije, kao to je gore opisano. Na primer, prefiks a.b.c.d/24 bi mogao da se
odnosi na konkretnu podmreu unutar organizacije.
Dok nije prihvaen CIDR, mreni deo IP adrese je morao da bude dugaak 8, 16 ili 24 bitova,
po adresnoj emi poznatoj kao adresiranje zasnovano na klasama, jer su se podmree ije su
adrese imale 8, 16 ili 24 bitova bile poznate kao mree klase A, B; odnosno C. Zahtev da deo IP
adrese koji se odnosi na mreu bude tano jedan, dva ili tri bajta pokazao se problematinim za
podrku sve veeg broja organizacija sa malim i srednjim podmreama. Podmrea klase C (/24)
mogla bi da sadri samo 2
E
- 2 = 254 raunara (dve od 2
a
= 256 adresa rezerviu se za posebnu
upotrebu) - to nije dovoljno za mnoge organizacije. Meutim, podmrea klase B (/16), koja moe da
podri do 65.634 raunara je prevelika. U adresiranju zasnovanom na klasama organizacija koja je
imala 2.000 raunara obino je dobijala adresu podmree klase B (/16). To je dovelo do naglog
troenja adresnog prostora klase B i loe iskorie-nosti dodeljenog adresnog prostora. Na primer,
organizaciji koja bi za svojih 2.000 raunara koristila adresu klase B bio je dodeljen adresni prostor
za 65.534 interfejsa - pa je ostajalo neiskorieno 63,000 adresa koje su se mogle dodeliti drugim
organizacijama.
Ali, ne bi bilo u redu da ne pomenemo jednu drugu vrstu IP adrese, naime, IP adresu za
difuzno emitovanje 255.255.255.255. Kada raunar emituje datagram sa adresom odredita
255.255.255.255, poruka se isporuuje svim raunarima u istoj podmrei. Ruteri opciono prosleduju
tu poruku i susednim [p podmreama (mada to obino ne rade). U poglavlju 5 emo videti primer
kako se koristi difuzno emitovani IP paket kada budemo opisivali protokol DHCP.
Poto smo detaljno prouili IP adresiranje, moramo da saznamo kako raunar ili podmrea
uopte dobija IP adresu (ili adrese). Prvo emo pogledati kako organizacija dobija blok adresa za
svoje ureaje, a zatim emo videti kako ureaj (na primer raunar) dobija jednu od adresa iz bloka
adresa koje su dobijene za organizaciju.

Dobijanje bloka mrenih adresa
Da bi dobio blok IP adresa koje e se koristiti u podmrei organizacije, administrator mree moe
prvo da pozove svog posrednika Internet usluga koji e mu obezbe-diti adrese iz jednog veeg
bloka adresa koje su ranije dodeljene posredniku Internet usluga. Na primer, posredniku Internet
usluga mogao je biti dodeljen blok adresa 200.23.16.0/20. Zatim bi on mogao da podeli svoj blok
adresa na osam manjih blokova adresa jednake veliine i preda po jedan od tih blokova svakoj od
najvie osam organizacija koje on podrava kao to je prikazano dole u tekstu. (Podvukli smo mreni
deo ovih adresa.)

POGLAVLJE 4 - MRENI SLOJ
336 336 336 336 4.4 . INTERNET PROTOKOL [IP] 180 180 180 180

Posrednikovblok200.23.16,0/20 11001000 00010111 00010000 00000000
Organizacija 0 200.23.16.0/23 11001000 00010111 00010000 00000000
Organizacija 1 200.23.18.0/23 11001000 00010111 00010010 00000000
Organizacija 2 200.23.20.0/23 11001000 00010111 00010100 00000000

Organizacija 7 200.23.30.0/23 11001000 00010111 00011110 00000000
PRINCIPI U PRAKSI
Ovaj primer posrednika za Internet usluge koji povezuje osam organizacija sa Internetom lepo
ilustruje kako paljivo dodeljene CIDR adrese olakavaju rutiranje. Pretpostavimo, kao to je
prikazano na slici 4.1 8, da posrednik (koga emo nazvati FBN) objavljuje spoljnom svetu da mu
treba poslati sve datagrame ijih prvih 20 adresnih bitova glasi 200.23.16.0/20. Ostatak sveta ne
mora da zna da se unutar bloka adresa 200.23.16.0/20 nalazi osam drugih organizacija od kojih
svaka ima vlastitu podmreu. Ova mogunost da se koristi jedan mreni prefiks za oglaavanje vie
mrea esto se naziva agregacija adresa agregacija adresa agregacija adresa agregacija adresa (a takode i agregacija ruta agregacija ruta agregacija ruta agregacija ruta ili sumiranje ruta]. sumiranje ruta]. sumiranje ruta]. sumiranje ruta].
Agregacija adresa izuzetno dobro funkcionie kada se blokovi adresa dodeljuju posrednicima
za Internet usluge, a zatim od posrednika klijentskim organizacijama. Ali, ta se dogaa kada se
adrese ne dodeljuju na takav hijerarhijski nain? ta e se, na primer, dogoditi ako Organizacija 1
poslane nezadovoljna loim uslugama posrednika FBN i odlui da se prebaci kod drugog
posrednika, na primer R-U? Kako je prikazano na slici 4.18, posrednik R-U je vlasnik bloka adresa
199.31.0.0/16, ali IP adrese Organizacije l su naalost izvan tog bloka adresa. ta bi sada trebalo
uraditi? Naravno, Organizacija 1 bi mogla da prenumerie sve svoje rutere i raunare na adrese
unutar bloka adresa posrednika R-U, Ali, to je skupo reenje, i Organizacija 1 bi ve zbog toga
ubudue mogla da pree od posrednika R-U kod nekog drugog. Obino se prihvata reenje da
Organizacija 1 zadri svoje IP adrese u domenu 200.23.18.0/23. U tom sluaju, kao to je
prikazano na slici 4.19, posrednik FBN i dalje objavljuje blok adresa 200.23.16.0/20, a posrednik
R-U blok 199.31.0.0/16. Meutim, posrednik R-U sada objavljuje j o i blok adresa za Organizaciju
1, 200.23.1 8.0/23. Koda ostali ruteri u veem Internetu naiu na blokove adresa 200.23.16.0/20
(posrednika FBN) i 200.23.1 8.0/23 [posrednika, R-U), a ele da rufiraju prema nekoj adresi u bloku
200.23.1 8.0/23 oni e upolrebiri pravilo najdueg prefiksa [videti odeljak 4.2.2) i ruti-rati prema
posredniku R-U poto on objavljuje dui (precizniji) adresni prefiks za traenu adresu odredita.


Dobijanje skupa adresa od posrednika internet usluga je jedan nain da se dobije blok
adresa, aii to nije jedini nain. Jasno je, mora da postoji neki nain na koji sam posrednik Internet
usluga dobija blok adresa. Da li postoji globalno ovlaeno telo sa najviom odgovornou za
upravljanje prostorom IP adresa i dodeljivanje blokova adresa posrednicima Internet usluga i
ostalim organizacijama? Zaista postoji! IP adresama upravlja Internet korporacija za dodeljena
imena i brojeve (Interne! Corporation for AssignedNames and Numbers, ICANN) [ICANN
2004] na osnovu smemica postavljenih u RFC 2050. Uloga neprofitne organizacije ICANN
[NTIA 1998] nije samo dodeljivanje IP adresa, ve takode i upravljanje osnovnim DNS ser-
verima. Ona takoe dodeljuje imena domena i razreava sporove o imenima domena. ICANN
dodeljuje adrese regionalnim Internet registrima (na primer, ARIN, RIPE, APNIC i LACNIC
koji zajedno ine organizaciju za podrku adresa ICANN ASO-ICANN 2004]) koji zatim
dodeljuju adrese i upravljaju svaki u svom regionu.

Pribavljanje adrese raunara
Kada organizacija pribavi blok adresa od svog posrednika Internet usluga, ona moe da dodeli
pojedinane IP adrese raunarskim i ruterskim interfejsima u svojoj organizaciji. Za ruterske
adrese interfejsa, sistemski administrator runo konfigurie IP adrese u ruter (esto to obavlja
daljinski pomou alatki za upravljanje mreom). Raunar moe da dobije IP adresu na jedan od
sledea dva naina:
Runo konfigurisanje. Sistemski administrator runo konfigurie IP adresu u raunar (obino
u datoteku).
Protokol za dinamiko konfigurisanje raunara (DHCP, Dynamic Host Configu-ration
Protokol) [RFC 2131 j. DHCP omoguava raunaru da pribavi (automatski dodeljenu) IP
adresu, kao i da sazna dodatne informacije kao Stoje adresa njegovog rutera za prvi skok i
adresa njegovog DNS servera.
DHCP je u stanju da automatizuje mrene aspekte povezivanja raunara i on se esto naziva
plug-and-play protokolom. Zbog tog svojstva on je veoma privlaan mrenim administratorima
koji bi inae morali te zadatke da obave runo! DHCP takoe ima iroku primenu u kunim
mreama za pristup Internetu i u beinim LAN-ovima u kojima raunari esto pristupaju mrei i
naputaju je.
Mreni administrator moe da konfigurie DHCP tako da dati raunar dobije postojanu IP
adresu tj. da mu se svaki put kada pristupi mrei uvek dodeli ta ista IP adresa. Ali, mnoge
organizacije i kuni posrednici Internet usluga nemaju dovoljno IP adresa za sve svoje raunare.
U takvom sluaju, DHCP se esto koristi da bi se svakom raunaru koji se povezuje dodelila
privremena IP adresa. Na primer, razmotrite kunog posrednika Internet usluga koji ima 2.000
korisnika, ali ih nikad nije istovremeno prikljueno vie od 400. Da bi zadovoljio svojih 2.000
korisnika, posredniku Internet usluga nije potreban blok od 2.000 adresa. Ako umesto toga,
upotrebi DHCP server za dinamiko dodeljivanje adresa, bie mu dovoljan blok od 512 adresa
(na primer, blok u obliku 200.23.30.0/23). Kako raunari dolaze i odlaze, DHCP server mora da
aurira svoju listu dostupnih IP adresa. Kad god se raunar prikljui, DHCP server mu dodeljuje
proizvoljnu adresu iz svog raspoloivog skupa (iz tzv. pula) dostupnih adresa; kada se raunar
iskljui, adresa se vraa u pul.
Drugi znaajan razlog to DHCP ima tako iroku primenu je pojava mobilnog raunarstva.
Uzmite, na primer, studenta koji nosi laptop iz spavaonice u biblioteku pa u uionicu. Vrlo je
verovatno da e na svakom mestu student da se prikljui na drugu mreu pa e mu na svakom cd
tih mesta biti potrebna nova IP adresa. DHCP je idealan za takvu situaciju, poto mnogi
korisnici dolaze i odlaze, a adrese su potrebne samo za ogranieno vreme.
Protokol DHCP ustvari premouje granicu izmeu mrenog sloja i sloja veze u
Internetovoj familiji protokola sa pet slojeva. Zato emo detaljan opis implementacije usluge
DHCP odloiti do poglavlja 5 u kojem se obrauje sloj veze.

Prevodioci mrenih adresa (NAT-ovi)
S obzirom na ono to smo gore rekli, sada smo svesni da svaki ureaj sposoban za IP mora da
ima IP adresu. Sa naglim irenjem takozvanih SOHO (srna!! ofjice, home office) mrea, to bi
naizgled znailo da bi kad god neki SOHO hoe da instalira LAN i meusobno povee vie
maina, posrednik za Internet usluge morao da mu dodeli raspon adresa za sve te maine. Ako bi
mrea kasnije porasla (na primer, kada deca kod kue ne bi imala samo vlastite raunare, ve i
PDA raunare, telefone osposobljene za IP i umreene Gamebov konzole) morao bi im se
dodeliti vei broj adresa. A ta ako je posrednik u meuvremenu ve drugima dodelio
neprekidne delove trenutnog adresnog prostora SOHO mree? I ta uopte prosean kuni
korisnik hoe (ili treba) da zna o upravljanju IP adresama? Sreom, postoji jednostavniji nain
za dodeljivanje adresa, prevoenje mrenih adresa (Network Addrcss Translation, NAT) i on se
u takvim situacijama sve vie koristi [RFC 2663; RFC 3022],
Na slici 4.20 prikazanje NAT ruter. Kuni NAT ruter ima interfejs koji spada u kunu
mreu na desnoj strani slike 4.20. Adresiranje unutar kune mree isto je kao to smo videli
ranije - sva etiri interfejsa kune mree imaju istu mrenu adresu, 10.0.0/24. Adresni prostor
10.0.0/8 je jedan od tri dela prostora IP adresa rezervi-sanih u [RFC 1918] za privatnu mreu ili
carstvo sa privatnim adresama kao to je kuna mrea sa slike 4.20. Carstvo sa privatnim
adresama j e mrea ije adrese neto znae samo ureajima unutar te mree. Da biste videli
zastoje to vano, razmotrite injenicu da postoji na stotine hiljada kunih mrea od kojih mnoge
koriste isti adresni prostor, 10.0.0/24. Ureaji unutar date kune mree mogu jedan drugome da
alju pakete koristei adresiranje 10.0.0/24. Meutim, jasno je da paketi koji se alju preko
granice kune mree u vei globalni Internet ne mogu da koriste te adrese (bilo kao adresu
izvora ili kao adresu odredita) poto ima na stotine hiljada mrea koje koriste taj blok adresa.
To znaci da adrese 10.0.0/24 jedino u datoj kunoj mrei neto znae.

182 POGLAVLJE 4 . MRENI SLOJ
4.4 . INTERNET PROTOKOL (IP) 34i j

Ali ako privatne adrese imaju znaenje samo unutar date mree, kako se sprovodi adresiranje ako
se paketi alju u globalni Internet ili se primaju iz Interneta gde su adrese obavezno jedinstvene?
Odgovor se nalazi u NAT prevoenju,
NAT ruter za spoljni svet ne izgleda kao ruter. Umesto toga, NAT ruter se prema spoljnom
svetu ponaa kao jedan ureaj sa jednom IP adresom. Na slici 4.20 sav saobraaj koji polazi od
kunog rutera prema veem Internetu ima izvornu IP adresu 138.76.29.7 i sav saobraaj koji
dolazi do kue mora imati adresu odredita 138.76.29-7. U sutini, NAT ruter krije detalje kune
mree od spoljnog sveta. (Moda se pitate odakle raunari u kunoj mrei dobijaju adrese i
odakle ruter dobija tu jednu IP adresu. esto je odgovor isti - od DHCP-a! Ruter dobija svoju
adresu od DHCP servera kod posrednika Internet usluga, a isti kuni ruter izvrava DHCP server
koji obezbeduje adrese za raunare u adresnom prostoru kune mree pod kontrolom NAT
DHCP rutera.)
Sada se moda pitate kako taj ruter zna kojem internom raunaru treba da prosledi dobijeni
datagram ako svi datagrami koji do NAT rutera stiu iz regionalne mree imaju istu IP adresu
odredita (konkretno, adresu interfejsa NAT rutera prema regionalnoj mrei)? Trik je u
korienju NAT tabele prevoenja u NAT ruteru i u tome da Se u stavke tabele osim IP adresa
dodaju i brojevi portova.
Razmotrite primer prikazan na slici 4.20. Uzmite da korisnik sedi za raunarom 10.0.0.1 u
kunoj mrei i zatrai veb stranicu od nekog veb servera (port 80) sa IP adresom
128.119.40.186. Raunar 10.0.0.1 dodeljuje (proizvoljan) broj izvornog porta 3345 i alje
datagram u LAN. NAT ruter prima datagram, pravi novi broj izvornog porta 5001 za taj
datagram, zamenjuje izvornu IP adresu svojom IP adresom za WAN 138.76.29.7 i zamenjuje
prvobitni broj izvornog porta 3345 sa 5001. Kada pravi novi broj izvornog porta NAT ruter
moe da izabere bilo koji broj izvornog porta koji se trenutno ne nalazi u NAT tabeli prevoenja.
(Obratite panju na to da poto polje za broj porta ima 16 bitova, protokol NAT moe da podri
preko 60.000 istovremenih konekcija sa jednom samom IP adresom tog rutera za WAN!) NAT u
ruteru takoe dodaje stavku u svoju NAT tabelu prevoenja. Veb server, u blaenom neznanju
daje pristigli datagram koji sadri HTTP zahtev prepravljen u NAT ruteru, odgovara
datagramom ija je odredina adresa IP adresa NAT rutera, a odredini port mu je 5001. Kada taj
datagram stigne u NAT ruter, ovaj pomou odredine IP adrese i broja porta u svojoj NAT tabeli
prevoenja pronalazi odgovarajuu IP adresu (10.0.0.1) i odredini broj porta (3345) za ita u
kunoj mrei. Ruter tada u datagramu prepravlja odredinu adresu i odredini broj porta i
prosleduje datagram u kunu mreu.
NAT uiva iroku primenu poslednjih godina, ali trebalo bi pomenuti da mu se mnogi
istunci u IETF zajednici uno protive. Prvo, oni prigovaraju da su brojevi portova namenjeni
adresiranju procesa, a ne adresiranju raunara. (Ovo krenje zaista moe dovesti do problema za
servere koji se izvravaju u kunoj mrei poto, kako smo videli u poglavlju 2, serverski procesi
ekaju dolazne pozive na dobro poznatim brojevima portova.) Drugo, oni prigovaraju da ruteri
treba da obrauju pakete samo do sloja 3. Tree, oni prigovaraju da protokol NAT kri takozvani
argument od kraja do kraja; tj. da bi raunari trebalo direktno da komuniciraju, a ne da usputni
vorovi menjaju IP adrese i brojeve portova. I etvrto, oni prigovaraju da bi za reenje nedo-
statka IP adresa trebalo upotrebiti IPv6 (videti odeljak 4.4.4), a ne lakomisleno krpiti problem
pomou tapa i kanapa kao to je NAT. Ali, sviao vam se ili ne, NAT je postao znaajna
komponenta Interneta.
Jo jedan veliki problem sa NAT-om je da on ometa P2P aplikacije, ukljuujui P2P
aplikacije za deljenje datoteka i P2P aplikacije za govor preko IP-a. Verovatno se seate iz
poglavlja 2 da u P2P aplikaciji svaki ravnopravni uesnik A mora biti u stanju da inicira TCP
konekciju sa bilo kojim drugim ravnopravnim uesnikom B. Sutina problema je u tome da kad
je uesnik B iza NAT-a on ne moe da preuzme ulogu servera i prihvata TCP konekcije (osim
ako je NAT posebno konfigurisan za P2P aplikacije). Kao to emo videti u domaim zadacima,
ovaj NAT problem moe se izbei ako uesnik A prvo kontaktira sa uesnikom B preko
posrednog uesnika C koji nije iza NAT-a i sa kojim je B uspostavio aktivnu TCP konekciju.
Uesnik A moe tada da zatrai da B preko uesnika C inicira TCP konekciju direktno sa
uesnikom A. im se uspostavi direktna P2P TCP konekcija izmeu uesnika A i B, oni mogu
da razmenjuju poruke ili datoteke. Ovaj trik, koji se naziva preokret konekcije zaista se koristi
u mnogim P2P aplikacijama. Ali ako su i A i B svako iza


svog NAT-a, tada je nemogue uspostaviti TCP konekciju izmeu ta dva uesnika, osim ako se NAT
posebno ne konfigurie za konkretnu aplikaciju.
Na opis NAT-a je ovde morao da bude kratak. NAT ima mnoge druge znaajne aspekte kao
to su statiki i dinamiki NAT i uticaj NAT-a na protokole viih slojeva i na bezbednost. Vie detalja
kao i argumente za NAT i protiv njega nai ete u knjigama [Cisco NAT 2004; Pliifer 2000].

4.4.3 ICMP: Internet Control Message Protocol
Sigurno se seate da mreni sloj Interneta ima tri glavne komponente: IP protokol o kojem smo
govorili u prethodnom odeljku; internetski protokoli rutiranja (ukljuujui RIP, OSPF i BGP) o kojima
se govori u odeljku 4.6 i ICMP, to je tema ovog odeljka.
ICMP, definisan u RFC-u 792, koriste raunari i ruteri za meusobno prenoenje informacija o
mrenom sloju. Najtipinija upotreba ICMP-a je izvetavanje o grekama. Na primer, kada se
izvrava Telnet, FTP ili HTTP sesija, moda ste naili na poruku o greci kao to je Destination
network unreachable" (odredina mrea nedostupna). Ta poruka je potekla iz ICMP-a. U nekom
trenutku, neki IP ruter nije mogao da pronae putanju prema raunaru navedenom u vaoj Telnet,
FTP ili HTTP aplikaciji. Taj ruter je napravio i poslao vaem raunaru ICMP poruku tipa 3 sa
oba-vetenjem o greci.
ICMP se esto smatra delom IP-a, alt u arhitekturi se nalazi neposredno iznad IP-a poto se
ICMP poruke prenose unutar IP paketa. To jest, ICMP poruke se prenose kao korisni podaci IP-a,
isto onako kao to se prenose TCP ili UDP segmenti. Slino tome, kada raunar primi IP paket u
kome se kao protokol gornjeg sloja navodi ICMP, on demultipleksira paket ICMP-u, isto kao to bi ga
demultipleksirao TCP-u ili UDP-u.
ICMP poruke imaju polje tipa i polje ifre a sadre takoe zaglavlje i prvih osam bajtova IP
datagrama koji je doveo do nastanka ICMP poruke (tako poiljalac moe da utvrdi koji je paket
doveo do greke). Nekoliko ICMP poruka dato je na slici 4.21. Obratite panju na to da se ICMP
poruke ne koriste samo za signalisanje greaka.
Veoma poznati program ping alje navedenom raunaru ICMP poruku tipa 8 sa ifrom 0. Kada
odredini raunar vidi zahtev za ehom, on vraa ICMP eho odgovor tipa 0 sa ifrom 0. Veina
implementacija TCP/IP-a podrava ping server direktno u operativnom sistemu; tj. ovaj server nije
proces. Izvomi oblik klijentskog programa ping moete nai u jedanaestom poglavlju knjige [Stevens
1990]. Obratite panju na to da klijentski program mora biti u stanju da naredi operativnom sistemu
da napravi ICMP poruku tipa 8 sa ifrom 0.
Jo jedna zanimljiva ICMP poruka je poruka za suzbijanje izvora. Ta poruka se retko koristi u
praksi. Prvobitna zamisao je bila da se tako kontrolie zaguenje - da zagueni ruter poalje nekom
raunaru ICMP poruku za suzbijanje izvora i primora taj raunar da smanji brzinu slanja. Videli smo
u poglavlju 3 da TCP ima vlastiti mehanizam za kontrolu zaguenja koji funkcionie u transportnom
sloju bez kori-enja povratnih informacija mrenog sloja kakva bi bila ICMP poruka za suzbijanje
izvora.
U poglavlju 1 predstavili smo program Traceroute koji omoguava trasiranje rute od jednog
raunara do bilo kog raunara na svetu. Zanimljivo je daje Traceroute implementiran pomou ICMP
poruka. Da bi se utvrdila imena i adrese rutera izmeu izvora i odredita, Traceroute u izvoru alje
na odredite niz obinih IP datagrama. Svaki od ovih datagrama nosi jedan UDP segment sa malo
verovatnim brojem UDP porta. Prvi od ovih datagrama ima TTL = 1, drugi 2, trei 3 itd. Izvor takoe
pokree tajmere za svaki datagram. Kada -ti datagram stigne do n-tog rutera, n-ti ruter primeuje
daje TTL u datagramu upravo istekao. Prema pravilima protokola IP, ruter odbacuje datagram i alje
izvoru ICMP poruku upozorenja (tip 11 ifra 0). Ta poruka upozorenja sadri ime rutera i njegovu IP
adresu. Kada se ta ICMP poruka vrati do izvora, izvor uzima vreme povratnog puta iz tajmera, a ime
i IP adresu n-tog rutera iz ICMP poruke.

4.4 INTERNET PROTOKOL (IP)
345 345 345 345

Kako Traceroute na izvoru zna kada da prestane sa slanjem UDP segmenata? Sigurno se
seate da za svaki poslati datagram izvor poveava polje TTL. Jedan od datagrama e kad tad
stii do odredinog raunara. Poto datagram sadri UDP segment sa malo verovatnim brojem
porta, odredini raunar e vratiti ICMP poruku da je odredini port nedostupan (tip 3 ifra 3).
Kada izvorni raunar primi tu konkretnu poruku, on zna da ne treba vie da alje istraivake
pakete. (Standardni program Traceroute u stvari alje grupe od po tri paketa sa istim TTL-om;
njegov izvetaj tako sadri po tri rezultata za svaki TTL.)
Na ovaj nain, izvorni raunar saznaje broj i identitet rutera koji se nalaze izmeu njega i
odredinog raunara kao i trajanje povratnog puta meu njima. Obratite panju na to da klijentski
program mora biti u stanju da naredi operativnom sistemu da napravi UDP datagrame sa
odreenim vrednostima TTL, a takoe da bude u stanju da primi obavetenje operativnog
sistema o prispeu ICMP poruka. Poto sada znate kako Traceroute funkcionie, moda ete
poeleti da se jo malo igrate sa njim.

4.4.4 !Pv6
Poetkom 1990-ih godina, IETF (Internet Engineering Task Force) je pokrenuo razvijanje
naslednika za protokol IPv4. Osnovnu motivaciju predstavljalo je to to se uvidelo da 32-bitni
adresni prostor IP-a poinje da se troi, a da e zapanjujuom brzinom poveava broj novih
podmrea i IP vorova koji se povezuju sa Internetom (i dobijaju jedinstvene IP adrese). Da bi
se zadovoljila ova potreba za velikim adresnim prostorom, razvijen je novi IP protokol, IPv6.
Projektanti protokola IPv6 iskoristili su tu priliku da ubace i poveaju i druge elemente na
osnovu prikupljenog operativnog iskustva sa protokolom IPv4.
Dugo se raspravljalo o trenutku kada e sve IPv4 adrese da se potroe (i kada nijedna nova
podmrea nee moi da se povee sa Internetom). Na osnovu tadanjih trendova u dodeljivanju
adresa, procena dvojice voa radne grupe IETF Address Lifetime Expectations bila je da e se
adrese istroiti 2008 odnosno.2018 [Solenskv 1996]. APJN (American Registrv for Internet
Numbers) je 1996. godine izvestio da su ve dodeljene sve IPv4 adrese klase A, 62 procenta
adresa klase B i 37 procenata adresa klase C [ARIN 1996]. Mada su ove procene i izvetaji
ukazivali na to da se ceo adresni prostor IPv4 nee tako brzo potroiti, bilo je jasno da e biti
potrebno dosta vremena da se nova tehnologija uvede na tako iroko podruje, pa je pokrenut
projekat ,,Next Generation IP" (IPng) [Bradner 1996; RFC 1752]. Rezultat tog projekta bila je
specifikacija za IP verziju 6 (IPv6) [RFC 2460]. (esto se postavlja pitanje gde je nestao IPv5.
Prvo se planiralo dae protokol ST-2 postati IPv5, ali se od ST-2 kasnije odustalo i umesto njega
je prihvaen protokol RSVP koji opisujemo u poglavlju 7.)
Odlini izvori informacija o protokolu IPv6 su matina stranica The IP Next Generation
[Hinden 2002] i knjiga na tu temu Huitema [Huitema 1998].
Format datagrama IPv6
Format datagrama IPv6 prikazanje na slici 4.22. Najvanije promene koje donosi IPv6 oigledne
su iz formata datagrama:
Proirene mogunosti adresiranja. IPv6 produava IP adresu sa 32 bita na 128 bitova. Tako
je obezbeeno da se nikada ne potroe sve IP adrese. Sada svako zrno peska na svetu moe da
dobije svoju IP-adresu. Osim jednoznanih i vie-znanih IP adresa, IPv6 je uveo i novu vrstu
adresa, adrese za jednostruko upuivanje (anvcast), koje omoguavaju da se datagram koji se
poalje na takvu adresu isporui samo jednom ali bilo kojem raunaru iz neke grupe. (To
svojstvo moe, na primer, da se upotrebi da bi se poslao HTTP GET najblioj od niza pre-
slikanih lokacija koje sadre dati dokument.)
Kompaktnije 40-bajtno zaglavlje. Kao to emo kasnije opisati, niz polja iz protokola IPv4 je
izbaeno ili je postalo opciono. Tako je dobijeno 40-bajtno zaglavlje fiksne duine koje
omoguava bru obradu IP datagrama. Novo kodiranje opcija obezbeduje njihovu
fleksibilniju obradu.
Oznaavanje i prioriteti toka. IPv6 sadri lukavu definiciju toka. RFC 1752 i RFC 2460
tvrde da to omoguava oznaavanje paketa koji pripadaju konkretnom toku za koji
poiljalac zahteva posebno rukovanje kao to su usluge u realnom vremenu ili kvalitet usluge
vii od podrazumevanog". Na primer, audio i video prenosi mogli bi se tretirati kao tok. S
druge strane, tradicionalnije aplikacije kao to su prenos datoteka i e-pota moda se nee
tretirati kao tokovi. Saobraaj koji prenosi korisnik sa visokim prioritetom (na primer, neko
ko plaa da za svoj saobraaj dobije bolju uslugu) takoe je mogue tretirati kao tok, Jasno

185 185 185 185 POGLAVLJE 4 MRENI SLOJ 4.4 - INTERNET PROTOKOL (IP) 347 347 347 347

je meutim da projektanti protokola IPv6 predviaju eventualnu potrebu da se pravi razlika
meu razliitim tokovima ak iako jo nije utvreno precizno znaenje toka. Zaglavlje IPv6
takoe sadri 8-bitno polje za klasu saobraaja, To polje, kao i polje TOS u protokolu IPv4,
moe se upotrebiti za davanje prednosti odreenim paketima unutar toka ili za davanje
prednosti datagramima iz odreenih aplikacija (na primer, ICMP paketima) nad datagramima
iz drugih aplikacija (na primer, novosti).
Kako smo ve napomenuli, poreenjem slike 4.22 sa slikom 4.13 otkriva se daje struktura
datagrama IPv6 jednostavnija i kompaktnija. U protokolu IPv6 definisana su sledea polja:
Verzija. Ovo polje od etiri bita sadri broj IP verzije. Jasno je da IPv6 u ovom polju sadri
vrednost 6. Obratite panju na to da ako u ovo polje stavite vrednost 4, neete dobiti pravilan
IPv4 datagram. (Kada bi to bilo tako, ivot bi bio mnogo jednostavniji - proitajte u nastavku
opis prelaska sa protokola IPv4 na IPv6.)
Klasa saobraaja. Svrha ovog 8-bitnog polja slina je polju TOS koje smo videli u protokolu
!Pv4.
Oznaka toka. Kao to smo ve opisali, ovo 20-bitno polje se koristi kao identifikacija toka
datagrama.
Duina korisnih podataka. Ova 16-bitna vrednost koristi se kao ceo broj bez predznaka kojim
se odreuje broj bajtova u IPv6 datagramu iza 40-bajtnog zaglavlja fiksne duine.
Sledee zaglavlje. Ovo polje ukazuje na protokol (na primer, TCP ili UDP) kome e se
isporuiti sadraj (polje podataka) ovog datagrama. U ovom polju koriste se iste vrednosti
koje se koriste u polju protokola u zaglavlju IPv4.
Granica za broj skokova. Sadraj ovog polja umanjuje se za jedan u svakom ruteru koji
prosledi datagram. Ako granica za broj skokova postane jednaka nuli, datagram se odbacuje.
Adrese izvora i odredita. Razliiti formati 128-bitne adrese protokola IPv6 opisani su u RFC
2373.
Podaci. Ovo je deo sa korisnim podacima u IPv6 datagramu. Kada datagram stigne na svoje
odredite, korisni podaci e se izdvojiti iz IP datagrama i predati protokolu navedenom u
polju za sledee zaglavlje.
U prethodnom opisu navedene su svrhe polja iz datagrama IPv6. Ako uporedimo format
datagrama IPv6 na slici 4.22 sa fonnatom datagrama IPv4 koji smo videli ranije na slici 4.13,
primetiemo da nekoliko polja koja su postojala u datagramu IPv4 vie ne postoje u datagramu
IPv6:
Fragmentacija/Ponovno sastavljanje. IPv6 ne dozvoljava fragmentiranje i ponovno
sastavljanje u usputnim ruterima; te operacije mogu se vriti samo na izvoru i na odreditu.
Ruter koji primi IPv6 datagram koji je previe velik da bi ga izlazni link prosledio,
jednostavno e odbaciti datagram i vratiti poiljaocu ICMP poruku Packet Too Big" (videti
kasnije). Poiljalac tada moe ponovo da poalje podatke u manjem IP datagramu.
Fragmentiranje i ponovno sastavljanje troe mnogo vremena; oduzimanje tih funkcija od
rutera i njihovo strogo zadravanje u krajnjim sistemima znatno ubrzava IP prosledivanje
unutar mree.
Kontrolni zbir zaglavlja. Poto kontrolne zbirove prave i kontroliu protokoli transportnog
sloja (na primer, TCP i UDP) i sloja veze podataka (na primer, Ethernet), projektanti
protokola IP verovatno su smatrali daje ta funkcija ve dovoljno redundantna u mrenom
sloju i da se moe ukloniti. I ovde je brza obradaTP paketa bila glavna briga. Moda se
seate iz opisa protokola IPv4 u odeljku 4.4.1 da kontrolni zbir zaglavlja IPv4 mora ponovo
da se izraunava na svakom ruteru zato to IPv4 zaglavlje sadri polje TTL (slino polju za
granicu broja skokova u protokolu IPv6). I ta operacija je previe optereivala IPv4, isto kao
fragmentacija i ponovno sastavljanje.
Opcije. Polje opcija vie ne postoji u standardnom IP zaglavlju. Meutim, opcije nisu
uklonjene. Umesto toga, polje opcija postalo je jedno od moguih sledeih zaglavlja na koje
se pokazuje iz IPv6 zaglavlja. To jest, kao to zaglavlja protokola TCP ili UDP mogu da
budu sledea zaglavlja IP paketa to moe da bude i polje opcija. Uklanjanjem polja opcija iz
zaglavlja, dobilo se 40-bajtno IP zaglavlje fiksne duine.
Moda se seate iz naeg opisa u odeljku 4.4.3 da se protokol ICMP koristi meu IP vorovima
za izvetavanje o grekama i za slanje ogranienih informacija (na primer, za eho odgovor na
poruku ping) nekom krajnjem sistemu. Za IPv6 je u RFC 2463 definisana nova verzija ICMP-a.
Osim to su postojee definicije ICMP vrsta i ifara preureene, ICMPv6 ima i nove vrste i ifre
potrebne za nove funkcije protokola IPv6. Tu spada i nova vrsta Packet Too Big" i nova ifra
greke unrecognized IPv6 options" (nepoznate IPv6 opcije). Osim toga, ICMPv6 obuhvata i
funkcije protokola IGMP (Internet Group Management Protocol) koji emo prouiti u odeljku
4.7. IGMP, koji se koristi kada raunar pristupa takozvanim grupama za vieznano emitovanje i
naputa ih. Prethodno je u protokolu IPv4, IGMP bio protokol odvojen od ICMP-a.

Prelazak sa protokola IPv4 na IPv6
Sada poto smo videli tehnike detalje protokola IPv6, razmotrimo jedno veoma praktino
pitanje: kako e javni Internet koji je zasnovan na protokolu ]Pv4 prei na IPv6? Problem je u
tome to novi sistemi osposobljeni za upotrebu protokola IPv6 moga da budu kompatibilni
unazad tj. mogu da alju, rutiraju i primaju IPv4 data-


grame, ali ve uvedeni sistemi osposobljeni za upotrebu protokola IPv4 ne mogu da rukuju
datagramima IPv6. Postoji nekoliko reenja.
Jedno reenje bi bilo da se proglasi jedan granini dan - datum i vreme kada bi se sve
maine na Internetu iskljuile i nadogradile sa protokola IPv4 na IPv6. Poslednja velika promena
tehnologije (kada se za uslugu pouzdanog transporta prelo sa NCP na TCP) dogodila se pre
skoro 20 godina. ak i tada [RFC 801] kadaje Internet bio mali i kadaje njime upravljao mali
broj genijalaca", znalo se da takav granini dan nije mogu. Granini dan koji bi ukljuio na
stotine miliona maina i milione mrenih administratora i korisnika danas je jo tee izvodljiv.
RFC 2893 opisuje dva pristupa (koji mogu da se koriste odvojeno ili u kombinaciji) za postepeno
uvoenje IPv6 raunara i rutera u svet kojim vlada IPv4 (naravno, sa dugoronim ciljem da svi
IPv4 vorovi jednog dana preu na IPv6).
Verovatno najprostiji nain da se uvedu vorovi sposobni za IPv6 jeste pristup sa
dvostrukim stekom, u kojem IPv6 vorovi imaju takoe i kompletnu implementaciju protokola
IPv4. Takav vor, koji se u RFC 2893 naziva IPv6/IPv4 osposobljen je za slanje i primanje obe
vrste datagrama. Kada sarauje sa IPv4 vorom, vor IPv6/IPv4 moe da koristi IPv4
datagrame; kada sarauje sa IPv6 vorom, on moe da koristi jezik IPv6. IPv6/IPv4 vorovi
moraju da imaju obe vrste adresa. Oni moraju ak da budu u stanju da odrede da li je drugi vor
osposobljen za IPv6 ili samo za IPv4. Taj problem se moe resiti pomou DNS-a (proitati
poglavlje 2) koji moe da vrati IPv6 adresu ako je traeni vor osposobljen za IPv6, a inae
vraa IPv4 adresu. Naravno, ako je.vor koji je izdao DNS zahtev sposoban samo za IPv4, DNS
e vratiti samo IPv4 adresu.
U pristupu sa dvostrukim stekom, ako je bilo poiljalac bilo primalac osposobljen samo za
IPv4, mora se koristiti IPv4 datagram. Zbog toga je mogue da dva vora osposobljena za IPv6
na kraju u sutini jedan drugome alju IPv4 datagrame. Ovo je prikazano na slici 4.23. Uzmimo
da je vor A osposobljen za IPv6 i eli da poalje IP datagram voru Fkoji je takode osposobljen
za IPv6. vorovi A i B mogu da razmenjuju IPv6 datagrame. Meutim, vor B mora da napravi
IPv4 datagram da bi mogao da ga poalje voru C. Naravno, polje podataka iz IPv6 datagrama
moe da se prekopira u polje podataka IPv4 datagrama i adrese mogu da se preslikaju na
odgovarajui nain. Meutim, prilikom konverzije iz protokola IPv6 u IPv4 posto-jae polja
specifina za IPv6 (na primer, identifikator toka) za koja nema odgovarajuih polja u protokolu
IPv4. Informacije iz tih polja bie izgubljene. Na taj nain, i pored toga to E i F mogu da
razmenjuju IPv6 datagrame, IPv4 datagrami koji u vor E stignu iz vora D ne sadre sva polja
koja su postojala u prvobitnom IPv6 datagramu koji je poslat iz A.
Jedna alternativa reenju sa dvostrukim stekom koja je takoe opisana u RFC-u 2893,
poznata je kao tunelovanje. Tunelovanje moe da resi gore navedeni problem, jer omoguava,
na primer, da E primi IPv6 datagram koji je nastao u voru A. Osnovna ideja tunelovanja je
sledea. Uzmimo da dva IPv6 vora (na primer, B i E sa slike 4.23) ele da sarauju i koriste
IPv6 datagrame ali su meusobno povezani preko usputnih IPv4 rutera. Usputne IPv4 rutere
izmeu dva IPv6 rutera nazivamo
tunelom, kao stoje prikazano na slici 4.24. Kada se koristi tunelovanje, IPv6 vor na otpremnoj
strani tunela (na primer, B) uzima ceo IPv6 datagram i stavlja ga u polje podataka (korisnih
podataka) IPv4 datagrama. Taj IPv4 datagram se zatim adresira IPv6 voru na prijemnoj strani
tunela (na primer, voru E) i alje prvom voru u tunelu (na primer, voru C). Usputni IPv4
ruteri u tunelu rutiraju ovaj IPv4 datagram medu sobom, kao to bi radili sa bilo kojim
datagramom, u blaenom neznanju da taj IPv4 datagram sadri ceo IPv6 datagram. IPv6 vor na
prijemnoj strani tunela konano prima IPv4 datagram (to i jeste odredite IPv4 datagrama!),
utvruje da IPv4 datagram sadri IPv6 datagram, izdvaja IPv6 datagram i zatim ga rutira isto
kao da gaje primio od direktno povezanog IPv6 suseda.
Ovaj odeljak zakljuujemo napomenom daje prihvatanje protokola IPv6 sporo poelo
[Lawton 2001]. Sigurno seseate da je jedan od glavnih razloga za uvoenje protokola IPv6 bilo
to to su se dostupne IPv4 adrese potroile. U odeljku 4.4.2 smo videli da su unapreenja kao to
su CIDR adrese za IPv4, DHCP i NAT doprinela reavanju ovog problema barem kratkorono.
Mogue je, meutim, da sve ira upotreba ureaja kao to su telefoni osposobljeni za IP i drugi
prenosivi ureaji obezbede potreban pritisak za bre uvoenje verzije IPv6. Evropski program
partnerstva tree generacije (Europe 's Third Generation Partnership Program) [3GPP 2004]
kao standardnu emu adresiranja za mobilne multimedije navodi IPv6. ak i ako IPv6 nije
opteprihvaen tokom prvih 9 godina njegovog ivota, potrebno je posmatrati stvari dugorono.
I za prihvatanje dananjeg sistema telefonskih brojeva bilo je potrebno vie desetina godina ali je
on sada u funkciji ve skoro pola veka i nema nagovetaja da e se ukinuti. Slino tome, bie
potrebno vreme da se prihvati IPv6, ali i on e nakon toga dugo biti na snazi. Brajan Karpenter,
bivi predsedavajui lAB-a (Internet Architecture Board) [IAB 2004] i autor vie RFC-a koji se
odnose na IPv6 kae uvek sam to smatrao procesom od 15 godina koji poinje 1995" [Lawton
2001], Prema Karpenterovim datumima, pribliavamo se taki na dve treine puta!

350
4.5 ALGORITMI RUTIRANJA 351

Jedna vana lekcija koju moemo nauiti iz iskustva sa protokolom IPv6 jeste da je uasno
teko menjati protokole mrenog sloja. Ve od poetka 90-tih godina niz novih protokola za
mreni sloj reklamirano je kao sledea velika revolucija na Internetu, ali je veina njih do danas
imala ogranien domet. Tu spadaju IPv6, protokoli za vieznano upuivanje (odeljak 4.7) i
protokoli za rezervisanje resursa (poglavlje 7). Zaista, uvoenje novih protokola u mreni sloj
slino je situaciji u kojoj bismo se nali kada bismo zamenjivali temelje kue - to se teko postie
bez ruenja cele graevine ili bar privremenog raseljavanja njenih stanovnika. S druge strane,
Internet je doiveo naglo uvoenje vie novih protokola u aplikacijskom sloju. Klasini prime-ri,
naravno, jesu Web, trenutno slanje poruka i deljenje datoteka meu ravnopravnim raunarima.
Jo neki primeri su protok audio i video signala u realnom vremenu i distribuirane igre, Uvoenje
novih'protokola aplikacisjkog sloja je kao kreenje kue - relativno se lako izvodi i ako ste
izabrali privlanu boju, imitirae vas i neki susedi. Da rezimiramo, u budunosti se mogu
oekivati promene u mrenom sloju Interneta, ali e te promene verovatno biti mnogo sporije od
promena u aplikacijskom sloju.
4.5 Algoritmi rutiranja
Do sada smo u ovom poglavlju uglavnom istraivali funkciju prosledivanja u mrenom sloju.
Nauili smo da kada paket stigne u ruter, ruter indeksira tabelu prosledivanja i utvruje na koji
interfejs linka treba usmeriti paket. Takoe smo nauili da algoritmi rutiranja koji se izvravaju
u mrenim ruterima razmenjuju i izraunavaju informacije potrebne za konfigurisanje tih tabela
prosledivanja. Odnos izmeu algoritma rutiranja i tabele prosledivanja prikazanje na slici 4.2,
Poto smo donekle istraili prosledivanje, sada posveujemo panju drugoj vanoj temi ovog
poglavlja, kritinoj funkciji mrenog sloja - rutiranju. Bez obzira na to da li mreni sloj prua
uslugu datagrama (kada izmeu datog para izvora i odredita razliiti paketi mogu da idu
razliitim rutama) ili uslugu virtuelnog kola (kada svi paketi izmeu datog izvora i odredita idu
uvek istom putanjom) mreni sloj ipak mora da utvrdi putanju za svaki paket. Videemo daje
posao rutiranja da se utvrde dobre putanje (tj. rute) od poiljalaca do primalaca kroz mreu
rutera.
Obino se raunar vezuje direktno na jedan ruter, takozvani podrazumevani ruter za taj
raunar (takoe se naziva i ruter prvog skoka za taj raunar), Kad god raunar emiruje paket,
on se prenosi na njegov podrazumevani ruter. Podrazumevani ruter izvornog raunara nazivamo
izvornim ruterom, a podrazumevani ruter odredinog raunara odredinim ruterom. Problem
rutiranja paketa od izvornog do odredinog raunara jasno se svodi na problem mtiranja paketa
od izvornog do odredinog rutera, a to je tema ovog odeljka.
Svrha algoritma rutiranja je jednostavna: ako je dat skup rutera sa linkovima koji ih
povezuju, algoritam rutiranja pronalazi dobni" putanju od izvornog do odredinog rutera.
Obino je dobra putanja ona koja ima najmanju cenu. Videemo, meutim, da po koncepciji
jednostavne i elegantne algoritme na kojima se zasniva rutiranje u dananjim mreama, u praksi
komplikuju realni problemi kao io su pitanja politike (na primer, pravilo kao stoje ruter* koji
pripada organizaciji 7 ne bi trebalo da prosleuje pakete koji potiu iz mree u vlasnitvu
organizacije Z").
Za formulisanje algoritama rutiranja koristi se graf. Verovatno se seate da je graf G = (N,
)$kup od N vorova i kolekcija ivica, gde je svaka ivica par vorova iz skupa JV. U
kontekstu rutiranja u mrenom sloju, vorovi u grafu predstavljaju rutere - take na kojima se
donose odluke o prosledivanju paketa - a ivice (u terminologiji teorije grafova -periferije") koje
povezuju te vorove predstavljaju fizike linkove izmeu rutera. Takva grafika apstrakcija
raunarske mree prikazana je na slici 4.25. Grafove koji predstavljaju mape stvarnih mrea
moete nai u knjigama [Dodge 1999, Cheswick 2000]; opis kvaliteta modeliranja razliitih
grafikih modela Interneta nai ete u knjigama [Zegura 1997, Faloutsos 1999].

352 352 352 352 POGLAVLJE 4 - MRENI SLOJ 4.5 ALGORITMI RUTIRANJA 353 353 353 353

Kao to se vidi na slici 4.25, ivica takoe ima vrednost koja predstavlja njenu cenu. Cena
moe da zavisi od fizike udaljenosti kojom se prostire taj link (na primer, prekookeanski link
moe da ima veu cenu od kratkog zemaljskog linka), od brzine linka ili od novanog iznosa
cene pridruene tom linku. Za nae trenutne potrebe uzeemo cenu linka kao datu i neemo
brinuti o tome kako se ona utvruje. Za svaku ivicu (x,y) u E cenu ivice izmeu vorova x i y
oznaiemo sa c(x,y). Ako par (x,y) ne pripada E staviemo daje c(x,y)~ . Takoe, sve vreme
emo razmatrati neusmerene grafove (tj. grafove ije ivice nemaju smer), tako daje ivica (x,y)
jednaka ivici (y,x) i daje c(x,y) = c(y,x). Osim toga, za vor y kaemo daje susedan voru x
ako (x,y) pripada kolekciji E.
Ako uzmemo da su ivicama ove grafike apstrakcije dodeljene cene, prirodan cilj algoritma
rutiranja je da se pronau putanje sa najmanjom cenom od izvora do odredita. Da bismo
problem postavili preciznije, prisetite se daje putanja u grafu
G = (N, E) niz vorova (*,, x2 .......... xp) takvih daje svaki od parova (x1,x1), x3),
(x,, x ) ivica izE. Cena putanje (x,, x2, >..t xp)je prosto zbir cena svih ivica na putanji, tj. C(JC,,
x2) + c(x2, JC3) + ... + C(JC xp). Za svaki par vorova x i y obino postoji vie putanja koje ih spajaju,
a svaka od njih ima svoju cenu. Jedna ili vie od ovih putanja su putanje sa najmanjom cenom.
Problem najmanje cene je, dakle, jasan: pronai putanju izmeu izvora i odredita koja ima
najmanju cenu. Na primer, na slici 4.25 putanja sa najmanjom cenom od izvornog vora u do
odredinog vora w je (u, x, y, w) sa cenom putanje jednakom 3. Obratite panju na to da ako su
cene svih linkova jednake, putanja sa najniom cenom je takoe i najkraa putanja (tj. putanja
koja od izvora do odredita prelazi najmanji broj linkova).
Ponite od jednostavne vebe da pronaete putanju sa najmanjom cenom od vora u do
vora z na slici 4.25 i razmislite malo o nainu na koji ste izraunali tu putanju. Ako razmiljate
slino veini ljudi, utvrdili ste putanju od vora u do vora z tako to ste posmatrali sliku 4.25,
isprobali nekoliko putanja od u do z i na neki nain doli do zakljuka daje putanja koju ste
izabrali najjeftinija od svih moguih putanja. (Da li ste proverili svih 17 moguih putanja
izmeu u i z? Verovatno niste!) Takvo izraunavanje je primer centralizovanog algoritma
rutiranja - algoritam rutiranja je izvren najednom mestu, u vaoj glavi, sa kompletnim
informacijama o celoj mrei. Jedan od naina na koji se algoritmi rutiranja klasifikuju je po
tome da li su globalni ili decentralizovani.
Globalni algoritam'rutiranja izraunava putanju sa najmanjom cenom od izvora do odredita
pomou kompletnog.globalnog znanja o celoj mrei. On upotrebljava podatke o povezanosti
svih vorova i cene svih linkova. Znai, algoritam mora nekako da pribavi te informacije pre
samog izraunavanja. Samo izraunavanje moe da se izvrava na jednoj lokaciji
(centralizovani globalni algoritam rutiranja) ili da bude replicirano na vie lokacija. Kljuna
karakteristika je, meutim, to da globalni algoritam ima kompletne informacije o
povezanosti i o cenama linkova. U praksi, algoritmi sa globalnim informacijama o stanju
esto se nazivaju algoritmima prema stanju linkova (link state, LS), poto algoritam mora
biti upuen u cenu svakog linka u mrei. Algoritam globalnog stanja linkova prouiemo u
odeljku 4.5.1.
U decentralizovanom algoritmu rutiranja, izraunavanje putanje sa najmanjom cenom
izvrava se na iterativni distribuirani nain. Nijedan vor nema kompletne informacije o
cenama svih mrenih linkova. Umesto toga, svaki vor poinje samo od saznanja o cenama
vlastitih direktno povezanih linkova. Zatim pomou iterativnog procesa izraunavanja i
razmene informacija sa susednim vorovima (tj. vorovima koji se nalaze na suprotnoj strani
linkova sa kojima je vor neposredno povezan) vor postepeno izraunava putanju sa
najniom cenom do jednog odredita ili skupa odredita. Decentralizovani algoritam ruti-
ranja koji emo prouiti u odeljku 4.5.2. poznat je kao algoritam sa vektorom rastojanja
(distance vector, DV) zato to svaki vor odrava vektor procenjenih cena (rastojanja) do
svih ostalih vorova u mrei.
Jo jedan nain za grubu klasifikaciju algoritama rutiranja je prema tome da li su statiki ili
dinamiki. Kod statikih algoritama rutiranja rute se menjaju veoma t retko, esto ljudskom
intervencijom (na primer, ovek runo ureuje tabelu prosleivanja u ruteru). U dinamikim
algoritmima rutiranja putanje rutiranja se menjaju kako se menja optereenje mree saobraajem ili
njena topologija. Dinamiki algoritam moe se izvravati povremeno ili kao direktan odgovor na
promene topologije ili cene linkova. Dok dinamiki algoritmi bolje reaguju na promene u mrei,
oni su takode i osetljiviji na probleme kao to su petlje rutiranja i oscilacije na rutama.

J354 ' POGLAVLJE 4 - MRENI SLOJ
4.5 - ALGORITMI RUTIRANJA 355

Trei nain da se klasifikuju algoritmi rutiranja je prema tome da li su osetljivi na
optereenje. Kod algoritma osetljivog na optereenje, cene linkova se menjaju dinamiki
zavisno od trenutnog nivoa zaguenja odreenog linka. Ako se linku koji je trenutno zaguen
pridrui visoka cena, algoritam rutiranja e teiti da bira rute koje izbegavaju taj zagueni link.
Na poetku su algoritmi rutiranja ARPAneta bili osetljivi na optereenje [McQuillan 1980] ali se
pojavio niz potekoa [Huitema 1998]. Algoritmi rutiranja dananjeg Interneta (kao to su PJP,
OSPF i BGP) nisu osetljivi na optereenje poto cena linka ne reflektuje eksplicitno trenutni (ili
nedavni) stepen zaguenja.

4.5.1 Algoritam rutiranja prema stanju linkova
Imajte na umu da su u algoritmu prema stanju linkova topologija mree i cene svih linkova
poznate, tj. dostupne kao podaci za algoritam stanja linkova. U praksi ovo se postie tako to
svaki vor difuzno emituje identitet i cenu svojih povezanih linkova svim ostalim ruterima u
mrei. U praksi (na primer pomou Internetovog protokola rutiranja OSPF koji obraoujemo u
odeljku 4.6.1) ovo se esto postie algoritmom za difuzno emitovanje stanja linkova [Perlman
1999]. Algoritme za difuzno emi-tovanje obradiemo u odeljku 4.7. Na kraju svih difuzno
emitovanih stanja linkova svi e vorovi imati identian i kompletan pregled mree. Tada svaki
vor moe da izvrava algoritam prema stanju linkova i da izrauna isti skup putanja sa
najniom cenom kao i svaki drugi vor.
Algoritam prema stanju linkova koji emo sada predstaviti poznat je kao Dijkstrin.
algoritam, prema svom pronalazau. Primov algoritam je veoma slian; u [Cormen 2001] nai
ete opti opis grafovskih algoritama. Dijkstrin algoritam izraunava putanju sa najniom cenom
od jednog vora (izvora, koji emo nazvati u) do svih ostalih vorova u mrei. Dijkstrin
algoritam je iterativan i ima svojstvo da su nakon jfe-te iteracije algoritma poznate putanje sa
najniom cenom do k odredinih vorova, a meu putanjama sa najniom cenom do svih
odredinih vorova; ili, ovih k putanja imaju k najniih cena. Defmisaemo sledee oznaavanje:
D(y): cena putanje od izvornog vora do odredita v koja trenutno (prema trenutnoj iteraciji
algoritma) ima najmanju cenu.
p(y): prethodni vor (sused vora v) na putanji sa trenutno najmanjom cenom od izvora do v.
N': skup vorova sa konano utvrenom najjeftinijom putanjom od izvora.
Globalni algoritam rutiranja sastoji se od jednog poetnog koraka nakon kojeg sledi petlja.
Broj ponavljanja petlje jednak je broju vorova u mrei. Na kraju, algoritam e imati izraunate
najkrae putanje od izvornog vora u do. svakog drugog vora u mrei.
Algoritam stanja linkova (Link State, LS) za izvorni vor u:
1 Inicijalizacija:
2 N' = {u}
3 za sve vorove v
4 ako je v sused u
5 then D(v) = c(u,v)
6 else D(v) = 7
8 Loop
9 petlja w nije u N' tako da je D<w) minimum koji
10 w dodaje u N'
11 aurira D(v) za sve v susedne w koji nisu N':
12 D(v) = min(D(v), D(w) + c(w,v) )
13 /* nova cena do v je stara cena do v ili cena poznate
14 najkrae putanje do w plus cena od w do v */
15 until N' = N
Kao primer, razmotrimo mreu na slici 4.25 i izraunajmo putanje sa najniim cenama od u
do svih moguih odredita. Tabelarni pregled izraunavanja po ovom algoritmu prikazanje u
tabeli 4,3, gde svaki red tabele daje vrednosti promenljivih iz algoritma na kraju jedne iteracije.
Razmotrimo detaljno prvih nekoliko koraka.
U koraku inicijalizacije trenutno poznatim putanjama sa najmanjim cenama od u do
njegovih direktno povezanih suseda, v, x i w daju se poetne vrednosti 2, 1 odnosno 5.
Obratite posebno panju na to da cena do w dobija vrednost 5 (mada emo uskoro videti da
postoji putanja sa manjom cenom) postoje to cena direktnog linka Gadnog skoka) od u do
w. Cenama doyiz daje se vrednost beskonano zato to oni nisu direktno povezani sa u.
U prvoj iteraciji pregledamo vorove koje jo nismo dodali skupu N' i pronalazimo vor sa
najmanjom cenom na kraju prethodne iteracije. Taj vor je x sa cenom I i tako se x dodaje
skupu N'. Tada se izvrava red 12 algoritma LS da bi se auriralo D(v) za sve vorove v,
ime se dobijaju rezultati prikazani u drugom redu (korak 1) tabele 4.3. Cena putanje do v
nije se promenila, Cena putanje do w (koja je na kraju inicijalizacije iznosila 5) ako se ide
preko JC ima cenu 4. Zato se bira ova putanja sa niom cenom, a prethodni vor vora w na
najkraem putu od u postaje x. Slino tome, cena do vora y (preko x) iznosi 2, a tabela se
aurira u skladu sa tim.

4.5 . ALGORITMI RUTIRANJA 35*

U drugoj iteraciji vorovi v i y se pokazuju kao najjeftiniji (2), pa proizvoljno reavamo nereeni
rezultat i u skup//' dodajemo y tako da A'"' sada sadri u , x \ y . Cena do preostalih vorova jo
se ne nalazi u N\ tj. vorovi v , wi z auriraju se u 12. redu algoritma LS gde se dobijaju
rezultati prikazani u treem redu tabele 4.3.
I tako dalje...

Kada se algoritam LS zavri, za svaki vor se zna prethodnik na putanji sa najniom cenom od
izvornog vora. Za svakog prethodnika takode je poznat njegov prethodnik, pa na taj nain moemo
da napravimo celu putanju od izvora do svih odredita. Tabela prosleivanja u svakom voru, na
primer u voru u , zatim moe da se napravi od ovih informacija tako to se za svako odredite uva
vor za sledei skok po putanji sa najniom cenom od u do tog odredita.
U emu je raunska sloenost ovog algoritma? To jest, ako je dato n vorova (ne raunajui
izvor), koliko izraunavanja treba izvriti u najgorem sluaju da bi se pronale najjeftinije putanje od
izvora do svih odredita? U prvoj iteraciji moramo da pretraimo svih n vorova da bismo odredili
vor w koji ima najmanju cenu a nije u skupu A
7
'. U drugoj iteraciji moramo da proverimo n - 1
vorova da bismo utvrdili najmanju cenu; u treoj iteraciji proveravamo n - 2 vorova itd. Sveukupno,
ukupan broj vorova koje moramo da ispitamo u svim iteracijama je n(n + I)/2, pa tako kaemo da
prethodna implementacija algoritma prema stanju linkova ima sloenost najgoreg sluaja reda n na
kvadrat: 0(n
2
). (Pomou jedne sloenije implementacije ovog algoritma, u,kojoj se koristi struktura
podataka poznata kao hip, mogue je pronai minimum ve u devetom redu u logaritamskom umesto
linearnom vremenu, ime se sloenost smanjuje.)
Pre nego to zakljuimo opis algoritma LS, razmotriemo nepoeljan sluaj do kojeg moe doi.
Na slici 4.26 prikazana je topologija jednostavne mree gde su cene linkova jednake optereenju
koje se tim linkom prenosi, na primer, da reflektuju kanjenje koje bi se pojavljivalo. U ovom primeru,
cene linkova nisu simetrine; tj. c(u,v) jednako je c(yyu) samo ako su na linku ( u , v ) optereenja u
oba' smera jednaka. U ovom primeru, iz vora z polazi jedinica saobraaja sa odreditem w, sa
vora x ta-
kode kree jedinica saobraaja sa odreditem w, a vor.y ubacuje koliinu saobraaja jednaku e,
takoe prema odreditu w. Poetno rutiranje prikazano je na slici 4.26(a) gde cene linkova
odgovaraju koliini prenetog saobraaja.
Kod sledeeg izvravanja algoritma LS, vor^ utvruje (na osnovu cena linkova prikazanih na
slici 4.26(a)) daje putanja do wu smeru kazaljke na satu ima cenu 1, dok putanja do istog odredita
u smeru suprotnom od kazaljke na satu koja se dotle koristila) ima cenu 1 + e. Zbog toga je putanja
do w sa najniom cenom sada u smeru kazaljke na satu. Slino tome, x utvruje da je njegova
putanja sa najniom cenom do w takoe u smeru kazaljke na satu, pa dobijamo cene kao na slici
4.26(b). Pri sledeem izvravanju algoritma LS, vorovi x, y, i z svi primeuju putanju sa cenom 0
prema w u smeru suprotnom od kazaljke na satu i svi rutiraju svoj saobraaj rutama suprotnim od
kazaljke na satu. Kod sledeeg izvravanja algoritma LS, x , y , i z svi rutiraju svoj saobraaj u smeru
kazaljke na satu.

ks8 POGLAVLJE 4 MRENI SLOJ 4.5 . ALGORITMI RUTIRANJA 359 359 359 359

ta da se uradi da bi se spreile takve oscilacije (do kojih moe doi ne samo u algoritmu
LS ve u svakom algoritmu koji koristi merenja zaguenja ili kanjenja na linkovima)?
Jedno reenje bilo bi da se propie da cene linkova ne smeju zavisiti od koliine prenetog
saobraaja - to reenje nije prihvatljivo poto je jedan od ciljeva rutiranja upravo izbegavanje
veoma zaguenih linkova (na primer, onih sa velikim kanjenjem). Drugo reenje je da se sprei
istovremeno izvravanje algoritma LS u svim ruterima. Ovo izgleda prihvatljivije, poto bismo
se nadali da ak i kada ruteri izvravaju algoritam LS u istim vremenskim intervalima instanca
algoritma ne bi bila ista u svim vorovima. Zanimljivo je da su istraivai nedavno utvrdili da
ruteri na Internetu mogu sami da se meusobno sinhronizuju [Floyd Svnchronization 1994], To
jest, ak i kada na poetku izvravaju algoritam u istim vremenskim intervalima ali u razliito
vreme, primerak instanca u ruterima vremenom postaje i ostaje sin-hronizovana. Jedan od naina
da se izbegne takva samosinhronizacija jeste da svaki ruter sluajno bira vreme kada e da
poalje objavu linka.
Poto smo prouili algoritam prema stanju linkova, sada emo prouiti drugi znaajan
algoritam rutiranja koji se koristi u dananjoj praksi - algoritam rutiranja sa vektorom rastojanja.

4 . 5 . 2 Algoritam rutiranja sa vektorom rastojanja
Dok algoritam LS koristi globalne informacije, algoritam sa vektorom rastojanja {distance
vector, DV) je iterativan, asinhron i distribuiran. On je distribuiran po tome to svaki vor prima
odreene informacije od jednog svog direktno povezanog suseda ili od vie njih, izraunava, a
zatim distribuira rezultate svog izraunavanja tim istim susedima. On je iterativan po tome to se
ovaj postupak ponavlja sve dok ima informacija za razmenu meu susedima. (Zanimljivo je,
videemo da se ovaj algoritam sam zaustavlja - ne postoji signal da izraunavanje treba
prekinuti; ono se prosto zavri.) Algoritam je asinhron po tome to nije neophodno da svi
vorovi rade usaglaeno. Videemo daje asinhroni, iterativni, distribuirani algoritam koji se sam
prekida daleko zanimljiviji i zabavniji od centralizovanog algoritma!
Pre nego to predstavimo algoritam DV, bie korisno da opiemo jedan vaan odnos koji
postoji izmeu cena i-putanja sa najniom cenom. Neka djy) bude cena najjeftinije putanje od
vora x do voray. Najnie cene vezane su slavnom Belman-Fordovom jednainom:
dx(y) = minw{ c(x,v) + dv(y)}, (4.1)
Izraz minv u jednaini predstavlja minimum svih direktno povezanih suseda vora x.
Belman-Fôrdova jednaina je intuitivno jasna. Zaista, ako nakon puta od x do v krenemo
putanjom sa najniom cenom od v do;', cena putanje bie c(x,v) + dv(y). Poto
putovanje moramo da ponemo prelaskom do nekog suseda v, najmanja cena od x do y,
izraunavae se kao zbir minimuma cena putanja c(x,v) + dv(y) za svakog suseda v.
Ali zbog onih koji moda sumnjaju u validnost ove jednaine, proverimo je za izvorni vor
u i odredini vor z sa slike 4.25. Izvorni vor u ima tri suseda: v, x i w. Ispitivanjem razliitih
putanja grafa, Iako je videti daje d ( z ) = 5, d ( z ) = 3 i d ( z ) = 3. Ako ove vrednosti
ubacimo u jednainu 4.1, uz cene c(u,v) = 2, c(u,x) ~ 1 i c(u,w) = 5 dobij amo
du(z) = min{2 + 5, 5 + 3, 1 + 3 } = 4, to je oigledno tano, a to je upravo rezultat koji za
ovu mreu daje i Dijkstrin algoritam. Ova brza provera trebalo bi da ukloni sve eventualne
sumnje.
Belman-Fordova jednaina nije samo intelektualni kuriozitet, Ona zaista ima znaajnu
praktinu vrednost. Konkretno, reenje Belman-Fordove jednaine obezbeduje stavke za tabelu
prosledivanja vora x. Da bismo to videli, neka v* bude susedni vor za koji je postignut
minimum u jednaini 4.1. Zatim, ako vor x eli da poalje paket voru y po najjeftinijoj putanji,
trebalo bi prvo da prosledi paket do vora v*. Prema tome, u tabeli prosledivanja vora x kao
ruter prvog skoka za krajnje odredite y bio bi naveden vor v*. Jo jedan znaajan praktian
doprinos Belman-Fordove jednaine jeste to to ona nagovetava oblik komunikacije meu
susedima do koje e doi u algoritmu DV.
Osnovna zamisao je sledea. Svaki vor poinje od Dx(y), procenjene cene najjeftinije
putanje od njega do voray, za sve vorove iz N. Neka Dx = [ D^ (y): y u N] bude vektor
rastojanja vora x, a to je vektor procenjenih trokova od x do svih ostalih vorova, y, iz N. U
algoritmu DV, svaki vor x odrava sledee podatke rutiranja:
Za svakog suseda v, cenu c (x,v) od .v do direktno povezanog suseda v.
Vektor rastojanja vorax, tj. Dx =[ Dx (y):y u N], koji sadri procenjene trokove do svih
odredita y, iz N.
Vektore rastojanja svih suseda, tj. = [ Dv (y): y u N] svih suseda v vora .v.
U distribuiranom asinhronom algoritmu, s vremena na vreme svaki vor alje svoj
aurirani vektor rastojanja svim svojim susedima. Kada vor* primi novi vektor rastojanja od
nekog svog suseda v, on memorie taj vektor rastojanja i zatim pomou Belman-Fordove
jednaine aurira vlastiti vektor rastojanja na sledei nain:

Dx (y) = minv{ c(x,v) + Dv(y)} za svaki vor y u N

Ako se vektor rastojanja vora x prilikom ovog auriranja promeni, vor x e zatim poslati
primerak svog vektora rastojanja svim svojim susedima koji zatim mogu da auriraju vlastite
vektore rastojanja. udesno je to da, ako svi vorovi stalno razmenjuju'svoje vektore rastojanja
na asinhroni nain, svi procenjeni trokovi Dx (y) tee iznosu dx (y), stvarnoj ceni najjeftinije
putanje od vora JCdo vora ;>[Bersekas 1992]!

4.5 . ALGORITMI RUTIRANJA

361 361 361 361
t
Algoritam sa vektorom rastojanja Na svakom
voru, x:

1 Initialization:
2 for ali destinations y in N:
3 Dx(y) = c (x,y) /* ako y nije sused, tada je c
4 (x,y) = - */
5 for each neighbor w
6 Dx (y) = for ali destinacions y in N
7 for each neighbor w
8 send distance vector Dx = [ Dx (y) : y in N] to w
9 loop
10 wait (until I see a link cost change to neighbor w
11 or until I receive a distance vector from neighbor w)
12
13 for each y in N:
14 Dx (y) - minv{ c(x,v) + Dv(y)} 15

16 if Dx (y) changed for any destination y
17 send'distance vector D DD Dx xx x = [ Dx (y) : y i n N] to ali neighbors 18
19 forever

U algoritmu DV (distance vector) vidimo da vor x aurira svoj vektor sa proce-nama
rastojanja kada primeti pramenu cene na nekom od svojih direktno povezanih linkova ili kada
od nekog suseda primi aurirani vektor rastojanja. Ali da bi vlastitu tabelu prosleivanja
aurirao za dato odredite y, voru x nije potrebno najkrae ra-stojanje do y ve susedni vor
v* (y) tj. ruter prvog skoka na najkraoj putanji do y. Kao to biste i oekivali, ruter prvog
skoka v*(y) je sused v koji ostvaruje minimum u 14. redu algoritma DV. (Ako vie suseda v
ostvaruje isti minimum, tada v* (y) moe da bude bilo koji od njih.) Prema tome, u redovima
13-14 za svako odredite^, vor.t takode utvruje v* (y) i aurira svoju tabelu prosleivanja za
odredite y.
Imajte na umu da je algoritam LS globalan u smislu da svaki vor mora prvo da pribavi
kompletnu mapu mree pre nego to primeni Dijkstrin algoritam. Algoritam DV je
decentralizovan i ne koristi takve globalne informacije. Zaista, jedine informacije u svakom
voru su cene linkova prema direktno povezanim susedima i informacije koje prima od tih
suseda. Svaki vor eka na auriranje od bilo kog suseda (redovi 16-17), izraunava nov vektor
rastojanja kada primi auriranje (red 14) i distribuira susedima svoj novi vektor rastojanja
(redovi 16-17). Algoritam DV se u praksi koristi u mnogim protokolima rutiranja ukljuujui
Internetove protokole RIP, i BGP, ISO IDRP, Novelov IPX i prvobitni ARPAnet.
Na slici 4.27 prikazanje rad algoritma DV za jednostavnu mreu od tri vora prikazanu na
vrhu slike. Rad algoritma prikazan je na sinhroni nain gde svi vorovi istovremeno dobiju
vektore rastojanja od svojih suseda, izraunavaju svoje nove vektore rastojanja i obavetavaju
svoje susede ako je dolo do promene vektora rastojanja. Poto prouite ovaj primer, trebalo bi
da uvidite da algoritam pravilno fun-kcionie i na asinhroni nain, gde se izraunavanja u
vorovima kao i pravljenje i primanje aurnih informacija dogaa u bilo kom trenutku.
U sasvim levoj koloni prikazane su tri poetne tabele rutiranja sva tri vora. Na primer,
tabela u gornjem levom uglu je poetna tabela rutiranja vora .t. Unutar odreene tabele
rutiranja, svaki red je jedan vektor rastojanja - konkretno, tabela rutiranja svakog vora sadri
njegov vlastiti vektor rastojanja i vektore rastojanja njegovih neposrednih suseda. Prema tome,
prvi red poetne tabele rutiranja vora x je Dx = [ D
x
(x), D
x
(y), D
x
(z)J = [0, 2, 7]. Drugi i trei
red ove tabele su poslednji primljeni vektori rastojanja od vorova y odnosno z. Poto u trenutku
inicijalizacije vor x nije jo nita primio od vorova y i z, stavke u drugom i treem redu imaju
poetnu vrednost beskonano.
Nakon inicijalizacije, svaki vor alje svoj vektor rastojanja svakom od svoja dva suseda.
Ovo je na slici 4.27 prikazano strelicama koje polaze iz prve kolone tabela prema drugoj koloni
tabela. Na primer, vor x alje svoj vektor rastojanja Dx = [0,2, 7] u oba vora y i z. Poto primi
auriranja, svaki vor ponovo izraunava vlastiti vektor rastojanja. Na primer, vor.v izraunava:
Dr(x) = 0
D
x
(y) = min{ c(x,y) + Dy(y), c(x,z) + Dp)}= min {2+0, 7+1} = 2 D( (z) =
min{ cfo;) + Dy(z), c(x,z) + D/z)}= min {2+1, 7+0} = 3
U drugoj koloni su, dakle, za svaki vor prikazani njegov vlastiti vektor rastojanja i vektori
rastojanja koji su upravo primljeni od suseda. Obratite, na primer, panju na to da vor x
procenjuje da se najjeftinija putanja do vora z, D
x
(z), promenila od 7 na 3. Takoe obratite
panju na to da za vorove y i z minimum predstavlja vor y. Prema tome, u ovoj fazi algoritma
ruteri prvog skoka su v*(y) =y i takoev*(z)=y.
Poto vorovi ponovo izraunaju vlastite vektore rastojanja, oni ponovo alju svoje
aurirane vektore rastojanja susedima (ukoliko je dolo do promene). Ovo je na slici 4.27
prikazano strelicama iz druge kolone tabela u treu. Primetiete da samo vorovi x i z alju
auriranja: vektor rastojanja vora y nije se promenio i zato on ne alje nita. Poto prime
auriranja, vorovi ponovo izraunavaju svoje vektore rastojanja i auriraju svoje tabele rutiranja
koje su prikazane u treoj koloni.
Postupak primanja novih cena od suseda, ponovnog izraunavanja stavki u tabeli rastojanja
i obavetavanja suseda o promenjenim cenama najjeftinije putanje do nekog odredita nastavlja
se sve dok ima poruka. U tom trenutku, poto se ne alju nikakve poruke sa novim vrednostima,
tabele rastojanja se vise nee preraunavati

362 362 362 362 POGLAVUE 4 - MRENI SLOJ
4.5 . ALGORITMI RUTIRANJA 363

i algoritam ulazi u stanje mirovanja; tj. svi vorovi izvravaju ekanje u redovima 10-11
algoritma DV. Algoritam ostaje u stanju mirovanja dok ne doe do promene cene nekog linka,
to emo sada opisati.

Algoritam vektora rastojanja: promene cena linkova i otkazivanje linkova
Kada vor koji izvrava algoritam DV otkrije promenu u ceni linka izmeu sebe i suseda (redovi
10-11), on aurira svoju tabelu rastojanja (redovi 13-14) i ako je dolo do promene cene
najjeftinije putanje, obavetava svoje susede (redovi 16-17). Na slici 4.28(a) prikazano je ovo
ponaanje u situaciji kada se cena linka od y prema x promenila od 4 na I. Ovde emo se
usredsrediti samo na stavke u tabelama rastojanja vorova y i z do odredita (reda) x. Algoritam
DV dovodi do sledeeg niza dogaaja:
U trenutku r0, y otkriva promenu u ceni linka (cena se promenila od 4 na 1), aurira svoj
vektor rastojanja i obavetava svoje susede o toj promeni poto se promenio vektor
rastojanja.
U trenutku z prima obavetenje od y i zatim aurira svoju tabelu. Poto izrauna novu
najniu cenu do x (smanjila se od 5 5 5 5 na 2), on alje svojim susedima novi vektor rastojanja.
TJ trenutku i2, y prima obavetenje od vora z i aurira svoju tabelu rastojanja. U voru y se
nisu promenlle najnie cene, pa zato y ne alje nikakvu poruku voru z. Algoritam dolazi u
stanje mirovanja.
Potrebne su, znai, samo dve iteracije algoritma DV da bi se dostiglo stanje mirovanja. Radosne
vesti o smanjenoj ceni izmeu x i y brzo su se propagirale kroz mreu.
Razmotrimo sada do ega moe doi ako cena linka porasle. Uzmimo da cena linka
izmeu x i y poraste od 4 na 60 kao to je prikazano na slici 4.28(b).
1. Pre promene cene linka imamo Dy(x) = 4, Dy(z) = 1, Dz(y) = 1 i Dy(x) = 5. U trenutku tQiy
otkriva promenu u ceni linka (cena se promenila od 4 na 60). Cvorjv izraunava da nova
najjeftinija putanja do JC iznosi

Dy (x) = min{ c(yj) + Dx(x), c(y,z) + D2(x)}= min {60+0, 1+5} = 6
Naravno, sa naim globalnim znanjem o mrei mi vidimo da ta nova cena prekoz nije
tana. Ali, vory jedino ima informaciju da direktna cena do* iznosi 60, a daje zadnje
obavetenje koje je y dobio od vora z glasilo da se do * moe stii za 5. Zato, da bi stigao
do x, y bi sada iao preko z smatrajui da se od z do * moe stii za 5. U trenutku /[ imamo
petlju rutiranja: da bi se stiglo do x, y rutira preko , a z rutira preko y. Petlja rutiranja je
kao crna rupa - paket sa odreditem JC koji u trenutku r, stigne do y ili z etae izmeu ta
dva vora zauvek (ili dok se njihove tabele prosledivanja ne promene).

i

4.5 . ALGORITMI RUTIRANJA
365 365 365 365
2. Kako je vor y izraunao novu minimalnu cenu prema x, on o tome obavetava z u trenutku
3. Nakon trenutka t{, z prima novi vektor rastojanja \zy sa novom najmanjom cenom iz vora y
do x, koja sada iznosi 6. z zna da moe stii u vory po ceni 1, pa tako izraunava da nova
najnia cena do x iznosi Dz (x) = min {50+0, 1+6} = 7. Kako se u voru z najnia cena do x
poveala, on o tome obavetava y u trenutku tv
4. Na slian nain, poto primi novi vektor rastojanja iz z, y tada utvruje da je Dy(x) = %, pa
alje svoj vektor rastojanja voru z. z zatim utvruje daje
Dz (x) = 9 i alje svoj vektor rastojanja voru.v itd.
Dokle e taj proces da traje? Trebalo bi da uvidite da e petlja imati 44 iteracije (razmena poruka
izmeu y i z) - sve dok z u jednom trenutku ne izrauna da je cena njegove putanje preko y vea
od 50. U tom trenutku, z e (konano!) utvrditi da njegova najjeftinija putanja do x ide preko
njegove direktne veze sa x. y e od tada putanje koje idu prema voru x rutirati preko vora z.
Videli smo da su loe vesti o poveanju cene linka zaista sporo putovale! ta bi se dogodilo da se
cena linka c(yj) promenila od 4 na 10.000, a daje cena c{zj) bila 9.999? Zbog takvih situacija se
problem koji smo sada videli ponekad naziva problemom brojanja do beskonanosti.
Algoritam sa vektorom rastojanja: dodavanje lanog rastojanja
Specifina situacija sa petljom koju smo upravo opisali moe da se izbegne pri-menom jedne
tehnike poznate kao lano rastojanje. Zamisao je jednostavna - ako z rutira preko y da bi se stiglo
do odredita x, tada e z obavestiti y da je njegovo rastojanje do x beskonano, tj. z e obavestiti y
da je Dt (x) = oo (iako z zna daje u stvari Dz (x) = 5). z e ostati pri toj maloj lai sve dok rutira
putanje prema odreditu x preko y. Kako y veruje da od z nema putanje prema x, y nee nikad
pokuati da rutira putanje ije je odredite x preko z, sve dok z nastavlja da rutira putanje prema x
preko y (i pretvara se da to ne radi).
Da pogledamo sada kako lano rastojanje reava konkretan problem petlje koji smo imali
na slici 4.28(b). Zahvaljujui lanom rastojanju, tabela rastojanja u voru y ukazuje daje D: (x) =
>. Kada se cena linka (x,y) promeni od 4 na 60 u trenutku t0, y aurira svoju tabelu i nastavlja
da rutira direktno prema x, iako je cena 60 vea, a obavetava z o toj novoj ceni prema x tj. Dy
{x) = 60. Poto primi to obavetenje u trenutku z odmah prebacuje rutu prema x direktno preko
linka (z,x) po ceni 50, Poto je ovo nova putanja sa najniom cenom prema x i poto putanja vie
ne prolazi preko y, z sada obavetava,y dajeDz(x) = 50 u trenutku t2. Poto primi obavetenje od
z, y aurira svoju tabelu rastojanja sa D(x) =51. Isto tako, poto se z sada nalazi na putanji
najnie cene od_y prema x,y blokira suprotnu putanju od z prema x tako to obavetava z u
trenutku t3d&}eDy(x) = oo (iako y zna daje u stvari D (x) = 51).
Da li lano rastojanje-reava problem brojanja do beskonanosti u optem sluaju? Ne.
Trebalo bi analizom da se uverite da petlje u kojima uestvuje tri ili vie vorova (a ne samo
dva neposredno susedna vora) ne mogu da se otkriju tehnikom lanog rastojanja.

Poreenje algoritama rutiranja sa stanjem linkova i sa vektorom rastojanja
Algoritmi DV i LS imaju komplementarne pristupe izraunavanju rutiranja. U algoritmu DV (sa
vektorom rastojanja) svaki vor razgovara jedino sa svojim direktno povezanim susedima, ali ih
snabdeva procenjenim najjeftinijim putanjama od njega do svih ostalih vorova u mrei (za koje
zna). U algoritmu LS (sa stanjem linkova), svaki vor razgovara sa svim ostalim vorovima
(putem difuznog emitovanja) ali im saoptava jedino cene do svojih direktno povezanih suseda.
Prouavanje algoritama sa stanjem linkova i sa vektorima rastojanja zakljuiemo jednim brzim
poreenjem nekih njihovih atributa.
Sloenost poruka. Videli smo daje za LS potrebno da svaki vor zna cenu svih linkova u
mrei. Da bi se to postiglo, potrebno je da se poalje 0(|N| jE|) poruka. Isto tako, kad god se
promeni cena nekog linka, nova cena mora da se poalje svim vorovima. Algoritam DV pri
svakoj iteraciji zahteva razmenu poruka meu direktno povezanim susedima. Videli smo da
vreme potrebno da se algoritam iscrpi zavisi od mnogo inilaca. Kada se promeni cena linka,
algoritam DV propagira rezultate te promene samo ako nova cena linka menja najniu cenu
putanje prema nekom od vorova vezanih za taj link.
Brzina izraunavanja. Videli smo da naa implementacija algoritma LS raste sa kvadratom
broja vorova i da je potrebno 0(|Nj |E|) poruka. Algoritam DV moe da se izraunava sporo
i moe da ima petlje rutiranja dok se algoritam ne zavri. U algoritmu DV takoe moe doi
do problema brojanja do beskonanosti.
Robusinost. Sta moe da se dogodi ako ruter otkae, pogreno se ponaa ili je napadnut? Ako
se koristi LS, ruter moe da emituje neispravnu cenu nekog od svojih povezanih linkova (ali
ne i drugih linkova). vor takode moe da oteti

366 366 366 366 POGLAVUE 4 MRENI SLOJ
4.5 ALGORITMI RUTIRANJA 367 367 367 367

ili ispusti neke LS pakete o stanju linkova koje je primio. Ali, LS vor izraunava samo
vlastite tabele prosledivanja; ostali vorovi vre slina izraunavanja sami za sebe. To znai
da su u sistemu LS izraunavanja ruta donekle razdvojena to im daje odreeni stepen
robustnosti. U sistemu DV, vor moe da objavi neispravne najjeftinije putanje do bilo kojeg
ili do svih odredita. (Zaista, 1997. godine pokvareni ruter u malom posredniku za Internet
usluge predao je ruterima dravne okosnice pogrene informacije o rutiranju. Zbog toga su
drugi ruteri preplavili neispravni ruter saobraajem i doveli do toga da veliki delovi Interneta
ak nekoliko sati ostanu nepovezani [Neumann 1997].) Uopteno govorei, pri-meujemo da
se u sistemu DV pri svakoj iteraciji izraunavanja koja je izvrio jedan vor predaju
njegovom susedu, a zatim u sledeoj iteraciji indirektno i susedu njegovog suseda. Na taj
nain, neispravan rezultat iz jednog vora moe u sistemu DV da se proiri kroz celu mreu.
Na kraju, nijedan od ovih algoritama nije bolji od drugog; zaista, u Internetu se koriste oba.

Ostali algoritmi rutiranja
Algoritmi LS i DV koje smo upravo obradili nisu samo u irokoj upotrebi, ve su n sutini jedini
algoritmi rutiranja koji se danas u praksi koriste. Ipak, tokom poslednjih 30 godina istraivai su
predlagali mnoge algoritme rutiranja, od krajnje jednostavnih do veoma sloenih i kompl i
kovanih. Jedna velika klasa algoritama rutiranja posmatra saobraaj paketa kao tokove izmeu
izvora i odredita u mrei. U takvom pristupu, problem rutiranja moe matematiki da se
formulie kao problem ograniene optimizacije poznat kao problem mrenog toka [Bertsekas
1991 ]. Pome-nuemo ovde jo jedan skup algoritama rutiranja koji potie iz sveta telefonije. Ovi
algoritmi rutiranja sa komutiranjem vodova vani su za umreavanje sa komutiranjem paketa u
sluajevima kada za svaku konekciju koja se rutira preko nekog linka treba rezervisati resurse na
tom linku (na primer, pomone memorije ili deo propusnog opsega linka). Dok formulacija
problema rutiranja moda izgleda sasvim razliita od formulacije rutiranja prema najnioj ceni
koju smo videli u ovom poglavlju, postoji niz slinosti bar u pogledu algoritma za pronalaenje
putanje (algoritma rutiranja). italac moe nai detaljan prikaz ovog podruja istraivanja u [Ash
1998; Ross 1995; Girard 1990].

4.5.3 Hijerarhijsko rutiranje
U prouavanju algoritama LS i DV posmatrali smo mreu jednostavno kao kolekciju meusobno
povezanih rutera. Ruteri se nisu meusobno razlikovali jer su svi izvravali isti algoritam
rutiranja za izraunavanje putanja rutiranja kroz celu mreu. U praksi je ovaj model i njegov
pojam homogenog skupa rutera koji svi izvravaju isti algoritam rutiranja previe uproen bar iz
dva znaajna razloga:
Skaliranje. Kako broj rutera raste, preoptereenje koje potie od izraunavanja, uvanja i
saoptavanja informacija o rutiranju (na primer, aurnog stanja linkova ili promena najniih
cena putanja) postaje preterano. Dananji javni Internet se sastoji od stotina miliona
raunara. Jasno je da bi za uvanje informacija o rutiranju prema svakom od njih bile
potrebne ogromne koliine memorije. Emitovanje aurnog stanja linkova svim ruterima u
javnom Internetu utroilo bi sav propusni opseg, pa nita ne bi ostalo za slanje paketa
podataka! Algoritam sa vektorom rastojanja koji bi iterirao preko tako velikog broja rutera
sigurno se nikada ne bi zavrio! Jasno je da treba neto uraditi da bi se smanjila sloenost
izraunavanja ruta u tako velikim mreama kakav je javni Internet.
Administrativna autonomija. Mada inenjeri esto zanemaruju elje kompanija da koriste
rutere po vlastitoj elji (na primer, da same biraju algoritme rutiranja), ili da kriju 'neke
aspekte interne organizacije svoje mree od spoljnog sveta, ovo su znaajna pitanja. Idealno
bi bilo da organizacija koristi i administrira svoju mreu kako sama hoe, a da ipak moe da
je povezuje sa ostalim spoljanjim mreama.
Oba ova problema mogu da se rese tako to se ruteri organizuju u autonomne sisteme (AS) i to
tako to je svaki autonomni sistem koji se sastoji od grupe rutera obino pod zajednikom
administrativnom kontrolom (npr. imaju istog posrednika za Internet usluge ili pripadaju istoj
organizaciji). Svi ruteri u jednom AS-u izvravaju isti algoritam rutiranja (na primer, algoritam
LS ili DV) i imaju informacije jedni o drugima - tano kao u naem idealizovanom modelu iz
prethodnog odeljka. Algoritam rutiranja koji se izvrava unutar autonomnog sistema nazivamo
unutranji protokol rutiranja autonomnog sistema. Bie naravno potrebno povezati AS-ove
meusobno, pa e jedan ili vie rutera u AS-u imati dodatni zadatak da prosleuje pakete na
odredita van AS-a; ti ruteri se nazivaju ruterima mrenog prolaza.
Na slici 4,29 prikazan je jednostavan primer sa tri autonomna sistema - AS1, AS2 i AS3.
Na ovoj slici, deblje linije predstavljaju direktne linkove izmeu parova rutera. Tanje linije koje
se sputaju od rutera predstavljaju podmree direktno povezane sa ruterima. AS1 ima etiri
rutera - la, lb, Ic i Id - koji izvravaju unutranji protokol rutiranja autonomnog sistema AS1.
Prema tome, svaki od ova etiri rutera zna kako da rutira pakete po optimalnoj putanji do
svakog odredita u autonomnom sistemu AS1. Slino tome, autonomni sistemi AS2 i AS3 imaju
svaki po tri rutera. Obratite panju na to da protokoli rutiranja unutar AS-ova koji se izvravaju
u sistemima AS1, AS2 i AS3 ne moraju biti isti. Obratite takoe panju na to da su ruteri lb, lc,
2a i 3a ruteri mrenog prolaza,
Sada bi trebalo da je jasno kako ruteri u AS-ovima utvruju putanje rutiranja za parove
izvor-odredite unutar aulonomnog sistema. Ali jo uvek nedostaje jedan veliki deo misterije
rutiranja sa kraja na kraj. Kako e ruter unutar jednog AS-a znati kako da rutira paket na
odredite izvan tog AS-a? Problem nije teak ako AS ima samo jedan mreni prolaz koji se
povezuje sa samo jednim drugim AS-om. U tom sluaju, postoje unutranji algoritam rutiranja
utvrdio najjeftiniju putanju od svakog

4.5 . ALGORITMI RUTIRANJA 369 369 369 369

unutranjeg rutera do mrenog prolaza, svaki unutranji ruter zna kako da prosledi paket. Kada primi
paket, ruter mrenog prolaza prosleduje paket na onaj link koji vodi iz autonomnog sistema.
Autonomni sistem na suprotnoj strani tog linka zatim preuzima odgovornost za rutiranje paketa
prema njegovom konanom odreditu, Kao primer, pretpostavite da ruter 2b sa slike 4.29 primi paket
ije se odredite nalazi izvan sistema AS2, Ruter 2b e tada proslediti paket bilo ruteru 2a ili ruteru
2c, to zavisi od tabele prosleivanja u ruteru 2b koja je konfigurisana unutranjim protokolom
rutiranja autonomnog sistema AS2. Paket e na kraju stii do rutera mrenog prolaza 2a, koji e
proslediti paket ruteru lb. Poto paket napusti ruter 2a, autonomni sistem AS2 vie nema nita sa
ovim paketom.
Znai pitanje nije teko ako izvorni AS ima samo jedan link koji vodi van AS-a. Ali ta ako izvorni
AS ima dva ili vie linkova (kroz jedan ili vie mrenih prolaza) koji vode van AS-a? Tada je mnogo
tee utvrditi gde treba da se prosledi paket. Na primer, razmotrite ruter iz sistema AS 1 i
pretpostavite da on primi paket ije se odredite nalazi izvan AS-a. Jasno je da ruter treba da
prosledi paket nekom od dva mrena prolaza, lb ili lc, ali kojem? Da bi se resio ovaj problem, AS 1
mora da (1) sazna koja su odredita dostupna putem autonomnog sistema AS2 a koja putem
sistema AS3 t (2) da propagira te informacije o dostupnosti svim ruterima u AS1 da bi svaki ruter
konfigurisao svoju tabelu prosleivanja i pravilno tretirao odredita van AS-a. Ova dva zadatka -
pribavljanje informacija o dostupnosti od susednih AS-ova i propagiranje informacija o dostupnosti
svim ruterima unutar AS-a - obavlja protokol ruti-
ranja meu autonomnim sistemima. Poto protokol rutiranja meu autonomnim sistemima
ukljuuje komunikaciju izmeu dva autonomna sistema, ta dva autonomna sistema moraju da
izvravaju isti protokol rutiranja meu autonomnim sistemima. U stvari, na Internetu svi AS-ovi
izvravaju isti protokol rutiranja medu autonomnim sistemima, po imenu BGP4, koji opisujemo u
sledeem odeljku. Kao to se vidi na slici 4.29, svaki ruter prima informacije od jednog unutranjeg
protokola rutiranja autonomnog sistema i jednog protokola rutiranja meu autonomnim sistemima i
konfigurie svoju tabelu prosleivanja pomou informacija iz oba ta protokola.
Uzmimo kao primer jednu podmreu x (sa odreenom CIDR adresom) i uzmimo da AS1 sazna
od protokola rutiranja meu autonomnim sistemima daje podmreax dostupna iz sistema AS3 ali da
nije dostupna iz sistema AS2. AS1 zatim propagira ovu informaciju svim svojim ruterima. Kada ruter
ld sazna daje mreax dostupna iz sistema AS3, pa prema tome preko mrenog prolaza Ic, on tada iz
informacija do-bijenih od unutranjeg protokola rutiranja odreuje ruterski interfejs na najjeftinijoj
putanji iz rutera ld do rutera mrenog prolaza lc. Recimo da je. to interfejs I. Ruter ld moe u svoju
tabelu prosleivanja da doda stavku (x, I). (Ovaj primer, kao i ostali iz ovog Odeljka, imaju za cilj da
objasne glavne principe ali uproeno prikazuju ono to se zaista dogaa na Internetu. U sledeem
odeljku daemo detaljniji, mada sloeniji, opis protokola BGP.)
Naovezujui se na prethodni primer, pretpostavimo sada daseAS2 iAS3 povezuju sa drugim
AS-ovima koji nisu prikazani na slici. Pretpostavimo takode da AS I sazna od protokola rutiranja
meu autonomnim sistemima da je podmrea x dostupna i iz sistema AS2 preko mrenog prolaza 1
b i iz sistema AS3 preko mrenog prolaza lc. ASI bi zatim propagirao ovu informaciju svim svojim
ruterima ukljuujui i ld. Da bi konfigurisao svoju tabelu prosleivanja, ruter ld bi trebalo da odredi u
koji ruter mrenog prolaza (lb ili lc) treba da usmeri pakete sa odreditem u x. Jedan pristup, koji se
esto koristi u praksi, je da se primeni rutiranje vrueg krompira. U rutiranju vrueg krompira ruter
pokuava da se oslobodi paketa (vrueg krompira) to pre moe (tanije, to jeftinije). To se postie
slanjem paketa onom ruteru mrenog prolaza koji od svih mrenih prolaza koji imaju putanju prema
odreditu imaju najniu cenu od rutera do mrenog prolaza. U kontekstu trenutnog primera, rutiranje
vrueg krompira koje bi se izvravalo u prolazu ld bi na osnovu informacija dobije-nih od unutranjeg
protokola rutiranja utvrdio cene putanja do lb i lc i zatim izabrao jeftiniju od te dve putanje. Poto se
izabere putanja, ruter ld dodaje stavku za podmreu x u tabelu prosleivanja. Na slici 4.30 prikazana
je rekapitulacija aktivnosti u ruteru ld potrebnih za dodavanje nove stavke za x u tabelu
prosleivanja.
Kada AS sazna od susednog AS-a za neko odredite, on moe da oglasi tu informaciju za
rutiranje nekim od svojih ostalih susednih AS-ova. Na primer, pretpostavimo da AS 1 sazna od
sistema AS2 da je podmrea x dostupna preko sistema AS2. AS 1 bi mogao da obavesti AS3 da je
x dostupna preko sistema AS I. Na ovaj nain, ako AS3 treba da rutira paket sa odreditem u x, AS3
bi prosledio paket u ASI, koji bi zatim prosledio paket u AS2. Kao to emo videti u opisu BGP-a, AS
prilino fle-

4.6 RUTIRANJE NA INTERNETU 197

ksibilno odluuje o tome da li da obavesti susedne AS-ove o nekom odreditu. To su odluke politike,
koje zavise vie od ekonomskih nego od tehnikih argumenata.
Iz odeljka 1.5 se moda seate da se Internet sastoji od hijerarhije meusobno povezanih
posrednika za Internet usluge. Kakav je dakle odnos posrednika i AS-a? Mogli biste pomisliti da
ruteri jednog posrednika i linkovi koji ih povezuju ine jedan AS. Mada je esto tako, mnogi
posrednici dele svoju mreu na vie AS-ova. Na primer, neki posrednici prvog reda koriste jedan AS
za celu svoju mreu dok je drugi dele desetine meusobno povezanih AS-ova.
Sve u svemu, problemi skaliranja i administrativne kontrole reavaju se definisa-njem
autonomnih sistema. Unutar autonomnog sistema svi ruteri izvravaju isti unutranji protokol
rutiranja. Autonomni sistemi meu sobom izvravaju isti protokol rutiranja meu autonomnim
sistemima. Problem skaliranja je reen poto unutranji protokol rutiranja treba da zna samo za
rutere u svom autonomnom sistemu. Problem administrativne kontrole je reen poto svaka
organizacija moe da izvrava unutranji protokol koji god hoe; meutim, svaki par povezanih
AS-ova mora da izvrava isti protokol rutiranja meu autonomnim sistemima kako bi mogli da
razmenjuju informacije o dostupnosti.
U sledeem odeljku ispitaemo dva unutranja protokola rutiranja (RIP i OSPF) ijedan protokol
rutiranja meu autonomnim sistemima (BGP) koji se koriste u dananjem Internetu. Ovi primeri e
lepo. upotpuniti naa razmatranje hijerarhijskog rutiranja.

4.6 Rutiranj e na Internetu
Poto smo prouili internetsko adresiranje i protokol IP, sada emo se posvetiti Internetovim
protokolima rutiranja; njihov zadatak je da utvrde putanju kojom e datagram stii od izvora do
odredita. Videemo da Internetovi protokoli rutiranja primenjuju mnoge principe koje smo prouili
ranije u ovom poglavlju. Za nain rutiranja na dananjem Internetu kljuni su algoritmi stanja linkova i
vektora rastojanja koje smo prouili u odeljcima 4.5.1 i 4.5.2 i pojam autonomnih sistema (AS) koji
smo razmatrali u odeljku 4.5.3.
Verovatno se seate iz odeljka 4.5.3 da se kolekcija rutera pod istom administrativnom i
tehnikom kontrolom i koja koristi isti zajedniki protokol rutiranja naziva autonomnim sistemom
(AS). Svaki AS, zatim, obino sadri vie podmrea (ovde koristimo izraz podmrea u preciznom
adresnom smislu iz odeljka 4.4.2).

4.6.1 Unutranji protokoli rutiranja autonomnih sistema na Internetu:
RIP
Unutranji protokol rutiranja AS-a slui da bi se odredilo kako se vri rutiranje unutar tog
autonomnog sistema. Unutranji protokoli rutiranja AS-a poznati su i kao unutranji protokoli mrenih
prolaza. Na Internetu su za rutiranje unutar autonomnih sistema bila u irokoj upotrebi dva
protokola rutiranja: najpre RIP (Routing Information Protokol) i zatim OSPF (Open Shortest Path
First). Protokol rutiranja blisko povezan sa OSPF-om je protokol IS-IS [RFC 1142, Periman 1999].
Prvo opisujemo RIP a zatim OSPF.
RIP je bio jedan od prvih unutranjih protokola rutiranja AS-a na Internetu i danas je jo uvek u
irokoj upotrebi. Njegovi koreni i ime potiu iz arhitekture XNS (Xerox Nenvork Svstems). RIP je
toliko rasprostranjen pre svega zato stoje bio ukljuen u verziju UNIX-a koji je podravao TCP/IP i
koji je distribuiran u paketu BSD (Berkeley Sopvare Distribution) 1982. godine. Prva verzija RlP-a
definisana je u dokumentu RFC 1058, a druga verzija, kompatibilna unazad, definisana je u doku-
mentu RFC 2453.
RIP je protokol vektora rastojanja koji funkcionie veoma slino idealizovanom protokolu koji
smo opisali u odeljku 4.5.2. Verzija RlP-a opisana u dokumentu RFC 1058 odreuje cene prema
broju skokova; tj. svaki link ima cenu 1. U algoritmu DV u odeljku 4.5.2 smo zbog jednostavnosti
navodili cene izmeu parova rutera. U RIP-u (a takoe i u OSPF-u) cene se navode od izvornog
rutera do neke odredine podmree. RIP koristi izraz skok to je u stvari broj podmrea kroz koje se
prolazi du najkrae putanje od izvornog rutera do odredine podmree, ukljuujui odredinu
podmreu. Na slici 4.31 prikazan je AS sa est podmrea grana. Tabela na stici prikazuje broj
skokova od izvora A do svih podmrea grana.
Maksimalna cena putanje ograniena je na 15, pa se zato RIP ograniava na autonomne
sisteme sa manje od 15 skokova u preniku. Verovatno se seate da kod protokola vektora
rastojanja, susedni ruteri meusobno razmenjuju informacije o rutiranju. Vektor rastojanja u svakom
ruteru sadri trenutno procenjena najmanja rastojanja od tog rutera do podmrea u AS-u. U RIP-u,
aurne podatke o rutiranju susedi razmenjuju priblino svakih 30 sekundi u takozvanim porukama
RIP odgovora. Poruka odgovora koju alje ruter ili raunar sadri spisak od najvie 25 odredinih
podmrea unutar AS-a kao i udaljenost poiljaoca do svake od tih podmrea. Poruke odgovora
nazivaju se takoe i RIP objave.
Pogledajmo jedan jednostavan primer gde emo videti kako funkcioniu RIP objave.
Razmotrite deo AS-a prikazan na slici 4.32. Na ovoj slici linije koje povezuju rutere predstavljaju
podmree. Radi bolje preglednosti oznaeni su samo izabrani

4.6 RUTIRANJE NA INTERNETU 198 198 198 198

ruteri (A, B, C i D) i podmree (w, x, y i z). Isprekidane linije ukazuju na to da se AS produava
i da u njemu ima mnogo vie rutera i linkova nego stoje prikazano,
Svaki ruter odrava RIP tabelu koja se naziva tabela rutiranja. Tabela rutiranja jednog rutera
sadri njegov vektor rastojanja i njegovu tabelu prosleivanja. Na slici 4.33 prikazana je tabela
rutiranja u ruteru D. Obratite panju na to da tabela rutiranja ima tri kolone. Prva kolona je za
odredinu podmreu, druga kolona sadri sfedei ruter na najkraoj putanji prema odredinoj mrei,
a u treoj se nalazi broj skokova (tj. broj podmrea koje treba prei, ukljuujui odredinu
podmreu) da bi se najkraim putem stiglo u odredinu podmreu. U ovom primeru tabela pokazuje
da za slanje datagrama iz rutera D u odredinu podmreu w, datagram treba prvo proslediti
susednom ruteru A; tabela takoe pokazuje da do odredine podmree w po najkraoj putanji treba
dva skoka. Slino tome, tabela pokazuje daje podmrea z udaljena sedam skokova i to preko rutera
B. U principu, tabela rutiranja ima po jedan red za svaku podmreu unutar AS-a, mada RIP verzije 2
dozvoljava agregaciju ruta prema podmreama pomou tehnika agregacije kakve smo ispitali u
odeljku 4.4. Tabela na slici 4.33 i sledee tabele su zbog toga samo delimino popunjene.
Pretpostavimo sada da nakon 30 sekundi ruter D primi od rutera A objavu prikazanu na slici
4.34. Obratite panju na to da ova objava sadri samo informacije iz tabele rutiranja rutera ,4! Ova
informacija kazuje, konkretno, daje podmrea z udaljena samo 4 skoka od rutera A. Kada ruter D
primi ovu objavu, on kombi-nuje objavu (slika 4.34) sa starom tabelom rutiranja (slika 4.33).
Konkretno, ruter D saznaje da do podmree z sada postoji putanja preko rutera A kraa od putanje
preko rutera B. Prema tome, ruter D aurira svoju tabelu rutiranja i ukljuuje krau najkrau putanju,
kao to je prikazano na slici 4.35. Moda se pitate kako to daje najkraa putanja do podmree.z
postala kraa? Moda se decentralizovani algoritam vektora rastojanja tek izraunavao (videti
odeljak 4.5.2) ili su moda u AS dodati novi linkovi i/ili ruteri pa su se tako promenile najkrae
putanje u AS-u.
Pogledajmo zatim nekoliko aspekata u implementaciji RlP-a. Sigurno se seate da RIP ruteri
razmenjuju objave priblino svakih 30 sekundi. Ako ruter nema vesti od svog suseda bar svakih 180
sekundi, smatrae da taj sused vie nije dostupan; ili je sused otkazao ili se prekinuo link koji ih
povezuje. U tom sluaju, RJP menja lokalnu tabelu rutiranja i zatim propagira tu informaciju tako to
alje objave svojim suse-dnim ruterima (onima koji su jo uvek dostupni). Ruter moe takoe od svog
suseda

199 POGLAVLJE 4 MRENI SLOJ 4.6 RUTIRANJE NA INTERNETU 375

da zahteva informaciju o ceni do datog odredita pomou poruke RIP zahteva. Ruteri alju jedni
drugima poruke RIP zahteva i RIP odgovora preko UDP-a i pri tom koriste broj porta 520. UDP
paket se izmeu rutera prenosi u standardnom IP datagramu. injenica da RIP koristi protokol
transportnog sloja (UDP) preko protokola mrenog sloja (IP) da bi implementirao funkciju mrenog
sloja (algoritam rutiranja) moe da izgleda prilino uvrnuto (i jeste!), Kada malo detaljnije razmotrimo
nain na koji se RIP implementira bie i ovo jasnije.
Na slici 4.36 data je skica uobiajenog implementiranja RlP-a u UNIX sistemu, na primer, u
UNIX radnoj stanici koja slui kao ruter. Proces po imenu routed (koji se izgovara ,,rut di") izvrava
protokol RIP, tj. odrava informacije o rutiranju i razme-njuje poruke sa routed procesima koji se
izvravaju u susednim ruterima. Poto je RIP implementiran kao proces aplikacijskog sloja (iako
veoma poseban proces koji moe da manipulie tabelama rutiranja u UNIX-ovom kemelu), on moe
da alje i prima poruke preko standardnog soketa i koristi standardni transportni protokol. Prema
tome, RIP je implementiran kao protokol aplikacijskog sloja (proitati poglavlje 2) koji se izvrava
preko UDP-a.

4.6.2 Unutranji protokoli rutiranja autonomnih sistema na Internetu:
OSPF
Kao i RIP, OSPF (otvorena prvo najkraa putanja) rutiranje se koristi unutar AS-ova. OSPF i njegov
blizak srodnik IS-IS obino se uvodi kod posrednika Internet usluga vieg reda dok se RIP uvodi kod
posrednika nieg reda i u mreama preduzea, Otvorena" u skraenici OSPF znai da je
specifikacija protokola rutiranja javno dostupna (za razliku, na primer, od Ciscovog protokola
EIGRP). Najnovija verzija OSPF-a, verzija 2 definisana je u javnom dokumentu RFC 2328.
OSPF je zamiljen kao naslednik RlP-a, pa kao takav ima niz naprednih svojstava. U sutini,
meutim, OSPF je protokol sa stanjem linkova koji koristi priliv in-
formacija o stanju linkova i jedan Dijkstrin algoritam za najjeftiniju putanju. Kada se koristi OSPF,
ruter izgrauje kompletnu topoloku mapu (tj. orijentisani graf) celog autonomnog sistema. Ruter
zatim lokalno izvrava Dijkstrin algoritam za najkrau putanju kako bi utvrdio stablo najkraih putanja
prema svim podmreama i pri tom sebe postavlja za osnovni vor. Mreni administrator konfigurie
cene pojedinanih linkova (proitajte Principe u praksi: Podeavanje pondera OSPF linkova). Admi-
nistrator moe svim linkovima da stavi cenu 1, ime postie rutiranje prema minimalnom broju
skokova a moe i da ponderie linkove tako da im cene budu obrnuto srazmeme kapacitetu da bi
podstakao saobraaj na linkovima sa veim propusnim opsegom. OSPF ne propisuje politiku za
ponderisanje linkova (to je zadatak mrenog administratora), ve umesto toga obezbeduje
mehanizme (protokol) kojim se utvruje rutiranje najjeftinijih putanja na osnovu datih pondera za
linkove.
Kada se koristi OSPF, ruter difuzno emituje informacije o rutiranju svim ostalim ruterima u
autonomnom sistemu, a ne samo svojim susednim ruterima. Ruter difuzno emituje informacije o
stanju linkova kad god doe do promene stanja nekog linka (na primer, do promene cene ili
promene statusa ukljuenja/iskljuenja). On takode povremeno difuzno emituje stanje linkova
(najmanje svakih 30 minuta), ak i kad nema promena u stanju linkova. RFC 2328 napominje da
povremeno auriranje objava stanja linkova poveava robustnost ovog algoritma". OSPF objave
stavljaju se u OSPF poruke koje direktno prenosi IP sa protokolom gornjeg sloja 89, za OSPF.
Prema tome, protokol OSPF mora sam da implementira funkcije kao to su pouzdani transfer
poruka i difuzno emitovanje stanja linkova. Protokol OSPF takoe provera-va da li linkovi
funkcioniu (pomou poruke HELLO koja se alje povezanom suse-du) i omoguava OSPF ruteru
da preko svog susednog rutera pribavi bazu podataka o stanju linkova u celoj mrei.
-?-

4.6 RUTIRANJE NA INTERNETU 377 377 377 377

Evo nekoliko unapreenja koje donosi OSPF:
Bezbednost. Proverava se autentinost kompletne razmene izmeu OSPF rutera (na primer,
auriranje stanja linkova). To znai da u OSPF protokolu unutar domena mogu da uestvuju
samo ruteri od poverenja, ime se spreava da zlo-namemi uljezi (ili studenti umreavanja
koji svoje novosteeno znanje koriste za ale) ubace netane informacije u ruterske tabele.
OSPF paketi meu ruterima se podrazumevano ne proveravaju pa bi moglo doi do
falsifikovanja. Mogue je konfigurisati dve vrste bezbednosti - jednostavnu ili MD5 (u
poglavlju 8 moete nai opti opis provere autentinosti i posebno MD5). Ako se koristi
jednostavna provera autentinosti u sve rutere se konfigurie ista lozinka. Kada ruter poalje
OSPF paket, on ukljuuje lozinku kao isti tekst. Jasno je da jednostavna provera
autentinosti nije bezbedna. Provera autentinosti MD5 zasniva se na zajednikim tajnim
kljuevima koji se konfiguriu u sve rutere. Svaki ruter izraunava MD5 he za svaki OSPF
paket na osnovu sadraja paketa i konfigurisanog tajnog kljua. Dobijenu vrednost hea
ukljuuje u OSPF paket. Prijemni ruter e pomou unapred konfigurisanog kljua izraunati
MD5 he primljenog paketa i uporediti dobijeni rezultat sa he vrednou iz paketa, ime
proverava autentinost paketa. Kao zatita od napada ponavljanjem koriste se i redni brojevi u
MD5 proveri autentinosti.
Vie putanja sa istom cenom. Kada do jednog odredita vie putanja ima istu cenu, OSPF
dozvoljava da se i koristi vie putanja (tj. ako postoji vie putanja sa istom cenom, ne mora se
za sav saobraaj birati ista putanja).
Integrisana podrka za jednoznano i vieznano rutiranje. Vieznani OSPF [RFC 1584]
sadri jednostavna proirenja za OSPF koja omoguavaju vieznano rutiranje (ova tema je
detaljnije obraena u odeljku 4.7.2). Vieznani OSPF (Multicast OSPF, MOSPF) koristi
postojeu OSPF bazu podataka o linkovima i dodaje jednu novu vrstu objave stanja linkova u
postojei mehanizam za difuzno emitovanje stanja linkova.
Podrka za hijerarhiju unutar istog domena rutiranja. Moda je najznaajniji napredak u
OSPF-u mogunost da se autonomni sistem strukturie hijerarhijski. U odeljku 4.5.3 ve smo
uvideli mnoge prednosti hijerarhijskih struktura za rutiranje. U ostatku ovog odeljka
obradiemo implementaciju OSPF hijerarhijskog rutiranja.
OSPF autonomni sistem moe se konfigurisati u podruja. Svako podruje izvrava vlastiti
OSPF algoritam rutiranja prema stanju linkova, tako to svaki ruter u podruju difuzno emituje
svoje stanje linkova svim ostalim ruterima u tom podruju. Unutranji detalji podruja tako
ostaju nevidljivi za sve rutere izvan podruja. Rutiranje unutar podruja ukljuuje samo rutere iz
istog podruja.
U svakom podruju je jedan rubni ruter podruja ili vie njih zadueno za rutiranje paketa
van podruja. Tano jedno OSPF podruje u autonomnom sistemu konfigurie se kao podruje
okosnice. Prvenstvena uloga podruja okosnice je da rutira saobraaj izmeu ostalih podruja u
autonomnom sistemu. Okosnica uvek sadri
sve rubne rutere podruja u autonomnom sistemu, a moe da sadri i rutere koii nisu rubni.
Rutiranje meu podrujima unutar autonomnog sistema zahteva da se paket prvo rutira rubnom
ruteru podruja (rutiranje unutar podruja), zatim kroz okosnicu do rubnog rutera podruja koji
se nalazi u odredinom podruju, a tek nakon toga do konanog odredita.
Na slici 4.35 dat je dijagram hijerarhijski strukturisane OSPF mree. Na ovoj slici vidimo
etiri vrste OSPF rutera.
Unutranji ruteri. Ovi ruteri su u podrujima koja ne spadaju u okosnicu i izvravaju samo
rutiranje unutar autonomnog sistema.
Rubni ruteri podruja. Ovi ruteri pripadaju i podruju i okosnici.
Ruteri okosnice {ruteri koji nisu }-ubni). Ovi ruteri vre rutiranje unutar okosnice, ali
sami'nisu rubni ruteri podruja. Unutranji ruteri saznaju da postoje rute prema drugim
podrujima van okosnice na osnovu informacija (u sutini objave o stanju linka koja,
meutim, objavljuje cenu rute prema drugom podruju, a ne cenu linka) difuzno emitovanih
unutar podruja iz njegovih rutera okosnice.
Granini ruteri. Granini ruter razmenjuje informacije o rutiranju sa ruterima koji pripadaju
drugim autonomnim sistemima. Taj ruter moe, na primer, da koristi BGP za rutiranje medu
AS-ovima. Kroz takav granini ruter ostali ruteri saznaju za putanje prema spoljnim
mreama.
OSPF je relativno sloen protokol i na je opis morao da bude skraen; dodatne detalje
moete nai u knjigama [Huitema 1998; Moy 1998; RFC 2328].

4.6 . RUTIRANJE NA INTERNETU 379 379 379 379

PRINCIPI U PRAKSI
PODE PODE PODE PODEAVANJE PONDERA OSPF LINKOVA AVANJE PONDERA OSPF LINKOVA AVANJE PONDERA OSPF LINKOVA AVANJE PONDERA OSPF LINKOVA
Nos opis rulironjo prema slanju linkova polazio je od pretpostavke do su ponderi linkova odreeni,
da se izvrava algorilam ruliranja kao to je OSPF i da saobraaj tee u skladu sa tabelama rutiranja
koje je izraunao algoritam LS. U smislu uzroka i posledice, ponderi linkova su doti (tj. oni su prvi), a
iz njih proizlaze (pomou Dijkstrinog algoritmo) putanje rutiranja premo najniim cenama. Iz te
perspektive, ponder linka reflektuje cenu koju treba platiti za korienje linka {npr. ako su ponderi
linkova obratno proporcionalni kapacitetu, tado bi korienje linkova sa velikim kapacitetom imalo
nii ponder pa bi bilo privlani je to se tie rutiranja) a Dijkstrin algoritam slui za pronalaenje to
nie ukupne cene.
U praksi su uzrono posledini odnosi izmeu pondera linkova i putanja rutiranja ponekad
obrnuti, jer mreni operateri konfigurisu pondere linkova da bi se dobile putanje rutiranjo koje e
ostvariti odreene ciljeve saobraajnih inenjera [Forlz 2000, Fortz 2002], Na primer, pretpostavite
da mreni operater procenu toka saobraaja koji ulazi u mreu na svakoj ulaznoj toki sa odreditem
na drugoj izlaznoj taki. Operater bi mogao da uredi specifino rutiranje tokova od ulaza ka izlazu
lako da maksimalno optereenje svih iinkovo u mrei bude to manje. Ali sa algoritmom rutiranja
kakav je OSPF, ponderi linkova predstavljaju glavne operaterove ruice" za usmeravanje tokova
kroz mreu. Prema tome, da bi postigao svoj cilj da maksimalno optereenje svih linkova u mrei
bude to manje, opeialer mora do pronae skup pondera zo linkove koji e laj cilj i ostvariti. Ovo je
suprotan uzrono posledini odnos - poznalo je eljeno rutiranje tokova a treba pronai takve
pondere OSPF linkova do OSPF algoritam rutiranja proizvede eljeno rutiranje tokova.
4.6.3 Rutiranje meu autonomnim sistemima: BGP
Upravo smo nauili kako posrednici za Internet usluge koriste RIP i OSPF za utvrivanje
optimalnih putanja za parove izvor - odredite unutar istog AS-a. Razmotrimo sada kako se
utvruju optimalne putanje za parove izvor - odredite iz razliitih AS-ova. Protokol BGP
(Border Gateway Protocol) verzija 4, definisan u RFC-u 1771 (videli takoe [RFC 1772; RFC
1773]), je u dananjem Internetu defacto standardni protokol za rutiranje medu domenima,
odnosno meu autonomnim sistemima. Obino se pominje kao BGP4 ili jednostavno kao BGP.
Kao protokol rutiranja meu autonomnim sistemima (videti odeljak 4.5.3), BGP svakom AS-u
omoguava da:
1. pribavi od susednih AS-ova informacije o dostupnosti podmrea;
2. propagira informacije o dostupnosti svim ruterima unutar AS-a;
3. odredi dobre" rute do podmrea na osnovu informacija o dostupnosti i politike AS-a.
Pogotovo, BGP omoguava svakoj podmrei da oglasi svoje postojania svima na Internetu.
Podmrea vie Ja postojim, ja sam ovde", a BGP e se pobrinuti da svaki AS na Internetu
sazna za tu podmreu i kako se do nje stie. Da nema BGP-a, svaka podmrea bi ostala
izolovana - sama i nepoznata ostalima na Internetu.

Osnove BGP-a
BGP je izuzetno sloen; cele knjige su posveene toj temi. tavie, ak poto se proitaju te
knjige i RFC-iji teko je potpuno ovladati BGP-om pre nego to se mese-cima (ako ne
godinama) praktino koristi BGP u ulozi projektanta ili administratora kod posrednika Internet
usluga vieg reda. I pored toga, poto je BGP apsolutno sutinski protokol na Internetu - to je
upravo protokol koji dri celu stvar na okupu - moramo da nauimo bar osnove njegovog
funkcionisanja. Na poetku opisujemo kako bi BGP mogao da radi u kontekstu primera
jednostavne mree sa slike 4.29. Ovim opisom nadovezujemo se na obradu hijerarhijskog
rutiranja iz odeljka 4.5.3; bilo bi dobro da ga ponovo proitate.
Kada se koristi BGP, parovi rutera razmenjuju informacije o rutiranju putem polutrajnih
TCP konekcija na portu 1 11 179. Polutrajne TCP konekcije za mreu sa slike 4.29 prikazane su na
slici 4.38. Obino postoji po jedna takva BGP TCP konekcija za svaki link koji direktno
povezuje dva rutera iz razliitih AS-ova; prema tome, na slicj 4.38 imamo jednu TCP konekciju
izmeu nitera mrenih prolaza 3a i lc i drugu TCP konekciju izmeu rutera mrenih prolaza lb i
2a. Postoje takoe polutrajne BGP TCP konekcije izmeu rutera unutar administrativnog
sistema. Konkretno, na slici 4.38 prikazana je uobiajena konfiguracija jedne TCP konekcije za
svaki par rutera unutar AS-a tako da imamo preplet TCP konekcija u svakom AS-u. Za svaku
TCP konekciju dva rutera na krajevima konekcije nazivamo BGP ravnopravnim uesnikom, a
TCP konekcija sa svim BGP porukama koje se alju po njoj je BGP sesija. Osim toga, BGP
sesija koja povezuje dva AS-a naziva se eksternom BGP (e-BGP) sesijom, a BGP sesija
izmeu rutera iz istog AS-a naziva se internom BGP (iBGP) sesijom. Na slici 4.38 eBGPsesije
su prikazane duim crticama; iBGP sesije su prikazane kraim crticama. Obratite panju na to
da linije BGP sesija na slici 4.38 ne odgovaraju uvek fizikim linkovima na slici 4.29.
BGP dozvoljava da svaki AS sazna koja su odredita dostupna preko njegovih susednih
AS-ova. Kada se koristi BGP, odredita nisu raunari ve CIDR prefiksi, gde svaki prefiks
predstavlja podmreu ili kolekciju podmrea. Tako, na primer, pretpostavimo da su za AS2
vezane etiri podmree: 138.16.64/24, 138,16.65/24, 138.16.66/24 i 138.16.67/24. AS2 bi tada
mogao da sakupi prefikse te etiri podmree i upotrebi BGP za objavu jedinstvenog prefiksa
138.16.64/22 autonomnom sistemu AS 1. Uzmimo kao drugi primer pretpostavku da se samo
prve tri podmree nalaze u AS-u2 a daje etvrta, 138.16.67/24, u AS-u3. Tada, kao stoje
objanjeno u tekstu pod naslovom Principi u praksi, odeljka 4.4.2, poto ruteri za prosledivanje
datagrama koriste pravilo najdueg prefiksa, AS3 bi mogao da dojavi AS-ul konkre-tniji prefiks
138.16.67/24, a AS2 bi ipak objavio zbirni prefiks 138.16.64/22. Svaku


objavu prefiksa moemo da posmatramo kao obeanje. Kada jedan AS objavi neki prefiks
drugom AS-u, on mu obeava da e proslediti datagram sa odreditem u tom prefiksu po putanji
prema tom prefiksu.
Ispitajmo sada kako bi BGP distribuirao informacije o dostupnosti prefiksa preko BGP
sesija prikazanih na slici 4.38. Kao to bi se oekivalo, pomou eBGP sesije izmeu mrenih
prolaza 3a i Ic AS3 alje u AS 1 listu prefiksa dostupnih iz AS-a3; a AS1 aljeuAS3 listu
prefiksa dostupnih iz AS-al. Slino tome,ASl i AS2 razme-njuju informacije o dostupnosti
prefiksa preko svojih rutera mrenog prolaza lb i 2a. Takoe prema oekivanju, kada ruter
mrenog prolaza (u bilo kom AS-u) primi prefikse koji stignu preko eBGP-a, on pomou svoje
iBGP sesije distribuira prefikse ostalim ruterima u AS-u. Na taj nain, ne samo da e ruteri iz
AS-al van eBGP sesije saznati za prefikse iz AS-a3, ve e za njih saznati i ruter mrenog
prolaza lb. Ruter mrenog prolaza lb (iz AS-al) moe zatim da objavi autonomnom sistemu AS2
prefikse iz AS-a3. Kada ruter (bez obzira na to da li je ruter mrenog prolaza ili nije) sazna za
neki novi prefiks, on u svojoj tabeli prosleivanja napravi stavku za taj prefiks kao to je opisano
u odeljku 4.5.3.

Atributi putanja i BGP
Poto sada imamo uvodna saznanja o BGP-u, krenimo malo dublje (ipak emo i dalje gurati pod
tepih neke manje vane detalje!). Kada se koristi BGP, autonomni sistem se prepoznaje po svom
globalno jedinstvenom broju autonomnog sistema {autonomous system number, ASN) [RFC
1930]. (Nije sasvim tano da svaki AS ima svoj ASN. Konkretno, takozvani zavrni AS koji
prenosi iskljuivo saobraaj iji je on ili izvor ili odredite, obino nema ASN; ovaj detalj
emo'zanemariti u
daljem opisu da nam drvo ne bi zaklonilo umu.) AS brojevi, kao i IP adrese, dodeljuju se u
regionalnim registrima ICANN [ICANN 2002].
Kada ruter kroz BGP sesiju objavljuje neki prefiks, on uz prefiks stavlja i odreen broj
BGP atributa. U BGP argonu, prefiks zajedno sa svojim atributima naziva se rutom. Prema
tome, ravnopravni BGP uesnici objavljuju jedni drugima rute. Dva najvanija atributa su
AS-PATH i NEXT-HOP:
AS-PATH. Ovaj atribut sadri eksplicitan spisak svih AS-ova kroz koje je prola objava za
prefiks o kojem je re. Kada se prefiks preda u AS, taj AS dodaje svoj ASN u atribut
AS-PATH. Na primer, razmotrite sliku 4.38 i pretpostavite daje prefiks 138.16.64/24 prvo
objavljen iz AS-a2 u ASI; ako ASI zatim objavi taj prefiks u AS3, atribut AS-PATH bi bio
AS2 ASI. Ruteri koriste atribut AS-PATH za otkrivanje i spreavanje petlji oglaavanja;
konkretno, ako ruter vidi da se njegov AS ve nalazi na spisku, on e odbaciti objavu. Kao
to emo uskoro objasniti, ruteri koriste atribut AS-PATH i prilikom biranja jedne od vie
putanja za isti prefiks.
NEXT-HOP. Par AS-ova, na primer AS A i AS B, moe da ima vie fizikih linkova koji ih
direktno povezuju. Zato, kada se prosleduje paket iz AS-a A u AS B, on bi mogao da se
poalje bilo kojim od ovih linkova koji direktno povezuju AS-ove. Kada ruter mrenog
prolaza iza AS-a B alje objavu rutera mrenom prolazu u AS-u A, on u objavu ukljuuje
svoju IP adresu (konkretni)e, IP adresu interfejsa koji ide do rutera mrenog interfejsa u
AS-u A). Ruter u AS-u A moe putem eBGP-a i iBGP-a da primi vie ruta za isti prefiks, a
da svaka prolazi kroz drugi ruter prvog skoka. Kada konfigurie svoju tabelu prosleivanja,
ovaj ruter bi morao da izabere jednu od tih putanja.
BGP takode ukljuuje atribute koji omoguavaju ruterima da rutama odrede ponder u izabranim
mernim jedinicama ijedan atribut koji oznaava na koji nainje prefiks stigao BGP u poetnom
AS-u. Potpuni opis atributa ruta moete nai u [Griffm 2002; Stewart 1999; Halabi 2000;
Feamster 2004].
Kada ruter mrenog prolaza dobije objavu rutera, on koristi svoju politiku uvoza pri
odluivanju da li da filtrira ili prihvati rutu i da li da podesi odreene atribute kao to su izabrane
meme jedinice rutera. Politika uvoza moe da filtrira rutu zato to AS ne eli da alje saobraaj
preko nekog od AS-ova iz spiska AS-PATH. Ruter mrenog prolaza moe takoe da filtrira rutu
zato to ve zna za bolju rutu prema istom prefiksu.

Izbor BGP ruta
Kao stoje u ovom odeljku ve reeno, BGP koristi eBGP i iBGP za distribuciju ruta svim
ruterima unutar AS-a. Iz distribuiranih informacija ruter moe da sazna za vie ruta prema istom
prefiksu pa u tom sluaju mora da se odlui za jednu od moguih ruta. U ovom postupku
selekcije ruter polazi od svih ruta za koje je saznao i koje je

I 382 382 382 382

prihvatio. Ako postoje dve ili vie ruta do istog prefiksa, BGP redom poziva sledea pravila
eliminacije dok ne ostane samo jedna ruta za dati prefiks,
Jedan od atributa svake rute je vrednost lokalnog prioriteta. Lokalni prioritet rute mogao je
da odredi ruter ili je mogao da ga sazna od drugog rutera u istom AS-u. Ovo je odluka
politike i preputa se mrenom administratoru AS-a. (Uskoro emo detaljnije opisati pitanja
BGP politika.) Biraju se rute sa najviim vredno-stima lokalnog prioriteta.
Od preostalih ruta (svih sa jednakom vrednou lokalnog prioriteta) bira se ruta sa najkraim
atributom AS-PATH. Daje ovo jedino pravilo za biranje ruta, BGP bi za odreivanje putanja
koristio algoritam DV, gde je jedinica mere za razdaljinu broj AS skokova a ne broj skokova
rutera.
Od preostalih ruta (svih sa jednakom vrednou lokalnog prioriteta i jednakim duinama
atributa AS-PATH) bira se ruta sa najbliim NEXT-HOP ruterom. Ovde se najbliim smatra
ruter za koga je utvrena najmanja cena po najjeftinijoj putanji, Ovaj postupak se esto
naziva rutiranjem vrueg krompira.
Ako jo uvek ostaje vie ruta, za izbor se koriste BGP identifikatori [Stewart 1999].
Pravila eliminacije su sloenija nego Stoje to gore opisano. Da bi se izbegle none more o
BGP-u, bolje gaje uiti u manjim dozama!

Politika rutiranja
Neke od osnovnih koncepata BGP rutiranja ilustrovaemo jednim jednostavnim pri-merom. Na
slici 4.39 prikazano je est meusobno povezanih autonomnih sistema: A, B, C, W, X i Y.
Obratite panju na to da su A, B, C, W, X i Y AS-ovi, a ne ruteri. Pretpostavimo da su
autonomni sistemi W, X i Y zavrne mree, a da su A, B i C mree posrednika za uslugu
okosnice. Sav saobraaj koji ulazi u zavrnu mreu mora imati odredite u toj mrei i sav
saobraaj koji naputa tu mreu mora da potie iz nje. Jasno je da su W i Y takve mree. X je
takozvana viedomna zavrna mrea, postoje povezana sa ostatkom mree preko dva razliita
posrednika (situacija koja je u praksi sve ea). Meutim, kao i W i Y, i sam X mora da bude
odredite, odnosno izvor svog saobraaja koji stie u X ili ga naputa. Ali, kako se implementira
i namee takvo ponaanje zavrne mree? Kako spreiti X da prosleuje saobraaj izmeu B i C?
To se moe Iako postii kontrolisanjem naina na koji se objavljuju BGP rute. Konkretno, X e
funkcionisati kao zavrna mrea ako (svojim susedima B i C) objavi da ne poseduje putanje hi za
jedno odredite osim njega samog. To jest, iako X zna za putanju, na primer XCY, kojom se
stie do mree Y, on nee objaviti tu putanju svom susedu B. .Poto B ne zna da X ima putanju
prema Y, B nee nikad proslediti saobraaj ije je odredite Y (ili C) preko X. Ovaj jednostavan
primer
ilustruje kako se za tmplementiranje odnosa izmeu korisnika i posrednika moe upotrebiti
selektivno objavljivanje ruta.
Preimo sada na mreu posrednika, na primer, AS B. Uzmimo da je B saznao (od A) da A
ima putanju AW prema W. B znai moe da instalira rum BAVV u svoju bazu informacija za
rutiranje. Jasno je, B takoe hoe da objavi putanju BAW svom korisniku X da bi X znao da se
prema W moe nitirati preko B. Meutim, da li bi B trebalo da oglasi putanju BAVV i drugom
korisniku C? Ako to uradi, tada bi C mogao da rutira saobraaj prema W preko CBAW. Ako su
A, B i C posrednici okosnice, tada bi B opravdano mogao da smatra da on ne treba da deli teret
(i trokove!) prenoenja tranzitnog saobraaja izmeu posrednika A i C. B moe opravdano da
smatra da je obaveza posrednika A i C da pri rutiranju koriste svoju direktnu vezu (i troak!)
izmeu A i C. Trenutno meu posrednicima za Internet usluge iz okosnice ne postoje zvanini
standardi za meusobno rutiranje. Meutim, grubo pravilo kojeg se dre komercijalni posrednici
zai Internet usluge jeste da saobraaj koji tee njihovom okosnicom mora imati izvor ili
odredite (ili oboje) u mrei nekog njihovog korisnika; inae taj saobraaj koristi besplatnu
vonju u mrei tog posrednika. Pojedinani partnerski ugovori (iz gore pomenute oblasti) obino
su predmet pregovaranja samih posrednika i smatraju se njihovom tajnom; u [Huston 1999a]
nalazi se zanimljiv opis partnerskih ugovora. Detaljniji opis naina na koji politike rutiranja
odraavaju komercijalne odnose meu posrednicima nai ete u [Gao 2001].
Kao to smo napomenuli, BGP je de facto standard za rutiranje meu AS-ovima u javnom
Internetu. Ako vas zanima sadraj razliitih BGP tabela rutiranja (velike su!) iz mtera
posrednika prvog reda, pogledajte http://www.routeviews.org. BGP tabele rutiranja esto sadre
na desetine hiljada prefiksa i odgovarajuih atributa. Statistike o veliini i karakteristikama BGP
tabela rutiranja predstavljene su u [Huston 2001].
Ovim zakljuujemo kratak uvod u BGP. Vano je razumeti BGP jer on igra centralnu
ulogu u Internetu. Savetujemo itaocima da pregledaju reference u [Griffin 2002; Stewart 1999;
Labovitz 1997; Halabi 2000; Huitema 1998; Gao 2001; Feam-ster 2004] i naue vie o BGP-u.

204 204 204 204 POGLAVLJE 4 MRENI SLOJ 4.7 . DIFUZNO I I I I VIEZNANO RUTIRANJE 385! 385! 385! 385!

PRINCIPI U PRAKSI
ZA ZA ZA ZATO SE UNUTAR TO SE UNUTAR TO SE UNUTAR TO SE UNUTAR 1 IZME IZME IZME IZMEU AS U AS U AS U AS- -- -OVA KORISTE RAZLI OVA KORISTE RAZLI OVA KORISTE RAZLI OVA KORISTE RAZLIITI PROTOKOLI RUTIRANJA? ITI PROTOKOLI RUTIRANJA? ITI PROTOKOLI RUTIRANJA? ITI PROTOKOLI RUTIRANJA?
Poto smo prouili detalje konkretnih protokola rutiranja koji se na dananjem Internetu koriste unutar
i izmeu AS-ova, moemo zakljuiti razmatranje ovim moda najfundamen-lalnijim pitanjem koje se
uopte moe postaviti o lim protokolima (nadam se da ste se sve vreme to pitali i da nisle zbog
drveta izgubili iz vida umu!): Zato se koriste razliiti protokoli rutiranja unutar i izmeu AS-ova?
Odgovor na ovo pitanje ukazuje na osnovnu razliku meu ciljevima rutiranja unutar i izmeu
AS-ova:
Pol i ti ka. Izmeu AS-ova preovladuju pitanja politike. Ponekad je vano da se saobraaju koji
potie iz datog AS-a nikako ne dozvoli prolaz kroz drugi konkretan AS. Slino tome, neki AS
moda eli da kontrolise vrstu tranzitnog saobraaja koji prenosi izmeu drugih ASova. Videli
smo da BGP prenosi atribute putanje i omoguava kontro-lisanu distribuciju informacija a
rutiranju, pa se mogu donositi takve odluke zasnovane na politici. Unutar AS-a se sve formalno
nalazi pod istom administrativnom kontrolom, pa pitanja politike imaju daleko manji znaaj kada
sa biraju tule unutar AS-a.
Skal i ranj e. Za rutiranje meu AS-ovima kritina je sposobnost algoritma'rutiranja i njegovih
struktura podataka da se skaliraju kako bi se omoguilo rutiranje prema velikom broju mrea i
izmeu njih. Unutar AS-a skaliranje nije toliko kritino. Meu ostalim, ako administrativni domen
previe poraste uvek ga je mogue podeliti na dva AS-a, pa izmeu njih koristiti rutiranje meu
AS-ovima. [Verovatno se seate da OSPF dozvoljava da se podelom AS-a u podruja" izgrade
takve hijerarhije.)
Performanse. Poto politika toliko utie na rutiranje meu AS-ovima, kvalitet (na primer,
performanse} upotrebljenih ruta cesto nije toliko znaajan (tj. ponekad e se izabrati dua' i
skuplja ruta koja zadovoljava odreene kriterijume politike umesto krae rute koja te kriterijume
ne zadovoljava). Zaista, videli smo da se rutama meu AS-ovima ne pridruuje ak ni pojam
cene (osim broja AS skokova). Unutar AS-a, meutim, pitanja politike nisu tako znaajna, pa se
rutiranje vie bavi performansama koje se mogu postii na ruti.
4. 7 Difuzno i vieznano rutiranje
U ovom poglavlju smo se do sada bavili protokolima rutiranja koji podravaju jednoznanu
komunikaciju (tj. od take do take) u kojoj jedan izvorni vor alje paket samo jednom
odredinom vora. U ovom odeljku obraamo panju na protokole za difuzno i vieznano
rutiranje. U difuznom rutiranju mreni sloj prua
uslugu isporuke paketa koji se iz jednog izvornog vora alje svim ostalim vorovima u mrei;
vieznano rutiranje omoguava da jedan izvorni vor poalje po primerak paketa nekom
podskupu ostalih vorova u mrei. U odeljku 4.7.1 razmo-triemo algoritme difuznog rutiranja i
njihovo otelotvprenje u protokolima rutiranja. Vieznano rutiranje istraiemo u odeljku 4.7.2.

4.7.1 Algoritmi difuznog rutiranja
Moda je najprostiji nain da se postignu komunikacije sa difuznim emitovanjem da otpremni
vor poalje zaseban primerak paketa na svako odredite, kao to je prikazano na slici 4.40(a).
Ako je dato N odredinih vorova, izvorni vor jednostavno napravi N kopija paketa, adresira
svaki primerak na drugo odredite a zatim poalje N primeraka na odredita pomou
jednoznanog rutiranja. Ovaj pristup sa iV-tostrukim jednoznanim difuznim emitovanjem je
jednostavan - nije potreban nikakav nov protokol rutiranja mrenog sloja, dupliranje paketa, niti
prosleivanje paketa. Taj pristup, meutim, ima nekoliko nedostataka. Prvi nedostatak je
njegova neefikasnost. Ako je izvomi vor vezan za ostatak mree samo jednim linkom, kroz taj
link e proi primeraka (istog) paketa. Jasno je da bi bilo efikasnije da se preko prvog skoka
poalje samo jedan primerak a da zatim vor na drugoj strani prvog skoka napravi i prosledi
potreban broj dodatnih kopija. To jest, bilo bi efikasnije kada bi sami mreni vorovi (a ne samo
izvorni vor) pravili duplikate paketa. Na primer, na slici 4.40(b) link R1-R2 prelazi samo jedan
primerak paketa. Taj paket se zatim duplira u R2 pa se linkovima R2-R3 i R2-R4 alje po jedan
primerak.
Jo jedan nedostatak pristupa sa AMostrukim jednoznanim emitovanjem je moda
suptilniji ali nije manje znaajan. Implicitna pretpostavka AMostrukog jednoznanog
emitovanja je da poiljalac zna sve primaoce i njihove adrese. Ali kako da se pribave te
informacije? Najverovatnije bi bili potrebni dodatni mehanizmi protokola (npr. protokol za
difuzno emitovani poziv na ulanjenje ili registrovanje odredita).
Pravljenje/prenoenje duplikata

4.7 DIFUZNO I VIEZNANO RUTIRANJE 205 205 205 205

To bi dovelo do dodatnog preoptereenja, a to je jo vanije, dodatnog uslonjava-nja protokola koji
je na poetku izgledao sasvim jednostavan. Konani nedostatak pristupa sa A^-tostrukim
jednoznanim emitovanjem odnosi se na svrhu kojoj difuzno emitovanje treba da slui. U odeljku 4.5
saznali smo da protokoli rutiranja prema stanju linkova koriste difuzno emitovanje za obznanjivanje
informacija o stanju linkova koje se koriste za izraunavanje jednoznanih ruta. Jasno je da ne bi bilo
mudro (u najmanju ruku!) koristiti infrastrukturu za jednoznano rutiranje u situaciji u kojoj se difuzno
emituju informacije za pravljenje i auriranje jednoznanih ruta.
S obzirom na nekoliko nedostataka pristupa sa N-tostrukim jednoznanim emitovanjem,
znaajni su pristupi u kojima sami mreni vorovi igraju aktivnu ulogu u dupliranju paketa,
prosledivanju paketa i izraunavanju difuznih ruta. Ispitaemo nekoliko takvih pristupa i pri tom
koristiti notaciju grafova koju smo uveli u odeljku 4.5. Ponovo modeliramo mreu kao graf, G =
{ N, E) , gde je H skup vorova i kolekcija E ivica gde je svaka ivica par vorova iz skupa N. Kada
to ne bude dovodilo do zabune biemo malo nedosledni sa notacijom pa emo koristiti N da bismo
oznaili i skup vorova kao i njegovu kardinalnost ( \ N\ ) odnosno veliinu.

Nekontrolisano plavljenje
Najoiglednija tehnika da se ostvari difuzno emitovanje je plavljenje u kojem izvorni vor alje
primerak paketa svim svojim susedima. Kada vor primi difuzno emitovani paket, on ga duplira i
prosleuje svim svojim susedima (osim suseda od kojeg je primio paket). Jasno je da e, ako je graf
povezan, ovom emom kad tad svaki vor u grafu primiti primerak paketa. Mada je ova ema
jednostavna i elegantna, ona ima jednu fatalnu greku (pre nego to nastavite sa itanjem, pokuajte
da otkrijete tu fatalnu greku): ako graf sadri cikluse, jedan ili vie primeraka svakog difuzno
emitovanog paketa e kruiti beskonano, Na primer, na slici 4.40 e R2 plaviti prema R3, R3 e
plaviti prema R4, R4 e plaviti prema R2, a R2 e plaviti (ponovo!) prema R3 i tako dalje. Ovaj
jednostavan scenario dovodi do beskonanog kruenja dva difuzno emitovana paketa, jednog u
smeru kretanja kazaljke na satu a drugog u smeru koji je suprotan smeru kretanja kazaljke na satu.
Meutim, moe se javiti jedna jo razomija fatalna greka: kada je vor povezan sa vie od dva druga
vora, on e napraviti i proslediti vie primeraka difuzno emitovanog paketa od kojih e svaki napraviti
vie primeraka (u drugim vorovima sa vie od dva suseda) i tako dalje. Takva oluja difuznog
emitovanja koja potie od beskonanog umnoavanja difuzno emitovanih paketa na kraju bi
proizvela toliko difuzno emitovanih paketa da bi mrea postala neupotrebljiva. (Meu domaim
zadacima na kraju ovog poglavlja nalazi se problem u kojem se analizira brzina kojom takva oluja
difuznog emitovanja raste.)
Kontrolisano plavljenje
Klju za izbegavanje oluje difuznog emitovanja sastoji se u tome da vor mudro proceni kada da
plavi a kada ne (npr. ako je ve primio i prosledio raniji primerak istog paketa). U praksi se to postie
na jedan od nekoliko naina.
U plavljenju pod kontrolom rednih brojeva izvorni vor stavlja u paket za difuzno
emitovanje svoju adresu (ili neki drugi jedinstveni identifikator) kao i redni, broj difuznog
emitovanja i zatim alje paket svojim susedima. Svaki vor odrava listu izvornih adresa i rednih
brojeva za sve difuzno emitovane pakete koje je ve primio, duplirao i prosledio. Kada primi difuzno
emitovani paket, vor prvo pro-verava da li se paket ve nalazi na listi. Ako se nalazi na listi, paket
se odbacuje; ako ga nema, paket se duplira i prosleuje svim susedima (osim suseda od kojeg je
paket primljen). U protokolu Gnutella, opisanom u poglavlju 2, koristi se plavljenje pod kontrolom
rednih brojeva za difuzno emitovanje poruka u preklopljenoj mrei. (Kada se koristi protokol
Gnutella, dupliranje i prosledivanje poruka vri se u aplikacijskom a ne u mrenom sloju.)
Drugi pristup reavanju problema kontrolisanog plavljenja je algoritam za prosledivanje
inverznom putanjom {reverse path fonvardirtg, RPF). [Dalal 1978] koji se ponekad naziva i
difuzno emitovanje inverznom putanjom (reversepath bro-adcasting, RPB). Zamisao na kojoj se
zasniva prosledivanje inverznom putanjom je jednostavna, ali ipak elegantna. Kada ruter primi
difuzno upueni paket sa datom adresom izvora, on predaje paket na sve svoje izlazne linkove
(osim onog na kojem je paket primljen) samo ako je paket stigao linkom koji se nalazi na njegovoj
vlastitoj najkraoj jednoznanoj putanji prema poiljaocu. Inae, ruter jednostavno odbacuje pristigli
paket i ne prosleuje ga ni na jedan od svojih izlaznih linkova. Takav paket moe da se ispusti poto
ruter zna daje na linku koji se nalazi na njegovoj najkraoj putanji prema poiljaocu ve primio ili e
primiti primerak istog paketa. (Mogli biste proveriti da li e se to zaista i dogoditi i da nee doi do
kruenja niti do oluje.) Obratite panju na to da prosledivanje inverznom putanjom ne koristi
jednoznano rutiranje za isporuku paketa na odredite niti zahteva da ruter zna celu najkrau puta-
nju izmeu njega i izvora. Dovoljno je da zna za sledei skok na njegovoj najkraoj jednoznanoj
putanji prema poiljaocu jer koristi identitet tog suseda samo za odluivanje da li da prosledi
primljeni difuzno upueni paket.
Na slici 4.4] prikazanje RPF. Pretpostavite da linkovi prikazani debelim zelenim linijama
predstavljaju najjeftinije putanje od primalaca do izvora ( A) . vor A na poetku difuzno upuuje
paket iz izvora A vorovima C i B. vor B e paket iz izvora A koji je primio od A (poto se A
nalazi na njegovoj najjeftinijoj putanji prema A) proslediti i u C i u D. B e zanemariti (ispustiti bez
prosledivanja) pakete iz izvora A koje primi iz svih ostalih rutera (na primer, od rutera C ili D) .
Razmotrimo sada vor C koji e primiti paket iz izvora A direktno od A, ali i od B. Poto se B ne
nalazi na najkraoj putanji od C do A, C e zanemariti (ispustiti) sve pakete iz izvora A koje primi
od B. Sa druge strane, kada C primi paket iz izvora A direktno od A, on e ga proslediti ruterima
B, E\ F,

4.7 . DIFUZNO I VIEZNANO RUTIRANJE 389! 389! 389! 389!

Difuzno emitovanje sveobuhvatnim stablom
Mada plavljenje pod kontrolom rednih brojeva i RPF izbegavaju oluje difuznog emitovanja, oni
ne izbegavaju u potpunosti prenoenje redundantnih difuzno emi-tovanih paketa. Na primer, na
slici 4.42 vorovi B, C, D i E primie jedan ili dva redundantna paketa. Idealno bi bilo da svaki
vor primi samo jedan primerak difuzno emitovanog paketa.
Ako ispitate stablo koje se sastoji od vorova povezanih debljim linijama na slici 4.42(a)
vidite da kada bi se difuzno emitovani paketi prosleivali samo du linkova ovog stabla, svaki
vor u mrei bi primio tano jedan primerak difuzno emitovanog paketa - upravo reenje kakvo
traimo! Ovo stablo je primer sveobuhvatnog stabla - stabla koje sadri sve vorove u grafu.
Formalnije reeno, sveobuhvatno stablo grafa G = (N,E)\q g i a f G'=(N,E
r
) takav da je E'
podskup od, G'je povezan, G' ne sadri cikluse i G' sadri sve prvobitne vorove iz G. Ako
svaki link ima pridruenu cenu a cena stabla je suma cena linkova, tada se'sveobuhvatno stablo
ija je cena najmanja od svih sveobuhvatnih stabala tog grafa naziva minimalno sveobuhvatno
stablo.
Prema tome, jo jedan pristup obezbeivanju difuznog emitovanja jeste da se prvo napravi
sveobuhvatno stablo. Kada izvorni vor hoe difuzno da emituje paket, on ga alje na sve
primerke linkova koji pripadaju sveobuhvatnom stablu. vor koji primi difuzno emitovani paket
zatim prosleduje paket svim svojim susedima u sveobuhvatnom stablu (osim suseda od kojeg je
primio paket). Ne samo to sveobuhvatno stablo eliminie redundantne difuzno emitovane
pakete, ve kad se jednom uspostavi to stablo moe koristi svaki vor koji poinje difuzno
emitovanje kao to je prikazano na slikama 4.41(a) i 4.42(b). Obratite panju na to da vor ne
mora biti svestan celog stabla; on jednostavno treba da zna koji od njegovih suseda iz G jesu
susedi u sveobuhvatnom stablu.
Glavna sloenost vezana za pristup sa sveobuhvatnim stablom jeste izgradnja i odravanje
sveobuhvatnog stabla. Razvijeno je vie distribuiranih algoritama sa sveobuhvatnim stablom
[Gallager 1983, Gartner 2003]. Ovde emo razmotriti samo jedan jednostavan algoritam. U
pristupu sa centrom za izgradnju sveobuhvatnog stabla definie se centralni vor (ponekad se
naziva takom sastanka ili centrom).'

4.7 DIFUZNO I VIEZNANO RUTIRANJE 391 391 391 391

vorovi zatim tom centralnom voru upuuju jednoznano adresirane poruke o pristupanju
stablu. Poruka o pristupanju stablu se prosleduje jednoznanim iritiranjem prema centru dok ne
stigne do vora koji ve pripada sveobuhvatnom stablu ili do centra. U svakom sluaju, putanja
kojom je ila poruka o pristupanju definie granu u stablu izmeu centra i rubnog vora koji je
pokrenuo poruku o pristupanju. Moe se smatrati da je ta nova putanja prikljuena postojeem
stablu.
Na slici 4.43 prikazana je izgradnja sveobuhvatnog stabla. Pretpostavite da se vor E
izabere za centar stabla. Stablu prvo pristupa vor F koji poruku o pristupanju prosleduje voru
E. Link EF postaje poetno stablo. Zatim stablu pristupa vor B tako to svoju poruku o
pristupanju alje voru E. Pretpostavimo da putanja jednoznanog upuivanja iz B u E ide preko
D. U tom sluaju, poruka pristupanja dodaje na stablo putanju BDE. vor A pristupa grupi
prosleivanjem svoje poruke o pristupanju prema E. Ako je putanja za jednoznano upuivanje
iz A prema E bila preko B, tada poto je B ve pristupio stablu, dolazak poruke o pristupanju iz A
u B dovee do trenutnog prikljuivanja linka AB na stablo. Sledei vor koji pristupa je C
prosleivanjem svoje poruke o pristupanju direktno u E, Na kraju, poto jednoznano rutiranje iz
G u E mora biti preko D, kada G poalje svoju poruku o pristupanju u E, link GD se prikljuuje
stablu u voru D.

Algoritmi za difuzno upuivanje u praksi
Protokoli za difuzno upuivanje se u praksi koriste i u aplikacijskom i u mrenom sloju. Kao
stoje reeno u odeljku 2.6, Gnutella [Gnutella 2004] koristi difuzno upuivanje u aplikacijskom
sloju za difuzno upuivanje upita o sadraju meu Gnutella uesnicima. Ovde je link izmeu dva
ravnopravna procesa distribuirane obrade u aplikacijskom sloju u stvari jedna TCP konekcija.
Gnutella koristi jedan vid pla-vljenja pod kontrolom rednih brojeva u kojem se jedan 16-bitni
identifikator i jedan 16-bitni opisiva korisnih podataka (koji definiu tip Gnutella poruke)
koriste za otkrivanje da li je primljena difuzno upuena ponika ve primljena, duplirana i
pro-sleena. Kao stoje ve reeno u odeljku 2.6, Gnutella takoe koristi polje TTL (rok trajanja)
da bi se ograniio broj skokova prilikom plavljenja. Kada proces Gnutella primi i duplira poruku,
os smanjuje polje TTL pre nego to prosledi upit. Na taj nain, prosleena Gnutella poruka e
stii samo do onih ravnopravnih uesnika koji su od pokretaa upita udaljeni manje od datog
broja (poetne vrednosti TTL) skokova aplikacijskog sloja. Gnutellin mehanizam plavljenja se
zato ponekad naziva plavljen}e sa ogranienim dometom.
Jo jedan vid plavljenja pod kontrolom rednih brojeva imamo i kod difuznog emitovanja
objava o stanju linkova (Link State Advertisment, LSA) u algoritmu rutiranja OSPF [RFC 2328,
Perlman 1999] i u algoritmu rutiranja JS-IS [RFC 1142, Perlman 3999]. Za identifikaciju objava
o stanju linkova OSPF koristi 32-bitni redni broj kao i 16-bitno polje starosti. Verovatno se
seate da OSPF vor povremeno difuzno emituje LSA-ove za povezane linkove kada se promeni
cena linka ili kada se link ukljui/iskljui. Redni brojevi LSA-ova koriste se za otkrivanje
duplikata ali za jo
jednu vanu funkciju u OSPF-u. S obzirom na plavljenje, mogue je da LSA koji je napravljen
na izvoru u trenutku / stigne nakon novijeg LSA-a koji je na istom izvoru napravljen u trenutku /
+ S. Redni brojevi koje pravi izvorni vor omoguavaju da se stariji LSA razlikuje od novijeg.
Polje starosti ima funkciju slinu polju TTL. Poetna vrednost polja starosti je nula a poveava
se pri svakom skoku plavljenja, ali se poveava i dok u memoriji rutera eka da bude prosleden.
Mada smo samo ukratko opisali LSA algoritam plavljenja, primeujemo da projektovanje LSA
protokola za difuzno emitovanje moe zaista da bude veoma sloeno, U [RFC 789; Perlman
1999, odeljak 12.2.3.3] opisan je incident kada je neispravno prenet LSA iz dva rutera u kvaru
doveo do toga da jedna od poetnih verzija algoritma LSA plavljenja skoro zaustavi ceo
ARPAnet.

4 . 7 . 2 Vieznano upuivanje
U prethodnom odeljku smo videli da se sa uslugama difuznog emitovanja, paketi isporuuju
svakom voru u mrei. U ovom odeljku obratiemo panju na uslugu vieznanog upuivanja u
kojoj se vieznano upueni paket isporuuje samo podskupu mrenih vorova. Niz novih
mrenih aplikacija zahteva isporuku paketa od jednog ili vie poiljalaca jednoj grupi primalaca.
Te aplikacije slue za paketsko slanje podataka (na primer, transfer softverske nadogradnje od
programera ka korisnicima kojima je potrebna nadogradnja), striming kontinualnih medija (na
primer, transfer audia, videa i teksta ivog predavanja za skup distribuiranih uesnika u
predavanju), aplikacije sa deljenim podacima (na primer, elektronska tabla za tele-konferencije
koja je zajednika za vie distribuiranih uesnika), dodatni podaci (na primer, stanje berze),
auriranje veb kesa i interaktivne igre (na primer, distribuirana interaktivna virtuelna okruenja
ili igre sa vie igraa kao to je Quake).
Kada se koristi vieznana komunikacija, odmah nailazimo na dva problema - kako
prepoznati primaoce vieznano upuenog datagrama i kako adresiran' datagram koji se alje tim
primaocima. U sluaju jednoznane komunikacije, IP adresa primaoca (odredita) nalazi se u
svakom jednoznano upuenom IP datagramu i identifikuje jedinog primaoca; u sluaju
difuznog upuivanja, svi vorovi treba da prime difuzno emitovani paket pa nisu potrebne
nikakve adrese odredita. Ali, u sluaju vieznanog upuivanja sada imamo vie primalaca.
Ima li smisla da svaki viestruko upueni datagram sadri IP adrese svih tih primalaca? Mada bi
za mali broj primalaca to reenje bilo izvodljivo, ne bi bilo dobro za sluaj stotina ili hiljada
primalaca; koliina adresnih informacija u datagramu bila bi vea od podataka koji se prenose u
polju korisnih podataka. Da bi poiljalac mogao eksplicitno da navede sve primaoce, on bi
morao da zna identitete i adrese svih primalaca. Ubrzo emo videti da postoje sluajevi kada bi
takav zahtev bio nepoeljan.
Iz tih razloga, u arhitekturi Interneta (a takode i u arhitekturi ATM [Black 1995]),
vieznano upueni datagram adresira se pomou indirektnih adresa. To jest, za grupu primalaca
se koristi jedan identifikator, a primerak datagrama koji je adresiran na grupu pomou tog
identifikatora isporuuje se svim primaocima koji su pridrueni

128.59.16.20

392 POGLAVLJE 4 - MRENI SLOJ
4.7 DIFUZNO I VIEZNANO RUTIRANJE 393j
toj grupi. Jedan identifikatorkoji u Internetu predstavlja grupu primalaca je adresa za vieznano
upuivanje klase D. Grupa primalaca vezana za adresu klase D naziva se grupa za vieznano
upuivanje. Pojam grupe za vieznano upuivanje prikazan je na slici 4.44. Ovde su etiri
raunara (osenena zeleno) pridruena adresi grupe za vieznano upuivanje 226.17.30.197 i
primie sve datagrame adresirane na tu adresu 2a vieznano upuivanje. Problem koji ostaje da
se resi je injenica da svaki raunar ima jedinstvenu IP adresu za jednoznano upuivanje koja je
potpuno nezavisna od adrese grupe za vieznano upuivanje u kojoj uestvuje.
Mada je pojam grupe za vieznano upuivanje jednostavan, on otvara niz novih pitanja.
Kako se grupa osniva i kako prestaje da postoji? Kako se bira adresa grupe? Kako se u grupu
dodaju novi raunari (bilo kao poiljaoci ili kao primaoci)? Moe li svako da se prikljui grupi (i
zatim alje ili prima datagrame tz grupe) ili se lanstvo u grupi ograniava, i ako je tako ko ga
kontrolie? Da Ji u okviru protokola mrenog sloja lanovi grupe znaju identitet ostalih
lanova? Kako mreni ruteri sarauju u
isporuivanju vieznano upuenog datagrama svim lanovima grupe? Za Internet, odgovori na
sva ova pitanja ukljuuju protokol za upravljanje grupama na Internetu (Internet Group
Management Protocol, IGMP) [RFC 3376]. Zato emo sada razmotriti IGMP, pa emo se nakon
toga vratiti na ova ira pitanja.

IGMP
Protokol za upravljanje grupama na Internetu (Internet Group Management Protocol, IGMP)
verzija 3 [RFC 3376], izvrava se izmeu raunara i njegovog direktno povezanog rutera
(nezvanino, direktno povezani ruter moete zamisliti kao ruter prvog skoka koji raunar vidi na
putanji prema bilo kojem drugom raunaru van vlastite lokalne mree ili kao ruter poslednjeg
skoka svake putanje prema ovom raunani), kao Stoje prikazano na slici 4.45. Na. slici 4.45
prikazana su tri rutera prvog skoka za vieznano upuivanje od kojih je svaki povezan sa
svojim raunarima preko jednog izlaznog lokalnog interfejsa. Taj lokalni interfejs je u ovom
primeru povezan sa LAN-om i mada svaki LAN ima vie povezanih raunara, oni obino ne
uestvuju svi u isto vreme u istoj grupi za vieznano upuivanje.
IGMP obezbeduje nain na koji raunar obavetava svoj povezani ruter da aplikacija koja
se izvrava na raunaru eli da pristupi odreenoj grupi za vieznano upuivanje. Kako je
IGMP ogranien na raunar i njegov direktno povezani ruter, jasno je da je potreban drugi
protokol koji e sluiti za koordinaciju vieznanih

394
4.7 . DIFUZNO I VIEZNANO RUTIRANJE 209

rutera (ukljuujui i povezane rutere) u elom Internetu da bi se vieznano upueni datagrami rutirali
do konanog odredita. Ova poslednja funkcija postie se pomou algoritama za vieznano rutiranje
u mrenom sloju kao to su PIM, DVMRP i MOSPF. Vieznano upuivanje u mrenom sloju
Interneta sastoji se od dve komplementarne komponente: IGMP-a i protokola za vieznano
rutiranje.
Iako se IGMP naziva protokolom lanstva u grupama" taj naziv nije sasvim taan poto se
IGMP izvrava lokalno, izmeu raunara i jednog povezanog rutera. Bez obzira na taj naziv, IGMP
nije protokol koji se izvrava meu svim raunarima koji su pristupili jednoj grupi za vieznano
upuivanje. Zaista, u mrenom sloju ne postoji nijedan protokol lanstva u grupi za vieznano
upuivanje koji se izvrava na svim Internet raunarima jedne grupe. Ne postoji, na primer, nijedan
protokol mrenog sloja koji bi omoguio raunaru da utvrdi identitet svili ostalih raunara u celoj
mrei koji su pristupili nekoj grupi za vieznano upuivanje. (Proitajte probleme za domai zadatak
gde e se dodatno istraivati posledice. ove projektantske odluke.)
IGMP ima samo tri vrste ponika. Fonnat IGMP poruke prikazanje na slici 4.46. Kao i za ICMP,
IGMP poruke se prenose (enkapsulirane) unutar IP datagrama sa brojem IP protokola 2. Ruter alje
poruku opti upit o lanstvu (engl. member-ship_query message) svim raunarima na prikljuenom
interfejsu (na primer, svim raunarima lokalne mree) da bi utvrdio skup svih grupa za vieznano
upuivanje kojima su pristupili raunari sa tog interfejsa. Ruter moe takoe da utvrdi da li je bilo koji
raunar sa prikljuenog interfejsa pristupio nekoj konkretnoj grupi za vieznano upuivanje ako uputi
konkretan upit o lanstvu. Kao stoje prikazano na slici 4.47, konkretan IGMP upit o lanstvu e u
polju za adresu grupe imati adresu za vieznano upuivanje traene grupe. Na poruku za upit o
lanstvu raunari odgovaraju IGMP porukom izvetaja o lanstvu (engl. membership_report mes-
sage) kao stoje prikazano na slici 4.47. Poruka sa izvetajem o lanstvu takoe se pravi u raunaru
kada aplikacija prvi put pristupa grupi za vieznano upuivanje, pa ne eka od rutera poruku sa
upitom o lanstvu.
Poslednja vrsta IGMP poruke je poruka o naputanju grupe (engl. leave_gro-up message).
Zanimljivo je daje ova poruka opciona! Ako je ona opciona, kako e ruter otkriti da na prikljuenom
interfejsu vie nema raunara koji pripadaju odreenoj grupi za vieznano upuivanje? Odgovor na
ovo pitanje lei u nainu na koji se koristi IGMP poruka za upit o lanstvu. Kada na poruku sa upitom
o lanstvu za
odreenu adresu grupe za vieznano upuivanje ne odgovori nijedan raunar, ruter zakljuuje da
nema raunara u datoj grupi. Ovo je primer onog to se ponekad naziva meko stanje internetskog
protokola. U protokolu sa mekim stanjem, stanje (u sluaju IGMP-a to je injenica da postoje raunari
koji pripadaju datoj grupi za vieznano upuivanje) se prekida putem tajm-auta (u ovom sluaju,
pomou povremene poruke sa upitom o lanstvu iz rutera) ako se eksplicitno ne obnovi (u ovom
sluaju porukom sa izvetajem o lanstvu iz prikljuenog raunara). Postoji miljenje daje protokole
sa mekim stanjem jednostavnije kontrolisati od protokola sa vrstim stanjima koja moraju eksplicitno
da se uspostavljaju i uklanjaju, a moraju jo da imaju i mehanizme za oporavak od situacije kada
otkae ili se pre vremena prekine entitet zaduen za uklanjanje stanja [Sharma 1997]. Izvrstan opis
mekog stanja moe se nai ii knjigama [Raman 1999; Ji 2003] proitajte i dodatak Principi u praksi
u odeljku 7.9.
Poto smo prouili protokol za pristupanje grupi za vieznano upuivanje i za njeno
naputanje, sada emo lake razumeti vaei model internetske usluge vieznanog upuivanja koja
se zasniva na radu tiva Diringa [RFC 1132, Deering 1990]. U tom modelu usluge, svaki raunar
moe da pristupi grupi za vieznano upuivanje u mrenom sloju. Raunar jednostavno izda svom
prikljuenom ruteru IGMP poruku sa izvetajem o lanstvu. Taj ruter e, u saradnji sa drugim
ruterima na Internetu, uskoro poeti tom raunaru da isporuuje vieznano upuene datagrame.
Prema tome, pristupanje grupi za vieznano upuivanje inicira primalac. Poiljalac ne mora da brine
o eksplicimom dodavanju primalaca u grupu za vieznano upuivanje, ali ne moe ni da kontrolie
ko pristupa grupi, pa prema tome ni ko prima datagrame koji se grupi alju. Slino tome, u poetnim
verzijama IGMP-a primalac nije mogao da odredi skup izvora iz kojih eli (ili ne eli) da prima
vieznano upuene pakete; IGMPv3 omoguava da se to odredi.
Postojei model usluge vieznanog upuivanja na Internetu zasniva se po mnogo emu na
istoj filozofiji kao i model usluge za jednoznano upuivanje - krajnje jednostavan mreni sloj, a
dodatne funkcije (kao stoje lanstvo u grupama) obezbeuju se u protokolima viih slojeva u
raunarima na periferiji mree. Ova filozofija je neosporno uspena u sluaju jednoznanog
upuivanja. Da li e minimalistiki

210 210 210 210 POGLAVLJE 4 MRENI SLOJ 4.7 . DIFUZNO I VIEZNANO RUTIRANJE 397 397 397 397

mreni sloj biti isto tako uspean za model usluge vieznanog upuivanja, ostaje jo uvek
otvoreno pitanje. Jedan alternativni model predstavljen je u [Holbrook 1999, RFC 3569].
Zanimljiv opis vaeeg modela usluge vieznanog upuivanja na Internetu i pitanja vezanih za
njegovu realizaciju nai ete u [Diot 2000].

Algoritmi za vieznano rutiranje
Na slici 4.48 prikazana je instalacija za problem vieznanog rutiranja. Razmotrimo jednu grupu
za vieznano upuivanje i pretpostavimo da svaki ruter kome je prikljuen raunar koji je
pristupio toj grupi moe da alje ili da prima saobraaj adresiran na tu grupu. Na slici 4.48 su
raunari koji su pristupili grupi za vieznano upuivanje oseneni u boji, a takode i njihov
direktno povezani ruter. Kao to se vidi na slici 4.48, vieznano upueni saobraaj potreban je
samo jednom podskupu u populaciji rutera za vieznano upuivanje (onima iji su prikljueni
raunari pristupili toj grupi za vieznano upuivanje). Na slici 4.48 to su ruteri A, B, E\ F.
Poto nijedan od raunara prikljuenih na ruter D nije pristupio grupi za vieznano upuivanje, a
ruteru C nije prikljuen nijedan raunar, ni C ni D nemaju potrebu da im se alje saobraaj grupe
za vieznano upuivanje.
Cilj vieznanog rutiranja je da se pronae stablo linkova koje povezuje sve rutere koji
imaju prikljuene raunare pripadnike grupe za vieznano upuivanje. Vieznano upueni
paketi e se zatim rutirati po tom stablu od poiljaoca do svih raunara koji pripadaju stablu za
vieznano upuivanje. Naravno, u stablu se mogu nai i ruteri bez prikljuenih raunara koji
pripadaju grupi za vieznano upuivanje (na primer, na slici 4.48 ne mogu se povezati ruteri
A, B, E\ F\ x stablo, a da se ne ukljui ruter C ili ruter D ili oba).
U praksi se za utvrivanje stabla vieznanog rutiranja koriste dva pristupa. Ti pristupi se
razlikuju po tome da li se koristi jedno stablo zajedniko za grupu za distribuciju saobraaja od
svih poiljalaca u grupi ili se za svakog pojedinanog poiljaoca pravi zasebno stablo rutiranja.
Vieznano rutiranje pomou stabla zajednikog za grupu. Kao u sluaju difuznog emitovanja
sveobuhvatnim stablom, vieznano rutiranje pomou stabla zajednikog za grupu zasniva se
na izgradnji stabla koje obuhvata sve rubne rutere tako to prikljueni raunari koji pripadaju
grupi alju (jednoznane) poruke pristupanja adresirane na centralni vor. Kao i kod difuznog
emitovanja poruka o pristupanju se pomou jednoznanog rutiranja prosleduje prema centru
dok ne stigne u sam centar ili do rutera koji ve pripada stablu za vieznano upuivanje. Svi
ruteri sa putanje kojom je ila poruka o pristupanju e zatim pro-sleivati primljene
vieznano upuene pakete prema rubnom ruteru koji je inicirao pristupanje. Osnovno pitanje
kod stabla za vieznano rutiranje sa centrom je postupak kojim se bira centar. Algoritmi za
biranje centra opisuju se u [Wall 1980; Thaler 1997;Estrin 1997].
Vieznano rutiranje pomou stabla od izvora. Dok je algoritam vieznanog rutiranja sa
stablom grupe sluio za izradu jednog zajednikog stabla rutiranja koje se koristi za rutiranje
paketa od svih poiljalaca, u drugoj velikoj klasi algoritama za vieznano rutiranje se za
svaki izvor u grupi za vieznano upuivanje pravi zasebno stablo. U praksi se RPF algoritam
(sa izvornim vorom x ) koristi za izgradnju stabla za vieznano upuivanje datagrama koji
polaze od izvora*. Algoritam RPF koji smo prouili treba malo prilagoditi da bi se koristio za
vieznano upuivanje. Da biste shvatili zato, razmotrite ta se dogaa u ruteru D na slici
4.49. Ako se koristi RPF za difuzno emitovanje, on e proslediti pakete ruteru G iako ruter G
nema nijedan povezani raunar koji je pristupio grupi za vieznano upuivanje. Mada to nije
tako strano u sluaju kada D ima samo jedan nizvodni ruter, G, zamislite ta bi se dogodilo
kada biste nizvodno od D imali na hiljade rutera! Svaki od tih rutera primio bi neeljene
vieznano upuene pakete. (Taj scenario nije sasvim nemogu. Prvobitni MBone [Casner
1992; Macedonia 1994], prva globalna mrea za vieznano upuivanje imala je na poetku
upravo taj problem.) Reenje problema sa primanjem neeljenih vieznano upuenih paketa
pod RPF-om naziva se orezivanje. Vieznani ruter koji primi vieznano upuene pakete i
nema prikljuene raunare koji su pristupili

211 211 211 211
4.8 . DIFUZNO I VIEZNANO RUTIRANJE 211 211 211 211

toj grupi poslae uzvodnom rutcru poruku orezivanja. Ako ruter primi poruke . orezivanja od
svih svojih nizvodnih rutera on moe da prosledi poruku orezivanja uzvodno.

Vieznano rutiranje na Internetu
Prvi protokol za vieznano rutiranje koji se koristio na Internetu i algoritam za vieznano
rutiranje sa najirom podrkom je protokol za vieznano usmeravanje sa vektorom
rastojanja (Distance Vector Multkast Routing Protokol, DVMRP) [RFC 1075]. DVMRP
implementira stabla od izvora, prosleivanje inverznom putanjom i orezivanje. DVMRP koristi
algoritam vektora rastojanja koji omoguava da svaki ruter izrauna izlazni link (sledei skok) na
svojoj najkraoj putanji prema svakom moguem izvoru. Ta informacija se zatim koristi u
algoritmu RPF koji smo malo pre opisali. Javno dostupan primerak DVMRP softvera moe se
dobiti u [mrouted 1996].
Pored izraunavanja informacija za sledei skok, DVMRP takoe izraunava spisak
zavisnih nizvodnih rutera koji je potreban za orezivanje. Kada ruter primi poruke orezivanja za
datu grupu od svih svojih zavisnih nizvodnih rutera, on e pro-
pagirati poniku orezivanja uzvodno prema ruteru od koga prima vieznano upueni saobraaj
za tu grupu. DVMRP poruka orezivanja sadri ivotni vek orezivanja (ija je podrazumevana
vrednost 2 sata) koji oznaava koliko e orezana grana ostati iskljuena do ponovnog
automatskog ukljuenja. Ruter alje DVMRP poniku prikljuenja svom uzvodnom susedu da bi
prethodno odseenu granu ponovo dodao na stablo vieznanog upuivanja.
Drugi protokol za vieznano upuivanje u irokoj upotrebi na Internetu je protokol
rutiranja za vieznano upuivanje nezavisno od protokola (Protocol Inde-pendent Multicast,
PIM) [Deering 1996; RFC 2362; Estrin 1998b] koji eksplicitno predvia dva razliita scenarija
vieznane distribucije. U takozvanom gustom reimu, lanovi grupe za vieznano upuivanje
su gusto locirani; tj. mnoge rutere ili veinu rutera u podruju treba ukljuiti u rutiranje
vieznano upuenih datagrama. U retkom reimu broj rutera sa prikljuenim lanovima grupe
je mali u odnosu na ukupan broj rutera; lanovi grupe su iroko rasejani. PIM se prilagoava
dihotomiji retko-gusto tako to nudi dva eksplicitna reima rada: gusti i retki reim. PIM Dense
Mode je tehnika prosleivanja inverznom putanjom sa slanjem i orezivanjem slina po
koncepciji sa protokolom DVMRP. PIM Sparse Mode je pristup na osnovu centra slian starijem
protokolu za vieznano rutiranje CBT (core-based tree) [RFC 2201; RFC 2189]. Jedno novije
svojstvo PIM-a je sposobnost da se nakon pristupanja zajednikoj taki prebaci sa zajednikog
stabla grupe na stablo sa odreenim izvorom. Stablo konkretnog izvora ponekad bolje odgovara
jer se smanjuje koncentracija saobraaja kada se koristi vie stabala sa konkretnim izvorima
(prouite probleme za domai zadatak). Ako se koristi PIM Sparse Mode, ruter koji od jednog
svog prikljuenog raunara primi datagram za slanje jednoznano e uputiti datagram
zajednikoj taki sastanka. Zajednika taka (rendezvous point, RP) zatim vieznano upuuje
datagram preko zajednikog stabla grupe. RP obavetava poiljaoca da prekine slanje ako nema
rutera prikljuenih na stablo (tj. kada niko ne slua!).
U gornjem opisu implicitno smo pretpostavili da svi ruteri izvravaju isti protokol za
vieznano rutiranje. Kao to smo videli i kod jednoznanog rutiranja to se obino dogaa
unutar jednog autonomnog sistema (AS). Meutim, razliiti AS-ovi mogu da izvravaju razliite
protokole za vieznano rutiranje. Za glavne Internet-ske protokole za vieznano rutiranje
definisana su pravila interoperabilnosti [RFC 2715]. (Pravila su posebno zamrena zbog veoma
razliitih pristupa vieznanom rutiranju u protokolima za retki i gusti reim.) Jo uvek,
meutim, nedostaje protokol za vieznano rutiranje meu AS-ovima da bi se rutirali vieznano
upueni datagrami izmeu razliitih AS-ova.
Do sada je DVMRP sluio kao de facto protokol za vieznano rutiranje meu AS-ovima.
Na kraju, pomenuemo da vieznano upuivanje nije na Internetu uzelo mnogo maha.
Mnoge kompanije za prenos (striming) video tokova i kompanije za distribuciju sadraja umesto
vieznanog upuivanja koriste preklapanje i prave mree za vieznanu distribuciju u
aplikacijskom sloju. Kao i IPv6, vieznani IP se borio - i jo uvek se bori - za znaajniji prodor
na Internet.

DOMAI ZADATAK: DOMAI ZADATAK: PROBLEMI I PITANJA 40l! 40l! 40l! 40l!
4. 8 Rezime
U ovom poglavlju krenuli smo u istraivanje jezgra mree. Nauili smo da mreni sloj obuhvata
sve raunare i rutere u mrei. Zbog toga su protokoli mrenog sloja najsloeniji u familiji
protokola.
Saznali smo da ruter moda mora istovremeno da obradi na milione tokova paketa izmeu
razliitih parova izvora i odredita. Da"bi ruter mogao da obradi tako veliki broj tokova,
projektanti su tokom godina zakljuili da bi zadaci rutera trebalo da ostanu to jednostavniji. Da
bi se pojednostavio posao rutera, mogue je pre-duzeti razliite mere ukljuujui korienje
mrenog sloja sa datagramima umesto mrenog sloja sa virtuelnim kolima, upotrebu ujednaenog
zaglavlja fiksne duine (kao za IPv6), eliminisanje fragmentacije (isto kao IPv6) kao i pruanje
samo usluge najboljeg pokuaja. Ovde je moda najvaniji trik u tome da se ne vodi rauna o
pojedinanim tokovima, ve da se odluke o rutiranju zasnivaju samo na hijerarhijski
strukturisanim odredinim adresama u paketima. Zanimljivo je primetiti da potanska sluba
godinama koristi upravo taj trik.
U ovom poglavlju, razmotrili smo takoe osnovne principe algoritama rutiranja. Saznali smo
da projektanti algoritama rutiranja apstrahuju mreu raunara kao graf sa vorovima i granama.
Polazei od takve apstrakcije mogue je iskoristiti bogatu teoriju pronalaenja najkraih putanja u
grafovima koja se u zajednici operacionih istraivanja i algoritama razvija ve 40 godina. Videli
smo da postoje dva ira pristupa, jedan centralizovani (globalni) pristup u kojem svaki vor
dobija kompletnu mapu mree i nezavisno primenjuje algoritam za rutiranje najkrae putanje; i
jedan decentralizovani pristup u kojem pojedinani vorovi imaju samo parcijalnu sliku cele
mree, a vorovi zajedniki rade na tome da se paketi isporue po najkraim rutama.Videli smo
kako se hijerarhija koristi u reavanju problema skaliranja tako to se velike mree dele u
nezavisne administrativne domene po imenu autonomni sistemi (AS-ovi). Svaki AS nezavisno
rutira svoje datagrame kroz AS, kao to svaka zemlja nezavisno rutira svoju potu po dravi.
Saznali smo kako se centralizovani, decentralizovani i hijerarhijski pristup primenjuju u glavnim
protokolima rutiranja na Internetu: RIP, OSPF i BGP. Prouavanje algoritama rutiranja zakljuili
smo razmatranjem difuznog i vieznanog rutiranja.
Zakljuujemo prouavanje mrenog sloja i prelazimo korak dalje niz familiju protokola, u
sloj veze, Isto kao i mreni sloj, sloj veze takoe spada u jezgro mree. Ali, u sledeem poglavlju
videemo da sloj veze ima znatnije lokalizovan zadatak prenoenja paketa meu vorovima na
istom linku ili LAN-u, Mada ovaj zadatak moe naizgled da se ini trivijalnim u poreenju sa
zadacima mrenog sloja, videemo da sloj veze postavlja pred nas niz znaajnih i fascinantnih
pitanja, koja e nas dugo zaokupljati.
| Domai zadatak: problemi i pitanja
ODEUCU.l-4.2
1. Obnovimo terminologiju koja se koristi u ovoj knjizi. Verovatno se seate da se paket
transportnog sloja naziva segment a daje paket sloja veze okvir. Kako se naziva paket
mrenog sloja? Sigurno se seate da se i ruteri i komutatori sloja veze nazivaju
komutatorima paketa. Koja je osnovna razlika izmeu rutera i komutatora sloja veze?
Imajte na umu da izraz ruteri koristimo i u mreama sa datagramima i u mreama sa
virtuelnim kolima.
2. Koje su dve glavne funkcije mrenog sloja u mreama sa datagramima? Koje dodatne
funkcije ima mreni sloj u mreama sa virtuelnim kolima?
3. Kakva je razlika izmeu rutiranja i prosledivanja?
4. .Da li ruteri koriste tabele prosledivanja i u mreama sa datagramima i u mreama sa
virtuelnim kolima? Ako je tako, opiite tabele prosledivanja za obe klase mrea.
5. Opiite neku zamiljenu uslugu koju bi mreni sloj mogao da prua pojedinanom paketu.
Uradite to isto za tok paketa. Da li neke od vaih zamiljenih usluga postoje u mrenom
sloju Interneta? Da li postoje u ATM-ovom modelu usluge CBR? Da li postoje u
ATM-ovom modelu usluge ABR?
6. Navedite neke aplikacije koje bi imale koristi od ATM-ovog modela usluge CBR.

ODELJAK 4.3
7. Objasnite zato svaki ulazni port u ruteru velike brzine uva kopiju tabele prosledivanja?
8. U odeljku 4.3 opisuju se tri vrste komutatorske mree. Navedite koje su i ukratko ih opiite.
9. Opiite na koji nain se gubitak paketa moe dogoditi u ulaznom portu. Opiite kako se
moe eliminisati gubitak paketa u ulaznom portu (ako se ne koriste beskonane pomone
memorije).
10. Opiite na koji nain se gubitak paketa moe dogoditi u izlaznim portovima,
11. Sta je to HOL blokiranje? Da li se ono deava u ulaznim ili u izlaznim portovima?
ODEUAK 4.4
12. Da li ruteri imaju IP adrese? Ako imaju, koliko ih imaju?
13. Koji je 32-bitni binarni ekvivalent IP adrese 223.1.3.27?

402
DOMAI ZADATAK: DOMAI ZADATAK: PROBLEMI I PITANJA 403
14. Posetite raunar koji koristi DHCP za dobijanje IP adrese, mrene maske,
podrazumevani niter i IP adrese lokalnog DNS servera. Navedite te vrednosti.
15. Pretpostavite da izmeu izvornog i odredinog raunara postoje tri rutera. AJco
i zanemarimo fragmentaciju, preko koliko interfejsa e prei IP segment koji se
1 poalje od izvornog do odredinog raunara? Koliko tabela pretraivanja e se
indeksirati da bi se datagram preneo od izvora do odredita?
16. Pretpostavimo da aplikacija svakih 20 ms proizvodi komade od po 40 bajtova
podataka i da se svaki takav komad enkapsulira u TCP segment, a zatim u IP
datagram. Koji procenat takvog datagrama pripada dodatnom optereenju, a
koji aplikacijskim podacima?
17. Pretpostavite da raunar A alje raunaru B jedan TCP segment enkapsuliran u
i IP datagram. Kada raunar B primi datagram, kako mreni sloj raunara B zna
| da treba taj segment (tj. korisne podatke datagrama) da preda TCP-u a ne UDP-
\ u ili nekom drugom?
\ 18. Pretpostavite da ste kupili beini ruter i povezali ga sa kablovskim modemom.
Pretpostavite takoe da va posrednik Internet usluga dinamiki dodeli vaem povezanom
ureaju (tj. beinom ruteru) jednu IP adresu, Takoe pretpostavite da u kui imate pet PC-ja
koji koriste 802.11 za beino povezivanje sa bei-
j nim ruterom. Kako se IP adrese dodeljuju PC-jima? Da li beini ruter koristi
I NAT? Zato?
j jj j 1 9. Opiite razliku izmeu polja zaglavlja kod protokola IPv4 i IPv6. Da U postoje
neka zajednika polja?
\ 20. Kae se da kada se IPv6 tuneluje kroz IPv4 rutere, IPv6 posmatra IPv4 tunele
j kao protokole sloja veze. Da li se slaete sa tim tvrenjem? Zato?
I ODELJAK 4.5
j jj j 21. Navedite razlike algoritama rutiranja prema stanju linkova i prema vektorima
j jj j rastojanja.
i 22. Objasnite kako je hijerarhijsko organizovanje Interneta pomoglo pri skaliranju
I na milione korisnika.
) 23. Da lije neophodno da svi autonomni sistemi koriste isti algoritam rutiranja
\ unutar AS-a? Zato?
| ODEUAK 4.6
"i
I II I 24. Razmotrite sliku 4.31. Uzmite prvobitnu tabelu u D i pretpostavite da D primi
j od .4 sledeu objavu:
Da li e se tabela u D promeniti? Ako hoe, kako?
25. Opiite razliku meu objavama protokola RIP i protokola OSPF.
26. Popunite praznu liniju: RIP objave obino objavljuju broj skokova do razliitih
odredita. Sa druge strane, BGP auriranja objavljuju ____________________ do razliitih
odredita.
27. Zato se na Internetu unutar i izmeu AS-ova koriste razliiti protokoli?
28.Zalo su pitanja politike isto toliko znaajna u unutranjim protokolima
AS-ova (kao to su OSPF i RIP) koliko i u protokolima izmeu AS-ova (kakav
je BGP)?
29. Definiite sledee pojmove i opiite razlike izmeu njili: podmrea, prefiks i
BGP ruta.
30. Na koji nain BGP koristi atribut NEXT-HOP? Kako koristi atribut AS-PATH?
31. Opiite na koji nain mreni administrator kod posrednika vieg reda implementira politike kada
konfigurie BGP.
ODELJAK 4.7
32. Koja je znaajna razlika izmeu implementiranja difuznog upuivanja pomou vie jednoznanih
upuivanja i jednogjedinog difuznog upuivanja koje podrava mreni ruter?
33. Da li su sledee izjave tane ili netane za sve tri vrste implementiranja difuznog upuivanja
(nekontrolisano plavljenje, kontrolisano plavljenje i difuzno emitovanje po sveobuhvatnom
stablu)? Moete poi od pretpostavke da se paketi ne gube zbog prekoraenja privremenih
memorija i da se svi paketi isporuuju na Sinku onim redosledom kojim su poslati.
a. vor e primiti vie kopija istog paketa.
b. vor moe da prosledi vie kopija jednog paketa preko istog izlaznog linka.
34. Kada raunar pristupi grupi za vieznano upuivanje da li mora da promeni svoju IP adresu u
adresu grupe za vieznano upuivanje kojoj pristupa?
35. Koje uloge, igraju protokol IGMP i protokol za vieznano rutiranje u regionalnoj mrei?
36. Koja je razlika izmeu zajednikog stabla grupe i stabla od izvora u kontekstu vieznanog
rutiranja?

PROBLEMI 405 405 405 405

Problemi
1. Razmotrimo razloge za mree sa datagramima i sa virtuelnim kolima i razloge
protiv njih.
a. Pretpostavimo da se u mrenom sloju ruteri nalaze u stresnim uslovima
zbog kojih ee mogu da otkazu. Koje aklivnosti bi trebalo izvriti na
viem nivou u sluaju otkazivanja rutera? Da li je za taj sluaj bolje okrue-
nje sa datagramima i sa virtuelnim kolima?
b. Pretpostavimo da bi u svrhu garantovanja nivoa performansi (na primer,
kanjenja) za celu putanju od izvora do odredita mrea zahtevala da poi-
ljalac objavi svoju maksimalnu brzinu saobraaja. Ako su prijavljena maksi-
malna brzina saobraaja i postojea objavljena brzina saobraaja takve da
nije mogue preneti saobraaj od izvora do odredita u zahtevanim grani-
cama kanjenja izvoru se ne dozvoljava da pristupi mrei. Da li bi se takva
politika lake postigla u okruenju sa datagramima ili sa virtuelnim kolima?
2. Razmotrite mreu sa virtuelnim kolima. Pretpostavite daje VC broj 16-bitno polje.
a. Koji je maksimalan broj virtuelnih kola koja mogu da se prenesu preko linka?
b. Pretpostavite da centralni vor odreuje putanje i VC brojeve prilikom
uspostavljanja konekcije. Pretpostavite da se na svakom linku du VC puta-
nje koristi isti VC broj. Opiite kako bi centralni vor utvrivao VC broj
prilikom uspostavljanja konekcije. Da lije mogue da bude manje aktivnih
virtuelnih kola od maksimuma defmisanog pod (a) a da ipak nema slobo-
dnih VC brojeva?
c. Pretpostavite da se dozvole razliiti VC brojevi na svakom linku du VC
putanje. Prilikom uspostavljanja konekcije, poto se utvrdi putanja sa kraja
na kraj, opiite kako linkovi mogu decentralizovano da biraju VC brojeve i
konfiguriu svoje tabele prosledivanja bez oslanjanja na centralni vor.
3. Osnovna tabela prosledivanja u mrei sa virtuelnim kolima ima etiri kolone. ta znae
vrednosti u tim kolonama? Osnovna tabela prosledivanja u mreu sa datagramima ima dve
kolone. ta znae vrednosti u tim kolonama?
4. Razmotrite mreu sa virtuelnim kolima sa 2-bitnim poljem za VC broj. Pretpostavite da mrea
hoe da uspostavi virtuelno kolo preko etiri linka: A, B, C i D. Pretpostavite da svaki od ovih
linkova trenutno ve odrava po dva virtu-elna kola sa sledeim VC brojevima:
a. Ako svako virtuelno kolo treba da koristi isti VC broj na svim linkovima
du putanje, koji VC broj bi mogao da se dodeli novom kolu?
b. Ako svako virtuelno kolo moe da ima razliite VC brojeve na raznim lin-
kovima du putanje (pa tabela prosledivanja mora da obavlja prevoenje
VC brojeva), koliko razliitih kombinacija etiri VC broja (po jedan za
svaki od etiri linka) bi se moglo upotrebiti?
5. U tekstu smo koristili izraz usluga sa konekcijom za opise u transportnom sloju a usluga
konekcije za mreni sloj. Zbog ega postoji ta suptilna razlika u terminologiji?
6. U odeljku 4.3 smo napomenuli da ne moe biti ekanja u redu na ulazu ako je komutatorska
mrea n puta bra od ulazne linije, pod pretpostavkom da n ulaznih linija ima identine
brzine. Objasnite (recima) zastoje tako?
7. Zamislite mreu sa datagramima u kojoj se koristi 32-bitno adresiranje. Pretpostavite da ruter
ima etiri linka, numerisana od 0 do 3, a da pakete treba proslediti interfejsima linkova na
sledei nain:
Raspon odredinih adresa Interfejs linka
n inoooo 00000000 00000000 00000000 0
do
11100000 l i i ui n mi l i l i mi l i l i
11100001 00000000 00000000 oooooooo 1
do
11 101001 00000000 I1I1I111 1 1 1 1 1 1 1 1
11101001 00000001 00000000 00000000 . 2
do
1110100L tlllUU UllIlU muni
Inae 3
a. Napravite tabelu prosledivanja sa etiri stavke koja e koristiti pravilo naj-
dueg prefiksa i prosleivati pakete na pravilne interfejse linkova.
b. Opiite na koji nain vaa tabela odreuje odgovarajui interfejs linka za
datagrame sa sledeim odredinim adresama:
11001000 10010001 01010001 01010101
11100001 00000000 11000011 00 U1100
11100001 10000000 00010001 0U10111
8. Zamislite mreu sa datagramima u kojoj se koristi 8-bitno adresiranje. Pretpostavite da ruter
koristi pravilo najdueg prefiksa i sledeu tabelu prosledivanja:
U odgovorima na sledea pitanja imajte na umu da svako od postojeih virtuel-nih,kola prolazi
samo kroz po jedan od navedenih linkova.

406
PROBLEMI 407

Navedite raspon odredinih adresa raunara i broj adresa u rasponu za svaki od navedenih
interfejsa. 9. Zamislite mreu sa datagramima u kojoj se koristi 8-bitno adresiranje. Pretpostavite
da ruter koristi pravilo najdueg prefiksa i sledeu tabelu prosleivanja:
Navedite raspon odredinih adresa raunara i broj adresa u rasponu za svaki od navedenih,
interfejsa.
10. Zamislite ruter koji povezuje tri podmree: Podmreu 1, Podmreu 2 i Podmreu 3.
Pretpostavite da svi interfejsi u tim podmreama moraju da imaju prefiks 223.1.17/24. Takoe
pretpostavite da Podmrea 1 mora da podri najvie 125 interfejsa a Podmree 2 i 3 treba da
podre najvie po 60 interfejsa. Odredite tri mrene adrese (oblika a.b.c/x) koje e zadovoljiti
postavljene zahteve.
11. 11 odeljku 4.2.2 dat je primer tabele prosleivanja (sa korienjem pravila najdueg prefiksa).
Prepiite tu tabelu ali u obliku a.b.c/x umesto u binarnom obliku.
12. U problemu 7 se zahtevalo da napravite tabelu prosleivanja (sa upotrebom pravila najdueg
prefiksa). Prepiite tu tabelu ali u obliku a.b.c/x umesto u binarnom obliku.
13. Zamislite podmreu sa prefiksom 101.101.101.64/26. Navedite primer adrese (oblika
xxx.xxx.xxx.xxx) koja se moe dodeliti u ovoj mrei. Pretpostavite da jedan posrednik za
Internet usluge poseduje blok adresa oblika 101.101.12S/17. Pretpostavite da on hoe od
tog-bloka da napravi etiri podmree sa podjednakim brojem IP adresa. Koji e biti prefiksi
(oblika a.b.c.d/x) te etiri podmree.
14. Razmotrite topologiju sa slike 4.17. Oznaite tri podmree sa raunarima (ponite u smeru
kazaljke na satu od 12:00) kao Mree A, B i C. Oznaite podmree bez raunara kao Mree D,
E i F.
a. Dodelite mrene adrese svakoj od ovih podmrea uz sledea ogranienja: Sve adrese treba
dodeliti iz 214.97.254/23; Podmrea A treba da ima
dovoljno adresa da podri 250 interfejsa; Podmrea B treba da ima dovoljno adresa da
podri 120 interfejsa; Podmrea C treba da ima dovoljno adresa da podri 120 interfejsa.
Naravno, podmree D, E i F moraju biti u stanju da podre po dva interfejsa. Za svaku
mreu dodeljivanje treba dati u obliku a.b.c.d/x ili a.b.c.d/x - e.f.g.h/v.
b. Na osnovu odgovora pod (a), napravite tabele prosleivanja (uz pravilo najdueg prefiksa)
za svaki od tri rutera.
15. Razmotrite slanje datagrama od 3000 bajtova u link iji je MTU jednak 500 bajtova.
Pretpostavite da originalni datagram ima identifikaciju 422. Koliko fragmenata treba
napraviti? Kakve su im karakteristike?
16. Pretpostavite da su izmeu izvornog raunara A i odredinog raunara B datagrami ogranieni
na 1500 bajtova (ukljuujui zaglavlje). Ako pretpostavimo daje zaglavlje 20 bajtova, koliko bi
datagrama bilo potrebno da se poalje jedan MP3 od 4 miliona bajtova?
17. Razmotrite raspored mree sa slike 4.20. Pretpostavite daje posrednik dodelio ruteru adresu
126.13.89.67, a daje mrena adresa matine mree 192.168/16.
a. Dodelite adrese svim interfejsima u matinoj mrei.
b. Pretpostavite da svaki raunar ima TCP konekcije u toku, sve sa portom 80
raunara 128.13 9.40.86. Pripremite est odgovarajuih stavki za NAT tabelu
prevoenja,
18. U ovom problemu treba da analiziramo uticaj NAT-a na P2P aplikacije. Pre-
tpostavite da ravnopravni uesnik Amold upitom otkrije da uesnik po imenu
Bernard ima datoteku koju eli da preuzme. Pretpostavite takoe da se-Ber-
nard nalazi iza NAT-a a Arnold ne. Neka adresa NAT-a prema WAN-u bude
138.76,29.7 a interna IP adresa za Bernarda 10.0.0.1. Pretpostaviemo da NAT nije posebno
konfigurisan za tu P2P aplikaciju.
a. Objasnite zato uesnik Arnold ne moe da pokrene TCP konekciju sa Ber-
nardom iako zna daje WAN adresa NAT-a 138.76.29.7.
b. Pretpostavite sada daje Bernard uspostavio TCP konekciju sa drugim
uesnikom, Sindi, koja nije iza NAT-a, Pretpostavite takoe daje Arnold
saznao od Sindi da Bernard ima eljenu datoteku i da Arnold moe da uspo-
stavi (ili je ve uspostavio) TCP konekciju sa Sindi. Opiite na koji nain
Amold moe da upotrebi dve TCP konekcije (jednu od Bernarda do Sindi
i drugu od Amolda do Sindi) i obavesti Bernarda da pokrene direktnu TCP konekciju (tj.
mimo Sindi) sa Arnoldom. Ta se tehnika ponekad naziva okretanje konekcije. Obratite
panju na to da i pored toga Stoje Bernard iza NAT-a, Arnold moe da upotrebi ovu direktnu
TCP konekciju da zatrai datoteku a Bernard moe tom konekcijom da isporuu datoteku.
19. Nadoveimo se na prethodni problem i pretpostavimo da su i Arnold i Bernard
iza NAT-ova. Pokuajte da osmislite tehniku kojom bi Arnold uspostavio TCP
konekciju sa Bernardom bez posebnog kon figuri sanja NAT-a za odreenu apli-
kaciju. Ako imate tekoe sa defmisanjem takve tehnike, objasnite zato.

408 408 408 408
POGLAVLJE 4 . MRENI SLOJ
PROBLEMI 409 409 409 409

20. Na slici 4.25 navedite putanje od u do z koje ne sadre petlje.
21. Razmotrite sledeu mreu. Sa navedenim cenama linkova primenite Dijkstrin algoritam
najkrae putanje i izraunajte najkrau putanju od x do svih ostalih mrenih vorova.
Prikaite rad algoritma pomou tabele sline tabeli 4.3.
22. Razmotrite mreu prikazanu u problemu 21. Pomou Dijkstrinog algoritma u
obliku slinom tabeli 4.3,
a. izraunajte najkrau putanju od s do svih ostalih mrenih vorova.
b. izraunajte najkrau putanju od i do svih ostalih mrenih vorova.
c. izraunajte najkrau putanju od u do svih ostalih mrenih vorova.
d. izraunajte najkrau putanju od v do svih ostalih mrenih vorova.
e. izraunajte najkrau putanju od w do svih ostalih mrenih vorova.
f. izraunajte najkrau putanju o&y do svih ostalih mrenih vorova.
g. izraunajte najkrau putanju od z do svih ostalih mrenih vorova.
23. Razmotrite sledeu mreu i pretpostavite da svaki vor na poetku zna za cenu
do svakog od svojih suseda. Uzmite algoritam vektora rastojanja i prikaite
stavke za tabelu rastojanja u voru z.
24. Razmotrite jednu optu topologiju (tj. nemojte uzeti konkretnu gore prikazanu mreu)
ijednu sinhronu verziju algoritma vektora rastojanja. Pretpostavite
da pri svakoj iteraciji vor razmenjuje svoje vektore rastojanja sa susedima i prihvata
njihove vektore rastojanja. Ako pretpostavimo da algoritam u svakom voru poinje od
saznanja jedino o cenama do svojih neposrednih suseda, koji je maksimalan broj iteracija
potreban da se distribuirani algoritam zavri? Dokaite svoj odgovor.
25. Razmotrite dole prikazani fragment mree. x ima samo dva prikljuena suseda, w\y.w ima
najjeftiniju putanju do odredita u (nije na slici) koja iznosi 5, a y ima najjeftiniju putanju
do u koja iznosi 6. Nismo prikazali kompletne putanje iz w i y do u (i izmeu w i y). Sve
cene linkova u mrei imaju iskljuivo celo-brojne pozitivne vrednosti.
a. Navedite stavke vektora rastojanja od x do odredita w, y i u.
b. Navedite promenu cene linka za c(x, xv) ili c{x, y) takvu da x obavesti svoje
susede o postojanju nove najjeftinije putanje prema u do koje je dolo
nakon izvravanja algoritma vektora rastojanja.
c. Navedite promenu cene linka za c(x, w) ili c(x,y) takvu da x nee obavestiti
svoje susede o postojanju nove najjeftinije putanje prema u nakon izvrava-
nja algoritma vektora rastojanja.
26. Razmotrite topologiju sa tri vora prikazanu na slici 4.27. Umesto cena linkova prikazanih
na slici 4.27, cene linkova su c(x,y) = 5, c(y, z) = 6, c(z, x) = 2. Izraunajte
tabele-rastojanja nakon koraka inicijalizacije i nakon svake iteracije jedne sinkrone verzije
algoritma vektora rastojanja (kao to smo ranije uradili prilikom opisa slike 4.27).
27. Opiite kako se u BGP-u mogu otkriti petlje u putanjama.
28. Razmotrite mreu koja je prikazana na poetku sledee strane. Posrednik B prua usluge
dravne okosnice regionalnom posredniku A. Posrednik C prua usluge dravne okosnice
regionalnom posredniku D. B i C su meusobno ravnopravno povezani na dva mesta i
koriste BGP. Razmotrite saobraaj koji se kree od A do D. B e radije predati saobraaj
posredniku C na Zapadnoj obali (pa e C morati da snosi trokove prenoenja saobraaja
kroz celu zemlju), dok bi C radije preneo saobraaj preko ravnopravne take na Istonoj
obali (tako da bi B snosio trokove saobraaja kroz celu zemlju). Koji bi BGP mehanizam
mogao da upotrebi C da bi predao saobraaj iz A za D u zajednikoj taki sa B na Istonoj
obali? Da biste odgovorili na ovo pitanje, inoraete dobro da prouite specifikaciju BGP.

PROBLEMI 411

29 Na slici 4 39 razmotrite informacije o putanjama koje stiu u zavrne mree W, X i Y. Na osnovu
informacija dostupnih u W i X, kakav je pogled na topolo-giju mree iz svakog od njih?
Objasnite svoj odgovor. Pogled na topologiju iz mree Y je sledei.
30. Razmotrite mreu sa osam vorova (gde su vorovi oznaeni slovima od s do 2) iz problema
21. Prikaite stablo minimalnih cena koje poinje od s, a ukljuuje (kao zavrne raunare)
vorove u, v, w i y. Svojim recima objasnite zato vae stablo jeste stablo minimalnih cena.
31. Razmotrite dva u osnovi razliita naina za ostvarivanje difuznog upuivanja: emulacija
pomou jednoznanog upuivanja i difuznog upuivanje pomou mrenog sloja (tj. pomou
rutera) pod pretpostavkom da se za difuzno upuivanje pomou mrenog sloja koristi difuzno
emitovanje po sveobuhvatnom stablu. Uzmimo sluaj sa jednim poiljaocem i 32 primaoca.
Pretpostavite da je poiljalac povezan sa primaocima jednim binarnim stablom rutera. Kakva je
za ovu topologiju cena slanja difuzno upuenog paketa u sluaju emulacije pomou
jednoznanog upuivanja i u sluaju difuznog upuivanja pomou mrenog sloja? Ovde, kad
god se paket (ili kopija paketa) alje preko jednog linka nastupa troak". Kakva topologija
meusobnog povezivanja poiljaoca,
primalaca i rutera dovodi do najvee razlike izmeu ove dve cene? Moete uzeti koliko god
hoete rutera.
32. Razmotrimo funkcionisanje algoritma inverznog prosleivanja (RPF) sa slike 4.41. Pomou iste
topologije pronaite skup putanja od svih vorova do izvornog vora A (i oznaite te putanje na
grafu deblje osenenim linijama kao na slici 4.41) tako da ako bi te putanje bile najjeftinije
putanje, tada bi pod RPF-om vor B primio od A, od C i od D po jedan primerak difuzno
emitovane poruke iz A.
33. Razmotrite topologiju prikazanu na slici 4.41, gde svi linkovi imaju jedinine cene i
pretpostavite daje vor E izvor difuznog upuivanja. Pomou strelica kakve su prikazane na
slici 4.41, ukaite na linkove preko kojih e se paketi prosleivati pomou RPF-a i linkove preko
kojih se paketi nee prosleivati ako se uzme da vor E predstavlja izvor.
34. Razmotrite topologiju prikazanu na slici 4.43. i pretpostavite da svi linkovi imaju jedinine cene.
Pretpostavite daje vor C izabran za centar u algoritmu za vieznano rutiranje prema centru.
Pod pretpostavkom da kada alje poruku pristupanja u C svaki prikljueni ruter koristi svoju
najjeftiniju putanju do vora C, nacrtajte dobijeno stablo za vieznano rutiranje prema centru.
Da li je dobijeno stablo jedno stablo minimalnih cena? Objasnite svoj odgovor.
35. U odeljku 4.5.1 smo prouili Dijkstrin algoritam rutiranja prema stanju linkova koji izraunava
jednoznane putanje koje su pojedinano najjeftinije od izvora do svih odredita. Unija tili
putanja mogla bi se posmatrati kao stablo najjeftinijih jednoznanih putanja (ili stablo
najkraih jednoznanih putanja, ako su cene svih linkova identine). Izgradnjom suprotnog
primera dokaite da stablo najjeftinijih putanja nije uvek isto to i stablo sa minimalnim
sveukupnim cenama.
36. Zamislite mreu u kojoj su svi vorovi povezani sa tri druga vora. U jednom vremenskom
koraku vor moe da primi difuzno emitovane pakete od svojih suseda, duplira pakete i poalje
ih svim svojim susedima (osim vora od kojeg je primio konkretan paket). U sledeem koraku,
susedni vorovi mogu da ih prime, dupliraju, proslede itd. Pretpostavite da se u takvoj mrei za
difuzno emitovanje koristi nekontrolisano plavljenje. Koliko e primeraka difuzno emitovanog
paketa biti preneto u koraku t , pod pretpostavkom da je u koraku I prenet samo jedan difuzno
emitovani paket iz izvornog vora do njegova tri suseda.
37. Videli smo u odeljku 4.7 da ne postoji protokol mrenog sloja koji bi se mogao upotrebiti za
prepoznavanje raunara koji uestvuju u grupi za vieznano upuivanje. Polazei od toga,
kako mogu aplikacije za vieznano upuivanje da saznaju identitet raunara koji uestvuju u
grupi za vieznano upuivanje?
38. Projektujte protokol (napravite opis u obliku pseudo koda) na aplikacijskom nivou koji
evidentira adrese raunara za sve raunare koji uestvuju u jednoj grupi za vieznano
upuivanje. Konkretno navedite mrenu uslugu (jednoznanu ili vieznanu) koju va protokol
koristi i navedite da li va protokol alje poruke unutar ili van normalnog toka (u odnosu na tok
aplikacijskih podataka medu uesnicima u grupi za vieznano upuivanje), i zato to ini.

412 412 412 412
POGLAVLJE 4 . MRENI SLOJ
LABORATORIJA ETHEREAL 413 413 413 413
39. Koja je veliina adresnog prostora za vieznano upuivanje? Pretpostavite sada da dve
razliite grupe za vieznano upuivanje biraju adresu na sluajan nain. Kolika je
verovatnoa da e izabrati istu adresu? Pretpostavite sada da 1000 grupa za vieznano
upuivanje istovremeno bira adresu grupe na sluajan nain. Kolika je verovatnoa da
doe do preklapanja?
Teze za diskusiju
1. Pronaite tri kompanije koje trenutno prodaju ruterske proizvode velike brzine. Uporedite
proizvode.
2. Upotrebite uslugu whois u amerikom registru za Internet brojeve (http://
www.arin.net/whois) i utvrdite blokove IP adresa za tri univerziteta. Moe li se usluga
whois iskoristiti za pouzdano utvrivanje lokacije konkretne IP adrese?
3. Da lije mogue napisati klijentski program ping (sa IMCP porukama) u Javi? Zato?
4. U odeljku 4.7 napomenuli smo da uvoenje protokola IPv6 za sada ide sporo. Zato ide
sporo? ta bi bilo potrebno da se to uvoenje ubrza?
5. Opiite neke probleme koje NAT-ovi postavljaju pred IPsec bezbednost (videti [Phifer
2000]).
6. Pretpostavite da AS-ovi X i Z nisu direktno povezani, ve da su povezani preko AS-a Y.
Nakon toga pretpostavite da X ima ugovor o ravnopravnosti sa Y, a da Y ima isti takav
ugovor sa Z. Na kraju, pretpostavite da Z prihvata tranzit svakog saobraaja iz Y, ali ne
prihvata tranzit saobraaja iz X. Da li BGP omoguava da Z implementira takvu politiku?
7. U odeljku 4.7 prikazali smo niz aplikacija vieznanih upuivanja. Koja od tih aplikacija je
primerena za minimalistiki Internetov model usluge vieznanog upuivanja? Zato? Koje
aplikacije nisu posebno primerene za ovaj model usluge?
Programerski zadatak
U ovom programerskom zadatku pisaete distribuirani" skup procedura koje implementiraju
distribuirano asinhrono rutiranje pomou vektora rastojanja za sledeu mreu.
Treba da napiete sledee rutine koje e se izvravati" asinhrono u pripremljenom
okruenju za ovaj zadatak. Za vor 0 treba da napiete rutine:
rtinit0{). Ova rutina e se pozvati jednom na poetku emulacije. Rutina rtinitO nema
argumenata. Ona treba da inicializuje vau tabelu rastojanja u voru 0 direktnim cenama 1, 3
i 7 do vorova I, 2 odnosno 3. Na gornjoj slici su svi linkovi dvosmerni, a cene u oba smera
identine. Nakon inicijaliziranja tabele rastojanja i ostalih struktura podataka potrebnih za
rutine vaeg vora 0, trebalo bi direktno povezanim susedima (u ovom sluaju, 1, 2 i 3)
poslati cene najjeftinijih putanja do svih ostalih vorova u mrei. Ove informacije o
minimalnim cenama alju se susednim vorovima u paketu za auriranje rutiranja tako to se
pozove rutina tolayer2Q kao stoje opisano u potpunom opisu zadatka. Format paketa za
auriranje rutiranja takoe se nalazi u potpunom opisu zadatka.
rtupdate0(struct rtpkt *rcvdpkr). Ova rutina e se pozivati kada vor 0 primi paket rutiranja
od nekog direktno povezanog suseda. Parametar *rcvdpkt je pokaziva na primljeni paket.
Rutina rtupdateOO predstavlja sr" algoritma vektora rastojanja. Vrednosti u paketu za
auriranje mtiranja dobijenom iz nekog drugog vora / predstavljaju cene trenutno
najjeftinijih putanja od vora / do svih ostalih vorova u mrei. Rutina rtupdate0Q koristi
primljene vrednosti za auriranje vlastite tabele rastojanja (kao stoje navedeno u algoritmu
vektora rastojanja). Ako se zbog ovog auriranja promeni njegova minimalna cena do nekog
drugog vora, vor 0 o toj promeni minimalne cene obavetava svoje direktno povezane
susede tako to im alje paket rutiranja. Sigurno se seate da u algoritmu vektora rastojanja
samo direktno povezani vorovi razmenjuju pakete rutiranja. Prema tome, vorovi 1 i 2 e
meusobno komunicirati, a vorovi 1 i 3 nee.
Sline rutine definisane su za vorove 1, 2 i 3. Prema tome, ukupno ete napisati osam
procedura: rtinitQ{), rtinitl{), rtinit2(), rtinit3(), rtupdateO(), rtupdateli), rtupda(e2() i
rtupdate3{). Te rutine e sve zajedno da implementiraju distribuirano, asinhrono izraunavanje
tabela rastojanja za topologiju i cene prikazane na slici sa prethodne strane.
Potpuni opis programskog zadatka, kao i kod u jeziku C koji e vam biti potreban za
pravljenje simuliranog hardversko/softverskog okruenja moete nai na adresi
http://www.awI.com/kurose-ross. Dostupna je takoe verzija ovog zadatka u jeziku Java.
Laboratorija Ethereal
Na veb lokaciji koja pripada ovom udbeniku: http;//www.awl.com/kurose-ross nai ete dve
Ethereal vebe za ovo poglavlje. U prvoj vebi ispituje se rad protokola IP, a posebno format IP
datagrama. U drugoj vebi istrauje se protokol ICMP u komandama- ping i traceroute.

219 219 219 219
415 415 415 415

INTERVJU
Vinton Vinton Vinton Vinton G. G. G. G. Serf Serf Serf Serf
Vihton G. Serf je vii potpredsednik odeljenja za arhifekluru i tehnologiju u
VVorldCom. Poznal je kao jedan od projektanata protokola TCP/IP i
arhitekture Interneta. Kao potpredsednik u MCI Digital Information
Services od 1982. do 1986. godine, on je predvodio uspostavljanje
sistema MCI Mail, prve komercijalne usluge za e-potu ________________
povezane sa Internetom. Dok je od 1976. do 1982. godine bio u agenciji za napredne
istraivake projekte ministarstva odbrane SAD [Defense Advanced Research Projeds
Ageocy, DARPA), njegova uloga je bila do vodi razvoj Interneta i tehnologija
bezbednosti i paketa podataka vezanih za Internet. Vinton je magistrirao matematiku
na univerzitetu Stanford, a doktorirao raunarske nauke na univerzitetu UCLA.
fa vas je navelo na specijalizaciju h oblasti umreavan\a?
Krajem '60-tih godina radio sam kao programer na univerzitetu UCLA. Moje postavljenje
podravala je Agencija za napredne istraivake projekte ministarstva odbrane SAD (koja se
tada nazivala ARPA, a sada DARPA). Radio sam u laboratoriji profesora Leonarda Klajnroka u
Centru za mrena merenja novostvorenog ARPANET-a. Prvi vor mree ARPANET
instaliranje na univerzitetu UCLA septembra 1969. godine. Ja sam bio zaduen za
programiranje jednog raunara koji se koristio za evidentiranje informacija o performansama
ARPANET-a i za izvetavanje o tim informacijama radi poredenja sa matematikim modelima i
predvienim performansama mree.
Nekoliko drugih apsolvenata i ja bili smo zadueni za rad na takozvanim protokolima za
nivo raunara" ARPANET-a - na procedurama i formatima koji bi omoguili saradnju razliitih
vrsta raunara u mrei. To je bilo oaravajue istraivanje (za mene) novog sveta distribuiranog
raunarstva i komunikacije.

Kada ste projeklovali protokol IP, da li ste zamiljali da e jednog dana biti toliko sveprisutan?
Kada smo Bob Kan i ja poeli na tome da radimo 1973. godine, mislim da smo uglavnom
razmiljali o glavnom pitanju: kako da obezbedimo saradnju razliitih paketskih mrea pod
pretpostavkom da ne moemo da menjamo same mree. Nadali smo se da emo pronai nain
koji e omoguiti proizvoljnom skupu paketskih mrea da saraduju na transparentan nain tako
da e raunari moi da komuniciraju sa kraja na kraj bez potrebe da uestvuju u bilo kakvim
prevoenjima, Mislim da smo znali da je re o monoj tehnologiji koja e moi da se iri, ali
sumnjam da smo imali predstavu kakav e biti svet sa milionima raunara povezanih u Internet.
Kakvo je vae miljenje o budunosti umreavanja i Interneta? Po vaem miljenju, koji su glavni
izazovi i prepreke u njihovom daljem razvoju?
Ja verujem da e sam Internet, i mree uopste, i dalje da se ire. Ve postoje ubedljivi dokazi da
c na Internetu postojati milijarde ureaja osposobljenih za Internet, ukljuujui sprave kao to
su mobilni telefoni, friideri, PDA-ovj, kuni serveri, televizori, kao i uobiajeni laptopovi,
serveri itd. Velike izazove predstavljaju podrka za mobilnost, trajanje baterija, kapacitet
linkova za pristup mrei i mogunost proirenja optikog umreavanja bez ogranienja.
Odreivanje meuplanetarnog proirenja Interneta je projekat na kojem sam intenzivno
angaovan u laboratoriji Jet Propulsion. Moraemo da preemo sa IPv4 (32-bk-nog adresiranja)
na 3Pv (128 bitova). Spisak je dugaak!

Ko vas je profesionalno inspirisao?
Moj kolega Bob Kan, moj mentor Derald Estrin, moj najbolji prijatelj Stiv Kroker (sreli
smo se u gimnaziji i on mi je prvi pokazao raunare 1960!); i hiljade inenjera koji danas
nastavljaju da razvijaju Internet.

Da li imate neki savet za studente koji danas ulaze u domen umreavanja i Interneta?
Razmiljajte izvan ogranienja postojeih sistema - zamislite ta bi moglo da se ostvari; a zatim
obavite teak posao smiljanja kako da se to dostigne polazei od trenutnog stanja stvari.
Usuujte se da sanjate: nekoliko kolega i ja u laboratoriji Jet Propulsion radimo na projektu
meuplanetarnog proirenja zemaljskog Interneta. Ta implementacija moe da potraje na desetine
godina, ali da parafraziram: ovek treba da stremi dalje od onog sto dosee, jet emu inae
slue nebesa?"

220

Sloj veze
podataka i
lokalne mree
raunara

U prethodnom poglavlju saznali ste da sloj mree obezbeduje komunikacionu uslugu' izmeu dva
matina raunara. Kao to je prikazano na slici 5.1, ova komunikaciona putanja sastoji se od niza
komunikacionih linija koji poinje od izvornog raunara, prolazi kroz niz rutera i zavrava se na
odredinom raunaru. Kako nastavljamo da prolazimo kroz familiju protokola, od sloja mree do
sloja veze podataka,:prirodno je da se zapitamo kako se paketi alju preko pojedinanih linija,
unutar komunikacione putanje od take do take. Kako se datagrami mrenog sloja
enkapsu.liraju u okvire sloja veze podataka za prenos preko jedne linije? Da li protokoli sloja
veze podataka obezbeuju pouzdan prenos podataka o jednog do drugog rutera? Mogu H
razliiti protokoli sloja veze podataka da se upotrebe'u razliitim linijama du komunikacione
putanje? Na ova, kao i na druga vana pitanja, odgovoriemo u ovom poglavlju.
Objanjavajui sloj veze, otkriemo da postoje dve fundamentalno razliite vrste kanala.
Prva vrsta sastoji se od difuznih kanala, koji su uobiajeni u lokalnim raunarskim mreama
(LAN), beinim LAN-ovimo, satelitskim mreama i mreama sa pristupom preko hibridnih
optikih kablova (HFC). Kod difuznog-kanala,.Vei broj raunara povezan je na istu
komunikacionu liniju i potreban je tzv. protokol za

418
POGLAVLJE 5 SLOJ VEZE PODATAKA I I I I LOKALNE MREE RAUNARA 5 .1 SLOJ VEZE PODATAKA: UVOD I USLUGE 221 221 221 221

pristup medijumu da bi se uskladili prenosi i izbegle kolizije. Druga vrsta kanala je
komunikaciona linija od take do take, kao na primer izmeu dva rutera Ui zmedu modema u
stanu i rutera posrednika za Internet usluge (ISP). Usklaivanje pristupa u liniji od take do
take je jednostavno, ali ipak postoje mnoga pitanja, koja obu-hvataju okvire, pouzdan prenos
podataka, otkrivanje greaka i kontrolu toka.
U ovom poglavlju emo istraiti vie znaajnih tehnologija sloja veze podataka. Detaljnije
emo razmotriti Ethernet, daleko najrasprostranjeniju tehnologiju lokalnih raunarskih mrea.
Pogledaemo takoe PPP, protokol pogodan za kune raunare.
Iako Wi-Fi, i uopte beini LAN-ovi, svakako spadaju u tematiku u vezi sa slojem veze
podataka, njih ne objanjavamo u ovom poglavlju. Razlog lei u tome to je Wi-Fi znaajna
tema - VVi-Fi revolucija dramatino menja nain kako ljudi pristupaju i koriste Ethernet. Zato je
Wi-Fi detaljno objanjen u poglavlju 6, koje je posveeno beinim raunarskim mreama i
mobilnosti.

5.1 Sloj veze podataka: uvod i usluge
Hajde da ponemo sa nekom korisnom terminologijom. U ovom poglavlju emo raunare i
rutere jednostavno zvati vorovi (nodes), i zato nam, kao to emo uskoro videti, nee biti
posebno znaajno da lije vor ruter ili raunar. Takoe, komunikacione kanale koji povezuju
susedne vorove du komunikacione putanje, zvaemo linkovi. Dakle, da bi se datagram preneo
od izvornog do odredinog raunara, on mora da pree preko svakog pojedinanog linka u
putanji od take do take. Na datom linku, predajni vor enkapsulira datagram u okvir i prenosi
okvir u link; prijemni vor prima okvir i iz njega izvlai datagram.

5.1.1 Usluge koje obezbeduje sloj veze
Protokol sloja veze podataka koristi se za prenos datagrama du pojedinanog linka. Protokol
sloja veze definie format paketa koji se razmenjuju izmeu vorova na krajevima linka, kao i
aktivnosti koje ti vorovi preduzimaju prilikom predaje i prijema tih paketa. Setite se iz
poglavlja 1 da se jedinice podataka koje se razmenjuju pomou protokola sloja veze podataka
zovu okviri i daje uobiajeno da svaki okvir ovog sloja enkapsulira jedan datagram mrenog
sloja. Kao to emo uskoro videti, aktivnosti koje preduzima protokol sloja veze podataka
prilikom slanja i prijema okvira obuhvataju otkrivanje greke, ponovni prenos, kontrolu toka i
sluajan pristup. Primere protokola sloja veze podataka moete nai u mreama kao to su
Ethernet, beine lokalne raunarske mree 802.11 (poznate kao i Wi-Fi), Token Ring i PPP; u
mnogim situacijama i ATM moe da se posmatra kao protokol sloja veze podataka. Navedene
protokole emo detaljnije objasniti u drugoj polovini ovog poglavlja.
Dok mreni sloj treba da prenosi segmente transportnog sloja od take do take, od
izvornog do odredinog raunara. protokol sloja veze podataka treba da prenosi datagrame
mrenog sloja od vora do vora, preko jednog linka u putanji. Znaajna karakteristika sloja
veze podataka jc da datagram moe da se prenosi razliitim protokolima veze podataka na
razliitim linkovima du putanje. Na primer, datagram moe da se prenosi pomou Etherneta na
prvom linku, pomou PPP-a na posle-dnjem linku i pomou WAN protokola sloja veze na svim
linkovima izmeu njih.

222 222 222 222 POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA
5.1 SLOJ VEZE PODATAKA: UVOD I USLUGE

421 421 421 421
1
Vano je zapaziti da usluge koje pruaju razliiti protokoli veze podataka i same mogu da budu
razliite. Na primer, protokol sloja veze moe ili ne moe da obe-zbedi pouzdanu isporuku.
Prema tome, mreni sloj mora da bude sposoban da izvri svoj zadatak od take do take, u
prisustvu heterogenog skupa pojedinanih usluga sloja veze.
Da bismo stekli uvid u sloj veze i u to kakav je njegov odnos prema mrenom sloju, hajde
da razmotrimo analogiju sa prevozom. Zamislite putniku agenciju koja planira turistiko
putovanje od Prinstona, u Nju Derziju, do Lozane u vajcarskoj. Pretpostavite da agencija
odlui daje za turistu najpogodnije da ide limuzinom od Prinstona do aerodroma JFK, zatim
avionom od aerodroma JFK do aerodroma u enevi i najzad vozom od aerodroma u enevi do
eleznike stanice u Lozani. Kada je putnika agencija napravila te tri rezervacije, odgovornost
kompanije za iznajmljivanje limuzina u Prinstonu je da preveze turistu od Prinstona do
aerodroma JFK; na vazduhoplovnoj kompaniji je da ga preveze turistu od JFK-a do eneve; a
odgovornost vajcarske eleznice je da on stigne od eneve do Lozane. Svaki od tri segmenta
putovanja je direktan" izmeu dve susedne" lokacije. Zapazite da svakim od tri segmenta
putovanja upravlja razliita kompanija i da koristi sasvim razliit nain prevoza (limuzina, avion
i voz). Mada su naini prevoza razliiti, svaki od njih prua osnovnu uslugu prenosa putnika od
jedne do druge susedne lokacije. U ovoj analogiji sa prevozom, turista je analogan sa
datagramom, svaki segment prevoza je analogan sa komunikacionim linkom, nain prevoza je
analogan sa protokolom sloja veze podataka, a putnika agencija koja planira putovanje je
analogna sa protokolom rutiranja.
Iako je osnovna funkcija usluge svakog sloja veze podataka da prenosi" datagram od
jednog do drugog susednog vora preko jednog komunikacionog linka, detalji usluge zavisie od
specifinog protokola koji se koristi. Protokol sloja veze podataka moe da prui sledee usluge:
Pravljenje okvira. Gotovo svi protokoli sloja veze podataka enkapsuliraju svaki datagram
mrenog sloja u okvir pre njegovog slanja na link. Okvir se sastoji od polja za podatke, u
koje se stavlja datagram mrenog sloja i izvesnog broja polja zaglavlja. (Okvir moe takoe
da ukljui zavrna polja; meutim, mi emo i polja zaglavlja i zavrna polja zvati poljima
zaglavlja.) Strukturu okvira odreuje protokol veze podataka. Kada u drugoj polovini ovog
poglavlja budemo ispitivali odreene protokole sloja veze podataka, videemo vie razliitih
formata okvira.
Pristup linku (LinkAccess). Protokol Media Access Control (MAC) definie pravila po
kojima se okvir prenosi na link. Za linkove od take do take, koji imaju jednog poiljaoca
najednom kraju i jednog primaoca na drugom kraju, protokol MAC je jednostavan (ili ak ine
postoji) - poiljalac moe da alje okvir kad god je link slobodan. Zanimljiviji sluaj nastaje
kada vie vorova deli jedan difuzni link - to je tzv. problem viestrukog pristupa. Ovde
MAC slui da koordinira prenose okvira iz vie vorova; protokole viestrukog pristupa
detaljno emo objasniti u odeljku 5.3.
Pouzdana isporuka. Kada protokol sloja veze podataka obezbeduje pouzdanu uslugu
isporuke, on garantuje da e preneti svaki datagram mrenog sloja preko linka bez greke.
Setite se da izvesni protokoli transportnog sloja (kao stoje TCP) takoe obezbeuju pouzdanu
uslugu isporuke. Slino usluzi pouzdane isporuke transportnog sloja, usluga pouzdane
isporuke sloja veze podataka postie se pomou potvrda i ponovnih prenosa (proitajte
odeljak 3.4). Usluga pouzdane isporuke obino se koristi za linkove koji su skloni velikoj
uestanosti greaka, kao to su beini linkovi, u cilju lokalnog ispravljanja greaka - na linku
gde se greka pojavljuje - radije nego da se prisilno ponavlja prenos od take do take
pomou protokola transportnog ili aplikacijskog sloja. Meutim, usluga pouzdane isporuke
moe da se posmatra kao nepotrebno dodatno optereenje za linkove sa malim grekama, kao
to su optiki, koaksijalni i mnogi linkovi sa upredenim paricama bakarnih provodnika. Iz tog
razloga, na mnogim oienim linkovima nije obezbeena usluga pouzdane isporuke.
Kontrola toka (flow control). vorovi na svakom kraju linka imaju ogranien kapacitet
privremenog smetanja okvira. To je potencijalni problem, zato to pri-
. jemni vor moe da prima okvire brzinom veom od one kojom je u stanju da ih obrauje.
Bez kontrole toka, privremena memorija prijemnika mogla bi da se prepuni, a okviri koji
zatim dolaze da se izgube. Slino transportnom sloju, protokol sloja veze podataka
obezbeduje kontrolu toka kako bi spreio predajni vor najednom kraju linka da prepuni
prijemni vor na drugom kraju linka.
Otkrivanje greke. Prijemnik vora moe pogreno da odlui da je bit u nekom okviru nula
kada je poslat kao jedinica i obratno. Do takvih greaka dolazi usled slabljenja signala i
elektromagnetskih smetnji. S obzirom na to da nije potrebno da se prosleduje datagram sa
grekom, mnogi protokoli sloja veze podataka imaju mehanizam za otkrivanje prisustva
jedne greke ili vie greaka. To se radi tako to predajni vor postavlja u okvir i bitove za
otkrivanje greke, a prijemni vor proverava te bitove, tj. da traga za grekama. Otkrivanje
greke je uobiajena usluga meu protokolima sloja veze podataka. Setite se iz poglavlja 3 i
4, da transportni i mreni slojevi Interneta takoe obezbeuju ogranien oblik otkrivanja
greke. Otkrivanje greke u sloju veze podataka obino je sloenije i implementirano je u
hardveru.
Ispravljanje greke. Ispravljanje greke slino je njenom otkrivanju, izuzev to prijemnik
moe ne samo da otkrije da lije dolo do greke u okviru, nego takoe i da tano odredi gde
se u okviru ona pojavila (pa samim tim i da ima mogunost da je ispravi). Neki protokoli
(kao to je ATM) obezbeuju ispravljanje greaka samo u zaglavlju paketa, a ne za ceo
paket. Otkrivanje i ispravljanje greaka objasniemo u odeljku 5.2.
Poludupleks i puni dupleks. Kod punog dupleksnog prenosa, svaki vor, na bilo kom kraju
linka, moe da predaje i prima pakete isto vreme. Kod poluduplek-snog prenosa, vor ne
moe da predaje i prima u isto vreme.

422 422 422 422 POGLAVLJE 5 SLOJ VEZE PODATAKA 1 LOKALNE MREE RAUNARA 5.2 TEHNIKE ZA OTKRIVANJE I ISPRAVLJANJE GREAKA 223

Kao Stoje ranije reeno, mnoge usluge koje obezbeuje sloj veze podataka paralelne su sa
uslugama koje obezbeuje transportni sloj. Na primer, i sloj veze podataka i transportni sloj mogu da
obezbede pouzdanu isporuku. Iako su mehanizmi koji se koriste za obezbeivanje pouzdane
isporuke u ta dva sloja slini (proitajte odeljak 3.4), usluge pouzdane isporuke ipak nisu iste.
Transportni protokol obezbeuje pouzdanu isporuku izmeu dva procesa od take do take;
pouzdani protokol sloja veze podataka obezbeuje uslugu pouzdane isporuke izmeu dva vora
povezana jednim linkom. Slino tome, protokoli i sloja veze podataka i transportnog sloja, mogu da
obezbede kontrolu toka i otkrivanje greaka; opet, kontrola toka u protokolu transportnog sloja
obezbeuje se od take do take, dok se u protokolu sloja veze podataka ona obezbeuje od vora
do susednog vora.

5.1.2 Komuniciranje adaptera
Za dati komunikacioni link, protokol sloja veze podataka je u veini sluajeva implementiran u
adapteru. Adapter je ploa (ili PCMCIA kartica) koja obino sadri RAM, DSP ipove, interfejs
magistrale raunara i interfejs linka. Uobiajeno je da se adapteri zovu mrene interfejsne kartice ili
NIC. Kao stoje prikazano 'na slici 5.2, mreni sloj u predajnom voru (odnosno raunaru ili ruteru)
prosle-uje datagram adapteru, koji upravlja predajnom stranom komunikacionog linka. Adapter
enkapsulira datagram u okvir i zatim predaje okvir na komunikacioni link. Na drugoj strani, prijemni
adapter prima ceo okvir, izvlai datagram i prosleuje ga mrenom sloju. Ako protokol sloja veze
podataka obezbeuje otkrivanje greke, predajni adapter postavlja bitove za otkrivanje greke, a
prijemni adapter proverava da li ima greaka. Ako protokol sloja veze podataka obezbeuje pouzdanu
isporuku, tada su mehanizmi za pouzdanu isporuku (na primer, sekvenca brojeva, tajmer i potvrde)
potpuno implementirani u adapterima. Ako protokol sloja veze podataka obezbeuje sluajan pristup
(proitajte odeljak 5.3), tada je i protokol sluajnog pristupa potpuno implementiran u adapterima.
Adap-ter je poluautonomna jedinica. Na primer, adapter moe da primi okvir, odredi da li je on
pogrean i odbaci ga, a da o tome ne obavesti vor koji ga je poslao. Kada primi okvir, adapter e
poslati signal prekida svom raunani samo ako eli da prosledi datagram mrenom sloju. Slino
tome, kada vor prosleuje datagram adapteru nanie, on mu poverava sav posao oko prenosa
datagrama preko tog linka. Iako je adapter poluautonoman, on nije potpuno autonomna jedinica.
Mada smo na slici 5.3 prikazali adapter kao posebnu kutiju", on je obino smeten u istom
fizikom kuitu sa ostalim komponentama vora, deli sa njim napajanje i magistrale i, na kraju,
nalazi se pod kontrolom vora.
Kao stoje prikazano na slici 5.3, glavni sastavni delovi adaptera su interfejs magistrale i
interfejs linka. Interfejs magistrale odgovoran je za komunikaciju sa vorom u kome se adapter
nalazi, prenosei podatke i upravljake informacije. Interfejs linka odgovoran je za implementiranje
protokola sloja veze podataka. Pored stavljanja datagrama u okvir i njiiiovog izdvajanja iz okvira, on
moe da obezbedi otkrivanje greke, da implementira protokol sluajnog pristupa, kao i da obezbedi i
druge potrebne funkcije. On takoe obuhvata i elektronska kola za predaju i prijem elektrinih
signala sa linka. Kod popularnih tehnologija, kao stoje Ethernet, interfejs linka implementiran je
pomou skupa ipova koji se mogu kupiti na tritu iroke potronje. Iz tog razloga, adapteri za
Ethernet i \VI-Fi su neverovatno jeftini -esto kotaju manje od 20 US$. Ako posetite veb stranicu za
adaptere firme 3COM, moete saznati vie o arhitekturi adaptera za Ethernet od 10, 100 i 1000 Mb/s
i za ATM od 155 Mb/s [3Com 2004].
5.2 Tehnike za otkrivanje i ispravljanje greaka
U prethodnom odeljku napisali smo da su otkrivanje i ispravljanje greaka na nivou bita - otkrivanje i
ispravljanje oteenja bitova unutar okvira sloja linka poslatog iz jednog vora u drugi sa njim fiziki
povezani vor - dve usluge koje esto obezbeduje sloj veze podataka. U poglavlju 3, videli smo da
se usluge otkriva-

224 224 224 224 POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA 5.2 . TEHNIKE ZA OTKRIVANJE I ISPRAVLJANJE GREAKA
425: 425: 425: 425:

nja i ispravljanja greaka esto nude i u transportnom sloju. U ovom odeljku, ispita-emo
nekoliko najjednostavnijih tehnika koje mogu da se upotrebe za otkrivanje i, u nekim
sluajevima, ispravljanje greaka. Potpuna teretska obrada i implementacija ove tehnike je sama
po sebi predmet mnogih radova (na primer, [Schv/artz 1980] ili [Bertsekas 1991]), pa emo sa na
njoj ovde samo kratko zadrati. Na cilj je da razvijemo intuitivan oseaj za mogunosti koje
imaju tehnike za otkrivanje i ispravljanje greaka i da vidimo kako rade jednostavne tehnike i
kako se one koriste u praksi.
Na slici 5.4 ilustrovana je postavka koju emo koristiti u naem prouavanju. Na strani
predajnog vora, podatak D koji treba da se zatiti od greaka bitova, proiren je je bitovima za
otkrivanje i ispravljanje greaka (EDQ. Podatak koji treba da se zatiti po pravilu ne ukljuuje
samo datagram koji je prosleden nanie iz mrenog sloja, nego i informaciju adresiranja na nivou
linka, brojeve sekvence i druga polja u zaglavlju okvira veze podataka. 1 D i EDC alju se ka
prijemnom voru unutar okvira linka. Kod prijemnog vora primaju se sekvence bitova D' i
EDC. Zapazite da D' i EDC mogu da se razlikuju od originalnih D i EDC, kao rezultat promene
bitova u prenosu.
Izazov za prijemnik je da otkrije da li je D' isti kao originalni D ili nije, imajui u vidu da je
primio samo D' i EDC. Precizno izraavanje po pitanju prijemnikove odluke na slici 5.4 je
znaajno (Mi pitamo da lije otkrivena greka, a ne da li se greka dogodila!). Tehnike za
otkrivanje i ispravljanje greaka dozvoljavaju prije-
mniku da ponekad, ali ne uvek, otkrije da su se pojavile greke bitova. To znai da, ak i uz
upotrebu bitova za otkrivanje greaka, postojae i dalje mogunost da se pojave neotkrivene
greke bitova, odnosno da prijemnik nije u stanju da otkrije da sadraj primljene informacije
ima pogrene bitove. Posledica toga je da prijemnik isporuuje neispravan datagram mrenom
sloju, ili da zakljuuje daje sadraj nekog drugog polja u zaglavlju okvira oteen. Mi zato
elimo da odaberemo emu otkrivanja greaka, tako daje verovatnoa ovakvih dogaaja mala.
Uopteno govorei, sloenije tehnike za otkrivanje i ispravljanje greaka (odnosno one koje rade
uz manju verovatnou pojave neotkrivenih greaka bitova) zahtevaju da se obavi vie
izraunavanja i prenese vei broj bitova u komunikaciji.
Hajde da sada ispitamo tri tehnike za otkrivanje greaka u podacima - ispitivanja pamosti
(da bismo ilustrovali osnovne ideje o otkrivanju i ispravljanje greaka), metode kontrolnog zbira
(koje se ee primenjuju u transportnom sloju) i cikline provere redundantnosti (za koje je
uobiajeno da se primenjuju u sloju veze podataka u adapterima).

5.2.1 Provere parnosti
Upotreba jednog bita parnosti je moda najjednostavniji oblik otkrivanja greke. Pretpostavite da
informacija koja treba da se poalje, D na slici 5.4, ima d bitova. U parnoj emi parnosti,
poiljalac jednostavno ukljuuje jedan dodatni bit i bira njegovu vrednost tako da ukupan broj
,jedinica" urf+1 bitu (originalna informacija plus bit parnosti) bude paran. Kod neparnih ema
parnosti, vrednost bita parnosti bira se tako da bude neparan broj Jedinica". Na slici 5.5
ilustrovana je parna ema parnosti, sa jednim bitom pamosti smetenim u posebnom polju.
Operacija prijemnika sa jednim bitom pamosti je takode jednostavna. Prijemnik treba samo
da prebroji koliko ima .jedinica" u primljenih d + 1 bitova. Ako se u parnoj emi pamosti
pronae neparan broj bitova koji imaju vrednost I, prijemnik zna da se dogodila najmanje jedna
greka na bitu. Tanije, on zna da se dogodio neki neparan broj greaka na bitovima.
Ali, ta se deava ako se dogodio paran broj greaka na bitovima? Rezultat bi bio
neotkrivena greka. Ako je verovatnoa greaka na bitovima mala fako se za greke moe
pretpostaviti da se dogaaju nezavisno od jednog bita do sledeeg, vero-

225 225 225 225
POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA
5.2 TEHNIKE ZA OTKRIVANJE I ISPRAVLJANJE GREAKA 427 427 427 427

vatnoa viestrukih greaka u paketu bila bi ekstremno mala. U tom sluaju, jedan bit pamosti bi
zadovoljavao, Meutim, merenja su pokazala da se greke javljaju zajedno, u grupama", pre
nego da se dogaaju nezavisno. U uslovima grupnih greaka, verovatnoa neotkrivenih greaka
unutar okvira zatienog pomou pamosti sa jednim bitom moe da se priblii vrednosti od 50
procenata [Spragins 1991}. Jasno je daje potrebna robustnija ema za otkrivanje greaka (i ona
se, na sreu, koristi u praksi). Ali, pre ispitivanja ema za otkrivanje greaka koje se koriste u
praksi, hajde da razmotrimo jednostavnu generalizaciju jednobitne pamosti koja e nam
obezbe-diti uvid u tehnike ispravljanja greaka.
Na slici 5.6 prikazana je dvodimenzionama generalizacija jednobitne eme. par-nosti. U
ovom sluaju, d bitova u D podeljeni su u / vrsta i j kolona. Vrednost par-nosti se rauna za
svaku vrstu i svaku kolonu. Rezultujuih ('+_/+ I I I I bitova pamosti obuhvataju bitove za otkrivanje
greke unutar okvira veze podataka.
Sada pretpostavite da se u originalnih c/bitova informacije pojavila greka jednog bita. Kod
ove dvodimenzionalne eme parnosti, pamost i kolone i vrste koje sadre pogrean bit bie
pogrene. Prijemnik zato moe ne samo da otkrije injenicu da se
dogodila jedna greka, nego i da upotrebi indekse vrste i kolone sa grekama pamosti da bi
stvarno identifikovao oteeni bit i ispravio tu greku! Na slici 5.6 prikazan je primer u kome je
bit sa vrednou 1 na poziciji (2,2) oteen i obrnut na 0 - stoje greka koju prijemnik moe da
otkrije i ispravi. Mada je naa rasprava usredsredena na originalnih d bitova informacije, jedna
greka u samim bitovima pamosti takoe se moe otkriti i ispraviti. Dvodimenzionalna pamost
takoe moe da otkrije (ali ne i da ispravi!) bilo kakvu kombinaciju dve greke u paketu. Ostale
osobine dvodimenzionalne eme pamosti ispitane su u problemima na kraju poglavlju.
Sposobnost prijemnika da otkrije i da ispravi greke poznata je kao ispravljanje greaka
unapred (forward error correction, FEC). Ove tehnike se obino koriste za skladitenje zvuka i
reprodukciju sa ureaja kao to su audio CD-ovi. U formiranju mrea, tehnike FEC mogu da se
upotrebe same po sebi, ili zajedno sa tehnikama ARQ koje smo izloili u poglavlju 3. Vrednost
tehnika FEC je to one mogu da smanje broj ponovnih prenosa od strane poiljaoca. Stoje
moda jo vanije, one dozvoljavaju trenutno ispravljanje greaka u prijemniku. Time se
izbegava ekanje u toku vremena povratnog puta, koje je prijemniku potrebno da bi primio
NAK paket i da bi paket koji je ponovo poslat stigao do prijemnika - to moe da bude znaajna
prednost za aplikacije mrea u realnom vremenu [Rubenstcin 1998], Noviji radovi koji ispituju
upotrebu tehnike FEC u protokolima sa kontrolom greke obuhvataju [Miersack 1992;
Nonnenmacher 1998; Byers 1998; Shacham 1990],

5.2.2 Metode kontrolnog zbira
U tehnikama kontrolnog zbira, sa dbitova sa slike 5.4 postupa se kao sa sekvencom ^-bitnih
celih brojeva. Jednostavna metoda kontrolnog zbira je da se prosto saberu ti /r-bitni celi brojevi i
bitovi rezultata upotrebe za otkrivanje greke. Takozvani Internet kontrolni zbir zasniva se na
ovom pristupu - sa bajtovima podataka postupa se kao sa 16-bitnim celim brojevima i oni se
sabiraju. Jedinini komplement ovog zbira formira Internet kontrolni zbir koji se prenosi u
zaglavlju segmenta. Kao Stoje objanjezno u odeljku 3.3, prijemnik proverava kontrolni zbir
tako to uzima jedinini komplement zbira primljenih podataka (ukljuujui tu i sam kontrolni
zbir) i ispituje da li su svi bitovi rezultata 1. Ako bilo koji bit ima vrednost 0, to ukazuje na
greku. RFC 1071 detaljno objanjava Internet algoritam kontrolnog zbira i njegovu
implementaciju. U protokolima TCP i UDP, Internet kontrolni zbir se proraunava preko svih
polja (ukljuujui zaglavlja i polja sa podacima). U drugim protokolima, na primer XTP
[Strayer 1992], jedan kontrolni zbir se rauna za zaglavlje, a drugi za ceo paket.
Metode kontrolnog zbira zahtevaju relativno malo proirivanje paketa u vidu dodavanja
novih bitova. Na primer, kontrolni zbirovi za TCP i UDP koriste samo 16 bitova. Meutim, oni
obezbeuju relativno slabu zatitu od greaka u poreenju sa ciklinim prbverama
redundantnosti (CRC), koje se objanjavaju dalje u tekstu i koje se esto koriste u sloju veze
podataka. Ovde se prirodno postavlja pitanje: zalo se kontrolni zbir koristi u transportnom
sloju, a CRC u sloju veze podataka? Setite

428 POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA
5.2 . TEHNIKE ZA OTKRIVANJE I ISPRAVLJANJE GREAKA
429
i
se da se transportni sloj obino implementira u softveru raunara, kao deo njegovog operativnog
sistema. S obzirom na to daje otkrivanje greaka transportnog sloja implementirano u softveru,
vano je da ema za otkrivanje greaka bude jednostavna i brza, ba kao stoje to metoda
kontrolnog zbira. S druge strane, otkrivanje greaka u sloju veze podataka implementirano je u
hardveru adaptera, koji brzo moe da izvri i sloenije CRC operacije.
Osnovni razlog zbog kojeg se kontrolni zbir koristi u transportnom sloju, a jae metode
CRC u sloju linka je to se kontrolno sabiranje lako implementira u softveru.
McAulev [McAulev 1994] opisuje poboljane kodove teinskog kontrolnog zbira koji su
pogodni za softverske implementacije velike brzine, a Feldheimer [Feldheimer 1995] prikazuje
tehnike brzih softverskih implementacija, ne samo za kodove teinskog kontrolnog zbira, nego i
za CRC (proitajte dalje u tekstu), kao i za druge kodove.

5.2.3 Ciklina provera redundantnosti (CRC)
Tehnika koja se danas iroko koristi u raunarskim mreama zasnovana je na kodovima sa
ciklinom proverom redundantnosti (CRC). CRC kodovi su takode poznati kao polinomski
kodovi, zato to se na niz bitova koji treba da se poalju moe gledati kao na polinom iji
koeficijenti imaju vrednosti 0 i 1 u tom nizu, sa operacijama koje se interpretiraju kao
polinomska aritmetika nad nizom bitova.
CRC kodovi rade na sledei nain. Zamislite o'-bitni podatak, D, koji predajni vor eli da
poalje prijemnom voru. Poiljalac i primalac moraju prvo da se spo-razumeju o uzorku od r +
1 bita, poznatom kao generator, koji emo oznaiti sa G. Zah'tevaemo da bit najvee teine
(krajnji levi) u G bude 1. Kljuna ideja na kojoj se zasniva CRC prikazana je na slici 5.7. Za dati
podatak, D, poiljalac e odabrati r dodatnih bitova, R , i prikljuiti ih na kraj niza D tako da
rezultujui uzorak d + r (interpretiran kao binarni broj) bude tano deljiv sa G koristei
aritmetiku modulo 2. Na ovaj nain, proces proveravanja greaka je jednostavan: primalac deli
primljeni d + r sa G. Ako ostatak nije nula, primalac zna da se dogodila greka; u suprotnom,
podatak se prihvata kao ispravan.
Sva CRC izraunavanja vre se u aritmetici modulo 2, bez prenosa u sabiranju ili
pozajmljivanja u oduzimanju. To znai da su sabiranje i oduzimanje identini i da su oba
ekvivalentni bitskom operandu iskljuivom ILI (XOR). Na primer,
1011 XOR 0101 = 1110 1001 XOR
1101 = 0100 Takoe, slino tome
1011 - 0101 = 1110 1001 - 1101 =
0100
Mnoenje i deljenje su isti kao u aritmetici sa osnovom 2, izuzev to se sva zahtevana sabiranja
ili oduzimanja vre bez prenosa i pozajmljivanja. Kao u obinoj binarnoj aritmetici, mnoenje sa
2
k
pomera bitove u levo za k mesta. Dakle, uz date D i R, izraz D 2
r
XOR R daje bitove d + r
prikazane na slici 5.7. U naoj daljoj diskusiji, koristiemo ovu algebarsku karakterizaciju bitova
d + r.
Okrenimo se sada odluujuem pitanju, kako poiljalac proraunava R. Setite se da elimo
da pronaemo R , tako da postoji takvo n da je

D -2
r
XOR R = nG

To znai, elimo da odaberemo R koje G deli sa> 2
r
XORtf bez ostatka. Ako izvrimo
iskljuivo-ILI (odnosno, saberemo po modulu 2 bez prenosa) R sa obe strane gornje jednaine,
dobijamo

D- 2 ' =n GX ORR

Ova jednaina nam govori da ako podelimo D 2
r
sa G, vrednost ostatka je tano R. Drugim
recima, moemo da izraunamo R na sledei nain
D- 2
r
R =
ostatak od q

Na slici 5.8 prikazanje ovaj proraun za sluaj D = 101110, d =6 , G = 1001 i r= 3. Devet
bitova koji se prenose u ovom sluaju su 101110011. Moete daprove-rite ovaj proraun, a
takoe da se uverite da je D 2
r
= 101011 G XOR R.
Definisani su meunarodni standardi za 8-, 12-, 16- i 32-bitne generatore, G. S-bitni CRC
se koristi da zatiti 5-bajtno zaglavlje u ATM elijama. 32-bitni standard CRC-32, koji je
usvojen u brojnim IEEE protokolima sloja linka, koristi generator

G
CRC-32
=
100000100110000010001110110110111

227 227 227 227
431 5.3 PROTOKOLI VIESTRUKOG PRISTUPA

Svaki od CRC standarda moe da otkrije grupu greaka koja se javlja na manje od r + 1
bitova. (To znai da sve uzastopne greke bitova na rastojanju / ili manje bitova mogu da se
otkriju.) Pored toga, pod odgovarajuim pretpostavkama, grupna greka vea od r + 1 bitova
moe da se otkrije sa verovatnoom od 1 - 0,5
r
. Takoe, svaki od CRC standarda moe da otkrije
svaki neparan broj greaka bitova. U tekstu [Schv/artz 1908], dat je odlian uvod u ovu temu.
5. 3 Protokoli viestrukog pristupa
U uvodu ovog poglavlja, napisali smo da postoje dve vrste mrenih linkova: linkovi od take do
take i difuzni linkovi. Link od take do take sastoji se od jednog poiljaoca najednom kraju
linka, i jednog primaoca na drugom kraju linka. Mnogi protokoli sloja linka projektovani su kao
linkoviod take do take; PPP {point-to-po-int protocol) i HDLC su dva takva protokola, koja
emo objasniti kasnije u ovom poglavlju. Druga vrsta linka, difuzni link, moe da ima vie
predajnih i vie prijemnih vorova koji svi dele jedan, isti difuzni kanal. Termin difuzni" ovde
se koristi zato to, kada bilo koji vor alje okvir, kanal difuzno prenosi okvir i svaki vor prima
kopiju. Primeri za tehnologije difuznog sloja linka su Ethernet i beini LAN-ovi. U ovom
odeljku emo se vratiti korak unazad od specifinih protokola sloja linka i prvo ispitati problem
koji je najznaajniji za sloj veze podataka: kako da se uskladi pristup vie predajnih i prijemnih
vorova deljenom difuznom kanalu
- takozvani problem viestrukog pristupa. Difuzni kanali se esto koriste u lokalnim
raunarskim mreama (LAN-ovima), mreama koje su geografski koncen-trisane u jednoj
zgradi (ili korporaciji ili univerzitetskom naselju). Zato emo na kraju ovog poglavlja takoe
videti kako se kanali sa viestrukim pristupom koriste u LAN-ovima.
Nama je svima poznato znaenje difuznog prenosa, zato to ga televizija koristi od kada je
pronaena. Ali, tradicionalna televizija je jednosmemi difuzni prenos (odnosno, jedan fiksni
vor prenosi mnogim prijemnim vorovima), dok vorovi na difuznom kanalu raunarske mree
mogu i da predaju i da primaju. Pogodnija analogija difuznog kanala je koktel prijem, gde se
mnogo ljudi skuplja u velikoj prostoriji (vazduh je difuzni medijum), da bi priali i sluali.
Druga dobra analogija je neto sa ime bi mnogi itaoci trebalo da budu upoznati - uionica gde
nastavnik (nastavnici) i student (studenti) takoe dele jedan difuzni medijum. Centralni problem
u oba scenarija je da se odredi ko i kada pria (odnosno predaje na kanal). Kao ljudi, mi smo
razradili skup protokola za deljenje difuznog kanala:
Dajte svakom priliku da govori." Ne priajte
kada vam se obraaju." Ne monopoliite
razgovor." Podignite ruku kada imate pitanje."
Ne prekidajte nekoga kada govori." Nemojte
zaspati kada neko govori."
Raunarske mree imaju sline protokole - to su takozvani protokoli viestrukog pristupa -
pomou kojih vorovi reguliu svoj prenos na deljenom difuznom kanalu. Kao stoje prikazano
na slici 5.9, protokoli sa viestrukim pristupom su potrebni u irokom skupu postavki mrea,
ukljuujui tu oiene i beine lokalne mree raunara, kao i satelitske mree. Mada, tehniki
posmatrano, svaki vor pristupa difuznom kanalu preko svog adaptera, u ovom odeljku mi emo
se pozivati na vor kao na predajni i prijemni ureaj. U praksi, stotine ili ak hiljade vorova
mogu direktno da komuniciraju preko difuznog kanala.
S obzirom na to da su svi vorovi u stanju da alju okvire, to vie od dva vora mogu da
rade istovremeno. Kada se to dogodi, svi vorovi primaju vie okvira u isto vreme; znai da
dolazi do kolizije okvira u prenosu, na svim primaocima. Obino se deava da, kada postoji
kolizija, nijedan od prijemnih vorova ne moe da uradi sa poslatim okvirima nita to bi imalo
smisla; signali okvira u koliziji postaju meusobno nerazumljivo zamreni. Zato su svi okviri u
koliziji izgubljeni, a difuzni kanal neupotrebljiv u vremenskom intervalu kolizija. Jasno je da,
ako mnogo vorova eli esto da predaje okvire, mnogi prenosi e za rezultat imati kolizije i
veliki deo propusnog opsega difuznog kanala e biti neiskorien.

432 432 432 432
228 228 228 228
5.3 * PROTOKOLI VIESTRUKOG PRISTUPA

Da bi se obezbedilo da difuzni kanal korisno radi kada je aktivno vie vorova, potrebno je
da se nekako usklade prenosi aktivnih vorova. To je posao protokola sa viestrukim pristupom.
U toku 30 godina, hiljade lanaka i stotine doktorskih disertacija napisano je o protokolima sa
viestrukim pristupom; iscrpan pregled ovog rada dat je u [Rom 1990]. tavie, aktivno
istraivanje u oblasti protokola sa viestrukim pristupom se nastavlja, zahvaljujui stalnom
pojavljivanju novih vrsta linkova, posebno novih beinih linkova.
Tokom godina, implemetirano je vie desetina protokola sa viestrukim pristupom u
razliitim tehnologijama sloja linka. Meutim, skoro svaki protokol sa viestrukim pristupom
moemo klasifikovati da pripada jednoj od sledee tri kategorije: protokoli sa deljenjem
kanala, protokoli sa sluajnim pristupom i protokoli sa pristupom na koga je red". U
sledea tri pododeljka objasniemo ove kategorije protokola sa viestrukim pristupom.
Zakljuiemo ovaj pregled time da bi, u idealnom sluaju, protokol sa viestrukim
pristupom za difuzni kanal brzine R bitova u sekundi, trebalo da ima sledee karakteristike:
1. Kada samo jedan vor ima podatke za slanje, on ima propusnu mo od R bitova u
sekundi.
2. Kada Mvorova imaju podatke za slanje, svaki od njih ima propusnu mo od R/M bitova
u sekundi. To ne znai da svaki od M vorova obavezno uvek ima brzinu prenosa od
R/M, nego da bi svaki od M vorova trebalo da ima brzinu prenosa od R/M u nekom
pogodno defmisanom vremenskom intervalu.
3. Protokol je decentralizovan; to znai, da nema centralnih vorova koji mogu da otkazu i
obore ceo sistem. y
4. Protokol je jednostavan, tako da nije skup za implementaciju.

5.3.1 Protokoli sa deljenjem kanala
Setite se ranijih objanjenja u odeljku 1.3 da su vremensko (time-division multiple-xing, TDM) i
frekventno muttipleksiranje (frequency-divison mtdtiplexing, FDM) dve tehnike koje mogu da se
koriste za deljenje propusnog opsega difuznog kanala izmeu svih vorova koji dele taj kanal.
Kao primer, pretpostavite da kanal podrava N vorova i da je brzina prenosa kanala R bitova u
sekundi. TDM deli vreme na vremenske okvire (time frames), a dalje deli svaki vremenski
okvir na N vremenskih odseaka (Ume siots). (Vremenski prozor TDM ne bi trebalo da se
pomea sa PDU-om sloja linka, koji se takoe naziva okvir. Da bi se smanjila mogunost
zabune, u ovom pododeljku na PDU sloja linka emo se pozivati kao na paket.) Svaki vremenski
odseak se onda dodeljuje jednom od N vorova. Kad god vor ima paket koji treba da poalje,
on vri predaju bitova paketa za vreme svog dodeljenog vremenskog odseka koji se aktivira
tokom rotirajueg TDM prozora, Uobiajeno je da se veliine vremenskih odseaka biraju tako
da jedan paket moe da se prenese u okviru jednog vremenskog odseka. Na slici 5.10 prikazan
je jednostavan primer TDM-a od etiri vora. Ako se vratimo na nau analogiju, koktel prijem
regulisan pomou TDM-a dozvolio bi jednom uesniku da govori u fiksnom vremenskom
periodu, a zatim drugom uesniku da govori jednako dugo i tako dalje. Kada su svi imali svoju
priliku da govore, postupak se ponavlja.
Tehnika TDM je privlana, zato to eliminie kolizije i savreno je pravedna: svaki vor
ima brzinu R tokom korienja svog okvira, a brzinu 0 izvan toga, pa je srednja brzina prenosa
po voru R/N bitova u sekundi za vreme svakog vremenskog okvira. Meutim, ona ima dva
velika nedostatka. Prvo, vor je ogranien na prose-nu brzinu od R/N bitova u sekundi ak i
kada je jedini vor sa paketima za slanje. Drugi nedostatak je to to vor uvek mora da eka na
svoj red u sekvenci prenosa - opet, ak i kada je jedini vor sa paketom za slanje. Zamislite
uesnika na prijemu koji jedini ima neto da kae (i zamislite daje to ak i reda okolnost u kojoj
svako na prijemu eli da uje ta ta jedna osoba ima da kae). Jasno, tehnika TDM bi bila lo
izbor za protokol sa vie pristupa na tom odreenom prijemu.

229 229 229 229
5.3 PROTOKOLI VIESTRUKOG PRISTUPA 435 435 435 435

Dok TDM deli difuzni kanal u vremenu, FDM deli kanal brzine R bitova u sekundi na
razliite frekvencije (od kojih svaka ima propusni opseg od R/N) i dodeljuje svaku frekvenciju
jednom od /V vorova. FDM tako stvara N manjih kanala od R/N bitova u sekundi od jednog,
veeg kanala brzine od R bitova u sekundi. FDM deli i prednosti i nedostatke TDM-a. FDM
takode deli glavni nedostatak sa TDM-om - vor je ogranien na propusni opseg od R/N, ak i
kada je jedini vor sa paketom za slanje.
Trei protokol za deljenje kanala je viestruki pristup sa deljenjem koda
(Code Division Multiple Access, CDMA). Dok TDM i FDM dodeljuju vorovima vremenske
odseke i frekvencije, respektivno, CDMA svakom voru dodeljuje razliit kod. Svaki vor
onda.koristi jedinstveni kod da bi kodovao bitove podataka koje alje. Ako se kodovi paljivo
izaberu, mree CDMA imaju izvanrednu osobinu da razliiti vorovi mogu da prenose
istovremeno, a da njihovi odgovarajui primaoci ipak tano prime bitove kodovanih podataka
(pretpostavljajui da primalac zna kod poiljaoca), uprkos uticaju prenosa drugih vorova.
Izvesno vreme CDMA se koristio u vojnim sistemima (zbog svoje otpornosti na ometanje), a
sada poinje da se iroko nalazi i u civilnoj upotrebi, posebno u beinim kanalima sa
viestrukim pristupom. S obzirom daje upotreba CDMA tako tesno povezana sa beinim kana-
lima, uzdraemo se od diskusije o tehnikim detaljima CDMA do poglavlja 6. Za sada, bie
dovoljno da znamo da CDMA kodovi, kao vremenski odseci u TDM-u i frekvencije u FDM-u,
mogu da se dodeljuju korisnicima kanala sa viestrukim pristupom..
5.3.2 Protokoli.sa sluajnim pristupom
Druga iroka klasa protokola sa viestrukim pristupom su takozvani protokoli sa sluajnim
pristupom. U protokolu sa sluajnim pristupom, predajni vor uvek predaje punom brzinom
kanala, odnosno R bitova u sekundi. Kada postoji kolizija, svaki vor koji je njime obuhvaen
ponovo alje svoj okvir (odnosno paket), sve dok okvir ne proe bez kolizija. Ali, kada vor
doivi koliziju, on ne alje ponovo okvir istog trenutka. Umesto toga, on eka da proe vreme
sluajnog trajanja dok ponovo ne poalje okvir. Svaki vor obuhvaen kolizijom bira nezavisno
sluajno kanjenje. S obzirom na to da se sluajna kanjenja biraju nezavisno, mogue je da e
jedan od vorova odabrati kanjenje koje je dovoljno manje od kanjenja ostalih vorova u
koliziji i da e zato moi da provue svoj okvir kroz kanal bez kolizije.
Postoje desetine, ako ne i stotine protokola sa sluajnim pristupom koji su opisani u
literaturi [Rom 1990; Bertsekas 1991], U ovom odeljku, opisaemo nekoliko protokola sa
sluajnim pristupom koji se najvie koriste - protokole ALOHA [Abramson 1970; Abramson
1985] i protokole sa prepoznavanjem nosioca sa sluajnim pristupom (carrier sense multiple
access, CSMA) [Kleinrock 1975b]. Kasnije, u odeljku 5.5, objasniemo detalje Ethemeta
[Metcalfe 1976], popularnog i iroko primenjivanog CSMA protokola.

ALOHA sa odsccima
Hajde da zaponemo nau studiju protokola sa sluajnim pristupom sa jednim od
najjednostavnijih, takozvanim protokolom ALOHA sa odsecima. U naem opisu ALOHE sa
odsecima, pretpostaviemo sledee:
Svi okviri se sastoje od tano L bitova.
Vreme se deli na odseke veliine L/R sekundi (odnosno, odseak je jednak vremenu
prenosa jednog okvira).
vorovi poinju da predaju okvire samo na poecima odseaka.
vorovi su sinhronizovani, tako da svaki od njih zna kada odseak poinje.
Ako dode do kolizije dva ili vie okvira u odseku, svi vorovi detektuju koliziju pre nego
to se odseak zavri.
Neka je p verovatnoa, odnosno broj izmeu 0 i 1. Operacija ALOHE sa odsecima u svakom
voru je jednostavna:
Kada vor treba da poalje novi okvir, on eka do poetka sledeeg odseka i predaje
celokupni okvir tom odseku.
Ako nema kolizije, vor je uspeno predao svoj okvir i zato ne treba da razmatra njegovo
ponovno prenoenje. (vor moe da pripremi novi okvir za prenos u sledeem okviru, ako
ga ima.)

5.3 PROTOKOLI VIESTRUKOG PRISTUPA
230 230 230 230

Ako postoji kolizija, vor je detektuje pre kraja odseka. vor ponovo predaje svoj okvir u
svakom sledeem odseku sa verovatnoom p dok se okvir ne prenese bez kolizije.
Pod ponovnim prenoenjem sa verovatnoom p, podrazumevamo da vor u stvari baca
novi sa sledeim ishodima: dogaaj glava" odgovara ponovnom pre-nosu i ima verovatnou
p. Dogaaj pismo" znai preskoi odseak i baci novi ponovo u sledeem odseku"; to se
deava sa verovatnoom (1 - p). Svi vorovi obuhvaeni kolizijom bacaju svoje novie
nezavisno.
Izgleda da ALOHA sa odsecima ima mnogo prednosti. Za razliku od deljenja kanala,
ALOHA sa odsecima dozvoljava voru da stalno predaje punom brzinom, R, kadaje taj vor
jedini aktivan. (Za vor kaemo daje aktivan kada ima okvira za slanje.) Protokol ALOHA sa
odsecima je i veoma decentralizovan, zato to svaki vor detektuje kolizije i nezavisno odluuje
kada da ponovi predaju. (Meutim, ALOHA sa odsecima zahteva da odseci budu
sinhronizovani u vorovima; uskoro emo objasniti verziju protokola ALOHA bez odseaka, kao
i protokole CSMA, od kojih nijedan ne zahteva takvu sinhronizaciju i zato su potpuno
decentralizovani.) ALOHA sa odsecima je takode izuzetno jednostavan protokol.
Protokol ALOHA sa odsecima dobro radi kada postoji samo jedan aktivan vor, ali koliko
je on jednostavan kada ima vie aktivnih vorova? U vezi sa efikasnou moe se razmiljati o
dve stvari. Prvo, kao stoje prikazano na slici 5.11, kada ima vie aktivnih vorova, izvestan deo
odseaka e biti u koliziji i zato e biti odbaen". Drugi problem je to e drugi deo odseaka
biti prazan, zato to se svi aktivni vorovi uzdravaju od prenosa zbog probabilistike politike
prenosa. Jedini iskorieni" odseci e biti oni u kojima tano jedan vor predaje. Odseak u
kome samo jedan vor predaje zove se odseak uspeha. Efikasnost protokola sa viestrukim
pristupom i odsecima definie se kao deo odseaka uspeha tokom dugog perioda, u sluaju kada
postoji veliki broj aktivnih vorova, od kojih svaki ima veliki broj okvira za slanje. Zapazite da
bi, ako nije upotrebljen nikakav oblik kontrole pristupa i ako bi svaki vor odmah ponovo
prenosio posle svake kolizije, efikasnost bila ravna nuli. Jasno je da ALOHA sa odsecima
poveava efikasnost iznad nule, ali koliko?
Sada emo nastaviti sa izvoenjem maksimalne efikasnosti protokola ALOHA sa
odsecima. Da bi ovo izvoenje bilo jednostavno, hajde da malo promenimo protokol i
pretpostavimo da svaki vor uvek ima okvir za slanje i da vor predaje novi okvir sa
verovatnoom p. (To znai da pretpostavljamo da svaki vor uvek ima okvir za slanje i da vor
alje novi okvir sa verovatnoom p, kao i okvir koji je ve u koliziji.) Najpre pretpostavite da
postoji N vorova. Tada je verovatnoa da dati odseak predstavlja odseak uspeha jednaka
verovatnoi da jedan od vorova predaje, a da ostalih N - 1 vorova ne predaju. Verovatnoa da
jedan vor predaje je p; verovatnoa da ostali vorovi ne predaju je (l - p)
N
'
!
. Zato je verovatnoa
da je odseak uspean jednaka p( 1 - p)
N
'
}
. S obzirom na to da ima N vorova, verovatnoa da
neki proizvoljan vor obavi uspean prenos iznosi Np(l - p )
N
~ ' '
Dakle, kada postoji N aktivnih vorova, efikasnost protokola ALOHA sa odsecima jednaka
je A^(l - p f - >. Da bi se dobila maksimalna efikasnost za N aktivnih vorova, treba da
pronaemokoje maksimizuje taj izraz. (Pogledajte probleme za domae zadatke u kojima je
opisan opti postupak tog izvoenja.) A da bismo dobili maksimalnu efikasnost za veliki broj
aktivnih vorova, uzeemo granicu N p\\ -p')
N
-' kada se N pribliava beskonanosti. (I to
pogledajte u problemima za domae zadatke.) Kada izvrimo te proraune, otkriemo daje
maksimalna efikasnost protokola data izrazom l/e = 0,37. To znai da, kada veliki broj vorova
ima mnogo okvira za predaju, onda (u najboljem sluaju) samo 37% vorova radi neto korisno.
Dakle, efektivna brzina prenosa kanala nije R, nego samo 0,37 R bitova u sekundi! Slina analiza
takoe pokazuje daje 37 procenata odseaka prazno i da se u 26 procenata odseaka javljaju
kolizije. Zamislite sirotog administratora mree koji je kupio sistem ALOHA sa odsecima, od
100 Mb/s, oekujui da e moi da koristi mreu za prenoenje podataka izmeu velikog broja
korisnika zajednikom brzinom od, recimo, 80 Mb/s! Iako kanal moe da prenosi dati okvir
punom brzinom od 100 Mb/s, u duem vremenu realna propusna mo tog kanala e biti manja od
37 Mb/s u sekundi.

POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNEMREE RAUNARA 5.3 PROTOKOLI VIESTRUKOG PRISTUPA 231 231 231 231

438 438 438 438
j
i
ALOHA
Protokol ALOHA sa odsecima zahteva da svi vorovi sinhronizuju svoje prenose tako da
zaponu na poetku odseka. Prvi protokol ALOHA [Abramson 1970] bio je stvarno bez
odseaka, potpuno decentralizovan protokol. U takozvanoj istoj ALOHI, kada okvir stigne prvi
put (odnosno, mreni sloj prosledi datagram nanie iz mrenog sloja u vor poiljaoca), vor
odmah predaje ceo okvir na difuzni kanal. Ako predati okvir dode u koliziju sa jednim ili vie
prenosa, vor e odmah (poto je predao ceo svoj okvir u koliziji) ponovo predati okvir sa
verovatnoom p. U suprotnom, vor eka u intervalu koji je jednak vremenu potrebnom za
prenos jednog okvira. Posle tog ekanja, on predaje okvir sa verovatnoom p , ili eka (ostajui
besposlen) na drugi okvir sa verovatnoom (l-/>).
Da bismo odredili efikasnost iste ALOHE, usredsrediemo se na jedan individualni vor.
Napraviemo iste pretpostavke kao i u naoj analizi ALOHE sa odsecima i uzeemo da vreme
prenosa okvira bude jedinica vremena. U bilo kom datom trenutku, verovatnoa da vor prenosi
okvir je p. Pretpostavimo da prenos tog okvira poinje u trenutku tQ. Kao Stoje prikazano na slici
5.12, da bi prenos tog okvira bio uspean, nijedan drugi okvir ne moe da zapone svoj prenos u
intervalu vremena [t0 - 1, t0]. Takav prenos bi se preklopio sa poetkom prenosa okvira /-tog
vora. Verovatnoa da nijedan drugi ne poinje prenos u tom intervalu je (1 - p)'
v
~'. Slino tome,
nijedan drugi vor ne moe da pone prenos dok vor i prenosi, jer bi se takav prenos preklopio
sa krajem prenosa /-tog vora. Verovatnoa da nijedan od svih drugih vorova ne poinje prenos
u tom intervalu je takoe (1 - p)
N
~'. Prema tome, verovatnoa da dati vor izvri uspean prenos
je /?(1 - p)^
N
'
!
K Izraunavanjem granice kao u sluaju ALOHE sa odsecima, dolazimo do toga
daje efikasnost iste ALOHE samo l/(2e) - tano polovina one koju ima ALOHA sa odsecima.
To je cena koja mora da se plati za potpuno decentralizovani protokol ALOHA.
KRATAK OSVRT
NORM ABRAMSON I ALOHANET
Dr Norm Abramson, inenjer, strasno je voleo jahanje na talasima i interesovala ga je
komutacija paketa. Ta kombinacija interesovanja dovela ga je na Univerzitet na Havajimo
1969. godine. Havaji se sastoje od mnogo planinskih ostrva, to oteava postavljanje i rad
zemaljskih mreo. Kada ne bi jahao na talasima, Abramson je razmiljao kako da projekfuje
mreu koja bi vrila komutaciju paketa preko radija. Mrea koju je projekfovao imala je jedan
centralni raunar i vie sekundarnih vorova, razbacanih po Havajskim ostrvima. Mrea je
imala dva kanala, od kojih je svaki koristio razliit frekventni opseg. Kanal za predaju nanie je
difuzno predavao pakete iz centralnog raunara do sekundarnih vorova; kanal za predaju
navie je slao pakete iz sekundarnih raunara u centralni raunar. Pored predaje informa-cionih
paketa, centralni raunar je kanalom za predaju nanie lakoe slao i potvrdu za svaki paket koji
je uspeno primio tz sekundarnih raunara.
S obzirom na to da su sekundarni raunari slali pakete na decentralizovan nain, neizbeno
je dolazilo do kolizija na kanalu za predaju navie. To posmatranje je dovelo Abramsona do
izuma istog protokola ALOHA, kao to je opisano u ovom poglavlju. Godine 1970. uz trajnu
podrku ARPA-e, Abramson je povezao svoju mreu ALOHAner so mreom ARPAnet.
Abramsonov rad znaajan je ne samo zato io je to bio prvi primer radiomree sa komutacijom
paketa, nego i zato to je nadahnuo Boba Metkalfa. Nekoliko godina poto ga je Abramson
izmislio, Metkalf je modifikovao protokol ALOHA, i toko su nastali protokol CSMA/CD i LAN
Ethernet.
CSMA - sluajan pristup sa prepoznavanjem nosioca
U oba protokola ALOHA, u onom sa odsecima kao i u onom bez njih, odluka vora da predaje
donosi se nezavisno od aktivnosti drugih vorova prikljuenih na difuzni kanal. Posebno, vor
nikada ne obraa panju na to da li neki drugi vor predaje kad on poinje sa predajom, niti
zaustavlja predaju ako drugi vor poinje da ga ometa svojom predajom. U naoj analogiji sa
koktel prijemom, protokoli ALOHA su kao dosadan uesnik na prijemu koji nastavlja da brblja
bez obzira na to da li drugi ljudi neto govore. Kao ljudi, mi imamo ljudske protokole koji nam
omoguavaju ne samo da se ponaamo civilizovanije, nego i da smanjimo vreme koje
provodimo ,,u kolizijama" meusobno u svojim razgovorima i, shodno tome, da poveamo
vreme u kome stvarno razgovaramo. Posebno, postoje dva vana pravila za voenje uljudnog
razgovora:
Sluaj pre nego to progovori. Ako neki drugi govore, saekaj dok oni zavre. U mrenom
svetu, to se zove prepoznavanje nosioca (carrier sensing) - vor slua kanal pre nego to
predaje. Ako se okvir iz drugog vora trenutno prenosi

5.3 - PROTOKOLI VIESTRUKOG PRISTUPA 441 441 441 441

po kanalu, vor onda eka (odstupa") sluajno vreme, a zatim opet slua kanal. Ako oseti da je
kanal slobodan, vor poinje sa predajom okvira. U suprotnom, vor eka drugo sluajno vreme
i zatim ponavlja ovaj proces. Ako neko pone da govori u isto vreme, prekini da govori. U
mrenom svetu, to se zove otkrivanje kolizija (collision detection) - vor koji predaje
istovremeno slua kanal. Ako otkrije da drugi vor predaje okvir koji ga ometa, on zaustavlja
predaju i koristi neki protokol da odredi kada bi sledei put trebalo da pokua da predaje.
Ova dva pravila ugraena su u familiju protokola CSMA (carrier sense multiple access,
otkrivanje nosioca sa sluajnim pristupom) i CSMA/CD (CSMA sa otkrivanjem kolizija)
[Kleinrock 1975b; Metcalfe 1976; Lam 1980; Rom 1990], Predloene su mnoge varijacije
CSMA i CSMA/CD. italac moe da proita tri reference radi detaljnijih informacija o ovim
protokolima. Mi emo u odeljku 5.5 detaljno prouiti emu CSMA/CD koja se koristi u
Ethernetu. Ovde emo razmotriti najvanije i osnovne karakteristike protokola CSMA i
CSMA/CD.
Prvo pitanje koje bi se moglo postaviti o protokolu CSMA glasi: Ako svi vorovi izvravaju
prepoznavanje nosioca, zato uopte dolazi do kolizija? Na kraju krajeva, vor e odustati od
predaje kad god oseti da neki drugi vor predaje. Odgovor na to pitanje moe najbolje da se
ilustruje upotrebom prostorno-vremenskih dijagrama [Molle 1987], Na slici 5.13 prikazanje
prostorno-vremenski dijagram etiri vora (A, B, C, D) koji su prikljueni na linearnu difuznu
magistralu. Horizontalna osa prikazuje poloaj svakog vora u prostoru. Vertikalna osa prikazuje
vreme.
U trenutku t0, vor B osea da je kanal slobodan, jer nijedan drugi vor trenutno ne predaje.
Zato vor B poinje sa predajom, a njegovi bitovi se propagiraju u oba pravca po difuznom
medijumu. Propagacija nanie bitova sa vora B na slici 5.13, sa porastom vremena pokazuje
daje potrebno vreme vee od nule da bi zaista bilo propagacije bitova B (iako skoro brzinom
svetlosti) du difuznog medijuma. U trenutku /, ( t l > tQ), vor D ima okvir za slanje. Mada vor
B u trenutku /, predaje, bitovi koje predaje B jo nisu stigli do D, pa zato D osea kanal kao
slobodan. U skladu sa protokolom CSMA, D zato poinje da predaje svoj okvir. Kratko vreme
posle toga, predaja vora B poinje da ometa predaju D na poloaju D. Na slici 5.15 jasno se
vidi da e kanjenje usled propagacije po kanalu od kraja do kraja difuznog kanala - vreme koje
je potrebno da se signal prostire od jednog do drugog vora - imati odluujuu ulogu u
odreivanju njegove performanse. to je kanjenje propagacije vee, to je vea verovatnoa da
vor koji otkriva nosioca nee moi da oseti predaju koja je ve poela u drugom voru mree.
Na slici 5.13, vorovi ne otkrivaju kolizije; i B i D nastavljaju da predaju svoje okvire u
celini, ak iako se dogodila kolizija. Kada vor otkriva koliziju, on prekida prenos im otkrije
koliziju. Na slici 5.14 prikazanje isti scenario kao na slici 5.13, izuzev to oba vora obustavljaju
svoje prenose odmah posle otkrivanja kolizija.
Jasno je da e dodavanje otkrivanja kolizija protokolu sa viestrukim pristupom poboljati
performansu protokola time to se nee prenositi beskoristan (ometanjem okvirom drugog
vora) oteen okvir u celini. Protokol Ethernet koji emo prouiti u odeljku 5.5 je CSMA
protokol koji koristi otkrivanje kolizija.

442 442 442 442
POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA 5.3 PROTOKOLI VIESTRUKOG PRISTUPA 443 443 443 443

5.3.3 Protokoli tipa na koga je red"
Setite se da su dve poeljne osobine protokola sa viestrukim pristupom da (1) kada je samo
jedan vor aktivan, on ima propusnu mo od R bitova u sekundi i (2) kada je M vorova aktivno,
onda svaki vor ima propusnu mo od skoro R/M bitova u sekundi. Protokoli ALOHA i CSMA
imaju prvu osobinu, ali ne i drugu. To je moti-visalo istraivae da stvore drugu klasu protokola -
protokole tipa na koga je red" {laking-tumsprolocol.i). Kao kod protokola sa sluajnim
pristupom, postoje na desetine protokola sa ovakvim pristupom i svaki od njih ima mnogo
varijacija. Ovde emo objasniti dva od najvanijih protokola. Prvi je protokol sa prozivanjem.
Pro-
tokol sa prozivanjem zahteva da jedan od vorova bude oznaen kao glavni. Glavni vor
proziva svaki od vorova na kruni nain. Preciznije, glavni vor prvo alje poruku voru 1,
kojom mu kae da moe da predaje do nekog maksimalnog broja okvira. Kada vor 1 prenese
nekoliko okvira, glavni vor saoptava voru 2 da sada on moe da prenese do nekog
maksimalnog broja okvira. (Glavni vor moe da odredi kada je vor zavrio sa slanjem svojih
okvira posmatrajui nedostatak signala na kanalu.) Postupak se nastavlja, tako to glavni vor
proziva svaki od vorova na ciklian nain.
Protokol sa prozivanjem odstranjuje kolizije i prazne odseke od kojih pate protokoli sa
sluajnim pristupom. To omoguava mnogo veu efikasnost. Ali, on takoe ima i nekoliko
nedostataka. Prvi nedostatak je to to protokol uvodi kanjenje prozivanja - vreme potrebno da
se obavesti svaki vor da on moe da predaje. Ako je, na primer, samo jedan vor aktivan, onda
e on prenositi brzinom manjom od R bitova u sekundi, zato to glavni vor mora da prozove
svaki od neaktivnih vorova redom, svaki put kada je aktivni vor poslao svoj maksimalni broj
okvira. Drugi nedostatak, koji je moda ozbiljniji, je to to ako glavni vor otkae, ceo kanal
postaje neopera-tivan.
Drugi protokol sa pristupom na koga je red" je protokol sa prosledivanjem etona
(token passingprotocol). U tom protokolu ne postoji glavni vor. Mali okvir posebne namene
koji se zove eton (token), razmenjuje se izmeu vorova po nekom fiksnom redu. Na primer,
vor 1 bi mogao uvek da alje eton voru 2, vor 2 bi mogao uvek da alje eton voru 3, vor
N bi mogao uvek da alje eton voru 1. Kada vor primi eton, on se na njemu zadrava samo
ako ima okvira za slanje; u suprotnom, on odmah prosleuje eton sledeem voru.
Prosledivanje etona je decentralizovano i ima veliku efikasnost. Ali ni ono nije bez problema.
Na primer, otkaz jednog vora moe da uniti ceo kanal. Ili, ako vor sluajno propusti da oslo-
bodi eton, tada moraju da se pozovu izvesni postupci obnavljanja, kako bi se eton vratio u
cirkulaciju. Tokom godina, razvijeni su mnogi proizvodi za prosledivanje etona i svaki od njih
je pokuavao da rei ovo i druga nezgodna pitanja; dva od tih protokola, FDD1 i IEEE 802.5,
spomenuemo u sledeem odeljku.

5.3.4 Lokalne raunarske mree (LAN-ovi)
Protokoli sa viestrukim pristupom upotrebljavaju se zajedno sa mnogo razliitih vrsta difuznih
kanala. Oni su se koristili za satelitske i beine kanale, iji vorovi su prenosili preko
zajednikog spektra frekvencija. Oni se danas koriste u uzvodnom kanalu za kablovski pristup
Internetu (proitajte odeljak 1,5), a iroko se upotrebljavaju u lokalnim raunarskim mreama
(LAN-ovima).
Setite se:da je LAN raunarska mrea koja je koncentrisana u geografskom podruju, kao
to'je zgrada ili univerzitetsko naselje. Kada korisnik pristupa Internetu iz univerzitetskog ili
korporativnog naselja, pristup je gotovo uvek putem LAN-a. U ovoj vrsti pristupa Internetu,
korisnikov raunar je vor LAN-a, a LAN obezbeduje pristup Internetu preko rutera, kao stoje
prikazano na slici 5.15. Brzina

444 444 444 444 POGLAVLJE 5 SLOJ VEZE PODATAKA l LOKALNE MREE RAUNARA
5.4 . ADRESIRANJE SLOJA LINKA 234

prenosa R veine LAN-ova je veoma velika. ak i poetkom 80-ih godina, bili su uobiajeni
LAN-ovi od 10 Mb/s. Danas su uobiajeni LAN-ovi od 100 Mb/s, a na raspolaganju su i
LAN-ovi od 1 i 10 Gb/s.
U 80-im i poetkom 90-ih godina, bile su popularne dve tehnologije LAN-ova. Prvu klasu
inili su Ethernet LAN-ovi (takode poznati kao LAN-ovi 802.3 [Spur-geon 2002]), koji su
zasnovani na sluajnom pristupu. Druga klasa tehnologija za LAN sastoji se od tehnologija
prosleivanja etona, ukljuujui Token Ring (takoe poznat i kao IEEE 802.5) i FDDI (poznata
takode kao interfejs optiki distribuiranih podataka [Jain 1994]). S obzirom na to da emo
detaljnije istraiti tehnologije Ethernet u odeljku 5.5, ovde emo se usredsrediti na LAN-ove sa
prosleivanjem etona. Nae objanjavanje tehnologija prosleivanja etona je namerno kratko,
zato to su one postale relativno sporedan igra u sueljavanju sa neumornom konkurencijom
Ethemeta. I pored toga, da bismo obezbedili primere tehnologije prosleivanja etona i da bismo
svemu ovome dali izvesnu istorijsku perspektivu, korisno je da kaemo neku re i o tehnologiji
Token Ring.
U Token Ring LAN-u, N vorova LAN-a (raunari i ruteri) povezani su u prsten direktnim
linkovima. Token ring topologija definie redosled prosleivanja etona. Kada vor dobije eton
i poalje okvir, okvir se propagira kroz ceo prsten, stvarajui tako virtuelni difuzni kanal.
Odredini vor ita okvir sa medijuma sloja linka dok okvir prolazi. vor koji alje okvir ima
odgovornost da ukloni okvir sa prstena.
FDDI je projektovan za geografski vee LAN-ove, ukljuujui tu i takozvane gradske
raunarske mree (metropolitan area nehvork, MAN). Za geografski velike mree (koje se
prostiru na vie kilometara), ne bi bilo efikasno da se okvir propagira nazad otpremnom voru
po prolasku kroz odredini vor. Kod kanala FDDI odredini vor uklanja okvir sa prstena.
(Strogo govorei, FDDI nije pravi difuzni kanal, zato to svaki vor ne prima svaki poslati
okvir.)

5.4 Adresiranje sloja linka
vorovi - odnosno, raunari i ruteri - imaju adrese sloja linka. To bi vas moglo iznenaditi, ako
se setite iz poglavlja 4 da vorovi imaju i adrese mrenog sloja. Mogli biste se zapitati, zato
jepotrebno da imamo adrese i u mrenom sloju i u sloju linka? Pored opisivanja sintakse i
funkcije adresa sloja linka, u ovom odeljku se nadamo da emo vam objasniti zato su dva sloja
adresa korisni i, u stvari, neophodni.
Pored toga, u ovom odeljku emo objasniti dva vana pojma koji se odnose na adrese. Prvi
je protokol razreavanja adresa (ARP), koji obezbeduje prevoenje IP adresa u adrese sloja
linka. Drugi je protokol za dinamiko konfigurisanje glavnog raunara (DHCP). O usluzi DHCP
govorili smo u poglavlju 4; ovde emo prime-niti nae znanje o adresama sloja linka da bi
opisali kako se implementira usluga DHCP.

5.4.1 MAC adrese
U stvarnosti, nema vor (odnosno, raunar ili ruter) adresu sloja linka; umesto toga njegov
adapter ima adresu sloja linka. To je ilustrovano na slici 5.16. Adresa sloja linka se drugaije
zove LAN adresa, fizika adresa, ili MAC adresa (Media Access Control, kontrola pristupa
medijumima). Kako je MAC adresa izgleda najpopularniji termin, mi emo se od sada na adrese
sloja linka pozivati kao na MAC adrese. Za veinu LAN-ova (ukljuujui tu Ethernet i beine
LAN-ove 802.11), MAC adresa je duine est bajtova, to daje 2
48
moguih MAC adresa. Kao
to je prikazano na slici 5.16, uobiajeno je da se ove estobajtne adrese izraavaju u
heksadecimalnoj notaciji, gde je svaki bajt izraen kao par heksadecimalnih brojeva. Znaajna
injenica o MAC adresama je da su one stalne - kada se adapter proizvede, LAN adresa se upie
u njegovu ROM memoriju.
Zanimljiva osobina LAN adresa je da ne postoje dva adaptera koja imaju iste adrese. To bi
moglo da izgleda iznenaujue, s obzirom na to da se adapteri proizvode u mnogo razliitih
zemalja i kompanija. Kako su kompanije koje proizvode adaptere u Tajvanu sigurne da koriste
adrese koje su razliite od onih koje koriste kompanije koje proizvode adaptere u Belgiji?
Odgovor je da IEEE upravlja prostorom fizikih adresa. Posebno, kada kompanija eli da
proizvodi adaptere, ona kupuje deo adresnog prostora od 2
24
adresa, za iznos nominalne
lanarine. IEEE dodeljuje deo od 2
24
adresa, fiksirajui prva 24 bita fizike adrese i
dozvoljavajui kompaniji da pravi jedinstvene kombinacije od poslednja 24 bita za svaki
adapter.

235 235 235 235 5.4 . ADRESIRANJE SLOJA LINKA 447 447 447 447

MAC adresa adaptera ima linearnu strukturu (za razliku od hijerarhijske strukture) i ne
menja se bez obzira na to gde se adapter nalazi. Prenosni raunar sa Ethernet karticom ima istu
MAC adresu, bez obzira na to gde je raunar. PDA sa interfejsom 802.11 ima uvek istu MAC
adresu, bez obzira gde je PDA. Setite se da, za razliku od toga, IP adresa ima hijerarhijsku
strukturu (odnosno, deo za mreu i deo za raunar) i da IP adresa vora mora da se menja kada se
raunar premeta. MAC adresa adaptera analogna je neijem broju socijalnog osiguranja, koji
takode ima linearnu strukturu i ne menja se bez obzira na to gde ide njegov vlasnik. IP adresa je
analogna neijoj potanskoj adresi koja je hijerarhijska i mora da se promeni kad god se ta osoba
preseli. Kao to je nekog korisno da ima i potansku adresu ' i broj socijalnog osiguranja, tako je
za vor korisno da ima i adresu mrenog sloja i MAC adresu.
Kao to smo opisali na poetku ovog odeljka, kada adapter eli da poalje okvir nekom
odredinom adapteru u okviru istog LAN-a, adapter poiljaoca umee MAC adresu adaptera
odredita u okvir i onda alje okvir u LAN. Ako je LAN difuzan (kao to su 802.11 i mnogi
Ethernet LAN-ovi), okvir primaju i obraduju svi drugi adapteri u LAN-u, Posebno, svaki adapter
koji prima okvir proverie da vidi da li MAC adresa odredita odgovara njegovoj sopstvenoj
MAC adresi. Ako postoji podudarnost, adapter izdvaja priloeni datagram i prosleuje ga
protokolu navie, svom nadreenom voru. Ako nema podudarnosti, adapter odbacuje okvir,
bez prosledivanja datagrama mrenom sloju. Dakle, samo e adapter u odredinom voru poslati
signal prekida svom nadreenom procesoru u trenutku kada prima okvir.
PRINCIPI U PRAKSI
NEZAVISNI SLOJEVI
Ima vie razloga zbog kojih vorovi imaju LAN adrese pored adresa mrenog sloja Prvo, LAN -ovi su
projeklovoni za proizvoljne protokole mrenog sloja, a ne samo za IP i Internet. Ako bi adapteri
trebalo da dobiju dodeljene IP adrese, a ne neutralne" MAC adrese, onda oni ne bi mogli iako da
podravaju druge protokole mrenog sloja (na primer IPX ili DECnet). Drugo, ako bi adapteri trebalo
da koriste adrese mrenog sloja umesto MAC adresa, adresa mrenog sloja bi trebalo da bude
uskladitena u RAM memoriji adaptera i ponovo konfigurisana svaki put kado bi se adopter
premestio (ili ukljuilo napajanje). Druga opcija bi bila da se ne koriste nikakve adrese u adapterima i
da svaki adapter prosleuje podatke (po pravilu, IP datagram) svakog primljenog okvira voru kome
pripada. Ovaj vor bi onda mogao da proveri da li mu odgovara adresa mrenog sloja. Problem sa
ovom opcijom je u tome to bi vor bio prekidan svakim okvirom posla-tim u LAN-u, ukljuujui tu i
okvire koji su namenjeni drugim vorovima na istom difuznom LAN-u. Sve u svemu, da bi slojevi
bili iroko nezavisni gradivni blokovi u mrenoj arhitekturi, mnogi od njih treba do imaju sopstvenu
adresnu emu. Sada moemo da vidimo tri razliite vrste adresa: imena vorova za aplikacijski sloj,
IP adrese za mreni sloj i LAN adrese za sloj veze podataka.
Meutim, ponekad predajni adapter zaista eli da svi drugi adapteri u LAN-u prime i
obrade okvir koji on alje. U tom sluaju, adapter umee specijalnu difuznu MAC adresu u polje
adrese odredita okvira. Kod LAN-ova koji koriste estobajtne adrese (kao to su Ethernet i
LAN-ovi sa prosledivanjem etona), difuzna adresa je niz od 48 susednih jedinica (odnosno,
FF-FF-FF-FF-FF-FF u heksadecimainoj notaciji).

5.4.2 Protokol razreavanja adresa (ARP)
S obzirom na to da postoje i adrese mrenog sloja (na primer, Internet IP adrese) i adrese sloja
linka (odnosno, MAC adrese), potrebno je da se izvri prevoenje izmeu njih. U sluaju
Interneta, to je zadatak protokola za razreavanje adresa (address resolution protocol, ARP)
[RFC 826].
Da biste razumeli potrebu za protokolom kao to je ARP, pogledajte mreu prikazanu na
slici 5.17. U ovom jednostavnom primeru, svaki vor ima IP adresu, a svaki adapter vora
MAC adresu. Kao i obino, IP adrese su prikazane u decimalnoj notaciji sa takom, a MAC
adrese u heksadecimainoj notaciji. Sada pretpostavite da

5.4 . ADRESIRANJE SLOJA LINKA 236 236 236 236

vor sa IP adresom 222.222.222.220 eli da poalje IP datagram voru 222.222.22-2.222. (Na
primer, odredini vor 222.222.222.222 moe da bude veb server, a predajni vor 222.222.222.220
je mogao da utvrdi IP adresu veb servera iz DNS-a). U ovom primeru, i izvorni i odredini vor su na
istoj mrei (LAN), u adresnom smislu iz odeljka 4.4.3. Da bi poslao datagram, predajni vor mora da
obezbedi svom ada-pteru ne samo IP datagram, nego i MAC adresu vora 222.222.222.222. Uz
dati IP datagram i MAC adresu, adapter predajnog vora e konstruisati okvir sloja veze podataka
koji sadri MAC adresu prijemnog vora i poslae okvir u LAN.
Vano pitanje koje se postavlja u ovom odeljku je kako predajni vor odreuje MAC adresu za
odredini vor sa IP adresom 222.222.222.222? Kao to moete da pogodite, on koristi ARP. ARP
modul u predajnom voru kao ulaz uzima bilo koju IP adresu na istom LAN-u i vraa odgovarajuu
MAC adresu. U naem primeru, predajni vor 222.222,222.220 obezbeduje svom ARP modulu IP
adresu 222.222.2-22.222, a ARP modul vraa odgovarajuu MAC adresu 49-BD-D2-C7-56-2A.
Dakle, vidimo da ARP prevodi IP adresu u MAC adresu. To je dosta analogno DNS-u
(razmatranom u odeljku 2.5), koji prevodi imena raunara u IP adrese. Meutim, znaajna razlika
izmeu ova dva prevodioca je u tome to DNS prevodi imena raunara za raunare bilo gde na
Internetu, dok ARP prevodi IP adrese samo za vorove u okviru istog LAN-a. Ako je vor u
Kaliforniji pokuavao da upotrebi ARP kako bi preveo IP adresu vora u Misisipiju, ARP bi vratio
greku.
Sad kada smo objasnili ta radi ARP, hajde da pogledamo kako on to radi. Modul ARP u
svakom voru ima tabelu u svojoj RAM memoriji koja se zove ARP tabela. Ova tabela sadri
preslikavanja IP adresa u MAC adrese. Na slici 5.18 prikazano je kako bi mogla da izgleda ARP
tabela u voru 222.222.222.220. Za svako preslikavanje adresa, tabela takoe sadri i stavku roka
trajanja (time to live, TTL), koja pokazuje kada e adresa biti izbrisana iz tabele. Po pravilu, vreme
isteka vanosti je 20 minuta od kada se stavka postavi u ARP tabelu.
Sada pretpostavite da vor 222.222.222.220 eli da poalje datagram sa odredinom IP
adresom drugog vora na istom LAN-u. Predajni vor treba da dobije MAC adresu vora odredita,
na osnovu date IP adrese tog vora. Taj zadatak je jednostavan, ako ARP tabela predajnog vora
ima stavku za vor odredita. Ali, ta ako ARP tabela trenutno nema stavku za vor odredita?
Konkretno, pretpostavite da vor 222.222.222.220 eli da poalje datagram voru 222.222.222.222.
U tom sluaju, predajni vor koristi protokol ARP da bi odredio adresu. Prvo, predajni vor konstruie
specijalan paket koji se zove ARP paket. ARP paket ima nekoliko polja, ukljuujui tu i prijemne IP i
MAC adrese. Paketi i za ARP upit i za odgovor imaju isti format. Namena ARP upitnog paketa je da
se poalje upit svim drugim vorovima u LAN-u sa namerom da se odredi MAC adresa koja
odgovara traenoj IP adresi.
Ako se vratimo naem primera, vor 222.222.222.220 prosleduje ARP upitni paket adapteru,
zajedno sa indikacijom da bi adapter trebalo da poalje paket na difu-znu LAN adresu, odnosno na
FF-FF-FF-FF-FF-FR Adapter enkapsulira ARP paket u okvir sloja veze podataka, koristi difuznu
adresu kao adresu odredita tog okvira i predaje okvir u LAN. Podsetivi se na nau analogiju sa
brojem socijalnog osiguranja/potanskom adresom, zapazite daje ARP upit ekvivalentan osobi koja
vie u prostoriji neke kompanije (na primer, AnvCorp) prepunoj boksova: Koji je broj socijalnog
osiguranja osobe ija potanska adresa je boks 13, soba 112, AnvCorp, Palo Alto, CA?" Okvir koji
sadri ARP upit primaju svi drugi adapteri u LAN-u, i (zbog difuzne adrese), svaki adapter prosleduje
ARP paket unutar okvira navie do svog raunarskog vora. Svaki vor proverava da li njegova IP
adresa odgovara IP adresi odredita u ARP paketu. Samo vor u kom postoji podudarnost vraa
odzivni ARP paket voru koji je pitao. Upitni vor (222.222.222.220) onda moe da aurira svoju ARP
tabelu i poalje svoj IP datagram.

POGLAVLJE 5 SLOJ VEZE PODATAKA 1 LOKALNE MREE RAUNARA
237 5.4 ADRESIRANJE SLOJA LINKA 451 451 451 451

Ima nekoliko zanimljivih stvari koje treba zapaziti u vezi sa ARP protokolom. Prvo, upitna
ARP poruka se alje unutar difuznog okvira, dok se odzivna ARP poruka alje unutar
standardnog okvira. Pre nego to nastavite sa itanjem, trebalo bi da razmislite zastoje to tako.
Drugo, ARP je prikljui i radi" (plug and plav); to znai da se ARP tabela vora pravi
automatski - ne treba da je konfigurie administrator sistema. A ako se, na kraju, vor iskljui iz
LAN-a, njegova stavka se konano brie iz tabela vorova koji ostaju u podmrei.

Slanje datagrama voru izvan LAN-a
Sada bi trebalo da bude jasno da ARP funkcionie kada vor eli da poalje datagram drugom
voru u istoj podrmrei. (Podmree su precizno definisane u odeljku 4.4.2). Ali, hajde da sada
pogledamo sloeniju situaciju, kada vor u podmrei eli da poalje datagram mrenog sloja
voru izvan podmree (odnosno, preko rutera u drugu podmreu). Hajde da govorimo o tom
pitanju u kontekstu slike 5.19, gde je prikazana jednostavna mrea koja se sastoji od dve
podmree, meusobno povezane pomou rutera.
Ima nekoliko zanimljivih stvari koje treba zapaziti u vezi sa slikom 5.19. Prvo, postoje dve
vrste vorova: raunari i ruteri. Svaki raunar ima tano jednu IP adresu i jedan adapter. Ali, kao
to smo govorili u poglavlju 4, ruter ima IP adresu za svaki od svojih interfejsa. Svaki interfejs
rutera takoe ima sopstveni ARP modul (u ruteru) i adapter. S obzirom na to da ruter na slici
5.19 ima dva intefejsa, on ima dve IP adrese, dva ARP modula i dva adaptera. Naravno, svaki
adapter u mrei ima svoju sopstvenu MAC adresu.
Takoe zapazite da podmrea 1 ima mrenu adresu 111.111.111/24, a da podmrea 2 ima
mrenu adresu 222.222.222/24. Dakle, svi interfejsi prikljueni na podmreu 1 imaju adrese u
obliku 111,111.111 ,xxx, a svi interfejsi prikljueni na podmreu 2 imaju oblik 222.222,222.xxx.
Hajde da sada ispitamo kako bi raunar na podmrei 1 poslao datagram raunaru na
podmrei 2. Posebno, pretpostavite da raunar 111.111.111.111. eli da poalje IP datagram
raunaru 222.222.222.222. Kao i obino, raunar poiljalac prosleuje datagram svom adapteru.
Ali, raunar poiljalac mora takoe da ukae svom adapteru odgovarajuu MAC adresu
odredita. Koju bi MAC adresu adapter trebalo da upotrebi? Mogli bismo da se usudimo da
nagaamo kako je odgovarajua MAC adresa ona koju ima adapter za raunar 222.222.222.222,
odnosno 49-BD-D2-C7-56-2A. Meutim, to nagaanje je pogreno. Ako bi predajni adapter
upotrebio tu MAC adresu, nijedan od adaptera unutar podmree 1 ne bi prosledio IP datagram
navie u svoj mreni sloj, zato to adresa odredita okvira ne bi odgovarala MAC adresi bilo kog
adaptera u podmrei 1. Datagram bi samo preminuo i otiao u raj za datagrame'.
Ako paljivo pogledamo sliku 5.19 vidimo da, kako bi datagram iz 111.11-
1. 111. i 11 otiao u vor u podmrei 2, on mora prvo da se poalje interfejsu rutera
111.111.111.110. Dakle, odgovarajua MAC adresa za okvir je adresa adaptera za interfejs
rutera 111.111.111.110, odnosno E6-E9-00-17-BB-4B. Kako vor poiljaoca dolazi do MAC
adrese U 1.111.II 1.110? Naravno, koristei ARP! Jednom kada predajni adapter ima tu MAC
adresu, on pravi okvir i alje ga u podmreu 1. Adapter rutera na podmrei 1 vidi daje okvir
sloja linka podataka adresiran njemu i zato prosleuje okvir mrenom sloju rutera. Ura! IP
datagram je uspeno prenet od izvornog raunara do rutera! AH, nismo zavrili. Jo uvek treba
da prenesemo datagram od rutera do odredita. Ruter sada treba da odredi taan interfejs na koji
treba da se prosledi datagram. Kao to smo objasnili u poglavlju 4, to se radi tako to se pogleda
u tabelu prosledivanja u ruteru. Tabeia prosledivanja kae ruteru da datagram treba da se
prosledi preko ruterovog interfejsa 222.222.222.220. Taj interfejs onda prosleuje datagram
svom adapteru, koji ga enkapsulira u novi okvir i alje okvir u podmreu
2. Ovog puta, MAC adresa odredita je stvarno MAC adresa krajnjeg odredita. A kako ruter
dobija tu MAC adresu odredita? Naravno, od ARP-a!
ARP za Ethemetje definisan u RFC-u 826. Lep uvod u ARP dat je u uputstvu za TCP/IP,
RFC 1180. Mi emo detaljnije ispitati ARP u problemima za domae zadatke.

5.4.3 Protokol za dinamiko konfigurisanje glavnog raunara
Kada smo u poglavlju 4 govorili o IP adresama, ukratko smo razmotrili uslugu koju prua
DHCP, protokol koji se dosta koristi u korporativnim, univerzitetskim i kunim LAN-ovima za
dinamiko dodeljivanje IP adresa raunarima. Poto smo uslugu opisali u poglavlju 4, sada
emo upotrebiti nae novousvojeno znanje o MAC adresama da bismo opisali kako DHCP
stvarno radi.

238
453i 5.4 ADRESIRANJE SLOJA LINKA

DHCP je protokol izmeu klijenta i servera. Klijent je obino novodoavi raunar koji eli da
dobije informacije o konfiguraciji mree, ukljuujui i sopstvenu IP adresu. U najprostijem
sluaju, svaka podmrea (u adresnom smislu opisanom u odeljku 4.4.2) e imati DHCP server.
Ako nema servera u podmrei, potreban je agent za prenos DHCP (obino ruter) koji zna adresu
DHCP servera za tu mreu. Na slici 5.20 prikazan je DHCP server prikljuen na podmreu
223.1.2/24, sa ruterom koji slui kao prenosni agent za dolazee klijente koji su prikljueni na
podmree 223,1. L/24 i 223.1.3/24.
Za novoprispeli raunar, protokol DHCP je proces u etiri koraka:
Otkrivanje DHCP-a, Prvi zadatak novoprispelog raunara je da pronae DHCP server sa kojim
treba da stupi u interakciju. To se radi upotrebom DHCP poruke za otkrivanje, koju klijent
alje unutar UDP paketa na port 67. UDP paket se enkapsulira u IP datagramu. Ali, kome bi
taj datagram trebalo da se poalje? Raunar ak ne zna ni IP adresu mree na koju je
prikljuen, to je mnogo manje od DHCP servera za tu mreu. U takvim uslovima, DHCP
klijent stvara IP datagram koji sadri njegovu DHCP poruku za otkrivanje, uz difuznu odre-
dinu IP adresu 255.255.255.255 i izvornu [P adresu ovog raunara" 0.0.0.0. DHCP klijent
prosleduje IP datagram svom adapteru, koji enkapsulira datagram u okvir sloja linka. Taj
okvir sloja linka obuhvata difuznu MAC adresu (FF-FF-FF-FF-FF-FF) u polju za adresu
odredita. DHCP klijent onda alje u mreu difuzni okvir, koji sadri poruku za otkrivanje.
Taj difuzni okvir e primiti svi adapteri u mrei. Ako je DHCP server prikljuen na istu
podmreu, on e obraditi enkapsuliranu poruku za otkrivanje (pogledajte dalje u tekstu); ako
je DHCP prenosni agent prikljuen na podmreu, on e proslediti okvir mrei sa DHCP
serverom. (Taj preneseni okvir e imati razliitu izvornu MAC adresu.) Poruka za otkrivanje
sadri ID transakcije koji dozvoljava sledeim odzivima da budu usklaeni sa zahtevom za
otkrivanje.
Ponuda (e) DHCP servera. DHCP server koji prima DHCP poruku za otkrivanje odgovara
klijentu DHCP porukom za ponudu. Kako u mrei moe da bude prisutno vie DHCP
servera, klijent moe da se nade u zavidnom poloaju daje u stanju da bira izmeu vie
ponuda. Svaka poruka servera za ponudu sadri ID transakcije primljene poruke za
otkrivanje, predloenu IP adresu za klijenta, mrenu masku i vreme zakupa IP adrese -
vreme za koje e IP adresa biti vaea. Uobiajeno je da server postavi vreme zakupa na vie
sati ili dana (Droms 1999). Okvir sloja linka koji sadri IP datagram koji sadri UDP
segment koji sadri DHCP poruku za ponudu se onda alje prispelom klijentu. (Ako vam se
od ove ugneene enkapsulacije vrti u glavi, vratite se korak natrag i ponovo proitajte
odeljak 1.7.)
DHCP zahtev. Novoprispeli klijent e izabrati izmeu jedne ili vie ponuda servera i
odgovorie na izabranu ponudu DHCP porukom za zahtev, vraajui nazad parametre
konfiguracije.
DHCP A CK. Server odgovara na DHCP poruku za zahtev porukom DHCP ACK,
potvrujui zahtevane parametre.
Jednom kada klijent primi DHCP ACK, interakcija je upotpunjena i klijent moe da koristi IP
adresu dodeljenu od DHCP za dato vreme zakupa. Kako klijent moe poeleti da koristi svoju
adresu i posle isteka zakupa, DHCP takoe obezbeduje mehanizam koji doputa klijentu da
obnovi svoj zakup IP adrese.
Jednostavna DHCP interakcija klijent-server prikazana je na slici 5.21, za postavku mree
sa slike 5.20. Na toj slici, yiaddr (vaa Internet adresa") pokazuje adresu koja se dodeljuje
novoprispelom klijentu.
Vrednost DHCP plug-and-play mogunosti je jasna. Zamislite studenta koji prelazi iz
uionice u spavau sobu sa prenosnim raunarom, pridruuje se novoj podmrei i tako dobija
novu IP adresu na svakoj lokaciji. Nezamislivo je da bi administrator sistema morao da
rekonfigurie prenosne raunare na svakoj lokaciji, a malo studenata (izuzev onih koji pohaaju
nastavu iz raunarskog umreavanja!) bi imalo znanja da runo konfigurie svoje prenosne
raunare. Meutim, sa aspekta pokretljivosti, DHCP zaista ima nedostatke. Kako se nova IP
adresa dobija od DHCP

454 454 454 454
5.5 ETHERNET 239 239 239 239

svaki put kada se vor povee na novu podmreu, veza sa udaljenom aplikacijom ne moe da se
odrava kada se pokretni vor kree izmeu podmrea. U poglavlju 6 emo ispitati pokretni IP -
nedavno proirenje IP infrastrukture koje dozvoljava pokretnom voru da koristi jednu stalnu
adresu dok se kree izmeu podmrea.
Dodatni detalji o DHCP mogu da se pronau u [Drooms 1999] i [dhc 2004].
Implementacija DHCP u izvornom kodu raspoloiva je na Internet Systems Consor-tium [ISC
2004],
5.5 Ethernet
Ethernet je u prilinoj meri preuzeo trite LAN-a. U 1980-im i poetkom 1990-ih godina,
Ethernet se suoavao sa mnogobrojnim izazovima od strane drugih tehnologija LAN,
ukljuujui tu Token Ring, FDDI i ATM. Neke od tih drugih tehnologija uspele su da zauzmu
deo trita za nekoliko godina. Ali, od kada je pronaen sredinom 1970-ih godina, Ethernet je
nastavio da se razvija i raste i zadrao je svoj veinski deo trita. Danas je Erthernet daleko
preovlaujua tehnologija za LAN i verovatno e to ostati u doglednoj budunosti. Moglo bi se
rei daje Erthernet za lokalno umreavanje raunara ono stoje Internet bio za globalno
umreavanje.
Ima mnogo razloga za Ethernetov uspeh. Prvo, Ethernet je bio prvi iroko pri-menjivani
brzi LAN. S obzirom na to daje Ethernet odavno u upotrebi, administratori mrea su se blisko sa
njim upoznali - sa njegovim udima i dosetkama - pa su nerado prelazili na druge LAN
tehnologije kada bi one stupale na scenu. Drugo, Token'Ring, FFDI i ATM bili su sloeniji i
skuplji od Etherneta, to je jo vie obeshrabrilo administratore mrea da uu u neke promene.
Tree, najjai razlog za prelazak na drugu LAN tehnologiju (kao to su FFDI i ATM) obino je
bila vea brzina nove tehnologije; meutim, Ethernet je uvek uzvraao udarac, proizvodei
verzije koje su radile jednakom ili jo veom brzinom. Komutirani Ethernet je takoe pred-
stavljen poetkom 1990-ih godina, sto je jo vie povealo njegovu efektivnu brzinu podataka.
Najzad, zbog velike popularnosti Etherneta, njegov hardver (posebno adapteri, habovi i
komutatori) je postao roba iroke potronje i izvanredno je jeftin.
Originalni Ethernet LAN su pronali Bob Metkalf i David Bogs, sredinom 1970-ih godina.
Na slici 5.22 prikazana je Metkalfova ema Etherneta.
Slika 5.22 Slika 5.22 Slika 5.22 Slika 5.22 Originalna Mefkalfova konstrukcija dovela je do
standarda Ethernet 10Base5, koji je obuhvatao interfejsni kabl za
povezivanje Ethernet adaptera sa spoljanjim primopredajnikom.

5.5 ETHERNET 240

Na ovoj slici ete zapaziti daje originalni Ethernet LAN koristio magistralu za meusobno
povezivanje vorova. Ta topologija magistrale se zadrala tokom 1980-ih i najveeg dela 1990-ih
godina; posebno, tehnologija Ethernet 10Base2, koja je koristila tanki koaksijalni kabl za
magistralu, bila je izuzetno popularna u 1990-im godinama. Meutim, izuzev retkih nasleenih,
gotovo sve Etherenet instalacije danas koriste topologiju zvezde, kao to je prikazano na slici
5.23. U sreditu topologije zvezde je hab ili komutator. Uskoro emo detaljnije govoriti o
habo-vima i komutatorima. Izvanredan izvor onlajn informacija o Ethernetu je Spurgeo-nova
Ethernet veb stranica [Spurgeon 2004],

5.5.1 Struktura Ethernetovog okvira
Ethernetov okvir je prikazan na slici 5.23. Jednom kad razumemo Ethernetov okvir, znademo ve
mnogo o Ethernetu. Da bismo nau diskusiju o Ethemetovom okviru stavili u opipljiv kontekst,
hajde da razmatramo slanje IP datagrama od jednog do drugog raunara, gde su oba raunara u
istom Ethernet LAN-u (na primer, Ethernet LAN na slici 5.23). Mada je koristan teret naeg
Ethernet okvira IP datagram, zapazimo, ipak, da Ethernet moe da prenosi i druge pakete
mrenog sloja. Neka predajni adapter, adapter A, ima MAC adresu AA-AA-AA-AA-AA-AA, a
prijemni adapter, adapter B, ima MAC adresu BB-BB-BB-BB-BB-BB. Predajni adapter
enkapsulira IP datagram unutar Ethernetovog okvira i prosleduje okvir na fiziki sloj. Prijemni
adapter prima okvir od fizikog sloja, izdvaja IP datagram i prosleduje ga mrenom sloju. U tom
kontekstu, hajde da ispitamo est polja Ethernetovog okvira, kao stoje prikazano na slici 5.24;
Polje za podatke (46 do 1500 bajtova). Ovo polje nosi IP datagram. Maksimalna jedinica
prenosa (MTU) Etherneta je 1500 bajtova. To znai da ako je IP datagram vei od 1500
bajtova, raunar mora da ga podeli, kao stoje objanjeno u odeljku 4.4.4. Minimalna veliina
polja za podatke je 46 bajtova. To znai da ako je datagram manji od 46 bajtova, polje za
podatke mora da bude popunjeno" do 46 bajtova. Kada se koristi popunjavanje, podaci koji
se prosleuju mrenom sloju sadre i popunu i IP datagram. Mreni sloj koristi polje za
duinu u zaglavlju IP datagrama, da bi uklonio popunu.
Adresa odredita (6 bajtova). Ovo polje sadri LAN adresu adaptera odredita, u naem
primeru BB-BB-BB-BB-BB-BB. Kada adapter B primi Ethernet okvir ija je adresa odredita
BB-BB-BB-BB-BB-BB ili difuzna MAC adresa, on prosleduje sadraj polja za podatke
okvira u mreni sloj; ako primi okvir sa bilo kojom drugom MAC adresom, on ga odbacuje.
Adresa izvora (6 bajtova). Ovo polje sadri LAN adresu adaptera koji predaje okviru LAN, u
naem primeru AA-AA-AA-AA-AA-AA.
Polje za tip (2 bajta). Polje tipa dozvoljava Ethernetu da multipleksira protokole mrenog
sloja. Da bismo razumeli ovu zamisao, treba da imamo na umu da raunari pored IP-a mogu
da koriste i druge protokole mrenog sloja. U stvari, dati raunar moe da podrava
viestruke protokole mrenog sloja, koristei razliite protokole za razliite aplikacije. Iz tog
razloga, kada Ethernet okvir stigne u adapter B, adapter B treba da zna kom protokolu
mrenog sloja treba da prosledi (odnosno demultipleksira) sadraj polja za podatke. IP i drugi
protokoli mrenog sloja (na primer, Novell IPX ili AppleTalk) imaju svaki svoj,
standardizovani broj koji odreuje tip. Pored toga, ARP protokol (objanjen u prethodnom
odeljku) ima sopstveni broj tipa. Zapazite daje polje tipa analogno polju protokola u data-
gramu mrenog sloja i poljima broja porta u segmentu transportnog sloja; svako od tih polja
slui da spoji protokol jednog sloja sa slojem koji se nalazi iznad njega.
Ciklika provera redundantnosti (CRC) (4 bajta). Kao stoje objanjeno u odeljku 5.2.3,
svrha polja CRC je da dozvoli prijemnom adaptera, adaptera B, da otkrije da li je nastala bilo
kakva greka u okviru, odnosno, da li su bitovi u okviru promenili vrednost. Uzroci greaka
bitova obuhvataju slabljenje snage signala i elektromagnetne smetnje iz okoline koje prodiru
u Erthemet kablove i interfejsne kartice. Greke se otkrivaju na sledei nain. Kada raunar
A konstruie Ether-

5.5 . ETHERNET 241
241

net okvir, on izraunava polje CRC, koje se dobija iz svih ostalih bitova unutar okvira, izuzev
bitova preambule. Kada raunar B prima okvir, on primenjuje iste matematike operacije na okvir
i proverava da li je rezultat jednak onome to se ve nalazi u polju CRC. Ta operacija se zove
CRC provera. Ako CRC provera ne uspe (odnosno, rezultat izraunavanja nije jednak sadraju
polja CRC), onda raunar B zna da postoji greka u okviru.
Preambula (8 bajtova). Ethernet okvir poinje osmobajtnim poljem preambule. Svaki od prvih
sedam bajtova preambule ima vrednost 10101010; poslednji bajt je 10101011. Prvih sedam
bajtova preambule slue da probude" prijemne ada-ptere i da sinhronizuju njihove generatore
takta sa generatorom takta poiljaoca. Zato bi generatori takta bili van sinhronizacije? Imajte na
umu da adapter A namerava da prenosi okvir na 10 Mb/s, 100 Mb/s ili I Gb/s, zavisno od vrste
Ethernet LAN-a. Meutim, zato to nita nije apsolutno savreno, adapter A nee prenositi okvir
tanom ciljnom brzinom; uvek e biti izvesnog odstupanja od ciljne brzine, koje nije a priori
poznato ostalim adapterima u LAN-u. Prijemni adapter moe da se sinhronizuje sa generatorom
takta adaptera A vezujui se jednostavno na bitove u prvih sedam bajtova preambule. Poslednja
dva bita osmog bajta preambule (prve dve susedne jedinice) obavetavaju adapter B da e
uskoro da naie neka vana stvar". Kada raunar B detekluje dve susedne jedinice, on zna da
su sledeih est bajtova adresa odredita. Adapter saoptava kada je naiao kraj okvira
jednostavnom detekcijom odsustva signala.
Ethernet koristi prenos u osnovnom opsegu; odnosno, adapter alje digitalni signal direktno u difuzni
kanal. Kartica interfejsa ne premeta signal u drugi frekventni opseg, kao to se to radi u ADSL i
sistemima kablovskih modema. Mnoge Ethernet tehnologije (na primer, lOBaseT) takoe koriste
Manchester kodovanje, kao to je prikazano na slici 5.25. Kod Manchester kodovanja, svaki bit
sadri prelaz; 1 ima prelaz odozgo na dole, dok 0 ima prelaz odozdo na gore. Razlog za Manchester
kodovanje je to generatori takta u predajnom i prijemnom adapteru nisu savreno sinhronizovani.
Ukljuivanjem prelaska u sredini svakog bita, prijemni raunar moe da sinhronizuje svoj generator
takta prema onome u predajnom raunaru. Jednom kada se generator takta prijemnog adaptera
sinhronizuje, prijemnik moe da iscrta svaki bit i utvrdi da li je o'n 1 ili 0. Manchester kodovanje je
operacija fizikog sloja, a ne operacija sloja veze podataka; meutim, mi smo ga ukratko opisali
ovde, zato to se ono koristi iskljuivo u Etherneru.

Nepouzdana usluga bez konekcije
Sve Ethernet tehnologije obezbeuju mrenom sloju uslugu bez konekcije. To znai da, kada adapter
A eli da'poalje datagram adapteru B, onda adapter A enkapsulira datagram u Ethernet okvir i
poalje okvir u LAN, bez prethodne sinhronizacije" (potvrivanja spremnosti za prenos) sa
adapterom B. Ova usluga bez konekcije slo-ja-2 analogna je usluzi datagrama IP sloja-3 i UDP
usluzi sloja-4.
KRATAK OSVRT
BOB METKALF 1 ETHERNET
Kao doktorant na Univerzitetu Harvard poetkom 1970-ih godina. Bob Melkolf je radio na
ARPAnetu na MIT-u. Za vreme studija, on je takoe imao uvida u Abramsonov rod na ALOH1
i protokolima sa sluajnim pristupom. Polo je zavrio doktorsku disertaciju, ba pre
poetka rada u Xeroxovom istraivakom cenSru u Palo Altu (Xerox PARC), poseSio je
Ambramsona i njegove kolege sa Univerziteta u Havajima u toku tri meseco, gde je dobio
uvid iz prve ruke u ALOHAnet. U Xerox PARC-u, na Metkalfa su ostavili utisak raunari Alto,
koji su u mnogo emu bili prethodnici personalnih raunara iz 1980-ih godina. Metkalf je
sagledao potrebu da umrei te raunare na jeftin nain, Tako je, naoruan svojim znanjem o
ARPAnetu, ALOHAnetu i protokolima sa viestrukim prisluporn, Metkalf - zajedno sa kolegom
Davidom Bogsom - pronaao Ethernet.
Melkalfov i Bogsov Ethernet prvobitno je radio na 2,94 Mb/s i povezivao do 256 raunara,
na udaljenosti do jedne milje. MelkaK i Bogs su uspeli da veino istraivaa u Xerox PARC-u
komuniciraju preko svojih raunara Alto. Metkalf je zatim napravio savez izmeu Xeroxa,
Digitala i Intela sa ciljem da uspostave Ethernet na standardu 10 Mb/s, koji je ratifikovala
organizacija IEEE. Xerox nije pokazao mnogo zanimanja za komercijolizociju Elhernefa.
Godine 1979, Metkalf je osnovao sopstvenu kompaniju, 3Com, koja je razvila i
komercijalizovala mrenu tehnologiju, ukljuujui i tehnologiju Eihernet. Posebno, u 3Com su
razvijene i dote na triie kartice Ethernet poetkom 1980-ih godina, za veoma popularne
IBM-ove PC raunare, Metkalf je napustio 3Com 1990. godine, kada je imao 2000 ljudi i dobit
od 400 miliona USD. Poetkom januara 2002. godine, 3Com zapoljava preko 8000 ljudi.

5.5 . ETHERNET 242 242 242 242
I-

460 460 460 460 POGLAVLJE 5 SLOJ VEZE PODATAKA i LOKALNE MREE RAUNARA
Sve Ethernet tehnologije obezbeuju nepouzdanu uslugu mrenom sloju. Posebno, kada
adapter B prima okvir od adaptera A, on proputa okvir kroz CRC proveru, ali ne alje potvrdu
kada okvir proe kroz CRC proveru (niti alje negativnu potvrdu kada CRC provera ne uspe).
Adapter A nema ni najmanju ideju da li je preneti okvir proao CRC proveru. Kada CRC provera
okvira ne uspe, adapter B jednostavno odbaci okvir. Ovaj nedostatak pouzdanog transporta (na
sloju veze podataka) ini Ethernet jednostavnim i jeftinim. Ali, to takode znai da niz datagrama
prosleenih mrenom sloju moe da ima propuste.
Ako ima propusta zbog odbaenih Ethernet okvira, da li propuste vidi i aplikacija u
raunaru B? Kao to smo saznali u poglavlju 3, to zavisi samo od toga da li aplikacija koristi
UDP ili TCP. Ako aplikacija koristi UDP, onda e ona u raunaru B zaista imati propuste u
podacima. S druge strane, ako aplikacija koristi TCP, onda TCP u raunaru B nee potvrditi
odbaene podatke, to e prouzrokovati da TCP u raunaru A ponovo zapone prenos
nepotvrenog segmenta. Zapazite da kada TCP ponovo alje podatke, oni e dolaziti preko
Ethernet adaptera u kome su biti odbaeni. Dakle, u tom smislu, Ethernet moe ponovo da
prenosi podatke. Ali, trebalo bi da imamo na umu da Ethernet nije svestan da ponovo prenosi iste
podatke. Ethernet misli da prima potpuno nov datagram sa potpuno novim podacima, ak iako
taj datagram sadri podatke koji su najmanje jednom ve bili prenoeni.

5.5.2 CSMA/CD: Ethernetov protokol sa viestrukim pristupom
Kada su vorovi meusobno povezani habom (za razliku od komutatora sloja veze podataka),
Ethernet LAN je pravi difuzni LAN - odnosno, kada adapter predaje okvir, primaju ga svi
adapteri u LAN-u. Imajui u vidu da Ethernet moe da koristi difuziju, potreban mu je protokol
sa viestrukim pristupom. Setite se iz odeljka 5.3 da CSMA/CD radi sledee:
1. Adapter moe da pone da predaje u bilo kom trenutku; to znai, ne koriste se nikakvi
vremenski odseci.
2. Adapter nikada ne predaje okvir kada oseti da neki drugi adapter predaje; to znai, on
koristi prepoznavanje nosioca,
3. Pre nego to pokua sa ponovnim prenosom, adapter eka tokom nasuminog vremenskog
perioda, koji je obino mali u poreenju sa trajanjem prenosa okvira.
Ovi mehanizmi daju CSMA/CD u okruenju LAN-a mnogo bolju performansu od ALOHE sa
odsecima. U stvari, ako je maksimalno kanjenje usled propagacije izmeu stanica
veoma^malo, efikasnost CSMA/CD moe da se priblii vrednosti od 100 procenata. Ali,
zapazite da gore navedeni drugi i trei mehanizam zahtevaju da svaki Ethernet adapter moe (1)
da oseti kada neki drugi adapter predaje i (2) da otkrije koliziju dok sam prenosi svoje okvire,
Ethernet adapteri izvravaju ove zadatke merei nivoe napona pre i posle prenosa.
Svaki adapter izvrava protokol CSMA/CD bez eksplicitne koordinacije sa drugim
adapterima u Ethernetu. Unutar odreenog adaptera, protokol CSMA/CD radi na sledei nain:
1. Adapter dobija datagram mrenog sloja iz svog nadreenog vora, priprema Ethemet okvir i
stavlja okvir u svoju privremenu memoriju,
2. Ako adapter oseti daje kanal slobodan (odnosno, da nema energije signala koji ulazi u
adapter iz kanala u vremenu trajanja 96 bitova), on poinje da prenosi okvir. Ako adapter
oseti daje kanal zauzet, on eka sve dok ne detektuje da nema signala (plus 96 vremena
trajanja bita) i tada poinje da prenosi okvir.
3. Dok prenosi, adapter nadgleda da li su prisutni signali koji dolaze od drugih adaptera. Ako
adapter prenese ceo okvir bez otkrivanja signala od drugih adaptera; on je zavrio sa
okvirom.
4. Ako adapter otkrije signal od drugih adaptera tokom prenosa, on zaustavlja svoj prenos
okvira i umesto njega alje 48-bitni signal zaguenja.
5. Posle prekida (odnosno slanja signala zastoja), adapter ulazi u fazu eksponen-cijalnog
odstupanja. Posebno, kada prenosi dati okvir, posle n-te kolizije za taj okvir, adapter na
sluajan nain bira vrednost za K iz {0, 1,2,..., 2
m A
) gde je m: = min (n,10). Adapter onda
eka/T-512 vremenskih intervala trajanja jednog bita, a zatim se vraa na postupak 2.
Nekoliko komentara o CSMA/CD-u. Svrha signala zastoja je da se osigura da ostali
adapteri koji predaju postanu svesni kolizija. Hajde da pogledamo jedan primer. Pretpostavite da
adapter A poinje da prenosi okvir i ba pre nego to signal iz A stigne do adaptera B, adapter B
poinje da predaje. Tako e B predati samo nekoliko bitova pre nego to zaustavi svoj prenos.
Tih nekoliko bitova e se zaista preneti do A, ali oni moda nemaju dovoljno energije da bi A
otkrio koliziju. Da bi se obezbedilo da A otkrije koliziju (tako da bi takoe mogao da se
zaustavi), B predaje 48-bitni signal zastoja.
Razmotrite sada algoritam eksponencijalnog odstupanja. Prva stvar koju ovde treba zapaziti
je daje trajanje bita (odnosno, vreme koje je potrebno da bi se preneo jedan bit) veoma kratko;
kod Etherneta od 10 Mb/s, ono iznosi 0,1 mikrosekunde. Pretpostavite da adapter prvi put
pokuava da prenese okvir i, dok prenosi, otkriva koliziju. Tada adapter bira K = 0 sa
verovatnoom 0,5 i K = 1 sa verovatnoom 0,5. Ako adapter izabere K= 0, on odmah posle
slanja signala zastoja prelazi na postupak 2. Ako adapter izabere K = 1, on eka 51,2
mikrosekunde posle slanja signala zastoja. Posle druge kolizije, i? se sa podjednakom
verovatnoom bira iz (0, I, 2, 3}. Posle tri kolizije, K se sa podjednakom verovatnoom bira iz
{0, 1,2, 3, 4,5, 6, 7}. Posle deset ili vie kolizija, K se sa podjednakom verovatnoom bira iz (0,
1,2, 1023}. Dakle, veliina skupa iz koga se bira hraste eksponencijalno sa brojem kolizija (do n
= 10); to je razlog zato se Ethernetov algoritam odstupanja zove eksponencijalnim
odstupanjem".

5.5 . ETHERNET 463

Ethernet standard namee ogranienja u rastojanju izmeu dva vora. Ova ogranienja
obezbeuju da, ako adapter A izabere manju vrednost za K od svih drugih adaptera koji su
obuhvaeni kolizijom, tada e on biti sposoban da poalje svoj okvir bez doivljavanja nove
kolizije. Ovu osobinu emo detaljnije istraiti u problemima za domae zadatke.
Zato se koristi eksponencijalno odstupanje? Zato da, na primer, ne izaberemo K iz {0, 1,
2, 3, 4, 5, 6, 7} posle svake kolizije? Razlog je u tome to, kada adapter doivi svoju prvu
koliziju, on nema nikakvu ideju o tome koliko je adaptera obuhvaeno tom kolizijom. Ako
postoji samo mali broj adaptera u koliziji, ima smisla birati K iz malog skupa malih vrednosti. S
druge strane, ako je mnogo adaptera obuhvaeno kolizijom, ima smisla birati K iz veeg, ireg
skupa vrednosti (zato?). A poveavanjem veliine skupa posle svake kolizije, adapter se na
odgovarajui nain prilagoava tim razliitim scenarijima.
Ovde takoe zapaamo da svaki put kada adapter priprema novi okvir za prenos, on
izvrava algoritam CSMA/CD koji je gore objanjen. Adapter ne uzima u obzir nikakve kolizije
koje su se mogle dogoditi u nedavnoj prolosti. Tako je mogue da adapter sa novim okvirom
bude odmah u stanju da obavi uspean prenos, dok se vie drugih adaptera nalazi u stanju
eksponencijalnog odstupanja.
Efikasnost Etherneta
Kada samo jedan vor ima okvir za slanje, on moe da vri prenos punom brzinom Ethernet
tehnologije (10 Mb/s, 100 Mb/s ili 1 Gb/s). Meutim, ako mnogo vorova ima okvire za slanje,
efektivna brzina prenosa kanala moe da bude mnogo manja. Efikasnost Etherneta definiemo
kao dugoroni deo vremena u kome se okviri prenose po kanalu bez kolizija kada postoji veliki
broj aktivnih vorova, gde svaki vor ima veliki broj okvira za slanje. Da bismo predstavili
aproksimaciju efikasnosti Etherneta, neka tpns[ oznaava maksimalno vreme koje je potrebno
energiji signala da se prenese izmeu dva adaptera. Neka je tlrons vreme za prenos Ethernet okvira
maksimalne veliine (priblino 1,2 ms za Ethernet od 10 Mb/s). Izvoenje efikasnosti je izvan
domena ove knjige (proitajte [Lam 1980] i [Bertsekas 1991]. Ovde jednostavno dajemo sledeu
aproksimaciju:

Efficiencv = --~ ---------
1 + 5^/^
Iz ove formule vidimo da, kako se tprost pribliava vrednosti 0, efikasnost se pribliava
vrednosti 1. Ovo odgovara naem intuitivnom zakljuku da ako je kanjenje propagacije nula,
vorovi u koliziji e odmah odustati, bez uzaludnog troenja vremena na kanalu. Takoe^, ako
^ranj-P
0Sta
J
e

veom
a veliko, efikasnost se pribliava vrednosti 1. To je takoe intuitivno, zato to
kada okvir zauzme kanal, on e ga drati veoma dugo vreme; dakle, kanal e raditi koristan
posao u najveem delu vremena.
5.5.3 Ethernet tehnologije
U 2004. godini, najee Ethernet tehnologije su 1 OBaseT i 1 OOBaseT, koje koriste upredene
parice bakarnih provodnika u topologiji zvezde i imaju brzinu prenosa od 10 Mb/s i 100 Mb/s,
respektivno. Ove Ethernet tehnologije su standardizovane od strane radnih grupa IEEE 802.3.
To je razlog zato se na Ethernet LAN esto poziva kao na 802.3 LAN.
Na slici 5.26 ilustrovane su tehnologije 10BaseT/l OOBaseT. Svaki adapter u svakom
voru ima direktnu vezu od take do take sa habom. Ova veza se sastoji od dva para upredenih
parica bakarnih provodnika, jedan za predaju a drugi za prijem. Na kraju veze je konektor RJ-45
koji lii na konektor RJ-11 za obine telefone. Ono ,,T" u lOBaseTi lOOBaseT znai upredena
parica" (twisied~pair). 1 za lOBaseTi za lOOBaseT, maksimalna duina veze izmeu adaptera i
haba je 100 metara; dakle, maksimalno rastojanje izmeu bilo koja dva vora iznosi 200 metara.
Kao to emo objasniti u sledeem odeljku, to maksimalno rastojanje moe da se povea
korienjem niza habova, mostova, komutatora i linkova na bazi optikih vlakana.
Hab je ureaj fizikog sloja koji deluje na pojedinanim bitovima, a ne na okvirima. On
ima dva ili vie interfejsa. Kada bit, koji predstavlja jedinicu ili nulu, stigne iz jednog interfejsa,
hab prosto ponovo napravi bit, pojaa njegovu energiju i preda bit na sve druge interfejse. Vano
je imati na umu da habovi ne primenjuju prepoznavanje nosioca niti bilo koji drugi deo
CSMA/CD; hab ponavlja dolazni bit na svim odlaznim interfejsitna, ak i kad postoji energija
signala na nekom od interfejsa. Zato to habovi predaju bitove, svaki adapter u Ethernetu
10/100BaseT moe da (1) oseti kanal kako bi odredio da li je slobodan i da (2) otkrije koliziju
tokom prenosa.

5.6 MEUSOBNE VEZE: HABOVI I KOMUTATORI 465J

Habovi takoe obezbeuju svojstva upravljanja mreom. Na primer, ako neki adapter radi
neispravno i stalno alje Ethernet okvire (takozvani brbljivi adapter"), tada e mrea
10/100BaseT nastaviti da funkcionie, zato to e hab otkriti problem i interno iskljuiti adapter
koji je neispravan. Uz ovo svojstvo, administrator mree ne mora da ustaje iz kreveta i vraa se
natrag na posao da bi resio problem. Takoe, veina habova moe da prikuplja informacije i
dostavlja ih raunaru koji je povezan direktno sa habom. Kao to se govori u poglavlju 9, ovaj
raunar za nadzor obezbeduje grafiki interfejs koji prikazuje statistike podatke i grafikone, kao
to su iskorienje propusnog opsega, uestanost kolizija, prosene veliine okvira itd.
Administratori mree mogu da koriste ove informacije, ne samo da bi otkrivali i reavali
probleme, nego i da bi planirali kako bi LAN trebalo da se razvija u budunosti.
Mnogi dananji Ethernet adapteri su za 10/100 Mb/s. To znai da oni mogu da se koriste i
za Ethernet lOBaseT i za Ethernet lOOBaseT. lOOBaseT obino koristi upreene parice
kategorije 5 (visokokvalitetan par upredenih ica sa mnogo zavoja). Za razliku od I0Base2 i
lOBaseT, lOOBaseT ne koristi Manchester kodovanje, nego umesto njega mnogo efikasnije
kodovanje koje se zove 4B5B: svaka grupa od pet perioda generatora takta koristi se za slanje
etiri bita da bi bilo dovoljno promena logikih nivoa, kako bi se obezbedila sinhronizacija
generatora takta.
Na ovom mestu ukratko pominjemo da obe Ethernet tehnologije, 10 Mb/s i ' 100 Mb/s, mogu
da koriste linkove od optikih vlakana. Link od optikih vlakana esto se koristi da povee
habove koji se nalaze u razliitim zgradama u okviru istog naselja. Optika vlakna su skupa, zbog
cene njihovih konektora, ali imaju odlinu otpornost na umove. Standardi IEEE 802
dozvoljavaju da LAN ima vei geografski domet kada se optika vlakna koriste pri povezivanju
vorova na okosnici.

Gigabit Ethernet'i Ethernet 10 Gb/s
Gigabit Ethernet je proirenje veoma uspenih standarda Ethernet 10 Mb/s i 100 Mb/s. Nudei
brzinu podataka od 1000 Mb/s, Gigabit Ethernet odrava punu kompatibilnost sa ogromnom
bazom instalirane opreme za Ethernet. Standard za Gigabit Ethernet, koji se zove IEEE 802.3z,
radi sledee:
Koristi standardni format Ethernet okvira (slika 5.24) i unazad je kompatibilan sa
tehnologijama IOBaseT i lOOBaseT. To doputa laku integraciju Gigabit Ether-neta sa
postojeom instaliranom bazom Ethernet opreme.
Doputa linkove od take do take, kao i deljene difuzne kanale. Linkovi od take do take
koriste komutatore (proitajte odeljak 5.6), dok difuzni kanali koriste habove, kao stoje ranije
opisano za IOBaseT i lOOBaseT. U argonu Gigabit Etherneta, habovi se zovu distributeri
sa privremenom memorijom".
Koristi CSMA/CD za deljene difuzne kanale. Da bi imao prihvatljivu efikasnost,
maksimalno rastojanje izmeu vorova mora da bude strogo ogranieno.
Doputa rad u punom dupleksu na 1000 Mb/s u oba pravca za kanale od take do take.

Kao i IOBaseT i lOOBaseT, Gigabit Ethemet ima topologiju zvezde, sa habom ili
komutatorom u centru. (Komutatori za Ethemet e biti objanjeni u odeljku 5.6.) Gigabit
Ethernet esto slui kao okosnica za meusobno povezivanje vie Ethernet LAN-ova 10 Mb/s i
100 Mb/s. U poetku radei preko optikih vlakana, Gigabit Ethernet je sada u stanju da radi
preko kablova UTP kategorije 5.
Sa proizvodima koji su se pojavili 2001. godine, 10 Gigabit Ethernet dalje proiruje
popularnu Ethernet tehnologiju. Pored toga, standard 10 Gigabit Ethernet, 802.3ae, proiruje
Ethernet tehnologiju na linkove od take do take regionalnih raunarskih mrea (wide area
network, WAN). Mnogo korisnih informacija i linkova o Gigabit i 10 Gigabit Ethernetu, moete
nai na Spurgeonovoj veb lokaciji o Ethernetu [Spurgeon 2004].
5. 6 Meusobne veze: habovi i komutatori
Institucije - kompanije, univerziteti i visoke kole - obino se sastoje od mnogo odeljenja,
gde svako odeljenje ima sopstveni Ethernet LAN i upravlja njime. Naravno, institucija eli da
njena odeljenja meusobno povezu svoje odeljenjske LAN segmente, U ovom odeljku emo
razmotriti tri razliita pristupa povezivanju LAN-ova: habove, mostove i komutatore. Danas je
upotreba sva tri pristupa iroko rasprostranjena.

5 . 6 . 1 Habovi
Najjednostavniji nain da se meusobno povezu LAN-ovi jeste da se koriste habovi. Na
slici 5.27 prikazana su tri akademska odeljenja na univerzitetu koja hoe da povezu svoje
LAN-ove. Svako od tri odeljenja na slici ima Ethernet IOBaseT koji obezbeduje mreni pristup
fakultetu, nastavnom osoblju i studentima odeljenja. Svaki raunar u odeljenju ima vezu od take
do take sa odeljenjskim habom. etvrti hab, koji se zove hab okosnice, ima veze od take do
take sa odeljenjskim liabovima, meusobno povezujui LAN-ove tri odeljenja. Konstrukcija
prikazana na slici 5.27 je konstrukcija haba sa vie nivoa (multi-tier hub design), zato to su
habovi rasporeeni u hijerarhiji. Mogu se takoe napraviti konstrukcije sa vie od dva nivoa - na
primer, jedan nivo za odeljenja, jedan nivo za kole unutar univerziteta (na primer, inenjerska
kola, poslovna kola itd.) i jedan nivo za najvii univerzitetski nivo.
|

5.6 . MEUSOBNE VEZE: HABOVI I KOMUTATORI 245 245 245 245

U konstrukciji sa vie nivoa, elu meusobno povezanu mreu zovemo LAN, a svaki od
odeljenjskih delova LAN-a (odnosno, odeljenjski hab i raunare koji su sa njim povezani)
zovemo segmentom LAN-a. Vano je zapaziti da svi segmenti LAN-a na slici 5.27 pripadaju
istom domenu kolizije; znai, kad god dva i li vie vorova u segmentu LAN-a predaju u isto
vreme, doi e do kolizija i svi vorovi koji predaju ui e u eksponencijalno odstupanje.
Meusobno povezivanje odeljenjskih LAN-ova pomou haba okosnice ima mnogih
prednosti. Prvo i pre svega, ono obezbeuje meuodeljenjsku komunikaciju izmeu raunara u
razliitim odeljenjima. Drugo, ono poveava maksimalno rasto-janje izmeu bilo kog para
vorova u LAN-u. Na primer, kod lOBaseT, maksimalno rastojanje izmeu vora i njegovog
haba je 100 metara; dakle, u jednom segmentu LAN-a, maksimalno rastojanje izmeu bilo kog
para vorova je 200 metara. Meusobnim povezivanjem habova, to maksimalno rastojanje moe
da se povea, zato Sto rastojanje izmeu direktno povezanih habova moe takoe da bude 100
metara kada se koriste upredene parice (a i vie ako se koriste optika vlakna). Trea korist je to
konstrukcija sa vie nizova obezbeuje izvestan stepen tolerancije pri moguem otkazu.
Preciznije, ako bilo koji od odeljenjskih habova pone da radi neispravno, hab okosnice moe da
otkrije problem i iskljui neispravan hab sa LAN-a; na taj nain, preostala odeljenja mogu da
nastave sa radom i komuniciraju dok se neispravan odeljenjski hab ne popravi.
Mada je hab okosnice koristan ureaj za meusobno povezivanje, on ima tri ozbiljna
ogranienja koja oteavaju njegovu primenu. Prvo i moda najvanije, kada su odeljenjski
LAN-ovi meusobno povezani pomou haba (ili repetitora), onda se nezavisni domeni kolizija
odeljenja pretvaraju u jedan veliki, zajedniki domen kolizije. Istraimo to pitanje u kontekstu
slike 5.27. Pre meusobnog povezivanja tri
odeljenja, svaki odeljenjski LAN imao je maksimalnu propusnu mo od 10 Mb/s, pa je
maksimalna zdruena propusna mo tri LAN-a bila 30 Mb/s. Ali, jednom kada su tri LAN-a
meusobno povezana pomou haba, svi raunari u tri odeljenja pripadaju istom domenu kolizija,
a maksimalna zdruena propusna mo je smanjena na 10 Mb/s.
Drugo ogranienje je to to, ako razliita odeljenja koriste razliite Ethernet tehnologije,
moe biti nemogue da se meusobno povezu odeljenjski habovi sa habom okosnice. Na primer,
ako neka odeljenja koriste lOBaseT, a ostala odeljenja lOOBaseT, onda je nemogue povezati
sva odeljenja bez stavljanja okvira u privremenu memoriju u taki meusobnog povezivanja;
kako su habovi u sutini repetitori i ne stavljaju okvire u privremenu memoriju, oni ne mogu da
meusobno povezuju segmente LAN-a koji rade na razliitim brzinama.
Tree ogranienje je to to svaka Ethernet tehnologija (10Base2, lOBaseT, lOOBaseT itd.)
ima ogranienje maksimalnog dozvoljivog broja vorova u domenu kolizija, maksimalnog
rastojanja izmeu dva raunara u domenu kolizija i maksimalnog dozvoljivog broja nivoa u
LAN-u sa vie nivoa, kao i geografskog dometa LAN-a sa vie nivoa.

5 . 6 . 2 Komutatori sloja veze podataka
Za razliku od habova koji su ureaji fizikog nivoa, komutatori sloja veze podataka - zvani
prosto komutatori - rade na Ethernet okvirima i zato su ureaji sloja-2. U stvari, kao potpuno
osposobljeni komutatori paketa, oni prosleduju okvire koristei LAN adrese odredita. Kada
okvir doe na interfejs komutatora, komutator ispituje adresu odredita sloja-2 okvira i
pokuava da prosledi okvir na interfejs koji vodi ka odreditu.
Na slici 5.28 prikazano je kako tri akademska odeljenja iz naeg prethodnog primera mogu
da se povezu pomou komutatora. Tri broja do komutatora su brojevi komutatorskih interfejsa.
Kada se odeljenja meusobno povezu pomou komutatora, kao na slici 5.28, opet celu
meusobno povezanu mreu zovemo LAN i opet svaki od odeljenjskih delova mree zovemo
segmentom LAN-a. Ali, za razliku od konstrukcije haba sa vie nivoa na slici 5.27, svaki
segment LAN-a je sada izolovani domen kolizije.
Komutatori mogu da prevazidu mnoge probleme koji postoje kod habova. Prvo, komutatori
dozvoljavaju meuodeljenjsku komunikaciju, dok istovremeno odravaju izolovane domene
kolizija za svako odeljenje. Drugo, komutatori mogu meusobno da povezuju razliite LAN
tehnologije, ukljuujui tu Ethernet od 10 Mb/s, 100 Mb/s i Gtgabit Ethernet. Tree, kada se za
meusobno povezivanje segmenata LAN-a koriste komutatori, nema ogranienja koliki LAN
moe da bude; u teoriji, ako se koriste komutatori, mogue je izgraditi LAN koji se prostire
preko cele zemaljske kugle. Dakle, kao to emo diskutovati na kraju ovog odeljka, komutatori
rade u punom dupleksu i obezbeuju komutaciju preicom (cut-(hrough).

4.

2 POGLAVLJE 5 SLOJ VEZE PODATAKA 1 LOKALNE MREE RAUNARA
5.6 . MEUSOBNE VEZE: HABOVI I I I I KOMUTATORI 469
Na slici 5.29 prikazano je kako institucija sa vie odeljaka i vie kritinih servera moe da
razmesti kombinaciju habova, komutatora i rutera. Na slici 5.29 svako od tri odeljenja ima svoj
sopstveni Ethernet segment od 10 Mb/s, sa svojim sop-stvenim habom. Zato to svaki
1
odeljenjski
hab ima vezu sa komutatorom, celoku-pan meuodeljenjski saobraaj je ogranien na Etherment
segment odeljenja. I veb i potanski serveri imaju namenski pristup komutatoru od 100 Mb/s. Najzad,
ruter koji vodi na Internet, ima pristup komutatoru od 100 Mb/s. Zapazite da ovaj komutator ima
najmanje tri interfejsa od 10 Mb/s i tri interfejsa od 100 Mb/s.

Prosleivanje i filtriranje komutatora
Filtriranje je sposobnost komutatora da odredi da li bi okvir trebalo da se prosledi nekom njegovom
interfejsu, ili samo da se odbaci. Prosleivanje je sposobnost da se odrede interfejsi ka kojima bi
okvir trebalo da se usmeri, a onda da se okvir i usmeri ka tim interfejsima. Filtriranje i prosleivanje
komutatora se rade pomou tabele komutatora. Tabela komutatora sadri stavke za neke, ali ne
obavezno i za sve vorove u LAN-u. Stavka u tabeli komutatora sadri (1) MAC adresu vora, (2)
interfejs komutatora koji vodi do vora i (3) vreme kadaje stavka za vor upisana u tabelu. Primer
tabele komutatora za LAN sa slike 5.28 prikazan je na slici 5.30. Iako ovaj opis prosleivanja okvira
moe da zvui slino objanjenju prosleivanja datagrama dalom u poglavlju 4, ubrzo emo videti da
postoje znaajne razlike. Ovde zapaamo da su adrese koje koriste komutatori MAC adrese, a ne
adrese mrenog
sloja. Uskoro emo takoe videti da se tabela komutatora konstruie na razliit nain od tabela
rutiranja.
Da bismo razumeli kako rade filtriranje i prosleivanje komutatora, pretpostavimo da okvir sa
adresom odredita DD-DD-DD-DD-DD-DD stie na komutator na interfejsu x. Komutator indeksira
svoju tabelu sa MAC adresom
Komutator

247 POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA 5.6 MEUSOBNE VEZE: HABOVI I KOMUTATORI 471

DD-DD-DD-DD-DD-DD i pronalazi svoj odgovarajui interfejs y za koji se zna da vodi do
adrese odredita DD-DD-DD-DD-DD-DD. (Uskoro emo videti ta se deava ako adresa
DD-DD-DD-DD-DD-DD nije u tabeli.)
Ako je x jednako y, onda okvir dolazi iz segmenta LAN-a koji sadri adapter
DD-DD-DD-DD-DD-DD. Nema potrebe da se okvir prosleduje na bilo koji drugi interfejs,
komutator obavlja funkciju filtriranja odbacujui okvir.
Ako x nije jednako y, onda okvir treba da se prosledi segmentu LAN-a prikljuenom na
interfejs y. Komutator obavlja svoju funkciju prosleivanja stavljajui okviru izlaznu
privremenu memoriju koja prethodi interfejsu y.
Ova jednostavna pravila doputaju komutatoru da odri razdvojene domene kolizija za svaki od
razliitih segmenata LAN-a koji su prikljueni na njegove interfejse. Pravila takoe dozvoljavaju
da dva skupa vorova na razliitim segmentima LAN-a komuniciraju istovremeno, bez
meusobnog ometanja.
Hajde da proemo kroz ova pravila za mreu na slici 5.28 i njenu tabelu komutatora na slici
5.30. Pretpostavite da okvir sa adresom odredita 62-FE-F7-11-89-A3 stie u komutator sa
interfejsa 1. Komutator ispituje svoju tabelu i vidi da je odredite na LAN segmentu povezanom
sa interfejsom 1 (odnosno LAN-om Elektro ine-njerstva). To znai daje okvir ve bio difuzno
poslat u segment LAN-a koji sadri odredite, Komutator zato filtrira (odnosno, odbacuje) okvir.
Sada pretpostavite da okvir sa istom adresom odredita stie sa interfejsa 2. Komutator ponovo
ispituje svoju tabelu i vidi daje odredite u pravcu interfejsa 1; on, dakle, prosleduje okvir na
izlaznu privremenu memoriju koja prethodi interfejsu 1. Iz ovog primera trebalo bi da bude jasno
da, dok je tabela komutatora potpuna i tana, komutator izoluje ode-ljenjske domene kolizija,
dok istovremeno doputa odeljenjima da komuniciraju.

Habovi u odnosu na komutatore
Setite se da kada hab prosleduje okvir u link, on samo alje bitove na link, ne trudei se da
oseti da li se na njemu trenutno odvija neki drugi prenos. Za razliku od toga, kada komutator eli
da prosledi okvir na link, on pokree algoritam CSMA/CD koji je objanjen u odeljku 5.3.
Posebno, komutator odustaje od prenosa ako oseti da je u toku prenos sa nekog drugog vora u
segmentu LAN-a u koji on eli da poalje okvir; pored toga, komutator koristi eksponencijalno
odstupanje kada jedan od njegovih prenosa za rezultat ima koliziju. Na taj nain, komutatori se u
velikoj meri ponaaju kao adapteri vorova. Ali, govorei tehniki, oni nisu adapteri vorova,
zato to ni komutator ni njegovi interfejsi nemaju MAC adrese. Setite se da adapter vora uvek
umee svoju MAC adresu u adresu izvora svakog okvira koji prenosi. S druge strane, komutator
ne menja izvornu adresu okvira.
Znaajna karakteristika komutatora je da mogu da se upotrebe za kombinova-nje Ethernet
segmenata koji koriste razliite Ethernet tehnologije. Na primer, ako
na slici 5.28 Elektro inenjerstvo ima Ethernet 10Base2, Raunarska tehnika Ethernet
lOOBaseT, a Sistemsko inenjerstvo Ethernet IOBaseT, onda moe da se kupi komutator koji
moe da povee ta tri LAN-a. Pomou komutatora Gigabit Ethernet, mogue je imati dodatnu
vezu od 1 Gb/s sa ruterom, koji je sa svoje strane povezan sa irom univerzitetskom mreom.
Kao to smo ranije pomenuh, ova osobina da se meusobno povezuju razliite brzine linkova
nije raspoloiva kod habova.
Takoe, kada se kao ureaji za meusobno povezivanje koriste komutatori, nema
teorijskog ogranienja za geografski obim LAN-a. U teoriji, moemo da izgradimo LAN koji se
prostire na celoj zemaljskoj kugli, meusobno povezujui habove u dugoj, linearnoj topologiji,
gde je svaki par susednih habova meusobno povezan pomou komutatora. Kod ovakve
konstrukcije, svaki hab ima sopstveni domen kolizije, a nema ogranienja koliko LAN moe da
bude dugaak. Meutim, uskoro emo videti da nije poeljno graditi veoma velike mree
koristei iskljuivo komutatore kao ureaje za meusobno povezivanje - velikim mreama su
takoe potrebni ruteri.

Samoobuavanje
Komutator ima izvanrednu osobinu (posebno za ve prezaposlenog administratora mree)
da se njegova tabela pravi automatski, dinamiki i autonomno - bez ikakve intervencije od
strane administratora mree ili protokola konfiguracije. Drugim recima, komutatori se sami
obuavaju. Ova sposobnost se ostvaruje na sledei nain:
1. Tabela komutatora je u poetku prazna.
2. Kada okvir stigne na jedan od interfejsa, a adresa odredita okvira nije u tabeli, komutator
prosleduje kopije okvira u privremene memorije koje prethode svim drugim interfejsima.
(Na svakom od ovih drugih interfejsa, okvir se prenosi u segment LAN-a koristei
CSMA/CD).
3. Za svaki primljeni okvir, komutatoru svojoj tabeli skladiti ( 1 ) MAC adresu u polju za
adresu izvora okvira, (2) interfejs sa koga je okvir stigao, (3) tekue vreme. Na taj nain,
komutator zapisuje u svojoj tabeli segment LAN-a u kome se nalazi vor poiljalac. Ako
svaki vor u LAN-u na kraju poalje okvir, onda e svaki vor na kraju biti zapisan u tabeli.
4. Kada vor stigne na jedan od interfejsa a adresa odredita okvira je u tabeli, onda komutator
prosleduje okvir na odgovarajui interfejs.
5. Komutator brie adresu u tabeli ako se posle odreenog vremenskog perioda (vreme
starenja, aging time) ne primi nijedan okvir sa tom adresom kao adresom izvora. Na taj
nain, ako se PC zameni drugim PC-jem (sa razliitim adapterom), LAN adresa prvobitnog
PC-ja e na kraju biti uklonjena iz tabele komutatora.

Hajde da proemo kroz osobinu samoobuavanja za mreu na slici 5.28 i njenu odgovarajuu
tabelu komutatora na slici 5.30. Pretpostavite da u vreme 9:39 okvir

2 POGLAVLJE 5 SLOJ VEZE PODATAKA l LOKALNE MREE RAUNARA
5.6 . MEUSOBNE VEZE: HABOVI I KOMUTATORI
473
sa adresom izvora 01-12-23-34-45-56 stie sa interfejsa 2. Pretpostavite da la adresa nije u tabeli
komutatora. Tada komutator dodaje novu stavku u tabeli, kao to je prikazano na slici 5.31.
Nastavljajui sa ovim istim primerom, pretpostavimo daje vreme zasta-revanja za ovaj
komutator 60 minuta i da nijedan okvir sa izvornom adresom 62-FE-F7-] 1-89-A3 ne stie u
komutator izmeu 9:32 i 10:32. Onda u trenutku 10:32 komutator brie tu adresu iz svoje tabele.
Komutatori su plug-an-play ureaji zato to ne zahtevaju nikakvu intervenciju od strane
administratora mree ili korisnika. Administrator mree koji eli da instalira komutator ne radi
nita vie od prikljuivanja segmenata LAN-a na inter-fejse komutatora. Administrator mree ne
treba da konfigurie tabele komutatora u vreme instalacije ili kada se raunar ukloni iz jednog od
segmenata LAN-a.

Namenski pristup i puni dupleks
Komutator sa velikim brojem interfejsa omoguava direktne konekcije izmeu raunara i
komutatora. Kada raunar ima direktnu konekciju sa komutatorom (a ne deljenu LAN
konekciju), kae se da ima namenski pristup. Na slici 5.32, komutator omoguava namenski
pristup za est raunara.
Komutator i sa njim direktno povezani raunari rade u reimu punog dupleksa. Hajde da
vidimo kako se to radi. Da bismo ovu diskusiju konkretizovali, pretpo-siavimo da svaka
konekcija na slici 5.32 korislj dva paTa upredenih parica bakarnih provodnika (kao u lOBaseT i
lOOBaseT), jedan par za predaju od raunara do komutatora, a drugi par za predaju od
komutatora do raunara. Zbog namenskog pristupa, kada raunar A predaje okvir na svom
uzvodnom paru provodnika, nema mogunosti da e okvir doi u koliziju sa predajom iz nekog
drugog raunara ili iz komutatora. Slino tome, zato to komutatori "memoriu i prosleuju",
komutator e predavati najvie jedan okvir istovremeno na bilo kome od nizvodnih parova pro-
vodnika. Dakle, sa direktnim uzvodnim i nizvodmm konekcijama, nisu potrebni ni detekcija
kolizija ni prepoznavanje nosioca. U stvari, svaki link postaje link od take do take, ime se
izbegava potreba za bilo kakvim protokolom za pristup medijumu! Dakle, onemoguavanje u
svakom adapteru prepoznavanja nosioca, detekcije kolizija i vraanja predavanih podataka na
ulaz prijemnika, stvara se kanal punog duple-
ksa izmeu svakog raunara i komutatora. Na primer, na slici 5.32, raunar A moe da poalje
datoteku u A' dok B alje datoteku u B', a C alje datoteku u C\ Ako svaki raunar ima
adaptersku karticu za 10 Mb/s, onda e ukupna propusna mo za vreme tri simultana prenosa
datoteka biti 30 Mb/s. Ako A i A' imaju adaptere od 100 Mb/s, a preostali raunari imaju
adaptere od 10 Mb/s, onda e ukupna propusna mo za vreme tri simultana prenosa datoteka biti
120 Mb/s.
Komutacija preicom
Pored velikog broja interfejsa, podrke za mnotvo vrsta fizikih medijuma, brzina prenosa i
privlanih svojstava upravljanja mreama, proizvoai komutatora esto mame kupce izjavama
da njihovi komutatori koriste komutaciju preicom (cut-through), a ne komutaciju paketa sa
memorisanjem i prosledivanjem, koju koriste ruteri i komutatori sloja veze. Razlika izmeu
memorisanja i prosledivanja i komutacije preicom je u nijansi. Da biste razumeli tu razliku,
posmatrajte paket koji se prosleuje kroz komutaciju paketa (odnosno ruter ili komutator). Kao
stoje objanjeno u odeljku 4.4, paket stie u komutator preko ulaznog porta, i naputa komutator
preko izlaznog porta. Na izlaznom portu moe da bude ili da ne bude drugih paketa koji ekaju u
izlaznoj privremenoj memoriji izlaznog porta. Kada ima paketa u izlaznoj privremenoj memoriji,
nema apsolutno nikakve razlike izmeu komutacije sa memorisanjem i prosledivanjem i
komutacije preicom. Dve tehnike komutacije razlikuju se samo kada je izlazna privremena
memorija prazna.

249 249 249 249 POGLAVLJE 5 SLOJ VEZE PODATAKA l LOKALNE MREE RAUNARA

5.6 MEUSOBNE VEZE: HABOVI I KOMUTATORI 475 475 475 475
Setite se iz poglavlja 1 da, kada se paket prosleduje kroz komutator paketa sa
memorisanjem i prosleivanjem, on se prvo prikupi i memorie u celosti, pre nego to komutator
pone da ga predaje na izlaznom linku. U sluaju kada se izlazna privremena memorija isprazni
pre nego to je ceo paket stigao u komutator, ovo prikupljanje stvara kanjenje memorisanja i
prosleivanja u komutatoru - kanjenje koje doprinosi ukupnom kanjenju od jednog do drugog
kraja (proitajte odeljak 1.6). Gornja granica tog kanjenja je L/R, gde je L duina paketa, a R
brzina prenosa ulaznog linka. Zapazite da paketu preti kanjenje memorisanja i prosleivanja
samo ako se izlazna privremena memorija isprazni pre nego to ceo paket stigne u komutator.
Kod komutacije preicom, ako se privremena memorija isprazni pre nego to ceo paket
stigne, komutator moe da pone da predaje prednji deo paketa dok njegov zadnji deo nastavlja
da dolazi. Naravno, pre predaje paketa na izlazni link, mora prvo da stigne deo paketa koji sadri
adresu odredita. (Ovo malo kanjenje je neizbeno za sve vrste komutacije, zato to komutator
mora da odredi odgovarajui izlazni link.) Sve u svemu, sa komutacijom preicom paket ne mora
da bude potpuno memorisan pre nego to se prosledi; umesto toga, paket se prosleduje kroz
komutator kada je izlazni link slobodan. Ako je izlazni link mrea sa viestrukim pristupom koja
se deli sa drugim raunarima (na primer, izlazni link se povezuje sa habom), onda komutator
takoe mora da oseti da li je link slobodan pre nego to direktno prosledi" paket.
Da bismo dobili izvestan uvid u razliku izmeu komutacije sa memorisanjem i
prosleivanjem i komutacije preicom, hajde da se podsetimo na analogiju sa karavanom, koja je
uvedena u odeljku 1.6. U toj analogiji, postoji autoput sa povremenim naplatnim kioscima, gde u
svakom kiosku postoji po jedan slubenik. Na autoputu se nalazi karavan od deset vozila koja
putuju zajedno, svako istom konstantnom brzinom. Vozila u karavanu su jedina vozila na
autoputu. Svaki naplatni kiosk opsluuje vozila konstantnom brzinom, tako da kada vozila
napuste naplatni kiosk, ona su na podjednakom meusobnom rastojanju. Kao i ranije, moemo
da razmiljamo o karavanu kao daje paket, o svakom vozilu u karavanu kao daje bit, a o brzini
naplatnog kioska kao o brzini prenosa linka. Sada razmotrite ta rade vozila iz karavana kada
stignu do naplatnog kioska. Ako svako vozilo nastavlja direktno do naplatnog kioska sve do
pristizanja, onda je naplatni kiosk-preicu. Ako, s druge strane, svako vozilo eka na ulasku dok
sva ostala vozila karavana ne stignu, onda je naplatni kiosk sa memorisanjem i prosleivanjem.
Jasno je da naplatni kiosk sa memorisanjem i prosleivanjem zadrava karavan vie od
naplatnog kioska-preice.
Komutator preicom moe da smanji kanjenje paketa od kraja do kraja, ali za koliko? Kao
to smo ranije pomenuli, maksimalno kanjenje memorisanja i prosleivanja je L/R, gde je L
veliina paketa, a R brzina ulaznog linka. Maksimalno kanjenje je priblino l,2-ms za Ethernet
od 10 Mb/s i 0,12 ms za Ethernet od 100 Mb/s (odgovarajue za Ethernet paket maksimalne
veliine). Dakle, komutator preicom smanjuje kanjenje za samo 0,12 do 1,2 ms, a do tog
smanjenja dolazi samo kadaje izlazni link malo optereen. Koliko je znaajno to kanjenje?
Verovatno ne mnogo u praktinim primenama.
Komutatori u odnosu na rutere
Kao to smo nauili u poglavlju 4, ruteri su komutatori za memorisanje i prosleivanje paketa,
koji svoj posao obavljaju koristei adrese mrenog sloja. Mada je komutator takode komutator
za memorisanje i prosleivanje paketa, on se sutinski razlikuje od rutera u tome to prosleduje
pakete koristei MAC adrese. Dok je ruter komutator paketa sloja-3, komutator komutira pakete
na sloju-2.
ak iako su komutatori i ruteri sutinski razliiti, administratori mree esto moraju da
biraju koji od njih e da upotrebe kada instaliraju ureaj za meusobno povezivanje. Na primer,
za mreu na slici 5.28, administrator mree bi mogao lako da upotrebi ruter umesto komutatora.
Zaista, ruter bi takoe drao tri domena kolizija razdvojeno, dok bi dozvoljavao komunikaciju
izmeu odeljenja. Imajui u vidu da su i komutatori i ruteri kandidati za ureaje meusobnog
povezivanja, koji su razlozi za i protiv ova dva pristupa?
Razmotrimo prvo razloge za i protiv u raspravi o primeni komutatora. Kao stoje ranije
pomenuto, komutatori su plug-and-play, to je osobina koju cene svi prezaposleni administratori
mree na svetu Komutatori takode imaju relativno velike brzine filtriranja i prosleivanja paketa
- kao to je prikazano na slici 5.33, komutatori treba samo da obrade pakete navie ka sloju 2,
dok ruteri moraju da obrauju okvire navie ka sloju 3. S druge strane, topologija komutirane
mree je ograniena na obu-hvatno stablo. Takoe, velika komutirana mrea bi zahtevala velike
ARP tabele u vorovima i generisala bi znaajan ARP saobraaj i obradu. Pored toga,
komutatori ne nude nikakvu zatitu protiv difuznih oluja - ako jedan od raunara poludi i pone
da predaje beskrajan niz difuznih Ethemet okvira, komutatori e prosleivati sve te okvire, to
dovodi do pada itave mree.
Razmotrimo sada razloge za i protiv u raspravi o primeni rutera. Zato stoje mreno
adresiranje esto hijerarhijsko (a ne linearno kao MAC adresiranje), paketi obino ne krue kroz
rutere. ak i kada mrea ima redundantne putanje. (Meutim, paketi mogu da krue kada su
tabele rutera pogreno konfigurisane; ali, kao to smo nauili u poglavlju 4, IP koristi specijalno
polje zaglavlja datagrama da ogranii kruenje.) Dakle, paketi nisu ogranieni na obuhvatno
stablo i mogu da koriste najbolju putanju izmeu izvora i odredita. S obzirom na to da ruteri
nemaju ogranienje obuhvatnog stabla, oni su dozvolili da se Internet izgradi sa bogatom
topologijom koja ukljuuje, na primer, viestruke aktivne linkove izmeu Evrope i Severne
Amerike. Drugo svojstvo rutera je da oni obezbeuju zatitu pomou mrene barijere od difuznih
oluja sloja-2. Meutim, moda je najvei nedostatak rutera to nisu plug-and-play, pa oni i
raunari koji su na njih prikljueni zahtevaju da se konfiguriu IP adrese. Takoe, ruteri esto
imaju da obave obimniji posao po paketu od komutatora, zato to moraju da obraduju i pakete u
sloju-3.

250 250 250 250
POGLAVLJE 5 SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA 5.7 . PPP: PROTOKOL OD TAKE TO TAKE
250 250 250 250

Imajui u vidu da i komutatori i ruteri imaju svoje razloge za i protiv, kada bi jedna
institucionalna mrea (na primer, mrea univerzitetskog naselja ili korporativna mrea) trebalo da
koristi komutatore, a kada rutere? Po pravilu, male mree koje se sastoje od nekoliko stotina
raunara, imaju nekoliko segmenata LAN-a. Komutatori su dovoljni za ove male mree, zato to
oni lokalizuju saobraaj i poveavaju zdruenu propusnu mo bez zahtevanja bilo kakvog
konfigurisanja IP adresa. Ali uobiajeno je da vee mree, koje se sastoje od hiljada raunara,
ukljuuju rutere unutar mree (pored komutatora). Ruteri obezbeuju robustniju izolaciju
saobraaja, kontroliu difuzne oluje i koriste inteligentnije" putanje izmeu raunara u mrei.
U ovom odeljku nauili smo da habovi, komutatori i ruteri mogu da se koriste kao ureaji
za meusobno povezivanje raunara i segmenata LAN-a. U tabeli 5.1 zbirno su date
karakteristike svakog od ovih ureaja za meusobno povezivanje. Veb lokacija kompanije Cisco
daje veliki broj poreenja razliitih tehnologija za meusobno povezivanje [Cisco Switches
2004],
5.7 PPP: protokol od take to take
Najvei deo nae diskusije o protokolima veze podataka do sada je bio usredsreen na protokole
za difuzne kanale. U ovom odeljku objasniemo protokol veze podataka za linkove od take do
take - PPP, protokol od take do take {point-to-point protocol). S obzirom na to da je PPP
uobiajen protokol koji se koristi za povezivanje kunih raunara i ISP-a, on je van svake
sumnje jedan od danas najire prime-njivanih protokola veze podataka, Drugi znaajan protokol
u dananjoj upotrebi je HDLC (high-level data link control); radi objanjenja HDLC-a, proitajte
[Spragins 1991], Nae objanjenje jednostavnijeg protokola PPP e nam omoguiti da istraimo
mnoge znaajne karakteristike protokola veze podataka od take do take.
Kao to mu i samo ime govori, protokol od take do take (PPP) [RFC 1661; RFC 2153] je
protokol sloja veze podataka koji radi nad linkom od take do take - linkom koji direktno
povezuje dva vora, po jednog na svakom svom kraju. Link od take do take na kome radi PPP
bi mogao da bude serijska telefonska linija (na primer, veze preko modema 56K), link
SONET/SDH, veza X.25, ili ISDN vodova. Kao to je napomenuto, PPP je postao protokol koji
se bira za povezivanje kunih korisnika sa njihovim posrednicima Internet usluga preko pozivne
konekcije.
Pre nego to zaronimo u detalje PPP-a, pouno je da ispitamo originalne zahteve koje je
organizacija IETF postavila za konstrukciju protokola PPP [RFC 1547]:
Stavljanje paketa u okvire. Poiljalac protokola PPP sloja veze podataka mora da bude
sposoban da preuzme paket mrenog nivoa i enkapsulira ga u okvir PPP sloja veze podataka,
takav da e primalac moi da identifikuje poetak i kraj i okvira veze podataka i paketa
mrenog sloja unutar okvira.
Transpareninost. Protokol PPP ne srne da postavi nikakva ogranienja na podatke koji se
pojavljuju na paketu mrenog sloja (zaglavlja ili podatke). Tako, na primer, protokol PPP ne
moe da zabrani upotrebu izvesnih kombinacija bitova u paketu mrenog sloja. Na ovo
pitanje vratiemo se uskoro u naem objanjenju popunjavanja bajtova.
Viestruki protokoli mrenog sloja. Protokol PPP mora da bude u stanju da istovremeno
podri vie protokola mrenog sloja (na primer, IP i DECnet) koji rade na istom fizikom
linku u isto vreme. Ba kao to se od IP protokola zahteva da multipleksira razliite
protokole transportnog nivoa (na primer, TCP i UDP) na istoj vezi od jednog do drugog
kraja, tako i PPP mora da bude u stanju da multipleksira razliite protokole mrenog sloja po
jednoj vezi od take do take. Ovaj zahtev znai da e, kao minimum, PPP verovatno
zahtevati polje tipa protokola" ili neki slian mehanizam, tako da prijemna strana PPP moe
da demultipleksira primljeni okvir navie do odgovarajueg protokola mrenog sloja.
Vie vrsta linkova. Pored sposobnosti istovremenog prenosa vie protokola vieg nivoa, PPP
mora takoe da bude u stanju da radi na irokom skupu vrsta linkova, ukljuujui tu linkove
koji su serijski (prenose jedan bit istovremeno u datom

5.7 PPP: PROTOKOL OD TAKE TO TAKE 251

pravcu) ili paralelni (prenose bitove paralelno), sinhroni (prenose signal generatora takta uz
bitove podataka) ili asinhroni, male ili velike brzine, elektrini ili optiki.
Otkrivanje greaka. PPP prijemnik mora da bude sposoban da otkrije greke u primljenom
okviru.
ivotnost konekcije. PPP mora da bude u stanju da otkrije otkaz na nivou linka (na primer,
nesposobnost da se prenose podaci od predajne do prijemne strane lirika) i da signalizira tu
pojavu mrenom sloju.
Usaglaavanje adrese mrenog sloja. PPP mora da obezbedi mehanizam za komuniciranje
mrenih slojeva (na primer, IP) da bi saznali ili konfigttrisali jedni drugima adrese mrenog
sloja.
Jednostavnost. Od PPP-a se zahtevalo da ispuni mnotvo dodatnih zahteva pored onih koje
smo gore naveli. Prvi i najvaniji od svih bio je onaj za Jednostavnou". U RFC-u 1547 stoji
da bi kljuna re za protokol od take do take trebalo da bude jednostavnost". Zaista teak
zahtev, imajui u vidu sve druge zahteve koji su postavljeni za projektovanje PPP-a! Vie od
50 RFC-ova (zahteva za komentarima) definiu razliite aspekte ovog Jednostavnog"
protokola!
Iako moe da izgleda kako je mnogo zahteva postavljeno za projektovanje PPP-a, situacija
bi stvarno mogla da bude jo mnogo tea! Projektni zahtevi za PPP takoe eksplicitno belee i
funkcionalnosti koje nisu zahtevi za implementaciju u PPP-u:
Ispravljanje greaka. Zahteva se da PPP otkrije, ali ne i da ispravi greke.
Kontrola toka. Od prijemnika PPP oekuje se da moe da prima okvire punom brzinom
fizikog sloja. Ako vii sloj ne moe da preuzima pakete tom punom brzinom, onda je na
fizikom sloju da odbacuje pakete ili da prigui predajnik na viem nivou. Odnosno, umesto
da PPP predajnik smanjuje sopstvenu brzinu prenosa, odgovornost protokola vieg nivoa je da
usporava brzinu kojom se paketi isporuuju PPP-u za slanje.

Sekvenciranje. Od PPP se ne zahteva da isporuuje okvire prijemniku linka u istom
redosledu u kome ih je poslao predajnik linka. Zanimljivo je zapaziti da, dok je ta
fleksibilnost u saglasnosti sa modelom IP usluga (koji dozvoljava IP paketima da se
isporuuju od take do take u bilo kom redosledu), drugi protokoli mrenog sloja koji rade
nad PPP-om 2aista zahtevaju isporuku paketa u redosledu.
linkovi za vie stanica- PPP treba da radi samo na linkovima koji imaju jednog poiljaoca i
jednog primaoca. Drugi protokoli slbja veze podataka (na primer, HDLC) mogu da prihvate
vie primalaca na linku (scenarid slian Ethemetu).
Polo smo razmotrili ciljeve (i one koji to nisu) projekta PPP, hajde da pogledamo kako on
ispunjava te ciljeve.
5.7.1 Pravljenje podataka u PPP okvire
Na slici 5.34 prikazanje PPP okvir podataka koji je napravljen slino HDLC-u [RFC 1662J.
Okvir PPP sadri sledea polja:
Polje indikatora. Svaki PPP okvir poinje i zavrava se jednobajtnim poljem indikatora sa
vrednou 01111110.
Polje adrese. Jedina mogua vrednost za ovo polje je 11111111.
Kontrolno polje. Jedina mogua vrednost za ovo polje je 00000011. S obzirom na to da i
adresno i kontrolno polje trenutno mogu imati samo fiksne vrednosti, mogli bismo se zapitati
zato su polja uopte i definisana. U specifikaciji PPP [RFC 1662] kae se da druge vrednosti
mogu da se definiu kasnije", mada ih do danas niko nije definisao. Imajui u vidu da ta
polja imaju fiksne vrednosti, PPP dozvoljava predajniku da prosto ne alje adresne i
kontrolne bajtove, tedei tako dva bajta dodatnog optereenja u PPP okviru.
Protokol. Polje za protokol saoptava PPP prijemniku protokol gornjeg sloja kome pripadaju
primljeni enkapsulirani podaci (odnosno, sadraj informacionog polja PPP okvira). Po
prijemu PPP okvira, PPP prijemnik e proveriti njegovu ispravnost i zatim proslediti
enkapsulirane podatke odgovarajuem protokolu. RFC 1700 i RFC 3232 definiu 16-bitne
kodove protokola koje koristi PPP. Nas zanima IP protokol (odnosno, podaci enkapsulirani u
PPP okviru u vidu IP datagrama), koji ima heksadecimalnu vrednost 21; drugi protokoli
mrenog sloja su npr. AppleTalk (29) i DECNet (27); PPP protokol kontrole linka
(heksadecimalno C021) o kome detaljno govorimo u sledeem odeljku; i IP kontrolni
protokol, IPCP (8021). Ovaj poslednji protokol PPP poziva kada se prvi put aktivira link, da
bi konfigurisao vezu izmeu ureaja sposobnih za IP na svakom kraju linka (pogledajte dalje
u tekstu).
Informacije. Ovo polje sadri enkapsulirani paket (za PPP to su podaci) koji je poslao
protokol gornjeg sloja (na primer, IP). Maksimalna podrazumevana duina polja za
informacije je 1500 bajtova, mada to moe da se promeni kada se link prvi put konfigurie,
kao stoje objanjeno dalje u tekstu.
Kontrolni zbir. Polje za kontrolni zbir koristi se za otkrivanje greaka u prenesenom okviru.
Ono koristi ili dvobajtni ili etvorobajtni standardni HDLC ciklini redundantni kod.

5.7 . PPP: PROTOKOL OD TAKE TO TAKE 481

Popunjavanje bajtova
Pre nego to zakljuimo nae izlaganje o pravljenju PPP okvira, razmotrimo problem koji se
javlja kada neki protokol koristi odreeni ablon bitova u polju indikatora kako bi opisao
poetak ili kraj okvira. Sta se deava ako se ablon indikatora i sam pojavljuje na nekom drugom
mestu u paketu? Na primer, ta se dogaa ako se vrednost polja indikatora 01111110 pojavljuje
u polju za informacije? Da li e prijemnik neispravno otkriti kraj PPP okvira?
Jedan od naina da se rei ovaj problem bio bi da PPP zabrani protokolu gornjeg sloja da
alje podatke koji sadre ablon bitova polja indikatora. Zahtev za transpa-rentnou PPP-a, o
kome smo ranije diskutovali, odstranjuje ovu mogunost. Alternativno reenje, ono koje je
preuzeto u PPP-u i mnogim drugim protokolima je da se koristi tehnika poznata kao
popunjavanje bajtova.
PPP definie specijalan kontrolni bajt, 01111101. Ako se sekvenca indikatora, 01111110
pojavljuje bilo gde u okviru, izuzev u polju indikatora, PPP stavlja ispred tog sluaja ablona
indikatora kontrolni bajt. To znai da popunjava" (dodaje) kontrolni bajt u niz podataka koji se
prenosi, pre 01111110, da bi ukazao da bajt 01111-110 koji sledi nije vrednost indikatora nego, u
stvari, stvarni podatak. Prijemnik koji vidi 01111110 kome prethodi 01111101 e, naravno,
ukloniti popunjen kontrolni bajt da bi rekonstruisao originalne podatke. Slino tome, ako se sam
ablon kontrolnog iskonog bajta pojavi u stvarnim podacima, njemu takoe mora da prethodi
popunjen kontrolni bajt. Na taj nain, kada prijemnik ugleda jedan kontrolni bajt u nizu podataka,
on zna daje bajt bio popunjen u tom nizu. Par kontrolnih bajtova jedan do drugog Znai da se
jedan od njih pojavljuje u originalnim podacima koji se alju. Na slici 5.35 ilustrovano je PPP
popunjavanje bajtova. (U stvari, PPP takoe vri operaciju eksluzivno ILI na bajtu podataka sa
heksadecimalnom vrednou 20, a kome je prethodio kontrolni bajt, stoje detalj koji emo radi
jednostavnosti ovde preskoiti,)

5.7.2 PPP protokol kontrole linka (LCP) i protokoli kontrole mree
Do sada smo videli kako se PPP okviri alju preko linka od take do take. Ali, kako se
inicijalizuje link kada se raunar ili ruter na jednom kraju PPP linka ukljue prvi put?
Inicijalizacija, odravanje, izvetavanje o grekama i zatvaranje PPP linka obavlja se upotrebom
PPP protokola za kontrolu linka (LCP) i familije PPP protokola za kontrolu mree.
Pre nego to se bilo kakav podatak razmeni preko PPP linka, dva ravnopravna ureaja (po
jedan na svakom kraju PPP linka) moraju prvo da obave prilino mnogo rada da bi konfigurisati
link, na nain veoma slian onom na koji TCP poiljalac i primalac moraju da izvedu trostruku
sinhronizaciju (proitajte odeljak 3.5) da bi podesili parametre TCP konekcije pre nego to pone
prenos TCP segmenta podataka, Na slici 5.36 Hustrovan je dijagram stanja za protokol LCP za
konfigurisanje, odravanje i zatvaranje PPP linka.

POGLAVLJE 5 SLOJ VEZE PODATAKA I I I I LOKALNE MREE RAUNARA
253 5.8 . VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE 483

posredovanje). LCP opcije konfiguracije ukljuuju maksimalnu veliinu okvira za link,
specifikaciju protokola za proveru autentinosti (ako postoji) koji treba da se koristi i opciju da
se preskoi upotreba adresnih i kontrolnih polja u PPP okvirima.
Jednom kadaje link uspostavljen, opcije linka dogovorene i provera autentinosti (ako je
ima) izvrena, onda dve strane PPP linka meusobno razmenjuju pakete za kontrolu mree
specifine za mreni sloj. Ako IP radi preko PPP linka, koristi se IP kontrolni protokol [RFC
1332] da bi se konfigurisali moduli IP protokola na svakom kraju PPP linka. Podaci IPCP se
prenose unutar PPP okvira (ija je vrednost polja za protokol 8021), ba kao to se podaci LCP
prenose u PPP okviru. IPCP doputa da dva IP modula razmenjuju ili konfiguriu svoje IP adrese
i pregovaraju da li e njihovi IP datagrami biti, ili nee biti poslati u komprimovanom obliku.
Slini protokoli za kontrolu mree definisani su i za druge protokole mrenog sloja, kao to su
DECnet [RFC 1762] i AppleTalk [RFC 1378], Jednom kada se konfigurie mreni sloj, PPP
moe da pone sa slanjem datagrama mrenog sloja - link je u otvorenom stanju i podaci poinju
da teku preko PPP linka. LCP okvir sa zahtevom za eho i okvir sa eho odzivom mogu da se
razmene izmeu dve krajnje take PPP-a da bi se proverilo stanje linka.
PPP link ostaje konfigurisan za komunikaciju sve dok se ne poalje LCP paket sa zahtevom
za zavretak. Ako se LCP okvir sa zahtevom za zavretak poalje sa jednog kraja PPP linka i na
njega odgovori sa LCP okvirom za potvrdu zavretka, link ulazi u mrtvo stanje.
Sve u svemu, PPP je protokol veze podataka pomou koga dve stanice nivoa linka
razmenjuju PPP okvire koji sadre datagrame mrenog sloja. Osnovne komponente PPP-a su:
Pravljenje okvira. Metoda za enkapsuliranje podataka u PPP okvir, koja identifikuje poetak
i kraj okvira i otkriva greke u okviru.
Protokol kontrole linka. Protokol za inicijalizovanje, odravanje i ukidanje PPP linka.
Protokoli za kontrolu mree. Skup protokola, po jedan za svaki protokol gornjeg sloja mree,
koja doputa modulima mrenog sloja da se sami konfiguriu pre nego to datagrami
mrenog nivoa ponu da teku preko PPP linka.

5. 8 Vizuelizacija linka: mrea kao sloj veze
Imajui u vidu da se u ovom poglavlju bavimo protokolima sloja veze podataka i da se sada
primiemo njegovom kraju, hajde da razmislimo koliko se razvilo nae razu-mevanje termina
link. Poeli smo ovo poglavlje sagledavanjem linka kao fizikog provodnika koji povezuje dva
raunara u komunikaciji, kao to je ilustrovano na slici 5.2. U prouavanju protokola sa
viestrukim pristupom, videli smo da vie raunara moe da se povee pomou deljenog
provodnika i da bi ica" koja ih povezuje mogla da bude radio spektar ili drugi medijumi. To
nas je navelo da posmatramo
link apstraktnije, kao kanal, a ne kao provodnik. U naoj studiji Ethemet LAN-ova (slike 5.26 -
5.28), videli smo da bi medijumi za meusobno povezivanje mogli da budu dosta sloene
komutacione strukture. Meutim, kroz ceo taj razvoj, sami raunari su zadravali predstavu daje
medijum za meusobno povezivanje prosto kanal sloja veze podataka koji povezuje dva ili vie
raunara. Videli smo, na primer, da Ethemet raunar moe da bude blaeno nesvestan da li je sa
drugim raunarima u LAN-u povezan pomou kratkog segmenta LAN-a (slika 5.9), ili pomou
geografski rairenog komutiranog LAN-a (slika 5.28).
U odeljku 5.7 smo videli da se protokol PPP esto koristi za savremene komunikacije
izmeu dva raunara. Ovde je link koji povezuje dva raunara u stvari telefonska mrea - logiki
odvojena, globalna telekomunikaciona mrea sa svojim sopstvenim komutatorima, linkovima i
skupovima protokola za prenos podataka i signalizaciju. Meutim, sa take gledita Intemetovog
sloja veze podataka, na pozivnu konekciju preko telefonske mree se gleda kao na obinu
icu". U tom smislu, Internet vizualizuje telefonsku mreu, videvi je kao tehnologiju sloja
veze podataka koja obezbeduje povezivost sloja veze podataka izmeu dva raunara na
Internetu. Setite se iz nae diskusije o prekrivajuim mreama u poglavlju 2, da jedna takva
mrea slino vidi Internet kao sredstvo za obezbeivanje povezivosti izmeu vorova, traei
prekrivanje na Internetu na isti nain kao to Internet prekriva telefonsku mreu.
U ovom odeljku, razmotriemo asinhroni reim prenosa (asynchronous transfer mode,
ATM) i mree sa vieprotokolnim komutiranjem na osnovu oznaka (Multi-protocol Label
Switching, MPLS). Za razliku od telefonskih mrea sa komutacijom kola, i ATM i MPLS su sa
komutacijom paketa, mree sa virtuelnim kolima na svoj nain. One imaju svoje sopstvene
formate paketa i ponaanje prilikom prosleivanja. Dakle, sa pedagoke take gledita, diskusija
o ATM-u i MPLS-u se dobro uklapa u sloj veze podataka. Meutim, sa take gledita Interneta,
moemo da smatramo ATM i MPLS, kao i telefonsku mreu i komutirani Ethernet, kao
tehnologije sloja veze podataka koje slue da povezuju IP ureaje. Iz tog razloga emo razmatrati
i MPLS i ATM u naoj diskusiji o sloju veze podataka. Mree Frame Relay takode mogu da se
upotrebe za meusobno povezivanje IP ureaja, ali one predstavljaju neto stariju (mada i dalje
primenjivanu) tehnologiju, pa ih ovde neemo objanjavati; za detalje pogledajte vrlo itljivu
knjigu [Goralski 1999]. Naa obrada ATM-a i MPLS-a e namemo biti kratka, jer bi o tim
mreama mogla da se napie (i napisana je) itava knjiga. Ovde emo se uglavnom usredsrediti
na to kako ove mree slue da meusobno povezu IP ureaje, iako emo se dublje upustiti i u
tehnologije koje ine njihovu osnovu.

5.8.1 Asinhroni reim prenosa (ATM)
Standardi za asinhroni reim prenosa (ATM) prvi put su razvijeni sredinom 1980-ih godina, sa
ciljem projektovanja jedne mrene tehnologije koja bi se upotrebljavala za prenos govora i videa
u realnom vremenu, kao i teksta, slika i elek-

254 254 254 254
485 485 485 485
5.8 . VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE

tronske pote. Dva komiteta za standarde, ATM Forum [ATM 2002] i International
Telecommunications Union [ITU 2002], razvili su standarde za ATM.

Glavne karakteristike ATM-a
Kao stoje reeno u odeljku 4.1, ATM podrava vie modela usluga, ukljuujui usluge
konstantne, promenljive, raspoloive i nespecifirane bitske brzine. ATM je mrena arhitektura za
komutaciju paketa sa virtuelnim kolima (VC). Setite se da smo u izvesnoj meri razmatrali
virtuelna kola u odeljku 4.2.1, Opta arhitektura ATM-a je organizovana u tri sloja, kao Stoje
prikazano na slici 5.37.
ATM adaptacioni sloj (AAL) priblino je analogan Internetovom transportnom sloju i
prisutan je samo na ATM ureajima na granici ATM mree. Na predaj-noj strani, AAL
prosleuje podatke iz aplikacije vieg nivoa ili protokola (kao to je IP, ako se ATM koristi za
povezane IP ureaje). Na prijemnoj strani, on prosleuje podatke navie ka protokolu vieg nivoa
ili aplikaciji. AAL-ovi su definisani za usluge konstantne bitske brzine i emulaciju kola (AAL1),
za usluge promenljive bitske brzine kao stoje video promenljive bitske brzine (AAL2) i za usluge
podataka kao stoje transport IP datagrama (AAL5). Meu uslugama koje izvrava AAL su
otkrivanje greke i segmentacija/ponovo sastavljanje. Jedinica podataka kojom rukuje AAL
generiki se zove AAL protokolna jedinica podataka {protocol data unit, PDU), i priblino je
ekvivalentna UDP ili TCP segmentu.
AAL PDU je prikazana na slici 5.38. PDU polja su relativno jasna. PAD obezbeduje daje
PDU celobrojni umnoak od 48 bajtova, zato to e se PDU izdeliti na segmente tako da stane u
48-bajtne korisne terete ATM paketa (poznatih kao ATM elije). Duina polja identifikuje
veliinu korisnog tereta PDU, tako da PAD moe da se ukloni kod prijemnika. Polje CRC
Obezbeduje otkrivanje greke, koristei istu ciklinu proveru redundantnosti kao Ethernet. Polje
za koristan teret moe da bude duine do 65535 bajtova.
Hajde da se spustimo sloj nie i da razmatramo ATM sloj, koji lei u srcu ATM
arhitekture. ATM sloj definie strukturu ATM elije i znaenja polja unutar elije. ATM elija je
vana za ATM mreu kao stoje to IP datagram za IP mreu. Prvih 5 bajtova elije ini ATM
zaglavlje; preostalih 48 bajtova ine ATM koristan teret. Na slici 5.39 prikazana je struktura
zaglavlja ATM elije.
Polja u ATM eliji imaju sledee funkcije:
Identifikator virtuelnog kanala (VCI), Pokazuje virtuelni kanal kome pripada elija. Kao i
u veini mrenih tehnologija koje koriste virtuelna kola, elijin VCI se prenosi od linka do
linka (proitajte odeljak 4.2.1).
Vrsta korisnog tereta (PT). Pokazuje vrstu korisnog tereta koji sadri elija. Ima vie vrsta
korisnog tereta podataka, vie vrsta korisnog tereta za odravanje i vrsta korisnog tereta
slobodne elije. Polje PT takoe obuhvata bit koji slui da pokae na poslednju eliju u
fragmentovanoj AAL PDU.
Bit prioriteta gubitka elije (CLP). Tzvor moe da ga postavi da bi se napravila razlika
izmeu saobraaja visokog i niskog prioriteta. Ako doe do zaguenja i ATM komutator
mora da odbacuje elije, on moe da upotrebi taj bit kako bi prvo odbacio saobraaj niskog
prioriteta.
Bajt za kontrolu greke zaglavlja (HEC). Bitovi za otkrivanje greaka koji tite zaglavlje
elije.

5.8 VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE 255
i -

Pre nego to izvor moe da pone sa slanjem elija odreditu, ATM mrea mora da uspostavi
virtuelni kanal (VC) od izvora do odredita. Virtuelni kanal nije nita vie od virtuelnog kola,
opisanog u odeljku 4.2.1. Svaki VC je putanja koja se sastoji od niza linkova izmeu izvora i
odredita. Identifikator virtuelnog kanala (VCI) se pridruuje svakom linku na VC-u. Kad god se
VC uspostavi ili ukine, moraju da se auriraju VC tabele (proitajte odeljak 4.3.1). Ako se
koriste trajni VC-ovi, nema potrebe za njihovim dinamikim uspostavljanjem i ukidanjem. Kada
se trai dinamiko uspostavljanje i ukidanje VC-ova, protokol Q.2931 [Black 1997, ITU-T
Q.2-931 ] obezbeduje potrebnu signalizaciju izmeu ATM komutatora i krajnjih sistema.
ATM fiziki sloj je na samom dnu familije ATM protokola i bavi se naponima, tajmirigom
bitova i pravljenje okvira na fizikom medijumu. Dobar deo fizikog sloja zavisi od fizikih
karakteristika linka. Postoje dve iroke klase fizikih slojeva: oni koji imaju strukturu okvira
prenosa (na primer, TI, T3, SONET ili SDH) i oni koji je nemaju. Ako fiziki sloj ima strukturu
okvira, on je onda odgovoran za generisanje i izdvajanje okvira. Termin okviri u ovom odeljku
ne treba da se pomea sa okvirima sloja veze podataka (odnosno, Etherneta), koji se koriste u
prethodnim odeljcima ovog poglavlja. Okvir prenosa je mehanizam fizikog sloja slian TDM-u,
za organizovanje bitova koji se alju preko linka. Neki mogui fiziki slojevi ukljuuju:
SONET/SDH (sinhrona optika mrea/ sinhrona digitalna hijerarhija) po mono-modnom
optikom vlaknu. Kao TI i T3, SONET i SDH imaju strukturu okvira kpja uspostavlja
sinkronizaciju bitova izmeu predajnika i prijemnika na dva kraja linka. Ima vie
standardizovanih brzina, ukljuujui:
OC-3: 51,84 Mb/s OC-3:
155,52 Mb/s OC-12:
622,08 Mb/s OC-48: 2,5
Gb/s
T1/T3 okviri preko optikog vlakna, mikrotalasa i bakarnih provodnika.
Zasnovani na elijama, bez okvira. U ovom sluaju, generator takta prijemnika se izvodi iz
predajnog signala.

IP preko ATM-a
Hajde sada da razmotrimo kako ATM mrea moe da se upotrebi da bi obezbedila veza izmeu
IP ureaja. Na slici 5.40 prikazana je ATM okosnica sa etiri ulazne/ izlazne take za Internet IP
saobraaj. Zapazite daje svaka ulazna/izlazna taka ruter. ATM okosnica moe da se prostire
preko celog kontinenta i moe da ima desetine ili ak stotine ATM komutatora. Veina ATM
okosnica ima postojani virtuelni kanal (VC) izmeu svakog para ulaznih/izlaznih taaka.
Upotrebom postojanih VC-ova, ATM elije se rutiraju od ulazne do izlazne take a da pri tom
VC-ovi ne moraju da se dinamiki uspostavljaju i ukidaju. Meutim, postojani VC-ovi su
izvodljivi samo
kada je broj ulaznih/izlaznih taaka relativno mali. Za n ulaznih taaka, potrebno je n(n - I)
postojanih VC-ova da direktno povezu ulaznih/izlaznih taaka.
Interfejsu svakog rutera koji se povezuje sa ATM mreom bie potrebne dve adrese, na
dosta slian nain kao to su IP raunaru potrebne dve adrese za Ethernet interfejs: IP adresa i
MAC adresa. Slino tome, ATM interfejs e imati IP adresu i MAC adresu. Razmotrite sada IP
datagram koji treba da se prenese preko ATM mree na slici 5.40. U najprostijem sluaju, ATM
mrea izgleda kao jedan logiki link - ATM meusobno povezuje ta etiri rutera ba kao to
Ethernet moe da se upotrebi da povee etiri rutera. Hajde da ruter u kome datagram ulazi u
ATM mreu zovemo ulazni ruter", a ruter sa koga datagram naputa mreu zovemo izlazni
ruter". Ulazni ruter radi sledee:
1. Ispituje adresu odredita datagrama.
2. Indeksira svoju tabelu rutirania i odreuje IP adresu izlaznog rutera (odnosno, sledeeg
rutera na putanji datagTama).
3. Da bi doveo datagram na izlazni ruter, ulazni ruter vidi ATM samo kao jedan protokol loja
veze podataka. Da bi se datagram preneo na sledei ruter, mora da se odredi fizika adresa
ruicra u sledeem skoku. Setite se iz nae rasprave u odeljku 5.4.2, da se to radi upotrebom
ARP-a. U sluaju ATM interfejsa, ulazni

5.8 VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE
489 489 489 489

ruter indeksira ATM ARP tabelu sa IP adresom izlaznog rutera i odreuje ATM adresu izlaznog
rutera. Protokol ATMARP je opisan u [RFC 2225]. 4. IP u ulaznom ruteru onda prosleduje nanie
datagram sloju veze podataka (odnosno ATM-u) zajedno sa ATM adresom izlaznog rutera.
Kada se zavre ova etiri postupka, posao prenosa datagrama u izlazni ruter je van kontrole
IP-a i prelazi u ruke ATM-a. ATM sada mora da prenese datagram na adresu ATM odredita,
dobijenu u gore pomenutom postupku 3. Ovaj zadatak ima dva podzadatka:
1. 1. 1. 1. Odreivanje VCI-ja za VC koji vodi do adrese ATM odredita.
2. Deljenje datagrama na elije na predajnoj strani VC-a (odnosno, u ulaznom ruteru) i ponovno
sastavljanje elija u prvobitni datagram na prijemnoj strani VC-a (odnosno, u izlaznom
ruteru).
Prvi od navedenih podzadataka je jasan. Interfejs na predajnoj strani odrava tabelu koja
preslikava ATM adrese u VCI-ove. S obzirom na to da smo pretpostavili da su VC-ovi postojani,
ova tabela je aurna i statina. (Ako VC-ovi ne bi bili postojani, onda bi bio potreban ATM
stgnalni protokol Q,2931 da dinamiki uspostavlja i ukida VC-ove.) Drugi podzadatak zasluuje
paljivije razmatranje. Jedan pristup je da se koristi IP fragmentacija, kao to je objanjeno u
odeljku 4.4.- Kod IP fragmentacije, predajni ruter bi prvo izdelio prvobitni datagram na
fragmente, gde nijedan fragment ne bi bio vei od 48 bajtova, tako da bi mogao da stane u
koristan teret ATM elije. Ali, taj pristup fragmentacije ima veliki problem - svaki IP fragment po
pravilu ima 20 bajtova zaglavlja, tako da bi ATM elija koja ga prenosi imala 25 bajtova ,jalovog
optereenja" i samo 28 bajtova korisnih informacija. ATM zato koristi AAL5 da bi obezbedio
efikasniji nain za deljenje i ponovno sastavljanje datagrama.
ATM mrea zatim prenosi svaku eliju kroz mreu do adrese ATM odredita. U svakom
ATM komutatoru izmeu ATM izvora i odredita, ATM eliju obrauju ATM fiziki sloj i ATM
sloj, ali ne i AAL sloj. U svakom komutatoru VCI se obino prevodi (proitajte odeljak 4.2.1) i
ponovo se izraunava HEC. Kada elije stignu na adresu ATM odredita, one se usmeravaju u
privremenu memoriju AAL koja je rezervisana za odreeni VC. AAL5 PDU se rekonstruie i IP
datagram se izdvaja i prosleduje navie protokolu IP sloja.

5.8.2 Vieprotokolna komutacija na osnovu oznaka (MPLS)
Vieprotokolna komutacija na osnovu oznaka (MPLS) se razvila iz brojnih industrijskih napora,
od sredine da kraja 1990-ih godina, da se pobolja brzina prosleivanja IP rutera usvajanjem
kljunog koncepta iz sveta mrea sa virtuelnim kolima: oznake fiksne duine. Cilj nije bio da se
napusti infrastruktura prosleivanja IP datagrama na osnovu odredita radi one koja je zasnovana
na oznakama fiksne duine i virtu-
elnim kolima, nego da se ona pojaa selektivno oznaavajui datagrame i dozvoljavajui
ruterima da, kadaje to mogue, prosleuju datagrame na osnovu oznaka fiksne duine (a ne na
osnovu IP adresa odredita). Vano je da ove tehnike idu ruku po ruku sa IP-om, koristei IP
adresiranje i rutiranje. IETF je ujedinio te napore u protokolu MPLS [RFC 3031, RFC 3032],
efikasno spajajui VC tehnike u mrei rutiranih datagrama.
Hajde da ponemo nae prouavanje MPLS-a razmatranjem formata okvira sloja veze
podataka sa kojim radi ruter osposobljen za MPLS. Na slici 5.41 pokazuje se da okvir sloja veze
podataka koji se prenosi na PPP linku ili LAN-u (kao to je Ethernet) ima malo MPLS zaglavlje,
dodato izmeu zaglavlja sloja-2 (na primer, PPP ili Ethernet) i zaglavlja sloja-3 (na primer, IP).
RFC 3032 definie format MPLS zaglavlja za takve linkove; zaglavlja se definiu za ATM i
Frame Relay mree, kao i u drugim RFC-ovima. Meu poljima MPLS zaglavlja su oznaka (koja
slui kao identifikator virtuelnog kola, koga smo sreli ranije u odeljku 4.2.1), 3 bita rezervisana
za eksperimentalnu upotrebu, jedan S bit, koji se koristi da ukae na kraj serije naslaganih"
MPLS zaglavlja (naprednija tema, koju ovde neemo objanjavati) i polje sa ivotnim
vremenom.
Sa slike 5.41 se odmah vidi da okvir koji je ojaan pomou MPLS-a moe da sc alje samo
izmeu rutera koji su oba osposobljeni za MPLS (zato to bi ruter koji nije osposobljen za
MPLS bio sasvim zbunjen kada bi pronaao MPLS zaglavlje tamo gde je oekivao da nae IP
zaglavlje!). Ruter osposobljen za MPLS se esto zove ruter komutiran pomou oznake, zato to
prosleduje MPLS okvir traei MPLS oznaku u svojoj tabeli prosleivanja i odmah prosleujui
datagram na odgovarajui izlazni interfejs. Dakle, ruter osposobljen za MPLS ne izdvaja adresu
odredita i trai podudarnost najdueg prefiksa u tabeli prosleivanja. Ali kako ruter zna da li je
njegov sused zaista osposobljen za MPLS i koju oznaku da pridrui datom IP odreditu? Da
bismo odgovorili na ova pitanja, bie potrebno da bacimo pogled na interakciju unutar grupe
rutera osposobljenih za MPLS.
U primeru na slici 5.42, ruteri Rl do R4 su osposobljeni za MPLS. R5 i R6 su standardni IP
ruteri. Rl je najavio R2 i R3 da on (Rl) moe da rutira ka odreditu A i da e primljeni okvir sa
MPLS oznakom 6 biti prosleen odreditu A. Ruter R3 je

5.9 . REZIME 491

najavio ruteru R4 da on moe da rutira ka odreditima A i D i da e dolazei okviri sa MPLS
oznakama 10 i 12 respektivno biti komutirani ka tim odreditima. Ruter R2 je takoe najavio
ruteru R4 da on (R2) moe da dostigne odredite A i da primljeni okvir sa MPLS oznakom 8
moe da se komutira ka A. Zapazite daje ruter R4 sada u zanimljivom poloaju, zato to ima dve
MPLS putanje da stigne do odredita A preko interfejsa 0 sa izlaznom MPLS oznakom 10 i
preko interfejsa 1 sa MPLS oznakom 8. Na slici 5.42 je prikazano da su IP R4, R5, A i D
meusobno povezani preko MPLS infrastrukture (ruteri osposobljeni za MPLS Rl, R2, R3 i R4)
na dosta slian nain kako komutirani LAN ili ATM mrea mogu da povezu IP ureaje. I kao
komutirani LAN ili ATM mrea, ruteri osposobljeni za MPLS Rl do R4 to rade a da nikada i ne
dotaknu IP zaglavlje paketa.
U naoj diskusiji nismo navodili specifian protokol koji se koristi za raspodelu oznaka
izmeu rutera osposobljenih za MPLS, zato to su detalji te signalizacije izvan domena ove
knjige. Meutim, napominjemo da je radna grupa IETF za MPLS odredila u RFC 3468 da e
proirenje protokola RSVP (koji emo prouiti u poglavlju 7), poznato kao RSVP-TE [RFC
3209] biti ia njenih napora za MPLS signalizaciju. Zato zainteresovanpm itaocu
preporuujemo da proita RFC 3209.
Do sada je naglasak u naoj raspravi o MPLS bio na injenici da MPLS i2vodi komutaciju
zasnovanu na oznakama, bez potrebe da razmatra IP adresu paketa. Prava prednost MPLS i
razlog trenutnog interesa za MPLS nije, meutim, u potencijalnim poveanjima brzina
komutacije, nego pre u novim sposobnostima za upravljanje saobraajem koje daje MPLS. Kao
Stoje gore napomenuto, R4 ima dve MPLS
putanje do A. Ako bi prosledivanje bilo izvreno do IP sloja na osnovu IP adrese, IP protokoli za
rutiranje koje smo prouili u poglavlju 4 bi odredili samo jednu, najjeftiniju putanju do A. Dakle,
MPLS obezbeduje sposobnost da se paketi prosleduju putanjama koje ne bi bile mogue
korienjem standardnih IP protokola za rutiranje. To je jednostavan oblik inenjerstva
saobraaja upotrebom MPLS [RFC 3346, Xiao 2000], u kome operator mree moe da stavi van
snage normalno IP rutiranje i da prisili deo saobraaja usmeren ka datom odreditu da ide
jednom putanjom, a drugi deo saobraaja usmeren ka istom odreditu da ide drugom putanjom
(zbog politike, performanse ili iz nekog drugog razloga).
Mogue je, takoe, upotrebiti MMPLS za mnoge druge namene. Na primer, da se izvede
brzo obnavljanje MPLS putanja za prosledivanje, odnosno da se ponovo rutira saobraaj preko
preraunate putanje kao odziv na otkaz linka [Kar 2000, Huang 2002, RFC 3469]. MPLS takoe
moe da se upotrebi za implementaciju okvira za diferenciranu uslugu, koju emo prouiti u
poglavlju 7. Najzad, napominjemo da MPLS moe da se upotrebi, i ve je bio upotrebljen, za
implementaciju takozvanih virtuelnih privatnih mrea (virtvalprivate neworks, VPN). U
implementaciji VPN za kupca, ISP koristi svoju mreu osposobljenu za MPLS, da bi meusobno
povezao kupeve razliite mree. MPLS moe da se upotrebi da bi izolovao i resurse i
adresiranje koje koristi kupeva VPN od drugih korisnika koji prolaze kroz ISP-ovu mreu; za
detalje proitajte [DeClercq 2002].
Naa rasprava o MPLS je namerno bila kratka i mi vam preporuujemo da pogledate
reference koje smo spomenuli. Napominjemo da uz toliko mnogo moguih upotreba MPLS,
izgleda da ona brzo postaje vajcarski perorez" inenjerstva saobraaja na Internetu!
5. 9 Rezime
U ovom poglavlju, ispitali smo sloj veze podataka - njegove usluge, principe na kojima se
zasniva rad i izvestan broj znaajnih protokola koji te principe koriste u implementiranju usluga
veze podataka.
Videli smo daje osnovna usluga sloja veze podataka da prenosi datagram mrenog sloja od
jednog vora (rutera ili raunara) do susednog vora. Takoe, videli smo da svi protokoli veze
podataka rade pomou enkapsuliranja datagrama mrenog sloja u okvir sloja veze podataka pre
prenoenja okvira preko linka" do susednog vora. Meutim, izvan ove zajednike funkcije
pravljenja okvira, nauili smo da razliiti protokoli sloja veze podataka obezbeuju veoma
razliite usluge pristupa linku, isporuke (pouzdanost, otkrivanje/ispravljanje greaka), kontrole
toka i prenosa (na primer, puni dupleks ili poludupleks). Te razlike su delom posledica razliitih
vrsta linkova preko kojih protokoli sloja veze podataka moraju da rade. Jednostavan link od
take do take ima jednog poiljaoca i jednog primaoca koji komuniciraju preko jedne ice".
Link sa viestrukim pristupom se deli izmeu vie poiljalaca i


DOMAI ZADATAK: PROBLEMI I PITANJA 493 493 493 493
primalaca; zbog toga, protokol veze podataka za kanal sa viestrukim pristupom ima protokol za
usklaivanje pristupa linku. U sluajevima ATM, X.25 i Frame Relay, videli smo da link" koji
povezuje dva susedna vora (na primer, dva IP rutera koji su susedni u smislu IP-a - da su IP
ruteri sledeeg skoka ka nekom odreditu) mogu u stvari da budu mrea u i po samoj sebi. U
izvesnom smislu, ideja da se mrea posmatra kao link" ne bi trebalo da izgleda udno. Na
primer, telefonski link" koji povezuje kuni modenVraunar sa udaljenim modemom/ruterom, u
stvari je putanja kroz usavrenu i sloenu telefonsku mreu.
Izmeu principa na kojima se zasniva komunikacija veze podataka, ispitali smo tehnike
otkrivanja i ispravljanja greaka, protokole sa viestrukim pristupom, adresiranje veze podataka i
konstrukciju proirenih lokalnih raunarskih mrea preko habova i komutatora. U sluaju
otkrivanja/ispravljanja greaka, ispitali smo kako je mogue dodati bitove zaglavlju okvira da bi
se otkrile i, u nekim sluajevima, ispravile greke koje bi mogle da se dogode kada se okvir
prenosi preko linka. Objasnili smo jednostavne eme parnosti i kontrolnog zbira, kao i robustniju
ciklinu proveru redundantnosti. Onda smo preli na temu protokola sa viestrukim pristupom.
Identifikovali smo i prostudirali tri iroka naina za usklaivanje pristupa difuznom kanalu:
pristupe deljenja kanala (TDM, FDM, CDMA), metode sluajnog pristupa (protokoli ALOHA i
CSMA) i metode sa pristupom po redu (prozivanje i prosleivanje etona). Videli smo'da je
posledica toga to vie vorova deli jedan difuzni kanal potreba da se obezbede adrese vorova
na nivou veze podataka. Nauili smo da su fizike adrese sasvim drugaije od adresa mrenog
sloja i da se, u sluaju Interneta, koristi specijalni protokol (ARP - protokol za prevoenje
adresa) da bi izvrio prevoenje izmeu ta dva oblika adresiranja. Onda smo ispitali kako
vorovi koji dele difuzni kanal formiraju lokalnu mreu raunara (LAN) i kako vie LAN-ova
mogu da se povezu da bi formirali vee LAN-ove, sve to bez primene tehnika rutiranja radi
meusobnog povezivanja tih lokalnih vorova.
Takoe smo detaljno objasnili izvestan broj specifinih protokola sloja veze podataka -
Ethemet i PPP. Zavrili smo nae prouavanje sloja veze podataka usred-sreujui se na to kako
ATM i MPLS mree obezbeuju usluge sloja veze podataka kada povezuju IP rutere. Poto smo
objasnili sloj veze podataka, nae putovanje niz familiju protokola je sada zavreno\ Svakako,
fiziki sloj lei ispod sloja veze podataka, ali detalje o fizikom sloju moda je najbolje ostaviti
za neki drugi kurs (na primer, u teoriji komunikacija, pre nego u raunarskom umreavanju).
Meutim, ipak smo dotakli nekoliko aspekata fizikog sloja u ovom poglavlju (na primer, u
naoj kratkoj raspravi o Manchester kodovanju u odeljku 5.5) i U poglavlju 1 (naa rasprava o
fizikim medtjumima u odeljku l .4). Razmatraemo opet fiziki sloj kada se budemo baviti
karakteristikama beinih veza u sledeem poglavlju.
Iako je putovanje kroz protokole zavreno, naa studija o raunarskom umreavanju ipak
nije dola do kraja. U sledea etiri poglavlja objasniemo beino umreavanje, multimedijalno
umreavanje, bezbednost mree i upravljanje mreom. Te etiri teme se ne uklapaju pogodno ni
u jedan sloj; zaista, svaka tema preseca vie
p| p| p| p| Domai zadatak: problemi i pitanja Poglavlje 5
Kontrolna pitanja
ODEUCI5.1-5.2
1. Ako bi svi linkovi u Internetu obezbeivali uslugu pouzdane isporuke, da li bi TCP
usluga pouzdane isporuke bila kompletno redundantna? Zato da, ili zato ne?
2. Koje su neke od moguih usluga koje protokol sloja veze podataka moe da
ponudi mrenom sloju? Koje od ovih usluga sloja veze podataka imaju odgo-
varajue usluge u IP-u? U TCP-u?
ODEUAK 5.3
3. Pretpostavite da va vora poinju da alju paket duine L u isto vreme preko
difuznog kanala brzine R. Oznaite kanjenje usled propagacije izmeu dva
vora kao tprosl. Da li e biti kolizija ako je tprgsl < URI Zato hoe, ili zato
nee?
4. U odeljku 5.3, naveli smo etiri poeljne karakteristike difuznog kanala. Koje
od tih karakteristika ima ALOHA sa odsecima? Koje od tih karakteristika ima
prosleivanje etona?
5. Opiite protokole sa prozivanjem i sa prosleivanje etona, koristei analogiju
interakcija na koktelu.
6. Zato bi Token Ring protokol bio neefikasan ako bi LAN imao veoma velik
obim?
ODEUAK 5.A
7. Koliko je veliki MAC adresni prostor? Adresni prostor IPv4? Adresni prostor IPv6?
8. Pretpostavite daje svaki od vorova A, B i C prikljuen na isti difuzni LAN (preko njihovih
adaptera). Ako A alje hiljade IP datagrama ka B sa svakim od enkapsuliranih okvira
adresiranih na MAC adresu B, da li e adapter vora C obraivati te okvire? Ako hoe, da li e
adapter C prosleivati IP datagrame u tim okvirima voru C (odnosno, voru kome adapter
pripada)? Kako e se vas" odgovor izmeniti ako A alje okvire sa difaznom MAC adresom?
9. Zato se upit ARP alje unutar difuznog okvira? Zato se odziv ARP alje unutar okvira sa
odreenom MAC adresom odredita?

494 POGLAVLJE 5 5LOJ VEZE PODATAKA I LOKALNE MREE RAUNARA
PROBLEMI 495
10. Za mreu na slici 5.19, ruter ima dva ARP modula, od kojih je svaki sa svojom
sopstvenom ARP tabelom. Da li je mogue da se ista MAC adresa pojavi u obe
tabele?
ODEUAK 5.5
11. Poredite strukture okvira za lOBaseT, lOOBaseT, 802.11b i Gigabit Ethernet. U emu se
one razlikuju?
12. Pretpostavite da adapter od 10 Mb/s alje u kanal beskrajan niz jedinica, koristei
Manchester kodovanje. Koliko e promena u sekundi imati signal koji se pojavljuje iz
adaptera?
13. U CSMA/CD, posle pete kolizije, kolika je verovatnoa da vrednost K koju vor bira
bude 4? Kolikom kanjenju u sekundama na Ethernetu od 10 Mb/s odgovara rezultat K
= 4?
Problemi
1. Pretpostavite da je informacioni sadraj paketa ablon bitova 1010101010101011 i da se
koristi parna ema pamosti. Koja bi bila vrednost kontrolnog zbira u sluaju
dvodimenzionalne parne eme? Va odgovor bi trebalo da bude takav da se koristi polje
kontrolnog zbira minimalne duine.
2. Pokaite (dajte primer drugaiji od onog sa slike 5.6) da dvodimenzionalna provera pamosti
moe da ispravi i otkrije jednu greku bita. Pokaite (dajte primer) da pogrena dva bita
mogu da se otkriju, ali ne mogu da se isprave.
3. Pretpostavite da informacioni deo paketa (D na slici 5.4) sadri deset bajtova koji se sastoje
od 8-bitnih binarnih prezentacija (bez znaka) celih brojeva od 0 do 9. Izraunajte Internet
kontrolni zbir za ove podatke.
4. Razmotrite 4-bitni generator, G, prikazan na slici 5.8, i pretpostavite da D ima vrednost
10101010. Koja je vrednosti?
5. U odeljku 5.3, dali smo kratko izvoenje efikasnosti ALOHE sa odsecima. U ovom
problemu upotpunicemo to izvoenje.
a. Setite se da kada postoji //aktivnih vorova, efikasnost ALOHE sa odse-
cima je data izrazom Np(l~p)N-l. Pronaite vrednostp koja daje maksi-
malnu vrednost tog izraza.
b. Koristei vrednost p pronaenu u delu pod a, pronaite efikasnost ALOHE
sa odsecima ako A'tei beskonanosti. (Savet: (1l/A/) tei ka l/e kada N
tei beskonanosti.)
6. Pokaite daje efikasnost iste ALOHE jednaka l/(2e). Zapazite: ovaj problem
je jednostavan, ako ste resili prethodni problem!
7. Nacrtajte grafik efikasnosti ALOHE sa odsecima i iste ALOHE u funkciji od pza;V=
100.
8. Razmotrite difuzni kanal sa JYvorova i brzinom prenosa od R b/s. Pretpostavite da difuzni
kanal za viestruki pristup koristi prozivanje (sa dodatnim vorom koji proziva).
Pretpostavite daje duina vremena od kada vor zavri prenos do kada se sledeem voru
dopusti da prenosi (odnosno, kanjenje prozivanja) tpmi. Pretpostavite da se u jednoj rundi
prozivanja datom voru doputa da prenese najvie Q bitova. Koja je maksimalna propusna
mo difuznog kanala?
9. Razmotrite tri LAN-a meusobno povezana pomou dva rutera, kao to je prikazano na
sledeoj slici.
a. Precrtajte sliku, tako da ukljui adaptere.
b. Dodelite IP adrese svim interfejsima. Za LAN 1 koristite adrese u obliku
111.111.111.xxx; za LAN 2 koristite adrese u obliku 122.222.222.xxx; a za
LAN 3 koristite adrese u obliku 133.133.133.xxx.
c. Dodelite MAC adrese svim adapterima.
d. Razmotrite slanje IP datagrama od raunara A do raunara R Pretpostavite
a su sve ARP tabele aurne. Nabrojte sve postupke kao stoje to uraeno za
primer sa jednim ruterom u odeljku 5.4.2.
e. Ponovite (d), sada pretpostavljajui daje ARP tabela u raunaru poiljaocu
prazna (a da su druge tabele aurne).

PROBLEMI 497 497 497 497

10. Setite se da kod protokola CSMA/CD, adapter ekaK - 512 vremena trajanja jednog bita
posle kolizije, gde je sluajan broj. Z a K = 100, koliko dugo adapter eka do vraanja na
postupak 2 za Ethernet od 10 Mb/s? Za Ethernet od 100 Mb/s?
11. Pretpostavite da su vorovi A i B na istom segmentu Ethemeta od 10 Mb/s i daje kanjenje
usled propagacije izmeu dva vora 225 vremena trajanja jednog bita. Pretpostavite da vor
A poinje prenoenje okvira i da, pre nego to on zavri, vor B poinje prenoenje okvira.
Moe li A da zavri prenoenje pre nego to otkrije da je B prenosio? Zato moe, ili zato ne
moe? Ako je odgovor da, onda A pogreno veruje da je njegov okvir uspeno prenesen bez
kolizija. (Savet: Pretpostavite da u trenutku / = 0 vremena trajanja jednog bita, A poinje
prenoenje okvira. U najgorem sluaju, A prenosi okvir minimalne veliine od 512 + 64
vremena trajanja jednog bita. Tako bi A zavrio sa prenoenjem okvira u t = 512 + 64
vremena trajanja jednog bita. Prema tome, odgovor je ne, ako signal vora B stigne do A pre
t = 512 + 64 vremena trajanja jednog bita. U najgorem sluaju, kada signal vora B stie do
A?)
12. Pretpostavite da su vorovi A i B na istom segmentu Ethemeta od 10 Mb/s i da je
kanjenje usled propagacije izmeu dva vora 225 vremena trajanja jednog bita.
Pretpostavite da A i B alju okvire u isto vreme, da okviri dolaze u koliziju i A i
B biraju razliite vrednosti K u algoritmu CSMA/CD. Pretpostavljajui da nema
drugih aktivnih vorova, moe li doi do kolizije ponovnih prenosa iz vorova A
i B? Za nae potrebe, dovoljno je da se obradi sledei primer. Pretpostavite da A
i B poinju prenos u t = 0 vremena trajanja jednog bita. Oba vora otkrivaju koliziju u t -
225 vremena trajanja jednog bita. Oni zavravaju prenoenje signala zastoja u t = 225 + 48 =
273 vremena trajanja jednog bita. Pretpostavite da su KA = 0 i KB = 1. U koje vreme B
planira svoj ponovni prenos? U koje vreme A poinje prenos? (Obratite panju: vorovi
moraju da ekaju na slobodan kanal posle vraanja na postupak 2 - pogledajte protokol.) U
koje vreme signal vora A stie do B? Da li B odustaje od prenoenja u svoje planirano
vreme? .
13. Razmotrite Ethernet lOOBaseT od 100 Mb/s. Koliko bi trebalo da bude maksimalno
rastojanje izmeu vora i haba da bi se postigla efikasnost od 0,50? Pretpostavite daje
duina okvira 64 bajta i da nema habova. Da li maksimalno rastojanje takode obezbeduje da
e predajni vor A biti sposoban da otkrije da li je bilo koji drugi vor prenosio za vreme
prenosa vora A? Zato da, ili zato ne? Kako se vae maksimalno rastojanje poredi sa
aktuelnim standardom za 100 Mb/s?
14. U ovom problemu izveete efikasnost protokola sa viestrukim pristupom slinom
CSMA/CD. U ovom protokolu, vreme je izdeljeno na odseke i svi adapteri su
sinhronizovani ria te odseke. Meutim, za razliku od ALOHE sa odsecima, duina
odseka (u sekundama) je mnogo manja od vremena okvira (vremena za prenos okvira).
Neka je S duina odseka. Pretpostavite da su svi okviri konstantne duine L = kRS, gde je
R brzina prenosa kanala, a k veliki ceo
broj. Pretpostavite da postoji A' vorova, svaki sa beskonanim brojem okvira za slanje.
Takode pretpostavljamo daje tpms[ < S, tako da svi vorovi mogu da otkriju'koliziju pre
zavretka vremenskog odseka. Protokol je sledei:
Ako, u datom odseku, nijedan vor ne poseduje kanal, svi vorovi se bore za kanal;
posebno, svaki vor alje u vremenskom odseku sa verovatnoom^. Ako tano jedan
vor alje u odseku, on preuzima vlasnitvo nad kanalom za sledeih k -1 odseaka i
alje svoj okvir u celosti.
Ako neki vor poseduje kanal, svi drugi vorovi odustaju od prenoenja dok vor koji
poseduje kanal ne zavri prenoenje svog okvira. Jednom kadaje taj vor preneo svoj
okvir, svi vorovi se bore za kanal.
Zapazite da kanal naizmenino menja dva stanja: proizvodno stanje", koje traje tano k
odseaka i neproizvodno stanje", koje traje sluajan broj odseaka. Jasno, efikasnost
kanala je odnos k/(k + x), gde je x oekivani broj susednih neproizvodnih odseaka,
a. Za fiksno A'i podredite efikasnost ovog protokola.
b. Za fiksno A', odredite p koje daje maksimalnu vrednost efikasnosti.
c. Koristeip (koje je u funkciji od A0 pronaeno u delu pod b, odredite efika-
snost kada N tei beskonanosti.
d. Pokaite da se ta efikasnost pribliava 1 kada duina okvira postaje velika.
15. Pretpostavite da su dva vora, A i B, prikljuena na suprotnim krajevima kabla
od 900 m i da svaki od njih ima okvir od 1000 bitova (ukljuujui sva zaglavlja
i preambule) da poalje onom drugom. Oba vora pokuavaju da prenose u
trenutku / = 0, Pretpostavite da postoje etiri haba izmeu A i B, od kojih svaki
unosi 20-bitno kanjenje. Pretpostavite daje brzina prenosa 10 Mb/s i da se
koristi CSMA/CD sa intervalima odstupanja u vidu umnoaka od 512 bitova.
Posle prve kolizije, A uzima K = 0 a B uzima K = 1 u protokolu eksponencijal-
nog odstupanja. Zanemarite signal zastoja i kanjenje u trajanju 96 bita.
a. Koliko je kanjenje jednosmeme propagacije (ukljuujui kanjenja
habova) izmeu A i B u sekundama? Pretpostavite daje brzina propagacije
signala 2 I0
8
m/s.
b. U koje vreme (u sekundama) je ceo paket vora A isporuen voru B?
c. Sada pretpostavite da samo A ima paket za slanje i da su habovi zamenjeni
komutatori ma. Pretpostavite da svaki komutator ima 20-bitno kanjenje
obrade pored kanjenja smetanja i prosleivanja. U koje vreme u sekun-
dama je paket vora A isporuen voru B?
16. Setite se da ATM koristi 53-bajtne pakete koji se sastoje od pet bajtova zagla-
vlja i 48 bajtova tovara. Pedeset tri bajta je neuobiajeno malo za pakete fiksne
duine; veina protokola umreavanja (IP, Ethemet, Frame Relay itd.) koriste
pakete koji su, u proeku, znaajno vei. Jedan od nedostataka male veliine
paketa je da veliki deo propusnog opsega linka troe dodatni bajtovi zaglavlja;


ETHEREAL LAB 499 499 499 499
u sluaju ATM-a, skoro 10 procenata propusnog opsega je uzaludno potroeno" na ATM
zaglavlje. U ovom problemu ispitujemo zastoje odabrana mala veliina paketa. Za sada,
pretpostavite da se ATM elija sastoji od P bajtova (moda razliito od 48) i 5 bajtova
zaglavlja.
a. Razmotrite slanje digitalno kodovanog govornog signala direktno preko
ATM-a. Pretpostavite daje izvor kodovan konstantnom brzinom od 64 Kb/
s. Pretpostavite da je svaka elija potpuno popunjena pre nego to je izvor
poalje u mreu. Vreme koje je potrebno za popunjavanje elije je kanje-
nje pripreme paketa (packetization delay). Izraeno pomou L, odredite
kanjenje pripreme paketa u milisekundama.
b. Kanjenja pripreme paketa vea od 20 ms mogu da prouzrokuju primetan i
neugodan eho. Odredite kanjenje pripreme paketa za L ~ 1500 bajtova (to
priblino odgovara Ethernet paketu maksimalne veliine) i za L = 48 (to
odgovara ATM eliji).
c. Proraunajte kanjenje memorisanja i prosledivanja na jednom ATM komu-
tatoru za brzinu linka od R = 155 Mb/s (popularna brzina linka za ATM) za
i = 1500 bajtova i za L = 48 bajtova.
d. Komentariite prednosti upotrebe male veliine elije.
17. Razmotrite MPLS mreu prikazanu na slici 5.42 i pretpostavite da su ruteri R5 i R6 sada
osposobljeni za MPLS. Pretpostavite da elimo da uradimo inenjering saobraaja, tako da
paketi iz R5 namenjeni za A budu komutirani ka A preko R6-R4-R3-R1, a paketi iz R5
namenjeni za A budu komutirani ka Apreko R5-R4-R2-R1. Prikaite MPLS tabele u R5 i
R6, kao i promenjenu tabelu u R4, koje bi to omoguile.
4. Iskoristite Web da biste pronali brojeve protokola korienih u Ethernet okviru za
IP datagram i za ARP paket.
5. Proitajte reference [Xiao 2000, Huang 2002 i RFC 3346] o inenjeringu saobraaja
korienjem MPLS. Napravile listu ciljeva za inenjering saobraaja. Koji od ovih ciljeva
mogu da se ispune samo sa MPLS, a koji mogu da se ispune korienjem postojeih
protokola (bez MPLS)? U poslednjem sluaju, koje prednosti nudi MPLS?
Ethereal Lab
U prateoj, veb lokaciji za ovu knjigu, http://ww.awl.com/kurose-ross, pronai ete
mEEtTv?
3

m mm m
r rr r
al al al al

23

V0

P
gtavije
-
Prvi

lS
P'
tu
J'
e

rad
P'Oôla
Ibbh 802.3 i format Ethernet okvira. Drugi istrauje upotrebu protokola DHCP koii
smo prouili u odeljku 5.4.3.
J
Teze za diskusiju
Preporuujemo vam da prokrstarite Webom pre nego to odgovorite na sledea pitanja.
1. Koliko priblino iznosi trenutni opseg cena adaptera 10/100 Mb/s? Adaptera Gigabit
Ethernet? Kakve su te cene u poreenju sa modemom 56 kb/s ili ADSL modemom?
2. Cene habova i komutatora se esto izraavaju brojem interfejsa (koji se u LAN argonu
takoe zovu i portovi). Koja je priblina trenutna cena po interfejsu haba od 10 Mb/s? Haba
od 100 Mb/s? Komutatora koji se sastoji samo od interfejsa za 10 Mb/s? Komutatora koji se
sastoji samo od interfejsa za 100 Mb/s?
3. Mnoge od funkcija adaptera mogu da se izvedu u softveru koji radi na centralnom
procesoru vora. Koje su prednosti i nedostaci premetanja te funkcionalnosti iz adaptera u
vor?

INTERVJU
Sajmon Sajmon Sajmon Sajmon S. S. S. S. Lem Lem Lem Lem
Sajmon S. Lem je profesor i ef katedre za raunarske nauke na
Teksakom univerzitetu u Ostinu. Od 1971. do 1974. godine, bio je u ARPA
Centru za mrena merenja (NeKvork Measurement Center) na UCLA, gde
je radio na satelitskom i radio komutiranju paketa. Vodio je istraivaku
grupu koja je pronala bezbedne sokele i 1993. godine napravila prototip
prvog bezbednog sloja soketa
(nazvanog Secure Network Programming). Njegova istraivaka interesovanja su u obiosti
projektovanjo i analize mrenih protokola i bezbednosnih usluga. Diplomirao je elektrotehniku na
Dravnom univerzitetu u dravi Vaingon, o akademske stepene magistra i doktora nauka ostvario
je na UCLA.

Zato ste odluili da se specijaliiujete u oblasti umreavanja?
Kada sam stigao na UCLA kao novi diplomirani student u jesen 1969. godine, imao sam
nameru da studiram teoriju upravljanja. Onda sam pohaao asove iz teorije ekanja u redovima
koje je drao Leonard Klajnrok i on me je veoma impresionirao. Posle kratkog vremena radio
sam na adaptivnom upravljanju sistema ekanja u redovima, kao moguoj temi za tezu.
Poetkom 1972. godine, Lari Roberts je otpoeo projekat ARPANET Satellite Svstem (koji je
kasnije nazvan Packet Satellite). Profesor Klajnrok me je zamolio da se pridruim projektu.
Prva stvar koju smo uradili bila je da uvedemo jednostavan, a ipak realistian algoritam
odstupanja u protokol Aloha sa vremenskim odsecima. Ubrzo posle toga, pronaao sam mnogo
zanimljivih problema za istraivanje, kao stoje problem Alohine nestabilnosti i potreba za
adaptivnim odstupanjem, koji bi formirali srce moje teze.
Bili sfe aktivni u prvim onima Interneta u 1970-im godinama, poinjui svoje studentske dane na
UCLA. Kako je tada bilo? Da li su ljudi imali ikakav nagovetaj o tome ta e Internet postati?
Atmosfera zaista nije bila razliita od drugih projekata izgradnje sistema koje sam imao prilike
da vidim u industriji i u akademskim krugovima. Prvobitno postavljeni cilj ARPANET-a bio je
prilino skroman, odnosno, da se obezbedi pristup skupim raunarima sa udaljenih lokacija
tako da mnogo vie naunika moe da ih koristi. Meutim, sa poetkom projekta Packet
Satellite 1972. godine i projekta Packet Radio 1973. godine, cilj ARPA-e se znaajno proirio.
Do 1973. godine, ARPA je gradila tri razliite paketske mree u isto vreme i postalo je
potrebno da Vint Serf i Bob Kan razviju strategiju meusobnog povezivanja.
U to doba, svi ti napredni razvoji u umreavanju bili su vieni (verujem) kao logini, a ne
kao magini. Niko nije mogao da predvidi obim Interneta i snagu dananjih personalnih
raunara. To je bilo deset godina pre pojave prvih PC-ja. Da bi sagledali stvari, veina
studenata su podnosili svoje programe u vidu hrpe buenih kartica za paketnu obradu. Samo
neki studenti su imali direktan pristup raunarima, koji su se obino nalazili u ogranienom
podruju. Modemi su bili spori i jo uvek retkost. Kao diplomirani student, imao sam samo
telefon na stolu i koristio sam olovku i papir da uradim vei deo svog posla.
500 500 500 500
Gde sfe videli da se u budunosti usmerava oblast umreavanja i
Interneta?
U prolosti, jednostavnost Intemetovog IP protokola bila je njegova najvea snaga u slamanju
konkurencije i postajanju de facto standarda za meusobno umreavanje. Za razliku od
konkurencije, kao stoje bio X.25 u 1980-im i ATM u 1990-im godinama, IP moe da radi iznad
bilo koje tehnologije umreavanja sloja veze podataka, zato to on nudi samo najbolju moguu
uslugu datagrama. Zato svaka paketska mrea moe da se povee sa Internetom.
Na nesreu, IP-ova najvea snaga sada je njegov nedostatak. IP lii na tesan kaput koji
ograniava razvoj Intemeia samo na specifine pravce. IP sloj je ekonomski suvie vaan da bi
se popravljao podrkom novim funkcionalnostima, kao to su viestruko usmeravanje i kvalitet
usluge. Poslednjih godina, mnogi istraivai su preusmerili svoje napore na aplikacijski i
transportni sloj za viestruko usmeravanje i kvalitet usluge. Veina drugih trenutnih tema za
istraivanje Interneta, kao to su bezbednost i P2P sistemi, obuhvataju samo aplikacijski sloj.
Postoji takode dosta istraivanja beinih i ad hoc mrea, senzorskih i satelitskih mrea. Na te
mree moe da se gleda kao na samostalne sisteme ili sisteme sloja veze podataka, koji mogu da
cvetaju zato to su izvan tesnog IP kapula.
Mnogi ljudi su uzbueni zbog mogunosti P2P sistema kao platforme za nove primene
Interneta. Meutim, P2P sistemi su veoma neefikasni u svojoj upotrebi Internet resursa. Brinem
se da li e kapacitet prenosa i komutiranja jezgra Interneta nastaviti da se poveava bre od
saobraajnih zahteva na Internetu, kako on raste da bi meusobno povezao sve vrste ureaja i
podrao budue aplikacije osposobljene za P2P. Bez znaajno veeg obezbedenja kapaciteta,
osiguranje stabilnosti mree u prisustvu zlonamernih napada i zaguenja, bio bi glavni zadatak.
Koji je najizazovniji deo vaeg posla?
Najizazovniji deo mog posla kao profesora je poduavanje i motivisanje svakog studenta u mojoj
klasi i svakog doktoranta pod mojim nadzorom, a ne samo onih koji postiu visoke rezultate.
Veoma inteligentni i motivisani mogu traiti malo voenja, ali ne mnogo vie od toga. Ja esto
uim vie od tih studenata nego to oni ue od mene. Obrazovanje i motivisanje onih koji
postiu slabije rezultate predstavlja glavni izazov.

Koje uticaje predviate da e tehnologija imati na uenje u budunosti?
Na kraju, gotovo celokupno ljudsko znanje e biti dostupno preko Interneta, koji e biti naj-
monija alatka za uenje. Ta ogromna baza znanja e imati potencijal ravnopravnog terena za
studente irom sveta. Na primer, motivisani studenti u bilo kojoj zemlji e biti u stanju da
pristupaju najboljim veb lokacijama za asove, multimedijskim predavanjima i materijalima za
poduavanje. Ve sada je reeno da su IEEE i ACM digitalne biblioteke ubrzale razvoj
istraivaa u oblasti raunarskih nauka u Kini. Vremenom, Internet e prevazii sve geografske
prepreke za uenje.
501 501 501 501

263

Beine i
mobilne mree
U svetu telefonije, neki smatraju proteklih 10 godina decenijom mobilne telefonije. Broj
pretplatnika mobilnih telefona u svetu porastao je sa 34 miliona u 1993. na preko milijarde u
2003. godini, tako daje broj mobilnih pretplatnika sada vei od broja osnovnih telefonskih linija
[ITU Statistics 2004]. Glavna prednost mobilnog telefona je svakome oigledna - neogranien
pristup globalnoj telefonskoj mrei bilo gde i bilo kada putem lako prenosivog i laganog
ureaja. Da li se pojavom laptopova, palmtop raunara i PDA-ova i njihovog obeanog
neogranienog pristupa globalnom Internetu sa bilo kog mesta u bilo kom trenutku sprema
slina eksplozija u upotrebi beinih ureaja za Internet?
Bez obzira na budue irenje beinih ureaja za Internet, ve je jasno da beine mree i
usluge vezane za mobilnost nisu prolazna pojava. Iz aspekta umreavanja, izazovi ovih mrea,
pogotovo u sloju veze podataka i mrenom sloju, toliko se razlikuju od uobiajenih oienih
raunarskih mrea daje potrebno zasebno poglavlje posveeno beinim i mobilnim mreama
(ovo poglavlje).
Poglavlje poinjemo opisom mobilnih korisnika, beinih linkova i mrea, kao i njihovog
odnosa prema veim (obino oienim) mreama sa kojima se povezuju. Moramo da
razlikujemo izazove do kojih dolazi zbog beine prirode komunikacionih linkova u'takvim
mreama, i onih koji potiu od mobilnosti koju ti beini linkovi omoguavaju. Povlaenje ove
znaajne granice - izmeu beinog i mobilnog - omoguie nam da bolje izolujemo,
prepoznamo i savladamo kljune koncepte iz

264 264 264 264 POGLAVLJE 6 BEINE I I I I MOBILNE MREE
6.1
UVOD 505 505 505 505

svakog od tih podruja. Obratite panju na to da postoje mnoga mrena okruenja u kojima su
mreni vorovi beini ali nisu mobilni (na primer, beine kune ili kancelarijske mree sa
nepokretnim radnim stanicama i velikim monitorima) i ograniene vrste mobilnosti za koje nisu
potrebni beini linkovi (na primer, radnik koji kod kue koristi laptop povezan icom, iskljui
ga, ode na posao i prikljui laptop na ianu mreu kompanije). Naravno, najzanimljivija su ona
mrena okruenja gde su korisnici i beini i mobilni - na primer, scenario u kome mobilni
korisnik (na primer, na zadnjem seditu automobila) odrava poziv tipa govor preko IP-a" i
nekoliko aktivnih TCP konekcija dok juri autoputem brzinom od 160 km/h. Najzanimljivije
tehnike izazove nalazimo ba tu, na preseku beinog i mobilnog!
Poeemo prvo sa prikazom konfiguracije u kojoj emo razmatrati beine komunikacije i
mobilnost - mreu u kojoj se beini (i eventualno mobilni) korisnici povezuju sa veom
mrenom infrastrukturom putem beinog linka na rubu mree. Zatim emo, u odeljku 6.2,
razmotriti karakteristike tog beinog linka. U isti odeljak smo dodali kratak uvod u CDMA
(Code Division Multiple Access), pristupni protokol deljenih medijuma koji se esto koristi u
beinim mreama. U odeljku 6.3 malo detaljnije emo razmotriti aspekte sloja veze u standardu
za beini LAN, IEEE 802.11 (Wi-Fi); ukratko emo pomenuti i Bluetooth. U odeljku 6.4
dajemo pregled mobilnog pristupa Internetu, ukljuujui nove mobilne tehnologije 3G koje
omoguavaju i govor i pristup Interneta velike brzine. U odeljku 6.5 obra-tiemo panju na
mobilnost usredsreujui se na probleme pronalaenja mobilnog korisnika, rutiranja prema
mobilnom korisniku i predavanju" mobilnog korisnika koji se dinamiki kree od jedne
prikljune take na mrei do druge. U odeljcima 6.6 i 6.7 ispitaemo kako se ove usluge za
mobilnost implementiraju u standardu za mobilni IP, odnosno u GSM-u. Na kraju, u odeljku 6.8,
razmotriemo uticaj beinih linkova i mobilnosti na protokole transportnog sloja i na aplikacije
umreavanja.
KRATAK OSVRT
JAVNI VVI-FI PRISTUP: USKORO STIE NA VA OAK?
Pre samo 5 godina beine raunarske mree bile su retkost. Mada je mnogo investirano u
licence radio spektra za sisteme 3G (potraite kratak osvrt u kojem se poredi 3G mobilnost sa
beinim LAN-ovima], 3G sistemi bili su (i jo uvek su) tek u ranim fazama razvoja. U ono
vreme, nekoliko prvih korisnika je poelo da isprobava upravo standardizovanu tehnologiju za
beini LAN, IEEE 802.11. Kakva pramena za ovih 5 godina! Danas mnoge korporacije,
univerziteti i kue imaju vlastite beine LAN-ove tipa IEEE 802.1 1. Sto je jo znaajnije naglo
raste broj beinih prikljunih taaka - javnih lokacija na kojima korisnici mogu da dobiju beini
pristup 802.11. Grupa Gartner procenjuje da je 2003. godine postojala 71.000 javnih prikljunih
taaka, sto je 50 puta vie od broja koji je postojao 2001. U Sjedinjenim Amerikim Dravama
restorani, kao to su Starbaks i Makdonald, na mnogim lokacijama nude Wi-Fi pristup. U Nju
Jorku, Verizon Communications je postavio take za Wi-Fi pristup u preko 1.000 javnih telefona
i povezao javne telefone sa Internetom [Verizon 2004J, i tako prolaznicima i okolnim
kancelarijama omoguio Wi-Fi pristup. Poetkom 2004. godine, T-Mobile [T-Mobile 2004]
obezbedio je preko 4.000 javnih Wi-Fi prikljunih taaka na lokacijama kao io su aerodromi,
restorani i knjiare. Novoosnovana kompanija Cometa najavila je 2003. godine da planira da
postavi 20.000 komercijalnih Wi-Fi prikljunih taaka na 50 gradskih podruja do 2005. godine.
Uz ovakve tendencije, moe se desiti da e se snovi o nesmetanom pristupu globalnom
Internetu skoro na svakom mestu i u svakom trenutku ostvariti bre nego to smo mislili!
6.1 Uvod
Na slici 6,1 prikazana je konfiguracija u kojoj emo razmatrati teme beine komunikacije
podataka i mobilnosti. Poeemo uoptenim opisom koji pokriva iroku lepezu mrea
ukljuujui i beine LAN-ove, kao to je IEEE 802.11 i mobilne mree, kao Stoje mrea 3G;
detaljnije opise konkretnih beinih arhitektura ostavi-emo za kasnije odeljke. U beinoj mrei
postoje sledei elementi: Beini raunari. Kao i kod oienih mrea, raunari su krajnji
ureaji na kojima se izvravaju aplikacije. Beini raunar moe da bude laptop, palmtop, PDA,
telefon ili stoni raunar. Sami raunari mogu, ali ne moraju da budu mobilni.
Beini linkovi. Raunar se povezuje sa baznom stanicom (koju emo defmisati malo kasnije)
ili sa drugim beinim raunarom pomou beinog komunikacionog linka. Razliite
tehnologije beinih linkova imaju razliite brzine prenosa i mogu da prenose na razliite
razdaljine. Na slici 6.2 prikazano je nekoliko kljunih karakteristika poznatijih standarda za
beine linkove. Te emo standarde opisati u prvoj polovini ovog poglavlja; u odeljku 6.2
razmotriemo takoe i druge karakteristike beinog linka (kao to je uestalost greaka u
bitovima i njihovi uzroci).
Na slici 6.1 beini linkovi povezuju raunare koji se nalaze na periferiji mree u jednu veu
mrenu infrastrukturu. Naglaavamo da se beini linkovi ponekad koriste i unutar mree i
za povezivanje rutera, komutatora i druge mrene opreme. Meutim, u ovom poglavlju se
usredsreujemo na upotrebu beine komunikacije na rubovima mree poto se tu javlja
veina najuzbudljivijih tehnikih izazova i vei deo proirenja.
Bazna stanica. Bazna stanica je kljuni deo beine mrene infrastrukture. Za razliku od
beinog raunara i beinog linka, za baznu stanicu ne postoji

265 POGLAVLJE 6 - BEINE I MOBILNE MREE
6.1 UVOD 507

odgovarajui ekvivalent u oienoj mrei. Bazna stanica je zaduena za slanje i prihvatanje
podataka (npr. paketa) prema beinom raunaru pridruenom toj baznoj stanici. Bazna
stanica se esto zaduuje za koordinisanje prenosa za vize beinih raunara kojima je
pridruena. Kada kaemo da je beini raunar pridruen" jednoj baznoj stanici
podrazumevamo da (1) raunar se nalazi u granicama beine komunikacije sa baznom
stanicom i (2) da raunar koristi tu baznu stanicu za prenoenje podataka prema veoj mrei i
od nje. Celijski tornjevi u mobilnoj telefoniji i pristupne take u beinim LAN-ovima tipa
802.11 su pri-meri baznih stanica.
Na slici 6.1 bazna stanica je povezana sa veom mreom (tj. sa Internetom, korporacijskom
ili kunom mreom, odnosno sa telefonskom mreom), pa tako fun-kcionie kao retej sloja
veze izmeu beinog raunara i ostatka sveta sa kojim raunar komunicira.
Za raunare koji su pridrueni baznoj stanici esto kaemo da rade u infrastrukturnom
reimu, poto sve tradicionalne mrene usluge (npr. dodeljivanje adresa i rutiranje)
obezbeduje mrea na koju je raunar prikljuen preko bazne stanice. U ad hoc mreama
beini raunari nemaju takvu infrastrukturu sa kojom bi se povezali. U odsustvu te
infrastrukture sami raunari moraju da obezbede usluge kao stoje rutiranje, dodeljivanje
adresa, prevoenje DNS imena i tome slino. U ovoj knjizi, pre svega, baviemo se mreama
u infrastrukturnom reimu.
Kada mobilni raunar izae iz dometa jedne bazne stanice i ue u domet druge, on e
promeniti taku povezivanja sa veom mreom (tj. promeniti baznu stanicu kojoj je
pridruen) - taj postupak nazivamo predavanje. Ovakva mobilnost otvara mnoga izazovna
pitanja. Ako raunar moe da se kree, kako da se pronae njegova trenutria lokacija u mrei
da bi mu se prosledili podaci? Kako se vri adresiranje kada raunar moe da se nalazi na
jednoj od vie moguih lokacija? Ako se raunar kree za vreme TCP konekcije ili
telefonskog poziva, kako se podaci rutiraju, a da se konekcija ne prekine? Zbog ovih i
mnogih (mnogih!) drugih pitanja beino i mobilno umreavanje predstavlja podruje
uzbudljivih istraivanja.
Mrena infrastruktura. Ovo je vea mrea sa kojom beini raunar moe da komunicira.
Sada emo detaljnije razmotrili tehnika pitanja koja se javljaju u beinim i mobilnim
mreama. Poinjemo prvo razmatranjem pojedinanog beinog linka, a opisivanje mobilnosti
ostavljamo za kasnije u ovom poglavlju.

508 508 508 508 POGLAVLJE 6 BEINE I MOBILNE MREE
6.2 BEINI LINKOVI I MRENE KARAKTERISTIKE
266 266 266 266J JJ J

6. 2 Beini linkovi i mrene karakteristike
Poeemo razmatranjem jedne jednostavne oiene mree, recimo kune mree, sa oienim
Ethernet komutatorom (proitajte odeljak 5.6) izmeu raunara. Ako oi-eni Ethernet
zamenimo beinom mreom tipa 802.11 u raunare bismo umesto kartica za oieni Ethernet
stavili kartice za beini NIC, umesto Ethernet komutatora stavili bismo pristupnu taku, dok na
mrenom sloju kao i u viim slojevima ne bi bile potrebne praktino nikakve promene. Ovde
vidimo da panju treba usmeriti na sloj veze ako nas zanimaju vane razlike izmeu oiene i
beine mree. Zaista, izmeu oienog i beinog linka postoji niz znaajnih razlika:
Smanjena jaina signala. Elektromagnetno zraenje slabi pri prolasku kroz razliite
materijale (npr. radio signal koji prolazi kroz zid). ak i u slobodnom prostoru se signal
raspruje i to dovodi do smanjene jaine signala (to se ponekad naziva gubitak usled
putovanje) sa poveanjem razdaljine izmeu poiljaoca i primaoca.
Smetnje od drugih izvora. Radio izvori koji emituju u istom frekventnom opsegu utiu jedni
na druge. Na primer, beini telefoni sa 2,4 GHz i beini LAN-ovi tipa 802.11b emituju u
istom frekventnom opsegu. Prema tome, korisnik beinog LAN-a tipa 802.11b koji
razgovara beinim telefonom sa 2,4 GHz ne moe se nadati dobrim performansama ni na
mrei ni na telefonu. Osim smetnji od razliitih izvora emitovanja, elektromagnetni um u
okruenju (npr. motor ili mikro.talasna penica u blizini) takode moe dovesti do smetnji.
Propagiranje po viestrukim putanjama. Propagiranje po viestrukim putanjama se javlja kada se
delovi elektromagnetnog talasa odbiju od objekata ili od zemlje, pa stiu od poiljaoca do
primaoca putanjama razliite duine. To dovodi do zamuenja primljenog signala kod
primaoca. Pokretni objekti izmeu poiljaoca i primaoca mogu da dovedu do toga da se
propagiranje po viestrukim putanjama menja u vremenu.
Iz gornjeg opisa se nasluuje da e greke u bitovima biti ee u beinim linkovima nego u
oienim. Zbog toga moda ne iznenauje da protokoli za beine linkove (kao stoje protokol
802.11 koji razmatramo u sledeem odeljku) koriste ne samo mone CRC kodove za otkrivanje
greaka ve i ARQ protokole u sloju veze koji ponovo alju oteene okvire.
Vea i promenljiva uestalost greaka u bitovima nije jedina razlika izmeu oienog i
beinog linka. Setite se da su u sluaju oienih linkova za difuzno emitovanje svi vorovi
primali prenos od svih ostalih vorova. Kao to se vidi na slici 6.3, kada je re o beinim
linkovima situacija nije tako jednostavna. Pretpostavimo da stanica A alje stanici B.
Pretpostavimo takoe da stanica C alje stanici B. Takozvani problem sakrivenog terminala,
javlja se kada fizike prepreke u okruenju (na pri
mer, planina ili zgrada) onemogue komunikaciju izmeu A i C iako se na odreditu
B njihova emitovanja meusobno ometaju. Ovo je prikazano na slici 6.3(a). Drugi scenario
dovodi do kolizija koje se kod primaoca teko otkrivaju a potiu od opadanja jaine signala
prilikom kretanja kroz beini medijum. Na slici 6.3(b) prikazan je sluaj gde su A i C tako
postavljeni da njihovi signali nisu dovoljno jaki da bi se meusobno otkrili, ali jesu dovoljno jaki
da jedan drugog ometaju u stanici B. Kao to emo videti u odeljku 6.3, viestruki pristup je u
beinoj mrei daleko sloeniji nego u oienoj zbog problema sakrivenog terminala i zbog
opadanja.
6.2.1 CDMA
Verovatno se seate iz poglavlja 5 daje za komunikaciju raunara preko zajednikog medijuma
potreban protokol da se signali od razliitih poiljalaca ne bi meusobno ometali kod primaoca.
U poglavlju 5 opisali.smo tri klase protokola za pristup medi-jumima: podela kanala, sluajni
pristup i redno korienje. CDMA (Code Division Multiple Access) je etvrta vrsta protokola za
pristup deljenom medijumu koja preo-vlauje u tehnologijama beinog LAN-a i mobilne
telefonije. Poto je CDMA tako vaan u beinom svetu sada emo ga ukratko razmotriti pre
nego to se u sledeim odeljcima udubimo u konkretne tehnologije beinog pristupa.
U protokolu CDMA, svaki bit koji se alje kodira se tako to se pomnoi jednim signalom
(kodom) koji se menja daleko bre (brzina seckanja) od prvobitnog niza bitova podataka. Na
slici 6.4 prikazan je jednostavan idealizovani scenario CDMA kodiranja/dekodiranja.
Pretpostavimo da jedinicu vremena definie brzina kojom originalni bitovi podataka stiu do
CDMA nkodera; tj. da se u jednoj jedinici vremena prenosi jedan originalni bit podataka. Neka
di bude vrednost bita podataka

267 267 267 267 POGLAVLJE 6 BEINE 1 MOBILNE MREE
6.2 BEINI LINKOVI I MRENE KARAKTERISTIKE 511 511 511 511

u (-tom vremenskom odseku. Da bi matematiki bilo pogodnije, bit podataka sa vredrioSu 0
prikazujemo kao -1. Svaki cdseak bitova deli se na M mini odseaka; na slici 6.4 Mje jednako
8, mada je u praksi M daleko vee. CDMA kod koju koristi poiljalac je niz od M vrednosti, cm>
m = 1,..., M od kojih je svaka +1 ili -1. U primeni na slici 6.4 poiljalac koristi CDMA kod od
Mbitova (1,1, 1, -1, l, -1, -1, -1), Da bismo ilustrovali kako CDMA funkcionie, razmotriemo
i-ti bit podataka, dv Za.m-xi mini vremenski odseak za prenos bita di CDMA nkoderdajeZ/)j(, a to
je vrednost d; pomnoena sa m-tim bitom dodeljenog CDMA koda, cm:
U jednostavnijem svem, kada ne bi bilo meusobnog ometanja poiljalaca, primalac bi dobio
kodovane bitove, Zjm i ponovo napravio originalni bit podataka dp tako to bi izraunao:
i
u
(6.2)
italac bi mogao detaljno da proradi primer sa slike 6.4 i uveri se da se pomou jednaine
6.2 kod primaoca zaista ispravno dobijaju originalni bitovi podataka.
Svet je meutim, daleko od idealnog, pa kako smo ve napomenuli, CDMA mora da
funkcionie u prisustvu poiljalaca koji se meusobno ometaju, koji koduju i prenose podatke
pomou drugaije dodeljenog koda. Ali, kako e CDMA primalac ponovo da dobije originalne
bitove podataka poiljaoca ako su ti bitovi podataka pomeani sa bitovima koje prenose drugi
poiljaoci? CDMA funkcionie pod pretpostavkom da su pomeani preneseni signali aditivni.
To znai, na primer, da ako 3 poiljaoca alju vrednost 1, a etvrti poiljalac alje vrednost -1
tokom istog mini-odseka, tada primljeni signal kod svih primalaca tokom tog mihi-odseka
iznosi 2 (postoje 1 + 1 + J(-l = 2). Kada imamo vie poiljalaca, poiljalac? izraunava svoj
kodovani izlaz, tano na isti nain kao u jednaini 6.1. Vrednost koju primalac dobije tokom
m-tog mini-odeska u (-tom bitu, meutim sada e biti zbir prenetih bitova od svih N poiljalaca
u tom mini-odseku:
N

Ukoliko se paljivo biraju kodove poiljalaca, svaki primalac moe da rekonstruie poslate
podatke datog poiljaoca iz zbirnog signala ako jednostavno primeni kod poiljaoca tano na isti
nain kao u jednaini 6.2:
4 = TjfX-< (6.3)
Na slici 6.5 prikazan je primer sa dva CDMA poiljaoca. M-bitni CDMA kod gornjeg
poiljaoca je (1, 1, 1,-1, 1,-1,-1,-l)a kod donjeg (1, -1, 1, 1, 1, -1, 1, 1). Na slici 6.5 prikazanje
primalac koji ponovo dobija originalne bitove podataka od gornjeg poiljaoca. Obratite panju
na to da primalac uspeva da izdvoji podatke poiljaoca 1 i pored ometanja prenosom od
poiljaoca 2.
Verovatno se seate analogije sa koktelom iz poglavlja 5. CDMA protokol bio bi slian
govoru u razliitim jezicima; u takvom sluaju ljudi dosta uspeSno prate razgovor na jeziku koji
razumeju i filtriraju sve ostalo. Ovde vidimo daje CDMA protokol koji deli kodni prostor (za
razliku od protokola sa podelom vremena ili frekvencija) i dodeljuje svakom voru odreeni
deo kodnog prostora.

268 POGLAVLJE 6 BEINE I MOBILNE MREE
6.3 VVI-FI: BEINI LAN-OVI TIPA 802.1 1
513

Ovaj opis protokola CDMA morao je da bude kratak; u praksi je potrebno uzeti u obzir niz
sloenih pitanja. Prvo, da bi CDMA primaoci mogli da izdvoje signal konkretnog poiljaoca, potrebno
je paljivo birati CDMA kodove. Drugo, u opisu smo pretpostavili da su jaine signala ra'zliitih
poiljalaca iste, a to se u stvarnosti teko postie. Veliki broj knjiga bavi se ovim i drugim pitanjima
vezanim za CDMA; detalje moete nai u knjigama [Pickholtz 1982; Viterbi 1995].
6.3 Wi-Fi: Beini LAN-ovi tipa 802.11
S obzirom na to da se koriste na poslu, kod kue, u obrazovnim ustanovama, kafe-ima,
aerodromima i u ulinim govornicama, beini LAN-ovi danas predstavljaju jednu od najvanijih
tehnologija za pristup mreama na Internetu. Mada je tokom '90-tih godina razvijeno vie tehnologija
i standarda, neosporno pobeuje jedna odreena klasa standarda; beini LAN IEEE 802.11, poznat
takode kao Wi-Fi. U ovom odeljku detaljno emo razmotriti beini LAN 802.11 tako to emo prouiti
strukturu okvira 802.11, protokol za pristup medijima 802.11 i meusobno povezivanje mrea LAN
802.11 sa oienim Ethernet LAN-ovima.
Za tehnologiju beinog LAN-a postoji nekoliko standarda 802.11. Tu izmeu ostalog spadaju
802.11b, 802.11a i 802.1 Ig. TJ tabeli 6.1 ukratko su prikazane glavne karakteristike ovih standarda,
Dok ovo piemo (prolee 2004) beini LAN-ovi 802.1 lb daleko su najzastupljeniji. Meutim, postoji i
iroka ponuda proizvoda 802.1 l a i 802.1 Ig, pa se u narednim godinama moe oekivati znaajno
uvoenje ovih beinih LAN-ova sa veim brzinama.
Tri standarda 802.11 imaju mnoge zajednike karakteristike. Sva tri koriste isti protokol za
pristup medijumima CSMA/CA koji emo ubrzo opisati. Svi za okvire sloja veze koriste istu strukturu
okvira. Sva tri standarda su u stanju da smanje brzinu prenosa da bi se poveala dostupna
udaljenost. Svi omoguavaju reim infrastrukture" i ,,ad hoc reim", to emo takoe ubrzo opisati.
Meutim, kao to e vidi iz tabele 6.1 ova tri standarda sadre neke bitne razlike u fizikom sloju.

514 514 514 514
POGLAVLJE BEINE I MOBILNE MREE
6.3 VVI-Fi: BEZICNIlAN-OVITIPA 802.il 515 515 515 515
Beini LAN 802.11b ima brzinu prenosa od 11 Mb/s, Stoje vie nego dovoljno za veinu
kunih mrea sa pristupom Internetu preko irokopojasnog kabla ili DSL-a. LAN-ovi 802.11b
funkcioniu u opsegu frekvencija bez licenci (2,4 do 2,485 GHz), u kojem mora da se bori sa
telefonima od 2,4 GHz i mikrotalasnim penicama. Beini LAN-ovi 802.Da mogu da rade na
znaajno veim brzinama, ali na veim frekvencijama. Meutim, poto rade na veoj frekvenciji,
LAN-ovi 802.11a imaju krai domet prenosa za dati nivo snage i podloniji su smetnjama od
propagiranja po viestrukim putanjama. Poto LAN-ovi 802.1 lg funkcioniu na istom niem
frekventnom opsegu kao 802.11 b, ali pri veim brzinama prenosa kao 802.11a, trebalo bi
korisnicima da omogue ,,i jare i pare".

63.1 Arhitektura 802.11
Na slici 6.6 prikazane su glavne komponente arhitekture beinog LAN-a 802.11. Osnovni
element arhitekture 802.11 je BSS (Basic Service Set, skup osnovne usluge). BSS sadri jednu ili
vie beinih stanica i centralnu baznu stanicu koja se u argonu 802.31 naziva AP (Access
Point, pristupna taka). Na slici 6.6 prikazano je kako se pristupne take (AP) u svakom od dva
BSS-a povezuju sa ureajem za povezivanje (hab, komutator ili ruter) koji zatim vodi do
Interneta. U prosenoj kunoj mrei postoji jedan AP ijedan ruter (esto se u istoj kutiji nalazi i
kablovski ili ADSL modem) koji povezuje BSS sa Internetom.
Kao i kod Ethernet ureaja, svaka beina stanica 802.11 ima 6-bajtnu MAC adresu koja se
uva u firmveru kartice (tj. kartice mrenog interfejsa 802.11). Svaki AP takoe ima MAC
adresu za svoj beini interfejs. Kao i kod Interneta, ovim MAC adresama administrira IEEE i
one su (teoretski) globalno jedinstvene.
Kao stoje napomenuto u odeljku 6.1, beini LAN-ovi sa pristupnim takama esto se
nazivaju infrastrukturni beini LAN-ovi, gde se infrastruktura" sastoji od pristupnih taaka
zajedno sa oienom Ethemet infrastrukturom koja povezuje pristupne take i ruter. Na slici 6.7
prikazano je da stanice IEEE 802.11 mogu takoe da se grupiu u ad hoc mreu - mreu bez
centralne kontrole i bez povezivanja sa spoljnim svetom". Ovde se mrea formira usput" od
mobilnih ureaja koji su trenutno u blizini, a imaju potrebu za meusobnom komunikacijom,
iako u blizini nema postojee mrene infrastrukture. Ad hoc mrea moe da se napravi kada se
sastanu ljudi sa laptopovima (na primer, u sali za konferencije, u vozu ili automobilu) koji ele
da razmene podatke, a u blizini ne postoji centralizovana pristupna taka. Kako se iri upotreba
prenosivih ureaja za komunikaciju, javlja se izuzetno zanimanje za ad hoc umreavanje. U
ovom odeljku emo se ipak usredsrediti na infrastrukturne beine LAN-ove.
Kanali i pridruivanje
Pod protokolom 802.11, da bi beina stanica mogla da alje ili prima okvire 802 11 koji sadre
podatke mrenog sloja, ona se mora pridruiti nekoj pristupnoj taki Mada svi standardi 802.11
koriste pridruivanje, ovu temu emo konkretno opisati u kontekstu protokola IEEE 802.11 b

o.3 . VVI-FI: BEINI LAN-OVITIPA802.il 270

Kada mreni administrator instalira pristupnu taku, on joj dodeljuje identifikacioni broj
SSID (Service Set Identifier) od jedne ili dve rei. (Kada, na primer, u Microsoft Windowsu XP
prikaete dostupne mree" prikazuje se lista SSID-ova svih dostupnih pristupnih taaka.)
Administrator mora pristupnoj taki takode da dodeli i broj kanala. Da biste shvatili brojeve
kanala, imajte na umu da protokol 802.11 b funkcionie u frekventnom opsegu 2,4 GHz do 2,485
GHz. U ovom rasponu od 85 MHz, protokol 802.11b definie 11 kanala koji se delimino
preklapaju. Dva kanala se ne preklapaju ako i samo ako ih razdvaja 4 ili vie kanala. Konkretno,
skup kanala 1, 6 i 11 je jedini skup od tri kanala koji se ne preklapaju. Ovo znai da bi
administrator mogao da napravi beini LAN sa ukupnom maksimalnom brzinom prenosa od 33
Mb/s tako to bi na istoj fizikoj lokaciji instalirao 3 pristupne take 802.11b, dodelio im kanale
1, 6 i 11 i povezao svaku pristupnu taku sa jednim komutatorom.
Uz ovo osnovno poznavanje kanala 802.11, opisaemo jednu zanimljivu (ne ba tako retku)
situaciju - Wi-Fi dunglu. Wi-Fi dungla je svaka fizika lokacija u kojoj beina stanica prima
dovoljno jak signal od dve ili vie pristupnih taaka. Na primer, u mnogim kafeima u Ne\v Yorku
beina stanica moe da uhvati signal od mnogih oblinjih pristupnih taaka. Jedna od pristupnih
taaka bi mogla da pripada kafeu dok ostale mogu da budu u stanovima u blizini kafea. Svaka od
ovih pristupnih taaka se verovatno nalazi u drugoj podmrei sa nezavisno dodeljenim kanalom.
Pretpostavimo sada da u takvu Wi-Fi dunglu uete sa svojim prenosivim rau-narom i
naruite beini pristup Internetu i kola sa borovnicama. Uzmimo da u dungli ima 5 pristupnih
taaka. Da bi dobila pristup Internetu, vaa beina stanica mora da pristupi tano jednoj
podmrei i mora da se pridrui tano jednoj pristupnoj taki. Pridruivanje znai da beina
stanica pravi virtuelnu icu izmeu sebe i pristupne take. Konkretno, samo pridruena pristupna
taka e da alje okvire podataka (tj. okvire koji sadre podatke, kao to su datagrami) prema
vaoj beinoj stanici, a vaa beina stanica e slati okvire podataka na Internet samo preko pri-
druene pristupne take. Ali, kako e se vaa beina stanica pridruiti konkretnoj pristupnoj
taki? Jo vanije, kako e vaa beina stanica saznati da li u dungli ima pristupnih taaka i
koje su one?
Standard 802.11 zahteva da pristupna taka povremeno alje okvire za navoenje koji sadre
SSID i MAC adresu pristupne take. Poto zna da pristupne take alju okvire za navoenje vaa
beina stanica osmatra svih 11 kanala i eka okvir za navoenje bilo koje pristupne take u
blizini (od kojih neke emituju na istim kanalima - prava dungla!). Kada i z okvira za navoenje
utvrdi koje pristupne take su dostupne, va beini raunar bira jednu od pristupnih taaka za
pridruivanje. Kada se izabere pristupna taka, va beini raunar i izabrana pristupna taka pre-
govaraju koristei protokol za pridruivanje 802.11. Ako se u tom pregovaranju sve dobro zavri,
vaa beina stanica postaje pridruena izabranoj pristupnoj taki. Implicitno, tokom faze
pridruivanja, vaa beina stanica pristupa podmrei kojoj pripada izabrana pristupna taka.
Odmah nakon faze pridruivanja, beina stanica
e preko pridruene pristupne take obino poslati u podmreu poruku DHCP otkrivanja
(proitajte odeljak 5.4.3) kako bi dobila IP adresu u podmrei pristupne take. Od tog trenutka,
va raunar vidi ostatak Interneta jednostavno kao raunar u podmrei pristupne take.
Da bi uspostavila pridruivanje sa konkretnom pristupnom takom, beina stanica
ponekad mora pristupnoj taki da dokae svoju autentinost. Beini LAN-ovi 802.11
predviaju niz alternativa za dokazivanje autentinosti i za pristupanje. Jedan pristup, koji
koriste mnoge kompanije, jeste da se dozvoli pristup beinoj mrei na osnovu MAC adrese
odreene stanice. Drugi pristup, koji se koristi u mnogim Internet kafeima upotrebljava
korisnika imena i lozinke. U oba sluaja, pristupna taka obino komunicira sa serverom za
proveru autentinosti tako to prenosi podatke izmeu krajnje beine'stanice i servera za
proveru autentinosti koristei protokole kao to su RADIUS [RFC 2138] ili DIAMETER [RFC
3588]. Razdvajanjem servera za proveru autentinosti od pristupne take omoguava se da jedan
server opslui mnoge pristupne take i centralizuju se (esto osetljive) odluke o autentinosti i
pristupu, pa tako trokovi i sloenost pristupnih taaka ostaju niski. U odeljku 8.8.4 videemo da
novi protokol IEEE 802.11 i koji definie bezbednosne aspekte familije protokola 802.11
prihvata upravo ovaj pristup.

6.3.2 MAC protokol 802.11
Poto se beina stanica pridrui pristupnoj taki, ona moe da pone da alje okvire podataka
pristupnoj taki i da ih prima od nje. Ali, poto se deava da vie stanica u isto vreme pokuava
da alje okvire podataka preko istog kanala, potreban je protokol za viestruki pristup koji e
koordinisati te prenose. Ovde, stanica moe biti beina stanica ili pristupna taka. Kao to je
opisano u poglavlju 5 i odeljku 6.2.1, u optem smislu postoje etiri klase protokola viestrukog
pristupa: podela kanala, sluajni pristup, redna upotreba i CDMA. Pod uticajem velikog uspeha
Ethemeta i njegovog protokola direktnog pristupa, projektanti protokola 802.11 su za beini
LAN 802.11 izabrali protokol sa direktnim pristupom. Ovaj protokol se naziva CSMA sa
izbcgavanjem kolizija ili ukratko CSMA/CA. Kao i kod Ethernetovog CSMA/CD, CSMA"
znai Carrier Sense Muliple Access, to znai da svaka stanica pronalazi kanal pre nego to
pone da emituje i da se uzdrava od emitovanja kada oseti da je kanal zauzet. Mada i Ethernet i
802.11 koriste direktan pristup sa ispitivanjem nosioca, izmeu ova dva MAC protokola postoje
znaajne razlike. Prvo, umesto otkrivanja kolizija 802.11 koristi tehnike za izbegavanje kolizija.
Drugo, zbog relativno visoke uestalosti greaka u bitovima u beinim kanalima, 802.11 (za
razliku od Ethemeta) koristi ARQ emu u sloju veze za potvrivanje i ponovno slanje. Sada emo
opisati izbegavanje kolizija i eme za potvrivanje u sloju veze u protokolu 802.11.
Verovatno se seate iz odeljaka 5.3 i 5.5 da u Ethemetovom algoritmu za otkrivanje
kolizija Ethernet stanica oslukuje kanal tokom emitovanja. Ako tokom prenosa otkrije da neka
druga stanica takode emituje, ova prekida prenos i pokuava da

6.3 VV/-R; BEINI LAN-OVI TIPA 802.11
271

alje kasnije po isteku malog, sluajno izabranog vremenskog intervala. Za razliku od Ethernet
protokola 802.3, MAC protokol 802.11 ne primenjuje otkrivanje kolizija. Za to postoje dva
vana razloga:
Sposobnost da se otkriju kolizije zahteva sposobnost istovremenog slanja (vlastitog signala
stanice) i primanja (da bi se utvrdilo da li jo neka stanica takoe alje). Poto je jaina
primljenog signala obino veoma mala u poreenju sa jainom signala koji se alje sa kartice
802.11, skupo je praviti hardver koji je u stanju da otkrije koliziju.
Jo vanjje, ak i kada bi kartica mogla istovremeno da emituje i da slua (i eventualno
prekine slanje kada otkrije optereenost kanala), adapter ipak ne bi mogao da otkrije sve
kolizije zbog problema sakrivenog terminala i opadanja kao to je opisano u odeljku 6.2.
Poto beini LAN-ovi 802.11 ne koriste otkrivanje kolizije, stanica koja pone sa slanjem
okvira alje okvir u potpunosti; tj. kad se stanica pokrene, nema vie povratka. Logino je da
slanje celih okvira (pogotovo dugakih okvira) u situaciji sa mnogo kolizija moe znaajno da
utie na performanse protokola viestrukog pristupa, Da bi se smanjila verovatnoa kolizija,
802.11 koristi nekoliko tehnika za izbegavanje kolizija koje emo uskoro opisati.
Pre nego to preemo na razmatranje izbegavanja kolizija, moramo prvo da razmotrimo
emu potvrda u sloju veze protokola 802.11. U odeljku 6.2 je ve reeno da kada stanica na
beinom LAN-u poalje okvir, on moe iz razliitih razloga da ne stigne do odredine stanice.
Zbog ove nezanemarljive verovatnoe neuspeha MAC 802.11 koristi potvrde u sloju veze. Kao
stoje prikazano na slici 6.8, kada odredina stanica primi okvir koji uspeno proe CRC proveru,
ona eka jedan kratak vremenski interval poznat kao SIFS (Short Inter-frame Spacing), a zatim
vraa okvir potvrde. Ako otpremna stanica u zadatom intervalu ne primi potvrdu, ona
pretpostavlja daje dolo do greke i ponovo alje isti okvir tako to za pristup kanalu ponovo
koristi protokol CSMA/CA. Ako potvrda ne stigne nakon odreenog broja ponovnih slanja,
otpremna stanica odustaje i odbacuje okvir.
Poto smo opisali kako 802.11 koristi potvrde sloja veze, sada moemo da opiemo
CSMA/CA protokol 802.11. Pretpostavimo da stanica (beina stanica ili pristupna taka) ima
okvir za slanje.
1. Ako stanica na poetku vidi daje kanal slobodan, ona alje svoj okvir nakon kratkog
vremenskog intervala poznatog kao DIFS (Disiributed Interframe Space); slika 6.8.
2. Inae, stanica bira sluajnu vrednost za odstupanje i odbrojava od te vrednosti sve dok je
kanal slobodan. Kada se otkrije zauzee kanala, vrednost brojaa se zamrzava.
3. Kada broja doe do 0 (obratite panju na to da do loga jedino moe doi kada je kanal
slobodan), stanica alje ceo okvir i zatim eka na potvrdu.
4. Ako se primi potvrda, otpremna stanica zna daje njen okvir pravilno primljen u odredinoj
stanici. Ako stanica ima jo neki okvir za slanje, ona pokree protokol CSMA/CA od take
2. Ako se potvrda ne primi, otpremna stanica ponovo prelazi na fazu oporavka iz koraka 2
tako to sluajnu vrednost bira iz veeg intervala.

Pronicljivi italac je moda primetio da u koraku 2 stanica bira sluajnu vrednost za
odstupanje i poinje odbrojavanje, pa tako odlae prenos ak i kada vidi daje kanal slobodan. U
Ethernetovom CSMA/CD protokolu za viestruki pristup (odeljak 5.5.2)'meutim, stanica
poinje sa slanjem im otkrije daje kanal slobodan. Zbog ega se u ovom pogledu CSMA/CD i
CSMA/CA tako razliito ponaaju?
Da bismo odgovorili na ovo pitanje, razmotrimo scenario u kojem dve stanice imaju okvire
podataka za slanje, ali nijedna od njih ne alje odmah zbog toga to otkriva da neka trea stanica
ve emituje, U Ethernetovom CSMA/CD-u obe stanice

6.3 . VVI-FI: BEINI LAN-OVI TIPA 802.11 521 521 521 521

bi poele da alju im bi otkrile daje trea stanica prestala sa slanjem. To bi dovelo do kolizije
to u protokolu CSMA/CD nije ozbiljan problem poto bi obe stanice prekinule sa slanjem i tako
tzbegle nepotrebno emitovanje ostatka okvira koji je pretr-peo koliziju. Meutim, u protokolu
802.11 situacija je sasvim razliita. Poto 802,11 ne prekida prenos kada otkrije koliziju, okvir
koji je pretrpeo koliziju bi se preneo u celosti. U protokolu 802.11 cilj je da se kolizije izbegnu
kad god je to mogue. U ovom protokolu, ako dve stanice vide daje kanal zauzet, one obe odmak
pokreu odstupanje sa sluajnim vrednostima za koje se pretpostavlja da e biti razliite. Ako su
te vrednosti zaista razliite, kada se kanal oslobodi jedna od stanica e poeti da alje pre druge
stanice, pa e gubilnika stanica" (pod pretpostavkom da stanice nisu sakrivene jedna od druge)
uoiti signal pobednike stanice", zamrznuti svoj broja i saekati sa slanjem sve dok
pobednika stanica ne zavri svoje slanje. Na ovaj nain izbegnutaje skupa kolizija. Naravno, i sa
protokolom 802.11 su kolizije mogue: ako su stanice sakrivene jedna od druge ili ako su
izabrale identine sluajne vrednosti za odstupanje.

Tretiranje sakrivenih terminala: RTS i CTS
MAC protokol 802.11 takoe sadri izvanrednu (opcionu) emu rezervacija koja pomae da se
izbegnu kolizije ak i u sluaju sakrivenih terminala. Ispitajmo ovu emu u kontekstu slike 6.9
gde su prikazane dve beine stanice i jedna pristupna taka. Obe beine stanice su u dometu
pristupne take (iji domet je prikazan kao oseneni krug) i obe su se pridruile pristupnoj taki.
Meutim, zbog opadanja, domet signala beinih stanica ogranienje na unutranji deo
osenenih krugova prikazanih na slici 6.9. Zbog toga, svaka beina stanica je sakrivena od
druge iako nijedna nije sakrivena od pristupne take.
Razmotrimo sada zato sakriveni terminali mogu da predstavljaju problem. Pretpostavimo
da stanica Hl alje okvir i da na pola tog slanja mreni sloj u stanici H2 preda MAC protokolu
802.11 jedan okvir (koji emo ovde nazvati okvir DATA). Poto ne primeuje slanje iz stanice
Hl, H2 e prvo saekati jedno kratko sluajno izabrano vreme, a zatim e poeti da alje okvir
DATA i tako dovesti do kolizije. Kanal e prema tome biti protraen tokom celog intervala
emitovanja iz Hl kao i iz H2.
Da bi se ovaj problem izbegao, protokol IEEE 802,11 omoguava stanici da jednim kratkim
kontrolnim okvirom RTS (Request To Send) i jednim kratkim kontrolnim okvirom CTS (Clear
To Send) rezervie pristup kanalu. Kada poiljalac hoe da poalje okvir DATA,.on moe
pristupnoj stanici prvo da poalje okvir RTS, i naznai ukupno vreme potrebno za prenos okvira
DATA i okvira potvrde (ACK). Kada pristupna stanica dobije okvir RTS, ona odgovara difuznim
emitovanjem okvira CTS. Okvir CTS ima dve svrhe: on daje poiljaocu eksplicitnu dozvolu da
alje i takoe obavetava ostale stanice da ne alju tokom rezervisanog perioda.
Na taj nain, kako vidimo na slici 6.10, prc nego to poalje okvir DATA, H1 prvo difuzno
emituje okvir RTS koji uju sve stanice u njegovom krugu ukljuujui pristupnu taku AP.
Pristupna taka zatim odgovara svojim okvirom CTS koji uju sve stanice unutar dometa,
ukljuujui Hl i H2. Stanica H2, postoje ula CTS, uzdrava se od slanja u intervalu navedenom
u okviru CTS. Na slici 6.10 prikazani su okviri RTS, CTS, DATA i ACK.
Korienje okvira RTS i CTS poboljava performanse na dva znaajna naina;
Problem sakrivenih stanica se ublaava poto se dugaki okvir DATA alje tek postoje kana!
rezervisan.
Posto su okviri RTS i CTS kratki, kolizija u kojoj uestvuje RTS ili CTS okvir trajae samo
koliko traje takav kratak okvir. Poto se okviri RTS i CTS ispravno prenesu, naredni okviri
DATA i ACK trebalo bi da prou bez kolizije.
Pogledajte aplet 802.11 na veb lokaciji ovog udbenika. Ovaj interaktivni aplet ilustruje
protokol CSMA/CA ukljuujui i razmenu RTS/CTS.
Mada razmena RTS/CTS moe da pomogne u smanjenju broja kolizija, ona takoe dovodi
do kanjenja i troi resurse kanala. Iz tog razloga se razmena RTS/ CTS koristi jedino da bi se
rezervisao kanal za prenos dugakog okvira DATA. TJ praksi, svaka beina stanica moe da
uspostavi RTS prag, pa da se paketi RTS/

6.3 . VVI-FI: BEINI LAN-OVI TIPA 802.11 273
512
POGLAVLJE 6 BEINE I MOBILNE MREE

^^^^^^^^
Koritenje protokola 802.11 u linku od take do take
Do sada smo opisivali 802.11 u situaciji viestrukog pristupa. Trebalo bi da pome-nemo da ako
dva vora imaju usmerive antene, oni mogu da usmere te antene jednu prema drugoj i da
izvravaju protokol 802.1L preko linka koji je u sutini od take do take. Zbog jeftinog hardvera
za 802.11, korienja usmerivih antena i sve vee jaine prenosa, 802.11 moe da se koristi kao
jeftin nain za beine konekcije od take do take na razdaljinama od nekoliko desetina
kilometara. U knjizi [Bhagvvat 2003J opisana je takva beina mrea sa vie skokova koja
funkcionie u seoskim podrujima oko reke Gang u Indiji sa linkovima 802.11 od take do take.
Okvir IEEE 802.11
Mada okvir 802.11 ima mnogo slinosti sa Ethernetovim okvirom, on takoe sadri niz polja
specifinih za njegove beine linkove. Okvir 802.11 prikazan je na slici 6.11. Brojevi iznad
polja u okviru predstavljaju duinu tih polja u bajtovima; brojevi iznad podpolja u kontrolnom
polju okvira predstavljaju duine tih podpolja u bitovima. Ispitajmo sada polja u okviru, kao i
neke od znaajnijih podpolja u kontrolnom polju okvira.
Polja korisnog terera i CRC
Glavno polje u okviru je polje korisnog tereta koje obino sadri jedan IP datagram ili ARP
paket. Mada je dozvoljeno da polje bude dugako 2312 bajtova, ono je obino manje od 1500
bajtova i sadri jedan IP datagram ili ARP paket. Kao i Ethernet okviri, okviri 802.11 sadre
CRC (Cyclic Redundancy Check) tako da primalac moe da otkrije greke u bitovima primljenog
okvira. Kao to smo videli, greke u bitovima su mnogo ee u beinim LAN-ovima nego u
oienim, pa je CRC ovde jo korisniji.

6.3 . VVI-FI: BEINI LAN-OVI TIPA 802.11
525 525 525 525

Polja adresa
Moda je najupadljivija novost u okviru 802.11 to to postoje etiri adresna polja od kojih svako
moe da primi 6-bajtnu MAC adresu. Ali zato etiri adresna polja? Zar nije dovoljno MAC
polje izvora i MAC polje odredita kao kod Etherneta? Ispada da su za meusobno povezivanje
mrea potrebna tri adresna polja - konkretno, za prenos datagrama mrenog sloja iz beine
stanice kroz pristupnu taku u interfejs rutera. etvrto adresno polje koristi se u ad hoc mreama,
ali ne i u infrastrukturnim mreama. Poto ovde razmatramo samo infrastrukturne mree,
obratiemo panju na prva tri adresna polja. Standard 802.11 definie ova polja na sledei nain:
Adresa 2 je MAC adresa stanice koja alje okvir. Prema tome, ako beina stanica alje
okvir, u adresno polje 2 stavlja se MAC adresa te stanice. Slino tome, ako pristupna taka
alje okvir, u adresno polje 2 stavlja se MAC adresa pristupne take.
Adresa 1 je MAC adresa beine stanice koja treba da primi okvir. Prema tome, ako okvir
alje mobilna beina stanica, polje adrese 1 sadri MAC adresu odredine pristupne take.
Slino tome, ako okvir alje pristupna taka, polje adrese 1 sadri MAC adresu odredine
beine stanice.
Da biste shvatili adresu 3, setite se da BSS (koji se sastoji od pristupne take i beinih
stanica) ini deo podmree i da se ova podmrea povezuje sa drugim podmreama preko
nekog ruterskog interfejsa, Adresa 3 sadri MAC adresu ovog interfejsa na ruteru.
Da bismo bolje shvatili svrhu adrese 3, razmotrimo primer meumrenog povezivanja u
kontekstu slike 6.12. Na ovoj slici postoje dve pristupne take od kojih je svaka zaduena za niz
beinih stanica. Svaka od pristupnih taaka ima direktnu vezu sa ruterom koji se zatim povezuje
sa globalnim Internetom. Trebalo bi imati na umu da je pristupna taka ureaj sloja veze, pa ni
jedna od njih ne govori" IP niti razume IP adrese. Razmotrite sada prenos datagrama od
ruterskog interfejsa Rl do beine stanice Hl. Ruter nije svestan da izmeu njega i stanice Hl
postoji pristupna taka AP; iz perspektive rutera, Hl je prosto raunar u jednoj od podmrea sa
kojima je on (ruter) spojen.
Ruter, koji zna IP adresu stanice Hl (na osnovu adrese odredita u datagramu), koristi ARP da
bi utvrdio MAC adresu Hl, kao u obinom Ethernet LAN-u. Kada pribavi MAC adresu
stanice Hl, ruterski interfejs Rl enkapsulira datagram u Ethernet okvir. Polje izvorne adrese u
ovom okviru sadri MAC adresu interfejsa Rl, a polje adrese odredita sadri MAC adresu
stanice Hl.
Kada Ethernet okvir stigne u pristupnu taku AP, AP konvertuje Ethernet okvir 802.3 u okvir
802.11 pre nego to ga poalje u beini kanal. AP popunjava prvu adresu MAC adresnog
raunara Hl, a adresu 2 vlastitom MAC adresom, kao Stoje gore opisano. U polje za treu
adresu AP ubacuje MAC adresu rutera Rl. Na taj nain, Hl e (iz adrese 3) saznati MAC
adresu ruterskog interfejsa koji je poslao datagram u podmreu.
Razmotrimo sada ta se dogaa kada beina stanica HI odgovori slanjem datagrama iz Hl u Rl.
Hl pravi okvir 802.11 i popunjava adresu 1 MAC adresom pristupne take, a polje adrese 2
MAC adresom stanice Hl, kao stoje gore opisano. U polje adrese 3 H1 unosi MAC adresu
rutera Rl,
Kada AP primi okvir, 802.11 konvertuje ga u Ethernet okvir. Polje adrese izvora u tom
okviru bie MAC adresa stanice Hl, a polje adrese odredita bie MAC adresa rutera Rl.
Prema tome, polje adrese 3 omoguava pristupnoj taki da odredi odgovarajuu MAC adresu
odredita da bi napravila Ethernet okvir.

6.3 . VVI-FI; BEINI LAN-OVJTIPA 802.il 275
526 POGLAVLJE 6 BEINE 1 MOBILNE MREE

Da rezimiramo, adresa 3 igra kljunu ulogu za meusobno umreavanje bazne stanice sa
oienim LAN-om.

Polja rednog broja, trajanja i kontrole okvira
Verovatno se seate da u standardu 802.11 stanica uvek vraa potvrdu kad god pravilno primi
okvir od druge stanice. Poto potvrde mogu da se izgube, otpremna stanica bi mogla da poalje
vie primeraka datog okvira. Kao to smo videli u opisu protokola rdt2.1 (odeljak 3.4.1) redni
brojevi omoguavaju primaocu da razlikuje novi okvir od nekog ponovo poslatog starog okvira.
Polje rednog broja u okviru 802.11 prema tome ima istu svrhu ovde u sloju veze kao to je
imalo u transportnom sloju u poglavlju 3.
Imajte na umu da protokol 802,11 dozvoljava otpremnoj stanici da rezervie kanal za
odreen vremenski period dovoljan da se poalje okvir podataka i da se primi potvrda. Ta
vrednost se stavlja u polje trajanja (kako u okvir podataka tako i u okvire RTS i CTS).
Kao to je prikazano na slici 6,11 kontrolno polje okvira ima vie delova. Rei emo samo
nekoliko rei o nekim najvanijim delovima; potpun opis moete nai u specifikaciji 802.11
[Heid 2001; Crow 1997; IEEE 802.11 1999]. Polja tip i podtip slue da bi se okviri podataka
razlikovali od pridruenih okvira RTS, CTS i ACK. Polja prema i od se koriste da bi sc odredilo
znaenje razliitih polja za adrese (Ova znaenja se menjaju zavisno od toga da li se koristi ad
hoc reim ili reim infrastrukture, a u sluaju da se koristi reim infrastrukture, znaenje zavisi
od toga da li okvir alje beina stanica ili pristupna taka.) Na kraju, polje WEP oznaava da li
se koristi ifrovanje. (WEP se opisuje u poglavlju 8.)

6.3.4 Mobilnost unutar iste IP podmree
Da bi se poveao fiziki domet beinog LAN-a, kompanije i univerziteti postavljaju vie baznih
stanica unutar iste IP podmree. Ovo, naravno, otvara pitanje mobilnosti izmeu baznih stanica
kako da se beine stanice neprimetno prebacuju sa jedne na drugu baznu stanicu ne
prekidajui postojee TCP konekcije? Kao to emo videti u ovom odeljku, kada bazne stanice
pripadaju istoj podmrei mobilnost se relativno jednostavno omoguava. Kada se stanice kreu
po razliitim podmreama, bie potrebni sloeniji protokoli za upravljanje koje emo prouiti u
odeljcima 6.5 i 6.6.
Pogledajmo sada konkretan primer mobilnosti izmeu baznih stanica u istoj podmrei. Na
slici 6.13 prikazane su dve meusobno povezane bazne stanice i jedan raunar, Hl koji se kree
izmeu baznih stanica BSS1 i BSS2. Poto u ovom primeru ureaj koji'meusobno povezuje
bazne stanice nije ruter, sve stanice iz ovih baznih stanica, ukljuujui' i pristupne take AP
pripadaju istoj IP podmrei. Prema tome, kada Hl pree sa BSS1 na BSS2 on moe da zadri
svoju IP adresu i sve TCP
konekcije koje su u toku. Da je ureaj za meusobno povezivanje bio ruter, tada bi H1 morao ili
da promeni IP adresu, pa da prekine TCP konekcije koje su u toku ili da upotrebi protokol za
mobilnost iz mrenog sloja kakav je mobilni IP kao to je opisano u odeljku 6.6.
Ali, ta se konkretno deava kada Hl prede sa BSS1 na BSS2? Kako se Hl udaljava od
pristupne take AP 1, on otkriva da signal pristupne take slabi pa poinje da trai neki jai
signal. Hl prima okvire za navoenje od pristupne take AP2 (koja e u mnogim korporacijskim
i univerzitetskim okruenjima imati isti SSID kao APl). H1 zatim raskida pridruivanje sa
pristupnom takom AP 1 i pridruuje se taki AP2 zadravajui istu IP adresu i ne prekidajui
TCP konekcije koje su bile u toku.
Ovo sve funkcionie kako treba ako je ureaj za meusobno povezivanje hab. Ali, ako je taj
ureaj komutator - to je esto sluaj - potrebno je obratiti posebnu panju. Kao to se moda
seate iz poglavlja 5, komutatori sami ue" i automatski grade svoje tabele za prosleivanje. Ta
njihova sposobnost je korisna prilikom povremenih premetanja (na primer, kad nekog
zaposlenog premeste iz jednog odeljenja u drugo); meutim, komutatori nisu projektovani za
podrku veoma pokretnih korisnika koji ele da odre TCP konekcije dok se premetaju izmeu
baznih stanica. Da biste shvatili problem koji st ovde javlja, imajte na umu da pre premetanja
komutator u tabeli prosleivanja ima stavku u kojoj se MAC adresa stanice Hl uparuje sa
izlaznim interfejsom komutatora preko kojeg se moe pronai Hl. Ako se H) na poetku nalazi u
baznoj slanici BSSI, tada e se datagram ije je odrediste Hl uputiti preko pristupne take APl.
Meutim, kada se Hl pridrui BSS2, njegove okvire treba uputiti prema pristupnoj taki AP2.
Jedno reenje (u sutini, doskoica) je da AP2 odmah nakon novog pridruivanja poalje
komutatoru difuzno emitovani

276 276 276 276

6.4 . CELULARNI PRISTUP INTERNETU . 529j
i
Ethernet okvir sa adresom izvora Hl. Kada komutator primi taj okvir, on aurira svoju tabelu
prosledivanja i tako dozvoljava da se do Hl stigne preko AP2. U grupi standarda 802.1 lf razvija
se protokol za komunikaciju meu pristupnim takama koji se bavi ovim i slinim pitanjima.

6.3.5 802.15 i Bluetooth
Kao to se vidi na slici 6.2, Wi-Fi standard IEEE 802.11 namenjen je komunikaciji meu
ureajima udaljenim do 100 metara dok pristup mrei preko mobilne telefonije ima domet na
desetine kilometara. Pre nego to se upustimo u detalje ovih beinih mrea sa veim
udaljenostima, pogledajmo ukratko standard 802.15 WPAN (Wireless Personal Area Network)
koji je u familiji IEEE 802 srodan sa 802.11, a namenjen je povezivanju meu linim ureajima
na rastojanju od priblino 10 metara. 802.15 je u sutini tehnologija male snage, kratkog dometa
i malih brzina, zamena za kabl" za meusobno povezivanje notbuka, perifernih ureaja,
mobilnih telefona i PDA-a dok je 802.11 pristupna" tehnologija vee snage, srednjeg dometa i
vee brzine.
Mrea IEEE 802.15 funkcionie na kratkom rastojanju, manjom snagom i manje kota.
Slojevi veze i fiziki sloj se kod 802.15 zasnivaju na prethodnoj specifikaciji Bluetooth za line
mree [Held 2001, Bisdikian 2001]. Mree 802.15 funkcioniu u radio opsegu 2,4 GHz za koji
nisu potrebne licence, u vremenskom multipleksu i sa vremenskim odsecima od 624 mikro
sekunde. U svakom vremenskom odseku poiljalac emituje najednom od 79 kanala tako to se
kanal menja na poznat, ali pseudo sluajan nain od odseka do odseka. Taj oblik preskakanja
kanala, poznat kao FHSS (Frequency Hopping Spread Spectrum) emituje sa podelom vremena
po frekventnom spektru. 802.15 omoguuje brzine podataka do 721 Kb/s.
Mree 802.15 su ad hoc mree: za povezivanje ureaja 802.15 nije potrebna nikakva
mrena infrastruktura (npr. pristupna taka). Prema tome, ureaji 802.15 moraju sami da se
organizuju. Ureaji 802.15 prvo se organizuju u piko mree od najvie osam aktivnih ureaja
kao stoje prikazano na slici 6.14. Jedan od ovih ureaja postaje glavni, a ostali ureaji su mu
podreeni. Glavni vor zaista upravlja piko mreom - njegov sat odreuje vreme u piko mrei,
on moe da emituje u svakom neparnom odseku dok podreeni moe da emituje samo poto je
glavni vor sa njim komunicirao u prethodnom odseku, pa ak i tada on moe da emituje samo
prema glavnom voru. Pored podreenih ureaja u mrei moe biti i maksimalno 255 parkiranih
ureaja. Ovi ureaji ne mogu da komuniciraju dok im glavni vor ne promeni status iz
parkiranog u aktivni.
itaoci koje zanima WAPN i njegov 802.15 nai e vie informacija u referencama za
Bluetooth [Held 2001, Bisdikian 2001] ili na zvaninoj veb lokaciji IEEE 802.15 [IEEE 802.15
2004].
6.4 Celularni pristup Internetu
U prethodnom odeljku ispitali smo kako raunar moe da pristupi Internetu kada se nae unutar
Wi-Fi lokacije za aktiviranje tj. kada se nalazi u blizini pristupne take 802.11. Ali, veina Wi-Fi
lokacija za aktiviranje ima mali domet, izmeu 10 i 100 metara u preniku. ta da radimo kada
imamo oajniku potrebu za beinim pristupom Internetu, a nije nam dostupna Wi-Fi lokacija
za aktiviranje? S obzirom na to daje mobilna telefonija sada sveprisutna na mnogim podrujima
u elom svetu, prirodna strategija bi bila da se celularne mree proire tako da podre ne samo
govornu telefoniju ve i beini pristup Internetu. Idealno bi bilo da taj pristup Internetu bude
relativno brz i da obezbedi nesmetanu mobilnost tako da korisnici ne prekidaju TCP konekcije za
vreme putovanja, na primer, autobusom ili vozom. Pod uslovom da uzvodne i nizvodne brzine
budu dovoljne, korisnik bi ak mogao da odri video konferencijsku sesiju dok se kree. Taj
scenario nije posebno nerealan. Dok ovo piem (prolee 2004) mnogi operateri mobilne
telefonije nude pretplatnicima celularni pristup Internetu za manje od 100 dolara meseno sa
uobiajenim uzvodnim i nizvodnim brzinama od nekoliko stotina kilobita u sekundi.
U ovom odeljku dajemo kratak pregled tehnologija za pristup Internetu koje trenutno
postoje ili se upravo pojavljuju. Fokus e nam biti na beinom prvom skoku izmeu mobilnog
telefona i oiene infrastrukture telefonske mree; u odeljku 6.7 razmotriemo kako se pozivi
rutiraju korisniku koji se kree izmeu baznih stanica. Ovako kratak opis moe sadrati samo
uproeni okvirni opis celularnih tehnologija. Modeme celularne komunikacije, naravno, mnogo
su sloenije, pa mnogi uni-

.277 POGLAVLJE 6 BEINE I MOBILNE MREE

6-4 CELULARNI PRISTUP INTERNETU 531
KRATAK OSVRT
POREENJE BEINIH LAN-OVA SA CELULARNIM MOBILNIM
TELEFONIMA 3G
Mnogi operateri mobilne telefonije uvode celularne mobilne 3G sisteme sa unutranjim
brzinama od 2 Mb/s, a spoljnirn od 384 kb/s. 3G sistemi se uvode u opsezima radio
frekvencija gde su potrebne licence tako da neki operateri plaaju vladama ak 2 hiljade dolara
po pretplatniku za licence. 3G sistemi e korisnicima omoguiti pristup Internelu sa udaljenih
spoljnih lokacija dok su u pokrelu na nain slian dananjem pristupu mobilnih telefona. Na
primer, tehnologija 3G dozvolie korisniku da pristupi informacijama o putnim kartama dok vozi
kola ili informacijama o repertoaru bioskopa dok se suna na plai. Ipak, mnogi eksperli se
danas pitaju da li e tehnologija 3G biti uspena s obzirom na trokove i na konkurenciju
tehnologije beinog LAN-a [VVeinstein 2002]. Posebno, ovi eksperti tvrde:
Nova infrastruktura beinih LAN-ova poslaje skoro sveprisutna. Kao io je napomenuto u
prethodnom kratkom osvrtu, sve vie ima beinih LAN-ova IEEE 802.1 1 koji funkcioniu
brzinom od 1 1 Mb/s, pa i viom (javni Wi-Fi pristup). Uskoro e skoro svi prenosivi
raunan i PDA-ovi imali fabriki ugraene LAN kartice 802.11. tavie, novi ureaji za
Internet - kao to su beine kamere i elektronski beini ramovi za slike - takoe e
koristiti male kartice za beini LAN slabe snage.
Veina beinog saobraaja podataka polazie ili e se zavravati u lokalnim okruenjima.
Pod pretpostavkom da se beini saobraaj koji polazi iz trnih centara, poslovnih zgrada
itd. ili se zavrava u njima prenosi jeftinim beinim LAN-ovima, za skupe sisteme 3G
ostae relativno mala koliina saobraaja.
Bazne stanice beinog LAN-a mogle bi da opslue i ureaje mobilnih telefona. To bi
omoguilo jeftin pristup podataka za celularne mobilne ureaje kao i za ureaje za beini
LAN, Prema tome, mobilni telefon koji nema karticu za beini LAN, ali se nalazi u
lokalnom okruenju moi e da zaobie 3G sisteme za pristup Internetu.
Naravno, mnogi drugi eksperti veruju da e tehnologija 3G biti ne samo veoma uspena, ve
da e takoe dramatino promeniti nain naeg rada i ivota. Naravno, i Wi-Fi i 3G bi mogle da
postanu preovlaujue beine tehnologije, pa bi beini ureaji u romingu automatski birali
pristupnu tehnologiju koja na trenutnoj fizikoj lokaciji prua najbolju uslugu (proitajte u ovom
odeljku opis beinog pristupa 4G).
verziteti nude vie predmeta na tu temu. itaoci koji ele dublje poznavanje upuuju se na
[Goodman 1997; Scourias 1997; Korhonen 2003; Kaaranen 2001; Lin 2001] kao t na posebno
dobru i iscrpnu referencu [Mouly 1992].
6-4.1 Opti pregled celularne arhitekture
Izraz celularni odnosi se na injenicu da se geografsko podruje deli na odreen broj
geografskih podruja pokrivanja, koje nazivamo elijama, kao to je prikazano na levoj strani
slike 6.1S. Svaka elija sadri jednu baznu stanicu koja emituje signale i prima signale od
mobilnih stanica u svojoj eliji. Podruje pokrivanja jedne elije zavisi od mnogih faktora
ukljuujui emisionu snagu bazne stanice, emisionu snagu mobilne stanice, od graevina koje
zaklanjaju prostor u eliji i visinu antene bazne stanice. Mada na slici 6.15 svaka elija sadri
jednu baznu stanicu koja se nalazi na sredini elije, mnogi dananji sistemi postavljaju bazne
slanice na uglove gde se seku tri elije tako da jedna bazna stanica sa usmerenim antenama moe
da opslui tri elije.

Osnovna mrena arhitektura
Kao to se vidi na slici 6.15, svaka bazna stanica povezana je sa regionalnom mreom - kao to
je javna telefonska mrea - ili direktno sa Internetom preko oiene

d.4 - CELULARNI PRISTUP INTERNETU
533! 533! 533! 533!
i
infrastrukture. Konkretno, na slici 6.15 vidi se daje svaka bazna stanica povezana sa mobilnim
komutacionim centrom MSC (Mobile Switching Center) koji upravlja uspostavljanjem i
raskidanjem poziva mobilnih korisnika. MSC sadri dobar deo funkcionalnosti koji postoji u
obinom telefonskom komutacionom centru (kakav je PBX ili centrala), ali ima dodatnu
funkcionalnost potrebnu za rad sa mobilnim korisnicima.

Pristupne tehnike vazdunog interfejsa
Uobiajena je situacija da se u datoj eliji istovremeno obavlja vie poziva. Ovi pozivi moraju da
dele raspon radio spektra koji je dodeljen posredniku za celularne usluge. Veina celularnih
sistema danas koristi jedan od dva opta pristupa za delje-nje radio spektra:
Kombinaciju frekventnog (FDM) i vremenskog (TDM) muitipleksiranja. Verovatno se seate
iz poglavlja 1 da se kod frekventnog muitipleksiranja kanal deli na odreen broj frekventnih
opsega tako da se svaki opseg namenjuje jednom pozivu. Takoe smo u poglavlju 1 videli da
se kod istog vremenskog muitipleksiranja vreme deli na okvire i da se svaki okvir dalje deli
na odseke, pa svaki poziv dobija na korienje odreeni odseak u pokretnom okviru. U
sistemima sa kombinacijom FDM/TDM kanal se deli na niz frekventnih podopsega; u sva-
kom podopsegu se vreme deli na okvire i odseke. Prema tome, u sistemu sa kombinacijom
FDM/TDM, ako je kanal podeljen na F podokvira, a vreme na T odseaka, tada e kanal biti
u stanju da podri F T istovremenih poziva.
Viestruki poziv sa kodnom podelom (CDMA). Sigurno se seate iz odeljka 6.2.1 da CDMA
ne deli ni frekvencije niti vreme. Umesto toga, svi korisnici dele istu radio frekvenciju u isto
vreme. Svaki korisnik u eliji dobija zaseban niz bitova koji nazivamo niz za seckanje. Kao
to smo videli u odeljku 6.2.1, kada poiljalac i primalac koriste isti niz za seckanje, primalac
moe iz istovremenih slanja svih poiljalaca da rekonstruie ono to je poslao njegov
poiljalac. Glavna prednost sistema CDMA je u tome to elimiuie potrebu da se dodeljuju
frekvencije. Kada se koristi FDM/TDM, na primaoce utie interferencija od drugih signala u
istom frekventnom opsegu. Prema tome, u sistemu FDM/TDM se dala frekvencija moe
ponovo koristiti samo u elijama koje su prostorno dovoljno udaljene tako da ne bude
interferencije. Prilikom projektovanja CDMA sistema takvo ponovno korienje frekvencija
ne predstavlja znaajno pitanje.
6.4.2 Celularni standardi i tehnologije: kratak pregled
Kada ljudi govore o celuiamim tehnologijama, obino ih klasifikuju na nekoliko generacija".
Starije generacije su bile projektovane pre svega za govorni saobraaj; noviji celularni sistemi
osim govora podravaju i pristup Internetu. Postoje ovo
knjiga o umreavanju raunara, a ne o govornoj telefoniji, nas, naravno, vie zanimaju novije
generacije celularnih sistema. Ali, poto su novije generacije direktno nastale od starijih, ipak
poinjemo pregled kratkim opisom beinih sistema prve i druge generacije.
Pri opisivanju ovih generacija naii ete na niz izraza koji se koriste u razliitim
tehnologijama. Kao italac, nemate obavezu da potpuno prihvatite i zapamtite sve ove izraze i
skraenice. Svrha ovog pregleda jeste da vam prui uvid u postojanje razliitih generacija
beinih sistema i da poslui kao brzi podsetnik za razliite izraze i skraenice.
Sistemi prve generacije (IG) su bili analogni FDMAsistemi projektovam samo za govorne
komunikacije. Ovi sistemi su sada skoro nestali, a zamenili su ih digitalni sistemi 2G.

Druga generacija (2G)
Sistemi druge generacije, iako su digitalni takoe suprojektovani za govornu komunikaciju. Ali,
poto su dananji sistemi 2,5G i 3G, projektovani da podre i prenos podataka, nastali od sistema
2G, vano je rei nekoliko rei o sistemima 2G. Mobilni telefon 2G konvertuje analogni govorni
signal u digitalni format pre nego to ga modulira i zatim poalje u etar. Digitalna tehnologija 2G
ima mnoge prednosti nad analognom tehnologijom IG a to su poveani kapacitet usluga unutar
elije, imapreena bezbednost od zloupotreba i naprednije usluge kao to su identifikacija
pozivaoca i poruke. Veina dananjih mobilnih operatera koristi tehnologiju 2G. U irokoj
upotrebi su razliiti 2G standardi i tehnologije:
IS-136 (lnterim Standard 135) TDMA. Ovo je kombinovani FDM/TDM sistem koji potie iz
FDMA tehnologije 1G. On je u irokoj upotrebi u Sevemoj Americi.
GSM {Global Svstem for Mobile Communications). Tokom '80-tih godina Evropljani su
uvideli potrebu za digitalnim sistemom koji e vaiti svuda u Evropi i zameiiiti njihove
nekompatibilne sisteme IG i omoguiti neprimetnu mobilnost medu zemljama kao i
mogunosti i usluge koje nisu mogue u analognim sistemima. Ova potreba dovela je do
standarda GSM za celularne komunikacije. Evropljani su veoma uspeno uveli GSM
tehnologiju poetkom '90-tih. GSM se zatim proirio na Aziju i Sevemu Ameriku, i sada
predstavlja standard za celu-lamu komunikaciju sa najirom primenom. GSM standard za
celularne sisteme 2G za vazduni interfejs koristi kombinovani FDM/TDM. GSM sistemi se
sastoje od opsega frekvencija od po 200 kHz gde svaki opseg podrava 8 TDM poziva. GSM
kodira govor na 13 kb/s i 12,2 kb/s.
IS-95 CDMA. Za razliku od sistema IS-136 i GSM, koji koriste FDM/TDM, sistem IS-95
CDMA koristi viestruki pristup sa kodnom podelom (odeljak 6.2.1). Kompanija Qualcom
demonstrirala je izvodljivost sistema CDMA za


6-4 CELULARNI PRISTUP INTERNETU 535 535 535 535
mobilnu telefoniju krajem 'SO-tih godina; od lad je uvedeno vie sistema IS-95, pogotovo u
Sevemoj Americi i Koreji.

Prelaz sa druge generacije na treu (2,5G)
2G sistemi kao to su IS-95, GSM i IS-136 optimizirani su za govorne usluge i nisu pogodni za
prenos podataka. Tokom '90-tih organizacije za standarde utvrdile su da postoji potreba za
celularnu tehnologiju 3G koja bi bila pogodna i za govor i za prenos podataka (ukljuujui
pristup Internetu). Meutim, poto uvoenje tehnologije 3G traje godinama, kompanije su
razvile privremene protokole i standarde koji omoguavaju prenos podataka preko postojee
infrastrukture 2G. Takvi sistemi nose zajedniko ime celularni sistemi 2,5G". Navodimo neke
od njih:
GPRS (General Packet Radio Service) je razvijen iz GSM-a. Za rad sa podacima, GSM igra
ulogu modema izmeu korisnikog ureaja i odredine mree podataka-tj, GSM koristi
komutiranje vodova kako za podatke tako i za govorni saobraaj. Kao to smo nauili u
poglavlju 1 komutiranje vodova je krajnje neefikasno za povremeni prenos podataka. tavie,
standard GSM podrava brzine prenosa do 9,6 kb/s to je nedopustivo sporo za bilo ta osim
za isti tekst. GPRS predstavlja privremeno reenje koje omoguava efikasnije usluge za
podatke sa paketima pri veim brzinama (obino u rasponu od 40 do 60 kb/s). GPRS usluga
prua se na osnovu postojee GSM mree. Meutim, za razliku od istog GSM-a, mobilna
GPRS stanica moe na zahtev da koristi vie vremenskih odseaka u datom kanalu. Kada se
koristi GPRS, odreen broj odseaka se rezervie za prenos podataka i dinamiki se
dodeljuje mobilnim stanicama zavisno od njihove trenutne potranje.
EDGE (EnhancedData Rates for Global Evolution). Glavni cilj sistema EDGE jeste da se
poveaju mogue brzine u mrei GSM/GPRS, tj. da se bolje iskoristi GSM kanal od 200
KHz sa okvirima od po 8 TDMA odseaka. To se postie pre svega zamenom modulacione
eme GSM-a jednom snanijom emom. Teoretski, EDGE moe korisnicima da obezbedi
384 kb/s za prenos podataka. Izvrstan pregled sistema EDGE moete nai u knjizi [Ericsson
2004].
CDMA2000,faza 1. Ova tehnologija 2,5G nastala je od IS-95. Ona moe da obezbedi usluge
za pakete podataka do 144,4 kb/s i priprema teren za uvoenje 3G sistema CDMA2000, faza
2.
Trea generacija (3G) '
Celularni sistemi tree generacije potrebni su za pruanje telefonske usluge, kao i za prenos
podataka pri osetno veim brzinama od odgovarajuih sistema druge generacije. Od sistema
tree generacije se pre svega oekuje da omogue:
144 kb/s za korisnike u vonji;
384 kb/s za upotrebu van zgrade u mirovanju ili pri brzini hoda;
2 Mb/s za upotrebu u zgradi.
U podruju tree generacije postoje dva glavna standarda koja se trenutno bore za prevlast:
UMTS (Vniversal Mobile Tehcommunications Service) je proireni GSM sa podrkom za
mogunosti tree generacije. Arhitektura UMTS mree veim delom nasleuje ve
uspostavljenu arhitekturu GSM mree. Meutim, radio pristup UMTS-a znaajno se razlikuje
od eme FDMA/TDMA koja se koristi za GSM. Konkretno, UMTS koristi CDMA tehniku
poznatu pod imenom DS-WCDMA (Direct Sequence Wideband CDMA). UMTS se upravo
uvodi u velikom delu Evrope to ne iznenauje s obzirom na to da UMTS potie od GSM-a.
CDMA-2000 je razvijen od 2G sistema IS-95 i kompatibilan je unazad sa sistemom IS-95.
Kako bi se i oekivalo na osnovu imena, on u svom vazdunom interfejsu takoe koristi
CDMA. CDMA-2000 se uvodi u Sevemoj Americi i u delovima Azije.
etvrta generacija (4G)
Poto smo razmotrili i tehnologiju beinog LAN-a i niz tehnologija za celularni prisnip,
vratimo se malo i razmotrimo ta bismo mi kao korisnici u idealnoj situaciji oekivali od
beinog pristupa Internetu. Ovde je lista elja:
eleli bismo sveprisutni beini pristup Internetu. Hteli bismo da se omogui pristup Internetu
bez obzira na to da li smo kod kue, u kancelariji, u kolima, u kafiu ili na plai.
Zavisno od nae fizike lokacije i brzine kojom se kreemo, eleli bismo najbri mogui
pristup Internetu. Na primer, ako se nalazimo na u/ici gde je dostupan 802.11b od 11 Mb/s i
3G pristup od 384 kb/s eleli bismo da na sistem automatski izabere 802.11b, tj. onaj sistem
koji u to vreme i na tom mestu nudi najveu brzinu.
Dok se kreemo kroz ovo heterogeno okruenje automatski i transparentno se prebacujemo
iz jedne tehnologije pristupa u drugu (na primer, iz 802.11 u 3G) zavisno od dostupnosti, bez
ikakve intervencije korisnika.
Naravno, elimo tokom naeg kretanja da zadrimo aktivne TCP konekcije. tavie, hteli
bismo da sistem zna gde se mi nalazimo da bismo primili nove po2ive i kad smo u pokreru.

280 280 280 280
6.5 UPRAVUANJE MOBILNOU: PRINCIPI
53? 53? 53? 53?

eleli bismo da sistem podrava govor i video u realnom vremenu preko IP-a, da bismo svi
mogli da nosimo pijunske satove i vodimo video konferencije sa svojim prijateljima i
kolegama bez obzira na to gde se nalazimo.
A naravno, eleli bismo da sve to bude besplatno (ili barem da ne bude skupo). Mada ovo moe
da zvui kao beina nirvana, dobra vest glasi da veina potrebnih tehnolokih komponenti ve
postoji. Sada je jedino pitanje kako da se naprave protokoli i tehnologije koje e ih povezati da bi
se ova lista elja ostvarila. U te komponente spadaju tehnologije pristupa kao to su 802.11 i 3G
kao i protokoli za upravljanje mobilnou (odeljci 6.5, 6.6 i 6.7), protokoli za kodrovanje i
proveru autentinosti (poglavlje 8) i multimedijski mreni protokoli (kao stoje SIP za prenos
govora preko IP-a, koji se opisuje u poglavlju 7).

6.5 Upravljanje mobilnou: principi
Poto smo sada opisali beinu prirodu komunikacionih linkova u beinoj mrei, vreme je da
obratimo panju na mobilnost koju ti beini linkovi omoguavaju. U najirem smislu, mobilni
vor je onaj koji u vremenu menja svoju taku prikljuenja na mreu. Poto izraz mobilnost ima
razliita znaenja u svetu raunara i u svetu telefonije, prvo emo donekle detaljno razmotriti
nekoliko dimenzija mobilnosti.
Koliko je korisnik mobilan iz aspekta mrenog sloja? Fiziki mobilan korisnik postavlja pred
mreni sloj veoma razliite probleme zavisno od naina na koji menja prikljunu taku sa
mreom. Najednom kraju spektra sa slike 6.16 korisnik moe da nosi laptop sa karticom
beinog mrenog interfejsa po nekoj zgradi. Kao to smo videli u odeljku 6.3.4 ovaj korisnik
iz perspektive mrenog sloja nije mobilan. tavie, ako se korisnik pridruuje istoj pristupnoj
taki bez obzira na to gde se nalazi on ak nije mobilan ni iz perspektive sloja veze.
Na drugom kraju spektra zamislite korisnika koji juri auto putem u BMW-u brzinom od 150
km/h, koji prolazi kroz mnoge beine prikljune mree i eli da zadri TCP konekciju sa
udaljenom aplikacijom tokom celog putovanja. Ovaj korisnik svakako jeste mobilan! Izmeu
ta dva ekstrema imamo korisnika koji uzme svoj laptop sa jednog mesta (npr. kancelarije ili
spavaonice) i prenese ga na drugo (npr. u kafi ili uionicu) i hoe da se povee sa mreom
na tom novom mestu. Ovaj korisnik je takoe mobilan (mada manje od vozaa BMW-al), ali
mu nije potrebno da zadri postojeu konekciju tokom premetanja izmeu mrenih
pristupnih taaka. Na slici 6.16 prikazan je ovaj spektar korisnike mobilnosti iz aspekta
mrenog sloja.
Koliko je vano da adresa mobilnog vora ostane uvek ista? U mobilnoj tele-foniji, va broj
telefona - u sutini to je adresa vaeg telefona u mrenom sloju - ostaje uvek isti kada se
kreete iz mree jednog operatera mobilne telefonije u mreu drugog operatera. Da li laptop
mora na slian nain da zadri istu IP adresu kada se kree meu IP mreama?
Odgovor na ovo pitanje umnogome zavisi od aplikacija koje se izvravaju. Za vozaa
BMW-a koji eli da zadri TCP konekciju sa udaljenom aplikacijom dok juri auto putem bilo
bi zgodno da zadri istu IP adresu. Verovatno se seate iz poglavlja 3 da internetska
aplikacija mora da zna IP adresu i broj porta na udaljenom ureaju sa kojim komunicira. Ako
je mobilni ureaj u stanju da zadri istu IP adresu dok se kree, njegova mobilnost iz aspekta
aplikacije ostaje neprime-tna. Ova transparentnost ima veliki znaaj - aplikacija ne mora da
brine o eventualno promenljivoj IP adresi, pa isti aplikacijski kod slui za mobilne konekcije
i za one koje to nisu. U sledeem odeljku videemo da mobilni IP obezbeduje tu
transparentnost, dozvoljavajui mobilnom voru da zadri svoju trajnu IP adresu dok se
kree po mreama.
S druge strane, skromniji mobilni korisnik e moda samo hteti da iskljui laptop u
kancelariji, donese ga kui, ukljui ga i nastavi da radi od kue. Ako laptop od kue
funkcionie pre svega kao klijent u klijent-server aplikacijama (npr. slanje i primanje
e-pote, pretraivanje Weba, Telnet prema udaljenom raunaru), konkretna IP adresa koju
koristi nije toliko vana. Pogotovo, dobro e posluiti i adresa koju laptopu privremeno
dodeljuje posrednik za Internet usluge iji nalog koristite kod kue, U odeljku 5.4.3 videli
smo da DHCP ve omoguava ovu funkciju.
Koja je oiena infrastruktura dostupna za podrku? U svim gore opisanim scenarijima,
implicitno smo pretpostavili da postoji fiksna infrastruktura sa kojom mobilni korisnik moe
da se povee, na primer, kuna mrea posrednika Internet usluga, beina prikljuna mrea u
kancelariji ili beina prikljuna mrea du celog autoputa. A ta ako takve infrastrukture
nema? Ako se dva korisnika nalaze dovoljno blizu, da li mogu da uspostave mrenu vezu i
bez ikakve druge infrastrukture mrenog sloja? Ad hoc umreavanje prua upravo tu
mogunost. Ovo podruje koje se ubrzano razvija predstavlja vrhunac istraivanja mobil-


6.5 . UPRAVUANJE MOBILNOU: PRINCIPI 539
nog umreavanja i prelazi okvire ove knjige. [Perkins 2000] i veb stranice IETF radne grupe
Mobile Ad Hoc Network [manet 2004] sadre sveobuhvatnu obradu ove teme.
Da bismo ilustrovali probleme koje postavlja zahtev da mobilni korisnik zadri postojee
konekcije dok se kree meu mreama, razmotrimo jednu analogiju iz svakodnevnog ivota.
Mlada osoba koja napusti roditeljsku kuu postaje mobilna, stanuje u raznim spavaonicama ili
stanovima i esto menja adrese. Ako stari prijatelj hoe da ga pronae, kako e da utvrdi adresu
svog mobilnog prijatelja? Uobiajeni nainje da se potrai porodica, poto mobilni mladi esto
prijavljuje svoju trenutnu adresu (ako ni zbog ega drugog onda zato da bi roditelji mogli da mu
poalju novac ako mu nedostaje za stanarinu!). Porodina kua sa svojom trajnom adresom
postaje mesto koje e drugi ljudi prvo potraiti kako bi stupili u kontakt sa mobilnim mladiem.
Nakon toga, komunikacija sa prijateljem moe biti indirektna (na primer, da se pota alje
roditeljima koji je zatim prosleuju mobilnom mladiu) ili direktna (na primer, kada prijatelj
upotrebi dobijenu adresu i alje potu direktno mobilnom prijatelju).
U mrenom okruenju, trajna kua" mobilnog vora (kao stoje laptop ili PDA) naziva se
matinom mreom, a entitet u matinoj mrei koji upravlja funkcijama mobilnosti u ime
mobilnog vora naziva se matini agent. Mrea u kojoj se mobilni vor trenutno nalazi naziva se
strana (ili poseena) mrea, a entitet u stranoj mrei koji pomae mobilnom voru u funkcijama
upravljanja mobiinou naziva se strani agent. Za mobilne profesionalce, matina mrea je
verovatno mrea njihove kompanije, a poseena mrea moe biti mrea nekog kolege kod kojeg
se nalaze. Kore-spondent je entitet koji eli da komunicira sa mobilnim vorom. Slika 6.17
ilustruje ovaj koncept, kao i koncept adresiranja koji e biti izloen u nastavku. Na slici 6.17
moe se primetiti da se agenti nalaze na istom mestu gde i ruteri (na primer, kao procesi koji se
izvravaju u ruterima), ali se oni mogu izvravati i na drugim raunarima ili serverima u mrei.

6.5.1 Adresiranje.
Ve smo napomenuli daje poeljno da mobilni vor zadri istu adresu prilikom premetanja iz
mree u mreu zato da bi njegova mobilnost bila transparentna za mrene aplikacije. Kada se
mobilni vor nalazi u stranoj mrei, sav saobraaj adresiran na njegovu trajnu adresu mora da se
rutira u stranu mreu. Kako se to postie? Jedna mogunost je da strana mrea objavi svim
ostalim mreama da se mobilni vor nalazi kod nje. To bi moglo da se postigne putem
uobiajene razmene informacija o rutiranju unutar domena i meu domenima, i zahtevalo bi
samo male izmene u postojeoj infrastrukturi rutiranja. Strana mrea bi jednostavno objavila
svojim susedima da poseduje veoma specifinu rum prema trajnoj adresi mobilnog vora (tj. u
sutini bi obavestila ostale mree da poseduje tanu putanju za rutiranje
datagrama prema trajnoj adresi mobilnog vora; proitajte odeljak 4.4). Ti susedi bi zatim
propagirali ovu informaciju po celoj mrei u sklopu normalne procedure za auriranje
informacija o rutiranju i tabela prosleivanja. Kada mobilni vor napusti jednu stranu mreu i
pree u drugu, nova strana mrea e objaviti novu, sasvim konkretnu rutu prema mobilnom
voru, a stara strana mrea e povui informacije o rutiranju koje se odnose na mobilni vor.
Na ovaj nain se istovremeno reavaju dva problema i to bez znaajnih izmena
infrastrukture mrenog sloja. Druge mree znaju za lokaciju mobilnog vora i datagrami se lako
rutiraju prema njemu poto e tabele prosleivanja usmeriti datagram u stranu mreu. Meutim,
tu postoji znaajan nedostatak skalabilnosti. Kada bi upravljanje mobiinou postalo zadatak
mrenih rutera, oni bi moda morali u tabeli prosleivanja da odravaju stavke za milione
mobilnih vorova i da ih auriraju u skladu sa kretanjem vorova. U problemima na kraju ovog
poglavlja istrauju se jo neki nedostaci.

6.5 . UPRAVLJANJE MOBILNOU: PRINCIPI 541 541 541 541
282 282 282 282 POGLAVLJE 6 BEINE l MOBILNE MREE

Drugi pristup (pristup koji je prihvaen u praksi) jeste da se funkcije mobilnosti prenesu iz
jezgra mree na njenu periferiju - tema na koju stalno nailazimo u prouavanju arhitekture
Interneta. Prirodno je da se to uradi preko matine mree mobilnog vora. Na slian nain kao
to roditelji mobilnog tinejdera prate njegovu lokaciju, matini agent u matinoj mrei
mobilnog vora moe da prati stranu mreu u kojoj se mobilni vor nalazi. Da bi se aurirala
prava lokacija mobilnog vora svakako e biti potreban i protokol izmeu mobilnog vora (ili
stranog agenta koji ga predstavlja) i njegovog matinog agenta.
Razmotrimo sada malo detaljnije stranog agenta. Prema najjednostavnijoj zamisli prikazanoj
na slici 6.17, strani agenti se stavljaju u periferne rutere strane mree. Jedna od uloga stranog
agenta je da napravi takozvanu privremenu adresu (care-of address, COA) za mobilni vor u
kojoj mreni deo adrese odgovara stranoj mrei. Na taj nain su mobilnom voru pridruene dve
adrese, njegova trajna adresa (analogna roditeljskoj adresi mobilnog tinejdera) i njegova COA
koju ponekad nazivamo stranom adresom (analogno adresi kue u kojoj mobilni tinejder
trenutno stanuje). U primeru sa slike 6.17, trajna adresa mobilnog vora je 128.119.40.186. Dok
se nalazi u poseti mrei 79.129.13/24, mobilni vor ima adresu COA 79.129.13.2. Druga uloga
stranog agenta je da obavesti matinog agenta da se mobilni vor nalazi u njegovoj (stranoj)
mrei i daje dobio adresu COA. Uskoro emo videti da se COA koristi za prerutiranje"
datagrama mobilnom voru preko njegovog stranog agenta.
Mada smo razdvojili funkcije mobilnog vora i stranog agenta, treba napomenuti da zadatke
stranog agenta moe da preuzme i sam mobilni vor. Na primer, mobilni vor bi mogao da
pribavi adresu COA u stranoj mrei (na primer, pomou protokola kakav je DHCP) i sam
obavesti matinog agenta o toj privremenoj adresi.

6.5.2 Rutiranje prema mobilnom voru
Sada smo videli kako mobilni vor dobija adresu COA i kako se matini agent obavetava o toj
adresi. Ali, to to matini agent zna za adresu COA reava samo deo problema. Kako adresirati
datagrame i kako ih proslediti mobilnom voru? Poto za lokaciju mobilnog vora zna samo
matini agent (a ne i ruteri svuda u mrei) nee vie biti dovoljno da se datagram jednostavno
adresira na trajnu adresu mobilnog vora i poalje u infrastrukturu mrenog sloja. Potrebno je
uraditi neto vie. Mogua su dva pristupa koja emo nazvati indirektnim i direktnim rutiranjem.

Indirektno rutiranje prema mobilnom voru
Razmotrimo prvo korespondenta koji eli da poalje datagram mobilnom voru, Ako se koristi
indirektno rutiranje, korespondent jednostavno adresira datagram na trajnu adresu mobilnog
vora i alje datagram u mreu, u blaenom neznanju da
li se mobilni vor nalazi u svojoj matinoj mrei ili u poseti stranoj mrei; mobilnost ostaje za
korespondenta potpuno transparentna. Takvi datagrami se prvo rutiraju kao i obino u matinu
mreu mobilnog vora. Ovo je prikazano kao korak 1 na slici 6.18.
Obratimo sada panju na matinog agenta. Osim to je zaduen za interakciju sa stranim
agentom kako bi pratio adresu COA mobilnog vora, matini agent ima jo jednu veoma vanu
funkciju. Njegov drugi zadatak je da eka datagrame adresirane na vorove ija matina mrea
jeste mrea matinog agenta, ali se trenutno nalaze u stranoj mrei. Matini agent presree te
datagrame i zatim ih prosleuje mobilnom voru u postupku od dva koraka. Datagram se prvo
prosleuje stranom agentu pomou adrese COA mobilnog vora (korak 2 na slici 6.18), a zatim
se prosleuje od stranog agenta ka mobilnom voru (korak 3 na slici 6.18).

542 POGLAVLJE o BEINE I MOBILNE MREE
6.5 UPRAVLJANJE MOBILNOU: PRINCIPI 283

Prouimo detaljnije ovo prerutiranje. Da bi mreni sloj rutirao datagram u stranu mreu, matini
agent mora da adresira datagram pomou adrese COA mobilnog vora. S druge strane, poeljno
je da datagram korespondenta ostane netaknut poto aplikacija koja prima datagram ne srne da
primeti daje datagram prosleden preko matinog agenta. Oba ova zahteva mogu da se zadovolje
ako matini agent enkapsulira kompletan prvobitni datagram dobijen od korespondenta u jedan
novi (vei) datagram. Ovaj vei datagram se adresira i isporuuje na adresu COA mobilnog
vora. Strani agent, vlasnik" adrese COA, e primiti i dekapsulirati datagram, tj. izdvojiti
prvobitni datagram korespondenta iz veeg enkapsulirajueg datagrama i zatim proslediti (korak
3 na slici 6.18) prvobitni datagram mobilnom voru. Na slici 6.19 prikazanje prvobitni datagram
korespondenta koji se alje u matinu mreu, enkapsulirani datagram koji se alje stranom agentu
i prvobitni datagram koji se isporuuje mobilnom voru. Pronicljivi italac e primetiti da je
enkapsuliranjc i dekapsuliranje koje ovde opisujemo identino pojmu tunelovanja koji smo u
poglavlju 4 opisivali u kontekstima vieznanog IP upuivanja i protokola IPv6.
Pogledajmo sada kako mobilni vor alje datagrame korespondentu. To je sasvim
jednostavno poto mobilni vor moe svoje datagrame da adresira direktno korespondentu
(koristei vlastitu trajnu adresu kao adresu izvora, a koresponden-tovu adresu kao adresu
odredita). Poto mobilni vor zna adresu korespondenta, nije potrebno da se datagram rutira
preko matinog agenta. Ovo je prikazano kao korak 4 na slici 6.18.
U ovoj rekapitulaciji indirektnog rutiranja dajemo spisak novih funkcija mrenog sloja
potrebnih za podrku mobilnosti.
Protokol izmeu mobilnog vora i stranog agenta. Mobilni vor e se prijaviti kod stranog
agenta prilikom povezivanja u stranu mreu. Slino tome, mobilni vor e se odjaviti kod
stranog agenta kada bude naputao stranu mreu.
Protokol kojim strani agent vri registraciju kod matinog agenta. Strani agent e prijaviti
adresu COA mobilnog vora matinom agentu. Sirani agent ne mora eksplicitno da odjavi
adresu COA kada mobilni vor napusti njegovu mreu poto e to resiti naknadno
prijavljivanje nove adrese COA kada mobilni vor pree u novu mreu.
Protokol kojim matini agent enkapsulira datagram. Za enkapsuliranje i prosleivanje
prvobitnog datagrama korespondenta u datagramu adresiranom na adresu COA.
Protokol kojim strani agent dekapsulira datagram. Za izdvajanje koresponen-tovog
prvobitnog datagrama iz enkapsulirajueg datagrama i za prosleivanje prvobitnog
datagrama mobilnom voru.
Prethodni opis sadri sve delove - strane agente, matinog agenta i indirektno prosleivanje
- potrebne da bi mobilni vor zadrao neprekinutu konekciju dok se kree po raznim mreama.
Kao primer ove saradnje pretpostavimo daje mobilni vor vezan za stranu mreu A, da je
prijavio adresu COA iz mree A svom matinom agentu i da prima datagrame inireklno
rutirane preko njegovog matinog agenta. Mobilni vor sada prelazi u stranu mreu B i
registruje se kod stranog agenta u mrei B koji obavetava matinog agenta o novoj adresi COA
mobilnog vora. Poevi od tog trenutka, matini agent e prerutirati datagrame u stranu mreu
B. to se tie korespondenta, mobilnost je transparentna - i pre i posle premetanja datagrami se
rutiraju preko istog matinog agenta. to se tie matinog agenta, nema prekida u toku
datagrama - pristigli datagrami se prvo prosleuju u stranu mreu A; nakon promene adrese
COA datagrami se prosleuju u stranu mreu B. Ali, da li e mobilni vor primetiti prekid u
toku datagrama kada promeni mreu? Ako je vreme od trenutka kada mobilni vor prekine
konekciju sa mreom A (kada vie ne moe da prima datagrame preko mree A) do trenutka
kada se prikljui na mreu B (kada bude prijavio novu adresu COA svom matinom agentu)
dovoljno kratko, izgubie se mali broj datagrama. Verovatno se seate iz poglavlja 3 da u
konekcijama sa kraja na kraj moe doi do gubitaka datagrama zbog zaguenja mree. Prema
tome,

6.5 UPRAVUANJE MOBILNOU: PRINCIPI
545 545 545 545

povremeni gubitak datagrama u konekciji kada vor prelazi iz mree u mreu nikako ne
predstavlja katastrofalan problem. Ako je potrebna komunikacija bez gubitaka, mehanizmi u
viim slojevima e se pobrinuti za oporavak od gubitaka, bez obzira na to da li je do gubitka
dolo zbog zaguenja mree ili zbog mobilnosti korisnika.
U standardu za mobilni IP [RFC 3220] prihvaen je pristup sa indirektnim ruti-ranjem kao
stoje opisano u odeljku 6.6.

Direktno rutiranje prema mobilnom voru
Pristup sa indirektnim rutiranjem prikazan na slici 6.18 pati od problema neefikasnosti poznatog
pod imenom trougao rutiranja - datagrami adresirani mobilnom voru moraju se prvo rutirati
matinom agentu i zatim stranoj mrei, ak i kada izmeu korespondenta i mobilnog vora
postoji mnogo efikasnija ruta. U najgorem sluaju, zamislite mobilnog korisnika u poseti stranoj
mrei nekog kolege. Njih dvojica sede jedan pored drugog i razmenjuju podatke preko mree.
Datagrami od korespondenta (u ovom sluaju kolege naeg posetioca) rutiraju se matinom
agentu mobilnog korisnika i ponovo nazad u stranu mreu!
Direktno rutiranje etiminie problem trougla rutiranja, ali zato poveava sloenost. U
pristupu sa direktnim rutiranjem, za adresu COA mobilnog vora prvo saznaje agent
korespondenta u mrei korespondenta. To se moe postii tako da agent korespondenta poalje
upit matinom agentu pod pretpostavkom (kao u sluaju indirektnog rutiranja) daje mobilni vor
prijavio aurnu vrednost adrese COA svom matinom agentu. Takoe je mogue da funkciju
agenta korespondenta vri sam korespondent, kao to je mobilni vor mogao da vri funkciju
stranog agenta. Ovo je prikazano kao koraci 1 i 2 na slici 6.20. Agent korespondenta zatim
direktno tuneluje datagrame na adresu COA mobilnog vora slino tunelovanju koje je obavljao
matini agent (koraci 3 i 4 na slici 6.20).
Iako direktno rutiranje reava problem trougla rutiranja, ono dovodi do dodatne sloenosti:
Potreban je poseban protokol za pronalaenje mobilnog korisnika da bi agent
korespondenta od matinog agenta saznao adresu COA mobilnog vora (koraci 1 i 2 na slici
6.20).
Kada mobilni vor prelazi iz jedne strane mree u drugu, kako e se podaci proslediti u novu
stranu mreu? U sluaju indirektnog rutiranja, ovaj problem se jednostavno reavao
auriranjem adrese COA pri matinom agentu. Meutim, kod direktnog rutiranja agent
korespodenta samo jedanput na poetku sesije trai adresu COA od matinog agenta. Prema
tome, auriranje COA kod matinog agenta (mada neophodno) nee biti dovoljno da resi
problem rutiranja podataka prema novoj stranoj mrei mobilnog vora.
Ovde bijedno reenje bilo da se napravi novi protokol za obavetavanje korespondenta o
promenjenoj adresi COA. Drugo reenje koje je primenjeno u praksi u GSM mreama,
funkcionie na sledei nain. Pretpostavimo da se podaci trenutno prosleduju mobilnom voru u
stranoj mrei u kojoj se mobilni vor nalazio na poetku sesije (korak 1 na slici 6.21). Stranog
agenta u stranoj mrei u kojoj se mobilni vor nalazi na poetku nazvaemo sidreni strani
agent. Kada mobilni vor pree u novu stranu mreu (korak 2 na slici 6.21) mobilni vor se
prijavljuje novom stranom agentu (korak 3), a novi strani agent predaje sidrenom stranom agentu
novu adresu COA mobilnog vora (korak 4). Sidreni strani agent koji primi enkapsulirani data-
gram za mobilni vor koji je otiao ponovo e enkapsulirati datagram i proslediti ga na novu
COA (korak 5). Ako mobilni vor kasnije ponovo ode u novu stranu mreu, strani agent nove
poseene mree e tada obavestiti sidrenog stranog agenta da se pripremi prosledivanje u tu
novu stranu mreu.

6.6 MOBILNI IP 285

6.6 Mobilni IP
Arhitektura Interneta i protokoli za podrku mobilnosti koji se zajedno zovu mobilni IP prvo su
definisani u standardu RFC 3220. Mobilni IP je fleksibilan standard, koji podrava mnoge
razliite reime'rada, na primer, rad sa stranim agentom ili bez njega, vie naina za meusobno
otkrivanje agenata i mobilnih vorova, korienje jedne ili vie adresa COA i vie oblika
enkapsuliranja. Kao takav, mobilni IP je sloeni standard i bila bi potrebna cela knjiga da se
detaljno opie; jedna od tih knjiga je [Perkins 1998b]. Na skromni cilj je da ovde opiemo
najvanije aspekte mobilnog IP-a i da prikaemo njegovo korienje u nekoliko uobiajenih
situacija.
Arhitektura mobilnog IP-a sadri mnoge od elemenata koje smo upravo razmatrali
ukljuujui i koncepciju matinih agenata, stranih agenata, privremenih adresa, kao i
enkapsulaciju i dekapsulaciju. Vaei standard [RFC 3220] zahteva indirektno rutiranje prema
mobilnom voru.
Mobilni standard ima tri glavna dela:
Otkrivanje agenta. Mobilni IP defmie protokole kojima matini i strani agent objavljuju svoje
usluge mobilnim vorovima i protokole kojima mobilni vorovi zahtevaju usiuge stranog ili
matinog agenta.
Prijavljivanje matinom agentu. Mobilni IP definie protokole pomou kojih mobilni vor
i/ili strani agent prijavljuje i odjavljuje adresu COA mobilnog vora matinom agentu.
Indirektno rutiranje datagrama. Standard takoe definie nain na koji matini agent
prosleduje datagrame mobilnim vorovima, ukljuujui pravila za prosleivanje datagrama,
pravila za obradu greaka i nekoliko razliitih oblika enkapsuliranja [RFC 2003, RFC 2004].
Pitanja bezbednosti imaju veliki znaaj u elom standardu za mobilni IP. Na primer,
svakako je potrebna provera autentinosti mobilnog vora da bi se zlona-memi korisnik spreio
da prijavi matinom agentu lanu privremenu adresu, pa bi svi datagrami adresirani ha neku IP
adresu bili preusmereni zlonamernom korisniku. Mobilni IP postie bezbednost pomou mnogih
mehanizama koje emo obraditi u poglavlju 8, pa se u naem sledeem tekstu neemo baviti
pitanjima bezbednosti.

Otkrivanje agenta
Mobilni IP vor koji stie u novu mreu, bilo da se prikljuuje stranoj mrei ili se vraa u svoju
matinu mreu, mora da sazna identitet odgovarajueg stranog ili matinog agenta. Zaista,
mreni sloj u mobilnom voru saznaje daje premeten u novu stranu mreu kada otkrije novog
stranog agenta sa novom mrenom adresom. Ovaj postupak se naziva otkrivanje agenta.
Otkrivanje agenta moe se postii na jedan od sledea dva naina: putem objave agenta ili putem
zahteva agentu.
Ako se koristi oglaavanje agenta, strani ili matini agent oglaava svoje usluge pomou
proirenja postojeeg protokola za otkrivanje rutera [RFC 1256]. Agent svim linkovima na koje
je povezan povremeno difuzno emituje ICMP poruku sa vrednou 9 (otkrivanje rutera) u polju
za tip'poruke. Poruka za otkrivanje rutera sadri IP adresu rutera (tj. agenta) i tako omoguava
mobilnom voru da sazna IP adresu agenta. Poruka za otkrivanje rutera takode sadri proirenje
sa objavom mobilnog agenta koje sadri dodatne informacije potrebne mobilnom voru. Znaaj-
nija polja u tom proirenju su:
Bit matinog agenta (H). Oznaava da je re o matinom agentu za mreu u kojoj se nalazi.
Bit stranog agenta (F). Oznaava da je re o stranom agentu za mreu u kojoj se nalazi.
Bit obaveznog registrovanja (R). Oznaava da mobilni korisnik u ovoj mrei mora da se
prijavi stranom agentu. Konkretno, mobilni korisnik ne moe sam da pribavi privremenu
adresu u stranoj mrei (na primer, pomou DHCP-a) i da sam preuzme funkcije stranog
agenta bez prijavljivanja stranom agenm.

286 POGLAVLJE 6 ' BEINE I MOBILNE MREE 6.6 MOBILNI IP 549

M, G bitovi enkapsuliranja. Oznaavaju da li e se koristiti neki vid enkapsulira-nja osim
enkapsuliranj a IP-u-IP.
Polja COA (Care-of addresses). Spisak od jedne ili nekoliko privremenih adresa koje nudi strani
agent. U naem sledeem primeru, COA e biti pridruena stranom agentu koji je zaduen za
primanje datagrama koji se alju na adresu COA i za njihovo prosledivanje odgovarajuem
mobilnom voru. Mobilni korisnik e prilikom prijavljivanja svom matinom agentu izabrati
jednu od ovih adresa za svoju adresu COA.
Na slici 6 22 prikazana su neka od kljunih polja u agentovoj poruci objave.
Ako se koriste zahtevi agentu, mobilni vor koji eli da sazna za agente, a ne da eka dok
primi oglaavanje agenta, moe difuzno da emituje poruku zahteva agentu - to je jednostavno
ICMP poruka sa vrednou 10 u polju tipa. Agent koji primi takav zahtev jednoznano e uputiti
oglaavanje agenta direktno mobilnom voru koji e zatim postupiti kao daje primio oglaavanje
koje nije sam traio.
Prijavljivanje matinom agentu i ii i
Kada mobilni IP vor pribavi adresu COA, ta adresa mora da se prijavi matinom J JJ J
agentu. To moe da uradi strani agent (koji zatim prijavljuje adresu COA matinom j jj j
agentu) ili direktno sam mobilni IP vor. Razmotriemo prvi sluaj koji se sastoji iz j jj j
etiri koraka. i ii i
1. Poto primi oglaavanje stranog agenta, mobilni vor alje stranom agentu !
poruku za prijavljivanje mobilnog IP-a. Poruka prijavljivanja stavlja se u ]
UDP datagram i alje na port 434. Poruka prijavljivanja sadri adresu COA iz \
oglaavanja stranog agenta, adresu matinog agenta (hotne agent, HA), trajnu \
adresu mobilnog vora (MA), zahtevano trajanje prijave i identifikaciju prijave i i i i
od 64 bita. Zahtevano trajanje prijave je broj sekundi koliko prijava treba da j j j j
vai. Ako se u navedenom intervalu prijava ne obnovi kod matinog agenta, \
ona prestaje da vai. Identifikator prijave slui kao redni broj i potreban je za 1
uparivanje odgovora o primljenoj rezervaciji sa zahtevom za rezervaciju, to I I I I
emo kasnije opisati. \
2. Strani agent prima poruku prijavljivanja i evidentira trajnu IP adresu mobilnog |
vora. Strani agent sada zna da treba oekivati datagrame koji sadre enka- \
psulirane datagrame ija je odredina adresa jednaka trajnoj adresi mobilnog
vora. Strani agent tada alje poruku sa mobilnom IP prijavom (opet u UDP J
datagramu) na port 434 matinog agenta. Poruka sadri COA, HA, MA, zahte- j
vani format enkapsuliranj a, zahtevano trajanje prijave i identifikaciju prijave. ;
3. Matini agent prima zahtev za prijavu i proverava autentinost i ispravnost. j j j j
Matini agent povezuje trajnu IP adresu mobilnog vora sa adresom COA; i i i i
ubudue, datagrami koji budu stizali matinom agentu, a namenjeni su mobil- ;
nom voru bie enkapsulirani i tunelovani ka adresi COA. Matini agent alje \
odgovor na mobilnu IP prijavu, a on sadri HA, MA, odobreno trajanje prijave ! i
identifikaciju prijave iz zahteva na koji se ovaj odgovor odnosi.
4. Strani agent prima odgovor na prijavu i prosleuje ga mobilnom voru.
U ovom trenutku prijava je potpuna i mobilni vor moe da prima datagrame upuene na
njegovu trajnu adresu. Ovi su koraci prikazani na slici 6.23. Obratite panju na to da matini
agent odobrava manje trajanje nego to je mobilni vor zahtevao.
Strani agent ne mora eksplicitno da odjavi adresu COA kada mobilni vor napusti njegovu
mreu. To e se postii automatski kada mobilni vor stigne u novu mreu (bilo drugu stranu
mreu ili svoju matinu mreu) i prijavi novu adresu COA.

6.7 UPRAVLJANJE MOBILNOU U CELULARNIM MREAMA 551

Osim ovde opisanih, standard za mobilni IP dozvoljava i mnoge dragaije scenarije. itaoci
koje to zanima trebalo bi da proitaju knJlge [Perkms 1998b; RFC 32201-
6. 7 Upravljanje mobiinou u celularnim mreama
Poto smo razmotrili nain na koji se mobiinou upravlja u IP mreama, obratimo sada panju na
mree sa jo veim iskustvom za podrku mobilnosti - mree mobilne telefonije. Dok smo u odeljku
6.4 analizirali beini link prvog skoka u celularnim mreama, ovde se usredsreujemo na mobilnost
u arhitekturi GSM mree [Goodman 1997; Mouly 1992; Scourias 1997; Kaaranen 2001; Korhonen
2002] postoje to zrela i iroko primenjena tehnologija. Kao i u sluaju mobilnog IP-a, videemo daje
u arhitekturu GSM mree ugraen niz osnovnih principa koje smo utvrdili u odeljku 6.5.
Isto kao i mobilni IP, GSM prihvata princip indirektnog rutiranja (odeljak 6.5.2), tako to poziv
korespondenta prvo rutira u matinu mreu mobilnog korisnika, a odande u poseenu mreu. U
terminologiji GSM-a matina mrea mobilnog korisnika naziva se matina javna zemaljska
mobilna mrea (home Public Land Mobile Network, home PLMN). Poto se akronim PLMN teko
izgovara i s obzirom na nau elju da izbegnemo prevelik broj akronima, matini PLMN u GSM mrei
nazvaemo jednostavno matinom' mreom. Matina mrea je mobilni operater kod kojeg je
mobilni korisnik pretplaen (tj. operater koji korisniku alje mesene fakture za usluge). Poseeni
PLMN, kojeg emo jednostavno zvati poseena mrea, jeste mrea u kojoj se mobilni korisnik
trenutno nalazi.
Kao i u sluaju mobilnog IP-a, zaduenja matine i poseene mree se veoma razlikuju.
Matina mrea odrava bazu podataka poznatu kao matini registar lokacija (Home Location
Register, HLR) koji za svakog pretplatnika sadri trajni broj telefona i informacije o profilu
pretplatnika. Veoma je vano to HLR takoe sadri informaciju o trenutnoj lokaciji pretplatnika.
To jest, ako je mobilni korisnik trenutno u romingu u mrei drugog operatera, HLR sadri
dovoljno informacija za utvrivanje (postupkom koji emo uskoro opisati) adrese u poseenoj
mrei na koju treba rutirati pozive mobilnom korisniku. Kao to emo videti, kada poziva
mobilnog korisnika korespondent stupa u vezu sa posebnim komutatorom u matinoj mrei koji
se naziva GMSC (Gateway Mobile Services Svvitching Center). I ovde, da bismo smanjili
broj upotrebljenih akronima GMSC emo
- nazivati matini MSC.
Poseena mrea odrava bazu podataka poznatu pod imenom registar lokacija posettlaca
(Visitor Location Register, VLR). VLR sadri po jednu stavku za svakog mobilnog korisnika
koji se trenutno nalazi u delu mree koji opsluuje VLR. Stavke VLR-a se zato dodaju i izbacuju
kako mobilni korisnici ulaze u mreu ili je naputaju.'VLR se obino nalazi na istom mesni gde i
MSC (Mobile Switching Center) koji koordinira uspostavljanje poziva prema poseenoj mrei i iz
nje.

6.7 . UPRAVLJANJE MOBILNOU U CELULARNIM MREAMA
551 551 551 551

Osim ovde opisanih, standard za mobilni IP dozvoljava i mnoge drugaije scenarije. itaoci
koje to zanima trebalo bi da proitaju knjige [Perkins 1998b; RFC 3220].
6. 7 Upravljanje mobilnou u celularnim mreama
Poto smo razmotrili nain na koji se mobilnou upravlja u IP mreama, obratimo sada panju
na mree sa jo veim iskustvom za podrku mobilnosti - mree mobilne telefonije. Dok smo u
odeljku 6.4 analizirali beini link prvog skoka u celularnim mreama, ovde se usredsreujemo
na mobilnost u arhitekturi GSM mree [Goodman 1997; Mouly 1992; Scourias 1997; Kaaranen
2001; Korhonen 2002] postoje to zrela i iroko primenjena tehnologija. Kao i u sluaju
mobilnog IP-a, videemo daje u arhitekturu GSM mree ugraen niz osnovnih principa koje
smo utvrdili u odeljku 6.5.
Isto kao i mobilni IP, GSM prihvata princip indirektnog rutiranja (odeljak 6.5.2), tako to
poziv korespondenta prvo rutira u matinu mreu mobilnog korisnika, a odande u poseenu
mreu. U terminologiji GSM-a matina mrea mobilnog korisnika naziva se matina javna
zemaljska mobilna mrea (home Public Land Mobile Netvvork, home PLMN). Poto se
akronim PLMN teko izgovara i s obzirom na nau elju da izbegnemo prevelik broj akronima,
matini PLMN u GSM mrei nazvaemo jednostavno matinom' mreom. Matina mrea je
mobilni operater kod kojeg je mobilni korisnik pretplaen (tj. operater koji korisniku alje
mesene fakture za usluge). Poseeni PLMN, kojeg emo jednostavno zvati poseena mrea,
jeste mrea u kojoj se mobilni korisnik trenutno nalazi. Kao i u sluaju mobilnog IP-a, zaduenja
matine i poseene mree se veoma razlikuju.
Matina mrea odrava bazu podataka poznatu kao matini registar lokacija (Home Location
Register, HLR) koji za svakog pretplatnika sadri trajni broj telefona i informacije o profilu
pretplatnika. Veoma je vano to HLR takoe sadri informaciju o trenutnoj lokaciji
pretplatnika. To jest, ako je mobilni korisnik trenutno u romingu u mrei drugog operatera,
HLR sadri dovoljno informacija za utvrivanje (postupkom koji emo uskoro opisati)
adrese u poseenoj mrei na koju treba rutirati pozive mobilnom korisniku. Kao to emo
videti, kada poziva mobilnog korisnika korespondent stupa u vezu sa posebnim komutatorom
u matinoj mrei koji se naziva GMSC (Gateway Mobile Services Switching Center). I
ovde, da bismo smanjili broj upotrebljenih akronima GMSC emo
nazivati matini MSC.
Poseena mrea odrava bazu podataka poznatu pod imenom registar lokacija posetilaca
(Visitor Location Register, VLR). VLR sadri po jednu stavku za svakog mobilnog korisnika
koji se trenutno nalazi u delu mree koji opsluuje VLR. Stavke VLR-a se zato dodaju i
izbacuju kako mobilni korisnici ulaze u mreu ili je naputaju. VLR se obino nalazi na
istom mestu gde i MSC (Mobile Switching Center) koji koordinira uspostavljanje poziva
prema poseenoj mrei i iz nje.

289 289 289 289 POGLAVLJE 6 BEINE 1 MOBILNE MREE
6.7 . UPRAVUANJE MOBILNOU U CELULARNIM MREAMA 553 553 553 553

U praksi, celularna mrea jednog posrednika igra ulogu matine mree za svoje
pretplatnike, a poseene mree za mobilne korisnike pretplaene kod drugog mobilnog operatera.
6.7,1 Rutiranje poziva prema mobilnom korisniku
Sada smo moemo da opiemo kako se poziva mobilni GSM korisnik u poseenoj mrei.
Razmotriemo sledei jednostavan sluaj; sloeniji scenariji opisani su u knjizi [Mou!y 1992],
Kao stoje prikazano na slici 6.24, koraci su sledei:
1. Korespondent bira telefonski broj mobilnog korisnika. Sam broj se ne odnosi ni na jednu
konkretnu telefonsku liniju ni lokaciju (broj telefona je stalan, a korisnik je mobilan!).
Poetne cifre u broju su dovoljne za globalnu identifikaciju matine mree mobilnog
korisnika. Poziv se rutira od korespondenta kroz javnu telefonsku mreu do matinog
MSC-a u matinoj mrei mobilnog korisnika. Ovo je prvi krak poziva.
2. Matini mobilni komutacioni centar prima poziv i ispituje HLR kako bi utvrdio lokaciju
mobilnog korisnika. U najprostijem sluaju HLR vraa roming broj
mobilne stanice MSRN (Mobile Station Roaming Number), koji emo zvati roming broj.
Obratite panju na to da se ovaj broj razlikuje od trajnog broja telefona koji je povezan sa
matinom mreom mobilnog korisnika. Roming broj je nepostojan: on se privremeno dodeljuje
mobilnom korisniku prilikom ulaska u poseenu mreu. Roming broj igra ulogu slinu
privremenoj adresi u mobilnom IP-u i isto kao COA nevidljiv je za korespondenta i za
mobilnog korisnika. Ako HLR ne raspolae roming brojem, on vraa adresu VLR-a u
poseenoj mrei. U tom sluaju (koji nije prikazan na slici 6.24) matini MSC morae da
poalje upit kako bi od VLR-a pribavio roming broj mobilnog vora. Ali kako HLR uopte
pribavlja roming broj ili VLR adresu? ta se dogaa sa ovim vrednostima kada mobilni
korisnik pree u neku drugu poseenu mreu? Uskoro emo razmotriti ova znaajna pitanja. 3.
Kada- pribavi roming broj, matini MSC uspostavlja drugi krak poziva kroz mreu do MSC-a
u poseenoj mrei. Poziv je kompletiran poto je rutiran od korespondenta do matinog MSC-a
odatle do poseenog MSC-a, a od njega do bazne stanice koja opsluuje mobilnog korisnika.
U koraku 2 ostaje nerazreeno pitanje kako HLR pribavlja informaciju o lokaciji mobilnog
korisnika. Kada se mobilni telefon ukljui ili kada ue u deo poseene mree koji pokriva novi
VLR, on mora da se prijavi poseenoj mrei. To se obavlja razmenom signalnih poruka izmeu
mobilnog telefona i VLR-a. Zatim poseeni VLR alje poruku sa zahtevom za auriranje
lokacije matinom HLR-u mobilnog telefona. Ova poruka obavetava HLR ili o roming broju
na kojem se moe stupiti u vezu sa mobilnim telefonom ili o adresi VLR-a (od kojeg se kasnije
moe dobiti broj mobilnog telefona). U sklopu ove razmene VLR takode pribavlja od HLR-a
pretplatnike informacije o mobilnom korisniku i utvruje koje usluge mu treba omoguiti u
poseenoj mrei.

6.7.2 Predavanje u GSM-u
Kada mobilna stanica tokom poziva promeni pridruivanje od jedne bazne stanice na drugu
kaemo daje dolo do predavanja. Kao to je prikazano na slici 6.25, mobilni poziv se na
poetku (pre predavanja) rutira mobilnom korisniku preko jedne bazne stanice (koju emo sada
nazivati stara bazna stanica), a nakon predavanja se rutira preko druge bazne stanice (koju emo
nazvati nova bazna stanica). Obratite panju na to da prilikom predaje meu baznim stanicama
ne dolazi samo do promene u komunikaciji izmeu mobilne stanice i nove bazne stanice, ve
takode i u preusmeravanju poziva izmeu centrale u mrei i nove bazne stanice. Poimo od
pretpostavke da stara i nova bazna stanica pripadaju istom MSC-u i da se preusme-ravanje
obavlja u tom MSC-u.
Do predavanja moe doi iz vie razloga, ukljuujui ( 1 ) ako signal izmeu trenutne
bazne stanice i mobilne stanice do te mere izgubi na kvalitetu da postoji opasnost od prekida
poziva i (2) ako je elija postala preoptereena zbog velikog

554 554 554 554 POGLAVLJE o BEINE I MOBILNE MREE
6.7 . UPRAVLJANJE MOBILNOU U CELULARNIM MREAMA 290 290 290 290

broja poziva. Ovo zaguenje moe da se ublai predavanjem mobilnih stanica manje zaguenim
oblinjim elijama.
Dok je pridruena baznoj stanici, mobilna stanica povremeno meri jainu signala za
navoenje iz trenutne bazne stanice, kao i jaine signala za navoenje iz oblinjih baznih stanica
koje moe da uje". Ova merenja se jednom ili dva puta u sekundi prenose trenutnoj baznoj
stanici. U GSM-u predavanje pokree stara bazna stanica na osnovu ovih merenja, trenutnog
optereenja mobilnim korisnicima u oblinjim elijama i drugih faktora [Mouly 1992], Standard
GSM ne odreuje konkretan algoritam koji bazna stanica treba da primeni kako bi utvrdila da li
da obavi predavanje ili ne.
Na slici 6.26 prikazani su koraci po kojima bazna stanica odluuje da preda mobilnog
korisnika:
1. Stara bazna stanica (BS) obavetava poseeni MSC da e se obaviti predavanje i navodi BS
(ili skup BS-ova) kojima bi se mobilna stanica mogla predati.
2. Poseeni MSC inicira uspostavljanje putanje prema novoj BS, dodeljuje resurse potrebne za
prenos preusmerenog poziva i obavetava novu BS da e doi do predavanja.
3. Nova BS dodeljuje i aktivira radio kanal koji e koristiti mobilna stanica.
4. Nova BS odgovara poseenom MSC-u i staroj BS daje uspostavljena putanja od poseenog
MSC-a do nove bazne stanice i daje potrebno obavestiti mobilnu stanicu da e nastupiti
predavanje. Nova BS obezbeduje sve informacije potrebne mobilnoj stanici za
pridruivanje sa novom BS.
5. Mobilna stanica se obavetava da treba da izvri predavanje. Obratite panju na to da je sve
do ovog trenutka mobilna stanica bila u blaenom neznanju da je mrea pripremala teren za
predavanje (tj. dodeljivala kanal novoj baznoj stanici i dodeljivala putanju od poseenog
MSC-a do nove BS).
7. Mobilna i nova BS razmenjuju jednu ili vie poruka da bi se potpuno aktivirao novi kanal
u novoj BS.
8. Mobilna stanica alje novoj baznoj stanici poruku da je predavanje dovreno, a nova BS
prosleduje tu poruku poseenom MSC-u. Poseeni MSC zatim preu-smerava poziv koji je u
toku mobilnoj stanici preko nove BS.
9. Zatim se oslobaaju resursi na putanji prema staroj baznoj stanici.
Zakljuimo ovaj opis predavanja razmatranjem dogaaja do kojih dolazi kada se mobilna
stanica premesti na baznu stanicu koja pripada razliitom MSC-u od stare bazne stanice i ta se
dogaa kada vie puta dolazi do takvog predavanja meu MSC-ovima. Kako je prikazano na slici
6.27, u GSM-u je defmisan pojam sidrenog MSC-a. Sidreni MSC je onaj MSC u kome se
mobilna stanica nalazila na poetku poziva; sidreni MSC se dakle ne menja tokom celog poziva.
Za svo vreme dok poziv traje i bez obzira na broj prelazaka meu razliitim MSC-ovima poziv se
rutira od matinog MSC-a u sidreni MSC, a zatim od sidrenog MSC-a u poseeni MSC gde se
mobilna stanica trenutno nalazi. Kada mobilna stanica prelazi iz podruja koje pokriva jedan
MSC u drugo podruje, poziv koji je u toku prerutira se iz sidrenog MSC-a u novi poseeni MSC
koji sadri novu baznu stanicu. Prema tome, izmeu korespondenta i mobilne stanice nalazi se
najvie 3 MSC-a (matini MSC, sidreni MSC i poseeni MSC). Na slici 6.2? prikazano je
rutiranje poziva meu MSC-ovima koje mobilni korisnik poseuje.
Alternativa ovakvom povezivanju gde se zadrava samo jedan skok od sidrenog MSC-a do
trenutnog MSC-a moglo bi biti zadravanje lanca poseenih MSC-ova tako to bi stari MSC
prosledio poziv koji je u toku novom MSC-u svaki put kada se mobilna stanica premesti. Do
takvog ulanavanja MSC-a zaista i dolazi u celu-

6.8 BEINE MREE I MOBILNOST: POSLEDICE PO PROTOKOLE VIIH NIVOA 291 291 291 291

lamim mreama 1S-4! uz opciono minimiziranje koraka putanje kojim se uklanjaju MSC-ovi izmeu
sidrenog i trenutno poseenog MSC-a [L-in 2001].
Zakljuimo sada opis upravljanja GSM mobilnou jednim poredenjem upravljanja mobilnou u
GSM-u i mobilnom IP-u. Poreenje u tabeli 6.2 ukazuje na to da i pored fundamentalnih razlika
izmeu IP-a i celularnih mrea oni imaju iznenaujue mnogo slinosti i zajednikih funkcionalnih
elemenata za podrku mobilnosti.
6.8 Beine mree i mobilnost: posiedice po protokole
viih nivoa
U ovom poglavlju emo videti da se beine mree znaajno razlikuju od oienih kako u sloju veze
(zbog karakteristika beinih kanala kao to su opadanje, viestruke putanje i sakriveni terminali) tako
i u mrenom sloju (zbog mobilnih korisnika koji menjaju take prikljuka sa mreom). Da li postoje
znaajne razlike i u transportnom i aplikacijskom sloju? Moglo bi se pomisliti da e te razlike biti mini-
malne poto mreni sloj prua viim slojevima isli model usluge najboljeg mogueg prenosa u
oienim i u neoicnim mreama.
Slino tome, ako se i u oienim i u beinim mreama za pruanje usluga aplikacijama u
transportnom sloju koriste protokoli kao to su TCP ili UDP, tada ni
aplikacijski sloj ne mora da se menja. Na neki nain intuitivna logika je tana - TCP i UDP mogu da
funkcioniu i u mreama sa beinim linkovima. S druge strane, transportni protokoli uopte, a
posebno TCP, ponekad imaju veoma razliite performanse u oienim i beinim mreama.
Pogledajmo zalo.
Setite se da TCP ponovo alje segment koji se na putanji od poiljaoca do primaoca izgubio ili
otetio. U sluaju mobilnih korisnika gubici mogu da nastanu bilo zbog zaguenja mree
(prekoraenja privremenih memorija u ruterima) ili zbog predavanja (npr. zbog odlaganja u
preusmeravanju segmenata prema novoj pristupnoj taki mobilne stanice sa mreom). U svim tim
sluajevima, ACK od primaoca ka poiljaocu u TCP-u ukazuje samo na to da segment nije stigao
neoteen; poiljalac ne zna da l i j e segment izgubljen zbog zaguenja, tokom predavanja ili zbog
toga to su otkrivene greke u bitovima. U svim sluajevima poiljalac reaguje jednako - ponovo alje
segment. TCP-ova kontrola zaguenja takoe reaguje isto u svim sluajevima - TCP smanjuje
prozor zaguenja kao to je opisano u odeljku 3.7. Bezuslovnim smanjivanjem prozora zaguenja
TCP implicitno pretpostavlja da do gubitka segmenata dolazi zbog zaguenja, a ne zbog oteenja ili
predavanja. U odeljku 6.2 videli smo.da su greke u bitovima daleko ee u beinim mreama
nego u oienim. Kada doe do takvih greaka ili do gubitka zbog predavanja, zaista nema razloga
da TCP poiljalac smanji prozor zaguenja (i tako smanji brzinu slanja). Zaista, sasvim je mogue da
su pomone memorije u ruterima prazne i da zaguenje ne omela pakete sa kraja na kraj putanje.

DOMAI ZADATAK: PROBLEMI I PITANJA
55 55 55 55
t tt t
Istraivai su poetkom '90-tih utvrdili da zbog visoke uestalosti greaka u bitovima na
beinim linkovima i verovatnoe gubitaka prilikom predavanja, kontrola zaguenja u TCP-u
moe u beinom okruenju da postane problematina. U reavanju ovog problema postoje dve
iroke klase pristupa [Balakrishnan 1995]:
Lokalni oporavak. Kod lokalnog oporavka cilj je da se oporavak od greaka u bitovima obavi
na licu mesta i u trenutku gde do njih dolazi (npr. u beinom linku). To znai da su potrebni
(1) protokoli koji oporavljaju od gubitaka i oteenja u sloju veze (npr. ARQ protokol 802.11
koji smo prouili u odeljku 6.3 ili sloeniji pristupi koji koriste i ARQ i FEC [Avanoglu
1995]); (2) protokoli transportnog sloja koji dele TCP konekciju na dva segmenta, jedan od
izvora do beinog linka, a drugi od beinog linka do odredita [Bakre 1995; Brovvn 1997];
i (3) protokoli sloja veze svesni TCP-a [Balakrishnan 1995; Liu 2002],
TCP poiljalac svestan beinih linkova. U pristupu sa lokalnim oporavkom, TCP poiljalac
ivi u blaenom neznanju da neki njegovi segmenti koriste beini link. Alternativni pristup
jeste da TCP poiljalac i primalac budu svesni postojanja beinog linka, da razlikuju gubitke
uzrokovane zaguenjem u oie-noj mrei od oteenja i gubitaka do kojih dolazi u beinom
linku, pa da pozivaju kontrolu zaguenja samo u sluaju gubitaka na zaguenoj oienoj
mrei. U knjizi [Balakrishnan 1995] istrauju se razliiti tipovi TCP-a pod pretpostavkom da
krajnji sistemi budu u stanju da otkriju tu razliku. U knjizi [Wei 2004] istrauju se tehnike za
otkrivanje razlika izmeu gubitaka na oienim od gubitaka na beinim delovima putanje sa
kraja na kraj.
Ovde je na opis TCP-a preko beinih linkova morao da bude kratak. Konsul-tujte
reference gde ele nai detalje o ovom podruju koje se jo uvek istrauje.
Poto smo razmotrili protokole transportnog sloja, razmotrimo sada na koji nain beine
veze i mobilnost utiu na protokole aplikacijskog sloja. Ovde je znaajno naglasiti da beini
linkovi esto imaju relativno male propusne opsege kao to smo videli na slici 6.2. Zbog toga
aplikacije koje rade preko beinih linkova, pogotovo preko celularnih beinih linkova, moraju
tretirati propusni opseg kao deficitaran resurs. Na primer, veb server koji alje sadraj itau koji
se izvrava na telefonu 3G verovatno nee moi da obezbedi isti bogat sadraj koji alje itau
preko oiene konekcije. Mada beini linkovi postavljaju izazove pred aplikacijski sloj,
mobilnost koju omoguavaju takoe omoguava iroku paletu aplikacija zavisnih od konteksta i
od lokacije [Chen 2000]. Uopteno govorei, beine i mobilne mree imae kljunu ulogu u
realizaciji sveprisutnih raunarskih okruenja budunosti [Weiser 1991]. Moe se rei da smo
videli samo vrh ledenog brega kadaje re o uticaju beinih i mobilnih mrea na mrene
aplikacije i njihove protokole!
6. 9 Rezime
Beine i mobilne mree predstavljaju revoluciju u telefoni] i i imaju sve vei uti-caj u svem
raunarskih mrea. Svojim pristupom globalnoj mrenoj infrastrukturi u svakom trenutku na
svakom mestn bez ikakvog zadravanja, ne samo to omoguavaju sveprisutni pristup mrei, ve
omoguavaju jedan nov i uzbudljiv skup usluga zavisno od lokacije. S obzirom na sve vei
znaaj beinih komunikacija i mrea ovo poglavlje govori o principima, tehnologijama
zajednikih linkova i mrenim arhitekturama za podrku beine i mobilne komunikacije.
Poglavlje smo zapoeli jednim uvodom u beine i mobilne mree, povlaei znaajnu
granicu izmeu zadataka koje namee beina priroda komunikacionih linkova u tim mreama i
onih koji su posledica mobilnosti koje ti beini linkovi omoguavaju. Na taj nain smo bolje
razdvojili, prepoznali i savladali kljune koncepte svakog od ovih podruja. Prvo smo se
usredsredili na beinu komunikaciju, razmotrili karakteristike beinog linka u odeljku 6.2. U
odeljcima 6.3 i 6.4 razmotrili smo aspekte u sloju veze IEEE standarda beinog LAN-a 802.11
(Wi-Fi) i celularni pristup Internetu. Zatim smo obratili panju na pitanje mobilnosti. U odeljku
6.5 ukazali smo na nekoliko oblika mobilnosti od kojih svaki postavlja razliite izazove i
dozvoljava razliita reenja. Ispitali smo probleme lociranja i rutiranja prema mobilnom
korisniku, kao i razliite pristupe predavanja mobilnog korisnika koji se dinamiki kree od
jedne pristupne take sa mreom do druge. Ispitali smo kako su ta pitanja reena u standardu za
mobilni IP u odeljku 6.6 odnosno u GSM-u u odeljku 6.7. Na kraju, u odeljku 6.8 razmatrali smo
uticaj beinih linkova i mobilnosti na protokole transportnog sloja i na mrene aplikacije.
Mada smo posvetili celo poglavlje studiranju beinih i mobilnih mrea, za potpun pregled
ovog uzbudljivog podruja koje se bTZo iri bila bi potrebna cela knjiga (ili vie njih). Da biste
detaljnije istraili ovo polje, posluite se brojnim referencama pomenutim u ovom poglavlju.
Domai zadatak: problemi i pitanja
1. Opiite ulogu okvira za navoenje u protokolu 802.11.
2. Opiite metode dostupne za proveru autentinosti korisnika u mreama 802.1 1.
3. Tano ili netano: Pre nego to stanica 802.11 poalje okvir podataka, ona mora prvo da
poalje RTS okvir i primi odgovarajui CTS okvir.
4. Zato se potvrde koriste u protokolu 802.11, a ne i u oienom Internetu?
5. Tano ili netano: Ethemet i 802.11 koriste istu strukturu okvira.

560
PROBLEMI 561
6. Opiite kako funkcionie RTS prag.
7. Kada bi RTS i CTS okviri protokola IEEE 802.11 bili dugaki kao i standardni DATA i
ACK okviri, da li bi CTS i RTS okviri bili od ikakve koristi? Zato?
8. U odeljku 6.3.4 opisana je mobilnost u protokolu 802.11 gde se beina stanica premeta
sa jedne bazne stanice na drugu unutar iste podmree. Kada su pristupne take meusobno
povezane komutatorom, pristupna taka ponekad mora da poalje okvir sa lanom MAC
adresom kako bi komutator pravilno prosleivao okvire. Zato?
9. Nauili smo u odeljku 6.3.2 da postoje dva glavna 3G standarda: UMTS i
CDMA-2000. Od kojih standarda druge i 2,5 generacije potiu ta dva standarda?
Problemi ______________________________________
1. Razmotrite primer sa jednim CDMA poiljaocem sa slike 6.4. ta bi bio izlaz poiljaoca
(za prikazana 2 bita podataka) ako bi CDMA kod poiljaoca bio (1, -1, 1,-1, 1,-1= 1,-1)?
2. Razmotrite poiljaoca 2 na slici 6.5. Staje izlaz poiljaoca prema kanalu (pre nego to se
doda na signal od poiljaoca 1), Z, ?
3. Pretpostavite da primalac sa slike 6.5 eli da primi podatke koje alje poiljalac 2. Dokaite
(raunski) da primalac zaista moe da izdvoji podatke poiljaoca 2 iz signala agregatnog
kanala tako to e upotrebiti kod poiljaoca 2.
4. Pretpostavite da postoje 2 posrednika za Internet usluge koja nude Wi-Fi pristup u
odreenom kafeu tako to svaki posrednik ima vlastitu pristupnu taku i vlastiti blok IP
adresa.
a. Pretpostavite dalje da su oba posrednika sluajno konfigurisala pristupne
take tako da rade na kanalu 11. Da li e protokol 802.11 u ovoj situaciji
potpuno da otkae? Opiite ta bi se desilo kada bi dve stanice od kojih je
svaka pridruena drugom posredniku istovremeno pokuale da emituju.
b. Sada pretpostavite da jedna pristupna taka radi na kanalu 1, a druga na
kanalu 11.
5. U koraku 4 protokola CSMA/CA stanica koja uspeno prenese jedan okvir
zapoinje protokol CSMA/CA za sledei okvir od koraka 2 umesto od koraka
1. Koji su razlog imali projektanti protokola CSMA/CA da ne dozvole takvoj
stanici da odmah pone, sa slanjem drugog okvira (ako otkrije daje kanal
slobodan)?
6. Pretpostavite daje stanica 802.11b konfigurisana tako da uvek rezervie kanal
nizom poruka RTS/CTS. Pretpostavite da ta stanica iznenada eli da poalje
1 000 bajtova podataka i da su u tom trenutku sve druge stanice neaktivne.
Zanemarujui kanjenje zbog propagiranja i pod pretpostavkom da nema greaka bitova
izraunajte vreme potrebno da se prenese okvir i primi potvrda (kao funkciju SIFS i DIFS).
7. U odeljku 6.5 jedno od predloenih reenja koje je omoguavalo mobilnim
korisnicima da zadre IP adresu prilikom kretanja po stranim mreama bilo
je da strana mrea objavljuje sasvim konkretnu mtu do mobilnog korisnika
i iskoristi postojeu infrastrukturu rutiranja za propagiranje ove informacije
po celoj mrei. Uoili smo da bijedan od problema mogao biti skalabilnost.
Pretpostavite da kad mobilni korisnik prede iz jedne mree u drugu nova strana
mrea objavi konkretnu rutu do mobilnog korisnika, a da stara strana mrea
povue svoju rum. Razmotrite kako se informacija za rutiranje propagira u
algoritmu vektora rastojanja (pogotovo za sluaj meudomenskog rutiranja
meu mreama koje pokrivaju celu zemlju).
a. Da li e drugi ruteri moi da rutiraju datagrame u novu stranu mreu im
strana mrea pone da objavljuje tu rum?
b. Da li je mogue da razni ruteri smatraju da mobilni korisnik pripada
razliitim stranim mreama?
c. Opiite vremenski raspon u kojem e drugi ruteri u mrei konano saznati
putanju prema mobilnim korisnicima.
8. Pretpostavite daje korespondent sa slike 6.17 mobilan. Skicirajte dodatnu
infrastrukturu u mrenom sloju koja bi bila potrebna da se datagram rutira od
prvobitno mobilnog korisnika do korespondenta (koji je sada mobilan). Prikaite
strukturu datagrama izmeu prvobitno mobilnog korisnika i sada mobilnog
korespondenta kao na slici 6.18.
9. U mobilnom IP-u, kakav bi efekat imala mobilnost na kanjenje datagrama sa kraja na kraj
izmeu izvora i odredita?
10. Razmotrite primer sa ulanavanjem opisan na kraju odeljka 6.7.2. Pretpostavite da mobilni
korisnik poseuje strane mree A, B i C, a da korespondent zapone konekciju sa mobilnim
korisnikom kada se on nalazi u stranoj mrei A. Navedite redosled poruka meu stranim
agentima i izmeu stranih agenata i matinog agenta kako se mobilni korisnik kree iz
mree A u mreu B, pa u mreu C. Zatim, pretpostavite da nema ulanavanja, a da
korespondent (kao
i matini agent) mora eksplicitno da se obavesti o promenama adrese COA mobilnog
korisnika. Navedite redosled poruka koje bi morale da se razmene u ovom drugom
scenariju.
11. Razmotrite dva mobilna vora u stranoj mrei sa stranim agentom. Da li je u mobilnom
IP-u mogue da ta dva mobilna vora koriste istu adresu COA? Objasnite.pdgovor. .
12. U naem opisu kako je VLR aurirao HLR informacijom o trenutnoj lokaciji mobilne
stanice, koje su prednosti i mane da se u HLR evidentira MSRN, a ne VLR?

294 POGLAVLJE 6 ' BEINE I MOBILNE MREE
INTERVJU

Teze za diskusiju _____________
1. Navedite 5 proizvoda na dananjem tritu koji sadre interfejs Bluetooth ili 802.15.
2. Da li su u vaoj okolini dostupne beine usluge 3G? Kakve su cene? Koje se aplikacije
podravaju?
3. Koje ste probleme uoili kao korisnik protokola IEEE 802.11? Kako bi dizajn standarda
802.11 mogao da se razvije da bi se ti problemi prevazili?
Laboratorija Ethereal
Na veb lokaciji koja pripada ovom udbeniku: http://www.awl.com/kurose-ross nai ete
Ethereal vebu za ovo poglavlje koja hvata i ispituje okvire 802.11 koje razmenjuju beini
laptop i jedna pristupna taka.
V
Carli Carli Carli Carli Perkins Perkins Perkins Perkins
Caris E. Perkins je istraiva najvieg strukovnog ranga u Laboratoriji za
komunikacione sisteme Nokijrnog Istraivakog centra, gde se bavi
mobilnim.beinim umreavanjem i dinamikim konfiguracionim protokolima. On
je izdava nekoliko ACM i IEEE asopisa za podruja vezana za beino
umreavanje. Obavlja funkciju redaktora dokumenata za radnu
grupu Mobile-IR u lETF-u. On je pisac i saradnik na izradi standarda u radnim grupama mobileip,
manet, IPv6 i seamoby (5eam/ess Mobi l i l y\. Takoe je medu izdavaima asopisa Mobi l e
Communi cati ons and Compufing, zvanine publikacije interesne grupe ACM 5IGMOBIIE,
radio je i u urednitvu asopisa IEEE I nt ernet Computi ng, Carli je napisao i redigovoo knjige o
mobilnom iP-u i od hoc umreavanju, a objavio je niz dokumenata i lanaka koji su dobili nagrade
u podrujima mobilnog umreavanja, ad hoc umreavanja, opfimizacije ruta za. mobilno
umreavanje, otkrivanje resursa i automatskog konfigurisanja za mobilne raunare.
Za Za Za Zato ste odlu to ste odlu to ste odlu to ste odluili da se specijali'iujete za be ili da se specijali'iujete za be ili da se specijali'iujete za be ili da se specijali'iujete za bei ii ino umre no umre no umre no umreavanje i mobilnost? avanje i mobilnost? avanje i mobilnost? avanje i mobilnost?

j
Moja povezanost sa beinim umreavanjem i mobilnou prirodno proistie iz rada na projektima
u IBM-ovom istraivakom centru krajem '80-tih. Imali smo radio-linkove i pokuavali da
napravimo ureaj u stilu ThinkPad" (kao neki Palm Pilot) sa beinim povezivanjem i
prepoznavanjem rukopisa.
Napravili smo jednostavno reSenje (koje je kasnije dobilo ime Mobile IP") i primetili da
funkcionie. To je, naravno, neobino u poredenju sa veinom istraivakih reenja. Na
osnovu iskustva sa mobilnim IP-om napravili smo brzu i efikasnu modifikaciju za RIP koja je
mogla da se izvrava ad hoc. I to je prilino dobro funkcionisalo. Pod funkcionisanjem"
podrazumevam da su aplikacije pravilno radile bez ikakvih izmena i da mrea nije posrfala
pod naim novim dizajnom. To se naziva svojstvima transparentnost u odnosu na aplikacije" i
skalabilnost".

Koji vam je bio prvi posao u ra Koji vam je bio prvi posao u ra Koji vam je bio prvi posao u ra Koji vam je bio prvi posao u raunarskoj industriji? unarskoj industriji? unarskoj industriji? unarskoj industriji?
Radio sam u firmi TRW Controls u Hjustonu (Teksas). To je bila drastina promena u odnosu na
univerzitetske studije.
Na tom poslu sam utvrdio koliko je lo softver za podrku ak i najvanijih pomonih
kontrolnih sistema. Ti su sistemi namenjeni kontroli elektrinog toka u velikim snanim
mreama, a softver koji ih podrava bio je napravljen tako da vam se kosa digne na glavi.
Osim toga, rokovi su uvek bili kratki, a programeri su cinino komentarisali namere uprave
i svoje ustove rada. Ceo sistem je trebalo preurediti iz osnova. Nisam ubeden da su se stvari
promenile za ovih 30 godina, pogotovo kad se setimo raspada elektrinog sistema 2003. U
stvari, s obzirom na poputanje regulativa, skoro sigurno je jo gore. Rado sam napustio

295
652 652 652 652

Kakva je vaa vizija budunosti multimedijskog umreavanja?
Mi smo sada u prelaznoj fazi, na samo nekoliko godina od trenutka kada e IP postati uni-
verzalna platforma za multimedijske usluge. Oekujemo da e radio, telefon i TV raditi ak i za
vreme snenih oluja i zemljotresa, tako da e korisnici, kada Internet preuzme ulogu ovih
namenskih mrea, imati isti nivo pouzdanosti.
Istraivanja umreavanja se u izvesnoj meri suoavaju sa problemom koji su istraivanja
operativnih sistema imala godinama, ili ak i vie. Dok je jo uvek mogue sprovoditi butik"
istraivanja operativnih sistema u malim zajednicama, pokretanje odvojene mree u velikoj meri
nema svrhe. Moraemo da nauimo da projektujemo mrene tehnologije za meusobno
povezivanje konkurentnih nosilaca, sa mnogo krajnjih korisnika koji su neznalice ili zlonamemi.
Vidljiva napredovanja u multimedijskim mreama pokretae inioci koji se nalaze izvan
same ove oblasti, kao to su dostignua u brzinama pristupa i okosnice, kao i jeftina raunarska
snaga.
Zato 5IP ima budunost koja obeava?
Kako se danas nastavlja nadgraivanje beinih mrea na 3G mree, postoji nada za proirivanje
jednog multimedijskog signalnog mehanizma na sve vrste mrea, od kablovskog modela do
korporativnih telefonskih i javnih beinih mrea. Zajedno sa softverskim radi-om, to e u
budunosti omoguiti da jedan ureaj moe da se koristi u kunoj mrei, kao beini Bluetooth
telefon, u korporativnoj mrei preko 802.11 i u globalnom podruju preko 3G mrea. ak prc
nego to budemo imali takav univerzalni beini ureaj, mehanizmi linih mobilnih aplikacija
omoguavaju da se sakriju razlike izmeu mrea. Jedan identifikator postaje univerzalno
sredstvo da se doe do neke osobe, i zamenjuje pamenje ili pro-laenje preko pola tuceta
tehnologija ili telefonskih brojeva koji zavise od lokacije.
SIP takode razdvaja prenos glasa od govornih usluga. Sada postaje tehniki mogue da se
odvoji od monopola lokalne telefonije, gde jedna kompanija obezbeduje neutralni bitski prenos,
dok druge obezbeuju IP tonsko biranje" i klasine telefonske usluge kao to su mreni prolazi,
prosleivanje poziva i identifikacija poziva.
Pored multimedijske signalizacije, SIP nudi novu uslugu koja je nedostajala na Internetu:
beleenje dogaaja. Mi smo aproksimirali takve usluge pomou HTTP improvizacija i
elektronske pote, ali to nikada nije bilo ba zadovoljavajue. Kako su dogaaji uobiajena
apstrakcija za distribuirane sisleme, ovo moe da uprosti konstrukciju novih usluga.
Imate li neki savet za studente koji ulaze u oblast umreavanja?
Umreavanje je gotovo klasina disciplina premoavanja. Ono ima korene u elektrotehnici,
raunarskim naukama, operacionim istraivanjima i drugim disciplinama. Dakle, istraivai
umreavanja treba da poznaju predmete koji su daleko izvan njihove osnovne oblasti.
Rad na mreama moe da prui ogromno zadovoljstvo, zato to dopusta ljudima da
komuniciraju i razmenjuju ideje, to je jedna od osnovnih crta ljudskosti. Mnoga podruja
inenjerstva ve su dosegla najvii nivo svog razvoja; automobili, vozovi i avioni jo uvek
uglavnom rade ono to su radjli pre 20 ili vie godina i verovatno nee ii mnogo bre u siedeih
20. Glavna promena bie u sposobnosti da ti entiteti komuniciraju i tako poboljaju svoju
performansu, postavi sigurniji, izbegavajui saobraajna zaguenja.
Bezbednost u
raunarskim
mreama
Predstavljamo vam Alisu i Boba, dvoje ljudi koji ele da komuniciraju i da to rade bezbedno".
Imajui u vidu da je ovo knjiga o umreavanju, trebalo bi da primetimo kako bi Alisa i Bob
mogli da budu dva rutera koji ele da bezbedno razmene tabele rutiranja, klijent i server koji ele
da uspostave bezbednu transportnu konekciju, ili dve aplikacije elektronske pote koje ele da
razmenjuju bezbednu elektronsku potu - to su sve sluajevi koje emo razmatrati kasnije u
ovom poglavlju. Alisa i Bob su dobro poznati u zajednici koja se bavi bezbednou, moda zato
to su njihova imena veselija od generikog entiteta zvanog ,,A" koji eli da bezbedno komuni-
cira sa generikim entitetom zvanim ,,B"- Zabranjene ljubavne veze, komunikacija u toku rata i
poslovne transakcije obino se navode kao ljudske potrebe za bezbednim komuniciranjem; poto
vie volimo prvu situaciju u odnosu na druge dve, sreni smo da koristimo Alisu i Boba kao
naeg poiljaoca i primaoca, i da ih zamislimo u ovom prvom scenariju.
Rekli smo da Alisa i Bob ele da komuniciraju i da to rade bezbedno", ali ta to tano
znai? Kao to emo videti, bezbednost je (kao i ljubav) arolika stvar; odnosno, ima mnogo
aspekata bezbednosti. Naravno, Alisa i Bob bi voleli da sadraj njihove komunikacije ostane
tajna za prislukivae (recimo, za ljubomornu suprugu). Oni bi takoe voleli da osiguraju da,
kada komuniciraju, oni zaista to ine jedno sa drugim i da, ako se u njihovu komunikaciju mesa
neki prislukiva, to meanje bude otkriveno. U prvom delu ovog poglavlja, objasniemo
tehnike koje dozvoljavaju

296 296 296 296 POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA
8.1 * TA JE BEZBEDNOST MREE 655 655 655 655

ifrovanje/deifrovanje komunikacije, autentifikovanje strane sa kojom se komunicira i
osiguranje integriteta poruke.
U drugom delu ovog poglavlja, razmotriemo injenicu da krajnje take u komunikaciji
rade u vorovima unutar preduzea ili kune mree, na slian nain kao to bi Alisa i Bob mogli
da ive u kuama iz kojih bi komunicirali slanjem pote. Videemo da mrea (kao kua) moe da
bude ranjiva na napade, ali da moe da preduzme protivmere kako bi se zatitila od "loih
momaka" koji nesumnjivo postoje. Zato emo objasniti i mrene barijere, koje obezbeuju
izvestan stepen izolacije i zatite od onih koji se nalaze izvan neije mree. Razmotriemo i
razne oblike napada na mrenu infrastrukturu, kao i protivmere koje se preduzimaju da bi se
uklonile, ili bar ublaile posledice tih napada. Poglavlje zakljuujemo studijama primera
bezbednosti u aplikaciji, transportu, mrei i slojevima linka.
8.1 ta je bezbednost mree
Ponimo prouavanje bezbednosti mree vrativi se naim ljubavnicima, Alisi i Bobu, koji ele
da komuniciraju bezbedno". ta to tano znai? Svakako, Alisa eli da samo Bob moe da
razume poruku koju je ona poslala, ak i ako oni komuniciraju preko nebezbednog" medijuma
na kojem uljez (Trudi) moe da presretne i ita sve to se prenosi od Alise do Boba, kao i da to
raunarski obradi. Bob takode eli da bude siguran da je poruku koju prima od Alise ona zaista i
poslala, a Alisa eli da bude siguma daje osoba sa kojom komunicira zaista Bob. Alisa i Bob
takoe ele da budu sigurni kako sadraj njihovih poruka nije promenjen u prenosu. Imajui u
vidu navedene zahteve, moemo da identifikujemo sledee poeljne osobine bezbe-dne
komunikacije:
Tajnost. Trebalo bi da samo poiljalac i nameravani primalac razumeju sadraj prenesene
poruke. S obzirom na to da prislukivai mogu da presretnu poruku, to obavezno zahteva da
ona bude nekako ifrovana (njeni podaci maskirani), tako da presretnutu poruku prislukiva
ne moe da deifruje (razume). Ovaj aspekt tajnosti je verovatno najee podrazumevano
znaenje termina bezbe-dna komunikacija". Zapazite, meutim, da to ne samo daje
ograniena definicija bezbedne komunikacije (kasnije emo navesti dodatne aspekte
bezbedne komunikacije), nego i ograniena definicija same tajnosti. Na primer, Alisa bi
takoe mogla da poeli da sama injenica da ona komunicira sa Bobom (ili vreme ili
uestalost njene komunikacije) bude tajna! Kriptografske tehnike za ifrovanje i deifrovanje
podataka prouiemo u odeljku 8.2. Videemo da se tajna komunikacija esto oslanja na
jedan klju ili na vie kljueva koji se koriste za ifrovanje/deifrovanje. Temu distribucije
ovih kljueva obradiemo u odeljku 8.5.
Autentifikacija. I poiljalac i primalac trebalo bi da mogu da potvrde identitet druge strane u
komunikaciji - odnosno, da potvrde kako je druga strana zaista onaj ili ono to tvrdi da jeste.
Ljudska komunikacija licem u lice taj problem Iako reava vizuelnim prepoznavanjem. Kada
entiteti koji komuniciraju razmenjuju poruke preko medijuma gde ne mogu da vide" drugu
stranu, autentifikacija nije tako jednostavna. Zato biste, na primer, verovali daje poruka
elektronske pote, koja sadri deo teksta u kome se kae daje ona dola od vaeg prijatelja,
zaista dola od vaeg prijatelja? Ako vas neko pozove preko telefona tvrdei daje iz vae
banke i trai broj vaeg rauna, tajni lini identifikacioni broj (PIN) i bilanse rauna radi
verifikacija, da li biste mu dali te informacije preko telefona? Nadajmo se da ne biste!
Ispitaemo tehnike autentifikacije u odeljku 8.3, ukljuujui vie njih koje se, moda
iznenaujue, takoe oslanjaju na kriptografske tehnike iz poglavlja 8.2.
Integritet i neporecivost poruke. ak i kada poiljalac i primalac mogu da autentifikuju jedan
drugog, oni takoe ele da obezbede da se sadraj njihove komunikacije ne menja u prenosu,
bilo zlonamerno ili sluajno. Proirenja tehnika kontrolnog zbira koje smo sreli u pouzdanom
transportu i protokolima linka podataka mogu da se iskoriste da bi se obezbedio takav
integritet poruka. to je tema koju emo poruavati u odeljku 8.4. Videemo takoe kako
primalac moe da dokae" daje poruka morala da stigne od najavljenog poiljaoca.
Videemo da se i integritet poruke i neporecivost takoe oslanjaju na kriptografske koncepte
iz odeljka 8.2.
Raspoloivost i kontrola pristupa. Potrebu za mrenom bezbednou su na bolan nain u
poslednjih nekoliko godina potencirali brojni napadi odbijanja usluga (denial-of-service,
DoS), koji su za legitimne korisnike izbacili iz upotrebe mreu, raunar ili neki drugi deo
mrene infrastrukture; moda najuveniji od tih DoS napada bili su oni protiv veb lokacija
velikih kompanija. Dakle, kljuni zahtev za bezbednu komunikaciju je da ona pre svega moe
da se odvija - da loi momci" ne mogu da spree da legitimni korisnici koriste infrastrukturu.
injenica da neki korisnici mogu da budu legitimni dok drugi to nisu, prirodno dovodi do
pojma kontrole pristupa - to obezbeduje da se entitetima koji trae da dobiju pristup
resursima to dozvoljava samo ako imaju odgovarajua pristupna prava i ako pristupaju na
dobro definisan nain.
Tajnost, autentifikacija, integritet poruka i neporecivost se ve izvesno vreme smatraju kljunim
komponentama bezbedne komunikacije [McCumber 1991]. Raspoloivost i kontrola pristupa su
novija proirenja pojma bezbedne komunikacije [Maconachy 2001], bez sumnje motivisana
stvarnim poslovima na obezbeivanju mrene infrastrukture od potencijalnih napada loih
momaka". Jedan od najsigurnijih naina da se obezbedi da loi momci" ne mogu da naprave
nikakvu tetu je da se njihovi paketi ne puste ni da uu u mreu. Mrena barijera (firewall) je
ureaj izmeu mree koja treba da se titi (nas") i ostatka sveta ( loih momaka" -

8.2 . TA JE BEZBEDNOST MREE 297 297 297 297
-i-

njih"). Ona kontrolie pristup ka mrei i slanje od nje, reguliui koji paketi mogu da prou
unutar neije mree i izau van nje. Mrene barijere su brao postale uobiajena komponenta u
mreama, u opsegu od malih kunih mrea do onih koje pripadaju najveim korporacijama na
svem. Ispitaemo kako mrene barijere obezbeuju kontrolu pristupa (i po paketima i po usluzi)
u odeljku 8.6.
Navedena definicija bezbedne komunikacije usredsreena je prvenstveno na zatitu
komunikacije i mrenih resursa, U praksi, mrena bezbednost obuhvata ne samo zatitu, nego i
detektovanje krenja bezbedne komunikacije i napada na infrastrukturu, a zatim i odgovor na te
napade. U mnogo sluajeva, u odgovoru na napade, administrator mree moe da primeni
dodatne zatitne mehanizme. U tom smislu, mrena bezbednost se postie kroz neprestani ciklus
zatite, detekcije i odgovora. (Sa malo podataka, ali veoma itljiva, knjiga u kojoj se ilustruju
aspekti ovog ciklusa je [Stoll 1995)).
Nastaviemo ovo poglavlje objanjenjem (u odeljku 8.7) jednog broja napada koji si; se do
sada koristili, kao ; prolivmera koje prema njima mogu da se pre-duzmu. U odeljku 8.8
zakljuiemo ovo poglavlje studijama primera u kojima se koriste tehnike iz odeljaka od 8.2 do
8.5 u aplikacionom sloju, transportnom sloju, mrenom sloju i sloju veze podataka.
Poto smo definisali bezbednost mree, sada emo videti kojim informacijama uljez moe
da ima pristup i koje aktivnosti moe da preduzme. Scenario je ilustro-van na slici 8.1. Alisa,
poiljalac, eli da poalje podatke Bobu, primaocu. Da bi se podaci bezbedno razmenjivali, uz
ispunjavanje zahteva tajnosti, autentifikacije i integriteta poruke, Alisa i Bob e razmeniri
kontrolne poruke i poruke sa podacima (na isti nain kao to TCP poiljaoci i primaoci
razmenjuju kontrolne segmente i segmente sa podacima). Sve, ili neke od ovih poruka e biti
ifrovane. Pasivni uljez moe da potencija/no izvede
prislukivan)e - sluanje i registrovanje kontrolne poruke i poruke sa podacima na kanalu;
modifikaciju, umetanje ili brisanje poruka ili njihovog sadraja.
Kao to emo videti, izuzev ako su preduzete odgovarajue prottvmere, ove sposobnosti
doputaju uljezu da izvede irok skup razliitih napada na bezbednost u opsegu od prislukivanja
komunikacije (mogua kraa lozinke i podataka), do predstavljanja drugog entiteta,
kidnapovanja" sesije u toku, odbijanja usluge legitimnim korisnicima mree preoptereivanjem
sistemskih resursa. Ove i druge napade objasniemo u odeljku 8.7. Sline bezbednosne pretnje
objanjene su u zbirci eseja [Deruiing 1997] i u veoma itljivoj Rubinovoj knjizi [Rubin 2001].
Sumarni pregled napada aurira se u organizaciji CERT Coordination Center [CERT 2002].
Proitajte takoe [Cisco Securitv 1997; Vovdock 1983; Bhimani 1996].
Poto smo ustanovili da zaista postoje prave pretnje (poznate i kao Trudi") prisutne na
Internetu, ta su Internet ekvivalenti Alise i Boba, naih dveju linosti koje treba bezbedno da
komuniciraju? Svakako, Bob" i Alisa" bi mogli da budu ljudi, korisnici dva krajnja sistema, na
primer, stvarna Alisa i stvarni Bob koji zaista ele da razmenjuju bezbednu elektronsku potu.
Oni bi, takoe, mogli da budu uesnici u elektronskoj komercijalnoj transakciji. Na primer,
stvarna Alisa hi mogla eleti da bezbedno prenese broj svoje kreditne kartice veb serveru da bi
onlajn kupila neki predmet ili uslugu. Slino tome, stvarna Alisa bi mogla eleti da ima onlajn
interakciju sa svojom bankom. Meutim, kao to pie u [RFC 1636], strane kojima je potrebna
bezbedna komunikacija mogle bi i same da budu deo mrene infrastrukmre. Selite se da sistem
za imenovanje domena (Domain Name System, DNS, proitajte odeljak 2.5) ili programi
rutiranja koji menjaju tabele rutiranja (proitajte odeljak 4.6) zahte-vaju bezbednu komunikaciju
izmeu dve strane. Isto vai i za aplikacije upravljanja mreom, stoje tema o kojoj govorimo u
poglavlju 9. Uljez koji bi mogao aktivno da utie, kontrolie ili oteuje DNS pretraivanja i
auriranja [RFC 2535, IETF dnsext 2004], proraune rutiranja [Murphy 2003], ili funkcije
upravljanja mreom [RFC 2574], mogao bi da napravi pravu propast na Internetu.
Poto smo ustanovili okvir, nekoliko najvanijih definicija i potrebu za mrenom
bezbednou, hajde sada da zaronimo u kriptografiju. Dok je upotreba kriptografije u
obezbeivanju tajnosti jasna sama po sebi, uskoro emo videti da ona takode ima centralnu
ulogu i u obezbeivanju autentifikacije, integriteta poruke, neosporavanju i kontroli pristupa -
stoje ini kamenom temeljcem mrene bezbednosti.
8. 2 Principi kriptografije
Iako kriptografija ima dugu istoriju koja datira jo od Julija Cezara (uskoro emo pogledati
takozvanu Cezarovu ifru), savremene kriptografske tehnike, ukljuujui i mnoge od onih koje
se koriste na dananjem Internetu, zasnovane su na dostignuima izposlednjih 30 godina.
Kanova knjiga, The Codebreakers [Kahn 1967] i Sin-

298 POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA

8.2
PRINCIPI KRIPTOGRAFIJE 659!
gova knj iga, The Code Book: The Science of Secrecy from Ancient Egypt to Quanium
Cryotigraphy [Singh 1999], daju fascinantan pogled na dugu istoriju kriptografije. Detaljna (ali
zabavna i itljiva) tehnika diskusija o kriptografiji, posebno sa take gledita mree, nalazi se u
Kaufmanovoj knjizi fKaufman 1995]. Difi u svojoj knjizi [Diffie 1998] ispituje politike i
socijalne aspekte (na primer, privatnost) koji su sada nerazmrsivo isprepletani sa kriptografijom.
Celovita rasprava o kriptografiji sama po sebi zahteva itavu knjigu [Kaufmari 1995; Schneier
1995] pa emo zasada samo dodirnuti njene sutinske aspekte, posebno kada se primenjuju na
dananjem Internetu. Odlina onlajn lokacija je FAQ stranica RSA Labs [RSA FAQ 2002].
Takoe napominjemo da dok e se nae izlaganje u ovom odeljku baviti pre svega upotrebom
kriptografije radi tajnosti, uskoro emo videti da su kriptografske tehnike utkane u
autentifikaciju, integritet poruke, neporecivost i jo mnogo toga.
Kriptografske tehnike dozvoljavaju poiljaocu da maskira podatke tako da uljez ne moe da
dobije nikakvu informaciju iz presremutih podataka. Primalac, naravno, mora da bude u stanju
da obnovi originalne podatke iz maskiranih podataka. Na slici 8.2 ilustrovani su neki od
znaajnih kriptografskih termina.
Pretpostavite sada da Alisa eli da poalje poruku Bobu. Njena poruka u svom originalnom
obliku (na primer, Bob, I love you . Alice")je poznata kao otvoren tekst (plaintext), ili jasan
tekst (cleartext). Alisa ifruje svoju poruku u otvorenom (itljivom) tekstu koristei algoritam
ifrovanja tako da ifrovana poruka, poznata kao ifrovan tekst (ciphertext), svakom uljezu
izgleda neitljivo. Zanimljivo je daje, u mnogim savremenim kriptografskim sistemima,
ukljuujui one koji se koriste na Internetu, sama tehnika ifrovanja poznata - objavljena,
stan-dardizovana i svima raspoloiva (na primer, [RFC 1321; RFC 2437; RFC 2420]), pa ak i
potencijalnom uljezu! Jasno, ako svako zna metod za ifrovanje podataka, onda mora da postoji
neka tajna informacija koja uljeza spreava da deifruje podatke koji se prenose. Ovde nastupaju
kljuevi.
Na slici 8.2, Alisa obezbeduje klju, KA, tj. niz brojeva ili znakova, kao ulaz u algoritam za
ifrovanje. Algoritam za ifrovanje uzima klju i poruku u otvorenom tekstu, m, kao ulaz i pravi
ifrovan tekst kao izlaz. Notacija KJm) odnosi se na ifrovani tekst (ifrovan upotrebom kljua
KA) poruke otvorenog teksta, m. Stvarni algoritam za ifrovanje koji koristi klju KA shvatiete iz
konteksta. Slino tome, Bob e obezbedtti klju, Kg, za algoritam za deifrovanje, koji uzima
ifrovan tekst i Bobov klju kao ulaz i pravi originalan otvoren tekst kao izlaz. Odnosno, ako
Bob prima ifrovanu poruku KA(m), on je deifruje izraunavajui KB(KA(m)) = m, U
simetrinim sistemima kljueva, Alisin i Bobov klju su istovetni i tajni. U javnim sistemima
kljueva, koristi se par kljueva. Jedan od kljueva znaju i Bob i Alisa (u stvari, zna ga ceo
svet). Drugi klju znaju ili Bob ili Alisa (ali ne i oboje). U sledea dva pododeljka, detaljnije
emo razmotriti simetrine i javne sisteme kljueva.

8.2.1 Kriptografija simetrinog kljua
Svi kriptografski algoritmi obuhvataju zamenu jedne stvari drugom, na primer, uzimanje dela
otvorenog teksta a zatim izraunavanje i zamenu odgovarajueg teksta ifrovanim tekstom, sve u
cilju pravljenja ifrovane poruke. Pre nego to prouimo
KRATAK OSVRT
TAKMI TAKMI TAKMI TAKMIENJA U RAZBIJANJU KODOVA ENJA U RAZBIJANJU KODOVA ENJA U RAZBIJANJU KODOVA ENJA U RAZBIJANJU KODOVA
Usvojen prvo od strane Vlade SAD 1977. godine, 56-bilni algoritam standarda za ifrovanje
podataka (Data Encrypti on Standard, DES) jo uvek iroko koriste finansi-I jske slube i druge
industrije irom svoto do bi zatitile osetljjve informacije. Da bi istakla potrebu za jaim
ifrovanjem od postojeeg 56-bitnog standarda, kompanija RSA je bila sponzor niza takmienja u
razbijanju DES-a koji se iroko koristi kako u SAD tako i u meunarodnoj trgovini. Svaki izazov
sastojao se u tome da se deifruje poruka ifrovana pomou 5o-bilnog DES-o u okviru
odvedenog vremena. Razbijai koda su prihvatali izazov iscrpno pretraujui prostor svib
moguih tajnih kljueva. Kao deo takmienja, RSA dodeljuje pobednicima nagradu bd 10.000
USD.
Kompanija RSA je pokrenula izazov u januaru 1997. godine, sa ciljem da pokae kako
standard Vlade SAD za ifrovanje podataka, sa svojim 56-bitnim kljuem, nudi samo
ogranienu zatitu protiv upornog protivnika. Na prvom takmienju pobedio je tim iz Kolorada
koji je otkrio tajni klju za manje od etiri meseca. Od tada, poboljana tehnologija je omoguila
mnogo bra iscrpno pretraivanja. U februaru 1998. godine, organizacija Distributed.Net
pobedila je na takmienju DES Challenge ll-l kompanije RSA u roku od 41 dana, a u julu je
firma Electronic Frontier Foundotron (EFF) pobedila no takmienju DES Challenge 11-2
rozbivi DES poruku za 56 sati.
U januaru 1999. godine, Distributed.Net, svelska koalicija raunarskih entuzijasta, radila je
sa Deep Crackom", posebno konstruisanim superraunarom firme EFF i mreom irom sveta
od skoro 100000 PC-ja na Internetu, da bi pobedila na takmienju DES Challenge III u
rekordnom roku od 22 sata i 15 minuta. EFF-ov. Deep Crack" i raunari Distributed.Net su
ispitivali brzinom od 245 milijardi kljueva u sekundi kada je klju bio pronaeni

8.2 . PRINCIPI KRIPTOGRAFIJE 299 299 299 299

savremen kriptografski sistem zasnovan na kljuu, hajde prvo da prouimo veoma star
jednostavan algoritam simetrinog kljua koji se pripisuje Juliju Cezaru, poznat kao Cezarova
ifra.
Za engleski tekst, Cezarova ifra funkcionie uzimanjem svakog slova u poruci otvorenog
teksta i zamenom tog slova onim koje je k slova dalje u azbuci (dozvoljavajui povratak na
poetak, to jest da posle slova ,,z" sledi slovo ,,a"). Na primer, ako je k = 3, onda slovo ,,a" u
otvorenom tekstu postaje ,,d" u ifrovanom tekstu; ,,b" u otvorenom tekstu postaje ,,e" u
ifrovanom tekstu itd. Ovde vrednost k slui kao klju. Kao primer, poruka otvorenog teksta
bob, i love you . alice" u ifrovanom tekstu postaje ere, 1 oryhbrx. dolfh". Mada ifrovan tekst
zaista izgleda besmisleno, ne bi bilo potrebno mnogo vremena da se razbije kod ako biste znali
da je upotrebljena Cezarova ifra, zato to postoji samo 25 moguih vrednosti kljua.
Poboljanje Cezarove ifre je jenoazbuna ifra, gde se takode jedno slovo azbuke
zamenjuje drugim. Meutim, umesto da se zamena vri u skladu sa nekim pravilnim uzorkom
(na primer, zamena sa pomerajem k za sva slova), svako slovo moe biti zamenjeno bilo kojim
drugim slovom, sve dok svako slovo ima jedinstveno slovo koje ga zamenjuje i obrnuto. Pravilo
zamene na slici 8,3 prikazuje jedno od moguih pravila za ifrovanje otvorenog teksta.
Poruka otvorenog teksta bob, i love you. alice" postaje ,,nkn, s gktc wky. mgsbc". Dakle,
kao i u sluaju Cezarove ifre, ovo izgleda nerazumljivo. Jenoazbuna ifra bi izgledala bolje od
Cezarove ifre utoliko to ima 261 (reda veliine IO
26
) a ne samo 25 moguih uparivanja. Pristup
grube sile, tj. pokuaja sa svih IO
26
moguih uparivanja zahtevao bi suvie mnogo rada da bi bio
izvodljiv nain za razbijanje algoritma ifrovanja i deifrovanje poruke. Meutim, statistika
analiza otvorenog teksta, na primer, znanje da su slova ,,e" i ,,t" ona koja se najee pojavljuju u
uobiajenom engleskom tekstu (13 i 9 procenata pojavljivanja), i znanje da su neke pojave po
dva ili tri slova zajedno posebno este (na primer, ,,in", ,,it", ,,the", ion", ,,ing," itd.) ine
razbijanje ovog koda relativno lakim. Ako uljez ima neko saznanje o moguem sadraju teksta,
onda je jo lake razbiti kod. Na primer, ako je uljez Trudi, Bobova supruga, i ako ona sumnja da
je Bob vara sa Alisom, onda bi ona mogla da posumnja da se imena bob" i alice" pojavljuju u
tekstu. Ako bi Trudi znala da se ta imena sigurno pojavljuju u ifrovanom tekstu i imala kopiju
gornjeg primera ifrovanog teksta, ona bi onda odmah mogla da odredi sedam od 26 uparivanja
slova, zahtevajui IO
9
manje mogunosti za proveravanje metodom grube sile. Zaista, ako bi
Trudi sumnjala daje Bob vara, ona bi mogla da oekuje da nade i druge odabrane rei u poruci.
Prilikom razmatranja koliko bi Trudi bilo lako da razbije Bobovu i Alisinu emu ifrovanja,
moemo da razlikujemo tri razliita scenarija, zavisno od toga koliko informacija uljez
poseduje.
Napad samo na ifrovan tekst. U nekim sluajevima, uljez moe da ima pristup samo na
presretnuti ifrovani tekst, bez ikakve sigurne informacije o sadraju poruke otvorenog
teksta. Videli smo kako statistika analiza moe da pomogne u ovakvom napadu samo na
ifrovani tekst.
Napad poznatim otvorenim tekstom. Videli smo da ako bi Trudi na neki nain sigumo znala
da su se bob" i ,,al ice" pojavili u poruci ifrovanog teksta, ona bi onda mogla da odredi
uparivanja (otvoren tekst, ifrovan tekst) za slova a, 1, i, c, e, b and o. Trudi bi takode mogla
da ima dovoljno sree daje zapisala sve prenose ifrovanog teksta i da je pronala Bobovu
sopstvenu deifrovanu verziju jednog od prenosa, zapisanu na paretu hartije. Kada uljez zna
neka od uparivanja (otvoren lekst, ifrovan tekst), mi to zovemo napadom na emu ifrovanja
poznatim otvorenim tekstom.
Napad izabranim otvorenim tekstom. U napadu izabranim otvorenim tekstom, uljez moe da
biro poruku otvorenog teksta i dobije njen odgovarajui oblik u ifrovanom teksni. Za
jednostavne algoritme ifrovanja koje smo do sada videli, ako bi Trudi mogla da navede
Alisu da poalje poruku, The quick brown f ox j umps over the- lazy dog", ona bi mogla u
potpunosti da razbije emu ifrovanja. Uskoro emo videti da za sloenije tehnike ifrovanja,
napad izabranim otvorenim tekstom ne znai obavezno da tehnika ifrovanja moe da se
razbije.
Pre pet stotina godina, pronaene su tehnike poboljavanja monoazbunog ifrovanja, poznate
kao vieazbuno ifrovanje. Ideja na kojoj se zasniva vieazbuno ifrovanje je da se koristi vie
jednoazbunih ifri, sa posebnom jednoazbunom ifrom za kodovanje slova na posebnoj poziciji
u poruci otvorenog teksta. Dakle, isto slovo, koje se pojavljuje na razliitim pozicijama u poruci
otvorenog teksta moglo bi da bude razliito kodovano. Primer vieazbune eme ifrovanja
prikazan je na slici 8.4. Ono ima dve razliite Cezarove ifre (sa k = 5 i k = 19), prikazane kao
redovi na slici 8.4. Moemo izabrati da koristimo te dve Cezarove ifre, C, i C2, po ponavljajuem
uzorku C|( C2, C2, C,, C;. Odnosno, prvo slovo otvorenog teksta e biti kodovano koristei C,,
drugo i tree koristei CT etvrto koristei Cp i peto koristei Cr Uzorak se onda ponavlja, pa se
esto slovo koduje koristei C,, sedmo pomou C2 itd. Poruka otvorenog teksta bob, i love you.
"je tako ifrovana u gnu, n etox dhz" Zapazile daje prvo ,,b" u poruci otvorenog teksta ifro-vano
koristei C,, dok je drugo ,,b" ifrovano koristei C2. U ovom primeru, klju" za ifrovanje i
deifrovanje je poznavanje dva Cezarova kljua (k = 5, k = 19) i uzorka C(, C2t C2, C]p CT


8.2 . PRINCIPI KRIPTOGRAFIJE
663 663 663 663
i
Standard za ifrovanje podataka (DES) i napredni standard za ifrovanje (AES)
Hajde da se sada brzo prebacimo u moderna vremena i ispitamo Standard za ifrovanje podataka
(DES) [NIST 1993], standard ifrovanja sa simetrinim kljuem, objavljen 1977. godine i
najskorije auriran 1993. godine od strane Nacionalnog biroa SAD za standarde, za komercijalnu
i javnu upotrebu Vlade SAD. DES ifruje otvoreni tekst u 64-bitnim krikama" koristei
64-bitni klju. U stvari, osam od tih 64 bita kljua su bitovi neparne pamosti (postoji po jedan bit
pamosti za svaki od osam bajtova), pa je klju DES stvarne duine od 56 bitova. Nacionalni
institut za standarde i tehnologiju (naslednik Nacionalnog biroa za standarde) ovako postavlja
cilj DES-a: Cilj je da se potpuno ifruju podaci i klju, tako da svaki bit ifrovanog teksta zavisi
od svakog bita podataka i svakog bita kljua. . . . Sa dobrim algoritmom, ne bi trebalo da bude
nikakve korelacije izmeu ifrovanog teksta i bilo originalnih podataka, bilo kljua". [NIST
1999].
Osnovni rad DES-a ilustrovan je na slici 8.5. U naoj diskusiji, napraviemo pregled rada
DES-a, ostavljajui osnovne detalje i detalje na nivou bita (ima ih mnogo) drugim izvorima
[Kaufman 1995; Schneier 1995]. najer u svojoj knjizi [Schneier 1995] obuhvata i C
implementaciju. DES se sastoji od dva permutaciona koraka (prvi i poslednji korak algoritma), u
kojima se svih 64 bita permutuju, sa 16 istovetnih rundi" rada izmeu. Rad svake runde je
identian, tako to se uzme izlaz prethodne runde kao ulaz. Za vreme svake runde, 32 bita ulaza
krajnje desno se pomeraju na 32 bita izlaza levo. Ceo 64-bitni ulaz u /-tu rundu i 48-bitni klju za
i'-tu rundu (izveden iz veeg 56-bitnog DES kljua) uzimaju se kao ulaz funkcije koja obuhvata
irenje etvorobitnih ulaznih kriki na Sestobitne krike, izvravanje operacije iskljuivo ILI sa
proirenim estobitnim krikama 48-bitnog kljua Ki, operaciju supstitucije i jo jednu operaciju
iskljuivo ILI sa 32 bita ulaza krajnje levo; vie detalja o tome proitajte u knjizi [Kaufman 1995;
Schneier 1995]. Rezultujui 32-bitni izlaz funkcije se onda koristi kao 32 bita krajnje desno
64-bitnog izlaza runde, kao to je prikazano na slici 8.5. Deifrovanje radi obrnutim izvravanjem
operacija algoritma.
Koliko dobro radi DES? Koliko je bezbedan? To ne moe niko da kae sa sigurnou
[Kaufman 1995]. U 1997. godini, kompanija za mrenu bezbednost, RSA Data Security Inc.,
pokrenula je takmienje DES Challenge za razbijanje" (deko-dovanje) kratke reenice koju je
ifrovala koristei 56-bitni DES. Neifrovana reenica (Strong cryptograpby makes the worid a
safer place.") bila je utvrena za manje od etiri meseca od strane tima koji je koristio
dobrovoljce irom Interneta da sistematski istrauju prostor kljueva. Tim je doao po nagradu
od 10000 USD posle pretraivanja samo etvrtine prostora kljueva - oko 18 kva-driliona
kljueva [RSA Challenge 2002]. Najnoviji DES Challenge III u 1999. godini bio je osvojen u
rekordnom vremenu od neto malo vie od 22 sata, sa mreom dobrovoljaca i raunarom
specijalne namene koji je bio izgraen za manje od 250000 USD (sa nadimkom Deep Crack") i
dokumentovan onlajn [EFF 1999].

664 664 664 664
POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA

Trebalo bi takoe da napomenemo da se na prethodni opis bavio samo ifrova-njem
64-bitnih koliina podataka. Kada se ifruju due poruke, to je obino sluaj, DES se esto
koristi sa tehnikom koja se zove ulanavanje ifrovanih blokova, u kojoj se ifrovana
verzija_/-te 64-bitne koliine podataka podvrgava operaciji iskljuivo ILI sa ( j + l)-vom
jedinicom podataka pre nego to se ifruje ( J + I )-va jedinica podataka,
Ako se 56-bitni DES smatra suvie nesigurnim, moemo jednostavno da pokrenemo
56-bitni algoritam vie puta, uzimajui 64-bitni izlaz iz jedne iteracije DES-a kao ulaz u sledeu
iteraciju DES-a, koristei svaki put razliit klju. Na primer, tro-struki-DES (3DES) je standard
Vlade SAD [NIST 1999b] koji zamenjuje upotrebu DES-a, koji iezava i dozvoljen je samo u
nasleenim sistemima. U jednoj konfiguraciji, 3DES prvo pokree DES algoritam za ifrovanje
podataka koristei prvi 56-bitni klju, zatim pokree DES algoritam za deifrovanje izlaza prve
runde ifrovanja koristei drugi klju i najzad i konano pokree DES algoritam za ifrovanje
izlaza druge runde koristei trei klju. 3DES je bio predloen kao standard za ifrovanje
protokola od take do take (PPP) [RFC 2420] za sloj veze podataka (proitajte odeljak 5.8).
Detaljna diskusija duina kljueva i procenjenog vremena i budeta koji je potreban da bi se
razbio DES moe da se pronae u knjizi [Blae 1996].
U novembru 2001. godine, NIST ne najavio naslednika DES-a: napredni standard za
ifrovanje (AdvancedEncryption Standard, AES) [NIST 2001, Danielvan 2001], takoe
poznatog i kao Rijndelov algoritam [Daemen 2000]. AES je algoritam simetrinog kljua koji
obrauje podatke u 128-bitnim blokovima i moe da radi sa kljuevima koji su duine od 128,
192 i 256 bitova. NIST procenjuje da bi maini koja bi mogla da razbije 56-bitni DES u jednoj
sekundi (odnosno; da pokua brzinu od 2
55
kljueva u sekundi) trebalo priblino 149 triliona
godina da razbije 128-bitni AES klju.

8.2.2 ifrovanje javnim kljuem
Za vie od 2000 godina (od vremena Cezarove ifre do 1970-ih godina), ifrovana komunikacija
zahtevala je da dve strane koje komuniciraju dele zajedniku tajnu - simetrini klju koji koriste
za ifrovanje i deifrovanje. Jedna od tekoa ovakvog pristupa je da dve strane nekako moraju
da se sporazumeju o deljenom kljuu; ali da bi se to uradilo, potrebna je (po pretpostavci
sigurna) komunikacija! Moda bi strane mogle da se prvo sretnu i lino sporazumeju o kljuu (na
primer, dva Cezarova centuriona bi mogla da se sretnu u rimskim kupatilima) i posle toga
ifrovano komuniciraju. Meutim, u umreenom svetu, moe da se desi da strane koje
komuniciraju nikada da ne razgovaraju, izuzev preko mree. Da li je mogue da dve strane ifro-
vano komuniciraju bez posedovanja deljenog tajnog kljua koji je unapred poznat? U 1976.
godini, Difi i Helman [Diffie 1976] su pokazali algoritam (poznat kao Dif-fie-Hellmanova
razmena kljua) koji radi ba to - stoje radikalno drugaiji i neodoljivo elegantan pristup sigurnoj
komunikaciji koji je doveo do razvoja dananjih kriptografskih sistema sa javnim kljuevima.
Uskoro emo videti da kriptografski
sistemi sa javnim kljuevima takoe imaju vie divnih osobina koje ih ine korisnim ne samo za
ifrovanje, nego i za autentifikaciju i digitalne potpise. Zanimljivo je da je nedavno dolo do
ideja slinih onima u knjigama [Diffie 1976] i [RSA 1978] koje su nezavisno razvijene u ranim
1970-im godinama u nizu tajnih izvetaja istraivaa u grupi Communications-Electromcs
Securitv Group u Ujedinjenom kraljevstvu [EIlis 1987]. Kao to je obino sluaj, velike ideje
mogu da se nezavisno pojave na vie mesta; na svu sreu, napredak javnih kljueva dogodio se
ne samo u privatnom, nego i u javnom domenu.
Upotreba kriptografije javnim kljuem svodi se na sasvim jednostavnu zamisao. Pretpostavite
da Alisa eli da komunicira sa Bobom, Kao to je prikazano na slici 8.6, umesto da Bob i Alisa
dele jedan tajni klju (kao u sluaju sistema simetrinih kljueva), Bob (primalac Alisinih poruka)
ima dva kljua-javni klju koji je raspoloiv svakome na svetu (ukljuujui i Trudi, uljeza) i
privatni klju koji je poznat samo njemu. Koristiemo notaciju KB* i KB' da bismo se pozivali na
Bobov javni i privatni klju, tim redom. Da bi komunicirala sa Bobom, Alisa prvo nabavlja njegov
javni klju. Alisa zatim ifruje svoju poniku za Boba, m, koristei Bobov javni klju i poznat (na
primer, standardizovani) algoritam za ifrovanje; odnosno, Alisa izraunava KB(m). Bob prima
Alisinu ifrovanu poruku i koristi svoj privatni klju i poznat (na primer, standardizovani)
algoritam za deifrovanje da bi deifrovao Alisinu ifrovanu poruku. Odnosno, Bob izraunava
KB(KB*(m)). Videemo dalje u tekstu da postoje algoritmi za ifrovanje/deifrovanje i tehnike za
biranje javnih i privatnih kljueva takvi da je KB(KB
r
(m)) = m; odnosno, primenjujui Bobov javni
klju, KB, na poruku, m (da bi se dobilo KB*(m)), a zatim primenjujui Bobov privatni klju, Kg,na
ifrovanu verziju m(odnosno, izraunavanjemKB(KB*(m))) dobijamo opet m. To je izvanredan
rezultat! Na taj nain, Alisa moe da koristi Bobov javno raspoloiv klju da bi poslala tajnu
poruku Bobu, a da nijedna od njih ne mora

8.2 - PRINCIPI KRIPTOGRAFIJE 667J

da distribuira bilo kakve tajne kljueve! Uskoro emo videti da moemo da zame-nimo
ifrovanje javnim i privatnim kljuem i da dobijemo isti izvanredan rezultat, odnosno, Kg
(Kg*(m)) = K * (KB'(m))= m.
Dakle, upotreba kriptografije javnim kljuem je jednostavna zamisao. Meutim, tu se mogu
javiti dva problema. Prvi problem je, da mada uljez koji presree Alisinu ifrovanu poruku vidi
samo neto nerazumljivo, on zna i klju (Bobov javni klju, koji moe da vidi ceo svet) i
algoritam koji je Alisa upotrebila za ifrovanje. Trudi na taj nain moe da preduzme napad
izabranim otvorenim tekstom, koristei poznat standardizovan algoritam za ifrovanje i Bobov
javno raspoloiv klju za ifrovanje, da bi deifrovala svaku poruku koju izabere! Trudi bi sasvim
lepo mogla da pokua da, na primer, ifruje poruke ili delove poruka za koje sumnja da bi Alisa
mogla da ih alje. Jasno, ako se radi kriptografija javnim kljuem, izbor kljua i
ifrovanje/deifrovanje mora da se uradi na takav nain daje uljezu nemogue (ili, u najmanju
ruku, toliko teko daje skoro nemogue) da ili odredi Bobov privatni klju ili da nekako drugaije
deifruje ili pogodi Alisinu poruku Bobu. Drugi potencijalni problem je to to, s obzirom na to da
je Bobov klju za ifrovanje javan, svako moe da poalje ifrovanu poruku Bobu, ukljuujui
Alisu ili nekog ko tvrdi da je Alisa. U sluaju jednog deljenog tajnog kljua, injenica da
poiljalac zna tajni klju implicitno identifikuje poiljaoca primaocu. Meutim, u sluaju
kriptografije javnim kljuem, to vie nije tano, zato to svako moe da poalje, ifrovanu poruku
Bobu koristei Bobov javno raspoloiv klju. Da bi se poiljalac povezao jedinstveno sa porukom
koju alje potreban je digitalni potpis, to je tema koju emo prouiti u odeljku 8.4,
Iako ima mnogo algoritama i kljueva koji reavaju ova pitanja, algoritam RSA (nazvan po
svojim pronalazaima, Ronu Rivestu, Adiju Shamiru i Leonardu Adlemanu) postao je skoro
sinonim za kriptografiju javnim kljuem. Hajde najpre da vidimo kako RSA radi, a zatim
ispitajmo zato to radi. Pretpostavite da Bob eli da prima ifrovane poruke, kao Stoje prikazano
na slici 8.6. Postoje dve meusobno povezane komponente algoritma RSA;
Izbor javnog i privatnog kljua
Algoritam za ifrovanje i deifrovanje
Da bi odabrao javni i privatni klju, Bob mora da izvede sledee postupke:
1. Odabrati dva velika prosta broja, p i q. Koliko bi p i q trebalo da budu veliki? to su
vrednosti vee, to je tee razbiti RSA, ali je potrebno vie vremena da bi se izvrilo
ifrovanje i deifrovanje. RSA Laboratorije preporuuju da proizvod p i q bude reda 1024
bita za profesionalnu upotrebu (npr. u kompanijama) i 768 bitova za rad sa manje vrednim
informacijama" [RSA Key 2004] (to dovodi do pitanja zastoje kompanijska upotreba toliko
znaajnija od ostale upotrebe!). O tome kako se pronalaze veliki prosti brojevi, proitajte
knjigu [Caldv/ell 2004].
2. Izraunati n = pq\z = {p~ l)(g -1).
3. Izabrati broj, e, manji od n, koji nema zajednikih inilaca (izuzev 1) sa brojem z. (U ovom
sluaju, za e i z se kae da su relativno prosti.) Slovo e se koristi zato to e ta vrednost biti
koriena u ifrovanju.
4. Pronai broj, d, takav daje ed-1 tano deljivo (odnosno, bez ostatka) saz. Slovo ,/f' je
upotrebljeno zato to e se ta vrednost koristiti u deifrovanju. Drugaije reeno, za dato e,
biramo d tako da celobrojni ostatak kada se ed podeli sa z iznosi 1. (Celobrojni ostatak kada
se ceo broj x podeli celim brojem n, oznaava se sa x mod ).
5. Javni klju koji Bob stavlja na raspolaganje elom svetu, K8
+
, je par brojeva (n,e)\ njegov
privatni klju, KB~, je par brojeva (n,d).
Alisino ifrovanje i Bobovo deifrovanje se obavljaju na sledei nain:
Pretpostavite da Alisa eli da poalje Bobu uzorak bitova ili broj, m, takav daje m< n. Da bi
ifrovala, Alisa obavlja operaciju eksponenciranja, m , a zatim izraunava celobrojni
ostatak kada se m
e
podeli sa n. Dakle, ifrovana vrednost, c, poruke otvorenog teksta, m, koji
Alisa alje je
c = nf mod n
Da bi deifrovao poruku ifrovanog teksta, c, Bob izraunava
m = * mod n to zahteva
upotrebu njegovog privatnog kljua (n,).
Kao jednostavan primer algoritma RSA, pretpostavite da Bob bira p = 5 i q = 7. (Iskreno
govorei, te vrednosti su suvie male da bi bile sigurne.) Onda je n = 35 i z = 24. Bob bira e = 5,
zato to 5 i 24 nemaju zajednikih inilaca. Najzad, Bob bira d = 29, zato stoje 5'29 -1 (odnosno,
ed - 1) tano deljivo sa 24. Bob ini dve vrednosti javnim, n = 35 i e = 5, a zadrava vrednost d =
29 kao tajnu. Posmatrajui ove dve javne vrednosti, pretpostavite da Alisa sada eli da poalje
Bobu slova 1", o", v" i ,,e". Interpretirajui svako slovo kao broj izmeu 1 i 26 (gde je a" 1,
a ,,z" 26), Alisa i Bob izvravaju ifrovanje i deifrovanje prikazano u tabelama 8.1 and 8.2, tim
redom.
Imajui u vidu daje pojednostavljeni primeru tabelama 8.1 i 8.2 ve proizveo neke izuzetno
velike brojeve, i s obzirom na to da znamo da smo ranije videli kako bi p i q trebalo da budu
duine vie stotina bitova, dolazimo do nekih praktinih pitanja u pogledu algoritma RSA. Kako
se biraju veliki prosti brojevi? Kako se biraju e i dl Kako se vri eksponenciranje sa velikim
brojevima? Diskusija o tim znaajnim pitanjima je izvan domena ove knjige; proitajte knjigu
[Kaufman 1995] i reference koje se tamo nalaze da biste saznali vie pojedinosti o tome.
Ovde samo napominjemo da je RSA eksponenciranje proces koji troi dosta vremena. S
druge strane, DES je najmanje 100 puta bri u softveru i izmeu 1000


i 10000 puta bri u hardveru [RSA Fast 200.4]. Kao rezultat, RSA se u praksi esto koristi u
kombinaciji sa DES-om ili AES-om. Na primer, ako Alisa eli da poalje Bobu veliku koliinu
ifrovanih podataka velikom brzinom, ona bi trebalo da uradi sledee. Alisa prvo bira DES klju
koji e se upotrebiti za ifrovanje samih podataka; taj klju se ponekad zove klju sesije, Ks.
Alisa mora da informie Boba o kljuu sesije, zato Stoje to deljeni simetrini klju koji e oni
koristiti za DES. Alisa dakle ifruje vrednost kljua sesije koristei Bobov javni RSA klju,
odnosno, izraunava c = (K^
e
mod . Bob prima RSA-ifrovan klju sesije, c, i deifruje ga da bi
dobio klju sesije, Ks Bob sada zna klju sesije koji e Alisa koristiti za prenos DES-ifrovanih
podataka.

Kako RSA radi?
Gore opisano RSA ifrovanje/deifrovanje izgleda kao prava magija. Zato bismo, kada
primenimo najpre algoritam za ifrovanje a zatim algoritam za deifrovanje, rekonstruisali
originalnu poruku? Da bismo razumeli kako RSA radi, bie potrebno da izvedemo aritmetike
operacije koristei aritmetiku modulo-. U modularnoj
aritmetici, izvravamo uobiajene operacije sabiranja, mnoenja i eksponenciranja. Meutim,
rezultat svake operacije se zamenjuje celobrojnim ostatkom koji preostaje kada se rezultat
podeli sa n. Uzeemo da je n = pg, gde su p i q veliki prosti brojevi koji se koriste u RSA
algoritmu.
Setite se da kod RSA ifrovanja, poruka (predstavljena celim brojem), m, prvo
eksponencira na stepen e koristei aritmetiku modulo-, Deifrovanje se vri podizanjem te
vrednosti na stepen d, koristei opet aritmetiku modulo-. Rezultat postupka ifrovanja praenog
postupkom deifrovanja je zato (m
e
)
d
. Hajde da sada vidimo ta moe da se kae o ovoj veliini.
Imamo:
(V/mod = m^mod
Iako pokuavamo da uklonimo neto od magije" u radu algoritma RSA, ovde e biti
potrebno da iskoristimo jedan prilino magian rezultat iz teorije brojeva. Naroito e nam
trebati rezultat koji kae da ako supin prosti brojevi, i ako je = pqt ondaje#>'mod isto to
\x
<ymod
(p-V(i- W mod n [Kaufman 1995]. Primenjujui ovaj rezultat, imamo
(m
c
)
d
mod n = m<
ud
"
>OD

(
P" M'
X))
mod n
Ali, setite se da biramo e i d tako da je ed - 1 tano deljivo (bez ostatka) sa (p - l)(q - 1), ili,
ekvivalentno tome, daje ed deljivo sa (p - l)(q - 1) sa ostatkom 1, pa je na taj nain ed mod (p -
l)(q - l) = 1. To nam daje
(m
c
)
d
mod n = m
[
mod = m
odnosno,
(m
e
)
d
mod n = m
To je rezultat kome smo se nadali! Prvo eksponenciranjem na stepen od e (odnosno,
ifrovanjem) a zatim eksponenciranjem na stepen od d (odnosno, deifrova-njem), dobijamo
originalnu vrednost, m. Jo bolja od toga jeste injenica da ako prvo eksponenciramo na stepen
od d, a zatim eksponenciramo na vrednost od e - odnosno, obmemo redosled ifrovanja i
deifrovanja, izvodei prvo operaciju deifrovanja, a zatim primenjujui operaciju ifrovanja -
takode dobijamo originalnu vrednost, m\ (Dokaz ovog rezultata sledi iz potpuno istog
rezonovanja kao u prethodnom delu teksta.) Uskoro emo videti da e nam ova divna osobina
algoritma RSA,
(m
e
)
d
mod = m = (m
d
)
e
mod n
biti veoma korisna.
Bezbednost RSA oslanja se na injenicu da he postoje poznati algoritmi za brzo
faktorisanje broja, u ovom sluaju javne vrednosti n, na proste brojeve p i q. Ako bi neko znao p
i g, onda bi uz datu javnu vrednost e, mogao lako da izrauna tajni klju, d. S druge strane, ne
zna se da li postoje ili ne postoje brzi algoritmi za faktorisanje broja, i u tom smislu bezbednost
RSA nije garantovana".
t

8.3 AUTENTIFIKACIJA
671 671 671 671
8. 3 Autentifikacija
Autentifikacija je proces dokazivanja identiteta jedne osobe drugoj osobi. Kao ljudi,
autentifikujemo jedan drugoga na mnogo naina: prepoznajemo jedni drugima lica kada se
sretnemo, prepoznajemo jedni drugima glasove preko telefona, autenti-fikuje nas carinik koji nas
proverava u odnosu na sliku u pasou.
U ovom odeljku razmatramo kako jedna sirana moe da autentifikuje drugu, kada one
komuniciraju preko mree. Usredsrediemo se na autentifikovanje ive" strane, u trenutku kada
se komunikacija stvarno dogaa. Videemo daje to malo drugaiji problem od dokazivanja da je
poruka, primljena u nekom trenutku u prolosti (na primer, daje mogla da se arhivira), zaista
dola od onoga koje tvrdio daje poiljalac. Ovaj poslednji problem zove se problem digitalnog
potpisa, kojeg emo objasniti u odeljku 8.4.
Kada izvravaju autentiftkaciju preko mree, strane u komunikaciji ne mogu da se oslone na
biometrijske informacije, kao to je vizuelna pojava ili uzorak glasa. Zaista, videemo u kasnijim
studijama primera da mreni elementi, kao to su ruteri i procesi klijent/server, esto moraju da
autentifikuju jedan drugoga, Ovde autentifikacija mora da se uradi samo na osnovu poruka i
podataka razmenjenih u okviru protokola autentifikacije. Uobiajeno je da se, protokol
autentifikacije izvri pre nego to dve strane koje komuniciraju pokrenu neki drugi protokol (na
primer, protokol pouzdanog prenosa, protokol za razmenu tabela rutiranja ili protokol za
elektronsku potu). Protokol autentifikacije prvo ustanovljava identitete strana na obostrano
zadovoljstvo; samo posle autentifikacije strane mogu da preu na posao koji ih oekuje.
Kao u sluaju razvoja naeg protokola za pouzdan prenos podataka (reliable data transfer,
rdt) u poglavlju 3, otkriemo daje ovde pouno razviti razliite verzije protokola za
autentifikaciju, koji emo zvati ap (autentifikacioni protokol") i razmatrati svaku verziju kako
napredujemo dalje u izlaganju. (Ako volite ovakav postepen razvoj dizajna, mogli biste takoe
proitati knjigu [Bryant 1988], u kojoj se prepriava izmiljen razgovor izmeu dizajnera i
sistema za autentifikaciju otvorene mree, i njihovo otkrie mnogih pitanja u vezi sa tim.)
Pretpostavimo da Alisa treba da se autentifikuje Bobu.

8-3.1 Autentifikacioni protokol apl.O
Moda je najjednostavniji autentifikacioni protokol koji moemo da zamislimo onaj u kom Alisa
prosto alje poruku Bobu u kojoj kae daje ona Alisa. Taj protokol je prikazan na slici 8.7. Ovde
je greka oigledna - nema naina da Bob stvarno zna da je osoba koja je poslala poruku Ja sam
Alisa" zaista Alisa. Na primer, Trudi (uljez) bi mogla takode da poalje takvu poruku.
8.3.2 Autentifikacioni protokol ap2.0
U sluaju da Alisa ima dobro poznatu mrenu adresu (na primer, IP adresu) sa koje ona uvek
komunicira, Bob bi mogao da pokua da autentifikuje Alisu proveravajui da izvorna adresa na
IP datagramu koji nosi poruku o autentifikaciji odgovara Ali-sinoj dobro poznatoj adresi. Ako je
tako, onda bi Alisa bila autentifikovana. To bi moglo da zaustavi veoma naivnog uljeza da se
predstavlja kao Alisa. Ali, to ne bi zaustavilo odlunog studenta koji ita ovu knjigu ili jo
mnogo drugih ljudi!
S obzirom na to da smo do sada prouili i mreni sloj i sloj linka podataka, znamo da nije
tako teko napraviti IP datagram (na primer, ako smo imali pristup kodu operativnog sistema i
mogli da izgradimo sopstveno jezgro operativnog sistema, kao u sluaju Linuxa i nekoliko
drugih besplatno raspoloivih operativnih sistema), staviti u IP datagram bilo kakvu IP adresu
izvora (na primer, Alisinu dobro poznatu IP adresu) i poslati datagram preko protokola sloja
linka na ruter prvog skoka. Odatle pa nadalje, netano izvorno adresiran datagram bi revnosno
bio pro-sleen Bobu. Ovaj pristup, prikazan na slici 8.8, predstavlja oblik IP obmane, veoma
dobro poznat bezbednosni napad koji emo detaljnije razmatrati u odeljku 8.7. IP obmana moe
da se izbegne ako je Trudin ruter prvog skoka konfigurisan da prosleuje samo datagrame koji
sadre Trudinu IP izvornu adresu [RFC 2827]. Meutim, ova sposobnost nije uvek prisutna niti
se obavezno primenjuje. Bob bi zato bio glup ako bi pretpostavio daje Trudin upravnik mree
(koji bi mogla da bude i sama Trudi) konfigurisao njen ruter prvog skoka da prosleuje samo one
datagrame koji su adresirani na odgovarajui nain.

J672
POGLAVLJE 8 BEZBEDNOST U U U U RAUNARSKIM MREAMA
8.3 . AUTENTIFIKACIJA 673
Jedan od klasinih pristupa autentifikaciji je da se koristi tajna lozinka. Svi koristimo PTN-ove
da bismo se identifikovali bankomatima i lozinke prijavljivanja za operativne sisteme. Lozinka
je deljena rajna izmeu onog ko autentifikuje i osobe koja se autentifikuje. U odeljku 2.2. smo
videli da HTTP koristi autentifikacionu emu zasnovanu na lozinci. Telnet i FTP takoe koriste
autentifikaciju pomou lozinke. U protokolu ap3.0, Alisa zato alje svoju tajnu lozinku Bobu,
kao Stoje prikazano na slici 8.9.
S obzirom na to da se lozinke tako iroko koriste, mogli bismo da pomislimo kako je
protokol ap3.0 prilino bezbedan. Meutim, ne bismo bili u pravu! Ovde je jasna bezbednosna
greka. Ako Trudi prislukuje Alisinu komunikaciju, ona bi onda mogla da sazna njenu lozinku.
Da ne biste pomislili kako je to neverovatno, razmotrite injenicu da kada se neko obraa preko
Telneta drugoj maini i prijavljuje se, lozinka za prijavljivanje se neifrovano alje Telnet
serveru. Neko povezan sa Telnet klijentom ili na serverovom LAN-u mogao bi da onjui"
(proita i zapie) sve pakete koji se prenose preko LAN-a i tako ukrade lozinku za prijavljivanje.
U stvari, to je dobro poznat pristup za krau lozinki (proitajte, na primer, knjigu [Jimenez
1 997]). Takva pretnja je oigledno veoma realna, pa je jasno da ap3.0 ne bi obavio posao.
Kada smo prouili prethodni odeljak o kriptografiji, naa sledea ideja za popravljanje protokola
ap3.0 je prirodno da upotrebimo ifrovanje kako bismo ifrovali lozinku. ifrovanjem lozinke,
moemo da spreimo Trudi da sazna Alisinu lozinku. Ako pretpostavimo da Alisa i Bob dele
simetrini tajni klju, KA2gi onda Alisa moe da ifruje lozinku i poalje Bobu svoju
identifikacionu poruku, I am Alice" i svoju ifrovanu lozinku. Bob onda deifruje lozinku i, pod
pretpostavkom da je
lozinka tana, autentifikuje Alisu. Bob se prilikom autentifikacije Alise osea komotno, zato to
Alisa ne samo da zna lozinku, nego poznaje i deljeni tajni klju koji je potreban da bi se
ifrovala lozinka. Nazovimo ovaj protokol ap3.1. Dok je tano da ap3.1 spreava Trudi da sazna
Alisinu lozinku, upotreba kriptografije ovde ne reava problem autentmkacije. Na Boba je
izvren takozvani napad reprodukcije: Trudi treba samo da prislukuje Alisinu komunikaciju,
zapie ifrovanu verziju lozinke i zatim kasnije reprodukuje ifrovanu verziju lozinke Bobu,
kako bi se pretvarala daje ona Alisa. Upotreba ifrovane lozinke u protokolu ap3.i situaciju ne
ini bitno drugaijom od one za protokol ap3.0 na slici 8.9.

Problem sa protokolom ap3.J je u tome to se stalno koristi ista lozinka. Jedan nain da se taj
problem rei bio bi da se svaki put koristi drukija lozinka. Alisa i Bob bi mogli da se dogovore
o sekvenci lozinki (ili o algoritmu za generisanje lozinki) i da koriste svaku lozinku samo
jednom, u sekvenci. Ta ideja se koristi u sistemu S/KY [RFC 1760], koji usvaja Lamportov
pristup za generisanje sekvence lozinki (Lamport 1983]. .'
?r
Ali, umesto da se ovde zadovoljimo tim reenjem, hajde da razmotrimo optiji pristup za
borbu protiv napada reprodukcije. Scenario neuspeha sa slike 8.9 posle-

8.3 . AUTENTIFIKACIJA
675 675 675 675

dica je injenice da Bob ne bi mogao da razlikuje originalnu Alisinu autentifika-ciju od kasnije
reprodukcije Alisine originalne autentifikacije. Odnosno, Bob ne bi mogao da kae da li je Alisa
bila uivo" (to jest, da li je stvarno bila na drugom kraju konekcije) ili da li su poruke koje je on
primao bile reprodukcija snimljene prethodne Alisine autentifikacije. italac sa velikom (veoma
velikom) sposobnou opaanja setie se da je TCP protokol sa trostrukom sinhronizacijom
trebalo da reava isti problem - serverska strana TCP konekcije nije htela da prihvati konekciju
ako je primljeni SYN segment bio stara kopija (retransmisija) SYN segmenta iz neke ranije
konekcije. Kako je serverska strana resila problem odreivanja da li je klijent stvarno iao
uivo"? Ona je izabrala poetni broj sekvence koji nije bio korien dugo vremena, poslala taj
broj klijentu i zatim ekala da klijent odgovori ACK segmentom koji sadri taj broj. Moemo
ovde da usvojimo istu ideju u svrhu autentifikacije.
Jednokratni broj (nonce) je broj koji e protokol upotrebiti samo jednom zauvek. Odnosno,
jednom kada protokol upotrebi jednokratni broj, on taj broj vie nikada nee koristiti. Na
protokol ap4.0 koristi jednokratni broj na sledei nain:
1. Alisa alje Bobu poruku I am Alice".
2. Bob bira jednokratni broj, R, i alje ga Alisi.
3. Alisa ifruje jednokratni broj koristei svoj i Bobov simetrini tajni klju, KA_B, i alje
natrag Bobu ifrovani jednokratni broj, KA_B(R). Kao u protokolu apS.i, injenica je da Alisa
zna KA_B i koristi ga za ifrovanje vrednosti koja doputa Bobu da zna kako je poruku koju
on prima napravila Alisa. Jednokratni broj se koristi da bi obezbedio da Alisa ide uivo".
4. Bob deifruje primljenu poruku. Ako je deifrovan jednokratni broj jednak jednokratnom
broju koji je on poslao Alisi, onda je Alisa autentifikovana.
Protokol ap4.0 ilustrovan je na slici 8.1 0. Koristei vrednost za R samo jednom zauvek i
zatim proveravajui vraenu vrednost, KA^B(R), Bob moe da bude siguran daje Alisa ona za koju
se izdaje (zato to poznaje vrednost tajnog kljua potrebnu za ifrovanje R) i da ide uivo" (zato
stoje ifrovala jednokratni broj, R, koji je Bob upravo napravio).

Upotreba jednokratnog broja i kriptografije simetrinog kljua stvorila je osnovu za na uspeni
protokol autentifikacije, ap4.0. Prirodno pitanje je da li moemo da koristimo jednokratan broj i
kriptografiju javnog kljua (a ne kriptografiju simetrinog kljua) da bismo resili problem
autentifikacije. Upotreba javnog kljua izbegla bi tekou koja se javlja u svakom sistemu sa
deljenim kljuem - brigu o tome kako bi obe strane saznale vrednost tajnog deljenog kljua.
Protokol koji koristi kriptografiju javnog kljua na slian nain kao kriptografiju deljenog kljua
u protokolu ap4.0]e protokol pod imenom ap5.0.
1 . Alisa alje Bobu poruku I am Alice".
2. Bob bira jednokratni broj, R, i alje ga Alisi. Jo jednom, jednokratni broj e biti
upotrebljen da bi se osiguralo da Alisa ide uivo".
3. Alisa koristi svoj privatni klju, KA, da bi ifrovala jednokratni broj i alje Bobu rezultujuu
vrednost KA(R). Kako samo Alisa zna svoj privatni klju, niko sem nje ne moe da generie
KA(R).
4. Bob primenjuje Alisin javni klju, K/, na primljenu poruku; odnosno, Bob izraunava
KA
+
(K/(R)). Setite se iz nae diskusije o RSA kriptografiji javnim kljuem u odeljku 8.2 da
je K/(KA(R))= R. Dakle, Bob izraunava R i auten-tifikuje Alisu.
Rad protokola ap5.0 prikazanje na slici 8.11. Da lije protokol ap5.0 tako bezbedan kao
protokol ap4.01 Oba protokola koriste jednokratne brojeve. Kako ap5.0 koristi tehnike javnih
kljueva, on zahteva da Bob dobije Alisin javni klju. To dovodi do zanimljivog scenarija,
prikazanog na slici 8.1 2, u kome Trudi moe da Bobu glumi Alisu.
1. Trudi alje Bobu poruku I am Alice".
2. Bob bira jednokratni broj, R, i alje ga Alisi, ali Trudi presree tu poruku.
3. Trudi koristi svoj privatni klju, Kj da bi ifrovala jednokratni broj i alje Bobu rezultujuu
vrednost, Kf(R). Za Boba, Kf(R)'p samo hrpa bitova i on ne zna da li bitovi predstavljaju
Kf(R) ili K/(R).
4. Bob sada mora da dobije Alisin javni klju da bi primenio KA+ na vrednost koju je ba
primio. On alje Alisi poruku u kojoj od nje trai K/ (Bob bi takode mogao da dobije Alisin
javni klju sa njene veb lokacije). Trudi presree i
tu poruku i odgovara Bobu sa KT
+
, odnosno, svojim javnim kljuem. Bob proraunava
KT
+
(K/R))=R i tako autentifikuje Trudi kao Alisu!
Iz gornjeg scenarija, jasno je daje protokol ap5.0 siguran" samo koliko je i distribucija javnih
kljueva sigurna. Na svu sreu, postoje bezbedni naini distribuiranja javnih kljueva, kao to
emo uskoro videti u odeljku 8.5.

8.3 AUTENTIFIKACIJA 677 677 677 677

U scenariju na slici 8.12, Bob i Alisa bi na kraju mogli zajedno da otkriju kako neto nije u
redu, zato to e Bob tvrditi daje imao interakciju sa Ahsom, ah Alisa zna da nikada nije imala
interakciju sa Bobom. Postoji akjo lukaviji napad koji bi
izbegao to otkrivanje. U scenariju na slici 8.13, i Alisa i Bob priaju jedno sa drugim ali,
koristei istu pukotinu u protokolu autentifikacije, Trudi moe da se transpa-rentno ubaci
izmeu Alise i Boba. Posebno, ako Bob pone da alje Alisi ifrovane podatke koristei klju za
ifrovanje koji prima od Trudi, Trudi moe da rekonstru-ie otvoreni tekst u komunikaciji od
Boba do Alise. U isto vreme, Trudi moe da prosledi Bobove podatke ka Alisi (posle ponovnog
ifrovanja podataka korienjem Alisinog stvarnog javnog kljua).

1
308
8.4 . INTEGRITET
Bob je zadovoljan to alje ifrovane podatke, a Alisa je zadovoljna to prima ifro-vane
podatke koristei sopstveni javni klju; oboje su nesvesni Trudinog prisustva. Ako bi se Bob i
Alisa kasnije sreli i porazgovarali o svojoj interakciji, Alisa bi rekla daje primila tano ono stoje
Bob posalo, pa se ne bi otkrilo nita to nije u redu. Ovo je jedan od primera takozvanog napada
oveka u sredini (ovde bi vie odgovaralo, napada ene u sredini"). To se ponekad naziva napad
brigade sa kofama, zato to Trudino prosledivanje podataka izmeu Alise i Boba lii na
prosledivanje kofa vode du lanca ljudi (brigade sa kofama") koji gase vatru koristei udaljeni
izvor vode.

8. 4 Integritet
Pomislite koliko ste se puta potpisali na paretu hartije u toku protekle nedelje. Potpisujete
ekove, raune kreditnih kartica, pravna dokumenta i pisma. Va potpis potvruje da ste vi
(nasuprot nekom drugom) potvrdili i/ili se saglasili sa sadrajem dokumenta. U digitalnom svetu,
esto elimo da ukaemo na vlasnika ili stvaraoca dokumenta, ili da oznaimo neiju saglasnost
sa sadrajem dokumenta. Digitalni potpis je kriptografska tehnika za postizanje ovih ciljeva u
digitalnom svem. Ba kao i potpisi ljudi, digitalno potpisivanje bi trebalo da se izvri na takav
nain da digitalni potpisi budu proverljivi, da se ne mogu falsifikovati ili ne priznavati. Odnosno,
mora biti mogue da se dokae" kako je dokument koji je neko potpisao zaista potpisala ta
osoba (potpis mora da bude proverljiv) i daje samo ta osoba mogla da potpie dokument (potpis
ne moe da se falsifikuje, a potpisnik ne moe kasnije da porekne ili da ne prizna daje potpisao
dokument). To se lako postie korienjem tehnika kriptografije javnim kljuem.

8.4.1 Stvaranje digitalnih potpisa
Pretpostavite da Bob eli da digitalno potpie dokument", m. O dokumentu moemo da
razmiljamo kao o datoteci ili o poruci koju e Bob da potpie i poalje. Kao to je prikazano na
slici 8.14, da bi potpisao taj dokument, Bob jednostavno koristi svoj privatni klju, KB, da bi
izraunao KB~(m). Na prvi pogled, moglo bi izgledati udno to Bob koristi svoj privatni klju
(koji se, kao to smo videli u odeljku 8.2, koristi za deifrovanje poruke koja je bila ifrovana
njegovim javnim kljuem) da bi potpisao dokument. Ali, setite se da se ifrovanje i deifrovanje
svode na matematiku operaciju (eksponenciranje na stepen e ili du algoritmu RSA; proitajte
odeljak 8.2) i da Bobov cilj nije da ifruje ili uini nejasnim sadraj dokumenta, nego da potpie
dokument na nain koji je proverljiv, bez mogunosti falsifikovanja i neopoziv. Bob ima
dokument, m, a njegov digitalni potpis dokumenta je KB'(m).
Da li digitalni potpis, KB-(m), ispunjava nae zahteve daje proverljiv, bez mogunosti
falsifikovanja i neopoziv? Pretpostavite da Alisa ima m i KB~(m). Ona eli da dokae na sudu (u
parnici) da je Bob zaista potpisao dokument i da je bio jedina osoba koja je uopte mogla da ga
potpie. Alisa uzima Bobov javni klju, KB*, i pri-menjuje ga na digitalni potpis, KB~(m),
pridruen dokumentu, m. Odnosno, ona izra-
unava K8*(KB~(m)) i dobija m, koji tano odgovara originalnom dokumentu! Alisa zatim
objanjava daje samo Bob mogao da potpie dokument, iz sledeih razloga;
Bilo ko daje potpisao poruku morao je da koristi privatni klju, KB', u izraunavanju potpisa
KB*(m)t tako daje KB
+
{KB'(m)) = m.
Bob je jedina osoba koja je mogla da zna privatni klju, KB'. Setite se iz nae diskusije o
algoritmu RSA u odeljku 8.2 da poznavanje javnog kljua, KB*t ne pomae u saznavanju
privatnog kljua, KB'. Dakle, jedina osoba koja bi znala Kg' jeste osoba koja je stvorila par
kljueva, (Kg
+
. Kg), a to je Bob. (Zapazite da to, meutim, pretpostavlja da Bob nikome nije
dao Kg\ niti je bilo ko ukrao" Kg od Boba.)

Vano je takoe zapaziti da ako je originalni dokument, m, ikada promenjen u neki drugi oblik,
m', potpis koji je Bob napravio za m nee vaiti za m', zato to KB(Kg (m)) nije jednako m'.
Dakle, vidimo da kriptografija javnim kljuem obezbeduje jednostavan i elegantan nain da
se digitalno potpisuju dokumenti, nain koji je proverljiv, ne moe se falsifikovati, neopoziv je i
titi od kasnijih promena dokumenta.
8.4.2 Izvodi poruka
Videli smo da tehnologija javnog kljua moe da se upotrebi da bi se napravio digitalni potpis.
Meutim, jedna od nevolja sa potpisivanjem podataka je da su ifrovanje i deifrovanje
raunarski skupe operacije. Kada se digitalno potpisuje dokument koji je zaista vaan, recimo
ugovor o spajanju dve velike multinacionalne korporacije ili ugovor sa detetom da ono jednom
nedeljno poisti svoju sobu, raunarska cena moe da ne bude vana. Meutim, mnogi mreni
ureaji i procesi (na primer,


8.4 . INTEGRITET 681
ruteri koji razmenjuju informacije tabela rutiranja i korisniki agenti za elektronsku potu koji
razmenjuju elektronsku potu) rutinski razmenjuju podatke koji ne moraju da se ifruju.
Svejedno, oni ipak ele da obezbede da:
poiljalac podataka zaista jeste onaj za koga se izdaje, odnosno, daje poiljalac potpisao
podatke i da taj potpis moe da se proveri.
preneti podaci nisu promenjeni od kada ih je poiljalac stvorio i potpisao.
S obzirom na to da operacije ifrovanja i deifrovanja predstavljaju raunaru zaista veliko
optereenje, potpisivanje celog skupa podataka (kompletnog dokumenta) moe da bude krajnje
nepraktino. Efikasniji pristup, upotrebom tzv. izvoda poruka, moe da ispuni ova dva cilja bez
ifrovanja cele poruke.
Izvod iz poruke u mnogome lii na kontrolni zbir. Algoritam za izvod iz poruke uzima
poruku, m, proizvoljne duine i proraunava otisak prsta" fiksne duine koji se zove izvod iz
poruke, H(m). Izvod iz poruke titi podatke u smislu da ako se m promeni u m' (zlonamerno ili
sluajno) onda H(m), izraunat za originalne podatke (i prenesen sa podacima), nee odgovarati
H(m') izraunatom za promenjene podatke, m', Dok izvod iz poruke obezbeduje integritet
podataka, kako on pomae u potpisivanju poruke m? Ovde je cilj da Bob, umesto da potpie celu
poruku izraunavajui KB'(m), potpisuje samo izvod iz poruke izraunavajui KB~(H(m)). Odno-
sno, posedovanje m i KB'(H(m)) zajedno (zapazite da m nije ifrovano) trebalo bi da bude isto
tako dobro" kao posedovanje potpisane celokupne poruke, KB'(tn), To znai da se m i K~B(H(m))
zajedno ne mogu falsifikovati, da su proverijivi i neopozivi. Nemogunost falsifikovanja zahteva
da izvod iz poruke ima neke specijalne osobine, kao to emo videti dalje u tekstu.
Naa definicija izvoda poruke moe da izgleda sasvim slino kao definicija kontrolnog
zbira (na primer, kontrolnog zbira za Internet, proitajte odeljak 3,3.2) ili monijeg koda za
ispravljanje greaka, kao to je ciklina provera redundantnosti (proitajte odeljak 5.2). Da lije
ona zaista razliita? Kontrolni zbirovi, cikline provere redundantnosti i izvodi iz poruka - sve su
to primeri takozvanih he funkcija. Kao to je prikazano na slici 8.15, he funkcija uzima ulaz,
m, i proraunava niz fiksne duine koji je poznat kao he. Kontrolni zbirovi za Internet, CRC-ovi
i izvodi iz poruka svi zadovoljavaju ovu definiciju. Ako potpisivanje izvoda poruke treba da
bude isto tako dobro" kao potpisivanje cele poruke, posebno ako e ono da zadovolji zahtev
nemogunosti falsifikovanja, onda algoritam za izvod poruke mora da ima sledee dodatno
svojstvo:
Raunarski je neizvodljivo pronai bilo koje dve razliite poruke* i y takve daje H(x)=H(y).
Nezvanino, ovo svojstvo znai daje uljezu raunarski neizvodljivo da zameni jednu poruku
drugom, koja je zatiena izvodom poruke. Odnosno, ako su (m,H(mJ) poruka i njen pripadajui
izvod koje je napravio poiljalac, onda uljez ne moe da falsifikuje sadraj druge poruke, y, koja
ima istu vrednost izvoda kao originalna poruka. Kada Bob potpise m izraunavajui KB(H(m)),
mi znamo da nijedna druga
poruka ne moe da zameni m. Pored toga, Bobov digitalni potpis H(m) ga jedinstveno
identifikuje kao proverljivog, neopozivog potpisnika H(m) (i, kao posledica, i samu m), kao to
je razmatrano ranije u odeljku 8.4.1.
U kontekstu Bobovog slanja poruke Alisi, na slici 8.16 dat je zbirni pregled procedure
stvaranja digitalnog potpisa. Bob proputa svoju originalnu dugaku poruku kroz he funkciju da
bi napravio izvod poruke. On zatim digitalno potpisuje izvod poruke svojim privatnim kljuem.
Originalna poruka (u obliku otvorenog teksta) zajedno sa digitalno potpisanim izvodom poruke
(na koji emo se od sada pozivati kao na digitalni potpis) alje se Alisi. Na slici 8.17 dat je zbirni
pregled procedure proveravanja integriteta poruke. Alisa primenjuje poiljaoev javni klju na
poruku da bi rekonstruisala poslati izvod poruke. Alisa takoe primenjuje he funkciju na poruku
otvorenog teksta da bi dobila izraunati izvod poruke. Ako su ova dva izvoda poruke identina,
onda Alisa moe da bude sigurna u pogledu integriteta i autora poruke.
8.4.3 Algoritmi he funkcija
Hajde da se uverimo kako bi jednostavan kontrolni zbir, kao to je kontrolni zbir za Internet, bio
slab algoritam za izvod poruke. Umesto da koristimo aritmetiku prvog komplementa (kao u
kontrolnom zbiru za Internet), hajde da izraunamo kontrolni zbir obraujui svaki znak kao bajt
i dodajui bajtove jedan drugom koristei kri-ke"od po etiri bajta istovremeno. Pretpostavimo
da Bob duguje Alisi 100,99 USD i da joj alje poruku IOU (poruku u kojoj kae da joj duguje [I
Owe You], prim. prev.) koja se sastoji od tekstualnog niza IOU100 . 9980B". ASCII
prezentacija

8.4 . INTEGRITET 683

tih slova (u heksadecimainoj notaciji) je 4 9, 4F, 55, 31, 30, 30, 2E, 3 9, 39, 42, 4F, 42.
Na gornjem delu slike 8.18 pokazano je daje etvorobajtni kontrolni zbir za tu poruku B2 Cl
D2 AC. Neznatno razliita poruka (ali sa mnogo veim trokom za Boba) prikazanaje u donjoj
polovini slike 8.18. Poruke IOU100 . 99BOB"i IOU900 .19BOB" imaju isti kontrolni zbir.
Dakle, ovaj jednostavan algoritam kontrolnog zbira kri dva gornja zahteva. Uz date originalne
podatke, jednostavno je pronai drugi skup podataka sa istim kontrolnim zbirom. Jasno je da e
nam, iz bezbednosnih razloga, biti potrebna monija he funkcija od kontrolnog zbira.
Algoritam za izvod poruke MD5 iji je autor Ron Rivest [RFC 1321] danas je u irokoj
upotrebi. On proraunava 128-bitni izvod poruke u procesu od etiri koraka, koji se sastoji od
koraka dopunjavanja (dodavanja jedinice praene sa dovoljno nula tako da poruka zadovoljava
izvesne uslove), koraka dodavanja (dodavanja 64-bitne prezentacije duine poruke pre
dopunjavanja), inicijalizacije akumulatora i konanog ulaska u petlju u kojoj se obraduju blokovi
poruke od po 16 rei u etiri runde obrade. Ne zna se da li MD5 stvarno zadovoljava gore
navedene zahteve. Autor MD5 tvrdi, Tekoa dolaenja do bilo koje poruke koja ima isti izvod
je reda veli-
ine 2
M
operacija, a tekoa dolaenja do bilo kakve poruke koja ima dati izvod poruke je
veliine reda veliine 2
I2S
operacija". Niko nije osporio ovu tvrdnju. Radi opisa poruke MD5
(ukljuujui implementaciju C izvornog koda) proitajte [RFC 1321].
Drugi glavni algoritam za izvod poruke danas u upotrebi je SHA-1, Secure Hash Algorithm
[FIPS 1995]. Ovaj algoritam se zasniva na principima slinim onima koji su upotrebljeni u
projektovanju poruke MD4 [RFC 1320], prethodnika poruke MD5. Upotreba SHA-1, saveznog
standarda u SAD, zahteva se kad god se trai bezbedni algoritam za izvode poruka koje se
primenjuju u federalnim institucijama. On daje 160-bitni izvod poruke. Vea izlazna duina ini
SHA-1 sigurnijim.

8.5 DISTRIBUCIJA I OVERAVANJE KLJUEVA 311.

8. 5 Distribucija i overavanje kljueva
U odeljku 8.2 videli smo daje nedostatak kriptografije simetrinim kljuem bio potreban da bi se
dve strane koje komuniciraju unapred dogovorile o svom tajnom kljuu. Kod kriptografije javnim
kljuem, taj a priori sporazum o tajnom kljuu nije potreban. Meutim, kao to smo objasnili u
odeljku 8.2, kriptografija javnim kljuem ima sopstvene tekoe, posebno problem dobijanja
neijeg tanog javnog kljua. Oba ova problema - odreivanje deljenog kljua za kriptografiju
simetrinim kljuem i bezbedno dobijanje javnog kljua za kriptografiju javnim kljuem - mogu
da se ree korienjem poverljivog posrednika. Poverljivi posrednik za kriptografiju
simetrinim kljuem zove se centar za distribuciju kljueva (key istribution center, KDC),
koji je poverljivi mreni entitet sa kojim neko moe da ima ustanovljen tajni klju, Videemo da
taj neko moe da koristi KDC kako bi dobio deljene kljueve potrebne da bi bezbedno
komunicirao sa svim drugim mrenim entitetima, izbegavajui neke od zamki koje smo otkrili u
odeljku 8.3. Za kriptografiju javnim kljuem, poverljivi posrednik zove se sertifikaciono telo
(certification authonty, CA). Sertifikaciono telo overava da javni klju pripada posebnom entitetu
(osobi ili mrenom entitetu). Za overen j^vni klju, ako neko moe bezbedno da veruje CA-u koji
je overio taj klju, onda taj neko moe da bude siguran kome javni klju pripada. Jednom kada je
javni klju overen, on moe da se distribuira skoro svuda, ukljuujui tu server javnih kljueva,
linu veb stranicu ili disketu.
PRINCIPI U PRAKSI
KERBEROS
Kerberos [RFC 1510; Neuman 1994] predstavlja uslugu autentifikacije razvijenu na MIT-u, koja
koristi tehnike ifrovanja simetrinim kljuem i centar za distribuciju kljueva. Mada |e konceptualno
isti kao generiki KDC koji smo opisali u odeljku 8.5.1, njegov renik je neznatno drugaiji. Kerberos
takoe sadri nekoliko 2godnih varijacija i proirenja osnovnih KDC mehanizama. Kerberos je
projektovan da autentifikuje korisnike koji pristupaju mrenim serverima i u poetku je bio namenjen
za upotrebu unutar jednog administrativnog domeno, kao to su univerzitetsko naselje ili kompanija.
Dakle, Kerberos je namenjen korisnicima koji ele da pristupaju mrenim uslugama (serverima)
koristei mrene programe aplikacionog nivoa, kao Eto je Telnet (za daljinsko prijavljivanje) i NFS
(za pristup udaljenim datotekama), a ne za uesnike u razgovorima izmeu ljudi koji ele da se
autenfiffkufu jedan drugom, kaa u naim prethodnim primerima. Svejedno, kl j une (igra rei!)
osnovne tehnike ostaju iste.
Kerberosov server za autentifikaciju (AS) igra ulogu KDC-a. AS je skladite ne samo tajnih
kljueva svih korisnika (tako da svaki korisnik moe bezbedno da komunicira sa AS-om) nego i
informacija o tome koji korisnici imaju privilegije pristupa kojim uslugama na kojim mrenim
serverima. Kada Alisa eli da pristupi Bobovoj usluzi (o Bobu sada mislimo kao o serveru], protokol
tano sledi na primer na slici 8.19.
1 Alisa uspostavlja vezu sa Kerberos AS-om, pokazujui da eli da koristi Boba. Celakupna
komunikacija izmeu Alise i AS-a ifrovana je upotrebom tajnog kljua koji dele Alisa i AS. U
Kerberosu, Alisa prvo daje svoje ime i lozinku svom lokalnom raunaru. Tada Alisin lokalni
raunar i AS utvruju jednokratni tajni klju za sesiju za ifrovanje komunikacije izmeu Alise i
AS-a.
2. AS autentifikuje Alisu, proverava da li ona ima privilegiju pristupa Bobu i generie
jednokratni tajni simetrini klju sesije, RJ, za komunikaciju izmeu Alise i Boba.
Autenfilikocioni server (koji se u argonu Kerberaso zove Ticltef Grant' mg Server
- server za odobravanje ulaznica), alje Alisi vrednost Rl, kao i ulaznicu za Bobove usluge.
Ulaznica sadri Alisino ime, klju 20 sesiju Alisa-Bob i vreme isteka vanosti, sve ifrovano
upotrebom Bobovog tajnog kljua (koji znaju samo Bob i AS), kao na slici 8.19. Alisina
ulaznica vai samo do trenutka koda joj istie vanost i Bob e je odbaciti oko mu se pokae
posle 1og Irenutka. Za Kerberos V4, maksimalni ivotni vek ulaznice je oko 21 sat. U
Kerberosu V5, ivotni vek mora da istekne pre kraja 9999. godine, to je definitivno problem
10000. godine!
3. Alisa tada alje Bobu svoju ulaznicu. Ona takoe uz to alje vremensku oznaku
ifrovanu pomou R l , kaja se koristi kao jednokratni broj. Bob deifruje ulaznicu
koristei svoj tajni klju, dobija klju sesije i deifruje vremensku oznaku koristei
klju sesije koji je upravo saznao. Bob alje Alisi natrag jednokratni broj, ifrovan
pomou R l , pokazujui na laj nain da Bob zna R l i do ide uivo".
Najnovija verzija Kerberosa (V5) obezbeduje podrku za vie autenlifikacionih servera,
proveravanje prava pristupa i obnovljive ulaznice. Obilje detalja o svemu ovome nalazi se u
knjigama [Kaufmann 1995] i [RFC 1510],

8.5 . DISTRIBUCIJA I OVERAVANJE KUUEVA 312 312 312 312

8.5.1 Centar za distribuciju kljueva
Pretpostavite jo jednom da Bob i Alisa ele da komuniciraju koristei kriptografiju simetrinim
kljuem. Pretpostavite da se oni nisu nikada sreli i zato nemaju una-pred ustanovljen deljeni tajni
klju. Kako oni mogu da se sporazumeju o tajnom kljuu, ako mogu da komuniciraju jedno sa
drugim samo preko mree? Reenje koje se esto usvaja u praksi je da se koristi poverljivi centar
za distribuciju kljueva (KDC).
KDC je server koji deli razliite tajne simetrine kljueve sa svakim registro-vanim
korisnikom. Taj klju moe da se instalira runo na serveru kada se korisnik prvi put registruje.
KJDC zna tajni klju svakog korisnika, a svaki korisnik moe da komunicira sa KDC-om
koristei taj klju. Hajde sada da vidimo kako poznavanje tog kljua dozvoljava korisniku da
bezbedno dobije klju za komuniciranje sa bilo kojim drugim registrovanim korisnikom.
Pretpostavite da su Alisa i Bob korisnici KDC-a; oni znaju samo svoje individualne kljueve,
KAmKDCi KB_1CDC> prema redosledu kojim smo ih ovde naveli, za bezbedno komuniciranje sa
KDC-om. Alisa preduzima prvi korak i oni nastavljaju kao stoje prikazano na slici 8.19.
1. Koristei K.A^KDC6a bi ifrovala svoju komunikaciju sa KDC-om, Alisa alje poruku KDC-u
koja kae da ona (A) eli da komunicira sa Bobom (5). Oznaavamo ovu poruku kao KAKDC
(A, B).
2. KDC, poznavajui KA^KC, deifruje KA_mc (A, B). KDC tada generie sluajni broj, Rl. To je
vrednost deljenog kljua koji e Alisa i Bob koristiti da bi izveli simetrino ifrovanje kada
komuniciraju jedno sa drugim. Taj klju se oznaava kao klju za jednokratnu sesiju, zato
to e ga Alisa i Bob upotrebiti samo
za tu jednu sesiju koju trenutno uspostavljaju. KDC sada treba da informie Alisu i
Boba o vrednosti broja/. KDC alje natrag Alisi poruku, ifrovanu upotrebom kljua
KA_KDO koja sadri sledee:
Rl, jednokratni klju za sesiju koji e Alisa i Bob koristiti da bi komunicirali.
Par vrednosti: A i Rl, koji je ifrovao KDC koristei Bobov klju, KB_KDC. To oznaavamo sa
KB_KDC (A, Rl). Vano je zapaziti da KDC ne alje Alisi samo vrednost Rl za njenu sopstvenu
upotrebu, nego i ifrovanu verziju vrednosti Rl i Alisinog imena, ifrovanu korienjem
Bobovog kljua. Alisa ne moe da deifruje ovaj par vrednosti u poruci (ona ne zna Bobov
klju za ifrovanje), ali ona to stvarno ne mora ni da radi. Uskoro emo videti da e Alisa
jednostavno proslediti taj ifrovani par vrednosti Bobu, koji e moi da ga deifruje.
KDC stavlja te stavke u poruku, ifruje ih koristei Alisin deljeni klju i alje ih ka Alisi.
Poruka od KDC-a do Alise je KAmKDC(Rl, Kb.q)C( A, Rl)).
3. Alisa prima poruku od KDC-a, deifruje je i izvlai i?/ iz poruke. Alisa sada zna jednokratni
klju sesije, Rl. Alisa takode izvlai KB mc(A, Rl) i to prosleduje Bobu.
4. Bob deifruje primljenu poruku, /Cg_/CDC (A. Rl) koristei KB_KDC i izvlai A i Rl. Bob sada
zna jednokratni klju sesije, Rl i osobu sa kojom deli taj klju, A. Naravno, on preduzima
mere da bi autentifikovao Alisu koristei Rl pre nego to nastavi bilo ta drugo.

8.5.2 Overa javnog kljua
Jedno od glavnih svojstava kriptografije javnim kljuem je to to je mogue da dva entiteta
razmenjuju tajne poruke bez potrebe da razmene tajne kljueve. Na primer, kada Alisa eli da
poalje Bobu tajnu poruku, ona jednostavno ifruje poruku Bobovim javnim kljuem i alje mu
ifrovanu poruku; ona ne mora da zna Bobov privatni klju, niti Bob treba da zna njen privatni
klju. Na taj nain, kriptografija javnim kljuem izbegava potrebu za infrastrukturom KDC.
Naravno, kod kriptografije javnim kljuem, entiteti koji komuniciraju moraju da razmene
javne kljueve. Korisnik moe da uini svoj javni klju javno raspoloivim na mnogo naina, na
primer, postavljanjem javnog kljua na svoju veb stranicu, postavljanjem kljua na server javnih
kljueva, ili slanjem kljua korespondentu preko elektronske pote. Komercijalna veb lokacija
moe da postavi svoj javni klju na svoj server na takav nain da pretraivai automatski
preuzmu javni klju kada se povezu sa lokacijom. Ruteri mogu da postave svoje javne kljueve
na servere javnih kljueva, dozvoljavajui tako drugim mrenim entitetima da ih proitaju.
Meutim, sa kriptografijom javnim kljuem postoji suptilan, ali ipak kritian problem. Da
bismo stekli uvid u taj problem, hajde da razmotrimo primer Internet trgovine. Pretpostavite da
Alisa radi na isporuci pica i da prihvata porudbine preko Interneta. Bob, ljubitelj pica, alje
Alisi poruku otvorenog teksta koja obuhvata nje-

8.5 DISTRIBUCIJA I OVERAVANJE KLJUEVA 689 689 689 689

govu kunu adresu i vrstu pice koju eli. U toj poruci, Bob takoe ukljuuje digitalni potpis
(odnosno, potpisani izvod poruke ili originalni otvoreni tekst poruke). Kao to smo diskutovali u
odeljku 8.4, Alisa moe da dobije Bobov javni klju (sa njegove line veb stranice, servera
javnih kljueva, ili iz poruke elektronske pote) i potvrdi digitalni potpis. Na taj nain, ona je
sigurna da je porudbinu napravio Bob, a ne neki mladi nestako.
Sve je to lepo dok se ne pojavi pametna Trudi. Kao Stoje prikazano na slici 8.20, Trudi
odluuje da im podvali. Trudi alje Alisi poruku u kojoj kae daje ona Bob, daje Bobovu kunu
adresu i naruuje picu. Ona takoe prikljuuje digitalni potpis, ali to radi potpisujui izvod
poruke svojim (odnosno, Trudinim) privatnim kljuem. Trudi se takoe preruava u Boba aljui
Alisi Trudin javni klju, ali rekavi da on pripada Bobu. U ovom primeru, Alisa e primeniti
Trudin javni klju (mislei daje Bobov) na digitalni potpis i zakljuie daje poruku otvorenog
teksta zaista napravio Bob. Bob e se veoma iznenaditi kada isporuilac donese u njegovu kuu
picu sa svim i svaim na njoj!
Iz ovog primera vidimo kako, da bi kriptografija javnim kljuem bila korisna, entiteti (korisnici,
pretraivai, ruteri itd.) treba sigurno da znaju da imaju javni klju entiteta sa kojim
komuniciraju. Na primer, kada Alisa komunicira sa Bobom koristei kriptografiju javnim
kljuem, ona treba sigurno da zna da javni klju za koji se pretpostavlja da je Bobov, njemu
zaista i pripada. Sline probleme imali smo i u naim protokolima za autentifikaciju na slikama
8.12 i 8.13.
Povezivanje javnog kljua sa nekim posebnim entitetom po pravilu vri sertifikaciono telo
(Certificate Authority, CA), iji posao je da proveri identitete i izda uverenja. CA ima sledee
uloge:
1. CA verifikuje da je entitet (linost, ruter itd.) to to kae da jeste. Nema propisanih
procedura kakose vri overavanje. Kada radimo sa CA-om, moramo da verujemo daje CA
izvrio strogu proveru identiteta. Na primer, ako bi Trudi bila u stanju da ueta u
sertifikaciono telo Fly-by-Night, jednostavno objavi Ja sam Alisa"i primi uverenja
pridruena identitetu Alisa", onda ne bismo mogli da imamo mnogo poverenja u javne
kljueve koje overava sertifikaciono telo Fty-by-Night. S druge strane, mogli bismo (ili ne
bismo mogli!) da imamo vie poverenja u CA koji je deo saveznog programa ili programa
koji podrava drava (na primer, drava Utali ovlauje CA-ove u toj dravi [Utah 2002]).
Moemo da imamo poverenja u identitet" pridruen javnom kljuu samo onoliko koliko
moemo da verujemo CA-u i njegovim tehnikama za proveru identiteta. Kakvu zamrenu
mreu poverenja smo pokrenuli!
2. Jednom kada CA proveri identitet entiteta, CA pravi uverenje koje povezuje javni klju
entiteta sa identitetom. Uverenje sadri javni klju i globalno jedinstvenu identifikujuu
informaciju o vlasniku javnog kljua (na primer, ime osobe ili IP adresu). Uverenje
digitalno potpisuje CA. Ovi postupci prikazani su na slici 8.21.
Hajde da sada vidimo kako uverenja mogu da se iskoriste za borbu protiv pica-aljivdija,
kao stoje Trudi, i drugih nepoeljnih osoba. Kada Alisa prima Bobovu porudbinu, ona dobija
Bobovo uverenje, koje moe da se nalazi na njegovoj veb stranici, u poruci elektronske pote, ili
na serveru za uverenja. Alisa koristi CA-ov javni klju da bi proverila verodostojnost Bobovog
uverenja koje je potpisao CA. Ako pretpostavimo daje sam javni klju CA svima poznat (na
primer, on bi mogao da se objavi na poverljivom, javnom i dobro poznatom mestu, kao to je
The New York Times, tako daje poznat svima i ne moe da bude laan), onda Alisa moe da
bude sigurna da ona zaista ima posla sa Bobom. Na slici 8.21 ilustrovani su postupci koji su
obuhvaeni ifrovanjem javnog kljua uz posredstvo CA-a. Moete videti CA uverenja
uskladitena u vaem pretraivau Netscape ako izaberete Communi-cator, Tools, Security Info,
Certificates;..u Internet.xploreru, birajte Tools, Internet Options, Content, Certificates.
I International Telecommunicatton Union (ITU) i IETF razvili su standarde za srtifikaciona
tela. ITU X,509 [ITU 1993] odreuje uslugu autentifikacije kao speci-

690 690 690 690 POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA 8.6 KONTROLA PRISTUPA: MRENE BARIJERE 691
finu sintaksu za uverenja. [RFC 1422] opisuje upravljanje kljuevima zasnovano na CA-u za
upotrebu sa bezbednom elektronskom potom na Internetu. On je kompatibilan sa X.509 ali ide
dalje od X.509 uspostavljanjem procedura i konvencija za arhitekturu upravljanja kljuevima. U
tabeli 8.3 opisana su neka znaajna polja u uverenju.
Sa nedavnim naglim razvojem elektronske trgovine i iroko rasprostranjenom potrebom za
bezbednim transakcijama, povealo se zanimanje za sertifikaciona tela. Izmeu ostalih
kompanija koje obezbeuju usluge CA-a, tu su Digital Signature Trust Companv [Digital
Signature 2004] i Verisign [Verisign 2004]. Uverenje koje je kompanija Thawte Consulting
izdala firmi Netfarmers Enterprisers, Inc., onako kao to se vidi pomou pretraivaa Netscape,
prikazano je na slici 8.22.

8. 6 Kontrola pristupa: mrene barijere
U ovom poglavlju videli smo da Internet nije ba sigurno mesto - tamo su loi momci", koji
prave sve same propasti. Sa take gledita mrenog administratora, svet se sasvim jasno deli na
dva tabora - dobre momke (koji pripadaju organizaciji koja upravlja mreom i koji bi trebalo da
mogu da pristupaju resursima unutar administratorove mree na relativno neogranien nain) i
loe momke (svi ostali, iji pristup mrei treba paljivo razmatrati). U mnogim organizacijama,
od srednje-vekovnih zamkova do savremenih zgrada korporativnih kancelarija, postoji jedna
taka za ulaz/izlaz gde se i dobri i loi momci koji ulaze i naputaju organizaciju bezbednosno
proveravaju. U zamku, to se radilo na kapiji najednom kraju pokretnog mosta; u korporativnoj
zgradi, to se radi na alteru za bezbednost/prijem. U raunarskoj mrei, kada se saobraaj koji
ulazi/naputa mreu hezbednosno proverava, prijavljuje, odbacuje i/ili prosleduje, to se radi na
ureaju koji se zove mrena barijera.
Slika 8.22 Slika 8.22 Slika 8.22 Slika 8.22 Uverenje koje je kompanija Thavvle Consulting izdala firmi Netfarmers
Enterprisers, Inc.


6.6 . KONTROLA PRISTUPA: MRENE BARIJERE 693 693 693 693
Mrena barijera (firewalf) jeste kombinacija hardvera i softvera koja izoluje unutranju
mreu organizacije od Interneta, dozvoljavajui nekim paketima da prou i blokirajui ostale.
Mrena barijera doputa administratoru mree da kontrolie pristup izmeu spoljanjeg sveta i
resursa unutar administrirane mree upravljanjem tokom saobraaja ka resursima i od tih
resursa. Na slici 8.23 prikazana je mrena barijera, koja se nalazi na granici izmeu
administrirane mree i ostatka Interneta. Dok velike organizacije mogu da koriste viestruke
nivoe mrenih barijera ili distribuirane mrene barijere [Ioannidis 2000], postavljanje mrene
barijere na jednu taku pristupa mrei, kao stoje prikazano na slici 8.23, olakava upravljanje i
spro-voenje politike bezbednosnog pristupa.
Postoje dve vrste mrenih barijera: mrene barijere sa filtriranjem paketa (koje rade u
mrenom sloju) i mreni prolazi aplikacionog nivoa (koji rade u apli-kacionom sloju).
Objasniemo svaku od njih u sledea dva pododeljka.

8.6.1 Filtriranje paketa
Kao stoje prikazano na slici 8.23, organizacija obino ima ruter mrenog prolaza koji povezuje
njenu internu mreu sa ISP-om (i na taj nain sa javnim Internetom). Ceo saobraaj koji ulazi u
internu mreu i izlazi sa nje prolazi kroz ovaj ruter i tu dolazi do filtriranja paketa. Filtri paketa
rade tako to prvo sintaksno analiziraju zaglavlja datagrama, a zatim primenjuju pravila
filtriranja iz skupa pravila koji je defmisao administrator, da bi odredili da li da odbace datagram
ili da ga puste da proe. Odluke o filtriranju po pravilu se zasnivaju na:
IP adresi izvora ili odredita;
TCP ili UDP portu izvora ili odredita;
vrsti poruke ICMP (Internet protokol za kontrolu poruka);
datagramima za inicijalizaciju konekcije korienjem bitova TCP SYN ili ACK.
Kao jednostavan primer, ftlter moe da se podesi da blokira sve UDP segmente i sve Telnet
konekcije. Takva konfiguracija spreava one koji nisu lanovi da se prijavljuju na interne
raunare koristei Telnet i lanove da se prijavljuju na spoljanje raunare koristei Telnet
konekcije, blokirajui sve TCP segmente (od kojih je svaki enkapsuiiran u datagram) iji je broj
porta izvora ili odredita 23 (to odgovara Tel-netu). Filtriranje UDP saobraaja je popularna
politika u korporacijama - na veliku alost vodeih prodavaa ivog zvuka i videa, iji proizvodi
teku preko UDP-a. Filtriranje Telnet konekcija je takoe popularno, zato to spreava uljeze
spolja da se prijavljuju na internim mainama. [CERT Filtering 2002] daje listu preporuenih
paketnih filtriranja porta/protokola da bi se izbegao izvestan broj dobro poznatih pukotina u
bezbednosti postojeih mrenih aplikacija.'
;
Politika filtriranja moe takoe da se zasniva na kombinaciji brojeva adrese i porta. Na
primer, ruter za filtriranje moe da prosleuje sve Telnet datagrame (one sa brojem porta 23)
izuzev onih koji odlaze sa liste posebnih IP adresa i dolaze na nju. Takva politika dozvoljava
Telnet konekcije ka raunaru sa dozvoljene liste i od
Slika 8.23 Slika 8.23 Slika 8.23 Slika 8.23 Postavljanje mrene barijere izmeu administrirane mree i spoljanjeg sveto

njega. Na nesreu, zasnivanje politike na spoljasnjim adresama ne obezbeduje nikakvu zatitu
od datagrama koji imaju adresu izvora koja pripada raunaru sa dozvoljene liste, ali su u stvari
poslati sa drugog raunara (najverovatnije vlasnitva loeg momka" koji je falsifikovao adresu
izvora datagrama). Takvu IP prevaru ispitaemo u sledeem odeljku.
Filtriranje takoe moe da se zasniva na tome da li je bit TCP ACK postavljen ili nije. Ovaj
trik je sasvim koristan ako organizacija eli da dopusti svojim internim klijentima da se povezuju
sa spoljasnjim serverima, ali eli da sprei spoljanje klijente da se povezuju sa internim
serverima. Setite se iz odeljka 3.5 da prvi segment u svakoj TCP konekciji ima bit ACK podeen
na 0, dok svi drugi segmenti u konekciji imaju bit ACK podeen na 1. Dakle, ako organizacija
eli da sprei spoljanje klijente da zaponu konekcije sa internim serverima, ona jednostavno
filtrira sve dolazne segmente sa bitom ACK postavljenim na 0. Ovakva politika obustavlja sve
TCP konekcije koje potiu iz spoljanjeg sveta, ali dozvoljava konekcije koje su stvorene
iznutra.
Iako ovi primeri mogu da daju utisak kako je dosta lako odrediti pravila filtriranja koja
implementiraju datu politiku bezbednosti, u toj oblasti ima mnogo suptilnosti i moguih zamki.
Da bismo ilustrovali neka od tih pitanja, hajde da razmotrimo primer, prilagoen
izknjige[Chapman 1992]. Filtriranje paketa radi tako to sekven-cijalno proverava pravila
filtriranja na datagramu koji se ispituje; prvo pravilo koje

694
8.6 KONTROLA PRISTUPA: MRENE BARIJERE 695J
odgovara datagramu odreuje akciju koja e da se preduzme. Evo naeg scenarija. Pretpostavite
da Alisa administrira mreom kompanije 222.22.0.0/16 i da, uopte, eli da zabrani pristup
svojoj mrei sa javnog Interneta (pravilo R3 u tabeli 8.4). Meutim, Alisa sarauje sa Bobom i
njegovim kolegama, koji su na univerzitetu, pa Alisa eli da dozvoli korisnicima sa Bobovog
univerziteta (ija je mrena adresa 111.11/16) pristup posebnoj podmrei, 222.22,22/24 unutar
mree njene kompanije (pravilo Rl). inilac koji sve ovo oteava je to to Alisa zna daje Trudi,
dobro poznali haker, na Bobovom univerzitetu i da je Trudina podmrea, 111.11.11/24, pravi raj
za nepouzdane hakere. Zato Alisa eli da nikakav saobraaj iz podmree 111.11.11/24 ne ue
nigde u njenu mreu (pravilo R2). Alisina pravila filtriranja paketa data su u tabeli 8.4.
U tabeli 8.5 prikazano je kako Alisina korporativna mrena barijera radi sa odabranim
datagramima kada se pravila primenjuju u jednom od dva razliita redosleda. Kada se pravila
primenjuju u redosledu prvo najspecifinije adrese: R2, Rl, R3 (u pretposlednjoj koloni tabele
8.5), dobijamo eljene rezultate: datagrami kao to je Pl koji imaju izvor u hakerskoj podmrei i
odredite u korporativnoj mrei, ali van specijalne podmree, ne proputaju se kroz mrenu
barijeru (po pravilu R2). Slino tome, datagrami kao Stoje P2 iz hakerske podmree koji za
odredite imaju specijalnu podmreu ne proputaju se kroz mrenu barijeru (po pravilu R2). Pod
redosledom pravila R2, Rl, R3, datagrami iz opte univerzitetske mree proputaju se ka
specijalnoj podmrei (datagram P3) ali ne i u druge delove korporativne mree (datagram P4).
Pretpostavite, meutim, da se pravila primenjuju u redosledu R l, R2, R3 (poslednja kolona
u tabeli 8.5). U tom sluaju, datagramu P2 se pogreno dozvoljava pristup specijalnoj podmrei
pod pravilom Rl, alo to se adrese izvora i odredita P2 podudaraju sa specifikacijom izvora i
odredita za pravilo Rl, a pravilo Rl se primenjuje kao prvo. Lekcija koju smo nauili iz ovog
jednostavnog primera sa tri pravila je jasna - vaan je redosled procene pravila mrene barijere.
Naravno, zahteva se paljivo razmiljanje - zamislite tekoe kada se odreuju mrene barijere sa
hiljadama pravila! Moglo bi se pomisliti da primenjivanje prvo specifinijih pravila uvek
izbegava nepredvieno ili neeljeno ponaanje koje nastaje usled pitanja redosleda. Meutim,
videemo u problemima koji su dati u domaem zadatku na kraju poglavlja da to ne mora uvek
tako da bude.
8,6.2 Aplikacioni mreni prolaz
U prethodnim primerima, videli smo da filtriranje na nivou paketa dozvoljava organizaciji da
grubo filtrira IP i TCP/UDP zaglavlja, ukljuujui IP adrese, brojeve portova i bitove potvrde.
Na primer, videli smo da filtriranje zasnovano na kombinaciji IP adresa i brojeva portova moe
da dopusti internim klijentima da ostvare Telnet konekcije spolja, dok istovremeno spreava
spoljanje klijente da obavljaju Telnet sesije unutar interne mree. Ali, ta ako organizacija eli
da obezbedi uslugu Telnet ogranienom skupu internih korisnika (prema njihovim IP adresama)?
I, ta ako organizacija eli da se tako privilegovani korisnici autentifikuju pre nego to im se
dozvoli da stvore Telnet sesije prema spoljanjem svetu? Takvi zadaci su izvan mogunosti
filtra. Zaista, informacija o identitetu internih korisnika nije ukljuena u IP/TCP/UDP zaglavlja,
nego se, umesto toga, nalazi u podacima aplikacionog sloja.
Da bismo imali bezbednost finijeg nivoa, mrene barijere moraju da kombinuju filtre paketa
sa aplikacionim mrenim prolazima. Aplikacioni mreni prolazi gledaj dalje od IP/TCP/UDP
zagiavlja i prave odluke upravljanja zasnovane na aplikacionim podacima. Aplikacioni mreni
prolaz je aplikaciono specifian server kroz koji moraju da prou svi podaci aplikacije (kako
ulazni tako i izlazni). Najednom raunaru moe da radi vie aplikacionih mrenih prolaza, ali
svaki od njih je poseban server sa sopstvenim procesima.
Da bismo dobili neki uvid u aplikacione mrene prolaze, hajde da konstruiemo mrenu
barijeru koja dozvoljava samo ogranienom skupu internih korisnika da radi Telnet spolja i
spreava sve spoljanje klijente da rade Telnet unutra. Takva politika moe da se ostvari
implementiranjem kombinacije filtra paketa (u ruteru) i Telnet mrenog prolaza, kao Stoje
prikazano na slici 8.24. Ruterov filter je konfigurisan da

696 696 696 696
8.7 NAPADI I KONTRAMERE 317 317 317 317

blokira sve Telnet konekcije izuzev onih koje potiu sa IP adrese aplikacionog mrenog prolaza.
Takva konfiguracija filtra prisiljava sve odlazne Telnet konekcije da prou kroz aplikacioni
mreni prolaz. Zamislite sada internog korisnika koji eli da radi Telnet sa spoljasnjim svetom.
Korisnik mora prvo da uspostavi Telnet sesiju sa aplikacionim mrenim prolazom. Aplikacija radi
kroz mreni prolaz, koji oslukuje dolazne Telnet sesije, trai od korisnika njegov 1D i lozinku.
Kada korisnik obezbedi te informacije, aplikacioni mreni prolaz proverava kako bi video da li
korisnik ima dozvolu da radi Telnet sa spoljasnjim svetom. Ako nema, mreni prolaz obustavlja
Telnet konekciju internog korisnika sa mrenim prolazom. Ako korisnik ima dozvolu, onda
mreni prolaz (1) trai od korisnika ime spoljanjeg raunara sa kojim eli konekciju, (2)
uspostavlja Telnet sesiju izmeu mrenog prolaza i i i i spoljanjeg raunara i (3) prenosi spoljanjem
raunaru sve podatke koji stiu od korisnika, a korisniku sve podatke koji stiu od spoljanjeg
raunara. Na taj nain Telnet aplikacioni mreni prolaz ne samo da izvrava ovlaenje korisnika
nego takode radi kao Telnet server i Telnet klijent, prenosei informacije izmeu korisnika i i i i uda-
ljenog Telnet servera. Zapazite da e filter dozvoliti korak 2 zato to mreni prolaz zapoinje
Telnet konekciju prema spoljanjem svetu.
Interne mree esto imaju vie aplikacionih mrenih prolaza, na primer, mrene prolaze za
Telnet, HTTP, FTP i elektronsku potu. U stvari, server za potu organizacije (proitajte odeljak
2.4) i ke memorija za Web su aplikacioni mreni prolazi.
Ni aplikacioni mreni prolazi nisu bez nedostataka. Prvo, potreban je razliit aplikacioni
mreni prolaz za svaku aplikaciju. Drugo, postoji cena u performansi koja mora da se plati, zato
to e se svi podaci prenositi preko mrenog prolaza. To postaje nevolja, posebno kada vie
korisnika ili aplikacija koriste istu mainu za mreni prolaz. Najzad, mora da se preduzme i
dodatni napor prilikom konfigurisanja:
softver klijenta mora da zna kako da uspostavi kontakt sa mrenim softverom umesto
spoljanjeg servera kada korisnik uputi zahtev, i mora da zna kako da kae aplikacionom
mrenom prolazu sa kojim spoljasnjim serverom treba da se povee, ili
korisnik mora izriito da se povee sa spoljasnjim serverom preko aplikacionog mrenog
prolaza.
Zakljuujemo ovaj odeljak napomenom da mrene barijere ni u kom sluaju nisu reenje za
sve probleme bezbednosti. One uvode kompromis izmeu stepena komunikacije sa spoljasnjim
svetom i nivoa bezbednosti. S obzirom na to da filtri ne mogu da spree prevare u vezi sa IP
adresama i brojevima portova, oni esto koriste politiku sve ili nita" (na primer, zabranu
celokupnog UDP saobraaja). Mreni prolazi takoe mogu da imaju softverske greke,
dozvoljavajui napadaima da prodru u njih. Najzad, mrene barijere su ak i manje efikasne
ako interno generisane komunikacije mogu da dou do spoljanjeg sveta bez prolaza kroz
mrenu barijeru. Dva takva primera su beine komunikacije i modemi.

8. 7 Napadi i kontramere
Poto smo ispitali ifrovanje/deifrovanje, autentifikaciju, integritet poruka, distribuciju kljueva
i mrene barijere, hajde sada da vidimo kako ove tehnike mogu da se upotrebe u borbi protiv
razliitih napada na mree. Neki od najsenzacionalnijih bezbednosnih napada, kao to su
CodeRed [CERT 2001-19], virus Melissa [CERT 1999-04] i crv Slammer [CERT 2003-04,
Moore 2003], koriste Internet da bi se irili, ali napadali samo operativne sisteme (prepunj avaj
ui privremene memorije u Microsoftovom IIS serveru u sluaju CodeReda) ili aplikacioni
softver (Microsoft Word u sluaju virusa Melissa), a ne samu mreu. S obzirom na to daje ovo
knjiga o mreama, ovde emo se usredsrediti na napade koji iskoriavaju mreu, napadaju je, ili
se bave njom na neki poseban nain.

8.7.1 Preslikavanje
U stvarnom svetu" (suprotno virtuelnom svetu) napadu obino prethodi prikupljanje
infonnacija. Gangsteri i filmova ostvaruju kontakt"; vojnici izviaju oblast". Svrha je jasna -
to se vie zna o meti pre napada, manje je verovatno da emo biti uhvaeni i vei su izgledi na
uspeh. To je istina i u virtuelnoj stvarnosti. Pre napada na mreu, napadai bi voleli da znaju IP
adrese maina u mrei, operativne sisteme

698 698 698 698
8.7 . NAPADI I KONTRAMERE 318 318 318 318

koje one koriste i usluge koje one nude, Sa tim informacijama, njihovi napadi e biti
usredsreeniji i manje je verovatno da e izazvati uzbunu. Proces prikupljanja tih informacija
poznat je kao preslikavanje.
Program kao stoje ping moe da se upotrebi da bi se utvrdile IP adrese maina u mrei
jednostavnim posmatranjem koje adrese odgovaraju na poruku ping. Ske-niranje portova
odnosi se na tehniku sekvencijalnog kontaktiranja (preko zahteva za TCP konekciju, ili preko
jednostavnog UDP datagrama) brojeva portova na maini i gledanja ta se deava kao odgovor.
Ti odgovori, sa svoje strane, mogu da se upotrebe da bi se odredile usluge (na primer, HTTP ili
FTP) koje maina nudi. Nmap [Nmap 2004] je iroko korien pomoni program otvorenog koda
za istraivanje mrea i reviziju bezbednosti" koji skenira portove. Mnoge mrene barijere, kao
to su one koje prodaje Checkpoint [Checkpoint 2004], otkrivaju preslikavanje i aktivnost posle
skeniranja, kao i druge takve zlonamerne aktivnosti" i prijavljuju ih upravljau mree.

8.7.2 Uhoenje paketa
Uhoda paketa (packet sniffer) je program na ureaju prikljuenom na mreu, koji pasivno prima
sve okvire sloja linka podataka koji prolaze kroz mreni adapter ureaja. U difuznom okruenju
kao stoje Ethernet LAN, to znai da uhoda paketa prima sve okvire koji se prenose ka svim
raunarima u LAN-u ili iz njih. Svaki raunar sa Ethernet karticom moe lako da poslui kao
uhoda paketa, zato to Ethernet adapter treba samo da se podesi na zajedniki reim
(promiscuous mode) da bi primao sve Ethernet okvire koji prolaze. Ti okviri, sa svoje strane,
mogu da se proslede aplika-cionim programima koji izvlae podatke aplikacionog nivoa. Na
primer, u Telnet scenariju prikazanom na slici 8.25, lozinka za prijavljivanje poslata od A do B,
kao i lozinka unesena u B uhode se" u raunaru C. Poto su dobili lozinke za korisnike naloge,
napadai mogu kasnije da upotrebe te naloge da bi zapoeli napade odbijanja usluga, o emu
emo govoriti dalje u tekstu. Uhoenje paketa je ma sa dve otrice - ono moe biti dragoceno
mrenom administratoru za nadgledanje i upravljanje mreom (proitajte poglavlje 9), ali takode
moe da ga upotrebi i neki haker.
Softver za uhoenje paketa je besplatno dostupan na razliitim veb lokacijama, ali i u vidu
komercijalnih proizvoda. Poznati su sluajevi profesora koji su na kur-sevima iz mrea davali
laboratorijske vebe koje su obuhvatale i pisanje programa za uhoenje paketa i rekonstrukciju
podataka aplikacionog nivoa. Zaista, Ethereal laboratorijske vebe [Ethereal 2004], pridruene
ovom tekstu (proitajte uvodnu Erthereal laboratorijsku vebu na kraju poglavlja 1) koriste tano
takav program za uhoenje paketa!
Klju za otkrivanje uhoenja paketa je da se detektuju mreni interfejsi koji rade u
zajednikom reimu. Unutar preduzea, mreni administratori mogu da instaliraju softver u svim
raunarima preduzea koji e uzbuniti administratore kada se neki interfejs konfigurie za rad u
zajednikom reimu. Da bi se otkrili interfejsi u zajednikom reimu, daljinski mogu da se
izvedu razliiti trikovi. Na primer,
raunar koji odgovara na datagram ICMP ehoa (odnosno, koji izaziva ICMP eho odgovor;
pogledajte sliku 4.21), koji je ispravno adresiran u IP datagramu ali sadri netanu adresu MAC
(nivoa okvira), verovatno ima svoj interfejs konfigurisan da radi u zajednikom reimu. Kljuna
stvar da se preivi uz uhoenje paketa je da se ifruju svi podaci (posebno lozinke) koji prolaze
preko mrenog linka.
8.7.3 Varanje
Svaki ureaj povezan sa Internetom obavezno alje IP datagrame u mreu. Setite se iz poglavlja
4 da ti datagrami nose poiljaoevu IP adresu, kao i podatke iz vieg sloja. Korisnik sa potpunom
kontrolom nad softverom ureaja (posebno njegovim operativnim sistemom) moe lako da
promeni protokole ureaja tako da postave proizvoljnu IP adresu u datagramovo polje za adresu
izvora. To se zove IP varanje (IP spoofmg). Korisnik na taj nain moe da napravi IP paket koji
po elji sadri bilo kakve podatke (iz vieg sloja) u korisnom teretu i izgleda kao da su podaci
poslati iz proizvoljnog IP raunara. IP varanje se esto koristi u napadima odbijanja usluge da bi
se sakrio organizator napada, o emu emo govoriti kasnije. Sa lanom IP adresom izvora u
datagramu, teko je pronai raunar koji je stvarno poslao datagram.
Sa tehnike take gledita, varanje moe lako da se sprei. Ruteri koji izvravaju
fdtriranje pristupa proveravaju IP adresu dolazeih datagrama i utvruju da lije adresa izvora u
opsegu mrenih adresa za koje se zna da su dostine preko tog


8-7 . NAPADI I KONTRAMERE 701 701 701 701
interfejsa. Ta provera moe lako da se izvede na ivici mree, na primer, na korporativnom
mrenom prolazu ili mrenoj barijeri, gde se zna da su svi raunari u korporaciji unutar datog
opsega adresa. Filtriranje pristupa se smatra trenutno najboljom praksom" [RFC 2827] na
Internetu. Mada tehniki jednostavno, filtriranje pristupa ne moe da se naredi, pa je zato teko
da se postavi sa socijalne take gledita. Kao rezultat, filtriranje pristupa se ne primenjuje
univerzalno.

8.7.4 Napadi odbijanja usluge i distribuiranog odbijanja usluge
iroku klasu bezbednosnih pretnji ine napadi odbijanja usluge (denial-of-service, DoS). Kao
to im ime nagovetava, DoS napadi ine mreu, raunar, ili neki deo mrene infrastrukture
neupotrebljivim za legitimne korisnike. DoS napad obino deluje tako to stvara toliko mnogo
posla za infrastrukturu koja mu je izloena, da legitimni rad ne moe da se obavi. U takozvanom
napadu SYN poplave [CERT SYN 1996], napada potapa server paketima TCP SYN, od kojih
svaki ima lanu IP adresu izvora. Server, nemoan da napravi razliku izmeu legitimnog i
lanog SYN-a, zavrava drugi korak TCP potvrivanja spremnosti za prenos (proitajte odeljak
3.5.6) za lani SYN, dodeljujui strukturu i stanje podataka. Napada nikad ne izvri trei korak
trostruke sinhronizacije, ostavljajui za sobom delimino ostvarene konekcije iji se broj stalno
poveava. Optereenje SYN paketima koji treba da se obrade i iscrpljivanje slobodne memorije
na kraju baca server na kolena. Srodan oblik napada alje IP fragmente raunaru, ali ih ne alje
nikada dovoljno da bi se upotpunio datagram. Napadnuti raunar nastavlja da akumulira
fragmente, uzalud ekajui one koji bi upotpunili datagram, troei vremenom sve veu koliinu
memorije. Napad trumfova" [CERT Smurf 1998] radi tako to veliki broj nevinih raunara
odgovara na pakete zahteva za ICMP eho (proitajte odeljak 4.4.3) koji sadre lanu IP adresu
izvora. To ima za rezultat veliki broj paketa odgovora na ICMP eho koji se alju raunaru ija je
IP adresa bila lana.
U napadu distribuiranog odbijanja usluge (distributeri denial-ofservice, DDoS), napada
najpre dobija pristup korisnikim nalozima na brojnim raunarima na Internetu (na primer,
uhoenjem lozinki ili drugim vrstama prodora u korisnikov nalog). Kao to je prikazano' na slici
8.26, napada onda instalira i puta u rad pro-gram-slugu na svakoj od lokacija, koji tiho eka
komandu od programa-gospodara. Sa velikim brojem takvih programa-slugu koji se izvravaju,
program-gospodar onda uspostavlja kontakt i nalae svakom od njih da zapone napad odbijanja
usluge usmeren na isti ciljni raunar. Rezultujui koordinirani napad je posebno razoran, zato to
dolazi sa tako mnogo napadakih raunara u isto vreme.
Napadi odbijanja usluge su punili novinske naslove u februaru 2000. godine, kada su bile
napadnute eBay, Yahoo, CNN i druge velike veb lokacije [Cnet 2000]. Teko je zatititi se od
DoS i (ak i vie) od DDoS napada. Filtriranje paketa nije lako, zato Stoje teko razlikovati
dobre od loih datagrama. Na primer, kako mrena barijera za filtriranje paketa moe da zna da
li je dolazei SYN za legitimnu kone-
kciju (na primer, kupac koji eli da obavi kupovinu na kompanijskoj veb lokaciji) ili zlonamemi
SYN, koji e vezati resurse servera a da kasnije ne obavi trostruku sin-hronizaciju. Kod
korienja IP varanja, teko je locirati pravi izvor napada. Izvestan broj novijih istraivakih
radova [Savage 2000; Snoeren 2001; Adler 2002] bavio se tehnikama za oznaavanje IP
zaglavlja dok prolaze kroz ruter da bi se tok DoS datagrama pratio unazad do njihovog izvora.
Jednom kada je kompromitovani izvorni raunar identifikovan, on moe da se stavi u karantin,
iako je to obino spor proces koji zahteva intervenciju oveka. Napad DDoS je ak i tei i
zahteva vie vremena za reenje.

8.7.5 Pljakanje
Pretpostavite da su Alisa i Bob u konekciji daje Trudi u poloaju da nadgleda pakete koji teku
izmeu Boba i Alise. Trudi moe da preuzme, ili opljaka, konekciju izmeu Alise i Boba.
Posebno, Trudi moe da prevari Boba da poveruje kako on i dalje komunicira sa Alisom, ak i
kada komunicira sa Trudi, Trudi prvo izbacuje Alisu pokretanjem napada odbijanja usluge protiv
nje. Poto je prislukivala Alisinu i Bobovu komunikaciju, Trudi zna celokupno stanje (na
primer, broj sekvence, broj ACK, najavljeni okvir primaoca) Alisine TCP konekcije sa Bobom.
Trudi na taj nain moe da napravi lane IP datagrame ka Bobu (koristei Alisinu adresu kao
adresu izvora) koji sadre vaee TCP segmente i proizvoljan korisniki teret. Zamislite
katastrofu koju Trudi moe da izazove u odnosu izmeu Boba i Alise!

8.8 - BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA
320!

Razni mreni napadi i bezbednosne pretnje prodiskutovani su u zbirci eseja [Denning 1997]
i u vrlo itljivoj Rubinovoj knjizi [Rubin 2001 j. Pregled napada o kojima postoje izvetaji
odrava se u CERT-ovom koordinacionom centru [CERT 2004], Proitajte i [Cisco Security
2004; Vovdock 1983; Bhimani 1996].

8. 8 Bezbednost u mnogo slojeva: studije primera
U prethodnim odeljcima, ispitali smo osnovna pitanja mrene sigurnosti, ukljuujui kriptografiju
pomou simetrinog i javnog kljua, autentifikaciju, raspodelu kljueva, integritet poruke i
digitalne potpise. Sada emo ispitati kako se ti alati koriste da bi se obezbedila sigurnost na
Internetu. Zanimljivo je da se mogu pruiti usluge bezbednosti na svakom od etiri gornja sloja
Intemetovih protokola. Kada se bezbednost osigurava za specifini protokol aplikacionog sloja,
onda e aplikacija koja koristi protokol dobijati jednu ili vie usluga bezbednosti, kao stoje
tajnost, aulen-tifikacija ili integritet. Kada se bezbednost osigurava za protokol transportnog
sloja, onda sve aplikacije koje koriste taj protokol dobijaju usluge bezbednosti transportnog
protokola. Kada se bezbednost prua za mreni sloj od raunara do raunara, onda svi segmenti
transportnog sloja (i zato svi podaci aplikacionog sloja) dobijaju usluge bezbednosti mrenog
sloja. Kada se bezbednost prua na nivou veze podataka, onda podaci u svim okvirima koji
putuju preko mree dobijaju ove bezbednosne usluge.
U ovom odeljku ispitujemo kako se bezbednosni alati koriste u aplikacionom, transportnom,
mrenom sloju i sloju veze podataka. Dosledno optoj strukturi ove knjige, poinjemo na vrhu
protokola i diskutujemo o bezbednosti u aplikacionom sloju. Na pristup e biti da iskoristimo
specifinu aplikaciju, elektronsku potu, kao studiju primera za bezbednost aplikacionog sloja.
Zatim se sputamo niz protokole. Ispitaemo SSL protokol (koji prua bezbednost na
transportnom sloju), IPsec (koji prua bezbednost na mrenom sloju) i bezbednost IEEE 802.11
protokola za beini LAN.
Mogli biste se zapitati zato se bezbednosna funkcionalnost prua na vie od jednog sloja na
Internetu. Zar ne bi bilo dovoljno da se funkcionalnost bezbednosti jednostavno prui na
mrenom sloju i zavri sa tim? Na ovo pitanje postoje dva odgovora. Prvo, mada bezbednost na
mrenom sloju moe da ponudi prekriva" ifrovanjem svih podataka u datagramima (odnosno,
svih segmenata transportnog sloja) i autentifikovanjem svih IP adresa izvora, ona ne moe da
prui bezbednost na nivou korisnika. Na primer, trgovinska lokacija ne moe da se pouzda u
bezbednost IP sloja da bi autentifikovala kupca koji kupuje robu na komercijalnoj lokaciji. Dakle,
postoji potreba za bezbednosnom funkcionalnou na viim slojevima kao i za prekrivaem na
niim slojevima. Drugo, obino je lake primeniti nove usluge Interneta, ukljuujui i usluge
bezbednosti, na viim nivoima protokola. Dok ekaju da se bezbednost iroko primeni na
mrenom sloju, to e se verovatno dogoditi kroz mnogo godina u budunosti, mnogi programeri
aplikacija to samo urade" i uvedu funkcionalnost bezbednosti u svoje omiljene aplikacije.
Klasini primer je Pretty Good Privacy (PGP), koji obezbeduje sigurnu elektronsku potu (o emu
emo govoriti kasnije u ovom odeljku). Zahtevajui samo klijentov i serverov aplikacioni kod,
PGP je bila jedna od prvih bezbednosnoih tehnologija koje se iroko koriste na Internetu.

8.8.1 Bezbedna elektronska pota
U ovom odeljku koristimo mnoge od tehnika uvedenih u prethodnom odeljku, da bismo
napravili projekat bezbednog sistema elektronske pote. Taj projekat visokog nivoa stvaramo na
postupan nain, tako to u svakoj fazi uvodimo nove usluge bezbednosti. Kod projektovanja
bezbednog sistema elektronske pote, imajmo na umu duhovit primer uveden u odeljku 8.1 -
ljubavnu aferu izmeu Alise i Boba. Zamislite da Alisa eli da poalje Bobu poruku elektronske
pote i da Trudi eli da bude uljez:
Pre nego to ponemo da projektujemo bezbedan sistem elektronske pote za Alisu i Boba,
trebalo bi prvo da razmotrimo koje bi bezbednosne karakteristike za njih bile najpoeljnije. To
je, pre svega, tajnost. Kao to je reeno u odeljku 8.1, ni Alisa ni Bob ne ele da Trudi ita
Alisinu poruku elektronske pote. Drugo svojstvo koje bi Alisa i Bob najverovatnije eleli da
vide u bezbednom sistemu elektronske pote je autentifikacija poiljaoca. Posebno, kada Bob
primi od Alise poruku ,,I don'C love you anymore. I never want to see you again. Formerly
yours, Al ice", on bi prirodno eleo da bude siguran daje poruka stigla od Alise, a ne od Trudi.
Drugo svojstvo koje bi dvoje ljubavnika centli je integritet poruke, odnosno, osiguranje da
poruka koju Alisa alje nije promenjena u toku puta do Boba. Najzad, sistem elektronske pote
bi trebalo da obezbedi autentifikaciju primaoca; odnosno, Alisa eli da bude sigurna da ona
stvarno alje pismo Bobu, a ne nekom drugom (na primer, Trudi) ko se predstavlja kao Bob.
Pa, hajde da ponemo sa reavanjem najznaajnije brige Alise i Boba, odnosno, tajnosti.
Najdirektniji nain da se obezbedi tajnost za Alisu je da ifruje poruku tehnologijom simetrinog
kljua (kao to je DES ili AES), a za Boba da deifruje poruku po njenom prijemu. Kao stoje
proi sku to vano u odeljku 8.2, ako je simetrini klju dovoljno dugaak i ako samo Alisa i Bob
imaju klju, onda je izuzetno teko da bilo ko drugi (ukljuujui Trudi) ita poruku. Mada je
ovakav pristup direktan, on ima osnovnu tekou o kojoj smo diskutovali u odeljku 8.2 - teko je
distribuirati simetrian klju tako da samo Alisa i Bob imaju njegove kopije. To je razlog zbog
kojeg mi razmatramo alternativni pristup, odnosno, kriptografiju javnim kljuem (koristei, na
primer, RSA). U pristupu javnog kljua, Bob ini svoj javni klju svima raspoloivim (na
primer, u serveru javnih kljueva ili na svojoj linoj veb stranici), Alisa ifruje svoju poruku
Bobovim javnim kljuem i alje je na Bobovu adresu elektronske pote. (ifrovana poruka je
enkapsulirana pomou MIME zaglavlja i poslala preko obinog SMTP-a, kao stoje objanjeno u
odeljku 2.4.) Kada Bob primi poruku, on je jednostavno deifruje pomou svog privatnog kljua.
Pod pretpostavkom da Alisa sigurno zna da je javni klju Bobov (i da je klju dovoljno
dugaak), ovaj pristup je odlino sredstvo da se obezbedi eljena tajnost. Meutim,

321 321 321 321
POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA 8.8 . BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA
705 705 705 705
i

problem je stoje ifrovanje javnim kljuem relativno neefikasno, posebno za duge poruke, (Duge
poruke elektronske pote su sada opteprisutne na Internetu, zahvaljujui sve veoj upotrebi
priloga, slika, zvuka i videa.)
Da bismo prevazili problem efikasnosti, hajde da koristimo klju sesije (disku-tovan u
odeljku 8.5). Alisa (1) sluajno bira simetrini klju sesije, Ks, (2) ifruje svoju poruku, m,
simetrinim kljuem, Ks, (3) ifruje simetrini klju Bobovim javnim kljuem, Kg*> (4) spaja
ifrovanu poruku i ifrovani simetrini klju da bi uobliila pakovanje" i (5) alje pakovanje na
Bobovu adresu elektronske pote. Postupci su ilustrovani na slici 8.27. (Na ovoj slici i na
sledeim slikama, +" predstavlja spajanje, a -" razdvajanje.) Kada Bob primi pakovanje, on (1)
koristi svoj privatni klju, KB; d\bi dobio simetrini klju, Ks, i (2) koristi simetrini klju Ks da
bi deifrovao poruku m.
Poto smo projektovali bezbedni sistem elektronske pote koji obezbeduje tajnost, hajde
sada da projektujemo drugi sistem, koji obezbeduje i autentifikaciju poiljaoca i integritet
poruka. Pretpostaviemo, za trenutak, da se Alisa i Bob vie ne brinu o tajnosti (oni ele da
podele svoja oseanja sa svima!), i zabrinuti su samo za autentifikaciju poiljaoca i integritet
poruka. Da bismo izvrili taj zadatak, koristimo digitalne potpise i izvode poruka, kao stoje
opisano u odeljku 8.4. Alisa (1) primenjuje he funkciju, H (na primer, MD5), na svoju poruku,
m, da bi dobila izvod iz poruke, (2) potpisuje rezultat he funkcije pomou svog privatnog kljua,
KA; da bi napravila digitalni potpis, (3) spaja originalnu (neifrovanu) poruku sa potpisom da bi
napravila pakovanje i (4) alje pakovanje na Bobovu adresu elektronske pote. Kada Bob primi
pakovanje, on (1) primenjuje Alisin javni klju, K/, na potpisani izvod poruke i (2) poredi
rezultat te operacije sa sopstvenim heom poruke, H. Postupci su ilustrovani na slici 8.28. Kao
stoje diskutovano u odeljku 8.5, ako su dva rezultata ista, Bob moe da bude prilino siguran u to
da je poruka dola od Alise i daje neizmenjena.
KRATAK OSVRT
FIL CIMERMAN I PGP
Filip R. Cimerman (Philip R. Zimmermann] je tvorac softvera Prelrv Good Privacv (PGP). Bio
je mela trogodinje kriminalne istrage, zato to je vlada tvrdila da su izvozna ogranienja SAD
prekrena kada se PGP, posle njegovog objavljivanja kao softvera za probu pre korienje
1991. godine, rairio po elom svetu. Posle objavljivanja PGP-a kao probnog softvero, neko
drugi ga je stavio na Internet i preuzimali su ga strani graani. Programi za kriptografiju su u
SAD saveznim zakonom kla-sifikovani kao municija i ne mogu da se izvoze.
Uprkos nedostatku novca, bilo kakvog plaenog osoblja i kompanije koja bi stala iza
njega, kao i intervencijama vlade, PGP je ipak postao najire korien softver za
ifrovanje elektronske pote na svetu. Zauujue je da je vlada SAD moda nehotice
doprinela irenju PGP-a, inei ga popularnijim upravo zbog Cimermanovog sluaja.
Vlada SAD je digla ruke od sluaja poetkom 1996. godine. Vest je proslavljena meu
aktivistima Interneta. Cimermanov sluaj je prerastao u priu o nevinoj linosti koja se bori za
svoja prava protiv maltretiranja od strane mone vlade. Vladino odustajanje bilo je dobrodola
vest, delimino zbog kampanje za cenzuru na Internetu u Kongresu i pritiska FBl-a da se
dozvoli poveano piislulkivanje od strane dravnih organa.
Poto je vlada odustala od njegovog sluaja, Cimerman je osnovao firmu PGP Inc., koju je
u decembru 1997. godine kupila kompanija Netvvork Associates. Cimerman je sada nezavisni
sovetnik u oblasti kriptografije.
Hajde sada da razmotrimo projektovanje sistema elektronske pote koji obezbeduje tajnost,
autentifikaciju poiljaoca i integritet poruke. To moe da se uradi kom-binovanjem postupaka na
slikama 8.27 i 8.28. Alisa prvo pravi prethodno pakovanje, tano kao na slici 8.28, koje se
sastoji od njene originalne poruke uz digitalno potpisani izvod poruke. Ona zatim obrauje to
prethodno pakovanje kao novu poruku i obrauje je kroz postupke poiljaoca na slici 8.27,
pravei novo pakovanje koje se alje Bobu. Postupci koje Alisa preduzima prikazani su na slici
8.29. Kada Bob primi pakovanje, on prvo primenjuje svoju stranu slike 8.27, a zatim svoju
stranu slike 8.28. Jasno je da ova konstrukcija obezbeduje tajnost, autentifikaciju poiljaoca i
integritet poruke. Zapazite da, u ovoj emi, Alisa koristi kriptografiju javnim kljuem dva puta:
jednom sa sopstvenim privatnim kljuem i jednom sa Bobovim javnim kljuen)! Slino tome,
Bob takoe koristi kriptografiju javnim kljuem dva puta - jednom sa svojim privatnim kljuem
i jednom sa Atisinim javnim kljuem.
Projekat bezbedne elektronske pote skiciran na slici 8.29 verovatno obezbeduje
zadovoljavajuu sigurnost veini korisnika elektronske pote i to u veini sluajeva.

8.8 . BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA
322 322 322 322
1"

Ali, postoji ipak jo jedno vano pitanje koje treba da se resi. Konstrukcija na slici 8.29 zahteva
da Alisa dobije Bobov javni klju, a da Bob dobije Alisin javni klju. Distribucija tih javnih
kljueva nije trivijalan problem. Na primer, Trudi bi mogla da se maskira u Boba i da da Alisi
svoj javni klju, tvrdei da je to Bobov javni klju, to bi joj omoguilo da primi poruku
namenjenu Bobu. Kao to smo nauili u odeljku 8.5, popularan nain distribucije javnih kljueva
je da se javni kljuevi overavaju koristei usluge sertifikacionog tela.

PGP
Prettv Good Privacv (PGP), kojeg je prvobitno napisao Fil Cimerman 1991. godine, postao je de
facto standardna ema za ifrovanje elektronske pote. Njegova veb lokacija prua vie od milion
stranica meseno korisnicima u 166 razliitih zemalja [PGPI 2002], Verzije PGP-a raspoloive
su u javnom domenu; na primer, moete da pronaete softver PGP za vau omiljenu platformu
kao i mnogo zanimljivih tekstova za itanje na lokaciji International PGP Home Page [PGPI
2002]. (Posebno zanimljiv je esej autora PGP-a [Zimmermann 1999].) PGP se takoe moe
komercijalno nabaviti, a na raspolaganju je i kao dodatak za mnoge agente korisnika elektronske
pote, ukljuujui Microsoftove Exchange i Outlook, kao i Eudoru firme Oualcomm.
Konstrukcija PGP-a je u sutini ista kao ona koja je prikazana na slici 8.29. Zavisno od verzije,
softver PGP koristi MD5 ili SHA za izraunavanje izvoda poruke; AST, trostruki DES, ili
IDEA za ifrovanje simetrinog kljua; i RSA za ifrovanje javnog kljua. Pored toga, PGP
obezbeduje i kompresiju podataka.
Kada se PGP instalira, softver stvara par javnih kljueva za korisnika. Javni klju moe da
se postavi u serveru javnih kljueva na korisnikovoj veb lokaciji. Privatni klju se titi
upotrebom lozinke. Lozinka treba da se unese svaki put kada kori-
snik pristupa privatnom kljuu. PGP prua korisniku opcije digitalnog potpisivanja poruke,
ifrovanja poruke, ili i digitalnog potpisivanja i ifrovanja. Na slici 8.30 prikazana je potpisana
PGP poruka. Ta poruka se pojavljuje posle zaglavlja MIME (Multipurpose Internet Mail
Extensions, vienamenska proirenja Internet pote). ifrovani podaci u poruci su K/ (H(m)),
odnosno, digitalno potpisan izvod poruke. Kao to smo ranije diskutovali, da bi Bob proverio
integritet poruke, on treba da ima pristup Alisinom javnom kljuu,
Na slici 8.31 prikazana je tajna PGP poruka. Ta poruka se takoe pojavljuje posle zaglavlja
MIME. Naravno, poruka otvorenog teksta nije ukljuena unutar tajne poruke elektronske pote.
Kada poiljalac (kao Alisa) eli i tajnost i integritet, PGP sadri poruku kao to je ona na slici
8.31 unutar poruke sa slike 8.30.
PGP takoe obezbeduje mehanizam za overu javnih kljueva, ali je taj mehanizam sasvim
drugaiji od konvencionalnijih metoda sertifikacionog tela. Javni kljuevi PGP overavaju se
pomou Weba od poverenja. Alisa moe sama da overi svaki par klju/korisniko ime kada
veruje da lanovi para zaista pripadaju jedan drugom. Pored toga, PGP dozvoljava Alisi da kae
da ona veruje drugom korisniku i da jami za autentinost vie kljueva. Neki korisnici PGP-a
potpisuju jedni drugima kljueve. Oni se fiziki okupljaju, razmenjuju diskete koje sadre javne
kljueve i overavaju jedni drugima kljueve potpisujui ih pomou svojih privatnih kljueva.
Javni kljuevi PGP se takode distribuiraju na PGP serverima javnih kljueva na Internetu. Kada
korisnik podnese javni klju takvom serveru, on memorie kopiju kljua, alje kopiju kljua
svim drugim serverima javnih kljueva i stavlja na raspolaganje klju svakome ko ga trai. Mada
strane za potpisivanje kljueva i serveri PGP javnih kljueva stvarno postoje, daleko uobiajeniji
nain da korisnici distribuiraju svoje javne kljueve je da ih izlau na svojim linim veb
stranicama i oglaavaju ih u svojim porukama elektronske pote.

8.8 . BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA 323

---- BEGIN PGP SIGNED MESSAGE -----
Hash:
SHA1 Bob:
Can I see you tonight?
Passionately yours, Alice
---- BEGIN PGP SIGNATURE -----
Version: PGP for Personal Privacy 5.0
Charset: noconv
yhHJRHhGJGhgg/12EpJ+lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2
---- END PGP SIGNATURE -----

Slika 8.30 Slika 8.30 Slika 8.30 Slika 8.30 Pofpisana PGP poruka
----- BEGIN PGP MESSAGE ---
Version: PGP for Personal Privacy 5.0
u2R4d+/jKmn8Bc5+hgDsqAewsDfrGdszX681iKmSF6Gc4sDfcXyt
RfdS10juHgbcfDssWe7/K=lKhnMikLoO + l/BvcX^t==Ujk9PbcD'5
Thdf2awQfgHbnmKlok8iy6gThlp
----- END PGP MESSAGE

Slika 8.31 Slika 8.31 Slika 8.31 Slika 8.31 Tajna PGP poruka

8.8.2 Sloj bezbednih soketa (SSL) i bezbednost transportnog
sloja (TLS)
U prethodnom odeljku, razmatrali smo kako aplikacioni sloj moe da koristi (u bezbednosti
elektronske pote) razliite bezbednosne mehanizme koje smo prouili ranije u ovom poglavlju:
ifrovanje, autentifikaciju, distribuciju kljueva, integritet poruka i digitalne potpise. U ovom
odeljku, nastaviemo nae studije primera razliitih bezbednosnih mehanizama sputajui se sloj
nie u protokolima i objanjavajui bezbedne sokete i bezbednost transportnog sloja. Kao primer
posluie nam aplikacija Internet trgovine, zato to su poslovne i fmansijske transakcije
znaajna pokretaka sila za bezbednost na Internetu.
Hajde da proetamo kroz uobiajeni scenario Internet trgovine. Bob krstari Webom i stie
na lokaciju Alice Incorporated, gde se prodaje neka trajna roba. Na lokaciji Alice Incorporated
prikazuje se formular u koji se od Boba oekuje da unese eljenu koliinu, svoju adresu i broj
svoje kartice za plaanje, Bob unosi te informacije, miem bira submlt" i zatim oekuje da
primi robu (recimo, preko obine pote); on takoe oekuje da primi raun za robu u svom
sledeem izvetaju platne kartice. To sve lepo zvui, ali ako nisu preduzete nikakve mere
bezbednosti - kao
to su ifrovanje ili autentifikacija - Bob bi mogao da doivi nekoliko iznenaenja.
Uljez bi mogao da presretne porudbinu i dobije informacije o Bobovoj platnoj kartici. U
tom sluaju uljez bi mogao da kupuje na Bobov raun.
Lokacija bi mogla da prikazuje poznati logo Alice Incorporated, ali da u stvari bude lokacija
koju odrava Trudi, koja se maskira u Alice Incorporated. Trudi bi mogla da uzme Bobov
novac i pobegne. Ili, Trudi bi mogla da pravi sopstvene kupovine i optereuje tim
trokovima Bobov raun.
Mogua su i mnoga druga iznenaenja, a mi emo o nekima od njih raspravljati u sledeem
pododeljku. Ali dva problema koja smo gore istakli su najozbiljniji. Trgovina na Internetu koja
koristi protokol SSL reava oba ova problema.
Sloj bezbednih soketa (secure sockets layer, SSL), koji je prvobitno razvio Netscape, jeste
protokol projektovan da obezbedi ifrovanje podataka i autentifikaciju izmeu veb klijenta i veb
servera. Protokol poinje fazom provere spremnosti za prenos kojom se dogovaraju algoritam
ifrovanja (na primer, DES ili IDEA) i kljuevi, i klijentu autentifikuje server. Postoji i druga
mogunost, a to je da se klijent autentifikuje serveru. Kada se klijent i server sinhronizuju i
pone prenos podataka aplikacije, svi podaci se ifruju koristei kljueve sesije dogovorene za
vreme faze sinhronizacije. SSL se iroko koristi u trgovini na Internetu, budui daje
implementiran u skoro svim popularnim pretraivaima i veb serverima. Pored toga, on je i
osnova protokola Bezbednost transportnog sloja (Transport Layer Security, TLS) [RFC 2246].
SSL i TLS nisu ogranieni na primenu na VVebu; na primer, oni na slian nain mogu da
se upotrebe za autentifikaciju i ifrovanje podataka za IMAP (Internet Mail Access Protocol)
pristup poti. SSL moe da se posmatra kao sloj koji se nalazi izmeu aplikacionog i
transportnog sloja. Na predajnoj strani, SSL prima podatke (kao to su HTTP ili IMAP poruka iz
aplikacije), ifruje podatke i usmerava ifro-vane podatke na TCP soket. Na prijemnoj strani,
SSL ita iz TCP soketa, deifruje podatke i usmerava ih u aplikaciju. Iako SSL moe da se
upotrebi sa mnogim Internet aplikacijama, mi emo raspravljati o njegovim mogunostima u
kontekstu Weba, gde se danas koristi uglavnom za Internet trgovinu.
SSL obezbeduje sledea svojstva:
SSL autentifikaciju servera, koja korisniku dozvoljava da potvrdi identitet servera.
Pretr'aiva sa omoguenim SSL-om odrava listu serlifikacionog tela (CA), zajedno sa
javnim kljuevima CA-ova. Kada pretraiva eli da posluje sa veb serverom na kome je
ukljuen SSL, on od servera dobija uverenje koje sadri serverov javni klju. Uverenje izdaje
(odnosno, digitalno potpisuje) CA koji se nalazi u klijentovoj listi CA-ova od poverenja. To
svojstvo dozvoljava pretrai-vau da autentifikuje server pre nego to korisnik podnese broj
kartice za plaanje. U kontekstu prethodnog primera, ta autentifikacija servera omoguava
Bobu da proveri da li zaista alje broj svoje kartice za plaanje lokaciji Alice Incorporated, a
ne nekom drugom ko bi mogao da se maskira kao Alice Incorporated.
SSL autentifikaciju klijenta, koja serveru dozvoljava da potvrdi identitet korisnika. Analogno
autentifikaciji servera, autentifikacija klijenta koristi klijentova uverenja, koja su takoe
izdali CA-ovi. Ta autentifikacija je znaajna ako je ser-

324 324 324 324 POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA 8.8 . BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRiMERA 324 324 324 324

ver, na primer, banka koja korisniku alje poverljivu finansijsku informaciju i eli da proveri
identitet primaoca. Iako podrana od SSL-a, autentifikacija klijenta je opciona. Da bismo
usredsredili nau diskusiju, mi emo je u daljem izlaganju zanemarivati.
ifrovanu SSL sesiju, u kojoj su sve informacije poslate izmeu pretraivaa i servera
ifrovane pomou predajnog softvera (pretraivaa ili veb servera) i dei-frovane pomou
prijemnog softvera (pretraivaa ili veb servera). Ova tajnost moe da bude vana i kupcu i
prodavcu. Takode, SSL obezbeduje mehanizam za otkrivanje falsifikovanja informacija od
strane nekog uljeza.
Kako radi SSL
Korisnik, recimo Bob, krstari Webom i bira link koji ga dovodi do bezbedne stranice na kojoj je
smeten Alisin server osposobljen za SSL. Protokolski deo URL-a za tu stranicu je https", a ne
uobiajeno http". Pretraiva i server tada izvravaju SSL protokol za proveru spremnosti za
prenos, koji (1) autentifikuje server i (2) stvara deljeni simetrini klju. U oba ova zadatka koristi
se RSA tehnologija javnih kljueva. Glavni tok dogaaja u fazi provere spremnosti za prenos
prikazanje na slici 8.32. Za vreme te faze, Alisa alje Bobu svoje uverenje, iz koga Bob dobija
njen javni klju. Tada Bob stvara sluajni simetrini klju, ifruje ga pomou Alisinog javnog
kljua i alje ifrovani klju Alisi. Bob i Alisa sada dele simetrini klju sesije. Kada se
sinhronizacija sa serverom zavri, svi podaci koji se alju izmeu pretraivaa i servera (preko
TCP konekcija) ifrovani su pomou simetrinog kljua sesije.
Poto smo dali globalni pregled SSL-a, hajde da blie pogledamo neke od najvanijih
detalja. U SSLsinhronizaciji preduzimaju se sledei postupci:
1. Pretraiva alje serveru broj svoje SSL verzije i spisak najpoeljnijih kripto-grafskih
metoda koje predlae za korienje. On to radi da bi se sa serverom dogovorio koji
algoritam simetrinog kljua i koja he funkcija e se koristiti.
2. Server alje pretraivau broj svoje SSL verzije, svoju odluku o kriptografskoj metodi i
svoje uverenje. Setite se da uverenje obuhvata serverov RSA javni klju i daje potvreno
od nekog CA-a; odnosno, uverenje je potpisano CA-ovim privatnim kljuem.
3. Pretraiva ima listu CA-ova od poverenja i javni klju za svaki CAsa liste. Kada
pretraiva primi uverenje od servera, on proverava da lije CAna listi. Ako nije, korisnik
dobija upozorenje i obavetenje da ne moe da se automatski uspostavi ifrovana i
autenttfikovana konekcija. Ako je CA na listi, pretraiva koristi CA-ov javni klju da bi
proverio uverenje i dobio serverov javni klju.
4. Pretraiva stvara simetrini klju sesije, ifruje ga pomou serverovog javnog kljua, i
alje serveru ifrovani klju sesije.
5. Pretraiva alje serveru poruku obavetavajui ga da e budue poruke od klijenta biti
ifrovane pomou kljua sesije. On zatim alje posebnu (ifrovanu) poruku, pokazujui daje
pretraivaev deo sinhronizacije zavren.
6. Server alje pretraivau poruku obavetavajui ga da e budue poruke od servera biti
ifrovane pomou kljua sesije. On zatim alje posebnu (ifrovanu) poniku, pokazujui daje
serverov deo sinhronizacije zavren.
7. Sada je SSL sinhronizacija zavrena, a SSL sesija je poela. Pretraiva i server koriste
kljueve sesije da bi ifrovali i deifrovali podatke koje alju jedan drugom i da bi
proveravali njihov integritet.
SSL sinhronizacija u stvari ima mnogo vie postupaka od'onih koji su gore navedeni. Vie
detalja o SSL-u moete da pronaete na [Netscape SSL 1998]. Pored kupovine putem kartica za
plaanje, ovde istiemo da SSL moe da se koristi (i koristi se) za druge finansijske transakcije,
ukljuujui onlajn bankarstvo i robnu trgovinu.


Ogranienja SSL-a u Internet trgovini
Zbog svoje jednostavnosti i ranog razvoja, SSL je iroko implementiran u pretrai-vaima,
serverima i komercijalnim proizvodima za Internet. Ti serveri i pretraivai osposobljeni za SSL
obezbeuju popularnu platformu za transakcije pomou platnih kartica. I pored toga, trebalo bi
imati na umu da SSL nije posebno pravljen za transakcije sa platnim karticama, nego za
svojevrsnu bezbednu komunikaciju izmeu klijenta i servera. Zbog toga SSL-u nedostaju mnoga
svojstva koja bi industrija platnih kartica volela da ima u protokolu za trgovinu na Internetu.
Razmotrite jo jednom ta se deava kada Bob kupuje od firme Alice Incorpo-rated preko
SSL-a. Potpisano uverenje koje Bob prima od Alise ubeuje Boba da on stvarno ima posla sa
firmom Alice Incorporated i da je to dobronamema kompanija. Meutim, generiko uverenje ne
pokazuje da lije Alice Incorporated ovlaena da prihvata kupovine putem platnih kartica, niti da
li je kompanija pouzdan trgovac. To otvara vrata trgovinskoj prevari. Slian problem postoji i za
ovlaenje klijenta. ak ako je iskoriena SSL autentifikacija klijenta, uverenje klijenta ne
povezuje Boba sa odreenom ovlaenom platnom karticom; dakle, Alice Incorporated nema
nikakvo osiguranje daje Bob ovlaen da kupuje pomou platne kartice, To otvara vrata svim
vrstama prevara, ukljuujui kupovinu pomou ukradene platne kartice i kupevo nepriznavanje
kupljene robe.

8.8.3 Bezbednost mrenog sloja: IPsec
Protokol IP securitv, poznatiji kao IPsec, jeste niz protokola koji pruaju bezbednost na
mrenom sloju. IPsec je vrlo sloen, a njegovi razliiti delovi opisani su u vie od dvanaestak
RFC-ova. U ovom odeljku, govoriemo o IPsec-u u specifinom kontekstu, odnosno, u
kontekstu gde svi raunari na Internetu podravaju IPsec. Iako e do toga proi jo mnogo
godina, to e za sada pojednostaviti priu i pomoi nam da razumemo glavna svojstva IPsec-a.
Dva kljuna RFC-a su RFC 2401, u kome se opisuje ukupna arhitektura IP bezbednosti i RFC
2411, u kome se daje pregled niza protokola IPsec i dokumenata koji ga opisuju.
Pre nego to uemo u specifinosti IPsec-a, hajde da se vratimo unazad i razmotrimo ta to
znai pruiti bezbednost na mrenom sloju. Pogledajmo, pre toga, ta znai obezbediti tajnost
mrenog sloja. Mreni sloj bi obezbedio tajnost ako bi svi podaci koje nose svi IP datagrami bili
ifrovani. To znai da kad god raunar eli da poalje datagram, on ifruje polje za podatke pre
nego to ga isporui mrei. U principu, ifrovanje bi moglo da se izvede pomou simetrinog
kljua, javnog kljua ili pomou kljueva sesije koji su dogovoreni korienjem ifrovanja
javnim kljuem, Polje za podatke moglo bi da bude TCP segment, UDP segment, poruka ICMP
itd. Ako bi takva usluga mrenog sloja bila prisutna, svi podaci koje alju raunari - ukljuujui
tu elektronsku potu, veb stranice, kontrolne poruke i poruke upravljanja (kao to su ICMP i
SNMP) - bili bi sakriveni za bilo koju treu stranu koja prislukuje" mreu. Dakle, takva usluga
bi obezbedila pokriva za celokupan saobraaj na Internetu, pruajui nam na taj nain izvestan
oseaj bezbednosti.
Pored tajnosti, moglo bi se takoe poeleti da mreni sloj obezbedi i autentifikaciju izvora.
Kada raunar odredita primi IP datagram sa odreenom IP adresom izvora, on autentifikuje
izvor uveravajui se daje IP datagram zaista stvoren u raunaru sa tom IP adresom. Takva
usluga spreava da se autentifikuju datagrami sa lanim IP adresama.
U nizu protokola IPsec postoje dva glavna protokola: protokol za autcntifika-ciju zaglavlja
(Authentication Header, AH) i protokol za enkapsulaciju bezbe-dnosnog tereta (Encapsulation
Secttrity Payload Protocol, ESP). Kada izvorni raunar alje bezbedne datagrame odredinom
raunaru, on to radi pomou AH protokola ili pomou ESP protokola. Protokol AH obezbeduje
autentifikaciju izvora i integritet podataka, ali ne obezbeduje tajnost. Protokol ESP obezbeduje
autentifikaciju, integritet podataka*! tajnost. Objedinjujui vie usluga, protokol ESP je prirodno
sloeniji i zahteva vie obrade od AH protokola.
I u AH i u ESP protokolu, pre slanja bezbednih datagrama od izvornog do odredinog
raunara, izvor i mreni raunari vre sinbronizaciju i stvaraju logiku konekciju mrenog sloja.
Taj logiki kanal zove se asocijacija bezbednosti {Security Association, SA). Dakle, IPsec
transformie uobiajeni mreni sloj Interneta bez konekcija u sloj sa logikim konekcijama!
Logika konekcija koju definie SA je simpleksna konekcija; to znai, da je ona jednosmerna.
Ako oba raunara ele da alju jedan drugom bezbedne datagrame, onda je potrebno da se
uspostave dve SA-e (odnosno, logike konekcije), po jedna u svakom smeni. SA je jedinstveno
identifi-kovana trojkom koja se sastoji od:
identifikatora bezbednosnog protokola (AH ili ESP);
IP adrese izvora za simpleksnu konekciju;
32-bitnog identifikatora konekcije koji se zove Security Parameter Index (SPI).
Za dam SA (odnosno, dam logiku konekciju od izvornog do odredinog raunara), svaki
IPsec datagram e imati specijalno polje za SPI. Svi datagrami u konekciji SA koristie istu
vrednost SPI u tom polju.

Protokol za autentifikaciju zaglavlja (AH)
Kao to je gore napomenuto, protokol AH obezbeduje autentifikaciju izvornog raunara i
integritet podataka, ali ne i njihovu tajnost. Kada izvorni raunar eli da poalje jedan datagram
ili vie datagrama na neko odredite, on prvo uspostavlja SA sa odreditem. Poto je uspostavio
SA, izvor moe da alje bezbedne datagrame odredinom raunaru. Bezbedni datagrami
ukljuuju AH zaglavlje, koje je umetnuto izmeu originalnih podataka IP datagrama (na primer,
TCP ili UDP segment) i IP zaglavlja, kao stoje prikazano na slici 8.33. Na taj nain AH
zaglavlje poveava polje originalnih podataka i to poveano polje za podatke se enkapsulira kao
standardni IP datagram. Za polje protokola u IP zaglavlju, upotrebljena je vrednost 51 da bi se
pokazalo da datagram ukljuuje AH zaglavlje. Kada odredini raunar primi

8.8 BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA
326 326 326 326^ ^^ ^

IP datagram, on zapisuje 51 u polju protokola i obrauje datagram koristei AH protokol. (Setite se
da se polje za protokol u IP datagramu koristi za odreivanje protokola vieg sloja - na primer, UDP,
TCP ili ICMP - kome e se proslediti deo IP datagrama sa podacima.) Ruteri na putu izmeu izvora i
odredita obrauju datagrame kao i uvek - oni ispituju IP adresu odredita i u skladu sa njom
prosleduju datagrame.
Zaglavlje AH obuhvata vie polja, odnosno:
Polje Next Header, koje ima ulogu polja za protokol u obinom datagramu. Ono pokazuje da li je
podatak koji sledi iza AH zaglavlja TCP segment, UDP segment, ICMP segment itd. (Setite se
da se polje za protokol u IP datagramu sada koristi da bi ukazalo na AH protokol, pa ne moe
vie da se upotrebi da bi ukazalo na protokol transportnog sloja.)
Polje Securitv Parametar lndex (SPI), proizvoljna 32-bitna vrednost koja, u kombinaciji sa IP
adresom odredita i bezbednosnim protokolom, jedinstveno identifikuje SA za datagram.
Polje Seguence Number, 32-bitno polje koje sadri broj sekvence za svaki datagram. Ono je u
poetku podeeno na 0 prilikom uspostavljanja konekcije SA. Protokol AH koristi brojeve
sekvenci da bi spreio napade reprodukcijom i oveka u sredini (proitajte odeljak 8.3).
Polje Auihetitication Data, polje promenljive duine koje sadri potpisan izvod iz poruke
(odnosno, digitalni potpis) za taj datagram. Izvod iz poruke izraunava se preko originalnog IP
datagrama, obezbeujui tako autentifikaciju izvornog raunara i integritet IP datagrama. Digitalni
potpis se izraunava korienjem algoritma koji odreuje SA, kao stoje MD5 ili SHA.
Kada odredini raunar primi IP datagram sa AH zaglavljem, on odreuje SA za datagram i
zatim autentifikuje integritet datagrama obraujui polje sa podacima autentifikacije. IPsec za
autentifikaciju (i za AH i za ESP protokol) koristi emu koja se zove HMAC, koja je ifrovan izvod
poruke opisan u knjizi [RFC 2104], HMAC za autentifikaciju poruke koristi deljeni tajni klju izmeu
dve strane, a ne metode javnog kljua. Vie detalja o AH protokolu moe se pronai u knjizi [RFC
2402].
Protokol ESP
Protokol ESP obezbeduje tajnost mrenog sloja, kao i autentifikaciju izvornog raunara i integritet
podataka. Jo jednom, sve poinje sa izvornim raunarom koji uspostavlja SA sa odredinim
raunarom. Tada izvorni raunar moe da poalje bezbedne datagrame odredinom raunaru. Kao
stoje prikazano na slici 8.34, bezbedni datagram se pravi uokvirivanjem podataka originalnog IP
datagrama pomou zaglavlja i zavrnog zapisa, a zatim umetanjem tih enkapsuliranih podataka u
polje za podatke IP datagrama. Vrednost 50 se uzima za polje protokola u zaglavlju IP datagrama,
da bi pokazala da datagram ukljuuje ESP zaglavlje i zavrni zapis. Kada odredini raunar primi IP
datagram, on belei 50 u polju za protokol i obrauje datagram koristei protokol ESP. Kao st oj e
prikazano na slici 8.34, podaci originalnog IP datagrama sa ESP poljem zavrnog zapisa su
ifrovani. Tajnost se obezbeduje pomou ifrovanja DES-CBC [RFC 2405]. Zaglavlje ESP sastoji se
od 32-bitnog polja za SPI i 32-bitnog polja za broj sekvence, koji imaju istu ulogu kao u protokolu
AH. Zavrni zapis ukljuuje polje Next Header, koje takoe ima istu ulogu kao u AH. Zapazite da
zato to je polje Next Header ifrovano zajedno sa originalnim podacima, uljez nee moi da odredi
upotrebljeni transportni protokol. Iza zavrnog zapisa postoji polje Authentication Data, koje takode
ima istu ulogu kao u protokolu AH. Vie detalja o ESP protokolu moe se pronai u knjizi [RFC
2406].

SA i upravljanje kljuevima
Za uspenu primenu IPseca, potrebna je skalabilna i automatizovana SA i ema za upravljanje
kljuevima. Za ove zadatke definisano je vie protokola.
Algoritam za razmenu kljueva (Internet Key Exchange, IKE) [RFC 2409] je podrazumevan
alat za upravljanje kljuevima za IPsec.
Protokol za bezbednosnu asocijaciju i upravljanje kljuevima (Internet Security
Association and Key Management Protocol, ISKMP) definie procedure za uspostavljanje i
ukidanje konekcije SA [RFC 2407; RFC 2408]. ISKMP-ova bezbednosna asocijacija je sasvim
razdvojena od IKE razmene kljueva.


Ovim se zavrava naa diskusija o IPsecu. Govorili smo o IPsecu u kontekstu IPv4 i
transportnog reima". IPsec takoe definie mnelski reim", u kome funkcionalnost
bezbednosti uvode ruteri, a ne raunari. Najzad, IPsec opisuje procedure ifrovanja za IPv6 kao i
za IPv4.

8.8.4 Bezbednost u IEEE 802.11
Bezbednost je posebno znaajna u beinim mreama, gde radio-talasi koji nose okvire mogu da
se prostiru daleko van zgrada u kojima se nalaze osnovna beina stanica (e) i raunari. Dobar
primer je 18-meseni ratni" napor koji je preduzeo Piter ipli, vozei se unaokolo po zalivu San
Franciska sa prenosnim raunarom i karticom za 802.11, traei beine mree koje su bile
vidljive" van zgrade, o emu moete itati u knjizi [Ship!ey 2001], On je registrovao vie od
9000 takvih mrea; jedan ugao ulica u San Francisku ponudio mu je est razliitih raspoloivih
mrea! Stoje moda jo vise za uzbunu, ipli je zapazio da 85 procenata od tih 9000 mrea ak i
ne koristi (kao to emo videti) dosta slabe mehanizme u originalnom standardu 802.11.
Pitanje bezbednosti u 802.11 privuklo je veliku panju, kako u tehnikim krugovima, tako i
u medijima. Mada je diskusija bila iroka, bilo je malo debate u pravom smislu rei - izgleda da
postoji opta saglasnost da originalna specifikacija 802.11 sadri brojne ozbiljne nedostatke.
Zaista, sada moe da se preuzme softver u javnom domenu koji eksploatie te pukotine, inei
korisnike obinih sigurnosnih mehanizama 802.11 toliko otvorenim za bezbednosne napade
koliko i onih 85 % korisnika beinih mrea u oblasti zaliva San Franciska koji uopte ne koriste
bezbednosna svojstva.
U daljem tekstu, govoriemo o bezbednosnim mehanizmima koji su u poetku
standardizovani u specifikaciji 802.11, grupno poznatim kao Wired Equivalent Privacv
CVVEP). Kao to mu i samo ime govori, WEP je namenjen da ostvari nivo bezbednosti u
mreama 802.11 sban onom koji se moe nai u oienim mreama. Zatim emo neto rei o
pukotinama u WEP-u i o standardu 802.11 i, fundamentalno bezbednijom verzijom 802.11 koja
je usvojena 2004. godine.

Wired Equivalent Privacy (WEP)
Protokol IEEE 802.11 WEP [IEEE 802.11 1999] obezbeduje autentifikaciju i ifrovanje
podataka izmeu raunara i beine pristupne take (odnosno, osnovne stanice), koristei pristup
simetrinog deljenog kljua. WEP ne odreuje algoritam za upravljanje kljuevima, pa se
podrazumeva da su se raunar i beina pristupna taka nekako sporazumeli o kljuu preko
metoda van opsega. Autentifikacija je izvrena kao u protokolu $ p 4 . 7 koji smo razvili u
odeljku 8.3. Time su obuhvaena etiri postupka:
1. Beini raunar prvo zahteva autentifikaciju od strane pristupne take.
2. Pristupna taka odgovara na zahtev za autentifikaciju 128-bajtnomjednokra-tnom
vrednocu.
3. Beini raunar ifruje jednokratnu vrednost koristei simetrini klju koji deli sa
pristupnom takom.
4. Pristupna taka deifruje jednokratnu vrednost.
Ako deifrovana jednokratna vrednost odgovara onoj koja je prvobitno poslata raunani, onda je
pristupna taka autentifikovala raunar.
Algoritam WEPza ifrovanje podataka ilustrovan je na slici 8.35. Tajni 40-bitni simetrini
klju, Ks, po pretpostavci poznaju i raunar i pristupna taka. Pored toga, 24-bitni inicijalizacioni
vektor (IV) dodaje se na 40-bitni klju da bi se stvorio 64-bitni klju koji e se koristiti za
ifrovanje jednog okvira. IV e se menjati od jednog do drugog okvira, pa e zato svaki okvir
biti ifrovan razliitim 64-bitnim kljuem. ifrovanje se izvrava na sledei nain. Prvo se
izraunava etvorobajtna CRC vrednost (proitajte odeljak 5.2) za polje podataka. Ovo polje i
etiri CRC bajta se zatim ifruju koristei ifru RC4. Ovde neemo objanjavati detalje u vezi sa
ifrom RC4 (njih moete nai u knjizi [Schneier 1995]). Za nau namenu, dovoljno je znati da,
kada mu se predstavi vrednost kljua (u ovom sluaju, 64-bitnog kljua (KÎV)), algoritam RC4
proizvodi niz vrednosti kljueva, k/
f
\ k2
n
', k3
lv
,.,. koji se koriste za ifrovanje podataka i CRC
vrednosti unutar postojeeg okvira. Iz praktinih razloga, moemo da zamislimo da se te
operacije izvravaju odjednom nad jednim bajtom. ifrovanje se izvodi izvravanjem operacije
ekskluzivno ILI /-tog bajta podataka, di} sa i-tim kljuem, ft/
1
', u nizu vrednosti kljueva koje je
stvorio par (KÎV) da bi proizveo i-ti bajt ifrovanog teksta, c:.

c i =d j XORk f
v
Vrednost IV menja se od jednog okvira do sledeeg i ukljuena je u otvorenom tekstu u
zaglavlju svakog WEP-ifrovanog okvira 802.11, kao Stoje prikazano na slici 8.35. Primalac
uzima tajni 40-bitni simetrini klju koji deli sa poiljaocem, dodaje IV i koristi rezultujui
64-bitni klju (koji je identian kljuu koji je poiljalac upotrebio za ifrovanje) da bi deifrovao
okvir.

d, = c i XOKk f
y
Pravilna upotreba algoritma RC4 zahteva da se ista 64-bitna vrednost kljua nikada ne
koristi vie od jednog puta. Setite se da se WEP klju menja od okvira do okvira. Za dati Ks (koji
se retko menja, ako to uopte ini), ovo znai da postoji samo 2
2a
jedinstvenih kljueva. Ako se
ti kljuevi retko biraju, moe se pokazati [Walker 2000] da je verovatnoa da se izabere ista
vrednost IV (i zato koristi isti 64-bitni klju) vea od 99 procenata posle samo 12000 okvira. Sa
okvirima veliine

328 POGLAVLJE 8 BEZBEDNOST U RAUNARSKIM MREAMA 8.8 BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA 719

1 K i brzinom prenosa podataka od 11 Mb/s, potrebno je samo nekoliko sekundi da se prenese
12000 okvira. tavie, kako se IV u okviru prenosi u otvorenom tekstu, prislukiva e znati
kada se koristi duplikat vrednosti IV.
Da biste shvatili jedan od vie problema koji se pojavljuju kada se koristi duplikat kljua,
razmotrite sledei napad izabranim otvorenim tekstom koji Trudi preduzima protiv Alise.
Pretpostavite da Trudi (moda koristei IP varanje) alje zahtev (na primer, HTTP ili FTP) ka
Alisi da prenese datoteku sa poznatim sadrajem, d,,
d2> d3, d4, ____ Trudi takode posmatra ifrovane podatke c,, c2, c3,c4 ---------------- Kako je dt
= CjXOR k!
v
, ako izvrimo eksluzivno ILI ci sa svake strane ove jednaine, imamo:

4XORc , _ k\
v
Pomou ove relacije, Trudi moe da upotrebi poznate vrednosti d-t i ci da bi izra-unala kj
v
.
Sledei put kada Trudi vidi da se koristi ista vrednost IV, ona e znati sekvencu kljueva k/
v
y
k2
IV
, k}'
v
,. . . i na taj nain e moi da deifruje ifrovanu poruku.
Postoji i vie dodatnih briga sa WEP-om. U knjizi [Fluhler 2001], opisan je napad koji
koristi poznatu slabost RC4 kada se odaberu izvesni slabi kljuevi. U radu [Stubblefield 2002]
govori se o efikasnim nainima da se implementira i eksploatie taj napad. Druga nevolja sa
WEP-om obuhvata CRC bitove, prikazane na slici 8.35 i prenesene u 802.11 okviru da bi otkrili
promenjene bitove u korisnom teretu. Meutim, napada koji promeni ifrovani sadraj
(odnosno, zameni originalne podatke neim besmislenim), izrauna CRC preko zamenjenog
besmislenog sadraja i smesti CRC u WEP okvir, moe da napravi 802.11 okvir koji e primalac
da prihvati. Ono to je ovde potrebno su tehnike za integritet poruka, kao one koje smo prouili u
odeljku 8.4, da bi se otkrilo falsifikovanje ili zamena sadraja. Za vie detalja o bezbednosti
WEP-a, proitajte [Walker 2000; Weatherspoon 2000, 802.11 Security 2004] i reference koje se
tamo navode.
IEEE802.111
Uskoro posle izdanja IEEE 802.11 1999. godine, poeo je rad na razvoju nove i njegove
poboljane verzije sa jaim bezbednosnim mehanizmima. Novi standard, poznat kao 802.11 i
prolazi kroz konanu ratifikaciju i trebalo bi da se odobri poetkom 2004. godine. Kao to emo
videti, dok je WEP obezbedio relativno slabo ifrovanje, samo jedan nain da se izvri
autentifikacija i nijedan mehanizam za distribuciju kljueva, IEEE 802.I l i ima mnogo, jae
oblike ifrovanja, proir-ljiv skup mehanizama za autentifikaciju i mehanizam za distribuciju
kljueva. U nastavku emo dati pregled 802.11 i; odlian tehniki pregled (ivi zvuk) 802.1
l i j e [TechOnline 2004].
Na slici 8.36 dat je pregled okvira 802.I l i . Pored beinog klijenta i pristupne take (AP),
802.1 l i definie i server za autentifikaciju sa kojim AP moe da komunicira. Razdvajanje
servera za autentifikaciju od AP dozvoljava serveru za autentifikaciju da opsluuje mnogo
AP-ova, centralizujui (esto osetljive) odluke u pogledu autentifikacije i pristupa unutar jednog
servera i drei cenu i sloenost AP na niskom nivou. 802.11 i radi u etiri faze:

8.9 . REZIME 721
1. Otkrie. U fazi otkria, AP oglaava svoje prisustvo i oblike autentifikacije i ifrovanja
koje moe da prui beinom klijentskom voru. Klijent onda zahteva odreene oblike
autentifikacije i ifrovanja po elji. Iako klijent i AP ve razmenjuju poruke, klijent jo
uvek nije autentifikovan, niti ima klju za ifrovanje, pa e tako biti zahtevano vie
postupaka pre nego to klijent bude mogao da komunicira sa proizvoljnim udaljenim
raunarom preko beinog kanala.
2. Meusobna autentifikacija i generisanje glavnog kljua (MK). Autentifikacija se deava
izmeu beinog klijenta i servera za autentifikaciju. U ovoj fazi, pristupna taka u sutini
radi kao relej, prosleujui poruke izmeu klijenta i servera za autentifikaciju. Protokol za
proirljivu autentiufikaciju (Extensi-hle Authentiftkacion Protocol, EAP) [RFC 2284]
definie formate poruka od kraja do kraja koje se koriste u jednostavnom reimu interakcije
zahtev/odziv izmeu klijenta i servera za autentifikaciju. Kao stoje prikazano na slici 8.37,
poruke EAP se enkapsuliraju korienjem EAPoL (EAP preko LAN-a, [IEEE 802. IX]) i
alju preko beinog linka 802.11. Te poruke EAP se onda dekapsuliraju u pristupnoj taki^
a zatim ponovo enkapsuliraju korienjem protokola RADIUS za prenos preko UDP/1P do
servera za autentifikaciju. Dok se RADIUS server i protokol [RFC 2138] ne zahtevaju u
protokolu 802.1 li, oni su de facto njegove standardne komponente. Nedavno standard izo
van i protokol DIAMETER [RFC 3588] e u bliskoj budunost verovntnn zameniti
RADIUS.
3. Generisanje uparenog glavnog kljua (Painvise MasterKey, PMK). MKje deljena tajna
koju znaju samo klijent i server za autentifikaciju, a koju svaki od njih koristi da bi
generisao drugi klju, upareni glavni klju (PMK). To smo hteti! Server za autentifikaciju
onda alje PMK u AP. Klijent i AP sada imaju deljeni klju (setite se da u WEP-u, uopte
nije bio reavan problem distribucije kljueva) i meusobno su se autentifikovali. Sada su
oni spremni da preu na posao.
4. Generisanje privremenog kljua (TK). Sa PMK, beini klijent i AP sada mogu da
generiu dodatne kljueve koji e biti upotrebljeni za komunikaciju. Od posebnog znaaja
je privremeni klju (TK), koji e se upotrebiti da se izvede ifrovanje na nivou linka
podataka koji se alju preko beinog linka ka proizvoljnom udaljenom raunaru.
802.Ili obezbeduje vie oblika ifrovanja, ukljuujui emu za ifrovanje zasnovanu na AES-u i
pojaanu verziju WEP ifrovanja.
8. 9 Rezime
U ovom poglavlju, ispitali smo razliite mehanizme koje nai tajni ljubavnici, Bob i Alisa,
mogu da upotrebe kako bi bezbedno" komunicirali. Videli smo da su Bob i Alisa
zainteresovani za tajnost (tako da samo oni mogu da razumeju sadraj prenesene poruke),
autentifikaciju (tako da su sigurni da razgovaraju jedno sa drugim) i integritet poruke (tako da
su sigurni da njihove poruke nisu usput promenjene). Naravno, potreba za bezbednom
komunikacijom nije ograniena samo na tajne ljubavnike. Zaista, videli smo u odeljcima 8.6 do
8.8 daje bezbednost potrebna u razliitim slojevima u mrenoj arhitekturi da bismo se zatitili
od loih momaka" koji imaju na raspolaganju itav arsenal mogunosti za napad.
U prvom delu ovog poglavlja, predstavljeni su razliiti principi na kojima se zasniva
bezbedna komunikacija. U odeljku 8.2 objasnili smo kriptografske tehnike za kodovanje i
dekodovapje podataka, ukljuujui i kriptografiju simetrinim kljuem i kriptografiju javnim
kljuem. DES i RSA su ispitani kao posebne studije primera ove dve glavne klase
kriptografskih tehnika koje se koriste u dananjim mreama. U odeljku 8.3 obratili smo panju
na autentifikaciju i razvili smo niz sve sloenijih protokola za autentifikaciju, koji obezbeuju
daje sagovornik zaista onaj za koga se on/ona izdaje i da ide uivo". Videli smo da i
kriptografija simetrinim kljuem i kriptografija javnim kljuem mogu da igraju vanu ulogu u
skrivanju podataka (ifrovanju/deifrovanju), ali takoe i u obavljanju autentifikacije. Tehnike
za potpisivanje" digitalnog dokumenta na nain koji je proverljiv, nekrivotovorljiv i neopoziv,
objanjene su u odeljku 8.4. Jo jednom, primena kriptografskih tehnika dokazala se kao
sutinska. Ispitali smo i digitalne potpise i izvode iz poruka, od kojih su ovi poslednji skraen
nain za potpisivanje digitalnog dokumenta. U odeljku 8.5

PROBLEMI 723 723 723 723
ispitali smo protokole za raspodelu kljueva. Videli smo da za ifrovanje simetrinim kljuem,
centar za raspodelu kljueva - mreni entitet od poveienja - moe da se koristi za raspodelu
deljenog simetrinog kljua izmeu strana u komunikaciji. Za ifrovanje javnim kljuem,
sertifikaciono telo distribuira uverenja da bi potvrdilo javne kljueve.
Naoruani tehnikama objanjenim u odeljcima od 8,2 do 8.5, Bob i Alisa mogu bezbedno
da komuniciraju. (Moemo se samo nadati da su njih dvoje studenti umreavanja koji su prouili
ovaj materijal i zato mogu da izbegnu da Trudi otkrije njihov sastanak!) Ali, sve vie, tajnost je
samo mali deo slike o mrenoj bezbednosti. Mrena bezbednost je sve vie usmerena na mrenu
infrastrukturu, a protiv mogueg juria loih momaka". Zato smo u poslednjem delu ovog
poglavlja objasnili mrene barijere (kojima se regulie pristup u zatiene mree i izlazak iz njih)
i niz napada koje lica spolja mogu da pokrenu protiv mree, kao i protivmere koje protiv njih
mogu da se prednzmu. Zakljuili smo poglavlje studijama primera u kojima se primenjuju
tehnike iz odeljaka od 8.2 do 8.5 u aplikacionom sloju, transportnom sloju, mrenom sloju i sloju
veze podataka.
Kontrolna pitanja
1. Koje su razlike izmeu tajnosti i integriteta poruke? Da li jedna moe bez druge?
Opravdajte svoj odgovor.
2. Koja je razlika izmeu aktivnog i pasivnog uljeza?
3. Koja je razlika izmeu sistema simetrinog kljua i sistema javnog kljua?
4. Pretpostavite da uljez ima ifrovanu poruku, kao i deifrovanu verziju te poruke, Da li uljez
moe da preduzme napad samo ifrovanim tekstom, napad poznatim otvorenim tekstom ili
napad izabranim otvorenim tekstom?
5. Pretpostavite da N ljudi eli da komunicira sa svakim od N-l drugih ljudi, koristei
ifrovanje simetrinim kljuem. Celokupna komunikacija izmeu dvoje ljudi, i i j, vidljiva
je svim drugim ljudima u toj grupi od N, a nijedna druga osoba u toj grupi ne bi trebalo da
moe da deifruje njihovu komunikaciju. Koliko kljueva se zahteva u sistemu u celini?
Sada pretpostavite da se koristi ifrovanje javnim kljuem. Koliko kljueva se zahteva u
tom sluaju?
6. Koja je namena jednokratne vrednosti u protokolu autentifikacije?
7. ta znai kada se kae daje jednokratna vrednost ona koja se upotrebi jednom u ivom? U
ijem ivom?
8. ta je to napad oveka u sredini? Moe li taj napad da se dogodi kada se koriste simetrini
kljuevi?
9. ta znai za potpisani dokumenc da bude proverljiv, nekrivotvorljiv i neopoziv?

10. Na koji nain izvod iz poruke obezbeduje bolju proveru integriteta poruke od
kontrolnog zbira kao stoje Internet kontrolni zbir?
11. Na koji nain izvod iz poruke ifrovan javnim kljuem obezbeduje holji" digitalni potpis
od korienja poruke ifrovane javnim kljuem?
12. Da lije poruka pridruena izvodu iz poruke ifrovana? Objasnite svoj odgovor.
13. Staje to centar za raspodelu kljueva? Staje to sertifikaciono telo?
14 Sumirajte kljune razlike u uslugama koje pruaju protokol Authentication Header(AH) i
protokol Encapsulation Securitv Pavload (ESP) u IPsecu.
Problemi
1. Koristei jednoazbunu ifru na slici 8.3, ifrujte poruku This is an easy problem".
Deifrujte poruku rmij ' u uamu xyj".
2. Pokaite da Trudin napad poznatim otvorenim tekstom, u kome ona zna parove prevoda
(ifrovani tekst, otvoreni tekst) za sedam slova, smanjuje broj moguih zamena koji treba da
se proveri u primeru 8.2.1 za priblino IO
9
.
3. Razmotrite vieazbuni sistem prikazan na slici 8.4. Da li e napad izabranim otvorenim
tekstom koji je u stanju da dobije ifrovanje otvorenog teksta poruke, The quick brown
fox jumps over the lazy dog" biti dovoljan da deifruje sve poruke? Zato, ili zato ne?
4. Korienjem RSA, izaberitep = 3 i q = 11 i ifrujte re hello". Primenite algoritam za
deifrovanje na ifrovanu verziju da biste rekonstruisali prvobitnu poruku otvorenog teksta.
5. Razmotrite na protokol autentifikacije 4,0, u kome se Alisa autentifikuje Bobu, za koji smo
videli da dobro radi (to jest, u njemu nismo pronali greke). Sada pretpostavite da u isto
vreme kada se Alisa autentifikuje Bobu, Bob i sam mora da se autentifikuje Alisi. Dajte
scenario u kome Trudi, pravei se daje AHsa, sada moe da se autentifikuje Bobu kao Alisa.
(Savet: zamislite da sekvence operacija ap4,0, ona koju zapoinje Trudi i ona koju zapoinje
Bob, mogu da se proizvoljno isprepletu. Posebno obratite panju na injenicu da e i Bob i
Alisa koristiti jednokratnu vrednost i da, ako se ne pazi, moe da se zlo-namerno upotrebi
ista jednokratna vrednost),
6. U napadu oveka u sredini na slici 8.13, Alisa nije autentifikovala Boba. Daje Alisa
zahtevala da se Bob autentifikuje koristei a p 5 . 0, da li bi napad oveka u sredini mogao
da se izbegne? Objasnite svoje razmiljanje.

TEZE ZA DISKUSIJU 725
7. Internet protokol za rutiranje BGP-a koristi MD5 izvod iz poruke a ne ifrovanje javnim kljuem
za potpisivanje BGP poruka. ta mislite zato je izabran MD5 a ne ifrovanje javnim kljuem?
8. Izraunajte treu poruku, razliitu od dve poruke na slici 8.18, koja ima isti kontrolni zbir kao
poruke na slici 8.18.
9. Zato Alisa ne mora eksplicitno da autentifikuje Boba u protokolu i diskusiji slike 8.19?
10. Zato nema eksplicitne autentifikacije u protokolu na slici 8.19? Da li je autentifikacija
potrebna? Zato?
11. Razmotrite KDC i CA servere. Pretpostavite da KDC otkae. Kako to utie na sposobnost
strana da bezbedno komuniciraju; odnosno, ko moe, a ko ne moe da komunicira?
Obrazloite svoj odgovor. Sada pretpostavite da otkae CA. Kakav je uticaj tog otkaza?
12. Razmotrite sledeu varijaciju mrene barijere za filtriranje paketa u odeljku 8.6. Pretpostavite
da Alisa eli da zabrani pristup svojoj mrei 222.22.0.0/16 sa javnog Interneta (pravilo R3 u
prvoj tabeli dalje u tekstu). Alisa opet sarauje sa Bobom i njegovim kolegama, koji su na
univerzitetu, pa Alisa zato eli da dozvoli korisnicima sa Bobovog univerziteta (ija je mrena
adresa 111.11/16) pristup odreenoj podmrei, 222.22.22/24, unutar mree njene kompanije
(pravilo Rl dole). Alisa zna daj e Trudi, dobro poznati haker, na Bobovom univerzitetu i da je
Trudina podmrea, 111.11.11/24, pravi raj za nepouzdane hakere. Zato Alisa eli da nikakav
saobraaj iz 111.11.11/24 ne ude bilo gde u njenu mreu (pravilo R2), izuzev u specijalnu
podmreu 222.22.22/24 (dozvoljeno pravilom Rl ; ovaj izuzetak je znaajna razlika od naeg
primera u odeljku 8.6). Alisina pravila za filtriranje paketa sumirana su u sledeoj tabeli.
V3. Na slici 8.29 prikazane operacije koje Alisa mora da izvede da bi obezbediia tajnost,
autentifikaciju , integritet. Napravite dijagram odgovarajuih operacija tcoje Bob mora da
izvede na pakovanju primljenom od Alise.
Teze za diskusiju _______________________________
1. Pretpostavite da uljez moe i da umetne i da ukloni DNS poruke u mrei. Dajte
tri scenarija koji reavaju probleme koje bi takav uljez mogao da prouzrokuje.
2. Niko nije formalno dokazao da su 3DES ili RSAbezbedni. Imajui to u vidu,
kakav dokaz imamo da su oni zaista bezbedni?
3. Ako IPsec ostvaruje bezbednost u mrenom sloju, zato su onda bezbednosni
mehanizmi i dalje potrebni u slojevima iznad IP-a?
4. Idite na meunarodnu veb lokaciju PGP (http://www.pgpi.org/). Koja verzija
PGP-a vam je legalno dozvoljena za preuzimanje, imajui u vidu zemlju u
kojoj se nalazite?
Popunite sledeu tabelu akcijama koje se preduzimaju u ovom scenariju prema redosledu Rl ,
R2, R3 i prema redosledu R2, Rl , R3.
Koji bi bio rezultat uklanjanja pravila R2 za pakete Pl , P2, P3 i P4?

INTERVJU
726 726 726 726
Stiven M. Belovin Stiven M. Belovin Stiven M. Belovin Stiven M. Belovin
Stiven M. Belovin je AT&T Fellow u NeNvork Seivices Research Lab u
AT&T Labs Research u Froham Parku, New Jersey. Oblasti njegovog
interesovanja su mree, bezbednost i piianje zato su te dve stvari
nekomaptibilne. 1995. godine, dobio je nagradu Usenix Lifetime Achievment
Award za svoj rad na stvaranju Useneta, prve mree za grupnu rozmenu
vesti koja je povezala dva ili vie raunara i dozvolila korisnicima da dele
informacije i uestvuju u diskusijama. Sliv je takoe izabrani lan National
Academy of Engineering. Diplomirao je na Kolumbija univerzitetu, a
doktorirao na Univerzitetu Severne Kroline u Capel Hiilu.
ta Vas je navelo da se specijalizujete u oblasti bezbednosti umre ta Vas je navelo da se specijalizujete u oblasti bezbednosti umre ta Vas je navelo da se specijalizujete u oblasti bezbednosti umre ta Vas je navelo da se specijalizujete u oblasti bezbednosti umreavanja? avanja? avanja? avanja?
Ovo e da zvui udno, ali odgovor je prost: to je bilo zabavno. Moji koreni su bili u
programiranju sistema i sistemskoj administraciji, to dosta prirodno vodi ka bezbednosti. I
uvek sam bio zainteresovan za komunikacije, jo od poslova sistemskog programiranja sa
deliminim radnim vremenom, kada sam bio na koledu.
Moj rad na bezbednosti nastavlja da bude motivisan dvema stvarima - eljom da rau-nari
budu i dalje korisni, Sto znai da njihovu funkciju ne ugroze napadai i eljom da se zatiti
privatnost.

Kakva je Va Kakva je Va Kakva je Va Kakva je Vaa vizija Useneta iz vremena kada ste ga razvijali? A sada? a vizija Useneta iz vremena kada ste ga razvijali? A sada? a vizija Useneta iz vremena kada ste ga razvijali? A sada? a vizija Useneta iz vremena kada ste ga razvijali? A sada?
Prvobitno smo ga videli kao nain da priamo o raunarskoj nauci i programiranju
raunara Sirom zemlje, sa mnogo lokalne upotrebe za administrativne poslove, za oglase o
rasprodajama itd. U stvari, moje prvobitno predvianje bilo je jedna do dve poruke na dan, na
moda 50 do 100 lokacija. Ali, stvarni rast bio je u temama koje su u vezi sa ljudima,
ukljuujui - ali ne ograniavajui se na - ljudske interakcije sa raunarima. Moje omiljene
elektronske grupe, tokom godina, bile su one kao rec.woodworking, kao i sci.crypt.
U izvesnoj meri, Web je istisnuo mrene vesti. Kada bili danas poeo da ih
projektu-jem, to bi izgledalo mnogo drugaije. Ali, one su i dalje nain da se postigne veoma
velik auditorijum koji je zainteresovan za odreenu temu, bez obaveze da se oslanja na
posebne veb lokacije.

Da li Vas je neko profesionalno inspirisao? Na koji na Da li Vas je neko profesionalno inspirisao? Na koji na Da li Vas je neko profesionalno inspirisao? Na koji na Da li Vas je neko profesionalno inspirisao? Na koji nain? in? in? in?
Profesor Fred Bruks - osniva i prvi ef katedre odeljenja za raunarske nauke na
Univerzitetu Seveme Kroline u apel Hilu, rukovodilac tima koji je razvio IBM S/360 i
OS/360 i autor knjige The Mythical Man-Month - imao je ogroman uticaj na moju karijeru. Vie
od bilo ega drugog, on je predavao o gleditima i kompromisima - kako da se
sagledavaju problemi u kontekstu stvarnog sveta (i koliko je stvarni svet liaotiniji od onoga to
bi teoretiar voleo) i kako da se uravnotee suprotni interesi u projektovanju reenja. Najvei
deo rada sa raunarima je inenjersrvo - umetnost pravljenja dobrih kompromisa da bi se
zadovoljili mnogi kontradiktorni ciljevi.

Kakva je Va Kakva je Va Kakva je Va Kakva je Vaa vizija budu a vizija budu a vizija budu a vizija budunosti umre nosti umre nosti umre nosti umreavanja i bezbednosti? avanja i bezbednosti? avanja i bezbednosti? avanja i bezbednosti?
Do sada, najvie bezbednosti koju imamo dolazi od izolacije. Na primer, mrena barijera
radi tako to preseca pristup izvesuim mainama i uslugama. Ali, mi smo u dobu poveanog
povezivanja - pa je sve tee da se stvari odvoje. to je jo gore, nai proizvodni sistemi
zahtevajn daleko vie razdvojene celine, meusobno povezane pomou mrea. Obezbeenje
svega toga jedan je od naih najveih izazova.

Da li biste mogli da nam ka Da li biste mogli da nam ka Da li biste mogli da nam ka Da li biste mogli da nam kaete ne ete ne ete ne ete neto o specijalnim projektima na kojima ba to o specijalnim projektima na kojima ba to o specijalnim projektima na kojima ba to o specijalnim projektima na kojima ba sada radite? sada radite? sada radite? sada radite?
Mnogo vremena posveujem operacionainim pitanjima. Za sistem nije dovoljno da bude
bezbedan; on treba da bude i upotrebljiv. To sa svoje strane znai da mreni operatori moraju
da budu sposobni za nadgledanje stvari. Ali, nadgledanje moe da se sukobi sa bezbednocu -
bezbednost tei da sakrije i zatiti raunare i i i i informacije, ali operatori treba da vide izvesne
stvari. Pored toga, sistemi treba da nastave sa radom, ak i kada najvaniji delovi otkazu. Kako
da deltmo informacije pravim stranama, a da ne pustimo loe momke unutra? To je pitanje
ijim se odgovorom ba sada bavim.

Za Za Za Za ta biste rekli da su najve ta biste rekli da su najve ta biste rekli da su najve ta biste rekli da su najvea dostignu a dostignu a dostignu a dostignua u bez a u bez a u bez a u bezbednosti? Koliko daleko mo bednosti? Koliko daleko mo bednosti? Koliko daleko mo bednosti? Koliko daleko moemo da idemo? emo da idemo? emo da idemo? emo da idemo?
Sa naune take gledita, znamo da radimo kriptografiju. To je bilo od velike pomoi. Ali
najvei problemi bezbednosti proistiu iz programa sa grekama, a to je mnogo tei problem. U
stvari, to je najstariji nereeni problem u raunarskoj nauci i ja mislim da e on to i ostati. Izazov
je da se smisli kako da se obezbede sistemi kada treba da ih izgradimo od nebezbednih sastavnih
delova. To ve moemo da uradimo u pogledu hardverskih otkaza; da li moemo da uradimo isto
i za bezbednost?

Da li imate neki savet o Internetu Da li imate neki savet o Internetu Da li imate neki savet o Internetu Da li imate neki savet o Internetu i bezbednosti umre bezbednosti umre bezbednosti umre bezbednosti umreavanja koji biste uputili studentima? avanja koji biste uputili studentima? avanja koji biste uputili studentima? avanja koji biste uputili studentima?
Uenje mehanizama je laki deo. Uenje kako da se paranoidno razmilja" je tee. Treba
da zapamtite da se raspodele verovatnoe ne primenjuju - napadai mogu da nau, i nai e
neverovatne uslove. A detalji su veoma vani.
727 727 727 727

Umrezavanje Racunara III Izdanje

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Umrezavanje Racunara III Izdanje

Uploaded by

Copyright:

Available Formats

P R E V O D T R E E G

You might also like