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


Risposte:


304

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.


3
Semplicemente fantastico per aver incluso i dettagli di SYNACK.
LazerSharks,

2
Questo esempio, o molto simile, è tratto da The Linux Programming Interface. L'edizione 2010 contiene questi esempi alle pagine 1155 e 1159.
Josh,

30

Socket Stream:

  • Canale dedicato e end-to-end tra server e client.
  • Utilizzare il protocollo TCP per la trasmissione dei dati.
  • Affidabile e senza perdite.
  • Dati inviati / ricevuti nell'ordine simile.
  • Molto tempo per il recupero di dati persi / errati

Presa datagramma:

  • Canale non dedicato e end-to-end tra server e client.
  • Usa UDP per la trasmissione dei dati.
  • Non affidabile al 100% e potrebbe perdere dati.
  • L'ordine dei dati inviati / ricevuti potrebbe non essere lo stesso.
  • Non preoccuparti o recuperare rapidamente i dati persi / errati.

I dati non vengono inviati nello stesso ordine (non solo "simili")? vale a dire. non avrebbe senso costruire un meccanismo di ordinamento dei pacchetti in un socket stream
Matthew D. Scholefield,

I pacchetti in una comunicazione di flusso vengono inviati e ricevuti in ordine "simile", nel senso che NON si garantisce che i pacchetti stessi vengano consegnati all'host ricevente in ordine, ma TCP individua le discrepanze, riorganizzando i pacchetti all'arrivo e richiedendo qualsiasi cosa che sembra essersi perso lungo la strada.
Alejandro Blasco,

Questo ha senso. Forse basta rimuoverlo come differenza e metterlo sotto (poiché se lo sto capendo correttamente, quando mi riferisco solo all'ordine a cui vengono inviati i pacchetti, in entrambi i casi l'ordine in cui i dati vengono inviati / ricevuti potrebbe non essere lo stesso).
Matthew D. Scholefield,

@Rick Più precisamente, i socket sono noti come punti end-to-end perché i protocolli di trasporto sono responsabili della consegna dei messaggi a uno o più endpoint di rete.
Alejandro Blasco,

0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.