Risposte:
Molto tempo fa ho letto una grande analogia per spiegare la differenza tra i due. Non ricordo dove l'ho letto, quindi sfortunatamente non posso dare credito all'autore per l'idea, ma ho comunque aggiunto molte delle mie conoscenze all'analogia di base. Quindi ecco qui:
Un socket di flusso è come una telefonata: un lato posiziona la chiamata, l'altro risponde, si salutano l'un l'altro (SYN / ACK in TCP) e quindi si scambiano informazioni. Una volta terminato, saluti (FIN / ACK in TCP). Se una parte non ascolta un addio, di solito richiamano l'altra poiché si tratta di un evento imprevisto; di solito il client si riconnetterà al server. C'è una garanzia che i dati non arriveranno in un ordine diverso da quello che hai inviato, e c'è una ragionevole garanzia che i dati non saranno danneggiati.
Un socket di datagramma è come passare una nota in classe. Considera il caso in cui non sei direttamente accanto alla persona a cui stai passando la nota; la nota viaggerà da persona a persona. Potrebbe non raggiungere la sua destinazione e potrebbe essere modificata dal momento in cui ci arriva. Se passi due note alla stessa persona, potrebbero arrivare in un ordine che non avevi previsto, poiché il percorso che le note prendono in classe potrebbe non essere lo stesso, una persona potrebbe non passare una nota più velocemente di un'altra, ecc. .
Quindi usi un socket di flusso quando avere informazioni in ordine e intatte è importante. I protocolli di trasferimento file sono un buon esempio qui. Non vuoi scaricare alcun file con i suoi contenuti mescolati casualmente e danneggiati!
Utilizzeresti un socket per datagramma quando l'ordine è meno importante della consegna puntuale (pensa ai protocolli VoIP o di gioco), quando non desideri il sovraccarico maggiore di uno stream (ecco perché il DNS è principalmente un protocollo datagramma, in modo che i server possano rispondere a molte, molte richieste contemporaneamente molto rapidamente) o quando non ti interessa troppo se i dati raggiungono mai la loro destinazione.
Per espandere il caso VoIP / gioco, tali protocolli includono il proprio meccanismo di ordinazione dei dati. Ma se un pacchetto viene danneggiato o perso, non si desidera attendere che il protocollo di flusso (in genere TCP) emetta una richiesta di reinvio, ma è necessario ripristinarlo rapidamente. Il ripristino del TCP può richiedere alcuni minuti e, per protocolli in tempo reale come giochi o VoIP, anche tre secondi potrebbero essere inaccettabili! L'uso di un protocollo datagram come UDP consente al software di recuperare da un evento del genere in modo estremamente rapido, semplicemente ignorando i dati persi o richiedendoli prima di TCP.
Il VoIP è un buon candidato per semplicemente ignorare i dati persi: una parte sentirà solo un piccolo divario, simile a quello che succede quando si parla con qualcuno al cellulare quando la ricezione è scarsa. I protocolli di gioco sono spesso un po 'più complessi, ma le azioni intraprese saranno di solito ignorare i dati mancanti (se i dati ricevuti successivamente sostituiscono i dati persi), richiedere nuovamente i dati mancanti o richiedere un aggiornamento completo dello stato per assicurarsi che lo stato del client sia sincronizzato con quello del server.
Socket Stream:
Presa datagramma:
Se è la programmazione di rete penso che partire da socket sarebbe un buon inizio.
socket = ip + port
ci sono tre tipi di
stream di socket (TCP, ordine e consegna garantiti, nessuna duplicazione, nessuna lunghezza o limite di caratteri per dati, orientato alla connessione, affidabile, concorrenza)
datagramma (UDP, basato su pacchetti, senza connessione, datagramma limite di dimensione, i dati possono essere persi o duplicati, ordine non garantito, non affidabile)
raw (accesso diretto ai protocolli di livello inferiore IP, ICMP)
Non vedo alcuna regola rigida per il tipo di protocollo di trasporto su quale socket deve usare quale protocollo di trasporto e l'affidabilità non dovrebbe essere confusa perché UDP è realizzabile nel caso in cui entrambe le estremità siano attive.
L'affidabilità si riferisce più all'affidabilità della consegna poiché ci sono controlli del numero di sequenza usando TCP come protocollo di trasporto che non esiste in UDP. È meglio usare l'analizzatore di protocollo di rete come WireShark tcpdump ecc per vedere cosa sta facendo esattamente il tuo software; tipo di verifica o fusione della teoria sulla carta con il tuo lavoro in azione.