开始新对话

未解决

此帖子已超过 5 年

312834

2014年6月9日 06:00

如果看了这个你还是不会用Wireshark,那就来找我吧(8月6日完结)

一站式学习Wireshark(一):Wireshark基本用法

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

Wireshark基本用法:抓取/过滤/查看报文

应用Wireshark观察基本网络协议

应用Wireshark过滤条件抓取特定数据流

应用Wireshark显示过滤器分析特定数据流(上)

应用Wireshark显示过滤器分析特定数据流(下) NEW

应用Wireshark IO图形工具分析数据流

应用Wireshark诊断网络性能 - TCP重传与重复ACK

应用Wireshark诊断网络性能 - TCP窗口与拥塞处理

应用Wireshark诊断网络性能 - 狙击网络高延时点

Statistics统计工具功能详解与应用

更多信息

按照国际惯例,从最基本的说起。

抓取报文:


下载和安装好Wireshark之后,启动Wireshark并且在接口列表中选择接口名,然后开始在此接口上抓包。例如,如果想要在无线网络上抓取流量,点击无线接口。点击Capture Options可以配置高级属性,但现在无此必要。

image002.png

点击接口名称之后,就可以看到实时接收的报文。Wireshark会捕捉系统发送和接收的每一个报文。如果抓取的接口是无线并且选项选取的是混合模式,那么也会看到网络上其他报文。


上端面板每一行对应一个网络报文,默认显示报文接收时间(相对开始抓取的时间点),源和目标IP地址,使用协议和报文相关信息。点击某一行可以在下面两个窗口看到更多信息。“+”图标显示报文里面每一层的详细信息。底端窗口同时以十六进制和ASCII码的方式列出报文内容。


image003.png

需要停止抓取报文的时候,点击左上角的停止按键。

image004.png

色彩标识:

进行到这里已经看到报文以绿色,蓝色,黑色显示出来。Wireshark通过颜色让各种流量的报文一目了然。比如默认绿色是TCP报文,深蓝色是DNS,浅蓝是UDP,黑色标识出有问题的TCP报文——比如乱序报文。

image005.png

报文样本:

比如说你在家安装了Wireshark但家用LAN环境下没有感兴趣的报文可供观察,那么可以去Wireshark wiki下载报文样本文件

打开一个抓取文件相当简单,在主界面上点击Open并浏览文件即可。也可以在Wireshark里保存自己的抓包文件并稍后打开。

image006.png

过滤报文:

如果正在尝试分析问题,比如打电话的时候某一程序发送的报文,可以关闭所有其他使用网络的应用来减少流量。但还是可能有大批报文需要筛选,这时要用到Wireshark过滤器。

最基本的方式就是在窗口顶端过滤栏输入并点击Apply(或按下回车)。例如,输入“dns”就会只看到DNS报文。输入的时候,Wireshark会帮助自动完成过滤条件。

image007.png

也可以点击Analyze菜单并选择Display Filters来创建新的过滤条件。

image008.png

另一件很有趣的事情是你可以右键报文并选择Follow TCP Stream

image009.png

你会看到在服务器和目标端之间的全部会话。

image010.png

关闭窗口之后,你会发现过滤条件自动被引用了——Wireshark显示构成会话的报文。

image011.png

检查报文:

选中一个报文之后,就可以深入挖掘它的内容了。

image012.png

也可以在这里创建过滤条件——只需右键细节并使用Apply as Filter子菜单,就可以根据此细节创建过滤条件。

image013.png

Wireshark是一个非常之强大的工具,第一节只介绍它的最基本用法。网络专家用它来debug网络协议实现细节,检查安全问题,网络协议内部构件等等。

             

1.2K 消息

2014年7月2日 01:00

一边写一边看了看整个系列,Filter的使用技巧这一部分有所缺失。写完了网络性能这节再写Filter。

1.2K 消息

2014年7月6日 23:00

一站式学习Wireshark(六):狙击网络高延时点

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

在某些情况下,丢包可能并不是造成延时的原因。你可能会发现尽管两台主机之间通讯速度很慢,但这种慢速并没有伴随着TCP重传或是重复ACK的征兆。在这种情况下,需要使用另一种方式来定位高延时点。

查找高延时点最有效的方法之一是检查最初的握手信号以及跟随其后的几个报文。例如,一个简单的客户端与网络服务器的连接,客户端尝试通过浏览器访问网络服务器的站点。我们只关心这一通信序列的前六个报文,包括TCP握手过程,首次HTTP GET请求,对此GET请求的确认,以及从服务器发至客户端的第一个数据报文。

更多信息

正常通讯:

在讨论高延时状况之前,找一个正常的通讯作为参照。在第二节已经介绍过TCP握手过程以及HTTP通讯,这里不再赘述。在下面这张图里,我们关心的部分只有Time列:

image002.jpg

这一通讯序列是非常快速的,整个过程耗时不到0.1秒。

接下来几个抓包文件包含同样的traffic模式,但是在报文时序上有所不同。

慢速通讯——线路延时:

让我们看看下面这个报文。注意到所有报文都是相同的,除了报文25的时间延时较长:

image003.jpg

逐一分析这六个报文,立刻就会看到第一次延时。客户端(172.16.16.128)发送首次SYN报文以开始TCP握手,在服务器(74.125.95.104)返回SYN/ACK之前,有0.87秒的延时。这是线路延时的第一个信号,这是由客户端和服务器之间的设备引起的。

我们判断这是线路延时的依据是所传送的报文类型特征。当服务器接收到一个SYN报文,只需花费很少的处理过程就可发送回复,因为这一工作负载并不包含任何传输层之上的处理。即使服务器工作负载非常繁重,它通常也会快速地以SYN/ACK来回复SYN报文。这就排除了服务器是高延时的潜在原因。

客户端也被排除的原因在于,它除了接收SYN/ACK报文之外,没有进行任何处理。

这一抓包的前两个报文帮我们排除了客户端和服务器,并指出了潜在原因。

继续分析,我们发现结束三步握手信号的ACK报文快速出现,客户端发送的HTTP GET请求也是如此。产生这两个报文的所有处理在本地客户端接收到SYN/ACK之后进行,因此在客户端没有繁重的负载需要处理的情况下,这两个报文预计会很快传送。

到了报文5,我们看到另一个延时高得离谱的报文。出现在最初的HTTP GET请求发送过后,从服务器返回的ACK报文花费了1.15秒才收到。接收到HTTP GET请求之后,服务器在开始发送数据之前首先发送了一个TCP ACK,同样只需占用服务器很少的处理。这是另一个线路延时的信号。

不管何时你经历着线路延时,你几乎总是会看到:在最初的握手信号期间的SYN/ACK报文,以及整个通讯过程的ACK报文中,存在着高延时。即使这一信息并没有告诉你网络上延时的确切原因,至少让你明白客户端和服务器都不是延时点所在,因此延时发生在两者之间的设备。这时,你应当开始检查受影响主机之间的各种防火墙,路由器,以及代理,以定位罪魁祸首。

慢速通讯——客户端延时:

下一个延时场景的抓包如下图所示:

image004.jpg

这一抓包开始时很正常,TCP握手非常迅速,没有任何延时的迹象。正常状态持续至第四个报文:握手信号结束之后接收到一个HTTP GET请求。这个报文距离前一个接收到的报文有1.34秒的延时。

要确认网络的延时点,需要检查第3和第4个报文之间发生了什么。报文3是客户端发送到服务器的TCP握手信号中的最后一个ACK,报文4是从客户端发送至服务器的GET请求。这两个报文的共同之处在于都是由客户端发送,并且独立于服务器。由于所有这些操作都集中在客户端上,GET请求应当在发送了ACK之后快速传送。

不幸的是对于终端用户,从ACKGET的传送并没有快速发生。GET报文的创建与传输取决于应用层的处理,这一过程中的延时意味着客户端无法及时的执行这一功能。这表示客户端最终为通讯中的高延时负责。

慢速通讯——服务器延时:

最后一个延时场景的抓包如下图所示:

image005.jpg

在这一抓包中,两个主机之间的TCP握手过程完成得干脆利落,因此开始时并无问题。接下来几个报文也很顺利,首个GET请求及回复ACK报文也在快速交付。直到最后一个报文,我们看到了高延时的信号。

第六个报文是服务器响应客户端GET请求的第一个HTTP数据报文,但是在服务器发送GET请求的TCP ACK 0.98秒之后才到达。报文56的传送过程与我们在前一个场景所见ACKGTE请求的传送类似。但是,在这一情况下,服务器是我们关注的焦点。

报文5是服务器对从客户端接收GET请求的回应。只要该报文被发送,服务器就应当立即发送数据。这一读取,封装,传送的过程是由HTTP协议完成的,由于这是应用层协议,需要服务器参与处理过程。这一报文的延迟接收表明服务器无法在合理的时间内处理数据,最终指向服务器是延时点。

延时定位思路:

通过六个报文,我们能够定位服务器与客户端之间的网络高延时点。这些场景可能看起来有点复杂,但是下图能使你的定位延时过程变得简单快捷。这一原则几乎能应用于任何基于TCP的通讯。

image006.jpg

1.2K 消息

2014年7月13日 18:00

一站式学习Wireshark(七):Statistics统计工具功能详解与应用

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

Wireshark一个强大的功能在于它的统计工具。使用Wireshark的时候,我们有各种类型的工具可供选择,从简单的如显示终端节点和会话到复杂的如FlowIO图表。本文将介绍基本网络统计工具。包括:捕捉文件摘要(Summary, 捕捉包的层次结构(Protocol Hirarchy, 会话(Conversations, 终端节点(Endpoints, HTTP


更多信息

Summary:

statistics菜单,选择Summary

image002.jpg

如下图的截屏所示,你会看到:

File

        捕捉文件的一般信息,如文件名和路径,长度,等等

Time

        第一个包和最后一个包的时间戳,以及抓包过程持续时间

Capture

        显示文件捕捉于哪一个接口,以及评论窗口

image003.jpg

在窗口的较低部分是Display窗口,展示抓包文件统计信息的摘要,包括:

捕捉报文的总数与百分比

显示报文的数量(加上过滤条件之后)

标记报文的数量

image004.jpg


何时使用:

这一菜单简单收集所有抓包数据,在定义了过滤条件的时候,将呈现过滤后的数据。当想要知道每秒的平均报文数或是字节数时,可以使用此工具。

Protocol Hierarchy:

这一部分阐述如何确知网络运行数据。从statistics菜单,选择Protocol Hierarchy

image005.jpg

这个窗口现实的是捕捉文件包含的所有协议的树状分支。如下图所示:

image006.jpg

Protocol Hierarchy窗口有如下字段:

Protocol

        协议名称

% Packets

        含有该协议的包数目在捕捉文件所有包所占的比例

Packets

        含有该协议的包的数目

Bytes

        含有该协议的字节数

Mbit/s

        抓包时间内的协议带宽

End Packets

        该协议中的包的数目(作为文件中的最高协议层)

End Bytes

        该协议中的字节数(作为文件中的最高协议层)

End Mbit/s

        抓包时间内的协议带宽(作为文件中的最高协议层)

小贴士:

包通常会包含许多协议,有很多协议会在每个包中被统计。End PacketsEnd BytesEnd Mbit/s列是该层在抓包中作为最后一层协议的统计数据(也就是说,协议处于报文的顶层,并且没有更高层信息了)。例如,没有载荷的TCP报文(例如,SYN报文),这一类没有负载任何上层信息的报文。这就是为什么在Ethernet层,IPv4层和UDP层报文计数为0,因为没有接收到以这些协议作为最后一层的帧。

何时使用:

值得注意的两点是:

百分比永远指的是相同协议层级。例如,

使用要点:

1. Percentage永远参照的是相同协议层。例如,上例中81.03%IPv4报文,8.85%IPv6报文,10.12%ARP报文。第二层之上的各协议所占百分比总和是100%

2. 另一方面,TCP占总数据的75.70%,在TCP协议之内,只有12.74%的报文是HTTP,除此之外没有其他统计。这是由于Wireshark只统计有HTTP头的报文。它不统计如确认报文或数据报文这样没有HTTP头的报文。

3. 为了使Wireshark同时统计数据报文,例如,TCP报文内部的HTTP报文,关闭Allow sub-dissector选项,对TCP数据流重新统计。可在Preferences菜单或Packet Details面板中右键TCP来实现。

Conversations

1. Statistics菜单中,选择Coversations

image007.jpg

2. 会看到以下窗口:

image008.jpg

3. 可以选择第2层以太网统计数据,第3IP统计数据,或第4TCPUDP统计数据。

4. 可以选择以下统计工具:

·         On layer 2(Ethernet):查找并过滤广播风暴或

·         On layer 3 or 4(TCP/IP)通过互联网路由器端口并行连接,查看谁在向ISP传输数据

小贴士:

如果你看到互联网上某一IP地址通过端口80HTTP)向外传输大量数据流,你就需要将该地址复制入浏览器并且查看你的用户与哪一个网站通讯最多。

如果没有得到结果,只需到标准DNS查询站点(Google一下DNS lookup)查看哪一种流量占用了你的网线。

5. 也可以通过选择位于窗口左下方的Limit to display filter复选框将会话统计信息进行显示过滤。这样,仅呈现所有通过显示过滤条件的统计数据。

6.要查看IP地址对应名称,可以选择Name resolution复选框。要查看IP名称解析,进入View | Name Resolution | Enable for Network layer进行激活。

7. 对于TCPUDP,可以在Packet list中对指定报文进行标记,之后从菜单中选择Follow TCP StreamFollow UDP Stream。从而定义一个显示过滤条件,仅显示指定数据流。

使用要点:

网络会话是两个指定终端之间的数据流。例如,IP会话是两个IP地址之间的所有数据流,TCP会话包含了所有TCP连接。

通过Conversations列表,能看出很多网络问题。

以太网会话统计

Ethernet conversations statistics中,查找以下问题:

·         大量的广播风暴:可以看见较轻微的广播风暴;而对于每秒数千甚至数万个报文的严重广播风暴,Wireshark会停止显示数据并且屏幕冻结。只有断开Wireshark连接时才能看见。

·         如果你看到来自某一MAC地址的大量数据,查看会话第一部分的vendor ID,会给你一些导致问题的线索。即使MAC地址的第一部分标识了vendor,但它并不一定就标识了PC本身。这是由于MAC地址属于PC上安装的以太网芯片厂商,而并不一定属于PC制造商。如果无法识别数据流来源地址,可以ping嫌疑地址并通过ARP获取它的MAC地址,在交换机中查找该地址,如果有操作系统的话直接用find命令来定位。

IP会话统计

IP conversations statistics中,查找以下问题:

·         查看收发大量数据流的IP地址。如果是你知道的服务器(你记得服务器的地址或地址范围),那问题就解决了;但也有可能只是某台设备正在扫描网络,或仅是一台产生过多数据的PC

·         查看扫描模式(scan pattern)。这可能是一次正常的扫描,如SNMP软件发送ping报文以查找网络,但通常扫描都不是好事情。

·         一次典型的扫描模式如下图所示:

image009.jpg

本例中的扫描模式,一个IP地址,192.168.110.58,发送ICMP报文至192.170.3.44, 192.170.3.45, 192.170.3.46, 192.170.3.47,等等(上图仅显示扫描的很小一部分)。这种情况下我们有一个蠕虫病毒感染了网络上的所有PC,在它感染PC的时候,它就开始产生ICMP请求并将它们发送至网络。这些窄带连接(例如:WAN连接)可以很容易地被封锁。

TCP/UDP会话统计

·         查看带有太多TCP连接的设备。每一个PC合理的连接数是1020个,上百个则是不正常的。

·         尝试查找无法辨识的端口号。它可能是正常的,但也可能是有问题的。下图显示了一次典型的TCP扫描:

image010.jpg

Endpoints:

1. statistics菜单,选择Endpoints

image011.jpg

2. 出现以下窗口:

image012.jpg

3. 此窗口中,能够看到第2,3,4层的endpoints,也就是以太网,IP, TCPUDP

使用要点:

这一工具列出了Wireshark发现的所有endpoints上的统计信息。可以是以下任意一种情况:

·         少量以太网endpointsMAC地址)与大量IP终端节点(IP地址):可能的情况例如,一个路由器从很多远端设备收发报文,我们会看见路由器的MAC地址及很多IP地址经由此处。

·         少量IP终端节点与大量TCP终端节点:可能的情况是每一台主机有很多个TCP连接。可能是有很多连接的服务器的一个正常操作,也可能是一种网络攻击(如SYN攻击)。

以下是一个网络中心的抓包示例,一个内部网络有四个HP服务器和一个Cisco路由器,MAC地址的第一部分已经解析了厂商名称:

image013.jpg

当我们查看IPv4:191下的endpoints,我们看到有很多来自192.168.10.0, 192.168.30.0,以及其他网络地址。

image014.jpg

HTTP:

1. statistics菜单,选择HTTP,将会出现以下窗口:

image015.jpg

HTTP子菜单中,可以看到以下信息:

Packet Counter

        每一个网站的报文数量。帮助识别有多少响应和请求。

Requests

        各网站的请求分布。

Load Distribution

各网站的负载分布。

按照以下操作步骤查看Packet Counter统计信息:

1. 进入Statistics | HTTP | Packet Counter

2. 显示以下过滤窗口:

image016.jpg

3. 此窗口中,可设置过滤条件以查看符合过滤条件的统计信息。如果想要查看整个抓包文件的统计信息,留白不填。这就会显示IP层之上的统计信息,也就是所有HTTP报文。

4. 点击Create Stat按钮,会看到以下窗口:

image017.jpg

如果要查看某一特定节点的HTTP统计信息,可以通过display filter的方式配置过滤条件。

按照以下操作步骤查看HTTP Requests统计信息:

1. 进入Statistics | HTTP | Requests出现以下窗口:

image018.jpg

2. 选择所需过滤条件。对于所有数据,留白。

3. 点击Create Stat按钮,会出现以下窗口:

image019.jpg

4. 要获得指定HTTP主机的统计信息,设置过滤条件http.host contains http.host==

5. 例如,通过设置过滤条件http.host contains ndi-com.com,可以获得站点 www.ndi-com.com的统计信息,如下图所示:

image020.jpg

6. 结果如下图所示:

image021.jpg

按照以下操作步骤查看Load Distribution统计信息:

1. 进入Statistics | HTTP | Load Distribution

2. 出现以下窗口:

image022.jpg

3. 选择所需过滤条件。对于所有数据,留白。

4. 点击Create Stat按钮,会出现以下窗口:

image023.jpg

使用要点:

当我们打开一个网页,通常会向若干个URL发送请求。本例中,我们打开的其中一个网页是www.cnn.com,并将我们导向edition.cnn.com。我们发送了若干个请求:到root URL,到breaking_news URL,以及主页上两个其他位置。

1.6K 消息

2014年7月13日 19:00

长篇巨作又更新了

1.2K 消息

2014年7月14日 02:00

看到有人转载把题目改成:如果看了这个还是不会Wireshark,就去掐死写文章的妹纸。我了个去。

8 消息

2014年7月15日 19:00

写的真好。期待早日给出过滤条件的那两张。

请教个问题:怎么升级/替换 wireshark里面的协议分析器?我用wireshark来抓cmpp(中国移动短消息协议)包,但是wireshark的协议分析器是cmpp1.0,现在网上通常都是2.0,这样我在分析cmpp包的时候,wireshark会说这是个malformed packet,因此就无法给出直观的解释。

另外,能推荐比较优秀的数据包协议分析器么?

8 消息

2014年7月15日 19:00

应该改成去追比较好。。。哈哈。。。

1.2K 消息

2014年7月15日 20:00

这个好像挺复杂的,我没有替换过,找到一些信息供参考:

假设已经有了解析器源文件,


插件型

为了编译该解析器代码来创建该插件,除了解析器的源代码packet-foo.c外,还需要在该源代码文件所在目录下创建下列一些文件,其包含了windows平台与unix/linux平台下的各自所需文件。①makefile.am —— unix/linux的makefile模板;②makefile.common ——包含插件文件的名称;③makefile.nmake ——包含wireshark插件的windows平台下的makefile;④moduleinfo.h ——包含插件版本信息;⑤moduleinfo.nmake ——包含windows平台下动态链接库(dll)的版本信息;⑥packet-foo.c ——自定义协议解析器的源代码;⑦plugin.rc.in ——包含windows平台下的dll资源模板。


makefile.commonmakefile.am文件必须修改,来反映相关的文件与解析器名称。moduleinfo.h moduleinfo.nmake文件必须填写版本信息。把该解析器编译成一个动态连接库或共享库,并复制到已安装wiresharkplugin目录下,即可使用。

内置型

内置型协议解析器源代码都在目录wireshark-1.2.0\\epan\\dissectors下。此处,我们以添加udp协议为例,说明内置型添加协议解析器的步骤:

第一步:将要添加的协议解析器源文件packet-udp.c和头文件packet-udp.h放在此目录下;

第二步:在此目录下修改makefile.common文件,分别将源文件和头文件名添加到对应的dissector_srcdissector_include宏下面。

第三步:最后对整个工程进行编译连接,就可以把要添加的协议解析器,如同wireshark大多数内置解析器一起被整合编译到libwireshark中。

1.6K 消息

2014年7月15日 20:00

这个建议好,哈哈。还可以出些题,设置闯三关游戏

1.2K 消息

2014年7月15日 22:00

数据包协议分析器Capsa,这篇文章可以供参考:十大免费又好用的网络分析工具

8 消息

2014年7月15日 23:00

感谢回复。确实复杂,需要改源代码重新编译,收益超过付出。等等看吧,暂时就对着协议看16进制的码了。

8 消息

2014年7月15日 23:00

感谢回复。科来大概看了一下,支持的协议不如wireshark多。我估计不会支持cmpp这种较冷门的协议。其实我对wireshark支持cmpp也是有点惊喜的。您文章写的很好,期待您的关于过滤的两章。谢谢!!!

1.2K 消息

2014年7月16日 00:00

感谢支持。这个帖子一直是看的人多讨论的人少,我有时候也犹豫下一节应该写什么。欢迎更多看到帖子的同学加入讨论喜欢哪方面的内容。

8 消息

2014年7月18日 00:00

这节很有实用意义(狙击网络高延时点)。正好最近处理问题用上了(非常感谢Zhang,Jiawen),分享下应用的思路(也有跟文中不同的地方)。

问题:业务突然变慢,客户端(确定)和服务端(应该)都没有改动。

问题定位:根据经验判断是网络质量变差,现在需要验证判断。(服务端无法协调联查,但服务端处理很多客户端,未见其他地方的客户端有同样问题)。

验证过程:首先断掉客户端重连,用wireshark抓包发现tcp三次握手都还行。客户端发数据包也很快,服务端回tcp的ack也挺快,但数据包的响应就慢了一些。客户端发大数据包的时候,干脆就没响应包回来(但也不是必然)。根据逻辑,服务端和网络都有可能有问题,客户端出问题的可能可以排除。不过业务的服务端是nb的中国移动,客户端所在的网络是中国电信的网络,因此我们基本可以把问题归结为网间互通。

有趣的问题是:小包看起来是ok的,大数据包延迟(或丢包)的现象很严重。

另外有三个问题想请教下Zhang,Jiawen:

1、在wireshark上,如何方便查一个tcp报对应的响应包(或响应包对应的原始包)。可以手工根据sequence id和ack id来判断,但是wireshark提供方便的工具么?----我们的业务是在一个tcp长连接中发很多包。

2、有没有技巧可以方便的统计延时的情况,例如某时间段中,发包到收到ack的延时超过1s的数据包数量?

3、有没有技巧可以方便的统计丢包的情况,例如某时间段中,发出去的包没收到ack的有多少?

1.2K 消息

2014年7月20日 20:00

问题:业务突然变慢,客户端(确定)和服务端(应该)都没有改动。

问题定位:根据经验判断是网络质量变差,现在需要验证判断。(服务端无法协调联查,但服务端处理很多客户端,未见其他地方的客户端有同样问题)。

验证过程:首先断掉客户端重连,用wireshark抓包发现tcp三次握手都还行。客户端发数据包也很快,服务端回tcp的ack也挺快,但数据包的响应就慢了一些。客户端发大数据包的时候,干脆就没响应包回来(但也不是必然)。根据逻辑,服务端和网络都有可能有问题,客户端出问题的可能可以排除。不过业务的服务端是nb的中国移动,客户端所在的网络是中国电信的网络,因此我们基本可以把问题归结为网间互通。

有趣的问题是:小包看起来是ok的,大数据包延迟(或丢包)的现象很严重。

非常感谢分享.很高兴这篇文章能帮到你.从现象来看像是服务器和客户端中间的某个环节出现了问题.不知道这个问题现在解决了没有,如果有进一步发现再来一起讨论~

关于这几个问题:

1、在wireshark上,如何方便查一个tcp报对应的响应包(或响应包对应的原始包)。可以手工根据sequence id和ack id来判断,但是wireshark提供方便的工具么?

可以参考楼下大牛的回答~

2、有没有技巧可以方便的统计延时的情况,例如某时间段中,发包到收到ack的延时超过1s的数据包数量?

添加一列按照每一个报文据上一个报文的延时来显示:

扩展TCP报文头。右键Time since previous frame in the TCP stream,然后选择Apply as a Column,这样产生新的一列。

如下图所示。就可以方便的看到每一个报文距离上一个报文的延时了。然后可以根据延时从大到小来排列。

Capture.PNG.png

3、有没有技巧可以方便的统计丢包的情况,例如某时间段中,发出去的包没收到ack的有多少?

可以尝试应用display filter过滤条件,输入tcp.analysis,wireshark会列出关于TCP问题和性能的过滤条件,其中有关于重传报文(tcp.analysis.retransmission)的过滤:

Capture.PNG.png

另外给出一个TCP显示过滤条件的详细说明:

Wireshark · Display Filter Reference: Transmission Control Protocol

找不到事件!

Top