Arhitecturi de Re țea și Internet 1 [608307]

Arhitecturi de Re țea și Internet 1

CAP. 3 NIVELUL TRANSPORT

Protocoalele de transport furnizeaz ă proceselor de aplica ții servicii de transfer date cap
la cap. Sunt definite dou ă protocoale la acest nivel: TCP (Transmission Control Protocol) și
UDP (User Datagram Protocol).
3.1 PORTURI ȘI SOCKET-URI
În cadrul acestui paragraf se introduc no țiunile de port și socket , necesare pentru
identificarea procesului local, care ruleaz ă într-un anumit sistem, precum și pentru
identificarea procesului corespondent, din sistemul distant, care comunic ă cu primul prin
intermediul unui anumit protocol. Toate aceste elemente implicate în comunica ție, sistemele
local și distant, procesele care lucreaz ă local și distant, precum și protocolul de comunica ție
trebuie identificate prin intermediul acestor mecanisme, dup ă cum urmeaz ă:
– Unui proces de aplica ție i se asociaz ă un num ăr de identificare (ID proces), care este
de preferat s ă fie diferit pentru fiecare ini țializare a procesului;
– ID-urile de proces difer ă pentru sisteme de operare diferite. Prin urmare, ace ști
identificare nu este uniform ă;
– Un proces server poate avea conexiuni multiple cu mai mul ți clien ți în acela și timp.
Prin urmare, identificatorii de conexiune nu sunt unici.

Conceptul utiliz ării de porturi și socket-uri ofer ă posibilitatea identific ării în mod
uniform și unic a conexiunilor, programelor și sistemelor implicate în comunica ție,
independent de identificatorii proceselor respective.

3.1.1 Porturi
Fiecare proces care necesit ă comunicarea cu un alt proces se identific ă în cadrul unei
stive TCP/IP printr-un port sau mai multe. Un ID port este un num ăr reprezentat pe 16 bi ți
utilizat de c ătre un protocol cap ăt la cap ăt pentru a identifica c ărui protocol de nivel superior
sau program (proces) de aplica ție trebuie s ă-i livreze mesajele recep ționate. Exist ă dou ă tipuri
de porturi:
– Porturi consacrate : aceste porturi apar țin unor servere standard, cum ar fi serverul
Telnet care folose ște portul 23. Numerele asociate porturilor consacrate apar țin
intervalului de la 1 la 1023. De obicei, numerele porturilor consacrate sunt impare,
deoarece în sistemele ini țiale, când s-au introdus aceste porturi, se impunea utilizarea
unei perechi num ăr impar-num ăr par pentru porturile implicate în transferuri
bidirec ționale. Cele mai multe servere necesit ă numai un singur port. Excep ție fac
serverul BOOTP, care folose ște dou ă porturi (67 și 68) și serverul FTP, care folose ște
dou ă porturi (20 și 21). Porturile consacrate sunt controlate și alocate de c ătre
Autoritatea de Asociere a Numerelor în Internet, IANA (Internet Assigned Number Authority) și în cele mai multe sisteme nu pot fi alocate decât proceselor sistem sau
programelor executate de utilizatorii cu drepturi speciale. Porturile consacrate permit clien ților s ă găseasc ă serverele f ără a necesita informa ții de configurare suplimentare.

– Porturi temporare : unii clien ți nu necesit ă numere de porturi consacrate deoarece
aceștia ini țiază comunica țiile cu serverele, iar num ărul portului utilizat de fiecare

3. Nivelul Transport 2
dintre clien ți este con ținut în mesajul UDP/TCP transmis c ătre server. Fiec ărui proces
client i se asociaz ă un num ăr de port, de c ătre sistemul pe care acesta ruleaz ă, pentru
un interval de timp nedefinit, cât necesit ă procesul client s ă transfere datele. Numerele
porturilor temporare au valori mai mari decât 1023, uzual fiind în intervalul de la 1024
la 65535. Porturile temporare nu sunt controlate de IANA și pot fi utilizate în oricare
sistem, de c ătre orice program dezvoltat de c ătre utilizator. Confuziile posibile care
pot apare atunci când dou ă aplica ții diferite încearc ă să utilizeze acelea și numere de
porturi, într-un acela și sistem, se pot evita prin configurarea acelor aplica ții să solicite
un port disponibil în stiva local ă TCP/IP. Deoarece num ărul de port este alocat
dinamic, acesta poate fi diferit de la o cerere la alta a aplica ției. Protocoalele de nivel
transport UDP, TCP și ISO TP-4 utilizeaz ă acela și principiu de identificare a
porturilor. Aproximativ acelea și numere de porturi sunt utilizate pentru identificarea
aplica țiilor care ofer ă acelea și servicii în stivele cu UDP, TCP și ISO TP-4.

Observa ție: În mod uzual, un server folose ște fie TCP, fie UDP, dar exist ă și excep ții. Spre
exemplu, aplica ția sistem de nume pentru domenii, DNS (Domain Name System) utilizeaz ă
atât portul 53 al UDP, cât și portul 53 al TCP.

3.1.2 Socket-uri
Interfa ța de tip socket reprezint ă una dintre interfe țele de programare a aplica ției, API
(Application Programming Interfaces) cu protocoalele de comunica ție. Destinate pentru a
reprezenta interfe țele de programare pentru comunica ții, socketurile API au fost introduse
pentru prima data în versiunea Unix BSD 4.2 (Berkeley Software Distribution). De și nu sunt
standardizate socketurile API BSD au devenit un standard implicit pentru implementarea
socketurilor re țelelor TCP/IP.
Se definesc urm ătorii termeni:
– Un socket reprezint ă un tip special de identificator de fi șier, care este utilizat de un
proces pentru a solicita serviciile de re țea de la un sistem de operare;
– Adresa unui socket este reprezentat ă de tripletul: <protocol, adres ă local ă, port local>.
Spre exemplu, în versiunea 4 a stivei TCP/IP se utilizeaz ă urm ătoarea adres ă a
socketului: <tcp, 192.168.14.234, 8080>;
– O conversa ție reprezint ă o leg ătură de comunica ție dintre dou ă procese;
– O asociere reprezint ă cvintetul care specific ă complet cele dou ă procese ce realizeaz ă
o conexiune: <protocol, adres ă local ă, port local, adres ă distant ă, port distant>. Spre
exemplu, în versiunea 4 a stivei TCP/IP se utilizeaz ă urm ătoarea asociere: <tcp,
192.168.14.234, 1500, 192.168.44, 22>;
– O semiasociere reprezint ă una dintre urm ătoarele dou ă triplete, care specific ă numai
jum ătate de conexiune: <protocol, adres ă local ă, port local> sau <protocol, adres ă
distant ă, port distant>. Semiasocierea este deasemenea numit ă socket sau adres ă de
transport . Prin urmare un socket este un cap ăt al conexiunii de comunica ție, care poate
fi denumit sau adresat într-o re țea.

Dou ă procese comunic ă prin socketuri TCP. Modelul de socket ofer ă unui proces o
conexiune duplex-simultan sub form ă de flux de octe ți, cu un alt proces. Aplica ția nu trebuie
să se ocupe cu administrarea acestui flux de octe ți, deoarece aceste facilit ăți sunt furnizate de
TCP.
TCP utilizeaz ă acela și principiu de administrare a porturilor ca și UDP pentru a realiza
multiplexarea de fluxuri. Ca și UDP, TCP utilizeaz ă porturile consacrate și temporare. Fiecare
cap ăt al unei conexiuni TCP are un socket care poate fi identificat prin tripletul <TCP, adres ă
IP, num ăr port>. Dac ă dou ă procese comunic ă peste TCP, atunci acestea au la dispozi ție o

Arhitecturi de Re țea și Internet 3
conexiune logic ă care este identificat ă unic de c ătre cele dou ă socketuri implicate, mai exact
de combina ția <TCP, adres ă IP local ă, port local, adres ă IP distant ă, port distant>. Procesele
de tip server pot controla mai multe conexiuni simultane prin intermediul aceluia și port.

3.2 PROTOCOLUL UDP
Este un protocol simplu care, folosind IP pentru transportul pachetelor, permite
identificarea nu numai a sistemelor surs ă și destina ție, prin adresele lor de re țea, ci și a
programelor de aplica ție între care se realizeaz ă transferul de informa ție. Sistemele de operare
ale majorit ății calculatoarelor permit executarea simultan ă a mai multor programe de aplica ție
așa încât, în fapt, destinatarul final pentru un mesaj transmis prin re țea este un anumit proces
(program de aplica ție) dintre toate cele care se execut ă simultan pe un sistem de calcul.
Pentru a se face distinc ție între multiplele programe ce se execut ă pe un acela și sistem,
UDP utilizeaz ă porturi de protocol , fiecare port fiind identificat printr-un num ăr, așa a fost
ilustrat în paragraful anterior.
Serviciul furnizat de UDP este un serviciu f ără conexiune, nefiabil, utilizatorii acestui
serviciu (programele de aplica ție) trebuind s ă aib ă în vedere c ă pot avea loc pierderi de
mesaje, duplic ări, livrarea mesajelor la destina ție într-o ordine diferit ă de cea în care au fost
emise. Dac ă este necesar, aceste func ții de cre ștere a calit ății serviciilor vor fi implementate la
nivelul aplica ție. UDP apare în aproximativ toate implement ările stivei Internet și este dedicat
transferului de unit ăți de date pentru aplica ții care pot admite pierderea unei cantit ăți mici de
date (cum ar fi fluxurile multimedia). UDP este doar o interfa ță de aplica ție pentru IP și nu serve ște decât pentru
multiplexarea/demultiplexarea fluxurilor de aplica ție, transmiterea și recep ționarea
datagramelor, utilizarea porturilor pentru redirectarea datagramelor. În figura 3.1 este ilustrat
mecanismul de multiplexare/demultiplexare pe baz ă de porturi, folosit de UDP.

Fig. 3. 1 Demultiplexarea UDP pe baz ă de porturi.
Aplica țiile care transmit datagrame c ătre un sistem trebuie s ă identifice o destina ție
care nu este specificat ă numai de adresa IP, deoarece datagramele sunt transmise c ătre un
anumit proces care ruleaz ă într-un sistem și nu întregului sistem. UDP permite acest lucru prin
intermediul porturilor.

3. Nivelul Transport 4
3.2.1. Formatul datagramei UDP
Fiecare mesaj UDP este numit pachet de utilizator (user datagram) pentru a-l distinge
de pachetul IP (IP datagram). Formatul mesajului UDP este prezentat în figura 3.2. Mesajul
UDP se compune dintr-un antet relativ redus (8 octe ți) și câmpul de date. Antetul precizeaz ă
porturile de protocol ale sursei și destina ției între care se face transferul mesajului, lungimea
total ă a mesajului UDP (inclusiv antetul) m ăsurat ă în octe ți.
Fiecare datagram ă UDP este transmis ă într-o singur ă datagram ă IP. Totu și, datagrama
IP poate fi fragmentat ă pe durata transmisiunii, dar la recep ție nivelul IP va reasambla
datagramele IP înainte de a oferi datele nivelului UDP. Toate implement ările IP accept ă
datagrame IP de 576 octe ți, ceea ce înseamn ă că dac ă se consider ă dimensiunea maxim ă a
antetului IP, de 60 de octe ți, atunci rezult ă o datagram ă UDP de 516 octe ți. Multe
implement ări accept ă datagrame de dimensiuni mai mari, dar acest lucru nu este garantat.

Fig. 3.2 Formatul mesajului UDP.

Specificarea portului surs ă este op țional ă. Acest port va fi utilizat ca port destina ție
pentru datagramele de r ăspuns. Dac ă nu se specific ă acest port câmpul respectiv din antet se
completeaz ă cu bi ți 0. Este op țional ă, de asemenea, și utilizarea secven ței de verificare care,
în caz c ă se folose ște, ia în considerare nu numai antetul (ca la IP) ci și câmpul de date.
Lungimea mesajului UDP este calculat ă în num ăr de octe ți și include antetul.
Secven ța de verificare se calculeaz ă pe un câmp mai mare decât cel ce corespunde
mesajului UDP. Pentru a crea posibilitatea de a verifica la recep ție c ă mesajul UDP a ajuns la
destina ția corect ă, secven ța de verificare se calculeaz ă pentru un ansamblu format din mesajul
UDP și antetul s ău precedate de un pseudoantet care con ține adresele de re țea ale sursei și
destina ției, protocolul și lungimea mesajului UDP. Acest pseudoantet nu se transmite dar la
recep ție protocolul UDP calculeaz ă secven ța de verificare pe baza mesajului UDP recep ționat
și a adreselor surs ă și destina ție, disponibile în antetul pachetului IP care a transportat mesajul
respectiv. Dac ă secven ța asfel calculat ă coincide cu cea din mesajul UDP rezult ă că mesajul a
ajuns la destina ția (sistem și port) desemnat ă de surs ă. Formatul pseudoantetului IP este
ilustrat în figura 3.3.

Fig. 3.3 Formatul pseudoantetului IP.

Arhitecturi de Re țea și Internet 5
Pseudoantetul IP este utilizat pentru a extinde calculul sumei de verificare pentru a
include și datagrama IP original ă (nefragmentat ă).
Figura 3.4 prezint ă pozi ția mesajului UDP în pachetul IP. Secven ța de verificare este
calculat ă pe 16 bi ți în complement fa ță de 1.

Fig. 3.4 Pozi ția mesajului UDP în pachetul IP.

3.2.2 Interfa ța de programare a aplica ției oferit ă de UDP
Interfa ța de aplica ție oferit ă de UDP permite urm ătoarele opera ții:
– Crearea de porturi noi pentru recep ție;
– Opera ția de recep ție care asigur ă livrarea unit ăților de date de aplica ție, indicarea
portului surs ă și a adresei IP surs ă;
– Opera ția de emisie, care are ca parametri datele, porturile surs ă și destina ție și adresele
IP;

Modul în care se implementeaz ă aceast ă interfa ță este l ăsat la latitudinea fiec ărui
produc ător.
Aplica țiile standard care utilizeaz ă UDP sunt urm ătoarele:
– Protocolul de transfer de fi șiere simplificat, TFTP (Trivial File Transfer Protocol);
– Serverul de nume pentru sistemul de nume pentru domenii, DNS (Domain Name
System);
– Procedura de apelare la distan ță, RPC (Remote Procedure Call), folosit ă de sistemul
de fi șiere pentru re țea, NFS (Network File System);
– Protocolul de administrare simpl ă a re țelei, SNMP (Simple Network Management
Protocol);

3.3 PROTOCOLUL TCP
Protocolul TCP, operând la nivelul transport, asigur ă un serviciu cu conexiune fiabil,
cu livrarea mesajelor la recep ție în ordinea în care au fost emise. Cele mai multe protocoale
de aplica ție utilizeaz ă T C P , c u m a r f i T e l n e t s a u F T P . C e l e d o u ă procese comunic ă prin
intermediul unei conexiuni TCP denumit ă conexiune de comunicare între procese, IPC
(InterProcess Communication) a șa cum se ilustreaz ă în figura 3.5. În acest exemplu din figura
3.5, procesele 1 și 2 comunic ă prin intermediul unei conexiuni TCP “purtat ă” de datagrame
IP.

3. Nivelul Transport 6

Fig. 3.5 Comunica ția TCP bazat ă pe conexiune.

3.3.1 Formatul segmentului TCP
Mesajele transferate la nivelul transport între dou ă sisteme prin protocolul TCP, se
numesc segmente . Formatul unui segment este prezentat în figura 3.6. Fiecare segment se
compune dintr-un antet urmat de date. Antetul con ține informa ție de identificare și informa ție
de control. Primele dou ă câmpuri, port surs ă și port destina ție, con țin numerele porturilor TCP
ce identific ă cele dou ă programe de aplica ție de la capetele conexiunii.
Num ărul de secven ță reprezint ă num ărul de ordine, în secven ță, al primului octet din
câmpul de date. Dac ă bitul de control SYN este fixat la valoarea 1, atunci num ărul de
secven ță reprezint ă num ărul ini țial de secven ță (n), iar primul octet de date este n+1.
Num ărul confirmat reprezint ă num ărul de secven ță al octetului de date ce se a șteapt ă a
fi recep ționat. Dac ă bitul de control ACK este fixat la valoarea 1, acest câmp con ține valoarea
num ărului de secven ță urm ător care se a șteapt ă a fi recep ționat.
Trebuie remarcat c ă num ărul de secven ță se refer ă la fluxul datelor ce se transmit în
acela și sens cu segmentul respectiv, iar num ărul confirmat se refer ă la fluxul datelor transmise
în sens invers. Lungimea antetului se exprim ă printr-un întreg care reprezint ă num ărul cuvintelor de
32 bi ți din care este constituit antetul. Este necesar s ă se indice lungimea antetului deoarece
lungimea câmpului rezervat pentru specificarea op țiunilor este variabil ă.

Fig. 3.6 Formatul unui segment TCP.

Arhitecturi de Re țea și Internet 7

Exist ă mai multe tipuri de segmente, func ție de scopul în care sunt folosite: transfer
date, stabilire conexiune, eliberare conexiune, numai pentru confirm ări (f ără transfer date),
transfer date în regim de urgen ță etc. Specificarea tipului de segment se face prin bi ții nota ți
U, A, P, R, S și F. Ace ști bi ți au urm ătoarele semnifica ții:
– U (URG) – specific ă semnifica ția important ă a câmpului de pointer urgent în cadrul
acestui segment;
– A (ACK) – specific ă semnifica ția important ă a câmpului de confirmare în cadrul
acestui segment;
– P (PSH) – Func ția de for țare (push) a segmentelor. În unele situa ții, o aplica ție trebuie
să fie informat ă că toate datele transferate la nivelul TCP au fost transmise c ătre
destina ție. Din acest motiv s-a introdus func ția de for țare a transmisiei segmentelor
TCP r ămase înc ă în unit ățile de memorie, c ătre sistemul destina ție. Închiderea normal ă
a conexiunii va determina deasemenea for țarea datelor c ătre destina ție;
– R (RST) – Resetarea conexiunii;
– S (SYN) – Sincronizeaz ă numerele de secven ță;
– F (FIN) – Oprirea transferului de date de la emi țător.
Câmpul “pointer urgent” indic ă pozi ția datelor care se transmit în regim de urgen ță în
fluxul general al datelor. În câmpul “fereastr ă” se specific ă num ărul de octe ți, începând cu cel men ționat în
câmpul de confirmare, pe care transmi țătorul îi poate accepta (pe sensul invers de
transmisiune).
Secven ța de verificare este folosit ă pentru a verifica integritatea întregului segment
(antet și date) dar, ca și în cazul protocolului UDP, pentru a da posibilitatea receptorului s ă
verifice c ă segmentul a ajuns la adresa de destina ție corect ă, se utilizeaz ă și un pseudoantet
având formatul din figura 3.7. Pseudoantetul nu se transmite, nu face deci parte din segment, dar se ata șează segmentului numai pentru calculul secven ței de verificare. El con ține adresele
de re țea (IP) ale sursei și destina ției, identificatorul protocolului și lungimea total ă a
segmentului TCP, inclusiv antetul TCP. Identificatorul protocolului este reprezentat de valoarea trecut ă în câmpul rezervat tipului de protocol din formatul utilizat de nivelul imediat
inferior. Pentru pachetele IP care transport ă segmente TCP aceast ă valoare este 6.

Fig. 3.7. Formatul pseudoantetului.

Protocolul TCP folose ște câmpul “op țiuni” pentru negocieri între cele dou ă capete ale
conexiunii. Printre altele, prin aceste negocieri i se permite receptorului s ă specifice
dimensiunea maxim ă a segmentelor pe care el o poate suporta, aspect foarte important, spre
exemplu, atunci când un mic calculator personal, cu o capacitate a memoriei tampon de câteva sute de octe ți, este conectat la un supercalculator.
Ca și în cazul op țiunilor datagramelor IP, op țiunile pentru segmentul TCP pot fi
specificate prin una din metodele:
– un singur octet care con ține num ărul op țiunii;

3. Nivelul Transport 8
– opțiuni de lungime variabil ă cu formatul din figura 3.8.

Fig. 3.8. Formatul op țiunilor TCP de lungime variabil ă.
Exist ă șapte op țiuni posibile pentru segmentele TCP, care sunt prezentate în tabelul 3.1:

Tip op țiune Lungime (octe ți) Semnifica ție
0 – Sfâr șitul listei de op țiuni
1 – F ără opera ții
2 4 Dimensiunea maxim ă a
segmentului
3 3 Ajustarea ferestrei
4 2 Permiterea SACK.
5 X SACK
8 10 Etichete temporale

Tab. 3. 1. Op țiunile segmentului TCP
Aceste op țiuni vor fi descrise în continuare.
Opțiunea de specificare a dimensiunii maxime a segmentului. Aceast ă op țiune este
utilizat ă numai pe durata stabilirii conexiunii (bitul de control SYN fiind setat) și cererea este
transmis ă de c ătre cap ătul care urmeaz ă să recep ționeze datele, pentru a indica lungimea
maxim ă a segmentului pe care acest sistem o poate suporta. Dac ă aceast ă op țiune nu este
utilizat ă atunci este permis ă orice dimensiune a segmentului.
În ceea ce prive ște dimensiunea segmentelor, teoretic valoarea optim ă a acesteia este
determinat ă de dimensiunea maxim ă admis ă de re țea pentru pachetele IP, pe calea de la surs ă
la destina ție, a șa încât s ă nu fie necesar ă fragmentarea segmentelor. Fragmentarea
segmentelor conduce la formarea de pachete ce corespund aceluia și segment dar care sunt în
mod independent tratate de re țea. Toate fragmentele trebuie s ă ajung ă la destina ție, altfel
trebuie s ă se retransmit ă întreg segmentul. Deoarece probabilitatea de pierdere ( și rejectare) a
unui fragment (pachet IP) nu este zero, cre șterea dimensiunii segmentului peste pragul de
fragmentare conduce la multiplicarea situa țiilor în care este necesar ă retransmiterea
segmentelor. Desigur, segmentele retransmise pot avea dimensiuni diferite în raport cu cele
inițiale, acesta fiind un motiv suplimentar pentru care în TCP confirmarea se face nu la nivel
de segment ci la nivel de octet. Opțiunea de ajustare a ferestrei. Ambele capete ale conexiunii trebuie s ă transmit ă opțiunea
de scalare a ferestrei în cadrul segmentelor SYN pentru a permite ajustarea dimensiunii ferestrei în sensul de transmisie. Transmiterea acestei op țiuni extinde dimensiunea ferestrei
TCP la o reprezentare pe 32 de bi ți. Dimensiunea ferestrei reprezentat ă pe 32 de bi ți este
definit ă prin intermediul unui factor de scalare (transmis în segmentul SYN) fa ță de fereastra
standard reprezentat ă pe 16 bi ți. Receptorul acestui mesaj modific ă dimensiunea ferestrei de
la valoarea standard pe 16 bi ți prin ad ăugarea factorului de scalare. Aceast ă opțiune poate fi
utilizat ă numai în faza de ini țializare a conexiunii. Astfel, dimensiunea ferestrei nu se mai
poate schimba pe toat ă durata men ținerii conexiunii.

Arhitecturi de Re țea și Internet 9

Opțiunea de permitere a SACK. Aceast ă op țiune este introdus ă numai atunci când pe
conexiunea TCP respectiv ă se utilizeaz ă confirm ări selective (SACK – Selective
ACKnowledgement). Pentru aceast ă op țiune câmpul de date op țiune nu este utilizat (se
transmit numai tipul op țiunii și lungimea)
Opțiunea SACK. Confirmarea selectiv ă SACK permite receptorului s ă informeze
transmi țătorul asupra tuturor segmentelor recep ționate corect. Astfel, transmi țătorul va
retransmite numai segmentele pierdute. În cazul în care num ărul de segmente pierdute,
înregistrat de la ultimul SACK transmis, este foarte mare atunci și dimensiunea op țiunilor
SACK va fi foarte mare. Din acest motiv num ărul de blocuri de segmente care pot fi raportate
de c ătre o op țiune SACK este limitat la patru. În figura 3.9 este ilustrat formatul op țiunii
SACK.

Fig. 3.9. Formatul op țiunii SACK.
Opțiunea etichetelor temporale (TS). Aceast ă op țiune transmite o valoare a etichetei
temporale TS (Time Stamp) care specific ă valoarea curent ă a timpului indicat de ceasul local
de la transmi țător. Valoarea “TS ecou” este utilizat ă dac ă bitul ACK este setat cu 1 logic în
antetul TCP. În figura 3.10 este ilustrat formatul op țiunii TS.

Fig. 3. 10. Formatul op țiunii etichet ă temporal ă.

3.3.2 Stabilirea conexiunilor TCP
Înainte de a începe transferul datelor între cele dou ă procese de utilizator (programe de
aplica ție) se stabile ște, prin intermediul re țelei, o conexiune logic ă numit ă circuit virtual . În
acest scop programele de aplica ție transmi țător și receptor interac ționeaz ă cu sistemele de
operare re țea din sistemele respective. Un program aplica ție realizeaz ă un apel, care trebuie s ă
fie acceptat de c ătre cel ălalt program aplica ție. Cele dou ă sisteme de operare, prin modulele
destinate protocolului de comunica ție, î și transmit mesaje prin re țea pentru a verifica dac ă

3. Nivelul Transport 10
transferul este autorizat (acceptat) și dac ă ambele p ărți sunt gata pentru acest transfer.
Conexiunea fiind stabilit ă, cele dou ă programe de aplica ție sunt informate c ă transferul
datelor poate s ă înceap ă. Programul de aplica ție transmi țător transfer ă datele spre nivelul
transport sub forma unui flux de bi ți, împ ărțit în octe ți. Acela și flux, în aceea și ordine a
octe ților, este primit de programul de aplica ție în sistemul de destina ție.
La nivelul transport fluxul octe ților primi ți de la programe de aplica ție este împ ărțit în
segmente , care sunt apoi transmise în re țea spre destina ție. Fiecare segment, format dintr-un
num ăr oarecare de octe ți, este transportat în re țea de un pachet IP. Conexiunile asigurate de
TCP/IP la acest nivel sunt conexiuni duplex , ceea ce înseamn ă că cele dou ă procese î și pot
transmite date simultan unul c ătre cel ălalt. Un avantaj al acestei conexiuni duplex const ă în
faptul c ă se poate transmite informa ția de control (al erorii, al fluxului) înapoi c ătre surs ă în
pachete ce transfer ă datele în sens opus, reducându-se astfel traficul în re țea (metoda piggy-
back ). Pentru controlul fluxului și al erorii se utilizeaz ă temporizatoare la emisie și confirm ări
pozitive la recep ție, ACK (Positive acknowledgement). Atunci când se transmite un segment
cu un anumit num ăr de secven ță se porne ște la emisie un temporizator. Dac ă pân ă expir ă
temporizatorul nu sose ște o confirmare ACK, atunci segmentul este retransmis automat.
Deoarece protocolul TCP ofer ă un serviciu cu conexiune, conexiunea ce se stabile ște
pentru transferul datelor este identificat ă printr-o pereche de puncte de cap ăt (porturi de
protocol). În felul acesta, acela și port de protocol poate fi simultan cap ăt al mai multor
conexiuni. Spre exemplu, un sistem poate permite accesul concuren țial la serviciul s ău de
poștă electronic ă, acceptând pe un acela și port de protocol mesajele transmise simultan de la
mai multe calculatoare, cu fiecare dintre acestea având stabilit ă o alt ă conexiune, identificat ă
distinct de celelalte. Protocolul TCP realizeaz ă multiplexarea conexiunilor pe baza numerelor
porturilor, a șa cum se realizeaz ă și la UDP.
Pentru stabilirea conexiunii, un proces (serverul, de obicei) transmite o cerere de deschidere pasiv ă a conexiunii (passive OPEN), iar cel ălalt proces transmite o cerere activ ă
(active OPEN). Cererea pasiv ă nu este luat ă în considerare pân ă când cel ălalt proces nu
încearc ă să se conecteze la primul printr-o cerere activ ă. În figura 3.11 este ilustrat faptul c ă
pentru stabilirea conexiunii este necesar s ă se fac ă un schimb de trei segmente TCP între cele
dou ă procese.

Fig. 3. 11. Stabilirea conexiunii TCP.
Aceast ă procedur ă de stabilire a conexiunii este cunoscut ă sub numele de “three-way
handshake”. Se poate observa din figura 3.11 c ă segmentele TCP schimbate la stabilirea
conexiunii include și valorile ini țiale ale numerelor de secven ță de la ambele capete, care vor
fi utilizate pentru urm ătoarele transmisii de date. Astfel, sincronizarea numerelor de secven ță
se realizeaz ă odat ă cu stabilirea conexiunii.
Închiderea unei conexiuni se realizeaz ă prin transmiterea unui segment TCP care are
bitul FIN (nu mai urmeaz ă alte date) setat cu 1. Deoarece conexiunea este bidirec țional ă
simultan (full-duplex) atunci segmentul FIN încheie transmisiunea datelor numai pentru un
sens al conexiunii. Cel ălalt proces va transmite datele r ămase și va încheia transmisiunea la

Arhitecturi de Re țea și Internet 11
rândul s ău cu un segment TCP care are bitul FIN setat cu 1. O conexiune se consider ă a fi
închis ă numai atunci se încheie transmisiunea în ambele sensuri.
Diferitele st ări ale unei conexiuni TCP sunt enumerate în continuare:
– LISTEN: A șteptarea unei cereri de conexiune de la un alt nivel TCP;
– SYN-SENT: S-a transmis un segment de sincronizare SYN, iar TCP a șteapt ă un
segment SYN de r ăspuns;
– SYN-RECEIVED: S-a recep ționat un segment SYN, s-a transmis un segment SYN,
iar TCP a șteapt ă un segment de confirmare ACK;
– ESTABLISHED: Schimbul celor trei mesaje de stabilire a conexiunii s-a încheiat;
– FIN-WAIT-1: Aplica ția local ă a emis o cerere de închidere CLOSE. TCP a transmis
FIN și așteapt ă un ACK sau un FIN;
– FIN-WAIT-2: S-a transmis un FIN și s-a recep ționat un ACK. TCP a șteapt ă un FIN de
la nivelul TCP corespondent;
– CLOSE-WAIT: TCP a recep ționat un FIN și a transmis un ACK. Nivelul TCP
așteapt ă o cerere ce închidere de la aplica ția local ă înainte de a transmite FIN;
– CLOSING: S-a transmis un FIN, s-a recep ționat un FIN și s-a transmis un ACK. TCP
așteapt ă un ACK pentru segmentul FIN pe care l-a transmis;
– LAST-ACK: S-a recep ționat un FIN și un ACK, iar un segment FIN a fost transmis.
TCP a șteapt ă un ACK;
– TIME-WAIT: FIN a fost recep ționat și confirmat cu ACK, iar TCP a șteapt ă dou ă
MSL pentru a șterge conexiunea din tabel ă;
– CLOSED: Indic ă faptul c ă o conexiune a fost eliminat ă din tabela de conexiuni.

3.3.3 Controlul fluxului și al erorii cu fereastra glisant ă
Livrarea la destina ție a fluxului de octe ți în ordinea în care ace știa au fost emi și, fără
pierderi și fără duplicate, se asigur ă prin folosirea unei tehnici de confirmare pozitiv ă cu
retransmitere, combinat ă cu fereastr ă glisant ă. Mecanismul ferestrei glisante utilizat de TCP,
operând la nivelul octe ților și nu al segmentelor, permite atât o transmisiune eficient ă, cât și
un control al fluxului. Octe ții din fluxul datelor primite de la programul aplica ție sunt numerota ți în ordine.
Transmi țătorul, s ă-l not ăm A, emite continuu segmente, formate cu ace ști octe ți, către cel ălalt
cap ăt al conexiunii, s ă-l not ăm B, urm ărind în acela și timp confirm ările venite în sens invers
în chiar segmentele de date transmise de B c ătre A. O confirmare venit ă de la cap ătul B
specific ă num ărul de ordine (de secven ță) al primului octet din segmentul pe care acesta
(cap ătul B) îl a șteapt ă, ceea ce înseamn ă, implicit, o confirmare pentru recep ția tuturor
octe ților anteriori transmi și de A. Numerele de ordine ale octe ților pe care îi poate emite
transmi țătorul f ără a avea confirmarea de recep ție a lor sunt specificate de fereastra glisant ă
(figura 3.12).

Fig. 3. 12 Fereastr ă glisant ă.

Pentru o conexiune transmi țătorul aloc ă trei num ărătoare (N 1, N2, N 3) care vor preciza
în orice moment pozi ția ferestrei glisante. Num ărătorul N 1 marcheaz ă începutul ferestrei
glisante (limita inferioar ă), separând octe ții emi și și pentru care s-au primit confirm ările de

3. Nivelul Transport 12
recep ție de cei pentru care nu s-au primit confirm ări. Num ărătorul N 3 indic ă sfâr șitul ferestrei
(limita superioar ă), adic ă num ărul de ordine al ultimului octet ce poate fi inclus într-un
segment ce urmeaz ă a fi transmis f ără să mai vin ă vreo confirmare de recep ție. Num ărătorul
N2 marcheaz ă în interiorul ferestrei limita ce separ ă octe ții deja transmi și de cei înc ă
netransmi și.
Deasemenea, receptorul va folosi o fereastr ă asem ănătoare pentru a reconstitui fluxul
octe ților emi și. În acela și timp, având în vedere c ă protocolul TCP stabile ște conexiuni duplex
și că pe fiecare sens de transmisiune se utilizeaz ă câte o fereastr ă de emisie și una de recep ție,
rezult ă că în fiecare cap ăt al conexiunii vor exista dou ă ferestre, una glisând pe fluxul datelor
ce se emit iar cealalt ă pe fluxul datelor ce se recep ționeaz ă.
Protocolul TCP permite modificarea dimensiunii ferestrei glisante pentru a reliza un control al fluxului. Fiecare confirmare, pe lâng ă specificarea num ărului de octe ți recep ționa ți
(în ordine), con ține și o indica ție privind num ărul de octe ți pe care receptorul îi poate accepta,
dependent de m ărimea spa țiului liber din memoria tampon a acestuia. Transmi țătorul î și va
modifica dimensiunea ferestrei de emisie corespunz ător acestei indica ții a receptorului, ceea
ce va conduce și la cre șterea eficien ței transmisiei prin reducerea sim țitoare a num ărului
pachetelor pierdute, rejectate de receptor și, în consecin ță, reducerea și a num ărului
retransmiterilor. În figura 3.13 se ilustreaz ă un exemplu de transmisie TCP unde dimensiunea ferestrei
este de 1500 octe ți și se utilizeaz ă segmente de 500 de octe ți. În acest exemplu, apare o
problem ă deoarece transmi țătorul a aflat c ă segmentul 2 s-a pierdut sau s-a recep ționat cu
erori, dar nu știe nimic despre segmentele 3 și 4. Transmi țătorul ar trebui s ă retransmit ă
segmentele 3 și 4, deoarece acestea se afl ă înc ă în fereastra curent ă. Referitor la aceast ă
situa ție, exist ă dou ă scenarii posibile:
– segmentul 3 a fost recep ționat corect și din acest moment nu se cunoa ște starea
recep ției segmentului 4. Este posibil ca și acesta s ă fi fost recep ționat corect, dar
confirmarea ACK nu a ajuns înc ă sau ACK s-a pierdut;
– segmentul 3 s-a pierdut și se transmi țătorul prime ște confirmarea ACK 1500 dup ă
transmiterea segmentului 4.

Fiecare implementare a TCP poate utiliza temporizatoare pentru a determina timpul
dup ă care se retransmite un segment, în cazul în care nu a sosit confirmarea. Dac ă în exemplul
din figura 3.13 se utilizeaz ă temporizator la emisie, atunci la expirarea timpului de a șteptare a
confirm ării segmentului 2, în primul scenariu se retransmite numai segmentul 2, dar în cel de-
al doilea scenariu se va a ștepta din nou expirarea temporizatorului pentru segmentul 3.
Indiferent de alegerea f ăcută eficien ța maxim ă a protocolului este pierdut ă deoarece
confirmarea nu con ține un al doilea num ăr de secven ță care s ă indice num ărul segmentului
recep ționat în momentul respectiv.
Timpul de a șteptare a confirm ărilor pentru octe ții con ținuți într-un segment emis este
limitat. Când acest timp expir ă fără a se primi confirmarea de recep ție, se presupune c ă
segmentul a fost eronat sau pierdut și se retransmite. Este evident c ă timpul de a șteptare
trebuie s ă depind ă de timpul necesar unui pachet s ă ajung ă la destina ție și de timpul necesar
pentru întoarcerea confirm ării. Ace ști timpi depind de leg ăturile de date parcurse (debit), de
întârzierea cu care sunt prelucrate pachetele în fiecare ruter, deci și de trafic și, prin urmare,
sunt variabili, pentru o aceea și conexiune, de la un moment la altul. Pentru a se adapta la
aceste întârzieri variabile introduse de re țea, protocolul TCP folose ște un algoritm de
retransmitere adaptiv prin care se regleaz ă permanent limita timpului de a șteptare a
confirm ărilor. Pentru a realiza acest lucru, TCP înregistreaz ă momentul transmiterii unui
anumit segment și momentul sosirii confirm ării pentru acesta. Se estimeaz ă o valoare medie a
acestui timp de propagare dus-întors (round trip time) pentru mai multe segmente transmise,

Arhitecturi de Re țea și Internet 13
care este utilizat ă pentru valoarea temporizatorului atunci când se transmite urm ătorul
segment.

Fig. 3. 13 Exemplu de transmisie TCP cu confirm ări și retransmisii.

3.3.4. Algoritmi de control al congestiei în TCP
O diferen ță esen țială dintre UDP și TCP este c ă TCP utilizeaz ă un algoritm de control
al congestiei. Algoritmul de control al congestiei în TCP previne situa ția în care
transmi țătorul ar dep ăși capacitatea de prelucrare a re țelei (spre exemplu, în cazul unor re țele
WAN lente). Astfel, TCP poate adapta debitul transmi țătorului în func ție de capacitatea
rețelei, astfel încât s ă se evite posibilele situa ții de congestie și deci, pierderea segmentelor.
Dealungul timpului s-au ad ăugat și s-au propus mai multe îmbun ătățiri ale TCP cu scopul de a
controla congestiile. Aceast ă căutare de algoritmi de evitare a congestiilor este înc ă o direc ție
de cercetare deschis ă, dar implement ările moderne ale TCP con țin patru algoritmi de baz ă
pentru Internet (de obicei utilizându-se variante combinate ale acestora):

– ini țializare lent ă;
– evitarea congestiei; – retransmisie rapid ă;
– recuperare rapid ă.
În continuare se descriu pe scurt ace ști patru algoritmi.
Inițializarea lent ă (Slow start). Implement ările TCP mai vechi deschide o conexiune prin
introducerea de la transmi țător a mai multor segmente în re țea, pân ă când se atinge
dimensiunea ferestrei anun țate de receptor. De și totul este în regul ă atunci când sistemele se
află în acela și LAN, atunci când exist ă ruteri între cele dou ă sisteme și se utilizeaz ă leg ături
lente atunci pot ap ărea probleme. Unii ruteri intermediari nu pot face fa ță situa ției și atunci

3. Nivelul Transport 14
pachetele se pierd, ceea ce determin ă apari ția retransmisiilor și deci, reducerea
performan țelor. Algoritmul utilizat pentru evitarea acestei situa ții poart ă numele de
inițializare lent ă. Acesta opereaz ă prin observarea faptului c ă rata cu care se introduc noi
pachete în re țea ar trebui s ă fie egal ă cu rata sosirii confirm ărilor de pe cel ălalt sens.
Inițializarea lent ă mai adaug ă o fereastr ă la nivelul TCP transmi țător: fereastra de congestie .
Atunci când se stabile ște o nou ă conexiune cu un sistem dintr-o alt ă rețea se ini țializeaz ă
fereastra de congestie cu dimensiunea de un segment (spre exemplu, dimensiunea segmentului anun țată de cel ălalt cap ăt sau implicit cu o valoare tipic ă de 536 sau 512). De
fiecare dat ă când se recep ționeaz ă un segment ACK dimensiunea ferestrei de congestie cre ște
cu un segment. Transmi țatorul poate transmite cea mai mic ă dimensiune a ferestrei de
congestie sau pe cea anun țată. Fereastra de congestie este impus ă de controlul de flux de la
transmi țător, în timp ce fereastra anun țată este impus ă de controlul de flux de la receptor.
Prima dintre acestea dou ă se bazeaz ă pe evaluarea f ăcută de c ătre transmi țător a congestiei
percepute în re țea, iar a doua este legat ă de num ărul de loca ții libere ale cozilor de a șteptare
de la recep ție, pentru aceast ă conexiune.
Transmi țătorul începe prin a transmite un segment și apoi a șteapt ă confirmarea ACK pentru
acesta. Atunci când sose ște confirmarea dimensiunea ferestrei de congestie este incrementat ă
de la unu la doi, iar apoi se pot transmite dou ă segmente. Atunci când ambele segmente sunt
confirmate, dimensiunea ferestrei de congestie se va incrementa la patru. Acest mecanism determin ă o cre ștere exponen țială a traficului, de și aceast ă cre ștere nu este tocmai
exponen țială deoarece receptorul trebuie s ă întârzie confirm ările sale, în mod uzual, prin
transmiterea unei ACK pentru fiecare dou ă segmente pe care le recep ționeaz ă. La un anumit
moment dat, capacitatea re țelei IP este atins ă, iar ruterul intermediar va începe s ă arunce
pachete. Acest lucru va specifica transmi țătorului c ă fereastra sa de congestie a devenit prea
mare. În figura 3.14 se ilustreaz ă algoritmul de ini țializare lent ă.

Fig. 3. 14 Exemplu de ini țializare lent ă pentru controlul congestiilor.

Arhitecturi de Re țea și Internet 15
Evitarea congestiei. Presupunerea care se face în cazul acestui algoritm este c ă pierderea
pachetelor cauzat ă de re țea este foarte mic ă (mult mai mic ă de 1%). Astfel, pierderea unui
pachet va determina semnalizarea congestiei undeva în re țea, între surs ă și destina ție. Exist ă
dou ă indicatoare ale pierderii unui pachet:
– expirarea unui temporizator;
– recep ționarea unor confirm ări ACK duplicat.
Evitarea congestiei și deschiderea lent ă sunt algortimi independen ți, care au obiective diferite.
Totu și, atunci când se produce o congestie, TCP va trebui s ă scad ă rata de transmisiune în
rețea a segmentelor și să utilizeze ini țializarea lent ă pentru a reporni transmisiunea. În practic ă
acești doi algoritmi sunt implementa ți împreun ă.
Evitarea congestiei și ini țializarea lent ă necesit ă men ținerea a dou ă variabile pentru fiecare
conexiune:
– o fereastr ă de congestie, notat ă cu cwnd ;
– un prag de ini țializare lent ă, notat cu ssthresh .
Algoritmul rezultat prin combinarea celor doi algoritmi de mai sus func ționeaz ă astfel:
1. Inițializarea unei anumite conexiuni presupune setarea cwnd cu valoarea de un
segment și ssthresh cu valoarea 65535 octe ți;
2. Rutina TCP de ie șire nu transmite niciodat ă mai mult decât valoarea cea mai mic ă
dintre cwnd și fereastra anun țată de receptor;
3. Atunci când se produce o congestie (expirare timp sau ACK duplicat), jum ătate din
dimensiunea ferestrei curente este salvat ă în ssthresh . În plus, dac ă aceea și congestie e
indicat ă de expirarea timpului, cwnd este setat la un segment;
4. Atunci când datele noi sunt confirmate de c ătre cel ălalt cap ăt se cre ște cwnd , dar
valoarea cu care cre ște aceasta depinde dac ă TCP realizeaz ă o ini țializare lent ă sau
evitarea congestiei. Dac ă cwnd este mai mic sau egal cu ssthresh , atunci TCP lucreaz ă
cu ini țializarea lent ă; în caz contrar, TCP ruleaz ă cu evitarea congestiei.
Se utilizeaz ă ini țializarea lent ă pân ă când se ajunge la jum ătate din valoarea la care
ajunsese când s-a produs congestia (deoarece a memorat jum ătate din dimensiunea
ferestrei care a cauzat problema, în pasul 3), iar apoi se comut ă pe modul de evitare a
congestiei. Ini țializarea lent ă începe cu cwnd având valoarea de un segment, iar apoi se
incrementeaz ă cu un segment la recep ționarea fiec ărei ACK. A șa cum s-a men ționat
anterior, fereastra cre ște exponen țial: se trimite un segment, apoi dou ă, apoi patru, etc.
Evitarea congestiei stabile ște ca cwnd să fie incrementat ă cu dim_segm* dim_segm /cwnd
de fiecare dat ă când se recep ționeaz ă o ACK, unde dim_segm reprezint ă dimensiunea
segmentului, iar cwnd se m ăsoar ă în octe ți. Aceasta este o cre ștere liniar ă a cwnd , prin
compara ție cu cre șterea exponen țială în cazul ini țializ ării lente. Cre șterea cwnd ar trebui
să fie cel mult cu un segment pentru fiecare interval de propagare dus-întors (indiferent
câte ACK sunt recep ționate în acest interval), în timp ce ini țializarea lent ă incrementeaz ă
cwnd cu num ărul de ACK recep ționare în acest interval de propagare dus-întors.
În figura 3.15 se ilustreaz ă cum lucreaz ă împreun ă algoritmul de ini țializare lent ă și cel de
evitare a congestiei.

3. Nivelul Transport 16

Fig. 3. 15 Exemplu de ini țializare lent ă pentru controlul congestiilor.

Retransmisie rapid ă. Algoritmul de retransmisie rapid ă evit ă ca TCP s ă aștepte expirarea
unui temporizator pentru a retransmite segmentele pierdute. În 1990 s-au propus ni ște
modific ări pentru algoritmul de evitare a congestiei. Înainte de a descrie modific ările f ăcute
trebuie f ăcută observa ția c ă TCP poate genera imediat o confirmare ACK duplicat atunci când
se recep ționeaz ă un segment care nu respect ă ordinea în secven ță. Aceast ă ACK duplicat nu
ar trebui întârziat ă. Scopul acestei ACK duplicat este de a informa cel ălalt cap ăt asupra
factului c ă un segment a fost recep ționat în afara ordinii din secven ță și să specifice care este
num ărul de secven ță așteptat.

Fig. 3. 16 Exemplu de retransmisie rapid ă pentru controlul congestiilor.

Deoarece TCP nu poate identifica dac ă o ACK duplicat este cauzat ă de pierderea unui
segment sau doar de o reordonare a segmentelor, acesta se va a ștepta s ă recep ționeze un
num ăr redus de confirm ări ACK duplicate. Se presupune c ă dac ă este doar cazul unei

Arhitecturi de Re țea și Internet 17
reordon ări a segmentelor, atunci se vor produce una sau dou ă ACK duplicate pân ă când va fi
procesat segmentul reordonat, care va genera și el o nou ă ACK. Dac ă se recep ționeaz ă trei sau
mai multe ACK duplicate în ordine, aceasta înseamn ă că un segent a fost pierdut. Atunci,
TCP va retransmite segmentele ce par s ă lipseasc ă, fără a mai a ștepta expirarea
temporizatorului de retransmisie. În figura 3.16 se ilustreaz ă algoritmul de retransmisie
rapid ă.
Recuperare rapid ă. Dup ă ce algoritmul de retransmisie rapid ă decide transmiterea
segmentului care aparent lipse ște, se utilizeaz ă algoritmul de evitare a congestiei; în nici un
caz, nu se va utiliza ini țializarea lent ă. Acesta este algoritmul cu numele de recuperare
rapid ă. Acesta determin ă o îmbun ătățire a performan țelor deoarece permite un debit mare în
condi ții de congestii moderate, în special pentru ferestre mari.
Motivul pentru care nu se utilizeaz ă algoritmul de ini țializare lent ă în acest caz este acela c ă
recep ția unor ACK duplicate informeaz ă TCP mai mult decât pierderea unui segment.
Deoarece receptorul poate genera un ACK duplicat numai dac ă un alt segment este
recep ționat, acel segment a fost scos din re țea și se afl ă în registrul receptorului. Astfel, în
acest moment mai exist ă date se ce propag ă între cele dou ă capete și este de dorit ca TCP s ă
nu reduc ă viteza brusc prin utilizarea ini țializ ării rapide. Algoritmii de retransmisie rapid ă și
recuperare rapid ă sunt de obicei implementa ți împreun ă, dup ă cum urmeaz ă:
1. Atunci când un al treilea ACK duplicat este recep ționat la rând se va seta ssthresh la
jum ătate din fereastra curent ă de congestie, cwnd , dar nu mai pu țin de dou ă segmente.
În continuare se va retransmite segmentul lips ă. Se seteaz ă cwnd cu valoarea din
ssthresh plus de trei ori dimensiunea segmentului. Aceast ă procedur ă conduce la
creșterea ferestrei de congestie cu num ărul de segmente care au fost scoase din re țea,
fiind memorate la cel ălalt cap ăt (în etapa 3).
2. De fiecare dat ă când sose ște un ACK duplicat se incrementeaz ă cwnd cu dimensiunea
segmentului. Aceast ă procedur ă conduce la cre șterea ferestrei de congestie cu
dimensiunea segmentului care a fost scos din re țea. Se transmite un segment dac ă
acest lucru este permis de noua valoare din cwnd .
3. Atunci când sose ște noua ACK care confirm ă noile date, se seteaz ă cwnd cu valoarea
din ssthresh (valoarea setat ă în etapa 1). Aceast ă ACK este confirmarea pentru
retransmisia din etapa 1, care sose ște dup ă un timp de propagare dus-întors de la acea
retransmisie. În plus, aceast ă ACK confirm ă toate segmentele transmise între timp,
între momentul pierderii segmentului și recep ția primei ACK duplicat. În aceast ă etap ă
se utilizeaz ă evitarea congestiei, deoarece TCP a sc ăzut viteza la jum ătate fa ță de
valoarea pe care o avea în momentul pierderii segmentului.