Internet I World Wide Web

IT255 - VEB SISTEMI 1
Internet i World Wide Web

Lekcija 01
IT255 - VEB SISTEMI 1
Lekcija 01
INTERNET I WORLD WIDE WEB

Poglavlje 1: Kratak pregled (r)evolucije WWW
Poglavlje 2: Internet mrea
Poglavlje 3: WEB pregledava klijent strana
Poglavlje 4: Web server
Poglavlje 5: URL
Poglavlje 6: Statiki Web dokumenti
Poglavlje 7: XML i XSL
Poglavlje 8: Dinamiki i aktivni Web dokumenti
Poglavlje 9: HTTP
Poglavlje 10: Proksi serveri i keiranje stranica
Poglavlje 11: Veba 1
Poglavlje 12: Domai zadatak 1
Zakljuak
Copyright 2017 UNIVERZITET METROPOLITAN, Beograd. Sva prava zadrana. Bez prethodne pismene dozvole od strane
Univerziteta METROPOLITAN zabranjena je reprodukcija, transfer, distribucija ili memorisanje nekog dela ili itavih sadraja
ovog dokumenta., kopiranjem, snimanjem, elektronskim putem, skeniranjem ili na bilo koji drugi nain.
Copyright 2017 BELGRADE METROPOLITAN UNIVERSITY. All rights reserved. No part of this publication may be reproduced,
stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording,
scanning or otherwise, without the prior written permission of Belgrade Metropolitan University.
www.metropolitan.ac.rs
UVOD
Web se sastoji od ogromne kolekcije dokumenata/stranica povezanih
hipervezama, a zapamenih u fajlovima koji su locirani na hiljadama
servera distribuiranim po globalnom Internetu.
Internet je globalni sistem meusobno povezanih raunarskih mrea koje koriste Internet
Protokol (TCP/IP) za meusobnu komunikaciju. Mrea svih mrea se sastoji od miliona
privatnih, javnih, akademskih, poslovnih i vladinih mrea i raunara povezanih raznim
tehnologijama, elektrinim, optikim i beinim. Internet se moe definisati i kao veza meu
raunarima radi omoguavanja razmene informacija meu korisnicima. Na Internetu je
zastupljen irok spektar informacija i servisa, kao to su hypertext stranice na World Wide
Webu, elektronska pota, zvuk, video, telefonska i video konverzacija, itd.
World Wide Web zvanino nastaje 1989. godine u CERN-u (evropskoj laboratoriji za fiziku
atomskih estica) u enevi. Grupa koju je vodio Tim Berners-Lee imala je za cilj kreiranje
distribuiranog sistema hipertekstualnih podataka: distribuirani je oznaavalo da su podaci
rasporeeni na razliitim lokacijama (raunarima), a hipertekstualni da se dodatne
informacije o eljenoj temi mogu dobiti jednostavnim izborom istaknutih mesta (klikom mia
na istaknutu re, frazu ili sliku).
Veb je tokom svog relativno kratkog postojanja evoluirao u platformu za razvoj i korienje
aplikacija. Dananje VA (Veb Aplikacije) su potpuno razvijeni, kompleksni softverski sistemi,
a izraz posetilac polako ali sigurno ustupa mesto izrazu korisnik Veb sajta, to implicira
visok nivo interakcije.
World Wide Web (ili samo Web) je kolekcija ogromnog broja elektronskih dokumenata
sainjenih od povezanih Web stranica napisanih u HTML-u. Stranice su raspoloive
korisnicima Web-a u vidu datoteka smetenih na milionima raunara distribuiranih po
Internetu. Svaka stranica moe sadrati pokazivae (tzv. linkove ili hiperveze) na druge
stranice koje mogu biti smetene na istom ili na nekom drugom raunaru (ili, u terminologiji
Web-a, Web sajtu).
Web se sastoji od ogromne kolekcije dokumenata/stranica povezanih hipervezama, a

zapamenih u fajlovima koji su locirani na hiljadama servera distribuiranim po globalnom
Internetu. Imajui to u vidu, kljuna pretpostavka Web-a je postojanje mehanizma za
imenovanje i lako lociranje stranica koji je sadran u URL-u (Uniform Resource Locator -
uniformni lokator resursa) stranice.
3
Poglavlje 1
Kratak pregled (r)evolucije WWW
ISTORIJA WWW
Za razliku od veine drugih stvari koje su vezane za informaciono-
komunikacionu tehnologiju, Veb nije nastao u Americi ve u Evropi.
Tanije u enevi, na CERN-u.
BernersLi je napravio sve komponente koje su mu bile potrebne (HTML, HTTP, pretraiva
nazvan WorldWideWeb, server i prvu Veb stranicu ikada, na kojoj je bio opisan sam projekat)
da pokrene Veb. WWW ima za cilj da omogui pravljenje veza (linkova) ka bilo kojoj
informaciji, bilo gde. (...) WWW projekat je zapoet kako bi se omoguilo fiziarima da
razmjenjuju podatke, novosti i dokumentaciju. Jako smo zainteresovani za irenje mree na
druge oblasti i otvaranje servera za druge podatke. Saradnici su dobrodoli!
Veb kakav danas poznajemo nije ni slian onome to je bio u svom skromnom zaetku.
Veb jeste razmenu fajlova uinio neposrednijom i lakom za korienje nego ikada pre: svako
je mogao koristiti sopstveni kompjuter da pretrauje fajlove skladitene na neijem tuem
kompjuteru. Razdaljina nije bila bitna. Operativni sistem nije bio bitan. Format nije bio bitan.
Magija koja je stajala iza svega toga bio je program zvani Veb server. Meutim, jo uvek je
falio efikasan alat za pretraivanje i korienje svih tih informacija koji bi bio prihvatljiv i manje
iskusnim korisnicima.
Potreba za boljim alatom na klijentu je postala stvarna, a stvarna potreba stvara trite. I tada
je nastao Veb pretraiva. Bio je to ultimativni alat za povezivanje klijenta na sve vei broj
Veb stranica, koje su nicale na serverima sa svih strana.
A kada se proulo o izuzetnim karakteristikama i mogunostima Veba, poslovni svet je obratio

panju i zapazio: ovde imamo medijum koji moe dopreti do bilo koga, bilo gde, u bilo koje
vreme, sa kompjuterom.
Strunjaci u marketingu su shvatili potencijal. Prodavci su bili odmah za njima, a ubrzo je

ubeen i top menadment. Veb je postao i sutinski javan. Odjednom, svi su imali svoju Veb
adresu i poele su da niu sve sloenije veb aplikacije.
Definicija 1: Veb aplikacija (VA) je softverski sistem zasnovan na tehnologijama i standardima

W3C konzorcijuma (eng. World Wide Web Consortium) koji prua resurse specifine za Veb,
kao to su sadraj i usluge, kroz korisniki interfejs, Veb pretraiva.
Veb je tokom svog relativno kratkog postojanja evoluirao u platformu za razvoj i korienje
aplikacija. Dananje VA su potpuno razvijeni, kompleksni softverski sistemi, a izraz posetilac
4
Poglavlje 1 Kratak pregled (r)evolucije WWW
polako ali sigurno ustupa mesto izrazu korisnik Veb sajta, to implicira visok nivo
interakcije.
KATEGORIJE VEB APLIKACIJA

Mada je prvobitno bio zamiljen kao iskljuivo informacioni medijum,
Veb je tokom svog relativno kratkog postojanja evoluirao u platformu
za razvoj i korienje aplikacija.
Umesto Vebmastera, veliki Veb sajtovi moraju da uposle Veb menadere, koji vode raznovrsne
timove IT profesionalaca, ukljuujui programere, administratore baza podataka, mrene
administratore, inenjere upotrebljivosti, grafike dizajnere, strunjake za bezbednost i
marketing. Ova evolucija moe se pratiti tragom nekoliko dimenzija i iz vie perspektiva:
rastom broja Veb sajtova i Veb stranica; rastom broja korisnika Veba; brojem poseta;
funkcionalnostima i interaktivnou Veb aplikacija; tehnologijama korienim za razvoj Veb
aplikacija; socijalnom i poslovnom uticaju Veba ili njihovim kombinacijama.
Slika desno daje pregled razliitih kategorija Veb sajtova u zavisnosti od njihove hronologije
razvoja i stepena sloenosti, sa primerima za svaku kategoriju. Moramo imati na umu da
postoji relacija izmeu hronologije nastanka i kompleksnosti. Novije kategorije su obino
sloenije, ali to ne znai da u potpunosti mogu zameniti prethodnu generaciju. Svaka od ovih
kategorija ima sopstvena, specifina, polja primene. Posledino, kompleksni Veb sajtovi mogu
obino biti svrstani u nekoliko kategorija odjednom.
Takoe moemo primetiti da razliite kategorije pokrivaju mnoge tradicionalne aplikacione

domene, kao to je bankarstvo, ali su istovremeno stvorena i potpuno nova polja primjene
softvera, kao to su servisi svesni lokacije.
Kategorije VA su: Dokument-orjentisani Veb sajtovi, interaktivne Veb aplikacije, Transakcione

Veb aplikacije, Aplikacije bazirane na tok rada, saradnike Veb aplikacije, socijalni Veb,
Portalski orjentisane aplikacije i Semantiki Veb.
Slika 1.1 1 Kategorije Veb sajtova/aplikacija
Ova lekcija sadri video materijal. Ukoliko elite da pogledate ovaj video morate da
otvorite LAMS lekciju.
5
NAJBITNIJA SVOJSTVA KATEGORIJA VEB APLIKACIJA

Prikazivanje veb stranice najee zapoinje ili unoenjem URL adrese
u web browser, ili preko hiperlinka koji vodi na tu stranicu (ili resurs,
uopteno).
Dokument-orjentisani Veb sajtovi su prethodili Veb aplikacijama. Veb stranice su skladitene

na Veb serverima kao gotovi, t.j. statini HTML dokumenti i slate su klijentu kao odgovor na
njegov zahtev. Izmene na njima su se obino vrile runo, uz pomo odgovarajuih alata.
Razumljivo je zato je ovo brzo postalo neefikasno i skupo, pogotovo za Veb sajtove sa velikim
brojem stranica. Sa druge strane, glavne prednosti ovakvih Veb sajtova su jednostavnost,
stabilnost, kao i relativno brz odgovor na zahteve klijenta, jer su stranice ve spremne na
serveru i potrebno ih je samo poslati, bez neke prethodne obrade ili prilagoavanja.
Sa uvoenjem CGI (eng. Common Gateway Interface) i HTML formi, pojavile su se interaktivne
Veb aplikacije. One su, gledano iz dananje perspektive, pruale prilino ogranien nivo
interakcije, ali tada bio je to korak od hiljadu kilometara, jer su oznaile jednu potpuno novu
ideju i fazu razvoja Veba. Veb stranice i veze (linkovi) ka drugim stranicama su se kreirale
dinamiki, u skladu sa korisnikim akcijama. Primeri za ovu kategoriju su virtuelne izlobe,
sajtovi za vesti i sl.
Transakcione Veb aplikacije su napravljene sa ciljem podizanja interaktivnosti na vii nivo. U

njima je korisnik mogao ne samo da ita ponueni sadraj, ve i da ga menja.
Ako uzmemo za primer sistem za turistike informacije, ovo bi omoguilo menjanje podataka
na decentralizovan nain ili rezervisanje smetaja. Preduslov ovome bili su sistemi za
upravljanje bazama podataka koji su omoguavali efikasno i konzistentno upravljanje sve
obimnijim sadrajem Veb aplikacija i postavljanje strukturisanih upita. Onlajn bankarstvo,
trgovina i sistemi za rezervacije pripadaju ovoj kategoriji.
Aplikacije bazirane na tok rada omoguavaju upravljanje tokom rada unutar jedne ili izmeu
vie kompanija, javnih slubi i/ili privantih lica. Kompleksnost usluga, autonomija uesnika u
procesu i potreba za robustnim i fleksibilnim tokovima rada su glavni izazovi na ovom polju.
Primeri za ovu kategoriju mogu biti B2B (eng. Business-to-Business) reenja u e-trgovini,
aplikacije e-uprave u domenu javne administracije (Vlada) i sl.
Dok aplikacije bazirane na tok rada zahtevaju odreeno strukturiranje automatizovanih
procesa i operacija, saradnike Veb aplikacije se koriste upravo u situacijama kada je
potrebno omoguiti saradnju pri nestrukturiranim operacijama. Ovde je potreba za saradnjom
razliitih
uesnika vrlo visoka. Saradnike Veb aplikacije podravaju deljenje informacija i radnog
prostora (npr. WikiWiki) u cilju generisanja, menjanja i kontrolisanja deljenih sadraja.
VEB INENJERING
Veb sajtovi koji nemaju softverskih komponenti, kao npr. statine HTML
stranice, takoe nisu Veb aplikacije.
6
Mada ga je u poetku karakterisala kakva-takva anonimnost korisnika, sve je izraeniji trend

transformisanja Veba usocijalni Veb, gde ljudi dobrovoljno otkrivaju svoj identitet odreenoj
zajednici korisnika, sa ciljem pronalaenja slinih interesovanja sa osobama koje ve poznaju
i/ili upoznavanja novih osoba koje imaju slina interesovanja. Ovaj trend je toliko izraen da
posedovanje profila na nekoj od socijalnih mrea (Fejsbuk, Tviter, LinkedIn i sl.) danas spada u
normu. Pored svih koristi koje ovakva umreavanja donose, javljaju se i znatne opasnosti
naroito za populaciju maloletnih korisnika te se namee potreba za vrlo tesnom saradnjom
IT inenjera i strunjaka iz domena drutvenih nauka (psiholozi, sociolozi itd.) u cilju zatite
najugroenijih korisnika ovakvih servisa.
Portalski orjentisane aplikacije predstavljaju jedinstvenu taku pristupa mnogobrojnim

odvojenim, mogue i heterogenim po prirodi, izvorima informacija i servisa.
Sve vanijesveprisutne Veb aplikacije pruaju korisniku prilagoene usluge u bilo koje
vreme, bilo gde, za bilo koji ureaj (sveprisutne).
Aktuelni trendovi, meutim, e dovesti do situacije da e ovaj tip aplikacija uskoro postati
dominantan na tritu. Jedan od ovih trendova je i Semantiki Veb . Cilj Semantikog Veba
je predstavljanje informacija na Vebu ne samo za ljudska bia, ve i u obliku koje bi mogle
da itaju maine. Kao i veina problema u raunarstvu, ovo se reava dodavanjem jo jednog
sloja posrednika (semantike) izmeu podataka koje razumeju ljudi i kompjutera. Svi koji
su se bavili razvojem VA bili poetnici, bez obzira koliko dugo su pre toga projektovali ili
kodirali softver.
Jako mnogo dobre inenjerske prakse je bilo prosto odbaeno i zanemareno u tim prvim
danima razvoja VA. Na (ne)sreu, strunjaci su (ne)blagovremeno uoili ovu tendenciju i
1996. godine se u IT svetu pojavila nova kovanica: Veb inenjering.
Definicija 2: Veb inenjering podrazumeva primenu sistematinih i merljivih pristupa

(koncepata, metoda, tehnika, alata) na isplativu analizu zahteva, dizajn, implementaciju,
testiranje, eksploataciju i odravanje visokokvalitetnih Veb aplikacija.
Mada Veb inenjering koristi principe softverskog inenjeringa, on dodatno obuhvata i nove
pristupe, metodologije, alate i tehnike, kao i smernice da bi izaao u susret jedinstvenim
zahtevima sistema zasnovanih na Vebu. U mnogim aspektima, razvoj sistema zasnovanih na
Vebu je mnogo vie od razvoja tradicionalnog softvera.
INTEROPERABILNOST U VEB INENJERINGU

Veb inenjering je danas dobro razvijeno i zrelo polje istraivanja,
snano povezano sa ostalim disciplinama, kao to su softverski
inenjering, HCI i vetaka inteligencija.
U dananje vreme VA su po sloenosti dostigle nivo da je nuna primena znanja, modela i

tehnika sistemske analize i dizajna sloenih sistema, a VA esto prerastaju u Veb sisteme
(VS). Glavne karakteristike VS su: Mnogi korisnici - mnogi jezici - mnoge kulture; Razliiti
mehanizmi pristupa; Mnogi Korisniki agenti; Veliki obim meusobno povezanih podataka
(ukljuujui razliite medije) i procese;
7
Slika 1.2 2 Veza Veb inenjeringa i ostalih disciplina
Odgovarajui prikaz (prezentacija); Napredovanje kroz aktivnosti - zavriti jednu stvar pre
poetka drugog; esto vodi korisnika; Nadogradnja i poveanje kompleksnosti; Mnogo
projektanata u timu, mnogo transakcija, sloena komunikacija i upravljanje projektom
razvoja; Veliki broj proizvoda iteracija / verzija /; Prilagoavanja korisnicima, personalizacija,
bezbedonosna pitanja i mnogo toga jo kao to je to na sledeoj slici prikazano.
VEB SISTEMI
Iako sistematske tehnike dizajna i izrade mogu biti primenjene, ipak je
neophodno proveravati meuproizvode, kao i finalnu aplikaciju.
UDa bi se osigurao uspean razvoj VS potrebno je, ali ne i dovoljno primeniti sledee korake
u dizajnu:
1. Razumeti optu funkciju sistema i operativno okruenje, ukljuujui i poslovne ciljeve i

uslove, poslovnu kulturu organizacije i politike upravljanja informacijama.
2. Jasno identifikovati zainteresovane strane - to jest, glavne korisnike tog sistema i njihove
tipine profile, organizaciju koja treba sistem, i ko finansira razvoj.
3. Objaviti ili specificirati (poetne) funkcionalne, tehnike, ali i netehnike zahteve

zainteresovanih strana i zahteve ukupnog VS. Dalje, prepoznati da ovi zahtevi ne moraju
ostati isti tokom projektovanja VS; poi od toga da oni treba da evoluiraju tokom vremena
razvoja veb sistema.
4. Razviti arhitekturu celokupnog Veb-baziranog sistema koji zadovoljava postavljene

tehnike i netehnike zahteve.
8
5. Identifikovati podprojekte ili podprocese za implementaciju arhitekture sistema. Ako su

podprojekti suvie sloeni za upravljanje, dodatno ih podeliti (usitniti) dok ne postanu skup
zadataka koji se lako realizuju.
6. Razviti i implementirati definisane podprojekte.
7. Ukljuiti efikasne mehanizme za upravljanje evolucijom veb sistema, promenu i

odravanje. Kako se sistem razvija, ponovite ceo proces ili neke delove toga, prema potrebi.
8. Adresirati netehnika pitanja, kao to su revidiranje: poslovnih procesa, organizacionih i

menadment politika, razvoj ljudskih resursa i pravne, kulturne, i socijalne aspekte.
9. Meriti performanse sistema, analizirati korienje Veb aplikacije preko veb logova,
razmatrati povratne informacije i sugestije korisnika u cilju poboljanja VS.
10. Doterivati i aurirati veb sistem kroz konstantno testiranje dizajna i implementaciju
(programiranje).
9
Poglavlje 2
Internet mrea
STRUKTURA INTERNETA
Internet poseduje tronivovsku strukturu . Okosnica Interneta ili
backbone predstavlja vrni nivo u hijerarhiji Interneta.
Povezivanjem dve ili vie mrea nastajeinternet (Sl. 1). Mree se povezuju pomou ureaja
za meumreno povezivanje (oznaeni slovom R na Sl. 1). Primeri ovakvih ureaja su ruteri
i gateway-i. Tipino, internet ini vei broj LAN i MAN mrea povezanih u WAN. Napomenimo
da treba praviti razliku izmeu pojmova internet (poinje malo slovom) i Internet (poinje
velikim slovom). Internet, sa malim i, je uopteni pojam koji se odnosi na povezivanje
mrea. Internet, sa velikim I, je ime najvee i najrasprostranjenije svetske mree.
Slika 2.1 1 Internet mrea
Struktura Interneta
Internet (sa velikim I) je gigantska mrea prvobitno kreirana povezivanjem razliitih

istraivakih i odbrambenih (vojnih) mrea (kao to su NSFnet, MILnet i CREN). Od tada, na
Internet su prikljuene brojne druge mree velike i male, privatne i javne. S preko 400
miliona hostova, Interent je danas ubedljivo najvea i najrasprostranjenija svetska mrea.
Internet poseduje tronivovsku strukturu (Sl. 2). Okosnica Interneta ili backbonepredstavlja
vrni nivo u hijerarhiji Interneta. Sastoji se od mrea kao to su NSFnet i EBONE koje prenose
saobraaj i obavljaju rutiranje za mree srednjeg nivoa. To su mree veoma velike propusne
moi koje poput kostura dre na okupu sve razuene delove Interneta.
10
Poglavlje 2 Internet mrea
Slika 2.2 2 Struktura Interneta
PAKETSKI PRENOS PODATAKA

U komunikacionim mreama koje pokrivaju vea geografska rastojanja,
kao to je Internet, komunikacija izmeu izvora i odredita se ostvaruje
prenosom podataka kroz mreu.
Tranzitne mree, takoe poznate i kao regionalne, u hijerarhiji Inerneta se nalaze odmah
ispod backbone mrea. Nihov zadatak je da osim za svoje hostove prosleuju saobraaj i
izmeu drugih mrea istog ili nieg nivoa. Tranzijentna mrea je uvek povezana s bar dve
duge mree.
Periferne mree su lokalne (LAN) ili gradske (MAN) mree, koje prenose podatke iskljuivo
ka i od svojih hostova. ak i kada su povezane sa jednom ili vie drugih mrea, kroz periferne
mree nikada ne prolazi saobraaj nemenjen nekoj drugoj mrei.
Rast Interneta je veoma brz, sa stopom od 10-15% meseno, a broj mrea koje se
razgranavaju sa Internet backbone-a udvostruava se svakih 16 meseci. Internet backbone
koji je 90-tih godina ima oblik riblje kosti, danas vie lii na ribarsku mreu razapetu po
celom svetu.
Paketski prenos podataka
U komunikacionim mreama koje pokrivaju vea geografska rastojanja, kao to je Internet,

komunikacija izmeu izvora i odredita se ostvaruje prenosom podataka kroz mreu
posrednih komutacionih vorova, tj. rutera.
Ruteri se ne bave interpretacijom sadraja i znaenja podataka, ve se bave prenosom

podataka od vora do vora na njihovom putu do krajnjeg odredita. Na Internetu se koristi
koncept prenosa podataka koji se naziva komutacijom paketa. Shodno ovom konceptu,
poruke se prenose u kratkim blokovima, tzv. paketima.
Duina paketa je ograniena, a maksimalno dozvoljena duina obino ne prelazi 1000 bajta.
Due poruke, koje se ne mogu upakovati u jedan paket, u izvornom hostu se dele na niz
paketa, koji se nezavisno alju i prenose kroz mreu. Svaki paket ima deo za korisnike
podatke i deo za kontrolne informacije. Kontrolne informacije, izmeu ostalog, sadre
informacije koje su neophodne ruterima kako bi paket usmerili ka eljenom odreditu. U
11
svakom ruteru, paket se prima, skladiti i nakon izvesnog vremena prosleuje sledeem
ruteru. Na Sl. 3 je ilustrovan osnovni princip rada komutacije paketa.
Slika 2.3 3 Komutacija paketa: datagramski pristup
KOMUTACIJA PAKETA
Kod mrea sa komutacijom paketa, svaki paket se u svakom ruteru
nezavisno obrauje, a nain na koji e ruter postuputi prema datom
paketu ne zavisi od postupka prema prethodnim.
Raunar sa leve strane slike alje poruku raunaru sa desne strane. Predajni (izvorni) raunar
deli sadraj poruke na niz paketa (Sl. 3(a)). Svaki paket, pored podataka iz originalne poruke,
sadri, u delu za kontrolne informacije, informaciju koja identifikuje odredini host. Izvorni
raunar alje paket po paket ruteru sa kojim je povezan. Ovaj ruter privremeno skladiti
(baferuje) primljene pakete; za svaki paket, na osnovu kontrolnih informacija iz paketa,
odreuje kom susednom ruteru treba proslediti paket i smeta paket u red ekanja pridruen
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
nain, kreui se od rutera do rutera (Sl. 3(b)), paket konano stie na svoje krajnje odredite
(Sl. 3(e) ).
Kod mrea sa komutacijom paketa, svaki paket se u svakom ruteru nezavisno obrauje, a
nain na koji e ruter postuputi prema datom paketu ne zavisi od toga kako je postupao
prema prethodnim paketima. Ovaj pristup je ilustrovan na Sl. 3. Usmeravanje paketa u
ruterima nije jednoznano. Kada ruter donosi odluku na koju stranu usmeriti paket, on uzima
u obzir ne samo informaciju o adresi odredinog hosta, ve i informacije prikupljene od
susednih rutera koje se tiu njihovog trenutnog
optereenja, otkaza pojedinih prenosnih linija i sl. To znai da paketi sa istom odredinom
adresom ne moraju biti uvek isporueni istom susednom ruteru (Sl. 3(c) ).
Posledica ove neodreenosti je pojava da paketi koji se prenose izmeu para hostova mogu
stii do odredita razliitim putanjama i izvan redosleda u kojem su poslati. U primeru sa Sl.3,
krajni ruter na putanji ureuje pristigle pakete u prvobitni redosled i isporuuje ih odreditu.
(Napomenimo da je kod nekih mrea, preureenje paketa zadatak odredinih stanica, a ne
krajnjih vorova.) Takoe, moe se desiti da neki paketi budu uniteni u toku prenosa. (Na
primer, ako neki ruter otkae, svi paketi koji trenutno borave u ruteru, bie izgubljeni.)
12
Ponovo, detekcija izgubljenih paketa i odluka kako postupiti u ovakvim situacijama je u

nadlenosti krajnjih hosova. Kod mrea koje koriste opisanu tehniku komutacije, za pakete se
uobiajeno koristi termin datagram.
Osnovne karakteristike paketskog prenosa, koje ga ine pogodnim za primenu kod Interneta
su:
? Prenosne linije se efikasno koriste, s obzirom na to da se komunikacioni kapacitet linije, koja

povezuje dva rutera, dinamiki, u vremenu, raspodeljuje na prenos mnogih paketa.
KARAKTERISTIKE PAKETSKOG PRENOSA

Ruter uzima pakete sa poetka reda ekanja i maksimalnom brzinom
ih alje na liniju.
Paketi koji iz razliitih pravac stiu u vor, a koje treba dalje preneti preko iste izlazne linije,
smeataju se u red ekanja pridruen toj liniji. Ruter uzima pakete sa poetka reda ekanja i
maksimalnom brzinom ih alje na liniju.
Mrea sa komutacijom paketa moe da amortizuje razlike u brizni prenosa podataka

razliitih hostova. Paketi se baferuju u ruterima, to znai da paket moe biti primljen
jednom, a poslat drugom brzinom. Na ovaj nain, u mrei sa komutacijom paketa mogue
je kombinovati spore i brze prenosne medijume, kao i hostove razliitih brzina prenosa
podataka.
Kod mrea sa komutacijom paketa, ak i u uslovima ntenzivnog saobraaja, mrea
prihvata nove pakete, mada je vreme prenosa paketa kroz mreu due. Sa poveanjem
optereenja mree, u baferima rutera se gomilaju paketi koji ekaju da budu preneti
dalje. Komunikacija izmeu hostova nije prekinuta, mada su performanse nie. Meutim,
baferski prostor u ruterima je ograniene veliine i moe se desiti da pri veoma velikom
optereenju neki paketi budu izgubljeni zato to je u pojedinim ruterima baferski prostor
iscrpljen.
Princip komutacije paketa omoguava uvoenje prioriteta. Ruter, umesto da se prilikom
slanja paketa na izlaznu liniju dri
striktnog redosleda paketa u redu ekanja, moe dati prednost paketima sa visokim
prioritetom. Paket visokog prioriteta bie izabran za slanje bez obzira na njegovu poziciju u
redu ekanja.
Na taj nain, paketi vieg prioriteta prenosie se bre kroz mreu nego paketi niskog
prioriteta.
Meutim, komutacija paketa ispoljava i izvesne nedostatke:
Prolazak paketa kroz ruter unosi dodatno kanjenje u prenosu. S obzirom na to da se

paket baferuje u ruteru, pre nego to se prosledi dalje, ovo kanjenje, u minimalnom
iznosu, jednako je koliniku duine 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 mrei.
13
Ukupno vreme prenosa paketa jednako je zbiru kanjenja paketa kroz rutere na putanji
koju paket prolazi. S obzirom na to to se paketi mogu razlikovati po duini, mogu
biti preneseni razliitim putanjama i mogu biti izloeni promenljivim kanjenjenima u
ruterima, sveukupno vreme prenosa paketa od datog para izvorodredite, moe znaajno
da varira od paketa do paketa.
MRENE ARHITEKTURE
Razmena podataka izmeu umreenih ureaja zahteva sprovoenje
veoma sloenih procedura, kao to su one za uspostavljanje i
odravanje komunikacione veze i sl.
Ova pojava se naziva treperenje ili diter (jitter) i moe biti nepoeljna kod izvesnih
aplikacija, kao to su aplikacije koje zahtevaju prenos podataka u relanom vremenu
(telefonija, video, audio, ..).
Da bi se omoguilo usmeravanje paketa kroz mreu, svaki paket osim podataka mora
sadrati i dodatne kontrolne (reijske) informacije (npr. adresa odredita, redni broj
paketa u poruci i sl.). Za prenos kontrolnih informacija troi se deo komunikacionog
kapaciteta prenosnih linja, ime se smanjuje raspoloiv kapacitet za prenos korisnikih
podataka.
Mrene arhitekture
Razmena podataka izmeu umreenih ureaja zahteva sprovoenje veoma sloenih

procedura, kao to su one za uspostavljanje i odravanje komunikacione veze, odravanje
korektne sinhronizacije izmeu strana koje komuniciraju, pronalaenje optimalne putanje u
mrei izmeu udaljenih vorova i jo itav niz drugih zadataka.
Veina ovih procedura se realizuju u softveru (tzv. mreni softver). Zadatak mrenog softvera
je da od krajnjeg korisnika sakrije sve detalje nieg nivoa koji su neophodni za ostvarivanje
komunikacije, pruajui mu privid direktne razmene podataka s korisnikom koji je na drugom
kraju veze.
(Korisnik moe biti ovek, raunar ili aplikacioni program). Meutim, umesto da se jedan
takav softver realizuje kao monolitni modul, koji bi se bavio svim aspektima i detaljima
mrene komunikacije, on se obino deli na nezavisne, ali meusobno povezane podmodule,
od kojih je svaki odgovoran za jedan specifian zadatak ili skup zadataka.
Neki zadaci su nieg nivoa apstrakcije, kao npr., transformacija bitova u signal koji se prenosi
linkom, dok su drugi vieg nivoa, kao npr., usmeravanje (rutiranje) poruka u mrei sloene
topologije. Iz tog razloga, podmoduli se rasporeuju u slojeve. Svaki sloj u ovakvoj vertikalnoj
strukturi reava niz problema karakteristinih za jedan nivo apstrakcije.
Kao to je zadatak celokupnog mrenog softvera da sakrije sve detalje mrene komunikacije
od krajnjeg korisnika, tako je zadatak svakog sloja da od sloja iznad sakrije sve detalje nieg
nova, koji su reeni u tom sloju i svim slojevima ispod.
14
Tako npr., sloj koje se bavi rutiranjem poruka nije optereen problemima koji se tiu prenosa
podataka preko jednog fizikog linka, zato to je to odgovornost niih slojeva.
RAVNOPRAVNI (PEER-TO-PEER) SLOJEVI

Treba istai da slojevita organizacija softvera nije karakteristina samo
za mreni softver, ve prestavlja jedan od bazinih principa u
raunarstvu i ima sutinske slinosti sa konceptima.
Koncept slojevite organizacije mrenog softvera ilustrovan je na Sl. 4. Broj slojeva, njihovi
nazivi, sadraj i funkcije, razlikuju se od mree do mree. Uopteno govorei, svrha svakog
sloja je da prui odreeni skup usluga (servisa) viim slojevima, skrivajui od njih detalje koji
se odnose na to kako su ti servisi konkretno realizovani. Na primer, sloj 3 koristi usluge sloja
2, a prua usluge sloju 4.
Slika 2.4 4 Slojevi, protokoli i interfejsi
Treba istai da slojevita organizacija softvera nije karakteristina samo za mreni softver, ve
prestavlja jedan od bazinih principa u raunarstvu i ima sutinske slinosti sa konceptima
kao to su:skrivanje informacija, apstraktni tipovi podataka, enkapsulacija podataka,
objektno-orijentisano programiranje. Sutinska ideja u svim ovim sluajevima je da se na
konkretni softver (ili hardver) gleda kao na komponentu koja prua izvesne usluge svojim
korisnicima od kojih su sakriveni detalji njene unutranje strukture, pa i sam algoritam rada.
Ravnopravni (peer-to-peer) slojevi
Za slojeve mrenog softvera, osim vertikalne, karakteristina je i horizontalna povezanost

(predstavljena isprekidanim linijama na Sl. 4). Mrea se sastoji od velikog broja raunara (ili
maina), a na svakom od njih se izvrava funkcionalno identina kopija mrenog softvera.
Moemo razumeti da sloj n na raunaru Host_1, obavlja konverzaciju sa sebi ravnopravnim
(tzv. peer) slojem n na raunaru Host_2. Pravila ove konverzacije se zajednikim imenom
15
zovu protokol sloja n. U osnovi, protokol je dogovor izmeu dve strane o nainu na koji se
komunikacija odvija.
SLOJEVITOST MREA
Skup protokola i slojeva zove se arhitektura mree. Specifikacija
arhitekture mora da sadri dovoljno informacija.
U realnosti, podaci se ne prenose direktno izmeu peer slojeva. Umesto toga, svaki sloj
prosleuje podatke, zajedno sa odgovarajuim kontrolnim informacijama, sloju ispod, sve do
sloja najnieg nivoa (sloj 1). Ispod sloja 1 nalazi se fiziki medijum, kroz koji se obavlja stvarni
prenos podataka. Na odredinoj strani, podaci prolaze kroz slojeve, ali sada u obrnutom
redosledu, sve do odgovarajueg, ravnopravnog sloja.
Interfejs
Izmeu svakog para vertikalno-susednih slojeva egzistira interfejs. Interfejs definie

primitivne operacije i servise nieg sloja koji su dostupni viem sloju. Kada projektanti mree
donose odluku o tome koliko slojeva treba predvideti i koje e funkcije obavljati svaki od njih,
jedan od najvanijih problema odnosi se upravo na osmiljavanje interfejsa izmeu slojeva.
Cilj je definisati to je mogue jednostavniji interfejs koji e initi skup dobro-definisanih i lako
razumljivih funkcija. Takav jedan interfejs treba da minimizuje koliinu dodatnih informacija
koje se prenose izmeu slojeva i da omogui zamenu jedne realizacije sloja nekom drugom,
a da to ne zahteva bilo kakve promene u susednim slojevima.
Protokol stek
Skup protokola i slojeva zove se arhitektura mree. Specifikacija arhitekture mora da sadri
dovoljno informacija na osnovu kojih e programeri ili projektanti hardvera biti u stanju da
realizuju softver, odnosno hardver, za dati protokol. Specifikacija ne sadri detalje realizacije
slojeva i interfejsa izmeu slojeva, s obzirom da oni, budui da su sakriveni u mrenom
softveru, nisu vidljivi izvan maine. ak nije neophodna da interfejsi izmeu slojeva na svim
mainama u mrei budu identini, pod uslovom da svaka maina korektno koristi svaki sloj.
Skup protokola koje se koristi u nekom sistemu, jedan protokol po sloju, naziva se protokol
stek (protocol stack).
Slojevitost mrea
Dananje mree su izrazito kompleksni entiteti. Kako bi se savladala kompleksnost mrea,

mree i mreni softver se moraju kreirati hijerarhijski, uz postojanje velikog broja zasebnih,
precizno definisanih, nivoa tj. slojeva. Broj slojeva se razlikuje od mree do mree. Na svakom
sloju, sprovodi se odgovarajui protokol komunikacije. Protokol je dogovor dve strane o nainu
komunikacije. Naruavanje protokola ini komunikaciju nemoguom.
16
OSI REFERENTNI MODEL

OSI (Open System Interconnect) referentni model, ukazuje da se radi o
modelu povezivanja otvorenih sistema, odnosno sistema koji su
otvoreni za komunikaciju sa drugim sistemima.
OSI referentni model
OSI model prikazan je na Sl. 5 . OSI je standard uveden 1983. godine od strane meunarodne
organizacije za standardizaciju (ISO - International Standard Organization). Njegovo ime,
OSI (Open System Interconnect) referentni model, ukazuje da se radi o modelu povezivanja
otvorenih sistema, odnosno sistema koji su otvoreni za komunikaciju sa drugim sistemima.
U sutini, OSI predstavlja model za razumevanje i razvoj fleksibilnih, robusnih i otvorenih
mrenih arhitektura.Open Systems Interconnection OSI- model sa 7 slojeva, standardizovan
od strane ISO.
Slika 2.5 5 OSI referentni model
TCP/IP - model sa 4 sloja, prisutan u okviru Interneta. OSI model je razvijen pod okriljem
medunarodne organizacije za standardizaciju (ISO) i, iako se konkretni protokoli koje definie
vie ne koriste, predstavlja znaajan apstraktni opis mrea. Sa druge strane, TCP/IP model je
takav da se njegova apstraktna svojstva ne koriste znaajno, dok se konkretni protokoli
intenzivno koriste i predstavljaju osnovu Interneta. Slojevi u okviru referentnih modela i njihov
meusobni odnos, grafiki su prikazani na slici 6 (Slajdovi TCP-IP).
17
Slika 2.6 6 TCP/IP - model sa 4 sloja
SLOJEVI U OSI REFERENTNIOM MODELU

Transportni sloj je odgovoran za isporuku celokupne poruke od izvora
do odredita (tj. od-kraja-do-kraja).
Fiziki sloj se sastoji od osnovnih hardverskih mrenih tehnologija. Fiziki sloj ne definie
prenos logikih paketa podataka, ve naine prenosa sirovih bitova preko fizikog linka
izmeu vorova u mrei. Praktino, on odreuje naponske nivoe u elektrinim mreama,
specifikacije lasera u optikim vlaknima, specifikacije beine mree, itd... Data Link sloj
obezbeuje funkciju prenosa podataka meu vorovima u mrei i treba da obezbedi pouzdan
prenos podataka preko fizike mree. Media Access Control (MAC) pod-sloj se brine o
adresiranju i pristupu medijumu, dok seLogical Link Conrol (LLC) pod-sloj bavi protokolima i
kontrolom protoka (detekciju i ispravljanje greaka koji se mogu javiti na fizikom sloju).
Mreni sloj je zaduen za rutiranje i isporuku paketa. U njegovoj nadlenosti je kako e

poruka biti podeljena na pakete i tako preneta preko vie fizikih mrea. Sloj mree odgovoran
je za isporuku paketa od izvora do odredita koji se mogu nalaziti i u razliitim mreama (nisu
povezani na isti link). Ako su dva sistema povezana na isti link, obino ne postoji potreba za
mrenim slojem. Meutim, ako su sistemi povezana na razliite mree (linkove), sa ureajem
za meumreno povezivanje izmeu njih, mreni nivo je neophodan, a njegov zadatak je
da regulie protok paketa izmeu dva sistema. Kada peketi prelaze granice mrea, mogu
nastati brojni problemi. Fiziko adresiranje koje se koristi u drugoj mrei se moe razlikovati
od onoga koje vai u prvoj. Paket koji stie iz jedne mree moe biti previe veliki da bi se u
drugoj mrei preneo jednim okvirom. Mogu se razlikovati protokoli nieg nivoa. Na sloju mree
je da rei sve ove probleme.
Transportni sloj se brine o komunikacionim servisima izmeu krajnjih taaka. Njegov zadatak
je da obezbedi connection-oriented tok podataka, pouzdanost, kontrolu toka i
multipleksiranje. Transportni sloj je odgovoran za isporuku celokupne poruke od izvora do
odredita (tj. od-kraja-do-kraja). Mreni sloj iako obezbeuje prenos pojedinanih paketa
od izvora do odredita, ne vidi bilo kakvu vezu izmeu njih, ve svaki paket tretira kao
nezavisnu jedinicu; kao da je svaki paket posebna poruka, bez obzira da li je to i zaista sluaj
ili ne. Takoe, sloj mree, iako ine najvie ta moe, ne garantuje da e svaki paket biti
18
isporuen. to vie, ako paket bude izgubljen, npr. zbog zaguenja rutera, mreni sloj nikoga
nee obavestiti o tome.
SLOJ SESIJE
Sloj sesije obezbeuje mehanizme za rukovanje sesijom izmeu
krajnjih aplikacija. Komunikaciona sesija se sastoji od niza zahteva i
odgovora koji se javljaju izmeu aplikacija.
S druge strane, transportni sloj obezbeuje da celokupna poruka, u izvornom obliku, bude
prenesena do odredita, nameui kontrolu greaka i kontrolu protoka na nivou izvora i
odredita. Na primer, fajl transfer aplikacija ima zadatak da fajl proizvoljne veliine prenese
od fajl servera na host koji je traio fajl. U cilju prenosa kroz mreu, fajl e biti podeljen na
pakete, a svaki paket e se prenositi nezavisno. Neki paketi mogu biti primljeni sa grekom, a
neki izgubljeni u prenosu. Zadatak transportnog sloja je da uvede strogu disciplinu u isporuci
paketa kao bi fajl u prvobitnom obliku bio prenet do svog odredita. Na Sl. 7 je prikazan
odnos izmeu transportnog sloja i slojeva mree i sesije. Osnovna funkcija transportnog sloja
je da prihvati podatke od vieg sloja, podeli ih na manje jedinice, ako je to potrebno, prosledi
ih sloju mree i osigura da svi oni korektno stignu na drugi kraj. Dodatno, sve to mora biti
obavljeno efikasno i na nain koji e izolovati vie slojeve od eventualnih promena na niim
slojevima (uslovljenih recimo promenom hardvera mree).
Slika 2.7 7 Transportni sloj
Sutinska razlika izmeu transportnog i slojeva nieg nivoa je u tome to se nie nivoi bave
komunikacijom izmeu maine i njenih neposrednih suseda u mrei, dok transportni sloj
podrazumeva komunikaciju izmeu krajnjih maina, koje mogu biti razdvojene veim brojem
rutera. Da bi se olakala koordinacija izvora i odredita, na nivou transportnog sloja obino se
kreira konekcijaizmeu dve krajnje take komunikacije. Konekcija se moe razumeti kao
logika veza (ili putanja) za sve pakete koje se prenose u konkretnoj komunikaciji (sadrani u
konkretnoj poruci).
Sloj sesije obezbeuje mehanizme za rukovanje sesijom izmeu krajnjih aplikacija.

Komunikaciona sesija se sastoji od niza zahteva i odgovora koji se javljaju izmeu aplikacija.
Sloj sesije omoguava korisnicima na razliitim mainama da uspostave sesiju izmeu njih.
Sesija prua razliite servise, kao to su: upravljanje dijalogom (ko i kada moe da alje
podatke), kontrola pristupa zajednikim resursima (da bi se spreilo da dve strane u isto
vreme pokuaju izvoenje neke kritine operacije) i sinhronizacija (nadgledanje dugotrajnih
19
prenosa velikih fajlova za sluaj abnormalnog prekida kako bi se po ponovnom uspostavljanju

komunikacije prenos nastavio poev od take prekida).
PREZENTACIONI I APLIKACIONI SLOJ

Aplikacioni sloj korisnikim aplikacijama prua mrene usluge i daje
pristup informacijama na mrei. Sloj aplikacije je vrni sloj OSI modela.
Odnos izmeu sloja sesije i susednih slojeva, prezentacionog i transportnog, prikazan je na Sl.
8. Tipine funkcije sloja sesije su:Upravljanje dijalogom, Kontrola pristupa mrenim resursima
i Sinhronizacija.
Prezentacioni sloj je odgovoran za isporuku i formatiranje podataka aplikacionom sloju za

dalju obradu ili prikazivanje. On treba da otkloni brige aplikacionom sloju vezane za razliite
predstave podataka (na primer, razliite kodne strane, razliite enkripcije i drugo).
Prezentacioni sloj je zaduen za sintaksu i semantiku informacija koje se razmenjuju izmeu

dva sistema. U sloju prezentacije se obavljaju transformacije podataka koje su neophodne
kako bi se uskladili formati podataka, omoguilo racionalno korienje komunikacionog
kapaciteta mree i obezbedila sigurnost podataka.
Slika 2.8 8 Sloj sesije
Na Sl. 9 je prikazan odnos izmeu prezentacionog sloja i susednih slojeva, aplikacionog i sloja
sesije.
Aplikacioni sloj korisnikim aplikacijama prua mrene usluge i daje pristup informacijama
na mrei. Sloj aplikacije je vrni sloj OSI modela koji omoguava korisniku korienje usluga
mree. Svrha est niih slojeva je obezbeivanje pouzdanog prenosa podataka. Meutim,
prenos podataka, sam po sebi, nije krajnji cilj. Tek na aplikacionom nivou, mogunost razmene
podataka sa udaljenim korisnicima se uobliava u svrsishodne servise i aplikacije. Sloj
aplikacije obezbeuje interfejs i podrku za standardne servise kao to su elektronska pota,
pristup i prenos udaljenih fajlova, Web i dr.
20
Slika 2.9 9 Prezentacioni sloj
OSNOVNE FUNKCIJE SLOJEVA OSI REFERENTNOG

MODELA
Korisnik moe biti neka druga aplikacija koja se izvrava na istom
raunaru. U tom sluaju, interfejs nisu tastatura, mi i ekran ve skup
funkcija (servis) koje su na raspolaganju korisniku.
Napomenimo da korisnik ne mora biti ovek. Korisnik moe biti neka druga aplikacija koja
se izvrava na istom raunaru. U tom sluaju, interfejs nisu tastatura, mi i ekran ve skup
funkcija (servis) koje su na raspolaganju korisnikom programu. Na Sl. 10 su u saetom obliku
navedene osnovne funkcije slojeva OSI referentnog modela.
Slika 2.10 10 Pregled funkcija slojeva OSI modela
21
Poglavlje 3
WEB pregledava klijent strana
KOMPONENTE I TEHNOLOGIJE U PROJEKTOVANJU

VEB SISTEMA
Da bi se Web implementirao na Internetu koriste se dve glavne
komponente: Web pregledava i Web server.
World Wide Web (ili samo Web) je kolekcija ogromnog broja elektronskih dokumenata
sainjenih od povezanih Web stranica napisanih u HTML-u (Sl. 1). Stranice su raspoloive
korisnicima Web-a u vidu datoteka smetenih na milionima raunara distribuiranih po
Internetu. Svaka stranica moe sadrati pokazivae (tzv. linkove ili hiperveze) na druge
stranice koje mogu biti smetene na istom ili na nekom drugom raunaru (ili, u terminologiji
Web-a, Web sajtu). Klikom na link, korisnik prelazi na sledeu stranicu, a ovaj proces se moe
nastaviti u nedogled..
Slika 3.1 1 Web - distribuirana kolekcija povezanih dokumenata
Koncept stranica koja sadri pokazivae na druge srodne stranice naziva se hipertekstom.
Web pregledava (browser) je aplikacioni program koji korisnik (klijent) poziva da bi pristupio
stranici i prikazao je. Najpoznatiji Web pregledavai suInternet Explorer, Mozilla Firefox i
drugi. Web pregledava ima ulogu klijenta koji stupa u vezu sa odgovarajuim Web serverom
da bi dobio primerak navedene stranice. Pregledava pribavlja traenu stranicu, interpretira
tekst zajedno sa sadranim komandama za formatiranje, i prikazuje ga na ekranu monitora
raunara ili mobilnog ureaja. Primer stranice prikazan je na Sl. 2.
22
Poglavlje 3 WEB pregledava klijent strana
Slika 3.2 2 Primer Web stranice; (b) Stranica koja se uitava u pregledava klikom na link Internet and
Web Technologies
KLIJENT STRANA VEB SISTEMA

Pregledava pribavlja stranicu bez ikakve pomoi korisnika, a nova
stanica moe biti uzeta sa istog raunara sa kojeg je pribavljena i prva
ili sa nekog drugog raunaru.
Osnovni model rada Web-a prikazan je na Sl. 3. Na Sl. 3 vidimo pregleda koji na klijentskom
raunaru prikazuje Web stranicu. Kada korisnik klikne na liniju teksta koja je povezana
sa stranicom sa servera abcd.com, pregledava sledi link tako to serveruabcd.com alje
poruku kojom od njega trai zahtevanu stranicu. Kada dobije traenu stranicu, pregledava
je prikazuje. Ako ova nova stranica sadri link na stranicu sa servera xyzw.com, klikom
na ovaj link, pregledava e poslati zahtev ovom raunaru, i tako do u nedogled. Da bi
bio u mogunosti da prikae stranicu, pregleda mora da razume njen format. Kako bi se
obezbedilo da svi pregledai razumeju sve Web stranice, Web stranice se piu u standardnom
jeziku koji se zove HTML. Iako su pregledai u osnovi HTML interpretatori, veina pregledaa
poseduje brojne dodatne funkcije koji olakavaju navigaciju na Web-u. Po pravilu,
pregledavai poseduju podrku za bookmark-e, tj. kreiranje liste esto poseivanih stranica.
Slika 3.3 3 Komponente Web modela pregledava klikom na link Internet and Web Technologies
23
WEB PREGLEDAVA URL

Za sada, dovoljno je znati da se URL sastoji iz tri dela: ime protokola
(http), simboliko (DNS) ime raunara na kome je stranica locirana
(www.abcd.com), i ime datoteke koja sadri stranicu.
U osnovi, pregledava je program koji moe da prikazuje Web stranice i reaguje kada se
miem klikne neki objekat na stranici. Kada je objekat izabran, pregledava prati hipervezu
pridruen objektu i pribavlja izabranu stranicu. Jasno je da je za implementaciju hiperveze
neophodan nain za imenovanje stranica na Web-u. Za imenovanje stranica koriste se
ema poznata pod nazivom URL (uniformni lokator resursa). Tipian URL je oblika:
http://www.abcd.com/products.html
Pretpostavimo da je korisnik pretraujui Web pronaao link na Elektronski fakultet u Niu:
http://www.elfak.ni.ac.rs/home/index.html
Sledi niz koraka koje obavlja pregledava nakon izbora ovog linka:
1. Pregledava odreuje URL (na stranici, URL obino nije vidljiv ve je sakriven iza
teksta hiperveze)2. Pregledava se obraa DNS serveru traei od njega IP adresu hosta
www.elfak.ni.ac.rs .3. DNS server odgovara sa 160.99.1.14. Pregledava uspostavlja TCP
konekciju sa hostom 160.99.1.1 na portu 80.5. Preko otvorene TCP konekcije, pregledava
alje zahtev traei fajl /home/index.html.6. Server www.elfak.ni.ac.rs odgovara slanjem fajla
/home/index.html.7. TCP konekcija se zatvara.8. Pregledava prikazuje tekst sadran u falju
/home/index.html.9. Pregledava pribavlja i prikazuje sve slike iz ovog fajla.
ANATOMIJA WEB APLIKACIJE

Pod pojmom Web aplikacije podrazumeva se irok skup programskih
reenja koje kao korisniki interface koriste neki Web browser.
Pod pojmom Web aplikacije podrazumeva se irok skup programskih reenja koje kao
korisniki interface koriste neki Web browser.
Sve Web aplikacije funkcioniu po principu klijent server. Server predstavlja raunar na
kome je aplikacija smetena i koji u zavisnosti od zahteva korisniku isporuuje traeni
rezultat. Klijent moe biti bilo koji Web browser ili neki specijalno napravljeni klient program
koji kontaktira server da bi korisnik dobio rezultate. Elementarni oblik Web aplikacije jeste
obina Internet prezentacija.
Web aplikacije su obino predmet skepticizma i potcenjivanja kada su u pitanju mogunosti

realizacije nekih kompleksnih problema ili kreiranja nekog ozbiljnijeg software-a.
Kompletan softwareski dio Web aplikacije smeten je na serveru, i samim tim je dostupan na
korienje veem broju ljudi istovremeno.
Aplikacija je sigurna od krae, prepravljanja i uopte bilo kakvog uticaja na kod u onolikoj meri
u kojoj je i sam server siguran.
24
Znai, nema nikakve potrebe za komplikovanim instalacijama, voenja rauna o

kompatibilnosti i podeavanjima.
Nije potreban nikakav specijalni software za pristup aplikaciji, nema ogranienja da se mora
koristiti iskljuivo sa jednog raunara, a brzina komunikacije sa aplikacijom zavisi od brzine
kojom se pristupa serveru.
Klient aplikacija je Web browser (MS Internet Explorer, Mozilla,Opera) i obino je ukljuena u
okviru OS instaliranog na korisnikom raunaru.
Koristei Internet kao globalnu mreu, on-linekupovina, elektronsko bankarstvo, informacioni

sistemi u okviru firmi, turistike aplikacije i mnogi drugi sloeni sistemi bazirani su upravo na
Web aplikacijama.
Osnovne tehnologije za izradu Web aplikacija su HTML jezik za izradu statikih strana i
Server-Side Scriptingjezici za generisanje HTML koda, odnosno, izradu dinamikih strana.
Preuzimanje i prikaz statikih Web strane predstavlja jednu realizaciju klijent server
arhitekture, iji su akteri Internet pretraiva i Web server. Web server predstavlja softver, koji
se instalira na odreenom serveru koji upravlja zahtevima za pristup odreenoj Web stranici,
tako to postupa po zahtevu klijenta, isporuujui sadraj neke Web strane. Web server i
pretraiva komuniciraju razmenom poruka putem HTTP.
PROCEDURA RADA WEB APLIKACIJE

Rezultat rada Web aplikacije moe biti Web stranica, CSS, XML, slika,
video ili flash, koje Web server alje preko Interneta do raunara
klijenta.
Korisnik u web pregledava unosi adresu (URL) ili popunjava obrazac. Raunar korisnika alje
HTTP ili HTTPS zahtev preko Interneta Web serveru na kome se nalaze HTTP server, skripting
jezik ili Web aplikacija.
Web aplikacija analizira upueni zahtev i po potrebi:
povlai i/ili obrauje podatke dokumenata baze podataka komunicira sa drugim web
serverima ili web servisima priprema redirekciju na drugi web server (primer: CDN).
Rezultat rada Web aplikacije moe biti Web stranica, CSS, XML, slika, video ili flash, koje Web
server alje preko Interneta do raunara klijenta.
Web stranice mogu biti:
Statike - jednom formirane, vie se ne menjaju. Obine HTML stranice, za iji prikaz je
dovoljan samo web pregledava.
Dinamike-sadraj se menja u zavisnosti od interakcije sa klijentom Za generisanje su
potrebni Web server i skripting jezik (npr. PHP).
Osnovni gradivni elementi dinamike Web aplikacije su u mnogim aspektima analogni sa

dvoslojnim/troslojnim klijent/server arhitekturama. Zbog velikog broja i raznolikosti proizvoda
za ovu namenu, kao i OS, nije mogue obraditi sva potencijalna reenaja, pa je akcenat
stavljen na Windows OS i njemu pripadajue komponente SQL Server i II Server.
25
Klijent-server arhitektura predstavlja jedan od danas najee korienih pristupa kod

distribuirane obrade podataka. Koreni ove arhitekture nalaze se kod mejn-frejm raunara i na
njih prikljuenih terminala. Slinost sa mejn- frejm arhitekturom jeste postojanje jednog lana
sposobnog za izvravanje zadataka koji su van mogunosti ostalih lanova mree.
Postoje, meutim, bitne razlike izmeu ove dve arhitekture. Kod mejn-frejm arhitekture
terminali nemaju nikakvu mogunost obrade podataka, dok kod klijent-server arhitekture
klijenti od servera dobijaju podatke koje, zatim, koriste u lokalnom procesu obrade.
Zatim,mejn-frejm raunari predstavljaju autonomne lanove mree koji za proces obrade

podataka koriste lokalne resurse. Nasuprot tome, server se u vidu klijenta moe obratiti
drugim serverima u mrei za odreeni resurs ili distribuiranu obradu.
DVOSLOJNA I TROSLOJNA KLIJENT-SERVER

ARHITEKTURA
Veb aplikacije najee koriste troslojnu klijent-server arhitekturu na
takav nain da osnovni klijentski deo ini Veb brauzer.
Osnovna klijent-server arhitektura podrazumeva postojanje dva sloja - sloja klijenta i sloja
servera (slika 4). Kod dvoslojne klijent-server arhitekture softversko reenje se razlae na
jednu iskljuivo klijentsku, i jednu iskljuivo serversku komponentu. Primer osnovne,
dvoslojne klijent-server arhitekture jeste mrea u kojoj korisnici putem aplikacija na svojim
raunarima pristupaju centralnoj bazi podataka. U praksi su este i klijent-server arhitekture
sa tri sloja jer se njima lake reavaju pitanja zatite podataka i kontrole pristupa. Dvoslojna
klijent/server aplikacijase tipino sastoji od klijentskog softvera koji implementira korisniki
interfejs i komunikaciju sa bazom podataka, kao to je SQL Server, radi postizanja aurnosti
podataka.
Dakle grafiki korisniki intrerfejs se obavezno nalazi na klijentskoj maini, DBMS obavezno
na serveru, dok se poslovni deo sistema (sama obrada) moe nalaziti ili na klijentu ili na
serveru.
Slika 3.4 4 Dvoslojna klijent-server arhitektura
Na primer, Veb aplikacije najee koriste troslojnu klijent-server arhitekturu na takav nain
da osnovni klijentski deo ini Veb brauzer, srednji sloj ini aplikativni Veb server, a server baze
podataka ini trei, serverski sloj (slika 5).
U takvoj organizaciji srednji sloj je realizovan kao serverska komponenta, gledano sa aspekta
Veb brauzera, odnosno kao klijentska komponenta, gledano sa aspekta servera baze
26
podataka. Na primeru troslojne arhitekture jasno se moe stei uvid da se pojmovi klijent"
i server" ne odnose na hardverske karakteristike raunara, ve na tipove procesa, ili ak
njihove procedure, koji se na tim raunarima izvravaju. Ukoliko neki proces, ili jedan njegov
deo, zahteva uslugu od drugog procesa (bilo na lokalnom ili na udaljenom raunaru) njegovo
ponaanje spada u klijentski deo klijent-server arhitekture. I obrnuto, ukoliko neki proces
eka na zahteve drugih procesa, njegovo ponaanje spada u serverski deo klijent-server
arhitekture. Opte pravilo za odreivanje uloge kod klijent-server arhitekture definie da je
klijentska strana ona koja od druge strane zahteva uslugu, a da je serverska strana ona koja
eka na zahtev od druge strane i isporuuje odgovor na njega.
Slika 3.5 5 Troslojna klijent-server arhitektura
27
Poglavlje 4
Web server
ITERATIVNA OBRADA ZAHTEVA

Serveri sa iterativnom obradom zahteva oslukuju na dodeljenom
portu ekajui na zahtev klijenta.
Postoji veliki broj razliitih strategija za optimalno iskoriavanje procesorskih, memorijskih i

komunikacionih kapaciteta raunarskih sistema i mrea. Serveri se, u zavisnosti od naina na
koji rasporeuju obradu viestrukih zahteva, dele na:
1. servere sa iterativnom obradom zahteva i
2. servere sa konkurentnom obradom zahteva.
Serveri sa iterativnom obradom zahteva oslukuju na dodeljenom portu ekajui na zahtev

klijenta, kao to je prikazano na slici 1.Nakon prihvatanja zahteva klijenta zahtevi ostalih
klijenata se odbacuju ili ekaju u ulaznom baferu sve dok se prihvaeni zahtev ne obradi i
rezultati njegove obrade poalju natrag klijentu.
Slika 4.1 1 Iterativna obrada zahteva
Mana iterativne obrade zahteva je u tome to takav pristup moe znatno uticati na
performanse u smislu broja obraenih zahteva po jedinici vremena. Ukoliko obrada jednog
zahteva u toku svog izvrenja zauzme sve resurse servera, performanse se mogu smatrati
optimalnim. Meutim, ukoliko obrada zahteva oduzme dodatno vreme usled ekanja na
resurs (koji nije potreban za obradu ostalih zahteva, odbaenih ili koji ekaju u ulaznom
baferu), iterativni pristup pokazuje loije performanse od konkurentnog. Glavna prednost
iterativnog pristupa jeste eliminisanje problema konkurentnog pristupa internim resursima
servera.
Konkurentna obrada zahteva je pristup koji nudi bolje performanse od iterativnog pristupa
u situacijama u kojima server obrauje veliki broj zahteva od strane vie klijenata. Poboljanje
28
Poglavlje 4 Web server
pefromansi proizilazi iz mogunosti obrade vie zahteva paralelno. Paralelna obrada se

postie pokretanjem novog procesa (ili niti procesa, u zavisnosti od samog softvera i od
operativnog sistema) za obradu svakog klijentskog zahteva (Slika 2).
Slika 4.2 2 Konkurentna obrada zahteva
KONKURENTNA OBRADA ZAHTEVA

Komponente na server strani slue istoj svrsi kao i kod runo pisanog
programa i obino im se pristupa preko skript koda. Komponente za
pristup serveru i bazi podataka su osnovna graa.
Za ovakav pristup je potreban kompleksniji serverski softver koji se sastoji od dispeerskog

dela (dela koji je zaduen za prihvatanje zahteva i pokretanje procesa njihove obrade) i
dela koji je zaduen za obradu zahteva. Konkurentna obrada zahteva moe u odreenim
situacijama pokazati slabije performanse od iterativne obrade usled troenja procesorskog
vremena na pokretanje novih procesa za obradu zahteva. Takoe, softver koji omoguava
konkurentnu obradu je kompleksniji jer interno reava konkurentni pristup sistemskim
resursnima. Softver za konkurentnu obradu najee unapred pokree odreen broj procesa
za obradu zahteva a po potrebi taj broj poveava do konfiguracione vrednosti ili ogranienja
sistemskim resursima.
Veb je danas najpopularniji servis Internet mree. Naziv je dobio po prvom Veb brauzeru koji
je posedovao grafiki korisniki interfejs.
Veb je incijalno razvijen da omogui pristup hipertekstualnim dokumentima koji su se nalazili

na razliitim serverima. Vremenom su se pojavili programski jezici na strani servera koji
su omoguili kreiranje dinamikih dokumenata kao odgovora na specifine zahteve klijenta,
zatim tehnologije za razvoj aktivnih komponenata na strani klijenta protokoli za servisno
orijentisanu arhitekturu zasnovani na Vebu i slino.
Time je Veb sve vie postajao platforma za razvoj mrenih aplikacija tako da danas preti
da u potpunosti zameni tradicionalne desktop aplikacije. Aplikacija se implementira u nekoj
kombinaciji HTML(korisniki interfejs) i serverovog skript koda (povezuje se sa bazom
podataka). Komponente na server strani slue istoj svrsi kao i kod runo pisanog programa i
obino im se pristupa preko skript koda. Komponente za pristup serveru i bazi podataka su
osnovna graa Web-zasnovane aplikacije.
Na serverskoj strani najosnovniji element su servisi za rad nad podacima, ali pored njih
postoje i neki dodatni servisi kao to su HTTP Server(statike stranice) ili Internet Information
Server(dinamike kao na slici 3)
29
Slika 4.3 3 Komponente za pristup serveru i bazi podataka
OSNOVNE PREDNOSTI WEB APLIKACIJA

Osnovna prednosti Web aplikacija je kompatibilnost jedne aplikacije sa
razliitim hardverskim i softverskim platformama (PC, laptop, tablet,
Windows, Linux, Mac itd).
Osnovne prednosti Web aplikacija su:
Kompatibilnost jedne aplikacije sa razliitim hardverskim i softverskim platformama (PC,

laptop, tablet, Windows, Linux, Mac itd).
Auriranje i odravanje na serveru, bez potrebe da se distribuira i/ili instalira na
raunarima krajnjih korisnika.
Povoljnije za korienje kod organizacija sa velikim brojem korisnika.
Po kvalitetu su postale ravnopravne desktop aplikacijama.
HTML5 omoguava kreiranje bogatog interaktivnog okruenja u okviru web pregledavaa
(video, audio, vizuelni efekti).
Zauzima malo (ili nimalo) mesta na hard disku korisnika.
SaaS (Software as a service)
Neuporedivo nia cena u odnosu na desktop aplikacije.
Oteava softversko piratstvo i/ili reverse engineering.
Laka integracija sa drugim web servisima.
Omoguavaju da se program izvrava u programskim jezicima koje Web pregledavai ne
podravaju.
Daju mogunost da se programiraju dinamike Web aplikacije nezavisno od itaa, bez

pribegavanja programiranju na strani klijenta, pomou Java apleta, DHTML-a i ActiveX
kontrola
Omoguuje klijentu podatke koji su mu inae nedostupni.
esto ostvaruje bre vreme uitavanja.
Obezbeuje poboljane mere bezbednosti.
Vano je napomenuti da korienje dinamikih Web strana poveava optereenje
servera, naroito ukoliko njima pristupa vei broj korisnika.
30
Potrebna je vea inicijalna investicija u hardver web servera, koji se koriste za

generisanje dinamikih web strana.
Jezik koji se najee koristi za kreiranje dinamikih strana je PHP.
PHP je stekao popularnost zbog svoje jednostavnosti i sintakse nasleene iz programskog
jezika C.
Tokom vremena jezik se proirivao i sticao mogunosti za objektno orijentisano
programiranje, naroito od verzije 5.0.
TOK KOMUNIKACIJE
Ove instrukcije, kao to su PHP, JSP (Java), ASP (Visual Basic), itd.,
nazivamo skriptovima na strane servera (Server - Side Scripts), zato
to se izvravaju na Web serverima.
Za kreiranje instrukcija ija je namena automatsko generisanje HTML koda, na osnovu

parametara zahteva, koriste se razliiti programski jezici i njihove varijante, kao to su PHP,
JSP (Java), ASP (Visual Basic), itd. Ove instrukcije nazivamo skriptovima na strane servera
(Server - Side Scripts), zato to se izvravaju na Web serverima kao na slici 4.
Za kreiranje instrukcija ija je namena automatsko generisanje HTML koda, na osnovu

parametara zahteva, koriste se razliiti programski jezici i njihove varijante, kao to su PHP,
JSP (Java), ASP (Visual Basic), itd.
Slika 4.4 4 Tok komunikacije klijent-server
Ove instrukcije nazivamo skriptovima na strane servera (Server - Side Scripts), zato to se
izvravaju na Web serverima (Slika 5).
Slika 4.5 5 Skriptovi na strane servera (Server - Side Scripts)
31
TOK KOMUNIKACIJE-OBRADA SKRIPTA

HTML- razlika izmeu statinog Web-sajta i dinamike Web-aplikacije
ogleda se u nainu na koji se vri kretanje po HTML stranama.
HTML- razlika izmeu statinog Web-sajta i dinamike Web-aplikacije ogleda se u nainu na

koji se vri kretanje po HTML stranama (Slika 6 i 7).
->Statiki HTML sajt moe da se uporedi sa knjigom iji se sadraj i indeks ne nalazi na
jednom mestu, nego su delovi rasporeeni po tekstu.
-> Strane na statikom Web-u imaju slabo definisane meusobne odnose.
-> Svaka strana sadri veze (link) prema ostalim relevantnim stranama, ali sveukupno
kretanje kroz sajt je uglavnom odreeno od strane korisnika.
-> Web-aplikacija je vie okrenuta ka zadatku nego pretraivanju.
-> Veze vie deluju kao meni, nego kao indeks,a mogua odredita bilo sa koje strane
ograniena su operacijama koje mogu da se izvre sa te strane.
Slika 4.6 6 Tok komunikacije-statike strane
Serverski skript kod - jedan od osnovnih zadataka skript koda koji se sadri u HTML strani
(ili formi) je da sakupi podatke od korisnika i prosledi ih aplikaciji na serveru.
-> Jedan od prvih i najpopularnijih intrefejsa za podrku skript kodu je Common Gateway
Interface (CGI) protokol.
Glavni nedostaci ovog protokola su:
dinamike strane moraju da budu u celini konstruisane programski,
obrada greaka koja se ekskluzivno obavlja na server strani moe da degradira vreme
odziva kod sporih veza
32
Slika 4.7 7 Tok komunikacije-dinamike strane
TCP KONEKCIJE
Kada korisnik ukuca URL ili klikne na hipervezu, pretraiva analizira
URL i deo izmeu http:// i sledee kose crte tumai kao DNS ime iju IP
adresu trai od DNS servera.
Sa IP adresom na raspolaganju, pretraiva uspostavlja TCP konekciju na portu 80

odgovarajueg servera. Kroz otvorenu konekciju, pretraiva alje komandu koja sadri
preostali deo URL-a, tj. ime fajla na kontaktiranom serveru. Server vraa nazad fajl i
pretraiva ga prikazuje.
Web server moemo zamisliti kao program koji neprekidno, u petlji, obavlja sledei niz
aktivnosti:
1. Prihvata TCP konekciju od klijenta (pretraivaa).
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 mogunosti, ali u osnovi, rad Web servera
se svodi na prethodnu proceduru. Uoimo da svaki zahtev upuen od strane klijenta,
podrazumeva pristup hard disku radi uzimanja traenog fajla. Proseno vreme pristupa hard
diskova velike brzine rada iznosi oko 5 ms, to postavlja ogranienje na najvie 200 zahteva/
s (i manje ako se esto itaju veliki fajlovi). Za Web sajtove sa velikom brojem istovremenih
posetioca 200 zahteva/s je isuvie malo.
Jedno poboljanje koje se koristi kod svih Web servera podrazumeva da se u operativnoj
memoriji raunara kreira ke sa n najskorije korienim fajlovima. Pre nego to fajl potrai
na disku, server proverava ke. Ako je fajl u keu, tada nije potrebno pristupati hard disku
jer se fajl moe uzet direktno iz memorije. Iako je za efikasno keiranje potrebno rezervisati
relativno veliku koliinu operativne memorije kao i dodatno CPU vreme radi provere da li
se fajl nalazi u keu, uteda u vremenu obrade jednog zahteva je obino dovoljno velika da
kompenzuje dodatni troak.
Sledei nain za ubrzanje rada Web servera predvia uvoenje multithreading (vienitni rad).
Engleska re thread se prevodi kao nit, a pojam multithreading kao vienitni rad ili rad sa
vie niti u isto vreme. Procesi i niti su dva osnovna mehanizma za paralelno (konkurentno)
izvravanje programa. Programi koji imaju potrebu da istovremeno obavljaju vie poslova u
isto vreme mogu za svaki takav zadatak da kreiraju jedan proces koji e se izvravti uporedo
sa drugim procesima. Svaki proces poseduje svoju memoriju za uvanje svojih podataka. Nit
je u osnovi slian procesu, s tom razlikom da ne poseduje svoju spostvenu memoriju ve je
deli sa svim ostalim nitima kreiranim u istom programu.
33
MULTITHREAD WEB SERVER

Da bi se ostvarilo bilo kakvo poboljanje performansi VA u odnosu na
single-thread (jednonitni) model, neophodno je da sistem poseduje
vie vie pozadinskih modula i jednog hard diska.
Kod vienitnog rada server se sastoji iz jednog front-end (isturenog) pristupnog modula koji
prihvata sve dolazne zahteve i k pozadinskih modula koji obrauju zahteve (Sl. 8). Svih k+1
thread-ova pripada istom procesu i imaju pristup keu. Kada zahtev stigne, pristupni modul
ga prihvata i kreira jedan kratak zapis sa podacima o zahtevu kojeg predaje jednom od
trenutno raspoloivih pozadinskih procesa.
Slika 4.8 8 Multithread Web server sa pristupnim modulom i pozadinskim modulima
Pozadinski modul najpre proverava da je fajl koji trai prisutan u keu i ako jeste, u zapis
upisuje pokaziva na fajl.
Ako fajl nije u keu, pozadinski modul zapoinje operaciju prenosa fajla sa diska u ke (uz
eventualno izbacivanje nekih keiranih fajlova, ako u keu nema dovoljno prostora).
Nakon to je fajl prebaen u ke, zapis sa upisanim pokazivaem se vraa pristupnom moduli
koji preuzima fajl iz kea i prosleuje ga klijentu koji je uputio zahtev. Prednost opisanog
mehanizma je u tome to za vreme dok su jedan ili vie pozadinskih modula blokirani ekajui
na zavretak operacije itanja fajla sa diska (i zbog toga ne troe CPU vreme), ostali moduli
mogu biti aktivno upoljeni na obradi novih zahteva. Da bi se ostvarilo bilo kakvo poboljanje
performansi u odnosu na single-thread (jednonitni) model, neophodno je da sistem poseduje
vie od jednog hard diska.
U idealnom sluaju, propusna mo multithreadWeb severa sa k pozadinskih modula u sistemu

sa k diskova, moe biti k puta vea u odnosu na single-thread server i jedan disk.
34
MULTITHREAD WEB SERVER - POZADINSKI MODUL

Savremeni Web serveri, osim vraanja klijentu traenog fajla, obavljaju
i niz dodatnih operacija.
U zavisnosti od tipa pristiglog zahteva, pozadinski modul obavlja neki podskup sledeeg niza
aktivnosti:
1. Odreivanje imena zahtevane Web stranice iz URL-a.
2. Provera autentinosti klijenta
3. Provera prava pristupa klijenta.
4. Provera prava pristupa Web stranici.
5. Provera kea.
6. Pribavljanje zahtevane stranice sa diska.
7. Odreivanje MIME tipa koji e biti sadran u odgovoru koji se vraa klijentu.
8. Slanje odgovora klijentu.
9. Kreiranje zapisa u log fajlu.
Korak 1 je neophodan zato to primljeni zahtev ne mora sadrati stvarno ime fajla. Na
primer, razmotrimo URL http://www.elfak.ni.ac.rs, kod kojeg ne postoji ime fajla. U takvim
sluajevima, zahtev se odnosi na podrazumevani fajl (ije je ime obino default.html ili
index.html).
Takoe, pretraiva moe 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 traenoj stranici.
U koraku 4 proverava se da li je postoji neko ogranienje koje se odnosi na pristup samoj

stranici. Na primer, pristup stranici moe biti dozvoljen samo ako zahtev potie iz odreenih
domena (npr. stranica moe biti dostupna samo lokalnim korisnicima).
U koracima 5 i 6 vri se uzimanje stranice. Korak 7 podrazumeva odreivanje MIME tipa

stranice (na osnovu ekstenzije fajla, prvih nekoliko rei samog fajla ili na neki drugi nain).
U koraku 8, formira se odgovor koji se vraa klijentu, i na kraju u koraku 9, formira se zapis
o obraenom zahtevu i upisuje u jednu posebnu datoteku za voenje evidencije o pristupima
Web severu (tzv. log fajl). Zapis sadri informaciju o identitetu klijenta, domenu iz kojeg je
zahtev poslat, vreme prijema zahteva, ime zahtevane stranice itd.
35
MODEL FARME SERVERA

U sluajevima kada je broj zahteva koji se upuuje Web serveru u
jednoj sekundi veoma veliki, jedan CPU nee biti u stanju da obradi sve
zahteve, bez obzira na broj hard diskova se koriste.
U sluajevima kada je broj zahteva koji se upuuje Web serveru u jednoj sekundi veoma
veliki, koristi se model farme servera. Kod ovog modela, umesto jednog koristi se vie vorova
(raunara), od kojih svaki eventualno poseduje vie diskova (Sl. 9). Pretpostavka je da svi
raunari ukljueni u farmu servera poseduju sve Web stranice. Pristupni modul i dalje prihvata
zahteve, ali ih sad distribuira razliitim raunarima, a ne nitima u okviru jednog raunara. Na
ovaj nain, smanjuje se optereenje pojedinanih raunara.
Slika 4.9 9 Farma servera
Jedan problem koji se javlja kod farme servera posledica je nepostojanja zajednikog kea, jer
svaki vor poseduje svoju sopstvenu memoriju. Naime, moe se desiti da je traeni fajl
prisutan u keu nekog vora, a da je zahtev prosleen voru kod kojeg se fajl mora proitati sa
diska. U takvoj situaciji, vreme obrade zahteva je due nego to je to neophodno.
Takoe, nakon obraenog zahteva isti fajl e se nai u dva kea. Jedan nain za ublaavanje
gubitka u performansama zbog nepostojanja zajednikog kea 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 nain, pojedinani vorovi se specijalizuju za pojedine stranice tako da se ukupni

raspoloivi prostor u keu ne troi neracionalno za uvanje svakog fajla u svakom keu.
36
Poglavlje 5
URL
UNIFORM RESOURCE LOCATOR - UNIFORMNI

LOKATOR RESURSA
Kljuna pretpostavka Web-a je postojanje mehanizma za imenovanje i
lako lociranje stranica.
Web se sastoji od ogromne kolekcije dokumenata/stranica povezanih hipervezama, a

zapamenih u fajlovima koji su locirani na hiljadama servera distribuiranim po globalnom
Internetu. Imajui to u vidu, kljuna pretpostavka Web-a je postojanje mehanizma za
imenovanje i lako lociranje stranica. Konkretno, pre nego to izabrana stranica moe biti
pribavljena i prikazana u pretraivau, neophodno je odgovoriti na sledea tri pitanja:
1. Koje je ime stranice?
2. Gide se stranica nalazi?
3. Kako se stranici moe pristupiti?
Odgovor na ova tri pitanja sadran 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 raunara na kome je stranica locirana i
(c) lokalno ime koje na jedinstveni nain ukazuje na konkretnu stranicu (najee ime fajla na
hard disku u kome je stranica zapamena).
Na primer, URL Web stranica kursa Internet i Web tehnologije na Elektronskom fakultetu
u Niu je http://es.elfak.ni.ac.rs/iw/iw.htm i sastoji se iz tri dela razdvojenih kosim
crtama:protokol (http), DNS ime hosta (es.elfak.ni.ac.rs) 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.rs (iw/) i imena samog fajla (iw.htm).
Deo za ime fajla moe biti izostavljen iz URL-a (npr. samo http://es.elfak.ni.ac.rs). U tom
sluaju, Web server zahtev se preusmerava na glavnu (podrazumevanu) stranicu Web sajta.
Takoe, deo za ime fajla moe da sadri putanju do direktorijuma, ali ne i samo ime fajla
(npr. http://es.elfak.ni.ac.rs/iw/). U takvim sluajevima, Web server preusmerava zahtev na
podrazumevani fajl u tom direktorijumu (npr. http://es.elfak.ni.ac.rs/iw/index.htm). Kod
mnogih Web sajtova uvedene su skraenice za imena fajlova, koje poinju znakom ~. Na
primer, ime oblika ~ana/ zamenjuje kompletnu putanju do direktorijuma korisnika ana na
lokalnom raunaru.
37
Poglavlje 5 URL
Kao to je ve reeno, za komunikaciju izmeu Web klijenta (pregledavaa) i Web servera

koristi se TCP protokol.
TCP PROTOKOL
Kada korisnik ukuca URL ili klikne na hipervezu, pregledava analizira
URL i deo izmeu http:// i sledee kose crte tumai kao DNS ime iju IP
adresu trai od DNS servera.
Pregledava otvara TCP konekciju sa Web serverom, koja se potom koristi za prenos zahteva
od pretraivaa ka serveru, a onda i za prenos odgovora (koji sadri traenu stranicu) od
servera do pretraivaa.
Meutim, TCP protoko se koristi samo za transport zahteva i odgovora, dok su pravila
konverzacije i formati poruka koje se razmenjuju izmeu pretraivaa i Web servera
regulisana posebnim aplikacionim protokolom. ta vie, ne postoji samo jedan, ve se za
ovu namenu mogu koristiti razliiti aplikacioni protokoli koji su specijalizovani za prenos
specifinih tipova resursa. Ime protokola koji se koristi za pristup stranici navedeno u
poetnom delu URL-a.
Delimian spisak protokola koji se mogu koristiti kao deo URL-a, naveden je u tabeli sa Sl. 1.
Slika 5.1 1 Protokoli koji se mogu korisiti u URL-u
Protokol HTTP je osnovni protokola Web-a i koristi se za komunikaciju Web klijenta i Web
servera. Vie detalja o ovom protokolu bie dato u sledeoj 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 najrazliitije fajlove.
ta vie Web je olakao korienje FTP-a, s obzirom na to da je pristup FTP serveru preko Web
pregledavaa laki, od pristupa putem osnovnog FTP korisnikog interfejsa. Takoe, FTP, za
razliku od HTTP, omoguava prenos fajlova u oba smera, kako od servera do klijenta, tako i od
klijenta do servera.
38
Poglavlje 5 URL
FTP PROTOKOL
URL je osmiljen ne samo da omogui korisnicima navigaciju na Web-u,
ve i korienje drugih mrenih servisa (FTP, news, Gopher, e-mai i
telent) na uniforman nain.
Protokol file omoguava pristup lokalnim fajlovima i prikazivanje njihovog sadraja u

pretraivau, na isti nain kao Web stranica. Ovaj pristup je slian FTP-u, ali ne zahteva FTP
server. Naravno, primenljiv je samo na fajlove koji se nalaze na lokalnom hard disku raunara.
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 najrazliitije teme tako to
postavljaju i itaju lanke koji se odnose na temu konkretne grupe. Protokol news omoguava
da se lanku iz grupe za razmenu vesti pristupa na isti nain kao i Web stranici.
Gopher je protokol koji se nekada koristio u istoimenom sistemu za pronalaenje informacija

na Internetu, koji se smatra preteom Web-a. Konceptualno, Gopher je slian Web-u, ali
podrava samo tekst, a ne i slike. Danas se smatra zastarelim i nije vie u upotrebi.
Protokol mailtoomoguava korisnicima da putem Web pretraivaa alju elektronsku potu.

Dovoljno je u polje za unos hiperlinka upisati mailto: i e-mail adresu primaoca. Veina Web
pretraivaa, u ovakvoj situaciji, otvara program za slanje elektronske pote sa popunjenim
poljima za e-mail adresu.
Protokol telnet, kao to znamo, koristi se za uspostavljanje konekcije sa udaljenim hostom.

Slino kao u sluaju mailto protokola, upisivanjem telnet: zajedno sa IP adresom udaljenog
hosta u polje za unos hipelinka, otvara program za rad TELNET protokolom.
39
Poglavlje 6
Statiki Web dokumenti
HTML JEZIK
Osnova Web-a jeste prenos Web stranica od servera do klijenta.
U svom najjednostavnijem obliku, Web stranicesu statike, tj. datoteke smetene na nekom
serveru koje ekaju da budu zatraene i koje se, bez bilo kakvih izmena, dostavljaju klijentu.
Posmatrano na ovaj nain, i za sadraje kakvi su video i audio se moe rei da predstavljaju
statike Web stranice jer se preuzimaju kao datoteke.
Web stranice se piu u jeziku koji se zove HTML (HyperText Markap Language hipertekstualni
markerski jezik). Pomou HTML-a projektant (dizajner) Web stranica moe da kreira Web
stranice koje sadre tekst, grafiku i hiperveze ka drugim Web stranicama. Pojam markap
language(markerski jezik) znai da HTML slui za opis naina na koji su dokumenti
formatirani, odnosno kako e biti prikazani u Web pretraivau. HTML definie skup komandi
za formatiranje koje, ugraene u prvobitni tekst dokumenta, daju uputstva za prikazivanje
sadraja dokumenta.
Komande se nazivaju oznakama ili tagovima (od eng. tag) i uokvirene su znakovima manje od
i vee od. Neki tagovi se javljaju u parovima, a odnose se na sve stavke koje se nalaze izmeu
uparenih oznaka. Na primer, u HTML-u,<b> znai poetak, 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 poinje tagom <head>, a zavrava se tagom</head>,
dok telo poinje tagom <body> i zavrava se tagom </body>. Tekst unutar taga se naziva
direktivom. Veina HTML tagova ima identian format; koriste <neto> da oznae poetak
neega i </neto> da oznae njegov kraj. Veina pretraivaa poseduje opciju, obino
nazvanu View Source. Izborom ove opcije, prikazuje se izvorna verzija tekue HTML
stranice, umesto njenog formatiranog izgleda.
Tagovi se mogu pisati bilo malim bilo velikim slovima. Tako, <head> i <HEAD> znae isto.
Formatiranje samog HTML dokumenta je irelevantno. HTML parser (deo pretraivaa koji
interpretira HTML) ignorie dodatne blanko znake (razmake) i prelaske u novi red. To znai
da se razmaci mogu slobodno koristiti kako bi se HTML dokument uinio itljivijim. Meutim,
prazne linije, s obzirom na to da se ignoriu, ne mogu se koristiti za razdvajanje paragrafa,
ve se za tu namenu moraju koristiti posebni tagovi.
ULOGA TAGOVA
Za svaki tag, postoji definisani skup dozvoljenih parametara
40
Poglavlje 6 Statiki Web dokumenti
Pojedini tagovi imaju parametre, koji se nazivaju atributima. Na primer,
<img src=abc alt=slika>
je tag, <img>, sa parametrima srci alt. Vrednost parametra srcje postavljena na abc, a
parametra altna slik a. S obzirom na to da su parametri imenovani, redosled navoenja
parametara u tagu nije od znaaja.
Za pisanje specijalnih karaktera (koji ne pripadaju ASCII skupu karaktera), u HTML se koristi
posebna sintaksa. Specijalni znak poinje znakom &, zavrava se znakom ;. Na primer,
oznaava blanko znak, è oznaava è, a è Irish. Za
predstavljanje znakova <, > i &, koji imaju posebno znaenje u HTML-u, koristi se:&lt,
&gt i &amp, respektivno.
Glavna stavka u zaglavlju HTML dokumenta je naslov, omeen tagovima <title> i </title>.
Naslov se ne prikazuju na stranici, mada se kod nekih pretraivaa prikazuje kao naslov
prozora stranice. U tabeli na Sl. 1 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> oznaava glavni
naslov, a <h6> naslov namanje vanosti. Oblik u kojem e naslovi biti prikazani, shodno
nihovom nivou, zavisi od pretraivaa.
Tipino, tekst naslova vieg nivoa (sa manjom brojnom vrednou) ispisuju se veim i teim
fontom. Takoe, pretraiva moe da koristi razliite boje za prikaz naslova razliitih nivo.
Obino, naslovi oznaeni tagom <h1> ispisuje se veim i masnim slovima i sa barem jednom
praznom linijom iznad i ispod naslova. Naslovi omeeni tagom <h2> ispisuju se manim
fontom sa manjim razmakom iznad i ispod teksta naslova, itd. Tagovi <b> i <i> se koriste za
oznaavanje teksta koji treba ispisati masnim (bold) i iskoenim (italic) slovima, respektivno.
Slika 6.1 1 Spisak najznaajnijih HTML tagova
UPOTREBA TAGOVA
HTML prua vie razliitih naina za kreiranje listi, ukljuujui i
ugnjedene liste.
41
Liste se zapoinju tagom<ul> ili<ol>, a tag <il> se, u oba sluaja, koristi za oznaavanje
poetka stavki u listi. Tag <ul> oznaava poetak nenumerisane liste. Pojedinane stavke
ovakve liste (omeene tagovima<il> i </il>) prikazuju se sa znakom na poetku. Za
numerisane liste (omeene tagom <ol>), umesto simbolom , stavke se prilikom ispisivanja
u pretraivau oznaavaju rednim brojevima.
Tagovi <br>, <p> i <hr> se koriste za ragranienje delova teksta. Tag <br> lomi liniju teksta
(prelazak u novi red). Tag<p> oznaava poetak novog paragrafa, to moe znaiti umetanje
jedne prazne linije ili uvlaenje prve linije novog paragrafa. Konano, tag <hr> prekida tekuu
liniju teksta i u novoj liniji crta horizontalnu liniju celom duinom stranice.
Osim teksta, Web stranice pisane u HTML-u mogu sadrati i slike. Za umetanje slika na tekuu
poziciju ne stranici koristi se tag <img>. Ovaj tag moe imati vie parametara. Parametar
src sadri URL slike. HTML ne propisuje dozvoljene grafike formate slika. U praksi, svi
pretraivai podravaju grafike formate GIF i JPEG.
Stranica moe sadrati i sliku u nekom drugom formatu (npr. BMP), da li e takva slika biti i
prikazana u pretraivau zavisi od sposobnosti pretraivaa da barata konkretnim formatom.
Parametar taga <img>, align, definie poravnanje slike u odnosu na tekst (top, middle,
bottom). Parametar alt omoguava da se umesto slike moe prikazati tekst, ukoliko korisnik
zabrani pretraivau da prikazuje slike. Konano, parametar ismap, ukazuje da se radi o
aktivnoj slici, tj. slici mapi. Za oznaavanje hiperveza koristi se tagovi <a> i </a>. Slino
tagu <img>, tag <a> moe sadrati vie parametara, kao to su href (za URL) i name (za ime
hiperveze). Tekst uokviren tagovima <a> i </a> se prikazuje, a klikom na tekst pretraiva
prelazi na novu stranicu iji je URL naveden u parametru href. Takoe, dozvoljeno je umesto
teksta navesti sliku (tag <img>). U tom sluaju, hiperveza se aktivira klikom na sliku.
Na primer, razmotrimo sledei fragment HTML teksta: <a href="http://www.nasa.gov">

NASA's home page </a>, koji se u retraivau prikazuje kao: NASA's home page.Ako korisnik
klikne na ovaj tekst, pretraiva e pribaviti i prikazati stranicu iji je URL:
http://www.nasa.gov .
JO O UPOTREBI TAGOVA
Za svaki tag, postoji definisani skup dozvoljenih parametara, npr. za
hiperveze, tabele i dr.
Parametar name tag <a> se koristi za hiperveze koje ukazuju na pojedine sekcije same
stranice. Na primer, na poetku mnogih Web stranica nalazi se sadraj stranice (slino
sadraju knjige). Klikom na stavku iz sadraja, korisnik ima mogunost da se brzo pozicionira
na odgovarajuu sekciju stranice.
HTML je jezik koji evoluira. Starije verzije HTML-a, 1.0 i 2.0, nisu predviale tabele. Podrka
za tabele uvedena je u veziji HTML 3.0. HTML tabela se sastoji iz jedne ili vie vrsta od
kojih svaka sadri jednu ili vie elija. elije mogu sadrati tekst, slike, ikone, fotografije, pa
ak i cele tabele. elije se mogu spajati u vee elije koje zauzimaju vie kolona i/ili vrsta.
Iako autor stranice ima mogunost izvesne kontrole nad izgledom tabele (definie poravnanje
sadraja elija, stil okvira tabele, margine teksta u eliji), konani izgled tabele zavisi od
naina na koji pretraiva interpretira HTML opis tabele.
42
Na Sl. 2 (a) je dat primer HTML-a koji ilustruje osnovne karakteristike HTML tabela, a na Sl. 2
(b) odgovarajui prikaz u pretraivau. Kao to se moe videti celokupna tabela je omeena
tagovima <table> i </table>. Tag <caption> sadri tekst naslova tabele. Svaka vrsta poinje
tagom <tr>, dok su pojedinane elije oznaene tagom <th> ili <td>..
elije oznaene tagom <th> (Table Header) odgovaraju nslovnim elijama kolona, dok one
oznane tagom <td> (TableData) predstavljaju unutranje elije tabele, tj. one koje sadre
podatke. Prilikom kreiranja tabela dozvoljeno je koristiti brojne atribute, kako bi se definisalo
horizonalno i vertikalno poravnanje elija, poravnanje unutar elije, nain crtanja okvira,
grupisanje elija itd
Slika 6.2 2 (a) HTML tabela; (b) prikaz tabele
PRAVLJENJE FORMI
Forma je uokvirena tagovima
&amp;amp;amp;lt;form&amp;amp;amp;gt; i
&amp;amp;amp;lt;/form&amp;amp;amp;gt;.
Na Sl. 3 (a) je dat primer HTML koda koji ilustruje osnovne mogunosti formi. Odgovarajui
prikaz u pretraivau dat je na Sl. 3 (b).
Forma je uokvirena tagovima <form> i </form>. Obuhvaeni tekst, koji nije deo nekog
taga, se prikazuje kao i tekst sadran u telu stranice. Pri tome, dozvoljeno je korienje svih
uobiajenih tagova (npr.<b>). Forma sa Sl. 3 (a) sadri tri vrste <input> box polja: polja za
unos teksta, kvadrate za tikliranje i nekoliko radio dugmadi. Prvo polje u formi definie polje
za unos teksta veliine (size) 46 karaktera predvieno za upis imena korisnika. Uneti string
se pamti u promenljivoj kupac radi kasnije obrade.
Tag<p> nalae pretraivau da tekst i box polja koja slede prikae u novoj linij. Uz pomo
tag <p> i slinih, autor forme moe da kontrolie raspored polja i teksta na formi. Sledea
linija forme definie polja za unos adrese i mesta stanovanja kupca. Prvo polje je veliine 40,
a drugo 14 karaktera. Naredna linija predviena je za unos podataka o kreditnoj kartici koju
kupac koristi za plaanje. Za broj kartice i datum kada istie vaenje kartice koriste se polja
43
za unos teksta, dok se tip kartice bira pomou novog tipa polja, tzv. radio dugmeta. Radio
dugmad se koriste kada treba obaviti izbor izmeu dve ili vie alternativnih opcija.
Slika 6.3 3 (a) HTML kod forme; (b) prikaz forme
VERZIJA HTML 4.0

U verziji HTML 4.0 uvedene u dodatne mogunosti, kao to su podrka
za olakano korienje Web stranica osobama sa hendikepom,
ugradnja objekata, podrka za skript jezike i druge.
U sluajevima kada je Web sajt sloen i sadri veliki broj stranica koje kreiraju razliiti autori
koji rade za istu kompaniju, poeljno je da postoji nain za unifikaciju izgleda (stila) razliitih
stranica. Ovaj problem se moe reiti korienjem kaskadnih style sheet-ova - CSS. Stranice
koje se oslanjaju na pridrueni style sheet ne moraju vie da sadre iskljuivo tzv. fizike
stilove (kao to su npr. <b> za bold ili <i> zaitalic). Umesto toga, autori koriste logike
stilove definisane u style sheet-u; npr. <nr> (za normalan tekst), <em> (za naglaen tekst),
<strong> (za jako naglaen tekst). Nain prevoenja logikih stilova definisan je u style
sheet -u koji se referencira na poetku svake stranice. Na ovaj nain, sve stranice imae
identian stil, a da bi se promenio stil svih stranica dovoljno je promeniti definiciju stila u
style sheet-u. Na primer, ustyle sheet-u moe biti definisano da se logiki stil <strong>
prikazuje u plavoj boji u italic fontu veliine 14-point-a. Ako je potrebo promeniti stil tako da
se tekst oznaen sa <strong> prikazuje u ruiastoj boji, bold fontom veliine 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.
44
Forme
HTML 1.0 je omoguavo samo jednosmernu komunikaciju. Korisnik je mogao da dobije

traenu stranicu od servera, ali je teko mogao da vrati nazad povratnu informaciju. Kako
je sve vei broj komercijalnih organizacija poinjalo da korisni Web, tako su rasli zahtevi
za dvosmernim saobraajem. Na primer, javila se potreba za popunjavanjem narudbenica
preko Web-a, registracijom korisnika, postavljanjem upita za pretraivanje baze podataka itd.
Ovi i slini zahtevi doveli su do uvoenja formi, ve u verziji HTML 2.0. Forme sadre box
polja (ili dugmad) koja korisnik moe da popuni traenim podacima ili uini izbor izmeu vie
ponuenih opcija i unetu informaciju vrati vlasniku stranice. Za ovu namenu koristi se tag
<input>. Ovaj tag poseduje vei broj parametara uz pomo kojih se regulie veliina, priroda i
upotreba polja. Nejee se koriste polja za unos teksta, kvadrati za tikliranje, aktivne mape
i dugme Submit.
JO O PRAVLJENJU FORMI
U pretraivau, radio dugme se prikazuju na nain koji omoguava
korisniku da klikom na dugme moe da izabere ili poniti izbor
odgovarajue opcije.
Radio dugmad se koriste i za izbor tipa poveza. Sva radio dugmad sa istim imenom pripadaju
istoj grupi. Tako, sva radio 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 dobie jednu od dve vrednosti mastercard ili visacard. Posle grupe
radio dugmadi za izbor poveza, sledi opcija za isporuku brzom potom, predstavljena tzv.
kvadratom za tikliranje (checkbox). Kvadrat za tikliranje moe biti ukljuen ili iskljuen. Za
razliku od radio dugmadi gde samo jedno dugme iz grupe moe 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 obino koristi za unos
lozinke, identian 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 takoe varijanta
polja za unos teksta, koja, za razliku od osnovnog tipa moe sadrati vie linija teksta.
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 definie vrednou submit parametra type. Vrednost
parametra value predstavlja tekst koji se prikazuje kao natpis dugmeta.
Kada korisnik klikne na Submit dugme, pretraiva pakuje informacije prikupljene sa forme
u jednu dugaku 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 moe biti
oblika:
45
kupac=Petar+Petrovic&ulica=Beogradska+14&mesto=Nis&cardno=1234567890&istice=9/
07&cc =mastercard&povez=tvrdi&express=on
Na serveru je da protumai dobijeni string i preduzme odgovarajue akcije.
46
Poglavlje 7
XML i XSL
XML - POBOLJANJE HTML-A

Organizacija W3C, koja se bavi razvojem Web-a i standardizacijom
protokola za Web, razvila je poboljanje HTML-a koje omoguava
struktuiranje Web stranice.
HTML, sa ili bez formi, ne bavi se struktuiranjem podataka na Web stranici niti razdvaja
sadraj 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 sadraja od naina prikazivanja (formatiranja). Na primer, zamislimo program
koji pretrauje Web u potrazi za najjeftinijom knjigom ili CDom.
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 teko moi da zakljui gde se na stranici nalazi
traena informacija.
Konkretno, uvedena su dva nova jezika. Prvi, XML (eXtesible Markup Language) opisuje Web
sadraj na struktuirani nain, dok drugi, XSL (eXtensible Style Language) opisuje formatiranje
Web stranice nezavisno od njenog sadraja. Budui da se radi o obimnim i sloenim jezicima,
u nastavku e biti izloena samo njihova osnovna ideja. Razmotrimo XML dokument sa Sl.
1. 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 omoguava kreiranje mnogo sloenijih struktura od one prikazane na
Sl. 1.
Na primer, dozvoljeno je da struktura sadri viestruka polja (npr. vie od jednog autora
knjige), opciona polja (npr. Naslov prateeg CD-ROM-a), alternativna polja (npr. URL knjiare,
ako knjiga nije rasprodata ili URL sajta za aukcijsku prodaju, ako je knjiga rasprodata). S
obzirom na to da XML tagovi ukazuju na smisao informacije koje sadre, XML dokument se
moe lako pretraivati, npr. da bi se pronale sve knjige datog autora.
47
Poglavlje 7 XML i XSL
Slika 7.1 1 Primer Web stranice u XML-u
XSL - POBOLJANJE XML-A

Da bi se definisao nain formatiranja dokumenta, neophodan je jo
jedan fajl, book_list.xsl, napisan u jeziku XSL, koji e objasniti
pregledavau kako da prikae podatke iz XML-a.
Razmotrimo XML dokument sa Sl. 1. 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 omoguava kreiranje mnogo
sloenijih struktura od one prikazane na Sl. 1. Na primer, dozvoljeno je da struktura sadri
viestruka polja (npr. vie od jednog autora knjige), opciona polja (npr. Naslov prateeg
CD-ROM-a), alternativna polja (npr. URL knjiare, ako knjiga nije rasprodata ili URL sajta za
aukcijsku prodaju, ako je knjiga rasprodata). S obzirom na to da XML tagovi ukazuju na smisao
informacije koje sadre, XML dokument se moe lako pretraivati, npr. da bi se pronale sve
knjige datog autora.
U primeru sa Sl. 1, sadraj svakog od tri polja, autor, naslov i godina, se tretira kao nedeljiva
informacija. Meutim, ako je potrebno, recimo radi preciznije pretrage, dozvoljeno je polja
razloiti na podpolja. Na primer, polje za ime autora, se moe 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 omoguava pretraivanje samo po imenu ili samo po
prezimenu autora. U optem sluaju dubina podele moe biti proizvoljna. Dokument sa Sl. 13
sadri spisak od tri knjige. Meutim, sam dokument na govori nita o tome kako jednu ovakvu
Web stranicu treba prikazati u pretraivau. objasniti pretraivau kako da prikae podatke
iz XML dokumenta. Na Sl. 2 je prikazan primer XSL fajla za formatiranje XML dokumenta sa
Sl. 1.
48
Poglavlje 7 XML i XSL
Slika 7.2 2 Primer XSL fajla
JO O XSLU
Drugim reima, pretraiva generie HTML tabelu popunjenu podacima
o svim knjigama iz XML dokumenta.
U primeru sa Slike 14, sekcija:
<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>
je analogna fornaredbi iz C-a, gde prva linija odgovara zaglavlju, pet unutranjih linija telu, a
poslednja oznaci za kraj for petlje. Kada pretraiva, koji interpretira dati XSL fajl, on prolazi
jedanput kroz petlju za svaku knjigu iz pridruenog XML dokumenta i u svakom prolasku
generie pet linija oblika: <tr> naslov, autor, godina </tr>.
Krajnji rezultat je isti kao da se prikazuje HTML stranica koja sadri tabelu popunjenu
podacima o tri knjige. Meutim, XML/XSL predstavlja daleko fleksibilnije reenje. 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 proiriti definiciju
tabele novim vrstama). S druge strane, ako treba promeniti nain prikazivanja potrebno
je modifikovati XSL fajl, ali ne i XML dokument. Drugo, program koji na Web stranici trai
informacije o nekoj knjizi, analizira XML dokument. S obzirom na to da XML dokument sadri
tagove koji ukazuju na smisao podataka i nije optereen tagovima za formatiranje, njega je
mnogo jednostavnije analizirati od odgovarajueg HTML dokumenta. Treba napomenuti da
iako XSL fajl sadri neku vrstu programskih konstrukcija, Web stranice napisane u XML i XSL
su i dalje statike. Naime, kao i HTML i XSL daje samo instrukcije Web pretraivau kako da
prikae stranicu. Naravno, upotreba XML/XSL-a podrazumeva da je pretraiva u stanju da
interpretira XML i XSL, to je danas sluaj sa gotovo svim pretraivaima.
49
Poglavlje 8
Dinamiki i aktivni Web dokumenti
DINAMIKI DOKUMENTI
Model Web-a opisan u prethodnim sekcijama podrazumeva da klijent
alje serveru ime fajla, a server odgovara slanjem klijentu statiki
sadraj traenog fajla.
U poetnom periodu razvoja Web-a celokupan sadraj dostupan na Web-u bio je statiki
(sadran u fajlovima koji se bez bilo kakve modifikacije transportuju do klijenta). Meutim,
u novije vreme, sadraj koji se moe preuzeti sa Web-a postaje u sve veoj meri dinamiki,
tj. ne postoji u unapred definisanom obliku, ve se kreira na zahtev. Generisanje sadraja
Web stranica moe se obaviti bilo na strani servera bilo na strani klijenta. U prvom sluaju,
tzv. dinamiki dokumenti, Web server, po prijemu zahteva, pokree odgovarajui aplikacioni
program koji kreira dinamiki dokument, a klijentu vraa izlaz programa (Sl. 1 (a)).Drugim
reima, kao odgovor na svaki zahtev klijenta, na strani severa se kreira nova verzija HTML
dokumenta. Krajnje jednostavan primer dinamikog dokumenta je preuzimanje tekueg
vremena i datuma od servera. Vreme i datum su primer dinamike (promenljive) informacije
koja se menja iz momenta u moment. Na primer, klijent moe da zahteva od servera da izvri
program koji ita sistemsko vreme serverskog raunara. Program konvertuje informaciju o
vremenu u tekst, formatira tekst pomou HTML tagova i generisani HTML dokument predaje
Web serveru koji ga vraa nazad klijentu.
Slika 8.1 1 (a) dinamiki dokument; (b) aktivni dokument
50
Poglavlje 8 Dinamiki i aktivni Web dokumenti
JO O DINAMIKIM DOKUMENTIMA
Tradicionalni, i danas ve zastareli nain za procesiranje HTML formi i
drugih interaktivnih Web stranica zasnovan je na sistemu koji se zove
CGI (Common Gateway Interface).
U drugom sluaju, tzv. aktivni dokumenti, Web stranica osim statikog sadraja (HTML,
slike i sl.) sadri i program koji se nakon uitavanja stranice izvrava na strani klijenta
(u pretraivau). Na primer, zamislimo da elimo da kreiramo Web stranicu koja sadri
animiranu grafiku ili interaktivni grafiki interfejs. Sobzirom na to da HTML regulie samo
prikaz sadraja stranice na ekranu pretraivaa, neophodan je poseban program koji e
kreirati animacije ili omoguiti neku specifinu interakciju sa korisnikom. Takoe, jasno je da
se takav jedan program mora izvravati na raunaru klijenta, tj. tamo gde se odvija interakcija
sa korisnikom. Uvek kada klijent zahteva aktivni dokument od servera, server alje kopiju
dokumenta sa sadranim program koji se po uitavanju izvrava u pretraivau (Sl. 1 (b)).
Potreba za generisanjem dinamikih dokumenata na strani servera najlake se moe

sagledati ako razmotrimo korienje HTML formi na ranije opisani nain. Kada korisnik popuni
formu i klikne na dugme Submit, pretraiva alje serveru poruku sa sadrajem forme
zajedno sa poljima koje je korisnik popunio. Oigledno, ova poruka nije ime fajla koji treba
vratiti klijentu, ve se sadraj poruke prosleuje odgovarajuem programu radi procesiranja.
Obino, obrada na strani servera podrazumeva pristup bazi podataka (smetenoj na hard
disku servera) radi upisa dostavljenih podataka ili itanja zapisa koji odgovaraju dostavljenim
podacima i generisanje HTML stranice koja sadri odgovor koji se vraa klijentu. Na primer,
poto 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 pokree program iji
je zadatak da kreira HTML stranicu narudbenice, koja e osim naziva i cene izabranih stavki
sadrati i ukupnu cenu, PDV, ime i adresu korisnika i sl. Uz to, od programa se oekuje i da
podatke o izdatoj narudbi upie u bazu podataka. Na Sl. 2 su prikazani koraci koji su potrebni
za obradu podataka unetih u HTML formu.
Slika 8.2 2 Obrada HTML forme dinamikog dokumenta
HTML STRANICA SA UGRAENIM PHP-OM

CGI (Common Gateway Interface - opti interfejs pristupa) predstavlja
standardizovani interfejs koji omoguava Web serveru da razgovara
sa pozadinskim programima.
51
Po pravilu, pozadinski programi su skripte napisane u jeziku Perl. Drugi uobiajeni nain za
generisanje dinamikog sadraja podrazumeva umetanje skripti unutar same HTML stranice.
Kada server dobije zahtev za ovakvom stranicom, on izdvaja skript iz stranice i izvrava 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 (slino kao to pretraiva mora da
razume XML da bi bio u stanju da interpretira Web stranicu napisanu u XML-u).Obino, server
oekuje da Web stranice koje sadre PHP imaju nastavak .php umesto .html ili .htm.
Na Sl. 3 je prikazana HTML stranica sa ugraenim jednostavnim PHP skriptom. Osim

standardnog HTML-a, stranica sadri jo i PHP skript unutar taga <?php . . . ?> . Efekat
ovog skirpta je generisane Web stranice koja sadri opte podatke o klijentu koji je zatraio
stranicu. Pretraivai, uz svaki zahtev upuen serveru obino alju i neke dodatne informacije
o sebi (tip pretraivaa, jezik, operativni sistem, tip klijentskog raunara, ...), koje se prenose
kao vrednost promenljive HTTP_USER_AGENT (deo poruke zahteva). Pretpostavimo da je
listing sa Sl. 3 smeten u fajlu test.php koji se nalazi na WWW direktorijumu kompanije ABCD.
Kada se korisnik obrati URL-uwww.abcd.com/test.php, server kompanije ABCD otvara fajl

test.php, pronalazi u njemu PHP skript, zamenjuje ga vrednou promenljive
HTTP_USER_AGENT iz pristiglog zahteva i tako modifikovanu stranicu vraa klijentu.
PHP je naroito pogodan za procesiranje formi. Razmotrimo primer HTML stranice sa Sl. 4
(a) koja sadri formu. Jedina specifinost ove stranice je sadraj prve linije koja definie da
radi obrade podataka unetih u formu i vraenih serveru treba koristiti fajl action.php. Stranica
prikazuje dva tekstualna polja, jedno predvieno za unos imena (name) a drugo za unos
godine roenja (age) korisnika.
Slika 8.3 3 HTML stranica sa ugraenim PHP-om
JO O HTML STRANICAMA SA UGRAENIM PHP-OM

PHP je moan programski jezik, koji se uz to i lako koristi, orijentisan
na spregu izmeu Web servera i servera baze podataka.
Nakon to je korisnik popunio oba polja, klikom na dugme Submit, popunjena stranica
(tanije, linija teksta koja sadri unete podatke) se vraa serveru. Server preuzima sadraje
polje name i age, a zatim otvara i prolazi kroz fajl action.php (Sl. 4 (b)) i izvrava svaki PHP
skript na koji naie. Pod pretpostavkom da je korisnik u polja name i age upisao Barbara i
24, HTML fajl koji se vraa klijentu imae oblik kao na Sl. 4 (c).
52
Slika 8.4 4 Web stranica sa formom i sa ugraenim PHP skriptom
PHP poseduje promenljive, stringove, polja i veinu upravljakih struktura koje sreemo u C-u.
PHP jeopen source i dostupan je za slobodno korienje. Posebno je projektovan za rad sa
Apache web serverom (koji je takoe open source).
Trea tehnika za dinamiko kreiranje Web stranica je JSP (JavaServer Pages). JSP je slina PHP-
u, s tom razlikom to se dinamiki deo stranice pie u programskom jeziku Java, umesto u
PHP-u. Stranice koje koriste ovu tehniku obino imaju nastavak .jsp.
etvrta tehnika, ASP (Active Server Pages) je Microsoft-ova verzija PHP-a i JSP-a. Za
generisane dinamikog sadraja kod ASP se koristi skript jezik Visual Basic Script(ili VB skript).
Stranice koje koriste ASP, obino imaju nastavak .asp.
Skript jezici kao to su CGI, PHP, JSP i ASP reavaju problem procesiranja formi i interakcije sa
bazama podataka na serveru. Svi oni su u mogunosti da prihvate informacije unete u formu,
pretrae informacije u bazi podataBojler Termorad 10 litara niskomontanika i generiu HTML
stranicu sa rezultatima obrade.
JAVA SKRIPT JEZIK

Meutim, ni jedan od CGI, PHP, JSP i ASP skript jezika nije u stanju da
reaguje na klik miem ili da direktno interaguje sa korisnikom koji
koristi ita.
Ni jedan od ovih skript jezika nije u stanju da reaguje na klik miem ili da direktno interaguje
sa korisnikom koji koristi ita. Za tu namenu, neophodan je program koji e se izvravati u
samom ita, na raunaru klijenta umesto na raunaru servera. Web stranica sa pridruenim
programom koji se izvrava na strani klijenta naziva se aktivnim dokumentom.
Postoje dva naina za kreiranje aktivnih dokumenata. Prvi nain podrazumeva da se program,
u obliku binarnog koda, uva na serveru, a da u HTML stranici postoji tag u kome je navedeno
53
ime fajla koji sadri program. Kada HTML interpretator u itau naie na ovakav tag, on najpre
preuzima fajl programa od servera, a zatim ga izvrava. Programi ovog tipa najee se piu
u programskom jeziku Java. Drugi nain je zasnovan na skript jeziku koji se, slino PHP-u,
ugrauje u sam HTML. Meutim, za razliku od PHP skripta koji se izdvaja iz HTML stranice i
izvrava na serverskom raunaru, skript namenjen klijetu iz HTML-a izdvaja ita i izvrava ga
uz pomo odgovarajueg interpretatora. Najpoznatiji skript jezik za ovu namenu je JavaScript.
Java
Java je objektno-orijentisan jezik zasnovan na C++. Za razliku od C++, i veine drugih viih
programskih jezika, kompajlirani programi pisani u Javi su portabilni, tj. mogu se izvravati na
bilo kom raunaru, nezavisno od tipa procesora i operativnog sistema. U terminologiji Jave,
kompajlirani program se naziva bajtkôdom (bytecode).
Bajtkôd ne sadri mainske instrukcije za neki konkretan procesor, ve instrukcije koje

se izvravaju u interpretatoru za Java bajtkôd, tj. u tzv. Java virtuelnoj maini. Bilo koji
raunar na kome je instalirana Java virtuelna maina u stanju je da izvrava programe pisane
u Javi. U osnovi, bajtkod predstavlja meukod, koji je po sloenosti izmeu Java izvornog koda
i mainskog koda. Virtuelna maina izvrava bajtkod tako to u kodu identifikuje pojedinane
komande (tzv. metode) i poziva odgovarajue funkcije pisane u mainskom jeziku za ciljnu
mainu.
JAVA APLETI
Java programi namenjeni za Web nazivaju se apletima.
Apleti se uvaju na Web serveru u fajlovima sa nastavkom .class. Aplet se ukljuuje u

HTML pomou odgovarajueg taga koji predstavlja instrukciju HTML interpretatoru da od Web
servera zatrai.class fajl, naveden u tagu, i prosledi ga virtuelnoj maini gde e aplet biti
izvren.
Primer jednostavnog apleta je aplet koji reprodukuje audio fajl, kao pozadinsku muziku,
za vreme dok je u pregledavau prikazana stranica. Pretpostavimo da je aplet ukljuen u
Web stranicu sa URL-om http://www.elfak.ni.ac.rs/ da je smeten u fajlu bgsound.class, koji
se nalazi na URL-u http://www.elfak.ni.ac.rs/java-apps . Tag koji ukljuuje aplet u HTML je
sledeeg oblika:
<OBJECT CODEBASE=http://www.elfak.ni.ac.yu/java-appsCLASSID =
java:bgsound.classDATA = bgsound.dataCODETYPE = audio/MP3></OBJECT>
Tag sadri vie atributa, sledeeg znaenja. Vrednost atributa CLASSID definie ime fajla u
kome je smeten aplet. CODEBASE definie 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 sadri podatke tipa audio/MP3, to je navedeno u atributu CODETYPE. Nakon
uitavanja, aplet i pratei audio fajl se predaju virtuelnoj maini; aplet se startuje i sadraj
audio fajla, u dekodiranom obliku, alje u audio karticu gde se obavlja reprodukcija. Na slian
nain, aplet moe sadrati grafiku animaciju ili video. U tom sluaju, kao atributi taga OBJECT
navode se dimenzije pravougaone oblasti na ekranu pregledavaa, gde e animacija/video
biti prikazani.
54
Java apleti se mogu razumeti i kao fleksibilna zamena za pomone aplikacije i plug_in-ove.
Na primer, pretpostavimo da Web stranica sadri sliku u nekom novom grafikom formatu
za koji na klijentskom raunaru ne postoji podrka u vidu plug-in-a ili pomone aplikacije
i da zbog toga slika ne moe biti prikazana na ekranu pregledavaa. Meutim, ako se za
prikazivanje slike koristi aplet, dekoder za novi format moe biti smeten u samom apletu koji
se automatski preuzima sa servera prilikom uitavanja stranice u pregledava.
ACTIVEX KONTROLE
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 izvravaju se direktno, bez posredovanja virtuelne maine,
kao to je to sluaj kod apleta. Zbog toga je izvrenje ActiveX kontrola znaajno bre od
izvravanja apleta, a njihove mogunosti su daleko vee, u smislu korienja raspoloivih
softverskih i hardverskih resursa raunara. Kada Internet Explorer u Web stranici primeti
pozivanje naActiveX kontrolu, on je preuzima od servera, verifikuje njen identitet, registruje
je na lokalnom raunaru i izvrava. Meutim, pored ograniena da se ActiveX kontrole mogu
koristiti samo na Pentium PC raunarima, njihovo korienje moe biti rizino u pogledu
sigurnosti.
JavaScript
Slina funkcionalnost kao sa Java apletima se moe dobiti i korienjem JavaScript jezika,
s tom razlikom to se, slino PHP-u, JavaScript skript jezik u izvornom obliku ugrauje u
HTML stranicu. JavaScript program se smeta u poseban HTML tag, <script>. Kada HTML
interpretator naie na tag <script> on poziva JavaScript interpretator koji izvrava sadrani
skript. Uprkos slinom imenu, JavaScript, kao jezik, nema direktne veze sa Javom. Slino
drugim skript jezicima, JavaScript sadri programske konstrukcije veoma visokog nivoa. Na
primer, u jednoj liniji JavaScript programa mogue je prikazati dijalog za unos teksta, ekati
da tekst bude unesen i smestiti uneti tekst u neku promenljivu.
Zahvaljujui ovakvim i slinim mogunostima, JavaScript je pogodan za lako projektovanje

interaktivnih Web stranica. Takoe, JavaScript poseduje mnoge osobine viih programskih
jezika, kao to su tipovi podataka, aritmetiki i logiki operatori, petlje (for(), while()), funkcije
itd. Kao primer programa u JavaScript jeziku, razmotrimo listing Web stranice sa Sl. 5. Slino
primeru sa Sl. 4, stranica sadri formu za unos imena i godina korisnika, a po unosu traenih
podataka predvia koliko e godina osoba imati sledee godine. Sekcija <body> je gotovo
identina kao u primeru za PHP. Glavna razlika je u deklaraciji Submit dugmeta i naredbe
dodele sadrane u ovoj deklaraciji. Ova naredba dodele kazuje pretraivau da kao odgovor
na klik dugmeta (dogaaj onclick) treba izvriti JavaScript funkciju response i kao parametar
preneti joj formu.
JAVASCRIPT JEZIK
Sa take gledita krajnjeg korisnika, krajnji rezultat oba primera (Sl. 18
i Sl. 19) je isti.
55
Funkcija responese()napisana je u zaglavlju HTML fajla, na mestu koje je inae rezervisano za

naslov stranice, boju pozadine i sl. Ova funkcija izdvaja iz forme vrednost polja name i pamti
je kao string u promenljivoj person. Takoe, funkcija izdvaja i vrednost polja Bojler Termorad
10 litara niskomontani age, konvertuje je u ceo broj, korienjem funkcijeeval(), dodaje
1-cu i rezultat pamti u promenljivu years. Nakon toga, funkcija otvara novi dokument za
prikaz rezultata i ispisuje etiri linije teksta korienjem funkcije writeln()i, konano, zatvara
dokument. Kreirani dokument je HTML fajl, kao to se lako moe zakljuiti na osnovu HTML
tagova koje funkcija response zajedno sa ostalim tekstom upisuje u dokument.
Bitno je razumeti da se naini obrade ova dva primera sutinski razlikuju. U primeru koji
koristi PHP, nakon klika na dugme Submit, pretraiva izdvaja informacije iz forme i u vidu
stringa ih alje nazad serveru koji je poslao stranicu. Server prepoznaje ime PHP fajla i
izvrava ga. PHP skript kreira novu HTML stranicu koja se vraa pretraivau i prikazuje.
S druge strane, u primeru koji koristi JavaScript, nakon klika na dugme Submit , pregledava
interpretira JavaScript funkciju sadranu u samoj stranici. Ne postoji novi kontakt sa
serverom, ve se sve obavlja lokalno, unutar itaa.
Zbog toga se rezultat obrade pojavljuju gotovo trenutno, za razliku od primera sa PHP gde
postoji izvesno neizbeno kanjenje (reda do nekoliko sekundi) dok rezultujui HTML fajl ne
stigne nazad do pretraivaa.
Slika - 5 Procesiranje forme pomou JavaScript-a
PROCESIRANJE SKRIPTA
Postoji razlika izmeu procesiranja skripti na strani klijenta i strani
servera prilikom upotrebe PHP i i korienjem JavaScript jezika.
Na Sl. 6 je ilustrovana razlika izmeu procesiranja skripti na strani klijenta i strani servera.
U oba sluaja, korak 1 poinje nakon to je forma uitana u pretraiva. Korak 2 iniciran je
56
klikom na dugme Submit, a nakon toga sledi procesiranje forme, koje u ova dva sluaja tee
na razliite naine.
Ove razlike ne znae da je JavaScript bolji od PHP-a. Namena ova dva skrip jezika je potpuno
razliita. PHP (i srodni skript jezici) prevashodno se koriste za interakciju sa udaljenom bazom
podataka. JavaScript se koristi za interakciju sa korisnikom na strani klijentskog raunara.
Mogue je, i uobiajeno, da Web stranica sadri oba skript jezika, sa raspodeljenim zadacima.
Slika 8.5 6 Procesiranje skripta: (a) na strani servera (PHP); (b) na strani klijenta (JavaScript)
RAZLIITI NAINI PROCESIRANJE SKRIPTA

Procesiranje skripta se odvija i na strani klijenta i na strani servera uz
pomo razliitih skript jezika (Perl, PHP, JSP ili ASP).
Slika 7 ilustruje razliite tehnike za kreiranje dinamikih i aktivnih Web stranica, o kojima
je bilo rei u ovoj sekciji. Dinamike Web stranice se generiu na strani servera, uz pomo
razliitih skript jezika (Perl, PHP, JSP ili ASP), a klijent dobija standardnu HTML stranicu koju
prosto treba da prikae. Aktivne Web stranice sadre ugraene skriptove (pisane u JavaSctipt
jeziku) ili hiperveze na kompletne programe (u vidu Java apleta ili ActiveX kontrola) koji se
nakon uitavanja izvravaju na klijentskom raunaru, to omoguava kreiranje interaktivnih
korisnikih interfejsa, pa ak i sloena procesiranja grafikih, audio ili video sadraja. Web
stranice napisane u XML-u se shodno pridruenom XSL fajlu u samom pretraivau konvertuju
u HTML, to takoe predstavlja neku formu aktivnog sadraja. Konano, plug-in-ovi i pomone
aplikacije predstavljaju proirenja pretraivaa i koriste se za prikazivanje multimedijalnih
sadraja razliitih formata.
Slika 8.6 7 Razliliti naini za generisanje i prikazivanje Web sadraja
57
Poglavlje 9
HTTP
HTTP (HYPERTEXT TRANSFER PROTOKOL -

PROTOKOL ZA PRENOS HIPERTEKSTA
HTTP je protokol koji se koristi za pristup podacima na Web-u. HTTP je
klijent-server protokol aplikacionog sloja TCP/IP steka, koji, slino
protokolima SMTP ili FTP, za transport poruka.
U veini sluajeva, HTTP klijent (ita) zahteva Web stranicu, a HTTP server (Web server)
isporuuje njenu kopiju. Meutim, HTTP dozvoljava i prenos od itaa kaserveru (npr. kada
korisnik serveru alje formu). HTTP je slian FTP-u, ali je mnogo jednostavniji jer koristi samo
jednu TCP konekciju: ne postoji posebna kontrolna konekcija, a izmeu klijenta i servera se
prenose samo podaci. Takoe, HTTP je slian SMTP-u, jer sadri koji se prenosi izmeu klijenta
i servera lii 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 oslukuje TCP port 80, ekajui
da neki pretraiva zatrai otvaranje TCP konekcije. S druge strane, pretraiva 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, pretraiva
alje serveru HTTP zahtev koji sadri putanju i ime traenog fajla. Web server odgovara
prenosom fajla, a po zavrenom prenosu zatvara TCP konekciju. Ako uitana Web stranica
sadri slike ili neki drugi dodatni sadraj, neophodno je da pretraiva radi prenosa svakog
takvog entiteta uspostavi novu TCP konekciju sa serverom. Ovakav nain rada, naziva se
neperzistentnom (nestalnom) vezom, i karakteristian je za prvobitne verzije HTTP protokola
(konkretno verzije 0.9 i 1.0).
Neperzistentni nain rada je izrazito neefikasan ako se prenose Web stranice koje osim
HTML-a sadre i vei broj slika, ikona ili drugih prateih sadraja (to je sluaj sa veinom
Web stranica koje danas viamo na Webu). Uspostavljane TCP konekcije generie dodatni
saobraaj u mrei i unosi izvesno kanjenje, to ima za posledicu sporo uitavanje ovakvih
Web stranica. Iz tog razloga, godine 1999. uvedena je nova verzija HTTP protokola, verzija
1.1, koja podrava perzistentne (trajne) veze klijenta i servera.
58
Poglavlje 9 HTTP
HTTP TRANSAKCIJA
HTTP je klijent-server protokol kod koga se komunikaciju obavlja nizom
transakcija: klijent alje poruku zahteva, a server odgovara porukom
odziva.
Kod perzistentnog naina rada, ita uspostavlja inicijalnu TCP konekciju, zatim alje zahtev
i dobija odgovor (kao kod HTTP 1.0). Meutim, nakon slanja odgovora, server ne zatvara TCP
konekciju, ve je ostavlja otvorenom dajui priliku itau da preko iste TCP konekcije uputi
dodatne zahteve. Tipino, server zatvara TCP konekciju po isteku nekog zadatog vremena
nakon poslednje upuenog zahteva. Na ovaj nain se dodatna optereenja usled
uspostavljanja i raskidanja TCP konekcije raspodjeljuju na vie HTTP zahteva/odgovora ta ko
da je relativno dodatno optereenje na nivou celokupne Web stranice znaajno manje.
Formati poruka
HTTP predvia dva generalna tipa poruka koje se razmenjuju izmeu klijenta i servera (Sl.
1). HTTP poruke se sastoje od jedne ili vie linija NVT ASCII teksta. Prva linija zahteva sadri
metod ili tip zahteva, a prva linija odgovora informaciju o statusu odgovora. Oba tipa poruke
sadre zaglavlje koje od tela poruke odvojeno jednom praznom linijom. Telo poruke je u oba
sluaja opciono (ne mora da postoji) i koristi se za prenos sadraja poruke. Poev od verzije
1.1 HTTP podrava MIME kodiranje sadraja (slino kao kod SMTP protokola).
Slika 9.1 1 Formati HTTP poruka: (a) format zahteva
HTTP METODE
HTTP je zamiljen optije od prostog protokola za komunikaciju tipa
zahtev/odgovor.
HTTP predvia vie razliitih tipova zahteva koje klijent moe da uputi serveru. U terminologiji
HTTP standarda tipovi zahtevi se zovu metodi. Osim osnovnog metoda GET koji slui za
pribavljanje Web stranice, HTTP predvia jo nekoliko dodatnih metoda navedenih u tabeli
sa Sl. 2. Metod GET zahteva od servera da poalje traenu stranicu. (Ovde se pod stranicom
misli na objekat koji moe biti HTML stranica, slika, Java aplet i sl, tj. na fajl). Stanica koja
se vraa ne mora da sadri samo ASCII tekst, a za identifikaciju tip sadraja koristi se MIME,
59
Poglavlje 9 HTTP
slino kao kod e-mail protokola. Najvei broj HTTP zahteva koji se javljaju na Web-u su upravo
tipa GET. Uobiajeni oblik metoda GET je:
GET ime_fajla HTTP /1.1
gde je ime_fajla ime resursa (fajla) koji se trai, a 1.1 verzija HTTP protokola koji se koristi.
Metod HEAD trai od servera ne celu stranicu ve samo njeno zaglavlje. Ovaj metod se
moe koristiti za pribavljane informacije o datumu i vremenu kada je stranica poslednji put
modifikovana, za prikupljanje drugih informacija o stranici i njenom sadraju ili prosto za
testiranje validnosti URL-a (da li je na datom URL-u prisutna stranica).
Slika 9.2 2 HTTP metode
KOMANDE PUT, POST, DELETE I JO NEKE HTTP

METODE
Metod PUT je suprotan metodu GET: umesto itanja, ovaj metod
upisuje stranicu na Web server.
Uz pomo PUT metoda mogue je postaviti Web stranicu na udaljeni Web server. Stranica je
sadrana u telu PUT zahteva. Stanica ne mora biti tekst, a njen MIME tip naveden je polju
Content-Type zaglavlja zahteva. Takoe, zaglavlje zahteva sadri i podatke za autorizaciju
kojima klijent dokazuje da ima pravo da izvri zahtevanu operaciju.
Metod POST je slian metodu PUT. Za razliku od PUT, kojim se na server postavlja nova
stranica (ili zamenjuje postojea), metod POST se koristi da se u resurs (u najoptijem smislu)
koji se nalazi na datom URL-u,upiu (dodaju) novi podaci. Postavljanje nove poruke na nekom
Web forumu, primer je ovog tipa operacije. Meutim, u praksi metod POST, kao i PUT, se retko
koristi.
Metod DELETE slui 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 nalae serveru da nazad
vrati primljenu poruku zahteva. TRACE je koristan u sluajevima kada se zahtevi ne obrauju
korektno, a klijent eli da sazna da li zahtevi uopte dolaze do servera.
60
Poglavlje 9 HTTP
Metod CONNECT nema definisanu namenu, ve je rezervisan za neku eventualnu buduu

primenu.
Metod OPTIONS omoguava klijentu da postavi upit serveru koji se odnosi na izvesne
parametre rada
servera ili parametre nekog konkretnog fajla.
STATUSI HTTP PORUKE

U http komunikaciji vaan je trocifreni kd statusa koji server vraa
klijentu o uspenosti obavljanja servisa koji je klijent traio.
Status
U prvoj liniji svaki odgovor kojeg server vraa klijentu sadran je trocifreni kôd statusa
koji klijentu treba da ukae da li je njegov zahtev uspeno opslue ili nije i ako nije zato nije.
Prva cifra statusnog koda slui za podelu odziva na pet glavnih grupa (Sl. 3). Kod 1xx (x -
proizvoljna cifra) se retko koristi u praksi. Kod 2xx znai da je zahtev uspeno obraen i da
poruka sadri traeni sadraj. Kod 3xx govori klijentu da traenu stranicu potrai na nekom
drugom URL-u ili u svom keu (kasnije e biti vie rei o keiranju). Kôd 4xx znai da
zahtev nije opsluen, bilo zato to je u samom zahtevu uoena greka ili zato to je klijent
zatraio nepostojeu stranicu. Konano, kod 5xx obavetava klijenta da na strani servera
postoje problemi, bilo zbog greke u programu Web servera bilo zato to je server privremeno
preoptereen.
Slika 9.3 3 Grupe statusnih kdova
ZAGLAVLJE HTTP PORUKE

U http komunikaciji pored trocifrenog kda statusa slede jedna ili vie
linija zglavlja koji server vraa klijentu o uspenosti obavljanja servisa
koji je klijent traio.
Zaglavlja poruka
Nakon linije metoda u poruci zahteva sledi jedna ili vie linija zaglavlja koje sadre dodatne
informacije o zahtevu. Za svaku liniju ove sekcije se kae da predstavlja jedno zaglavlje
zahteva. Poruka odziva takoe moe sadrati zaglavlja (jedno ili vie). Neka zaglavlja se
koriste i kod zahteva i kod odgovora. U tabeli sa Sl.4 navedena su najvanija zaglavlja.
Zaglavlje User-Agent (korisniki agent) omoguava da klijent obavesti servera o tipu
pretraivaa koji koristi, operativnom sistemu i drugim osobinama. etiri zaglavlja koja
61
Poglavlje 9 HTTP
poinju sa Accept obavetavaju servera kakav sadraj je klijent spreman da prihvata. Prvo od
ovih zaglavlja (Accept) navodi MIME tip stranice koji klijentov pretraiva moe da obradi (npr.
text/html). Drugo (Accept-Charset) definie skup karaktera (npr. ISO-8859-5 ili Unicode-1-1)
koji klijent prepoznaje. Tree (Accept-Encoding) definie metod kompresije koji klijent
podrava (npr. gzip), a etvrto (Accept-Language) ukazuje na prirodni jezik (npr. Srpski) koji
korisnik razume. Ako server ima mogunost izbora stranice (npr. postoji vie varijanti iste
stranice), on e izabrati o vratiti klijentu onu koja se uklapa u postavljene zahteve. Ako
server nije u mogunosti da udovolji zahtevima klijenta, vratie odgovor sa postavljenim
odgovarajuim kodom greke.
Slika 9.4 4 Zaglavlja HTTP poruka (delimian spisak)
OPIS SADRAJA ZAGLAVLJA HTTP PORUKE

Zaglavlje Host sadri ime servera, preuzeto iz URL-a.
Zaglavlje Host je obavezno jer se moe desiti da za istu IP adresu budu vezana vie DNS
imena. Ispitivanjem sadraja ovog polja, sever proverava da li se zahtev odnosi ba na njega.
Zaglavlje Authorization je neophodno za stranice koje su zatiene i za koje je klijent u

obavezi da dokae da ima pravo da vidi stranicu.
Cookie-ima su posveena dva zaglavlja. Preko zaglavlja Cookie klijent vraa serveru sadraj
cookie-a kojeg je ranije poslat klijentu od strane neke maine iz domena servera. Server alje
cookie klijentu u obliku sadraja zaglavlja Set-Cookie. Kao to znamo, klijent je u obavezi da
zapamti cookie na svoj hard disk, i vrati ga serveru pri svakom narednom obraanju.
Zaglavlje Date (datum) se moe koristiti u oba smera i sadri vreme i datum kada je poruka
poslata.
Slede zaglavlja koja se javljaju iskljuivo u odgovorima koje server alje klijentu. Zaglavlje
Server omoguava serveru da saopti svoj identitet klijentu, ako eli.
Sledea etiri zaglavlja, koja poinju sa Content - (sadraj) omoguavaju serveru da opie
osobine stranice koje alje. (Znaenje ovih zaglavlja je analogno odgovarajuim Accept -
zaglavljima).
62
Poglavlje 9 HTTP
Zaglavlje Last-Modified sadri datum i vreme kada je stranica poslednji put modifikovana.
Ovo zaglavlje ima bitnu ulogu u keiranju stranica.
KOMPLETAN HTTP ODGOVOR SERVERA

Zaglavlje ETag sadri jedinstveni identifikator stranice.
Server koristi zaglavlje Location kada eli da obavesti klijenta da bi trebalo da pokua da
potrai zahtevanu stranicu na nekom drugom URL-u. Ova mogunost se koristi ako je stranica
premetena na drugu lokaciju ili ako vie od jednog URL-a ukazuje na istu stranicu. Na primer,
neka internacionala kompanija moe 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 je prikazan izgled jednog kompletnog HTTP odgovora. Prva linija sadri status
odgovora, koji je u ovom sluaju pozitivan. Sledi vei broj zaglavlja, zatim jedna prazna linija
i konano sama Web stranica.
Zaglavlje ETag sadri jedinstveni identifikator stranice. Ovo zaglavlje se koristi prilikom
keiranja stranica.
63
Poglavlje 9 HTTP
Slika 9.5 5 Primer HTTP odgovora
64
Poglavlje 10
Proksi serveri i keiranje stranica
PROXY SERVER
Dva tipa meu-servera su: firewall i proxy server.
U dosadanjem izlaganju o Web-u pretpostavljali smo da klijent i server direktno komuniciraju

razmenom HTTP poruka preko Interneta. Meutim, u izvesnim sluajevima komunikacija
klijent-server ne mora biti direktna ve se moe ostvarivati posredstvom jednog ili vie meu-
servera. Dva tipa meu-servera su:firewall i proxyserver.
Proxy server je posrednik izmeu lokalnih (intranet) korisnika i Web-a (Sl. 1) i omoguava
optimizaciju kojom se smanjuje ekanje klijenata na pribavljanje zahtevanih Web stranica.
Web pretraivai u mrei koja koristi proxy server su konfigurisani tako da svoje HTTP
zahteve ne upuuju direktno udaljenim Web serverima ve ih alju lokalnom proxy serveru
koji u njihovo ime obavlja zahtevanu transakciju. Kada prvi korisnik u korporaciji pristupi
odreenoj Web stranici, proxy mora da pribavi kopiju od servera na kome se stranica nalazi.
Proxy ostavlja kopiju u svom keu i vraa traenu stranicu kao odgovor na zahtev. Kada
sledei put neki korisnik pristupi istoj stranici, proxy uzima podatke iz svog kea i ne alje
zahtev preko Interneta. Proxy serveri su bitan deo arhitekture Web-a. Osim to efektivno
skrauju vreme pribavljanja Web stranica, proxy serveri znaajno redukuju saobraaj na
Internetu i smanjuju optereenje Web servera.
Slika 10.1 1 Proksi server
KONCEPT PROKSI SERVERA

HTTP sadri eksplicitnu podrku za proxy servere.
Koncept proxy servera i keiranja (Sl. 2) nije ograniena samo na korporacijski intranet,
ve se primenjuje i u drugim kontekstima. Na primer, proxy server ne mora biti raunar na
lokalnoj mrei, ve moe biti i proces pokrenut na PC raunaru. Takoe, mnogi provajderi
65
Poglavlje 10 Proksi serveri i keiranje stranica
internet usluga (ISP) poseduju proxy server sa ciljem da svojim korisnicima ubrzaju pristup
Web-u (i u isto vreme smanje protok podataka prema nadreenom ISP-u). esto, postoji
hijerarhija proxy servera. Zahtev se najpre alje lokalnom proxy serveru, koji, ako nije u
stanju da opslui zahtev, zahtev prosleuje npr. korporacijskom proxy serveru, a ovaj proxy
serveru provajdera internet usluga i tako redom sve dok se u nekom keu ne pronae traena
stranica. Tek ako stranica ne postoji u keu proxy servera na vrhu hijerarhije, ona se direktno
trai od Web servera, a onda prosleuje nazad do pretraivaa koji je uputio zahtev i pri tome
pamti u keevima svih posrednih proxy servera. Protokol tano odreuje nain na koji proksi
obrauje svaki zahtev, kako proksi treba da tumai zaglavlje, kako pretraiva pregovara sa
proksijem i kako proksi pregovara sa serverom.
Nekoliko HTTP zaglavlja je posebno namenjeno za proksije. Na primer, HTTP omoguava

serveru da kontrolie kako proksiji obrauju svaku Web stranicu. Server moe u odgovoru
da ukljui zaglavlje Max_Forwardsi tako ogranii broj proksija koji obrauju stavku pre nego
to se ona isporui itau. Ako server odredi samo jedan, Max_Forewards: 1, na putanji od
servera do pretraivaa dozvoljen je samo jedan proksi. Nula znai da je zabranjeno da proksi
obrauju stavku.
Slika 10.2 2 Hijerarhijsko keiranje sa tri proksija
KONCEPT KEIRANJA POMOU PROKSI SERVERA

Eliminisanjem nepotrebnih prenosa, proxy ke smanjuje i vreme
ekanja i mreni saobraaj.
Glavni aspekt keiranja jeste privremeno uvanje stranica (Sl. 3), a glavno pitanje tie
se vremena uvanja stranice, tj. koliko dugo treba stavku uvati u keu. S jedne strane,
ako se kopija predugo uva u keu ona moe da zastari, to se deava ako je original u
meuvremenu, nakon to je kopija uneta u ke, promenjen. S druge strane, ako se kopija ne
uva dovoljno dugo, dolazi do smanjenja efikasnosti keiranja zato to sledei zahtev mora
nepotrebno da ide do servera. Pojedine Web stranice su podlone estim promenama (npr.
stranica sa rezultatima fudbalskih utakmica), dok druge mogu ostati neizmenjene u duem
vremenskom intervalu (npr. stranica posveena Grkoj mitologiji). Takoe, sklonost stranice
promenama moe da varira u vremenu (npr. stranica sa rezultatima fudbalskih utakmica se
brzom menja samo dok utakmica traja, a onda ostaje neizmenjena do sledeeg kola).
Takoe, neke stranice se ni u kom sluaju ne mogu keirati. To je sluaj sa dinamikim Web
stranicama koje se generiu na strani servera na osnovu postavljenog upita. HTTP dozvoljava
da server kontrolie keiranje na dva naina. Prvi nain se oslanja na informaciju iz zaglavlja
odgovora Last-Modified kada odreuje koliko dugo e stranica biti uvana u keu. Ako je
stranica koja se upravo stavlja u ke promenjena pre jednog sata, ona e biti uvana u
keu jedan sat. Ako je promenjena pre dva meseca, u keu e ostati dva meseca. Iako ovaj
66
pristup esto dobro radi u praksi, on je zasnovan na predvianjima i zato ne garantuje da e

pretraivau uvek biti vraena aurna kopija stranice.
Slika 10.3 3 Princip uslovnog GET zahteva
KONCEPT PROKSI SERVERA - GET ZAHTEV PROXY-JU

Svakoj keiranoj stranici pridruena je informacija o datumu i vremenu
kada je stranica keirana.
Drugi pristup eliminie mogunost da pregledava dobije zastarelu strancu, ali na raun
izvesnog poveanja saobraaja i vremena ekanja na pribavljanje stranice. Pristup se oslanja
na tzv. uslovni GET zahtev, koji proxy moe da poalje serveru kako bi proverio aurnost
keirane stranice. Uslovni GET zahtev je HTTP poruka koja sadri zaglavljeIf-Modified-Since
(ako je modifikovana posle ...). Procedura je ilustrovana na Sl. 3 i odvija se na sledei nain:
Pregledava upuuje standardni GET zahtev proxy-ju (korak 1). Pretpostavimo da proxy u
svom keu ima traenu stranicu. Svakoj keiranoj stranici pridruena je informacija o datumu
i vremenu kada je stranica keirana. Ova informacija je preuzeta iz poljaLast-Modified HTTP
poruke kojom je originalna stranica ranije preneta od servera do proxy-ja. Pre nego to
pretraivau vrati keiranu stranicu, proxy alje uslovnu GET poruku serveru sa upisanim
vremenom poslednje modifikacije keirane kopije u zaglavlju If-Modified-Since(korak 2). Na Sl.
3 je pretpostavljeno da stranica nije modifikovana u meuvremenu, tj. od datuma i vremena
navedenih u zaglavlju If-Modified-Since. Zbog toga server vraa proxy-ju kratak odgovor sa
statusnim kodom 304 (Not modified - nije modifikovana) i bez tela (korak 3). Po prijemu
odgovora, proxy vraa keiranu stranicu pregledavau (korak 4). U sluaju da je zahtevana
stranica u meuvremenu 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 pregledavau.
Dva pristupa za kontrolu vremena keiranja se lako mogu kombinovati. Na primer, prvih T
sekundi nakon pribavljanja stranice proxy vraa regledavau keiranu kopiju bez postavljanja
pitanja serveru. Po isteku T sekundi, proxy koristi uslovnu GET poruku za proveru aurnosti
kopije.
Jo jedan nain za poboljanje performansi keiranja naziva se proaktivnim keiranjem. Kada

proksi pribavi stranicu od servera, on je analizira i izdvaja sadrane hiperveze. Nakon toga,
proksi moe da pribavi i smesti u svoj ke stranice na koje ukazuju izdvojene hiperveze, za
sluaj da korisnik naknadno zatrai neku od njih. Na ovaj nain mogue je skratiti vreme
pristupa za budue zahteve za sluaj da korisnik izabere neki od linkova na upravo uitanoj
67
stranici. Meutim, pribavljajui i stranice koje nikada nee biti potrebne, ova tehnika ne
smanjuje ve poveava saobraaj na Internetu.
FIREWALL - SIGURNOSNI GATEWAY

Administrator intraneta moe da konfigurie firwall tako da prema
Internetu proputa smo TCP paketa sa odredinim brojem porta 80 i da
tako lokalnim korisnicima omogui korienje global
Danas se na veini lokalnih, korporacijskih mrea koristi isti skup protokola kao i na Internetu
(TCP/IP), a takve mree se nazivaju intranetima. Korienje Internet protokola na intranet
mrei ima dvojako opravdanje. Prvo, olakan je pristup Web-u od strane raunara povezanih
na intranet (lokalni raunari na isti nain komuniciraju meusobno kao i sa udaljenim
serverima). Drugo, omogueno je spoljnim Internet korisnicima da pristupaju informacijama
i servisima dostupnim na korporacijskim serverima (kao to je korporacijski Web server).
Meutim, iz sigurnosnih razloga, spoljnim korisnicima obino nije dozvoljen direktan pristup
korporacijskim serverima, ve se ostvaruje posredstvom specijalizovanog server, tzv. firewall
ili sigurnosni gateway, koji nadgleda i filtrira mrei saobraaj. Kao to se moe videti sa
Sl. 4, firewall kontrolie protok informacija u oba smera (kao iz tako i u intranet). Firewall
presree i filtrira pakete koji su sa Interneta upueni lokalnim serverima, kao i sve zahteve
koji se iz intraneta alju prema Internetu. Filtriranje se obavlja na osnovu izvornih i odredinih
IP adresama i brojevima portova sadranim u TCP/UDP paketima ili na bazi nekih drugih
kriterijuma. Firewall moe biti konfigurisan tako da prosleuje ka intranetu samo pakete koji
su upueni na odreene lokalne IP adrese i/ili samo ako su paketi poslati iz nekog odreenog
domena, a da sve ostale ponitava. Takoe, firewall moe da uvede restrikcije koje se odnose
na brojeve portova. Na primer, firewall moe biti tako podeen da ponitava sve dolazne TCP
pakete sa brojem odredinog porta 20 ili 21 i da na taj nain onemogui pristup bilo kom
lokalnom FTP serveru.
Slika 10.4 4 Firewall
68
Poglavlje 11
Veba 1
UVOD U VEBE
Cilj ove sekcije je da uvede studenta u tok samih vebi na predmetu
IT255:ta emo raditi na vebama?
ta emo raditi na vebama?

Na vebama iz predmeta IT255 Web sistemi 1 baviemo se izradom frontend dela web
sistema po specifikacijama i zahtevima kako se to obino radi i u praksi. Ovaj predmet
fokusirae se na izradu web aplikacije MetAir kroz svih 15 nedelja. Domai zadaci studenata
bie da naprave slian sistem po uzoru na ono to su nauili na vebama i predavanjima iz
ovog predmeta.
ta je to Front end programiranje
Front end programiranje ili programiranje klijentske strane predstavlja programiranje onoga
to korisnik vidi a to je grafiki korisniki interfejs i komunikaciju grafikog korisnikog
interfejsa sa programskom logikom (back end delom programa).
ta je to Web Framework
Web Application Framework (WAF) je softverski omot oko nekog web programskog jezika
koji nam omoguava podrku u izradi dinamikih web sajtova, web aplikacija, web servisa
ili resursa. Framework se pravi iskljuivo da olaka I omogui bolji razvoj aplikacija. Na
ovom predmetu obraivaemo Angular JS front end framework u kombinaciji sa programskim
jezikom PHP.
GitHub
GitHub je web aplikacija koja omoguava besplatnu kontrolu koda svima koji ele da je koriste
za pravljenje aplikacija otvorenog koda. Kontrola koda (eng. Source Control) nam omoguava
da lako pratimo izmene u samom kodu, radimo u timu i verzioniemo nae aplikacije. Ovo je
jako dobra praksa pa emo kroz predmet praktikovati da sve domae radite preko GitHub-a.
Jedan GitHub nalog moe da ima vie repozitorijuma. Jedan repozitorijom predstavlja kontrolu
koda za jedan projekat. GitHub koristi Git sistem kontrole koda pa je Git potrebno instalirati
na raunaru. Git funkcionie po sistemu local -> remote. Tako da ono to izmenite kod sebe
na raunari ne ide odma na remote GitHub nalog ve ide tek nakon Push akcije (prebacivanje
fajlova na remote lokaciju). U lokalu fajl moete dodati u projekat (Add) i verifikovati ga
(Commit) kada ste zavrili sa radom na fajlu.
69
Poglavlje 11 Veba 1
INSTALACIJA I PODEAVANJE ALATA POTREBNIH ZA

VEBE
Cilj ove sekcije je da prikae studentu kako se instaliraju i konfiguriu
alati potreni za vebe iz web sistema.
Za vebe iz web sistema potrebni su sledei alati:
Xampp 5.5.30
Node JS (Node JS Package Manager NPM) 5.4.0
Git 2.7.0
Notepad++
Linkovi za download potrebnih alata su:

https://www.apachefriends.org/download.html
https://nodejs.org/en/download/
https://git-scm.com/downloads
https://notepad-plus-plus.org/download/v6.8.8.html
INSTALACIJA XAMPP PAKETA

U ovoj sekciji bie objaenjena instalacija XAMPP paketa
Nakon preuzimanja XAMPP-a sa navedenog sajta potrebno je pokrenuti instalaciju. Nakon

pokretanja instalacije otvorie Vam se prozor instalacije. Ukoliko Vam instalacija izbaci poruku
pre paljenja pritisnite OK.
Slika 11.1 Upaljena instalacija
Kada vidite ovaj ekran kliknite na dugme Next. A potom odaberite komponente koje su
potrebne kao na sledeoj slici:
70
Poglavlje 11 Veba 1
Slika 11.2 Komponente za instalaciju
Nakon biranja komponenti potrebno je da se izabare mesto instalacije XAMPP aplikacije:
Slika 11.3 Biranje lokacija za instalaciju
INSTALACIJA XAMPP PAKETA DRUGI DEO

U ovoj sekciji bie objaenjen drugi deo instalacije XAMPP paketa
Nakon biranja lokacije za instalaciju pritisnite dugme Next I detiklirajte Learn more about
Bitnami for XAMPP I idite opet na opciju Next. Kada je instalacija spremna za instalaciju idite
na dugme Next.
71
Poglavlje 11 Veba 1
Slika 11.4 Pokrenuta instalacija XAMPP-a (PHP I MySQL server)
Nakon uspee instalacije XAMPP-a moete pokrenuti Apache server kao i MySQL server klikom
na Fisnih dugme I otvaranjem XAMPP Control Panela.
Slika 11.5 Uspena intalacija XAMPP-a.
Slika 11.6 Xampp Control Panel
72
Poglavlje 11 Veba 1
INSTALACIJA GIT-A
Cilj ove sekcije je da prikae studentu kako da instalira Git na svom
raunaru

Nakon preuzimanja Git-a sa navedenog sajta potrebno je pokrenuti instalaciju.
Slika 11.7 Poetni ekran instalacije za Git
Na ovom koraku potrebno je kliknuti dugme Next a potom prihvatiti licencu.
Slika 11.8 Prihvatanje lincence klikom na Next
Nakon prihvatanje licence klikom na Next potrebno je odabrati lokaciju instalacije Git-a.
73
Poglavlje 11 Veba 1
Slika 11.9 Biranje lokacije za instalaciju Git-a
INSTALACIJA GIT-A DRUGI DEO

Cilj ove sekcije je da studentu prikae kako da instalira Git na svom
raunaru
Sledei korak je biranje komponenti koje ostavljamo na standardnim podeavanjima.
Slika 11.10 Biranje komponenti za instalaciju
Nakon preuzimanja Git-a sa navedenog sajta potrebno je pokrenuti instalaciju. Nakon biranja
komponenti potrebno je pritisnuti dugme Next a potom odabrati kako e se zvati folder u
Start meniju za Git.
74
Poglavlje 11 Veba 1
Slika 11.11 Naziv foldera za Git u Start meniju
Nakon ovog koraka potrebno je kliknuti na Next a potom odbrati Use Git from Windows
Command Prompt
Slika 11.12 Podeavanje GIt-a da radi iz Command Prompt-a
INSTALACIJA GIT-A TREI DEO

Cilj ove sekcije je da studentu prikae kako da instalira Git na svom
kompjuteru
Nakon ovoga koraka potrebno je kliknuti na Next ostaviti podeavanje za encoding u

tekstualnim fajlovima I opet ii na Next. Za konzolu je potrebno odabrati Use Windows default
console window.
75
Poglavlje 11 Veba 1
Slika 11.13 Biranje windows konzole za Git
Nakon ovog koraka ponavljati Next komandu do poetka instalacije.
Slika 11.14 Instalacija Git-a
Nakon uspene instalacije pojavie se prozor na kome je potrebno pritisnuti Finish.
Slika 11.15 Gotova Git instalacija
76
Poglavlje 11 Veba 1
INSTALACIJA NODE JS PACKAGE MANAGER-A

Cilj ove sekcije je da studentu prikae kako da instalira NPM na svom
raunaru
Nakon preuzimanja Node JS-a sa navedenog sajta potrebno je pokrenuti instalaciju.
Slika 11.16 Poetak instalacije NodeJS-a
Pritsnite dugme Next a potom prihvatite uslove korienja i opet kliknite Next.
Slika 11.17 Prihvatanje licence
Nakon prihvatanja uslova potrebno je odabrati lokaciju instalacije i opet pritisnuti dugme
Next.
77
Poglavlje 11 Veba 1
Slika 11.18 Biranje lokacije za instalaciju
INSTALACIJA NODE JS PACKAGE MANAGER-A DRUGI

DEO
Cilj ove sekcije je da studentu prikae kako da instalira NPM na svom
kompjuteru
Nakon ovoga potrebno je odabrati sve komponente za instalaciju.
Slika 11.19 Odabir svih paketa
Nakon klikna Next pritisnuti opet Next i zatim Install dugme. Instalacija e poeti.
Slika 11.20 Instalacija NodeJS-a je u procesu
Nakon instalacije potrebno je kliknuti Finish dugme
78
Poglavlje 11 Veba 1
Slika 11.21 Uspena instalacija NodeJS Package Manager-a
INSTALACIJA NOTEPAD++-A
Cilj ove sekcije je da studentu prikae kako da instalira Notepad++ na
svom raunaru
Nakon preuzimanja Notepad++-a sa navedenog sajta potrebno je pokrenuti instalaciju. Prvo

je potrebno izabrati jezik instalacije a potom kliknuti na dugme Next.
Slika 11.22 Poetan instalacije Notepad++ aplikacije
Klikom na dugme Next otvaraju se uslovi korienja aplikacije pa treba pritisnuti dugme I
Agree. Nakon prihvatanja uslova korienja potrebno je odabrati lokaciju instalacije.
79
Poglavlje 11 Veba 1
Slika 11.23 Lokacija za intalaciju Notepad-a++
Nakon biranja lokacije potrebno je pritisnuti dugme Next a zatim ponovo Next poto emo
instalirati sve standardne pakete za Notepad++. Ostaviemo i ostale komponente po
standaru pa treba da pritisnemo dugme Install.
Slika 11.24 Biranje dodatnih komponenti
INSTALACIJA NOTEPAD++-A DRUGI DEO

Cilj ove sekcije je da studentu prikae kako da instalira Notepad++ na
svom kompjuteru
Nakon odabira komponenti pritisnuti dugme Install i instalacija treba da pone.
80
Poglavlje 11 Veba 1
Slika 11.25 Instaliranje Notepada++
Nakon instaliranja pokazae se prozor sa informacijom o zavretku instalacije gde je potrebno

pritisnuti Finish.
Slika 11.26 Uspena instalacija Notepad++-a
POKRETANJE PRVOG PHP PROJEKTA

U ovoj sekciji student e nauiti kako da pokrene svoj prvi PHP projekat
U C:/xampp/htdocs je potrebno kreirati folder projekta (it255) a potom kreirati unutar njega
fajl index.php
81
Poglavlje 11 Veba 1
Slika 11.27 Kreirani index.php fajl
Otvorite fajl preko Notepad++ programa desnim klikom na File pa onda klikom with Edit with
Notepad++. Unutar Notepad-a napisati sledei kod:
<?php
echo "Hello World";
?>
Nakon ovoga potrebno je da upalimo Apache server preko XAMPP Control Panel-a koji ste
prethodno instalirali. Apache palimo klikom na dugme Start sa desne strane.
Slika 11.28 Startovanje Apache servera
Nakon uspenog startovanja Apache servera potrebno je izai na adresu http://localhost/

it255/ i ispisae se poruku Hello World
KAKO POSTAVITI PHP PROJEKAT NA GITHUB

U ovoj sekciji student e nauiti kako da svoj PHP projekat postavi na
GitHub
Kada smo postavili PHP projekat moemo ga postaviti na GitHub kako bi mogli kasnije
projekat da nadogarujemo i kako bi tu postavljali ubudue domae zadatke.
Prvo je potrebno da upalimo Command Prompt iz Windowsa ( Ctrl + R pa cmd i Run).
A potom da doemo do foldera gde nam se nalaze nai PHP fajlovi. Ovo moemo uraditi
komandom cd C:\xampp\htdocs\it255
82
Poglavlje 11 Veba 1
Slika 11.29 Otvaranje foldera it255 preko Command Prompta
Nakon ulaska u folder treba da inicializujemo GIT repozitorijum, ovo moemo uraditi
komandom git init
Slika 11.30 Kreiranje lokalnog Git repozitorijuma
Ukoliko niste ranije potrebno je da setujete promenjive za Va username i emejl za Git ovo
uradite sledeim komandama:
git config --global user.name "John Doe"

git config --global user.email johndoe@example.com
Nakon konfiguracije treba da dodamo sve fajlove u GIT repozitorijum ovo moemo uraditi
komandom git add -A
Slika 11.31 Dodavanje svih fajlova na lokalni Git
KAKO POSTAVITI PHP PROJEKAT NA GITHUB DRUGI

DEO
U ovoj sekciji student e nauiti kako da postavi fajlove na Git-u kao
aktuelne
83
Poglavlje 11 Veba 1
Nakon ovoga potrebno je da fajlove komitujemo tj da fajlove stavimo kao aktuelne na

repozitorjumu ovo radimo komandom git commit -m Poruka komita.
Slika 11.32 Postavlje fajlova kao aktuelnih na lokalnom Git-u
Kada zavrite commit treba kreirati nalog na GitHub.com i napraviti repozitorijum kako bi
mogli kod da objavite na internet zbog timskog rada.
PRAVLJENJE GITHUB NALOGA

U ovoj sekciji studentu e biti objanjeno kako na GitHub nalogu da
napravi repozitorijum
Prvo je potrebno da odete na sajt http://GitHub.com I napravite nalog. Potom se ulogujte na

nalog.
Slika 11.33 Kreiranje repozitorijuma koristei GitHub
Kada kliknete na New Repository izaie Vam forma u kojoj popunjavate ime vaeg
repozitorijuma i njegov opis
84
Poglavlje 11 Veba 1
Slika 11.34 Pravljenje repozitorijuma na GitHub-u.
Kada uspeno kreirate repozitorijum dobiete Git adresu samog repozitorijuma koju treba da
kopirate jer nam treba za git push funkciju koja stavlja repozitorijum na internet.
Slika 11.35 Adresa napravljenog GitHub repozitorijuma.
POSTAVKA PODATAKA SA LOKALNOG GIT-A NA

UDALJENI (GITHUB)
Cilj ove sekcije je da pokae studentu kako da povee svoj lokalni git
sa udaljenim GitHub-om
Nakon kreiranja repozitorijuma potrebno je da se vratimo u komandu liniju i dodamo remote

repozitorijum komandom git remote add origin https://github.com/vasicvuk/it255.git
(umesto ovog linka ide link do vaeg repozitorijuma.
Slika 11.36 Dodavanje udaljenog git repozitorijuma
Nakon ovoga moemo podii verziju koda na GitHub koristei komandu git push origin
master.
85
Poglavlje 11 Veba 1
Slika 11.37 Podizanje koda na GitHub
Nakon ovoga upisati svoj Username i Password za GitHub i repozitorjum je postavljen na web.
Slika 11.38 Uspeno postavljanje na GitHub
Nakon ovoga moemo videti i uspean commit na GitHub-u
Slika 11.39 Uspean commit na GitHub-u
VIDEO KLIP - UVOD U PHP

Uvod u PHP - video
PRIMER ZA SAMOSTALNI RAD

Pokuajte sami da instalirate na svom raunaru sve potrebna alate za
razvoj poetne veb aplikacije koja je raena u okviru vebe u ovoj
lekciji.
86
Poglavlje 11 Veba 1
Proverite da li ste sproveli sledee aktivnosti:
1. Instalirani supotrebnisledei alati:
Xampp 5.5.30
Node JS (Node JS Package Manager NPM) 5.4.0
Git 2.7.0
Notepad++
2. Pokretanje prvog PHP projekta
3.Postaviti PHP projekat na GitHub
87
Poglavlje 12
Domai zadatak 1
DOMAI ZADATAK BROJ 1

Za domai zadatak student treba kui da podesi sve to je potrebno za
kreiranje PHP projekta
Za domai zadatak student treba kui da podesi sve to je potrebno za kreiranje PHP projekta
a potom:
1. Kreira PHP projekat sa imenom MetHotels.2. Napravi GitHub nalog:

imeprezimebrojIndeksa3. Podigne kod svog PHP projekta na GitHub.4. Pokrene PHP projekat
na Apache serveru5. Poalje mail asistentu sa slikom pokrenute aplikacije kao i linkom ka
GitHub repozitorijumu gde je podignut kod.
Domai treba slati asistentu na mejl: vuk.vasic@metropolitan.ac.rs za studente u Beogradu a
na mejl nikola.dimitrijevic@metropolitan.ac.rs za studente u Niu.
88
Zakljuak
INERNET I WORLD WIDE WEB

Za izradu veb aplikacija vano je sagledati istorijat web-a, znati
osnovno o dizajnu veb aplikacija i projektovanju veb sistema. Prouiti
primere dobre prakse izrade veb aplikacija.
U ovoj lekciji student je nauio osnovno o elementima interneta, TCP/IP protokolu i njegovoj
vezi sa OSI modelom, protokoli koji se koriste, kako funkcioe web server pozivi i dostavljanje
HTML-a od strane servera.
Opisana je evolucija veba koja se moe pratiti tragom nekoliko dimenzija i iz vie perspektiva:
rastom broja Veb sajtova i Veb stranica;

rastom broja korisnika Veba;
brojem poseta;
funkcionalnostima i interaktivnou Veb aplikacija;
tehnologijama korienim za razvoj Veb aplikacija;
socijalnom i poslovnom uticaju Veba ili njihovim kombinacijama.
uspostavljanje veza Veb inenjeringa i ostalih disciplina
89

Internet I World Wide Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internet I World Wide Web

Uploaded by

Copyright:

Available Formats

IT255 - VEB SISTEMI 1

Internet i World Wide Web

INTERNET I WORLD WIDE WEB

Internet i World Wide Web

Web se sastoji od ogromne kolekcije dokumenata/stranica povezanih hipervezama, a

Kratak pregled (r)evolucije WWW

A kada se proulo o izuzetnim karakteristikama i mogunostima Veba, poslovni svet je obratio

Strunjaci u marketingu su shvatili potencijal. Prodavci su bili odmah za njima, a ubrzo je

Definicija 1: Veb aplikacija (VA) je softverski sistem zasnovan na tehnologijama i standardima

KATEGORIJE VEB APLIKACIJA

Takoe moemo primetiti da razliite kategorije pokrivaju mnoge tradicionalne aplikacione

Kategorije VA su: Dokument-orjentisani Veb sajtovi, interaktivne Veb aplikacije, Transakcione

Slika 1.1 1 Kategorije Veb sajtova/aplikacija

NAJBITNIJA SVOJSTVA KATEGORIJA VEB APLIKACIJA

Dokument-orjentisani Veb sajtovi su prethodili Veb aplikacijama. Veb stranice su skladitene

Transakcione Veb aplikacije su napravljene sa ciljem podizanja interaktivnosti na vii nivo. U

Mada ga je u poetku karakterisala kakva-takva anonimnost korisnika, sve je izraeniji trend

Portalski orjentisane aplikacije predstavljaju jedinstvenu taku pristupa mnogobrojnim

Definicija 2: Veb inenjering podrazumeva primenu sistematinih i merljivih pristupa

INTEROPERABILNOST U VEB INENJERINGU

U dananje vreme VA su po sloenosti dostigle nivo da je nuna primena znanja, modela i

Slika 1.2 2 Veza Veb inenjeringa i ostalih disciplina

1. Razumeti optu funkciju sistema i operativno okruenje, ukljuujui i poslovne ciljeve i

3. Objaviti ili specificirati (poetne) funkcionalne, tehnike, ali i netehnike zahteve

4. Razviti arhitekturu celokupnog Veb-baziranog sistema koji zadovoljava postavljene

5. Identifikovati podprojekte ili podprocese za implementaciju arhitekture sistema. Ako su

6. Razviti i implementirati definisane podprojekte.

7. Ukljuiti efikasne mehanizme za upravljanje evolucijom veb sistema, promenu i

8. Adresirati netehnika pitanja, kao to su revidiranje: poslovnih procesa, organizacionih i

Slika 2.1 1 Internet mrea

Internet (sa velikim I) je gigantska mrea prvobitno kreirana povezivanjem razliitih

Slika 2.2 2 Struktura Interneta

PAKETSKI PRENOS PODATAKA

Paketski prenos podataka

U komunikacionim mreama koje pokrivaju vea geografska rastojanja, kao to je Internet,

Ruteri se ne bave interpretacijom sadraja i znaenja podataka, ve se bave prenosom

Slika 2.3 3 Komutacija paketa: datagramski pristup

Ponovo, detekcija izgubljenih paketa i odluka kako postupiti u ovakvim situacijama je u

? Prenosne linije se efikasno koriste, s obzirom na to da se komunikacioni kapacitet linije, koja

KARAKTERISTIKE PAKETSKOG PRENOSA

Mrea sa komutacijom paketa moe da amortizuje razlike u brizni prenosa podataka

Meutim, komutacija paketa ispoljava i izvesne nedostatke:

Prolazak paketa kroz ruter unosi dodatno kanjenje u prenosu. S obzirom na to da se

Razmena podataka izmeu umreenih ureaja zahteva sprovoenje veoma sloenih

RAVNOPRAVNI (PEER-TO-PEER) SLOJEVI

Slika 2.4 4 Slojevi, protokoli i interfejsi

Ravnopravni (peer-to-peer) slojevi

Za slojeve mrenog softvera, osim vertikalne, karakteristina je i horizontalna povezanost

Izmeu svakog para vertikalno-susednih slojeva egzistira interfejs. Interfejs definie

Dananje mree su izrazito kompleksni entiteti. Kako bi se savladala kompleksnost mrea,

OSI REFERENTNI MODEL

OSI referentni model

Slika 2.5 5 OSI referentni model

Slika 2.6 6 TCP/IP - model sa 4 sloja

SLOJEVI U OSI REFERENTNIOM MODELU

Mreni sloj je zaduen za rutiranje i isporuku paketa. U njegovoj nadlenosti je kako e

Slika 2.7 7 Transportni sloj

Sloj sesije obezbeuje mehanizme za rukovanje sesijom izmeu krajnjih aplikacija.

prenosa velikih fajlova za sluaj abnormalnog prekida kako bi se po ponovnom uspostavljanju

PREZENTACIONI I APLIKACIONI SLOJ

Prezentacioni sloj je odgovoran za isporuku i formatiranje podataka aplikacionom sloju za

Prezentacioni sloj je zaduen za sintaksu i semantiku informacija koje se razmenjuju izmeu

Slika 2.8 8 Sloj sesije