Roger_Wu
5 Tungsten

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧

分析无线报文不错,理论上配合其他一些工具,是可以通过分析802.11封包破解WPA-PSK的密码的。

0 项奖励
Highlighted
Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧

恩,比如802.11报文过滤技巧,安全这方面。

0 项奖励
daiwliang
2 Bronze

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(连载中)

+ 1000 赞 !

内容非常充实,期待后续更新。

0 项奖励
Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(连载中)

谢谢。

0 项奖励
Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(连载中)

一站式学习Wireshark(四):网络性能排查之TCP重传与重复ACK

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

介绍

作为网络管理员,很多时间必然会耗费在修复慢速服务器和其他终端。但用户感到网络运行缓慢并不意味着就是网络问题。

解决网络性能问题,首先从TCP错误恢复功能(TCP重传与重复ACK)和流控功能说起。之后阐述如何发现网络慢速之源。最后,对网络各组成部分上的数据流进行概况分析。这几张内容将会帮助读者识别,诊断,以及排查慢速网络。


更多信息

接下来的内容,较多是黑白图片了。虽然看起来有点不爽,但还是很值得一看。

TCP错误恢复功能:

TCP的错误恢复功能是定位,诊断及修复网络延时的最佳工具。

延时可以在单程也可以往返方向测量。高延时是网络管理员的头号大敌。本节我们讨论TCP高延时是如何导致序列号和确认号乱序的。

TCP重传:

主机报文重传是TCP最基本的错误恢复功能,它的目的是防止报文丢失。

报文丢失的可能因素有很多种,包括应用故障,路由设备过载,或暂时的服务宕机。报文级别速度是很高的,而通常报文丢失是暂时的,因此TCP能够发现和恢复报文丢失显得尤为重要。

决定报文是否有必要重传的主要机制是重传计时器(retransmission timer),它的主要功能是维护重传超时(RTO)值。当报文使用TCP传输时,重传计时器启动,收到ACK时计时器停止。报文发送至接收到ACK的时间称为往返时间(RTT)。对若干次时间取平均值,该值用于确定最终RTO值。在最终RTO值确定之前,确定每一次报文传输是否有丢包发生使用重传计时器,下图说明了TCP重传过程。

image001.jpg

当报文发送之后,但接收方尚未发送TCP ACK报文,发送方假设源报文丢失并将其重传。重传之后,RTO值加倍;如果在2RTO值到达之前还是没有收到ACK报文,就再次重传。如果仍然没有收到ACK,那么RTO值再次加倍。如此持续下去,每次重传RTO都翻倍,直到收到ACK报文或发送方达到配置的最大重传次数。

最大重传次数取决于发送操作系统的配置值。默认情况下,Windows主机默认重传5次。大多数Linux系统默认最大15次。两种操作系统都可配置。

示例如下图:

image002.png

image003.png


TCP重传过程发送的第一个报文如下图所示(图片不很清楚,已经尽力了):

image004.jpg

这是一个TCP PSH/ACK报文,包含648字节数据,从10.3.30.1发送至10.3.71.7。这是一个典型的数据报文。

在通常情况下,第一个报文发送之后很快会收到TCP ACK报文。然而,在这个case里,第二个是重传报文。可以在Packet list面板里看到。Info栏清楚的标明“TCP Retransmission”,报文以黑色背景红色字体标出。下图是Packet List面板中的重传示例(仍然不清楚,但可参见上图):

image005.jpg

也可以在Packet DetailsPacket Bytes面板中查看来确定是否是重传报文,如下图所示:

image006.jpg

注意此报文与源报文相同(除了IP标识和checksum字段)。要验证这一点,比较两个报文的Packet Bytes

Packet Details面板,注意到重传报文在SEQ/ACK Analysis下面有些额外的信息。这些信息是由Wireshark提供的而并非报文本身。SEQ/ACK Analysis告诉我们这确实是一个重传报文,RTO值是0.206秒,此时的RTO是基于报文1的时间增量。

检查剩下的报文会得到类似的结果,不同之处只有IP标识和checksum,以及RTO值。要使报文之间的时间间隔形象化,在Packet List面板中查看Time栏,如下图所示。这里可以看到RTO值的翻倍增长关系。

image007.png

TCP重复ACK以及快速重传:

重复ACK是指在接收方收到乱序报文时,所发出的一类TCP报文。TCP使用报文头的序列号和确认号以有效保证数据按照发送的顺序接收和重组。

TCP连接建立以后,握手过程中交换的一个最重要的信息是初始序列号(ISN)。一旦连接双方设定了ISN之后,接下来发送的报文所包含的序列号增加一个数据载荷值。

假设有个主机ISN5000,发送500字节报文至接收方。一旦报文接收之后,接收端回复一个ACK号为5500TCP ACK报文,基于以下公式:

Sequence Number In + Bytes of Data Received = Acknowledgment Number Out

按照上述计算结果,返回发送端的确认编号实际上是接收端希望收到的序列号。示例如下图:

image008.jpg

数据接收方通过序列号来检查报文丢失。接收方通过追踪接收到的序列号,能够确认序列号是否乱序。当接收方收到一个不正常的序列号,它会假设传输过程中有报文丢失。为了正确重传数据,接收方必须拥有丢失报文,所以它发送包含有丢失报文正确序列号的ACK报文,以便发送方重传此报文。

当重传主机从发送端接收到3个重复ACK时,它会假设此报文确实在传送中丢失,并且立即发送一个快速重传。一旦触发了快速重传,所有正在传输的其他报文都被放入队列中,直到快速重传报文发送为止。过程如下图所示:

image009.jpg

承接上文的彩图:

image010.png

本例中第一个报文如下图:

image011.jpg

这是一个TCP ACK报文,从数据接收端(172.31.136.85)发给发送端(195.81.202.68,确认前一个报文所发送的数据。

此报文中的确认编号是1310973186,应当是下一个接收报文的序列号,如下图所示:

image012.jpg

不幸的是接收端的序列号是1310984130,并不是所期望的值。这意味着报文在传送中丢失。接收端注意到报文乱序,并且在第三个报文中发送重复ACK,如下图所示:

image013.jpg

可以通过以下两种方式之一来确认这是一个重复ACK

Packet Detaisl面板中的Info栏。报文呈现黑色背景红色字体。

SEQ/ACK Analysis下的Packet Deatails面板。扩展这一栏会发现报文显示为duplicate ACK。接下来几个报文重复此过程。如下图所示:

image014.jpg

此文件中的第四个报文是发送端所发出具有错误序列号的另一个数据块。因此,接收端发送第二个重复ACK。接收端又收到一个乱序报文。从而触发了第三以及最后一个重复ACK.

一旦发送方接收到接收方所发来的第三个重复ACK,它就会暂停所有传输报文并且重传丢失报文,下图显示了快速重传过程:

image015.jpg

重传报文同样可以通过Packet List面板的Info栏观察到。报文呈现黑色背景红色字体。这个报文的SEQ/ACK Analysis截面告诉我们这可能是一个快速重传帧。(标识报文为快速重传的信息不是报文本身所包含的内容,而是Wireshark的功能)。最后一个报文是接收到快速重传的ACK

             

Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(6月16日更新)

一站式学习Wireshark(五):TCP窗口与拥塞处理

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

介绍

TCP通过滑动窗口机制检测丢包,并在丢包发生时调整数据传输速率。滑动窗口机制利用数据接收端的接收窗口来控制数据流。

接收窗口值由数据接收端指定,以字节数形式存储于TCP报文头,并告知传输设备有多少数据将会存储在TCP缓冲区。缓冲区就是数据暂时放置的地方,直至传递至应用层协议等待处理。因此,发送端每次只能发送Window Size字段指定的数据量。为了使发送端继续传送数据,接收端必须发送确认信息:之前的数据接收到了。同时必须对占用缓冲区的数据进行处理以释放缓存空间。下图显示了接收窗口是如何工作的:

image002.jpg

上图中,客户端向服务器发送数据,服务器接收窗口是5000字节。客户端发送了2500字节,服务器缓冲区还剩2500字节,之后又发送了2000字节,从而缓冲区只剩500字节。服务器发送确认信息。对缓存中数据进行处理并清空缓存。此过程重复进行,客户端又发送3000字节和1000字节,服务器缓存减少至1000字节,客户端再次确认数据并处理缓存中内容。

更多信息

调整窗口大小:

TCP堆栈接收到数据的时候,生成一个确认信息并以回复的方式发送,但是放置在接收端缓存中的数据并不总是立即被处理。当服务器忙于处理从多个客户端接收的报文,服务器很有可能因为清理缓存而变得缓慢,无法腾出空间接收新的数据,如果没有流控,则可能会造成丢包和数据损坏。好在,接收窗口所设定的速率无法使服务器正常处理数据时,能够调整接收窗口大小。通过减小返回给发送端的ACK报文的TCP头窗口大小值来实现。如下图所示:

image003.jpg

上图中,服务器初始窗口大小为5000字节。客户端发送2000字节,之后又发送了2000字节,缓冲区中只有1000字节可用。服务器意识到缓冲区正在快速填满,它知道如果数据继续以此速率传输,很快会有报文丢失。为了防止报文丢失,服务器发送确认信息给客户端,更新窗口大小为1000字节。结果,客户端减少数据发送,服务器以可以接受的速率处理缓存内容,即保持数据流以稳定的速率传输。

调整窗口大小在两个方向都是可行的。当服务器能够更加快速的处理报文时,它会发送一个较大窗口的ACK报文。

零窗口暂停数据流:

某些情况下,服务器无法再处理从客户端发送的数据。可能是由于内存不足,处理能力不够,或其他原因。这可能会造成数据被丢弃以及传输暂停,但接收窗口能够帮助减小负面影响。

当上述情况发生时,服务器会发送窗口为0的报文。当客户端接收到此报文时,它会暂停所有数据传输,但会保持与服务器的连接以传输探测(keep-alive)报文。探测报文在客户端以稳定间隙发送,以查看服务器接收窗口状态。一旦服务器能够再次处理数据,将会返回非零值窗口大小,传输会恢复。下图示例了零窗口通知过程。

image004.jpg

服务器初始接收数据窗口为5000字节大小。从客户端接收4000字节数据之后,服务器负载变得非常繁重,无法继续处理客户端任何数据。服务器于是发送窗口大小值为0的报文。客户端暂停数据传输并发送一个探测报文。探测报文之后,服务器回复以告知客户端现在可以接收数据的报文,以及窗口大小为1000字节。客户端恢复传送数据。

TCP滑动窗口实战:

本例中,开始从192.168.0.20发送至192.168.0.30。我们关心的是窗口大小字段,可以从Packet List面板的Info栏以及Packet DetailsTCP报文头看到。前三个报文后,可看到该值立刻减小,如下图所示:

image005.jpg

窗口大小值从第一个报文的8760字节变成第二个报文的5840字节到第三个报文的2920字节。窗口大小值的减小是主机延时的典型标志。在时间栏注意到这一过程发生的非常迅速。当窗口大小迅速减小的时候,通常就有可能下降为零。这就是第四个报文所发生的,如下图所示:

image006.jpg

第四个报文从192.168.0.20发送至192.168.0.30,目的是告诉192.168.0.30它不再接收任何数据。0值见于TCP报文头WiresharkPacket List面板Info栏,以及TCP报文头的SEQ/ACK Analysis字段也告诉我们这是一个0窗口报文。

一旦发送了零窗口报文,192.168.0.30的设备不会再发送任何数据,直到收到从192.168.0.20的窗口更新,告知窗口大小已经增加了。本例中导致零窗口的问题是暂时的,所以在下一个报文中发送了窗口更新信息,如下图所示。

image007.jpg

本例中,窗口大小增加到一个非常健康的数值64240字节Wireshark再次在SEQ/ACK Analysis告诉我们这是一个窗口更新。

一旦收到更新报文,192.168.0.30的主机就再次开始发送数据,在报文6和报文7中。这一过程发生很快。如果它持续时间再长一点,就可能会导致网络的潜在中断,引起数据传输减慢或失败。

下一个关于滑动窗口的例子,第一个报文是正常HTTP,从195.81.202.68172.31.136.85。此报文之后立刻跟随一个从172.31.136.85发送的零窗口报文,如下图所示:

image008.jpg

这与上一个例子中的零窗口报文十分类似,但结果显著不同,172.31.136.85主机不是发送一个窗口更新并回复通讯,而是一个探测报文,如下图所示:

image009.jpg

此报文被Wireshark标注为探测报文。时间栏告诉我们这一报文发生于最后一个接收到的报文3.4秒之后。这一过程持续若干次,一端发送零窗口报文另一端发送探测报文,如下图所示:

image010.jpg

探测报文发送间隙为3.46.813.5秒。这一过程可能会持续相当长一段时间,取决于通讯设备的操作系统。该情况下,把时间栏的值加起来,通讯暂停了25秒。

TCP差错控制和流控排查总结:

重传报文

重传的发生是由于客户端检测到服务器没有接收到它所发送的数据。因此,取决于你所分析的是通讯的哪一端,有可能是看不见重传的。如果从服务器端抓取数据,并且它确实没有接收到客户端所发送的和重传报文,可能会一无所获因为无法看见重传报文。如果怀疑并不是服务器端导致的报文丢失,可以考虑在客户端尝试抓取报文,以查看实际是否有重传发生。

重复ACK

可以将重复ACK看作重传的“所谓相反面”,因为它是在服务器检测到客户端发送报文丢失的时候产生的。大多数情况下,在通讯两端抓取流量时都可以看到重复ACK。需记住当接收报文乱序时会触发重复ACK。例如,如果服务器之接收到发送的第一个和第三个报文,就会导致发送重复ACK引起客户端对第二个报文的快速重传,因为你已经收到了第一个和第三个报文,因此不管导致第二个报文丢弃的原因是什么,都很有可能是暂时的,因此大多数情况下重复ACK都会成功发送和接收。当然,这种情形并不一定永远会发生,因此当你怀疑在服务器端丢失报文而又看不到任何重复ACK,考虑从通讯的客户端抓取报文。

零窗口和探测报文

滑动窗口直接与服务器无法接收和处理报文有关,任何窗口大小的缩小以及零值都是服务器问题的直接结果。所以如果你在哪里看到这两者之一发生,就应该在那里深入研究。通常应当在网络通讯两端一直主机窗口更新报文。

Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(6月24日更新)

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

Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(6月24日更新)

一站式学习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

Zhang_Jiawen
4 Tellurium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)

一站式学习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 <host_name> http.host==<host_name>

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,以及主页上两个其他位置。

Yanhong1
4 Beryllium

Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)

长篇巨作又更新了

0 项奖励