用抓包软件抓的数据　见下：　从A到B的TCP报文的序列号和确认号都是一样的　反方向的报文也是一样的问题　根据字节数判断　显然不是重复发某一个报文　如果是一组报文分成多个TCP报文发送　序列号应该是不一样的啊　　不知道如何解释这种现象？　
方向　　　字节数　　　标志位　　　序列号　　　　　　确认号
Back           byte 1500      Flag is 16      len_num 54770   ack_num 25991
Back       byte 1500      Flag is 16      len_num 54770   ack_num 25991
Back            byte 1500      Flag is 16      len_num 54770   ack_num 25991
Back         byte 663       Flag is 24      len_num 54770   ack_num 25991
Back            byte 1500      Flag is 16      len_num 54770   ack_num 25991
To             byte 40        Flag is 16      len_num 25991   ack_num 54770
To              byte 40        Flag is 16      len_num 25991   ack_num 54770
To             byte 40        Flag is 16      len_num 25991   ack_num 54770

最大的可能：
监控端口的镜像源是多个端口（逻辑或物理的），如：在Cisco6509上，monitor Des为G2/1,而Monitor sou 是Vlan2，Vlan3，Vlan4。Vlan4是出口，Vlan2通过Vlan3路由，那么监控端抓到的报就是3份（Vlan2内主机对外网的通信）了。

检查一下报文的 TTL变化情况，就可以核实了。

[ 本帖最后由 hulzh 于 2008-6-26 07:44 编辑 ]

没有时间戳吗？楼主用什么工具抓的包，可以上传上来吗

看一下IP头 IP ID 是否一样

回复2楼 我把ttl值打印出来之后同一个方向的ttl值还是一样的  
回复3楼 该软件是我们自主开发的 有时间戳
回复4楼 ip id对于同一个数据段的所有报文都是一样的  P368 《计算机网络》第四版

引用:

原帖由 zzxxyy1982 于 2008-6-26 10:10 发表
回复2楼 我把ttl值打印出来之后同一个方向的ttl值还是一样的  
回复3楼 该软件是我们自主开发的 有时间戳
回复4楼 ip id对于同一个数据段的所有报文都是一样的  P368 《计算机网络》第四版

"ip id对于同一个数据段的所有报文都是一样的  P368 《计算机网络》第四版"
不明白这句话的具体意思是什么。
这里的“同一数据段”是指tcp segment吗？如果是的话，“ip id对于同一个数据段的所有报文都是一样的”是指由ip层分片后的报文吗？
如果是上面我所理解的情况的话，那么，你抓取的前5个back方向都是同一tcp segment的ip分片包，那么其ip id是一样的就很好解释啦，只是，不解的是分片包并无4层信息啊，哪来的seq、ack num？是你软件设计时让其分片包继承了tcp段的信息吗？

“同一数据段”是指tcp segment

“抓取的前5个back方向都是同一tcp segment的ip分片包，那么其ip id是一样的就很好解释啦”
事实上恰恰相反 我刚分析了下数据 id不一样 那证明应该不是同一数据段的  

我所给出的报文是指TCP报文 所以有 seq、ack num

对于id号 分析了一下对于同一个方向的报文 并不是连续的
如下 ：
To      byte 476       Flag is 24      len_num 56183   ack_num 27944 id  16971---下一个应该是16972??
Back   byte 1500      Flag is 16      len_num 27944   ack_num 56183 id  24775
Back   byte 1500      Flag is 16      len_num 27944   ack_num 56183 id  24776
To       byte 40        Flag is 16      len_num 56183   ack_num 27944 id  16973---但却是16973?
有的甚至跳跃很大 如上一个ID为10000 下一个则可能达到11500
不知道对于这种跳跃您如何理解？
此外对于我提出的同一个方向的序列号和确认号一样　有和见解？　

呵呵，你问的这两个问题都很有深度，最好将数据报的完整信息上传上来，期待高手一起过来看看～～

看不到抓包没法分析，lz有回帖的时间的话，还是先把抓包发上来

上传了部分报文  按照五元组进行输出  详细见附件

引用:

原帖由 zzxxyy1982 于 2008-6-26 14:36 发表
上传了部分报文  按照五元组进行输出  详细见附件 173961739617396

我想问下楼主，client、server两端通讯的协议栈是你自己写的吗？

SIP 3689321852         DIP3726416022         sport 4271         dport 80         protol 6
To        1 time is 1190958939 and 896897         byte 64        Flag is 2        len_num 25991        ack_num 0 id  61459
Back        2 time is 1190958939 and 914465         byte 44        Flag is 18        len_num 54769        ack_num 25991 id  0
To        3 time is 1190958939 and 917633         byte 40        Flag is 16        len_num 25991        ack_num 54769 id  61461
To        4 time is 1190958939 and 918065         byte 329        Flag is 24        len_num 25991        ack_num 54769 id  61463
Back        5 time is 1190958939 and 935697         byte 40        Flag is 16        len_num 54769        ack_num 25991 id  16827
Back        6 time is 1190958939 and 936321         byte 1500 Flag is 16len_num 54769        ack_num 25991 id  16829
Back        7 time is 1190958939 and 936545         byte 1500Flag is 16len_num 54770        ack_num 25991 id  16831
To        8 time is 1190958939 and 939809         byte 40        Flag is 16        len_num 25991        ack_num 54770 id  61467
Back        9 time is 1190958939 and 957457         byte 1500Flag is 16len_num 54770        ack_num 25991 id  16833
Back        10 time is 1190958939 and 957537         byte 1500Flag is 16len_num 54770        ack_num 25991 id  16835
Back        11 time is 1190958939 and 957697         byte 1500Flag is 16len_num 54770        ack_num 25991 id  16837
To        12 time is 1190958939 and 961073         byte 40        Flag is 16        len_num 25991        ack_num 54770 id  61469
To        13 time is 1190958939 and 961073         byte 40        Flag is 16        len_num 25991        ack_num 54770 id  61470

查看你上面的数据报显示，应该可以知道，这些数值都为10进制格式的，那么我们可以知道：
packet 1：显示的为client向server的80端口发送syn请求连接，其seq＝25991；
packet 2：显示为server对packet的响应（flag为ack，syn），其seq＝54769，ack＝25991；
         （问题出来了：这里的ack值应该为25992，表示server期望收到的下一个数据段的seq为25992）
packet 3：显示为client对server的ack，seq＝25991，ack＝54769；
          （问题1：按照正常的tcp协议栈的处理，client应该不会理会来自server的p2包，但是这里却做了ack）
          （问题2：这里的ack值应该为54770，表示client期望收到的下一个数据段的seq值为54770）
packet 4：显示为client向server发送len＝289的数据段，seq＝25991，ack＝54769，flag为ack，push
                 （这里的问题是：按照正常的tcp协议栈处理的过程，这个tcp的3次握手是无法正常建立的，但是此处却显示为client已经向server端发送数据）

分析了这几个包，基本上可以说是client与server的协议栈处理的问题了，不知其他兄弟对此有何看法？

[ 本帖最后由 孤独的意尹者 于 2008-6-26 16:39 编辑 ]

首先谢谢你一直的关注   
这个数据是我们实时从某省网边境用我们自己开发的软件采集的 为了便于分析，我把一些有用的信息用十进制打印出来
你后面的回帖提出的问题正是我不明白的 按照正常来说 序列号 确认号应该是变化的 但是事实从我们采集的数据来看不是 对于同一个方向的数据 很多都是重复的
你觉得“client与server的协议栈处理的问题” 我个人认为这个不太可能 因为所有的数据都是这样的 而不是某一对主机之间的数据

引用:

原帖由 zzxxyy1982 于 2008-6-26 21:54 发表
首先谢谢你一直的关注   
这个数据是我们实时从某省网边境用我们自己开发的软件采集的 为了便于分析，我把一些有用的信息用十进制打印出来
你后面的回帖提出的问题正是我不明白的 按照正常来说 序列号 确认号应该 ...

不知能否提供wireshark抓取的数据包

还有就是你提供的包中，似乎没有看到完整的tcp连接结束过程，一般只看见一方的fin标识，这些都不正常，不知怎么回事？

原始的数据非常大 一分钟不到就有200多Ｍ　
即使给出也没有什么意义　需要写程序来进行读取　
“没有完整的结束　”你的观察还是挺仔细的　这个主要是因为我们手动结束的　遇到FIN或者ＲＳＴ标志则输出 具体的原则则是我们模拟Cisco的NetFlow进行组流

问题已经解决　程序编写错误的原因　谢谢各位的关注