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.