Retele Calculatoare-Curs 10 PDF

Reele de Calculatoare - Curs 10
Reele de Calculatoare
Curs 10
Obiective:
1. Servicii oferite de nivelul transport nivelurilor superioare.

2. Primitive ale serviciior de transport.
3. Nivelul transport adresarea, stabilirea conexiunii, eliberarea conexiunii,
controlul fluxului, multiplexarea, refacerea dup cdere.
4. Protocoale de transport prin Internet: UDP, TCP.
1. Nivelul transport
Nivelul transport nu este doar un alt nivel, el este miezul ntregii ierarhii de protocoale. Sarcina
sa este de a transporta date de la maina surs la maina destinaie ntr-o manier sigur i
eficace din punctul de vedere al costurilor, independent de reeaua sau reelele fizice utilizate.
Fr nivelul transport i-ar pierde sensul ntregul concept de ierarhie de protocoale.
1.1 Servicii oferite de nivelul transport

n seciunile urmtoare se va face o prezentare a serviciilor oferite de nivelul transport. Se vor
studia serviciile oferite nivelului aplicaie. Pentru a face problema serviciului de transport mai
concret, se vor examina dou seturi de primitive ale nivelului transport.
1.1.1
Servicii furnizate nivelurilor superioare
Scopul principal al nivelului transport este de a oferi servicii eficiente, sigure i ieftine
utilizatorilor, n mod normal procese aparinnd nivelului aplicaie. Pentru a atinge acest scop,
nivelul transport utilizeaz serviciile oferite de nivelul reea. Hardware-ul i/sau software-ul care
se ocup de toate acestea n cadrul nivelului transport poart numele de entitate de transport.
Entitatea de transport poate aparine nucleului sistemului de operare, unui proces distinct, unei
biblioteci legate de aplicaiile de reea sau poate fi gsit n cadrul plcii de reea. Relaia
(logic) ntre nivelurile reea, transport i aplicaie este prezentat n Figura 10-1.
Figura 10-1 Nivelurile reea, transport i aplicaie.

Cele dou tipuri de servicii: orientate pe conexiune sau datagram, existente n cadrul nivelului
reea, se regsesc i la acest nivel. Serviciul orientat pe conexiune de la nivelul transport are
multe asemnri cu cel de la nivel reea. n ambele cazuri, conexiunile au trei faze: stabilirea
conexiunii, transferul de date i eliberarea conexiunii. Adresarea i controlul fluxului sunt i ele
similare pentru ambele niveluri. Mai mult, chiar i serviciul fr conexiune al nivelului transport
este foarte asemntor cu cel al nivelului reea.
O ntrebare evident este atunci: dac serviciile la nivel transport sunt att de asemntoare cu
cele de la nivel reea, de ce este nevoie de dou niveluri distincte? De ce nu este suficient un
singur nivel? Codul pentru nivelul transport este executat n ntregime pe mainile utilizatorilor,
dar nivelul reea este executat n cea mai mare parte de mediul de transport (cel puin pentru
reelele larg rspndite geografic - WAN). Ce s-ar ntmpla dac nivelul reea ar oferi servicii
neadecvate? Dar dac acesta ar pierde frecvent pachete? Ce se ntmpl dac din cnd n
cnd ruterul cade?
n toate aceste cazuri apar probleme. Deoarece utilizatorii nu pot controla nivelul reea, ei nu
pot rezolva problema unor servicii de proast calitate folosind rutere mai bune sau adugnd o
tratare a erorilor mai sofisticat la nivelul legtur de date. Singura posibilitate este de a pune
deasupra nivelului reea un alt nivel care s amelioreze calitatea serviciilor. Dac pe o subreea
orientat pe conexiune, o entitate de transport este informat la jumtatea transmisiei c a fost
nchis abrupt conexiunea sa la nivel reea, fr nici o indicaie despre ceea ce s-a ntmplat cu
datele aflate n acel moment n tranzit, ea poate iniia o alt conexiune la nivel reea cu entitatea
de transport aflat la distan. Folosind aceast nou conexiune, ea i poate ntreba
corespondenta care date au ajuns la destinaie i care nu, i poate continua comunicarea din
locul de unde a fost ntrerupt.
n esen, existena nivelului transport face posibil ca serviciile de transport s fie mai sigure dect cele echivalente de la nivelul reea. Pachetele pierdute sau incorecte pot fi detectate i
corectate de ctre nivelul transport. Mai mult, primitivele serviciului de transport pot fi
implementate ca apeluri ctre procedurile de bibliotec, astfel nct s fie independente de
primitivele de la nivelul reea. Apelurile nivelului reea pot s varieze considerabil de la o reea
la alta (de exemplu, serviciile fr conexiune ntr-o reea local pot fi foarte diferite de serviciile
orientate pe conexiune dintr-o reea larg rspndit geografic). Ascunznd serviciul reea n
spatele unui set de primitive ale serviciului transport, schimbarea serviciului reea necesit
numai nlocuirea unui set de proceduri de bibliotec cu un altul care face acelai lucru, cu un
serviciu inferior diferit.
Mulumit nivelului transport, programatorii de aplicaii pot scrie cod conform unui set standard
de primitive, pentru a rula pe o mare varietate de reele, fr s i pun problema interfeelor
de subreea diferite sau transmisiilor nesigure. Dac toate reelele reale ar fi perfecte i toate ar
3

avea acelai set de primitive i ar fi garantate s nu se schimbe niciodat, atunci probabil c
nivelul transport nu ar mai fi fost necesar. Totui, n lumea real el ndeplinete importanta
funcie de a izola nivelurile superioare de tehnologia, arhitectura i imperfeciunile subreelei.
Din aceast cauz, n general se poate face o distincie ntre nivelurile de la 1 la 4, pe de o
parte, i cel (cele) de deasupra, pe de alt parte. Primele pot fi vzute ca furnizoare de servicii
de transport, iar ultimele ca utilizatoare de servicii de transport. Aceast distincie ntre
utilizatori i furnizori are un impact considerabil n ceea ce privete proiectarea arhitecturii de
niveluri i confer nivelului transport o poziie cheie, acesta fiind limita ntre furnizorul i
utilizatorul serviciilor sigure de transmisie de date.
1.1.2 Primitivele serviciilor de transport

Pentru a permite utilizatorului s acceseze serviciile de transport, nivelul transport trebuie s
ofere unele operaii programelor aplicaie, adic o interfa a serviciului transport. Fiecare
serviciu de transport are interfaa sa.
Serviciul transport este similar cu cel reea, dar exist i cteva diferene importante. Principala
diferen este c serviciul reea a fost conceput pentru a modela serviciile oferite de reelele
reale. Acestea pot pierde pachete, deci serviciile la nivel reea sunt n general nesigure.
n schimb, serviciile de transport (orientate pe conexiune) sunt sigure. Desigur, n reelele reale
apar erori, dar este tocmai acesta este scopul nivelului transport: s furnizeze un serviciu sigur
deasupra unui nivel reea nesigur.
Ca exemplu, se consider dou procese conectate prin pipe-uri n UNIX. Acestea presupun o
conexiune perfect ntre ele. Ele nu vor s aib de-a face cu confirmri, pachete pierdute,
congestii sau altele asemntoare. Ele au nevoie de o conexiune sigur n proporie de 100%.
Procesul A pune datele la un capt al tubului, iar procesul B le ia de la cellalt capt. Aceasta
este exact ceea ce face un serviciu transport orientat pe conexiune: ascunde imperfeciunile
reelei, astfel nct procesele utilizator pot s presupun existena unui flux de date fr erori.
n acelai timp nivelul transport furnizeaz i un serviciu nesigur. Totui, sunt puine de spus n
legtur cu acesta, aa c n acest capitol se va concentra atenia asupra serviciului orientat pe
conexiune. Cu toate acestea, exist unele aplicaii, cum sunt programele client-server i
fluxurile multimedia, care beneficiaz de transport fr conexiune, deci se va vorbi puin despre
ele mai trziu.
O a doua diferen ntre serviciul reea i cel de transport se refer la destinaiile lor. Serviciul
reea este folosit doar de entitile de transport. Puini utilizatori scriu ei nii entitile de
transport i, astfel, puini utilizatori sau programe ajung s vad vreodat serviciile reea aa
cum sunt ele. n schimb, multe programe (i programatori) folosesc primitivele de transport. De
4

aceea, serviciul transport trebuie s fie uor de utilizat.
Se consider cele cinci primitive prezentate n Figura 10-2. Aceast interfa este ntr-adevr
simpl, dar prezint trsturile de baz ale oricrei interfee orientate pe conexiune a nivelului
transport. Ea permite programelor de aplicaie s stabileasc, s utilizeze i s elibereze
conexiuni, ceea ce este suficient pentru multe aplicaii.
Primitiva
LISTEN
Unitatea de date trimis

(nimic)
CONNECT
SEND
RECEIVE
CONNECTION REQ.
DATE
(nimic)
DISCONNECT
DISCONNECTION REQ.
Explicaii
Se blocheaz pn cnd un proces
ncearc s se conecteze
ncearc s stabileasc conexiunea
Transmite informaie
Se blocheaz pn cnd primete
date trimise
Trimis de partea care vrea s se
deconecteze
Figura 10-2 Primitivele unui serviciu de transport simplu
Pentru a vedea cum pot fi utilizate aceste primitive, se consider o aplicaie cu un server i un
numr oarecare de clieni la distan. La nceput, serverul apeleaz primitiva LISTEN, n
general prin apelul unei funcii de bibliotec care face un apel sistem pentru a bloca serverul
pn la apariia unei cereri client. Atunci cnd un client vrea s comunice cu serverul, el va
executa un apel CONNECT. Entitatea de transport trateaz acest apel blocnd apelantul i
trimind un pachet la server. Acest pachet ncapsuleaz un mesaj ctre entitatea de transport
de pe server.
Se va folosi acronimul TPDU (Transport Protocol Data Unit - unitate de date a protocolului de
transport) pentru toate mesajele schimbate ntre dou entiti de transport corespondente.
Astfel, TPDU-urile (schimbate la nivelul transport) sunt coninute n pachete (utilizate de nivelul
reea). La rndul lor, pachetele sunt coninute n cadre (utilizate la nivelul legtur de date).
Atunci cnd este primit un cadru, nivelul legtur de date prelucreaz antetul cadrului i d
coninutul util nivelului reea. Entitatea reea prelucreaz antetul pachetului i paseaz
coninutul util entitii de transport. Aceast ierarhie este ilustrat n Figura 10-3.
Apelul CONNECT al clientului genereaz un TPDU de tip CONNECTION REQUEST care i
este trimis serverului. Atunci cnd acesta ajunge, entitatea de transport verific dac serverul
este blocat ntr-un apel LISTEN (deci dac ateapt o cerere de conexiune). n acest caz,
deblocheaz serverul i trimite napoi clientului un TPDU CONNECTION ACCEPTED. Atunci
cnd acest TPDU ajunge la destinaie, clientul este deblocat i conexiunea este stabilit.
Acum pot fi schimbate date folosindu-se primitivele SEND i RECEIVE. Cea mai simpl posibilitate este ca una din pri s fac un apel RECEIVE (blocant) ateptnd ca cealalt parte s
5

execute un SEND. Atunci cnd sosete un TPDU, receptorul este deblocat. El poate prelucra
TPDU-ul i trimite o replic. Atta vreme ct amndou prile tiu cine este la rnd s trimit
mesaje i cine este la rnd s recepioneze, totul merge bine.
Figura 10-3. Ierarhia de cadre, pachete i TPDU-uri.
Se observ c la nivelul transport, chiar i un schimb de date simplu, unidirecional, este mult
mai complicat dect la nivelul reea. Fiecare pachet de date trimis va fi (n cele din urm)
confirmat. Pachetele care conin TPDU-uri de control sunt de asemenea confirmate, implicit sau
explicit. Aceste confirmri sunt gestionate de entitile de transport folosind protocoalele de la
nivelul reea i nu sunt vizibile utilizatorilor nivelului transport. Similar, entitile de transport
trebuie s se ocupe de ceasuri i de retransmisii. Nimic din tot acest mecanism nu este vizibil
pentru utilizatorii nivelului transport, pentru care o conexiune este un tub fr pierderi: un
utilizator ndeas bii la un capt i acetia apar, ca prin minune, la captul celalalt. Aceast
capacitate de a ascunde complexitatea este motivul care face ierarhia de protocoale s fie un
instrument att de puternic.
Atunci cnd o conexiune nu mai este necesar, ea trebuie eliberat pentru a putea elibera i
spaiul alocat n tabelele corespunztoare din cele dou entiti de transport. Deconectrile se
pot face n dou variante: asimetric sau simetric. n varianta asimetric, oricare dintre
utilizatori poate ape-la o primitiv DISCONNECT, ceea ce va avea ca rezultat trimiterea unui
TPDU DISCONNECT REQUEST entitii de transport aflate la distan. La sosirea acestuia
conexiunea este eliberat.
n varianta simetric fiecare direcie este nchis separat, independent de cealalt. Atunci cnd
una din pri face un apel DISCONNECT, nsemnnd c nu mai sunt date de trimis, ea va putea
nc recepiona datele transmise de entitatea de transfer aflat la distan. n acest model
conexiunea este eliberat dac ambele pri au apelat DISCONNECT.
Figura 10-4 Diagrama de stri pentru o schem simpl de control al conexiunii.

Tranziiile etichetate cu italice sunt cauzate de sosirea unor pachete.
Liniile continue indic secvena de stri a clientului.
Liniile punctate indic secvena de stri a serverului.
O diagram de stri pentru stabilirea i eliberarea conexiunilor folosind aceste primitive simple
este prezentat n Figura 10-4. Fiecare tranziie este declanat de un eveniment: fie este
executat o primitiv de ctre utilizatorul local al nivelului transport, fie este primit un pachet.
Pentru simplitate se va presupune c fiecare TPDU este confirmat separat. Se va presupune de
asemenea c este folosit un model de deconectare simetric, clientul iniiind aciunea. Trebuie
reinut c acesta este un model foarte simplu.
1.1.3 Socluri Berkeley
Se vor trece n revist acum un alt set de primitive de transport: primitivele pentru socluri TCP
folosite n sistemul de operare Berkeley-UNIX. Primitivele sunt enumerate n Figura 10-5.
Primele patru primitive din tabel sunt executate, n aceast ordine, de ctre server. Primitiva
SOCKET creeaz un nou capt al conexiunii i aloc spaiu pentru el n tabelele entitii de
transport. n parametrii de apel se specific formatul de adres utilizat, tipul de serviciu dorit (de
exemplu, flux sigur de octei) i protocolul. Un apel SOCKET reuit ntoarce un descriptor de
fiier (la fel ca un apel OPEN) care va fi utilizat n apelurile urmtoare.

Funcia
Creeaz un nou punct de capt al comunicaiei
Ataeaz o adres local la un soclu
Anun capacitatea de a accepta conexiuni;
determin mrimea cozii
Blocheaz apelantul pn la sosirea unei cereri de
conexiune
Tentativ (activ) de a stabili o conexiune
Trimite date prin conexiune
Recepioneaz date prin conexiune
Elibereaz conexiunea
Primitiva
SOCKET
BIND
LISTEN
ACCEPT
CONNECT
SEND
RECEIVE
CLOSE
Figura 10-5 Primitivele pentru socluri TCP
Soclurile nou create nu au nc nici o adres. Ataarea unei adrese se face utiliznd primitiva
BIND. Odat ce un server a ataat o adres unui soclu, clienii se pot conecta la el. Motivul
pentru care apelul SOCKET nu creeaz adresa direct este c unor procese le pas de adresa
lor, n timp ce altele nu.
Urmeaz apelul LISTEN, care aloc spaiu pentru a reine apelurile primite n cazul cnd mai
muli clieni ncearc s se conecteze n acelai timp. Spre deosebire de modelul din primul
nostru exemplu, aici LISTEN nu mai este un apel blocant.
Pentru a se bloca i a atepta un apel, serverul execut o primitiv ACCEPT. Atunci cnd
sosete un TPDU care cere o conexiune, entitatea de transport creeaz un nou soclu cu
aceleai proprieti ca cel iniial i ntoarce un descriptor de fiier pentru acesta. Serverul poate
atunci s creeze un nou proces sau fir de execuie care va gestiona conexiunea de pe noul
soclu i s atepte n continuare cereri de conexiune pe soclul iniial. ACCEPT returneaz un
descriptor normal de fiier, care poate fi folosit pentru citirea i scrierea n mod standard, la fel
ca pentru fiiere.
Din punct de vedere al clientului, soclul trebuie creat folosind o primitiv SOCKET, dar primitiva
BIND nu mai este necesar, deoarece adresa folosit nu mai este important pentru server.
Primitiva CONNECT blocheaz apelantul i demareaz procesul de conectare. Cnd acesta s-a
terminat (adic atunci cnd TPDU-ul corespunztor a fost primit de la server), procesul client
este deblocat i conexiunea este stabilit. Att clientul ct i serverul pot utiliza acum primitivele
SEND i RECEIVE pentru a transmite sau recepiona date folosind o conexiune duplex integral.
Se pot folosi i apelurile de sistem READ i WRITE standard din UNIX, dac nu sunt necesare
opiunile speciale oferite de SEND i RECV.
Eliberarea conexiunii este simetric. Atunci cnd ambele pri au executat primitiva CLOSE,
conexiunea este eliberat.
2. Noiuni de baz despre protocoalele de transport
Serviciul transport este implementat prin intermediul unui protocol de transport folosit de cele
dou entiti de transport. Cteva caracteristici sunt asemntoare pentru protocoalele de
transport i pentru cele de legtur de date. Amndou trebuie s se ocupe, printre altele, de
controlul erorilor, de secveniere i de controlul fluxului.
Totui, exist diferene semnificative ntre cele dou protocoale. Aceste diferene sunt datorate
deosebirilor majore dintre mediile n care opereaz protocoalele, aa cum rezult din Figura 106. La nivelul legturii de date, cele dou rutere comunic direct printr-un canal fizic, n timp ce la
nivelul transport acest canal fizic este nlocuit de ntreaga subreea. Aceast deosebire are mai
multe implicaii importante pentru protocoale.
n cazul legturii de date, pentru un ruter nu trebuie specificat cu care alt ruter vrea s
comunice, deoarece fiecare linie specific n mod unic o destinaie. n schimb, n cazul nivelului
transport este necesar adresarea explicit.
n plus, procesul stabilirii unei conexiuni prin cablul din Figura 10-6(a) este simplu: cellalt capt
este ntotdeauna acolo (n afar de cazul n care nu a czut) i n nici unul din cazuri nu sunt
prea multe de fcut. Pentru nivelul transport ns, stabilirea iniial a conexiunii este mult mai
complicat, aa cum se va vedea.
Figura 10-6 (a) Mediul pentru nivelul legtur de date. (b) Mediul pentru nivelul transport.
O alt diferen ntre nivelurile legtur de date i transport, care genereaz multe probleme,
este existena potenial a unei capaciti de memorare a subreelei. Atunci cnd un ruter trimite
un cadru (nivel legtur de date), acesta poate s ajung sau poate s se piard, dar nu poate
s se plimbe un timp ajungnd pn la captul lumii i s apar 30 de secunde mai trziu, ntrun moment nepotrivit. Dac subreeaua folosete datagrame i dirijare adaptiv, exist o
posibilitate - care nu poate fi neglijat - ca un pachet s fie pstrat pentru un numr oarecare de
9

secunde i livrat mai trziu. Consecinele capacitii de memorare a subreelei pot fi uneori
dezastruoase i necesit folosirea unor protocoale speciale.
O ultim diferen ntre nivelurile legtur de date i transport este una de dimensionare i nu
de proiectare. Folosirea tampoanelor i controlul fluxului sunt necesare la amndou nivelurile,
dar prezena unui numr mare de conexiuni n cazul nivelului transport necesit o abordare
diferit de cea de la nivelul legtur de date. La nivel transport, numrul mare de conexiuni care
trebuie s fie gestionate face ca ideea de a aloca tampoane dedicate s fie mai puin atractiv.
2.1 Adresarea
Atunci cnd un proces aplicaie (de exemplu, un proces utilizator) dorete s stabileasc o
conexiune cu un proces aflat la distan, el trebuie s specifice cu care proces dorete s se
conecteze. (La protocoalele de transport neorientate pe conexiune apare aceeai problem: cui
trebuie trimis mesajul?). Metoda folosit n mod normal este de a defini adrese de transport la
care procesele pot s atepte cereri de conexiune. n Internet acestea se numesc porturi. La
reelele ATM perechile se numesc AAL - SAP-uri. n continuare se va folosi pentru acestea
termenul generic TSAP (Transport Service Access Point - punct de acces la serviciul de
transport). Punctele similare n cazul nivelului reea (adic adresele la nivel reea) sunt numite
NSAP (Network Service Access Point). Adresele IP sunt exemple de NSAP-uri.
Figura 10-7 ilustreaz relaia ntre TSAP, NSAP i conexiunile transport. Procesele aplicaie,
att clienii ct i serverele, se pot ataa la TSAP pentru a stabili o conexiune la un TSAP la
distan. Aceste conexiuni ruleaz prin TSAP-uri pe fiecare gazd aa cum se arat.
Necesitatea de a avea mai multe TSAP-uri este dat de faptul c n unele reele, fiecare
calculator are un singur NSAP, deci cumva este nevoie s se disting mai multe puncte de
sfrit de transport care partajeaz acel NSAP.
Un scenariu posibil pentru stabilirea unei conexiuni la nivel transport este urmtorul.
1. Un proces server care furnizeaz ora exact i care ruleaz pe gazda 2 se ataeaz la
TSAP 122 ateptnd un apel. Felul n care un proces se ataeaz la un TSAP nu face
parte din modelul de reea i depinde numai de sistemul de operare local. Poate fi
utilizat un apel de tip LISTEN din capitolul precedent.
2. Un proces aplicaie de pe gazda 1 dorete s afle ora exact; atunci el genereaz un
apel CONNECT specificnd TSAP 1208 ca surs i TSAP 1522 ca destinaie. Aceast
aciune are ca rezultat n cele din urm stabilirea unei conexiuni la nivel transport ntre
procesele aplicaie de pe gazda 1i serverul 1 de pe gazda 2.
3. Procesul aplicaie trimite o cerere o cerere pentru timp.
10

4. Procesul server de timp rspunde cu timpul curent.
5. Conexiunea transport este apoi eliberat.
Gazda 1
Gazda 2
Figura 10-7 TSAP, NSAP i conexiunile la nivel transport.
Trebuie reinut c foarte bine pot exista alte servere pe gazda 2 care s fie ataate la alte
TSAPuri i care s atepte conexiuni care ajung pe acelai NSAP.
Figura 10-7 explic aproape tot, cu excepia unei mici probleme: cum tie procesul utilizator de
pe maina 1 c serverul de or exact este ataat la TSAP 1522? O posibilitate este ca acest
server de or exact s se ataeze la TSAP 1522 de ani de zile i, cu timpul, toi utilizatorii au
aflat acest lucru. n acest model serviciile au adrese TSAP fixe, care pot fi afiate n fiiere n
locuri bine cunoscute, cum este fiierul etc/services pe sistemele UNIX care afieaz ce servere
sunt ataate permanent i la ce porturi. Dar schema cu adrese de servicii fixe funcioneaz doar
pentru un numr mic de servicii cheie, a cror adres nu se schimb niciodat (de exemplu
server de Web). ns, n general, procesele utilizator vor s comunice cu alte procese care
exist numai pentru scurt timp i nu au o adres TSAP dinainte cunoscut. Pe de alt parte, pot
exista mai multe procese server, majoritatea utilizate foarte rar, i ar fi neeconomic ca fiecare s
fie activ i s asculte la o adres TSAP fix tot timpul. Pe scurt, este necesar o soluie mai
bun.
O astfel de soluie este prezentat n Figura 10-8, ntr-o form simplificat. Ea este cunoscut
ca protocolul de conectare iniial. n loc ca orice server s asculte la un TSAP fixat, fiecare
main care dorete s ofere servicii utilizatorilor aflai la distan are un server de procese
special care acioneaz ca un intermediar pentru toate serverele mai puin utilizate. El ascult n
11

acelai timp la un numr de porturi, ateptnd o cerere de conexiune. Utilizatorii poteniali ai
serviciului ncep prin a face o cerere de conexiune, specificnd adresa TSAP a serviciului pe
care l doresc. Dac nu exist un server care s atepte conexiuni la acel port, ele obin o
conexiune la serverul de procese, ca n Figura 10-8 (a).
Dup ce primete cererea, serverul de procese d natere serverului cerut, permindu-i s
moteneasc conexiunea cu procesul utilizator. Noul server execut prelucrarea cerut, n timp
ce serverul de procese continu s atepte noi cereri, ca n Figura 10-8 (b).
Figura 10-8 Stabilirea unei conexiuni ntre calculatorul gazd1 i serverul pentru ora exact.
n timp ce acest protocol funcioneaz bine pentru serverele care pot fi create ori de cte ori
este nevoie de ele, exist mai multe situaii n care serviciile exist independent de serverul de
procese. De exemplu, un server de fiiere va rula folosind un hardware specializat (o maina cu
disc) i nu poate fi creat din mers. Pentru a trata aceast situaie, este des utilizat o soluie
alternativ. n acest model exist un proces special numit server de nume (name server sau,
uneori, directory server). Pentru a gsi adresa TSAP corespunztoare unui serviciu dat prin
nume, aa cum este ora exact, utilizatorul stabilete o conexiune cu serverul de nume (care
ateapt mesaje la un TSAP cunoscut). Apoi utilizatorul trimite un mesaj specificnd numele
serviciului, iar serverul de nume i trimite napoi adresa TSAP a acestuia. Dup aceasta,
utilizatorul elibereaz conexiunea cu serverul de nume i stabilete o nou conexiune cu
serviciul dorit.
n acest model, atunci cnd este creat un nou serviciu, el trebuie s se nregistreze singur la
serverul de nume, furniznd att numele serviciului oferit (n general un ir ASCII) ct i adresa
12

TSAP. Serverul de nume nregistreaz aceast informaie ntr-o baz de date intern, astfel
nct el va ti rspunsul atunci cnd vor sosi noi cereri.
2.2 Stabilirea conexiunii

Stabilirea unei conexiuni poate s par uoar dar, n realitate, este surprinztor de complicat.
La prima vedere, ar prea suficient ca o entitate de transport s trimit numai un TPDU
CONNECTION REQUEST i s atepte replica CONNECTION ACCEPTED . Problema apare
deoarece reeaua poate pierde, memora sau duplica pachete. Acest comportament duce la
complicaii serioase.
Se poate imagina o subreea care este att de congestionat nct confirmrile ajung greu
napoi, i, din aceast cauz, fiecare pachet ajunge s fie retransmis de cteva ori. Se poate
presupune c subreeaua folosete datagrame i fiecare pachet urmeaz un traseu diferit.
Unele pachete pot s ntlneasc o congestie local de trafic i s ntrzie foarte mult, ca i
cum ar fi fost memorate de subreea un timp i eliberate mai trziu.
Cel mai neplcut scenariu ar fi: un utilizator stabilete o conexiune cu o banc i trimite un
mesaj cernd transferul unei sume de bani n contul unei alte persoane n care nu poate avea
ncredere n totalitate, i apoi elibereaz conexiunea. Din nefericire, fiecare pachet din acest
scenariu este duplicat i memorat n subreea. Dup ce conexiunea a fost eliberat, pachetele
memorate ies din subreea i ajung la destinatar, cernd bncii s stabileasc o nou
conexiune, s fac transferul (nc o dat) i s elibereze conexiunea. Banca nu poate s tie
c acestea sunt duplicate, ea trebuie s presupun c este o tranzacie independent i va
transfera banii nc o dat.
Punctul crucial al problemei este existena duplicatelor ntrziate. El poate fi tratat n mai multe
feluri, dar nici unul nu este ntr-adevr satisfctor. O posibilitate este de a utiliza adrese de
transport valabile doar pentru o singur utilizare. n aceast abordare, ori de cte ori este
necesar o adres la nivel transport, va fi generat una nou. Dup ce conexiunea este eliberat, adresa nu mai este folosit. Acest mecanism face ns imposibil modelul cu server de
procese din Figura 10-8.
O alt posibilitate este de a atribui fiecrei conexiuni un identificator (adic, un numr de secven incrementat pentru fiecare conexiune stabilit), ales de cel care iniiaz conexiunea, i
pus n fiecare TPDU, inclusiv n cel care iniiaz conexiunea. Dup ce o conexiune este
eliberat, fiecare entitate de transport va completa o tabel cu conexiunile care nu mai sunt
valide, reprezentate ca perechi (entitate de transport, identificator conexiune). Ori de cte ori
apare o cerere de conexiune se va verifica n tabel c ea nu aparine unei conexiuni care a
fost eliberat anterior.
13

Din nefericire, aceast schem are un defect important: ea necesit ca fiecare entitate de transport s menin informaia despre conexiunile precedente un timp nedefinit. Dac o main
cade i i pierde datele din memorie, ea nu va mai ti care identificatori de conexiune au fost
deja utilizai.
Se poate ncerca i o alt soluie. n loc s se permit pachetelor s triasc la nesfrit n
subreea, se poate inventa un mecanism care s elimine pachetele mbtrnite. Dac exist
sigurana c nici un pachet nu poate s supravieuiasc mai mult de un anume interval de timp
cunoscut, problema devine ceva mai uor de rezolvat.
Durata de via a pachetelor poate fi limitat la un maxim cunoscut, folosind una (sau mai
multe) din urmtoarele tehnici:
1. Restricii n proiectarea subreelei
2. Adugarea unui contor al nodurilor parcurse n fiecare pachet
3. Adugarea unei amprente de timp la fiecare pachet
Prima metod include soluiile care mpiedic pachetele s stea n bucl, combinate cu
modaliti de a limita ntrzierile datorate congestiilor, pe orice cale din reea (indiferent de
lungime). A doua metod const n a iniializa contorul cu o valoare adecvat i n a-l
decrementa la trecerea prin orice nod. Protocolul de nivel reea pur i simplu elimin pachetele
al cror contor a devenit zero. A treia metod presupune ca fiecare pachet s conin timpul
crerii sale, ruterele acceptnd s elimine pachetele mai vechi de un anumit moment de timp,
asupra cruia au czut de acord. Aceast metod necesit ca ceasurile de la fiecare ruter s fie
sincronizate, i aceast cerin n sine este destul de greu de ndeplinit (mai uor este dac
sincronizarea ceasurilor se obine din exteriorul reelei, de exemplu folosind GPS sau staii radio
care transmit periodic ora exact).
n practic, nu este suficient doar garantarea c pachetul este eliminat, ci trebuie garantat i c
toate confirmrile sale au fost eliminate, astfel nct se va introduce T, care va fi un multiplu
(mic) al duratei maxime de via a unui pachet. Depinde de protocol de cte ori T este mai mare
dect durata de via a unui pachet. Dac se ateapt un timp T dup trimiterea unui pachet
exist sigurana c toate urmele sale au disprut i nici el, nici vreo confirmare de-a sa nu vor
aprea din senin, doar ca s complice lucrurile.
Folosind durata de via limitat a pachetelor, exist metode de a obine conexiuni sigure a
cror corectitudine a fost demonstrat. Metoda descris n cele ce urmeaz este datorat lui
Tomlinson (1975). Ea rezolv problema, dar introduce cteva particulariti proprii. Metoda a
fost mbuntit de Sunshine i Dalal (1978). Variante ale sale sunt larg folosite n practic,
inclusiv n TCP.
Pentru a ocoli problemele generate de pierderea tuturor datelor din memoria unei maini dup o
14

cdere, Tomlinson propune echiparea fiecrei maini cu un ceas. Nu este nevoie ca ceasurile
de pe maini diferite s fie sincronizate. Fiecare ceas va fi de fapt un contor binar care se
autoincrementeaz dup un anumit interval de timp. n plus, numrul de bii ai contorului trebuie
s fie cel puin egal cu numrul de bii al numerelor de secven. n cele din urm, i cel mai
important, ceasul trebuie s continue s funcioneze chiar n cazul n care calculatorul gazd
cade.
Ideea de baz este de a fi siguri c dou TPDU numerotate identic nu pot fi generate n acelai
timp. Atunci cnd conexiunea este iniiat, k bii mai puin semnificativi ai ceasului sunt folosii
ca numr iniial de secven (tot k bii). Astfel, fiecare conexiune ncepe s-i numeroteze
TPDU-urile sale cu un numr de secven diferit. Spaiul numerelor de secven ar trebui s fie
suficient de mare pentru ca, n timpul scurs pn cnd contorul ajunge din nou la acelai
numr, toate TPDU-urile vechi cu acel numr s fi disprut deja. Aceast relaie liniar ntre
timp i numrul de secven iniial este prezentat n Figura 10-9.
Figura 10-9 (a) TPDU-urile nu pot s intre n regiunea interzis. (b) Problema resincronizrii.
Odat ce ambele entiti de transport au czut de acord asupra numrului de secven iniial,
pentru controlul fluxului poate fi folosit orice protocol cu fereastr glisant. n realitate curba ce
reprezint numrul iniial de secven (desenat cu linie ngroat) nu este chiar liniar, ci n
trepte, cci ceasul avanseaz n trepte. Pentru simplitate, se va ignora acest detaliu.
O problem apare atunci cnd cade un calculator gazd. Cnd el i revine, entitatea sa de
transport nu tie unde a rmas n spaiul numerelor de secven. O soluie este de a cere
entitii de transport s stea neocupat T secunde dup revenire pentru ca n acest timp toate
vechile TPDU s dispar. Totui, ntr-o reea complex T poate fi destul de mare, astfel c
aceast strategie nu este prea atrgtoare.
15

Pentru a evita cele T secunde de timp nefolosit dup o cdere, este necesar s se introduc o
nou restricie n utilizarea numerelor de secven. Necesitatea introducerii acestei restricii este
evident n urmtorul exemplu. Fie T, timpul maxim de via al unui pachet, egal cu 60 de
secunde i se presupune c ceasul este incrementat la fiecare secund. Dup cum arat linia
ngroat din Figura 10-9 (a), numrul iniial de secven pentru o conexiune iniiat la
momentul x este x. Se imagineaz c la t=30 sec, unui TPDU trimis pe conexiunea cu numrul
5 (deschis anterior) i se d numrul de secven 80. Se denumete acest TPDU X. Imediat
dup ce X este trimis, calculatorul gazd cade i re-vine imediat. La t=60 el redeschide
conexiunile de la 0 la 4. La t=70, el deschide conexiunea 5, folosind un numr de secven
iniial 70, aa cum am stabilit. n urmtoarele 15 secunde el va transmite TPDU-uri cu date
numerotate de la 70 la 80. Astfel c la t=85, n subreea este generat un nou TPDU cu numrul
de secven 80 i conexiunea 5. Din nefericire, TPDU X nc mai exist. Dac el ajunge
naintea noului TPDU 80, atunci TPDU X va fi acceptat i TPDU-ul corect va fi respins ca fiind
un duplicat.
Pentru a preveni o astfel de problem trebuie s se ia msuri ca numerele de secven s nu
fie utilizate (adic atribuite unor noi TPDU-uri) un timp T naintea utilizrii lor ca noi numere de
secven. Combinaiile imposibile - timp, numr de secven - sunt prezentate n Figura 10-9(a)
ca regiunea interzis. nainte de trimiterea oricrui TPDU pe orice conexiune, entitatea de
transport trebuie s citeasc ceasul i s verifice dac nu cumva se afl n regiunea interzis.
Pot s apar probleme n dou cazuri: dac un calculator gazd trimite prea multe date i prea
repede pe o conexiune nou deschis, curba numrului de secven n funcie de timp poate s
fie mult mai abrupt dect cea iniial. Aceasta nseamn c rata de transmisie pentru orice
conexiune este de cel mult un TPDU pe unitatea de timp a ceasului. De asemenea, este
necesar ca entitatea de transport s atepte pn cnd ceasul avanseaz o dat, nainte s
deschid o nou conexiune pentru ca, la revenirea dup o cdere, acelai numr de secven
s nu fie utilizat de dou ori. Cele dou observaii de mai sus sunt argumente pentru ca
perioada ceasului s fie ct mai mic (cteva s sau mai mic).
Din nefericire, intrarea n regiunea interzis prin trimitere prea rapid nu este singura situaie
care creeaz probleme. Figura 10-9(b) arat c la orice rat de transfer mai mic dect
frecvena ceasului curba numerelor de secven utilizate raportat la timp va ajunge pn la
urm n regiunea interzis din stnga. Cu ct curba numerelor de secven utilizate va fi mai
nclinat, cu att mai trziu se ajunge n regiunea interzis. Aa cum am afirmat anterior,
imediat naintea trimiterii unui TPDU, entitatea de transport trebuie s verifice dac nu se afl
cumva n regiunea interzis, i, dac se afl, s ntrzie transmisia cu T secunde sau s
resincronizeze numerele de secven.
Metoda bazat pe ceasuri rezolv problema duplicatelor ntrziate pentru TPDU-urile de date,
dar pentru ca aceast metod s poat fi folosit, trebuie mai nti s stabilim conexiunea.
16

Deoarece TPDU-urile de control pot i ele s fie ntrziate, pot aprea probleme atunci cnd
entitile de transport ncerc s cad de acord asupra numrului iniial de secven. S
presupunem, de exemplu, c, pentru a stabili o conexiune, gazda 1 trimite un mesaj
CONNECTION REQUEST coninnd numrul de secven iniial propus i portul destinaie
gazdei 2. Acesta va confirma mesajul trimind napoi un TPDU CONNECTION ACCEPTED .
Dac TPDU-ul CONNECTION REQUEST este pierdut, dar un duplicat ntrziat al unui alt
CONNECTION REQUEST va ajunge la gazda 2, atunci conexiunea nu va fi stabilit corect.
Figura 10-10 Trei scenarii posibile de stabilire a conexiunii pentru un protocol cu nelegere n
trei pai. CR reprezint CONNECTION REQUEST. (a) Cazul normal, (b) Un duplicat vechi al
unui mesaj CONNECTION REQUEST apare cnd nu trebuie, (c) Sunt duplicate att
CONNECTION REQUEST ct i CONNECTION ACCEPTED.
Pentru a rezolva aceasta problem, Tomlinson (1975) a introdus stabilirea conexiunii cu nelegere n trei pai (three-way handshake). Acest protocol nu necesit ca ambele pri s nceap
s trimit acelai numr de secven, deci poate fi utilizat i mpreun cu alte metode de
sincronizare dect ceasul global. Procedura normal de iniiere a conexiunii este exemplificat
17

n Figura 10-10(a). Gazda 1 alege un numr de secven x i trimite un TPDU CONNECTION
REQUEST care conine x gazdei 2. Gazda 2 rspunde cu CONNECTION ACK, confirmnd x i
anunnd numrul su iniial de secven, y. n cele din urm gazda 1 confirm alegerea lui y
gazdei 2 n primul mesaj de date pe care l trimite.
Se va arunca acum o privire asupra stabilirii conexiunii cu nelegere n trei pai n prezena
TPDU-urilor de control duplicate ntrziate. n Figura 10-10(b) primul TPDU sosit este o copie
ntrziat a unui CONNECTION REQUEST de la o conexiune mai veche. Acest TDU ajunge la
gazda 2 fr ca gazda 1 s tie. Gazda 2 rspunde acestui TPDU trimind gazdei 1 un TPDU
ACK, verificnd de fapt c gazda 1 a ncercat ntr-adevr s stabileasc o conexiune. Atunci
cnd gazda 1 refuz cererea gazdei 2 de a stabili conexiunea, gazda 2 i d seama c a fost
pclit de o copie ntrziat i abandoneaz conexiunea. n acest fel o copie ntrziat nu
poate s strice nimic.
n cel mai ru caz, att CONNECTION REQUEST ct i ACK sunt copii ntrziate n subreea.
Acest caz este prezentat n Figura 10-10 (c). Ca i n exemplul precedent, gazda 2 primete o
comand CONNECTION REQUEST ntrziat i rspunde la ea. Gazda 2 a propus y ca numr
iniial de secven pentru traficul de la 2 la 1, fiind sigur c nu mai exist n reea nici un TPDU
(sau confirmare) cu acelai numr de secven. Atunci cnd al doilea TPDU ntrziat ajunge la
gazda 2, aceasta deduce, din faptul c a fost confirmat z i nu y, c are de-a face cu o copie
mai veche. Important este c nu exist nici o combinaie posibil ale unor copii vechi ale TPDUurilor ntrziate care s reueasc s iniieze o conexiune atunci cnd nimeni nu a cerut asta.
2.3 Eliberarea conexiunii

Eliberarea unei conexiuni este mai uoar dect stabilirea ei. Totui, exist mai multe dificulti
dect ne-am atepta. Aa cum am mai amintit, exist dou moduri de a termina o conexiune:
eliberare simetric i eliberare asimetric. Sistemul telefonic folosete eliberarea asimetric:
atunci cnd unul din interlocutori nchide, conexiunea este ntrerupt. Eliberarea simetric
privete conexiunea ca pe dou conexiuni separate unidirecionale i cere ca fiecare s fie
eliberat separat.
Eliberarea asimetric este brusc i poate genera pierderi de date. Se consider scenariul din
Figura 10-11. Dup stabilirea conexiunii, gazda 1 trimite un TPDU care ajunge corect la gazda
2. Gazda 1 mai trimite un TPDU dar, nainte ca acesta s ajung la destinaie, gazda 2 trimite
DISCONNECT REQUEST . n acest caz, conexiunea va fi eliberat i vor fi pierdute date.
Evident, pentru a evita pierderea de date, este necesar un protocol de eliberare a conexiunii
mai sofisticat. O posibilitate este utilizarea eliberrii simetrice: fiecare direcie este eliberat
independent de cealalt; un calculator gazd poate s continue s primeasc date chiar i dup
18

ce a trimis un TPDU de eliberare a conexiunii.
Figura 10-11 Deconectare brusc cu pierdere de date. CR= CONNECTION REQUEST,

ACK=CONNECTION ACCEPTED , DR=DISCONNECT REQUEST.
Eliberarea simetric este util atunci cnd fiecare proces are o cantitate fix de date de trimis i
tie bine cnd trebuie s transmit i cnd a terminat. n alte situaii ns, nu este deloc uor de
determinat cnd trebuie eliberat conexiunea i cnd a fost trimis tot ce era de transmis. S-ar
putea avea n vedere un protocol de tipul urmtor: atunci cnd 1 termin, trimite ceva de tipul:
Am terminat. Ai terminat i tu? Dac gazda 2 rspunde: Da, am terminat. nchidem! conexiunea
poate fi eliberat n condiii bune.
Figura 10-12 Problema celor dou armate.

Din nefericire, acest protocol nu merge ntotdeauna. Binecunoscuta problem a celor dou armate este similar acestei situaii: se imagineaz c armata alb i-a pus tabra ntr-o vale (ca
n Figura 10-12) Pe amndou crestele care mrginesc valea sunt armatele albastre. Armata
alb este mai mare dect fiecare din cele dou armate albastre, dar mpreun armatele albastre
sunt mai puternice. Dac oricare din armatele albastre atac singur, ea va fi nfrnt, dar dac
19

ele atac simultan, atunci vor fi victorioase.
Armatele albastre vor s-i sincronizeze atacul. Totui singura lor posibilitate de comunicaie
este s trimit un mesager care s strbat valea. Mesagerul poate fi capturat de armata alb i
mesajul poate fi pierdut (adic vor trebui s utilizeze un canal de comunicaie nesigur).
Problema este urmtoarea: exist vreun protocol care s permit armatelor albastre s nving?
Se presupune c comandantul primei armate albastre trimite un mesaj: Propun s atacm pe
29 martie, mesajul ajunge la armata 2 al crei comandant rspunde: De acord iar rspunsul
ajunge napoi la armata 1. Va avea loc atacul n acest caz? Probabil c nu, deoarece
comandantul armatei 2 nu tie dac rspunsul su a ajuns sau nu la destinaie. Dac nu a
ajuns, armata 1 nu va ataca, deci ar fi o prostie din partea lui s intre n lupt.
Se ncearc mbuntirea protocolului, transformndu-l ntr-unul cu nelegere n trei pai.
Iniiatorul propunerii de atac trebuie s confirme rspunsul. Presupunnd c nici un mesaj nu
este pierdut, armata 2 va avea confirmarea, dar comandantul armatei 1 va ezita acum. Pn la
urm, el nu tie dac confirmarea sa a ajuns la destinaie i este sigur c dac aceasta nu a
ajuns, armata 2 nu va ataca. Se ncearc un protocol cu confirmare n patru timpi, dar ne-am
lovi de aceleai probleme.
De fapt, poate fi demonstrat c nu exist un protocol care s funcioneze. Se presupune c ar
exista un asemenea protocol: decizia final poate s depind sau nu de ultimul mesaj al unui
asemenea protocol. Dac nu depinde, se poate elimina acest mesaj (i oricare altul la fel) pn
se ajunge la un protocol n care orice mesaj este vital. Ce se va ntmpla dac ultimul mesaj
este interceptat? Tocmai s-a hotrt c acest mesaj era unul vital, deci dac este pierdut, atacul
nu va avea loc. Deoarece cel care trimite ultimul mesaj nu poate fi niciodat sigur c mesajul a
ajuns, el nu va risca atacnd. Mai ru chiar, cealalt armat albastr tie i ea acest lucru, deci
nu va ataca nici ea.
Pentru a vedea legtura problemei celor dou armate cu problema eliberrii conexiunii este
suficient s se nlocuiasc atac cu deconectare. Dac niciuna din pri nu se deconecteaz
pn nu este sigur c cealalt parte este gata s se deconecteze la rndul ei, atunci
deconectarea nu va mai avea loc niciodat.
Figura 10-13 prezint patru scenarii de eliberare a conexiunii folosind un protocol cu confirmare
n trei timpi. n Figura 10-13(a) apare cazul normal n care unul dintre utilizatori trimite un TPDU
de tip DR (DISCONNECT REQUEST) pentru a iniia eliberarea conexiunii. Atunci cnd acesta
sosete, receptorul trimite napoi tot un TPDU DR i pornete un ceas pentru a trata cazul n
care mesajul su este pierdut. Cnd primete mesajul napoi, iniiatorul trimite o confirmare i
elibereaz conexiunea. n sfrit, la primirea confirmrii, receptorul elibereaz i el conexiunea.
Eliberarea conexiunii nseamn de fapt c entitatea de transport terge din tabelele sale
informaia despre conexiunea respectiv din tabela de conexiuni deschise n momentul curent
20

i semnaleaz acest lucru utilizatorului nivelului transport. Aceast aciune nu este acelai lucru
cu apelul unei primitive DISCONNECT de ctre un utilizator al nivelului transport.
Dac ultima confirmare este pierdut, ca n Figura 10-13(b), se poate salva situaia cu ajutorul
ceasului: dup scurgerea unui anumit interval de timp conexiunea este eliberat oricum.
Figura 10-13 Patru cazuri posibile la eliberarea conexiunii: (a)Cazul normal cu confirmare n
trei timpi. (b)Ultima confirmare este pierdut. (c) Rspunsul este pierdut. (d) Rspunsul i
urmtoarele cereri de deconectare sunt pierdute. (DR=DISCONNECT REQUEST).
Se consider acum cazul n care cel de-al doilea DR este pierdut: utilizatorul care a iniiat deconectarea nu va primi rspunsul ateptat, va atepta un anumit timp i va trimite din nou un
DR. n Figura 10-13(c), se poate vedea cum se petrec lucrurile n acest caz, presupunnd c la
a doua ncercare toate TPDU-urile ajung corect i la timp.
Ultima posibilitate pe care o studiem, prezentat n Figura 10-13(d), este similar cu cea din
21

Figura 10-13(c), cu urmtoarea diferen: de aceasta dat niciuna din ncercrile urmtoare de
a retransmite DR nu reuete. Dup N ncercri, emitorul va elibera pur i simplu conexiunea.
n acelai timp, i receptorul va elibera conexiunea dup expirarea timpului.
Dei acest protocol este, n general, destul de bun, n teorie el poate s dea gre dac att
mesajul DR iniial ct i N retransmisii ale sale se pierd. Emitorul va renuna i va elibera
conexiunea, n timp ce la cellalt capt nu se tie nimic despre ncercrile de deconectare i
aceasta va rmne n continuare activ. n aceast situaie rezult o conexiune deschis pe
jumtate.
S-ar putea evita aceast problem nepermind emitorului s cedeze dup N rencercri
nereuite, ci cerndu-i s continue pn primete un rspuns. Totui, dac celeilalte pri i se
permite s elibereze conexiunea dup un interval de timp, este posibil ca iniiatorul s ajung s
atepte la infinit. Dac ns nu s-ar permite eliberarea conexiunii dup expirarea unui interval de
timp, atunci n cazul din Figura 10-13 (b) protocolul s-ar bloca.
O alt posibilitate de a scpa de conexiunile pe jumtate deschise este de a aplica o regul de
tipul: dac nici un TPDU nu sosete ntr-un anumit interval de timp, atunci conexiunea este
eliberat automat. n acest fel, dac una din pri se deconecteaz, cealalt parte va detecta
lipsa de activitate i se va deconecta i ea. Desigur, pentru a implementa aceasta regul este
nevoie ca fiecare entitate de transport s aib un ceas care va fi repornit la trimiterea oricrui
TPDU. La expirarea timpului, se transmite un TPDU vid, doar pentru a menine conexiunea
deschis. Pe de alt parte, dac este aleas aceast soluie, i cteva TPDU-uri vide sunt
pierdute la rnd pe o conexiune altfel liber, este posibil ca, mai nti una din pri, apoi cealalt
s se deconecteze automat.
2.3 Controlul fluxului i memorarea temporar (buffering)

n continuare, se va arunca o privire asupra modului n care sunt tratate conexiunile ct timp
sunt utilizate. Una din problemele cheie a aprut i pn acum: controlul fluxului. La nivel
transport exist asemnri cu problema controlului fluxului la nivel legtur de date, dar exist
i deosebiri. Principala asemnare: la ambele niveluri este necesar un mecanism (fereastr
glisant sau altceva) pentru a mpiedica un emitor prea rapid s depeasc capacitatea de
recepie a unui receptor prea lent. Principala deosebire: un ruter are n general puine linii, dar
poate s aib numeroase conexiuni. Aceast diferen face nepractic implementarea la nivel
transport a strategiei de memorare temporar a mesajelor folosit la nivel legtur de date.
La nivel legtur de date, emitorul trebuie s memoreze cadrele transmise, pentru c poate fi
necesar retransmiterea acestora. Dac subreeaua ofer un serviciu datagram, atunci
entitatea de transport emitoare va trebui s memoreze pachetele trimise din aceleai motive.
22

Dac receptorul tie c emitorul stocheaz toate TPDU-urile pn cnd acestea sunt
confirmate, el poate s aloce sau nu tampoane specifice fiecrei conexiuni, dup cum i se pare
mai bine.
Receptorul poate, de exemplu, s rezerve un singur grup de tampoane pentru toate
conexiunile. La sosirea unui TPDU se face o ncercare de a obine dinamic un nou tampon.
Dac un tampon este liber, atunci TPDU-ul este acceptat, altfel, este refuzat. Cum emitorul
este gata s retransmit TPDU-urile pierdute de subreea, faptul c unele TPDU-uri sunt
refuzate nu produce nici o daun, dei n acest fel sunt risipite resurse. Emitorul va
retransmite pn cnd va primi confirmarea.
Pe scurt, dac serviciul reea nu este sigur, emitorul va trebui s memoreze toate TPDU-urile
trimise, la fel ca la nivel legtur de date. Totui, folosind un serviciu la nivel reea sigur sunt
posibile unele compromisuri. n particular, dac emitorul tie c receptorul are ntotdeauna
tampoane disponibile, atunci nu trebuie s pstreze copiile TPDU-urilor trimise. Totui, dac
receptorul nu poate garanta c orice TPDU primit va fi acceptat, emitorul va trebui s pstreze
copii. n ultimul caz, emitorul nu poate avea ncredere n confirmarea primit la nivel reea,
deoarece aceasta confirm sosirea TPDU-ului la destinaie, dar nu i acceptarea lui.
Figura 10-14 (a) Tampoane de dimensiune fix nlnuite. (b) Tampoane de dimensiune
variabil nlnuite. (c) Un tampon circular pentru fiecare conexiune.
Chiar dac receptorul va realiza memorarea temporar a mesajelor primite, mai rmne problema dimensiunii tamponului. Dac cea mai mare parte a TPDU-urilor au aceeai dimensiune,
este natural organizarea tampoanelor ntr-o resurs comun care conine tampoane de
aceeai dimensiune, cu un TPDU per tampon, ca n Figura 10-14(a). Dac ns dimensiunea
23

TPDU-urilor variaz de la cteva caractere tiprite la un terminal, la mii de caractere pentru un
transfer de fiiere, organizarea ca o resurs comun cu tampoane de aceeai dimensiune va
pune probleme. Dac dimensiunea tampoanelor ar fi constant, egal cu cel mai mare TPDU
posibil, atunci va aprea o risip de spaiu ori de cte ori este primit un TPDU mai scurt. Dac
dimensiunea tampoanelor este aleas mai mic dect cel mai mare TPDU posibil, atunci pentru
memorarea unui TPDU mai lung vor fi necesare mai multe tampoane, iar complexitatea
operaiei va crete.
O alt soluie este utilizarea unor tampoane de dimensiune variabil, ca n Figura 10-14(b).
Avantajul este o mai bun utilizare a memoriei, cu preul unei gestiuni a tampoanelor mai
complicat. O a treia posibilitate este alocarea unui singur tampon circular pentru fiecare
conexiune, ca n Figura 10-14(c). Aceast soluie are de asemenea avantajul unei utilizri
eficiente a memoriei, dar numai n situaia n care conexiunile sunt relativ ncrcate.
Compromisul optim ntre memorarea temporar la surs sau la destinaie depinde de tipul
traficului prin conexiune. Pentru un trafic n rafal cu o band de transfer ngust, ca traficul
produs de un terminal interactiv, este mai bine ca tampoanele s nu fie prealocate, ci mai
curnd, alocate dinamic. ntruct emitorul nu poate s fie sigur c receptorul va reui s aloce
un tampon la sosirea unui pachet, emitorul va fi nevoit s rein copia unui TPDU transmis
pn cnd acesta va fi confirmat. Pe de alt parte, pentru un transfer de fiiere sau pentru orice
alt trafic care necesit o band de transfer larg este mai bine dac receptorul aloc un set
ntreg de tampoane, pentru a permite un flux de date la vitez maxim. Cu alte cuvinte, pentru
un trafic n rafal cu o band de transfer ngust este mai bine s fie folosite tampoane la
emitor, n timp ce pentru un trafic continuu cu o band de transfer larg, este mai eficient
folosirea tampoanelor la receptor
Pe msur ce conexiunile sunt create i eliberate de trafic, iar ablonul se schimb, emitorul
i receptorul trebuie s i ajusteze dinamic politica de alocare a tampoanelor. n consecin,
protocolul de transport trebuie s permit emitorului s cear spaiu pentru tampoane la
captul cellalt al conexiunii. Tampoanele pot fi alocate pentru o anumit conexiune sau pot fi
comune pentru toate conexiunile ntre dou calculatoare gazd. O alternativ este ca
receptorul, cunoscnd situaia tampoanelor sale (dar necunoscnd ablonul traficului) s poat
spune emitorului: Am rezervat X tampoane pentru tine. Dac numrul conexiunilor deschise
trebuie s creasc, poate fi necesar ca spaiul alocat unei singure conexiuni s scad, deci
protocolul trebuie s furnizeze i aceast facilitate.
O modalitate neleapt de a trata alocarea dinamic a tampoanelor este separarea stocrii n
tampoane de confirmarea mesajelor. Alocarea dinamic a tampoanelor nseamn, de fapt, o
fereastr cu dimensiune variabil. La nceput, emitorul trimite cereri pentru un anumit numr
de tampoane bazndu-se pe o estimare a necesitilor. Receptorul i aloc attea tampoane ct
24

i poate permite. De fiecare dat cnd emitorul trimite un TPDU, el decrementeaz numrul
de tampoane pe care le are alocate la receptor, oprindu-se cnd acest numr devine zero.
Receptorul trimite napoi confirmri i situaia tampoanelor alocate, mpreun cu traficul n sens
invers.
Figura 10-15 Alocarea dinamic a tampoanelor. Sgeile indic direcia transmisiei. Punctele
de suspensie (...) indic pierderea unui TPDU.
Figura 10-15 este un exemplu pentru modul n care administrarea dinamic a ferestrelor poate fi
folosit ntr-o subreea cu datagrame, cu numere de secven pe 4 bii. Se presupune c
informaia despre alocarea tampoanelor este mpachetat n TPDU-uri distincte i c este
separat de traficul n sens invers. La nceput A dorete opt tampoane, dar nu i se acord dect
patru. Dup aceea trimite trei TPDU-uri, iar al treilea este pierdut. TPDU-ul 6 confirm recepia
tuturor TPDU-urilor cu numere de secven mai mici sau egale cu 1, permind lui A s
elibereze acele tampoane i, mai mult, l informeaz pe A c B poate s mai recepioneze trei
TPDU-uri (adic TPDU-urile cu nu-mere de secven 2, 3, 4). A tie c a trimis deja numrul 2,
deci se gndete c ar putea trimite 3 i 4, ceea ce i ncearc s fac. n acest moment, el
este blocat i trebuie s atepte alocarea unui tampon. Expirarea timpului pentru primirea
confirmrii determin retransmisia mesajului 2 (linia 9), care poate avea loc, dei emitorul este
blocat, deoarece se vor utiliza tampoane deja alocate. n linia 10, B confirm primirea tuturor
TPDU-urilor pn la 4, dar l ine pe A nc blocat. Urmtorul TPDU de la B la A aloc nc un
tampon i i permite lui A s continue.
n cazul strategiilor pentru alocarea tampoanelor de tipul celei de mai sus, eventuale probleme
25

pot s apar n reele neorientate pe conexiune dac sunt pierdute TPDU-uri de control. S
privim linia 16 din Figura 10-15: B a mai alocat tampoane pentru A, dar TPDU-ul care
transmitea aceast informaie a fost pierdut. Deoarece TPDU-urile de control nu sunt
numerotate sau retransmise, A va fi blocat. Pentru a preveni aceast situaie, fiecare calculator
gazd trebuie s trimit periodic pe fiecare conexiune TPDU-uri de control ce pot conine
confirmri i informaii despre starea tampoanelor. n acest fel, A va fi deblocat mai devreme
sau mai trziu.
Pn acum s-a presupus c singura limit impus ratei de transfer a emitorului este legat de
dimensiunea spaiului alocat la receptor pentru tampoane. Deoarece preul memoriei continu
s scad vertiginos, ar putea deveni posibil echiparea unei gazde cu suficient de mult
memorie, astfel nct lipsa tampoanelor s pun rar probleme, dac le va pune vreodat.
Atunci cnd spaiul de memorie alocat pentru tampoane nu limiteaz fluxul maxim, va aprea o
alt limitare: capacitatea de transport a subreelei. Dac dou rutere adiacente pot s schimbe
cel mult x pachete pe secund i exist k ci distincte ntre dou calculatoare gazd, atunci
este imposibil transferul la o rat mai mare de k * x TPDU-uri pe secund, orict de multe
tampoane ar fi alocate la cele dou capete ale conexiunii. Dac emitorul se grbete prea
tare (adic trimite mai mult de k * x TPDU-uri pe secund), reeaua se va congestiona,
deoarece nu va putea s livreze datele le fel de repede cum le primete.
Este necesar un mecanism bazat pe capacitatea de transport a subreelei i nu pe capacitatea
de memorare n tampoane a receptorului. Evident, mecanismul de control al fluxului trebuie
aplicat la emitor pentru a preveni existena prea multor TPDU-uri neconfirmate la acesta.
Belsens (1975) a propus folosirea unei scheme cu fereastr glisant n care emitorul modific
dinamic dimensiunea ferestrei pentru a o potrivi la capacitatea de transport a reelei. Dac
reeaua poate s transporte c TPDU-uri pe secund i durata unui ciclu (incluznd transmisia,
propagarea, timpul petrecut n cozi, prelucrarea la destinaie i revenirea confirmrii) este r,
atunci dimensiunea ferestrei la emitor trebuie s fie c * r . Folosind o fereastr cu aceast
dimensiune, emitorul va putea lucra la capacitate maxim. Orice mic scdere a
performanelor reelei va genera blocri ale emitorului. Pentru a ajusta periodic dimensiunea
ferestrei, emitorul poate urmri cei doi parametri, dup care poate calcula dimensiunea dorit
a ferestrei. Capacitatea de transport a subreelei poate fi determinat pur i simplu numrnd
TPDU-urile confirmate ntr-o anumit perioad de timp i raportnd la acea perioad. n timpul
msurtorii, emitorul trebuie s transmit ct mai repede pentru a fi sigur c factorul care
limiteaz numrul confirmrilor este capacitatea de transport a subreelei i nu rata mic de
emisie. Timpul necesar pentru ca un TPDU transmis s fie confirmat poate fi msurat cu
exactitate i media poate fi calculat continuu. Deoarece capacitatea de transport a reelei
disponibil pentru orice flux dat variaz n timp, dimensiunea ferestrei trebuie ajustat frecvent
pentru a urmri schimbrile n capacitatea de transport.
26

2.4 Multiplexarea
Multiplexarea mai multor conversaii pe conexiuni, circuite virtuale i legturi fizice joac un rol
important n mai multe niveluri ale arhitecturii reelei. n cazul nivelului transport, multiplexarea
poate fi necesar din mai multe motive. De exemplu, dac doar o singur adres de reea este
disponibil pe o gazd, toate conexiunile transport de pe acea main trebuie s o foloseasc.
Cnd un TDPU sosete este necesar un mod de a spune crui proces trebuie dat. Aceast
situaie numit multiplexare n sus, este prezentat n Figura 10-16(a). n aceast figur, patru
conexiuni transport diferite folosesc n comun aceeai conexiune reea (de exemplu, adresa IP)
ctre calculatorul gazd de la distan.
Figura 10-16 (a) Multiplexare n sus. (b) Multiplexare n jos.
Multiplexarea poate s fie util nivelului transport i din alt motiv, legat de deciziile tehnice i nu
de politica de preuri ca pn acum. S presupunem, de exemplu, c o subreea folosete
intern circuite virtuale i impune rat de date maxim p fiecare dintre ele. Dac un utilizator are
nevoie de mai mult lime de band dect poate oferi un circuit virtual, o soluie este ca nivelul
transport s deschid mai multe conexiuni reea i s distribuie traficul prin acestea (ntr-un
sistem round-robin), la fel ca n Figura 10-16(b). Acest mod de operare se numete
multiplexare n jos. n cazul a k conexiuni reea deschise limea de band real este
multiplicat cu un factor k. Un exemplu obinuit de multiplexare n jos apare la utilizatorii care
au acas o linie ISDN. Aceast linie pune la dispoziie dou conexiuni separate de 64 Kbps.
Folosirea ambelor pentru apelul unui distribuitor de Internet i mprirea traficului pe ambele
linii, face posibil atingerea unei limi de band efectiv de 128 Kbps.
27

2.5 Refacerea dup cdere
n cazul n care calculatoarele gazd sau ruterele se ntmpl s cad, recuperarea dup o
astfel de cdere devine o problem. Dac entitatea de transport este n ntregime coninut de
calculatorul gazd, atunci revenirea dup o cdere a reelei sau a unui ruter este simpl. Dac
nivelul reea furnizeaz un serviciu datagram, atunci entitatea de transport tie s rezolve
problema TPDU-urilor pierdute. Dac nivelul reea furnizeaz un serviciu orientat pe conexiune,
atunci pierderea unui circuit virtual este tratat stabilind un circuit virtual nou i apoi ntrebnd
entitatea de transport aflat la distan care TPDU-uri a primit deja i ce TPDU-uri nu. Acestea
din urm pot fi retransmise.
Cderea unui calculator gazd pune o problem mult mai suprtoare. n particular, clienii pot
dori s continue s lucreze imediat dup ce serverul cade i repornete. Pentru a ilustra
aceast dificultate, se presupune c o gazd (clientul) trimite un fiier lung unei alte gazde
(serverul) folosind un protocol simplu de tip pas-cu-pas (stop-and-wait). Nivelul transport de pe
server nu face dect s paseze utilizatorului TPDU-urile primite, unul cte unul. Dac n timpul
transmisiei serverul cade, la revenirea acestuia tabelele sunt reiniializate i serverul nu va mai
ti precis unde a rmas.
ntr-o ncercare de a reveni n starea sa iniial, serverul ar putea s trimit cereri tuturor
celorlalte gazde anunnd c tocmai s-a refcut dup o cdere i cernd clienilor s-l
informeze despre situaia tuturor conexiunilor deschise. Fiecare client poate fi n una din
urmtoarele stri: un TPDU neconfirmat (starea S1) sau nici un TPDU neconfirmat (starea S0).
Bazndu-se numai pe aceast informaie, clientul trebuie s decid dac s retransmit sau nu
cel mai recent TPDU.
La prima vedere pare evident: atunci cnd afl de cderea i revenirea serverului, clientul
trebuie s retransmit doar dac are TPDU-uri neconfirmate (adic este n starea S1). Totui, o
privire mai atent descoper dificultile care apar n aceast abordare naiv. Se consider, ca
exemplu, situaia n care entitatea de transport de pe server trimite mai nti confirmarea i apoi,
dup ce confirmarea a fost trimis, paseaz datele procesului aplicaie. Trimiterea confirmrii i
transferul datelor procesului aplicaie sunt dou evenimente distincte care nu pot avea loc
simultan. Dac o cdere a serverului are loc dup trimiterea confirmrii, dar nainte de transferul
datelor, clientul va primi confirmarea i se va afla n starea S0, atunci cnd anunul despre
cdere ajunge la el. n acest caz, clientul nu va mai retransmite (ceea ce este incorect), creznd
c TPDU-ul respectiv a fost recepionat. Aceast decizie a clientului va conduce la lipsa unui
TPDU.
n acest moment s-ar putea spune: Nimic mai simplu! Tot ceea ce trebuie fcut este s se
reprogrameze entitatea de transport astfel, nct s se transfere datele mai nti i s se trimit
confirmarea dup aceea!. Dac transferul datelor a avut loc, dar serverul cade nainte s trimit
28

confirmarea, clientul va fi n starea S1, va retransmite i astfel se va avea un TPDU duplicat n
fluxul de date ctre procesul aplicaie.
Oricum ar fi proiectai clientul i serverul, ntotdeauna vor exista situaii n care revenirea dup o
cdere nu se va face corect. Serverul poate fi programat n dou feluri: s fac mai nti
confirmarea sau s transfere mai nti datele. Clientul poate fi programat n patru feluri: s
retransmit ntotdeauna ultimul TPDU, s nu retransmit niciodat, s retransmit numai n
starea S0, s retransmit numai n starea S1. Rezult astfel opt combinaii, dar, pentru fiecare
combinaie exist o anumit succesiune de evenimente pentru care protocolul nu funcioneaz
corect.
La server sunt posibile trei evenimente: trimiterea unei confirmri (A), transferul datelor la procesul aplicaie (T) i cderea (C). Aceste trei evenimente pot s fie ordonate n 6 feluri: AC(T),
ATC, C(AT), C(TA), TAC i TC(A). Parantezele sunt folosite pentru a indica faptul c nici A, nici
T nu pot urma dup C (odat ce serverul a czut, e bun czut). Figura 10-17 prezint toate cele
opt combinaii ale strategiilor clientului i serverului i prezint secvenele valide pentru fiecare
din ele. Se observ c pentru orice strategie exist o secven de evenimente pentru care
protocolul nu funcioneaz corect. De exemplu, dac clientul retransmite ntotdeauna, secvena
ATC va genera un duplicat care nu poate fi detectat, n timp ce pentru celelalte dou secvene
totul este n regul.
Figura 10-17 Combinaiile diferitelor strategii posibile pentru server i client.
ncercarea de a reproiecta mai minuios protocolul nu ajut. Chiar dac clientul i serverul
schimb mai multe TPDU-uri nainte ca serverul s transfere datele, astfel nct clientul tie
exact ceea ce se petrece pe server, nu poate afla dac serverul a czut imediat nainte sau
imediat dup transferul datelor. Concluzia se impune de la sine: dat fiind condiia de baz ca
dou evenimente s nu fie simultane, revenirea dup o cdere nu poate fi fcut transparent
29

pentru nivelurile superioare.
n termeni mai generali, acest rezultat poate fi reformulat astfel: restartarea dup o cdere a nivelului N nu poate fi fcut dect de ctre nivelul N+1, i aceasta doar dac nivelul superior
reine suficient informaie de stare. Nivelul transport poate s revin dup erorile nivelului reea
numai dac fiecare capt al conexiunii ine minte unde a rmas.
n principiu, protocolul de transport este unul capt-la-capt i nu nlnuit ca la nivelurile de mai
jos. Se consider cazul unui utilizator care genereaz cereri de tranzacii pentru o baz de date
de la distan. Se presupune c entitatea de transport aflat la distan este programat s
trimit mai nti TPDU-ul nivelului superior i apoi s confirme. Chiar i n acest caz, primirea
unei confirmri de ctre maina utilizator nu nseamn neaprat c maina gazd de la distan
a avut timp s actualizeze baza de date. De fapt, o adevrat confirmare capt-la-capt, a crei
primire arat c s-au efectuat toate prelucrrile de ctre maina de la distan, este probabil
imposibil de obinut.
3. Protocoale de transport prin Internet: UDP
Internet-ul are dou protocoale principale n nivelul de transport: unul neorientat pe conexiune i
unul orientat pe conexiune. Protocolul neorientat pe conexiune se numete UDP. Protocolul
orientat pe conexiune se numete TCP.
3.1.
Introducere n UDP
Setul de protocoale Internet suport un protocol de transport fr conexiune, UDP (User

Datagram Protocol Protocol cu Datagrame Utilizator). UDP ofer aplicaiilor o modalitate de
a trimite datagrame IP ncapsulate i de a le transmite fr a fi nevoie s stabileasc o
conexiune. UDP este descris n RFC 768.
Figura 10-18 Antetul UDP.

UDP transmite segmente constnd ntr-un antet de 8 octei urmat de informaia util . Antetul
30

este prezentat n Figura 10-18. Cele dou porturi servesc la identificarea punctelor terminale ale
mainilor surs i destinaie. Cnd ajunge un pachet UDP, coninutul su este predat procesului
ataat portului destinaie. Aceast ataare are loc atunci cnd se folosete o simpl procedur
de nume sau ceva asemntor. De fapt, valoarea cea mai important dat de existena UDPului fa de folosirea doar a IPului simplu, este aceea a adugrii porturilor surs i destinaie.
Fr cmpurile portului, nivelul de transport nu ar ti ce s fac cu pachetul. Cu ajutorul lor,
segmentele se livreaz corect.
Portul surs este n primul rnd necesar atunci cnd un rspuns trebuie transmis napoi la
surs. Prin copierea cmpului port surs din segmentul care sosete n cmpul port destinaie
al segmentului care pleac, procesul ce trimite rspunsul specific ce proces de pe maina de
trimitere urmeaz s-l primeasc. Cmpul lungime UDP include antetul de 8 octei i datele.
Cmpul sum de control UDP este opional i stocat ca 0 (zero) dac nu este calculat (o
valoare de adevr 0 rezultat n urma calculelor este memorat ca un ir de bii 1).
Dezactivarea acestuia este o prostie, excepie fcnd cazul n care calitatea informaiei chiar nu
conteaz (de exemplu, transmisia vocal digitalizat).
Merit probabil menionate, n mod explicit, unele dintre lucrurile pe care UDP-ul nu le face. Nu
realizeaz controlul fluxului, controlul erorii, sau retransmiterea unui segment incorect primit.
Toate acestea depind de procesele utilizatorului. Ceea ce face este s ofere protocolului IP o
interfa cu faciliti adugate de demultiplexare a mai multor procese, folosind porturi. Aceasta
este tot ceea ce face UDP-ul.
Un domeniu unde UDP-ul este n mod special util este acela al situaiilor client-server. Deseori,
clientul trimite o cerin scurt server-ului i ateapt napoi un rspuns scurt. Dac se pierde
ori cererea ori rspunsul, clientul poate pur i simplu s ncerce din nou dup ce a expirat
timpul. Nu numai c va fi mai simplu codul, dar sunt necesare i mai puine mesaje (cte unul n
fiecare direcie) dect la un protocol care solicit o iniializare iniial.
O aplicaie care folosete UDP-ul n acest fel este DNS (Domain Name System, rom: Sistem de
rezolvare de nume). Pe scurt, un program care trebuie s caute adresele de IP ale unor nume
gazd, de exemplu www.cs.berkley.edu , poate trimite un pachet UDP, coninnd numele
gazd, ctre un server DNS. Serverul rspunde cu un pachet UDP coninnd adresa de IP a
gazdei. Nu este necesar nici o iniializare n avans i nici o nchidere de sesiune. Doar dou
mesaje traverseaz reeaua.
3.2.
Apel de procedur la distan (Remote Procedure Call)
ntr-un anume sens, trimiterea unui mesaj ctre o staie la distan i primirea napoi a unui rspuns seamn mult cu realizarea unei funcii de apel ntr-un limbaj de programare. n ambele
31

cazuri se ncepe cu unul sau mai muli parametri i se primete napoi un rezultat. Aceast
observaie le-a fcut pe unele persoane s ncerce s organizeze interaciunile cerere-rspuns
n reele pentru a fi puse mpreun sub forma apelurilor procedurale. Un astfel de aranjament
face aplicaiile de reea mai uor programabile i mai abordabile. De exemplu, imaginai-v doar
procedura numit get_IP_address(host_name) care funcioneaz prin trimiterea unui pachet
UDP ctre un server DNS i ateptarea rspunsului, cronometrnd i ncercnd nc o dat,
dac rspunsul nu apare suficient de rapid. n acest fel, toate detaliile de reea pot fi ascunse
programatorului.
Efortul cel mai important n acest domeniu a fost depus de ctre Birell i Nelson (1984). Rezumnd, ce au sugerat Birell i Nelson a fost s permit programelor s apeleze proceduri
localizate pe staii aflate la distan. Cnd procesul de pe maina 1 invoc o procedur de pe
maina 2, procesul apelant de pe prima main este suspendat i execuia procedurii invocate
are loc pe cea de-a doua. Informaia poate fi transportat de la cel care apeleaz la cel care
este apelat n parametri i se poate ntoarce n rezultatul procedurii. Nici un transfer de mesaje
nu este vizibil pentru programator. Tehnica este cunoscut sub numele de RPC (Remote
Procedure Call Apel de procedur la distan), i a devenit baza pentru multe aplicaii de
reea. n mod tradiional, procedura care apeleaz este cunoscut ca fiind clientul i procedura
apelat ca fiind serverul i se va folosi aceste denumiri i aici.
Ideea din spatele RPC-ului este aceea de a face un apel de procedur la distan s arate pe
ct posibil ca unul local. n forma cea mai simpl, pentru apelarea unei proceduri la distan,
programul client trebuie sa fie legat cu o mic procedur de bibliotec, numit client stub (ciot),
care reprezint procedura server-ului n spaiul de adres al clientului. n mod similar, serverul
este legat cu o procedur numit server stub . Aceste proceduri ascund faptul c apelul de
procedur de la client la server nu este local.
Paii efectivi ai realizrii unui RPC sunt prezentai n Figura 10-19. Pasul 1 este cel n care
clientul apeleaz stub-ul client. Acest apel este un apel de procedur local, cu parametrii
introdui n stiv n modul obinuit. Pasul 2 const n mpachetarea parametrilor de ctre stub-ul
client ntr-un mesaj i realizarea unui apel de sistem pentru a trimite mesajul. mpachetarea
parametrilor este denumit marshaling (mpachetare). Pasul 3 const n faptul c nucleul
sistemului de operare trimite un mesaj de la maina client la maina server. Pasul 4 const n
trimiterea de ctre nucleu a pachetelor care sosesc la stub-ul server. n sfrit, pasul 5 const n
faptul c stub-ul server apeleaz procedura server cu parametrii despachetai. Rspunsul
urmeaz aceeai cale i n cealalt direcie.
Elementul cheie de reinut aici este acela c procedura client, scris de ctre utilizator, doar
face un apel normal de procedur (adic local) ctre stub-ul client, care are acelai nume cu
procedura server. Cum procedura client i stub-ul client se gsesc n acelai spaiu de adres,
32

parametrii sunt transferai n modul obinuit. n mod asemntor, procedura server este apelat
de o procedur din spaiul su de adres cu parametrii pe care i ateapt. Pentru procedura
server nimic nu este neobinuit. n felul acesta, n loc ca intrarea/ieirea s se fac pe socluri,
comunicaia de reea este realizat imitnd o procedur de apelare normal.
Figura 10-19 Paii pentru a crea un apel de procedur la distan. Stub-urile sunt haurate.
n ciuda eleganei conceptului de RPC, sunt civa erpi care se ascund prin iarb. Unul mare
este utilizarea parametrilor pointer. n mod normal, transmiterea unui pointer ctre procedur nu
este o problem. Procedura apelat poate folosi pointer-ul n acelai mod n care poate s o
fac i cel care o apeleaz, deoarece ambele proceduri se gsesc n acelai spaiu de adrese
virtuale. Cu RPC-ul, transmiterea pointer-ilor este imposibil deoarece clientul i server-ul se
gsesc n spaii de adres diferite. n anumite cazuri, se pot folosi unele trucuri pentru a face
posibil transmiterea pointer-ilor. Se presupune c primul parametru este un pointer ctre un
ntreg, k. Stub-ul client poate mpacheta variabila k i s o trimit server-ului. Atunci, server stub
creeaz un pointer ctre k i-l transmite procedurii server, exact aa cum aceasta se ateapt.
Cnd procedura server cedeaz controlul server stub, acesta din urm trimite variabila k napoi
clientului, unde noul k este copiat peste cel vechi, n caz c serverul l-a schimbat. n fapt,
secvena standard de apelare apel-prin-referin a fost nlocuit de copiaz-restaureaz (eng.:
copy-restore). Din pcate, acest truc nu funcioneaz ntotdeauna, de exemplu dac un pointer
este ctre un grafic sau alt structur complex de date. Din acest motiv, trebuie puse anumite
restricii asupra parametrilor procedurilor apelate la distan.
O a doua problem este aceea c n limbajelor mai puin bazate pe tipuri, cum ar fi C-ul, este
perfect legal s scrii o procedur care calculeaz produsul scalar a doi vectori, fr a specifica
dimensiunea vreunuia dintre ei. Fiecare poate fi terminat printr-o valoare special cunoscut
doar de ctre procedura apelat i de cea apelant. n aceste condiii, n mod cert este
33

imposibil pentru stub-ul client s mpacheteze parametrii: nu are nici o modalitate de a
determina ct de mult spaiu ocup acetia.
O a treia problem este aceea c nu ntotdeauna este posibil deducerea tipurilor parametrilor,
nici mcar dintr-o specificaie formal sau din cod n sine. Un exemplu este printf, care poate
avea orice numr de parametri (cel puin unul), iar parametrii pot fi o combinaie arbitrar a
tipurilor ntregi, short, long, caractere, iruri, numere n virgul mobil de diferite lungimi i alte
tipuri. A ncerca s invoci printf ca procedur cu apel la distan ar fi practic imposibil, deoarece
C-ul este prea permisiv. Totui, o regul care s spun c RPC-ul poate fi folosit cu condiia s
nu programezi n C (sau C++) nu ar fi prea popular.
O a patra problem este legat de utilizarea variabilelor globale. n mod normal, procedura de
apelare i cea care este apelat pot comunica folosind variabilele globale, n plus fa de
comunicarea prin parametri. Dac procedura apelat este mutat acum pe o main la distan,
codul va da erori deoarece variabilele globale nu mai sunt partajate.
Aceste probleme nu sunt menite s sugereze c RPC-ul este lipsit de anse. De fapt, este larg
folosit, dar sunt necesare anumite restricii pentru a-l face s funcioneze bine n practic.
Desigur, RPC-ul nu are nevoie s foloseasc pachete UDP, dar RPC i UDP se potrivesc bine,
i UDP este uzual folosit pentru RPC. Totui, cnd parametrii sau rezultatele pot s fie mai mari
dect pachetul maxim UDP sau atunci cnd operaia cerut nu este idempotent (adic nu
poate fi repetat n siguran, ca de exemplu atunci cnd se incrementeaz un contor), poate fi
necesar stabilirea unei conexiuni TCP i trimiterea cererii prin aceasta, n loc s se foloseasc
UDP-ul.
3.3.
Protocolul de transport n timp real Real-Time Transport Protocol
RPC-ul client-server este un domeniu n care UDP este mult folosit. Un alt domeniu este acela
al aplicaiilor multimedia n timp real. n particular, avnd n vedere c radioul pe internet,
telefonia pe Internet, muzica la cerere, video-conferinele, video la cerere i alte aplicaii
multimedia au devenit mai rspndite, oamenii au descoperit c fiecare aplicaie a folosit, mai
mult sau mai puin, acelai protocol de transport n timp real. Treptat a devenit clar faptul c un
protocol generic de transport n timp real, pentru aplicaii multimedia, ar fi o idee bun. Aa a
luat natere RTP-ul (Real-time Transport Protocol, Protocol de transport n timp real). Este
descris n RFC 1889 i acum este folosit pe scar larg.
Poziia RTP-ului n stiva de protocoale este oarecum ciudat. S-a hotrt s se pun RTP-ul n
spaiul utilizator i s se ruleze (n mod normal) peste UDP. El funcioneaz dup cum urmeaz.
Aplicaiile multimedia constau n aplicaii audio, video, text i posibil alte fluxuri. Acestea sunt
trimise bibliotecii RTP, care se afl n spaiul utilizator mpreun cu aplicaia. Apoi, aceast
34

bibliotec multiplexeaz fluxurile i le codeaz n pachete RTP, pe care apoi le trimite printr-un
soclu. La cellalt capt al soclului (n nucleul sistemului de operare), pachete UDP sunt
generate i ncapsulate n pachete IP. Dac computer-ul se gsete ntr-o reea Ethernet,
pachetele IP sunt puse apoi n cadre Ethernet, pentru transmisie. Stiva de protocoale pentru
aceast situaie este prezentat n Figura 10-20 (a). ncapsularea pachetului este prezentat n
Figura 10-20 (b).
Figura 10-20 (a)Poziionarea Protocolului RTP n stiva de protocoale. (b) ncapsularea

pachetului.
Ca o consecin a acestei proiectri, este cam dificil de spus n ce nivel este RTP-ul. Cum
ruleaz n spaiul utilizator i este legat la programul aplicaie, n mod cert arat ca un protocol
de aplicaie. Pe de alt parte, este un protocol generic independent de aplicaie, care doar
furnizeaz faciliti de transport, astfel nct arat totodat ca un protocol de transport. Probabil
c cea mai potrivit descriere este aceea c este un protocol de transport care este
implementat la nivelul aplicaie.
Funcia de baz a RTP-ului este multiplexarea mai multor fluxuri de date n timp real ntr-un
singur flux de pachete UDP. Fluxul UDP poate fi transmis ctre o singur destinaie (unicasting)
sau ctre destinaii multiple (multicasting). Deoarece RTP-ul folosete numai UDP normal,
pachetele sale nu sunt tratate n mod special de ctre rutere, dect dac sunt activate anumite
faciliti de calitate a serviciilor din IP. n particular, nu exist garanii speciale referitoare la
livrare, bruiaj etc.
Fiecrui pachet trimis n fluxul RTP i se d un numr cu unu mai mare dect al predecesorului
su. Aceast numerotare permite destinaiei s stabileasc dac lipsesc unele pachete. Dac
un pachet lipsete, cea mai bun decizie ce poate fi luat de ctre destinaie este de a
aproxima valoarea lips prin interpolare. Retransmiterea nu este o opiune practic avnd n
vedere c pachetul retransmis va ajunge probabil prea trziu pentru a fi util. Ca o consecin,
35

RTP-ul nu are control al fluxului, control al erorii, nu are confirmri i nu are mecanism pentru a
cere retransmiterea.
Fiecare informaie util din RTP poate s conin mostre multiple i ele pot fi codate n orice
mod dorete aplicaia. Pentru a permite compatibilitatea, RTP-ul definete mai multe profiluri
(de exemplu un singur flux audio) i pentru fiecare profil pot fi permise multiple formate de
codare. De exemplu, un singur flux audio poate fi codat ca mostre de 8 bii PCM la 8 KHz,
codare delta, codare previzibil, codare GSM, MP3 i aa mai departe. RTP-ul furnizeaz un
cmp antet n care sursa poate specifica codarea, dar altfel nu este implicat n modul n care
este fcut codarea. O alt facilitate de care au nevoie multe aplicaii multimedia este stabilirea
amprentei de timp. Aici ideea este de a permite sursei s asocieze o amprent de timp cu prima
mostr din fiecare pachet. Amprentele de timp sunt relative la nceputul fluxului, aa c numai
diferenele dintre acestea sunt semnificative. Valorile absolute nu au nici o semnificaie. Acest
mecanism permite destinaiei s foloseasc zone tampon de dimensiuni mici i s reproduc
fiecare eantion la numrul corect de milisecunde dup nceputul fluxului, independent de
momentul n care ajunge pachetul ce conine eantionul. Stabilirea amprentelor de timp nu
numai c reduce efectele bruiajului, ci permite de asemenea mai multor fluxuri s se
sincronizeze ntre ele. De exemplu, un program de televiziune digital poate avea un flux video i
dou fluxuri audio. Cele dou fluxuri audio pot fi pentru emisiuni stereo sau pentru a permite
filmelor s fie manipulate cu o coloan sonor n limba original i o coloan sonor dublat n
limba local, oferind o alegere celui care vede. Fiecare flux provine dintr-un dispozitiv fizic
diferit, dar dac sunt stabilite amprentele de timp de ctre un singur contor, ele pot fi redate
sincronizat, chiar dac fluxurile sunt transmise ntr-un mod dezordonat.
Antetul RTP este ilustrat n Figura 10-21. Acesta const din trei cuvinte de 32 bii i eventual
unele extensii. Primul cuvnt conine cmpul Versiune, care este deja la 2.
Figura 10-21 Antetul RTP-ului.

36

Bitul P indic faptul c pachetul a fost extins la un multiplu de 4 octei. Ultimul octet extins ne
spune ci octei au fost adugai. Bitul X indic prezena unui antet extins. Formatul i
semnificaia antetului extins nu sunt definite. Singurul lucru care este definit este acela c primul
cuvnt al extensiei d lungimea. Aceasta este o cale de scpare pentru orice cerine
neprevzute.
Cmpul CC arat cte surse contribuabile sunt prezente, de la 0 la 15 (vezi mai jos). Bitul M
este un bit de marcare specific aplicaiei. Poate fi folosit pentru a marca nceputul unui cadru
video, nceputul unui cuvnt ntr-un canal audio sau altceva ce aplicaia nelege. Cmpul Tip
informaie util indic ce algoritm de codare a fost folosit (de exemplu 8 bii audio necompresai,
MP3, etc). Din moment ce fiecare pachet transport acest cmp, codarea se poate schimba n
timpul transmisiei. Numrul de secven este doar un contor care este incrementat pe fiecare
pachet RTP trimis. Este folosit pentru a detecta pachetele pierdute.
Amprenta de timp este stabilit de ctre sursa fluxului pentru a se ti cnd este fcut primul
eantion din pachet. Aceast valoare poate s ajute la reducerea bruiajului la receptor prin
separarea redrii de momentul ajungerii pachetului. Identificatorul sursei de sincronizare spune
crui flux i aparine pachetul. Este metoda utilizat pentru a multiplexa i demultiplexa mai
multe fluxuri de date ntr-un singur flux de pachete UDP. n sfrit, dac exist, identificatorii
sursei care contribuie sunt folosii cnd n studio exist mixere. n acest caz, mixerul este sursa
de sincronizare i fluxurile, fiind amestecate, apar aici.
RTP are un protocol nrudit numit RTCP (Real Time Transport Control Protocol, Protocol de
control al transportului n timp real). Acesta se ocup de rspuns, sincronizare i de interfaa cu
utilizatorul, dar nu transport date. Prima funcie poate fi folosit pentru a oferi surselor reacie
(feedback) la ntrzieri, bruiaj, lime de band, congestie i alte proprieti ale reelei. Aceast
informaie poate fi folosit de ctre procesul de codare pentru a crete rata de transfer a datelor
(i s ofere o calitate mai bun) cnd reeaua merge bine i s reduc rata de transfer cnd
apar probleme pe reea. Prin furnizarea continu de rspunsuri, algoritmii de codare pot fi n
continuu adaptai pentru a oferi cea mai bun calitate posibil n circumstanele curente. De
exemplu, dac limea de band crete sau scade n timpul transmisiei, codarea poate s se
schimbe de la MP3 la PCM pe 8 bii la codare delta, aa cum se cere. Cmpul Tip informaie
util este folosit pentru a spune destinaiei ce algoritm de codare este folosit pentru pachetul
curent, fcnd posibil schimbarea acestuia la cerere.
De asemenea, RTCP-ul se ocup de sincronizarea ntre fluxuri. Problema este c fluxuri diferite
pot folosi ceasuri diferite, cu granulariti diferite i devieri de flux diferite. RTCP poate fi folosit
pentru a le menine sincronizate.
n sfrit, RTCP ofer un mod pentru a numi diversele surse (de exemplu n text ASCII). Aceast informaie poate fi afiat pe ecranul receptorului pentru a indica cine vorbete n acel
37

moment.
4. Protocoale de transport prin Internet: TCP
UDP-ul este un protocol simplu i are anumite nie de utilizare, cum ar fi interaciunile client-server i cele multimedia, dar pentru cele mai multe aplicaii de Internet este necesar un transport
de ncredere, secvenial al informaiei. UDP-ul nu poate oferi acest lucru, deci este nevoie de un
alt protocol. Acesta este TCP i este pionul principal de lucru al Internet-ului.
4.1.
Introducere n TCP
TCP (Transport Communication Protocol - protocol de comunicaie de nivel transport) a fost

proiectat explicit pentru a asigura un flux sigur de octei de la un capt la cellalt al conexiunii
ntr-o inter-reea nesigur. O inter-reea difer de o reea propriu-zis prin faptul c diferite pri
ale sale pot diferi substanial n topologie, lrgime de band, ntrzieri, dimensiunea pachetelor
i ali parametri. TCP a fost proiectat s se adapteze n mod dinamic la proprietile inter-reelei
i s fie robust n ceea ce privete mai multe tipuri de defecte.
TCP a fost definit n mod oficial n RFC 793. O dat cu trecerea timpului, au fost detectate
diverse erori i inconsistene i au fost modificate cerinele n anumite subdomenii. Aceste
clarificri, precum i corectarea ctorva erori sunt detaliate n RFC 1122. Extensiile sunt
furnizate n RFC 1323.
Fiecare main care suport TCP dispune de o entitate de transport TCP, fie ca proces
utilizator, fie ca procedur de bibliotec, fie ca parte a nucleului. n toate aceste cazuri, ea care
gestioneaz fluxurile TCP i interfeele ctre nivelul IP. O entitate TCP accept fluxuri de date
utilizator de la procesele locale, le mparte n fragmente care nu depesc 64K octei (de regul
n fragmente de aproximativ 1460 de octei, pentru a ncpea ntr-un singur cadru Ethernet
mpreun cu antetele TCP i IP) i expediaz fiecare fragment ca o datagram IP separat.
Atunci cnd datagramele IP coninnd informaie TCP sosesc la o main, ele sunt furnizate
entitii TCP, care reconstruiete fluxul original de octei. Pentru simplificare, se va folosi
cteodat doar TCP , subnelegnd prin aceasta sau entitatea TCP de transport (o poriune de
program) sau protocolul TCP (un set de reguli). Din context va fi clar care din cele dou noiuni
este referit. De exemplu, n Utilizatorul furnizeaz date TCP-ului este clar referirea la
entitatea TCP de transport.
Nivelul IP nu ofer nici o garanie c datagramele vor fi livrate corect, astfel c este sarcina
TCPului s detecteze eroarea i s efectueze o retransmisie atunci cnd situaia o impune.
Datagramele care ajung (totui) la destinaie pot sosi ntr-o ordine eronat; este, de asemenea,
38

sarcina TCP-ului s le reasambleze n mesaje respectnd ordinea corect (de secven). Pe
scurt, TCP-ul trebuie s ofere fiabilitatea pe care cei mai muli utilizatori o doresc i pe care IPul nu o ofer.
4.2.
Modelul serviciului TCP
Serviciul TCP este obinut prin crearea att de ctre emitor, ct i de ctre receptor, a unor
puncte finale, numite socluri (sockets). Fiecare soclu are un numr de soclu (adres) format din
adresa IP a mainii gazd i un numr de 16 bii, local gazdei respective, numit port. Port este
numele TCP pentru un TSAP. Pentru a obine o conexiune TCP, trebuie stabilit explicit o
conexiune ntre un soclu de pe maina emitoare i un soclu de pe maina receptoare.
Apelurile de soclu sunt prezentate n Figura 10-5.
Un soclu poate fi folosit la un moment dat pentru mai multe conexiuni. Altfel spus, dou sau mai
multe conexiuni se pot termina la acelai soclu. Conexiunile sunt identificate prin identificatorii
soclurilor de la ambele capete, adic (soclu 1, soclu 2). Nu este folosit nici un alt numr sau
identificator de circuit virtual.
Numerele de port mai mici dect 256 se numesc porturi general cunoscute i sunt rezervate
serviciilor standard. De exemplu, orice proces care dorete s stabileasc o conexiune cu o
main gazd pentru a transfera un fiier utiliznd FTP, se poate conecta la portul 21 al mainii
destinaie pentru a contacta demonul su FTP. Similar, portul 23 este folosit pentru a stabili o
sesiune de lucru la distan utiliznd TELNET. Lista porturilor general cunoscute se gsete la
www.iana.org. Cteva dintre cele foarte cunoscute sunt prezentate n Figura 10-22.
Port
21
23
25
Protocol
FTP
Telnet
SMTP
69
TFTP
79
Finger
80
110
119
HTTP
POP-3
NNTP
Utilitate
Transfer de fiiere
Login la distan
E-mail
Protocol de transfer de fiiere
trivial
Cutare de informaii despre un
utilizator
World Wide Web
Acces prin e-mail la distan
tiri USENET
Figura 10-22 Cteva porturi asignate
Cu siguran ar fi posibil ca, n momentul ncrcrii, demonul de FTP s se autoataeze la

portul 21, demonul telnet la portul 23 i tot aa. Totui, dac s-ar proceda astfel s-ar umple
memoria cu demoni inactivi n majoritatea timpului. n schimb, n general se folosete un singur
39

demon, numit inetd (Internet daemon, demon de Internet) n UNIX, care s se autoataeze la
mai multe porturi i s atepte prima conexiune care vine. Cnd acest lucru se ntmpl, inetd
creeaz un nou proces i execut n el demonul adecvat, lsnd acel demon s se ocupe de
cerere. Astfel, demonii, n afar de inetd, sunt activi doar cnd au de lucru. Inetd afl ce porturi
s foloseasc dintr-un fiier de configurare. n consecin, administratorul de sistem poate seta
sistemul s aib demoni permaneni pe cele mai ocupate porturi (de exemplu portul 80) i inetd
pe restul.
Toate conexiunile TCP sunt duplex integral i punct-la-punct. Duplex integral nseamn c traficul se poate desfura n ambele sensuri n acelai timp. Punct-la-punct indic faptul c fiecare
conexiune are exact dou puncte finale. TCP nu suport difuzarea parial sau total.
O conexiune TCP este un flux de octei i nu un flux de mesaje. Dimensiunile mesajelor nu se
conserv de la un capt la cellalt. De exemplu, dac procesul emitor execut patru scrieri de
cte 512 octei pe un canal TCP, aceste date pot fi livrate procesului receptor ca patru
fragmente (chunks) de 512 octei, dou fragmente de 1024 octei, un singur fragment de 2048
octei (Figura 10-23) sau n orice alt mod. Nu exist posibilitatea ca receptorul s determine
numrul de uniti n care a fost scris informaia.
Figura 10-23. (a) Patru segmente de 512 octei au fost trimise ca datagrame IP separate. (b)
Livrarea celor 2048 octei ctre aplicaie, printr-un singur apel read
n UNIX, aceeai proprietate o au i fiierele. Cititorul unui fiier nu poate spune dac fiierul a
fost scris bloc cu bloc, octet cu octet sau tot dintr-o dat. Ca i un fiier UNIX, programele TCP
nu au nici cea mai vag idee despre semnificaia octeilor i nici cel mai mic interes pentru a afla
acest lucru. Un octet este pur i simplu un octet.
Atunci cnd o aplicaie trimite date ctre TCP, TCP-ul le poate expedia imediat sau le poate reine ntr-un tampon (n scopul colectrii unei cantiti mai mari de informaie pe care s o
expedieze toat odat), dup bunul su plac. Cu toate acestea, cteodat, aplicaia dorete ca
informaia s fie expediat imediat. De exemplu, se presupune c un utilizator este conectat la
o main de la distan. Dup ce a fost terminat o linie de comand i s-a tastat Return, este
esenial ca linia s fie imediat expediat ctre maina de la distan i s nu fie memorat pn
la terminarea urmtoarei linii. Pentru a fora expedierea, aplicaia poate folosi indicatorul PUSH,
40

care i semnaleaz TCP-ului s nu ntrzie procesul de transmisie.
Unele din primele aplicaii foloseau indicatorul PUSH ca un fel de marcaj pentru a delimita marginile mesajelor. Dei acest truc funcioneaz cteodat, uneori el eueaz datorit faptului c,
la recepie, nu toate implementrile TCP-ului transmit aplicaiei indicatorul PUSH. Mai mult
dect att, dac mai multe indicatoare PUSH apar nainte ca primul s fi fost transmis (de
exemplu, pentru c linia de legtur este ocupat), TCP-ul este liber s colecteze toat
informaia referit de ctre aceste indicatoare ntr-o singur datagram IP, fr s includ nici
un separator ntre diferitele sale pri.
O ultim caracteristic a serviciului TCP care merit menionat aici const n informaia
urgent. Atunci cnd un utilizator apas tasta DEL sau CTRL-C pentru a ntrerupe o prelucrare
la distan, aflat deja n execuie, aplicaia emitor plaseaz o informaie de control n fluxul
de date i o furnizeaz TCP-ului mpreun cu indicatorul URGENT. Acest eveniment impune
TCP-ului ntreruperea acumulrii de informaie i transmisia imediat a ntregii informaii
disponibile deja pentru conexiunea respectiv.
Atunci cnd informaia urgent este recepionat la destinaie, aplicaia receptoare este
ntrerupt (de ex. prin emisia unui semnal, n terminologie UNIX), astfel nct, eliberat de orice
alt activitate, aplicaia s poat citi fluxul de date i s poat regsi informaia urgent.
Sfritul informaiei urgente este marcat, astfel nct aplicaia s tie cnd se termin informaia.
nceputul informaiei urgente nu este marcat. Este sarcina aplicaiei s determine acest nceput.
Aceast schem furnizeaz de fapt un rudiment de mecanism de semnalizare, orice alte detalii
fiind lsate la latitudinea aplicaiei.
4.3.
Protocolul TCP
O caracteristic important a TCP, care domin structura protocolului, este aceea c fiecare
octet al unei conexiuni TCP are propriul su numr de secven, reprezentat pe 32 bii. Cnd a
luat fiin Internetul, liniile dintre rutere erau n cel mai bun caz linii nchiriate de 56 Kbps, deci
unei gazde funcionnd la vitez maxim i lua mai mult de o sptmn s utilizeze toate
numerele de secven. La vitezele reelelor moderne, numerele de secven pot fi consumate
intr-un ritm alarmant. Numerele de secven sunt utilizate att pentru confirmri ct i pentru
mecanismul de secveniere, acesta din urm utiliznd cmpuri separate de 32 de bii din antet.
Entitile TCP de transmisie i de recepie interschimb informaie sub form de segmente. Un
segment TCP const dintr-un antet de exact 20 de octei (plus o parte opional) urmat de zero
sau mai muli octei de date. Programul TCP este cel care decide ct de mari trebuie s fie
aceste segmente. El poate acumula informaie provenit din mai multe scrieri ntr-un singur
segment sau poate fragmenta informaia provenind dintr-o singur scriere n mai multe
41

segmente. Exist dou limite care restricioneaz dimensiunea unui segment. n primul rnd,
fiecare segment, inclusiv antetul TCP, trebuie s ncap n cei 65.535 de octei de informaie
util IP. n al doilea rnd, fiecare reea are o unitate maxim de transfer sau MTU (Maximum
Transfer Unit), deci fiecare segment trebuie s ncap n acest MTU. n realitate, MTU este n
general de 1500 octei (dimensiunea informaiei utile din Ethernet), definind astfel o limit
superioar a dimensiunii unui segment.
Protocolul de baz utilizat de ctre entitile TCP este protocolul cu fereastr glisant. Atunci
cnd un emitor transmite un segment, el pornete un cronometru. Atunci cnd un segment
ajunge la destinaie, entitatea TCP receptoare trimite napoi un segment (cu informaie util,
dac aceasta exist sau fr, n caz contrar) care conine totodat i numrul de secven
urmtor pe care aceasta se ateapt s-l recepioneze. Dac cronometrul emitorului
depete o anumit valoare naintea primirii confirmrii, emitorul retransmite segmentul
neconfirmat.
Dei acest protocol pare simplu, pot aprea multe situaii particulare care vor fi prezentate mai
jos. Segmentele pot ajunge ntr-o ordine arbitrar, deci octeii 3072-4095 pot fi recepionai, dar
nu pot fi confirmai datorit absenei octeilor 2048-3071. Segmentele pot de asemenea ntrzia
pe drum un interval de timp suficient de mare pentru ca emitorul s detecteze o depire a
cronometrului i s le retransmit. Retransmisiile pot include poriuni de mesaj fragmentate
altfel dect n transmisia iniial, ceea ce impune o tratare atent, astfel nct s se in
evidena octeilor primii corect. Totui, deoarece fiecare octet din flux are un deplasament unic
fa de nceputul mesajului, acest lucru se poate realiza.
TCP trebuie s fie pregtit s fac fa unor astfel de situaii i s le rezolve ntr-o manier eficient. Un efort considerabil a fost dedicat optimizrii performanelor fluxurilor TCP, inndu-se
cont inclusiv de probleme legate de reea. n continuare vor fi prezentai un numr de algoritmi
utilizai de numeroase implementri TCP.
4.4.
Antetul segmentului TCP
n Figura 10-24 este prezentat structura unui segment TCP. Fiecare segment ncepe cu un
antet format dintr-o structur fix de 20 de octei. Antetul fix poate fi urmat de un set de opiuni
asociate antetului. n continuarea opiunilor, dac ele exist, pot urma pn la 65.535 - 20 - 20 =
65.495 de octei de date, unde primul 20 reprezint antetul IP, iar al doilea antetul TCP.
Segmente care nu conin octei de date sunt nu numai permise, dar i utilizate n mod frecvent
pentru confirmri i mesaje de control.
42
Figura 10-24 Antetul TCP.
Cmpurile Port surs i Port destinaie identific punctele finale ale conexiunii. Porturile general
cunoscute sunt definite la www.iana.org, dar fiecare gazd le poate aloca pe celelalte dup cum
dorete. Un port formeaz mpreun cu adresa IP a mainii sale un unic punct de capt (end
point) de 48 de bii. Conexiunea este identificat de punctele de capt ale sursei i destinaiei.
Cmpurile Numr de secven i Numr de confirmare au semnificaia funciilor lor uzuale. Trebuie observat c cel din urm indic octetul urmtor ateptat i nu ultimul octet recepionat n
mod corect. Ambele cmpuri au lungimea de 32 de bii, deoarece ntr-un flux TCP fiecare bit de
informaie este numerotat.
Lungimea antetului TCP indic numrul de cuvinte de 32 de bii care sunt coninute n antetul
TCP. Aceast informaie este util, deoarece cmpul Opiuni este de lungime variabil,
proprietate pe care o transmite astfel i antetului. Tehnic vorbind, acest cmp indic n realitate
nceputul date-lor din segment, msurat n cuvinte de 32 de bii, dar cum acest numr este
identic cu lungimea antetului n cuvinte, efectul este acelai.
Urmeaz un cmp de ase bii care este neutilizat. Faptul c acest cmp a supravieuit intact
mai mult de un sfert de secol este o mrturie despre ct de bine a fost proiectat TCP-ul.
Protocoale mai prost concepute ar fi avut nevoie de el pentru a corecta erori ale proiectrii
iniiale. Urmeaz acum ase indicatori de cte un bit. URG este poziionat pe 1 dac Indicatorul
Urgent este valid. Indicatorul Urgent este folosit pentru a indica deplasamentul n octei fa de
numrul curent de secven la care se gsete informaia urgent. O astfel de facilitate ine
locul mesajelor de ntrerupere. Aa cum am menionat deja anterior, aceast facilitate
reprezint esena modului n care emitorul poate transmite un semnal receptorului fr ca
TCP-ul n sine s fie cauza ntreruperii.
Bitul ACK este poziionat pe 1 pentru a indica faptul c Numrul de confirmare este valid. n cazul n care ACK este poziionat pe 0, segmentul n discuie nu conine o confirmare i cmpul
43

Numr de confirmare este ignorat.
Bitul PSH indic informaia FORAT. Receptorul este rugat respectuos s livreze aplicaiei
informaia respectiv imediat ce este recepionat i s nu o memoreze n ateptarea umplerii
tampoanelor de comunicaie (lucru care, altminteri, ar fi fcut din raiuni de eficien).
Bitul RST este folosit pentru a desfiina o conexiune care a devenit inutilizabil datorit defeciunii unei maini sau oricrui alt motiv. El este de asemenea utilizat pentru a refuza un segment
invalid sau o ncercare de deschidere a unei conexiuni. n general, recepionarea unui segment
avnd acest bit poziionat indic o problem care trebuie tratat n funcie de context.
Bitul SYN este utilizat pentru stabilirea unei conexiuni. Cererea de conexiune conine SYN = 1
i ACK = 0 pentru a indica faptul c acel cmp suplimentar de confirmare nu este utilizat.
Rspunsul la o astfel de cerere conine o confirmare, avnd deci SYN = 1i ACK = 1. n esen,
bitul SYN este utilizat pentru a indica o CERERE DE CONEXIUNE i o CONEXIUNE
ACCEPTAT, bitul ACK fcnd distincia ntre cele dou posibiliti.
Bitul FIN este folosit pentru a ncheia o conexiune. El indic faptul c emitorul nu mai are nici
o informaie de transmis. Cu toate acestea, dup nchiderea conexiunii, un proces poate
recepiona n continuare date pe o durat nedefinit. Ambele segmente, SYN i FIN, conin
numere de secven i astfel este garantat faptul c ele vor fi prelucrate n ordinea corect.
n TCP, fluxul de control este tratat prin ferestre glisante de dimensiune variabil. Cmpul Fereastr indic numrul de octei care pot fi trimii, ncepnd de la octetul confirmat. Un cmp
Fereastr de valoare 0 este perfect legal i spune c octeii pn la Numr de confirmare -1
inclusiv au fost recepionai, dar receptorul dorete cu ardoare o pauz, aa c mulumete
frumos, dar pentru moment nu dorete continuarea transferului. Permisiunea de expediere
poate fi acordat ulterior de ctre receptor prin trimiterea unui segment avnd acelai Numr de
confirmare, dar un cmp Fereastr cu o valoare nenul.
n TCP, confirmrile i permisiunea de a trimite noi date sunt total decuplate. De fapt, receptorul
poate spune: Am primit octeii pn la al k-lea, dar n acest moment nu mai doresc s primesc
alii. Aceast decuplare (care de fapt reprezint o fereastr de dimensiune variabil) ofer mai
mult flexibilitate.
Este de asemenea prevzut o Sum de control, n scopul obinerii unei fiabiliti extreme.
Aceast sum de control este calculat pentru antet, informaie i pseudo-antetul conceptual
prezentat n Figura 10-25. n momentul calculului, Suma de control TCP este poziionat pe
zero, iar cmpul de date este completat cu un octet suplimentar nul, dac lungimea sa este un
numr impar. Algoritmul de calcul al sumei de control este simplu, el adunnd toate cuvintele de
16 bii n complement fa de 1i aplicnd apoi nc o dat complementul fa de 1 asupra
sumei. n acest mod, atunci cnd receptorul aplic acelai calcul asupra ntregului segment,
44

inclusiv asupra Sumei de control, rezultatul ar trebui s fie 0.
Pseudo-antetul conine adresele IP ale mainii surs i destinaie, de 32 de bii fiecare, numrul
de protocol pentru TCP (6) i numrul de octei al segmentului TCP (incluznd i antetul). Prin
includerea pseudo-antetului n calculul sumei de control TCP se pot detecta pachetele care au
fost preluate eronat, dar procednd astfel, este negat nsi ierarhia protocolului, deoarece
adresa IP aparine nivelului IP i nu nivelului TCP.
Cmpul Opiuni a fost proiectat pentru a permite adugarea unor faciliti suplimentare neacoperite de antetul obinuit. Cea mai important opiune este aceea care permite fiecrei maini
s specifice ncrcarea maxim de informaie util TCP pe care este dispus s o accepte.
Utilizarea segmentelor de dimensiune mare este mai eficient dect utilizarea segmentelor de
dimensiune mic datorit amortizrii antetului de 20 de octei prin cantitatea mai mare de
informaie util. Cu toate acestea, este posibil ca maini mai puin performante s nu fie
capabile s manevreze segmente foarte mari. n timpul iniializrii conexiunii, fiecare parte
anun dimensiunea maxim acceptat i ateapt de la partener aceeai informaie. Ctig
cel mai mic dintre cele dou numere. Dac o main nu folosete aceast opiune, cantitatea
implicit de informaie util este de 536 octei. Toate mainile din Internet trebuie s accepte
segmente de dimensiune 536 + 20 = 556 octei. Dimensiunea maxim a segmentului nu trebuie
s fie aceeai n cele dou direcii.
Figura 10-25 Pseudo-antetul inclus n suma de control TCP.
O fereastr de 64 K octei reprezint adesea o problem pentru liniile cu o lrgime de band

mare i/sau cu ntrzieri mari. Pe o linie T3 (44.736 Mbps) trimiterea unei ferestre ntregi de 64
K octei dureaz doar 12 ms. Dac ntrzierea propagrii dus-ntors este de 50 ms (care este
valoarea tipic pentru o linie trans-continental), emitorul va atepta confirmri - fiind deci
inactiv din timp. Pe o conexiune prin satelit, situaia este chiar mai rea. O fereastr de
dimensiune mare ar permite emitorului s continue trimiterea informaiei, ns o astfel de
dimensiune nu poate fi reprezentat n cei 16 bii ai cmpului Fereastr. n RFC 1323 se
propune o opiune Scal a ferestrei, permind emitorului i receptorului s negocieze un
45

factor de scalare a ferestrei. Acest numr permite ambelor pri s deplaseze cmpul Fereastr
cu pn la 14 bii spre stnga, permind astfel ferestre de pn la 230 octei. Aceast opiune
este suportat n prezent de cele mai multe implementri ale TCP-ului.
O alt opiune propus de RFC 1106, i care este n prezent implementat pe scar larg,
const n utilizarea unei repetri selective n locul unui protocol cu ntoarcere de n pai (go back
n protocol). Dac receptorul primete un segment eronat urmat de un numr mare de segmente
corecte, protocolul TCP clasic va constata ntr-un final o depire de timp i va retrimite toate
segmentele neconfirmate, deci i pe acelea care au fost recepionate corect (adic se face o
ntoarcere de n pai). RFC 1106 introduce NAK-urile pentru a permite receptorului s cear un
anumit segment (sau segmente). Dup obinerea acestora, el poate confirma toat informaia
memorat reducnd astfel cantitatea de informaie retransmis.
4.5.
Stabilirea conexiunii TCP
n TCP conexiunile sunt stabilite utiliznd nelegerea n trei pai. Pentru a stabili o conexiune,
una din pri de exemplu serverul - ateapt n mod pasiv o cerere de conexiune prin execuia
primitivelor LISTEN i ACCEPT, putnd specifica o surs anume sau nici o surs n mod
particular.
Cealalt parte de exemplu clientul - execut o primitiv CONNECT, indicnd adresa IP i
numrul de port la care dorete s se conecteze, dimensiunea maxim a segmentului TCP pe
care este dispus s o accepte i, opional, o informaie utilizator (de exemplu o parol).
Primitiva CONNECT trimite un segment TCP avnd bitul SYN poziionat i bitul ACK
nepoziionat, dup care ateapt un rspuns.
Atunci cnd sosete la destinaie un segment, entitatea TCP receptoare verific dac nu cumva
exist un proces care a executat LISTEN pe numrul de port specificat n cmpul Port
destinaie. n caz contrar, trimite un rspuns cu bitul RST poziionat, pentru a refuza
conexiunea.
Dac exist vreun proces care ascult la acel port, segmentul TCP recepionat va fi dirijat ctre
procesul respectiv. Acesta poate accepta sau refuza conexiunea. Dac o accept, trimite napoi
expeditorului un segment de confirmare. n Figura 10-26(a) este reprezentat secvena de
segmente TCP transferate n caz de funcionare normal. De notat c un segment SYN
consum un octet din spaiul numerelor de secven, astfel nct confirmarea s poat fi fcut
fr ambiguiti.
46
Figura 10-26 (a) Stabilirea unei conexiuni TCP n cazul normal. (b) Coliziunea apelurilor.
Secvena de evenimente ilustrat n Figura 10-26(b) reprezint cazul n care dou maini
ncearc simultan s stabileasc o conexiune ntre aceleai dou porturi. Rezult c este
suficient s fie stabilit o singur conexiune i nu dou, deoarece conexiunile sunt identificate
prin punctele lor terminale. Dac prima iniializare conduce la crearea unei conexiuni identificat
prin (x, y) i acelai lucru l face i cea de-a doua iniializare, atunci este construit o singur
intrare de tabel, n spe pentru (x, y). Numrul iniial de secven asociat unei conexiuni nu
este 0, din motivele discutate anterior. Se utilizeaz o schem bazat pe un ceas cu o btaie la
fiecare 4 s. Pentru mai mult siguran , atunci cnd o main se defecteaz, este posibil ca
ea s nu fie reiniializat n timpul de via maxim al unui pachet, garantndu-se astfel c
pachetele unei conexiuni anterioare nu se plimb nc pe undeva prin Internet.
4.6.
Eliberarea conexiunii TCP
Dei conexiunile TCP sunt bidirecionale, pentru a nelege cum sunt desfiinate conexiunile, cel
mai bine este s se imagineze sub forma unei perechi de legturi unidirecionale. Fiecare
legtur unidirecional este eliberat independent de perechea sa. Pentru eliberarea unei
conexiuni, orice partener poate expedia un segment TCP avnd bitul FIN setat, lucru care
indic faptul c nici o informaie nu mai urmeaz s fie transmis. Atunci cnd FIN-ul este
confirmat, sensul respectiv de comunicare este efectiv oprit pentru noi date. Cu toate acestea,
informaia poate fi transferat n continuare, pentru un timp nedefinit, n cellalt sens.
Conexiunea este desfiinat atunci cnd ambele direcii au fost oprite. n mod normal, pentru a
elibera o conexiune sunt necesare patru segmente TCP: cte un FIN i un ACK pentru fiecare
sens. Cu toate acestea, este posibil ca primul ACK i cel de-al doilea FIN s fie cuprinse n
acelai segment reducnd astfel numrul total la trei.
47

La fel ca n conversaiile telefonice, n care ambele persoane pot spune la revedere i pot
nchide telefonul simultan, ambele capete ale unei conexiuni TCP pot expedia segmente FIN n
acelai timp. Acestea sunt confirmate ca de obicei, conexiunea fiind astfel eliberat. Nu exist
de fapt nici o diferen esenial ntre cazurile n care mainile elibereaz conexiunea secvenial
respectiv simultan.
Pentru a evita problema celor dou armate, sunt utilizate cronometre. Dac un rspuns la un
FIN nu este recepionat pe durata a cel mult dou cicluri de maxime de via ale unui pachet,
emitorul FIN-ului elibereaz conexiunea. Cealalt parte va observa n final c nimeni nu mai
pare s asculte la cellalt capt al conexiunii, i va elibera conexiunea n urma expirrii unui
interval de timp. Aceast soluie nu este perfect, dar avnd n vedere faptul c o soluie
perfect este teoretic imposibil, va trebui s ne mulumim cu ce avem. n realitate astfel de
probleme apar foarte rar.
4.7.
Modelarea administrrii conexiunii TCP
Paii necesari stabilirii unei conexiuni pot fi reprezentai printr-un automat cu stri finite, cele 11
stri ale acestuia fiind prezentate n Figura 10-27. n fiecare stare pot aprea doar anumite
evenimente. Atunci cnd are loc un astfel de eveniment, este ndeplinit o aciune specific.
Atunci cnd se produce un eveniment a crui apariie nu este legal n starea curent, este
semnalat o eroare.
Stare
CLOSED (NCHIS)
LISTEN (ASCULTARE)
SYN RCVD (Recepie SYN)
SYN SENT (Transmisie SYN)
ESTABLISHED (STABILIT)
FIN WAIT 1 (Ateptare FIN 1)
FIN WAIT 2 (Ateptare FIN 2)
TIMED WAIT (Ateptare Temporizat)
CLOSING (n curs de INCHIDERE)
CLOSE WAIT (NCHIDE i ATEAPT)
LAST ACK (CONFIRMARE FINAL)
Descriere
Nici o conexiune nu este activ sau n ateptare
Serverul ateapt recepionarea unui apel
S-a recepionat o cerere de conexiune; atept ACK
Aplicaia a nceput deschiderea unei conexiuni
Starea normal de transfer a datelor
Aplicaia a anunat c termin
Partenerul este de acord cu eliberarea conexiunii
Se ateapt moartea tuturor pachetelor
Ambele pri ncearc simultan nchiderea
Partenerul a iniiat eliberarea conexiunii
Se ateapt moartea tuturor pachetelor
Figura 10-27 Strile utilizate n automatul cu stri finite pentru controlul conexiunii TCP
Fiecare conexiune ncepe n starea NCHIS. Aceast stare este prsit dac urmeaz s se
stabileasc o conexiune pasiv (LISTEN) sau activ (CONNECT). Dac partenerul stabilete o
conexiune de tipul opus, starea devine STABILIT. Desfiinarea conexiunii poate fi iniiat de
oricare din parteneri, o dat cu eliberarea conexiunii revenindu-se n starea NCHIS. Automatul
cu stri finite este reprezentat n Figura 10-28. Cazul cel mai comun, al unui client conectndu48

se activ la un server pasiv, este reprezentat prin linii groase - continue pentru client i ntrerupte
pentru server. Liniile subiri reprezint secvene de evenimente mai puin obinuite, dar posibile.
Fiecare linie din Figura 10-28 este etichetat cu o pereche eveniment/aciune. Evenimentul
poate fi unul iniiat de ctre utilizator printr-un apel sistem (CONNECT, LISTEN, SEND sau
CLOSE), recepionarea unui segment (SYN, FIN, ACK sau RST) sau, ntr-un singur caz,
expirarea unui interval de timp egal cu dublul ciclului de via a unui pachet. Aciunea const n
expedierea unui segment de control (SYN, FIN sau RST) sau nici o aciune, lucru reprezentat
prin . Comentariile sunt incluse ntre paranteze.
Figura 10-28 Automatul cu stri finite pentru controlul conexiunii TCP. Linia groas continu
este calea normal pentru client. Linia groas ntrerupt este calea normal pentru server.
Liniile subiri sunt evenimente neuzuale. Fiecare tranziie este etichetat de evenimentul care a
creat-o i aciunea care rezult din el, separate de slash.
Diagrama poate fi neleas cel mai bine urmrind de la bun nceput calea urmat de un client
(linia groas continu) i apoi calea urmat de un server (linia groas ntrerupt). Atunci cnd
49

un program aplicaie de pe maina client genereaz o cerere CONNECT, entitatea TCP local
creeaz o nregistrare de conexiune, o marcheaz ca fiind n starea SYN SENT i trimite un
segment SYN. De observat c mai multe conexiuni pot fi deschise (sau n curs de a fi deschise)
n acelai timp spre folosul mai multor aplicaii, astfel nct o stare este asociat unei conexiuni
i este nregistrat n nregistrarea asociat acesteia. La recepia unui SYN + ACK, TCP
expediaz ultima confirmare (ACK) din nelegerea n trei pai i comut n starea STABILIT.
Din acest moment, informaia poate fi att expediat ct i recepionat.
Atunci cnd se termin o aplicaie, se apeleaz primitiva CLOSE care impune entitii TCP
locale expedierea unui segment FIN i ateptarea ACK-ului corespunztor (dreptunghiul figurat
cu linie ntrerupt i etichetat nchidere activ). Atunci cnd ACK-ul este recepionat, se trece
n starea ATEPTARE FIN 2, unul din sensuri fiind n acest moment nchis. Atunci cnd cellalt
sens este la rndul su nchis de partenerul de conexiune, se recepioneaz un FIN care este
totodat i confirmat. n acest moment, ambele sensuri sunt nchise, dar TCP-ul ateapt un
interval de timp egal cu dublul duratei de via a unui pachet, garantnd astfel c toate
pachetele acestei conexiuni au murit i c nici o confirmare nu a fost pierdut. Odat ce acest
interval de timp expir, TCP-ul terge nregistrarea asociat conexiunii.
Se examineaz acum gestiunea conexiunii din punctul de vedere al server-ului. Acesta execut
LISTEN i se aeaz fiind totodat atent pentru a vedea cine se ridic n picioare. La
recepionarea unui SYN, acesta este confirmat i serverul comut n starea SYN RCVD. Atunci
cnd SYN-ul server-ului este la rndul su confirmat, nelegerea n trei pai este complet,
serverul comutnd n starea STABILIT. De acum, transferul informaiei poate ncepe.
Atunci cnd clientul a terminat, execut CLOSE, ceea ce conduce la atenionarea server-ului
prin recepionarea unui FIN (dreptunghiul figurat cu linie ntrerupt i etichetat nchidere
pasiv). Atunci cnd i acesta execut un CLOSE, se trimite un FIN ctre client. O dat cu
primirea confirmrii clientului, serverul desfiineaz conexiunea i terge nregistrarea asociat.
4.8.
Politica TCP de transmisie a datelor
Cum s-a menionat anterior, administrarea ferestrei n TCP nu este direct legat de confirmri,
aa cum se ntmpl la cele mai multe protocoale de nivel legtur de date. De exemplu, se
presupune c receptorul are un tampon de 4096 octei, aa cum se vede n Figura 10-29. Dac
emitorul transmite un segment de 2048 de octei care este recepionat corect, receptorul va
confirma segmentul. Deoarece acum tamponul acestuia din urm mai are liberi doar 2048 octei
(pn cnd aplicaia terge nite date din acest tampon), receptorul va anuna o fereastr de
2048 octei ncepnd de la urmtorul octet ateptat.
Acum, emitorul transmite ali 2048 octei, care sunt confirmai, dar fereastra oferit este 0.
50

Emitorul trebuie s se opreasc pn cnd procesul aplicaie de pe maina receptoare a ters
nite date din tampon, moment n care TCP poate oferi o fereastr mai mare.
Figura 10-29 Controlul ferestrei n TCP.
Atunci cnd fereastra este 0, n mod normal emitorul nu poate s transmit segmente, cu
dou excepii. n primul rnd, informaia urgent poate fi trimis, de exemplu pentru a permite
utilizatorului s opreasc procesele rulnd pe maina de la distan. n al doilea rnd, emitorul
poate trimite un segment de un octet pentru a determina receptorul s renune urmtorul octet
ateptat i dimensiunea ferestrei. Standardul TCP prevede n mod explicit aceast opiune
pentru a preveni interblocarea n cazul n care se ntmpl ca anunarea unei ferestre s fie
vreodat pierdut.
Emitorii nu transmit n mod obligatoriu date de ndat ce acest lucru este cerut de ctre
aplicaie. Nici receptorii nu trimit n mod obligatoriu confirmrile de ndat ce acest lucru este
posibil. De exemplu, n Figura 10-29, atunci cnd sunt disponibili primii 2K octei, TCP, tiind c
dispune de o fereastr de 4K octei, va memora informaia n tampon pn cnd ali 2K octei
devin disponibili i astfel se va putea transmite un segment cu o ncrcare util de 4K octei.
Aceast facilitate poate fi folosit pentru mbuntirea performanelor. Se consider o
51

conexiune TELNET cu un editor interactiv care reacioneaz la fiecare apsare a tastelor. n cel
mai ru caz, atunci cnd un caracter sosete la entitatea TCP emitoare, TCP creeaz un
segment TCP de 21 octei, pe care l furnizeaz IP-ului pentru a fi transmis ca o datagram IP
de 41 octei. De partea receptorului, TCP transmite imediat o confirmare de 40 octei (20 octei
antet TCP i 20 octei antet IP). Mai trziu, cnd editorul a citit caracterul, TCP transmite o
actualizare a ferestrei, deplasnd fereastra cu un octet la dreapta. Acest pachet este de
asemenea de 40 octei. n final, cnd editorul a prelucrat caracterul, transmite ecoul sub forma
unui pachet de 41 octei. Cu totul, sunt folosii 162 octei din lrgimea de band i sunt trimise
patru segmente pentru orice caracter tiprit. Atunci cnd lrgimea de band este redus,
aceast metod de lucru nu este recomandat.
O abordare folosit de multe implementri TCP pentru optimizarea acestei situaii const n ntrzierea confirmrilor i actualizrilor de fereastr timp de 500 ms, n sperana apariiei unor
informaii la care s se ataeze pentru o cltorie pe gratis. Presupunnd c editorul are un
ecou de 50 ms, este necesar acum un singur pachet de 41 octei pentru a fi trimis utilizatorului
de la distan, reducnd numrul pachetelor i utilizarea lrgimii de band la jumtate.
Dei aceast regul reduce ncrcarea reelei de ctre receptor, emitorul opereaz nc
ineficient trimind pachete de 41 octei care conin un singur octet de date. O modalitate de a
reduce aceast deficien este cunoscut ca algoritmul lui Nagle (Nagle, 1984). Sugestia lui
Nagle este simpl: atunci cnd emitorul dispune de date, n secven, de cte un octet, el va
trimite doar primul octet, restul octeilor fiind memorai pn la confirmarea primului octet. Apoi
vor fi trimise toate caracterele memorate ntr-un segment TCP i va continua memorarea pn
la confirmarea tuturor octeilor. Dac utilizatorul tasteaz repede i reeaua este lent, un numr
substanial de caractere poate fi plasat n fiecare segment, reducnd cu mult lrgimea de band
folosit. n plus, algoritmul permite transmisia unui nou pachet, dac s-a dispus de suficient
informaie pentru a umple jumtate dintr-o fereastr sau pentru a completa un segment.
Implementrile TCP folosesc pe scar larg algoritmul lui Nagle, dar exist situaii cnd este
mai bine ca el s fie dezactivat. n particular, cnd o aplicaie X-Windows ruleaz prin Internet,
deplasrile mausului trebuie transmise mainii de la distan. (Sistemul X Window este sistemul
de ferestre utilizat pe majoritatea sistemelor UNIX.) Gruparea lor pentru a fi transmise n rafal
provoac o micare imprevizibil a cursorului, lucru care nemulumete profund utilizatorii.
O alt problem care poate degrada performana TCP este sindromul ferestrei stupide
(Clark, 1982). Aceast problem apare atunci cnd informaia este furnizat entitii TCP
emitoare n blocuri mari, dar la partea receptoare o aplicaie interactiv citete datele octet cu
octet. Pentru a nelege problema, se analizeaz Figura 10-30. Iniial, tamponul TCP al
receptorului este plin i emitorul tie acest fapt (adic are o fereastr de dimensiune 0). Apoi,
aplicaia interactiv citete un caracter de pe canalul TCP. Aceast aciune face fericit
52

entitatea TCP receptoare, deci ea va trimite o actualizare de fereastr ctre emitor dndu-i
astfel dreptul de a mai trimite un octet. ndatorat, emitorul trimite un octet. Cu acesta,
tamponul este plin i receptorul confirm segmentul de 1 octet, dar repoziioneaz dimensiunea
ferestrei la 0. Acest comportament poate continua la nesfrit.
Soluia lui Clark este de a nu permite receptorului s trimit o actualizare de fereastr la fiecare
octet. n schimb, el este forat s atepte pn cnd spaiul disponibil are o dimensiune
decent, urmnd s-l ofere pe acesta din urm. Mai precis, receptorul nu ar trebui s trimit o
actualizare de fereastr pn cnd nu va putea gestiona minimul dintre dimensiunea maxim
oferit atunci cnd conexiunea a fost stabilit i jumtate din dimensiunea tamponului su, dac
este liber.
Mai mult dect att, emitorul poate mbunti situaia netrimind segmente de dimensiune
mic. n schimb, el ar trebui s ncerce s atepte pn cnd acumuleaz suficient spaiu n
fereastr pentru a trimite un segment ntreg sau mcar unul coninnd cel puin jumtate din
dimensiunea tamponului receptorului (pe care trebuie s o estimeze din secvena actualizrilor
de fereastr recepionate pn acum).
Figura 10-30 Sindromul ferestrei stupide.
Algoritmul lui Nagle i soluia lui Clark pentru sindromul ferestrei stupide sunt complementare.
Nagle a ncercat s rezolve problema furnizrii datelor ctre TCP octet cu octet, cauzat de
aplicaia emitoare. Clark a ncercat s rezolve problema extragerii datelor de la TCP octet cu
octet, cauzat de ctre aplicaia receptoare. Ambele soluii sunt valide i pot funciona
mpreun. Scopul este ca emitorul s nu trimit segmente mici, iar receptorul s nu cear
53

astfel de segmente.
Receptorul TCP poate face, pentru mbuntirea performanelor, mai mult dect simpla actualizare a ferestrei n uniti mari. Ca i emitorul TCP, el are posibilitatea s memoreze date,
astfel nct s poat bloca o cerere de READ a aplicaiei pn cnd i poate furniza o cantitate
semnificativ de informaie. Astfel se reduce numrul de apeluri TCP, deci i suprancrcarea.
Bineneles, n acest mod va crete i timpul de rspuns, dar pentru aplicaii care nu sunt
interactive, aa cum este transferul de fiiere, eficiena poate fi mai important dect timpul de
rspuns la cereri individuale.
O alt problem de discutat despre receptor se refer la ce trebuie s fac acesta cu
segmentele care nu sosesc n ordine. Ele pot fi reinute sau eliminate, dup cum dorete
receptorul. Bineneles, confirmrile pot fi trimise numai atunci cnd toat informaia pn la
octetul confirmat a fost recepionat. Dac receptorul primete segmentele 0, 1, 2, 4, 5, 6 i 7,
el poate confirma totul pn la ultimul octet din segmentul 2 inclusiv. Atunci cnd emitorul
constat o depire de timp, el va retransmite segmentul 3. Dac receptorul a memorat n
tampon segmentele 4 pn la 7, odat cu recepia segmentului 3 el poate confirma toi octeii
pn la sfritul segmentului 7.
4.9.
Controlul congestiei n TCP
Atunci cnd ncrcarea la care este supus o reea este mai mare dect poate aceasta s
suporte, apare congestia. Internet-ul nu face excepie. Dei nivelul reea ncearc de asemenea
s controleze congestia, cea mai mare parte a muncii este fcut de TCP, i aceasta deoarece
adevrata soluie a congestiei const n micorarea ratei de transfer a informaiei.
Teoretic, congestia poate fi controlat pe baza unui principiu mprumutat din fizic: legea conservrii pachetelor. Ideea de baz este de a nu injecta un nou pachet n reea pn cnd un
pachet mai vechi nu o prsete (de exemplu este furnizat receptorului). TCP ncearc s
ating acest scop prin manipularea dinamic a dimensiunii ferestrei.
Primul pas n controlul congestiei este detecia ei. Mai demult, detecia congestiei era dificil. O
depire de timp datorat pierderii unui pachet putea fi cauzat fie de (1) zgomotul de pe linia
de transmisie, fie de (2) eliminarea pachetului de ctre un ruter congestionat. Diferenierea celor
dou cazuri era dificil.
n ziua de azi, pierderea pachetului din pricina erorilor de transmisie este destul de rar, deoarece cele mai multe din trunchiurile principale de comunicaie sunt din fibr (dei reelele fr fir
sunt un subiect separat). n consecin, cele mai multe depiri ale timpilor de transmisie pe
Internet se datoreaz congestiilor. Toi algoritmii TCP din Internet presupun c depirile de
timp sunt cauzate de congestii i monitorizeaz aceste depiri pentru a detecta problemele.
54

Atunci cnd se stabilete o conexiune, trebuie s se aleag o fereastr de o dimensiune
potrivit. Receptorul poate specifica o fereastr bazndu-se pe dimensiunea tamponului
propriu. Dac emitorul accept aceast dimensiune a ferestrei, nu mai pot aprea probleme
datorit depirii tamponului la recepie, dar pot aprea n schimb datorit congestiei interne n
reea.
Figura 10-31 (a) O reea rapid alimentnd un rezervor de capacitate mic. (b) O reea lent
alimentnd un receptor de mare capacitate.
n Figura 10-31, se poate vedea interpretarea hidraulic a acestei probleme. n Figura 10-31(a),
se observ o conduct groas care duce la un receptor de dimensiune mic. Atta timp ct
emitorul nu trimite mai mult ap dect poate conine gleata, apa nu se va pierde. n Figura
10-31(b), factorul de limitare nu mai este capacitatea gleii, ci capacitatea de transport a
reelei. Dac vine prea repede prea mult ap, ea se va revrsa i o anumit cantitate se va
pierde (n acest caz prin umplerea plniei).
Soluia din Internet este de a realiza posibilitatea existenei a dou probleme - capacitatea
reelei i capacitatea receptorului - i de a le trata pe fiecare separat. Pentru a face acest lucru,
fiecare emitor menine dou ferestre: fereastra acceptat de ctre receptor i o a doua
fereastr, fereastra de congestie. Fiecare reflect numrul de octei care pot fi trimii de ctre
emitor. Numrul octeilor care pot fi trimii este dat de minimul dintre cele dou ferestre.
Astfel, fereastra efectiv este minimul dintre ceea ce emitorul crede c este n regul i ceea
55

ce receptorul crede c este n regul. Dac receptorul spune: Trimite 8K octei, dar
emitorul tie c o rafal de mai mult de 4K octei poate aglomera excesiv reeaua, el va trimite
4K octei. Din alt punct de vedere, dac receptorul spune: Trimite 8K octei i emitorul tie c
o rafal de 32K octei poate strbate fr efort reeaua, el va trimite toi cei 8K octei cerui.
La stabilirea conexiunii, emitorul iniializeaz fereastra de congestie la dimensiunea celui mai
mare segment utilizat de acea conexiune. El trimite apoi un segment de dimensiune maxim.
Dac acest segment este confirmat naintea expirrii timpului, mai adaug un segment la
fereastra de congestie, fcnd-o astfel de dimensiunea a dou segmente de dimensiune
maxim, i trimite dou segmente. O dat cu confirmarea fiecruia din aceste segmente,
fereastra de congestie este redimensionat cu nc un segment de dimensiune maxim. Atunci
cnd fereastra de congestie este de n segmente, dac toate cele n segmente sunt confirmate n
timp util, ea este crescut cu numrul de octei corespunztor celor n segmente. De fapt, fiecare
rafal confirmat cu succes dubleaz fereastra de congestie.
Fereastra de congestie crete n continuare exponenial pn cnd sau se produce o depire
de timp, sau se atinge dimensiunea ferestrei receptorului. Ideea este ca dac rafale de
dimensiune, s spunem, 1024, 2048 i 4096 de octei funcioneaz fr probleme, dar o rafal
de 8192 octei duce la
o depire de timp, fereastra de congestie va fi stabilit la 4096 de octei pentru a evita
congestia. Atta timp ct fereastra de congestie rmne la 4096, nu va fi transmis nici o rafal
mai mare de aceast valoare, indiferent ct de mult spaiu de fereastr este oferit de ctre
receptor. Acest algoritm este numit algoritmul startului lent, fr a fi ns ctui de puin lent
(Jacobson, 1988). Este exponenial. Toate implementrile TCP trebuie s l suporte.
n cazul Internetului, controlul congestiei utilizeaz n plus fa de ferestrele de recepie i de
congestie un al treilea parametru, numit prag, iniial de 64K. Atunci cnd apare o depire de
timp, pragul este poziionat la jumtate din fereastra curent de congestie i fereastra de
congestie este repoziionat la dimensiunea unui segment maxim. Startul lent este utilizat apoi
pentru a determina ct poate reeaua s duc, atta doar c acea cretere exponenial se
oprete odat cu atingerea pragului. De aici nainte transmisiile reuite mresc n mod liniar dimensiunea ferestrei de congestie (cu cte un segment maxim pentru fiecare rafal), n locul
unei creteri pentru fiecare segment. De fapt, algoritmul presupune c este acceptabil
njumtirea ferestrei de congestie, din acel punct continundu-i gradual calea spre
dimensiuni mai mari.
Funcionarea algoritmului de congestie se poate vedea n Figura 10-32. Dimensiunea unui
segment maxim este, n acest caz, de 1024 de octei. Iniial fereastra de congestie are 64K
octei, dar apare o depire de timp i deci pragul este stabilit la 32K octei iar fereastra de
congestie la 1K octei acesta fiind punctul 0 al transmisiei din figur. Fereastra de congestie
56

crete apoi exponenial pn atinge pragul (32K octei). ncepnd de aici, creterea este liniar.
Figura 10-32 Un exemplu al algoritmului de congestie din Internet.
Transmisia 13 nu are noroc (este de la sine neles) i apare o depire de timp. Pragul este
stabilit la jumtate din fereastra curent (acum 40K octei, deci jumtate este 20K octei) i
startul lent este iniiat din nou. Atunci cnd confirmrile pentru transmisia 14 ncep s soseasc,
primele patru dubleaz fiecare fereastra de congestie, dar dup aceea creterea redevine
liniar.
Dac nu mai apar depiri de timp, fereastra de congestie va continua s creasc pn la
dimensiunea ferestrei receptorului. n acest punct, creterea ei va fi oprit i va rmne
constant atta timp ct nu mai apar depiri i fereastra receptorului nu i modific
dimensiunea. Ca un alt aspect, dac un pachet ICMP SOURCE QUENCH sosete i este
furnizat TCP-ului, acest eveniment este tratat la fel ca o depire de timp. O alternativ (i o
abordare mai recent) este descris n RFC 3168.
4.10.
Administrarea contorului de timp n TCP
TCP utilizeaz (cel puin conceptual) mai multe contoare pentru a face ceea ce are de fcut. Cel
mai important dintre acestea este contorul de retransmisie. Atunci cnd este trimis un
segment, se pornete un contor de retransmisie. Dac segmentul este confirmat nainte de
57

expirarea timpului, contorul este oprit. Pe de alt parte, dac timpul expir naintea primirii
confirmrii, segmentul este retransmis (i contorul este pornit din nou). ntrebarea care se pune
este urmtoarea: Ct de mare trebuie s fie intervalul de timp pn la expirare?
Aceast problem este mult mai dificil la nivelul transport din Internet dect la nivelul
protocoalelor generice de legtur de date. n cazul din urm, ntrzierea ateptat este uor
predictibil (de exemplu, are o varian sczut), deci contorul poate fi setat s expire chiar
imediat dup ce era ateptat confirmarea, aa cum se arat n Figura 10-33(a). Cum
confirmrile sunt rareori ntrziate n nivelul legtur de date, absena unei confirmri n
momentul n care aceasta era ateptat nseamn de obicei c s-a pierdut fie cadrul, fie
confirmarea.
Figura 10-33 (a) Densitatea de probabilitate a sosirilor n timp a confirmrilor n nivelul

legtur de date. (b) Densitatea de probabilitate a sosiri confirmrilor pentru TCP.
TCP trebuie s fac fa unui mediu radical diferit. Funcia de densitate a probabilitii pentru
timpul necesar ntoarcerii unei confirmri TCP arat mai degrab ca n Figura 10-33(b) dect ca
n Figura 10-33(a). Este dificil determinarea timpului n care se realizeaz circuitul dus-ntors
pn la destinaie. Chiar i cnd acesta este cunoscut, stabilirea intervalului de depire este
de asemenea dificil. Dac intervalul este prea scurt, s spunem T1 n Figura 10-33(b), vor
aprea retransmisii inutile, aglomernd Internet-ul cu pachete fr rost. Dac este prea lung,
(T2), performanele vor avea de suferit datorit ntrzierii retransmisiei de fiecare dat cnd se
pierde un pachet. Mai mult dect att, media i variana distribuiei sosirii confirmrilor se pot
schimba cu rapiditate pe parcursul a ctorva secunde atunci cnd apare sau se rezolv o
congestie.
Soluia este s se utilizeze un algoritm profund dinamic, care ajusteaz n mod constant
58

intervalul de depire bazndu-se pe msurtori continue ale performanei reelei. Algoritmul
utilizat n general de ctre TCP este datorat lui Jacobson (1988). Pentru fiecare conexiune, TCP
pstreaz o variabil, RTT, care este cea mai bun estimare a timpului n care se parcurge circuitul dus-ntors ctre destinaia n discuie. Atunci cnd este trimis un segment, se pornete un
con-tor de timp, att pentru a vedea ct de mult dureaz pn la primirea confirmrii ct i
pentru a iniia o retransmisie n cazul scurgerii unui interval prea lung. Dac se primete
confirmarea naintea expirrii contorului, TCP msoar ct de mult i-a trebuit confirmrii s
soseasc, fie acest timp M. n continuare el actualizeaz RTT, dup formula:
RTT =RTT + (1)M
unde este un factor de netezire care determin ponderea dat vechii valori. Uzual, =7/8.
Chiar presupunnd o valoare bun a lui RTT, alegerea unui interval potrivit de retransmisie nu
este o sarcin uoar. n mod normal, TCP utilizeaz RTT, dar problema const n alegerea
lui .
n implementrile iniiale, era ntotdeauna 2, dar experiena a artat c o valoare constant
este inflexibil deoarece nu corespunde n cazul creterii varianei.
n 1988, Jacobson a propus ca s fie aproximativ proporional cu deviaia standard a funciei
de densitate a probabilitii timpului de primire a confirmrilor, astfel nct o varian mare
implic un mare i viceversa. n particular, el a sugerat utilizarea deviaiei medii ca o estimare
puin costisitoare a deviaiei standard. Algoritmul su presupune urmrirea unei alte variabile de
netezire, D, deviaia. La fiecare sosire a unei confirmri, este calculat diferena dintre valorile
ateptate i observate |RTT M|. O valoare netezit a acesteia este pstrat n D, prin formula
D =D + (1) |RTT M|
unde poate sau nu s aib aceeai valoare ca cea utilizat pentru netezirea lui RTT. Dei D
nu este chiar deviaia standard, ea este suficient de bun i Jacobson a artat cum poate fi
calculat utiliznd doar adunri de ntregi, scderi i deplasri, ceea ce este un mare punct
ctigat. Cele mai multe implementri TCP utilizeaz acum acest algoritm i stabilesc valoarea
intervalului de depire la:
Depire = RTT + 4 D
Alegerea factorului 4 este ntr-un fel arbitrar, dar are dou avantaje. n primul rnd,
multiplicarea prin 4 poate fi fcut printr-o singur deplasare. n al doilea rnd, minimizeaz
depirile de timp i retransmisiile inutile, datorit faptului c mai puin de un procent din totalul
pachetelor sosesc cu ntrzieri mai mari de patru ori deviaia standard. (De fapt, Jacobson a
propus iniial s se foloseasc 2, dar experiena ulterioar a demonstrat c 4 conduce la
performane mai bune).
59

O problem legat de estimarea dinamic a RTT se refer la ce trebuie fcut n situaia n care
un segment cauzeaz o depire i trebuie retransmis. Atunci cnd confirmarea este primit, nu
este clar dac aceasta se refer la prima transmisie sau la o transmisie urmtoare. O decizie
eronat poate contamina serios estimarea lui RTT. Phil Karn a descoperit aceast problem cu
mult greutate. El este un radio amator entuziast, interesat n transmiterea pachetelor TCP/IP
prin operare radio, un mediu recunoscut pentru lipsa de fiabilitate (pe o zi senin, la destinaie
ajung jumtate din pachete). El a fcut o propunere simpl: s nu se actualizeze RTT pentru
nici un segment care a fost retransmis. n loc de aceasta, timpul de expirare este dublat la
fiecare eec, pn cnd segmentele ajung prima oar la destinaie. Aceast corecie este
numit algoritmul lui Karn. Cele mai multe din implementrile TCP utilizeaz acest algoritm.
Contorul de retransmisie nu este singurul utilizat de ctre TCP. Un al doilea contor este
contorul de persisten. El este proiectat s previn urmtoarea situaie de interblocare.
Receptorul trimite o confirmare cu o dimensiune a ferestrei 0, spunndu-i emitorului s
atepte. Mai trziu, receptorul actualizeaz fereastra, dar pachetul cu aceast actualizare este
pierdut. Acum, att emitorul ct i receptorul ateapt o reacie din partea celuilalt. Atunci
cnd contorul de persisten expir, emitorul transmite o sond ctre receptor. Rspunsul la
aceast investigare furnizeaz dimensiunea ferestrei. Dac aceast dimensiune continu s fie
zero, contorul de persisten este repoziionat i ciclul se repet. Dac este nenul, informaia
poate fi acum transmis.
Un al treilea contor utilizat de unele implementri este contorul de meninere n via. Cnd o
conexiune a fost inactiv o lung perioad de timp, contorul de meninere n via poate expira
pentru a fora una din pri s verifice dac cealalt parte exist nc. Dac aceasta nu
rspunde, conexiunea este nchis. Aceast facilitate este
controversat, deoarece
suprancarc reeaua i poate termina o conexiune altfel sntoas datorit unei partiionri
tranzitorii a reelei.
Ultimul contor folosit la fiecare conexiune TCP este acela utilizat n strile de ATEPTARE
CONTORIZAT pe parcursul nchiderii conexiunilor. El funcioneaz pe durata a dou viei
maxime ale unui pachet, pentru a se asigura c, atunci cnd o conexiune este nchis, toate
pachetele create de aceasta au murit.
4.11.
TCP i UDP n conexiune fr fir
Teoretic, protocoalele de transport ar trebui s fie independente de tehnologia nivelului reea. n

particular, TCP-ului ar trebui s nu-i pese dac IP ruleaz peste o reea cablu sau radio. n
practic, acest lucru conteaz, deoarece cele mai multe implementri TCP au fost atent
optimizate pe baza unor presupuneri care sunt adevrate pentru reele cu cabluri, dar care nu
60

mai sunt valabile n cazul reelelor fr fir. Ignorarea proprietilor de transmisie fr fir poate
conduce la o implementare TCP corect din punct de vedere logic, dar cu performane incredibil
de proaste.
Principala problem este algoritmul de control al congestiei. Aproape toate implementrile TCP
din zilele noastre pleac de la premisa c depirile de timp sunt cauzate de congestie i nu de
pierderea pachetelor. n consecin, atunci cnd expir un contor, TCP ncetinete ritmul i
trimite pachete cu mai puin vigoare (ex. algoritmul startului lent al lui Jacobson). Ideea din
spatele acestei abordri const n reducerea ncrcrii reelei, astfel eliminndu-se neplcerile
cauzate de congestie.
Din nefericire, legturile bazate pe transmisia fr fir nu sunt deloc fiabile. Ele pierd tot timpul
pachete. Pentru a controla aceast pierdere a pachetelor, abordarea corect este s se
retrimit ct mai repede posibil. ncetinirea ritmului nu face dect s nruteasc lucrurile.
Dac se presupune c, atunci cnd emitorul transmite 100 de pachete pe secund, 20% din
totalul pachetelor se pier-de, productivitatea este de 80 pachete/sec. Dac emitorul
ncetinete ritmul la 50 pachete/sec, productivitatea scade la 40 pachete/sec.
Atunci cnd se pierde un pachet pe o reea cu cabluri, emitorul ar trebui s ncetineasc
ritmul. Atunci cnd se pierde un pachet pe o reea fr fir, emitorul ar trebui s l mreasc.
Dac emitorul nu tie despre ce tip de reea este vorba, luarea unei decizii este dificil.
n mod frecvent, calea de la emitor la receptor este eterogen. Primii 1000 km pot s fie ntr-o
reea cu cabluri, dar ultimul kilometru poate s fie fr fir. Acum, luarea unei decizii n situaia
unei depiri de timp este i mai dificil, dat fiind c intervine i locul n care apare problema. O
soluie propus de Bakne i Badrinath (1995), TCP indirect, const n spargerea conexiunii
TCP n dou conexiuni separate, ca n Figura 10-34. Prima conexiune pleac de la emitor la
staia de baz. Cea de-a doua leag staia de baz de receptor. Aceast staie de baz nu face
dect s copieze pachetele din cele dou conexiuni n ambele direcii.
Figura 10-34 Spargerea conexiunii TCP n dou conexiuni.
61

Avantajul acestei scheme este acela c ambele conexiuni sunt acum omogene. Depirile de
timp din prima conexiune pot ncetini emitorul, n timp ce depirile de timp din cea de-a doua
l pot accelera. Ali parametri pot fi de asemenea reglai separat n fiecare din cele dou
conexiuni. Dezavantajul este acela c este negat nsi semantica TCP. Atta timp ct fiecare
parte a conexiunii este o conexiune TCP n sine, staia de baz confirm fiecare segment TCP
n mod obinuit. Doar c acum, recepia unei confirmri de ctre emitor nu mai nseamn c
receptorul a primit segmentul, ci doar c el a fost primit de ctre staia de baz.
O soluie diferit, datorat lui Balakrishnan et. al (1995), nu ncalc semantica TCP. Ea se
bazeaz pe mici modificri fcute n codul nivelului reea din staia de baz. Una din modificri
const n adugarea unui agent de supraveghere care observ i intercepteaz pachetele TCP
care pleac spre gazda mobil precum i confirmrile care se ntorc de la acesta. Atunci cnd
observ un segment TCP care pleac spre gazda mobil, dar nu observ confirmarea
recepionrii acestuia ntr-un interval de timp dat (relativ scurt), agentul ascuns pur i simplu
retransmite acel segment, fr a mai spune sursei acest lucru. De asemenea, el retransmite i
atunci cnd observ confirmri duplicate din partea gazdei mobile, lucru care indic invariabil
faptul c aceasta a pierdut ceva. Confirmrile duplicate sunt eliminate pe loc, pentru a evita ca
sursa s le interpreteze ca un semn de congestie.
Cu toate acestea, un dezavantaj al acestei transparene este acela c, dac legtura fr fir
pierde multe pachete, sursa poate depi limita de timp n ateptarea unei confirmri i poate
invoca n consecin algoritmul de control al congestiei. n cazul TCP-ului indirect, algoritmul de
control al congestiei nu va fi niciodat iniiat dac nu apare ntr-adevr o situaie de congestie n
partea cablat a reelei.
Algoritmul Balakrishnan ofer de asemenea o soluie problemei pierderii segmentelor generate
de ctre gazda mobil. Atunci cnd staia de baz constat o pauz n interiorul domeniului
numerelor de secven, aceasta genereaz o cerere pentru o repetare selectiv a octetului
lips, utiliznd o opiune TCP.
Utiliznd aceste corecturi, legtura fr fir devine mai fiabil n ambele direcii fr ca sursa s
tie acest lucru i fr modificarea semanticii TCP.
Dei UDP-ul nu sufer de aceleai probleme ca i TCP-ul, comunicaia fr fir induce i pentru
el anumite dificulti. Principala problem este aceea c programele utilizeaz UDP se ateapt
ca acesta s fie foarte fiabil. Ele tiu c nu este furnizat nici o garanie, dar cu toate acestea se
ateapt ca el s fie aproape perfect. ntr-un mediu fr fir, el va fi ns departe de perfeciune.
Pentru programele care sunt capabile s se refac dup pierderea mesajelor UDP, dar numai
cu un cost considerabil, trecerea brusc de la un mediu n care mesajele puteau fi pierdute mai
mult teoretic dect practic la un mediu n care ele sunt pierdute sistematic poate conduce la un
dezastru n ceea ce privete performanele.
62

Comunicaia fr fir afecteaz i alte domenii dect cel al performanelor. De exemplu, cum
poate o gazd mobil s gseasc o imprimant local la care s se conecteze, n loc s
utilizeze propria imprimant? Oarecum legat de aceasta este i problema obinerii paginii
WWW pentru celula local, chiar dac numele ei nu este cunoscut. De asemenea, proiectanii
paginilor WWW au tendina s presupun disponibil o mare lrgime de band. Punerea unei
embleme mari pe fiecare pagin poate s devin contraproductiv dac transmisia paginii
printr-o legtur fr fir lent va dura 10 secunde, i acest lucru ajunge pn la urm s irite
utilizatorii.
Cum reelele cu comunicaii fr fir devin tot mai comune, problema rulrii TCP-ului pe ele a
devenit tot mai acut.
4.12.
TCP Tranzacional
S-a analizat anterior apelul de proceduri la distan ca modalitate de a implementa sistemele

client-server. Dac att cererea, ct i rspunsul sunt suficient de mici nct s se potriveasc
n pachete simple i operaia este idempotent, UDP-ul poate fi uor utilizat. Totui, dac
aceste condiii nu sunt ndeplinite, utilizarea UDP-ului este mai puin atractiv. De exemplu,
dac rspunsul este unul lung, atunci datagramele trebuie sa fie secveniate i trebuie iniiat un
mecanism pentru a retransmite datagramele pierdute. De fapt, aplicaiei i este cerut s
reinventeze TCP-ul.
n mod cert, acest lucru nu este atractiv, dar nici utilizarea TCP-ului n sine nu este atractiv.
Problema este eficiena. Secvena normal a pachetelor pentru a face un RPC peste TCP este
prezentat n Figura 10-35(a). n cel mai bun caz sunt necesare nou pachete.
Figura 10-35 (a) RPC folosind TCP clasic ; (b) RPC folosind T/TCP
63

Cele nou pachete sunt dup cum urmeaz:
1. Clientul trimite un pachet SYN pentru a stabili o conexiune.
2. Serverul trimite un pachet ACK pentru a recunoate pachetul SYN.
3. Clientul finalizeaz nelegerea n trei pai.
4. Clientul trimite cererea real.
5. Clientul trimite un pachet FIN pentru a indica dac s-a terminat trimiterea.
6. Serverul confirm cererea i FIN-ul.
7. Serverul trimite rspunsul napoi clientului.
8. Serverul trimite un pachet FIN pentru a indica c i acest lucru s-a ncheiat.
9. Clientul confirm FIN-ul server-ului.
A se reine c acesta este cazul ideal. n cazul cel mai ru, cererea clientului i FIN-ul sunt confirmate separat, precum sunt rspunsul server-ului i FIN-ul. ntrebarea care apare imediat este
dac exist vreo posibilitate de a combina eficiena RPC-ului folosind UDP (doar 2 mesaje) cu
fiabilitatea TCP-ului. Rspunsul este: aproape c da. Se poate realiza cu o variant
experimental de TCP numit T/TCP (Transactional TCP, TCP tranzacional), care este
descris n RFC 1379 i 1644.
Ideea principal este aceea de a modifica secvena standard de iniializare a conexiunii astfel
nct s permit, la nivel nalt, transferul de date n timpul iniializrii. Protocolul T/TCP este
prezentat n Figura 10-35(b). Primul pachet al clientului conine bitul SYN, cererea n sine i
FIN-ul. De fapt acesta spune: vreau s stabilesc o conexiune, aici sunt datele i am terminat
Cnd serverul primete cererea, caut sau calculeaz rspunsul i alege modul n care s
rspund. Dac rspunsul ncape ntr-un pachet, d rspunsul din Figura 10-35(b), care spune:
confirm FIN-ul tu, iat rspunsul, iar eu am terminat. Clientul confirm apoi FIN-ul server-ului i
protocolul ia sfrit n (dup) trei mesaje.
n orice caz, dac rezultatul este mai mare de 1 pachet, serverul are de asemenea i opiunea
de a nu seta bitul FIN, caz n care poate trimite pachete multiple nainte de a-i nchide direcia.
Merit probabil menionat faptul c T/TCP nu este singura mbuntire propus pentru TCP. O
alt propunere este SCTP (Stream Control Transmission Protocol, Protocolul de control al
transmisiei fluxului). Caracteristicile sale includ pstrarea legturilor dintre mesaje, modaliti
multiple de livrare.
64
Test autoevaluare
S se sublinieze rspunsurile corecte:

1. Principala diferen dintre servicul transport
i serviciul reea este:
a. codul pentru nivelul reea este executat n
ntregime pe mainile utilizatorilor, dar
nivelul transport este executat n cea mai
mare parte de mediul de transport.
b. utilizatorii pot controla nivelul reea, dar nu
pot control nivelul transport.
c. serviciul reea a fost conceput pentru a
modela serviciile oferite de reelele reale,
n schimb, serviciul transport (orientat pe
conexiune) este sigur.
d. pachetele pierdute sau incorecte pot fi
detectate de nivelul reea, dar nu pot fi
detectate de nivelul transport.
e. serviciul reea a fost conceput pentru a
modela serviciile oferite de nivelele fizic i
legtur de date, iar serviciul transport ia n
considerare detaliile reale de implementare
ale nivelului legtur de date.
2. Primitivele pentru socluri TCP folosite n
sistemul de operare Berkeley-UNIX sunt:
a. Socket, Bind, Listen, Accept, Connect,
Send, Receive, Close.
b. Socket, Bind, Accept, Start, Connect,
Transmit, Receive, Close.
c. Socket, Open, Read, Write, Accept, Sebd,
Receive, Close.
d. Socket, Listen, Request, Listen, Read,
Write, Connect, Stop.
e. Socket, Open, Request, Accept, Connect,
Send, Receive, Stop.
3. Cmpurile antetului UDP sunt:
a. Port surs, Port destinaie, Lungime UDP,
Lungime antet UDP.
b. Port surs, Port destinaie, Lungime UDP,
Sum de control UDP.
c. Port surs, Port destinaie, Deplasament
fragment, Sum de control UDP.
d. Port surs, Port destinaie, Numr
secven, Lungime UDP.
e. Port surs, Port destinaie, Deplasament
fragment, Numr secven.
4. Din punct de vedere al controlul fluxului, la

nivel transport exist asemnri cu
problema controlului fluxului la nivel
legtur de date. Principala asemnare
este:
a. la ambele niveluri este necesar un
mecanism bazat pe utilizarea adreselor
pentru controlul fluxului.
b. la
ambele
niveluri
este
practic
implementarea strategiei de memorare
temporar a mesajelor.
c. la ambele niveluri este necesar un
mecanism pentru a mpiedica un emitor
prea rapid s depeasc capacitatea de
recepie a unui receptor prea lent.
d. la ambele niveluri pe fiecare linie de
comunicaie poate exista o singur
conexiune.
e. la ambele niveluri este necesar cte un
mecanism care s fie interconectat unul cu
cellalt i care s fie capabil s detecteze
i s corecteze erorile aprute pe linia de
comunicaie.
5. n procesul de stabilire a conexiunii,
problema principal const n existena
duplicatelor ntrziate, problemn care
poate fi tratat n mai multe feluri:
a. folosirea de adrese de transport valabile
doar pentru o singur utilizare.
b. atribuirea fiecrei conexiuni a doi
identificatori, unul ales de cel care iniiaz
conexiunea, iar cellalt ales de destinatarul
cererii de conexiune.
c. utilizarea unui mecanism care s elimine
pachetele mbtrnite i care nu permite
pachetelor s triasc la nesfrit n
subreea.
d. folosirea mpreun cu adresele de
transport a adreselor unice de la nivelul
legtur de date.
e. implementarea la nivelul Aplicaie a unui
mecanism software de eliminare a
duplicatelor ntrziate.
Grila de evaluare: 1-c; 2-a; 3-b; 4-c; 5-a,c.
65
Termeni eseniali:
Servicii oferite de nivelul transport servicii furnizate nivelurilor superioare (entitate de

transport), primitivele serviciilor de transport, socluri Berkeley.
Nivelul transport adresarea, stabilirea conexiunii, eliberarea conexiunii, controlul fluxului i

memorarea temporar (buffering), multiplexarea, refacerea dup cdere.
Protocolul UDP (User Datagram Protocol) modelul serviciului TCP, antetul UDP.
Apel de procedur la distan (Remote Procedure Call).
Protocolul TCP (Transport Communication Protocol) modelul serviciului TCP, antetul

TCP, stabilirea conexiunii TCP, eliberarea conexiunii TCP, modelarea administrrii conexiunii
TCP, politica TCP de transmisie a datelor.
Controlul congestiei n TCP fereastra de congestie, algoritmul startului lent.
Administrarea contorului de timp n TCP contorul de retransmisie, algoritmul lui Karn,

contorul de persisten, contorul de meninere n via.
TCP i UDP n conexiune fr fir.
TCP Tranzacional SCTP (Stream Control Transmission Protocol, Protocolul de control al

transmisiei fluxului).
66
Bibliografie
1. Tanenbaum, A. , Wetherall D., Computer Networks (5rd Edition), Prentice Hall Software
Series, 2010.
2. Crainicu B., Reele de calculatoare: pentru uzul studenilor, Universitatea Petru Maior, 2005.
3. Peterson, L, Davie, B., Computer networks: A systems approach, Elsevier Publishing
Company; Morgan Kaufmann Publishers, Inc, 2007.
4. Kurose, J., Ross, K., Computer Networking: A Top-Down Approach (5th Edition), AddisonWesley, 2009
67
Test evaluare
S se sublinieze rspunsurile corecte:

1.
a.
b.
c.
d.
e.
2.
a.
b.
c.
d.
e.
3.
a.
b.
c.
d.
e.
Una din diferenele semnificative dintre

protocoale de nivel legtur de date i cele de
nivel transport este determinat de urmtorul
aspect:
la nivel legtur de date numrul mare de conexiuni
care trebuie s fie gestionate face ca ideea de a
aloca tampoane dedicate s nu fie atractiv, n
schimb, la nivel transport numrul mare de
conexiuni care trebuie s fie gestionate face ca
ideea de a aloca tampoane dedicate s fie extrem
de atractiv i util.
nivelul legtur de date face abstracie de
tehnologia hardware de reea, n schimb, nivelul
transport trebuie s cunoasc detaliile tehnologiei de
reea.
nivelul legtur de date se ocup doar de controlul
erorilor, iar nivelul transport se ocup doar de
controlul fluxului.
n cazul legturii de date, pentru un ruter este
necesar adresarea explicit, n schimb, n cazul
nivelului transport nu trebuie specificat cu care alt
ruter vrea s comunice.
la nivelul legturii de date, dou rutere comunic
direct printr-un canal fizic, n timp ce la nivelul
transport acest canal fizic este nlocuit de ntreaga
subreea.
4.
Secvenele de stabilire a conexiunii pentru un

protocol cu nelegere n trei pai, cazul normal,
sunt:
CR(seq=x), ACK(seq=y, ACK=x), REJECT(ACK=y).
CR(seq=x), ACK(seq=y), ACK(seq=x).
CR(seq=x,
seq=y),
REJECT(ACK=y),
DATA(ACK=y).
CR(seq=x, seq=y), ACK(seq=x), DATA(seq=x,
REJECT=y).
CR(seq=x), ACK(seq=y, ACK=x), DATA(seq=x,
ACK=y).
5.
Despre o conexiune TCP se poate afirma:

este punct-la-multipunct.
este half-duplex
este un flux de octei i nu un flux de mesaje.
dimensiunile mesajelor nu se conserv de la un
capt la cellalt.
suport difuzarea parial sau total.
a.
b.
c.
d.
e.
a.
b.
c.
d.
e.
Paii procesului de eliberare a conexiunii, cazul

normal cu confirmare n trei timpi, sunt:
gazda1(trimitere_DR
+
pornire_ceas),
gazda2(trimitere_DR
+
pornire_ceas),
gazda1(eliberare_conexiune
+
trimitere_ACK),
gazda2(eliberare_conexiune).
gazda1(trimitere_DR
+
pornire_ceas),
gazda2(trimitere_DR
+
pornire_ceas),
gazda1(eliberare_conexiune
+
trimitere_ACK),
gazda2(expirare_timp_elberare_conexiune
+
eliberare_conexiune).
gazda1(trimitere_DR),
gazda2(trimitere_DR
+
pornire_ceas),
gazda1(eliberare_conexiune),
gazda2(eliberare_conexiune + trimitere_ACK).
gazda1(pornire_ceas),
gazda2(trimitere_DR
+
pornire_ceas), gazda1(trimitere_DR + trimitere_ACK
+ eliberare_conexiune), gazda2(trimitere_ACK +
eliberare_conexiune).
gazda1(trimitere_DR
+
trimitere_ACK),
gazda2(trimitere_DR
+
pornire_ceas),
gazda1(pornire_ceas
+
eliberare_conexiune),
gazda2(eliberare_conexiune).
Protocolul de conectare iniial funioneaz n
felul urmtor:
fiecare server ascult la mai multe TSAP-uri fixate,
furnizndu-se astfel un grad ridicat de redundan a
serviciilor oferite prin intermediul TSAP-urilor.
n loc ca orice server s asculte la un TSAP fixat,
fiecare main care dorete s ofere servicii
utilizatorilor aflai la distan are un server de
procese special care acioneaz ca un intermediar
pentru toate serverele mai puin utilizate.
utilizatorii poteniali ai serviciului ncep prin a face o
cerere de conexiune, nefiind necesar specificarea
adresei TSAP a serviciului pe care l doresc (acesta
este implicit).
n loc ca orice server s asculte la un TSAP fixat,
utilizatorilor aflai la distan redirecteaz cererile de
conexiune ctre o main din reea responsabil cu
rezolvarea acestor cereri.
utilizatorilor aflai la distan are un server de
procese special care interogheaz n mod secvenial
utilizatorii pentru a afla dac acetia au nevoie de
vreun serviciu.
Grila de evaluare: 1-e; 2-e; 3-c,d; 4-a; 5-b.
68

Retele Calculatoare-Curs 10 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Retele Calculatoare-Curs 10 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Reele de Calculatoare - Curs 10

1. Servicii oferite de nivelul transport nivelurilor superioare.

Reele de Calculatoare - Curs 10

1.1 Servicii oferite de nivelul transport

Servicii furnizate nivelurilor superioare

Figura 10-1 Nivelurile reea, transport i aplicaie.

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

1.1.2 Primitivele serviciilor de transport

Reele de Calculatoare - Curs 10

Unitatea de date trimis

Figura 10-2 Primitivele unui serviciu de transport simplu

Reele de Calculatoare - Curs 10

Figura 10-3. Ierarhia de cadre, pachete i TPDU-uri.

Reele de Calculatoare - Curs 10

Figura 10-4 Diagrama de stri pentru o schem simpl de control al conexiunii.

Reele de Calculatoare - Curs 10

Figura 10-5 Primitivele pentru socluri TCP

Reele de Calculatoare - Curs 10

2. Noiuni de baz despre protocoalele de transport

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Figura 10-7 TSAP, NSAP i conexiunile la nivel transport.

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

2.2 Stabilirea conexiunii

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

2.3 Eliberarea conexiunii

Reele de Calculatoare - Curs 10

Figura 10-11 Deconectare brusc cu pierdere de date. CR= CONNECTION REQUEST,

Figura 10-12 Problema celor dou armate.

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

2.3 Controlul fluxului i memorarea temporar (buffering)

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Figura 10-16 (a) Multiplexare n sus. (b) Multiplexare n jos.

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Figura 10-17 Combinaiile diferitelor strategii posibile pentru server i client.

Reele de Calculatoare - Curs 10

3. Protocoale de transport prin Internet: UDP

Setul de protocoale Internet suport un protocol de transport fr conexiune, UDP (User

Figura 10-18 Antetul UDP.

Reele de Calculatoare - Curs 10

Apel de procedur la distan (Remote Procedure Call)

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Reele de Calculatoare - Curs 10

Protocolul de transport n timp real Real-Time Transport Protocol

Reele de Calculatoare - Curs 10

Figura 10-20 (a)Poziionarea Protocolului RTP n stiva de protocoale. (b) ncapsularea

Reele de Calculatoare - Curs 10

Figura 10-21 Antetul RTP-ului.

Reele de Calculatoare - Curs 10