P R E V O D I Z D A N J A

T R E E G

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 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 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
c

O autorima
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^u 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.

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 praenju ovog koda.

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.

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.

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.

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.

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.

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,

Uvod

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.

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.

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.

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.

Sadraj
Poglavlje 1 Raunarske mree i Internet
I.l
1.1.1 Osnovne komponente Interneta

1
Staje Internet?

1.3

1.5 1.6

1.9

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 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! Posrednici za Internet usluge i okosnice Interneta 34 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 Rezime 59 Mapa knjige 60 Domai zadatak: problemi i pitanja 61 Problemi 62

XIV

Sadraj

Sadraj

Teze za diskusiju Ethereal laboratorijska vebanja Intervju: Leonard Klajnrok

68 69 71

Poglavlje 3

Transportni sloj
3.1 3.1.1 Odnos izmeu transportnog i mrenog sloja 3.1.2 Kratak pregled transportnog sloja u Internetu

183
Usluge transportnog sloja 184 187

Poglavlje 2 Aplikativni sloj

2.1 Principi rada mrenih aplikacija 2.1.1 Arhitektura mrenih aplikacija 2.1.2 Komunikacija procesa 2.1.3 Protokoli aplikativnog sloja 2.1.4 Koje su usluge potrebne aplikaciji? 2.1.5 Usluge koje obezbeduju Internet transportni protokoli 2.1.6 Mrene aplikacije o kojima emo govoriti u ovoj knjizi 2.2 Web i HTTP 2.2.2 Nepostojane i postojane veze 2.2.3 Format HTTP poruke 2.2.4 Interakcija izmeu korisnika i servera: kolaii 2.2.5 HTTP sadraj 2.2.6 Web keiranje 2.2.7 Uslovno preuzimanje 2.3 Transfer datoteka: protokol FTP 2.4 Elektronska pota na Internetu 2.4.2 Poredenje sa protokolom HTTP 2.4.3 Formati elektronske pote i MIME 2.4.4 Protokoli za prijem elektronske pote 2.5 DNS - Internetova usluga direktorijuma 2.5.1 Usluge koje obezbeduje DNS 2.5.2 Prikaz naina rada usluge DNS 2.5.3 DNS zapisi i poruke 2.6 P2P razmena datoteka 2.7 Programiranje soketa za protokol TCP 2.7.1 Programiranje soketa za protokol TCP 2.7.2 Primer klijentsko-serverske aplikacije u Javi 2.8 Programiranje soketa za protokol UDP 2.9 Pravljenje jednostavnog veb servera 2.9.1 Funkcije veb servera 2.10 Rezime Domai zadatak: problemi i pitanja Problemi Teze za diskusiju Zadaci sa programiranjem soketa Ethereal laboratorijske vebe Intervju: Tim Bemers-Li

73
74 75 78 81 82 84 87 87 90 93 98 100 101 105 106 109 115 115 118 123 123 126 132 136 146 147 149 156 164 164 169 170 171 177 178 180 181

3.2 3.3

Mulripleksiranje i demultipleksiranje 189 Prenos bez uspostavljanja konekcije: UDP 196 3.3.1 Struktura UDP segmenta 199: 3.3.2 UDP kontrolni zbir 200 Principi pouzdanog transfera podataka 3.4 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 Transport sa konekcijom: TCP 3.5 3.5.1 TCP konekcija 228 231 3.5.2 Struktura TCP segmenta 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: 261 Kontrola zaguenja ATM ABR 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
4.1

Mreni sloj

299

Uvod 300 4.1.1 Prosleivanje i rutiranje 301 304 4.1.2 Modeli mrene usluge 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

313 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 371 sistema na Internetu: R1P 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 Domai zadatak: problemi i pitanja 401 Problemi 404 Teze za diskusiju 412 Programerski zadatak 412 Laboratorija Ethereal 413 Intervju: Vinion G. Cerf 414 4.3

4.1.3 Poreklo usluga datagrama i virtualnog kola

5.3.4 Protokoli tipa na koga je red" 5.3.5 Lokalne raunarske mree (LAN-ovi)

442 443

5.4
5.4.1 MAC adrese 5.4.2 Protokol razreavanja adresa (ARP)447 . 5.4.3

Adresiranje sloja linka

445

Protokol 5.5

za

dinamiko
451

konfigurisanje glavnog raunara

5.5.1 Struktura Ethemetovog okvira 5.5.2 CSMA/CD: Ethemetov protokol sa viestrukim pristupom 5.5.3 Ethernet tehnologije

Ethernet
455

460
453

5.6
5.6.1 Habovi 5.6.2 Komutatori sloja linka

Meusobne veze: liabovi i komutatori

455 457

5.7
5.7.1 PPP uokvirivanje podataka

PPP: protokol od take to take

479

5.8

5.9

480 Vizuelizacija Jinka: mrea kao sloj veze482 5.8-1 Asinhroni reim prenosa (ATM) 483 5.8.2 Vieprotokolna komutacija na osnovu oznaka (MPLS) 488 Rezime49J Domai zadatak: problemi i pitanja 493 Problemi 494 Teze za diskusiju 498 Ethereal Lab
499 500

5.7.2 PPP protokol kontrole linka (LCP) i protokoli kontrole mree

Intervju: Simon S. Lam

Poglavlje 6
6.1 6.2
6.3

Beine i mobilne mree

Uvod Beini linkovj i mrene karakteristike508
6.2.1

503
504

CDMA
509 513

Poglavlje 5
5.1

Sloj veze podataka i lokalne mree raunara

417

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 Protokoli viestrukog pristupa 5.3 5.3.1 Protokoli sa deljenjem kanala 433 5.3.2 Protokoli sa sluajnim pristupom 435

Wi-Fi: Beini LAN-ovi tipa 802.11 6.3.1 Arhitektura 802.11 6.3.2 MAC protokol 802. II 6.3.4 Mobilnost unutar iste IP podmree 6.3.5 802.15 i Bluetooth 6.4 Celularni pristup Internetu 6.4.1 Opti pregled celularne arhitekture 6.4.2 Celularni standardi i tehnologije: kratak pregled 6.5 Upravljanje mobilnou: principi536 6.5.) 533 6.5.2 Rutiranje prema mobilnom voru 6.6 Mobilni IP

514
517

526
528

529 531 532 Adresiranje 540

546

xviii

Sadraj

Sadraj

10

6.7 Upravljanje mobilnocu u celularnim mreama 6.7.1 Rutiranje poziva prema mobilnom korisniku 552 553 6.7.2 Predavanje u GSM-u 6.8 Beine mree i mobilnost: posledice po protokole viih nivoa 556 6.9 Rezime559 Domai zadatak: problemi i pitanja 559 Problemi 560 Teze za diskusiju 562 Laboratorija Ethereal 562 Intervju: arli Perkins 563

Poglavlje 7
7.1

Multimedijsko umreavanje
Multimedijske aplikacije umreavanja 7.1.1 Primeri multimedijskih aplikacija 7.1.2 Prepreke za multimedije na dananjem Internetu 7.1.3 Kako bi Internet trebalo da se razvija da bi bolje

565
566 566 569

7.2

7.5 7.6

podrao multimedije? 7.1.4 Kompresija zvuka i videa 572 Protok memorisanog zvunog signala i video signala u realnom vremenu 574 576 7.2.1 Pristupanje zvuku i videu kroz veb server 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 590 7.3.3 Oporavljanje od gubitaka paketa 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 Distribuiranje multimediju ma: mree za distribuciju sadraja 610 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 625 7.7.2 Upravljanje: uplja kofa 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 643 7.10 Rezime Domai zadatak: problemi i pitanja 64^4 Problemi 645 Teze za diskusiju 649 Programerski zadatak 649 Intervju: Hening ulcrine 651

Poglavlje 8
8.1 8.2

Bezbednost u raunarskim mreama

ta je bezbednost mree Principi kriptografije 8.2.1 Kriptografija simetrinog kljua 8.2.2 ifrovanje javnim kljuem 8.3 8.3.1 Autentifikacioni protokol apl.O 8.3.2 Autentifikacioni protokol ap2.0 8.3.3 Autentifikacioni protokol ap3.0 8.3.4 Autentifikacioni protokol ap3.1 8.3.5 Autentifikacioni protokol ap4.0 8.3.6 Autentifikacioni protokol ap5.0 Integritet 678 8.4.1 Stvaranje digitalnih potpisa 8.4.2 Izvodi poruka 8.4.3 Algoritmi he funkcija

653
654 657 658 664 Autentifikacija 670 671 672 672 673 674 678 679 681

"

8.4

11

Sadraj

Distribucija i overavanje kljueva 686 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 Domai zadatak: problemi i pitanja 722 Problemi 723 Teze za diskusiju 725 Intervju: Stiven M. Belovin 651 8.5.1 Centar za distribuciju kljueva 8.5.2 Overa javnog kljua

8.5

Umreavanje raunara
Od vrha ka dnu sa Internetom u fokusu
Prevod treeg izdanja

Poglavlje 9
9.1 9.2 9.3

Upravljanje mreom
Sta je upravljanje mreom? Infrastruktura za upravljanje mreom Standardni upravljaki radni okvir za Internet 9.3.1 Komponenta SMI 9.3.2 Upravljaka informaciona baza: MIB 9.3.3 Funkcionisanje protokola SNMP i transportna preslikavanja 9.3.4 Bezbednost i administracija ASN.l Zakljuak757 Domai zadatak: problemi 758 759 Teze za

729
730 734 738 740 743 745 749 753 i pitanja Problemi diskusiju 760 Intervju: Jeff Case 763 797

9.4 9.5

Reference Indeks

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

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.1

STAJE INTERNET?

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 S t a j 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?

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-

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.1

TA JE INTERNET?

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? 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

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

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

POGLAVLJE 1

RAUNARSKE MREE l INTERNET

1.2

PERIFERIJA MREE

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.

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.

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:

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

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.

10

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.2

PERIFERIJA MREE

17

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.

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.

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: usluge sa konekcijom i usluge bez konekcije. Programer koji

18

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.2

PERIFERIJA MREE

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^e 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 prekoraenja 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.

14

POGLAVLJE 1

RAUNARSKE MREE 1 INTERNET

1.3

JEZGRO MREE

19

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.

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.

1.3.1 Komutiranje vodova i komutiranje paketa

U formiranju mrenog jezgra postoje dva osnovna pristupa i to su komutiranje vodova i komutiranje paketa.

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

POGLAVLJE 1

RAUNARSKE MREE 1 INTERNET

1.3

JEZGRO MREE

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 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 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

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.3

JEZGRO MREE

19

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 memorija 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

22

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

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

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.3

JEZGRO MREE

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

POGLAVLJE 1

RAUNARSKE MREE l INTERNET

1.4

PRISTUP MREI I FIZIKI MEDIJUMI

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.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.

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.

25

POGLAVLJE 1

RAUNARSKE MREE l INTERNET

1.4

PRISTUP MREI I FIZIKI MEDUUMI

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

26

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.4

PRISTUP MREI I FIZIKI MED1JUMI

29

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. 1 1 (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.

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.

Ovo vai za 802.11b dok 802.1 Ig ima 54 MB/s! {prim. rec.)

30

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.4

PRISTUP MREI l FIZIKI MEDIJUMI

27

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

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.

28

POGLAVLJE )

RAUNAR5KE MREE I INTERNET

1.4

PRISTUP MREI I r\ZiCKi MEDIJUM)

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

Ovo u praksi nikada nije sluaj, (prim. rec.)

34

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.5

POSREDNICI ZA INTERNET USLUGE I OKOSNICE INTERNETA

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

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.6

KANJENJE l GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA

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.

38

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.6

KANJENJE I GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA

31

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 IO8 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

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

"

Propagacijn zavisi iskljuivo od elektrinih ili elekiromagnelnili osobina medijuma (prim. rec.)

40

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.6

KANJENJE I GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA

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 = ^obrada + ^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 ^obrada 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 (<^obrada. 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, 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

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.6

KANJENJE I GUBITAK PAKETA U MREAMA SA KOMUTIRANJEM PAKETA

43

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 ~ ^ ^obrado + ^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. 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.

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

44

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.7

SLOJEVI PROTOKOLA I NJIHOVI MODELI USLUGA

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 0.931 ms 0.441 ms 0.651 ms (128.119.2.194) i.032 ms 0.484 ms 0.4S1 ms 10.006 ms 8.150 ms 8.460 ms 12.272 ms 14.344 ms 13.267 ms 13.225 ms 12.292 ms 12.148 ms 12.218 ms 11.823 ms 11.793 ms

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

2 128.119.3.151

(128.119.3.154)

3 border4~rt-gi-l-3.gw.umass.edu 4 acrl-ge-2-l-0.Boston.cw.net 5 agr4-loopback,NewYork.cw.net 6 acr2-loopback.NewYork.cw.net

(208.172.51.129) (206.24.194.104) (206.24.194.62)

1 poslO-2.core2.NewYockl.Level3.net

(209.244.160.133)

8 gige9-l-52.hsipaccessl.NewYorkl.Level3.net 9 pO-0.polyu.bbnplanet.net 10 cis.poly.edu (4.25.109.122)

(64.159.17.39)

13.081 ms 11.556 ms 13.297 ms

12,116 ms 13.052 ms 12.786 ms

(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

35

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.7

SLOJEVI PROTOKOLA I NJIHOVI MODELI USLUGA

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).

48

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.7

SLOJEVI PROTOKOLA I NJIHOVI MODELI USLUGA

36

Aplikacijski sloj

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.

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.

50

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.7

SLOJEVI PROTOKOLA I NJIHOVI MODELI U5LUGA

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

POGLAVLJE

RAUNARSKE MREE I INTERNET

1.8

ISTORIJSKI PREGLED UMREAVANJA I INTERNETA

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

POGLAVLJE 1

RAUNARSKE MREE i INTERNET

1.8

ISTORIJ5KI PREGLED UMREAVANJA I INTERNETA

39

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.

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-

56

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

1.8

ISTORIJSKI PREGLED UMREAVANJA I INTERNETA

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.

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.

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

41

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

REZIME

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.

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.

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.

60

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

DOMAI ZADATAK: PROBLEMI 1 PITANJA

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. 2. 3. 4. 5. 6. 7. 8. 9. Raunarske mree i Internet Aplikacijski sloj Transportni sloj Mreni sloj Sloj veze podataka i lokalne raunarske mree Beino i mobilno umreavanje Multimedijalno umreavanje Bezbednost u raunarskim mreama Upravljanje mreama

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? Re protokol esto se u medijima povezuje sa'diplomatijom. Navedite jedan primer diplomatskog protokola. Staje klijentski program? Staje serverski program? Da li serverski program zahteva i dobija usluge od klijentskog programa? Navedite dva tipa usluga koje Internet prua svojim aplikacijama. Navedite neke njihove karakteristike. 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? Ukratko ispriajte na koji nain Internet usluga sa konekcijom obezbeduje pouzdan transport. 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? Zbog ega se kae da komutiranje paketa primenjuje statistiko multipleksira-nje? Uporedite statistiko multipleksiranje sa multipleksiranjem koje se odvija u okviru TDM tehnologije. 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.)

2. 3. 4. 5.

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.

6. 7.

8.

9.

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

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

PROBLEMI

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

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. Podseamo 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?

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.

64

POGLAVLJE 1

RAUNARSKE MREE l INTERNET

PROBLEMI

44

6. Ovim elementarnim problemom zapoinjemo istraivanje kanjenja usled propagacije 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 108, 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 korisnici aktivni, oni stvaraju saobraaj od 100 kb/s, ali verovatnoa njihove aktivnosti 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 izvornog 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 108 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

POGLAVLJE 1

RAUNARSKE MREE ! INTERNET

PROBLEMI

67

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. Pretpostaviemo da brzina propagacije iznosi 2,4 108 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 IO6 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?

46

POGLAVLJE 1

RAUNARSKE MREE I INTERNET

ETHEREAL LABORATORIJSKA VEBANJA

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.

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

Teze za diskusiju
1. 2. 3. 4. Koje vrste beinih mobilnih usluga postoje u vaem kraju? 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. Staje od PC-ja do telefona"? Pronaite veb lokacije koje se bave ovim poslom. 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? 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. ta su Internet video konferencije? Opiite neke od postojeih proizvoda za Internet video konferencije, Pronaite veb lokacije kompanija koje se time bave. Navedite pet kompanija koje obezbeuju uslugu P2P razmene datoteka i za svaku od njih navedite vrstu datoteka iju razmenu podravaju. Staje trenutna razmena poruka? Postoje li PDA ili slini ureaji koji bi mogli da vam omogue pristup uslugama za trenutnu razmenu poruka? 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? 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.

5.

6. 7. 8. 9.

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.

INTERVJU

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 ega ste se opredelili za specijalizaciju u oblasti tehnologije umreavanja 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 pokrenem 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 prvi posao u raunarskoj 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 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 emu ste razmiljali prilikom slanja prve poruke poruke od raunara do raunara (iz Univerziteta UCLA ka Istraivakom 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

47

71

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 komponentama. 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.

72

7k

74

POGLAVLJE 2

APLIKATIVNI SLOJ

2.1

PRINCIPI RADA MRENIH APLIKACIJA

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 arhitekture 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.1

PRINCIPI RADA MRENIH APLIKACIJA

50

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].

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

78

POGLAVLJE 2

APLIKATIVNI SLOJ

2.1

PRINCIPI RADA MRENIH APLIKACIJA

51

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.

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.

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.

52

POGLAVLJE 2

APLIKATIVNI SLOJ

2.1

PRINCIPI RADA MRENIH APLIKACIJA

81

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 aplikacijskog 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.1

PRINCIPI RADA MRENIH APLIKACIJA

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.

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 realistinost 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.

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.

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.

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.

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

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-

88

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

WEB I HTTP

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,

90

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

WEB I HTTP

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.

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-

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.)

92

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

WEB I HTTP

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 H E A D 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

WEB l HTTP

60

HTTP poruka sa odgovorom U nastavku moete da vidite kako izgleda uobiajena HTTP poruka sa odgovorom. odgovorom. Ova poruka koju smo naveli mogla bi da predstavlja odgovor na poruku sa zahtevom o kojoj smo prethodno prethodno govorili.

Pogledajmo malo paljivije ovu poruku. Ona ima tri dela: inicijalni statusni red, est redova zaglavlja i telo poruke. Telo poruke predstavlja najvaniji deo poruke - ovde se nalazi traeni objekat objekat (podaci podaci podaci podaci podaci . . .). Statusni red ima tri polja - polje sa verzijom protokola, statusni kod i odgovarajuu poruku sa statusom. U ovom primeru statusnim redom navedeno je da server koristi protokol HTTP/ 1 .1 i daje sve u redu (OK), odnosno, daje server pronaao i poslao traeni objekat. Preimo sada na redove zaglavlja. Server pomou reda Connection : close , govori klijentu da e nakon slanja traenog objekta prekinuti TCP konekciju. Redom Date : navode se datum i vreme kada je server generisao i poslao HTTP odgovor. Skreemo vam panju na to da to nije vreme kada je traeni objekal odgovorom napravljen ili poslednji put promenjen, ve vreme kada gaje server uitao iz svog sistema datoteka, stavio u poruku sa odgov orom i poslao klijentu. Redom Server : naznaeno je daje poruku generisao veb server Apache; ovaj red odgovara redu UserUser-agent: HTTP poruke sa zahtevom. U redu LastLast-Modif ied: navodi se kada je Zaglavlje Lasttraeni objekat napravljen ili poslednji put izrnenjen. Zaglav lje Last -Modif ied :, kome emo uskoro posvetiti neto vie panje, izuzetno je vano za keiranje objekta kako na lokalnom klijentu, tako i na mrenim serverima za keiranje (oni se nazivaju i proksi serveri). U zaglavlju ContentContent-Length: navodi se broj bajtova objekta koji se alje. Konano, redom zaglavlja ContentContent-Type: naznaava se tip datoteke koja se nalazi u telu poruke (u ovom sluaju to je HTML tekst). (Tip objekta se zvanino naznaava zaglavljem ContentContent-Type:, a ne oznakom tipa datoteke.) Poto smo zajedno analizirali ovaj primer, pogledajmo kako izgleda opsti format format poruke sa odgovorom (slika 2.9). Kao to vidite, opti format ove poruke se u potpunosti poklapa sa naim primerom. Recimo poneto i o statusnim kodovima i njihovim opisima. Statusnim Statusnim kodom i odgovarajuim opisom navodi se rezultat zahteva. Evo nekih uobiajenih statusnih kodova i odgovarajuih opisa.

200 OK : Komanda je uspeno izvrena i zahtevana informacija se vraa u odgovoru. 301 Moved Permanently: Traeni objekat je trajno uklonjen; novi URL se navodi u zaglavlju Location: poruke sa odgovorom. Klijentski softver tako
automatski dolazi do novog URLURL-a.

400 Bad Request: Uopteni kod sa grekom kojim se naznaava da server nije nije razumeo primljeni zahtev. 404 Not Found: Traeni dokument ne postoji na serveru. 505 HTTP Version Not Supported: Server ne podrava traenu verziju verziju protokola HTTP.
Da li biste eleli da sada vidite pravu HTTP poruku sa odgovorom? Osim stoje veoma preporuljivo, to je i krajnje jednostavno. Dakle, uspostavite Telnet sesiju sa svojim omiljenim veb serverom. Zatim upiite poruku sa zahtevom duine jednog reda kojom ete traiti neki objekat koji se nalazi na serveru. Primera radi, u komandnoj koman dnoj liniji moete da upiete: telnet cis.poly.edu 80 GET //-ross/ HTTP/1.1 Host: c i s .poly.edu (Nakon upisivanja poslednjeg reda dvaput pritisnite taster taster Enter.) Ovim se uspostavlja TCP konekcija sa portom 80 raunara www. eurecom. f r i alje HTTP poruka sa zahtevom. U poruci sa odgovorom trebalo bi da ugledate osnovnu HTML

98

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

WEB I HTTP

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.

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

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

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

100

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

VVEBIHTTP

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.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.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.

63

POGLAVLJE 2

APLIKATIVNI SLOJ

2.2

WE8 I HTTP

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

POGLAVLJE 64

APLIKATIVNI SLOJ

2.2

V/EBIHTTP

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:

106

POGLAVLJE 2

APLIKATIVNI SLOJ

2.65

TRANSFER DATOTEKA; PROTOKOL FTP

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

66

POGLAVLJE 2

APLIKATIVNI SLOJ

2.4

ELEKTRONSKA POTA NA INTERNETU

109

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

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 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.4

ELEKTRONSKA POTA NA INTERNETU

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 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 povremeno 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.

68

POGLAVLJE 2

APLIKATIVNI SLOJ

2.4

ELEKTRONSKA POTA NA INTERNETU

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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.4

ELEKTRONSKA POTA NA INTERNETU

69

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 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. 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

razlikuju 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.4

ELEKTRONSKA POTA NA INTERNETU

70

Uobiajeno zaglavlje poruke izgleda ovako:

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:

71

POGLAVLJE 2

APLIKATIVNI SLOJ

2.4

ELEKTRONSKA POTA NA INTERNETU

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 Received: hamburger.edu; 3 Jul 01 15:17:39 GMT from crepes.fr by

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

72

POGLAVLJE 2

APLIKATIVNI SLOJ

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 PO P3 server ready user bob +OK pass hungry

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.

+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

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

122

POGLAVLJE 2

APLIKATIVNI SLOJ

2.5

DNS -INTERNETOVA USLUGA DIREKTORIJUMA

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 direktorijuma 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.5

DNS-INTERNETOVA USLUGA DIREKTORIJUMA

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: KRITINE MRENE FUNKCIJE PUTEM KLUENTSKOKLUENTSKO-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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.5

DNS - INTERNETOVA USLUGA DIREKTORIJUMA

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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.5

DNS - INTERNETOVA USLUGA DIREKTORIJUMA

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 implementiraju 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

130

POGLAVLJE 2

APLIKATIVNI SLOJ

2.5

DNS - INTERNETOVA USLUGA DIREKTORIJUMA

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),

78

POGLAVLJE 2

APLIKATIVNI SLOJ

2.5

DNS - INTERNETOVA USLUGA DIREKTORIJUMA

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

POGLAVLJE 2 .

APLIKATIVNI SLOJ

2.5

DNS - INTERNETOVA USLUGA DIREKTORIJUMA

135

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, {dnsl.networkutopia.com, 212.212.212.1, A) NS)

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.

i-

136

POGLAVLJE 2

APLIKATIVNI SLOJ

2.80

P2P RAZMENA DATOTEKA

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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.6

P2P RAZMENA DATOTEKA

81

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

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-

82

POGLAVLJE 2

APLIKATIVNI SLOJ

2.6

P2P RAZMENA DATOTEKA

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

2. 3.

4.

5.

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. 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. 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. 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. 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).

83

POGLAVLJE 2

APLIKATIVNI SLOJ

2.6

P2P RAZMENA DATOTEKA

143

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:

i-

84

POGLAVLJE 2

APLIKATIVNI SLOJ

2.

P2P RAZMENA DATOTEKA

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 poklapanje 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,

SiiilSKaZaA

KRATAK OSVRT

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 [Recording Induslr/ Association of America, 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.

146

POGLAVLJE 2

APLIKATIVNI SLOJ

2,7

PROGRAMIRANJE SOKETA ZA PROTOKOL TCP

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.)

148

POGLAVLJE 2

APLIKATIVNI SLOJ

2.7 .

PROGRAMIRANJE SOKETA ZA PROTOKOL TCP

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.

150

POGLAVLJE 2

APLIKATIVNI SLOJ

2.87

PROGRAMIRANJE SOKETA ZA PROTOKOL TCP

151

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", 6789); 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. * ;

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.

152

POGLAVLJE 2

APLIKATIVNI SLOJ

2.7

PROGRAMIRANJE SOKETA ZA PROTOKOL TCP

153

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 }

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 istoimenoj 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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.7

PROGRAMIRANJE SOKETA ZA PROTOKOL TCP

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

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 = new BufferedReader(new InputStreamReader( connectionSocket.getlnputStream()) ) ; DataOutputStream outToClient = new DataOutputStream( connectionSocket.getOutputStream()); clientSentence ~ inFromClient.readLine(}; capitalizedSentence = 1 clientSentence . toUpperCase () + \n' ;. outToClient.writeBytes(capitalizedSentence);
I
}

\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).

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

, POGLAVLJE 2

APLIKATIVNI SLOJ

2.8

PROGRAMIRANJE SOKETA ZA PROTOKOL UDP

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.

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 zajednikog 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. 2. 3. 4. 5. Klijent ita red teksta iz standardnog ulaza. Server ita red teksta iz svog soketa. Server prebacuje ovaj tekst u sva velika slova. Server, kroz svoj soket, alje izmenjeni tekst klijentu. Klijent ita izmenjeni tekst kroz svoj soket i prikazuje ga na standardnom izlazu (monitoru).

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.

158

POGLAVLJE 2

APLIKATIVNI SLOJ

2.8

PROGRAMIRANJE SOKETA ZA PROTOKOL UDP

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

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 ();

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

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,

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

160

POGLAVLJE 2

APLIKATIVNI SLOJ

2,8

PROGRAMIRANJE SOKETA ZA PROTOKOL UDP

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") ;

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.

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

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, IPAddress, 9876); sendData.length,

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

POGLAVLJE 2

APLIKATIVNI SLOJ

2.8

PROGRAMIRANJE SOKETA ZA PROTOKOL UDP

163

String modifiedSentence = new String(receivePacket.getData{ ) ) ; Ovaj red programa izvla i podatke iz objekta receivePacket i izvrava konverziju tipa, pretvaraju i niz bajtova u string modif iedSentence.
}

sendData = capitalizedSentence.getBytes( ) ; DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, p o r t ) ; serverSocket.send(sendPacket);

} }

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. Budu i da kod UDP veza nema konekcije, klijent serveru nakon ovog reda ne alje poruku transportnog sloja (nasuprot programu 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( ) ;

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 slu aju 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-

164

POGLAVLJE 2

APLIKATIVNI SLOJ

2.9

PRAVLJENJE JEDNOSTAVNOG VEB SERVERA

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.

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 pretpostaviemo i to da se datoteka koju klijent trai zaista nalazi u serverovom sistemu datoteka.

i i
]
j

Vv'ebServer.java Evo kako izgleda kod jednostavnog veb servera.

j j

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.

import java.io,*; import java.net.*; 1 import java.util.*; 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 new BufferedReader(new InputStreamReader( 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"))

166

POGLAVLJE 2

APLIKATIVNI SLOJ

2,9

PRAVLJENJE JEDNOSTAVNOG VEB SERVERA

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"); }
}

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 razlikuje 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);

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,

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

.-1-,

96

POGLAVLJE 2

APLIKATIVNI SLOJ

2.10

REZIME

169

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 F O II OVJS , 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);

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.

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

170

POGLAVLJE 2

APLIKATIVNI SLOJ

PROBLEMI

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.

172

POGLAVLJE 2

APLIKATIVNI SLOJ

PROBLEMI

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 ustanovite 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 : 1 498 . S : 2 912
S: .

C: retr L S : bla bla . . . S : ........................ bla S: . ?

174

POGLAVLJE 2

APLIKATIVNI SLOJ

PROBLEMI

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: .

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 ^iznenada 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.

C: retr 1 S : bla bla . . . S: ...................... bla

S: . ?

c) Pretpostavimo da ste svog POP klijenta za elektronsku potu konfigurisali 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. Pretpostaviemo da u tih pet minuta niste dobili nijednu novu poruku. Ispiite transkript 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. Rezimirajte 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 nslookup 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 raunara. Ukoliko pretpostavimo daje va raunar dovoljno jak da ga istovremeno preuzimanje i slanje podataka ne optereuju (procesor, disk, itd), da li e istovremeno slanje podataka koji takoe moraju da prou kroz usko grlovae veze sa Internetom usporiti vae preuzimanje? Obrazloite svoj odgovor, Sta bi se

A-.

176

POGLAVUE 2

APLIKATIVNI SLOJ

TEZE ZA DISKUSIJU

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? 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)? 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. Lokacije za elektronsku trgovinu, ali i druge veb lokacije esto imaju pozadinske baze podataka. Na koji nain HTTP serveri komuniciraju sa ovim bazama podataka? Staje dinamiki HTML? Navedite primere veb lokacija koje koriste dinamiki HTML. Navedite neke popularne serverske skript jezike. Staje svrha serverskihskript jezika? Na koji nain biste svoj ita konfigurisali za lokalno keiranje? Koje opcije vam u tom smislu stoje na raspolaganju? 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. 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?

2.

3.

4. 5. 6. 7. 8.

9.

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?

78

POGLAVLJE 2

APLIKATIVNI SLOJ

ZADACI SA PROGRAMIRANJEM SOKETA

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?

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

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 odgovarajuom 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.

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.

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.

180

POGLAVLJE 2

APLIKATIVNI SLOJ

I NT ER VJ U

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 BernersBerners-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 ^ojo 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. 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 istraivanjem uinile su mi se najzanimljivije. Mikroprocesor se upravo pojavio i oblast telekomunikacija je veoma brzo poela da prelazi sa oienih sistema na sisteme zasnovane na procesorima. Bilo je to veoma zanimljivo.

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.

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 komunikacija ljudi kroz zajednika znanja mora biti mogua u svim razmerama i onoliko jednostavna koliko je danas lina komunikacija,
102

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 intuiciju... 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 simbiozu 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

183

i-

184

POGLAVLJE 3

TRANSPORTNI SLOJ

3.1

USLUGE TRANSPORTNOG SLOJA

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

105

POGLAVLJE 3

TRANSPORTNI SLOJ

3.1

USLUGE TRANSPORTNOG SLOJA

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.2

MULTIPLEKSIRANJE I DEMULTIPLEKSIRANJE .

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.2

MULTIPLEKSIRANJE 1 DEMULTIPLEKSIRANJE

191

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: 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 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

192

POGLAVLJE 3

TRANSPORTNI SLOJ

3.2

MULTIPLEKSIRANJE I DEMULTIPLEKSIRANJE

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:

194

POGLAVLJE 3

TRANSPORTNI SLOJ

3.2

MULTIPLEKSIRANJE

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 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.

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-

198

POGLAVLJE 3

TRANSPORTNI SLOJ

3.3

PRENOS BEZ USPOSTAVLJANJA KONEKCIJE: UDP

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

Slika 3.7 Struktura UDP segmente

200

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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.

202

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

113

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 protokola 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 d t 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.
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 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.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

114

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

205|

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 slanju, 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.

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"!

1206

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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

208

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

116

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

117

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

-i-

118

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

213

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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 (IO9 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.

216

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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 GB N
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,

il8

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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 2k. (To jest, prostor rednih brojeva moe se posma-trati kao prsten veliine 2k, gde za rednim brojem 2k-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

122

POGLAVLJE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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+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

. 1. Podaci'primljeni odozgo. Kada se odozgo prime; podaci, SR.poiljalaQprbveravasledcislobodni redni broj a paket; Akoje^ poiij'aoca,:pbdacj'se.palcuju:i alju; inae se privremeno1 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'korititi 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 Dogaaji i aktivnosti SR poiljaoca

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

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

POGLAVUE 3

TRANSPORTNI SLOJ

3.4

PRINCIPI POUZDANOG TRANSFERA PODATAKA

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

229

3 .5

Transport sa konekcijom: TCP

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

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:

KRATAK OSVRT
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.

230

POGLAVLJE 3

TRANSPORTNI SLOJ

3.127

TRANSPORT SA KONEKCIJOM: TCP

127

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: 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 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.

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.

232

POGLAVLJE 3

TRANSPORTNI SLOJ

3.128

. TRANSPORT SA KONEKCIJOM: TCP

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 raunara 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

POGLAVUE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

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.

236

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

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 nepotvrenom 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

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.

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:

238

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

239

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:

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

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

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-

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.

240

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

241

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

(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

break;

} /* kraj beskonane petlje */ Slika 3.33

Pojednostavljen TCP poiljalac

1242

POGLAVLJE 3

TRANSPORTNI SLOJ

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.

244

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

245

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 _ received for y if for y==3) /* } break; { */ (number of duplicate ACKS received _ { /* dupli ACK za ve potvreni segment *7 increment number of duplicate ACKs {

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

TCP brzo ponovno slanje

resend segment with sequence number y

2/46

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

247

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

24?

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

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.

250

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

251

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.

252

POGLAVLJE 3

TRANSPORTNI SLOJ

3.5

TRANSPORT SA KONEKCIJOM: TCP

253

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

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.

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 XUVM 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.

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.

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.

i
( 141

POGLAVLJE 3

TRANSPORTNI

3.6

PRINCIPI KONTROLE ZAGUENJA

259

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 XLI[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 XUIN poveanje vrednosti XUIAZ dovodi do poveanja vrednosti XIZ]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 XA]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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.6

PRINCIPI KONTROLE ZAGUENJA

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. Videemo 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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.6

PRINCIPI KONTROLE ZAGUENJA

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.7

TCP KONTROLA ZAGUENJA

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],

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.

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:

266

POGLAVLJE 3

TRANSPORTNI SLOJ

3.7

. TCP KONTROLA ZAGUENJA

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 poveava 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.

146

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. 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 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 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].

147

POGLAVLJE 3

TRANSPORTNI SLOJ

3.7

. TCP KONTROLA ZAGUENJA

147

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):

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:

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.7

TCP KONTROLA ZAGUENJA

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

J149

POGLAVUE 3

TRANSPORTNI SLOJ

3.7

TCP KONTROLA ZAGUENJA

149

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].

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.

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 1 1 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.

150

POGLAVLJE 3

TRANSPORTNI SLOJ

3.7

TCP KONTROLA ZAGUENJA

277

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

POGLAVLJE 3

TRANSPORTNI SLOJ

3.7

. TCP KONTROLA ZAGUENJA

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 2k-' 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:

152

POGLAVLJE 3

TRANSPORTNI SLOJ

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)2k~'. 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

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

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).

K = 8. U sledeoj tabeli ispitujemo efekat koji mehanizam sporog poetka ima na vreme ekanja za
razliite brzine prenosa.

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

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. 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,

Domai zadatak: problemi i pitanja Poglavlje 3 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

POGLAVLJE 3

TRANSPORTNI SLOJ

PROBLEMI

155

ODEUAK 3.5

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.

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.

156

POGLAVLJE 3

TRANSPORTNI SLOJ

PROBLEMI

289|

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. 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 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.

290

POGLAVLJE 3

TRANSPORTNI SLOJ

PROBLEMI

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 SampleRTT1 bude najnoviji uzorak RTT-a, SampleRTT2 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):

158

POGLAVLJE 3

TRANSPORTNI SLOJ

PROBLEMI

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 -MSS

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.

294

POGLAVLJE 3

TRANSPORTNI SLOJ

3.1 *

LABORATORIJA ETHEREAL: ISTRAITE TCP

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

JUProgramerski 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 tajmera, a tajmerski prekidi aktivirae vau rutinu za njegovu obradu.

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.

Teze za diskusiju
1. Razmotrite protok memorisanog audio sadraja u realnom vremenu. Da li je logino da

Laboratorija Ethereal: Istraite TCP

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

se aplikacija izvrava preko UDP-a ili TCP-a? Koji transportni protokol koristi RealNetworks? Zato?

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 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.

297

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?

Mreni sloj

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 istraivanje, 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.

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

162

POGLAVLJE 4

MRENI SLOJ

4.1

. UVOD

301!

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, BGPPoglavlje 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 prijemnog raunara. U tom poslu mogu se uoiti dve znaajne funkcije mrenog sloja:

|
i j j

163

POGLAVLJE 4 MRENI SLOJ 4.1

UVOD

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 izlaznog 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

i-

164

POGLAVLJE 4 . MRENI SLOJ

4.1 UVOD

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.

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-

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:

306

POGLAVLJE 4

MRENI SLOJ

4.2 . MREE SA VIRTUALNIM KOLIMA I SA DATAGRAMIMA

307

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.

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 . 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.

i-

308

POGLAVLJE 4 . MRENI-SLOJ

4.2 . MREE SA VIRTUALNIM KOLIMA I SA DATAGRAMIMA

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:

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.

'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-

J310

POGLAVLJE 4 .

MRENI SLOJ

4.2

MREE SA VIRTUALNIM KOLIMA I SA DATAGRAMIMA

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 Raspon odredinih adresa 11001000 000101I I 00010000 00000000 do iiooiooooooioin oooioin miini 11001000 00010111 00011000 00000000 do 11001000 00010111 00011000 11111111 i i o o i o o o o o o i o i n oooiiooi o o o o o o o o do i i o o i o o o o o o i o i n 00011111 m i n u inae 3 2 o Interfejs linka 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:

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

POGLAVLJE 4 MRENI 5LOJ

4.2 . MREE 5A VIRTUALNIM KOLIMA I SA DATAGRAMIMA

313

Prefiks

Interfejs linka

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.

iiooiooooooioin 00010 iiooiooooooioin 00011000 iiooiooooooioin ooon

inae

o i
2
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.

314

POGLAVLJE 4

MRENI SLOJ

4.3 . TA IMA U RUTERU?

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.

316

POGLAVLJE 4 MRENI SLOJ

4.3 TA IMA U RUTERU?

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).

Stl*-?'
CISCO SISTEMI: DOMINACIJA JEZGROM MREE

KRATAK OSVRT

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 2N.) 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.

318

POGLAVLJE 4 MRENI SLOJ

4.3 TA IMA U RUTERU?

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.

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

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-

172

POGLAVUE 4 . MRENI SLOJ

4.3 TA IMA U RUTERU?

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 sluaju, 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

J322

POGLAVLJE 4 MRENI SLOJ

4.4

INTERNET PROTOKOL (IP)

173

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.

174

POGLAVLJE 4

MRENI SLOJ

4.4 . INTERNET PROTOKOL (IP)

325

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: 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

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.

Control Message Protocol), Internetov protokol mrenog sloja za izvetavanje o grekama i davanje
informacija.

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

POGLAVLJE A MRENI SLOJ

4.4 INTERNET PROTOKOL (IP)

175

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.

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.

-i

176

POGLAVLJE 4 - MRENI SLOJ

4.4 . INTERNET PROTOKOL (IP)

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

POGLAVLJE 4

MRENI SLOJ

4.4

INTERNET PROTOKOL (IP)

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 moguih IP adresa.
n

Kako je 231 priblino 4,3 * IO3, 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 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

-1

178

POGLAVLJE 4

MRENI SLOJ

4.4 - INTERNET PROTOKOL (IP)

333

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

179

POGLAVLJE 4

MRENI SLOJ

4.4 . INTERNET PROTOKOL (IP)

335

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 2E - 2 = 254 raunara (dve od 2a = 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.

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

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.)

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

336

POGLAVLJE 4 - MRENI SLOJ

4.4 . INTERNET PROTOKOL [IP]

180

Posrednikovblok200.23.16,0/20 Organizacija 0 Organizacija 1 Organizacija 2 200.23.16.0/23 200.23.18.0/23 200.23.20.0/23

11001000 00010111 00010000 00000000 11001000 00010111 00010000 00000000 11001000 00010111 00010010 00000000 11001000 00010111 00010100 00000000

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

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 (a takode i agregacija ruta ili sumiranje ruta].

R-U blok 199.31.0.0/16. Meutim, posrednik R-U sada objavljuje jo 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.

181

POGLAVLJE 4

MRENI SLOJ

4.4 . INTERNET PROTOKOL (IP)

339

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 serverima. 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)

34ij

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 nedostatka 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

183

POGLAVLJE 4 . MRENI SLOJ

4.4 . INTERNET PROTOKOL (IP)

343

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].

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.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.

184

POGLAVLJE 4

MRENI SLOJ

4.4 INTERNET PROTOKOL (IP)

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.

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 preslikanih 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

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].

185

POGLAVLJE 4

MRENI SLOJ

4.4 - INTERNET PROTOKOL (IP)

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-

186

POGLAVLJE 4

MRENI SLOJ

4.4 . INTERNET PROTOKOL (IP)

349

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

POGLAVLJE 4 MRENI SLOJ

4.5 ALGORITMI RUTIRANJA

351

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].

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.

352

POGLAVLJE 4 - MRENI SLOJ

4.5 ALGORITMI RUTIRANJA

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 (*,, x 2 .......... x p ) takvih daje svaki od parova (x 1 ,x 1 ), x3), (x,, x ) ivica izE. Cena putanje (x,, x 2 , >.. t x p )je prosto zbir cena svih ivica na putanji, tj. C(JC,, x 2 ) + c(x 2 , JC3) + ... + C(JC x p ). 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 rutiranja 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.

Algoritam stanja linkova (Link State, LS) za izvorni vor u: 1

2

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.

3 4 5 6 8 9 10 11 12 13 14 15

Inicijalizacija: N' = {u} za sve vorove v ako je v sused u then D(v) = c(u,v) else D(v) = 7 Loop petlja w nije u N' tako da je D<w) minimum koji w dodaje u N' aurira D(v) za sve v susedne w koji nisu N': D(v) = min(D(v), D(w) + c(w,v) ) /* nova cena do v je stara cena do v ili cena poznate najkrae putanje do w plus cena od w do v */ 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.

190

POGLAVLJE 4 . MRENI SLOJ

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 , w i z auriraju se u 12. redu algoritma LS gde se dobijaju rezultati prikazani u treem redu tabele 4.3.

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 w u 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.

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 A7'. 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(n2). (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-

k s8

POGLAVLJE 4

MRENI SLOJ

4.5 . ALGORITMI RUTIRANJA

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)

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. D x = [ 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 JC do vora ;>[Bersekas 1992]!

Izraz minv u jednaini predstavlja minimum svih direktno povezanih suseda vora x. Belman-F^ordova 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

360

POGLAVLJE 4 . MRENI SLOJ

4.5 . ALGORITMI RUTIRANJA

361 t

Algoritam sa vektorom rastojanja Na svakom voru, x: 1 Initialization: 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 14 16 17 19 for each y in N: Dx (y) - minv{ c(x,v) + Dv(y)} 15 if Dx (y) changed for any destination y send'distance vector Dx = [ Dx (y) : y i n N] to ali neighbors 18 forever

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 = [ Dx (x), Dx (y), Dx (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

Dx (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 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.

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, Dx (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

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 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).

364

POGLAVLJE 4 MRENI SLOJ

4.5 . ALGORITMI RUTIRANJA

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.

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

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).

366

POGLAVUE 4 MRENI SLOJ

4.5 ALGORITMI RUTIRANJA

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

368

POGLAVLJE 4

MRENI SLOJ

4.5 . ALGORITMI RUTIRANJA

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-

370

POGLAVLJE 4

MRENI SLOJ

4.6

RUTIRANJE NA INTERNETU

197

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 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. 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 dokumentu 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 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.

198

POGLAVLJE 4 . MRENI SLOJ

4.6

RUTIRANJE NA INTERNETU

198

ruteri (A, B, C i D) i podmree (w, x, y i

z).Isprekidane linije ukazuju na to da se AS produava

Pretpostavimo sada da nakon 30 sekundi ruter

primi od rutera

objavu prikazanu na slici

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

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

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 Daurira 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

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

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.

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. 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). Administrator 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.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-

-?-

200

POGLAVLJE 4 . MRENI SLOJ

4.6 RUTIRANJE NA INTERNETU

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].

201

POGLAVLJE 4 - MRENI SLOJ

4.6 . RUTIRANJE NA INTERNETU

379

PRINCIPI U PRAKSI
PODEAVANJE 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.

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 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

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.

202

POGLAVLJE 4 MRENI SLOJ

4.6 . RUTIRANJE NA INTERNETU

381

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. 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. 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

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

I 382

POGLAVLJE 4

MRENI SLOJ

4.7 . RUTIRANJE NA INTERNETU

203

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! 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.

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

204

POGLAVLJE 4

MRENI SLOJ

4.7 . DIFUZNO I VIEZNANO RUTIRANJE

385!

PRINCIPI U PRAKSI
ZATO SE UNUTAR 1 IZMEU ASAS-OVA KORISTE RAZLIITI 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:

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).

Politika. 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.

Skaliranje. 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.

Pravljenje/prenoenje duplikata

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

386

POGLAVLJE 4

MRENI SLOJ

4.7

DIFUZNO I VIEZNANO RUTIRANJE

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 =

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 putanju 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

{ 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.)

B,E\F,

206

POGLAVLJE 4 . MRENI SLOJ

4.7 . DIFUZNO I VIEZNANO RUTIRANJE

389!

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,Er) 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).'

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.

207

POGLAVLJE 4

- MRENI SLOJ

4.7 DIFUZNO I VIEZNANO RUTIRANJE

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

392

POGLAVLJE 4 - MRENI SLOJ

4.7

DIFUZNO I VIEZNANO RUTIRANJE

393j

128.59.16.20

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

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

394

POGLAVLJE 4

MRENI SLOJ

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 message) 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

POGLAVLJE 4 MRENI SLOJ

4.7 . DIFUZNO I VIEZNANO RUTIRANJE

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

POGLAVLJE 4

MRENI SLOJ

4.8 . DIFUZNO I VIEZNANO RUTIRANJE

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.

400

POGLAVLJE 4 MRENI SLOJ

DOMAI ZADATAK: DOMAI ZADATAK: PROBLEMI I PITANJA

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

Poglavlje 4 Kontrolna 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. Koje su dve glavne funkcije mrenog sloja u mreama sa datagramima? Koje dodatne funkcije ima mreni sloj u mreama sa virtuelnim kolima? .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. 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? Navedite neke aplikacije koje bi imale koristi od ATM-ovog modela usluge CBR.

2.

3. Kakva je razlika izmeu rutiranja i prosledivanja? 4. 5.

6.

ODELJAK 4.3

7. 8. 9.

Objasnite zato svaki ulazni port u ruteru velike brzine uva kopiju tabele prosledivanja? U odeljku 4.3 opisuju se tri vrste komutatorske mree. Navedite koje su i ukratko ih opiite. 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

POGLAVLJE 4

MRENI SLOJ

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.
i 1

15. Pretpostavite da izmeu izvornog i odredinog raunara postoje tri rutera. AJco zanemarimo fragmentaciju, preko koliko interfejsa e prei IP segment koji se 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 25. 26. Da li e se tabela u D promeniti? Ako hoe, kako? Opiite razliku meu objavama protokola RIP i protokola OSPF. 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?

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 UDPu 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-

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

nim ruterom. Kako se IP adrese dodeljuju PC-jima? Da li beini ruter koristi NAT? Zato? 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 kao protokole sloja veze. Da li se slaete sa tim tvrenjem? Zato? ODELJAK 4.5 21. Navedite razlike algoritama rutiranja prema stanju linkova i prema vektorima rastojanja. 22. Objasnite kako je hijerarhijsko organizovanje Interneta pomoglo pri skaliranju na milione korisnika. 23. Da lije neophodno da svi autonomni sistemi koriste isti algoritam rutiranja unutar AS-a? Zato? ODEUAK 4.6 24. Razmotrite sliku 4.31. Uzmite prvobitnu tabelu u D i pretpostavite da D primi od .4 sledeu objavu:

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?

j
\

j I
j j
i I

) \ |

I
j

"i

404

POGLAVLJE 4 - MRENI SLOJ

PROBLEMI

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 okruenje 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 poiljalac objavi svoju maksimalnu brzinu saobraaja. Ako su prijavljena maksimalna brzina saobraaja i postojea objavljena brzina saobraaja takve da nije mogue preneti saobraaj od izvora do odredita u zahtevanim granicama 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 putanje 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 slobodnih 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 linkovima 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 n inoooo 00000000 00000000 00000000 do 11100000 l i i u i n m i l i l i m i l i l i 11100001 00000000 00000000 oooooooo do 11 101001 00000000 I1I1I111 1 1 1 1 1 1 1 1 11101001 00000001 00000000 00000000 do 1110100L tlllUU UllIlU muni Inae . 2 1 Interfejs linka 0

a. Napravite tabelu prosledivanja sa etiri stavke koja e koristiti pravilo najdueg 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

POGLAVLJE 4

MRENI SLOJ

PROBLEMI

407

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. 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: 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, 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 18. U ovom problemu treba da analiziramo uticaj NAT-a na P2P aplikacije. Pretpostavite da ravnopravni uesnik Amold upitom otkrije da uesnik po imenu Bernard ima datoteku koju eli da preuzme. Pretpostavite takoe da se-Bernard 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 Bernardom 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 uspostavi (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 aplikaciju. Ako imate tekoe sa defmisanjem takve tehnike, objasnite zato.

408

POGLAVLJE 4 . MRENI SLOJ

PROBLEMI

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.

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. 22. Razmotrite mreu prikazanu u problemu 21. Pomou Dijkstrinog algoritma u obliku slinom tabeli 4.3, a. b. c. d. e. f. g. izraunajte najkrau putanju od s do svih ostalih mrenih vorova. izraunajte najkrau putanju od i do svih ostalih mrenih vorova. izraunajte najkrau putanju od u do svih ostalih mrenih vorova. izraunajte najkrau putanju od v do svih ostalih mrenih vorova. izraunajte najkrau putanju od w do svih ostalih mrenih vorova. izraunajte najkrau putanju o&y do svih ostalih mrenih vorova. izraunajte najkrau putanju od z do svih ostalih mrenih vorova. 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 ne e obavestiti svoje susede o postojanju nove najjeftinije putanje prema u nakon izvravanja 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.

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

410

POGLAVLJE 4

MRENI SLOJ

PROBLEMI

411

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. 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. 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 30. Razmotrite mreu sa osam vorova (gde su vorovi oznaeni slovima od s do

2) iz problema

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.

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,

412

POGLAVLJE 4 . MRENI SLOJ

LABORATORIJA ETHEREAL

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?

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.

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.

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.

INTERVJU

Vinton G. 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

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?

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.

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?

fa vas je navelo na specijalizaciju h oblasti umre avan\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?

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?"

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.

219

415

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

220

418

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5 .1

SLOJ VEZE PODATAKA: UVOD I USLUGE

221

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. 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.

222

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.1

SLOJ VEZE PODATAKA: UVOD I USLUGE

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

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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.2

TEHNIKE ZA OTKRIVANJE I ISPRAVLJANJE GREAKA

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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.2

TEHNIKE ZA OTKRIVANJE I ISPRAVLJANJE GREAKA

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 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.

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 2k pomera bitove u levo za k mesta. Dakle, uz date D i R, izraz D 2rXOR 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 -2rXOR R = nG To znai, elimo da odaberemo R koje G deli sa> 2rXORtf bez ostatka. Ako izvrimo iskljuivo-ILI (odnosno, saberemo po modulu 2 bez prenosa) R sa obe strane gornje jednaine, dobijamo D-2'=nGXORR Ova jednaina nam govori da ako podelimo D 2rsa G, vrednost ostatka je tano R. Drugim recima, moemo da izraunamo R na sledei nain D-2r R = ostatak od

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,

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 2r = 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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

431

- 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 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,5r. 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. 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.

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

432

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

228

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.

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.

229

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

435

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: 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 kanalima, 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.. 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.)

436

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

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.

438

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNEMREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

231

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.
NORM ABRAMSON I ALOHANET

KRATAK OSVRT

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

232

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.3

PROTOKOLI VIESTRUKOG PRISTUPA

443

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 oslobodi 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

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-

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 248 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 224 adresa, za iznos nominalne lanarine. IEEE dodeljuje deo od 224 adresa, fiksirajui prva 24 bita fizike adrese i dozvoljavajui kompaniji da pravi jedinstvene kombinacije od poslednja 24 bita za svaki adapter.

235

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.4

ADRESIRANJE SLOJA LINKA

447

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.

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.

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

448

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.4

ADRESIRANJE SLOJA LINKA

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.

237

POGLAVLJE 5

SLOJ VEZE PODATAKA 1 LOKALNE MREE RAUNARA

5.4

ADRESIRANJE SLOJA LINKA

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.111. 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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.4

ADRESIRANJE SLOJA LINKA

453i

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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.5

ETHERNET

239

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 predstavljen 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.

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],
Slika 5.22 Originalna Mefkalfova konstrukcija dovela je do standarda Ethernet 10Base5, koji je obuhvatao interfejsni kabl za povezivanje Ethernet adaptera sa spoljanjim primopredajnikom.

456

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.5

ETHERNET

240

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. 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], 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 datagramu 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.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;

241

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA 5.5 . ETHERNET 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. 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.

KRATAK OSVRT

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.

I-

460

POGLAVLJE 5

SLOJ VEZE PODATAKA i LOKALNE MREE RAUNARA

5.5

ETHERNET

242

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.

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.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.

243

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

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.

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.

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 0Sta e veom ^ranj-P J 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.

244

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

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.

245

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.6

MEUSOBNE VEZE: HABOVI I KOMUTATORI

245

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

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 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.

POGLAVLJE 5

SLOJ VEZE PODATAKA 1 LOKALNE MREE RAUNARA

5.6

. MEUSOBNE VEZE: HABOVI I KOMUTATORI

469

Komutator

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 svaki1 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. 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

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

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

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 provodnika. 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 dupleksa 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

POGLAVLJE 5

SLOJ VEZE PODATAKA l LOKALNE MREE RAUNARA

5.6

MEUSOBNE VEZE: HABOVI I KOMUTATORI

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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.7

PPP: PROTOKOL OD TAKE TO TAKE

250

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

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],

478

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

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.

252

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

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.

253

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

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

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.8

VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE

485

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.

486

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.8

VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE

255

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

i -

256

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.8

VIZUELIZACIJA LINKA: MREA KAO SLOJ VEZE

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. 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).

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

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-

257

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

5.9

REZIME

491

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! 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

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

492

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

DOMAI ZADATAK: PROBLEMI I PITANJA

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| 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 odgovarajue 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?

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
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 odsecima je data izrazom Np(l~p)N-l. Pronaite vrednostp koja daje maksimalnu 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!

496

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA

PROBLEMI

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 efikasnost 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 eksponencijalnog 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 I08 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 sekundama je paket vora A isporuen voru B? 16. Setite se da ATM koristi 53-bajtne pakete koji se sastoje od pet bajtova zaglavlja 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;

498

POGLAVLJE 5

SLOJ VEZE PODATAKA I LOKALNE MREE RAUNARA ETHEREAL LAB 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 kanjenje 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 komutatoru 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
3 m al 23 V0 P gtavije Prvi lS tu e rad mEEtTv? r Drugi istrauje P' J' P' O^ola Ibbh 802.3 i format Ethernet okvira. upotrebu protokola DHCP koii

U prateoj, veb lokaciji za ovu knjigu, http://ww.awl.com/kurose-ross, pronai ete

J

smo prouili u odeljku 5.4.3.

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 S. 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.

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.

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?

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 najmonija 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.

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

501

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
263

264

POGLAVLJE 6

BEINE I MOBILNE MREE

6.1

UVOD

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

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.

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.

508

POGLAVLJE 6

BEINE I MOBILNE MREE

6.2

BEINI LINKOVI I MRENE KARAKTERISTIKE

266J 266J

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

POGLAVLJE 6

BEINE 1 MOBILNE MREE

6.2

BEINI LINKOVI I MRENE KARAKTERISTIKE

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:
iu (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

POGLAVLJE

BEINE I MOBILNE MREE

6.3

VVI-Fi: BEZICNIlAN-OVITIPA 802.il

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

516

POGLAVLJE 6

BEINE I MOBILNE MREE

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 pridruene 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 pregovaraju 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

518

POGLAVLJE 6

BEINE I MOBILNE MREE

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

272

POGLAVLJE 6

BEINE I MOBILNE MREE

6.3

VVI-FI: BEINI LAN-OVI TIPA 802.11

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/

512

POGLAVLJE 6

BEINE I MOBILNE MREE

6.3

. VVI-FI: BEINI LAN-OVI TIPA 802.11

273

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.

^^^^^^^^

274

POGLAVLJE 6

BEINE I MOBILNE MREE

6.3

. VVI-FI: BEINI LAN-OVI TIPA 802.11

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.

526

POGLAVLJE 6

BEINE 1 MOBILNE MREE

6.3

VVI-FI; BEINI LAN-OVJTIPA 802.il

275

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.)

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

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

276

POGLAVLJE 6

BEINE I MOBILNE MREE

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 zavr ava 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).

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

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].

532

POGLAVLJE 6

BEINE I MOBILNE MREE

d.4

CELULARNI PRISTUP INTERNETU

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 svakom 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.

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.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

279

POGLAVLJE 6

BEINE I MOBILNE MREE

6-4

CELULARNI PRISTUP INTERNETU

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.

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.

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:

280

POGLAVLJE 6

BEINE I MOBILNE MREE

6.5

UPRAVUANJE MOBILNOU: PRINCIPI

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).

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 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.

281

POGLAVLJE 6

BEINE I MOBILNE MREE

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.

282

POGLAVLJE 6

BEINE l MOBILNE MREE

6.5

UPRAVLJANJE MOBILNOU: PRINCIPI

541

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.

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).

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

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,

284

POGLAVLJE 6

BEINE I MOBILNE MREE

6.5

UPRAVUANJE MOBILNOU: PRINCIPI

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 datagram 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.

546

POGLAVLJE 6

BEINE I MOBILNE MREE

6.6

MOBILNI IP

285

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. Znaajnija 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.

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.

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.

Prijavljivanje matinom agentu Kada mobilni IP vor pribavi adresu COA, ta adresa mora da se prijavi matinom agentu. To moe da uradi strani agent (koji zatim prijavljuje adresu COA matinom agentu) ili direktno sam mobilni IP vor. Razmotriemo prvi sluaj koji se sastoji iz etiri koraka. 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 od 64 bita. Zahtevano trajanje prijave je broj sekundi koliko prijava treba da 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 uparivanje odgovora o primljenoj rezervaciji sa zahtevom za rezervaciju, to 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 enkapsulirane datagrame ija je odredina adresa jednaka trajnoj adresi mobilnog vora. Strani agent tada alje poruku sa mobilnom IP prijavom (opet u UDP datagramu) na port 434 matinog agenta. Poruka sadri COA, HA, MA, zahtevani format enkapsuliranj a, zahtevano trajanje prijave i identifikaciju prijave. 3. Matini agent prima zahtev za prijavu i proverava autentinost i ispravnost. Matini agent povezuje trajnu IP adresu mobilnog vora sa adresom COA; ubudue, datagrami koji budu stizali matinom agentu, a namenjeni su mobilnom voru bie enkapsulirani i tunelovani ka adresi COA. Matini agent alje odgovor na mobilnu IP prijavu, a on sadri HA, MA, odobreno trajanje prijave 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.

i J j j i
! ] \ \

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.

i j

\
1

\ | \
J j

j i

; \ !i

550

POGLAVLJE 6

BEINE l MOBILNE MREE

6.7

UPRAVLJANJE MOBILNOU U CELULARNIM MREAMA

551

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.

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-

288

POGLAVLJE 6

BEINE I MOBILNE MREE

6.7

. UPRAVLJANJE MOBILNOU U CELULARNIM MREAMA

551

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.

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].

289

POGLAVLJE 6

BEINE 1 MOBILNE MREE

6.7

UPRAVUANJE MOBILNOU U CELULARNIM MREAMA

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

POGLAVLJE o

BEINE I MOBILNE MREE

6.7

UPRAVLJANJE MOBILNOU U CELULARNIM MREAMA

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-

291

POGLAVLJE 6

BEINE l MOBILNE MREE

6.8

BEINE MREE I MOBILNOST: POSLEDICE PO PROTOKOLE VIIH NIVOA

291

aplikacijski sloj ne mora da se menja. Na neki nain intuitivna logika je tana - TCP i UDP mogu da 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 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.

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 minimalne 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

558

POGLAVLJE 6

BEINE I MOBILNE MREE

DOMAI ZADATAK: PROBLEMI I PITANJA

55t

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

Poglavlje 6 Kontrolna 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

POGLAVLJE 6

BEINE I MOBILNE MREE

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? 7.

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). 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?

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. 8.

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. Pretpostavite daje korespondent sa slike 6.17 mobilan. infrastrukturu u mrenom sloju koja bi bila potrebna da se prvobitno mobilnog korisnika do korespondenta (koji je sada strukturu datagrama izmeu prvobitno mobilnog korisnika korespondenta kao na slici 6.18. Skicirajte dodatnu datagram rutira od mobilan). Prikaite i sada mobilnog

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
V

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?

Carli 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 Mobilily\. Takoe je medu izdavaima asopisa Mobile

Communications and Compufing, zvanine publikacije interesne grupe ACM 5IGMOBIIE,

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.

radio je i u urednitvu asopisa IEEE Internet Computing, 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.

Zato

ste

odluili

da

se

specijali'iujete

za

beino

umreavanje

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 raunarskoj 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

Kakva je vaa vizija budunosti multimedijskog umreavanja? Mi smo sada u prelaznoj fazi, na samo nekoliko godina od trenutka kada e IP postati univerzalna 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?

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 komunicira 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

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.

652 295

296

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.1

TA JE BEZBEDNOST MREE

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.

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 .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.

656

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.2

TA JE BEZBEDNOST MREE

297

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-

-i-

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.

KRATAK OSVRT
TAKMIENJA U RAZBIJANJU KODOVA Usvojen prvo od strane Vlade SAD 1977. godine, 56-bilni algoritam standarda za ifrovanje podataka (Data Encryption 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.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

660

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.2

PRINCIPI KRIPTOGRAFIJE

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 IO26) a ne samo 25 moguih uparivanja. Pristup grube sile, tj. pokuaja sa svih IO26 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 IO9 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

300

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.2

PRINCIPI KRIPTOGRAFIJE

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

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.2

PRINCIPI KRIPTOGRAFIJE

665

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 255 kljueva u sekundi) trebalo priblino 149 triliona godina da razbije 128-bitni AES klju.

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(KBr(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.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 ifrovano 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

302

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

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 me 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 nto 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

668

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.2

PRINCIPI KRIPTOGRAFIJE

303

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 (me)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 (mc)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 (mc)d mod n = m[ mod = m odnosno, (me)d mod n = m 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. 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, (me)d mod = m = (md)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".

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

304

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.3

AUTENTIFIKACIJA

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.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.

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.

J672

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.3

AUTENTIFIKACIJA

673

8.3.3 Autentifikacioni protokol ap3.0

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.

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.

8.3.5 Autentifikacioni protokol ap4.0

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.4 Autentifikacioni protokol ap3.1

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

306

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.3

AUTENTIFIKACIJA

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".

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).

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.6 Autentifikacioni protokol ap5.0

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.

307

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.3

AUTENTIFIKACIJA

677

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).

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

678

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.4

INTEGRITET

308

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.

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.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-

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,

309

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA 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)). Odnosno, 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

310

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

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 2M operacija, a tekoa dolaenja do bilo kakve poruke koja ima dati izvod poruke je veliine reda veliine 2I2S 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.

684

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.5

DISTRIBUCIJA I OVERAVANJE KLJUEVA

311.

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, klju ne (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. 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], 1

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.

686

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.5

. DISTRIBUCIJA I OVERAVANJE KUUEVA

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

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, K b.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.

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

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-

313

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.5

DISTRIBUCIJA I OVERAVANJE KLJUEVA

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

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.6

KONTROLA PRISTUPA: MRENE BARIJERE

691

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. 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.

Slika 8.22 Uverenje koje je kompanija Thavvle Consulting izdala firmi Netfarmers Enterprisers, Inc.

692

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

6.6

KONTROLA PRISTUPA: MRENE BARIJERE

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 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

Slika 8.23 Postavljanje mrene barijere izmeu administrirane mree i spoljanjeg sveto

694

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

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

POGLAVLJE 8 696

BEZBEDNOST U RAUNARSKIM MREAMA

8.7

NAPADI I KONTRAMERE

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 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 udaljenog 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

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.7

NAPADI I KONTRAMERE

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

319

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8-7

NAPADI I KONTRAMERE

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!

702

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

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].

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,

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

321

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.8

BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA

705

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.

1"

706

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.8

BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA

322

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.

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.

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-

708

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

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 Pofpisana PGP poruka

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-

-----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 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.

324

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.8

BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRiMERA

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.

712

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.8

BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA

325

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.

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.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.

714

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.8

BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA

326^ 326^

IP datagram, on zapisuje 5 1 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 s t o j 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.

327

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

8.8

BEZBEDNOST U MNOGO SLOJEVA: STUDIJE PRIMERA

717

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.

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^IV)), algoritam RC4 proizvodi niz vrednosti kljueva, k/f\ k2n', k3lv,.,. 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^IV) da bi proizveo i-ti bajt ifrovanog teksta, c:. ci=djXORkfv 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 X O K k 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 22a 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

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:

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:
4 X O R c , _ k\
v

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:

Pomou ove relacije, Trudi moe da upotrebi poznate vrednosti d-t i ci da bi izra-unala kjv. Sledei put kada Trudi vidi da se koristi ista vrednost IV, ona e znati sekvencu kljueva k / v y k2IV, 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.

720

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

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

722

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA

PROBLEMI

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.

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".

Domai zadatak: problemi i pitanja Poglavlje 7 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?

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 IO9. 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.

724

POGLAVLJE 8

BEZBEDNOST U RAUNARSKIM MREAMA TEZE ZA DISKUSIJU 725

7. 8. 9.

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? Izraunajte treu poruku, razliitu od dve poruke na slici 8.18, koja ima isti kontrolni zbir kao poruke na slici 8.18. Zato Alisa ne mora eksplicitno da autentifikuje Boba u protokolu i diskusiji slike 8.19? potrebna? Zato?

10. Zato nema eksplicitne autentifikacije u protokolu na slici 8.19? Da li je autentifikacija 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 d a j 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 R l ; 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 R l , R2, R3 i prema redosledu R2, R l , R3. Koji bi bio rezultat uklanjanja pravila R2 za pakete P l , P2, P3 i P4?

IN T E RVJ U

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.

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 Vaa vizija budunosti umreavanja 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 kaete neto o specijalnim projektima na kojima ba sada radite?

ta Vas je navelo da se specijalizujete u oblasti bezbednosti umreavanja?

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 Vaa vizija Useneta iz vremena kada ste ga razvijali? A sada?

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 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 ta biste rekli da su najvea dostignua u bezbednosti? bezbednosti? Koliko daleko moemo da idemo?

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 nain?

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 i bezbednosti umreavanja 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.

726

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

727