如上图所示，PC发送echo请求并接收echo回复。 Ping 数据包标记为类型8，响应数据包标记为类型0。

如果要多次ping 同一系统，请清除PC 上的ARP 缓存并使用以下ARP 命令生成新的ARP 请求：

HTTP：

HTTP协议是当今使用最广泛的基础协议。这是因为目前很多应用都是基于WEB方式，实现起来很容易，不需要额外的客户端。可以使用浏览器使用。该过程首先请求服务器传送网络文件。

如上图所示，该消息包含GET 命令。 HTTP发送第一个GET命令后，TCP在后续的链接过程中继续数据发送过程，并使用TCP发送数据。将数据返回给客户端。服务器在发送数据之前，会发送HTTP OK消息，通知客户端请求有效。如果服务器没有权限将目标发送给客户端，则会返回403 Forbidden。如果服务器找不到客户端请求的目标，则返回404。

如果没有更多的数据，就可以终止连接，类似于TCP的三向握手信号SYN和ACK消息。这里发送FIN和ACK消息。当服务器完成数据发送后，向客户端发送FIN/ACK，表示连接结束。然后客户端返回ACK消息并将FIN/ACK序列号加1。这将终止来自服务器端的通信。要终止此进程，客户端必须重新启动服务器进程。 FIN/ACK 过程必须在客户端和服务器端发起并确认。

介绍

基本IO 图：

IO 图是一个非常有用的工具。基本Wireshark IO 图表显示数据包捕获文件中的总体流量情况，通常以数据包或每秒字节为单位。默认X轴时间间隔为1秒，Y轴为每个时间间隔内的数据包数量。如果要显示每秒的位数或字节数，请单击单位并在Y 轴下拉列表中选择要显示的内容。这是一个基本应用程序，可帮助您查看流量的高峰/低谷。要查看更多详细信息，请单击图表中的任意点以查看消息详细信息。

为了便于说明，请单击示例数据包或使用您自己的Wireshark，然后单击“统计信息- IO 图表”。此数据包捕获是在HTTP 下载遇到数据包丢失时发生的。

注意：如果过滤条件为空，该图表将显示所有流量。

在大多数故障排除情况下，此默认显示并不是很有用。将Y 轴更改为每刻度位数以查看每秒流量。从该图中您可以看到峰值速率约为300kbps。如果您发现一个交通量为零的区域，这可能是一个问题。这个问题在查看图像时很容易发现，但在查看数据包列表时可能不那么明显。

.toutiaoimg.com/pgc-image/d4f3b43dadd146dcb7269ae53f09a035~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1717845439&x-signature=llVf3%2B%2BvOJFSt31hJYRxk3uVjU4%3D” alt=”d4f3b43dadd146dcb7269ae53f09a035~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1717845439&x-signature=llVf3%2B%2BvOJFSt31hJYRxk3uVjU4%3D” />
过滤：
每一个图形都可以应用一个过滤条件。这里创建两个不同的graph，一个HTTP一个ICMP。可以看到过滤条件中Graph 1使用“http”Graph 2使用“icmp”。图中可以看到红色ICMP流量中有些间隙，进一步分析。

创建两个图形，一个显示ICMP Echo（Type=8）一个显示ICMP Reply（Type=0）。正常情况下对于每一个echo请求会有一个连续的reply。这里的情况是：

可以看到红色脉冲线(icmp type==0 – ICMP Reply)中间有间隙，而整张图中ICMP请求保持连续。这意味着有些reply没有接收到。这是由于报文丢失导致的reply drop。CLI中看到的ping信息如下：

常用排错过滤条件:
对于排查网络延时/应用问题有一些过滤条件是非常有用的：
tcp.analysis.lost_segment：表明已经在抓包中看到不连续的序列号。报文丢失会造成重复的ACK，这会导致重传。
tcp.analysis.duplicate_ack：显示被确认过不止一次的报文。大凉的重复ACK是TCP端点之间高延时的迹象。
tcp.analysis.retransmission：显示抓包中的所有重传。如果重传次数不多的话还是正常的，过多重传可能有问题。这通常意味着应用性能缓慢和/或用户报文丢失。
tcp.analysis.window_update：将传输过程中的TCP window大小图形化。如果看到窗口大小下降为零，这意味着发送方已经退出了，并等待接收方确认所有已传送数据。这可能表明接收端已经不堪重负了。
tcp.analysis.bytes_in_flight：某一时间点网络上未确认字节数。未确认字节数不能超过你的TCP窗口大小（定义于最初3此TCP握手），为了最大化吞吐量你想要获得尽可能接近TCP窗口大小。如果看到连续低于TCP窗口大小，可能意味着报文丢失或路径上其他影响吞吐量的问题。
tcp.analysis.ack_rtt：衡量抓取的TCP报文与相应的ACK。如果这一时间间隔比较长那可能表示某种类型的网络延时（报文丢失，拥塞，等等）。
在抓包中应用以上一些过滤条件：

注意：Graph 1是HTTP总体流量，显示形式为packets/tick，时间间隔1秒。Graph 2是TCP丢失报文片段。Graph 3是TCP 重复ACK。Graph 4是TCP重传。
从这张图可以看到：相比于整体HTTP流量，有很多数量的重传以及重复ACK。从这张图中，可以看到这些事件发生的时间点，以及在整体流量中所占的比例。
函数:
IO Graphs有六个可用函数：SUM, MIN, AVG, MAX, COUNT, LOAD。
MIN( ), AVG( ), MAX( )
首先看一下帧之间的最小，平均和最大时间，这对于查看帧/报文之间的延时非常有用。我们可以将这些函数结合“frame.time_delta”过滤条件看清楚帧延时，并使得往返延时更为明显。如果抓包文件中包含不同主机之间的多个会话，而只想知道其中一个pair，可将“frame.time_delta”结合源和目标主机条件如“ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。如下图所示：

我们做了以下步骤：
将Y轴设置为“Advanced”，让Caculation域可见。不做这一步就看不到计算选项。X轴时间间隔1秒，所以每个柱状图代表1秒间隔的计算结果。过滤出两个特定IP地址的HTTP会话，使用条件：“(ip.addr==192.168.1.4&& ip.addr==128.173.87.169) && http”。使用3个不同的graph，分别计算Min(), Avg(), Max()。对每一个计算结果应用条件“frame.time_delta”，将style设置成“FBar”，显示效果最佳。从上图可见，在第106秒时数据流的MAX frame.delta_time达到0.7秒，这是一个严重延时并且导致了报文丢失。如果想要深入研究，只需要点击图中这一点，就会跳转至相应帧。对应于本例抓包文件中第1003个报文。如果你看见帧之间平均延时相对较低但突然某一点延时很长，可点击这一帧，看看这一时间点究竟发生了什么。
Count( )
此函数计算时间间隔内事件发生的次数，在查看TCP分析标识符时很有用，例如重传。例图如下：

Sum( )
该函数统计事件的累加值。有两种常见的用例是看在捕获TCP数据量，以及检查TCP序列号。让我们看看第一个TCP长度的例子。创建两个图，一个使用客户端IP 192.168.1.4为源，另一个使用客户端IP作为一个目的地址。每个图我们将sum()功能结合tcp.len过滤条件。拆分成两个不同的图我们就可以看到在一个单一的方向移动的数据量。

从图表中我们可以看到，发送到客户端的数据量（IP.DST = = 192.168.1.4过滤条件）比来自客户端的数据量要高。在图中红色表示。黑条显示从客户端到服务器的数据，相对数据量很小。这是有道理的，因为客户只是请求文件和收到之后发送确认数据，而服务器发送大文件。很重要的一点是，如果你交换了图的顺序，把客户端的IP作为图1的目标地址，并且客户端IP作为图2的源地址，采用了FBAR的时候可能看不到正确的数据显示。因为图编号越低表示在前台显示，可能会覆盖较高图号。
现在让我们看一下同一个数据包丢失和延迟的TCP序列号。

可以在图中看到若干峰值和下降，表示TCP传输有问题。与正常TCP报文比较：

这张图可以看到TCP序列号相当稳定地增加，表示传输平稳，没有过多重传或丢包。