Qual è la differenza tra flussi e datagrammi nella programmazione di rete?

Question

Qual è la differenza tra socket (stream) vs socket (datagrammi)? Perché usarne uno sull'altro?

Answer 1

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 attribuire credibilità all'autore dell'idea, ma ho anche aggiunto molte delle mie conoscenze all'analogia principale. Ecco qui:

Una presa di streaming è come una telefonata: un lato mette la chiamata, l'altro risponde, tu saluti l'uno con l'altro (SYN/ACK in TCP), e poi scambi informazioni. Una volta che hai finito, dici addio (FIN/ACK in TCP). Se un lato non sente un addio, di solito chiamerà l'altro indietro poiché questo è un evento inaspettato; di solito il client si riconnetterà al server. È garantito che i dati non arriveranno in un ordine diverso da quello in cui sono stati inviati e vi è 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 arrivare a destinazione e potrebbe essere modificato dal momento in cui arriva. Se passi due note alla stessa persona, possono arrivare in un ordine che non intendevi, poiché il percorso che le note portano attraverso l'aula potrebbe non essere lo stesso, una persona potrebbe non passare una nota veloce come un'altra, ecc.

Così si utilizza una presa di corrente quando avere informazioni in ordine e intatto è importante. I protocolli di trasferimento file sono un buon esempio qui. Non vuoi scaricare alcun file con il suo contenuto mescolato e danneggiato casualmente!

devi usare un datagram socket quando l'ordine è meno importante la puntualità nella consegna (si pensi VoIP o protocolli di gioco), quando non si desidera che la più alta testa di un flusso (questo è il motivo per cui DNS è principalmente un protocollo datagram, 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 sua destinazione.

Per espandere il caso VoIP/gioco, tali protocolli includono il proprio meccanismo di ordinazione dei dati. Ma se un pacchetto è danneggiato o perso, non si desidera attendere il protocollo del flusso (di solito TCP) per inviare una richiesta di ritrasmissione - è necessario recuperare rapidamente. TCP può richiedere un certo numero di minuti per il ripristino e per i protocolli in tempo reale come i giochi o il VoIP anche tre secondi potrebbero essere inaccettabili! L'utilizzo di un protocollo datagramma come UDP consente al software di recuperare da un tale evento estremamente rapidamente, semplicemente ignorando i dati persi o ri-richiedendolo prima di quanto farebbe TCP.

VoIP è un buon candidato per ignorare semplicemente i dati persi - una parte sarebbe solo ascoltare un breve scarto, simile a quanto accade quando si parla con qualcuno al cellulare quando hanno scarsa ricezione. I protocolli di gioco sono spesso un po 'più complessi, ma le azioni intraprese saranno solitamente ignorare i dati mancanti (se i dati ricevuti successivamente superano i dati persi), richiedere nuovamente i dati mancanti o richiedere un aggiornamento completo dello stato a assicurarsi che lo stato del client sia sincronizzato con quello del server.

Answer 2

flusso Socket:

• Dedicato & point-to-point canale tra server e client.
• Utilizzare il protocollo TCP per la trasmissione dei dati.
• Affidabile e senza perdita di dati.
• Dati inviati/ricevuti nello stesso ordine.
• Molto tempo per il recupero persi/dati errati

Datagram Socket:

• No dedicato canale & point-to-point tra server e client.
• Utilizzare UDP per la trasmissione dei dati.
• Non affidabile al 100% e potrebbe perdere dati.
• dati inviati/ricevuti fine potrebbe non essere la stessa
• non si cura o un rapido recupero dei dati errati