实测发现RTP都不如TCP快？

Question

RTP和TCP是同一层面的东西么？

Answer 1

TCP有接收包的确认机制和流量控制机制，这样基本上保证不会丢包，而RTP用udp传输的话，它只负责往出发送数据，不管对方是否接收到数据，所以需要你进行控制！还有就是你需要了解一下JRTPLib实现的机制！

Answer 2

呵呵，看来你们也没用过。JRTPLIB的流量控制就是在发送过程中加入延时等待，现在我已经做了这个控制，就是每发送10个包后暂停1秒再继续发送，而且这个已经是最快的了，不能再快了，再快的话就丢包很严重，例如每发送10个包后暂停半秒再继续发送或者每发送11个包后暂停1秒再继续发送，都会丢包，所以我现在这个流量控制已经是最优的，可是仍然比不是TCP快，TCP都不用加入延时等待，一下就发送过去了，而且接收端能完全接收到数据。总结的说：RTP在最优流量控制情况下仍然比不是TCP传输快速。

Answer 3

我觉得你这个测试结果只是在本机上(换句话说是在网络情况很好的情况下)   换成广域网  网络不优的环境下你用tcp传视频流实时效果应该会很差...PS：只是个人感觉  我没研究过视频方面的

Answer 4

用rtp的意义更多的在于网络状况不好的情况下，对可容忍的丢包率和视频质量间的一个成熟的平衡点把握。
当然如果用rtp over tcp的话，我个人认为这个意义就失去了。所以我觉得在网络状况不太好，但是对于视频出现部分宏块错码或者跳帧可以接受的范围内，rtp是不错的。如果网络状况很好的情况，用什么都无所谓了

Answer 5

非常感谢大家，我现在正是做音视频实时传输，目前也只能先用TCP了，过些天再研究RTP，到时回来和大家分享交流。

Answer 6

RTP如果不进行速度控制，很容易丢包，在公网条件，无线程更是丢包严重，不适合视频传输，但是对于固定流量的语音数据来说，确是最好的，原因是丢包产生的音噪可以通过算法进行，去噪，去回音。而同样的道理，在传输视频的时候，RTP在公网条件，及3G条件是不适合的。可以考虑UDP的可靠传输协议，UDX协议，UDT协议。

Answer 7

rtp 是 在udp/tcp之上的

Answer 8

rtp介绍
如果传输大数据，tcp效率优于udp

Answer 9

这个不见得，在传输效率上，大多数的时候，UDP是优于TCP的，我这有测试程序，有兴趣的可以和TCP对比测试。http://www.goodudx.com/web/index.php/site/download/6

Answer 10

这个不见得，在传输效率上，大多数的时候，UDP是优于TCP的，我这有测试程序，有兴趣的可以和TCP对比测试。http://www.goodudx.com/web/index.php/site/download/6
建议你看看《tcp/ip高效编程》

Answer 11

这个不见得，在传输效率上，大多数的时候，UDP是优于TCP的，我这有测试程序，有兴趣的可以和TCP对比测试。http://www.goodudx.com/web/index.php/site/download/6
建议你看看《tcp/ip高效编程》我测试过不下10000次，UDX和TCP的对比了。

Answer 12

这个不见得，在传输效率上，大多数的时候，UDP是优于TCP的，我这有测试程序，有兴趣的可以和TCP对比测试。http://www.goodudx.com/web/index.php/site/download/6
建议你看看《tcp/ip高效编程》我测试过不下10000次，UDX和TCP的对比了。

设置tcp的缓冲去了吗？

Answer 13

tcp和udp性能差异的原因知道吗？

Answer 14

udp 可靠传输，1对1 ，我使用了特殊的优化 [ETudp , 提供库，使用示范代码 ， 以及现成的测试程序 UdpMark.exe]，在i7 ddr3 1600 win8 64bit环境下，本机器极限传输能达到的数字也就是 205-215 MB/s , 也就是相当于 最高输出 2Gbps+
关于这个性能的限制造成的原因，我在  udp可靠传输那些事 一文里都已经给出了
udp可靠传输，在目前通过的系统调用接口以及实现下，无法超过TCP的jrt lib 不是这么用的，它的实现只是一个框架，投入商用，你需要替换里面的传输协议为自己的协议，有很多人已经做了这方面的工作，可以到海外网站去搜一下已经替换好的

Answer 15

在我本机I7cpu的测试下，本机可以达到收发250MB左右每秒

Answer 16

我那个测试是在2012年做的,硬件条件不如现在,
而且测试程序是完全按照Internet 应用环境设置的缓冲10个MTU[包],
本地传输对缓冲大小是很敏感的,我设置成64K(约 60个mtu) 
也可以加速,或者把块传输改成流,同样可以加速,但是这种缓冲大小在Internet上没有意义的,1对1的udp可靠传输实现多的是,我只用来试验新技术,做测试,不想投入太多,没什么意义
只是看到楼主这个主题,进来谈点看法.

Answer 17

还变的真快,2012年发贴单路达不到200MB,眼睛一眨就达到了
wwwllg
#19 得分：20 回复于： 2012-12-13 16:38:34
多条线程发送，对于本机，确实可以达到并超过200M,这个是指的总的接收流量。比如，一个服务，多个客户发送，多个客户流量相加，可以达到200多。目前来说，不管是IOCP,还是SENDTO,我还没有见过200M/S的，单个可靠连接，注意这个前提。
在我的I7 CPU, 3.5GHZ的环境下，已经相当牛B了吧。VTCP可以传到180MB/S,UDX可以传到156MB/秒，VTCP是使用的IOCP,UDX使用的是一般的Sendto.单条连接。所以，我认为，现在主流的系统，目前UDP不会超过250MB/S。 

Answer 18

to楼上：
在我的机器上，就可以跑250MB/秒，我觉得主要原因在于连接处理逻辑上是单线程，是被CPU主频限制了。
并不是系统API的问题。你有你的意见，我保持自己的观点，这就是为什么，不同性能的机器，速度不一样的根本原因。可靠传输并没有你想象的简单，你只是做到了可靠，并不高效（我主观认为，你可以认为我是错的），可靠协议最大的用处，并不只是在内网这样的好的条件的网络，而是在公网条件，无线WIFI,3G条件下，发挥更好的吞吐性，在实时应用，比如监控中的IPC，手持设备上，保持协议的一致性，发挥更好的实时性，吞吐量和稳定性相对传统的协议(TCP,RTSP/RTP)之类。可靠的难点不在可靠，而在于他要充份利用现有代宽，并能实时的反馈发送方的信息，让APP做出相应对策。如果你认为我的观点错误，完全可以拿你自己写的协议和我的协议对比，随时欢迎你比较，我们一起讨论原因及现象。

Answer 19

实时音视频传输有几个特点：数据量大，实时性要求高，但是可容忍适当丢包率，即一段语音中丢一两个包不会产生明显失真，或者部分失真也并不影响使用。
LZ的测试可能存在几个问题：
1、数据150K是否合适：低分辨率显示器640*480，每秒30帧，传输的数据量是640*480*32*30，即每秒需要传输27M左右的数据。
2、网络环境过于单纯：需考虑高负载网络导致的延时抖动、网络丢包问题。实时音视频传输使用RTP意义在于：
1、实时音视频传输需要高效的数据传输效率，声卡编码压缩之后的大数据不断的产生需要及时的传输出去，TCP有效载荷率不高；
2、TCP可靠性的保证一点是流量控制，直接导致延时加大，抖动频发，实时性下降；
3、TCP丢包重传以尽力保证每一个包不丢失对于实时音视频通信并不十分必要，且重传机制直接降低实时性；此外，RTP虽然名义上与TCP、UDP一样为传输层协议，但是使用上RTP可有开发人员进一步的实现控制，已保证其通信的稳定性。