Perché SCTP non è molto usato / conosciuto

Di recente ho controllato il libro "UNIX Network Programming, Vol. 1" di Richards Stevens e ho scoperto che esiste un terzo standard di livello di trasporto oltre a TCP e UDP: SCTP .

Riepilogo: SCTP è un protocollo a livello di trasporto basato su messaggi come UDP, ma affidabile come TCP. Ecco una breve introduzione da IBM DeveloperWorks .

Onestamente, non ho mai sentito parlare di SCTP prima. Non ricordo di averlo letto in nessun libro di rete o di averne sentito parlare durante le lezioni che avevo seguito. Leggere altre domande di StackOver che menzionano SCTP suggerisce che non sono solo con questa mancanza di conoscenza.

Perché SCTP è così sconosciuto? Perché non è molto usato?

Infatti, SCTP è utilizzato principalmente nell'area delle telecomunicazioni. Tradizionalmente, gli switch di telecomunicazione utilizzano SS7 ( Signaling System n. 7 ) per interconnettere diverse entità nella rete di telecomunicazione. Ad esempio: la base dati abbonati del provider di telecomunicazioni (HLR), con uno switch (MSC), anche l'abbonato è collegato (MSC).

L'area delle telecomunicazioni si sta spostando a velocità più elevate e in un ambiente più raggiungibile. Una di queste modifiche è quella di sostituire il protocollo SS7 con un protocollo basato su IP più elegante, veloce e flessibile.

L'area delle telecomunicazioni è molto conservatrice. La rete SS7 è stata utilizzata qui per decenni. È una rete molto affidabile e chiusa. Ciò significa che un utente normale non ha accesso ad esso.

La rete IP, al contrario, è aperta e non affidabile e le telecomunicazioni non si convertiranno ad essa se non gestirà almeno il carico che gestisce SS7. Ecco perché è stato sviluppato SCTP. Prova:

• imitare tutti i vantaggi della rete SS7 accumulata nel corso dei decenni.
• per creare un protocollo orientato alla connessione migliore di TCP in termini di velocità, sicurezza e ridondanza

Le ultime versioni di Linux dispongono già del supporto SCTP.

Abbiamo implementato SCTP in diverse applicazioni e abbiamo riscontrato problemi significativi con il supporto SCTP in vari router domestici. Semplicemente non gestiscono correttamente SCTP. Credo che questo sia principalmente un problema di prestazioni (le specifiche del protocollo SCTP richiedono che i checksum vengano ricalcolati per tutti i pacchetti e non solo per le intestazioni).

Come molti altri protocolli promettenti, SCTP è tristemente morto nell'acqua fino a quando D-link e Netgear riparano le loro scatole NAT rotte.

SCTP richiede una maggiore progettazione all'interno dell'applicazione per sfruttarla al meglio. Ci sono più opzioni di TCP, l'API simile a Socket è arrivata più tardi ed è giovane. Tuttavia, penso che la maggior parte delle persone che impiegano del tempo per capirlo (e che conoscono le carenze di TCP) lo apprezzino: è un protocollo ben progettato che si basa sui nostri ~ 30 anni di conoscenza di TCP e UDP.

Uno degli aspetti che richiede un pensiero è quello dei flussi. I flussi forniscono (di solito, penso che tu possa disattivarlo) una garanzia d'ordine al loro interno (molto simile a una connessione TCP) ma possono esserci più flussi per connessione SCTP. Se i dati dell'applicazione possono essere inviati su più flussi, si evita il blocco head-of-line in cui il ricevitore muore di fame a causa di un pacchetto smarrito. È possibile avere conversazioni effettivamente diverse sulla stessa connessione senza influire reciprocamente.

Un'altra utile aggiunta è quella del supporto multi-homing: una connessione può avvenire attraverso più interfacce su entrambe le estremità e può far fronte a guasti. Puoi emularlo in TCP, ma a livello di applicazione.

Il battito cardiaco corretto del collegamento, che è la prima cosa che qualsiasi applicazione che utilizza TCP per implementare connessioni non transitorie, è disponibile gratuitamente.

Il mio riepilogo personale di SCTP è che non fa nulla che tu non possa fare diversamente (in TCP o UDP) con un sostanziale supporto applicativo. La cosa che fornisce è la capacità di non dover implementare quel codice (male) da soli.

Cordiali saluti, SCTP è obbligatorio come supportato per Diametro (vedi RADIUS next gen). vedi RFC 3588

   I client di diametro DEVONO supportare TCP o SCTP, mentre agenti e
   i server DEVONO supportare entrambi. Versioni future di questa specifica MAGGIO
   mandato che i client supportano SCTP.

SCTP non è molto conosciuto e non utilizzato / distribuito molto perché:

• Diffuso: non ampiamente integrato negli stack TCP / IP (nel 2013: ancora mancante in modo nativo negli ultimi Mac OSX e Windows)
• Librerie: pochi collegamenti di alto livello in lingue facili da usare (Dichiarazione di non responsabilità: sono manutentore di pysctp , supporto dello stack facile SCTP per Python)
• NAT: non attraversa NAT molto bene / affatto (meno dell'1% di router Internet domestici e aziendali fanno NAT su SCTP).
• Popolarità: nessuna app pubblica lo usa
• Paradigma di programmazione: è cambiato un po ': è ancora un socket, ma è possibile collegare molti host a molti host (multihoming), il datagramma è ordinato e affidabile, erc ...
• Complessità: lo stack SCTP è complesso da implementare (a causa di quanto sopra)
• Concorrenza: il multipath TCP sta arrivando e dovrebbe rispondere alle esigenze / capacità del multihoming in modo che le persone si astengano dall'implementare SCTP, se possibile, aspettando MTCP
• Nicchia: i riempimenti SCTP necessari sono molto peculiari (datagrammi affidabili ordinati, multistream) e non necessari per molte applicazioni
• Sicurezza: SCTP elude i controlli di sicurezza (alcuni firewall, la maggior parte degli IDS, tutti i DLP, non appare su netstat tranne CentOS / Redhat / Fedora ...)
• Capacità di controllo: qualcosa come 3 aziende nel mondo eseguono regolarmente controlli di sicurezza SCTP (Dichiarazione di non responsabilità: lavoro in una di esse)
• Curva di apprendimento: non molta toolchain per giocare con SCTP (controlla l'eccellente withsctp che si combina bene con netcat o usa socat)
• Sotto il cofano: utilizzato principalmente nelle telecomunicazioni e ogni volta che invii SMS, inizi a navigare in rete sul tuo cellulare o fai chiamate telefoniche, stai spesso innescando messaggi che scorrono su SCTP (SIGTRAN / SS7 con GSM / UMTS, Diametro con LTE / IMS / RCS, S1AP / X2AP con LTE), quindi in realtà lo usi molto ma non lo sai mai ;-)

p1. SCTP mappato direttamente su IPv4 richiede il supporto nei gateway NAT, che non sono mai stati ampiamente implementati ovunque, e senza di esso il tipico gateway NAT consentirà a un solo host privato per indirizzo pubblico di utilizzare SCTP alla volta.

p2. SCTP mappato su UDP / IPv4 consente un numero maggiore di host privati ​​per indirizzo pubblico, ma i mapping UDP nei gateway IPv4 / NAT sono notoriamente difficili da stabilire e mantenere, poiché UDP è un trasporto senza connessione senza alcun stato esplicito per il tracciamento di un NAT .

p3. SCTP mappato direttamente su IPv6 richiede ... beh ... IPv6. Hai provato a distribuire IPv6? In tal caso, hai provato ad acquistare un firewall IPv6? Supporta SCTP? Che ne dici di un bilanciamento del carico? Un acceleratore SSL?

p4. Infine, gran parte di Internet è praticamente vincolata a ciò che può adattarsi attraverso la porta TCP 80 e la porta 443, quindi SCTP di qualsiasi sapore tende a perdere lì. Quindi, vedi sforzi come il gruppo di lavoro MPTCP nell'IETF .

Molti di noi useranno presto SCTP, poiché viene utilizzato dai canali di dati WebRTC per creare un livello affidabile simile a TCP sopra UDP - SCTP su DTLS su UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # sezione-6

Leggendo la pagina Wikipedia di SCTP direi che il motivo principale è che SCTP è un protocollo molto giovane (proposto nel 2000) che attualmente non è supportato dai sistemi operativi tradizionali ( Windows , OS X , Linux ).

Se "molto giovane" ti sembra inappropriato, pensa a IPV6 : "nel dicembre 2008, nonostante abbia celebrato il suo decimo anniversario come protocollo Standards Track, IPv6 era solo agli inizi in termini di diffusione generale in tutto il mondo".

SCTP è ampiamente utilizzato nella rete 4G LTE in cui il diametro è utilizzato per AAA.

Potrebbe non essere ben noto, ma non è inutilizzato. Poco tempo fa ci fu un progetto pubblicato alla IETF circa Utilizzando SCTP come strato di protocollo di trasporto per HTTP .

In riferimento a tutti i commenti sui router commerciali rotti o privi del supporto SCTP, il problema è che SCTP con NAT è ancora in bozza con l'IETF. Quindi non esiste alcuna specifica RFC per implementarla.

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

Sctp è nato troppo tardi e per molte situazioni il TCP è sufficiente.

Inoltre, come so la maggior parte del suo utilizzo è nell'area delle telecomunicazioni.