Discussione Differenza Protocolli e bitstream

BushidoBushido

Utente Iron
23 Aprile 2021
37
9
12
18
Salve a tutti!

Ho incontrato la sigla SCTP e informandomi ho visto è un protocollo similare al TCP (infatti ho letto tcp friendly). SCTP, ergo, si occupa di trasportare info su reti IP
A differenza del TCP instrada tutto in una sequenza di unità frammentate e non in un unico bitstream.
Domandina: cos'è un bitstream? ho provato a leggere online ma sinceramente non ho capito, anche su wikipedia sembra chiaro ma non riesco a capire il concetto davvero..
Se per favore potreste spiegarmi meglio il tutto, la differenza fra i due protocolli, in quali casi si usa uno o l'altro e qualsiasi altra informazione. Leggo volentieri !
 
A differenza del TCP instrada tutto in una sequenza di unità frammentate e non in un unico bitstream.
Vuol dire che SCTP è message-oriented (come UDP), non stream-oriented (come TCP).

In un protocollo stream-oriented i dati vengono spezzati in dei pacchetti a dimensione (più o meno) fissa e non c'è nessuna correlazione tra la dimensione del pacchetto e la dimensione di ciò che ti voglio inviare: inviano un flusso di dati (bitstream) e spetta all'applicazione raggrupparli e capire dove inizia/finisce un blocco di informazione. In un protocollo message-oriented l'header del pacchetto (o datagram) ha un campo size che contiene la dimensione del messaggio. Se ciò che voglio inviare è più grande della dimensione massima (e.g. UDP ha 16 bits nel campo data, quindi oltre 65535 bytes non si può andare) è l'applicazione che ha il compito spezzettare l'informazione in tanti messaggi.

Sembrano due concetti molto simili, perché se un pacchetto non è abbastanza in entrambi i casi ti ritroverai a formare uno stream, ma in un caso questo stream è implementato dal protocollo di trasporto (layer 4) mentre nell'altro caso la frammentazione è implementata dall'applicazione (layer 7). Se il protocollo è stream-oriented in un unico pacchetto possono arrivarti anche due frammenti di messaggi diversi, mentre nei message-oriented hai un meccanismo di separazione già a livello di trasporto.

Se per favore potreste spiegarmi meglio il tutto, la differenza fra i due protocolli, in quali casi si usa uno o l'altro e qualsiasi altra informazione. Leggo volentieri !
Non conosco SCTP. Leggendo su internet mi pare di aver capito che sia un protocollo message-oriented, affidabile e connection-oriented: preserva la struttura e l'ordine dei messaggi, ciò che si perde viene ritrasmesso e prima di scambiare messaggi (bidirezionalmente, full-duplex) bisogna instaurare un canale di comunicazione tra i due endpoints. È pensato per essere conveniente quando si vogliono inviare tanti messaggi di piccola dimensione (e.g., segnali di controllo, tipici in telecomunicazioni). Oltre a questa piccola overview non mi sento di scrivere: se hai una domanda specifica posso documentarmi anch'io e vediamo se in due ci capiamo qualcosa, ma rimanendo sul vago la mia non può che diventare una riesposizione di quello che probabilmente hai già letto su internet.
 
  • Mi piace
Reazioni: BushidoBushido
OK ! Per l'orientamento e la questione dei pacchetti ho capito, ti ringrazio

riguardo SCTP , invece, chiedo: se è affidabile e preserva ordine e struttura dei mes, e fa un check di ciò che non è stato inviato (come in TCP appunto) cosa condivide con UDP ? udp è per comunicazioni come live video streaming ecc, del tipo se mi perdo qualche pacchetto lo stream si capisce ugualmente e non sono dettagli fondamentali..Udp quindi Non verifica che ogni pacchetto sia arrivato e non rinvia. Mi sembra un ibrido questo SCTP dei due tcp/udp. Invia pacchetti piccoli e numerosi stile udp ma li controlla e mantiene la struttura come tcp

Guarda già con la tua risposta hai aggiunto informazioni extra; è il bello del confronto : si trovano sempre nuovi spunti/visioni per ampliare il proprio sapere!
 
UDP lo usi quando l'affidabilità è più un ostacolo che una convenienza. L'esempio classico è la trasmissione audio/video: se perdo qualche frame, preferisco disegnare il successivo e mantenere fluidità piuttosto che assicurarmi di disegnare ogni singolo frame anche a costo di bloccare il video. TCP lo usi quando l'affidabilità è indispensabile. Se devi inviare un file e ti perdi qualche pezzo per strada, dall'altra parte ricevono un file corrotto e potenzialmente inutilizzabile.

Il discordo di tanti/pochi pacchetti di grandi/piccole dimensioni è secondario: nella stragrande maggioranza dei casi l'affidabilità è il criterio principale che ti porta a scegliere se usare TCP o UDP.

Invia pacchetti piccoli e numerosi stile udp ma li controlla e mantiene la struttura come tcp
TCP non mantiene la struttura dei messaggi, è un protocollo stream-oriented: invia un flusso di bytes e poi sta all'applicazione (non al protocollo di trasporto) capire dov'è l'inizio e la fine. È UDP quello che, come SCTP, mantiene la struttura del messaggio. Un datagram UDP equivale a un messaggio e non può essere altrimenti visto che non preserva l'ordine. SCTP combina la message-orientation di UDP con l'affidabilità di TCP e viene utilizzato principalmente per inviare messaggi di controllo (i.e., informazioni che permettono di gestire la modalità di comunicazione).
Questo link contiene una tabella che confronta i tre protocolli.

Come detto prima, l'affidabilità è il criterio principale che ti porta a scegliere se usare TCP o UDP e nei messaggi di controllo hai bisogno di affidabilità, quindi se non ci fosse SCTP useresti TCP. Tuttavia, essendo TCP un protocollo stream-oriented, le applicazioni (layer 7) devono delineare l'inizio e la fine di ogni messaggio e non ti è permesso fare interleaving (i.e., inviare un po' di uno e un po' dell'altro) di due o più messaggi. I dati devono arrivarti in ordine anche se si riferiscono a due messaggi diversi, ma questo non è un requisito così importante per la tua applicazione. Per ovviare a queste limitazioni, che sono intrinseche nel protocollo TCP, o implementi l'affidabilità nel livello applicazione sopra a UDP oppure costruisci un protocollo di trasporto ad hoc. È per questo che è nato SCTP: inizialmente era domain-specific e si utilizzava principalmente in telecomunicazioni, adesso... io non so dirti se è diventato più popolare o se è rimasto un protocollo di nicchia. Sicuramente TCP e UDP sono di tutt'altro livello in termini di diffusione.
 
Il discordo di tanti/pochi pacchetti di grandi/piccole dimensioni è secondario: nella stragrande maggioranza dei casi l'affidabilità è il criterio principale che ti porta a scegliere se usare TCP o UDP.
Certo certo, a seconda dello scopo usi uno strumento diverso; fin qua siam d'accordo!



mhhh!! chiaro! credevo li inviasse in ordine TCP, e che li controllasse uno alla volta prima di passar al successivo. Quindi li invia random sebbene di eguali dimensioni.
TCP non mantiene la struttura dei messaggi
però mi sorge il dubbio su UDP: li invia quindi in ordine i pacchetti e non li ricontrolla, corretto?

p.s. tabella fantastica w IBM

per il resto molto chiaro, se hai dei testi (IDEALMENTE in italiano) ulteriori per approfondire me li vedo :)
Mi rimane infine un ultima domanda; essendo una fusione di UDP e TCP (a grandi linee) non converrebbe utilizzare questo modello rispetto ai piu diffusi TCP/UDP?

Inoltre vi sono tanti modelli come DCCP, SNA (ibm x reti bancarie), OSPF... perchè tutta questa diversità?
ti spiego la mia logica così puoi capire meglio cosa sto pensando : trovato un protocollo di trasporto Valido sicuro efficace potente ecc perchè non lo si utilizza su larga scala?
prendo come es NDP, che si usa solo in reti IPV6 o IGMP in reti IPV4.. perchè non trovare un modello comune da adottare? anche perchè così si può investire risorse nel perfezionamento di esso. è come dire trovo il modo migliore per ottenere un determinato risultato e lo diffondo e continuo. è errato il modo di pensare?

Perdonami della banalità delle mie domande, ma ho tantissimi banali dubbi. Piu sono semplici le cose piu mi fanno pensare =) E forse questa cosa così semplice non lo è visto il numero di domande che pongo..

grazie ancora ^^
 
Certo certo, a seconda dello scopo usi uno strumento diverso; fin qua siam d'accordo!

mhhh!! chiaro! credevo li inviasse in ordine TCP, e che li controllasse uno alla volta prima di passar al successivo. Quindi li invia random sebbene di eguali dimensioni.
Uhm... no, non è chiaro. Evidentemente non ci siamo capiti da qualche parte, perché non è quello che volevo dire.

La differenza principale tra TCP e UDP è che uno è l'affidabilità. Ci sono un altra sfilza di differenze (e.g., stream di bytes vs messaggi, connection-oriented vs connectionless, etc...), ma l'affidabilità è un fattore talmente tanto importante che nella maggior parte dei casi tutto il resto passa in secondo piano e scegli cosa utilizzare solo in base a questo fattore. Affidabilità vuol dire che se io ti invio un messaggio e tu non lo ricevi, io me ne accorgo e te lo rispedisco. Fin qui penso che sia tutto chiaro.

TCP è un protocollo stream-oriented. Questo vuol dire che se io ti invio tre messaggi A, B e C di dimensione diversa, tu ricevi 7 (numero sparato a caso) pacchetti pacchetti TCP ognuno dei quali contiene un pezzettino dei tre messaggi. Continuando a sparare numeri a caso: i primi due pacchetti contengono i pezzi di A, il terzo contiene assieme sia l'ultimo pezzo di A che il primo di B, fino al sesto ci sono i pezzi di B e il settimo contiene tutto C. Tu, che li ricevi, li vedi tutti appiccicati (un flusso di byte---bitstream o bytestream) e spetta a te capire dove inizia e finisce A, dove inizia e finisce B e dove inizia e finisce C. Essendo un protocollo stream-oriented affidabile, è indispensabile che i dati ti arrivano in ordine: se io ti invio un po' di A, un po' di B e poi ancora un po' di A, tu vai in confusione.

UDP è un protocollo message-oriented. Questo vuol dire che se, idealmente, per inviarti A, B e C io ti spedisco tre dataframe: il primo contiene il messaggio A, il secondo il messaggio B e il terzo il messaggio C. L'ordine di arrivo non è garantito, quindi tu potresti ricevere prima B, poi C e poi A, ma sono tre messaggi distinti e non mischi mai un pezzo di B con un pezzo di A. Molto conveniente. Se il messaggio è più grande della dimensione massima del dataframe (e.g., se A pesa 100 kilobytes) è l'applicazione che si deve preoccupare di spezzettarlo in chunks e ricostruirli dall'altra parte. Nel caso di UDP questo è particolarmente problematico visto che il protocollo non è affidabile.

SCTP è sia message-oriented che affidabile. Fa quello che fa UDP, ma non si perde pezzi per strada. In più, supporta l'interleaving dei messaggi: posso inviarti un pezzo di A, un pezzo di B, un pezzo di A, un pezzo di C, un pezzo di A, etc... è il protocollo di trasmissione che si occupa di ricostruire il puzzle.

Piccola parentesi che non c'entra niente con questo discorso: ti ricordo che i pacchetti/dataframe del layer 4 vengono inseriti nel payload del protocollo IP (layer 3), quindi un pacchetto TCP o UDP può spezzarsi in molti pacchetti IP.

Mi rimane infine un ultima domanda; essendo una fusione di UDP e TCP (a grandi linee) non converrebbe utilizzare questo modello rispetto ai piu diffusi TCP/UDP?
SCTP non è meglio di UDP e TCP, è semplicemente diverso e ha uno use-case diverso. Perché non viene utilizzato più frequentemente? Perché TCP e UDP sono dei mostri sacri e sono abbastanza buoni per la maggior parte dei casi. Se ti inventi il tuo protocollo di livello 4 (eg., Bushido Bushido Transport Protocol) dovrai sviluppare un modulo kernel per supportarlo e installarlo su tutti i tuoi devices. Tutto ciò che non è layer 7 non è pensato per essere toccato facilmente. SCTP esiste già, quindi sei libero di utilizzarlo quando vuoi, ma è stato pensato per essere utilizzato per trasmettere segnali di controllo in telecomunicazioni: se lo usi per quello va alla grande, se lo usi per altro potrebbe andare molto peggio di UDP/TCP.

ho trovato un protocollo di trasporto Valido sicuro efficace potente ecc perchè non lo si utilizza su larga scala?
Ne abbiamo trovati due di protocolli di trasporto molto validi. Uno si chiama TCP ed è molto buono quando hai bisogno di non perdere informazioni (e.g., inviare files), l'altro si chiama UDP ed è molto buono quando hai bisogno di basso delay (e.g., video streaming). L'altra sfilza di protocolli che trovi in uno dei link che ho postato nei messaggi in precedenza serve per ottimizzare la trasmissione in use-cases specifici.

Inoltre vi sono tanti modelli come DCCP, SNA (ibm x reti bancarie), OSPF... perchè tutta questa diversità?
DCCP è layer 4, OSPF è layer 3, SNA è proprio uno stack completo (tipo ISO/OSI). Questi tre che hai elencato sono proprio tre cose diverse che servono a fare cose diverse, ma se generalmente vuoi sapere perché ci sono tanti protocolli di pari livello... beh, hanno use case diversi:
  • nel layer 7 abbiamo HTTP che serve per le pagine web, IRC che serve per le chat, etc...
  • nel layer 4 abbiamo TCP che serve per non perdere dati, UDP che serve per bassa latenza, ecc...
  • nel layer 3 abbiamo IP che serve per internet, OSPF che serve fare routing, etc...
  • nel layer 2 abbiamo ARP che fa address resolution, VLAN che crea reti virtuali, etc...
  • nel layer 1 abbiamo ethernet che vuole il cavo, WiFi che va con onde radio, etc...
Ce ne sono tanti, perché ci sono tante cose diverse che possiamo fare. Non è che possiamo dire: usiamo solo la fibra ottica e chi vuole navigare con lo smartphone compra un cavo bello lungo e sta attento che nessuno lo calpesti. Nel caso di SCTP vs TCP e UDP mi rendo conto che il discorso è meno ovvio, ma anche lì: video streaming su SCTP andrebbe peggio che in UDP e file sharing su SCTP andrebbe peggio che in TCP; è stato per risolvere un problema diverso.

prendo come es NDP, che si usa solo in reti IPV6 o IGMP in reti IPV4.. perchè non trovare un modello comune da adottare?
Se scendi abbastanza in giù con i layer c'è anche il problema della difficoltà di adozione e costi. La fibra ottica è meglio del rame, ma non puoi pretendere che l'intero pianeta passi alla fibra ottica nel giro di poco. Se io ti propongo la fibra ottica plus che è leggermente meglio della fibra ottica, sei disposto a buttare via tutto il tuo impianto in fibra ottica per utilizzare la mia? Se è significativamente meglio magari sei ben disposto a fare questo investimento, altrimenti lasci perdere. IPv6 è da 20 anni che prova a ingranare, ma non è affatto semplice.
 
Innanzi tutto grazie del tempo , maestro muten :)
(così era il nome??)


La differenza principale tra TCP e UDP è che uno è l'affidabilità. Ci sono un altra sfilza di differenze (e.g., stream di bytes vs messaggi, connection-oriented vs connectionless, etc...), ma l'affidabilità è un fattore talmente tanto importante che nella maggior parte dei casi tutto il resto passa in secondo piano e scegli cosa utilizzare solo in base a questo fattore. Affidabilità vuol dire che se io ti invio un messaggio e tu non lo ricevi, io me ne accorgo e te lo rispedisco. Fin qui penso che sia tutto chiaro.
Questa era la parte facile =P


SCTP è sia message-oriented che affidabile. Fa quello che fa UDP, ma non si perde pezzi per strada. In più, supporta l'interleaving dei messaggi: posso inviarti un pezzo di A, un pezzo di B, un pezzo di A, un pezzo di C, un pezzo di A, etc... è il protocollo di trasmissione che si occupa di ricostruire il puzzle.
fighissimo l'interleaving. questo mondo mi stupisce di continuo


Tutto ciò che non è layer 7 non è pensato per essere toccato facilmente.
...domanda forse da true ignorant person ma... perchè? ho visto il modello iso/osi ma non l'ho interiorizzato a pieno ancora, ergo ho ancora dubbi sui livelli

SCTP esiste già, quindi sei libero di utilizzarlo quando vuoi, ma è stato pensato per essere utilizzato per trasmettere segnali di controllo in telecomunicazioni: se lo usi per quello va alla grande, se lo usi per altro potrebbe andare molto peggio di UDP/TCP.
Ok, come dicevi sopra udp e tcp son già belli svezzati utilizzati ecc e han funzioni differenti, ma, mi chiedo: non si è ancora sviluppato un modello per ovviare ai difetti di tcp e di udp in altri ambiti -non segnali di controllo in telecomunicazioni(tipo il ping?)- ?





Riguardo il mod ISO/OSI hai da farmi leggere qualcosa di valido? se hai qualche link dove si approfondisce gradualmente ogni livello me lo leggo. Ho trovato in rete molti moltissimi esempi, ma come antecedentemente detto, non ho capito a pieno, infatti ho dubbi e insicurezze a riguardo ancora! Magari trovo un testo che trova le parole giuste per farmi comprendere tutto a fondo! =)




IPv6 è da 20 anni che prova a ingranare, ma non è affatto semplice.
perchè?

(riguardo la fibra, io stesso l'ho montata tardissimo rispetto a quando era uscita per dire)
 
perchè (n d.r., tutto ciò che non è layer 7 non è pensato per essere toccato facilmente)? ho visto il modello iso/osi ma non l'ho interiorizzato a pieno ancora, ergo ho ancora dubbi sui livelli
Stando al modello ISO/OSI, visto che gerarchico, è tutto intercambiabile facilmente... il problema è che dall'1 al 3 il supporto hardware è importante e aggiornare l'hardware non è gratis. IPv6 fatica a prendere piede perché hai bisogno di router nuovi (non solo a casa tua, ma su tutta la rete internet); te lo deve fornire il tuo internet provider e se non c'è un vantaggio economico allora non c'è nemmeno fretta ad aggiornare le infrastrutture. A livello 4 la situazione è già più malleabile, ma devi comunque scrivere codice kernel. Se da una parte c'è nuovo è meglio, dall'altra parte c'è quello che stiamo già usando è good enough: la gente è restia ai cambiamenti non indispensabili, soprattutto se bisogna tirare fuori soldi.

Riguardo il mod ISO/OSI hai da farmi leggere qualcosa di valido?
Credo che ci sia anche qualche guida in giro per il forum (e.g., 1, 2), prova a usare il tasto cerca. Per il resto io non ho niente di particolare da consigliarti... dovrei cercare su google, ma a questo punto lo puoi fare tu stesso. Se poi hai domande, sentiti libero di aprire un thread per chiedere spiegazioni.
 
Perfetto! Grazie dell' attenzione allora, mi vedo i due link in forum inforge, e poi cerco nuove info su google
chiedo, perchè a volte le cose migliori si trovano in posti di cui non sai l'esistenza o perlomeno ove non sai bene cercare.. google è grande quanto dispersivo!