TCP vs UDP sul flusso video

Sono appena tornato a casa dal mio esame di programmazione di rete e una delle domande che ci hanno posto è stata "Se hai intenzione di trasmettere video in streaming, useresti TCP o UDP? Fornisci una spiegazione sia per i video memorizzati che per i flussi video live" . A questa domanda si aspettavano semplicemente una breve risposta di TCP per il video memorizzato e UDP per il video live, ma ci ho pensato mentre tornavo a casa, ed è necessariamente meglio usare UDP per lo streaming di video live? Voglio dire, se hai la larghezza di banda per farlo e dici che stai trasmettendo in streaming una partita di calcio, o un concerto per quella materia, hai davvero bisogno di usare UDP?

Diciamo che mentre stai trasmettendo questo concerto o qualsiasi altra cosa usando TCP inizi a perdere pacchetti (è successo qualcosa di brutto in qualche rete tra te e il mittente) e per un minuto intero non ricevi pacchetti. Il flusso video si interromperà e dopo che il minuto è trascorso, i pacchetti ricominceranno a passare (IP ha trovato un nuovo percorso per te). Ciò che accadrebbe è che TCP ritrasmetterà il minuto perso e continuerà a inviarti il ​​live streaming. Come presupposto, la larghezza di banda è superiore al bit-rate sullo stream e il ping non è troppo alto, quindi in un breve lasso di tempo, il minuto perso fungerà da buffer per lo stream per te, in questo modo , se la perdita di pacchetti si verifica di nuovo, non te ne accorgerai.

Ora, mi viene in mente alcuni apparecchi in cui questo non sarebbe una buona idea, come ad esempio video-conferenze, in cui è necessario essere sempre alla fine del flusso, perché ritardo durante una video-chat è semplicemente orribile, ma durante una partita di calcio o un concerto che importa se sei un minuto dietro la corrente? Inoltre, hai la garanzia di ottenere tutti i dati e sarebbe meglio salvarli per una visione successiva quando arriveranno senza errori.

Quindi questo mi porta alla mia domanda. Ci sono degli svantaggi che non conosco nell'utilizzo di TCP per lo streaming live? O dovrebbe davvero essere, che se hai la larghezza di banda per farlo dovresti scegliere TCP dato che è "più bello" per la rete (controllo di flusso)?

Svantaggi dell'utilizzo di TCP per video live:

1. In genere, le appliance di streaming video live non sono progettate pensando allo streaming TCP. Se si utilizza TCP, il sistema operativo deve eseguire il buffer dei segmenti non riconosciuti per ogni client. Ciò è indesiderabile, in particolare nel caso di eventi dal vivo; presumibilmente il tuo elenco di clienti simultanei è lungo a causa della singolarità dell'evento. I video-cast preregistrati in genere non hanno un grosso problema con questo perché gli spettatori scaglionano la loro attività di riproduzione; pertanto TCP è più appropriato per riprodurre un video su richiesta.
2. Il multicast IP riduce significativamente i requisiti di larghezza di banda video per un vasto pubblico; TCP impedisce l'uso di IP multicast, ma UDP è adatto per IP multicast.
3. Il video in diretta è normalmente un flusso a larghezza di banda costante registrato da una telecamera; i flussi video preregistrati provengono da un disco. Le dinamiche di loss-backoff del TCP rendono più difficile offrire video dal vivo quando i flussi di origine sono a una larghezza di banda costante (come accadrebbe per un evento dal vivo). Se esegui il buffer su disco da una telecamera, assicurati di disporre di buffer sufficiente per eventi di rete imprevedibili e velocità di invio / backoff TCP variabili. UDP ti dà molto più controllo per questa applicazione poiché UDP non si preoccupa delle cadute del livello di trasporto di rete.

Cordiali saluti, per favore non usare la parola "pacchetti" per descrivere le reti. Le reti inviano "pacchetti".

ma durante una partita di calcio o un concerto che importa se sei un minuto dietro la corrente?

Per alcuni tifosi di calcio, un bel po '. È stato notato che i ritardi anche di pochi secondi presenti nei flussi video digitali dovuti alla codifica (o altro) possono essere molto fastidiosi quando, durante eventi di alto profilo come le partite di coppa del mondo, puoi sentire gli applausi ei gemiti dei ragazzi della porta accanto (che stanno guardando un programma analogico immeritato) prima di vedere le mosse del gioco che li hanno causati.

Penso che per qualcuno che si preoccupa molto dello sport (e quelli sono il più grande gruppo di clienti paganti per la TV digitale, almeno qui in Germania), essere indietro di un minuto in uno streaming video in diretta sarebbe completamente inaccettabile (come in, loro " d passare al tuo concorrente dove ciò non accade).

Di solito un flusso video è in qualche modo tollerante ai guasti. Quindi, se alcuni pacchetti si perdono (a causa del sovraccarico di alcuni router lungo il percorso, ad esempio), sarà comunque in grado di visualizzare il contenuto, ma con una qualità ridotta.

Se il tuo live streaming utilizzava TCP / IP, sarebbe stato costretto ad attendere quei pacchetti rilasciati prima di poter continuare a elaborare i dati più recenti.

È doppiamente negativo:

• i vecchi dati vengono ritrasmessi (probabilmente per un frame che era già visualizzato e quindi inutile) e
• i nuovi dati non possono arrivare fino a quando i vecchi dati non sono stati ritrasmessi

Se il tuo obiettivo è visualizzare le informazioni più aggiornate possibile (e per un live streaming di solito vuoi essere aggiornato, anche se i tuoi frame sembrano un po 'peggiori), allora TCP funzionerà contro di te.

Per uno stream registrato la situazione è leggermente diversa: probabilmente eseguirai il buffering molto di più (forse diversi minuti!) E preferiresti che i dati fossero ritrasmessi piuttosto che avere alcuni artefatti dovuti a pacchetti persi. In questo caso TCP è una buona corrispondenza (questo potrebbe ancora essere implementato in UDP, ovviamente, ma TCP non ha tanti svantaggi come nel caso del live streaming).

Ci sono alcuni casi d'uso adatti al trasporto UDP e altri adatti al trasporto TCP.

Il caso d'uso determina anche le impostazioni di codifica per il video. Quando si trasmette una partita di calcio, l'attenzione è sulla qualità e per le videoconferenze l'attenzione è sulla latenza.

Quando si utilizza il multicast per fornire video ai clienti, viene utilizzato UDP.

Il requisito per il multicast è un costoso hardware di rete tra il server di trasmissione e il cliente. In pratica questo significa che se la tua azienda possiede un'infrastruttura di rete puoi usare UDP e multicast per lo streaming video live. Anche in questo caso viene implementata anche la qualità del servizio per contrassegnare i pacchetti video e assegnare loro la priorità in modo che non si verifichino perdite di pacchetti.

Il multicast semplificherà il software di trasmissione perché l'hardware di rete gestirà la distribuzione dei pacchetti ai clienti. I clienti si iscrivono ai canali multicast e la rete si riconfigurerà per instradare i pacchetti al nuovo abbonato. Per impostazione predefinita, tutti i canali sono disponibili per tutti i clienti e possono essere instradati in modo ottimale.

Questo flusso di lavoro pone difficoltà nel processo di autorizzazione. L'hardware di rete non distingue gli utenti iscritti da altri utenti. La soluzione all'autorizzazione consiste nella crittografia dei contenuti video e nell'abilitazione della decrittografia nel software del lettore quando l'abbonamento è valido.

Il flusso di lavoro unicast (TCP) consente al server di controllare le credenziali del client e consente solo sottoscrizioni valide. Consenti anche solo un certo numero di connessioni simultanee.

Il multicast non è abilitato su Internet.

Per la distribuzione di video su Internet è necessario utilizzare TCP. Quando viene utilizzato UDP, gli sviluppatori finiscono per reimplementare la ritrasmissione dei pacchetti, ad es. Protocollo live p2p bittorrent.

"Se si utilizza TCP, il sistema operativo deve bufferizzare i segmenti non riconosciuti per ogni client. Ciò è indesiderabile, in particolare nel caso di eventi live".

Questo buffer deve esistere in qualche forma. Lo stesso vale per il jitter buffer sul lato del giocatore. Si chiama "buffer socket" e il software del server può sapere quando questo buffer è pieno e scartare i fotogrammi video appropriati per i flussi live. È preferibile utilizzare il metodo unicast / TCP perché il software del server può implementare una logica di eliminazione dei frame appropriata. I pacchetti mancanti casuali nel caso UDP creeranno solo una cattiva esperienza utente. come in questo video: http://tinypic.com/r/2qn89xz/9

"Il multicast IP riduce notevolmente i requisiti di larghezza di banda video per un vasto pubblico"

Questo è vero per le reti private, Multicast non è abilitato su Internet.

"Nota che se TCP perde troppi pacchetti, la connessione muore; quindi, UDP ti dà molto più controllo per questa applicazione poiché UDP non si preoccupa delle cadute del livello di trasporto di rete."

UDP inoltre non si preoccupa di eliminare interi frame o gruppi di frame, quindi non dà più controllo sull'esperienza dell'utente.

"Di solito uno stream video è in qualche modo tollerante ai guasti"

Il video codificato non è a tolleranza di errore. Quando viene trasmesso su un trasporto inaffidabile, la correzione degli errori di inoltro viene aggiunta al contenitore video. Un buon esempio è il contenitore MPEG-TS utilizzato nelle trasmissioni video satellitari che trasportano diversi flussi audio, video, EPG, ecc. Ciò è necessario in quanto il collegamento satellitare non è una comunicazione duplex, il che significa che il ricevitore non può richiedere la ritrasmissione dei pacchetti persi.

Quando è disponibile la comunicazione duplex, è sempre meglio ritrasmettere i dati solo ai client con perdita di pacchetti, quindi includere l'overhead della correzione degli errori di inoltro nel flusso inviato a tutti i client.

In ogni caso i pacchetti persi sono inaccettabili. I frame persi vanno bene in casi eccezionali quando la larghezza di banda è ostacolata.

Il risultato dei pacchetti mancanti sono artefatti come questo:

Alcuni decoder possono interrompersi sui flussi mancanti di pacchetti in punti critici.

Ti consiglio di dare un'occhiata al nuovo protocollo live p2p Bittorent Live .

Per quanto riguarda lo streaming è meglio usare UDP, innanzitutto perché abbassa il carico sui server, ma soprattutto perché puoi inviare pacchetti con multicast, è più semplice che inviarlo a ogni client connesso.

Dipende. Quanto è critico il contenuto che stai trasmettendo in streaming? Se critico usa TCP. Ciò potrebbe causare problemi di larghezza di banda, qualità video (potrebbe essere necessario utilizzare una qualità inferiore per gestire la latenza) e latenza. Ma se hai bisogno che il contenuto ti garantisca di arrivarci, usalo.

Altrimenti UDP dovrebbe andare bene se il flusso non è critico e sarebbe preferito perché UDP tende ad avere meno overhead.

Uno dei maggiori problemi con la distribuzione di eventi live su Internet è la "scalabilità" e il TCP non si adatta bene. Ad esempio, quando trasmetti una partita di calcio dal vivo, invece di una riproduzione di film su richiesta, il numero di persone che guardano può facilmente essere 1000 volte maggiore. In uno scenario del genere, l'utilizzo del TCP è una condanna a morte per i CDN (reti di distribuzione dei contenuti).

Ci sono un paio di ragioni principali per cui TCP non si adatta bene:

1. Uno dei maggiori compromessi del TCP è la variabilità del throughput ottenibile tra il mittente e il destinatario. Durante lo streaming di video su Internet, i pacchetti video devono attraversare più router su Internet, ciascuno di questi router è connesso con connessioni a velocità diverse. L'algoritmo TCP inizia con la finestra TCP ridotta, quindi cresce finché non viene rilevata la perdita di pacchetti, la perdita di pacchetti è considerata un segno di congestione e TCP risponde riducendo drasticamente la dimensione della finestra per evitare la congestione. Quindi a sua volta riducendo immediatamente il rendimento effettivo. Ora immagina una rete con trasmissione TCP che utilizza 6-7 salti di router al client (uno scenario molto normale), se uno qualsiasi dei router intermedi perde un pacchetto, il TCP per quel collegamento ridurrà la velocità di trasmissione. In effetti, il flusso di traffico tra i router segue una forma a clessidra; gong sempre su e giù tra uno dei router intermedi. Il rendering del throughput effettivo è molto inferiore rispetto all'UDP con il massimo impegno.

2. Come forse già saprai, TCP è un protocollo basato sul riconoscimento. Ad esempio, diciamo che un mittente è a 50 ms di distanza (cioè latenza tra due punti). Ciò significherebbe che il tempo necessario per inviare un pacchetto a un ricevitore e il ricevitore per inviare un riconoscimento sarebbe di 100 ms; quindi il throughput massimo possibile rispetto alla trasmissione basata su UDP è già dimezzato.

3. Il TCP non supporta il multicasting o il nuovo standard emergente di multicasting AMT. Ciò significa che i CDN non hanno l'opportunità di ridurre il traffico di rete replicando i pacchetti quando molti client guardano lo stesso contenuto. Già questo è un motivo sufficiente per i CDN (come Akamai o Level3) per non utilizzare TCP per i live streaming.

Durante la lettura del dibattito su TCP UDP ho notato un difetto logico. Una perdita di pacchetti TCP che causa un ritardo di un minuto convertito in un buffer di un minuto non può essere correlata a UDP che perde un minuto intero mentre si verifica la stessa perdita. Un confronto più equo è il seguente.

TCP subisce una perdita di pacchetti. Il video viene interrotto mentre TCP invia nuovamente i pacchetti nel tentativo di trasmettere in streaming pacchetti matematicamente perfetti. Il video viene ritardato di un minuto e riprende da dove era stato interrotto dopo che il pacchetto mancante è arrivato a destinazione. Aspettiamo tutti ma sappiamo che non perderemo un singolo pixel.

UDP subisce una perdita di pacchetti. Per un secondo durante il flusso video un angolo dello schermo diventa un po 'sfocato. Nessuno se ne accorge e lo spettacolo va avanti senza cercare i pacchetti persi.

Tutto ciò che trasmette ottiene i maggiori vantaggi da UDP. La perdita di pacchetti che causa un ritardo di un minuto su TCP non causa un ritardo di un minuto su UDP. Considerando che la maggior parte dei sistemi utilizza più flussi di risoluzione che rendono le cose a blocchi quando si muore di fame per i pacchetti, ha ancora più senso usare UDP.

UDP FTW durante lo streaming.

Se la larghezza di banda è molto superiore al bitrate, consiglierei TCP per lo streaming video live unicast.

Caso 1: i pacchetti consecutivi vengono persi per una durata di diversi secondi. => il video live si fermerà sul lato client qualunque sia il livello di trasporto (TCP o UDP). Quando la rete viene ripristinata: - se viene utilizzato TCP, il lettore video client può scegliere di riavviare lo streaming al primo pacchetto perso (timeshift) O di eliminare tutti i pacchetti in ritardo e di riavviare il flusso video senza timeshift. - se viene utilizzato UDP, non c'è scelta sul lato client, il video si riavvia dal vivo senza alcun timeshift. => TCP uguale o migliore.

Caso 2: alcuni pacchetti vengono persi in modo casuale e spesso sulla rete. - se viene utilizzato TCP, questi pacchetti verranno immediatamente ritrasmessi e con un buffer di jitter corretto non ci sarà alcun impatto sulla qualità / latenza del flusso video. - se viene utilizzato UDP, la qualità video sarà scarsa. => TCP molto meglio

Per lo streaming video la larghezza di banda è probabilmente il vincolo del sistema. Utilizzando multicast è possibile ridurre notevolmente la quantità di larghezza di banda upstream utilizzata. Con UDP puoi facilmente inviare in multicast i tuoi pacchetti a tutti i terminali collegati. Potresti anche usare un protocollo multicast affidabile, uno si chiama Pragmatic General Multicast (PGM), non ne so niente e immagino non sia diffuso nel suo utilizzo.

Oltre a tutti gli altri motivi, UDP può utilizzare il multicast. Supportare migliaia di utenti TCP che trasmettono tutti gli stessi dati spreca larghezza di banda. Tuttavia, c'è un altro motivo importante per utilizzare TCP.

TCP può passare molto più facilmente attraverso firewall e NAT. A seconda del NAT e dell'operatore, potresti non essere nemmeno in grado di ricevere un flusso UDP a causa di problemi con la perforazione UDP.

Tutte le risposte "usa UDP" presuppongono una rete aperta e "riempila il più possibile". Buono per le reti audio / video dedicate al giardino chiuso vecchio stile, che sono un tipo in via di estinzione.

Nel mondo reale, la tua trasmissione passerà attraverso i firewall (che lasceranno cadere multicast e talvolta udp), la rete è condivisa con altre app più importanti ($$$), quindi vuoi punire gli utenti che abusano con il ridimensionamento delle finestre.

Questo è il problema, è più una questione di contenuto che di tempo. Il protocollo TCP richiede che un pacchetto che non è stato consegnato debba essere controllato, verificato e riconsegnato. UDP non utilizza questo requisito. Quindi, se hai inviato un file che contiene milioni di pacchetti utilizzando UDP, come un video, se alcuni dei pacchetti mancano al momento della consegna, molto probabilmente andranno persi.