Ključne teme računarskih mreža

Autor: Yueban Feiyu, izvorna veza: https://mp.weixin.qq.com/s/7EddtzpwIRvYfw34QE4zvw

OSI model sa sedam slojeva

Fizički sloj

Prvo se rešava potreba za komunikacijom između dve fizičke mašine: mašina A šalje tok bitova ka mašini B, a mašina B taj tok primi.

Fizički sloj uglavnom definiše standarde za fizičke uređaje, kao što su tip mrežnog kabla, tip optičkog priključka i brzine prenosa različitih medijuma.

Glavna uloga mu je prenos toka bitova (0101 binarni podaci) — pretvaranje toka bitova u jačinu struje radi prenosa, a na odredištu ponovo u tok bitova, odnosno ono što se obično naziva digitalno-analognom i analognodigitalnom konverzijom.

Podaci na ovom sloju nazivaju se bitovima. Mrežna kartica radi na ovom sloju.

Fizički sloj je fizička osnova OSI modela sa sedam slojeva — bez njega nema prenosa podataka.

Fizički sloj se oslanja na fizičke objekte, pa ako bismo tražili poređenje, putevi, automobili i avioni — prevozna sredstva koja prevoze teret (podatke) — simbolizuju fizički sloj.

Sloj veze podataka

Tokom prenosa toka bitova postoji mogućnost greške u prenosu ili nepotpunog prenosa podataka.

Sloj veze podataka definiše kako se podaci formatiraju za prenos i kako se kontroliše pristup fizičkom medijumu. Obično obezbeđuje detekciju i ispravku grešaka, čime se garantuje tačnost prenosa podataka.

Ovaj sloj grupiše bitove u okvire (frame); svič radi na ovom sloju, dekodira okvire i, na osnovu informacija sadržanih u okviru, šalje podatke pravom primaocu.

Ovaj sloj je odgovoran za komunikaciju između fizički međusobno povezanih čvorova. Na primer, komunikacija između dva čvora povezana na jednu Ethernet mrežu.

Česti protokoli su HDLC,PPP,SLIP i slični.

Sloj veze podataka deli niz 0,1 u okvire sa značenjem i šalje ih drugoj strani (formiranje i prijem okvira podataka).

Mrežni sloj

Sa stalnim rastom broja mrežnih čvorova, komunikacija između tačaka prolazi kroz više čvorova — kako pronaći ciljni čvor i kako izabrati optimalnu putanju postaje primarna potreba.

Glavna funkcija mrežnog sloja je pretvaranje mrežnih adresa u odgovarajuće fizičke adrese i odlučivanje kako se podaci rutiraju od pošiljaoca do primaoca.

Mrežni sloj, uzimajući u obzir prioritet slanja, stepen zagušenja mreže, kvalitet usluge i cenu opcionalnih ruta, donosi odluku o optimalnoj putanji od čvora A u jednoj mreži do čvora B u drugoj mreži.

Pošto mrežni sloj obrađuje i inteligentno usmerava prenos podataka, a ruteri povezuju mrežne segmente, ruteri pripadaju mrežnom sloju.

Podaci na ovom sloju nazivaju se paketima (packet). Protokoli koje ovde treba pratiti su IP protokol iz TCP/IP protokola.

Mrežni sloj je odgovoran za dostavljanje podataka na ciljnu adresu. Ciljna adresa može biti jedna od adresa u mreži koja je nastala povezivanjem više mreža preko rutera. Zato je ovaj sloj uglavnom odgovoran za adresiranje i izbor rute. Sastoji se pretežno od dva protokola: IP i ICMP.

Mrežni sloj šalje podatke od hosta pošiljaoca do hosta primaoca; između dva hosta može postojati više veza podataka, ali mrežni sloj pronalazi relativno nesmetanu putanju kojom će podatke proslediti. Za prenos se koriste IP adrese. IP adresa se stalnim prosleđivanjem ka bližoj IP adresi konačno stiže do ciljne adrese.

Transportni sloj

Sa daljim širenjem potreba za mrežnom komunikacijom, u toku komunikacije treba poslati velike količine podataka, poput prenosa ogromnih fajlova, što može potrajati dugo; mreža će tokom komunikacije prekidati vezu mnogo puta. Da bi se pri prenosu velikih fajlova očuvala tačnost, poslate podatke treba podeliti na segmente (Segement) koji se šalju pojedinačno; da li ponovo preneti izgubljeni segment i da li segmenti stižu po redosledu, pitanja su koja razmatra transportni sloj.

Transportni sloj rešava prenos podataka između hostova; prenos može ići preko različitih mreža, a transportni sloj rešava problem kvaliteta prenosa.

Protokoli koje transportni sloj treba da prati su TCP i UDP iz TCP/IP protokola.

Sloj sesije

Automatsko slanje i prijem paketa, automatsko adresiranje.

Uloga sloja sesije je da odgovara za uspostavljanje i raskidanje veze — kada se uspostavlja, kada prekida i koliko dugo traje. Česti protokoli su ADSP,RPC i slični.

Prezentacioni sloj

Kada Linux šalje paket ka Windowsu, sintaksa se razlikuje između sistema — na primer, exe ne može da se izvrši na Linuxu, a shell ne može direktno da se pokrene na Windowsu. Zato je potreban prezentacioni sloj.

Rešava problem sintakse komunikacije između različitih sistema; na prezentacionom sloju podaci se formatiraju prema šemi koju mreža razume, a formatiranje zavisi od mreže koja se koristi.

Uglavnom je odgovoran za konverziju formata podataka. Konkretno, podatke u formatu specifičnom za uređaj pretvara u mrežni standardni format. Česti protokoli su ASCII,SSL/TLS i slični.

Aplikativni sloj

Propisuje da pošiljalac i primalac moraju koristiti zaglavlje poruke fiksne dužine, da zaglavlje mora imati određenu fiksnu strukturu i da u zaglavlju moraju biti zabeleženi podaci poput dužine tela poruke, kako bi primalac mogao ispravno da raščlani podatke koje šalje pošiljalac.

Aplikativni sloj ima za cilj da olakša aplikacijama prijem podataka iz mreže, sa posebnim fokusom na HTTP protokol iz TCP/IP protokola.

Podaci transportnog sloja (četvrti sloj) nazivaju se segmentima (Segments);

Podaci mrežnog sloja (treći sloj) nazivaju se paketima (Packages);

Podaci sloja veze podataka (drugi sloj) nazivaju se okvirima (Frames);

Podaci fizičkog sloja (prvi sloj) nazivaju se tokom bitova (Bits).

TCP i IP model

OSI model naglašava funkcije koje su nužne za komunikacione protokole; TCP/IP više ističe koju vrstu programa treba razviti da bi se protokol implementirao na računaru.

TCP/IP deli mrežni model na četiri sloja

• Prvi sloj: aplikativni sloj — uglavnom sadrži HTTP protokol zadužen za web pregledače, FTP protokol za prenos fajlova, SMTP protokol za e-poštu, DNS za sistem domenskih imena i slično.
• Drugi sloj: transportni sloj — uglavnom sadrži TCP protokol za pouzdan prenos i UDP protokol koji je posebno efikasan. Glavno je zadužen za prenos paketa aplikativnog sloja.
• Treći sloj: mrežni sloj — uglavnom IP protokol. Glavno je zadužen za adresiranje (nalaženje lokacije ciljnog uređaja).
• Četvrti sloj: sloj veze podataka — uglavnom je zadužen za konverziju između digitalnog signala i fizičkog binarnog signala.

Uloga četveroslojnog mrežnog protokola

• Na strani pošiljaoca ide se odozgo nadole: podaci koji dolaze sa gornjeg sloja dobijaju na vrhu zaglavlje sa podacima tog sloja (preamble) i prosleđuju se sloju ispod.
• Na strani primaoca ide se odozdo nagore: podaci primljeni sa donjeg sloja se dešifruju i skida im se zaglavlje, pa se šalju gornjem sloju.
• Nakon slojevitog šifrovanja i dešifrovanja, aplikativni sloj konačno dobija podatke koji su mu potrebni.

Na primer:

Treba da pošaljemo jedan index.html.

Oba računara na aplikativnom sloju koriste HTTP protokol (odnosno oba koriste pregledač).

Na transportnom sloju, TCP protokol posmatra podatke koje šalje HTTP protokol kao jedan paket i ispred tog paketa dodaje deo informacije TCP paketa (preamble).

Na mrežnom sloju, IP protokol posmatra podatke koje TCP protokol treba da pošalje kao paket i isto tako ispred tog paketa dodaje IP zaglavlje.

Na sloju veze podataka, odgovarajući protokol ispred IP paketa dodaje Ethernet zaglavlje.

Izvorni i ciljni uređaj su povezani mrežnim kablom, pa preko binarnog prenosa na fizičkom sloju mogu razmenjivati podatke.

Sloj veze podataka, koristeći odgovarajući protokol, pronalazi binarne podatke na fizičkom sloju, dekodira Ethernet zaglavlje i odgovarajući IP paket, a zatim IP paket prosleđuje gornjem mrežnom sloju.

Sloj veze podataka > mrežni sloj > transportni sloj > aplikativni sloj — dekodiranjem sloj po sloj, konačno se u pregledaču dobija index.html koji je poslao ciljni uređaj.

Familija TCP/IP protokola

U doslovnom smislu, TCP/IP označava TCP protokol transportnog sloja i IP protokol mrežnog sloja.

U stvari, TCP/IP je zajednički naziv za grupu protokola koji su nužni pri komunikaciji pomoću IP-a.

Konkretno, na mrežnom sloju su IP/ICMP protokoli, na transportnom sloju TCP/UDP protokoli, a na aplikativnom sloju SMTP, FTP i HTTP i slični. Svi oni pripadaju TCP/IP protokolima.

Mrežni uređaji

Svič

Svič može da priključi više računara.

MAC adresa mrežne kartice svakog računara je drugačija; kada računar šalje podatke, zaglavlje podataka nosi MAC adresu kartice, pa se MAC adresa koristi za razlikovanje računara.

Svič može da prepozna MAC adresu u zaglavlju podataka i tako razlikuje različite računare.

Pored toga što razlikuje računare, svič mora i da pronađe port sviča na koji je računar povezan, kako bi podatke uspešno poslao kroz odgovarajući port.

Svič putem mehanizma samoučenja dodaje naučene MAC adrese uređaja i brojeve portova sviča u MAC tabelu adresa, i na osnovu nje vrši prosleđivanje podataka.

Ruter

MAC tabela koju svič mora da vodi postaje sve veća, a potreban je i sve veći broj svičeva.

Međutim, kapacitet i performanse sviča su ograničeni: MAC tabela ne može da zabeleži MAC adrese i odgovarajuće portove svih računara na svetu, a i prevelika MAC tabela ne bi dozvolila brzo pronalaženje odgovarajućeg zapisa.

Zato se pojavio mrežni uređaj trećeg sloja — ruter — koji može da poveže mreže celog sveta.

Za povezivanje mreža unutar lokalne mreže koristi se svič; na primer, mreža unutar jedne firme ili jednog kampusa povezuje se preko sviča.

Za međusobno povezivanje lokalnih mreža u različitim područjima koristi se ruter.

Kako onda razlikovati različita mrežna područja? I kako se podaci prosleđuju između mrežnih područja?

Ruter ima više portova koji povezuju različita mrežna područja, a mrežni broj IP adrese razlikuje se između područja.

On prepoznaje mrežni broj ciljne IP adrese, a zatim na osnovu tabele rutiranja vrši prosleđivanje podataka.

HTTP

Metode zahteva

HTTP1.0 definiše tri metode zahteva: GET, POST i HEAD.

HTTP1.1 dodaje šest metoda zahteva: OPTIONS, PUT, PATCH, DELETE, TRACE i CONNECT.

Br.	Metoda	Opis
1	GET	Traži informacije o navedenoj stranici i vraća telo entiteta.
2	HEAD	Slično GET zahtevu, samo što u odgovoru nema konkretnog sadržaja; koristi se za dobavljanje zaglavlja.
3	POST	Šalje zahtev sa podacima ka navedenom resursu na obradu (npr. slanje formulara ili upload fajla). Podaci su sadržani u telu zahteva. POST zahtev može dovesti do uspostavljanja novog resursa i/ili izmene postojećeg.
4	PUT	Podaci koje klijent šalje serveru zamenjuju sadržaj navedenog dokumenta.
5	DELETE	Traži od servera da obriše navedenu stranicu.
6	CONNECT	U HTTP/1.1 protokolu rezervisano za proxy servere koji mogu prebaciti konekciju u tunelski režim.
7	OPTIONS	Dozvoljava klijentu da pregleda performanse servera.
8	TRACE	Vraća (eho) zahtev koji je server primio, uglavnom za testiranje ili dijagnostiku.
9	PATCH	Dopuna PUT metodi, koristi se za delimičnu izmenu poznatog resursa.

Razlika između GET i POST zahteva

1. Parametri GET zahteva dodaju se u zaglavlje i vide se u URL-u; parametri POST zahteva dodaju se u telo i ne vide se u URL-u.
2. URL zahteva ima ograničenje dužine koje određuju i podešavaju pregledač i web server; na primer, IE pregledač ima maksimalno ograničenje od 2083 znaka za URL — ako se pređe ovaj broj, dugme za slanje ne reaguje. Pošto se parametri GET zahteva dodaju u URL, u ograničenje dužine URL-a GET zahteva mora se uračunati i dužina parametara. POST zahtev ne mora da razmatra dužinu parametara.
3. GET zahtev stvara jedan paket; POST zahtev stvara dva paketa (u Firefox pregledaču stvara jedan paket). Razlika je u mehanizmu pregledača: prvo se šalje zaglavlje zahteva, pa telo zahteva — pošto GET nema telo zahteva, šalje se jedan paket, dok POST sadrži telo zahteva pa se šalju dva paketa; međutim, zbog drugačijeg mehanizma Firefox šalje jedan paket.
4. GET zahtev pregledač aktivno kešira i ostavlja trag u istoriji, dok POST podrazumevano ne.
5. GET je idempotentan, a POST nije (idempotentnost znači da ponavljanje iste operacije daje isti rezultat).
6. GET služi za dobavljanje podataka, POST za izmenu podataka.

Statusni kodovi

Statusni kod sačinjavaju tri cifre, pri čemu prva definiše kategoriju odgovora

1XX: informativno, znači da je zahtev primljen i obrada se nastavlja.

2XX: uspeh, znači da je zahtev uspešno primljen, razumevan i prihvaćen.

• 200 OK je najčešći statusni kod uspeha i znači da je sve u redu. Ako nije HEAD zahtev, odgovor servera u telu sadrži podatke (body).

• 204 No Content je takođe čest statusni kod uspeha, u suštini isti kao 200 OK, ali u odgovoru nema podataka u telu.

• 206 Partial Content koristi se kod HTTP preuzimanja u delovima ili nastavka prekida; znači da telo odgovora ne predstavlja ceo resurs već njegov deo — takođe je status uspešne obrade na serveru.

3XX: statusni kod znači da je traženi resurs klijenta promenjen i da klijent mora ponovo poslati zahtev sa novim URL-om da bi dohvatio resurs, odnosno redirekcija.

• 301 Moved Permanently označava trajnu redirekciju, što znači da traženi resurs više ne postoji i da treba koristiti novi URL za pristup; pretraživači pri hvatanju novog sadržaja istovremeno menjaju staru adresu u adresu nakon redirekcije.
• 302 Moved Permanently označava privremenu redirekciju, što znači da resurs i dalje postoji, ali mu se trenutno pristupa preko drugog URL-a; pretraživač će hvatati novi sadržaj, a čuvati staru adresu.

I 301 i 302 u zaglavlju odgovora koriste polje Location kojim se navodi URL na koji treba preći, a pregledač automatski vrši redirekciju na novi URL.

• 304 Not Modified nema značenje redirekcije; označava da resurs nije izmenjen, odnosno da se koristi keširani fajl koji već postoji — poznato i kao redirekcija ka kešu, koristi se za kontrolu keširanja.

4XX: statusni kod znači da je poruka koju je poslao klijent pogrešna i da server ne može da je obradi, odnosno označava kod greške.

• 400 Bad Request znači da je poruka klijentovog zahteva pogrešna.

• 401 Unauthorized: nedostaje ili je pogrešna autentifikacija; ovaj statusni kod mora se koristiti zajedno sa poljem zaglavlja WWW-Authenticate.

• 403 Forbidden znači da server zabranjuje pristup resursu, a nije do greške u klijentovom zahtevu.

• 404 Not Found znači da traženi resurs ne postoji ili nije pronađen na serveru, pa se ne može dostaviti klijentu.

5XX: statusni kod znači da je poruka zahteva klijenta ispravna, ali je pri obradi na serveru došlo do interne greške — to su statusni kodovi grešaka na strani servera.

• 501 Not Implemented znači da funkcionalnost koju klijent zahteva još uvek nije podržana.

• 502 Bad Gateway obično je kod greške koji vraća server kada radi kao gateway ili proxy; znači da sam server radi normalno, ali je prilikom pristupa bek-end serveru došlo do greške.

• 503 Service Unavailable znači da je server trenutno veoma zauzet i privremeno ne može da odgovori.

• 504 Gateway Timeout: gateway je istekao; koristi ga server koji radi kao proxy ili gateway i znači da nije mogao blagovremeno dobiti odgovor od udaljenog servera.

Razlika između 301 i 302

301 redirekcija označava trajni prenos stranice, odnosno da je resurs ili stranica trajno premeštena na drugu lokaciju.

301 je statusni kod u HTTP protokolu; kada korisnik ili pretraživač pošalje zahtev serveru za pregled, u zaglavlju HTTP toka koji server vraća nalazi se statusni kod 301, što znači da je resurs trajno promenio lokaciju.

302 redirekcija je privremeni prenos stranice; pretraživač hvata novi sadržaj, a čuva staru adresu smatrajući da je nova adresa samo privremena.

HTTP1.1

Duga veza (persistentna konekcija)

HTTP 1.1 podržava dugu vezu.

HTTP 1.0 propisuje da pregledač i server održavaju samo kratku vezu — svaki zahtev pregledača mora sa serverom uspostaviti novu TCP konekciju, a server odmah nakon obrade zahteva prekida TCP konekciju; server ne prati svakog klijenta i ne pamti prošle zahteve.

HTTP 1.1 podržava persistentnu konekciju (Persistent Connection) i podrazumevano je koristi; unutar iste TCP konekcije može se preneti više HTTP zahteva i odgovora, više zahteva i odgovora se može preklapati, odnosno više zahteva i odgovora može se odvijati istovremeno, uz bogatije zaglavlje zahteva i odgovora.

Da bi se realizovala persistentna konekcija HTTP 1.1, potrebno je dodati nova zaglavlja zahteva: kada vrednost zaglavlja Connection iznosi Keep-Alive, klijent obaveštava server da nakon rezultata ovog zahteva održi vezu; kada vrednost zaglavlja Connection iznosi Close, klijent obaveštava server da nakon rezultata ovog zahteva prekine vezu.

Prenos preko cevdovoda (pipeline)

HTTP/1.1 koristi dugu vezu, što omogućuje i prenos preko cevdovoda.

Dakle, unutar iste TCP konekcije klijent može pokrenuti više zahteva — čim je prvi zahtev poslat, ne mora da čeka odgovor, već može poslati i drugi zahtev, čime se smanjuje ukupno vreme odgovora.

Na primer, klijentu treba da zatraži dva resursa. Ranije je, unutar iste TCP konekcije, prvo slao zahtev A, čekao odgovor servera, pa po prijemu slao zahtev B; mehanizam cevdovoda dozvoljava pregledaču da istovremeno pošalje i zahtev A i zahtev B.

Međutim, server i dalje po redosledu prvo odgovara na zahtev A, pa tek nakon toga na zahtev B — ako je prvi odgovor posebno spor, mnogo zahteva će se naći u redu čekanja.

Polje Host

U HTTP1.0 se smatralo da je svaki server vezan za jedinstvenu IP adresu, pa URL u poruci zahteva nije prenosio ime hosta. Sa razvojem tehnologije virtuelnih hostova, na jednom fizičkom serveru može postojati više virtuelnih hostova koji dele istu IP adresu.

HTTP1.1 zahteva da i poruka zahteva i poruka odgovora podržavaju Host zaglavlje, a ako u poruci zahteva nedostaje Host zaglavlje, prijavljuje se greška (400 Bad Request).

Pored toga, server treba da prihvati zahteve za resurse označene apsolutnom putanjom.

100 Status

HTTP/1.1 uvodi novi statusni kod 100.

Klijent prethodno pošalje zahtev koji sadrži samo zaglavlje; ako server zbog ovlašćenja odbije zahtev, vraća kod odgovora 401 (Unauthorized);

Ako server prihvati zahtev, vraća kod odgovora 100 i klijent tada može nastaviti da šalje kompletan zahtev sa telom entiteta.

Korišćenje statusnog koda 100 dozvoljava klijentu da, pre nego što pošalje telo (body) request poruke, pomoću request zaglavlja proveri da li server želi da primi request telo, pa tek onda odluči da li će ga poslati.

Chunked Transfer Coding

HTTP/1.1 omogućava pošiljaocu da podeli poruku u proizvoljno velike blokove podataka; pri slanju svaki blok dobija podatke o svojoj dužini, a na kraju se blokom dužine nula označava kraj poruke.

Ovaj pristup dozvoljava pošiljaocu da baferuje samo jedan fragment poruke, čime se izbegava preopterećenje od baferovanja cele poruke.

Cache (keš)

HTTP/1.1 na osnovu verzije 1.0 dodaje neke nove karakteristike keširanja: kada starost (Age) keširanog objekta pređe Expire, postaje Stable objekat — Cache ne mora odmah da odbaci Stable objekat, već ga reaktivira sa izvornim serverom.

HTTP2.0

Nove karakteristike HTTP2.0 u odnosu na HTTP1.X

• Novi binarni format — analiza HTTP1.x zasniva se na tekstu.

• Multipleksiranje, odnosno deljenje konekcije: svaki request koristi se kao mehanizam deljenja konekcije — jedan request odgovara jednom id-u, tako da na jednoj konekciji može biti više zahteva, a zahtevi svake konekcije mogu se mešati; primalac na osnovu id-a zahteva ponovo razvrstava zahteve u različite serverske zahteve.

• Kompresija zaglavlja: zaglavlje HTTP1.x nosi mnogo informacija i mora se ponovo slati svaki put; HTTP2.0 koristi encoder da smanji veličinu zaglavlja koje treba preneti, a obe strane komunikacije keširaju po jednu tabelu header fields — čime se izbegava ponovni prenos istih zaglavlja i smanjuje veličina koja se prenosi.

• Server push (guranje sa servera).

HTTP/2 je do izvesne mere i poboljšao tradicionalni režim rada zahtev—odgovor: server više nije samo pasivno odgovara, već može i aktivno slati poruke klijentu.

Na primer, čim pregledač zatraži HTML, server unapred može aktivno poslati klijentu statičke resurse poput JS i CSS fajlova koji bi mogli zatrebati, čime se smanjuje čekanje na kašnjenje — to je upravo server push.

Tok podataka (Stream)

Paketi HTTP/2 ne šalju se po redosledu; uzastopni paketi unutar iste konekcije mogu pripadati različitim odgovorima.

Zato pakete treba označiti i navesti kom odgovoru pripadaju.

Svi paketi jednog zahteva ili odgovora nazivaju se tok podataka (Stream).

Svaki tok nosi jedinstveni broj, pri čemu je propisano da tok koji šalje klijent ima neparan broj, a tok koji šalje server paran broj.

Klijent može i da odredi prioritet toka. Za zahtev visokog prioriteta server će prvo odgovoriti.

Kakva je razlika između multipleksiranja u HTTP2.0 i ponovnog korišćenja duge veze u HTTP1.X

• Pipeling HTTP/1.1 serijalizuje (u redu) više zahteva na jednoj niti obrade — kasniji zahtevi čekaju povratak ranijih da bi dobili priliku za izvršenje; ako jedan zahtev istekne, kasniji zahtevi mogu samo da budu blokirani, bez ikakvog načina da se to izbegne.
• HTTP2.0 dozvoljava da više zahteva istovremeno paralelno ide na jednoj konekciji, pa ako jedan zahtev znatno duže traje, to ne utiče na normalno izvršenje ostalih konekcija.

HTTP3.0

Korišćenje UDP protokola

Glavni problem HTTP/2 je u tome što više HTTP zahteva ponovo koristi jednu TCP konekciju, a TCP protokol na donjem sloju ne zna koliko HTTP zahteva postoji.

Zato čim dođe do gubitka paketa, pokreće se TCP mehanizam retransmisije, pa svi HTTP zahtevi unutar jedne TCP konekcije moraju čekati da se izgubljeni paket ponovo prenese.

• U cevdovodnom prenosu HTTP/1.1, ako jedan zahtev zastane, svi zahtevi iza njega u redu takođe bivaju blokirani.
• HTTP/2 više zahteva koristi jednu TCP konekciju — jednom kad dođe do gubitka paketa, blokira sve HTTP zahteve.

Sve je to problem TCP transportnog sloja, pa je HTTP/3 zamenio TCP protokol na donjem sloju HTTP-a UDP-om!

HTTPS

Razlika između HTTP i HTTPS

HTTP je protokol prenosa u otvorenom tekstu (cleartext), dok je HTTPS mrežni protokol koji za šifrovani prenos i autentifikaciju identiteta nastaje kombinacijom SSL+HTTP protokola i bezbedniji je od HTTP-a.

• HTTPS je bezbedniji od HTTP-a, prijatniji za pretraživače i povoljniji za SEO — Google i Baidu daju prednost indeksiranju HTTPS stranica.

• HTTPS zahteva SSL sertifikat, a HTTP ne.

• Standardni port HTTPS je 443, a HTTP 80.

• HTTPS se oslanja na transportni sloj, a HTTP na aplikativni sloj.

• HTTPS u pregledaču prikazuje zeleni sigurnosni katanac, a HTTP ne.

Princip rada

HTTPS protokol šifrira podatke koji se prenose, a proces šifrovanja realizuje se asimetričnom enkripcijom.

Ceo proces HTTPS-a deli se na fazu verifikacije sertifikata i fazu prenosa podataka; konkretan postupak interakcije je sledeći:

• Klijent pokreće HTTPS zahtev.
• Server klijentu vraća prethodno podešen sertifikat sa javnim ključem.
• Klijent verifikuje sertifikat sa javnim ključem: na primer, da li je u periodu važenja, da li namena sertifikata odgovara sajtu koji klijent traži, da li je na CRL listi opoziva, da li je sertifikat višeg nivoa važeći — to je rekurzivni proces koji ide sve do korenskog sertifikata (Root sertifikat ugrađen u operativni sistem ili Root sertifikat koji je sam klijent ugradio). Ako je verifikacija uspešna, postupak se nastavlja; ako nije, prikazuje se upozorenje.
• Klijent pseudoslučajnim generatorom brojeva generiše simetrični ključ za šifrovanje, zatim taj simetrični ključ šifruje javnim ključem iz sertifikata i šalje serveru.
• Server svojim privatnim ključem dešifruje ovu poruku i dobija simetrični ključ. Time i klijent i server drže isti simetrični ključ.
• Server koristi simetrični ključ da šifruje sadržaj otvorenog teksta A i šalje ga klijentu.
• Klijent simetričnim ključem dešifruje šifrovani odgovor i dobija sadržaj otvorenog teksta A.
• Klijent ponovo pokreće HTTPS zahtev, simetričnim ključem šifruje sadržaj otvorenog teksta B zahteva, a zatim server simetričnim ključem dešifruje šifrovani tekst i dobija sadržaj otvorenog teksta B.

Digitalni sertifikat

Klijent prvo od servera zatraži javni ključ, zatim njime šifruje informaciju, a server po prijemu šifrovanog teksta koristi svoj privatni ključ za dešifrovanje.

Ovde se javljaju neka pitanja — kako garantovati da javni ključ nije izmenjen i da mu se može verovati?

Zato je ovde potrebno pribegnuti autoritativnom trećem licu — CA (autoritet za digitalna sertifikaciju) — koje javni ključ servera stavlja u digitalni sertifikat (koji izdaje institucija za digitalnu sertifikaciju); sve dok je sertifikat poverljiv, i javni ključ je poverljiv.

Na taj način, preko digitalnog sertifikata, garantuje se identitet javnog ključa servera i rešava se rizik od lažnog predstavljanja.

Poruka zahteva

Zaglavlje zahteva

HTTP poruka zahteva sastoji se iz 3 dela (linija zahteva + zaglavlje zahteva + telo zahteva).

Česta svojstva zaglavlja HTTP poruke

• Accpet

  • Govori serveru koje tipove odgovora klijent prihvata.

• Referer

  • Označava sa kog URL-a je došao ovaj zahtev; na primer, želite da kupujete na mreži, a ne znate koju platformu da izaberete, pa pitate Baidu koja je najpovoljnija — iskoči vam gomila rezultata, među njima i Taobao; kada iz Baidua uđete na Taobao, Referer ovog zahteva biće: www.baidu.com.

• Cache-Control

  • Kontroliše keširanje; na primer, ako zahtev želi da se sadržaj odgovora kešira kod klijenta godinu dana ili se ne kešira, to se može podesiti ovim zaglavljem.

• Accept-Encoding

  • Ovo svojstvo govori serveru koje formate kodiranja prihvata, uključujući kodiranje znakova i kompresovani oblik (najčešće kompresovani oblik).
    • Na primer: Accept-Encoding:gzip, deflate (oba su kompresovani formati).

• Host

  • Navodi host i port resursa koji se traži.

• User-Agent: govori serveru operativni sistem, verziju pregledača i ime koji klijent koristi.

• Connection

  Odlučuje da li će se mrežna konekcija zatvoriti nakon što se tekuća transakcija (three-way handshake i four-way handshake) završi.

• Persistentna konekcija, nakon transakcije ne zatvara mrežnu konekciju: Connection: keep-alive.

• Nepersistentna konekcija, nakon transakcije zatvara mrežnu konekciju: Connection: close.

Poruka odgovora

Poruka odgovora se, kao i poruka zahteva, sastoji iz tri dela (linija odgovora, zaglavlje odgovora, telo odgovora).

Svojstva HTTP poruke odgovora

• Cache-Control
  • Nakon što odgovor stigne klijentu, server preko ovog svojstva govori klijentu kako da kontroliše keširanje sadržaja odgovora.
• ETag
  • Označava verziju traženog resursa; ako se resurs promeni, i ovo svojstvo se menja.
• Location
  • Koristi se kod redirekcije ili pri kreiranju novog resursa.
• Set-Cookie
  • Server može podesiti kolačiće (cookie) klijenta.

TCP

TCP je protokol transportnog sloja koji obezbeđuje pouzdan prenos, podržava ful-dupleks i predstavlja protokol orijentisan na konekciju.

Dupleks/Singleks

U svakom trenutku, ako se podaci mogu slati samo u jednom smeru, to je simpleks.

Ako se u nekom trenutku podaci mogu prenositi u jednom smeru, a zatim i u suprotnom, naizmenično, to je polumpleks (half-duplex); polumpleks zahteva bar jednu liniju.

Ako se podaci u svakom trenutku mogu slati i primati u oba smera, to je ful-dupleks; ful-dupleks zahteva više od jedne linije.

TCP je dupleksni protokol — podaci se u svakom trenutku mogu prenositi u oba smera.

To znači da klijent i server mogu ravnopravno slati i primati poruke.

Glavne karakteristike TCP protokola

• TCP je transportni protokol orijentisan na konekciju; orijentisan na konekciju znači da pre prenosa podataka obe strane moraju uspostaviti kanal — na primer, three-way handshake je proces uspostavljanja kanala, a four-way handshake jedan od procesa njegovog zatvaranja i uništavanja.

• Svaka TCP konekcija može imati samo dve krajnje tačke (odnosno dva soketa) i može biti samo tačka-do-tačke.

• TCP pruža pouzdan prenos. Preneseni podaci su bez grešaka, ne gube se, ne ponavljaju i stižu po redosledu.

• TCP obezbeđuje ful-dupleksnu komunikaciju. Dozvoljava aplikacijskim procesima obe strane komunikacije da u svakom trenutku šalju podatke, jer oba kraja imaju i bafer za slanje i bafer za prijem.

• Orijentisan je na tok bajtova. Iako aplikacija sa TCP-om razmenjuje podatke u blokovima različitih veličina, TCP te podatke posmatra kao neprekinuti tok bajtova bez strukture; ne garantuje da blok podataka koji primalac primi ima istu veličinu kao blok koji je pošiljalac poslao — na primer, pošiljalac može predati 10 blokova podataka svom TCP-u, a primalacv TCP može gornjem sloju aplikacije predati taj tok bajtova u samo 4 bloka.

Princip pouzdanosti TCP-a

Pouzdan prenos ima dve osobine:

1. Kanal prenosa je bez grešaka i garantuje ispravnost prenetih podataka.
2. Bez obzira na to kojom brzinom pošiljalac šalje podatke, primalac uvek stiže da obradi primljene podatke.

Prvo, TCP uspostavlja TCP konekciju three-way handshake-om, a oslobađa je four-way handshake-om, čime se garantuje pouzdanost uspostavljenog kanala prenosa.

Drugo, TCP koristi neprekidni ARQ protokol (Go-back-N; automatska retransmisija nakon isteka vremena) da bi garantovao ispravnost prenosa podataka, a protokol kliznog prozora (sliding window) koristi da bi primalac mogao blagovremeno obraditi primljene podatke i vršio kontrolu protoka.

Konačno, TCP koristi spor početak (slow start), izbegavanje zagušenja (congestion avoidance), brzu retransmisiju (fast retransmit) i brzi oporavak (fast recovery) radi kontrole zagušenja i izbegavanja mrežnog zagušenja.

Segment

Iako je TCP orijentisan na tok bajtova, jedinica podataka koja se prenosi je segment.

Segment = zaglavlje + podaci (dva dela).

Sve funkcije TCP-a ogledaju se u ulozi polja u zaglavlju.

1. Prvih 20 bajtova zaglavlja je fiksno, a iza njih sledi 4n bajtova opcija koje se dodaju po potrebi.
2. Dakle, minimalna dužina TCP zaglavlja = 20 bajtova.

Port:

Izvorni i odredišni port zauzimaju po 16 bitova, odnosno dva bajta, pa je opseg portova 2^16=65535.

Pored toga, portovi ispod 1024 su rezervisani od strane sistema, dok je opseg od 1024 do 65535 namenjen korisnicima.

seq broj sekvence: zauzima 4 bajta; svaki bajt u toku bajtova koji se prenose preko TCP konekcije ima svoj redni broj po redosledu.

Na primer: ako vrednost polja broja sekvence jednog segmenta iznosi 107, a on nosi 100 bajtova podataka, sledeći segment počinje od broja sekvence 107+100=207.

ack broj potvrde: 4 bajta; to je broj sekvence prvog bajta podatka sledećeg segmenta koji se očekuje od druge strane.

Na primer: B primi segment od A čiji je broj sekvence 301, a dužina podataka 200 bajtova — to pokazuje da je B ispravno primio podatke od A do broja sekvence 500 (301+200-1=500). B očekuje od A sledeći broj sekvence 501, pa u segmentu potvrde koji B šalje A postavlja ack na 501.

Pomeraj podataka (data offset): zaglavlje ima opcione promenljive polja; navodi koliko je daleko početak podataka TCP segmenta od početka samog segmenta.

Rezervisano: rezervisano za buduću upotrebu, postavljeno na 1.

Kontrolna polja: sastoji se od 8 indikatorskih bitova; svaki indikatorski bit predstavlja jednu kontrolnu funkciju.

Glavnih 6:

• URG indikator urgentnog pokazivača: 1 znači da je urgentni pokazivač važeći, 0 znači da se urgentni pokazivač ignoriše.

• ACK indikator broja potvrde: 1 znači da je broj potvrde važeći, 0 znači da segment ne sadrži potvrdu i da se polje broja potvrde ignoriše; da li gornji broj potvrde važi kontroliše se upravo ovim indikatorom.

• PSH indikator: 1 označava da segment nosi push oznaku i nalaže primaocu da po prijemu segmenta što pre preda podatke aplikaciji, umesto da stoje u redu u baferu.

• RST indikator resetovanja konekcije: resetuje konekciju koja je zbog kraha hosta ili drugih razloga pala u grešku, ili služi za odbijanje nelegalnih segmenata, odnosno nelegalnih konekcija.

• SYN sinhronizacija sekvence: služi za uspostavljanje konekcije; u zahtevu za konekciju SYN=1 i ACK=0 znače da taj segment ne koristi priloženo polje potvrde, dok odgovor na konekciju prilaže potvrdu, odnosno SYN=1 i ACK=1.

• FIN indikator završetka: služi za oslobađanje konekcije; 1 znači da pošiljalac više nema šta da pošalje.

Prozor (window): veličina kliznog prozora kojom se pošiljaocu saopštava veličina bafera primaoca, čime se kontroliše brzina slanja podataka pošiljaoca, odnosno vrši kontrola protoka.

Kontrolna suma (checksum): paritetna provera; ova kontrolna suma računa se nad celim TCP segmentom (uključujući TCP zaglavlje i TCP podatke) u 16-bitnim rečima — računa je i čuva pošiljalac, a primalac je proverava.

Urgentni pokazivač: važi samo kada je kontrolni bit URG postavljen na 1; navodi broj bajtova urgentnih podataka u ovom segmentu.

Opcije: promenljive dužine; definišu druge opcione parametre.

Spajanje i deljenje paketa

TCP je protokol orijentisan na tok bajtova i posmatra podatke aplikativnog sloja kao tok bajtova, pa ne šalje pakete fiksne veličine i TCP protokol nema polje koje navodi veličinu poslatog paketa.

Pored toga, TCP ne garantuje da blok podataka koji aplikacija primaoca primi ima odgovarajuću veličinu kao blok koji je aplikacija pošioca poslala.

Na primer, aplikacija pošiljaoca može predati svom TCP-u 10 blokova podataka, a TCP primaoca možda samo iz 4 bloka u potpunosti preda primljeni tok bajtova gornjoj aplikaciji.

Donji sloj TCP-a ne razume konkretno značenje poslovnih podataka gornjeg sloja; podelu paketa vrši na osnovu stvarnog stanja TCP bafera, pa se sa stanovišta aplikacije dešava da jedan kompletan paket TCP može podeliti u više paketa za slanje, ili više malih paketa može objediniti u jedan veliki paket — to je takozvani problem spajanja i deljenja TCP paketa.

Strategije za rešavanje spajanja/deljenja TCP paketa

Pošto TCP ne može da razume karakteristike poslovnih podataka gornjeg sloja, ne može da garantuje da poslati paketi neće biti spojeni ili podeljeni; ovaj problem može se rešiti samo dobrim dizajnom protokola na gornjem sloju. Pristupi su sledeći:

• Fiksna dužina poruke: svaki poslati paket ima fiksnu veličinu, na primer 100 bajtova; paketi kraći od 100 bajtova dopunjuju se razmacima, a primalac pri čitanju podataka ravna se po toj dužini.

• Dodavanje znaka za novi red na kraj poruke kao oznake cele poruke: primalac pri čitanju na osnovu znaka za novi red procenjuje da li je poruka kompletna; ako i sam sadržaj poruke sadrži znak za novi red, ovaj pristup nije podesan.

• Podela poruke na zaglavlje i telo, pri čemu zaglavlje navodi dužinu podataka, pa se kompletna poruka čita na osnovu dužine; UDP protokol je tako projektovan — koristi dva bajta za dužinu poruke, pa zato UDP nema problem spajanja i deljenja paketa.

Three-way handshake

Prvi handshake:

Klijent postavi indikatorski bit TCP segmenta SYN na 1, nasumično generiše vrednost broja sekvence seq=J i sačuva je u polju broja sekvence TCP zaglavlja, čime navodi port servera sa kojim želi da se poveže, a zatim taj paket šalje serveru. Nakon slanja, klijent prelazi u stanje SYN_SENT i čeka potvrdu servera.

Drugi handshake:

Server, po prijemu paketa, na osnovu indikatorskog bita SYN=1 zaključuje da klijent traži uspostavljanje konekcije; server postavlja i indikatorski bit SYN i indikatorski bit ACK TCP segmenta na 1, postavlja ack=J+1, nasumično generiše vrednost broja sekvence seq=K i taj paket šalje klijentu radi potvrde zahteva za konekciju, a server prelazi u stanje SYN_RCVD.

Treći handshake:

Klijent po prijemu potvrde proverava da li je ack jednako J+1 i da li je ACK jednako 1; ako jeste, postavlja indikatorski bit ACK na 1, ack=K+1 i šalje taj paket serveru. Server proverava da li je ack jednako K+1 i da li je ACK jednako 1; ako jeste, konekcija je uspešno uspostavljena i klijent i server prelaze u stanje ESTABLISHED, čime se završava three-way handshake, nakon čega klijent i server mogu početi da prenose podatke.

ack i ACK iznad nisu isti pojam:

• Malo slovo ack predstavlja broj potvrde (Acknowledge number) iz zaglavlja — skraćeno ack — potvrđuje broj prethodnog paketa, ack=seq+1.

• Veliko slovo ACK je indikatorski bit TCP zaglavlja o kojem smo govorili; služi da označi da li je TCP paket izvršio operaciju potvrde prethodnog paketa — ako jeste, indikatorski bit ACK se postavlja na 1.

Zašto TCP koristi three-way handshake, a ne two-way handshake

• Da bi se ostvario pouzdan prenos podataka, obe strane u TCP komunikaciji moraju održavati broj sekvence koji identifikuje koje su poslate pakete druga strana već primila. Proces three-way handshake je nužan korak kojim obe strane saopštavaju jedna drugoj početnu vrednost broja sekvence i potvrđuju da su tu početnu vrednost primile.

• Ako bi se koristio samo two-way handshake, najviše što bi se moglo potvrditi je početni broj sekvence strane koja je pokrenula konekciju, dok broj sekvence koji izabere druga strana ne bi bio potvrđen.

U „Računarskim mrežama“ piše sledeće:

Da bi se sprečilo da već poništen zahtev za konekcijom iznenada stigne do servera i pritom izazove grešku.

U knjizi se istovremeno navodi i primer:

Pretpostavimo da prvi zahtev za konekcijom koji pošalje client nije izgubljen, već se dugo zadržao na nekom mrežnom čvoru, pa stiže do servera tek u nekom trenutku nakon oslobađanja konekcije. To je zapravo već odavno poništen segment, ali kada server primi ovaj poništeni zahtev za konekcijom, pomisli da je u pitanju novi zahtev za konekcijom koji client ponovo šalje.

Zato server pošalje clientu segment potvrde i pristaje na uspostavljanje konekcije. Pretpostavimo da se ne koristi three-way handshake — tada bi novu konekciju bilo dovoljno da server pošalje potvrdu i konekcija je uspostavljena; pošto klijent u tom trenutku uopšte nije poslao zahtev za uspostavljanje konekcije, on neće reagovati na potvrdu servera, niti će slati podatke serveru.

Server, međutim, misli da je nova konekcija uspostavljena i stalno čeka da client pošalje podatke — pa se mnogo resursa servera bespotrebno rasipa.

Korišćenjem three-way handshake-a može se sprečiti gore opisana pojava: u opisanoj situaciji klijent ne bi potvrdio potvrdu servera, a server, pošto ne dobije potvrdu, zna da klijent uopšte nije tražio uspostavljanje konekcije.

Šta je red polu-otvorenih konekcija

Kada server prvi put primi SYN od klijenta, prelazi u stanje SYN_RCVD; u tom trenutku još uvek nisu potpuno uspostavili konekciju, pa server ovakve zahteve za konekcijom stavlja u red — taj red nazivamo redom polu-otvorenih konekcija.

Naravno, postoji i red potpunih konekcija: one koje su završile three-way handshake i uspostavile konekciju stavljaju se u red potpunih konekcija. Ako se red napuni, može doći do gubitka paketa.

Još jedna napomena o broju SYN-ACK retransmisija:

Nakon što server pošalje SYN-ACK paket, ako ne primi paket potvrde od klijenta, vrši prvu retransmisiju; ako ni posle određenog vremena ne primi potvrdu, vrši drugu retransmisiju; ako broj retransmisija pređe sistemski propisan maksimum, sistem briše informacije o toj konekciji iz reda polu-otvorenih konekcija.

Da li se tokom three-way handshake-a mogu nositi podaci

Zapravo, pri trećem handshake-u mogu se nositi podaci, odnosno prvi i drugi handshake ne mogu nositi podatke, ali treći može.

Ako bi prvi handshake mogao nositi podatke, onda bi napadač koji želi zlonamerno da napadne server u SYN segmentu svaki put stavio ogromnu količinu podataka — pošto napadaču nije stalo do toga da li serverski kapaciteti za prijem i slanje rade normalno, uzastopnim slanjem SYN segmenata naterao bi server da potroši mnogo vremena i memorijskog prostora na prijem tih segmenata. Drugim rečima, ako bi prvi handshake mogao da nosi podatke, jedan od jednostavnih razloga protiv toga je taj što bi server bio znatno izloženiji napadima.

Za treći handshake, pak, klijent je već u stanju established — odnosno, za klijent je konekcija već uspostavljena i on već zna da serverski kapaciteti za prijem i slanje rade normalno, pa nošenje podataka ne predstavlja problem.

Four-way handshake

Zahtev za prekid može pokrenuti i klijent i server; pretpostavimo da ga pokreće klijent:

• Prvi handshake: Klijent pokreće zahtev za prekid i šalje serveru segment sa indikatorskim bitom FIN, pri čemu postavlja broj sekvence seq; tada klijent prelazi u stanje FIN_WAIT_1, što znači da klijent više nema podatke za slanje serveru.

• Drugi handshake: Server primi FIN segment od klijenta i vraća klijentu segment sa indikatorskim bitom ACK, pri čemu postavlja ack na seq+1; klijent prelazi u stanje FIN_WAIT_2, a server time saopštava klijentu da prihvata i odobrava zahtev za zatvaranje.

• Treći handshake: Server šalje klijentu segment sa indikatorskim bitom FIN kojim traži zatvaranje konekcije, dok klijent prelazi u stanje LAST_ACK.

• Četvrti handshake: Klijent primi FIN segment od servera i šalje serveru segment sa indikatorskim bitom ACK, a zatim klijent prelazi u stanje TIME_WAIT. Pošto server primi ACK segment od klijenta, zatvara konekciju; klijent, nakon što istekne vreme 2MSL i dalje ne dobije odgovor, time dokazuje da je server normalno zatvoren, pa i klijent može zatvoriti konekciju.

Zašto se kod uspostavljanja konekcije koristi three-way handshake, a kod zatvaranja four-way handshake?

Pri uspostavljanju konekcije, kada server primi SYN zahtev klijenta, može odmah poslati SYN+ACK segment — pritom ACK segment služi za odgovor, a SYN za sinhronizaciju, pa je za uspostavljanje konekcije dovoljan three-way handshake.

Pošto je TCP protokol transportni komunikacioni protokol orijentisan na konekciju, pouzdan i zasnovan na toku bajtova, a radi u ful-dupleks režimu.

To znači da prilikom zatvaranja konekcije, kada klijent pošalje FIN segment, to samo znači da klijent saopštava serveru da je slanje podataka završeno. Kada server primi FIN segment i vrati ACK segment, to znači da zna da klijent više ne šalje podatke, ali server i dalje može slati podatke klijentu, pa server verovatno neće odmah zatvoriti SOCKET — sve dok i server ne završi sa slanjem svojih podataka.

Kada i server pošalje FIN segment, to znači da server više nema podatke za slanje i da saopštava klijentu da ni on nema šta da pošalje, nakon čega obe strane raskidaju TCP konekciju.

Zašto TIME_WAIT čeka 2MSL?

MSL: maksimalno vreme života segmenta — najduže vreme koje segment može provesti u mreži pre nego što bude odbačen.

Ima dva razloga:

• Prvo: da se garantuje pouzdano zatvaranje ful-dupleks TCP konekcije. Zbog nepouzdanosti IP protokola ili drugih mrežnih razloga, server možda nije primio ACK segment klijenta, pa će server nakon isteka vremena ponovo poslati FIN. Ako je u tom trenutku konekcija klijenta već zatvorena i nalazi se u stanju CLOSED, ponovo poslati FIN neće naći odgovarajuću konekciju, što dovodi do nereda u konekcijama. Zato klijent, nakon što pošalje poslednji ACK, ne sme odmah preći u stanje CLOSED, već mora ostati u TIME_WAIT, kako bi, ako ponovo primi FIN, mogao garantovati da je druga strana primila ACK i konačno ispravno zatvorila konekciju.
• Drugo: da se garantuje da duplikati segmenata ove konekcije nestanu iz mreže. Ako klijent nakon slanja poslednjeg ACK-a odmah pređe u stanje CLOSED, a zatim prema serveru pokrene novu konekciju, ne može se garantovati da će portovi nove i tek zatvorene konekcije biti različiti — odnosno portovi nove i stare konekcije mogu biti isti, pa može doći do problema: ako su neki podaci prethodne konekcije još uvek zadržani u mreži, ti kašnjenjem pristigli podaci mogu, nakon uspostavljanja nove konekcije, stići do klijenta; pošto su i port i IP isti i za staru i za novu konekciju, TCP će pomisliti da ti podaci pripadaju novoj konekciji, pa će nova konekcija primiti „prljave” podatke, što dovodi do nereda u paketima. Zato TCP konekcija u stanju TIME_WAIT mora čekati 2 puta MLL, kako bi se garantovalo da svi podaci ove konekcije nestanu iz mreže.

Kontrola protoka

RTT i RTO

RTT: vreme od slanja jednog paketa do prijema odgovarajućeg ACK-a.

RTO: interval retransmisije (TCP nakon slanja paketa pokreće tajmer retransmisije; RTO je vreme retransmisije tog tajmera).

Prvo se unapred izračuna vreme tajmera; ako stigne ACK, tajmer retransmisije automatski prestaje da važi, odnosno nema retransmisije; ako ACK ne stigne, RTO tajmer istekne i vrši se retransmisija.

RTO je procenjeno vreme isteka za slanje tekućeg paketa; RTO nije fiksno upisana konfiguracija, već se izračunava na osnovu RTT-a.

Klizni prozor (sliding window)

Klizni prozor TCP-a ima dve glavne uloge:

1. Garantuje pouzdanost TCP-a.

2. Garantuje karakteristike kontrole protoka TCP-a.

Polje Window u zaglavlju TCP segmenta služi da primalac saopšti pošiljaocu koliko još prostora u baferu ima za prijem podataka; pošiljalac na osnovu kapaciteta primaoca šalje podatke, čime neće preopteretiti primaoca — i to je kontrola protoka.

Pošiljalac održava neprekidni niz brojeva okvira kojima je dozvoljeno slanje, koji se naziva prozor slanja; istovremeno, i primalac održava neprekidni niz brojeva okvira kojima je dozvoljen prijem, koji se naziva prozor prijema.

Gornje i donje granice brojeva prozora slanja i prozora prijema ne moraju biti iste, čak se i veličine mogu razlikovati.

Različiti protokoli kliznog prozora uglavnom imaju i različite veličine prozora.

Brojevi sekvenci unutar prozora pošiljaoca predstavljaju okvire koji su već poslati, a još uvek nisu potvrđeni, ili okvire koji smeju biti poslati.

Klizni prozor sastoji se iz četiri dela; svaki bajt podataka ima jedinstveni redni broj, a s vremenom se nepotvrđeni deo i deo sa brojevima paketa koji se mogu slati pomeraju udesno, čime nastaje klizni prozor.

1. zeleno: podaci uspešno poslati i potvrđeni ACK-om.
2. žuto: podaci uspešno poslati, ali čekaju ACK potvrdu (zauzimaju veličinu kliznog prozora).
3. ljubičasto: preostala veličina kliznog prozora, odnosno broj bajtova koji se još mogu poslati (raspoloživa veličina kliznog prozora).
4. sivo: kodovi narednih podataka.

Veličina prozora prijema je maksimalna vrednost kliznog prozora; tokom prenosa podataka, raspoloživa veličina kliznog prozora dinamički se menja.

Međutim, ima još jedna stvar: dizajn kliznog prozora uzima u obzir samo kapacitet primaoca obrade, a ne uzima u obzir propusnost puta.

Kao što server može obraditi 100M podataka, ali se 99M tih podataka zaglavi na putu — zar to ne vodi ka zagušenju puta? Zato je potrebno još jedno dizajnersko rešenje: izbegavanje zagušenja.

Cilj kontrole protoka

Ako pošiljalac šalje podatke previše brzo, a primalac ne stiže da ih primi, doći će do gubitka paketa.

Da bi se izbegao gubitak paketa, kontroliše se brzina slanja pošiljaoca, tako da primalac stiže da primi podatke — to je kontrola protoka.

Osnovni cilj kontrole protoka jeste sprečavanje gubitka paketa i ona čini jednu stranu pouzdanosti TCP-a.

Kako se ostvaruje kontrola protoka

Ostvaruje se protokolom kliznog prozora (neprekidni ARQ protokol). Protokol kliznog prozora garantuje i prijem paketa bez grešaka i po redosledu, a i realizuje kontrolu protoka.

Glavni način je taj što ACK koji primalac vraća sadrži veličinu svog prozora prijema, pa se tom veličinom kontroliše slanje podataka pošiljaoca.

Deadlock izazvan kontrolom protoka

Kada pošiljalac dobije odgovor sa prozorom 0, prestaje sa slanjem i čeka sledeći odgovor primaoca.

Međutim, ako taj odgovor sa prozorom različitim od nule bude izgubljen u prenosu, pošiljalac će čekati unedogled, dok primalac misli da je pošiljalac već primio taj odgovor i čeka nove podatke — obe strane onda čekaju jedna na drugu, što dovodi do deadlock-a.

Da bi se izbegao deadlock izazvan kontrolom protoka, TCP koristi tajmer istrajnosti (persist timer). Kad god pošiljalac dobije odgovor sa nultim prozorom, pokreće taj tajmer; čim vreme istekne, on aktivno šalje segment kojim pita primaoca o veličini prozora. Ako primalac i dalje vrati nulti prozor, tajmer se resetuje i čeka dalje; ako prozor nije 0, to znači da je odgovor izgubljen, pa se nakon resetovanja prozora slanja nastavlja sa slanjem — čime se izbegava deadlock.

Kontrola zagušenja

Zašto je potrebna kontrola zagušenja

Pretpostavimo da se u mreži već pojavilo zagušenje: ako se zagušenje ne obradi, kašnjenje će se povećati, doći će do još gubitka paketa, što će pokrenuti retransmisiju od strane pošiljaoca i dodatno pogoršati zagušenje — začarani krug se nastavlja sve do pada mreže.

Scenariji primene i ciljevi kontrole zagušenja razlikuju se od kontrole protoka.

Pre pojave zagušenja, kontrola može sprečiti da prebrz rast saobraćaja sruši mrežu; kada do zagušenja dođe, jedini izbor jeste smanjenje protoka.

Kontrola zagušenja se uglavnom ostvaruje pomoću 4 algoritma:

1. Spor početak (slow start).
2. Izbegavanje zagušenja (congestion avoidance).
3. Brza retransmisija (fast retransmit).
4. Brzi oporavak (fast recovery).

Algoritmi 1 i 2 primenjuju se pre pojave zagušenja, algoritam 3 u trenutku zagušenja, a algoritam 4 nakon rešavanja zagušenja (odnosno kao pre pojave zagušenja).

rwnd i cwnd

rwnd (Receiver Window, prozor primaoca) i cwnd (Congestion Window, prozor zagušenja):

• rwnd je veličina prozora za kontrolu protoka; uglavnom zavisi od brzine obrade primaoca, a primalac njome obaveštava pošiljaoca i pasivno se prilagođava.

• cwnd je veličina prozora za obradu zagušenja; zavisi od stanja mreže, a pošiljalac je aktivno podešava ispitivanjem mreže.

Ako se istovremeno razmatraju i kontrola protoka i obrada zagušenja, veličina prozora pošiljaoca ne prelazi min{rwnd, cwnd}.

Algoritam sporog početka

Osnovna ideja algoritma sporog početka jeste da se ne pošalje odmah velika količina podataka, već da se prvo ispitaju stepen zagušenja mreže, odnosno da se veličina prozora zagušenja postepeno povećava od male ka većoj.

Ovde se broj segmenata uzima kao veličinu prozora zagušenja radi objašnjenja algoritma sporog početka; stvarna veličina prozora zagušenja izražava se u bajtovima.

Vreme trajanja jednog prenosa zapravo je vreme povratnog puta RTT, a nakon svakog prenosa, prozor zagušenja cwnd se udvostručuje.

Da bi se sprečilo da preveliki rast cwnd-a izazove zagušenje mreže, potrebno je uvesti i stanje granice sporog početka — ssthresh.

Upotreba ssthresh je sledeća:

• Kada je cwnd<ssthresh, koristi se algoritam sporog početka.

• Kada je cwnd>ssthresh, prelazi se na algoritam izbegavanja zagušenja.

• Kada je cwnd=ssthresh, može se koristiti bilo koji od njih.

Napomena: ovde „sporo” ne znači da je brzina rasta cwnd-a mala, već znači da TCP pri slanju segmenata prvo postavlja cwnd=1, a zatim ga postepeno povećava — što je, naravno, znatno sporije nego da se odjednom, sa velikim cwnd-om, u mrežu ubaci mnogo segmenata.

Algoritam izbegavanja zagušenja

Veličina prozora zagušenja cwnd se polako povećava — nakon svakog RTT-a, cwnd pošiljaoca se uvećava za 1, umesto da se udvostručuje.

Tako cwnd raste po linearnom zakonu, znatno sporije od brzine rasta cwnd-a u algoritmu sporog početka.

Bilo u fazi sporog početka, bilo u fazi izbegavanja zagušenja, čim pošiljalac oceni da je u mreži došlo do zagušenja (osnova za ocenu je kašnjenje potvrde — iako kašnjenje potvrde može biti i posledica gubitka paketa iz drugih razloga, pošto se to ne može utvrditi, sve se tretira kao zagušenje), granica sporog početka ssthresh se postavlja na polovinu veličine prozora slanja u trenutku pojave zagušenja (ali ne manje od 2).

Zatim se cwnd ponovo postavlja na 1 i izvršava algoritam sporog početka.

Cilj ovog postupka jeste da se brzo smanji broj paketa koje host šalje u mrežu, kako bi ruter na kom je došlo do zagušenja imao dovoljno vremena da obradi pakete koji su se nagomilali u redu.

Celi tok kontrole zagušenja:

Pretpostavimo da je pri cwnd=24 u mreži došlo do isteka vremena (zagušenje); tada je novi ssthresh=12, cwnd se ponovo postavlja na 1 i izvršava se algoritam sporog početka.

Kada cwnd=12=ssthresh, prelazi se na izvršavanje algoritma izbegavanja zagušenja.

Napomena: izbegavanje zagušenja ne znači da se zagušenje potpuno izbeglo, već da mreža teže dolazi u stanje zagušenja.

Algoritam brze retransmisije

Brza retransmisija zahteva da primalac, čim primi segment pogrešnog redosleda, odmah pošalje duplikat potvrde (kako bi pošiljalac što pre saznao da neki segment nije stigao do njega — time se propusnost mreže povećava za oko 20%), bez čekanja da potvrdu priloži uz podatke koje sam šalje.

Algoritam brze retransmisije propisuje da pošiljalac, čim uzastopno primi tri duplikata potvrde, odmah retransmituje segment koji druga strana još nije primila, umesto da i dalje čeka istek tajmera retransmisije.

Algoritam brzog oporavka

Sa algoritmom brze retransmisije koristi se i algoritam brzog oporavka, sa dva ključna elementa:

• Kada pošiljalac uzastopno primi tri duplikata potvrde, ssthresh se prepolavlja (kako bi se sprečilo zagušenje mreže).

• Međutim, nakon toga se ne izvršava algoritam sporog početka.

S obzirom na to da pri zagušenju mreže ne bi bilo dobijeno više duplikata potvrde, pošiljalac sada smatra da u mreži verovatno nije došlo do zagušenja.

Zato se sada ne izvršava algoritam sporog početka, već se cwnd postavlja na vrednost nakon prepolavljivanja ssthresh-a, a zatim se izvršava algoritam izbegavanja zagušenja, čime se cwnd polako povećava.

Socket

Socket, odnosno soket, jeste apstraktni softverski sloj između aplikativnog sloja i komunikacije sa familijom TCP/IP protokola; pojavljuje se kao programerski interfejs (API) koji enkapsulira TCP/IP familiju protokola.

Socket nije protokol, već programerski interfejs za pozive (API) i pripada transportnom sloju ( uglavnom rešava pitanje kako se podaci prenose kroz mrežu).

Za korisnika je dovoljno da poziva Socket kako bi organizovao podatke u skladu sa propisanim protokolom i tako ostvario komunikaciju.

UDP

Karakteristike UDP protokola

• UDP je transportni protokol bez konekcije.

• UDP radi najbolje što može da isporuči, ali ne garantuje pouzdanu isporuku.

• UDP je orijentisan na poruke (datagram); poruke koje primi od aplikativnog sloja ne spaja i ne deli, već čuva granice originalne poruke.

• UDP nema kontrolu zagušenja, pa čak i kada se u mreži pojavi zagušenje, ne smanjuje brzinu slanja.

• UDP podržava komunikaciju jedan-na-jedan, jedan-na-više i više-na-više.

• UDP zaglavlje je malog obima — samo 8 bajtova.

Razlika između TCP i UDP

• TCP je pouzdan prenos, UDP je nepouzdan prenos.

• TCP je orijentisan na konekciju, UDP je bez konekcije.

• TCP prenosi podatke po redosledu, UDP ne garantuje redosled podataka.

• TCP ne čuva granice podataka, UDP čuva granice podataka.

• TCP je u brzini prenosa relativno sporiji od UDP-a.

• TCP ima kontrolu protoka i kontrolu zagušenja, UDP nema.

• TCP je teški protokol, UDP je laki protokol.

• TCP zaglavlje je duže — 20 bajtova, UDP zaglavlje je kraće — 8 bajtova.

Česti protokoli zasnovani na TCP i UDP

HTTP, HTTPS, FTP, TELNET, SMTP (protokol za prenos jednostavne pošte) zasnovani su na pouzdanom TCP protokolu.

TFTP, DNS, DHCP, TFTP, SNMP (protokol za upravljanje jednostavnom mrežom), RIP zasnovani su na nepouzdanom UDP protokolu.

Segment

UDP segment ima dva polja: polje podataka + polje zaglavlja.

Značenje svakog polja UDP segmenta:

• Izvorni port: ovo polje zauzima prvih 16 bitova zaglavlja UDP datogreme i obično sadrži UDP port koji aplikacija koja šalje datagramu koristi; aplikacija primaoca ovu vrednost koristi kao odredišnu adresu za slanje odgovora. Ovo polje je opcionalno, pa aplikacija pošiljaoca ne mora upisati svoj broj porta — ako ga ne upiše, polje se postavlja na 0, čime aplikacija primaoca ne može poslati odgovor.
• Odredišni port: port koji koristi UDP softver na računaru primaoca; zauzima 16 bitova.
• Dužina: ovo polje zauzima 16 bitova i predstavlja dužinu UDP datogreme, uključujući zaglavlje i dužinu UDP podataka; pošto je zaglavlje 8 bajtova, minimalna vrednost ovog polja je 8.
• Kontrolna suma: ovo polje zauzima 16 bitova i može proveriti da li su podaci oštećeni u toku prenosa.

Mrežni sloj

MAC adresa

MAC se naziva fizička adresa, odnosno hardverska adresa; služi da definiše lokaciju mrežnog uređaja. MAC adresa se postavlja pri proizvodnji mrežne kartice i fiksna je (mada se može promeniti preko Device Manager-a ili registra; unutar istog mrežnog segmenta MAC adrese moraju biti jedinstvene).

MAC adresa se izražava heksadecimalno, dužina je 6 bajtova (48 bitova) i deli se na prvih 24 bita i zadnjih 24 bita.

MAC adresa odgovara drugom sloju (sloju veze podataka) OSI referentnog modela; svič koji radi na sloju veze podataka održava bazu podataka o MAC adresama računara i sopstvenim portovima, a na osnovu polja odredišne MAC adrese u okviru koji primi, svič prosleđuje taj okvir.

IP adresa

Česte IP adrese dele se na IPv4 i IPv6; u širokoj upotrebi je IPv4 koji je trenutno gotovo istrošen, pa će sledeća faza nužno podrazumevati nadogradnju na IPv6.

IP adresa obeležava host u mreži preko mrežnog broja i broja hosta; hostove sa istim mrežnim brojem nazivamo lokalnom mrežom, a hostove sa različitim mrežnim brojem — udaljenim mrežnim hostovima.

Hostovi unutar lokalne mreže mogu komunicirati neposredno; hostovi u udaljenoj mreži, žele li da komuniciraju, moraju podatke proslediti preko lokalnog gateway-a.

IP adresa odgovara trećem sloju (mrežnom sloju) OSI referentnog modela; ruter koji radi na mrežnom sloju, na osnovu ciljne i izvorne IP adrese, ocenjuje da li se radi o istom mrežnom segmentu — ako su različiti, prosleđuje paket.

Format i prikaz IP adrese

IP adresa (IPv4) sastoji se iz 32 binarne cifre, podeljene u 4 dela (4 bajta), pri čemu svaki deo ima 8 binarnih cifara (1 bajt).

Između svakog dela od 8 binarnih cifara stavlja se znak ..

Pošto je binarni broj predug, radi lakšeg pamćenja i prepoznavanja, svaki deo od 8 binarnih cifara prevodi se u dekadni broj, u opsegu od 0 do 255.

Ovakav prikaz IP adrese naziva se tačkasto-dekadni prikaz.

IP adresa se prikazuje kao: xxx.xxx.xxx.xxx.

Na primer: 210.21.196.6 jeste jedan prikaz IP adrese.

IP adresa računara sastoji se iz dva dela: jednog koji je identifikator mreže i drugog koji je identifikator hosta; računari unutar istog mrežnog segmenta imaju isti mrežni deo, dok deo hosta ne sme biti duplikat.

Ruter povezuje različite mrežne segmente i odgovoran je za prosleđivanje podataka između njih, dok svič povezuje računare istog mrežnog segmenta.

Postavljanjem mrežne adrese i adrese hosta, u celoj međusobno povezanoj mreži garantuje se da se IP adrese pojedinačnih hostova ne preklapaju — odnosno IP adresa dobija jedinstvenost.

Detaljna podela IP adresa

IP adrese se dele u pet klasa A, B, C, D, E; od toga su A, B i C klase koje se najčešće koriste, dok su D i E posebne adrese.

Subnet maska

Pojam i uloga subnet maske

Tek preko subnet maske može se pokazati odnos između podmreže u kojoj se nalazi host i ostalih podmreža, čime mreža normalno radi.

Subnet maska i IP adresa se AND operacijom razdvajaju mrežna adresa i adresa hosta iz IP adrese, čime se utvrđuje da li se IP adresa nalazi u lokalnoj mreži ili u udaljenoj mreži.

Subnet maska se koristi i za dalju podelu mreže na više podmreža, kako se ne bi došlo do zagušenja zbog previše hostova ili do rasipanja IP adresa zbog premalo hostova.

Sastav subnet maske

Kao i IP adresa, subnet maska je adresa od 32 binarne cifre.

32 bita subnet maske odgovaraju 32 bita IP adrese: ako je neki bit IP adrese deo mrežne adrese, onda je odgovarajući bit subnet maske 1, inače je 0.

Na primer: 11111111.11111111.11111111.00000000.

Broj uzastopnih jedinica s leve strane označava dužinu mrežnog broja (u upotrebi mora biti uzastopan, mada teorijski ne mora), a broj uzastopnih nula s desne strane označava dužinu broja hosta.

Zašto se koristi subnet maska

Da bi dva hosta komunicirala, prvo treba utvrditi da li su u istom mrežnom segmentu, odnosno da li im je ista mrežna adresa.

Ako jeste, paket se može neposredno poslati ciljnom hostu; inače je potreban gateway koji će paket proslediti ka odredištu.

Može se pojednostavljeno razumeti ovako: host A želi da komunicira sa hostom B; IP adrese i A i B se AND operacijom uparuju sa subnet maskom hosta A, pa se posmatra rezultat:

1. Ako je rezultat isti, ta dva hosta nalaze se u istom mrežnom segmentu, pa A može putem ARP broadcast-a otkriti MAC adresu od B, a i B može otkriti MAC adresu od A i ostvariti normalnu komunikaciju.

2. Ako je rezultat različit, ARP broadcast se završava na lokalnom gateway-u; tada A podatke namenjene B prvo šalje lokalnom gateway-u, a gateway zatim, na osnovu IP adrese hosta B, pretražuje tabelu rutiranja i nastavlja da prosleđuje paket dok konačno ne stigne do odredišta B.

---

Gateway (prijenosnik) računara jeste izlaz ka drugim mrežnim segmentima, odnosno IP adresa interfejsa rutera.

IP adresa koju koristi interfejs rutera može biti bilo koja adresa u tom mrežnom segmentu, mada se obično bira prva ili poslednja raspoloživa adresa tog segmenta, kako bi se što više izbegao sukob sa adresama hostova u tom segmentu.

U primeru topologije ispod, A i B, kao i C i D, mogu komunicirati neposredno (svi pripadaju istom mrežnom segmentu i ne moraju preko rutera).

Međutim, A i C, A i D, B i C, te B i D ne pripadaju istom mrežnom segmentu, pa pri komunikaciji moraju preko lokalnog gateway-a; ruter zatim, na osnovu IP adrese sagovornika, u tabeli rutiranja pronalazi direktnu rutu koja odgovara toj adresi i prosleđuje paket kroz drugi gateway interfejs, čime se ostvaruje međusobna povezanost.

Odnos subnet maske i IP adrese

Subnet maska služi za ocenu da li se IP adrese bilo koja dva hosta nalaze u istoj mreži.

Kada se IP adrese oba hosta AND operacijom upare sa subnet maskom sopstvenog hosta, pa rezultat bude ista mreža, mogu komunicirati neposredno.

Kako se, na osnovu IP adrese i subnet maske, izračunava mrežna adresa:

IP adresa i subnet maska se pretvore u binarne brojeve.

Binarna IP adresa i subnet maska se AND-uju.

Dobijeni rezultat se pretvori u dekadni broj i time se dobija mrežna adresa.

Gateway

Gateway je suštinski IP adresa preko koje jedna mreža pristupa drugoj mreži.

Na primer, neka su date mreža A i mreža B. Opseg IP adresa mreže A je 192.168.1.1~192. 168.1.254, a subnet maska 255.255.255.0;

Opseg IP adresa mreže B je 192.168.2.1~192.168.2.254, a subnet maska 255.255.255.0.

Bez rutera, te dve mreže ne mogu ostvariti TCP/IP komunikaciju; čak i ako su obe mreže povezane na isti svič (ili habor), TCP/IP protokol će na osnovu subnet maske (255.255.255.0) oceniti da se hostovi iz te dve mreže nalaze u različitim mrežama.

Da bi se ostvarila komunikacija između te dve mreže, neophodan je gateway.

Ako host iz mreže A ustanovi da ciljni host paketa nije u lokalnoj mreži, proslediće paket svom gateway-u, a gateway ga onda prosleđuje gateway-u mreže B; gateway mreže B zatim ga prosleđuje nekom hostu u mreži B. Slično je i sa procesom prosleđivanja paketa iz mreže B ka mreži A.

Dakle, tek kada se podesi IP adresa gateway-a, TCP/IP protokol može ostvariti međusobnu komunikaciju između različitih mreža.

Čija je to IP adresa?

IP adresa gateway-a jeste IP adresa uređaja sa funkcijom rutiranja; uređaji sa funkcijom rutiranja obuhvataju ruter, server sa aktiviranim protokolom rutiranja (u suštini ekvivalent ruteru) i proxy server (takođe ekvivalent ruteru).

Ping

Ping je česta komanda kojom isprobavamo mrežnu konekciju.

On pomoću ICMP poruka detektuje mrežnu konekciju.

Pretpostavimo da A ping-uje B

1. Ping obaveštava sistem da formira ICMP zahtev u fiksnom formatu.

2. ICMP protokol pakuje taj paket zajedno sa IP adresom od B i predaje ga IP sloju.

3. IP sloj, sa IP adresom mašine B kao odredišnom, IP adresom sopstvene mašine kao izvornom i dodatnim neophodnim kontrolnim podacima u zaglavlju, gradi IP paket.

4. Pribavlja se MAC adresa od B; pri tome mašina A prvo ocenjuje da li se B nalazi u istom mrežnom segmentu — ukoliko IP sloj, na osnovu B-ove IP adrese i sopstvene subnet maske, ustanovi da B pripada istoj mreži, traži MAC adresu te mašine neposredno u toj mreži, a inače vrši slično traženje preko rutera.

Sledi proces ARP protokola kojim se na osnovu IP adrese pronalazi MAC adresa:

• Ako su dve mašine već ranije komunicirale, u ARP keš tabeli mašine A trebalo bi da postoji mapiranje B-ove IP adrese u njegovu MAC adresu.

• Ako nema zapisa, šalje se ARP zahtev putem broadcast-a, dobija se MAC adresa mašine B iz odgovora i predaje se sloju veze podataka.

5. Sloj veze podataka gradi okvir podataka; odredišna adresa je MAC adresa koju je preneo IP sloj, izvorna adresa je MAC adresa sopstvene mašine, uz dodatak neophodnih kontrolnih podataka, a zatim se, u skladu sa pravilima pristupa mediju Ethernet-a, šalje napolje.

6. Kada mašina B primi taj okvir, prvo proverava odredišnu adresu i poredi je sa sopstvenom MAC adresom:

Ako se poklapa, prihvata okvir, zatim po prijemu ispituje taj okvir i iz njega izdvaja IP paket koji predaje IP protokolu sopstvene mašine. IP protokol ga ispita, izdvaja korisne informacije i predaje ih ICMP protokolu, koji odmah gradi ICMP odgovor i šalje ga A. Taj proces je sličan procesu slanja ICMP zahteva od A ka B, ali B ne mora da koristi ARP broadcast da bi prikupio podatke o A — jer zahtev već sadrži dovoljno informacija koje B koristi za odgovor A.

Ako se adrese ne poklapaju, okvir se odbacuje.

Vidi se da PING predstavlja proces slanja poruke i prijema poruke potvrde, pri čemu se u toku tog povratnog puta može izračunati kašnjenje.

DNS

DNS, preko imena hosta, konačno dobija IP adresu koja odgovara tom imenu — taj proces se naziva razlaganje domenskog imena (ili razlaganje imena hosta).

Prosto rečeno, mi radiše pamtimo ime nekog sajta, poput www.baidu.com, nego li njegovu IP adresu, na primer 167.23.10.2.

Princip rada

Ime domena hosta se pretvara u IP adresu; radi se o protokolu aplikativnog sloja koji za prenos koristi UDP.

Prvi korak: klijent lokalnom DNS serveru šalje zahtev za razlaganje.

Drugi korak: ako lokalni DNS ima odgovarajući zapis, direktno vraća rezultat klijentu; ako nema, šalje zahtev ka DNS root serveru.

Treći korak: DNS root server, po prijemu zahteva, lokalnom serveru vraća adresu autoritativnog servera glavnog domena traženog domena.

Četvrti korak: lokalni DNS server zatim šalje upit na vraćenu adresu autoritativnog servera glavnog domena.

Peti korak: ako autoritativni server glavnog domena ima zapis, vraća rezultat; ako nema, vraća adresu relevantnog podređenog servera domena.

Šesti korak: lokalni DNS server nastavlja da šalje upite na primljenu adresu.

Sedmi korak: podređeni server domena ima odgovarajući zapis i vraća rezultat.

Osmi korak: lokalni DNS server vraća primljenu adresu klijentu i istovremeno je upisuje u svoj keš, kako bi njome raspologao pri sledećem upitu.

Upit domenskog imena DNS-a zapravo je neprekidan proces rekurzivnog upita, sve dok se ne pronađe odgovarajući rezultat; treba napomenuti da, kada se ne pronađe odgovarajući zapis, vraća se prazan rezultat, a ne poruka o isteku vremena.

DNS zapisi

A zapis

Definiše IP adresu za www.example.com
www.example.com.     IN     A     139.18.28.5;

Gore navedeno jeste jedan DNS zapis — dovoljan je običan tekst.

www.example.com je domensko ime koje se razlaže.

A je tip zapisa; A zapis predstavlja zapis koji služi za razlaganje IPv4 adrese.

Iz ovog zapisa se vidi da je IP adresa za www.example.com 139.18.28.5.

CNAME

CNAME služi za definisanje aliasa domena, kao u sledećem DNS zapisu:

Definiše alias za www.example.com
a.example.com.          IN     CNAME   b.example.com.

Ovaj DNS zapis definiše da je a.example.com alias za b.example.com.

Kada korisnik u pregledač unese a.example.com, DNS upit će pokazati da je a.example.com alias za b.example.com, pa će, kada zatreba stvarna IP adresa, uzeti A zapis od b.example.com.

Kada želite da sajt prebacite na novi domen, a stari domen zadržite; kao i kada svoje statičke resurse želite da stavite na CDN — CNAME je veoma koristan.

AAAA zapis

A zapis je mapiranje između domena i IPv4 adrese. Slično A zapisu, AAAA zapis je mapiranje između domena i IPv6 adrese.

MX zapis

MX zapis je zapis o pošti i opisuje domen servera e-pošte.

U radu često šaljemo e-poruke na imejl nekog kolege.

Na primer, šaljete poruku na xiaoming@xiaoflyfish.com — kako saznati koja IP adresa pripada serveru e-pošte?

Tada koristan sledeći MX zapis:

IN MX mail.xiaoflyfish.com

IP adresa mail.xiaoflyfish.com može se dobiti upitom za A i AAAA zapise od mail.xiaoflyfishcom.

NS zapis

NS zapis opisuje adresu DNS servera. Sa stanovišta strukture DNS-a, Name Server sadrži katalog autoritativnih DNS servisa.

Drugim rečima, NS zapis navodi koji server je autoritativni server domena koji odgovara na DNS upit.

Kada DNS upit naiđe na NS zapis, ponovo upituje DNS server konfigurisan u NS zapisu i dobija konačni zapis. Na primer:

a.com.     IN      NS      ns1.a.com.
a.com.     IN      NS      ns2.a.com.

Pri razlaganju adrese a.com vidimo da a.com ima dva NS zapisa, pa zaključujemo da se konačni zapisi za a.com nalaze na ns1.a.com i ns2.a.com.

Po dizajnu, ns1 i ns2 su pametni DNS serveri koje sajt a.com obezbeđuje i mogu pružati usluge poput balansiranja opterećenja i distribuiranog Sharding-a.

Na primer, kada korisnik iz Pekinga želi da pristupi a.com, ns1 vidi da je u pitanju IP adresa iz Pekinga pa vraća IP adresu najbližeg centra iz Pekinga.

U gore navedenom kodu a.com konfigurisana su dva NS zapisa.

Obično NS nije samo jedan — to je radi visoke dostupnosti: ako jedan padne, drugi i dalje nastavlja da služi.

Obično je NS zapis sa manjim brojem višeg prioriteta, odnosno ns1 ima prioritet nad ns2.

Nakon konfiguracije gore navedenih NS zapisa, ako se konfiguriše i A zapis za a.com, taj A zapis će biti prebačen od strane NS zapisa.

ARP protokol

ARP, odnosno protokol za razlaganje adresa, služi za ostvarivanje mapiranja iz IP adrese u MAC adresu — odnosno za ispitivanje MAC adrese koja odgovara ciljnoj IP adresi.

Proces rada ARP protokola

Prvo, svaki host u svom ARP kešu vodi ARP listu koja predstavlja odnos između IP adrese i MAC adrese.

Kada izvorni host želi da pošalje podatke, prvo proverava da li u ARP listi postoji MAC adresa hosta sa odgovarajućom ciljnom IP adresom; ako postoji, podatke šalje neposredno, a ako ne, šalje ARP paket svim hostovima u tom mrežnom segmentu.

Kada svi hostovi u toj mreži prime ARP paket, prvo proveravaju da li je IP adresa u paketu njihova sopstvena; ako nije, ignorišu paket, a ako jeste, prvo iz paketa izdvajaju izvornu IP i MAC adresu hosta i upisuju ih u ARP listu (ako zapis postoji, prepisuju ga), a zatim svoju MAC adresu upisuju u ARP odgovor i time saopštavaju izvornom hostu da su oni MAC adresa koju traži.

Nakon što izvorni host primi ARP odgovor, u ARP listu upisuje IP i MAC adresu ciljnog hosta i tim podacima šalje podatke; ako izvorni host nikako ne dobije ARP odgovor, to znači da je ARP upit neuspešan.

Digitalni potpis

Tokom prenosa preko mreže podaci prolaze kroz više posrednih čvorova; iako podaci ne mogu biti dešifrovani, ipak mogu biti izmenjeni.

Digitalni potpis proverava celovitost podataka.

Digitalni potpis ima dve uloge:

• Može da potvrdi da je poruku zaista potpisao i poslao pošiljalac, jer niko drugi ne može lažirati potpis pošiljaoca.

• Digitalni potpis može potvrditi celovitost poruke, odnosno dokazati da podaci nisu izmenjeni.

Tekst se prvo Hash funkcijom pretvara u sažetak poruke, zatim se privatnim ključem pošiljaoca šifruje u digitalni potpis, pa se zajedno sa originalnim tekstom šalje primaocu.

Primalac samo javnim ključem pošiljaoca može dešifrovati šifrovani sažetak, a zatim nad primljenim originalom Hash funkcijom generiše sažetak i poredi ga sa sažetkom iz prethodnog koraka.

Ako su isti, to znači da je primljena informacija celovita i da u toku prenosa nije menjana; u suprotnom je informacija menjana, pa digitalni potpis može proveriti celovitost informacije.

SQL injekcija

Princip SQL injekcije jeste napad u kome se SQL kod maskira u ulazni parametar i prosleđuje serveru na raščlanjivanje i izvršenje.

Primer SQL injekcionog napada

Na primer, na ekranu za prijavu, gde se traži korisničko ime i lozinka, možete ovako uneti i ostvariti prijavu bez naloga:

Korisničko ime: 'or 1 = 1 --
Lozinka:

Čim korisnik klikne na prijavu, ukoliko nije urađena specijalna obrada, ovaj nelegalni korisnik lako uđe.

Hajde da to analiziramo: teorijski, program za autentifikaciju na bek-endu sadrži sledeću SQL naredbu:

String sql ="select * from user_table where username=’ "+userName+” ’ and password=’ “+password+” ‘”;

Zato, kada se unese gore navedeno korisničko ime i lozinka, ta SQL naredba postaje:

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

Analizom gore navedene SQL naredbe vidimo da username=' or 1=1 nužno uspeva; zatim dodavanje dve crtice - označava komentar, koji komentariše ostatak naredbe i čini ga nevažećim. Na taj način gore navedena naredba uvek ispravno izvršava, pa korisnik lako prevari sistem i dobija legitiman identitet.

Mere zaštite

Prekompajliranje (precompilation)

Korišćenje prekompajliranja i vezivanje parametara jeste najbolji način zaštite od SQL injekcije.

Mnogi ORM okviri i JDBC već su implementirali SQL prekompajliranje i vezivanje parametara; napadačev zlonamerni SQL tretiraće se kao parametar SQL-a, a ne kao SQL komanda koja se izvršava.

U mapper fajlu mybatis-a, za prosleđene parametre obično koristimo ## i $ da bismo uzeli vrednost parametra.

Kada se koristi #, promenljiva je mesto rezervisano (placeholder), odnosno isti onaj placeholder koji koristimo kod jdbc PrepareStatement u Javi, pa može sprečiti SQL injekciju.

Kada se koristi $, promenljiva se direktno nadovezuje na SQL, pa obično postoji problem SQL injekcije.

Korišćenje regularnih izraza za filtriranje ulaznih parametara

Filtriranje ključnih reči baze podataka sadržanih u parametrima

Algoritmi enkripcije

Algoritmi enkripcije dele se na simetričnu enkripciju i asimetričnu enkripciju; kod simetričnih algoritama ključ za šifrovanje i ključ za dešifrovanje su isti, dok su kod asimetričnih algoritama ključ za šifrovanje i ključ za dešifrovanje različiti. Pored toga, postoji i klasa hash algoritama koja ne zahteva ključ.

Česti simetrični algoritmi uglavnom su DES, 3DES, AES i slični; česti asimetrični algoritmi uglavnom su RSA, DSA i slični, dok su hash algoritmi pretežno SHA-1, MD5 i slični.

Simetrična enkripcija

U simetričnim algoritmima postoji samo jedan ključ; i pošiljalac i primalac njime vrše šifrovanje, odnosno dešifrovanje podataka.

• Proces šifrovanja podataka: u simetričnom algoritmu, pošiljalac podataka otvoreni tekst (originalne podatke) i ključ za šifrovanje, nakon specijalne obrade šifrovanja, pretvara u složeni šifrovani tekst koji zatim šalje.

• Proces dešifrovanja podataka: primalac podataka, po prijemu šifrovanog teksta, želi li da pročita originalne podatke, mora upotrebom ključa korišćenog pri šifrovanju i inverznog algoritma istog algoritma dešifrovati šifrovani tekst, kako bi ga vratio u čitljiv otvoreni tekst.

Asimetrična enkripcija

Asimetrični algoritam zahteva dva ključa: jedan se naziva javni ključ (public key), odnosno javni ključ, a drugi privatni ključ (private key), odnosno privatni ključ.

Pošto se za šifrovanje i dešifrovanje koriste dva različita ključa, ovaj algoritam se naziva asimetričnim algoritmom.

1. Ako se podaci šifruju javnim ključem, samo odgovarajući privatni ključ može izvršiti dešifrovanje.

2. Ako se podaci šifruju privatnim ključem, samo odgovarajući javni ključ može izvršiti dešifrovanje.

Primer: strana A generiše par ključeva i jedan od njih, kao javni ključ, objavljuje ostalima; strana B, koja dobije taj javni ključ, njime šifruje poverljivu informaciju i šalje je strani A, a strana A zatim, pomoću svog specijalnog ključa (privatnog ključa) koji je sačuvala, dešifruje šifrovanu informaciju.

Mrežni napadi

CSRF i XSS

XSS:

Cross-site scripting (skriptovanje između sajtova) jeste napad iskorišćavanjem bezbednosne ranjivosti veb aplikacija i jedna je vrsta ubrizgavanja koda.

On omogućava zlonamernom korisniku da ubrizga kod u veb stranicu; ostali korisnici prilikom pregleda stranice bivaju pogođeni. Ovakvi napadi obično sadrže HTML i skriptne jezike na strani klijenta.

Na primer, preko skriptnog jezika na strani klijenta (najčešće JavaScript).

Objavljivanje zlonamerne JavaScript linije koda u forumu jeste ubrizgavanje skripte; ako taj kod zahteva eksterni server, radi se o XSS-u.

Podela XSS napada

Refleksni XSS napad (nepostojani XSS napad)

Na primer, normalno slanje poruke:

http://www.test.com/message.php?send=Hello,World!

Primalac prima poruku i prikazuje HelloWorld; međutim, abnormalno slanje poruke:

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>!

Primalac, prilikom prikaza poruke, videće iskačući prozor sa upozorenjem!

Postojani XSS napad (scenarij oglasne table)

Obično se odnosi na XSS napad čiji se kod čuva u bazi podataka sajta i izvršava kada korisnik otvori stranicu.

Drugim rečima, svaki put kada korisnik pregledačem otvori navedenu stranicu, skripta se izvršava.

U poređenju sa nepostojanim XSS napadom, postojani XSS napad je štetniji.

Iz samog imena se vidi: postojani XSS napad čini to što napadački kod unosi u bazu podataka, a zatim ga klijent izvršava pri otvaranju.

Na primer, polje formulara u formi oglasne table:

<input type="text" name="content" value="ovde su podaci koje korisnik unosi">

Normalan tok radnje: korisnik prosledi odgovarajuću poruku — podaci se skladište u bazu — ostali korisnici pristupaju oglasnoj tabli, aplikacija preuzima podatke i prikazuje ih;

Dok je abnormalan tok radnje da napadač u value upiše:

<script>alert('foolish!');</script> <!--ili druge html tagove (uništava stil...), deo napadačkog koda-->

i podatke prosledi i skladišti u bazu; kada drugi korisnici preuzmu i prikažu podatke, izvršiće se taj napadački kod.

CSRF:

Cross-site request forgery (falsifikovanje zahteva između sajtova) jeste napad kojim se korisnik natera da, na trenutno prijavljenoj veb aplikaciji, izvrši radnju koju nije nameravao.

Na primer, napadač se predstavlja kao korisnik i (bez znanja korisnika) pokreće zahtev koji izvršava radnje protiv korisnikove volje (npr. zlonamerno objavljivanje, brisanje, izmenu lozinke, slanje e-pošte i sl.).

DOS napad

DOS: naziv za uskraćivanje usluge (denial of service); efekat ovog napada je da računar ili mreža ne mogu pružati normalnu uslugu.

Princip DOS napada:

Napadač prvo ka napadnutom serveru šalje veliki broj zahteva sa lažnom IP adresom; napadnuti server po prijemu zahteva vraća potvrdu i čeka da napadač izvrši potvrdu — taj proces zahteva TCP three-way handshake. Pošto su zahtevi koje šalje napadač lažni, server ne prima potvrdu, pa ostaje u stanju čekanja određeno vreme, dok su resursi dodeljeni tom zahtevu i dalje zauzeti.

Kada napadnuti server posle određenog vremena prekine vezu zbog isteka vremena, napadač ponovo šalje nove lažne zahteve; tako se na kraju resursi servera iscrpe, sve do pada.

DDOS: distribuirani napad uskraćivanja usluge

To znači da napadač kontroliše više hostova koji istovremeno prema istom hostu ili mreži pokreću DOS napad.

DRDoS (distribuirani refleksivni napad uskraćivanja usluge) jeste varijacija DDoS napada.

Kako zaista radi DDOS

Trenutno najpopularniji i najefikasniji način napada jeste upotreba SYN-Flood-a — SYN-Flood je poplava SYN zahtevima.

SYN-Flood ne završava treći korak TCP three-way handshake-a, odnosno ne šalje serveru informaciju o potvrdi konekcije, pa server ne može dovršiti treći handshake; međutim, server se ne odriče konekcije odmah — on stalno pokušava i čeka određeno vreme pre nego što odustane od te nezavršene konekcije. Taj period se zove SYN timeout i iznosi oko 30 sekundi do 2 minuta.

Ako jedan korisnik pri konekciji ima problem koji natera jednu nit servera da čeka minut, to nije nešto strašno; međutim, ako neko specijalnim softverom masovno simulira takvu situaciju, posledice su lako predvidive. Ako server zbog obrade velikog broja polu-otvorenih konekcija potroši mnogo sistemskih resursa i mrežnog protoka, neće više imati kapacitet da obradi normalne zahteve običnih korisnika (jer je udeo normalnih zahteva klijenata vrlo mali), pa će server prestati da radi — takav napad se i zove SYN-Flood napad.

Do sada je odbrana od DDoS napada i dalje prilično teška.

Prvo, karakteristika ovog napada jeste da iskorišćava ranjivost TCP/IP protokola; jedino ako ne koristite TCP/IP, možete se u potpunosti odbraniti od DDoS napada.

Međutim, to ne znači da nemamo načina da zaustavimo DDoS napad — možemo maksimalno nastojati da ga ublažimo.

Evo nekih metoda odbrane:

1. Zatvaranje nepotrebnih servisa.

2. Ograničavanje broja istovremeno otvorenih SYN polu-konekcija.

3. Skraćivanje SYN timeout vremena za polu-konekcije.

4. Ispravno podešavanje firewall-a.

5. Zabrana pristupa hostu na servisima koji nisu otvoreni.

6. Ograničavanje pristupa sa određenih IP adresa.

7. Aktiviranje osobina firewall-a za zaštitu od DDoS-a.

Cookie i Session

Session je mehanizam zasnovan na Cookie-ju, kojim se beleži stanje sesije između servera i klijenta.

Session se čuva na serveru, dok se SessionId čuva u Cookie-ju na klijentu.

Proces autentifikacije Session-a:

1. Klijent prvi put šalje zahtev serveru; server na osnovu informacija kreira odgovarajući Session i u zaglavlju odgovora vraća SessionID.
2. Po prijemu SessionID-a od servera, klijent tu informaciju skladišti u Cookie i istovremeno beleži kom domenu taj SessionID pripada.
3. Kada klijent ponovo pristupi serveru, zahtev automatski proverava da li pod tim domenom postoji Cookie; ako postoji, šalje ga serveru; server iz Cookie-ja izdvaja SessionID, a zatim na osnovu njega pronalazi odgovarajući Session — ako Session postoji, zahtev se odobrava i nastavlja se izvršenje; u suprotnom se prekida.

Razlika između Cookie-ja i Session-a

1. Bezbednost: pošto se Cookie može menjati na strani klijenta, a Session se podešava samo na serveru, bezbednost Session-a je veća od Cookie-ja; obično se koristi za proveru stanja prijave korisnika.
2. Primena: Cookie može čuvati samo string podatke, dok Session može čuvati podatke proizvoljnog tipa.
3. Rok važenja: Cookie se može podesiti da važi proizvoljno vreme, dok Session obično kraće traje.

Česta pitanja sa razgovora za posao

Unos URL-a u adresnu traku pregledača

1. DNS razlaganje: pregledač, sloj po sloj, postavlja upit kešu DNS servera i razlaže IP adresu koja odgovara domenu iz URL-a; DNS keš, od najbližeg ka najdaljem, obuhvata keš pregledača, sistemski keš, keš rutera, keš IPS servera, keš servera domena i keš top-level domena.

Sa koje keš tačke se pronađe odgovarajuća IP adresa, odande se vraća i ne ispituju se kasnije tačke.

2. TCP konekcija: uz three-way handshake.

3. Slanje HTTP zahteva: pregledač šalje HTTP zahtev za čitanjem fajla, koji se prosleđuje serveru.

4. Server obrađuje zahtev i vraća HTTP poruku: server odgovara na zahtev pregledača i šalje mu HTTP poruku odgovora sa HTML tekstom.

5. Pregledač raščlanjuje i renderuje stranicu.

6. Kraj konekcije: pregledač oslobađa TCP konekciju, što jeste four-way handshake.

Korak 5 i korak 6 mogu se smatrati istovremenim; nema posebnog zahteva oko toga ko je prvi.

---

Autor: Yueban Feiyu, izvorna veza: https://mp.weixin.qq.com/s/7EddtzpwIRvYfw34QE4zvw