RM2p3 (04/19)

3. Sloj mrežnih aplikacija

U ovom poglavlju iznosimo središnje pojmove iz govora o aplikacijskoj razini mrežnog sustava, te prikaze struktura i načela rada dominantnih protokola te razine. Opisani su standardni mrežni protokoli među koje spadaju HTTP (web sustav), FTP (sustav za prijenos datoteka), SMTP (sustav računalne pošte), DNS (sustav imena domena), i drugi. Uz opise tih protokola aplikacijske razine dani su i kraći prikazi korisničkih sustava (aplikacija) čiji se rad zasniva na implementaciji navedenih protokola.

Standardni protokoli i sustavi aplikacijske razine oblikovani su i rade prema osnovnom načelu klijent-server. Drugo načelo, prema kojem se oblikuju novije mrežne aplikacije, naziva se peer-to-peer (P2P). U aplikacijama toga tipa, komunikatori su istovrsni (peer) sustavi, koji koriste usluge drugih istovrsnih sustava i pružaju usluge takvim sustavima. Ovdje iznosimo prikaz jednog sustava za distribuciju datoteka (BitTorrent) i sustava distribuiranih hash tablica (DHT), kao istaknutih protokola i mrežnih aplikacija tipa P2P.

1

3.1 Struktura mrežnih aplikacija

Mrežne aplikacije su uglavnom softverski sustavi koji rade na raznim računalima, pri čemu razmjenjuju informacijske sadržaje sa sustavima na drugim računalima, koristeći usluge prijenosa koje im pruža računalna mreža. Mrežne aplikacije rade na završnim čvorovima mreže (end nodes), koje nazivamo domaćinima (hosts); čini se da taj naziv dolazi od toga što su ti čvorovi domaćini za aplikacije koje rade na njima. Prema osnovnoj strukturi, mrežne aplikacije dijele se u dvije osnovne skupine: klijent-server, i peer-to-peer (P2P).

Tradicionalne mrežne aplikacije su tipa klijent-server. Takve aplikacije imaju klijentski dio, koji traži neku uslugu (dostavu sadržaja, izvršenje operacije) i serverski dio, koji izvršava takve zahtjeve klijenata. Klijentski dio aplikacije obično radi na osobnim računalima i na mobitelima; klijenti ne moraju biti uvijek aktivni; osobna računala se često gase. Serverski dio mrežne aplikacije obično radi na većim računalima, koja su stalno aktivna i vezana na mrežu. Web preglednik je klijentski podsustav u web sustavu, koji korisniku omogućava dosizanje sadržaja web stranica sa udaljenih servera na kojima su ti sadržaji pohranjeni, i prikaz tih sadržaja (kao web stranica) na lokalnom računalu. Korisnik može pokrenuti preglednik (kao klijentski sustav) na svom računalu kada hoće i zaustaviti ga kada hoće. S druge strane, web serveri, na kojima su pohranjeni sadržaji raznih vrsta, su stalno aktivni i vezani na računalnu mrežu, tako da klijenti mogu u svakom trenutku zatražiti od servera da im dostave neke sadržaje koji su pohranjeni na njima.

Serveri raznih aplikacija sadrže razne vrste informacijskih sadržaja, koje njihovi klijenti mogu tražiti od njih i koje im serveri dostavljaju na njihov zahtjev. U sustavima tipa klijent-server, klijenti ne komuniciraju izravno jedan s drugim; komunikacija klijentskog dijela aplikacije uvijek se odvija sa nekim serverskim dijelom te aplikacije.

Neke mrežne aplikacije tipa klijent-server su vrlo popularne, tako da se klijentski dio tih sustava nalazi na većini korisničkih računala. Pored "računala", može se uvijek dodati "i novijih mobitela", ali to nije potrebno činiti, jer su razlike između prijenosnih računala i mobitela sve manje: obje vrste naprava služe komuniciranju i računanju, pri čemu komunikacijske aktivnosti stalno rastu. Dakle, pojmom osobno računalo ovdje obuhvaćamo i naprave koje nominalno spadaju u mobilnu telefoniju. Serverski dio aplikacija o kakvima ovdje govorimo, isto tako radi na velikom broju računala, ali na mnogo manjem broju nego klijentski dio, jer jedan server može opsluživati ogroman broj klijenata istodobno (paralelno). Koliki je taj broj, zavisi od vrste i intenziteta posla, i od informacijskih sadržaja koji se prenose. Naprimjer, jedna tvrtka ili jedan odjel sveučilišta može imati svoj web server. Takav server općenito izvršava zahtjeve svakog klijenta u mreži Internet, koji od njega zatraži da mu dostavi sadržaje web stranica, koji su pohranjeni na njemu.

Kod mrežnih aplikacija tipa klijent-server, klijentski dio i serverski dio aplikacije se bitno razlikuju po strukturi, operacijama i sadržajima. Kod mrežnih aplikacija tipa peer-to-peer (P2P), klijent i server su samo trenutne uloge istog sustava u nekoj mrežnoj komunikaciji. Kod P2P aplikacija, sustavi koji međusobno razmjenjuju sadržaje, nemaju fiksne uloge klijenta i servera, nego su "istovrsni" i "istorazinski" (peer = iste razine ili vrste). Domaćini na kojima rade mrežne aplikacije tipa P2P su obično računala krajnjih korisnika mrežnih usluga.

Aplikacije tipa P2P uspostavljaju izravnu komunikaciju i razmjenu sadržaja između istovrsnih sustava. Aplikacije tipa P2P pogodne su za razmjenu datoteka između velikog broja sustava (korisnika). Kod takvih aplikacija, na svim domaćinima koji sudjeluju u procesu međusobne razmjene sadržaja nalazi se jednak softver, i svi domaćini sudjeluju u procesu međusobne razmjene. Mrežne aplikacije tipa P2P koriste se za distribuiranje datoteka (aplikacija BitTorrent), u Internetskoj telefoniji (sustav Skype) i kod prijenosa televizijskog programa pomoću Interneta (IPTV; sustav PPLive). O nekim aplikacijama tipa P2P govorimo u drugom dijelu ovog

2

poglavlja.Dakle, mrežne aplikacije su sustavi koji rade na domaćinima i čiji rad iziskuje izvođenje

određenih procesa (različitih ili jednakih) na dva ili više domaćina, koji međusobno razmjenjuju informacijske sadržaje koristeći prijenosne usluge računalne mreže. Mrežne aplikacije mogu se pisati u raznim programskim jezicima, kao što su C++, Java, Python i drugi. Mrežne aplikacije rade na završnim čvorovima mreže, koje nazivamo domaćinima. Prijenosnici raznih vrsta - usmjerivači, vrata, preklopnici i mostovi - ostvaruju usluge prijenosa, koje omogućuju rad aplikacijskih sustava, ali na tim čvorovima ne rade mrežne aplikacije, odnosno mrežni sustavi aplikacijske razine.

Domaćin na kojem radi serverski dio aplikacije ima fiksnu IP (mrežnu) adresu; ta adresa treba biti poznata klijentskom dijelu aplikacije, da bi mogao stupiti u komunikaciju sa serverskim dijelom te aplikacije i uputiti mu neki zahtjev.

Kod nekih mrežnih usluga odvija se vrlo intenzivan promet i prenose se velike količine podataka. Takve usluge (aplikacije) su sustavi za distribuciju video sadržaja (YouTube i drugi), sustavi društvenog umrežavanja (Facebook, Twitter, MySpace i drugi), tražilice (Google i drugi), i sustavi za internetsko trgovanje (Amazon, e-Bay i drugi). Broj veza u jedinici vremena i količina sadržaja s kojima rade takvi sustavi, su izrazito veliki, tako da jedan server ne bi mogao fizički udovoljiti zahtjevima koji istodobno dolaze sa velikog broja klijenata. Neke društvene mreže primaju više desetaka tisuća klijentskih zahtjeva u sekundi; izvršenje svakog takvog zahtjeva može iziskivati da server nađe i pošalje klijentu više gigabajtova podataka, ili da primi od klijenta toliko sadržaja i spremi (zapiše) ga u svoju memoriju. Jedno računalo (na kojem radi serverski dio aplikacije) ne bi moglo obavljati toliki posao. Zato se kod takvih mrežnih aplikacija koriste grozdovi (clusters) domaćina, koji se nazivaju i centrima podataka (data centers). Jedan takav grozd tvori jednog virtualnog domaćina, čija se fizička realizacija može sastojati od više tisuća fizičkih domaćina koji su raspoređeni širom svijeta i na kojima rade kopije istog web servera koji pruža neku određenu uslugu.

Aplikacije za društveno umrežavanje i aplikacije za razmjenu raznih vrsta sadržaja, su web aplikacije koje korisnicima pružaju neke specifične usluge. Većina takvih aplikacija spada u Web 2.0 aplikacije. Naziv Web 2.0 označava jednu vrstu web usluga, više nego novu vrstu web sustava. Aplikacije za koje se kaže da su tipa Web 2.0, su web aplikacije, bez obzira na specifičnosti sustava, i usluga koje ti sustavi pružaju. Spomenimo da popularne web aplikacije, kao što su YouTube, Facebook, Google, i druge, iziskuju ogromnu količinu računalne opreme i prijenosa podataka, tako da je razvoj i održavanje takvih mrežnih usluga skup poduhvat. Dakle, pored dobrih komercijalnih ideja, za razvoj tako opsežnih sustava potrebno je imati i dovoljno sredstava (ili investitora). Ovdje se ne bavimo pitanjem koliko je postojanje takvih sustava izravno isplativo za njihove vlasnike, ni na koji način takvi sustavi naplaćuju svoje usluge. Postojanje takvih mrežnih usluga (aplikacija) pokreće potrošnju računalne opreme (hardvera i softvera) od strane korisnika tih usluga, i stvara veliku potrošnju u području prijenosa sadržaja, a time i prihode vlasnicima prijenosnih sustava. Tako popularne mrežne usluge pokreću cjelokupnu industriju informacijske opreme i informacijskih sadržaja.

Mrežna aplikacija je općenito par procesa koji se izvode na različitim završnim računalima mreže; jedan od tih procesa ima ulogu klijenta a drugi ima ulogu servera. Proces možemo opisati kao "program u izvođenju"; dakle, program definira neki proces, a izvođenje programa realizira taj proces. Za rad mrežnih aplikacija potrebno je uspostaviti komunikaciju između dvaju procesa koji se izvode na različitim domaćinima. Takva komunikacija odvija se u obliku razmjene poruka između dvaju međusobno udaljenih procesa; te poruke prenose se pomoću prijenosnog sustava računalne mreže. Naprimjer, kod web aplikacije, proces kojeg izvodi preglednik (kao klijent) šalje poruke procesu kojeg izvodi web server na nekom drugom domaćinu. Web server izvršava zahtjeve klijenta i odgovara na njegove poruke; to uključuje slanje klijentu

3

onih informacijskih sadržaja (datoteka, web objekata) koje je klijent tražio.Na taj način ostvaruje se rad web aplikacije kao cjeline. U standardnom web sustavu su

uloge klijenta i servera stalne: određene su strukturom tih softverskih elemenata, kao i sadržajima s kojima rade. Kod web aplikacija tipa P2P nema takve stalne podjele uloga na klijenta i servera, ali u svakom procesu komunikacije, komunikatori poprimaju uloge klijenta ili servera. Kod takvih aplikacija, istovrsni procesi odvijaju se na istovrsnim domaćinima, ali se onu stranu (domaćina i proces) koja traži i prima sadržaje naziva klijentom, dok se onu stranu koja joj šalje te sadržaje naziva serverom. Kod aplikacija P2P, isti proces poprima ulogu klijenta i ulogu servera, zavisno od toga da li prima ili šalje informacijske sadržaje.

Općenito, u okviru jedne komunikacije (sesije) između dvaju procesa, onaj proces koji je započeo tu sesiju (sa porukom-zahtjevom koju je uputio sustavu na drugom domaćinu), naziva se klijentom. Onaj proces koji je bio pokrenut (i koji "čeka" da bude pokrenut) naziva se serverom. Kod tradicionalnih mrežnih aplikacija tipa klijent-server, uloge klijenta i servera su stalne i određene su sa procesima koji se izvode na pojedinim domaćinima, kao i sa sadržajima koji su pohranjeni na tim domaćinima, sa kojima ti procesi upravljaju. Kod web aplikacija tipa P2P, domaćini i procesi na domaćinima su istovrsni, tako da se uloge klijenta i servera mijenjaju u zavisnosti od toga koji je proces (domaćin) uputio poruku drugom istovrsnom procesu (domaćinu) sa zahtjevom da mu dostavi neke sadržaje. Dakle, pokretač aktivnosti ima općenito ulogu klijenta, dok izvršitelj zahtjeva ima ulogu servera.

Procesi aplikacijske razine šalju svoje poruke i primaju poruke od udaljenih procesa iste razine preko prijenosnog sustava računalne mreže. Proces aplikacijske razine predaje poruke odabranom protokolu transportne razine i prima poruke od tog protokola preko pripadnog softverskog sučelja koje se naziva utičnicom (socket). Utičnica je softverski element koji povezuje aplikaciju sa odabranim protokolom transportne razine. Aplikacija predaje podatkovne sadržaje transportom sloju mreže na taj način da ih upisuje u svoju utičnicu prema protokolu transportne razine, koji te sadržaje onda prenosi na utičnicu zadanog procesa na udaljenom domaćinu.

Utičnicu pokreće aplikacija, ali i protokol transportne razine kad donosi zahtjev serveru za uspostavu TCP veze, koji dolazi od nekog klijenta. Utičnica je općenito proces pomoću kojeg, i mjesto (memorijski prostor) na kojem, aplikacija predaje sadržaje za prijenos protokolu transportne razine, i prima od tog protokola sadržaje koji su upućeni toj aplikaciji. Slika 3.1 ilustrira položaj i ulogu utičnice, koje smo opisali iznad.

4

Slika 3.1 Položaj i uloga utičnice

Utičnica je sučelje između jednog elementa aplikacijske razine i jednog protokola transportne razine računalne mreže. Utičnicu se programira uz pomoć sučelja za programiranje aplikacija (Application Programming Interface - API). Za API se kaže da je to "skup alata" (napisanih funkcija i procedura) od kojih se sastavlja aplikaciju; kaže se i da je to skup metoda (funkcija) za komuniciranje između dvaju sustava. Ovdje je API oboje; dakle, to su "komadi softvera" od kojih se izrađuje utičnicu, koja definira i izvodi komunikaciju između jedne aplikacije i transportnog sloja.

Onaj tko oblikuje mrežnu aplikaciju i piše programe koji je realiziraju, oblikuje procese i ekrane na aplikacijskoj strani utičnice; pritom piše i utičnicu, koju se isto izrađuje programski, zajedno s aplikacijom. Kod izrade mrežne aplikacije i pripadne utičnice, proizvođač aplikacije koristi neki protokol transportne razine mreže, ali nema mogućnost mijenjati taj protokol ni njegove usluge prijenosa. Proizvođač aplikacije bira protokol transportne razine (TCP ili UDP) čije će usluge koristiti njegova aplikacija; taj izbor vrši se u okviru pisanja utičnice. Proizvođač aplikacije (i utičnice) postavlja neke parametre na utičnici, koji se odnose na transportni protokol čije usluge koristi, ali te mogućnosti su ograničene. Takvi parametri su uglavnom veličina nekog memorijskog prostora (bafera) i dužina segmenata sa kojima odabrani protokol transportne razine prenosi poruke dane aplikacije.

U okviru jedne komunikacijske sesije, procesi (klijent i server) mogu razmijeniti mnogo poruka (u oba smjera) preko jedne TCP veze. TCP veza između dvaju udaljenih procesa traje i koristi se za prijenos podataka, sve dok jedan od tih dvaju procesa ne pokrene postupak njezinog prekida. TCP veza je tipa full-duplex, što znači da preko takve veze mogu oba procesa (komunikatora) istodobno slati poruke drugom procesu, kao i primati poruke od njega.

Drugi element transportne razine Interneta je UDP sustav. UDP ne uspostavlja postojane veze između komunikatora; umjesto toga, taj sustav prenosi svaku jedinicu podataka sa izvora na odredište na temelju adrese odredišta. Adresu odredišta (za svaku jedinicu) pritom čine IP adresa domaćina i port aplikacije na tom domaćinu, kojem je ta jedinica podataka upućena.

Ovdje nema početnog rukovanja u tri koraka između klijenta i servera, jer se ovdje ne

5

uspostavlja postojanu (zasebnu) vezu za pojedinu komunikaciju, kako se to čini kod TCP sustava. Ovdje server prihvaća i obrađuje svaku jedinicu podataka zasebno, bez obzira što mnoge jedinice podataka mogu biti dijelovi iste komunikacije, odnosno istog posla kojeg neki klijent želi obaviti uz pomoć danog servera.

Kod izrade mrežne aplikacije, bira se onaj protokol transportne razine koji je najpogodniji za tu aplikaciju. Izradom softverske utičnice prema tom protokolu, aplikacija odabire taj protokol i definira proces komunikacije s njim. Na transportnoj razini koriste se uglavnom protokoli TCP i UDP. Protokoli transportne razine razlikuju se prema nekoliko osnovnih svojstava među koje spadaju pouzdanost prijenosa, brzina rada (prijenosa), veličina kašnjenja, i mogućnosti zaštite komunikacije i sadržaja.

Paketi podataka mogu biti izgubljeni ili iskrivljeni putem, u procesu prijenosa mrežom; paketi mogu biti odbačeni na nekom usmjerivaču na kojeg su stigli u trenutku kad je njegov prijemni bafer bio pun. Manji gubici podataka u prijenosu nisu od presudne važnosti za uspješan rad nekih mrežnih aplikacija. Naprimjer, kod izravnog video prijenosa, manja iskrivljenja na pojedinim snimkama nisu naročito važna. S druge strane, neke mrežne aplikacije zahtijevaju potpuno ispravan prijenos podataka. Naprimjer, greške u prijenosu kod financijskih transakcija bile bi neprihvatljive; greške u prijenosu prevedenog programa iskrivile bi taj program i učinile ga neupotrebljivim. Za izravan video prijenos, brzina prijenosa je važnija od potpune točnosti prijenosa; za financijske transakcije i softver, točnost prijenosa je bitno važnija od brzine.

Različitim aplikacijama trebaju prijenosni kanali različitih svojstava; zato je razvijeno više protokola transportne razine. Za onaj protokol koji jamči ispravan prijenos informacijskih sadržaja kaže se da pruža uslugu pouzdanog prijenosa podataka (reliable data transfer). U mreži Internet, pouzdan prijenos pruža protokol transportne razine TCP. Drugi protokol transportne razine u Internetu je protokol UDP, koji pruža uslugu nepouzdanog prijenosa podataka. To znači da kod korištenja protokola UDP, neki podaci koje pošiljatelj šalje mogu biti trajno izgubljeni na putu i nikad ne stići na odredište. Nepouzdan protokol omogućava postizanje veće brzine prijenosa, te je zato prikladan za one aplikacije kod kojih je brzina prijenosa važnija od potpune točnosti prijenosa sadržaja. Takve su aplikacije koje vrše izravan prijenos zvučnih i video sadržaja. Za takve aplikacije kaže se da toleriraju gubitke informacijskih sadržaja. Sa porastom razmjera gubitaka paketa u procesu njihovog prijenosa, opada kvaliteta prenijetih informacijskih sadržaja, a time i kvaliteta komunikacije.

Raspoloživa propusnost veze za prijenos sadržaja pojedine aplikacije varira u zavisnosti od toga koliko je ta veza trenutno opterećena prenošenjem sadržaja za druge mrežne aplikacije. Da bi uspješno radile, neke aplikacije trebaju imati neku zajamčenu (trajnu) propusnost veze; to znači, mogućnost da u svakom trenutku dostavljaju sadržaje na odredište određenom brzinom, kao i da dobivaju sadržaje određenom brzinom. Zato je potrebno da postoje protokoli transportne razine koji mogu jamčiti aplikacijama određenu propusnost, odnosno brzinu prijenosa sadržaja od izvora do odredišta. Zajamčena propusnost potrebna (važna) je kod aplikacija za telefonsku (audio) komunikaciju i za izravnu video komunikaciju (video prijenose i telekonferencije). Za aplikacije koje trebaju određenu propusnost da bi mogle normalno raditi, kaže se da su osjetljive na širinu frekventnog pojasa.

Internet radi prema načelu usmjeravanja paketa, i ne uspostavlja postojane putove između komunikatora. Zato u Internetu nema protokola transportne razine koji bi mogao potpuno jamčiti propusnost veze (brzinu prijenosa) za potrebe neke aplikacije. Isto vrijedi za veličinu kašnjenja. Ali postoje metode rada usmjerivača koje omogućuju da mreža ostvari određenu propusnost i veličinu zadržavanja (kašnjenja) u prijenosu podataka za određene aplikacije. Te metode zasnivaju se na davanju određenih prioriteta određenim aplikacijama (to jest, njihovim paketima i segmentima) na usmjerivačima. Među aplikacije koje trebaju određenu propusnost (brzinu prijenosa) spadaju aplikacije koje rade u realnom vremenu, poput Internet telefonije, mrežnih video igara, i raznih video prijenosa i telekonferencija. Protokoli transportne razine Interneta ne

6

daju jamstva po pitanju propusnosti i kašnjenja. Ali prikladnim metodama rada usmjerivača i aplikacija postiže se uspješan rad i onih mrežnih aplikacija koje su osjetljive na propusnost mreže (prijenosa). Takve aplikacije obično rade dovoljno dobro, sve dok propusnost koju mreža pruža nekoj danoj aplikaciji ne padne ispod određene razine.

Za ostvarenje komunikacije između dvaju procesa neke mrežne aplikacije, koji se izvode na različitim domaćinima, potrebno je da svaki od tih procesa bude jednoznačno određen (adresiran) u računalnoj mreži. Takvu oznaku (adresu) procesa u Internetu općenito tvori par koji čine adresa domaćina (IP) i port na tom domaćinu; dakle, par oblika: < IP, Port >

IP adresa je niz od 32 bita (u IPv4), odnosno od 128 bitova (u IPv6) koji jednoznačno označava jedan čvor mreže, ili točnije, jedno sučelje čvora prema mreži, jer jedan čvor mreže (računalo) može imati više IP adresa. Uzima se da jedna IP adresa jednoznačno određuje jednog domaćina u globalnoj mreži Internet, ali zbog pomanjkanja IP adresa (verzije IPv4) koriste se neka rješenja (kao što je Network Address Translator - NAT) koja čine da to nije uvijek tako. Sustav NAT ima na raspolaganju jedan broj IP adresa, koje privremeno dodjeljuje znatno većem broju završnih sustava, obično klijentskog tipa, na kojima rade klijentski dijelovi aplikacija (poput preglednika i drugih). To znači da oni nemaju fiksnu (stalnu) IP adresu, ali imaju (dobivaju od NATa) jedinstvenu IP adresu onda kad se uključuju u mrežu.

Pored IP adrese domaćina na kojeg treba prenijeti neku poruku, treba odrediti i kojem procesu na tom domaćinu treba predati tu poruku. Jer na jednom domaćinu može istodobno (paralelno) raditi više mrežnih aplikacija. Zato svaka mrežna aplikacija ima svoj "broj (oznaku) ulaznih vrata" (port number), ili kraće, svoj broj porta, ili još kraće, svoj port. Naprimjer, web server kao aplikacija (na danom domaćinu) označen je brojem porta 80, odnosno koristi port 80. Server za računalnu poštu, kao dio aplikacije računalne pošte, koristi broj porta 25. Na web adresi

http://www.iana.orgdana je lista portova za standardne (poznatije) internetske aplikacije (protokole). Kad netko razvije neku novu mrežnu aplikaciju, onda toj aplikaciji treba dodijeliti i neki broj porta, kojeg nije već zauzela neka druga mrežna aplikacija.

Pored jednoznačnih adresa, za ostvarenje komunikacije između međusobno udaljenih procesa jedne mrežne aplikacije potrebno je odrediti i niz drugih stvari. Između ostalog, potrebno je definirati:

* Tipove poruka koje procesi međusobno razmjenjuju; osnovni tipovi su obično poruka-zahtjev i poruka-odgovor.

* Sintaksu (formu, ispravan oblik) za svaki tip poruke. Takve definicije sadrže opise funkcija, tipove i veličine njihovih parametara (dužine polja za njihov upis), načine odvajanja parametara (polja), i slične stvari.

* Semantiku (značenje/učinke) poruke; za to je potrebno definirati značenje i učinak svakog elementa (parametra, polja) dane poruke.

* Procese komunikacije, odnosno pravila koja određuju kada (u kojim situacijama) i na koji način proces može/treba poslati poruku drugom procesu, odnosno odgovoriti na poruku drugog procesa.

Sve te stvari i mnoge druge, definirane su i opisane protokolima, čijim implementacijama nastaju mrežne aplikacije. U tablici na slici 3.2 navedene su neke poznate mrežne aplikacije, nazivi njihovih protokola i RFCi u kojima su ti protokoli definirani, te protokoli transportne razine koje koriste te aplikacije.

7

Slika 3.2 Aplikacije, RFCi i protokoli

Protokol TCP koriste one aplikacije za koje je važna pouzdanost prijenosa podataka; dakle, prijenos bez iskrivljenja sadržaja. Aplikacije internetske telefonije obično koriste protokol UDP, jer je kod tih aplikacija bitna brzina prijenosa, više nego točnost. Ispravljanje grešaka (ponovno slanje iskrivljenih i izgubljenih paketa) ovdje ne bi imalo smisla jer bi ponovo poslani paketi stizali prekasno: govor preko telefona ide dalje. Osim toga, govor se može uspješno reproducirati (na strani primatelja) i uz određeni gubitak informacijskih sadržaja u prijenosu.

Prijenos podataka između serverskog i klijentskog dijela aplikacije trebao bi biti siguran; to ovdje znači zaštićen od raznih vrsta napada. U računalnim mrežama sigurnost i zaštita imaju tri osnovne dimenzije: (1) zaštita povjerljivosti (tajnosti) sadržaja, (2) utvrđivanje autentičnosti komunikatora, i (3) zaštita integriteta poruke - to jest, mogućnost da se utvrdi da li je došlo do namjernog iskrivljenja sadržaja neke poruke. Problematika sigurnosti je opsežna i složena; o tim stvarima govorimo u 4. poglavlju.

Protokoli transportne razine TCP i UDP ne sadrže funkcije za ostvarenje sigurnosti mrežne komunikacije, tako da se pitanja sigurnosti općenito trebaju rješavati u okviru pojedinih aplikacija. Sigurnost i zaštita komunikacije neophodni su za uspješan rad mnogih aplikacija. Zato je u sustavu Internet razvijen jedan skup protokola koji definiraju i ostvaruju procese sigurnosti i zaštite komunikacije, nezavisno od pojedinačnih aplikacija. Taj skup protokola nazvan je slojem sigurnih utičnica (secure sockets layer - SSL) i mogu ga koristiti razne aplikacije. Sustav SSL opisuje se kao "dodatak" TCP protokolu, ali pojam "sloj" u njegovom nazivu pokazuje da se ovdje radi o jednom međusloju koji je smješten između sloja aplikacija i transportnog sloja.

Protokol TCP "dopunjen i poboljšan" sa SSL radi iste poslove kao i bez SSLa; ali dodani skup sigurnosnih protokola čini da TCP prijenos sadržaja između dvaju komunikatora bude ne samo pouzdan, nego i siguran (zaštićen, u smislu u kojem je to rečeno iznad). SSL pruža usluge šifriranja sadržaja poruka, utvrđivanja autentičnosti (identiteta) komunikatora, i zaštite integriteta (neizmijenjenosti) poruke. Kurose i Ross ističu kako SSL nije jedan novi (treći) protokol transportne razine Interneta, nego je to "poboljšanje protokola TCP, pri čemu je to poboljšanje implementirano u aplikacijskom sloju" (str. 96). Ova tvrdnja izgleda neobično: TCP, kao element transportnog sloja "poboljšan" je (sa SSL) u aplikacijskom sloju.

Prema OSI modelu, između transportnog sloja i sloja aplikacija nalaze se sloj sesije i sloj prezentacije; ta dva sloja se u literaturi obično izostavljaju (čime model dobiva pet slojeva), uz obrazloženje da se njihove sadržaje može uključiti u transportni sloj ili (češće) u sloj aplikacija.

8

Međutim, gornja tvrdnja o SSL entitetu pokazuje da između transportnog i aplikacijskog sloja ipak postoje (i potrebne su) razne stvari. Problemi sigurnosti i zaštite komunikacije pojavili su se nakon što su definirani OSI model i TCP/IP model; ti problemi postajali su sve veći zajedno sa širenjem računalnih mreža i rastom intenziteta korištenja tih mreža. Precizno govoreći, protokoli i softver koji se odnose na sigurnost, ne spadaju na transportnu razinu, a ne stoje udobno ni na aplikacijskoj razini. Skup protokola i usluga iz područja sigurnosti i zaštite tvori jedan međusloj između aplikacijskog i transportnog sloja, bez obzira na to što neki taj međusloj nazivaju "dopunom" TCPa koja je implementirana na aplikacijskoj razini. Da bi se izbjeglo množenje slojeva, nove elemente mrežnog sustava pokušava se nekako svrstavati u stare slojeve.

Da bi mrežna aplikacija mogla koristiti sigurnosne usluge međusloja SSL, potrebno je da bude instaliran SSL softver na klijentskoj i na serverskoj strani te aplikacije. SSL se smješta između aplikacije i TCP protokola; to znači da aplikacija ima utičnicu prema SSLu, a SSL ima utičnicu prema TCP protokolu. Aplikacija šalje sadržaje na taj način da ih upisuje u svoju utičnicu kojom je vezana na SSL. SSL prihvaća te sadržaje i izvodi zahtijevane operacije vezane uz sigurnost (šifriranje i drugo); zatim te sadržaje upisuje u svoju utičnicu prema TCP protokolu.

TCP prenosi te zaštićene (šifrirane i drugo) sadržaje preko mreže na njihovo odredište, gdje stižu na TCP utičnicu prema SSL međusloju na odredištu. SSL prihvaća prispjele sadržaje, izvodi operacije zadane sustavom sigurnosti, i primljene sadržaje upisuje u utičnicu one aplikacije kojoj su ti sadržaji namijenjeni. O sigurnosti govorimo u 4. poglavlju.

Mnogi protokoli definirani (opisani) su u pripadnim RFCima, tako da su njihovi opisi javno dostupni. RFCi su ponekad prilično opsežni i zahtjevni za čitanje. Opis protokola aplikacijske razine HTTP, koji definira proces komunikacije između web preglednika i web servera, dan je u RFC 2616. Kratica HTTP dolazi od "HyperText Transfer Protocol"; riječ "transfer" iz tog naziva slična je riječi "transport", ali to je protokol aplikacijske razine. Protokol HTTP definira jezik i proces komunikacije između web preglednika i web servera, u okviru kojeg server dostavlja pregledniku sadržaje onih web stranica (objekata) koje je preglednik tražio. Proces prijenosa HTTP poruka izvodi protokol TCP (sa transportne razine), kako je to opisano ranije.

Ako neki proizvođač softvera napravi web preglednik koji je oblikovan u skladu sa RFC opisom HTTPa, onda će taj preglednik moći dosizati (tražiti i dobivati) sadržaje web stranica sa svakog web servera koji je oblikovan u skladu sa opisima (definicijama) koje su dane u tom RFCu.

Mrežna aplikacija je često opsežnija od jednog mrežnog protokola. Mrežna aplikacija može biti opsežan softverski sustav čiji su dijelovi oblikovani prema raznim protokolima. Naprimjer, web sustav se obično promatra kao jednu aplikaciju (tipa klijent-server) koja omogućava korisnicima da dosežu (traže i dobivaju) sadržaje web stranica, koje su pohranjene na web serverima. HTTP kao protokol aplikacijske razine, definira oblike poruka koje razmjenjuju web preglednik (klijent) i web server, kao i redoslijed tih poruka u komunikaciji, da bi se time ostvario prijenos (kopije) sadržaja zadane (tražene) web stranice sa servera na klijenta. Ali HTTP je samo jedan od protokola (iako bitan) prema kojima su oblikovane komponente web sustava kao cjeline. Drugi protokoli određuju način oblikovanja sadržaja web stranica (jezik HTML), način rada web preglednika (naprimjer, način postupanja s apletima), način rada web servera i drugih komponenata web sustava. Dakle, mrežna aplikacija obično sadrži više elemenata nego što ih definira jedan protokol, tako da su njeni dijelovi oblikovani prema definicijama koje su dane u različitim protokolima.

Osnovu aplikacije računalne pošte čini protokol SMTP (Simple Mail Transfer Protocol), koji je opisan u RFC 5321. Ali aplikacija računalne pošte (kao cjelina) sastoji se od većeg broja komponenata, koje su oblikovane prema specifičnim protokolima.

RFC 959 definira mrežnu aplikaciju FTP, koja je namijenjena prijenosu datoteka. Softver koji realizira mrežnu aplikaciju koja je definirana sa RFC 959 napravljen je odavno. Ali neki proizvođač softvera može napisati taj softver nanovo, naprimjer sa ciljem da njegova softverska

9

realizacija istog protokola (RFC 959) bude operativno učinkovitija od postojeće, i da ima estetski ljepše napravljeno sučelje.

Jedan proizvođač može napraviti novi softver klijentske strane nekog danog protokola, a drugi proizvođač može napraviti novi softver serverske strane istog protokola. Ako proizvođači softvera oblikuju svoje proizvode prema odredbama danog protokola, njihovi proizvodi biti će kompatibilni i raditi će dobro jedan s drugim.

S druge strane, neke mrežne aplikacije su vlasničke (proprietary); to ovdje znači da su te aplikacije vlasništvo nekih tvrtki ili pojedinaca. Vlasničke aplikacije su isto rađene prema nekim "nacrtima", koje možemo zvati protokolima, ali protokoli vlasničkih aplikacija obično nisu javno poznati. Korisnik može kupiti i koristiti neku vlasničku aplikaciju, ali time neće dobiti uvid u njenu unutarnju strukturu, odnosno u protokol prema kojem je napravljena. Mnoge aplikacije (i protokoli) tipa P2P su vlasničke. Drugi proizvođači softvera mogu pokušati napraviti neku aplikaciju Ay koja "radi isto" što i neka popularna vlasnička aplikacija Ax, ali ti proizvođači nemaju uvid u nacrt (protokol) prema kojem je napravljena vlasnička aplikacija Ax. Dakle, sličnost se može postići na operativnoj razini, ali unutarnja struktura ostaje nepoznata.

Postoji mnogo mrežnih aplikacija i razvijaju se nove. U ovom poglavlju prikazati ćemo strukturu i način rada nekoliko mrežnih aplikacija koje se široko koriste i koje pokazuju tipične strukture i načine rada mrežnih aplikacija. Opisujemo web sustav (protokol HTTP), sustav za prijenos datoteka (FTP), sustav računalne pošte (protokol SMTP), sustav imena domena (DNS), i neke mrežne aplikacije tipa P2P.

3.2 Web sustav i protokol HTTP

Središnji protokol web sustava je protokol HTTP (HyperText Transfer Protocol). HTTP protokol je implementiran (realiziran) sa dva podsustava, od kojih se jednog naziva klijentom a drugog serverom. Ta dva podsustava rade na različitim računalima i međusobno komuniciraju razmjenom poruka čiji oblici i značenja (učinci) su definirani HTTP protokolom. HTTP isto tako definira kada i na koji način web klijent (preglednik) i web server razmjenjuju poruke.

Definirajmo još neke pojmove. Web stranica, koju se naziva i dokumentom, sastoji (ili tvori) se od web objekata. Web objektom naziva se svaka datoteka koja sadrži neki sadržaj od kakvih se tvore web stranice. Web objekt je HTML datoteka koja sadrži HTML kodni zapis osnovne strukture i tekstualnog sadržaja web stranice; web objekti su datoteke koje sadrže digitalne zapise slika (u GIF ili JPEG formatu), datoteke koje sadrže digitalne zapise zvuka (u formatu MP3), ili digitalne zapise video sadržaja (u formatu MPEG); web objekti su datoteke koje sadrže Java aplete, i razne druge sadržaje. Svaki web objekt treba biti oblikovan i postavljen na web server na takav način da se može adresirati sa jednom URL (web) adresom.

URL (uniform resource locator) možemo prevesti (ili opisati) kao "jedno-oblični označitelj položaja izvora"; pritom je "izvor" (resource) onaj sadržaj čiju kopiju klijent traži od servera, da bi iz nje proizveo web stranicu. URL nazivamo i web adresom; ta adresa sastoji se od dva osnovna dijela: od tekstualne adrese domaćina (na kojem se nalazi adresirani objekt) i od puta do tog objekta (datoteke) na tom domaćinu. Naprimjer, u URL adresi

http://inf.uniri.hr/~mradovan/index.htmlprvi dio (inf.uniri.hr) nakon oznake protokola (http) i odvajatelja (://) je tekstualna adresa domaćina, dok drugi dio te adrese (~mradovan/index.html) pokazuje put do osnovne HTML datoteke (na tom domaćinu), koja nosi naziv "index.html".

Kod standardnih web stranica, preglednik tvori web stranicu iz sadržaja HTML datoteke koja sadrži osnovni kodni (HTML) zapis koji određuje strukturu stranice, i od nekoliko dodatnih

10

objekata čije URL adrese su sadržane u osnovnom HTML zapisu. Naprimjer, uzmimo da se neka web stranica sastoji od datoteke sa osnovnim HTML kodnim zapisom, od tri fotografije (u JPEG formatu) koje su zapisane svaka u svojoj datoteci, i od dva apleta koji su zapisani svaki u svojoj datoteci. Ta web stranica sastoji se od ukupno šest objekata; dakle, web preglednik proizvodi tu web stranicu od navedenih šest objekata.

Web preglednik traži osnovnu HTML datoteku neke web stranice, koja se nalazi na danoj URL adresi; taj zahtjev stiže do web servera na domaćinu na kojem se nalazi tražena datoteka; taj server na to dostavlja pregledniku kopiju tražene datoteke (objekta). Datoteka sa osnovnim HTML zapisom web stranice sadrži URL adrese ostalih objekata koji su potrebni za tvorbu te web stranice. Ti objekti mogu se nalaziti na istom ili na različitim serverima; u oba slučaja, preglednik traži od servera (jednog ili više) da mu dostavi ostale objekte koji su potrebni za tvorbu dane web stranice. Po primitku svih objekata, web preglednik dovršava i prikazuje traženu web stranicu na ekranu.

Web preglednik implementira klijentsku stranu HTTP protokola, dok web server implementira serversku stranu HTTP protokola. Web objekti su pohranjeni na web serverima; svaki takav objekt ima svoju URL adresu. Jedan od poznatijih web preglednika je Internet Explorer; jedan od poznatijih web servera je Apache.

Protokol HTTP definira na koji način web klijent (preglednik) traži sadržaje web stranice od web servera i na koji način web server dostavlja sadržaje web stranice klijentu. Slika 3.3 ilustrira proces komunikacije dvaju klijenata sa jednim serverom.

Slika 3.3 Komunikacija klijenata sa serverom

Kad korisnik zada pregledniku URL adresu neke web stranice (ili klikne na neku vezu na web stranici), preglednik upućuje poruku-zahtjev odgovarajućem serveru da mu dostavi sadržaj koji se nalazi na toj URL adresi. Web server prima tu poruku-zahtjev i na nju odgovara, pri čemu njegov odgovor sadrži kopiju tražene datoteke koja se nalazi na danoj URL adresi. Iz tako dobivenog sadržaja, preglednik pokreće postupak tvorbe web stranice na ekranu korisnika.

Iznesimo malo podrobniji opis procesa kojeg smo naznačili iznad.

11

Kad korisnik pokrene preglednik na svom računalu i zada mu neku URL adresu, preglednik pokreće postupak uspostavljanja TCP veze između sebe (kao klijenta) i web servera koji se nalazi na onom domaćinu čija je adresa sadržana u zadanoj URL adresi.

Uspostava takve TCP veze odvija se u tri koraka koje opisujemo u nastavku. U trećem koraku, preglednik (klijent) ujedno šalje serveru URL adresu čiji sadržaj traži od servera. U prvoj poruci jedne takve komunikacijske sesije preglednik obično traži HTML datoteku koja definira strukturu (i sadrži tekstualne elemente) jedne web stranice.

Server prima zahtjev klijenta i u odgovoru na taj zahtjev dostavlja klijentu kopiju tražene datoteke. Web server bi pritom mogao pokrenuti postupak prekida te TCP veze (jer odgovorio je na zahtjev) ali server to ne čini, nego daje klijentu mogućnost da po istoj TCP vezi šalje nove poruke-zahtjeve, sve dok ima takve potrebe.

Datoteka sa HTML zapisom strukture web stranice sadrži URL adrese onih web objekata (slika, videa, zvuka, apleta) iz kojih se sastoji (i proizvodi) tražena web stranica. Kad preglednik dobije takvu HTML datoteku, onda za svaki URL koji je sadržan u toj datoteci, šalje jednu HTTP poruku-zahtjev odgovarajućem serveru sa zahtjevom da mu pošalje kopiju objekta koji se nalazi na toj URL adresi.

Ako URL adrese navedene u osnovnoj HTML datoteci web stranice vode prema web serveru Sj na domaćinu Dk sa kojeg je stigla osnovna HTML datoteka, onda TCP veza između danog preglednika Pi i servera Sj već postoji. Tada preglednik Pi šalje serveru Sj po jednu poruku-zahtjev za svaki od objekata čije su URL adrese navedene u osnovnoj HTML datoteci. Preglednik šalje zahtjeve po postojećoj TCP vezi, jednog za drugim; server prima te zahtjeve i redom odgovara na svakog od njih, pri čemu svaki od odgovora donosi klijentu onaj objekt kojeg je tražio u svom zahtjevu.

Ako neka od URL adresa koje su navedene u osnovnoj HTML datoteci tražene web stranice pokazuje na nekog drugog domaćina (a ne Dk, na kojem se nalazi osnovna HTML), onda za svaku takvu URL adresu preglednik Pi uspostavlja TCP vezu sa web serverom Sm na odgovarajućem domaćinu Dm i šalje mu po toj vezi svoju poruku-zahtjev da mu Sm dostavi traženi sadržaj. Pozvani web serveri odgovaraju na primljene zahtjeve.

Kad preglednik na taj način sakupi sve objekte koji su mu potrebni za tvorbu web stranice koju je korisnik tražio od njega, onda preglednik proizvodi tu stranicu i prikazuje je na ekranu. Proces proizvodnje stranice na ekranu obično se odvija paralelno sa prikupljanjem objekata koji su potrebni za njenu tvorbu, ali web stranicu se ne može dovršiti dok se ne prikupi sve objekte koji su potrebni za njenu proizvodnju.

12

Slika 3.4 Komunikacija web klijenta i web servera

Slika 3.4 ilustrira proces komunikacije između web klijenta i web servera. Klijent najprije pokreće postupak uspostave TCP veze sa serverom; zatim preko te veze traži od servera jedan web objekt (datoteku sa dane URL). Server odgovara na klijentov zahtjev, pri čemu u svom odgovoru dostavlja klijentu traženi objekt. Nakon toga klijent ili server mogu pokrenuti postupak prekida te TCP veze. Ali to obično ne čine, sve dok klijent ne zatraži i dobije od servera sve one objekte koji su mu potrebni za tvorbu dane web stranice (i koji se nalaze na tom serveru).

Postupak uspostavljanja TCP veze naziva se rukovanjem u tri koraka (three-way handshake); izraz "three-way" može se prevesti i drukčije, ali ovako je dovoljno dobro. Klijent počinje taj proces slanjem jednog upravljačkog TCP segmenta serveru; server na to odgovara slanjem svog upravljačkog TCP segmenta klijentu; konačno, klijent odgovara na odgovor servera; ako su sva tri koraka razmjene upravljačkih sadržaja izvedena uspješno, onda je time uspostavljena jedna TCP veza između danog klijenta i servera.

U trećem koraku rukovanja, sa kojim je veza uspostavljena, klijent ujedno šalje svoju

13

poruku-zahtjev serveru, sa kojim traži da mu server dostavi sadržaj datoteke koja se nalazi na danoj URL adresi (na tom serveru). Server odgovara na taj zahtjev slanjem tražene datoteke.

Protokol aplikacijske razine HTTP koristi usluge protokola TCP sa transportne razine. Svaka komunikacijska sesija između HTTP klijenta (web preglednika) i HTTP servera počinje na taj način što klijent (preglednik) pokreće postupak uspostave TCP veze sa serverom na udaljenom domaćinu. Nakon uspostave TCP veze između preglednika Pi i pozvanog servera Sj, preglednik Pi i server Sj šalju i primaju poruke preko te TCP veze. TCP veza prenosi poruke (u TCP segmentima) između utičnice klijenta i utičnice servera (prema TCPu), i obrnuto.

TCP veza traje sve dok klijent (preglednik) ne dobije od servera sve web objekte koji su mu potrebni; nakon toga, klijent (koji je pokrenuo preoces uspostave veze), pokreće proces prekida te TCP veze. Ako klijent to ne učini, server pokreće proces prekida TCP veze nakon što protekne zadano vrijeme u kojem server nije primio nikakav zahtjev od klijenta.

HTTP protokol (web server) ne pamti usluge koje pruža pojedinim klijentima. Server će poslati istom klijentu isti sadržaj onoliko puta za redom koliko puta klijent zatraži taj sadržaj. Zato se za HTTP protokol (web server) kaže da je bezstanjski (stateless) protokol. Izraz "bezstanjski" ne zvuči lijepo, ali ni izraz "stateless" (u engleskom) nije ljepši ni precizniji. Navikli smo prihvaćati engleske nazive kao "normalne", ali ti nazivi su često nezgrapni i/ili neprecizni, tako da možemo koristiti poneki nezgrapan naziv i u hrvatskom jeziku. Inače, pojmom "stateless" (bez stanja) htjelo se reći ono što smo rekli iznad: da HTTP protokol (odnosno, web server) ne pamti poslove koje je izvršio za svoje klijente. To omogućava da server i njegov rad budu jednostavniji. Takvo pamćenje nije ni neophodno, jer klijenti mogu voditi računa o tome da ne traže od servera da za njih ponovno napravi onaj posao kojeg je već napravio (ako klijenti nemaju neke zle namjere prema serveru, naravno).

Za prijenos HTTP poruke između klijenta Ki i servera Si potrebno je između njih najprije uspostaviti TCP vezu. Postoje dva osnovna načina komunikacije između klijenta i servera: (1) sa ne-persistentnom TCP vezom i (2) sa persistentnom TCP vezom.

Kod rada sa ne-persistentnom vezom, server pokreće proces prekidanja TCP veze nakon što je u tu vezu uputio svoju poruku-odgovor na poruku-zahtjev klijenta. Ako klijent ima još poruka-zahtjeva za isti server, onda mora za svaku od tih poruka-zahtjeva ponovno uspostavljati TCP vezu sa tim serverom.

Kod rada sa persistentnom vezom, TCP veza čije je uspostavljanje pokrenuo klijent (web preglednik) da bi poslao svoj prvi zahtjev serveru, ostaje otvorena sve dok traje ta komunikacijska sesija između klijenta i servera. To klijentu omogućava da preko iste TCP veze traži (od istog servera) veći broj objekata koji su mu potrebni za tvorbu jedne web stranice, kao i da zahtjeva (pita) druge web stranice (i njihove objekte) koje se nalaze na istom serveru. Kod persistentne veze, server pokreće proces prekidanja TCP veze nakon što protekne neko zadano vrijeme od zadnjeg zahtjeva klijenta. Klijent može biti opterećen drugim procesima, tako da TCP vezu koju se predugo ne koristi, prekida server.

HTTP radi sa persistentnom vezom po difoltu, ali web preglednik i web server mogu se postaviti (konfigurirati) tako, da rade sa ne-persistentnom vezom. Svaki od dvaju načina rada ima neka dobra i neka loša svojstva. Kod rada sa nepersistentnom vezom, TCP veza između istog klijenta i servera često se uspostavlja (i prekida) više puta, da bi se izvršilo prijenos objekata koji tvore jednu web stranicu. Kod persistentne veze, dovoljno je da klijent uspostavi jednu TCP vezu prema nekom serveru; nakon toga može, nizom svojih zahtjeva, dobiti sve objekte sa tog servera koji su mu potrebni, bez da prekida i ponovno uspostavlja TCP vezu sa tim serverom.

Slabost rada sa persistentnim vezama je u tome što dovodi do loše iskorištenosti prijenosnog sustava, kao i do loše iskorištenosti kapaciteta servera. Server može održavati ograničen broj TCP veza; zato dugo zadržavanje TCP veza od strane nekih klijenata, koji te veze

14

ne koriste intenzivno, može dovesti do toga da drugi klijenti (web preglednici) ne mogu uspostaviti svoju TCP vezu sa nekim web serverom.

Komunikacija između klijenta i servera uz upotrebu ne-persistentnih veza je obično sporija nego kod persistentnih veza. Jedna web stranica se obično sastoji od više objekata, koji se obično nalaze na istom domaćinu (web serveru) kao i osnovna HTML datoteka te web stranice. Zato je obično bolje zadržati TCP vezu dok se ne prenesu svi objekti sa danog servera, nego prekidati i nanovo uspostavljati TCP vezu sa istim serverom za svaki objekt kojeg se prenosi sa tog servera.

Koristeći istu persistentnu TCP vezu, klijent može od istog servera tražiti i druge web stranice, jednu za drugom (klikanjem na veze). Server odgovara na zahtjeve klijenta redom, kako ih prima.

Proces uspostave i prekida TCP veze iziskuje izvršenje niza operacija na klijentu i na serveru, koje uključuju rezerviranje (i oslobađanje) memorijskih prostora za slanje i za primanje (bafera) i izvršenje niz drugih procedura. Zato uspostavljanje velikog broja TCP veza znatno opterećuje rad servera, koji često treba opsluživati (odgovarati na zahtjeve) više stotina ili tisuća klijenata u isto vrijeme (paralelno). Zbog toga HTTP protokol radi po difoltu sa persistentnim TCP vezama. Ali i takav način rada ima svoje nedostatke koje smo naveli iznad, tako da postoji mogućnost da se HTTP klijent i server postave na način da rade na ne-persistentan način. Kod persistentnih TCP veza, server pokreće proces prekidanja veze onda kad tom vezom ne dobiva zahtjeve od klijenta neko zadano vrijeme.

Jedan preglednik može uspostaviti više paralelnih (istodobnih) TCP veza sa istim web serverom. Na taj način može se ubrzati prijenos objekata sa istog servera na istog klijenta. Nakon što je od servera dobio osnovnu HTML datoteku neke web stranice, preglednik može vidjeti da mu je za izradu te stranice potrebno osam objekata (čije su URL adrese dane u toj HTML datoteci). Ako se ti objekti nalaze na istom serveru, preglednik može uspostaviti osam paralelnih TCP veza sa tim serverom i na taj način dobiti te objekte znatno brže nego sa osam uzastopnih zahtjeva, pri čemu se svakim zahtjevom traži jedan objekt. Paralelnost TCP veza ne smanjuje broj zahtjeva i odgovora, ali smanjuje potrebno vrijeme za njihovo izvršenje. Kaže se da web klijent (preglednik) može uspostavljati pet do deset paralelnih TCP veza (sa istim serverom).

Dakle, postoje tri osnovna načina komunikacije između HTTP klijenta i HTTP servera:(1) Sa ne-persistentnom vezom: TCP veza se uspostavlja za svaku poruku-zahtjev, i

prekida nakon svake poruke-odgovora.(2) Sa persistentnom vezom: TCP veza se uspostavlja na početku komunikacijske sesije, i

održava do kraja te sesije, tako da se svi zahtjevi i odgovori prenose preko iste TCP veze.(3) Uz uspostavljanje većeg broja paralelnih TCP veza između istog klijenta i servera; veze

mogu ovdje biti persistentne ili ne; u svakom slučaju, ovdje treba uspostaviti i prekinuti više TCP veza u okviru jedne komunikacijske seanse.

HTTP protokol ne definira cjelokupan rad web preglednika ni web servera, nego samo oblike i procese njihove međusobne komunikacije. HTTP ne definira vrste sadržaja web stranica, ni sredstva (alate) za njihovo oblikovanje. HTTP protokol definira prvenstveno jezik i proces komunikacije između web klijenta i web servera. Ostale elemente, koji zajedno tvore opsežan web sustav, kao jednu vrstu mrežne aplikacije (ili klasu aplikacija) definiraju razni drugi protokoli, od kojih su neki javni a neki privatni.

RFC 2616 sa kojim je definiran protokol HTTP, sadrži definicije oblika (formate) i opise učinaka (značenja) HTTP poruka koje međusobno razmjenjuju HTTP klijent (web preglednik) i HTTP server (web server). HTTP poruke dijele se u dvije osnovne grupe: poruke-zahtjevi (kraće, zahtjevi), i poruke-odgovori (kraće, odgovori).

Klijent upućuje serveru svoje poruke-zahtjeve, dok server na te zahtjeve odgovara svojim porukama-odgovorima. Pogledajmo jedan primjer poruke-zahtjeva.

15

GET /~mradovan/index.html HTTP/1.1Host: inf.uniri.hrConnection: closeUser-agent: Mozila/5.0Accept-language: sp

HTTP poruka klijenta sastoji se od nekoliko redaka-stavaka koji su napisani u čitljivom obliku. Kaže se da svaki redak završava "znakom za kraj retka", kojeg se ne piše, a kojeg se obično naziva <CRLF>, što je kratica od izraza "carriage return and a line feed". Ta kratica se često susreće, ali je nitko ne objašnjava; to je "znak za kraj retka", koji se ne ispisuje na papir i kojeg se ne vidi, ali ima svoj kodni zapis u računalu; taj kodni zapis određuje na koji način će jedna poruka biti razlomljena na redove kod njenog ispisa na ekran.

Iza zadnjeg pisanog retka poruke slijedi jedan prazan redak, koji označava završetak poruke. Kaže se da taj prazan redak sadrži samo (nevidljivi) znak za završetak retka i za prelazak u novi red <CRLF>; rekli smo da taj znak koji se ne vidi na papiru (osim kao bjelina) ima svoj kodni zapis u računalu, tako da se u računalu "vidi" i može služiti kao oznaka za kraj poruke.

Poruka-zahtjev klijenta može imati od jednog retka na više. Prvi redak takve HTTP poruke-zahtjeva naziva se retkom zahtjeva (request line), dok se ostali redovi nazivaju redovima zaglavlja (header line).

Redak zahtjeva ima tri elementa, koji su odvojeni bjelinama.Prvi element naziva se metodom; njime se zadaje operaciju čije se izvršenje zahtijeva (od

servera) ovom porukom-zahtjevom. Ovdje je ta metoda/operacija GET. Pojam "get" ima više značenja; u osnovi, "to get" znači dobiti; valjda klijent želi "dobiti" datoteku koju traži.

Drugi element definira jednu datoteku (na nekom web serveru) na koju se odnosi operacija zadana prvim elementom. Ovdje je to datoteka /~mradovan/index.html.

Treći element pokazuje prema kojoj verziji HTTP protokola je oblikovan klijent (preglednik) koji šalje ovu poruku-zahtjev.

HTTP poruke-zahtjevi mogu sadržavati razne metode (operacije), među koje spadaju GET, POST, HEAD, PUT, i DELETE. Većina HTTP poruka-zahtjeva sadrži metodu GET. Tom metodom web preglednik traži od web servera da mu dostavi objekt (kopiju datoteke) čiji su naziv i položaj (na tom serveru) zadani drugim elementom istog retka.

Drugi redak zahtjeva (koji je prvi "redak zaglavlja") sadrži Internet adresu domaćina (IP) na kojem se nalazi traženi objekt (iz prvog retka). Da bi mogao uputiti svoju HTTP poruku nekom serveru, klijent treba najprije uspostaviti TCP vezu sa tim serverom; klijent normalno uspostavlja TCP vezu sa web serverom na onom domaćinu na kojem se nalazi datoteka koju traži; zato se čini da ovaj redak zahtjeva nije potreban, jer da bi HTTP poruka bila poslana odgovarajućem serveru, treba već postojati TCP veza sa tim serverom. U ovoj situaciji zadavanje adrese domaćina zaista nije potrebno, ali ovaj podatak o adresi domaćina potreban je onda kada preglednik ne šalje svoje zahtjeve izravno ciljanom domaćinu, nego to čini preko sustava koji se naziva proxy, o kojem govorimo kasnije.

Stavkom "Connection: close" klijent poručuje serveru da pokrene proces raskidanja (zatvaranja) TCP veze preko koje je primio ovaj zahtjev, odmah nakon što tom vezom pošalje klijentu odgovor na ovaj zahtjev. Dakle, ovdje klijent traži od servera da se ova komunikacija izvede uz upotrebu ne-persistentne veze, na način kako smo to opisali iznad.

U stavku "User-agent", HTTP klijent (web preglednik) daje web serveru podatke o sebi. Ovaj podatak služi zato da server može oblikovati svoje poruke u skladu s mogućnostima klijenta. Server može usto sadržavati različite verzije istog objekta; na temelju podatka o vrsti preglednika, server može pregledniku poslati onu verziju traženog objekta, koja je prikladna za tog preglednika.

Zadnjim stavkom poruke-zahtjeva, klijent traži da mu server dostavi "španjolsku verziju" traženog objekta, ako takva verzija postoji na tom serveru; ako ne postoji, onda server šalje onu

16

verziju traženog objekta koju šalje po difoltu.Protokol HTTP definira velik broj opcionalnih stavaka, poput stavka "Accept-language"

koji je ovdje naveden. Klijenti mogu koristiti ovakve stavke zato da čim bolje definiraju (opišu) svoje poruke-zahtjeve, koje upućuju serverima.

Poruka-zahtjev općenito sadrži i tijelo. Kod GET naredbe (metode), klijent samo zahtjeva od servera da mu dostavi danu web stranicu (web objekt), tako da je tijelo poruke klijenta prazno. Ali klijent (korisnik) može tražiti web stranicu (odgovor) od servera za neke zadane parametre. U tom slučaju, korisnik upisuje te parametre u sučelje (web stranicu) preglednika ili aplikacije, a preglednik (aplikacija) onda šalje te parametre serveru u tijelu svoje poruke serveru. Naprimjer, klijent traži od servera podatke o knjigama nekog autora; da bi server mogao odgovoriti na takvo pitanje, klijent mu treba dostaviti ime autora o kojem se radi. U takvom slučaju, web preglednik šalje web serveru svoju poruku-zahtjev koja sadrži metodu POST; kod primjene te metode, tijelo poruke sadrži one parametre koje je korisnik zadao pregledniku, obično njihovim upisivanjem u polja neke forme na ekranu koja je namijenjena tome da korisnik definira (opiše) svoje zahtjeve danoj web aplikaciji. Takve forme su dio sučelja (ili jedno od sučelja) aplikacije.

Dakle, kad korisnik zadaje neke parametre (u formu), koji definiraju njegov zahtjev (upit), onda preglednik šalje serveru svoju poruku-zahtjev koja sadrži metodu POST, a parametri koje je zadao korisnik sadržani su u tijelu te poruke-zahtjeva.

Parametre koje zadaje korisnik (njihovim upisivanjem u formu na web stranici), klijent može prenijeti serveru i onda kad koristi metodu GET (kod koje je tijelo poruke prazno). U tom slučaju, preglednik dodaje te parametre iza URL adrese koja je sadržana u poruci-zahtjevu klijenta. Kod pretraživanja nekih baza podataka za dane parametre, u odgovorima se mogu vidjeti URL adrese koje imaju nastavak oblika "?xxx&yyy"; u tom slučaju, "xxx" i "yyy" su parametri koje je korisnik zadao (pregledniku) u svom zahtjevu za pretraživanje baze, kojeg je preglednik onda proslijedio serveru.

Zahtjev koji koristi metodu HEAD je sličnog oblika kao i zahtjev koji koristi metodu GET. Zahtjevom sa metodom HEAD klijent traži od servera da mu dostavi osnovne podatke o zadanom objektu (datoteci), ali ne i sam objekt. Ili recimo to ovako: navođenjem metode HEAD u svojoj poruci-zahtjevu, klijent traži od servera da izvede metodu HEAD na zadanom objektu. Rezultat izvođenja te metode na zadanom objektu su osnovni podaci o tom objektu, koje server dostavlja klijentu kao odgovor na njegov zahtjev sa kojim je pokrenuta metoda HEAD.

Navođenjem metode PUT u svojoj poruci-zahtjevu, klijent traži od servera da "postavi" (zapiše, pohrani) dani objekt (datoteku) u svoj direktorij, i to na ono mjesto koje je navedeno u zahtjevu klijenta. Dakle, ovdje klijent šalje web serveru (na određenom domaćinu) neku datoteku (određenog naziva) i traži od tog servera da pokrene metodu PUT i da na taj način zapiše (spremi) tu datoteku na zadano mjesto u direktoriju toga servera.

Porukom-zahtjevom koja sadrži metodu DELETE, klijent (preglednik, korisnik) traži od danog servera da izbriše dani objekt (datoteku) sa tog servera.

Da bi klijent mogao postavljati objekte na server (PUT) i brisati objekte (DELETE), klijent treba imati ovlasti za izvođenje takvih operacija.

Pogledajmo kako izgleda tipična HTTP poruka-odgovor web servera. Primjer koji slijedi mogao bi biti odgovor na poruku-zahtjev koju smo opisali iznad.

HTTP/1.1 200 OKConnection: closeDate: Mon, 24 May 2010 18:06:34 GMTServer: Apache/1.3.0 (Unix)Last-Modified: Wed, 12 May 2010 15:45:09 GMTContent-Length: 72385

17

Content-Type: text/html

(* ...... podaci/datoteka ...... *)

Dana poruka-odgovor servera sastoji se od tri dijela koji se nazivaju: (1) statusni redak, (2) redovi zaglavlja, i (3) tijelo odgovora.

Statusni redak ima tri elementa (koje se naziva poljima). Prvi element je verzija HTTP protokola prema kojoj je oblikovan web server; ovdje je to verzija "1.1". Drugi element je kodna oznaka stanja stvari, odnosno ishoda pokušaja izvršenja zahtjeva kojeg je klijent uputio serveru. Treći element je tekstualna poruka koja opisuje stanje koje označava numerička koda. U ovom slučaju koda "200" i poruka "OK" znače da je server našao traženi objekt i da ovom porukom-odgovorom šalje klijentu kopiju toga objekta.

Stavkom "Connection: close" server javlja klijentu da će pokrenuti proces zatvaranja (prekida) TCP veze kojom mu dostavlja ovaj odgovor, nakon što taj odgovor pošalje tom TCP vezom klijentu.

U stavku "Date:" zapisano je vrijeme (datum i sat) kada je server generirao ovu poruku-odgovor i uputio je klijentu.

Stavak "Server:" sadrži podatke o web serveru koji je generirao ovu poruku.Stavak "Last-Modified:" sadrži vrijeme (datum i sat) kada je zadnji put mijenjan objekt

(datoteka) kojeg web server ovom porukom-odgovorom šalje klijentu.Stavak "Content-Length:" sadrži veličinu objekta (izraženu u bajtovima) kojeg server ovim

odgovorom šalje klijentu.Stavak "Content-Type:" navodi podatak o tipu sadržaja u objektu kojeg se dostavlja

klijentu. U danom primjeru, to je tekstualni sadržaj, koji uključuje stavke HTML jezika.Slijedi prazan redak, koji označava završetak zaglavlja poruke-odgovora web servera. Iza

praznog retka slijedi tijelo poruke-odgovora; tijelo je objekt (datoteka) kojeg server ovim odgovorom šalje klijentu.

Kodne oznake stanja i prateće tekstualne poruke pokazuju ishod pokušaja izvršenja onog zahtjeva kojeg je klijent uputio serveru. Naprimjer, kodna oznaka stanja (ili kraće, status) "200" i prateća tekstualna poruka "OK", kazuju da je server (1) primio zahtjev klijenta, (2) da je "razumio" taj zahtjev (uspješno ga interpretirao), i (3) da je taj zahtjev izvršio, te da (4) u ovom odgovoru dostavlja klijentu rezultat izvršenja njegovog zahtjeva.

Status i poruka "301 Moved permanently" kazuju da je zadani (traženi) objekt prenijet na drugu URL adresu, tako da server nije izvršio traženu operaciju sa zadanim objektom. U ovakvoj situaciji, server uključuje u zaglavlje odgovora redak "Location:" u kojem navodi URL adresu na koju je prenijet traženi objekt. Na temelju toga podatka, klijent (preglednik) može odmah (automatski) tražiti od servera da izvrši zadanu operaciju sa danim objektom na novoj lokaciji (URL adresi), ako se ta lokacija nalazi na istom serveru. Ako je objekt prenijet na drugi server, preglednik može uspostaviti TCP vezu sa drugim serverom i uputiti takav zahtjev drugom serveru (na drugom domaćinu).

Status i poruka "400 Bad Request" kazuju da zahtjev klijenta nije dobro oblikovan, tako da ga server ne razumije (nije uspio interpretirati ga na valjan način); zato server ne može izvršiti taj zahtjev (niti dostaviti sadržajan odgovor na tu poruku klijenta).

Status i poruka "404 Not Found" kazuju da server razumije zahtjev klijenta, ali da traženog objekta nema u direktoriju toga servera, tako da server ne može izvršiti traženu operaciju sa tim objektom. Za razliku od ranije situacije sa premještanjem objekta ("301"), o kojem server ima zapis i novu adresu objekta, u ovom slučaju server uopće nema evidencije o traženom objektu.

Status i poruka "505 HTTP Version Not Supported" kazuju da ovaj server ne podržava onu verziju HTTP protokola koju je klijent naveo u svojoj poruci (zahtjevu), i prema kojoj je klijent oblikovao svoju poruku. Novije verzije obično rade sa starijim verzijama; naprimjer, ako bi

18

server koristio stariju verziju HTTPa nego klijent, onda bi klijent razumio odgovor servera. Ali server (starija verzija) vjerojatno ne bi razumio neke stvari iz zahtjeva klijenta (novija verzija). Osim po starosti, različite verzije istog protokola mogu se razlikovati i na druge načine.

HTTP protokol je definirao mnogo stavaka zaglavlja, koje klijent i server mogu koristiti u svojim porukama, da bi pomoću njih izrazili čim preciznije (1) što zahtijevaju, (2) što su napravili, i (3) što se dogodilo. Ovdje smo iznijeli samo osnovne stavke od kojih se sastoje takvi opisi zahtjeva, odgovora, i stanja. Toliko je dovoljno za to da se prikaže odnose i proces komunikacije između web klijenta (preglednika) i web servera koji su definirani sa HTTP protokolom aplikacijske razine računalne mreže.

Kolačići (cookies)

Neka web sjedišta žele upoznati klijente koji im pristupaju. Za to je potrebno definirati sustav jedinstvene identifikacije klijenata. Takva identifikacija omogućava serveru da bilježi i sakuplja podatke o aktivnostima klijenata na tom web sjedištu; to obično znači o zahtjevima koje klijenti upućuju tom serveru. Na temelju tako prikupljenih podataka web sjedište, odnosno server, mogu tretirati svakog klijenta na način kojeg smatraju prikladnim za tog klijenta. Nekim klijentima mogu nuditi razne stvari, a nekima mogu i ograničiti pristup sadržajima svog sjedišta.

Da bi omogućio jedinstvenu identifikaciju klijenta (preglednika) na jednom serveru, HTTP protokol definirao je "kolačiće" (cookies) i način rada s njima. Kolačići su definirani u RFC 2965; razlozi za odabir takvog naziva nisu nam poznati; inače, takvi razlozi su često neobični, nepouzdani i nevažni. Kaže se da većina komercijalnih web sjedišta koristi kolačiće. To je razumljivo jer za takva sjedišta važno je upoznaju potrošačke interese posjetitelja njihovih web sjedišta.

Postupak identificiranja klijenata koji pristupaju nekom web sjedištu (to jest, serveru koji upravlja njegovim sadržajima) odvija se na slijedeći način. Korisnik pokreće web preglednik na svom računalu i zadaje mu URL adresu web sjedišta tvrtke T koje želi posjetiti; to sjedište nalazi se na web serveru S (ili web server S upravlja tim web sjedištem). Ovdje korisnik i njegov preglednik imaju ulogu klijenta K: prvi za tvrtku, a drugi za server S kojem se obraća.

Web preglednik K uspostavlja TCP vezu sa web serverom S čija je adresa sadržana u URL adresi web sjedišta kojem K želi pristupiti. K zatim po toj TCP vezi šalje svoju HTTP poruku (zahtjev) serveru S; naprimjer da mu dostavi neku web stranicu. Kad server S primi prvi zahtjev nepoznatog klijenta, S generira jedan jedinstveni identifikacijski broj B (na tom serveru) i taj broj zapisuje u svoju "datoteku kolačića". Taj broj (kolačić) je primarni ključ u osnovnoj datoteci kolačića; tom ključu mogu se kasnije dodavati razni drugi podaci, i tako formirati bazu podataka koja sadrži mnogo podataka o svakom pojedinom kolačiću B, odnosno o klijentu K kojem je taj kolačić dodijeljen i koji se tim kolačićem jednoznačno identificira na tom serveru.

Server S zatim generira odgovor na zahtjev klijenta K; naprimjer, šalje mu traženu web stranicu, ili izračunani odgovor na neki njegov upit. Pritom server S šalje klijentu K i broj kolačića B kojeg je tom klijentu dodijelio; server to čini na taj način da u zaglavlje svog odgovora klijentu K uvrsti stavak oblika

Set-cookie: 567812gdje je 567812 jedinstvena oznaka (kolačić) B koja je klijentu K dodijeljena na serveru S.

Kad klijent (preglednik) K primi takav odgovor od S, uzima iz zaglavlja dani kolačić B i zapisuje ga u svoju datoteku kolačića zajedno sa adresom servera S koji mu je dodijelio taj kolačić i na kojem ga taj kolačić jednoznačno identificira. Datoteka kolačića jednog klijenta (preglednika) K obično sadrži mnogo kolačića, jer svaki posjet klijenta K nekom novom web sjedištu (serveru) S može dovesti do tvorbe kolačića za K na sjedištu (serveru) S.

Opisani način identificiranja klijenata na serverima koristi se na slijedeći način. Kad klijent K namjerava poslati zahtjev nekom serveru S, klijent (preglednik) provjerava u svojoj datoteci

19

kolačića da li ima kolačić na S. Ako ima, onda preglednik K u zaglavlje svoje poruke serveru S uvrštava stavak oblika

Cookie: 567812Kad primi zahtjev sa tim brojem kolačića, server S zna da je to zahtjev od klijenta K koji

je već komunicirao sa S, i koji na tom serveru ima jedinstvenu oznaku 567812. Server S, odnosno neka posebna web aplikacija koja koristi njegove usluge, može na osnovu toga provjeriti u bazi podataka o kolačićima što sve ima zapisano o klijentu K (kojeg poznaje kao broj 567812). Na temelju takvog uvida, web aplikacija može oblikovati svoj odgovor na upit klijenta K onako kako smatra da treba odgovoriti tom klijentu.

U odgovoru klijentu K koji ima kolačić na serveru S, server S ne uvrštava broj kolačića jer to nije potrebno činiti. S druge strane, klijent K navodi broj svog kolačića u svakom HTTP zahtjevu kojeg upućuje web serveru S, jer je to potrebno zato da ga S prepozna kao klijenta K.

Saberimo ukratko priču o kolačićima. Kolačići omogućuju jednoznačnu identifikaciju korisnika K na serveru S; sustav identificiranja funkcionira na slijedeći način.

(1) Server S dodjeljuje jedinstvenu oznaku B na tom serveru klijentu K; tu oznaku naziva se kolačićem. S zapisuje B u svoju bazu podataka o kolačićima; u svom odgovoru klijentu K, server S obavještava klijenta K da mu je na tom serveru dodijeljena jedinstvena oznaka B.

(2) Klijent (preglednik) K zapisuje svoju oznaku B na serveru S (zajedno sa URL adresom od S) u svoju datoteku kolačića, koje su mu dodijelili razni serveri.

(3) Kod svakog slanja HTTP poruke-zahtjeva nekom serveru S, klijent-preglednik K provjerava u svojoj datoteci kolačića da li na tom serveru S ima kolačić (jedinstvenu oznaku); ako ima, onda taj kolačić uvrštava u zaglavlje svoje HTTP poruke serveru i na taj način identificira se na tom serveru.

Kolačići omogućuju serveru, odnosno korisničkim aplikacijama koje rade na tom serveru (ili koriste njegove usluge) da skupljaju podatke o aktivnostima klijenata toga servera, odnosno posjetitelja nekog web sjedišta. U bazu podataka o kolačićima (točnije, o njihovim vlasnicima), mogu se zapisivati podaci o tome koje je stranice (na tom sjedištu) posjetio neki klijent, što je kupio, i druge stvari. Na temelju tako prikupljenih podataka, S može sugerirati klijentu K razne stvari i nuditi mu razne proizvode i usluge. Pritom server (ili neka aplikacija web sjedišta) ne treba znati ime korisnika ni njegovu adresu računalne pošte. O klijentu broj 567812 može se saznati mnogo stvari i razmijeniti s njim mnogo poruka, bez da se tog klijenta identificira izvan dosega danog servera i njegovog sustava kolačića. Opisani način označavanja i samo-predstavljanja klijenata web sjedišta dovoljan je za uspostavu osobne komunikacije na razini jednog servera, i za uspostavu mnogih takvih komunikacija na razini web sustava.

Korisnik se može osobno registrirati na nekom web serveru (odnosno, web sjedištu) preko kojeg želi obavljati neke poslove. Naprimjer, može se registrirati na web sjedištu neke tvrtke, da bi preko tog sjedišta mogao kupovati proizvode i usluge koje ta tvrtka prodaje. Kod takve registracije korisnik obično upisuje osobne podatke (u zadanu formu na web stranici) i te podatke šalje web serveru, odnosno web aplikaciji koja radi na tom serveru (koristi njegove usluge). Među takve podatke mogu spadati i broj kreditne kartice kojom klijent plaća robe i usluge koje kupuje.

Takva registracija klijenta K na web sjedište tvrtke T koje koristi usluge servera S, sama po sebi ne mora "povezati" klijenta K sa onim podacima koje je server S prikupio o klijentu K koji se na S identificira brojem kolačića B. Kolačić nije "vezan" za ime i prezime osobe koju identificira na nekom serveru. Međutim, ako se klijent K registrira na web server (ili sjedište) S sa istog osobnog računala (preglednika) sa kojeg je ranije pristupao sjedištu S, onda mu je S već dodijelio kolačić (na tom serveru). To onda znači da će i poruka preglednika sa kojom se klijent K sad registrira na S, sadržavati kolačić B koji identificira K na S. To će onda serveru S (odnosno, nekoj aplikaciji na tom serveru) omogućiti da "spoji" podatke koje je K unio prigodom svoje registracije, i podatke koje je o klijentu K (kao o kolačiću broj B) ranije skupio server S. U tome ne mora biti ničeg lošeg, ali to pokazuje kako se lako širi mreža "veza i putova" kojima razne aplikacije i sustavi

20

mogu prikupljati podatke o pojedincima.

Ovom pričom o kolačićima, o načinu njihova funkcioniranja i o mogućnostima njihove uporabe, ilustrirali smo na koji način se u komunikaciji između web preglednika i web servera mogu definirati i razvijati razni "dodaci" koji tu komunikaciju mogu učiniti sadržajnijom.

O kolačićima postoje različiti stavovi, kao i o drugim elementima informacijske tehnologije koji omogućuju skupljanje podataka o ljudima i nadziranje ljudi. Skupljanje podataka i nadziranje (uz kršenje prava na privatnost) postaje još izrazitije onda kad server, pored podataka koje je sakupio o jednom kolačiću, ima i osobne podatke vlasnika toga kolačića (ime i prezime, broj kreditne kartice). Takvi podaci mogu se koristiti na štetu osobe na koju se odnose, a da ta osoba to ne zna (na izravan način). Takvi podaci mogu se prodavati, izgubiti, ukrasti, koristiti na dobronamjeran ali i na štetan način, i tako redom. Da bi mogla dobro funkcionirati, svaka zajednica treba mnogo podataka, te ih zato mora prikupljati na neke načine. Ali intenzivno prikupljanje podataka ima neke loše strane, a može imati i vrlo loše posljedice, ali s tim pitanjem ne možemo se ovdje baviti.

Proxy server

Proxy je osoba koja zamjenjuje (nadomješta ili predstavlja) neku drugu osobu. Isti izraz koristi se i za naprave: dakle, proxy je ovdje sustav koji (povremeno) zamjenjuje neki drugi sustav. Proxy server je server koji nastoji nadomjestiti druge servere; pritom je u tome dovoljno često uspješan da opravda svoje postojanje. Konkretno, kad neki klijent uputi neki zahtjev nekom serveru, onda se taj zahtjev najprije šalje proxy serveru, da se utvrdi da li taj server može odgovoriti na dani zahtjev, umjesto izvornog servera na kojeg je taj zahtjev adresiran. Pritom je proxy server obično fizički blizu klijentu, a izvorni server se nalazi daleko.

Da bi proxy server mogao izvršavati zahtjeve klijenata, potrebno je da sadrži one sadržaje koji su potrebni za izvršenje tih zahtjeva. Proxy server nastoji stalno prikupljati takve sadržaje. Kad proxy server P nema one sadržaje koji su potrebni za izvršenje zahtjeva kojeg je primio od klijenta K, onda P upućuje zahtjev od K onom serveru S na kojeg se odnosi zahtjev klijenta K; na tom serveru S su izvorno pohranjeni sadržaji na temelju kojih se može ispuniti zahtjev od K.

Server S prihvaća zahtjev kojeg mu je poslao P i na tu poruku odgovara svojim odgovorom proxy serveru P. Kad proxy P primi odgovor od izvornog servera S, onda taj odgovor prosljeđuje klijentu K, koji je izvorno uputio dani zahtjev. Pritom proxy server P zadržava kopiju odgovora kojeg je za klijenta K dobio od servera S. Na taj način proxy server skuplja sadržaje sa mnogih servera; na temelju tih sadržaja proxy onda nastoji odgovarati na razne zahtjeve klijenata, bez da pritom traži pomoć od onih servera na kojima su neki traženi sadržaji izvorno pohranjeni.

Osnovni razlog za korištenje proxy servera je taj što se pomoću njih nastoji smanjiti broj prenošenja istih sadržaja sa udaljenih servera. Jedan proxy server opslužuje mnogo klijenata na svom lokalnom području. Umjesto da izravno šalju svoje zahtjeve udaljenim serverima, preglednici upućuju svoje zahtjeve lokalnom proxy serveru, koji pokušava izvršiti te zahtjeve. Ako to ne može učiniti, onda se proxy server obraća udaljenim izvornim serverima i od njih dobiva odgovore na zahtjeve "svojih" klijenata, kako je to opisano iznad.

Proxy serveri koriste se uglavnom u okviru web sustava, a nazivaju se i web cash; ovdje koristimo naziv proxy server, ili kraće proxy.

Time smo ukratko objasnili što je proxy server, što radi i kako. Dakle, proxy skuplja sadržaje raznih web stranica, koji mu omogućuju da nadomješta mnoge udaljene servere na kojima su ti sadržaji izvorno pohranjeni. Time se postižu dva osnovna dobra učinka: (1) smanjenje prometa u mreži, i (2) smanjenje vremena čekanja klijenata na odgovor.

Upotrebom proxy servera izbjegava se višestruko prenošenje istih sadržaja sa velikih udaljenosti na neko lokalno područje. Time se smanjuje ukupna količina prometa u globalnoj mreži,

21

kao i učestalost zagušenja nekih njenih čvorova i veza. Na manjim udaljenostima, mreža općenito doseže veće propusnosti, tako da je vrijeme čekanja klijenata na odgovor od proxy servera znatno manje nego vrijeme dobivanja istih odgovora od udaljenih izvornih servera.

Slika 3.5 ilustrira položaj proxy servera u računalnoj mreži i njegovu ulogu u web sustavu, koju smo ukratko opisali iznad.

Slika 3.5 Položaj i uloga proxy servera

Web preglednici korisnika na nekom području mogu se konfigurirati na način da svi upiti korisnika (to znači, HTTP poruke-zahtjevi preglednika-klijenata) budu upućeni lokalnom proxy serveru, umjesto da se upućuju onim udaljenim serverima na kojima su izvorno zapisani sadržaji (web stranice, objekti) koje klijenti traže sa tim zahtjevima. To znači da kod svakog zahtjeva korisnika, njegov web preglednik uspostavlja TCP vezu sa lokalnim proxy serverom i preko te veze upućuje mu svoj HTTP zahtjev sa kojim traži da mu proxy dostavi neki web objekt, ili općenito da izvrši neki njegov HTTP zahtjev.

Proxy server prima svaki takav zahtjev i provjerava da li u svojoj memoriji ima pohranjene sadržaje (objekte) za izvršenje zahtjeva kojeg je primio od klijenta. To je obično zahtjev klijenta da mu server dostavi sadržaje (objekte) koji su potrebni za tvorbu neke web stranice. Ako proxy ima te sadržaje, onda odmah odgovara na zahtjev klijenta i u svom odgovoru dostavlja mu sadržaje koje je klijent tražio.

Ako proxy nema sadržaje koji su potrebni za izvršenje zahtjeva klijenta, onda proxy uspostavlja TCP vezu sa serverom na kojem su izvorno zapisani traženi sadržaji (kraće: sa izvornim serverom) i upućuje mu (tom TCP vezom) svoj HTTP zahtjev sa kojim od izvornog servera traži da (za njega) izvrši onaj zahtjev kojeg je proxy serveru uputio izvorni klijent. Izvorni server prima zahtjev od proxy servera i izvršava ga, što obično znači da mu šalje HTTP odgovor u kojem mu

22

šalje traženi sadržaj (objekt). Koristeći istu TCP vezu, proxy može uputiti izvornom serveru više zahtjeva, i na taj način dobiti sve sadržaje (objekte) koji su mu potrebni da bi izvršio neki zahtjev izvornog klijenta.

Kad proxy dobije tražene sadržaje, onda te sadržaje šalje kao odgovor izvornom klijentu (preko ranije uspostavljene TCP veze), kao HTTP odgovor na klijentov polazni HTTP zahtjev. Pritom proxy server zapisuje u svoju memoriju kopiju onih sadržaja koje je primio od izvornog servera. Ako isti klijent, ili neki drugi klijent, kasnije uputi proxy serveru zahtjev za čije izvršenje su potrebni ti sadržaji, onda će proxy moći izvršiti taj zahtjev bez da ponovno traži i donosi iste sadržaje sa istog udaljenog servera.

Osnovno načelo rada proxy servera i web sustava koji koristi takve servere, izgleda jasno; tehničke pojedinosti mogu biti složenije. Naprimjer, uzmimo da klijent K traži od proxy servera P neku web stranicu koja se sastoji od 10 objekata, i da P nema tu web stranicu pohranjenu u svojoj memoriji. Tada proxy P uspostavlja TCP vezu sa izvornim serverom S i od njega traži (i dobiva) spomenutih 10 objekata. Taj proces mogao bi se odvijati na dva načina. Prvi način, P traži jedan objekt od S i prosljeđuje ga klijentu K; proxy P zatim čeka da K od njega zatraži slijedeći objekt, kojeg P onda traži od S i prosljeđuje ga klijentu K. I tako sve dok klijent K ne dobije sve objekte koji mu trebaju; tada K prestaje slati zahtjeve prema P i prekida pripadnu TCP vezu sa P; tada P prestaje slati svoje zahtjeve prema S i prekida pripadnu TCP vezu sa S.

Drugi način bio bi da P najprije traži (i dobije) od S svih 10 objekata koji su potrebni za izradu web stranice koju je od P izvorno tražio K, te da nakon toga dostavlja te objekte klijentu K, jednog za drugim, kao odgovore na niz HTTP zahtjeva koje mu K upućuje. Na temelju onoga što je rečeno o HTTP protokolu, prijenos sadržaja preko proxy servera trebao bi se odvijati na prvi od dva opisana načina. Dakle, K traži prvi objekt (osnovnu HTML stranicu) od P; ako P nema taj objekt, onda ga traži (i dobiva) od S i smjesta ga prosljeđuje izvornom tražitelju K. K na to traži slijedeći objekt koji mu je potreban, i tako redom, kako je to objašnjeno iznad.

Proxy server ima ulogu servera i klijenta. Proxy ima ulogu web servera kad prima HTTP zahtjeve od klijenta i kad šalje odgovore na te zahtjeve. Proxy ima ulogu klijenta kad upućuje HTTP zahtjeve izvornom serveru (umjesto izvornog klijenta) i kad prima HTTP odgovore od izvornog servera (koje zatim šalje izvornom klijentu).

Proxy servere obično postavljaju ISPi (Internet service providers = davatelji Internet usluga). Sveučilište može biti davatelj Internet usluga za svoje studente, djelatnike i organizacijske jedinice, i može imati jedan ili više proxy servera. Tada se web preglednici korisnika njegovih usluga konfiguriraju na taj način da sve svoje HTTP zahtjeve upućuju lokalnom proxy serveru. Proxy onda procesira te upite na način kako je to objašnjeno iznad.

Veliki ISPi koji pokrivaju područje cijele države, mogu imati jedan ili više proxy servera u svakoj zoni u kojoj prodaju svoje Internet usluge. Takvi proxy serveri onda pohranjuju one sadržaje koje lokalni klijenti traže, a koji su izvorno zapisani na serverima koji se nalaze u nekim udaljenim zonama.

Rekli smo da upotreba proxy servera može znatno umanjiti ukupnu količinu prometa u mreži. Pohranjivanjem sadržaja koji se donose sa udaljenih servera, na lokalnom proxy serveru, izbjegava se potrebu da se iste sadržaje prenosi više puta sa udaljenog servera. Sadržaji nekih popularnih web sjedišta (kao što su Wikipedia, YouTube i drugi) mogli bi se prenositi mnogo puta u kratkom vremenskom razdoblju u istu lokalnu mrežu.

Primjena lokalnih proxy servera smanjuje vrijeme čekanja na odgovor (na izvršenje HTTP zahtjeva), jer je propusnost veza na malim udaljenostima općenito veća od propusnosti koju mreža može pružiti pojedinačnim komunikacijama na velikim udaljenostima. Slika 3.6 pokazuje kako se dodavanjem proxy servera u lokalnu mrežu velike propusnosti (100 Mbps) može smanjiti količinu prometa prema ostatku Interneta preko sporije veze (10 Mbps); na taj način smanjuje se i prosječno vrijeme čekanja klijenata na odgovor na njihove HTTP zahtjeve sa kojima traže razne

23

web sadržaje (objekte). Koliko će iznositi to smanjenje, zavisi od toga koliko često klijenti "pogađaju" one sadržaje koji su pohranjeni na proxy serveru. Postoje tvrdnje da bi se takva pogađanja trebala kretati u rasponu od 20 do 70 posto, što zavisi od raznih čimbenika među koje spadaju: ponašanje klijenata, vrste podatkovnih sadržaja, intenzitet mijenjanja izvornih zapisa na udaljenim serverima, i druge stvari.

Ako proxy server sadrži one sadržaje koje od njega traže lokalni klijenti u barem 20 posto slučajeva, onda je njegovo postojanje obično korisno. Razlika između propusnosti veza (kanala) na lokalnoj razini i u globalnim komunikacijama je obično velika, tako da ako proxy uspijeva odgovoriti na barem 20 posto zahtjeva klijenata, onda je njegova upotreba obično opravdana. Tada proxy server smanjuje količinu prometa u mreži i prosječno vrijeme čekanja klijenata na odgovore na zahtjeve.

24

Slika 3.6 Proxy server u lokalnoj mreži

Na slici 3.6, mreža institucije ima propusnost od 100 Mbps; ta lokalna mreža vezana je na jedan rubni usmjerivač globalne mreže ("na Internet") vezom koja ostvaruje prosječnu propusnost od 10 Mbps. U mreži institucije jedan čvor ima ulogu usmjerivača (vrata Uins) koji povezuje tu lokalnu mrežu sa jednim rubnim usmjerivačem Interneta (Uint), i time sa globalnom mrežom Internet. Propusnost od 10 Mbps nije ovdje stvar samo jedne veze (između tih dvaju usmjerivača), nego je to pitanje koliku prosječnu propusnost pruža Internet lokalnim mrežama u njihovim komunikacijama sa čvorovima iz udaljenih zona. Povećanje propusnosti veze između usmjerivača Uins i Uint ne bi znatnije povećalo propusnost kanala između domaćina koji se nalaze u međusobno udaljenim lokalnim mrežama. Jer propusnost veze koja prolazi kroz više usmjerivača i sastoji se od više dionica određena je propusnošću najsporijeg (zasićenog) usmjerivača i najsporije (zasićene) veze između dvaju usmjerivača na putu između krajnjih točaka prijenosa. Zato je propusnost veza (kanala) između domaćina iz iste zone općenito veća nego propusnost kanala između dvaju domaćina iz međusobno udaljenih zona. Propusnost okosnica je vrlo velika, ali je i broj prijenosa (kanala) koji se odvijaju preko okosnica vrlo velik, što bitno ograničava propusnost koju okosnica može pružiti pojedinom prijenosu (kanalu). Općenito, s porastom broja usmjerivača i dionica na nekom putu, raste vjerojatnost da će neki od tih elemenata biti preopterećen, što će onda odrediti (u nepovoljnom smislu) propusnost veze (kanala) između dvaju međusobno udaljenih domaćina.

Zbog svega toga, smanjenje vremena čekanja klijenata na odgovore na njihove HTTP zahtjeve nastoji se postići uključivanjem proxy servera u lokalne mreže i zone, na mjesta gdje postoje naznake da bi proxy mogao biti od koristi. Time se odgovori na znatan dio HTTP zahtjeva klijenata (20 do 70 posto) dobivaju od proxy servera lokalne zone. U takvim slučajevima, prijenos HTTP zahtjeva i HTTP odgovora izvodi se samo na lokalnom području, čime se smanjuje veličinu prometa u mreži i vrijeme čekanja na odgovor.

Uvjetni GET

Glavni problem za proxy servere je taj što sadržaji web stranica koje oni pohranjuju, s vremenom zastarijevaju. Brzina zastarijevanja varira u zavisnosti od vrste sadržaja, ali zapisi i sadržaji mnogih web stranica na izvornim serverima se mijenjaju, što onda čini da kopije takvih sadržaja na proxy serverima postanu zastarjele.

Zato je u HTTP protokolu definirana uvjetna GET naredba, pomoću koje proxy server provjerava da li je neka web stranica (objekt), čiju kopiju ima pohranjenu, mijenjana na izvornom serveru nakon "datuma zadnje promjene" koji je zapisan na kopiji te stranice na proxy serveru. Ako stranica nije mijenjana, onda nema potrebe donositi novu kopiju te stranice sa izvornog servera na proxy; ako stranica jest mijenjana, onda uvjetnom GET naredbom proxy traži (i dobiva) od izvornog servera novu kopiju dane web stranice. Pogledajmo primjer komunikacije proxy servera i izvornog servera kod upotrebe GET naredbe i kod upotrebe uvjetne GET naredbe.

Prvo, neka preglednik traži sadržaj web stranice koja se nalazi na URLwww.razno-bilje.hr/vocke/jabuka.gifPreglednik je postavljen (konfiguriran) tako, da njegovi HTTP zahtjevi bivaju upućeni

lokalnom proxy serveru. Uzmimo da lokalni proxy server ne sadrži traženu web stranicu (ili web objekt koji se izvorno nalazi na danoj URL adresi). Tada proxy šalje slijedeći HTTP zahtjev izvornom serveru:

GET /vocke/jabuka.gif HTTP/1.1Host: www.razno-bilje.hr

25

Izvorni server izvršava zahtjev proxy servera i šalje mu HTTP odgovor slijedećeg oblika:

HTTP/1.1 200 OKDate: Fri 20 May 2011 13:44:32 GMTServer: Apache/1.3.0 (Unix)Last-Modified: Wed 11 May 2011 14:22:06 GMTContent-Type: image/gif

(* ...... podaci/datoteka ...... *)

Objekt (sliku) kojeg je primio od izvornog servera, proxy šalje izvornom klijentu koji je taj sadržaj tražio; pritom proxy ujedno zapisuje kopiju tog sadržaja u svoju memoriju. Uz taj sadržaj (objekt), proxy zapisuje podatak o vremenu kojeg mu je izvorni server poslao u retku "Last-Modified", u zaglavlju poruke.

Uzmimo da slijedeći dan na proxy server stigne zahtjev nekog klijenta (istog ili drugog) koji traži da mu se dostavi sadržaj web stranice sa URL adrese

www.razno-bilje.hr/vocke/jabuka.gifLokalni proxy server sada ima pohranjen traženi sadržaj, ali ne zna da li je u

međuvremenu taj sadržaj (web stranica) mijenjan na udaljenom izvornom serveru (na kojem se nalazi original). Zato proxy šalje izvornom serveru HTTP zahtjev slijedećeg oblika:

GET /vocke/jabuka.gif HTTP/1.1Host: www.razno-bilje.hrIf-modified-since: Wed 11 May 2011 14:22:06 GMT

U stavku "If-modified-since" Proxy navodi točno onu vremensku oznaku (datum i sat) koju je primio od izvornog servera (zajedno sa danim objektom) u stavku "Last-Modified" iz zaglavlja poruke u kojoj je primio taj objekt.

Ovim uvjetnim GET stavkom proxy traži od izvornog servera da mu pošalje traženi objekt (datoteku, sadržaj web stranice) koji se nalazi na danoj URL adresi, ako i samo ako je taj objekt (datoteka) mijenjan nakon onog vremena koje proxy navodi u svom zahtjevu. Jer ako taj objekt nije mijenjan nakon tog vremena, onda proxy već ima sadašnji sadržaj danog objekta (web stranice).

Uzmimo da dani objekt nije mijenjan nakon vremena koje navodi proxy u svom zahtjevu. Tada izvorni server šalje proxy serveru odgovor slijedećeg oblika:

HTTP/1.1 304 Not ModifiedDate: Tue 24 May 2011 10:34:42 GMTServer: Apache/1.3.0 (Unix)

(* ...... tijelo (prazno) ...... *)

Dakle, server odgovara na uvjetni upit, ali je tijelo odgovora prazno, jer nema potrebe slati proxy serveru sadržaj (objekt) koji je jednak onom kojeg proxy već ima pohranjenog (od ranije).

Po primitku takvog odgovora od izvornog servera, proxy server šalje klijentu traženi sadržaj (iz svoje memorije). Na taj način izbjegnut je ponovni (nepotreban) prijenos sadržaja (koji može biti vrlo velik) sa udaljenog servera; time je ujedno smanjeno vrijeme čekanja klijenta na odgovor.

3.3 Prijenos datoteka i protokol FTP

26

Protokol FTP (file transfer protocol) je protokol aplikacijske razine računalne mreže (Interneta), koji definira (i izvodi) prijenos datoteka između dvaju domaćina. Strukturu računalne mreže i FTP sustava, koji omogućuju takav prijenos ilustrira slika 3.7.

Slika 3.7 Struktura FTP sustava

Da bi mogao raditi na lokalnom sustavu (domaćinu) i pristupati lokalnom sustavu datoteka, korisnik se treba prijaviti na taj (lokalni) sustav; korisnik to čini sa imenom (IDl) i lozinkom (PWl) sa kojima je registriran na tom sustavu. Za rad na udaljenom sustavu, korisnik treba biti registriran na tom (udaljenom) sustavu i prijaviti se na taj sustav sa imenom (IDu) i lozinkom (PWu) s kojima je registriran na tom udaljenom sustavu.

Nakon što se korisnik prijavio na lokalno računalo i pokrenuo FTP sustav, otvara se FTP korisničko sučelje, koje korisniku omogućuje da se prijavi na odabrano udaljeno računalo (domaćina). Nakon što se prijavio na oba dva računala, korisnik može prenositi datoteke (kojima je ovlašten pristupati) sa jednog računala na drugo.

Korisnik komunicira (radi) sa FTP sustavom preko (i pomoću) FTP korisničkog sučelja. Korisnik prvo zadaje sučelju ime (adresu) udaljenog domaćina s kojim namjerava raditi (prenositi datoteke). Na temelju toga, klijentski dio FTP sustava na lokalnom domaćinu uspostavlja TCP vezu sa serverskim dijelom FTP sustava na udaljenom domaćinu. Umjesto o klijentskom i serverskom "dijelu FTP sustava" može se govoriti o klijentskom i serverskom "FTP procesu".

Dakle, kad FTP klijent uspostavi TCP vezu sa FTP serverom, onda korisnik unosi u lokalno FTP sučelje svoje ime (IDu) i lozinku (PWu) sa kojima je registriran na udaljenom domaćinu. FTP sustav prenosi ime i lozinku korisnika sa lokalnog domaćina na udaljenog domaćina preko TCP veze koju je prethodno uspostavio između lokalnog i udaljenog domaćina. Serverski dio FTP

27

sustava na udaljenom domaćinu izvodi proces prijave korisnika na tom domaćinu. Nakon što je uspješno prijavljen na udaljenom domaćinu, korisnik može pokretati operacije prenošenja datoteka sa udaljenog domaćina (sustava datoteka) na lokalnog domaćina (sustav datoteka), kao i u obrnutom smjeru.

FTP sustav izvodi prijenos datoteka između dvaju domaćina na sličan način kao što HTTP sustav prenosi datoteke (web objekte) između web servera i klijenta. Oba dva protokola vrše prijenos naredbi i datoteka preko TCP veze na transportnoj razini. Ali svaki od ta dva protokola ima svoje specifičnosti po kojima se razlikuje od drugog.

Jedna od specifičnosti FTP protokola (sustava) je da u radu koristi dvije paralelne TCP veze između lokalnog i udaljenog domaćina. Jedna od tih veza naziva se upravljačkom (control) a druga podatkovnom (data). Upravljačkom TCP vezom izvodi se prijenos upravljačkih podataka i naredbi između dvaju domaćina. Takvi podaci su naprimjer ime i lozinka korisnika. Razne upravljačke naredbe omogućuju korisniku (1) da se kreće po stablu direktorija (mapa) udaljenog domaćina, (2) da prenosi (kopira) datoteke sa udaljenog domaćina na lokalnog (naredbe tipa "get"), i (3) da prenosi datoteke sa lokalnog domaćina na udaljenog domaćina i da ih zapisuje na njega (naredbe tipa "put"). Slika 3.8 ilustrira dvostruku TCP vezu između klijentskog i serverskog dijela FTP sustava. Upravljačka komunikacija odvija se preko porta 21, dok se podatkovna komunikacija odvija preko porta 20.

Slika 3.8 Komunikacija u TCP sustavu

U FTP sustavu, datoteke se prenose preko podatkovne TCP veze između dvaju domaćina. Kada neki mrežni sustav aplikacijske razine koristi posebnu TCP vezu za prijenos upravljačkih sadržaja (podataka i naredbi) između domaćina, onda se kaže da taj sustav prenosi upravljačke sadržaje (ili komunicira) izvan pojasa (out-of-band). To znači da u FTP sustavu, klijent i server razmjenjuju upravljačke sadržaje izvan pojasa. Za razliku od FTP protokola (sustava), kod HTTP (web) protokola koristi se ista TCP veza za prijenos upravljačkih sadržaja (to jest, zaglavlja HTTP zahtjeva i odgovora) i za prijenos podataka (datoteka, web objekata). Za sustave koji rade na taj način (sa jednom TCP vezom) kaže se da komuniciraju (prenose upravljačke sadržaje) unutar pojasa (in-band).

Kad korisnik pokrene FTP sustav i zatraži pristup nekom udaljenom domaćinu, klijentski dio FTP sustava pokreće uspostavu upravljačke TCP veze sa serverskim dijelom FTP sustava na udaljenom domaćinu. Upravljačka TCP veza uspostavlja se na portu 21. Klijentska strana FTPa šalje po toj vezi serverskoj strani FTPa (na udaljenom domaćinu) identifikacijske podatke korisnika na tom udaljenom domaćinu. Nakon procesa identifikacije korisnika na udaljenom domaćinu, klijentska strana šalje svoje FTP naredbe serverskoj strani preko te TCP veze sa portom 21.

28

Kad serverska strana TCP sustava primi od klijentske strane (preko upravljačke TCP veze) zahtjev za prijenos datoteke (sa tog sustava na klijenta, ili u obrnutom smjeru), onda serverska strana pokreće uspostavu podatkovne TCP veze prema klijentskoj strani, preko porta 20. FTP sustav izvodi prijenos jedne datoteke preko tako uspostavljene veze, i zatim tu podatkovnu vezu zatvara (prekida). Ali upravljačka veza traje i dalje, dok je jedna od strana u komunikaciji ne prekine.

Ako u okviru jedne FTP sesije (to jest, jednog prenošenja datoteka) korisnik (FTP klijent) pošalje zahtjev za prijenos još jedne datoteke, onda FTP server uspostavlja novu podatkovnu TCP vezu sa FTP klijentom i preko te veze prenosi klijentu traženu datoteku. I tako za svaku datoteku koju klijent zatraži preko iste upravljačke veze. TCP veza za razmjenu upravljačkih podataka i naredbi FTP sustava ostaje otvorena cijelo vrijeme trajanja jedne FTP sesije (to jest, jedne FTP komunikacije između dvaju domaćina), ali se za prijenos svake datoteke uspostavlja novu podatkovnu TCP vezu.

U nastavku navodimo nekoliko osnovnih naredbi u sustavu FTP. Upravljački sadržaji (podaci i naredbe) u FTP sustavu pisani su u 7-bitnom ASCII formatu i čitljivi su za korisnike. Svaki upravljački stavak zapisuje se u novi redak (ili prikazuje se u zasebnom retku); kaže se da svaki stavak "završava sa CRLF" (carriage return and line feed); doslovno značenje te kratice nije ovdje važno; praktički, to označava završetak jednog retka.

Naredbe u FTP sustavu sastoje se od četiri ASCII velika slova i mogu imati parametre. Navedimo oblike nekih od tih naredbi.

USER ime-korisnika - tom naredbom klijentski dio FTP sustava (na lokalnom domaćinu) šalje ime korisnika serverskom dijelu FTP sustava na udaljenom domaćinu.

PASS lozinka - tom naredbom klijentski dio FTP sustava šalje lozinku korisnika serverskom dijelu FTP sustava na udaljenom domaćinu.

LIST - tom narednom klijentski FTP sustav traži od serverskog FTP sustava da mu dostavi listu datoteka koje su sadržane u tekućem direktoriju udaljenog domaćina. Server odgovara na takav zahtjev na taj način da uspostavi jednu podatkovnu TCP vezu sa klijentom, i preko te veze pošalje klijentu odgovor na njegov zahtjev. Dakle, na takav upit klijenta, server ne odgovara preko postojeće upravljačke TCP veze, nego uspostavlja podatkovnu TCP vezu i po njoj šalje odgovor klijentu.

RETR ime-datoteke - takvom naredbom klijent traži (i dobiva) kopiju zadane datoteke iz tekućeg direktorija udaljenog domaćina. Ta naredba je jedan oblik opće naredbe tipa "get". Serverski dio FTP sustava na udaljenom domaćinu izvršava taj zahtjev tako, da uspostavi jednu podatkovnu TCP vezu sa klijentskim dijelom FTP sustava i preko te veze pošalje tom klijentu kopiju tražene datoteke.

STOR ime-datoteke - takvom naredbom zapisuje se kopiju dane datoteke sa lokalnog domaćina na tekući direktorij udaljenog domaćina. Ta naredba zahtjeva od serverskog dijela FTP sustava (na udaljenom domaćinu) da uspostavi podatkovnu TCP vezu sa klijentskim dijelom TCP sustava, kao i kod prethodne naredbe RETR. Tom vezom onda lokalni domaćin (FTP klijent) šalje udaljenom domaćinu (FTP serveru) navedenu datoteku, koju server zapisuje u svoj tekući direktorij.

Na svaku naredbu (zahtjev) klijentske strane FTP sustava, serverska strana FTP sustava šalje svoj odgovor. Takvi odgovori sastoje se od troznamenkastog broja (kode) i od tekstualnog objašnjenja što ta koda znači. Pogledajmo nekoliko odgovora serverske strane FTP sustava.

331 Username OK, password required125 Data connection already open; transfer starting425 Can't open data connection452 Error writing fileUkratko, prvi odgovor serverske strane FTP sustava kaže da je ime (IDu) prijavljenog

korisnika (sa klijentske strane) u redu, ali da korisnik treba upisati još i lozinku (PWu). Drugi odgovor kaže da je serverska strana uspostavila podatkovnu TCP vezu i da prijenos datoteke

29

počinje. Trećim odgovorom server javlja klijentu da ne uspijeva uspostaviti podatkovnu TCP vezu. Tu vezu server uspostavlja s klijentom na portu 20, kako to ilustrira slika 3.8 Četvrtim odgovorom server javlja klijentu da je došlo do greške u zapisivanju datoteke (na serveru), koju mu je klijent poslao.

Potpun opis naredbi (zahtjeva) i odgovora u FTP sustavu dan je u RFC 959.

3.4 Računalna pošta: SMTP, POP, IMAP

Ljudi koji su radili na razvoju računalne mreže razmjenjivali su međusobno poruke preko te mreže od početka njenog rada. Zato se može reći da razvoj sustava računalne pošte počinje od samog početka rada računalne mreže. Taj sustav razvijao se tokom proteklih desetljeća, tako da danas omogućava prijenos raznih vrsta informacijskih sadržaja, kao i razne oblike rada sa tim sadržajima.

Za sustav računalne pošte kaže se da pruža usluge asinkrone komunikacije. Time se hoće reći da primatelj poruke ne mora primati njen sadržaj u isto vrijeme kada pošiljatelj proizvodi taj sadržaj. Općenito, izravna komunikacija je sinkrona jer primatelj prima sadržaje u isto vrijeme kada ih pošiljatelj proizvodi. Komunikacija pomoću zapisanih (snimljenih) sadržaja je asinkrona, jer primatelj sadržaja može te sadržaje pogledati (čitati, slušati) u bilo koje vrijeme nakon što su mu dostavljeni.

Slika 3.9 prikazuje osnovne elemente koji čine sustav računalne pošte, i odnose među tim elementima.

30

Slika 3.9 Struktura sustava računalne pošte

Sustav računalne pošte sastoji se od tri osnovne vrste elemenata, i to od: (1) korisničkih agenata (user agents), (2) servera računalne pošte (mail servers), i (3) SMTP protokola (simple mail transfer protocol). U nastavku ovog odjeljka, izraz "server za računalnu poštu" ćemo često skratiti na "poštanski server", ili na "server" jer se ovdje zna o kojem serveru govorimo.

Korisničkim agentima nazivaju se softverski sustavi koji korisniku omogućuju izravan rad sa računalnom poštom. Među poznate sustave takve vrste spadaju Outlook, Apple Mail, Mozila Thunderbird i drugi. Takvi sustavi omogućuju korisniku da na svom računalu piše poruke računalne pošte i da ih šalje serveru, da prima i čita takve poruke, da ih sprema ili briše. Da bi koristio sustav računalne pošte, korisnik treba imati osobnu adresu računalne pošte na nekom serveru računalne pošte; korisnik onda preko tog servera šalje i prima poruke računalne pošte.

Korisnički agent za računalnu poštu radi na osobnom računalu korisnika, dok server za računalnu poštu obično radi na nekom računalu davatelja Internet usluga i pruža usluge mnogim korisnicima koji su registrirani na tom serveru i imaju na njemu osobnu adresu računalne pošte.

31

Kad korisnik napiše svoju poruku računalne pošte pomoću svog korisničkog agenta (na svom računalu), onda njegov agent šalje tu poruku serveru na kojem je taj korisnik registriran. Server prihvaća poruke koje mu šalju agenti njegovih (registriranih) korisnika i smješta te poruke u svoj red izlaznih poruka (outgoing message queue). To je red (niz) poruka koje server šalje na one adrese računalne pošte na koje su te poruke upućene (adresirane). Server to čini na taj način, da za svaku poruku uspostavi TCP vezu sa poštanskim serverom na onom domaćinu čija je adresa sadržana u adresi računalne pošte na koju je upućena dana poruka. Naprimjer, da bi prenio poruku na adresu računalne pošte mradovan@inf.uniri.hr, poštanski server pošiljatelja te poruke (koji radi na nekom udaljenom domaćinu), uspostavlja TCP vezu sa poštanskim serverom koji radi na domaćinu čija tekstualna adresa glasi inf.uniri.hr. Zatim server-pošiljatelj po toj TCP vezi šalje danu poruku serveru-primatelju na odredišnom domaćinu.

Korisnik koji je registriran (ima poštansku adresu) na nekom serveru računalne pošte, ima na tom serveru svoj poštanski pretinac (mailbox). Poruke koje stižu na server za nekog njegovog korisnika, server zapisuje u poštanski pretinac toga korisnika. Da bi preuzeo poruke iz svog pretinca (na serveru na kojem je registriran), korisnik pokreće svog agenta za računalnu poštu (na svom računalu), uspostavlja vezu svog agenta sa poštanskim serverom (na kojem je registriran) i pomoću agenta preuzima poruke iz svog pretinca na tom serveru. Nakon toga korisnik može prekinuti vezu sa serverom i raditi sa primljenim porukama što želi, na svom računalu i pomoću svog agenta.

Korisnički agenti imaju grafička korisnička sučelja (graphical user interface - GUI) koja korisnicima olakšavaju rad sa računalnom poštom. Prije uvođenja grafičkih sučelja, korisnički agenti za računalnu poštu bili su tekstualno orijentirani (text-based). To znači da su korisnici upravljali sa tim agentima pomoću tekstualnih naredbi (u naredbenom retku), a ne pritiskom miša na ikone i dugmad. Među poznate tekstualno orijentirane korisničke agente za računalnu poštu spadaju mail, pine, i elm, koji se i dalje nalaze u upotrebi.

Serveri za računalnu poštu čine središnji dio sustava računalne pošte. Svaki korisnik toga sustava registriran je na nekom od tih servera, na kojem ima svoju adresu računalne pošte i svoj poštanski pretinac (memorijski prostor) u kojeg taj server zapisuje poruke koje prima za tog korisnika. Preko istog poštanskog servera, korisnik i šalje svoje poruke, kako je to objašnjeno iznad. Ista fizička osoba može imati adrese računalne pošte na više poštanskih servera, ali za sustav su te adrese međusobno nezavisne.

Poruka računalne pošte nekog korisnika A proizvodi (piše) se na njegovom korisničkom agentu za računalnu poštu. Taj agent zatim prenosi tu poruku serveru Si (izvor) na kojem je korisnik A registriran. Server Si prihvaća tu poruku i prenosi je onom serveru So (odredište) na kojem je registriran primatelj te poruke. Server So prima tu poruku i zapisuje je u poštanski pretinac onog korisnika B na kojeg je ta poruka naslovljena.

Da bi korisnik B vidio poruke iz svog poštanskog pretinca na serveru So, B treba pokrenuti korisničkog agenta za računalnu poštu na svom računalu i pomoću njega uspostaviti vezu sa serverom So. Prigodom uspostavljanja takve veze, server So traži od korisnika B ime i lozinku sa kojima je B registriran na So; nakon uspješne identifikacije korisnika B, server So predaje agentu toga korisnika poruke iz poštanskog pretinca od B. To predavanje ili preuzimanje poruka može se izvesti na različite načine: uz zadržavanje zapisa na serveru, ili uz njegovo brisanje, o čemu govorimo kasnije.

Pokušaj servera Si da dostavi poruku računalne pošte serveru So može ne uspjeti, zato što server So trenutno ima nekih problema (ne radi dobro, ili uopće) tako da nije u mogućnosti primati poruke. U takvom slučaju server Si zadržava poruku (koju nije uspio prenijeti) u svom nizu izlaznih poruka i kasnije ponovno pokušava prenijeti tu poruku na odredišni server So. Server Si ponavlja takav pokušaj otprilike svakih pola sata, o čemu može povremeno obavještavati pošiljatelja te poruke. Ako server Si ne uspije prenijeti poruku odredišnom serveru So u roku od

32

nekoliko dana (obično pet), onda Si briše tu poruku iz svog reda izlaznih poruka i obavještava o tome pošiljatelja te poruke. Server šalje takve obavijesti korisnicima u obliku poruka računalne pošte.

Protokol SMTP koristi TCP veze sa transportne razine za prijenos poruka od servera-izvora (Si) do servera-odredišta (So) tih poruka; dakle, od servera pošiljatelja poruka, do servera primatelja poruka. Kao i većina protokola aplikacijske razine, SMTP ima dvije "strane" ili dvije komponente: klijentsku stranu i serversku stranu. Svaki poštanski server izvodi oba dva dijela SMTP protokola, zavisno od toga u kojoj se ulozi nalazi, pošiljatelja ili primatelja. Klijentska strana SMTP protokola izvodi se na poštanskom serveru koji šalje poruku, a serverska strana SMTP protokola izvodi se na serveru za računalnu poštu koji prima poruku. Svaki od dvaju dijelova SMTP protokola može se izvoditi na svakom poštanskom serveru, u zavisnosti od njegove uloge u prijenosu neke konkretne poruke. Dakle, poštanski server koji šalje poruku radi kao SMTP klijent, a poštanski server koji prima poruku radi kao SMTP server. Serveri za računalnu poštu stalno šalju i primaju poruke za svoje mnogobrojne korisnike, tako da se na njima stalno odvijaju klijentski proces i serverski proces od SMTP protokola.

Protokol SMTP

Sadašnja verzija protokola SMTP definirana je u RFC 5321, ali prva RFC definicija toga protokola bila je napravljena još 1982. godine. Davno porijeklo SMTP protokola navodi se kao razlog što taj protokol ima neka svojstva koja su nekad bila normalna, ali ih je razvoj tehnologije učinio neprikladnima i smetnjom. Naprimjer, SMTP protokol zahtijeva da poruka računalne pošte (zaglavlje i tijelo) bude zapisana u 7-bitnom ASCII kodu. U vrijeme kad su poruke računalne pošte bile čisto tekstualne, takav način kodiranja njihovih sadržaja bio je normalan. Ali sadašnje poruke računalne pošte sastavljaju se u formatu MIME (Multipurpose Internet Mail Extension). U formatu MIME mogu se zapisati (i prenositi) razne vrste sadržaja, kao što su tekst, slike, zvučni i video zapisi, i zato je zahtjev SMTPa o 7-bitnim ASCII zapisima svih sadržaja postao nepovoljan. Taj zahtjev znači da sav sadržaj poruke računalne pošte - uključujući digitalne zapise grafičkih, video i zvučnih sadržaja - treba prekodirati u 7-bitni ASCII kodni zapis, da bi ta poruka mogla biti prenošena u SMTP sustavu. Nakon prijenosa prekodirane poruke na njeno odredište pomoću SMTP sustava, tu poruku treba na odredištu dekodirati u njen izvorni oblik zapisa.

Spomenimo da HTTP protokol, koji prenosi sadržaje (objekte, datoteke) u web sustavu - među koje spadaju digitalni zapisi audio i video sadržaja - ne zahtjeva prekodiranje tih zapisa, nego ih prenosi onakve kakvi jesu (i kakvi su mu dani). Nije nam ovdje poznato zašto je ograničenje na 7-bitni ASCII kodni zapis zadržano u SMTP protokolu, ako se taj protokol razvijao i mijenjao tokom proteklih nekoliko desetljeća.

SMTP protokol uspostavlja izravnu TCP vezu između servera koji šalje poruku (Si) i servera koji prima tu poruku (So). SMTP ne koristi usluge drugih poštanskih servera na putu između izvora poruke Si i njenog odredišta So, bez obzira koliko je taj put dug. Ako server primatelja So trenutno ne radi, onda se poruka čuva u izlaznom nizu servera pošiljatelja Si, a ne na nekom poštanskom serveru na putu između njih, naprimjer čim bliže odredištu So.

Pogledajmo kako izgleda proces kojim SMTP prenosi poruke računalne pošte sa poštanskog servera Si koji šalje te poruke, na poštanski server So koji te poruke prima. Prvo, SMTP koji radi na serveru Si koji treba poslati poruku, traži od TCP sloja (na svom domaćinu) da za njega uspostavi TCP vezu sa udaljenim domaćinom na kojem radi server za računalnu poštu So kojem Si treba prenijeti poruku računalne pošte. Poruke upućene na port 25 prima SMTP protokol koji radi na tom poštanskom serveru. Nakon što je uspostavljena TCP veza između klijentske strane (ili dijela) SMTPa koji radi na poštanskom serveru Si i serverske strane (ili dijela) SMTPa koji radi na

33

poštanskom serveru So, te dvije strane SMTPa razmjenjuju neke upravljačke podatke; kažemo da tom razmjenom podataka izvode međusobno "rukovanje" na aplikacijskoj razini.

Pogledajmo jedan primjer niza stavaka kakve razmjenjuju SMTP klijent (K) i SMTP server (S) u procesu međusobnog predstavljanja i prijenosa poruka računalne pošte. Ime domaćina na kojem radi klijent K je ovdje oliver.efpu.hr, a ime domaćina na kojem radi server S je inf.uniri.hr. Stavke ispred kojih stoji "K:" upisuje SMTP klijent u svoju utičnicu TCP veze koja je prethodno uspostavljena između K i S; stavke ispred kojih stoji "S:" upisuje SMTP server u svoju utičnicu iste TCP veze, koja prenosi sadržaje u ovoj komunikaciji. Nakon što je klijent uspostavio TCP vezu sa SMTP serverom, između njih odvija se razmjena upravljačkih i sadržajnih poruka kakve ilustrira slijedeći primjer.

S: 220 inf.uniri.hrK: HELO oliver.efpu.hrS: 250 Hallo oliver.efpu.hr, pleased to meet youK: MAIL FROM: <mara@oliver.efpu.hr>S: 250 mara@oliver.efpu.hr ... Sender okK: RCPT TO: <jure@inf.uniri.hr>S: 250 jure@inf.uniri.hr ... Recipient okK: DATAS: 345 Enter mail, end with "." on a line by itselfK: (* ...... sadržaj poruke računalne pošte ...... *)K: .S: 250 Message accepted for deliveryK: QUITS: 221 inf.uniri.hr closing connection

Razmjenom danog niza poruka SMTP protokola između poštanskog servera Si koji radi na domaćinu oliver.efpu.hr (kao klijenta) i poštanskog servera So koji radi na domaćinu inf.uniri.hr (kao servera), izvršen je prijenos jedne poruke računalne pošte od korisnika čija adresa glasi mara@oliver.efpu.hr korisniku čija adresa glasi jure@inf.uniri.hr. Ta poruka je prenijeta sa izlazne liste poruka poštanskog servera-izvora Si na odredišni poštanski server So, koji tu poruku zapisuje u poštanski pretinac korisnika "jure", koji je registriran na poštanskom serveru So. Korisnik "jure" može zatim prenijeti tu poruku iz svog pretinca na serveru So na svoje osobno računalo pomoću svog korisničkog agenta za računalnu poštu.

Opišimo ukratko stavke iz gornjeg primjera komunikacije između dvaju poštanskih servera. Prije navedene razmjene poruka, između tih dvaju poštanskih servera uspostavljena je TCP veza. Jedan od dvaju poštanskih servera ima u ovoj komunikaciji ulogu klijenta (K) a drugi ima ulogu servera (S); TCP veza je uspostavljena na zahtjev klijenta. Nakon uspostave te TCP veze, u prvom retku serverska strana predstavlja se svojom SMTP porukom klijentskoj strani; serverska strana to čini navođenjem imena (adrese) domaćina na kojem ona radi.

Klijentska strana je već znala adresu domaćina serverske strane, jer bez toga ne bi bila mogla pokrenuti uspostavu TCP veze između njih, ali ovdje se izvodi razmjena poruka na SMTP razini (dakle, na aplikacijskoj razini), što treba razlikovati od razmjene poruka (i uspostave TCP veze) na transportnoj razini.

Poruke poštanskog servera S (koji u ovoj komunikaciji ima ulogu servera) počinju sa numeričkom kodom i sa tekstualnim objašnjenjem njena značenja. Poruke poštanskog servera K (koji u ovoj komunikaciji ima ulogu klijenta) počinju riječima kao što su HELO, MAIL FROM, i druge. U drugom retku (porukom "HELO ...") poštanski server K predstavlja se poštanskom serveru S (na SMTP razini) navodeći ime domaćina na kojem radi. U slijedećem retku, S potvrđuje primitak poruke od K (odgovorom "Hallo ...").

Poštanski server-klijent K zatim kaže poštanskom serveru-serveru S da ima poruku od Mare; ta poruka nalazi se u redu izlaznih poruka od K, što znači da ju treba prenijeti na njeno odredište. S prihvaća navedenu adresu računalne pošte, kao valjanog pošiljatelja.

34

K kaže da je primatelj te poruke Jure, koji ima poštanski pretinac na S; to ujedno znači da K namjerava prenijeti tu poruku na S. Svojim odgovorom, S prihvaća navedenu adresu računalne pošte primatelja kao valjanu.

Porukom DATA, klijent K najavljuje slanje sadržaja poruke računalne pošte. Server S prihvaća slanje i poručuje klijentu neka kao znak za završetak poruke navede jedan redak koji sadrži znak "." na početku i ništa više. To se ponekad piše kao <CRLF>.<CRLF>; prvi znak <CRLF> znači prelazak u novi red; na početku toga retka zapisan je znak ".", nakon čega slijedi novi prelazak u novi red.

Klijent K šalje serveru S sadržaj poruke od Mare za Juru, i označava njen završetak na zadani način. Server S na to javlja klijentu K da je tu poruku "prihvatio za isporuku"; time se valjda hoće reći da je primio poruku i da će poštanski server (za kojeg SMTP vrši prijenos) zapisati tu poruku u poštanski pretinac od Jure.

Konačno, klijent K šalje poruku QUIT da je završio sa svojim slanjem; S na to odgovara da je pokrenuo proces prekida TCP veze preko koje je izveden ovaj prijenos jedne poruke računalne pošte sa jednog poštanskog servera na drugog, odnosno ova komunikacija između dva poštanska servera, na SMTP razini.

Protokol SMTP radi sa persistentnom TCP vezom; to znači da se TCP veza između dvaju poštanskih servera ne prekida nakon prijenosa jedne poruke, ako pošiljatelj ima još poruka koje treba poslati istom primatelju. Ako sa poštanskog servera K treba prenijeti više poruka na isti poštanski server S, onda nakon prijenosa prve poruke (na način koji je opisan iznad), server K ne šalje serveru S poruku QUIT. Umjesto toga, K najavljuje i izvodi prijenos slijedeće poruke računalne pošte preko iste TCP veze. K to čini na taj način da ponovno izvede proces kojeg smo opisali iznad, počevši od retka (poruke) "MAIL FROM:" u kojem navodi adresu pošiljatelja nove poruke, koju hoće prenijeti serveru S. Jednak postupak ponavlja se sve dok ima poruka koje treba prenijeti sa poštanskog servera K na poštanski server S. Na kraju, poštanski server-klijent K šalje poštanskom serveru-serveru SMTP poruku QUIT sa kojom završava danu komunikaciju (sesiju) i traži od servera S da prekine TCP vezu preko koje je izvođena ova komunikacija.

Protokol SMTP prenosi datoteke sa jednog domaćina na drugog; to isto čini HTTP protokol o kojem smo govorili ranije. HTTP prenosi datoteke (koje se nazivaju objektima) sa web servera na web klijenta, koji je obično preglednik. SMTP prenosi datoteke (koje sadrže poruke računalne pošte) sa jednog poštanskog servera na drugi poštanski server. Oba dva protokola spadaju na aplikacijsku razinu mreže i koriste persistentne TCP veze za prijenos svojih sadržaja.

Pored tih značajnih sličnosti, između tih dvaju protokola postoje i značajne razlike. Prije svega, HTTP radi po metodi "dovlačenja" sadržaja (sa servera na klijenta), tako da se opisuje kao "pull protocol"; to možemo prevesti sa dovlačni protokol, ali može biti da postoji i neki ljepši prijevod. Na web servere postavljaju se razni informacijski sadržaji; web preglednici koriste usluge HTTP protokola za to da "dovuku" (prenesu) te sadržaje sa servera na osobna računala korisnika, gdje ih onda prikazuju na ekranima. Uspostavu TCP veze između web klijenta i web servera pokreće klijent koji hoće preko te veze dobiti neke sadržaje od servera.

Suprotno gornjem opisu, protokol SMTP opisuje se kao "push protocol" - to jest, kao odgurni protokol. Ovdje klijentski SMTP protokol uspostavlja TCP vezu sa serverskim SMTP protokolom zato da bi po toj vezi poslao (prenio, "odgurnuo") neke sadržaje (poruke, datoteke) sa svog domaćina i poštanskog servera na drugog domaćina i na njegov poštanski server.

Drugu bitnu razliku između protokola HTTP i SMTP spomenuli smo ranije: način kodiranja sadržaja za prijenos. SMTP traži da cjelokupan sadržaj koji se prenosi tim sustavom bude kodiran u 7-bitnom ASCII formatu. To znači da svi tekstovi koji nisu tako kodirani, kao i svi zapisi audio i video sadržaja, trebaju biti prekodirani u 7-bitni ASCII kodni zapis da bi mogli biti prenošeni u SMTP sustavu. Nakon prijenosa na konačno odredište, te sadržaje treba prekodirati iz 7-bitnog ASCII zapisa u njihov izvorni oblik zapisa. HTTP protokol, koji je mnogo mlađi od SMTP

35

protokola, ne postavlja takve zahtjeve, nego svaki sadržaj prenosi u onom formatu u kojem je taj sadržaj izvorno zapisan.

Treća razlika između HTTP i SMTP protokola sastoji se u načinu prenošenja jedne sadržajne cjeline, kao što je jedna web stranica, odnosno jedna poruka računalne pošte. Kad se jedna web stranica sastoji od sadržaja više datoteka (web objekata), onda HTTP klijent treba za svaki od tih objekata poslati poseban zahtjev HTTP serveru, na što mu server dostavlja traženi objekt. Takav niz zahtjeva i odgovora odvija se po istoj (persistentnoj) TCP vezi. S druge strane, kod SMTP protokola, sav sadržaj jedne poruke računalne pošte (svi dijelovi koji tvore jednu takvu poruku) smješta se u jednu datoteku koja se onda prenosi poštanskom serveru, bez obzira od koliko se dijelova (slika i privitaka) sastoji ta poruka.

Format poruke

Poruke računalne pošte sastoje se od dva osnovna dijela: zaglavlja i tijela. Ta dva dijela poruke odvojena su jednim praznim retkom: to jest, sa znakom <CRLF><CRLF>. Oblik i značenje (učinak) stavaka iz zaglavlja poruke računalne pošte definirani su u RFC 5322.

Svaki stavak zaglavlja sastoji se od ključne riječi, iza koje slijedi dvotočka i odgovarajući parametar. Neki od stavaka zaglavlja trebaju obavezno biti navedeni u svakoj poruci; neki od stavaka su opcionalni, što znači da ih se ne mora uvrstiti u zaglavlje poruke, ili da im se ne mora zadati parametre. Neke stavke zaglavlja (sa odgovarajućim parametrima) uvrštava sam korisnički agent za računalnu poštu pomoću kojeg se piše poruke i prenosi ih na poštanski server.

Zaglavlje svake poruke treba sadržavati stavak oblika "To: adresa-primatelja" i stavak "From: adresa-pošiljatelja" ; vrijednost parametra iz prvog stavka kazuje na koju adresu računalne pošte treba prenijeti tu poruku; vrijednost parametra iz drugog stavka pokazuje sa koje adrese računalne pošte je ta poruka poslana. Parametar u stavku "To:" upisuje korisnik koji piše (i šalje) poruku; parametar u stavku "From:" upisuje korisnički agent za računalnu poštu pomoću kojeg korisnik piše poruke i šalje ih svom poštanskom serveru. Osnovu zaglavlja poruke računalne pošte čini slijedeći niz stavaka:

From: mara@oliver.efpu.hrTo: jure@inf.uniri.hrSubject: --- jedno sitno pitanje ---

Treba razlikovati stavke u zaglavljima poruka računalne pošte, od sličnih stavaka (poruka) SMTP protokola, koje međusobno razmjenjuju poštanski serveri. Stavci iz zaglavlja poruka pokazuju odakle poruka dolazi i kamo je treba prenijeti; stavci iz SMTP komunikacije između poštanskih servera služe tome da se izvede prijenos poruke računalne pošte. Naprimjer, adresa računalne pošte koju klijent K javlja (u svojoj SMTP poruci) serveru S, jednaka je adresi računalne pošte koja je zapisana u zaglavlju poštanske poruke koju klijent K šalje serveru S za nekog primatelja koji ima tu adresu računalne pošte na poštanskom serveru S. Radi se o dva zapisa istog sadržaja, pri čemu ti zapisi imaju različite uloge.

Dakle, treba razlikovati "osobnu komunikaciju" između poštanskog servera-klijenta K i poštanskog servera-servera S na SMTP razini, od poruke (zaglavlja i tijela) koju se u toj SMTP komunikaciji prenosi sa jednog poštanskog servera na drugog. Komunikacija na SMTP razini između poštanskog servera K i poštanskog servera S potrebna je za izvršenje prijenosa poruke računalne pošte; ali ta komunikacija ima samo operativnu ulogu; sadržaj te komunikacije postaje nevažan po izvršenju operacije prijenosa. S druge strane, sadržaji iz poruke (zaglavlja i tijela) koju se prenosi - uključujući adrese iz njena zaglavlja - su trajni zapisi koji traju dok ih primatelj ne izbriše.

Preuzimanje poruka

36

Slika 3.10 prikazuje put poruke računalne pošte od njenog nastanka na osobnom računalu pošiljatelja (Mara), do prikaza njenog sadržaja na osobnom računalu primatelja (Jure).

Slika 3.10 Prijenos/put poruke računalne pošte

Mara proizvodi svoju poruku uz pomoć korisničkog agenta za računalnu poštu koji radi na njenom osobnom računalu. Nakon što je proizvela poruku, Mara daje naredbu svom agentu da pošalje tu poruku poštanskom serveru na kojem je Mara registrirana i ima adresu računalne pošte. Agent za računalnu poštu tada poprima ulogu klijenta u SMTP komunikaciji, što znači da pokreće postupak uspostave TCP veze sa Marinim poštanskim serverom, koji time poprima ulogu servera u SMTP komunikaciji koja će se odvijati preko te veze. U komunikaciji između ta dva elementa na SMTP razini (kakvu smo opisali ranije), poruka računalne pošte biva prenijeta sa osobnog računala pošiljatelja (Mara) na poštanski server pošiljatelja, odnosno u red izlaznih poruka toga servera.

Poštanski server uspostavlja TCP veze sa onim poštanskim serverima širom svijeta na kojima imaju adrese i poštanske pretince primatelji poruka (od raznih pošiljatelja) koje se nalaze u njegovom redu izlaznih poruka i koje poštanski server stalno šalje primateljima tih poruka. Prijenos poruka odvija se u komunikaciji između poštanskih servera na SMTP razini, koja se odvija na način kako smo to opisali iznad.

Preostaje još zadnja dionica puta kojeg poruka treba prijeći od svog izvora (Mare) do svog odredišta (Jure): to je dionica od Jurinog poštanskog pretinca na poštanskom serveru, do njegovog osobnog računala (a time i do njega). Na slici 3.10 navedeno je nekoliko protokola koji se mogu koristiti za prijenos poruka na toj dionici puta, ali među njima nije naveden protokol SMTP. Kako smo to ranije rekli, SMTP je "odgurni" protokol, tako da nije prikladan za to da primatelj poruka pomoću njega "dovlači" poruke iz svog poštanskog pretinca na svoje osobno računalo. Definirano je više protokola koji prenose poruke iz poštanskih pretinaca korisnika (na poštanskom serveru) na osobna računala korisnika. Među poznate protokole te vrste spadaju POP3 (Post Office Protocol - Version 3) i IMAP (Internet Mail Access Protocol); za prijenos poruka na toj (zadnjoj)

37

dionici puta može se koristiti i protokol HTTP, jer je taj protokol povlačnog tipa.

Protokol POP 3

Protokol POP3 omogućava primatelju poruka računalne pošte da prenese poruke iz svog poštanskog pretinca na poštanskom serveru, na svoje osobno računalo. Protokol POP3 definiran je u RFC 1939. Korisnik daje naredbu svom agentu za računalnu poštu da mu omogući pristup sadržaju njegovog poštanskog pretinca na njegovom poštanskom serveru. Agent na to uspostavlja TCP vezu sa zadanim poštanskim serverom; na tom serveru, na portu 110 poruke prima protokol POP3.

Pomoću protokola POP3, proces preuzimanja sadržaja iz poštanskog pretinca na serveru izvodi se u tri faze: (1) autorizacija (provjera) korisnika, (2) prijenos poruka na računalo korisnika, i (3) ažuriranje stanja poštanskog pretinca.

U prvoj fazi, korisnik pomoću svog agenta za računalnu poštu, šalje poštanskom serveru svoje ime i lozinku, sa kojima je registriran na tom serveru. Ako je korisnik valjano registriran i ako faza autorizacije završi uspješno, slijedi druga faza; u suprotnom, taj pokušaj pristupa poštanskom serveru (i određenom pretincu računalne pošte) završava s neuspjehom.

U drugoj fazi, korisnikov poštanski agent prenosi poruke iz korisnikovog poštanskog pretinca na korisnikovo računalo; agent to čini uz pomoć POP3 protokola. U toj fazi, agent može označavati u poštanskom pretincu one poruke koje treba brisati iz pretinca, nakon što je kopija njihovog sadržaja prenijeta na računalo korisnika.

Kad korisnički agent za računalnu poštu (kao klijent) završi s preuzimanjem (prijenosom) poruka iz poštanskog pretinca, onda izdaje naredbu "quit" sa kojom završava svoju komunikaciju sa protokolom POP3 (završava POP3 sesiju). Tada slijedi treća faza preuzimanja poštanskih poruka, u kojoj poštanski server briše iz korisnikovog poštanskog pretinca one poruke koje je korisnički agent označio za brisanje (nakon što je preuzeo njihov sadržaj).

Komunikacija između korisničkog agenta za računalnu poštu (kao klijenta) i protokola POP3 na poštanskom serveru (kao servera), odvija se na taj način da klijent izdaje naredbe, na koje server odgovara. Odgovor servera počinje sa "+OK" ako server prihvaća naredbu klijenta kao ispravnu. Iza oznake "+OK" mogu slijediti podaci koje server šalje kao odgovor na naredbu klijenta (iz prethodnog retka). Ako server smatra da naredba klijenta nije valjana (ili izvršiva), onda na tu naredbu šalje odgovor koji počinje sa "-ERR" Korisnički agent za računalnu poštu, koji koristi protokol POP3 za preuzimanje računalne pošte sa servera, može biti postavljen na jednu od dvije osnovne opcije: (1) "preuzmi i izbriši" iz pretinca (download and delete), ili (2) "preuzmi i ostavi (zadrži)" u pretincu (download and keep). U procesu preuzimanja (kopiranja) poruka iz poštanskog pretinca, protokol POP3 može označavati one preuzete poruke koje treba izbrisati iz pretinca; to brisanje zatim izvodi poštanski server. Hoće li POP3 označavati poruke za brisanje, ili neće, zavisi od toga na koju je od spomenute dvije opcije postavljen poštanski agent kojemu POP3 pruža usluge, jer poštanski agent daje naredbe protokolu POP3 kako da postupa.

Pogledajmo jedan primjer komunikacije između korisničkog agenta za računalnu poštu i poštanskog servera, koja se odvija preko protokola POP3, pri čemu je na agentu postavljena opcija "preuzmi i izbriši". Ovaj proces odvija se nakon uspješne faze autorizacije (prijave) korisnika na poštanski server.

K: listS: 1 5318S: 2 7592S: .K: retr 1S: (* ...... šalje sadržaj poruke 1 ...... *)

38

S: .K: dele 1K: retr 2S: (* ...... šalje sadržaj poruke 2 ...... *)S: .K: dele 2K: quitS: +OK POP3 server signing off

Klijent prvo traži od servera (na kojem radi POP3) da mu dade listu poruka koje se nalaze u njegovom poštanskom pretincu i veličine tih poruka (u bajtovima). Server odgovara na taj zahtjev i završava svoj odgovor sa znakom "." na početku retka koji sadrži samo taj znak.

Klijent (to jest, korisnički agent za računalnu poštu) traži od servera da mu dostavi sadržaj prve poruke; server (preko POP3) prenosi sadržaj poruke klijentu (agentu). Po primitku sadržaja tražene poruke, agent šalje naredbu protokolu POP3 na serveru da tu poruku briše iz poštanskog pretinca korisnika; na temelju te naredbe, POP3 na serveru označava tu poruku za brisanje.

Korisnički agent (kao klijent) zatim traži i dobiva (preko POP3) poruku broj 2; nakon toga agent daje naredbu protokolu POP3 da tu poruku briše iz poštanskog pretinca; na temelju toga, POP3 označava tu poruku za brisanje.

Nakon što je dobio obje poruke, korisnički agent prekida komunikaciju sa protokolom POP3 koji radi na poštanskom serveru, a time i sa poštanskim serverom. Protokol POP3 prihvaća zahtjev korisničkog agenta (kao klijenta) za prekid veze.

Nakon završetka prijenosa poruka računalne pošte i prekida veze, poštanski server izvodi treću fazu procesa preuzimanja računalne pošte: briše iz poštanskog pretinca danog korisnika one poruke koje je njegov agent tražio da budu izbrisane.

Ako korisnik želi gledati iste poruke iz svog poštanskog pretinca sa više računala, onda njegov agent treba biti postavljen na opciju "preuzmi i ostavi na serveru". Tada poštanski agent prenosi kopije poruka iz poštanskog pretinca na osobno računalo korisnika, ali ne daje zahtjev da se te poruke brišu iz pretinca. To omogućava korisniku da kopije istih poruka preuzima i na druga računala; dakle, da "čita istu poštu" sa više mjesta, odnosno preko više korisničkih računala. Kod tog načina rada dobro je na jednom od računala (zadnjem) sa kojih korisnik čita poštu ipak postaviti opciju "preuzmi i izbriši", jer se inače u poštanskom pretincu na serveru skuplja velik broj (nepotrebnih) poruka.

Protokol IMAP

Nakon što preuzme poruke iz svog pretinca na poštanskom serveru i prenese ih na svoje računalo, korisnik može uz pomoć agenta za računalnu poštu, urediti (složiti) te poruke u mape (direktorije) onako kako mu to odgovara. Dakle, poruke se u ovom slučaju uređuju (slažu u mape) na računalu korisnika, nakon što su preuzete sa servera. Ta mogućnost je dobra, ali nije dovoljno dobra za one koji preuzimaju kopije istih poruka na više računala, kako je to opisano iznad. Jer ako korisnik uredi (složi) preuzete poruke u mape na jednom od svojih računala, time to neće biti učinjeno i na ostalim računalima.

Poštanski server omogućava da poruke čiji su sadržaji preuzeti (kopirani) na neko računalo korisnika ostanu zapisane u poštanskom pretincu toga korisnika na serveru, tako da korisnik može preuzimati (kopirati) iste sadržaje na mnogo računala. Ali protokol POP3, koji radi sa poštanskim pretincima na serveru, ne omogućava da se poruke uređuju u pretincima korisnika na serveru.

Dakle, kod protokola POP3, korisnik ima mogućnost zadržati kopirane poruke u pretincu (i kopirati te poruke na mnogo računala), ali nema mogućnost urediti te poruke u svom poštanskom pretincu, a onda gledati tako uređene poruke sa mnogo mjesta. Ako korisnik želi da njegove poruke

39

budu jednako uređene u mape na svim računalima na koje preuzima njihove kopije, onda mora te poruke urediti na svakom od tih računala nanovo.

Jedno rješenje opisanog problema je da se korisniku omogući da svoje poruke trajno čuva u svom pretincu na poštanskom serveru i da te poruke uređuje u mape u svom pretincu na serveru. Na taj način korisnik bi mogao gledati iste sadržaje i isto uređenje tih sadržaja sa različitih računala, jer bi ti sadržaji bili zapisani i uređeni na jednom mjestu: u korisnikovu poštanskom pretincu na poštanskom serveru. Protokol POP3 ne omogućava korisnicima da poruke u svojim poštanskim pretincima na serveru uređuju u mape. Zato je razvijen protokol IMAP (Internet Mail Access Protocol), koji korisnicima daje takvu mogućnost; taj protokol definiran je u RFC 3501.

IMAP je protokol pomoću kojeg korisnički agent za računalnu poštu pristupa poštanskim pretincima korisnika, kao i pomoću protokola POP3. Ali IMAP omogućava korisniku (agentu) da u svom poštanskom pretincu definira mape (direktorije) kako želi, i da poruke koje stižu u njegov osnovni Inbox direktorij prenosi u one svoje mape u koje želi. Korisnik može brisati primljene poruke ako želi, iz Inbox direktorija i iz drugih mapa koje je sam kreirao.

Čuvanje poruka u poštanskom pretincu na poštanskom serveru i uređivanje tih poruka u mape na tom serveru, omogućava korisniku da gleda iste poruke jednako uređene (u mape), sa svakog računala sa kojeg gleda svoju računalnu poštu.

Protokol IMAP sadrži naredbe (funkcije) koje korisnicima pružaju razne druge mogućnosti. Korisnički agent za računalnu poštu može tražiti od IMAP protokola (koji radi na poštanskom serveru), samo pojedine dijelove poruka računalne pošte. Tako agent može tražiti i dobiti od IMAP protokola samo zaglavlja poruka; ako je neka poruka vrlo velika, a propusnost veze između klijentskog i serverskog računala je (trenutno) mala, onda agent (kao klijent) može ne prenositi tu poruku na to računalo.

Poruke računalne pošte obično se pišu u formatu MIME, koji omogućava da se poruke sastavljaju od dijelova koji sadrže različit vrste sadržaja. To mogu biti razne vrste tekstova, digitalni zapisi zvuka, slika i pokretnih slika, te razne strukture podataka (tablica, grafova i drugog) koje proizvode razne aplikacije kao što je Word, CorelDRAW i druge. Protokol IMAP omogućava poštanskom agentu da preuzme (prenese na računalo korisnika) samo neke dijelove poruke koja je sastavljana u MIME formatu.

Na slici 3.10 navedeno je da poruke računalne pošte mogu biti prenošene sa poštanskog servera na osobno računalo i pomoću HTTP protokola. Kod takvog načina rada ulogu korisničkog agenta ima web preglednik, koji donosi poruke sa poštanskog servera uz pomoć HTTP protokola i prikazuje te poruke na osobnom računalu; preglednik može isto tako prenositi poruke sa osobnog računala na poštanski server uz upotrebu HTTP protokola.

Kod ovog načina rada govori se o web emailu; to su poruke računalne pošte koje se proizvode i prenose na poštanski server i sa njega uz upotrebu elemenata web sustava. Ali prijenos poruka računalne pošte između poštanskih servera izvodi se i dalje uz pomoć SMPT protokola i sustava, kako to pokazuje slika 3.10.

3.5 Sustav imena domena DNS

Računalo u mreži treba imati jedinstvenu oznaku u toj mreži, koja omogućava njegovu identifikaciju. Takvu oznaku nazivamo imenom ili adresom računala. Ljudima više odgovara uporaba tekstualnih imena, koja se mogu sastojati od više dijelova i biti varijabilne dužine. Takva imena mogu ujedno pokazivati gdje je fizički smješteno neko računalo; naprimjer iz imena (adrese)

40

računala inf.uniri.hr može se vidjeti da se to računalo nalazi u Hrvatskoj; neki će iz te adrese ujedno vidjeti da je to računalo od Sveučilišta u Rijeci (uniri), i to od Odjela za informatiku (inf).

S druge strane, mrežne procese koji rade sa adresama, lakše je oblikovati i izraditi ako su adrese numeričke i ako imaju jednaku strukturu i dužinu. Zato su računalima u mreži Internet dodijeljene dvojne oznake: (1) tekstualne adrese, koje koriste ljudi, i (2) numeričke adrese, s kojima rade računala u mreži.

Tekstualne adrese nazivaju se mnemoničkim adresama, ili imenima. Numeričku adresu tvori niz od 32 bita (kod IPv4) koji se naziva IP adresom. Numeričke IP adrese promatraju se kao četiri 8-bitna bajta i zapisuju se sa dekadskim vrijednostima tih bajtova: svaki bajt sa jednim brojem; pritom su ta četiri zapisa odvojena (ili spojena) točkama. Naprimjer, 120.34.218.14 je jedna IP adresa. Osnovni zadatak sustava DNS je da za svaku danu tekstualnu adresu nekog računala u mreži Internet, nađe njegovu numeričku (IP) adresu. Jer vezu sa nekim čvorom mreže može se uspostaviti samo na osnovu njegove numeričke IP adrese. Kratica DNS dolazi od "domain name system", što se može prevesti sa sustav imena domena.

DNS sustav je jedna distribuirana baza podataka, koja je implementirana pomoću jednog globalnog sustava DNS servera koji tvore hijerarhijsku strukturu, ili koji su organizirani u jedan sustav hijerarhijske strukture. DNS je isto tako jedan protokol aplikacijske razine koji omogućava mrežnim aplikacijama da toj distribuiranoj bazi podataka postavljaju upite i da od nje dobivaju odgovore na te upite. Sustav DNS koristi usluge UDP protokola transportne razine, a radi na portu 53.

Usluge sustava DNS ne koriste izravno korisnici (osobe), nego ih koriste drugi sustavi aplikacijske razine; dakle, protokoli kao što su HTTP, FTP i SMTP. Kod upotrebe tih sustava, korisnici navode tekstualne adrese domaćina s kojima hoće komunicirati; zato ti aplikacijski sustavi trebaju usluge DNS sustava, da im za dane tekstualne adrese dade pripadne IP adrese. Jer vezu sa nekim čvorom u mreži može se uspostaviti jedino na osnovu numeričke (IP) adrese toga čvora.

U nastavku iznosimo opis strukture i načina rada DNS sustava; u opisu koristimo konkretne adrese, ali opis je načelan: to znači da pokazuje načela organizacije sustava i načela njegova rada, ali konkretne realizacije mogu odstupati od danog opisa iz raznih praktičkih razloga. Pogledajmo najprije na koji način DNS sustav pruža usluge drugim aplikacijama, naprimjer web pregledniku.

Korisnik zadaje web pregledniku URL adresu kao što je inf.uniri.hr/~mradovan/index.html; da bi web preglednik sa domaćina Di mogao uspostaviti TCP vezu sa web serverom na kojem se nalazi dana URL adresa, web preglednik treba imati IP adresu domaćina Dj na kojem se nalazi taj web server. Na domaćinu Di na kojem radi web preglednik, radi klijentska strana DNS sustava. Preglednik uzima tekstualno ime domaćina (ovdje inf.uniri.hr) iz URL adrese koja mu je zadana i predaje to ime klijentskoj strani DNS sustava na tom domaćinu. DNS klijent šalje upit sa danom tekstualnom adresom domaćina lokalnom DNS serveru za danu lokalnu mrežu (u kojoj se nalazi Di). Uzmimo da lokalni DNS ne zna numeričku IP adresu za danu tekstualnu adresu domaćina Dj; tada lokalni DNS šalje dobiveni upit odgovarajućem DNS serveru u hijerarhijskom sustavu DNS servera. Time počinje proces na kraju kojeg lokalni DNS server nalazi traženu IP adresu i predaje je DNS klijentu na domaćinu koji je tražio tu IP adresu. DNS klijent predaje dobivenu IP adresu web pregledniku koji ju je tražio.

Na temelju dobivene IP adrese domaćina Dj, web preglednik sa domaćina Di pokreće postupak uspostave TCP veze sa web serverom koji se nalazi na domaćinu Dj i prima poruke na portu 80. Proces nalaženja IP adrese u DNS sustavu opisan je podrobnije u nastavku.

Pored svog osnovnog posla kojeg smo ukratko opisali iznad, sustav DNS obavlja i druge poslove, tako da je to jedan opsežan i složen sustav. DNS je definiran u RFC 1034 i RFC 1035, ali specifikacije (opisi) toga sustava su kasnije dopunjavane u još nekoliko RFCa. Spomenimo ukratko još neke stvari koje se zasnivaju na uslugama DNS sustava.

DNS sustav omogućava da isti domaćin koristi više tekstualnih imena (adresa) uz istu IP adresu. Jedno od tih imena domaćina naziva se kanonskim, dok se ostala imena nazivaju "alias"

41

tekstualnim (ili mnemoničkim) imenima toga domaćina.DNS omogućava i da jedno tekstualno ime referira na više IP adresa. Neka popularna

web sjedišta primaju više desetaka tisuća zahtjeva klijenata u sekundi za uspostavu veze. Jedno računalo ne može fizički izvršavati tako velik broj zahtjeva; taj problem rješava se na taj način da se kopije sadržaja jednog web sjedišta postave na web servere na više domaćina. Svaki od tih domaćina ima svoju (drukčiju) IP adresu, ali svi oni imaju istu tekstualnu adresu. U takvoj situaciji kaže se da web sjedište ima više replika, što znači više kopija istog sadržaja. Da bi bilo zaista tako, sadržaje svih replika treba stalno usklađivati s promjenama sadržaja danog web sjedišta. Dovoljan broj takvih sjedišta-replika uspijeva odgovoriti na zahtjeve svih klijenata.

Web sjedište sa više replika koristi istu tekstualnu adresu za sve domaćine na kojima se nalaze njegove replike, ali svaki od tih domaćina ima (i treba imati) jedinstvenu numeričku IP adresu. U ovakvoj situaciji, za jedno tekstualno ime web sjedišta, DNS sadrži skup (listu) IP adresa svih domaćina na kojima se nalaze replike toga sjedišta. Kad klijent zatraži IP adresu sjedišta koje ima više replika, onda mu DNS sustav dostavlja listu IP adresa svih domaćina na kojima se nalaze replike sjedišta čiju je tekstualnu adresu (uzetu iz URLa) klijent zadao DNS sustavu. DNS pritom rotira listu adresa u svom odgovoru. Web preglednik koji je tražio IP adresu web sjedišta, obično uzima prvu IP adresu sa dobivene liste-odgovora i uspostavlja TCP vezu sa domaćinom na toj IP adresi. Na taj način, rotiranjem liste IP adresa u svojim odgovorima klijentima, DNS dijeli teret upita klijenata na ravnomjeran način između svih replika jednog web sjedišta.

Korisnici usluga Interneta ne komuniciraju izravno sa DNS sustavom; sa tim sustavom komuniciraju drugi sustavi aplikacijske razine, kao što su web preglednik i FTP sustav, s kojima izravno rade korisnici usluga Interneta. Iako korisnici ne koriste izravno njegove usluge, DNS je protokol (i sustav) aplikacijske razine, jer DNS ne ostvaruje usluge prijenosa, nego u svom radu koristi usluge prijenosa, kako je to opisano u nastavku. Kad bi na svakom domaćinu postojala jedna datoteka koja sadrži parove svih tekstualnih adresa domaćina u Internetu i pripadnih numeričkih IP adresa, onda DNS kao sustav koji nalazi IP adrese za dane tekstualne adrese, ne bi trebao postojati. Takva datoteka korištena je u počecima razvoja Interneta; ali broj čvorova je s vremenom postao toliko velik da je održavanje takve datoteke na svakom domaćinu (jer stvari se mijenjaju) postalo previše zahtjevno i neopravdano. Zato je umjesto mnogo kopija jedne datoteke takvih parova uveden DNS sustav.

Pogledajmo strukturu DNS sustava i način rada toga sustava. Slika 3.11 pokazuje na koji način je oblikovana hijerarhija DNS servera u globalnom DNS sustavu.

42

Slika 3.11 Struktura DNS sustava

Na vrhu hijerarhije nalaze se korijenski DNS serveri (root DNS servers); u informatici stabla obično stoje naopako, tako da im je korijen na vrhu. Slijedi razina DNS servera koji se nazivaju serverima vršnih domena (top-level domain DNS - TLD DNS). Serveri treće razine DNS sustava općenito se nazivaju mjerodavnim DNS serverima (authoritative DNS). Međutim, vršne domene često imaju više razina pod-domena; tada su obično mjerodavni DNS serveri najniže razine u toj hijerarhiji. Te DNS servere naziva se mjerodavnima zato što oni sadrže parove tekstualnih adresa i pripadnih IP adresa za konkretne domaćine. DNS serveri viših razina sadrže samo podatke koji vode do pravog mjerodavnog DNS servera za traženu IP adresu.

Globalni DNS sustav ima 13 korijenskih DNS servera (u vrijeme pisanja ovog teksta), koji nose oznake od "A" do "M". Većina korijenskih servera DNS sustava nalazi se u Americi, ali ti serveri imaju replike na desetak ili više lokacija u svijetu. Replike se nalaze na različitim mjestima, čime se olakšava pristup (skraćuje put) do tih DNS servera. Replike ujedno povećavaju sigurnost i pouzdanost rada DNS sustava; u slučaju kvara (oštećenja) nekih replika, isti sadržaji i usluge sačuvani su (i dostupni) na drugim replikama toga servera.

Svaki od servera vršne domene (TLD) sadrži podatke o sustavu DNS servera za tu domenu. Vršne domene su net, com, org, edu, gov, i mil, koje su uvele SAD u ranoj fazi razvoja Interneta; druge države obično imaju po jednu vršnu domenu; takve domene su de, fr, uk, jp, it, hr, i druge. Serveri vršnih domena isto tako imaju više replika, zbog povećanja dostupnosti i sigurnosti njihovih sadržaja. Koliko replika imaju, uvelike zavisi od veličine države (i broja korisnika Interneta); država od milijardu ljudi ima više replika DNS servera svoje vršne domene nego države od milijun ljudi.

Mjerodavni DNS serveri sadrže parove tekstualnih imena i pripadnih IP adresa (i druge podatke) za domaćine jednog ograničenog prostora, ili jedne organizacijske jedinice. Davatelj Internet usluga na nekom području obično ima svoj mjerodavni DNS server sa podacima o svojim domaćinima na tom području; velika tvrtka, ili sveučilište mogu imati svoj mjerodavni DNS server koji sadrži podatke o njihovim domaćinima.

Pored opisanih triju vrsta DNS servera, postoje i lokalni DNS serveri, koje se ne smatra dijelom hijerarhije servera kakvu prikazuje slika 3.11. Kako to njihov naziv pokazuje, lokalni DNS serveri nalaze se blizu onih domaćina kojima pružaju usluge. Takvi DNS serveri mogu biti sadržani u LANovima i mrežama tvrtki i institucija, ili u mrežama ISPa na nekom ograničenom području. Tvrtke i institucije ne moraju imati vlastite mjerodavne DNS servere; podatke o adresama njihovih domaćina može sadržavati i održavati mjerodavni DNS server nekog većeg ISPa sa tog područja. Ali velike tvrtke i institucije često imaju vlastite lokalne DNS servere.

Lokalni DNS server ponaša se kao proxy DNS server za mrežu nekog lokalnog prostora. Kad neka aplikacija na nekom domaćinu treba IP adresu za neku danu tekstualnu adresu nekog udaljenog domaćina, onda ta aplikacija šalje svoj upit lokalnom DNS serveru. Ako taj server ima zapisanu IP adresu za danu tekstualnu adresu (u svojoj bazi podataka), onda odmah odgovara na dobiveni zahtjev. Ako lokalni DNS server nema zapisan odgovor na dobiveni upit, onda taj upit (zahtjev) prosljeđuje u hijerarhijski sustav DNS servera na način koji je opisan u nastavku. Slika 3.12 prikazuje niz koraka koji bivaju izvedeni u DNS sustavu, da bi taj sustav servera proizveo odgovor na jedan upit.

43

Slika 3.12 Rad sustava DNS servera

U danom primjeru uzeto je da neka aplikacija A na domaćinu Di čija tekstualna adresa je cs.ucla.edu, traži IP adresu domaćina Dj čija tekstualna adresa glasi inf.uniri.hr. Neka pritom tekstualna adresa lokalnog DNS servera bude dns.ucla.edu, a tekstualna adresa mjerodavnog DNS server za domaćina Dj (čiju se IP adresu traži) neka bude dns.uniri.hr. Pogledajmo kako se odvija proces nalaženja IP adrese od Dj, koju traži aplikacija A sa domaćina Di.

(1) Di šalje svom lokalnom DNS serveru zahtjev kojim traži IP adresu od Dj. Lokalni DNS ne sadrži (nema pohranjen) taj podatak, tako da ne može izravno odgovoriti na taj zahtjev. Lokalni DNS isto tako ne zna na kojem mjerodavnom DNS serveru je zapisan taj podatak.

(2) Zato lokalni DNS šalje primljeni zahtjev jednom od korijenskih DNS servera.(3) Korijenski DNS server ne sadrži podatke o pojedinačnim domaćinima, tako da ne može

odgovoriti na primljeni zahtjev. Ali korijenski DNS server sadrži podatke o DNS serverima vršnih domena; zato lokalnom DNS serveru šalje listu IP adresa od DNS servera koji sadrže podatke o vršnoj domeni "hr".

(4) Lokalni DNS sad šalje isti zahtjev na jednu od IP adresa (prvu na listi) koje je dobio u prethodnom koraku. To znači da upit o IP adresi domaćina Dj šalje jednom od DNS servera koji sadrže podatke o vršnoj domeni "hr".

(5) DNS server vršne razine "hr" nema podatak o tekstualnoj adresi (inf.uniri.hr), ali na temelju pod-domene "uniri" iz te adrese, taj vršni DNS server šalje tražitelju IP adresu mjerodavnog DNS servera za Sveučilište u Rijeci; dakle, IP adresu od DNS servera koji se nalazi na domaćinu dns.uniri.hr.

(6) Lokalni DNS sad šalje polazni zahtjev, sa kojim traži IP adresu od Dj, mjerodavnom DNS serveru čiju je IP adresu dobio u prethodnom koraku.

(7) Taj mjerodavni DNS server sadrži podatak o IP adresi domaćina Dj čiju tekstualnu adresu (inf.uniri.hr) mu je poslao lokalni DNS server dns.ucla.edu. Mjerodavni DNS izvršava

44

zadatak kojeg je dobio od lokalnog servera: dakle, šalje traženu (numeričku) IP adresu domaćina Dj lokalnom DNS serveru dns.ucla.edu.

(8) Lokalni DNS server sad šalje dobivenu IP adresu tražitelju na domaćinu Di.

Dani opis postupka traženja numeričke IP adrese za danu tekstualnu adresu pokazuje strukturu i način rada DNS sustava. Konkretna rješenja u nekim vršnim domenama mogu sadržavati više ili manje razina sustava DNS servera, zavisno od konkretnih potreba.

Lokalni DNS server, za kojeg smo rekli da ima ulogu proxy servera, zapisuje u svoju memoriju podatke o tekstualnim adresama i pripadnim IP adresama domaćina, koje saznaje u procesu rada kojeg smo opisali iznad. Kad neka aplikacija sa nekog domaćina kasnije zatraži od tog lokalnog DNS servera IP adresu za neku tekstualnu adresu domaćina, onda lokalni DNS najprije provjerava da li u svojoj bazi podataka ima zapisanu IP adresu za danu tekstualnu adresu. Ako ima, onda može izravno odgovoriti na primljeni zahtjev, bez da izvodi proces nalaženja tražene IP adrese, kojeg smo opisali iznad.

Lokalni DNS server zapisuje u svoju bazu i razne druge podatke; naprimjer, IP adrese DNS servera vršnih domena (ima ih relativno malo), tako da više ne treba ništa pitati DNS servere sa korijenske razine DNS sustava. Lokalni DNS server može zapisivati i IP adrese mjerodavnih DNS servera, tako da na temelju danih tekstualnih adresa domaćina, svoje upite može slati izravno odgovarajućim mjerodavnim serverima.

U načelu, da bi našao IP adresu za bilo koju tekstualnu adresu u Internetu, lokalni DNS server treba znati samo IP adresu jednog od DNS servera korijenske razine. Sve ostalo saznaje u procesu kojeg smo opisali iznad. Ali lokalni DNS server zapisuje čim više podataka o adresama, tako da te podatke ne mora ponovno tražiti od globalnog DNS sustava. Pored IP adresa domaćina, lokalni DNS server zapisuje u svoju memoriju IP adrese DNS servera nižih razina, koje dobiva od DNS servera viših razina. U danom primjeru, lokalni DNS zapisao bi u svoju memoriju listu IP adresa DNS servera vršne domene "hr", koju mu je dostavio DNS server korijenske razine, kojem je prvo uputio svoj zahtjev. Isto tako zapisao bi i IP adresu mjerodavnog DNS servera za domenu uniri.hr.

Stvarnost se mijenja, tako da podaci zastarijevaju. Velika većina domaćina ne mijenja često svoje tekstualno ime, ni numeričku IP adresu. Ali neki domaćini ponekad promijene jedno ili drugo, češće tekstualno ime. Zbog toga što se neke stvari ponekad mijenjaju i što neki podaci zbog toga postaju zastarjeli, lokalni DNS server koristi svoje zapise o tekstualnim i IP adresama koji su stari do dva dana. Nakon toga ti podaci smatraju se zastarjelima; ako neka aplikacija zatraži neku IP adresu o kojoj lokalni DNS server ima zastarjeli zapis, onda lokalni DNS server pokreće ponovno proces traženja te IP adrese; kada od DNS sustava dobije tu IP adresu, onda je šalje tražitelju, te ujedno osvježava svoj (zastarjeli) zapis o toj IP adresi.

Hijerarhijska struktura DNS sustava nema svugdje točno tri razine. Neki DNS server sa treće razine može sadržavati IP adrese nekih domaćina iz domene koju pokriva, ali ta domena može imati svoje pod-domene; tada taj DNS server sadrži IP adrese DNS servera tih pod-domena. Na upit lokalnog DNS servera, takav DNS server treće razine može odgovoriti sa IP adresom DNS servera odgovarajuće pod-domene. Tada lokalni DNS server traži odgovor na svoj upit od DNS servera te pod-domene. U pojedinim dijelovima hijerarhija DNS sustava može imati više razina pod-domena, ali načelo rada DNS sustava je isto. DNS serveri viših razina vode lokalnog DNS servera prema mjerodavnom DNS serveru za danu tekstualnu adresu, koji onda tražitelju šalje pripadnu IP adresu.

Pokazali smo na koji način DNS sustav nalazi numeričku IP adresu za danu tekstualnu adresu domaćina. Numerička IP adresa omogućava komunikaciju (uz uspostavu TCP veze ili bez toga) sa udaljenim domaćinom, na temelju koje dana aplikacija izvodi tražene poslove. Ne zalazeći u pojedinosti, recimo da zapisi podatkovnih sadržaja u DNS sustavu sadrže više parametara, i obično se opisuju kao četvorke slijedećeg oblika:

45

< ime, vrijednost, tip, ttl >Značenja prvih dvaju parametara zavise od vrijednosti trećeg parametra, koji pokazuje kojeg

je tipa dani zapis. Tipom zapisa razlikuje se zapise koji sadrže podatke o IP adresama domaćina, od zapisa koji sadrže podatke o DNS serverima i o domenama. Osnovni tipovi zapisa su A i NS, ali postoje i drugi tipovi zapisa. U zapisima tipa A, prvi parametar je tekstualno ime domaćina, a drugi parametar je njegova numerička IP adresa.

Četvrti parametar (ttl - time to live) sadrži vijek trajanja danog zapisa (koji zastarijeva). Zapis koji je zastario ne valja koristiti, bez obzira da li se briše iz baze odmah kad zastari, ili biva pregažen novim zapisom onda kad neka aplikacija zatraži IP adresu čiji je zapis u bazi lokalnog DNS servera zastario.

Sadržaji mjerodavnih DNS servera su uglavnom tipa A. Takve sadržaje traže od lokalnih DNS servera razne aplikacije: za danu tekstualnu adresu, traže pripadnu IP adresu. Lokalni DNS serveri pohranjuju takve zapise u svoju memoriju; na temelju toga onda daju izravne odgovore na zahtjeve drugih aplikacija, dok ti zapisi ne zastare.

DNS serveri viših razina sadrže zapise tipa A, ali i zapise tipa NS, koji su istog oblika, ali su značenja njihovih parametara različita. Kod zapisa tipa NS, prvi parametar je naziv domene, a drugi parametar je tekstualna adresa domaćina na kojem se nalazi DNS server te domene. Taj DNS server može biti mjerodavan za danu domenu, ili može sadržavati zapise tipa NS o DNS serverima pod-domena dane domene.

Primjer zapisa tipa A izgleda ovako:< xxx.yyy.com, 142.135.28.212, A, ttl >Primjer zapisa tipa NS izgleda ovako:< yyy.com, dns.yyy.com, NS, ttl >

Na temelju zapisa tipa NS, DNS serveri viših razina daju odgovore lokalnim DNS serverima, sa kojima te servere vode prema odgovarajućim mjerodavnim DNS serverima, od kojih onda lokalni DNS serveri dobivaju konačne odgovore na svoje polazne upite, koje na početku šalju višim razinama DNS sustava.

Pored zapisa tipa NS, DNS serveri viših razina trebaju sadržavati i odgovarajuće zapise tipa A, tako da lokalnim DNS serverima mogu slati IP adrese odgovarajućih DNS servera nižih razina. Naprimjer, gornji zapis tipa NS može se nalaziti na DNS serveru vršne domene "com" i sadržavati tekstualnu adresu odgovarajućeg DNS servera mjerodavne razine za pod-domenu "yyy" od vršne domene "com". Tada uz takav zapis tipa NS, dani DNS server više razine treba sadržavati i zapis tipa A slijedećeg oblika:

< dns.yyy.com, 122.64.180.72, A, ttl >Gornji zapis tipa NS daje DNS serveru (na kojem je zapisan) tekstualnu adresu DNS

servera čiju IP adresu treba poslati lokalnom DNS serveru, kao odgovor na njegov upit. Zapis tipa A, koji ide uz taj zapis tipa NS, sadrži IP adresu DNS servera niže razine, koju DNS server više razine šalje lokalnom DNS serveru, kao odgovor na njegov upit. Na taj način, lokalni DNS server stiže do odgovarajućeg mjerodavnog DNS servera, te od njega dobiva konačni odgovor na svoj početni upit, kako je to opisano iznad.

Opisali smo osnovnu strukturu DNS sustava i pokazali na koji način taj sustav nalazi odgovore na upite o IP adresama, koje mu upućuju druge aplikacije. Da bi sustav DNS servera sadržavao i nalazio odgovore na takve zahtjeve (upite), potrebno je u taj sustav unositi takve sadržaje. Za svakog domaćina potrebno je uvrstiti na njegov mjerodavni DNS server odgovarajući zapis tipa A, koji sadrži njegovu tekstualnu i IP adresu.

Za svaku pod-domenu treba uvrstiti zapise tipa NS i tipa A na DNS server vršne razine, odnosno na odgovarajući DNS server razine iznad te pod-domene, ako ta vršna domena ima više razina pod-domena. U tom slučaju, na svakoj od tih pod-razina treba uvrstiti zapise tipa NS i tipa A na odgovarajuće DNS servere, na način da ti zapisi određuju put do mjerodavnog DNS servera za konkretnog (traženog) domaćina koji spada u neku od pod-domena najniže pod-razine te vršne

46

domene. Na taj način ti zapisi vode lokalne DNS servere (koji postavljaju upite) od vrha hijerarhije DNS servera prema dolje: prema onom mjerodavnom DNS serveru koji sadrži zapis o traženoj IP adresi, kako je to objašnjeno iznad i kako to ilustrira slika 3.12.

Unos podataka u DNS sustav i održavanje sadržaja toga sustava, izvodi se pomoću posebnih softverskih alata. Postoje tvrtke koje održavaju zapise u DNS sustavu za potrebe drugih tvrtki, na tržišnoj osnovi. Dakle, tvrtke održavaju podatke u DNS sustavu o domaćinima neke tvrtke, tako da taj sustav čini njihove domaćine (i njihove sadržaje) dostupne ostatku interneta.

Dani opis sustava DNS je više načelan nego potpun. Elementi računalne mreže su obično previše opsežni i tehnički složeni da bi se mogli detaljno opisati u jednom udžbeniku.

3.6 Aplikacije tipa P2P

Protokoli i sustavi aplikacijske razine, koje smo do sada opisali, oblikovani su i rade prema načelu klijent-server. Pritom je server stalno aktivan, dok se klijent uključuje (i šalje svoje zahtjeve) onda kada ima neku potrebu da to učini.

U sustavima aplikacijske razine koji rade prema načelu peer-to-peer (P2P), općenito nema postojanih uloga servera i klijenata. U takvim sustavima svi domaćini koji sudjeluju u nekom procesu su istovrsni (peer) i svaki od njih može pružati usluge drugima i dobivati usluge od drugih. U takvim sustavima, istovrsni domaćini izravno komuniciraju jedni s drugima, a veze između njih uspostavljaju se onda kad za to postoje konkretni razlozi.

Čvorove na kojima rade aplikacije nazvali smo završnim čvorovima mreže; pritom smo te čvorove načelno podijelili na klijentske i serverske. Serveri su obično veća završna računala, koja su vlasništvo davatelja Internet usluga (ISPa), dok osobna računala korisnika obično imaju ulogu klijenata. Istovrsna računala o kojima ovdje govorimo su obično osobna računala u vlasništvu korisnika; rad P2P aplikacija izvodi se većinom na takvim računalima.

U ovom odjeljku opisane su dvije aplikacije koje su prikladne za to da budu oblikovane prema načelu rada P2P. Prva od tih aplikacija izvodi distribuciju datoteka sa jednog računala (izvora) na velik broj istovrsnih računala. Primjer aplikacije takve vrste je sustav BitTorrent. Druga vrsta aplikacije tipa P2P je sustav distribuirane baze podataka, čiji je sadržaj smješten (razdijeljen) na grupi istovrsnih računala koja se nalaze u mreži. Primjer P2P aplikacije takve vrste je distribuirana hash tablica (distributed hash table - DHT).

Među istaknute mrežne aplikacije tipa P2P spada sustav Skype koji omogućava razne oblike telefonske i video komunikacije preko Interneta. Ta mrežna aplikacija nije ovdje opisana zbog ograničenosti prostora, kao i zbog toga što je ta aplikacija privatni (vlasnički, proprietary) proizvod, tako da pojedinosti o njenoj unutarnjoj strukturi i o njenim protokolima uglavnom nisu javno dostupne. Takve sustave se obično opisuje na razini funkcioniranja (rada); pritom se na temelju operativnog ponašanja sustava pokušava zaključiti kako bi mogli izgledati njegova unutarnja struktura i protokoli prema kojima taj sustav radi.

Distribuiranje datoteka

Uzmimo da treba prenijeti neku veliku datoteku sa jednog računala (izvora) na mnoga računala. Takva datoteka može biti neki film, nova verzija nekog softvera, ili neki drugi sadržaj. Ako distribuciju datoteka izvodi aplikacija koja radi po načelu klijent-server, onda server treba izravno poslati kopiju dane datoteke svakom računalu (kao klijentu) koje treba dobiti tu datoteku. Ako datoteku treba poslati na tisuće ili milijune računala, onda je to velik posao za server; takvim načinom distribuiranja datoteka ujedno se troši velik dio kapaciteta veza između tog servera i

47

ostatka računalne mreže.S druge strane, mrežni sustav (aplikacija) tipa P2P izvodi distribuciju (dostavu) datoteka na

velik broj računala na taj način da ona računala koja su primila datoteku ili neke njene dijelove, prenose drugim (istovrsnim) računalima to što su primila. Takvim načinom rada distribucija sadržaja izvodi se uz bitno manje opterećenje servera, odnosno onog čvora koji je izvor nekog sadržaja kojeg se distribuira. Proces distribucije (slanja) sadržaja izvode sva računala koja primaju sadržaje u tom procesu distribucije, tako da polazni izvor sadržaja nema posebno intenzivnu ulogu u tom procesu.

Neka vrijeme distribucije bude ono vrijeme koje je potrebno da se neka datoteka prenese (dostavi) na n računala u nekoj mreži. Vrijeme distribucije je općenito povoljnije (kraće) kad se distribucija izvodi prema P2P načelu, nego prema klijent-server načelu. Konkretna veličina tog vremena zavisi od više čimbenika, među koje spadaju: (1) propusnosti veza od servera prema mnoštvu klijenata, (2) uzlazna (upstream) i silazna (downstream) propusnost veza između istovrsnih računala (te propusnosti mogu se znatno razlikovati), i (3) broj istovrsnih računala na koje treba prenijeti neku datoteku.

Navedeni čimbenici (i neki drugi) zajedno određuju veličinu vremena koje je potrebno da se neku datoteku prenese na n računala u sustavu distribucije koji radi prema načelu klijent-server, kao i u sustavu koji radi prema načelu P2P. Ne zalazeći u pojedinosti načina izračunavanja vremena, za distribuciju neke datoteke sa servera na n klijenata u sustavu tipa klijent-server općenito je potrebno više vremena nego za izvršenje istog zadatka u sustavu koji radi prema načelu P2P. Nadalje, kod aplikacija tipa klijent-server, sa porastom broja računala n na koje se prenosi datoteka, linearno raste vrijeme koje je potrebno za izvršenje toga prijenosa. Kod aplikacija koje rade prema načelu P2P, sa porastom broja računala n raste i vrijeme distribucije, ali (znatno) sporije nego što raste broj računala. Naprimjer, kod sustava tipa klijent-server, za prijenos neke datoteke na tisuću računala treba deset puta više vremena nego za prijenos iste datoteke na sto računala. Kod sustava tipa P2P, u ovakvoj situaciji porast vremena je znatno manji nego kod sustava koji radi prema načelu klijent-server. Opisani odnos rasta vremena ilustrira graf sa slike 3.13.

48

Slika 3.13 Vrijeme distribucije kod klijent-server i P2P sustava

Ravna linija (pravac) na slici 3.13 pokazuje linearni rast vremena prijenosa u zavisnosti od broja računala (klijenata) kojima se prenosi neku datoteku sa aplikacijom tipa klijent-server. Druga (donja) linija na istom grafu pokazuje rast vremena distribucije u zavisnosti od broja računala kod aplikacija za distribuciju datoteka koje rade prema načelu P2P. Sa porastom broja računala, raste i vrijeme distribucije, ali kod aplikacija tipa P2P taj porast je općenito sporiji nego kod aplikacija tipa klijent-server. Posebno je važno da kod P2P aplikacija, intenzitet rasta potrošnje vremena opada sa porastom broja računala kojima se dostavlja datoteku. Dakle, s porastom broja računala, raste i vrijeme, ali ovdje vrijeme ne raste linearno, nego sve sporije.

BitTorrent je jedan protokol (i aplikacija) tipa P2P, koji definira jedan način distribuiranja datoteka između istovrsnih računala. Skup računala koja sudjeluju u jednom procesu distribucije sadržaja (datoteke), naziva se jednom bujicom (torrent). Pojam "torrent" može se prevesti i sa "izljev" (što bolje opisuje dani proces), ali "bujica" zvuči ljepše.

Računala u jednoj bujici šalju komade (chunks) datoteke jedno drugom i dobivaju komade datoteke jedno od drugog. Ovdje se uzima da je ta datoteka velika, tako da tipična veličina jednog (njenog) komada iznosi 256 KB. Računala traže i dobivaju komade datoteke od drugih računala iz bujice; istodobno, računala šalju one komade datoteke koje ona imaju, drugim računalima koja te komade nemaju. Postupajući na taj način, svako računalo iz bujice trebalo bi (s vremenom) dobiti sav sadržaj datoteke. Računalo koje je dobilo cijelu datoteku može napustiti bujicu, ali može i ostati u bujici i nastaviti slati komade datoteke onim računalima koja još nemaju te komade. Računalo može napustiti bujicu i prije nego što je dobilo cijelu datoteku; kasnije se može ponovno uključiti u tu bujicu i dobiti ostatak datoteke. Slika 3.14 prikazuje strukturu i tokove podataka u jednoj bujici.

49

Slika 3.14 Jedna bujica kod P2P sustava

Opišimo ukratko na koji način radi BitTorrent protokol (i aplikacija). Za svaku bujicu postoji jedan čvor koji čini osnovu bujice; taj čvor nazvali smo tragašem (tracker = onaj koji ostavlja ili prati trag). Računalo se uključuje u bujicu na taj način da se registrira kod tragaša; nakon toga računalo povremeno obavještava tragaša da je i dalje uključeno u bujicu. Jedna bujica može sadržavati manje od deset, ali i više od tisuću računala; broj računala u bujici se mijenja jer bujici pristupaju nova računala, a neka računala je napuštaju.

Slika 3.14 prikazuje jednu bujicu računala; uzmimo da se Mara upravo registrirala na tragašu te bujice i time se uključila u tu bujicu. Kad se Mara uključila u bujicu, tragaš je nasumce uzeo nekoliko IP adresa računala (naprimjer 50) koja su uključena u tu bujicu i poslao Mari taj skup IP adresa. Mara pokušava uspostaviti (paralelno) TCP veze sa računalima čije IP adrese joj je dostavio tragaš, ali obično ne uspijeva uspostaviti veze sa svim tim računalima; ona računala s kojima je Mara uspjela uspostaviti TCP vezu postala su njena susjedna istovrsna računala (neighbouring peer) u toj bujici. Na slici 3.14, Mara ima četiri susjedna računala; u praksi bi ih obično imala znatno više. Takva susjedstva su promjenljiva; neka računala mogu prekinuti neku TCP vezu, ili izaći iz bujice; neka druga računala mogu uspostaviti TCP vezu sa Marinim računalom i tako postati susjedima njenog računala.

U svakom trenutku, svako računalo u bujici, ima (primilo je) jedan skup komada (dijelova) datoteke koju se u toj bujici distribuira. Različita računala općenito imaju (skupila su) različite dijelove datoteke koju se distribuira. Mara povremeno pita svakog od svojih susjeda da joj dostavi listu onih komada datoteke koje on ima. Podsjetimo, Marini susjedi su ona računala s kojima je Mara ranije uspostavila TCP vezu (koja traje), kao i ona računala koja su uspostavila TCP vezu sa Marinim računalom. Marini susjedi čine isto: dakle, pitaju Maru da im dostavi listu onih

50

dijelova datoteke koje ona ima.Liste koje je Mara dobila od susjeda pokazuju joj koje dijelove izvorne datoteke može

tražiti od kojeg susjeda. Te liste općenito nisu jednake, ali se djelomično preklapaju. Na temelju usporedbe dobivenih listi, Marino računalo zatražiti će od susjeda onaj dio datoteke kojeg Mara nema i koji je najmanje prisutan na listama koje je Mara dobila od svojih susjeda. Mara će zatražiti taj dio od nekog od susjeda koji taj dio imaju. Takvim načinom biranja dijela datoteke kojeg računalo traži od svojih susjeda, potiče se širenje (u danom susjedstvu) onih dijelova datoteke koji su (u tom susjedstvu) prisutni u najmanjoj mjeri - to jest, na minimalnom broju računala. Takvo načelo biranja (traženja) dijelova naziva se prvo najrjeđi (rarest first). Primjenom toga načela postiže se ravnomjerno širenje svih dijelova datoteke koju se distribuira.

Protokol BitTorrent sadrži više zanimljivih načela sa kojima nastoji optimizirati rad sustava i poticati članove bujice da šalju sadržaje drugima, a ne samo da traže sadržaje od drugih, jer bez slanja, sustav ne bi funkcionirao. Pogledajmo neka od takvih načela. Prije svega, svako računalo odgovara na upite onih susjeda koji njemu najviše šalju, odnosno koji najviše odgovaraju na njegove upite. Svako računalo vodi evidenciju o tome kojim intenzitetom dobiva komade datoteke od svakog pojedinog susjeda. Na temelju toga računalo bira nekoliko susjeda od kojih dobiva dijelove datoteke najvećim intenzitetom; dakle, nekoliko susjeda koji su njemu najkorisniji. Računalo uzvraća tim susjedima susjeda na taj način što im šalje one dijelove datoteke koje oni traže od njega; računalo ima liste dijelova koje posjeduju pojedini susjedi, tako da može i samoinicijativno slati odabranim susjednima ono što to računalo ima a oni nemaju.

Računalo izračunava intenzitet kojim prima dijelove datoteke od susjeda, svakih 10 sekundi; na temelju toga, računalo može mijenjati listu "najboljih susjeda", na čije upite odgovara i kojima šalje dijelove datoteke. Podsjetimo, računalo ima mnogo (više desetaka) susjeda s kojima ima uspostavljenu TCP vezu; od tih susjeda, računalo ima stalnu razmjenu dijelova datoteke sa nekoliko odabranih (najboljih) susjeda. Za odabrane susjede (s kojima računalo ostvaruje razmjenu) kaže se da su odgušeni (ili otvoreni, unchoked); ostali susjedi (s kojima računalo ima uspostavljene TCP veze) su prigušeni (ili zatvoreni, choked). Izraz "prigušeni" izgleda dobro, ali "odgušeni" ne zvuči naročito lijepo.

Svakih 30 sekundi računalo pokušava ispitati ima li u susjedstvu netko tko bi mogao postati jednim od njegovih najboljih susjeda. Opis protokola koji nam je pri ruci nije sasvim precizan, ali je osnovno načelo jasno i otvara brojne mogućnosti. Dakle, svakih 30 sekundi računalo bira nasumce jednog od prigušenih susjeda (s kojim ima uspostavljenu TCP vezu) i šalje mu jedan ili više svojih dijelova datoteke. Računalo može slati neki dio kojeg je taj susjed ranije tražio, ili neki dio za kojeg vidi da susjedu nedostaje; što susjedu nedostaje vidi se prema listi njegovih dijelova, koje susjedi povremeno razmjenjuju. Samom međusobnom razmjenom listi dijelova koje imaju, susjedi ne zahtijevaju od drugih da im pošalju to što im nedostaje, ali daju im priliku da to učine.

Ovdje postoji niz mogućnosti. Mara šalje nekoliko dijelova datoteke jednom prigušenom susjedu (Juri) koji ne spada među njena četiri odabrana susjeda; kažemo da je Mara time pokusno odgušila (unchoked) komunikaciju sa susjedom Jurom (s kojima ima otvorenu TCP vezu). Slanjem većeg broja dijelova datoteke Juri, Mara može postati jednom od Jurinih odabranih susjeda; tada će Jure početi slati Mari svoje dijelove datoteke, prema načelu da svatko šalje onome tko njemu šalje (najviše). Svojim slanjem, Jure može postati jednim od četiri Marina odabrana susjeda, s kojima Mara intenzivno razmjenjuje dijelove datoteke. Dakle, Marino pokusno odgušenje veze prema jednom prigušenom susjedu (Juri) dovelo je do toga da taj susjed postane jednim od njenih odabranih susjeda; to ujedno znači da je jedan od četiriju prethodno odabranih susjeda morao otpasti (biti prigušen).

Rekli smo da ovdje postoji niz mogućnosti; spomenimo jednu od njih, bez obzira da li je u protokolu i aplikaciji BitTorrent realizirana na ovaj način ili nije. Uzmimo da Mari nedostaje jedan dio datoteke, kojeg ima Pero; Mara to vidi kod povremene razmjene listi dijelova (koje imaju) sa

51

susjedima. Mara upućuje zahtjev Peri da joj dostavi dio koji joj nedostaje; ali ako Mara ne spada među njegove odabrane susjede, onda Pero ne mora (neće) odgovoriti na njen zahtjev. Mara ga može navesti da to učini, tako da mu pošalje više dijelova (koje Pero nema) i da se time uvrsti među Perine najbolje pošiljatelje (odabrane susjeda); tada će Pero (prema temeljnom načelu biranja komunikatora) morati odgovoriti na Marin zahtjev.

Iznijeto temeljno načelo biranja komunikatora - "slati onima koji najviše šalju" - potiče komunikaciju među onim računalima koja su si međusobno najviše zanimljiva po sadržajima i po mogućnostima slanja. Jer ako računalo A šalje intenzivno računalu B, ali B ne šalje intenzivno računalu A, onda B može (ili mora) uvrstiti A među svoje odabrane susjede, ali A neće uvrstiti B među svoje odabrane susjede. I tako će komunikacija između njih prestati.

Svako računalo aktivno razmjenjuje dijelove datoteka sa nekoliko susjeda i povremeno pokušava ispitati komunikaciju sa jednim novim susjedom. TCP veze prema ostalim susjedima su tada prigušene. Prigušenost veza je privremena i jednosmjerna. Računalo A može uvijek odgušiti svoju prigušenu vezu prema računalu B; isto tako, dok je veza od A prema B prigušena, veza od B prema A može biti odgušena i B može slati dijelove datoteke računalu A.

Kaže se da je protokol i sustav aplikacijske razine računalne mreže zvan BitTorrent, kojeg smo ovdje ukratko opisali, vrlo uspješan u praksi. Kaže se da milijuni istovrsnih računala, koja su povezana u stotine tisuća bujica, stalno razmjenjuju (distribuiraju) bezbrojne datoteke raznih sadržaja. Kaže se da je glavni razlog za uspješnost tog protokola (i aplikacije) taj, što korisnike (računala) primorava da šalju, ako žele primati, na način kako smo to opisali iznad. Ono računalo koje ne šalje drugima, druga računala neće uvrstiti među svoje odabrane susjede, tako da tom računalu nitko neće slati (osim povremeno, kod traženja novog odabranog susjeda). Onaj tko se uključi u neku bujicu, treba pridonositi njenom funkcioniranju; inače neće imati puno koristi od tog uključenja.

Distribuirane hash tablice (DHT)

Sadržaj distribuirane baze podataka zapisuje se na više međusobno povezanih računala. Kod sustava takve strukture, valja riješiti dva osnovna pitanja: (1) kamo (na koje računalo) se zapisuje neki podatak, i (2) gdje (na kojem računalu) treba tražiti neki podatak. U ovom odjeljku iznosimo načela rada distribuirane baze podataka čiji je sadržaj zapisan na većem broju istovrsnih računala koja su međusobno povezana u mrežu.

Podaci koje zapisujemo u distribuiranu bazu podataka kakvu ovdje opisujemo su općenito oblika < ključ, vrijednost >. Zapisi takvog oblika mogu sadržavati sadržaje raznih vrsta; to mogu biti (1) osobni identifikacijski broj (ključ) i niz podataka o osobi (vrijednost), (2) naziv nekog filma ili glazbe (ključ) i fizička adresa na kojoj se nalazi digitalni zapis toga filma ili glazbe (vrijednost) te niz drugih parova takve vrste.

Podaci se unose (upisuju) u takvu bazu podataka kao parovi oblika < ključ, vrijednost >; podaci iz takve baze dobivaju se na taj način da se sustavu za upravljanje bazom zada ključ, za kojeg onda taj sustav vraća pripadnu vrijednost. Izrada baze podataka koja radi prema načelu klijent-server, je relativno jednostavna: baza je smještena na serveru, koji izvodi sve operacije s njom; server to čini na zahtjeve klijenata. Problem održavanja i korištenja baze postaje složeniji kad je sadržaj baze podataka distribuiran na više istovrsnih računala, pri čemu nijedno od tih računala nema tako dominantnu ulogu kao server; računala općenito ne znaju ni adrese svih ostalih računala na kojima se nalaze sadržaji dane baze.

U nastavku iznosimo načela prema kojima se može napraviti distribuiranu bazu podataka. Svakom računalu na kojem se nalaze dijelovi distribuirane baze podataka dodijelimo jedinstvenu numeričku oznaku; neka to bude cijeli broj u rasponu od 0 do 2n-1, za neki odabrani n. Raspon je

52

zadan na takav način zato što se brojevi iz tog raspona mogu zapisati u binarnom obliku sa n bitova; naprimjer, za n = 5, binarni zapis donje granice raspona glasi 00000, a gornje granice 11111 - to je dekadski broj 31, što je jednako 25-1.

Ključevi (identifikatori) podataka (zapisa) u bazi ne moraju biti brojevi, nego mogu biti alfanumerički (tekstualni) nizovi znakova: naprimjer, šifra, ime, ili naziv. Funkcija heširanja (hash function) je funkcija (proces, algoritam) koja preslikava zapise iz jedne domene u zapise iz druge (manje) domene. Neka ovdje hash funkcija preslikava ključ zapisa na numeričku vrijednost u rasponu od 0 do 2n-1. Hash funkcija može biti definirana na razne načine; naprimjer, ta funkcija može čitati binarni zapis ključa kao jedan broj i onda taj broj dijeliti sa 2n; tada će ostatak kod dijeljenja biti broj u rasponu od 0 do 2n-1.

Pojam "to hash" ima više značenja; jedno od njih je "isjeckati"; dakle, ta funkcija "sjecka" dani ulaz (na zadani način) i tako proizvodi izlaz (rezultat). Nije nam poznat dobar prijevod za naziv "hash funkcija"; zato ćemo ovdje koristiti taj naziv.

Kod distribuirane baze podataka treba odrediti načelo prema kojem sustav odlučuje na koje će računalo zapisati pojedini podatak, odnosno na kojem računalu će tražiti neki podatak u distribuiranoj bazi čiji su sadržaji zapisani na više računala. Računalima smo dodijelili jedinstvene oznake u rasponu od 0 do 2n-1; uzmimo ovdje da hash funkcija preslikava ključeve zapisa podataka na numeričke vrijednosti iz toga raspona. Sada možemo usvojiti načelo da se podatak zapisuje na ono računalo čija je numerička oznaka jednaka ili prva veća od vrijednosti hasha od ključa danog podatka. Tu definiciju dopuniti ćemo u nastavku.

Hash funkcija koja se koristi u distribuiranoj bazi podataka radi na svim računalima na kojima se nalaze dijelovi dane distribuirane baze podataka. To omogućava svakom od tih računala da preslikava zapise ključeva na hash vrijednosti tih ključeva. Time računala utvrđuju na koje od računala treba zapisati dani zapis (podatak), odnosno na kojem od računala treba tražiti zapis (podatak) za dani ključ. Takvu distribuiranu bazu podataka, koja dijeli sadržaje (na računala) prema hash vrijednostima ključeva zapisa, naziva se distribuiranom hash tablicom (distributed hash table - DHT). Ovdje govorimo o bazi podataka, ali baza je skup tablica koje su međusobno povezane; jednu tablicu se isto tako može smatrati bazom podataka.

Pogledajmo primjer; uzmimo da je n = 5; to znači da se oznake računala mogu kretati u rasponu od 0 do 31 (kako je to objašnjeno iznad). Uzmimo da je u podmrežu na čija se računala zapisuje sadržaje neke distribuirane baze trenutno uključeno devet računala, koja nose oznake 3, 7, 8, 12, 14, 21, 23, 29, 30. Nadalje, uzmimo da hash od ključa podatka kojeg treba upisati u danu bazu glasi 22. Prema gornjem načelu, taj zapis oblika <ključ, vrijednost > treba zapisati na računalo koje nosi oznaku 23.

Dani opis treba dopuniti slijedećim načelom: podatak kod kojeg je hash od ključa veći od oznake svih računala koja su trenutno uključena u dani sustav, zapisuje se na računalo čija je oznaka najmanja. Dakle, numeričke oznake uređuju računala u kružnicu: nakon računala sa numerički najvećom oznakom (2n-1; ovdje 31) slijedi računalo sa numerički najnižom oznakom (0). U danom primjeru, podatak za kojeg hash ključa glasi 31 bio bi zapisan na računalo 3, jer računalo 31 nije uključeno u sustav, kao ni računalo 0 koje mu izravno slijedi; tako prvo slijedeće računalo nakon 30 postaje računalo 3.

53

Slika 3.15 Povezivanje čvorova kod aplikacije DHT

Sad treba odrediti na koji način se traži (fizički) računalo za danu oznaku, odnosno za danu vrijednost hasha od ključa podatka koji je zapisan na tom računalu, ili kojeg treba zapisati na to računalo. Na slici 3.15 pokazane su dvije mogućnosti povezivanja računala, koje omogućuju nalaženje traženog računala. To su dvije mogućnosti uspostave logičkih veza među računalima; definiranjem takvih veza uspostavlja se neko uređenje na skupu računala na kojima su zapisani podaci iz neke distribuirane baze podataka. Na slici 3.15a, računala su uređena u usmjerenu kružnicu; to se može napraviti na taj način da svako računalo zna oznaku (i IP adresu) "slijedećeg" računala u toj kružnici. Slika 3.15b pokazuje logičku strukturu koja nastaje kad računala znaju oznake (i IP adrese) više drugih računala; takva dodatna znanja omogućuju brže nalaženje traženog računala, ali zahtijevaju i dodatne procese održavanja takvog sustava.

Pogledajmo prvo jednostavniju varijantu. Uzmimo da korisnik računala 7 želi upisati u distribuiranu bazu podatak oblika < ključ, vrijednost >, pri čemu hash od ključa iznosi 22. Prema načelu koje smo odredili iznad, taj podatak treba zapisati na ono računalo čija je oznaka jednaka ili prva veća od vrijednosti 22. Na temelju tog načela, računalo 7 prosljeđuje zahtjev za upis podatka računalu 8, kao "svom slijedećem"; računala 8, 12, 14 i 21 postupaju na isti način, tako da zahtjev za upis danog podatka stiže na računalo 23. To računalo zna da je njegova oznaka veća od 22; s obzirom da je taj podatak stigao do njega, to znači da oznaka prethodnog čvora (u usmjerenoj kružnici) nije bila jednaka ili veća od 22. Dakle, računalo 23 zaključuje da dani podatak pripada njemu i da treba biti zapisan na to računalo.

Postoji više mogućnosti realizacije opisanog procesa (protokola). Ako se kružnicom kreću ključ i vrijednost (sadržaj) koje treba upisati, onda računalo 23 može izvršiti traženi upis podatka u distribuiranu tablicu i obavijestiti o tome izvornog pošiljatelja toga zahtjeva, računalo 7. Ako se kružnicom kreće samo upit o tome na koju adresu treba poslati (za upis) dani podatak, onda računalo 23 može poslati izravnu poruku računalu 7 da mu dostavi taj podatak (na njegovu IP adresu), tako da ga računalo 23 može upisati u distribuiranu bazu podataka.

Konačno, ako računalo 7 traži sadržaj zapisa (podatak), onda će taj zahtjev računala 7 stići do računala 23, prema načelu kretanja koje smo iznijeli iznad. Po primitku toga zahtjeva, računalo 23 izračunava (nalazi) odgovor na primljeni zahtjev (iz baze zapisa koje to računalo sadrži) i šalje taj odgovor tražitelju, računalu 7.

Za uspostavu logičke strukture "usmjerene kružnice" na nekom skupu računala koja su

54

fizički vezana u neku računalnu mrežu, dovoljno je za svako računalo iz toga skupa odrediti njegovog "slijedećeg". Svako računalo može znati i svog prethodnika, jer od njega izravno prima poruke, ali to znanje nije neophodno za uspostavu strukture usmjerene kružnice.

Kružnica je jednostavna struktura i jednostavno ju je održavati; računala ne trebaju znati ništa osim IP adrese svog "slijedećeg računala" u toj kružnici. Ali ako su sadržaji neke distribuirane baze zapisani na velikom broju računala, onda kružnica u koju su uređena ta računala sadrži mnogo računala. To znači da za nalaženje traženog računala treba (u prosjeku) postaviti velik broj upita, što je nepovoljno. Ako se krug sastoji od m računala, onda je za nalaženje traženog računala potrebno u prosjeku uputiti m/2 upita "slijedećem računalu" da bi upit stigao kružnicom do traženog računala.

Slika 3.15b pokazuje na koji način se može nadopuniti strukturu kružnice sa ciljem da se smanji broj upita (koraka) koji su potrebni da se stigne do traženog računala. Ovdje računala ne sadrže samo oznaku i IP adresu svog slijedećeg računala, nego usto sadrže oznake i IP adrese od još nekoliko računala iz kružnice. To čvorovima omogućava da skrate put do traženog računala, umjesto da zahtjeve prosljeđuju samo u krug.

Postoje razne mogućnosti da se računalima daju liste adresa drugih računala iz kružnice, čime se stvaraju "prečice" u kretanju krugom; postoje i razne mogućnosti (metode) korištenja tih prečica. Prema slici 3.15b, računalo 7 ima adrese računala 8 kao slijedećeg, te adrese računala 14 i 29, koje mu omogućuju da koristi prečice u danoj kružnici.

Kad računalo 7 traži podatak (za dani ključ), onda izračunava hash toga ključa i utvrđuje na kojem računalu (ili nekom kasnijem) bi taj podatak trebao biti zapisan. Kad utvrdi da je traženi podatak zapisan na računalu 22 (ili kasnijem), onda svoj upit ne šalje susjednom računalu 8, nego prečicom računalu 14. Slanjem zahtjeva računalu 14, računalo 7 zna da nije "prebacilo" traženo računalo, jer traži se ono računalo čija je oznaka 22 ili prva veća. Računalo 7 ne šalje upit izravno (prečicom) računalu 29 jer bi time moglo prebaciti traženo računalo (što bi se u ovom primjeru i dogodilo). Računalo 7 nema podataka o računalu 23 i ne zna da to računalo postoji, ali zna da računalo s tom oznakom može postojati, kao što mogu postojati druga računala sa oznakama većim od 14 i manjim od 29. Zato računalo šalje svoj upit najdalje što može, ali ne na ona računala čije oznake su veće od hasha danog ključa, jer tu postoji opasnost da se prebaci cilj.

Na isti način koriste prečice druga računala u osnovnoj kružnici, koja primaju zahtjeve koji ne pripadaju njima, i koje trebaju proslijediti dalje. Naprimjer, da računalo 7 nema prečicu do 14 i da je dani zahtjev (za računalo 22) uputilo svom slijedećem računalu (8), onda bi računalo 8 upotrijebilo svoju prečicu i proslijedilo taj zahtjev računalu 21, koje bi ga onda proslijedilo računalu 23.

Dani opis pokazuje na koji način se određuje računalo na koje treba zapisati neki podatak, odnosno računalo na kojem treba tražiti neki podatak. Hash od ključa je broj (oznaka) od računala. U izvorima koje smo koristili to nije eksplicitno rečeno, ali dani distribuirani sustav radi sa tri veličine: ključ, hash ključa, i vrijednost (sadržaj, podatak). Ključ jednoznačno identificira jednu vrijednost (podatak); hash od ključa određuje na kojem računalu se tu vrijednost zapisuje, i gdje je treba tražiti; vrijednost je podatak (sadržaj) kojeg se zapisuje i traži.

Opisali smo osnovna načela rada sustava (protokola) distribuirane hash tablice; taj sustav (mrežna aplikacija) je tipa P2P jer su računala koja ostvaruju njegovo funkcioniranje istovrsna. Za potpun opis toga sustava trebalo bi iznijeti još niz stvari, što ovdje ne možemo učiniti. Sustav dopušta da se u njega uključe nova računala, i da se računala isključe iz njega. Takve promjene zahtijevaju da neka računala iz sustava distribuirane baze promijene svoje zapise o svom slijedećem računalu. Treba odrediti i što treba učiniti s podacima koji su zapisani na računalu koje se isključilo iz sustava, tko vodi računa o uključivanju i isključivanju računala, i niz drugih stvari. S tim pitanjima ne možemo se ovdje baviti, ali protokoli trebaju točno opisati svaku od situacija u kojoj se sustav može naći, kao i moguće postupke sustava u toj situaciji.

55

+

56