SCTP ( Engleză Stream Control Transmission Protocol - „protocol de transmisie cu control al fluxului”) este un protocol de nivel de transport în rețelele de calculatoare care a apărut în 2000 în IETF . RFC 4960 descrie acest protocol, iar RFC 3286 oferă o introducere tehnică a acestuia.
Ca orice alt protocol de nivel de transport, SCTP funcționează similar cu TCP sau UDP [1] . Fiind un protocol mai nou, SCTP are mai multe inovații precum multi-threading, protecție împotriva atacurilor DDoS, conexiune sincronă între două gazde pe două sau mai multe canale fizice independente (multi-homing).
Crearea unei noi conexiuni în protocoalele TCP și SCTP are loc utilizând mecanismul de confirmare (handshaking) a pachetelor. În protocolul TCP, această procedură este numită strângere de mână în trei căi. Clientul trimite un pachet SYN (abreviar Synchronize). Serverul răspunde cu un pachet SYN-ACK (Synchronize-Acknowledge). Clientul confirmă primirea pachetului SYN-ACK cu un pachet ACK. Aceasta completează procedura de stabilire a conexiunii.
TCP are o vulnerabilitate potențială în care un atacator ar putea trimite mai multe pachete SYN către un server prin configurarea adreselor IP surse falsificate. La primirea unui pachet SYN, serverul alocă o parte din resursele sale pentru a stabili o nouă conexiune. Procesarea multor pachete SYN va necesita mai devreme sau mai târziu toate resursele serverului și va face imposibilă procesarea cererilor noi. Acest tip de atac se numește " SYN flood " ( SYN flood ).
Protocolul SCTP este protejat de astfel de atacuri folosind mecanismul de strângere de mână în patru căi și introducerea unui token (cookie). În SCTP, clientul începe procedura de stabilire a conexiunii prin trimiterea unui pachet INIT. Ca răspuns, serverul trimite un pachet INIT-ACK care conține un token (o cheie unică care identifică noua conexiune). Clientul răspunde apoi trimițând un pachet COOKIE-ECHO care conține jetonul primit de la server. Abia după aceea serverul își alocă resursele noii conexiuni și confirmă acest lucru prin trimiterea unui pachet COOKIE-ACK către client.
Pentru a rezolva problema întârzierii transferului de date la efectuarea procedurii de strângere de mână în patru căi în protocolul SCTP, este permisă includerea datelor în pachetele COOKIE-ECHO și COOKIE-ACK.
Să ne uităm la diferențele dintre procedura de închidere a soclului SCTP și procedura de semiînchidere TCP.
În protocolul TCP, este posibilă o situație de închidere parțială a conexiunii atunci când un nod a terminat de transmis date (prin trimiterea unui pachet FIN), dar continuă să primească date pe această conexiune. Celălalt nod poate continua să transmită date până când închide conexiunea pe propria sa parte. Starea de închidere parțială este rar folosită de aplicații, așa că dezvoltatorii protocolului SCTP au considerat că este necesar să-l înlocuiască cu o secvență de mesaje pentru a rupe asocierea existentă. Când un nod își închide soclul (trimite un mesaj SHUTDOWN), ambii egali trebuie să înceteze transmiterea datelor, permițând doar schimbul de pachete care confirmă primirea datelor trimise anterior.
TCP gestionează secvența de octeți : datele trimise de aplicația care trimite trebuie să ajungă în aplicația de primire exact în aceeași ordine (în timp ce protocolul IP este capabil să inverseze secvența pachetelor; în plus, pachetele lipsă sunt retrimise și ajung de obicei la destinatar în afara secvenței; datele sunt tamponate pentru a combate aceste fenomene). SCTP poate transporta date între două puncte ( noduri ) simultan prin mai multe fluxuri de mesaje . Spre deosebire de TCP , SCTP procesează mesaje întregi (păstrează limita mesajului) și nu octeți obișnuiți de informații . În acest fel, SCTP este similar cu UDP. Astfel, dacă expeditorul trimite serverului un mesaj format din 100 de octeți în primul pas, urmat de alți 50 de octeți, atunci destinatarul din primul pas va primi exact primii 100 de octeți în primul mesaj și abia apoi 50 de octeți în a doua operatie de citire din priza .
Termenul „multithreading” (ing. multi-streaming ) se referă la capacitatea SCTP de a transmite în paralel prin mai multe fluxuri independente de mesaje . De exemplu, transferăm mai multe fotografii printr-o aplicație HTTP ( de exemplu, un browser ). Puteți utiliza o mulțime de conexiuni TCP multiple pentru aceasta, dar o asociere SCTP (eng. SCTP association ), care gestionează mai multe fluxuri de mesaje în acest scop, este, de asemenea, acceptabilă. Fluxurile sunt unidirecționale, ceea ce înseamnă că transferă informații doar într-o direcție ( imaginea de mai sus este inexactă ).
TCP realizează ordinea corectă a octeților într-un flux, atribuind în mod abstract un număr de secvență fiecărei unități trimise și ordonând octeții primiți folosind numerele de secvență atribuite pe măsură ce ajung. Pe de altă parte, SCTP atribuie diferite numere de secvență mesajelor trimise pe un anumit flux . Acest lucru permite ordonarea independentă a mesajelor pe diferite fire. Oricum, multithreading este o opțiune în SCTP. În funcție de dorințele aplicației utilizator, mesajele pot fi procesate nu în ordinea în care au fost trimise, ci în ordinea în care au fost primite.
Beneficiile utilizării SCTP includ:
O parte a avantajului provine din faptul că dezvoltatorii inițiali ai SCTP au proiectat protocolul pentru a transporta telefonia ( SS7 ) prin IP .
SCTP a fost proiectat cu unele caracteristici pentru a îmbunătăți securitatea, cum ar fi o „strângere de mână 4x” (față de „strângere de mână 3x” de la TCP) pentru a preveni atacurile SYN flood și cookie -uri mari pentru autentificarea asociației.
Fiabilitatea a fost unul dintre aspectele cheie ale designului de securitate al protocolului SCTP. Multi-homing permite unei asocieri să rămână deschisă chiar dacă unele dintre rutele și interfețele utilizate devin indisponibile. Acest lucru este de o importanță deosebită pentru SIGTRAN , care utilizează SCTP pentru a transporta mesaje și servicii de protocol SS7 printr-o rețea IP, necesitând o rezistență puternică în timpul întreruperilor de legătură pentru a menține serviciile de telecomunicații, chiar și în fața unor anomalii severe ale rețelei.
Criptarea nu face parte din designul original al SCTP.
În unele cazuri, SCTP este un bun candidat pentru a puterea TCP/IP Motivul pentru aceasta este faptul că unele sisteme de operare sunt distribuite cu suport pentru protocolul SCTP, dar din cauza lui puțin cunoscut (comparativ cu TCP sau UDP), administratorii uită uneori să configureze detectarea intruziunilor în firewall , ceea ce face posibilă scanează traficul.
| Parametru | UDP | TCP | SCTP |
|---|---|---|---|
| Stabilirea unei conexiuni | Nu | da | da |
| Transmisie fiabilă | Nu | da | da |
| Păstrarea limitelor mesajelor | da | Nu | da |
| livrare ordonata | Nu | da | da |
| Livrare necomandată | da | Nu | da |
| Sume de verificare a datelor | da | da | da |
| Dimensiunea sumei de control (biți) | 16 | 16 | 32 |
| Calea MTU | Nu | da | da |
| Managementul acumulării | Nu | da | da |
| Multithreading | Nu | Nu | da |
| Suport pentru mai multe interfețe | Nu | Nu | da |
| O grămadă de fire | Nu | da | da |
La formarea cadrelor de mesaje, limitele mesajului sunt păstrate în forma în care este transmis la soclu; aceasta înseamnă că dacă clientul trimite 100 de octeți urmați de 50 de octeți către server, atunci serverul ia 100 de octeți și 50 de octeți ca două citiri. Protocolul UDP funcționează exact în același mod; aceasta este o caracteristică a protocoalelor orientate pe mesaje.
În schimb, protocolul TCP gestionează un flux nestructurat de octeți. Dacă procedura de încadrare a mesajelor nu este utilizată, atunci nodul de rețea poate primi date mai mari sau mai mici decât datele trimise. Acest mod de operare necesită ca, pentru protocoalele orientate pe mesaje care rulează peste TCP, un buffer de date dedicat să fie furnizat la nivelul aplicației și să fie efectuată încadrarea mesajelor (o sarcină potențial complexă).
Protocolul SCTP oferă încadrare pentru transmiterea datelor. Când un nod scrie într-un socket, peer-ul său este garantat să primească un bloc de date de aceeași dimensiune.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Pachetele SCTP au o structură mai simplă decât pachetele TCP. Fiecare pachet este format din două secțiuni principale:
Primul bloc este marcat cu verde, iar ultimul dintre cele N blocuri (N bloc) este evidențiat cu roșu.
Fiecare bloc are un identificator de tip, care ocupă un octet. Astfel, pot fi definite maximum 255 de tipuri de blocuri diferite. RFC 4960 definește o listă de tipuri de blocuri, cu un total de 15 tipuri definite în prezent. Restul blocului constă dintr-un câmp de lungime de 2 octeți (lungimea maximă care poate fi conținută în acest câmp este de 65535 octeți) și, de fapt, datele. Dacă dimensiunea blocului nu este un multiplu de 4 octeți, atunci este completată cu zerouri până la o dimensiune care este un multiplu de 4 octeți.
Retransmisia blocurilor DATE se poate datora (a) unui timeout definit de temporizatorul de retransmisie sau (b) primirii unui SACK care indică faptul că blocul DATA nu a fost primit de către destinație. Pentru a reduce șansa de aglomerație, retransmisia blocurilor de DATE este limitată. Valoarea de expirare a reîncercării (RTO) este setată pe baza unui timp estimat de călătorie dus-întors și scade exponențial pe măsură ce crește rata de pierdere a mesajelor. Pentru asocierile active cu trafic de DATE aproape constant, motivul reîncercării este probabil să fie mesajele SACK, mai degrabă decât un timeout. Pentru a reduce probabilitatea unor reîncercări inutile, se folosește regula 4 SACK, conform căreia retransmisia are loc numai la al patrulea SACK, indicând că un bloc de date a fost omis. Acest lucru previne retransmisiile cauzate de livrarea în afara comenzii.
Este menținut un contor pentru numărul de reîncercări către o anumită adresă de destinație fără confirmarea livrării cu succes. Când valoarea acestui contor atinge pragul specificat (parametru de configurare), adresa este declarată inactivă și protocolul SCTP începe să folosească o altă adresă pentru transmiterea blocurilor DATE. În plus, blocurile speciale Heartbeat sunt trimise periodic către toate adresele neutilizate (opționale) și se menține un contor pentru numărul de blocuri Heartbeat trimise fără a returna un Heartbeat Ack corespunzător. Când valoarea contorului atinge un anumit prag (parametru de configurare), adresa corespunzătoare este declarată inactivă. Blocurile de bătăi ale inimii sunt transmise la adrese inactive până când este primit un mesaj de confirmare care indică faptul că adresa a fost restabilită la activitate. Frecvența blocurilor Heartbeat este determinată de valoarea RTO și de întârzierea suplimentară, care permite trimiterea blocurilor Heartbeat fără a interfera cu traficul utilizatorului.
Pentru toate adresele destinatarului, se menține un numărător comun al numărului de repetări sau blocuri Heartbeat, datele sunt transmise la un punct la distanță fără a primi o confirmare corespunzătoare (Ack) de la acesta. Când valoarea contorului atinge pragul specificat (parametrul de configurare), punctul final este declarat inaccesibil și asocierea SCTP este închisă.
Protocolul TCP oferă mijloacele de bază pentru transmiterea datelor prin Internet pe o cale fiabilă. Cu toate acestea, TCP impune unele restricții asupra transportului de date:
Toate aceste limitări sunt dăunătoare performanței rețelelor de telefonie prin IP .
Protocolul a fost dezvoltat ca parte a muncii unui grup SIGTRAN special creat în cadrul IETF [2] pentru a implementa protocoale și adaptări ale stivei SS-7 pentru utilizare în rețele IP, datorită necesității unei livrări de date fiabile și rapide. Acest lucru este menționat în mod explicit în RFC 4960 capitolul 1.1 Motivație :
...
Transportul semnalizării PSTN prin rețeaua IP este o aplicație pentru care toate aceste limitări ale TCP sunt relevante. În timp ce această aplicație este motivată direct de dezvoltarea SCTP, alte aplicații pot găsi SCTP o potrivire bună cu cerințele lor... ...
Semnalizarea PSTN printr-o rețea IP este o aplicație pentru care toate limitările TCP sunt direct relevante. În timp ce acest lucru a motivat în mod direct dezvoltarea SCTP, alte aplicații pot considera că SCTP este o potrivire bună pentru cerințele lor...
RFC 4960
| Protocoale | TCAP | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V5.2 | MTP3 | MTP3 | ESTE SUS | SCCP | DSS1 | TCAP | ||||||||||||||
| SIGTRAN | V5UA | M2UA | M2PA | M3UA | IUA | SUA | ||||||||||||||
| retea de calculatoare | SCTP | |||||||||||||||||||
| IP | ||||||||||||||||||||
Există o implementare de referință pentru FreeBSD, Mac OS X, Microsoft Windows și Linux [3] .
Protocolul SCTP este implementat pe următoarele sisteme de operare:
Implementare prin drivere terțe:
Biblioteci separate pentru utilizatori:
Aplicatii:
| Protocoale de bază TCP /IP pe straturi ale modelului OSI | |
|---|---|
| Fizic | |
| canalizat | |
| reţea | |
| Transport | |
| sesiune | |
| Reprezentare | |
| Aplicat | |
| Altele aplicate | |
| Lista de porturi TCP și UDP | |