TCP vs UDP sur un flux vidéo

Question

Je viens de rentrer de mon examen de programmation réseau, et une des questions qu'ils nous ont posées était "Si vous voulez diffuser de la vidéo en continu, utiliseriez-vous TCP ou UDP ? Donnez une explication pour la vidéo stockée et les flux vidéo en direct". . À cette question, ils attendaient simplement une réponse courte, à savoir TCP pour la vidéo stockée et UDP pour la vidéo en direct, mais j'ai réfléchi à cette question sur le chemin du retour, et je me suis demandé s'il était nécessairement préférable d'utiliser UDP pour le streaming vidéo en direct ? Je veux dire, si vous avez la bande passante nécessaire et que vous diffusez un match de football ou un concert, avez-vous vraiment besoin d'utiliser UDP ?

Imaginons que pendant que vous diffusez ce concert ou autre en utilisant TCP, vous commencez à perdre des paquets (quelque chose de grave 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 s'interrompt, et une fois la minute écoulée, les paquets recommencent à passer (l'IP a trouvé une nouvelle route pour vous). Le TCP retransmet alors la minute que vous avez perdue et continue à vous envoyer le flux en direct. En supposant que la bande passante est supérieure au débit binaire du flux et que le ping n'est pas trop élevé, la minute que vous avez perdue servira de tampon pour le flux, de sorte que 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éo-conférences, où vous besoin de d'être toujours à la fin du flux, car les retards lors d'un chat vidéo sont tout simplement horribles, mais lors d'un match de football ou d'un concert, quelle importance si vous avez une minute de retard sur le flux ? De plus, vous avez la garantie de recevoir toutes les données et il serait préférable de les sauvegarder pour les visionner plus tard lorsqu'elles arrivent sans erreur.

Ce qui m'amène à ma question. Y a-t-il des inconvénients que je ne connais pas à l'utilisation du protocole TCP pour la diffusion en direct ? Ou bien, si vous avez la bande passante nécessaire, vous devriez opter pour le protocole TCP, car il est plus "gentil" pour le réseau (contrôle de flux) ?

Answer 1

Inconvénients de l'utilisation du protocole TCP pour la vidéo en direct :

1. Comme vous l'avez mentionné, TCP met en mémoire tampon les segments non acquittés pour chaque client. Dans certains cas, cela n'est pas souhaitable, comme le streaming TCP pour des événements en direct très populaires : votre liste de clients simultanés (et les exigences de mise en mémoire tampon) est importante dans ce cas. Les diffusions vidéo préenregistrées ne posent généralement pas ce problème car les spectateurs ont tendance à échelonner leur activité de relecture.

2. Les garanties de livraison du protocole TCP sont une fonction de blocage qui n'est pas utile dans les conversations interactives. Supposons que votre connexion réseau s'interrompe pendant 15 secondes. Lorsque nous manquons une partie d'une conversation, nous demandons naturellement à la personne de répéter (ou l'autre partie répétera de manière proactive s'il semble que vous ayez manqué quelque chose). UDP ne se soucie pas de savoir si vous avez manqué une partie de la conversation pendant les 15 dernières secondes ; il continue à fonctionner comme si de rien n'était. D'un autre côté, l'application pourrait être conçue pour que TCP rejoue les 15 dernières secondes (et la personne à l'autre bout du fil pourrait ne pas vouloir ou savoir cela). Une telle relecture par TCP aggrave le problème et rend plus difficile la synchronisation avec les autres parties de la conversation. En comparant le comportement de TCP et d'UDP face à la perte de paquets, on peut dire qu'il est plus facile pour UDP de rester en phase avec l'état d'une conversation interactive.

3. La multidiffusion IP réduit considérablement les besoins en bande passante vidéo pour les audiences importantes. La multidiffusion nécessite UDP (et est incompatible avec TCP). Remarque : la multidiffusion est généralement limitée aux réseaux privés. Veuillez noter que la multidiffusion sur Internet n'est pas courante. Je tiens également à souligner que l'exploitation des réseaux de multidiffusion est plus compliquée que celle des réseaux monodiffusion typiques.

Pour votre information, n'utilisez pas le mot "paquets" pour décrire les réseaux. Les réseaux envoient des "paquets".

Answer 2

mais pendant un match de foot, ou un concert, quelle importance si vous êtes une seule minute de retard sur le flux ?

Pour certains fans de football, c'est beaucoup. Il a été remarqué que les retards, même de quelques secondes, présents 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 très médiatisés tels que les matchs de la coupe du monde, vous pouvez entendre les acclamations et les gémissements des gars d'à côté (qui regardent un programme analogique non diffusé) avant de voir les mouvements de jeu qui les ont provoqués.

Je pense que pour quelqu'un qui s'intéresse beaucoup au sport (et c'est le groupe le plus important de clients payants pour la télévision numérique, du moins ici en Allemagne), avoir une minute de retard dans un flux vidéo en direct serait totalement inacceptable (comme dans, ils passeraient à votre concurrent où cela ne se produit pas).

Answer 3

En général, un flux vidéo est quelque peu tolérant aux pannes. Ainsi, si certains paquets sont perdus (en raison de la surcharge d'un routeur en cours de route, par exemple), le contenu pourra toujours être affiché, mais avec une qualité réduite.

Si votre flux en direct utilisait TCP/IP, alors ce serait forcé pour attendre ces paquets déposés antes de il pouvait continuer à traiter des données plus récentes.

C'est doublement mauvais :

• les anciennes données sont retransmises (il s'agit probablement d'une trame déjà affichée et donc sans valeur) et
• les nouvelles données ne peuvent pas arriver avant après les anciennes données ont été retransmises

Si votre objectif est d'afficher des informations aussi à jour que possible (et pour un flux en direct, vous voulez généralement être à jour, même si vos images ont l'air un peu moins bonnes), alors TCP jouera contre vous.

Pour un flux enregistré, la situation est légèrement différente : la mise en mémoire tampon sera probablement beaucoup plus longue (peut-être plusieurs minutes !) et vous préférerez que les données soient retransmises plutôt que d'avoir des artefacts dus à des paquets perdus. Dans ce cas, TCP est une bonne solution (on pourrait bien sûr utiliser UDP, mais TCP ne présente pas autant d'inconvénients que dans le cas d'un flux en direct).

Answer 4

Je vous recommande de regarder le nouveau protocole p2p live. Bittorent Live .

Pour 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 multicast, c'est plus simple que de les envoyer à chaque client connecté.

Answer 5

Cela dépend. Quel est le degré de criticité du contenu que vous diffusez ? Si c'est le cas, utilisez le protocole TCP. Cela peut poser des problèmes de bande passante, de qualité vidéo (vous devrez peut-être utiliser une qualité inférieure pour faire face à la latence) et de latence. Mais si vous avez besoin que le contenu soit garanti, utilisez-le.

Sinon, UDP devrait convenir si le flux n'est pas critique et serait préféré car UDP a tendance à avoir moins d'overhead.