注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

mie

 
 
 

日志

 
 

【★★★】某网络软件的BUG跟踪分析  

2011-03-16 19:15:47|  分类: 疑难杂症 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
网络传输压力测试。
        测试过程中,出现这样的情况:此前的数据包和之后的数据包没法合并。前后的数据包的数据比较结果显示,很可能是丢包了!TCP连接的网络数据包,居然丢包了。由于TCP服务器/客户端程序存在粘包问题,必须自己拆包。丢包就导致一个很严重的问题,没法拆包,结果是进程崩溃。
        我的理解是,TCP的丢包问题可以忽略的,因为TCP有ACK进行验证的,数据包应该是连续的。
        (1)第一次崩溃
        崩溃发生在软件运行几十分钟之后。数据传输量大约在十几MB,共传输一千多个文件。
        (2)第二次崩溃
       崩溃发生在软件运行一个多小时之后。数据传输量大约在几十MB,共传输三千多个文件。
        (3)第三次崩溃
       崩溃发生在软件运行八个多小时之后。数据传输量大约在200MB左右,共传输20多万个文件。
       
        之后,为了定位BUG,我在所有可疑的地方加上详细的TRACE信息,同时开启网络抓包软件。软件持续运行了6个多小时,没有出现问题。此次共传输三十多万个文件,数据量大约在300多MB。之后,由于TRACE信息过多,导致另外一台机器的VC挂了,网络连接中断。——这次没有崩溃。

        为了重现BUG,不得不再次测试。这次比较倒霉,程序运行了几个小时,插线板跳闸(很强大的、可以跳闸的插线板)!
        再次测试,这次运气不错,一个多小时后,BUG重现!

        仔细查看Trace信息,发现最大的数据包接收大小是665字节!没想到MTU只有700字节左右!我使用的是因特网的MTU(1500字节)进行数据包分片。
        我一直认为,TCP协议是流式的,对于流式传输协议,可以直接忽略一点:数据包分片和重组。因为TCP协议本身已经帮我们考虑了这些。
       不过,从这次压力测试的结果来看,导致此BUG的原因在于:一个1450字节的数据包被拆分成了2个665字节和一个120字节的数据包,而随后,windows的网络驱动通过网卡将这三个数据包依次发送。结果表明,Windows将三个数据包的次序弄乱了!原先是一个A数据包拆分为A1、A2和A3,现在收到的是A2、A1和A3。于是,进程崩溃。

       至此,问题解决。解决方法就是,将数据包的最大大小从1450字节降为665字节。这样,windows底层网络驱动就不会进行数据报文拆包的工作,网络数据包也就不会乱序了。

By:zhanyonhu

  评论这张
 
阅读(468)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017