查看: 7942|回复: 5

C/S架构程序网络卡机,请各位帮忙分析一下

[复制链接]
发表于 2010-5-19 14:49:23 | 显示全部楼层 |阅读模式
程序采用的是C/S架设,socket通信,采用的是TCP协议,具体卡的表现现象是:
1。客户端双开,假设为客户端A和B,跨网访问服务器,会出现一个卡,一个不卡的现象。也就是说A卡B不卡,或者B卡A不卡。双个同时卡的现象基本没有
2。用wireshark抓包的表现是卡的这段时间内,客户端没有收到任何数据包
3。当A出现卡的时候,A进行操作的数据包还可以传到服务器,因为在B客户端会同步看到A的操作表现。这也就是说线路是下线卡,但上行是不卡的。
4。卡的情况只出现在跨网访问服务器的时候才出现,同网访问服务器或借助代理不会出现卡的情况。

目前我们做的工作可以确定数据包已经从服务器发送成功,但不知道在公网某个地方由于某种原因一直发送不成功,无数重传,在某一时刻重传成功以后,服务器所有积攒的包就一下子全发到客户端了。
这个问题已经困扰我半年了,还请版上各位经验丰富的大侠指点迷津。

附件是昨天抓的包, 请版上各位牛人帮忙分析一下

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?CSNA会员注册

×

评分

1

查看全部评分

回复

使用道具 举报

发表于 2010-5-19 15:07:34 | 显示全部楼层
网络线路 不畅通
查线
回复

使用道具 举报

 楼主| 发表于 2010-5-19 23:06:01 | 显示全部楼层
是啊,现在基本确定问题出在公网传输过程中了。 但你说的查线怎么查啊,呵呵。 有没有办法能追踪到是哪个路由或哪个线路段出的问题啊。
回复

使用道具 举报

发表于 2010-5-20 13:39:28 | 显示全部楼层
是不是程序设计上的问题,比如Server端的TCP Listener并发数太小
回复

使用道具 举报

 楼主| 发表于 2010-5-20 15:21:24 | 显示全部楼层
是不是程序设计上的问题,比如Server端的TCP Listener并发数太小
ValorZ 发表于 2010-5-20 13:39


这个有什么方法验证吗? 卡机的时候,那个客户端跟服务器的SOCKET还是有效的,并没有断开,只是没有数据来往了。
回复

使用道具 举报

发表于 2010-5-21 18:39:20 | 显示全部楼层
看了包,不是掉包而是被防火墙之类的设备把包给丢弃掉了,查看你本地的设备 或者在外网接入处抓包,与本地同时抓包,看数据到底在那掉的 从包中 数据包在编号17654这前网络通迅正常,没有存在掉包,而之后就很不正常了


编号为17654的包的确认号为确认号 1645570199
也就证明下个一个从服务器发送过来的数据包SEQ(序列号)为1645570199
可是服务器220.189.221.132 发来的下一个数据包是SEQ=1645570672  1645570672-1645570199= 473  中途掉一个数据包序列号为1645570199,数据大小为473的包。只到编号为17664的包这个包才接收到。

中途相差45秒左右,

在看数据包编号为17671的包确认号为1645573432
可是只到数据包编号17694才确认到1645573432

在看数据包号为17940的包确认号[Ack Number]:1645681171

证明下一个从服务器发过来的包序列号1645681171
只到编号为17996这个数据包SEQ为1645681171才确认

中间相差6 分钟你说网络不通畅可从SEQ=1645681351的包却可以收到,证明服务器已发出SEQ1645681171可客户端就是收不到


客户端用代理看看

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?CSNA会员注册

×
回复

使用道具 举报

您需要登录后才可以回帖 登录 | CSNA会员注册

本版积分规则

快速回复 返回顶部 返回列表