Nivelul aplicație

2.1. Principiile aplicațiilor de rețea

Dezvoltarea aplicațiilor de rețea presupune proiectarea și

implementarea unor programe care rulează pe diferite sisteme
gazdă și care comunică între ele prin rețea.

2.1.1. Arhitecturi ale aplicațiilor de rețea

- arhitectura rețelei este fixă și oferă un set specific de

servicii aplicațiilor
- arhitectura aplicației este proiectată de dezvoltatorul
aplicației și dictează modul în care aplicația este
structurată pe diferite sisteme finale
- exista doua feluri de arhitectura :
1. arhitectura client-server
2. arhitectura „peer-to-peer”

Arhitectura client-server
- în ea există un sistem gazdă mereu pornit, numit server,
care deservește cereri de la multe sisteme gazdă, numite
clienți
- serverul are o adresă fixă, numită adresă IP
- o soluție care se bazează pe un singur sistem server este
incapabilă să țină pasul cu toate solicitările clienților
Arhitectura „peer-to-peer”
- exploatează comunicarea directă între perechile de gazde
conectate intermitent
- comunică fără a trece printr-un server dedicat
- una dintre cele mai importante caracteristici este
auto-scalabilitatea
- se confruntă cu trei provocări majore:
1. Trebuie să se integreze în ecosistemul furnizorului de
servicii de Internet (ISP)
2. Securitate
3. Stimulente pentru promovarea aplicațiilor P2P

Există și situații în care unele aplicații au arhitecturi hibride,

combinând atât elemente client-server cât și elemente P2P.

2.1.2. Comunicarea între procese

Procesele de pe două sisteme diferite comunică între ele prin

schimburi de mesaje prin rețeaua de calculatoare.

Procese client și server

O aplicație de rețea este alcatuita din perechi de procese care

își trimit mesaje reciproc printr-o rețea.
 Putem eticheta un proces drept client și celălalt proces ca
server.
În partajarea de fișiere P2P, atunci când A îi cere lui B să-i
trimită un anumit fișier, A este clientul și B este serverul.

Interfața dintre proces și rețeaua de calculatoare

Orice mesaj trimis de la un proces la altul trebuie să treacă

prin rețeaua de bază.
Un proces trimite mesaje și primește mesaje din rețea printr-o
interfață software numită socket.
Socket-ul este interfața de programare cu care sunt construite
aplicațiile de rețea.

Mecanismul de adresare

Pentru ca un proces care rulează pe un sistem gazdă să

trimită pachete către un alt proces care rulează pe un alt sistem
gazdă, procesul de recepție trebuie să aibă o adresă.
Pentru a identifica procesul de recepție, trebuie specificate
două informații:
- adresa sistemului gazdă
- un identificator care specifică procesul de recepție din
sistemul gazdă destinație
În Internet, un sistem gazdă este identificat prin adresa IP.
 Pe lângă cunoașterea acestei adrese, procesul de trimitere
trebuie să specifice și procesul de primire.
În general, un sistem gazdă ar putea rula mai multe aplicații de
rețea de aceea trebuie specificata aceasta informatie.
Aceste procese sunt identificate printr-un număr de port.

2.1.3. Servicii de transport disponibile pentru aplicații

Alegerea unuia sau dintre protocoalele disponibile trebuie să

se facă pe baza unei analize a acestora, iar în final să fie
selectat protocolul cu serviciile care se potrivesc cel mai bine
nevoilor aplicației dezvoltate.
Putem clasifica serviciile posibile astfel :
- transfer fiabil de date
- debitul de date
- constrângeri de timp
- securitate
 Transfer fiabil de date

Dacă un protocol oferă un serviciu de livrare de date garantat,

se spune că asigură un transfer de date fiabil.
Atunci când un protocol de transport oferă acest serviciu,
procesul de trimitere poate transmite datele sale prin socket și
poate ști cu deplină încredere că datele vor ajunge fără erori la
procesul de recepție.
Atunci când un protocol de transport nu oferă acest serviciu,
este posibil ca unele dintre datele trimise de procesul de
trimitere să nu ajungă niciodată la procesul de recepție.
Acest lucru poate fi acceptabil pentru aplicațiile tolerante la
pierderi.

Debitul de date

Debitul de date este rata la care procesul de trimitere poate

livra biți către procesul de recepție.
Debitul de date disponibil poate fluctua în timp.
Aplicațiile elastice pot utiliza cât de mult sau cât de puțin debit
se întâmplă să fie disponibil.
Cu cât este mai mult debit disponibil, cu atât mai bine.
 Constrângeri de timp

Fiecare bit pe care expeditorul îl „pompează” prin socket

ajunge la socket-ul de recepție cu cel mult 100 msec mai târziu.
Aplicațiile interactive în timp real necesita constrângeri de timp
la livrarea datelor pentru a fi eficiente.
Nu există restricții importante privind întârzierile de la un capăt
la altul.

Securitate

Un protocol de transport poate furniza unul sau mai multe

servicii de securitate :
- confidențialitate
- integritatea datelor
- autentificarea
- sistemelor terminale

2.1.4. Servicii de transport furnizate de Internet

Rețeaua Internet pune la dispoziția aplicațiilor două protocoale

de transport, UDP și TCP.
Atunci când se creează o nouă aplicație de rețea pentru
Internet, una dintre primele decizii care trebuie luate este dacă
se utilizează UDP sau TCP.
 Servicii TCP

- include un serviciu orientat pe conexiune și un serviciu de

transfer de date fiabil
- cand este invocată, aplicația beneficiază de ambele
servicii de la TCP
Serviciu orientat spre conexiune :
- procesele client și server schimba informațiile de control
ale nivelului de transport înainte ca mesajele de la nivelul
aplicație să înceapă să curgă (handshaking)
- prin handshaking clientul și serverul se pregătesc pentru
transferul de pachete
- după faza de handshaking, spunem că există creată o
conexiune TCP (full-duplex) între socket-urile celor două
procese
- când aplicația termină de trimis mesaje, conexiunea
trebuie întreruptă
Serviciu de transfer de date fiabil:
- procesele de comunicare se pot baza pe TCP pentru a
livra toate datele trimise fără erori și în ordinea corectă

Mecanismul de control al congestiei TCP restrânge un proces

de trimitere (client sau server) atunci când rețeaua este
aglomerată între expeditor și receptor.
 Servicii UDP

- este un protocol de transport simplu, care oferă servicii

minimale.
- este un protocol fără conexiune, deci nu există o etapă
handshake
- oferă un serviciu de transfer de date nesigur
- nu include un mecanism de control al congestiei

2.2. World Wide Web

- utilizatorii primesc ceea ce doresc, când doresc.

- este extrem de ușor pentru orice persoană să ofere
informații pe Web

2.2.1. Prezentare generală a HTTP

- este protocolul nivelului aplicație al World Wide Web-ului

- este un protocol fără stare
- își trimite informațiile de control în bandă
- definește modul în care procesele client și server schimbă
între ele mesaje, precum și structura acestor mesaje
 - definește modul în care clienții Web solicită pagini Web de
la servere Web și modul în care serverele transferă pagini
Web către clienți
- folosește TCP ca protocol de transport de bază
- odată ce mesajele au trecut prin socket, în nivelul de
transport acestea nu mai sunt sub controlul aplicațiilor ci
sunt „la mâna” protocolului TCP
- HTTP nu trebuie să-și facă griji cu privire la datele
pierdute sau detaliile despre modul în care TCP rezolva
pierderea sau reordonarea datelor din rețea
- serverul trimite fișierele solicitate către clienți fără a stoca
nicio informație de stare despre aceștia

2.2.2. Conexiuni non-persistente și persistente

În multe aplicații de Internet, clientul și serverul comunică

pentru o perioadă extinsă de timp, clientul făcând o serie de
solicitări și serverul răspunzând la fiecare dintre cereri.
Când această interacțiune client-server are loc prin TCP,
dezvoltatorul aplicației trebuie să ia o decizie importantă
- dacă fiecare pereche de solicitare–răspuns este trimisă
printr-o conexiune TCP separată (conexiuni
non–persistente)
- dacă toate aceste perechi cerere–răspuns se vor trimite
prin aceeași conexiune TCP (conexiuni persistente)
HTTP cu conexiuni non-persistente :
- fiecare conexiune TCP este închisă după ce serverul
trimite obiectul
- fiecare conexiune TCP transportă exact un mesaj de
solicitare și un mesaj de răspuns
HTTP cu conexiuni persistente :
- trebuie stabilită și menținută o conexiune nouă pentru
fiecare obiect solicitat
- trebuie alocate buffere și variabile TCP care trebuie
păstrate atât în client cât și în server

2.2.3. Formatul mesajului HTTP

Există două tipuri de mesaje HTTP :

- mesaje de solicitare

- primul rand al unui mesaj de solicitare HTTP se numește

randul cererii (request line)
- rândurile următoare se numesc rândurile antetului
- rândul cererii are trei câmpuri: câmpul metodei, câmpul
URL și câmpul versiunii HTTP
 - mesaje de răspuns
- are trei secțiuni: un rând pentru indicarea stării, șase
rânduri de antet și apoi corpul mesajului.
- corpul mesajului conține însuși obiectul solicitat.
- linia de stare are trei câmpuri: câmpul versiunii
protocolului, un cod de stare și un mesaj de stare
corespunzător.

2.2.4. Interacțiunea utilizator-server: cookie-uri

- cookie-urile, permit site-urilor să „urmărească” utilizatorii
- are patru componente :
1. o linie de antet cookie în mesajul de răspuns HTTP
2. o linie de antet cookie în mesajul de solicitare HTTP
3. un fișier cookie păstrat pe sistemul final al utilizatorului și
gestionat de browser-ul sau
4. o bază de date pe partea serverului Web
 2.3. Transfer de fișiere. Protocolul FTP

Într-o sesiune FTP tipică, utilizatorul operând un sistem gazdă

dorește să transfere fișiere către un sistem gazdă sau de pe un
sistem gazdă aflat la distanță.
Pentru ca utilizatorul să acceseze contul respectiv la distanță,
trebuie să furnizeze un set de credențiale.
După acestea, utilizatorul poate transfera fișiere din sistemul
de fișiere local în sistemul de fișiere la distanță și invers.
HTTP și FTP sunt protocoale de transfer de fișiere și au
caracteristici comune cum ar fi ca ambele folosesc TCP ca
protocol de transport .
Cele două protocoale au și unele diferențe importante cum ar
fi faptul ca FTP folosește două conexiuni TCP paralele pentru a
transfera un fișier, una de control și una de date.
Conexiunea de control este utilizată pentru trimiterea
informațiilor de control între cele două gazde.
Conexiunea de date este utilizată pentru a trimite efectiv un
fișier.
FTP trimite informațiile sale de control în afara benzii.
 2.3.1. Comenzi FTP
Unele dintre cele mai comune comenzi sunt :
USER username : Trimite numele utilizatorului către server
PASS password : Trimite parola utilizatorului către server
LIST : Solicită serverului să trimită o listă cu toate fișierele din
directorul curent
RETR filename : Solicită serverului să trimită fișierul specificat,
din directorul curent
STOR filename: Solicită serverului să stocheze un fișierul
specificat, pe care clientul i-l va trimite, în directorul curent al
serverului, la distanță.

Unele răspunsuri tipice, împreună cu mesajele lor posibile,

sunt:
- 331 Username OK, password required
- 125 Data connection already open; transfer starting
- 425 Can’t open data connection
- 452 Error writing file
 2.4. Protocolul DNS

Pentru a putea accesa un sistem gazdă în Internet avem

nevoie să-l putem identifica.
Sistemele gazdă din Internet pot fi identificate printr nume și
adresă IP.
O adresă IP este alcatuita din patru octeți și are o structură
ierarhică rigidă.

2.4.1. Servicii furnizate de DNS

- este o bază de date distribuită implementată într-o ierarhie

de servere DNS și un protocol de nivel de aplicație care
permite gazdelor să interogheze baza de date distribuită.
- folosește UDP ca protocol de transport și portul 53
- este utilizat în mod obișnuit de alte protocoale de nivel de
aplicație inclusiv HTTP și FTP pentru a traduce în adrese
IP numele sistemelor gazdă furnizate de utilizator

Pe lângă traducerea numelor de gazdă în adrese IP, DNS oferă

câteva alte servicii importante:
- host aliasing
- mail server aliasing
- load distribution
 2.4.2. Prezentare generală a modului în care funcționează
DNS

În această abordare centralizată, clienții direcționează toate

interogările către un singur server DNS, iar serverul le
răspunde direct acestora.
O bază de date centralizată într-un singur server DNS pur și
simplu nu se poate extinde, deci DNS-ul trebuie să aibă un
design distribuit.

O bază de date ierarhică distribuită

Pentru a rezolva problema scalării, DNS utilizează un număr

mare de servere, organizate într-un mod ierarhic și distribuite în
întreaga lume.
Există trei clase de servere DNS :
- servere DNS rădăcină ( o rețea de servere replicate, atât
din motive de securitate, cât și de fiabilitate)
- servere DNS de nivel superior ( sunt responsabile pentru
domeniile de nivel superior )
- servere DNS autorizate ( asociază numele sistemelor
gazdă care sunt accesibile publicului pe Internet cu adrese
IP )
Mai există un alt tip important de server DNS numit server
DNS local.
Când un sistem se conectează la rețea, furnizorul de servicii
Internet îi pune la dispoziție adresele IP ale unuia sau mai
multor servere DNS locale.
Când acesta efectuează o interogare DNS, interogarea este
trimisă către serverul DNS local, care acționează ca un proxy,
redirectionand interogarea în ierarhia serverelor DNS.

Memorarea în cache a asocierilor (DNS Caching)

Pentru a îmbunătăți performanțele legate de „conversațiile”

cauzate de interogările DNS s-a recurs la utilizarea unor spații
de memorare (cache) într-un server DNS „din apropiere”.
Atunci când un server DNS primește un răspuns acesta poate
memora informația respectivă în memoria sa locală.
Deoarece asocierile dintre numele sistemelor gazdă și adresele
IP nu sunt nicidecum permanente, serverele DNS renunță la
informațiile memorate în cache după o perioadă de timp.

2.4.3. Înregistrări DNS

Serverele DNS care implementează împreună baza de date
distribuită DNS stochează înregistrări despre resurse.
Acestea includ înregistrările care furnizează asocierile între
nume și adrese IP.
 Fiecare mesaj de răspuns DNS „transportă” una sau mai
multe înregistrări despre resurse.
O înregistrare despre resurse contine urmatoarele campuri
(Name, Value, Type, TTL)
TTL - este durata de viață (Time-To-Live) a înregistrărilor de
resurse și determină când o resursă trebuie eliminată dintr-un
cache.

2.4.4. Mesaje DNS

Mesajele DNS de interogare și de răspuns sunt singurele două

tipuri de mesaje DNS. Atât mesajele de interogare, cât și cele
de răspuns au același format.