PROTOCOALE DE COMUNICAȚIE UTILIZATE

ÎN TRANSMISIA DATELOR

Masterand: Sima Oana

Anul I

1
 CUPRINS

1. Introducere
1.1.Comparatia UDP cu TCP
2. Protocolul UDP
2.1. Caracteristicile protocolului UDP
2.2. Structura pachetelor
2.3.Formatul datagramelor UDP
2.4.Interfata de programare pentru aplicațiile UDP
3. Protocolul TCP
3.1. Caracteristicile protocolului TCP
3.1.1.Transfer de date in flux(Stream Data Transfer)
3.1.2. Siguranta
3.1.3. Controlul transmisiei(Flow Control)
3.1.4. Multiplexarea
3.1.5. Conexiunile logice
3.1.6. Full Duplex
3.2. Principiul ferestrei glisante aplicat la TCP
3.3. Formatul segmentului TCP
3.4. Stabilirea unei conexiuni TCP
3.5. Interfata de programare a aplicatiilor TCP
4. Concluzii
5. Bibliografie

2
 1.Introducere
În informatica și telecomunicație, un protocol de comunicații este un set de
reguli și norme care permite ca două sau mai multe entitați dintr un sistem de
comunicații să comunice între ele prin transmiterea de informație printr un mediu de
orice tip prin variația unei mărimi fizice. Protocoalele controlează toate aspectele
comunicațiilor de date.

1.1.Comparatia UDP cu TCP

Este proiectat astfel încât să permită dialogiul între entități pereche din
gazdele susa și destinație, pentru aceasta fiind definite doua protocoale capăt - la -
capăt: TCP și UDP.
Protocolul de control al transmisiei (TCP) permitre ca un flux de octeți emis de
o mașină sa fie recepționat fără erori pe orice alta mașină din rețea. TCP
fragmentează fluxul de octeți în mesaje discrete pe care le pasează nivelului internet.
La destinație, procesul TCP receptor reasamblează mesajele primite, reconstituind
datele inițiale.
TCP realizează controlul fluxului de date pentru a evita situația in care un
transmitător rapid inundă un receptor lent cu mai multe mesaje decât poate acesta
să prelucreze.
TCP este un protocol orientat pe conexiune UDP ( User Datagram Protocol –
protocolul datagramelor utilizator) este un protocol nesigur, fără conexiuni, destinat
aplicațiilor care doresc să utilizeze propria secventiere și control al fluxului și nu
mecanismele asigurate de TCP.
Este un protocol folosit în aplicații pentru care comunicarea rapidă este mai
importantă decât acuratetea transmisiei, așa cum sunt aplicațiile de transmitere a
sunetului și imaginilor video.
Operarea bazată pe datagrame :
 Pachetele sunt trimidse individual și sunt verificate pentru integritate
doar dacă sosesc la destinație.
 Pachetele au frontiere bine definite.

3
 Procesul1 Procesul 2 Procesul n

Port a Port b ............................ Port z

Demultiplexor de porturi

2.Protocolul UDP
UDP este un protocol simplu care oferă funcţiile de bază ale nivelului
transport. Protocolul UDP nu stabileşte o conexiune între sursă şi destinaţie înainte
de a transmite date şi furnizează o încărcătură scăzută transportului de date, datorită
faptului că antetul datagramei este mic şi pentru că nu administrează traficul reţelei.
Deoarece UDP nu este orientat pe conexiune, sesiunile nu sunt stabilite înainte ca
comunicarea să aibă loc, cum se întâmplă cu TCP.
UDP este declarat a fi bazat pe tranzacţii. Cu alte cuvinte, atunci când o
aplicaţie are de transmis date, acesta trimite pur şi simplu acele date. O parte din
protocoalele nivelului Aplicaţie ce utilizează UDP sunt următoarele: DNS (Domain
Name System); SNMP (Simple Network Management Protocol); DHCP (Dynamic
Host Configuration Protocol); RIP (Routing Information Protocol); TFTP (Trivial File
Transfer Protocol).

2.1.Caracteristicile protocolului UDP

UDP este un protocol simplu, cu puţine facilităţi. Nu realizează controlul
fluxului, a erorilor, nu retransmite datagrame pierdute etc. El pur şi simplu oferă IP-
ului un mijloc de multiplexare a proceselor (aplicaţiilor) folosind porturile de nivel
transport. Este utilizat în transferurile scurte de date, gen întrebare - răspuns în
aplicaţiile client - server. Un client trimite o cerere scurtă spre server şi aşteaptă un
răspuns scurt. Dacă aceste nu vine într-un timp aşteptat, atunci repetă cererea.
Un exemplu tipic de utilizare este între un client şi serverul DNS (Domain
Name System) pentru aflarea adresei IP corespunzătoare unui nume de gazdă. Nu
este nevoie de deschiderea unei conexiuni, nici de închidere, pentru un transfer
pentru două mesaje scurte care traversează reţeaua. Atunci când mai multe
datagrame sunt trimise la destinaţie, ele pot lua diferite căi şi pot ajunge în ordine
greşită.

4
 UDP nu ţine cont de numerele de secvenţă cum le utilizează protocolul TCP.
UDP nu are nici o modalitate de a reordona datagramele în ordinea în care au fost
transmise. În figura 1. se observă acest lucru şi mai ales faptul că datagramele
pierdute nu se mai retransmit.

Datagrama 1 Datagrama 1

Datagrama 2 Datagrama 2

Data este → →
Datagrama 3 Datagrama 6
divizată în
datagrame Datagrama 4 Datagrama 5

Datagrama 5
Datagrama 4

Datagrama 6

Fig. 1. Transmiterea datagramelor

2.2. Structura pachetelor

UDP transmite segmente formate dintr –un header de 8 Bytes, urmat de
datele efective de transmis.

32 Biți

Port Sursă Port destinație

Lungime UDP UDP checksum

Cele două poturi identifică cele două sisteme de calcul care comunică, sursa si
destinația. Când un pachet UDP sosește, încărcătura lui este preluată de procesul
atașat portului destinație. Pe scurt, poturile asigură livrarea segmentelor aplicației
corecte.

5
 Portul sursă este necesar în cazul în care receptorul trebuie să răspundă
emitătorului. Copiind portul sursă din pachetul abiasosit în câmpul de destinație al
pachetului de răspuns, procesul care trimite răspunsul poate specifica ce proces de
pe emițător îl primește. Câmpul „Lungime UDP” include headerul de 8 Bytes si
datele. Lungimea minimă este de 8 Bytes (pentru header). Lungimea maximă este
de 65.515 bytes (dimensiune mai mică decât maximul reprezentabil pe 16 biți, limita
este data de dimensiunea maximă a pachetelor IP).
Suma de verificare este opțională și se folosește pentru creșterea fiabilității.
Face verificare header-ului, a datelor și un pseudoheader IP conceptual. Când se
face calculul, câmpul checksum este setat la 0 si câmpul de date este bordat cu un
byte adițional de 0 dacă lungimea lui este un număr impar. Algoritmul de verificare
constă în sumarea tuturor cuvintelor de 16 biți în complement față de 1 și scoaterea
complementului lui 1 din rezultat. Deci, când receptorul face calculul pe întregul
segment, inclusiv pe câmpul de checksum, rezultatul ar trebui să dea 0. Dacă
checksum –ul nu se calculează, atunci se va stoca cu valoarea 0.
În cazul IPV4, pseudoheader-ul arată ca în figura următoare:
Adresa sursei (IPV4)
Adresa destinației (IPV4)
00000000 Protocol = 17 Lungime UDP

Conține adresele IPV4 pe 32 biți ale emitătorului și receptorului, numărul de

protocol pentru UDP (17) și lungimea segmentului (inclusiv headerul). La IPV6 este
similar, însă câmpul de checksum nu mai este opțional.
Includerea pseudoheader-ului în calculul checksum-ului ajuta la detectarea
pachetelor livrate greșit, da includerea lui violează ierarhia protocolului, pentru că
adresele IP din el aparțin stratului IP, nu celui UDP. TCP folosește același
pseudoheader pentru checksum-ul lui.
Trebuie ținut cont că UDP nu are nici o metodă de control a congestiei și a
debitului si nici nu retransmite în cazul primirii unui segment eronat. Totul ramâne pe
seama proceselor user-ului. Însă, oferă o interfață către protocolul IP și poate, și
demultiplexa mai multe procese folosind porturi si opțional, detenție de erori la
recepție. Este util in situații de comunicare client-server. Deseori, clientul trimite o

6
cerere scurtă către server și așteaptă un răspuns rapid. Dacă fir răspunsul, fie
cererea s au pierdut, clientul așteaptă o perioadă de time-out, și apoi încearcă din
nou. Pe lângă faptul că programarea e mai ușoară, sunt necesare și puține mesaje
(unul în fiecare direcție) decât în cazul unui protocol care cere o setare inițială, ca
TCP.
O aplicație care folosește UDP în acest fel este DNS(Domain Name Server).
Pe scurt, un program care trebuie să caute adresa IP a unui host oarecare poate
trimite un pachet UDP care conține numele hostu-lui către un server DNSS. Serverul
răspunde cu un pachet UDP care conține adresa IP a hostului. Nu este nevoie de
nici o setare inițială și eliberare ulterioară a conexiunii.
UDP mai este folosit in aplicații care pun viteza înaintea calitații, în aplicațiile de
tip FINGER (FINGER este un protocol simplu pentru schimbul de status-uri și
informații despre utilizator), si , în general, acolo unde cererile sunt rapide și necesită
un singur pachet de răspuns ( exemplu : SNMP – Simple Network Management
Protocol, RIP – Routing Information Protocol, DHCP – Dynamic Host Configuration
Protocol).
Traficul video si audio este în general transmis folosind UDP. Protocoalele de
streaming audio – video au fost proiectate să suporte eventualele pierderi de
pachete, deci va apărea doar o scădere slabă a calității, în locul unor întarzieri
deranjante care ar apărea în cazul retransmisiei pachetelor pierdute.
Nu există controlul congestiei : UDP nu evită congestiile de unul singur, și este
posibil ca aplicațiile de viteză mare să ducă la blocaj dacă nu se implementează
metode de control al congestiei la nivelul aplicației.

2.3. Formatul datagramelor UDP.

În limbajul curent unitățile de transmisie a informației pentru UDP se numesc
datagrame UDP. Fiecare datagramă UDP este trimisă într – o singură datagrama IP.
Cu toate că, datagrama IP poate fi fragmentată în timpul transmisiei, implementarea
IP a hostului destinată o va reasambla înainte de a prezent – o stratului UDP. Toate
implementările IP trebuie să accepte datagrame de până la 576 octeți, ceea ce
înseamnă că, pentru un antet IP de 60 octeți maxim, o datagramă UDP de 516 octeți
va fi acceptată de toate implementările. Multe implementări vor accepta datagrame
mai mari, dar acest lucru nu este garantat. Datagrama UDP are un antet de numai 8
octeți care este descris în figura următoare:

7
 Lungimea oricărui dintre câmpurile antetului este de 2 octeți (16 biți)
Semnificația câmpurilor este următoarea:
1. Portul sursă – Indică portul procesului eminent. Este portul către care
trebuie trimise răspunsurile.
2. Portul destinație – Precizează portul procesului destinație de poe hostului
destinație.
3. Lungime – Este lungimea în octeți a datagramei utilizatorului
inclusiv antetului.
4. Suma de control – Este un câmp opțional de16 biți, este complementul față
de unu al sumei în complement față de unu a antetului pseudo – IP, antetul UDP și
datelor UDP. Antetul pseudo – IP conține adresele IP sursă si destinație, protocolul
și lungimea UDP.
Suma de control - Complementul față de unu al sumei in complement față de
unu al tuturor cuvintelor de 16 biți din pseudo- antet, antetul TCP si datele TCP. La
calcularea sumei de control, câmpul "Suma de control" este considerat zero. Antetul
pseudo – IP extinde efectiv suma control pentru a include datagrama IP originală
(nefragmentată). Pseudo-antetul este acelasi ca cel folosit de către UDP pentru
calculul sumei sale de control. Este un antet pseudo-IP folosit doar pentru calculul
sumei de control cu formatul descris in figura următoare:

8
 2.4. Interfața de programare pentru aplicațiile UDP
Interfața de aplicație oferită de UDP este descrisă în RFC 768. Ea asigură:
1.Crearea porturilor noi de recepție.
2.Operație de recepție care întoarce datele și o indicație a portului
sursă și a adresei IP sursă.
3.Operație de emisie care are ca parametrii datele, porturile și adresele
sursă și destinație.
Modul în care acestea trebuie implementate este lăsat la disreția celui care
realizează aplicația UDP.
Trebuie avut grijă că UDP și IP nu asigură siguranța livrării, controlul
transmisiei și recuperarea erorilor, astfel încât acestea trebuie asigurate de către
aplicație.
Dintre aplicațiile standard care utilizează UDP enumerăm:
 Trivial File Transfer Protocol (TFTP).
 Serverul de nume DNS (Domain Name System).
 Remote Procedure Call (RPC), utilizat de către NFS (Network File
System).
 Simple Network Management Protocol (SNMP).
 Linghtweight Directory Access Protocol (LDAP).

3. Protocolul TCP
TCP este protocolul principal care permite transportul sigur al datelor de la un
capăt la altul al unei conexiuni într-o reţea nesigură. A fost proiectat special pentru
Internet şi este larg folosit în acest scop. TCP este un protocol orientat pe conexiuni,
care permite ca un flux de octeţi trimişi de un calculator să ajungă fără erori pe orice
alt calculator din reţeaua Internet.
Fiabilitatea comunicării prin intermediul protocolului TCP este dată de
sesiunile orientate pe conexiune. Înainte ca o gazdă să trimită date către o altă
gazdă folosind protocolul TCP, nivelul Transport iniţiază un proces pentru a crea o
legătură cu destinaţia. Această conexiune permite urmărirea sesiunii, sau fluxului de
comunicare între gazde.
Acest proces se asigură că fiecare gazdă are cunoştinţă despre comunicare şi
este pregătită pentru aceasta. O conversaţie TCP completă cere stabilirea unei

9
sesiuni între gazde, în ambele direcţii. După ce sesiunea a fost stabilită, destinaţia
trimite confirmări la sursă pentru fiecare segment pe care îl primeşte.
Aceste confirmări formează baza de fiabilitate în cadrul sesiunii TCP. Când
sursa primeşte o confirmare, se ştie că datele, pentru care s-a primit respectiva
confirmare, au fost livrate cu succes şi astfel se poate încheia urmărirea acelor
datele. În cazul în care sursa nu primeşte o confirmare în cadrul unei sume
prestabilite de timp, se retransmit datele către destinaţie.
Cîteva dintre cele mai cunoscute aplicaţii care sunt transmise cu ajutorul
protocolului TCP sunt prezentate (prin intermediul numerelor de port) în următorul
tabel:

Număr de port Protocol

21 FTP
23 Telnet
25 SMTP
80 HTTP
110 POP-3

Principalul scop al TCP este de a asigura circuit logic sigur sau serviciu de
conexiune între două procese pereche. El nu se bazează pe siguranța altor
protocoale de nivel inferior (cum este IP), așa că TCP trebuie să garanteze el însuși
siguranța transmisiei. TCP asigură considerabil mai multe facilități pentru aplicații
decât UDP, mai ales recuperarea erorilor, controlul transmisiei și siguranța.
TCP este un protocol orientat pe conexiune spre deosebire de UDP care este
fără conexiune. Cele mai multe aplicații protocol, precum Telnet si FTP, utilizează
TCP. Cele două procese comunică unul cu celalalt printr-o conexiune TCP
(InterProcess Communication - IPC), așa cum se arată în figura următoare:

10
 3.1.Caracteristicile protocolului TCP
Principalele caracteristici ale TCP sunt:
 Transfer de date în flux continuu - datele circulă în acelaşi timp,
în ambele sensuri ale conexiunii.
 Siguranţa transmisiei - recuperează pachetele transmise cu erori,
pierdute sau cu număr de secvenţă eronat.
 Controlul fluxului de date – în transferul de date dintre două procese,
când aplicaţia destinaţie trimite o confirmare către emitent, se indică şi numărul
permis de octeţi ce se pot recepţiona, pentru a se asigura că transmiterea rapidă de
mesaje de către un emiţător, nu face ca un receptor lent să primească mai multe
mesaje decât poate prelucra. În urma unui astfel de mesaj, emiţătorul îşi va
dimensiona pachetele transmise la lungimea indicată de receptor.
 Multiplexarea - permite mai multor procese, care rulează pe acelaşi
calculator host, să utilizeze facilităţile protocolului TCP simultan.
 Controlul conexiunii (fiabilitatea conexiunii) - presupune stabilirea
numărului de secvenţă şi a dimensiunii ferestrei, pentru fiecare segment TCP.
 Stabilirea conexiunii.
 Full duplex.

11
 3.1.1. Transfer de date în flux ( Stream Data Transfer)
TCP transferă un șir (stream) continuu de octeți prin rețea. Aplicația nu trebuie
să – și facă griji cu segmentarea datelor în blocuri de baza sau datagrame. O face
TCP prin gruparea octetilor in fragmente TCP, care sunt transferati IP pentru a fi
transmisi la destinatie.
Uneori, o aplicație are nevoie să fie sigură ca toate datele trasnsmise către
TCP au fost în realitate transmise la destinație. Pentru aceasta, o funcție push este
definită. Ea va forța transmiterea tuturor segmentelor TCP rămase în memorie către
destinație. Funcția de închidere (close) normală forțeaza și ea transmiterea datelor la
destinație.
3.1.2. Siguranța
TCP atribuie un număr de secvență fiecarui octeț transmis și asteaptă o
confirmare (acknowledgment - ACK) de la aplicația care recepționează datele TCP.
Dacă confirmarea nu vine într-un interval de timp prestabilit, datele sunt
transmise din nou. Deoarece datele sunt transmise în blocuri (segmente TCP) numai
numărul de secvență al primului octeț este trimis calculatorului destinație. Aplicația
TCP destinație folosește numerele de secvență pentru a le ordona atunci cand
sosesc neordonate și să elimine segmentele duplicate.
3.1.3 Controlul transmisiei (Flow Control)
Aplicația TCP destinație, cand trasmite o confirmare (ACK) către emitent,
indiăa de asemenea numărul de octeți pe careîi poate recețtiona pe lânga ultimul
segment TCP primit, fără să se supraîncarce sau să apară depășirea memoriilor
tampon (internal buffers) ale sale.
3.1.4. Multiplexarea
Este realizata prin utilizarea porturilor, la fel ca si la UDP.
3.1.5. Conexiunile logice
Siguranța și mecanismele de control ale transmisiei descrise mai înainte
necesită ca TCP să inițializeze și mențină câteva informții referitoare la starea
fiecarui flux de date (data stream). Această informație de stare ce include socketurile,
numerele de secvență, dimensiunile ferestrelor se numește conexiune logica.
3.1.6. Full Duplex
TCP asigură două fluxuri concurente de date în ambele sensuri.

12
 3.2. Principiul ferestrei glisante aplicat la TCP
Principiul ferestrei glisante: Un protocol de comunicație simplu ar putea folosi
următorul principiu: trimite un pachet si apoi așteaptă confirmarea de primire de la
destinatar înainte de a trimite pachetul următor.
Dacă confirmarea (ACK) nu este primită într-un interval de timp prestabilit,
pachetul este trimis din nou.
Principiul ferestrei glisant este folosit de către TCP, însă cu câteva diferențe:
 Deoarece TCP asigură o conexiune de flux de octeți (byte-stream
connection), numerele de secvență sunt atribuite fiecarui biț din stream. TCP împarte
acest flux continuu de biți in segmente TCP pentru a le transmite. Principul ferestrei
glisante este folosit la nivel de octeț, adică, segmentele trimise si confirmările vor
transporta numere de secvență pentru octeț si dimensiunea ferestrei va fi exprimată
în număr de biți în loc de număr de pachete.
 Dimensiunea ferestrei este determinată de către receptor când
conexiunea este stabilită și este variabilă în timpul transferului de date. Fiecare
mesaj ACK va include dimensiunea ferestrei pe care receptorul este apt să opereze
în acest moment particular.
Fluxul de date al emitentului poate fi reprezent ca în figura următoare:

13
 Octeții A sunt octeții transmisi despre care s-a recepționat confirmarea de
primire.
Octeții B sunt octeții trimiși despre care nu s-a recepționat confirmarea de
primire.
Octeții C pot fi trimisi fără a se aștepta nici o confirmare.
Octeții D sunt octeti care nu pot fi încă transmisi.

3.3. Formatul segmentului TCP

Formatul segmentului TCP este prezentat în figura de mai jos:

Portul sursă - Numărul portului sursă pe 16 biți folosit de receptor pentru a

răspunde.
Portul destinatie - Numarul portului destinatie pe 16 biți.
Numărul de secvență - Numărul de secvență al primului octate de date din
acest segment. Dacă bițul de control SYN este setat, numărul de secvență este
numărul de secvență initial (n) si primul octeț de date este n+1.
Numărul de confirmare - Dacă bițul de control ACK este setat, acest camo
conține valoarea următorului număr de secvență pe care receptorul se așteaptă să-l
primească.

14
 Data Offset - Numărul de cuvinte de 32 biți din antetul TCP. El indică unde
încep datele.
Reserved - Șase biți rezervați pentru utilizare în viitor; trebuie sa fie zero.
URG - Precizează că articolul pointer de urgență are semnificație în acest
segment.
ACK - Precizează că articolul de "Număr de secvență confirmat" are
semnificație în acest segment.
PSH - Funcția push.
RST - Resetează conexiunea.
SYN - Sincronizează numerele de secvență.
FIN - Nu mai sunt date de la emitent.
Fereastra - Folosit in segmentele ACK. El specifică numărul de octeți de date
începand cu acela indicat în "numarul de secvența confirmat" pe care receptorul
(adică emitentul acestui segment) dorește (si poate) să accepte.
Suma de control - Complementul față de unu al sumei în complement față de
unu al tuturor cuvintelor de 16 biți din pseudo- antet, antetul TCP si datele TCP. La
calcularea sumei de control, câmpul "Suma de control" este considerat zero.Pseudo-
antetul este același ca cel folosit de către UDP pentru calculul sumei sale de control.
Este un antet pseudo-IP folosit doar pentru calculul sumei de control cu formatul
descris în figura urmatoare:

3.4. Stabilirea unei conexiuni TCP

Înainte ca orice dată sa fie transmisă, trebuie stabilită între cele două procese.
Unul dintre procese (de regula serverul) lansează un apel OPEN pasiv, celălalt un
apel OPEN activ. Apelul OPEN pasiv așteaptă până când un alt proces încearcă să
se conecteze la el printr-un apel OPEN activ.

15
 Prin retea, sunt schimbate trei segmente:

proces 1 proces 2
Apelul OPEN pasiv,
așteaptă cereri active
Apelul OPEN activ
trimite SYN, secv = n
Recepționează SYN
trimite SYN, secv = m, ACK n+1

Recepționează SYN +
ACK. Trimite ACK m+1

Conexiunea este acum stabilită si două fluxuri (streamuri) de date (câte unul
pentru fiecare sens) au fost inițializate (numerele de sevență).
Întregul proces este cunoscut ca un "three-way handshake". 
Segmentele TCP schimbate includ numere de secvență inițiale de la ambele
părti pentru a fi folosite la transferurile de date ulterioare. Închiderea conexiunii este
făcuată implicit prin trimiterea unui segment TCP cu bițul FIN setat (cu semnificația
nu mai sunt date). deoarece conexiunea este full-duplex (adică, există două fluxuri
de date, câte unul pentru fiecare sens),segmentul FIN închide transferul numai într-o
direcție. Celălalt proces va trimite acum restul de date pe care-l mai are de transmis
și termină și el cu un segment în care bițul  FIN este setat. Conexiunea este ștearsă
(informațiile despre stare ale ambelor părti) odată ce fluxul de date este închis în
ambele direcții.

3.5. Interfața de programare a aplicațiilor TCP.

 Ca și în cazul UDP, interfața de programare a aplicațiilor TCP nu este
complet definită. Numai cateva funcții de bază pe care trebuie să le asigure sunt
descrise in RFC 793 - Transmission Control Protocol. Așa cum este cazul cu cele
mai multe RFC-uri din suita de protocoale TCP/IP, un mare grad de libertate este
lăsat implementatorilor, permitând de aceea unor implementări optimale (ce depind
de sistemul de operare), ceea ce conduce la o mai bună eficiență (o viteza mai mare
de comunicare).
Următoarele apeluri de funcții sunt descrise in acest RFC:

16
 Open
Pentru a stabili o conexiune sunt necesari câțiva parametrii precum:
 activ/pasiv
 socketul distant (al serverului)
 un număr de port local
 o valoare de timp maximală pentru așteptarea confirmării (opționala)
Această întoarce un nume de conexiune local care este folosit pentru referirea
acestei conexiuni particulare in toate celelalte funcții.
Send
Determină ca datele dintr-un buffer utilizator precizat sa fie trimise prin
conexiune. Poate in mod opțional să seteze fanionul URGENT sau PUSH.
Receive
Copiază datele TCP intr-un buffer utilizator.
Close
Închide conexiunea; determină forțarea transmiterii tuturor datelor care au
mai ramas (push) si un segment cu fanionul FIN setat.
Status
Este un apel dependent de implementare care poate intoarce informații
precum:
 socketul local si socketul ce descrie celălalt capăt al conexiunii.
 dimensiuniel ferestrelor de emisie si receptie.
 starea conexiunii.
 numele local al conexiunii.
Abort
Face ca toate operațiile Send si Receive in desfășurare sa fie terminate și un
RESET sa fie trimis corespondentului TCP.

4. Concluzii:
Protocolul TCP asigură considerabil mai multe facilitati pentru aplicații decât
protocolul UDP, mai ales recuperarea erorilor, controlul transmisiei si siguranța. TCP

17
este un protocol orientat pe conexiune spre deosebire de UDP care este fara
conexiune.

5. Bibliografie:
1. http://www.unibuc.ro/prof/niculae_c_m/telecom/cuprins.htm
2. http://www.kulituranauka.com/wp-content/uploads/2012/02/lectia7.pdf
3. http://profs.info.uaic.ro/~busaco/teach/courses/net/presentations/net5.pdf
4. http://shannon.etc.upt.ro/laboratoare/rcd/rcd_laborator.pdf
5. http://carment.ase.ro/rc/curs/cap7.pdf
6. http://vega.unitbv.ro/~zaharia/tdrcii/TDRC_II-10-TCP.pdf
7.
8. http://stst.elia.pub.ro/news/RC/Teme_RC_IVA_2011_12/Lecu%20tica%20v
dascu%20442A%20Algoritmi%20de%20control%20al%20congestiei%20.pdf
9. http://www. afahc.ro>rețele-note-curs.

18