UDP 并发丢包问题

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

解决方案 »

  1.   

    主要是服务器在转发给接受客户端的时候丢包，我们有序列号，到600个接收端，丢包率几乎达到50%，使用linux服务器
      

  2.   

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

  3.   

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

  4.   

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

  5.   

    本帖最后由 wenxy1 于 2008-09-24 09:48:19 编辑
      

  6.   

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

  7.   

    一般不会是发送慢的原因，而是需要拥赛控制。有机会可以聊一下。msn: ruby.li#wswtek.com
      

  8.   

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

  9.   

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

  10.   

    UDP一定要有拥塞控制才能最大限量的不丢包
    而想每个包都送到，则要有重传机制  (排除网线被拔，没有网卡等情况...)这两样东西，tcp都有，所以出现了楼主所说的描述
      

  11.   

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