又掉了！我头大了，IP都绑定了啊

ming811208

又掉了！我头大了，IP都绑定了啊

逍遥一指令

部署不正确
另外请先检查本机

lbzxy

楼主昨天不是发过类似的帖子吗？
你是更改了本机的IP地址还是什么呢？昨天的工程里本机IP是192.168.1.37.
你的产品部署不正确，请参考这个帖子重新部署：http://www.csna.cn/forum.php?mod ... &extra=page%3D1
最后，建议检查本机是否感染病毒或者安装了扫描软件之类的。

oldjiang

观察会话192.168.1.19:1287--218.23.28.90:80
1、数据包60/61连续的两次ack
比较两个包，除了接收窗口大小不同，其他都相同。接收窗口变化，要通知对方？
2、包79的ack有点奇怪
此前客户端只有包11一个GET请求，服务器已经在包12 ACK了序号1833676714，包79 ACK的是什么呢？
3、关于RESET
诊断有较多的TCP连接被复位事件。想问问版主，reset之后的逻辑如何?状态如何变化?
包82之后服务器连续发了8个包,把剩余数据全部发完?不考虑接收窗口了?
4、有些会话不显示
192.168.1.19和218.23.28.90有54个TCP会话
TCP复位非活动连接事件，本地端口为1345、1346、1349，在会话视图按本地端点排升序则不见1349，降序则见，导出导入筛选端口>=1345的数据也见，数了一下，只显示50个会话。在何处可以修改设置？

徐徐渐进

这些问题有可能都是因为网络性能差所致。
１。如你所言，TCP的窗口用来定义当前主机所能接收数据的最大数，主机将字段用于流量控制；
２。我们从序列号和确认号可以看出数据包79是对71进行确认的，1102020639+835=1102021474;
３。工程中的复位连接太多是因为老版本的浏览器使用复位连接的方法关闭HTTP连接所致。
４。1349升序或降序排列都可以显示的。请确定的点击的次数，在初始状态下，点一次是降序排列，点二次是升序排列，点三次时恢复到初如状态。

oldjiang

5楼对4楼第二点的回答不对，1833676714<>1102021474，包71、79的源都是服务器，没有自己ACK自己的吧。在节点浏览器定位218.23.28.90，不作任何排序，会话视图第一行就是1349，如果升序则1349就不见了。不论定位与否、排序与否确实只显示50个会话。

[ 本帖最后由 oldjiang 于 2008-1-24 16:26 编辑 ]

徐徐渐进

原帖由 oldjiang 于 2008-1-24 16:18 发表
5楼对4楼第二点的回答不对，18336767141102021474，包71、79的源都是服务器，没有自己ACK自己的吧。在节点浏览器定位218.23.28.90，不作任何排序，会话视图第一行就是1349，如果升序则1349就不见了。不论定位与否、排 ...

楼主真是细心人，赞！出现楼主所说的情况，个人认为还是网络性能和客户机出现故障所致。
我们可以试着访问同样的网站进行抓包，然后对比可知192.168.1.19这台机器有问题，他居然用连续的端口与218.23.28.90的80连接。

oldjiang

"他居然用连续的端口与218.23.28.90的80连接",我也是用连续的端口连接www.csna.cn

徐徐渐进

如果是50节点的技术交流版的话，就只能显示50个会话。
刚刚查了下资料，71和79这两个数据包是有问题，应是服务器或客户端出故障的原因。
oldjiang的细致令人赞。

oldjiang

徐兄查的资料能否贴出来？我也很想看看

徐徐渐进

根据TCP通讯的原理，我们应知道，http服务器将数据发送给客户端后，客户端应对收到的数据进行确认，如果客户端对收到的数据不确认的话，发送者就认为数据丢失并重传此数据。而在此工程中，客户端还没有确认，服务端就开始传送下一个数据了。
当然，也不排除这个会话本身就没有完成从而出现了这种情况。

oldjiang

1、"客户端还没有确认，服务端就开始传送下一个数据了",能否给出数据包编号？包80确认了包71

2、71号数据包，我觉得完全正常，该包数据835字节，小于MSS，是一个完整数据的最后一个包，PUSH置位，HTML数据的最后一行是Line 25:</html>也是一个页面的结尾。“71和79这两个数据包是有问题”，请徐徐说说71的问题在何处？

3、楼主的工程，UDP-OTHER协议有6个数据包，其UDP包头长度域不等于数据长度+8，如图所示。我看了其他几个工程，未见类似情况。本来我想学习一下填充、校验等再继续研究，无奈公务繁忙，还是先问问版主。

[ 本帖最后由 oldjiang 于 2008-1-25 12:53 编辑 ]

徐徐渐进

是的，从数据包看，80是对71进行了确认，但是客户端却并没有对序列号1833676714进行确认，然后就开始序列号1833677124的通讯了，这也是我感到奇怪的地方。
另外，单看71数据包是正常的。

oldjiang

“但是客户端却并没有对序列号1833676714进行确认”，1833676714是客户端的序列号，客户端为何要对其确认？“然后就开始序列号1833677124的通讯了”指的是82号包吧，正常啊。

徐徐渐进

UDP-OTHER协议的6个数据包是正常的。在科来网络分析系统目前的版本里面，UDP的长度是实际的数据包长度，不包括填充的数据。而在以太网里数据包在64－1518之间，所以这里应是系统填充了2个字节的数据。

[ 本帖最后由 徐徐渐进 于 2008-1-25 16:07 编辑 ]

564631594aa

各位楼主讲了很多，本人长知识了。。。。。