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.
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 |
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ă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ă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 (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 (3 biți) pentru utilizare ulterioară și trebuie setat la zero.
Acest câmp conține steaguri de 9 biți:
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.
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.
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 .
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.
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 | |
---|---|
Î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) |
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> <-- INSTABILITPe 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 .
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.
Încetarea unei conexiuni poate fi luată în considerare în trei pași:
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.
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] .
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ă.
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).
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.
TCP /IP pe straturi ale modelului OSI | Protocoale de bază|
---|---|
Fizic | |
canalizat | |
reţea | |
Transport | |
sesiune | |
Reprezentare | |
Aplicat | |
Altele aplicate | |
Lista de porturi TCP și UDP |
![]() |
---|