T C P / IP

Deo materijala za pripremu ispita iz predmeta

- Računarske mreže i interfejsi -
SMER: Elektronika
Godina: 2006/2007
2
 SADRŽAJ

1 INTERNET..................................................................................................................................................5
1.1 STRUKTURA INTERNETA .......................................................................................................................5
1.2 PAKETSKI PRENOS ................................................................................................................................6
1.3 TCP/IP .................................................................................................................................................8
1.4 ADRESIRANJE .......................................................................................................................................9
1.5 INTERNET STANDARDI ........................................................................................................................11
2 INTERNET SLOJ .....................................................................................................................................13
2.1 IP ADRESIRANJE .................................................................................................................................13
2.1.1 Klasno IP adresiranje ...................................................................................................................13
2.1.2 Besklasno IP adresiranje ..............................................................................................................23
2.2 ISPORUKA, PROSLEĐIVANJE I RUTIRANJE IP DATAGRAMA ..................................................................28
2.2.1 Isporuka ........................................................................................................................................28
2.2.2 Prosleđivanje ................................................................................................................................29
2.2.3 Rutiranje .......................................................................................................................................37
2.2.4 Struktura rutera ............................................................................................................................37
2.3 ARP I RARP......................................................................................................................................39
2.4 INTERNET PROTOKOL (IP)...................................................................................................................44
2.4.1 Datagram ......................................................................................................................................44
2.4.2 Fragmentacija...............................................................................................................................45
2.4.3 Opcije............................................................................................................................................47
2.4.4 Kontrolna suma.............................................................................................................................49
2.5 NAT ...................................................................................................................................................51
2.6 ICMP .................................................................................................................................................53
3 TRANSPORTNI SLOJ.............................................................................................................................58
3.1 PORTOVI .............................................................................................................................................58
3.2 UDP ...................................................................................................................................................59
3.2.1 Korisnički datagram .....................................................................................................................59
3.2.2 Način rada ....................................................................................................................................60
3.2.3 Primene.........................................................................................................................................61
3.3 TCP....................................................................................................................................................62
3.3.1 Servisi ...........................................................................................................................................62
3.3.2 Mehanizmi.....................................................................................................................................64
3.3.3 Segment.........................................................................................................................................65
3.3.4 Konekcija ......................................................................................................................................66
3.3.5 Dijagram stanja ............................................................................................................................70
3.3.6 Kontrola protoka...........................................................................................................................74
3.3.7 Kontrola grešaka ..........................................................................................................................75
3.3.8 Kontrola zagušenja .......................................................................................................................82
4 APLIKACIONI SLOJ ..............................................................................................................................88
4.1 KLIJENT-SERVER MODEL ....................................................................................................................88
4.2 TELNET ............................................................................................................................................89
4.3 FTP ....................................................................................................................................................96
4.4 ELEKTRONSKA POŠTA.......................................................................................................................102
4.4.1 Arhitektura ..................................................................................................................................102
4.4.2 Korisnički agent ..........................................................................................................................104
4.4.3 Agent za prenos poruka: SMTP ..................................................................................................109
4.4.4 Agent za preuzimanje poruka: POP3 i IMAP4 ...........................................................................112
4.5 DNS .................................................................................................................................................115

3
5 WEB .........................................................................................................................................................124
5.1 WEB PRETRAŽIVAČ...........................................................................................................................125
5.2 WEB SERVER ....................................................................................................................................127
5.3 URL .................................................................................................................................................129
5.4 COOKIE.............................................................................................................................................130
5.5 STATIČKI WEB DOKUMENTI..............................................................................................................132
5.6 DINAMIČKI I AKTIVNI WEB DOKUMENTI ...........................................................................................138
5.7 HTTP ...............................................................................................................................................143
5.8 PROKSI SERVERI I KEŠIRANJE STRANICA ...........................................................................................147
5.9 FIREWALL.........................................................................................................................................148

4
1 Internet
1.1 Struktura Interneta
Internet je gigantska mreža prvobitno kreirana povezivanjem različitih istraživačkih i odbrambenih (vojnih)
mreža (kao što su NSFnet, MILnet i CREN). Od tada, na Internet su priključene brojne druge mreže – velike i
male, privante i javne. Sa preko 400 miliona hostova, Interent je danas ubedljivo najveća i najrsprostranjenija
svetska mreža.
Internet poseduje tronivovsku strukturu (Sl. 1-1).
Okosnica Interneta ili backbone predstavlja vršni nivo u hijerarhiji Interneta. Sastoji se od mreža kao što su
NSFnet i EBONE koje prenose saobraćaj i obavljaju rutiranje za mreže srednjeg nivoa. To su mreže veoma
velike propusne moći koje poput kostura drže na okupu sve razuđene delove Interneta.
Tranzitne mreže, takođe poznate i kao regionalne, u hijerarhiji Inerneta se nalaze odmah ispod backbone mreža.
Nihov zadatak je da, osim za svoje hostove, prosleđuju saobraćaj i između drugih mreža istog ili nižeg nivoa.
Tranzijentna mreža je uvek povezana sa barem dve duge mreže.
Periferne mreže su u osnovi lokalne (LAN) ili gradske (MAN) mreže koje prenose podatke isključivo ka i od
svojih hostova. Čak i kada su povezane sa jednom ili više drugih mreža, kroz periferne mreže nikada ne prolazi
saobraćaj nemenjen nekoj drugoj mreži.

Sl. 1-1 Struktura Interneta.

Rast Interneta je veoma brz, sa stopom od 10-15% mesečno (Sl. 1-2), a broj mreža koje se razgranavaju sa
Internet backbone-a se udvostručava svakih 16 meseci. Internet backbone koji je 90-tih godina ima oblik ˝riblje
kosti˝, danas više liči na ˝ribarsku mrežu˝ razapetu po celom svetu.
Broj hostova na Internetu (u milionima)

Godina

Sl. 1-2 Rast Interneta.

5
1.2 Paketski prenos
U komunikacionim mrežama koje pokrivaju veća geografska rastojanja, kao što je Internet, komunikacija
između izvora i odredišta se ostvaruje prenosom podataka kroz mrežu posrednih komutacionih čvorova, tj.
rutera. Ruteri se ne bave interpretacijom sadržaja i značenja podataka, već se bave prenosom podataka od čvora
do čvora na njihovom putu do krajnjeg odredišta. Na Internetu se koristi koncept prenosa podataka koji se
naziva komutacijom paketa. Shodno ovom konceptu, poruke se prenose u kratkim blokovima, tzv. paketima
Dužina paketa je ograničena, a maksimalno dozvoljena dužina obično ne prelazi 1000 bajta. Duže poruke, koje
se ne mogu upakovati u jedan paket, u izvornom hostu se dele na niz paketa, koji se nezavisno prenose kroz
mrežu. Svaki paket ima deo za korisničke podatke i deo za kontrolne informacije. Kontrolne informacije,
između ostalog, sadrže informacije koje su neophodne ruterima kako bi paket usmerili ka željenom odredištu. U
svakom ruteru, paket se prima, skladišti i nakon izvesnog vremena prosleđuje sledećem ruteru.

(a)

(b)

(c)

1
2

(d)

(e)
Sl. 1-3 Komutacija paketa: datagramski pristup.
Na Sl. 1-3 je ilustrovan osnovni princip rada komutacije paketa. Računar sa leve strane slike šalje poruku
računaru sa desne strane. Predajni (izvorni) računar deli sadržaj poruke na niz paketa (Sl. 1-3(a)). Svaki paket,
pored podataka iz originalne poruke, sadrži, u delu za kontrolne informacije, informaciju koja identifikuje
odredišni host. Izvorni računar šalje paket po paket ruteru sa kojim je povezan. Ovaj ruter privremeno skladišti

6
(baferuje) primljene paket; za svaki paket, na osnovu kontrolnih informacija iz paketa, određuje kom susednom
ruteru treba proslediti paket i smešta paket u red čekanja pridružen izlaznoj liniji koja vodi ka izabranom
susednom ruteru. Paket ostaje u redu čekanja sve dok svi prethodni paketi iz reda čekanja ne budu poslati, a
zatim se i on šalje na liniju. Na ovaj način, krećući se od rutera do rutera ( Sl. 1-3(b-d)), paket konačno stiže na
svoje krajnje odredište (Sl. 1-3(e)).
Kod mreža sa komutacijom paketa, svaki paket se u svakom ruteru nezavisno obrađuje, a način na koji će ruter
postuputi prema datom paketu ne zavisi od toga kako je postupao prema prethodnim paketima. Ovaj pristup je
ilustrovan na Sl. 1-3. Usmeravanje paketa u ruterima nije jednoznačno. Kada ruter donosi odluku na koju stranu
usmeriti paket, on uzima u obzir ne samo informaciju o adresi odredišnog hosta, već i informacije prikupljene
od susednih rutera koje se tiču njihovog trenutnog opterećenja, otkaza pojedinih prenosnih linija i sl. To znači da
paketi sa istom odredišnom adresom ne moraju biti uvek isporučeni istom susednom ruteru (Sl. 1-3(c)).
Posledica ove neodređenosti je pojava da paketi koji se prenose između para hostova mogu stići do odredišta
različitim putanjama i izvan redosleda u kojem su poslati. U primeru sa Sl. 1-3, krajni ruter na putanji uređuje
pristigle pakete u prvobitni redosled i isporučuje ih odredištu. (Napomenimo da je kod nekih datagramskih
mreža, preuređenje paketa zadatak odredišnih stanica, a ne krajnjih čvorova.) Takođe, može se desiti da neki
paketi budu uništeni u toku prenosa. (Na primer, ako neki ruter otkaže, svi paketi koji trenutno borave u ruteru,
biće izgubljeni.) Ponovo, detekcija izgubljenih paketa i odluka kako postupiti u ovakvim situacijama je u
nadležnosti krajnjih hosova. Kod mreža koje koriste opisanu tehniku komutacije, za pakete se uobičajeno koristi
termin datagram.
Osnovne karakteristike paketskog prenosa, koje ga čine pogodnim za primenu kod Interneta su:
• Prenosne linije se efikasno koriste, obzirom da se komunikacioni kapacitet linije, koja povezuje dva rutera,
dinamički, u vremenu, raspodeljuje na prenos mnogih paketa. Paketi koji iz različitih pravac stižu u čvor, a
koje treba dalje preneti preko iste izlazne linije, smešataju se u red čekanja pridružen toj liniji. Ruter uzima
pakete sa početka reda čekanja i maksimalnom brzinom ih šalje na liniju.
• Mreža sa komutacijom paketa može da amortizuje razlike u brizni prenosa podataka različitih hostova.
Paketi se baferuju u ruterima, što znači da paket može biti primljen jednom, a poslat drugom brzinom. Na
ovaj način, u mreži sa komutacijom paketa moguće je kombinovati spore i brze prenosne medijume, kao i
hostove različitih brzina prenosa podataka.
• Kod mreža sa komutacijom paketa, čak i u uslovima intenzivnog saobraćaja, mreža prihvata nove pakete,
mada je vreme prenosa paketa kroz mrežu duže. Sa povećanjem opterećenja mreže, u baferima rutera se
gomilaju paketi koji čekaju da budu preneti dalje. Komunikacije između hostova nije prekinuta, mada su
performanse niže. Međutim, baferski prostor u ruterima je ograničene veličine i može se desiti da pri veoma
velikom opterećenju neki paketi budu izgubljeni zato što je u pojedinim ruterima baferski prostor iscrpljen.
• Princip komutacije paketa omogućava uvođenje prioriteta. Ruter, umesto da se prilikom slanja paketa na
izlaznu liniju drži striktnog redosleda paketa u redu čekanja, može dati prednost paketima sa visokim
prioritetom. Paket visokog prioriteta biće izabran za slanje bez obzira na njegovu poziciju u redu čekanja.
Na taj način, paketi višeg prioriteta prenosiće se brže kroz mrežu nego paketi niskog prioriteta.
Međutim, komutacija paketa ispoljava i izvesne nedostatke:
• Prolazak paketa kroz ruter unosi dodatno kašnjenje u prenosu. Obzirom da se paket baferuje u ruteru, pre
nego što se prosledi dalje, ovo kašnjenje, u minimalnom iznosu, jednako je količniku dužine paketa i brzine
prenosa preko dolazne linije - vreme koje je potrebno da se paket prenese iz jednog u drugi čvor. Na ovo
vreme treba dodati vreme procesiranja paketa i vreme čekanja paketa u redu čekanja, koje je promenljivo i
uslovljeno trenutnim uslovima u mreži.
• Ukupno vreme prenosa paketa jednako je zbiru kašnjenja paketa kroz rutere na putanji koju paket prolazi.
Obzirom da se paketi mogu razlikovati po dužini, mogu biti prenešeni različitim putanjama i mogu biti
izloženi promenljivim kašnjenjenima u ruterima, sveukupno vreme prenosa paketa od datog para izvor-
odredište, može značajno da varira od paketa do paketa. Ova pojava se naziva treperenje ili džiter (jitter) i
može biti nepoželjna kod izvesnih aplikacija, kao što su aplikacije koje zahtevaju prenos podataka u
relanom vremenu (telefonija, video, audio, ..).
• Da bi se omogućilo usmeravanje paketa kroz mrežu, svaki paket osim podataka mora sadržati i dodatne
kontrolne (režijske) informacije (npr. adresa odredišta, redni broj paketa u poruci i sl.). Za prenos
kontrolnih informacija troši se deo komunikacionog kapaciteta prenosnih linja, čime se smanjuje raspoloživ
kapacitet za prenos korisničkih podataka.

7
1.3 TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol - Protokol za kontrolu prenosa/Internet protokol ) je
referentni model koji se koristi na Internetu. Razvijen je pre OSI modela, tako da se slojevi ova dva modela ne
poklapaju u potpunosti. TCP/IP model čini pet slojeva: fizički, sloj veze, mrežni, transportni i aplikacioni.
TCP/IP se samo sporadično bavi najnižim slojevima (fizičkim i slojem veze). Zajedno, ova dva sloja se tretiraju
kao ˝host-mreža ˝sloj. TCP/IP ne nameće neke posebne zahteve koji se tiču ovih slojeva (pretpostavlja se da
mreža poseduje protokole koji pokrivaju funkcije tih slojeva), a naglasak stavlja na sloj mreže, transportni i
aplikacioni sloj. Mrežni i transportni sloj odgovaraju slojevima 3 i 4 OSI modela. Međutim, kod TCP/IP na
transportni sloj direktno se nastavlja aplikacioni sloj, koji obuhvata funkcionalnost tri vršna sloja OSI modela
(Sl. 1-4).

Sl. 1-4 Odnos između OSI i TCP/IP modela.

TCP/IP je hijerarhijski skup protokola sačinjen od interaktivnih, ali ne obavezno i međusobno nezavisnih
modula od kojih svaki ostvaruje neku specifičnu funkciju. Za razliku od OSI modela koji definiše koje funkcije
pripadaju kom sloju, slojevi TCP/IP modela sadrže relativno nezavisne protokole koji se mogu kombinovati
zavisno od potreba sistema. Pojam hijerarhijski znači da je svaki protokol višeg nivoa podržan od strane jednog
ili više protokola nižeg nivoa. Na Sl. 1-5 je prikazana struktura TCP/IP modela sa protokolima razvrstanim u
slojeve koji su preklopljeni sa odgovarajućim slojevima OSI modela.

Sl. 1-5 TCP/IP i OSI model.

Mrežni (Internet) sloj
Glavni protokol na mrežnom nivou je IP (Internet Protocol). Pored IP, sloj mreže sadrži još nekoliko pomoćnih
protokola (ARP, RARP, ICMP, IGMP i dr.). Internet sloj je odgovoran za isporuku paketa od hosta do hosta na
Internetu. Glavna briga ovog sloja je rutiranje paketa i izbegavanje zagušenja (odgovara mrežnom sloju OSI
modela).
Transportni sloj
Na transportnom nivou, TCP/IP definiše dva protokola: TCP i UDP (User Datagram Protocol). TCP je
transportni protokol konekcionog tipa koji omogućava uspostavljanje pouzdanog toka bajtova između dve
udaljene aplikacije. TCP obavlja segmentaciju toka bajtova na poruke koje prosleđuje internet sloju. Na strani
odredišta, TCP rekonstruiše tok bajtova i prosleđuje ga aplikaciji. Uz to, TCP se bavi kontrolom protoka kako bi
sprečio da brzi predajnik pretrpa porukama sporog prijemnika koje on ne može da obradi.

8
UDP je jednostavan, nepouzdan, beskonekcioni transportni protokol za aplikacije koje ne zahtevaju strogu
kontrolu grešaka i redosleda pristizanja paketa. Radi se o aplikacijama kao što su one koje prenose audio i
video, kod kojih je brza isporuka paketa važnija od precizne isporuke.
Aplikacioni sloj
TCP/IP model ne predviđa prezentacioni i sloj sesije, već su funkcije ovih slojeva pripojene aplikacionom sloju.
To znači da aplikacije moraju samostalno da realizuju funkcije koje se odnose na sesiju i prezentaciju podataka,
ako su im takve funkcije uopšte potrebne. Aplikacioni sloj sadrži veći broj protokola visokog nivoa. Prvobitno
su razvijeni protokoli: TELNET (virtuelni terminal), FTP (File Transfer Protocol) - protokol za prenos fajlova i
SMTP (Simple Mail Transfer Protocol) - protokol za prenos elektronske pošte. Vremenom, aplikacioni sloj je
proširen brojnim protokolima, od kojih su najznačajniji: DNS (Domain Name System) - za preslikavanje imena
hostova u njihove mrežne adrese i HTTP - za pribavljanje strana na Web-u.

1.4 Adresiranje
TCP/IP protokoli koriste tri nivoa adresiranja: fizičke adrese, logičke ili mrežne (IP) adrese i adrese portova.
Svaki tip adresa vezan je za jedan sloj TCP/IP arhitekture (Sl. 1-6).

Aplikacioni
Procesi
sloj

Transportni Adrese
TCP UDP
sloj portova

Mrežni
Logičke
(Internet) IP i drugi protokoli
adrese
sloj

Sloj
veze
Fizičke mreže i ˝host- Fizičke
mreža˝ protokoli adrese
Fizički
sloj

Sl. 1-6 Odnos između slojeva i adresa kod TCP/IP.

Fizička adresa
Fizička adrese je adresa čvora na LAN-u. Ovo je adresa najnižeg nivoa koja se koristi na nivou sloja veze za
identifikaciju prijemnog i predajnog čvora povezanih na zajednički prenosni medijum (ili link). Važnost fizičke
adrese je ograničena na lokalnu mrežu (LAN). Veličina i format fizičke adrese zavisi od tipa lokalne mreže. Na
primer, kod Etherneta se koriste 6-bajtne (48-bitne) fizičke adrese koje su fabrički utisnute u karticu mrežnog
adaptera. Sa druge strane, kod mreže tipa LocalTalk adrese su 1-bajtne i dinamičke - adresa čvora se menja uvek
kada se čvor uključi.
Fizičke adrese se prenose u zaglavlju okvira sloja veze i identifikuju primaoca ili primaoce okvira. Adrese mogu
biti: unicast ili jednoznačne (samo jedan primalac okvira), multicast ili grupne (okvir je namenjen grupi
čvorova) i broadcast ili opšte (okvir je namenjen svim sistemima koji su priključeni na lokalnu mrežu). Neke
mreže podržavaju sva tri tipa adresa, kao što je to slučaj sa Ethernet-om. Pojedine mreže ne podržavaju grupne
ili opšte fizičke adrese. Kod takvih mreža, ako okvir mora biti poslat grupi primaoca ili svim sistemima u mreži,
grupne i opšte adrese se simuliraju pomoću jednoznačnih adresa (umesto jednog šalje se više okvira, jedan ka
svakom željenom primaocu).
Pr. 1-1. Fizičke adrese
Na Sl. 1-7, čvor sa fizičkom adresom 10 šalje okvir čvoru sa fizičkom adresom 69. Dva čvora su povezana
linkom. Na nivou sloja veze, u zaglavlju okvira sadržane su fizičke adrese. Osim adresa, zaglavlje sadži i neke
druge informacije. Završni zapis obično sadrži dodatne bitove za detekciju grešaka.

9
 Sl. 1-7 Fizičke adrese.

Logičke adrese
Logičke adrese se koriste kao adrese hostova i rutera na Internetu. To su univerzalne, globalne adrese koje ne
zavise od tipa fizičke mreže na koju je sistem priključen. Fizičke adrese nisu adekvatne za među-mrežnu
komunikaciju, obzirom na različite formate fizičkih adresa koje se koriste kod različitih tipova mreža.
Neophodna je univerzalna šema adresiranja koja će obezbediti jedinstvenu identifikaciju svakog hosta ili rutera,
nezavisno od njegovog lokalnog mrežnog okruženja. Logičke adrese na Internetu su 32-bitne. Ne postoje dva
javno vidljiva i dostupna hosta na Internetu sa istom IP adresom.
Logičke adrese, kao i fizičke, mogu biti: jednoznačne, grupne ili opšte. Međutim, u pogledu opštih adrese
postoje izvesna ograničenja, o čemu će biti govora u sekciji 2.1.1.
Pr. 1-2 IP adrese
U primeru sa Sl. 1-8, čvor sa logičkom adresom A i fizičkom adresom 10 lociran na jednom LAN-u šalje
podatke čvoru sa logičkom adresom P i fizičkom adresom 95 lociranom u nekom drugom LAN-u. S obzirom da
izvorni i odredišni čvor nisu priključeni na istu mrežu, fizičke adrese nisu dovoljne. Neophodne su univerzalne
adrese, koje važe i izvan granica LAN-a. Ovu osobinu imaju logičke (ili mrežne) adrese. Paket na nivou sloja
mreže sadrži logičke adrese izvora i krajnjeg odredišta (adrese A i P na Sl. 1-8) koje ostaju neizmenjene duž cele
putanje paketa. Za razliku od logičkih, fizičke adrese se menjaju kako paket prelazi iz jednu u drugu mrežu.
Kvadrati označeni slovom R predstavljaju rutere - uređaje za međumrežno povezivanje.

Sl. 1-8 IP adrese.

Adrese portova
IP adrese i fizičke adrese su neophodne kako bi se podaci preneli od izvornog do odredišnog hosta. Međutim,
isporuka podataka odredišnom hostu, nije krajnji cilj komunikacije preko Interneta. Komunikacioni sistem koji
omogućava prenos podataka sa jednog na neki drugi računar nije kompletan. Današnji računari mogu da
izvršavaju više procesa u isto vreme. Krajnji cilj komunikacije preko Interneta je komunikacija između
udaljenih procesa. Iz tog razloga neophodan je metod za identifikaciju procesa. Kod TCP/IP arhitekture, ova

10
identifikacija se naziva adresom porta. Adrese porta su 16-bitne. Svi procesi koji se izvršavaju na istom hostu
imaju različite adrese portova.
Pr. 1-3 Adrese portova
Na Sl. 1-9 je ilustrovana komunikacija na transportnom sloju. Podaci koji dolaze iz višeg sloja u transportni
potiču od procesa sa adresom porta j i namenjeni su udaljenom procesu sa adresom porta k. Pošto je veličina
poruke veća od one koju podržava sloj mreže, podaci se u transportnom sloju dele na dva paketa. Paketi
zadržavaju adrese portova i dopunjeni logičkim adresama izvornog i odredišnog računara prosleđuju se sloju
mreže. Na prijemnoj strani, dva paketa se isporučuju sloju mreži, koji uklanja svoje zaglavlje i prosleđuje ih
transportnom sloju gde se oni objedinjuju u jedinstvenu poruku koja se konačno isporučuje odredišnom procesu
sa adresom servisa k.

Sl. 1-9 Adrese portova.

1.5 Internet standardi

Internet standard je sveobuhvatno testirana specifikacija namenjena onima koji rade sa Internetom (softverskim
kompanijama koje realizuju mrežni sofver ili mrežne aplikacije, kao i hardverskim kompanijama koje proizvode
mrežne uređaje, kao što su ruteri). Internet stadardi su otvoreni, tj. javno dostupni, s razlogom da doprinesu
popularizaciji, bržem širenju Interneta i bržem usvajanju novih tehnologija. Internet standardi se moraju
poštovati kako bi se obezbedila međuoperativnost sistema priključenih Internet i aplikacija koje rade na
Internetu. Specifikacija novog protokla ili aplikacije postaje Internet standard tek nakon stroge procedure
usvajanja koju sprovode nadležna regulativna tela Interneta, a u koju su uključene brojne istraživačke i razvojne
grupe, forumi i organizacije. Takva jedan specifikacija zapičinje svoj životni vek kao Internet nacrt (Internet
draft). To je radni dokument bez zvaničnog statusa i sa ograničenim važnošću od šest meseci. Nakon preporuke
od strane nadležnog tela, nacrt se publikuje kao dokument koji se zove RFC (Request for comments). RFC
prolazi kroz nekoliko nivoa zrelosti u toku svog životnog veka.
Nivoi zrelosti
RFC, tokom svog životnog veka, se svrstava u jedan od šest nivoa zrelosti: predlog standarda, nacrt standarda,
Internet standard, istorijski, eksperimentalni i informativni ( Sl. 1-10).
Predlog standarda je stabilna i razumljiva specifikacija od dovoljno velikog značaja za Internet zajednicu. Na
ovom nivou, specifikacija se testira i implementira od strane nekoliko različitih grupa. Nakon barem dve
uspešne realizacije i potvrde u realnim uslovima, predlog standarda evoluira u nacrt standarda. Nacrt standarda
je otvoren za komentare, primedbe i sugestije svih zainteresovanih strana. Nacrt stadarda može da doživi
izvesne modifikacije u slučaju da su uočeni problemi u njegovoj implementaciji ili korišćenju, pre nego što se
prevede na nivo Internet stadarda. Istorijski RFC-ovi su značajni iz istorijskih razloga. Radi se o RFC-ovima
koji su ili nasleđeni novim specifikacijama ili nikada nisu dostigli nivo standarda. Eksperimentalni RFC-ovi
opisuju esperimente koji se odnose na analizu rada Interneta i nisu namenjeni implementaciji. Informativi RFC-
ovi sadrže opšte (istorijske, edukativne) informacije o Internetu.

11
 Sl. 1-10 Nivoi zrelosti RFC-a.
Nivoi obaveznosti
Svaki RFC se klasifikuje u jedan od sledećih pet nivoa obaveznosti: obavezan, preporučljiv, izborni, ograničene
upotrebe i nepreporučljiv.
Obavezan RFC mora biti implementiran u svim sistemima na Internetu. Na primer, IP i ICMP su obavezni
protokoli. Drugim rečima, sistem ne može raditi na Internetu ukoliko ne poseduje podršku za ove protokole.
Preporučljiv RFC nije obavezan, ali se njegova implementacija preporučuje zbog značajne upotrebne vrednosti.
Na primer, FTP i TELNET su preporučljivi protokoli. Izborni RFC nije ni obavezan ni preporučljiv, ali ako
bude realizovan u nekom sistemu doprineće njegovom boljem radu i boljim performansama. RFC ograničene
upotrebe, trebalo bi da se koristi samo u specifičnim situacijama, dok je nepreporučljiv RFC nepodesan za opštu
upotrebu (obično, u ovu kategoriju spadaju zastareli i istorijski RFC-ovi).

12
2 Internet sloj
U ovom poglavlju bavićemo se Internet slojem TCP/IP arhitekture. Internet je heterogena globalna mreža
sačinjena od ogroman broj nezavisnih mreža, različitih tipova, međusobno povezanih ruterima. Na nivou
pojedinačnih mreža koriste se različiti prenosni medijumi i različiti komunikacioni protokoli fizičkog i sloja
veze. Zadatak Internet sloja je da unificira sve te razlike i omogući komunikaciju između krajnih sistema, bilo
da su oni priključeni na istu ili različite mreže. Problemi koji se rešavaju na Internet sloju u su vezi sa: logičkim
adresiranjem, rutiranjem datagrama, fragmentacijom datagrama i u izvesnoj meri sa kontrolom zagušenja i
obezbeđivanjem zahtevanog nivoa kvaliteta servisa. Za jedinstvenu identifikaciju sistema priključenih na
Internet (hostova i rutera) koriste se tzv. Internet (IP) adrese. Na Internetu se koristi paketski prenos. Na strani
izvora informacija deli na manje jedinice, tzv. datagrame koji se nezavisno prenose od rutera do rutera sve do
krajnjeg odredišta. Rutiranjem datagrama od izvornog do odredišnog hosta bavi se IP protokol. IP se
prevashodno izvršava u ruterima. Funkcija rutera je da svaki primljeni datagram, a shodno njegovoj odredišnoj
IP adresi, usmeri dalje ka sledećem ruteru ili odredišnom hostu. U izvesnim situacijama, ruter mora da podeli
datagram na više manjih datagrama, tzv. fragmenata. Fragmenti nastavljaju put kao nezavisne jedinice, da bi se
na odredišnom hostu objedinili u prvobitni datagram. Pravila za fragmentaciju i defragmentaciju datagrama su,
takođe, definisana IP protokolom. Pored IP protokola, Internet sloj TCP/IP steka sadrži još nekoliko pomoćnih
protokola manje složenosti. Razmotrićemo dva takva protokola: ARP i ICMP. IP koristi ARP protokol za
preslikavanje IP adresa na fizičke adrese koje važe u konkretnoj fizičkoj mreži. ICMP protokol obezbeđuje
povratne informacije izvornom hostu o eventualnim problemima nastalim u rutiranju datagrama.

2.1 IP adresiranje
Mogućnost globalne komunikacije između svih povezanih uređaja predstavlja jednu od glavnih karakteristika
Interneta. Pretpostavka globalne komunikacije je postojanje univerzalne šeme adresiranja koja se koristi za
jedinstvenu identifikaciju svakog priključenog uređaja. (Identičan zahtev postoji i u telefoniji, gde svaki
pretplatnik poseduje jedinstveni telefonski broj – u kombinaciji sa pozivnim brojem države i pozivnim brojem
grada). Identifikator koji se koristi na IP sloju TCP/IP protokol steka naziva se IP adresom.
Internet ili IP adresa je 32-bitna (ili 4-bajtna) adresa (identifikator) koja na jedinstven i univerzalan način
definiše vezu hosta ili rutera na Internet. IP adrese su jedinstvene u smislu da svaka adresa definiše jednu i samo
jednu vezu (priključak) na Internet. Dva uređaja na Internetu nikada ne mogu imati istu IP adresu. Međutim, ako
uređaj (najčešće ruter) poseduje dve Internet veze, preko dve različite mreže, onda će on imati i dve IP adrese.
IP adrese su univerzalne u smislu da svaki host koji želi da se poveže na Internet mora poštovati opšte usvojeni
sistem IP adresiranja.
Adresni prostor
Protokol kao što je IP, koji se oslanja na adrese, pokriva određeni adresni prostor. Adresni prostor čine sve
adrese koje protokol može koristiti. Ako protokol predviđa N bita za predstavljanje adresa, tada je veličina
adresnog prostora 2 N. IP protokol u verziji IPv4 koristi 32-bitne adrese, što znači da je njegov adresni prostor
veličine 232, odnosno 4.294.967.296. To znači da kada ne bi postojala dodatna ograničenja, na Internet bi moglo
da se priključi više od 4 milijarde uređaja. Nažalost, stvaran broj raspoloživih adresa je mnogo manji.
Notacija
Za zapisivanje Internet adresa obično se koristi tačkasta decimalna notacija. U ovom formatu, svaki od četiri
bajta adrese se zapisuje kao decimalni broj, od 0 do 255. Najniža IP adresa je 0.0.0.0 (sve 0), a najviša
255.255.255.255 (sve jedinice). Sl. 2-1 prikazuje bit oblik i decimalni format jedne konkretne IP adrese.

Sl. 2-1 Tačkasta decimalna notacija.

2.1.1 Klasno IP adresiranje

Kada je pre nekoliko decenija uvedeno IP adresiranje korišćen je koncept klasa, odnosno šema klasnog IP
adresiranja. Sredinom 90’-tih godina prošlog veka, uvedena je nova šema, tzv. besklasno adresiranje, koja je
vremenom gotovo u potpunosti potisnula prvobitnu šemu. Bez obzira na to, postoje dva razloga za izučavanje

13
klasnog IP adresiranja: 1) deo Interneta još uvek koristi klasno adresiranje; 2) poznavanje koncepta klasnog
adresiranja je neophodan za razumevanje besklasnog adresiranja.
Kod klasnog IP adresiranja, prostor IP adresa je podeljen na pet klasa: A, B, C, D i E. Svaka klasa zauzima
jedan kontinualni deo adresnog prostora (Sl. 2-2). Kao što možemo videti na Sl. 2-2, klasa A pokriva čak
polovinu adresnog prostora, klasa B 1/4, klasa C 1/8, a klase D i E po jednu 1/16. Broj adresa u svakoj klasi dat
je u tabeli sa Sl. 2-2.
Adresni prostor Klasa Broj adresa Procenat
A 231 = 2,147,483,648 50%
A
B 230 = 1,073,741,824 25%
C 229 = 536,870,912 12.5%
B C D E D 228 = 268,435,456 6.25%
E 228 = 268,435,456 6.25%
Sl. 2-2 Zauzeće adresnog prostora.
Određivanje klase
Svaka IP adresa pripada jednoj klasi. Pripadnost IP adrese klasi može se odrediti na osnovu binarnog ili
decimalnog oblika adrese. Ako je adresa data u binarnom obliku, tada prvih nekoliko bita ukazuju na klasu kojoj
adresa pripada ( Sl. 2-3(a)). Adresa pripada klasi A ako njen krajnji levi bit ima vrednost 0. Pripadnost klasi B se
prepoznaje po početnoj sekvenci 10, klasi C po sekvenci 110, klasi D po 1110 i klasi E po četiri početne 1-ce.
(Napomenimo da klasama A i E pripadaju i neke specijalne adrese koje se ne uklapaju u klasifikaciju. O njima
nešto kasnije.)
Da bi smo odredili klasu IP adrese date u obliku tačkaste-decimalne notacije, potrebno je pogledati samo prvi
(krajnji levi) bajt (broj) adrese. Svaka klasa ima određeni opseg ovih brojeva (Sl. 2-3(b)). Na primer, ako je prvi
bajt između 0 i 127, klasa adrese je A. Ako je prvi bajt između 128 i 191, klasa adrese je B, i td.

(a) (b)
Sl. 2-3 Određivanje klase: (a) u binarnoj notaciji; (b) u decimalnoj notociji.
Netid i Hostid
IP adrese u klasama A, B i C podeljene su na dva dela: netid i hostid. Ovi delovi su promenljive dužine,
zavisno od klase kojoj adresa pripada ( Sl. 2-4). Netid identifikuje mrežu na Internetu, a hostid host u mreži. U
klasi A, jedan bajt definiše netid, a tri bajta hostid; u klasi B, po dva bajta se koriste za netid i hostid; u klasi C,
tri bajta definišu netid, a jedan hostid. Adrese iz klase D se koriste kao multicat adrese. U ovoj klasi ne postoji
podela na netid i hostid. Adrese iz klase E su rezervisane za neke buduće primene.

Sl. 2-4 Netid i hostid

14
Klase i blokovi
Jedan problem klasnog adresiranja je taj da je svaka klasa podeljena na fiksni broj blokova fiksne veličine.
Razmotrimo detaljnije svaku od klasa.
Klasa A
Klasa A je podeljena na 128 blokova, gde svaki blok ima različiti netid. Prvi blok pokriva adrese od 0.0.0.0 do
0.255.255.255 (netid 0). Drugi blok pokriva adrese 1.0.0.0 do 1.255.255.255 (netid 1). Poslednji blok pokriva
adrese 127.0.0.0 do 127.255.255.255 (netid 127). Uočimo da sve adrese u bloku imaju isti prvi bajt (netid), a
razlikuju se po vrednostima preostala tri bajta (hostid).
Prvi i poslednji blok u klasi A rezervisani su za posebne namene (kao što ćemo uskoro videti). Dodatno, jedan
blok (netid 10) se koristi za privatne adrese (za izolovane mreže koje nisu povezane na Internet). Preostalih 125
blokova su raspoloživi za dodelu zainteresovanim organizacijama. To znači da je ukupan broj organizacija koje
mogu posedovati adresu iz klase A samo 125. Međutim, svaki blok u klasi A sadrži čak 16,777,216 adresa !
Organizacija mora biti veoma velika da bi iskoristila toliki broj adresa.
Na Sl. 2-5 je prikazano kako organizacija kojoj je dodeljen blok sa netid 73 koristi svoje adrese. Prva adresa iz
bloka (73.0.0.0) se koristi za identifikaciju same organizacije na Internetu. Ova adresa se zove mrežna adresa i
definiše mrežu organizacije, a ne neki pojedinačni host. Organizaciji nije dozvoljeno da koristi poslednju adresu
bloka (73.255.255.255), jer ova adresa imam specijalnu namenu. Preostale adrese iz bloka, organizacija može
koristiti za svoje hostove i rutere.
Klasa A je namenjena velikim organizacijama, sa velikim brojem hostova i rutera, ali ogroman broj adresa u
svakom bloku je verovatno veći od potreba i najvećih organizacija. Zbog toga mnoge adrese iz ove klase ostaju
neiskorišćene.
Klasa A

73 je zajedničko u svim adresama Netid 0

Specijalan 0.0.0.0
blok
73.0.0.1
0.255.255.255
73.0.0.0

73.0.0.2

Netid 73
73.0.0.0
73.8.17.2
73.255.255.255

73.255.255.254
Netid 127
Specijalan 127.0.0.0
blok
73.255.255.255 (specijana adresa) 127.255.255.255

128 blokova; 16.777.216

adresa u svakom bloku

Sl. 2-5 Blokovi u klasi A.

Klasa B
Klasa B je podeljena na 16,384 bloka, pri čemu svaki blok ima isto netid. Šesnaest blokova su rezervisani za
privatne adrese, dok su preostalih 16,368 raspoloživi za dodelu organizacijama. Prvi blok pokriva adrese od
128.0.0.0 do 128.0.255.255 (netid 128.0). Poslednji blok pokriva adrese od 191.0.0.0 do 191.0.255.255 (netid
128.0). Uočimo da sve adrese iz istog bloka imaju ista prva dva bajta (hostid), a da se razlikuju po vrednosti
druga dva bajta (hostid). Na Sl. 2-6 je prikazano kako organizacija kojoj je dodeljen blok sa netid 180.0 može
koristiti svoje adrese. Kao i u klasi A, prva adresa iz bloka je mrežna adresa, a poslednja ima posebnu namenu.
Preostale adrese organizacija može koristiti za svoje hostove i rutere.
Ukupan broj organizacija kojima se može dodeliti blok iz klase C iznosi 16,368. Me đutim, pošto svaki blok iz
ove klase sadrži 65,536 hostova, organizacija mora biti dovoljno velika da iskoristi sve ove adrese. Iz tog
razloga, kao i kod klase A, veliki broj adresa iz klase B, je neiskorišćen.

15
 Klasa B

180.8 je zajedničko u svim adresama Netid 128.0

128.0.0.0
180.8.0.1
128.0.255.255
180.8.0.0

180.8.0.2

Netid 180.8
180.8.0.0
180.8.17.9
180.8.255.255

180.8.255.254
Netid 191.255
191.255.0.0

180.8.255.255 (specijana adresa) 191.255.255.255

16,384 blokova; 65,536 adresa

u svakom bloku

Sl. 2-6 Blokovi u klasi B.

Klasa C
Klasa C je podeljena na 2,097,152 bloka, pri čemu svaki blok ima isto netid. 256 blokova su rezervisani za
privatne adrese, dok su preostalih 2,096,896 predviđeni za dodelu organizacijama. Prvi blok obuhvata adrese od
192.0.0.0 do 192.0.0.255. (netid 192.0.0). Poslednji blok obuhvata adrese od 223.255.255.0 do 223.255.255.255
(netid 223.255.255). Uočimo da su prva tri bajta (netid) svih adrese iz istog blokova identična, dok četvrti bajt
može imati bilo koju vrednost (hostid). Na Sl. 2-7 je prikazano kako organizacija kojoj je dodeljen blok sa netid
200.11.8 može koristiti svoje adrese. Kao i kod klasa A i B, prva adresa iz svakog bloka je mrežna adresa, a
poslednja ima posebnu namenu.
Ukupan broj organizacija koje mogu posedovati blok iz klase C je 2,096,896. Međutim, pošto svaki blok u ovoj
klasi sadrži 256 adresa, ovu klasu obično koriste organizacije sa malim brojem hostova i rutera. (Zbog
ograničenog broja adresa u bloku, mali broj organizacija se odlučuje da uzme blok iz klase C.)

Sl. 2-7 Blokovi klase C.

Klasa D
U klasi D postoji samo jedan blok adresa. Klasa D se koristi za multicast (poruka se ne šalje samo na jedno, već
na više odredišta). Svaka adresa iz ove klase se koristi da definiše jednu grupu hostova na Internetu. Kada se
grupi dodeli adresa iz klase D, svi hostovi, članovi ove grupe, pored normalne (unicast) imaće i grupnu
(multicast) adresu.

16
Klasa E
U klasi E postoji samo jedan blok adresa, koje su rezervisane za neke buduće namene.
Mrežne adrese
Mrežne adrese igraju bitnu ulogu u klasnom IP adresiranju. Mrežna adresa poseduje sledeće osobine:
• Mrežna adresa je prva adresa u bloku.
• Mrežna adresa definiše mrežu (a ne host). (Ruteri usmeravaju pakete shodno mrežnoj adresi)
• Za datu mrežnu adresu, u mogućnosti smo da odredimo klasu adrese, blok i opseg adresa u bloku.
Pr. 2-1. Za mrežnu adresu 132.21.0.0 odrediti klasu, blok i opseg adresa.
Data adresa pripada klasu B, zato što je prvi bajt iz opsega 128 - 191. Blok ima netid 132.21. Opseg adresa je od
132.21.0.0 do 132.21.255.255.
Treba uočiti da kod klasnog adresiranja mrežna adresa pruža potpune informacije o mreži. Za datu mrežnu
adresu, u mogućnosti smo da odredimo broj adresa u odgovarajućem bloku. To proističe iz činjenice da je broj
adresa u svakom bloku fiksiran klasnom šemom adresiranja.
Maska
U prethodnoj sekciji smo videli kako se za datu mrežnu adresu može odrediti opseg adresa u odgovarajućem
bloku. Postavlja se pitanje da li moguća i inverzna operacija: kako na osnovu date IP adrese odrediti mrežnu
adresu (tj. prvu adresu u odgovarajućem bloku). Ova operacija je važna prilikom rutiranja paketa. Da bi ruter
usmerio paket u korektnu mrežu, on mora iz odredišne IP adrese (sadržane u zaglavlju datagrama) da izvuče
adresu mreže.
Jedan način kako se može naći mrežna adresa jeste da se najpre odrede klasa i netid date IP adrese, a da se zatim
hostid postavi na nulu. Na primer, neka je data adresa 134.45.78.2. Adresa pripada klasi B (prvi bajt je iz opsega
128 - 191) u kojoj netid zauzima 2 bajta. Dakle netid je 134.45, a tražena mrežna adresa 134.45.0.0.
Opisani način je moguć samo ako posmatrana mreža nije podeljena na podmreže. Procedura za određivanje
mrežne adrese na osnovu date IP adrese, koja se može uopštiti i na slučaj kada podmreže postoje, koristi tzv.
masku.
Maska je 32-bitni broj, koji AND-ovan sa bilo kojom adresom iz bloka daje mrežnu adresu ( Sl. 2-8). AND
(logička I) operacija se primenjuje na svaki par bitova maske i adrese. Drugim rečima, bitovi adrese koji
odgovaraju 1-cama iz maske zadržavaju svoju vrednost (ako su 1 ostaju 1, ako su 0 ostaju 0), a bitovi koji
odgovaraju 0-ma iz maske menjaju se na 0.

Sl. 2-8 Koncept maskiranja.

Podrazumevane maske
Kod klasnog adresiranja postoje tri maske, tzv. podrazumevane maske, jedna za svaku klasu (T. 2-1). Za klasu
A maska ima osam 1-ca i dvadesetčetiri 0; maska za klasu B ima šesnaest 1-ca i šesnaest 0; maska za klasu C
ima dvadesetčetiri 1-ca i osam 0. Jedinice u maskama odgovaraj netid, a nule hostid sekciji u svakoj klasi.
T. 2-1 Podrazumevane maske
Klasa Maska (binarni zapis) Maska (decimalna-tačkasta notacija)
A 11111111 00000000 00000000 00000000 255.0.0.0
B 11111111 11111111 00000000 00000000 255.255.0.0
C 11111111 11111111 11111111 00000000 255.255.255.0

Pr. 2-2 Za IP adresu 23.56.7.91 odrediti početnu adresu bloka (tj. mrežnu adresu)
Data adresa pripada klasi A, što znači da je podrazumevana maska oblika 255.0.0.0. Pošto u masci prvi bajt ima
vrednost 255 (sve jedinice), prvi bajt adrese ostaje neizmenjen, dok preostala tri postaju 0. Dakle, tražena
mrežna adresa je 23.0.0.0.

17
CIDR notacija
Iako kod klasnog adresiranja svaka adresa ima podrazumevanu (jednoznačnu) masku, ponekada je uobičajeno (a
i kompatabilno sa klasnim adresiranjem) da se podrazumevana maska eksplicitno naglasi prilikom zapisivanja
adrese. Za ovu namenu koristi se CIDR (izgovara se ˝cider˝) notacija. U ovoj notaciji, broj 1-ca u maski se
zapisuje na kraju adrese posle kose crte. Na primer, adresa 18.46.74.10, koja je iz klase A sa podrazumevanom
maskom 255.0.0.0, se zapisuje kao 18.46.74.10/8, da bi se naglasilo da u maski postoji osam 1-ca. Sli čno, adresa
141.24.74.69 se zapisuje kao 141.24.74.69/16 (što pokazuje da adresa pripada klasi B i da maska ima šesnaest 1-
ca.
Problem iscrpljivanja IP adresa
Zbog brzog rasta Interneta, kao i zbog nedostataka samog klasnog adresiranja, raspoložive IP adresu su gotovo
iscrpljene. Uprkos tome, broj uređaja na Internetu je još uvek mnogo manji od 232. Klase A i B su u potpunosti
iskorišćene, dok su blokovi iz klase C previše mali za organizacije srednje veličine. Nešto kasnije, ukazaćemo
na načine kako se problem iscrpljivanja IP adresa može ublažiti.
Uređaji sa više mrežnih adaptera (multihomed uređaji)
IP adresa definiše vezu uređaja na Internet, tj. mesto na Internetu gde se uređaj nalazi. Otuda sledi da uređaj koji
je povezan na više od jedne mreže mora imati i više od jedne IP adrese. Računar koji je povezan na različite
mreže se zove računar sa više mrežnih adaptera i imaće više od jedne adrese, moguće iz različitih klasa. Ruter je
uvek povezan na više od jedne mreže (inače nema gde da usmerava pakete). Shodno tome, ruter uvek ima dve ili
više IP adresa, po jednu za svaki mrežni adapter.
Na Sl. 2-9 su prikazani jedan računar sa više mrežnih adaptera i jedan ruter. Računar je povezan na dve mreže i
shodno tome ima dve IP adresa. Ruter je povezan na tri mreže i zato ima tri IP adrese.

123.50.16.90 141.14.22.9

Mreža Mreža

123.70.9.111 141.14.67.80

205.66.74.6

Mreža

Sl. 2-9 Uređaji sa više mrežnih adaptera.

Pr. 2-3 Jednostavan internet

Na Sl. 2-10 je prikazan deo Interneta koga čine četiri mreže (tri Ethernet i jedan Token Ring LAN). Adrese
mreža napisane su masnim slovima i sadrže netid deo i sve nule u delu hostId. Adrese mreža sa slike su:
129.8.0.0 (klasa B), 124.0.0.0 (klasa A), 220.3.6.0 (klasa C) i 134.18.0.0 (klasa B). Svaki ruter ima posebnu IP
adresu za svaku mrežu na koju je povezan.
134.18.10.88

129.8.0.1 129.8.45.13
222.13.16.41

134.18.68.44

134.18.0.0

129.8.0.0
129.8.14.12
220.3.6.3

220.3.6.0 222.13.16.0
220.3.6.23

222.13.16.40
220.3.6.1
134.18.14.21

x.y.z.w
134.18.8.2
207.42.56.0

ka ostatku Interneta

207.42.56.2

124.100.33.77
124.0.0.0
124.42.5.45 124.4.51.66

Sl. 2-10 Mrežne adrese i adrese hosta.

18
Uočimo da IP adresa definiše mrežnu lokaciju uređaja, a njegov identitet. Drugim rečima, obzirom da IP adresu
čine dva dela (netid i hostid), ona jedino može da definiše vezu uređaja na određenu mrežu. Jedna posledica
ovoga je ta da premeštanje računara iz jedne u neku drugu mrežu podrazumeva i promenu njegove IP adrese.
Specijalne adrese
Pojedini delovi adresnog prostora IP protokola se koriste za specijalne adrese ( T. 2-2).
T. 2-2 Specijalne adrese.
Specijalna adresa Netid Hostid Izvor ili odredište
Mrežna adresa Određena Sve nule -
Direktna broadcast adresa Određena Sve 1-ce Odredište
Ograničena broadcast adresa Sve 1-ce Sve 1-ce Odredište
Ovaj host na ovoj mreži Sve nule Sve nule Izvor
Konkretan host na ovoj mreži Sve nule Određena Odredište
Loopback adresa 127 Bilo koja Odredište
Mrežna adresa
Mrežne adrese su već razmatrane. Mrežna adresa je prva adresa u bloku iz klasa A, B i C.
Direktna opšta adresa
Direktna opšta (ili broadcast) adresa je adresa iz klasa A, B ili C sa definisanim netid i svim 1-cama u delu
hostid. Ovu adresu omogućava broadcast (emitovanje namenjeno svima) datagrama na udaljenoj mreži, bilo gde
na Internetu (ukazuje na sve hostove adresirane mreže). Paket koji kao odredišnu adresu imaju adresu ovog tipa,
prihvatiće svi hostovi (bez obzira na svoju normalnu IP adresu). Međutim, ruteri većine mreža na Internetu
onemogućavaju prolazak ovakvih datagrama u mrežu (iz bezbednosnih razloga). Uočimo da direktna opšta
adresa može biti korišćena samo kao odredišna adresa. Takođe, uočimo da ova specijalna adresa smanjuje za 1
broj raspoloživih IP adresa u svakom bloku iz klasa A, B i C.
Ograničena opšta adresa
Adresa iz klasa A, B ili C, sa svim 1-cama (u netid i u hostid) predstavlja opštu adresu na lokalnoj mreži. Host
koji želi da pošalje istu poruku svim ostalim hostovima u svojoj mreži, može da koristi ovu adresu kao
odredišnu adresu u IP paketu. Ruter sprečava prolazak paketa sa ovim tipom adrese u druge mreže i time
ograničava broadcast samo na mrežu u kojoj je paket emitovan. Uočimo da po klasifikacija, ova adresa pripada
klasi E.
Host na ovoj mreži
IP adresa koja sadrži sve nule tumači se kao ˝host na ovoj mreži˝. Ovu adresu koristi host ako nakon uključena
ne zna svoju IP adresu. Tipično, u takvim slučajevima, host šalje IP paket za zahtevom za dodelu adrese serveru
koji je zadužen za raspodelu IP adresa hostovima na lokalnoj mreži. Pošto host ne zna IP adresu servera, a ni
mrežnu adresu mreže u kojoj je, paket kojeg šalje sadržaće ograničenu broadcast adresu kao odredišnu i adresu
˝host na ovoj mreži˝ kao izvornu. Uočimo da ova adresa može biti korišćena samo kao izvorna adresa. Takođe,
uočimo da adresa ˝host na ovoj mreži˝ pripada klasi A.
Konkretni host na ovoj mreži
IP adresa sa svim nulama u delu netid ukazuje na konkretni host na ovoj mreži. Ovu adresu koristi host da bi
poslao poruku nekom drugom hostu na istoj mreži. Ruter će blokirati ovakav paket i tako ograničiti njegovo
prostiranje samo na lokalnu mrežu. Uočimo da ova adresa može biti korišćena samo kao odredišna adresa.
Takođe, uočimo da adresa tipa ˝Konkretni host na ovoj mreži˝, po klasifikaciji pripada klasi A i da smanjuje broj
blokova u klasi A za 1.
Loopback adresa
IP adrese oblika 127.xx.yy.zz predstavljaju tzv. loopback adrese, koje se koriste za testiranje mrežnog softvera
lokalne mašine. Paketi upućeni na ovu adresu nikada ne napuštaju mašinu, već se vraćaju nazad mrežnom
softveru, koji ih tretira na isti način kao i bilo koji paket primljen sa mreže. Na ovaj način se može testirati
operativnost IP softvera. Takođe, loopback adrese može koristiti klijentski proces (program koji se izvršava)
kada se obraća serverskom procesu na istoj mašini. Loopback adresa se može koristiti samo kao odredišna
adresa; klasifikuje se u klasu A i, praktično, smanjuje broj blokova u ovoj klasi za 1.

19
Privatne adrese
Izvestan broj blokova u klasama A, B i C rezervisan je za privatne mreže ( T. 2-3). Adrese iz ovih blokova nisu
globalno prepoznatljive, a koriste se u izolovanim mrežama (koje nisu povezane na Internet) ili u mrežama kod
kojih se za vezu sa Internetom koristi tehnika prevođenja IP adresa (tzv. NAT, poglavlje 0).
T. 2-3 Adrese za privatne mreže.
Klasa Netid Broj blokova
A 10.0.0 1
B 172.16 – 172.31 16
C 192.168.0 – 192.168.255 256

Individualne, grupne i opšte adrese

Komunikacija na Internetu može se ostvariti korišćenjem individualnih (unicast), grupnih (multicast) i opštih
(broadcast) adresa.
Individualne adrese
Individualne IP adrese se koriste za komunikaciju tipa jedan-na-jedan (tzv. unicast). Izvor šalje paket namenjen
tačno jednom odredištu. Svi sistemi direktno povezani na Internet imaju barem jednu, jedinstvenu individualnu
IP adresu. Individualne IP adrese pripadaju klasama A, B i C. Na Sl. 2-11 je prikazan primer unicast
komunikacije. Izvor (S1) šalje paket koji prolazi kroz rutere i stiže do svog odredišta (D1).

Sl. 2-11 Unicast (jedna-na-jedna) komunikacije.

Grupne adrese
Grupna (multicast) komunikacija je komunikacija tipa jedan-ka-više. Izvor šalje paket kojeg prima više
odredišta. Grupne adrese pripadaju klasi D. Celokupna adresa (svih 32 bita) definiše groupid - identifikator, ili
adresa grupe. Sistem na Internetu može imati jednu ili više grupnih adresa iz klase D (pored jedne ili više
individualnih adresa). Ako sistem (obično host) ima npr. 7 grupnih adresa, to znači da je član 7 multicast grupa.
Uočimo da se adrese iz klase D mogu koristiti samo kao odredišne adrese.
Grupna komunikacija na Internetu može biti lokalna i globalna. Na lokalnom nivou, multicast grupu može činiti
podskup hostova na nekom LAN-u. Na globalnom nivou, grupu mogu formirati hostovi iz različitih mreža. U
oba slučaja, svim hostovima iz iste grupe dodeljuje se ista grupna adresa.
Na Sl. 2-12 je ilustrovan koncept grupne komunikacije. Multicast paket polazi iz izvora S1 i stiže do svih
odredišta koja pripadaju grupi G1. Uočimo da ruteri, po potrebi, mogu da dupliciraju paket i kopije proslede
dalje kroz nekoliko svojih mrežnih adaptera.

Sl. 2-12 Grupna (multicast) komunikacija.

20
Tipične primene grupne komunikacije su:
Pristup distribuiranim bazama podataka. Većina velikih baza podataka su distribuirane. To znači da su
informacije smeštene na više različitih lokacija. Korisnik koji želi da pristupi bazi, ne mora da zna
tačnu lokaciju tražene informacije, već svoj upit može da pošalje na grupnu adresu svih lokacija.
Odgovoriće lokacija koja poseduje traženu informaciju.
Distribucija informacija. U poslovanju, često se javlja potreba da firma šalje cirkularna obaveštenja
svojim korisnicima. Ako se za ovu namenu koristi multicast firma može poslati jednu poruku, koja će
stići do svih zainteresovanih korisnika. Na sličan način, mogu se distribuirati vesti.
Telekonferencije. Osnovna pretpostavka telekonferencije je da svi učesnici dobijaju iste informacije u
isto vreme (˝svako vidi svakog˝). Za ovu namenu se mogu formirati privremene ili trajne multikast
grupe.
Učenje na daljinu. Predavanje jednog profesora može se emitovati specifičnoj grupi studenata.
Višestruki unicast v.s. multicast
Za sve navedene primere primene grupne komunikacije zajedničko je da izvor u isto vreme šalje identičnu
informaciju većem broju zainteresovanih odredišta. Isti efekat se može postići ako izvor umesto jednog
multicast paketa, ka svakom odredištu pošalje jedan individualnih paketa (tzv. višestruki unicast). Na Sl. 2-13 je
ilustrovana razlika između multicast-a i višestrukog unicasta-a. Multicast započinje jednim paketom koji se
umnožava u ruterima. Sve kopije paketa imaju istu (grupnu) odredišnu adresu. Uočimo da se između para rutera
uvek prenosi jedna kopija paketa. Kod višestrukog unicasta-a, izvor šalje više paketa, svaki sa različitom
individualnom odredišnom adresom. Uočimo da se između pojedinih parova rutera prenosi više kopija paketa.
Multicast je efikasniji od višestrukog unicast-a. Uočimo da je za distribuciju informacije iz primera sa Sl. 2-13
potrebno da mreža prenese ukupno 11 paketa, za slučaj multicast-a, u odnosu na 19 paketa za slučaj višestrukog
unicast-a. Takođe, kod višestrukog unicast-a pojedini linkovi (oni koji su bliži izvoru) su više opterećeni od
drugih.

(a) (b)
Sl. 2-13 Multicast v.s. unicast: (a) multicast; (b) unicast.
Opšte adrese
Broadcast (ili emitovanje namenjeno svima) je komunikacija tipa jedan-ka-svima. Internet dozvoljava
broadcast samo na lokalnom nivou. Prethodno su pomenuta dva tipa IP adresa koje se koriste za ovu namenu:
ograničena opšta adresa (sve 1-ce) i direktna opšta adresa (konkretno netid, hostid sve 1-ce). Broadcast na
globalnom nivou nije dozvoljen. To znači da sistem (host ili ruter) ne može da pošalje poruku svim hostovima i
ruterima na Internetu.
Podmrežavanje
Dva nivoa hijerarhije
Kao što već znamo, jedan deo IP adrese identifikuje mrežu (netid), a drugi host (ili ruter) u mreži (hostid). To
znači da u IP adresiranju postoji hijerarhija. Privi nivo hijerarhije je mreža, a drugi host ( Sl. 2-14). Da bi
datagram stigao do nekog hosta na Internetu, on mora najpre da stigne u mrežu kojoj host pripada (korišćenjem

21
netid). Kada datagram stigne u mrežu isporučuje se hostu shodno broju hosta (hostid). Drugim rečima klase A,
B i C IP adresa podržavaju dvonivovsku hijerarhiju.

Sl. 2-14 Mreža sa dva nivoa hijerarhije (bez podmrežavanja).

Međutim, u mnogim slučajevima, dva nivoa hijerarhije nisu dovoljna. Razmotrimo sledeći primer. Niški
univerzitet rezervisao je za svoje potrebe jedan mrežni broj iz klase B. Prva mreža uvedena je na Elektronskom
fakultetu - lokalna mreža tipa Ethernet LAN koji povezuje sve računare ovog fakulteta i ruter za vezu sa
Internetom. Godinu data kasnije, Mašinski fakultet je izrazio želju da dobije pristup Internetu. Kupljen je
repetitor i Ethernet LAN Elektronskog fakulteta proširen je i na Mašinski fakultet koji se nalazi u susednoj
zgradi. Vremenom, i neki drugi fakulteti su na isti način priključivani. Klasa B adresa dozvoljava 65.536
hostova u jednoj mreži, što je više nego dovoljno da zadovolji sve potrebe univerziteta. Međutim, pojavio se
drugi problem, Ethernet LAN nije mogao više da se proširuje jer je ograničenje od najviše 4 repetitora brzo
dostignuto. Očigledno, neophodna je drugačija organizacija mreže.
Pribavljanje nove mrežne adrese nije rešenje, zato što su mrežne adrese danas deficitarne i teško se mogu dobiti
nove, a univerzitet ionako već ima dovoljan broj slobodnih adresa za više od 60.000 hostova. Suština problema
je u dvonivovskoj strukturi IP adresa klase A, B i C koje ne mogu pokrivati više od jedne mreže. Hostovi ne
mogu biti organizovani u grupe - svi su na istom nivou.
Rešenje koje se danas širok koristi u situacijama sličnim opisanoj zasnovano je konceptu formiranja podmreža
ili podmrežavanja (subnetting) koji omogućava da se mreža, za interne potrebe, podeli na više manjih fizičkih
podmreža (subnet), a da se gledano od spolja i dalje vidi i ponaša kao jedna mreža. Tipična savremena
univerzitetska mreža može izgledati kao na Sl. 2-15, sa glavnim ruterom koji je povezan sa ostatkom Interneta i
brojnim Ethernet LAN-ovima (podmrežama) razvedenim po različitim fakultetima. Svaka podmreža ima svoj
ruter za vezu sa glavnim ruterom. Kada datagram sa Interneta stigne u glavni ruter, interpretacija IP adresa se
menja. Ruter je ˝svestan˝ da je mreža fizički podeljena na podmreže i na neki način ˝zna˝ na koju podmrežu da
preusmeri datagram.

Sl. 2-15 Mreža sa uvedenim podmrežama.

Tri nivoa hijerarhije
Uvođenje podmreža kreira treći nivo hijerarhije u IP adresiranju. Sada postoje tri nivou: sajt, podmreža i host
(Sl. 2-16), a rutiranje uključuje tri koraka: isporuka datagrama sajtu, isporuka podmreži i konačno, isporuka
datagrama hostu. (Može se uspostaviti analogija sa šemom telefonskih brojeva. Na primer, u broju 381-18-
529601 postoje tri nivoa hijerarhije: 381 - kod države, 18 - pozivni broj grada i 529601 - broj telefona.)

(a) (b)
Sl. 2-16 Adrese u mreži: (a) bez podmreža; (b) sa podmrežama.

22
Maska podmreže
Ranije smo već uveli pojam podrazumevane maske. Podrazumevana maska se koristi kada je potrebno za datu
IP adresu odrediti prvu adresu u bloku (tj. mrežnu adresu). Međutim, sa podelom na podmreže situacija se
menja - neophodna je maska podmreže. U odnosu na podrazumevanu masku, maska podmreže ima veći broj 1-
ca (Sl. 2-17). Podrazumevana maska definiše mrežnu, a maska podreže adresu podmreže. U osnovi, umesto da se
koristi jedna mrežna adresa, neki bitovi se oduzimaju od hostid i koriste za kreiranje većeg broja podmreža.
255.255.0.0
Podrazumevana
11111111 11111111 00000000 00000000
maska
16
255.255.224.0
Maska
11111111 11111111 111 000 00000000
podmreže
3 13
Sl. 2-17 Poređenje podrazumevane maske i maske podmreže
Za datu IP adresu, adresu podmreže možemo odrediti na isti način kao i adresu mreže - primenom logičke AND
operacije na masku i IP adresu.
Broj podmreža se može odrediti na osnovu broja dodatnih 1-ca u maski. Na primer, u primeru sa Sl. 2-17, broj
dodatnih 1-ca je 3. To znači da je broj podmreža 2 3=8. Broj adresa po podmreži može se odrediti na osnovu broj
0 u maski podmreže. U primeru sa slike, broj 0 je 13, što znači da u svakoj pomreži postoji 2 13=8192
raspoloživih adresa.
Pr. 2-4 Za IP adresu 200.45.34.56 i masku podmreže 255.255.240.0 odrediti adresu podmreže.
Adresa: 200.45.34.56 AND 11001000 00101101 00100010 00111000
Maska podmreže: 255.255.240.0 11111111 11111111 11110000 00000000
Adresa podmreže: 11001000 00101101 00100000 00000000 => 200.45.32.0
Dakle, adresa podmreže je 200.45.34.56.
Specijalne adrese u podmrežavanju
Sa uvedenim podmrežavanjem, dve adrese iz svake podmreže se dodaju listi specijalnih adresa. Prva adresa
svake podmreže (hostid sve nule) je adresa podmreže. Poslednja adresa u svakoj podmreži (sa hostid sve 1-ce)
je rezervisana za ograničeni broadcast unutar podmreže.
CIDR notacija
CIDR notacija se takođe može koristiti i kod podmrežnog adresiranja. Korišćenjem ove notacije, adresa u
podmrežu se može lako zapisati. Na primer, zapis 141.14.92.3/16 prikazuje adresu klase B. Me đutim, zapis
141.14.92.3/18 prikazuje adresu koja pripada podmreži sa maskom 255.255.192.0 (18 1-ca).

2.1.2 Besklasno IP adresiranje

Upotreba klasnog adresiranja stvorila je mnoge probleme. Do sredine 1990’ adrese iz klasa A, B i C su bile
praktično iscrpljen. Najmanji broj adresa dodeljivan organizacijama bio je 256 (klasa C), a najveći 16,777,216
(klasa A). Za organizacije čije u potrebe bile između ovih granica, koristile su se adrese iz klase B ili više
blokova iz klase A. U svakom slučaju, broj dodeljenih adresa mogao je biti samo umnožak od 256. Zbog svega
toga, veliki broj adresa dodeljenih tipičnoj organizaciji ostajao je neiskorišćen, a zbog prirode klasnog
adresiranja nije mogao biti ˝ustupljen˝ nekoj drugoj organizaciji. Takođe, sa širenjem Interneta, adrese su
postale potrebne i malim firmama (čije potrebe ne prelaze više od 16 adresa), pa čak i kućnim korisnicima, koji
dovoljna jedna ili tek nekoliko adresa.
Tokom 1990’ godina, uporedo sa komercijalizacijom Interneta, pojavili su se provajderi Internet usluga (ISP -
Internet Service Provider). ISP je organizacija koja svojim korisnicima (pojedincima, manjim firmama i
organizacijama srednje veličine) obezbeđuje pristup Inernetu i nudi servise kao što je elektronska pošta. ISP
poseduje veći opseg IP adresa, koje deli na grupe adresa (od po 2, 4, 16 i td) i dodeljuje ih korisnicima shodno
njihovim potrebama. ISP je sa svojim korisnicima povezan putem dial-up, ADSL, DSL ili kablovskog modema.
Na taj način, Internet je postepeno evoluirao od globalne mreže velikih mreža u globalnu mrežu ogromnog broja
razuđenih mreža, od veoma velikih do veoma malih.
U cilju pospešivanja ovakvog trenda razvoja i prevazilaženja nedostataka klasnog adresiranja, 1996. godine
uvedeno je besklasno adresiranje koje je u međuvremenu gotovo u potpunosti potisnulo klasično, klasno
adresiranje.

23
Blokovi promenljive dužne
Kod besklasnog adresiranja opsezi adresa koji se dodeljuju organizacijama su blokovi promenljive dužine koji
ne pripadaju klasama. Blokovi mogu imati 2 adrese, 4 adresa, 128 adresa i td. Postoji samo jedno ograni čenje
koje se tiče veličine bloka, o kome će uskoro biti reči, ali u opštem slučaju, veličina blokova se kreće od veoma
malih do veoma velikih.
Kod besklasnog adresiranja, adresni prostor (2 32 adresa) je podeljen na blokove različitih veličina, a organizaciji
se dodeljuje blok veličine koja najbolje odgovara njenim potrebama ( Sl. 2-18).

Sl. 2-18 Blokovi promenljive dužine.

Ograničenja
Besklasno adresiranje rešava mnoge probleme. Međutim, da bi šema mogla biti upotrebljiva (mogućnost lakog
rutiranja datagrama, implementacija u ruterima i sl.) neophodno je prilikom definisanja blokova poštovati
izvesna pravila, koja se odnose na veličinu bloka i prvu adresu u bloku.
Broja adresa u bloku
Veličina bloka mora biti stepen dvojke (2, 4, 8, 16, ...). Na primer, rezidencijalnom korisniku se može dodeliti
blok od 2, nekoj manjoj firmi blok od 16, a nekoj velikoj firmi bloko od 1024 (2 10) adresa.
Prva adresa u bloku
Prva adresa u bloku mora biti deljiva bez ostatka brojem adresa u bloku. Na primer, ako blok sadrži 4 adrese,
prva adresa mora biti deljiva sa 4. Ako blok sadrži 16 adresa, prva adresa mora biti deljiva sa 16.
Ako blok ima 256 (28) ili manje adresa, dovoljno je proveriti samo krajnji desni bajt. Ako blok ima 65336 (2 16)
ili manje adresa, dovoljno je proveriti dva krajnja desna bajta, i td.
Pr. 2-5: Koja od sledećih adresa može biti prva adresa bloka koji sadrži 16 adresa?
a) 205.16.37.32
b) 190.16.42.44
c) 17.17.33.80
d) 123.45.24.52
Samo dve adrese (a i c) zadovoljavaju ograničenje deljivosti sa 16: 205.16.37.32 zbog toga što je 32 deljivo sa
16, a 17.17.33.80 zbog 80 koje je takođe deljivo sa 16.
Pr. 2-6: Koja od sledećih adresa može biti prva adresa bloka koji sadrži 256 adresa?
a) 205.16.37.32
b) 190.16.42.0
c) 17.17.32.0
d) 123.45.24.52
U ovom slučaju, krajnji desni bajt mora biti 0. Kod IP adresa koristi se aritmetika u osnovi 256. Kada je krajnji
desni bajt 0, celokupna adresa je deljiva sa 256. Od ponuđenih, samo dve adrese (b i c) zadovoljavaju ovaj
kriterijum.
Pr. 2-7: Koja od sledećih adresa može biti prva adresa bloka koji sadrži 1024 adresa?
a) 205.16.37.32
b) 190.16.42.0
c) 17.17.32.0
d) 123.45.24.52
U ovom slučaju moramo proveriti dva krajnja desna bajta. Pošto je 1024 = 4 x 256, krajnji desni bajt mora biti
deljiv sa 256, a drugi bajt (s desne strane) deljiv sa 4. Samo jedna adresa (c) zadovoljava ovaj uslov.
Maska
Kod klasnog adresiranja maska je implicitna (podrazumevana). Maska za blok iz klase A je 255.0.0.0 (/8);
maska za blok iz klase B je 255.255.0.0 (/16), a maska za blok iz klase C 255.255.255.0 (/24). Za datu IP

24
adresu, najpre možemo odrediti njenu klasu (na osnovu prvog bajta), a zatim primenom odgovarajuće maske
odrediti i početnu adresu bloka (tj. mrežnu adresu).
Sa druge strane, kod besklasnog adresiranja, samo na osnovu date IP adrese nismo u mogućnosti da odredimo
blok kojem adresa pripada. Neophodo je poznavati i masku. Drugim rečima, kod besklasnog adresiranja adresa i
maska uvek idu u paru. Maska je određena vodećih brojem 1-ca, a adresa se obično zapisuje u CIDR notaciji,
kao:
x.y.z.t/n
Broj n nakon kose crte, ukazuje na broj bita koji su isti u svim adresama iz bloka. Tako, ako je n = 20, tada su
dvadest početnih (levih) bita isti u svim adresama odgovarajućeg bloka, dok se preostalih 12 razlikuju. Na
osnovu ove informacije lako možemo naći broj adresa u bloku i poslednju adresu bloka.
Prefiks i dužina prefiksa. Pojmovi prefisk i dužna prefiksa se često koriste u kontekstu besklasnog adresiranja.
Prefiks je drugo ime za zajednički deo svih adresa iz bloka (slično kao netid). Dužina prefiksa je broj bita u
zajedničkom delu (tj. n).
Sufiks i dužna sufiksa. Sufiks je promenljivi deo u adresama nekog bloka (slično kao hostid). Dužina sufiksa je
broj bita u promenljivom delu adrese (tj. 32 - n).
Određivanje bloka
Na osnovu besklasne adrese (adresa oblika x.y.z.t/n) lako možemo odrediti prvu adresu bloka i veličinu bloka.
Određivanje prve adrese
Prva adresa bloka se koristi kao mrežna adresa i ne može se dodeliti hostu (slično kao i prva adresa bloka kod
klasnog adresiranja). Prva adresa bloka kojem data besklasna adresa pripada odre đuje se primenom AND
operacije na adresu i masku. Prosto, prvih n bita se zadrže kakvi jesu, a preostalih 32-n se postave na 0.
Pr. 2-8: Odrediti prvu adresu u bloku ako je 140.120.84.24/20 jedna od adresa iz bloka.
Dužina prefiksa date adrese je 20, što znači da zadržavamo prvih 20 bita, a preostalih 5 menjamo na 0.
Adresa u binarnom obliku: 10001100 01111000 01010100 00011000
Zadržavamo prvih 27 bita: 10100111 11000111 01010000 00000000
Rezultat u CIDR notaciji: 140.120.80.0/20

Određivanje broja adresa u bloku

Ukupan broj adresa u bloku iznosi 2 32-n.
Pr. 2-9: Odrediti broj adresa u bloku ako je 140.120.84.24/20 jedna od adresa iz bloka.
Dužina prefiksa je 20, a broj adresa u bloku 2 32-20 = 212 = 4096.

Određivanje poslednje adrese u bloku

Poslednja adresa u bloku je specijalna adresa, koja se, slično poslednjoj adresi bloka kod klasnog adresiranja,
koristi kao orgraničena opšta adresa. Poslednju adresu u bloku možemo odrediti na dva načina:
1) Poslednja adresa bloka jednaka je zbiru prve adrese bloka i veličine bloka umanjene za 1.
2) Poslednja adresa bloka jednaka je zbiru prve adrese bloka i jediničnog komplementa maske.
Pr. 2-10: Odrediti poslednju adresu bloka kojem pripada adresa 140.120.84.24/20.
Prvi način: U primeru Pr. 2-9 izračunato je da blok kojem pripada odresa 140.120.84.24/20 sadrži 4096 adresa, a
u Pr. 2-8 da je njegova prva adresa 140.120.80.0/20. Poslednju adresu bloka određujemo tako što na početnu
adresu dodajemo (4096-1). Da bi smo zadržali tačkasu-decimalnu notaciju i prilikom izvođenja operacije
sabiranja, broj 4095 predsavićemo u osnovi 256, tj. kao 15.255 (što sledi iz 4095 = 15x256 + 255). Tako,
140.120.80.0
+ 15.255
140.120.95.255
Poslednja adresa bloka je 140.120.95.255/20.
Drugi način: Maska ima dvadeset 1-ca i dvanaest 0. Komplement maske imaće dvanaest 1-ca i dvadeset 0.
Drugim rečima, komplement maske je 00000000 00000000 00001111 11111111 ili 0.0.15.255. Poslednju
adresu bloka nalazimo tako što saberemo prvu adresi i komplement maske:

25
 140.120.80.0
+ 0. 0. 15.255
140.120.95.255
Poslednja adresa bloka je 140.120.95.255/20.

Pr. 2-11 Odrediti blok ako je jedna od njegovih adresa 190.87.140.202/29.

Blok je određen prvom adresom, veličinom i poslednjom adresom. Uočimo da maska sa dužinom prefiksa 29
ima sve 1-ce na pozicijama prva tri bajta i pet 1-ca i tri nule na poziciji poslednjeg bajta, tj. 11111000. To znači
da će u prvoj adresi bloka u odnosu na datu adresu biti promenjen samo poslednji bajt (202). Broj 202 u
binarnom obliku ima vrednost 11001010, a primenom maske dobijamo: (11001010) AND (11111000) =
11001000 (decimalno 200). Dakle, prva adresa bloka je: 190.87.140.200/29. Veli čina bloka iznosi 232-29 = 23 = 8
adresa. Komplement maske je 0.0.0.7, što sabrano sa prvom adresom daje poslednju adresu bloka:
190.87.140.207/29.
Dakle, prva adresa bloka je 190.87.140.200/29, a poslednja 190.87.140.207/29. Blok ima samo 8 adresa.
Pr. 2-12 Prikazati mrežnu konfiguraciju za blok iz Pr. 2-11
Organizacija kojoj je dodeljen blok iz Pr. 2-11 može koristiti adrese iz bloka za svoje hostove. Međutim, prva i
poslednja adresa u bloku moraju ostati nedodeljene. Prva adresa predstavlja adresu mreže, a poslednja se koristi
kao ograničena opšta adresa. Dakle, organizacija u svojoj mreži može imati najviše 6 hosta. Maksimalna
konfiguracija mreže je prikazana na Sl. 2-19. (Uočimo da se poslednja adresa zavšava bajtom 207; kod klasnog
adresiranja poslednji bajtu poslednje adrese bloka je uvek 255.)

Sl. 2-19 Pr. 2-12

Podmrežavanje
Besklasno, kao i klasno adresiranje, podržava podmrežavanje. Organizacija kojoj je dodeljen blok adresa, može
kreirati podmreže shodno svojim potrebama. Administrator mreže, za svaku podmrežu, određuje odgovarajuću
masku. Maska podmreže imaće veću dužina prefiksa (n) od maske koja važi na nivou dodeljenog bloka.
Određivanje maske podmreže
Prefiks podmreže određen je brojem uvedenih podmreža. Ako je broj podmreža s, tada je broj dodatnih 1-ca u
dužini prefiksa jednak log2s. Uočimo da ako želimo da sve podmreže budu iste veličine (tj. da imaju isti broj
adresa), broj podmreža mora biti stepen dvojke.
Pr. 2-13 Organizaciji je dodeljen blok 130.34.12.64/26. Organizacija želi da kreira 4 podmreže. Kolika je
dužina prefiksa podmreže?
Kreiraju se 4 podmreže, što znači da su, u odnosu na dužinu prefiksa sajta, potrebna dve dodatne 1-ce (log24 =
2). Dakle, dužina prefiksa podmreže je /28.
Određivanje adresa u podmreži
Ako je maska podmreže poznata, lako je odrediti opseg adresa u svakoj podmreži.

26
Pr. 2-14 Odrediti adrese podmreža i opsege adresa za svaku podmrežu iz Pr. 2-13.
Mrežna konfiguracija je prikazana na Sl. 2-20.

Sl. 2-20 Pr. 2-14

32-26
Sajt ima na raspolaganju 2 = 64 adresa. Svaka podmreža ima 2 32-28 = 16 adresa. Odredimo prve i poslednje
adrese u svakoj podmreži.
Korišćenjem poznate procedure nalazimo da je prva adresa u prvoj podmreži: 130.34.12.64/28. (Uo čimo da je
prva adresa prve podmreže ujedno i prva adresa bloka.). Poslednju adresu prve podmreže naćićemo oko na prvu
adresu dodamo 15 (16-1), što daje 130.34.12.79/28.
Prva adresa u drugoj podmreži je 130.34.12.80/28 (prva naredna adresa nakon poslednje adrese iz prve
podmreže). Ponovo, sabirajući prvu adresu sa 15 dobijamo poslednju adresu: 130.34.12.95/28.
Slično, prva adresa treće podmreže je 130.34.12.96/28, a poslednja 130.34.12.111/28.
Slično, prva adresa četvrte podmreže je 130.34.12.112/28, a poslednja 130.34.12.127/28.
Podmreže promenljive veličine
Podmrežavanje nije ograničeno samo na podmreže iste veličine, odnosno podmreže sa istom maskom (n).
Mrežu je moguće podeliti i na podmreže različite veličine, koje će koristiti maske promenljive dužine prefiksa.
To omogućava da organizacije raspodeljuju svoje adrese shodno potrebama podmreža. U osnovi, postupak
kreiranja podmreža je identičan kao u slučaju podmreža istih veličina. Koncept će biti ilustrovan u sledećem
primeru.
Pr. 2-15 Organizaciji je dodeljen blok adresa sa početnom adresom 14.24.74.0/24. Blok sadrži 2 32-24=256
adresa. Organizacija želi da formira 11 podmreža:
a) dve podmreže sa po 64 adresa
b) dve podmreže sa po 32 adrese
c) tri podmreže sa po 16 adresa
d) četiri podmreže sa po 4 adrese
Projektovati podmreže.
Jedna moguća konfiguracija je prikazana na Sl. 2-21. Slika pirkazuje adrese svih podmreža.

27
 16 adrese

Podmreža
14.24.74.224/28

4 adrese 16 adrese

Podmreža Podmreža
14.24.74.240/30 14.24.74.208/28 32 adrese 32 adrese
4 adrese
Podmreža Podmreža
Podmreža 16 adrese 14.24.74.128/27 14.24.74.160/27
14.24.74.244/30
Podmreža
4 adrese 14.24.74.192/28
64 adrese 64 adrese
Podmreža
14.24.74.248/30 Podmreža Podmreža
4 adrese 14.24.74.0/26 14.24.74.64/26
Podmreža
14.24.74.252/30

Sajt: 14.24.74.0/24

Ka ostatku
Interneta

Sl. 2-21 Pr. 2-15

Prvih 128 adresa su iskorišćene za prve dve podmreže (sa po 64 adrese). Maska ovih podmreža je /27.
Sledeće 64 adrese su iskorišćene za sledeće dve podmreže (sa po 32 adrese). Maska ovih podmreža je /27.
Sledećih 48 adrese su iskorišćene za sledeće tri podmreže (sa po 16 adresa). Maska ovih podmreža je /28.
Poslednjih 16 adresa su iskorišćene za poslednje četiri podmreže (sa po 4 adrese). Maska ovih podmreža je /30.
Dodela adresa
Dodela IP adresa na globalnom nivou je pod kontrolom međunarodne neprofitne organizacije koja se zove
ICANN (Internet Corporation for Assigned Names and Numbers). Međutim, ICANN, po pravilu, se ne bavi
dodelom adresa pojedinačnim organizacijama, već blokove adresa dodeljuje ISP-ovim. Svaki ISP zatim deli
svoj blok adresa na manje blokove i raspodeljuje ih svojim korisnicima. Ovakav pristup se naziva agregacijom
adresa, jer se veliki broj manjih blokova adresa objedinjuje u jedan veliki blok koji je dodeljen jednom ISP-u.

2.2 Isporuka, prosleđivanje i rutiranje IP datagrama

U ovoj sekciji bavićemo se isporukom, prosleđivanjem i rutiranjem IP datagrama do njihovog krajnjeg
odredišta. Isporuka se odnosi na način kako se datagrami, po kontrolom mrežnog sloja, tretiraju i prenose
unutar jedne mreže. Prosleđivanje se odnosi na način kako se datagrami isporučuju sledećem ruteru, kada
datagram treba da prođe kroz više mreža da bi stigao do svog odredišta. Rutiranje se odnosi na način kako se
kreiraju tabele rutiranja koje ruteri koriste kada donose odluke o prosleđivanju/isporuci datagrama.

2.2.1 Isporuka
Isporuku datagrama možemo podeliti na dve ne tako stroge kategorije: direktna i indirektna isporuka. Direktna
isporuka se odnosi na prenos datagrama sa jednog hosta jedne fizičke mreže na drugi host te iste mreže.
Indirektna isporuka se događa kada se izvor i odredište ne nalaze u istoj mreži, zbog čega izvor mora da preda
datagram ruteru da bi ga ovaj dalje preneo.
Direktna isporuka
Kod direktne isporuke, konačno odredište datagrama je host povezan na istu fizičku mrežu kao i pošiljalac
(izvor) datagrama. Možemo uočiti dva slučaja direktne isporuke (Sl. 2-22):
a) Od izvornog do odredišnog hosta koji su locirani na istoj fizičkoj mreži. U ovom slučaju prenos
datagrama se obavlja bez učešća rutera, a izvorni host direktno isporučuje datagram odredišnom hostu.

28
 b) Od poslednjeg rutera do odredišnog hosta. Ovo je slučaj koji odgovara poslednjem koraku u prenosu
datagrama kada se izvor i odredište ne nalaze u istoj mreži. Poslednji ruter na putanji između izvora i
odredišta datagrama priključen je direktno na istu fizičku mrežu kao i odredište. Prema tome, poslednji
ruter će preneti datagram koristeći direktnu isporuku.

Sl. 2-22 Direktna isporuka.

Osnovno pitanje je kako će pošiljalac znati da li se odredište nalazi u mreži na koju je on direktno priključen.
Odgovor se krije u jednostavnom testu. Pošiljalac analizira odredišnu IP adresu uzetu iz zaglavlja datagrama; iz
nje izdvaja mrežnu adresu i upoređuje je sa adresama mreža na koje je priključen. Ako pronađe podudarnost,
datagram može biti direktno isporučen.
Da bi datagram i fizički bio prenet, pošiljalac dodatno treba da na osnovu odredišne IP adrese pronađe fizičku
adresu odredišnog hosta. Za ovu namenu (preslikavanje IP adresa na fizičke adrese) koristi se ARP protokol,
koji će kasnije biti razmatran. Sa fizičkom adresom na raspolaganju, IP softver predaje datagram sloju veze koji
ga enkaspulra u okvir i posredstvom fizičkog sloja šalje na liniju.
Indirektna isporuka
Ukoliko se odredišni host ne nalazi u istoj mreži gde i izvorni host, datagram se isporučuje indirektno. Kod
indirektne isporuke, datagram se prenosi od rutera do rutera sve dok ne stigne do rutera koji je povezan na istu
fizičku mrežu u kojoj se nalazi konačno odredište (Sl. 2-23). Uočimo da isporuka uvek uključuje jednu direktnu
isporuku i ni jednu, jednu ili više idirektnih isporuka. Poslednja isporuka je uvek direktna.

Sl. 2-23 Indirektna isporuka.

Indirektni prenos je složeniji od direktnog jer pošiljalac (izvorni host, odnosno među-ruter) mora da identifikuje
IP adresu sledećeg rutera kojem treba da pošalje datagram. Ovaj izbor se vrši na osnovu odredišne IP adrese
datagrama i tabela rutiranja. Kada je IP adresa sledećeg rutera poznata, pošiljalac koristi ARP da bi pronašao
njegovu fizičku adresu.

2.2.2 Prosleđivanje
Proslediti datagram znači uputiti ga jedan korak dalje duž putanje do njegovog krajnjeg odredišta. Prosleđivanje
podrazumeva da hostovi i ruteri poseduju tabele rutiranja. Host kada želi da pošalje datagram (ili ruter koji treba
da pošalje primljeni datagram), iz tabele rutirana, a na osnovu odredišne IP adrese, dobija informaciju kome
treba da proslediti datagram. Glavni problem u vezi sa tabelama rutiranja tiče se njihove veličine. Zbog

29
impresivne veličine današnjeg Interneta, rešenje kod koga bi tabela rutiranja sadržala posebnu stavku sa
kompletnom putanjom za svaku moguću odredišnu IP adresu je praktično neizvodljivo.
Tehnike prosleđivanja
Nekoliko tehnika je razvijeno sa ciljem da se velična tabela rutiranja održi na prihvatljivom nivou.
Metod sledećeg skoka. Kod ove tehnike, tabela rutiranja sadrži samo informaciju o adresi sledećeg skoka
(koraka), umesto informacije o kompletnoj putanji. Na Sl. 2-24 je prikazno kako se tabele rutiranja mogu
pojednostaviti korišćenjem ove tehnike. Slika prikazuje delove tabela rutiranja koje se odnose na host B u datoj
mrežnoj konfiguraciji. Na Sl. 2-24(a) date su tabele koje sadrže kompletne putanje do hosta B, a na Sl. 2-24(b)
tabele sa navedenim sledećim-skokom. Na primer, host A ne mora da zna kompletnu putanju do hosta B,
dovoljno je da zna da datagram kojeg želi da pošalje hostu B treba da isporuči ruteru R1. Slično, ruter R1,
isporučiće ruteru R2 svaki datagram koji putuje ka hostu B. Datagrame namenjene hostu B, ruter R2 direktno
isporučuje. Dakle, svaka tabela rutiranja određuje samo jedan (sledeći) korak duž putanje od odredišta
(host/ruter ne poznaje celu putanju do odredišta!).

(a)

(b)
Sl. 2-24 Metod sledećeg skoka.
Mežno-specifični metod. Drugi metod za smanjenje veličine tabele rutiranja i pojednostavljenja procesa
pretrage tabela zove se mrežno-specifični metod. Kod ovog metoda, umesto da tabele sadrže posebnu stavku za
svaki odredišni host povezan na neku fizičku mrežu na Internetu, one sadrže stavke koje definišu odredišne
mreže. Drugim rečima, svi hostovi povezani na istu mrežu tretiraju se kao jedan entitet. Na primer, ako je na
nekoj mreži prisutno 1000 hostova, u tabeli rutiranja će postojati samo jedna stavka, a ne 1000. Na Sl. 2-25 je
ilustrovan koncept mrežno-specifičnog metoda. Datagrami koji se šalju hostovima iz mreže N2 uvek se
prosleđuju ruteru R1. Nema potrebe u tabeli rutiranja eksplicitno navoditi svaki host iz mreže N2, jer će ruter u
poslednjem koraku (u ovom slučaju R1) obaviti direktnu isporuku odgovarajućem odredišnom hostu.

Sl. 2-25 Mrežno-specifični metod

Metod podrazumevanog rutera. Razmotrimo mrežnu konfiguraciju sa Sl. 2-26. Host A je povezan na mrežu
koja ima dva rutera. Ruter R1 se koristi za isporuku datagrama hostovima iz mreže N2, dok se za ostatak
Interneta koristi ruter R2. Umesto da su u tabeli rutiranja hosta A eksplicitno navede sve mreže na Internetu,
navedena je samo jedna tzv. podrazumevana stavka (u delu za odredište ove stavke normalno je navedena
mrežna adresa 0.0.0.0). Dakle, ako datagram nije upućen u mrežu N2, biće prosleđen ruteru R2, koji na sebe
preuzima odovornost dalje isporuke. Datagram se prosleđuje ruteru R1, jedino ako je namenjen nekom hostu iz
mreže N2.

30
 Tabela rutiranja hosta A
Odredište Sledeći skok
N2 R1
Host A ... ...
Podrazumevano R2

R1
N1 N2

R2

Ostatak Interneta

Sl. 2-26 Podrazumevano rutiranje.

Prosleđivanje kod klasnog adresiranja
Klasna šema adresiranja poseduje niz nedostataka koji su posledica fiksiranih veličina blokova. Međutim,
upravo ova osobina, koja se ogleda i kroz postojanje podrazumevanih maski, čini proces prosleđivanja
jednostavnim. U nastavku će biti opisani postupci prosleđivanja datagrama za slučaj klasnog adresiranja u
mrežnim konfiguracijama bez i sa podmrežavanjem.
Prosleđivanje bez podmrežavanja
Kod klasnog adresiranja, većina rutera na Internetu nisu opterećeni podmrežavanjem. Podmrežavanje se javlja
samo unutar organizacija. Na Sl. 2-27 je prikazana struktura modul za prosleđivanje, za slučaju klasnog
adresiranja bez podmrežavanja. Modul sadrži tri tabele rutiranja, po jednu za svaku klasu A, B i C. (Ako ruter
podržava multicast komunikaciju, postojaće još jedna tabela za adrese iz klase D.) Podela na tri tabele
omogućava brzu pretragu. Svaka tabela ima tri kolone:
1. Mrežna adresa odredišne mreže - ukazuje na mrežu u kojoj je odredišni host lociran (pretpostavka je da
se koristi mrežno-specifično prosleđivanje).
2. Adresa sledećeg skoka - ukazuje kom ruteru treba isporučiti datagram (za slučaj indirektne isporuke). U
slučaju direktne isporuku, ova kolona je prazna.
3. Broj mrežnog adaptera - definiše izlazni port kroz koji treba poslati datagram. Ruter je normalno
priključen na nekoliko mreža. Svaki mrežni priključak ima različiti broj porta, tj. broj mrežnog
adaptera.

Sl. 2-27 Modul za prosleđivanje datagrama za klasno adresiranje bez podmrežavanja.

Jedna stavka tabele se tumači na sledeći način: Datagram upućen hostu koji se nalazi u mreži čija je adresa
navedena u prvoj koloni, treba isporučiti ruteru, čija je IP adresa navedena u drugoj koloni, a koji se nalazi u
fizičkoj mreži koja je dostupna preko mrežnog adaptera čiji je broj naveden u trećoj koloni.

31
Pr. 2-16: Prikazati sadržaj tabela rutiranja rutera R1 u mrežnoj konfiguraciji sa Sl. 2-28.

Sl. 2-28 Mrežna konfiguracija za Pr. 2-16

Tri tabele rutiranja rutera R1, za klase A, B i C, prikazane su na Sl. 2-29. Uočimo da su neke stavke za adresu
sledećeg skoka prazne. U svakom takvom slučaju odredište se nalazi u jednoj od mreža na koje je ruter
priključen (koristi se direktna isporuka), a ARP-u se predaje odredišna IP adresa uzeta iz datagrama.

Sl. 2-29 Tabela za Pr. 2-16

U najjednostavnijem obliku, modul za prosleđivanje obavlja sledeće tri aktivnosti prilikom obrade svakog
datagram:
1. Izdvajanje odredišne adrese iz datagrama
2. Određivanje klase odredišne adrese.
3. Odredišna adresa, zajedno sa klasom određenom u koraku 2., se koriste za određivanje mrežne adrese
odredišta.
4. Klasa adrese i mrežna adresa se koriste za pretragu tabela rutiranja. Klasa određuje tabelu koju treba
pretražiti. U prvoj koloni izabrane tabele traži se mrežna adresa. Ako je pretraga uspešna, iz
odgovarajuće vrste tabele uzimaju se adresa sledećeg skoka i broj mrežnog adraptera. Ako u tabeli ne
postoji stavka sa traženom mrežnom adresom, koristi se podrazumevana stavka.
5. Adresa sledećeg skoka i broj mrežnog adaptera se prosleđuju ARP modulu koji ima zadatak da pronađe
fizičku adresu sledećeg rutera. Nakon toga, ARP prosleđuje datagram sloju veze koji obavlja fizički
prenos.
Pr. 2-17: Ruter R1 sa Sl. 2-28 prima datagram upućen na adresu 192.16.7.14. Opisati postupak
prosleđivanja ovog datagrama.
Prvo, određuje se klasa odredišne adrese. Obzirom da za prvi bajt adrese važi 192 ≤ 192 ≤ 223, odredišna IP
adresa pripada klasi C. Drugo, klasi C, netid je veličine 3 bajta, što znači da je datagram upućen u odredišnu
mrežu: 192.16.7.0. Treće, tražena mrežna adresa postoji u tabeli rutiranja za klasu C. Četvrto, odgovarajuća
adresa sledećeg skoka (111.15.17.32) i broj mrežnog adaptera (m0) se prosleđuju ARP-u koji treba da pronađe
fizičku adresu sledećeg rutera i uz pomoć softvera sloja veze pošalje datagram sledećem ruteru.
Pr. 2-18: Ruter R1 sa Sl. 2-28 prima datagram sa odredišnom adresom 167.24.160.5. Opisati postupak
prosleđivanja ovog datagrama.
Odredišna adresa pripada klasi B (128 ≤ 167 ≤ 191). U klasi B, netid je veličine 2 bajta. Dakle, mrežna adresa
odredišta je 167.24.0.0. Pretražuje se tabela za klasu B. Međutim, u ovoj tabeli ne postoji odrednica za traženu
mrežnu adresu. Zbog toga, paket treba isporučiti podrazumevanom ruteru (tj. na IP adresu 111.30.31.18 kroz
mrežni adapter m0.

32
Prosleđivanje sa podmrežavanjem
Kod klasnog adresiranja, podmrežavanje postoji samo unutar organizacija. Ruteri koji se bave podmrežavanjem
su ili na granicama organizacija ili unutar samih organizacija. Na Sl. 2-30 je prikazana strukura modula za
prosleđivanje za slučaj podmreža fiksne veličine. Modul obrađuje svaki datagram na sledeći način:
1. Izdvaja odredišnu adresu iz datagrama.
2. Odredišna adresa i maska se koriste za određivanje adrese podmreže.
3. Adresa podmreže se koristi za pretragu tabele rutiranja kako bi se pronašla adresa sledećeg skoka i broj
mrežnog adaptera. Ako u tabeli na postoji odrednica za traženu adresu podmreže, koristi se odrednica
za podrazumevani ruter.
4. Adresa sledećeg skoka i broj mrežnog adaptera se predaju ARP-u

Sl. 2-30 Modul za prosleđivanje datagrama za klasno adresiranje sa podmrežama.

Pr. 2-19 Na Sl. 2-31 je prikazan ruter priključen na 4 prodmreže.

Adresa Adresa sledećeg Mrežni
podmreže skoka adapter
145.14.0.0 - m0
145.14.64.0 - m1
145.14.128.0 - m2
145.14.192.0 - m3
0.0.0.0 podrazumerani ruter m4

x.y.z.t/n m4 Maska podmreže: /18

m3 m2 m1 m0

145.14.192.0/18 145.14.0.0/18

145.14.128.0/18 145.14.64.0/18

Sajt 145.14.0.0/16

Sl. 2-31 Konfiguracija za Pr. 2-19.

Treba uočiti nekoliko detalja. Prvo, adresa sajta je 145.14.0.0/16 (adresa klase B). Svaki datagram sa adresom
odredišta iz opsega 145.14.0.0 - 145.14.255.255 koji kroz mrežni adapter m4 stigne u ruter, prosleđuje se, kroz
mrežne adaptere m0-m3 u jedno od četiri podmreža. Drugo, IP adresa rutera za mrežni adapter m4 zapisana je u
obliku x.y.z.t/n, zato što ne znamo na koju mrežu je ovaj ruter povezan. Treće, tabela ima podrazumevanu
odredicu za datagrame koji napuštaju sajt. Ruter je konfigurisan tako da primenjuje masku podmreže /18 za sve
odredišne podmreže.
Pr. 2-20: Ruter sa Sl. 2-31 je primio datagram sa odredišnom adresom 145.14.32.78. Gde će ovaj datagram
biti isporučen?
Maska je /18. Nakon primene maske na odredišnu adresu dobijamo adresu podmreže; 145.14.0.0. Datagram se
predaje ARP-u sa adresom sledećeg skoka 145.14.32.78 i brojem mrežnog adaptera m0.

33
Prosleđivanje kod besklasnog adresiranja
Kod besklasnog adresiranja, celokupan adresni prostor se tretira kao jedinstvena celina; ne postoje klase.
Adresni prostor se deli na blokove različitih veličina koji se dodeljuju organizacijama. To znači da u tabeli
rutiranja za besklasno adresiranje mora postojati stavka za svaki poznati blok. Stavka sadrži masku (/n) i prvu
(mrežnu) adresu bloka, koje zajedno definišu blok, sa jedne i adresu sledećeg skoka i broj mrežnog adaptera sa
druge strane.

Sl. 2-32 Struktura modula za prosleđivanje za besklasno adresiranje.

Na Sl. 2-32 je prikazana struktura modula za prosleđivanje za besklasno adresiranje. Za razliku od klasnog
adresiranja kod koga se pripadnost odredišne adrese klasi i mrežna adresa utvrđuju na osnovu same odredišne
adrese (vidi Sl. 2-27), kod klasnog adresiranja za testiranje pripadnosti odredišne adrese bloku neophodno je
koristiti i masku, koja je specifična za svaki blok. Zbog toga je pretraga tabele rutiranja za besklasno adresiranje
složenija jer zahteva da se mrežna adresa date odredišne adrese određuje za svaku stavku iz tabele posebno,
korišćenjem maske sadržane u stavci.
Pr. 2-21: Sačiniti tabelu rutiranja rutera R1 u mrežnoj konfiguraciji sa Sl. 2-33.

Sl. 2-33 Konfiguracija za Pr. 2-21.

Tabela rutiranja rutera R1 je prikazana na Sl. 2-34.

Sl. 2-34 Tabela rutiranja za ruter sa Sl. 2-33.

Pr. 2-22: U ruter R1 sa Sl. 2-33 stiže datagram sa odredišnom adresom 180.70.65.128. Opisati proces
prosleđivanja ovog datagrama.
Ruter obavlja sledeće aktivnosti:

34
1 - Ispituje se prva vrsta tabele rutiranje. Na odredišnu adresu se primenjuje maska /26, kako bi se izdvojila
mrežna adresa. Obzirom da rezultujuća adresa, 180.70.65.128, nije jednaka adresi iz druge kolone analizirane
stavke, zaključujemo da odredišna adresa ne pripada ovom bloku.
2 - Ispituje se druga vrsta tabele rutiranja. Primenom maske /25 na odredišnu adresu dobijamo mrežnu adresu
koja se poklapa sa onom navedenoj u drugoj koloni ispitivane stavke, Znači, odredišna adresa pripada ovom
bloku, a za prosleđivanje datagrama treba koristiti informacije iz treće i četvrte kolone druge stavke. Pošto
adresa sledećeg skoka nije navedena, zaključujemo da se odredišni host nalazi u mreži na koju je ruter direktno
priključen. Zato se ARP-u predaje odredišna adresa iz datagrama zajedno sa brojem mrežnog adaptera m0
(vrednost iz četvrte kolone).
Pr. 2-23: Opisati proces prosleđivanja datagrama sa odredišnom adresom 18.24.32.78 kroz ruter R1 sa Sl.
2-33.
U ovom slučaju, odredišna adresa na pripada ni jednom bloku navedenom u tabeli rutiranja rutera R1 ( Sl. 2-34).
Zato se za prosleđivanje datagrama koriste informacije iz podrazumevane stavke: datagram se kroz mrežni
adapter m2 prosleđuje ruteru sa IP adresom 180.70.65.200.
Agregacija adresa
Glavna prednost besklasnog u odnosu na klasno adresiranje je mogućnost podele adresnog prostora na veći broj
blokova promenljive dužine. Međutim, zbog toga su i tabele rutiranja za besklasno adresiranje veće (sadrže veći
broj stavki) od tabela za klasno adresiranje. Povećan broj stavki u tabeli ne samo da zuzima veću količinu
memorije, već i produžava vreme pretrage tabele. Da bi se ovaj problem prevazišao, ili barem ublažio,
primenjuje se tehnika adregacije adresa, koja će biti objašnjena uz pomoć Sl. 2-35.

Sl. 2-35 Agregacija adresa.

U mrežnoj konfiguraciji sa Sl. 2-35, ruter R1 je priključen na četiri mreže od kojih svaka pripada jednoj
organizaciji i sadrži 64 adresa. Sa druge strane, R1 je povezan sa ruterom R2 koji se nalazi na nekoj udaljenoj
lokaciji. Tabele rutiranja rutera R1 je veća od one kod rutera R2 zato što R1 mora svaki datagram direktno da
usmeri ka jednoj od četiri organizacije. Sa druge strane, tabela rutiranja rutera R2 je kraća zato što on svaki
datagram sa odredišnom adresom iz opsega 140.24.7.0.0 do 140.24.7.255 šalje kroz adapter m0 ka ruteru R1,
bez obzira kojoj od četiri organizacije je namenjen. Dakle, R2 ne mora da sadrži posebnu stavku za svaku od
četiri organizacije, već su četiri bloka objedinjeni u jedan veći blok. Agregacija adresa četiri organizacije je
moguća zato što su njihovi blokovi adresa kontinualni (nadovezuju se jedan na drugog).
Lako je uočiti da se agregacije adresa može primenjivati hijerarhijski. Na primer, možemo zamisliti ruter R3 u
kome je izvršena adregacija adresa rutera R2.
Poklapanje po najdužoj maski
Postavlja se pitanje: šta će se desiti ako je jedna od organizacija iz prethodnog primera geografski udaljena u
odnosu na preostale tri? Na primer, ako se, iz bilo kog razloga, mreža organizacije 4 ne može povezati sa
ruterom R1, da li je i dalje moguće primeniti agregaciju adresa, a da organizacija 4 zadrži blok 140.24.7.192/26?
Odgovor je potvrdan, zahvaljujući principu poklapanja po najdužoj maski koji se koristi u ruterima za besklasno
adresiranje. Shodno ovom principu, stavke u tabeli rutiranja su sortirane po dužini maske, počev od najduže do

35
najkraće. Na primer, ako u tabeli postoje tri maske: /27, /26 i /24, tada će stavka sa maskom /27 biti prva, a /24
poslednja stavka u tabeli. Razmotrimo kako se primenom ovog principa može razrešiti situacija sa Sl. 2-36, gde
je organizacija 4 udaljena od preostale tri i putem posebnog rutera, R3, pozvezana sa ruterom R2.

Sl. 2-36 Poklapanje po najdužoj maski.

Prva stavka u tabeli rutiranja rutera R2 se upravo odnosi na mrežu organizacije 4, dok je druga dobijena
agregacijom adresa sve četiri organizacije (uključujući organizaciju 4). Uočimo da je opseg adresa organizacije
4 pokriven i prvom i drugom stavkom. Međutim, do pogrešnog usmeravanja ne dolazi je će druga stavka biti
razmatrana samo ako datagram nije upućen organizaciji 4. Na primer, pretpostavimo da je ruter R2 primio
datagram sa odredišnom adresom 140.24.7.200. Primenom maske /26 iz prve stavke na odredišnu adresu dobija
se mrežna adresa 140.24.7.192 koja se poklapa sa mežnom adresom iz ove stavke. Dakle, datagram će ispravno
biti usmeren kroz adapter m0 ka organizaciji 4. Uočimo da bi pri drugačijem (nesortiranom) redosledu stavki u
tabeli u kome bi stavka sa maskom /24 prethodila stavki za mrežu organizacije 4, datagram bio pogrešno
usmeren ka ruteru R1.
Hijerarhijsko rutiranje
Savremeni Internet je najvećim delom organizovan na hijerarhijski način. Internet je podeljen na međunarodne i
nacionalne ISP-ove. Nacionalni ISP-ovi su podeljeni na regionalne, a regionalni na lokalne ISP-ove. Ovakav
način organizacije omogućava smanjene veličine tabela rutiranja.
Razmotrimo slučaj lokalnog ISP-a. Lokalnom ISP-u može biti dodeljen jedan veći blok adresa određene dužine
prefiksa. Lokalni ISP može podeliti ovaj blok na manje blokove rezličitih dužina i dodeliti ih pojedinačnim
korisnicima i organizacijama. Ako blok dodeljen lokalnom ISP-u počinje adresom a.b.c.d/n, tada će dužina
prefiksa maski svih podeljenih blokva biti duže od n. Iako je blok razdeljen na veliki broj manjih blokova,
ostatak Interneta nije svestan ove podele. Za ostatak Interneta svi korisnici lokalnog ISP-a definisani su sa
a.b.c.d/n. Svaki datagram upućen na neku adresu iz ovog velikog bloka, biće isporučen lokalnom ISP-u, a u
tabelama rutiranja svih rutera na Internetu postojaće samo jedna stavka za sve ove korisnike. Svi oni pripadaju
istoj grupi. Naravno, ruter lokalnog ISP-a mora prepoznati podblokove i usmeriti datagram ka odgovarajućem
odredišnom korisniku. Ako je neki od korisnika veća organizacija, onda se unutar te organizacije, uvođenjem
podmrežavanja, može formirati još jedan nivo hijerarhije. Drugim rečima, podblok organizacije biće podeljen na
manje podblokove (pod-podblokove). Kod besklasnog adresiranja, broj nivoa hijerarhije nije ograničen, sve dok
se poštuju pravila besklasnog adresiranja.
Geografsko rutiranje
Veličina tabela rutiranja se dodatno smanjuje uvođenjem geograskog rutiranja. Celokupan adresni prostor je
podeljen na nekoliko velikih blokova. Jedan blok je dodeljen Severnoj Americi, drugi Evropi, treći Aziji i td.
Ruteri ISP-ova izvan Evrope sadržaće samo jednu stavku za sve datagrame koji se upućuju nekome u Evropi.
Slično, ruteri ISP-ova izvan Severne Amerike imaće samo jednu stavku za sve datagrame koji se upućuju
nekome u Severnoj Americi i td.

36
2.2.3 Rutiranje
Rutiranje se odnosi na kreiranje i ažuriranje tabela rutiranja.
Statičke i dinamičke tabele rutiranja
Kao što smo videli u prethodnoj sekciji, ruter usmerava datagrame na osnovu sadržaja tabele rutiranja koja za
svako odredište ili grupu odredišta sadrži jednu stavku. Tabele rutiranja mogu biti statičke ili dinamičke.
Statičke tabele rutiranja
Statičke tabele rutiranja se manuelno popunjavaju. Stavke u tabelu unosi administrator mreže. Nakon što je
tabela kreirana, ona se ne može automatski ažurirati (zbog npr. promena nastalih na Internetu). Svaku promenu
mora da unese administrator. Statičke tabele se koriste u malim mrežama, čija se konfiguracija ne menja često.
Dinamičke tabele rutiranja
Dinamičke tabele rutiranja se automatski ažuriraju korišćenjem jednog od protokla za dinamičko rutiranje (RIP,
OSPF ili BGP). Uvek kada se na Internet desi neka promena, kao što je prestanak rada nekog rutera ili prekid
nekog linka, dinamički protokol za rutiranje je odgovoran za automatsko ažuriranje tabela svih rutera.

2.2.4 Struktura rutera

U dosadašnjim razmatranjima u vezi prosleđivanja i rutiranja, ruter je uvek bio predstavljan kao crna kutija koja
prihvata dolazne pakete sa svojih ulaznih portova, koristi tabele rutiranja da bi odredito izlazni port kroz koji
treba isporučiti paket i kroz izabrani izlazni port šalje datagram sledećem ruteru ili odredišnom hostu. U ovoj
sekciji, razmotrićemo sa više detalja unutrašnju strukturu rutera.
Ruter čine četiri osnovne komponente: ulazni portovi, izlazni portovi, procesor rutiranja i komutatorska matrica
(Sl. 2-37).

Sl. 2-37 Komponente rutera.

Ulazni portovi. Ulazni port zadužen je za funkcije rutera koji se odnose na fizički i sloja veze. Ulazni port prima
okvir sa linije, detektuje greške u prenosu i iz okvira izdvaja datagram. Dodatno, ulazni port sadrži bafer (red
čekanja) za čuvanje datagrama pre nego što iz usmeri ka komutatorskoj matrici. Na Sl. 2-38 je prikazan šematski
dijagram ulaznog porta.

Sl. 2-38 Ulazni port.

Izlazni portovi. Izlazni port obavlja iste funkcije kao ulazni port, samo u obrnutom redosledu. Odlazni datagrami
se smeštaju u red čekanja, pakuju se u okvire, a zatim se okvir konvertuje u signal koji se šalje na liniju (Sl.
2-39).

Sl. 2-39 Izlazni port.

37
Procesor rutiranja. Procesor rutiranja obavlja funkciju mrežnog sloja. Ovaj blok koristi odredišnu adresu
datagrama za pretragu tabele rutiranja radi određivanja adrese sledećeg skoka i broja mrežnog adaptera (tj.
izlaznog porta).
Komutatorska matrica. Najsloženija aktivnost koja se obavlja u ruteru je prebacivanje datagrama iz ulaznih u
izalazne redove čekanja. Brzina sa kojom može da se obavi prebacivanje, određuje potrebnu veličinu ulaznih i
izlaznih bafera, kako i ukupno kašnjenje datagrama kroz ruter. Komutatorska matrica treba da omogući prenos
datagrama iz bilo kog ulaznog bafera u bilo koji izlazni bafer i da pri tome bude u stanju da istovremeno obavlja
prenos više od jednog datagrama. Kod savremenih rutera koriste se različita rešenja. Ukratko ćemo razmotriti
dva:
Krozbar komutator. Po strukturi najjednostavniji, ali po složenosti najsloženiji tip komutatorske matric
je krozbar (Sl. 2-40). Krozbar povezuje n ulaza i n izlaza putem mreže u čijim presecima su nalaze
mirkoprekidači koji uspostavljaju željeni kontakt. Krozbar može istovremeno da prenosi n datagrama iz
n ulaznih bafera pod uslovom da su svi oni upućeni ka različitim izlaznim portovima. Nedostatak
krozbara je veliki broj mikroprekidača = n x n.
0
1
Ulaz
2
3

0 1 2 3
Izlaz

Sl. 2-40 Krozbar.

Banyan komutator. Banyan komutator je višestepeni komutator sa mikroprekidačima u svakom stepeno
koji usmeravaju pakete shodno reperezentaciji rednog broja izlaznog porta u binarnom obliku. Za n
ulaza i n izlaza, mreža sadrži log2(n) stepena sa po n/2 mikroprekidača. Prvi stepen usmerava pakete
shodno bitu najveće težine rednog broja izlaznog porta, drugi stepen odluku o usmeravanju donosi na
osnovu prvog sledećeg bita i td. Na Sl. 2-41 je prikazan banyan komutator sa osam ulaza i osam izlaza.
Broj stepena je log2(8) = 3.

Sl. 2-41 Banyan komutator.

Na Sl. 2-42 je ilustrovan način rada banyan komutatora. Na Sl. 2-42(a) je istaknuta putanja kojom se
kroz komutator prenosi datatagram koji stiže preko ulaznog porta 1 i prenosi se na izlazni port 6
(binarno 110). Prvo mirkoprekidač (A-2) usmerava datagram na osnovu prvog bita (1), drugi (b-4) na
osnovu drugog (1), a treći mikroprekidač na putanji (C-4) na osnovu trećeg bita (0). Na Sl. 2-42(b)
vidimo putanju datagrama kroz komutator od ulaznog porta 5 do izlaznog porta 2 (010).

38
 (a) (b)
Sl. 2-42 Primer rutiranja kroz banyan komutator: (a) od ulaza 5 do izlaza 6 (110); (b) od ulaza 5 do izlaza 2 (010).
U odnosu na krozbar, banyian komunator sadrži manji broj mikroprekidača za isti broj ulaza i izlaza,
ali zato je vreme prenosa paketa duže, jer svaki paket mora proći kroz log2(n) mikroprekidača umesto
samo kroz jedan, kao što je to slučaj kod krozbara. Još jedan problem koji se javlja kod banyan
komutatora, a koji ne postoji kod krozbara, je mogućnost interne kolizije dva pakete. Naime ako su na
oba ulaza nekog mikroprekidača prisutni datagrami koji treba usmeriti na isti izlaz mikroprekidača,
preneće se samo jedan, dok drugi mora da čeka.

2.3 ARP i RARP

Internet čini kombinacija raznorodnih fizičkih mreža spregnutih ruterima. Svaka mašina na Internetu (host ili
ruter) ima jednu (ili više) IP adresa. Kao što znamo, IP adrese su logičke (mrežne) adrese koje se koriste za
rutiranje datagrama od izvornog do odredišnog hosta. IP adrese su jedinstvene i univerzalne na nivou globalnog
Interneta. Međutim, paket na putu od izvora do odredišta obično prolazi kroz više različitih fizičkih mreža. Na
fizičkom nivou, hostovi i ruteri se prepoznaju po svojim fizičkim adresama. Fizičke adrese su lokalne adrese jer
imaju značenje samo u okviru lokalne mreže. One moraju biti jedinstvene (na lokalnom nivou) ali ne obavezno i
univerzalne (na globalnom nivou). Zovu se fizičkim adresama zato što su obično utisnute u hardver mrežnog
adaptera. Primer fizičkih adresa su 48-bitne MAC adrese koje se koriste kod Ethernet-a.
Fizičke i mrežne adrese su dva različita identifikatora; dok fizičke identifikuju priključak mašine na lokalnu
mrežu, mrežne identifikuju priključak mašine na globalni Internet. Fizička adresa se može lako promeniti, npr.
zamenom mrežnog adaptera (npr. zbog kvara), dok su IP adrese dugotrajnije i ne mogu se proizvoljno menjati.
Dakle, za prenos paketa do hosta ili rutera potrebna su dva nivoa adresiranja: logički i fizički. Postavlja se
pitanje: kako IP adrese preslikati na fizičke. Ovo pitanje se postavlja uvek kada jedna mašina treba da isporuči
IP datagram drugoj mašini (hostu ili ruteru) na istoj fizičkoj mreži. Mašina M1 koja šalje datagram zna IP
adresu odredišne mašine M2, ali da bi se prenos i fizički ostvario M1 mora znati i fizičku adresu mašine M2.
Preslikavanje adresa se može ostvariti statički ili dinamički. Statičko preslikavanje podrazumeva kreiranje tabele
u kojoj su mrežnim adresama pridružene fizičke. Ovakvu tabelu bi trebalo da poseduje svaka mašina na mreži.
Mašina M1 koja zna IP adresu mašine M2, fizičku adresu mašine M2 može da potraži u svojoj tabeli. Međutim:
1. Mrežni adapter može biti zamenjen, što znači i promenu fizičke adrese mašine.
2. Kod nekih tipova LAN mreža, fizička adresa se menja uvek kada se mašina uključi.
3. Mobilni računari se mogu premeštati iz jedne u drugu mrežu, što povlači i neizbežnu promenu fizičke
adrese.
Iz navedenih razloga, tabele bi morale biti često ažurirane, što je svakako nepraktično.
Kod dinamičkog preslikavanja, mašina koja zna jednu od dve adrese (logičku ili fizičku) može koristiti protokol
da bi saznala drugu. Za dinamičko preslikavanje adresa u upotrebi su dva protokola: ARP (Address Resolution
Protocol - Protokol za razrešavanje adresa) i RARP (Reverse Address Resolution Protocol). Prvi preslikava
logičke adrese na fizičke, a drugi fizičke na logičke (Sl. 2-43).

39
 Sl. 2-43 ARP i RARP.
Pre nego što pređemo na detaljniji prikaz ova dva protokola, treba napomenuti da oni koriste kako unicast tako i
broadcast fizičke adrese. Unicast fizička adresa je ona koja se odnosi na tačno jednu stanicu na lokalnoj mreži,
dok se broadcast odnosi na sve stanice. Na primer, kod Ethernet-a se kao broadcast koristi adresa sa svim 1-
cama (FF-FF-FF-FF-FF-FF).
ARP
Host ili ruter koji želi da pošalje IP datagram nekom drugom hostu ili ruteru, raspolaže logičkom (IP) adresom
prijemnika. Međutim, da bi mogao biti prenet fizičkim linkom, datagram mora biti enkapsuliran u okvir. To
znači da pošiljalac datagrama, pored logičke, mora da poznaje i fizičku adresu prijemnika. Pošto između
logičkih i fizičkih adresa ne postoji direktna veza, neophodan je mehanizam koji će omogućiti pronalaženje
fizičke adrese za datu logičku adresu. Već je rečeno da statički pristup, koji se oslanja na tabele koje se
manuelno popunjavaju, nije pogodan za ovu namenu. Dinamički pristup podrazumeva mogućnost da se
pošiljalac obrati primaocu sa zahtevom da mu saopšti svoju fizičku adresu. ARP je protokol koji reguliše
konverzaciju predajnika i prijemnika u toku ovog procesa.
Kad god nekom hostu ili ruteru zatreba fizička adresa nekog drugog hosta ili rutera u istoj mreži, on formira i
šalje na mrežu paket tipa ARP upit. Ovaj paket sadrži fizičku i IP adresu pošiljaoca i IP adresu primaoca. Pošto
pošiljalac na zna fizičku adresu primaoca, paket se emituje (broadcast) na mrežu (Sl. 2-44(a)). U slučaju
Etherneta, braodcast se ostvaruje slanjem okvira na fizičku adresu FF-FF-FF-FF-FF-FF (sve 1-ce). Svi hostovi i
ruteri u mreži primaju i obrađuju ARP paket, ali samo onaj koji u upitu prepozna svoju IP adresu odgovara
hostu koji je postavio upit slanjem paketa tipa ARP odgovor (Sl. 2-44(b)). U ovom paketu sadržana je fizička
adresa traženog hosta, a paket se direktno šalje pošiljaocu upita, na fizičku adresu preuzetu iz ARP upita
(unicast). Host koji je postavio upit, uzima fizičku adresu iz ARP odgovora i koristi je kao odredišnu adresu u
okviru koji prenosi datagram do odredišnog hosta.

(a)

(b)
Sl. 2-44 ARP: (a) ARP upit; (b) ARP odgovor.

40
Format paketa
Format ARP paketa prikazan je na Sl. 2-45.
0 8 16 31
HardwareType ProtocolType

HLEN (0x06) PLEN (0x04) OPERATION (0x0001 or 0x0002)

Sender EA
Sender EA Sender IP

Sender IP Target EA

Target EA

Target IP

Sl. 2-45 Format ARP paketa.

Značenja polja su sledeća:
• Hardware Type. 16-bitno polje koje definiše tip mreže u kojoj se ARP primenjuje (odnosno tip fizičke
adrese). Standardom je svakom tipu LAN-a dodeljen jedinstveni ceo broj. Na primer, za Ethernet LAN
u ovom polju je upisana 1-ca (0x0001). ARP je univerzalan protokol koji se može koristiti na bilo kojoj
fizičkoj mreži.
• Protocol Type. 16-bitno polje koje definiše tip protokola odnosno tip mrežne adrese. Za IPv4 u ovom
polju je upisano 0x0800. ARP se može koristiti u kombinaciji sa bilo kojim protokolom višeg nivoa.
• HLEN (Hardware Length). 8-bitno polje koje definiše dužinu fizičke adrese u bajtovima (0x06 za
Ethernet adrese).
• PLEN (Protocol Length). 8-bitno polje koje definiše dužinu mrežne adrese u bajtovima (0x04 za IP
adrese).
• OPERATION. 16-bitno polje koje definiše tip paketa: ARP upit (0x0001) ili ARP odgovor (0x0002).
• Sender EA. Polje promenljive dužine koje sadrži fizičku adresu pošiljaoca. Na primer, za Ethernet,
dužina ovog polja iznosi 6 bajta.
• Sender IP. Polje promenljive dužine koje sadrži logičku adresu pošiljaoca. Na primer, za IPv4 dužina
ovog polja iznosi 4 bajta.
• Target EA. Polje promenljive dužine koje sadrži fizičku adresu ciljne mašine. Na primer, za Ethernet
dužina ovog polja je 6 bajta. Za ARP upit, ova adresa nije poznata i zato se obično postavlja na sve
nule. Na prijemu se ignoriše.
• Target IP. Polje promenljive sadrži koje definiše logičku adresu ciljne mašine. Za IPv4 dužina ovog
polja je 4 bajta.
Oba tipa ARP paketa: ARP upit i ARP odgovor imaju identičan oblik, a za identifikaciju tip koristi se polje
OPERATION. ARP protokol nije ograničen samo na IP, kao protokol višeg nivoa i Ethernet kao tip fizičke
mreže, već je univerzalan u smislu da se može koristiti za preslikavanje adresa između bilo koja dva para
mrežnih i protokola sloja veze. Tipovi protokola navedeni su u poljima Hardware Type i Protocol Type.
Dužine adresa različitih protokola se razlikuju. Zato postoje polja HLEN i PLEN koja sadrže informaciju o
dužinama adresa. U ARP paketu predviđen je prostor za dva para (fizička adresa, mrežna adresa). Prvi par
(Sender EA, Sender IP) odnosi se na pošiljaoca ARP upita, a par (Target EA, Target IP) na mašinu od koje se
traži odgovor. U ARP upitu polje Target EA je prazno (sadrži sve 0). Mašina koja je prepoznala svoju mrežnu
adresu u polju Target IP, popunjava polje Target EA svojom fizičkom adresom, tip paketa menja na ARP
odgovor i tako formiran paket šalje na fizičku adresu iz polja Sender EA.
Enkapsulacija
ARP paket se enkapsulira direktno u okvir sloja veze. Na primer, na Sl. 2-46 ARP paket je enkapsuliran u
Ethernet okvir. Uočimo da sadržaj polje Tip Ethernet okvira (0x0806) ukazuje da okvir sadrži ARP paket.

41
 Sl. 2-46 Enkapsulacija ARP paketa.
Način rada
Sledi niz aktivnosti u tipičnom ARP procesu:
1. Pošiljalac poseduje IP datagram namenjen ciljnoj mašini poznate IP adrese.
2. IP traži od ARP da kreira ARP upit popunjen fizičkom adresom pošiljaoca, IP adresom pošiljaoca i
ciljnom IP adresom. Polje za ciljnu fizičku adresu se popunjava svim nulama.
3. Poruka ARP upita se prosleđuje sloju veze gde se enkapsulira u okvir. Izvorna adresa okvira je fizička
adrese pošiljaoca, dok se kao odredišna koristi fizička broadcast adresa.
4. Obzirom da je okvir upućen na broadcast adresu, svi hostovi ili ruteri na mreži primaju okvir. Softver
sloja veze izdvaja ARP paket iz okvira i prosleđuje ga ARP-u. Sve mašine, osim ciljne, odbacuju paket.
Ciljna mašina prepoznaje svoju IP adresu i prihvata paket.
5. Ciljna mašina odgovara porukom tipa ARP odgovor, koji sadrži njenu fizičku adresu.
6. Pošiljalac prima ARP odgovor i koristi dobijenu fizičku adresu ciljne mašine kao odredišnu adresu za
okvir kojim će poslati IP datagram iz koraka 1.
Na Sl. 2-47 su prikazana četiri različite situacije u kojima se koristi ARP.

Sl. 2-47 Četiri slučaja korišćenja ARP-a.

Slučaj 1. Pošiljalac je host koji želi da pošalje datagram drugom hostu na istoj mreži. U ovom slučaju, logička
adresa koja se preslikava na fizičku je odredišna IP adresa iz zaglavlja datagrama.
Slučaj 2. Pošiljalac je host koji želi da pošalje datagram hostu na nekoj drugoj mreži. U ovom slučaju, host
pretražuje svoju tabelu rutiranja i za dato odredište pronalazi IP adresu sledećeg skoka (rutera). IP adresa rutera
postaje logička adresa koja se preslikava na fizičku adresu.
Slučaj 3. Pošiljalac je ruter koji je primio datagram namenjen hostu koji se nalazi na nekoj drugoj mreži. Ruter
pretražuje svoju tabelu rutiranja i za dato odredište pronalazi IP adresu sledećeg skoka (rutera). IP adresa
sledećeg rutera postaje logička adresa koja se preslikava na fizičku adresu.

42
Slučaj 4. Pošiljalac je ruter koji je primio datagram namenjen hostu u istoj mreži. Odredišna IP adresa
datagrama postaje logička adresa koju treba preslikati na fizičku adresu.
Keš tabela
Moguće su različite optimizacije opisane procedure, kako bi se ARP učinio efikasnijim. Prvo, svaki host koji
podržava ARP poseduje keš tabelu (tzv. ARP keš) koja sadrži parove adresa (IP adresa, fizička adresa) iz
skorašnje primljenih ARP odgovora. Na taj način, ako u bliskoj budućnosti hostu zatreba ista fizička adresa, on
će je naći u ARP tabeli, bez potrebe da ponovo šalje ARP upit.
Takođe, u mnogim slučajevima, komunikacija na IP nivou nije jednosmerna; ako host A šalje IP datagram hostu
B, gotov je izvesno da će u bliskoj budućnosti i host B poslati IP datagram hostu A. Emitovanje ARP upita od
strane hosta B kojim traži fizičku adresu hosta A može se izbeći ako host B, u svoj ARP keš, upiše par (Sender
EA, Sender IP) iz ranije primljenog ARP upita hosta A. Šta više, sve mašine na mreži, one koje su primile ARP
upit, ali nisu odgovorile, mogu takođe da unesu ovu stavku u svoje keš tabele.
Da se omogućila pomena fizičkih adresa (zamena NIC-a), stavke u keš tabeli treba da imaju ograničeno trajanje,
npr. nekoliko minuta, nakon čega zastarevaju i brišu se iz tabele.
RARP
RARP je protokol koji se koristi za pronalaženje logičke adrese mašine koja jedino zna svoju fizičku adresu.
Svakom hostu ili ruteru dodeljena je jedna ili više logičkih (IP) adresa, koje su jedinstvene i nezavisne od
njegovih fizičkih adresa. Host ili ruter mora da zna svoju sopstvenu IP adresu da bi mogao da kreira IP
datagrame, jer se ona koristi kao izvorna adresa u zaglavlju IP datagrama. IP adresa mašine se obično čuva u
konfiguracionom fajlu na hard-disku.
Međutim, postoje uređaji koji ne poseduju hard disk i čiji je operativni sistem u potpunosti smešten u
permanentnoj memoriji (ROM). ROM instalira proizvođač uređaja i njegov sadržaj se ne može naknadno
menjati. To znači da se u ROM-u ne može čuvati IP adresa, jer IP adrese dodeljuje administrator mreže prilikom
priključenja mašine na mrežu. Sa druge strane, ovakva jedna mašina može lako da sazna svoju fizičku
(hardversku) adresu (npr. može je pročitati iz svog mrežnog adaptera) i da je onda iskoristi da uz pomoć RARP-
a sazna i svoju IP adresu. Mašina kreira RARP upit i emituje ga (broadcast) na lokalnu mrežu. Neka druga
mašina (tzv. RARP server) na lokalnoj mreži koja zna IP adrese svih hostova i rutera na toj mreži odgovara
porukom tipa RARP odgovor ( Sl. 2-48).
Moja fizička adresa je
A4:6E:A5:57:82:36. RARP server
Tražim svoju IP adresu

RARP UPIT

Host ili ruter

(a)

(b)
Sl. 2-48 RARP: (a) RARP upit (broadcast); (b) RARP odgovor (unicast).
Sl. 2-48(a) prikazuje host bez hard diska koji je upravo startovan. Da bi saznao svoju IP adresu, host emituje
RARP upit svim sistemima u mreži. Ovaj paket prima svaki host (ili ruter) na fizičkoj mreži, ali na nju odgovara
samo RARP server. Server šalje RARP odgovor koji sadrži IP adresu hosta koji je uputio upit ( Sl. 2-48(b)).

43
Format
Format RARP paketa je identičan formatu ARP paketa (vidi Sl. 2-45), sa jedinom razlikom što su vrednosti u
polju OPERATION različite. Za RARP upit se koristi 0x0003, a za RARP odgovor 0x0004. Kao i ARP paket i
RARP paket se direktno enkapsulira u Ethernet okvir, a razlika u odnosu na Sl. 2-46 je u sadržaju polja Type
Ethernet okvira koje za RARP ima vrednost 0x8035.
Alternativna rešenja
RARP se danas smatra zastarelim protokolom. Mašini bez hard diska su osim IP adrese obično potrebne i
dodatne informacije, kao što je maska podmreže, IP adresa podrazumevanog rutera i drugi podaci neophodni za
normalno funkcionisanje mašine u konkretnoj mreži. RARP ne može da obezbedi ove dodatne informacije. Zato
su razvijeni novi protokoli kao što su BOOTP i DHCP, koji omogućavaju potpuno konfigurisanje mašina bez
hard diska.

2.4 Internet protokol (IP)

Internet protokol (IP) je centralni protokol mrežnog sloja TCP/IP modela. Savremeni Internet predstavlja
kolekciju međusobno povezanih podmreža. Ne postoji planska, uniformna, fiksna struktura, već okosnicu
Interneta čine nekoliko magistralnih (backbone) mreža povezanih pomoću komunikacionih linija velike
propusne moći i brzih rutera. Na backbone mreže povezane su regionalne, a na regionalne LAN mreže mnogih
univerziteta, kompanija i ISP-ova (Sl. 1-1). Zadatak Internet protokola je da mreže Internet-a ˝drži na okupu˝.
Zahvaljujući IP-u, mnoštvo fizički raznorodnih mreža objedinjeno je u jednu ogromnu mrežu. IP pravi utisak
kao da su svi hostovi povezani na tu veliku mrežu, a ne na svoje individualne fizičke mreže.
IP obezbeđuje best-effort (tj. negarantovani) servis za prenos podataka od izvora do odredišta, bez obzira da li se
mašine nalaze u istoj, susednim ili udaljenim mrežama. Best-effort znači da IP ne obezbeđuje proveru grašaka i
evidenciju o isporuci podataka. IP pretpostavlja da su niži slojevi nepouzdani i ˝daće sve od sebe˝ da podatke
isporuči na odredište, ali bez garancija. U toku prenosa, podaci mogu biti uništen na fizičkom nivou (npr. zbog
grešaka u prenosu nastalih usled električnih smetnji), ruter, zagušen saobraćajem, može odbaciti paket, linija
kojom paket treba da se prenese dalje može privremeno biti u prekidu. Ako je pouzdanost bitna, IP se mora
upariti sa pouzdanim transportnim protokolom (kao što je TCP).
IP je takođe beskonekcioni protokol za mreže sa komutacijom paketa koje koriste datagramski pristup. Kao što
znamo, to znači da se svaki datagram nezavisno prenosi i da svaki datagram može biti prenet do svog odredišta
različitim putanjama. Prenošeni različitim putanjama između istog para izvor-odredište datagrami mogu stići na
odredište izvan redosleda. Ponovi, IP se oslanja na protokole višeg nivoa da reše sve ove probleme.
Ograničenu funkcionalnost IP-a se ne treba smatrati njegovom slabošću. IP obezbeđuje bazični servis prenosa
podataka na daljinu; na korisniku je da po potrebi doda funkcije koje su neophodne za implementaciju svake
konkretne aplikacije.

2.4.1 Datagram
Paketi koji se prenose na IP nivou nazivaju se datagramima. Datagram je paket promenljive dužine (do 65535
bajta) i sastoji se iz dva dela: zaglavlje i podaci. Zaglavlje je podeljeno na polja koja sadrže informacije bitne za
rutiranje i isporuku datagrama. Format zaglavlja prikazan je na Sl. 2-49. Veličina zaglavlja je najmanje 20, a
najviše 60 bajta. Prvih dvadeset bajtova u zaglavlju su fiksni (uvek postoje); opcioni deo (IP OPTIONS) je
promenljive dužine od 0 do 40 bajtova. Kod TCP/IP protokola uobičajeno je da se formati zaglavlja prikazuju
podeljeni na 4-bajtne sekcije. Datagram se prenosi u ˝big-endian˝ poretku: s leva na desno, sa krajnjim levim
bitom polja VERS na početku. Sledi kratak opis polja zaglavlja.

Sl. 2-49 Format IP datagrama.

VERS (Verzija). Četvorobitno polje koje definiše verziju IP protokola. Aktuelna verzija je 4 (IPv4), kojoj u
ovom polju odgovara binarna vrednost 0100. Postojanje broja verzije u svakom datagramu olakšava prelazak na

44
novu verziju IP protokola (omogućava da neke mašine podržavaju samo staru, a druge samo novu ili obe verzije
protokola). Trenutno je aktuelan prelaz sa IPv4 na IPv6, koji traje već godinama, i trajaće još dugo vremena.
HLEN (Header Length - dužina zaglavlja). Pošto veličina zaglavlja nije konstantna, u samom zaglavlju
predviđeno je polje HLEN, koje definiše dužinu zaglavlja izraženu brojem 32-bitnih reči (4-bajta). Minimalna
vrednost je 5 (opcije ne postoje), a maksimalna 15 (polje za opcije postoji i maksimalne je dužine).
SERVICE TYPE (Tip servisa). Polje veličine jednog bajta koje definiše kako će datagram biti tretiran od
strane rutera. Pojedinačni bitovi ovog polja definišu prioritet datagrama, nivo pouzdanosti i kašnjenja koje
pošiljaoca datagrama očekuje od rutera. Međutim, u praksi, ruteri najčešće ignorišu ovo polje.
TOTAL LENGTH (Ukupna dužina) definiše veličinu IP datagrama (zaglavlje plus podaci) izraženu u
bajtovima. Veličina ovog polja je 16 bita, što znači da veličina datagrama može biti maksimalno 65535 bajta
(216-1). Broj bajtova podataka koji se prenose datagramom može se odrediti tako što će se od TOTAL LENGTH
oduzeti veličina zaglavlja (4 x HLEN). Kada kasnije u ovoj sekciji budemo razmatrali fragmentaciju, videćemo
da pojedine fizičke mreže ne mogu enkapsulirati datagram od 65535 u njihov okvir. U takvim slučajevim, da bi
se ostvario prenos, neophodno je izvršiti fragmentaciju datagrama.
IDENTIFICATION (Identifikacija) 16-bitno polje koje se koristi prilikom fragmentacije datagrama.
FLAGS (Polje za markere). Trobitno polje koje se takođe koristi prilikom fragmentacije datagrama.
FRAGMENT OFFSET (Pomeraj fragmenta) 13-bitno polje koje se koristi, kao i prethodna dva, prilikom
fragmentacije datagrama.
TIME TO LIVE (Vreme života) je brojač koji se koristi da bi se ograničilo vreme života datagrama. Vrednost
ovog polja se umanjuje za 1 u svakom ruteru kroz koji datagram prolazi. Ako Vreme života dostigne 0 pre nego
što datagram stigne do odredišta, datagram se uništava. Na ovaj način sprečava se da datagram ostane zarobljen
u mreži, lutajući od rutera do rutera, zbog npr. greške u tabelama rutera.
PROTOCOL (8 bita) ukazuje na protokol višeg nivoa koji koristi usluge IP sloja. IP datagram može da
enkapsulira podatke iz više protokola višeg nivoa, kao što su UDP, TCP, ICMP i IGMP. Ovo polje definiše
kojem se isporučuje sadržaj IP datagrama. Vrednosti ovog polja, za različite protokole višeg nivoa navedene su
u tabeli T. 2-4.
T. 2-4 Protokoli
Vrednost Protokol
1 ICMP
2 IGMP
6 TCP
17 UDP
89 OSPF
HEADER CHECKSUM (Kontrolna suma zaglavlja) je 16-bitno polje koje se koristi za verifikaciju zaglavlja
(ne celog paketa). Način izračunavanja kontrolne sume biće objašnjen kasnije u ovoj sekciji.
Polja SOURCE IP ADDRESS i DESTINATION IP ADDRESS (Adresa izvora i Adresa odredišta) sadrže
32-bitne mrežne (IP) adrese izvornog hosta (host koji je poslao datagram) i odredišnog hosta (krajnje odredište
datagrama). Ove adrese ostaju neizmenjene u svim fragmentima na koje se datagram eventualno deli u toku
prenosa.

2.4.2 Fragmentacija
Na putu do svog krajnjeg odredišta, datagram može proći kroz više različitih mreža. Svaki ruter izdvaja IP
datagram iz primljenog okvira, obrađuje ga i ponovo enkapsulira u okvir kojeg šalje sledećem ruteru ili
odredišnom hostu. Format i veličina primljenog okvira zavisi od protokola sloja veze koji se koristi na fizičkoj
mreži preko koje je okvir stigao u ruter. Format i veličina okvira kojeg ruter šalje zavisi od protokola sloja veze
koji se koristi na fizičkoj mreži preko koje okvir dalje nastavlja svoj put. Na primer, ako ruter povezuje LAN na
WAN, on prima okvir u LAN formatu, a šalje ga u WAN formatu.
MTU
Svaki protokol sloja veze definiše format svog okvira. Ograničenje koje uvek postoji jeste maksimalna veličina
polja za podatke u okviru (tzv. MTU - Maximum Transfer Unit - najveća jedinica prenosa). Drugim rečima,
kada se datagram enkapsulira u okvir, ukupna veličina datagrama mora biti manja od ove maksimalne veličine,
koja je definisana ograničenjima nametnutim hardverom i softverom koji se koriste u mreži. Vrednost MTU
parametra se razlikuje od jedne do druge fizičke mreže (T. 2-5).

45
 T. 2-5 MTU kod nekoliko standardnih mreža.
Protokol MTU
Hyperchannel 65,535
TokenRing (16 Mbps) 17,914
TokenRing (4 Mbps) 4,464
FDDI 4,352
Ethernet 1,500
X.25 576
PPP 296
Da bi se IP protokol učinio nezavisnim od fizičke mreže, projektanti IP protokola su odlučili da maksimalna
veličina IP datagrama bude jednaka 65,535 bajta. Na taj način, prenos je efikasniji ako se koristi mreža sa MTU
ovo veličine. Međutim, za ostale fizičke mreže, sa manjim MTU, datagram se mora podeliti na manje celine
kako bi mogao biti prenet kroz mrežu. Ova podela se naziva fragmentacijom.
Nakon izvršene fragmentacije, svaki fragment (koji je takođe datagram) ima svoje zaglavlje u kome su većina
polja iz prvobitnog datagrama ponovljena, ali su neka i promenjena. Fragmentirani datagram i sam može biti
fragmentiran, ako naiđe na mrežu sa još manjim MTU-om. Drugim rečima, datagram može biti fragmentiran
nekoliko puta dok ne stigne na odredište.
Datagram može biti fragmentiran od strane bilo kog rutera na putanji. Međutim, rekonstrukciju prvobitnog
datagrama od fragmentiranih delova obavlja isključivo odredišni host. Ovo ograničenje je logično, jer se ne
može garantovati da će svi fragmenti istog datagrama proći istom putanjom do odredišta.
Kada se datagram fragmentira, obavezni delovi zaglavlja moraju biti kopirati u zaglavlja svih kreiranih
fragmenata. Polje za opcije može ali i ne mora biti identično onome iz prvobitnog datagrama. Host ili ruter koji
obavlja fragmentaciju, mora promeniti vrednosti tri polja: FLAGS, FRAGMENTATION OFFSET i TOTL
LENGTH. Naravno, vrednost polja za kontrolnu sumu se mora ponovo izračunati, bez obzira da li se datagram
fragmentira ili ne. Sledeća tri polja zaglavlja IP datagrama se koriste u fragmentaciji:
IDENTIFICATION (Identifikacija) 16-bitno polje koje identifikuje datagrame koji potiču iz istog izvora.
Kombinacija izvorne IP adrese i vrednosti polja za identifikaciju na jedinstveni način definiše datagram kada on
napusti izvorni host. Da bi se obezbedila jedinstvenost, IP protokol koristi brojač za označavanje datagrama.
Uvek kada šalje datagram, IP protokol izvornog hosta kopira tekuću vrednost ovog brojača u polje za
identifikaciju, a zatim uvećava brojač za 1. Ako se datagram fragmentira, vrednost polja za identifikaciju se
kopira u sve fragmente. Drugim rečima, svi fragmenti nastali podelom jednog datagrama imaće istu vrednost u
polju za identifikaciju kao i polazni datagram. Na taj način, odredišnom hostu je omogućeno da odredi kom
datagramu upravo pristigli fragment pripada. Host zna da sve fragmente sa istom vrednošću za identifikaciju i
istom izvornom IP adresom treba da objedini u jedan datagram.
FLAGS (Polje za markere). Sadrži tri bita. Prvi bit je neiskorišćen (nema definisanu namenu). Drugi bit, DF,
postavljen ne vrednost 1 znači Don´t Framgment (ne fragmentiraj) i predstavlja instrukciju ruteru da datagram
nije dozvoljeno fragmentirani (zato što npr. odredište nije sposobno da obavi rekonstrukciju datagrama).
Postavljajući DF na 1, pošiljalac je siguran da će datagram stići do odredišta ˝u jednom komadu˝ (čak iako to
znači da će datagram do odredišta stići nekim zaobilaznim putem, izbegavajući male mreže, koje nisu u
mogućnosti da ga prenesu u okviru jednog okvira). Ako ruter ne može da prosledi datagram ni kroz jednu od
raspoloživih fizičkih mreža, ruter će uništiti datagram, a izvorno hostu će poslati ICMP poruku sa obaveštenjem
o grešci (videti sledeću sekciju). Bit DF postavljen na 0 označava da je datagram dozvoljeno fragmentirati. Treći
bit polja FLAGS, MF (More Fragments) postavljen na vrednost 1 ukazuje da datagram nije poslednji fragment
nekog većeg datagrama; postoji jedan ili više fragmenata koji slede. Ako bit MF ima vrednost 0, to znači da je
ovaj datagram poslednji fragment nekog većeg datagrama ili se radi o datagramu koji nije fragmentiran.
FRAGMENT OFFSET (Pomeraj fragmenta) (13 bita) definiše poziciju ovog fragmenta u okviru celokupnog
datagrama. Predstavlja pomak (offset) podataka u prvobitnom datagramu izražen u jedinicama od po 8 bajta. Na
Sl. 2-50 je prikazan datagram sa podacima veličine 4000 bajta podeljen na tri fragmenta. Bajtovi u polaznom
datagramu su numerisani sa 0 do 3999. Prvi fragment sadrži bajtove 0 do 1399. Pomak kod ovog datagrama je
0/8 = 0. Drugi fragment prenosi bajtove 1400 do 2799; vrednost njegovog pomaka je 1400/8 = 175. Konačno,
treći fragment sadrži bajtove 2800 do 3999, a njegov pomak je 2800/8 = 350.

46
 Sl. 2-50 Primer fragmentacije.
Na Sl. 2-51 je dat detaljniji prikaz fragmentiranih datagrama sa prethodne slike. Uočimo da polje za
identifikaciju kod svih fragmenata sadrži istu vrednost. Uočimo, takođe, da bit MF ima vrednost 1 kod svih
fragmenta, osim kod poslednjeg. Vrednosti polja FRAGMENT OFFSET su takođe prikazane.

Sl. 2-51 Detaljniji primer fragmentacije.

Sl. 2-51 takođe prikazuje šta se dešava ako se fragment fragmentira. U ovom slučaju, vrednost pomaka se računa
u odnosu na polazni datagram, a ne u odnosu na fragment koji se deli. Kao što možemo videti na Sl. 2-51, drugi
fragment je fragmentiran na dva nova fragmenta od 800 i 600 bajta. Pomaci novonastalih fragmenata pokazuju
relativnu poziciju sadržanih podataka u odnosu na prvobitni datagram.

2.4.3 Opcije
Zaglavlje IP datagrama se sastoji iz dva dela: fiksnog i promenljivog. Fiksni deo, dužine 20 bajta, smo već
obradili. Promenljivi deo, maksimalne dužine 40 bajta, rezervisan je za tzv. opcije. Opcije, kao što i samo ime
sugeriše, nisu obavezne. Opcije se koriste za testiranje i debagiranje mreže. Pri normalnom prenosu podataka,
zaglavlje IP datagrama ne sadrži ovo polje.
Format
Deo za opcije, ako postoji, može sadržati jednu ili više opcija. Sve opcije imaju identičan format, koji je
prikazan na Sl. 2-52. Opcija se sastoji iz tri polja: 1-bajtno polje za kôd (Code), 1-bajtno polje za dužinu (Length)
i polje za podatke (Data) promenljive dužine.

47
 Code Length Data
8 bita 8 bita Promenljive dužine

Copy Class Number

1 bita 2 bita 5 bita

Sl. 2-52 Format opcije.

Code. Polje za kôd opcije sadrži 8 bita i podeljeno je tri podpolja: Copy, Class i Number.
Copy. Ovo jednobitno podpolje kontroliše prisustvo opcije u fragmentima. Ako je ovaj bit postavljen
na 0, tada opcija sadržana u polaznom datagramu mora biti kopirana samo u njegov prvi fragment. Za
vrednost 1, opcija se kopira u svim fragmentima.
Class. Ovo 2-bitno podpolje definiše opštu namenu opcije. Vrednost 00 u ovom polju ukazuje na
opciju koja se koristi za kontrolu datagrama. Vrednost 10 ukazuje na opciju koja se koristi za
debagiranje i menadžment mreže. Značenje dve preostale vrednosti , 01 i 11, još uvek nije definisano.
Number. Ovo 5-bitno podpolje definiše tip opcije. Mada se sa 5 bita može definisati do 32 različita
tipa, u upotrebi su samo 6.
Lenght. Ovo polje definiše ukupnu dužinu opcije uključujući i polja kôd i dužinu. (Nije prisutno kod svih opcija)
Data. Ovo polje sadrži podatke specifične za konkretnu opciju. (Nije prisutno kod svih opcija).
Tipovi opcija
Kao što je napomenutu, trenutno su u upotrebi šest opcija. Dve opcije su 1-bajtne (sastoje se samo od polja za
kôd), dok su preostale četiri više-bajtne (sadrže sva tri polja). Sledi kratak opis opcija:
No Operation. Ovo je 1-bajtna opcija koja se koristi za popunu nepopunjenih bajtova između opcija,
kada datagram sadrži više od dve opcije. Na primer, može se koristiti za poravnanje sledeće opcije,
tako da ona počne od naredne 16-bitne ili 32-bitne reči.
End of Options (Kraj opcija). Ovo je takođe 1-bajtna opcija koja se koristi za dopunu polja za opcije,
kako bi ono zauzimalo celi broj 16-bitnih ili 32-bitnih reči. U polju za opcije se može nalaziti samo
jedna end of operation opcija, a može se koristiti sam kao poslednja opcija. U slučajevima kada je za
poravnanje potrebno više od jednog bajta, na kraj polja za opcije može se umetnuti više no operation i
jedna end of options opcija.
Record route (snimanje putanje). Ova opcija se koristi za snimanje putanje kojom se datagram prenosi
kroz Internet. U polju za podatke ove opcije može se smestiti do devet IP adresa rutera kroz koje je
datagram prošao (najviše devet zbog ograničenja dužine polja za opcije na 40 bajta). Izvorni host
rezerviše mesta (stavke) u polju za opcije koja će popunjavati ruteri koje datagram poseti. Format ove
opcije prikazan je na Sl. 2-53. Polje pointer ukazuje na prvu slobodnu stavku, tj. sadrži redni broj prvog
slobodnog bajta (brojano od početka polja za opcije). Kada datagram napusti izvorni host, sve stavke su
prazne, a pointer ima vrednost 4. Svaki ruter koji obrađuje datagram, poredi vrednost pointera sa
vrednošću polja za dužinu. Ako je vrednost pointera veća od vrednosti polja za dužinu, polje za opcije
je popunjeno, a nova stavka se ne upisuje. U suprotnom, ako u polju za opcije još uvek ima slobodnog
prostora, ruter upisuje IP adresu pridruženu mrežnom adapteru kroz koji će datagram biti poslat dalje,
počev od pozicije na koju ukazuje pointer i uvećava vrednost pointera za 4. Na ovaj način, analizom
zaglavlja na strani odredišnog hosta, može se rekonstruisati putanja kojom je datagram prenesen.
Code Length
Pointer
00000111 (Ukupna dužina)
Prva IP adresa
(prazno na početku)
Druga IP adresa
(prazno na početku)
.
.
.
Poslednja IP adresa
(prazno na početku)

Sl. 2-53 Opcija za snimanje putanje.

Strict Source Route (Striktno rutiranje na izvoru). Ovu opciju može da koristi izvorni host kako bi
unapred odredio putanju datagrama kroz Internet, navodeći IP adrese rutera koje datagram mora da
poseti. Ako ova opcija postoji u datagramu, svi navedeni ruteri moraju biti posećeni. Ako datagram

48
 dospe u ruter koji nije na listi, datagram se uništava, a izvornom hostu se šalje ICMP poruka o grešci.
Striktno rutiranje koristi isključivo administratori mreže za testiranje i debagiranje mreže. Za normalni
prenos podataka, izbor putanje se prepušta ruterima. Format ove opcije sličan je formatu opcije record
route, ali sada stavke popunjava izvorni host IP adresama rutera.
Loose Source Route (Približno rutiranje na izvoru) Ova opcija je slična opciji striktnog rutiranja na
izvoru ali sa nešto blažim zahtevima. Svaki ruter u listi mora biti posećen, ali datagram može posetiti i
neke druge rutere. Format i način korišćenja je sličan kao kod prethodne opcije.
Timestamp (Vremenski zapis). Ova opcija se koristi za beleženje vremena kada su ruteri procesirali
datagram. Vreme se izražava u milisekundama počev od ponoći. Poznavanje ovog vremena pomaže
administratorima mreže da prate ponašanje rutera na Internetu. Na primer, uz pomoć ovih informacija
moguće je proceniti vreme koje je bilo potrebno da datagram pređe iz jednog u drugi ruter. Format
opcija vremenskog zapisa prikazan je na Sl. 2-54. Polja za kôd i dužinu imaju isto značenje kao i ranije.
U polju Overflow pamti se broj rutera koji nisu uspeli da upišu svoj vremenski zapis zato što više nije
bilo slobodnog prostora u polju za opcije. U polju Flags definisane su odgovornosti rutera (definisano
je šta se očekuje od rutera). Ako je vrednost ovog polja 0, svaki ruter upisuje samo vremenski zapis u
odgovarajuću stavku. Za vrednost 1, svaki ruter upisuje pored vremenskog zapisa i svoju odlaznu IP
adresu. Za vrednost 3, IP adrese su unapred postavljene od strane izvornog hosta; svaki ruter proverava
odgovarajuću IP adresu sa svojom dolaznom IP adresom i, ako utvrdi da su jednake, zamenjuje je
svojom odlaznom IP adresom i upisuje vremenski zapis.

Sl. 2-54 Opcija vremenskog zapisa.

2.4.4 Kontrolna suma

Kod većine TCP/IP protokola za kontrolu grešaka se koristi metod koji se naziva kontrolnom sumom
(checksum). Kontrolna suma predstavlja redundantnu informaciju koja se dodaje paketu radi zaštite od grešaka
koje mogu nastati u toku prenosa paketa. Kontrolna suma se izračunava na strani pošiljaoca paketa, a dobijena
vrednost se šalje zajedno sa paketom. Prijemnik ponavlja isto izračunavanje nad celim paketom, uključujući i
polje za kontrolnu sumu. Ako je rezultat zadovoljavajući, paket se prihvata; ako nije, pakete se odbacuje.
Izračunavanje kontrolne sume na strani pošiljaoca
Na strani pošiljaoca, paket se deli na n-bitne sekcije (n je obično 16 bita). Sve sekcije se sabiraju korišćenjem
pravila sabiranja binarnih brojeva u jediničnom komplementu. Rezultat je n-to bitna suma. Nakon toga, suma se
komplementira i upisuje u polje za kontrolnu sumu.
Izračunavanje kontrolne suma na strani primaoca
Primalac deli primljeni paket na n-bitne sekcije. Sve sekcije se sabiraju, a dobijeni rezultat komplementira. Ako
je konačni rezultat 0, paket se prihvata kao ispravan; inače, ako se dobije vrednost različita od 0, paket se
odbacuje, kao neispravan.
Sl. 2-55 na grafički način prikazuje procedure izračunavanja kontrolne sume na strani pošiljaoca i strani
prijemnika.

49
 Sl. 2-55 Koncept kontrolne sume.
Kao što znamo, za brojeve u formatu jediničnog komplementa operacija komplementiranja identična je promeni
znaka (komplement od T je -T). Pretpostavimo da smo sabiranjem sekcija na strani pošiljaoca dobili vrednost T.
Nakon komplementiranja dobija se -T, što predstavlja vrednost kontrolne sume koja se šalje prijemniku. Sa
druge strane, prijemnik sabira sve sekcije i ako nema grešaka u prenosu dobija sumu jednaku T + (-T) (T za sva
polja osim kontrolne sume i -T za polje kontrolne sume). Rezultat će biti ˝sve 1-ce˝, odnosno -0, što nakon
komplementiranja postaje 0 (˝sve nule˝).
Kontrolna suma u IP datagramu
Kontrolna suma za IP datagram se izračunava shodno prethodno opisanoj proceduri. Prvo, polje u zaglavlju
datagrama predviđeno za kontrolnu sumu se postavlja na ˝sve nule˝. Zatim se celokupno zaglavlje deli na 16-
bitne sekcije, koje se potom sabiraju. Rezultujuća suma se komplementira i umeće u polje za kontrolnu sumu.
Kontrolna suma kod IP datagrama pokriva samo zaglavlje, a ne i podatke. Postoje dva razloga za to. Prvo, svi
protokoli višeg nivoa koje se prenose IP datagramom poseduju svoje polje za kontrolnu sumu koja pokriva
celokupan paket. Zahvaljujući tome, nema potreba da se kontrolnom sumom IP datagrama proveravaju i
enkapsulirani podaci. Drugo, prolaskom kroz svaki ruter, zaglavlje IP datagrama se modifikuje, ali ne i podaci.
Dakle, kontrolna suma uključuje samo one delove datagrama koji se menjaju u prenosu.
Pr. 2-24: Izračunavanje kontrolne sume
Na Sl. 2-56 je prikazan primer izračunavanja kontrolne sume za IP zaglavlje koje ne sadrži opcije. Zaglavlje je
podeljeno na 16-bitne sekcije; sve sekcije su sabrane; zbir je komplementiran i konačni rezultat umetnut u polje
za kontrolnu sumu.
4 5 0 28
1 0 0
4 17 0
10.12.14.5
12.6.7.9

4,5 i 0 01000101 00000000

28 00000000 00011100
1 00000000 00000001
0 i 0 00000000 00000000
4 i 17 00000100 00010001
0 00000000 00000000
10,12 00001010 00001100
14,5 00001110 00000101
12,6 00001100 00000110
7,9 00000111 00001001

Suma 01110100 01001110

Kontrolna suma 10001011 10110001

Sl. 2-56 Primer izračunavanja kontrolne sume.

50
2.5 NAT
Privatne mreže su mreže koje koriste TCP/IP ali su izolovane od Interneta. Privatna mreža može sadržati od
nekoliko do nekoliko stotina računara, a njihova glavna namena je deoba zajedničkih resursa unutar jedne
organizacije, kao što su baze podataka, štampači i dr. Kao što je ranije napomenuto, hostovima u privatnim
mrežama dodeljuju se IP adrese iz nekoliko za tu namentu rezervisanih opsega (tzv. privatne IP adrese, vidi
tabelu T. 2-3). Čak iako je privatna mreža ruterom povezana sa globalnim Internetom, ona će ostati izolovana jer
će ruter onemogućiti izalazak datagrama koji nose privatne IP adrese izvan mreže.
Tehnika prevođenja mrežnih adresa (Network Address Translation - NAT) omogućava hostovima iz privatne
mreže da komuniciraju sa sajtovima na globalnom Internetu. Preduslov je da sajt mora imati jednu konekciju ka
globalnom Interentu posredstvom rutera na kome se izvršava NAT softver (Sl. 2-57).

Sl. 2-57 NAT.

Kao što se može videti na Sl. 2-57, hostovima iz privatne mreže dodeljene su privatne adrese. Ruter poseduje
jednu privatnu adresu, ka privatnoj mreži, i jednu globalnu adresu, ka ostatku Internetu. Gledano sa strane
Interneta, pojedinačni hostovi u privatnoj mreži nisu vidljivi, već je vidljiv samo NAT ruter sa adresom
200.24.5.8.
Prevođenje adresa
Na Sl. 2-58 je ilustrovan osnovni koncept prevođenja adresa. NAT ruter modifikuje svaki paket koji napušta
privatnu mrežu, tako što izvornu adresu u paketu zamenjuje svojom NAT adresom (200.24.5.8). Svaki paket
koji iz Interneta dolazi u privatnu mrežu, takođe prolazi kroz NAT ruter, koji sada odredišnu adresu u paketu (a
to je globalna adresa NAT rutera) zamenjuje odgovarajućom odredišnom privatnom adresom. Na ovaj način,
iako u isto vreme više hostova iz privatne mreže mogu komunicirati sa različitim hostovima na Interetu, hostovi
sa Interneta imaju utisak da komuniciraju samo sa jednim hostom, čija je IP adresa NAT adresa rutera.
172.18.3.1
Izvor: 172.18.3.1 Izvor: 200.24.5.8

Internet

Odredište: 172.18.3.1 Odredište: 200.24.5.8

Sl. 2-58 Prevođenje adresa.

Prevođenje adresa za odlazne pakete je trivijalno. Ali, postavlja se pitanje kako NAT ruter zna kom privatnom
hostu je namenjen paket koji dolazi sa Interneta da bi shodno tome u polju za odredišnu adresu dolaznog paketa
upisao baš njegovu privatnu adresu. Ovaj problem se rešava tako što NAT ruter kreira tabelu prevođenja koja
uspostavlja vezu između privatnih i eksternih adresa.
Korišćenje jedne IP adrese
U najjednostavnijem obliku, tabela prevođenja ima samo dve kolone: privatnu adresu i eksternu adresu
(odredišne adrese paketa). Kada ruter zamenjuje izvornu adresu odlaznog paketa svojom adresom, on takođe
upisuju u tabelu prevođenja na koju odredišnu (eksternu) adresu je paket upućen. Kada kasnije od odredišta
stigne odziv, ruter, na osnovu izvorne adrese paketa (eksterna adresa) u tabeli prevođenja pronalazi privatnu
adresu hosta koji se prethodno obratio tom eksternom odredištu. Opisana ideja ilustrovana je na Sl. 2-59.
Uočimo da NAT tehnika pretpostavlja da komunikaciju prema Internetu uvek inicira host iz privatne mreže. To
praktično znači da korisnici iz prvatne mreže u komunikaciji prema Internetu mogu imati isključivo ulogu
klijenta. Na primer, korisnici iz privatne mreže mogu koristiti Web preko Web pretraživača (program kao što je
Internet Explorer) jer je pretraživač klijentski program koji obraća Web serveru tražeći od njega Web stranicu.
Međutim, u privatnoj mreži ne mogu postojati serverske aplikacije vidljive klijentima izvan privatne mreže. Na

51
primer, privatna mreža ne može imati Web server pokrenut na nekom inernom Hostu koji će biti vidljiv za
eksterne klijente.

Odredište: 25.8.2.10 Odredište: 25.8.2.10

Izvor: 172.18.3.1 Izvor: 200.24.5.8

Privatna adresa Eksterna adresa

172.18.3.1 25.8.2.10
. .
. .
. .

Odredište: 172.18.3.1 Odredište: 200.24.5.8

Izvor: 25.8.2.10 Izvor: 25.8.2.10

Sl. 2-59 Prevođenje.

Korišćenje više IP adresa
Prevođenje adresa koje se oslanja na koršćenju samo jedne globalne adrese (kao na Sl. 2-59) onemogućava da sa
istim eksternim hostom, u isto vreme, komuniciraju dva ili više internih hostova. Da bi se ovo ograničenje
otklonilo NAT ruter, može koristiti više globalnih adresa. Na primer, umesto da koristi samo jednu globalnu
adresu (200.24.5.8) NAT ruter može koristiti četiri (200.24.5.8, 200.24.5.9, 200.24.5.10 i 200.24.5.11). Sa ovim
proširenjem, četiri privatna hosta mogu u isto vreme komunicirati sa istim eksternim hostom. Međutim, izvesna
ograničenja i dalje postoje. Na primer, prema istom eksternom hostu iz privatne mreže nije moguće uspostaviti
više od četiri veze. Takođe, host iz privatne mreže ne može u isto vreme da komunicra sa dva serverska
programa (npr. FTP i TELNET) pokrenuta na istom eksternom hostu.
Korišćenje IP adresa i adresa portova
Radi uspostavljanja relacije više-ka-više između hostova iz privatne mreže, sa jedne i hostova na Internetu, sa
druge strane, neophodno je u tabelu prevođenja uvrstiti dodatne informacije. Na primer, pretpostavimo da dva
interna hosta, sa privatnim adresama 172.18.3.1 i 172.18.3.2, žele da pristupe istom Web serveru na eksternom
hostu sa adresom 25.8.3.2. Za komunikaciju sa Web serverom se koristi aplikacioni protokol HTTP koji se
oslanja na transportni protokol TCP i dostupan je preko adrese porta 80. Ako tabela prevo đenja umesto dve
sadrži pet kolona sa dodatnim kolonama za izvorne i odredišne adrese portova i oznaku protokola transportnog
protokola koji se koristi u komunikaciji, nejednoznačnost u prevođenju adresa biće eliminisana (vidi T. 2-6).
Uočimo da kada se NAT ruteru vrati odziv od Web serera, kombinacija izvorne adrese (25.8.3.2) i odredišne
adrese porta (1400) jednoznačno definiše host u privatnoj mreži kome odziv treba biti isporučen. (Za više
informacija o adresama portova i TCP protokolu pogledati poglavlje 3.)
T. 2-6 Tabela prevođenja sa pet kolona.
Privatna Privatni Eksterna Eksterni Transportni
adresa port adresa port protokol
172.18.3.1 1400 25.8.3.2 80 TCP
172.18.3.2 1401 25.8.3.2 80 TCP
... ... ... ... ...

NAT i ISP
ISP koji pruža usluge Internet pristupa dail-up korisnicima može koristiti NAT radi racionalnijeg korišćenja
svojih IP adresa. Na primer, pretpostavimo da neki ISP poseduje 1000 IP adresa (globalnih) i opslužuje 100,000
korisnika. Svakom korisniku je dodeljena jedna privatna adresa. ISP prevodi svaku od 100,000 izvornih adresa u
odlaznim paketima u jednu od 1000 globalnih adresa, odnosno globalnu odredišnu adresu u dolaznim paketima
u odgovarajuću privatnu adresu. Opisani koncept je ilustrovan na Sl. 2-60.

52
 Sl. 2-60 ISP i NAT.

2.6 ICMP
IP je mrežni protokol koji obezbeđuje negarantovanu (best-effort) isporuku datagrama od izvornog do
odredišnog hosta, osmišljen na način da obezbedi efikasno korišćenje mrežnih resursa. Međutim, IP protokolu
nedostaju mehanizmi za kontrolu grešaka i pomoć u menadžmentu mreže.
IP ne poseduje mehanizme za obaveštavanje o nastalim greškama ili korekciju grešaka. Na primer, šta će se
desiti ako ruter mora da uništi datagram zato što nije u stanju da nađe putanju do njegovog krajnjeg odredišta, ili
zato što je vreme života datagrama isteklo. Ili, šta će se desiti ako odredišni host mora da uništi primljene
fragmente nekog datagrama ako u definisanom vremenu nije primio sve fragmente tog datagrama. Ovo su sam
oneki od problema koji mogu nastati u komunikaciji na IP nivou, a kojima se IP ne bavi niti poseduje
odgovarajuće ugrađene mehanizme kojima bi barem obavestio izvorni host o njihovom nastanku.
Takođe, IP ne poseduje podršku za postavljaje upita kojima bi se olakšalo dijagnosticiranje kvarova i problema
u radu mreže. Na primer, povremeno se javlja potreba za ispitivanjem da li je neki ruter ili host operativan, ili
potreba da se od hosta ili rutera pribave neke specifične informacije.
ICMP (Internet Control Message Protocol) je zamišljen kao kompenzacija za pomenute nedostatke IP-a. U
suštini, ICMP obezbeđuje povratne informacije o problemima nastalim u mreži. U većini slučajeva ICMP
poruku šalje ruter ili odredišni host nazad izvornom hostu kao reakciju na problem nastao prilikom procesiranja
datagrama.
ICMP spada u grupu mrežnih protokola (kao i IP). Međutim, njegove poruke se ne prosleđuju direktno sloju
veze kao što bi se očekivalo. Umesto toga, ICMP poruke se najpre enkapsuliraju u IP datagrame pre nego što se
predaju nižim slojevima (Sl. 2-61). Obzirom da se ICMP poruke prenose u IP datagramima, nihova isporuka nije
garantovana i njihova upotreba se ne može smatrati pouzdanom.

Sl. 2-61 Enkapsulacija ICMP poruka.

Tipovi ICMP poruka
ICMP poruke se mogu klasifikovati u dve grupe: izveštaji o greškama i upit. Poruke prve kategorije koriste
ruteri ili hostovi (odredišni) a za slanje obaveštenja o neočekivanim događajima u toku procesiranja datagrama.
Sa druge strane, poruke upita uvek idu u paru i pomažu hostu ili administratoru mreže da od rutera ili drugog
hosta pribavi neke specifične informacije. Spisak poruka obe kategorije dat je u tabeli T. 2-7.

53
 T. 2-7 ICMP poruke
Kategorija Tip Poruka
Nedostupno odredište
3
(DESTINATION UNREACHABLE)
Prigušenje izvora
4
(SOURCE QUENCH)
Izveštaji Isteklo vreme
11
o greškama (TIME EXCEEDED)
Problem sa parametrima
12
(PARAMETER PROBLEM)
Preusmeravanje
5
(REDIRECTION)
Eho ili odziv na eho
8 ili 0
(ECHO / ECHO REPLY)
Vremenski zapis, zahtev ili odgovor
Upit 13 ili 14
(TIMESTAMP REQUEST / TIMESTAMP REPLY)
Adresna maska, zahtev ili odgovor
17 ili 18 (ADDRESS MASK REQUEST / REPLY)

Format ICMP poruke

ICMP poruka se sastoji iz 8-bajtnog zaglavlja i polja za podatke promenljive dužine. Mada, format zaglavlja
zavisi od tipa poruke, 4 prva bajta su ista za sve tipove (Sl. 2-62). Prvo polje zaglavlja (Type) definiše tip poruke.
Drugo polje (Code) se koristi za parametre poruke koji se mogu predstaviti jednim ili sa nekoliko bita. Poslednje
zajedničko polje (Checksum) se koristi za kontrolnu sumu poruke. Ostatak zaglavlja je specifičan za svaki tip
poruke. Kod izveštaja o greškama, sekcija za podatke sadrži informacije na osnovu kojih je moguće
identifikovati datagram koji je doveo do greške. Kod upita, sekcija za podatke sadrži dodatne informacije koje
zavise od tipa upita.

Sl. 2-62 Uopšteni format ICMP poruke.

Izveštaji o greškama
Jedna od glavnih odgovornosti ICMP-a je da izveštava o greškama. Iako napretkom tehnologije, prenosni
medijumi postaju sve pouzdaniji, greške u prenosu i dalje postoje i moraju se obrađivati na odgovarajući način.
Kao što je više puta do sada naglašeno, IP je nepouzdan protokol. Drugim rečima, IP nije odgovoran za proveru
i kotrolu grešaka. ICMP je delom projektovan da nadomesti ovu nepotpunost IP-a. Međutim, ni ICMP ne
ispravlja greške, već samo izveštava o njima. ICMP uvek šalje izveštaje o greškama izvoru (prvobitnom
pošiljaocu) datagrama. (To je iz razloga što su u datagramu, kao jedine informacije o njegovoj putanji, dostupne
samo izvorna i odredišna IP adresa.) Dakle, ICMP koristi izvornu IP adresu za slanje izveštaja o grešci izvoru
datagrama.
ICMP obrađuje 5 tipova grešaka: nedostupno odredište (destination unreachable), prigušenje izvora (source
quench), isteklo vreme (time exceeded), problemi sa parametrima (parameter problems) i preusmeravanje
(redirection). Formati svih pet odgovarajući ICMP poruka prikazani su na Sl. 2-63.

(a) (b) (c)

Sl. 2-63 Formati ICMP poruka za izveštavanje o greškama.
Uočimo da sve poruke o greškama, u sekciji za podatke, sadrže zaglavlje IP datagrama koji je izazvao grešku
plus 8 bajtova podataka iz tog datagrama (Sl. 2-64). IP zaglavlje je uključeno iz razloga da bi izvorni host, kojem
je izveštaj namenjen, bio u mogućnosti da identifikuje problematični datagram. Osam bajtova podataka je
uključeno zato što je njima obuhvaćen deo zaglavlja protokola višeg nivoa, koji npr. kod UDP i TCP definiše

54
brojeve portova i redne brojeve kod TCP protokola. Ove informacije su potrebne kako bi izvorni host mogao da
obavesti protokol višeg nivoa o nastaloj grešci.

Sl. 2-64 Sadržaj sekcije za podatke ICMP poruke za izveštaj o greškama.

Nedostupno odredište. Poruka tipa nedostupno odredište pokriva brojne neregularne situacije koje nastaju
prilikom rutiranja datagrama ili isporuke sadržaja datagrama protokolu višeg nivoa na strani odredišnog hosta.
Razlog slanja poruke definisan je sadržajem polja Code (vidi Sl. 2-63(a)). Poruku ovog tipa može da pošalje ruter
kada ne može da locira odredište datagrama, ne može da prosledi datagram sledećem ruteru (zato hardverskog
otkaza mreže ili rutera) ili kada datagram sa setovanim bitom DF (zabranjena fragmentacija) ne može biti
isporučen jer mreža koja stoji na putu zbog velike dužine datagrama ne dopušta njegov prenos. Odredišni host
šalje poruku ovog tipa izvornom hostu u situacijama kada protokol višeg nivoa kojem su podaci iz IP datagrama
namenjeni nije operativan ili kada aplikacioni program koji koristi podatke nije pokrenut.
Prigušenje izvora. IP je beskonekcioni protokol. To znači da između izvornog hosta, koji generiše datagrame,
rutera, koji prosleđuju datagrame, i odredišnog hosta koji ih obrađuje ne postoji nikakva povratna komunikacija.
Jedna od posledica nepostojanja ovakve komunikacije je nemogućnost kontrole protoka. Naime, IP ne poseduje
ugrađene mehnizme za kontrolu protoka što može da dovede do ozboljnog problema u IP komunikaciji:
zagušenja. Izvorni host nikada ne može znati da li je neki ruter ili odredišni host pretrpan datagramima; ili, da li
generiše datagrame bržim tempom od onoga kojim ruteri mogu da ih prosleđuju, odnosno kojim odredišni host
može da ih obrađuje.
Ruter ili host koristi bafer za privremeno smeštanje primljenih datagrama. Datagrami čekaju u baferu rutera da
budu prosleđeni sledećem ruteru ili odredišnom hostu. Slično, datagrami čekaju u baferu odredišno hosta da
budu isporučeni protoloku višeg nivoa. Ovi baferi imaju ograničenu veličinu. Ukoliko datagrami pristižu brže
nego što se prosleđuju ili isporučuju, u jednom trenutku, bafer će postati put. U takvoj situaciji, koja se naziva
zagušenjem, ruter ili hosta nema drugog izbora nego da uništi neke od datagrama ili ne prihvati nove datagrame.
ICMP poruka tipa ˝prigušenje izvora˝ uvedena je iz razloga uvođenja bazične forme kontrole protoka na IP
nivou. Kada ruter ili host zbog zagušenja odbaci datagram, on šalje poruku tipa ˝prigušenje izvora˝ pošiljocu
datagrama. Namena ove poruke je dvostruka. Prvo, poruka informiše izvor da je datagram odbačen. Drugo, ona
upozorava izvor da negde na putanji do odredišta postoji zagušenje i da bi zbog toga trebalo smanjiti (prigušiti)
brzinu slanja datagrama. Format poruke ˝prigušenje izvora˝ je prikazan na Sl. 2-63(a).
Isteklo vreme. Poruku tipa ˝isteklo vreme˝ šalje ruter nazad izvornom hostu nakon što je uništio datagram kome
je isteklo vreme života. Kao što znamo, svaki datagram sadrži polje time-to-live čija se vrednost umanjuje za 1 u
svakom ruteru kroz koji datagram prođe na svom putu ka odredišnom hostu. Kada nakon dekrementiranja time-
to-live postane jednako nuli, ruter uništava datagram. Dodatno, u ovoj situaciju, ruter šalje ICMP poruku nazad
hostu koji je poslao datagram. Ovaj događaj je simptom da paket ˝luta˝ u mreži, da je mreža zagušena ili da je
polje time-to-live u datagramu inicijalno postavljeno na isuviše malu vrednost.
Takođe, ICMP poruku ˝isteklo vreme˝ može generisati i odredišni host ako u definisanom vremenu ne primi sve
fragmente nekog datagrama. Kada primi prvi fragment, host startuje tajmer. Ako u trenutku kada zadato vreme
tajmera istekne, host još uvek nije primio sve fragmente, tada on uništava do tog trenutka primljene fragmente, a
izvornom hostu šalje poruku tipa ˝isteklo vreme˝.
Format poruke ˝isteklo vreme˝ prikazan je na Sl. 2-63(a). Vrednost 0 u polju Code znači da je poruku generisao
ruter zbog isteklog vremena života datagrama. Vrednost 1 u polju Code znači da je poruku poslao odredišni host
jer je isteklo vreme čekanja na sve fragmente datagrama.
Problem sa parmetrima. Bilo kakva greška, nedoslednost ili neusklađenost informacija u zaglavlju datagrama
može stvoriti ozbilje probleme prilikom prenosa datagrama kroz mrežu. Ruter ili odredišni host koji otkrije
problem u zaglavlju datagrama, uništava datagram i izvornom hostu vraća ICMP poruku tipa ˝problem sa
paremetrima˝. Format ove ICMP poruke prikazan je na Sl. 2-63(b). Sadržaj polja Code definiše razlog
odbacivanja datagrama: Ako polje Code ima vrednost 0, tada je u zaglavlju IP datagrama otkrivena greška. Pri
tome, vrednost u polju Pointer ukazuje na bajt IP zaglavlja gde je uočen problem. Ako polje Code ima vrednost
1, tada problem postoji u polju za opcije IP datagrama.

55
Preusmeravanje. Kada ruter treba da prosledi datagram u neku drugu mrežu, on mora znati IP adresu
odgovarajućeg sledećeg rutera. Isto važi ako je pošiljac host priključen na mrežu koja sadrži više od jednog
rutera. Kao i ruter, i host mora posedovati tabelu rutiranja koja će sadržati adrese dostupnih rutera. Međutim, za
razliku od rutera kod kojih se koristi pristup dinamičkog rutiranja i čije tabele se automatski ažuriraju, tabele
rutiranja hostova su po pravilu statičke. Obično, kada se host priključi na mrežu on u svojoj tabeli rutiranja
poseduje adresu samo jednog rutera - podrazumevanog rutera. Sve datagrame koje šalje, host će direktno
isporučivati podrazumevanom ruteru, čak iako podrazumevani ruter nije najbolji posrednik na putu datagrama
do odredišta. U takvim situacijama, podrazumevani ruter će isporučiti datagram odgovarajućem ruteru, ali će
dodatno poslati i ICMP poruku tipa ˝preusmeravanje˝ izvornom hostu sa preporukom da ubuduće datagrame
koje upućuje na dato odredište šalje tom drugom ruteru.
Poruka za redirekciju A

IP
datagram
R1 R2 B

LAN LAN

IP IP
datagram datagram

Sl. 2-65 Princip preusmeravanja.

Koncept preusmeravanja ilustrovan je na Sl. 2-65. Host A želi da pošalje datagram hostu B. Bez obzira što je
ruter R2 očigledno bolji izbor, host A šalje datagram ruteru R1. Ruter R1, nakon pregleda svojih tabele rutiranja,
nalazi da je datagram trebalo isporučiti ruteru R2. Ruter R1 isporučuje datagram ruteru R2, ali dodatno šalje
poruku za preusmeravanje hostu A. Host A dobija poruku i ažurira svoju tabelu rutiranja.
Format poruke za preusmeravanja prikazan je na Sl. 2-63(c). Uočimo da je IP adresa ciljnog rutera sadržana u
drugoj vrsti. Takođe, uočimo da se poruka za preusmeravanje donekle razlikuje od drugih poruka o greškama:
ruter ne uništava datagram, već ga prosleđuje odgovarajućem ruteru.
Upiti
Pored izveštavanja o greškama, ICMP se koristi i za dijagnosticiranje izvesnih problema u mreži. Za ovu
namenu se koriste poruke upita. U ovom slučaju, poruku (upit) šalje host, a na poruku odgovara odredišni ruter
ili host.

(a) (b) (c)

Sl. 2-66 Formati ICMP upita.
Eho. Poruke eho-zahtev i echo-odziv namenjene su dijagnosticiranju problema u mreži. Ove poruke koriste
administratori mreže ili korisnici da bi ustanovili da li dva sistema (hostovi ili ruteri) mogu međusobno
komunicirati. Poruku eho-zahtev može poslati host ili ruter drugom hostu ili ruteru. Host ili ruter koji primi eho-
zahtev kreira poruku tipa eho-odziv i vraća je nazad prvobitnom pošiljaocu.
Eho-zahtev/odziv se mogu koristiti za testiranje komunikcije na IP nivou. Obzirom da su ICMP poruke
enkapsulirane u IP datagrame, prijem eho-odziva je dokaz da IP protokoli na izvornoj i odredišnoj mašini
korektno funkcionišu i u stanju su da međusobno komuniciraju. Takođe, to je dokaz i da svi ruteri na putanji
između krajnjih mašina korektno primaju, obrađuju i prosleđuju IP datagrame.
Format poruke tipa eho-zahtev/odziv prikazan je na Sl. 2-66(a). Značenje polja Identification i Sequence number
nije definisano ICMP protokolom, već je način korišćenja ovih polja prepušten aplikaciji koja koristi eho
poruke. Po pravilu, polje Identification ukazuje na aplikacioni program koji je poslao eho-zahtev, dok se polje
Sequence number uvećava za 1 pri svakom slanju eho-zahteva. Polje za podatke je opciono. Poruka koju
pošiljac eho-zahteva upiše u ovo polje, mora u identičnom obliku biti sadržana i u odgovarajućem eho-odzivu.
Vremenski zapis. Par ICMP poruka tipa vremenski zapis se koristiti za određivanje vremena prenosa IP
datagrama između dve mašine (hostova ili rutera). Takođe, ova vrsta poruke se može koristiti i za sinhronizaciju
lokalnih časovnika dve mašine. Format poruka vremenski zapis/odziv prikazan je na Sl. 2-66(b).

56
Oba tipa poruke, vremenski-zapis-zahtev (timestamp request) i vremenski-zahtev-odziv (timestamp reply),
sadže tri 32-bitna polja za vremenske zapise (ili vremenske žigove, eng. timestamp). Svako od ovih polja sadrži
brojnu vrednost koja predstavlja vreme u milisekundama počev od ponoći po Univerzalnom vremenu (ranije,
vreme po Griniču). Izvor popunjava polje original timestamp (polazni vremenski zapis) vremenom slanja
timestamp request poruke. Preostala dva polja popunjava nulama. Odredište kreira timestamp reply poruku.
Odredište kopira vrednost iz polja original timestamp u isto polje timestamp reply poruke, a polja receive
timestamp i transmit timestamp, popunjava vremenom prijema timestamp request poruku i vremenom slanja
timestamp reply poruke, respektivno.
Par poruka vremenski zahtev/odziv se mogu koristiti za izračunavanje vremena prenosa u jednom pravcu
(sending_time), u drugom pravcu (receiving_time) ili u oba pravca (round-trip_time - vreme potrebno da
datagram pređe put od izvora do odredišta i nazad do izvora). Odgovarajuće formule su:
sending_time= receive_timestamp – original_timestamp izvor → odredište
receiving_time = returned_time – transmit_timestamp odredište → izvor
round-trip_time = sending_time + receiving_timestamp izvor → odredište → izvor
Uočimo da su vremena sending_time i receiving_time precizna samo ako su časovnici izvora i odredišta
usaglašeni (sinhronizovani). Međutim, treće vreme, round-trip_time, je tačno čak iako dva časovnika nisu
sinhronizovana. To je iz razloga što i jedan i drugi časovnik učestvuju dva puta u izračunavanju ovog vremena,
čime se poništava eventualna razlika u sinhronizaciji.
Adresna maska. U nekim sprecifičnim situacijama, host može da zna svoju IP adresu, a da pri tome ne zna
odgovarajuću masku. Da bi saznao masku host šalje poruku tipa zahtev za adresnom maskom (address-mask-
request) ruteru na lokalnoj mreži. Ako host zna IP adresu rutera, poruku će posati direktno ruteru, a ako ne zna,
poruku će poslati na broadcast adresu. Ruter koji primi poruku zahteva za adresnom maskom, odgovara
porukom odziva (address-mask reply) koja sadrži traženu masku. Format zahteva i odziva poruke tipa ˝adresna
maska˝ prikazan je na Sl. 2-66(c). U poruci zahteva polje za adresnu masku je popunjeno nulama; u poruci
odziva ovo polje sadrži traženu masku.

57
3 Transportni sloj
IP je odgovoran za komunikaciju između računara (tzv. host-host komunikacija). Kao protokol mrežnog sloja,
IP isporučuje poruku od izvornog do odredišnog računaru. Međutim, ovo je nepotpuna isporuka, jer često nije
dovoljno samo isporučiti poruku odredišnom računaru, već je treba i predati odgovarajućem procesu na
odredišnom računaru koji će je prihvatiti i obraditi. Drugim rečima, konačno odredište poruke nije računar, već
aplikacioni proces na odredišnom računaru (tzv. proces-proces komunikacija). Upravo ovaj poslednji korak u
isporuci poruka predstavlja odgovornost protokola transportnog sloja, kao što su UDP i TCP.

3.1 Portovi
Proces-proces komunikacija se uobičajno ostvaruje shodno klijent-server paradigmi: Proces na lokalnom hostu,
tzv. klijent, traži uslugu procesa na udaljenom računaru, tzv. server. Tipično, oba procesa (klijent i server) imaju
isto ime. Tako, na primer, da bi smo od udaljene mašine saznali tekući datum i vreme, potreban nam je Daytime
klijentski proces pokrenut na lokalnom i Daytime serverskom proces pokrenut na udaljenom hostu.
Savremeni operativni sistemi podržavaju više-korisnička (multiuser) i više-programska (multiprogramming)
okruženja. Na udaljenom računaru mogu se u isto vreme izvršavati više serverskih procesa, slično kao što se na
lokalnom računaru mogu izvršavati više klijentskih procesa. Da bi se uspostavila komunikacija između
odgovarajućeg para procesa nepohodno je definisati:
- Lokalni host
- Lokalni proces
- Udaljeni host
- Udaljeni proces
Lokalni i udaljeni host su definisani IP adresama. Da bi se definisali procesi, neophodan je još jedan
identifikator, koji se zove adresa servisa ili broj porta (tj. samo port). Kod TCP/IP, brojevi portova su celi
brojevi iz opsega 0 - 65,535.
Za identifikaciju klijentskog procesa koristi se broj porta koji se zove efmerni (ili privremeni) broj porta. Reč
efemerni znači ˝kratko-živući˝ i koristi se zato što je život klijenta po pravilu kratak. Efemerni brojevi porta su
veći od 1023. Tipično, klijetnskom procesu se prilikom pokretanja dodeljuje proizvoljno izabran jedan od
neiskorišćenih privremenih portova na klijentskom računaru, kojeg on koristi za svolju identifikaciju prilikom
obraćanja serverskom procesu. Kada klijentski proces završi sa radom, njegov broj porta se oslobađa i može biti
dodeljen nekom drugom klijetskom procesu. Server se takođe identifikuje brojem porta. Međutim, ovaj broj ne
može biti proizvoljno izabran. Ako bi serverski računar dodeljivao portove svojim serverskim procesima na
slučajan način, klijentski procesi koji se izvršavaju na klijentskim računarima ne bi znali preko kog porta da
zatraže uslugu udaljenog serverskog procesa. Zato se kod TCP/IP za standardizovane servise koriste univerzalni,
tzv. dobro-poznati brojevi porta. Svi klijentski procesi znaju dobro-poznati port odgovarajućeg serverskog
procesa. Na primer, dok se za identifikaciju Daytime klijentskog procesa može koristiti broj porta 52,000,
Daytime serverski proces mora da koristi broj porta 13. Ovaj koncept je ilustrovan na Sl. 3-1.
Daytime Daytime
klijent server

52,000 13

UDP UDP

Podaci 13 52,000

13 52,000 Podaci

Sl. 3-1 Brojevi porta.

Dakle, IP adrese i brojevi porta imaju različite uloge u izboru konačnog odredišta podataka. Odredišna IP adresa
definiše jedan od svih hostova na Interntu. Pošto je host izabran, broj porta definiše jedan od procesa na tom
konkretnom hostu.

58
Opsezi portova
Organizacija ICANN podelila je brojeve portova na tri opsega: dobro-poznati, registrovani i dinamički (ili
privatni).
Dobro-poznati portovi - portovi iz opsega 0 - 1,023, koje dodeljuje (definiše njihvou namenu) organizacija
ICANN.
Registrovani protovi - protovi iz opsega 1,024 - 49,151, koji nisu dodeljeni (organizacija ICANN nije definisala
njihvou namenu), ali koje neke druge organizacije ili firme mogu registrovati kod ICANN organizacije da bi se
predupredila dupliciranja.
Dinamički portovi - portovi iz opsega 49,152 - 65,535, koji nisu ni dodeljeni niti registrovani. Oni mogu biti
korišćeni kao privremeni ili privatni brojevi portova. Organizacija ICANN-a preporučuje da se efemerni brojevi
porta biraju iz ovog opsega. Međutim, kod mnogih sistema ova preporuka nije ispoštovana.
Adrese soketa
Kombinacija IP adrese i broja porta se naziva adresom soketa (Sl. 3-2). Klijentska adresa soketa jednoznačno
definiše klijentski, kao što serverska adresa soketa jednoznačno definiše serverski proces.

Sl. 3-2 Adresa soketa.

Da bi se koristile usluge transportnog sloja neophodan je par klijentska/serverska adresa soketa. Ova ukupno
četiri podatka su deo IP zaglavlja i UDP (odnosno TCP) zaglavlja. IP zaglavlje sadrži IP adrese, dok UDP
(TCP) zaglavlje sadži brojeve portova.

3.2 UDP
UDP (User Datagram Protocol - Protokol korisničkih datagrama) je jednostavniji od dva standardna TCP/IP
transportna protokola. UDP omogućava udaljenim aplikacijama da razmenjuju enkapsulirane IP datagrame, bez
potrebe da uspostavljaju konekciju (beskonekcioni protokol). UDP pruža samo osnovnu funkcionalnost
potrebnu za razmenu podataka na transportnom nivou. Konceptualno, jedina bitna razlika između UDP
datagrama i IP datagrama je u tome što UDP sadrži brojeve portova, što omogućava predajnoj aplikaciji da se
obrati tačno određenoj aplikaciji na odredišnoj mašini. UDP se ne bavi kontrolom toka, kontrolom grešaka i
retransmisijom nakon prijema lošeg datagrama, baš kako ni IP.

3.2.1 Korisnički datagram

Paketi koji se razmenjuju UDP protokolom nazivaju se korisničkim ili UDP datagramima. Korisnički datagram
se sastoji od 8-bajtnog zaglavlja i podataka. Format zaglavlja prikazan je na Sl. 3-3.

Sl. 3-3 UDP zaglavlje.

Source Port (Izvorni port): Broj porta aplikacionog procesa koji je kreirao poruku. Izvorni port je potreban u
situacijama kada udaljena aplikacija (kojoj se UDP datagram šalje) treba da vrati odgovor. Proces koji vraća
odgovor kopira broj iz polja Source Port u polje Destination Port poruke koju vraća i na taj način obezbeđuje da
će poruka biti isporučena pravoj aplikaciji.
Destination Port (Odredišni port). Broj porta udaljenog aplikacionog procesa kojem je poruka namenjena.
Total Length (Ukupna dužina): Veličina UDP datagrama u bajtovima, uključujući i zaglavlje i podatke.
Minimalna dužina UDP datagrama je 8 bajta (nema podataka). Obzirom na dužinu ovog polja od 16 bita,
maksimalna dužina UDP datagrama je 216 = 65,535 bajta. Međutim, zbog enkapsulacije u IP datagram,
maksimalna dužina UDP datagrama je manja.
Checksum (Kontrolna suma): 16-bitno polje koje se koristi za proveru ispravnosti poruke.

59
Kontolna suma
Koncept kontrolne sume koji se primenjuje kod TCP/IP razmatran je u sekciji 2.4.4 zajedno sa opisom postupka
izračunavanja kontrolne sume kod IP protokola. Međutim, izračunavanje kontrolne sume kod UDP-a se donekle
razlikuje od onog koji se koristi kod IP protokola. Kod UDP-a, kontrolna suma uključuje: pseudo zaglavlje,
UDP zaglavlje i podatke.

Sl. 3-4 Pseudo zaglavlje kod UDP-a.

Pseudo zaglavlje je deo zaglavlja IP datagrama u kojem je UDP datagram enkapsuliran (Sl. 3-4). Uključivanje IP
zaglavlja u kontrolnu sumu UDP datagrama obezbeđuje veću zaštitu od isporuke UDP datagrama pogrešnom
hostu ili pogrešnom protokolu. Naime, ako je greška nastala u IP zaglavlju i to baš u polju za odredišnu IP
adresu, i pri tome nije otkrivena kontrolnom sumom IP datagrama, UDP datagram, koji je sam za sebe ispravan,
biće isporučen pogrešnom hostu. Polje za protokol iz IP zaglavlja je uključeno da bi se obezbedilo da primljeni
paket pripada UDP-u. U polju za protokol zaglavlja IP datagrama koji enkapsulira UDP datagram, upisana je
vrednost 17. Ako se tokom prenosa ova vrednost promeni, datagram može biti isporučen nekom drugom
protokolu (npr. TCP).

3.2.2 Način rada

Beskonekcioni servis. UDP je beskonekcioni protokol. To znači da se svaki korisnički datagram poslat preko
UDP-a tretira kao nezavisni datagram. Između različitih UDP datagrama ne postoji veza, čak iako potiču od
istog izvornog i upućeni su istom odredišnom procesu. Korisnički datagrami nisu numerisani, a pošto do
odredišta mogu stići izvan redosleda, UDP nije u mogućnosti da rekonstruiše njihov prvobitni redosled. Takođe,
razmeni poruka između dva udaljena procesa preko UDP-a ne prethodi uspostavljanje konekcije, niti se po
završetku komunikacije konekcija raskida (kao što je to slučaj kod TCP-a). Posledica beskonekcionog načina
rada je i ta da proces ne može koristiti UDP za slanje toka podataka i da pri tome očekuje da UDP automatski
vrši pakovanje podataka u različite datagrame. Umesto toga, svaka poruka koju proces šalje mora biti dovoljno
kratka da može stati u jedan UDP datagram.
Kontrola toka i kontrola grešaka. UDP je jednostavan, nepouzdani transportni protokol. UDP ne poseduje
mehanizme za kotrolu toka, što znači da u samom protokolu ne postoji zaštita od zagušenja prijemnika velikim
brojem poruka. Takođe, UDP, izuzev kontrolne sume, ne poseduje druge mehanizme za kontrolu grešaka.
Pošiljalac ne može znati da li je poruka koju je poslao uspešno preneta, ili je možda izgubljena ili duplicirana u
prenosu. Prijemnik koji proverom kontrolne sume detektuje grešku, jednostavno uništava datagram.
Nepostojanje podrske za kontrolu toka i kontrolu grešaka znači da je na procesu koji koristi UDP da reši ove
probleme, u meri koja je njemu potrebna.
Enkapsulacija korisničkih datagrama
Proces koji šalje poruku preko UDP-a, prosleđuje poruku UDP-u zajedno sa parom adresa soketa i informacijom
o dužini podataka (Sl. 3-5). UDP softver dodaje podacima UDP zaglavlje i tako kreiran korisnički datagram
prosleđuje IP-u zajedno sa adresama soketa. IP dodaje svoje zaglavlje, postavljajući vrednost 17 u polje za
PROTOCOL, što treba odredišnoj strani da ukaže da podaci potiču od UDP protokola. Tako formiran IP
datagram se prosleđuje sloju veze gde se pakuje u okvir, a zatim se isporučuje fizičkom sloju koji kodira bitove
okvira u električne ili optičke signale i šalje ih udaljenoj mašini.
Kada poruka stigne do odredišnog hosta, fizički sloj dekodira signal u niz bitova koje prosleđuje sloju veze. Sloj
veze proverava ispravnost primljeniog okvira i pod uslovom da je okvir ispravan odstranjuje svoje zaglavlje, a
enkapsulirani IP datagram predaje IP-u. IP obavlja svoju proveru datagrama (na bazi kontrolne sume) i ako
nema grešaka, odstranjuje IP zaglavlje, a korisnički datagram prosleđuje UDP-u zajedno sa IP adresama
pošiljaoca i primaoca. UDP koristi svoju kontrolu sumu za proveru korisničkog datagrama. Ako je kontrolna
suma ispravna, UDP odstranjuje svoje zaglavlje i podatke sadržane u korisničkom datagramu, zajedno sa

60
adresom soketa pošiljaoca isporučuje prijemnom procesu. Adresa soketa je potrebna procesu u sitacijama kada
se od njega očekuje da odgovori na prmljenu poruku.

Sl. 3-5 Enkapsulacija i deenkapsulacija korisničkog datagrama.

Multipleksiranje i demultipleksiranje
Na hostu na kome se izvršava TCP/IP postoji samo jedan UDP. Međutim, može postojati nekoliko aplikacionih
procesa koji u isto vreme žele da koriste usluge UDP-a. Da bi se razrešile ovakve situacije, na nivou UDP-a
koristi se koncept multipleksiranja i demultipleksiranja (Sl. 3-6).

Sl. 3-6 Multipleksiranje i demultipleksiranje.

Multipleksrianje se koristi na strani pošiljaoca kada više od jednog aplikacionog procesa želi da pošalje
korisničke datagrame (odgovara relaciji više-prema-jedan: više aplikacionih procesa, jedan UDP). UDP prihvata
poruke od različitih procesa (koji se identifikuju svojim brojevima porta), svakoj poruci pridodaje zaglavlje i
kreirani korisnički datagram predaje IP-u.
Demultipleksiranje se koristi na strani prijemnika kada postoji više od jednog aplikacionog procesa koji očekuju
korisničke datagrame (odgovara relaciji jedan-prema-više: jedan UDP, više aplikacionih procesa). UDP prima
korisnički datagram od IP-a. Nakon provere grešaka i odstranjivanja zaglavlja, UDP isporučuje poruku
odgovarajućem aplikacionom procesu shodno broju porta.

3.2.3 Primene
Jedna oblast gde je UDP naročito koristan su izvesne klijet-server konfiguracije. Često, klijent šalje kratak upit
serveru i očekuje kratak odgovor. Ukoliko se upit ili odgovor izgube u prenosu, klijent jednostavno čeka neko
vreme i pokušava ponovo. Primer aplikacije koja koristi UDP na ovaj način je već ranije pomenut Daytime
servis. Program kome je potrebna informacija o tekućem vremenu šalje UDP datagram sa zahtevom Daytime
serveru. Server odgovara UDP datagramom sa upisanim tekućim datumom i vremenom. Da bi se obavila ova

61
prosta konverzacija, nije potrebna nikakva prethodna priprema ili uspostavljanje konekcije, dovoljno je
razmeniti dve kratke poruke.
Druga oblast primene UDP protokola su real-time multimedijalne aplikacije, kao što su: Internet radio, Internet
telefonija, muzika-na-zahtev, video konferencije, video-na-zahtev i druge. Zajednička karakteristika svih ovih
aplikacija je prenos kontinualnog toka digitalizovanog zvuka i/ili videa. Na predajnoj strani, zvuk (ili video) se
konvertuje u niz digitalnih odmeraka. Odmerak je binarni broj koji ukazuje na trenutnu amplitudu signala.
Odmerci se generišu frekvencijom koja je dovoljno visoka da omogući vernu reprodukciju (npr. 44kHz za
muziku). Odgovarajući proces deli generisani tok odmeraka na segmente (od po npr. 500 odmeraka) i pakuje ih
u UDP datagrame koje šalje prijemnoj strani. Na taj način, brzi tok odmeraka, konvertovan je u tok UDP
datagrama. Odgovarajući proces na prijemnoj strana dobija UDP datagrame, izdvaja odmerke i reprodukuje ih
tempom koji odgovara frekvenciji odmeravanja. U prenosu UDP datagrama može se ispoljiti džiter, a pojedini
datagrami mogu biti izgubljeni u prenosu, što narušava kvalitet reprodukcije. Međutim, s obzirom da se radi o
real-time toku (neprekidnom) retransmisija izgubljenih datagrama nije moguća (jer nema vremena za čekanje),
kao ni neka stroga kontrola protoka. Iz tog razloga za pomenute aplikacije se koristi UDP (a ne TCP), a
aplikaciji se prepušta da prevaziđe (ublaži) probleme koji nastaju gubitkom ili kašnjenjem paketa. Na primer,
umesto da se traži ponovno slanje izgubljenog paketa, aplikacija na prijemu može sama da pokuša da
rekonstruiše deo zvuka koji nedostaje. Takođe, umesto da odmerke odmah reprodukuje može privremeno da ih
smešta u bafer, čime će uneti izvesno kašnjenje u reprodukciji, ali zato će moći da toleriše veće kašnjenje
pojedinih paketa, koje će kada stignu da umetne na pravo mesto u baferu.

3.3 TCP
TCP (Transmission Control Protocol - Protokol za kontrolu prenosa) je konekcioni, pouzdani, proces-proces
transportni protokol koji pruža puni transportni servis udaljenim aplikacijama. TCP je proces-proces (program-
program) protokol koji, kao i UDP, koristi brojeve portova. Međutim, za razliku od UDP-a, TCP je konekcioni
protokol, koji radi prenosa podataka između dva udaljena procesa kreira virtuelnu konekciju. TCP sprovodi
kontrolu protoka i kontrolu grešaka, a projektovan je tako da se može dinamički prilagoditi promenljivim
karakteristikama Interneta i održi pouzdanu vezu čak i u slučajevima pojave raznih vrsta otkaza u mrežnoj
infrastrukturi.

3.3.1 Servisi
Proces-proces komunikacija
Slično UDP-u, TCP omogućava komunikaciju od procesa do procesa korišćenjem 16-bitnih brojeva portova za
identifikaciju procesa. Opsezi portova (dobro-poznati, registrovani i dinamički) su identični kao kod UDP-a.
Orijentacija na tok
Za razliku od UDP-a, TCP je protokol orijentisan na tok. Kod UDP-a, proces (aplikacioni program) šalje poruke
koje imaju tačno definisane granice. Svakoj takvoj poruci UDP dodaje svoje zaglavlje i isporučuje je IP-u.
Poruke se zovu korisnički datagrami, a svaka od njih u konačnom obliku postaje jedan IP datagram. UDP, kao
ni IP, ne vide bilo kakvu vezu između datagrama.
Sa druge strane, TCP omogućava predajnom procesu da šalje, a prijemnom procesu da prima podatke u vidu
kontinualnog toka bajtova. TCP kreira okruženje u kojem izgleda kao da su dva procesa spojena nekom
imaginarnom ˝cevi˝, kroz koju teku njihovi podaci (Sl. 3-7). Predajni proces generiše (upisuje) tok bajtova, a
prijemni proces konzumira (čita) bajtove iz ˝cevi˝.

Sl. 3-7 Tok bajtova.

Predajni i prijemni baferi
Obzirom da predajni i prijemni procesi ne moraju da upisuju ili čitaju podatke istom brzinom, TCP-ju su
neophodni baferi za privremeno čuvanje podataka. Postoje dva takva bafera: predajni i prijemni bafer. (Kasnije

62
u ovom poglavlju videćemo da su ovi baferi takođe potrebni za realizaciju mehanizama za kontrolu protoka i
kontrolu grešaka.) Baferi se realizuju u vidu cirkularnog memorijskog polja 1-bajtnih lokacija (Sl. 3-8). Radi
jednostavnosti, kapacitet oba baferi sa slike je 20 bajtova; u realnosti, a zavisno od implementacije, veličina
TCP bafera je više stotina ili više hiljada bajtova.

Sl. 3-8 Predajni i prijemni bafer.

Sl. 3-8 prikazuje prenos podataka u jednom smeru. Na predajnoj strani, uočavamo tri sekcije memorijskih
lokacija. Bela sekcija odgovara slobodnim (nepopunjenim) lokacijama, koje su raspoložive za upis novih
bajtova. Tamna oblast sadrži bajtove koji su poslati ali čiji prijem suprotna strana još uvek nije potvrdila. TCP
čuva poslate bajtove u baferu sve dok ne budu protvrđeni. Siva (osenčena) oblast sadrži bajtove koji tek treba da
budu poslati. Nakon što su bajtovi iz tamne sekcije potvrđeni, odgovarajuće lokacije se oslobađaju i postaju
˝bele˝.
Rad bafera na prijemnoj strani je jednostavniji. Cirkularni bafer je podeljen na dve sekcije (prikazane kao ˝bela˝
i ˝siva˝ sekcija). Bela sekcija sadrži prazne lokacije koje se raspoložive za upis novih bajtova koji stižu sa
mreže. Siva sekcija sadrži primljene bajtove koji prijemni proces može da preuzme (konzumira). Kada prijemni
proces pročita bajt, odgovarajuća lokacija se osobađa i postaje ˝bela˝.
TCP Segmenti
Iako baferi rešavaju problem usaglašavanja brzine generisanja i konzumiranja podataka, neophodan je još jedan
korak pre nego što se podaci pošalju kroz mrežu. Naime, IP sloj, kao mrežni servis koji stoji na raspolaganju
TCP-ju, prenosi podatke u paketima, a ne kao tok bajtova. Iz tog razloga, TCP grupiše određeni broj sukcesivnih
bajtova u paket tzv. segment. TCP dodaje zaglavlje svakom segmentu i isporučuj ga IP sloju. Segmenti se
enkapsuliraju u IP datagrame i šalju. Za prijemni proces, celokupna ova procedura je transparentna (nevidljiva).
Kasnije u ovom poglavlju, videćemo da segmenti mogu stići na predajnu stranu izvan redosleda, mogu biti
izgubljeni u prenosu, pokvareni i ponovo poslati. TCP rešava sve ove neregularne situacije bez bilo kakvog
učešća ili pomoći prijemnog procesa. Na Sl. 3-9 je prikazano kako se bajtovi uzimaju iz predajnog bafera, pakuju
u segmente, prenose na prijemnu stranu, i tamo raspakuju i upisuju u prijemni bafer.

Sl. 3-9 TCP segmenti.

63
Puna dupleksna komunikacija
TCP nudi uslugu pune dupleksne (full-duplex) komunikacije, gde podaci mogu da teku u oba smera u isto
vreme. To znači da svaki TCP poseduje oba bafera (predajni i prijemni), a segmenti se prenose u oba smera.
Konekcioni servis
TCP je protokol konekcionog tipa. Kada proces na mašini A želi da razmenjuje podatke sa procesom na mašini
B, dešava se sledeće:
1. Dva TCP-ja uspostavljaju (otvaraju) konekciju.
2. Podaci se razmenjuju u oba smera.
3. Konekcija se zatvara.
Napomenimo da se ovde radi o virtuelnoj, a ne fizičkoj konekciji. TCP segment se enkapsulira u IP datagram
koji na odredište može stići izvan redosleda, može se izgubiti ili duplicirati u prenosu. Drugim rečima, ne
postoji fizička konekcija koja bi garantovala isporuku segmenata u pravilnom redosledu, već TCP kreira
okruženje orijentisano na tok i na sebe preuzima odgovornost za isporuku bajtova u prvobitnom redosledu.
Pouzdani servis
TCP je pouzdani transportni protokol. Pouzdanost se postiže mehanizmom potvrđivanja. Prijemna strana
potvrđuje primljene podatke, a predajna ponovo šalje (retransmituje) podatke koji nisu potvrđeni u nekom
definisanom vremenu.

3.3.2 Mehanizmi
TCP obezbeđuje servise (pomenute u prethonoj sekciji) korišćenjem nekoliko bazičnih mehanizama koji će
ukratko biti opisani u ovoj sekciji.
Redni brojevi
TCP numeriše sve bajtove podataka koji se prenose putem uspostavljene konekcije. Numerisanje je nezavisno u
oba smera. Uvek kada dobije bajt podataka od predajnog procesa, TCP smešta bajt u predajni bafer i dodeljuje
mu redni broj. Numerisanje ne mora obavezno da počne od 0. Umesto toga, za numerisanje prvog bajta TCP
generiše slučajni broj iz opsega 0 - 232. Ako je generisan broj x, redni broj prvog bajta podataka biće x+1.
Numerisanje bajtova je ključna osobina TCP-ja, koja dominira svim aspektima protokola. Redni brojevi se
koriste za kontrolu protoka i kontrolu grešaka.
Iako TCP vodi evidenciju o segmentima koje šalje i prima, u zaglavlju segmenta ne postoji polje za redni broj
segmenta. Umesto toga, zaglavlje segmenta sadrži dva polja koja se zovu: Sequence Number (SEQ broj) i
Acknowledgement Number (ACK broj). Zajedničko ime za ova dva polja je broj bajta, a ne broj segmenta.
Sequence Number
Radi slanja kroz mrežu, TCP grupiše bajtove u segmente i svakom segmentu dodeljuje Sequence Number jednak
rednom broju prvog bajta u segmentu.
Acknowledgement Number
Kod TCP-ja komunikacija je tipa puni-dupleks: nakon što je konekcije uspostavljena, obe strane mogu da šalju i
primaju podatke u isto vreme. Svaka strana nezavisno numeriše svoje bajtove (one koje šalje), obično, počev od
rezličitih početnih brojeva bajta. SEQ broj u svakom smeru ukazuje na prvi bajt sadržan u segmentu. Takođe,
svaka strana koristi Acknowledgement Number (ACK broj) da bi potvrdila bajtove koje je primila. Međutim,
ACK broj definiše broj sledećeg bajta kojeg strana očekuje da primi. Dodatno, ACK broj je kumulativan. To
znači da strana koja šalje potvrdu, uzima broj poslednje ispravno primljenog bajta, uvećava ga za 1 i dobijenu
sumu koristi kao ACK broj. Drugim rečima, prijemnik ne potvrđuje eksplicitno svaki primljeni bajt, već se
potvrda odnosi na sve bajtove sa rednim brojevima manjim od ACK broja. (ACK broj jednak X znači da su svi
bajtovi do X, ali ne i X, uspešno primljeni).
Kontrola protoka
TCP se, za razliku od UDP, bavi kontrolom protoka. Kod TCP-ja, prijemnik je u mogućnosti da kontroliše
tempo kojim predajnik šalje podatke. Kontrola protoka je neophodna kako prijemnik ne bi bio pretrpan
podacima koje predajnik šalje isuviše velikom brzinom. Zahvaljujući rednim brojevima, TCP je u mogućnosti
da sprovodi kontrolu protoka do nivoa bajtova.

64
Kontrola grešaka
Mehanizam za kontrolu grešaka je neophodan da bi se obezbedio pouzdani prenos. Od TCP-ja se očekuje da na
prijemnoj strani rekonstruiše prvobitni tok bajtova, bez obzira na eventualne greške u segmentima, dupliciranje
ili gubitak segmenata. Iako se detekcija grešaka obavlja na nivou segmenata, koncept kontrole grešaka je, kao i
kontrola protoka, bajtovski orijentisan.
Kontrola zagušenja
TCP, za razliku od UDP, vodi računa o zagušenjima u mreži. Količinu podataka koje predajnik šalje, ne
kontroliše samo prijemnik (kotrola protoka), već je određena i nivoom zagušenja mreže.

3.3.3 Segment
TCP paketi se nazivaju segmentima. Format segmenta je prikazan na Sl. 3-10. Segment počinje 20-bajtnim
zaglavljem fiksnog formata. Nakon fiksnog dela zaglavlja slede polje za opcije (koje nije obavezno), a zatim i
podaci (maksimalno 65535 - 20 - 20 = 65495. Prvo ˝-20˝ zbog TCP, a drugo zbog IP zaglavlja.) Segmenti bez
podataka su dozvoljeni i često se koriste za provrđivanje i razmenu drugih upravljačkih informacija.

Sl. 3-10 TCP segment.

Slede kratka objašnjenja značenja polja TCP zaglavlja.
Source Port (Izvorni port, 16 bita). Definiše broj porta aplikacionog programa na hostu koji šalje
segment.
Destination Port (Odredišni port, 16 bita). Definiše broj porta aplikacionog programa na hostu koji
prima segment.
Sequence Number (Redni broj, 32 bita). Sadrži SEQ broj, tj. redni broj dodeljen prvom bajtu podataka
sadržanih u segmentu. Kao što je već rečeno, TCP je orijentisan na tok. Da bi se obezbedila striktna
kontrola toka i kontrola grešaka, svaki bajt koji se prenosi mora biti numerisan. SEQ broj ukazuje na
bajt iz toka bajtova koji je kao prvi sadržan u segmentu. U toku uspostavljanja konekcije, svaka strana
nezavisno, na slučajan način, generiše inicijalni SEQ broj.
Acknowledgment Number (Broj potvrde, 32 bajta). Sadrži ACK broj, tj. redni broj koji je dodeljen
prvom narednom bajtu podataka kojeg pošiljalac segmenta očekuje da primi od druge strane. Ako je
pošiljalac segment uspešno primio bajt sa rednim brojem x, tada će ACK broj biti jednak x+1. Ovo
polje je važeće ako je bit ACK (kasnije u zaglavlju) postavljen na 1. Napomenimo da isti segment
može da sadrži i podatke i potvrdu za prethodno primljene podatke.
HLEN (Veličina zaglavlja, 4 bita). Definiše broj 32-bitnih reči u TCP zaglavlju. Najveća 4-bitna
vrednost je 15, što znači da TCP zaglavlje može sadržati najviše 15*4 = 60 bajta (zajedno sa opcijama).
Pošto su 20 bajta fiksna, dužina polja za opcije može biti najviše 40 bajta.
Reserved (Rezervisano, 6 bita). Deo zaglavlja rezervisan na neku buduću namenu. Za sada, ovi bitovi
moraju biti postavljeni na 0.
Control bits (Kontrolni bitovi, 6 bita). Sadrži 6 bita ili flaga od kojih svaki ima neku posebnu namenu
u procesu kontrole toka, uspostavljanja i raskidanja konekcije, kao i definisanju načina prenosa
podataka. Potpunije objašnjenje uloge kontrolnih bitova sledi kasnije u ovom poglavlju, kada se
budemo bavili detaljinijm opisom rada TCP-ja.

65
 T. 3-1 Kontrolni bitovi.
Flag Opis
UGR Vrednost polja Urgent Pointer je validna.
ACK Vrednost polja Acknowledgment Number je validna.
PSH Push podataka.
RST Konekcija mora biti resetovana.
SYN Sinhroniše redne brojeve u toku uspostavljanja konekcije.
FIN Raskida konekciju.

Window Size (Veličina prozora, 16 bajta). Definiše veličinu tzv. prozora, u bajtovima. Ova vrednost se
obično naziva prozorom prijemnika (rwnd) i predstavlja trenutnu veličinu slobodnog prostora u
prijemnom baferu pošiljaoca segmenta. Informiše suprotnu stranu koliko bajtova, počev od broja
potvrde, može da pošalje. Veličina prozora 0 je legalna i ukazuje drugoj strani da je host, pošiljalac
segmenta, u takvom stanju da trenutno nije u mogućnosti da prima nove podatke (možda kasnije).
Checksum (Kontrolna suma, 16 bita). Polje za kontrolnu sumu. Procedura za izračunavanje kontrolne
sume za TCP je u osnovi identična onoj koja se primenjuje kod UDP-a. Međutim, kod UDP-a,
kontrolna suma je opciona, dok je kod TCP-ja obavezna. Radi izračunavanja kontrolne sume zaglavlju
segmenta se dodaje istio pseudo zaglavlje kao i kod UDP-a ( Sl. 3-11).

Sl. 3-11 Pseudo zaglavlje kod TCP-ja.

Urgent Pointer (Pointer na urgentne podatke, 16 bajta). Sadržaj ovog polja je validan samo ako je bit
URG=1. Koristi se kada segment sadrži urgentne (hitne) podatke. Definiše broj koji kada se sabere sa
SEQ brojem daje redni broj prvog urgentnog bajta sadržanog u sekciji za podatke segmenta. (Više
detalja kasnije u poglavlju).
Options (Polje za opcije, 0 - 40 bajtova). Pruža mogućnost da se zaglavlje proširi dodatnim
informacijama. (Više detalja o opcijama kasnije u poglavlju.)
Enkapsulacija segmenta
TCP segment se enkapsulira u IP datagram, koji se dalje enkapsulira u okvir nivoa veze, kao što je prikazano na
Sl. 3-12.

Zaglavlje IP TCP
okvira zaglavlje segment

Sl. 3-12 Enkapsulacija TCP segmenta.

3.3.4 Konekcija
TCP je konеkcioni protokol. To znači da se između izvora i odredišta uspostavlja virtuelna putanja za prenos
svih segmenata koji će biti razmenjivani u komunikaciji između dve strane. Virtuelna putanja olakšava proces
potvrđivanja, kao i retransmisiju oštećenih ili izgubljenih segmenata. Može se postaviti pitanje, kako TCP može
biti konekcioni protokol, ako koristi usluge IP-a, koji je, kao što znamo, beskonekcioni protokol. Suština je u
tome da je TCP konekcija virtuelna, a ne fizička, odnosno da TCP radi na višem nivou apstrakcije od IP-a. TCP
koristi usluge IP-a samo za isporuku pojedinačnih segmenata prijemniku, dok sam obavlja kontrolu konekcije.
Ako se segment izgubi ili ošteti u prenosu, TCP će inicirati njegovu retransmisiju. IP nije svestan retransmisije.
Ako segment stigne izvan redosleda, TCP će ga privremeno zadržati sve dok ne stignu svi segmenti koji
nedostaju. Ponovo, IP nije svestan ovog preuređivanja.

66
Kod TCP-ja, konekcioni prenos se ostvaruje u tri faze: uspostavljanje konekcije, prenos podataka i raskidanje
konekcije.
Uspostavljanje konekcije
TCP komunikacija je tipa ˝puni dupleks˝. Dve mašine koje su u TCP vezi u mogućnosti su da jedna drugoj
istovremeno šalju segmente. To znači da obe strane moraju učestvovati u inicijalizaciji komunikacije kako bi od
druge strane dobile odobrenje za slanje podataka.
Trostepeno usaglašavanje
TCP konekcija se uspostavlja procedurom koja se zove trostepeno usaglašavanje (eng. three-way handshaking).
Pretpostavimo da aplikacioni program (klijent), želi da uspostavi TCP konekciju sa nekim drugim aplikacionim
programom (server). Celokupan proces započinje server. Serverski program obaveštava lokalni TCP da je
spreman da prihvati konekciju. Drugim rečima, server od svog TCP-ja zahteva pasivno otvaranje konekcije
(eng. passive open). Pasivno otvaranje ne uspostavlja konekciju, već samo daje dozvolu TCP-ju da prihvati
zahtev za uspostavljanje konekcije koji eventualno stigne od neke udaljene aplikacije.
Klijentski program, sa druge strane, izdaje zahtev lokalnom TCP-ju, za aktivno otvaranje konekcije (eng. active
open). Klijent zapravo saopštava TCP-ju da želi da ostvari konekciju se konkretnim ˝otvorenim˝ serverom. U
ovom trenutku, TCP na klijetnskoj strani započine proceduru trostepenog usaglašavanja (Sl. 3-13). Na Sl. 3-13 su
prikazane dve vremenske ose, jedna za klijentsku, a druga za serversku stranu. Segmenti koji se razmenjuju
tokom uspostavljanja konekcije prikazani su delovima svojih zaglavlja koji su bitni u odgovarajućoj fazi ove
procedure.

Sl. 3-13 Uspostavljanje TCP konkcije: trostepeno usaglašavanje.

Sledi opis svakog od tri koraka:
1. Klijent šalje prvi segment, tzv. SYN segment, u kojem je flag SYN postavljen (tj. ima vrednost 1).
Ovaj segment služi za sinhronizaciju rednih brojeva. Klijent slučajno bira prvi redni i šalje ga serveru
(kao vrednost polja Sequence Number). Ovaj redni broj se zove inicijalni redni broj (ISN). Uočimo da
SYN segment ne sadrži ACK broj (bit ACK=0), niti definiše veličinu prozora. SYN segment je
kontrolni segment i ne sadrži bilo kakve podatke. Međutim, SYN segment ˝troši˝ jedan redni broj.
Kada prenos podataka bude počeo, redni broj za prvi bajt podataka će biti za 1 veći od ISN broja.
(Možemo zamisliti kao da SYN segment, iako ne prenosi ni jedan ˝fizički˝ bajt, ipak, sadrži jedan
imaginarni bajt.
2. Drugi segment (tzv. SYN+ACK segment) šalje server. Kod ovog segmenta postavljena su dva flaga:
SYN i ACK. Segment ima dvostruku ulogu. Prvo, on ima ulogu SYN segmenta za komunikaciju u
suprotnom smeru. Naime, server koristi SYN+ACK segment da bi inicijalizovao redni broj za prenos
bajtova od servera do klijenta. Drugo, server koristi SYN+ACK segment da bi potvrdio prijem
klijentovog SYN segmenta. Iz tog razloga, u ovom segmentu je postavljen flag ACK, a polje
Acknowlegmnet Number sadrži sledeći redni broj koji server očekuje da primi od klijenta. S obzirom da
segment sadrži potvrdu (ACK=1), u njemu mora biti definisana i veličina prozora, rwind.

67
 3. Treći segment (tzv. ACK segment) šalje klijent. Ovim segmentom klijent podvrđuje početni redni broj
servera. Flag ACK je postavljen, a polje Acknowlegmnet Number sadrži redni broj prvog očekivanog
bajta. Uočimo da je redni broj, sadržan u polju Sequence number, ACK segmenta identičan ovome iz
SYN segmenta, što znači da ACK segment ne troši ni jedan redni broj. Klijent, takođe, mora da
definiše veličinu prozora servera. Kao i prethodna dva, ACK segment sadrži samo zaglavlje, ali ne i
podatke.
Prenos podataka
Nakon što su uspostavile konekciju, dve udaljene aplikacije mogu da razmenjuju podatke. Klijent i server mogu
slati podatke i potvrde u oba smera. Podaci i potvrede koje se prenose u istom smeru mogu se prenositi istim
segmentom. Za podvrđivanje primljenih podataka koristi se flag ACK i polje Acknowledgment number iz
zaglavlja, a za slanje podataka sekcija za podatke segmenta. Na Sl. 3-14 je prikazan primer prenosa podataka.
Pretpostavka je da je konekcija prethodno uspostavljena. Klijent prvo šalje 2000 bajtova podataka podeljenih u
dva segmenta. Zatim, server šalje 2000 bajtova u jednom segmentu. Konačno, klijent šalje još jedan segment.
Prva tri segmenta prenose i podatke i potvrde, dok poslednji segment prenosi samo potvrdu (zato što nema više
podataka za slanje). Treba obratiti pažnju na SEQ i ACK brojeve. Takođe, uočima da je u segmentima koje šalje
klijent postavljen flag PSH (push), što predstavlja indikaciju serveru da primljene podatke treba da isporuči
serverskom procesu odmah nakon prijema (bez zadržavanja u prijemnom baferu). U segmentu koji server šalje
klijentu, flag PSH nije postavljen.
Klijent Server

Seq:
8 00 1
ACK A ck:
1500
PS H 1

b a jto P o d a ci
vi: 8 0
01 -
9000

Seq:
9 00 1
ACK A ck:
1500
PS H 1

b a jto Pod
vi: 9 0 a ci
01 -
10 0 0
0

1
1 5 00
Seq: 1
10 0 0
A c k:
ci
ACK P o d a - 1 7 00 0
50 0 1
vi: 1
b a jto

Seq:
1 00 0
A ck: 0
ACK 1 70 0
1
R wn
d: 1 0 00 0

Vreme Vreme

Sl. 3-14 Prenos podataka.

Push operacija
Kao što znamo, predajni TCP koristi bafer za privremeno skladišćenje podataka koje predajni aplikacioni
program želi da pošalje. Predajni TCP uzima podatke iz bafera i pakuje ih u segmente, čiju veličinu sam bira.
Ako aplikacioni program upiše u predajni bafer mali broj bajtova, nedovoljan da se popuni jedan segment
optimalne veličine, TCP će sačekati još neko vreme očekujući da će aplikacija upisati nove podatke. Sa druge
strane, prijemni TCP smešta primljene podatke u prijemni bafer i isporučuje ih prijemnom aplikacionom
programu onda kada je aplikacioni program spreman da prihvati nove podatke ili onda kada je to ˝zgodno˝
prijemnom TCP-ju. Na primer, prijemni TCP može da sačeka da se prijemni bafer napuni do izvesne mere, pre
nego što podatke preda prijemnoj aplikaciji. Ovakav tip fleksibilnosti povećava efikasnost TCP komunikacije.
Međutim, postoje situacije kada podatke treba isporučiti prijemnoj aplikacije što je pre moguće. To je tipično
slučaj kod interaktivnih aplikacija. Na primer, klijent šalje serveru kratku tekstualnu komandu unetu preko
tastature na koju očekuje brzi odgovor. Čekanje TCP da se u baferima ˝prikupi˝ dovoljan broj bajtova unelo bi
neprihvatljivo kašnjenje.

68
TCP je u stanju da prevaziđe prethodno opisan problem. Aplikacioni program na predajnoj strani može zahtevati
tzv. push operaciju. To znači da predajni TCP neće čekati na nove podatke, već će odmah po upisu podataka u
predajni bafer kreirati i poslati segment. Pri tome, u segmentu kojeg šalje, predajni TCP postavlja flag PSH kako
bi obavestio prijemni TCP da segment nosi podatke koje treba isporučiti prijemnoj aplikaciji što je pre moguće.
Urgentni podaci
TCP je protokol orijetisan na tok. Drugim rečima, aplikacija predaje podatke TCP-ju u vidu kontinualnog toka
bajtova. Svaki bajt podataka ima svoju tačnu poziciju u ovom toku. Međutim, postoje situacije kada aplikacioni
program ima potrebu da pošalje urgentne bajtove. To znači da predajna aplikacija želi da izvesni podaci budu
pročitani izvan redosleda iz prijemnog bafera i što pre predati prijemnom aplikacionom programu.
Razmotrimo sledeći primer. Predajni aplikacioni program šalje podatke na obradu prijemnom aplikacionom
programu. Po prijemu prvih razultata obrade, predajna aplikacija zaključuje da je ˝sve bilo pogrešno˝ i da je
najbolje prekinuti dalju obradu. Međutim, predajna aplikacija je u međuvremenu već poslala veću količinu
podataka. Ako pošalje komandu za prekid procesa, npr. Ctrl-C, ova dva karaktera će se naći na kraju prijemnog
bafera i biće isporučeni prijemnog aplikaciji tek kada ona obradi sve prehodno pogrešno poslate bajtove.
Rešenje prethodnog problema se sastoji u slanju segmenta sa postavljenim flagom URG. Predjani aplikacioni
program saopštava predajnom TCP-ju da su podaci koje mu predaje urgentni. Predajni TCP kreira segment i na
početak polja za podatke umeće urgentne podatke. Preostali prostor u polju za podatke može biti ispunjen
˝normalnim˝ podacima. Polje Urgent pointer iz zaglavlja segmenta ukazuje kraj uregnetnih i početak
˝normalnih˝ podataka.
Kada prijemni TCP primi segment sa postavljenim flagom URG, on izdvaja urgentne podatke iz segmenta
(korišćenjem vrednosti iz polja Urgent pointer) i isporučuje ih, izvan redosleda, prijemnom aplikacionom
programu.
Zatvaranje konekcije
Konekciju može da zatvori bilo koja od dve strane uključene u razmenu podataka (klijenti ili server). Većina
aktuelnih implementacija TCP protokola nudi dve opcije za zatvaranje konekcije: trostepeno usaglašavanje i
četvorostepeno usaglašavanje sa opcijom za zatvaranje konekcije u jednom smeru (tzv. polu-zatvaranje).
Klijent

Seq:
x
F IN A ck:
y

FIN
Klijent Server
Aktivno
zatvaranje
y-1
Seq:
k : x+1
Ac

ACK ACK
Seq:
x Pasivno n tu
F IN A ck: a klije
y zatvaranje e rv e ra k
od s
od a ta ka
FIN e n ti p
Segm
Aktivno
zatvaranje
y Potvrde od klijenta ka serveru
S e q:
x+1
A ck: z
S e q:
ACK x+1
F IN ACK A ck:
FIN +
F IN F IN

Seq:
x
A CK A c k: Seq:
y+1 x
A CK A c k:
z+1
ACK
ACK

Vreme Vreme Vreme

(a) (b)
Sl. 3-15 Zatvaranje konekcije: (a) trostepeno usaglašavanje; (b) polu-zatvaranje.

69
Trostepeno usaglašavanje
Postupak zatvaranja konekcije postupkom trostepenog usaglašavanja ilustrovan je na Sl. 3-15(a).
1. U normalnim situacijama, klijentski TCP, nakon što od klijentskog procesa primi komandu za
zatvaranje konekcije, šalje prvi segment (tzv. FIN segment) u kojem je postavljen flag FIN.
Napomenimo da FIN segment može sadržati i poslednje podatke koje klijent šalje serveru, ali može biti
i kontrolni segment (segment koji ne sadrži podatke), kao što je to slučaj na Sl. 3-15(a). Ako se radi o
kontrolnom segmentu, FIN segment troši samo jedan redni broj.
2. Nakon prijema FIN segmenta, serverski TCP obaveštava serverski proces da klijent traži zatvaranje
konekcije, a zatim šalje drugi segment (tzv. FIN + ACK segment) kojim potvrđuje prijem FIN
segmenta i u isto vreme objavljuje zatvaranje konekcije u dugom smeru. Ovaj segment takođe može
sadržati i poslednji odeljak podataka koje server šalje klijentu. Ako ne sadrži podatke, FIN+ACK
segment troši samo jedan redni broj.
3. Klijentski TCP šalje poslednji segment, ACK segment, kojim potvrđuje FIN segment dobijen od
serverskog TCP-ja. Ovaj segment sadrži ACK broj koji je za 1 veći od SEQ broja iz FIN segmenta.
Ovaj segment ne može sadržati podatke i ne troši redne brojeve.
Polu-zatvaranje
Kod TCP-ja, dozvoljeno je da jedna strana prestane sa slanjem ali nastavi sa prijemom podataka. Ovakva
situacija se naziva polu-zatvaranjem konekcije i obično je inicirana od strane klijenta. Na Sl. 3-15(b) je pirkazan
primer polu-zatvaranja. Klijent zatvara svoj smer konekciju (u smeru slanja svojih podataka) slanjem FIN
segmenta. Server prihvata polu-zatvaranje slanjem ACK segmenta (a ne FIN+ACK, kao kod obostranog
zatvaranja). Međutim, server može nastaviti da šalje svoje podatke. Server, kada više nema podataka za slanje,
zatvara svoj smer konekcije slanjem FIN segmenta kojeg klijent potvrđuje ACK segmentom.
Nakon polu-zatvaranja konekcije, podaci se mogu i dalje prenositi od servera do klijenta, a potvrde od klijenta
do servera. Međutim, kijent ne može više slati nove podatke serveru. Obratimo pažnju na redne brojeve. Iako je
klijent primio redni broj y-1 i očekuje y, redni broj servera je još uvek y-1. Kada je konekcija konačno
zatvorena, SEQ broj poslednjeg ACK segmenta je još uvek x, zato što nakon polu zatvaranja klijent nije potrošio
ni jedan redni broj.
Resetovanje konekcije
Flag RST se koristi kada TCP, sa bilo koje strane konekcije, želi da odbije zahtev za uspostavljanje konekcije,
ili trenutno prekinute otvorenu konekciju.
Odbijanje konekcije. Pretpostavimo da je TCP na serverskom hostu dobio zahtev za usopstavljanje konekcije na
nepostojećom portu (tj. na portu koji na tom hostu nije otvoren za slušanje). U takvoj situaciji serverski TCP
odbija zahtev slanjem klijentu segent sa postavljenim bitom RST.
Prekidanje konekcije. U toku trajanja konekcije mogu nastati izvesne neregularne situacije, kao što je npr.
razdešavanje rednih brojeva, nakon kojih nije moguće nastaviti normalnu komunikaciju. TCP koji primeti takvu
situaciju, kada nije moguće ni sprovesti regularnu proceduru zatvaranja konekcije, ˝nasilno˝ prekida konekciju
slanjem TCP-ju sa druge strane segmenta sa postavljenim bitom RST.
Zatvaranje pasivne konekcije. TCP na jednoj od dve strane konekcije, može primetiti da je druga strane pasivna
neko duže vreme (ne šalje podatke), što može biti simtom neregularnog rada aplikacionog programa na
udaljenom hostu koji koristi konekciju. U takvoj situaciju, TCP, slanjem RST segment, može da uništi
konekciju.

3.3.5 Dijagram stanja

Da bi se olakšalo praćenje različitih događaja i brojnih izuzetnih sitacija koje se mogu desiti u toku
uspostavljanja konekcije, prenosa podataka i zatvaranja konekcije, TCP softver je realizovan u vidu konačnog
automata (FSM – Finite State Machine). Konačni automat, pod dejstvom događaja, prolazi kroz konačni broj
stanja. U svakom momentu, automat je u jednom od svojih stanja. Automat ostaje u tekućem stanju sve dok se
ne desi neki događaj pod čijim dejstvom prelazi u novo stanje. U isto vreme, kao reakciju na događaj, automat
može izvršiti i izvesne aktivnosti. Drugim rečima, događaj je ulaz u stanje, koji može da promeni stanje i
generiše izlaz. TCP protokol predviđa 11 stanja (tabela T. 3-2).

70
 T. 3-2 Stanja TCP protokola.
Stanje Opis
CLOSED Konekcija ne postoji
LISTEN Aplikacija je izvršila pasivno otvaranje, TCP čeka na SYN.
SYN-SENT SYN je poslat; TCP čeka na ACK.
SYN-RCVD ACK+SYN je poslat. TCP čeka na ACK.
ESTABLISHED Konekcija je uspostavljena. Normalni prenos podataka je u toku.
FIN-WAIT-1 Poslat je prvi FIN. TCP čeka na ACK.
FIN-WAIT-2 ACK za prvi FIN je primljen. TCP čeka na drugi FIN.
CLOSE-WAIT Primljen je prvi FIN i poslat ACK. TCP čeka da se aplikacija zatvori
TIMED-WAIT Primljen je drugi FIN i poslat ACK. TCP čeka vreme 2MS.
LAST-ACK Poslat je drugi FIN. TCP čeka na ACK.
CLOSING Obe strane su istovremeno inicirale zatvaranje konekcije.

Dijagram stanja TCP protokola prikazan je na Sl. 3-16. Zaobljeni pravougaonici prestavljaju stanja. Prelazi
između stanja prikazani su usmerenim linijama (granama). Svakoj grani pridružen je natpis kojeg čine dva dela
razdvojne kosom crtom. Prvi deo ukazuje na događaj ili ulaz (šta TCP prima), a drugi na akciju ili izlaz (šta
TCP šalje). Događaj može da inicira aplikacija (zahtev za aktivno/pasivno otvaranje ili zatvaranje konekcije),
prijem segmenta (SZN, FIN, ACK ili RST) ili istek vremena čekanja (tzv. timeout). Akcija je slanje
upravljačkog segmenta (SYN, FIN ili RST). Izostanak akcije označen je crtom, -. Dijagram sa Sl. 3-16 prikazuje
aktivnosti i klijenta i servera. Normalni tok aktivnosti servera predsavljen je isprekidanim, a normalni tok
aktivnosti klijenta punim linijama.

Sl. 3-16 Dijagram stanja TCP protokola.

Scenarija
Da bi smo razumeli dijagram stanja i rad TCP-ja, razmotrićemo nekoliko tipičnih scenarija.
Uspostavljanje i raskidanje konekcije
Na Sl. 3-17 je ilustrovan scenario u kojem serverski proces obavlja pasivno otvaranje i pasivno zatvaranje, a
klijentski aktivno otvaranje i aktivno zatvaranje konekcije. Zatvaranje konekcije sledi proceduru polu-
zatvaranja. Stanja i njihova relativna trajanje prikaza su duž vremenske ose.
Klijentska stanja. Klijentski proces izdaje komandu svom TCP-ju zahtevajući uspostavljanje konekcije sa
serverom na datoj adresi soketa. Drugim rečima, klijenski proces inicira aktivno otvaranje. Kao reakciju na

71
zahtev, TCP šalje SYN segment na specificiranu adresu soketa i prelazi u stanje SYN-SENT. Nakon prijema
segmenta SYN+ACK, TCP šalje ACK segment i prelazi u stanje ESTABLISHED. U ovom stanju prenose se
podaci i potvrde (po potrebi u oba smera).
Kada klijentski proces nema više podataka za slanje, on svom TCP-ju izdaje komandu za aktivno zatvaranje
konekcije. Klijentski TCP šalje FIN segment i prelazi u stanje FIN-WAIT-1. Nakon što primi ACK za poslati
FIN segment, TCP prelazi u sanje FIN-WAIT-2 i ostaje u ovom stanju sve dok ne primi FIN segment od
servera. Kada primi FIN segment, klijent šalje ACK segment, prelazi u stanje TIME-WAIT i startuje tajmer
podešen na dvostruko maksimalno vreme života segmenta (MSL - Maximum Segment Livetime). Vreme MSL je
maksimalno vreme koje segment može da provede u Internetu pre nego što bude uništen. (Podsetimo se da se
TCP segment enkapsulira u IP datagram čije je vreme života ograničeno - TTL. Kada ruter uništi datagram zbog
isteklog vremena života, uništen je i enkapsulirani TCP segment.) Tipično vrednost za MSL je između 30 s i 1
min.
Stanje TIME-WAIT i čekanje 2MSL uvedeni su da bi se prevazišla izuzetna situacija koja nastaje ako se
poslednji ACK kojeg klijet šalje izgubi u prenosu. U takvoj situaciji, serverski TCP koji je poslao poslednji FIN
i čeka na ACK koji ne dolazi, zaključuje da je FIN izgubljen i ponovo ga šalje. Ako klijent pre isteka vremena
2MSL pređe u stanje CLOSE i zatvori konekciju može se desiti da ponovljeni FIN ne stigne do njega što znači
da serverski TCP nikada neće dobiti završni ACK. Drugim rečima, server neće uspeti da zatvori konekciju.
Uvođenjem tajmera podešenog na vreme 2MSL obezbeđuje da će klijent, pre konačnog napuštanja konekcije,
čekati dovoljno dugo da ACK bude izgubljen (jedno MSL) i da ponovljeni FIN stigne do njega (drugo MSL).
Ako u toku stanja TIME-WAIT, klijent primi novi FIN, klijent šalje novi ACK i vraća tajmer na početak.

Sl. 3-17 Uspostavljanje i zatvaranje konekcije.

72
Serverska stanja. U scenariju predstavljenom na Sl. 3-17, serverski proces izdaje svom TCP-ju komandu za
pasivno otvaranje. To se mora desiti pre nego što klijent izda komandu za aktivno otvaranje. Serverski TCP
prelazi u stanje LISTEN gde ostaje, pasivno čekajući, se dok ne primi SYN segment. Kada primi SYN segment,
serverski TCP šalje SYN+ACK segment i prelazi u stanje SYN-RCVD gde čeka da klijent pošalje ACK
segment. Nakon prijema ACK segmenta, TCP prelazi u stanje ESTABLISHED u kome se odbavlja prenos
podataka.
Serverski TCP ostaje u stanju ESTABLISHED sve dok od klijentskog TCP-ja ne primi FIN segment što znači
da klijentsi proces nema više podataka za slenje i želi da zatvori konekciju ka serveru. Kao odgovor na FIN,
serverski TCP šalje klijentu ACK segment, isporučuje serverskoj aplikaciji preostale podatke iz prijemnog
bafera i prelazi u stanje CLOSE-WAIT. Razmatrani scenario podrazumeva polu-zatvaranje konekcije. To znači
da serverski TCP može i dalje da šalje podatke klijentu i od njega prima potvrde. Međutim, podaci se više ne
mogu prenositi u suprotnom smeru, od klijenta ka serveru. Serverski TCP ostaje u ovom stanju sve dok
serverska aplikacija ne zatraži zatvaranje konekcije izdavanjem odgovarajuće komande (close). Kada se to desi,
serverski TCP šalje FIN segment klijentu, kako bi mu saopštio svoju nameru da i on želi da zatvori konekciju, i
prelazi u stanje LAST-ACK. TCP ostaje u ovom stanju sve dok ne primi poslednji ACK, a onda prelazi u stanje
CLOSED. Procedura zatvaranja konekcije koja je počela prvim FIN segmentom se naziva četvorostepenim
usaglašavanjem (four-way handshake).
Zatvaranje konekcije korišćenjem trostepenog usaglašavanja
Kao što je već napomenuto, trostepeno usaglašavanje je uobičajeni način zatvaranja TCP konekcije. U ovom
slučaju, strana koja primi FIN segment, kao odgovor šalje FIN+ACK segment, kombinujući tako u isti segment
FIN i ACK segmente iz procedure četvorostrukog usaglašavanja. Klijent, preskače FIN-WAIT-2 stanje i
direktno prelazi u stanje TIME-WAIT. Scenario zatvaranja korišćenjem trostepenog usaglašavanja ilustrovan je
na Sl. 3-18. Nakon završene faze prenosa podataka, klijent izdaje komandu close. Klijentski TCP šalje FIN
segment i prelazi u stanje FIN-WAIT-1. Po prijemu FIN segmenta, serverski TCP isporučuje serverskoj
aplikaciji zaostale podatke zajedno sa informacijom da konekcija mora biti zatvorena. Nakon toga, serverski
TCP prelazi u stanje CLOSE-WAIT i odlaže slanje ACK segmenta na primljeni klijentov FIN sve dok od svoje
aplikacije na dobije zahtev za pasivnim zatvaranjem. Kada serveska aplikacija izda komandu close, TCP šalje
FIN+ACK segment klijentu i prelazi u stanje LAST-ACK, gde čeka na poslednji ACK. Ostatak procedre je isti
kao kod četvorostepenog usaglašavanja.
Klijentski Serverski
proces proces

... ...

FIN

Pasivno
zatvaranje

2MSL
tajmer FIN + ACK

Isteklo
A CK
vreme

Klijentska
stanja

Serverska
stanja

Sl. 3-18 Zatvaranje konekcije korišćenjem trostepenog usaglašavanja.

73
Odbijanje konekcije
Često se dešava da TCP odbije konekciju zato što odredišni port iz primljenog SYN segmenta definiše serversku
aplikaciju koja trenutno nije u stanju LISTEN. U tom slučaju, serverski TCP, nakon prijema SYN segmenta,
šalje nazad RST+SYN segment koji potvrđuje SYN segment i u isto vreme resetuje (odbija) konekciju. Nakon
toga, serverski TCP se vraća u stanje LISTEN da čeka na nove zahteve. Klijent, po prijemu RST-ACK
segmenta, prelazi u stanje CLOSED. Scenario odbijanja konekcije prikazan je na Sl. 3-19.
Klijentski Serverski
proces proces

otvaranje
Pasivno
otvaranje

CLOSED
Aktivno

CLOSED

LISTEN
SYN-SENT

SYN

SYN-RCVD
RST + ACK
CLOSED

LISTEN
Sl. 3-19 Odbijanje konekcije.
Prekidanje konekcije
Umesto da zatvori, proces može da prekine konekciju. To se može desiti usled otkaza ili neregularnog rada
procesa (npr. zbog ulaska u beskonačnu petlju) ili ako proces ne želi da podaci koje je upisao u predajni bafer
budu poslati (npr. zato što je naknadno zaključio da su podaci pogrešni). Prekid konekcije može da inicira i
TCP, na primer, ako primi segment koji pripada prethodnoj konekciji. U svim ovim slučajevima, TCP može da
pošalje RST kako bi trenutno prekidnuo konekciju. Na Sl. 3-20 je prikazan scenario kada klijent prekida
konekciju. Klijentski TCP šalje RST+ACK paket i poništava sve podatke trenutno prisutne u baferu. Serverski
TCP takođe poništava podatke u svom baferu i obaveštava serverski proces o prekidu konekcije putem poruke o
grešci. Oba TCP-ja trenutno prelaze u stanje CLOSED.

Sl. 3-20 Prekidanje konekcije

3.3.6 Kontrola protoka

Kotrola protoka reguliše količinu podataka koju izvor može da pošalje pre nego što od odredišta primi potvrdu
prijema poslatih podataka. U ekstremnom slučaju, protokol transportnog sloja bi mogao da pošalje 1 bajt, a onda
da čeka na potvrdu pre nego što pošalje sledeći bajt. Međutim, ovo bi bio ekstremno spor proces. Ako podaci i
potvrde prelaze veliko rastojanje, izvor će najveći deo vremena biti pasivan, čekajući na potvrde.

74
Drugi ekstremni slučaj bio bi onaj kada protokol transportnog sloja šalje sve podatke koje ima, na primer, u vidu
niza uzastopnih segmenata maksimalne dužine bez čekanja na potvrde za pojedinačne segmente. Ovako bi
proces prenosa bio začajno ubrzan. Međutim, može se desiti da prijemnik bude pretrpan podacima koje ne može
tako brzo da prihvati i obradi. Osim toga, ako se pojedini segmenti izgude, dupliciraju ili stignu na odredište
izvan redosleda ili sa greškom, izvor neći imati povratnu informaciju sve dok odredište ne detektuje problem i
obavesti ga o tome. Prevazilaženje pomenutih problema može zahtevati ponavljanje prenosa, a količina
podataka koji se moraju ponovo poslati može biti velika, što nepotrebno zauzima kapacitet mreže i usporava
komunikaciju.
TCP nudi rešenje koje može ˝pomirit˝ dva pomenuta ekstremna slučaja. TCP uvodi tzv. prozor (eng. window) u
okviru predajnog bafera koji definiše koje od svih podataka trenutno prisutnih u predajnom baferu TCP sme da
pošalje. Veličina prozora se reguliše tzv. protokolom kliznog prozora (eng. sliding window protocol).
Protokol kliznog prozora
Suština protokola kliznog prozora je da predajnik vodi računa o preostalom prostoru u baferu prijemnika i šalje
samo onoliko bajtova koliko prijemnik može trenutno da prihvati. Prijemnik, sa druge strane, putem povratnih
segmenata ima obavezu da obaveštava predajnu stranu o veličini preostalog prostora u svom baferu. Za ovu
namenu koristi se polje Window Size (vličina prozora) iz zaglavlja TCP paketa.
Konkretno, predajnik koristi tri pointera koji sadrže tri karakteristična redna broja iz toka bajtova koji šalje.
Princip je ilustrovan na Sl. 3-21. Krajnji levi pointer sadrži redni broj za jedan veći od poslednje potvrđenog
bajta, odnosno redni broj prvog od bajtova koje je poslao, a za koje još uvek čeka potvrdu. Pointer u sredini
sadrži redni broj poslednje poslatog, a nepotvrđenog bajta. Krajni desni pointer je za vrednost veličine prozora
predajnika veći od krajnjeg levog pointera. Predajnik pretpostavlja da su bajtovi između krajnjeg levog i
srednjeg pointera još uvek u baferu prijemnika i zato će u sledećem segmentu poslati samo bajtove između
srednjeg i krajnjeg desnog pointera. Levi pointer se pomera udesno sa svakom primljenom potvrdom. Za isti
iznos se pomera i krajnji desni pointer. Na primer, ako u situaciji sa Sl. 3-21 stigne potvrda za pet bajtova, a pri
tome veličina prozora nije promenjena, krajnji pointeri se pomeraju za pet pozicija udesno, što daje mogućnost
za prenos ne više samo 3 već 8 bajtova. Srednji pointer se pomera udesno nakon slanja segmenta za iznos
poslatih bajtova. Ako prijemnik promeni veličinu prozora, pomera se samo desni pointer, dok levi i srednji
ostaju na istim pozicijama.

Sl. 3-21 Klizni prozor.

3.3.7 Kontrola grešaka

TCP je pouzdani transportni protokol. TCP isporučuje tok aplikacionih podataka sa jednog na drugi kraj
konekcije bez grešaka i bez delova koji su izgubljeni ili duplicirani. TCP postiže pouzdanost korišćenem
kontrole grešaka. Kontrola grešaka uključuje mehanizme za detekciju segmenata sa greškom, izgubljenih
segmenata, dupliciranih i segmenata primljenih izvan redosleda. Takođe, kontrola grešaka uključuje i
mehanizme za korekciju grešaka nakon što su one detektovane. Detekcija i korekcija grešaka kod TCP-ja se
postiže pomoću tri jednostavna principa: kontrolna suma, potrvrđivanje i retransmisija.
Kontrolna suma
Svaki TCP segment sadrži polje za kontrolnu sumu koje se koristi za proveru ispravnosti segmenta. Prijemnik
odbacuje svaki segment za koji, proverom kontrolne sume, ustanovi da sadrži grešku. Drugim rečima, pogrešni
segmenti se tretiraju na isti način kao izgubljeni segmenti (tj. kao da nisu ni primljeni).
Potvrđivanje
TCP koristi potvrđivanja (acknowledgments) da bi potvrdio prijem segmenta podataka. Kao što znamo, polje za
ACK broj iz zaglavlja TCP segmenta sadrži redni broj sledećeg bajta kojeg pošiljalac segmenta očekuje da
primi. Kod TCP-ja se koristi princip akumulativnog potvrđivanja. Naime, primljeni segment sa ACK brojem

75
postavljenim na vrednost x, TCP tumači kao potvrdu uspešnog prijema svih bajtova sa radim brojevima manjim
od x.
Generisanje potvrde
Postavlja se pitanje kada prijemnik treba da generiše (šalje) potvrde. Trivijalno rešenje, gde bi prijemnik
eksplicitno potvrđivao svaki uspešno primljeni segment podataka, slanjem nazad kontrolnog ACK segmenta,
nije efikasno. (Da bi vratio nazad 32-bitni ACK broj, prijemnik šalje celokupno zaglavlje od 40 bajtova).
Efikasnije rešenje je da prijemnik ne šalje ACK segmente, već da potvrdu za primljene podatke uvršćuje u
segmente kojima svoje podatke šalje drugoj strani. Međutim, šta ako prijemnik trenutno nema podatke za
slanje? Tokom evolucije TCP protokola, koristila su se različita pravila koja određuju pod kojim uslovima
prijemnik šalje potvrdu. Neka od njih biće navedena u nastavku.
1. Svaki segment podataka koji jedna strana šalje drugoj sadrži ACK broj postavljen na vrednost rednog
broja sledećeg bajta kojeg očekuje da primi. Na ovaj način smanjuje se broj segmenata potrebnih za
potvrđivanje.
2. Kada prijemnik primi očekivani segment (sa očekivanim rednim - SEQ brojem) u situaciji kada nema
svojih podataka za slanje, a sve prethodno primljene segmente je već potvrdio, prijemnik odlaže slanje
ACK segmenta sve do prijema sledećeg segmenta podataka ili do isteka unapred zadatog vremenskog
perioda (tipično 500 ms). Drugim rečima, prijemnik odlaže slanje ACK segmenta ako postoji samo
jedan nepotvrđeni segment. Ovo pravilo sprečava generisanje dodatnog saobraćaja radi slanja velikog
broja ACK segmenata.
3. Kada prijemnik primi očekivani segment u sitaciju kada prethodno primljeni segment još uvek nije
potvrdio, prijemnik odmah šalje ACK segment. Drugim rečima, na strani prijemnika ne bi trebalo da
postoji više od jednog nepotvrđenog segmenta. Na ovaj način, sprečava se nepotrebna retransmisija
segmenata zbog kašnjenja potvrde.
4. Kada prijemnik primi segment izvan redosleda, sa redni brojem većim od očekivanog (što ukazuje da je
segment sa očekivanim rednim brojem izgubljen u prenosu), prijemnik odmah šalje ACK segment sa
ACK brojem sledećeg očekivanog segmenta. Na ovaj način se inicira brza retransmislija segmenta koji
nedostaje.
5. Kada stigne segment koji nedostaje, prijemnik, bez čekanja, šalje ACK segment kojim predajnika
obaveštava o sledećem očekivanom rednom broju.
6. Ako primi duplicirani segment, prijemnik, bez čekanja, šalje ACK segment.
Retransmisija
Retransmisija (ponovno slanje) segmenata leži u osnovi kontrole grešaka. Svaki segment koji je primljen sa
greškom, izgubljen ili dupliciran u prenosu se ponovo šalje. Retransmisiji su podložni segmenti koji troše redne
brojeve (segmenti podataka i pojedini kontrolni segmenti, tj. oni koji zahtevaju potvrđivanje). Segmenti koji ne
troše redne brojeve, kao što je ACK segment se ne retransmituju. Segment se ponovo šalje u dva slučaja: vreme
retransmisionog tajmera je isteklo i prijemnik je primio tri duplicirana ACK segmenta.
Retransmisija nakon isteka RTO vremena
Kad god pošalje segment, TCP startuje retransmisioni tajmer (tzv. retransmission time-out (RTO) timer). Ako
potvrda prijema segmenta stigne pre nego što vreme tajmera (tzv. RTO vreme) istekne, tajmer se zaustavlja.
Međutim, ako RTO vreme istekne pre nego što stigne potvrda, odgovarajući segment se smatra izgubljenim ili
izmenjenim u prenosu i ponovo se šalje, čak iako izostanak prijema ACK-a može biti posledica povećanog
kašnjenja segmenta, kašnjenja ACK-a ili gubitka ACK-a u prenosu. Nešto kasnije u ovom poglavlju, videćemo
da se RTO vrednost dinamički podešava na osnovu procene vremena prenosa segmenta od predajnika do
prijemnika i nazad (round trip time - RTT). RTT je vreme potrebno da segment stigne do prijemnika plus vreme
potrebno da se potvrda vrati nazad do predajnika.
Retransmisija nakon tri duplicirana ACK segmenta
Prethodno pravilo za retransmisiju je dovoljno ako RTO vreme nije podešeno na previše malu vrednost.
Međutim, ponekada se može desiti da predajnik pre isteka RTO vremena izgubljenog segmenta pošalje veći broj
sledećih segmenta, toliko da sve njih prijemnik ne može da prihvati, zbog ograničenog prostora u svom baferu.
Da bi se ovakva situacija prevazišla, primenjuje se pravilo ˝tri duplicirana ACK-a˝, shodno kome predajnik, bez
obzira na RTO vreme koje još uvek nije isteklo, retransmituje segmen nakon što primi tri duplikata ACK
segmenta u kojima se kao ACK broj pojavljuje njegov SEQ broj. Ova osobina se naziva brzom retransmisijom.

76
Segmenti primljeni izvan redosleda
Kada neki segment zakasni, bude izgubljen ili odbačen zbog greške, segmenti koji slede biće primljeni izvan
redosleda. Kod prvobitnih implementacija TCP protokola, segmenti primljeni izvan redosleda su odbacivani, što
je kao posledicu imalo retransmisiju ne samo izgubljenog segmenta, već i svih sledećih, u međuvremenu
uspešno primljenih, segmenta. Kod većine savremenih implementacija, segmenti primljeni izvan redosleda se ne
odbaciju, već se privremeno čuvaju, sve dok ne stigne segment koji nedostaje. U svakom slučaju, segmenti
primljeni izvan redosleda se ne isporučuju aplikacionom programu - TCP garantuje isporuku podataka u
redosledu u kojem su poslati.
Scenariji
Normalni rad
Prvi scenario, ilustrovan na Sl. 3-22, odnosi se na dvosmerni prenos podataka između dva sistema. Klijentski
TCP šalje jedan segment, a serverski tri. Na Sl. 3-22 je naglašeno koje pravilo za generisanje potvrde se
primenjuje pri svakom potvrđivanju. Za klijentov prvi segment i sva tri serverska segmenta primenjuje se
pravilo 1. Svaki segment podataka sadrži ACK broj sledećeg bajta čiji prijem se očekuje. U situaciji kada klijent
primi prvi segment podataka od servera, pravilo 1 se ne može primeniti jer klijent nema više podataka koje bi
poslao. Zato klijent podvrđuje ovaj segment eksplicitno, slanjem ACK segmenta. Međutim, shodno pravilu 2,
potvrda se ne šalje odmah po prijemu segmenta, već sa kašnjenjem od 500 ms (kako bi se sačekalo na
eventualni novi segment podataka). Kada primi sledeći segment podataka (drugi serverov segment), klijent
započinje odmeravanje vremena kašnjenja potvrde. Međutim, pre isteka 500 ms, klijent dobija novi segment
(treći serverov segment). Prijemom ovog segmenta stvaraju se uslovi za primenu pravila 3 (dva nepotvrđena
segmenta) tako da klijent odmah generiše i šalje ACK segment.

Sl. 3-22 Normalni rad.

Izgubljeni segment
Ovaj scenario pokazuje šta se dešava ako je segment izgubljen ili primljen sa greškom. Prijemnik na isti način
tretira i izgubljene i pokvarene segmente. (Izgubljeni segment je uništen negde u mreži; segment primljen sa
greškom uništava sam prijemnik, tako da je krajnji efekat isti.) Na Sl. 3-23 je prikazana situacije kada je segment
izgubljen, tj. uništen od strane nekog rutera u mreži zbog, na primer, zagušenja.
U prikazanom scenariju, pretpostavlja se da je prenos jednosmeran: jedna strana šalje, a druga prima podatke.
Predjanik šalje segmente 1 i 2 koji se potvrđuju jednim ACK segmentom (pravilo 3). Međutim, segment 3 je
izgubljen, tako da prijemnik prima segment 4 izvan redosleda. Prijemnik smešta podatke iz ovog segmenta u
prijemni bafer, ali tako da ostavlja prazan prostor za bajtove koji nedostaju. Prijemnik bez čekanja šalje ACK
predajniku sa ACK brojem sledećeg očekivanog bajta (pravilo 4). Naglasimo da iako prijemnik smešta u bafer
bajtove 801 do 900, oni neće biti isporučeni aplikaciji sve dok se prazan prostor u baferu ne popuni bajtovim
koji nedostaju (701 do 800).

77
 Predajnik Prijemnik

Prijemni
Seq: 501 – 60 bafer
0
Ack: x

Seq: 601 – 70
0
Ack: x
RTO

Seq: 701 – 80
0
Ack: x
Izgubljen Šupljina
Seq: 801 – 90
0
Ack: x Pravilo 4

Segment primljen
Seq: 801 – 90 izvan redosleda
0
Ack: x Pravilo 5
retransmisija

Vreme Vreme

Sl. 3-23 Izgubljeni segment.

Iako predajnik koristi poseban RTO tajmer za svaki poslati segment, na Sl. 3-23 je prikazan samo RTO tajmer
izgubljenog segmenta, tj. segmenta 3. Pošto prijemnik ne šalje potvredu za izgubljeni segment, zadato vreme
RTO tajmera ističe i predajni TCP ponovo šalje segment 3. Ovog puta segment uspešno stiže do prijemnika, i
prijemnik ga potvrđuje bez čekanja (pravilo 5).
Brza retransmisija
Ovaj scenario ilustruje ideju brze retransmisije. Scenario je sličan prethodnom sa razlikom da je u ovom slučaju
RTO tajmer podešen na značajno duže vreme (Sl. 3-24). Predajnik nije svestan da je segment 3 izgubljen i
nastavlja da šalje sledeće segmente. Prijemnik prima četvrti, peti i šesti segment, smešta ih u bafer i za svaki od
njih (pridržavajući se pravila 4) ˝uporno˝ šalje potvrde za poslednji segment primljen u redosledu (ACK: 301).
Iako RTO vreme za segment 3 još uvek nije isteklo, u trenutku kada primi četvrtu potvrdu sa istim ACK brojem
(tri duplikata), predajnik, bez čekanja, ponavlja slanje segmenta 3, tj. segmenta kojeg, shodno ACK broju,
prijemnik očekuje.

Sl. 3-24 Brza retransmisija.

78
Zakasneli segmenti
Četvri scenario se odnosi na zakasnele segmente. TCP koristi usluge IP-a. TCP segmenti se enkapsuliraju IP
datagrame, a kao što znamo, datagrami mogu stići do konačnog odredišta različitim putanjama i sa različitim
kašnjenjima. S toga pojedini TCP segmenti mogu zakasniti više od drugih. Prijemnik tretira zakasnele segmente
na isti način kao i izgubljene ili segmente primljene sa greškom. Zakasneli segment su najčešći uzrok pojave
dupliciranih segmenata: segment kasni više nego što je uobičajeno; predajnik ne dobija potvrdu i ponovo šalje
isti segment. Posle izvesnog vremena prijemnik dobija oba segmenta, zakasneli i retransmitovani.
Duplicirani segment
TCP lako prepoznaje i odbacuje duplicirane segmente. Odredišni TCP očekuje kontinualni tok bajtova.
Primljeni segment sa redinim brojem manjim od rednog broja poslednje primljenog i potvrđenog bajta iz toka,
smatra se dupliciranim i odbacuje se.
Izgubljeni ACK
Prvi od dva scenarija koji se odnose na gubitak ACK segmenta opisuje situaciju kada se izgubljeni ACK
automatski zamenjuje sledećim ACK-om. Na Sl. 3-25(a) je prikazan gubitak ACK segmenta poslatog od strane
prijemnika nakon uspešnog prijema podataka. Odredišni TCP (predajnik) ne mora ni da primeti gubitak ACK
segmenta. TCP koristi princip akumulativnog potvrđivanja, tako da sledeći ACK, koji je uspešno primljen,
potvrđuje sve prethodne bajtove, sa rednim brojem manjim od ACK broja sadržanog u ACK segmentu,
uključujući i one koji su zbog gubitka prvog ACK segmenta ostali privremeno nepotvrđeni. Možemo reći da
sledeći ACK segment automatski koriguje prethodni, izgubljeni ACK segment.
Predajnik Prijemnik

RTO

Seq: 501 – 60
0
Ack: x

Seq: 601 – 70
0
Isteklo vreme

Ack: x
Ack: 701
Izgubljen

Seq: 501 – 600

Ack: x
retransmisija Ack: 701 Pravilo 6

Vreme Vreme
(a) (b)
Sl. 3-25 Izgubljena potvrda: (a) automatska zamena; (b) ponovno slanje segmenta.
Međutim, sledeći ACK segment ne mora da postoji (izgubljeni ACK je ujedno i poslednji ACK) ili može stići
dosta kasnije. U takvoj situaciji, korekcija se inicira RTO tajmerom na strani koja očekuje prijem ACK
segmenta (efekat je isti kao da je izgubljen segment podataka). Pošto potvrda ne stiže, predajnik retransmituje
segment. Retransmitovani segment se pojavljuje na strani prijemnika kao duplicirani segment. Prijemnik
odbacuje duplikat, ali zato, bez čekanja, ponovo šalje ACK (pravilo 6). Sl. 3-25(b) prikazuje ovaj scenario.
Uočimo da je retransmitovan samo jedan segment, iako dva segmenta nisu potvrđena.
Retransmisioni tajmer
Kao što je već napomenuto, uloga retransmisionog tajmera je merenje vremena čekanja na potvrdu segmanta.
Uvek kada pošalje segment, TCP kreira retransmisioni tajmer za taj konkretni segment. Mogu nastati dve
situacije:
1. Ako potvrda segmenta stigne pre nego što vreme tajmera istekne, tajmer se uništava.
2. Ako vreme tajmera istekne, a da pri tome potvrda za poslati segment još uvek nije stigla, segment se
retransmituje, a tajmer resetuje.
Postavlja se pitanje: koliko dugo treba čekati na potvrdu, tj. koliko treba da bude vreme RTO (Retransmission
time-out) na koje se podešava retransmisioni tajmer.

79
Potvrda prijema se često koristi i na nivou veze. Međutim, problem određivanja optimalnog vremena čekanja je
daleko teži na transportnom nego na nivou veze. Na nivou veze (npr. u LAN mreži tipa Ethernet) vreme
kašnjenja potvrde se može lako predvideti (ne varira puno). Tipična karakteristika vremena odziva na novu veze
prikazana je na Sl. 3-26(a). Vidi se da je u najvećem broju slučajeva vreme odziva 20 ms, sa relativno malim
odstupanjima. Pod ovakvim uslovima retransmisioni tajmer može biti postavljen na vreme koje je tek nešto duže
od očekivanog vremena kašnjenja (označeno vertikalnom isprekidanom linijom na Sl. 3-26(a)).

Vreme odziva Vreme odziva

(a) (b)
Sl. 3-26 (a) raspodela verovatnoće očekivanog vremena odziva na: (a) nivou veze; (b) na transportnom nivou.
Međutim, TCP radi u radikalno drugačijem okruženju. Kašnjenje u prenosu između dve tačke na Internetu
podložno je daleko većim varijacijama, a tipična funkcija raspodele očekivanog vremena odziva je oblika kao na
Sl. 3-26 (b). Svrha tajmera je da se detektuju situacije kada je segment izgubljen u prenosu. Međutim, ako je RTO
vreme isuviše kratko (T1 na Sl. 3-26(b)), može se desiti da predajnik bespotrebno retransmituje segmente, jer
potvrda nema ne zato što su segmenti izgubljeni nego zato što prenos potvrde traje duže nego obično. Sa druge
strane, ako je RTO vreme previše dugo (T2 na Sl. 3-26(b)), u situacijama kada zaista segment zaista bude
izgubljen, prenos će biti privremeno obustavljen, sve dok ne istekne predviđeno vreme čekanja. Šta više, u
dužim vremenskim intervalima karakteristika sa Sl. 3-26(b) se može menjati, kao posledica promenjenih uslova
u mreži.
Izbor RTO vremena zasnovan je na procena trenutnog vremena odziva, tzv. RTT vremena (Round-Trip Time).
Međutim, izračunavanje RTT vremena je složen proces, koji zahteva postepeno objašnjenje.
Izmereno RTT. Izmereno RTT vreme (u oznaci RTTM) segmenta je vreme od trenutka slanja segmenta do
trenutka prijema potvrde za poslati segment. U toku trajanja konekcije, TCP neprekidno meri i ažurira RTT M.
Merenje RTT-a se komplikuje činjenicom da između segmenta i potvrde ne postoji relacija 1-1: jedan segment
potvrde (ACK) može da potvrdi više semenata podataka. Kod TCP-ja uvek je u toku najviše jedno aktivno
merenje RTT vremena. To znači da kada merenje RTT vremena jednom započne ono se mora okončati pre nego
što se započne sledeće.
Uravnoteženo RTT. Izmereno RTT, RTT M, se menja od merenja do merenja. Na savremenom Internetu
fluktuacije ovog vremena su toliko velike da se ono ne može koristiti za podešavanje retransmisionog tajmera.
Većina realizacija TCP protokola koristi uravnoteženo RTT, u oznaci RTT S, koje se izračunava na sledeći način:
Početno => nema vrednost
Posle prvog merenja => RTTS = RTTM
Posle svakog sledećeg merenja => RTTS = (1-α)RTTS + α RTTM

Parametar α određuje kolika težina se daje staroj vrednosti RTTS, a kolika novoizmerenom RTTM. Tipično se
usvaja α=7/8. Ako je RTTM manje od trenutnog RTTS, RTTS će biti smanjeno i obrnuto. Međutim, ova promena
neće biti nagla, zbog α, već postepena.
RTT devijacija. Kod većina realizacija, pored RTT S, izračunava se i devijacija RTT-a, u oznaci RTT D, na sledeći
način:
Početno => nema vrednost
Posle prvog merenja => RTTD = RTTM/2
Posle svakog sledećeg merenja => RTTD = (1-β)RTTD + β |RTTS - RTTM|

Tipično se usvaja, β=1/4.

RTO vreme. Konačno, vrednost RTO se izračunava na osnovu uravnoteženog RTT i njegove devijacije. Kod
većina realizacija koristi se sledeća formula:

80
 Početno => Početna vrednost
Posle svakog merenja => RTO = RTTS + 4 RTTD

Pr. 3-1: Razmotrimo jedan hipotetički primer. Na Sl. 3-27 je prikazan deo jedne konekcije (uspostavljanje
konekcije i deo faze prenosa podataka).
Predajnik Prijemnik

RTTM = RTTS = SYN

RTTD = RTO = 6.00 Seq: 1400 Ack
:

1.50 s
SYN + ACK
k: 1401
RTTM = 1.5 RTTS = 1.50 Seq: 4000 Ac
RTTD = 0.75 RTO = 4.50 ACK
Seq: 1400 Ac
k: 4001

Podaci
Seq: 1401 Ac
k: 4001
Podaci: 1401
- 1500
Podaci
Seq: 1501 Ac
k: 4001
2.50 s
Podaci: 1501
- 1600
ACK
k: 1601
RTTM = 2.50 RTTS = 1.625 Seq: 4000 Ac
RTTD = 0.78 RTO = 4.74

Vreme Vreme

Sl. 3-27 Primer Pr. 2-24.

1. U trenutku slanja SYN segmenta ne postoje vrednosti za RTTM, RTTS i RTTD, a RTO je postavljeno na
početnu vrednost 6.00 s.
2. U trenutku prijema SYN+ACK segmenta, izmereno je RTTM = 1.5 s. Ažurirane vrednosti relevantnih
promenljivih su:
RTTM = 1.5
RTTS = 1.5
RTTD = 1.5/2 = 0.75
RTO = 1.5 + 4*0.75 = 4.5
3. Merenje nove RTT vrednosti počinje u trenutku slanja prvog segmenta podataka. Uočimo da predajnik ne
započinje merenje RTT vremena kada šalje ACK segment, zato što ACK segment ne troši redne brojeve i nema
definisan time-out. RTT vreme se ne meri ni za drugi segment podataka, zato što je jedno RTT merenje već u
toku. Merenje RTT-a se završava prijemom poslednjeg ACK segmenta. Iako poslednji ACK segment potvrđuje
oba poslata segmenta podatka (akumulativno potvrđivanje), trenutak njegovog dolaska označava kraj RTTM
vremena prvog segmenta podataka. Ažurirane vrednosti promenljivih su:
RTTM = 2.5
RTTS = 7/8 * 1.5 + 1/8 * 2.5 = 1.625
RTTD = 3/4 * 7.5 + 1/4 * |1.625 - 2.5| = 0.78
RTO = 1.625 + 4*0.78 = 4.74
Karnov algoritam
Pretpostavimo da u toku retransmisionog perioda segment nije potvrđen i da je zbog toga retransmitovan. Kada
predajni TCP konačno primi potvrdu, ostaje dilema da li je to potvrda za prvobitni ili za retransmitovan segment
(jer, može se desiti da prvobitni segment nije izgubljen u prenosu, već je samo zakasno). Iz tog razloga RTT se
ne meri za retransmitovane segmente. Drugim rečima, u obzir se uzima samo RTTM za segmente koji nisu
retransmitovani.
Eksponencijalni backoff
Postavlja se pitanje: koju vrednost za RTO izabrati nakon retransmisije segmenta ? Kod većine realizacija TCP
protokola koristi se strategija eksponencijalnog backoff-a. RTO vrednost se duplira sa svakom uzastopnom
retransmisijom. Nakon prve retransije segmenta, RTO postaje 2*RTO, posle druge uzastopne retransmisije
4*RTO i td.

81
Pr. 3-2: Sl. 3-28 je nastavak Pr. 3-1 i ilustruje primenu Karnovog algoritma i uticaj retransmisije na RTO vreme.

Sl. 3-28 Primer Pr. 3-2

Prvi segment sa Sl. 3-28 je posalat i izgubljen. Vreme RTO tajmera ističe nakon 4.74 s. Segment se
retransmituje, a tajmer se podešava na dvostruku prethodnu RTO vrednost (2*4.74 = 9.48). Ovog puta, ACK se
prima pre isteka vremena čekanja. Uočimo da RTT nije mereno za retransmitovan segment (Karnov algoritam).

3.3.8 Kontrola zagušenja

Zagušenje u mreži nastaje kada opterećenje mreže (broj paketa poslatih u mrežu) postane veće od kapaciteta
mreže (broj paketa koje mreža može da prihvati). Cilj kontrole zagušenja je održavanje opterećenja mreže ispod
kapaciteta mreže, tj. regulacija broja paketa u mreži ispod nivoa pri kome performanse mreže počinju naglo da
padaju.
Zagušenje je posledica postojanja redova čekanja u ruterima (tj. bafera u kojima se čuvaju paketi pre nego što
stignu na red za obradu). Na primer, ruter poseduje par redova čekanja, ulazni i izlazni, za svaki mrežni
interfejs. Sa jedne strane, ako je brzina pristizanja paketa veća od brzine obrade paketa, ulazni redovi čekanja se
pune i postaju sve duži i duži. Sa druge strane, ako je brzina kojom se paketi isporučuju sledećim ruterima
manja od brzine obrade paketa, pune se izlazni redovi čekanja. U suštini, Internet se može posmatrati kao
ogromna mreža redova čekanja.
Performanse mreže
Dve osnovne mere koje karakterišu performanse mreže i nivo zagušenja u mreži su: kašnjenje i propusnost.
Kašnjenje vs. Opterećenje
Na Sl. 3-29(a) je prikazana zavisnost kašćenja paketa od opterećenja mreže. Kada je opterećenje mnogo manje
od kapaciteta mreže, kašnjenje paketa je minimalno. Minimalno kašnjenje čine dve konstantne komponente:
propagaciono kašnjenje signala na prenosnim linijama i kašnjenje usled obrade paketa u ruterima. Oba ova
kašnjenja su gotovo zanemarljiva. Međutim, kada se opterećenje približi kapacitetu mreže, kašnjenje naglo raste
zato što sada ukupnom kašnjenju treba dodati i treću komponentu: vreme čekanja u redovima čekanja (u svim
ruterima na putanji paketa). Vreme čekanja je promenljivo i raste sa dužinom redova čekanja. Što je opterećenje
veće, to će i redovi čekanja biti duži, a time i prosečno kašnjenje paketa veće. Za opterećenje veće od kapaciteta
mreže, kašnjenje je beskonačno.
Postoji jednostavno, intuitivno objašnjenje ˝beskonačnog˝ kašnjenje. Pretpostavimo da svi ruteri u mreži
poseduju bafere beskonačne dužine i da opterećenje prevazilazi kapacitet mreže. Obzirom da broj paketa koje
mreža može da isporuči ne može biti veći od njenog kapaciteta, višak paketa koji se ubacuje u mrežu gomila se
u redovima čekanja. Vremenom dužina redova čekanja neograničeno raste, a time i vreme čekanja paketa u
redovima čekanja.

82
 Opterećenje
(a)

(1)
B
A (2)

Nema
zagušenja
Opterećenje
Kapacitet
(b)
Sl. 3-29 Zavisnost kašnjenja i propusnosti od opterećenja mreže.
Propusnost vs. Opterećenje
Propusnos mreže jednaka je broju paketa prenetih kroz mrežu u jedinici vremena. Na Sl. 3-29(b) je prikazana
propusnost u funkciji opterećenja mreže. Kriva (1) prikazuje idealnu, a kriva (2) realnu zavisnost. U idealnim
uslovima, za opterećenja manja od kapaciteta mreže, propusnost je jednaka opterećenju, zato što svi paketi koje
izvori šalju u mrežu stižu do svojih odredišta. Za opterećenja veća od kapaciteta mreže, popusnost je konstantna
i jednaka kapacitetu mreže, zato što bez obzira na broj poslatih paketa, mreža ne može da prenese veći broj od
svog kapaciteta. Međutim, idealni slučaj podrazumeva bafere beskonačne dužine kao i nepostojanje bilo kakvog
trošenja kapaciteta mreže na neke druge aktivnosti (kao što je kontrola zagušenja) osim prenosa podataka.
Napomenimo još jedanput, da se u idelnom slučaju, čak i pri opterećenju većem od kapaciteta, paketi ne gube,
već se gomilaju u baferima koji su dovoljno veliki da pihvate svaki novi paket. Međutim, vremenom, broj
paketa u redovima čekanja neograničeno raste, a time i prosečno kašnjenje paketa.
Razmotrimo sada šta se dešava u mreži sa baferima konačne dužine, u kojoj nije implementiran bilo kakav
mehanizam kontrolu zagušenja (kriva (2)). Pri niskom opterećenju, propusnost prati idalnu karakteristiku (baferi
u riterima, iako konačne dužine, dovoljno su veliki da prihavate sve poslate pakete). Sa porastom opterećenja
dolazi se do tačke (tačka A na krivoj (2)) posle koje propusnost mreže i dalje raste ali sporije od porasta
opterećenja - kažemo da je mreža u stanju umerenog zagušenja. U ovom regionu, mreža i dalje uspeva da se
˝izbori˝ sa povećanim opterećenjem (mada na račun povećanog kašnjenja paketa). Odstupanje propusnosti od
idalne, posledica je brojnih uzroka. Malo je verovatno da će saobraćaj biti ravnomerno raspodeljen u mreži i da
će svi ruteri biti jednako opterećeni. Tako, dok neki rade u uslovima umerenog opterećenja, neki drugi mogu biti
preopterećeni i biti u situaciji da zbog nedostatka baferskog prostora uništavaju pojedine pakete. Uz to, sa
porastom opterećenja, mreža će pokušavati da uravnoteži opterećenje preusmeravajući saobraćaj iz
preopterećenih u manje opterećene oblasti. Kao posledica toga, paketi se prenose dužim putanjama od
optimalnih, tj. prenose se kroz veći broj rutera, što povećava prosečno angažovanje resursa mreže (bafera) na
prenosu jednog paketa. Takođe, povećava se i broj paketa koji se razmenjuju između samih rutera, a koji služe
za distribuciju informacija o nivou zagušenja rutera i pojedinih delova mreže.
Sa daljim povećanjem opterećenja mreže, redovi čekanja u ruterima nastavljaju da rastu. Konačno, dolazimo do
tačke (tačka B na krivoj (2)) posle koje, sa porastom opterećenja, propusnost umesto da raste počinje da opada.
Razlog je u konačnoj dužini bafera u ruterima. Kada se bafer u ruteru napuni, ruter nema drugu soluciju nego da
uništava novopridošle pakete. To znači da izvori osim novih u mrežu šalju i retransmitovane uništene pakete. To
dodatno pogoršava situaciju, jer retransmisija paketa dodatno povećava opterećenje mreže i sve veći broj bafera
postaje pun. Dok se sistem, sa jedne strane, oslobađa viška paketa koji njegov kapacitet ne može da podnese,
korisnici sistema uporno ubacuju u sistem i nove i stare pakete. Čak i uspešno isporučeni paketi mogu biti
retransmitovani, zbog velikog kašnjenja potvrde (izvor, pošto nikako ne dobija potvrdu, zaključuje da je paket
izgubljen). Pod ovakvim uslovima, a pri daljem povećanju opterećenja, propusnost mreže postepeno pada na
nulu.
Mehanizmi za kontrolu zagušenja
Kontrola zagušenja je pojam koji se odnosi na tehnike i mehanizme koji se koriste za sprečavanje zagušenja, pre
nego što se ono desi, ili za eliminaciju zagušenja, nakon što se desi. Uošteno govoreći, mehanizmi za kontrolu

83
zagušenja se mogu svrstati u dve široke kategorije: kontrola zagušenja u otvorenoj petlji (sprečavanje zagušenja)
i kontrola zagušenja u zatvorenoj petlji (eliminacija zagušenja).
Kontrola zagušenja u otvorenoj petlji
Motodi za kontrola zagušenja u otvorenoj petlji se primenjuju da bi se sprečila pojava zagušenja. Kod ovih
mehanizama, za kontrolu zagušenja je zadužen ili izvor ili odredište. Slede kratka objašnjenja nekoliko
mehanizama iz ove kategorije.
Politika retransmisija. Dobra politka (strategija) retransmisije može da spreči pojavu zagušenja. Eksponencijalni
backoff mehanizam koji udvostručava vreme čekanja potvrde (RTO vreme) pri svakoj sledećoj retransmisiji
segmenta je dobar primer mehnizma koji povoljno utiče na sprečavanje zagušenja. Kao što je već rečeno, pri
velikom opterećenu mreže, retransmisija uništenih paketa doprinosi dodatnoj redukciji propusnosti. Ponavljanje
retransmisije istog segmenta je simptom zagušenja, a udvostručavanje RTO vremena je pokušaj izvora da u
takvim uslovima redukuje broj retransmitovanih paketa koje ubacuje u mrežu.
Politika potvrđivanja. Politika potvrđivanja koju sprovodi prijemnik može imati uticaja na zagušenje. Na
primer, ako prijemnik, umesto da potvrđuje svaki ili svaki drugi segment, pređe u režim potvrđivanja svakog n-
tog segmenta, usporiće predajnika i u isto vreme pomoćiće u prevenciji zagušenja.
Kontrola zagušenja u zatvorenoj petlji
Mezanizmi za kontrolu zagušenja u zatvorenoj petlji pokušavaju da prevaziđu zagušenje nakon što se ono
pojavilo. Različiti protokoli koriste različite mehanizme iz ove kategorije, a nekoliko njih će biti opisani u
nastavku.
Potisak (Back Pressure). Ruter koji je postao zagušen, može zatražiti od prethodnog rutera da redukuje brzinu
slanja paketa. Ruter kojem je zahtev upućen vremenom će i sam postati zagušen (zato što se sporije oslobađa
primljenih paketa) i uputiće identičan zahtev sebi prethodnom ruteru. Na ovaj način, informacija o nastalom
zagušenju se rekurzivno prenosi unazad sve do primarnih izvora od kojih se zahteva da smanje opterećenje
mreže. Nakon redukcije opterećenja (brzine slanja novih paketa), zagušenje će početi postepeno da se otklanja.
Kontrolni (chocke) paket. Kontolni paket je paket koji se generiše u zagušenom ruteru i šalje nazad izvornom
hostu sa zahtevom da redukuje brzinu slanja paketa. Primer chocke paketa je ICMP poruka za prigušenje izvora
(Source Quench paket, sekcija 0). Po prijemu choke paketa, izvor smanjuje brzinu slanja paketa odredištu na
koje se poruka odnosi. Kada choke paketi prestanu da dolaze, izvor uspostavlja prvobitni intenzite slanja paketa
datom odredištu.
Implicitna signalizacija. Sam izvor, bez pomoću rutera, može na neki posredan način da detektuje izvesne
signale koji upozorenja o mogućem zagušenju u mreži i da nakon toga samnji brzinu slanja paketa. Na primer,
povećano kašnjenje u prijemu potvrda (ACK) može biti signal da je mreža zagušena.
Eksplicitna signalizacija. Ruter izložen zagušenju, može poslati ekplicitan signal, na primer, postavljanjem
nekog posebnog bita u paketima koje prosleđuje, kao bi pošiljaoca ili primaoca paketa obavestio o pojavi
zagušenja. Uočimo da kod konekcijonih protokola (kao što je TCP) paketi se prenose u oba smera (podaci u
jednom, potvrde u suprotnom smeru), tako da će informaciju o zagušenju dobiti i izvor, a ne samo odredište, čak
iako je komunikacija jednosmerna.
Kontrola zagušenja kod TCP protokola
Prozor zagušenja
U izlaganju o kontroli protoka opisano je rešenje problema pretrpavanja prijemnika podacima. Rečeno je da se
veličina prozora predajnika određuje shodno rasploživom slobodnom prostoru u baferu prijemnika (rwnd).
Drugim rečima, veličinu prozora predajnika diktira prijemnik. Tom prilikom u potpunosti smo ignorisali uticaj
mreže, jer ako mreža ne može da isporuči podatke brzinom kojom ih predajnik generiše, ona mora na neki način
da obavestiti predajnika da treba da uspori. Dakle, pored prijemnika, mreža je drugi entitet koji određuje
veličinu prozora predajnika. Odnosno, veličina prozora predajnika ne određuje samo prijemnik već zavisi i od
zagušenja u mreži. Konkretno, predajnik poseduje dve informacije: veličina prozora koju zahteva prijemnik
(rwnd) i veličina prozora zagušenja (cwnd), a stvarna veličina prozora je jednaka minimalnoj od ove dve, tj.
min(rwnd, cwnd).
Strategija koju TCP primenjuje za prevazilaženje zagušenaj podrazumeva tri faze: spori start, izbegavanje
zagušenja i detektcija zagušenja. U prvoj fazi, spori start, predajnik počinje prenos podataka veoma malom
brzinom, a zatim naglo povećava brzinu prenosa sve dok ne dostigne zadatu granicu. Kada je granična brzina
prenosa dostignuta, brzina se smanjuje kao bi se izbegno zagušenje. Konačno, ako se zagušenje detektuje,

84
predajnik se vraća u režim sporog starta, ili izbegavanja zagušenje zavisno od načina na koji je zagušenje
detektovano.
Spori start
Što je prozor predajnika veći, to će predajnik moći da pošalje veći broj segmenata pre nego što će morati da
čeka na njihovu potvrdu. U ustaljenom režimu rada, fleksibilni mehanizmi za potvrđivanje i retransmisiju su
obično dovoljni da definišu tempo rada predajnika usaglašen sa trenutnim uslovima u mreži. Međutim, problem
postoji na samom početku konekcije, kada povratne informacije o vremenu odziva i učestalosti gubitka paketa
još uvek nisu dostupne.
Strategija koja bi se mogla primeniti bila bi ta da predajnik započne rad sa realativno velikim ali ne i
maksimalnim prozorom, nadajući se da će tokom trajanja konekcije uspeti da podesi optimalnu veličinu.
Međutim, ovakav pristup je rizičan, jer predajnik može da preplavi Internet mnoštvom segmenata pre nego što
shvati, na osnovu izostalih potvrda, da je intenzitet mrežnog saobraćaja kojeg je generisao ipak isuviše veliki.
Umesto toga, predajnika počinje rad postepeno povećavajući prozor do optimalne veličine. Princip sporog
startovanja ilustrovan je na Sl. 3-30.

Sl. 3-30 Spori start, ekponencijalno povećanje.

Kada je nova konekcija uspostavljena, TCP inicijalizuje cwnd na 1. (Radi pojednostavljenja, veličinu prozora
izražavaćemo brojem segmenata, a ne brojem bajtova). Drugim rečima, predajniku je dozvoljeno da pošalje
samo jedan segment, a onda mora da čeka na njegovu potvrdu, pre nego što nastavi dalje. Svaki put kada primi
potvrdu za poslate segmente iz prozora, TCP udvostručava veličinu prozora. Tako, po prijemu potvrde za prvi
segment, TCP postavlja cwnd=2, što znači da sada može da pošalje dva segmenta. Kada primi potvrdu za ova
dva segmenta, TCP postalja cwnd=4. Nakon što ova 4 segmenta budu poslata i potvrđena, nova veličina prozora
biće cwnd=8, i td.
Spori start ne može da traje u nedogled. Mora da postoji granična vrednost na kojoj će se zaustaviti proces
uvećanja brzine slanja segmenata. Vrednost ove granica se čuva u posebnoj promenljivoj, tzv. sstresh (slow
start treshold). Kada veličina prozora dostigne vrednost sstresh, faza sporog startovanja se završava i počinje
sledeća.
Izbegavanje zagušenja: linearno povećanje
U fazi sporog starta, veličina prozora se eksponencijalno povećava. Da bi se izbeglo zagušenje, pre nego što
nastane, neophodno je usporiti eksponecijalni rast. TCP koristi drugi algoritam, tzv. izbegavanje zagušenja, koji

85
linearno, a ne eksponencijalno, povećava veličinu prozora. Kada veličina prozora dostigne granicu sporog starta
(sstresh), faza sporog starta se završava, a počinje linearna faza. U ovoj fazi, nakon prijema potvrde za sve
segmente iz prozora, veličina prozora zagušenja se uvećava za 1. Rad ovog algoritma ilustrovan je na Sl. 3-32.
Linearno povećanje prozora traje sve dok se ne detektuje pojava zagušenja.

Sl. 3-31 Izbegavanje zagušenja: linearno povećanje.

Detekcija zagušenja: multiplikativno smanjenje
Nakon pojave zagušenja, veličina prozora zagušenja mora biti smanjena. Jedini način kako predajnik može
naslutiti da se u mreži nastalo zagušenje jeste potreba za retransmisijom segmenata. Međutim, do retransmisije
može doći iz dva razloga: kada vreme RTO tajmer istekne, ili kada su primljena tri identična ACK segmenta (sa
istim ACK brojem). U oba slučaja, TCP smanjuje vrednost granice sstresh na pola (multipikativno smanjenje).
Pri tome:
Slučaj 1. (Vreme RTO tajmera je isteklo). Istek vremena čekanja na potvrdu, posledica je gubitka segmenta ili
potvrde, i s toga ukazuje, sa velikom verovatnoćom, na mogućnost zagušenja. Zato, u ovom slučaju, TCP
drastično reaguje:
- Postavlja graničnu veličinu prozora na polovinu trenutne veličine prozora (sstresh = cwnd/2).
- Postavlja na 1 veličinu prozora zagušenja (cwnd = 1).
- Ponovo startuje fazu sporog starta.
Slučaj 2. (tri ponovljena ACK-a). Prijem tri ponovljena ACK-a takođe ukazuje, ali sa značajno manjom
verovatnoćom u odnosu na prethodni slučaj, na mogućnost zagušenja. Neki segment može biti uništen, ali, pošto
su primljena tri ACK-a, segmenti koji slede su uspešno preneti. Ovakva situacija se zove brza retransmisija i
brzi oporavak. U ovom slučaju reakcija TCP-ja je blaža i uključuje sledeće korake:
- Postavlja graničnu veličinu prozora na polovinu trenutne veličine prozora (sstresh = cwnd/2).
- Postavlja veličinu prozora zagušenja na graničnu vrednost (cwnd = sstresh)
- Vraća se na fazu izbegavanja zagušenja.
Pr. 3-3 Kontrola zagušenja kod TCP-ja
Na Sl. 3-32 je ilustrovane rad sve tri faze izbegavanja kolizije kod TCP-ja. Usvojena maksimalna veličina
prozora je 32 segmenta. Granična veličina je postavljena na 16 (polovina od maksimalne veličine). U fazi
sporog strata, veličina prozora kreće od 1 i eksponencijalno raste sve dok ne dostigne granicu. Nakon dostizanja
granice, veličina prozora nastavlja da raste, ali sada linearno (shodno proceduru izbegavanja kolizije – linearno
povećanje). Linearni rast traje sve dok se ne dostigne maksimalna veličina prozora ili se ne desi istek vremena

86
RTO tajmera. U primeru sa slike, vreme RTO tajmera je isteklo pri veličini prozora od 20 segmenta. U tom
momentu, pokreće se procedura multiplikativnom smanjenja koja smanjuje veličinu granice na polovinu
trenutne veličine prozora (tj. na 10 segmenata).
cwnd

26
24
22
Isteklo vreme
20
18 Multiplikativno
sstresh = 16
16 smanjene
14
3-ACK
12
Linearno sstresh = 10
10
Spori povećanje
08 Spori

povećanje
start

Linearno

povećanje
06 start

Lin.
04
02

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
RTT
Sl. 3-32 Primer zagušenja.
TCP se vraća u režim sporog startovanja počev od veličine prozora 1, a kada dostigne vrednost nove granice
prelazi na linerano povećanje. U trenutku kada je veličina prozora dostigla 12 segmenata, dešava se prijem tri
ponovljena ACK-a. Procedura multiplikativnog smanjenja se ponovo startuje. Kao i u slučaju isteklog vremena,
granica se postavlja na polovinu trenutne veličine prozora (6 segmenata), ali se zato veličina prozora ne spušta
na 1 segment, već na vrednost nove granice (6 segmenata), a TCP prelazi u fazu linearnog povećanja. TCP
ostaje u ovoj fazi sve do novog isteka RTO vremena ili nova tri-ACK-a.

87
4 Aplikacioni sloj
TCP/IP je projektovan pre OSI modela i zato njegovi slojevi nisu u potpunosti usklađeni sa slojevima koje
predviđa OSI. TCP/IP ima pet nivoa: niža četiri se uklapaju u niža četiri sloja OSI modela. Međutim, peti,
aplikacioni sloj TCP/IP-a ekvivalentan je kombinaciji prezentacionog, sloja sesije i aplikacionog sloja OSI
modela. To znači da se funkcije predviđene ovim slojevima kod TCP/IP obuhvaćene jednim slojem.
Slojevi ispod aplikacionog obezbeđuju pouzdani prenos podataka. Međutim, osim mogućnosti komuniciranja,
oni ne pružaju neki drugi servis koji je od direktne korisni krajnjem korisniku. Tek na vršnom sloju nalazimo
realne mrežne aplikacije. Međutim, i na ovom nivou postoji potreba za protokolima koji će omogućiti
aplikacijama da funkcionišu.
U ovom poglavlju razmatraćemo tri aplikacije (tj. aplikaciona protokola) koje se tradicionalno smatraju
obaveznim elemantima TCP/IP-a: TELNET, FTP i SMTP. TELNET pruža servis logovanja na daljinu koji
omogućava korisniku na terminalu ili personalnom računaru da se loguje i koristi udaljeni računar na isti način
kao da je direktno povezan sa tim računarom. FTP (File Transfer Protocol - Protokola za prenos fajlova) se
koristi za prenos fajlova od jednog na neki drugi sistem. SMTP (Simple Message Transfer Protocol) pruža
osnovnu podršku za razmenu elektronske pošte.

4.1 Klijent-server model

Za korišćenje servisa dostupnih na Internetu neophodni su aplikacioni programi koji se izvršavaju na dva krajnja
računara i međusobno komuniciraju. Na Internetu, aplikacioni programi su ti koji komuniciraju, ne računari ili
korisnici.
Aplikacioni programi koji koriste Internet zasnovani su na obliku distribuiranog procesiranja koji se zove
klijent-server model. Pod ovim modelom podrazumeva se sledeća strategija:
Jedan aplikacioni program, klijent, koji se izvršava na lokalnoj mašini, zahteva uslugu (servis) od drugog
aplikacionog programa, server, koji se izvršava na udaljenoj mašini (Sl. 4-1).
Server nudi usluge mnogim klijentima, a ne samo nekom konkretnom klijentu. Drugim rečima, klijent-
server model odgovara relaciji tipa: ˝više-prema-jedan˝: više klijenata može koristiti servise jednog servera.
U opštem slučaju, klijentski program se izvršava samo onda kada je usluga servera potrebna. Sa druge
strane, serverski program, koji pruža uslugu, trebalo bi da radi sve vreme, zato što unapred ne zna kada će
neki klijent zatražiti uslugu.
Servisi koji su često potrebni mnogim korisnicima podržani su specifičnim aplikacionim programima. Na
primer, trebalo bi da postoji aplikacioni program koji će omogućiti korisnicima da pristupaju udaljenim
fajlovima, razmenjuju elektronsku poštu i td. S obzirom na opštost primene, servisi ovog tipa su podržani
odgovarajućim protokolima aplikacionog sloja.
Klijent Server

Internet

Sl. 4-1 Klijent-server model

Klijent je program koji se izvršava na lokalnoj mašini i zahteva uslugu servera. Klijentski program je konačan,
što znači da se pokreće od strane korisnika (ili drugog aplikacionog programa) kada je usluga potrebna i
završava kada je usluga dobijena.
Server je program koji se izvršava na udaljenoj mašini i pruža usluge klijentima. Kada je jednom startovan,
server je dostupan mnogim klijentima, ali nikada ne pokreće servis, a da on nije zatražen. Serverski program je
beskonačan (nikada se ne završava, osim u slučaju nekih abnormalnih situacija) i neprekidno čeka na zahteve
klijenata. Kada zahtev stigne, server odgovara na zahtev.

88
4.2 TELNET
Glavni zadatak Interneta i TCP/IP-ja je da obezbede mrežne servise korisnicima. Na primer, korisnici bi želeli
da mogu da izvršavaju različite aplikacione programe na udaljenim računarima, a da kreirane rezulte potom
prenesu na svoj lokalni računar. Jedan način kako se može ostvariti ovaj zahtev jeste da se kreira poseban
klijent-server aplikacioni program za svaki od potrebnih servisa. Programi kao što su programi za FTP, e-mail i
td., su primeri ovakvog pristupa. Međutim, bilo bi nemoguće napisati aplikacioni program za svaku iskazanu
potrebu.
Bolje rešenje je klijent-server program opšte namene, koji će omogućiti korisniku da pristupi bilo kom
aplikacionom programu na udaljenom računaru. Drugim rečima, da omogući korisniku da se prijavi za rad
(login-uje) na udaljenom računaru. Nakon prijavljivanja, korisnik može da koristi servise dostupne na
udaljenom računaru i prenese rezultate nazad na svoj računar.
TELNET je upravo takav klijent-server program. TELENT omogućava uspostavljanje konekcije sa udaljenim
sistemom na način da se lokalni terminal ponaša kao da je terminal tog udaljenog sistema.
Koncepti
Sistemi sa raspodelom vremena
TELENT je razvijen u vreme kada su većina operativnih sistema, kao što je UNIX, podržavali koncept
raspodele vremena koji je omogućavao da više korisnika koristi jedan veliki računar. Kod ovakvih sistema,
interakcija između korisnika i računara se ostvaruje putam terminala (kombinacija tasture, monitora i eventualno
miša). Celokupna obrada se obavlja na centralnom računaru, a terminali se koriste za unos podataka i prikaz
rezultata. Operativni sistemi sa raspodelom vremena kreiraju iluziju da svaki korisnik radi na izdvojenom,
namenskom računaru. Korisnik može da pokrene program, pristupa sistemskim resursima, prelazi iz jednog u
drugi program i slično.
Lokalni Login
U sistemima sa raspodelom vremena, svaki korisnik poseduje izvesna prava pristupa sistemskim resursima.
Svaki autorizovani korisnik poseduje identifikaciju (u vidu korisničkog imena) i lozinku. Da bi pristupio
sistemu, korisnik se prijavljuje za rad (kaže se, korisnik se loguje) navodeći svoje korisničko ime i lozinku.
Kada se korisnik prijavi za rad na lokalnom sistemu sa raspodelom vremena (putem korisničkog imena i
lozinke) kaže se da je korisnik izvršio lokalni login. Kako korisnik kuca na tastaturi terminala, svaki pritisak na
dirku se prenosi drajveru terminala. Drajver terminala prenosi karaktere (znaci koji odgovaraju dirkama)
operativnom sistemu. Operativni sistem, interpretira kombinaciju karaktera i poziva odgovarajući aplikacioni
program (Sl. 4-2).

Sl. 4-2 Lokalni login.

Mehanizam ipak nije tako jednostavan, kao što izgleda, zato što operativni sistem može dodeliti posebno
značenje pojedinim specijalnim karakterima. Na primer, kod UNIX-a, pojedine kombinacije karaktera imaju
posebno značenje, kao što je kombinacija kontrolnog karaktera, ˝Ctrl˝, i karaktera ˝z˝, koja označava suspenziju,
ili kombinacija Ctrl-c, koja označava trenutni prekid programa.
Udaljeni login
Kada korisnik pristupa aplikacionom programu lociranom na udaljenom računaru, on obavlja udaljeni login
(remote login). TELNET je posrednik u ovoj interakciji. Klijentska strana TELNET aplikacije izvršava se na
strani korisnika, a serverska na strani udaljenog računara. Pritisak na dirku tastature lokalnog terminala prenosi

89
se terminal drajveru, od koga operativni sistem preuzima karaktere, ali ih ne interpretira, već ih šalje TELNET
klijentu. TELNET klijent prevodi karaktere (koji u zavisnosti od tipa lokalnog operativnog sistema mogu biti
kodirani ASCII, EBCDIC ili nekim trećim kodom) u univerzalni karakter kôd (NVT - Network Virtual Terminal
chracters) i isporučuje ih lokalnom TCP/IP steku (Sl. 4-3).
TELNET Aplikacioni programi
TELNET
klijent server

...

Operativni ... ...

sistem TCP TCP
Terminal IP IP
veza veza
Terminal Pseudoterminal
drajver fiz. fiz. Operativni drajver
sistem

Internet

Sl. 4-3 Udaljeni login.

Komande ili tekst, u NVT obliku, prenosi se kroz Internet i stižu do TCP/IP steka udaljenog računara, koji ih
isporučuje operativnom sistemu, a on TELNET serveru, gde se karakteri konvertuju iz NVT formata u oblik
razumljiv udaljenom računaru. Sada bi smo očekivali da TELNET server vrati konvertovane karaktere
operativnom sistemu koji bi onda obavio interakciju sa odgovarajućom aplikacijom. Međutim, to se ne dešava
jer operativni sistem nije projektovan da karaktere dobija od TELNT servera već od lokalnog terminala
(posredstvom terminal drajvera). Rešenje je u ugradnji specifičnog programa, pseudoterminal drajver, koji se
prema operativnom sistemu ponaša kao terminal drajver, ali zato sa druge strane, karaktere ne očekuje od
lokalnog terminala već od TELNET servera. Konačno, operativni sistem prenosi karaktere do odgovarajućeg
aplikacionog programa.
NVT
Mehanizam pristupa udaljenom računaru je složen. Razlog za to je što različiti računari i operativni sistemi
koriste različita kodiranja karaktera i prepoznaju različite specijalne kombinacije karaktera. Na primer, kod
DOS-a se za kraj fajla koristi kombinacija Ctrl+z, a kod UNIX-a Ctrl+d. Drugim rečima, radi se o heterogenim
sistemima.
TELNET rešava problem heterogenosti uvođenjem univerzalnog skupa karaktera, NVT. NVT (Network Virtual
Terminal - mrežni virtuelni terminal) je sakriven između TENET klijenta i servera. TELNET klijent prevodi
lokalni skup karakter u NVT oblik, a server iz NVT u skup karaktera udaljenog računara. Na ovaj način,
omogućena je interakcija raznorodnih računara i operativnih sistema. Koncept je ilustrovan na Sl. 4-4.
Naglasimo da je kod OSI modela, konverzija podataka (kao ona koju obavlja NVT) zadatak prezentacionog
sloja. Kod TCP/IP, prezentacioni sloj nije predviđen, a funkcije prezentacionog sloja su pridružene
aplikacionom sloju.

Sl. 4-4 NVT

NVT skup karaktera
NVT sadrži dva skupa 8-bitnih karaktera, jedan za podatke, a drugi za kontrolne (upravljačke) informacije.
Najviši bit karaktera za podatke ima vrednost 0, dok kod kontrolnih karaktera ima vrednost 1. Nižih 7 bitova
karaktera za podatke je isti kao kod ASCII kôda. Neki od važnijih kontrolnih karaktera biće pomenuti u
nastavku.

90
Ugrađivanje
TELNET koristi samo jednu TCP konekciju. Server koristi dobro-poznati port 23, dok se za klijente koriste
dinamički portovi. Ista konekcija se koristi kako za slanje podataka tako i za slanje kontrolnih karaktera. To se
postiže ugradnjom kontrolnih karaktera u tok podataka. Da bi se napravila razlika između podataka i kontrolnih
karaktera, svaka sekvenca kontrolnih karaktera počinje specijalnim kontrolnim karakterom koji se označava
skraćenicom IAC (Interpret As Control - interpretiraj kao kontrolu).
Na primer, zamislimo da korisnik traži od servera da prikaže sadržaj fajla file1. Korisnik unosi komandu: cat
file1. Međutim, umesto da unese file1, korisnik je pogrešio u kucanju i uneo filea1. Da bi ispravio grešku,
korisnik koristi taster backspace, tako da je niz unetih karaktera: cat filea<backspace>1. Međutim, kod
prvobitnih implementacija TELNET-a, lokalno editovanje nije moguće, već se radi na udaljenom serveru.
Karakter backspace se prevodi u dva karaktera (IAC EC) i ugrađuje u tok podataka koji se šalje serveru (Sl. 4-5).

Sl. 4-5 Primer ugrađivanja.

Opcije
TELNET pruža mogućnost klijentu i serveru da pregovaraju oko opcija koje će koristiti tokom sesije. Opcije su
dodatne mogućnosti raspoložive korisnicima sa naprednijim terminalima. Korisnici sa jednostavnijiim
terminalima mogu koristiti podrazumevane opcije. U tabeli T. 4-1 su navedene neke od često korišćenih opcija.
T. 4-1 Opcije
Kôd Opcija Značenje
0 Binary 8-bitni (binarni) prenos
1 Echo Svi primljeni podaci se vraćaju drugoj strani
3 Suppress go ahead Ignoriši go-ahead opciju
5 Status Zahteva status TELENT-a
6 Timing mark Definiše vremenski marker
24 Terminal type Postavlja tip terminala
32 Terminal speed Postavlja brzinu terminala
34 Line mode Promena na linijski način rada

Sledi detaljnije objašnjenje opcija:

Binary. Ova opcija omogućava prijemniku da svaki primljeni 8-bitni podatak, izuzev IAC, tretira kao binarni
podatak. Kada se primi IAC, sledeći karakter ili karakteri se interpretiraju kao komande. Međutim, ako se prime
dva uzastopna IAC karaktera, tada se prvi odbacuje, a drugi interpertira kao binarni podatak.
Echo. Ova opcija omogućava serveru da, odmah po prijemu, vraća nazad klijentu svaki primljeni podatak. To
praktično znači da će svaki karakter kojeg klijent pošalje serveru biti vraćan nazad klijentu i prikazan na ekranu
njegovog terminala. Drugim rečima, karakteri koji klijent unosi se ne prikazuju odmah na njegovom ekranu, već
se čeka da ih server vrati nazad.
Suppress go-ahead. Ova opcija isključuje dejstvo kontrolnog karaktera go-ahead (GA). (Više detalja u sekciji o
načinima rada).
Status. Ova opcija omogućava korisniku da dobija informacije o dozvoljenim opcijama na serveru.
Timing mark. Ova opcija omogućava jednoj od strana da drugoj šalje vremenske markere koji ukazuje da je
završena obrada svih prethodno primljenih podataka.
Terminal type. Ova opcija omogućav klijentu da obavesti servera o tipu svog terminala.
Terminal speed. Ova opcija omogućav klijentu da obavesti servera o brzini svog terminala.
Line mode. Ova opcija omogućava klijentu da se prebaci u linijski način rada. (Više detalja kasnije)
Pregovaranje oko opcija
Klijent i server se moraju dogovoriti oko svake opcije koju bi jedna od strane želela da koristi. Za pregovaranje
se korste četiri kontrolna karaktera, data u tabeli T. 4-2.

91
 T. 4-2 NTV karakteri za pregovaranje.
Karakter Decimalno Binarno Značenje
WILL 251 11111011 1. Ponuda dozvole
2. Prihvatanje tražene dozvole
WONT 252 11111000 1. Odbijanje tražene dozvole
2. Ponuda zabrane
3. Prihvatanje ponuđene zabrane
DO 253 11111001 1. Prihvatanje tražene dozvole
2. Traženje dozvole
DONT 254 1111110 1. Neprihvatanje ponuđene dozvole
2. Prihvatanje ponuđene zabrane
3. Traženje zabrane.

Ponuda dozvole
Jedna od strana (klijent ili server) može ponuditi drugoj da dozvoli (omogući, uključi) neku opciju. Ponuda
može biti prihvaćena ili odbijena. Strana koja nudi, šalje komandu WILL, koja se tumači kao ˝Da li da dozvolim
opciju?˝. Druga strana odgovara sa DO, što znači ˝Dozvoli˝, ili DONT, što znači ˝Nemoj da dozvoliš˝. Vidi Sl.
4-6.

Sl. 4-6 Ponuda da se opcija dozvoli.

Traženje dozvole
Jedna od strana može tražiti od druge da dozvoli opciju. Zahtev može biti odobren ili odbijen. Strana koja traži
dozvolu šalje komandu DO, ˝Tražim od tebe da dozvoliš opciju˝. Druga strana odgovara sa WILL, ˝Hoću˝, ili sa
WONT, ˝Neću˝. Vidi Sl. 4-7.

Sl. 4-7 Ponuda da se opcija zabrani.

Ponuda zabrane
Jedna od strana može ponuditi drugoj da zabrani neku od ranije dozvoljenih opcija. Druga strana mora prihvatiti
ponudu (ne može je odbiti). Strana koja nudi zabranu, šalje komandu WONT, što znači ˝Ne želim više da
koristim ovu opciju˝. Odgovor mora biti komanda DONT, što znači ˝Nemoj više da je koristiš˝. Vidi Sl. 4-8.

Sl. 4-8 Zahtev za dozvolu opcije.

Traženje zabrane
Jedna od strana može tražiti od druge strane zabranu neke opcije. Druga strana mora prihvatiti zahtev (ne može
odbiti). Strana koja traži zabranu šalje komandu DONT, koja znači ˝Nemoj više da koristiš ovu opciju˝.
Odgovor mora biti komanda WONT, što znači ˝Neću je više koristiti˝. Vidi sliku.

Sl. 4-9 Zahtev za zabranu opcije.

92
Pr. 4-1: Pregovaranje oko opcija
Na Sl. 4-10 je prikazan primer pregovaranja oko opcije. U ovom primeru, klijent želi da uključi opciju echo. Ova
opcija se dozvoljava na strani servera, jer je server taj koji šalje karaktere nazad korisničkom terminalu. Zato,
klijent, slanjem komande DO, traži od servera da dozvoli ovu opciju. Zahtev se sastoji iz tri karaktera: ICA, DO
i ECHO. Server prihvata zahtev i dozvoljava opciju, a zatim informiše klijenta da je opcija dozvoljena slanjem
tri karaktera: IAC, WILL, ECHO.
Klijent Server

Tražim od tebe da dozvoliš opciju Echo.

ECHO DO IAC

Dozvoliću opciju Echo.

IAC WILL ECHO

Sl. 4-10 Opcija Echo.

Simetrija
Ravnopravnost u pregovaranju je bitna osobina TELNET-a. To znači da na početku veze obe strane koriste
podrazumevane TELNET opcije, odnosno ni jedna opcija nije dozvoljena. Ako bilo koja strana želi da dozvoli
neku opciju, ona je može ponuditi ili zatražiti. Druga strana ima pravo da prihvati ponudu ili odbije zahtev,
ukoliko nije u stanju ili ne želi da koristi ponuđenu, odnosno traženu opciju. Koncept pregovaranja omogućava
lako proširenje TELNET-a. Na strani klijenta ili servera može se instalirati nova verzija TELENET, a novim
opcijama. Nakon uspostavljana veze, drugoj strani se mogu ponuditi ili od nje tražiti da dozvoli ove nove opcije.
Ukoliko druga strana takođe podržava ove opcije, opcije se mogu dozvoliti. Ako to nije slučaj, jer npr. druga
strana još uvek koristi neku stariju verziju TELENT-a, nove opcije ostaju nedozvoljene.
Pregovaranje oko podopcija
Pojedine opcije zahtevaju dodatne informacije. Na primer, da bi se definisao tip ili brzina terminala,
pregovaranje mora uključiti string ili broj koji će definisati tip, odnosno brzinu terminala. Za pregovaranje oko
podopcija koriste se dva specijalna karaktera, navedena u tabeli T. 4-3. Na primer, na slici je ilustrovano kako
klijent postavlja tip terminala.
T. 4-3 NVT karakteri za pregovaranje oko podopcija.
Karakter Decimalno Binarno Značenje
SE 240 11110000 Kraj podopcije
SB 250 11111010 Početak podopcije

Klijent Server

Da li da dozvolim opciju ˝terminal type˝

Terminal Type WILL IAC

Dozvoli opciju ˝terminal type˝

IAC DO Terminal Type

Postavljam tip terminala na ´VT´

SE IAC ´T´ ´V´ Terminal Type SB IAC

Sl. 4-11 Primer pregovaranja oko opcija.

Kontrola servera
Pojedini kontrolni karakteri se koriste za kontrolu udaljenog servera. Kada se program izvršava lokalno,
specijalni karakteri se koriste za prekid rada programa (Abort - npr. Ctrl-c) ili brisanje poslednjeg unetog
karaktera (npr. taster Delete ili Backspace). Međutim, kada se program izvršava na udaljenom računaru, ovi
kontrolni karakteri moraju biti poslati udaljenoj mašini. Korisnik i dalje preko tastature unosi istu kombinaciju
tastera. TELENT klijent prevodi unetu kombinaciju karaktera (koja je moguće specifična za konkretni tip

93
operativnog sistema) u odgovarajući NVT specijalni karakter i šalje ga TELNET serveru koji ga interpretira i na
odgovarajući način deluje na aplikacioni program.
T. 4-4 NVT karakteri koji se koriste za kontrolu aplikacije koja se izvršava na udaljenom serveru.
Kôd Decimalno Binarno Značenje
IP 244 11110100 Prekid (interrupt) procesa
AO 245 11110101 Prekid (abort) procesa
AYT 246 11110110 Da li si tamo?
EC 247 11110111 Brisanje karkatera
EL 248 11110000 Brisanje linije

IP (interrupt process). Povremeno se dešavaju situacije kada izvršenje program treba ˝nasilno˝ prekinuti (na
primer, zato što se program više ne odaziva jer je upao u beskonačnu petlju). Ako se program izvršava na
lokalnom računaru, korisnik ga može prekinuti unosom specifične kombinacije karatera. Operativni sistem
prepoznaju nameru korinika i poziva odgovarajuću funkciju koja prekida izvršenje programa. Međutim, ako se
program izvršava na udaljenom računaru, odgovarajuću funkciju za prekid rada programa treba pozvati na
udaljenom računaru. TELENT definiše kontroli karakter IP koji se na strani servera tumači na isti način kao
kombinacija tastera za prekid izvršenja programa.
AO (abort output). Slično kontrolnom karakteru IP, s tom razlikom što omogućava procesu da nastavi sa
izvršenjem ali bez generisanja izlaza. Ova komanda je korisna u situacijama kada proces osim kreiranja izlaza
(npr. rezultat u obliku fajla) ima i neke druge efekte, koje korisnik ne želi da poništi.
AYT (are you there?) Pomoću ovog kontrolnog karaktera, klijent može da proveri da li je server još uvek
operativan, naročito nakon dužih perioda ˝tišine˝. Kada primi karkater AYT, server odgovara porukom koja
potvrđuje klijentu da je TELENT veza još uvek ˝živa˝.
EC (erase character). Za brisanje poslednje unetog karaketera preko tastatature na lokalnom računaru koriste se
tasteri Delete ili Backspace. Da bi se ostvario isti efekat i na udaljenom računaru, TELENT predviđa kontrolni
karakter EC.
EL (erase line). Koristi se za brisanje tekuće linije na udaljenom hostu.
Out-of-band signalizacija
Da bi u svim situacijama obezbedio dejstvo kontrolnih karaktera, TELENT koristi out-of-band signalizaciju.
Kod out-of-band signalizacije, kontrolni karakteri se šalju udaljenom procesu izvan redosleda.
Zamislimo situaciju u kojoj je aplikacioni program koji se izvršava na serveru upao u beskonačnu petlju i zbog
toga ne prihvata nove podatke. Korisnik želi da prekine izvršenje programa, ali to ne može, jer je program
prestao da čita podatke iz bafera. Vremenom, prijemni bafer postaje pun, a serverski TCP šalje klijentskom
TCP-ju kontrolni segment sa veličinom prozora postavljenom na nulu saopštavajući mu da više nije u
mogućnosti da prihvata regularne podatke. Opisana situacija se može prevazići urgentnim segmentom kojeg bi
klijentski TCP poslao serverskom TCP-ju. Za urgentne segmente (sa postavljenim bitom URG) ne važe pravila
kontrole protoka: iako TCP više ne prihvata normalne segmente, u obavezi je da prihvata urgentne.
TELENT proces (klijentski ili serverski) koji želi drugom procesu da pošalje sekvencu karaktera izvan
redosleda (out-of-band), ugrađuje sekvencu u tok podataka i umeće specijalni karakter DM (data mark) na kraj
sekvence. Dodatno, da bi primorao drugu stranu da obradi sekvencu izvan redosleda, proces kreira TCP segment
sa postavljenim bitom URG i urgentnim pointerom koji ukazuje na karakter DM. Kada primi takav segment,
prijemni TCP čita podatke iz segmenta i odbacuje sve podatke koje prethode kontrolnim karakterima (kao što su
IAC ili IP), a podatke koji slede nakon DM karaktera, tretira na normalan način. Drugim rečima DM se koristi
kao sinhronizacioni karakter koji prebacuje prijemni TCP iz urgentnog u normalni način rada (vidi Sl. 4-12). Na
ovaj način, kontrolni karakter IP se izvan redosleda isporučuje operativnom sistemu koji pozivom odgovarajuće
funkcije prekida izvršenje aplikacionog procesa.
Klijent Server

Urgentni
pointer

Podaci DM IP IAC Podaci

prihvataju se odbacuju se

Sl. 4-12 Out-of-band signalizacija.

Načini rada
Većina TELNET realizacija radi u jednom od sledeća tri načina rada: podrazumevani, karakter-orijentisani i
linijski.

94
Podrazumevani način rada
Podrazumevani način rada se koristi ukoliko putem pregovaranja nije postavljen neki drugi način rada. U ovom
načinu rada, eho karaktera obavlja klijent. Kako korisnik unosi karaktere preko tastature, tako ih klijent
prikazuje na ekranu, ali ih ne šalje serveru sve dok korisnik ne unese celu jednu liniju teksta. Kada pošalje liniju
teksta serveru, klijent je spreman da od korisnika prihvati novu liniju tek nakon što od servera dobije komandu
GA (go ahead). Ovakav polu-dupleks način rada nije efikasan, s obzirom da TCP podržava komunikaciju u
punom dupleksu.
Karakter-orijentisani način rada
U ovom načinu rada, eho karaktera obavlja server. Klijent šalje serveru svaki pojedinačni karakter kojeg
korisnik unese preko tastature. Server vraća nazad primljene karaktere, a klijent ih prikazuje na ekranu. Pri
ovakvom načinu rada, često se uočava kašnjenje u prikazu otkucanih karaktera, u situacijama kada je vreme
prenosa između klijenta i servera veliko. Takođe, karakter-orijentisani način rada nije efikasan jer generiše
nepotrebno veliki mrežni saobraćaj jer su za prenos jednog karaktera neophodna tri TCP segmenta: 1) segment
kojim se od klijenta do servera prenosi karakter kojeg je korisnik uneo preko tastature; 2) segment kojim server
potvrđuje prijem karaktera i vraća ga nazad klijentu i 3) segment kojim klijent potvrđuje (ACK) prijem
karaktera kojeg je server vratio.
Linijski način rada
U linijskom načinu rada, editovanje linije teksta (eho, brisanje, umetanje karaktera i sl.) se obavlja na klijentu, a
serveru se šalju samo kompletne linije. Za razliku od podrazumevanog načina rada, linijski način rada
omogućava punu-dupleks komunikaciju, jer klijent može, bez čekanja na komandu GA, da pošalje serveru više
linija teksta, jednu za drugom.
Pr. 4-2 Podrazumevani način rada
Na slici je prikazan primer odvijanja TELENT sesije u prodrazumevanom načinu rada. Sisija počinje
pregovaranjem oko tipa i brzine terminala, a nastavlja se logovanjem korisnika na server. Nakon uspešnog
logovanja, korisnik je u mogućnosti da interaguje sa serverom.

Sl. 4-13 TELENT sesija u podrazumevanom načinu rada.

95
4.3 FTP
FTP (File Transfer Protocol – Protokol za prenos fajlova) je aplikacioni protokol za kopiranje fajlova sa jednog
na neki drugi host. Prenos fajlova između hostova je jedan od najčešćih zadataka koji se očekuje od bilo kog
mrežnog okruženja. Iako se čini da se fajlovi mogu jednostavno prenositi sa jednog na drugi sistem, postoje
problemi koji se moraju rešiti kako bi prenos uopšte bio moguć. Na primer, dva sistema mogu koristiti različite
konvencije za imenovanje fajlova, načine za predstavljanje teksta i drugih tipova podataka, ili podržavati
razičite strukture direktorijuma. Na FTP-ju je da reši ove probleme.
FTP se razlikuje od drugih klijent-server aplikacija po tome što ne uspostavlja samo jednu već dve TCP
konekcije između hostova (klijenta i srevera). Jedna konekcija se koristi za prenos podataka, a druga za prenos
upravljačkih informacija (komande i odzivi). Osnovni model FTP-a je prikazan na Sl. 4-14. FTP klijent sadrži tri
komponente: korisnički interfejs, proces za upravljanje klijentom i proces za prenos podataka. Server ima dve
komponente: proces za upravljanje serverom i proces za prenos podataka. Upravljačka konekcija se uspostavlja
između upravljačkih, a konekcija za prenos podataka između procesa zaduženih za prenos podataka na stranama
klijenta i servera. Upravljačka konekcija ostaje aktivna za sve vreme trajanja jedne FTP sesije. Konekcija za
prenos podataka se otvara, a onda i zatvara za prenos svakog pojedinačnog fajla. Drugim rečima, upravljačka
konekcija se uspostavlja kada korisnik otvori FTP sesiju. Dok je upravljačka konekcija otvorena, konekcija za
prenos podataka može biti otvarana i zatvarana više puta, ako se prenosi više fajlova. Upravljačka konekcija
koristi jednostavna pravila komunikacije: klijent šalje komandu, a server vraća odziv. Sa druge strane, konekcija
za prenos podataka zahteva složenija pravila komunikacije, s obzirom na brojne tipove fajlova i specifične
načine prenosa podatak. FTP koristi TCP. Upravljačka konekcija se ostvaruje preko porta 20, a konekcija za
prenos podataka preko port 21.

Sl. 4-14 FTP.

Konekcije
Dve FTP konekcije, upravljačka i konekcija za prenos podataka koriste različite brojeve portova i različite
mehanizme komunikacije.
Upravljačka konekcija
Upravljačka konekcija se uspostavlja na isti način kao i dok drugih standardnih mrežnih aplikacionih programa,
kao što je npr. TELNET. Konekcija se uspostavlja u dva koraka:
1. Server izvršava pasivno otvaranje dobro-poznatog porta 21 i čeka na klijenta.
2. Klijent koristi dinamički prort i inicira aktivno otvaranje konekcije sa serverom.
Konekcija ostaje otvorena za sve vreme trajanja FTP sesije. Slično kao kod TELENT-a, korisnik unosi komande
i od servera dobija odzive. Proces uspostavljanja upravljačke konekcije ilustrovan je na Sl. 4-15.

(a) (b)
Sl. 4-15 Uspostavljanje upravljačke konekcije: (a) korak 1.; (b) korak 2.

96
Konekcija za prenos podataka
Konekcija za prenos podataka (ili samo konekcija za podatke) na strani servera koristi dobro-poznati port 20.
Međutim, kreiranje konekcije se razlikuje u odnosu na standardnu proceduru. Za uspostavljanje konekcija za
podatke potrebna su tri koraka:
1. Klijent, a ne server, izvršava pasivno otvaranje dinamičkog porta.
2. Klijent šalje broj dinamičkog porta serveru, korišćenjem komande PORT (prenosi se preko upravljačke
konekcije).
3. Server prima broj porta i izvršava aktivno otvaranje konekcije sa klijentom koristeći dobro-poznati port
20 za sebe i primljeni dinamički broj porta za klijenta.
Procedura uspostavljana konekcije za prenos podataka ilustrovana je na Sl. 4-16.

Upravljacki Upravljacki
62012 21
proces proces

Proces za Proces za
prenos 63000 prenos
podataka podataka
Pasivno
otvoren port
Klijent Server
(a)

PORT 63000
Upravljacki Upravljacki
62012 21
proces proces

Proces za Proces za
prenos 63000 prenos
podataka podataka
Pasivno
otvoren port
Klijent Server
(b)

Upravljacki Upravljacki
62012 21
proces proces

Proces za Proces za
prenos 63000 20 prenos
podataka Aktivno podataka
otvoren port
Klijent Server
(c)
Sl. 4-16 Uspostavljanje konekcije za prenos podataka: (a) klijent pasivno otvara dinamički port 63000; (b) klijent
šalje broj dinamičkog porta serveru; (c) server aktivno otvara port 20 i uspostavlja konekciju sa klijentom na portu
63000.
Komunikacija
Komunikacija preko upravljačke konekcije
Za komunikaciju preko upravljačke konekcije kod FTP-a se koristi, kao i kod TELENT-a ili SMTP-a, NVT
ASCII skup karaktera (Sl. 4-17). Komunikacija se stvaruje putem komandi i odziva. Ovakav način komunikacije
(polu dupleks) je pogodan za upravljačku konekciju zato što se preko konekcije, u bilo kom trenutku, prenosi
najviše jedna komanda (ili odziv). Komande i odzivi su kratke linije teksta, tako da nema potrebe brinuti o
različitim tipovima fajlova ili različitim strukturama fajlova na klijentu i serveru.

Sl. 4-17 Korišćenje upravljačke konekcije.

Komunikacija preko konekcije za podatke
Konekcija za podatke ima različitu namenu i ostvaruje se na drugačiji način u odnosu na komunikaciju preko
upravljačke konekcije. Preko konekcije za podatke se prenose fajlovi. Za svaki fajl koji želi da prenese, klijent

97
mora definisati tri atributa komunikacije: tip fajla, strukturu podataka i način prenosa (Sl. 4-18). Prenosu fajla
preko konekcije za podatke prethodi priprema prenosa preko upravljačke konekcije.

Sl. 4-18 Korišćenje konekcije za prenos podataka.

Tip fajla. Preko konekcije za podatke FTP može prenosit sledeće tipove fajlova:
ASCII. Ovo je podrazumevani format prenosa tekstualnih fajlova. Svaki karakter se kodira u NVT
ASCII kôdu. Predajnik transformiše fajl iz svoje sopstvene reprezentacije u NVT ASCII karaktere. Sa
druge strane, prijemnik transformiše NVT ASCII karaktere u fajl kodiran svojim kôd.
EBCDIC. Ako jedna ili obe strane u komunikaciji koriste EBCDIC kôd, tekstualni fajl se može
prenositi korišćenjem EBCDIC kodiranja (umesto u NVT ASCII).
Image. Ovo je podrazumevani format za prenos binarnih fajlova. Fajl se prenosi kao kontinualni tok
bitova bez bilo kakve interpretacije ili kodiranja. Uglavnom se koristi za prenos binarnih fajlova kao
što su izvršni programi.
Struktura podataka. FTP može prenositi fajlove preko konekcije za podatke korišćenjem jedne od sledeće tri
interpretacije strukture podatka u fajlu:
File (podrazumevana opcija). Fajl nije struktuiran, tj. sadrži kontinualni tok bajtova.
Record. Fajl je podeljen na zapise. Primenljivo samo na tekstualne fajlove.
Page. Fajl je podeljen na stranice. Svaka stranica ima broj i zaglavlje. Stranicama se može pristupati
bilo sekvencijalno bilo proizvoljno.
Način prenosa. Postoje tri načina prenosa fajlova preko konekcije za podatke:
Stream. Ovo je podrazumevani način prenosa. FTP isporučuje TCP-ju podatke u vidu kontinualnog
toka podataka. TCP je odgovoran za podelu podataka na segmente odgovarajuće veličine. Ako su
podaci koji se prenose prosti tok bajtova (struktura tipa File structure), marker za kraj fajla (EOF- End-
Of-File) nije potreban. U ovom slučaju, kraj fajla konicidira sa zatvaranjem konekcije od strane
predajnika. Ako su podaci podeljeni na zapise (striktura tipa Record structure), svakom zapisu se
pridodaje 1-bajtni specijalni karakter end-of-record (EOR), dok se kraj celokupnog fajla označava
karakterom EOF.
Block. FTP može isporučivati TCP-ju podatke u blokovima. U ovom slučaju, svakom bloku prethodi 3-
bajtno zaglavlje. Prvi bajt je bajt za opis bloka (block descriptor), dok sledeća dva bajta definišu
veličinu bloka u bajtovima.
Compressed. Ako je fajl isuviše veliki, podaci su mogu komprimovati, kako bi se smanjila količina
podataka koju treba preneti preko mreže.
Obrada komandi
Preko upravljačke konekcije obavlja de dijalog između klijenta i servera. Klijent šalje komandu serveru, server
je obrađuje i vraća odziv klijentu.
Komande
Klijent šalje komande u obliku teksta koji sadrži ime komande, napisanog velikim slovima, i eventualno prateće
argumente. Komande se grubo mogu podeliti u šest grupa: komande za pristup, komande za menadžment
fajlova, komande za formatiranje podataka, komande za definisanje porta, komande za prenos fajlova i ostale
komande.
Komande za pristup. Ove komande omogućavaju korisniku da pristupi udaljenom sistemu. Spisak komandi za
pristup dat je tabeli T. 4-5.

98
 T. 4-5 Komande za pristup
Komanda Argument(i) Opis
USER User id Korisničko ime
PASS User password Korisnička lozinka
ACCT Nalog koji se menja Podaci o nalogu
REIN Ponovna inicijalizacija
QUIT Logout (odjavljivanje)
ABOR Poništavanje prethodne komande

Komande za manadžment fajlova. Komande iz ove grupe omogućavaju korisniku da pristupa fajl sistemu na
udaljenom računaru. Komande omogućavaju korisniku da se kreće po strukturi direktorijuma, kreira nove
direktorijume, briše fajlove i slično. Spisak komandi iz ove grupe dat je u tabeli T. 4-6.
T. 4-6 Komande za menadžment fajlova.
Komanda Argument(i) Opis
CWD Ime direktorijuma Promena radnog direktorijuma
CDUP Prelazak na roditeljski direktorijum
DELE Ime fajla Brisanje fajla
LIST Ime direktorijuma Listanje poddirektorijuma ili fajlova
NLIST Ime direktorijuma Listanje imena direktorijuma ili fajlova bez dodatnih atributa
MKD Ime direktorijuma Kreiranje novog direktorijuma
PWD Prikazivanje imena radnog direktorijuma
RMD Ime direktorijuma Brisanje direktorijuma
RNFR Ime fajla (staro ime fajla) Identifikuje fajla čije se ime menja
RNTO Ime fajla (novo ime fajla) Promena imena fajla
SMNT Ime fajl-sistema Priključivanje fajl-sistema.

Komande za formatiranje podataka. Ove komande omogućavaju korisniku da definiše strukturu podataka, tip
fajla i način prenosa. Definisani atributi se potom koriste prilikom prenosa fajla. Tabela T. 4-7 sadrži komande iz
ove grupe.
T. 4-7 Komande za formatiranje podataka.
Komanda Argument(i) Opis
TYPE A (ASCII), E (EBCDIC), I (Image) Definisanje tipa fajla
STRU F (File), R (Record), P (Page) Definisanje strukture fajla
MODE S (Stream), B (Block), C (Compressed) Definisanje načina prenosa

Komande za definisanje porta. Ovim komandama se definiše broj prota konekcije podataka na strani klijenta.
Postoje dva načina kako se to može uraditi. Prvi način koristi komandu PORT. Klijent bira dinamički port,
pasivno otvara izabrani port, a serveru, putem upravljačke konekcije šalje komandu PORT sa brojem izabranog
porta. Server koristi broj porta da bi uspostavio konekciju za podatke prema klijentu. Drugi način koristi
komandu PASV. Slanjem ove komande klijent traži od servera da izabere dinamički port i izvrši pasivno
otvaranje izabranog porta. Nakon što otvori port, server u odzivu vraća klijentu broj izabranog porta. Konačno,
klijent, koji je sada aktivna strana konekcije, uspostavlja konekciju za prenos podataka sa servorom, na
dobijenom portu. Komande za definisanje porta navedene su u tabeli T. 4-8.
T. 4-8 Komande za definisanje porta.
Komanda Argument(i) Opis
PORT 6-cifreni idnetifikator Klijent bira port
PASV Server bira port.

Komande za prenos fajlova. Ove komande služe za stvarni prenos fajlova. Navedene su u tabeli T. 4-9.
Ostale komande. Ovim komandama korisnik može doći do nekih dodatnih informacija (T. 4-10).

99
 T. 4-9 Komande za prenos fajlova.
Komanda Argument(i) Opis
RETR Ime fajla(ova) Preuzimanje fajla. Fajl se prenosi sa servera na klijenta.
STOR Ime fajla(ova) Smeštanje fajla. Fajl (ili fajlovi) se prenosi sa klijenta na server
APPE Ime fajla(ova) Slično STOR s tom razlikom da ako fajl postoji, podaci se dodaju fajlu
STOU Ime fajla(ova) Isto kao STOR, s tim da se očekuje da ime fajla bude jedinstveno u direktorijumu. Ako fajl
sa datim imenom postoji, postojeći fajl neće biti prebrisan.
ALLO Ime fajla(ova) Rezerviše prostor za smeštanje fajla na serveru.
REST Ime fajla(ova) Pozicionira marker fajla na navedenu poziciju u fajlu.
STAT Ime fajla(ova) Vraća status fajla.

T. 4-10 Ostale komande.

Komanda Argument(i) Opis
HELP Traži informacije o serveru.
NOOP Testiranje da li je server ˝živ˝
SITE Komande Za komande specifične za konkretan sajt
SYST Traži informaciju o operativnom sistemu servera

Odzivi
Svaka FTP komanda generše barem jedan odziv. Odziv se sastoji iz dva dela: tro-cifarski broj i prateći tekst.
Numerički deo definiše potrebne parametre ili dodatne informacije. Tri cifre odziva predstavićemo u obliku xyz.
Sledi objašnjenje značenja cifara.
Prva cirfra. Prva cifra odziva definiše status kmande. Na ovoj poziciji može se naći jedna od pet cifara (1-5):
1yz (pozitivan preliminarni odziv). Akcija zahtevana komandom je startovana. Kada završi akciju,
server će poslati još jedan odziv.
2yz (konačni pozitivan odziv). Akcija je završena. Server je spreman da prihvati sledeću komandu.
3yz (pozitivan među-odziv). Komanda je prihvaćena, ali su neophodne dodatne informacije.
4yz (prolazni negativan odziv). Akcija nije startovana, jer server trenutno nije u mogućnosti da je
izvrši. Ista komanda može biti poslata kasnije.
5yz (konačni negativni odziv). Komanda nije prihvaćena i ne bi trebalo pokušavati ponovo.
Druga cifra. Druga cifra odziva takođe definiše status komande. Na ovoj poziciji meže se naći jedna od šest
cifara (1-6):
x0z - odziv se odnosi na sintaksu komande
x1z - odziv je informativne prirode
x2z - odziv se odnosi na konekciju
x3z - odziv se odnosi na autorizaciju korisnika
x4z - značenje nije definisano
x5z - odziv se odnosi na fajl sistem
Treća cifra. Treća cifra ukazuje na dodatne informacije.
U tabeli je navedeno nekoliko tipičnih odziva
Prenos fajlova
Prenos fajlova se ostvaruje preko konekcije za podatke pod kontrolom komandi poslatih preko upravljačke
konekcije. Međutim, treba imati na umu da prenos fajlova preko FTP-a znači jednu od sledeće tri operacije:
Fajl se kopira sa serverskog na klijentski računar. Ova operacija se pod kontrolom komande RETR i
zove se preuzimanje fajla.
Fajl se kopira sa klijentskog na serverski računar. Ova operacija je pod kontrolom komande STOR i
zove se smeštanje fajla.
Server šalje klijentu spisak direktorijuma ili imena fajlova. Ova operacija je pod kontrolom komande
LIST.

100
Pr. 4-3: FTP sesija
Sl. 4-19 ilustruje korišćenje FTP komandi na primeru listanja sadržaja direktorijuma.
Klijent Server Klijent Server

Proces za Proces za
Upravljački Upravljački
prenos prenos
proces proces
podataka podataka

220 (Servis je spreman)

USER petar

331 (Korisničko ime OK. Lozinka?)

PASS ****

230 (Login OK)

PORT 7777

150 (Sledi otvaranje kon. za podatke)

LIST predavanja/IT

226 (Konekcija za podatke OK)

Spisak fajlova ili direktorijuma

PRENOS
PODATAKA
Spisak fajlova ili direktorijuma

236 (Zatvaranje kon. za podatke)

QUIT

221 (Zatvaranje servisa)

Upravljačka konekcija Konekcija za podatke

Sl. 4-19 Pr. 4-3

1 - Nakon uspostavljanja upravljačke konekcije na portu 21, FTP server šalje odziv 220 (servis je spreman).
2 - Klijent šalje komandu USER.
3 - Server odgovara odzivom 331 (Korisničko ima je OK, potrebna je lozika).
4 - Klijent šalje komandu PASS.
5 - Server odgovara odzivom 230 (Login OK)
6 - Klijent pasivno otvara dinamički port za konekciju za podatke i šalje komandu PORT (preko upravljačke
konekcije) da bi serveru predao izabrani broj porta.
7 - Server ne uspostavlja konekciju, u ovom trenutku, već se priprema za aktivno otvaranje konekcije za podatke
između svog porta 20 i dinamičkog porta klijenta. Server šalje odziv 150 (konekcija za podatke će ubrzo biti
uspostavljena).
8 - Klijent šalje komandu LIST.
9 - Server odgovara odzivom 125 i otvara konekciju za podatke.
10 - Server, preko konekcije za podatke, šalje spisak fajlova ili direktorijuma. Kada je poslat kompletan spisak,
server, preko upravljačke konekcije, šalje odziv 226 (zatvaranje konekcije za podatke).
11- Sada, klijent ima dve opcije. Klijent može poslati komandu QUIT i zahtevati zatvaranje upravljačke
konekcije (čime bi sesija bila okončana) ili može posalati neku drugu komandu kako bi započeo neku drugu
aktivnost (i eventualo otvorio novu konekciju za podatke). U razmatranom primeru, klijent šalje komandu
QUIT.
12 - Nakon prijema komande QUIT, server odgovara odzivom 221 (zatvaranje servisa) i zatvara upravljačku
konekciju.

101
4.4 Elektronska pošta
Elektronska pošta (e-mail) je sigurno jedan od najpopularnijih mrežnih servisa. Na početku ere Interneta, poruke
koje su slate elektronskom poštom bile su kratke i isključivo tekstualne. Danas je elektronska pošta mnogo
složenija i omogućava prenos ne samo teksta, već i audio i video zapisa. U ovom poglavlju upoznaćemo se sa
arhitekturom sistema elektronske pošte koju čine tri glavne komponente: korisnički agent, agent za prenos
poruka i agent za preuzimanje poruka i potom i sa protokolima kojima se realizuju ove komponente.

4.4.1 Arhitektura
Arhitekturu e-mail sistema istražićemo kroz opis četiri tipična scenarija. Počećemo sa najjednostavnijom, a
završiti sa najsloženijom i u isto vreme najčešćom situacijom.
Prvi scenario
U prvom scenariju, pošiljalac i primalac e-mail-a su korisnici (ili aplikacioni programi) na istom sistemu.
Administrator je kreirao jedno poštansko sanduče (mailbox) za svakog korisnika. Sve poruke koje prima neki
korisnik, smeštaju se u njegovom poštanskom sandučetu. Mailbox je fajl na lokalnom hard disku sa ograničenim
pravom pristupa. Mailbox-u može pristupati jedino njegov vlasnik. Pretpostavimo da korisnik Ana želi da
pošalje poruku korisniku Milanu. Ana pokreće program korisnički agent (UA - User Agent) pomoću koga
priprema (piše) poruku i smešta je u Milanovo poštansko sadnuče. Poruka sadrži mailbox adrese (tj. imena
odgovarajućih fajlova) pošiljaoca i primaoca. Takođe pomoću korisničkog agenta Milan može preuzeti i
pročitati poruku, onda kada je njemu zgodno. Opisani scenario ilustrovan je na Sl. 4-20.

Sl. 4-20 Prvi scenario. UA (User Agent) - korisnički agent.

Drugi scenario
U drugom scenariju, pošiljalac i primalac e-mail-a su korisnici (ili aplikacioni programi) na dva različita
sistema. Poruka mora biti preneta kroz Internet, a pored korisničkog agenta, sada je neophodan i agent za prenos
poruka (MTA - Message Transfer Agent), kao što je prikazano na Sl. 4-21.

Sl. 4-21 Drugi scenario. UA (User Agent) - korisnički agent; MTA (Message Transfer Agent) - agent za prenos poruka.
Ani je neohpodan korisnički agent da bi poruku poslala lokalnom sistemu, tzv. mail serveru. Mail server koristi
red čekanja za smeštanje poruka koje još uvek nisu poslate. Milanu je takođe neophodan korisnički agent, kako
bi mogao da preuzme poruke iz poštanskog sandučeta u njegovom lokalnom sistemu. Međutim, poruka treba
biti preneta kroz Internet, od Aninog do Milanovog sistema. Ovaj zadatak obavljaju dva agenta za prenos
poruka: jedan ima ulogu klijenta, a drugi servera. Poput većine klijent-server programa na Internetu, server radi
sve vreme zato što unapred ne zna kada će mu se neki klijent obratiti. Sa druge strane, klijenta može pokrenuti
sistem onda kada u redu čekanja ima poruka koje treba poslati.
Treći scenario
U trećem scenariju, Milan je, kao i u prethodnom scenariju, direktno povezan na svoj sistem. Međutim, to nije
slučaj sa Anom, koja je sa svojim sistemom povezana putem dial-up, ADSL ili kablovskog modema, ili je
povezana na LAN u organizaciji koja koristi jedan mail server za sve korisnike (svi korisnici moraju da šalju
svoje mejlove ovom mail serveru). Situacija koja odgovara trećem scenariju prikazana je na Sl. 4-22.

102
Sl. 4-22 Treći scenario. UA (User Agent) - korisnički agent; MTA (Message Transfer Agent) - agent za prenos poruka.
Ani je i dalje neophodan korisnički agent za pripremu poruke. Međutim, sada je specifično to da ona treba da
pošalje poruku mail serveru kroz LAN (ili dial-up, ADSL i sl). To se postiže parom (klijent-server) agenata za
prenos poruka (MTA). Uvek kada Ana ima poruku za slanje, ona poziva korisničkog agenta, koji dalje poziva
MTA klijenta. MTA klijent uspostavlja vezu sa MTA serverom koji radi sve vreme. Sistem na Aninoj strani sve
primljene poruke čuva u redu čekanja, a korisni MTA klijenta za slanje poruka sistemu na Milanovoj strani.
Milanov sistem prima poruku i smešta je u Milanovo poštansko sanduče. Milan korisni korisničkog agenta za
preuzimanje poruke iz sandučeta i čitanje poruke. Uočimo da su u ovom slučaju potrebna dva para MTA klijent-
server programa.
Četvrti scenario
U četvrtom i najčešćem scenariju, Milan je takođe povezan sa svojim mail serverom putem LAN-a. Pošto Milan
nema mogućnost direktnog pristupa mail serveru, potreban je mehanizam koji će mu omogućiti da preuzme
primljene poruke iz svog poštanskog sandučeta. Ovaj zadatak obavlja još jedan par klijent-server agenata, tzv.
agenti za preuzimanje poruka (MAA - Message Access Agent). Za preuzimanje svojih poruka, Milan koristi
MAA klijenta. Klijent šalje zahtev MAA serveru, koji neprekidno radi, zahtevajući prenos poruka iz Milanovog
mailbox-a. Opisana situacija prikazana je na Sl. 4-23.

Sl. 4-23 Četvrti scenario. UA (User Agent) - korisnički agent; MTA (Message Transfer Agent) - agent za prenos
poruka; MAA (Message Access Agent) - agent za preuzimanje poruka.
Treba ukazati na dva bitna detalja. Prvo, Milan ne može da zaobiđe mail server i za prijem poruka direktno
koristi MTA server. MTA server, koji bi bio pokrenut na Milanovom računaru, morao bi neprekidno da radi, jer
Milan unapred ne može znati kada će mu neko poslati poruku. To znači da bi Milanov računar mora biti stalno
uključen, što svakako nije praktično rešenje. Drugo, uočimo da je potreban još jedan par klijent-server
programa, MAA, koji se koristi za preuzimanje poruka iz poštanskog sandučeta. Ovu operaciju ne može da
obavlja MTA, zato što je MTA program push tipa (uvek samo šalje poruke severu). Preuzimanje poruka je
operacija pull tipa (poruke se uzimaju od servera). Sl. 4-24 prikazuje ovu razliku.

103
 Sl. 4-24 Push vs. Pull.

4.4.2 Korisnički agent

Prva komponenta sistema elektronske pošte je korisnički agent. Njegova namena je da korisniku olakša slanje i
primanje poruka.
Servisi korisničkog agenta
Korisnički agent je softverski paket (program kao npr. Microsoft Outlook) za kompoziciju (kreiranje) poruka,
čitanje poruka, odgovaranje na i prosleđivanje poruka. Korisnički agent se takođe brine o poštanskom
sandučetu.
Kreiranje poruka. Korisnički agent pomaže korisniku da kreira poruku koju želi da pošalje. Većina korisničkih
agenata na ekranu monitora prikazuje šablon kojeg korisnik popunjava adresom primaoca, temom i sadržajem
poruke.
Čitanje poruka. Drugi zadatak korisničkog agenta je da omogući čitanje primljenih poruka. Kada pozve
korisničkog agenta, korisnik prvo proverava da li u sadučetu primljenih poruka (incoming mailbox ili Inbox) ima
novih poruka. Većina korisničkih agenata prikazuje spisak poruka prisutnih u Inbox-u, gde za svaku poruku daje
podatak o veličini poruke, pošiljaocu poruke, status poruke (indikaciju da li je poruka nova, već pročitana ali
neodgovorena, pročitana i odgovorena) i opciono temu (subject) poruke.
Odgovaranje na poruku. Pošto je pročitao poruku, korisnik može da iskoristi korisničkog agenta da bi
odgovorio na prouku. Korisnički agent omogućava korisniku da odgovor uputi samo pošiljaocu prvobitne
poruke ili svima kojima je prvobitna poruka bila upućena. Poruka odgovora obično, osim novog teksta, sadrži i
tekst iz prvobitne poruke.
Prosleđivanje poruka. Odgovor na poruku podrazumeva slanje poruke pošiljaocu ili svim primaocima primljene
poruke. Prosleđivanje znači slanje primljene poruke, u neizmenjenom obliku, nekom trećem licu.
Mailbox-ovi. Korisnički agent obično kreira dva mailbox-a: za primljene poruke (inbox) i poslate poruke
(outbox). Svaki mailbox je fajl u specifičnom formatu kojeg kreira i o kome se stara korisnički agent. Inbox čuva
primljene poruke sve dok ih korisnik ne obriše. Outbox čuva sve poruke koje je korisnik poslao, sve dok ih
korisnik ne obriše.
Tipovi korisničkih agenata
Postoje dva tipa korisničkih agenata: komandni i grafički.
Komandni. Komandni korisnički agenti pripadaju ranim danima elektronske pošte. Program korisničkog agenta
se poziva iz komandne linije, a zatim korisnik unosi tekstualne komande kojima agentu nalaže da izvrši željenu
operaciju. Na primer, korisnik može da unese preko tastature slovo r da bi ogovorio pošiljaocu poruke ili slovo
R da bi odgovorio pošiljaocu i svim primaocima poruke. Primeri ovakvih korisnkičkih agenata su programi
mail, pine i elm (iz Unix-a).
Grafički. Savremeni korisnkički agenti obezbeđuju grafičke interfejse za interakciju sa korisnikom. Interfejs
čine ikone, meni i prozori, a za interakciju sa programom korisnik može koristiti i miša. Popularni grafički
korisnički agenti su: Microsoft’s´Outlook, Eudora, Netscape.
Elektronsko pismo (e-mail)
Posredstvom korisničkog agenta, korisnik kreira elektronsko pismo (e-mail) koje po strukturi nalikuje
poštanskom pismu i sastoji se iz koverte i poruke ( Sl. 4-25). Koverta sadrži obično adresu pošiljaoca, adresu
primaoca i eventualno neke druge informacije. Poruka se sastoji iz zaglavlja i tela. Zaglavlje poruke definiše
pošiljaoca, primaoca, temu poruke i neke druge podatke. Telo poruke sadrži tekst koji će pročitati primalac
pisma.

104
 Koverta
Zaglavlje
Telo
(a) (b)
Sl. 4-25 Koverta i poruka: (a) poštansko pismo; (b) elektronsko pismo.
Informacije sa koverte koristi MTA za za isporuku poruke na pravu adresu (baš kao što to čini i PTT). Zaglavlje
sadrži informacije za korisničkog agenta. Telo je namenjeno primaocu (čoveku).
E-mail adrese
Da bi isporučio poruku, sistem elektronske pošte mora da poznaje adresu primaoca (tj. e-mail adresu). E-mail
adresa se sastoji iz dva dela: lokalni deo i ime_domena razdvojena znakom @: lokalni_deo@.ime_domena.
Lokalni deo je ime jednog specijalnog fajla, koji se zove korisničko poštansko sanduče (user mailbox), gde se
čuvaju sve poruke upućene konkretnom korisniku, dok ih on ne preuzme, direktno ili posredstvom MAA agenta.
Drugi deo adrese ukazuje na domen odredišta. Organizacije obično izaberu jedan (ili više) hostova koji će
prihvatati sve e-mail poruke upućene na njihov domen. Host sa ovom ulogom se zove mail izmenjivač (ME -
mail exchanger). Mailbox-ovi svih registrovanih korisnika nalaze se na ME hostu.
MIME
Sistem elektronske pošte ima jednostavnu strukturu. Međutim, jednostavnost ima svoju cenu: mogu se prenosi
isključivo tekstualne poruke u NVT 7-bitnom ASCII formatu. Otuda potiču sledeća ograničenja: nije moguće
prenositi poruke u jezicima koji koriste alfabete sa apostrofima (srpski, nemački, francuski); ne-latinične
alfabete (ćirilica), poruke u jezicima koji ne koriste alfabet (kineski i japanski), a ni poruke sa ne-tekstualnim
sadržajem (slike, audio, video).
MIME (Multipurpose Internet Mail Extensions – višenamenska proširenja Internet pošte ) je dodatni protokol
koje omogućava prenos ne-ASCII sadržaja u e-mail poruci. Na strani pošiljaoca, MIME transformiše ne-ASCII
podatke u ASCII podatke, koje MTA klijent isporučuje na identičan način kao standardne, tekstualne poruke.
MTA server, na strani primaoca, prihvata ASCII podatke i prosleđuje ih MIME konvertoru da ih prevede u
prvobitni oblik. MIME možemo zamisliti kao skup funkcija za konverziju ne-ASCII podataka u ASCII i
obrnuto, kao što je prikazano na Sl. 4-26.
Korisnik Korisnik

UA UA

ne-ASCII kod ne-ASCII kod

MIME MIME

7-bitni NVT ASCII 7-bitni NVT ASCII

7-bitni NVT ASCII

MTA MTA

Sl. 4-26 MIME.

Sa podrškom za MIME, e-mail poruka može sadržati: više objekata u jednom telu, tekst bez ograničena u dužini
linija i ukupnoj dužini, skup karaktera različit od ASCII, različite fontove, binarne fajlove i multimedijalne
poruke (slike, audio i video).

105
MIME uvodi pet novih zaglavlja koji se mogu pridodati originalnom zaglavlju e-mail poruke kako bi se
definisali parametri transformacije (vidi tabelu T. 4-11).
T. 4-11 MIME zaglavlja.
Zaglavlje Značenje
MIME-Version: Definiše verziju MIME standarda
Content-Description: String koji opisuje sadržaj poruke
Content-Id: Jedinstveni identifikator poruke
Content-Trensfer-Encoding Način kodiranja tela poruke
Content-Type: Tip i format sadržaja poruke
MIME-Version. Ovo zaglavlje definiše korišćenu verziju MIME standarda i ujedno informiše korisničkog
agenta da u poruci postoji MIME sadržaj. Trenutno aktuelna verzija je 1.1.
Content-Description (opis sadržaja). Ovo zaglavlje definiše na sadržaj tele poruke (slika, audio, video).
Content-Id. Ovo zaglavlje sadrži jedinstveni identifikator poruke.
Content-Type (tip sadržaja). Ovo zaglavlje definiše tip podataka u telu poruke. Standardom je definisano je
nekoliko tipova, od kojih svaki ima jedan ili više podtipova. Tip i podtip su razdvojeni kosom crtom, npr.:
Content-Type: video/mpeg
Spisak tipova i podtipova dat je u tabeli T. 4-12.
T. 4-12 MIME tipovi i podtipovi.
Tip Podtip Opis
Plane Neformatirani tekst
Text Enriched Tekst sa jednostavnim formatiranjem
HTML HTML format
Gif Slike u GIF formatu
Image
Jpeg Slike u JPEG formatu
Audio Basic Zvuk
Video Mpeg Film u MPEG formatu
Ocet-stream sekvenca bajtova
Application
Postscript dokument za štampanje u PostScript formatu
Rfc822 MIME RFC 822 poruka
Message Partial Poruka je podeljena na delove
External-body Poruka se mora preneti nezavisno
Mixed Nezavisni delovi definisanom redosledu
Alternative Više poruka različitog formata
Multipart
Parallel Delovi moraju biti prikazani istovremeno
Digest Svaki deo je jedna kompletna RFC 822 poruka
Text. Koristi se za osnovni 7-bitni ASCII tekst. Kombinacija text/plane je za obične, neformatirane poruke koje
se mogu prikazati u obliku u kom su primljene, bez dodatnog procesiranja od strane MIME. Podtip text/enriched
znači da se u tekstu može koristiti jednostavan jezik za formatiranje teksta, koji omogućava da se označe npr.
boldirani delovi teksta, definiše poravnanje linija i sl.. Na primer, poruka:
The <bold> time </bold> has come the <italic> walrus </italic> said ...
Biće prikazana kao:
The time has come the walrus said ...
Kada je Web postao popularan, dodat je novi podtip, text/html koji omogućava da se e-mejlom šalju Web
stranice.
Image. MIME tip image označava da se e-mail porukom prenose slike. Za čuvanje i prenos slika u upotrebi su
brojni formati, sa ili bez kompresije. Dva formata, GIF i JPEG, ugrađeni su u skoro svaki Inernet pretraživač.
Tipovi audio i video se koriste za zvuk i video sadržaj, respektivno, uz napomenu da se video odnosi samo
vizuelnu informaciju, ali ne i preteći zvuk. Ako treba preneti filmski zapis, video i audio delovi se, u zavisnosti
od načina kodiranja, prenose ili nezavisno ili kao jedinstvena celina. MPEG je prvi format koji je bio korišćen
za kodiranje videa; kasnije su dodati i neki drugi.
Application. Ovaj tip se odnosi na formate koji zahtevaju eksterno procesiranje koje nije predviđeno nekim
drugim tipom. Podtip octet-stream predstavlja proizvoljnu (neinterpretiranu) sekvencu bajtova (binarni fajl). Po
prijemu takvog sadržaja, korisnički agent obično predloži korisniku da dobijeni sadržaj kopira u fajl, a naknadno

106
procesiranje se prepušta korisniku. Podtip postscript se odnosi na jezik PostScript (razvijen u firmi Adobe
Systems) koji se široko koristi za opis stranica predviđenih za štampanje. Mnogi štampači imaju ugrađene
interpretatore za PostScript.
Message. Ovaj tip omogućava da jedna poruka bude u potpunosti sadržana u nekoj drugoj. Podtip rfc822 se
odnosi na slučaj kada telo poruke sadži kompletnu klasičnu e-mail poruku (zajedno sa njenim zaglavljem). Ova
šema je korisna za prosleđivanje e-mail poruka. Podtip partial se koristi ako je prvobitna velika poruka
razbijena na više e-mail poruka. Svaka takva e-mail poruka - fragment sadži zaglavlje message/partial sa još tri
dodatna parametra: id, number i total. Id definiše originalnu poruku i sadržano je u svim fragmentima. Number
(broj) definiše redni broj fragmenta, a total ukupni broj fragmenata. MIME na odredištu prikuplja fragmente i
rekonstruiše prvobitnu poruku. Sledi primer sadržaja zaglavlja Content-Type prvog fragmenta poruke koja je
razbijena na tri fragmenta:
Content-Type: message/partial;
id=˝gdjordj@elfak.ni.ac.yu˝;
number=1;
total=1;
Podtip external-body se može koristi za izrazito velike poruke (npr. film). Umesto da se u e-mail poruku uključi
MPEG fajl, daje se FTP adresa sa koje korisnički agent može da pribavi fajl. Tri prateća parametra definišu ime
fajla, njegovu lokaciju i način pristupa, na primer:
Content-Type: message/external-body;
name=˝IT.pdf˝;
site=es.elfak.ni.ac.yu/it;
access-type=˝ftp˝;
Multipart. Telo poruke može sadržati više jasno razdvojenih delova. Svrha multipart zaglavlja je da definiše
granice između ovih delova. Poseban parametar zaglavlja multipart definiše granični string. U telu poruke,
svakom delu poruke prethodi linija koja sadrži granični string kome predhode dva znaka minus ˝--˝. Telo poruke
se završava linijom koja sadrži graničnog stringa omeđen sa obe strane sa po dva znaka minus.
Tip multipart podržava četiri podtipa: mixed, parallel, digest i alternative. Podtip mixed omogućava da svaki
deo bude različitog tipa. Tip dela (tj. njegov Content-Type) naveden je odmah nakon granične linje. Sledeći
primer pokazuje poruku iz više delova mixed tipa:
Content-Type: multipart/mixed;boundary=xxxx;

--xxxx
Content-Type:text/plane;
--------------------------
--xxxx
Content-Type:image/gif;
--------------------------
--xxxx--
Podtip parallel se koristi kada svi delovi moraju biti prikazani istovremeno. Na primer, filmovi često imaju
razdvojene audio i video kanale, koje treba istovremeno reprodukovati. Podtip digest se koristi u slučajevima
kada je u e-mail poruku upakovan veći broj drugih e-mail poruka. , podtip alternative omogućava da isti sadržaj
bude uključen u poruku više puta, ali u različitim oblicima. Na primer, poruka može biti poslata u tri oblika: kao
običan ASCII tekst, kao enriched tekst i kao PostScript. Korisnički agent će najpre pokušati da poruku prikaže
kao PostScript, ako je moguće. Druga mogućnost je enriched, a ako ni to nije u stanju, prikazaće ASCII tekst.
Pr. 4-4 Multipart poruka
Primer sa Sl. 4-27 odgovara jednoj multimedijalnoj poruci. Rođendanska čestitka je poslata u dva oblika, kao
tekst i kao zvuk. Ako prijemnik ima mogućnost da reprodukuje audio, korisnički agent će pribaviti audio fajl
birthday.snd sa navedene adrese i reprodukovaće ga. U suprotnom, biće prikazan tekst. Dva dela poruke su
razdvojena linijom koja počinje duplom crtom sa stringom u nastavku koji je definisan parametrom boundary.
Uočimo da se zaglavlje Content-Type javlja na tri mesta. Prvo pojavljivanje, u zaglavlju cele poruke, ukazuje da
poruka ima više delova. U okviru svakog dela, definiše tip i podtip dela. Konačno, u telu drugog dela, zaglavlje
Content-Type je potrebno kao obaveštenje korisničkom agentu o tipu eksternog fajla koji treba pribaviti.
Takođe, za eksterni deo koji nije ASCII tipa, potrebno je i polje content-transfer-encoding.

107
 Zaglavlje
poruke
Content-Type: multipart/alternative; boundary=qwerqcewfqweffqe

--qwerqcewfqweffqe
Content-Type: text/enriched;

Happy birthday to you

Happy birthday to you
Happy birthday dear <bold> Tanja </bold>

poruke
Happy birthday to you

Telo
--qwerqcewfqweffqe
Content-Type: message/external-body;
access-tipe=”ftp”;
site=”music.com”
name=”birthday.snd”

Content-type:audio&basic
Content-transfer-encoding: base64
--qwerqcewfqweffqe--

Sl. 4-27 Primer mulipart poruke.

Zaglavlje Content-Transfer-Encoding ukazuje na način (šemu) kodiranja tela poruke. Raspoloživa su pet tipa
kodiranja (vidi tabelu T. 4-13).
T. 4-13 Content-transfer-encoding tipovi.
Tip Opis
7bit NVT ASCII karakteri i kratke linije
8bit Ne-ASCII karakteri i kratke linije
Binary Jedinstveni Ne-ASCII karakteri sa linijama neograničene dužine
Base64 6-bitni blokovi podataka su kodirani 8-bitnim ASCII karakterima
Quated-printable Ne-ASCII karakteri su kodirani parom znak jednakosti i ASCII kod
7bit. Ova opcija odgovara 7-bitnom NVT ASCII kodiranju i koristi se za standardni ASCII tekst, uz uslov da
dužina linije ne sme preći 1000 karaktera.
8bit. Ova opcija odgovara 8-bitnom kodiranju i koristi se za prenos ne-ASCII karaktera sa ograničenjem da
dužina linije ne sme preći 1000 karaktera. Za ovaj tip MIME ne vrši bilo kakvu transformaciju, već se
podrazumeva da je MTA protokol (najčešće SMTP) u stanju da direktno obavlja prenos 8-bitnih ne-ASCII
karaktera. Pošto to ne mora uvek biti slučaj, za prenos binarnog sadržaja, umesto ove opcije, preporučuje se tip
Base64 ili quated-printable.
Binary. Ova opcija odgovara 8-bitnom kodiranju i koristi se za prenos ne-ASCII karaktera bez ograničenjem da
dužina linije ne sme preći 1000 karaktera. Za ovaj tip MIME ne vrši bilo kakvu transformaciju, već se
podrazumeva da je MTA protokol (najčešće SMTP) u stanju da direktno obavlja prenos binarnih podataka.
Pošto to ne mora uvek biti slučaj, za prenos binarnog sadržaja, umesto ove opcije, preporučuje se tip Base64 ili
quated-printable.
Base64. Ova opcija služi za kodiranje binarnog sadržaja. Kod ove šeme, grupa od 24 bita se deli na četiri 6-bitna
dela od kojih se svaka prenosi kao jedan legalni ASCII karakter ( Sl. 4-28).

Sl. 4-28 Base64 kodiranje.

Kod za 0 (tj. ˝000000˝) je ˝A˝, kod za 1 (˝000001˝) je ˝B˝ i td. Najveća 6-bitna vrednost je 63, što će zahtevati
upotrebu malih slova, deset cifara i još dva znaka, ˝+˝ i ˝–˝, za 62 i 63. Dva uzastopna znaka jednakosti, ==,
znače da poslednja grupa sadrži samo 8, a jedan znak jednakosti da sadrži samo 16 bita. Znakovi za novi red se
ignorišu prilikom interpretacije poruke, a umeću se u poruku da bi se dužina linije ograničila na 76 karaktera.
Na primer, ispod je dat izgled binarnog fajla kodiranog šemom base64:

108
 SVNBKjAwKiAgICAgICAgICAqMDAqICAgICAgICAgICowMSo5ODc2NTQzMjEgICAgICAqMTIq
ODAwNTU1MTIzNCAgICAgKjkxMDYwNyowMTExKlUqMDAyMDAqMTEwMDAwNzc3KjAqVCo+CkdT
KlBPKjk4NzY1NDMyMSo4MDA1NTUxMjM0KjkyMDUwMSoyMDMyKjc3MjEqWCowMDIwMDMKU1Qq
ODUwKjAwMDAwMDAwMQpCRUcqMDAqTkUqTVMxMTEyKio5MjA1MDEqKkNPTlRSQUNUIwpSRUYq
SVQqODEyODgyNzc2MwpOMSpTVCpNQVZFUklDSyBTWVNURU1TCk4zKjMzMTIgTkVXIEhBTVBT
SElSRSBTVFJFRVQKTjQqU0FOIEpPU0UqQ0EqOTQ4MTEKUE8xKjEqMjUqRUEqKipWQypUUDhN
TSpDQipUQVBFOE1NClBPMSoyKjMwKkVBKioqVkMqVFAxLzQqQ0IqVEFQRTEvNElOQ0gKUE8x
KjMqMTI1KkVBKioqVkMqRFNLMzEvMipDQipESVNLMzUKQ1RUKjMKU0UqMTEqMDAwMDAwMDAx
CkdFKjEqNzcyMQpJRUEqMSoxMTAwMDA3NzcK
Originalni binarni sadržaj se lako može povratiti. (Svaki znak se zameni odgovarajućom 6-bitnom binarnom
sekvencom, a novi redovi se ignorišu). Pošto u poruci postoji ukupno 612 karaktera, odgovarajući binarni fajl
sadrži 612*6 = 3672 bita, odnosno 3672 /8 = 459 bajta. Pošto se svaki ASCII karakter predstavlja sa 7 bita,
ukupan broj bita koji se prenose porukom iznosi 612*7 = 4284. Šema kodiranja base64 unosi premašenje od
oko 16.67% u odnosu na direktni prenos binarnog fajla.
Quated-printable. Za poruke koje su najvećim delom ASCII, ali sadrže i manji broj ne-ASCII karaktera, šema
base64 je neefikasna. Umesto nje, može se koristiti šema quated-printable. Kod ove šeme kodira se bajt po bajt
binarnog fajla. Ako je binarna vrednost bajta manji od 127 (osmi bit je 0), bajt se zamenjuje odgovarajućim 7-
bitnim ASCII karakterom. Ako je bajt veći od 127 (osmi bit je 1), bajt se zamenjuje znakom jednakosti nakon
kojeg sledi vrednost bajta izražena sa dve heksadecimalne cifre (vidi Sl. 4-29).

Sl. 4-29 Quated-printable kodiranje.

4.4.3 Agent za prenos poruka: SMTP

Prenos e-mail poruka obavlja agent za prenos poruka (MTA). MTA klijent šalje, a MTA server prima poruku.
SMTP ((Simple Mail Transfer Protocol - jednostavan protokol za prenos poruka) je formalni Internet protokol
koje realizuje MTA klijenta i servera. Kao što je već rečeno, za prenos e-mail prouka, u opštem slučaju (četvrti
scenario), neophodna su dva para MTA klijent-server programa. Na Sl. 4-30 je prikazan domen SMTP protokola
za ovaj scenario.
SMTP SMTP

Primalac
Pošiljac

LAN LAN

Mail server Internet Mail server

Sl. 4-30 Oblast primene protokla SMTP.

SMTP se koristi dva puta. Između pošiljaoca poruke i njegovog mail servera, kao i između mail servera
pošiljaoca i mail servera primaoca. (Između mail servera i primaoca koristi se jedan drugi protokol, o kome će
kasnije biti reči.) Pojednostavljeno rečeno, SMTP definiše komande i odzive koji se razmenjuju između MTA
klijenta i servera.
Komande i odzivi
SMTP koristi komande za prenos poruke između MTA klijenta i servera (Sl. 4-31). Svaka komanda ili odziv je
završen sa dva specijalna karaktera koji se standardno koriste za označavanje kraja linije, CR LF, (CR - carriage
return; LF - line feed).

109
 Sl. 4-31 Komande i odzivi.
Komande
Komande se šalju od klijenta ka serveru. Format komande je jednostavan; komanda počinje ključnom rečju
nakon koje slede nula ili više argumenata. SMTP definiše 14 komandi. Prvih 5 su obavezne (moraju biti
podržane u svakoj implementacija SMTP protokola). Sledeće tri se povremeno koriste i tretiraju se kao
preporučive. Poslednjih šest se retko koriste. Spisak komandi dat je u tabeli T. 4-14.
T. 4-14 SMPT komande.
Ključna reč Argumenti
HELO Ime hosta pošiljaoca
MAIL FROM Pošiljalac poruke
RCPT TO Primalac poruke
DATA Telo poruke
QUIT
RSET
VRFY Ime primaoca koje treba verifikovati
NOOP
TURN
EXPN Mailing lista koju treba proširiti
HELP Ime komande
SEND FROM Primalac poruke
SMOL FROM Primalac poruke
SMAL FROM Primalac poruke
Sledi detaljnije objašnjenje obaveznih i preporučenih SMTP komandi.
HELO. Ovom komandom klijent se predstavlja serveru. Argument je ime domena klijentskog hosta. Format
komande je:
HELO: elfak.ni.ac.yu
MAIL FROM. Ovom komandom klijent identifikuje pošiljaoca poruke. Argument je e-mail adresa pošiljoca
poruke (lokalni deo plus ime domena). Format komande je:
MAIL FROM: ana@elfak.ni.ac.yu
RCPT TO. Ovom komandom klijent identifikuje primaoca poruke. Argument je e-mail adresa primaoca. Ako
se poruka šalje na više adresa, komanda se ponavlja za svakog primaoca. Format komade je:
RCPT TO: milan@elfak.ni.ac.yu
DATA. Ova komanda se koristi za slanje sadržaja poruke. Linije koje slede nakon komande DATA, tretiraju se
kao e-mail poruka. Poruka se završava linijom koja sadrži samo jednu tačku. Format komadne je:
DATA
Ovo je poruka koju Ana
šalje Milanu.
QUIT. Ovom komandom se završava poruka. Format:
QUIT
RSET. Ova komanda prekida e-mail transakciju koja je u toku. Podaci o pošiljaocu i primaocu se brišu, a
konekcija resetuje.
RSET
VRFY. Ova komanda se koristi za proveru adrese primaoca. Argument komade je adresa koju treba proveriti.
Klijent traži od servera da potvrdi da adresa koju mu šalje identifikuje postojećeg primaoca. Format:
VRFY: milan@elfak.ni.ac.yu
NOOP. Ovom komandom klijent proverava status primaoca. Očekuje se odgovor od primaoca. Format:
NOOP

110
Odzivi
Odzivi se prenose od servera ka klijentu. Odziv je tro-cifarski numerički kôd. Posle kôda, u istoj liniji, može da
sledi tekstualna informacija. Značenja prve cifre su:
2yz (konačni pozitivan odziv). Akcija je završena. Server je spreman da prihvati sledeću komandu.
3yz (pozitivan među-odziv). Komanda je prihvaćena, ali su neophodne dodatne informacije.
4yz (prolazni negativan odziv). Akcija nije startovana, jer server trenutno nije u mogućnosti da je
izvrši. Ista komanda može biti poslata kasnije.
5yz (permanentni negativan odziv). Komanda nije prihvaćena i ne bi trebalo pokušavati ponovo.
Druga i treća cifra pružaju dodatne informacije o odzivu.
Faze prenosa poruke
Proces prenosa e-mail poruke ostvaruje se u tri faze: uspostavljanje veze, prenos poruke i raskidanje veze.
Uspostavljanje veze
SMTP server započinje fazu uspostavljanja veze, nakon što klijent uspostavi TCP konekciju sa serverom na
dobro-poznatom portu 25. Ova faza sadrži sledeća tri koraka ( Sl. 4-32):
1. Server šalje kôd 220 (servis je spreman) kojom obaveštava klijenta da je spreman da primi poruku. U
slučaju da nije u mogućnosti da prihvata nove poruke, server će poslati kôd 421 (servis nije dostupan).
2. Klijent šalje komandu HELO kojom serveru, radi identifikacije, šalje ime svog domena. Ovaj korak je
neophodan kako bi se serveru dostavilo ime domena sa kojeg dolazi poruka. (Setimo se da tokom
uspostavljanja TCP konekcije, klijent i server razmenjuju svoje IP adrese, ali ne i imena svojih
domena.)
3. Server odgovara kôdom 250 (zahtevana komanda je izvršena), ili nekim drugim, zavisno od situacije.

Sl. 4-32 Uspostavljanje veze.

Prenos poruke
Nakon što je između klijenta i servera uspostavljena veza, moguće je preneti jednu poruku između jednog
pošiljaoca i jednog ili više primaoca. Ova faza sadrži osam koraka. Koraci 3 i 4 se ponavljaju ako postoji više od
jednog primaoca ( Sl. 4-33).
1. Klijent šalje komandu MAIL FROM kojom predstavlja pošiljaoca poruke. Komanda sadrži e-mail
adresu pošiljaoca. Ovaj korak je potreban kako bi se serveru dostavila povratna e-mail adresa na koju
će moći, u slučaju neke greške, da pošalje poruku sa obaveštenjem o problemu u isporuci poruke.
2. Server odgovara kôdom 250 (OK).
3. Klijent šalje komandu RCPT TO koja sadrži e-mail adresu primaoca.
4. Server odgovara kôdom 250 (OK).
5. Klijent šalje komandu DATA, kojim inicijalizuje prenos poruke.
6. Server odgovara kôdom 354 (start mail input - počni sa slanjem poruke).
7. U narednim linijama, klijent šalje sadržaj poruke. Svaka linija se završava kombinacijom specijalnih
karaktera CR LF. Poruka se završava linijom koja sadrži samo jednu tačku.
8. Server odgovara kodom 250 (OK).

111
 Sl. 4-33 Prenos poruke.
Raskidanje veze
Nakon što je poruka uspeštno preneta, klijent raskida vezu sa serverom. Ova faza uključuje dva koraka (Sl.
4-34):
1. Klijent šalje komandu QUIT.
2. Server odgovara kôdom 221.

MTA MTA
klijent server

QUIT

221 Service closed

Sl. 4-34 Raskidanje veze.

Nakon što je veza raskinuta, sledi raskidanje TCP konekcije.

4.4.4 Agent za preuzimanje poruka: POP3 i IMAP4

Isporuka e-mail poruke od pošiljaoca do primaoca, u najopštijem slučaju, uključuje tri faze. U prvoj fazi,
klijentski računar šalje poruku svom mail serveru koji, u drugoj fazi, poruku isporučuje mail serveru primaoca.
Konačno, u trećoj fazi, primalac preuzima poruku od svog mail servera. SMTP se koristi u prvoj i drugoj, ali ne
i u trećoj fazi. Kao što je već pomenuto, SMPT je protokol push tipa koji omogućava klijentu da pošalje (preda)
poruku severu. Međutim, u trećoj fazi neophodan je protokol pull tipa: klijent preuzima (traži) poruku od
servera. U trećoj fazi koristi se agent za prisup porukama (MAA).
Danas su u upotrebi dva MAA protokola: POP3 (Post Office Protocol, version 3 - Poštanski protokol, verzije 3)
i IMAP4 (Internet Mail Access Protocol, version 4 - Internet protokol za pristup e-mail-ovima, verzije 4 ). Na Sl.
4-35 je prikazana pozicija ova dva protokola u najčešćoj situaciji (četvrti scenario).

112
 Sl. 4-35 Oblast primene protokola POP3 i IMAP4.
POP3
POP3 je jednostavan protokol za preuzimanje poruka ograničene funkcionalnosti. POP3 klijent je instaliran na
računaru primaoca, a POP3 server na mail serveru. POP3 počinje sa radom kada korisnik startuje program za e-
mail-ove, ili klikne dugme ˝Send/Receive˝ u programu kao što je Microsoft Outlook, sa namerom da preuzme
pristigle e-mail poruke iz svog poštanskog sandučeta na mail serveru. Program za e-mail-ove se obraća POP3
klijentu koji uspostavlja TCP konekciju na portu 110 sa POP3 serverom. Po uspostavljanju konekcije, POP3
obalja sledeća tri koraka:
1. Autorizacija
2. Transakcije
3. Ažuriranje
Autorizacija se odnosi na proveru prava pristupa korisnika mailbox-u na mail serveru, što uključuje slanje
korisničkog imena i lozinke. Transakcija omogućava korisniku da pregleda sadržaj i preuzme e-mail poruke,
jednu po jednu, iz svog mailbox-a. POP3 podržava dva režima rada: režim brisanja i režim čuvanja e-mail-ova.
U režimu brisanja, nakon preuzimanja, e-mail poruka se označava za brisanje. U fazi ažuriranja, e-mail-ovi
označeni za brisanje se odstranjuju iz mailbox-a. U režimu čuvanja, preuzeti e-mail-ovi ostaju u korisnikovom
mailbox-u. Režim brisanja se obično koristi kada korisnik radi na svom stalnom računaru na kome čuva i
organizuje sve svoje e-mail poruke. Režim čuvanja se obično koristi kada korisnik pristupa svojim e-mail-ovima
sa nekog drugo računara, kojeg privremeno koristi. Korisnik je preuzeo i pročitao e-mail, ali umesto da bude
odstranjen, e-mail je ostao u mailbox-a na mail serveru, tako da kasnije ponovo može biti preuzet i eventualno
prenet na korisnikov stalni računar.
Slično SMTP protokolo, POP3 koristi komande i odzive za interakciju između klijenta i servera. Bez ulaženja u
detaljnije objašnjenje pojedinačnih komandi i odziva, razmotrimo primer preuzimanja e-mail-ova pomoću
protokola POP3 ilustrovan na Sl. 4-36.

113
 Sl. 4-36 POP3.
Nakon što klijent uspostavi TCP konekciju sa serverom na portu 110, server se prvi javlja slanjem ASCII
poruke. Ova poruka obično sadrži +OK, na početku i neki komentar u nastavku. U toku faze autorizacije, klijent
šalje svoje korisničko ime, a onda i lozinku (komande USER i PASS). Nakon uspešne autorizacije, klijent
prelistava sadržaj svog mailbox-a pomoću komande LIST. Server vraća spisak poruka (svaka poruka u jednoj
liniji) zajedno sa veličinama poruka. Spisak se završava tačkom. Klijent, koji sada poseduje spisak, preuzima
poruke komandom RETR navodeći redni broj poruke kao parametar. U datom primeru, korisnik je obe preuzete
poruke označio za brisanje (komandom DELE). Pošto je preneo sve svoje poruke, klijent završava fazu
transakcije komandom QUIT. Po prijemu ove komande server ulazi u fazu ažuriranja, kada iz korisnikovog
mailboxa briše sve poruke označene za brisanje. Nakon završenog brisanja poruka, server vraća odziv (+OK) i
zatvara TCP konekciju.
IMAP4
POP3 ima nekoliko nedostataka. Na primer, POP3 ne omogućava korisnicima da organizuju svoje e-mail
poruke na mail serveru. Takođe, POP3 ne pruža mogućnost korisnicima da delimično preuzmu e-mail pre nego
što odluče da li će ga preuzeti u celosti ili obrisati. Protokol IMAP4 je sličan protokolu POP3, ali ima više
funkicija.
IMAP4 pruža sledeće dodatne mogućnosti:
Korisnik može proveriti zaglavlje e-mail-a pre nego što ga preuzme.
Korisnik može pretraživati e-mail tražeći u njemu zadati string karaktera pre nego što ga preuzme.
Korisnik može delimično preuzeti e-mail (Ova mogućnost je korisna, ako se za vezu sa mail serverom
korisni dila-up modem, a u e-mail je prisutan multimedijalni sadržaj koji zahteva daleko veću
propusnost radi preuzimanja.)
Korisnik može da kreira, briše i preimenuje mailbox-ove na mail serveru.
Korisnik može da kreira hijerarhijski organizovane mailbox-ove.

114
4.5 DNS
Za identifikaciju entiteta na Internetu, TCP/IP koristi IP adrese koje na univerzalan i jedinstveni način
identifikuju vezu hosta na Internet. Međutim, ljudima je lakše da koriste imena nego IP adrese. Lakše je
zapamtiti: www.elfak.ni.ac.yu nego 160.136.4.23. Šta više, ako organizacija premesti Web server na drugu
mašinu, sa drugom IP adresom, npr. 160.136.4.100, promeniće se i njena Web adresa: 160.136.4.23. Simbolička
imena su uvedena upravo iz razloga da bi se imena hostova razdvojila od adresa hostova. Na taj način,
simbolička adresa www.elfak.ni.ac.yu može ostati ista i posle promene IP adrese. Međutim, mreža u svakom
slučaju razume samo IP adrese, što znači da je potreban mehanizam za preslikavanje simboličkih imena na IP
adrese.
Kada je Internet bio mali, za preslikavanje je korišćen tzv. host fajl. Host fajl ima samo dve kolone: ime i
adresa. Host fajl se čuvao na hard disku i periodično ažurirao preuzimanjem podataka iz glavnog host fajla.
Kada je nekom programu ili korisniku potrebno preslikavanje, host pretražuje host fajl i vraća IP adresu
pridruženu datom simboličkom imenu. Međutim, ovakav pristup je danas nemoguć. Zbog ogromnog broja
hostova na Internetu, host fajl bi bio previše veliki. Takođe, bilo bi nemoguće ažurirati host fajlove svih hostova
na Internetu uvek kada se desi neka promena.
Jedno rešenje bilo bi da se celokupan host fajl smesti na jedan centralizovani računar, a da se svi hostovi na
Internetu obraćaju ovom računaru uvek kada im je potrebno preslikavanje. Naravno, ni ovo rešenje nije
praktično, jer bi generisalo veliku količinu saobraćaja na Internetu, a otkaz centralizovanog računara doveo bi
do otkaza celog Interneta.
Rešenje koje se danas koristi zasnovano je na podeli ogromne količine informacija na manje delove koji se
čuvaju na različitim računarima. Host, kome je potrebno preslikavanja, obraća se najbližem računaru koji sadrži
traženu infomaciju. Ovakav metod koristi DNS (Domain Name System - Sistem imena domena). U ovoj sekciji
najpre će biti izloženi osnovni koncepti DNS-a, a potom i sam DNS protokol.
Prostor imena
Imena koja se dodeljuju mašinama biraju se iz prostora imena. Prostor imena može biti ravanski ili hijerarhijski.
Ravanski prostor imena
Kod ravanskog prostora imena, ime je pridruženo adresi. Imena iz ovog prostora su nizovi karaktera bez bilo
kakve unapred nametnute strukture. Imena mogu, ali ne moraju, imati zajedničke delove; ako ih imaju, onda to
nema neko posebno značenje. Ravanski prostora imena mora biti pod centralizovanom kontrolom, kao bi se
obezbedila jednoznačnost dodeljenih imena, što ga čini nepodesnim za velike sisteme, kao što je Internet.
Hijerarhijski prostor imena
Kod hijerarhijskog prostora imena, svako ime se sastoji iz nekoliko delova. Na primer, prvi deo može definisati
tip organizacije, drugi ime organizacije, treći odeljenje unutar organizacije, i td. U ovom slučaju, kontrola nad
dodelom imena može biti decentralizovana. Centralna uprava može kontrolisati dodelu delova imena koji
definišu tip i ime organizacije, dok se odgovornost za preostali deo imena može preneti na samu organizaciju.
Organizacija može dodavati sufikse (ili prefikse) kako bi kreirala imena za svoje hostove ili druge resurse.
Menadžment organizacije ne mora da brine da li je isti sufiks (ili prefiks) izabrala i neka druga organizacija, jer
čak iako je su delovi imena isti, celokupna imena su različita.
Prostor imena domena
Prostor imena domena je hijerarhijski prostor imena koji se koristi na Internetu. Prostor je struktuiran u obliku
invertovanog stabla sa korenom na vrhu. Stablo može imati najviše 128 nivoa: nivo 0 (koren) do nivo 127 (vidi
Sl. 4-37).

Sl. 4-37 Prostor imena domena.

Labela
Svaki čvor u stablu ima oznaku (labelu). Labela je string od maksimalno 63 karaktera. Labela korena je prazan
string. DNS zahteva da sva deca nekog čvora imaju različite labele, čime se garantuje jedinstvenost imena
domena.

115
Ime domena
Svaki čvor u stablu ima ime domena. Puno ime domena je niz labela razdvojenih tačkom (.). Ime domena se
uvek čita počev od posmatranog čvora pa naviše do korena. To znači da se puno ime domena uvek završava
praznim stringom, odnosno tačkom. Na Sl. 4-38 su prikazana neka imena domena.

Sl. 4-38 Imena domena i labele.

Puno ime domena (FQDN - Fully Qualified Domain Name)
FQDN je labela završena praznim stringom (odnosno tačkom). FQDN je ime domena koje sadrži puno ime
nekog hosta. Ono sadrži sve labele, od najkonkretnije do najopštije i na jedinstveni način definiše ime hosta. Na
primer:
golijat.elfak.ni.ac.yu.
je FQDN ime računara nazvanog golijat instaliranog na Elektronskom fakultetu u Nišu. DNS server preslikava
jedino FQDN imena na IP adrese.
Delimično ime domena (PQDN - Partially Qualified Domain Name)
Labela koja nije završena tačkom naziva se PQDN imenom. PQDN počinje od posmatranog čvora, ali ne doseže
do korena. PQDN se koristi kada ime koje treba preslikati pripada istom sajtu kao i klijent (onaj ko traži
preslikavanje). U ovom slučaju, deo koji nedostaje, tzv. sufiks, pridodaje program koji je zadužen za
preslikavanje imena, tzv. respolver, i tako formira FQDN. Na primer, korisnik sa sajta elfak.ni.ac.yu koji želi da
sazna IP adresu računara golijat, može definisati delimično ime:
golijat
Pre nego što prosledi ime DNS serveru, DNS klijent dodaje sufiks elfak.ni.ac.yu. Normalno, DNS klijent
poseduje listu sufiksa. Lista sufiksa na Elektronskom fakultetu u Nišu može imati sledeći oblik:
elfak.ni.ac.yu
ni.ac.yu
ac.yu
null
(Sufiks null znači ˝ništa˝. golijat sa sufiksom null postaje golijat. (sa tačkom na kraju)).
Domen
Domen je podstablo prostora imena domena. Ime domena je ime domena čvora na vrhu podstabla. Na Sl. 4-39 su
prikazani neki domeni. Uočimo da i sam domen može biti podeljen na domene (ili poddomene, kako se
ponekada nazivaju).

Sl. 4-39 Domeni.

116
Podela prostora imena
Informacije sadržane u prostoru imena domena moraju negde biti smeštene. U teoriji, dovoljan je jedan host koji
bi čuvao sve informacije o prostoru imena Interneta i odgovarao na sve upite koji bi dolazili iz bilo kog kraja
sveta. Međutim, u praksi, takav jedan sever bi do te mere bio preopterećen da bi bio beskoristan. Uz to, ako bi
otkazao, ceo Internet bi stao.
Hijerarhija DNS servera
Rešenje pomenutih problema je u distribuciji informacija na veliki broj računara, tzv. DNS servera, tj. server za
prevođenje imena domena. To se može uraditi tako što će se celokupan prostor podeli na domene shodno prvom
nivou. Drugim rečima, slično kao na Sl. 4-39, za svaki čvor sa prvog nivoa kreira se jedan domen koji obuhvate
sve čvorove podstabla sa korenom u tom čvoru. Obzirom da domeni kreirani na ovaj način mogu biti veoma
veliki, DNS omogućava podelu domena na manje domene (ili poddomene). Svaki server može biti odgovoran za
jedan domen. Na taj način, formira se hijerarhija servera, slično hijerarhiji imena.
Zona
Oblast odgovornosti DNS severa se naziva zonom. Zona se može definisati kao povezani deo stabla. Ako je
server odgovoran za domen, a taj domen nije dalje podeljen na manje domene, tada je ˝zona˝ isto što i ˝domen˝.
Server kreira bazu podataka, tzv. zonski fajl (eng. zone file) u kojoj čuva sve informacije o svakom čvoru unutar
tog domena. Međutim, ako je domen servera podeljen na poddomene i deo njegovih odgovornosti prebačen na
druge servere, ˝domen˝ i ˝zona˝ više nemaju isto značenje. Informacije o čvorovima iz poddomena čuvaju se u
zonskim fajlovima servera sa nižih nivoa, dok prvobitni server čuva neku vrstu referenci na servere sa nižih
nivoa. Naravno, vršni server se ne oslobođa u potpunosti odgovornosti: on još uvek ima zonu, ali se detaljne
informacije čuvaju kod servera sa nižih nivoa (Sl. 4-40).
Koren

com Zona

Domen
yahoo
Zona i
domen

Sl. 4-40 Zone i domeni.

Primarni i sekundarni serveri
DNS definiše dva tipa servera: primarni i sekundarni. Primarni server je onaj koji na svom hard disku čuva fajl
o zoni za koju je odgovoran. Primarni server kriera održava i ažurira zonski fajl.
Sekundarni server je server koji informacije o zoni dobija od nekog drugog servera (primarnog ili sekundarnog).
Sekundarni serveri ne kreiraju niti ažuriraju zonske fajlove. Ako je ažuruiranje neophodno, ono se obavlja na
primarnom serveru, koji potom sekundarnim serverima šalje ažurnu verziju.
I primarni i seknundarni serveri su odgovorni za zonu koju pokrivaju. Ideja nije da se sekundarni severi postave
na niži nivo odgovornosti u odnosu na primarni server, već da se postigne redundantnost tako da u slučaju da
jedan server otkaže preostali mogu nastaviti da opslužuju klijente.
Root server
Root (ili vršni) server je server čiju zonu čini čitavo stablo. Vršni server obično ne čuva bilo kakve informacije o
domenima, već delegira svoju odgovornost na druge servere, čuvajući samo reference na te servere. Postoji
nekoliko vršnih server, distribuiranih po celom svetu, od kojih svaki pokriva celokupan prostor imena domena.
DNS na Internetu
Na Internetu, prostor imena domena (stablo) je podeljeno na dve sekcije: generički (opšti) domeni i nacionalni
domeni (Sl. 4-41). Labele generičkih domena navedene su u tabeli T. 4-15. Svaka država ima svoj nacionalni
domen. Generički domeni su pod kontrolom organizacije ICANN. Imena nacionalnih domena su
standardizovana (ISO 3166).

117
 Sl. 4-41 Generički i nacionalni domeni.
T. 4-15 Generički domeni.
Oznaka Opis
com komercijalne organizacije
edu obrazovne institucije
gov vladine institucije
int međunarodne organizacije
mil vojne grupacije
net centri za podršku mreži
org neprofitne organizacije
aero avio-kompanije
biz komercijalne organizacije i firme (slično .com)
coop organizacije za kooperativno poslovanje
info informacioni servisi
museum muzeji i druge neprofitne organizacije
name lična imena (pojedinci)
pro profesionalne individualne organizacije
Na drugom nivou hijerarhije su domeni registrovani od strane kompanija, univerziteta i drugih privatnih, javnih
ili vladinih institucija ali i privatnih lica. Registracija takvog domena podrazumeva proveru da li je ime domena
slobodno i da li je registrovani zaštitni znak. Ako nema problema, podnosilac zahteva, uz simboličnu novčanu
godišnju pretplatu, dobija prava korišćenja domena. Do danas, praktično sve česte reči engleskog jezika su
zauzete.
Razrešavanje imena
Proces preslikavanja imena na adrese ili adresa na imena naziva se razrešavanjem ili rezolucijom (od name-
address resolution).
Razrešivač
DNS je projektovan kao klijent-server aplikacija. Host kome je potrebno preslikavanje, bilo imena na adrese
bilo adresa na imena, poziva DNS klijenta koji se naziva razrešivačem. Razrešivač se obraća najbližem DNS
serveru za zahtevom za konkretno razrešavanje. Ako poseduje traženu informaciju, server vraća odgovor
razrešivaču; inače, server upućuje rezrešivač na nekog drugog servera ili se sam obraća drugim serverima kako
bi pribavio traženu informaciju. Kada dobije rezultat preslikavanja, razrešivač najpre interpretira odgovor, da bi
proverio da li odgovor sadrži traženo razrešavanje ili grešku, i konačno, isporučuje rezultat procesu koji je
zahtevao razrešavanje.
Najčešće, razrešivač šalje serveru ime domena tražeći od njega odgovarajuću adresu, što odgovara preslikavanju
imena na adrese. (Na primer, razrešivač može dobiti zahtev da razreši ime domena www.elfak.ni.ac.yu.) Mnogo
ređe, klijent šalje serveru IP adresu koju želi da preslika na odgovarajuće ime domena. Ovakav tip upita se
naziva inverzinim upitom. (Na primer, razrešivač može dobiti zahev da pronađe ime domena za IP adresu
160.99.13.134.)
Rekurzivno i iterativno razrešavanje upita
Postoje dva načina obrade DNS upita: rekurzivno i iterativno razrešavanje.
Rekurzivno razrešavanje. Kod rekuzivne obrade DNS upita, klijent (razrešivač) očekuje da konačni odgovor na
svoj upit dobije direktno od servera kome je postavio pitanje. Ako je domen koji se traži u nadležnosti DNS
servera, razrešivač direktno dobija odgovor. Međutim, ako se radi o udaljenom domenu, a informacija o njemu

118
nije dostupna na lokalnom DNS serveru, server šalje zahtev nekom drugom serveru (obično roditeljskom
serveru) i čeka na odgovor. Ako je odgovoran za ime domena, roditeljski server će vratiti odgovor, a ako nije,
proslediće upit sledećem serveru. Kada je upit konačno razrešen, odgovor se istom putanjom vraća unazad, od
servera do servera, sve dok konačno ne stigne do klijenta koji je izdao prvobitni zahtev. Opisani princip je
prikazan na Sl. 4-42.

6
2

5
9
Sl. 4-42 Rekurzivno razrešavanje.
Iterativno razrešavanje. Kod iterativnog razrešavanja, server koji nije u mogućnosti da obavi razrešavanje ne
obraća se sledećem serveru, već nazad vraća IP adresu servera za koga smatra da može razrešiti upit. Klijent
ponavlja upit i šalje ga ovom drugom serveru. Ako zna odgovor, drugi server vraća klijentu odgovarajuću IP
adresu; inače, klijentu vraća IP adresu sledećeg DNS servera. Klijent se sada mora obratiti trećem serveru i td.
Opisani proces se naziva iterativnim zato što klijent ponavlja isti upit ka više servera. Na Sl. 4-43 klijent iz
domena fhda.edu koji zahteva razrešavanje imena iz domena yahoo.com dobija konačni odgovor tek od četvrtog
servera odgovornog za domen yahoo.com.

Sl. 4-43 Iterativno razrešavanje.

Keširanje
Svaki put kada primi upit koji se odnosi na ime koje nije iz njegovog domena, server, nakon pretraživanja svoje
baze imena, prosleđuje upit dalje odgovarajućem sledećem serveru. Zbog potrebe aktivnog učešća većeg broja
servera, proces razrešavanja, bilo da je se obavlja rekurzivno ili hijerarhijski, može biti dugotrajan. Da bi se
vreme razrešavanja skratilo, DNS koristi mehanizam keširanja. Server, svaki put kada primi odgovor na upti
poslat drugom serveru, smešta informacije iz odgovora u svoju keš memoriju, za slučaj da kasnije ponovo bude
potrebna. Ako nekada kasnije, isti, ili neki drugi klijent, zahtva isto preslikavanje, server će proveriti svoju keš
memoriju i obaviti zahtevano razrešavanje, bez potrebe da upit šalje nekom drugom serveru. Server vraća
odgovor klijentu, uz obaveštenje da odziv dolazi iz keš memorije, a ne od servera koji je nadležan za domen na
koji se upit odnosi.
Keširanje ubržava razrešavanje, ali i stvara nove probleme. Keširana preslikavanja nekog servera potiču iz
nekog drugog domena, za koji taj server nije odgovoran, a promena učinjena na udaljenom domenu se neće
preneti, sama od sebe u njegovu keš memoriju. Ako sever čuva keširano preslikavanje isuviše dugo, može se
desiti da odgovor koji šalje klijentu postane naužurno. Da bi se ovaj problem prevazišao, koriste se dve tehnike.
Prvo, kada odgovara na upit koji se odnosi na domen za koji je nadležan, sever preslikavanju koje vraća
pridodaje i vreme života (TTL - time-to-live ). TTL je vreme u sekundama koje definiše koliko dugo infomacija

119
iz odgovora može boraviti u keš memoriji bilo kog severa koji dođe u njen posed. Posle tog vremena,
preslikavanje se smatra zastarelim, a svaki sledeći upit mora ponovo biti proleđen nadležnom serveru. Drugo,
DNS zahteva da server svakoj stavci iz keš memoriju pridruži TTL brojač. Keš memorija se periodično
pretražuje i sve stavke sa prekoračenim vremenom života se odstranjuju iz memorije.
DNS poruke
DNS definiše dva tipa poruka: upit i odziv. Oba tipa imajuisti format. Poruka upita sadrži: zaglavlje i zapis za
pitanje, poruka odziva: zaglavlje, zapis za pitanje, zapis za odgovor, zapis za nadležnost i dodatne zapise ( Sl.
4-44).

(a) (b)
Sl. 4-44 Poruke upita i odziva: (a) upit; (b) odziv.
Zaglavlje
Oba tipa poruka imaju isti format zaglavlja, s tim što su kod poruke upita neka polja fiksno postavljena na ˝sve
nule˝. Zaglavlje sadrži 12 bajtova i njegov format je prikazan na Sl. 4-45.

Sl. 4-45 Format zaglavlja.

Polja zaglavlja imaju sledeće značenje:
Identifikacija. Ovo je 16-bitno polje koje služi klijentu da bi upario primljeni odziv sa ranije poslatim upitom.
Za svaku poruku upita, klijent koristi različiti identifikacioni broj. Server kopira ovaj identifikacioni broj iz
poruke upita u odgovarajuću poruku odziva.
Markeri (Flags). Ovo je 16-bitno polje podeljeno na više podpolja od kojih svako ima neko posebno zančenje
(Sl. 4-46).

Sl. 4-46 Polje za markere.

Markeri imaju sledeće značenje:
- QR (query/response - upit/odziv). Ovo je 1-bitno polje koje definiše tip poruke. Ako je 0, poruka je
upit; ako je 1, poruka je odziv
- OpCode (kôd operacije). Ovo je 4-bitno podpolje koje definiše tip upita ili odziva. (0 za standardni, 1
za inverzni upit/odziv i 2 za zahtev za status servera).
- AA (authoritative answer - odgovor o nadležnosti). Ovo je 1-bitno polje koje postavljeno na 1 znači da
je server nadležan za ime domena na koje se poruka odnosi. Koristi se samo u poruci odziva.
- TC (truncated - odsečeno). Ovo je 1-bitno polje koje postavljeno na 1 znači da je odziv bio duži od
512 bajta i da je skraćen na 512 bajta. Koristi se samo ako DNS koristi UDP za transport upita/odziva.
- RD (recursion desired - rekurzija poželjna). Ovo je 1-bitno polje koje postavljeno na 1 znači da bi
klijent želeo da se razrešavanje upita obavlja rekurzivno. Postavlja se poruci upita, a korpira u poruci
odziva.
- RA (recursion available - rekurzija je moguća). Ovo je 1-bitno polje koje kada je u poruci odziva
postavljeno na 1 znači da je rekurzivno razrešavanje raspoloživo. Postalja se samo u poruci odziva.

120
 - Reserved (rezervisano). 3-bitno polje fiksno postavljeno na 000.
- rCode (kôd greške). Ovo je 4-bitno polje koje ukazuje na status greške u odzivu. Status greške može
da postavi samo nadležni server. Delimičan spisak kôdova dat je u tabeli.
T. 4-16 Vrednosti polja rCode.
Vrednost Značenje
0 Nema greške
1 Greška u formatu
2 Problem na strani servera imena
3 Problem u referenciranju domena
4 Tip pitanja nije podržan
5 Administrativna zabrana
6-15 Rezervisano
Broj zapisa za pitanja. Ovo je 16-bitno polje koje sadrži broj pitanja u sekciji poruke predviđenoj za pitanja.
Broj zapisa za odgovore. Ovo je 16-bitno polje koje sadrži broj odgovora u sekciji poruke odziva predviđenoj za
odgovore. U poruci upita, vrednost ovog polja je ˝sve nule˝.
Broj dodatnih zapisa. Ovo je 16-bitno polje koje sadrži broj dodatnih zapisa u sekciji poruke odziva predvi đenoj
za dodatne zapise. U poruci upita, vrednost ovog polja je ˝sve nule˝.
Sekcija za pitanja
Ova sekcija sadrži jedan ili više zapisa za pitanja. Sekcija je prisutna u poruci upita, ali i u poruci odziva.
(Format zapisa za pitanja biće objašnjen nešto kasnije).
Sekcija za odgovore
Ova sekcija sadrži jedan ili više zapisa za odgovore. Sekcija je prisutna samo u poruci odziva i sadrži odgovor
koji server vraća klijentu (razrešivaču).
Sekcija za nadležnost
Ova sekcija je prisutna samo u poruci odziva i sadrži jedan ili više tzv. zapisa resursa. Sekcija sadrži informaciju
o jednom ili više servera koji su nadležni za ime domena iz odgovarajuće poruke upita.
Sekcija za dodatne informacije
Ova sekcija sadrži jedan ili više zapisa resursa i prisutna je samo u poruci odziva. Sekcija sadrži dodatne
informacije koje mogu biti od koristi razrešivaču. Na primer, server koji šalje vraća poruku odziva klijentu može
u sekciji za nadležnost upisati ime domena nadležnog servera, a u sekciji za dodatne informacije njegovu IP
adresu.
Tipovi zapisa
Kao što je već rečeno prilikm opisa formata DNS poruke, kod DNS-a se koriste dva tipa zapisa: zapisi za pitanja
i zapisi za resurse. Zapisi za pitanja se koriste u sekciji za pitanja u porukama upita i odziva. Zapisi za resurse se
koriste u sekcijama za odgovore, nadležnosti i dodatne informacije poruke odziva.
Zapis za pitanja
Zapis za pitanja koristi klijent da dobio informacije od servera. Konkretno, zapis sadrži ime domena. Format
zapisa za pitanja prikazan je na Sl. 4-47.

Sl. 4-47 Format zapisa za pitanja.

Ime upita (Query Name). Ovo je polje promenljive dužine koje sadrži ime domena u formatu kao na Sl. 4-48.

Sl. 4-48 Format imena upita. Napomena: svakoj labeli prethodi broj slova u labeli; ime se završava cifrom 0.
Tip upita (Query Type). Ovo je 16-bitno polje koje definiše tip upita. Neki od često korišćenih tipovo upita dati
su u tabeli.

121
 T. 4-17 Tipovi upita.
Tip Mnemonik Opis
1 A Adresa. 32-bitna IPv4. Koristi se za konverziju imena domena u IPv4 adresu
2 NS Server imena. Identifikuje nadležni server zone.
5 CNAME Kanoničko ime. Definiše alternativno ime oficijelnog imena hosta.
6 SOA Početak nadležnosti. Označava početak zone. Obično prvi zapis u fajlu zone.
11 WKS Dobro-poznati servis. Definiše mrežni servis kojeg pruža host.
12 PTR Pointer. Koristi se za konverziju IP adrese u ime domena.
13 HINFO Informacije o hostu. Sadrži opis hardvera i operativnog sistema hosta
15 MX Mail izmenjivač (server). Saadrži IP adresu mail servera domena.
28 AAAA Adresa. IPv6 adresa.
252 AXFR Traži se prenos celokupne zone.
255 ANY Traže se svi zapisi.
Klasa upita (Query class). Ovo je 16-bitno polje koje definiše protokol kojeg DNS koristi. Za primenu na
Internetu od interesa je jedino klasa 1.
Zapisi resursa
Svakom imenu domena (tj. svakom čvoru iz stabla prostora imena) pridružen je jedan zapis koji se zove zapis
resursa. Baza imena servera zapravo sadrži resurse zapisa. Takođe, resursi zapisa su ono sta sever vraća klijentu
kao odgovor na postavljeno pitanje. Na Sl. 4-49 je prikazan format zapisa resursa.

Sl. 4-49 Format zapisa resursa.

Ime domena (Domain name). Ovo je polje promenljive dužine koje sadrži ime domena. Iz razloga efikasnosti,
DNS zahteva da se u svim slučajevima kada se ime domena ponavlja više puta u poruci odziva u ovom polju
umesto imena nalazi pointer na prvo pojavljivanje imena domena (obično u zapisu pitanja). Pointer je veličine 2
bajta. Prva dva bita su 11, a preostalih 14 predstavljaju redni broj bajta u poruci koji odgovara prvom slovu
imena domena (Sl. 4-50).

Sl. 4-50 Format pointera u polju za ime domena.

Tip domena (Domain type). Sadržaj ovog polja je identičan sadržaju polja za tip upita iz zapisu pitanja s tim da
poslednja dva tipa nisu dozvoljena.
Klasa domena (Domain class). Sadržaj ovog polja je identičan sadržaju polja za klasu upita iz zapisu pitanja.
Vreme života (Time to live). Ovo je 16-bitno polje koje definiše vreme važenja odgovora u sekundama.
Prijemnik može da kešira odgovor, ali po isteku vrmena života ima obavezu da ga odstrani iz keš memorije.
Vrednost nula u ovom polju znači zabranu kešrianja informacije zapisa resursa.
Dužina polja za podatke (Resourse data length). Ovo je 16-bitno polje koje definiše dužinu polja za podatke u
zapisu resursa.
Podaci o resursu (Resource data). Ovo je polje promenljive dužine koje sadrži odgovor na upit (ako se zapis
nalazi u sekciji za odgovore) ili ime domena nadležnog servera (ako se zapis resursa nalazi u sekciji za
nadležnosti) ili dodatne informacije (ako se zapis resursa nalazi u sekciji za dodatne informacije). Format i
sadržaj ovog polja zavisi od tipa sadržane informacije i može biti:
Broj. Zapisan u oktetima (bajtovima). Na primer, IPv4 adresa je intedžer od 4 okteta.
Ime domena. Imena domena se predstavljaju kao niz labela. Svakoj labeli prethodi 1-bajtno polje koje
definiše broj karaktera u labeli. Pošto se svako ime domena završava praznom labelom, poslednji bajt
svakog imena domena je polje za dužnu sa vrednošću 0.
Pointer. Imena domena se mogu zameniti 2-bajtnim pointerom. Dva najviša bita pointera su uvek 11.

122
 Niz karaktera. Niz karaktera (string) sa 1-bajtnim poljem na početku koje sadrži broj karaktera u
stringu.
Pr. 4-5: DNS upit i odziv
Razrešivač šalje poruku upita lokalnom severu, da bi pronašao IP adresu hosta ˝elfak.ni.ac.yu˝. Posebno ćemo
razmotriti poruku upita i poruku odziva.
Na Sl. 4-51(a) je prikazana poruka upita koju je razrešivač poslao serveru. Prva 2 bajta sadrže idntifikacioni broj
poruke (1333). Kao što znamo razrešivač koristi identifikaciju da bi povezao primljeni odziv sa ranije poslatim
upitom, u slučajevima kada je razrešivača uzastopno poslao više upita, a odzivi su stigli izvan redosleda. Sledeći
bajt sadrži markere. Vrednost ovog polja 0x0100 heksadecimalno ili 0000000100000000 binarno, ili podeljeno
na podpolja:
QR OpCode AA TC RD RA Reserv. rCode
0 0000 0 0 1 0 000 0000
Bit QR postavljen na 0 znači da se radi o poruci upita. OpCode = 0000 znači da je upit standardnog tipa. Bit RD
postavljen na 1 znači da bi razređivač želeo da se razrešavanje obavi rekurzivno. Poruka sadrzi samo jedan zapis
pitanja. Ime domena je 5elfak2ni2ac2yu0. Sledeća dva bajta označavaju da je upit tipa IP adresa; poslednja dva
da je upita klase Internet.
Na Sl. 4-51(b) je prikazan odziv servera. Odziv je sličan upitu osim što su markeri drugačije postavljeni i
dodatno postoji jedan zapis odgovora. Vrednost polja za markere je 0x8180 heksadecimalno, odnosno
1000000110000000 binarno, il podeljeno na podpolja:
QR OpCode AA TC RD RA Reserv. rCode
1 0000 0 0 1 1 000 0000
Bit QR definiše poruku kao odziv. OpCode = 0000 znači da se radi o standardnom odzivu. Bitovi RA i RA su
postavljeni na 1, što znači server podržava rekurzivno razrešavanje. Zapis pitanja je ponovljen u poruci odziva.
Zapis odgovora počinje vrednošću 0xC00C (podeljeno u dve linije). Ova vrednost se tumači kao pointer na ime
domena. Sledeće polje definiše tip domena (adresa), a polje posle njega klasu (Internet). Polje sa upisanom
vrednošću 12,000 je vreme života (12,000 s). Sledeće polje je dužina podataka o resursu, a polje za podatke
sadrži IP adresu (153.18.8.105).

(а) (b)
Sl. 4-51 Pr. 4-5: (a) poruka upita; (b) poruka odziva.

123
5 Web
World Wide Web (ili samo Web) je kolekcija ogromnog broja elektronskih dokumenata sačinjenih od povezanih
Web stranica napisanih u HTML-u (Sl. 5-1). Stranice su raspoložive korisnicima Web-a u vidu datoteka
smeštenih na milionima računara distribuiranih po Internetu. Svaka stranica može sadržati pokazivače (tzv.
linkove ili hiperveze) na druge stranice koje mogu biti smeštene na istom ili na nekom drugom računaru (ili, u
terminologiji Web-a, Web sajtu). Klikom na link, korisnik prelazi na sledeću stranicu, a ovaj proces se može
nastaviti u nedogled. Koncept stranica koja sadrži pokazivače na druge srodne stranice naziva se hipertekstom.
Stranica može sadržati i delove koji nisu tekstualni (npr. slike).

Sl. 5-1 Web - distribuirana kolekcija povezanih dokumenata.

Da bi se Web implementirao na Internetu koriste se dve glavne komponente: Web pretraživač i Web server.
Web pretraživač (browser) je aplikacioni program koji korisnik poziva da bi pristupio stranici i prikazao je.
Najpoznatiji Web pretraživači su Internet Explorer i Natscape Navigator. Web pretraživač ima ulogu klijenta
koji stupa u vezu sa odgovarajućim Web serverom da bi dobio primerak navedene stranice. Pretraživač pribavlja
traženu stranicu, interpretira tekst zajedno sa sadržanim komandama za formatiranje, i prikazuje ga na ekranu
monitora. Primer stranice prikazan je na Sl. 5-2. Kao i mnoge slične Web stranice, stranica sa Sl. 5-2 sadrži
naslov i izvesne informacije. Konkretno stranica sadrži spisak predmeta i predavača iz grupe za Embedded
sisteme Elektronskog fakulteta u Nišu. Delovi teksta koji sadrže linkove na druge stranice su obično naglašeni
(podvučeni ili prikazani u odgovarajućoj bolji). Klikom na tekst ˝Internet and Web technologies˝ korisnik može
da dobije dodatne informacije o istoimenom predmetu. Pretraživač pribavlja i prikazuje stranicu na koju ukazuje
izabrani link. Pretraživač pribavlja stranicu bez ikakve pomoći korisnika, a nova stanica može biti uzeta sa istog
računaru sa kojeg je pribavljena i prva ili sa nekog drugog računaru.

(a) (b)
Sl. 5-2 (a) Primer Web stranice; (b) Stranica koja se učitava u pretraživač klikom na link Internet and Web
Technologies.

124
Osnovni model rada Web-a prikazan je na Sl. 5-3. Na Sl. 5-3 vidimo pretraživač koji na klijentskom računaru
prikazuje Web stranicu. Kada korisnik klikne na liniju teksta koja je povezana sa stranicom sa servera abcd.com,
pretraživač sledi link tako što serveru abcd.com šalje poruku kojom od njega traži zahtevanu stranicu. Kada
dobije traženu stranicu, pretraživač je prikazuje. Ako ova nova stranica sadrži link na stranicu sa servera
xyzw.com, klikom na ovaj link, pretraživač će poslati zahtev ovom računaru, i tako do u nedogled.

5.1 Web pretraživač

Razmotrimo sa više detalja rad klijenta sa Sl. 5-3. U osnovi, pretraživač je program koji može da prikazuje Web
stranice i reaguje kada se mišem klikne neki objekat na stranici. Kada je objekat izabran, pretraživač prati
hipervezu pridružen objektu i pribavlja izabranu stranicu. Jasno je da je za implementaciju hiperveze neophodan
način za imenovanje stranica na Web-u. Za imenovanje stranica koriste se šema poznata pod nazivom URL
(uniformni lokator resursa). Tipičan URL je oblika:
http://www.abcd.com/products.html
Detaljnije objašnjenje URL-ova sledi kasnije u ovom poglavlju. Za sada, dovoljno je znati da se URL sastoji iz
tri dela: ime protokola (http), simboličko (DNS) ime računara na kome je stranica locirana (www.abcd.com), i
ime datoteke koja sadrži stranicu (products.html).
Kada korisnik klikne na hipervezu, pretraživač obavlja niz aktivnosti kako bi pribavio traženu stranicu.
Pretpostavimo da je korisnik pretražujući Web pronašao link na Elektronski fakultet u Nišu:
http://www.elfak.ni.ac.yu/home/index.html. Sledi niz koraka koje obavlja pretraživač nakon izbora ovog linka:
1. Pretraživač određuje URL (Na stranici, URL obično nije vidljiv već je ˝sakriven˝ iza teksta hiperveze)
2. Pretraživač se obraća DNS serveru tražeći od njega IP adresu hosta www.elfak.ni.ac.yu.
3. DNS server odgovara sa 160.99.1.1
4. Pretraživač uspostavlja TCP konekciju sa hostom 160.99.1.1 na portu 80.
5. Preko otvorene TCP konekcije, pretraživač šalje zahtev tražeći fajl /home/index.html.
6. Server www.elfak.ni.ac.yu odgovara slanjem fajla /home/index.html.
7. TCP konekcija se zatvara.
8. Pretraživač prikazuje tekst sadržan u falju /home/index.html.
9. Pretraživač pribavlja i prikazuje sve slike iz ovog fajla.

Sl. 5-3 Komponente Web modela.

Da bi bio u mogućnosti da prikaže stranicu, pretraživač mora da razume njen format. Kako bi se obezbedilo da
svi pretraživači razumeju sve Web stranice, Web stranice se pišu u standardnom jeziku koji se zove HTML.
Iako su pretraživači u osnovi HTML interpretatori, većina pretraživača poseduje brojne dodatne funkcije koji
olakšavaju navigaciju na Web-u. Tipično, pretraživači imaju dugme za povratak na prethodnu stranicu, dugme
za prelazak na sledeću stranicu i dugme za direktno učitavanje stranice koju je korisnik označio kao svoju
početnu stranicu. Po pravilu, pretraživači poseduju podršku za bookmark-e, tj. kreiranje liste često posećivanih
stranica. Takođe, učitane stranice se mogu štampati ili snimiti na hard disk. Pored toga, obično su dostupne
brojne opcije za podešavanje izgleda stranice.

125
Pomoćne aplikacije i plug-in-ovi
Ne sadrže sve stranice samo HTML. Stranica se može sastojati od dokumenta formatiranog u PDF formatu,
ikone u GIF formatu, fotografije u JPEG formatu, muzike u MP3 formatu, videa u MPEG formatu, odnosno bilo
kojeg sadržaja u jednom od stotina različitih tipova fajlova i formata. Pretraživač mora biti u stanju da prepozna
i pravilno interpretira sve ove formate. Međutim, umesto neprekidnog proširivanja i prilagođenja interpretatora
sve obimnijem skupu različitih tipova fajlova, kod većine pretraživača koristi se jedno opštije rešenje. Kada
server vrati stranici, on zajedno sa stranicom šalje i dodatne informacije o stranici, kao što je MIME tip stranice.
Stranice tipa text/html se prikazuju direktno, a to važi i za još nekoliko drugih ugrađenih tipova. Međutim, ako
MIME tip stranice nije jedan od ugrađenih, pretraživač konsultuje svoju tabelu MIME tipova u kojoj pronalazi
informaciju o tome kako prikazati stranicu datog tipa. Ova tabela pridružuje MIME tip odgovarajućem
programu za prikazivanje.
Postoje dve mogućnosti: plug-in-ovi (dodaci programu) i pomoćne (halper) aplikacije. Plug-in je programski
modul kojeg pretraživač dobavlja iz jednog posebnog direktorijuma na hard disku i instalira kao svoje
sopstveno, privremeno proširenje (kao što je ilustrovano na Sl. 5-4(a)). Plug-in nije program za sebe, već se
izvršava kao deo pretraživača i na taj način ima pravo pristupa tekućoj stranici i može je procesirati. Nakon što
je plug-in obavio svoj zadatak, on se odstranjuje iz memorije pretraživača.
Klijetski računar Klijetski računar

Pretraživač Pretraživač Pomoćna aplikacija

Pretraživač se izvršava
kao jedan proces
Interfejs pretraživača Program
(koristi ga plug-in) Pretraživača

Interfejs plug-in-a
(koristi ga pretraživač)
plug-in

Proces 1 Proces 2

(a) (b)
Sl. 5-4 Koncept proširenja pretraživača: (a) plug-in; (b) pomoćna aplikacija
Da bi pretraživač i plug-in mogli da se povežu, svi plug-in-ovi predviđeni za određeni pretraživač moraju
posedovati identičan interfejs. Interfejs plug-in-a čini skup procedura koje pretraživač može da poziva. Na
primer, svaki plug-in poseduje proceduru putem koje je pretraživač u mogućnosti da plug-in-u prenese podatke
za procesiranje. Slično, i pretraživač poseduje interfejs koji je dostupan plug-in-ovima, a putem kojeg oni mogu
da zahtevaju izvesne usluge od pretraživača. Na primer, tipična procedura ovog interfejsa je ona putem koje je
plug-in-u omogućeno da ispiše poruku u statusnoj liniji pretraživača ili da zatraži od pretraživača vrednosti
izvesnih parametara. Postojanje unapred definisanih interfejsa omogućava da pretraživač koristi sve plug-in-ove
na identičan način. To praktično znači da pojava novog tipa fajla (tj. formata) zahteva kreiranje odgovarajućeg
plug-in-a, ali ne zahteva bilo kakvu izmenu u pretraživaču.
Međutim, pre nego što može da se koristi, plug-in mora biti instaliran u sistem. Uobičajeni scenario je taj da
korisnik download-uje instalacioni fajl plug-in-a sa Web sajta plug-in-a. Kod Wnidnows sistema, instalacioni
fajl je tipično samo-ekstrahujući zip fajl sa nastavkom .exe. Duplim klikom na zip fajl, pokreće se program
sadržan u zip fajlu. Ovaj program ekstrahuje plug-in iz fajla i kopira ga u direktorijum predviđen za plug-in-ove.
Takođe, program registruje plug-in-ov MIME tip i pridružuje plug-in ovom novom MIME tipu.
Drugi način za proširenje pretraživača je zasnovan na pomoćnim aplikacijama. Pomoćne aplikacije su kompletni
programi koji se izvršavaju nezavisno od pretraživača (Sl. 5-4(b)). Pošto se radi o zasebnom programu,
komunikacija između pretraživača i pomoćne aplikacije se ne ostvaruje putem interfejsa. Obično, pomoćnoj
aplikaciji se prilikom pokretanja prosleđuje ime fajla u koji je smešten sadržaj koji treba obraditi. Pomoćna
aplikacija otvara naznačeni fajl i prikazuje njegov sadržaj. Tipično, pomoćne aplikacije su obimni programi koji
egzistiraju nezavisno od pretraživača, kao što je Adobe Acrobat Reader, program za prikazivanje PDF fajlova,
ili Microsoft Word.
Većina pomoćnih aplikacija koristi MIME tip application. Definisan je veliki broj podtipova. Na primer,
application/pdf za PDF fajlove ili application/msword za Word fajlove. Na ovaj način URL može direktno da
ukazuje na PDF ili Word fajl (npr. http://es.elfak.ni.ac.yu/iw/Materijal/lab1.pdf), a kada korisnik klinke na URL,
Acrobat ili Word se automatski startuje i preuzima na sebe obradu preuzetog fajla. Na ovaj način, pretraživač
može biti konfigurisan za praktično neograničeni broj tipova dokumenata, a da to, slično kao kod plug-in-ova,
ne zahteva bilo kakve promene u samom pretraživaču. Web pretraživač na računaru tipičnog korisnika
konfigurisan je sa tipično više desetina kombinacija tip/podtip, a novi tipovi i podtipovi se obično dodaju uvek
kada se instalira neki novi program. Naime, u Windows sistemu, program koji se instalira na računar ujedno i

126
registruje MIME tipove koje želi da obrađuje. Međutim, ovakav mehanizam vodi do koflikta kada u sistemu
postoji više prikazivača za isti MIME podtip (npr. video/mpg). U takvim situacijama, poslednji program koji je
registrovan prepisuje postojeću asocijaciju ˝MIME tip - pomoćna aplikacija˝ i dati MIME tip/podtip vezuje za
sebe. Zbog toga, instalacija novog programa može kao posledicu imati promenu načina na koji pretraživač
obrađuje postojeće tipove dokumenata.
Pretraživači mogu otvarati i lokalne fajlove (sa hard diska), a ne samo one preuzete sa udaljenih Web servera.
Pošto lokalnim fajlovima nisu pridruženi MIME tipovi, neophodan je način kako će pretraživač odrediti koji
plug-in ili pomoćnu aplikaciju upotrebiti za obradu konkretnog lokalnog fajla. Ovaj problem se prevazilazi na
sledeći način. Pomoćne aplikacije, pored toga što su u sistemu registrovane za obradu MIME tipa, mogu takođe
biti registrovane i za obradu fajlova sa nekim specifičnim nastavkom (ekstenzijom). U tipičnoj konfiguraciji,
dupli klik na fajl nesto.pdf, pokrenuće Acrobat u kome će sadržaj fajla biti prikazan. Slično, dupli klik na fajl
nešto.doc dovešće do otvaranja ovog fajla u programu Word. Pojedini pretraživači koriste MIME tipove,
ekstenzije fajlova, pa čak i informacije uzete iz samog fajla kako bi odredili o kom tipu fajla se radi i pozvali
odgovarajuću pomoćnu aplikaciju ili učitali odgovarajući plug-in.
Slično kao kod asocijacija za MIME tipove, i kod asocijacija za ekstenzije fajlova može doći do konflikta
između programa koji su ˝voljni˝ da obrađuju fajlove sa istim nastavkom. Na primer, u sistemu može postojati
više programa koji su u mogućnosti da procesiraju .mpg fajlove. Tipično, u toku instalacije novog programa,
korisniku se postavlja pitanje da li želi da program kojeg instalira registruje za ponuđene ekstenzije. Ukoliko je
odgovor potvrdan, postojeće asocijacije će biti prepisani novim.
Mogućnost proširenja pretraživača velikim brojem novih tipova značajno olakšava korišćenje Web-a, ali sa
druge strane, može da dovede i do problema koji se tiču sigurnosti. Na primer, kada Internet Explorer pribavlja
fajl sa nastavkom .exe, on zaključuje da se radi o izvršnom programa kome zbog toga nije potreba pomoćna
aplikacija. Normalna akcija u ovakvoj situaciji je pokretanje preuzetog programa. Međutim, to može biti
ozbiljna pretnja sigurnosti sistema jer preuzeti program može sadržati virus. Da bi se predupredile ovakve
situacije, Internet Explorer može biti podešen da ne startuje automatski nepoznate programe ili da konsultuje
korisnika pre nego što pokrene preuzeti program.

5.2 Web server

Kao što je objašnjeno u prethodnoj sekciji, kada korisnik ukuca URL ili klikne na hipervezu, pretraživač
analizira URL i deo između http:// i sledeće kose crte tumači kao DNS ime čiju IP adresu traži od DNS servera.
Sa IP adresom na raspolaganju, pretraživač uspostavlja TCP konekciju na portu 80 odgovarajućeg servera. Kroz
otvorenu konekciju, pretraživač šalje komandu koja sadrži preostali deo URL-a, tj. ime fajla na kontaktiranom
serveru. Server vraća nazad fajl i pretraživač ga prikazuje.
Web server možemo zamisliti kao program koji neprekidno, u petlji, obavlja sledeći niz aktivnosti:
1. Prihvata TCP konekciju od klijenta (pretraživača).
2. Preuzima ime zahtevanog fajla.
3. Pronalazi fajl (na svom hard disku).
4. Šalje fajl klijentu.
5. Zatvara TCP konekciju.
Savremeni Web serveri poseduju brojne dodatne mogućnosti, ali u osnovi, rad Web servera se svodi na
prethodnu proceduru.
Uočimo da svaki zahtev upućen od strane klijenta, podrazumeva pristup hard disku radi uzimanja traženog fajla.
Kao posledica toga, broj zahteva koje Web server može da opsluži u sekundi direktno je određen vremenom
pristupa hard disku. Prosečno vreme pristupa hard diskova velike brzine rada iznosi oko 5 ms, što postavlja
ograničenje na najviše 200 zahteva/s (i manje ako se često čitaju veliki fajlovi). Za Web sajtove sa velikom
brojem istovremenih posetioca 200 zahteva/s je isuviše malo.
Jedno poboljšanje koje se koristi kod svih Web servera podrazumeva da se u operativnoj memoriji ra čunara
kreira keš sa n najskorije korišćenim fajlovima. Pre nego što fajl potraži na disku, server proverava keš. Ako je
fajl u kešu, tada nije potrebno pristupati hard disku jer se fajl može uzet direktno iz memorije. Iako je za
efikasno keširanje potrebno rezervisati relativno veliku količinu operativne memorije kao i dodatno CPU vreme
radi provere da li se fajl nalazi u kešu, ušteda u vremenu obrade jednog zahteva je obično dovoljno velika da
kompenzuje dodatni trošak.

127
Sledeći način za ubrzanje rada Web servera predviđa uvođenje multithreading1. Kod takvog rešenja, server se
sastoji iz jednog front-end (isturenog) pristupna modula koji prihvata sve dolazne zahteve i k pozadinskih
modula koji obrađuju zahteve (Sl. 5-5). Svih k+1 thread-ova pripada istom procesu i imaju pristup kešu. Kada
zahtev stigne, pristupni modul ga prihvata i kreira jedan kratak zapis sa podacima o zahtevu kojeg predaje
jednom od trenutno raspoloživih pozadinskih procesa. Pozadinski modul najpre proverava da je fajl koji traži
prisutan u kešu i ako jeste, u zapis upisuje pokazivač na fajl. Ako fajl nije u kešu, pozadinski modul započinje
operaciju prenosa fajla sa diska u keš (uz eventualno izbacivanje nekih keširanih fajlova, ako u kešu nema
dovoljno prostora). Nakon što je fajl prebačen u keš, zapis sa upisanim pokazivačem se vraća pristupnom
moduli koji preuzima fajl iz keša i prosleđuje ga klijentu koji je uputio zahtev.

Sl. 5-5 Multithread Web server sa pristupnim modulom i pozadinskim modulima.

Prednost opisanog mehanizma je u tome što za vreme dok su jedan ili više pozadinskih modula blokirani
čekajući na završetak operacije čitanja fajla sa diska (i zbog toga ne troše CPU vreme), ostali moduli mogu biti
aktivno upošljeni na obradi novih zahteva. Naravno, da bi se ostvarilo bilo kakvo poboljšanje performansi u
odnosu na single-thread (jednonitni) model, neophodno je da sistem poseduje više od jednog hard diska (kako
bi više diskova bili istovremeno upošljeni). U idealnom slučaju, propusna moć multithread Web severa sa k
pozadinskih modula u sistemu sa k diskova, može biti k puta veća u odnosu na single-thread server i jedan disk.
Savremeni Web serveri, osim vraćanja klijentu traženog fajla, obavljaju i niz dodatnih operacija. Konkretno, u
zavisnosti od tipa pristiglog zahteva, pozadinski modul obavlja neki podskup sledećeg niza aktivnosti:
1. Određivanje imena zahtevane Web stranice iz URL-a.
2. Provera autentičnosti klijenta
3. Provera prava pristupa klijenta.
4. Provera prava pristupa Web stranici.
5. Provera keša.
6. Pribavljanje zahtevane stranice sa diska.
7. Određivanje MIME tipa koji će biti sadržan u odgovoru koji se vraća klijentu.
8. Slanje odgovora klijentu.
9. Kreiranje zapisa u log fajlu.
Korak 1 je neophodan zato što primljeni zahtev ne mora sadržati stvarno ime fajla. Na primer, razmotrimo URL
http://www.elfak.ni.ac.yu, kod kojeg ne postoji ime fajla. U takvim slučajevima, zahtev se odnosi na
podrazumevani fajl (čije je ime obično default.html ili index.html). Takođe, pretraživač može u zahtevu da
navede podrazumevani jezik korisnika (npr. Srpski ili Engleski), a da server izabere verziju stranice na tom
jeziku. Korak 2 podrazumeva proveru identiteta klijenta. Ovaj korak je neophodan za stranice koje nisu
dostupne svim korisnicima. U koraku 3 proverava se da li je datom klijentu dozvoljen pristup traženoj stranici.
U koraku 4 proverava se da li je postoji neko ograničenje koje se odnosi na pristup samoj stranica. Na primer,
pristup stranici može biti dozvoljen samo ako zahtev potiče iz određenih domena (npr. stranici može biti
dostupna samo lokalnim korisnicima). U koracima 5 i 6 vrši se uzimanje stranice. Korak 7 podrazumeva
određivanje MIME tipa stranice (na osnovu ekstenzije fajla, prvih nekoliko reči samog fajla ili na neki drugi

1
Engleska reč thread se prevodi kao nit, a pojam multithreading kao višenitni rad ili rad sa više niti u isto vreme. Procesi i
niti su dva osnovna mehanizma za paralelno (konkurentno) izvršavanje programa. Programi koji imaju potrebu da
istovremeno obavljaju više poslova u isto vreme mogu za svaki takav zadatak da kreiraju jedan proces koji će se izvršavti
uporedo sa drugim procesima. Svaki proces poseduje svoju memoriju za čuvanje svojih podataka. Nit je u osnovi sličan
procesu, s tom razlikom da ne poseduje svoju spostvenu memoriju već je deli sa svim ostalim nitima kreiranim u istom
programu.

128
način). U koraku 9, formira se odgovor koji se vraća klijentu. U koraku 9, formira se zapis o obrađenom zahtevu
i upisuje u jednom posebnu datoteku za vođenje evidencije o pristupima Web severu (tzv. log fajl). Zapis sadrži
informaciju o identitetu klijenta, domenu iz kojeg zahtev poslat, vreme prijema zahteva, ime zahtevane stranice i
td.
U slučajevima kada je broj zahteva koji se upućuje Web serveru u jednoj sekundi veoma veliki, jedan CPU neće
biti u stanju da obradi sve zahteve, bez obzira na broj hard diskova koji se koriste u paraleli. U takvim
situacijama koristi se model farme servera. Kod ovog modela, umesto jednog koristi se više čvorova (računara),
od kojih svaki eventualno poseduje više diskova (Sl. 5-6). Pretpostavka je da svi računari uključeni u farmu
servera poseduju sve Web stranice. Pristupni modul i dalje prihvata zahteve, ali ih sad distribuira različitim
računarima, a ne nitima u okviru jednog računara. Na ovaj način, smanjuje se opterećenje pojedinačnih
računara.

Sl. 5-6 Farma servera

Jedan problem koji se javlja kod farme servera posledica je nepostojanja zajedničkog keša, jer svaki čvor
poseduje svoju sopstvenu memoriju. Naime, može se desiti da je traženi fajl prisutan u kešu nekog čvora, a da je
zahtev prosleđen čvoru kod kojeg se fajl mora pročitati sa diska. U takvoj situaciji, vreme obrade zahteva je
duže nego što je to neophodno. Takođe, nakon obrađenog zahteva isti fajl će se naći u dva keša. Jedan način za
ublažavanje gubitka u performansama zbog nepostojanja zajedničkog keša sastoji se u tome da pristupni modul
vodi evidenciju o tome kome je poslao svaki zahtev, a da naredne zahteve koji odnose na istu stranicu šalje
istom čvoru. Na taj način, pojedinačni čvorovi se ˝specijalizuju˝ za pojedine stranice tako da se ukupni
raspoloživi prostor u kešu ne troši neracionalno za čuvanje svakog fajla u svakom kešu.

5.3 URL
Web se sastoji od ogromne kolekcije dokumenata/stranica povezanih hipervezama, a zapamćenih u fajlovima
koji su locirani na hiljadama servera distribuiranim po globalnom Internetu. Imajući to u vidu, ključna
pretpostavka Web-a je postojanje mehanizma za imenovanje i lako lociranje stranica. Konkretno, pre nego što
izabrana stranica može biti pribavljena i prikazana u pretraživaču, neophodno je odgovoriti na sledeća tri
pitanja:
1. Koje je ime stranice?
2. Gde se stranica nalazi?
3. Kako se stranici može pristupiti?
Odgovor na ova tri pitanja sadržan je u URL-u (Uniform Resource Locator - uniformni lokator resursa) stranice.
Naime, svakoj stranici na Web-u dodeljen je URL koji se koristi kao njeno svetski jedinstveno ime. URL se
sastoji iz tri dela: (a) protokol (ili šema); (b) DNS ime računara na kome je stranica locirana i (a) lokalno ime
koje na jedinstveni način ukazuje na konkretnu stranicu (najčešće ime fajla na hard disku u kome je stranica
zapamćena).
Na primer, URL Web stanica kursa Internet i Web tehnologije na Elektronskom fakultetu u Nišu je
http://es.elfak.ni.ac.yu/iw/iw.htm i sastoji se iz tri dela razdvojenih kosim crtama: protokol (http), DNS ime
hosta (se.elfak.ni.ac.yu) i ime fajla (iw/iw.htm). Deo za ime fajla se sastoji od relativna putanja u odnosu na
podrazumevani Web direktorijum na serveru es.elfak.ni.ac.yu (iw/) i imena samog fajla (iw.htm).
Deo za ime fajla može biti izostavljen iz URL-a (npr. samo http://es.elfak.ni.ac.yu). U tom slučaju, Web server
zahtev se preusmerava na glavnu (podrazumevanu) stranicu Web sajta. Takođe, deo za ime fajla može da sadrži
putanju do direktorijuma, ali ne i samo ime fajla (npr. http://es.elfak.ni.ac.yu/iw/). U takvim slučajevima, Web
server preusmerava zahtev na podrazumevani fajl u tom direktorijumu (npr.
http://es.elfak.ni.ac.yu/iw/index.htm). Kod mnogih Web sajtova uvedene su skraćenice za imena fajlova, koje
počinju znakom ˝~˝. Na primer, ime oblika ~ana/ zamenjuje kompletnu putanju do direktorijuma korisnika ana
na lokalnom računaru.

129
Kao što je već rečeno, za komunikaciju između Web klijenta (pretraživača) i Web servera koristi se TCP
protokol. Pretraživač otvara TCP konekciju sa Web serverom, koja se potom koristi za prenos zahteva od
pretraživača ka serveru, a onda i za prenos odgovora (koji sadrži traženu stranicu) od servera do pretraživa ča.
Međutim, TCP protoko se koristi samo za transport zahteva i odgovora, dok su pravila konverzacije i formati
poruka koje se razmenjuju između pretraživača i Web servera regulisana posebnim aplikacionim protokolom.
Šta više, ne postoji samo jedan, već se za ovu namenu mogu koristi različitih aplikacionih protokola koji su
specijalizovani za prenos specifičnih tipova resursa. Ime protokola koji se koristi za pristup stranici navedeno u
početnom delu URL-a. Delimičan spisak protokola koji se mogu koristiti kao deo URL-a, naveden je u tabeli sa
Sl. 5-7.
Protokol HTTP je osnovni protokola Web-a i koristi se za komunikaciju Web klijenta i Web servera. Više
detalja o ovom protokolu biće dato u sledećoj sekciji.
Protokol FTP, koji se koristi za pristup fajlovima, bio je u širokoj upotrebi i pre nastanka Web-a. I danas na
Internetu postoj veliki broj FTP servera sa kojih zainteresovani korisnici mogu preuzimati najrazličitije fajlove.
Šta više Web je olakšao korišćenje FTP-a, s obzirom da je pristup FTP serveru preko Web pretraživača lakši, od
pristupa putem osnovnog FTP korisničkog interfejsa. Takođe, FTP, za razliku od HTTP, omogućava prenos
fajlova u oba smera, kako od servera do klijenta, tako i od klijenta do servera.
Ime Koristi se za Primer
http Hipertekst (HTML) http://es.elfak.ni.ac.yu
ftp FTP ftp://ftp.elfak.ni.ac.yu
file Lokalni fajl file:// C:\Documents and Settings\Goran\My Documents\Courses\IWT\iwt.doc
news Newsgroup news:comp.os.minix
gopher Gopher gopher://gopher.tc.umn.edu/11/Libraries
mailto slanje elektronske pošte mailto:ppetrovic@elfak.ni.ac.yu
telnet Udaljeni login telnet://www.w3.org:80

Sl. 5-7 Protokoli koji se mogu korisiti u URL-u.

Protokol file omogućava pristup lokalnim fajlovima i prikazivanje njihovog sadržaja u pretraživaču, na isto
način kao Web stranica. Ovaj pristup je sličan FTP-u, ali ne zahteva FTP server. Naravno, primenljiv je samo na
fajlove koji se nalaze na lokalnom hard disku računara.
Sistem vesti USENET, postojao je mnogo pre nastanka Interneta. Danas ga čini oko 30.000 grupa za razmenu
vesti u kojima milioni ljudi diskutuju na najrazličitije teme tako što postavljaju i čitaju članke koji se odnose na
temu konkretne grupe. Protokol news omogućava da se članku iz grupe za razmenu vesti pristupa na isti način
kao i Web stranici.
Gopher je protokol koji se nekada koristio u istoimenom sistemu za pronalaženje informacija na Internetu, koji
se smatra pretečom Web-a. Konceptualno, Gopher je sličan Web-u, ali podržava samo tekst, a ne i slike. Danas
se smatra zastarelim i nije više u upotrebi.
Protokol mailto omogućava korisnicima da putem Web pretraživača šalju elektronsku poštu. Dovoljno je u polje
za unos hiperlinka upisati mailto: i e-mail adresu primaoca. Većina Web pretraživača, u ovakvoj situaciji, otvara
program za slanje elektronske pošte sa popunjenim poljima za e-mail adresu.
Protokol telnet, kao što znamo, koristi se za uspostavljanje konekcije sa udaljenim hostom. Slično kao u slučaju
mailto protokola, upisivanjem telnet: zajedno sa IP adresom udaljenog hosta u polje za unos hipelinka, otvara
program za rad TELNET protokolom.
U zaključku, URL je osmišljen ne samo da omogući korisnicima navigaciju na Web-u, već i korišćenje drugih
mrežnih servisa (FTP, news, Gopher, e-mai i telent) na uniforman način, posredstvom Web pretraživača.

5.4 Cookie
Kod Web-a ne postoji sesija. Pretraživač šalje zahtev, a server vraća nazad traženi fajl. Nakon obavljene
transakcije, server ˝zaboravlja˝ da je ikada komunicirao sa tim konkretnim klijentom. (Kaže se da je Web
stateless (bez stanja) ili bez memorije).
U prvom periodu razvoja Web, kada se Web gotovo isključivo koristio za pribavljanje javno dostupnih
dokumenata, ovakav (stateless) način rada bio je u potpunosti zadovoljavajući. Međutim, sa naglim širenjem
Web i porastom njegove popularnosti, model zasnovan na nezavisnim transakcijama više nije mogao da
zadovolji sve potrebe novih primena. Na primer, neki Web sajtovi zahtevaju od korisnika da se registruju pre
nego što im se dozvoli korišćenje dostupnih usluga sajta. Postavlja se pitanje, kako će Web server znati da li

130
zahtev potiče od registrovanog ili neregistrovanog korisnika, pa da na osnovu toga dozvoli ili zabrani pristup
nekim svojim stranicama. Drugi primer su Web portali (npr. Yahoo) kod kojih svaki registrovani korisnik može
da konfiguriše sadržaj početne stranice birajući informacije koje će biti prikazane uvek kada učita stranicu (npr.
vremenska prognoza, kurs, sportski rezultati...). Međutim, kako će Web server znati kako da prilagodi stranicu
korisniku, ako ne zna koji korisnik je uputio zahtev. Sličan problem se javlja kod Web sajtova elektronskih
prodavnica koje omogućavaju korisniku da pregleda ponuđene artikle, izabere one koje želi da kupi i stavi ih u
elektronsku korpu i na kraju kupovine plati račun kreditnom karticom.
Na prvi pogled, čini se da je dovoljno da server vodi evidenciju o IP adresama sa kojih se upućuju zahtevi za
stranicama. Međutim, ova ideja nije dobra. Pre svega, mnogi korisnici koriste računare koje dele sa drugim
korisnicima. IP adrese može da identifikuje računara, ali ne i korisnika koji trenutno radi na računaru. Drugo,
mnogi korisnici (pre svega kućni) Internetu pristupaju putem provajdera Internet usluga (npr. pomoću modema)
od kojih, nakon konektovanja, dobijaju IP adresu na privremeno korišćenje, koja ne mora biti ista kao IP adresa
koju su koristili prilikom prethodnog konektovanja.
Da bi se opisani problem rešio, razvijena je tehnika pod nazivom cookies (kolačići). U nastavku će biti objašnjen
način kreiranja, čuvanja i korišćenja cookie-a.
Kreiranje i čuvanje Cookie-a.
Iako kreiranje i čuvanje cookie-a zavisi od konkretne realizacije, osnovni princip je uvek isti. Cookie je mali fajl
(ne veći od 4KB) ili string koji se pridodaje svakom zahtevu ili odzivu koji se razmenjuju između klijenta i
servera. Cookie pravi server i, zajedno sa traženom Web stranicom, šalje ga klijentu. Cookie sadrži ime domena
servera zajedno sa podacima koje je server prikupio od klijenta (korisničko ime, registracioni broj) kao i dodatne
podatke koje imaju značaj u konkretnoj situaciji. Na strani klijenta, pretraživač automatski izdvaja cookie iz
primljenog odziva i smešta ga na hard disk u direktorijum predviđen za čuvanje cookie-a. Kada klijent šalje
zahtev serveru, pretraživač proverava da li u direktorijum za cookie, postoji cookie kojeg je poslao dati server.
Ako takav cookie postoji, pretraživač ga pridodaje zahevu i šale serveru. Server, kada primi zahtev, zna da se
radi o starom, prepoznatljivom korisniku, a ne o nekom novom.
Dakle, cookie pravi i koristi (konzumira) server. Pretraživač čuva cookie do sledećeg obraćanja serveru, ali
nikada ne čita sadržaj cookie-a, niti njegov sadržaj otkriva korisniku.
Korišćenje cookie-a
Jedan mogući scenario korišćenja cookie-ja je sledeći. Prilikom prve posete sajtu za on-line prodaju knjiga, od
korisnika se zahteva da izabere jednu ili više oblasti za koje je zainteresovan (tehnika, beletristika, ).. Nakon
obavljene registracije server kreira cookie sa sadržajem oblast1=tehnika, oblast2=naucna_fantastika, ..., i šalje
ga klijentu. Pretraživač izdvaja cookie iz odgovora i smešta ga u odgovarajući direktorijum. Kad god kasnije
korisnik pristupi ovom sajtu, pretraživač zajedno sa zahtevom šalje serveru i odgovarajući cookie. Na osnovu
sadržaja cookie-a, server saznaje ime korisnika i koristi ga kao ključ za pretragu baze podataka iz koje čita i
ostale podatke tog korisnika. Na osnovu ovih podataka, Web server kreira, i vraća nazad stranicu koja sadrži
spisak novih knjiga iz oblasti za koje je korisnik zainteresovan.
Još jedan tipičan scenari okorišćenja cookie-a srećemo kod elektronskih prodavnica. Kada klijent (kupac)
izabere artikal i stavi ga u korpu, kreira se cookie koji sadrži informacije o artiklu (npr. cena i količina) i šalje
pretraživaču. Ako klijent izabere drugi artikl, cookie se ažurira novim podacima. Kada klijent završi kupovinu i
želi da se odjavi, server preuzima poslednji cookie i izračunava ukpunu cenu.
Format cookie-a
Cookie može sadržati do pet polja:
(Domain, Path, Content, Expires, Secure)
Domain (Domen). Ovo polje sadrži ime domena iz koga cookie potiče (domen servera).
Path (putanja). Ovo polje sadrži putanju u strukturi direktorijuma servera koja ukazuje na deo njegovog stabla
direktorijuma unutar kojeg sve stranice mogu koristiti cookie. Kosa crta ˝/˝ u ovom polju znači celokupno
stablo.
Content (sadržaj). Sadržaj ovog polja je oblika ime = vrednost. Ime i vrednost mogu biti bilo koja informacija
koju server želi da uvrsti u cookie.
Expires (rok važenja). Ovo polje sadrži datum i vreme kada prestaje važnost cookie-ja. Ako ovo polje ne postoji,
pretraživač uništava cookie prilikom svog zatvaranja. Ovakav cookie se zove neperzistentni cookie. Ukoliko su

131
datum i vreme sadržani u cookie-ju, za cookie se kaže da je perzistentan i da će ostati na klijentu sve do isteka
navedenog roka.
Secure (Sigurnost). Ako je postavljeno na Yes, nalaže pretraživaču da cookie može da se vrati serveru samo u
šifrovanom obliku. Ova mogućnost se koristi kod aplikacija za elektronsko poslovanje u bankovnim
transakcijama i drugim aplikacijama koje zahtevaju zaštitu informacija.

5.5 Statički Web dokumenti

Osnova Web-a jeste prenos Web stranica od servera do klijenta. U svom najjednostavnijem obliku, Web stranice
su statičke, tj. datoteke smeštene na nekom serveru koje ˝čekaju˝ da budu zatražene i koje se, bez bilo kakvih
izmena, dostavljaju klijentu. Posmatrano na ovaj način, i za sadržaje kakvi su video i audio se može reći da
predstavljaju statičke Web stranice jer se preuzimaju kao datoteke.
HTML
Web stranice se pišu u jeziku koji se zove HTML (HyperText Markap Language – hipertekstualni markerski
jezik). Pomoću HTML-a projektant (dizajner) Web stranica može da kreira Web stranice koje sadrže tekst,
grafiku i hiperveze ka drugim Web stranicama. Pojam markap language (markerski jezik) znači da HTML služi
za opis načina na koji su dokumenti formatirani, odnosno kako će biti prikazani u Web pretraživaču. HTML
definiše skup komandi za formatiranje koje, ugrađene u prvobitni tekst dokumenta, daju uputstva za
prikazivanje sadržaja dokumenta.
Komande se nazivaju oznakama ili tagovima (od eng. tag) i uokvirene su znakovima manje od i veće od. Neki
tagovi se javljaju u parovima, a odnose se na sve stavke koje se nalaze između uparenih oznaka. Na primer, u
HTML-u, <b> znači početak, a </b> kraj teksta napisanog masnim slovima.
Svaka Web stranica se sastoji iz dva dela: zaglavlje i telo. Oba ova dela uokvirena su tagovima <html> i
</html>. Zaglavlje počinje tagom <head>, a završava se tagom </head>, dok telo počinje tagom <body> i
završava se tagom </body>. Tekst unutar taga se naziva direktivom. Većina HTML tagova ima identičan format;
koriste <nešto> da označe početak nečega i </nešto> da označe njegov kraj. Većina pretraživača poseduje
opciju, obično nazvanu ˝View Source˝. Izborom ove opcije, prikazuje se izvorna verzija tekuće HTML stranice,
umesto njenog formatiranog izgleda.
Tagovi se mogu pisati bilo malim bilo velikim slovima. Tako, <head> i <HEAD> znače isto. Formatiranje
samog HTML dokumenta je irelevantno. HTML parser (deo pretraživača koji interpretira HTML) ignoriše
dodatne blanko znake (razmake) i prelaske u novi red. To znači da se razmaci mogu slobodno koristiti kako bi
se HTML dokument učinio čitljivijim. Međutim, prazne linije, s obzirom da se ignorišu, se ne mogu koristiti za
razdvajanje paragrafa, već se za tu namenu moraju koristiti posebni tagovi.
Pojedini tagovi imaju parametre, koji se nazivaju atributima. Na primer,
<img src=”abc” alt=”slika”>
je tag, <img>, sa parametrima src i alt. Vrednost parametra src je postavljena na abc, a parametra alt na slika.
Za svaki tag, postoji definisani skup dozvoljenih parametara. S obzirom da su parametri imenovani, redosled
navođenja parametara u tagu nije od značaja.
Za pisanje specijalnih karaktera (koji ne pripadaju ASCII skupu karaktera), u HTML se koristi posebna sintaksa.
Specijalni znak počinje znakom ˝&˝, а završava se znakom ˝;˝. Na primer, &nbsp; označava blanko znak,
&egrave; označava è, a &egrave; é. Za predstavljanje znakova ˝<˝, ˝>˝ i ˝&˝, koji imaju posebno značenje u
HTML-u, koristi se: &lt, &gt i &amp, respektivno.
Glavna stavka u zaglavlju HTML dokumenta je naslov, omeđen tagovima <title> i </title>. Naslov se ne
prikazuju na stranici, mada se kod nekih pretraživača prikazuje kao naslov prozora stranice.
U tabeli sa Sl. 5-8 navedeni su tagovi definisani HTML jezikom. Za ispisivanje naslova koristi se tag <h n>, gde
je n ceo iz opsega 1 - 6. Tako, tag <h1> označava glavni naslov, a <h6> naslov namanje važnosti. Oblik u
kojem će naslovi biti prikazani, shodno nihovom nivou, zavisi od pretraživača. Tipično, tekst naslova višeg
nivoa (sa manjom brojnom vrednošću) ispisuju se većim i ˝težim˝ fontom. Takođe, pretraživač može da koristi
različite boje za prikaz naslova različitih nivo. Obično, naslovi označeni tagom <h1> ispisuje se većim i masnim
slovima i sa barem jednom praznom linijom iznad i ispod naslova. Naslovi omeđeni tagom <h2> ispisuju se
manim fontom sa manjim razmakom iznad i ispod teksta naslova, i td.
Tagovi <b> i <i> se koriste za označavanje teksta koji treba ispisati masnim (bold) i iskošenim (italic) slovima,
respektivno.

132
 Tag Opis
<html> ... </html> Deklariše da je Web stranica pisana u HTML-u
<head> ... </head> Omeđuje zaglavlje stranice
<title> ... </title> Definiše naslov stranice (ne prikazuje se na stranici)
<body> ... </body> Omeđuje telo stranice
<h n> ... </h n> Omeđuje naslov nivoa n
<b> ... </b> Postavlja ... u bold
<i> ... </i> Postavlja ... u italik
<center> ... </center> Horizontalno centrira ... na stranici
<ul> ... </ul> Omeđuje neuređenu listu
<ol> ... </ol> Omeđuje uređenu listu
<il> ... </il> Omeđuje jednu stavku uređene liste
<br> Umeće novi red (prelom linije)
<p> Započinje novi paragraf
<hr> Umeće horizonalnu liniju po celoj dužini stranice
<img src = “...“> Prikazuje sliku
<a href=“...“> ... </a> Definiše hipervezu
Sl. 5-8 Spisak najznačajnijih HTML tagova.
HTML pruža više različitih načina za kreiranje listi, uključujući i ugnježdene liste. Liste se započinju tagom
<ul> ili <ol>, a tag <il> se, u oba slučaja, koristi za označavanje početka stavki u listi. Tag <ul> označava
početak nenumerisane liste. Pojedinačne stavke ovakve liste (omeđene tagovima <il> i </il>) prikazuju se sa
znakom • na početku. Za numerisane liste (omeđene tagom <ol>), umesto simbolom •, stavke se prilikom
ispisivanja u pretraživaču označavaju rednim brojevima.
Tagovi <br>, <p> i <hr> se koriste za ragraničenje delova teksta. Tag <br> lomi liniju teksta (prelazak u novi
red). Tag <p> označava početak novog paragrafa, što može značiti umetanje jedne prazne linije ili uvlačenje
prve linije novog paragrafa. Konačno, tag <hr> prekida tekuću liniju teksta i u novoj liniji crta horizontalnu
liniju celom dužinom stranice.
Osim teksta, Web stranice pisane u HTML-u mogu sadržati i slike. Za umetanje slika na tekuću poziciju ne
stranici koristi se tag <img>. Ovaj tag može imati više parametara. Parametar src sadrži URL slike. HTML ne
propisuje dozvoljene grafičke formate slika. U praksi, svi pretraživači podržavaju grafičke formate GIF i JPEG.
Stranica može sadržati i sliku u nekom drugom formatu (npr. BMP), da li će takva slika biti i prikazana u
pretraživaču zavisi od sposobnosti pretraživača da barata konkretnim formatom. Parametar taga <img>, align,
definiše poravnanje slike u odnosu na tekst (top, middle, bottom). Parametar alt omogućava da se umesto slike
može prikazati tekst, ukoliko korisnik zabrani pretraživaču da prikazuje slike. Konačno, parametar ismap,
ukazuje da se radi o aktivnoj slici, tj. slici mapi.
Za označavanje hiperveza koristi se tagovi <a> i </a>. Slično tagu <img>, tag <a> može sadržati više
parametara, kao što su href (za URL) i name (za ime hiperveze). Tekst uokviren tagovima <a> i </a> se
prikazuje, a klikom na tekst pretraživač prelazi na novu stranicu čiji je URL naveden u parametru href. Takođe,
dozvoljeno je umesto teksta navesti sliku (tag <img>). U tom slučaju, hiperveza se aktivira klikom na sliku.
Na primer, razmotrimo sledeći fragment HTML teksta:
<a href="http://www.nasa.gov"> NASA's home page </a>
koji se u pretraživaču prikazuje kao:
NASA's home page
Ako korisnik klikne na ovaj tekst, pretraživač će pribaviti i prikazati stranicu čiji je URL http://www.nasa.gov.
U sledećem primeru:
<a href="http://www.nasa.gov"> <img src="shuttle.gif" alt="NASA"> </a>
na stranici će biti prikazana slika (npr. slika spejs šatla). Klik na ovu sliku imaće isti efekat kao klik na
podvučeni tekst iz prethodnog primera. Ukoliko korisnik zabrani prikazivanje slika u pretraživaču, na mestu na
stranici, gde bi inače bila prikazana slika, biće ispisan tekst NASA.
Parametar name tag <a> se koristi za hiperveze koje ukazuju na pojedine sekcije same stranice. Na primer, na
početku mnogih Web stranica nalazi se sadržaj stranice (slično sadržaju knjige). Klikom na stavku iz sadržaja,
korisnik ima mogućnost da se brzo pozicionira na odgovarajuću sekciju stranice.

133
HTML je jezik koji evoluira. Starije verzije HTML-a, 1.0 i 2.0, nisu predviđale tabele. Podrška za tabele
uvedena je u veziji HTML 3.0. HTML tabela se sastoji iz jedne ili više vrsta od kojih svaka sadrži jednu ili više
ćelija. Ćelije mogu sadržati tekst, slike, ikone, fotografije, pa čak i cele tabele. Ćelije se mogu spajati u veće
ćelije koje zauzimaju više kolona i/ili vrsta. Iako autor stranice ima mogućnost izvesne kontrole nad izgledom
tabele (definiše poravnanje sadržaja ćelija, stil okvira tabele, margine teksta u ćeliji), konačni izgled tabele
zavisi od načina na koji pretraživač interpretira HTML opis tabele.
Na Sl. 5-9(a) je dat primer HTML-a koji ilustruje osnovne karakteristike HTML tabela, a na Sl. 5-9(b)
odgovarajući prikaz u pretraživaču. Kao što se može videti celokupna tabela je omeđena tagovima <table> i
</table>. Tag <caption> sadrži tekst naslova tabele. Svaka vrsta počinje tagom <tr>, dok su pojedinačne ćelije
označene tagom <th> ili <td>. Ćelije označene tagom <th> (Table Header) odgovaraju nslovnim ćelijama
kolona, dok one označne tagom <td> (TableData) predstavljaju unutrašnje ćelije tabele, tj. one koje sadrže
podatke.
Prilikom kreiranja tabela dozvoljeno je koristiti brojne atribute, kako bi se definisalo horizonalno i vertikalno
poravnanje ćelija, poravnanje unutar ćelije, način crtanja okvira, grupisanje ćelija i td.
<html>
<head><title> Primer stranice sa tabelom
</title></head>
<body>
<table border=1 rules=all>
<caption> Razlike izmedju verzija HTML-a </caption>
<col align = left>
<col align = center>
<col align = center>
<col align = center>
<col align = center>
<tr><th>Stavka<th>HTML 1.0<th>HTML 2.0<th>HTML 3.0
<th>HTML 4.0</tr>
<tr><th>Hiperveze <td> x <td> x <td> x <td> x </tr>
<tr><th>Slike <td> x <td> x <td> x <td> x </tr>
<tr><th>Liste <td> x <td> x <td> x <td> x </tr>
<tr><th>Aktivne mape i
slike<td>&nbsp<td>x<td>x<td>x</tr>
<tr><th>Forme<td> &nbsp <td> x <td> x <td> x </tr>
<tr><th>Formule<td> &nbsp <td> &nbsp <td> x <td> x
</tr>
<tr><th>Tulbarovi<td> &nbsp <td>&nbsp<td> x <td> x
</tr>
<tr><th>Tabele<td>&nbsp<td>&nbsp<td>x<td>x</tr>
<tr><th>Ugradnja
objekata<td>&nbsp<td>&nbsp<td>&nbsp<td>x </tr>
<tr><th>Skripte<td>&nbsp<td>&nbsp<td>&nbsp<td>x</tr>
</table>
</body>
</html>
(a) (b)
Sl. 5-9 (a) HTML tabela; (b) prikaz tabele.
U verziji HTML 4.0 uvedene u dodatne mogućnosti, kao što su podrška za olakšano korišćenje Web stranica
osobama sa hendikepom, ugradnja objekata (opštenje taga <img> tako da i druge vrste objekata mogu biti
sadržani na stranici), podrška za skript jezike (koja omogućava kreiranje dinamičkog sadržaja stranice) i druge.
U slučajevima kada je Web sajt složen i sadrži veliki broj stranica koje kreiraju različiti autori koji rade za istu
kompaniju, poželjno je da postoji način za unifikaciju izgleda (stila) različitih stranica. Ovaj problem se može
rešiti korišćenjem style sheet-ova. Stranice koje se oslanjaju na pridruženi style sheet ne moraju više da sadrže
isključivo tzv. fizičke stilove (kao što su npr. <b> za bold ili <i> za italic). Umesto toga, autori koriste logičke
stilove definisane u style sheet-u; npr. <nr> (za normalan tekst), <em> (za naglašen tekst), <strong> (za jako
naglašen tekst). Način prevođenja logičkih stilova definisan je u style sheet-u koji se referencira na početku
svake stranice. Na ovaj način, sve stranice imaće identičan stil, a da bi se promenio stil svih stranica dovoljno je
promeniti definiciju stila u style sheet-u. Na primer, u style sheet-u može biti definisano da se logički stil
<strong> prikazuje u plavoj boji u italic fontu veličine 14-point-a. Ako je potrebo promeniti stil tako da se tekst
označen sa <strong> prikazuje u ružičastoj boji, bold fontom veličine 18, dovoljno je izmeniti samo jednu
definiciju u style sheet-u i automatski, promena će biti vidljiva na svim stranicama, svuda tamo gde se koristi
ovaj stil.

134
Forme
HTML 1.0 je omogućavo samo jednosmernu komunikaciju. Korisnik je mogao da dobije traženu stranicu od
servera, ali je teško mogao da vrati nazad povratnu informaciju. Kako je sve veći broj komercijalnih
organizacija počinjalo da korisni Web, tako su rasli zahtevi za dvosmernim saobraćajem. Na primer, javila se
potreba za popunjavanjem narudžbenica preko Web-a, registracijom korisnika, postavljanjem upita za
predraživanje baze podataka i td.
Ovi i slični zahtevi doveli su do uvođenja formi, već u verziji HTML 2.0. Forme sadrže box polja (ili dugmad)
koja korisnik može da popuni traženim podacima ili učini izbor između više ponuđenih opcija i unetu
informaciju vrati vlasniku stranice. Za ovu namenu koristi se tag <input>. Ovaj tag poseduje veći broj
parametara uz pomoć kojih se reguliše veličina, priroda i upotreba polja. Nejčešće se koriste polja za unos
teksta, kvadrati za štikliranje, aktivne mape i dugme Submit. Na Sl. 5-10(a) je dat primer HTML koda koji
ilustruje osnovne mogućnosti formi. Odgovarajući prikaz u pretraživaču dat je na Sl. 5-10(b).
Forma je uokvirena tagovima <form> i </form>. Obuhvaćeni tekst, koji nije deo nekog taga, se prikazuje kao i
takst sadržan u telu stranice. Pri tome, dozvoljeno je korišćenje svih uobičajenih tagova (npr. <b>). Forma sa Sl.
5-10(a) sadrži tri vrste <input> box polja: polja za unos teksta, kvadrate za štikliranje i nekoliko radio dugmadi.
Prvo polje u formi definiše polje za unos teksta veličine (size) 46 karaktera predviđeno za upis imena korisnika.
Uneti string se pamti u promenljivoj kupac radi kasnije obrade. Tag <p> nalaže pretraživaču da tekst i box polja
koja slede prikaže u novoj linij. Uz pomoć tag <p> i sličnih, autor forme može da kontroliše raspored polja i
teksta na formi.
Sledeća linija forme definiše polja za unos adrese i mesta stanovanja kupca. Prvo polje je veličine 40, a drugo 14
karaktera. Naredna linija predviđena je za unos podataka o kreditnoj kartici koju kupac koristi za plaćanje. Za
broj kartice i datum kada ističe važenje kartice koriste se polja za unos teksta, dok se tip kartice bira pomoću
novog tipa polja, tzv. radio dugmeta. Radio dugmad se koriste kada treba obaviti izbor između dve ili više
alternativnih opcija. U pretraživaču, radio dugme se prikazuju na način koji omogućava korisniku da klikom na
dugme može da izabere ili poništi izbor odgovarajuće opcije. Klik na jedno dugme isključuje sva ostala iz iste
grupe. Radio dugmad se koriste i za izbor tipa poveza. Sva radio dugmad sa istim imenom pripadaju istoj grupi.
Tako, sva rado dugmad za izbor tipa kreditne kartce imaju ime ´cc´, a ona za tip poveza ime ´povez´. Parametar
value (vrednost) se koristi za indikaciju koje radio dugme je izabrano. Na primer, zavisno od toga koji tip
kreditne kartice je izabran, promenljiva cc dobiće jednu od dve vrednosti ˝mastercard˝ ili ˝visacard˝.
Posle grupe radio dugmadi za izbor poveza, sledi opcija za isporuku brzom poštom, predstavljena tzv.
kvadratom za štikliranje (checkbox). Kvadrat za štikliranje može biti uključen ili isključen. Za razliku od radio
dugadi gde samo jedno dugme iz grupe može biti izabrano, svaki kvadrat za štikliranje se postavljaju nezavisno
od ostlih.
Polje za unos teksta, radio dugme i kvadrat za štikliranje su tri tipa taga <input>. Tip se navodi kao vrednost
parametra type, npr. type=radio ili type=checkbox. Polje za unos teksta je podrazumevani tip i zbog toga nije
nepohodo navoditi parametar type. Postoje još dva tipa taga <input>, tipovi password i textarea. Tip password,
koji se obično koristi za unos lozinke, identičan je polju za unost teksta, osim što se ne ispisuju karakteri koji se
kucaju, već se svaki uneti karakter predstavlja istim znakom, npr. *. Tip textarea je takođe varijanta polja za
unos teksta, koja, za razliku od osnovnog tipa može sadržati više linija teksta.
<html>
<head><title> FORMA ZA NARUCIVANJE KNJIZARE CENTAR</title></head>
<body>
<h1> Forma za narucivanje knjiga </h1>
<form ACTION="http://www.centar-knjiga.com/cgi-bin/narudzba" method=POST>
<p> Ime <input name="kupac" size=46></p>
<p> Ulica<input name="ulica" size=20> Mesto <input name="mesto" size=14></p>
<p> Br. kreditne kartice <input name="cardno" size=10>
Istice <input name="istice" size=4>
MASTER <input name="cc" type=radio value="mastercard">
VISA <input name="cc" type=radio value="visacard"></p>
<p>Narucujem knjigu <input name="knjiga" size=46></p>
<p>Povez Tvrdi <input name="povez" type=radio value="tvrdi">
Meki <input name="povez" type=radio value="meki">
Dostava preko brze poste <input name="express" type=checkbox></p>
<p><input type=submit value="narucivanje"></p>
Hvala na poverenju.
</form>
</body>
</html>
(a)

135
 (b)
Sl. 5-10 (a) HTML kod forme; (b) prikaz forme
Poslednje <input> polje na formi sa slike je Submit dugme sa natpisom ˝narucivanje˝. Klikom na ovo dugme,
informacije unete na formu se šalju nazad na server od kojeg je Web stranica dobijena. Submit dugme se
definiše vrednošću submit parametra type. Vrednost parametra value predstavlja tekst koji se prikazuje kao
natpis dugmeta. Kada korisnik klikne na Submit dugme, pretraživač pakuje informacije prikuljene sa forme u
jednu dugačku liniju i šalje je serveru na obradu. Znak & se koristi za razdvajanje polja, a znak + predstavlja
razmak. Na primer, za formu sa slike, linija koja se šalje serveru može biti oblika:
kupac=Petar+Petrovic&ulica=Beogradska+14&mesto=Nis&cardno=1234567890&istice=9/07&cc
=mastercard&povez=tvrdi&express=on
Na serveru je da protumači dobijeni string i preduzme odgovarajuće akcije.
XML i XSL
HTML, sa ili bez formi, ne bavi se struktuiranjem podataka na Web stranici niti razdvaja sadržaj od
formatiranja. Sa pojavom naprednih Web aplikacija, kao što su aplikacije za elektronsku trgovinu (e-commerce),
javila se potreba za struktuiranjem Web stranica i jasnim razdvajanjem sadržaja od načina prikazivanja
(formatiranja). Na primer, zamislimo program koji pretražuje Web u potrazi za najjeftinijom knjigom ili CD-
om. Jedan takav program bi morao da analizira veliki broj Web stranica raznih sajtova za elektronsku trgovinu i
da iz svake izdvoji naslove i cene knjiga ili CD-ova. Ako su Web stranice napisane u HTML-u, program će
veoma teško moći da zaključi gde se na stranici nalazi tražena informacija.
Iz ovog i sličnih razloga, organizacija W3C, koja se bavi razvojem Web-a i standardizacijom protokola za Web,
razvila je poboljšanje HTML-a koje omogućava struktuiranje Web stranice na način koji olakšava automatsku
obradu njenog sadržaja. Konkretno, uvedena su dva nova jezika. Prvi, XML (eXtesible Markup Language)
opisuje Web sadržaj na struktuirani način, dok drugi, XSL (eXtensible Style Language) opisuje formatiranje Web
stranice nezavisno od njenog sadržaja. S obzirom da se radi o obimnim i složenim jezicima, u nastavku će biti
izložena samo njihova osnovna ideja.
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="book_list.xsl"?>
<book_list>
<book>
<title> Computer Networks, 4/e </title>
<author> Andrew S. Tanenbaum </author>
<year> 2001 </year>
</book>
<book>
<title> Internetworking with TCP/IP, Vol I</title>
<author> Douglas E. Comer </author>
<year> 2000 </year>
</book>
<book>
<title> Data Communications and Networking</title>
<author> Behrouz A. Forouzan, 2/e </author>
<year> 2001 </year>
</book>
</book_list>
Sl. 5-11 Primer Web stranice u XML-u.

136
Razmotrimo XML dokument sa Sl. 5-11. Dokument opisuje strukturu nazvanu book_list, koja predstavlja spisak
knjiga. Za svaku knjigu u strukturi postoje tri polja: naslov (title), autor (author) i godina izdavanja (year).
Napomenimo da XML omogućava kreiranje mnogo složenijih struktura od one prikazane na Sl. 5-11. Na primer,
dozvoljeno je da struktura sadrži višestruka polja (npr. više od jednog autora knjige), opciona polja (npr. naslov
pratećeg CD-ROM-a), alternativna polja (npr. URL knjižare, ako knjiga nije rasprodata ili URL sajta za
aukcijsku prodaju, ako je knjiga rasprodata). S obzirom da XML tagovi ukazuju na smisao informacije koje
sadrže, XML dokument se može lako pretraživati, npr. da bi se pronašle sve knjige datog autora.
U primeru sa Sl. 5-11, sadržaj svakog od tri polja, autor, naslov i godina, se tretira kao nedeljiva informacija.
Međutim, ako je potrebno, recimo radi preciznije pretrage, polja je dozvoljeno razložiti na podpolja. Na primer,
polje za ime autora, se može podeliti na dva podpolja, jedno za ime a drugo za prezime autora:
<author>
<first_name> Andrew </first_name>
<last_name> Tanenbaum </last_name>
</author>
Uvedena podela polja author omogućava pretraživanje samo po imenu ili samo po prezimenu autora. U opštem
slučaju dubina podele može biti proizvoljna.
Dokument sa Sl. 5-11 sadrži spisak od tri knjige. Međutim, sam dokument na govori ništa o tome kako jednu
ovakvu Web stranicu treba prikazati u pretraživaču. Da bi se definisao način formatiranja dokumenta,
neophodan je još jedan fajl, book_list.xsl, napisan u jeziku XSL, koji će ˝objasniti˝ pretraživaču kako da prikaže
podatke iz XML dokumenta.
Na Sl. 5-12 je prikazan primer XSL fajla za formatiranje XML dokumenta sa Sl. 5-11. Nakon neophodnih
deklaracija, koje između ostalog sadrže URL na XSL standarda, slede tagovi <html> i <body>, koji, slično kao
kod HTML-a dokumenta, definišu početak Web stranice. Zatim sledi definicija tabele, koja sadrži naslove i tri
kolone.
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<th> Title </th>
<th> Author </th>
<th> Year </th>
</tr>
<xsl:for-each select="book_list/book">
<tr>
<td><xsl:value-of select="title"/></td>
<td><xsl:value-of select="author"/></td>
<td><xsl:value-of select="year"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Sl. 5-12 Primer XSL fajla.
U primeru sa Sl. 5-12, sekcija:
<xsl:for-each select="book_list/book">
<tr>
<td><xsl:value-of select=”title”/></td>
<td><xsl:value-of select=”author”/></td>
<td><xsl:value-of select=”year”/></td>
</tr>
</xsl:for-each>

137
je analogna for naredbi iz C-a, gde prva linija odgovara zaglavlju, pet unutrašnjih linija telu, a poslednja oznaci
za kraj for petlje. Kada pretraživač, koji interpretira dati XSL fajl, on prolazi jedanput kroz petlju za svaku
knjigu iz pridruženog XML dokumenta i u svakom prolasku generiše pet linija oblika: <tr> naslov, autor,
godina </tr>. Drugim rečima, pretraživač generiše HTML tabelu popunjenu podacima o svim knjigama iz XML
dokumenta. Krajnji rezultat je isti kao da se prikazuje HTML stranica koja sadrži tabelu popunjenu podacima o
tri knjige. Međutim, XML/XSL predstavlja daleko fleksibilnije rešenje. Na primer, ako je potrebno u spisak
uvrstiti nove knjige, dovoljno je u XML dokument dopisati nova <book> polja; XSL ostaje neizmenjen. (U
HTML varijanti, bilo bi neophodno proširiti definiciju tabele novim vrstama). Sa druge strane, ako treba
promeniti način prikazivanja potrebno je modifikovati XSL fajl, ali ne i XML dokument. Drugo, program koji
na Web stranici traži informacije o nekoj knjizi, analizira XML dokument. S obzirom da XML dokument sadrži
tagove koji ukazuju na smisao podataka i nije opterećen tagovima za formatiranje, njega je mnogo jednostavnije
analizirati od odgovarajućeg HTML dokumenta.
Treba napomenuti da iako XSL fajl sadrži neku vrstu programskih konstrukcija, Web stranice napisane u XML i
XSL su i dalje statičke. Naima, kao i HTML, XSL daje samo instrukcije Web pretraživaču kako da prikaže
stranicu. Naravno, upotreba XML/XSL-a podrazumeva da je pretraživač u stanju da interpretira XML i XSL, što
je danas slučaj sa gotovo svim pretraživačima.

5.6 Dinamički i aktivni Web dokumenti

Model Web-a opisan u prethodnim sekcijama podrazumeva da klijent šalje serveru ime fajla, a server odgovara
slanjem klijentu sadržaja traženog fajla. U početnom periodu razvoja Web-a celokupan sadržaj dostupan na
Web-u bio je statički (sadržan u fajlovima koji se bez bilo kakve modifikacije transportuju do klijenta).
Međutim, u novije vreme, sadržaj koji se može preuzeti sa Web-a postaje u sve većoj meri dinamički, tj. ne
postoji u unapred definisanom obliku, već se kreira na zahtev. Generisanje sadržaja Web stranica može se
obaviti bilo na strani servera bilo na strani klijenta. U prvom slučaju, tzv. dinamički dokumenti, Web server, po
prijemu zahteva, pokreće odgovarajući aplikacioni program koji kreira dinamički dokument, a klijentu vraća
izlaz programa (Sl. 5-13(a)). Drugim rečima, kao odgovor na svaki zahtev klijenta, na strani severa se kreira
nova verzija HTML dokumenta. Krajnje jednostavan primer dinamičkog dokumenta je preuzimanje tekućeg
vremena i datuma od servera. Vreme i datum su primer dinamičke (promenljive) informacije koja se menja iz
momenta u moment. Na primer, klijent može da zahteva od servera da izvrši program koji čita sistemsko vreme
serverskog računara. Program konvertuje informaciju o vremenu u tekst, formatira tekst pomoću HTML tagova
i generisani HTML dokument predaje Web serveru koji ga vraća nazad klijentu.

1. Klijent šalje zahtev serveru 1. Klijent šalje zahtev serveru

2. Na strani servera se izvršava program koji kreira 2. Server vraća klijentu kopiju programa
dokument

Program

Dokument

Klijent Server

3. Server vraća klijentu kreirani dokument 3. Program se izvršava na strani klijenta i kreira
dokument.

(a) (b)
Sl. 5-13 (a) dinamički dokument; (b) aktivni dokument.

138
U drugom slučaju, tzv. aktivni dokumenti, Web stranica osim statičkog sadržaja (HTML, slike i sl.) sadrži i
program koji se nakon učitavanja stranice izvršava na strani klijenta (u pretraživaču). Na primer, zamislimo da
želimo da kreiramo Web stranicu koja sadrži animiranu grafiku ili interaktivni grafički interfejs. S obzirom da
HTML reguliše samo prikaz sadržaja stranice na ekranu pretraživača, neophodan je poseban program koji će
kreirati animacije ili omogućiti neku specifičnu interakciju sa korisnikom. Takođe, jasno je da se takav jedan
program mora izvršavati na računaru klijenta, tj. tamo gde se odvija interakcija sa korisnikom. Uvek kada klijent
zahteva aktivni dokument od servera, server šalje kopiju dokumenta sa sadržanim program koji se po učitavanju
izvršava u pretraživaču (Sl. 5-13(b)).
Dinamički dokumenti
Potreba za generisanjem dinamičkih dokumenata na strani servera najlakše se može se sagledati ako razmotrimo
korišćenje HTML formi na ranije opisani način. Kada korisnik popuni formu i klikne na dugme Submit,
pretraživač šalje serveru poruku sa sadržajem forme zajedno sa poljima koje je korisnik popunio. Očigledno,
ova poruka nije ime fajla koji treba vratiti klijentu, već se sadržaj poruke prosleđuje odgovarajućem programu
radi procesiranja. Obično, obrada na strani servera podrazumeva pristup bazi podataka (smeštenoj na hard disku
servera) radi upisa dostavljenih podataka ili čitanja zapisa koji odgovaraju dostavljenim podacima i generisanje
HTML stranice koja sadrži odgovor koji se vraća klijentu. Na primer, pošto je na Web stranici neke elektronske
prodavnice, korisnik izabrao stavke koje želi da kupi i kliknuo na dugme Submit, podaci uneti na formi se šalju
serveru gde se pokreće program čiji je zadatak da kreira HTML stranicu narudžbenice, koja će osim naziva i
cene izabranih stavki sadržati i ukupnu cenu, PDV, ime i adresu korisnika i sl. Uz to, od programa se očekuje i
da podatke o izdatoj narudžbi upiše u bazu podataka. Na Sl. 5-14 su prikazani koraci koji su potrebni za obradu
podataka unetih u HTML formu.

Sl. 5-14 Obrada HTML forme. Korisnik popunjava formu (1). Forma se vraća serveru (2) i predaje CGI-u (3). CGI
postavlja upit bazi podataka (4). Iz baze se preuzimaju traženi podaci (5). CGI kreira HTML stranicu (6). Stranica se
vraća klijentu (7) i prikazuje u pretraživaču (8).
Tradicionalni, i danas već zastareli način za procesiranje HTML formi i drugih interaktivnih Web stranica
zasnovan je na sistemu koji se zove CGI (Common Gateway Interface - opšti interfejs pristupa). CGI predstavlja
standardizovani interfejs koji omogućava Web serveru da ˝razgovara˝ sa pozadinskim programima. Po pravilu,
pozadinski programi su skripte napisane u jeziku Perl.
Drugi uobičajeni način za generisanje dinamičkog sadržaja podrazumeva umetanje skripti unutar same HTML
stranice. Kada server dobije zahtev za ovakvom stranicom, on izdvaja skript iz stranice i izvršava ga. Primer
jezika koji se koristi za pisanje ovakvih skripti je PHP (Hypertext Processor). Da bi PHP mogao da se koristi,
server mora da razume PHP jezik (slično kao što pretraživač mora da razume XML da bi bio u stanju da
interpretira Web stranicu napisanu u XML-u). Obično, server očekuje da Web stranice koje sadrže PHP imaju
nastavak .php umesto .html ili .htm.
Na Sl. 5-15 je prikazana HTML stranica sa ugrađenim jednostavnim PHP skriptom. Osim standardnog HTML-a,
stranica sadrži još i PHP skript unutar taga <?php . . . ?> . Efekat ovog skirpta je generisane Web stranice koja
sadrži opšte podatke o klijentu koji je zatražio stranicu. Pretraživači, uz svaki zahtev upućen serveru obično
šalju i neke dodatne informacije o sebi (tip pretraživača, jezik, operativni sistem, tip klijentskog računara, ...),
koje se prenose kao vrednost promenljive HTTP_USER_AGENT (deo poruke zahteva). Pretpostavimo da je
listing sa Sl. 5-15 smešten u fajlu test.php koji se nalazi na WWW direktorijumu kompanije ABCD. Kada se
korisnik obrati URL-u www.abcd.com/test.php, server kompanije ABCD otvara fajl test.php, pronalazi u njemu
PHP skript, zamenjuje ga vrednošću promenljive HTTP_USER_AGENT iz pristiglog zahteva i tako
modifikovanu stranicu vraća klijentu.
<html>
<body>
<h2>Ovo je sve sta znam o tebi:</h2>
<?php echo $HTTP_USER_AGENT?>
</body>
</html>

Sl. 5-15 HTML stranica sa ugrađenim PHP-om.

139
PHP je naročito pogodan za procesiranje formi. Razmotrimo primer HTML stranice sa Sl. 5-16(a) koja sadrži
formu. jedina specifičnost ove stranice je sadržaj prve linije koja definiše da radi obrade podataka unetih u
formu i vraćenih serveru treba koristiti fajl action.php. Stranica prikazuje dva tekstualna polja, jedno predviđeno
za unos imena (name) a drugo za unos godine rođenja (age) korisnika. Nakon što je korisnik popunio oba polja,
klikom na dugme Submit, popunjena stranica (tačnije, linija teksta koja sadrži unete podatke) se vraća serveru.
Server preuzima sadržaje polje name i age, a zatim otvara i prolazi kroz fajl action.php (Sl. 5-16(b)) i izvršava
svaki PHP skript na koji naiđe. Pod pretpostavkom da je korisnik u polja name i age upisao ˝Barbara˝ i ˝24˝,
HTML fajl koji se vraća klijentu imaće oblik kao na Sl. 5-16(c).
<html>
<body>
<form action=”action.php” method=”post”>
<p>Unesi svoje ime: <input type=”text” name=”name”> </p>
<p>Koliko imas godina: <input type=”text” name=”age”> </p>
<input type=”submit”>
</form>
</body>
</html>
(a)
<html>
<body>
<h1> Odgovor:</h1>
Zdravo <?php echo $name;?>.
Predvidjanje: sledece godine imaces <?php echo $age + 1;?> godina
</body>
</html>
(b)
<html>
<body>
<h1> Odgovor:</h1>
Zdravo Barbara.
Predvidjanje: sledece godine imaces 25 godina
</body>
</html>
(c)

Sl. 5-16 (a) Web stranica sa formom. (b) PHP skript za obradu podataka unetih u formu. (c) Izlaz PHP skripta za
ulaze ˝Barbara˝ i 24.
PHP je moćan programski jezik, koji se uz to i lako koristi, orijentisan na spregu između Web servera i servera
baze podataka. PHP poseduje promenljive, stringove, polja i većinu upravljačkih struktura koje srećemo u C-u.
PHP je open source i dostupan je za slobodno korišćenje. Posebno je projektovan za rad sa Apache web
serverom (koji je takođe open source).
Treća tehnika za dinamičko kreiranje Web stranica je JSP (JavaServer Pages). JSP je slična PHP-u, s tom
razlikom što se dinamički deo stranice piše u programskom jeziku Java, umesto u PHP-u. Stranice koje koriste
ovu tehniku obično imaju nastavak .jsp.
Četvrta tehnika, ASP (Active Server Pages) je Microsoft-ova verzija PHP-a i JSP-a. Za generisane dinamičkog
sadržaja kod ASP se koristi skript jezik Visual Basic Script (ili VB skript). Stranice koje koriste ASP, obično
imaju nastavak .asp.
Aktivni dokumenti
Skript jezici kao što su CGI, PHP, JSP i ASP rešavaju problem procesiranja formi i interakcije sa bazama
podataka na serveru. Svi oni su u mogućnosti da prihvate informacije unete u formu, pretraže informacije u bazi
podataka i generišu HTML stranicu sa rezultatima obrade. Međutim, ni jedan od ovih skript jezika nije u stanju
da reaguje na klik mišem ili da direktno interaguje sa korisnikom koji koristi pretraživač. Za tu namenu,
neophodan je program koji će se izvršavati u samom pretraživaču, na računaru klijenta umesto na računaru
servera. Web stranica sa pridruženim programom koji se izvršava na strani klijenta naziva se aktivnim
dokumentom.

140
Postoje dva načina za kreiranje aktivnih dokumenata. Prvi način podrazumeva da se program, u obliku binarnog
kôda, čuva na serveru, a da u HTML stranici postoji tag u kome je navedeno ime fajla koji sadrži program. Kada
HTML interpretator u pretraživaču naiđe na ovakav tag, on najpre preuzima fajl programa od servera, a zatim ga
izvršava. Programi ovog tipa najčešće se pišu programskom jeziku Java. Drugi način je zasnovan na skrip
jeziku koji se, slično PHP-u, ugrađuje u sam HTML. Međutim, za razliku od PHP skripta koji se izdvaja iz
HTML stranice i izvršava na serverskom računaru, skrip namenjen klijet iz HTML-a izdvaja pretraživač i
izvršava ga uz pomoć odgovarajućeg interpretatora. Najpoznatiji skript jezik za ovu namenu je JavaScript.
Java
Java je objektno-orijentisan jezik zasnovan na C++. Za razliku od C++, i većine drugih viših programskih
jezika, kompajlirani programi pisani u Javi su portabilni, tj. mogu se izvršavati na bilo kom računaru, nezavisno
od tipa procesora i operativnog sistema. U terminologiji Jave, kompajlirani program se naziva bajtkôdom
(bytecode). Bajtkôd ne sadrži mašinske instrukcije za neki konkretan procesor, već instrukcije koje se izvršavaju
u interpretatoru za Java bajtkôd, tj. u tzv. Java virtuelnoj mašini. Bilo koji računar na kome je instalirana Java
virtuelna mašina u stanju je da izvršava programe pisane u Javi. U osnovi, bajtkôd predstavlja međukôd, koji je
po složenosti između Java izvornog kôda i mašinskog kôda. Virtuelna mašina izvršava bajtkôd tako što u
bajtkôdu identifikuje pojedinačne komande (tzv. metode) i poziva odgovarajuće funkcije pisane u mašinskom
jeziku za ciljnu mašinu.
Java programi namenjeni za Web nazivaju se apletima. Apleti se čuvaju na Web serveru u fajlovima sa
nastavkom .class. Aplet se uključuje u HTML pomoću odgovarajućeg taga koji predstavlja instrukciju HTML
interpretatoru da od Web servera zatraži .class fajl, naveden u tagu, i prosledi ga virtuelnoj mašini gde će aplet
biti izvršen.
Primer jednostavnog apleta je aplet koji reprodukuje audio fajl, kao pozadinsku muziku, za vreme dok je u
pretraživaču prikazana stranica. Pretpostavimo da je aplet uključen u Web stranicu sa URL-om
http://www.elfak.ni.ac.yu/ i da je smešten u fajlu bgsound.class, koji se nalazi na URL-u
http://www.elfak.ni.ac.yu/java-apps. Tag koji uključuje aplet u HTML je sledećeg oblika:
<OBJECT CODEBASE=”http://www.elfak.ni.ac.yu/java-apps”
CLASSID = ˝java:bgsound.class˝
DATA = ˝bgsound.data˝
CODETYPE = ˝audio/MP3˝></OBJECT>
Tag sadrži više atributa, sledećeg značenja. Vrednost atributa CLASSID definiše ime fajla u kome je smešten
aplet. CODEBASE definiše server i putanju na kojoj se fajl nalazi. Ime fajla, ˝bgsound.data˝ u kome se čuvaju
podaci koje aplet treba da procesira navedeno je u atributu DATA. Ovaj fajl sadrži podatke tipa audio/MP3, što
je navedeno u atributu CODETYPE. Nakon učitavanja, aplet i prateći audio fajl se predaju virtuelnoj mašini;
aplet se startuje i sadržaj audio fajla, u dekodiranom obliku, šalje u audio karticu gde se obavlja reprodukcija.
Na sličan način, aplet može sadržati grafičku animaciju ili video. U tom slučaju, kao atributi taga OBJECT
navode se dimenzije pravougaone oblasti na ekranu pretraživača, gde će animacija/video biti prikazani.
Java apleti se mogu razumeti i kao fleksibilna zamena za pomoćne aplikacije i plug_in-ove. Na primer,
pretpostavimo da Web stranica sadrži sliku u nekom novom grafičkom formatu za koji na klijentskom računaru
ne postoji podrška u vidu plug-in-a ili pomoćne aplikacije i da zbog toga slika ne može biti prikazana na ekranu
pretraživača. Međutim, ako se za prikazivanje slike koristi aplet, dekoder za novi format može biti smešten u
samom apletu koji se automatski preuzima sa servera prilikom učitavanja stranice u pretraživač.
ActiveX kontrole su Microsoft-ov odgovor na Java aplete. ActiveX kontrole se, kao i apleti mogu ugraditi na
Web stranicu. ActiveX kontrole su programi kompilirani za Pentium procesore i izvršavaju se direktno, bez
posredovanja virtuelne mašine, kao što je to slučaj kod apleta. Zbog toga je izvršenje ActiveX kontrola značajno
brže od izvršavanja apleta, a njihove mogućnosti su daleko veće, u smislu korišćenja raspoloživih softverskih i
hardverskih resursa računara. Kada Internet Explorer u Web stranici primeti pozivanje na ActiveX kontrolu, on
je preuzima od servera, verifikuje njen identitet, registruje je na lokalnom računaru i izvršava. Međutim, pored
ograničena da se ActiveX kontrole mogu koristiti samo na Pentium PC računarima, njihovo korišćenje može biti
rizično u pogledu sigurnosti.
JavaScript
Slična funkcionalnost kao sa Java apletima se može dobiti i korišćenjem JavaScript jezika, s tom razlikom što je,
slično PHP-u, JavaScript skript jezik koji se u izvornom obliku ugrađuje u HTML stranicu. JavaScript program
se smešta u poseban HTML tag, <script>. Kada HTML interpretator naiđe na tag <script> on poziva JavaScript
interpretator koji izvršava sadržani skript.
Uprkos sličnom imenu, JavaScript, kao jezik, nema direktne veze sa Javom. Slično drugim skript jezicima,
JavaScript sadrži programske konstrukcije veoma visokog nivoa. Na primer, u jednoj liniji JavaScript programa

141
moguće je prikazati dijalog za unos teksta, čekati da tekst bude unesen i smestiti uneti tekst u neku promenljivu.
Zahvaljujući ovakvim i sličnim mogućnostima, JavaScript je pogodan za lako projektovanje interaktivnih Web
stranica. Takođe, JavaScript poseduje mnoge osobine viših programskih jezika, kao što su tipovi podataka,
aritmetički i logički operatori, petlje (for(), while()), funkcije i td.
Kao primer programa u JavaScript jeziku, razmotrimo listing Web stranice sa Sl. 5-17. Slično primeru sa Sl. 5-16,
stranica sadrži formu za unos imena i godina korisnika, a po unosu traženih podataka predviđa koliko će godina
osoba imati sledeće godine. Sekcija <body> je gotovo identična kao u primeru za PHP. Glavna razlika je u
deklaraciji Submit dugmeta i naredbe dodele sadržane u ovoj deklaraciji. Ova naredba dodele kazuje
pretraživaču da kao odgovor na klik dugmeta (događaj onclick) treba izvršiti JavaScript funkciju response i kao
parametar preneti joj formu.
<html>
<head>
<script language="javascript" type="text/javascript">
function response(test_form){
var person = test_form.name.value;
var years = eval(test_form.age.value) + 1;
document.open();
document.writeln("<html><body>");
document.writeln("Zdravo" + person + ".<br>");
document.writeln("Predvidjanje: sledece godine imaces" + years + ".");
document.writeln("<body><html>");
document.close();}
</script>
</head>
<body>
<form>
Unesi svoje ime: <input type="text" name="name">
<p>
Koliko imas godina?: <input type="text" name="age">
<p>
<input type=submit value="submit" onclick="response(this.form)"></form>
</body>
</html>
Sl. 5-17 Procesiranje forme pomoću JavaScript-a.
Funkcija responese() napisana je u zaglavlju HTML fajla, na mestu koje je inače rezervisano za naslov stranice,
boju pozadine i sl. Ova funkcija izdvaja iz forme vrednost polja name i pamti je kao string u promenljivoj
person. Takođe, funkcija izdvaja i vrednost polja age, konvertuje je u ceo broj, korišćenjem funkcije eval(),
dodaje 1-cu i rezultat pamti u promenljivu years. Nakon toga, funkcija otvara novi dokument za prikaz rezultata
i ispisuje četiri linije teksta korišćenjem funkcije writeln() i, konačno, zatvara dokument. Kreirani dokument je
HTML fajl, kao što se lako može zaključiti na osnovu HTML tagova koje funkcija response zajedno sa ostalim
tekstom upisuje u dokument.
Sa tačke gledišta krajnjeg korisnika, krajnji rezultat oba primera (Sl. 5-16 i Sl. 5-17) je isti. Međutim, bitno je
razumeti da se načini obrade ova dva primera suštinski razlikuju. U primeru koji koristi PHP, nakon klika na
dugme Submit, pretraživač izdvaja informacije iz forme i u vidu stringa ih šalje nazad serveru koji je poslao
stranicu. Server prepoznaje ime PHP fajla i izvršava ga. PHP skript kreira novu HTML stranicu koja se vraća
pretraživaču i prikazuje. Sa druge strane, u primeru koji koristi JavaScript, nakon klika na dugme Submiti,
pretraživač interpretira JavaScript funkciju sadržanu u samoj stranici. Ne postoji novi kontakt sa serverom, već
se sve e obavlja lokalno, unutar pretraživača. Zbog toga se rezultat obrade pojavljuju gotovo trenutno, za razliku
od primera sa PHP gde postoji izvesno neizbežno kašnjenje (reda do nekoliko sekundi) dok rezultujući HTML
fajl ne stigne nazad do pretraživača. Na Sl. 5-18 je ilustrovana razlika između procesiranja skripti na strani
klijenta i strani servera. U oba slučaja, korak 1 počinje nakon što je forma učitana u pretraživač. Korak 2
iniciran je klikom na dugme Submit, a nakon toga sledi procesiranje forme, koje u ova dva slučaja teče na
različite načine.

(a) (b)
Sl. 5-18 Procesiranje skripta: (a) na strani servera (PHP); (b) na strani klijenta (JavaScript)

142
Ove razlike ne znače da je JavaScript bolji od PHP-a. Namena ova dva skrip jezika je potpuno različita. PHP (i
srodni skript jezici) prevashodno se koriste za interakciju sa udaljenom bazom podataka. JavaScript se koristi za
interakciju sa korisnikom na strani klijentskog računara. Moguće je, i uobičajeno, da Web stranica sadrži oba
skript jezika, sa raspodeljenim zadacima.
Sl. 5-19 ilustruje različite tehnike za kreiranje dinamičkih i aktivnih Web stranica, o kojima je bilo reči u ovoj
sekciji. Dinamičke Web stranice se generišu na strani servera, uz pomoć različitih skript jezika (Perl, PHP, JSP
ili ASP), a klijent dobija standardnu HTML stranicu koju prosto treba da prikaže. Aktivne Web stranice sadrže
ugrađene skriptove (pisane u JavaSctipt jeziku) ili hiperveze na kompletne programe (u vidu Java apleta ili
ActiveX kontrola) koji se nakon učitavanja izvršavaju na klijentskom računaru, što omogućava kreiranje
interaktivnih korisničkih interfejsa, pa čak i složena procesiranja grafičkih, audio ili video sadržaja. Web
stranice napisane u XML-u se shodno pridruženom XSL fajlu u samom pretraživaču konvertuju u HTML, što
takođe predstavlja neku formu aktivnog sadržaja. Konačno, plug-in-ovi i pomoćne aplikacije predstavljaju
proširenja pretraživača i koriste se za prikazivanje multimedijalnih sadržaja različitih formata.

Sl. 5-19 Razlilčiti načini za generisanje i prikazivanje Web sadržaja.

5.7 HTTP
HTTP (HyperText Transfer Protokol - protokol za prenos hiperteksta) je protokol koji se koristi za pristup
podacima na Web-u. HTTP je klijent-server protokol aplikacionog sloja TCP/IP steka, koji, slično protokolima
SMTP ili FTP, za transport poruka koristi TCP. U većini slučajeva, HTTP klijent (pretraživač) zahteva Web
stranicu, a HTTP server (Web server) isporučuje njenu kopiju. Međutim, HTTP dozvoljava i prenos od
pretraživača ka serveru (npr. kada korisnik serveru šalje formu). HTTP je sličan FTP-u, ali je mnogo
jednostavniji jer koristi samo jednu TCP konekciju: ne postoji posebna kontrolna konekcija, a između klijenta i
servera se prenose samo podaci. Takođe, HTTP je sličan SMTP-u, jer sadrži koji se prenosi između klijenta i
servera liči na SMTP poruku. Uz to, za kontrolu formatiranja poruke se, kao i kod SMTP, koristi MIME. Za
razliku od SMTP, HTTP poruke nisu direktno nemenjene ljudima, već ih čitaju i interpretiraju HTTP klijent i
HTTP server.
Trajanje veze
Broj porta HTTP protokola je 80. Web server neprekidno osluškuje TCP port 80, čekajući da neki pretraživač
zatraži otvaranje TCP konekcije. Sa druge strane, pretraživač koji želi da pribavi Web stranicu poznatog URL-a,
inicira otvaranje TCP konekcije na portu 80 sa serverom čije je ime navedeno u URL-u. (Naravno, ovome
prethodi interakcija sa DNS serverom radi konverzije DNS imena servera u IP adresu). Kada je TCP konekcija
uspostavljena, pretraživač šalje serveru HTTP zahtev koji sadrži putanju i ime traženog fajla. Web server
odgovara prenosom fajla, a po završenom prenosu zatvara TCP konekciju. Ako učitana Web stranica sadrži
slike ili neki drugi dodatni sadržaj, neophodno je da pretraživač radi prenosa svakog takvog entiteta uspostavi
novu TCP konekciju sa serverom. Ovakav način rada, naziva se neperzistentnom vezom, i karakterističan je za
prvobitne verzije HTTP protokola (konkretno verzije 0.9 i 1.0).
Neperzistentni način rada je izrazito neefikasan ako se prenose Web stranice koje osim HTML-a sadrže i veći
broj slika, ikona ili drugih pratećih sadržaja (što je slučaj sa većinom Web stranica koje danas viđamo na Web-
u). Uspostavljane TCP konekcije generiše dodatni saobraćaj u mreži i unosi izvesno kašnjenje, što ima za
posledicu sporo učitavanje ovakvih Web stranica. Iz tog razloga, godine 1999. uvedena je nova verzija HTTP
protokola, verzija 1.1, koja podržava perzistentne (trajne) veze klijenta i servera. Kod perzistentnog načina rada,
pretraživač uspostavlja inicijalnu TCP konekciju, zatim šalje zahtev i dobija odgovor (kao kod HTTP 1.0).
Međutim, nakon slanja odgovora, server ne zatvara TCP konekciju, već je ostavlja otvorenom dajući priliku
pretraživaču da preko iste TCP konekcije uputi dodatne zahteve. Tipično, server zatvara TCP konekciju po
isteku nekog zadatog vremena nakon poslednje upućenog zahteva. Na ovaj način se dodatna opterećenja usled
uspostavljanja i raskidanja TCP konekcije raspodjeljuju na više HTTP zahteva/odgovora tako da je relativno
dodatno opterećenje na nivou celokupne Web stranice značajno manje.

143
HTTP transakcija
HTTP je klijent-server protokol kod koga se komunikaciju obavlja nizom transakcija: klijent šalje poruku
zahteva, a server odgovara porukom odziva.
Formati poruka
Formati poruka zahteva i odziva su slični (slika). Poruka zahteva se sastoji iz: linije zahteva, zaglavlja i tela
zaglavlja. Poruka odziva se sastoji od: statusne linije, zaglavlja i tela. Kod oba tipa poruka, telo je opciono, a
ako postoji koristi se za prenos sadržaja poruke (npr. Web stranica se nalazi u telu odziva). Ako postoji, telo je
od zaglavlja razdvojeno jednom praznom linijom.
Formati poruka
HTTP predviđa dva generalna tipa poruka koje se razmenjuju između klijenta i servera (Sl. 5-20). HTTP poruke
se sastoje od jedne ili više linija NVT ASCII teksta. Prva linija zahteva sadrži metod ili tip zahteva, a prva linija
odgovora informaciju o statusu odgovora. Oba tipa poruke sadrže zaglavlje koje od tela poruke odvojeno
jednom praznom linijom. Telo poruke je u oba slučaja opciono (ne mora da postoji) i koristi se za prenos
sadržaja poruke. Počev od verzije 1.1 HTTP podržava MIME kodiranje sadržaja (slično kao kod SMTP
protokola).

(a) (b)
Sl. 5-20 Formati HTTP poruka: (a) format zahteva; (b) format odgovora.
Metodi
HTTP je zamišljen opštije od prostog protokola za komunikaciju tipa zahtev/odgovor. HTTP predviđa više
različitih tipova zahteva koje klijent može da uputi serveru. U terminologiji HTTP standarda tipovi zahtevi se
zovu metodi. Osim osnovnog metoda GET koji služi za pribavljanje Web stranice, HTTP predviđa još nekoliko
dodatnih metoda navedenih u tabeli sa Sl. 5-21.
Metod Opis
GET Zahtev za čitanjem Web stranice
HEAD Zahtev za čitanjem zaglavlja Web stranice
PUT Zahtev za prenos Web stranice na server
POST Dodavanje sadržaja imenovanom resursu (npr. Web stranici)
DELETE Zahtev za brisanjem Web stranice na serveru
TRACE Echo poslatog zahteva
CONNECT Rezervisano za neku buduću namenu
OPTIONS Upit koji se odnosi na neke parametre servera

Sl. 5-21 HTTP metodi.

Metod GET zahteva od servera da pošalje traženu stranicu. (Ovde se pod stranicom misli na objekat koji može
biti HTML stranica, slika, Java aplet i sl, tj. na fajl). Stanica koja se vraća ne mora da sadrži samo ASCII tekst, a
za identifikaciju tip sadržaja koristi se MIME, slično kao kod e-mail protokola. Najveći broj HTTP zahteva koji
se javljaju na Web-u su upravo tipa GET. Uobičajeni oblik metoda GET je:
GET ime_fajla HTTP /1.1
gde je ime_fajla ime resursa (fajla) koji se traži, a 1.1 verzija HTTP protokola koji se koristi.
Metod HEAD traži od servera ne celu stranicu već samo njeno zaglavlje. Ovaj metod se može koristiti za
pribavljane informacije o datumu i vremenu kada je stranica poslednji put modifikovana, za prikupljanje drugih
informacija o stranici i njenom sadržaju ili prosto za testiranje validnosti URL-a (da li je na datom URL-u
prisutna stranica).
Metod PUT je suprotan metodu GET: umesto čitanja, ovaj metod upisuje stranicu na Web server. Uz pomoć
ovog metoda moguće je postaviti Web stranicu na udaljeni Web server. Stranica je sadržana u telu PUT zahteva.

144
Stanica ne mora biti tekst, a njen MIME tip naveden je polju Content-Type zaglavlja zahteva. Takođe, zaglavlje
zahteva sadrži i podatke za autorizaciju kojima klijent dokazuje da ima pravo da izvrši zahtevanu operaciju.
Metod POST je sličan metodu PUT. Za razliku od PUT, kojim se na server postavlja nova stranica (ili
zamenjuje postojeća), metod POST se koristi da se u resurs (u najopštijem smislu) koji se nalazi na datom URL-
u, upišu (dodaju) novi podaci. Postavljanje nove poruke na nekom Web forumu, primer je ovog tipa operacije.
Međutim, u praksi metod POST, kao i PUT, se retko koristi.
Metod DELETE služi za brisanje (uklanjanje) stranice sa Web servera. Kao i kod PUT, u zaglavlju zahteva tipa
DELETE moraju postojati podaci za autorizaciju.
Metod TRACE se koristi za testiranje veze sa serverom. Ovaj metod nalaže serveru da nazad vrati primljenu
poruku zahteva. TRACE je koristan u slučajevima kada se zahtevi ne obrađuju korektno, a klijent želi da sazna
da li zahtevi uopšte dolaze do servera.
Metod CONNECT nema definisanu namenu, već je rezervisan za neku eventualnu buduću primenu.
Metod OPTIONS omogućava klijentu da postavi upit serveru koji se odnosi na izvesne parametre rada servera
ili parametre nekog konkretnog fajla.
Status
U prvoj liniji svaki odgovor kojeg server vraća klijentu sadržan je trocifreni kôd statusa koji klijentu treba da
ukaže da li je njegov zahtev uspešno opsluže ili nije i ako nije zašto nije. Prva cifra statusnog kôda služi za
podelu odziva na pet glavnih grupa (Sl. 5-22). Kôd 1xx (x - proizvoljna cifra) se retko koristi u praksi. Kô 2xx
znači da je zahtev uspešno obrađen i da poruka sadrži traženi sadržaj. Kôd 3xx govori klijentu da traženu
stranicu potraži na nekom drugom URL-u ili u svom kešu (kasnije će biti više reči o keširanju). Kôd 4xx znači
da zahtev nije opslužen, bilo zato što je u samom zahtevu uočena greška ili zato što je klijent zatražio
nepostojeću stranicu. Konačno, kôd 5xx obaveštava klijenta da na strani servera postoje problemi, bilo zbog
greške u programu Web servera bilo zato što je server privremeno preopterećen.
Kôd Značenje Primer
1xx Informativno 100 - server pristaje da obradi klijentov zahtev
2xx Uspešno 200 - zahtev je prihvaćen i obrađen; 204 - odgovor ne sadrži telo
3xx Preusmeravanje 301 - stranica je premeštena na drugu URL lokaciju; 304 - keširana stranica je još uvek validna.
4xx Greška klijenta 403 - zabranjen pristup stranici; 404 - stranica nije pronađena.
5xx Greška servera 500 - interna greška servera; 503 - kasnije pokušaj ponovo

Sl. 5-22 Grupe statusnih kôdova.

Zaglavlja poruka
Nakon linije metoda u poruci zahteva sledi jedna ili više linija zaglavlja koje sadrže dodatne informacije o
zahtevu. Za svaku liniju ove sekcije se kaže da predstavlja jedno zaglavlje zahteva. Poruka odziva takođe može
sadržati zaglavlja (jedno ili više). Neka zaglavlja se koriste i kod zahteva i kod odgovora. U tabeli sa Sl. 5-23
navedena su najvažnija zaglavlja.
Zaglavlje User-Agent (korisnički agent) omogućava da klijent obavesti servera o tipu pretraživača koji koristi,
operativnom sistemu i drugim osobinama. Četiri zaglavlja koja počinju sa Accept obaveštavaju servera kakav
sadržaj je klijent spreman da prihvata. Prvo od ovih zaglavlja (Accept) navodi MIME tip stranice koji klijentov
pretraživač može da obradi (npr. text/html). Drugo (Accept-Charset) definiše skup karaktera (npr. ISO-8859-5
ili Unicode-1-1) koji klijent prepoznaje. Treće (Accept-Encoding) definiše metod kompresije koji klijent
podržava (npr. gzip), a četvrto (Accept-Language) ukazuje na prirodni jezik (npr. Srpski) koji korisnik razume.
Ako server ima mogućnost izbora stranice (npr. postoji više varijanti iste stranice), on će izabrati o vratiti
klijentu onu koja se uklapa u postavljene zahteve. Ako server nije u mogućnosti da udovolji zahtevima klijenta,
vratiće odgovor sa postavljenim odgovarajućim kodom greške.
Zaglavlje Host sadrži ime servera, preuzeto iz URL-a. Ovo zaglavlje je obavezno jer se može desiti da za istu IP
adresu budu vezana više DNS imena. Ispitivanjem sadržaja ovog polja, sever proverava da li se zahtev odnosi
baš na njega.
Zaglavlje Authorization je neophodno za stranice koje su zaštićene i za koje je klijent u obavezi da dokaže da
ima pravo da vidi stranicu.
Cookie-ima su posvećena dva zaglavlja. Preko zaglavlja Cookie klijent vraća serveru sadržaj cookie-a kojeg je
ranije poslat klijentu od strane neke mašine iz domena servera. Server šalje cookie klijentu u obliku sadržaja
zaglavlja Set-Cookie. Kao što znamo, klijent je u obavezi da zapamti cookie na svoj hard disk, i vrati ga serveru
pri svakom narednom obraćanju.

145
 Zaglavlje Tip Sadržaj
User-Agent Zahtev Informacija o pretraživaču i platformi
Accept Zahtev Tip stranica koje klijent može da procesira
Accept-Charset Zahtev Skup karaktera koji je prihvatljiv za klijenta
Accept-Encoding Zahtev Kodiranje stranice koje klijent može da procesira
Accept-Language Zahtev Prirodni jezik koji klijent može da procesira
Host Zahtev DNS ime servera
Authorization Zahtev Podaci za autorizaciju klijenta
Cookie Zahtev Sadrži cookie kojeg je server prethodno poslao klijentu
Date Zahtev/Odgovor Datum i vreme slanja poruke
Server Odgovor Opšte informacije o serveru
Content-Encoding Odgovor Način kodiranja stranice
Content-Language Odgovor Prirodni jezik korišćen na stranici
Content-Length Odgovor Veličina stranice u bajtovima
Content-Type Odgovor MIME tip stranice
Last-Modified Odgovor Datum i vreme poslednje promene stranice
Location Odgovor Instrukcija klijentu da zahtev pošalje na neko drugo mesto
Set-Cookie Odgovor Sadrži cookie kojeg server šalje klijentu
Sl. 5-23 Zaglavlja HTTP poruka (delimičan spisak).
Zaglavlje Date (datum) se može koristiti u oba smera i sadrži vreme i datum kada je poruka poslata.
Slede zaglavlja koja se javljaju isključivu u odgovorima koje server šalje klijentu. Zaglavlje Server omogućava
serveru da saopšti svoj identitet klijentu, ako želi.
Sledeća četiri zaglavlja, koja počinju sa Content- (sadržaj) omogućavaju serveru da opiše osobine stranice koje
šalje. (Značenje ovih zaglavlja je analogno odgovarajućim Accept- zaglavljima).
Zaglavlje Last-Modified sadrži datum i vreme kada je stranica poslednji put modifikovana. Ovo zaglavlja ima
bitnu ulogu u keširanju stranica.
Server koristi zaglavlje Location kada želi da obavesti klijenta da bi trebalo da pokuša da potraži zahtevanu
stranicu na nekom drugom URL-u. Ova mogućnost se koristi ako je stranica premeštena na drugu lokaciju ili
ako više od jednog URL-a ukazuje na istu stranicu. Na primer, neka internacionala kompanija može nakon
prijema zahteva za njenu glavnu stranicu na .com domenu, da preusmeri klijenta, na osnovu njegove IP adrese,
na jednu od svojih nacionalnih ili regionalnih stranicu.
Na Sl. 5-24 je prikazan izgled jednog kompletnog HTTP odgovora. Prva linija sadrži status odgovora, koji je u
ovom slučaju pozitivan. Sledi veći broj zaglavlja, zatim jedna prazna linija i konačno sama Web stranica.
Zaglavlje ETag sadrži jedinstveni identifikator stranice. Ovo zaglavlje se koristi prilikom keširanja stranica.

Sl. 5-24 Primer HTTP odgovora.

146
5.8 Proksi serveri i keširanje stranica
U dosadašnjem izlaganju o Web-u pretpostavljali smo da klijent i server direktno komuniciraju razmenom
HTTP poruka preko Interneta. Međutim, u izvesnim slučajevima komunikacija klijent-server ne mora biti
direktna već se može ostvarivati posredstvom jednog ili više među-servera. Dva tipa među-servera su: firewall i
proxy server.
Proxy server je posrednik između lokalnih (intranet) korisnika i Web-a (Sl. 5-25) i omogućava optimizaciju
kojom se smanjuje čekanje klijenata na pribavljanje zahtevanih Web stranica. Web pretraživači u mreži koja
koristi proxy server su konfigurisani tako da svoje HTTP zahteve ne upućuju direktno udaljenim Web serverima
već ih šalju lokalnom proxy serveru koji u njihovo ime obavlja zahtevanu transakciju. Kada prvi korisnik u
korporaciji pristupi određenoj Web stranici, proxy mora da pribavi kopiju od servera na kome se stranica nalazi.
Proxy ostavlja kopiju u svom kešu i vraća traženu stranicu kao odgovor na zahtev. Kada sledeći put neki
korisnik pristupi istoj stranici, proxy uzima podatke iz svog keša i ne šalje zahtev preko Interneta. Proxy serveri
su bitan deo arhitekture Web-a. Osim što efektivno skraćuju vreme pribavljanja Web stranica, proxy serveri
značajno redukuju saobraćaj na Internetu i smanjuju opterećenje Web servera.

Sl. 5-25 Proksi server.

Koncept proxy servera i keširanja nije ograničena samo na korporacijski intranet, već se primenjuje i u drugim
kontekstima. Na primer, proxy server ne mora biti računar na lokalnoj mreži, već može biti i proces pokrenut na
PC računaru. Takođe, mnogi provajderi internet usluga (ISP) poseduju proxy server sa ciljem da svojim
korisnicima ubrzaju pristup Web-u (i u isto vreme smanje protok podataka prema nadređenom ISP-u). Često,
postoji hijerarhija proxy servera. Zahtev se najpre šalje lokalnom proxy serveru, koji, ako nije u stanju da
opsluži zahtev, zahtev prosleđuje npr. korporacijskom proxy serveru, a ovaj proxy serveru provajdera internet
usluga i tako redom sve dok se u nekom kešu ne pronađe tražena stranica. Tek ako stranica ne postoji u kešu
proxy servera na vrhu hijerarhije, ona se direktno traži od Web servera, a onda prosleđuje nazad do pretraživača
koji je uputio zahtev i pri tome pamti u keševima svih posrednih proxy servera.

Sl. 5-26 Hijerarhijsko keširanje sa tri proksija.

HTTP sadrži eksplicitnu podršku za proxy servere. Protokol tačno određuje način na koji proksi obrađuje svaki
zahtev, kako proksi treba da tumači zaglavlje, kako pretraživač pregovara sa proksijem i kako proksi pregovara
sa serverom. Nekoliko HTTP zaglavlja je posebno namenjeno za proksije. Na primer, HTTP omogućava serveru
da kontroliše kako proksiji obrađuju svaku Web stranicu. Server može u odgovoru da uključi zaglavlje
Max_Forwards i tako ograniči broj proksija koji obrađuju stavku pre nego što se ona isporuči pretraživaču. Ako
server odredi samo jedan, Max_Forewards: 1, na putanji od servera do pretraživača dozvoljen je samo jedan
proksi. Nula znači da je zabranjeno da proksi obrađuju stavku.
Keširanje
Eliminisanjem nepotrebnih prenosa, proxy keš smanjuje i vreme čekanja i mrežni saobraćaj. Glavni aspekt
keširanja jeste privremeno čuvanje stranica, a glavno pitanje tiče se vremena čuvanja stranice, tj. koliko dugo
treba stavku čuvati u kešu. Sa jedne strane, ako se kopija predugo čuva u kešu ona može da zastari, što se dešava
ako je original u međuvremenu, nakon što je kopija uneta u keš, promenjen. Sa druge strane, ako se kopija ne
čuva dovoljno dugo, dolazi do smanjenja efikasnosti keširanja zato što sledeći zahtev mora nepotrebno da ide do
servera. Pojedine Web stranice su podložne čestim promenama (npr. stranica sa rezultatima fudbalskih
utakmica), dok druge mogu ostati neizmenjene u dužem vremenskom intervalu (npr. stranica posvećena Grčkoj
mitologiji). Takođe, sklonost stranice promenama može da varira u vremenu (npr. stranica sa rezultatima
fudbalskih utakmica se brzom menja samo dok utakmica traja, a onda ostaje neizmenjena do sledećeg kola).

147
Takođe, neke stranice se ni u kom slučaju ne mogu keširati. To je slučaj sa dinamičkim Web stranicama koje se
generišu na strani servera na osnovu postavljenog upita.
HTTP dozvoljava da server kontroliše keširanje na dva načina. Prvi način se oslanja na informaciju iz zaglavlja
odgovora Last-Modified kada određuje koliko dugo će stranica biti čuvana u kešu. Ako je stranica koja se
upravo stavlja u keš promenjena pre jednog sata, ona će biti čuvana u kešu jedan sat. Ako je promenjena pre dva
meseca, u kešu će ostati dva meseca. Iako ovaj pristup često dobro radi u praksi, on je zasnovan na
predviđanjima i zato ne garantuje da će pretraživaču uvek biti vraćena ažurna kopija stranice.

Sl. 5-27 Princip uslovnog GET zahteva.

Drugi pristup eliminiše mogućnost da pretraživač dobije zastarelu strancu, ali na račun izvesnog povećanja
saobraćaja i vremena čekanja na pribavljanje stranice. Pristup se oslanja na tzv. uslovni GET zahtev, koji proxy
može da pošalje serveru kako bi proverio ažurnost keširane stranice. Uslovni GET zahtev je HTTP poruka koja
sadrži zaglavlje If-Modified-Since (˝ako je modifikovana posle ...˝). Procedura je ilustrovana na Sl. 5-27 i odvija
se na sledeći način:
Pretraživač upućuje standardni GET zahtev proxy-ju (korak 1). Pretpostavimo da proxy u svom kešu ima
traženu stranicu. Svakoj keširanoj stranici pridružena je informacija o datumu i vremenu kada je stranica
keširana. Ova informacija je preuzeta iz polja Last-Modified HTTP poruke kojom je originalna stranica ranije
preneta od servera do proxy-ja. Pre nego što pretraživaču vrati keširanu stranicu, proxy šalje uslovnu GET
poruku serveru sa upisanim vremenom poslednje modifikacije keširane kopije u zaglavlju If-Modified-Since
(korak 2). Na Sl. 5-27 je pretpostavljeno da stranica nije modifikovana u međuvremenu, tj. od datuma i vremena
navedenih u zaglavlju If-Modified-Since. Zbog toga server vraća proxy-ju kratak odgovor sa statusnim kodom
304 (Not modified - nije modifikovana) i bez tela (korak 3). Po prijemu odgovora, proxy vraća keširanu stranicu
pretraživaču (korak 4). U slučaju da je zahtevana stranica u međuvremenu bila modifikovana, server će vratiti
proxy-ju novu kopiju stranice, koju će proxy smestiti u keš (zajedno sa datumom i vremenom iz zaglavlja Last-
Modified) pre nego što je prosledi pretraživaču.
Dva pristupa za kontrolu vremena keširanja se lako mogu kombinovati. Na primer, prvih T sekundi nakon
pribavljanja stranice proxy vraća pretraživačima keširanu kopiju bez postavljanja pitanja serveru. Po isteku T
sekundi, proxy koristi uslovnu GET poruku za proveru ažurnosti kopije.
Još jedan način za poboljšanje performansi keširanja naziva se proaktivnim keširanjem. Kada proksi pribavi
stranicu od servera, on je analizira i izdvaja sadržane hiperveze. Nakon toga, proksi može da pribavi i smesti u
svoj keš stranice na koje ukazuju izdvojene hiperveze, za slučaj da korisnik naknadno zatraži neku od njih. Na
ovaj način moguće je skratiti vreme pristupa za buduće zahteve za slučaj da korisnik izabere neki od linkova na
upravo učitanoj stranici. Međutim, pribavljajući i stranice koje nikada neće biti potrebne, ova tehnika ne
smanjuje već povećava saobraćaj na Internetu.

5.9 Firewall
Danas se na većini lokalnih, korporacijskih mreža koristi isti skup protokola kao i na Internetu (TCP/IP), a takve
mreže se nazivaju intranetima. Korišćenje Internet protokola na intranet mreži ima dvojako opravdanje. Prvo,
olakšan je pristup Web-u od strane računara povezanih na intranet (lokalni računari na isti način komuniciraju
međusobno kao i sa udaljenim serverima). Drugo, omogućeno je spoljnim Internet korisnicima da pristupaju
informacijama i servisima dostupnim na korporacijskim serverima (kao što je korporacijski Web server).
Međutim, iz sigurnosnih razloga, spoljnim korisnicima obično nije dozvoljen direktan pristup korporacijskim
serverima, već se ostvaruje posredstvom specijalizovanog server, tzv. firewall ili sigurnosni gateway, koji
nadgleda i filtrira mreži saobraćaj.

148
 Sl. 5-28 Firewall
Kao što se može videti sa Sl. 5-28, firewall kontroliše protok informacija u oba smera (kao iz tako i u intranet).
Firewall presreće i filtrira pakete koji su sa Interneta upućeni lokalnim serverima, kao i sve zahteve koji se iz
intraneta šalju prema Internetu. Filtriranje se obavlja na osnovu izvornih i odredišnih IP adresama i brojevima
portova sadržanim u TCP/UDP paketima ili na bazi nekih drugih kriterijuma. Firewall može biti konfigurisan
tako da prosleđuje ka intranetu samo pakete koji su upućeni na određene lokalne IP adrese i/ili samo ako su
paketi poslati iz nekog određenog domena, a da sve ostale poništava. Takođe, firewall može da uvede restrikcije
koje se odnose na brojeve portova. Na primer, firewall može biti tako podešen da poništava sve dolazne TCP
pakete sa brojem odredišnog porta 20 ili 21 i da na taj način onemogući pristup bilo kom lokalnom FTP serveru.
Slične restrikcije mogu biti uvedene i za pakete koji se iz intraneta šalju ka Internetu. Na primer, administrator
intraneta može da konfiguriše firwall tako da prema Internetu propušta smo TCP paketa sa odredišnim brojem
porta 80 i da tako lokalnim korisnicima omogući korišćenje globalnog Web-a, ali u isto vreme i zabrani pristup
ostalim servisima dostupnim na Internetu.

149