TCP vs UDP sur le stream 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 voulez diffuser de la vidéo, utiliseriez-vous TCP ou UDP? Donnez une explication à la fois pour la vidéo stockée et les stream vidéo en direct” . À 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 pensé en rentrant chez moi, et est-il nécessairement préférable d’utiliser UDP pour la diffusion de vidéo en direct? Je veux dire, si vous avez la bande passante nécessaire et que vous dites que vous diffusez un match de football ou un concert, avez-vous vraiment besoin d’UDP?

Disons que pendant que vous diffusez ce concert ou que vous utilisiez TCP, vous commencez à perdre des paquets (quelque chose de mal est arrivé dans un réseau entre vous et l’expéditeur) et pendant une minute vous ne recevez aucun paquet. Le stream vidéo sera mis en pause et, une fois la minute écasting, les paquets recommenceront à passer (IP a trouvé une nouvelle route pour vous). Ce qui arriverait alors, c’est que TCP retransmet la minute que vous avez perdue et continue à vous envoyer le stream en direct. En supposant que la bande passante soit supérieure au débit du stream et que le ping n’est pas trop élevé, la minute perdue agira comme un tampon pour le stream dans un court laps de temps. , si la perte de paquets se reproduit, vous ne le remarquerez pas.

Maintenant, je peux penser à certaines appliances où cela ne serait pas une bonne idée, comme par exemple les vidéoconférences, où vous devez toujours être à la fin du stream, car le délai pendant un chat vidéo est horrible, mais pendant un match de football, ou un concert, qu’importe si vous êtes à une minute du stream? De plus, vous avez la garantie d’obtenir toutes les données et il est préférable de les enregistrer pour les visionner ultérieurement, sans erreur.

Cela m’amène donc à ma question. Y a-t-il des inconvénients dont je ne connais pas l’utilisation de TCP pour la diffusion en direct? Ou devrait-il vraiment être, si vous avez la bande passante pour cela, vous devriez aller pour le TCP étant donné qu’il est “plus agréable” pour le réseau (contrôle de stream)?

    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 pour la diffusion en continu TCP. Si vous utilisez TCP, le système d’exploitation doit mettre en mémoire tampon les segments non acquittés pour chaque client. Cela n’est pas souhaitable, en particulier dans le cas d’événements en direct; Votre liste de clients simultanés est probablement longue en raison de la singularité de l’événement. Les vidéos pré-enregistrées ne posent généralement pas autant de problèmes car les téléspectateurs échelonnent leur activité de lecture. 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 convient parfaitement à la multidiffusion IP.
    3. La vidéo en direct est normalement un stream à bande passante constante enregistré par une caméra. les stream vidéo pré-enregistrés sont stockés sur un disque. La dynamic de perte de temps de retour de TCP rend plus difficile la diffusion de vidéo en direct lorsque les stream source ont une bande passante constante (comme cela se produirait pour un événement en direct). Si vous mettez en mémoire tampon un disque hors 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 variables d’envoi / de retour TCP. UDP vous donne beaucoup plus de contrôle sur cette application, car UDP ne se soucie pas de la couche de transport réseau.

    Pour votre information, n’utilisez pas le mot “packages” pour décrire les réseaux. Les réseaux envoient des “paquets”.

    mais pendant un match de football ou un concert, qu’importe si vous êtes à une minute de la piste?

    Pour certains fans de football, pas mal. On a remarqué que les retards de quelques secondes dans les stream vidéo numériques dus à l’encodage (ou peu importe) peuvent être très ennuyeux lorsque, lors d’événements prestigieux tels que des matchs de coupe du monde, on peut entendre les gémissements des gars. juste à côté (qui regardent un programme analogique indéfectible) avant de voir les mouvements du jeu qui les ont provoqués.

    Je pense que pour quelqu’un qui se soucie beaucoup du sport (et qui est le groupe le plus important de clients payants pour la télévision numérique, du moins ici en Allemagne), il serait totalement inacceptable de se retrouver à une minute dans un stream vidéo en direct. d passez à votre concurrent là où cela ne se produit pas).

    Généralement, un stream vidéo est quelque peu tolérant aux pannes. Ainsi, si certains paquets sont perdus (par exemple, en raison de la surcharge d’un routeur en cours de route), il sera toujours possible d’afficher le contenu, mais avec une qualité réduite.

    Si votre stream en direct utilisait TCP / IP, il serait alors obligé d’attendre que ces paquets soient supprimés avant de pouvoir continuer à traiter des données plus récentes.

    C’est doublement mauvais:

    • les anciennes données sont retransmises (c’est probablement pour une image déjà affichée et donc sans valeur) et
    • les nouvelles données ne peuvent pas arriver avant que les anciennes données aient été retransmises

    Si votre objective est d’afficher des informations aussi actualisées que possible (et pour un stream en direct, vous souhaitez généralement être à jour, même si vos images sont un peu moins bonnes), TCP fonctionnera alors contre vous.

    Pour un stream enregistré, la situation est légèrement différente: vous stockerez probablement beaucoup plus de mémoire (peut-être plusieurs minutes!) Et préférez que les données soient retransmises plutôt que des artefacts dus à des paquets perdus. Dans ce cas, TCP est une bonne correspondance (cela pourrait bien sûr toujours être implémenté dans UDP, mais TCP ne présente pas autant d’inconvénients que dans le cas du stream 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 parameters d’encodage pour 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, l’accent est mis sur la latence.

    Lorsque vous utilisez la multidiffusion pour diffuser de la vidéo à vos clients, le protocole UDP est utilisé.

    La multidiffusion nécessite du 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 implémentée pour marquer les paquets vidéo et les hiérarchiser afin d’éviter toute perte de paquets.

    La multidiffusion simplifiera le logiciel de diffusion, car le matériel réseau se chargera de dissortingbuer les paquets aux clients. Les clients s’abonnent aux canaux de multidiffusion et le réseau se reconfigure pour acheminer les paquets vers un nouvel abonné. Par défaut, tous les canaux sont disponibles pour tous les clients et peuvent être acheminés de manière optimale.

    Ce stream de travail pose des difficultés lors du 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 à activer le déchiffrement dans le logiciel du lecteur lorsque l’abonnement est valide.

    Le stream 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 autoriser seulement un certain nombre de connexions simultanées.

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

    Pour diffuser des vidéos 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 live de Bittorrent p2p.

    “Si vous utilisez TCP, le système d’exploitation doit mettre en mémoire tampon les segments non acquittés pour chaque client. Cela est indésirable, en particulier dans le cas d’événements en direct”.

    Ce tampon doit exister sous une forme quelconque. La même chose est vraie pour le tampon de gigue côté joueur. Il est appelé “socket buffer” et le logiciel serveur peut savoir quand ce tampon est plein et supprimer les images vidéo appropriées pour les stream en direct. Il est préférable d’utiliser la méthode unicast / TCP car le logiciel serveur peut implémenter une logique de suppression de trame correcte. Les paquets manquants aléatoires dans le cas UDP créeront simplement 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 meurt. Ainsi, UDP vous donne beaucoup plus de contrôle pour cette application car UDP ne se soucie pas des baisses de couche de transport réseau.”

    UDP ne se soucie pas non plus de supprimer des images entières ou des groupes d’images, de sorte qu’il ne permet plus de contrôler l’expérience utilisateur.

    “Généralement, un stream vidéo est un peu tolérant aux pannes”

    La vidéo codée n’est pas tolérante aux pannes. Lorsqu’elles sont transmises 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 stream audio, vidéo, EPG, etc. Cela est nécessaire car la liaison par satellite n’est pas une communication duplex, ce qui signifie que le récepteur ne peut pas demander la retransmission de paquets perdus.

    Lorsque vous disposez d’une communication recto verso, il est toujours préférable de ne retransmettre les données qu’aux clients ayant une perte de paquets, puis d’inclure la surcharge de correction d’erreur dans le stream envoyé à tous les clients.

    Dans tous les cas, les paquets perdus sont inacceptables. Les images supprimées sont acceptables dans des cas exceptionnels lorsque la bande passante est entravée.

    Le résultat des paquets manquants sont des artefacts comme celui-ci: artefacts

    Certains décodeurs peuvent casser des stream de paquets manquants dans des endroits critiques.

    Je vous recommande de consulter le nouveau protocole en direct de p2p, Bittorent Live .

    En ce qui concerne le streaming, il est préférable d’utiliser UDP, d’abord parce qu’il réduit la charge sur les serveurs, mais surtout parce que vous pouvez envoyer des paquets avec multicast, il est plus simple que de l’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 fonctionner correctement si le stream 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 celui de «l’échelle», et TCP ne fonctionne pas bien. Par exemple, lorsque vous diffusez un match de football en direct, par opposition à une lecture de 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 réseaux de diffusion de contenu (CDN).

    Il y a deux raisons principales pour lesquelles TCP ne fonctionne pas bien:

    1. L’un des compromis les plus importants de TCP est la variabilité du débit pouvant être atteint entre l’expéditeur et le destinataire. Lors de la diffusion vidéo sur Internet, les paquets vidéo doivent traverser plusieurs routeurs sur Internet, chacun de ces routeurs étant connecté à des connexions de vitesse différentes. L’algorithme TCP commence avec la fenêtre TCP petite, puis augmente 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. Ainsi, en réduisant immédiatement le débit effectif. Imaginez maintenant un réseau avec une transmission TCP utilisant 6-7 routages de saut au client (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 stream 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 passe beaucoup moins que le meilleur effort UDP.

    2. Comme vous le savez peut-être déjà, TCP est un protocole basé sur les accusés de réception. Disons par exemple qu’un expéditeur est à 50ms (c’est-à-dire une latence entre deux points). Cela signifie que le temps nécessaire pour qu’un paquet soit envoyé à un destinataire et que le récepteur envoie un accusé de réception 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 protocole TCP ne prend pas en charge la multidiffusion ni 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 le même contenu. C’est une raison suffisante pour que les CDN (comme Akamai ou Level3) ne fonctionnent pas avec TCP pour les stream en direct.

    Pour la vidéo en streaming, la bande passante est probablement la contrainte sur le 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 que son utilisation n’est pas très répandue.

    Toutes les réponses «use UDP» supposent un réseau ouvert et l’approche «farce autant que vous pouvez». Bon pour les réseaux audio / vidéo dédiés de style ancien avec jardin clos, qui sont en voie de disparition.

    Dans le monde réel, votre transmission passera par des pare-feu (qui lâcheront le multicast et parfois l’UDP), le réseau est partagé avec d’autres applications plus importantes ($$$), vous voulez donc punir les abuseurs de fenêtres.

    Outre toutes les autres raisons, UDP peut utiliser la multidiffusion. La prise en charge de milliers d’utilisateurs TCP qui transmettent tous les mêmes données gaspillent la bande passante. Cependant, il existe une autre raison importante d’utiliser TCP.

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

    En lisant le débat TCP UDP, j’ai remarqué un défaut logique. Une perte de paquets TCP causant un délai d’une minute converti en une mémoire tampon d’une minute ne peut pas être corrélée à la perte d’une minute par UDP 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’est arrêtée après que le paquet manquant a atteint sa destination. Nous attendons tous mais nous soaps que nous ne manquerons aucun pixel.

    UDP subit une perte de paquets. Pendant une seconde pendant le stream 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 plus d’avantages de l’UDP. La perte de paquets causant un délai d’une minute à TCP ne causerait pas de délai d’une minute à UDP. Considérant que la plupart des systèmes utilisent des stream de résolution multiples rendant les choses difficiles en cas de manque de paquets, il est encore plus judicieux d’utiliser UDP.

    UDP FTW en streaming.

    Si la bande passante est bien supérieure au débit binary, je recommanderais le protocole TCP pour le streaming vidéo en direct unicast.

    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 se rétablit: – si TCP est utilisé, le lecteur vidéo client peut choisir de redémarrer le stream au premier paquet perdu (décalage temporel) OU de supprimer tous les paquets en retard et de redémarrer le stream vidéo sans décalage temporel. – si UDP est utilisé, il n’y a pas de choix du côté client, le redémarrage de la vidéo est direct sans décalage. => TCP égal ou meilleur.

    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 stream vidéo. – Si UDP est utilisé, la qualité vidéo sera médiocre. => TCP beaucoup mieux

    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 remis. 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 à la livraison, ils risquent fort de ne pas être acceptés.