SCTP (Stream Control Tran­smis­sion Protocol): il pro­to­col­lo di trasporto af­fi­da­bi­le e orientato ai messaggi

Questa famiglia di pro­to­col­li Internet co­sti­tui­sce la base per la co­mu­ni­ca­zio­ne di sistemi in reti come Internet. Gli oltre 500 membri di questo gruppo hanno in gran parte ruoli molto diversi, ma ci sono anche pro­to­col­li che hanno più o meno la stessa funzione. Per esempio, sia il TCP (Tran­smis­sion Control Protocol) che l'UDP (User Datagram Protocol) de­fi­ni­sco­no il modo in cui vengono scambiati i dati tra i par­te­ci­pan­ti di una rete. Tuttavia, mentre il TCP richiede una con­nes­sio­ne esistente, l'UDP consente il tra­sfe­ri­men­to di file senza con­nes­sio­ne. Con l'SCTP (Stream Control Tran­smis­sion Protocol), l'IETF (Internet En­gi­nee­ring Task Force) ha pub­bli­ca­to nel 2000 un altro pro­to­col­lo che combina le ca­rat­te­ri­sti­che del TCP e dell'UDP.

Lo Stream Control Tran­smis­sion Protocol, in breve SCTP, è un pro­to­col­lo di rete af­fi­da­bi­le della famiglia dei pro­to­col­li Internet, svi­lup­pa­to dal gruppo di lavoro IETF Signaling Transport (SIGTRAN). Una prima versione del pro­to­col­lo è definita nell'RFC 2960, pub­bli­ca­to nel 2000. Sette anni dopo, l'IETF ha pub­bli­ca­to una versione rivista nell'RFC 4960. In questi standard l'SCTP è descritto prin­ci­pal­men­te come un pro­to­col­lo uti­liz­za­to per le in­fra­strut­tu­re te­le­fo­ni­che nelle reti IP. Tuttavia, viene uti­liz­za­to anche in altre aree, ad esempio nel Reliable Server Pooling (gestione di pool di server per il bi­lan­cia­men­to della quantità di dati trasmessa).

L'SCTP utilizza ti­pi­ca­men­te l'IP come base, ma può anche uti­liz­za­re qualsiasi altro servizio di tra­smis­sio­ne senza con­nes­sio­ne. Il trasporto dei pacchetti è ca­rat­te­riz­za­to in par­ti­co­la­re dalle seguenti ca­rat­te­ri­sti­che:

• tra­smis­sio­ne con­fer­ma­ta di dati utente (senza errori e senza duplicati)
• fram­men­ta­zio­ne dei dati per ri­spet­ta­re la di­men­sio­ne massima dei pacchetti del ri­spet­ti­vo percorso di rete
• ricezione in sequenza di messaggi utente al­l'in­ter­no di più flussi di dati (mul­ti­strea­ming), compresa l'opzione per spe­ci­fi­ca­re l'ordine di questi messaggi
• rag­grup­pa­men­to (fa­col­ta­ti­vo) di più messaggi utente in un unico pacchetto SCTP (chunk bundling)
• tol­le­ran­za agli errori a livello di rete grazie al mul­ti­ho­ming (host con più indirizzi di rete validi) di uno o entrambi i partner di co­mu­ni­ca­zio­ne

Lo Stream Control Tran­smis­sion Protocol punta pertanto sulla tra­smis­sio­ne sicura e af­fi­da­bi­le dei dati. Un rigoroso re­go­la­men­to della sequenza dei flussi di dati inviati non è ne­ces­sa­rio, ma in linea di principio è possibile in qualsiasi momento. In questo caso, se l'ap­pli­ca­zio­ne mittente lo richiede, la tra­smis­sio­ne dei pacchetti SCTP deve essere eseguita secondo una procedura fissa. I dati inviati, che possono essere suddivisi in più flussi, non sono re­gi­stra­ti in byte, ma in pacchetti, il che è par­ti­co­lar­men­te utile per i servizi orientati ai messaggi.

La sicurezza viene as­si­cu­ra­ta dal four-way handshake (au­ten­ti­ca­zio­ne reciproca, compresa la creazione di una con­nes­sio­ne) tra il mittente e il de­sti­na­ta­rio, senza la quale il tra­sfe­ri­men­to dati tramite SCTP non sarebbe possibile. L'header contiene anche un tag di verifica e un campo opzionale checksum.

Al fine di il­lu­stra­re il fun­zio­na­men­to del trasporto dati tramite lo Stream Control Tran­smis­sion Protocol, esa­mi­ne­re­mo più in dettaglio le funzioni prin­ci­pa­li dell’SCTP, dalla four-way handshake alla fram­men­ta­zio­ne e alla tra­smis­sio­ne dei pacchetti.

Le con­nes­sio­ni SCTP stabilite possono essere chiuse dal­l'ap­pli­ca­zio­ne o dal­l'u­ten­te non appena la tra­smis­sio­ne è terminata, se non vengono in­ter­rot­te pre­ma­tu­ra­men­te a causa di un errore. Inoltre è possibile in­ter­rom­pe­re il col­le­ga­men­to in qualsiasi momento tramite una richiesta. In ogni caso il tra­sfe­ri­men­to di dati viene com­ple­ta­men­te in­ter­rot­to non appena un utente si di­scon­net­te.

Nello standard SCTP il termine stream si riferisce a una sequenza di dati utente che vengono scambiati tra server e client. Una singola con­nes­sio­ne SCTP consente un numero in­de­fi­ni­to di stream, che viene spe­ci­fi­ca­to dal­l'u­ten­te quando sta­bi­li­sce la con­nes­sio­ne. Mentre l'ordine dei dati al­l'in­ter­no di un flusso è ri­go­ro­sa­men­te ri­spet­ta­to, per la consegna dei vari flussi non esistono una gerarchia fissa e di­pen­den­ze. Se dunque ci sono problemi durante il tra­sfe­ri­men­to di un flusso di dati, ciò non ha alcun effetto sulla tra­smis­sio­ne degli altri flussi. Esiste inoltre un mec­ca­ni­smo che permette di bypassare la tra­smis­sio­ne in sequenza e di inviare pacchetti di messaggi con priorità.

L'SCTP offre la pos­si­bi­li­tà di fram­men­ta­re i pacchetti per poter ri­spet­ta­re in ogni momento il PMTU (Path Maximum Tran­smis­sion Unit) de­ter­mi­na­to, cioè la di­men­sio­ne massima del pacchetto che può essere trasmessa sul ri­spet­ti­vo percorso di con­nes­sio­ne. Al momento della ricezione i singoli frammenti vengono rias­sem­bla­ti e inviati al­l'u­ten­te come messaggio completo. Questa fram­men­ta­zio­ne a livello di trasporto offre alcuni vantaggi rispetto alla fram­men­ta­zio­ne eseguita a livello di rete dal pro­to­col­lo IP: ad esempio riduce il carico di lavoro dei router re­spon­sa­bi­li della fram­men­ta­zio­ne dei pacchetti IP. Inoltre viene eliminato il problema dei messaggi completi che devono essere nuo­va­men­te inviati a causa della perdita in rete di un singolo frammento.

Lo Stream Control Tan­smis­sion Protocol con­tras­se­gna tutti i frammenti di dati o messaggi non fram­men­ta­ti con un co­sid­det­to Tran­smis­sion Sequence Number (numero di sequenza di tra­smis­sio­ne). Per ognuno di questi numeri di sequenza il mittente si aspetta un messaggio di conferma dal de­sti­na­ta­rio. Se questo messaggio non viene ricevuto entro un periodo di tempo spe­ci­fi­ca­to, il pacchetto cor­ri­spon­den­te viene inviato nuo­va­men­te.

Per garantire questa af­fi­da­bi­li­tà di tra­smis­sio­ne in­di­pen­den­te­men­te dalla tra­smis­sio­ne in sequenza, il de­sti­na­ta­rio conferma la ricezione di un Tran­smis­sion Sequence Number anche se ci sono lacune nella sequenza di tra­smis­sio­ne. Per as­si­cu­ra­re che la tra­smis­sio­ne non solo sia af­fi­da­bi­le, ma anche il più veloce possibile, l'SCTP utilizza algoritmi di controllo della con­ge­stio­ne simili a quelli del TCP, che regolano l'invio in modo che non si crei una con­ge­stio­ne di pacchetti e, di con­se­guen­za, un so­vrac­ca­ri­co dell'host.

L'SCTP consente di rag­grup­pa­re più messaggi in un unico pacchetto. In questo modo è possibile inviare una serie di in­for­ma­zio­ni di controllo e/o dati utente, chiamate chunk (in italiano pezzo) nello standard SCTP, sotto un'in­te­sta­zio­ne comune. Il mec­ca­ni­smo di chunk bundling è re­spon­sa­bi­le sia del rag­grup­pa­men­to che della scom­po­si­zio­ne del pacchetto completo sul lato de­sti­na­ta­rio.

Durante l'in­stau­ra­zio­ne della con­nes­sio­ne SCTP i due end point con­cor­da­no un tag di verifica che deve essere spe­ci­fi­ca­to nelle in­te­sta­zio­ni dei pacchetti inviati durante l'intero processo di tra­smis­sio­ne. Se uno dei partner di co­mu­ni­ca­zio­ne riceve un pacchetto senza questo in­di­ca­to­re, il pacchetto cor­ri­spon­den­te viene im­me­dia­ta­men­te rifiutato. In questo modo il pro­to­col­lo fornisce pro­te­zio­ne contro gli accessi non au­to­riz­za­ti e impedisce inoltre che i pacchetti di con­nes­sio­ne pre­ce­den­ti con­ti­nui­no ad essere ricevuti.

Per pro­teg­ge­re ul­te­rior­men­te i dati il mittente ha la pos­si­bi­li­tà di ag­giun­ge­re al­l'in­te­sta­zio­ne un checksum CRC32C. Il pro­to­col­lo fornisce un campo opzionale a 32 bit proprio a questo scopo.

Dal momento che l'SCTP supporta il mul­ti­ho­ming, gli utenti possono spe­ci­fi­ca­re un intero insieme di indirizzi di trasporto che possono essere uti­liz­za­ti come de­sti­na­zio­ni po­ten­zia­li per i pacchetti inviati. Se vengono elencati più indirizzi, il pro­to­col­lo utilizza di default il percorso del­l'in­di­riz­zo primario. Se questo non è di­spo­ni­bi­le, vengono se­le­zio­na­ti gli indirizzi al­ter­na­ti­vi per poter con­ti­nua­re la tra­smis­sio­ne senza in­ter­ru­zio­ni. Per fornire questo servizio lo Stream Control Tran­smis­sion Protocol ha im­ple­men­ta­to una funzione di gestione dei percorsi che utilizza le istru­zio­ni di indirizzo spe­ci­fi­ca­te. Questa funzione controlla inoltre la di­spo­ni­bi­li­tà di tutti i percorsi di indirizzo indicati, in­vian­do­vi re­go­lar­men­te co­sid­det­ti heartbeat (segnali di controllo).

Ci sono tre im­por­tan­ti so­mi­glian­ze tra il TCP e l'SCTP: entrambi i pro­to­col­li ri­chie­do­no una con­nes­sio­ne tra le parti in co­mu­ni­ca­zio­ne, for­ni­sco­no un mec­ca­ni­smo per il controllo della con­ge­stio­ne e rap­pre­sen­ta­no inoltre soluzioni af­fi­da­bi­li; tutti e due as­si­cu­ra­no quindi che i pacchetti arrivino al de­sti­na­ta­rio senza perdite. L'UDP non fornisce tale garanzia a causa della mancanza di messaggi di conferma, tuttavia evita al­l'ap­pli­ca­zio­ne utente di dover impostare i propri marcatori dei dati (per marcare i confini dei pacchetti), poiché non è orientato ai byte ma ai messaggi, un vantaggio offerto anche dall'SCTP.

Oltre a questa fles­si­bi­li­tà, che rende l'SCTP la soluzione ideale per i servizi di tra­smis­sio­ne vocale come VoIP (Voice over IP), il pro­to­col­lo si distingue anche per il supporto del mul­ti­strea­ming e mul­ti­ho­ming (tol­le­ran­za ai guasti invece di host al­ter­na­ti­vi), che non offrono né l'UDP né il TCP. Lo Stream Control Tran­smis­sion Protocol ga­ran­ti­sce inoltre, con la four-way handshake (incluso il cookie di au­ten­ti­ca­zio­ne) e il tag di verifica ob­bli­ga­to­rio nel­l'in­te­sta­zio­ne di ogni pacchetto inviato, il livello più alto di sicurezza di tutti e tre i pro­to­col­li di trasporto.