网络：抓包分析ping的原理

谁借莪１个温暖的怀抱￠ 2022-12-17 03:29 556阅读 0赞

>  *  控制报文协议（Internet Control Message Protocol，ICMP）是 TCP/IP 协议族的一个子协议。ICMP 协议用于在 IP 主机和路由器之间传递控制消息，描述网络是否通畅、主机是否可达、路由器是否可用等网络状态。
>  *  由于IP协议简单，数据传输天然存在不可靠，无连接等特点，为了解决数据传输出现的问题，人们引入了ICMP协议。虽然ICMP协议的数据包并不传输用户数据，但是对于用户数据的传递有着重要的作用

# ping一下 #

ping是基于`ICMP`协议工作的，所以要明白ping的工作，就要先学习**ICMP协议**

## IP协议的助手—ICMP ##

## ICMP是什么 ##

ICMP 全称是**Internet Control Message Protocol**，也就是**互联网控制报文协议**

里面有个关键词：**控制**，如何控制呢？

*  网络包在复杂的网络传输环境里，常常会遇到各种问题。
 *  当遇到问题的时候，总不能死的不明不白，没头没脑的作风不是计算机网络的风格。
 *  所以需要传出消息，报告遇到了什么问题，这样才可以调整传输策略，以此来控制整个局面。

ICMP经常被认为是IP层的一个组成部分。它传递差错报文以及其他需要注意的信息。ICMP报文通常被IP层或者更高层协议(TCP/UDP)使用，一些ICMP报文把差错报文返回给用户进程。

## ICMP有什么功能 ##

`ICMP` 主要的功能包括：**确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center]

在`IP`通信中如果某个`IP`包因为某种原因未能达到目标地址，那么这个具体的原因将**由ICMP负责通知**

*  比如上图例子：主机`A`向主机`B`发送了数据包，由于某种原因，途中的路由器`2`未能发现主机`B`的存在，这时，路由器`2`就会向主机`B`发送一个`ICMP`目标不可达的数据包，说明发往主机`B`的包未能成功。
 *  ICMP的这种通知消息会使用`IP`进行发送
 *  因此，从路由器`2`返回的ICMP包会按照往常的路由控制先经过路由器`1`再转发给主机`A`。收到该ICMP包的主机`A`则分解ICMP的首部和数据域以后得知具体发生问题的原因。

ICMP报文是在IP数据报内部被传输的，如下图所示：  
![在这里插入图片描述][20210608153607909.png]

## 为什么要ICMP协议 ##

数据包在发送到目标主机的过程中，通常会经过一个或多个路由器。而数据包在通过这些路由进行传输时，可能会遇到各种问题，导致数据包无法发送到目标主机上。为了了解数据包在传输的过程中在哪个环节出现了问题，就需要用到 ICMP 协议。它可以跟踪消息，把问题反馈给源主机。

## ICMP 包头格式 ##

![在这里插入图片描述][20201022160042527.gif_pic_center]  
ICMP报文是封装在IP包里面，它工作在网络层，是IP协议的助手。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 1]

ICMP包头的类型字段和代码字段取值如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]  
从上面可以看出，ICMP包头的类型，大致可以分为两类：

*  一类是用于诊断的查询信息，即：**查询报文信息**
 *  另一类是通知出错原因的错误信息，即：**差错报文类型**

为什么要对ICPM类型进行区分？

*  因为需要对 ICMP差错报文有时需要作特殊处理，因此我们需要对它们进行区分
 *  在对ICMP差错报文进行响应时，永远不会生成另一份ICMP报文类型(如果没有这个限制规则，可能会遇到一个差错产生另一个差错的情况，而差错再产生差错，这样会无休止地循环下去)

下面各种情况都不会导致产生ICMP差错报文

*  ICMP差错报文（但是，ICMP查询报文可能会产生ICMP差错报文）
 *  目的地址是广播地址或多播地址（D类地址）的I P数据报。
 *  作为链路层广播的数据报
 *  不是IP分配的分片的第一片
 *  源地址不是单个主机的数据报。这也就是说，源地址不能是零地址、环回地址、广播地址或多播地址。

这些规则是为了防止过去允许ICMP差错报文对广播分组响应所带来的广播风暴。

### 查询报文类型 ###

> 回送消息 — 类型 `0`和`8`

**回送消息**用于进行通信的主机或者路由器之间，**判断所发送的数据包是否已经成功到达对端的一种消息**，`ping`命令就是利用这个消息实现的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 2]  
可以向对端主机发送**回送请求**的消息（ `ICMP Echo Request Message` ，类型 `8` ），也可以接收对端主机发回来的**回送应答**消息（ `ICMP Echo Reply Message` ，类型 `0` ）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 3]  
相比原生的 ICMP，这里多了两个字段：

*  **标识符**：用以区分是哪个应用程序发`ICMP` 包，比如用进程`PID` 作为标识符；
 *  **序号**：序列号从`0` 开始，每发送一次新的回送请求就会加`1`， 可以用来确认网络包是否有丢失。

> ICMP时间戳请求与应答------类型13或者14

ICMP时间戳请求系统向另一个系统查询当前时间。返回的建议值是自午夜开始计算的毫秒数，协调的统一时间UTC。这种ICMP报文的好处是它提供了毫秒级的分辨率，而利用其他方法从别的主机获取的时间（如某些Unix系统提供的rdate命令）只能提供秒级的分辨率。由于返回的时间是从午夜开始计算的，因此调用者必须通过其他方法获知当时的日期，这是它的一个缺陷。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]  
请求端填写发起时间戳，然后发送报文。应答系统收到请求报文时填写接收时间戳，在发送应答时填写发送时间戳。但是，实际上，大多数的实现把后面两个字段都设成相同的值（提供三个字段的原因是可以让发送方分别计算发送请求的时间和发送应答的时间）。

> ICMP地址掩码请求与应答-----类型17或者18

ICMP地址掩码请求用于无盘系统在引导过程中获取自己的子网掩码。系统广播它的ICMP请求报文。无盘系统获取子网掩码的另一个方法是BOOTP协议。

![在这里插入图片描述][20210608155110923.png]  
ICMP报文中的标识符和序列号字段由发送端任意选择设定，这些值将在应答中被返回。这样，发送端就可以把应答与请求进行匹配。

### 差错报文类型 ###

接下来，说明几个常用的 ICMP 差错报文的例子：

*  目标不可达消息 —— 类型 为 3
 *  原点抑制消息 —— 类型 4
 *  重定向消息 —— 类型 5
 *  超时消息 —— 类型 11

#### 目标不可达消息（Destination Unreachable Message） —— 类型为`3` ####

IP 路由器无法将 IP 数据包发送给目标地址时，会给发送端主机返回一个**目标不可达**的 ICMP 消息，并在这个消息中显示不可达的具体原因，原因记录在 ICMP 包头的**代码**字段。

由此，根据 ICMP 不可达的具体消息，发送端主机也就可以了解此次发送**不可达的具体原因**。

常见的目标不可达类型的代码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 4]

> 网络不可达代码为`0`

*  外卖版本：小林第一次送外卖时，小区里只有 A 和 B 区两栋楼，但送餐地址写的是 C 区楼，小林表示头上很多问号，压根就没这个地方。
 *  正常版本：
    
     *  IP 地址是分为网络号和主机号的，所以当路由器中的路由器表匹配不到接收方 IP 的网络号，就通过ICMP 协议以**网络不可达**（ `Network Unreachable` ）的原因告知主机。
     *  自从不再有网络分类以后，网络不可达也渐渐不再使用了。

> 主机不可达代码为`1`

*  外卖版本：小林第二次送外卖时，这次小区有 5 层楼高的 C 区楼了，找到地方了，但送餐地址写的是 C 区楼 601号房 ，说明找不到这个房间。
 *  正常版本： 当路由表中没有该主机的信息，或者该主机没有连接到网络，那么会通过 ICMP 协议以**主机不可达**（ `Host Unreachable` ）的原因告知主机。

> 协议不可达代码为 `2`

*  外卖版本：小林第三次送外卖时，这次小区有 C 区楼，也有 601 号房，找到地方了，也找到房间了，但是一开门人家是外国人说的是英语，我说的是中文！语言不通，外卖送达失败~
 *  正常版本：当主机使用 TCP 协议访问对端主机时，能找到对端的主机了，可是对端主机的防火墙已经禁止 TCP 协议访问，那么会通过 ICMP 协议以**协议不可达**的原因告知主机。

> 端口不可达代码为`3`

*  外卖版本：小林第四次送外卖时，这次小区有 C 区楼，也有 601 号房，找到地方了，也找到房间了，房间里的人也是说中文的人了，但是人家说他要的不是外卖，而是快递。。。
 *  正常版本：当主机访问对端主机 8080 端口时，这次能找到对端主机了，防火墙也没有限制，可是发现对端主机没有进程监听 8080 端口，那么会通过 ICMP 协议以**端口不可达**的原因告知主机。

> 需要进行分片但设置了不分片位代码为 `4`

*  外卖版本：小林第五次送外卖时，这次是个吃播博主点了 100 份外卖，但是吃播博主要求一次性要把全部外卖送达，小林的一台电动车装不下呀，这样就没办法送达了。
 *  正常版本：发送端主机发送 IP 数据报时，将 IP 首部的**分片禁止标志**位设置为 1 。根据这个标志位，**途中的路由器遇到超过 MTU 大小的数据包时，不会进行分片，而是直接抛弃**。随后，通过一个 ICMP 的不可达消息\*\*类型，代码为 `4`的报文，告知发送端主机。

#### 原点抑制消息（ICMP Source Quench Message） —— 类型 `4` ####

*  在使用低速广域线路的情况下，连接 WAN 的路由器可能会遇到网络拥堵的问题。
 *  ICMP 原点抑制消息的目的就是为了**缓和这种拥堵情况。**
 *  **当路由器向低速线路发送数据时，其发送队列的缓存变为零而无法发送出去时，可以向 IP 包的源地址发送一个 ICMP 原点抑制消息。**
 *  收到这个消息的主机借此了解在整个线路的某一处发生了拥堵的情况，从而增大 IP 包的传输间隔，减少网络拥堵的情况。
 *  然而，由于这种 ICMP 可能会引起不公平的网络通信，**一般不被使用。**

#### 重定向消息（ICMP Redirect Message） —— 类型 `5` ####

*  如果路由器发现发送端主机使用了「不是最优」的路径发送数据，那么它会返回一个 ICMP **重定向消息**给这个主机。
 *  在这个消息中包含了 **最合适的路由信息和源数据**。这主要发生在路由器持有更好的路由信息的情况下。路由器会通过这样的 ICMP 消息告知发送端，让它下次发给另外一个路由器。
 *  好比，小林本可以过条马路就能到的地方，但小林不知道，所以绕了一圈才到，后面小林知道后，下次小林就不会那么傻再绕一圈了。

#### 超时消息（ICMP Time Exceeded Message） —— 类型 `11` ####

*  IP 包中有一个字段叫做 `TTL`（ `Time To Live`，生存周期），它的 **值随着每经过一次路由器就会减1，直到减到 0 时该 IP 包会被丢弃。**
 *  此时，路由器将会发送一个**ICMP 超时消息**给发送端主机，并通知该包已被丢弃。
 *  设置 IP 包生存周期的主要目的，是为了在路由控制遇到问题发生循环状况时，避免 IP 包无休止地在网络上被转发。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 5]  
此外，有时可以用 TTL 控制包的到达范围，例如设置一个**较小的 TTL 值。**

## ping —— 查询报文类型的使用 ##

接下来，我们重点来看 **`ping` 的发送和接收过程**。

同个子网下的主机`A` 和 主机 `B`，主机 `A` 执行 `ping` 主机 `B` 后，我们来看看其间发送了什么？  
![在这里插入图片描述][20201022170735984.png_pic_center]  
ping命令执行的时候，源主机首先会构建一个 **ICMP回送请求消息**数据包

ICMP数据包中包含多个字段，最重要的是两个：

*  **类型**：对于回送请求消息而言该字段为`8`
 *  **序号**： 主要用于区分连续ping的时候发出的多个数据包

每发出一个请求数据包，序号会自动加`1`。为了能够计算往返时间`RTT`，它会在报文的数据部分插入发送时间。  
![在这里插入图片描述][20201022171813174.png_pic_center]  
然后，由`ICMP` 协议将这个数据包连同地址 `192.168.1.2` 一起交给`IP 层`。IP 层将以 192.168.1.2 作为**目的地址**，本机 IP 地址作为**源地址**，**协议字段**设置为`1` 表示是 `ICMP` 协议，再加上一些其他控制信息，构建一个`IP` 数据包。  
![在这里插入图片描述][20201022171913552.png_pic_center]  
接下来，需要加入`MAC` 头。如果在本地`ARP`映射表中查找出 IP 地址 192.168.1.2 所对应的 MAC地址，则可以直接使用；如果没有，则需要发送 ARP 协议查询 MAC 地址，获得 MAC 地址后，由`数据链路层`构建一个`数据帧`，目的地址是 IP 层传过来的 MAC 地址，源地址则是本机的 MAC 地址；还要  
附加上一些控制信息，依据以太网的介质访问规则，将它们传送出去。

![在这里插入图片描述][20201022173428584.png_pic_center]  
主机 `B`收到这个数据帧后，先检查它的目的 `MAC`地址，并和本机的 `MAC` 地址对比，如符合，则接收，否则就丢弃。

接收后检查该数据帧，将`IP`数据包从帧中提取出来，交给本机的`IP` 层。

同样，`IP`层检查后，将有用的信息提取后交给`ICMP` 协议。

主机`B` 会构建一个 **ICMP 回送响应消息数据包**，回送响应数据包的类型**字段**为 0 ，**序号**为接收到的请求数据包中的序号，然后再发送出去给主机 A。

![在这里插入图片描述][20201022173626969.png_pic_center]  
在规定的时候间内，源主机如果没有接到 ICMP 的应答包，则说明目标主机不可达；如果接收到了ICMP 回送响应消息，则说明目标主机可达。

此时，源主机会检查，用当前时刻减去该数据包最初从源主机上发出的时刻，就是 ICMP 数据包的时间延迟。

针对上面发送的事情，总结成了如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 6]

当然这只是最简单的，同一个局域网里面的情况。如果跨网段的话，还会涉及网关的转发、路由器的转发等等。

但是对于 ICMP 的头来讲，是没什么影响的。会影响的是根据目标 IP 地址，选择路由的下一跳，还有每经过一个路由器到达一个新的局域网，需要换 MAC 头里面的 MAC 地址。

说了这么多，可以看出 ping 这个程序是使用了**ICMP 里面的 ECHO REQUEST(类型为 8)和ECHO REPLY(类型为 0)。**

[http://c.biancheng.net/view/6399.html][http_c.biancheng.net_view_6399.html]

# 抓包分析 #

tcpdump和wireshark

*  tcpdump仅仅支持命令行格式使用，常用在Linux服务器中抓包
 *  winshark是windows下抓包的，提供了可视化分析网络包的图形界面

我们可以在linux下使用tcpdump抓包，在windows上使用winshark分析

## 实践 ##

### 第一个包 ###

1、打开终端，因为ping是icmp协议，因此执行下面命令

tcpdump -i ens33 icmp and host 192.168.0.11 -nn
    # -i ens33表示抓取ens33网口的数据包
    # icmp表示抓取icmp协议的数据包
    # host表示主机过滤，抓取对应IP的数据包
    # -nn 表示不解析IP地址和端口号的名称

![在这里插入图片描述][20201022104724119.png_pic_center]

2、打开另一个终端，执行ping命令：

ping -I ens33 -c 3 192.168.0.11
    # -I ens33表示指定从ens33网口出去
    # -c 3 表示发出3个icmp数据包

![在这里插入图片描述][20201022104801645.png_pic_center]

这个时候我们可以在第一个终端中看到下面的界面：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 7]  
可以看到，tcpdump抓取到icmp数据包之后，输出的格式如下：  
![在这里插入图片描述][2020102210512286.png_pic_center]  
从数据包中，我们可以很清楚的看到`ICMP echo`的交互过程：

*  首先发送发发起一个`ICMP echo request`请求报文，接收方收到之后回了一个`ICMP echo reply`响应报文。
 *  每一个`ICMP`请求对应两个报文，因为我们之前发出了3个`ICMP`报文，因此整个过程中有六个报文。

我们也可以将`tcpdump`抓取到的数据包保存成`pcap`后缀的文件，然后用`Wireshark`来分析：

tcpdump -i ens33 icmp and host 192.168.0.11 -nn  -w ping.pcap
    # -i ens33表示抓取ens33网口的数据包
    # icmp表示抓取icmp协议的数据包
    # host表示主机过滤，抓取对应IP的数据包
    # -nn 表示不解析IP地址和端口号的名称
    # -w ping.pcap:表示将抓取到的数据包保存到ping.pcap文件中。

接着把 ping.pcap 文件拖到电脑，再用 Wireshark 打开它。打开后，就可以看到下面这个界面：  
![在这里插入图片描述][20201022110236664.png_pic_center]  
这里先简单的介绍下Wireshark的控制面板，这个面板包含7个字段，分别是：

*  NO.编号
 *  Time：包的时间戳
 *  Source：源地址
 *  Destination：目标地址
 *  Protocol：协议
 *  Length：包长度
 *  Info：数据包附加信息

在 Wireshark 的页面里，可以更加直观的分析数据包，不仅展示各个网络包的头部信息，还会用**不同的颜色来区分不同的协议**，由于这次抓包只有 ICMP 协议，所以只有紫色的条目。

从编号可以看出，一共有6帧，每一帧的结构都是类似的，如下：  
![在这里插入图片描述][20201022110600840.png_pic_center]

*  Frame 1: 物理层的数据帧情况， 对应OSI七层模型中的【物理层】
 *  Ethernet II, Src: 数据链路层以太网帧头部信息，对应OSI七层模型中的【数据链路层】
 *  Internet Protocol Version 4, Src: 互联网层IP包头信息，对应OSI七层模型中的【网络层】
 *  Internet Control Message Protocol: 互联网控制信息协议，即ICMP，对应OSI七层模型中的【网络层】

前三层基本上都是一样的，第四层开始就可以出现TCP, UDP 协议，第五层就可能有HTTP 应用层协议等等。

接下来我们来分析各个层的具体情况

*  第一层 : Frame: 物理层的数据帧概况

Frame 1: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
    # 第1帧，线路有98个字节（共784位），实际捕获到98字节
        Encapsulation type: Ethernet (1)
        # 封装类型: 以太网(1)
        Arrival Time: Oct 22, 2020 10:59:36.412790000 中国标准时间
        # 到达时间
        [Time shift for this packet: 0.000000000 seconds]
        # 包偏移时间
        Epoch Time: 1603335576.412790000 seconds
        [Time delta from previous captured frame: 0.000000000 seconds]
        # 两帧之间的时间间隔
        [Time delta from previous displayed frame: 0.000000000 seconds]
        # 捕获到显示的间隔时间
        [Time since reference or first frame: 0.000000000 seconds]
        # 此包和第一帧的时间间隔
        Frame Number: 1   #帧序号
        Frame Length: 98 bytes (784 bits)   #帧长度
        Capture Length: 98 bytes (784 bits) #捕获长度
        [Frame is marked: False]        #此帧是否做了标记：否
        [Frame is ignored: False]    #此帧是否被忽略：否
        [Protocols in frame: eth:ethertype:ip:icmp:data]   #帧内封装的协议层次结构
        [Coloring Rule Name: ICMP]  #着色标记的协议名称
        [Coloring Rule String: icmp || icmpv6] #着色规则显示的字符串

*  第二层： Ethernet II , Src: 数据链路层以太网帧头部信息。

Ethernet II, Src: VMware_4c:e6:d1 (00:0c:29:4c:e6:d1), Dst: Micro-St_64:86:44 (30:9c:23:64:86:44)
        Destination: Micro-St_64:86:44 (30:9c:23:64:86:44)  #目的MAC地址
        Source: VMware_4c:e6:d1 (00:0c:29:4c:e6:d1)        #源MAC地址   
        Type: IPv4 (0x0800)

*  第三层： Internet Protocol Version 4, Src: 以太网协议层

Internet Protocol Version 4, Src: 192.168.0.12, Dst: 192.168.0.11
     # IPv4 协议              源IP：192.168.0.12， 目的IP：192.168.0.11
        0100 .... = Version: 4   # 版本4
        .... 0101 = Header Length: 20 bytes (5)  #  头长度20字节
        Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)  #差分服务区域
        Total Length: 84    #总长度
        Identification: 0x81d9 (33241)  #鉴别
        Flags: 0x4000, Don't fragment  #标志
        Fragment offset: 0   #分的偏移量
        Time to live: 64  # 生存期
        Protocol: ICMP (1) # 协议名称： ICMP(将协议字段设置为1表示是ICMP协议)
        Header checksum: 0x3768 [validation disabled] # 头部校验和
        [Header checksum status: Unverified] # 头部校验和检验状态：
        Source: 192.168.0.12 # 源IP
        Destination: 192.168.0.11 #目的地IP

*  第四层：ICMP层【结构和ICMP协议的数据格式一样】

Internet Control Message Protocol   // 因特网控制信息协议
        Type: 8 (Echo (ping) request)  //  类型，ping 请求
        Code: 0  
        Checksum: 0x4cd3 [correct]        // 和校验
        [Checksum Status: Good]             // 和检验状态
        Identifier (BE): 24759 (0x60b7)  // 标识符
        Identifier (LE): 46944 (0xb760)  
        Sequence number (BE): 1 (0x0001)   // BE 序列号
        Sequence number (LE): 256 (0x0100)  //LE 序列号
        [Response frame: 2]
        Timestamp from icmp data: Oct 22, 2020 10:59:36.000000000 中国标准时间
        [Timestamp from icmp data (relative): 0.412790000 seconds]
        Data (48 bytes)    // 数据
            Data: 5c4c060000000000101112131415161718191a1b1c1d1e1f…
           [Length: 48]

> 从第4层往上面看，就和 上文【ping —— 查询报文类型的使用】过程是一样的

*  Type：标识ICMP消息类型。对于ICMPv6，从0到127的值是错误消息，值128到255是信息性消息。此字段的常用值在ICMP消息类和类型主题的表中给出。
    
     *  8表示Echo Request ， 回送请求报文。
     *  0表示Echo Reply ， 回送应答报文
 *  Code：标识每个ICMP消息类型值中消息的“子类型”。因此，可以为每个消息类型定义多达256个“子类型”。此字段的值显示在各个ICMP消息类型主题中。
 *  Checksum： 16位校验和字段，其计算方式与IPv4中的IP报头校验和类似。它为整个ICMP消息提供错误检测覆盖范围。请注意，在ICMPv6中，IPv6报头字段的一个伪报头用于校验和计算；这与TCP中的方法类似。
    
     *  Checksum为0x4cd3
 *  Sequence number (BE): 1 (0x0001) //标识码
 *  Sequence number (LE): 256 (0x0100) //序列码。
 *  5c4c060000000000101112131415161718191a1b1c1d1e1f…为发送的数据

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 8]  
Wireshark 用了分层的方式，展示了各个层的包头信息

*  可以在数据链路层，看到 MAC 包头信息，如源 MAC 地址和目标 MAC 地址等字段；
 *  可以在 IP 层，看到 IP 包头信息，如源 IP 地址和目标 IP 地址、TTL、IP 包长度、协议等 IP 协议各个字段的数值和含义；
 *  可以在 ICMP 层，看到 ICMP 包头信息，比如 Type、Code 等 ICMP 协议各个字段的数值和含义；

从 ping 的例子中，我们可以看到网络分层就像有序的分工，每一层都有自己的责任范围和信息，上层协议完成工作后就交给下一层，最终形成一个完整的网络包。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 9]

[Wireshark抓包深入分析一下Ping的过程][Wireshark_Ping]  
[Wireshark 分析ping报文][Wireshark _ping]  
[Wireshark 分析捕获的数据记录][Wireshark]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/53c2baa4667542858546f335586bd168.png
[20210608153607909.png]: /images/20221123/ccfefea2894b4719952eedba9c8ff32b.png
[20201022160042527.gif_pic_center]: /images/20221123/f655b7ff7cb74004bc00570c0eb6fbb4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/de2e0b14fcf741a6a44f5021141638b9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221123/d6969138ed4d48c2b284d454f8a4ffbe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/cc1441fc9151471a899fb54128bc74bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/ee3035253c7a4264aba282943923045e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20221123/5f26206d95b24dc08330f071c6f08c22.png
[20210608155110923.png]: /images/20221123/6bca72be69c54fc1b3782f3ac076f2ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/c73e3a6fed584ef093bb30ad57db2cb5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221123/6705bb83b89b4290bb31b21db1fc648a.png
[20201022170735984.png_pic_center]: /images/20221123/ce5fa481be1a411aaf73c3b7604ff9ab.png
[20201022171813174.png_pic_center]: /images/20221123/b27ec2a708204a499c8c04711f8e2ecb.png
[20201022171913552.png_pic_center]: /images/20221123/1b75eaeaaecf44699a6867990b654709.png
[20201022173428584.png_pic_center]: /images/20221123/fcbd5bbfee3f4f098199fbb67738bd65.png
[20201022173626969.png_pic_center]: /images/20221123/4cdce8f8035f41209a7879ef4740fe59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221123/ebf40e0da4a549dbaa05f29b9210563b.png
[http_c.biancheng.net_view_6399.html]: http://c.biancheng.net/view/6399.html
[20201022104724119.png_pic_center]: /images/20221123/9d8f3b3c5e084822b846635834d916a6.png
[20201022104801645.png_pic_center]: /images/20221123/3ddc25ae20aa4a59916eaddc7b88a1e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221123/c404b756fc50473fa660f837714e6884.png
[2020102210512286.png_pic_center]: /images/20221123/13917b83faf044afa1aa6f7f570df807.png
[20201022110236664.png_pic_center]: /images/20221123/e6fc5ea764e94dbf9bfcc034e6e11254.png
[20201022110600840.png_pic_center]: /images/20221123/3a2ea358aac24abfb12be7950c6fb2e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221123/b3508ed0590a462e8239bf339d5b709c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221123/eee5eff035ca48e29396f82fcd6bdbf9.png
[Wireshark_Ping]: https://blog.csdn.net/C_TestMG/article/details/86235879
[Wireshark _ping]: https://blog.csdn.net/u010999240/article/details/52969384
[Wireshark]: https://blog.csdn.net/guo_lei_lamant/article/details/83151152