最近打算优化原来写的一个可靠UDP的模块，在测试中发现重传率居高不下，希望有牛人指点一二大致机制:
发送方发送UDP包后缓存此包到一缓冲池，接收方收到后立即反馈成功接收消息，发送方收到反馈后将缓冲池中对应的缓冲包置为空闲，如果发送方在一定时间内未收到反馈则重传相应的包
发送速率以及重传延迟时间都有根据重传率以及接收方收到数据包的冗余率进行动态调整问题: 在网络状况较差的情况下(比如电信与网通之间)，发送方的重传率经常在20%以上，甚至达到50%(因为我的目标环境要求即时性较高，所以我设置合法的接收冗余率为5%以内)，按此推理，如果重传率达到50%，而接收方冗余率在5%以内，那丢包率就达到了45%，而在网络流畅的环境下(比如电信与电信或者网通与网通)，重传率一般小于0.1%，而接收方的冗余率则在0.02%左右，但奇怪的是我用ping测试时，即使电信与网通之间，丢包率也不过3%-12%之间，并且我设置ICMP包大小为1464(MTU为1492，即满载)，尽量仿真UDP的测试环境，而且测试环境下UDP的发送速率也跟ping的ICMP包速率相似，发送/接收缓冲区未满，请问UDP包和ICMP包的丢包率为何会有如此之大的差别，还请高人指点迷津TIA
发送方发送UDP包后缓存此包到一缓冲池，接收方收到后立即反馈成功接收消息，发送方收到反馈后将缓冲池中对应的缓冲包置为空闲，如果发送方在一定时间内未收到反馈则重传相应的包
发送速率以及重传延迟时间都有根据重传率以及接收方收到数据包的冗余率进行动态调整问题: 在网络状况较差的情况下(比如电信与网通之间)，发送方的重传率经常在20%以上，甚至达到50%(因为我的目标环境要求即时性较高，所以我设置合法的接收冗余率为5%以内)，按此推理，如果重传率达到50%，而接收方冗余率在5%以内，那丢包率就达到了45%，而在网络流畅的环境下(比如电信与电信或者网通与网通)，重传率一般小于0.1%，而接收方的冗余率则在0.02%左右，但奇怪的是我用ping测试时，即使电信与网通之间，丢包率也不过3%-12%之间，并且我设置ICMP包大小为1464(MTU为1492，即满载)，尽量仿真UDP的测试环境，而且测试环境下UDP的发送速率也跟ping的ICMP包速率相似，发送/接收缓冲区未满，请问UDP包和ICMP包的丢包率为何会有如此之大的差别，还请高人指点迷津TIA
我指定了ping包的大小,ping的ICMP包为满负荷的包: ping x.x.x.x -f -l 1464 -t,我测试时UDP包和ICMP包都为满负荷
ICMP包: MTU-IP首部-ICMP首部, 在我的测试环境下此值为1464
UDP包: MTU-IP首部-UDP首部因此应该不会出现"再次会片"
即使我将UDP的测试数据限制在几个字节,在网络状态较差的情况下丢包率与满载的数据包情形相差不大,我想这个还不是关键问题欢迎大家继续讨论...
虽然不能保证环境完全一样,在数据传输量如此之小的情况下,应该是影响不大的
至于丢包率的计算,最简单地说,一段时间内发送方发送的数据包总数与接收方接收的数据包总数的一个比例,尚且不考虑丢包反馈的情况,UDP的丢包都明显高于ping的丢包
wenxy1所说TOS最小延时,但还不是问题的关键,即使转发速度快一些,但似乎对丢包率应该不会有如此大的影响
已经考虑了你所说的处理，此机制的关键问题是怎么获取一个最佳的处理，其实也不存在某一固定的最理想的状态，根据网络环境、目标应用，此处理还是有挺大差别的
我做了一个算法，可以根据网络环境、目标应用事先设置一些参数，在实际运行过程中根据这个参数动态的调整发送速率以及重传延时等，正常使用没有问题(至于开销与效率方面，我还没做对比，但总体运行良好)，但我的问题不在于些，我想知道的是为何UDP包的丢包会高于ICMP包的丢包，按我的理解，在发送速率以及发包频率较低的情况下，UDP在传输层到应用层不会导致丢包率的上升，那么在网络层及以下是否对ICMP有特殊的、不同于UDP传输的机制我就不得而知了，所以想请高人指点一二
慢启动算，Nagle算法， 快速重传算，快速恢复算法等。
另外，对比过自己的UDP模块，跟现成的TCP传输，哪个效率更高了吗？如果TCP的效率更高，还是采用TCP的好，毕竟TCP实现是由很多人开发和测试过的产品，自己做的肯定没有人家做的要好吧。
2. 因为我们的可靠UDP主要用于P2P的传输，而我们采用TCP的P2P效果一直不理想，所以最终放弃了TCP，也考虑过一些成熟的可靠UDP方案，比如UDT，但效果也不是很理想
这里提点建议
1."接收方收到后立即反馈成功接收消息"
这就意味着接收方也要发送同等数量的包(虽然大小不同),网络开销太大,如果同时传送多个文件,影响会很大..
建议接收方判断丢包的情况,然后请求丢失的包.
2.我感觉UDP的传输速度(保证完整性的前提)很难超过TCP,我在远距离传文件时(珠海-北京),P2P的速度比TCP(服务器中转)的速度要慢5倍甚至更多,所以还是建议TCP,如果NAT穿透不理想,可以考虑服务器中转..
因为数据量不大，正常情况下每秒不超过10K的数据，使用发送+即时反馈的机制所引起的开销不会太大，所以暂时还是使用这种机制，但关键还是丢包
至于你说的服务器中转方式，我的机制中也使用了这种方式，主要是用于NAT穿透不成功或者速度太慢的情况下使用，为了让一台服务器能够维护更多的客户端，我尽量使用P2P，如果全部使用服务器中转，那势必造成服务器负担陡增
另外，我们的机制还有UPnP的机制，如果客户端支持UPnP，那会优先使用UPnP映射端口来替代NAT穿透，这样也可方便在两个客户端之间建立TCP连接，但总体感觉速度不理想，由其是像电信跟网通之间的这类应用...