TCP vs UDP sur flux vidéo

Je viens de rentrer de mon examen de programmation réseau et l'une des questions qu'ils nous ont posées était "Si vous voulez diffuser de la vidéo, utiliseriez-vous TCP ou UDP? Expliquez à la fois la vidéo stockée et les flux vidéo en direct" . À cette question, ils s'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 pensé en rentrant chez moi, et est-il nécessairement préférable d'utiliser UDP pour diffuser de la vidéo en direct? Je veux dire, si vous avez la bande passante pour cela, et que vous dites que vous diffusez un match de football, ou un concert d'ailleurs, 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 mauvais s'est produit dans un réseau entre vous et l'expéditeur), et pendant une minute entière, vous ne recevez aucun paquet. Le flux vidéo se mettra en pause et une fois la minute écoulée, les paquets recommenceront à passer (IP a trouvé une nouvelle route pour vous). Ce qui se passerait alors, c'est que TCP retransmettrait la minute perdue et continuerait à vous envoyer le flux en direct. En supposant que la bande passante est plus élevée que le débit binaire sur le flux, et le ping n'est pas trop élevé, donc dans un court laps de temps, la minute que vous avez perdue servira de tampon pour le flux pour vous, de cette façon , 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 devez toujours être à la fin du flux, car le retard lors d'un chat vidéo est tout simplement horrible, mais pendant un match de football ou 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 les enregistrer 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 à propos de l'utilisation de TCP pour la diffusion en direct? Ou devrait-il vraiment être, que si vous avez la bande passante pour cela, vous devriez opter pour TCP étant donné qu'il 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:

1. En règle générale, les appareils de diffusion vidéo en direct ne sont pas conçus avec le streaming 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 d'événements en direct; vraisemblablement, votre liste de clients simultanés est longue en raison de la singularité de l'événement. Les diffusions vidéo préenregistrées n'ont généralement pas autant de problème avec cela, car les téléspectateurs échelonnent leur activité de relecture; TCP est donc plus approprié pour rejouer une vidéo à la demande.
2. La multidiffusion IP réduit considérablement les besoins en bande passante vidéo pour un large public; TCP empêche l'utilisation de la multidiffusion IP, mais UDP est bien adapté à la multidiffusion IP.
3. La vidéo en direct est normalement un flux à bande passante constante enregistré sur une caméra; les flux vidéo préenregistrés sortent d'un disque. La dynamique de perte-backoff de TCP rend plus difficile la diffusion de vidéo en direct lorsque les flux sources sont à une bande passante constante (comme cela se produirait pour un événement en direct). Si vous mettez en mémoire tampon sur le disque d'une caméra, assurez-vous de disposer de suffisamment de mémoire tampon pour les événements réseau imprévisibles et les taux d'envoi / d'arrêt TCP variables. UDP vous donne beaucoup plus de contrôle pour cette application car UDP ne se soucie pas des pertes de couche de transport réseau.

Pour votre information, veuillez ne pas utiliser le mot «packages» pour décrire les réseaux. Les réseaux envoient des "paquets".

mais pendant un match de foot, ou un concert, qu'importe si vous êtes à une minute derrière le flux?

Pour certains fans de football, un peu. Il a été remarqué que des retards de même quelques secondes présents dans les flux vidéo numériques dus à l'encodage (ou autre) peuvent être très ennuyeux lorsque, lors d'événements de grande envergure tels que les matchs de coupe du monde, vous pouvez entendre les acclamations et les gémissements des gars. à côté (qui regardent un programme analogique non asservi) avant de voir les mouvements de jeu qui les ont provoqués.

Je pense que pour quelqu'un qui se soucie beaucoup du sport (et c'est le plus grand groupe de clients payants pour la télévision numérique, du moins ici en Allemagne), être une minute de retard dans un flux vidéo en direct serait complètement inacceptable (comme dans, ils '' d passer à votre concurrent lorsque cela ne se produit pas).

Habituellement, un flux vidéo est quelque peu tolérant aux pannes. Donc, si certains paquets sont perdus (en raison de la surcharge d'un routeur en cours de route, par exemple), il sera toujours en mesure d'afficher le contenu, mais avec une qualité réduite.

Si votre flux en direct utilisait TCP / IP, il serait obligé d'attendre ces paquets abandonnés avant de pouvoir continuer à traiter des données plus récentes.

C'est doublement mauvais:

• les anciennes données soient retransmises (c'est probablement pour une trame qui était déjà affichée et donc sans valeur) et
• les nouvelles données ne peuvent arriver qu'après la retransmission des anciennes données

Si votre objectif est d'afficher des informations aussi à jour que possible (et pour une diffusion en direct, vous voulez généralement être à jour, même si vos cadres semblent un peu pires), 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 (peut-être plusieurs minutes!) Et préféreriez avoir des données retransmises plutôt que 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 n'a pas autant d'inconvénients que pour le cas du flux en direct).

Il existe des cas d'utilisation adaptés au transport UDP et d'autres adaptés au transport TCP.

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 de la vidéo à vos clients, UDP est utilisé.

La nécessité de la multidiffusion est un matériel réseau coûteux entre le serveur de diffusion et le client. En pratique, cela signifie que si votre entreprise possède une infrastructure 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 mise en œuvre pour marquer les paquets vidéo et les hiérarchiser afin qu'aucune perte de paquets ne se produise.

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 aux 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 acheminé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 à crypter le contenu vidéo et à activer le décryptage dans le logiciel du lecteur lorsque l'abonnement 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. N'autorisez même qu'un certain nombre de connexions simultanées.

La multidiffusion n'est pas activée sur Internet.

Pour diffuser 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. 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. Ceci n'est pas souhaitable, en particulier dans le cas d'événements en direct".

Ce tampon doit exister sous une forme ou une autre. Il en va de même pour le tampon de gigue côté joueur. Il est appelé "tampon de socket" et le logiciel serveur peut savoir quand ce tampon est plein et rejeter les images vidéo appropriées pour les flux en direct. Il est préférable d'utiliser la méthode monodiffusion / TCP car le logiciel serveur peut implémenter une 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 un large public"

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 s'éteint; ainsi, UDP vous donne beaucoup plus de contrôle pour cette application car UDP ne se soucie pas des pertes de couche de transport réseau."

UDP ne se soucie pas non plus de supprimer des cadres entiers ou des groupes de cadres, de sorte qu'il ne donne plus de contrôle sur l'expérience utilisateur.

"Habituellement, un flux vidéo est quelque peu tolérant aux pannes"

La vidéo encodée n'est pas tolérante aux pannes. Lorsqu'elle est transmise sur un transport non fiable, la correction d'erreur directe est ajoutée au conteneur vidéo. Un bon exemple est le conteneur MPEG-TS utilisé dans la diffusion vidéo par satellite qui transporte plusieurs flux audio, vidéo, EPG, etc. Ceci est nécessaire car la liaison satellite n'est pas une communication duplex, ce qui signifie que le récepteur ne peut pas demander la retransmission des paquets perdus.

Lorsque vous disposez d'une communication duplex disponible, il est toujours préférable de retransmettre les données uniquement aux clients ayant une perte de paquets, puis d'inclure le surdébit de correction d'erreur avant dans le flux envoyé à tous les clients.

Dans tous les cas, les paquets perdus sont inacceptables. Les trames perdues sont acceptables dans des cas exceptionnels lorsque la bande passante est limitée.

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 le streaming, il est préférable d'utiliser UDP, d'abord parce que cela réduit la charge sur les serveurs, mais surtout parce que vous pouvez envoyer des paquets en multidiffusion, c'est plus simple que de les envoyer à chaque client connecté.

Ça dépend. Dans quelle mesure le contenu que vous diffusez est-il critique? 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 surcharge.

L'un des plus gros problèmes liés à la diffusion d'événements en direct sur Internet est «l'échelle», et TCP ne s'adapte pas bien. Par exemple, lorsque vous diffusez un match de football en direct - par opposition à la lecture d'un film à la demande - le nombre de personnes qui regardent peut facilement être 1000 fois plus élevé. Dans un tel scénario, l'utilisation de TCP est une condamnation à mort pour les CDN (réseaux de diffusion de contenu).

Il y a plusieurs raisons principales pour lesquelles TCP ne s'adapte pas bien:

1. L'un des plus grands compromis de TCP est la variabilité du débit réalisable entre l'expéditeur et le récepteur. Lors du streaming vidéo sur Internet, les paquets vidéo doivent traverser plusieurs routeurs sur Internet, chacun de ces routeurs étant connecté avec des connexions à vitesse différente. L'algorithme TCP commence avec une fenêtre TCP éteinte, puis augmente jusqu'à ce que la perte de paquets soit détectée, la perte de paquets est considérée comme un signe de congestion et TCP y répond en réduisant drastiquement la taille de la fenêtre pour éviter la congestion. Ainsi, à son tour, la réduction du débit effectif est immédiate. Imaginez maintenant un réseau avec transmission TCP utilisant 6-7 sauts de routeur vers le client (un scénario très normal), si l'un des routeurs intermédiaires perd un paquet, le TCP pour ce lien réduira le débit de transmission. En fait, le flux de trafic entre les routeurs suit une forme de sablier; toujours en haut et en bas entre l'un des routeurs intermédiaires. Le rendu efficace à travers met beaucoup plus bas que l'UDP au meilleur effort.

2. Comme vous le savez peut-être déjà, TCP est un protocole basé sur l'accusé de réception. Disons par exemple qu'un expéditeur est à 50 ms (c'est-à-dire une latence entre deux points). Cela signifierait que le temps qu'il faut pour qu'un paquet soit envoyé à un récepteur et qu'un récepteur envoie un accusé de réception serait de 100 ms; ainsi, le débit maximum possible par rapport à la transmission basée sur UDP est déjà divisé par deux.

3. Le TCP ne prend pas en charge la multidiffusion ou la nouvelle norme émergente de 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 le même contenu. C'est en soi une raison suffisante pour que les CDN (comme Akamai ou Level3) ne soient pas compatibles avec TCP pour les flux en direct.

En lisant le débat sur TCP UDP, j'ai remarqué une faille logique. Une perte de paquet TCP causant un délai d'une minute qui est converti en un tampon d'une minute ne peut pas être corrélée à une perte d'UDP d'une minute complète tout en subissant la même perte. Une comparaison plus juste est la suivante.

TCP subit une perte de paquets. La vidéo est arrêtée pendant que TCP renvoie les paquets pour tenter de diffuser des paquets mathématiquement parfaits. La vidéo est retardée d'une minute et reprend là où elle s'était arrêtée après que le paquet manquant ait atteint sa destination. Nous attendons tous mais nous savons que nous ne manquerons pas un seul pixel.

UDP subit une perte de paquets. 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é tire le meilleur parti d'UDP. La perte de paquets causant un retard d'une minute à TCP ne provoquerait pas un retard d'une minute à UDP. Étant donné que la plupart des systèmes utilisent plusieurs flux de résolution, ce qui rend les choses bloquées quand on manque de paquets, il est encore plus logique d'utiliser UDP.

UDP FTW lors du streaming.

Si la bande passante est beaucoup plus élevée que le débit, je recommanderais TCP pour le streaming vidéo en direct unicast.

Cas 1: les paquets consécutifs sont perdus pendant une durée de plusieurs secondes. => la vidéo en direct s'arrêtera 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 (décalage temporel) OU de supprimer tous les paquets en retard et de redémarrer le flux vidéo sans décalage temporel. - si UDP est utilisé, il n'y a pas de choix côté client, la vidéo redémarre en direct sans décalage. => TCP égal ou supérieur.

Cas 2: certains paquets sont aléatoirement 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 sera mauvaise. => TCP beaucoup mieux

Pour le streaming vidéo, la bande passante est probablement la contrainte du système. En utilisant la multidiffusion, vous pouvez réduire considérablement la quantité de bande passante en amont utilisée. 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 qu'il n'est pas répandu dans son utilisation.

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, il existe une autre raison importante d'utiliser TCP.

TCP peut passer beaucoup plus facilement à travers les pare-feu et les NAT. En fonction de votre NAT et de votre opérateur, vous ne pourrez peut-être même pas recevoir un flux UDP en raison de problèmes de perforation UDP.

Toutes les réponses «utiliser UDP» supposent un réseau ouvert et l'approche «bourrez-le autant que vous le pouvez». Bon pour les réseaux audio / vidéo dédiés à l'ancien jardin clos, qui sont en voie de disparition.

Dans le monde réel, votre transmission passera par des pare-feu (qui abandonneront la multidiffusion et parfois udp), le réseau est partagé avec d'autres applications plus importantes ($$$), vous voulez donc punir les abuseurs avec la mise à l'échelle de la fenêtre.

C'est la chose, c'est plus une question de contenu qu'une question de temps. Le protocole TCP exige qu'un paquet qui n'a pas été livré doit être vérifié, vérifié et renvoyé. 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 sont manquants lors de la livraison, ils ne seront probablement pas manqués.