为什么RTP使用UDP而不是TCP？
我想知道为什么RTP中使用UDP而不是TCP？ 主要 VoIP 工具仅使用 UDP，因为我破解了一些 VoIP OSS。
I wanted to know why UDP is used in RTP rather than TCP ?. Major VoIP Tools used only UDP as i hacked some of the VoIP OSS.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
正如DJ所指出的，TCP是为了获得可靠的数据流，并且会减慢传输速度，并重新传输损坏的数据包，以实现这一目标。
UDP不关心通信的可靠性，并且不会减慢或重新传输数据。
如果您的应用程序需要可靠的数据流（例如，从网络服务器检索文件），您可以选择 TCP。
如果您的应用程序不关心数据包损坏或丢失，并且您不需要承担额外的开销来提供额外的可靠性，则可以选择 UDP。
可靠的数据包传输并没有显着改善 VOIP，事实上，在某些情况下，TCP 中的重传和指数退避等操作实际上会损害 VOIP 质量。 因此，UDP是更好的选择。
As DJ pointed out, TCP is about getting a reliable data stream, and will slow down transmission, and re-transmit corrupted packets, in order to achieve that.
UDP does not care about reliability of the communication, and will not slow down or re-transmit data.
If your application needs a reliable data stream, for example, to retrieve a file from a webserver, you choose TCP.
If your application doesn't care about corrupted or lost packets, and you don't need to incur the additional overhead to provide the additional reliability, you can choose UDP instead.
VOIP is not significantly improved by reliable packet transmission, and in fact, in some cases things in TCP like retransmission and exponential backoff can actually hurt VOIP quality. Therefore, UDP was a better choice.
已经给出了很多好的答案，但我想明确指出一件事：
基本上，完整的数据流对于实时音频/视频来说是一件好事，但它并不是严格必要的（正如其他人指出的那样） out)：
重要的事实是，一些到达太晚的数据是毫无价值的。 对于应该在一秒钟前显示的帧来说，丢失的数据有什么用呢？
如果您要使用 TCP（它也保证所有数据的正确顺序），那么在旧数据正确传输之前，您将无法获取更新的数据。 这是双重糟糕的：您必须等待旧数据的重新传输，而新数据（现在已延迟）可能同样毫无价值。
因此，RTP 会进行某种尽力而为的传输，尝试及时传输所有可用数据，但不会尝试重新传输传输期间丢失/损坏的数据 (*)。 它只是继续生活，并希望更重要的当前数据能够正确到达那里。
(*)实际上我不知道RTP的具体情况。 也许它确实尝试重新传输，但如果这样做，它就不会像 TCP 那样激进（它永远不会接受任何丢失的数据）。
A lot of good answers have been given, but I'd like to point one thing out explicitly:
Basically a complete data stream is a nice thing to have for real-time audio/video, but its not strictly necessary (as others have pointed out):
The important fact is that some data that arrives too late is worthless. What good is the missing data for a frame that should have been displayed a second ago?
If you were to use TCP (which also guarantees the correct order of all data), then you wouldn't be able to get to the more up-to-date data until the old one is transmitted correctly. This is doubly bad: you have to wait for the re-transmission of the old data and the new data (which is now delayed) will probably be just as worthless.
So RTP does some kind of best-effort transmission in that it tries to transfer all available data in time, but doesn't attempt to re-transmit data that was lost/corrupted during the transfer (*). It just goes on with life and hopes that the more important current data gets there correctly.
(*) actually I don't know the specifics of RTP. Maybe it does try to re-transmit, but if it does then it won't be as aggressive as TCP is (which won't ever accept any lost data).
其他人是正确的，但并没有真正告诉你真正的原因。 Saua 对此有所暗示，但这里有一个更完整的答案。
音频和视频是实时的。 如果您正在听广播或看电视，并且信号被中断，它不会从您中断的地方继续。您只是在“观察”信号流，如果您无法观察到在任何给定的时间，你都会失去它。
原因，很简单。 延迟。 VOIP 非常努力地尽量减少从某人向一端讲话、您在另一端收到声音以及您回复的延迟时间。 否则，随着错误的发生，从说话到收到信号之间的延迟量会不断增加，直到变得毫无用处。
请记住，每次重传造成的延迟都必须重播，这会导致进一步的数据延迟，然后另一个错误会导致更大的延迟。 唯一可行的解决方案是简单地删除所有无法实时显示的数据。
重传延迟 1 秒意味着从我说某件事到你听到它现在需要 1 秒。 现在，第二个 1 秒延迟意味着从我说某件事到您听到它有 2 秒。 这是累积性的，因为数据以与说出的速率相同的速率播放，等等...
RTP 可能是面向连接的，但无论如何它都必须丢弃（或跳过）数据以跟上重传错误，那么为什么还要担心额外的开销呢？
The others are correct, however the don't really tell you the REAL reason why. Saua kind of hints at it, but here's a more complete answer.
Audio and Video is real-time. If you are listening to a radio, or watching TV, and the signal is interrupted, it doesn't pick up where you left off.. you're just "observing" the signal as it streams, and if you can't observe it at any given time, you lose it.
The reason, is simple. Delay. VOIP tries very hard to minimize the amount of delay from the time someone speaks into one end and you get it on your end, and your response back. Otherwise, as errors occured, the amount of delay between when the person spoke and when the signal was received would continuously grow until it became useless.
Remember, each delay from a retransmission has to be replayed, and that causes further data to be delayed, then another error causes an even greater delay. The only workable solution is to simply drop any data that can't be displayed in real-time.
A 1 second delay from retransmission would mean it would now be 1 second from the time I said something until you heard it. A second 1 second delay now means it's 2 seconds from the time i say something until you hear it. This is cumulative because data is played back at the same rate at which it is spoken, and so on...
RTP could be connection oriented, but then it would have to drop (or skip) data to keep up with retransmission errors anyways, so why bother with the extra overhead?
从技术上讲，RTP 数据包可以通过 TCP 连接进行交织。 这里给出了很多很棒的答案。 另外两个小要点：
RFC 4588 描述了如何对 RTP 数据使用重传。 大多数接收 RTP 流的客户端都会使用缓冲区来解决网络中的抖动问题，该缓冲区通常长度为 1-5 秒，这意味着有时间重新传输以接收所需的数据。
RTP 流量可以通过 TCP 连接进行交错。 实际上，当这样做时，交错 RTP（即通过 TCP）和通过 UDP 发送的 RTP 之间的区别在于这两者在用户可用带宽不足的有损网络上的执行方式。 当播放器持续在缓冲状态等待数据包到达时，Interleaved TCP 流最终会变得不稳定。 根据玩家的不同，它可能会向前跳跃以赶上。 通过 RTP 连接，您将在视频中出现伪影（拖尾/撕裂）。
Technically RTP packets can be interleaved over a TCP connection. There are lots of great answers given here. Two additional minor points:
RFC 4588 describes how one could use retransmission with RTP data. Most clients that receive RTP streams employ a buffer to account for jitter in the network that is typically 1-5 seconds long and which means there is time available for a retransmit to receive the desired data.
RTP traffic can be interleaved over a TCP connection. In practice when this is done, the difference between Interleaved RTP (i.e. over TCP) and RTP sent over UDP is how these two perform over a lossy network with insufficient bandwidth available for the user. The Interleaved TCP stream will end up being jerky as the player continually waits in a buffering state for packets to arrive. Depending on the player it may jump ahead to catch up. With an RTP connection you will get artifacts (smearing/tearing) in the video.
UDP 通常用于不需要严格排序的各种类型的实时流量。 这是因为 TCP 在将数据传递到应用程序之前强制执行排序（默认情况下，您可以通过设置 URG 指针来解决此问题，但似乎没有人这样做），并且在您需要的环境中，这可能是非常不可取的。宁愿获取当前的实时数据，也不愿可靠地获取旧数据。
UDP is often used for various types of realtime traffic that doesn't need strict ordering to be useful. This is because TCP enforces an ordering before passing data to an application (by default, you can get around this by setting the URG pointer, but no one seems to ever do this) and that can be highly undesirable in an environment where you'd rather get current realtime data than get old data reliably.
RTP对丢包相当不敏感，因此不需要TCP的可靠性。
UDP 的报头开销较少，因此一个数据包可以承载更多数据，从而更有效地利用网络带宽。
UDP 还提供快速数据传输。
因此，在这种情况下，UDP 是显而易见的选择。
RTP is fairly insensitive to packet loss, so it doesn't require the reliability of TCP.
UDP has less overhead for headers so that one packet can carry more data, so the network bandwidth is utilized more efficiently.
UDP provides fast data transmission also.
So UDP is the obvious choice in cases such as this.
实时传输协议是一种网络协议，用于通过互联网传送流式音频和视频媒体，从而实现互联网协议语音 (VoIP)。
RTP 通常与信令协议（例如 SIP）一起使用，用于跨网络建立连接。 RTP 应用程序可以使用传输控制协议 (TCP)，但大多数使用用户数据报协议 (UDP)，因为 UDP 可以更快地传输数据。
The Real-time Transport Protocol is a network protocol used to deliver streaming audio and video media over the internet, thereby enabling the Voice Over Internet Protocol (VoIP).
RTP is generally used with a signaling protocol, such as SIP, which sets up connections across the network. RTP applications can use the Transmission Control Protocol (TCP), but most use the User Datagram protocol (UDP) instead because UDP allows for faster delivery of data.
UDP 用于发送数据、不需要在目标上准确接收数据或不需要稳定连接的情况。
如果需要逐位准确接收数据且不丢失位，则使用 TCP。
对于视频和声音流，途中丢失的一些比特不会以某种方式影响结果，值得注意的是，流的图片中的一些像素失败，不会影响用户，在 DVD 上丢失的比特率是更高。
UDP is used wherever data is send, that does not need to be exactly received on the target, or where no stable connection is needed.
TCP is used if data needs to be exactly received, bit for bit, no loss of bits.
For Video and Sound streaming, some bits that are lost on the way do not affect the result in a way, that is mentionable, some pixels failing in a picture of a stream, nothing that affects a user, on DVDs the lost bit rate is higher.
只是一个评论：
RTP 流中发送的每个数据包都会被赋予一个比其前一个数据包高 1 的编号。这允许目的地确定是否有任何数据包丢失。
如果数据包丢失，目的地采取的最佳操作是通过插值来近似丢失的值。
重传不是一个实际的选择，因为重传的数据包太晚而无用。
just a remark:
Each packet sent in an RTP stream is given a number one higher than its predecessor.This allows thr destination to determine if any packets are missing.
If a packet is mising, the best action for the destination to take is to approximate the missing vaue by interpolation.
Retranmission is not a proctical option since the retransmitted packet would be too late to be useful.
我想快速补充一下 Matt H 在回应 Stobor 的回答时所说的话。 Matt H 提到，RTP over UDP 数据包可以进行校验和，这样如果它们被损坏，它们将被重新发送。 这实际上是大多数 PBX 上的可选功能。 例如，在 Asterisk 中，您可以使用以下行在 rtp.conf 配置文件中启用/禁用基于 UDP 的 RTP 流量的校验和：
干杯！
I'd like to add quickly to what Matt H said in response to Stobor's answer. Matt H mentioned that RTP over UDP packets can be checksum'ed so that if they are corrupted, they will get resent. This is actually an optional feature on most PBXs. In Asterisk, for example, you can enable / disable checksums on your RTP over UDP traffic in the rtp.conf configuration file with the following line:
Cheers!