为什么RTP使用UDP而不是TCP？

我想知道为什么在RTP而不是TCP中使用UDP？主要的VoIP工具只使用UDP,因为我攻击了一些VoIP OSS.

1> Stobor..：

---

正如DJ指出的那样,TCP是为了获得可靠的数据流,并且会减慢传输速度,并重新传输损坏的数据包,以实现这一目标.

UDP不关心通信的可靠性,也不会减慢或重新传输数据.

如果您的应用程序需要可靠的数据流,例如,要从Web服务器检索文件,请选择TCP.

如果您的应用程序不关心数据包损坏或丢失,并且您不需要承担额外的开销以提供额外的可靠性,则可以选择UDP.

可靠的数据包传输并没有显着改善VOIP,事实上,在某些情况下,像重传和指数退避这样的TCP事件实际上会损害VOIP质量.因此,UDP是更好的选择.

---

我想指出UDP确实提供了数据包的校验和.因此,如果您收到UDP消息,那就是发送的内容.但如果它很糟糕然后被丢弃,你的应用程序将无法看到它.TCP会要求另一端重新传输.在某些情况下,TCP并不总是最有效(例如,将同一文件传输到多个目的地),因此某些应用程序级协议是在UDP之上构建的.

2> Joachim Saue..：

---

已经给出了很多好的答案,但我想明确指出一件事:

基本上,完整的数据流对于实时音频/视频来说是一件好事,但它并非绝对必要(正如其他人所指出的那样):

重要的事实是,一些到达太晚的数据毫无价值.应该在一秒钟之前显示的帧的丢失数据有什么用？

如果您使用TCP(这也保证了所有数据的正确顺序),那么在旧数据正确传输之前,您将无法获得更新的数据.这是非常糟糕的:你必须等待旧数据的重新传输,而新数据(现在被推迟)可能同样毫无价值.

因此,RTP进行某种尽力传输,因为它尝试及时传输所有可用数据,但不会尝试重新传输在传输过程中丢失/损坏的数据(*).它只是继续生活,并希望更重要的当前数据正确到达那里.

(*)实际上我不知道RTP的具体细节.也许它确实尝试重新传输,但如果它确实那么它就不会像TCP那样具有攻击性(它不会接受任何丢失的数据).

3> Erik Funkenb..：

---

其他都是正确的,但是并没有真正告诉你真正的原因.Saua有点暗示,但这是一个更完整的答案.

音频和视频是实时的.如果您正在收听收音机或看电视,并且信号被中断,它就不会在您离开的地方捡起......您只是"观察"信号流,如果您无法观察它在任何时候都会失去它.

原因很简单.延迟.VOIP非常努力地减少从有人说到一端的延迟时间,并且你得到它的结果,以及你的回复.否则,当发生错误时,人发声和接收信号之间的延迟量将持续增长,直至变得无用.

请记住,必须重播每次重传的延迟,这会导致更多的数据被延迟,然后另一个错误会导致更大的延迟.唯一可行的解​​决方案是简单地删除任何无法实时显示的数据.

从重传开始延迟1秒就意味着从我说出来之前它会持续1秒直到你听到它为止.现在,第二个1秒的延迟意味着距离我说话的时间是2秒,直到你听到它为止.这是累积的,因为数据的播放速度与播放时的速率相同,等等......

RTP可能是面向连接的,但是它必须丢弃(或跳过)数据才能跟上重传错误,所以为什么还需要额外的开销呢？

4> J. Fritz Bar..：

---

从技术上讲,RTP数据包可以通过TCP连接进行交织.这里有很多很棒的答案.另外两个小问题:

RFC 4588描述了如何使用RTP数据进行重传.接收RTP流的大多数客户端使用缓冲区来计算网络中的抖动,通常为1-5秒,这意味着有可能有时间重新传输以接收所需数据.

RTP流量可以通过TCP连接进行交互.实际上,当这样做时,Interleaved RTP(即通过TCP)和通过UDP发送的RTP之间的区别在于这两者如何在可用于用户的带宽不足的有损网络上执行.当播放器持续等待缓冲状态以使数据包到达时,Interleaved TCP流将最终变得不稳定.根据玩家的不同,它可能会向前追赶.使用RTP连接,您将在视频中获得伪影(涂抹/撕裂).