UVOD

Raunari su u dananje vreme ureaji koje sreemo na svakom koraku u ivotu

oveka: u birou, u bankama, kolama, industrijama i na mnogim drugim mestima. ivot je
danas postao nezamisliv bez njih. Meutim, pored tih osnovnih funkcija, u svetu i okruenju
koji je postao zavistan od stalne komunikacije, javila se dodatna potreba da se informacije
razmenjuju sa drugim raunarima. Razmena podataka se definie kao proces pouzdanog
slanja podataka izmeu dva ili veeg broja uesnika u komunikaciji, u kome se kao
neizostavni uesnici javljaju pre svega poiljalac, primalac, medijum kao i poruka iji se
prenos obavlja.Na ovaj nain mogu se razmenjivati podaci raznorodnih oblika i formi, i
najee su to raunarski fajlovi (datoteke), digitalizirani signali slike, merni rezultati sa
udaljenih postrojenja, centralne baze za nadgledanje i upravljanje sloenim procesima u
industriji i slino. Od kljunog znaaja za ovakav vid komunikacije je da poruke i podaci
stignu do primaoca u nepromenjenom stanju, istom redosledu i najbrem moguem roku. U
ovom radu bie rei upravo o protokolima, interfejsima i drugim iniocima koji omoguavaju
uspenu razmenu podataka izmeu dva ili vie korisnika na mrei.
 Internet predstavlja mreu vie desetina miliona raunara koji su
meusobno povezani na razliite naine. Svi ti raunari, korienjem TCP/IP
protokola meusobno komuniciraju. Internet svojim korisnicima nudi veliki broj usluga
- servisa. Najee korieni servisi su: e- mail, World Wide Web (WWW), FTP,
Newsgroups, Chat, servisi za pretraivanje. Svaki korisnik na Internetu ima svoje
jedinstveno korisniko ime (user name), korisniku adresu i lozinku (password).
Godine 1961. ministarstvo odbrane SAD, odnosno Agencija amerikog ministarstva
odbrane za napredna istraivanja (Advanced Research Projects Agency, ARPA) dala
je vodeim amerikim univerzitetima zadatak da smisle i naprave raunarski sistem,
koji je trebalo da povee amerike univerzitete, kao centre znanja i vladine ustanove,
kao centre odluivanja.
Ova potreba je dovela do razvoja mrenih tehnologija koje bi omoguile
komunikacju izmeu kompjuterskih sistema. Mogunosti mrenih sistema su toliko
napredovale, tako da su mree postale osnovni deo rastue kompjuterske industrije.
Razne firme, univerziteti i vlade su razvijale sopstvene naine komuniciranja u okviru
njihovih mrea, a to je dovelo do velikih problema pri povezivanju s ostalim
mreama. Pojavljuje se prvi metod koji omoguava razliitim mreama da
komuniciraju meusobno. Ovaj metod postaje poznat kao internetworking.
Internetworking je osim povezivanja razliitih mrea omoguio velikim mreama da
budu sastavljene od manjih, lokalnih mrea. Organizacija koja je prva razvijala
interenetworkig je bila ARPA(US Advanced Research Projects Agency). Jedna od
glavnih tehnologija koju je ARPA razvila u okviru internetworking je pocket-switching.
Packet-switched mrea alje podatke delei ih u male standardizovane jedinice koje
se zovu paketii (eng. Packets), od kojih svaka sadri deo kompletnog podatka koji
se alje, kao i adresu destinacije. (slika). ARPA je uspela da uz pomo packet-
switchinga povee univerzitete, vlade, istraivake centre u jednu veliku mreu
koja je dobila ime ARPANET. Kako je ARPANET postajala naprednija i mnogo vea,
ona je privukla panju ostalih agencija koje su radile na razvoju Internetworking
tehnologije.Ove agencije i ARPA poinju krajem 70-ih da rade na razvoju mrene
tehnolgije koja e kasnije biti poznata kao TCP/IP.

OSI SISTEM
Kako su se raunarske mree razmnoavale javljala se sve vea potreba za komuniciranjem
izmeu korisnika razliitih mrea. Istorijski posmatrano (60-tih godina prolog veka),
komunikacija izmeu grupe raunara bila je obino ograniena na razmenu podataka izmeu
uredjaja istog proizvoaa. Zbog toga je organizacija ISO formirala svoj OSI (Open System
Interconnection) referentni model koji bi reio problem meusobnog povezvanja razliitih
korisnika u sistemu. Ova ideja se zasniva na tome da, ukoliko vie sistema potuju odreene
standarde u komunikaciji, mogue je stvaranje i realizacija raunarskih mrea bez obzira na
izbor opreme, softvera i sistema.
Prema ISO/OSI referentnom modelu, svi slojevi u jednom protokolu mogu vriti dve
funkcije: Mreno zavisne i aplikaciono orijentisane funkcije. Dalje, ovaj model razlikuje tri
operativna sistema:

2
 mreno okruenje koje odnosi se na primenu protokola i standarda u cilju ostvarivanja
korektne razmene podataka;
OSI okruenje - sadri u sebi mreno okruenje, a ukljuuje i dodatne aplikaciono-
orijentisane protokole i standarde koji omoguavaju krajnjim korisnicima sistema da
komuniciraju bez ogranienja;
Okruenje realnih sistema koje sadri OSI okruenje a uzima u obzir i razliite
osobine proizvoaa softvera i servisa koji su razvijeni sa ciljem da bi se izvrio
odreeni zadatak.

Ovaj referentni sistem se sastoji iz 7 nivoa, od kojih su nivoi od prvog do treeg mreno-
zavisni, nivoi od petog do sedmog aplikaciono orijentisani, dok etvrti nivo predstavlja
interfejs izmeu aplikaciono orijentisanih i mreno zavisnih nivoa i obezbeuje uspeno
razmenjivanje poruka izmeu njih.

Kao to je ve reeno, ovaj model se sastoji iz 7 nivoa kroz koje se obavlja proces
komunikacije. To su sledei nivoi:
Fiziki sloj definie elektrine i mehanike karakteristike mrenog intefejsa, tj. zaduen je za
predaju bitova podataka po fizikom medijumu, a takodje i za mehanike, elektrine,
funkcionalne, i proceduralne karakteristike koje se odnose na pristup fizikom medijumu.
Sloj veze je zaduen za upravljanje vezom kod prenosa podataka, njeno uspostavljanje,
odravanje i raskidanje. Ovaj sloj treba da obezbedi pouzdan prenos informacije po fizikoj
vezi, predaju podataka sa potrebnom sinhronizacijom, kontrolu greaka i toka podataka.
Sloj mree upravlja rutiranjem u mrei, adresiranjem i ostvaruje uslove za nezavistan rad
viih nivoa modela u saglasnosti sa tehnologijama komunikacionih puteva koji se koriste.
Odgovoran je za uspostavljanje, odravanje, i raskidanje veze.

3
 Transportni sloj je zaduen za prenos poruka od-kraja-do-kraja (upravljanje vezom),
fragmenataciju poruka, upravljanje redoslednim tokom podataka kod prenosa. Obezbeuje da
se jedinice podataka prosleuju bez greaka, gubitka ili udvostruavanja i u pravom
redosledu.
Sloj sesije obezebeuje mehanizam za voenje dijaloga izmeu aplikacija i diktira nain na
koji e dva aplikaciona procesa da uspostave i koriste vezu koja se naziva sesija.
Sloj prezentacije se bavi sintaksom podataka koji se razmenjuju izmeu aplikacionih celina,
odnosno premouje razliku u formatu i reprezentaciji podataka. Prezentacioni sloj definie
sintaksu koja se koristi izmeu aplikacionih celina.
Aplikacioni sloj obavlja fajl-transfer, pristup i upravljanje razmenom poruka i dokumenata,
transfer poslova i manipulisanje, tj. aplikacije se sastoje od aplikacionih procesa koji
obavljaju procesiranje informacije.
Prenos podataka poinje time to aplikacioni proces predaje podatke koje eli poslati
aplikacionom nivou. Ovaj nivo dodaje tim podacima svoje zaglavlje i prosleuje ih
prezentacionom nivou. Prezentacioni nivo vri odreene modifikacije podataka i dodaje im
svoje zaglavlje, te tu novonastalu celinu prosleuje sloju sesije. Potrebno je naglasiti da
prezentacioni sloj ne razlikuje prvobitne podatke i zaglavlje aplikacionog sloja. Ovaj proces
se ponavlja dok se ne doe do fizikog sloja, a zatim se putem mree prenosi do prijemne
strane. Na prijemnoj strani podaci se kreu ka viim nivoima, odbacuju se pridodata
zagljavlja sve dok se ne stigne do aplikacionog nivoa. Ideja se zasniva na tome da svaki nivo
doda zaglavlje koje e prepoznati isti nivo na drugoj strani i omoguiti peer to peer
komunikaciju.

STA JE PROTOKOL
Kada raunari, terminali, i/ili drugi uredjaji namenjeni za obradu padataka ele da razmenjuju
podatke, procedure koje su sastavni deo ovog procesa mogu biti veoma sloene. Razmotrimo
na primer prenos fajlova izmedju dva raunara. Kao prvo, da bi prenos bio mogu, mora da
postoji fiziki put za prenos podataka izmedju oba raunara. Put moe biti izveden kao
direktni, ili da se prenos obavlja preko komunikacione mree. Ali pored tog hardverskog
zahteva, potrebno je da oba sistema poseduju i odgovarajue softvere koji e omoguiti
komunikaciju.
Da bi komunikacija izmeu dva ureaja bila mogua, neophodno je da oni rade na isti nain i
po istim standardima, odnosno da govore istim jezikom, ta nije sluaj sa razliitim
proizvoaima raunarske i komunikacijske opreme. Upravo iz tog razloga, organizacije za
standardizaciju poput ISO (International Organization for Standardization) dobile zadatak da
razviju nain na koji e povezivanje razliitih raunarskih sistema biti mogue. Tada su se
javili protokoli. Protokol predstavlja skup unapred odreenih pravila koja rukovode
razmenom podataka izmeu dve celine. Protokol moe biti napravljen kao hardver, softver ili
oba i neophodno je da obe strane uesnice u razmeni podataka koriste i podravaju isti
protokol.
Kljune karakteristike protokola jesu:
Sintaksa, koja se odnosi na format blokova podataka, kao i na kontrolu kodiranja i
nivoa signala;
Semantika, koja se tie se upravljake (kontrolne) informacije u ijoj je nadlenosti
koordinacija rada oba sistema, kao uesnika u razmeni podataka, kao i nainima
manipulisanja sa grekama koje se mogu javiti u toku prenosa.

4
 tajming ili vremenska sinhronizacija, koja se odnosi se na usklaivanje brzine
prenosa podataka kao i sekvenciranje poruka.
Zadaci koje protokol mora obaviti radi ostvarenja uspene razmene podataka
obuhvataju:
uspostavljanje i odravanje veze, kao i korienje istih puteva za vie veza;
odravanje korektne sinhronizacije izmeu poiljaoca i primaoca sa ciljem da se
izvri ispravna interpretacija poruka i sprei prenatrpavanje sporog primaoca od
strane brzog poiljaoca;
razmenu podataka imeu uesnika u komunikaciji po unapred definisanim
propisima;
kontrolisanje prijemnog signala kako bi se ustanovilo da li je dolo do greke u
prenosu signala ili poruka. U sluaju da se otkrije greka preduzimaju se
odgovarajue korektivne akcije;
adresiranje i usmeravanje poruka. Ove funkcije obezbeuju da se ostvari korektno
usmeravanje poruka kroz mreu i obavi uspeno povezivanje poiljaoca i primaoca;
formatiranje poruka. Informacija koja se prenosi neophodno je da se formatira i
kodira u pogodnoj formi.

TCP/IP PROTOKOL
1.3 TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol - Protokol za kontrolu prenosa/Internet protokol) je
referentni model koji se koristi na Internetu. Razvijen je pre OSI modela, tako da se slojevi ova dva modela ne
poklapaju u potpunosti. TCP/IP model ini pet slojeva: fiziki, sloj veze, mreni, transportni i aplikacioni.
TCP/IP se samo sporadino bavi najniim slojevima (fizikim i slojem veze). Zajedno, ova dva sloja se tretiraju
kao host-mrea sloj. TCP/IP ne namee neke posebne zahteve koji se tiu ovih slojeva (pretpostavlja se da
mrea poseduje protokole koji pokrivaju funkcije tih slojeva), a naglasak stavlja na sloj mree, transportni i
aplikacioni sloj. Mreni i transportni sloj odgovaraju slojevima 3 i 4 OSI modela. Meutim, kod TCP/IP na
transportni sloj direktno se nastavlja aplikacioni sloj, koji obuhvata funkcionalnost tri vrna sloja OSI modela
(Sl. 1-4).

TCP/IP je hijerarhijski skup protokola sainjen od interaktivnih, ali ne obavezno i meusobno nezavisnih
modula od kojih svaki ostvaruje neku specifinu funkciju. Za razliku od OSI modela koji definie koje funkcije
pripadaju kom sloju, slojevi TCP/IP modela sadre relativno nezavisne protokole koji se mogu kombinovati
zavisno od potreba sistema. Pojam hijerarhijski znai da je svaki protokol vieg nivoa podran od strane jednog
ili vie protokola nieg nivoa. Na Sl. 1-5 je prikazana struktura TCP/IP modela sa protokolima razvrstanim u
slojeve koji su preklopljeni sa odgovarajuim slojevima OSI modela.

Mreni (Internet) sloj

Glavni protokol na mrenom nivou je IP (Internet Protocol). Pored IP, sloj mree sadri jo nekoliko pomonih
protokola (ARP, RARP, ICMP, IGMP i dr.). Internet sloj je odgovoran za isporuku paketa od hosta do hosta na
Internetu. Glavna briga ovog sloja je rutiranje paketa i izbegavanje zaguenja (odgovara mrenom sloju OSI
modela).

5
Transportni sloj
Na transportnom nivou, TCP/IP definie dva protokola: TCP i UDP (User Datagram Protocol). TCP je
transportni protokol konekcionog tipa koji omoguava uspostavljanje pouzdanog toka bajtova izmeu dve
udaljene aplikacije. TCP obavlja segmentaciju toka bajtova na poruke koje prosleuje internet sloju. Na strani
odredita, TCP rekonstruie tok bajtova i prosleuje ga aplikaciji. Uz to, TCP se bavi kontrolom protoka kako bi
spreio da brzi predajnik pretrpa porukama sporog prijemnika koje on ne moe da obradi.
UDP je jednostavan, nepouzdan, beskonekcioni transportni protokol za aplikacije koje ne zahtevaju strogu
kontrolu greaka i redosleda pristizanja paketa. Radi se o aplikacijama kao to su one koje prenose audio i video,
kod kojih je brza isporuka paketa vanija od precizne isporuke.
Aplikacioni sloj
TCP/IP model ne predvia prezentacioni i sloj sesije, ve su funkcije ovih slojeva pripojene aplikacionom sloju.
To znai da aplikacije moraju samostalno da realizuju funkcije koje se odnose na sesiju i prezentaciju podataka,
ako su im takve funkcije uopte potrebne. Aplikacioni sloj sadri vei broj protokola visokog nivoa. Prvobitno
su razvijeni protokoli: TELNET (virtuelni terminal), FTP (File Transfer Protocol) - protokol za prenos fajlova i
SMTP (Simple Mail Transfer Protocol) - protokol za prenos elektronske pote. Vremenom, aplikacioni sloj je
proiren brojnim protokolima, od kojih su najznaajniji: DNS (Domain Name System) - za preslikavanje imena
hostova u njihove mrene adrese i HTTP - za pribavljanje strana na Web-u.
2 Internet sloj
U ovom poglavlju baviemo se Internet slojem TCP/IP arhitekture. Internet je heterogena globalna mrea
sainjena od ogroman broj nezavisnih mrea, razliitih tipova, meusobno povezanih ruterima. Na nivou
pojedinanih mrea koriste se razliiti prenosni medijumi i razliiti komunikacioni protokoli fizikog i sloja
veze. Zadatak Internet sloja je da unificira sve te razlike i omogui komunikaciju izmeu krajnih sistema, bilo da
su oni prikljueni na istu ili razliite mree. Problemi koji se reavaju na Internet sloju u su vezi sa: logikim
adresiranjem, rutiranjem datagrama, fragmentacijom datagrama i u izvesnoj meri sa kontrolom zaguenja i
obezbeivanjem zahtevanog nivoa kvaliteta servisa. Za jedinstvenu identifikaciju sistema prikljuenih na
Internet (hostova i rutera) koriste se tzv. Internet (IP) adrese. Na Internetu se koristi paketski prenos. Na strani
izvora informacija deli na manje jedinice, tzv. datagrame koji se nezavisno prenose od rutera do rutera sve do
krajnjeg odredita. Rutiranjem datagrama od izvornog do odredinog hosta bavi se IP protokol. IP se
prevashodno izvrava u ruterima. Funkcija rutera je da svaki primljeni datagram, a shodno njegovoj odredinoj
IP adresi, usmeri dalje ka sledeem ruteru ili odredinom hostu. U izvesnim situacijama, ruter mora da podeli
datagram na vie manjih datagrama, tzv. fragmenata. Fragmenti nastavljaju put kao nezavisne jedinice, da bi se
na odredinom hostu objedinili u prvobitni datagram. Pravila za fragmentaciju i defragmentaciju datagrama su,
takoe, definisana IP protokolom. Pored IP protokola, Internet sloj TCP/IP steka sadri jo nekoliko pomonih
protokola manje sloenosti, a dva takva protokola su: ARP i ICMP. IP koristi ARP protokol za preslikavanje IP
adresa na fizike adrese koje vae u konkretnoj fizikoj mrei. ICMP protokol obezbeuje povratne informacije
izvornom hostu o eventualnim problemima nastalim u rutiranju datagrama.
2.1 IP adresiranje
Mogunost globalne komunikacije izmeu svih povezanih ureaja predstavlja jednu od glavnih karakteristika
Interneta. Pretpostavka globalne komunikacije je postojanje univerzalne eme adresiranja koja se koristi za
jedinstvenu identifikaciju svakog prikljuenog ureaja. (Identian zahtev postoji i u telefoniji, gde svaki
pretplatnik poseduje jedinstveni telefonski broj u kombinaciji sa pozivnim brojem drave i pozivnim brojem
grada). Identifikator koji se koristi na IP sloju TCP/IP protokol steka naziva se IP adresom.
Internet ili IP adresa je 32-bitna (ili 4-bajtna) adresa (identifikator) koja na jedinstven i univerzalan nain
definie vezu hosta ili rutera na Internet. IP adrese su jedinstvene u smislu da svaka adresa definie jednu i samo
jednu vezu (prikljuak) na Internet. Dva ureaja na Internetu nikada ne mogu imati istu IP adresu. Meutim, ako
ureaj (najee ruter) poseduje dve Internet veze, preko dve razliite mree, onda e on imati i dve IP adrese. IP
adrese su univerzalne u smislu da svaki host koji eli da se povee na Internet mora potovati opte usvojeni
sistem IP adresiranja.
Adresni prostor
Protokol kao to je IP, koji se oslanja na adrese, pokriva odreeni adresni prostor. Adresni prostor ine sve
adrese koje protokol moe koristiti. Ako protokol predvia N bita za predstavljanje adresa, tada je veliina
adresnog prostora 2N. IP protokol u verziji IPv4 koristi 32-bitne adrese, to znai da je njegov adresni prostor
veliine 232, odnosno 4.294.967.296. To znai da kada ne bi postojala dodatna ogranienja, na Internet bi moglo
da se prikljui vie od 4 milijarde ureaja. Naalost, stvaran broj raspoloivih adresa je mnogo manji.
Notacija
Za zapisivanje Internet adresa obino se koristi takasta decimalna notacija. U ovom formatu, svaki od etiri
bajta adrese se zapisuje kao decimalni broj, od 0 do 255. Najnia IP adresa je 0.0.0.0 (sve 0), a najvia
255.255.255.255 (sve jedinice). Sl. 2-1 prikazuje bit oblik i decimalni format jedne konkretne IP adrese.

6
 Sl. 2-1 Takasta decimalna notacija.

2.1.1 Klasno IP adresiranje

Kada je pre nekoliko decenija uvedeno IP adresiranje korien je koncept klasa, odnosno ema klasnog IP
adresiranja. Sredinom 90-tih godina prolog veka, uvedena je nova ema, tzv. besklasno adresiranje, koja je
vremenom gotovo u potpunosti potisnula prvobitnu emu. Bez
obzira Klasa Broj adresa Procenat na to, postoje dva razloga za izuavanje klasnog IP adresiranja:
1) deo A 231 = 2,147,483,648 50% Interneta jo uvek koristi klasno adresiranje; 2) poznavanje
B 230 = 1,073,741,824 25% koncepta klasnog adresiranja je neophodan za razumevanje
C 229 = 536,870,912 12.5% besklasnog adresiranja.
28
D 2 = 268,435,456 6.25%
E 228 = 268,435,456 6.25%

Sl. 2-2 Zauzee adresnog prostora.

Kod klasnog IP adresiranja, prostor IP adresa je podeljen na pet klasa: A, B, C, D i E. Svaka klasa zauzima jedan
kontinualni deo adresnog prostora (Sl. 2-2). Kao to moemo videti na Sl. 2-2, klasa A pokriva ak polovinu
adresnog prostora, klasa B 1/4, klasa C 1/8, a klase D i E po jednu 1/16. Broj adresa u svakoj klasi dat je u tabeli
sa Sl. 2-2.

Odreivanje klase
Svaka IP adresa pripada jednoj klasi. Pripadnost IP adrese klasi moe se odrediti na osnovu binarnog ili
decimalnog oblika adrese. Ako je adresa data u binarnom obliku, tada prvih nekoliko bita ukazuju na klasu kojoj
adresa pripada (Sl. 2-3(a)). Adresa pripada klasi A ako njen krajnji levi bit ima vrednost 0. Pripadnost klasi B se
prepoznaje po poetnoj sekvenci 10, klasi C po sekvenci 110, klasi D po 1110 i klasi E po etiri poetne 1-ce.
Da bi smo odredili klasu IP adrese date u obliku takaste-decimalne notacije, potrebno je pogledati samo prvi
(krajnji levi) bajt (broj) adrese. Svaka klasa ima odreeni opseg ovih brojeva ( Sl. 2-3(b)). Na primer, ako je prvi
bajt izmeu 0 i 127, klasa adrese je A. Ako je prvi bajt izmeu 128 i 191, klasa adrese je B, i td.

(a) (b) Sl. 2-3 Odreivanje

klase: (a) u binarnoj notaciji; (b) u decimalnoj notociji. Netid i Hostid
IP adrese u klasama A, B i C podeljene su na dva dela: netid i hostid. Ovi delovi su promenljive duine, zavisno
od klase kojoj adresa pripada (Sl. 2-4). Netid identifikuje mreu na Internetu, a hostid host u mrei. U klasi A,
jedan bajt definie netid, a tri bajta hostid; u klasi B, po dva bajta se koriste za netid i hostid; u klasi C, tri bajta
definiu netid, a jedan hostid. Adrese iz klase D se koriste kao multicat adrese. U ovoj klasi ne postoji podela na
netid i hostid. Adrese iz klase E su rezervisane za neke budue primene.

7
Sl. 2-4 Netid i hostid

Klase i blokovi
Jedan problem klasnog adresiranja je taj da je svaka klasa podeljena na fiksni broj blokova fiksne veliine.
Razmotrimo detaljnije svaku od klasa.
Klasa A
Klasa A je podeljena na 128 blokova, gde svaki blok ima razliiti netid. Prvi blok pokriva adrese od 0.0.0.0 do
0.255.255.255 (netid 0). Drugi blok pokriva adrese 1.0.0.0 do 1.255.255.255 (netid 1). Poslednji blok pokriva
adrese 127.0.0.0 do 127.255.255.255 (netid 127). Uoimo da sve adrese u bloku imaju isti prvi bajt (netid), a
razlikuju se po vrednostima preostala tri bajta (hostid).
Prvi i poslednji blok u klasi A rezervisani su za posebne namene (kao to emo uskoro videti). Dodatno, jedan
blok (netid 10) se koristi za privatne adrese (za izolovane mree koje nisu povezane na Internet). Preostalih 125
blokova su raspoloivi za dodelu zainteresovanim organizacijama. To znai da je ukupan broj organizacija koje
mogu posedovati adresu iz klase A samo 125. Meutim, svaki blok u klasi A sadri ak 16,777,216 adresa !
Organizacija mora biti veoma velika da bi iskoristila toliki broj adresa.
Na Sl. 2-5 je prikazano kako organizacija kojoj je dodeljen blok sa netid 73 koristi svoje adrese. Prva adresa iz
bloka (73.0.0.0) se koristi za identifikaciju same organizacije na Internetu. Ova adresa se zove mrena adresa i
definie mreu organizacije, a ne neki pojedinani host. Organizaciji nije dozvoljeno da koristi poslednju adresu
bloka (73.255.255.255), jer ova adresa imam specijalnu namenu. Preostale adrese iz bloka, organizacija moe
koristiti za svoje hostove i rutere.
Klasa A je namenjena velikim organizacijama, sa velikim brojem hostova i rutera, ali ogroman broj adresa u
svakom bloku je verovatno vei od potreba i najveih organizacija. Zbog toga mnoge adrese iz ove klase ostaju
neiskoriene.

Klasa B
Klasa B je podeljena na 16,384 bloka, pri emu svaki blok ima isto netid. esnaest blokova su rezervisani za
privatne adrese, dok su preostalih 16,368 raspoloivi za dodelu organizacijama. Prvi blok pokriva adrese od
128.0.0.0 do 128.0.255.255 (netid 128.0). Poslednji blok pokriva adrese od 191.0.0.0 do 191.0.255.255 (netid
128.0). Uoimo da sve adrese iz istog bloka imaju ista prva dva bajta (hostid), a da se razlikuju po vrednosti
druga dva bajta (hostid). Na Sl. 2-6 je prikazano kako organizacija kojoj je dodeljen blok sa netid 180.0 moe
koristiti svoje adrese. Kao i u klasi A, prva adresa iz bloka je mrena adresa, a poslednja ima posebnu namenu.
Preostale adrese organizacija moe koristiti za svoje hostove i rutere.
Ukupan broj organizacija kojima se moe dodeliti blok iz klase C iznosi 16,368. Meutim, poto svaki blok iz
ove klase sadri 65,536 hostova, organizacija mora biti dovoljno velika da iskoristi sve ove adrese. Iz tog
razloga, kao i kod klase A, veliki broj adresa iz klase B, je neiskorien.

Klasa C
Klasa C je podeljena na 2,097,152 bloka, pri emu svaki blok ima isto netid. 256 blokova su rezervisani za
privatne adrese, dok su preostalih 2,096,896 predvieni za dodelu organizacijama. Prvi blok obuhvata adrese od
192.0.0.0 do 192.0.0.255. (netid 192.0.0). Poslednji blok obuhvata adrese od 223.255.255.0 do 223.255.255.255
(netid 223.255.255). Uoimo da su prva tri bajta (netid) svih adrese iz istog blokova identina, dok etvrti bajt
moe imati bilo koju vrednost (hostid). Na Sl. 2-7 je prikazano kako organizacija kojoj je dodeljen blok sa netid
200.11.8 moe koristiti svoje adrese. Kao i kod klasa A i B, prva adresa iz svakog bloka je mrena adresa, a
poslednja ima posebnu namenu.

8
Ukupan broj organizacija koje mogu posedovati blok iz klase C je 2,096,896. Meutim, poto svaki blok u ovoj
klasi sadri 256 adresa, ovu klasu obino koriste organizacije sa malim brojem hostova i rutera. (Zbog
ogranienog broja adresa u bloku, mali broj organizacija se odluuje da uzme blok iz klase C.)

Klasa D
U klasi D postoji samo jedan blok adresa. Klasa D se koristi za multicast (poruka se ne alje samo na jedno, ve
na vie odredita). Svaka adresa iz ove klase se koristi da definie jednu grupu hostova na Internetu. Kada se
grupi dodeli adresa iz klase D, svi hostovi, lanovi ove grupe, pored normalne (unicast) imae i grupnu
(multicast) adresu.

Klasa E
U klasi E postoji samo jedan blok adresa, koje su rezervisane za neke budue namene. Mrene
adrese
Mrene adrese igraju bitnu ulogu u klasnom IP adresiranju. Mrena adresa poseduje sledee osobine:
Mrena adresa je prva adresa u bloku.
Mrena adresa definie mreu (a ne host). (Ruteri usmeravaju pakete shodno mrenoj
adresi) Za datu mrenu adresu, u mogunosti smo da odredimo klasu adrese, blok i opseg
adresa u bloku.
Treba uoiti da kod klasnog adresiranja mrena adresa prua potpune informacije o mrei. Za datu mrenu
adresu, u mogunosti smo da odredimo broj adresa u odgovarajuem bloku. To proistie iz injenice da je broj
adresa u svakom bloku fiksiran klasnom emom adresiranja.
Maska
U prethodnoj sekciji smo videli kako se za datu mrenu adresu moe odrediti opseg adresa u odgovarajuem
bloku. Postavlja se pitanje da li mogua i inverzna operacija: kako na osnovu date IP adrese odrediti mrenu
adresu (tj. prvu adresu u odgovarajuem bloku). Ova operacija je vana prilikom rutiranja paketa. Da bi ruter
usmerio paket u korektnu mreu, on mora iz odredine IP adrese (sadrane u zaglavlju datagrama) da izvue
adresu mree.
Jedan nain kako se moe nai mrena adresa jeste da se najpre odrede klasa i netid date IP adrese, a da se zatim
hostid postavi na nulu. Na primer, neka je data adresa 134.45.78.2. Adresa pripada klasi B (prvi bajt je iz opsega
128 - 191) u kojoj netid zauzima 2 bajta. Dakle netid je 134.45, a traena mrena adresa 134.45.0.0.
Opisani nain je mogu samo ako posmatrana mrea nije podeljena na podmree. Procedura za odreivanje
mrene adrese na osnovu date IP adrese, koja se moe uoptiti i na sluaj kada podmree postoje, koristi tzv.
masku.
Maska je 32-bitni broj, koji AND-ovan sa bilo kojom adresom iz bloka daje mrenu adresu ( Sl. 2-8). AND
(logika I) operacija se primenjuje na svaki par bitova maske i adrese. Drugim reima, bitovi adrese koji
odgovaraju 1-cama iz maske zadravaju svoju vrednost (ako su 1 ostaju 1, ako su 0 ostaju 0), a bitovi koji
odgovaraju 0-ma iz maske menjaju se na 0.

Sl. 2-8 Koncept maskiranja. Podrazumevane maske

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

9
CIDR notacija
Iako kod klasnog adresiranja svaka adresa ima podrazumevanu (jednoznanu) masku, ponekada je uobiajeno (a
i kompatabilno sa klasnim adresiranjem) da se podrazumevana maska eksplicitno naglasi prilikom zapisivanja
adrese. Za ovu namenu koristi se CIDR (izgovara se cider) notacija. U ovoj notaciji, broj 1-ca u maski se
zapisuje na kraju adrese posle kose crte. Na primer, adresa 18.46.74.10, koja je iz klase A sa podrazumevanom
maskom 255.0.0.0, se zapisuje kao 18.46.74.10/8, da bi se naglasilo da u maski postoji osam 1-ca. Slino, adresa
141.24.74.69 se zapisuje kao 141.24.74.69/16 (to pokazuje da adresa pripada klasi B i da maska ima esnaest
1ca.
Problem iscrpljivanja IP adresa
Zbog brzog rasta Interneta, kao i zbog nedostataka samog klasnog adresiranja, raspoloive IP adresu su gotovo
iscrpljene. Uprkos tome, broj ureaja na Internetu je jo uvek mnogo manji od 2 32. Klase A i B su u potpunosti
iskoriene, dok su blokovi iz klase C previe mali za organizacije srednje veliine. Neto kasnije, ukazaemo
na naine kako se problem iscrpljivanja IP adresa moe ublaiti.

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

Dodela adresa
Dodela IP adresa na globalnom nivou je pod kontrolom meunarodne neprofitne organizacije koja se zove
ICANN (Internet Corporation for Assigned Names and Numbers). Meutim, ICANN, po pravilu, se ne bavi
dodelom adresa pojedinanim organizacijama, ve blokove adresa dodeljuje ISP-ovim. Svaki ISP zatim deli svoj
blok adresa na manje blokove i raspodeljuje ih svojim korisnicima. Ovakav pristup se naziva agregacijom
adresa, jer se veliki broj manjih blokova adresa objedinjuje u jedan veliki blok koji je dodeljen jednom ISP-u.
2.2 Isporuka, prosleivanje i rutiranje IP datagrama
U ovoj sekciji baviemo se isporukom, prosleivanjem i rutiranjem IP datagrama do njihovog krajnjeg
odredita. Isporuka se odnosi na nain kako se datagrami, po kontrolom mrenog sloja, tretiraju i prenose
unutar jedne mree. Prosleivanje se odnosi na nain kako se datagrami isporuuju sledeem ruteru, kada
datagram treba da proe kroz vie mrea da bi stigao do svog odredita. Rutiranje se odnosi na nain kako se
kreiraju tabele rutiranja koje ruteri koriste kada donose odluke o prosleivanju/isporuci datagrama.
2.2.1 Isporuka
Isporuku datagrama moemo podeliti na dve ne tako stroge kategorije: direktna i indirektna isporuka. Direktna
isporuka se odnosi na prenos datagrama sa jednog hosta jedne fizike mree na drugi host te iste mree.
Indirektna isporuka se dogaa kada se izvor i odredite ne nalaze u istoj mrei, zbog ega izvor mora da preda
datagram ruteru da bi ga ovaj dalje preneo.
Direktna isporuka
Kod direktne isporuke, konano odredite datagrama je host povezan na istu fiziku mreu kao i poiljalac
(izvor) datagrama. Moemo uoiti dva sluaja direktne isporuke (Sl. 2-22):

10
 a) Od izvornog do odredinog hosta koji su locirani na istoj fizikoj mrei. U ovom sluaju prenos
datagrama se obavlja bez uea rutera, a izvorni host direktno isporuuje datagram odredinom hostu.
b) Od poslednjeg rutera do odredinog hosta. Ovo je sluaj koji odgovara poslednjem koraku u prenosu
datagrama kada se izvor i odredite ne nalaze u istoj mrei. Poslednji ruter na putanji izmeu izvora i
odredita datagrama prikljuen je direktno na istu fiziku mreu kao i odredite. Prema tome, poslednji
ruter e preneti datagram koristei direktnu isporuku.

Sl. 2-22 Direktna isporuka.

Osnovno pitanje je kako e poiljalac znati da li se odredite nalazi u mrei na koju je on direktno prikljuen.
Odgovor se krije u jednostavnom testu. Poiljalac analizira odredinu IP adresu uzetu iz zaglavlja datagrama; iz
nje izdvaja mrenu adresu i uporeuje je sa adresama mrea na koje je prikljuen. Ako pronae podudarnost,
datagram moe biti direktno isporuen.
Da bi datagram i fiziki bio prenet, poiljalac dodatno treba da na osnovu odredine IP adrese pronae fiziku
adresu odredinog hosta. Za ovu namenu (preslikavanje IP adresa na fizike adrese) koristi se ARP protokol,
koji e kasnije biti razmatran. Sa fizikom adresom na raspolaganju, IP softver predaje datagram sloju veze koji
ga enkaspulra u okvir i posredstvom fizikog sloja alje na liniju. Indirektna isporuka
Ukoliko se odredini host ne nalazi u istoj mrei gde i izvorni host, datagram se isporuuje indirektno. Kod
indirektne isporuke, datagram se prenosi od rutera do rutera sve dok ne stigne do rutera koji je povezan na istu
fiziku mreu u kojoj se nalazi konano odredite ( Sl. 2-23). Uoimo da isporuka uvek ukljuuje jednu direktnu
isporuku i ni jednu, jednu ili vie idirektnih isporuka. Poslednja isporuka je uvek direktna.

Sl. 2-23 Indirektna isporuka.

Indirektni prenos je sloeniji od direktnog jer poiljalac (izvorni host, odnosno meu-ruter) mora da identifikuje
IP adresu sledeeg rutera kojem treba da poalje datagram. Ovaj izbor se vri na osnovu odredine IP adrese
datagrama i tabela rutiranja. Kada je IP adresa sledeeg rutera poznata, poiljalac koristi ARP da bi pronaao
njegovu fiziku adresu.
2.2.2 Prosleivanje
Proslediti datagram znai uputiti ga jedan korak dalje du putanje do njegovog krajnjeg odredita. Prosleivanje
podrazumeva da hostovi i ruteri poseduju tabele rutiranja. Host kada eli da poalje datagram (ili ruter koji treba
da poalje primljeni datagram), iz tabele rutirana, a na osnovu odredine IP adrese, dobija informaciju kome
treba da proslediti datagram. Glavni problem u vezi sa tabelama rutiranja tie se njihove veliine. Zbog
impresivne veliine dananjeg Interneta, reenje kod koga bi tabela rutiranja sadrala posebnu stavku sa
kompletnom putanjom za svaku moguu odredinu IP adresu je praktino neizvodljivo.

11
2.2.3 Rutiranje
Rutiranje se odnosi na kreiranje i auriranje tabela rutiranja.
Statike i dinamike tabele rutiranja
Kao to smo videli u prethodnoj sekciji, ruter usmerava datagrame na osnovu sadraja tabele rutiranja koja za
svako odredite ili grupu odredita sadri jednu stavku. Tabele rutiranja mogu biti statike ili dinamike.
Statike tabele rutiranja
Statike tabele rutiranja se manuelno popunjavaju. Stavke u tabelu unosi administrator mree. Nakon to je
tabela kreirana, ona se ne moe automatski aurirati (zbog npr. promena nastalih na Internetu). Svaku promenu
mora da unese administrator. Statike tabele se koriste u malim mreama, ija se konfiguracija ne menja esto.
Dinamike tabele rutiranja
Dinamike tabele rutiranja se automatski auriraju korienjem jednog od protokla za dinamiko rutiranje (RIP,
OSPF ili BGP). Uvek kada se na Internet desi neka promena, kao to je prestanak rada nekog rutera ili prekid
nekog linka, dinamiki protokol za rutiranje je odgovoran za automatsko auriranje tabela svih rutera.
2.4 Internet protokol (IP)
Internet protokol (IP) je centralni protokol mrenog sloja TCP/IP modela. Savremeni Internet predstavlja
kolekciju meusobno povezanih podmrea. Ne postoji planska, uniformna, fiksna struktura, ve okosnicu
Interneta ine nekoliko magistralnih (backbone) mrea povezanih pomou komunikacionih linija velike
propusne moi i brzih rutera. Na backbone mree povezane su regionalne, a na regionalne LAN mree mnogih
univerziteta, kompanija i ISP-ova (Sl. 1-1). Zadatak Internet protokola je da mree Internet-a dri na okupu.
Zahvaljujui IP-u, mnotvo fiziki raznorodnih mrea objedinjeno je u jednu ogromnu mreu. IP pravi utisak
kao da su svi hostovi povezani na tu veliku mreu, a ne na svoje individualne fizike mree.
IP obezbeuje best-effort (tj. negarantovani) servis za prenos podataka od izvora do odredita, bez obzira da li se
maine nalaze u istoj, susednim ili udaljenim mreama. Best-effort znai da IP ne obezbeuje proveru graaka i
evidenciju o isporuci podataka. IP pretpostavlja da su nii slojevi nepouzdani i dae sve od sebe da podatke
isporui na odredite, ali bez garancija. U toku prenosa, podaci mogu biti uniten na fizikom nivou (npr. zbog
greaka u prenosu nastalih usled elektrinih smetnji), ruter, zaguen saobraajem, moe odbaciti paket, linija
kojom paket treba da se prenese dalje moe privremeno biti u prekidu. Ako je pouzdanost bitna, IP se mora
upariti sa pouzdanim transportnim protokolom (kao to je TCP).
IP je takoe beskonekcioni protokol za mree sa komutacijom paketa koje koriste datagramski pristup. Kao to
znamo, to znai da se svaki datagram nezavisno prenosi i da svaki datagram moe biti prenet do svog odredita
razliitim putanjama. Prenoeni razliitim putanjama izmeu istog para izvor-odredite datagrami mogu stii na
odredite izvan redosleda. Ponovi, IP se oslanja na protokole vieg nivoa da ree sve ove probleme.
Ogranienu funkcionalnost IP-a se ne treba smatrati njegovom slabou. IP obezbeuje bazini servis prenosa
podataka na daljinu; na korisniku je da po potrebi doda funkcije koje su neophodne za implementaciju svake
konkretne aplikacije.
2.4.1 Datagram
Paketi koji se prenose na IP nivou nazivaju se datagramima. Datagram je paket promenljive duine (do 65535
bajta) i sastoji se iz dva dela: zaglavlje i podaci. Zaglavlje je podeljeno na polja koja sadre informacije bitne za
rutiranje i isporuku datagrama. Format zaglavlja prikazan je na Sl. 2-49. Veliina zaglavlja je najmanje 20, a
najvie 60 bajta. Prvih dvadeset bajtova u zaglavlju su fiksni (uvek postoje); opcioni deo (IP OPTIONS) je
promenljive duine od 0 do 40 bajtova. Kod TCP/IP protokola uobiajeno je da se formati zaglavlja prikazuju
podeljeni na 4-bajtne sekcije. Datagram se prenosi u big-endian poretku: s leva na desno, sa krajnjim levim
bitom polja VERS na poetku. Sledi kratak opis polja zaglavlja.

Sl. 2-49 Format IP datagrama.

VERS (Verzija). etvorobitno polje koje definie verziju IP protokola. Aktuelna verzija je 4 (IPv4), kojoj u
ovom polju odgovara binarna vrednost 0100. Postojanje broja verzije u svakom datagramu olakava prelazak na
novu verziju IP protokola (omoguava da neke maine podravaju samo staru, a druge samo novu ili obe verzije
protokola). Trenutno je aktuelan prelaz sa IPv4 na IPv6, koji traje ve godinama, i trajae jo dugo vremena.

12
HLEN (Header Length - duina zaglavlja). Poto veliina zaglavlja nije konstantna, u samom zaglavlju
predvieno je polje HLEN, koje definie duinu zaglavlja izraenu brojem 32-bitnih rei (4-bajta). Minimalna
vrednost je 5 (opcije ne postoje), a maksimalna 15 (polje za opcije postoji i maksimalne je duine).
SERVICE TYPE (Tip servisa). Polje veliine jednog bajta koje definie kako e datagram biti tretiran od
strane rutera. Pojedinani bitovi ovog polja definiu prioritet datagrama, nivo pouzdanosti i kanjenja koje
poiljaoca datagrama oekuje od rutera. Meutim, u praksi, ruteri najee ignoriu ovo polje.
TOTAL LENGTH (Ukupna duina) definie veliinu IP datagrama (zaglavlje plus podaci) izraenu u
bajtovima. Veliina ovog polja je 16 bita, to znai da veliina datagrama moe biti maksimalno 65535 bajta
(216-1). Broj bajtova podataka koji se prenose datagramom moe se odrediti tako to e se od TOTAL LENGTH
oduzeti veliina zaglavlja (4 x HLEN). Kada kasnije u ovoj sekciji budemo razmatrali fragmentaciju, videemo
da pojedine fizike mree ne mogu enkapsulirati datagram od 65535 u njihov okvir. U takvim sluajevim, da bi
se ostvario prenos, neophodno je izvriti fragmentaciju datagrama.
IDENTIFICATION (Identifikacija) 16-bitno polje koje se koristi prilikom fragmentacije datagrama.
FLAGS (Polje za markere). Trobitno polje koje se takoe koristi prilikom fragmentacije datagrama.
FRAGMENT OFFSET (Pomeraj fragmenta) 13-bitno polje koje se koristi, kao i prethodna dva, prilikom
fragmentacije datagrama.
TIME TO LIVE (Vreme ivota) je broja koji se koristi da bi se ograniilo vreme ivota datagrama. Vrednost
ovog polja se umanjuje za 1 u svakom ruteru kroz koji datagram prolazi. Ako Vreme ivota dostigne 0 pre nego
to datagram stigne do odredita, datagram se unitava. Na ovaj nain spreava se da datagram ostane zarobljen
u mrei, lutajui od rutera do rutera, zbog npr. greke u tabelama rutera.
PROTOCOL (8 bita) ukazuje na protokol vieg nivoa koji koristi usluge IP sloja. IP datagram moe da
enkapsulira podatke iz vie protokola vieg nivoa, kao to su UDP, TCP, ICMP i IGMP. Ovo polje definie
kojem se isporuuje sadraj IP datagrama. Vrednosti ovog polja, za razliite protokole vieg nivoa navedene su u
tabeli T. 2-4.
T. 2-4 Protokoli
Vrednost Protokol
1 ICMP
2 IGMP
6 TCP
17 UDP
89 OSPF
HEADER CHECKSUM (Kontrolna suma zaglavlja) je 16-bitno polje koje se koristi za verifikaciju zaglavlja
(ne celog paketa). Nain izraunavanja kontrolne sume bie objanjen kasnije u ovoj sekciji.
Polja SOURCE IP ADDRESS i DESTINATION IP ADDRESS (Adresa izvora i Adresa odredita) sadre
32-bitne mrene (IP) adrese izvornog hosta (host koji je poslao datagram) i odredinog hosta (krajnje odredite
datagrama). Ove adrese ostaju neizmenjene u svim fragmentima na koje se datagram eventualno deli u toku
prenosa.
2.4.2 Fragmentacija
Na putu do svog krajnjeg odredita, datagram moe proi kroz vie razliitih mrea. Svaki ruter izdvaja IP
datagram iz primljenog okvira, obrauje ga i ponovo enkapsulira u okvir kojeg alje sledeem ruteru ili
odredinom hostu. Format i veliina primljenog okvira zavisi od protokola sloja veze koji se koristi na fizikoj
mrei preko koje je okvir stigao u ruter. Format i veliina okvira kojeg ruter alje zavisi od protokola sloja veze
koji se koristi na fizikoj mrei preko koje okvir dalje nastavlja svoj put. Na primer, ako ruter povezuje LAN na
WAN, on prima okvir u LAN formatu, a alje ga u WAN formatu.
MTU
Svaki protokol sloja veze definie format svog okvira. Ogranienje koje uvek postoji jeste maksimalna veliina
polja za podatke u okviru (tzv. MTU - Maximum Transfer Unit - najvea jedinica prenosa). Drugim reima, kada
se datagram enkapsulira u okvir, ukupna veliina datagrama mora biti manja od ove maksimalne veliine, koja
je definisana ogranienjima nametnutim hardverom i softverom koji se koriste u mrei. Vrednost MTU
parametra se razlikuje od jedne do druge fizike mree (T. 2-5).
T. 2-5 MTU kod nekoliko standardnih mrea.
Protokol MTU
Hyperchannel 65,535
TokenRing (16 Mbps) 17,914
TokenRing (4 Mbps) 4,464
FDDI 4,352
Ethernet 1,500
X.25 576
PPP 296

13
Da bi se IP protokol uinio nezavisnim od fizike mree, projektanti IP protokola su odluili da maksimalna
veliina IP datagrama bude jednaka 65,535 bajta. Na taj nain, prenos je efikasniji ako se koristi mrea sa MTU
ovo veliine. Meutim, za ostale fizike mree, sa manjim MTU, datagram se mora podeliti na manje celine
kako bi mogao biti prenet kroz mreu. Ova podela se naziva fragmentacijom.
Nakon izvrene fragmentacije, svaki fragment (koji je takoe datagram) ima svoje zaglavlje u kome su veina
polja iz prvobitnog datagrama ponovljena, ali su neka i promenjena. Fragmentirani datagram i sam moe biti
fragmentiran, ako naie na mreu sa jo manjim MTU-om. Drugim reima, datagram moe biti fragmentiran
nekoliko puta dok ne stigne na odredite.
Datagram moe biti fragmentiran od strane bilo kog rutera na putanji. Meutim, rekonstrukciju prvobitnog
datagrama od fragmentiranih delova obavlja iskljuivo odredini host. Ovo ogranienje je logino, jer se ne
moe garantovati da e svi fragmenti istog datagrama proi istom putanjom do odredita.
Kada se datagram fragmentira, obavezni delovi zaglavlja moraju biti kopirati u zaglavlja svih kreiranih
fragmenata. Polje za opcije moe ali i ne mora biti identino onome iz prvobitnog datagrama. Host ili ruter koji
obavlja fragmentaciju, mora promeniti vrednosti tri polja: FLAGS, FRAGMENTATION OFFSET i TOTL
LENGTH. Naravno, vrednost polja za kontrolnu sumu se mora ponovo izraunati, bez obzira da li se datagram
fragmentira ili ne. Sledea tri polja zaglavlja IP datagrama se koriste u fragmentaciji:
IDENTIFICATION (Identifikacija) 16-bitno polje koje identifikuje datagrame koji potiu iz istog izvora.
Kombinacija izvorne IP adrese i vrednosti polja za identifikaciju na jedinstveni nain definie datagram kada on
napusti izvorni host. Da bi se obezbedila jedinstvenost, IP protokol koristi broja za oznaavanje datagrama.
Uvek kada alje datagram, IP protokol izvornog hosta kopira tekuu vrednost ovog brojaa u polje za
identifikaciju, a zatim uveava broja za 1. Ako se datagram fragmentira, vrednost polja za identifikaciju se
kopira u sve fragmente. Drugim reima, svi fragmenti nastali podelom jednog datagrama imae istu vrednost u
polju za identifikaciju kao i polazni datagram. Na taj nain, odredinom hostu je omogueno da odredi kom
datagramu upravo pristigli fragment pripada. Host zna da sve fragmente sa istom vrednou za identifikaciju i
istom izvornom IP adresom treba da objedini u jedan datagram.
FLAGS (Polje za markere). Sadri tri bita. Prvi bit je neiskorien (nema definisanu namenu). Drugi bit, DF,
postavljen ne vrednost 1 znai Dont Framgment (ne fragmentiraj) i predstavlja instrukciju ruteru da datagram
nije dozvoljeno fragmentirani (zato to npr. odredite nije sposobno da obavi rekonstrukciju datagrama).
Postavljajui DF na 1, poiljalac je siguran da e datagram stii do odredita u jednom komadu (ak iako to
znai da e datagram do odredita stii nekim zaobilaznim putem, izbegavajui male mree, koje nisu u
mogunosti da ga prenesu u okviru jednog okvira). Ako ruter ne moe da prosledi datagram ni kroz jednu od
raspoloivih fizikih mrea, ruter e unititi datagram, a izvorno hostu e poslati ICMP poruku sa obavetenjem
o greci (videti sledeu sekciju). Bit DF postavljen na 0 oznaava da je datagram dozvoljeno fragmentirati. Trei
bit polja FLAGS, MF (More Fragments) postavljen na vrednost 1 ukazuje da datagram nije poslednji fragment
nekog veeg datagrama; postoji jedan ili vie fragmenata koji slede. Ako bit MF ima vrednost 0, to znai da je
ovaj datagram poslednji fragment nekog veeg datagrama ili se radi o datagramu koji nije fragmentiran.
FRAGMENT OFFSET (Pomeraj fragmenta) (13 bita) definie poziciju ovog fragmenta u okviru celokupnog
datagrama. Predstavlja pomak (offset) podataka u prvobitnom datagramu izraen u jedinicama od po 8 bajta. Na
Sl. 2-50 je prikazan datagram sa podacima veliine 4000 bajta podeljen na tri fragmenta. Bajtovi u polaznom
datagramu su numerisani sa 0 do 3999. Prvi fragment sadri bajtove 0 do 1399. Pomak kod ovog datagrama je
0/8 = 0. Drugi fragment prenosi bajtove 1400 do 2799; vrednost njegovog pomaka je 1400/8 = 175. Konano,
trei fragment sadri bajtove 2800 do 3999, a njegov pomak je 2800/8 = 350.

14
2.4.3 Opcije
Zaglavlje IP datagrama se sastoji iz dva dela: fiksnog i promenljivog. Fiksni deo, duine 20 bajta, smo ve
obradili. Promenljivi deo, maksimalne duine 40 bajta, rezervisan je za tzv. opcije. Opcije, kao to i samo ime
sugerie, nisu obavezne. Opcije se koriste za testiranje i debagiranje mree. Pri normalnom prenosu podataka,
zaglavlje IP datagrama ne sadri ovo polje.
Format
Deo za opcije, ako postoji, moe sadrati jednu ili vie opcija. Sve opcije imaju identian format, koji je
prikazan na Sl. 2-52. Opcija se sastoji iz tri polja: 1-bajtno polje za kd (Code), 1-bajtno polje za duinu (Length)
i polje za podatke (Data) promenljive duine.
Code Length Data
8 bita 8 bita Promenljive duine

Copy Class Number

1 bita 2 bita 5 bita

Sl. 2-52 Format opcije.

Code. Polje za kd opcije sadri 8 bita i podeljeno je tri podpolja: Copy, Class i Number.
Copy. Ovo jednobitno podpolje kontrolie prisustvo opcije u fragmentima. Ako je ovaj bit postavljen na 0, tada
opcija sadrana u polaznom datagramu mora biti kopirana samo u njegov prvi fragment. Za vrednost 1, opcija se
kopira u svim fragmentima.
Class. Ovo 2-bitno podpolje definie optu namenu opcije. Vrednost 00 u ovom polju ukazuje na opciju koja se
koristi za kontrolu datagrama. Vrednost 10 ukazuje na opciju koja se koristi za debagiranje i menadment mree.
Znaenje dve preostale vrednosti , 01 i 11, jo uvek nije definisano.
Number. Ovo 5-bitno podpolje definie tip opcije. Mada se sa 5 bita moe definisati do 32 razliita tipa, u
upotrebi su samo 6.
Lenght. Ovo polje definie ukupnu duinu opcije ukljuujui i polja kd i duinu. (Nije prisutno kod svih opcija)
Data. Ovo polje sadri podatke specifine za konkretnu opciju. (Nije prisutno kod svih opcija).
Tipovi opcija
Kao to je napomenutu, trenutno su u upotrebi est opcija. Dve opcije su 1-bajtne (sastoje se samo od polja za
kd), dok su preostale etiri vie-bajtne (sadre sva tri polja). Sledi kratak opis opcija:
No Operation. Ovo je 1-bajtna opcija koja se koristi za popunu nepopunjenih bajtova izmeu opcija, kada
datagram sadri vie od dve opcije. Na primer, moe se koristiti za poravnanje sledee opcije, tako da ona pone
od naredne 16-bitne ili 32-bitne rei.
End of Options (Kraj opcija). Ovo je takoe 1-bajtna opcija koja se koristi za dopunu polja za opcije, kako bi
ono zauzimalo celi broj 16-bitnih ili 32-bitnih rei. U polju za opcije se moe nalaziti samo jedna end of
operation opcija, a moe se koristiti sam kao poslednja opcija. U sluajevima kada je za poravnanje potrebno
vie od jednog bajta, na kraj polja za opcije moe se umetnuti vie no operation i jedna end of options opcija.
Record route (snimanje putanje). Ova opcija se koristi za snimanje putanje kojom se datagram prenosi kroz
Internet. U polju za podatke ove opcije moe se smestiti do devet IP adresa rutera kroz koje je datagram proao
(najvie devet zbog ogranienja duine polja za opcije na 40 bajta). Izvorni host rezervie mesta (stavke) u polju
za opcije koja e popunjavati ruteri koje datagram poseti. Format ove opcije prikazan je na Sl. 2-53. Polje pointer
ukazuje na prvu slobodnu stavku, tj. sadri redni broj prvog slobodnog bajta (brojano od poetka polja za
opcije). Kada datagram napusti izvorni host, sve stavke su prazne, a pointer ima vrednost 4. Svaki ruter koji
obrauje datagram, poredi vrednost pointera sa vrednou polja za duinu. Ako je vrednost pointera vea od
vrednosti polja za duinu, polje za opcije je popunjeno, a nova stavka se ne upisuje. U suprotnom, ako u polju za
opcije jo uvek ima slobodnog prostora, ruter upisuje IP adresu pridruenu mrenom adapteru kroz koji e
datagram biti poslat dalje, poev od pozicije na koju ukazuje pointer i uveava vrednost pointera za 4. Na ovaj
nain, analizom zaglavlja na strani odredinog hosta, moe se rekonstruisati putanja kojom je datagram
prenesen.
Code Length (Ukupna Pointer
00000111 duina)
Prva IP adresa (prazno na poetku)

Druga IP adresa (prazno na poetku)

15
 .
.
.
Poslednja IP adresa (prazno na poetku)

Sl. 2-53 Opcija za snimanje putanje.

Strict Source Route (Striktno rutiranje na izvoru). Ovu opciju moe da koristi izvorni host kako bi unapred
odredio putanju datagrama kroz Internet, navodei IP adrese rutera koje datagram mora da poseti. Ako ova
opcija postoji u datagramu, svi navedeni ruteri moraju biti poseeni. Ako datagram dospe u ruter koji nije na
listi, datagram se unitava, a izvornom hostu se alje ICMP poruka o greci. Striktno rutiranje koristi iskljuivo
administratori mree za testiranje i debagiranje mree. Za normalni prenos podataka, izbor putanje se preputa
ruterima. Format ove opcije slian je formatu opcije record route, ali sada stavke popunjava izvorni host IP
adresama rutera.
Loose Source Route (Priblino rutiranje na izvoru) Ova opcija je slina opciji striktnog rutiranja na izvoru ali sa
neto blaim zahtevima. Svaki ruter u listi mora biti poseen, ali datagram moe posetiti i neke druge rutere.
Format i nain korienja je slian kao kod prethodne opcije.
Timestamp (Vremenski zapis). Ova opcija se koristi za beleenje vremena kada su ruteri procesirali datagram.
Vreme se izraava u milisekundama poev od ponoi. Poznavanje ovog vremena pomae administratorima
mree da prate ponaanje rutera na Internetu. Na primer, uz pomo ovih informacija mogue je proceniti vreme
koje je bilo potrebno da datagram pree iz jednog u drugi ruter. Format opcija vremenskog zapisa prikazan je na
Sl. 2-54. Polja za kd i duinu imaju isto znaenje kao i ranije. U polju Overflow pamti se broj rutera koji nisu
uspeli da upiu svoj vremenski zapis zato to vie nije bilo slobodnog prostora u polju za opcije. U polju Flags
definisane su odgovornosti rutera (definisano je ta se oekuje od rutera). Ako je vrednost ovog polja 0, svaki
ruter upisuje samo vremenski zapis u odgovarajuu stavku. Za vrednost 1, svaki ruter upisuje pored vremenskog
zapisa i svoju odlaznu IP adresu. Za vrednost 3, IP adrese su unapred postavljene od strane izvornog hosta; svaki
ruter proverava odgovarajuu IP adresu sa svojom dolaznom IP adresom i, ako utvrdi da su jednake, zamenjuje
je svojom odlaznom IP adresom i upisuje vremenski zapis.

Sl. 2-54 Opcija vremenskog zapisa.

2.4.4 Kontrolna suma
Kod veine TCP/IP protokola za kontrolu greaka se koristi metod koji se naziva kontrolnom sumom
(checksum). Kontrolna suma predstavlja redundantnu informaciju koja se dodaje paketu radi zatite od greaka
koje mogu nastati u toku prenosa paketa. Kontrolna suma se izraunava na strani poiljaoca paketa, a dobijena
vrednost se alje zajedno sa paketom. Prijemnik ponavlja isto izraunavanje nad celim paketom, ukljuujui i
polje za kontrolnu sumu. Ako je rezultat zadovoljavajui, paket se prihvata; ako nije, pakete se odbacuje.
Izraunavanje kontrolne sume na strani poiljaoca
Na strani poiljaoca, paket se deli na n-bitne sekcije (n je obino 16 bita). Sve sekcije se sabiraju korienjem
pravila sabiranja binarnih brojeva u jedininom komplementu. Rezultat je n-to bitna suma. Nakon toga, suma se
komplementira i upisuje u polje za kontrolnu sumu. Izraunavanje kontrolne suma na strani primaoca
Primalac deli primljeni paket na n-bitne sekcije. Sve sekcije se sabiraju, a dobijeni rezultat komplementira. Ako
je konani rezultat 0, paket se prihvata kao ispravan; inae, ako se dobije vrednost razliita od 0, paket se
odbacuje, kao neispravan.
Sl. 2-55 na grafiki nain prikazuje procedure izraunavanja kontrolne sume na strani poiljaoca i strani
prijemnika.

16
Kao to znamo, za brojeve u formatu jedininog komplementa operacija komplementiranja identina je promeni
znaka (komplement od T je -T). Pretpostavimo da smo sabiranjem sekcija na strani poiljaoca dobili vrednost T.
Nakon komplementiranja dobija se -T, to predstavlja vrednost kontrolne sume koja se alje prijemniku. Sa
druge strane, prijemnik sabira sve sekcije i ako nema greaka u prenosu dobija sumu jednaku T + (-T) (T za sva
polja osim kontrolne sume i -T za polje kontrolne sume). Rezultat e biti sve 1-ce, odnosno -0, to nakon
komplementiranja postaje 0 (sve nule). Kontrolna suma u IP datagramu
Kontrolna suma za IP datagram se izraunava shodno prethodno opisanoj proceduri. Prvo, polje u zaglavlju
datagrama predvieno za kontrolnu sumu se postavlja na sve nule. Zatim se celokupno zaglavlje deli na
16bitne sekcije, koje se potom sabiraju. Rezultujua suma se komplementira i umee u polje za kontrolnu sumu.
Kontrolna suma kod IP datagrama pokriva samo zaglavlje, a ne i podatke. Postoje dva razloga za to. Prvo, svi
protokoli vieg nivoa koje se prenose IP datagramom poseduju svoje polje za kontrolnu sumu koja pokriva
celokupan paket. Zahvaljujui tome, nema potreba da se kontrolnom sumom IP datagrama proveravaju i
enkapsulirani podaci. Drugo, prolaskom kroz svaki ruter, zaglavlje IP datagrama se modifikuje, ali ne i podaci.
Dakle, kontrolna suma ukljuuje samo one delove datagrama koji se menjaju u prenosu.

2.5 NAT
Privatne mree su mree koje koriste TCP/IP ali su izolovane od Interneta. Privatna mrea moe sadrati od
nekoliko do nekoliko stotina raunara, a njihova glavna namena je deoba zajednikih resursa unutar jedne
organizacije, kao to su baze podataka, tampai i dr. Kao to je ranije napomenuto, hostovima u privatnim
mreama dodeljuju se IP adrese iz nekoliko za tu namentu rezervisanih opsega (tzv. privatne IP adrese, vidi
tabelu T. 2-3). ak iako je privatna mrea ruterom povezana sa globalnim Internetom, ona e ostati izolovana jer
e ruter onemoguiti izalazak datagrama koji nose privatne IP adrese izvan mree.
Tehnika prevoenja mrenih adresa (Network Address Translation - NAT) omoguava hostovima iz privatne
mree da komuniciraju sa sajtovima na globalnom Internetu. Preduslov je da sajt mora imati jednu konekciju ka
globalnom Interentu posredstvom rutera na kome se izvrava NAT softver (Sl. 2-57).

Kao to se moe videti na Sl. 2-57, hostovima iz privatne mree dodeljene su privatne adrese. Ruter poseduje
jednu privatnu adresu, ka privatnoj mrei, i jednu globalnu adresu, ka ostatku Internetu. Gledano sa strane
Interneta, pojedinani hostovi u privatnoj mrei nisu vidljivi, ve je vidljiv samo NAT ruter sa adresom
200.24.5.8.
Prevoenje adresa
Na Sl. 2-58 je ilustrovan osnovni koncept prevoenja adresa. NAT ruter modifikuje svaki paket koji naputa
privatnu mreu, tako to izvornu adresu u paketu zamenjuje svojom NAT adresom (200.24.5.8). Svaki paket koji

17
iz Interneta dolazi u privatnu mreu, takoe prolazi kroz NAT ruter, koji sada odredinu adresu u paketu (a to je
globalna adresa NAT rutera) zamenjuje odgovarajuom odredinom privatnom adresom. Na ovaj nain, iako u
isto vreme vie hostova iz privatne mree mogu komunicirati sa razliitim hostovima na Interetu, hostovi sa
Interneta imaju utisak da komuniciraju samo sa jednim hostom, ija je IP adresa NAT adresa rutera.
172.18.3.1
Izvor: 172.18.3.1 Izvor: 200.24.5.8

Internet

Odredite: 172.18.3.1 Odredite: 200.24.5.8

Sl. 2-58 Prevoenje adresa.

Prevoenje adresa za odlazne pakete je trivijalno. Ali, postavlja se pitanje kako NAT ruter zna kom privatnom
hostu je namenjen paket koji dolazi sa Interneta da bi shodno tome u polju za odredinu adresu dolaznog paketa
upisao ba njegovu privatnu adresu. Ovaj problem se reava tako to NAT ruter kreira tabelu prevoenja koja
uspostavlja vezu izmeu privatnih i eksternih adresa. Korienje jedne IP adrese
U najjednostavnijem obliku, tabela prevoenja ima samo dve kolone: privatnu adresu i eksternu adresu
(odredine adrese paketa). Kada ruter zamenjuje izvornu adresu odlaznog paketa svojom adresom, on takoe
upisuju u tabelu prevoenja na koju odredinu (eksternu) adresu je paket upuen. Kada kasnije od odredita
stigne odziv, ruter, na osnovu izvorne adrese paketa (eksterna adresa) u tabeli prevoenja pronalazi privatnu
adresu hosta koji se prethodno obratio tom eksternom odreditu. Opisana ideja ilustrovana je na Sl. 2-59.
Uoimo da NAT tehnika pretpostavlja da komunikaciju prema Internetu uvek inicira host iz privatne mree. To
praktino znai da korisnici iz prvatne mree u komunikaciji prema Internetu mogu imati iskljuivo ulogu
klijenta. Na primer, korisnici iz privatne mree mogu koristiti Web preko Web pretraivaa (program kao to je
Internet Explorer) jer je pretraiva klijentski program koji obraa Web serveru traei od njega Web stranicu.
Meutim, u privatnoj mrei ne mogu postojati serverske aplikacije vidljive klijentima izvan privatne mree. Na
primer, privatna mrea ne moe imati Web server pokrenut na nekom inernom Hostu koji e biti vidljiv za
eksterne klijente.

Sl. 2-59 Prevoenje. Korienje vie IP adresa

Prevoenje adresa koje se oslanja na korenju samo jedne globalne adrese (kao na Sl. 2-59) onemoguava da sa
istim eksternim hostom, u isto vreme, komuniciraju dva ili vie internih hostova. Da bi se ovo ogranienje
otklonilo NAT ruter, moe koristiti vie globalnih adresa. Na primer, umesto da koristi samo jednu globalnu
adresu (200.24.5.8) NAT ruter moe koristiti etiri (200.24.5.8, 200.24.5.9, 200.24.5.10 i 200.24.5.11). Sa ovim
proirenjem, etiri privatna hosta mogu u isto vreme komunicirati sa istim eksternim hostom. Meutim, izvesna
ogranienja i dalje postoje. Na primer, prema istom eksternom hostu iz privatne mree nije mogue uspostaviti
vie od etiri veze. Takoe, host iz privatne mree ne moe u isto vreme da komunicra sa dva serverska
programa (npr. FTP i TELNET) pokrenuta na istom eksternom hostu. Korienje IP adresa i adresa portova
Radi uspostavljanja relacije vie-ka-vie izmeu hostova iz privatne mree, sa jedne i hostova na Internetu, sa
druge strane, neophodno je u tabelu prevoenja uvrstiti dodatne informacije. Na primer, pretpostavimo da dva

18
interna hosta, sa privatnim adresama 172.18.3.1 i 172.18.3.2, ele da pristupe istom Web serveru na eksternom
hostu sa adresom 25.8.3.2. Za komunikaciju sa Web serverom se koristi aplikacioni protokol HTTP koji se
oslanja na transportni protokol TCP i dostupan je preko adrese porta 80. Ako tabela prevoenja umesto dve
sadri pet kolona sa dodatnim kolonama za izvorne i odredine adrese portova i oznaku protokola transportnog
protokola koji se koristi u komunikaciji, nejednoznanost u prevoenju adresa bie eliminisana (vidi T. 2-6).
Uoimo da kada se NAT ruteru vrati odziv od Web serera, kombinacija izvorne adrese (25.8.3.2) i odredine
adrese porta (1400) jednoznano definie host u privatnoj mrei kome odziv treba biti isporuen. (Za vie
informacija o adresama portova i TCP protokolu pogledati poglavlje 3.)
T. 2-6 Tabela prevoenja sa pet kolona.
Privatna Privatni Eksterna Eksterni Transportni
adresa port adresa port protokol
172.18.3.1 1400 25.8.3.2 80 TCP
172.18.3.2 1401 25.8.3.2 80 TCP
... ... ... ... ...
NAT i ISP
ISP koji prua usluge Internet pristupa dail-up korisnicima moe koristiti NAT radi racionalnijeg korienja
svojih IP adresa. Na primer, pretpostavimo da neki ISP poseduje 1000 IP adresa (globalnih) i opsluuje 100,000
korisnika. Svakom korisniku je dodeljena jedna privatna adresa. ISP prevodi svaku od 100,000 izvornih adresa u
odlaznim paketima u jednu od 1000 globalnih adresa, odnosno globalnu odredinu adresu u dolaznim paketima
u odgovarajuu privatnu adresu. Opisani koncept je ilustrovan na Sl. 2-60.

2.6 ICMP
IP je mreni protokol koji obezbeuje negarantovanu (best-effort) isporuku datagrama od izvornog do
odredinog hosta, osmiljen na nain da obezbedi efikasno korienje mrenih resursa. Meutim, IP protokolu
nedostaju mehanizmi za kontrolu greaka i pomo u menadmentu mree.
IP ne poseduje mehanizme za obavetavanje o nastalim grekama ili korekciju greaka. Na primer, ta e se
desiti ako ruter mora da uniti datagram zato to nije u stanju da nae putanju do njegovog krajnjeg odredita, ili
zato to je vreme ivota datagrama isteklo. Ili, ta e se desiti ako odredini host mora da uniti primljene
fragmente nekog datagrama ako u definisanom vremenu nije primio sve fragmente tog datagrama. Ovo su sam
oneki od problema koji mogu nastati u komunikaciji na IP nivou, a kojima se IP ne bavi niti poseduje
odgovarajue ugraene mehanizme kojima bi barem obavestio izvorni host o njihovom nastanku.
Takoe, IP ne poseduje podrku za postavljaje upita kojima bi se olakalo dijagnosticiranje kvarova i problema u
radu mree. Na primer, povremeno se javlja potreba za ispitivanjem da li je neki ruter ili host operativan, ili
potreba da se od hosta ili rutera pribave neke specifine informacije.
ICMP (Internet Control Message Protocol) je zamiljen kao kompenzacija za pomenute nedostatke IP-a. U
sutini, ICMP obezbeuje povratne informacije o problemima nastalim u mrei. U veini sluajeva ICMP
poruku alje ruter ili odredini host nazad izvornom hostu kao reakciju na problem nastao prilikom procesiranja
datagrama.
ICMP spada u grupu mrenih protokola (kao i IP). Meutim, njegove poruke se ne prosleuju direktno sloju
veze kao to bi se oekivalo. Umesto toga, ICMP poruke se najpre enkapsuliraju u IP datagrame pre nego to se
predaju niim slojevima (Sl. 2-61). Obzirom da se ICMP poruke prenose u IP datagramima, nihova isporuka nije
garantovana i njihova upotreba se ne moe smatrati pouzdanom.

19
Sl. 2-61 Enkapsulacija ICMP poruka.

20
3 Transportni sloj
IP je odgovoran za komunikaciju izmeu raunara (tzv. host-host komunikacija). Kao protokol mrenog sloja, IP
isporuuje poruku od izvornog do odredinog raunaru. Meutim, ovo je nepotpuna isporuka, jer esto nije
dovoljno samo isporuiti poruku odredinom raunaru, ve je treba i predati odgovarajuem procesu na
odredinom raunaru koji e je prihvatiti i obraditi. Drugim reima, konano odredite poruke nije raunar, ve
aplikacioni proces na odredinom raunaru (tzv. proces-proces komunikacija). Upravo ovaj poslednji korak u
isporuci poruka predstavlja odgovornost protokola transportnog sloja, kao to su UDP i TCP.
3.1 Portovi
Proces-proces komunikacija se uobiajno ostvaruje shodno klijent-server paradigmi: Proces na lokalnom hostu,
tzv. klijent, trai uslugu procesa na udaljenom raunaru, tzv. server. Tipino, oba procesa (klijent i server) imaju
isto ime. Tako, na primer, da bi smo od udaljene maine saznali tekui datum i vreme, potreban nam je Daytime
klijentski proces pokrenut na lokalnom i Daytime serverskom proces pokrenut na udaljenom hostu.
Savremeni operativni sistemi podravaju vie-korisnika (multiuser) i vie-programska (multiprogramming)
okruenja. Na udaljenom raunaru mogu se u isto vreme izvravati vie serverskih procesa, slino kao to se na
lokalnom raunaru mogu izvravati vie klijentskih procesa. Da bi se uspostavila komunikacija izmeu
odgovarajueg para procesa nepohodno je definisati:
- Lokalni host
- Lokalni proces
- Udaljeni host
- Udaljeni proces
Lokalni i udaljeni host su definisani IP adresama. Da bi se definisali procesi, neophodan je jo jedan
identifikator, koji se zove adresa servisa ili broj porta (tj. samo port). Kod TCP/IP, brojevi portova su celi
brojevi iz opsega 0 - 65,535.
Za identifikaciju klijentskog procesa koristi se broj porta koji se zove efmerni (ili privremeni) broj porta. Re
efemerni znai kratko-ivui i koristi se zato to je ivot klijenta po pravilu kratak. Efemerni brojevi porta su
vei od 1023. Tipino, klijetnskom procesu se prilikom pokretanja dodeljuje proizvoljno izabran jedan od
neiskorienih privremenih portova na klijentskom raunaru, kojeg on koristi za svolju identifikaciju prilikom
obraanja serverskom procesu. Kada klijentski proces zavri sa radom, njegov broj porta se oslobaa i moe biti
dodeljen nekom drugom klijetskom procesu. Server se takoe identifikuje brojem porta. Meutim, ovaj broj ne
moe biti proizvoljno izabran. Ako bi serverski raunar dodeljivao portove svojim serverskim procesima na
sluajan nain, klijentski procesi koji se izvravaju na klijentskim raunarima ne bi znali preko kog porta da
zatrae uslugu udaljenog serverskog procesa. Zato se kod TCP/IP za standardizovane servise koriste univerzalni,
tzv. dobro-poznati brojevi porta. Svi klijentski procesi znaju dobro-poznati port odgovarajueg serverskog
procesa. Na primer, dok se za identifikaciju Daytime klijentskog procesa moe koristiti broj porta 52,000,
Daytime serverski proces mora da koristi broj porta 13. Ovaj koncept je ilustrovan na Sl. 3-1.
Daytime Daytime
klijent server

52,000 13

UDP UDP

Podaci 13 52,000

13 52,000 Podaci

Sl. 3-1 Brojevi porta.

Dakle, IP adrese i brojevi porta imaju razliite uloge u izboru konanog odredita podataka. Odredina IP adresa
definie jedan od svih hostova na Interntu. Poto je host izabran, broj porta definie jedan od procesa na tom
konkretnom hostu.
Opsezi portova
Organizacija ICANN podelila je brojeve portova na tri opsega: dobro-poznati, registrovani i dinamiki (ili
privatni).
Dobro-poznati portovi - portovi iz opsega 0 - 1,023, koje dodeljuje (definie njihvou namenu) organizacija
ICANN.

21
Registrovani protovi - protovi iz opsega 1,024 - 49,151, koji nisu dodeljeni (organizacija ICANN nije definisala
njihvou namenu), ali koje neke druge organizacije ili firme mogu registrovati kod ICANN organizacije da bi se
predupredila dupliciranja.
Dinamiki portovi - portovi iz opsega 49,152 - 65,535, koji nisu ni dodeljeni niti registrovani. Oni mogu biti
korieni kao privremeni ili privatni brojevi portova. Organizacija ICANN-a preporuuje da se efemerni brojevi
porta biraju iz ovog opsega. Meutim, kod mnogih sistema ova preporuka nije ispotovana.
Adrese soketa
Kombinacija IP adrese i broja porta se naziva adresom soketa (Sl. 3-2). Klijentska adresa soketa jednoznano
definie klijentski, kao to serverska adresa soketa jednoznano definie serverski proces.

Sl. 3-2 Adresa soketa.

Da bi se koristile usluge transportnog sloja neophodan je par klijentska/serverska adresa soketa. Ova ukupno
etiri podatka su deo IP zaglavlja i UDP (odnosno TCP) zaglavlja. IP zaglavlje sadri IP adrese, dok UDP (TCP)
zaglavlje sadi brojeve portova.
3.2 UDP
UDP (User Datagram Protocol - Protokol korisnikih datagrama) je jednostavniji od dva standardna TCP/IP
transportna protokola. UDP omoguava udaljenim aplikacijama da razmenjuju enkapsulirane IP datagrame, bez
potrebe da uspostavljaju konekciju (beskonekcioni protokol). UDP prua samo osnovnu funkcionalnost potrebnu
za razmenu podataka na transportnom nivou. Konceptualno, jedina bitna razlika izmeu UDP datagrama i IP
datagrama je u tome to UDP sadri brojeve portova, to omoguava predajnoj aplikaciji da se obrati tano
odreenoj aplikaciji na odredinoj maini. UDP se ne bavi kontrolom toka, kontrolom greaka i retransmisijom
nakon prijema loeg datagrama, ba kako ni IP.
3.2.1 Korisniki datagram
Paketi koji se razmenjuju UDP protokolom nazivaju se korisnikim ili UDP datagramima. Korisniki datagram
se sastoji od 8-bajtnog zaglavlja i podataka. Format zaglavlja prikazan je na Sl. 3-3.

Sl. 3-3 UDP zaglavlje.

Source Port (Izvorni port): Broj porta aplikacionog procesa koji je kreirao poruku. Izvorni port je potreban u
situacijama kada udaljena aplikacija (kojoj se UDP datagram alje) treba da vrati odgovor. Proces koji vraa
odgovor kopira broj iz polja Source Port u polje Destination Port poruke koju vraa i na taj nain obezbeuje da
e poruka biti isporuena pravoj aplikaciji.
Destination Port (Odredini port). Broj porta udaljenog aplikacionog procesa kojem je poruka namenjena.
Total Length (Ukupna duina): Veliina UDP datagrama u bajtovima, ukljuujui i zaglavlje i podatke.
Minimalna duina UDP datagrama je 8 bajta (nema podataka). Obzirom na duinu ovog polja od 16 bita,
maksimalna duina UDP datagrama je 216 = 65,535 bajta. Meutim, zbog enkapsulacije u IP datagram,
maksimalna duina UDP datagrama je manja.
Checksum (Kontrolna suma): 16-bitno polje koje se koristi za proveru ispravnosti poruke.

Kontolna suma
Koncept kontrolne sume koji se primenjuje kod TCP/IP razmatran je u sekciji 2.4.4 zajedno sa opisom postupka
izraunavanja kontrolne sume kod IP protokola. Meutim, izraunavanje kontrolne sume kod UDP-a se donekle
razlikuje od onog koji se koristi kod IP protokola. Kod UDP-a, kontrolna suma ukljuuje: pseudo zaglavlje,
UDP zaglavlje i podatke.

22
 Sl. 3-4 Pseudo zaglavlje kod UDP-a.
Pseudo zaglavlje je deo zaglavlja IP datagrama u kojem je UDP datagram enkapsuliran ( Sl. 3-4). Ukljuivanje IP
zaglavlja u kontrolnu sumu UDP datagrama obezbeuje veu zatitu od isporuke UDP datagrama pogrenom
hostu ili pogrenom protokolu. Naime, ako je greka nastala u IP zaglavlju i to ba u polju za odredinu IP
adresu, i pri tome nije otkrivena kontrolnom sumom IP datagrama, UDP datagram, koji je sam za sebe ispravan,
bie isporuen pogrenom hostu. Polje za protokol iz IP zaglavlja je ukljueno da bi se obezbedilo da primljeni
paket pripada UDP-u. U polju za protokol zaglavlja IP datagrama koji enkapsulira UDP datagram, upisana je
vrednost 17. Ako se tokom prenosa ova vrednost promeni, datagram moe biti isporuen nekom drugom
protokolu (npr. TCP).
3.2.2 Nain rada
Beskonekcioni servis. UDP je beskonekcioni protokol. To znai da se svaki korisniki datagram poslat preko
UDP-a tretira kao nezavisni datagram. Izmeu razliitih UDP datagrama ne postoji veza, ak iako potiu od
istog izvornog i upueni su istom odredinom procesu. Korisniki datagrami nisu numerisani, a poto do
odredita mogu stii izvan redosleda, UDP nije u mogunosti da rekonstruie njihov prvobitni redosled. Takoe,
razmeni poruka izmeu dva udaljena procesa preko UDP-a ne prethodi uspostavljanje konekcije, niti se po
zavretku komunikacije konekcija raskida (kao to je to sluaj kod TCP-a). Posledica beskonekcionog naina
rada je i ta da proces ne moe koristiti UDP za slanje toka podataka i da pri tome oekuje da UDP automatski
vri pakovanje podataka u razliite datagrame. Umesto toga, svaka poruka koju proces alje mora biti dovoljno
kratka da moe stati u jedan UDP datagram.
Kontrola toka i kontrola greaka. UDP je jednostavan, nepouzdani transportni protokol. UDP ne poseduje
mehanizme za kotrolu toka, to znai da u samom protokolu ne postoji zatita od zaguenja prijemnika velikim
brojem poruka. Takoe, UDP, izuzev kontrolne sume, ne poseduje druge mehanizme za kontrolu greaka.
Poiljalac ne moe znati da li je poruka koju je poslao uspeno preneta, ili je moda izgubljena ili duplicirana u
prenosu. Prijemnik koji proverom kontrolne sume detektuje greku, jednostavno unitava datagram.
Nepostojanje podrske za kontrolu toka i kontrolu greaka znai da je na procesu koji koristi UDP da rei ove
probleme, u meri koja je njemu potrebna.
Enkapsulacija korisnikih datagrama
Proces koji alje poruku preko UDP-a, prosleuje poruku UDP-u zajedno sa parom adresa soketa i informacijom
o duini podataka (Sl. 3-5). UDP softver dodaje podacima UDP zaglavlje i tako kreiran korisniki datagram
prosleuje IP-u zajedno sa adresama soketa. IP dodaje svoje zaglavlje, postavljajui vrednost 17 u polje za
PROTOCOL, to treba odredinoj strani da ukae da podaci potiu od UDP protokola. Tako formiran IP
datagram se prosleuje sloju veze gde se pakuje u okvir, a zatim se isporuuje fizikom sloju koji kodira bitove
okvira u elektrine ili optike signale i alje ih udaljenoj maini.
Kada poruka stigne do odredinog hosta, fiziki sloj dekodira signal u niz bitova koje prosleuje sloju veze. Sloj
veze proverava ispravnost primljeniog okvira i pod uslovom da je okvir ispravan odstranjuje svoje zaglavlje, a
enkapsulirani IP datagram predaje IP-u. IP obavlja svoju proveru datagrama (na bazi kontrolne sume) i ako
nema greaka, odstranjuje IP zaglavlje, a korisniki datagram prosleuje UDP-u zajedno sa IP adresama
poiljaoca i primaoca. UDP koristi svoju kontrolu sumu za proveru korisnikog datagrama. Ako je kontrolna
suma ispravna, UDP odstranjuje svoje zaglavlje i podatke sadrane u korisnikom datagramu, zajedno sa
adresom soketa poiljaoca isporuuje prijemnom procesu. Adresa soketa je potrebna procesu u sitacijama kada
se od njega oekuje da odgovori na prmljenu poruku.

23
Sl. 3-5 Enkapsulacija i deenkapsulacija korisnikog datagrama.
Multipleksiranje i demultipleksiranje
Na hostu na kome se izvrava TCP/IP postoji samo jedan UDP. Meutim, moe postojati nekoliko aplikacionih
procesa koji u isto vreme ele da koriste usluge UDP-a. Da bi se razreile ovakve situacije, na nivou UDP-a
koristi se koncept multipleksiranja i demultipleksiranja (Sl. 3-6).

Sl. 3-6 Multipleksiranje i demultipleksiranje.

Multipleksrianje se koristi na strani poiljaoca kada vie od jednog aplikacionog procesa eli da poalje
korisnike datagrame (odgovara relaciji vie-prema-jedan: vie aplikacionih procesa, jedan UDP). UDP prihvata
poruke od razliitih procesa (koji se identifikuju svojim brojevima porta), svakoj poruci pridodaje zaglavlje i
kreirani korisniki datagram predaje IP-u.
Demultipleksiranje se koristi na strani prijemnika kada postoji vie od jednog aplikacionog procesa koji oekuju
korisnike datagrame (odgovara relaciji jedan-prema-vie: jedan UDP, vie aplikacionih procesa). UDP prima
korisniki datagram od IP-a. Nakon provere greaka i odstranjivanja zaglavlja, UDP isporuuje poruku
odgovarajuem aplikacionom procesu shodno broju porta.
3.2.3 Primene
Jedna oblast gde je UDP naroito koristan su izvesne klijet-server konfiguracije. esto, klijent alje kratak upit
serveru i oekuje kratak odgovor. Ukoliko se upit ili odgovor izgube u prenosu, klijent jednostavno eka neko
vreme i pokuava ponovo. Primer aplikacije koja koristi UDP na ovaj nain je ve ranije pomenut Daytime
servis. Program kome je potrebna informacija o tekuem vremenu alje UDP datagram sa zahtevom Daytime
serveru. Server odgovara UDP datagramom sa upisanim tekuim datumom i vremenom. Da bi se obavila ova
prosta konverzacija, nije potrebna nikakva prethodna priprema ili uspostavljanje konekcije, dovoljno je
razmeniti dve kratke poruke.
Druga oblast primene UDP protokola su real-time multimedijalne aplikacije, kao to su: Internet radio, Internet
telefonija, muzika-na-zahtev, video konferencije, video-na-zahtev i druge. Zajednika karakteristika svih ovih
aplikacija je prenos kontinualnog toka digitalizovanog zvuka i/ili videa. Na predajnoj strani, zvuk (ili video) se
konvertuje u niz digitalnih odmeraka. Odmerak je binarni broj koji ukazuje na trenutnu amplitudu signala.

24
Odmerci se generiu frekvencijom koja je dovoljno visoka da omogui vernu reprodukciju (npr. 44kHz za
muziku). Odgovarajui proces deli generisani tok odmeraka na segmente (od po npr. 500 odmeraka) i pakuje ih
u UDP datagrame koje alje prijemnoj strani. Na taj nain, brzi tok odmeraka, konvertovan je u tok UDP
datagrama. Odgovarajui proces na prijemnoj strana dobija UDP datagrame, izdvaja odmerke i reprodukuje ih
tempom koji odgovara frekvenciji odmeravanja. U prenosu UDP datagrama moe se ispoljiti diter, a pojedini
datagrami mogu biti izgubljeni u prenosu, to naruava kvalitet reprodukcije. Meutim, s obzirom da se radi o
real-time toku (neprekidnom) retransmisija izgubljenih datagrama nije mogua (jer nema vremena za ekanje),
kao ni neka stroga kontrola protoka. Iz tog razloga za pomenute aplikacije se koristi UDP (a ne TCP), a
aplikaciji se preputa da prevazie (ublai) probleme koji nastaju gubitkom ili kanjenjem paketa. Na primer,
umesto da se trai ponovno slanje izgubljenog paketa, aplikacija na prijemu moe sama da pokua da
rekonstruie deo zvuka koji nedostaje. Takoe, umesto da odmerke odmah reprodukuje moe privremeno da ih
smeta u bafer, ime e uneti izvesno kanjenje u reprodukciji, ali zato e moi da tolerie vee kanjenje
pojedinih paketa, koje e kada stignu da umetne na pravo mesto u baferu.
3.3 TCP
TCP (Transmission Control Protocol - Protokol za kontrolu prenosa) je konekcioni, pouzdani, proces-proces
transportni protokol koji prua puni transportni servis udaljenim aplikacijama. TCP je proces-proces
(programprogram) protokol koji, kao i UDP, koristi brojeve portova. Meutim, za razliku od UDP-a, TCP je
konekcioni protokol, koji radi prenosa podataka izmeu dva udaljena procesa kreira virtuelnu konekciju. TCP
sprovodi kontrolu protoka i kontrolu greaka, a projektovan je tako da se moe dinamiki prilagoditi
promenljivim karakteristikama Interneta i odri pouzdanu vezu ak i u sluajevima pojave raznih vrsta otkaza u
mrenoj infrastrukturi.
3.3.1 Servisi
Proces-proces komunikacija
Slino UDP-u, TCP omoguava komunikaciju od procesa do procesa korienjem 16-bitnih brojeva portova za
identifikaciju procesa. Opsezi portova (dobro-poznati, registrovani i dinamiki) su identini kao kod UDP-a.
Orijentacija na tok
Za razliku od UDP-a, TCP je protokol orijentisan na tok. Kod UDP-a, proces (aplikacioni program) alje poruke
koje imaju tano definisane granice. Svakoj takvoj poruci UDP dodaje svoje zaglavlje i isporuuje je IP-u.
Poruke se zovu korisniki datagrami, a svaka od njih u konanom obliku postaje jedan IP datagram. UDP, kao ni
IP, ne vide bilo kakvu vezu izmeu datagrama.
Sa druge strane, TCP omoguava predajnom procesu da alje, a prijemnom procesu da prima podatke u vidu
kontinualnog toka bajtova. TCP kreira okruenje u kojem izgleda kao da su dva procesa spojena nekom
imaginarnom cevi, kroz koju teku njihovi podaci (Sl. 3-7). Predajni proces generie (upisuje) tok bajtova, a
prijemni proces konzumira (ita) bajtove iz cevi.

Sl. 3-7 Tok bajtova.

Predajni i prijemni baferi
Obzirom da predajni i prijemni procesi ne moraju da upisuju ili itaju podatke istom brzinom, TCP-ju su
neophodni baferi za privremeno uvanje podataka. Postoje dva takva bafera: predajni i prijemni bafer. (Kasnije u
ovom poglavlju videemo da su ovi baferi takoe potrebni za realizaciju mehanizama za kontrolu protoka i
kontrolu greaka.) Baferi se realizuju u vidu cirkularnog memorijskog polja 1-bajtnih lokacija ( Sl. 3-8). Radi
jednostavnosti, kapacitet oba baferi sa slike je 20 bajtova; u realnosti, a zavisno od implementacije, veliina TCP
bafera je vie stotina ili vie hiljada bajtova.

25
 Sl. 3-8 Predajni i prijemni bafer.
Sl. 3-8 prikazuje prenos podataka u jednom smeru. Na predajnoj strani, uoavamo tri sekcije memorijskih
lokacija. Bela sekcija odgovara slobodnim (nepopunjenim) lokacijama, koje su raspoloive za upis novih
bajtova. Tamna oblast sadri bajtove koji su poslati ali iji prijem suprotna strana jo uvek nije potvrdila. TCP
uva poslate bajtove u baferu sve dok ne budu protvreni. Siva (osenena) oblast sadri bajtove koji tek treba da
budu poslati. Nakon to su bajtovi iz tamne sekcije potvreni, odgovarajue lokacije se oslobaaju i postaju
bele.
Rad bafera na prijemnoj strani je jednostavniji. Cirkularni bafer je podeljen na dve sekcije (prikazane kao bela
i siva sekcija). Bela sekcija sadri prazne lokacije koje se raspoloive za upis novih bajtova koji stiu sa mree.
Siva sekcija sadri primljene bajtove koji prijemni proces moe da preuzme (konzumira). Kada prijemni proces
proita bajt, odgovarajua lokacija se osobaa i postaje bela.
TCP Segmenti
Iako baferi reavaju problem usaglaavanja brzine generisanja i konzumiranja podataka, neophodan je jo jedan
korak pre nego to se podaci poalju kroz mreu. Naime, IP sloj, kao mreni servis koji stoji na raspolaganju
TCP-ju, prenosi podatke u paketima, a ne kao tok bajtova. Iz tog razloga, TCP grupie odreeni broj sukcesivnih
bajtova u paket tzv. segment. TCP dodaje zaglavlje svakom segmentu i isporuuj ga IP sloju. Segmenti se
enkapsuliraju u IP datagrame i alju. Za prijemni proces, celokupna ova procedura je transparentna (nevidljiva).
Kasnije u ovom poglavlju, videemo da segmenti mogu stii na predajnu stranu izvan redosleda, mogu biti
izgubljeni u prenosu, pokvareni i ponovo poslati. TCP reava sve ove neregularne situacije bez bilo kakvog
uea ili pomoi prijemnog procesa. Na Sl. 3-9 je prikazano kako se bajtovi uzimaju iz predajnog bafera, pakuju
u segmente, prenose na prijemnu stranu, i tamo raspakuju i upisuju u prijemni bafer.

Sl. 3-9 TCP segmenti.

Puna dupleksna komunikacija
TCP nudi uslugu pune dupleksne (full-duplex) komunikacije, gde podaci mogu da teku u oba smera u isto
vreme. To znai da svaki TCP poseduje oba bafera (predajni i prijemni), a segmenti se prenose u oba smera.

26
Konekcioni servis
TCP je protokol konekcionog tipa. Kada proces na maini A eli da razmenjuje podatke sa procesom na maini
B, deava se sledee:
1. Dva TCP-ja uspostavljaju (otvaraju) konekciju.
2. Podaci se razmenjuju u oba smera.
3. Konekcija se zatvara.
Napomenimo da se ovde radi o virtuelnoj, a ne fizikoj konekciji. TCP segment se enkapsulira u IP datagram
koji na odredite moe stii izvan redosleda, moe se izgubiti ili duplicirati u prenosu. Drugim reima, ne postoji
fizika konekcija koja bi garantovala isporuku segmenata u pravilnom redosledu, ve TCP kreira okruenje
orijentisano na tok i na sebe preuzima odgovornost za isporuku bajtova u prvobitnom redosledu.
Pouzdani servis
TCP je pouzdani transportni protokol. Pouzdanost se postie mehanizmom potvrivanja. Prijemna strana
potvruje primljene podatke, a predajna ponovo alje (retransmituje) podatke koji nisu potvreni u nekom
definisanom vremenu.
3.3.2 Mehanizmi
TCP obezbeuje servise (pomenute u prethonoj sekciji) korienjem nekoliko bazinih mehanizama koji e
ukratko biti opisani u ovoj sekciji.
Redni brojevi
TCP numerie sve bajtove podataka koji se prenose putem uspostavljene konekcije. Numerisanje je nezavisno u
oba smera. Uvek kada dobije bajt podataka od predajnog procesa, TCP smeta bajt u predajni bafer i dodeljuje
mu redni broj. Numerisanje ne mora obavezno da pone od 0. Umesto toga, za numerisanje prvog bajta TCP
generie sluajni broj iz opsega 0 - 2 32. Ako je generisan broj x, redni broj prvog bajta podataka bie x+1.
Numerisanje bajtova je kljuna osobina TCP-ja, koja dominira svim aspektima protokola. Redni brojevi se
koriste za kontrolu protoka i kontrolu greaka.
Iako TCP vodi evidenciju o segmentima koje alje i prima, u zaglavlju segmenta ne postoji polje za redni broj
segmenta. Umesto toga, zaglavlje segmenta sadri dva polja koja se zovu: Sequence Number (SEQ broj) i
Acknowledgement Number (ACK broj). Zajedniko ime za ova dva polja je broj bajta, a ne broj segmenta.
Sequence Number
Radi slanja kroz mreu, TCP grupie bajtove u segmente i svakom segmentu dodeljuje Sequence Number jednak
rednom broju prvog bajta u segmentu.
Acknowledgement Number
Kod TCP-ja komunikacija je tipa puni-dupleks: nakon to je konekcije uspostavljena, obe strane mogu da alju i
primaju podatke u isto vreme. Svaka strana nezavisno numerie svoje bajtove (one koje alje), obino, poev od
rezliitih poetnih brojeva bajta. SEQ broj u svakom smeru ukazuje na prvi bajt sadran u segmentu. Takoe,
svaka strana koristi Acknowledgement Number (ACK broj) da bi potvrdila bajtove koje je primila. Meutim,
ACK broj definie broj sledeeg bajta kojeg strana oekuje da primi. Dodatno, ACK broj je kumulativan. To
znai da strana koja alje potvrdu, uzima broj poslednje ispravno primljenog bajta, uveava ga za 1 i dobijenu
sumu koristi kao ACK broj. Drugim reima, prijemnik ne potvruje eksplicitno svaki primljeni bajt, ve se
potvrda odnosi na sve bajtove sa rednim brojevima manjim od ACK broja. (ACK broj jednak X znai da su svi
bajtovi do X, ali ne i X, uspeno primljeni). Kontrola protoka
TCP se, za razliku od UDP, bavi kontrolom protoka. Kod TCP-ja, prijemnik je u mogunosti da kontrolie tempo
kojim predajnik alje podatke. Kontrola protoka je neophodna kako prijemnik ne bi bio pretrpan podacima koje
predajnik alje isuvie velikom brzinom. Zahvaljujui rednim brojevima, TCP je u mogunosti da sprovodi
kontrolu protoka do nivoa bajtova.

Kontrola greaka
Mehanizam za kontrolu greaka je neophodan da bi se obezbedio pouzdani prenos. Od TCP-ja se oekuje da na
prijemnoj strani rekonstruie prvobitni tok bajtova, bez obzira na eventualne greke u segmentima, dupliciranje
ili gubitak segmenata. Iako se detekcija greaka obavlja na nivou segmenata, koncept kontrole greaka je, kao i
kontrola protoka, bajtovski orijentisan.
Kontrola zaguenja
TCP, za razliku od UDP, vodi rauna o zaguenjima u mrei. Koliinu podataka koje predajnik alje, ne
kontrolie samo prijemnik (kotrola protoka), ve je odreena i nivoom zaguenja mree.
3.3.3 Segment
TCP paketi se nazivaju segmentima. Format segmenta je prikazan na Sl. 3-10. Segment poinje 20-bajtnim
zaglavljem fiksnog formata. Nakon fiksnog dela zaglavlja slede polje za opcije (koje nije obavezno), a zatim i
podaci (maksimalno 65535 - 20 - 20 = 65495. Prvo -20 zbog TCP, a drugo zbog IP zaglavlja.) Segmenti bez
podataka su dozvoljeni i esto se koriste za provrivanje i razmenu drugih upravljakih informacija.

27
Slede kratka objanjenja znaenja polja TCP zaglavlja.
Source Port (Izvorni port, 16 bita). Definie broj porta aplikacionog programa na hostu koji alje segment.
Destination Port (Odredini port, 16 bita). Definie broj porta aplikacionog programa na hostu koji prima
segment.
Sequence Number (Redni broj, 32 bita). Sadri SEQ broj, tj. redni broj dodeljen prvom bajtu podataka
sadranih u segmentu. Kao to je ve reeno, TCP je orijentisan na tok. Da bi se obezbedila striktna kontrola
toka i kontrola greaka, svaki bajt koji se prenosi mora biti numerisan. SEQ broj ukazuje na bajt iz toka bajtova
koji je kao prvi sadran u segmentu. U toku uspostavljanja konekcije, svaka strana nezavisno, na sluajan nain,
generie inicijalni SEQ broj.
Acknowledgment Number (Broj potvrde, 32 bajta). Sadri ACK broj, tj. redni broj koji je dodeljen prvom
narednom bajtu podataka kojeg poiljalac segmenta oekuje da primi od druge strane. Ako je poiljalac segment
uspeno primio bajt sa rednim brojem x, tada e ACK broj biti jednak x+1. Ovo polje je vaee ako je bit ACK
(kasnije u zaglavlju) postavljen na 1. Napomenimo da isti segment moe da sadri i podatke i potvrdu za
prethodno primljene podatke.
HLEN (Veliina zaglavlja, 4 bita). Definie broj 32-bitnih rei u TCP zaglavlju. Najvea 4-bitna vrednost je 15,
to znai da TCP zaglavlje moe sadrati najvie 15*4 = 60 bajta (zajedno sa opcijama). Poto su 20 bajta
fiksna, duina polja za opcije moe biti najvie 40 bajta.
Reserved (Rezervisano, 6 bita). Deo zaglavlja rezervisan na neku buduu namenu. Za sada, ovi bitovi moraju
biti postavljeni na 0.
Control bits (Kontrolni bitovi, 6 bita). Sadri 6 bita ili flaga od kojih svaki ima neku posebnu namenu u
procesu kontrole toka, uspostavljanja i raskidanja konekcije, kao i definisanju naina prenosa podataka.
Potpunije objanjenje uloge kontrolnih bitova sledi kasnije u ovom poglavlju, kada se budemo bavili detaljinijm
opisom rada TCP-ja.
T. 3-1 Kontrolni bitovi.
Flag Opis
UGR Vrednost polja Urgent Pointer je validna.
ACK Vrednost polja Acknowledgment Number je validna.
PSH Push podataka.
RST Konekcija mora biti resetovana.
SYN Sinhronie redne brojeve u toku uspostavljanja konekcije.
FIN Raskida konekciju.
Window Size (Veliina prozora, 16 bajta). Definie veliinu tzv. prozora, u bajtovima. Ova vrednost se obino
naziva prozorom prijemnika (rwnd) i predstavlja trenutnu veliinu slobodnog prostora u prijemnom baferu
poiljaoca segmenta. Informie suprotnu stranu koliko bajtova, poev od broja potvrde, moe da poalje.
Veliina prozora 0 je legalna i ukazuje drugoj strani da je host, poiljalac segmenta, u takvom stanju da trenutno
nije u mogunosti da prima nove podatke (moda kasnije).
Checksum (Kontrolna suma, 16 bita). Polje za kontrolnu sumu. Procedura za izraunavanje kontrolne sume za
TCP je u osnovi identina onoj koja se primenjuje kod UDP-a. Meutim, kod UDP-a, kontrolna suma je
opciona, dok je kod TCP-ja obavezna. Radi izraunavanja kontrolne sume zaglavlju segmenta se dodaje istio
pseudo zaglavlje kao i kod UDP-a (Sl. 3-11).

28
 Sl. 3-11 Pseudo zaglavlje kod TCP-ja.
Urgent Pointer (Pointer na urgentne podatke, 16 bajta). Sadraj ovog polja je validan samo ako je bit
URG=1. Koristi se kada segment sadri urgentne (hitne) podatke. Definie broj koji kada se sabere sa SEQ
brojem daje redni broj prvog urgentnog bajta sadranog u sekciji za podatke segmenta. (Vie detalja kasnije u
poglavlju).
Options (Polje za opcije, 0 - 40 bajtova). Prua mogunost da se zaglavlje proiri dodatnim informacijama.
(Vie detalja o opcijama kasnije u poglavlju.)
Enkapsulacija segmenta
TCP segment se enkapsulira u IP datagram, koji se dalje enkapsulira u okvir nivoa veze, kao to je prikazano na
Sl. 3-12.
Zaglavlj IP TCP
e okvira zaglavlje segment

Sl. 3-12 Enkapsulacija TCP segmenta.

3.3.4 Konekcija
TCP je konkcioni protokol. To znai da se izmeu izvora i odredita uspostavlja virtuelna putanja za prenos
svih segmenata koji e biti razmenjivani u komunikaciji izmeu dve strane. Virtuelna putanja olakava proces
potvrivanja, kao i retransmisiju oteenih ili izgubljenih segmenata. Moe se postaviti pitanje, kako TCP moe
biti konekcioni protokol, ako koristi usluge IP-a, koji je, kao to znamo, beskonekcioni protokol. Sutina je u
tome da je TCP konekcija virtuelna, a ne fizika, odnosno da TCP radi na viem nivou apstrakcije od IP-a. TCP
koristi usluge IP-a samo za isporuku pojedinanih segmenata prijemniku, dok sam obavlja kontrolu konekcije.
Ako se segment izgubi ili oteti u prenosu, TCP e inicirati njegovu retransmisiju. IP nije svestan retransmisije.
Ako segment stigne izvan redosleda, TCP e ga privremeno zadrati sve dok ne stignu svi segmenti koji
nedostaju. Ponovo, IP nije svestan ovog preureivanja.
Kod TCP-ja, konekcioni prenos se ostvaruje u tri faze: uspostavljanje konekcije, prenos podataka i raskidanje
konekcije.
Uspostavljanje konekcije
TCP komunikacija je tipa puni dupleks. Dve maine koje su u TCP vezi u mogunosti su da jedna drugoj
istovremeno alju segmente. To znai da obe strane moraju uestvovati u inicijalizaciji komunikacije kako bi od
druge strane dobile odobrenje za slanje podataka.
Trostepeno usaglaavanje
TCP konekcija se uspostavlja procedurom koja se zove trostepeno usaglaavanje (eng. three-way handshaking).
Pretpostavimo da aplikacioni program (klijent), eli da uspostavi TCP konekciju sa nekim drugim aplikacionim
programom (server). Celokupan proces zapoinje server. Serverski program obavetava lokalni TCP da je
spreman da prihvati konekciju. Drugim reima, server od svog TCP-ja zahteva pasivno otvaranje konekcije
(eng. passive open). Pasivno otvaranje ne uspostavlja konekciju, ve samo daje dozvolu TCP-ju da prihvati
zahtev za uspostavljanje konekcije koji eventualno stigne od neke udaljene aplikacije.
Klijentski program, sa druge strane, izdaje zahtev lokalnom TCP-ju, za aktivno otvaranje konekcije (eng. active
open). Klijent zapravo saoptava TCP-ju da eli da ostvari konekciju se konkretnim otvorenim serverom. U
ovom trenutku, TCP na klijetnskoj strani zapoine proceduru trostepenog usaglaavanja ( Sl. 3-13). Na Sl. 3-13 su
prikazane dve vremenske ose, jedna za klijentsku, a druga za serversku stranu. Segmenti koji se razmenjuju
tokom uspostavljanja konekcije prikazani su delovima svojih zaglavlja koji su bitni u odgovarajuoj fazi ove
procedure.

29
Sledi opis svakog od tri koraka:
1. Klijent alje prvi segment, tzv. SYN segment, u kojem je flag SYN postavljen (tj. ima vrednost 1).
Ovaj segment slui za sinhronizaciju rednih brojeva. Klijent sluajno bira prvi redni i alje ga serveru (kao
vrednost polja Sequence Number). Ovaj redni broj se zove inicijalni redni broj (ISN). Uoimo da SYN segment
ne sadri ACK broj (bit ACK=0), niti definie veliinu prozora. SYN segment je kontrolni segment i ne sadri
bilo kakve podatke. Meutim, SYN segment troi jedan redni broj. Kada prenos podataka bude poeo, redni
broj za prvi bajt podataka e biti za 1 vei od ISN broja. (Moemo zamisliti kao da SYN segment, iako ne
prenosi ni jedan fiziki bajt, ipak, sadri jedan imaginarni bajt.
2. Drugi segment (tzv. SYN+ACK segment) alje server. Kod ovog segmenta postavljena su dva flaga:
SYN i ACK. Segment ima dvostruku ulogu. Prvo, on ima ulogu SYN segmenta za komunikaciju u
suprotnom smeru. Naime, server koristi SYN+ACK segment da bi inicijalizovao redni broj za prenos
bajtova od servera do klijenta. Drugo, server koristi SYN+ACK segment da bi potvrdio prijem
klijentovog SYN segmenta. Iz tog razloga, u ovom segmentu je postavljen flag ACK, a polje
Acknowlegmnet Number sadri sledei redni broj koji server oekuje da primi od klijenta. S obzirom da
segment sadri potvrdu (ACK=1), u njemu mora biti definisana i veliina prozora, rwind.
3. Trei segment (tzv. ACK segment) alje klijent. Ovim segmentom klijent podvruje poetni redni broj
servera. Flag ACK je postavljen, a polje Acknowlegmnet Number sadri redni broj prvog oekivanog
bajta. Uoimo da je redni broj, sadran u polju Sequence number, ACK segmenta identian ovome iz
SYN segmenta, to znai da ACK segment ne troi ni jedan redni broj. Klijent, takoe, mora da definie
veliinu prozora servera. Kao i prethodna dva, ACK segment sadri samo zaglavlje, ali ne i podatke.
Prenos podataka
Nakon to su uspostavile konekciju, dve udaljene aplikacije mogu da razmenjuju podatke. Klijent i server mogu
slati podatke i potvrde u oba smera. Podaci i potvrede koje se prenose u istom smeru mogu se prenositi istim
segmentom. Za podvrivanje primljenih podataka koristi se flag ACK i polje Acknowledgment number iz
zaglavlja, a za slanje podataka sekcija za podatke segmenta. Na Sl. 3-14 je prikazan primer prenosa podataka.
Pretpostavka je da je konekcija prethodno uspostavljena. Klijent prvo alje 2000 bajtova podataka podeljenih u
dva segmenta. Zatim, server alje 2000 bajtova u jednom segmentu. Konano, klijent alje jo jedan segment.
Prva tri segmenta prenose i podatke i potvrde, dok poslednji segment prenosi samo potvrdu (zato to nema vie
podataka za slanje). Treba obratiti panju na SEQ i ACK brojeve. Takoe, uoima da je u segmentima koje alje
klijent postavljen flag PSH (push), to predstavlja indikaciju serveru da primljene podatke treba da isporui
serverskom procesu odmah nakon prijema (bez zadravanja u prijemnom baferu). U segmentu koji server alje
klijentu, flag PSH nije postavljen.
Klijent Server

30
 Vreme Vreme
Sl. 3-14 Prenos podataka.
Push operacija
Kao to znamo, predajni TCP koristi bafer za privremeno skladienje podataka koje predajni aplikacioni
program eli da poalje. Predajni TCP uzima podatke iz bafera i pakuje ih u segmente, iju veliinu sam bira.
Ako aplikacioni program upie u predajni bafer mali broj bajtova, nedovoljan da se popuni jedan segment
optimalne veliine, TCP e saekati jo neko vreme oekujui da e aplikacija upisati nove podatke. Sa druge
strane, prijemni TCP smeta primljene podatke u prijemni bafer i isporuuje ih prijemnom aplikacionom
programu onda kada je aplikacioni program spreman da prihvati nove podatke ili onda kada je to zgodno
prijemnom TCP-ju. Na primer, prijemni TCP moe da saeka da se prijemni bafer napuni do izvesne mere, pre
nego to podatke preda prijemnoj aplikaciji. Ovakav tip fleksibilnosti poveava efikasnost TCP komunikacije.
Meutim, postoje situacije kada podatke treba isporuiti prijemnoj aplikacije to je pre mogue. To je tipino
sluaj kod interaktivnih aplikacija. Na primer, klijent alje serveru kratku tekstualnu komandu unetu preko
tastature na koju oekuje brzi odgovor. ekanje TCP da se u baferima prikupi dovoljan broj bajtova unelo bi
neprihvatljivo kanjenje.
TCP je u stanju da prevazie prethodno opisan problem. Aplikacioni program na predajnoj strani moe zahtevati
tzv. push operaciju. To znai da predajni TCP nee ekati na nove podatke, ve e odmah po upisu podataka u
predajni bafer kreirati i poslati segment. Pri tome, u segmentu kojeg alje, predajni TCP postavlja flag PSH kako
bi obavestio prijemni TCP da segment nosi podatke koje treba isporuiti prijemnoj aplikaciji to je pre mogue.
Urgentni podaci
TCP je protokol orijetisan na tok. Drugim reima, aplikacija predaje podatke TCP-ju u vidu kontinualnog toka
bajtova. Svaki bajt podataka ima svoju tanu poziciju u ovom toku. Meutim, postoje situacije kada aplikacioni
program ima potrebu da poalje urgentne bajtove. To znai da predajna aplikacija eli da izvesni podaci budu
proitani izvan redosleda iz prijemnog bafera i to pre predati prijemnom aplikacionom programu.
Razmotrimo sledei primer. Predajni aplikacioni program alje podatke na obradu prijemnom aplikacionom
programu. Po prijemu prvih razultata obrade, predajna aplikacija zakljuuje da je sve bilo pogreno i da je
najbolje prekinuti dalju obradu. Meutim, predajna aplikacija je u meuvremenu ve poslala veu koliinu
podataka. Ako poalje komandu za prekid procesa, npr. Ctrl-C, ova dva karaktera e se nai na kraju prijemnog
bafera i bie isporueni prijemnog aplikaciji tek kada ona obradi sve prehodno pogreno poslate bajtove.
Reenje prethodnog problema se sastoji u slanju segmenta sa postavljenim flagom URG. Predjani aplikacioni
program saoptava predajnom TCP-ju da su podaci koje mu predaje urgentni. Predajni TCP kreira segment i na
poetak polja za podatke umee urgentne podatke. Preostali prostor u polju za podatke moe biti ispunjen
normalnim podacima. Polje Urgent pointer iz zaglavlja segmenta ukazuje kraj uregnetnih i poetak
normalnih podataka.
Kada prijemni TCP primi segment sa postavljenim flagom URG, on izdvaja urgentne podatke iz segmenta
(korienjem vrednosti iz polja Urgent pointer) i isporuuje ih, izvan redosleda, prijemnom aplikacionom
programu.
Zatvaranje konekcije
Konekciju moe da zatvori bilo koja od dve strane ukljuene u razmenu podataka (klijenti ili server). Veina
aktuelnih implementacija TCP protokola nudi dve opcije za zatvaranje konekcije: trostepeno usaglaavanje i
etvorostepeno usaglaavanje sa opcijom za zatvaranje konekcije u jednom smeru (tzv. polu-zatvaranje).

31
zatvaranje

Pasivno

32
 zatvaranje

Vreme Vreme Vreme

(a) (b)
Sl. 3-15 Zatvaranje konekcije: (a) trostepeno usaglaavanje; (b) polu-zatvaranje.
Aktivno
Trostepeno usaglaavanje
Postupak zatvaranja konekcije postupkom trostepenog usaglaavanja ilustrovan je na Sl. 3-15(a).
1. U normalnim situacijama, klijentski TCP, nakon to od klijentskog procesa primi komandu za
zatvaranje konekcije, alje prvi segment (tzv. FIN segment) u kojem je postavljen flag FIN.
Napomenimo da FIN segment moe sadrati i poslednje podatke koje klijent alje serveru, ali moe biti
i kontrolni segment (segment koji ne sadri podatke), kao to je to sluaj na Sl. 3-15(a). Ako se radi o
kontrolnom segmentu, FIN segment troi samo jedan redni broj.
2. Nakon prijema FIN segmenta, serverski TCP obavetava serverski proces da klijent trai zatvaranje
konekcije, a zatim alje drugi segment (tzv.Server FIN + ACK segment) kojim potvruje prijem FIN
segmenta i u isto vreme objavljuje zatvaranje konekcije u dugom smeru. Ovaj segment takoe moe
sadrati i poslednji odeljak podataka koje server alje klijentu. Ako ne sadri podatke, FIN+ACK
segment troi samo jedan redni broj.
3. Klijentski TCP alje poslednji segment, ACK segment, kojim potvruje FIN segment dobijen od
serverskog TCP-ja. Ovaj segment sadri ACK broj koji je za 1 vei od SEQ broja iz FIN segmenta.
Ovaj segment ne moe sadrati podatke i ne troi redne brojeve. Polu-zatvaranje
Kod TCP-ja, dozvoljeno je da jedna strana prestane sa slanjem ali nastavi sa prijemom podataka. Ovakva
situacija se naziva polu-zatvaranjem konekcije i obino je inicirana od strane klijenta. Na Sl. 3-15(b) je pirkazan
primer polu-zatvaranja. Klijent zatvara svoj smer konekciju (u smeru slanja svojih podataka) slanjem FIN
segmenta. Server prihvata polu-zatvaranje slanjem ACK segmenta (a ne FIN+ACK, kao kod obostranog
zatvaranja). Meutim, server moe nastaviti da alje svoje podatke. Server, kada vie nema podataka za slanje,
zatvara svoj smer konekcije slanjem FIN segmenta kojeg klijent potvruje ACK segmentom.
Nakon polu-zatvaranja konekcije, podaci se mogu i dalje prenositi od servera do klijenta, a potvrde od klijenta
do servera. Meutim, kijent ne moe vie slati nove podatke serveru. Obratimo panju na redne brojeve. Iako je
klijent primio redni broj y-1 i oekuje y, redni broj servera je jo uvek y-1. Kada je konekcija konano zatvorena,
SEQ broj poslednjeg ACKKlijent
segmenta je jo uvek x, zato to nakon polu zatvaranja klijent nije potroio ni jedan
redni broj.
Resetovanje konekcije
Flag RST se koristi kada TCP, sa bilo koje strane konekcije, eli da odbije zahtev za uspostavljanje konekcije, ili
trenutno prekinute otvorenu konekciju.
Odbijanje konekcije. Pretpostavimo da je TCP na serverskom hostu dobio zahtev za usopstavljanje konekcije na
nepostojeom portu (tj. na portu koji na tom hostu nije otvoren za sluanje). U takvoj situaciji serverski TCP
odbija zahtev slanjem klijentu segent sa postavljenim bitom RST.
Prekidanje konekcije. U toku trajanja konekcije mogu nastati izvesne neregularne situacije, kao to je npr.
razdeavanje rednih brojeva, nakon kojih nije mogue nastaviti normalnu komunikaciju. TCP koji primeti takvu
situaciju, kada nije mogue ni sprovesti regularnu proceduru zatvaranja konekcije, nasilno prekida konekciju
slanjem TCP-ju sa druge strane segmenta sa postavljenim bitom RST.
Zatvaranje pasivne konekcije. TCP na jednoj od dve strane konekcije, moe primetiti da je druga strane pasivna
neko due vreme (ne alje podatke), to moe biti simtom neregularnog rada aplikacionog programa na
udaljenom hostu koji koristi konekciju. U takvoj situaciju, TCP, slanjem RST segment, moe da uniti
konekciju.
3.3.5 Dijagram stanja K
C K
CA
+
N
IF
Da bi se olakalo praenje razliitih dogaaja i brojnih izuzetnih sitacija koje se mogu desiti u toku
N

uspostavljanja konekcije, prenosa podataka i zatvaranja konekcije, TCP softver je realizovan u vidu konanog
automata (FSM Finite State Machine). Konani automat, pod dejstvom dogaaja, prolazi kroz konani broj
stanja. U svakom momentu, automat je u jednom od svojih stanja. Automat ostaje u tekuem stanju sve dok se
K
ne desi neki dogaaj pod ijim dejstvom prelazi u novo stanje. U isto vreme, kao reakciju na dogaaj, automat
A C A
F

moe izvriti i izvesne aktivnosti. Drugim reima, dogaaj je ulaz u stanje, koji moe da promeni stanje i
generie izlaz. TCP protokol predvia 11 stanja (tabela T. 3-2).

T. 3-2 Stanja TCP protokola.

Stanje Opis
CLOSED Konekcija ne postoji
LISTEN Aplikacija je izvrila pasivno otvaranje, TCP eka na SYN.
SYN-SENT SYN je poslat; TCP eka na ACK.
SYN-RCVD ACK+SYN je poslat. TCP eka na ACK.

33
 ESTABLISHED Konekcija je uspostavljena. Normalni prenos podataka je u toku.
FIN-WAIT-1 Poslat je prvi FIN. TCP eka na ACK.
FIN-WAIT-2 ACK za prvi FIN je primljen. TCP eka na drugi FIN.
CLOSE-WAIT Primljen je prvi FIN i poslat ACK. TCP eka da se aplikacija zatvori
TIMED-WAIT Primljen je drugi FIN i poslat ACK. TCP eka vreme 2MS.
LAST-ACK Poslat je drugi FIN. TCP eka na ACK.
CLOSING Obe strane su istovremeno inicirale zatvaranje konekcije.
Dijagram stanja TCP protokola prikazan je na Sl. 3-16. Zaobljeni pravougaonici prestavljaju stanja. Prelazi
izmeu stanja prikazani su usmerenim linijama (granama). Svakoj grani pridruen je natpis kojeg ine dva dela
razdvojne kosom crtom. Prvi deo ukazuje na dogaaj ili ulaz (ta TCP prima), a drugi na akciju ili izlaz (ta TCP
alje). Dogaaj moe da inicira aplikacija (zahtev za aktivno/pasivno otvaranje ili zatvaranje konekcije), prijem
segmenta (SZN, FIN, ACK ili RST) ili istek vremena ekanja (tzv. timeout). Akcija je slanje upravljakog
segmenta (SYN, FIN ili RST). Izostanak akcije oznaen je crtom, -. Dijagram sa Sl. 3-16 prikazuje aktivnosti i
klijenta i servera. Normalni tok aktivnosti servera predsavljen je isprekidanim, a normalni tok aktivnosti klijenta
punim linijama.

Scenarija
Da bi smo razumeli dijagram stanja i rad TCP-ja, razmotriemo nekoliko tipinih scenarija.
Uspostavljanje i raskidanje konekcije
Na Sl. 3-17 je ilustrovan scenario u kojem serverski proces obavlja pasivno otvaranje i pasivno zatvaranje, a
klijentski aktivno otvaranje i aktivno zatvaranje konekcije. Zatvaranje konekcije sledi proceduru poluzatvaranja.
Stanja i njihova relativna trajanje prikaza su du vremenske ose.
Klijentska stanja. Klijentski proces izdaje komandu svom TCP-ju zahtevajui uspostavljanje konekcije sa
serverom na datoj adresi soketa. Drugim reima, klijenski proces inicira aktivno otvaranje. Kao reakciju na
zahtev, TCP alje SYN segment na specificiranu adresu soketa i prelazi u stanje SYN-SENT. Nakon prijema
segmenta SYN+ACK, TCP alje ACK segment i prelazi u stanje ESTABLISHED. U ovom stanju prenose se
podaci i potvrde (po potrebi u oba smera).
Kada klijentski proces nema vie podataka za slanje, on svom TCP-ju izdaje komandu za aktivno zatvaranje
konekcije. Klijentski TCP alje FIN segment i prelazi u stanje FIN-WAIT-1. Nakon to primi ACK za poslati
FIN segment, TCP prelazi u sanje FIN-WAIT-2 i ostaje u ovom stanju sve dok ne primi FIN segment od servera.
Kada primi FIN segment, klijent alje ACK segment, prelazi u stanje TIME-WAIT i startuje tajmer podeen na
dvostruko maksimalno vreme ivota segmenta (MSL - Maximum Segment Livetime). Vreme MSL je
maksimalno vreme koje segment moe da provede u Internetu pre nego to bude uniten. (Podsetimo se da se
TCP segment enkapsulira u IP datagram ije je vreme ivota ogranieno - TTL. Kada ruter uniti datagram zbog
isteklog vremena ivota, uniten je i enkapsulirani TCP segment.) Tipino vrednost za MSL je izmeu 30 s i 1
min.
Stanje TIME-WAIT i ekanje 2MSL uvedeni su da bi se prevazila izuzetna situacija koja nastaje ako se
poslednji ACK kojeg klijet alje izgubi u prenosu. U takvoj situaciji, serverski TCP koji je poslao poslednji FIN
i eka na ACK koji ne dolazi, zakljuuje da je FIN izgubljen i ponovo ga alje. Ako klijent pre isteka vremena
2MSL pree u stanje CLOSE i zatvori konekciju moe se desiti da ponovljeni FIN ne stigne do njega to znai
da serverski TCP nikada nee dobiti zavrni ACK. Drugim reima, server nee uspeti da zatvori konekciju.

34
Uvoenjem tajmera podeenog na vreme 2MSL obezbeuje da e klijent, pre konanog naputanja konekcije,
ekati dovoljno dugo da ACK bude izgubljen (jedno MSL) i da ponovljeni FIN stigne do njega (drugo MSL).
Ako u toku stanja TIME-WAIT, klijent primi novi FIN, klijent alje novi ACK i vraa tajmer na poetak.

Sl. 3-17 Uspostavljanje i zatvaranje konekcije.

Serverska stanja. U scenariju predstavljenom na Sl. 3-17, serverski proces izdaje svom TCP-ju komandu za
pasivno otvaranje. To se mora desiti pre nego to klijent izda komandu za aktivno otvaranje. Serverski TCP
prelazi u stanje LISTEN gde ostaje, pasivno ekajui, se dok ne primi SYN segment. Kada primi SYN segment,
serverski TCP alje SYN+ACK segment i prelazi u stanje SYN-RCVD gde eka da klijent poalje ACK
segment. Nakon prijema ACK segmenta, TCP prelazi u stanje ESTABLISHED u kome se odbavlja prenos
podataka.
Serverski TCP ostaje u stanju ESTABLISHED sve dok od klijentskog TCP-ja ne primi FIN segment to znai da
klijentsi proces nema vie podataka za slenje i eli da zatvori konekciju ka serveru. Kao odgovor na FIN,
serverski TCP alje klijentu ACK segment, isporuuje serverskoj aplikaciji preostale podatke iz prijemnog
bafera i prelazi u stanje CLOSE-WAIT. Razmatrani scenario podrazumeva polu-zatvaranje konekcije. To znai
da serverski TCP moe i dalje da alje podatke klijentu i od njega prima potvrde. Meutim, podaci se vie ne
mogu prenositi u suprotnom smeru, od klijenta ka serveru. Serverski TCP ostaje u ovom stanju sve dok
serverska aplikacija ne zatrai zatvaranje konekcije izdavanjem odgovarajue komande (close). Kada se to desi,
serverski TCP alje FIN segment klijentu, kako bi mu saoptio svoju nameru da i on eli da zatvori konekciju, i
prelazi u stanje LAST-ACK. TCP ostaje u ovom stanju sve dok ne primi poslednji ACK, a onda prelazi u stanje
CLOSED. Procedura zatvaranja konekcije koja je poela prvim FIN segmentom se naziva etvorostepenim
usaglaavanjem (four-way handshake).
Zatvaranje konekcije korienjem trostepenog usaglaavanja

35
Kao to je ve napomenuto, trostepeno usaglaavanje je uobiajeni nain zatvaranja TCP konekcije. U ovom
sluaju, strana koja primi FIN segment, kao odgovor alje FIN+ACK segment, kombinujui tako u isti segment
FIN i ACK segmente iz procedure etvorostrukog usaglaavanja. Klijent, preskae FIN-WAIT-2 stanje i direktno
prelazi u stanje TIME-WAIT. Scenario zatvaranja korienjem trostepenog usaglaavanja ilustrovan je na Sl. 3-
18. Nakon zavrene faze prenosa podataka, klijent izdaje komandu close. Klijentski TCP alje FIN segment i
prelazi u stanje FIN-WAIT-1. Po prijemu FIN segmenta, serverski TCP isporuuje serverskoj aplikaciji zaostale
podatke zajedno sa informacijom da konekcija mora biti zatvorena. Nakon toga, serverski TCP prelazi u stanje
CLOSE-WAIT i odlae slanje ACK segmenta na primljeni klijentov FIN sve dok od svoje aplikacije na dobije
zahtev za pasivnim zatvaranjem. Kada serveska aplikacija izda komandu close, TCP alje FIN+ACK segment
klijentu i prelazi u stanje LAST-ACK, gde eka na poslednji ACK. Ostatak procedre je isti kao kod
etvorostepenog usaglaavanja.

36
 KA
C

...

37
Sl. 3-18 Zatvaranje konekcije korienjem trostepenog usaglaavanja.
Odbijanje konekcije
esto se deava da TCP odbije konekciju zato to odredini port iz primljenog SYN segmenta definie serversku
aplikaciju koja trenutno nije u stanju LISTEN. U tom sluaju, serverski TCP, nakon prijema SYN segmenta,
alje nazad RST+SYN segment koji potvruje SYN segment i u isto vreme resetuje (odbija) konekciju. Nakon
toga, serverski TCP se vraa u stanje LISTEN da eka na nove zahteve. Klijent, po prijemu RST-ACK
segmenta, prelazi u stanje CLOSED. Scenario odbijanja konekcije prikazan je na Sl. 3-19.

ej
n
ar
a
vt
o
n
vi
s
a
o
P

ej
n
ar
a
vt
o
n
vi
tk
A
o

N
E
T
S
I D
V
C
R
N-
Y
... S

D
E
S
O
L
T
N
E
S
N-
Y

S
C

Sl. 3-19 Odbijanje konekcije. Prekidanje konekcije

Umesto da zatvori, proces moe da prekine konekciju. To se moe desiti usled otkaza ili neregularnog rada
procesa (npr. zbog ulaska u beskonanu petlju) ili ako proces ne eli da podaci koje je upisao u predajni bafer

38
budu poslati (npr. zato to je naknadno zakljuio da su podaci pogreni). Prekid konekcije moe da inicira i TCP,
na primer, ako primi segment koji pripada prethodnoj konekciji. U svim ovim sluajevima, TCP moe da poalje
RST kako bi trenutno prekidnuo konekciju. Na Sl. 3-20 je prikazan scenario kada klijent prekida konekciju.
Klijentski TCP alje RST+ACK paket i ponitava sve podatke trenutno prisutne u baferu. Serverski TCP takoe
ponitava podatke u svom baferu i obavetava serverski proces o prekidu konekcije putem poruke o greci. Oba
TCP-ja trenutno prelaze u stanje CLOSED.

Sl. 3-20 Prekidanje konekcije

3.3.6 Kontrola protoka
Kotrola protoka regulie koliinu podataka koju izvor moe da poalje pre nego to od odredita primi potvrdu
prijema poslatih podataka. U ekstremnom sluaju, protokol transportnog sloja bi mogao da poalje 1 bajt, a onda
da eka na potvrdu pre nego to poalje sledei bajt. Meutim, ovo bi bio ekstremno spor proces. Ako podaci i
potvrde prelaze veliko rastojanje, izvor e najvei deo vremena biti pasivan, ekajui na potvrde.
Drugi ekstremni sluaj bio bi onaj kada protokol transportnog sloja alje sve podatke koje ima, na primer, u vidu
niza uzastopnih segmenata maksimalne duine bez ekanja na potvrde za pojedinane segmente. Ovako bi
proces prenosa bio zaajno ubrzan. Meutim, moe se desiti da prijemnik bude pretrpan podacima koje ne moe
tako brzo da prihvati i obradi. Osim toga, ako se pojedini segmenti izgude, dupliciraju ili stignu na odredite
izvan redosleda ili sa grekom, izvor nei imati povratnu informaciju sve dok odredite ne detektuje problem i
obavesti ga o tome. Prevazilaenje pomenutih problema moe zahtevati ponavljanje prenosa, a koliina
podataka koji se moraju ponovo poslati moe biti velika, to nepotrebno zauzima kapacitet mree i usporava
komunikaciju.
TCP nudi reenje koje moe pomirit dva pomenuta ekstremna sluaja. TCP uvodi tzv. prozor (eng. window) u
okviru predajnog bafera koji definie koje od svih podataka trenutno prisutnih u predajnom baferu TCP sme da
poalje. Veliina prozora se regulie tzv. protokolom kliznog prozora (eng. sliding window protocol).
Protokol kliznog prozora
Sutina protokola kliznog prozora je da predajnik vodi rauna o preostalom prostoru u baferu prijemnika i alje
samo onoliko bajtova koliko prijemnik moe trenutno da prihvati. Prijemnik, sa druge strane, putem povratnih
segmenata ima obavezu da obavetava predajnu stranu o veliini preostalog prostora u svom baferu. Za ovu
namenu koristi se polje Window Size (vliina prozora) iz zaglavlja TCP paketa.
Konkretno, predajnik koristi tri pointera koji sadre tri karakteristina redna broja iz toka bajtova koji alje.
Princip je ilustrovan na Sl. 3-21. Krajnji levi pointer sadri redni broj za jedan vei od poslednje potvrenog
bajta, odnosno redni broj prvog od bajtova koje je poslao, a za koje jo uvek eka potvrdu. Pointer u sredini
sadri redni broj poslednje poslatog, a nepotvrenog bajta. Krajni desni pointer je za vrednost veliine prozora
predajnika vei od krajnjeg levog pointera. Predajnik pretpostavlja da su bajtovi izmeu krajnjeg levog i
srednjeg pointera jo uvek u baferu prijemnika i zato e u sledeem segmentu poslati samo bajtove izmeu
srednjeg i krajnjeg desnog pointera. Levi pointer se pomera udesno sa svakom primljenom potvrdom. Za isti
iznos se pomera i krajnji desni pointer. Na primer, ako u situaciji sa Sl. 3-21 stigne potvrda za pet bajtova, a pri
tome veliina prozora nije promenjena, krajnji pointeri se pomeraju za pet pozicija udesno, to daje mogunost
za prenos ne vie samo 3 ve 8 bajtova. Srednji pointer se pomera udesno nakon slanja segmenta za iznos
poslatih bajtova. Ako prijemnik promeni veliinu prozora, pomera se samo desni pointer, dok levi i srednji
ostaju na istim pozicijama.

39
3.3.7 Kontrola greaka
TCP je pouzdani transportni protokol. TCP isporuuje tok aplikacionih podataka sa jednog na drugi kraj
konekcije bez greaka i bez delova koji su izgubljeni ili duplicirani. TCP postie pouzdanost korienem
kontrole greaka. Kontrola greaka ukljuuje mehanizme za detekciju segmenata sa grekom, izgubljenih
segmenata, dupliciranih i segmenata primljenih izvan redosleda. Takoe, kontrola greaka ukljuuje i
mehanizme za korekciju greaka nakon to su one detektovane. Detekcija i korekcija greaka kod TCP-ja se
postie pomou tri jednostavna principa: kontrolna suma, potrvrivanje i retransmisija.
Kontrolna suma
Svaki TCP segment sadri polje za kontrolnu sumu koje se koristi za proveru ispravnosti segmenta. Prijemnik
odbacuje svaki segment za koji, proverom kontrolne sume, ustanovi da sadri greku. Drugim reima, pogreni
segmenti se tretiraju na isti nain kao izgubljeni segmenti (tj. kao da nisu ni primljeni).
Potvrivanje
TCP koristi potvrivanja (acknowledgments) da bi potvrdio prijem segmenta podataka. Kao to znamo, polje za
ACK broj iz zaglavlja TCP segmenta sadri redni broj sledeeg bajta kojeg poiljalac segmenta oekuje da
primi. Kod TCP-ja se koristi princip akumulativnog potvrivanja. Naime, primljeni segment sa ACK brojem
postavljenim na vrednost x, TCP tumai kao potvrdu uspenog prijema svih bajtova sa radim brojevima manjim
od x.
Generisanje potvrde
Postavlja se pitanje kada prijemnik treba da generie (alje) potvrde. Trivijalno reenje, gde bi prijemnik
eksplicitno potvrivao svaki uspeno primljeni segment podataka, slanjem nazad kontrolnog ACK segmenta,
nije efikasno. (Da bi vratio nazad 32-bitni ACK broj, prijemnik alje celokupno zaglavlje od 40 bajtova).
Efikasnije reenje je da prijemnik ne alje ACK segmente, ve da potvrdu za primljene podatke uvruje u
segmente kojima svoje podatke alje drugoj strani. Meutim, ta ako prijemnik trenutno nema podatke za slanje?
Tokom evolucije TCP protokola, koristila su se razliita pravila koja odreuju pod kojim uslovima prijemnik
alje potvrdu. Neka od njih bie navedena u nastavku.
1. Svaki segment podataka koji jedna strana alje drugoj sadri ACK broj postavljen na vrednost rednog
broja sledeeg bajta kojeg oekuje da primi. Na ovaj nain smanjuje se broj segmenata potrebnih za
potvrivanje.
2. Kada prijemnik primi oekivani segment (sa oekivanim rednim - SEQ brojem) u situaciji kada nema
svojih podataka za slanje, a sve prethodno primljene segmente je ve potvrdio, prijemnik odlae slanje
ACK segmenta sve do prijema sledeeg segmenta podataka ili do isteka unapred zadatog vremenskog
perioda (tipino 500 ms). Drugim reima, prijemnik odlae slanje ACK segmenta ako postoji samo
jedan nepotvreni segment. Ovo pravilo spreava generisanje dodatnog saobraaja radi slanja velikog
broja ACK segmenata.
3. Kada prijemnik primi oekivani segment u sitaciju kada prethodno primljeni segment jo uvek nije
potvrdio, prijemnik odmah alje ACK segment. Drugim reima, na strani prijemnika ne bi trebalo da
postoji vie od jednog nepotvrenog segmenta. Na ovaj nain, spreava se nepotrebna retransmisija
segmenata zbog kanjenja potvrde.
4. Kada prijemnik primi segment izvan redosleda, sa redni brojem veim od oekivanog (to ukazuje da je
segment sa oekivanim rednim brojem izgubljen u prenosu), prijemnik odmah alje ACK segment sa
ACK brojem sledeeg oekivanog segmenta. Na ovaj nain se inicira brza retransmislija segmenta koji
nedostaje.
5. Kada stigne segment koji nedostaje, prijemnik, bez ekanja, alje ACK segment kojim predajnika
obavetava o sledeem oekivanom rednom broju.
6. Ako primi duplicirani segment, prijemnik, bez ekanja, alje ACK segment. Retransmisija

40
Retransmisija (ponovno slanje) segmenata lei u osnovi kontrole greaka. Svaki segment koji je primljen sa
grekom, izgubljen ili dupliciran u prenosu se ponovo alje. Retransmisiji su podloni segmenti koji troe redne
brojeve (segmenti podataka i pojedini kontrolni segmenti, tj. oni koji zahtevaju potvrivanje). Segmenti koji ne
troe redne brojeve, kao to je ACK segment se ne retransmituju. Segment se ponovo alje u dva sluaja: vreme
retransmisionog tajmera je isteklo i prijemnik je primio tri duplicirana ACK segmenta. Retransmisija nakon
isteka RTO vremena
Kad god poalje segment, TCP startuje retransmisioni tajmer (tzv. retransmission time-out (RTO) timer). Ako
potvrda prijema segmenta stigne pre nego to vreme tajmera (tzv. RTO vreme) istekne, tajmer se zaustavlja.
Meutim, ako RTO vreme istekne pre nego to stigne potvrda, odgovarajui segment se smatra izgubljenim ili
izmenjenim u prenosu i ponovo se alje, ak iako izostanak prijema ACK-a moe biti posledica poveanog
kanjenja segmenta, kanjenja ACK-a ili gubitka ACK-a u prenosu. Neto kasnije u ovom poglavlju, videemo
da se RTO vrednost dinamiki podeava na osnovu procene vremena prenosa segmenta od predajnika do
prijemnika i nazad (round trip time - RTT). RTT je vreme potrebno da segment stigne do prijemnika plus vreme
potrebno da se potvrda vrati nazad do predajnika.
Retransmisija nakon tri duplicirana ACK segmenta
Prethodno pravilo za retransmisiju je dovoljno ako RTO vreme nije podeeno na previe malu vrednost.
Meutim, ponekada se moe desiti da predajnik pre isteka RTO vremena izgubljenog segmenta poalje vei broj
sledeih segmenta, toliko da sve njih prijemnik ne moe da prihvati, zbog ogranienog prostora u svom baferu.
Da bi se ovakva situacija prevazila, primenjuje se pravilo tri duplicirana ACK-a, shodno kome predajnik, bez
obzira na RTO vreme koje jo uvek nije isteklo, retransmituje segmen nakon to primi tri duplikata ACK
segmenta u kojima se kao ACK broj pojavljuje njegov SEQ broj. Ova osobina se naziva brzom retransmisijom.
Segmenti primljeni izvan redosleda
Kada neki segment zakasni, bude izgubljen ili odbaen zbog greke, segmenti koji slede bie primljeni izvan
redosleda. Kod prvobitnih implementacija TCP protokola, segmenti primljeni izvan redosleda su odbacivani, to
je kao posledicu imalo retransmisiju ne samo izgubljenog segmenta, ve i svih sledeih, u meuvremenu
uspeno primljenih, segmenta. Kod veine savremenih implementacija, segmenti primljeni izvan redosleda se ne
odbaciju, ve se privremeno uvaju, sve dok ne stigne segment koji nedostaje. U svakom sluaju, segmenti
primljeni izvan redosleda se ne isporuuju aplikacionom programu - TCP garantuje isporuku podataka u
redosledu u kojem su poslati.
Scenariji
Normalni rad
Prvi scenario, ilustrovan na Sl. 3-22, odnosi se na dvosmerni prenos podataka izmeu dva sistema. Klijentski
TCP alje jedan segment, a serverski tri. Na Sl. 3-22 je naglaeno koje pravilo za generisanje potvrde se
primenjuje pri svakom potvrivanju. Za klijentov prvi segment i sva tri serverska segmenta primenjuje se
pravilo 1. Svaki segment podataka sadri ACK broj sledeeg bajta iji prijem se oekuje. U situaciji kada klijent
primi prvi segment podataka od servera, pravilo 1 se ne moe primeniti jer klijent nema vie podataka koje bi
poslao. Zato klijent podvruje ovaj segment eksplicitno, slanjem ACK segmenta. Meutim, shodno pravilu 2,
potvrda se ne alje odmah po prijemu segmenta, ve sa kanjenjem od 500 ms (kako bi se saekalo na eventualni
novi segment podataka). Kada primi sledei segment podataka (drugi serverov segment), klijent zapoinje
odmeravanje vremena kanjenja potvrde. Meutim, pre isteka 500 ms, klijent dobija novi segment (trei
serverov segment). Prijemom ovog segmenta stvaraju se uslovi za primenu pravila 3 (dva nepotvrena
segmenta) tako da klijent odmah generie i alje ACK segment.

41
Izgubljeni segment
Ovaj scenario pokazuje ta se deava ako je segment izgubljen ili primljen sa grekom. Prijemnik na isti nain
tretira i izgubljene i pokvarene segmente. (Izgubljeni segment je uniten negde u mrei; segment primljen sa
grekom unitava sam prijemnik, tako da je krajnji efekat isti.) Na Sl. 3-23 je prikazana situacije kada je segment
izgubljen, tj. uniten od strane nekog rutera u mrei zbog, na primer, zaguenja.
U prikazanom scenariju, pretpostavlja se da je prenos jednosmeran: jedna strana alje, a druga prima podatke.
Predjanik alje segmente 1 i 2 koji se potvruju jednim ACK segmentom (pravilo 3). Meutim, segment 3 je
izgubljen, tako da prijemnik prima segment 4 izvan redosleda. Prijemnik smeta podatke iz ovog segmenta u
prijemni bafer, ali tako da ostavlja prazan prostor za bajtove koji nedostaju. Prijemnik bez ekanja alje ACK
predajniku sa ACK brojem sledeeg oekivanog bajta (pravilo 4). Naglasimo da iako prijemnik smeta u bafer
bajtove 801 do 900, oni nee biti isporueni aplikaciji sve dok se prazan prostor u baferu ne popuni bajtovim
koji nedostaju (701 do 800).

Sl. 3-23 Izgubljeni segment.

Iako predajnik koristi poseban RTO tajmer za svaki poslati segment, na Sl. 3-23 je prikazan samo RTO tajmer
izgubljenog segmenta, tj. segmenta 3. Poto prijemnik ne alje potvredu za izgubljeni segment, zadato vreme
RTO tajmera istie i predajni TCP ponovo alje segment 3. Ovog puta segment uspeno stie do prijemnika, i
prijemnik ga potvruje bez ekanja (pravilo 5).

42
Brza retransmisija
Ovaj scenario ilustruje ideju brze retransmisije. Scenario je slian prethodnom sa razlikom da je u ovom sluaju
RTO tajmer podeen na znaajno due vreme ( Sl. 3-24). Predajnik nije svestan da je segment 3 izgubljen i
nastavlja da alje sledee segmente. Prijemnik prima etvrti, peti i esti segment, smeta ih u bafer i za svaki od
njih (pridravajui se pravila 4) uporno alje potvrde za poslednji segment primljen u redosledu (ACK: 301).
Iako RTO vreme za segment 3 jo uvek nije isteklo, u trenutku kada primi etvrtu potvrdu sa istim ACK brojem
(tri duplikata), predajnik, bez ekanja, ponavlja slanje segmenta 3, tj. segmenta kojeg, shodno ACK broju,
prijemnik oekuje.

Sl. 3-24 Brza retransmisija.

Zakasneli segmenti
etvri scenario se odnosi na zakasnele segmente. TCP koristi usluge IP-a. TCP segmenti se enkapsuliraju IP
datagrame, a kao to znamo, datagrami mogu stii do konanog odredita razliitim putanjama i sa razliitim
kanjenjima. S toga pojedini TCP segmenti mogu zakasniti vie od drugih. Prijemnik tretira zakasnele segmente
na isti nain kao i izgubljene ili segmente primljene sa grekom. Zakasneli segment su najei uzrok pojave
dupliciranih segmenata: segment kasni vie nego to je uobiajeno; predajnik ne dobija potvrdu i ponovo alje
isti segment. Posle izvesnog vremena prijemnik dobija oba segmenta, zakasneli i retransmitovani. Duplicirani
segment
TCP lako prepoznaje i odbacuje duplicirane segmente. Odredini TCP oekuje kontinualni tok bajtova. Primljeni
segment sa redinim brojem manjim od rednog broja poslednje primljenog i potvrenog bajta iz toka, smatra se
dupliciranim i odbacuje se.
Izgubljeni ACK
Prvi od dva scenarija koji se odnose na gubitak ACK segmenta opisuje situaciju kada se izgubljeni ACK
automatski zamenjuje sledeim ACK-om. Na Sl. 3-25(a) je prikazan gubitak ACK segmenta poslatog od strane
prijemnika nakon uspenog prijema podataka. Odredini TCP (predajnik) ne mora ni da primeti gubitak ACK
segmenta. TCP koristi princip akumulativnog potvrivanja, tako da sledei ACK, koji je uspeno primljen,
potvruje sve prethodne bajtove, sa rednim brojem manjim od ACK broja sadranog u ACK segmentu,
ukljuujui i one koji su zbog gubitka prvog ACK segmenta ostali privremeno nepotvreni. Moemo rei da
sledei ACK segment automatski koriguje prethodni, izgubljeni ACK segment.

43
 (a) (b)
Sl. 3-25 Izgubljena potvrda: (a) automatska zamena; (b) ponovno slanje segmenta.
Meutim, sledei ACK segment ne mora da postoji (izgubljeni ACK je ujedno i poslednji ACK) ili moe stii
dosta kasnije. U takvoj situaciji, korekcija se inicira RTO tajmerom na strani koja oekuje prijem ACK segmenta
(efekat je isti kao da je izgubljen segment podataka). Poto potvrda ne stie, predajnik retransmituje segment.
Retransmitovani segment se pojavljuje na strani prijemnika kao duplicirani segment. Prijemnik odbacuje
duplikat, ali zato, bez ekanja, ponovo alje ACK (pravilo 6). Sl. 3-25(b) prikazuje ovaj scenario. Uoimo da je
retransmitovan samo jedan segment, iako dva segmenta nisu potvrena.
Retransmisioni tajmer
Kao to je ve napomenuto, uloga retransmisionog tajmera je merenje vremena ekanja na potvrdu segmanta.
Uvek kada poalje segment, TCP kreira retransmisioni tajmer za taj konkretni segment. Mogu nastati dve
situacije:
1. Ako potvrda segmenta stigne pre nego to vreme tajmera istekne, tajmer se unitava.
2. Ako vreme tajmera istekne, a da pri tome potvrda za poslati segment jo uvek nije stigla, segment se
retransmituje, a tajmer resetuje.
Postavlja se pitanje: koliko dugo treba ekati na potvrdu, tj. koliko treba da bude vreme RTO ( Retransmission
time-out) na koje se podeava retransmisioni tajmer.
Potvrda prijema se esto koristi i na nivou veze. Meutim, problem odreivanja optimalnog vremena ekanja je
daleko tei na transportnom nego na nivou veze. Na nivou veze (npr. u LAN mrei tipa Ethernet) vreme
kanjenja potvrde se moe lako predvideti (ne varira puno). Tipina karakteristika vremena odziva na novu veze
prikazana je na Sl. 3-26(a). Vidi se da je u najveem broju sluajeva vreme odziva 20 ms, sa relativno malim
odstupanjima. Pod ovakvim uslovima retransmisioni tajmer moe biti postavljen na vreme koje je tek neto due
od oekivanog vremena kanjenja (oznaeno vertikalnom isprekidanom linijom na Sl. 3-26(a)).

Vreme odziva Vreme odziva

(a) (b)
Sl. 3-26 (a) raspodela verovatnoe oekivanog vremena odziva na: (a) nivou veze; (b) na transportnom nivou.
Meutim, TCP radi u radikalno drugaijem okruenju. Kanjenje u prenosu izmeu dve take na Internetu
podlono je daleko veim varijacijama, a tipina funkcija raspodele oekivanog vremena odziva je oblika kao na
Sl. 3-26(b). Svrha tajmera je da se detektuju situacije kada je segment izgubljen u prenosu. Meutim, ako je RTO
vreme isuvie kratko (T1 na Sl. 3-26(b)), moe se desiti da predajnik bespotrebno retransmituje segmente, jer
potvrda nema ne zato to su segmenti izgubljeni nego zato to prenos potvrde traje due nego obino. Sa druge

44
strane, ako je RTO vreme previe dugo (T2 na Sl. 3-26(b)), u situacijama kada zaista segment zaista bude
izgubljen, prenos e biti privremeno obustavljen, sve dok ne istekne predvieno vreme ekanja. ta vie, u
duim vremenskim intervalima karakteristika sa Sl. 3-26(b) se moe menjati, kao posledica promenjenih uslova u
mrei.
Izbor RTO vremena zasnovan je na procena trenutnog vremena odziva, tzv. RTT vremena (Round-Trip Time).
Meutim, izraunavanje RTT vremena je sloen proces, koji zahteva postepeno objanjenje.
Izmereno RTT. Izmereno RTT vreme (u oznaci RTT M) segmenta je vreme od trenutka slanja segmenta do
trenutka prijema potvrde za poslati segment. U toku trajanja konekcije, TCP neprekidno meri i aurira RTT M.
Merenje RTT-a se komplikuje injenicom da izmeu segmenta i potvrde ne postoji relacija 1-1: jedan segment
potvrde (ACK) moe da potvrdi vie semenata podataka. Kod TCP-ja uvek je u toku najvie jedno aktivno
merenje RTT vremena. To znai da kada merenje RTT vremena jednom zapone ono se mora okonati pre nego
to se zapone sledee.
Uravnoteeno RTT. Izmereno RTT, RTTM, se menja od merenja do merenja. Na savremenom Internetu
fluktuacije ovog vremena su toliko velike da se ono ne moe koristiti za podeavanje retransmisionog tajmera.
Veina realizacija TCP protokola koristi uravnoteeno RTT, u oznaci RTTS, koje se izraunava na sledei nain:
Poetno => nema vrednost
Posle prvog merenja => RTTS = RTTM
Posle svakog sledeeg merenja => RTTS = (1-)RTTS + RTTM
Parametar odreuje kolika teina se daje staroj vrednosti RTT S, a kolika novoizmerenom RTTM. Tipino se
usvaja =7/8. Ako je RTTM manje od trenutnog RTTS, RTTS e biti smanjeno i obrnuto. Meutim, ova promena
nee biti nagla, zbog , ve postepena.
RTT devijacija. Kod veina realizacija, pored RTTS, izraunava se i devijacija RTT-a, u oznaci RTT D, na sledei
nain:
Poetno => nema vrednost
Posle prvog merenja => RTTD = RTTM/2
Posle svakog sledeeg merenja => RTTD = (1-)RTTD + |RTTS - RTTM| Tipino se usvaja, =1/4.

RTO vreme. Konano, vrednost RTO se izraunava na osnovu uravnoteenog RTT i njegove devijacije. Kod
veina realizacija koristi se sledea formula:
Poetno => Poetna vrednost

Karnov algoritam
Pretpostavimo da u toku retransmisionog perioda segment nije potvren i da je zbog toga retransmitovan. Kada
predajni TCP konano primi potvrdu, ostaje dilema da li je to potvrda za prvobitni ili za retransmitovan segment
(jer, moe se desiti da prvobitni segment nije izgubljen u prenosu, ve je samo zakasno). Iz tog razloga RTT se
ne meri za retransmitovane segmente. Drugim reima, u obzir se uzima samo RTT M za segmente koji nisu
retransmitovani. Eksponencijalni backoff
Postavlja se pitanje: koju vrednost za RTO izabrati nakon retransmisije segmenta ? Kod veine realizacija TCP
protokola koristi se strategija eksponencijalnog backoff-a. RTO vrednost se duplira sa svakom uzastopnom
retransmisijom. Nakon prve retransije segmenta, RTO postaje 2*RTO, posle druge uzastopne retransmisije
4*RTO i td.

4 Aplikacioni sloj
TCP/IP je projektovan pre OSI modela i zato njegovi slojevi nisu u potpunosti usklaeni sa slojevima koje
predvia OSI. TCP/IP ima pet nivoa: nia etiri se uklapaju u nia etiri sloja OSI modela. Meutim, peti,
aplikacioni sloj TCP/IP-a ekvivalentan je kombinaciji prezentacionog, sloja sesije i aplikacionog sloja OSI
modela. To znai da se funkcije predviene ovim slojevima kod TCP/IP obuhvaene jednim slojem.
Slojevi ispod aplikacionog obezbeuju pouzdani prenos podataka. Meutim, osim mogunosti komuniciranja,
oni ne pruaju neki drugi servis koji je od direktne korisni krajnjem korisniku. Tek na vrnom sloju nalazimo
realne mrene aplikacije. Meutim, i na ovom nivou postoji potreba za protokolima koji e omoguiti
aplikacijama da funkcioniu.
U ovom poglavlju razmatraemo tri aplikacije (tj. aplikaciona protokola) koje se tradicionalno smatraju
obaveznim elemantima TCP/IP-a: TELNET, FTP i SMTP. TELNET prua servis logovanja na daljinu koji
omoguava korisniku na terminalu ili personalnom raunaru da se loguje i koristi udaljeni raunar na isti nain
kao da je direktno povezan sa tim raunarom. FTP (File Transfer Protocol - Protokola za prenos fajlova) se
koristi za prenos fajlova od jednog na neki drugi sistem. SMTP (Simple Message Transfer Protocol) prua
osnovnu podrku za razmenu elektronske pote.

45
4.1 Klijent-server model
Za korienje servisa dostupnih na Internetu neophodni su aplikacioni programi koji se izvravaju na dva krajnja
raunara i meusobno komuniciraju. Na Internetu, aplikacioni programi su ti koji komuniciraju, ne raunari ili
korisnici.
Aplikacioni programi koji koriste Internet zasnovani su na obliku distribuiranog procesiranja koji se zove
klijent-server model. Pod ovim modelom podrazumeva se sledea strategija:
Jedan aplikacioni program, klijent, koji se izvrava na lokalnoj maini, zahteva uslugu (servis) od drugog
aplikacionog programa, server, koji se izvrava na udaljenoj maini (Sl. 4-1).
Server nudi usluge mnogim klijentima, a ne samo nekom konkretnom klijentu. Drugim reima, klijentserver
model odgovara relaciji tipa: vie-prema-jedan: vie klijenata moe koristiti servise jednog servera.
U optem sluaju, klijentski program se izvrava samo onda kada je usluga servera potrebna. Sa druge strane,
serverski program, koji prua uslugu, trebalo bi da radi sve vreme, zato to unapred ne zna kada e neki klijent
zatraiti uslugu.
Servisi koji su esto potrebni mnogim korisnicima podrani su specifinim aplikacionim programima. Na
primer, trebalo bi da postoji aplikacioni program koji e omoguiti korisnicima da pristupaju udaljenim
fajlovima, razmenjuju elektronsku potu i td. S obzirom na optost primene, servisi ovog tipa su podrani
odgovarajuim protokolima aplikacionog sloja.

Sl. 4-1 Klijent-server model

Klijent je program koji se izvrava na lokalnoj maini i zahteva uslugu servera. Klijentski program je konaan,
to znai da se pokree od strane korisnika (ili drugog aplikacionog programa) kada je usluga potrebna i
zavrava kada je usluga dobijena.
Server je program koji se izvrava na udaljenoj maini i prua usluge klijentima. Kada je jednom startovan,
server je dostupan mnogim klijentima, ali nikada ne pokree servis, a da on nije zatraen. Serverski program je
beskonaan (nikada se ne zavrava, osim u sluaju nekih abnormalnih situacija) i neprekidno eka na zahteve
klijenata. Kada zahtev stigne, server odgovara na zahtev.
4.2 TELNET
Glavni zadatak Interneta i TCP/IP-ja je da obezbede mrene servise korisnicima. Na primer, korisnici bi eleli
da mogu da izvravaju razliite aplikacione programe na udaljenim raunarima, a da kreirane rezulte potom
prenesu na svoj lokalni raunar. Jedan nain kako se moe ostvariti ovaj zahtev jeste da se kreira poseban
klijent-server aplikacioni program za svaki od potrebnih servisa. Programi kao to su programi za FTP, e-mail i
td., su primeri ovakvog pristupa. Meutim, bilo bi nemogue napisati aplikacioni program za svaku iskazanu
potrebu.
Bolje reenje je klijent-server program opte namene, koji e omoguiti korisniku da pristupi bilo kom
aplikacionom programu na udaljenom raunaru. Drugim reima, da omogui korisniku da se prijavi za rad
(login-uje) na udaljenom raunaru. Nakon prijavljivanja, korisnik moe da koristi servise dostupne na
udaljenom raunaru i prenese rezultate nazad na svoj raunar.
TELNET je upravo takav klijent-server program. TELENT omoguava uspostavljanje konekcije sa udaljenim
sistemom na nain da se lokalni terminal ponaa kao da je terminal tog udaljenog sistema. Koncepti
Sistemi sa raspodelom vremena
TELENT je razvijen u vreme kada su veina operativnih sistema, kao to je UNIX, podravali koncept
raspodele vremena koji je omoguavao da vie korisnika koristi jedan veliki raunar. Kod ovakvih sistema,
interakcija izmeu korisnika i raunara se ostvaruje putam terminala (kombinacija tasture, monitora i eventualno
mia). Celokupna obrada se obavlja na centralnom raunaru, a terminali se koriste za unos podataka i prikaz
rezultata. Operativni sistemi sa raspodelom vremena kreiraju iluziju da svaki korisnik radi na izdvojenom,
namenskom raunaru. Korisnik moe da pokrene program, pristupa sistemskim resursima, prelazi iz jednog u
drugi program i slino. Lokalni Login
U sistemima sa raspodelom vremena, svaki korisnik poseduje izvesna prava pristupa sistemskim resursima.
Svaki autorizovani korisnik poseduje identifikaciju (u vidu korisnikog imena) i lozinku. Da bi pristupio
sistemu, korisnik se prijavljuje za rad (kae se, korisnik se loguje) navodei svoje korisniko ime i lozinku.

46
Kada se korisnik prijavi za rad na lokalnom sistemu sa raspodelom vremena (putem korisnikog imena i
lozinke) kae se da je korisnik izvrio lokalni login. Kako korisnik kuca na tastaturi terminala, svaki pritisak na
dirku se prenosi drajveru terminala. Drajver terminala prenosi karaktere (znaci koji odgovaraju dirkama)
operativnom sistemu. Operativni sistem, interpretira kombinaciju karaktera i poziva odgovarajui aplikacioni
program (Sl. 4-2).

Mehanizam ipak nije tako jednostavan, kao to izgleda, zato to operativni sistem moe dodeliti posebno
znaenje pojedinim specijalnim karakterima. Na primer, kod UNIX-a, pojedine kombinacije karaktera imaju
posebno znaenje, kao to je kombinacija kontrolnog karaktera, Ctrl, i karaktera z, koja oznaava suspenziju,
ili kombinacija Ctrl-c, koja oznaava trenutni prekid programa.
Udaljeni login
Kada korisnik pristupa aplikacionom programu lociranom na udaljenom raunaru, on obavlja udaljeni login
(remote login). TELNET je posrednik u ovoj interakciji. Klijentska strana TELNET aplikacije izvrava se na
strani korisnika, a serverska na strani udaljenog raunara. Pritisak na dirku tastature lokalnog terminala prenosi
se terminal drajveru, od koga operativni sistem preuzima karaktere, ali ih ne interpretira, ve ih alje TELNET
klijentu. TELNET klijent prevodi karaktere (koji u zavisnosti od tipa lokalnog operativnog sistema mogu biti
kodirani ASCII, EBCDIC ili nekim treim kodom) u univerzalni karakter kd (NVT - Network Virtual Terminal
chracters) i isporuuje ih lokalnom TCP/IP steku (Sl. 4-3).

Sl. 4-3 Udaljeni login.

Komande ili tekst, u NVT obliku, prenosi se kroz Internet i stiu do TCP/IP steka udaljenog raunara, koji ih
isporuuje operativnom sistemu, a on TELNET serveru, gde se karakteri konvertuju iz NVT formata u oblik
razumljiv udaljenom raunaru. Sada bi smo oekivali da TELNET server vrati konvertovane karaktere
operativnom sistemu koji bi onda obavio interakciju sa odgovarajuom aplikacijom. Meutim, to se ne deava
jer operativni sistem nije projektovan da karaktere dobija od TELNT servera ve od lokalnog terminala
(posredstvom terminal drajvera). Reenje je u ugradnji specifinog programa, pseudoterminal drajver, koji se
prema operativnom sistemu ponaa kao terminal drajver, ali zato sa druge strane, karaktere ne oekuje od
lokalnog terminala ve od TELNET servera. Konano, operativni sistem prenosi karaktere do odgovarajueg
aplikacionog programa.
NVT
Mehanizam pristupa udaljenom raunaru je sloen. Razlog za to je to razliiti raunari i operativni sistemi
koriste razliita kodiranja karaktera i prepoznaju razliite specijalne kombinacije karaktera. Na primer, kod
DOS-a se za kraj fajla koristi kombinacija Ctrl+z, a kod UNIX-a Ctrl+d. Drugim reima, radi se o heterogenim
sistemima.

47
TELNET reava problem heterogenosti uvoenjem univerzalnog skupa karaktera, NVT. NVT (Network Virtual
Terminal - mreni virtuelni terminal) je sakriven izmeu TENET klijenta i servera. TELNET klijent prevodi
lokalni skup karakter u NVT oblik, a server iz NVT u skup karaktera udaljenog raunara. Na ovaj nain,
omoguena je interakcija raznorodnih raunara i operativnih sistema. Koncept je ilustrovan na Sl. 4-4.
Naglasimo da je kod OSI modela, konverzija podataka (kao ona koju obavlja NVT) zadatak prezentacionog
sloja. Kod TCP/IP, prezentacioni sloj nije predvien, a funkcije prezentacionog sloja su pridruene aplikacionom
sloju.

NVT skup karaktera

NVT sadri dva skupa 8-bitnih karaktera, jedan za podatke, a drugi za kontrolne (upravljake) informacije.
Najvii bit karaktera za podatke ima vrednost 0, dok kod kontrolnih karaktera ima vrednost 1. Niih 7 bitova
karaktera za podatke je isti kao kod ASCII kda. Neki od vanijih kontrolnih karaktera bie pomenuti u
nastavku.
Ugraivanje
TELNET koristi samo jednu TCP konekciju. Server koristi dobro-poznati port 23, dok se za klijente koriste
dinamiki portovi. Ista konekcija se koristi kako za slanje podataka tako i za slanje kontrolnih karaktera. To se
postie ugradnjom kontrolnih karaktera u tok podataka. Da bi se napravila razlika izmeu podataka i kontrolnih
karaktera, svaka sekvenca kontrolnih karaktera poinje specijalnim kontrolnim karakterom koji se oznaava
skraenicom IAC (Interpret As Control - interpretiraj kao kontrolu).
Na primer, zamislimo da korisnik trai od servera da prikae sadraj fajla file1. Korisnik unosi komandu: cat
file1. Meutim, umesto da unese file1, korisnik je pogreio u kucanju i uneo filea1. Da bi ispravio greku,
korisnik koristi taster backspace, tako da je niz unetih karaktera: cat filea<backspace>1. Meutim, kod
prvobitnih implementacija TELNET-a, lokalno editovanje nije mogue, ve se radi na udaljenom serveru.
Karakter backspace se prevodi u dva karaktera (IAC EC) i ugrauje u tok podataka koji se alje serveru (Sl. 4-5).

Sl. 4-5 Primer ugra

ivanja.
Opcije
TELNET prua mogunost klijentu i serveru da pregovaraju oko opcija koje e koristiti tokom sesije. Opcije su
dodatne mogunosti raspoloive korisnicima sa naprednijim terminalima. Korisnici sa jednostavnijiim
terminalima mogu koristiti podrazumevane opcije. U tabeli T. 4-1 su navedene neke od esto korienih opcija.
T. 4-1 Opcije
Kd Opcija Znaenje
0 Binary 8-bitni (binarni) prenos
1 Echo Svi primljeni podaci se vraaju drugoj strani
3 Suppress go ahead Ignorii go-ahead opciju
5 Status Zahteva status TELENT-a
6 Timing mark Definie vremenski marker
24 Terminal type Postavlja tip terminala
32 Terminal speed Postavlja brzinu terminala
34 Line mode Promena na linijski nain rada
Sledi detaljnije objanjenje opcija:

48
Binary. Ova opcija omoguava prijemniku da svaki primljeni 8-bitni podatak, izuzev IAC, tretira kao binarni
podatak. Kada se primi IAC, sledei karakter ili karakteri se interpretiraju kao komande. Meutim, ako se prime
dva uzastopna IAC karaktera, tada se prvi odbacuje, a drugi interpertira kao binarni podatak.
Echo. Ova opcija omoguava serveru da, odmah po prijemu, vraa nazad klijentu svaki primljeni podatak. To
praktino znai da e svaki karakter kojeg klijent poalje serveru biti vraan nazad klijentu i prikazan na ekranu
njegovog terminala. Drugim reima, karakteri koji klijent unosi se ne prikazuju odmah na njegovom ekranu, ve
se eka da ih server vrati nazad.
Suppress go-ahead. Ova opcija iskljuuje dejstvo kontrolnog karaktera go-ahead (GA). (Vie detalja u sekciji o
nainima rada).
Status. Ova opcija omoguava korisniku da dobija informacije o dozvoljenim opcijama na serveru.
Timing mark. Ova opcija omoguava jednoj od strana da drugoj alje vremenske markere koji ukazuje da je
zavrena obrada svih prethodno primljenih podataka.
Terminal type. Ova opcija omoguav klijentu da obavesti servera o tipu svog terminala.
Terminal speed. Ova opcija omoguav klijentu da obavesti servera o brzini svog terminala.
Line mode. Ova opcija omoguava klijentu da se prebaci u linijski nain rada. (Vie detalja kasnije)
Pregovaranje oko opcija
Klijent i server se moraju dogovoriti oko svake opcije koju bi jedna od strane elela da koristi. Za pregovaranje
se korste etiri kontrolna karaktera, data u tabeli T. 4-2.
T. 4-2 NTV karakteri za pregovaranje.
Karakter Decimalno Binarno Znaenje
WILL 251 111110111. Ponuda dozvole
2. Prihvatanje traene dozvole
WONT 252 111110001. Odbijanje traene dozvole
2. Ponuda zabrane
3. Prihvatanje ponuene zabrane
DO 253 111110011. Prihvatanje traene dozvole
2. Traenje dozvole
DONT 254 1111110 1. Neprihvatanje ponuene dozvole
2. Prihvatanje ponuene zabrane
3. Traenje zabrane.

49
4.5 DNS
Za identifikaciju entiteta na Internetu, TCP/IP koristi IP adrese koje na univerzalan i jedinstveni nain
identifikuju vezu hosta na Internet. Meutim, ljudima je lake da koriste imena nego IP adrese. Lake je
zapamtiti: www.elfak.ni.ac.yu nego 160.136.4.23. ta vie, ako organizacija premesti Web server na drugu
mainu, sa drugom IP adresom, npr. 160.136.4.100, promenie se i njena Web adresa: 160.136.4.23. Simbolika
imena su uvedena upravo iz razloga da bi se imena hostova razdvojila od adresa hostova. Na taj nain,
simbolika adresa www.elfak.ni.ac.yu moe ostati ista i posle promene IP adrese. Meutim, mrea u svakom
sluaju razume samo IP adrese, to znai da je potreban mehanizam za preslikavanje simbolikih imena na IP
adrese.
Kada je Internet bio mali, za preslikavanje je korien tzv. host fajl. Host fajl ima samo dve kolone: ime i adresa.
Host fajl se uvao na hard disku i periodino aurirao preuzimanjem podataka iz glavnog host fajla. Kada je
nekom programu ili korisniku potrebno preslikavanje, host pretrauje host fajl i vraa IP adresu pridruenu
datom simbolikom imenu. Meutim, ovakav pristup je danas nemogu. Zbog ogromnog broja hostova na
Internetu, host fajl bi bio previe veliki. Takoe, bilo bi nemogue aurirati host fajlove svih hostova na
Internetu uvek kada se desi neka promena.
Jedno reenje bilo bi da se celokupan host fajl smesti na jedan centralizovani raunar, a da se svi hostovi na
Internetu obraaju ovom raunaru uvek kada im je potrebno preslikavanje. Naravno, ni ovo reenje nije
praktino, jer bi generisalo veliku koliinu saobraaja na Internetu, a otkaz centralizovanog raunara doveo bi do
otkaza celog Interneta.
Reenje koje se danas koristi zasnovano je na podeli ogromne koliine informacija na manje delove koji se
uvaju na razliitim raunarima. Host, kome je potrebno preslikavanja, obraa se najbliem raunaru koji sadri
traenu infomaciju. Ovakav metod koristi DNS (Domain Name System - Sistem imena domena). U ovoj sekciji
najpre e biti izloeni osnovni koncepti DNS-a, a potom i sam DNS protokol.
Prostor imena
Imena koja se dodeljuju mainama biraju se iz prostora imena. Prostor imena moe biti ravanski ili hijerarhijski.
Ravanski prostor imena
Kod ravanskog prostora imena, ime je pridrueno adresi. Imena iz ovog prostora su nizovi karaktera bez bilo
kakve unapred nametnute strukture. Imena mogu, ali ne moraju, imati zajednike delove; ako ih imaju, onda to
nema neko posebno znaenje. Ravanski prostora imena mora biti pod centralizovanom kontrolom, kao bi se
obezbedila jednoznanost dodeljenih imena, to ga ini nepodesnim za velike sisteme, kao to je Internet.
Hijerarhijski prostor imena
Kod hijerarhijskog prostora imena, svako ime se sastoji iz nekoliko delova. Na primer, prvi deo moe definisati
tip organizacije, drugi ime organizacije, trei odeljenje unutar organizacije, i td. U ovom sluaju, kontrola nad
dodelom imena moe biti decentralizovana. Centralna uprava moe kontrolisati dodelu delova imena koji
definiu tip i ime organizacije, dok se odgovornost za preostali deo imena moe preneti na samu organizaciju.
Organizacija moe dodavati sufikse (ili prefikse) kako bi kreirala imena za svoje hostove ili druge resurse.
Menadment organizacije ne mora da brine da li je isti sufiks (ili prefiks) izabrala i neka druga organizacija, jer
ak iako je su delovi imena isti, celokupna imena su razliita.
Prostor imena domena
Prostor imena domena je hijerarhijski prostor imena koji se koristi na Internetu. Prostor je struktuiran u obliku
invertovanog stabla sa korenom na vrhu. Stablo moe imati najvie 128 nivoa: nivo 0 (koren) do nivo 127 (vidi
Sl. 4-37).

Sl. 4-37 Prostor imena domena.

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

50
Svaki vor u stablu ima ime domena. Puno ime domena je niz labela razdvojenih takom (.). Ime domena se
uvek ita poev od posmatranog vora pa navie do korena. To znai da se puno ime domena uvek zavrava
praznim stringom, odnosno takom. Na Sl. 4-38 su prikazana neka imena domena.

Puno ime domena (FQDN - Fully Qualified Domain Name)

FQDN je labela zavrena praznim stringom (odnosno takom). FQDN je ime domena koje sadri puno ime
nekog hosta. Ono sadri sve labele, od najkonkretnije do najoptije i na jedinstveni nain definie ime hosta. Na
primer: golijat.elfak.ni.ac.yu.
je FQDN ime raunara nazvanog golijat instaliranog na Elektronskom fakultetu u Niu. DNS server preslikava
jedino FQDN imena na IP adrese.
Delimino ime domena (PQDN - Partially Qualified Domain Name)
Labela koja nije zavrena takom naziva se PQDN imenom. PQDN poinje od posmatranog vora, ali ne dosee
do korena. PQDN se koristi kada ime koje treba preslikati pripada istom sajtu kao i klijent (onaj ko trai
preslikavanje). U ovom sluaju, deo koji nedostaje, tzv. sufiks, pridodaje program koji je zaduen za
preslikavanje imena, tzv. respolver, i tako formira FQDN. Na primer, korisnik sa sajta elfak.ni.ac.yu koji eli da
sazna IP adresu raunara golijat, moe definisati delimino ime: golijat
Pre nego to prosledi ime DNS serveru, DNS klijent dodaje sufiks elfak.ni.ac.yu. Normalno, DNS klijent
poseduje listu sufiksa. Lista sufiksa na Elektronskom fakultetu u Niu moe imati sledei oblik:
elfak.ni.ac.yu ni.ac.yu ac.yu null
(Sufiks null znai nita. golijat sa sufiksom null postaje golijat. (sa takom na kraju)).
Domen
Domen je podstablo prostora imena domena. Ime domena je ime domena vora na vrhu podstabla. Na Sl. 4-39 su
prikazani neki domeni. Uoimo da i sam domen moe biti podeljen na domene (ili poddomene, kako se
ponekada nazivaju).

Sl. 4-39 Domeni.

Podela prostora imena
Informacije sadrane u prostoru imena domena moraju negde biti smetene. U teoriji, dovoljan je jedan host koji
bi uvao sve informacije o prostoru imena Interneta i odgovarao na sve upite koji bi dolazili iz bilo kog kraja
sveta. Meutim, u praksi, takav jedan sever bi do te mere bio preoptereen da bi bio beskoristan. Uz to, ako bi
otkazao, ceo Internet bi stao.
Hijerarhija DNS servera
Reenje pomenutih problema je u distribuciji informacija na veliki broj raunara, tzv. DNS servera, tj. server za
prevoenje imena domena. To se moe uraditi tako to e se celokupan prostor podeli na domene shodno prvom
nivou. Drugim reima, slino kao na Sl. 4-39, za svaki vor sa prvog nivoa kreira se jedan domen koji obuhvate
sve vorove podstabla sa korenom u tom voru. Obzirom da domeni kreirani na ovaj nain mogu biti veoma
veliki, DNS omoguava podelu domena na manje domene (ili poddomene). Svaki server moe biti odgovoran za
jedan domen. Na taj nain, formira se hijerarhija servera, slino hijerarhiji imena.
Zona

51
Oblast odgovornosti DNS severa se naziva zonom. Zona se moe definisati kao povezani deo stabla. Ako je
server odgovoran za domen, a taj domen nije dalje podeljen na manje domene, tada je zona isto to i domen.
Server kreira bazu podataka, tzv. zonski fajl (eng. zone file) u kojoj uva sve informacije o svakom voru unutar
tog domena. Meutim, ako je domen servera podeljen na poddomene i deo njegovih odgovornosti prebaen na
druge servere, domen i zona vie nemaju isto znaenje. Informacije o vorovima iz poddomena uvaju se u
zonskim fajlovima servera sa niih nivoa, dok prvobitni server uva neku vrstu referenci na servere sa niih
nivoa. Naravno, vrni server se ne osloboa u potpunosti odgovornosti: on jo uvek ima zonu, ali se detaljne
informacije uvaju kod servera sa niih nivoa (Sl. 4-40).
Koren

com Zona

Domen
yahoo
Zona i
domen

Sl. 4-40 Zone i domeni.

Primarni i sekundarni serveri
DNS definie dva tipa servera: primarni i sekundarni. Primarni server je onaj koji na svom hard disku uva fajl o
zoni za koju je odgovoran. Primarni server kriera odrava i aurira zonski fajl.
Sekundarni server je server koji informacije o zoni dobija od nekog drugog servera (primarnog ili sekundarnog).
Sekundarni serveri ne kreiraju niti auriraju zonske fajlove. Ako je auruiranje neophodno, ono se obavlja na
primarnom serveru, koji potom sekundarnim serverima alje aurnu verziju.
I primarni i seknundarni serveri su odgovorni za zonu koju pokrivaju. Ideja nije da se sekundarni severi postave
na nii nivo odgovornosti u odnosu na primarni server, ve da se postigne redundantnost tako da u sluaju da
jedan server otkae preostali mogu nastaviti da opsluuju klijente.
Root server
Root (ili vrni) server je server iju zonu ini itavo stablo. Vrni server obino ne uva bilo kakve informacije o
domenima, ve delegira svoju odgovornost na druge servere, uvajui samo reference na te servere. Postoji
nekoliko vrnih server, distribuiranih po celom svetu, od kojih svaki pokriva celokupan prostor imena domena.
DNS na Internetu
Na Internetu, prostor imena domena (stablo) je podeljeno na dve sekcije: generiki (opti) domeni i nacionalni
domeni (Sl. 4-41). Labele generikih domena navedene su u tabeli T. 4-15. Svaka drava ima svoj nacionalni
domen. Generiki domeni su pod kontrolom organizacije ICANN. Imena nacionalnih domena su
standardizovana (ISO 3166).

Sl. 4-41 Generi

ki i nacionalni domeni.
T. 4-15 Generiki domeni.
Oznaka Opis
com komercijalne organizacije
edu obrazovne institucije
gov vladine institucije
int meunarodne organizacije
mil vojne grupacije
net centri za podrku mrei
org neprofitne organizacije
aero avio-kompanije
biz komercijalne organizacije i firme (slino .com)

52
 coop organizacije za kooperativno poslovanje
info informacioni servisi
museum muzeji i druge neprofitne organizacije
name lina imena (pojedinci)
pro profesionalne individualne organizacije
Na drugom nivou hijerarhije su domeni registrovani od strane kompanija, univerziteta i drugih privatnih, javnih
ili vladinih institucija ali i privatnih lica. Registracija takvog domena podrazumeva proveru da li je ime domena
slobodno i da li je registrovani zatitni znak. Ako nema problema, podnosilac zahteva, uz simbolinu novanu
godinju pretplatu, dobija prava korienja domena. Do danas, praktino sve este rei engleskog jezika su
zauzete.
Razreavanje imena
Proces preslikavanja imena na adrese ili adresa na imena naziva se razreavanjem ili rezolucijom (od
nameaddress resolution).
Razreiva
DNS je projektovan kao klijent-server aplikacija. Host kome je potrebno preslikavanje, bilo imena na adrese bilo
adresa na imena, poziva DNS klijenta koji se naziva razreivaem. Razreiva se obraa najbliem DNS serveru
za zahtevom za konkretno razreavanje. Ako poseduje traenu informaciju, server vraa odgovor razreivau;
inae, server upuuje rezreiva na nekog drugog servera ili se sam obraa drugim serverima kako bi pribavio
traenu informaciju. Kada dobije rezultat preslikavanja, razreiva najpre interpretira odgovor, da bi proverio da
li odgovor sadri traeno razreavanje ili greku, i konano, isporuuje rezultat procesu koji je zahtevao
razreavanje.
Najee, razreiva alje serveru ime domena traei od njega odgovarajuu adresu, to odgovara preslikavanju
imena na adrese. (Na primer, razreiva moe dobiti zahtev da razrei ime domena www.elfak.ni.ac.yu.) Mnogo
ree, klijent alje serveru IP adresu koju eli da preslika na odgovarajue ime domena. Ovakav tip upita se
naziva inverzinim upitom. (Na primer, razreiva moe dobiti zahev da pronae ime domena za IP adresu
160.99.13.134.)
Rekurzivno i iterativno razreavanje upita
Postoje dva naina obrade DNS upita: rekurzivno i iterativno razreavanje.
Rekurzivno razreavanje. Kod rekuzivne obrade DNS upita, klijent (razreiva) oekuje da konani odgovor na
svoj upit dobije direktno od servera kome je postavio pitanje. Ako je domen koji se trai u nadlenosti DNS
servera, razreiva direktno dobija odgovor. Meutim, ako se radi o udaljenom domenu, a informacija o njemu
nije dostupna na lokalnom DNS serveru, server alje zahtev nekom drugom serveru (obino roditeljskom
serveru) i eka na odgovor. Ako je odgovoran za ime domena, roditeljski server e vratiti odgovor, a ako nije,
prosledie upit sledeem serveru. Kada je upit konano razreen, odgovor se istom putanjom vraa unazad, od
servera do servera, sve dok konano ne stigne do klijenta koji je izdao prvobitni zahtev. Opisani princip je
prikazan na Sl. 4-42.

53
 3
5
8
6

Sl. 4-42 Rekurzivno razreavanje.

Iterativno razreavanje. Kod iterativnog razreavanja, server koji nije u mogunosti da obavi razreavanje ne
obraa se sledeem serveru, ve nazad vraa IP adresu servera za koga smatra da moe razreiti upit. Klijent
ponavlja upit i alje ga ovom drugom serveru. Ako zna odgovor, drugi server vraa klijentu odgovarajuu IP
adresu; inae, klijentu vraa IP adresu sledeeg DNS servera. Klijent se sada mora obratiti treem serveru i td.
Opisani proces se naziva iterativnim zato to klijent ponavlja isti upit ka vie servera. Na Sl. 4-43 klijent iz
domena fhda.edu koji zahteva razreavanje imena iz domena yahoo.com dobija konani odgovor tek od etvrtog
servera odgovornog za domen yahoo.com.

Sl. 4-43 Iterativno razreavanje.

Keiranje
Svaki put kada primi upit koji se odnosi na ime koje nije iz njegovog domena, server, nakon pretraivanja svoje
baze imena, prosleuje upit dalje odgovarajuem sledeem serveru. Zbog potrebe aktivnog uea veeg broja
servera, proces razreavanja, bilo da je se obavlja rekurzivno ili hijerarhijski, moe biti dugotrajan. Da bi se
vreme razreavanja skratilo, DNS koristi mehanizam keiranja. Server, svaki put kada primi odgovor na upti
poslat drugom serveru, smeta informacije iz odgovora u svoju ke memoriju, za sluaj da kasnije ponovo bude
potrebna. Ako nekada kasnije, isti, ili neki drugi klijent, zahtva isto preslikavanje, server e proveriti svoju ke
memoriju i obaviti zahtevano razreavanje, bez potrebe da upit alje nekom drugom serveru. Server vraa

54
odgovor klijentu, uz obavetenje da odziv dolazi iz ke memorije, a ne od servera koji je nadlean za domen na
koji se upit odnosi.
Keiranje ubrava razreavanje, ali i stvara nove probleme. Keirana preslikavanja nekog servera potiu iz
nekog drugog domena, za koji taj server nije odgovoran, a promena uinjena na udaljenom domenu se nee
preneti, sama od sebe u njegovu ke memoriju. Ako sever uva keirano preslikavanje isuvie dugo, moe se
desiti da odgovor koji alje klijentu postane nauurno. Da bi se ovaj problem prevaziao, koriste se dve tehnike.
Prvo, kada odgovara na upit koji se odnosi na domen za koji je nadlean, sever preslikavanju koje vraa
pridodaje i vreme ivota (TTL - time-to-live ). TTL je vreme u sekundama koje definie koliko dugo infomacija
iz odgovora moe boraviti u ke memoriji bilo kog severa koji doe u njen posed. Posle tog vremena,
preslikavanje se smatra zastarelim, a svaki sledei upit mora ponovo biti proleen nadlenom serveru. Drugo,
DNS zahteva da server svakoj stavci iz ke memoriju pridrui TTL broja. Ke memorija se periodino
pretrauje i sve stavke sa prekoraenim vremenom ivota se odstranjuju iz memorije.
DNS poruke
DNS definie dva tipa poruka: upit i odziv. Oba tipa imajuisti format. Poruka upita sadri: zaglavlje i zapis za
pitanje, poruka odziva: zaglavlje, zapis za pitanje, zapis za odgovor, zapis za nadlenost i dodatne zapise ( Sl. 4-
44).

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

Sl. 4-45 Format zaglavlja.

Polja zaglavlja imaju sledee znaenje:
Identifikacija. Ovo je 16-bitno polje koje slui klijentu da bi upario primljeni odziv sa ranije poslatim upitom. Za
svaku poruku upita, klijent koristi razliiti identifikacioni broj. Server kopira ovaj identifikacioni broj iz poruke
upita u odgovarajuu poruku odziva.
Markeri (Flags). Ovo je 16-bitno polje podeljeno na vie podpolja od kojih svako ima neko posebno zanenje
(Sl. 4-46).

Sl. 4-46 Polje za markere.

Markeri imaju sledee znaenje:
- QR (query/response - upit/odziv). Ovo je 1-bitno polje koje definie tip poruke. Ako je 0, poruka je
upit; ako je 1, poruka je odziv
- OpCode (kd operacije). Ovo je 4-bitno podpolje koje definie tip upita ili odziva. (0 za standardni, 1
za inverzni upit/odziv i 2 za zahtev za status servera).
- AA (authoritative answer - odgovor o nadlenosti). Ovo je 1-bitno polje koje postavljeno na 1 znai da
je server nadlean za ime domena na koje se poruka odnosi. Koristi se samo u poruci odziva.
- TC (truncated - odseeno). Ovo je 1-bitno polje koje postavljeno na 1 znai da je odziv bio dui od 512
bajta i da je skraen na 512 bajta. Koristi se samo ako DNS koristi UDP za transport upita/odziva.
- RD (recursion desired - rekurzija poeljna). Ovo je 1-bitno polje koje postavljeno na 1 znai da bi
klijent eleo da se razreavanje upita obavlja rekurzivno. Postavlja se poruci upita, a korpira u poruci
odziva.
- RA (recursion available - rekurzija je mogua). Ovo je 1-bitno polje koje kada je u poruci odziva
postavljeno na 1 znai da je rekurzivno razreavanje raspoloivo. Postalja se samo u poruci odziva.
- Reserved (rezervisano). 3-bitno polje fiksno postavljeno na 000.

55
 - rCode (kd greke). Ovo je 4-bitno polje koje ukazuje na status greke u odzivu. Status greke moe da
postavi samo nadleni server. Delimian spisak kdova dat je u tabeli. T. 4-16 Vrednosti polja rCode.
Vrednost Znaenje
0 Nema greke
1 Greka u formatu
2 Problem na strani servera imena
3 Problem u referenciranju domena
4 Tip pitanja nije podran
5 Administrativna zabrana
6-15 Rezervisano
Broj zapisa za pitanja. Ovo je 16-bitno polje koje sadri broj pitanja u sekciji poruke predvienoj za pitanja.
Broj zapisa za odgovore. Ovo je 16-bitno polje koje sadri broj odgovora u sekciji poruke odziva predvienoj za
odgovore. U poruci upita, vrednost ovog polja je sve nule.
Broj dodatnih zapisa. Ovo je 16-bitno polje koje sadri broj dodatnih zapisa u sekciji poruke odziva predvienoj
za dodatne zapise. U poruci upita, vrednost ovog polja je sve nule.
Sekcija za pitanja
Ova sekcija sadri jedan ili vie zapisa za pitanja. Sekcija je prisutna u poruci upita, ali i u poruci odziva.
(Format zapisa za pitanja bie objanjen neto kasnije).
Sekcija za odgovore
Ova sekcija sadri jedan ili vie zapisa za odgovore. Sekcija je prisutna samo u poruci odziva i sadri odgovor
koji server vraa klijentu (razreivau).
Sekcija za nadlenost
Ova sekcija je prisutna samo u poruci odziva i sadri jedan ili vie tzv. zapisa resursa. Sekcija sadri informaciju
o jednom ili vie servera koji su nadleni za ime domena iz odgovarajue poruke upita.
Sekcija za dodatne informacije
Ova sekcija sadri jedan ili vie zapisa resursa i prisutna je samo u poruci odziva. Sekcija sadri dodatne
informacije koje mogu biti od koristi razreivau. Na primer, server koji alje vraa poruku odziva klijentu moe
u sekciji za nadlenost upisati ime domena nadlenog servera, a u sekciji za dodatne informacije njegovu IP
adresu. Tipovi zapisa
Kao to je ve reeno prilikm opisa formata DNS poruke, kod DNS-a se koriste dva tipa zapisa: zapisi za pitanja
i zapisi za resurse. Zapisi za pitanja se koriste u sekciji za pitanja u porukama upita i odziva. Zapisi za resurse se
koriste u sekcijama za odgovore, nadlenosti i dodatne informacije poruke odziva. Zapis za pitanja
Zapis za pitanja koristi klijent da dobio informacije od servera. Konkretno, zapis sadri ime domena. Format
zapisa za pitanja prikazan je na Sl. 4-47.

Sl. 4-47 Format zapisa za pitanja.

Ime upita (Query Name). Ovo je polje promenljive duine koje sadri ime domena u formatu kao na Sl. 4-48.

Sl. 4-48 Format imena upita. Napomena: svakoj labeli prethodi broj slova u labeli; ime se zavrava cifrom 0.
Tip upita (Query Type). Ovo je 16-bitno polje koje definie tip upita. Neki od esto korienih tipovo upita dati
su u tabeli.
T. 4-17 Tipovi upita.
Tip Mnemonik Opis
1 A Adresa. 32-bitna IPv4. Koristi se za konverziju imena domena u IPv4 adresu
2 NS Server imena. Identifikuje nadleni server zone.
5 CNAME Kanoniko ime. Definie alternativno ime oficijelnog imena hosta.
6 SOA Poetak nadlenosti. Oznaava poetak zone. Obino prvi zapis u fajlu zone.
11 WKS Dobro-poznati servis. Definie mreni servis kojeg prua host.
12 PTR Pointer. Koristi se za konverziju IP adrese u ime domena.
13 HINFO Informacije o hostu. Sadri opis hardvera i operativnog sistema hosta
15 MX Mail izmenjiva (server). Saadri IP adresu mail servera domena.
28 AAAA Adresa. IPv6 adresa.
252 AXFR Trai se prenos celokupne zone.
255 ANY Trae se svi zapisi.
Klasa upita (Query class). Ovo je 16-bitno polje koje definie protokol kojeg DNS koristi. Za primenu na
Internetu od interesa je jedino klasa 1.
Zapisi resursa

56
Svakom imenu domena (tj. svakom voru iz stabla prostora imena) pridruen je jedan zapis koji se zove zapis
resursa. Baza imena servera zapravo sadri resurse zapisa. Takoe, resursi zapisa su ono sta sever vraa klijentu
kao odgovor na postavljeno pitanje. Na Sl. 4-49 je prikazan format zapisa resursa.

Sl. 4-49 Format zapisa resursa.

Ime domena (Domain name). Ovo je polje promenljive duine koje sadri ime domena. Iz razloga efikasnosti,
DNS zahteva da se u svim sluajevima kada se ime domena ponavlja vie puta u poruci odziva u ovom polju
umesto imena nalazi pointer na prvo pojavljivanje imena domena (obino u zapisu pitanja). Pointer je veliine 2
bajta. Prva dva bita su 11, a preostalih 14 predstavljaju redni broj bajta u poruci koji odgovara prvom slovu
imena domena (Sl. 4-50).

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

Tip domena (Domain type). Sadraj ovog polja je identian sadraju polja za tip upita iz zapisu pitanja s tim da
poslednja dva tipa nisu dozvoljena.
Klasa domena (Domain class). Sadraj ovog polja je identian sadraju polja za klasu upita iz zapisu pitanja.
Vreme ivota (Time to live). Ovo je 16-bitno polje koje definie vreme vaenja odgovora u sekundama.
Prijemnik moe da keira odgovor, ali po isteku vrmena ivota ima obavezu da ga odstrani iz ke memorije.
Vrednost nula u ovom polju znai zabranu kerianja informacije zapisa resursa.
Duina polja za podatke (Resourse data length). Ovo je 16-bitno polje koje definie duinu polja za podatke u
zapisu resursa.
Podaci o resursu (Resource data). Ovo je polje promenljive duine koje sadri odgovor na upit (ako se zapis
nalazi u sekciji za odgovore) ili ime domena nadlenog servera (ako se zapis resursa nalazi u sekciji za
nadlenosti) ili dodatne informacije (ako se zapis resursa nalazi u sekciji za dodatne informacije). Format i
sadraj ovog polja zavisi od tipa sadrane informacije i moe biti:
Broj. Zapisan u oktetima (bajtovima). Na primer, IPv4 adresa je inteder od 4 okteta.
Ime domena. Imena domena se predstavljaju kao niz labela. Svakoj labeli prethodi 1-bajtno polje koje definie
broj karaktera u labeli. Poto se svako ime domena zavrava praznom labelom, poslednji bajt svakog imena
domena je polje za dunu sa vrednou 0.
Pointer. Imena domena se mogu zameniti 2-bajtnim pointerom. Dva najvia bita pointera su uvek 11.

57
Opis sistema PAMETNA kua

Razvoj sistema kao to je Pametna kua nije nimalo jednostavan

posao. Stoga ga je potrebno podeliti u manje cjeline, tj. podsisteme, koji
e biti zadueni za upravljanje i nadzor pojedinih procesa unutar kue, te
za komunikaciju. Pametna kua je podeljena na sledee podsisteme:
o Ethernet komunikacija
o Upravljanje kuom u okviru lokalne mreze
o Upravljanje 8 releja

Takoe, u okviru projekta koriste se i digitalni senzori kao sto je

DHT11, senzor temperature i vlaznosti, BMP180, senzor pritiska, te se na
osnovu podataka dobijenih sa senzora donosi odluka o upravljanju
odredjenim relejem.

Povezivanje i protokol

Predlozene senzore koje cemo koristiti potrebno je meusobno iano povezati, i

to radi sigurnosti podataka i brzine upravljanja. Danas za tu svrhu postoje razni
naini povezivanja ureaja, kao to su: Ethernet, RS-232, modem,... U sklopu
ovog rada, odabrana je komunikacija putem Etherneta. To je vrsta mrene
tehnologije koja se koristi za izgradnju lokalnih mrea. Ethernet je dobar izbor iz
nekoliko glavnih razloga: velike rairenosti, jednostavnosti i niske cene
postavljanja mree Error: Reference source not found. Takoe, brzina
komunikacije Ethernetom je neuporedivo vea od ostalih nabrojenih metoda
(preko 1 Gbps), to moe biti od velikog znaaja za regulaciju brzim procesima
unutar ili izvan kue.
Za komunikaciju ureaja IP protokolom, potrebno je poznavati njihove IP adrese
(adrese ureaja na mrei), te port na kojem se alju, odnosno primaju poruke. U
doba kada ak i telefoni, televizori i kamere dobijaju IP adrese, bilo je sasvim
logino iskoristiti ovakvo provereno reenje u pametnoj kui.
IP omoguuje, na transportnom sloju, komunikaciju pomou dva protokola: TCP
(eng. Transmission Control Protocol) i UDP (eng. User Datagram Protocol). TCP
protokol omoguuje spor, ali pouzdan prenos podatataka.
Postojea reenja

58
 Prilikom razrade ideja o projektu pametna kua, zamiljeno je da se
pojedine komponente nee razvijati potpuno iz poetka, ve da se koriste
postojea reenja i njihove kombinacije.

Kako bi korisnicima olakao koritenje svojih proizvoda te omoguio brzo

zapoinjanje i provedbu projekata, Arduino je proizveo vlastiti programski paket
za programiranje, kompajliranje (eng. compiling) i prebacivanje programa na
mikrokontroler (eng. uploading) Error: Reference source not found. Programski
paket se isporuuje zajedno sa svim potrebnim bibiliotekama za koritenje
serijskog porta, memorije, pokaznika, itd., pa tako i Etherneta i TCP/IP protokola.
Zbog velike popularnosti Arduinovih mikrokontrolerskih ploica, postoji velika
zajednica korisnika koja uvelike doprinosi razvoju raznih mogunosti i softverskih
rjeenja. Tako se mogu pronai bibilioteke za koritenje UDP protokola, obradu
zvunog signala, slike,...

Izvedba komunikacije

Potrebne komponente
Za izradu ovog sustava koritene su slijedee komponente:

o Arduino Mega mikrokontrolerska ploica

o Arduino Ethernet Shield ploica
o Ruter
o UTP kabal
o USB kabel sa konektorima A-B
o LAN switch
o Arduino programski paket
Kratki opis komponenata

Arduino mikrokontrolerska ploica

Arduino je fiziko-raunarska platforma (razvojni sistem) otvorenog koda. Hardver se sastoji od

jednostavnog otvorenog hardverskog dizajna Arduino ploe sa Atmel AVR procesorom i prateim
ulazno-izlaznim elementima, tanije, na sebi poseduje mikrokontroler. Softver se sastoji od
razvojnog okruenja koje ine standardni kompajler i bootloader koji se nalazi na samoj ploi.
Arduino hardver se programira koristei programski jezik zasnovan na Wiring jeziku (sintaksa i
biblioteke). U osnovi je slian C++ programskom jeziku sa izvesnim pojednostavljenjima i
izmenama. Integrisano razvojno okruenje je zasnovano na Processing-u.
Arduino plou ine 8-bitni Atmel AVR mikrokontroler sa pripadajuim komponentama koje
omoguavaju programiranje i povezivanje sa drugom elektronikom. Bitan aspekt Arduino projekta
je standardizovan raspored konektora koji omoguava lako povezivanje sa dodatnim modulima,
poznatijim kao titovi. Ove dodatne module, titove, poizvode razni proizvoai irom sveta.
Zvanine Arduino ploe uglavnom koriste megaAvr seriju ipova, konkretno ATmega8,
ATmega168, ATmega328, ATmega1280 i ATmega2560. Veina ploa poseduje 5V linearni
naponski regulator i 16MHz kristalni oscilator (ili keramiki rezonator u nekim verzijama). Arduino
mikrokontroleri se isporuuju sa programiranim bootloader-om koji pojednostavljuje postupak
prebacivanja prevedenog koda u fle memoriju na ipu. Drugi mikrokontroleri obino zahtevaju
zaseban programator.

59
Arduino integrisano razvojno okruenje je aplikacija napisana u Java programskom jeziku.
Kreirano je tako da uvede u programiranje uenike, studente i ostale poetnike koji nisu upoznati
sa nainom razvoja softvera. Sastoji se od ureivaa koda sa mogunostima kao to su
oznaavanje koda, uparivanje zagrada, automatsko uvlaenje linija. Ovaj ureiva moe da
prevede kd a zatim ga i prebaci u ip jednom komandom. U ovom sluaju nije potrebno
podaavati parametre prevoenja koda ili pokretati programe iz komandne linije.

Slika 1. Arduino Duemilanove mikrokontrolerska ploica.

Arduino Ethernet Shield omoguava Arduinu da se povee preko interneta sa samo par minuta. Sve to treba da
uradite je da prikljuite ovaj modul na Arduino plou, poveete mreni kabl (proizvod se ne prodaje sa kablom) i
pratite nekoliko jednostavnih uputstava kako biste omoguili kontrolu i komunikaciju putem interneta. Ko i do
sada, svi elementi Arduino platforme, hardver, softver i dokumentacija su dostupni kao open-source i potpuno
besplatni. To znai da moete nauiti kako je tano napravljen i koristiti isti dizajn kao poetnu taku sa sopstvena
reenja. Stotine hiljada Arduino ploa irom sveta podstiu kreativnost raznih ljudi, svakog dana. Pridrui se
odmah, Arduino to si ti!

Za rad je neophodna osnovna Arduino ploa (prodaje se zasebno)

Radni napon od 5V (napajanje iz osnovne ploe)

Ethernet kontroler: W5100 sa unutranjim baferom od 16KB

Brzina konekcije: 10/100Mb

Veza sa Arduino ploom preko SPI porta

Arduino Ethernet Shield omoguava Arduino ploama da se poveu na internet. Zasnovan je na Wiznet W5100
ethernet ipu koji omoguava mrenu komunikaciju koristei TCP i UDP protokole. Podrava do etiri
istovremene socket konekcije. Za pisanje programa koji koriste ovaj shield dostupna je i Ethernet biblioteka.
Povezivanje sa Arduino ploom je izvedeno tako da su svi pinovi sa konektora osnovne ploe dostupni i na
konektoru shielda. Time je omogueno reanje modula jednih preko drugih uz zadravanje osnovnog rasporeda
pinova.Najnovija verzija ove ploe koristi 1.0 raspored pinova, kao na Rev3 Arduino Uno ploama.Ethernet Shield
ima standardni RJ-45 mreni konektor, sa integrisanim transformatorom i PoE mogunostima.

60
 Slika 2. Arduino Ethernet Shield.

Kabeli
Potrebne su dvije vrste kabela: za povezivanje na mreu, te za povezivanje na
USB sabirnicu. Ureaj se na mreu pak moe povezati sa dvije vrste UTP kabela, i
to sa ravnim (eng. straight) ili ukrienim (eng. crossover) vodovima. Ukrieni se
koriste za izravno spajanje ureaja sa drugim ureajem ili raunalom, dok ravni
slue spajanju na mreu preko switch-eva.
USB kabel je potreban za povezivanje Arduino mikrokontrolerske ploice sa
raunalom pomou kojeg je elimo isprogramirati. Osim u postupku
programiranja, takoer se moe koristiti i za uspostavljanje serijske veze sa
drugim ureajima, te prijenos podataka.

Slika 3. RJ-45 konektor za UTP Slika 4. USB kabel sa A i B

kabel. konektorom.

DHT-11 je senzor temperature i vlanosti vazduha sa jednoinim digitalnim interfejsom. Senzor je fabriki
kalibrisan i ne zahteva dodatne komponente tako da ga moete odmah upotrebiti za merenja. Sastoji se od
kapacitivnog senzora vlanosti vazduha, termistora za merenje temperature i elektronike za komunikaciju sa
mikrokontrolerom.

Tehnike karakteristike:

napajanje 5V DC

potronja struje 2.5mA (za vreme konverzije)

opseg temperature: 0-50C 2C

opseg vlanosti: 20-80% RH preciznost 5% RH

digitalni interfejs

61
KOD
//*********************************************************************************
***************
//***** Arduino mega u lokalnoj mrei kontrolie 8 releja i ita stanja sa nekih
senzora
//***** LCD je povezan preko I2C adaptera radi utede pinova na Arduinu
//***** Ethernet shield koristi pinove 10,11,12 i 13 na Arduinu.
//***** Analogni ulazi su pinovi od A0 do A5 (opciono za razna analogna
oitavanja)
//***** DHT11 na digital pin 34, VCC na 3V3!!! (nova verzija radi na 5v)
//***** Foto-otpornik na xx(definisano u kodu kasnije) + 10k ka masi, drugi kraj
na +5v
//***** BMP180 VCC na 3V3 !!! SCL na pin21(SCL), SDA na pin20(SDA)- nije
trenutno iskoriten
//***** I2C LCD adapter ide na SCL i SDA. BMP180 je izostavljen u tom sluaju
//***** PIR modul OUT na neki od analognih ulaza privremeno, kasnije ide na
digitalni pin
//***** Rele modul: IN1 na 2, IN2 na 3, IN3 na 4, IN4 na 5, IN5 na 6, IN6 na 7, IN7
na 8, IN8 na 9
//*********************************************************************************
****************

#include <SPI.h>
#include <Ethernet.h>
#include <dht11.h>
#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BMP085_U.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); // 0x27 je adresa I2C
adaptera za LCD,
// nije kod svih ista, sa Seriall_Scanner-om
// proitati adresu
DHT11 DHT11;
Adafruit_BMP085_Unified bmp = Adafruit_BMP085_Unified(10085);

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xEF }; // MAC address LAN
shield-a, nebitno, izmisliti neku.
byte gateway[] = { 192, 168, 1, 1 }; // ROUTER IP Addresa, adresa Gateway-a u
lokalnoj mrei
byte subnet[] = { 255, 255, 255, 0 }; // Subnet mask
IPAddress ip(192,168,1,5); // Adresa Arduina sa Ethernet shield-om koja je
dodaljena od strane rutera
EthernetServer server(80); //port 80 default za HTTP

#define RELAY_CH1 2 // digitalni pin 2 kontrolie rele 1

#define RELAY_CH2 3 // digitalni pin 3 kontrolie rele 2
#define RELAY_CH3 4 // digitalni pin 4 kontrolie rele 3
#define RELAY_CH4 5 // digitalni pin 5 kontrolie rele 4

62
#define RELAY_CH5 6 // digitalni pin 6 kontrolie rele 5
#define RELAY_CH6 7 // digitalni pin 7 kontrolie rele 6
#define RELAY_CH7 8 // digitalni pin 8 kontrolie rele 7
#define RELAY_CH8 9 // digitalni pin 9 kontrolie rele 8
#define DHT11PIN 34 // digitalni pin 34; stanje na senzoru DHT11
#define photocellPin 8 // digitalni pin 8; stanje na foto-otporniku
#define pirpin 0 // privremeno PIR na A0, kasnije ide na neki digitalni

String readString;
int svetlo1 = (analogRead(photocellPin)/10); // otprilike daje tanu temperaturu
void setup()
{
pinMode(RELAY_CH1, OUTPUT);
digitalWrite(RELAY_CH1, HIGH);
pinMode(RELAY_CH2, OUTPUT);
digitalWrite(RELAY_CH2, HIGH);
pinMode(RELAY_CH3, OUTPUT);
digitalWrite(RELAY_CH3, HIGH);
pinMode(RELAY_CH4, OUTPUT);
digitalWrite(RELAY_CH4, HIGH);
pinMode(RELAY_CH5, OUTPUT);
digitalWrite(RELAY_CH5, HIGH);
pinMode(RELAY_CH6, OUTPUT);
digitalWrite(RELAY_CH6, HIGH);
pinMode(RELAY_CH7, OUTPUT);
digitalWrite(RELAY_CH7, HIGH);
pinMode(RELAY_CH8, OUTPUT);
digitalWrite(RELAY_CH8, HIGH);

Serial.begin(9600); // Otvori serijsku komunikaciju

while (!Serial) { ; }
Ethernet.begin(mac, ip); // Pokreni Ethernet konekciju i server

server.begin(); // pokreni server

//Serial.print("server is at "); // serijski info

//Serial.println(Ethernet.localIP()); // adresa u lokalnoj mrei dodeljena od rutera

//******* Deo za BMP180 senzor koji je trenutno izostavljen *****

// sensor_t sensor;
// bmp.getSensor(&sensor);
// {
// if(!bmp.begin()) // Initialise sensor
// {
// while(1);
// }
// }
//******* Deo za BMP180 senzor koji je trenutno izostavljen *****
{
lcd.begin(16,2);

63
}

void loop() // Glavna petlja koja se konstantno izvrava

{
instanca1();
instanca2();

void instanca1()
{
Lcd_DHT11 ();
wait (2000);
// Lcd_Light_resistor ();
//wait (2000);
// Pir_sensor ();
// wait (2000);
}

void instanca2() // rezervno ime, da bi u void loop(); izgledalo loginije

{
web_server ();
}

/*void Pir_sensor ()
{
int pir = analogRead(pirpin);
lcd.clear ();
lcd.setCursor(0, 0);
lcd.print("Passive infrared");
lcd.setCursor(2, 1);
lcd.print("sensor = ");
lcd.print(pir);
}

void Lcd_Light_resistor ()
{
lcd.clear ();
int svetlo1 = (analogRead(photocellPin)/10);
lcd.setCursor(0, 0);

64
 lcd.print("Light intensity");
lcd.setCursor(7, 1);
lcd.print(svetlo1);
lcd.print("%");
}

*/

void Lcd_DHT11 ()
{
DHT11.read(DHT11PIN);
lcd.clear ();
lcd.setCursor(0, 0);
lcd.print("Temperatura:");
lcd.setCursor(12, 0);
lcd.print((float)DHT11.temperature, 0);
lcd.print("_C");
lcd.setCursor(3, 1);
lcd.print("Vlaznost:");
lcd.setCursor(12, 1);
lcd.print((float)DHT11.humidity, 0);
lcd.print("%");
}

void web_server ()
{
{

EthernetClient client = server.available();

if (client)
{
// Serial.println("new client");
boolean currentLineIsBlank = true;
while (client.connected())
{
if (client.available())

{
char c = client.read();
if (readString.length() < 100)
{
readString += c;
}
//Serial.write(c);
if (c == '\n' && currentLineIsBlank)

{
client.println("HTTP/1.1 200 OK");
client.println("Content-Type: text/html");

65
 client.println("Connection: close");
client.println("Refresh: 5"); // Osveava stranicu na 5 sekundi
client.println();
client.println("<!DOCTYPE HTML>");
client.println("<html>");
client.println("<HEAD>");
client.println("<meta name='apple-mobile-web-app-capable' content='yes'
/>");
client.println("<meta name='apple-mobile-web-app-status-bar-style'
content='black-translucent' />");
client.println("</HEAD>");
client.println("<body bgcolor=\"#D0D0D0\">");
client.print("<center> <p> <h1>SKLOP PREKIDACA </h1></p> ");
client.println("<center>");
client.println("<table border=\"5\">");
client.println("<tr>");

if (digitalRead(RELAY_CH1))
{
client.print("<td> <p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 1.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p> </td>");
}
else
{
client.print("<td> <p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 1.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
if (digitalRead(RELAY_CH2))
{
client.print("<td> <p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 2.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{
client.print("<td> <p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 2.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
if (digitalRead(RELAY_CH3))
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 3.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{

66
 client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 3.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
if (digitalRead(RELAY_CH4))
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 4.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 4.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
if (digitalRead(RELAY_CH5))
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 5.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 5.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
if (digitalRead(RELAY_CH6))
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 6.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 6.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
if (digitalRead(RELAY_CH7))
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 7.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 7.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");

67
}
if (digitalRead(RELAY_CH8))
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 8.</p><p style=\"font-family:arial;color:red;font-
size:35px;\">OFF</p></td>");
}
else
{
client.print("<td><p style=\"font-family:arial;color:black;font-
size:26px;\">Sklop 8.</p><p style=\"font-family:arial;color:green;font-
size:35px;\">ON</p></td>");
}
client.println("</tr>");
client.println("</table>");
client.println("</center>");
client.println("<br />");
client.println("<a href=\"/?relay1on\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\";>Sklop 1 ON </font>
</button> </a> ");
client.println("<a href=\"/?relay1off\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\">Sklop 1 OFF </font>
</button> </a> <br />");
client.println("<a href=\"/?relay2on\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\";>Sklop 2 ON </font>
</button> </a> ");
client.println("<a href=\"/?relay2off\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\">Sklop 2 OFF </font>
</button> </a> <br />");
client.println("<a href=\"/?relay3on\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\";>Sklop 3 ON </font>
</button> </a> ");
client.println("<a href=\"/?relay3off\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\">Sklop 3 OFF </font>
</button> </a> <br />");
client.println("<a href=\"/?relay4on\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\";>Sklop 4 ON </font>
</button> </a> ");
client.println("<a href=\"/?relay4off\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\">Sklop 4 OFF </font>
</button> </a> <br />");
client.println("<a href=\"/?relay5on\"\"> <button
style=\"width:120px;height:30px\"> <font size=\"3\";>Sklop 5 ON </font>
</button> </a> ");
client.println("<a href=\"/?relay5off\"\"><button
style=\"width:120px;height:30px\"> <font size=\"3\">Sklop 5 OFF </font>
</button> </a> <br />");
client.println("<a href=\"/?relay6on\"\"><button
style=\"width:120px;height:30px\"> <font size=\"3\";>Sklop 6 ON </font>
</button> </a> ");

68
 client.println("<a
style=\"width:120px;height:30px\"> <font
</button> </a> <br />");
client.println("<a
style=\"width:120px;height:30px\"> <font
</button> </a> ");
client.println("<a
style=\"width:120px;height:30px\"> <font
</button> </a> <br />");
client.println("<a
style=\"width:120px;height:30px\"> <font
</button> </a> ");
client.println("<a
style=\"width:120px;height:30px\"> <font
</button> </a> <br />");
href=\"/?relay6off\"\"><button
size=\"3\">Sklop 6 OFF </font>
href=\"/?relay7on\"\"><button
size=\"3\";>Sklop 7 ON </font>
href=\"/?relay7off\"\"><button
size=\"3\">Sklop 7 OFF </font>
href=\"/?relay8on\"\"><button
size=\"3\";>Sklop 8 ON </font>
href=\"/?relay8off\"\"><button
size=\"3\">Sklop 8 OFF </font>

if(readString.indexOf("?relay1on") >0)
{
digitalWrite(RELAY_CH1, LOW);
}
else{
if(readString.indexOf("?relay1off") >0)
{
digitalWrite(RELAY_CH1, HIGH);
}
}
if(readString.indexOf("?relay2on") >0)
{
digitalWrite(RELAY_CH2, LOW);
}
else{
if(readString.indexOf("?relay2off") >0)
{
digitalWrite(RELAY_CH2, HIGH);
}
}
if(readString.indexOf("?relay3on") >0)
{
digitalWrite(RELAY_CH3, LOW);
}
else{
if(readString.indexOf("?relay3off") >0)
{
digitalWrite(RELAY_CH3, HIGH);
}
}
if(readString.indexOf("?relay4on") >0)
{
digitalWrite(RELAY_CH4, LOW);
}
else{

69
if(readString.indexOf("?relay4off") >0)
{
digitalWrite(RELAY_CH4, HIGH);
}
}
if(readString.indexOf("?relay5on") >0)
{
digitalWrite(RELAY_CH5, LOW);
}
else
{
if(readString.indexOf("?relay5off") >0)
{
digitalWrite(RELAY_CH5, HIGH);
}
}
if(readString.indexOf("?relay6on") >0)
{
digitalWrite(RELAY_CH6, LOW);
}
else
{
if(readString.indexOf("?relay6off") >0)
{
digitalWrite(RELAY_CH6, HIGH);
}
}
if(readString.indexOf("?relay7on") >0)
{
digitalWrite(RELAY_CH7, LOW);
}
else
{
if(readString.indexOf("?relay7off") >0)
{
digitalWrite(RELAY_CH7, HIGH);
}
}
if(readString.indexOf("?relay8on") >0)
{
digitalWrite(RELAY_CH8, LOW);
}
else
{
if(readString.indexOf("?relay8off") >0)
{
digitalWrite(RELAY_CH8, HIGH);

}
}
{

70
 DHT11.read(DHT11PIN);
client.print("<font size=\"4\";>Temperatura A = </font> ");
client.print(DHT11.temperature);
client.print(" C");
client.println("<br />");

//******* Deo za BMP180 senzor koji je trenutno izostavljen *****

// sensors_event_t event;
// bmp.getEvent(&event);
// float temperature;
// bmp.getTemperature(&temperature);
// client.print("<font size=\"4\";>Temperature B = </font> ");
// client.print(int(temperature));
// client.print(" C");
// client.println("<br />");
//******* Deo za BMP180 senzor koji je trenutno izostavljen *****

client.print("<font size=\"4\";>Vlaznost = </font> ");

client.print(DHT11.humidity);
client.print(" %");
client.println("<br />");
//Lcd_DHT11 ();
}

//******* Deo za BMP180 senzor koji je trenutno izostavljen *****

// client.print("<font size=\"4\";>Pressure = </font> ");
// client.print(event.pressure);
// client.print(" hPa");
// client.println("<br />");
// float seaLevelPressure = SENSORS_PRESSURE_SEALEVELHPA;
// client.print("<font size=\"4\";>Altitude = </font> ");
//
client.print(bmp.pressureToAltitude(seaLevelPressure,event.pressure,temperature
));
// client.print(" m");
// client.println("<br />");
//******* Deo za BMP180 senzor koji je trenutno izostavljen *****

/* {
int svetlo1 = (analogRead(photocellPin)/10);
client.print("<font size=\"4\";>Light intensity = </font> ");
client.print(svetlo1);
client.println(" %");
client.println("<br />");
//Lcd_Light_resistor ();
}
{
int pir = analogRead(pirpin);
client.print("<font size=\"4\";>Senzor pokreta = </font> ");
client.print(pir);
//Pir_sensor ();

71
 } */
client.println("<br />");
client.println("<br />");
client.println("<br />");

// Stanje na analognim ulazima

client.println("<br />");
for (int analogChannel = 1; analogChannel < 6; analogChannel++)
{
int sensorReading = analogRead(analogChannel);
client.print("analog input ");
client.print(analogChannel);
client.print(" is ");
client.print(sensorReading);
client.println("<br />");
}

client.println("<hr> <p> By <a

href=\"http://androidcontrol.blogspot.com\"></p><p style=\"font-
family:arial;color:blue;font-size:20px;\"> MUHAMED </p></a>");

readString="";
client.println("</body>");
client.println("</html>");

break;
}
if (c == '\n') {

currentLineIsBlank = true;
}
else if (c != '\r') {
currentLineIsBlank = false;
}
}
}
wait(1);
client.stop();
//Serial.println("client disonnected");

}
}
}

// ***** WAIT *****

void wait(int _millis)

{
unsigned long timeOut=millis()+_millis;
while((long)(millis()-timeOut)<0)

72
{
}
}

IZGLED HTML STRANICE

73
 ZAKLJUCAK
Na kraju, moemo zakljuiti da je znaaj protokola i interfejsa u procesu prenosa podataka
veoma veliki. Protokoli predstavljaju skup unapred utvrenih pravila u procesu komunikacije,
i oni nam omoguavaju komunikaciju meu raunarskim i softverskim sistemima razliitih
proizvoaa. Deljenjem kompleksnog procesa komunikacije na nivoe i slojeve, oni
obezbeuju pouzdanu, sigurnu i brzu komunikaciju i staraju se o tome da poruka koju
poiljalac alje do primaoca stigne u istovetnom stanju u kome je i poslata. Interfejsi
omoguavaju komunikaciju meu slojevima protokola, ulaznih i izlaznih stanica u ruteru,
meu mreama i izmeu samog korisnika i raunara i njegovih perifernih delova, takoe
znaajnih za komunikaciju. OSI i TCP/IP referentni modeli skupa protokola predstavljaju
standarde koji definiu principe na kojima bi svi sistemi komunikacije i prenosa podataka
trebali da funkcioniu, ukljuujui i globalnu mreu Internet. Meutim, da bi protokoli i
interfejsi mogli obavljati svoje funkcije, neophodno je i postojanje rutera (raunara) koji
omoguavaju povezivanje vie razliitih raunarskih mrea i sistema. Poto je danas
tehnologija u eri neprekidnog i ubrzanog razvoja a komunikacija i prenos podataka putem
mrea postala vitalan deo svakodnevnog ivota, protokoli i interfejsi se idalje razvijaju, izdaju
se novi standardi i modeli i moemo samo usko nagaati kako e, kroz odreeni niz godina,
izgledati i funkcionisati razmena podataka.

74
Sustavom opisanim u ovom projektu omoguena je komunikacija izmeu razliitih
dijelova inteligentne kue. Zahvaljujui odabranim standardima i protokolima
(Ethernet i TCP/IP), omoguena je sigurna, a opet brza komunikacija. Pouzdanost
prijenosa je od vrlo velikog znaaja za ovu primjenu, jer se ne smije dopustiti da
npr. informacije iz alarmnog sustava ne stignu na odredite. Odabrani TCP/IP
protokol nam upravo to omoguava, a sam Ethernet je ve dugotrajno koritena i
isprobana tehnologija, to nam jami ispravnost njegovog odabira. Komunikacija
izmeu podsustava je uspjeno provedena, to potvruje ostvarenost ciljeva
zadanih u uvodu, te opravdava sredstva kojima smo doli do njih.

75