Nivelul Transport

Introducere
Rețelele de date și Internetul suportă rețeaua umană asigurând comunicație fiabilă între
oameni. Pe un singur echipament, oamenii pot utiliza mai multe aplicații și servicii cum ar fi
email, web și mesagerie instantă pentru a trimite mesaje sau pentru a obține informații.
Aplicații precum clienți de email, navigatoare web și clienți de mesagerie instantă permit
oamenilor să folosească rețele și calculatoare pentru a trimite mesaje și a găsi informații.

Datele de la fiecare din aceste aplicații sunt împachetate, transportate și trimise la

aplicația corespunzătoare a echipamentului de destinație. Procesele descrise de layer-ul
transport al modelului OSI acceptă date de la layer-ul aplicație și îl pregătesc pentru adresarea
la layer-ul rețea. Layer-ul transport pregătește datele pentru transmisie în rețea. Un calculator
sursă comunică cu un calculator destinatar pentru a decide cum să împartă informațiile în
segmente,cum să se asigure că nici unul din segmente nu se pierde și să verifice modul în care
sosesc segmentele. Atunci când ne gândim la layer-ul transport, ne gândim de la un
departament de livrare care pregătește o singură comandă pentru livrarea mai multor pachete.

În acest curs examinăm rolul layer-ului transport în încapsularea datelor aplicației

pentru a fi utilizate de layer-ul rețea. Layer-ul transport asigură și aceste funcții:

- Permite mai multor aplicații, cum ar fi email-ul și rețelele sociale să funcționeze în

același timp pe un singur echipament
- Dacă este necesar, se asigură dacă datele au fost primite corect și în ordine de
aplicația corectă
- Furnizează mecanisme de gestiune a erorilor

Protocoale specifice nivelului Transport

Transportul datelor

Layer-ul transport este responsabil cu stabilirea unei sesiuni provizorii de comunicare

între două aplicații și livrarea datelor între ele. O aplicație generează date trimise de la o
aplicație de pe un host sursă către o aplicație de pe un host de destinație, fără a lua în considerare
tipul hostului de destinație, tipul de mediu prin care trebuie să treacă datele, calea urmată de
date, congestionarea sau dimensiunea rețelei. Așa cum se arată în figură, layer-ul transport este
legătura dintre layer-ul aplicație și layerele inferioare care sunt responsabile cu transmisia în
rețea.

Layer-ul transport furnizează o metodă de livrare a datelor în rețea într-o modalitate

care garantează asamblarea corespunzătoare a datelor la capătul receptor. Layer-ul transport
asigură segmentarea datelor și controalele necesare pentru a reasambla aceste segmente în
stream-uri de comunicare diferite. În TCP/IP, această segmentare și procesul de reasamblare
pot fi obținute folosind două protocoale diferite ale layer-ului transport: Transmission Control
Protocol (TCP) și User Datagram Protocol (UDP).

Responsabilitățile principale ale protocoalelor layer-ului transport sunt:

- Urmărirea comunicației individuale între aplicații pe hosturile sursă și destinație

- Segmentarea datelor și gestionarea și reasamblarea datelor segmentate în stream-
uri de date la destinație
- Identificarea aplicației corespunzătoare pentru fiecare stream de comunicație

Fig. 9.1.Activarea aplicațiilor pe echipamente pentru comunicare

 Urmărirea Conversațiilor Individuale

Layer-ul transport urmărește fiecare conversație individuală care călătorește între o aplicație
sursă și una de destinație, separat. Un host poate avea mai multe aplicații care comunică în rețea în mod
simultan. Fiecare din aceste aplicații comunică cu una sau mai multe aplicații pe unul sau mai multe
hosturi. Este responsabilitatea layer-ului transport să mențină și să urmărească aceste conversații
multiple.

Fig.9.2. Urmărirea conversațiilor

Segmentarea Datelor și Reasamblarea Segmentelor

Datele trebuie să fie pregătite pentru a fi trimise în mediu sub forma unor piese ce pot fi
gestionate. Majoritatea rețelelor au o cantitate de date limită ce poate fi inclusă într-un singur pachet.
Protocoalele layer-ului transport au servicii care segmentează datele aplicației în blocuri de date de
dimensiuni corespunzătoare (Fig.9. 3). Acest serviciu include încapsularea cerută pe fiecare piesă de
date. Este adăugat la fieacare bloc de date un header folosit pentru reasamblare. Acest header este
utilizat pentru a urmări stream-ul de date.

La destinație, layer-ul transport trebuie să poată reconstrui piesele de date într-un stream
complet de date care este util layer-ului aplicație. Protocoalele layer-ului transport descriu modul în
care informația din header-ul transport este utilizată pentru a reasambla datele în stream-uri ce vor fi
pasate layer-ului aplicație.
 Fig.9.3. Segmentarea

Identificarea Aplicațiilor

Pot exista mai multe aplicații sau servicii care să se execute pe fiecare host din rețea. Pentru a
transmite stream-urile de date la aplicațiile corespunzătoare, layer-ul transport trebuie să identifice
aplicația țintă (Fig.9 4). Pentru a realiza asta, layer-ul transport alocă un identificator pentru fiecare
aplicație. Acest identificator este denumit număr de port. Fiecare proces software care are nevoie să
acceseze rețeaua primește un număr de port unic în acel host. Layer-ul transport folosește porturi pentru
a identifica aplicația sau serviciul.

Fig.9.4. Identificarea aplicațiilor

 Multiplexarea transmisiunii de date

Trimiterea unor tipuri de date (de exemplu, un streaming video) într-o rețea sub forma
unui stream de comunicare complet ar putea utiliza toată lățimea de bandă disponibilă și ar
putea împiedica apariția altor comunicații în același timp. De asemenea, efectuează și
recuperarea erorilor și retransmisia datelor deteriorate.

Figura 9.5 arată că segmentarea datelor în părți mai mici permite mai multor
comunicații diferite, de la mai mulți utilizatori diferiți, să fie intercalate în aceeași rețea.
Segmentarea datelor de către protocoalele layer-ului transport furnizează și mijloace pentru a
trimite și primi date atunci când mai multe aplicații concurează pe un calculator.

Fără segmentare, o singură aplicație ar putea primi date. Spre exemplu, un flux video
poate ocupa întregul mediu de comunicație în loc să îl partajeze. Nu ați mai putea primi email-
uri, discuta folosind mesageria instant sau vizualiza pagini web în timp ce urmăriți și un video.

Pentru a identifica fiecare segment de date, layer-ul transport adaugă la segment un

header ce conține date binare. Header-ul conține câmpuri de biți. Valorile din acest câmp sunt
cele ce permit ca protocoale diferite ale layer-ului transport să efectueze diferite funcții în
gestiunea comunicațiilor de date.

Fig.9.5. Serviciile nivelului Transport

 Layer-ul transport este responsabil și cu gestiunea cerințelor de fiabilitate ale unei
conversații. Diferite aplicații au cerințe de fiabilitate ale transportului diferite.

IP se preocupă doar cu structura, adresarea și rutarea pachetelor. IP nu specifică modul

în care are loc livrarea sau transportul pachetelor. Protocoalele de transport specifică modul în
care se realizează transferul mesajelor între hosturi. TCP/IP asigură două protocoale ale layer-
ului transport: Transmission Control Protocol (TCP) și User Datagram Protocol (UDP), așa
cum se arată în figură. IP folosește aceste protocoale de transport pentru a permite hosturilor
să comunice și să transfere date.

TCP este considerat un protocol al layer-ului transport fiabil, cu opțiuni complete, care
se asigură că toate datele ajung la destinație. În schimb, UDP este un protocol al layer-ului
transport foarte simplu care nu asigură fiabilitate.

Fig.9.6. Rolul protocoalelor nivelului Transport

 Așa cum s-a afirmat anterior, TCP este considerat un protocol fiabil , ceea ce înseamnă
că include procese pentru a asigura livrarea fiabilă între aplicații în cadrul livrării confirmate.
Transportul TCP este similar cu livrarea pachetelor care sunt urmărite de la sursă la destinație.
Dacă o comandă FedEx este împărțită în mai multe livrări, un client poate verifica online pentru
a vedea ordinea de livrare.

Folosind TCP, cele trei operații de bază ale fiabilității sunt:

- Urmărirea segmentelor de date transmise

- Confirmarea datelor primite
- Retransmiterea datelor neconfirmate

TCP împarte un mesaj în părți mai mici cunoscute ca segmente. Segmentele sunt
numerotate în secvență și pasate procesului IP pentru asamblarea în pachete. TCP păstrează
urma numărului de segmente care au fost trimise către un anumit host dintr-o anumită aplicație.
Dacă expeditorul nu primește o confirmare într-o anumită perioadă de timp, se presupune că
segmentele au fost pierdute și se retransmit. Doar porțiunea mesajului care este pierdut se
retrimite, nu întregul mesaj. La hostul receptor, TCP este responsabil cu reasamblarea
mesajului în segmente și pasarea lor la aplicație. FTP (File Transfer Protocol) și HTTP
(Hypertext Transfer Protocol) sunt exemple de aplicații care folosesc TCP pentru a asigura
livrarea datelor.

Dați clic pe butonul Play din figură pentru a vedea o animație a segmentelor TCP ce
sunt transmise de la expeditor la receptor.

Aceste procese de fiabilitatea plasează supraîncărcarea adițională pe resursele rețelei

din cauza proceselor de confirmare, urmăririi și retransmisiei. Pentru a suporta aceste procese
de fiabilitate, mai multe date de control sunt interschimbate între hosturile de recepție și
emitere. Această informație de control este conținută în header-ul TCP.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.1.1.5/media/index.html

În timp ce funcțiile de fiabilitate ale TCP-ului asigură o comunicare mai robustă între
aplicații, realizează și supraîncărcare adițională și posibile întârzieri în transmisie. Este un
schimb între valoarea fiabilității și încărcătura pe care o plasează pe resursele rețelei. Impunerea
supraîncărcării pentru a asigura fiabilitatea pentru unele aplicații ar putea reduce caracterul util
al aplicației și ar putea fi chiar dezavantajoasă pentru aplicație. În asemenea cazuri, UDP este
un protocol de transport mai bun.
 UDP asigură toate funcțiile de bază pentru livrarea segmentelor de date între aplicațiile
corespunzătoare, cu o supraîncărcare mică și cu verificare a datelor. UDP este cunoscut ca un
protocol de livrare best-effort. Din punct de vedere al rețelisticii, livrarea best-effort este
caracterizată ca nesigură, deoarece la destinație nu se primesc confirmări ale faptului că au fost
primite datele. Cu UDP, nu există procese ale layer-ului transport care informează expeditorul
dacă livrarea s-a realizat cu succes.

UDP este similar cu depunerea unei scrisori nesemnate la poștă. Expeditorul scrisorii
nu știe dacă destinatarul va primi scrisoare, nici dacă oficiul poștal este cel responsabil cu
urmărirea scrisorii sau cu informarea expeditorului în care în care scrisoare nu ajunge la
destinația finală.

Dați clic pe butonul Play din figură pentru a vedea o animație a segmentelor UDP ce
sunt transmise de la expeditor la receptor.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.1.1.6/media/index.html

Atât TCP, cât și UDP sunt protocoale de transport valide. În funcție de cerințele
aplicației, poate fi utilizat un protocol de transport, sau în unele situații chiar amândouă.
Dezvoltatorii de aplicații trebuie să aleagă ce tip de protocol de transport este corespunzător în
funcție de cerințele aplicației.

Pentru unele aplicații este necesar ca segmentele să sosească într-o anumită ordine
pentru a fi procesate cu succes. Alte aplicații au nevoie ca toate datele să fie primite complet
înainte de a fi considerate utile. În ambele cazuri, TCP este utilizat ca protocol de transport. De
exemplu, aplicațiile precum baze de date, navigatoare web și clienți de email necesită ca toate
datele trimise să sosească la destinație în starea originală. Datele lipsă pot determina o
comunicație coruptă care este incompletă sau nu poate fi citită. Așadar, aceste aplicații sunt
proiectate pentru a utiliza TCP. Traficul suplimentar este considerat necesar pentru aceste
aplicații.

În alte cazuri, o aplicație poate tolera anumite pierderi de date în timpul transmisiei în
rețea, dar întârzierile nu sunt acceptate. UDP este cea mai bună alegere pentru aceste aplicații
deoarece este nevoie de mai puțină încărcare a rețelei. UDP este preferat pentru aplicații cum
ar fi streaming audio, video și VoIP. Confirmările ar încetini livrarea iar retransmisiile nu sunt
de dorit.
 De exemplu, în cazul în care unul din două segmente dintr-un stream video nu se
primesc, se realizează o întrerupere în stream. Acest lucru poate apărea ca o distorsiune în
imagine, dar poate să nu fie vizibilă pentru utilizator. Pe de cealaltă parte, imaginea din
streaming-ul video poate fi degradată dacă echipamentul de destinație trebuie să țină cont de
datele pierdute sau de întârzierea stream-ului în timp ce se așteaptă retransmisia. În acest caz,
este mai bine să afișăm clipul video la calitatea maximă posibilă, utilizând segmentele
recepționate, în detrimentul fiabilității.

Radio pe Internet este un alt exemplu de aplicație care folosește UDP. Dacă o parte din
mesaj este pierdută în rețea, nu este retransmisibilă. Dacă lipsesc câteva pachete, auditorul
poate auzi o pauză scurtă în sunet. Dacă TCP era utilizat și pachetele pierdute erau retrimise,
transmisia s-ar fi întrerupt pentru a primi aceste pachete iar întreruperea ar fi mai evidentă.

Fig.9.7. Protocoale specifice nivelului Transport

 Introducere în TCP și UDP

Pentru a înțelege cu adevărat diferențele între TCP și UDP, este important să înțelegem
modul în care fiecare protocol implementează funcțiile specifice de fiabilitate și modul în care
urmăresc comunicațiile.

Transmission Control Protocol (TCP)

TCP a fost descris inițial în RFC 793. Pentru a suporta funcțiile de bază ale segmentării
și reasamblării datelor, așa cum se arată în figură, TCP asigură și:

- Conversații orientate pe conexiune prin stabilirea sesiunilor

- Livrare fiabilă
- Reconstrucția ordonată a datelor
- Controlul fluxului
- Stabilirea unei sesiuni

TCP este un protocol orientat pe conexiune. Un protocol orientat pe conexiune este

acela care negociază și stabilește o conexiune permanentă (sau sesiune) între sursă și destinație
înainte de transmiterea traficului. Stabilirea sesiunii pregătește echipamentele pentru a
comunica între ele. În timpul stabilirii sesiunii, echipamentele negociază cantitatea de trafic ce
poate fi trimisă la un anumit moment, iar datele de comunicare dintre cele două pot fi
gestionate. Sesiunea se termină doar după ce comunicarea este completă.

Livrare Fiabilă

TCP poate implementa o metodă pentru a asigura livrarea fiabilă a datelor. În termeni
de rețelistică, fiabilitatea se referă la faptul că fiecare piesă de date pe care o trimite sursa ajunge
la destinație. Din mai multe motive, este posibil ca o parte din date să fie corupte sau pierdute
complet, pe măsură ce sunt transmise în rețea. TCP se poate asigura că toate piesele ajung la
destinație, punând echipamentul sursă să retransmită datele pierdute sau corupte.

Livrarea în Aceeași Ordine

Deoarece rețelele pot furniza mai multe rute care pot avea rate de transmisie diferite,
datele pot sosi în ordinea greșită. Prin numerotarea și secvențierea segmentelor, TCP se poate
asigura că aceste segmente sunt asamblate în ordinea corectă.
 Controlul Fluxului

Hosturile din rețea au resurse limitate, cum ar fi memoria sau lățimea de bandă. Atunci
când TCP este conștient că aceste resurse sunt suprataxate, poate solicita aplicației expeditoare
să reducă rata fluxului de date. Acest lucru se realizează de TCP care reglează cantitatea de
date transmise de sursă. Controlul fluxului poate împiedica pierderea de segmente în rețea și
poate evita nevoia de retransmisie.

Fig.9.8. Servicii TCP

După ce TCP stabilește o sesiune, poate urmări conversația din acea sesiune. Datorită
acestei abilități a TCP-ului, aceste este considerat un protocol dinamic. Un protocol dinamic
este un protocol care urmărește starea sesiunii de comunicare. De exemplu, atunci când datele
sunt transmise folosind TCP, expeditorul se așteaptă ca destinatarul să confirme că a primit
datele. TCP urmărește ce informații au fost trimise și ce informații au fost confirmate. Dacă
datele nu sunt confirmate, expeditorul presupune că datele nu au ajuns la destinație și le
retrimite. Sesiunea dinamică începe cu stabilirea sesiunii și se oprește cu terminarea sesiunii.

Notă:Păstrarea acestor informații de stare necesită resurse care nu sunt necesare pentru un
protocol cum ar fi UDP.

TCP realizează supraîncărcarea pentru a obține aceste funcții. Așa cum se arată în
figură, fiecare segment TCP are 20 octeți de supraîncărcare în header-ul care încapsulează
datele layer-ului aplicație. Asta înseamnă mai mult decât un segment UDP, care are doar 8
octeți. Traficul suplimentar include:

- Numărul de secvneță (32 biți) - Folosit pentru reasamblarea datelor.

- Numărul de confirmare (32 biți) - Indică datele care au fost primite.
- Lungimea header-ului (4 biți) - Cunoscut ca ʺdata offsetʺ. Indică lungimea header-
ului segmentului TCP.
- Rezervat (6 biți) - Acest câmp este rezervat pentru viitor.
- Biți de control (6 biți) - Include flag-uri care indică scopul și funcția segmentului
TCP.
- Dimensiunea ferestrei (16 biți) - Indică numărul de segmente ce poate fi acceptat la
un anumit moment de timp.
- Checksum (16 biți) - Folosit pentru verificarea erorilor din datele și header-ul
segmentului.
- Urgent (16 biți) - Indică dacă datele sunt urgente.

Exemple de aplicații care folosesc TCP sunt navigatoarele web, email-urile și

transferurile de fișiere.
 Fig. 9.9. Segment TCP

User Datagram Protocol (UDP)

UDP este considerat un protocol de transport best-effort, descris în RFC 768. UDP este
un protocol de transport de categorie ușoară care oferă aceeași reasamblare și segmentare a
datelor, dar nu include și fiabilitatea și controlul fluxului de la TCP. UDP este un protocol atât
de simplu, încât de obicei spunem ce nu poate face în comparație cu TCP.

Așa cum se arată în Fig. 9.10, următoarele caracteristici descriu UPD-ul:

- Neorientat pe conexiune - UDP nu stabilește o conexiune între hosturi înainte de

trimiterea datelor.
- Livrare nesigură - UDP nu furnizează servicii prin care să ne asigurăm că datele au
fost livrate în mod sigur. Nu există procese în cadrul UDP-ului prin care expeditorul
să retransmită datele pierdute sau corupte.
 - Nu există Reconstrucția ordonată a datelor - Uneori, datele sunt primite în ordine
diferită față de cum au fost trimise. UDP nu furnizează nici un mecanism de
reasamblare a datelor în secvența originală. Datele sunt efectiv livrate aplicației în
ordinea în care sosesc.
- Nu există Controlul Fluxului - Nu există mecanisme pentru controlul cantității de
date transmise de sursă în scopul evitării supraîncărcării echipamentului de
destinație. Sursa trimite datele. Dacă resursele hostului de destinație sunt
suprataxate, este cel mai probabil ca acesta să renunțe la date până când resursele
devin disponibile. Spre deosebire de TCP, la UDP nu există mecanism pentru
retransmisia automată a datelor aruncate.

Fig. 9.11. Caracteristici UDP

Deși UDP-ul nu include mecanismele de fiabilitate și control al fluxului de la TCP, așa

cum se arată în figură, livrarea datelor cu încărcătură mică fac ca UDP să fie un protocol ideal
de transport pentru aplicațiile care pot tolera anumite pierderi de date. Piesele de comunicare
din UDP sunt denumite datagrame. Aceste datagrame sunt trimise cu cel mai bun efort de
protocolul layer-ului transport. Câteva aplicații care folosesc UDP sunt DNS (Domain Name
System), streaming-ul video și VoIP.
 Una dintre cele mai importante cerințe pentru livrarea în timp real a imaginilor video și
de voce în rețea este ca datele să circule în mod continuu și rapid. Aplicațiile de voce și video
pot tolera unele pierderi de date care au efect minim sau neobservabil și se potrivesc perfect cu
UDP.

UDP este un protocol stateless, ceea ce înseamnă că nici clientul, nici server-ul nu sunt
obligate să monitorizeze starea sesiunii de transmisiune. Așa cum se arată în figură, UDP nu
se preocupă cu fiabilitatea și controlul fluxului. Datele pot fi pierdute sau primite într-o altă
secvență fără nici un mecanism UDP care să recupereze sau să reordoneze datele. În cazul în
care este necesară fiabilitatea atunci când UPD-ul este folosit ca protocol de transport, acesta
trebuie gestionat de către aplicație.

Fig.9.12. Datagrama UDP

Layer-ul transport trebuie să poată separa și gestiona mai multe comunicații care au
cerințe de transport diferite. De exemplu, luați în considerare un utilizator conectat la o rețea
de pe un echipament final. Utilizatorul primește și trimite email-uri și mesaje instant în același
timp în care vizitează și site-uri web sau participă la un apel telefonic VoIP. Fiecare aplicație
primește și trimite date prin rețea în același timp, în ciuda cerințelor diferite de fiabilitate. În
plus, datele de la apelul telefonic nu sunt direcționate către navigatorul web, iar textul de la
mesajele instant nu apar în email.

Pentru fiabilitate, utilizatorii au nevoie ca email-ul sau pagina web să se primească

complet și să se prezinte în întregime, pentru ca informația să fie utilă. Ușoarele întârzieri în
încărcarea email-ului sau a paginii web sunt de obicei acceptate, atâta timp cât produsul final
este arătat în întregime și corect. În acest exemplu, rețeaua gestionează retrimiterea sau
înlocuirea informației lipsă, și nu afișează produsul final până când nu este primit și asamblat
totul.

În schimb, părți mici ce pot lipsi dintr-o conversație telefonică pot fi considerate
acceptabile. Chiar dacă unele părți mici sau câteva cuvinte lipsesc, acestea se pot deduce din
contextul conversației sau putem ruga interlocutorul să repete. Acest lucru este de preferat
pentru întârzierile apărute în cazul în care rețeaua trebuie să gestioneze și să retrimită
segmentele lipsă. În acest exemplu, utilizatorul, nu rețeaua gestionează retransmiterea sau
înlocuirea informației lipsă.

Așa cum se arată în Fig.9.13, pentru ca TCP și UDP să gestioneze aceste conversații
simultan având cerințe diferite, TCP și serviciile bazate pe UDP trebuie să urmărească
comunicarea diferitelor aplicații. Pentru a diferenția segmentele și datagramele pentru fiecare
aplicație, TCP și UDP au câmpuri în header ce pot identifica în mod unic acestea aplicații.
Acești identificatori unici sunt numere de port.

Fig.9.13. Adresarea portului

În header-ul fiecărui segment sau datagramă, există un port sursă și unul de destinație.
Numărul portului sursă este numărul pentru această comunicație asociată cu aplicația originală
din hostul local. Așa cum se arată în figură, numărul portului de destinație este numărul pentru
această comunicație asociată cu aplicația de destinație de pe hostul remote.

Atunci când un mesaj este livrat folosind TCP sau UDP, protocoalele și serviciile
solicitate sunt identificate de un număr de port. Un port este un identificator numeric din cadrul
fiecărui segment utilizat pentru a urmări anumite conversații și servicii de destinație solicitate.
Fiecare mesaj pe care îl trimite o gazdă conține sursa, dar și portul destinație.

Portul de destinație

Clientul plasează un număr al portului de destinație în segment pentru a spune

serverului de destinație ce serviciu este solicitat. De exemplu, portul 80 se referă la HTTP sau
serviciul de web. Atunci când un client specifică portul 80 în portul de destinație, serverul care
primește mesajul știe că sunt solicitate serviciile de web. Un server poate oferi mai mult de un
serviciu simultan. De exemplu, un server poate oferi servicii de web pe portul 80 în același
timp în care oferă și stabilirea conexiunii FTP pe portul 21.

Port sursă

Numărul portului sursă este generat aleator de echipamentul expeditor pentru a

identifica o conversație între cele două echipamente. Acest lucru permite apariția simultană a
mai multor conversații Cu alte cuvinte, un echipament poate trimite mai multe solicitări de
serviciu HTTP către un server de web, în același timp. Conversațiile separate sunt urmărite în
funcție de porturile sursă.
 Fig.9.14. Adresarea portului

Porturile sursă și destinație sunt plasate în cadrul segmentului. Segmentele sunt apoi
încapsulate în cadrul unui pachet IP. Pachetul IP conține adresa IP a sursei și a destinației.
Combinația dintre adresele IP sursă și de destinație și numerele portului sursă și de destinație
este cunoscută ca socket. Socket-ul este utilizat pentru a identifica serverul și serviciul solicitat
de client. În fiecare zi, mii de hosturi comunică cu milioane de servere diferite. Aceste
comunicații sunt identificare de socket-uri.

Combinația dintre numărul de port al layer-ului transport și adresa IP a layer-ului rețea

a hostului este cea care identifică în mod unic un anumit proces de aplicație care se execută pe
un echipament de host individual. Și această combinație este denumită socket. O pereche
socket constă în adresele IP de destinație și sursă și numere portului și este unică, aceasta
identifică o anumită conversație între cele două hosturi.

Un socket client poate arăta astfel, cu 1099 care reprezintă numărul portului sursă:
192.168.1.5:1099
 Socket-ul de pe un server de web poate fi: 192.168.1.7:80

Împreună, aceste două socket-uri se combină pentru a forma o pereche:

192.168.1.5:1099, 192.168.1.7:80.

Crearea socket-urilor permite cunoșterea capetelor comunicațiilor, iar datele pot merge
de la o aplicație ce rulează pe un host către o aplicație care rulează pe un alt host. Socket-urile
permit mai multor procese ale unui client să se recunoască între ele, iar conexiunile multiple la
un server să se distingă între ele.

Portul sursă al unei interogări de client este generat aleator. Acest număr de port se
comportă ca o adresă returnată pentru aplicația solicitată. Layer-ul transport urmărește acest
port și aplicația care a inițiat interogarea pentru ca atunci când este primit un răspuns, acesta să
poată fi trimis la aplicația corectă. Este utilizat numărul portului al aplicației care cere
informații ca port destinație în răspunsul venind dinspre server.

Fig.9.15. Exemple de socket pe segmente

 Internet Assigned Numbers Authority (IANA) alocă numere de porturi. IANA este un
grup de standarde responsabil cu alocarea diferitelor standarde de adresare.
Există tipuri diferite ale numerelor de porturi, așa cum se arată în Figura 9.16:

Fig.9.16. Numerele portului

Porturi cunoscute (numere de la 0 la 1023) - Aceste numere sunt rezervate pentru

servicii și aplicații. Sunt utilizate de obicei pentru aplicații precum HTTP (server de web),
Internet Message Access Protocol (IMAP)/Simple Mail Transfer Protocol (SMTP) (server de
email server) și Telnet. Prin definirea acestor porturi cunoscute pentru aplicații de server,
aplicațiile de client pot fi programat pentru a solicita o conexiune la un anumit port și la
serviciul asociat lui.
Porturi Înregistrare (Numbere de la 1024 la 49151) - Aceste numere sunt alocate
aplicațiilor și proceselor utilizatorului. Aceste procese sunt aplicații individuale pe care un
utilizator a ales să le instaleze, nu aplicații obișnuite care ar primi un număr de port cunoscut.
Atunci când nu sunt utilizate pentru o resursă a serverului, aceste porturi pot fi utilizate și
dinamic, selectate de un client ca portul său sursă.
Porturi Dinamice sau Private (Numbere de la 49152 la 65535) - Cunoscute și ca porturi
efemere, aceasta sunt alocate de obicei dinamic aplicațiilor client atunci când clientul
inițializează o conexiune la un serviciu. Portul dinamic este utilizat de obicei pentru a identifica
aplicația client în timpul comunicației, în timp ce clientul folosește portul cunoscut pentru a
identifica și a se conecta la serviciul solicitat pe server. Nu este ceva uzual pentru un client să
se conecteze la un serviciu folosind un port privat sau dinamic (deși unele programare de
partajare peer-to-peer a fișierelor folosesc aceste porturi).
Figura 9.17 afișează câteva porturi înregistrare și cunoscute mai uzuale din cadrul TCP-
ului.
Figura 9.18 afișează câteva porturi înregistrare și cunoscute mai uzuale din cadrul
UDP-ului.
Fig. 9.17. Porturi TCP cunoscute

Fig.9.18. Porturi UDP cunoscute

 Folosirea TCP-ului și a UDP-ului
Unele aplicații pot utiliza atât TCP, cât și UDP (Fig, 9.19). De exemplu, supraîncărcarea
redusă a UDP-ului permite DNS să se ocupe în mod rapid de mai multe interogări de client. În
orice caz, uneori trimiterea informației solicitatea poate necesita fiabilitatea TCP-ului. În acest
caz, numărul portului cunoscut, 53, este utilizat de TCP și UDP pentru acest serviciu.
Pe site-ul web al organizației IANA se poate găsi o listă cu numere de porturi și
aplicațiile asociate.

Fig.9.19. Porturi comune TCP cât și de UDP

Uneori este necesar să știm ce conexiuni TCP active sunt deschise și funcționează pe
un host dintr-o rețea. Netstat este un utilitar de rețea important ce poate fi utilizat pentru a
verifica acele conexiuni. Netstat afișează protocoalele aflat în uz, adresa locală și numărul
portului, numărul portului și adresa exterioare și starea conexiunii.

Conexiunile TCP neexplicate pot ridica amenințări majore la adresa securității,

deoarece pot indica pe cineva sau ceva conectat la hostul local. În plus, conexiunile TCP inutile
pot consuma resurse valoroase ale sistemului și să scadă performanța hostului. Netstat ar trebui
utilizat pentru a examina conexiunile deschise de pe un host atunci când performanța pare a fi
compromisă.

Există mai multe opțiuni utile pentru comanda netstat . Dați clic pe butoanele din Figura
1-5 pentru a vedea rezultatul diferit al comenzii netstat .

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.1.2.9/media/index.html

În cadrul nivelului Rețea s-a explicat modul în care PDU-urile (protocol data units) sunt
construite prin transmiterea datelor de la o aplicație către layere diferite, pentru a realiza un
PDU care este apoi transmis în mediu. La hostul de destinație acest proces este inversat până
când datele pot fi pasate aplicației.

Unele aplicații transmit cantități mari de date, în unele cazuri chiar mai mulți gigabytes.
Nu ar fi practică trimiterea datelor într-o singură tranșă foarte mare. Nici un alt trafic de rețea
nu ar putea fi transmis în timp ce datele erau salvate. O parte mare de date ar putea să se
transmită chiar și în câteva ore. În plus, dacă au existat erori, întregul fișier de date se va pierde
sau va trebui retrimis. Echipamentele de rețea nu ar avea memorii tampon suficient de mari
pentru a stoca o cantitate așa de mare de date în timpul transmiterii sau primirii. Limita variază
în funcție de tehnologia de rețea și de mediul fizic utilizat.

Împărțirea aplicațiilor de date în segmente se asigură că datele sunt transmise în limitele

mediului și că datele din aplicații diferite pot fi multiplexate în mediu.

TCP și UDP Gestionează în mod Diferit Segmentarea

Așa cum se arată în figură, fiecare header al segmentului TCP conține un număr de
secvență ce permite funcțiilor layer-ului transport de pe hostul de destinație să reasambleze
segmentele în ordinea în care au fost transmise. Astfel, se asigură faptul că aplicația de
destinație are datele în forma exactă pe care a intenționat-o expeditorul.

Deși serviciile care folosesc UDP urmăresc și conversațiile între aplicații; acestea nu
sunt preocupate de ordinea în care a fost transmisă informația sau cu menținerea unei
conexiuni. Nu există nici un număr de secvență în header-ul UDP. UDP este un design simplu
care generează mai puțină încărcare decât TCP, ceea ce duce la un rezultat rapid al datelor.

Informația poate sosi într-o ordine diferită decât cea în care a fost transmisă, deoarece
pachetele diferite pot urma căi diferite în rețea. O aplicație care folosește UDP trebuie să
tolereze faptul că datele pot să nu sosească în ordinea în care au fost trimise.
 Nivelul Transport împarte datele în piese și adaugă un header pentru transportul în
rețea. (Fig.9.20).

Fig. 9.20. Funcțiile nivelului Transport

Comunicarea prin TCP

Diferența cheie între TCP și UDP este fiabilitatea. Fiabilitatea unei comunicații TCP
este obținută prin utilizarea sesiunilor orientate pe conexiune. Înainte ca un host care folosește
TCP să trimită datele către un alt host, TCP inițiază procesul de realizare a conexiunii cu
destinația. Conexiunea dinamică permite urmărirea unei sesiuni sau existența stream-ului de
comunicare între hosturi. Acest proces se asigură că fiecare host este conștient și pregătit pentru
stream-ul de comunicare. O conversație TCP necesită stabilirea unei sesiuni între hosturi în
ambele direcții, așa cum se arată în animație.

După ce a fost stabilită o sesiune, iar transferul de date a început, destinația trimite
confirmări către sursă pentru segmentele pe care le-a primit. Aceste confirmări formează baza
de fiabilitate pentru sesiunea TCP. Atunci când sursa primește o confirmare, știe că datele au
fost livrate cu succes și pot renunța la urmărirea datelor. Dacă sursa nu primește confirmare
într-o anumită perioadă de timp, se retransmit datele către destinație.
O parte din traficul adițional generat utilizând TCP este cel generat de confirmări de primire și
retransmiteri. Stabilirea sesiunilor realizează supraîncărcarea sub forma unor segmente adiționale ce
sunt interschimbate. Există și supraîncărcare adițională pe hosturi individuale create din nevoia de a
urmări ce segmente așteaptă confirmarea și de procesul de retransmisie.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.2.1.1/media/index.html

Procesele aplicațiilor se execută pe servere. Un singur server poate executa mai multe
aplicații de procese în același timp. Aceste procese așteaptă până când un client inițializează
comunicația cu o solicitare pentru informații sau de alte servicii.

Fiecare proces de aplicație de pe un server este configurat să utilizeze un număr de port,

fie în mod implicit, fie manual de un administrator de sistem. Un server individual nu poate
avea două servicii alocate aceluiași număr de port din aceleași servicii ale layer-ului transport.
Un host care execută o aplicație de server de web și o aplicație de transfer de fișier nu pot fi
configurate să folosească același port (de exemplu, portul 8080 din TCP). O aplicație de server
activă alocată la un anumit port este considerată deschisă, ceea ce înseamnă că layer-ul
transport acceptă și procesează segmentele adresate la acel port. Orice cerere adresată socket-
ului corect este acceptată și datele sunt transmise aplicației serverului. Pot fi mai multe porturi
deschise simultan pe un server, câte unul pentru fiecare aplicație activă a serverului. Este un
lucru obișnuit pentru un server să asigure mai mult de un serviciu în același timp, cum ar fi un
server de web sau FTP.

O modalitate de îmbunătățire a securității pe un server este restricționarea accesului la

acele porturi asociate cu serviciile și aplicațiile care ar trebui să fie accesibile solicitanților
autorizați.

Consultați Figurile 1-5 din link-ul următor, pentru a vedea alocarea tipică a porturilor
sursă și de destinație în operațiunile client/server din TCP.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.2.1.2/media/index.html

În unele culturi, atunci când două persoane se întâlnesc, se salută prin faptul că dau
mâna. Acest act este privit de ambele părți ca un semnal pentru o întâmpinare prietenească.
Conexiunile din rețea sunt similare. Primul handshake (strângere de mână) necesită
sincronizarea. Al doilea handshake confirmă interogarea de sincronizare inițială și
sincronizează parametrii de conexiuni din direcția opusă. Al treilea segment de handshake este
o confirmare utilizată pentru a informa destinația că ambele părți sunt de acord cu faptul că s-
a stabilit o conexiune,

Atunci când două hosturi comunică folosind TCP, este stabilită o conexiune înainte ca
datele să fie interschimbate. După ce comunicarea este completă, sesiunile sunt închise și
conexiunea este terminată. Mecanismele de conexiune și sesiune activează funcția de fiabilitate
a TCP-ului. Vizualizați figura pentru a vedea pașii necesari la stabilirea și terminarea unei
conexiuni TCP.

Hosturile urmăresc fiecare segment de date din sesiune și interschimbă informațiile cu

privire la ce date sunt primite folosind informația din header-ul TCP. TCP este un protocol full-
duplex, în care fiecare conexiune reprezintă două stream-uri de comunicare într-o singură
direcție, sau două sesiuni. Pentru a stabili conexiunea, hosturile efectuează un three-way
handshake. Biții de control din header-ul TCP indică progresul și starea conexiunii.

Three-way Handshake:

- Stabilește dacă echipamentul de destinație este prezent în rețea

- Verifică dacă echipamentul de destinație are un serviciu activ și acceptă interogări
pe numărul portului de destinație pe care clientul intenționează să îl folosească
pentru sesiune.
- Informează echipamentul de destinație că clientul sursă intenționează să stabilească
o sesiune de comunicație pe acel număr de port

În conexiunile TCP, clientul hostului stabilește conexiunea cu serverul. Cei trei pași din
stabilirea conexiunii TCP sunt:

Pasul 1. Clientul inițiator solicită o sesiune de comunicare client-server cu serverul.

Pasul 2. Serverul confirmă sesiunea de comunicare client-server și solicită o sesiune de

comunicare server-client.

Pasul 3. Clientul inițiator confirmă sesiunea de comunicare server-client.

Dați clic în figura din următorul link pe butoanele 1-3 pentru a vedea stabilirea de
conexiune TCP.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.2.1.3/media/index.html
 Pentru a înțelege procesul three-way handshake, uitați-vă la valorile diferite pe care le
interschimbă cele două hosturi. În cadrul header-ului segmentului TCP, există șase câmpuri de
1 bit care conțin informația de control utilizată pentru a gestiona procesele TCP. Aceste
câmpuri sunt:

- URG - Urgent pointer field significant

- ACK Câmpul confirmării de primire
- PSH - Funcția Push
- RST - Reset the connection
- SYN - Synchronize sequence numbers
- FIN - Nu mai există date de la expeditor

Câmpurile ACK și SYN sunt relevante pentru analiza three-way handshake-ului.

Pentru a închide o conexiune, flag-ul de control FIN (Finish) trebuie setat în header-ul
segmentului. Pentru a termina fiecare sesiune TCP dintr-o singură direcție, este utilizat un two-
way handshake, care constă într-un segment FIN și un segment ACK. Așadar, pentru a termina
o singură conversație suportată de TCP, sunt necesare patru interschimbări care termină ambele
sesiuni, așa cum se arată în Figura din link-ul următor.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.2.1.7/media/index.html

Obs.În această explicație, termenii client și server sunt utilizați ca referință pentru simplitate,
dar procesul de terminarea poate fi inițiat de oricare două hosturi care au o sesiune deschisă.

Pasul 1: Când clientul nu mai are date de trimis, va trimite un segment cu indicatorul FIN setat.

Pasul 2: Serverul trimite un ACK pentru a confirma primirea FIN-ului și pentru a termina
sesiunea de la client la server.

Pasul 3: Serverul trimite un FIN la client pentru a termina sesiunea dintre server și client.

Pasul 4. Clientul răspunde cu un ACK pentru a confirma FIN-ul de la server.

Atunci când clientul nu mai are date de transferat, setează flag-ul FIN în header-ul unui
segment. Apoi, serverul trimite un segment normal ce conține date cu indicatorul ACK setat
cu numărul confirmării de primire pentru a confirma că toți biții au fost recepționați. Când toate
segmentele au fost confirmate, sesiunea este închisă.
 Sesiunea în cealaltă direcție este închisă folosind același proces. Destinatarul indică
faptul că nu mai sunt date de trimis setând indicatorul FIN în antetul unui segment trimis către
sursă. O confirmare returnată arată că toți octeții de date au fost primiți și sesiunea este închisă.

Priviți figurile 2 și 3 pentru a vedea indicatorii de control FIN și ACK setați în antetul
segmentului pentru a închide o sesiune HTTP.

Puteți termina conexiunea și printr-un 3-way handshake. Atunci când clientul nu are
mai multe date de trimis, trimite un FIN la server. Dacă nici serverul nu mai are date de trimis,
poate răspunde cu flag-urile FIN și ACK, combinând doi pași în unul. Apoi clientul răspunde
cu un ACK.

Comunicarea UDP

UDP este un protocol simplu care asigură funcțiile de bază ale layer-ului transport. Are
o încărcare mult mai mică decât TCP, deoarece nu este orientat pe conexiune și nu oferă
retransmisiuni sofisticate, secvențieri și mecanisme de control al fluxului care asigură
fiabilitate.

Asta nu înseamnă că aplicațiile care folosesc UDP sunt mereu nesigure, nici că UDP
este un protocol inferior. Înseamnă doar că aceste funcții nu sunt asigurate de protocolul layer-
ului transport și trebuie implementate în altă parte, dacă este necesar.

Deși cantitatea totală de trafic UDP aflat într-o rețea tipică este de obicei scăzută,
protocoalele cheie ale layer-ului aplicație care folosesc UDP includ:

- Domain Name System (DNS)

- Simple Network Management Protocol (SNMP)
- Dynamic Host Configuration Protocol (DHCP)
- Routing Information Protocol (RIP)
- Trivial File Transfer Protocol (TFTP)
- Telefonie IP sau Voice over IP (VoIP)
- Jocuri online

Unele aplicații cum ar fi jocurile online sau VoIP pot tolera unele pierderi de date. Dacă
aceste aplicații foloseau TCP, ar putea întâmpina întârzieri mari în timp ce TCP detectează
pierderea de date și le retransmite. Aceste întârzieri ar fi mai dăunătoare performanței aplicației
decât pierderile mici de date. Unele aplicații, cum ar fi DNS, reîncearcă solicitarea dacă nu au
primit un răspuns; așadar, nu au nevoie de TCP pentru a garanta livrarea mesajului.

Încărcarea redusă a UDP-ului îl face să fie dorit pentru asemenea aplicații.

Fig. 9.21. Transportul de date cu încărcătură mică din UDP

Deoarece UDP nu este orientat pe conexiune, sesiunile nu sunt stabilite înainte să aibă
loc comunicarea, așa cum se întâmplă la TCP. Se spune că UDP se bazează pe tranzacție; asta
înseamnă că, atunci când o aplicație are date de transmis, transmite efectiv datele.

Mai multe aplicații care folosesc UDP trimit cantități mici de date care pot încăpea într-
un segment. În orice caz, unele aplicații trimit cantități mari de date ce trebuie împărțite în mai
multe segmente. PDU-ul UDP-ului este denumit datagramă, deși uneori termenii de segment
și datagramă sunt similari pentru a descrie un PDU al layer-ului transport.

Atunci când sunt trimise mai multe datagrame la o destinație, pot urma căi diferite și
ajunge într-o ordine greșită. UDP nu urmărește numerele de secvență așa cum face TCP. UDP
nu dispunde de nici o modalitate pentru a reordona datagramele în ordinea de transmisie, așa
cum se arată și în figură.
 Așadar, UDP doar reasamblează datele în ordinea în care au fost primite și le trimite
către aplicație. Dacă secvența de date este importantă pentru aplicație, aplicația trebuie să
identifice secvența corectă și să determine modul în care datele ar trebui procesate.

Fig. 9.22. UDP : neorientat pe conexiune și nesigur

Ca și în cazul aplicațiilor bazate pe TCP, aplicațiile de server bazate pe UDP primesc

numere de porturi cunoscute sau înregistrate.

Atunci când aceste aplicații și procese sunt executate pe un server, acceptă datele
potrivite cu numărul de port alocat. Când UDP primește o datagramă alocată pentru unul din
aceste porturi, acesta trimite datele aplicației la o aplicație corespunzătoare bazată pe numărul
portului său.
 Fig.9.23. Serverul UDP așteaptă solicitări

Ca și în cazul TCP, comunicarea client/server este inițiată de o aplicație client care

solicită date de la un proces de server. Clientul UDP selectează aleator un număr de port din
intervalul de numere de porturi dinamice și îl folosește ca portul sursă pentru această
conversație. Portul de destinație este de obicei un număr de port înregistrat sau cunoscut alocat
la procesul serverului.

Și numerele de port sursă aleatoare pot ajuta la menținerea securității. Dacă există un
model predictibil pentru alegerea portului de destinație, un intrus poate simula ușor accesul la
un client încercând să se conecteze la numărul portului cel mai probabil de deschis.

Deoarece nu există sesiune care trebuie creată cu UDP, pe măsură ce datele sunt
pregătite pentru a fi trimise și porturile identificate, UDP poate forma pachetele numite
datagrame și le poate trimite nivelului rețea pentru a fi adresate și trimise pe rețea.

După ce un client a selectat porturile sursă și de destinație, aceeași pereche de porturi

este utilizat în header-ul tuturor datagramelor folosite în tranzacție. Pentru ca datele să se
întoarcă de la client la server, numerele portului sursă și de destinație trebuie inversate.
 Vizualizați figurile din link-uș următor pentru a vedea detalii ale proceselor clientului
UDP.

http://cisco.ctcnvk.ro/RS1Romana/course/module7/7.2.3.4/media/index.html

Mai multe aplicații necesită fiabilitate și alte servicii furnizate de TCP. Aceste aplicații
pot tolera întârzieri sau pierderi ale performanței din cauza supraîncărcării impuse de TCP.

Din acest motiv, TCP este mai potrivit pentru aplicații care au nevoie de transport fiabil
și pot tolera unele întârzieri. TCP este un exemplu pentru a arăta rolurile diferite ale layer-elor
din suita TCP/IP. Deoarece protocolul TCP al nivelului transport se ocupă de toate sarcinile
asociate cu segmentarea fluxurilor de date, fiabilitate, controlul fluxului și organizarea
segmentelor, eliberează aplicația de aceste sarcini. Aplicația poate trimite efectiv stream-ul de
date la layer-ul de transport și poate folosi serviciile TCP-ului.

Așa cum se arată în Fig.9.24, unele exemple de aplicații cunoscute care folosesc TCP
includ:

- Hypertext Transfer Protocol (HTTP)

- File Transfer Protocol (FTP)
- Simple Mail Transfer Protocol (SMTP)
- Telnet

Fig. 9.24. Aplicații care folosesc TCP

Există trei aplicații mai potrivite pentru UDP:

 - Aplicațiile care pot tolera pierderi de date, dar nu pot suporta întârzieri
- Aplicații cu interogări simple și tranzacții de răspuns
- Comunicații unidirecționale în care fiabilitatea nu este necesară sau poate fi
gestionată de o altă aplicație

Mai multe aplicații multimedia sau video, precum VoIP sau IPTV (Internet Protocol
Television) folosesc UDP. Aceste aplicații pot tolera unele pierderi de date care au efect minim
sau neobservabil. Mecanismele de fiabilitate ale TCP-ului introduc unele întârzieri ce pot fi
observabile în calitatea sunetului sau a imaginii primite.

Alte tipuri de aplicații potrivite pentru UDP sunt acelea care folosesc interogări simple
și tranzacții de răspuns. Acest lucru se întâmplă atunci când un host trimite o interogare și poate
să primească sau nu un răspuns. Aceste tipuri de aplicații includ:

- DHCP
- DNS - Poate folosi și TCP
- SNMP
- TFTP

Unele aplicații se ocupă chiar ele de fiabilitate. Aceste aplicații nu au nevoie de

serviciile TCP, și pot utiliza mai bine UDP ca protocol al layer-ului transport. TFTP este un alt
exemplu al acestui tip de protocol. TFTP are propriile mecanisme de control al fluxului,
detecție a erorilor, confirmări și recuperare. Nu are nevoie de TCP pentru aceste servicii.

Fig.9.25. Aplicații care folosesc UDP