Pourquoi RTP utilise-t-il UDP au lieu de TCP?
Je voulais savoir pourquoi UDP est utilisé dans RTP plutôt que TCP?. Les principaux outils VoIP ont utilisé uniquement UDP car j'ai piraté une partie de l'OSS VoIP.
Comme l'a souligné DJ, TCP consiste à obtenir un flux de données fiable, et ralentira la transmission et retransmettra les paquets corrompus, afin d'y parvenir.
UDP ne se soucie pas de la fiabilité de la communication et ne ralentira ni ne retransmettra les données.
Si votre application a besoin d'un flux de données fiable, par exemple, pour récupérer un fichier à partir d'un serveur Web, vous choisissez TCP.
Si votre application ne se soucie pas des paquets corrompus ou perdus et que vous n'avez pas besoin d'engager des frais supplémentaires pour fournir une fiabilité supplémentaire, vous pouvez choisir UDP à la place.
La VoIP n'est pas améliorée de manière significative par une transmission de paquets fiable, et en fait, dans certains cas, les choses dans TCP comme la retransmission et le backoff exponentiel peuvent en fait nuire à la qualité VOIP. Par conséquent, UDP était un meilleur choix.
Beaucoup de bonnes réponses ont été données, mais je voudrais souligner une chose explicitement:
Fondamentalement, un flux de données complet est une bonne chose à avoir pour l'audio/vidéo en temps réel, mais ce n'est pas strictement nécessaire (comme d'autres l'ont souligné):
Le fait important est que certaines données qui arrivent trop tard n'ont aucune valeur. À quoi servent les données manquantes pour un cadre qui aurait dû être affiché il y a une seconde?
Si vous deviez utiliser TCP (qui garantit également le bon ordre de toutes les données), vous ne pourrez pas accéder aux données les plus à jour jusqu'à ce que l'ancienne soit Ceci est doublement mauvais: vous devez attendre la retransmission des anciennes données et les nouvelles données (qui sont maintenant retardées) seront probablement tout aussi inutiles.
Donc RTP fait une sorte de transmission au mieux en ce sens qu'il essaie de transférer toutes les données disponibles à temps, mais n'essaie pas de retransmettre les données qui ont été perdues/corrompues pendant le transfert ( *). Cela continue avec la vie et espère que les données actuelles les plus importantes y parviendront correctement.
(*) en fait, je ne connais pas les spécificités de RTP. Peut-être qu'il essaie de retransmettre, mais s'il le fait, il ne sera pas aussi agressif que TCP est (qui n'acceptera jamais aucune donnée perdue).
Les autres ont raison, mais ils ne vous disent pas vraiment la VRAIE raison. Saua sorte d'indices, 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 étiez arrêté. Vous "observez" simplement le signal pendant sa diffusion, et si vous ne pouvez pas observer à tout moment, vous le perdez.
La raison en est simple. Retard. VOIP essaie très fort de minimiser la quantité de retard à partir du moment où quelqu'un parle dans une extrémité et vous obtenez de votre côté, et votre réponse en retour. Sinon, à 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 augmentait continuellement jusqu'à ce qu'il devienne inutile.
N'oubliez pas que chaque retard d'une retransmission doit être relu, ce qui entraîne le retard de nouvelles données, puis une autre erreur entraîne un retard encore plus important. La seule solution réalisable consiste à simplement supprimer toutes les données qui ne peuvent pas être affichées en temps réel.
Un délai de 1 seconde à compter de la retransmission signifierait que cela prendrait maintenant 1 seconde entre le moment où j'ai dit quelque chose et ce que vous avez entendu. Un deuxième délai de 1 seconde signifie maintenant qu'il est de 2 secondes à partir du moment où je dis quelque chose jusqu'à ce que vous l'entendiez. Ceci est cumulatif car les données sont lues au même rythme auquel elles sont prononcées, etc.
Le RTP pourrait être orienté connexion, mais il faudrait alors supprimer (ou ignorer) les données pour suivre les erreurs de retransmission de toute façon, alors pourquoi s'embêter avec la surcharge supplémentaire?
Techniquement, les paquets RTP peuvent être entrelacés sur une connexion TCP. Il y a beaucoup de bonnes réponses données ici. Deux points mineurs supplémentaires:
La RFC 4588 décrit comment utiliser la retransmission avec des données RTP. La plupart des clients qui reçoivent des flux RTP utilisent un tampon pour tenir compte de la gigue dans le réseau qui dure généralement de 1 à 5 secondes et qui signifie qu'il y a du temps disponible pour une retransmission pour recevoir les données souhaitées.
Le trafic RTP peut être entrelacé sur une connexion TCP. Dans la pratique, lorsque cela est fait, la différence entre RTP (c'est-à-dire via TCP) entrelacé (c'est-à-dire via TCP) et RTP envoyé via UDP est la façon dont ces deux performances sur un réseau avec perte avec une bande passante insuffisante disponible pour l'utilisateur . Le flux TCP entrelacé finira par être saccadé car le joueur attend continuellement dans un état de mise en mémoire tampon que les paquets arrivent. Selon le joueur, il peut avancer pour rattraper son retard. Avec une connexion RTP, vous obtiendrez des artefacts (maculage/déchirure) dans la vidéo.
UDP est souvent utilisé pour différents types de trafic en temps réel qui n'ont pas besoin d'un ordre strict pour être utiles. C'est parce que TCP applique un ordre avant de passer des données à une application (par défaut, vous pouvez contourner cela en définissant le pointeur URG, mais personne ne semble jamais le faire)) et cela peut être hautement indésirable dans un environnement où vous préférez obtenir les données en temps réel actuelles que les anciennes données de manière fiable.
RTP est assez insensible à la perte de paquets, il ne nécessite donc pas la fiabilité de TCP.
UDP a moins de surcharge pour les en-têtes afin qu'un seul paquet puisse transporter plus de données, de sorte que la bande passante du réseau est utilisée plus efficacement.
UDP permet également une transmission rapide des données.
UDP est donc le choix évident dans des cas comme celui-ci.
En plus de toutes les autres réponses sympas et correctes cet article donne une bonne compréhension des différences entre TCP et UDP.
UDP est utilisé partout où les données sont envoyées, qui n'ont pas besoin d'être reçues exactement sur la cible, ou lorsqu'aucune connexion stable n'est nécessaire.
TCP est utilisé si les données doivent être reçues exactement, bit pour bit, sans perte de bits.
Pour le streaming vidéo et audio, certains bits perdus en cours de route n'affectent pas le résultat d'une manière, c'est-à-dire, certains pixels échouant dans une image d'un flux, rien qui n'affecte un utilisateur, sur les DVD, le débit binaire perdu est plus haute.
Le protocole de transport en temps réel est un protocole réseau utilisé pour diffuser des médias audio et vidéo en streaming sur Internet, permettant ainsi le protocole Voice Over Internet (VoIP).
RTP est généralement utilisé avec un protocole de signalisation, tel que SIP, qui établit des connexions sur le réseau. RTP peuvent utiliser le protocole TCP (Transmission Control Protocol), mais la plupart utilisent le protocole User Datagram (UDP) à la place car UDP permet une livraison plus rapide des données.
Je voudrais ajouter rapidement ce que Matt H a dit en réponse à la réponse de Stobor. Matt H a mentionné que RTP sur les paquets UDP peut être une somme de contrôle afin que s'ils sont corrompus, ils seront renvoyés. C'est en fait une fonctionnalité facultative sur la plupart des PBX. Dans Asterisk, par exemple, vous pouvez activer/désactiver les sommes de contrôle sur votre RTP sur le trafic UDP dans le fichier de configuration rtp.conf avec la ligne suivante:
rtpchecksums=yes ; or no if you prefer
À votre santé!
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 à la destination de déterminer si des paquets sont manquants. Si un paquet fait une erreur, le meilleur l'action à effectuer pour la destination consiste à approximer la valeur manquante par interpolation. La retransmission n'est pas une option proactive car le paquet retransmis serait trop tard pour être utile.