本帖最后由 iejtqy 于 2011-9-29 16:13 编辑
上面这个数据包呢，是我在看其它哥们发的帖子中的数据包。
就是这个数据包呢，我有一个疑问，也是在这个帖子中大家都很关心的一个问题，但是没有人给予回复！！
1.当我们在抓包时如何在众多的数据包当中去快速的定位丢包？
2.当服务器在接收一组数据包时，发现在一个数据包没有收到，服务器是如何做出响应的？（是让客户端重传这组数据包吗？）如果是的话，就上面这个（TCP意外中断）这个例子中丢包的原因是因为MTU造成的，那么它在重传这个数据包时是不是会重先协商MSS的大小以达可以重传这个数据包。
3.当客户端在发送数据时丢了一个包时（会收到一个ICMP的差错报文），那么客户端在收到这个差错报文做出的响应是重传这个数据包吗？下面这张图片没有看懂，在发生丢包是到底是客户端收到ICMP的差错报文，还是服务端收到？
--------------------------------------------------------------------
孤独的意尹者版主（是如何的快速定位到44到46之间的丢包的呢？）根据“TCPU意外中断”数据包的分析。看了以下的分析后，也许有人会说根据sep值来判断啊（通过比较44、46两包的seq值（46包的seq=1906062，44包的seq=1905038，其差值为1906062-1905038=1024），也就是说，中间被丢失的tcp段长为1024字节）那么我们在抓包是抓到的数据包是成千上万个，总不可能一个一个的去这样找吧？
----------------------------------------------------------------------
以下是孤独的意尹者版主根据“TCP意外中断”数据包的分析以及论坛哥们的问答版主给的回复，我把它移过来供大家看，版主太厉害了。
原文链接（http://www.csna.cn/network-analyst-10220-1-1.html）
-------------------------------------------------------------------------
大致看了下楼主的数据包，发现：
1，存在两个会话；
2，第一个会话异常终止是由于在客户端还有数据没有传完时，服务器端主动发送FIN结束请求，导致后续客户端到服务器的数据包被服务器发送RESET包重置；
3，第二个会话异常是由于服务器端在给客户端回包时，其中一个数据包（在46包之前应该还有个包）丢失了，导致服务器最终发送RESET数据包重置了这个会话。
分析了数据包情况，接下来分析故障原因：
1，我们主要看第二个会话的异常，首先我们将注意力放在服务器数据包丢失的地方，通过比较44、46两包的seq值（46包的seq=1906062，44包的seq=1905038，其差值为1906062-1905038=1024），也就是说，中间被丢失的tcp段长为1024字节；
2，我们再回过头看看前面的TCP三次握手过程，看看客户端与服务器端协商时的MSS值，哈哈，发现没？1024字节啦。
3，推论一下吧，是否是中间链路的某个原因（MTU值？MPLS封装？ADSL封装？其他封装？）导致无法传输大于1044字节的数据包呢？
好人做到底吧，哈哈。分析了故障可能的原因，我们再给个解决方案：
请楼主检查中间链路吧，特别是MTU和相应封装。改下MTU试试。
问：
1,如何修改MTU值?
2,中间停顿的近一分钟时间,服务器和和客户端在干什么?
答：
1,至于mtu值的修改不同产品修改方法都不一样，你可以根据你产品的品牌和型号网上找下。
2，你给的数据包文件只有那两个会话，中间那些时间的确没有数据包，不知是否是你使用了过滤器造成的。
3，如果你的网络环境比较复杂，那么，建议在客户端与服务器端同时抓包做对比分析。
问：1、既然工作站与服务器协商的MSS值为1024，为什么服务器还会发大于1024的数据包？
答：
服务器的MSS是1024，但是中间设备的MTU值可能小于1024+20ip头长，对吧，而这个是服务器是不知道的，所以服务器还是以1024作为tcp的段长来传输数据啊。
|
发表于 2011-9-29 16:06:09
发表于 2011-9-29 16:41:38