Protocol de control al transmisiei

Această intrare sau secțiune pe subiectul internetului nu citează sursele necesare sau cei prezenți sunt insuficienți . Puteți îmbunătăți această intrare adăugând citate din surse de încredere în conformitate cu liniile directoare privind utilizarea surselor . Urmați sfaturile de proiectare de referință .

În domeniul telecomunicațiilor și tehnologiei informației, Protocolul de control al transmisiei ( TCP ) este un protocol de rețea de pachete de straturi de transport , aparținând suitei de protocol Internet , care se ocupă cu controlul transmisiei , adică asigurând o comunicare de date de rețea fiabilă între expeditor și destinatar. Definită în RFC 793 , majoritatea aplicațiilor internetului se bazează pe acesta, este prezentă numai pe terminalele de rețea ( gazde ) și nu pe nodurile de comutare interne ale rețelei de transport , implementate ca strat software de rețea în cadrul sistemului de operare al o gazdă, iar terminalul de transmisie sau de recepție îl accesează prin utilizarea apelurilor de sistem adecvate definite în API-ul sistemului.

Descriere

TCP poate fi clasificat la nivelul de transport (nivelul 4) al modelului de referință OSI și este de obicei utilizat împreună cu protocolul stratului de rețea (nivel OSI 3) IP . În modelul TCP / IP, protocolul TCP ocupă stratul 3, transport.

În conformitate cu dictatele stratului de transport stabilite de modelul ISO / OSI și cu scopul de a depăși problema lipsei de fiabilitate și control a comunicațiilor care a apărut odată cu interconectarea pe scară largă a rețelelor locale într-o singură rețea geografică mare. , TCP a fost proiectat și construit pentru a utiliza serviciile oferite de protocoalele de rețea de nivel inferior ( IP și protocoale de strat fizic și strat de legătură de date) care definesc în mod eficient modul de transfer pe canalul de comunicație, dar care nu oferă nicio garanție de fiabilitate pe livrarea în termeni de întârziere, pierdere și eroare a pachetelor de informații transmise, asupra controlului fluxului între terminale și asupra controlului congestiei rețelei, compensând astfel problemele de mai sus și construind astfel un canal de comunicație fiabil între două procese de aplicații de rețea. Canalul de comunicație astfel construit este compus dintr-un flux bidirecțional de octeți în urma stabilirii unei conexiuni la capetele dintre cele două terminale de comunicare. În plus, unele caracteristici ale TCP sunt vitale pentru buna funcționare generală a unei rețele IP. Din acest punct de vedere, TCP poate fi considerat ca un protocol de rețea care se ocupă de construirea conexiunilor și garantarea fiabilității pe o rețea IP subiacentă, care este în esență de cel mai bun efort .

TCP s-a născut în 1970 ca rezultat al activității unui grup de cercetare al Departamentului Apărării al SUA . Punctele sale forte sunt fiabilitatea și robustețea ridicate. Popularitatea sa se datorează și implementării sale pe scară largă de către Universitatea din Berkeley , lansată în California sub formă de sursă ( TCP Berkeley ). Cu toate acestea, există multe implementări și dezvoltări care au avut loc de-a lungul timpului, cum ar fi evoluțiile și îmbunătățirile (de exemplu, TCP Tahoe , TCP Reno , TCP New Reno ).

Caracteristici principale

• TCP este un protocol orientat spre conexiune, adică înainte de a putea transmite date, trebuie să stabilească o comunicare, negocind o conexiune între expeditor și destinatar, care rămâne activă chiar și în absența schimbului de date și este închisă în mod explicit atunci când nu mai este nevoie. Prin urmare, are funcționalitatea de a crea, menține și închide o conexiune .
• TCP este un protocol fiabil: garantează livrarea segmentelor la destinația lor prin mecanismul de confirmare.
• Serviciul oferit de TCP este transportul unui flux de octeți bidirecțional între două aplicații care rulează pe gazde diferite. Protocolul permite celor două aplicații să transmită simultan în ambele direcții, astfel încât serviciul poate fi considerat „ Full-duplex ” chiar dacă nu toate protocoalele de aplicație bazate pe TCP folosesc această posibilitate.
• Fluxul de octeți produs de aplicație (sau aplicație sau protocolul aplicației) pe gazda expeditoare, este preluat de TCP pentru transmisie, este apoi împărțit în blocuri, numite segmente , și livrat către TCP pe gazda primitoare care va trece către aplicația indicată de numărul de port al destinatarului în antetul segmentului (de exemplu: aplicație HTTP, portul 80).
• TCP garantează că datele transmise, dacă ajung la destinație, vor face acest lucru în ordine și o singură dată („ cel mult o dată ”). Mai formal, protocolul oferă nivelurilor superioare un serviciu echivalent cu o conexiune fizică directă care transportă un flux de octeți. Acest lucru se realizează prin diverse mecanisme de retransmisie de confirmare și timeout .
• TCP oferă funcționalitatea de verificare a erorilor pe pachetele primite datorită câmpului de sumă de verificare conținut în PDU-ul său.
• TCP are funcționalitate de control al fluxului între terminalele comunicante și controlul congestionării conexiunii, prin mecanismul ferestrei glisante . Acest lucru permite optimizarea utilizării bufferelor de recepție / trimitere pe cele două dispozitive finale (controlul fluxului) și reducerea numărului de segmente trimise în caz de congestie a rețelei.
• TCP oferă un serviciu de multiplexare a conexiunii pe o gazdă , prin mecanismul numărului portului expeditorului.

Comparație cu UDP

Principalele diferențe dintre TCP și UDP (User Datagram Protocol), celălalt transport de protocol principal al suitei de protocol Internet sunt:

• TCP este un protocol orientat spre conexiune. Prin urmare, pentru a stabili, întreține și închide o conexiune, este necesar să trimiteți segmente de servicii care să mărească cheltuielile de comunicare. În schimb, UDP nu are conexiune și trimite doar datagramele cerute de stratul aplicației ; (notă: pachetele iau nume diferite în funcție de circumstanțele la care se referă: segmente (TCP) sau datagrame (UDP));
• UDP nu oferă nicio garanție cu privire la fiabilitatea comunicării sau la sosirea efectivă a segmentelor și nici la ordinea lor în ordine pe măsură ce sosesc; dimpotrivă, TCP, prin mecanismele de confirmare și retransmisie la expirare, este capabil să garanteze livrarea datelor, chiar dacă cu costul unei cheltuieli generale mai mari (comparabile vizual prin compararea dimensiunii antetelor celor două protocoale); TCP este, de asemenea, capabil să reordoneze segmentele care sosesc la destinatar printr-un câmp al antetului său: numărul secvenței;
• Obiectul de comunicare al TCP este un flux de octeți, în timp ce UDP-urile sunt datagrame unice .

Utilizarea protocolului TCP peste UDP este, în general, preferată atunci când este necesar să existe garanții cu privire la livrarea datelor sau la ordinea de sosire a diferitelor segmente (ca de exemplu în cazul transferurilor de fișiere). Dimpotrivă, UDP este utilizat în principal atunci când interacțiunea dintre cele două gazde este idempotentă sau în cazul unor constrângeri puternice asupra vitezei și economiei resurselor rețelei (de exemplu, streaming în timp real, jocuri video multiplayer).

Segment TCP

PDU TCP se numește segment . Fiecare segment este în mod normal învelit într-un pachet IP și este alcătuit din antetul TCP și o sarcină utilă ( sarcină utilă în limba engleză), adică datele provenite din stratul aplicației (de exemplu: HTTP). Datele conținute în antet constituie un canal de comunicație între expeditorul TCP și destinatarul TCP, care este utilizat pentru a implementa funcționalitatea stratului de transport și nu este accesibil straturilor nivelurilor superioare.

Un segment TCP este structurat după cum urmează:

• Port sursă [16 biți] - Identifică numărul portului pe gazda de trimitere asociată conexiunii TCP.
• Port de destinație [16 biți] - Identifică numărul portului pe gazda de recepție asociată conexiunii TCP.
• Număr secvență [32 biți] - Număr secvență , indică decalajul (exprimat în octeți) de la începutul segmentului TCP în fluxul complet, începând de la Numărul secvenței inițiale ( ISN ), decis când se deschide conexiunea.
• Număr de confirmare [32 biți] - Număr de confirmare , are semnificație numai dacă semnalizatorul ACK este setat la 1 și confirmă primirea unei părți din fluxul de date în direcția opusă, indicând valoarea următorului număr de secvență pe care gazda expeditoare din segmentul TCP se așteaptă să primească.
• Offset de date [4 biți] - Indică lungimea (în dword pe 32 de biți) a antetului segmentului TCP; această lungime poate varia de la 5 dwords (20 octeți) la 15 dwords (60 octeți) în funcție de prezența și lungimea câmpului Opțiuni opționale.
• Rezervat [4 biți] - Biți neutilizați și pregătiți pentru dezvoltarea viitoare a protocolului; acestea ar trebui să fie setate la zero.
• Steaguri [8 biți] - Biți folosiți pentru controlul protocolului:
  • CWR (Fereastra de congestie redusă) - dacă este setat la 1 indică faptul că gazda sursă a primit un segment TCP cu semnalizatorul ECE setat la 1 (adăugat la antet în RFC 3168 ).
  • ECE [ECN (Explicit Congestion Notification) -Echo] - dacă este setat la 1 indică faptul că gazda acceptă ECN în timpul strângerii de mână cu 3 căi (adăugat la antet în RFC 3168 ).
  • URG - dacă este setat la 1 indică faptul că datele urgente sunt prezente în flux la poziția (decalare) indicată de câmpul indicator Urgent . Urgent Pointer indică sfârșitul datelor urgente;
  • ACK - dacă este setat la 1 indică faptul că câmpul Număr de confirmare este valid;
  • PSH - dacă este setat la 1 indică faptul că datele primite nu trebuie să fie tamponate, ci transmise imediat la nivelurile superioare ale aplicației;
  • RST - dacă este setat la 1 indică faptul că conexiunea nu este validă; este utilizat în cazul unei erori grave; uneori utilizat împreună cu steagul ACK pentru închiderea unei conexiuni.
  • SYN - dacă este setat la 1 indică faptul că gazda expeditorului segmentului dorește să deschidă o conexiune TCP cu gazda destinatarului și specifică valoarea Numărului de secvență inițială ( ISN ) în câmpul Număr de secvență ; este menit să sincronizeze numerele de ordine ale celor două gazde. Gazda care a trimis SYN trebuie să aștepte un pachet SYN / ACK de la gazda de la distanță.
  • FIN - dacă este setat la 1 indică faptul că gazda expeditorului segmentului dorește să închidă conexiunea TCP deschisă cu gazda primitoare. Expeditorul așteaptă confirmarea de la receptor (cu un FIN-ACK). În acest moment, conexiunea este considerată închisă pentru jumătate: gazda care a trimis FIN nu va mai putea trimite date, în timp ce cealaltă gazdă are canalul de comunicație încă disponibil. Când și cealaltă gazdă va trimite pachetul cu setul FIN, conexiunea, după FIN-ACK relativă, va fi considerată complet închisă.
• Dimensiunea ferestrei [16 biți] - Indică dimensiunea ferestrei de recepție a gazdei care trimite, adică numărul de octeți pe care expeditorul este capabil să-l accepte începând cu cel specificat de numărul de confirmare.
• Suma de verificare [16 biți] - Câmp de verificare utilizat pentru a verifica validitatea segmentului. Se obține făcând complementul 1 al celor de 16 biți care completează suma întregului antet TCP (cu câmpul sumă de control setat la zero), a întregii sarcini utile, cu adăugarea unui pseudo antet format din: adresa IP sursă ( 32 biți), adresa IP de destinație (32 biți), un octet de zerouri, un octet care indică protocolul și doi octeți care indică lungimea pachetului TCP (antet + date).
• Pointer Urgent [16 bit] - Pointer către date urgente, are semnificație numai dacă semnalizatorul URG este setat la 1 și indică abaterea în octeți începând de la numărul secvenței octetului de date urgente din flux.
• Opțiuni - Opțiuni (opționale) pentru utilizări avansate ale protocolului.
• Date - reprezintă sarcina utilă sau sarcina utilă care trebuie transmisă, adică PDU provenind de la nivelul superior.

Conexiune

Chiar înainte de transferul de date pe canalul de comunicație și operațiunile de control al transmisiei pe fluxul de date recepționat, în transmisia TCP se ocupă de stabilirea conexiunii la capetele dintre procesele de aplicație ale terminalelor de comunicare prin definiția socketului sau a adresei IP pereche , portul expeditorului și al destinatarului. Pe de altă parte, trebuie amintit că comutarea internă în nodurile rețelei de transport de date urmează de obicei comutarea pachetelor, adică fără circuit sau conexiune fixă ​​dedicată tipică în loc de comutare de circuit . Scopul conexiunii TCP este în orice caz rezervarea resurselor între procesele de aplicații care schimbă informații sau servicii între ele (de exemplu, server și client ). La sfârșitul conexiunii, TCP efectuează faza de eliminare a conexiunii. Cele două proceduri sunt distincte și sunt descrise mai jos. Implementarea aplicațiilor de conectare la rețea de pachete intră în sfera așa-numitei programări de socket .

Deschiderea unei conexiuni - strângere de mână în trei direcții

Procedura utilizată pentru stabilirea fiabilă a unei conexiuni TCP între două gazde se numește o strângere de mână în trei direcții , indicând necesitatea schimbului de 3 mesaje între gazda expeditoare și gazda primitoare pentru ca conexiunea să fie stabilită corect. De exemplu, considerați că gazda A intenționează să deschidă o conexiune TCP cu gazda B; pașii de urmat sunt:

1. A trimite un segment SYN către B - semnalizatorul SYN este setat la 1 și câmpul numărului de secvență conține valoarea x care specifică numărul secvenței inițiale a lui A;
2. B trimite un segment SYN / ACK la A - semnalizatoarele SYN și ACK sunt setate la 1, câmpul Număr secvență conține valoarea y care specifică Numărul secvenței inițiale al lui B și câmpul Număr confirmare conține valoarea x + 1 care confirmă primirea ISN-ul lui A;
3. A trimite un segment ACK către B - semnalizatorul ACK este setat la 1 și câmpul Număr de confirmare conține valoarea y + 1 care confirmă primirea ISN-ului lui B.

Al treilea segment nu ar fi, în mod ideal, necesar pentru deschiderea conexiunii, deoarece deja după ce A a primit al doilea segment, ambele gazde și-au exprimat disponibilitatea pentru a deschide conexiunea. Cu toate acestea, este necesar pentru a permite, de asemenea, gazdei B o estimare a expirării inițiale, deoarece timpul scurs între trimiterea unui segment și primirea ACK corespunzător.

Semnalizatorul SYN este util în implementarea practică a protocolului și în analiza acestuia prin firewall-uri : în traficul TCP segmentele SYN stabilesc noi conexiuni, în timp ce cele cu semnalizatorul inactiv aparțin conexiunilor deja stabilite.

Segmentele utilizate în timpul strângerii de mână sunt de obicei „doar antet”, adică au câmpul de date gol, deoarece aceasta este o fază de sincronizare între cele două gazde și nu de schimb de date.

Strângerea de mână în trei direcții este necesară, deoarece secvența numerică (ISN) nu este legată de un ceas de rețea general, în plus, fiecare pachet IP poate avea propriul mod de a calcula numărul inițial de secvență. La primirea primului SYN nu este posibil să se știe dacă secvența primită aparține unei întârzieri din cauza unei conexiuni anterioare. Cu toate acestea, ultima secvență utilizată în conexiune este stocată, astfel încât verificarea SYN aparținând vechii conexiuni poate fi solicitată de la gazda expeditoare.

Închiderea unei conexiuni - strângere de mână dublă în două direcții

Închidere cu strângere de mână cu 3 căi

Odată stabilită, o conexiune TCP nu este considerată o singură conexiune bidirecțională, ci mai degrabă ca interacțiune a două conexiuni unidirecționale; prin urmare, fiecare parte ar trebui să își încheie propria conexiune. De asemenea, pot exista conexiuni pe jumătate închise , în care doar o gazdă a închis conexiunea, deoarece nu mai are nimic de transmis, dar poate (și trebuie) să primească în continuare date de la cealaltă gazdă.

Conexiunea poate fi închisă în două moduri: cu o strângere de mână în trei direcții, în care cele două părți închid conexiunile respective în același timp, sau cu o strângere de mână în patru direcții (sau mai bine 2 strângere de mână separată), în care cele două conexiuni sunt închis.în momente diferite.

Strângerea de mână cu 3 căi pentru închiderea conexiunii este aceeași cu cea utilizată pentru deschiderea conexiunii, cu diferența că steagul utilizat este FIN în loc de SYN. O gazdă trimite un segment cu cererea FIN, cealaltă răspunde cu un FIN + ACK, în cele din urmă primul trimite ultimul ACK și întreaga conexiune este terminată.

Strângerea de mână cu două căi, pe de altă parte, este utilizată atunci când deconectarea nu este simultană între cele două gazde comunicante. În acest caz, una dintre cele două gazde trimite cererea FIN și așteaptă răspunsul ACK; celălalt terminal va face atunci același lucru, generând astfel un total de 4 segmente.

Un mod mai agresiv de închidere a conexiunii este, de asemenea, posibil, prin setarea semnalizării RESET în segment, întrerupând conexiunea în ambele direcții. TCP care primește o RESET închide conexiunea oprind orice transmisie de date.

Multiplexare și uși

Fiecare conexiune TCP activă este asociată cu un socket deschis de un proces (socketul este instrumentul oferit de sistemul de operare aplicațiilor pentru a utiliza funcționalitatea rețelei). TCP se ocupă de sortarea datelor între conexiunile active și procesele conexe. Pentru aceasta, fiecare conexiune între două gazde este asociată cu un număr de port pe fiecare dintre cele două gazde, care este un număr întreg de 16 biți nesemnat (0-65535), conținut în câmpul antet corespunzător.

O conexiune TCP va fi apoi identificată prin adresele IP ale celor două gazde și porturile utilizate pe cele două gazde.

În acest fel, un server poate accepta conexiuni de la mai mulți clienți simultan prin unul sau mai multe porturi, un client poate stabili conexiuni multiple la destinații multiple și este, de asemenea, posibil ca un client să stabilească simultan mai multe conexiuni independente la același port pe același port Server.

Server și client

Cele două procese care comunică printr-o conexiune TCP au roluri diferite:

• Procesul care inițiază o nouă conexiune TCP se numește client și trimite o cerere de conectare la un anumit port.
• Pentru ca conexiunea să fie stabilită, trebuie să existe un proces de server „ascultător” pe acel port, care acceptă să stabilească o conexiune TCP.

Porturile cunoscute și înregistrate sunt apoi utilizate de procesele serverului și sunt asociate în mod convențional cu anumite servicii, astfel încât un client să știe la ce port să se conecteze pentru a ajunge la un anumit server.

Procesul serverului, care ascultă pe un anumit port, se blochează în așteptarea conectării unui client. Procesul client solicită stabilirea unei conexiuni la un anumit server pe un anumit port. În mod normal, portul sursă utilizat de client este alocat dinamic de sistemul de operare al clientului. Când TCP stabilește conexiunea, ambelor procese li se atribuie un socket prin care pot comunica între ele. De obicei, procesul serverului se bifurcă , încredințează copilului sarcina de a comunica cu noul client și ascultă din nou. Din acest moment, clienții și serverele au roluri simetrice și folosesc aceleași instrumente pentru a comunica prin socket.

Fiabilitatea comunicării

Livrarea ordonată și eliminarea duplicatelor

Numărul de secvență sau numărul de secvență este utilizat pentru a identifica și poziționa ordonat sarcina utilă a segmentului TCP în fluxul de date. De fapt, cu transmisia tipică comutată de pachete a rețelei de date, fiecare pachet poate urma căi diferite din rețea și ajunge în afara secvenței la recepție.

La recepție, TCP se așteaptă să primească următorul segment la ultimul segment primit în ordine, adică cel al cărui număr de ordine este egal cu numărul de ordine al ultimului primit în ordine, plus dimensiunea sarcinii utile a segmentului de așteptare ( adică câmpul său de dată ).

În raport cu numărul de ordine TCP, destinatarul efectuează următoarele proceduri:

• dacă numărul de secvență primit este cel așteptat, acesta trimite sarcina utilă a segmentului direct la procesul de la nivelul aplicației și își eliberează bufferele .
• dacă numărul secvenței primite este mai mare decât cel așteptat, se deduce că unul sau mai multe segmente anterioare au fost pierdute, întârziate de stratul de rețea subiacent sau încă în tranzit pe rețea. Prin urmare, stochează temporar într-un buffer încărcătura utilă a segmentului primit în afara secvenței pentru a o putea livra în procesul de aplicare numai după ce a primit și livrat și toate segmentele anterioare care nu au fost încă primite trecând prin buffer, așteptând ca sosirea lor până la o limită fixă ​​( time-out ). În momentul livrării blocului de segmente comandat, tot conținutul bufferului este eliberat. Din punctul de vedere al procesului de aplicare, prin urmare, datele vor ajunge în ordine chiar dacă rețeaua a modificat, din orice motiv, această comandă, îndeplinind astfel cerința de livrare ordonată a datelor .
• dacă numărul de secvență primit este mai mic decât cel așteptat, segmentul este considerat un duplicat al unuia deja primit și deja trimis la stratul de aplicație și, prin urmare, aruncat. Acest lucru permite eliminarea duplicatelor de rețea .

Confirmarea și retransmiterea pachetului

Pentru fiecare segment primit în ordine, partea de recepție TCP trimite, de asemenea, un număr de confirmare sau un număr de confirmare a chitanței. Numărul de confirmare dintr-un segment se referă la fluxul de date în direcția opusă . În special, numărul de confirmare trimis de la A (receptor) la B este egal cu numărul de ordine așteptat de A și, prin urmare, se referă la fluxul de date de la B la A , un fel de raport asupra a ceea ce a fost primit.

În special, protocolul TCP adoptă politica de confirmare cumulativă , adică sosirea numărului de confirmare indică către TCP-ul care transmite că receptorul a primit și a redirecționat corect procesului de cerere segmentul cu un număr de ordine egal cu numărul de confirmare indicat (- 1) și, de asemenea, toate segmentele anterioare . Din acest motiv, partea care transmite TCP păstrează temporar într-un buffer o copie a tuturor datelor trimise, dar care nu este încă confirmată: atunci când acesta din urmă primește un număr de confirmare pentru un anumit segment, deduce că toate segmentele anterioare acelui număr au fost primit corect, eliberându-vă tamponul de date. Dimensiunea maximă a pachetelor care pot fi găsite cumulativ este specificată de dimensiunea așa-numitei ferestre glisante .

Pentru a evita timpii de așteptare care sunt prea lungi sau prea scurți pentru fiecare segment trimis, TCP pornește un temporizator , numit temporizator de retransmisie RTO (Retransmission Time Out): dacă acesta din urmă nu primește o confirmare ACK pentru segmentul trimis înainte de expirarea temporizatorului, TCP presupune că toate segmentele transmise de atunci s-au pierdut și apoi se retransmite.

Rețineți că, în TCP, mecanismul numărului de confirmare nu permite receptorului să comunice emițătorului că s-a pierdut un segment, dar unele dintre următoarele au fost primite (mecanismul negativ al numărului de confirmare ), deci este posibil ca doar pentru un pachet pierdut pe un segment trebuie retransmis multe. Acest comportament suboptim este compensat de simplitatea protocolului. Această tehnică se numește Go-Back-N (reveniți la N segmente); alternativa, adică proiectarea protocolului în așa fel încât să fie retransmise doar pachetele efectiv pierdute, se numește Repetare selectivă ; cu toate acestea, utilizarea unor câmpuri permite utilizarea repetării selective.

Numerele de confirmare și temporizatoarele de retransmisie aferente permit, prin urmare, livrarea fiabilă , adică pentru a se asigura că toate datele trimise sunt livrate în continuare în cazul în care unele pachete pot fi pierdute în tranzit prin rețea (controlul erorilor în ceea ce privește transmiterea confirmării).

Controlul debitului

Același subiect în detaliu: Controlul fluxului .

Fiabilitatea comunicării în TCP este garantată și de așa-numitul control al fluxului, adică asigurarea faptului că fluxul de date în transmisie nu depășește capacitatea de recepție sau stocare a receptorului cu pierderea pachetelor și greutate și latențe mai mari în cererile ulterioare de retransmisie. . Este implementat prin specificație de către destinatarul unui câmp adecvat cunoscut sub numele de RCV_WND ( fereastră de recepție ), o variabilă dinamică (adică dependentă de spațiul disponibil) care specifică numărul maxim de segmente care pot fi primite de destinatar. Definit:

• LastByteRead : numărul ultimului octet din fluxul de date pe care procesul de aplicare din B l-a citit din buffer
• LastByteRcvd: numărul ultimului octet din fluxul de date provenit din rețea care a fost copiat în bufferul de primire RcvBuffer alocat anterior

atunci neapărat, având TCP pentru a evita revărsarea propriului buffer, vom avea:

RCV_WND = RcvBuffer - [ LastByteRcvd - LastByteRead ]

unde, în mod evident, pentru a nega revărsarea:

RcvBuffer ≥ [ LastByteRcvd - LastByteRead ]

La rândul său, expeditorul va ține evidența ultimului octet trimis și a ultimului octet pentru care a fost primit ACK, astfel încât să nu depășească tamponul destinatarului.

Rețineți cum, dacă fereastra de recepție este goală (RCV_WND == 0), expeditorul va continua să trimită segmente de un octet, pentru a garanta sincronizarea între expeditor și receptor.

Probleme de control al fluxului în TCP

Există unele probleme de control al fluxului în TCP care apar atât pe părțile transmițătorului, cât și pe cele ale receptorului. Aceste probleme se numesc sindromul ferestrei Silly și au efecte și cauze diferite, în funcție de latură.

Fereastra stupidă pe partea receptorului : dacă receptorul golește bufferul de recepție foarte încet, numai atunci când receptorul extrage informații din buffer-ul de recepție este un spațiu liber liber (fereastra de recepție foarte mică) și această valoare a ferestrei de recepție este comunicată înapoi emițătorului. problema este că acum, emițătorul folosește o fereastră de transmisie foarte îngustă și, prin urmare, se poate întâmpla ca acesta să fie obligat să trimită segmente foarte scurte în comparație cu antetul canonic de 20 de octeți, cu o consecință a scăderii eficienței transmisiei.

Pentru a atenua această problemă, TCP determină receptorul să „mintă” transmițătorul indicând o fereastră nulă până când bufferul de recepție este golit pentru jumătate sau pentru o porțiune cel puțin egală cu MSS (= mărimea maximă a segmentului), evitând astfel că transmițătorul trimite segmente foarte scurte care limitează eficiența transmisiei.

Acest algoritm de soluție se numește algoritm Clark.

Silly window lato trasmettitore : si verifica quando l'applicazione genera dati molto lentamente. Dal momento che il TCP legge i dati che sono presenti nel buffer di trasmissione creando dei segmenti che invia dall'altra parte, nel caso in cui l'applicazione generi i dati molto lentamente l'entità TCP potrebbe essere forzata a creare segmenti molto corti (e con tanto overhead).

La soluzione si chiama algoritmo di Nagle, per cui il TCP sorgente invia la prima porzione di dati anche se corta, e quando è il momento di creare nuovi segmenti, tali segmenti, vengono creati solamente se il buffer d'uscita contiene dati sufficienti per riempire un MSS oppure anche quando riceve un riscontro valido.

Controllo di congestione

Lo stesso argomento in dettaglio: Controllo della congestione in TCP .

Infine l'ultimo tipo di controllo effettuato da TCP per garantire affidabilità alla comunicazione è il cosiddetto controllo della congestione ovvero far in modo che si limitino il più possibile fenomeni di congestione all'interno della rete per eccessivo traffico sui dispositivi di rete con perdita di pacchetti in transito e maggior peso e latenze nelle successive richieste di ritrasmissione, modulando nel tempo la quantità di dati in trasmissione in funzione dello stato interno di congestione. La particolarità di tale controllo è che viene effettuato agendo sulla trasmissione agli estremi cioè sui terminali di rete e non attraverso la commutazione interna alla rete grazie alle informazioni deducibili dal terminale stesso sullo stato della trasmissione dei pacchetti. Nello specifico, una volta "stimato" lo stato di congestione interno della rete avendo scelto come parametro di riferimento la perdita di pacchetti trasmessi desunta dai mancati ACK di riscontro dei pacchetti stessi, tale controllo viene poi attuato attraverso la definizione da parte del mittente di un opportuno campo noto come C_WND ( finestra di congestione ) la quale assegna, dinamicamente nel tempo, il numero massimo di segmenti da trasmettere al destinatario.

I timer del TCP

Timer di ritrasmissione

Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato.

La corretta impostazione di questo timer è difficile ma molto importante, in quanto un timer troppo breve comporta ritrasmissioni inutili (il timer scatta mentre il riscontro o il pacchetto sono ancora in viaggio), mentre un timer troppo lungo comporta attese in caso di effettiva perdita di pacchetti. Ovviamente tale intervallo dovrà essere almeno pari al Round Trip Time cioè al tempo di percorrenza a due vie di un pacchetto per tornare al mittente sotto forma di ACK. Tale RTT, per la natura intrinseca della commutazione di pacchetto interna alla rete, è tipicamente variabile in maniera aleatoria. TCP allora aggiusta continuamente il timer di ritrasmissione basandosi su una stima a media mobile del Round Trip Time .

Timer di persistenza

Come spiegato sopra, il TCP utilizza il metodo della finestra scorrevole per gestire il controllo di flusso di dati che il ricevente è in grado di accettare dal mittente. Tra i valori validi di questo campo vi è anche lo zero, a significare che il ricevente richiede l'interruzione momentanea dell'invio di dati.

Nel malaugurato caso in cui il pacchetto che riapre la finestra venga perso, il mittente del canale TCP rimarrà però in attesa indefinita. Per evitare questo, il TCP avvia un timer, detto timer di persistenza , ogni qual volta il ricevente chiude la finestra. Quando questo timer scade, il mittente invia un pacchetto sonda al ricevente, provocandone una risposta: in questo modo il mittente potrà essere sicuro che la finestra sia chiusa (ricevendo un altro pacchetto con campo Window a 0) o sbloccarsi dallo stallo (ricevendo un pacchetto con campo Window diverso da zero).

Timer di keepalive

La RFC 793 che definisce il protocollo TCP non prevede particolari azioni da intraprendere quando non ci sono dati da trasmettere sulla connessione. Alcune implementazioni però consentono di trasmettere periodicamente segmenti vuoti, detti keepalive , per evitare di mantenere indefinitamente in memoria connessioni con sistemi che potrebbero anche non essere più attivi. In molti sistemi il software applicativo ha la possibilità di scegliere se abilitare o meno i keepalive per ogni connessione.

Quando si usano i keepalive, è presente dunque il timer di keepalive : esso viene reimpostato alla ricezione o alla trasmissione di ogni segmento, e quando scade viene trasmesso un keepalive. Un valore tipico è di due ore.

Timed wait

L'ultimo timer utilizzato da TCP è il timed wait . In pratica, prima di disconnettere effettivamente una connessione, i due estremi del canale attendono un tempo pari al doppio del tempo di vita di un comune pacchetto: questo evita che dei pacchetti possano rimanere circolanti per la rete anche dopo la chiusura.

Vulnerabilità

Il protocollo TCP viene progettato per la prima volta come strumento da utilizzare in reti chiuse e private, gestite da enti o università che quindi non si pongono il problema di garantirne la sicurezza; funzionalità come la sicurezza, l'integrità e l'autenticità della comunicazione tra due host vengono relegate a livelli di rete superiori. Esistono perciò diverse soluzioni implementative per ovviare a questa mancanza. I risultati di una valutazione completa sulla sicurezza di questo protocollo, insieme a possibili soluzioni, sono stati pubblicati nel 2009 ^[1] , e sono attualmente studiati da IETF . Di seguito vengono riportate e illustrate genericamente le principali e più diffuse metodologie per condurre un attacco a livello di trasporto su una comunicazione che si appoggia a questo protocollo.

Denial of service

Lo stesso argomento in dettaglio: Denial of service .

Un attacco Dos ha come scopo quello di mandare in tilt un server occupando tutte le risorse a sua disposizione. Questo obiettivo può essere raggiunto attraverso diverse tecniche. Un primo modo consiste nell'utilizzare un metodo che prende il nome di SYN flood . Per aprire una connessione TCP, come già detto, è necessario il meccanismo del Three-Way Handshake. Se il client che ha chiesto di instaurare una connessione non risponde al server con il pacchetto di ACK dopo che ha ricevuto il relativo SYN-ACK, il server rimarrà in attesa. Utilizzando tecniche di IP spoofing e inviando ripetutamente pacchetti SYN appositamente assemblati e non il corrispettivo ACK, un singolo host può arrivare a consumare grandi quantità di risorse sul server che continuerà a tenere in memoria informazioni su connessioni fittizie. Possibili soluzioni a questo problema sono l'introduzione di timer al termine del quale il server cancellerà la connessione o l'introduzione di un meccanismo chiamato SYN cookies , anche se quest'ultimo porta con sé un proprio insieme di vulnerabilità. Un altro attacco che mira a consumare tutte le risorse di un sistema è l'utilizzo di software di tipo Sockstress , tale eventualità può facilmente essere scongiurata applicando politiche di gestione delle risorse del sistema.

Connection hijacking

Come detto precedentemente, ogni pacchetto TCP è identificato da un numero di sequenza che lo individua univocamente all'interno della comunicazione. Un utente malintenzionato che è in grado di intercettare una sessione TCP e di reindirizzare i pacchetti può disattivare una connessione TCP. Per farlo, l'attaccante apprende il successivo numero di sequenza della comunicazione in corso e crea un falso pacchetto che assomigli a quello successivo del flusso e lo invia al destinatario al posto dell'originale. Quando il destinatario riceve il pacchetto falso, lo accetta per via del numero di sequenza corretto, ma riscontrando una lunghezza del pacchetto diversa da quella prevista, perde la sincronizzazione con l'host sorgente e chiude quindi la connessione. Questo procedimento può essere combinato con tecniche di ARP spoofing o di modifica del protocollo di routing per gestire il controllo del flusso di pacchetti, in modo da ottenere un controllo permanente sulla connessione TCP. Attuare questo tipo di attacco non era difficile prima della RFC 1948 , quando il numero di sequenza era facilmente prevedibile grazie a tecniche di IP Spoofing. Questo è il motivo per cui, ad oggi, il numero di sequenza iniziale viene scelto casualmente.

TCP Veto

Un utente malintenzionato che, oltre al numero di sequenza, è in grado di predire anche la dimensione del pacchetto successivo può indurre il destinatario ad accettarne uno dannoso senza interrompere la connessione esistente. L'attaccante genera un pacchetto con il numero di sequenza e con una dimensione del payload del successivo segmento atteso, avendo però completa libertà sui dati da inserire all'interno. Una volta ricevuto questo pacchetto il destinatario lo accetta quindi senza problemi. Quando il pacchetto legittimo viene ricevuto, viene scartato dal destinatario poiché ne ha già ricevuto uno con quel numero di sequenza in quella connessione, come un normale pacchetto duplicato. Da ciò deriva il termine che descrive questo attacco: il pacchetto legittimo riceve il veto dal pacchetto dannoso. A differenza del Connection hijacking, la connessione non viene mai persa e la comunicazione continua normalmente dopo che il pacchetto dannoso viene accettato. TCP Veto dà all'attaccante un controllo minore sulla comunicazione, ma rende l'attacco particolarmente difficile da individuare. Il traffico che richiede il Connection hijacking per il controllo della connessione in questo caso non avviene, evitando di attirare attenzioni indesiderate. L'unica prova di un avvenuto TCP Veto è un singolo pacchetto duplicato, un evento normale in TCP. Il mittente del pacchetto legittimo invece non avrà alcuna percezione dell'avvenuto attacco.

TCP Reset

Nei pacchetti TCP è presente un flag nell'header, chiamato RST . In molti pacchetti questo bit è impostato a zero e non ha nessun effetto, se invece è impostato a uno, indica al destinatario che può interrompere immediatamente la connessione e quindi liberare tutte le risorse occupate, dato che il mittente non ha intenzione di inviare ulteriori pacchetti. Un utente malintenzionato può quindi ascoltare la conversazione tra due host, e inviare a uno oa entrambi un pacchetto con il flag RST impostato a uno. Questo metodo consente di interrompere connessioni TCP in modo veloce e senza lasciare particolari tracce. L'attaccante deve comunque camuffare il pacchetto modificando l'indirizzo IP di provenienza, per poter ingannare l'host.

Note

Voci correlate

• Internet Protocol
• Porta (reti)
• Finestra scorrevole
• User Datagram Protocol (UDP)
• Stream Control Transmission Protocol
• Controllo di errore
• Controllo di flusso
• Controllo della congestione in TCP
• TCP tuning
• TCP connect scan

Altri progetti

• Wikimedia Commons contiene immagini o altri file su Transmission Control Protocol

Collegamenti esterni

• ( EN ) RFC 793 - Transmission Control Protocol Specifications , su tools.ietf.org .
• Traduzione in italiano dell'RFC ( TXT ), su rfc.altervista.org .
• ( EN ) Porte di comunicazione TCP ( PDF ), su answersthatwork.com .
• ( EN ) RFC 1948 - Defending Against Sequence Number Attacks , su tools.ietf.org .
• ( EN ) Security Assessment of the Transmission Control Protocol (TCP) ( PDF ), su cpni.gov.uk (archiviato dall' url originale il 6 marzo 2009) .

Portale Telematica : accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete