PROTOCOALE UTILIZATE ÎN REŢELE LOCALE:

   O retea de calculatoare este alcatuita dintr-un ansamblu de mijloace de transmisie si de

sisteme de calcul, pentru a realiza atat functii de transport a informatiei cat si functii de
prelucrare a acesteia. O retea de calculatoare care interconecteaza diferite sisteme de calcul poate
functiona in bune conditii numai daca exista o conventie care stabileste modul in care se
transmite si se interpreteaza informatia, conventie numita protocol.
Un exemplu ar fi modul de comunicare intre doi filozofi.

Filozof 1                                                    Filozof 2

          Doi filozofi, din tari diferite doresc sa faca schimb de idei. Din pacate, sunt departe unul de
celalalt si nici nu au o limba comuna prin care sa comunice.Pentru a putea sa comunice trebuie sa
foloseasca suport de comunicatie.Pentru a putea comunica, fiecare filozof angajeaza cate un
traducator care sa cunoasca ambele limbi, iar ei la randul lor angajeaza cate o secretara care se va
ocupa cu transmiterea efectiva a mesajului.
          Urmarind figura, se observa ca filozoful 1 trimite translatorului sau mesajul pe care doreste
sa-l primeasca filozoful 2. Acesta il traduce si il inmaneaza secretarei care il transmite mai departe
prin fax, posta electronica sau cu telefonul secretarei 2.
               In concluzie un protocol este un set de reguli si conventii ce se stabilesc intre participantii
(de exemplu, filozof 1- filozof 2) la o comunicatie in vederea asigurarii bunei desfasurari a
comunicatiei respective; sau protocolul este o intelegere intre partile care comunica asupra modului
de realizare a comunicarii.
          Din exemplu anterior, s-a observat ca pentru a realiza comunicatia sunt necesare mai multe
reguli (protocoale) care se stabilesc intre membrii de pe acelasi nivel si intre membrii din cadrul
aceluiasi grup. Acest concept se numeste familie de protocoale (stiva) si reprezinta o lista de
protocoale utilizate de catre un anumit sistem, cate un protocol pentru fiecare nivel.
         
Protocoalele sunt de doua feluri:
- rutabile: sunt acel protocoale care accepta comunicatii LAN - LAN pe mai multe cai;
- nerutabile.

          In cadrul unui aceluiasi grup (filozof - translator - secretar) intre participantii la comunicatie
schimbul de informatii se face pe baza unor alte conventii, numite servicii. In general participantii la
comunicatie se numesc entitati. Entitatile de pe un nivel n (de exemplu, filozoful) furnizeaza un
serviciu utilizat de catre nivelul n+1 (in cazul nostru, traducator). Nivelul n se numeste furnizor de
servicii, iar nivelul n+1 se numeste utilizator de servicii

1
 IPX/SPX, TCP/IP

Protocoalele IPX şi SPX reprezintă două tipuri de bază de protocoale de comunicaţie în

reţele: IPX nu se bazează pe conexiuni, pe când SPX este orientat către conexiune. Vor fi arătate
avantajele şi dezavantajele fiecărui tip de protocol şi vor fi prezentate structurile pachetelor IPX
şi SPX.

1 Protocolul IPX

Netware IPX este un protocol bazat pe datagrame (fără conexiune). Termenul fără
conexiune înseamnă că atunci când o aplicaţie foloseşte IPX pentru a comunica cu alte aplicaţii din
cadrul reţelei, nu este stabilită nici o conexiune sau cale de date între cele două aplicaţii. Deci,
pachetele IPX sunt trimise către destinaţiile lor, dar nu se garantează şi nici nu se verifică faptul că
acestea ajung sau nu la destinaţie. Termenul datagramă (datagram) desemnează faptul că un pachet
este tratat ca o entitate individuală, care nu are nici o legătură sau relaţie secvenţială cu alte pachete.
IPX execută funcţii echivelente nivelului reţea din modelul OSI. Aceste funcţii includ
adresare, rutare şi transfer de pachete pentru schimburi de informaţie, funcţiile IPX fiind dedicate
transmisiei de pachete în cadrul reţelei.

Avantaje şi dezavantaje

Deoarece IPX execută doar sarcinile nivelului reţea din modelul OSI, oferă beneficiile
vitezei şi performanţei care rezultă din încărcarea mică pe care o produce. Totuşi, serviciile IPX
sunt insuficiente dacă sunt necesare garanţiile nivelului transport. IPX este deci folosit în cazul în
care este potrivit tipului particular de aplicaţie, alegând în funcţie de caz IPX sau SPX.
Principalele avantaje şi dezavantaje ale IPX sunt:

• Disponibilitatea simultană a sursei şi destinaţiei nu este necesară, deoarece nu există o

conexiune predeterminată. Totuşi, sursa nu primeşte nici o confirmare a faptului că destinaţia a
primit datele;
• Flexibilitatea în rutarea pachetelor este mare, deoarece nu este necesară o rută
predeterminată a pachetelor;
• Pachetele pot fi trimise către destinaţii multiple pur şi simplu prin duplicarea pachetului şi
schimbarea adresei destinaţie.

Un mesaj se poate trimite folosind IPX prin plasarea mesajului în porţiunea de date a unui
pachet IPX, la fel ca şi punerea unui mesaj într-un plic. Headerul pachetului IPX trebuie să conţină
reţeaua destinaţie, numerele de nod şi soclu (adică adresa la care trebuie trimis pachetul). IPX
trimite fiecare pachet individual prin diferite subreţele (posibil pe diferite rute pentru a profita de
traficul mai scăzut) până când pachetul atinge destinaţia. Deoarece fiecare pachet este o entitate
individuală, rutarea şi secvenţierea pachetelor poate să varieze.

Când pachetul ajunge, sursa nu primeşte nici o informaţie privind livrarea cu succes a
pachetului. Doar dacă destinaţia ia hotărârea să trimită un pachet către sursă, sursa poate fi sigură de
ajungerea pachetului la destinaţie. Oricum, IPX trimite cu succes aproximativ 95% din numărul
pachetelor.

2
1.1 Structura pachetului IPX

Pachetul IPX este identic din punct de vedere al structurii cu un pachet Xerox IDP. El are
două părţi: un header de 30 de octeţi şi o porţiune de date cu o lungime între 0 şi 546 octeţi.
Lungimea minimă a pachetului este 30 octeţi (doar headerul), iar lungimea sa maximă este 576
octeţi (30+546). Structura pachetului IPX este prezentată în tabelul 1.
Toate câmpurile sunt structurate high-low, adică cel mai semnificativ octet al câmpului este
primul.

Offset Conţinut Tip

0 Checksum BYTE[2]
2 Length BYTE[2]
4 Transport Control BYTE
5 Packet Type BYTE
6 Destination Network BYTE[4]
10 Destination Node BYTE[6]
16 Destination Socket BYTE[2]
18 Source Network BYTE[4]
22 Source Node BYTE[6]
28 Source Socket BYTE[2]
30 Data Portion byte[0546]

Tabelul 1. Structura pachetului IPX.

Semnificaţia câmpurilor headerului este următoarea:

Checksum (Suma de control)

Acest câmp a fost inclus pentru conformitate cu headerul original Xerox. IPX îl încarcă
totdeauna cu valoarea 0FFFFh. Cartelele de reţea aplică sume de control întregului pachet IPX, deci
acest câmp nu este necesar.

Length (Lungime)
Acest câmp conţine lungimea întregului pachet (header+date). Valoarea lui minimă este 30,
iar cea maximă 576. IPX setează acest câmp.

Transport Control (Controlul transportului)

Acest câmp este folosit de bridge-urile inter-reţea NetWare. IPX îl încarcă cu valoarea 0.

Packet Type (Tipul pachetului)

Acest câmp indică tipul de serviciu oferit sau cerut de către pachet. Xerox a definit
următoarele valori (totuşi, utilizatorii IPX trebuie să seteze valoarea acestui câmp la 0 sau 4):
• 0 - Pachet necunoscut;
• 1 - Pachet care conţine informaţii de rutare;
• 2 - Pachet în ecou;
• 3 - Pachet de eroare;

3
 • 4 - Packet Exchange Packet (pachet IPX);
• 5 - Sequenced Packet Protocol Packet (pachet SPX);
• 1631 - Protocoale experimentale;
• 17 - Protocol NetWare Core (Core = miez).

Utilizatorii IPX trebuie să seteze tipul pachetului la 0 sau 4, iar utilizatorii SPX trebuie să-i
dea valoarea 5.

Destination Network (Reţeaua destinaţie)

Acest câmp conţine numărul reţelei căreia îi aparţine nodul destinaţie. în cazul NetWare,
reţelele din cadrul unei reţele globale primesc de la administratorul reţelei globale un număr unic de
4 octeţi. Când acest câmp este 0, nodul destinaţie este în aceeaşi reţea ca şi nodul sursă, pachetul
nefiind procesat de un bridge inter-reţea.

Destination Node (Nodul destinaţie)

Acest câmp conţine adresa fizică a nodului destinaţie. Lungimea acestui câmp este variabilă
în funcţie de topologia reţelei. Un nod din cadrul unei reţele Ethernet va avea o adresă fizică de 6
octeţi, pe când un nod din cadrul unei reţele Omninet va avea o adresă de un octet. Dacă o adresă
fizică are lungimea mai mică de 6 octeţi, adresa trebuie să ocupe cea mai putin semnificativă poziţie
în cadrul câmpului, prima parte a acestuia trebuind completată cu zero. O adresă de nod egală cu
0FFFFFFFFFFFFh (6 octeţi formaţi numai din biţi unu) identifică un pachet broadcast.

Destination Socket (Soclul destinaţie)

Acest câmp conţine adresa soclului procesului destinaţie a pachetului. Soclurile rutează
pachetele către diferite destinaţii în cadrul aceluiaşi nod. Xerox a rezervat următoarele numere de
socluri:
• 1 - Routing Information Packet;
• 2 - Echo Protocol Packet;
• 3 - Error Handler Packet;
• 20h03Fh - Experimental;
• 10BB8h - Registered with Xerox;

Xerox a asignat pentru Novell un set de socluri pentru folosirea de către NetWare:
• 451 - File Service Packet;
• 452 - Service Advertising Packet;
• 453 - Routing Informaton Packet;
• 455 - NetBIOS Packet;
• 456 - Diagnostic Packet.

De exemplu, serverele NetWare acceptă cereri adresate soclului 451.

Source Network (Reţeaua sursă)
Source Node (Nodul sursă)
Source Socket (Soclul sursă)
Aceste trei câmpuri au semnificaţii similare cu cele corespunzătoare destinaţiei.

2 Protocolul SPX

SPX este identic cu IPX cu excepţia faptului că oferă servicii suplimentare conferite de
faptul că se află la nivelul transport din modelul OSI, spre deosebire de IPX, aflat la nivelul reţea.
Aceste funcţii suplimentare fac din SPX un protocol orientat către conexiune. Aceasta înseamnă că
înainte ca un pachet SPX să fie trimis, se stabileşte o conexiune între sursă şi destinaţie. SPX

4
garantează livrarea datelor, secvenţierea pachetelor, detectarea şi corectarea erorilor şi suprimarea
pachetelor duplicate.

Avantaje şi dezavantaje

În schimbul acestor garanţii, SPX nu are viteza şi performanţele IPX. Proiectantul de

aplicaţii trebuie să determine ce este mai important pentru aplicaţiile sale: viteza sau siguranţa
livrărilor. Astfel, el va alege IPX sau SPX. Iată în continuare câteva dintre avantajele şi
dezavantajele folosirii SPX:
• Livrarea garantată a datelor; conexiunea este stabilită înainte ca informaţia să fie trimisă şi
la sursă se întorc informaţii privind livrarea cu succes. Trimiterea de pachete broadcast este greoaie,
deoarece trebuie stabilită o conexiune cu fiecare potenţial receptor înainte. De asemenea, unele
aplicaţii nu au nevoie de garantarea livrării fiecărui pachet;
• Secvenţiere garantată a pachetelor; deci, oricâte pachete ar cere transmiterea unui flux de
date, acestea vor ajunge în ordine;
• Suprimarea pachetelor duplicat; în timpul procesului de garantare a livrării (care include
retransmiterea pachetelor considerate pierdute), este posibilă apariţia unor pachete duplicat care
ajung ambele la nodul destinaţie; SPX elimină astfel de pachete, deci aplicaţia primeste doar o copie
a datelor trimise de către partenerul de comunicaţie.

2.1 Structura pachetelor SPX

Un pachet SPX este identic ca structură cu un pachet IPX, cu excepţia faptului că are 12
octeţi suplimentari în header. Pachetul SPX constă din două părţi: un header de 42 de octeţi şi un
câmp de date care poate conţine între 0 si 534 octeţi. Lungimea minimă a pachetului este de 42
octeţi (doar headerul), iar cea maximă de 576 octeţi (42+534).
Câmpurile pachetului SPX care au aceeaşi denumire ca şi cele din cadrul pachetelor IPX au
şi aceeaşi semnificaţie ca şi acestea, cu specificarea că niciodată în cadrul unui pachet SPX nu se
permite o valoare 0FFFFFFFFFFFFh a adresei nodului destinaţie (nu sunt permise broadcast-uri),
iar SPX încarcă totdeauna valoarea 5 în câmpul Packet Type. În tabelul 2 este prezentată structura
pachetului SPX:

Offset Conţinut Tip

0 Checksum BYTE2
2 Length BYTE2
4 Transport Control BYTE
5 Packet Type BYTE
6 Destination Network BYTE4
10 Destination Node BYTE6
16 Destination Socket BYTE2
18 Source Network BYTE4
22 Source Node BYTE6
28 Source Socket BYTE2

30 Connect. Control BYTE

5
 31 Data Stream Type BYTE
32 Source Connect. ID BYTE2
34 Dest. Connect ID BYTE2
36 Sequence Number BYTE2
38 Acknowledge Number BYTE2
40 Allocation Number BYTE2
42 Data Portion BYTE0534

Tabelul 2. Structura pachetului SPX.

Ordinea octeţilor în cadrul câmpurilor este high-low, ca şi în cazul IPX. Semnificaţiile

câmpurilor suplimentare faţă de cele din cadrul headerului IPX sunt:

Connection Control (Controlul conexiunii)

Acest câmp conţine 4 indicatori de 1 bit folosiţi de SPX şi clienţii săi pentru a controla
fluxul bidirecţional de date de-a lungul unei conexiuni:
• 18 - Valori nedefinite de către Xerox Sequenced Packet Protocol. SPX îi ignoră;
• 10h - Sfârşitul unui mesaj; clientul setează acest bit pentru a semnala sfârşitul mesajului
partenerului său; SPX ignoră acest bit şi îl livrează neschimat partenerului;
• 20h - Atenţie; clientul setează acest indicator dacă pachetul este un pachet de atenţionare;
această facilitate nu a fost implementată; SPX ignoră acest bit şi îl livrează neschimat
partenerului;
• 40h - Se cere confirmare; SPX setează acest bit dacă este necesar un pachet de
confirmare; deoarece SPX controlează cererile şi răspunsurile de confirmare, clientul trebuie
să ignore acest indicator;
• 80h - Pachet sistem; SPX setează acest bit dacă pachetul este un pachet sistem; aceste
pachete sunt folosite intern şi nu sunt livrate clienţilor.

Clienţii nu trebuie să folosească sau să modifice niciodată biţii nedefiniţi, de confirmare sau
sistem. Aceştia sunt rezervaţi pentru folosirea de către SPX.

Data Stream Type (Tipul fluxului de date)

Acest câmp este un indicator de un octet care arată tipul datelor care au fost găsite în cadrul
pachetului. Valorile posibile sunt arătate în continuare:
• 00FDh - Definit de client; SPX ignoră aceste valori;
• 0FEh - Sfârşitul conexiunii; când un client execută un apel pentru a termina o conexiune
activă, SPX va genera un pachet de terminare a conexiunii. Acesta va fi ultimul pachet
trimis partenerului în cadrul conexiunii;
• 0FFh - Confirmarea sfârşitului conexiunii; SPX generează un pachet de confirmare a
sfârşitului conexiunii automat; acest pachet este marcat sistem şi nu este livrat clienţilor.

Source Connection ID (Identificatorul sursei)

Acest câmp conţine un număr de identificare asignat de către SPX sursei pachetului.

Destination Connection ID (Identificatorul destinaţiei)

Acest câmp contine un număr de identificare asignat de către SPX destinaţiei pachetului şi
folosit pentru demultiplexarea pachetelor sosite în cadrul multiplelor conexiuni care ajung la acelaşi

6
soclu; demultiplexarea este necesară deoarece conexiunile active concurente de pe orice maşină pot
folosi acelaşi număr de soclu.

Sequence Number (Numărul de secvenţă)

Acest câmp reţine numărul pachetelor schimbate într-o direcţie a conexiunii. Fiecare parte a
conexiunii ţine propriul contor. Numărul ia valoarea zero după ce depăşeşte 0FFFFh. Deoarece SPX
controlează acest câmp, clienţii nu sunt interesaţi de valoarea lui.

Acknowledge Number (Număr de confirmare)

Acest câmp indică numărul de secvenţă al următorului pachet pe care SPX se aşteaptă să îl
recepţioneze. Orice pachet cu un număr de secvenţă mai mic decât valoarea acestui câmp este în
secvenţa corectă şi nu trebuie retransmis. Deoarece SPX controlează acest câmp, clienţii nu sunt
interesaţi de valoarea lui.

Allocation Number (Număr de buffere alocate)

Acest câmp indică numărul de buffere de ascultare disponibile într-o direcţie a conexiunii.
SPX poate să trimită pachete doar până când numărul de secvenţă devine egal cu numărul de
buffere alocate la celălalt capăt al conexiunii. Deoarece SPX controlează acest câmp, clienţii nu sunt
interesaţi de valoarea lui.

3 Protocoalele TCP/IP

Transmission Control Protocol (TCP) şi Internet Protocol (IP) se referă de fapt la un set de
protocoale şi servicii care împreună permit calculatoarelor legate în reţea să se interconecteze pentru
a realiza transferuri de fişiere, servicii de poştă electronică şi sesiuni de lucru interactiv la distanţă.
TCP este folosit pe scară largă în mediile academice şi inginereşti (şi, de exemplu, în cadrul
reţelei guvernamentale americane).
De asemenea, datorită marelui număr de programe apărute pe piaţă care folosesc TCP/IP,
acest set de protocoale a început să fie din ce în ce mai răspândit în mediul comercial, ca şi în cadrul
reţelelor locale de calculatoare.

3.1 Protocolul Internet (Internet Protocol - IP)

Între protocoalele de nivel 3 (nivelul REţEA) documentate de Departamentul de Apărare al

Statelor Unite (DoD - Department of Defense), Internet Protocol este cel mai important. Principalul
său scop este de a interconecta mai multe reţele bazate pe schimbul de pachete într-o supra-reţea
(internet - în continuare vom înţelege prin internet (scris cu litere mici) orice suprareţea (reţea
globală). Atunci când este nevoie să se specifice în mod explicit că este vorba despre reţeaua
Internet iniţiată de către DoD, cuvântul Internet se va scrie cu prima literă capitalizată). IP îşi oferă
serviciile diferitelor protocoale de pe nivelele superioare (Upper Layer Protocols - ULP) prin
asistarea livrării datelor ULP prin internet în cadrul unuia sau mai multor blocuri de date
(datagrams).

7
 Figura 1. O privire din punct de vedere logic asupra structurii Internet la nivelul IP

Arhitectura internet permite o ierarhie de reţele independente logic pe două nivele. Nivelul
cel mai de sus este conexiunea între reţele pereche. O reţea poate să conţină o colecţie de subreţele
pereche. Reţelele şi subreţelele pot să conţină hosturi ataşate direct, după cum se poate observa în
figura 1.
Singura diferenţă între reţele şi subreţele constă în modul în care sunt interpretate adresele
IP şi depinde de localizarea modulului IP specificat de adresă. În majoritatea cazurilor, subreţelele
pot fi numite pentru simplitate reţele. În general, termenul "subreţea" este folosit doar în cazul în
care este necesar să se facă distincţia între diferitele nivele ierarhice ale internet.
IP este limitat la funcţiile de bază necesare transmisiei unui bloc de date (datagram) prin
internet. Fiecare bloc de date este o entitate independentă, nefiind legată de alte "datagrame"
(traducerea, poate puţin forţată, a termenului "datagram" este preluată din cartea "Reţele de
calculatoare", cu semnificaţia "mesaj fără confirmare"). Nivelul IP al hostului asigură servicii
protocoalelor de la nivelul transport şi foloseşte serviciile nivelului legăturii de date pentru a
transmite datagramele hostului destinaţie. IP nu pretinde că ar oferi servicii sigure. Calculatoarele
gazdă (hosts) vor ignora datagramele atunci când nu au resurse suficiente pentru procesare şi nu vor
detecta datagramele pierdute sau ignorate de către nivelul legăturii de date.
IP izolează protocoalele de pe nivelele superioare de caracteristicile specifice reţelei.
Serviciile adiţionale furnizate de către IP includ diferite nivele de comportare a transmisiei,
implicând caracteristici ca: precedenţă, nivel de încredere, întârzieri. IP permite de asemenea
etichetarea datelor, necesară în medii sigure, pentru a asocia datelor informaţii de securitate.
Transmisia începe atunci când un protocol de pe nivelul superior transmite date către IP
pentru livrare. IP împachetează datele în format internet datagram şi le transmite protocolului de pe
nivelul legăturii de date pentru transmisie prin reţeaua locală. Dacă hostul destinaţie se află legat
direct în reţeaua locală, IP trimite pachetul direct acestui host. Dacă destinaţia se află într-o altă
reţea, IP trimite pachetul unui gateway IP local pentru transmisie. Acest gateway va trimite pachetul
prin următoarea reţea hostului destinaţie sau unui alt gateway. Astfel, datagrama se propagă prin
setul de reţele interconectate de la un modul IP la altul, până când aceasta ajunge la destinaţie.

8
Pachetele transmise de către hostul numărul 1 pot să circule pe una dintre cele două căi prezentate.
(figura 2)

Figura 2. Transmisia datelor prin intermediul IP

Gateway-urile, uneori numite "Routere IP" (sau "Local Bridges" ori "Remote Bridges") sunt
de fapt un fel de "relee de pachete" care interconectează două sau mai multe reţele sau subreţele.
Fiecare gateway conţine un modul IP aflat deasupra a două sau mai multe procese bazate pe
protocoale aflate la nivelul legăturii de date.
Modulele IP folosesc reguli comune pentru interpretarea adreselor internet necesare în
procesul stabilirii traseului pe care pachetul trebuie să-l urmeze pentru a ajunge la destinaţie.
Rutarea executată de către un gateway se bazează pe câmpul network/subnetwork al adresei internet
de destinaţie.
Un gateway ataşat mai multor reţele trebuie să decidă care este reţeaua următoare prin care
trebuie să treacă pachetul pe care l-a primit pentru a ajunge la destinaţie. De asemenea, trebuie să
decidă dacă hostul destinaţie se află în cadrul următoarei reţele (caz în care pachetul poate fi trimis
direct acestui host) sau dacă cel puţin un alt gateway este necesar pentru a trimite pachetul către
reţeaua destinaţie aflată la distanţă.
Pentru a determina care este următorul gateway căruia trebuie să-i fie transmis pachetul,
echipamentul gateway curent trebuie să cunoască opţiunile pe care le are la dispoziţie şi modul de
alegere a următorului gateway dintre cele disponibile. Echipamentul gateway curent trebuie să fie
capabil să achiziţioneze într-un fel oarecare informaţii despre alte echipamente gateway şi despre
căile disponibile pentru ca un pachet să poată atinge reţeaua destinaţie. Cel mai bine ar fi ca aceste
informaţii privind posibilitatea atingerii de către un pachet a unei reţele îndepărtate să poată fi
achiziţionată şi menţinută dinamic, în acord cu conectivitatea instantanee asigurată de toate celelalte
echipamente gateway ale reţelei globale (internet). Pentru a putea fi atins acest scop, echipamentele
gateway trebuie să fie capabile să schimbe între ele informaţii asupra posibilităţii de a trimite un
pachet către diferite reţele. De-a lungul anilor, au fost dezvoltate mai multe protocoale gateway-
gateway, protocoale care caută să furnizeze acest schimb de informaţii.
Echipamentele gateway care conectează un set de reţele private din punct de vedere al
proprietăţii şi administrării pot să folosească orice protocol, fără restricţii. De obicei, un asemenea
protocol privat se numeşte Interior Gateway Protocol (IGP). În termeni IP, fiecare astfel de reţea
administrată independent este numită sistem autonom (Autonomous System).
Pe de altă parte, toate echipamentele gateway care fac legătura între reţele private şi reţele
publice de date (DDN, Digital Data Networks) trebuie să folosească un protocol oficial simplu şi
bine definit numit Exterior Gateway Protocol.

9
3.1.1 Headerul IP

Pachetele (datagramele) IP au un antet (header) bine definit, header definit de standardele

DoD (U.S.A. Department of Defense). Acest header are structura prezentată în figura 3.
În continuare sunt prezentate câmpurile care compun acest header:

Version (Versiune)
Abreviere: VER
Lungimea câmpului: 4 biţi
Câmpul Version indică formatul headerului IP. Va fi prezentată în continuare versiunea 4,
ultima până la data apariţiei materialului bibliografic avut la dispoziţie (1988). Versiunile 13 nu
mai erau deja folosite încă la acea dată.
Câmpul Version indică versiunea protocolului căreia îi aparţine pachetul. Includerea
versiunii protocolului în fiecare pachet face posibilă dezvoltarea de noi protocoale şi testarea
acestora fără a afecta buna funcţionare a reţelei.

Internet Header Length (Lungimea headerului Internet)

Abreviere: IHL
Lungimea câmpului: 4 biţi
Unitate: Grupe de câte 4 octeţi
Gamă: 515 (implicit 5)
Câmpul Internet Header Length indică lungimea headerului IP exprimată în multipli de
unităţi de 32 biţi. Acest câmp este necesar deoarece headerul IP are o lungime variabilă datorită
faptului că lungimea câmpului Options nu este constantă.

Figura 3. Headerul IP

Type of Service (Tipul de serviciu)

Abreviere: TOS
Lungimea câmpului: 8 biţi
Câmpul Type of Service conţine parametrii IP care descriu calitatea serviciului dorită pentru
prezentul pachet transmis. Câmpul permite calculatorului gazdă să specifice reţelelor de tranzit tipul

10
de serviciu pe care îl doreşte. Câmpul permite specificarea precedenţei pachetului, nivelul dorit de
încredere şi nivelul presupus de consumare a resurselor, după cum se va arăta mai jos.
Tipul de serviciu se foloseşte pentru a specifica reţelelor de tranzit ce serviciu se doreşte de
la acestea. Reţelele de tranzit decid dacă pot sau doresc să se achite de serviciile cerute.

Total Length (Lungimea totală)

Abreviere: TL
Lungimea câmpului: 16 biţi
Total Length este lungimea pachetului, măsurată în octeţi, incluzând headerul IP şi zonele
de date ale pachetului.
Se observă că lungimea câmpului Total Length permite o lungime totală maximă a
pachetului de 65.536 octeţi.

Identification (Identificare)
Abreviere: ID
Lungimea câmpului: 16 biţi
Câmpul reprezintă o valoare de identificare folosită pentru a asocia fragmentele unui pachet.
ULP (Upper Layer Protocol) care transmite de obicei generează această valoare ca pe un parametru
al interfeţei. Altfel, IP generează acest câmp în aşa fel încât el să fie unic pentru fiecare ULP care
transmite.
Câmpul Identification indică numărul pachetului pentru a permite calculatorului gazdă
destinaţie să determine cărui pachet îi aparţine fragmentul care tocmai a sosit.

Flags (Indicatori)
Abreviere: -
Lungimea câmpului: 3 biţi
Acest câmp conţine indicatorii de control Don't Fragment (a nu se fragmenta, care inhibă
fragmentarea pachetului de către IP) şi More Fragments (care ajută la identificarea poziţiei unui
fragment în pachetul original).
Indicatorul Don't Fragment este destinat pentru folosirea cu calculatoare gazdă care nu sunt
capabile să reconstituie pachetul din fragmentele din care este format. De fapt, multe implementări
ale TCP/IP nu permit fragmentarea şi reconstituirea pachetelor.

Fragment Offset (Offsetul fragmentului)

Abreviere: FO
Lungimea câmpului: 13 biţi
Unitate: Grupe de câte 8 octeţi
Gamă: 08191 (implicit 0)
Câmpul indică poziţia fragmentului relativ la începutul datelor în pachetul original. Atât un
pachet complet, cât şi primul fragment al unui pachet au acest câmp resetat.
Fragment Offset localizează poziţia fragmentului curent într-un pachet ca multiplu de 8 biţi.
Pentru aceasta, lungimea câmpului este de 13 biţi, deci sunt permise maximum 8.192 fragmente
pentru fiecare pachet, în acest caz extrem, primele 8.191 fragmente vor avea lungimea de un octet.

Time-to-Live (Timp de viaţă)

Abreviere: TTL
Lungimea câmpului: 8 biţi
Unitate: secunde
Gamă: 0255 (255=4,25 minute)
Acest câmp indică timpul maxim cât poate să rămână pachetul în internet. Când valoarea
acestui câmp, după decrementare, ia valoarea zero, pachetul ar trebui distrus.

11
 Unitatea de timp utilizată pentru măsurarea timpului de viaţă al pachetului este secunda,
deci timpul maxim de viaţă al unui pachet este 255 secunde (4,25 minute).
Valoarea câmpului este scăzută cu cel puţin 1 de către fiecare router prin care trece pachetul.
Protocol (Protocol)
Abreviere: PROT
Lungimea câmpului: 16 biţi
Acest câmp arată care ULP (Upper Level Protocol) trebuie să recepţioneze porţiunea de date
a unui pachet. Numerele asignate ULP-urilor uzuale sunt disponibile de la DoD Executive Agent
for Protocols. Unele vor fi arătate mai jos, în tabelul 3.
Câmpul Protocol specifică protocolul particular de la nivelul 4 căruia îi aparţine pachetul (de
exemplu, TCP sau alt protocol echivalent).

Număr Prescurtare Descriere

(zecimal)
0 Reserved
1 ICMP Internet Control Message
5 ST Stream
6 TCP Transmission Control Protocol
8 EGP Exterior Gateway Protocol
9 IGP Any private interior gateway protocol
11 NVP Network Voice Protocol
17 UDP User Datagram Protocol
20 HMP Host Monitoring Protocol
22 XNS-IDP Xerox Network Systems Internet Datagram
Protocol
27 RDP Reliable Data Protocol
28 IRTP Internet Reliable Transaction Protocol
29 ISO-TP4 ISO Transport Protocol Class 4
30 NETBLT Bulk Data Transfer Protocol
61 Any host internal protocol

Tabelul 3. Numere de protocol asignate în cadrul headerului IP.

Header Checksum (Suma de control a headerului)

Lungimea câmpului: 16 biţi
Acest câmp conţine o sumă de control aplicată doar headerului IP. Suma de control ajută la
detectarea unor eventuale erori apărute în timpul transmisiei. Algoritmul după care se generează
această sumă de control este: se adună complementele faţă de 1 ale tuturor entităţilor headerului
(grupate pe câte 16 biţi) şi apoi se complementează suma faţă de 1.
Suma de control a headerului se foloseşte doar pentru a verifica validitatea datelor din
cadrul headerului. Ori de câte ori pachetul trece printr-un gateway, această sumă de control este
recalculată (deoarece de fiecare dată este modificat câmpul TTL).

12
Source Address (Adresa sursei)
Abreviere: SOURCE
Lungimea câmpului: 32 biţi
Acest câmp conţine adresa Internet a calculatorului gazdă care a generat pachetul.

Destinaton Adress (Adresa de destinaţie)

Abreviere: DEST
Lungimea câmpului: 32 biţi
Câmpul conţine adresa Internet a hostului destinaţie.
Adresele sursă şi destinaţie indică numărul reţelei folosind 824 biţi. Biţii nefolosiţi pentru
identificarea reţelei sunt folosiţi pentru a referi numărul hostului şi, opţional, numărul subreţelei.

Options (Opţiuni)
Abreviere: OPT
Lungimea câmpului: variabilă
Acest câmp a fost prevăzut pentru a permite unor versiuni ulterioare ale protocolului să
includă informaţii care nu sunt prezente în implementarea originală, să permită experimentatorilor s
încerce noi idei şi să evite alocarea permanentă a unor biţi în cadrul headerului pentru informaţii rar
folosite.
Lungimea acestui câmp depinde de numărul şi tipurile opţiunilor asociate cu pachetul.
Opţiunile definite oficial sunt:

- Security – etichetează nivelul, compartimentul, grupul de utilizatori şi restricţiile de

manipulare, aşa cum sunt ele cerute de DoD;
- Loose Source Routing - permite celui care trimite pachetul să ceară ca pachetul să urmeze
o cale oarecare (generală) prin reţea;
- Strict Source Routing - cere ca pachetul să urmeze o cale specificată;
- Record Route - înregistrează calea urmată de pachet;
- Stream ID - permite unui gateway să manipuleze o colecţie de pachete în acelaşi fel;
- Timestamp - permite o înregistrare a căii pe care o urmează un pachet prin reţea cu
înregistrarea de asemenea a momentelor în care pachetul a ajuns în diferite locuri.

3.1.2 Fragmentarea şi reasamblarea pachetelor

Reţelele întotdeauna impun o lungime maximă a pachetelor, din cauza:

- limitărilor hardware (lăţimea unui slot de transmisie);

- limitărilor software ale unui sistem de operare particular (de exemplu, un sistem de
operare ar putea cere ca lungimea pachetelor pe care le manipuleaăÎ să nu depăşească
512 octeţi);
- protocoalele folosite (restricţii privind numărul de biţi în câmpul de lungime a
pachetelor);
- restricţii impuse de standard;
- măsuri luate pentru reducerea numărului de erori;
- limitări privind durata cât un pachet poate ocupa un canal.

În continuare, în tabelul 4, se prezintă un tabel care demonstrează diversitatea lungimii

maxime a pachetelor impusă de diferite reţele.

13
 Numele reţelei Maxim biţi
Bell Labs' Spider 256
ALOHANET (University of Hawaii) 640
X.25 (implicit) 1.024
ARPA Packet Radio Network 2.024
ARPANET 8.192
X.25 (maxim) 8.192
Ethernet 12.144

Tabelul 4. Lungimea maximă a pachetului în funcţie de reţea.

Pachetele IP de nivel 3 în tranzit pot să traverseze subreţele a căror lungime maximă a

pachetelor este mai mică decât lungimea pachetului. Pentru a se rezolva această problemă, IP
prevede mecanismele de fragmentare şi reconstituire a pachetelor.
Atunci când un gateway ar trebui să trimită un pachet într-o reţea care nu poate primi
pachetul din cauza lungimii sale, echipamentul gateway trebuie să fragmenteze pachetul original în
mai multe subpachete, numite fragmente de pachet (datagram fragments), care sunt suficient de
mici pentru a putea fi transmise.
Datagramele IP sunt transmise independent, deci datagramele fragmentate pot să nu se
"întâlnească" până când ajung la calculatorul gazdă destinaţie şi pot chiar să ajungă în altă ordine
decât cea originală. Deci, toate host-urile care pot să recepţioneze pachete trebuie să fie capabile să
le şi reasambleze.
Modulul IP din host-ul destinaţie va reasambla datagramele fragmentate într-o singură
datagramă pentru livrare către clientul său de pe nivelul transport (4).
Figura 4 ilustrează procesul fragmentării pachetelor. Pentru claritate, figura este
simplificată, neincluzând headere etc.
Trebuie remarcat că nu toate protocoalele efectuează fragmentarea şi reasamblarea în acelaşi
fel. XNS (Xerox Network Standard) cere ca reasamblarea să fie făcută de către reţeaua care a
fragmentat datagrama, ceea ce simplifică implementarea pentru host-urile receptoare. XNS impune
o restricţie importantă rutării inter-reţea şi caracteristicilor reţelei finale (receptoare) şi anume ca
cele două reţele să admită pachete de aceeaşi lungime maximă.

14
Figura 4. Fragmentarea unui pachet cu lungimea de 10 octeţi
în cazul unei reţele care acceptă doar pachete
cu lungimea de până la 8 octeţi.

15
3.1.3 Setarea parametrilor IP

IP poate să-şi adapteze serviciile pentru a permite existenţa unei diversităţi de ULP-uri. De
exemplu, un protocol de la nivelul transport care are cerinţe de lucru în timp real, cum ar fi NVP
(Network Voice Protocol) poate să folosească serviciul IP de transmisie de pachete într-un mod care
diferă de metodele utilizate de TCP, de exemplu.
Există metode specifice prin care ULP-urile pot să identifice serviciile care vor fi oferite de
către IP şi să adapteze aceste servicii într-o configuraţie particulară a reţelei.
De exemplu, dacă se doreşte ca un pachet (datagramă) să parcurgă o rută specifică în drumul
său către destinaţie, o astfel de rută (numită Source Route) poate fi specificată de către ULP. Fiecare
modul IP este capabil să trimită datagrama conform rutei specificate, eventual mărită de către
mecanismul standard de rutare, dacă este necesar.
Parametrii setabili ai IP se pot încadra în două categorii:

- parametri privind calitatea serviciilor (Service Quality Parameters);

- opţiuni privind serviciile (Service Options).

Parametrii privind calitatea serviciilor influenţează serviciul de transmisie asigurat de către

echipamentele gateway care intervin în procesul de transmisie, iar opţiunile privind serviciile sunt
folosite pentru a specifica cererea de servicii speciale care trebuie asigurate în cadrul modulelor IP.

3.1.4 Parametrii de calitate a serviciilor

Acele ULP care ştiu că datagramele lor vor trece prin echipamente gateway care pot efectua
modificări asupra pachetelor care trec prin ele, pot să sugereze acestor echipamente gateway
tratamentul pe care acestea să-l aplice fiecăruia dintre pachetele trimise. Aceste sugestii se
realizează prin intermediul parametrului TOS (Type of Service) din cadrul headerului pachetului IP.
Semnificaţia acestui câmp poate fi:

Precedence (Precedenţa) – indică echipamentului gateway să încerce să aplice un tratament

preferenţial pentru datagrame care au o înaltă importanţă. Tratamentul preferenţial poate să prevină
astfel de datagrame să fie întârziate în cadru unei cozi în interiorul echipamentului gateway, de
exemplu.

Transmision mode - datagram versus stream (Modul de transmisie – datagramă sau şir de
datagrame) - Modul Datagram (implicit) indică faptul că ULP consideră această datagramă ca fiind
un eveniment sporadic, necorelat cu datagrame trecute sau viitoare. Modul Stream cere
echipamentului gateway să minimizeze întârzierile şi dispersia întârzierilor între transmisiile
pachetelor similare, prin rezervarea resurselor reţelei.

Reliability (încredere) - destinat minimizării pierderii datelor şi ratei erorilor. Acest

parametru asigură faptul că resursele cozilor sunt alocate în primul rând pachetelor care cer un înalt
nivel de siguranţă şi faptul că pachetele care nu cer în mod explicit acest lucru pot să fie "aruncate"
în cazul în care nu mai este loc în coadă şi apare un pachet care cere un înalt nivel de încredere.

Resource Tradeoff – indică dacă este mai important să se onoreze cererea de "High
Precedence" sau cea de "High Reliability" în cazul în care echipamentul gateway nu poate să le
asigure pe ambele în acelaşi timp.
Noţiunea de Stream Mode versus Datagram Mode de obicei nu este folosită în cazul
reţelelor locale sau WAN terestre, dar se foloseşte în cazul reţelelor bazate pe rutarea prin satelit,
deoarece routerele aflate pe sateliţi în general pot să ceară alocarea unei benzi de transmisie în
avans. Dacă routerul constată că începe să recepţioneze pachete care au bitul Stream Mode setat, el

16
poate să anticipeze primirea mai multor pachete care fac parte din acelaşi şir şi deci va cere staţiilor
sale pereche alocarea într-un viitor apropiat a unei benzi de frecvenţă mai mari pentru a se asigura
că un pachet care va fi recepţionat nu va fi întârziat în momentul recepţiei pentru a se cere alocarea
unei benzi de frecvenţă în timp real (routerele aflate pe sateliţi nu pot să comunice între ele
instantaneu; pachetele care trec prin ele au cel puţin o întârziere de un sfert de secundă).

3.1.5 Opţiuni privind serviciile

Headerul IP poate să fie expandat pentru a include unele câmpuri opţionale pentru a cere
servicii IP în nodurile sursă, destinaţie sau intermediare (de rutare). Câteva dintre opţiunile definite
sunt:

Security Labeling – Identifică nivelul de securitate (secret, strict secret etc.) al datagramei
pentru serverele care conţin informaţii secrete.

Source Routing – Selectează setul de module IP din echipamentele gateway prin care trebuie
să treacă pachetul, în acord cu specificaţia celui care trimite pachetul. Permite unui nod să selecteze
reţelele prin care urmează să tranziteze pachetul şi reţelele prin care nu trebuie să tranziteze
pachetul, astfel îmbunătăţind nivelul de securitate al unor anumite tipuri de tranzacţii. Source
Routing poate fi specificată ca fiind "slabă" (lăsându-se echipamentului gateway unele libertăţi) sau
"strictă".

Route Recording - Cere înregistrarea modulelor IP din cadrul echipamentelor gateway prin
care tranzitează pachetul, astfel încât hostul destinaţie poate să ştie toate locurile prin care a trecut
pachetul.

Stream Identification – Identifică şirul de pachete căruia îi aparţine pachetul; este folosit în
cadrul serviciilor de tip stream.

Timestamping - Permite echipamentului gateway să marcheze momentul în care a procesat

o datagramă.

Don't Fragment – Marchează o datagramă ca fiind o unitate indivizibilă, care nu trebuie să

fie fragmentată de către echipamentul gateway.

3.1.6 Serviciul de raportare a erorilor

Unele erori detectate de către protocoalele de la nivelul legăturii de date sau raportate de
către protocoalele IP pereche trebuie indicate de către nivelul IP al unui host nivelelor superioare
interesate de aceste erori. Aceste indicaţii descriu câteva clase de erori, incluzând argumente
invalide, resurse insuficiente şi probleme de transmisie. Erorile care sunt raportate de IP nivelelor
superioare sunt în general determinate de fiecare implementare a IP.

3.1.7 Asignarea adreselor IP în funcţie de configuraţia reţelei

Unul dintre scopurile IP este de a asigura servicii într-o mare varietate de medii (reţele şi
reţele globale). Mecanismul de adresare IP este astfel conceput încât să permită trei clase diferite de
configuraţii ale reţelelor. Cele trei clase de adrese IP, notate A, B, C, sunt prevăzute pentru reţele
care au:
• A - multe hosturi distribuite în reţele puţine;
• B - o distribuţie medie a hosturilor şi reţelelor;
• C - puţine hosturi în multe reţele.

17
 Aceste situaţii sunt ilustrate în figura 5.

Figura 5. Tipuri de reţele

Doar 32 de biţi sunt alocaţi pentru a exprima o adresă IP completă, care constă atât din
adresa reţelei, cât şi din adresa hostului. O reţea globală care conţine doar câteva reţele va avea
nevoie doar de câţiva biţi pentru a identifica reţeaua. Prin convenţie, aceştia vor fi cei mai
semnificativi biţi dintre cei 32 biţi disponibili pentru adresare. Pe de altă parte, o retea globală cu
multe reţele va avea nevoie de mai mulţi biţi pentru a exprima toate adresele de reţele componente,
deci va ocupa mai mulţi biţi dintre cei 32 disponibili pentru a exprima adresa reţelei (aceşti biţi vor
fi tot cei mai seminficativi biţi ai adresei).
În cadrul unei reţele, hosturile pot fi organizate în comunităţi mai mici, numite subreţele.
Forma adreselor IP permite, pentru proiectarea subreţelelor, mascarea unor biţi pentru a putea fi
folosiţi pentru identificarea subreţelelor.
De exemplu, un campus poate avea o adresă clasă B, care cere 2 octeţi pentru porţiunea
alocată reţelei şi doi octeţi pentru porţiunea alocată hostului. În loc să existe 65.536 adrese de
hosturi, se poate alege soluţia divizării campusului în 254 subreţele (un octet), fiecare având câte
254 de hosturi (celălalt octet). Trebuie făcută observaţia că doar 254 de hosturi, respectiv reţele sunt
posibile, deoarece valorile 0 şi 255 sunt rezervate).
Adresele IP, măştile şi formatele pentru cele trei clasificări sunt ca în tabelul 5:

Clasa Cei 3 biţi mai Biţi pt. id. Biţi pt. id. Mască pt. id. reţea
semnif. reţea HOST (hex)
A 0XX 7 24 FF000000
B 10X 14 16 FFFF0000
C 110 21 8 FFFFFF00

Tabelul 5. Clasificarea tipurilor de reţele.

După cum se poate observa din tabelul de mai sus, inspectând primii trei biţi ai unei adrese
de IP se poate şti dacă este o adresă de clasă A, B sau C. Dacă primul (cel mai semnificativ) bit este
18
0, atunci adresa este o adresă clasă A. Dacă primul bit este 1, trebuie inspectat al doilea bit. Dacă
primul bit este 0 şi al doilea bit este 0, atunci adresa este de clasă B. Dacă primii trei biţi sunt 110,
adresa este de clasă C. Dacă primii trei biţi sunt 111, atunci avem de a face cu o adresă clasă D, care
nu este folosită (este o combinaţie păstrată pentru dezvoltări ulterioare). Aceste combinaţii sunt
prezentate în tabelul 6:

Clasă A primul bit 0

Clasă B primul bit 1 al doilea bit 0
Clasă C primul bit 1 al dilea bit 1 al treilea bit 0
Clasă D primul bit 1 al doilea bit 1 al treilea bit 1

Tabelul 6. Tipuri posibile de reţele.

O adresă IP este de obicei reprezentată ca patru câmpuri separate de câte un punct, fiecare
câmp reprezentând un octet (având deci valori cuprinse între 0 şi 255). Diferenţele în interpretările
acestor câmpuri depind de clasa căreia îi aparţine adresa respectivă. Se observă posibilitatea
identificării clasei unei aderse IP prin examinarea primului octet al adresei, ca în tabelul 7.

Valoare Clasă

0127 A
128191 B
192223 C
224255 D

Tabelul 7. Identificarea clasei unei reţele în funcţie

de primul octet al adresei IP

De exemplu, 10.1.17.1 este o adresă de clasă A, 128.203.5.17 este o adresă de clasă B, iar
192.1.2.10 este o adresă de clasă C.

3.1.8 Servicii pe care IP le cere nivelelor inferioare

IP nu oferă doar servicii pentru ULP. În conformitate cu principiile ISO OSI, IP cere servicii
nivelelor inferioare, incluzând transferul transparent de date între calculatoare gazdă din cadrul
aceleiaşi subreţele şi raportarea de erori. Datagramele pot să nu fie recepţionate în ordinea în care au
fost transmise şi nici nu se garantează transmiterea lor fără erori. Nivelele inferioare nivelului IP
generează rapoarte privind erorile de la nivelul subreţea şi cele inferioare, după caz. Cerinţele de
mesaje de eroare specifice sunt dependente de subreţeaua în cauză. De exemplu, în cazul unei
subreţele de tip Ethernet, spre deosebire de WAN, în general nu se raportează erori, cu excepţia
cazului în care datagrama trebuie să fie abandonată din cauza apariţiei a 16 coliziuni consecutive.
Cât timp livrarea unei datagrame prin IP nu se pretinde că ar fi infailibilă, modul în care un modul
IP reacţionează la informaţiile de eroare provenite de la nivelele inferioare este în mare măsură
nespecificat.

19
3.1.9 Internetwork Control Message Protocol (ICMP)

Nivelele superioare pot să dorească transmitera de mesaje către modulele IP, prin care să
anunţe faptul că unele aspecte privind comportarea hostului care transmite pachete ar trebui
modificate. Pentru aceasta se foloseşte ICMP. În general, mesaje ICMP sunt generate de către staţii
care percep o eroare sau o problemă în cadrul unui pachet pe care un alt host l-a transmis. Eroarea
poate fi detectată ori de hostul destinaţie, ori de un echipament gateway intermediar. Dacă reţeaua,
maşina sau portul destinaţie nu pot fi atinse, un gateway poate folosi ICMP pentru a avertiza hostul
sursă asupra acestui fapt. ICMP poate de asemenea avertiza hostul sursă asupra rutelor preferate sau
asupra congestiei reţelei.
ICMP este în mod oficial considerat ca făcând parte din IP. Totuşi, datagramele ICMP sunt
trimise folosind IP. Deci, ICMP este o parte funcţională a nivelului trei, dar este codificat ca şi când
ar face parte din nivelul patru.

3.1.10 Adress Resolution Protocol (ARP)

Toate staţiile şi echipamentele gateway sunt codificate folosind o adresă IP , care este
limitată la 32 biţi. Transmiterea de pachete printr-o reţea Ethernet, de exemplu, cere adrese
destinaţie de 48 biţi pentru a identifica nodul destinaţie. De aceea, se pot inventa, de exemplu, cei 16
biţi adiţionali. Dar, nici aceasta nu este o soluţie, deoarece adresele Ethernet sunt arbitrare şi în
general sunt setate de către producătorii cartelelor de cuplare la reţea (ba mai mult, primii 3 octeţi ai
adresei unei cartele Ethernet în general identifică producătorul cartelei). Deci, nu vor exista în
general staţii care să aibă adrese legate în vreun fel. De aceea, un alt set de servicii trebuie asigurat
în cadrul nivelului reţea, pentru a asigura transformarea unei adrese IP de 32 biţi într-o adresă
Ethernet de 48 biţi. Astfel a apărut ARP.
Atunci când un proces de la nivelul reţea doreşte să transmită un pachet care are adresa
Internet specificată, dar a cărui adresă Ethernet nu este cunoscută, acel proces de la nivelul reţea
trebuie să transmită o cerere ARP broadcast pentru a afla adresa Ethernet a destinaţiei. Un nod
urmează să răspundă cererii de adresă Ethernet conţinută în pachetul ARP, de obicei chiar nodul
destinatie. Când este recepţionat răspunsul, de obicei cei 48 biţi sunt reţinuţi într-un cache, astfel
încât atunci când va fi făcută o cerere de transmitere a unui pachet către o destinaţie, corespondentul
Ethernet al adresei IP destinaţie este căutat în cache, iar dacă este găsit, pachetul este transmis direct
şi se poate evita o tranzacţie ARP. Altfel, se generează un nou pachet ARP pentru a se afla adresa
Ethernet corespunzătoare destinaţiei.
Deci, un host rezolvă adresa destinaţie în următorul mod: Caută în cache adresa Ethernet
corespunzătoare. Dacă nu o găseşte, apelează la ARP pentru a transmite o cerere de adresă Ethernet
în reţea. Ca o alternativă, se poate folosi un fişier de configuraţie aflat la nivelul hostului sursă.
Deci, există trei surse tipice din care se poate afla echivalentul Ethernet al unei adrese IP:

- răspunsul la cereri ARP;

- memoria cache de adrese provenite de la răspunsuri ARP anteroiare;
- informaţia conţinută în fişierele de configuraţie.

Specificarea protocolului ARP permite acestui protocol să convertească o datagramă IP într-

o cerere ARP. Astfel, datagrama va fi 'consumată". De aceea, ULP trebuie să fie gata să asigure din
nou datagrama nivelului trei. Deoarece funcţiile IP sunt considerate ca nedemne de încredere,
pachetul transformat în cerere ARP este văzut de nivelul transport (nivelul patru) ca un pachet
pierdut.
Trebuie remarcat că ARP localizează hosturi aflate în aceeaşi reţea sau subreţea ca şi hostul
sursă. Utilitatea sa este limitată deci la un broadcast Ethernet. Pentru a trimite pachete unui host
dintr-o altă reţea, datagrama trebuie întâi trimisă unui router ataşat reţelei sursă. în acest caz, hostul
sursă trebuie să identifice adresa routerului, care apoi va trimite datagrama către reţeaua destinaţie.

20
 Unele routere IP răspund la cereri ARP în numele unui host îndepărtat. Hostul sursă este
astfel "păcălit", deoarece va crede că îi răspunde hostul destinaţie. Această tehnică se numeşte
Proxy ARP. Folosirea ei nu este în general recomandată, dar este necesară atunci când IP-ul unui
host nu este suficient de sofisticat pentru a determina faptul că pachetul trebuie trimis unui router
pentru a putea ajunge la destinaţie.

3.1.11 Reverse Address Resolution Protocol (RARP)

Să presupunem că singurul lucru pe care o staţie îl ştie la iniţializare este propria sa adresă
Ethernet, de obicei prin citirea informaţiei de configuraţie proprii. Deci, respectiva staţie nu îşi
cunoaşte propria adresă IP. De aceea, este necesar să încerce să afle această adresă la iniţializare.
Pentru servirea acestui scop s-a implementat protocolul RARP, care permite unei staţii să trimită un
pachet broadcast prin care să ceară informaţii de tipul "Cine sunt eu?", adică "Ce adresă IP am eu?".
De obicei, un host (tipic, un server RARP) trebuie să fie pregătit să execute inversul unui ARP,
adică să trimită înapoi adresa IP corespunzătoare adresei Ethernet primită. Acest protocol (RARP)
este folosit doar la iniţializare. RARP nu mai este apoi rulat până la o nouă iniţializare a sistemului.
O valoare 8035h a câmpului Type din cadrul headerului Ethernet identifică un pachet RARP.
Trebuie notat că trebuie să existe un server RARP pe fiecare segment Ethernet, deoarece se folosesc
pachete de tip broadcast, care nu sunt transferate mai departe de către routerele IP.

3.1.12 IP în cadrul reţelelor IEEE 802

Formatul pachetelor în reţelele IEEE 802 diferă de formatul folosit în reţelele Ethernet. În
particular, standardul IEEE 802.3 nu prevede un câmp Type, ca reţelele Ethernet. Câmpul
corespunzător este folosit pentru a specifica lungimea pachetului. Câmpuri adiţionale specifică
informaţii despre Link Service Access Point (LSAP) şi Subnetwork Access Point (SNAP), aşa cum
sunt ele definite în standardul IEEE 802.2 Aceste protocoale nu sunt încă oficial adoptate pentru
folosirea de către IP, dar par să câştige din ce în ce mai mult teren.

Ethernet IEEE 802.3

DA DA
SA SA
TYPE Length
DSAP

DATA
SSAP
Control
Protocol ID
Type

DATA

Figura 6. Poziţia headerului SNAP.

21
 SNAP va asigura o metodă standardizată de încapsulare a datagramelor IP în cele trei tipuri
de reţele prevăzute în standardul IEEE 802. De asemenea, va asigura un standard pentru
implementarea unor protocoale legate de IP, cum ar fi ARP. Încapsularea despre care s-a vorbit
arată ca în figura 6.
Pentru a indica prezenţa unui header SNAP, câmpurile DSAP şi SSAP trebuie să aibă ambele
valoarea 0AAh. Trebuie asignat un identificator de protocol SNAP (poate să aibă şi valoarea zero)
pentru a indica faptul că urmează un pachet Ethernet încapsulat. Câmpul Ethernet Type va indica
dacă acest pachet este în format IP sau nu.

3.2 Nivelul patru - nivelul transport

Nivelul transport este al patrulea nivel din cadrul modelului referinţă OSI , după cum se
arată şi în figura 7.

Figura 7. Nivelul transport

3.2.1 Servicii specifice pentru nivelul transport

Nivelul transport este destinat să asigure unei maşini servicii de conexiune şi tranzacţie.
Nivelele inferioare ale modelului se ocupă de transmisia şi rutarea pachetelor între diferite maşini.
Nivelul transport are menirea de a oferi servicii de transmisie eficiente şi sigure între diferite
procese şi nu între maşini.
Toate cele patru nivele conlucrează pentru a oferi un serviciu de transport complet, înlesnind
o comunicaţie robustă şi transparentă pe baza cărora se pot construi apoi protocoale la nivelele
superioare.
Scopul acestui nivel este de a oferi o cale de comunicaţie între diferite procese care să
simuleze o legătură punct-la-punct, procesele nefiind interesate de modul cum se face de fapt
comunicaţia.
Un protocol de la nivelul transport execută această sarcină prin împărţirea datelor în pachete
şi transmisia (eventual retransmisia) lor pentru a permite livrarea datelor în ordine, fără duplicate
sau omisiuni.
TCP/IP asigură două protocoale principale la nivelul patru: TCP (Transmission Control
Protocol) şi UDP (User Datagram Protocol), cum se arată în figura 8.

22
 Figura 8. TCP şi UDP în cadrul nivelului transport

Au fost specificate şi alte protocoale de transport, cum ar fi cele pentru transportul

semnalelor audio digitizate, dar acestea nu fac obiectul prezentului proiect.

3.3 Protocolul de control al transmisiei (TCP)

TCP a fost proiectat să opereze în diferite reţele şi să ofere conexiuni virtuale între procese,
prin transmisii sigure şi în ordine ale datelor utilizatorilor.
TCP reprezintă baza unui mecanism de comunicaţie interprocese aşezat peste câteva nivele
care oferă servicii nedemne de încredere, nivele în care pot să apară pierderi, duplicări, întârzieri,
erori sau dezordonări ale pachetelor. Este un protocol complex, care trebuie să se ocupe, de
exemplu, de detecţia pachetelor pierdute, retransmisia automată şi probleme "patologice", cum ar fi
apariţia unor pachete duplicat întârziate.
Potenţialul de a asigura robusteţe în faţa unui mediu de transmisie nesigur, fac din TCP un
protocol foarte dorit de o multitudine de aplicaţii care fac apel la intercomunicaţie.
TCP poate lucra şi în medii constituite din reţele interconectate. A fost special proiectat să
lucreze deasupra protocolului IP, aflat la nivelul trei din modelul ISO OSI (nivelul reţea), ca în
figura 9:

Figura 9. Relaţia între TCP şi IP.

23
3.3.1 Caracteristici generale ale TCP

TCP are sarcina de a asigura servicii de comunicaţie sigure între procese pereche aflate în
cadrul unor calculatoare gazdă distincte legate în aceeaşi reţea sau în cadrul unui set de reţele
interconectate. Oferă transferuri de date orientate pe conexiune la nivelul transport – aceleaşi
servicii de bază ca şi Sequenced Packet Protocol (SPP) realizat în cadrul XNS.
TCP acceptă o gamă largă de ULP care au nevoie să trimită date perechilor lor aflate pe alte
calculatoare gazdă. TCP nu încearcă să impună vreo structură a datelor trimise de către un protocol
de la nivel superior.
TCP tratează datele primite ca pe un şir continuu, lăsând structurarea mesajelor pe seama
ULP, spre deosebire de SPP, care ajută propriii clienţi la demarcarea mesajelor. TCP încearcă,
totuşi, să segmenteze datele în unităţi distincte astfel încât ele să poată fi transmise şi recepţionate ca
pachete individuale. Fiecare astfel de unitate este numită segment.
Deoarece TCP a fost proiectat să fie independent de caracteristici particulare ale reţelelor în
cadrul cărora operează, este dată o definiţie generală a noţiunii de pachet (sau segment) care permite
existenţa unor pachete cu o lungime de până la 65KB. TCP pereche pot să-şi transmită pachete care
au o lungime până la lungimea maximă definită în standard (65KB). În realitate, dacă se în cearcă
schimbul unor pachete de o asemenea lungime, nivelele IP vor fi nevoite să împartă aceste pachete
în multe pachete de nivel mai coborât, pentru ca acestea să corespundă lungimii maxime a
pachetelor în cadrul reţelei din care hostul face parte. De obicei, diversele implementări ale TCP
lucrează cu pachete care au lungimi adecvate reţelei la care sunt ataşate.
TCP asignează câte un număr de ordine fiecărui octet al şirului infinit de date al clientului
său. Atunci când schimbă segmente cu perechea sa, TCP etichetează segmentul cu numărul de
ordine al primului octet al segmentului şi cu numărul de octeţi conţinuţi în pachet. Aceasta permite
TCP să reasambleze fluxul de date atunci când îl livrează nivelelor superioare.
Dacă este nevoit să retransmită o serie de segmente, TCP poate să reîmpacheteze datele,
combinând două segmente mai mici într-un segment mai mare, de exemplu. Acest mecanism,
motivat de dorinţa de a spori eficienţa transmisiei în cadrul unor reţele larg distribuite, unde se pune
problema minimizării raportului între numărul de biţi ai headerului şi numărul de biţi de date, face
ca TCP să fie mai complex decât alte protocoale de transport.
Transmisia unui pachet folosind TCP poate să decurgă după cum urmează (figura 10):

(1) ULP sursă trimit un flux de date către TCP pentru transmisie;

(2) TCP împarte fluxul de date în segmente, eventual înzestrate cu informaţii privind
retransmisiile, ordonarea, codificarea nivelelor de precedenţă şi de securitate, controlul fluxului de
date şi contolul erorilor. Apoi, segmentul este trimis către IP.

(3) IP execută propriile atribuţiuni (creând datagramele, executând eventualele fragmentări

etc.) şi transmite datagramele prin nivelul legăturii de date şi nivelul fizic de-a lungul reţelei până la
IP destinaţie;

(4) IP destinaţie execută procesele de control sau reasamblare necesare şi livrează

datagramele ca segmente către TCP destinaţie;

(5) TCP destinaţie îşi execută propriile servicii (inverse celor de la pasul 2), restaurând
datele fragmentate pentru a reconstitui fluxul original de date transmis şi livrează aceste date către
ULP destinaţie.

24
 Figura 10. Procesul de transmisie

O descriere completă a serviciilor menţionate la pasul doi de mai sus este:

- Full-duplex - o conexiune TCP permite transmisia simultană în ambele direcţii a datelor între
ULP corespunzătoare;
- Timely - atunci când condiţiile din cadrul sistemului nu permit trimiterea la timp a datelor, aşa
cum a fost specificat de un parametru de time-out al ULP, TCP anunţă ULP asupra eşecului şi ULP
poate atunci termina conexiunea sau să ia o altă decizie adecvată;
- Ordered - TCP livrează datele către ULP destinaţie în ordinea în care le-a primit de la ULP sursă;
- Labeled - TCP asociază fiecărei conexiuni nivelele de precedenţă şi securitate care i-au fost
indicate de către ULP în timpul stabilirii conexiunii. Atunci când informaţiile nu sunt indicate de
către ULP-urile pereche, TCP va folosi nişte valori implicite. TCP stabileşte o conexiune între o
pereche de ULP doar dacă informaţiile de securitate indicate de cele două ULP care formează
perechea sunt identice. Fiecare segment TCP este etichetat cu valoarea negociată a indicatorului de
securitate. Dacă apare o neconcordanţă a nivelului de securitate în timpul unei conexiuni faţă de
nivelul negociat la început, TCP va termina conexiunea;
- Flow controlled - TCP regularizează fluxul de date prin conexiune pentru a preveni, printre
altele, congestia internă a TCP, care ar duce la degradarea sau eşecul serviciilor oferite;
- Error checked - TCP livrează datele lipsite de erori, garantând că datele sunt lipsite de erori în
măsura în care se poate garanta acest lucru bazându-se pe o sumă de control.

25
3.3.2 Formatul headerului TCP

Headerul TCP este relativ mare, structura sa fiind prezentată în figura 11.

Figura 11. Headerul TCP.

În continuare este prezentată semnificaţia fiecărui câmp al headerului TCP:

Source Port (Portul sursă)
Abreviere: SRC PORT
Lungimea câmpului: 16 biţi
În principiu, acest câmp conţine o adresă care identifică un proces sau un serviciu în cadrul
host-ului sursă. Portul sursă nu face parte din adresa IP; totuşi, combinaţia dintre adresa IP şi
numărul portului identifică în mod unic ceea ce se cheamă un soclu (socket) sau punct de acces într-
un proces dat.

Destination Port (Portul destinaţie)

Abreviere: DEST PORT
Lungimea câmpului: 16 biţi
Acesta este un câmp care identifică procesul sau serviciul în cardul calculatorului gazdă
receptor.
Câmpurile Source Port şi Destination Port sunt sub controlul calculatoarelor gazdă. Fiecare
host poate să decidă pentru sine cum să aloce porturile.

Sequence Number (Număr în cadrul secvenţei)

Abreviere: SEQ
Lungimea câmpului: 32 biţi
Unitate: octeţi

26
 Gamă: 0232-1
Această valoare reprezintă poziţia în cadrul secvenţei de octeţi a primului octet al unui
segment. Totuşi, dacă este prezent un SYN, atunci valoarea acestui câmp reprezintă prima poziţie în
cadrul secvenţei (Initial Sequence Number - ISN) pentru acea conexiune; primul octet de date este
numerotat ISN+1.
Câmpurile Sequence Number şi Acknowledgement au ambele lungimea de 32 biţi,
permiţând astfel specificarea unui spaţiu de secvenţiere foarte mare. (La o rată de transfer al datelor
de 1000 octeţi pe secundă, ar fi necesare aproximativ 50 de zile pentru a fi necesară reluarea
numerotării cu numărul în cadrul secvenţei zero. Dată fiind durata maximă de viaţă a unui pachet -
255 secunde - nu este posibil ca un pachet vechi să aibă acelaşi număr de secvenţă ca şi unul nou şi
să pară că ar fi un pachet duplicat sau să fie recepţionat în locul unui pachet care nu a fost livrat din
cauza unor erori).

Acknowledgement Number (Număr de confirmare)

Abreviere: ACK
Lungimea câmpului: 32 biţi
Unitate: octeţi
Gamă: 0232-1
Dacă este setat bitul de control ACK, acest câmp conţine valoarea numărului de secvenţă al
următorului octet pe care receptorul se aşteaptă să-l primească.

Data Offset (Deplasamentul datelor)

Lungimea câmpului: 4 biţi
Unitate: 32 biţi
Gamă: 515, implicit 5
Acest câmp indică numărul de cuvinte de 32 de biţi conţinute în cadrul headerului TCP.
Folosind această valoare, poate fi calculat deplasamentul datelor în cadrul pachetului. Această
informaţie este necesară datorită lungimii variabile a câmpului Options. Headerul TCP, chiar dacă
include un câmp Options, are o lungime care este un multiplu de 32 biţi.

Reserved (Rezervat)
Lungimea câmpului: 6 biţi
Acest câmp este rezervat pentru extensii ulterioare. Trebuie să aibă toţi biţii zero.

Control Flags (Indicatori de control)

Lungimea câmpului: 6 biţi
Acest câmp conţine un număr de indicatori de câte un bit fiecare, folosiţi pentru stabilirea,
terminarea şi menţinerea unei conexiuni:

- URG - Urgent Pointer. URG=1 indică faptul că este folosit câmpul Urgent Pointer pentru
a localiza date urgente, prin intermediul unui offset exprimat în octeţi faţă de numărul de secvenţă
curent. Acest pointer poate fi necesar în cazul apariţiei unei întreruperi. Dacă indicatorul URG nu
este setat, atunci câmpul Urgent Pointer trebuie ignorat.
- SYN - Este folosit pentru a stabili o conexiune. SYN=1 semnifică cererea de stabilire a
unei conexiuni.
- ACK – Indică faptul că are semnificaţie câmpul Acknowlwdgement.
- RST - Poate reseta o conexiune în cazul apariţiei unor pachete întârziate cu bitul SYN setat,
în cazul căderii calculatorului gazdă sau în alte cazuri. RST=1 înseamnă că trebuie resetată
conexiunea.
- PSH - PSH=1 transmite TCP-ului receptor să transmită imediat datele din cadrul
segmentului către ULP receptor. Acest bit poate fi folosit pentru a indica faptul că nu vor apărea
date de la ULP sursă imediat.

27
 - FIN - Este folosit pentru a termina o conexiune. FIN=1 înseamnă că sursa nu va mai
transmite date către ULP receptor.

Window (Fereastră)
Abreviere: WNDW
Lungimea câmpului: 16 biţi
Unitate: octeţi
Gamă: 0216-1
Această valoare reprezintă numărul octeţilor de date, începând cu cel indicat în cadrul
câmpului Acknowledgement, pe care hostul sursă este dispus sâ îi accepte.
Window este parametrul care permite controlul fluxului în cadrul TCP.
Window este un câmp relativ lung deoarece numără octeţii care vor putea fi recepţionaţi
după octetul confirmat, în loc să numere pachetele care ar putea fi trimise (cum se face în cazul
SPP-XNS).

Checksum (Sumă de control)

Lungimea câmpului: 16 biţi
Acest câmp se aplică tuturor cuvintelor de 16 biţi din cadrul headerului şi datelor. El de
asemenea acoperă un pseudo-header de 96 biţi care conceptual precede headerul TCP. Acest
pseudoheader conţine adresa sursei, adresa destinaţiei, identificatorul de protocol şi lungimea
segmentului TCP.
Checksum conţine complementul faţă de 1 al sumei complementelor faţă de 1 ale tuturor
cuvintelor de 16 biţi din header şi din cadrul câmpului de date.

Urgent Pointer (Pointer urgent)

Abreviere: URGPTR
Lungimea câmpului: 16 biţi
Unitate: octeţi
Gamă: 0216-1
Acest câmp specifică ultimul octet de date urgente.
Valoarea câmpului este un deplasament pozitiv faţă de numărul de secvenţă în cadrul
segmentului. Adunând URGPTR la SEQ se poate afla numărul din cadrul secvenţei al ultimului
octet de date urgent. Acest câmp are semnificaţie doar dacă este setat bitul de control URG.

Options (Opţiuni)
Abreviere: OPT
Lungimea câmpului: variabilă
Dacă este prezent, acest câmp ocupă spaţiu la sfârşitul headerului TCP. Toate opţiunile sunt
incluse în Checksum. Orice opţiune ocupă un număr întreg de octeţi.
Options este rezervat pentru diferite lucruri. Singura opţiune oficială interesantă definită
până în prezent comunică lungimea maximă a unui segment şi este trimisă în timpul stabilirii
conexiunii.

3.3.3 Gestionarea conexiunilor

Principala funcţiune a TCP este să ofere conexiuni de date (canale de comunicaţie) între
perechi de ULP-uri. Gestionarea conexiunilor poate fi împărţită în trei faze: stabilirea conexiunii,
menţinerea conexiunii şi terminarea conexiunii.
Conexiunile sunt dotate cu câteva proprietăţi care se aplică pe toată perioada existenţei
conexiunii, incluzând nivelele de precedenţă şi de securitate. Aceste proprietăţi sunt specificate de
către ULP la deschiderea conexiunii. TCP oferă mijloacele necesare pentru ca ULP să poată intra în
conexiune cu alte ULP în mod unic adresate printr-un nume de soclu (socket). Un socket este de

28
fapt concatenarea unei adrese de IP (care se găseşte în headerul IP) cu numărul de port al aplicaţiei
(din headerul TCP). O conexiune este definită ca o cobinaţie a numerelor de socket ale celor doi
participanţi la conexiune.
TCP stabileşte în mod activ o conexiune pentru un ULP dacă:
- nu există deja o conexiune între cele două socluri;
- există suficiente resurse interne TCP disponibile;
- celălalt ULP (pereche) a executat simultan o deschidere activă de conexiune potrivită sau a
executat anterior o deschidere de conexiune globală, nespecificată (deschidere pasivă). O deschidere
activă se mai numeşte uneori chemare, iar o deschidere pasivă se mai numeşte ascultare.

TCP oferă mijloace pentru ULP să asculte pasiv şi să răspundă la chemări din partea unor
ULP corespunzătoare. Un ULP poate fi interesat de chemări din partea unui anumit corespondent
sau din partea oricărui corespondent îndepărtat. Deci, un ULP are două posibilităţi de a executa o
deschidere pasivă de conexiune:
- în totalitate specificată - un ULP care execută o chemare este în mod unic determinat de
către un soclu. O conexiune va fi acceptată doar dacă se constată apariţia unei chemări din partea
unui soclu îndepărtat specific;
- nespecificată - nu este specificat nici un soclu din partea căruia să fie acceptată o cerere de
deschidere activă a unei conexiuni. Se va stabili o conexiune cu orice ULP îndepărtat care execută o
operaţie de deschidere activă potrivită care identifică acest ULP.

Odată ce s-a stabilit o conexiune, TCP o va menţine cât timp ambele părţi rămân interesate
să o menţină activă. Conexiunile care sunt stabilite dar nu generează în mod activ date care să fie
schimbate între cele două ULP, nu generează nici un pachet. Aceasta nu este o problemă, dar este
interesant faptul că TCP nu oferă un mecanism care să detecteze pierderea unui partener de
conexiune atunci când nu se schimbă date între parteneri. Dar, deoarece pentru unele aplicaţii o
asemenea informaţie este de folos, unele implementări TCP folosesc un truc pentru a realiza această
detecţie: se trimit datagrame care nu conţin date şi cu număr de secvenţă incorect. TCP specifică
faptul că recipientul trebuie să răspundă cu o datagramă conţinând numărul de secvenţă corect.
Dacă nu se recepţionează nici un răspuns, TCP care verifică existanţa conexiunii poate să decidă că
perechea sa a dispărut.
Conexiunile stabilite pot fi terminate în unul dintre următoarele moduri:

1 Graceful Close (închidere cu succes) - Ambele ULP închid partea conexiunii duplex,
simultan sau secvenţial, atunci când transferul de date s-a terminat cu succes. TCP coordonează
terminarea conexiunii şi evită pierderea datelor în tranzit.
2 Abort - Atunci când un ULP forţează unilateral închiderea conexiunii, TCP nu
coordonează această terminare. Datele în tranzit pot să se piardă.

TCP îşi construieşte serviciile pe serviciile potenţial nesigure ale nivelului reţea, cu
mecanisme ca: detecţie de erori, confirmări, numere de secvenţă şi controlul fluxului de date.
Aceste mecanisme cer ca informaţiile de adresare şi de control să fie iniţializate şi menţinute pe
toată durata transferului, aşa cum se va arăta în continuare.

3.3.4 Confirmarea

TCP foloseşte un mecanism numit confirmare pozitivă cu retransmisie (Positive

Acknowledgement with Retransmission - PAR) pentru a recupera erorile provenite din pierderea
datelor la nivelele inferioare. PAR permite protocolului TCP al unui host sursă să retransmită datele
din timp în timp, până când este primită confirmarea pozitivă. Pentru a evita retransmisiile care nu
sunt necesare şi întârzierile excesive de retransmisie, TCP ajustează dinamic valoarea timeoutului
pentru a estima timpul pe care îl necesită trimiterea pachetului, primirea confirmării şi procesările

29
interne în cadrul modulelor TCP pereche. O sumă de control simplă detectează segmentele
deteriorate în tranzit şi ele sunt aruncate fără confirmare. Deci, PAR tratează segmentele cu erori ca
pe nişte segmente pierdute şi compensează pierderea lor.
Marea varietate de reţele suportate de TCP (Ethernet, reţele prin satelit, reţele întinse
terestre) diferă în mare măsură din punct de vedere al ratei de transfer al datelor, întârzieri etc. TCP
specifică tehnici adaptive pentru tratarea întârzierilor astfel încât să nu se retransmită un pachet prea
des sau prea rar. TCP specifică un algoritm de generare exponenţială a întârzierilor, similar celui din
cazul Ethernet.
Numerele de secvenţă folosite de TCP extind mecanismul PAR prin faptul că se permite ca
o singură confirmare să acopere toate datele recepţionate anterior. Astfel, un TCP sursă poate să
transmită date noi în intervalul de timp în care aşteaptă confirmarea primirii datelor vechi.
Confirmarea se referă la toate datele anterioare, nu numai la un segment de date recent. Astfel,
receptoarele pot să ia decizia de a nu trimite confirmări în cazul primirii fiecărui pachet, ci doar din
când în când (pentru mai multe pachete odată).

3.3.5 Controlul fluxului de date

Mecanismul de control al fluxului de date implementat de TCP permite unui TCP destinaţie
să controleze datele expediate de un TCP sursă. Mecanismul este bazat pe implementarea unei
ferestre care defineşte o gamă continuă de numere de secvenţă acceptabile. Pe măsură ce noi date
sunt acceptate, TCP mută fereastra în sus în spaţiul numerelor de secvenţă. Fereastra este specificată
în cadrul fiecărui segment şi permite TCP să menţină informaţii actuale.
Există un mecanism recomandat pentru a nu permite apariţia "sindromului de ferestre
prostuţe" (Silly Window Syndrome), sindrom care ar putea să ducă la supraîncărcarea modululelor
TCP şi chiar la epuizarea resurselor lor. Acest sindrom este rezultatul trimiterii cu o rată prea mare a
unor informaţii privind modificările ferestrelor, fapt care poate duce la transmiterea de către TCP
sursă de multe datagrame de dimensiuni mici în locul câtorva mai mari.

3.3.6 Multiplexarea

Mecanismul de multiplexare al TCP permite asigurarea de servicii de către un singur TCP

pentru mai multe ULP şi mai multe procese din cadrul aceluiaşi host. De asemenea, este permis mai
multor procese din cadrul aceluiaşi ULP să folosească TCP simultan. Mecanismul asignează
identificatori, numiţi porturi, fiecărui proces care cere servicii TCP. O conexiune TCP este legată în
mod univoc de un soclu (concatenarea numărului portului cu adresa IP). Conexiunea este
determinată în mod unic de o pereche de socluri (sursă şi destinaţie).
Această schemă de identificare permite unui singur ULP să aibă conexiuni TCP cu mai
multe ULP îndepărtate. De asemenea este permis ca un set de procese să aibă conexiuni multiple
(orice pereche de procese poate avea o conexiune TCP). Acele ULP care permit conexiuni pentru
resurse populare sunt asignate permanent, fiind numite porturi bine-cunoscute.

3.3.7 Sincronizarea

Două ULP care doresc să comunice, dau instrucţiuni TCP-urilor respective să iniţieze şi să
sincronizeze informaţiile cerute pentru stabilirea unui circuit virtual. Deoarece nivelele inferioare,
nedemne de încredere, pot să livreze date provenind din conexiuni mai vechi, stabilirea conexiunii
se realizează pe baza unui mecanism handshaking bazat pe numere de secvenţă care au la bază
timpul curent. Acest mecanism reduce posibilitatea ca primirea de pachete întârziate să pară pachete
valide în cadrul conexiunii curente. Folosind un mecanism handshaking foarte simplu, cele două
TCP se sincronizează în trei paşi (figura 12).

30
 Figura 12. Handshaking în trei paşi

3.3.8 Rendezvous

Un ULP are două posibilităţi pentru a deschide o conexiune în două moduri: activ sau pasiv.
O conexiune se deschide activ atunci când un ULP dă instrucţiuni TCP să iniţieze un protocol
handshaking pentru a se conecta la un alt ULP.
Pentru a se realiza o conexiune pasivă, se indică TCP să aştepte o tentativă de deschidere a
unei conexiuni din partea unui alt TCP. Această facilitate este utilă pentru aplicaţiile orientate pe
servere. Un program de gestiune de la distanţă a unei baze de date, de exemplu, poate să aştepte
pasiv deschiderea unei conexiuni de către utilizatori aflaţi la staţii în reţea. Mecanismul handhske în
trei paşi de asemenea coordonează activităţile necesare în cazul apariţiei unor tentative de
deschidere activă a unei conexiuni între două TCP pereche.

3.3.9 Indicatorul PUSH

Folosirea indicatorului PUSH este o altă parte a funcţiei de segmentare. TCP grupează în
mod normal datele pentru transmisie într-o manieră transparentă, după bunul său plac. Totuşi,
folosind un push, un ULP poate să indice TCP să trimită datele primite fără a aştepta să mai
primească şi alte date pentru transmisie. De exemplu, un ULP care deserveşte terminale la distanţă,
poate să dorească să trimită datele către terminale câte o linie odată.
În acest scop, sunt necesare două mecanisme. Întâi, ULP sursă trebuie să aibă implementat
un mecanism specific implementării pentru a indica TCP-ului local să transmită datele, iar apoi TCP
sursă trebuie să fie capabil să indice TCP receptor să livreze datele. Indicatorul PUSH este folosit
pentru acest al doilea scop.

3.4 User Datagram Protocol (UDP)

UDP oferă servicii de transport de încărcare redusă pentru a permite ULP să transfere
datagrame între ele. Ca şi TCP, UDP foloseşte câmpuri port pentru a specifica procesul sursă şi
destinaţie al fiecărei tranzacţii. Se poate folosi, opţional, şi o sumă de control.

31
3.4.1 Numerele porturilor

TCP şi UDP folosesc ambele numere de porturi, pentru a distinge participanţii la diferite
schimburi de date. Deoarece identificatorul de protocol (câmpul de 16 biţi PROT din cadrul
headerului IP) este evaluat înaintea valorii numărului de port, TCP şi UDP folosesc valori
independente de câte 16 biţi pentru a identifica porturile. Deci, acelaşi număr de port poate
identifica două porturi diferite: unul pentru TCP şi altul pentru UDP.
Mai mult, selecţia numerelor de porturi este restricţionată. Valorile între 0 şi 255 sunt
rezervate pentru asignare de către DoD; aceste 256 porturi sunt cunoscute sub numele de Well-
Known Ports (porturi bine-cunoscute). Un subset al acestor porturi este prezentat în tabelul 8.
Orice program care foloseşte un Well-Known Port trebuie să se conformeze protocolului
specificat de la nivelele superioare. Trebuie notat că se încearcă să se coordoneze asignarea acestor
porturi bine cunoscute între TCP şi UDP.

Numărul Abreviere Descriere

portului

7 Echo Echo
9 Discard Discard
13 Daytime Daytime
15 Netstat Who is up?
17 Quote Quote of the day
20 FTP-Data File Transfer (Default Data)
21 FTP File Transfer (Control)
23 Telnet Telnet
25 SMTP Simple Mail Transfer Protocol
37 Time Time of Day
39 RLP Resource Location Protocol
42 Nameserver Host Name Server
46 MPM-Snd MPM (Default send)
53 Domain Domain Name Server
67 BootPS Bootstrap Protocol Server
68 BootPC Bootstrap Protocol Client
69 TFTP Trivial File Transfer
79 Finger Who is on System
101 Hostname NIC Host Name Server
102 ISO-TSAP ISO-TSAP
103 X400 X400
104 X400-SND X400-SND

32
 105 CSNET-NS CSNet Name Server
109 POP-2 Post Office Protocol, Version 2
113 AUTH Authentication Server
115 SFTP Simple File Transfer Protocol
119 NNTGP Network News Trans. Protocol
123 NTP Network Time Protocol
129 PWDGEN Password Generator Protocol

Tabelul 8. Numere de porturi asignate în headerele TCP şi UDP

Multe sisteme de operare includ aceste numere de porturi într-un set de porturi protejate. Ele
pot să fie accesate doar de procese care au privilegii speciale, la nivel de sistem de operare.
Numerele de porturi rămase, numite numere de porturi efemere (Ephemeral Port Numbers), pot să
fie folosite de orice proces.

33