TCP vs UDP sur le flux vidéo
Je viens de rentrer de mon examen en programmation réseau et l'une des questions qu'ils nous ont posées était "Si vous allez diffuser de la vidéo, utiliseriez-vous TCP ou UDP? Donnez une explication pour les vidéos stockées et les flux vidéo en direct ". A cette question, ils attendaient simplement une réponse courte de TCP pour la vidéo stockée et UDP pour la vidéo en direct, mais j'y ai réfléchi en rentrant chez moi. Est-il nécessairement préférable d'utiliser UDP pour le streaming de vidéo en direct? Je veux dire, si vous avez la bande passante, et dites que vous diffusez un match de football ou un concert, avez-vous vraiment besoin d'utiliser UDP?
Disons que pendant que vous diffusez ce concert ou quoi que ce soit en utilisant TCP, vous commencez à perdre des paquets (quelque chose de grave est arrivé sur un réseau entre vous et l'expéditeur), et vous ne recevez aucun paquet pendant une minute. Le flux vidéo s'interrompt et une fois la minute écoulée, les paquets recommencent à passer (IP a trouvé un nouvel itinéraire pour vous). Ce qui arriverait alors, c’est que TCP retransmet la minute perdue et continue de vous envoyer le flux en direct. En supposant que la bande passante est supérieure au débit binaire sur le flux et que le ping n'est pas trop élevé, de sorte qu'en peu de temps, la minute perdue servira de mémoire tampon pour le flux pour vous. , si la perte de paquets se reproduit, vous ne le remarquerez pas.
Maintenant, je peux penser à certains appareils où ce ne serait pas une bonne idée, comme par exemple les vidéoconférences, où vous besoin d'être toujours à la fin du flux, car un chat vidéo est horrible, mais lors d'un match de football ou d'un concert, qu'importe si vous êtes une minute derrière le flux? De plus, vous avez la garantie d'obtenir toutes les données et il serait préférable de sauvegarder pour une visualisation ultérieure lorsqu'elles arrivent sans aucune erreur.
Cela m'amène donc à ma question. Y a-t-il des inconvénients que je ne connais pas sur l'utilisation de TCP pour la diffusion en direct? Ou bien faut-il vraiment que, si vous avez la bande passante nécessaire, vous devez utiliser TCP, étant donné qu'elle est "plus agréable" pour le réseau (contrôle de flux)?
Inconvénients de l’utilisation de TCP pour la vidéo en direct:
- En règle générale, les appliances de diffusion vidéo en direct ne sont pas conçues avec TCP à l'esprit. Si vous utilisez TCP, le système d'exploitation doit mettre en mémoire tampon les segments non acquittés pour chaque client. Ceci n'est pas souhaitable, en particulier dans le cas de la diffusion en direct. vraisemblablement, votre liste de clients simultanés est longue en raison de la singularité de l'événement. Les enregistrements vidéo préenregistrés ne posent généralement pas autant de problèmes, car les téléspectateurs étalent leur activité de relecture; TCP est plus approprié pour la lecture d'une vidéo à la demande.
- La multidiffusion IP réduit considérablement les besoins en bande passante vidéo pour les grands publics; TCP empêche l'utilisation de la multidiffusion IP, mais UDP convient bien à la multidiffusion IP.
- La vidéo en direct est normalement un flux à bande passante constante enregistré par une caméra; les flux vidéo pré-enregistrés sortent d'un disque. La dynamique de perte de sauvegarde de TCP) rend plus difficile la diffusion de vidéos en direct lorsque les flux source ont une bande passante constante (comme cela se produirait pour un événement en direct). Caméra, assurez-vous de disposer de suffisamment de mémoire tampon pour les événements réseau imprévisibles et de variables TCP taux d'envoi/de réduction. UDP vous donne beaucoup plus de contrôle pour cette application, car UDP ne se soucie pas des chutes de la couche de transport réseau.
Pour votre information, veuillez ne pas utiliser les "packages" de Word pour décrire les réseaux. Les réseaux envoient des "paquets".
mais lors d'un match de football ou d'un concert, qu'importe si vous êtes une minute derrière le courant?
Pour certains fans de foot, pas mal. Il a été remarqué que des retards même de quelques secondes dans les flux vidéo numériques en raison de l’encodage (ou autre) peuvent être très gênants lorsque, lors d’événements de grande envergure tels que des matches de coupe du monde, vous pouvez entendre les applaudissements et les gémissements des gars. à côté (qui regardent un programme analogique inexistant) avant de voir les mouvements du jeu qui les ont causés.
Je pense que pour quelqu'un qui se passionne pour le sport (et qui constituent le plus grand groupe de clients payants pour la télévision numérique, du moins ici en Allemagne), il serait totalement inacceptable de se retrouver à la minute près dans un flux vidéo en direct ( d passez chez votre concurrent où cela ne se produit pas).
Habituellement, un flux vidéo est quelque peu tolérant aux pannes. Ainsi, si certains paquets sont perdus (par exemple, en raison de la surcharge de certains routeurs), ils pourront toujours afficher le contenu, mais avec une qualité moindre.
Si votre diffusion en direct utilisait TCP/IP, alors il serait obligé d'attendre ces paquets abandonnés avant cela pourrait continuer traitement des données plus récentes.
C'est doublement mauvais:
- les anciennes données soient retransmises (probablement pour une trame déjà affichée et donc sans valeur) et
- les nouvelles données ne peuvent pas arriver avant après que les anciennes données aient été retransmises
Si votre objectif est d'afficher des informations aussi récentes que possible (et pour un flux en direct, vous voulez généralement être à jour, même si vos images paraissent un peu moins bonnes), alors TCP fonctionnera contre vous.
Pour un flux enregistré, la situation est légèrement différente: vous allez probablement mettre beaucoup plus de mémoire tampon (éventuellement plusieurs minutes!) Et préféreriez que les données soient retransmises plutôt que d'avoir des artefacts dus à la perte de paquets. Dans ce cas TCP est une bonne correspondance (cela pourrait toujours être implémenté dans UDP, bien sûr, mais TCP ne présente pas autant d'inconvénients que pour le cas de flux en direct).
Certains cas d'utilisation conviennent au transport UDP et d'autres à TCP transport.
Le cas d'utilisation dicte également les paramètres d'encodage de la vidéo. Lors de la diffusion d'un match de football, l'accent est mis sur la qualité et pour la vidéoconférence, sur la latence.
Lorsque vous utilisez la multidiffusion pour diffuser des vidéos à vos clients, le protocole UDP est utilisé.
La multidiffusion est un matériel réseau coûteux entre serveur de diffusion et client. En pratique, cela signifie que si votre entreprise possède une infrastructure de réseau, vous pouvez utiliser UDP et la multidiffusion pour la diffusion vidéo en direct. Même dans ce cas, la qualité de service est également implémentée pour marquer les paquets vidéo et les hiérarchiser afin d'éviter toute perte de paquet.
La multidiffusion simplifiera le logiciel de diffusion car le matériel réseau gérera la distribution des paquets aux clients. Les clients s'abonnent à des canaux de multidiffusion et le réseau se reconfigurera pour acheminer les paquets vers le nouvel abonné. Par défaut, tous les canaux sont disponibles pour tous les clients et peuvent être routés de manière optimale.
Ce flux de travail rend difficile le processus d'autorisation. Le matériel réseau ne différencie pas les utilisateurs abonnés des autres utilisateurs. La solution à l'autorisation consiste à chiffrer le contenu vidéo et à permettre le déchiffrement dans le logiciel du lecteur lorsque la souscription est valide.
Le flux de travail Unicast (TCP) permet au serveur de vérifier les informations d'identification du client et d'autoriser uniquement les abonnements valides. Même ne permettent qu'un certain nombre de connexions simultanées.
La multidiffusion n'est pas activée sur Internet.
Pour diffuser de la vidéo sur Internet TCP doit être utilisé. Lorsque UDP est utilisé, les développeurs finissent par réimplémenter la retransmission de paquets, par exemple avec le protocole Bittorrent p2p live.
"Si vous utilisez TCP, le système d'exploitation doit mettre en mémoire tampon les segments non acquittés pour chaque client. Ce n'est pas souhaitable, en particulier dans le cas d'événements en direct".
Ce tampon doit exister sous une forme quelconque. Il en va de même pour le tampon de gigue côté lecteur. Il est appelé "tampon de socket" et le logiciel serveur peut savoir quand ce tampon est plein et ignorer les images vidéo appropriées pour les flux en direct. Il est préférable d'utiliser la méthode unicast/TCP car le logiciel serveur peut implémenter la logique de suppression de trame appropriée. Les paquets manquants aléatoires dans le cas UDP ne feront que créer une mauvaise expérience utilisateur. comme dans cette vidéo: http://tinypic.com/r/2qn89xz/9
"La multidiffusion IP réduit considérablement les besoins en bande passante vidéo pour les grands publics"
Cela est vrai pour les réseaux privés, la multidiffusion n’est pas activée sur Internet.
"Notez que si TCP perd trop de paquets, la connexion meurt; ainsi, UDP vous donne beaucoup plus de contrôle pour cette application, car UDP ne se soucie pas des abandons de la couche de transport réseau."
UDP ne se soucie pas non plus de supprimer des images entières ou des groupes d’images, il ne donne donc plus aucun contrôle sur l’expérience utilisateur.
"Habituellement, un flux vidéo est quelque peu tolérant aux pannes"
La vidéo codée est pas tolérante aux pannes. Lorsqu'elle est transmise sur un transport non fiable, la correction d'erreur de transmission est ajoutée au conteneur vidéo. Un bon exemple est le conteneur MPEG-TS utilisé dans la diffusion vidéo par satellite qui achemine plusieurs flux audio, vidéo, EPG, etc. Cela est nécessaire car la liaison par satellite n'est pas une communication en duplex, ce qui signifie que le récepteur ne peut pas demander la retransmission de paquets perdus.
Lorsque vous avez une communication en duplex disponible, il est toujours préférable de ne retransmettre les données qu'aux clients ayant une perte de paquet plutôt que d'inclure une surcharge de correction d'erreur avant dans le flux envoyé à tous les clients.
Dans tous les cas, les paquets perdus sont inacceptables. Les images perdues sont acceptables dans des cas exceptionnels lorsque la bande passante est réduite.
Le résultat des paquets manquants sont des artefacts comme celui-ci: 
Certains décodeurs peuvent interrompre les flux de paquets manquants dans des endroits critiques.
Je vous recommande de regarder le nouveau protocole P2P Live Bittorent Live .
En ce qui concerne la diffusion en continu, il est préférable d'utiliser UDP, tout d'abord parce que cela réduit la charge sur les serveurs, mais surtout parce que vous pouvez envoyer des paquets avec multidiffusion, c'est plus simple que de l'envoyer à chaque client connecté.
Ça dépend. Quelle est l'importance du contenu que vous diffusez? Si critique, utilisez TCP. Cela peut entraîner des problèmes de bande passante, de qualité vidéo (vous devrez peut-être utiliser une qualité inférieure pour gérer la latence) et de latence. Mais si vous avez besoin du contenu pour y arriver, utilisez-le.
Sinon, UDP devrait convenir si le flux n'est pas critique et serait préférable, car UDP a tendance à avoir moins de temps système.
L’un des problèmes les plus importants lors de la diffusion d’événements en direct sur Internet est l’échelle, et TCP ne s’adapte pas bien. Par exemple, lorsque vous retransmettez un match de football en direct, par opposition à un événement à la demande. lecture de films: le nombre de personnes regardées peut facilement être 1000 fois plus. Dans un tel scénario, utiliser TCP est une condamnation à mort pour les CDN (réseaux de diffusion de contenu).
Il y a deux raisons principales pour lesquelles TCP ne s'adapte pas bien:
L’un des plus importants compromis de TCP est la variabilité du débit pouvant être atteint entre l’expéditeur et le destinataire. Lorsque la vidéo en streaming est diffusée sur Internet, les paquets vidéo doivent traverser plusieurs routeurs sur Internet, chacun de ces routeurs). est connecté avec différentes connexions à une vitesse différente. L'algorithme TCP commence par TCP fenêtre est petite, puis s'agrandit jusqu'à ce que la perte de paquets soit détectée, la perte de paquets est considérée comme un signe d'encombrement et TCP y répond en réduisant considérablement la taille de la fenêtre pour éviter l'encombrement. Réduisant ainsi immédiatement le débit effectif. Imaginez maintenant un réseau avec TCP transmission à l'aide de 6 à 7 sauts de routeur au client (scénario très normal), si l'un des routeurs intermédiaires perd un paquet, le TCP de cette liaison réduira le débit de transmission. En fait Le flux de trafic entre les routeurs suit une forme de sablier, toujours de haut en bas entre les routeurs intermédiaires. Tentative d’utilisation efficace beaucoup plus faible par rapport au meilleur effort UDP.
Comme vous le savez peut-être déjà TCP est un protocole basé sur l’accusé de réception. Supposons, par exemple, qu’un expéditeur se trouve à 50 ms (c’est-à-dire une latence entre deux points). Cela signifierait qu'il faut du temps pour qu'un paquet soit envoyé à un récepteur et le destinataire pour envoyer un accusé de réception serait de 100 ms, ce qui permet un débit maximal par rapport à une transmission basée sur UDP déjà divisée par deux.
Le TCP ne prend pas en charge la multidiffusion ou le nouveau standard émergent de la multidiffusion AMT. Ce qui signifie que les CDN n’ont pas la possibilité de réduire le trafic réseau en répliquant les paquets - lorsque de nombreux clients regardent la même contenu. C’est en soi une raison suffisante pour que les CDN (tels que Akamai ou Level3) ne soient pas compatibles avec TCP pour les flux en direct.
Pour la vidéo en continu, la bande passante est probablement la contrainte sur le système. L'utilisation de la multidiffusion vous permet de réduire considérablement la quantité de bande passante utilisée en amont. Avec UDP, vous pouvez facilement multidiffuser vos paquets vers tous les terminaux connectés. Vous pouvez également utiliser un protocole de multidiffusion fiable, l’un s’appelle Pragmatic General Multicast (PGM), je n’en sais rien et je suppose que son utilisation n’est pas généralisée.
Si la bande passante est de loin supérieure au débit, je recommanderais TCP pour la diffusion en continu de vidéo en monodiffusion.
Cas 1: les paquets consécutifs sont perdus pendant plusieurs secondes. => La vidéo en direct s'arrête côté client, quelle que soit la couche de transport (TCP ou UDP). Lorsque le réseau récupère: - si TCP est utilisé, le lecteur vidéo client peut choisir de redémarrer le flux au premier paquet perdu (timeshift) OR pour tout supprimer Paquets tardifs et redémarrage du flux vidéo sans timeshift - Si UDP est utilisé, il n'y a pas d'autre choix du côté client, la vidéo redémarre en direct sans timeshift. => TCP égal ou supérieur.
Cas 2: certains paquets sont aléatoires et souvent perdus sur le réseau. - si TCP est utilisé, ces paquets seront immédiatement retransmis et avec un tampon de gigue correct, il n'y aura aucun impact sur la qualité/latence du flux vidéo. - si UDP est utilisé, la qualité vidéo être pauvre. => TCP beaucoup mieux
Toutes les réponses "use UDP" supposent un réseau ouvert et "le bourre autant que vous le pouvez". Bon pour les anciens réseaux audio/vidéo dédiés aux jardins fermés, qui sont en train de disparaître.
Dans le monde actuel, votre transmission passera par des pare-feu (qui abandonneront la multidiffusion et parfois l’UDP), le réseau est partagé avec d’autres applications plus importantes ($$$), de sorte que vous souhaitez pour punir les agresseurs avec la mise à l'échelle de la fenêtre.
Lors de la lecture du débat TCP UDP, j’ai remarqué une faille logique. Une perte de paquets A TCP, entraînant un délai d’une minute converti en une mémoire tampon d’une minute) ne peut pas être corrélée. UDP perd une minute entière tout en subissant la même perte. Voici une comparaison plus juste.
TCP subit une perte de paquet. La vidéo est arrêtée pendant que TCP renvoyez les paquets dans le but de diffuser des paquets mathématiquement parfaits. La vidéo est retardée d'une minute et reprend là où elle s'est arrêtée après que le paquet manquant ait fait sa destination. Nous attendons tous mais nous savons que nous ne manquerons pas un seul pixel.
UDP subit une perte de paquet. Pendant une seconde pendant le flux vidéo, un coin de l'écran devient un peu flou. Personne ne le remarque et le spectacle continue sans chercher les paquets perdus.
Tout ce qui est diffusé profite le plus du programme UDP. La perte de paquets causant un délai d'une minute à TCP ne causerait pas un délai d'une minute à UDP. Compte tenu du fait que la plupart des systèmes utilisent plusieurs flux de résolution, ce qui rend les choses bloquantes lorsqu'il manque de paquets, est encore plus judicieux. utiliser UDP.
UDP FTW lors de la diffusion.
Outre toutes les autres raisons, UDP peut utiliser la multidiffusion. La prise en charge de milliers d'utilisateurs TCP) transmettant tous les mêmes données gaspille de la bande passante. Cependant, l'utilisation de TCP est une autre raison importante.
TCP peut beaucoup plus facilement passer à travers les pare-feu et les NAT. Selon votre opérateur NAT et, vous risquez même de ne pas pouvoir recevoir de flux UDP en raison de problèmes liés à la perforation de trou UDP.
C'est la chose, c'est plus une question de contenu que c'est une question de temps. Le protocole TCP requiert qu'un paquet qui n'a pas été livré doit être vérifié, vérifié et redélivré. UDP n'utilise pas cette exigence. Donc, si vous avez envoyé un fichier contenant des millions de paquets en utilisant UDP, comme une vidéo, si certains des paquets manquent à la livraison, ils resteront très probablement incontournables.