Reţele de Calculatoarestst.elia.pub.ro/news/RC/Teme_RC_IVA_2014_15/1_VicaDaCa_SipicaAl… · model...

Universitatea Politehnică Bucureşti

Facultatea de Electronică, Telecomunicaţii şi Tehnologia Informaţiei

Reţele de Calculatoare

“Realizarea comunicării în reţea

prin mecanismele din Nivelul de Transport (modelul TCP/IP)”

Profesor coordonator: prof. univ. dr. ing. Ştefan Stăncescu

Studenţi: Vică Daniel-Cătălin, Sipică Alin-Marian

Grupa: 441A (CTI)

Anul universitar

2014-2015


REALIZAREA COMUNICARII IN RETEA PRIN MECANISMELE DIN NIVELUL DE TRANSPORT (MODELUL TCP/IP)

1

CUPRINS

1 Introducere

1.1 Notiuni introductive despre modelul TCP/IP (Sipica Alin-Marian) ........................... 2

1.2 Notiuni avansate despre modelului TCP/IP (Sipica Alin-Marian) ............................. 4

1.3 Nivelele modelului TCP/IP (Vica Daniel-Catalin) ..................................................... 6

1.4 Compararea dintre modelului TCP/IP si modelul OSI (Vica Daniel-Catalin) .......... 10

2 Nivelul de Transport (Transport Layer)

2.1 Principii de functionare si notiuni avansate (Sipica Alin-Marian) ............................ 12

2.2 Protocoale proeminente ale Nivelului de Transport (Vica Daniel-Catalin) .............. 14

2.2.1 Probleme rezoltate de catre protocolul TCP (Vica Daniel-Catalin) ........ 15

2.2.2 Probleme rezoltate de catre protocolul UDP (Sipica Alin-Marian) ......... 18

2.2.3 Probleme rezoltate de catre protocolul RSVP (Vica Daniel-Catalin) ..... 19

2.2.4 Probleme rezoltate de catre protocolul DCCP (Vica Daniel-Catalin) ..... 20

2.2.5 Probleme rezoltate de catre protocolul SCTP (Sipica Alin-Marian) ....... 20

3 Concluzii (Sipica Alin-Marian) ............................................................................................. 22

4 Bibliografie ............................................................................................................................ 23



2

INTRODUCERE

1.1 Notiuni introductive despre modelul TCP/IP

Putem defini pe scurt modelul TCP/IP, cunoscut si sub numele de „Internet Protocol

Suite” (tradus oarecum „Suita de Protocoale ale Internetului”) sau „DoD Model” (datorita

primului prototip ce a fost finantat de catre „DARPA”, o agentie cu responsabila cu asigurarea

securitatii in orice domeniu, apartinand de „United States Deparment of Defense”), ca fiind un

model de referinta pe baza caruia se construiesc arhitecturile de retea, cuprinzand protocoale ce

ajuta la comunicarea dintre terminalele acesteia. Insa, pentru a putea intelege cu adevarat scopul

unui model TCP/IP si influenta acestuia asupra telecomunicatiei, este necesar a defini mai intai

notiunea de „protocol” si „retea” (in engleza tradusa drept „network”).

Inainte de toate, se impune definirea viitorului si mult utilizatului termen in cadrul acestei

lucrari, cel de „comunicare”. Atunci cand facem referire la „comunicare”, putem afirma faptul ca

aceasta se realizeaza prin viu grai intre un emitator si receptor uman, printr-un canal de

transmisiune, ceea ce poate fi transpus in termeni de retelistica prin faptul ca doua terminale

comunica intre ele prin intermediul unei retele (canal de transmisiune), realizand un transport de

date/informatii. Deci, asemeni oamenilor ce utilizeaza cuvintele pentru a transmite o informatie,

terminalele „transporta” intre ele pachete de date, cu un anumit scop prestabilit de catre utilizator

(o vedere de ansamblu asupra comunicarii si transportului).

Astfel, putem defini o retea ca fiind o metoda de comunicare intre terminale si/sau

servere, ce implica atat o parte fizica numita „topologie”, alcatuita din fire (fibra optica, de

exemplu) si componente caracteristice (routere, hub-uri etc.), cat si o parte abstracta, formata din

reguli de transport, comunicare, inter-schimbare de resurse, ce constituie practic mecanismul

central care asigura buna functionare mult dorita de catre proiectant. Drept urmare, putem afirma

faptul ca doua sau mai multe terminale (termen utilizat in cadrul acestei lucrari cu scopul de a

face referire la orice aparat care se poate conecta la o retea, cum ar fi un computer, telefon mobil,

laptop, servere etc), interconectate printr-o metoda prestabilita ce prezinta reguli de comun acord

pe baza carora se efectueaza un schimb de date, se afla „intr-o retea” (notiune ce urmeaza a fi

dezoltata in capitolele viitoare ale lucrarii de fata). De asemenea, pe baza ideii ca reteaua poate fi

vazuta precum un „canal de comunicare” s-au dezvoltat diverse mecanisme elaborate, precum

accesul la „World Wide Web”, actionarea unui printer prin transmisiunea wireless, utilizarea

aplicatiilor de tip „e-mail” (tradus oarecum drept „posta electronica”) sau mesagerie instantanee

(programul „Yahoo Messenger”, de pilda), fapt ce a condus umanitatea cu un pas mai aproape de

modernizare si progres. [1]

Avand o idee generala asupra modului de functionare teoretic al retelei, ne putem atinti

privirea catre notiunea de „protocol”, mentionata in paragraful anterior. Un protocol poate fi

vazut drept un set de reguli ce serveste un scop bine definit, precum transportul datelor,

verificarea la receptie a acestora, asigurarea calitatii prin reducerea zgomotului la reconstructia



3

semnalului etc. . Drept urmare, un protocol poate fi atat o implementare de tip hardware, cat si

software, fiind mai mult o notiune abstracta ce impune anumiti parametrii, precum necesitatea

unei sintaxe si sincronizarea comunicarii dintre cele doua terminale, fiind la fel de esentiale

pentru retele asa cum sunt limbajele de programare pentru compilatoare.

(Ilustrarea conceptului de „retea” discutat anterior)

(http://www.conceptdraw.com/How-To-Guide/picture/Computer-network-system-design-diagram.png)

Cunoscand la nivel conceptual termenii de „retea” si „protocol”, putem incerca o definitie

mai academica asupra modelului TCP/IP, si anume ca, reprezinta un sablon alcatuit din patru

nivele, fiecare avand un set de reguli (protocoale) cu scop bine stabilit, pe baza caruia se poate

intocmi un canal de transmisiune a datelor intre terminale (retea), atat la nivel fizic prin

componente caracteristice domeniului, cat si la nivel abstract, prin modelarea unor proceduri

complexe ce au la baza protocoalele mentionate. Trebuie precizat faptul ca, modelul conceptual

TCP/IP nu prezinta o stransa legatura cu topologia retelei, insa se impune o oarecare analiza is

asupra acesteia daca dorim a asigura un canal de transmisiune „error proof”, de pilda (tradus ca

„fara erori), ramanand in sarcina proiectantului de a gasi o punta de mijloc, optima, intre

componentele utilizate si procedurile formate. [2]

Trebuie mentionat faptul ca modelul TCP/IP, alaturi de protocoalele aferente acestuia, a

fost conceput in concordanta cu normele inpuse de catre organizatia „Internet Engineering Task

Force – IETF”, ce au ca scop stabilirea unor standarde internationale de comunicare atat intre

terminale, cat si intre retele (pot exista retele ce intercomunica, la un nivel super-scalar, cum este

spre exemplu, internetul zilelor noastre). Componentele fizice care asigura buna functionare a

retelei pot fi inctocmite dupa mai multe standarde, precum „Cisco Systems Incorporated –

CISCO” sau „Institute of Electrical and Electronics Engineering – IEEE”. [2]



4

In subcapitolul ce urmeaza, vom discuta in ansamblu despre notiuni avansate cu privire la

modelul TCP/IP, explicand mecanismele din spatele functionarii acestuia si ilustrand totodata

necesitatea impartirii acestuia in patru nivele bine definite.

1.2 Notiuni avansate despre modelului TCP/IP

In subcapitolul anterior am discutat despre modelul TCP/IP din punct de vedere

principial, punand astfel bazele cunostiintelor ce ne vor servi in continuarea lucrarii. Avand de

partea noastra principiile functionarii mecanismului din spatele acestui model, putem incepe

discutii mai aprofundate folosind termeni caracteristici domeniului.

Modelul TCP/IP si-a capatat denumirea datorita celor mai importante doua protocoale ale

sale, si anume, „Transmission Control Protocol” (abreviat „TCP”) ce se afla pe Nivelul de

Transport, asigurand o comunicare bazata pe octeti, fara erori, intre terminalele retelei, si

„Internet Protocol” (abreviat „IP”) aflat pe Nivelul de Internet, cu scop in rutarea cailor dintre

participantii retelei. De asemenea, trebuie mentionat faptul ca aceste doua protocoale au fost

printre primele standardizate de catre asociatia IETF, mecanismul din spatele acestora servind si

in dezvoltarea altor modele de retea. [3]

Precum sistemele de calcul, modelul TCP/IP trebuia sa dispuna de o arhitectura ce urma a

fi utilizata drept referinta in conceperea altor modele de retea. Astfel, analizand documentatia

sub numele de „RFC 1122” publicata de catre IETF, putem descoperi faptul ca TCP/IP este

alcatuit din patru nivele principale, fiecare cu protocoalele sale aferente, totodata fiind construit

pe baza a doua principii foarte importante. Cel dintai se numeste „end-to-end principle”, elaborat

in 1981 de catre Saltzer Reed, care desi a fost schimbat de nenumarate ori de la aparitia sa,

mecanismul din spate a ramas acelasi, exprimand ideea ca functiile specifice aplicatiilor ar trebui

sa existe in terminalele de la capatele retelelor (denumite adesea si „end hosts”), decat in

nodurile intermediare, astfel reducand costurile productiei (spre exemplu, daca un router ar

dispune de aceste functii, tot ar fi necesara implementarea lor si asupra terminalelor ce

comunicau intre ele), asigurand si un transport al informatiei mai apropiat de notiunile „complet”

si „corect”. Retelele zilelor noastre inca pastreaza acest principiu, insa modificat datorita

necesitatii utilizarii unui firewall, translatarea adreselor din retea si aparitia continutului web

stocat sub forma de cache (precum memoria „cache” a procesorului). Cel de-al doilea principiu,

„robustness principle” (cunoscut si sub numele de „Legea lui Postel” datorita pionierului

internetului, Jon Postel), impune ideea de a fi conservativ in ceea ce trimite, insa liberal in ceea

ce se primeste. Cu alte cuvinte, implementarea TCP impune terminalelor de a fi foarte stricte si

concise in codul elaborat spre transmitere, insa mecanismul de la receptia acestora sa permita

citirea unui sir de octeti atata timp cat intelesul mesajului este clar. [3]

Avand aceste doua principii in minte, ne aflam cu un pas mai aproape de intelegerea

totala a modelului TCP/IP, insa mai sunt si alte mecanisme importante, ce trebuie luate in seama.



5

De pilda, datorita celor 4 nivele, transmiterea datelor se realizeaza in urma unui proces de

„incalsulare” (tradus in engleza drept „encapsulation”).

(Nivelele modelului TCP/IP alaturi de cele mai importante protocoale aferente)

(https://i-technet.sec.s-msft.com/dynimg/IC197700.gif)

Asemeni unui continut intr-o cutiuta, ce se afla la randul ei intr-o cutie mai mare si asa

mai departe (ne putem referi la papusile rusesti „matrioska” pentru o mai buna reprezentare),

incapsularea presupune utilizarea notiunii de abstractizare a protocoalelor pentru a realiza o

transmisiune de date intre doua terminale. Astfel, plecand de la doua procese aflate pe Nivelul de

Aplicatie (cel mai intal nivel) ce intercomunica, vrand sa transmita un pachet de date, putem

observa ca, pe masura ce parcurgem modelul TCP/IP in adancime (spre ultimul nivel, cel de

legatura), respectivul sir de octeti din pachet este „incapsulat”, adaugandu-i-se alte string-uri, ce

il ajuta in a fi trimis si receptionat cu succes. Pentru o mai buna analogie, ne putem gandi la

pachetul de date drept o scrisoare, care, pentru a putea ajunge la destinatar, trebuie sa fie pusa

intr-un plic, apoi sa i se lipeasca un trimbru, iar ulterior, sa fie pusa intr-o cutie postala.

(Reprezentare concreta a incalsularii datelor pe nivele)

(http://upload.wikimedia.org/wikipedia/commons/3/3b/UDP_encapsulation.svg)

Trebuie mentionat faptul ca, aceasta metoda de incapsulare a informatiei ajutat atat in

buna realizare a transmisiunii (error-proof, de exemplu), fiecare protocol avand cate un rol

prestabilit, insa totodata este foarte eficient deoarece imparte o sarcina in bucati de dimensiune



6

redusa, ceea ce este o consecinta in viteza (un protocol ce asigura transmiterea fara erori si unul

ce face rutarea sunt mai eficiente decat un singur protocol caruia i se impun ambele task-uri).

Pe masura ce nivele sunt parcurse, de la cel superior de Aplicatie spre cel inferior de

Legatura, putem afirma faptul ca exista o tranzitie de la un nivel de tip logic, mai apropiat de

caracteristicile unei aplicatii, spre un nivel de tip fizic, ce are legatura mai mult cu transmiterea

datelor (trecem de la o comunicare logica prin biti de 0 si 1 la una de tip fizic, ce ilustreaza

transmiterea efectiva a impulsurilor electrice prin componentele aferente retelei). Putem observa

acest lucru mai bine, folosindu-ne de diagrama de mai jos.

(Diagrama explicativa ce ilustreaza transmiterea datelor pe nivele) (http://upload.wikimedia.org/wikipedia/commons/c/c4/IP_stack_connections.svg)

Cunoscand principiile de baza din spatele mecanismelor centrale de functionare ale

modelului TCP/IP, putem discuta in continuare despre nivelele acestuia, mentionand scopul fi

protocoalele aferente fiecaruia.

1.3 Nivele modelului TCP/IP

Dupa cum am discutat pana in momentul actual, modelul TCP/IP este impartit in patru

nivele, fiecare cu protocoale aferente, cu scopul diminuarii concentrarii sarcinilor si a realizarii



7

corecte a transmiterii de date. Astfel, documentul „RFC 1122” [4] despre care am mentionat si in

capitolele anterioare, ne prezinta structura modelului TCP/IP dupa cum urmeaza:

1) Nivelul de Aplicatie („Application Layer”): este nivelul unde aplicatiile creaza date ce

pot fi folosite de catre utilizatori cu scopul transmiterii acesteia spre alte aplicatii din

cadrul aceleiasi retele sau aceluiasi terminal. Partenerii intre care se realizeaza transferul

sunt caracterizati de catre arhitectura aplicatiei in cauza, putand fi de tipul „client-server

model” (principiu bazat pe un program de distribuire si partitionare a resurselor unui

distribuitor, pe baza cererilor emise de catre terminale) sau „peer-to-peer” (mecanism ce

ilustreaza partajarea sarcinilor si resurselor intre nodurile retelei, fara a fi necesar un

sistem central de administrare a acestora). Astfel, putem deduce faptul ca, acest nivel

utilizeaza protocoale ce servesc in asigurarea serviciilor fata de utilizatori si realizarea

schimbarii de date intr-o retea descrisa fizic de nivelele inferioare. Drept exemple de

protcoale caracteristice acestui layer avem „Hypertext Transfer Protocol” (abreviat

„HTTP”), cu scop in distribuirea informatiei de tip „hypermedia” (ceva mai mult decat

siruri de biti, discutand despre poze, fisiere audio etc.) cu ajutorul „hypertext-ului” (text

structurat ce ne arata legaturile logice dintre nodurile unei retea), „Dynamic Host

Configuration Protocol” (prescurtat „DHCP”), ce are ca rol distribuirea dinamica a

parametrilor unei retea, precum adresele IP, eliminand astfel necesitatea unui sistem de

tipul „administrator” sau configurarea manuala a acestuia, „File Transfer Protocol”

(„FTP”), ce asigura transmiterea datelor intre participantii comunicarii printr-o retea ce

foloseste protocolul „TCP” („Transmission Control Protocol”, va fi discutat mai in

ansamblu in capitolele viitoare), sau „Simple Mail Protocol” („SMP”), care face posibila

utilizarea bine cunoscutei aplicatii de „posta electronica”. Trebuie specificat faptul ca

protocoalele acestui nivel trateaza layer-ele inferioare drept „black boxes” ce asigura un

canal de transmisiune stabil, chiar daca aplicatiile in cauza sunt constiente de anumiti

parametrii, precum numerotarea porturilor spre exemplu. Pachetele de date sunt

incapsulate, protocoalele nivelelor inferioare neprezentand niciun interes fata de acesta.

(Modelul “client-to-client”) (Modelul “peer-to-peer”) (http://upload.wikimedia.org/wikipedia/commons/c/c9/Client-server-model.svg)

(http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/P2P-network.svg/200px-P2P-network.svg.png)



8

2) Nivelul de Transport („Transportation Layer”): nivelul ce asigura transportul

pachetelor de informatie intre terminalele gazda ale retelei. Acesta asigura o conectivitate

„process-to-process”, insemnand totodata ca realizeaza servicii „end-to-end”

independente de structura datelor sau a scopului transmisiunii acestora, insa dispunand de

caracteristici precum segmentarea mesajului, controlul transmisiunii sirurilor de biti

(eliminand crearea unei congestii de date pe magistrala de transmisie), adresarea catre

porturile cerute si controlul erorii. Atunci cand vorbim despre transport de tip „end-to-

end”, acesta poate fi categorisit drept „connection-oriented”, implementat in protocolul

„Transmission Control Protocol”, ce face referire la o sesiune de comunicare permanenta

sau semi-permanenta stabilita inaintea transmiterii de date (sirul de biti este primit asa

cum a fost trimis), sau drept „connectionless”, find o metoda care impune transportul

fiecarei bucati din pachetul de date in functie de continutul sau (implementata cu

protocolul „User Datagram Protocol”). Mecanismul „connection-oriented transport” ajuta

la asigurarea unui transport eficient de date, insa viteza redusa prezinta un deficit major,

compensat de catre metoda „connectionless”, ce are aplicabilitate in domenii precum

Voice Over IP Communications sau streaming-ul de fisiere video/audio. Astfel, in

proiectarea unei retele, scopul defineste mecanismul utilizat din cadrul nivelului de

transport. Cand ne referim la transport, dorim ca reteaua noastra sa asigure un randament

cat mai ridicat al datelor transmise cu succes, astfel protocoalele aferente Nivelului de

Transport trebuie sa fie de incredere (spre exemplu, protocolul TCP asigura

transmisiunea informatiei in ordine, prezinta rata de eroare minimala, datele duplicate

sunt ignorate, etc.). [2]

(Transmisiunea prin protocoalele TCP si UDP)

(https://blog.logentries.com/wp-content/uploads/2014/07/tcp-versus-udp.jpg)



9

3) Nivelul de Internet („Internet Layer”): acest nivel are sarcina de a realiza un schimb

de datagrame in afara retelei locale, dispunand de o interfata uniforma ce ascunde

topologia fizica. Practic, defineste modul de adresare si rutarea traseelor, parametrii

folositi de catre nivelul superior de transport (termenul de „rutare” sau „routing” in

engleza reprezinta transmiterea pachetului de date de-a lungul mai multor retele, pana la

destinatie, de obicei urmarindu-se traseul cel mai optim). Cel mai proeminent protocol

este „Internet Protocol” (abreviat „IP”), ce serveste atat ca identificator al emitatorului,

prin adresa IP, cat si alegerea unui traseu cat mai scurt dintre reteaua de care apartine

terminalul expeditor, catre reteaua terminalului destinatar. „Internet Protocol-ul”

indeplineste sarcini pentru diferite protocoale din nivele superioare, identificandu-le prin

atribuirea unui numar unic fiecaruia (spre exemplu, „Internet Control Message Protocol”

are numarul 1, pe cand „Internet Group Management Protocol” este notat ca 2). Dupa

cum am mentionat anterior, una din functiile acestui protocol este atribuirea unei adrese

pe 32 de biti fiecarui terminal pentru a putea fi identificat, sub forma a patru diviziuni de

cate maxim trei cifre (exemplu: „172.16.254.1”), astfel putand exista aproximativ patru

miliarde de adrese diferite. [2]

(Exemplificare de adresa IP)

(http://cs.stanford.edu/people/eroberts/cs181/projects/2010-11/FreedomOfInformationChina/wp-

content/uploads/2011/05/ip_address_structure1.gif)

4) Nivelul de Legatura („Link Layer”): este cel mai inferior nivel al modelului TCP/IP,

ce asigura o buna conexiune la nivel fizic intre terminale, totodata avand protocoale ce

descriu mai mult conectivitatea la un nivel mai rudimentar (descompunerea semnalului,

transmisiunea acestuia prin fire etc.). Trebuie sa avem in minte faptul ca modelul din

lucrarea de fata este independent de implementarea hardware, asadar o configuratie pe

Nivelul de Legatura poate fi aplicat oricaror componente ce alcatuiesc o retea. Procesul

transmiterii unui pachet de date, examinat la acest layer, poate fi controlat software sau

hardware prin „firmwares” (programe scrise special pentru un anumit tip de procesor de



10

semnal) sau „chipsets” (SoC – „System on Chip”), atasand un header special inainte de a

trimite in mediul fizic (de pilda, protocolul „MAC – Media Access Control” ce arata

accesul la canalul de comunicare si modul de adresare al datelor acceptate, astfel

impunand un mediu comun de transfer intre terminale). De asemenea, un atribut

important il constituie si protocoalele de tip „tunneling”, ce ofera o compatibilitate intre

doua retele sau terminale ce nu utilizeaza acelasi tip de protocol (spre exemplu,

comunicarea dintre o retea cu IPv6 si una cu IPv4). [2]

1.4 Compararea dintre modelului TCP/IP si modelul OSI

In domeniul calculatoarelor si al informatiei exista mai multe modele pe baza carora se

poate proiecta arhitectura unei retele, insa cele mai intalnite sunt OSI si TCP/IP. Despre cel din

urma am discutat pana in momentul actual, asadar se cuvine sa ne atintim privirile pret de o clipa

si asupra „rivalului” sau.

Modelul OSI reprezinta un sablon conceptual de interconectare a terminalelor in retea, ce

tinde sa asigure toate beneficiile mentionate anterior la TCP/IP (comunicare prin transport de

date, canal de transmisiune cu o rata a erorii scazuta etc.). Denumirea provine de la acronimul

„Open Systems Interconnection” ce a fost un proiect initiat de catre „Internation Organization for

Standardization” in scopul obtinerii unui model teoretic pe baza caruia se pot proiecta retelele de

calculatoare. Insa, in zilele noastre, desi ambele modele prezinta acelasi mecanism de

functionare pe baza protocoalelor clasificate in nivele bine definite, OSI este preferat in

dezvoltarea standardelor de comunicatie, cercetare in domeniul hardware al retelisticii si analiza

conceptuala pentru o imbunatatire constanta, pe cand TCP/IP a demonstrat o aplicabilitate mult

mai mare in lumea reala datorita protocoalelor sale caracteristice. [5]

Dupa cum se poate observa in

schema alaturata, prima deosebire il

reprezinta numarul nivelelor, OSI

avand sapte, iar TCP/IP 4, insa

principial, indeplinind aceleasi functii,

prin protocoale oarecum diferite. De

asemenea, la categoria „deosebiri”

putem include si faptul ca modelul

TCP/IP utilizeaza protocolul UDP

discutat anterior, ce nu garanteaza

mereu transmiterea informatiei, precum

Nivelul de Transport al modelului OSI.

O alta deosebire signifianta consta in

Prezentare6

Sesiune5

Transport4

Reţea3

Legătură de date2

Aplicaţie7

Fizic1

Aplicaţie

4

Transport3

Internet2

Acces reţea1

OSI TCP/IP



11

faptul ca primele trei nivele ale modelului OSI au fost compresate intr-unul singur la TCP/IP,

indeplinind functiile necesare stabilirii unei conexiuni in retea (cele trei nivele OSI prezentau

mult mai multe protocoale ce probabil ar fi ingreunat procesult de transmisie in viata reala, astfel

TCP/IP construindu-se doar pe baza a ceea ce a fost necesar si nimic in plus). Aceeasi deosebire

o putem observa si in cazul ultimelor nivele, unde modelul TCP/IP a adoptat ideea contopirii

celui „Fizic” cu cel de „Legatura de date” deoarece specialistiilor li s-a parut mult mai util in

cazurile practice, avand aceleasi intrebuintari si atribute.

Oricat de diferite ar parea cele doua modele la prima vedere, trebuie mentionat faptul ca

ambele functioneaza prin mecanismul de „packet switching” ce are la baza protocoale

asemanatoare ca scop. Asadar, in sarcina proiectarii unei retele, un inginer ar trebui sa aiba cu

sine modelul ISO drept referinta teoretica deoarece dispune de o plaja mai ampla a posibilitatilor,

insa ar trebui sa foloseasca modelul TCP/IP in cazul practic, datorita flexibilitatii si fiabilitatii

sale.



12

NIVELUL DE TRANSPORT (TRANSPORT LAYER)

2.1 Principii de functionare si notiuni avansate

In prima parte a acestei lucrari ne-am axat asupra modelului TCP/IP, explicand

mecanismele generale si principiile din spatele sau, acumuland cunostiinte ce ne vor permite in

continuare sa ne concentram atentia doar asupra Nivelului de Tranport (se va folosi si termenul

din limba engleza, „Transport Layer” pentru evitarea repetitarii exhaustive a denumire in limba

romana). Dupa cum ne-am lamurit pana in momentul actual, transportul este una din

caracteristicile esentiale si necesare ale unei retele, fiind metoda prin care terminalele

participante pot face schimb de informatii (pot „comunica”). Asadar, putem afirma faptul ca

Transport Layer-ul are una dintre cele mai dificile si importante sarcini cand vine vorba de

comunicare, desi in ierarhia nivelelor se afla pe locul al doilea in modelul TCP/IP si pe locul al

patrulea la OSI.

Nivelul de Transport functioneaza pe baza aceluiasi principiu ilustrat mai sus, si anume,

prin utilizarea de protocoale, continand unul dintre cele mai utilizate: „Transmission Control

Protocol” (TCP) ce actioneaza sub principiul „connection-oriented transmissions” (o sesiune de

comunicare permanenta sau semi-permanenta stabilita intre terminale inaintea inceperii

transportului, sirul de biti fiind trimis precum receptionat, nemodificat). Totodata, trebuie

mentionat faptul ca suita de protocoale despre care discutam in aceasta lucrare si-a capatat

numele pe baza acestui protocol (TCP) si a celui din Nivelul de Internet (protocolul IP),

devenind astfel „modelul TCP/IP”. [6]

Cercetatorii ce au avut ca scop proiectarea acestui nivel, pe langa modelul de referinta

OSI, au avut in vedere si serviciile de care va dispune, vrand sa imbunatateasca transportul

pachetelor de date intre terminale (teoretic, comunicarea este doar o „mutare” de biti intre

experditor si destinatar, insa practic, este un proces mult mai complex, fiind necesare masuri de

precautie in vederea aparitiei problemelor precum aglomerarea canalului de transmisie, spre

exemplu). Aceste servicii sunt conectate direct cu Nivelul de Tranrport cu ajutorul unei aplicatii

ce dispune de o interfata programabile, astfel permitand specialistului sa editeze diversi

parametrii:

a) Serviciul de comunicare orientata dupa conexiune („connection-oriented

communication”): exprima ideea discutata si in capitolele anterioare, despre faptul

ca transmiterea pachetelor de date este mult mai sigura daca structura acestora nu este

modificata iar calea este deja cunoscuta, in contradictie cu modelul de transmisie al

datagramelor (un transfer de baza de tipul packet-switching, unde timpul pana la

destinatie, ordinea bitilor si livrarea pachetului nu sunt garantate de catre retea) impus de

catre protocolul „User Datagram Protocol” (UDP). [8]



13

b) Serviciul de asigurare a livrarii pachetelor in ordine („same order delivery”): este

proiectat cu scopul de a micsora rata probabilitatii bucatirii pachetelor de date pe traseul

retelei, iar in cazul folosii protocolului UDP, de a evita problema de „head-of-line

blocking” (atunci cand unui port i se cuvin doua bucati din pachete de date diferite,

transmise catre acesta in acelasi timp, ceea ce provoaca un efect de „bottleneck” asupra

retelei, micsorand perfomantele acesteia). [9]

c) Serviciul de incredere („reliability”): un serviciu ce doreste asigurarea transportului

total al datelor (informatia se poate pierde pe drum datorita zgomotului de pe canal sau a

altor factori externi), astfel ca se poate efectua o detectie a erorii la receptionarea unui

pachet, pentru a vedea daca acesta este corupt sau nu, ulterior trimitand un semnal de

„acknowledgment” (ACK) daca s-a primit cu succes, sau „not acknoelwdment” (NACK)

daca s-au intampinat probleme. [7]

d) Serviciul de rata transferului datelor („flow control”): un principiu bazat pe ideea

ca un expeditor poate trimite pachetele de date cu o viteza mult mai mare decat le poate

receptiona cu bine si procesa expeditorul.[9]

e) Serviciul de evitare a congestionarii retelei („congestion avoidance”): se bazeaza pe

controlul traficului astfel incat, reteaua sa nu se aglomereze. Evitarea efectului de

„bottleneck” se poate face prin controlul ratei transferului de date sau prin diverse tehnici,

precum „slow-start” ce compenseaza cererile repetate de tip „automatic repeat request”

(ARQ).[9]

f) Serviciul de multiplexare („multiplexing”): un mecanism ce se refera la faptul ca un

terminal poate expedia si trimite date in acelasi timp, utilizand deodata toate porturile sale

aferente (fiind astfel o operatie de „multiplexare”).[10]

Astfel, dispunand de aceste servicii, Nivelul de Tranrport reuseste sa isi duca la bun

sfatsit sarcina de a livra pachete de date catre terminalul destinatie, ceea ce implica o

multiplexare a informatiilor provenite de la diferite procese ale aplicatiei in cauza, aduagandu-i

numerele porturilor unde ar trebui sa ajunga, alaturi de alte informatii relevante, in header-ul

specific (pentru referinta vizuala, este indicata consultarea capitolului 1.2 unde se discuta

amanuntit despre metoda encapsularii). Un lucru important de mentionat este faptul ca, anumite

protocoale (TCP, spre exemplu, dar nu si UDP) dispun si de un mecanism abstract, ce poarta

denumirea de „circuite virtuale” („virtual circuit”), care reprezinta un proces de transmisiune a

datelor intr-o asemenea maniera incat creaza iluzia existentei unui strat fizic de legatura intre

sursa si destinatie. Astfel, sirul de biti este transportat, in timp ce ideea de „pachet” este oarecum

ascunsa fata de procesul aferent aplicatiei in cauza (stream-urile de biti se numeste „segmente” in

cazul de fata).



14

„User Datagram Protocol” pe de alta parte, functioneaza pe baza unui principiu simplu si

eficient, asigurand transportul pachetelor numite „datagrame” in cazul nostru (adica livrarea la

timp, ordinea bitilor si realizarea transportului complet nu sunt garantate), cu o viteza mult mai

mare, astfel servind in aplicatii precum „streaming-ul” unui video pe internet sau ascultarea unui

post radio prin browser-ul de navigare online.

Trebuie mentionat faptul ca, in cadrul altor modele de retea ce nu se bazeaza pe ideea de

„adresa IP”, precum X.25, ATM sau Frame Relay, conexiunea de tip „connection-oriented" este

implementata intr-un Nivel de Date sau Nivel de Retea, necesitatea utilizarii unui Transport

Layer devenind inutila.

2.2 Protocoale proeminente ale Nivelului de Transport

Acum, cunoscand si mecanismele principale din spatele functionarii Nivelului de

Transport al modelului TCP/IP, ne putem concentra asupra descrierii in detaliu a celor mai

proeminente protocoale ale acestuia.

(Protocoalele „TCP” si „UDP”)

(https://i-technet.sec.s-msft.com/dynimg/IC213263.gif)

In imagina de mai sus putem observa doua dintre cele mai importante protocoale ale

nivelului de Transport, TCP, respectiv UDP. Astfel, ne vom concentra asupra explicarii

mecanismului din spatele acestora, alaturi de alte protocoale proeminente.



15

2.2.1 Protocolul TCP

„Transmission Control Protocol” reprezinta unul din protocoalele „nucleu” ale Nivelului

de Transport din modelul TCP/IP (de unde si denumirea), dispunand de servicii precum livrarea

in ordine si verificarea bitilor transmisi intre terminalele participante din cadrul unei retele, fiind

folosit totodata si pentru operatii complexe datorita altor protocoale ce sunt incapsulate in acesta

(dintre care putem mentiona „Hypertext Transfer Protocol”, „Simple Mail Transfer Protocol”,

„Post Office Protocol” etc.). Acesta a luat nastere in anul 1974, drept rezultat a necesitatii

proiectarii unei metoda de comunicare intre terminale, in cadrul unei retele, fiind publicat in

documentul RFC 1122 de catre Vint Cerf si Bob Kahn.[4]

Dupa cum am mentionat si in capitolele anterioare, protocolul TCP functioneaza pe baza

idee de „connection-oriented transmission” (transmisiunea datelor in ordinea lor originala,

asigurand livrarea si stabilind initial in canal de conexiune intre terminalele ce comunica), fiind

nivelul dintre aplicatie si „Internet Protocol” (IP). Atunci cand o aplicatie doreste a efectua o

transmisiune de pachete (compuse din octeti de date), si nu se recurge la mecanismul de bucatire

a acestuia in dimensiuni si format precum a adreselor IP (metoda rar utilizata), se genereaza o

cerere catre protocolul TCP, acesta intrand in functiune dupa cum se dicteaza. De obicei,

pachetele ce urmeaza a fi trimise sunt alcatuite dintr-un „body” (continand informatia propriu-

zisa pe care protocolul IP o transmite), caruia i se adauga niste „headers” ce ajuta la descrierea

detaliilor precum sursa, destinatia si controlul informatiei. De asemenea, tinand cont de faptul ca

un pachet de date poate fi pierdut („lost”), duplicat („duplicated”) sau livrat in alta ordine

(„delivered out-of-order”), protocolul TCP tinde sa anticipeze aceste probleme prin emiterea

cererilor de retransmitere a datelor, re-aranjarea bitilor in cadrul pachetelor sau optimizarea

traseului dintre sursa si destinatie, incercand decongestionarea retelei. [11]

„Transmission Control Protocol” a fost conceput sub ideea realizari corecte si precise a

transportului, neglijand astfel viteza in favoarea acuratetei, astel nefiind indicat in aplicatii ce

necesita transfer in timp real, precum „Voice Over IP”, spre exemplu. Desi, in mod normale,

protocolul IP se ocupa de livrarea propriu-zisa a datelor, TCP tine cont de toate pachetele trimise

(denumtie „segmente” dupa atribuirea unui „header”), totodata indicand cum ar trebui sa fie

transferate acestea (pentru o analogie mai potrivita, ganditi-va la faptul ca IP este practi soferul

unui camion, insa cel care il incarca cu date si ii explica traseul este de fapt protocolul TCP).

Drept mecanism de functionare, TCP acceta datele provenite dintr-un nivel superior, le

imparte in pachete carora le adauga un „header” caracteristic, astfel creand un „segment TCP”,

ce urmeaza fi si el incapsulat la randul sau intr-o datagrama impusa de „Internet Protocol”,

ulterior facandu-se transferul cu acesta intre terminale.[11]



16

(„Header-ul” specific protocolului TCP)

(http://en.wikipedia.org/wiki/Transmission_Control_Protocol)

Precum putem vedea in imaginea de mai sus, „header-ul” specific protocolului TCP

contine informatii cruciale in transmiterea informatiei, precum portul sursa de unde se transmit

datele („Source Port”- adresa pe 16 biti), portul destinatie („Destination Port” – adresa pe 16

biti), numarul de secvente („Sequence Number” – dimensiune de 32 biti, cu rol dublu: daca

fanionul „SYN” este egal cu 1, atunci acesta este numarul initial de secventa, sau in caz contrat,

daca „SYN”=0, atunci acesta este numarul de secvente acumulate; „numarul secventei” adunat

cu „1” este practic numarul recunoscut in cadrul procedurii de „ACK” atunci cand se face

verificarea daca terminalul destinatie a primit pachetul sau nu), numarul de recunoastere

(„Acknowledgement Number” – pe 32 de biti, despre care s-a discutat in paranteza anterioara),

decalajul de date („Data Offset” – pe 4 biti, specificand dimensiunea header-ului TCP in cuvinte

de 32 biti, dimensiunea minima a acestuia putand fi de 5 cuvinte, respectiv maxima de 15), biti

rezervati („Reserved” – 3 biti, in cazul unei utilizari viitoare, de obicei setati pe zero), fanioane

(„Flags” – 9 biti, existand 9 fanioane ce servesc scopuri diverse, precum „NS”, „CWR” cu rol in

decongestionarea canalului de transmieie, „ECE”, „URG”, „ACK”, „PSH”, „RST” pentru

resetare, „SYN” despre care am vorbit anterior avand roluri in sincronizarea datelor, „FIN” ce

indicata faptul ca nu mai sunt date de trimis de la sursa), dimensiunea ferestei de la destinatie

(„Window Size” – 16 biti), verificarea erorilor („Checksum” – 16 biti), pointer urgent („Urgent

Pointer” – 16 biti, daca fanionul „URG” este setat pe „1”, atunci acest camp devine un decalaj

pentru numarul de secventa ce indica ultimul octect urgent de date), si alte campuri pentru

optiuni („Options” – variaza intre 0 si 320 de biti).

Mecanismul de functionare al protocolului TCP poate fi divizat in trei faze, astfel incat,

in cea incipienta, conexiunile sunt stabilite pe baza principiului „hand-shake”

(trimiterea/primirea confirmarilor), apoi urmand transferul de date efectiv, tot procesul



17

incheindu-se cu faza de „connection termination” unde circuitele vituale sunt inchise iar

resursele folosite sunt eliberate spre a putea fi utilizate si de catre alte protocoale.

(Diagrama decizionala ce asigura functionarea protocolului TCP)

(http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Tcp_state_diagram_fixed_new.svg/796px-

Tcp_state_diagram_fixed_new.svg.png)

Dupa cum am mentionat pana in momentul actual, protocolul TCP se axeaza pe livrarea

pachetelor de date asa cum au fost trimise, fara erori, si urmarind totodata sa nu aglomereze

traficul pe canalele retelei, astfel sacrificand viteza. Asadar, s-a impus proiectarea unui alt

protocol, fiind un complementar al lui TCP, si anume „User Datagram Protocol” (UDP) despre

care vom discuta in continuare.

2.2.2 Protocolul UDP

„User Datagram Protocol” este unul din protocolalele de baza ale Nivelului de Transport,

asemeni lui TCP, fiind proiectat de catre David Reed in anul 1980 si publicat in lucrarea de

specialitate RFC 768. Dupa cum am mentionat anterior, UDP foloseste principiul



18

„connectionless” (datele sunt aranjate intr-o alta ordine decat cea initiala, rutarea facandu-se cat

mai rapid, in defavoarea optimizarii acesteia), ce nu prezinta mecanisme de tipul „hand-

shaking”, astfel compensand cu o viteza mult mai mare in comparatie cu „rivalul” sau, TCP-ul.

De asemenea, acest protocol nu garanteaza receptionarea pachetelor de fiecare data cand are loc

o transmisiune, nu se ocupa de cele de tip „duplicated”, insa utilizeaza serviciul de verificare a

erorilor („Checksum”) pentru integritatea informatiei si numerotarea porturilor destinatie. Astfel,

UDP-ul ajuta in transmiterea pachetelor de date numite „datagrame” catre alte terminale,

folosind „Internet Protocol” precum TCP, fara a fi necesara o conexiune stabilita apriorii, servind

in aplicatii unde verificarea amanuntita pentru erori nu este necesara. [12]

Protocolul UDP prezinta un set de caracteristici pentru care este preferat in proiectarea

anumitor aplicatii, precum faptul ca este „transaction-oriented” (ofera raspunsuri rapide

protocoalelor de tip „Domain Name System”), functioneaza prin transfer de datagrame (ajuta in

modelarea protocoalelor de tipul „Remote Procedure Call” sau in metoda de „IP tunneling”

mentionata in capitolele precedente), viteza de transmisie (potrivit pentru un numar foarte mare

de clienti), functionarea avantajata de caile unidirectionale si lipsa de efectuare a cererii de

retransmitere. Asadar, desi nu garanteaza transmiterea datelor de fiecare data, acesta

compenseaza prin atributele enuntate mai sus, fiind potrivit pentru alte tipuri de aplicatie.

„User Datagram Protocol” functioneaza pe acelasi principiu de atribuire a pachetului cu

informatie un „header” specific, insa putin diferit fata de cel al lui TCP, acesta ilustrand doar

numarul portului sursa („Source Port Number”), numarul portului destinatie („Desination Port

Number”), lungimea „header-ului” si a datelor transmite („Lenght”) si algoritm de verificare a

erorilor („Checksum” – camp optional in cazul transmisiei prin IPv4 si oblicatoriu pentru IPv6).

(„Header-ul” caracteristic protocolului UDP)

(http://en.wikipedia.org/wiki/User_Datagram_Protocol)

Utilizand un mecanism simplu la baza si avand atribute unica, protocolul UDP s-a facut

remarcat in proiectarea retelelor si a aplicatiilor ce necesita un transfer de date in timp real, astfel

fiind considerat deseori un complementar al lui TCP, nicidecum neglijat in favoarea acestuia.



19

2.2.3 Protocolul RSVP

Pana la momentul actual am ales a discuta doar despre mecanismele din spatele

transportului in sine, insa se considera necesara o analiza mai amanuntita si asupra principiului

de alocare a resurselor, destul de important de altfel, altminteri neavand ce sa se transmita efectiv

pe canal. Asadar, Nivelul de Transport este prevazut si cu un protocol de alocare a resurselor in

retea, si anume „Resource Reservation Protocol” (abreviat „RSVP”). Acesta opereaza pe baza

protocoalelor IPv4 si IPv6 din Nivelul de Internet, asigurand rezervarea resurselor intr-un mod

ce evita congestionarea retelei si timpii de asteptare indelungati, asemeni lui „Internet Control

Message Protocol” (ICMP), fiind descris in lucrarea RFC 2205. Protocolul RSVP poate fi utilizat

atat de terminalele expeditoare, cat si de cele destinatare, definind astfel modalitatea in care

aplicatiile rezerva sau elibereaza datele o data ce tranzactia s-a incheiat cu succes. In zilele

noastre, RSVP-ul este rar intalnit in forma sa initiala, insa extensiile sale, precum RSVP-TE

devin din ce in ce mai intalnite in comunicatiile de zi cu zi. [13]

Drept caracteristici principale, putem observa faptul ca RSVP-ul se distinge prin cererile

de alocare a resurselor intr-o singura directie (de la expeditor catre destinatar), prin faptul ca nu

este un protocol de rutare la baza (insa noile sale extensii tind a indeplini si aceasta sarcina),

suporta ideea schimbarilor dinamice ce au loc intr-o retea printr-un mecanism de „soft state” ce

impune o reimprospatare a resurselor blocate de fiecare nod si dispune de cateva moduri de

rezervare a datelor, ceea ce permite o flexibilitate enorma in proiectarea retelei. De asemenea,

acesta dispune si de atribute precum raportarea de erori sau informatii despre sirul de date

generat de catre RSVP. [13]

„Resource Reservation Protocol” functioneaza pe baza a doua principii bine stabilite, si

anume „flowspec” si „filterspec”. Cel dintai ne vorbeste depsre rezervarea resurselor pentru un

stream de date, ce este identificat pe baza adresei destinatie si calitatea serviciului ceruta de catre

aplicatie (denumita despre „flowspec”, adica „specificarea stream-ului”, neputand intelege

cererea eliberata de catre QoS). Un „flowspec” se poate defini fie drept clasa unui serviciu,

rezervarea resurselor (determinata de catre QoS) sau specificatiile traficului de date. Cel de-al

doilea principiu are ca rol definirea pachetelor ce sunt afectate de catre „flowspec-ul” mentionat

anterior, putand fi de tip fix (rezerva resursele pentru stream-ul respectiv), partajat (pune la

dispozitie resurse comune pentru mai multe stream-uri) sau de tip „wildcard” (rezerva un tip de

resursa doar pentru anumite stream-uri). O cerere emisa catre RSVP, continand un „flowspec” si

un „filterspec” se numeste „flowdescriptor”, ceeea ce ajuta la descrierea parametrilor principali

ai stream-ului de informatii.

Totodata, se impune o discutie si asupra tipurilor de mesaje emise sau primite de catre

protocolul nostru, acestea fiind de doua tipuri: mesaje de tip „path” ce sunt trimise de la sursa

catre destinatie, stocand mereu adresa IP a ultimului nod prin care a trecut si avand informatii cu

privire la stadiul in care se afla magistrala de comunicare, si mesaje de tip „resv” (de la

„reservation”), ce este trimis in sens opus drept un mesaj de confirmare.



20

2.2.4 Protocolul DCCP

„Datagram Congestion Control Protocol” se numara printre protocoalele Nivelului de

Transport, a carei functie principala reprezinta unul din mecanismele ce asigura un transfer optim

al datelor in retea. Acesta contine functii ce se ocupa de decongestionarea traficului de informatii

(precum spune si numele, de altfel, evitarea unui efect de „bottleneck”), fiind introdus in anul

2006 de catre asociatia IETF in documentul RFC 4340, astfel fiind un protocol in continua

dezvoltare.

DCCP-ul prezinta o idee centrala de a avea acces la mecanismele de decongestionare a

canalului de transmisiune fara a fi necesara implementarea acestora in Nivelul de Aplicatie.

Putem spuen faptul ca, pe langa caracteristicile sale de baza, le imprumuta si pe cele ale

protocolului TCP (fara cea de a transmite bitii in ordinea sa originala), insa nu suporta

concentrarea asupra mai multor stream-uri de date precum „Stream Control Transmission

Protocol” (SCTP). Asadar, putem afirma faptul ca protocolul DCCP este util in implementari

precum streaming-ul video, suportul jocurilor online, VoIP sau alte aplicatii ce prezinta un

numar mare de terminale client. [14]

Protocolul de fata lucreaza atat cu pachete de date, cat si cu chei de „ACK”

(acknowledgment), reusind astfel sa informeze expeditorul daca informatiile au ajuns la

destinatie sau au fost marcate cu o eticheta de tipul „ECN” („Explicit Congestion Notification”).

2.2.5 Protocolul SCTP

„Stream Control Transmission Protocol” este unul dintre cele mai interesante protocoale

ale Nivelului de Transport deoarece combina oarecum facilitatile celor doua protocoale centrale,

UDP, si respectiv, TCP, fiind totodata al 132-lea protocol din nivel, proiectat de catre asociatia

IETF in cadrul lucrarii „Stream Control Transmission Protocol”, anul 2000. [15]

Aplicatiile construite pe baza transportului realizat prin SCTP impun ca datele sa fie

transmise sub forma de „mesaje”, ulterior acestora si informatiilor despre destinatie fiindu-le

atasat cate un „header” specific. Astfel, putem caracteriza protocolul ca fiind de tipul „message-

oriented”, transmitand pachetele de date intr-o forma neschimbata, insa stream-ul este impatit in

mesaje (nu este trimis tot deodata precum face TCP). Totodata, asemeni protocolului UDP,

mesajele transmise de catre un expeditor ce utilizeaza SCTP sunt trimise catre aplicatia destinatie

intr-o singura operatie, astfel avand o viteza destul de considerabila, desi foloseste o parte din

mecanismele lui TCP. De asemenea, SCTP-ul este capabil de a realiza „multi-streaming”

(transmisie multipla in acelasi timp), fiind capacitatea de a transmite siruri de date independente

in paralel (precum afisarea pozelor si textului unei pagini web simultan).

Drept caracteristici, putem observa faptul ca oferta suport de tipul „multihoming”

(ambele terminale intre care se realizeaza conexiunea pot avea mai mult de o adresa IP),



21

eliminarea efectului de „head-on-bloking” prezent la TCP prin livrarea mesajelor de date,

selectarea caii de transmisiune a informatiilor si monitorizarea acestea (putand totodata sa o

recunoasca drept un „canal primar”), detectare a erorii sporita si utilizarea sistemului de „ACK”

pentru confirmarea primirii pachetelor de catre destinatar. De asemenea, structura pachetelor

joaca un rol esential in evidentierea acestor atribute, prin faptul ca „header-ul” consta in doua

sectiuni importante: prima este numita „common header”, indicand primii 12 octecti si continand

portul sursa si cel destinatie, eticheta de verificare si „checksum-ul”, iar a doua fiind „data

chunks” ce descrie atat datele ce urmeaza a fi transmise, cat si fanioane, lungime si tipul de date.

(Structura „mesajelor” transmise de protocolul SCTP)

(http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)



22

CONCLUZII

In finalul acestei lucrari putem conclude faptul ca modelul TCP/IP poate fi privit drept o

trusa cu unelte ce ajuta la proiectarea unei varietati de retele (streaming, data transfer only etc.),

iar desi aici am discutat pe larg doar despre Nivelul de Transport, putem afirma faptul ca toate

componentele modelului sunt esentiale bunei functionari ale unei conexiuni. Transport Layer-ul

asigura nu doar comunicarea propriu-zisa prin mecanismele enuntate anterior, dar totodata

asigura si o oarecare ordine si disciplina in pregatirea datelor inainte de livrarea acestora prin

atasarea „header-elor”, precum am putut observa la discutia despre protocoalele TCP si UDP.

De asemenea, suntem de parere ca, un proiectant ar trebui sa aiba cu sine mereu modelul

OSI drept referinta teoretica, in timp ce pune in aplicare modelul TCP/IP, astfel putand obtine o

performanta ridicata in cadrul retelei concepute, stiind ce mecanisme i-ar fi utile si care ar fi de

prisos.



23

BIBLIOGRAFIE

1. „Computer networks (limba romana)” – Andrew Tanenbaum, pag 1-2


3. RFC 1123, “Requirements for Internet Hosts – Application and Support”, R. Braden

(ed.), October 1989

4. RFC 1122, “Requirements for Internet Hosts – Communication Layers”, R. Braden (ed.),

October 1989



7. „Computer networks (limba romana)” – Andrew Tanenbaum, pag 454






13. "RSVP Project". USC Information Science Institute. Retrieved 2011-02-16

14. RFC 4340 - Datagram Congestion Control Protocol

15. “Stream Control Transmission Protocol”. IETF. October 2000. RFC 2960

Reţele de Calculatoarestst.elia.pub.ro/news/RC/Teme_RC_IVA_2014_15/1_VicaDaCa_SipicaAl… · model...

Documents

Transcript of Reţele de Calculatoarestst.elia.pub.ro/news/RC/Teme_RC_IVA_2014_15/1_VicaDaCa_SipicaAl… · model...