REȚELE DE COMPUTERE

MODULUL 2: STRATUL DE TRANSPORT

2.1 Introducere ș i servicii de nivel de transport

2.1.1 Relaț ia între straturile de transport ș i reț ea
2.1.2 Prezentarea stratului de transport în Internet
2.2 Multiplexare ș i Demultiplexare
2.2.1 Endpoint Identification
2.2.2 Multiplexare ș i demultiplexare fără conexiune
2.2.3 Multiplexare ș i Demultiplexare Orientată pe Conexiune
2.2.4 Servere Web ș i TCP
2.3 Transport fără conexiune: UDP
2.3.1 Structura segmentului UDP
2.3.2 Verificarea checksum-ului UDP

2.4 Principiile transferului de date fiabil

2.4.1 Construirea unui Protocol de Transfer de Date Fiabil
[Link] Transfer de date fiabil peste un canal perfect fiabil: rdt1.0
[Link] Transfer de date fiabile peste un canal cu erori de bit: rdt2.0
[Link].1 Expeditorul gestionează ACK/NAK-uri distorsionate: rdt2.1
[Link].2 Expeditorul foloseș te ACK/NAK-uri: rdt2.2
[Link] Transfer de date fiabile pe un canal cu pierderi ș i erori de biț i: rdt3.0
2.4.2 Protocoale de transfer de date fiabile cu pipeline
2.4.3 Mergi-Înapoi-N (GBN)
[Link] Trimitător GBN
[Link] Receiever GBN
[Link] Funcț ionarea protocolului GBN
2.4.4 Repetare Selectivă (SR)
[Link] SR Expeditor
[Link] Recepț ioner SR
2.4.5 Rezumat al mecanismelor de transfer de date fiabile ș i utilizarea acestora
2.5 Transport orientat pe conexiune: TCP
2.5.1 Conexiunea TCP
2.5.2 Structura Segmentului TCP
[Link] Numere de secvenț ă ș i numere de confirmare
[Link] Telnet: Un studiu de caz pentru numerele de secvenț ă ș i confirmare
2.5.3 Estimarea timpului de întoarcere ș i expirare
[Link] Estimarea Timpului de Răspuns
[Link] Stabilirea ș i gestionarea intervalului de timp pentru retransmiterea pachetului
2.5.4 Transfer de date fiabile

[Link].1 Primul Scenariu

[Link].2 Al Doilea Scenariul
[Link].3 Al Treilea Scenariu
[Link] Retransmisie Rapidă
2.5.5 Controlul Fluxului
2.5.6 Managementul conexiunii TCP
[Link] Configurarea conexiunii ș i transferul de date
[Link] Eliberarea conexiunii
2.6 Principiile controlului congestiei
2.6.1 Cauzele ș i Costurile Congestiei
[Link] Scenariul 1: Două Expeditori, un Router cu Buffere Infinte
[Link] Scenariul 2: Două Surse ș i un Router cu Buffere Finite
[Link] Scenariul 3: Patru Emitători, Rute cu Bufferi Finiti ș i Trasee Multisăritură

„Cea mai mare înș elăciune de care suferă oamenii este din cauza propriilor lor opinii.” —Leonardo da Vinci

2-1
REȚELE DE CALCULATOARE
2.6.2 Abordări pentru controlul congestiei
2.6.3 Exemplu de Control al Congestiunii Asistat de Reț ea: Controlul Congestiunii ATM ABR
[Link] Trei metode de a indica congestionarea
2.7 Controlul congestiei TCP
2.7.1 Controlul congestiei TCP
[Link] Start Lent
[Link] Evitarea Congestiei
[Link] Recuperare Rapidă
[Link] Controlul congestiei TCP: Retrospectivă
2.7.2 Echitate
[Link] Dreptate ș i UDP
[Link] Echitate ș i Conexiuni TCP Paralele

„Dacă cauț i răzbunare, începe prin a sapa două morminte.” —Proverb chinezesc antic

2-2
REȚELE DE CALCULATOARE

MODULUL 2: STRATUL DE TRANSPORT

2.1 Introducere ș i Servicii de Nivel de Transport

• Un protocol de nivel de transport oferă comunicare logică între procesele aplica ț iei care rulează pe
gazde diferite.
Programele de protocol de nivel de transport sunt implementate în sistemele finale, dar nu în routerele de reț ea.
•Pe expeditor, stratul de transport
→primește mesaje de la un proces aplicație
→transformă mesajele în segmente și
→trimite segmentul la stratul de rețea.
•Pe receptor, stratul de transport
→ primește segmentul de la stratul de rețea
→transformă segmentele în mesaje și
→ transmite mesajele către procesul aplicației.
Internetul are 2 protocoale la nivelul transportului: TCP ș i UDP

2.1.1 Relaț ia dintre straturile de transport ș i reț ea

•Un protocol de nivel de transport oferă comunicare logică între procesele care rulează pe gazde diferite.
Întrucât, un protocol de nivel de reț ea oferă comunicaț ie logică între gazde.
Protocolele de transport sunt implementate în sistemele finale, dar nu în routerele de reț ea.
•În cadrul unui sistem final, un protocol de transport
→mută mesajele de la procesele aplicației la stratul de rețea și invers.
→dar nu spune nimic despre modul în care mesajele sunt mutate în interiorul nucleului rețelei.
Routers nu recunosc nicio informaț ie care este adăugată mesajelor de către nivelul de transport.

2.1.2 Prezentare generală a straturilor de transport în Internet

Când proiectăm o aplicaț ie de reț ea, trebuie să alegem fie TCP, fie UDP ca protocol de transport.
1) UDP (Protocolul Datagramă Utilizator)
UDP oferă un serviciu fără conexiune aplicaț iei care îl invocă.
UDP oferă următoarele 2 servicii:
i) Livrarea datelor de la proces la proces ș i
ii) Verificarea erorilor.
UDP este un serviciu nesigur, adică nu garantează că datele vor ajunge la procesul de destinaț ie.
2) TCP (Protocolul de Control al Transmisiunii)
TCP oferă un serviciu orientat pe conexiune aplicaț iei invocate.
TCP oferă următoarele 3 servicii:
1) Transfer de date fiabile adică garantează că datele vor ajunge la destinaț ie ș i vor fi procesate corect.
Controlul congestionării ș i

„Nu am întâlnit niciodată un om atât de ignorant încât să nu pot învăț a ceva de la el.” —Galileo Galilei

2-3
REȚELE DE COMPUTERE
2.2 Multiplexare ș i Demultiplexare
Un proces poate avea unul sau mai multe socket-uri.
Soclalile sunt folosite pentru a transmite date de la reț ea la proces ș i viceversa.
1) Multiplexare
La expeditor, stratul de transport
→cumpără bucăți de date de la gazda sursă din diferite prize
→învelește un chunk de date cu un header pentru a crea segmente și
→transmite segmentele către stratul de rețea.
Sarcina de a combina bucăț ile de date din diferite socluri pentru a crea un segment se numeș te
multiplexare.
Demultiplexare
La receptor, stratul de transport
→examinează câmpurile din segmente pentru a identifica socket-ul de primire și
→direcționează segmentul către priza de recepție.
Sarcina de a livra datele dintr-un segment la socketul corect se numeș te demultiplexare.
• În Figura 2.1,
În hostul din mijloc, stratul de transport trebuie să demultiplexeze segmentele care sosesc din reț ea.
nivel pentru a procesa fie P1, fie P2.
The arriving segment’s data is directed to the corresponding process’ssocket.

Figura 2.1: Multiplexarea ș i demultiplexarea la nivelul transportului

„Numai prostii ș i morț ii nu îș i schimbă niciodată opiniile.” — James R. Lowell

2-4
REȚELE DE CALCULATOARE
2.2.1 Identificarea punctului final
Fiecare priză trebuie să aibă un identificator unic.
Fiecare segment trebuie să includă 2 câmpuri de antet pentru a identifica priza (Figura 2.2):
1) Câmpul numărului port sursă ș i
2) Câmpul numărului portului de destinaț ie.
Fiecare număr de port este un număr de 16 biț i: 0 la 65535.
Numerele de port care variază de la 0 la 1023 se numesc numere de port cunoscute ș i sunt restricț ionate.
De exemplu: HTTP foloseș te portul numărul 80
FTP foloseș te portul numărul 21

•Când dezvoltăm o nouă aplicaț ie, trebuie să atribuim aplicaț iei un număr de port, care este cunoscut
ca porturi efemere (49152–65535).

Figura 2.2: Câmpurile de număr de port sursă ș i destinaț ie într-un segment de transport

•Cum implementează stratul de transport serviciul de demultiplexare?

• Răspuns:
Fiecare priza din gazdă va fi atribuit un număr de port.
Când un segment ajunge la gazdă, stratul de transport
→examinează punctul de destinație-port în segment
→direcționează segmentul către socketul corespunzător și
→pasează apoi segmentul procesului atașat.

Când nu poț i schimba direcț ia vântului - ajustează-ț i pânzele.

2-5
REȚELE DE CALCULATORI
2.2.2 Multiplexare ș i demultiplexare fără conexiune
La partea client a aplicaț iei, stratul de transport atribuie automat numărul de port.
În timp ce, pe partea serverului, aplicaț ia atribuie un număr de port specific.
•Să presupunem că procesul de pe Host-A (portul 19157) doreș te să trimită date către procesul de pe Host-B (portul 46428).

Figura 2.3: Inversarea numerelor de port sursă ș i destinaț ie

•La expeditorul A, stratul de transport

→crează un segment care conține portul sursă 19157, portul destinație 46428 și datele
→transmite apoi segmentul rezultat către stratul de rețea.
•La receptorul B, stratul de transport
→examinează câmpul portului de destinație din segment și
→livrează segmentul către mufa identificată prin portul 46428.
•Un socket UDP este identificat printr-un tuplu de două elemente:

1) Adresa IP de destinaț ie &

2) Numărul-port-destinaț ie
•Aș a cum este ilustrat în Figura 2.3,
Numărul portului sursă de la Host-A este folosit la Host-B ca "adresă de întoarcere", adică atunci când B doreș te să trimită un
segmentaț i înapoi la A.

„Deș i lumea este plină de suferinț ă, ea este de asemenea plină de depăș irea acesteia.” —Helen Keller

2-6
REȚELE DE CALCULATOARE
2.2.3 Multiplexare ș i demultiplexare orientată pe conexiune
Fiecare conexiune TCP are exact 2 puncte finale. (Figura 2.4).
Astfel, 2 segmente TCP sosite cu numere de port sursă diferite vor fi direcț ionate către 2 socket-uri diferite.
chiar dacă au acelaș i număr de port de destinaț ie.
•Un socket TCP este identificat printr-un cvadruplu:
1) Adresa IP sursă
2) Numărul portului sursă
Adresa IP de destinaț ie &
4) Număr-port-destinaț ie

Figura 2.4: Inversarea numerelor de port pentru sursă ș i destinaț ie

Serverul-gazdă poate susț ine multe socket-uri de conexiune simultane.

Fiecare priză va fi
→ atașat la un proces.
→identificat prin propriul său cvadruplu.
•Când un segment ajunge la gazdă, toate cele 4 câmpuri sunt folosite pentru a direcț iona segmentul către destinaț ia corespunzătoare
socat. (adică. Demultiplexare).

„Dificultăț ile sunt lucruri care arată unei persoane cine este.” —Epictet

2-7
REȚELE DE CALCULATOARE
2.2.4 Servere Web ș i TCP
•Consideraț i un host care rulează un server Web (ex: Apache) pe portul 80.
Când clienț ii (ex: browsere) trimit segmente către server, toate segmentele vor avea portul de destinaț ie 80.
•Serverul distinge segmentele de la diferiț ii clienț i folosind un tuplu de două valori:
1) Adrese IP sursă &
2) Numărul portului sursă.
•Figura 2.5 arată un server web care creează un nou proces pentru fiecare conexiune.
•Serverul poate folosi fie i) HTTP persistent, fie ii) HTTP nepermanent.
i) HTTP persistent
Pe parcursul duratei conexiunii persistente, clientul ș i serverul schimbă HTTP
mesaje prin aceeaș i socket de server.
ii) HTTP non-persistent
O nouă conexiune TCP este creată ș i închisă pentru fiecare cerere/răspuns.
Astfel, un nou socket este creat ș i închis pentru fiecare cerere/răspuns.
Acest lucru poate afecta grav performanț a unui server Web aglomerat.

Figura 2.5: Doi clienț i, folosind acelaș i număr de port destinaț ie (80) pentru a comunica cu aceeaș i reț ea Web
aplicaț ie server

„Niciodată să nu subestimezi puterea pasiunii.” —Eve Swayer

2-8
REȚELE DE CALCULATOARE
2.3 Transport fără conexiune: UDP
•UDP este un protocol nesigur, fără conexiune.
Serviciul nesigur înseamnă că UDP nu garantează că datele vor ajunge la procesul destinaț ie.
Fără conexiune înseamnă că nu există un handshake între expeditor ș i receptor înainte de a trimite date.
•Oferă următoarele 2 servicii:
i) Livrarea datelor de la proces la proces ș i
ii) Verificarea erorilor.
Nu oferă controlul fluxului, erorilor sau congestionării.
•La expeditor, UDP
→preia mesaje din procesul de aplicație
→atașează numerele porturilor sursă și destinație și
→trimite segmentul rezultat la nivelul rețelei.
•La receptor, UDP
→examinează numărul portului destinație în segment și
→livrează segmentul către procesul corect de aplicare.
Este potrivit pentru aplicaț ii care
→trebuie să trimită mesaje scurte &
nu își permite retransmisia.
•UDP este potrivit pentru multe aplicaț ii din următoarele motive:
1) Control mai fin la nivel de aplicaț ie asupra datelor care sunt trimise ș i când.
Când un proces de aplicaț ie trimite date către UDP, UDP
→împachetează datele într-un segment și
→trece imediat segmentul la nivelul de rețea.
Pe de altă parte,
În TCP, un mecanism de control al congestiei reduce viteza de transmisie a expeditorului atunci când reț eaua este congestionaă

2) Nicio stabilire a conexiunii.

TCP foloseș te un proces de stabilire a conexiunii în trei paș i înainte de a începe transferul de date.
UDP transmite imediat datele fără niciun preliminar formal.
Astfel, UDP nu introduce nici o întârziere pentru a stabili o conexiune.
De aceea, DNS funcț ionează pe UDP mai degrabă decât pe TCP.
3) Fără stare de conexiune.
TCP menț ine starea de conexiune în sistemele finale.
Această stare de conexiune include
→primește și trimite buffere
→parametrii de control al congestiei și
→parametrii numărului de secvență și al numărului de confirmare.
Pe de altă parte,
În UDP, nu se menț ine niciun stat de conexiune.
4) Supraincarcare mică a antetului pachetului.
Segmentul TCP are 20 de octeț i de suprasarcină a headerului în fiecare segment.
Pe de altă parte, UDP are doar 8 octeț i de suprasarcină.

Tabelul 2.1: Aplicaț ii populare de internet ș i protocoalele de transport subiacente

Aplicaț ie Stratul de aplicaț ie Transport de bază
Protocol Protocol
Poș tă electronică SMTP TCP
Acces la terminalul la distanț ă Telnet TCP
Web HTTP TCP
Transfer de fiș iere FTP TCP
Server de fiș iere la distanț ă NFS În mod tipic UDP
Streaming multimedia în mod obiș nuit exclusiv UDP sau TCP
Telefonie prin Internet de obicei proprietar UDP sau TCP
Gestionarea reț elei SNMP De obicei UDP
Protocol de rutare Odihneș te-te în pace De obicei UDP
Traducerea numelui DNS De obicei UDP

Când nu mai suntem capabili să schimbăm o situaț ie, suntem provocaț i să ne schimbăm pe noi înș ine. -Victor Frankl

2-9
REȚELE DE COMPUTER
2.3.1 Structura Segmentului UDP

Figura 2.6: Structura segmentului UDP

•Segmentul UDP conț ine următoarele câmpuri (Figura 2.6):

1) Datele aplicaț iei: Acest câmp ocupă câmpul de date al segmentului.
2) Numărul portului de destinaț ie: Acest câmp este folosit pentru a livra datele procesului corect care rulează pe
gazda-destinatie. (adică funcț ia de demultiplexare).
3) Lungime: Acest câmp specifică numărul de octeț i din segment (antet plus date).
4) Suma de control: Acest câmp este folosit pentru detectarea erorilor.

2.3.2 Suma de control UDP

•Checksum-ul este folosit pentru detectarea erorilor.
•Checksum-ul este folosit pentru a determina dacă biț ii din segment au fost alteraț i.
Cum să calculezi suma de verificare pe expeditor:
Toate cuvintele de 16 biț i din segment sunt adunate pentru a obț ine o sumă.
2) Apoi, complementul 1 al sumei este obț inut pentru a obț ine un rezultat.
3) În cele din urmă, rezultatul este adăugat în câmpul de checksum din interiorul segmentului.
•Cum să verifici pentru erori pe receptor:
1) Toate cuvintele de 16 biț i din segment (inclusiv suma de control) sunt adunate pentru a obț ine o sumă.
i) Pentru nicio eroare: În sumă, toate bit-urile sunt 1. (Ex: 1111111)
ii) Pentru orice eroare: În sumă, cel puț in unul dintre biț i este un 0. (Ex: 1011111)
Exemplu:
•Pe expeditor:
Să presupunem că avem următoarele trei cuvinte de 16 biț i:
0110011001100000
0101010101010101 →trei cuvinte de 16 biți
1000111100001100
Suma primelor două cuvinte de 16 biț i este:
0110011001100000
0101010101010101
1011101110110101
Adăugarea celui de-al treilea cuvânt la suma de mai sus dă:
1011101110110101 →suma de 1stdouă cuvinte de 16 biț i
1000111100001100 →al treilea cuvânt de 16 biți

0100101011000010 →suma tuturor celor trei cuvinte de 16 biți

Luând complementul faț ă de 1 pentru suma finală:
0100101011000010 →suma tuturor celor trei cuvinte de 16 biți

1011010100111101 →complementul 1 pentru suma finală

Valoarea 1's complement este numită checksum, care este adăugată în interiorul segmentului.
•Pe receptor
Toate cele patru cuvinte de 16 biț i sunt adunate, inclusiv suma de control.
i) Dacă nu sunt introduse erori în pachet, atunci clar suma va fi
1111111111111111.
ii) Dacă unul dintre biț i este 0, atunci au fost introduse erori în pachet.

Trăieș ti doar o dată, dar dacă o faci bine, o dată este suficient.

2-10
REț ELE DE CALCULATOARE
2.4 Principiile transferului de date fiabile
Figura 2.7 ilustrează cadrul protocolului de transfer de date fiabile.

Figura 2.7: Transfer de date fiabil: Model de serviciu ș i implementare a serviciului

•Pe expeditor, rdt_send() va fi apelat atunci când un pachet trebuie trimis pe canal.
•Pe receptor,
i) rdt_rcv() va fi apelată când un pachet trebuie să fie primit pe canal.
ii) deliver_data() va fi apelat când datele trebuie livrate către stratul superior

Dacă iubeș ti viaț a, nu-ț i pierde timpul, pentru că timpul este ceea ce compune viaț a.

2-11
REȚELE DE COMPUTER
2.4.1 Construirea unui protocol de transfer de date fiabil
[Link] Transfer de date fiabil pe un canal complet fiabil: rdt1.0
•Consideraț i transferul de date printr-un canal perfect fiabil.
Aceast protocol îl numim rdt1.0.

Figura 2.8: rdt1.0 - Un protocol pentru un canal complet de încredere

Definiț iile maș inii cu stări finite (FSM) pentru expeditorul ș i receptorul rdt1.0 sunt prezentate în Figura 2.8.
•FSM-urile expeditorului ș i receptorului au doar un singur stat.
În FSM, următoarele notări sunt utilizate:
i) Săgeț ile indică tranziț ia protocolului dintr-o stare în alta.
ii) Evenimentul care cauzează tranziț ia este arătat deasupra liniei orizontale care etichetează tranziț ia.
iii) Acț iunea întreprinsă atunci când evenimentul apare este arătată sub linia orizontală.
săgeata întreruptă indică starea iniț ială.
•On the sender, rdt
→acceptă date de la stratul superior prin evenimentul rdt_send(data)
→creează un pachet care conține datele (prin acțiunea make_pkt(data)) și
→trimite pachetul în canal.
•Pe receptor, rdt
→ primește un pachet de la canalul de bază prin evenimentul rdt_rcv(pachet)
→îndepărtează datele din pachet (prin acțiunea extrage (pachet, date)) și
→transmite datele către stratul superior (prin acțiunea deliver_data(data)).

Scrie pe inima ta că fiecare zi este cea mai bună zi din an.

2-12
REȚELE COMPUTERALE
[Link] Transfer de date fiabile printr-un canal cu erori de bit: rdt2.0
•Consideraț i transferul de date printr-un canal nesigur în care biț ii dintr-un pachet pot fi corupț i.
Numim acest protocol rdt2.0.
•Protocolul de dictare a mesajelor foloseș te atât
→recunoașteri pozitive (ACK) și
→reconștințe negative (NAK).
•Recepț ionerul foloseș te aceste mesaje de control pentru a informa expeditorul despre
→ce a fost primit corect și
→ce a fost primit prin eroare și, prin urmare, necesită retransmisie.
Protocolul de transfer de date fiabile bazate pe retransmisie sunt cunoscute sub numele de protocoale ARQ.
•Trei capabilităț i suplimentare de protocol sunt necesare în protocoalele ARQ:
1) Detectarea erorilor
Este nevoie de un mecanism pentru a permite receptorului să detecteze când au avut loc erori de biț i.
UDP foloseș te câmpul de sumă de control pentru detectarea erorilor.
Tehnicile de corectare a erorilor permit receptorului să detecteze ș i să corecteze erorile de biț i din pachete.
2) Feedback-ul Destinatarului
Deoarece expeditorul ș i receptorul sunt de obicei executaț i pe sisteme finale diferite.
Singura modalitate pentru expeditor de a afla despre starea receptorului este ca receptorul să ofere
feedback explicit pentru expeditor.
De exemplu: ACK ș i NAK
3) Retransmitere
A packet that is received in error at the receiver will beretransmitted by the sender.
•Figura 2.9 arată reprezentarea FSM a rdt2.0.

Figura 2.9: rdt2.0 - Un protocol pentru un canal cu erori de biț i

„Totul este amuzant, atâta timp cât se întâmplă altcuiva.” —Will Rogers

2-13
REȚELE DE CALCULATOARE
Expeditor FSM
•Expeditorul rdt2.0 are 2 stări:
1) Într-un stat, protocolul aș teaptă ca datele să fie transmise de la stratul superior.
2) În altă stare, protocolul aș teaptă un ACK sau un NAK de la receptor.
i) Dacă se primeș te un ACK, protocolul
→știe că pachetul transmis cel mai recent a fost primit corect
→reveni la starea de a aștepta date de la stratul superior.
ii) Dacă se primeș te un NAK, protocolul
→retransmite ultimul pachet și
→așteaptă ca un ACK sau NAK să fie returnat de către receptor.
• Expeditorul nu va trimite date noi până când nu este sigur că destinatarul a primit corect.
pachet curent.
• Din cauza acestui comportament, protocolul rdt2.0 este cunoscut ca protocoale de oprire ș i aș teptare.
FSM de Recepț ie
Receiverul rdt2.0 are un singur stadiu.
La sosirea pachetului, receptorul răspunde cu un ACK sau un NAK, în funcț ie de pachetul primit.
este corupt sau nu.

„Dacă petreceț i prea mult timp gândindu-vă la un lucru, nu îl veț i termina niciodată.” —Bruce Lee

2-14
REȚELE DE CALCULATOARE
[Link].1 Expeditorul gestionează ACK/NAK-uri distorsionate: rdt2.1
• Problemă cu rdt2.0:
If an ACK or NAK is corrupted, the sender cannot know whether the receiver has correctly
a primit datele sau nu.
•Soluț ie: Expeditorul retrimite pachetul de date curent atunci când primeș te un pachet ACK sau NAK distorsionat.
Problemă: Această abordare introduce pachete duplicate în canal.
Soluț ie: Adăugaț i câmpul de număr de secvenț ă la pachetul de date.
Receivatorul trebuie doar să verifice numărul de secvenț ă pentru a determina dacă a fost primit.
pachetul este o retransmisie sau nu.
Pentru un protocol de oprire ș i aș teptare, un număr de secvenț ă de 1 bit va fi suficient.
Un număr de secvenț ă de 1 bit permite receptorului să ș tie dacă expeditorul trimite
→pachet transmis anterior (0) sau
→pachet nou (1).
Numim acest protocol rdt2.1.
• Figura 2.10 ș i 2.11 arată descrierea FSM pentru rdt2.1.

Figura 2.10: expeditor rdt2.1

„Pentru fiecare minut în care rămâi supărat, renunț i la 60 de secunde de liniș te sufletească.” —Ralph Waldo Emerson

2-15
REŢELE DE COMPUTERE

Figura 2.11: receptor rdt2.1

„Când eș ti nervos, numără până la zece înainte să vorbeș ti. Dacă eș ti foarte nervos, numără până la o sută.” —Thomas Jefferson

2-16
COMPUTER NETWORKS
[Link].2 Expeditorul foloseș te ACK/NAK-uri: rdt2.2
Protocolul rdt2.2 utilizează atât confirmări pozitive, cât ș i negative din partea receptorului către expeditor.
i) Când un pachet în afara ordinii este primit, receptorul trimite o confirmare pozitivă (ACK).
ii) Atunci când un pachet corupt este primit, receptorul trimite o recunoaș tere negativă (NAK).
Numim acest protocol rdt2.2. (Figura 2.12 ș i 2.13).

Figura 2.12: rdt2.2expeditor

Figura 2.13: receptor rdt2.2

„Crede că poț i ș i eș ti deja pe jumătate pe drum.” —Theodore Roosevelt

2-17
REȚELE DE COMPUTERE
[Link] Transfer de date fiabile printr-un canal pierdut cu erori de biț i: rdt3.0
•Consideraț i transferul de date peste un canal nesigur în care pot apărea pierderi de pachete.
Numim acest protocol rdt3.0.
• Două probleme trebuie rezolvate de rdt3.0:
1) Cum să detectezi pierderea de pachete?
2) Ce să faci când apare pierderea de pachete?
• Soluț ie:
Expeditorul
trimite un pachet și pornește un temporizator și
→așteaptă ACK de la receptor (ok să continue).
Dacă timerul expiră înainte ca ACK-ul să ajungă, expeditorul retransmite pachetul ș i reporneș te
temporizator.
Expeditorul trebuie să aș tepte cel puț in atât de mult cât
1) O întârziere de retur între expeditor ș i receptor plus
2) Timpul necesar pentru a procesa un pachet la receptor.
Implementarea unui mecanism de retransmisie bazat pe timp necesită un cronometru de numărare inversă.
Timerul trebuie să întrerupă expeditorul după ce a expirat o anumită perioadă de timp.
•Figura 2.14 arată FSM-ul pentru trimitere pentru rdt3.0, un protocol care transferă fiabil date pe un canal
care poate corupe sau pierde pachete;
Figura 2.15 arată cum funcț ionează protocolul fără pachete pierdute sau întârziate ș i cum gestionează pachetele pierdute.
pachete de date.
•Pentru că numerele de secvenț ă alternează între 0 ș i 1, protocolul rdt3.0 este cunoscut sub numele de protocol cu bit alternativ.

Figura 2.14: expeditor rdt3.0

„Viaț a nu este corectă; obiș nuieș te-te cu asta“—Bill Gates

2-18
REȚELE DE CALCULATOARE

Figura 2.15: Funcț ionarea rdt3.0, protocolul cu bit alternativ

“The key to immortality is first living a life worth remembering.” —Bruce Lee

2-19
REȚELE DE COMPUTERE
2.4.2 Protocoale de transfer de date fiabile în pipeline
• Expeditorul este autorizat să trimită mai multe pachete fără a aș tepta confirmările.
• Acest lucru este ilustrat în Figura 2.16 (b).
• Pipelining are următoarele consecinț e:
Gama numerelor de secvenț ă trebuie să fie crescută.
2) Exp editorul ș i receptorul pot fi nevoiț i să stocheze mai mult de un pachet.
•Două abordări de bază pentru recuperarea erorilor în pipeline pot fi identificate:
1) Go-Back-N and 2) Selective repeat.

Figura 2.16: Oprire ș i aș teptare ș i trimitere în pipeline

„Viaț a trebuie trăită ca un joc.” —Platon

2-20
REȚELE DE COMPUTERE
2.4.3 Mergi Înapoi-N (GBN)
Expeditorul are voie să transmită mai multe pachete fără a aș tepta o confirmare.
•Dar, expeditorul este constrâns să aibă cel mult N pachete neconfirmate în pipeline.
Unde N = dimensiunea feroniei care se referă la numărul maxim de pachete neconfirmate în conductă
Protocolul GBN este denumit un protocol cu fereastră glisantă.
•Figura 2.17 arată perspectiva expeditorului asupra intervalului numerelor de secvenț ă.

Figura 2.17: Viziunea expeditorului asupra numerelor de secvenț ă în Go-Back-N

•Figura 2.18 ș i 2.19 oferă o descriere FSM a trimisului ș i a receptorilor unui protocol GBN.

Figura 2.18: Descriere extinsă a FSM-ului pentru expeditorul GBN

Figura 2.19: Descriere extinsă a FSM pentru receptorul GBN

„Încearcă să nu devii un om de succes, ci mai degrabă încearcă să devii un om de valoare.” —Albert Einstein

2-21
REȚELE DE CALCULATOARE
[Link] Trimitător GBN
Expeditorul trebuie să răspundă la 3 tipuri de evenimente:
1) Invocaț ie din cer.
Când rdt_send() este apelat din partea de sus, expeditorul verifică mai întâi dacă fereastra este plină
adică dacă există N pachete restante, neconfirmate.
i) Dacă fereastra nu este plină, expeditorul creează ș i trimite un pachet.
ii) Dacă fereastra este plină, expeditorul returnează pur ș i simplu datele la nivelul superior. Aceasta
este o indicaț ie implicită că fereastra este plină.
2) Primirea unui ACK.
O confirmare pentru un pachet cu numărul de secvenț ă n va fi considerată acumulativă
recunoaș tere.
Toate pachetele cu un număr de secvenț ă de până la n au fost primite corect de receptor.
3) Un Eveniment de Timeout.
A timer will be used to recover from lost data or acknowledgment packets.
i) Dacă apare un timeout, expeditorul retransmite toate pachetele care au fost trimise anterior, dar
care nu au fost încă recunoscute.
ii) Dacă se prime ș te un ACK, dar există în continuare date transmise care nu au fost încă
pachetele recunoscute, temporizatorul este repornit.
iii) Dacă nu există pachete neconfirmate, temporizatorul este oprit.
[Link] Primitor GBN
•Dacă un pachet cu numărul de secvenț ă n este primit corect ș i în ordine, receptorul
→ trimite un ACK pentru pachetul n și
→livrează pachetul către stratul superior.
•În toate celelalte cazuri, receptorul
→scapă pachetul și
→trimite din nou un ACK pentru pachetul cel mai recent recepționat în ordine.

„Judeca-ț i caracterul natural prin ceea ce faci în visele tale.” —Ralph Waldo Emerson

2-22
REȚELE DE CALCULATOARE
[Link] Funcț ionarea Protocolului GBN

Figura 2.20: Go-Back-N în funcț iune

•Figura 2.20 arată funcț ionarea protocoalelor GBN în cazul unei dimensiuni a feronului de patru pachete.
Expeditorul trimite pachetele 0 până la 3.
Expeditorul trebuie apoi să aș tepte ca unul sau mai multe dintre aceste pachete să fie recunoscute înainte de a continua.
•Pe măsură ce fiecare ACK succesiv (de exemplu, ACK0 ș i ACK1) este primit, fereastra se deplasează înainte ș i
expeditorul transmite un nou pachet (pkt4 ș i pkt5, respectiv).
•Pe receptor, pachetul 2 este pierdut ș i astfel pachetele 3, 4 ș i 5 sunt găsite a fi în ordinea greș ită ș i sunt
respins.

„Natura ș i cărț ile aparț in ochilor care le văd.” —Ralph Waldo Emerson

2-23
REȚELE DE COMPUTERE
2.4.4 Repetiț ie Selectivă (SR)
• Problemă cu GBN:
GBN suferă de probleme de performanț ă.
Când dimensiunea feroniei ș i produsul lăț ime întârziere sunt ambele mari, multe pachete pot fi în
conducta.
Astfel, o eroare de pachet unic duce la retransmiterea unui număr mare de pachete.
• Soluț ie: Folosiț i Repeat Selectiv (SR).

Figura 2.21: Vederi ale expeditorului ș i receptorului selective-repeat (SR) ale spaț iului de numere de secvenț ă

•The sender retransmits only those packets that itsuspectswere erroneous.

• Prin urmare, evită retransmisiile inutile. De aici ș i numele „selectiv-repetare”.
•Receivers vor recunoaș te individual pachetele primite corect.
•O dimensiune a feronierului N este utilizată pentru a limita numărul de pachete restante, neconfirmate în tubul de transport.
•Figura 2.21 arată perspectiva expeditorului SR asupra spaț iului numerelor de secvenț ă.

[Link] SR Expeditor
•Acț iunile diverse întreprinse de expeditorul SR sunt următoarele:
1) Date primite de la cei de mai sus.
Când sunt primite date de la sursă, expeditorul verifică următorul număr de secvenț ă disponibil pentru
pachetul.
Dacă numărul secvenț ei se află în fereastra expeditorului;
Apoi, datele sunt pachetizate ș i trimise;
În caz contrar, datele sunt tamponate pentru transmisia ulterioară.
2) Timp de aș teptare.

Fiecare pachet trebuie să aibă propriul său temporizator logic. Acest lucru se datorează faptului că
→doar un singur pachet va fi transmis la expirarea timpului.
3) ACK primit.
Dacă se primeș te un ACK, expeditorul marchează acel pachet ca fiind primit.
Dacă numărul de secvenț ă al pachetului este egal cu send_base, baza feroniei este crescută cu
cel mai mic număr de secvenț ă.
Dacă există pachete netransmise cu numere de secvenț ă care cad în fereastră, acestea
pachet sunt transmise.

„Viaț a este pe jumătate petrecută înainte să ș tim ce este.” —George Herbert

2-24
REȚEALE DE CALCULATOARE

[Link] Recepț ioner SR

•Acț iunile diverse întreprinse de receptorul SR sunt următoarele:
1) Pachetul cu numărul de secvenț ă în [rcv_base, rcv_base+N-1] a fost primit corect.
În acest caz,
→pachetul primit se încadrează în fereastra receptorului și
→pachetul ACK selectiv este returnat expeditorului.
Dacă pachetul nu a fost primit anterior, este stocat în buffer.
Dacă acest pachet are un număr de secvenț ă egal cu rcv_base, atunci acest pachet ș i orice pachet precedent
pachetele tamponate ș i numerotate consecutiv sunt livrate la stratul superior.
Fereastra de recepț ie este apoi mutată înainte cu numărul de pachete livrate către stratul superior.
De exemplu: luaț i în considerare Figura 2.22.
¤ Când un pachet cu un număr de secvenț ă de rcv_base=2 este primit, acesta ș i pachetele 3, 4,
ș i 5 pot fi livrate la stratul superior.
Pachetul cu numărul de secvenț ă în [rcv_base-N, rcv_base-1] este primit corect.
În acest caz, trebuie generat un ACK, chiar dacă acesta este un pachet pe care receptorul l-a
recunoscut anterior.
3) Altfel.
Ignoră pachetul.

Figura 2.22: Funcț ionarea SR

„Totul are frumuseț e, dar nu toț i o văd.” —Confucius

2-25
REȚELE DE COMPUTERE
2.4.5 Rezumat al mecanismelor de transfer de date fiabile ș i utilizarea acestora

Tabelul 2.2: Rezumat al mecanismelor de transfer de date fiabile ș i utilizarea acestora

Mecanism Use, Comments
Sumă de control Utilizat pentru a detecta erorile de bit într-un pachet transmis.
Cronometru A fost utilizat pentru a expira/retransmite un pachet deoarece pachetul (sau ACK-ul său) a fost
pierdut.
Pentru că time-out-urile pot apărea când un pachet este întârziat, dar nu pierdut,
exemplare duplicate ale unui pachet pot fi primite de un receptor.
Numărul de secven ț ă utilizat pentru numerotarea secven ț ială a pachetelor de date care curg de la expeditor la
receiver.
Lacunele în secvenț a numerelor pachetelor primite permit receptorului să
detectaț i un pachet pierdut.
Pachetele cu numere de secven ț ă duplicate permit receptorului să detecteze
copia duplicată a unui pachet.
Recunoaș tere Folosit de receptor pentru a informa expeditorul că un pachet sau un set de pachete a fost
a fost primit corect.
Aprecierea va conț ine de obicei numărul de secvenț ă al pachetului sau
pachetele fiind recunoscute.
Aprecierea poate fi individuală sau cumulativă, în func ț ie de
protocol.
Negativ Folositor de către receptor pentru a informa expeditorul că un pachet nu a fost primit
reconcilere corect.
Acknowledge-urile negative vor purta de obicei numărul de secvenț ă al
pachet care nu a fost primit corect.
Fereastră, pipeline. Expeditorul poate fi restricț ionat să trimită doar pachete cu secvenț ă-
numere care se încadrează într-un interval dat.
Permiț ând transmiterea mai multor pachete care nu au fost încă recunoscute,
utilizarea expeditorului poate fi crescută peste un mod de operare de tip stop-and-wait.

„Între două rele, întotdeauna aleg pe cel pe care nu l-am încercat înainte.” —Mae West

2-26
REȚELE DE CALCULATOARE
2.5 Transport orientat pe conexiune: TCP
•TCP este un protocol de conectare fiabil, orientat pe conexiune.
Orientat pe conexiune înseamnă că o conexiune este stabilită între expeditor ș i destinatar înainte de a trimite
datele.
Un serviciu de încredere înseamnă că TCP garantează că datele vor ajunge la procesul-destina ț ie
corect.
•TCP oferă controlul fluxului, controlul erorilor ș i controlul congestionării.

2.5.1 Conexiunea TCP

• Caracteristicile TCP sunt următoarele:
1) Orientat pe conexiune
TCP este considerat orientat pe conexiune. Acest lucru se datorează faptului că
Cele 2 procese de aplicaț ie trebuie mai întâi să stabilească o conexiune între ele înainte de a
începe comunicarea.
Ambele procese de aplicaț ie vor iniț ializa multe variabile de stare asociate cu conexiunea.
2) Rulează în sistemele finale
TCP funcț ionează doar în sistemele finale, dar nu în routerele intermediare.
Routerele nu menț in niciun variabil de stare asociat cu conexiunea.
3) Serviciu Full Duplex
Conexiunea TCP oferă un serviciu duplex complet.
Ambele procese de aplicaț ie pot transmite ș i primi datele în acelaș i timp.
4) Punct la punct
O conexiune TCP este de tip punct-la-punct, adică doar 2 dispozitive sunt conectate printr-un link dedicat.
Aș adar, multicastarea nu este posibilă.
5) Handshake în trei paș i
Procesul de stabilire a conexiunii este denumit un schimb de mâini în trei părț i. Acest lucru se datorează faptului că
3 segmente sunt trimise între cei doi gazde:
Clientul trimite un prim segment.
ii) Serverul răspunde cu un al doilea segment ș i
În cele din urmă, clientul răspunde din nou cu un al treilea segment conț inând încărcătura (sau datele).
6) Dimensiunea maximă a segmentului (MSS)
MSS limitează cantitatea maximă de date care poate fi plasată într-un segment.
De exemplu: MSS = 1.500 de octeț i pentru Ethernet
7) Buffere de trimitere ș i primire
După cum este prezentat în Figura 2.23, se consideră trimiterea de date de la procesul client la procesul server.
La expeditor
i) Clientul-proces transmite un flux de date prin socket.
ii) Apoi, TCP trimite datele în buffer-ul de trimitere.
fiecare bucata de date este ataș ată cu un header pentru a forma un segment.
iv) Segmentele sunt trimise în reț ea.
La receptor
Datele segmentului sunt plasate în bufferul de recepț ie.
Aplicaț ia citeș te fluxul de date din buffer-ul de primire.

Figura 2.23: Buffere de trimitere ș i primire TCP

„Secretul succesului este să fii pregătit atunci când apare oportunitatea ta.” —Benjamin Disraeli

2-27
REȚELE DE COMPUTERE
2.5.2 Structura Segmentului TCP
• Segmentul constă din câmpuri de antet ș i un câmp de date.
• Thedata-field contains a chunk-of-data.
Când TCP trimite un fiș ier mare, acesta îl împarte în bucăț i de dimensiunea MSS.
• Figura 2.24 arată structura segmentului TCP.

Figura 2.24: Structura segmentului TCP

• Câmpurile segmentului TCP sunt următoarele:

1) Numerele porturilor de sursă ș i destinaț ie
Aceste câmpuri sunt folosite pentru multiplexarea/demultiplexarea datelor din/în aplicaț iile de nivel superior.
2) Numărul de secvenț ă ș i numărul de recunoaș tere
Aceste câmpuri sunt folosite de expeditor ș i destinatari în implementarea unui serviciu de transfer de date fiabil.
3) Header Length
Acest câmp specifică lungimea header-ului TCP.
Steag
Acest câmp conț ine 6 biț i.
i) ACK
¤ Această porț iune indică faptul că valoarea câmpului de recunoaș tere este validă.
ii) RST, SYN ș i FIN
¤ Aceste biț i sunt utilizaț i pentru configurarea ș i desființ area conexiunii.
iii) PSH
¤ Acest bit indică faptul că expeditorul a invocat operaț iunea de push.
iv)URG
¤ Acest bit indică faptul că segmentul conț ine date urgente.
Fereastra de recepț ie
Acest câmp defineș te dimensiunea feronului pentru receptor
Acest câmp este folosit pentru controlul fluxului.
6) Sumă de control
Acest câmp este folosit pentru detectarea erorilor.
7) Punct de Date Urgent
Acest câmp indică locaț ia ultimului octet de date urgente.
8) Opț iuni
Acest domeniu este utilizat atunci când un expeditor ș i un receptor negociază MSS-ul pentru utilizare în reț ele de mare viteză.

Fiecare eș ec este doar un alt pas mai aproape de o victorie. Nu înceta niciodată să încerci.

2-28
REȚELE DE COMPUTERE
[Link] Numere de secvenț ă ș i numere de confirmare
Numere de secvenț ă
• Numărul secvenț ei este folosit pentru numerotarea secvenț ială a pachetelor de date care curg de la expeditor la
recepț ionar.
•Applications:
1) Lacunele din secvenț a numerelor pachetelor primite permit receptorului să detecteze un pachet pierdut.
Pachetele cu numere de secvenț ă duplicat permit receptorului să detecteze copii duplicat ale unui
pachet.
Numere de confirmare
Numărul de confirmare este utilizat de către receptor pentru a îi spune expeditorului că un pachet a fost
primit corect.
Recunoaș terile vor purta de obicei numărul de secvenț ă al pachetului care este recunoscut.

Figura 2.25: Numere de secvenț ă ș i de confirmare pentru o aplicaț ie simplă Telnet peste TCP

• Luaț i în considerare un exemplu (Figura 2.25):

Un proces în Host-A doreș te să trimită un flux de date către un proces în Host-B.
În Host-A, fiecare octet din fluxul de date este numerotat aș a cum se arată în Figura 2.26.

Figura 2.26: Împărț irea datelor fiș ierului în segmente TCP

Primul segment de la A la B are un număr de secvenț ă 42, adică Seq=42.

Segmentul doi de la B la A are un număr de secvenț ă 79 adică Seq=79.
Al doilea segment de la B la A are numărul de recunoaș tere 43, care este secvenț a -
numărul următor de byte, Host-B aș teaptă de la Host-A. (adică ACK=43).
Ce face un gazdă atunci când primeș te biț i în ordine greș ită?
Răspuns: Există două alegeri:
1) Recepț ia elimină imediat octeț ii în ordine greș ită.
2) Destinatarul
→ păstrează octeții în ordinea greșită și
așteaptă ca byte-urile lipsă să umple golurile.

„Nu vei fi pedepsit pentru furia ta; vei fi pedepsit de furia ta.” —Buddha

2-29
REȚELE DE CALCULATOARE
[Link] Telnet: Un studiu de caz pentru numerele de secvenț ă ș i recunoaș tere
Telnet este un protocol popular la nivel de aplicaț ie folosit pentru autentificarea de la distanț ă.

Telnet rulează pe TCP.

Telnet este conceput să funcț ioneze între orice două gazde.
• Aș a cum este arătat în Figura 2.27, să presupunem că clientul iniț iază o sesiune Telnet cu serverul.
• Acum să presupunem că utilizatorul tastează o singură literă, 'C'.
• Trei segmente sunt trimise între client ș i server:
1) Primul segment
Primul segment este trimis de la client la server.
Segmentul conț ine
→litera ‘C’
→sequence-number 42
→acknowledgment-number 79
2) Al doilea segment
Al doilea segment este trimis de la server la client.
Două scopuri ale segmentului:
i) Oferă o confirmare a datelor pe care serverul le-a primit.
ii) Este folosit pentru a reda litera 'C'.
Confirmarea pentru datele client-la-server este transportată într-un segment care transportă server-la-client.
date.
Această recunoaș tere se spune că este suprapusă pe segmentul de date server-client.
3) Al treilea segment
Al treilea segment este trimis de la client la server.
Un scop al segmentului:
i) Recunoaș te datele pe care le-a primit de la server.

Figura 2.27: Numere de secvenț ă ș i de confirmare pentru o aplicaț ie Telnet simplă peste TCP

„Dacă îț i trăieș ti viaț a în trecut, îț i iroseș ti viaț a pe care ai de trăit.” —Jessica Cress

2-30
REȚELE DE COMPUTERE
2.5.3 Estimarea Timpului de Runda ș i Timpul de Aș teptare
• TCP foloseș te un mecanism de timeout/retransmisie pentru a recupera segmentele pierdute.
• În mod clar, timpul de aș teptare ar trebui să fie mai mare decât timpul de răspuns (RTT) al conexiunii.

[Link] Estimarea Timpului de Răspuns

SampleRTT este definit ca
„Cantitatea de timp între momentul în care segmentul este trimis ș i momentul în care se primeș te un mesaj de confirmare.”
În mod evident, valorile SampleRTT vor fluctua de la segment la segment din cauza congestiei.
TCP menț ine o medie a valorilor SampleRTT, care este denumită EstimatedRTT.

•DevRTT este definit ca

O estimare a cât de mult SampleRTT se abate de obicei de la EstimatedRTT.

• Dacă valorile SampleRTT au fluctuaț ii mici, atunci DevRTT va fi mic.

Dacă valorile SampleRTT au fluctuaț ii mari, atunci DevRTT va fi mare.

[Link] Setarea ș i gestionarea intervalului de timeout pentru retransmisie

Ce valoare ar trebui folosită pentru intervalul de timeout?
• În mod clar, intervalul ar trebui să fie mai mare sau egal cu RTT estimat.
Intervalul de timeout este dat de:

Câș tigătorii niciodată nu renunț ă, iar cei care renunț ă niciodată nu câș tigă.

2-31
REȚELE DE COMPUTERE
2.5.4 Transfer de date fiabil
• IP este nesigur, adică IP nu garantează livrarea datelor.
IP nu garantează livrarea în ordine a datelor.
IP nu garantează integritatea datelor.
TCP creează un serviciu de transfer de date fiabil deasupra serviciului nesigur al IP.
• La receptor, serviciul de încredere înseamnă
→fluxul de date nu este corupt
→fluxul de date este fără duplicare și
→fluxul de date este în secvență.

[Link] Câteva scenarii interesante

[Link].1 Primul scenariu
• Aș a cum este arătat în Figura 2.28, Host-A trimite un segment către Host-B.
• Presupuneț i că confirmarea de la B la A se pierde.
• În acest caz, evenimentul de timeout are loc, iar Host-A retransmite acelaș i segment.
Când Host-B primeș te retransmiterea, observă că numărul de secvenț ă a fost deja primit.
Astfel, Host-B va ignora segmentul retransmis.

Figura 2.28: Retransmisie datorată unei confirmări pierdute

„Acț iunea este adevărata măsură a inteligenț ei.” —Napoleon Hill

2-32
REȚELE DE CALCULATOARE
[Link].2 Al doilea scenariu
• Aș a cum este prezentat în Figura 2.29, Host-A trimite două segmente unul după altul.
Host-B trimite două recunoaș teri separate.
• Să presupunem că niciunul dintre confirmări nu ajunge la Host-A înainte de expirarea temporizatorului.
Când apare evenimentul de expirare a timpului, Host-A retrimite primul segment ș i restartează cronometrul.
Al doilea segment nu va fi retransmis până când ACK pentru al doilea segment nu soseș te.
timp de expirare nou.

Figura 2.29: Segmentul 100 nu a fost retransmis

[Link].3 Al treilea scenariu

• Aș a cum este arătat în Figura 2.30, Host-A trimite cele două segmente.
• Confirmarea primului segment este pierdută.
• Dar chiar înainte de evenimentul de timeout, Host-A primeș te o confirmare - nr. 120.
Prin urmare, Host-A ș tie că Host-B a primit toț i byte-ii până la 119.
Aș adar, Host-A nu retransmite niciuna dintre cele două segmente.

Figura 2.30: Un acknowledgments cumulat evită retransmiterea primului segment

„Credinț a este pasărea care simte lumina când zori încă sunt întunecaț i.” —Rabindranath Tagore

2-33
REȚELE DE CALCULATOARE
[Link] Retransmitere rapidă
• Perioada de aș teptare poate fi relativ lungă.
Expeditorul poate adesea să detecteze pierderi de pachete cu mult înainte ca intervine expirarea prin observarea ACK-urilor duplicate.
• Un ACK duplicat se referă la ACK pe care expeditorul îl primeș te a doua oară. (Figura 2.31).

Table 2.3: TCP ACK Generation Recommendation

Eveniment Acț iunea receptor TCP
Sosirea segmentului în ordine cu ACK întârziat a ș teptat.
număr-secuenț ă. Aș teptaț i până la 500 msec pentru sosirea altuia în-
Toate până la numărul de secven ț ă a ș teptat sunt deja segmentul de comandă.
recunoscut. Dacă următorul segment în ordine nu sose ș te în acest
interval, trimite un ACK.
Sosirea segmentului în ordine cu a ș teptat Trimite ț i imediat un ACK cumulativ unic, confirmând
număr-secvenț ă. ambele segmente în ordine.
Un alt segment în ordine a ș teaptă ACK
transmisie.
Sosirea unui segment în afara ordinii cu prioritate mai mare - Trimite ț i imediat un ACK duplicat, indicând
număr de secvenț ă mai mare decât se aș tepta. numărul secvenț ei al următorului byte aș teptat.
Diferenț ă detectată.

Sosirea segmentului care parț ial sau complet trimite imediat ACK.
completează golul din datele primite.

Figura 2.31: Retransmitere rapidă: retransmiterea segmentului lipsă înainte ca timerul segmentului să expire

„Viaț a este cu adevărat simplă, dar insistăm să o complicăm.” —Confucius

2-34
REȚELE DE CALCULATOARE
2.5.5 Controlul fluxului
TCP oferă un serviciu de control al fluxului pentru aplicaț iile sale.
Un serviciu de control al fluxului elimină posibilitatea ca expeditorul să depăș ească buffer-ul receptorului.

Figura 2.32:a)Send buffer and b) Receive Buffer

•Aș a cum este arătat în Figura 2.32, definim următoarele variabile:

1) MaxSendBuffer: Un buffer de trimitere alocat expeditorului.
2) MaxRcvBuffer: Un buffer de primire alocat pentru receptor.
3) UltimulByteTrimis: Numărul ultimelor byte-uri trimise către buffer-ul de trimitere la expeditor.
4) LastByteAcked: The no. of the last bytes acknowledged in the send-buffer at the sender.
5) LastByteRead: The no. of the last bytes read from the receive-buffer at the receiver.
6) LastByteRcvd: The no. of the last bytes arrived & placed in receive-buffer at the receiver.
Trimite buffer-ul
• Expeditorul menț ine un tampon de trimitere, împărț it în 3 segmente, ș i anume
1) Date recunoscute
2) Date neacceptate ș i
3) Date de transmis
• Bufferul de trimitere menț ine 2 indicii: UltimulOctetConfirmat ș i UltimulOctetTrimis. Relaț ia dintre acestea două este:

Receive Buffer
•Recepț ionerul menț ine un buffer de primire pentru a păstra datele chiar dacă acestea sosesc în ordine greș ită.
•Bufferul de recepț ie menț ine 2 indicatoare: UltimulByteCitit ș i UltimulByteRecepț ionat. Relaț ia dintre aceste două este:

Operaț iunea de Control al Fluxului

•Expeditorul previne overflow-ul buffer-ului de trimitere prin menț inerea

•Receptorul evită depăș irea buffer-ului de primire prin menț inerea

Recepț ionerul limitează expeditorul prin promovarea unei feronieră care este mai mică decât cantitatea de spaț iu liber.
că poate bufferiza:

„Nu poț i câș tiga decât dacă înveț i cum să pierzi.” —Kareem Abdul-Jabbar

2-35
REȚELE DE COMPUTERE
2.5.6 Gestionarea conexiunii TCP
[Link] Configurarea conexiunii ș i transferul de date
• Pentru a stabili conexiunea, sunt trimise trei segmente între cele două gazde. Prin urmare, acest proces este
numit un handshake în trei paș i.
• Să presupunem că un proces client doreș te să iniț ieze o conexiune cu un proces server.
•Figura 2.33 ilustrează paș ii implicaț i:
Pasul 1: Clientul trimite un segment de cerere de conexiune către Server
Clientul trimite mai întâi un segment de cerere de conectare serverului.
Segmentul de solicitare a conexiunii conț ine:
Bitul SYN este setat la 1.
2) Numărul de secvenț ă iniț ial (client_isn).
Segmentul SYN este encapsulat într-un datagram IP ș i trimis către server.
Pasul 2: Serverul trimite un segment de conectare aprobat clientului
Apoi, serverul
→extracts the SYN segment from the datagram
→alocă buferele și variabilele pentru conexiune și
→trimite un segment de conexiune acordată clientului.
Segmentul de conexiune acordată conț ine:
Bitul SYN este setat pe 1.
2) Câmpul de recunoaș tere este setat la client_isn+1.
3) Numărul de secvenț ă iniț ial (server_isn).
Pasul 3: Clientul trimite un segment ACK către Server
În cele din urmă, clientul
→alocă buffer-e și variabile pentru conexiune și
→trimite un segment ACK serverului
Segmentul ACK confirmă serverul.
Bitul SYN este setat la zero, deoarece conexiunea este stabilită.

Figura 2.33: Handshake-ul în trei paș i TCP: schimb de segmente

„Autosugestia te face stăpân pe tine însuț i.” —W. Clement Stone

2-36
REȚELE DE CALCULATOARE
[Link] Eliberarea conexiunii
• Oricare dintre cele două procese dintr-o conexiune poate încheia conexiunea.
Când o conexiune se încheie, „resursele” din gazde sunt de-alocate.
• Să presupunem că clientul decide să închidă conexiunea.
•Figure 2.34 illustrates the steps involved:
1) Procesul client emite o comandă de închidere.
Apoi, clientul trimite un segment de închidere către server.
¤ Acest segment are un bit FIN setat pe 1.
2) Serverul răspunde cu o confirmare către client.
3) The server then sends its own shutdown-segment.
¤ Acest segment are un bit FIN setat pe 1.
4) În cele din urmă, clientul recunoaș te segmentul de oprire al serverului.

„Oamenii trebuie să trăiască ș i să creeze. Trăieș te până la punctul de a plânge.” —Albert Camus

2-37
REȚELE DE CALCULATOARE
2.6 Principiile controlului congestionării
2.6.1 Cauzele ș i costurile aglomeraț iei
[Link] Scenariul 1: Două trimiț ători, un router cu bufferi infinț i
• Două gazde (A ș i B) au o conexiune care împarte o legătură pe un singur salt între sursă ș i destinaț ie.
• Acest lucru este ilustrat în Figura 2.35.

Figura 2.35: Scenariul de congestie 1: Două conexiuni care împărtăș esc un salt unic cu buffer-uri infinite

• Să
Rata de trimitere a Host-A = λînbiti/sec
Capacitatea link-ului de ieș ire = R
Pachetele de la gazdele A ș i B trec printr-un router ș i pe un link de ieș ire partajat.
• Routerul are bufere.
Buffers stochează pachetele de date primite atunci când rata de sosire a pachetelor depăș eș te capacitatea linkului de ieș ire.

Figura 2.36: Scenariul de congestionare 1: Debitul ș i întârzierea ca funcț ie a ratei de trimitere a gazdei

•Figura 2.36 ilustrează performanț a conexiunii Host-A.

Graficul din partea stângă

• Graficul din stânga reprezintă throughput-ul pe conexiune ca o funcț ie a ratei de trimitere a conexiunii.
• Pentru o rată de trimitere între 0 ș i R/2, prinputul la receptor este egal cu rata de trimitere a expeditorului.
Cu toate acestea, pentru o rată de trimitere mai mare de R/2, prinputul la receptor este doar R/2. (Figura 2.36a)
• Concluzie: Legătura nu poate livra pachete unui receptor la o rată constantă care să depăș ească R/2.
Graficul Mâinii Drepte
Grafica din dreapta reprezintă întârzierea medie ca o funcț ie a ratei de trimitere a conexiunii (Figura 2.36b).
Pe măsură ce rata de trimitere se apropie de R/2, întârzierea medie devine din ce în ce mai mare.
Cu toate acestea, pentru o rată de trimitere peste R/2, întârzierea medie devine infinită.
• Concluzie: Se experimentează întârzieri mari în coadă pe măsură ce rata de sosire a pachetelor se apropie de capacitatea linkului.

Regula nr. 1: Niciodată nu pierde bani. Regula nr. 2: Niciodată nu uita regula nr. 1.

2-38
REȚELE DE COMPUTERE
[Link] Scenariul 2: Două Trimiteri ș i un Router cu Buffere Finite
• Aici, avem 2 presupuneri (Figura 2.37):
1) Cantitatea de memorie tampon a router-ului este finită.
Pachetele vor fi pierdute atunci când sosesc într-un buffer deja plin.
Fiecare conexiune este fiabilă.
Dacă un pachet este pierdut la router, expeditorul îl va retransmite în cele din urmă.
• Să
Rata de trimitere a aplicaț iei de la Host-A = λînbiti/sec
Rata de trimitere a nivelului de transport a Gazdei-A =λînbiti/sec (numit de asemenea încărcare oferită reț elei)
Capacitatea linkului de ieș ire = R

Figura 2.37: Scenariul 2: Două gazde (cu retransmisiuni) ș i un router cu buffere finite

Cazul 1 (Figura 2.38(a)):

Host-A trimite un pachet doar atunci când un buffer este liber.
• În acest caz,
→nu apare nicio pierdere

→λînva fi egal cu λîn‘, ș i

prin capacitatea de conectare va fi egală cu λîn.
Expeditorul retransmite doar atunci când un pachet este pierdut.
• Consideraț i încărcătura oferită λîn=R/2.
Rata la care datele sunt livrate aplicaț iei receptor este R/3.
•Expeditorul trebuie să efectueze retransmisiuni pentru a compensa pachetele pierdute din cauza depăș irii buffer-ului.

Figura 2.38: Performanț a scenariului 2 cu bufferi fini

Caz 3 (Figura 2.38(c)):

• Expeditorul poate expira ș i retransmite un pachet care a fost întârziat în coadă, dar care nu a fost încă pierdut.
• Atât pachetul de date original, cât ș i retransmisiunea pot ajunge la receptor.
• Recepț ionerul are nevoie de o copie a acestui pachet ș i va arunca retransmisiunea.
• Munca depusă de router în retransmiterea copiei originale a pachetului a fost risipită.

Timpul descoperă adevărul.

2-39
REȚELE DE CALCULATOARE
[Link] Scenariul 3: Patru expeditori, routere cu buffer finite ș i căi multi-hop
• Patru gazde transmit pachete, fiecare pe căi de două salturi care se suprapun.
• Acest lucru este ilustrat în Figura 2.39.

Figura 2.39: Patru expeditori, routere cu buffer-uri finite ș i căi multi-hop

• Consideraț i conexiunea de la Host-A la Host C, trecând prin routerele R1 ș i R2.

Conexiunea A–C
→împărtășește routerul R1 cu conexiunea D–B și
→împărtășește routerul R2 cu conexiunea B–D.
• Caz-1: Pentru valori extrem de mici ale λ
→supraîncărcările de buffer sunt rare (așa cum se întâmplă în scenariile de congestie 1 și 2) și

→debitul este aproximativ egal cu sarcina oferită.

• Caz-2: Pentru valori uș or mai mari ale λîn, prin urmare, prin urmare, debitele corespunzătoare sunt, de asemenea, mai mari. Acest lucru se datorează
→ mai multe date originale sunt transmise în rețea
→datele sunt livrate la destinație și
→supraîncărcările sunt încă rare.
• Caz-3: Valori extrem de mari ale λîn.
Consideraț i routerul R2.

valoareλîn.
unde R = capacitatea legăturii de la R1 la R2.
Dacăλîneste extrem de mare pentru toate conexiunile, atunci rata de sosire a traficului B-D la R2 poate fi
mult mai mare decât cel al traficului A–C.
Traficul A–C ș i B–D trebuie să concureze la routerul R2 pentru cantitatea limitată de spaț iu de tampon.
Astfel, cantitatea de trafic A–C care reu ș eș te să treacă prin R2 devine mai mică ș i
mai mic pe măsură ce sarcina oferită de B–D devine din ce în ce mai mare.
In the limit, as the offered-load approaches infinity, an empty buffer at R2 is immediately
umplut de un pachet B–D, iar lăț imea de bandă a conexiunii A–C la R2 scade la zero.
Când un pachet este pierdut pe un traseu, capacitatea de transmisie ajunge să fi fost
wasted.

Oamenii care trăiesc profund nu au frică de moarte.

2-40
REȚELE DE CALCULATOARE
2.6.2 Abordări pentru controlul congestiei
Abordările de control al congestiei pot fi clasificate în funcț ie de faptul dacă stratul de reț ea oferă vreo
asistenț ă explicită pentru stratul de transport:
Controlul congestiei de la un capăt la altul
Stratul de reț ea nu oferă niciun suport explicit stratului de transport pentru controlul congestionării.
Chiar ș i prezen ț a congestiei trebuie inferată de sistemele finale bazându-se doar pe
comportamentul reț elei observat.
Pierdere segmentului este considerată un indicator al congestionării re ț elei ș i dimensiunea feroniei este ...
a scăzut corespunzător.
2) Controlul congestiei asistat de reț ea
Componentele de nivel de reț ea oferă feedback explicit expeditorului cu privire la congestie.
Această feedback poate fi un singur bit care indică congestionarea la un link.
Informaț iile despre congestie sunt transmise de la reț ea la expeditor în unul dintre cele două moduri:
i) Feedback-ul direct poate fi trimis de la un router de reț ea către expeditor (Figura 2.40).
¤ Această formă de notificare are de obicei forma unui pachet de restricț ie.
ii) Un router marchează un câmp într-un pachet care curge de la expeditor la receptor pentru a indica
congestie.
¤ La primirea unui pachet marcat, receptorul notifică apoi expeditorul despre
indicaț ie de congestie.
¤ Această formă de notificare necesită cel puț in un ciclu complet de timpi de răspuns.

Figura 2.40: Două căi de feedback pentru informaț iile despre congestia indicată de reț ea

Lucruri mari sunt realizate atunci când oamenii se întâlnesc cu munț ii.

2-41
REȚELE DE CALCULATOARE
2.6.3 Exemplu de Control al Congestiei Asistat de Reț ea: Controlul Congestiei ATM ABR
Protocolul ATM (Modul de Transfer Asincron) foloseș te o abordare asistată de reț ea pentru controlul congestionării.
ABR (Rata de Transfer Disponibilă) a fost concepută ca un serviciu elastic de transfer de date.
i) Când reț eaua este subîncărcată, ABR trebuie să profite de lăț imea de bandă disponibilă liberă.
ii) Când reț eaua este congestionată, ABR ar trebui să-ș i reducă rata de transmitere.

Figura 2.41: Cadru de control al congestiei pentru serviciul ABR ATM

•Figura 2.41 arată cadrul pentru controlul congestionării ABR ATM.

Celulele de date sunt transmise de la o sursă la o destinaț ie printr-o serie de comutatoare intermediare.
•Celulele RM sunt plasate între celulele de date. (RM Managementul resurselor).
Celulele TheRM sunt utilizate pentru a trimite informaț ii legate de congestie gazdelor ș i comutatoarelor.
• Când un RM-cell ajunge la o destinaț ie, celula va fi trimisă înapoi expeditorului
• Astfel, celulele RM pot fi folosite pentru a oferi atât
→feedback direct de rețea și
→feedback de rețea prin intermediul receptorului.

[Link] Trei metode de a indica congestionarea

Controlul congestiei ATM ABR este o abordare bazată pe rată.
• ABR oferă 3 mecanisme pentru a indica informaț ii legate de congestie:
1) Bit EFCI
Fiecare celulă de date conț ine un bit EFCI. (EFCI Indicaț ie explicită a congestiei înainte
Un comutator congestionat setează bitul EFCI la 1 pentru a semnala congestia destinaț iei.
The destination must check the EFCI bit in all received data-cells.
Dacă cea mai recent primită celulă de date are bitul EFCI setat la 1, atunci destinaț ia
→setează bitul CI la 1 în celula RM (CI indicaț ie de congestie
→sends the RM-cellback to the sender.
Astfel, un expeditor poate fi notificat despre congestia de la un comutator de reț ea.
2) Bith-urile CI ș i NI
Rata de intercalare a celulelor RM este un parametru reglat.
Nici o creș tere
Valoarea implicită este un RM-cell la fiecare 32 de celule de date.
Celulele RM au un bit CI ș i un bit NI care pot fi setate de un comutator congestionat.

→ setează bitul NI la 1 într-o celulă RM sub congestie ușoară și

→setează bitul CI la 1 în condiții de congestionare severă.
3) Setarea ER
Fiecare celulă RM conț ine de asemenea un câmp ER. (ER rată explicită
Un switch congestionat poate reduce valoarea conț inută în câmpul ER dintr-o celulă RM care trece.
În acest fel, câmpul ER va fi setat la rata minimă suportabilă a tuturor comutatoarelor de pe cale.

„Dacă ai vrea să ș tii valoarea banilor, mergi ș i încearcă să împrumuț i unii.” —Benjamin Franklin

2-42
REȚELE DE CALCULATOARE
2.7 Controlul congestiei TCP
2.7.1 Controlul congestionării TCP
TCP are un mecanism de control al congestiei.
TCP foloseș te controlul congestiei de la capăt la capăt, mai degrabă decât controlul congestiei asistat de reț ea
Iată cum funcț ionează:
Fiecare expeditor limitează rata la care î ș i trimite traficul în conexiunea sa în func ț ie de
congestie percepută.
i) Dacă expeditorul percepe că există puț ină aglomerare, atunci expeditorul îș i creș te rata de date.
ii) Dacă expeditorul percepe că există congestie, atunci expeditorul îș i reduce rata de date.
Această abordare ridică trei întrebări:
1) Cum îș i limitează un expeditor rata la care trimite trafic în conexiunea sa?
2) Cum percepe un expeditor că există congestie pe traseu?
3) Ce algoritm ar trebui să folosească expeditorul pentru a schimba rata de transfer a datelor?

• Expeditorul urmăreș te o variabilă suplimentară numită fereastra de congestie (cwnd).

• Fereastra de congestionare impune o constrângere asupra ratei de date a unui expeditor.
•Cantitatea de date neconfirmate la un expeditor nu va depăș i minimum dintre (cwnd ș i rwnd), adică:

• Rata de transfer a expeditorului este de aproximativ cwnd/RTT octeț i/sec.

•Explicaț ia evenimentului de pierdere:
Un „eveniment de pierdere” la un expeditor este definit ca fiind apariț ia fiecărei
→timeout sau
→primirea a 3 ACK-uri duplicate de la receptor.
Datorită congestionării excesive, bufferul routerului de-a lungul drumului se umple. Acest lucru cauzează o
datagrama să fie dropată.
Datagrama pierdută, la rândul său, rezultă într-un eveniment de pierdere la expeditor.
Expeditorul consideră că evenimentul de pierdere este o indicaț ie a congestiei pe traseu.
Cum este detectată congestia?
Considerăm că reț eaua este liberă de congestie.
Recunoaș terile pentru segmentele anterior neacordate vor fi primite de expeditor.
TCP
→va considera sosirea acestor confirmări ca o indicație că totul este în regulă și
→va folosi recunoașterile pentru a crește dimensiunea ferestrei (& prin urmare rata de date).
TCP este spus că este auto-sincronizat deoarece
→recunoașterile sunt folosite pentru a declanșa creșterea dimensiunii feroniei
Algoritmul de control al congestiei are 3 componente majore:
1) Început lent
2) Evitarea congestionării ș i
3) Recuperare rapidă.

Dacă îi tratezi bine pe oameni, ei te vor trata bine... 90% din timp.

2-43
REȚELE DE CALCULATOARE
[Link] Începere lentă
• Când o conexiune TCP începe, valoarea cwnd este iniț ializată la 1 MSS.
TCP dublează numărul de pachete trimise la fiecare RTT în cazul unei transmisii reuș ite.
• Iată cum funcț ionează:
După cum se arată în Figura 2.42, TCP
→trimite primul segment în rețea și
→așteaptă o confirmare.
Când ajunge o confirmare, expeditorul
→ crește fereastra de congestie cu un MSS și
→trimite 2 segmente.
Când sosesc două confirmări, expeditorul
→îngreunează fereastra de congestie cu un MSS și
→trimite 4 segmente.
Acest proces duce la o dublare a ratei de trimitere la fiecare RTT.
Astfel, rata de date TCP începe lent, dar creș te exponential în timpul fazei de pornire lentă.

Figura 2.42: Începerea lentă TCP

Când ar trebui să se termine creș terea exponenț ială?

O pornire lentă oferă mai multe răspunsuri la această întrebare.
1) Dacă există un eveniment de pierdere, expeditorul
→setează valoarea cwnd la 1 și
→începe din nou procesul lent de pornire. praș tia de început lentă
→ setează valoarea lui ssthresh la cwnd/2.
2)When the value of cwnd equals ssthresh, TCP enters the congestion avoidance state.
3) Când sunt detectate trei ACK-uri duplicate, TCP
→efectuează o retransmisie rapidă și
→intră în starea de recuperare rapidă.
Comportamentul TCP în stadiul de început lent este rezumat în descrierea FSM din Figura 2.43.

Bărbaț ii nu sunt prizonieri ai destinului, ci doar prizonieri ai propriilor minț i.

2-44
REȚELE DE CALCULATOARE

Figura 2.43: Descrierea FSM a controlului de congestie TCP

Succesul este să faci lucruri obiș nuite extraordinar de bine.

2-45
REȚELE DE CALCULATOARE
[Link] Evitarea Congestiei
• La intrarea în starea de evitare a congestionării, valoarea cwnd este aproximativ jumătate din valoarea sa anterioară.
Astfel, valoarea cwnd este crescută cu un singur MSS la fiecare RTT.
• Expeditorul trebuie să crească cwnd cu MSS octeț i (MSS/cwnd) de fiecare dată când sosesc o nouă confirmare
Când ar trebui să se încheie creș terea liniară (de 1 MSS pe RTT)?
Când apare un timeout.
Când a avut loc evenimentul de pierdere,
→valoarea cwnd este setată la 1 MSS și
→valoarea ssthresh este setată la jumătate din valoarea cwnd.
2) Când apare un ACK triplu duplicat.
Când au fost primite cele trei ACK-uri duplicate,
valoarea cwnd este înjumătățită.
→value of ssthresh is set to half the value of cwnd.

[Link] Recuperare Rapidă

Valoarea cwnd creș te cu 1 MSS pentru fiecare ACK duplicat primit.
• Când un ACK soseș te pentru segmentul lipsă, se intră în starea de evitarea congestiei.
• Dacă apare un eveniment de expirare a timpului, recuperarea rapidă trece la starea de început lent.
• Când a avut loc evenimentul de pierdere
valoarea cwnd este setată la 1 MSS, și
valoarea ssthresh este setată la jumătate din valoarea cwnd.
Există 2 versiuni de TCP:
TCP Tahoe
O versiune timpurie a TCP era cunoscută sub numele de TCP Tahoe.
TCP Tahoe
→reducerea feroniei de congestie la 1 MSS și
→a intrat în faza de început lent după ce
i) indicat de expirare a timpului sau
eveniment de pierdere indicat de triple-duplicate-ACK.
2) TCP Reno
Noua versiune a TCP este cunoscută sub numele de TCP Reno.
TCP Reno a încorporat recuperarea rapidă.
Figura 2.44 ilustrează evoluț ia feronului de congestie TCP pentru atât Reno, cât ș i Tahoe.

Figura 2.44: Evoluț ia feroniei de congestie TCP (Tahoe ș i Reno)

„Începutul este cea mai importantă parte a lucrării.” —Platon

2-46
REȚELE DE CALCULATOARE
[Link] Controlul Congestiei TCP: Retrospectivă
Controlul congestionării TCP constă în (AIMD creș tere aditivă, scădere multiplicativă
→Creșterea liniară (aditivă) a valorii cwnd cu 1 MSS per RTT și
→Reducerea la jumătate (scădere multiplicativă) a valorii cwnd la un eveniment de triple duplicate-ACK.
Din acest motiv, controlul congestiei TCP este adesea denumit AIMD.
Controlul congestionării AIMD dă naș tere comportamentului „dinte de ferăstrău” arătat în Figura 2.45.
TCP
→incrementează liniar dimensiunea feronului de congestie până când apare un eveniment de confirmare triplă duplicată și
→scade atunci dimensiunea feroniei de congestionare cu un factor de 2

Figura 2.45: Controlul congestiei prin creș tere aditivă ș i scădere multiplicativă

Fie că tu conduci ziua, fie că ziua te conduce pe tine.

2-47
REȚELE DE CALCULATOARE
2.7.2 Echitate
Mecanismul de control al congestiei este corect dacă fiecare conexiune primeș te o parte egală din lăț imea de bandă a legăturii.
• Aș a cum este arătat în Figura 2.46, consideraț i 2 conexiuni TCP care împărtăș esc un singur link cu o rată de transmisie R.
• Assume the two connections have the same MSS and RTT.

Figura 2.46: Două conexiuni TCP care împărtăș esc un singur link de congestie

•Figura 2.47 ilustrează debitul realizat de cele două conexiuni TCP.

Dacă TCP împarte lăț imea de bandă a legăturii în mod egal între cele 2 conexiuni,
atunci, fluxul scade de-a lungul săgeț ii de 45 de grade pornind din origine.

Figura 2.47: Prinț de realizat de conexiunile TCP 1 ș i 2

[Link] Corectitudine ș i UDP

Multe aplicaț ii multimedia (cum ar fi telefonul pe internet) de multe ori nu funcț ionează peste TCP.
• În schimb, aceste aplicaț ii preferă să ruleze pe UDP. Acest lucru se datorează
→aplicațiile pot pompa sunetul lor în rețea la o rată constantă și
→ocazional pierd pachete.

[Link] Corectitudine ș i Conexiuni TCP Paralele

• Browserele web folosesc conexiuni paralele multiple pentru a transfera multiplele obiecte dintr-o pagină web.
Astfel, aplicaț ia primeș te o fracț iune mai mare din lăț imea de bandă într-un link congestionat.
Traficul web este atât de răspândit pe Internet; conexiunile paralele multiple sunt comune în zilele noastre.

Ai grijă de corpul tău. Este singurul loc în care trebuie să trăieș ti.

2-48
REȚELE DE COMPUTERE

ÎNTREBĂRI PE MODULE
PARTEA 1
1) Cu un diagramă, explică multiplexarea ș i demultiplexarea. (6*)
2) Explicaț i semnificaț ia numărului de port sursă ș i destinaț ie într-un segment. (4*)
3) Cu un diagramă, explicaț i multiplexarea ș i demultiplexarea fără conexiune. (4)
4) Cu un diagramă, explică multiplexarea ș i demultiplexarea orientată pe conexiune. (4)
5) Explicaț i pe scurt UDP ș i serviciile sale. (6*)
6) Cu format general, explică diversele câmpuri ale segmentului UDP. Explică cum se calculează suma de control (8*)
7) Cu un diagramă, explică funcț ionarea rdt1.0. (6)
8) Cu un diagramă, explică funcț ionarea rdt2.0. (6*)
9) Cu un diagramă, explică funcț ionarea rdt2.1. (6)
10) Cu un diagramă, explică funcț ionarea rdt3.0. (6*)
11) Cu un diagramă, explică modul de funcț ionare al Go-Back-N. (6*)
12) Cu un diagramă, explică funcț ionarea repetării selective. (6*)
13) Explicaț i următorii termeni: (8)
i) Număr de secvenț ă
ii) Recunoaș tere
iii) Recunoaș tere negativă
iv) Fereastră, pipeline

PARTEA 2
14) Explicaț i pe scurt TCP ș i serviciile sale. (6*)
15) Cu un format general, explică diferitele câmpuri ale segmentului TCP. (6*)
16) Cu un diagramă, explică semnificaț ia numerelor de secvenț ă ș i a numerelor de confirmare. (4*)
17) Cu un diagramă, explică transferul de date fiabil cu câteva scenarii interesante. (8)
18) Cu un diagram, explică retransmisia rapidă în TCP. (6*)
19) Cu un diagram, explică controlul fluxului în TCP. (6)
20) Cu un diagramă, explicaț i gestionarea conexiunii în TCP. (8*)
21) Cu un diagram, explică cauzele congestiei cu câteva scenarii. (8)
22) Explicaț i pe scurt abordările pentru controlul congestiei. (6*)
23) Cu un diagramă, explică controlul congestiei ATM ABR. (8)
24) Cu un diagramă, explică slowstart în TCP. (6*)
25) Cu un diagramă, explică recuperarea rapidă în TCP. (6*)

Viaț a este ca ș i cum ai merge pe bicicletă. Pentru a-ț i menț ine echilibrul, trebuie să continui să te miș ti.

2-49