Perché SCTP non molto usato / nota

StackOverflow https://stackoverflow.com/questions/1171555

Domanda

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

Sommario: SCTP è un protocollo a livello di trasporto che è il messaggio-driven come UDP, ma affidabile come TCP. Ecco una breve introduzione da IBM DeveloperWorks .

Onestamente, non ho mai sentito parlare di SCTP prima. Non riesco a ricordare letto in tutti i libri di rete o di averne sentito parlare nelle classi che avevo preso. Lettura altre domande StackOverflow che cita SCTP suggerisce che non sono sola con questa mancanza di conoscenza.

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

È stato utile?

Soluzione

In effetti, SCTP è utilizzato soprattutto nella zona delle telecomunicazioni. Tradizionalmente, interruttori di telecomunicazioni usano SS7 ( Signalling System 7 No. ) per interconnettere diverse entità nella rete di telecomunicazioni . Per esempio - base di dati degli abbonati del provider di telecomunicazioni (HLR), con un interruttore (MSC), l'abbonato è collegato troppo (MSC)

.

L'area delle telecomunicazioni si sta muovendo per velocità più elevate e ambiente più raggiungibile. Uno di questi cambiamenti è quello di sostituire il protocollo SS7 da alcuni più elegante, veloce e flessibile protocollo IP-based.

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

La rete IP, al contrario, è aperto e non è affidabile, e delle telecomunicazioni non convertirà ad esso se non sarà gestire almeno il carico che gestisce SS7. Questo è il motivo per cui è stato sviluppato SCTP. Si cerca:

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

Le ultime versioni di Linux hanno già il supporto SCTP.

Altri suggerimenti

Abbiamo schierando SCTP in diverse applicazioni ora, e incontrato problema significativo con il supporto SCTP in vari router domestici. Semplicemente non gestiscono correttamente SCTP. Credo che questo sia principalmente un problema di prestazioni (la specifica del protocollo SCTP checksum richiede per l'intero pacchetti di essere ricalcolati e non solo per le intestazioni).

Come molti altri protocolli promettenti SCTP è tristemente morto in acqua fino a D-Link e Netgear corregge le loro caselle di NAT rotti.

SCTP richiede più di progettazione all'interno dell'applicazione per ottenere il miglior uso di esso. Ci sono più opzioni che TCP, l'API Sockets-come è venuto dopo, ed è giovane. Tuttavia penso la maggior parte delle persone che prendono il tempo per capirlo (e che conoscono le carenze di TCP) apprezzo - si tratta di un protocollo ben progettato che si basa sulle nostre ~ 30 anni di conoscenza del protocollo TCP e UDP

.

Uno degli aspetti che richiede una riflessione è quello di corsi d'acqua. Streams fornire (di solito, credo che è possibile disattivarlo) una garanzia ordine al loro interno (molto simile a una connessione TCP), ma non ci può essere più flussi per connessione SCTP. Se i dati della vostra applicazione possono essere inviati su più flussi quindi si evita di head-of-line blocco in cui il ricevitore affama a causa di un pacchetto smarrito. Effettivamente diverse conversazioni si possono avere sulla stessa connessione senza impattare l'altro.

Un'altra aggiunta utile è quella di supporto multi-homing - una connessione può essere attraverso interfacce multiple su entrambe le estremità e si fa fronte con errori. È possibile emulare questa in TCP, ma a livello di applicazione.

Una corretta collegamento heartbeating, che è la prima cosa che qualsiasi applicazione che utilizza il protocollo TCP per le connessioni attrezzi non transitori, è lì gratuitamente.

La mia sintesi personale di SCTP è che non fa nulla non si poteva fare in un altro modo (in TCP o UDP) con il supporto applicativo considerevole. La cosa che offre è la possibilità di non dover attuare tale codice (male) da soli.

Cordiali saluti, SCTP viene mandato come supportata per Diametro (cf RADIUS Next Gen). vedere RFC 3588 

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers MUST support both.  Future versions of this specification MAY
   mandate that clients support SCTP.

SCTP non è molto conosciuto e non utilizzati / schierato molto perché:

Molti di noi fare uso di SCTP presto, dal momento che è utilizzato da datachannels WebRTC per creare uno strato TCP-come affidabile su UDP - SCTP oltre DTLS su UDP: https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 # sezione-6

Lettura del href="http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol" rel="nofollow noreferrer"> pagina direi che il motivo principale è che è SCTP un giovanissimo protocollo (proposta nel 2000) che è attualmente supportato dal mainstream sistemi operativi ( di Windows , OS X , Linux ).

Se "molto giovani" sembra inadeguato a te, pensare a IPV6 : "nel mese di dicembre 2008, nonostante segnando il suo 10 ° anniversario come un protocollo standard traccia, IPv6 è stato solo nella sua infanzia in termini di diffusione generale in tutto il mondo ".

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

Potrebbe non essere ben noto, ma non è inutilizzata. Recentemente c'è stata una progetto pubblicato alla < a href = "http://www.ietf.org/" rel = "nofollow noreferrer"> IETF su Utilizzo SCTP come Transport layer protocollo HTTP .

Con riferimento a tutti i commenti su router commerciali essere rotto o manca il supporto SCTP, il problema è che SCTP con NAT è ancora in bozza con l'IETF. Quindi non v'è alcuna specifica RFC per loro di attuarla.

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

SCTP è nato troppo tardi, e per molti situazione TCP è sufficiente.

Inoltre, come so che la maggior parte del suo utilizzo è in settore delle telecomunicazioni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top