联通公司1个月没修好连续丢包问题，谁有类似的情况一起来找解决方法_联通吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：2,993,595贴子：
联通公司1个月没修好连续丢包问题，谁有类似的情况一起来找解决方法收藏
我家里接入的是2M ADSL，在这之前（网通未并入联通之前）连续用了四年多，网络从未出现过任何问题，但是最近也就是2010年12月中旬至今，网络频繁丢包，连续丢包，无论看电影、玩游戏都是无限掉线，联通公司首次查看说是因为要对小区网络进行增容，于是等了半个月，OK了，但还是无限丢包，他们来换过端口，让我重做过系统，换过猫，还是无限丢包，从昨天开始()用ATKKPING软件测试百度、新浪、腾讯、网易、搜狐、华军软件园，同时无限丢包，最高连续12秒持续丢包，当然此时别提什么网速了，玩游戏最怕丢包。我不知道是因为网通并入了联通技术力量变的薄弱了还是联通本身无条件做个互联网，后来他们工程人员竟解释说地井内的线因为天冷的缘故冻了，我想问问联通，东北冷还是宁夏冷，东北的好多朋友都说他们网络很正常，再后来他们工程人员让我PING nx.onlinedown.net 说是宁夏本地服务器不丢包，后来的事实验证了他们的话，全是错误的，包依旧丢，再再后来他们又说是因为通向我这栋楼的线路有问题，这栋楼住了60多户人，用的一根线路，偏偏我有问题？再再再后来他们工程人员又说是我电脑硬件的问题，我一怒之下向开电脑专卖的朋友借来一台联想笔记本电脑，包依旧丢。今天测试结果 百度 3小时46分，丢包率11.28% 新浪 3小时46分 丢包率 12.39% 腾讯 3小时45分 丢包率 9.88% 网易 3小时45分 丢包率 17.24% 华军软件园宁夏服务器 3小时22分 丢包率13.06%
盛大网络 3小时49分 丢包率 26.25%。现在我打10010，只要一看我电话号码，客服就知道我要说什么，他们无奈，我更无奈，他们火大，我的火更大。发个帖子不指望联通能因此解决问题，但我把我的问题说出来，看看有没有相似情况的朋友，有没有解决方法，指望不了联通的工程师们，咱自己指望自己吧！
登录百度帐号推荐应用温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
积极的人生必受青睐！
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(7976)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'UDP丢包和无序 问题的解决方法',
blogAbstract:' 最近在做一个项目,在这之前,做了个验证程序.
发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象.
纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了.
我用过sleep(10),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多',
blogTag:'udp,丢包,无序,文件传输',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:7,
publishTime:4,
permalink:'blog/static/',
commentCount:2,
mainCommentCount:2,
recommendCount:1,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'积极的人生必受青睐！',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}PING 丢包 故障解决思路 - CSDN博客
PING 丢包 故障解决思路
ping 丢包现象的发生非常普遍，但是广大网友对为何ping 丢包却不是非常清楚，看了下面的文章，相信您会有收获！
故障现象：公司有一台型号为清华同方TP200的 WEB服务器，操作系统安装顺利，IIS服务也配置无误，可是在访问此台服务器网站却时断时续。
分析解决：首先使用Ping命令测试，发现不定时的有数据包丢失的现象，初步认为是物理层的原因。重做网线的RJ45头后，故障依旧，换根网线也不行。怀疑是网卡接口或者交换机端口的问题。经查看网卡驱动无误，网卡接口也没有任何异常。再查看交换机端口，发现与服务器连接的交换机端口工作指示灯在绿与黄之间闪烁，这说明端口工作不正常。使用超级终端登录交换机，查看此端口的参数，发现此端口是工作在100Mbyte/s全双工模式，回到服务器前查看本地连接状态，网卡是工作在10Mbyte/s全双工模式。交换机的端口与网卡的传输速率和双工模式不一致。将网卡工作模式改为100Mbyte/s全双工模式后测试，一切正常，故障解决。
注：笔者单位使用的是CISCO3500XL系列交换机
如果你是小区宽带那种直接连接网卡的网络,丢包需要从下边查找原因&
1-计算机网卡是否损坏&
2-RJ45头是否损坏,是否线路错误&
3-网线是否折伤&
4-附近邻居是否同样出现问题,如果是说明问题出在上一级交换机与出口之间,如果别人正常,说明问题出在你的计算机到最近的交换机之间
如果是ADSL使用电话线路&
首先看看ADSL的衰减情况&
USB的能直接看出来,LAN口的需要登陆到MODEM上看,并且LAN口的需要检计算机到MODEM之间是否丢包,具体MODEM的IP请看说明书
说到投诉意义不大,问题是客观存在的,并且大过年的,虽然你不高兴,但是别人多人不高兴了,你看好不好,问题能处理了是关键&
从家里测试宽带网连接的丢包是一项非常困难的工作。丢包可以发生在从你的计算机到你在互联网上正在连接的目的地之间的线路上的任何一个地方。引起丢包的原因包括:网络阻塞、路由器或者交换机超过工作负荷、信号往返时间缓慢以及服务提供商或者托管你访问的网站的公司使用的通信优先等级。
　　没有主动测量实际重复传输的TCP流量(对于家庭宽带网连接来说，这类产品太昂贵了)，很难确定是否真的发生了重复传输。你指出的机制ping和跟踪路由对于帮助家庭用户确定互联网上哪里的速度慢是最有用的工具。Ping测量你的计算机和你要连接的IP地址之间的信号往返时间。跟踪路由是测量路由器在你的计算机和你正在跟踪的路由的IP地址之间的通道的反应时间。
　　使用Ping
　　使用Ping测量丢包的最佳方法是向一个IP地址发送大量的Ping命令，然后检查没有应答的那些Ping命令。如果你快速地发出了50次Ping命令，
　　你可以检查没有没有应答的次数，并把没有应答的次数作为丢包。没有应答的次数超过5%可能就值得担心了。
　　在一台Windows计算机上，在命令提示符后面输入如下命令就可以完成这个任务:
　　Ping -n 50(IP地址或者域名，如)这个命令中的“-n”开关告诉发送ping命令的次数，“50”是发送的次数。
　　然后，你将得到一个测试总结。这个总结将包括丢失的数量和百分比:
　　199.181.132.250地址Ping的统计结果:
　　包: 发送 = 6, 接收 = 6, 丢失 = 0 (0%)
　　大约往返时间以毫秒(ms)显示:
　　最小 = 26ms, 最大 = 29ms, 平均 = 27ms
　　如果你看到平均往返时间较高(超过100ms)，这也会降低你的网络下载速度。
　　设法消除某些引起丢包的网络某些部分的故障的一种方法是在通道的各个部分进行ping测试。我首先开始进行测试的地方是本地的“缺省网关”。这是你所有的数据传输到网络上经过的第一个路由器。如果在这一部分的丢包率很高，那么问题就在你的服务提供商的网络上。
　　在Windows命令提示符后面输入“ipconfig”命令你就可以发现你的缺省路由器的IP地址。这个结果显示如下:
　　以太网接口本地区域连接:
　　具体连接的DNS后缀:
　　IP地址. . . . . . : 192.168.2.189
　　子网掩码 . . . . . : 255.255.252.0
　　缺省网关 . . . : 10.10.0.1
　　你在这里要查看的是缺省网关的IP地址。在上述例子中就10.10.0.1。
　　使用跟踪路由
　　在Windows命令提示符后面使用跟踪路由命令就可以实施跟踪路由。在Windows XPZH中这个命令是:tracert (IP地址或者主机名)
　　虽然结果不能向你显示丢包，但是，可以向你显示在路径中路由器反应速度减慢的情况。
　　这个输出结果将显示所有的路由器的反应时间。下面是一个例子:
　　5 ms 2 ms 3 ms
[10.10.0.1]
　　10 ms 6 ms 7 ms 10.60.0.6
　　9 ms 7 ms 7 ms 10.20.0.1
　　6 ms 7 ms 7 ms x130.cd9e68.sj.concentric.net [205.158.104.130]
　　7 ms 7 ms 8 ms ge9-0.dcr2.dc-fremont-ca.us.xo.net [205.158.60.169]
　　7 ms 7 ms 7 ms ge2-0.dcr1.dc-fremont-ca.us.xo.net [65.106.2.205]
　　10 ms 7 ms 8 ms p5-1-0-2.rar2.sanjose-ca.us.xo.net [65.106.2.153]
　　10 ms 9 ms 11 ms p1-0.ir1.paloalto-ca.us.xo.net [65.106.5.178]
　　9 ms 10 ms 15 ms 206.111.12.114.ptr.us.xo.net [206.111.12.114]
　　9 ms 10 ms 10 ms svl-core-03.inet.qwest.net [205.171.205.29]
　　29 ms 28 ms 29 ms stl-core-02.inet.qwest.net [205.171.5.85]
　　30 ms 29 ms 29 ms sea-edge-03.inet.qwest.net [205.171.26.42]
　　* * * Request timed out.
　　* * * Request timed out.
　　28 ms 28 ms 29 ms sam. [199.181.132.250]
　　如果你看到在路径中跟踪路由往返时间有超过100ms(十分之一秒)的，这就可能引起网络上传输的时间减慢。
　　从上述例子中，你可以看到数据在很多不同的网络(XO, Qwest, ABC)上传输。这是互联网美妙的一部分。不利的方面是一个用户无法解决反应时间减慢的问题。最佳的出发点就是确认你和你的服务提供商之间没有出现丢包。
两个idc机房托管的服务器之间通讯不畅，经查，两个机房间的丢包率在8%左右。这样的丢包率很容易引起tcp连接失败，由于网络在线业务异常重要，不得有片刻的停机时间。刻不容缓，马上处理。
一、先判断丢包发生在那里。从办公室的计算机分别ping 两个机房的服务器、然后是网关，通过观察输出进行比较，发现问题在望京机房。在用路由跟踪的方式测试，结论也是一样。
二、去现场排查。检查网段类服务器之间，服务器与交换机之间，以及交换机之间的网络通讯情况，发ping 包，没有丢包，但从网内ping 外部任何地址，都有丢包现象出现，路由跟踪有时不成功。这些情况可以表明网段内的通讯是完全正常的。接下来要做的事情就是测试网关的状态。网关是一个cisco 6509交换机，是网通自己管理，我方的交换机通过一条双绞线与cisco 6509相连，它是所有服务器的外联接口。通过技术手段，已经知道上联交换机的上联端口是Fa0/41。
1、从网段内的某些服务器ping网关，发现丢包。
2、从外网的某台计算机ping 这个网关，没有丢包发生。
3、从外网的某些计算机执行到这个网关的路由跟踪，情况正常。
4、用外网远程的交换机ping　小包，情况正常。
５、从网段内的交换机ping 小包，发现丢包。
有上面的测试结果可以得出结论：是我方的交换机与网通交换机（我方服务器的网关）间的链路有故障。由于我们的网络服务不能中断，网通机房的人建议晚间访问量少的时候重新做一条线或重压网线两端的水晶头。前几天我方为扩容在机架上施工，因此有可能把线缆碰了。已经是中午了，肚子尽管饿了，但还是有点不甘心，再捣鼓一下看能不能找出点什么来。于是我搬来梯子，爬上去看接近天花板的交换机的指示灯状态。居然有一个端口指示灯黄绿交替一闪一闪的，仔细一看，是某个交换机的41号端口，而且网线上标明这条线是整个网段的上联线，即与网关相连的那条线，和先前测试出来的端口是一致的。可能问题就是在这个交换机上了，赶快连上console线，登录上这个交换机，用命令
# show int f0/41 查看41号端口的输出，嘿嘿！居然变成半双工了，再查看其他一些端口的双工情况，均是自适应，再去问IDC 机房的人，确认网关哪个连接端口的双工配置，网关的端口为全双工。好，马上进入配置模式，# config t , int f0/41 ,# duplex full 就把交换机的41号端口设置成全双工了，马上生效，保存配置；然后再爬梯子看41号端口指示灯的状态，变成绿色，这基本表明故障已经排除了。现在，开始从内外来测试丢包的情况了，经测试一切恢复正常。
原因分析：端口速率不匹配是引起丢包的最直接的原因。而引起端口速率变成半双工的原因可能是网络闪断引起的，比如网关那端的端口速率变化，而我方交换机的端口是自适应的，因此在协商后就变成半双工了。
关于ping IP 老是丢包的问题
通常有以下几种原因:
1.由于服务器的IIS中运行了非法或者没有独立进程池的原因,找到这个站点,给他一个独立的进程池.
2.如果服务器上捆绑了一个主机头为空的站点的话,容易造成这个问题,最好把这个主机为空的站点给删除了,或者把这个站点的进程池给独立起来,就可以解决问题.
3.由于对服务器的带宽和流量限制的太低问题,一般有一些机房的IDC服务商为了获得更多的托管的用户,十分的苛刻的限制用户托管的服务器,造成流出去的十分少,请求的多,就造成丢包问题.
4.由于交换机的交换口的问题:首先使用Ping命令测试，发现不定时的有数据包丢失的现象，初步认为是物理层的原因。重做网线的RJ45头后，故障依旧，换根网线也不行。怀疑是网卡接口或者交换机端口的问题。经查看网卡驱动无误，网卡接口也没有任何异常。再查看交换机端口，发现与服务器连接的交换机端口工作指示灯在绿与黄之间闪烁，这说明端口工作不正常。使用超级终端登录交换机，查看此端口的参数，发现此端口是工作在100Mbyte/s全双工模式，回到服务器前查看本地连接状态，网卡是工作在10Mbyte/s全双工模式。交换机的端口与网卡的传输速率和双工模式不一致。将网卡工作模式改为100Mbyte/s全双工模式后测试，一切正常，故障解决。
5.由于被DDOS或者洪水猛兽攻击造成的大量丢包,这个时候没有什么好说的,赶快加上硬件防火墙吧
总结:一般排除故障的方法是:
带宽有没有占满换个交换机端口试试换个网线试试网卡及主板驱动是不是没装(一般不会是这个问题)交换机上设置是100M的还是10M的,与机器设置成一样的还不成换交换机
本文已收录于以下专栏：
相关文章推荐
原文链接：/17530.html 【感谢】
我们使用Linux作为服务器操作系统时，为了达到高并发处理能力，充分利用机器性能，经常会进行一些...
最近单位的个别互联网用户反映上网不稳定时通时断，结合这次维修工作实际讲一下解决此类问题的一点心得。一、简单介绍Ping丢包率概念数据在网络中是被分成一个个数据包传输的,每个数据包中都有表示数据的信息和...
服务器网络故障处理——ping丢包或不通时链路测试说明前言当客户端访问目标服务器出现 ping 丢包或 ping 不通时，可以通过 tracert 或 mtr 等工具进行链路测试来判断问题来源。本文先...
文章出处：.cn/s/blog_4efdrx.html
    某次开局，使用Quidway路由器与其他厂商的某路由器互连，并运行...
项目中遇到一个这样的问题，用的是ping++支付，集成了支付宝和微信，支付宝支付是没有问题的，微信界面就是死活调不起，直接就是显示支付失败。
我是这样排查的：
1.微信支付调不起来，微信分享呢？微信分...
在虚拟用户上传时
家目录不能有写权限，否则报错：
lftp westos1@172.25.2.11:~& ls     
ls: Login failed: 500 OOPS: vsftpd: ...
前几天陆续安装了google一键安装套件，系统优化等各式软件。购买了wm1耳机到货，但安装软件后识别有点问题，手机进行了重启。
    万万没有想到这么悲催的事情被我遇到了，重启后，进行操作，在开机...
用Ping命令快速检测网络故障
　　网络的应用已渐渐深入我们的工作和生活，它带给了我们各方面的便利。因此，这种种的便利致使很...
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)UDP主要丢包原因及具体问题分析
UDP主要丢包原因及具体问题分析
一、主要丢包原因
1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。
二、具体问题分析
1.发送频率过高导致丢包
很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否被发送。（SendTo方法是异步的）这样，如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对&过快&的解释，作者这样说：&A few packets a sec hundreds or thousands may be an issue.&（一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不好办了）。 要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监听（如果数据包不确定什么时候发过来的话），其次，要在收到一个数据包后最短的时间内重新回到监听状态，其间要尽量避免复杂的操作（比较好的解决办法是使用多线程回调机制）。
2.报文过大丢包
至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报文长度控制在1280 bytes以下。
3.发送方丢包
发送方丢包：内部缓冲区（internal buffers）已满，并且发送速度过快（即发送两个报文之间的间隔过短）； &接收方丢包：Socket未开始监听； &虽然UDP的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是因为当报文过大时会被分割，使得每个分割块（翻译可能有误差，原文是fragmentation）的长度小于MTU，然后分别发送，并在接收方重新组合（reassemble），但是如果其中一个报文丢失，那么其他已收到的报文都无法返回给程序，也就无法得到完整的数据了。&UDP主要丢包原因及具体问题分析 - CSDN博客
UDP主要丢包原因及具体问题分析
文章来源：
UDP主要丢包原因及具体问题分析
一、主要丢包原因
1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。
二、具体问题分析
1.发送频率过高导致丢包
很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否被发送。（SendTo方法是异步的）这样，如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释，作者这样说：“A few packets a sec hundreds or thousands
may be an issue.”（一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不好办了）。 要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监听（如果数据包不确定什么时候发过来的话），其次，要在收到一个数据包后最短的时间内重新回到监听状态，其间要尽量避免复杂的操作（比较好的解决办法是使用多线程回调机制）。
2.报文过大丢包
至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报文长度控制在1280 bytes以下。
3.发送方丢包
发送方丢包：内部缓冲区（internal buffers）已满，并且发送速度过快（即发送两个报文之间的间隔过短）； &接收方丢包：Socket未开始监听； &虽然UDP的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是因为当报文过大时会被分割，使得每个分割块（翻译可能有误差，原文是fragmentation）的长度小于MTU，然后分别发送，并在接收方重新组合（reassemble），但是如果其中一个报文丢失，那么其他已收到的报文都无法返回给程序，也就无法得到完整的数据了。
-------------------------
我们是后一个包丢掉了
最近在做一个项目,在这之前,做了个验证程序.
发现客户端连续发来字节的包,服务器端出现了丢包现象.
纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了.
有没有成熟的解决方案来解决这个问题.
我用过sleep(1),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失.
你试着用阻塞模式吧...
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可能会更适合你！
-------------------------
1：什么是丢包率？&
你的电脑向目标发送一个数据包，如果对方没有收到.就叫丢包.&
比如你发10个，它只收到9个. 那么丢包率就是 10%&
数据在网络中是被分成一各个个数据报传输的,每个数据报中有表示数据信息和提供数据路由的桢.而数据报在一般介质中传播是总有一小部分由于两个终端的距离过大会丢失,而大部分数据包会到达目的终端.所谓网络丢包率是数据包丢失部分与所传数据包总数的比值.正常传输时网络丢包率应该控制在一定范围内.
2：什么是吞吐量？
网络中的数据是由一个个数据包组成，防火墙对每个数据包的处理要耗费资源。吞吐量是指在没有帧丢失的情况下，设备能够接受的最大速率。其测试方法是：在测试中以一定速率发送一定数量的帧，并计算待测设备传输的帧，如果发送的帧与接收的帧数量相等，那么就将发送速率提高并重新测试；如果接收帧少于发送帧则降低发送速率重新测试，直至得出最终结果。吞吐量测试结果以比特/秒或字节/秒表示。
吞吐量和报文转发率是关系防火墙应用的主要指标，一般采用FDT(Full Duplex Throughput)来衡量，指64字节数据包的全双工吞吐量，该指标既包括吞吐量指标也涵盖了报文转发率指标。&
随着Internet的日益普及，内部网用户访问Internet的需求在不断增加，一些企业也需要对外提供诸如WWW页面浏览、FTP文件传输、DNS域名解析等服务，这些因素会导致网络流量的急剧增加，而防火墙作为内外网之间的唯一数据通道，如果吞吐量太小，就会成为网络瓶颈，给整个网络的传输效率带来负面影响。因此，考察防火墙的吞吐能力有助于我们更好的评价其性能表现。这也是测量防火墙性能的重要指标。
吞吐量的大小主要由防火墙内网卡，及程序算法的效率决定，尤其是程序算法，会使防火墙系统进行大量运算，通信量大打折扣。因此，大多数防火墙虽号称100M防火墙，由于其算法依靠软件实现，通信量远远没有达到100M,实际只有10M-20M。纯硬件防火墙，由于采用硬件进行运算，因此吞吐量可以达到线性90-95M,是真正的100M防火墙。
对于中小型企业来讲，选择吞吐量为百兆级的防火墙即可满足需要，而对于电信、金融、保险等大公司大企业部门就需要采用吞吐量千兆级的防火墙产品。
3：检测丢包率
下载一个世纪前线，在百度可以找到，很小的程序。
NetIQ Chariot &一款网络应用软件性能测试工具
网络吞吐量测试,
本文已收录于以下专栏：
相关文章推荐
转自：http://blog.csdn.net/ljh0302/article/details/
实习项目需要用Winsock内核模式驱动提供的sockets方法，，这个驱动负责...
/li-hao/archive//2257596.html
（一）基础知识
IPv4 数据报最大大小是65535（16位）...
实时音视频领域UDP才是王道       
       在 Internet 上进行音视频实时互动采用的传输层方案有TCP（如：RTMP）和UDP（如：RTP）两种。TCP协议能为两个端点间的数据传...
UDP RTP 丢包解决 AVCom的API接口使用说明
通过RTP传输高清h264码流时，当码流的分辨率为1080P，帧率为 60帧每秒的码流在网络上传输过程中，瞬时的码率峰值可能会超过系统默认的udp的缓冲区大小，导致解码数据不完整，看到花屏的视频。解决...
实习项目需要用Winsock内核模式驱动提供的sockets方法，，这个驱动负责连接和缓冲管理，对应用程序提供socket风格的编程接口。
大概的流程是发送端将一幅图像分成多个包进行发送，接收端接收包...
本文讨论的udp丢包是指网卡接收到数据包后，linux内核的tcp/ip协议栈在udp数据包处理过程中的丢包，主要原因有两个:
1)        udp数据包格式错误或校验和检查失败
2)  &...
【转自】http://blog.csdn.net/libaineu2004/article/details/
文章来源：/net/20131...
减少UDP丢包的经验
最近在研究linux下的UDP的传输,但是由于UDP协议本身的一些原因,在数据量非常大的时候会造成一定数量的丢包,数量越大,丢包率越高.
为了解决丢包这个问题,我从网上查到了一些资料,大致可以从三个方...
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)}