跳转到主要内容
开始新对话

未解决

此帖子已超过 5 年

Zhang_Jiawen

1.2K 消息

312811

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网络协议实现细节，检查安全问题，网络协议内部构件等等。

             

bairichard1

107 消息

2014年7月20日 20:00

1， “业务突然变慢，客户端（确定）和服务端（应该）都没有改动。”

[沛满]：如果怀疑是网络有问题，可以在业务慢的时候抓个500MB左右的网络包分析一下。论坛可以上传的话我也可以帮忙分析。

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

[沛满]：这个要从基本原理讲起。TCP的工作方式不是逐个包发送的，而是一口气发出多个包，从而提高传输效率。就像快递员会一次性携带很多包裹到我司前台一样，为的是减少消耗在路上的往返时间。接收方收到这些包之后有两个选择，既可以每个包都确认（也就是你提到的响应），也可以只确认最后一个来暗示所有包都收到了。举个例子，发送方发出了10个包，编号1至10，且没有一个丢失的，那接收方既可以回复10个确认包，也可以只回复“ack 11”，表示10以及10之前的所有包都收到了。当有丢包发生时，比如还是发送了10个包的情况，编号也是1至10，但其中10号包丢失了，那接收方可以回复9个确认包，也可以只回复“ack 10”，表示9以及9之前的包都收到了。

了解了这个原理，我们就知道在Wireshark上没有必要去对应每个ack和seq，因为大多数包即便正常收到后也不会有ack。

3，“有没有技巧可以方便的统计延时的情况，例如某时间段中，发包到收到ack的延时超过1s的数据包数量？”

[沛满]：如果你只是想了解网络延时状况，那用ping最简单准确了，没有必要用Wireshark。一般我们在乎的是应用层的延时，比如向一个服务器发送读请求，到收到读响应的时间差究竟有多少。Wireshark上有提供这个功能，比如CIFS协议那就可以用“smb.time > 1”来过滤出所有超过一秒钟的延时的CIFS操作。如果是NFS，就用rpc.time（因为NFS是基于RPC的协议）。HTTP也有http.time。

4，“有没有技巧可以方便的统计丢包的情况，例如某时间段中，发出去的包没收到ack的有多少？”

[沛满]：还是那句话，没有收到ack不一定是丢包了。如果是想看丢包重传的统计，那就Analyze-->Expert Info，然后看warnings or notes tab. 虽然要统计出结果很容易，不过使用者需要理解tcp的基础知识才能解读这个结果，比如一个超时重传，导致的后果远远超过一个快速重传。有启用SACK的时候，处理多个丢包的效率远高于没有启用SACK的……这个说起来太复杂了。

Zhang_Jiawen

1.2K 消息

2014年7月20日 21:00

感谢沛满，解释的非常清楚

iamgoust

42 消息

2014年7月20日 23:00

妹子的确是认真的干了这件事情，赞一个，择机转到我的个人博客www.vants.org，欢迎文章作者妹子来访切磋，本人做科来4年半，现在在合肥组织一群技术兄弟创业中

Zhang_Jiawen

1.2K 消息

2014年7月20日 23:00

朋友也在创业，我很理解创业的辛苦不足为外人道之处，向创业的兄弟致以由衷的敬意～

拜访了你的博客，非常专业细致的总结～

happydanye

8 消息

2014年7月21日 01:00

哈哈，又有高手出没，感谢解答。继续发问：

1、既然可以只确认最后一个，那么接收方的确认机制通常有哪几种？（每n个包确认一次？），如果收到1，2，3，4，5，7，8，9，10个包（包6丢了），如何回复确认消息？

2、ping这个我是知道的，但是有的服务器禁ping。另外，我还发现有ping正常的包，但是实际业务包延迟厉害。我刚测试了一下，ping的时候，包大小很有关系。900以下比较正常，超过1000的包都收不到，900和1000之间的包时好时坏。这个结果有参考意义么？

happydanye

8 消息

2014年7月21日 02:00

晕，找不到“Time since previous frame in the TCP stream”，展开tcp报文头，【seq/ack analysis】后面就是pdu了。

Zhang_Jiawen

1.2K 消息

2014年7月21日 02:00

先回答这个问题：

晕，找不到“Time since previous frame in the TCP stream”，展开tcp报文头，【seq/ack analysis】后面就是pdu了。

需要在TCP protocol preferences开启Calculate conversation timestamps让它显示出来。

此外，还有一个显示过滤条件也可以使用：tcp.time_delta>X。

Zhang_Jiawen

1.2K 消息

2014年7月21日 03:00

2、ping这个我是知道的，但是有的服务器禁ping。另外，我还发现有ping正常的包，但是实际业务包延迟厉害。我刚测试了一下，ping的时候，包大小很有关系。900以下比较正常，超过1000的包都收不到，900和1000之间的包时好时坏。这个结果有参考意义么？

发现延时的时候，首先应当做的事情就是ping。这个结果有啥意义，我暂时想不到，等沛满来看看。

Zhang_Jiawen

1.2K 消息

2014年7月21日 03:00

1、既然可以只确认最后一个，那么接收方的确认机制通常有哪几种？（每n个包确认一次？），如果收到1，2，3，4，5，7，8，9，10个包（包6丢了），如何回复确认消息？

举个例子解释一下这一过程：（在Edit | Preferences列配置，显示下图tcp.seq和tcp.ack值，回答之前的问题）

7645_09_16a.jpg

如上图，服务器626.219.24.171发送序列号为120185105的报文，之后发送序列号为120186557的报文，客户端10.0.0.7接收到之后，通过ACK=120188009告知服务器下一个报文序列号。之后服务器发送序列号为120188009的报文，这样下去。

7645_09_16b.jpg

当一个报文的ACK丢失，或是ACK没有及时到达的时候，报文会重传，发送方会做两件事情：

1.再次发送报文，（可以参考前文）

2.减小吞吐量。

bairichard1

107 消息

2014年7月21日 15:00

1、“既然可以只确认最后一个，那么接收方的确认机制通常有哪几种？（每n个包确认一次？），如果收到1，2，3，4，5，7，8，9，10个包（包6丢了），如何回复确认消息？”

[沛满]：通常有两种，一种是每个包都确认，一种是只确认（连续的）最后一个包。如果不是连续的（中间有包丢失），就确认丢包之前的那一个。以你所举的“如果收到1，2，3，4，5，7，8，9，10个包（包6丢了）”为例，那确认包就是ack 6, 表示12345收到了，在等待6。6没有丢，只是乱序到10后面了，那发送方在收到4个ack 6之后，又会收到ack 11。


2、“ping这个我是知道的，但是有的服务器禁ping。另外，我还发现有ping正常的包，但是实际业务包延迟厉害。我刚测试了一下，ping的时候，包大小很有关系。900以下比较正常，超过1000的包都收不到，900和1000之间的包时好时坏。这个结果有参考意义么？”

ping正常而实际业务包延迟得厉害，正符合我昨天提到的，“一般情况下我们更关注的是应用层的延迟”。比如你发送一个http request给IIS服务器，但是IIS当时很忙，所以就回复得很慢，从客户端看起来就是高延迟。ping包则不一样，收到后基本都是及时回复的，所以更能反映网络上的延迟。

ping的大小在MTU以内应该关系不是非常明显，假如900以下正常，超过1000的全收不到，那得好好查查网络了，比如是不是路上有个设备的MTU比较小。

Zhang_Jiawen

1.2K 消息

2014年7月21日 16:00

一站式学习Wireshark（八）：应用Wireshark过滤条件抓取特定数据流

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

介绍

应用抓包过滤，选择Capture | Options，扩展窗口查看到Capture Filter栏。双击选定的接口，如下图所示，弹出Edit Interface Settints窗口。

image002.png

下图显示了Edit Interface Settings窗口，这里可以设置抓包过滤条件。如果你确知抓包过滤条件的语法，直接在Capture Filter区域输入。在输入错误时，Wireshark通过红色背景区域表明无法处理过滤条件。最有可能的情况是，过滤条件中含有输入错误，或是使用了display filter的语法。

点击Capture Filter按钮查看并选择已保存的抓包过滤条件。

image003.png

更多信息

抓取指定IP地址的数据流:

如果你的抓包环境下有很多主机正在通讯，可以考虑使用所观察主机的IP地址来进行过滤。以下为IP地址抓包过滤示例：

·         host 10.3.1.1：抓取发到/来自10.3.1.1的数据流

·         host 2406:da00:ff00::6b16:f02d：抓取发到/来自IPv6地址2406:da00:ff00::6b16:f02d的数据流

·         not host 10.3.1.1：抓取除了发到/来自10.3.1.1以外的所有数据流

·         src host 10.3.1.1：抓取来自10.3.1.1的数据流

·         dst host 10.3.1.1：抓取发到10.3.1.1的数据流

·         host 10.3.1.1 or 10.3.1.2：抓取发到/来自10.3.1.1，以及与之通讯的所有数据流，与10.3.1.2，以及与之通讯的所有数据流

·         host www.espn.com：抓取发到/来自所有解析为www.espn.com的IP地址的数据流

抓取指定IP地址范围的数据流:

当你需要抓取来自/发到一组地址的数据流，可以采用CIDR(无类别域间路由，Classless Interdomain Routing)格式或使用mask参数。

·         net 10.3.0.0/16：抓取网络10.3.0.0上发到/来自所有主机的数据流(16表示长度)

·         net 10.3.0.0 mask 255.255.0.0：与之前的过滤结果相同

·         ip6 net 2406:da00:ff00::/64：抓取网络2406:da00:ff00:0000(IPv6)上发到/来自所有主机的数据流

·         not dst net 10.3.0.0/16：抓取除了发到以10.3开头的IP地址以外的所有数据流

·         not src net 10.3.0.0/16：抓取除了来自以10.3开头的IP地址以外的所有数据流

·         ip proto ：抓取ip协议字段等于 值的报文。如TCP(code 6), UDP(code 17), ICMP(code 1)。

·         ip[2:2]== ：ip报文大小

·         ip[8]== ：TTL(Time to Live)值

·         ip[9]== ：协议值

·         icmp[icmptype]== : 抓取 ICMP代码等于identifier的ICMP报文, 如icmp-echo 以及 icmp-request。

方括号中第一个数字表示从协议头开始的偏移量，第二个数字表示需要观察多少位。

image004.png

抓取发到广播或多播地址的数据流:

只需侦听广播或多播数据流，就可以掌握网络上主机的许多信息。

·         ip broadcast：抓取广播报文

·         ip multicast：抓取多播报文

·         dst host ff02::1：抓取到IPv6多播地址所有主机的数据流

·         dst host ff02::2：抓取到IPv6多播地址所有路由器的数据流

小贴士：

Wireshark包含了一些默认的抓包过滤条件。点击主工具栏的Edit Capture Filters，跳转到已保存抓包过滤列表。你会发现一些常见抓包过滤的示例。

抓取基于MAC地址的数据流:

当你需要抓取发到/来自某一主机的IPv4或IPv6数据流，可创建基于主机MAC地址的抓包过滤条件。

应用MAC地址时，需确保与目标主机处于同一网段。

·         ether host 00:08:15:00:08:15：抓取发到/来自00:08:15:00:08:15的数据流

·         ether src 02:0A:42:23:41:AC：抓取来自02:0A:42:23:41:AC的数据流

·         ether dst 02:0A:42:23:41:AC：抓取发到02:0A:42:23:41:AC的数据流

·         not ether host 00:08:15:00:08:15：抓取除了发到/来自00:08:15:00:08:15以外的所有数据流

·         ether broadcast或ether dst ff:ff:ff:ff:ff:ff：抓取广播报文

·         ether multicast：多播报文

·         抓取指定以太网类型的报文：ether proto 0800

·         抓取指定VLAN：vlan

·         抓取指定几个VLAN：vlan and vlan

抓取基于指定应用的数据流:

你可能需要查看基于一个或几个应用的数据流。抓包过滤器语法无法识别应用名，因此需要根据端口号来定义应用。通过目标应用的TCP或UDP端口号，将不相关的报文过滤掉。

·         port 53：抓取发到/来自端口53的UDP/TCP数据流（典型是DNS数据流）

·         not port 53：抓取除了发到/来自端口53以外的UDP/TCP数据流

·         port 80：抓取发到/来自端口80的UDP/TCP数据流（典型是HTTP数据流）

·         udp port 67：抓取发到/来自端口67的UDP数据流（典型是DHCP据流）

·         tcp port 21：抓取发到/来自端口21的TCP数据流（典型是FTP命令通道）

·         portrange 1-80：抓取发到/来自端口1-80的所有UDP/TCP数据流

·         tcp portrange 1-80：抓取发到/来自端口1-80的所有TCP数据流

抓取结合端口的数据流:

当你需要抓取多个不连续端口号的数据流，将它们通过逻辑符号连接起来，如下图所示：

·         port 20 or port 21：抓取发到/来自端口20或21的UDP/TCP数据流（典型是FTP数据和命令端口）

·         host 10.3.1.1 and port 80：抓取发到/来自10.3.1.1端口80的数据流

·         host 10.3.1.1 and not port 80：抓取发到/来自10.3.1.1除了端口80以外的数据流

·         udp src port 68 and udp dst port 67：抓取从端口68到端口67的所有UDP数据流（典型是从DHCP客户端到DHCP服务器）

·         udp src port 67 and udp dst port 68：抓取从端口67到端口68的所有UDP数据流（典型是从DHCP服务器到DHCP客户端）

·         抓取TCP连接的开始（SYN）和结束（FIN）报文，配置tcp[tcpflags] & (tcp-syn|tcp-fin)!=0

·         抓取所有RST(Reset)标志位为1的TCP报文，配置tcp[tcpflags] & (tcp-rst)!=0

·         less ：抓取小于等于某一长度的报文，等同于len <=

·         greater ：抓取大于等于某一长度的报文，等同于len >=

SYN: 简历连接的信号

FIN: 关闭连接的信号

ACK: 确认接收数据的信号

RST: 立即关闭连接的信号

PSH: 推信号，尽快将数据转由应用处理

·         tcp[13] & 0x00 = 0: No flags set (null scan)

·         tcp[13] & 0x01 = 1: FIN set and ACK not set

·         tcp[13] & 0x03 = 3: SYN set and FIN set

·         tcp[13] & 0x05 = 5: RST set and FIN set

·         tcp[13] & 0x06 = 6: SYN set and RST set

·         tcp[13] & 0x08 = 8: PSH set and ACK not set

tcp[13]是从协议头开始的偏移量，0,1,3,5,6,8是标识位。

image005.png

尽量避免使用抓包过滤。即便多看几个报文，也比漏看一个报文要好。当你抓取了大量报文的时候，用显示过滤（过滤选项也更多）来重点查看某一数据流。

小贴士：

如果你需要查看TCP帧中的某一ASCII字符串，用Wireshark String-Matching Capture Filter Generator(http://www.wireshark.org/tools/string-cf.html)。例如，想要抓取HTTP GET报文，输入GET并将TCP偏移量设置为0。

             

Zhang_Jiawen

1.2K 消息

2014年7月21日 16:00

赞！

happydanye

8 消息

2014年7月21日 17:00

To 沛满：非常感谢，受益良多。

我们这个网络涉及电信和移动的互联互通，我们怀疑是电信动了手脚（有先例，不过那次是整个断了，这次电信升级了手段？）

WCD

43 消息

2014年7月21日 22:00

楼主再弄个FC版的贝

Zhang_Jiawen

1.2K 消息

2014年7月21日 23:00

FC版？

查看更多

查看全部

找不到事件！

Top