最近在做一个项目,在这之前,做了个验证程序. 
发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象. 
纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了. 

我用过sleep(10),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失.

你试着用阻塞模式吧... 
select...我开始的时候好像也遇到过..不过改为阻塞模式后就没这个问题了...

采用回包机制,每个发包必须收到回包后再发下一个

UDP丢包是正常现象，因为它是不安全的。

丢包的原因我想并不是“服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了”，而是服务器端的socket接收缓存满了(udp没有流量控制，因此发送速度比接收速度快，很容易出现这种情况)，然后系统就会将后来收到的包丢弃。你可以尝试用setsockopt()将接收缓存(SO_RCVBUF)加大看看能不能解决问题。

服务端采用多线程pthread接包处理

UDP是无连接的，面向消息的数据传输协议，与TCP相比，有两个致命的缺点，一是数据包容易丢失，二是数据包无序。 
要实现文件的可靠传输，就必须在上层对数据丢包和乱序作特殊处理，必须要有要有丢包重发机制和超时机制。 
常见的可靠传输算法有模拟TCP协议，重发请求（ARQ）协议，它又可分为连续ARQ协议、选择重发ARQ协议、滑动窗口协议等等。 

如果只是小规模程序，也可以自己实现丢包处理，原理基本上就是给文件分块，每个数据包的头部添加一个唯一标识序号的ID值，当接收的包头部ID不是期望中的ID号，则判定丢包，将丢包ID发回服务端，服务器端接到丢包响应则重发丢失的数据包。 

模拟TCP协议也相对简单，3次握手的思想对丢包处理很有帮助。

udp是不安全的，如果不加任何控制，不仅会丢失包，还可能收到包的顺序和发送包的顺序不一样。这个必须在自己程序中加以控制才行。 
收到包后，要返回一个应答，如果发送端在一定时间内没有收到应答，则要重发。

UDP本来存在丢包现象,现在的解决方案暂时考虑双方增加握手. 
这样做起来,就是UDP协议里面加上了TCP的实现方法. 
程序中采用的是pthread处理,丢包率时大时小,不稳定可靠

我感觉原因可能有两个，一个是客户端发送过快，网络状况不好或者超过服务器接收速度，就会丢包。 
第二个原因是服务器收到包后，还要进行一些处理，而这段时间客户端发送的包没有去收，造成丢包。 

解决方法，

一是   客户端降低发送速度，可以等待回包，或者加一些延迟。 
二是，服务器部分单独开一个线程，去接收UDP数据，存放在一个缓冲区中，又另外的线程去处理收到的数据，尽量减少因为处理数据延时造成的丢包。

有两种方法解决楼主的问题： 
方法一：重新设计一下协议，增加接收确认超时重发。（推荐） 
方法二：在接收方，将通信和处理分开，增加个应用缓冲区；如果有需要增加接收socket的系统缓冲区。（本方法不能从根本解决问题，只能改善）

网络丢包，是再正常不过的了。 
既然用UDP，就要接受丢包的现实，否则请用TCP。 
如果必须使用UDP，而且丢包又是不能接受的，只好自己实现确认和重传，说白了，就是自己实现TCP（当然是部分和有限的简单实现）。

UDP是而向无连接的，用户在实施UDP编程时，必须制定上层的协议，包括流控制，简单的超时和重传机制，如果不要求是实时数据，我想TCP可能会更适合你！

huangcanbao 发表于Tuesday, September 22, 2009 7:33:22 PM 举报

今天接到了电话面试，还好我的解决方案和你这位朋友的一样。1：给自己发的数据定义协议，序号 大小 数据。 2：传输过程都要进行双方验证，是否接受到正确的数据。根据传输的字节大小来管理的。

转自http://blog.csdn.net/yylklshmyt20090217/archive/2009/06/17/4275937.aspx

建议的办法是,对于大的报文自己进行一个分包和组包操作.要减少丢包率(丢包重发,同样是不小的消耗),把单包的大小定在1500字节以内,按24MBit/s的带宽最大流通量2048个包每秒,这个压力是相当小的.

丢包是很正常的，发包越大丢包的可能性就越高，与网卡速度没有必然联系，需要自己设计应答和重发机制。至于多大的数据包最合适，要在实际运行的环境中测试才能知道。程序运行过程中可以自己统计并计算丢包率，然后动态调整数据包的大小来适应运行环境。

另外是内存池这些,最简单的,你要是每次new char[1024]再去收,那收线程速度就当下来了. 
记住,收线程不要做任何事.那怕只查个MAP,在上万包每秒时,每秒的操作就上万个MAP查询, 

另外丢包可能是发送端,发出来已经丢了,你要考虑发送的的发送处理,发送处理写得不好,其实发 
的过程根本没机会出网卡缓冲,就已经丢了有可能. 
中间路由器环节(这个无法控制,只能看看这个环节性能如何)