Zhang_Jiawen
4 Beryllium

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

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.减小吞吐量。

0 项奖励
hu279318344
2 Bronze

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

你好,后面那两项,我没有添加出来,能不能麻烦你在给指导下,谢谢啦

0 项奖励
Zhang_Jiawen
4 Beryllium

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

“后面两项”指的是什么?如果是说最后两篇文章,我刚试了一下可以打开,换个浏览器试试?

0 项奖励
Zhang_Jiawen
4 Beryllium

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

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

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

0 项奖励
bairichard1
3 Argentum

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

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
4 Beryllium

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

赞!

0 项奖励
happydanye
2 Bronze

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

To 沛满:非常感谢,受益良多。

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

0 项奖励
happydanye
2 Bronze

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

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

0 项奖励
Zhang_Jiawen
4 Beryllium

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

先回答这个问题:

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

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

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

0 项奖励
Zhang_Jiawen
4 Beryllium

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