UDP 并发丢包问题

[victor_cui]

有如下应用，客户端发送数据到服务器，然后服务器负责转发该数据给订阅该发送客户端信息的客户端，测试发现当接受客户端多余200个以后，随着订阅者的增加，丢包率也随之增加，发送端发送的数据量大约是60个1K左右的包每秒，测试环境为千兆网，server CPU利用率低于50%，带宽利用率这个时候也很低，如果使用TCP协议，数据都可以及时被转发，所以原因应该是UDP并发的问题，如何解决？

[lew0002]

嘿嘿，发得太快了，传输路径上的只要任何一点缓存不了那么多包，就会丢包
按时间间隔更均匀地分布网络荷载

[victor_cui]

但是linux系统没有那么高的时间分辨率啊，最小也就10ms而已，除非有在1ms级的精度才可以做适当负载分配啊，怎么办啊，郁闷之极

[lew0002]

linux随便一个api都是微秒级的精度啊，比如select

[victor_cui]

是的，肯定是我们程序的转发机制的原因，测试发现我们600个接收端转发一轮需要6ms左右，而接收到发送端的数据间隔15ms左右，也就是说系统有9ms左右的空闲，可以肯定应该是转发过程中造成的问题，而不是接收端的问题，因为存在600个接收端，接收这点数据绰绰有余。所以我想如果有方法把转发每个包的时间平均分布在15ms的时间范围内是最理想均衡的结果，我想这也是解决这个问题的一个办法

[UDX协议]

应该是代码问题 。

[kikyou_zk]

UDP是没有流量控制的, 发送端总是"尽可能快"地发送, 而接收端总是"尽可能快"地接收, 接收端如果因为处理逻辑复杂或者其它原因导致接收过慢, 必然有丢包问题, 其实不是中间因为传输问题丢掉了, 而是接收端主机因为接收缓冲区满而直接丢掉了.
解决办法就是每包一个ACK, 不然还能怎么办呢?

[Wenxy1]

所以原因应该是UDP并发的问题，如何解决？
-------------------------------------
1. UDP协议是不可靠的，TCP是可靠的当然能保证到达嘛。
2. UDP丢包的原因有多种，我列出几种:
1) 交换机的缓存用完（也就是交换机所在的网络非常忙)。
2）路由器存储转发时,由于某些原因(比如IP分组的头部设置了不分片标志,而IP的分组的长度超过了它的MTU),丢弃一些UDP包.
3) 接收UDP包的机器的UDP socket缓存已满.
其它情况...

所以,你虽然在千兆网,但还是存在忙的情况(人家高速公路还堵车呢!).
3. 解决方法,应用程序设置一个可靠传输的机制,可以参考一下TCP的实现.:)

[Wenxy1]

我修改了一下我的回答,使它更严谨.
关键在于UDP协议不可靠且不面向连接的传输层协议,TCP协议是面向连接的可靠的传输层协议.

[UDX协议]

一般不会是发送慢的原因，而是需要拥赛控制。

有机会可以聊一下。msn: ruby.li#wswtek.com

[niyubao2233]

用什么语言实现的?

[Wenxy1]

[Quote=引用 14 楼 victor_cui 的回复:]
是的，肯定是我们程序的转发机制的原因，测试发现我们600个接收端转发一轮需要6ms左右，而接收到发送端的数据间隔15ms左右，也就是说系统有9ms左右的空闲，可以肯定应该是转发过程中造成的问题，而不是接收端的问题，因为存在600个接收端，接收这点数据绰绰有余。所以我想如果有方法把转发每个包的时间平均分布在15ms的时间范围内是最理想均衡的结果，我想这也是解决这个问题的一个办法
[/Quote]
楼主，你没有找到出现这个问题的主要原因！！！。

[Wenxy1]

[Quote=引用 14 楼 victor_cui 的回复:]
是的，肯定是我们程序的转发机制的原因，测试发现我们600个接收端转发一轮需要6ms左右，而接收到发送端的数据间隔15ms左右，也就是说系统有9ms左右的空闲，可以肯定应该是转发过程中造成的问题，而不是接收端的问题，因为存在600个接收端，接收这点数据绰绰有余。所以我想如果有方法把转发每个包的时间平均分布在15ms的时间范围内是最理想均衡的结果，我想这也是解决这个问题的一个办法
[/Quote]
楼主，你没有找到出现这个问题的主要原因！！！。

[Wenxy1]

[Quote=引用 14 楼 victor_cui 的回复:]
是的，肯定是我们程序的转发机制的原因，测试发现我们600个接收端转发一轮需要6ms左右，而接收到发送端的数据间隔15ms左右，也就是说系统有9ms左右的空闲，可以肯定应该是转发过程中造成的问题，而不是接收端的问题，因为存在600个接收端，接收这点数据绰绰有余。所以我想如果有方法把转发每个包的时间平均分布在15ms的时间范围内是最理想均衡的结果，我想这也是解决这个问题的一个办法
[/Quote]
楼主，你没有找到出现这个问题的主要原因！！！。

[Wenxy1]

晕，怎么重复回答这么多？？？

[dengfeng_liu]

这样设计上就是有问题的啊。


订阅终端太多，用点对点方式通信会造成效率很低。

为什么不考虑用组播的方式通信？

[netelife]

才几百个终端，算什么多啊，设计问题，如果怕丢包，就不应该用UDP，如果用了UDP，丢包的事情应该有程序自己来解决，因为这个协议本身就没有考虑丢包的问题。

[wxq4100798]

[Quote=引用 20 楼 dengfeng_liu 的回复:]
这样设计上就是有问题的啊。


订阅终端太多，用点对点方式通信会造成效率很低。

为什么不考虑用组播的方式通信？
[/Quote]
组播正解

[贵子潘]

UDP一定要有拥塞控制才能最大限量的不丢包
而想每个包都送到，则要有重传机制 (排除网线被拔，没有网卡等情况...)

这两样东西，tcp都有，所以出现了楼主所说的描述

[AthlonxpX86]

如果UDP的话应该用广播模式，丢包是因为UDP没有3次握手，请求传输返回请求，UDP要做到无误就的自己做握手

[wuleeemail]

组播是不错，但是组播应该是不能跨网段的，好像你那600多个接收端不会都在一个网段里吧？闲聊！