CAPITOLUL 4

Stratul Transport din OSI

4.0.1. Introducere

In acest capitol, vom examina rolul stratului Transport in incapsularea datelor pentru a
putea fi folosite de stratul retea. Stratul Transport are de asemenea urmatoarele functii
cuprinse in el:
Permite aplicatiilor multiple ,aflate pe un singur dispozitiv, sa comunice in retea in acelasi
timp;
Asigura ca, daca este necesar, toate datele sunt receptionate si ordonate de aplicatia
corecta la destinatie
Foloseste mecanisme de gestionare a erorilor

La sfarsitul acestui capitol, veti putea sa:

Explicati necesitatea stratului Transport;

Descrieti rolul stratului Transport in timp ce asigura transferul de date end-to-end intre
aplicatii (intre doua dispozitive/echipamente sursa si destinatie – PC-uri, server-e etc );
Descrieti rolul celor doua protocoale ce fac parte din stratul Transport: TCP si UDP;
Explicati functiile principale ale stratului Transport, incluzand siguranta
transferului(reliability) , asocierea porturilor cu aplicatiile utilizator(port addressing) si
segmentarea;
Explicati cum TCP si UDP asigura indeplinirea functiilor principale;
Identificati cand este potrivit sa folositi TCP sau UDP si dati exemple de aplicatii care
folosesc fiecare protocol.
4.1.1.1. Scopul stratului de Transport

Stratul Transport asigura segmentarea datelor si controlul necesar la reasamblarea

fragmentelor in diverse fluxuri de date. Principalele responsabilitati in indeplinirea acestui
obiectiv sunt :

Separarea comunicatiilor individuale intre aplicatiile de la sursa la destinatie;

Segmentarea datelor si gestionarea fiecarui fragment;
Reasamblarea/concatenarea segmentelor in fluxuri recunoscute de aplicatii (recunoscute
de aplicatiile carora le sunt adresate);
Identificarea diferitelor aplicatii (prin acel port/numar).

Separarea conversatiilor individuale

Orice host (dispozitiv – pc, server, etc) poate avea instalate, multiple aplicatii care
comunica in retea. Fiecare dintre aceste aplicatii va comunica cu una sau mai multe
aplicatii cu un alt host la distanta. Este responsabilitatea stratului Transport de a asigura
suportul pentru comunicatii multiple de fluxuri intre aceste aplicatii.

Segmentarea datelor

Asa cum fiecare aplicatie creaza un flux de date pentru a fi transmis unei aplicatii la
distanta, tot asa aceste date trebuie pregatite in vederea transmiterii in mediu, in
fragmente gestionabile. Protocoalele stratului Transport descriu segmentarea acestor
fluxuri de la nivelul aplicatie in segmente. Aceasta include si incapsularea necesara
fiecarui fragment de date. Fiecare fragment de date necestita adaugarea unui antet la
nivelul Transport pentru a indica carei comunicatii ii este asociat.

Reasamblarea segmentelor

Fiecare fragment este trimis la aplicatia potrivita, in momentul in care ajunge la destinatie.
In plus, aceste fragmente individuale de date trebuie sa fie reconstruite intr-un flux
complet (fluxul sursa) pentru a fi folositoare si utilizabile la nivelul aplicatie.Protocoalele
de la nivelul Transport descriu modul in care informatiile din antetul stratului Transport
sunt folosite la reansamblarea fragmentelor de date in fluxuri (streams) pentru a fi
transmise mai departe nivelului Aplicatie.

Identificarea aplicatiilor

In vederea transmiterii fluxurilor aplicatiilor corespunzatoare, stratul Transport trebuie sa

identifice aplicatia caruia ii este destinat fluxul. Pentru a indeplini aceasta sarcina, stratul
Transport asociaza aplicatiei un identificator. Protocoalele TCP/IP numesc acest
identificator numar de port (port number – port logic). Fiecarui proces software ce are
nevoie sa comunice in retea, ii este alocat un port logic numit si identificator unic. Acest
port logic este utilizat in antetul stratului Transport (antetul datagramei Transport) pentru
a indica carei aplicatii ii sunt destinate datele.

Nivelul Transport este liantul intre stratul Aplicatie si straturile inferioare responsabile de
transmisia efectiva de date (1,2,3 OSI). Acest strat Transport accepta datele provenite
din multiple conversatii (de nivel Aplicatie) si le transmite in jos catre stratul cel mai de
jos, ca date gestionabile si care intr-un final sunt multiplexate in mediul de transmisie.

Aplicatiile nu trebuie sa cunoasca mecanismele de functionare a retelei folosite.

Aplicatiile genereaza datele ce trebuiesc transmise de la o aplicatie la alta fara sa le
intereseze tipul host-ului destinatie, tipul mediului de transmisie, calea pe care sunt
transportate, congestia dintr-un link, sau dimensiunea retelei.

In plus, straturile inferioare nu cunosc ca mai multe aplicatii transmit date in retea.
Responsabilitatea lor(a protocoalelor inferioare stratului transport) este sa livreze datele
destinatiei corespunzatoare (hostului destinatie careia ii sunt adresate). Stratul Transport
filtreaza aceste fragmente inainte de transmiterea lor la aplicatia destinatie. Aceasta
filtrare consta in analizarea fiecarui port din antetul fragment si transmiterea lor catre
aplicatia careia ii este asociat acest port.

Cerinte variabile la transportul datelor in retea

Din cauza faptului ca diverse aplicatii au cerinte diferite, exista mai multe protocoale care
opereaza la nivelul stratului Transport. Pentru anumite aplicatii, segmentele trebuie sa
ajunga la destinatie intr-o ordine specifica in vederea procesarii cu succes. In unele
cazuri, TOATE datele trebuie receptionate pentru a fi folosite. In alte cazuri, o aplicatie
poate tolera unele pierderi de date in timpul transportului in retea.

In retelele contemporane unificate, aplicatii cu cerinte de transport foarte diferite pot

comunica in aceeasi retea. Diverse protocoale ale stratului Transport au reguli diferite ce
permit dispozitivelor sa gestioneze aceste cereri diferite.

Unele protocoale asigura minimul functiilor necesare pentru a transfera fragmentele de

date intre aplicatiile implicate in conversatie. Aceste tipuri de protocoale sunt folositoare
aplicatiilor sensibile la intarzieri.

Alte protocoale ale stratului Transport descriu procesele ce asigura functionalitati

suplimentare, cum ar fi transmiterea in siguranta a datelor intre aplicatii. O data cu
asigurarea transportului, aceste functii suplimentare induc o incarcare suplimentara in
ceea ce priveste timpii de procesare (incarcarea procesorului echipamentului) si fac
cereri suplimentare in retea in sensul de retransmitere a segementelor care nu ajung la
destinatie (incarca reteaua cu trafic de date suplimentar).
4.1.1.2. Scopul stratului Transport

Separarea comunicatiilor multiple

Sa luam cazul unui calculator (PC), conectat la o retea, a carui utilizator, foloseste in
acelasi timp serviciul de mesagerie electronica (e-mail), navigheaza pe internet si
transfera fisiere. Fiecare din aceste aplicatii trimit si primesc date in/din retea in acelasi
timp. Chiar si in acest caz, datele trimise unei aplicatii nu se vor “amesteca” cu datele a
caror destinatie este alta aplicatie.

Mai mult, utilizatorii de servicii e-mail, de exemplu, necesita receptionarea in integralitate

a mesajului pentru a fi folositor. Daca este necesar ca datele sa ajunga integral la
destinatie, micile intarzieri datorate transportului in siguranta, sunt acceptate.

In contrast cu cele mentionate anterior, lipsa unor fragmente mici dintr-o conversatie
telefonica, poate fi considerata acceptabila. Aceasta deoarece se poate deduce din
context fragmentul lipsa sau cerand celeilalte persoane sa repete. Acest lucru este
preferabil intarzierilor ce ar rezulta din cauza cererilor suplimentare catre retea in vederea
retransmiterea segmentelor lipsa/pierdute. In acest exemplu, utilizatorul – nu reteaua –
gestioneaza retransmiterea sau inlocuirea informatiilor lipsa.
4.1.1.3. Scopul nivelului transport

Asa cum este explicat in pargraful anterior, transmiterea unor tipuri de date – video de
exemplu – in retea, ca flux continuu, ar impiedica alte comunicatii, in acelasi timp. De
asemenea, mecanismul de recuperare si retransmisie a datelor alterate din retea ar fi
dificil.

Divizarea datelor (fluxului de date) in parti/fragmente mai mici, permite multiplexarea

(intercalarea) conversatiilor in aceasi retea.

Segmetarea datelor, in concordanta cu protocoalele stratului Transport, precizeaza rolul

transmitatorului si receptorului de date cand ruleaza aplicatii multiple simultane. Fara
segmentare, doar o singura aplicatie, ar putea sa primeasca date. Cu alte cuvinte un
utilizator nu ar putea receptiona e-mail, in timp ce vizualizeaza pagini web.

La nivelul transport, fiecare set de fragmente, care circula intre aplicatia sursa si
destinatie este numit conversatie.

Pentru a identifica fiecare segment de date, stratul Transport adauga fiecarui fragment un
antet, rezultand astfel segmentul. Continutul acestui antet asigura fiecaruia dintre
protocoalele Transport sa efectueze functii diferite. Cu alte cuvinte UN PROTOCOL
asigura servicii pentru MAI MULTE APLICATII utilizator.
4.1.2.1. Gestionarea conversatiilor

Functiile principale specificate de toate protocoalele stratului transpor includ:

Segmentarea si reansamblarea – Marea majoritate a retelelor au limitari cu privire la

cantitatea de date ce poate fi incorporata intr-o singura datagrama. Stratul Transport
fragmenteaza datele aplicatiilor in blocuri de date corespunzatoare limitelor. La
destinatie, stratul Transport, reasambleaza datele inainte de a le transmite catre aplicatia
destinatie.

Multiplexarea conversatiei – Pot exista multe aplicatii sau servicii ce ruleaza pe fiecare
host in retea. Fiecarei aplicatii sau fiecarui serviciu ii este asociata o adresa cunoscuta ca
port care identifica carei aplicatii ii sunt destinate datele. In doua cuvinte, datele care
contin in antet portul 80, sunt transmise protocolului HTTP.

In afara folosirii datelor din antet ,pentru indeplinirea functiilor de baza (segmentare si
reansamblare), protocoalele din stratul Transport asigura si :
Comunicarea orientata pe conexiune
Livrarea garantata/in siguranta (datele ajung la aplicatia destinatie in ordine si integral)
Reansamblarea datelor in ordine
Controlul fluxului
4.1.2.2. Gestionarea conversatiilor

Stabilirea unei sesiuni

Stratul Transport poate asigura comunicarea orientata pe conexiune prin crearea unei
sesiuni intre aplicatii. Aceste conexiuni premergatoare comunicarii pregatesc aplicatiile sa
comunice inainte ca orice date sa fie transmise intre sursa si destinatie. In timpul acestor
sesiuni, datele ce fac obiectul comunicarii intre cele doua aplicatii pot fi gestionate cu
rigurozitate.

Livrarea garantata

Din motive multiple, este posibil ca un fragment de date sa fie corupt (datele transmise de
sursa nu sunt IDENTICE cu cele de la destinatie), sau pierdut complet, in timpul
transportului prin retea. Stratul Transport poate garanta ca toate fragmentele ajung la
destinatie cerand sursei sa retransmita orice fragment lipsa.

Livrarea in aceeasi ordine

Datele pot ajunge la destinatie in dezordine, deoarece retelele asigura rute multiple de
transport si fiecare ruta poate avea timpi diferiti de transmisie (intarzieri diferite). Prin
numerotarea segmentelor, stratul transport asigura ca aceste segmente sunt
reansamblate in ordine.

Controlul fluxului
Gazdele din retea au resurse limitate, cum ar fi memoria sau latimea de banda. Cand
stratul Transport este anuntat ca aceste resurse sunt suprasolicitate, unele protocoale
(din cadrul acestui strat) pot cere reducerea ratei de transmisie. Acest lucru este infaptuit
la nivelul Transport prin reglementarea cantitatii de date (luate ca grup - segment)
transmise de sursa.

4.1.3. Asigurarea suportului pentru comunicatiilor garantate

Aminititi-va ca functia de baza a nivelului Transport este de a gestiona datele aplicatiilor

din conversatia intre gazde. Oricum, diferite aplicatii au diverse cerinte pentru date si de
aceea au fost dezvoltate protocoale de transport diferite pentru a raspunde acestor
cerinte.

Un protocol al stratului Transport poate pune in aplicare o metoda, in vederea livrarii

garantate (in siguranta) a datelor. In terminologia de retea, siguranta inseamna ca fiecare
fragment de date transmis de sursa ajunge la destinatie. In acest sens, la nivelul
Transport exista trei operatii de baza:
urmarirea datelor transmise;
confirmarea datelor receptionate;
retransmiterea datelor neconfirmate.

Aceasta necesita ca procesele din stratul Transport, de la sursa, sa urmareasca fiecare

fragment, din fiecare conversatie si sa retransmita datele la care nu s-a raspuns cu
confirmare de la destinatie. Stratul Transport, de la destinatie trebuie de asemenea sa
urmareasca datele la primire si sa confirme.

Aceste procese care garanteaza comunicarea incarca suplimentar resursele retelei,

datorita confirmarilor, procesului de urmarirea (tracking) si procelului de retransmisie.
Pentru a asigura transportul garantat al datelor , intre gazda sursa si destinatie sunt
schimbate date suplimentare de control. Aceste informatii de control sunt incluse in
antetul Transport.

Aceasta duce la corelarea sigurantei datelor cu incarcarea suplimentara indusa de datele

suplimentare in retea. Dezvoltatorii de aplicatii trebuie sa aleaga ce tip de protocol
transport este util, tinand cont de cerintele aplicatiilor. La nivelul Transport, sunt
protocoale care specifica ambele metode: in siguranta cu garantarea livrarii (reliable) si
fara garantarea livrarii (best-efort). In comunicatiile fara garantarea livrarii, nu exista
confirmari referitoare la datele ajunse la destinatie.

Cand este necesar transportul garantat (in siguranta) al datelor

Aplicatii, cum ar fi cele de baze de date, pagini web sau e-mail, necesita ca toate datele
transmise sa ajunga la destinatie in forma originala, pentru ca datele sa fie utilizabile.
Orice lipsa de date poate duce la o comunicatie alterata, care poate fi incompleta sau de
neutilizat. De aceea, aceste aplicatii sunt proiectate sa foloseasca protocolul nivelului
Transport care implementeaza garantarea livrarii datelor. In acest caz, incarcarea retelei,
cu date suplimentare, este considerata o necesitate.

Alte aplicatii sunt mai tolerante la pierderea a mici portiuni (fragmente) de date. De
exemplu, daca unul sau doua segmente dintr-un flux video nu ajung la destinatie, vor
crea doar o discontinuitate in flux. Aceasta poate apare ca o distorsiune a imaginii si de
multe ori utilizatorul nu o sesizeaza.

Impunand incarcarea suplimentara a retelei pentru a garanta livrarea datelor poate

reduce drastic functionarea aplicatiilor. Imaginea din fluxul video va fi degradata/alterata
in mare masura daca destinatia trebuie sa contabilizeze datele pierdute si sa intarzie
transmiterea fluxului in asteptarea datelor lipsa. Este mai bine sa redai imaginea, la
calitatea maxima posibila, compusa din segmentele deja ajunse si sa uiti de garantare
(adica sa nu mai astepti segmentele lipsa).
4.1.4. Protocoalele TCP si UDP (Transport Control Protocol si User Datagram Protocol)

Doua din cele mai utilizate protocoale ale stratului Transport, din stiva de protocoale
TCP/IP sunt: protocolul de control al transmisie (Transmission Control Protocol - TCP) si
protocolul datagramelor utilizator (User Datagram Protocol - UDP). Ambele protocoale
gestioneaza comunicarile intre aplicatii multiple. Diferenta dintre cele doua protocoale
consta in functiile specifice implementate.

Protocolul Datagramelor Utilizator (User Datagram Protocol - UDP)

Protocolul Datagramelor Utilizator (User Datagram Protocol – UDP), este un protocol

simplu (mai simplu decat protocolul TCP), descris in RFC 768. Are avantajul, ca asigura,
o incarcare minimala (in raport cu protocolul TCP) asupra retelei in procesul transmiterii
datelor. Aceste datagrame sunt transmise ca “best effort” (fara garantii) de catre
protocolul Transport afiliat.

Aplicatiile care folosesc UDP:

sistemul numelor de domenii;
fluxuri video;
transmisia de voce peste date (VoIP).

Protocolul de control al transmisiei (Transmission Control Protocol - TCP)

Acest protocol (TCP) este orientat pe conexiune si descris in RFC 793. TCP creaza
incarcari suplimentare pentru a duce la bun sfarsit sarcina. Functiile suplimentare
specificate de TCP sunt livrarea in aceeasi ordine, livrarea garantata (reliable) si controlul
fluxului. Fiecare segment TCP are o incarcare suplimentara de 20 de octeti (Bytes) si
anume antetul segmentului, in timp ce UDP are doar 8 octeti. Vedeti figura pentru
comparatie.

Aplicatii care folosesc TCP:

Browser-e web
E-mail
FTP

4.1.5.1. Asocierea porturilor

Identificarea conversatiilor

Sa luam in considerare cazul precedent in care un utilizator, prin intermediul unui

calculator primeste si transmite e-mail (posta electronica), vizualizeaza pagini web si
altele.

Serviciile bazate pe regulile TCP si UDP urmaresc cine cu cine comunica intr-un noian de
conversatii. Pentru a face diferenta intre segmentele si datagramele adresate fiecarei
aplicatii, antetele TCP si UDP contin campuri care pot identifica, in mod unic, aceste
aplicatii. Acesti identificatori unici se numesc numere de porturi (atentie porturi logice, nu
porturi fizice).

In antetul fiecarui segment sau datagrama, exista campuri in care este scris portul sursa
si portul destinatie. Numarul portului sursa este numarul care asociaza o aplicatie sursa
cu o anumita conversatie(unica), initiata de gazda locala. Numarul portului destinatie este
numarul comunicatiei asociate cu aplicatia ce ruleaza pe gazda la distanta.

Numerele de porturi sunt alocate prin metode diferite, depinzand daca mesajul este o
cerere sau raspuns. In timp ce proceselor de pe server-e le sunt alocate porturi statice,
clientilor li se aloca porturi dinamice pentru fiecare conversatie.

In momentul in care o aplicatie client trimite o cerere catre aplicatia server, portul
destinatie continut in antet este portul alocat serviciului “daemon’’ ce ruleaza pe gazda la
distanta (remote host). Acest port destinatie este alocat implicit ori este configurat manual
de catre administratorul server-ului. In primul rand vreau sa rup “nitel” pisica in doua in ce
priveste acest “daemon”. Acest “daemon”, pe care il voi folosi in continuare, nu este
altceva decat un proces ce ruleaza in memoria server-ului si care are ca scop principal sa
urmareasca (asculte) datele adresate portului asociat. In momentul in care datele sunt
adresate portului corespondent, ele sunt preluate si procesate de aplicatia respectiva. Un
exemplu de daemon – cel care urmareste cererile pentru portul 80, procesul (asociat
protocolului web - HTTP) rezident in memoria server-ului, va prelua si apoi procesa
aceste cereri, pentru ca in final sa transmita pagina de web celui care a facut cererea. In
al doilea rand, cateva randuri despre portul implicit sau configurat de catre administratorul
server-ului. O aplicatie server este configurata sa functioneze dupa standarde, de
exemplu o aplicatie server web, instalata cu parametrii impliciti, va face ca daemon-ul
asociat sa asculte pe portul 80. Acest lucru se poate schimba de catre gestionarul
aplicatiei server prin configurare manuala. Nu exista decat doua probleme, iar una este
majora. Prima problema este ca admin-ul respectiv trebuie sa verifice ca nu cumva un alt
daemon asociat altei aplicatii, sa zicem (web-ul securizat HTTPS), sa nu asculte pe
acelasi port. A doua problema, cea majora, este ca cei care vor sa acceseze o
pagina, sa zicem http://www.nerdad.du, trebuie sa scrie in navigatorul web
http://www.nerdad.du:”numar_port_configurat_manual”. V-ati dat seama, ceva de genul
http://www.nerdad.du:55, daca portul configurat manual pe server-ul web este “55”. Va
dati seama ce inseamna pentru marea majoritate sa tina minte pe ce port ruleaza un
server web, dar procedeul poate fi folosit ca metoda de securitate RUDIMENTARA.

Numarul portului sursa, pe scurt portul sursa, din antetul segmentului sau datagramei
cerere este generat aleator si are valori mai mari de 1023. Atat timp cat nu intra in conflict
cu un port folosit de sistem, clientul poate alege orice port utilizabil de sistem (de obicei
de la 1024 la 65535 inclusiv). Acest numar de port joaca rolul adresei aplicatiei expeditor
la care ajung raspunsurile de la destinatie. Nivelul Transport urmareste acest port si
aplicatia care a initiat cererea in asa fel incat, atunci cand este transmis un raspuns,
acesta este inaintat aplicatiei care a facut cererea. Portul aplicatiei care initiaza cererea
este folosit ca port destinatie in raspunsul ce se intoarce de la server (ganditi-va la
scrisori, de ce trec adresa expeditorului, ca sa stie destinatarul unde sa-mi transmita
raspunsul).

Combinatia dintre porturile nivelului Transport si adresele IP ce fac parte din nivelul
Retea (Network), identifica in mod unic un proces ce ruleaza pe un dispozitiv de retea
(calculator, server, imprimanta etc). Aceasta combinatie se numeste “socket”. O pereche
de socket-uri, formata din adresa sursa, adresa destinatie si porturile, este unica si
identifica o conversatie dintre doua host-uri.

Un alt exemplu, cererea catre un server web cu adresa IP 192.168.1.20, pe portul 80, de
a transmite o pagina web, va fi destinata socket-ului 192.168.1.20:80. Pare ciudata
aceasta reprezentare?
192.168.1.20 este adresa IP a calculatorului/serverului (la fel ca adresa dvs. de acasa )
ce urmeaza dupa acele doua puncte adica :80 reprezinta aplicatia al carei daemon
asculta pe acel port si anume 80 (se subantelege ca e vorba de un server web).
Cateva cuvinte despre “socket”. In dictionarele care nu au nici o legatura cu tehnologia IT
acestea sunt traduse ca “mufe” sau “prize”. Oare locuri de conexiune? Da locuri de
conexiune virtuala pentru fiecare aplicatie in parte. Si mai mult, mai multe conexiuni in
cadrul aceleiasi aplicatii(sa zicem ca deschid mai multe sesiuni de navigare web, de pe
acelasi calculator). Ce se intampla daca fac cereri simultan de pe un singur calculator(sa
zicem ca vreau sa accesez pagina http), catre acelasi server web, care contine o
multitudine de pagini, cum stie server-ul web sa-mi livreze pagini diferite catre acelasi
calculator, acelasi browser. Raspuns ... dupa portul destinatie.

Daca browser-ul de pe 192.168.100.48 cere o pagina web localizata si numarul portului

alocat dinamic este 49152, socket-ul pentru acea pagina va fi 192.168.100.48:49152

4.1.5.2. Adresarea porturilor

Autoritatea de Alocare a Numerelor in Internet (Internet Assigned Numbers Authority –

IANA) aloca, asa cum reiese din numele autoritatii, numere de porturi.

Exista diferite tipuri de numere de porturi :

Porturile binecunoscute (numere de la 0 la 1023) – aceste numere sunt rezervate pentru
servicii si aplicatii. Ele sunt, in mod obisnuit, folosite pentru aplicatii cum ar fi HTTP,
POP3/SMTP, Telnet si altele. Prin precizarea ca aceste porturi standardizate sunt porturi
pentru server-e, aplicatiile client pot fi programate sa faca cereri de conectare pe un port
specific asociat serviciului.

Porturile inregistrate (“registered ports” - de la 1024 la 49151) sunt alocate proceselor si

aplicatiilor utilizatorului. Aceste procese sunt in primul rand aplicatii individuale pe care
utilizatorul a ales sa le instaleze si nu aplicatii aplicatii ce primesc un port
binecunoscut(standard). Cand nu sunt folosite pentru resursele unui server, aceste
porturi pot fi folosite dinamic de un client ca fiind porturile lui sursa.

Porturile dinamice sau private (dynamic/private ports de la 49152 la 65535) – cunoscute

si ca porturi efemere, acestea sunt alocate dinamic aplicatiilor client ce initiaza o
conexiune. Nu este un lucru obisnuit ca un client sa se conecteze la un servici folosind un
port dinamic sau privat(cu toate unele programe de file sharing o fac).

Folosirea porturilor TCP si UDP impreuna de catre aceeasi aplicatie

Unele aplicatii pot folosi porturile TCP si UDP impreuna. De exemplu, incarcarea bezii
mai mica la UDP permite server-ului de nume (DNS) sa raspunda foarte repede cererilor
simultane adresate de catre mai multi clienti. Uneori, insa, transmiterea informatiilor
cerute necesita serviciul de transport in siguranta a datelor asigurat de TCP. In acest caz,
portul binecunoscut 53 este utilizat de amandoua protocoalele acestui servici.
4.1.5.3. Alocarea porturilor

Uneori este necesar de stiut ce conexiuni TCP sunt deschise si ruleaza pe o gazda de
retea. “Netstat” este un utilitar de retea important ce poate fi folosit la verificarea acestor
conexiuni. Netstat ne afiseaza liste de protocoale in lucru, adresa locala cu portul aferent,
adresa ip la distanta cu portul la distanta si starea conexiunii.

Conexiunile TCP necunoscute pot crea probleme majore de securitate. Aceasta

deoarece ele pot indica ca ceva sau cineva este conectat la gazda locala. In plus,
conexiuni TCP inutile pot consuma resurse importante de sistem si de aici scaderea
performantelor host-ului. Netstat trebuie folosit in vederea examinarii conexiunilor
deschise cand performantele par a fi mici.

Comanda netstat are multe optiuni folositoare.

4.1.6.1. Segmentarea si reasamblarea – “divide si cucereste”

In capitolul precedent a fost detaliat procesul de creare a datagramelor prin livrare a

datelor de la o aplicatie in jos prin intermediul diferitelor protocoale(existente la diferite
niveluri din stiva) pentru a crea o datagrama ce este transmisa apoi in mediul de
comunicatie. Cand aceasta ajunge la hostul destinatie, procesul este reluat, dar in sens
invers, pentru ca datele sa poata fi livrate aplicatiei corespunzatoare.

Unele aplicatii transmit cantitati mari de date – in unele cazuri mai multi gigabytes. Ar fi
imposibil sa transmita toate aceste date intr-o singura mare “bucata” de date. Nici o alta
aplicatie sau host nu vor putea transmite in timpul transmisiei GIGANT. Acest tip de
transmisie “giganta” poate dura minute sau chiar ore. In plus, daca ar aparea erori,
intregul fisier de date ar fi pierdut (nu ar ajunge la destinatie) sau ar trebui retransmis
INTEGRAL. Dispozitivele de retea nu ar avea memorie “buffers” suficient de mare pentru
a stoca parti ale acestei conversatii inainte de transmisie sau receptie. Limitele difera in
functie de tehnologia retelei si de specificul mediului de transmisie folosit.

Inainte de a trece mai departe vreau sa explic termenul “buffer”. In momentul in care o
sursa transmite date, destinatia are un mecanism de preluare a acestora din punct de
vedere al memoriei. Acest mecanism consta in asigurarea unei memorii tampon (buffer)
care sa permita destinatiei sa primeasca date continuu in timp ce datele deja primite sa
fie procesate in vederea transmiterii mai departe catre nivelul superior. Aceste memorii
buffer,memorii temporare de altfel, pot fi spatii alocate in RAM, pe HDD sau in chip-uri
speciale cum ar fi UART, folosite in comunicatiile seriale.

Divizarea datelor aplicatiei in fragmente asigura ca datele sunt transmise in limitele

acceptate de mediul de transmisie si ca datele provenite de la aplicatii diferite pot fi
multiplexate. Dreptul de a comunica aproape simultan este asigurat de acest proces
numit multiplexare.

TCP si UDP gestioneaza segmentarea diferit.

La TCP, fiecare antet de segment contine un numar de secventa(sequence number).

Acest numar de secventa permit functiilor nivelului Transport la destinatie sa
reansambleze segmente in ordinea in care ele au fost transmise. Acesta asigura ca
aplicatia destinatie primeste datele exact in forma in care sursa a intentionat.

Cu toate ca serviciile UDP urmaresc de asemenea conversatia dintre aplicatii, ele nu se

preocupa de ordinea in care informatiile au fost transmise . Nu exista numar de secventa
(sequence number) in antetul UDP. UDP este un model mai simplu , ca urmare, incarca
mai putin reteaua decat TCP si de aici transferul mai rapid al datelor.

Informatia poate sosi in ordine diferita fata de ordinea in care a fost transmisa, deoarece
diferite pachete pot circula pe cai diferite prin retea. O aplicatie ce foloseste serviciile
UDP trebuie sa tolereze faptul ca datele pot ajunge in alta ordine decat au fost transmise
de la sursa.

4.2.1. TCP – Crearea conversatiilor garantate/sigure (reliable)

Diferenta de baza intre TCP si UDP o constituie conversatia garantata(reliable).

Garantarea comunicatiei este indeplinita folosind sesiuni orientate pe conexiune
(connection-oriented). Inainte ca un host (gazda, calculator) ce foloseste TCP sa
transmita date altui host (gazda, server), nivelul Transport initiaza un proces pentru a
crea o conexiune cu destinatia. Aceasta conexiune permite urmarirea sesiunii sau
comunicarea fluxului intre host-uri. Acest proces asigura ca fiecare host este anuntat si
pregatit de comunicatie. O conversatie completa TCP necesita stabilirea sesiunii in
ambele sensuri intre host-uri.

Dupa ce sesiunea a fost stabilita, destinatia trimite confirmari sursei pentru segmentele
receptionate. Aceste confirmari formeaza baza garantarii livrarii datelor in sesiunile TCP.
Atat timp cat sursa primeste confirmari, stie ca datele au ajuns la destinatie. Daca sursa
nu primeste o confirmare intr-un interval de timp predefinit, retransmite datele lipsa la
destinatie.

O parte din “incarcarea in plus” (overhead) adusa retelei, de catre TCP, este traficul de
retea suplimentar, generat de confirmari si retransmisii (acknowledgements and
retransmissions). Stabilirea sesiunilor creaza “incarcare in plus” datorita segmentelor in
plus schimbate. Exista o “incarcare in plus” si la nivelul host-urilor creata de necesitatea
urmaririi segmentelor ce asteapta confirmare si de procesul de retransmisie.
Aceasta garantare este indeplinita cu ajutorul campurilor din atetul segment TCP, fiecare
camp avand un scop bine definit, asa cum reiese din figura. Aceste campuri vor fi
discutate mai incolo in aceasta sectiune.
4.2.2. Procesele server TCP

Asa cum am discutat mai devreme, procesele aplicatie ruleaza pe un server. Aceste
procese asteapta pana cand un client initiaza comunicatia, cu o cerere de informatii sau
alte servicii.

Fiecare proces aplicatie ce ruleaza pe un server este configurat sa foloseasca un numar

de port, implicit(standard) sau configurat de administratorul de system. Un server
individual nu poate avea doua servicii asociate cu acelasi numar de port TCP. Un host nu
poate aloca pentru aplicatiile locale server web si server de fisiere(FTP), acelasi port, sa
zicem 80. Cand unei aplicatii server ii este alocat un port, acel port este considerat
deschis (open). Aceasta inseamna ca nivelul Transport accepta si proceseaza segmente
adresate acelui port. Orice cerere a unui client adresata socket-ului
corect(adresa_ip:port_TCP) este acceptata si datele sunt livrate aplicatiei server. Pot
exista mai multe porturi deschise simultan pe server, cate unul pentru fiecare aplicatie
server activa. Este obisnuit pentru un server sa furnizeze mai mult de o aplicatie, cum ar
fi server web si server de fisiere in acelasi timp.

O cale de a imbunatatii securitatea pe un server este de a permite accesul numai la

anumite porturi, iar aplicatiile si serviciile asociate cu acele porturi sa fie accesibile numai
clientilor autorizati.
4.2.3. Stabilirea si inchiderea conexiunii TCP

Cand doua hosturi comunica folosind TCP, o conexiune este stabilita inainte ca datele sa
fie transmise. Dupa ce comunicatia este completa, sesiunea este inchisa si conexiunea
terminata. Mecanismele “conexiune” si “sesiune” permit TCP asigurarea functiei de
garantare.

Vedeti figura pentru stabilirea si teminarea unei conexiuni TCP.

Host-ul urmareste fiecare segment de date din cadrul unei sesiuni si schimba informatii
despre datele primite de fiecare host folosind informatiile din antetul TCP.
Fiecare conexiune inseamna comunicarea fluxului intr-un singur sens sau sesiunile de
stabilire si terminare a proceselor ce ruleaza pe host-uri.
Pentru stabilirea conexiunii, host-urile realizeaza o “sincronizare” in trei pasi (three-way
handshake). Bitii de control din antetul TCP indica progresul si starea conexiunii.

Procesul three-way handshake:

Stabileste daca dispozitivul destinatie este prezent in retea;
Verifica daca hostul destinatie are un seviciu activ si ca accepta cereri pe portul cerut de
sursa ;
Informeaza dispozitivului destinatie ca sursa intentioneaza sa stabileasca o sesiune de
comunicare pe acel port.

In conexiunile TCP, host-ul client initializeaza sesiunile catre server. Pentru a intelege
cum functioneaza procesul in trei pasi este important sa observati valorile schimbate intre
cele doua host-uri. Cei trei pasi in stabilirea conexiunilor sunt:

1. Clientul trimite un segment cu bitul SYN setat pe 1 (ceea ce inseamna cerere de

conexiune ) .

2. Server-ul raspunde cu un segment de date ce contine o confirmare

(ACKnowledgement) egala cu cu valoarea secventei + 1 (ACKS=SEQC+1). Valoarea
confirmarii este intotdeauna mai mare cu 1 decat SEQC deoarece ACK reprezinta
numarul octetului urmator asteptat. Aceasta confirmare permite clientului sa potriveasca
raspunsul cu segmentul original transmis serverului.
3. Clientul raspunde cu o valoare de confirmare (ACKnowledgement) egala cu valoarea
secventei primite de la server + 1 (SEQS) . Aceasta incheie procesul de stabilire a
conexiunii.

In antetul segmentului TCP, exista 6 campuri de control ( a cate un bit ) ce contin

informatii de control folositi la gestionarea proceselor TCP. Aceste campuri sunt:

URG – campul care determina importanta mesajului

ACK – campul care determina ca segmenutl este o confirmare

PSH – functia PUSH

RST – reseteaza conexiunea

SYN – cerere de conexiune

FIN – host-ul nu mai are date de transmis (cerere de inchidere a conexiunii)

Aceste campuri ne sunt prezentate ca indicatori, deoarece lungimea unui camp este de
un bit, el poate avea doar doua valori: 0 sau 1. Cand valoarea unui camp este 1, indica
ce informatii de control contine in antetul segmentului. Daca campul din antetul
segmentului (din cele sase campuri) SYN =1 inseamna ca cel care a trimis acest
segment doreste sa stabileasca o conexiune. Daca campul ACK = 1, in antetul
segmentului, segmentul respectiv reprezinta o confirmare. Ca idee generala, in momentul
in care unul din campuri(oricare din acestea sase) sunt setate de catre transmitator cu
valoarea “1” indica receptorului ce tip de comunicatie rezulta (stabilirea conexiunii - SYN,
transmiterea datelor, inchiderea/resetarea conexiunii – FIN/RST )

Procesul in 4 pasi de inchidere a conexiunii.

4.2.4.1. Stabilirea conexiunii TCP in trei pasi

Folosind aplicatia “wireshark” puteti analiza stabilirea conexiunii in 3 pasi

Pasul 1

Un client TCP initializeaza procesul de comunicare in trei pasi prin transmiterea unui
segment care in antet are bitul SYN setat pe valoarea 1 (Synchronize Sequence Number
– numarul secventei de sincronizare) cea ce indica o valoare initiala in numarul secventei
in antet (valoare aleatoare pe 32 de biti)
Indicatorul de control SYN este setat (SYN=1) si numarul relativ de secventa este 0. Desi
analizorul de protocol indica valorile relative pentru numarul de secventa si numerele de
confirmare, valorile reale sunt numere pe 32 biti.

4.2.4.2. Stabilirea conexiunii TCP in trei pasi

Pasul 2

Server-ele care folosesc TCP trebuie sa confirme primirea segmentului SYN de la client
pentru a stabilirea sesiunii intre client si server. Pentru aceasta, server-ul trimite un
segment raspuns clientului ce contine pe campul de control ACK valoarea 1 (ceea ce
inseamna ca acest segment raspuns este o confirmare ). Acest segment de confirmare
indica clientului ca server-ul a receptionat cererea de conexiune segmentul SYN.

Valoarea numarului de confirmare este egal cu valoarea initiala trimisa de client +1

(SYN+1). Aceasta stabileste o sesiune de la client la server. Indicatorul ACK va ramane
setat pe 1 pentru restul sesiunii. Amintitiva ca conversatia intre client si server este, de
fapt, o conversatie compusa din doua sesiuni intr-un singur sens: una de la client la
server, iar cealalta de la server la client. In acest al doilea pas din cei trei, server-ul
trebuie sa transmita raspunsul catre client. Pentru stabilirea aceastei sesiuni (pasul 2
raspuns) server-ul foloseste indicatorul de stabilirea conexiunii SYN in acelsi fel ca si
clientul. Indicatorul SYN server arata ca valoare SYN-server ca valoarea numarului de
secventa-server este in antet. Aceasta valoare va fi folosita pentru urmarirea transmiterii
datelor, in aceasta sesiune, inapoi de la server la client.
Asa cum se vede in figura de mai jos, analizorul de protocol (wireshark), ne infatiseaza
ca indicatorii ACK si SYN sunt setati pe valoarea 1.

Frame 15

4.2.4.3. Stabilirea conexiunii TCP in trei pasi

Pasul 3
In final, clientul raspunde cu un segment ce contine o confirmare-raspuns, cererii SYN
trimise de server. In aceste segmente nu exista date utilizator. Valoarea continuta in
campul de confirmare contine un alt ISN (initial sequence number received from the
server). In momentul in care amandoua sesiunile (comunicatia client-server si server-
client) sunt stabilite, toate segmentele urmatoare din aceasta conexiune vor avea
ACK=1(confirmarile de primire vor fi intotdeauna, important este numarul utlimului octet
receptionat ).

Un plus de securitate poate fi adaugat datelor prin:

Interzicerea stabilirii conexiunilor TCP
Stabilirea echipamentelor de retea care au voie sa initializeze conexiuni
Permitand doar traficul de date apartinand sesiunilor deja stabilite

Acest tip de securitate poate fi implementat pentru toate sesiunile TCP sau doar pentru
anumite sesiuni.
4.2.5.1. Inchiderea sesiunilor TCP

Pentru inchiderea unei sesiuni, indicatorul FIN (Finish) din antetul segmentului trebuie sa
fie setat, ca si in cazul precedent, aceasta inseamna ca FIN=1. Pentru a inchide fiecare
din sesiunile cu sens unic, se foloseste un proces in doi pasi, compus dintrun segment
FIN si un segment de confirmare (ACK). De aceea pentru a inchide o singura conversatie
este nevoie de patru schimburi de segmente de control.

1. Cand clientul nu mai are date de transmis, trimite un segment cu bit-ul FIN setat pe 1.

2. Server-ul trimite o confirmare (ACK) pentru a instiinta clientul ca a primit cererea de

inchiderea a sesiunii (FIN-un de la client)

3. Server-ul mai trimite si o cerere de inchidere a sesiunii (FIN) clientului.

4. clientul raspunde cu o confirmare (ACK) pentru a instiinta serverul ca a receptionat

cererea de inchiderea sesiunii.

Cand toate segmentele au fost confirmate, sesiunea este inchisa

Este de asemenea posibil ca o sesiune sa se inchida in trei pasi. Cand clientul nu mai are
date de transmis, trimite un segment cu bitul FIN setat pe 1 catre server. Daca server-ul
nu mai are date de transmis, poate raspunde cu amandoi indicatori FIN si SYN setati pe
1, combinand 2 pasi intr-unul singur. Clientul raspunde cu confirmarea ACK.
4.3.1. Reansamblarea segmentelor TCP

Rearanjarea segmentelor la destinatie pentru a respecta ordinea in care au fost

transmise de la sursa

Cand serviciile transmit date folosind TCP, segmentele pot ajunge la destinatie in
dezordine. Pentru ca receptorul sa inteleaga mesajul, datele din aceste segmente sunt
ansamblate in ordinea initiala (de la sursa). Numarul de secventa (sequence number)
este lipit in antetul fiecarui segment pentru a obtine acest rezultat.
In timpul initierii sesiunii, un numar initial de secventa (ISN) este setat. Acest numar initial
de secventa reprezinta valoarea de pornire a octetilor (bytes) ce va fi transmis la aplicatia
destinatie pe parcursul acestei sesiuni. Pe parcursul sesiunii de transmitere, numarul de
secventa (sequence number) este incrementat. Aceasta urmarire a datelor permite ca
fiecare segment sa fie unic identificat si confirmat de destinatie. Segmentele lipsa pot fi
identificate.

Secventa de numar a segmentelor asigura garantarea furnizarii datelor, prin indicarea

ordinii de reansamblare si rearanjarea segmentelor (daca este cazul), asa cum ne
infatiseaza figura de mai jos.

Procesul de receptie TCP stocheaza datele dintr-un segment intr-o memorie de tip
“buffer” . Segmentele sunt stocate in ordine si livrate mai departe stratului Aplicatie dupa
reansamblare. Orice segment receptionat si care nu are numarul de secventa
corespunzator este memorat si retinut pentru o procesare ulterioara. Apoi, cand
segmentele lipsa ajung, aceste sunt procesate si transmise stratului Aplicatie.
4.3.2. Confirmarile si procesul de “windowing” din protocolul TCP

Confirmarea segmentelor receptionate

Una dintre functiile TCP este sa se asigure ca fiecare segment ajunge la destinatie.
Serviciile TCP ce functioneaza la destinatie confirma sursei ca datele au fost
receptionate.

Numarul de secventa si numarul confirmarii sunt folosite impreuna pentru a instiinta sursa
ca datele din segmente au fost receptionate. Numarul de secventa este numarul de
octetii care au fost transmisi in sesiunea actuala + 1 (numarul primului octet de date din
segmentul urmator). TCP foloseste numerele confirmarilor in segmentele trimise inapoi la
sursa pentru a indica urmatorul octet din aceasta sesiune pe care receptorul asteapta
sa-l primeasca. Aceasta confirmare se numeste confirmare asteptata (la care sursa se
astepta) “
The source is informed that the destination has received all bytes in this data stream up
to, but not including, the byte indicated by the acknowledgement number. The sending
host is expected to send a segment that uses a sequence number that is equal to the
acknowledgement number.
Sursa este informata ca destinatia a receptionat toti octetii din fluxul de date (sesiunea
curenta), dar nu si octetul ce indica numarul confirmarii. Transmitatorul asteapta sa
transmita un segment ce foloseste un numar de secventa egal cu numarul de confirmare.
Remember, each connection is actually two one-way sessions. Sequence numbers and
acknowledgement numbers are being exchanged in both directions.
Amintiti-va, fiecare conexiune este formata din doua sesiuni (“cu sens unic”). Numarul
secventei si numarul confirmarii au fost schimbate in ambele sensuri
In the example in the figure, the host on the left is sending data to the host on the right. It
sends a segment containing 10 bytes of data for this session and a sequence number
equal to 1 in the header.
In exemplul din figura de mai jos, gazda din stanga transmite date gazdei din dreapta. Ea
transmite un segment continand 10 octeti (bytes) de date pentru aceasta sesiune si un
numar de secventa egal cu 1 in antet.

Gazda receptoare din dreapta receptioneaza un segment si observa ca numarul de

secventa este 1 si contine 10 octeti de date. Aceeasi gazda trimite un segment inapoi
gazdei din stanga pentru a-i confirma ca a primit datele. In acest segment, seteaza
numarul confirmarii la 11 pentru a indica ca urmatorul octet asteptat este 11. Observati,
valoarea confirmarii ACK la gazda sursa ramane 1 pentru a indica ca segmentul face
parte din conversatia in derulare si numarul confirmarii este valid.

Cand gazda sursa din stanga receptioneaza aceasta confirmare, poate transmite
urmatorul segment din aceasta sesiune incepand cu octetul 11.
Looking at this example, if the sending host had to wait for acknowledgement of the
receipt of each 10 bytes, the network would have a lot of overhead. To reduce the
overhead of these acknowledgements, multiple segments of data can be sent before and
acknowledged with a single TCP message in the opposite direction. This
acknowledgement contains an acknowledgement number based on the total number of
bytes received in the session.
Privind acest exemplu, daca gazda sursa trebuie sa astepte confirmari la fiecare 10 octeti
transmisi, reteaua va fi incarcata cu aceste confirmari. Pentru a reduce aceste incarcari
suplimentare cu confirmari, se pot transmite mai multe segmente de date si pentru toate
sa se transmita un singur numar de confirmare in antetul unui singur segment TCP, in
directia opusa. Aceast numar de confirmare este numarul total de octeti primiti in
sesiunea respectiva.

De exemplu, pornind cu numarul de secventa 2000, daca 10 segmente de 1000 de octeti

sunt receptionati, numarul 12000 de confirmare va fi returnat sursei.

Cantitatea de date pe care o poate transmite o sursa inainte de a primi confirmarea este
numita dimensiunea fereastrei. Dimesiunea ferestrei este scrisa intr-un camp din antetul
TCP, ea asigura gestionarea datelor pierdute si controlul fluxului.
4.3.3. Retransmisia datelor

Gestionarea segmentelor nereceptionate

Oricat de bine ar fi proiectata o retea, pierderea de date va aparea inevitabil. De aceea

TCP are o metoda de gestionare a segmentelor pierdute. Aceasta metoda consta in
retransmiterea datelor pentru care nu au fost primite confirmari.

De obicei, serviciile gazdei destinatie ce folosesc protocolul TCP, confirma numai datele
care au secventa de octeti continua. Daca unul sau mai multe segmente lipsesc, numai
segmentele receptionate cu date complete sunt confirmate.

De exemplu, daca segmentele cu numarul secventei de la 1500 la 3000 si 3400 la 3500

au fost receptionate, numarul confirmarii va fi 3001. Aceasta se intampla deoarece
segmentele cu secventa de numar cuprinse intre 3001 si 3399 nu au fost receptionate.

Cand protocolul TCP de la gazda sursa nu primeste o confirmare, intr-un timp predefinit,
va analiza ultimul numar de confirmare primit si va retransmite din acel punct (de la acel
ultim octet confirmat).

Pentru o impementare standard TCP, o gazda poate transmite un segment, poate retine
o copie a acelui segment intr-o coada de asteptare (buffer) si sa porneasca un timer
(perioada de timp in care acel segment poate stationa in memorie). Cand confirmarile
sunt receptionate, segmentele sunt sterse din memorie. Daca confirmarea nu este primita
inainte ca timpul specificat sa expire, segmentul este retransmis.
Gazdele din zilele noastre pot dispune de functionalitatea numita confirmare selectiva
(selective acknoledgement), este posibil ca destinatia sa transmita confirmarea pentru
segmente discontinue iar sursa sa fie nevoita sa transmita doar segmentele lipsa.

4.3.4.1. Controlul congestiilor TCP – micsorarea numarului de segmente pierdute

Controlul fluxului de date

Protocolul TCP furnizeaza, de asemenea, un mecanism de control al fluxului. Controlul

fluxului ajuta la garantarea transportului de date modificand efectiv cantitatea de date ce
circula intre seviciile sursa si destinatar implicate in sesiune. Cand susrsa este instiintata
ca o cantitate de date a fost receptionata, poate transmite restul datelor continute in
aceasta sesiune.

Aceasta capacitate a ferestrei specificata in antetul segmentului TCP, ne precizeaza

cantitatea de date ce pot fi transmise inainte de a primi confirmari. Capacitate/dimesiunea
ferestrei initiale este stabilita in timpul initierii sesiunii in trei pasi (three-way handshake)

Mecanismul de stabilire a cantitatii de date, ajusteaza rata efectiva de transmisie a

datelor la rata maxima permisa de retea (tipul retelei) si la rata de receptie suportata de
destinatie.

Observati in figura de mai jos o reprezentare simplificata a dimensiunii ferestrei si

confirmarilor. In acest exemplu, dimesiunea ferestrei pentru o sesiune TCP este setata la
3000 de octeti. Dupa ce transmitatorul a transmis 3000 de octeti, asteapta o confirmare
inainte de a transmite alte segmente apartinand acestei sesiuni.

Dupa primirea confirmarii transmitatorul, poate transmite urmatorii 3000 de octeti.

Atat timp cat asteapta confirmarea, transmitatorul nu va transmite nici un segment in plus
pentru aceasta sesiune. In perioada cand reteaua este congestionata sau resursele
gazdei receptoare sunt suprasolicitate, intarzierile pot creste. O data cu cresterea
intarzierilor, rata efectiva de transmisie din aceasta sesiune va scadea. Incetinirea ratei
de transmisie ajuta la reducerea problemei ridicata de resurse.
4.3.4.1. Controlul congestiilor TCP – micsorarea numarului de segmente pierdute

Reducerea dimensiunii ferestrei

Un alt mod de control al fluxului de date este utilizarea ferestrelor cu lungime variabila
alocata dinamic. Cand resursele sunt suprasolicitate, TCP poate reduce dimensiunea
ferestrei pentru a cere ca segmentele receptionate sa fie confirmate mai des. Aceasta
reduce efectiv rata de transmisie deoarece sursa asteapta confirmari mai des.

Gazda receptoare trimite dimensiunea ferestrei transmitatorului pentru a indica numarul

de octeti pe care este pregatita sa-l receptioneze ca parte a acestei sesiuni. Daca
destinatia trebuie sa micsoreze rata comunicarii din cauza memoriei buffer insuficiente,
ea poate transmite sursei o valoare mai mica a “ferestrei” in cadrul unei confirmari.

Asa cum reiese din figura, daca o gazda receptoare este supraincarcata(congestionata),
poate trimite transmitatorului un segmet prin care cere reducerea ferestrei. In figura de
mai jos, s-a pierdut un segment. Receptorul modifica valoarea dimensiunii ferestrei in
segmentul raspuns catre sursa, de la 3000 la 1500 (micsoreaza fereastra). Aceasta va
face ca transmitatorul sa-si micsoreze fereastra la 1500 octeti.

Dupa o perioada de transmisie fara date pierdute sau supraincarcari de resurse,

receptorul va creste dimensiunea ferestrei. Aceasta va reduce traficul in retea datorita
numarului micsorat de confirmari. Dimensiunea ferestrei va continua sa creasca pana
cand vor aparea pierderile de date, ceea ce va duce la, binenteles, micsorarea ferestrei.

Aceasta modificare dinamica a ferestrei (crestere/micsorare) este un proces permanent

in TCP, proces ce determina dimensiunea optima a ferestrei pentru fiecare sesiune TCP.
In retele cu eficienta mare, dimensiunea ferestrei poate deveni foarte mare datorita
faptului ca nu se pierd date. In retelele in care infrastructura inferioara este
supraincarcata, dimensiunea ferestrei va ramane mica.

4.4.1. Trafic redus (UDP) in comparatie cu garantarea datelor (TCP)

Protocolul Datagramei Utilizator UDP (User Datagram Protocol) este un protocol simplu
ce asigura functiile de baza ale stratului Transport. Produce mai putin trafic suplimentar,
deoarece nu este un protocol orientat pe conexiune (connection-oriented) si nu asigura
mecanismul complex de retransmisie, secventionare si controlul fluxului.

Aceasta nu inseamna ca aplicatiile ce folosesc UDP sunt intotdeauna negarantate.

Inseamna pur si simplu ca garantarea nu este asigurata de protocolul UDP din stratul
Transport si ca aceasta garantare va fi implementata altundeva (la nivelul unui strat
superior), daca este necesar.

Chiar daca procentul UDP din totalul traficului in retelele obisnuite este relativ scazut,
protocoale importante ale stratului Aplicatie folosesc acest protocol, de exemplu:
Sistemul numelor de domenii (DNS);
Protocolul simplu de gestionare a retelei (SNMP);
Protocolul de configurare dinamica a host-urilor (DHCP);
Protocolul de rutare a informatiilor (RIP);
Protocolul de transfer al fisierelor (TFTP);
Jocuri in retea;

Unele aplicatii, cum ar fi jocurile in retea sau VOiP, pot tolera unele pierderi de date.
Daca aceste date ar folosi TCP, s-ar putea confrunta cu intarzieri mari datorita
mecanismului de detectare a pierderilor si retransmiterii datelor. Aceste intarzieri pot
afecta mai mult aplicatiile decat pierderile mici de date. Unele aplicatii, cum ar fi DNS, vor
retrimite cererea, daca nu primesc raspuns, la cererea initiala, de aceea ele nu au nevoie
de GARANTAREA TCP.

Scaderea traficului suplimentar si a intarzierilor aferente face ca protocolul UDP sa fie cel
mai oportun pentru aceste aplicatii.

4.4.2. Reasamblarea datelor UDP

Deoarece UDP nu este un protocol orientat pe conexiune, sesiunile nu se stabilesc

inainte de comunicate, cum se intampla la TCP. Se spune ca UDP este bazat pe
tranzactii. Cu alte cuvinte, cand o aplicatie are date de transmis, transmite datele pur si
simplu.

Multe aplicatii care folosesc protocolul UDP trimit date de dimensiune mica ce pot fi
incadrate intr-un segment. Alte aplicatii vor dori sa transmita date care trebuiesc
fragmentate in mai multe segmente. Unitatatea de informatie a protocolului UDP este
numita si “datagrama” chiar daca acest termen este interschimbabil cu numele de
“segment”, care se refera la unitatea de informatie TCP.

Cand mai multe datagrame sunt transmise la o destinatie, ele pot “circula” pe diverse cai
(path) si din acest motiv sa ajunga in dezordine la destinar. UDP nu urmareste numarul
de secventa al segmentelor asa cum face TCP. UDP nu are un mecanism de rearanjare
a datelor in ordinea stabilita de transmitator, Vezi figura.
De aceea, UDP reansambleaza datele in ordinea in care au sosit si le transmite mai
departe aplicatiei. Daca secventa datelor este importanta pentru aplicatie, aplicatia va
trebui sa identifice ordinea datelor si cum vor fi procesate.
4.4.3. Cererile si procesele server UDP

Ca si aplicatiile bazate pe TCP, aplicatiile server bazate pe UDP sunt asociate porturilor
binecunoscute(0-1023). Cand aceste aplicatii sau procese sunt in functiune, vor accepta
date ce se adreseaza acelor porturi pentru a le transmite mai departe aplicatiilor.

4.4.4.1. Procesele client UDP

Ca si in cazul TCP, comunicatiia UDP client/server este initiata de o aplicatie client ce

cere date de la procesul server. Procesul client UDP aloca aleator un numar de port
pentru conversatia respectiva. Portul destinatie va fi un port standard (0-1023).

Portul sursa alocat aleator ajuta de asemenea la securitatea datelor. Daca ar exista un
tipar previzibil in ceea ce priveste portul sursa, un intrus poate simula cu usurinta accesul
(de pe acel port sursa) la un client prin incercarea de a se conecta la un port presupus
deschis.

Din cauza faptului ca UDP nu are nevoie sa creeze sesiuni inainte de a transmite, de
indata ce datele sunt pregatite de transmisie si portul identificat, UDP formeaza
datagrama si o transmite stratului Retea pentru adresare si transmitere in retea.

Odata ce un clien a ales porturile sursa si destinatie, aceeasi pereche de porturi este
folosita in toate antetele datagramelor din tranzactia respectiva. Pentru datele ce se
intorc de la server la client, porturile sursa si destinatie din antet sunt inversate.