PROTOCOALE DE TRANSPORT PRIN INTERNET:

UDP si TCP
Internet-ul are dou protocoale principale n nivelul de transport: unul
neorientat pe conexiune i unul orientat pe conexiune. n urmtoarele seciuni o
s le studiem pe ambele. Protocolul neorientat pe conexiune se numete UDP.
Protocolul orientat pe conexiune se numete TCP. O s ncepem cu UDP-ul
deoarece n esen este la fel ca IP-ul cu un mic antet adugat. De asemeni, o s
studiem i dou aplicaii ale UDP-ului.
1. UDP Introducere n UDP
Setul de protocoale Internet suport un protocol de transport fr conexiune,
UDP (User 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. UDP transmite segmente constnd ntr-un antet de 8 octei urmat de
informaia util . Antetul este prezentat n figura de mai jos. 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 pentru TCP (procesul de legtur este
acelai pentru UDP). De fapt, valoarea cea mai important dat de existena
UDP-ului fa de folosirea doar a IP-ului 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.

Antetul UDP

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. Pentru aplicaiile care trebuie s aib un control precis
asupra fluxului de pachete, controlului erorii sau cronometrarea, UDP-ul
furnizeaz doar ceea ce a ordonat doctorul. 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.
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 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 , rom: 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 vom 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 (rom: 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
urmatoarea figura. 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 ntrun mesaj i realizarea unui apel de sistem pentru a trimite mesajul.
mpachetarea parametrilor este denumit marshaling (rom: 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.

Paii pentru a crea un apel de procedur la distan.

Stub-urile sunt haurate.
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 stubul client se gsesc n acelai spaiu de adres, 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. n ciuda eleganei conceptului de RPC, sunt
cteva neajunsuri. 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. S presupunem 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 cazul 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 printro valoare special cunoscut doar de ctre procedura apelat i de cea apelant.
n aceste condiii, n mod cert este 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.
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, rom:
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 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 fig. 6-25
(a). ncapsularea pachetului este prezentat n fig.

(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, 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 urmtoare. Acesta const din trei
cuvinte de 32 bii i eventual unele extensii. Primul cuvnt conine cmpul
Versiune, care este deja la 2. S sperm c aceast versiune este foarte

asemntoare cu ultima versiune deoarece a mai rmas aici doar un punct de

cod (dei 3 ar putea fi definit ca semnificnd faptul c versiunea real se gsete
ntr-un cuvnt extins).

Antetul RTP-ului.
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. 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, rom: 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 (eng.:
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 moment.

2. PROTOCOALE
INTERNET:

DE

TRANSPORT

PRIN

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.
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 interreelei 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 anteteleTCP 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, vom 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, 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 IP-ul nu o
ofer.
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), aa cum s-a
discutat n Sec. 6.1.3. 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.
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 mai jos.

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 sar proceda astfel s-ar umple memoria cu demoni inactivi n majoritatea
timpului. n schimb, n general se folosete un singur demon, numit inetd
(Internet daemon, rom: 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 (ca in
figura de mai jos) sau n orice alt mod. Nu exist posibilitatea ca receptorul s
determine numrul de uniti n care a fost scris informaia.

(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, s presupunem 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, 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 (exemplu 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 urgent
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.
Protocolul TCP
n aceast seciune vom prezenta un punct de vedere general asupra
protocolului TCP, pentru a ne concentra apoi, n seciunea care i urmeaz,
asupra antetului protocolului, cmp cu cmp.

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, dup cum vom vedea mai trziu. 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 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 pe
care le vom prezenta 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.
Antetul segmentului TCP
n figura urmatoare 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 associate 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.

Antetul TCP
S disecm acum structura antetului TCP, cmp cu cmp. 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 (eng.: 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 datelor 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 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 = 1 i 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 protocoalele din cap. 3, confirmrile pentru cadrele primite i
permisiunea de a trimite noi cadre erau legate una de alta. Aceasta era o

consecin a dimensiunii fixe a ferestrei pentru fiecare protocol. 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. O
vom studia detaliat mai jos. Este de asemenea prevzut o Sum de control, n
scopul obinerii unei fiabiliti extreme.
Aceast sum de control este calculat pentru antet, informaie i pseudoantetul conceptual prezentat n figura de mai jos. 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 1 i aplicnd apoi nc o dat complementul fa de 1
asupra sumei. n acest mod, atunci cnd receptorul aplic acelai calcul asupra
ntregului segment, 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.

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 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 (eng.: 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.
Acestea sunt protocoalele de transport care stau la baza transmisiilor de
date in INTERNET