Protocol de control al transmisiei

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 28 septembrie 2022; verificarea necesită 1 editare .
TCP
Nume Protocol de control al transmisiei
Nivel (conform modelului OSI ) Transport
Familie TCP/IP
Specificație RFC 793 (septembrie 1981) / STD 7
Implementări majore UNIX , Linux , BSD , Windows
Extensibilitate Opțiuni
 Fișiere media la Wikimedia Commons

Protocolul de control al transmisiei (TCP, protocolul de control al transmisiei) este unul dintre principalele protocoale de transmisie a datelor de pe Internet. Conceput pentru a gestiona transmisia de date pe Internet . Pachetele din TCP sunt numite segmente .

În stiva de protocoale, TCP/IP îndeplinește funcțiile stratului de transport al modelului OSI .

Mecanismul TCP oferă un flux de date prestabilit de conexiune , re-solicită date în caz de pierdere a datelor și elimină dublarea la primirea a două copii ale aceluiași pachet, garantând astfel (spre deosebire de UDP ) integritatea datelor transmise și notificând expeditorul despre rezultatele transmisiei.

Implementările TCP sunt de obicei încorporate în nucleele OS . Există implementări ale TCP care rulează în spațiul utilizatorului .

Când se transferă de la computer la computer prin Internet, TCP operează la nivelul superior între două sisteme finale, cum ar fi un browser și un server web. TCP efectuează un transfer de încredere al unui flux de octeți de la un proces la altul.

Antet de segment TCP

Structura antetului
Pic 0 - 3 4 - 6 7 - 15 16 - 31
0 Port sursă  Port de destinație
32 Număr de secvență (SN)
64 Număr de confirmare (ACK SN)
96 Lungimea antetului, ( Data compensare ) rezervat Steaguri Dimensiunea ferestrei
128 Sumă de control, Sumă de control Indicator de importanță, Punct urgent
160 Opțiuni (opționale, dar aproape întotdeauna utilizate)
160/192+ Date

Port sursă, Port destinație

Aceste câmpuri pe 16 biți conțin numere de port  - numere care sunt determinate de o listă specială .

Portul sursă identifică aplicația client de la care sunt trimise pachetele. Datele de răspuns sunt trimise clientului pe baza acestui număr.

Portul de destinație identifică portul către care a fost trimis pachetul.

Număr ordinal

Numărul de secvență (32 de biți) - măsurat în octeți, iar fiecare octet transferat de sarcină utilă (sarcină utilă) crește această valoare cu 1.

Dacă este setat indicatorul SYN (se stabilește o sesiune), atunci câmpul conține numărul de secvență inițial - ISN (Numărul de secvență inițial). Din motive de securitate, această valoare este generată aleatoriu și poate fi între 0 și 2 32 −1 (4294967295). Primul octet de încărcare utilă din sesiunea care se stabilește va fi ISN+1.

În caz contrar, dacă SYN nu este setat, primul octet de date transmis în acest pachet are acel număr de secvență.

Deoarece un flux TCP poate fi, în general, mai lung decât numărul de stări diferite ale acestui câmp, toate operațiile asupra numărului de secvență trebuie efectuate modulo 2 32 . Acest lucru pune o limită practică a utilizării TCP. Dacă viteza de transmisie a sistemului de comunicații este de așa natură încât să apară o depășire a numărului de secvență în timpul MSL (Viața maximă a segmentului), atunci în rețea pot apărea două segmente cu același număr, aparținând unor părți diferite ale fluxului, iar receptorul va primi date incorecte.

Numărul de confirmare

Număr de confirmare (ACK SN)  (32 de biți) - Dacă flagul ACK este setat, atunci acest câmp conține numărul de secvență al octetului pe care expeditorul acestui segment dorește să-l primească. Aceasta înseamnă că toți octeții anteriori ( de la ISN+1 la ACK-1 inclusiv) au fost recepționați cu succes.

Fiecare parte își calculează propriul număr de secvență pentru datele transmise și un număr separat de confirmare pentru datele primite. Numărul de secvență al fiecărei părți corespunde numărului de confirmare al celeilalte părți.

Lungimea antetului (offset de date)

Lungimea antetului (Data offset) este de 4 biți și indică valoarea lungimii antetului măsurată în cuvinte de 32 de biți . Dimensiunea minimă este de 20 de octeți (cinci cuvinte de 32 de biți ) iar maxima este de 60 de octeți (cincisprezece cuvinte de 32 de biți ). Lungimea antetului determină decalajul sarcinii utile de la începutul segmentului. De exemplu, un offset de date de 1111 2  indică faptul că antetul este de cincisprezece cuvinte de 32 de biți (15 linii * 32 de biți pe linie / 8 biți = 60 de biți).

Rezervat

Rezervat (3 biți) pentru utilizare ulterioară și trebuie setat la zero.

Steaguri (biți de control)

Acest câmp conține steaguri de 9 biți:

Dimensiunea ferestrei

Window Size determină independent numărul de octeți de date ( payload ), după transmiterea cărora expeditorul așteaptă confirmarea de la destinatar că datele au fost primite. Cu alte cuvinte, receptorul pachetului are un buffer cu o lungime de octeți „dimensiunea ferestrei” pentru primirea datelor.

În mod implicit, dimensiunea ferestrei este măsurată în octeți, deci este limitată la 2 16 (65535) octeți. Cu toate acestea, datorită opțiunii TCP Window scale, această dimensiune poate fi mărită la 1 GB. Pentru a activa această opțiune, ambele părți trebuie să convină asupra acestui lucru în segmentele lor SYN.

Sumă de control

Câmpul sumă de control este complementul de 16 biți a sumei tuturor cuvintelor antet de 16 biți (inclusiv pseudo antet) și a datelor. Dacă segmentul pe care se calculează suma de control are o lungime care nu este un multiplu de 16 biți, atunci lungimea segmentului este mărită la un multiplu de 16 adăugând zero biți de umplutură în partea dreaptă. Biții de umplutură (0) nu sunt trimiși în mesaj și sunt utilizați doar pentru a calcula suma de control. La calcularea sumei de control, se presupune că valoarea câmpului sumei de control în sine este 0.

Indicator urgent

O valoare de offset pozitivă de 16 biți din numărul de secvență din acest segment. Acest câmp indică numărul de secvență al octetului care termină datele urgente. Câmpul este luat în considerare doar pentru pachetele cu steagul URG setat. Folosit pentru date în afara benzii .

Opțiuni

Poate fi folosit în unele cazuri pentru a extinde protocolul. Uneori folosit pentru testare. În prezent, opțiunile includ aproape întotdeauna 2 octeți NOP (în acest caz 0x01) și 10 octeți care specifică marcajele de timp . Puteți calcula lungimea câmpului de opțiune prin valoarea câmpului de offset.

Mecanismul de acțiune al protocolului

Spre deosebire de alternativa tradițională, UDP, care poate începe să transmită pachete imediat, TCP stabilește conexiuni care trebuie create înainte ca datele să poată fi transmise. O conexiune TCP poate fi împărțită în 3 etape:

Stările sesiunii TCP

Stările sesiunii TCP
ÎNCHIS Starea inițială a nodului. De fapt fictiv
ASCULTA Serverul așteaptă cereri de conectare de la client
SYN-SENT Clientul a trimis o cerere către server pentru a stabili o conexiune și așteaptă un răspuns
SYN PRIMIT Serverul a primit o cerere de conectare, a trimis o cerere de răspuns și așteaptă o confirmare
STABILIT Conexiune stabilită, transfer de date în curs
FIN-WAIT-1 Una dintre părți (să-i spunem nodul-1) încheie conexiunea prin trimiterea unui segment cu steag FIN
ÎNCHIS-ASTEPTĂ Cealaltă parte (nodul-2) intră în această stare trimițând pe rând un segment ACK și continuă transmisia unidirecțională
FIN-WAIT-2 Nodul-1 primește un ACK, continuă citirea și așteaptă un segment cu indicatorul FIN.
LAST-ACK Nodul-2 încheie transmisia și trimite un segment cu flag-ul FIN
TIMP DE AȘTEPTARE Nodul-1 a ​​primit un segment cu steag FIN, a trimis un segment cu steag ACK și așteaptă 2*MSL secunde înainte de a închide în cele din urmă conexiunea
ÎNCHIDERE Ambele părți au inițiat închiderea conexiunii în același timp: după trimiterea unui segment cu indicatorul FIN, nodul-1 primește și un segment FIN, trimite un ACK și așteaptă un segment ACK (o confirmare a cererii sale de deconectare)

Stabilirea unei conexiuni

Procesul de pornire a unei sesiuni TCP (numit și strângere de mână  ) constă din trei pași.

1. Un client care intenționează să stabilească o conexiune trimite un segment cu un număr de secvență și un steag SYN către server.

2. Dacă clientul primește un segment cu flag SYN, atunci își amintește numărul de secvență și trimite segmentul cu flag ACK.

3. Dacă serverul în starea SYN-RECEIVED primește un segment cu steag ACK, atunci acesta trece la starea ESTABLISHED.

Procesul se numește „strângere de mână în trei căi” ( ing.  strângere de mână în trei căi ), deoarece, în ciuda faptului că procesul de stabilire a unei conexiuni folosind patru segmente este posibil (SYN către server, ACK către client, SYN către client, ACK către server), în practică sunt folosite trei segmente pentru a economisi timp.

Un exemplu de negociere de bază în 3 pași:

TCP A TCP B 1. ASCULTATE ÎNCHIS 2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED 3. STABILIT <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 4. STABILIT --> <SEQ=101><ACK=301><CTL=ACK> --> INSTALAT 5. STABILIT <-- <SEQ=301><ACK=101><CTL=ACK> <-- INSTABILIT

Pe linia 2, TCP A începe să trimită un segment SYN care indică utilizarea numerelor de secvență care încep de la 100;

Pe linia 3, TCP B trimite un SYN și o confirmare pentru SYN-ul primit către TCP A. Câmpul de confirmare arată TCP B care așteaptă numărul de secvență 101, confirmând numărul SYN 100;

Pe linia 4, TCP A răspunde cu un segment gol cu ​​un ACK pentru segmentul SYN de la TCP B;

Pe linia 5, TCP B trimite unele date. Rețineți că numărul de confirmare a segmentului de pe linia 5 (ACK=101) este același cu numărul de secvență de pe linia 4 (SEQ=101), deoarece ACK-ul nu ocupă spațiu pentru numărul de secvență (dacă faceți acest lucru, va trebui să confirmați recunoașteri - ACK pentru ACK).

Există extensii experimentale ale protocolului TCP care reduc numărul de pachete la stabilirea unei conexiuni, cum ar fi TCP Fast Open . Anterior, exista și o extensie T/TCP . Pentru criptarea transparentă a datelor, se propune utilizarea extensiei tcpcrypt .

Transfer de date

La schimbul de date, receptorul folosește numărul de ordine conținut în segmentele primite pentru a le restabili ordinea inițială. Receptorul notifică partea care transmite numărul de ordine până la care a primit cu succes date, incluzându-l în câmpul numărului de confirmare. Toate datele primite care se află în intervalul de secvențe confirmate sunt ignorate. Dacă segmentul primit conține un număr de secvență mai mare decât cel așteptat, atunci datele din segment sunt stocate în tampon, dar numărul de secvență confirmat nu este modificat. Dacă un segment corespunzător numărului de secvență așteptat este primit ulterior, ordinea datelor va fi reordonată automat pe baza numerelor de secvență din segmente.

Pentru a se asigura că partea de transmisie nu trimite date mai intens decât poate procesa receptorul, TCP conține facilități de control al fluxului. Pentru aceasta se folosește câmpul „fereastră”. În segmentele trimise de la receptor către partea de transmisie, câmpul „fereastră” indică dimensiunea curentă a tamponului de recepție. Partea de transmisie păstrează dimensiunea ferestrei și nu trimite mai multe date decât receptorul specificat. Dacă receptorul a specificat o dimensiune de fereastră de zero, atunci nu sunt trimise date în direcția acelui nod până când receptorul raportează o dimensiune mai mare a ferestrei.

În unele cazuri, aplicația care trimite poate solicita în mod explicit ca datele să fie trimise într-o anumită secvență către aplicația care primește, fără a le pune în tampon. Pentru aceasta se folosește steagul PSH. Dacă indicatorul PSH este găsit în segmentul recepționat, atunci implementarea TCP returnează toate datele tamponate în prezent către aplicația de primire. „Push” este folosit, de exemplu, în aplicațiile interactive. În terminalele de rețea, nu are sens să așteptați intrarea utilizatorului după ce au terminat de tastat o comandă. Prin urmare, ultimul segment care conține comanda trebuie să conțină flag-ul PSH, astfel încât aplicația de pe partea de recepție să poată începe să o execute.

Încheierea unei conexiuni

Încetarea unei conexiuni poate fi luată în considerare în trei pași:

  1. Trimiterea unui flag FIN de la client la server pentru a încheia conexiunea.
  2. Serverul trimite semnale de răspuns ACK, FIN către client că conexiunea este închisă.
  3. După primirea acestor steaguri, clientul închide conexiunea și trimite un ACK către server pentru a confirma că conexiunea este închisă.

Probleme cunoscute

Dimensiunea maximă a segmentului

TCP necesită o dimensiune maximă a segmentului ( MSS ) explicită dacă conexiunea virtuală este realizată pe un segment de rețea în care dimensiunea maximă a unității ( MTU ) este mai mică decât MTU Ethernet standard (1500 de octeți).

În protocoalele de tunel, cum ar fi GRE , IPIP și PPPoE , tunelul MTU este mai mic decât cel standard, astfel încât dimensiunea maximă a segmentului TCP are o lungime a pachetului mai mare decât MTU. Acest lucru duce la fragmentare și la o scădere a ratei de transfer a datelor utile. Dacă fragmentarea este dezactivată pe orice nod, atunci din punctul de vedere al utilizatorului arată ca o „înghețare” a conexiunilor. În acest caz, „blocarea” poate apărea la momente arbitrare, și anume atunci când expeditorul a folosit segmente mai lungi decât dimensiunea admisă. Pentru a rezolva această problemă, routerele folosesc reguli de firewall care adaugă parametrul MSS la toate pachetele care inițiază conexiuni, astfel încât expeditorul să folosească segmente de dimensiune validă.

MSS poate fi controlat și prin setările sistemului de operare.

Detectarea erorilor în timpul transmiterii datelor

Deși protocolul efectuează o verificare a sumei de control pe fiecare segment, algoritmul utilizat este considerat slab [1] .

În general, aplicațiile de rețea distribuite sunt încurajate să utilizeze software suplimentar pentru a asigura integritatea informațiilor transmise [2] .

Atacuri de protocol

Neajunsurile protocolului se manifestă în atacuri teoretice și practice de succes, în care un atacator poate obține acces la datele transmise, uzurpa identitatea celeilalte părți sau poate aduce sistemul într-o stare nefuncțională.

Implementare

Pseudo-titlu

Antetul TCP nu conține informații despre adresa expeditorului și destinatarului, așa că chiar dacă portul destinatar se potrivește, este imposibil să spunem cu certitudine că mesajul a ajuns la locul potrivit. Deoarece scopul protocolului TCP este livrarea de încredere a mesajelor, acest punct este de o importanță fundamentală. Această problemă poate fi rezolvată în diferite moduri. Cel mai evident este să adăugați informații despre adresa de destinație la antetul TCP, dar acest lucru, în primul rând, duce la duplicarea informațiilor, ceea ce reduce ponderea informațiilor utile transportate de segmentul TCP și, în al doilea rând, încalcă principiul încapsulării Modelul OSI. Prin urmare, dezvoltatorii de protocol au mers în altă direcție și au folosit un pseudo-antet suplimentar:

Pseudo antet TCP IPv4

biți 0 unu 2 3 patru 5 6 7 opt 9 zece unsprezece 12 13 paisprezece cincisprezece 16 17 optsprezece 19 douăzeci 21 22 23 24 25 26 27 28 29 treizeci 31
0-31 Adresa IP expeditorului (adresa sursa)
32-63 Destinatia adresei IP
64-95 0 0 0 0 0 0 0 0 Protocol Lungimea segmentului TCP (lungimea TCP)

Pseudo antet TCP IPv6

biți 0 unu 2 3 patru 5 6 7 opt 9 zece unsprezece 12 13 paisprezece cincisprezece 16 17 optsprezece 19 douăzeci 21 22 23 24 25 26 27 28 29 treizeci 31
0-95 Adresa IP expeditorului (adresa sursa)
128-223 Destinatia adresei IP
224-255 Lungimea segmentului TCP (lungimea TCP)
256-287 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Protocol de nivel superior (antetul următor)

Pseudo-antetul nu este inclus în segmentul TCP. Este folosit pentru a calcula suma de control înainte ca un mesaj să fie trimis și când este primit (receptorul își construiește propriul pseudo-antet folosind adresa gazdei de la care a venit mesajul și propria sa adresă, apoi calculează suma de control).

Scutire de la calculul sumei de control

Multe implementări ale stivei TCP/IP oferă posibilitatea de a utiliza suport hardware pentru a calcula automat suma de control în adaptorul de rețea înainte de transmiterea în rețea sau după primirea de la rețea pentru verificare. Acest lucru poate elibera sistemul de operare de la irosirea de cicluri valoroase ale procesorului la calcularea sumei de control.

Această caracteristică poate cauza analizoare de trafic care captează pachetele de ieșire înainte de a fi trimise la adaptorul de rețea și nu sunt conștienți de delegarea calculului sumei de control către adaptorul de rețea, pot raporta o eroare de sumă de control în pachetele de ieșire.

Vezi și

Literatură

Link -uri