Pourquoi RTP utilise-t-il UDP au lieu de TCP?

beaucoup de bonnes réponses ont été données, mais j'aimerais souligner une chose explicitement:

fondamentalement, un flux de données complet est une chose agréable à avoir pour l'audio / vidéo en temps réel, mais ce n'est pas strictement nécessaire (comme d'autres l'ont fait remarquer):

le fait important est que certaines données qui arrivent trop tard sont sans valeur. À quoi servent les données manquantes pour un cadre qui aurait dû être affiché il y a une seconde?

si vous utilisez TCP (qui garantit également l'ordre correct de toutes les données), alors vous ne seriez pas en mesure d'obtenir les données les plus à jour jusqu'à ce que l'ancienne soit transmise correctement. C'est doublement mauvais: il faut attendre la re-transmission des anciennes données et les nouvelles données (qui est maintenant de retard) sera probablement tout aussi inutile.

donc RTP fait une sorte de transmission du meilleur effort en ce qu'il essaie de transférer toutes les données disponibles à temps, mais ne tente pas de retransmettre les données qui ont été perdues/corrompues pendant le transfert (*). Il va juste avec la vie et espère que les données plus importantes actuelles obtient là correctement.

(*) en fait, je ne connais pas les détails de RTP. Peut-être qu'il essaie de re-transmettre, mais si c'est le cas, il ne sera pas aussi agressif que TCP (qui n'acceptera jamais de données perdues).

les autres sont corrects, cependant les ne vous disent pas vraiment la vraie raison pour laquelle. Saua genre de trucs, mais voici une réponse plus complète.

L'Audio et la vidéo sont en temps réel. Si vous écoutez une radio, ou regardez la télévision, et que le signal est interrompu, il ne reprend pas là où vous vous êtes arrêté.. vous "observez" juste le signal en le diffusant, et si vous ne pouvez pas l'observer à tout moment, vous le perdez.

La raison est simple. Retard. VOIP fait de son mieux pour minimiser la quantité de retard à partir du moment où quelqu'un parle dans une extrémité et vous obtenez sur votre extrémité, et votre réponse en arrière. Autrement, à mesure que des erreurs se produisaient, le délai entre le moment où la personne parlait et le moment où le signal était Reçu ne cessait de croître jusqu'à devenir inutile.

rappelez-vous, chaque délai d'une retransmission doit être rediffusé, et cela retarde d'autres données, puis une autre erreur provoque un retard encore plus grand. La seule solution viable est de il suffit de laisser tomber toutes les données qui ne peuvent pas être affichées en temps réel.

un délai d'une seconde à partir de la retransmission signifierait qu'il serait maintenant d'une seconde à partir du moment où j'ai dit quelque chose jusqu'à ce que vous l'entendiez. Un second délai d'une seconde signifie Maintenant que c'est 2 secondes à partir du moment où je dis quelque chose jusqu'à ce que vous l'entendiez. Ceci est cumulatif parce que les données sont jouées à la même vitesse à laquelle elles sont parlées, et ainsi de suite...

RTP pourrait être orienté connexion, mais alors il devrait laisser tomber (ou sauter) les données pour suivre la retransmission des erreurs de toute façon, pourquoi s'embêter avec les frais généraux supplémentaires?

techniquement, les paquets RTP peuvent être intercalés sur une connexion TCP. Il y a beaucoup de réponses ici. Deux autres points mineurs:

RFC 4588 décrit comment on pourrait utiliser la retransmission avec des données RTP. La plupart des clients qui reçoivent des flux RTP emploient un tampon pour tenir compte du jitter dans le réseau qui est typiquement de 1-5 secondes long et qui signifie qu'il y a du temps disponible pour une retransmission pour recevoir les données désirées.

le trafic RTP peut être intercalé sur une connexion TCP. Dans la pratique, lorsque cela est fait, la différence entre la RTP intercalée (c.-à-d. sur TCP) et la RTP envoyée sur UDP est la façon dont ces deux-là fonctionnent sur un réseau à perte avec une bande passante insuffisante disponible pour l'utilisateur. Le flux TCP entrelacé finira par être saccadé alors que le joueur attend continuellement dans un État de tampon que les paquets arrivent. Selon le joueur, il peut aller de l'avant pour rattraper. Avec une connexion RTP, vous obtiendrez des artefacts (frottement/déchirement) dans le vidéo.

UDP est souvent utilisé pour différents types de trafic en temps réel qui n'a pas besoin d'un ordre strict pour être utile. Ceci est dû au fait que TCP impose une commande avant de passer des données à une application (par défaut, vous pouvez contourner cela en paramétrant le pointeur URG, mais personne ne semble jamais le faire) et cela peut être hautement indésirable dans un environnement où vous préféreriez obtenir des données en temps réel actuelles plutôt que d'obtenir de vieilles données de manière fiable.

RTP est assez insensible à la perte de paquets, donc il ne nécessite pas la fiabilité de TCP.

UDP a moins de frais généraux pour les en-têtes de sorte qu'un paquet peut transporter plus de données, de sorte que la bande passante du réseau est utilisée plus efficacement.

UDP permet également la transmission rapide des données.

Donc UDP est le choix évident dans ce type de cas.

en plus de toutes les autres bonnes et bonnes réponsescet article donne une bonne compréhension des différences entre TCP et UDP.

UDP est utilisé partout où des données sont envoyées, qui n'ont pas besoin d'être exactement reçues sur la cible, ou où aucune connexion stable n'est nécessaire.

TCP est utilisé si les données doivent être exactement reçues, bit Pour bit, pas de perte de bits.

pour le streaming vidéo et sonore, certains bits qui sont perdus sur le chemin n'affectent pas le résultat d'une manière, qui est mentionable, certains pixels défaillants dans l'image d'un stream, rien qui affecte un utilisateur, sur les DVD le débit binaire perdu est plus élevé.

juste une remarque: Chaque paquet envoyé dans un flux RTP reçoit un numéro un plus élevé que son prédécesseur.Cela permet à thr destination de déterminer si des paquets sont manquants. Si un paquet est embrumé, la meilleure action à prendre pour la destination est d'approximer la valeur manquante par interpolation. La rétrodiffusion n'est pas une option proctical puisque le paquet retransmis serait trop tard pour être utile.

je voudrais ajouter rapidement à ce que Matt H a dit en réponse à la réponse de Stobor. Matt h a mentionné que les paquets RTP sur les paquets UDP peuvent être checksum'ed de sorte que s'ils sont corrompus, ils obtiendront du resent. C'est en fait une fonctionnalité optionnelle sur la plupart des PBX. Dans Asterisk, par exemple, vous pouvez activer / désactiver les checksums sur votre RTP sur le trafic UDP dans le rtp.fichier de configuration conf avec la ligne suivante:

rtpchecksums=yes ; or no if you prefer

Cheers!