计网实验三

Uncategorized
27k words

IP签名

前言

非常好的巩固理论知识的一次实验，我将实验原理所涉及的知识详尽的列举了出来。

检查内容很简单，抓包分析即可。我不再赘述（看情况，文章还会更新）

算了，搬一个简化版流程 （11/29更新）

Wireshark 报文抓取
DNS 报文
查看本机 WLAN 的 DNS 服务器

1
ipconfig /all

找到无线局域网适配器下的 DNS 服务器栏，记录下 IP（可能存在多个，先拿第一个尝试，不行再换）。

建议顺便也看下本机 IP

打开 wireshark 选择无线网卡设备 WLAN，开始抓包，同时使用浏览器访问 www.baidu.com。加载完成后立即停止 wireshark 的抓取。
使用过滤器 ip.src == 202.117.80.6 || ip.dst == 202.117.80.6，找到目的地址为 DNS 服务器的报文并找到报文信息含 www.baidu.com 的包，这就是要求的 DNS 请求报文。

此处 202.117.80.6 替换成你的 DNS 服务器地址
找到对应的源地址为 DNS 服务器的报文，即为 DNS 响应报文。

大概长这样：

No. Time Source Destination Protocol Length Info
39 2.863990 10.31.5.62 202.117.80.6 DNS 73 Standard query 0xad34 A www.baidu.com
40 2.867692 202.117.80.6 10.31.5.62 DNS 135 Standard response 0xad34 A www.baidu.com CNAME www.a.shifen.com A 220.181.38.149 A 220.181.38.150

其中响应报文中的 220.181.38.149 为百度服务器的 IP，可以通过 nslookup www.baidu.com 进行简单验证：

1
2
3
4
5
6
7
8
9
10
服务器:  UnKnown
Address:  202.117.80.6

非权威应答:
名称:    www.a.shifen.com
Addresses:  240e:ff:e020:966:0:ff:b042:f296
          240e:ff:e020:9ae:0:ff:b014:8e8b
          220.181.38.150
          220.181.38.149
Aliases:  www.baidu.com
注意，注意，有些人现实的网站IP可能不一样，直接访问IP无法到达百度官网，说明是CDN（内容分发网络）。

DNS 响应的地址可能会变，建议实时看下有没有更新

ARP

arp -a查看缓存
记得清缓存（需要管理员执行）

1
arp -d *

sh 可能会把 * 当成 glob，建议用 cmd 运行

学校校园网是华为机子的，看到 arp 报文的通信方含 Huawei 的基本就是了，另一个则是本机网卡设备。

TCP 三次握手与四次挥手

TCP 三次握手流程：

  1. 客户端发送 [SYN] SEQ=c
  2. 服务端响应 [SYN, ACK] SEQ=s ACK=c+1
  3. 客户端回复 [ACK] SEQ=c+1 ACK=s+1

加强下过滤器，把本机 ip 加上 (ip.src == 10.31.5.62 && ip.dst == 220.181.38.149) || (ip.src == 220.181.38.149 && ip.dst == 10.31.5.62)。

10.31.5.62 替换成自己的本机 IP

重点观察信息含 SYN/ACK 的报文，最后得到的结果大概长这样（过滤后基本是挨一块的）：

No. Time Source Destination Protocol Length Info
42 2.868711 10.31.5.62 202.117.80.6 TCP 66 58015 -> 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
43 2.892018 202.117.80.6 10.31.5.62 TCP 66 443 -> 58015 [SYN, ACK] Win=8192 Len=0 MSS=1380 WS=32 SACK_PERM
44 2.892237 10.31.5.62 202.117.80.6 TCP 54 58015 -> 443 [ACK] Seq=1 ACK=1 Win=131072 Len=0

TCP 四次挥手流程

  1. 客户端发送 [FIN, ACK] SEQ=s1 ACK=c1
  2. 服务器响应 [ACK] SEQ=c1 ACK=s1+1
  3. 服务器发送 [FIN, ACK] SEQ=s2 ACK=c2
  4. 客户端发送 [ACK] SEQ=c2 ACK=s2+1

浏览器与网站建立连接没那么简单，关闭页面后连接可能仍未被关闭，可以将浏览器的所有进程全部关闭等待一段时间直到抓到 FIN。通过该方法掐断的 TCP 连接大概率抓取不到第四次挥手的报文，但是应该可以抓取到一个客户端发送给服务器的 [RST, ACK]，该报文与服务器发送给客户端的 [FIN, ACK] 报文成对出现，且互相的接受序号与确认序号相等。

根据文档内容，实验分为两个部分：网络协议分析与验证，以及网络广播报文发送编程。以下是两个实验内容的详细介绍：

实验内容1: 网络协议分析与验证

实验目标：

  • 通过分析用户访问WEB网站的过程，深入理解WEB服务系统的原理。
  • 使用Wireshark或Ethereal工具捕获并分析WEB服务过程中的数据报文，了解DNS、WEB协议的工作机制。
  • 分析TCP三次握手建立连接和四次挥手断开连接的时序关系。
  • 探讨ARP协议的工作原理。
  • 研究数据链路层工业以太网的工作原理及其数据帧的格式。

实验内容：

  • 学习Wireshark或Ethereal工具的使用方法。
  • 访问www.baidu.com首页，捕获整个通信过程的数据包。
  • 通过分析捕获的数据包，加深对网络协议的理解。

实验要求：

  • 解释DNS请求报文、HTTP请求报文、TCP连接请求报文、ARP请求报文和应答报文从应用层到数据链路层各协议单元首部字段的意义。
  • 分析并提供证据证明如何获取特定信息，如www.baidu.com对应的IP地址、网关的IP地址和MAC地址等。
  • 以HTTP请求报文为例，描述WEB服务器接收到报文后，接收方从数据链路层到应用层如何识别不同层数据字段的长度和位置。
  • 讨论从应用层到数据链路层的校验字段，包括校验码的计算方法和校验范围，评估不同层次重复校验的必要性。
  • 如果实验中未观察到DNS和ARP协议的工作，探讨可能的原因及解决方案，并列出使用的网络命令。
  • 解释在客户端使用ping命令测试网络连通性时，出现的异常情况及其原因。

实验步骤：

  • 安装WINPCAP组件和Wireshark抓包工具。
  • 启动Wireshark，在指定的网络接口上开始抓包。
  • 浏览器访问www.baidu.com直至页面加载完成。【网络协议】DNS域名解析的详细过程
  • 结束抓包，对捕获的数据包进行分析，寻找满足实验要求的报文证据。nslookup baidu.com

ok，我们先来复习下相关知识：

DNS协议

简述：域名系统（Domain Name System，DNS）是因特网的一项服务，它用于将域名转换为IP地址。
DNS协议详解

详细解析DNS请求报文及其从应用层到数据链路层各协议单元首部字段的意义。

DNS请求报文从应用层到数据链路层各协议单元首部字段的表格形式：

DNS 请求报文结构

应用层：DNS 协议

字段名称 长度（字节） 描述
事务ID 2 用于匹配请求和响应报文。
标志 2 包含多个标志位，如查询类型、响应标志、递归期望等。
问题数 2 表示问题部分的条目数。
答案数 2 表示答案部分的条目数（在请求报文中为0）。
权威记录数 2 表示权威记录部分的条目数（在请求报文中为0）。
附加记录数 2 表示附加记录部分的条目数（在请求报文中可能为0）。
问题部分 可变 包含需要解析的域名和查询类型。
- QNAME 可变 域名，使用标签压缩方式表示。
- QTYPE 2 查询类型，如1表示A记录（IPv4地址）。
- QCLASS 2 查询类别，通常为1（IN，表示Internet）。
  1. ID (16位)：用于标识请求，响应中包含相同的ID，以便客户端可以匹配请求和响应。
  2. 标志 (16位)：
    • QR (1位)：查询/响应标志，0表示请求，1表示响应。
    • Opcode (4位)：操作码，通常为0表示标准查询。
    • AA (1位)：授权回答，如果设置，表示响应来自权威名称服务器。
    • TC (1位)：截断标志，如果设置，表示消息被截断。
    • RD (1位)：期望递归，如果设置，请求递归查询。
    • RA (1位)：可用递归，如果设置，表示服务器支持递归查询。
    • Z (3位)：保留位，必须为0。
    • Rcode (4位)：响应代码，0表示没有错误。
  3. 问题数 (16位)：问题部分中的条目数。
  4. 回答RRs数 (16位)：回答资源记录的数量。
  5. 权威RRs数 (16位)：权威资源记录的数量。
  6. 额外RRs数 (16位)：额外资源记录的数量。

传输层：UDP 协议

字段名称 长度（字节） 描述
源端口 2 发送方的端口号。
目的端口 2 接收方的端口号（DNS默认为53）。
长度 2 整个UDP数据报的长度（包括头部和数据）。
校验和 2 用于检测数据报是否损坏。对于IPv4，校验和是可选的；对于IPv6，校验和是必需的。
  1. 源端口 (16位)：发送方的端口号。
  2. 目的端口 (16位)：接收方的端口号，DNS默认使用53端口。
  3. 长度 (16位)：整个UDP数据包的长度，包括头部和数据部分。
  4. 校验和 (16位)：用于检测数据包在传输过程中是否发生错误。

网络层：IP 协议

字段名称 长度（字节） 描述
版本 1/8 表示IP协议版本（4表示IPv4，6表示IPv6）。
头部长度 1/8 表示IP头部的长度（以32位字为单位）。
服务类型 1 表示服务质量。
总长度 2 表示整个IP数据报的长度（包括头部和数据）。
标识 2 用于唯一标识主机发送的每一份数据报。
标志 1/8 控制数据报的分片。
分片偏移 2/8 表示数据报片在原始数据报中的位置。
生存时间 1 表示数据报的生存时间（跳数）。
协议 1 表示上层协议类型（17表示UDP）。
头部校验和 2 用于检测IP头部是否损坏。
源IP地址 4 (IPv4) 表示发送方的IP地址。
目的IP地址 4 (IPv4) 表示接收方的IP地址。
  1. 版本 (4位)：IP协议版本，如IPv4或IPv6。
  2. IHL (4位)：IP头部长度。
  3. 服务类型 (8位)：已废弃，现在用于区分服务。
  4. 总长度 (16位)：整个IP数据包的长度。
  5. 标识 (16位)：用于分片重组的唯一标识。
  6. 标志 (3位)：用于控制分片的行为。
  7. 分片偏移 (13位)：指示该分片相对于原始数据包的位置。
  8. 生存时间 (TTL, 8位)：限制数据包在网络中存活的时间，每通过一个路由器减1。
  9. 协议 (8位)：上层协议类型，对于DNS请求来说，通常是17 (UDP)。
  10. 头部校验和 (16位)：用于验证IP头部的完整性。
  11. 源地址 (32位或128位)：发送方的IP地址。
  12. 目的地址 (32位或128位)：接收方的IP地址。

数据链路层：以太网协议

字段名称 长度（字节） 描述
前导码 8 用于接收同步。
目标MAC地址 6 表示接收方的MAC地址。
源MAC地址 6 表示发送方的MAC地址。
类型 2 表示上层协议类型（0x0800表示IPv4）。
数据 46-1500 包含上层协议的数据。
帧校验序列 4 用于检测帧的完整性。
  1. 目标MAC地址 (48位)：接收方的物理地址。
  2. 源MAC地址 (48位)：发送方的物理地址。
  3. 类型 (16位)：指示上层协议类型，对于IP数据包，值为0x0800 (IPv4) 或 0x86DD (IPv6)。
  4. 数据：实际传输的数据，即上述所有层次的数据。
  5. 帧校验序列 (FCS) (32位)：用于检测以太网帧在传输过程中是否发生错误。

HTTP协议

面向开发者的 Web 技术-HTTP

超文本传输协议（HyperText Transfer Protocol）是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端—服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。
（HTTP通常使用TCP作为传输层协议，默认端口为80（HTTP）和443（HTTPS）。）

HTTP 请求报文结构

1. 请求行 (Request Line)

请求行包含请求方法、请求URI和HTTP版本。

字段名称 描述
请求方法 指定请求类型，常见的有GET、POST、PUT、DELETE等。
请求URI 指定请求资源的路径，可以是绝对路径或相对路径。
HTTP版本 指定使用的HTTP协议版本，如HTTP/1.1。

示例：

1
GET /index.html HTTP/1.1

2. 请求头 (Request Headers)

请求头包含多个键值对，每个键值对占一行，以冒号分隔。请求头提供了关于请求的额外信息。

字段名称 描述
Host 指定请求的主机和端口。
User-Agent 指定发送请求的客户端软件信息。
Accept 指定客户端可以接受的媒体类型。
Accept-Language 指定客户端可以接受的语言。
Accept-Encoding 指定客户端可以接受的内容编码。
Connection 指定连接类型，如keep-alive或close。
Content-Length 指定请求体的长度（字节数）。
Content-Type 指定请求体的媒体类型。
Cookie 指定客户端发送的Cookie信息。
Referer 指定请求的来源页面URL。
Authorization 指定认证信息。

示例：

1
2
3
4
5
6
7
8
9
10
11
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 23
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=abc123
Referer: http://www.example.com/
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

3. 请求体 (Request Body)

请求体包含客户端发送给服务器的数据，通常在POST、PUT等方法中使用。

示例：

1
username=admin&password=secret

完整的HTTP请求报文示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
POST /login HTTP/1.1 
Host: www.example.com 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate, br 
Connection: keep-alive
Content-Length: 23
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=abc123
Referer: http://www.example.com/
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

username=admin&password=secret

字段意义总结

  • 请求方法：指定请求类型，如GET、POST等。
  • 请求URI：指定请求资源的路径。
  • HTTP版本：指定使用的HTTP协议版本。
  • Host：指定请求的主机和端口。
  • User-Agent：指定发送请求的客户端软件信息。
  • Accept：指定客户端可以接受的媒体类型。
  • Accept-Language：指定客户端可以接受的语言。
  • Accept-Encoding：指定客户端可以接受的内容编码。
  • Connection：指定连接类型，如keep-alive或close。
  • Content-Length：指定请求体的长度（字节数）。
  • Content-Type：指定请求体的媒体类型。
  • Cookie：指定客户端发送的Cookie信息。
  • Referer：指定请求的来源页面URL。
  • Authorization：指定认证信息。
  • 请求体：包含客户端发送给服务器的数据，通常在POST、PUT等方法中使用。

TCP请求报文

TCP连接请求报文是TCP三次握手过程中的第一个报文，用于发起连接请求。下面详细解析TCP连接请求报文的结构和各字段的意义。

TCP 连接请求报文结构

1. 传输层：TCP 协议

TCP报文头包含多个字段，用于控制和管理TCP连接。以下是TCP报文头的主要字段及其意义：

字段名称 长度（字节） 描述
源端口 2 发送方的端口号。
目的端口 2 接收方的端口号。
序列号 4 发送方的序列号，用于标识发送的数据段。
确认号 4 接收方期望收到的下一个字节的序列号，初始时为0。
数据偏移 1/4 TCP头部的长度（以32位字为单位），通常为5（20字节）。
保留 1/4 保留字段，必须设置为0。
控制位 1 包含多个标志位，如SYN、ACK、FIN、RST等。
窗口大小 2 接收方的接收窗口大小，表示接收方可以接收的字节数。
校验和 2 用于检测TCP报文头和数据的完整性。
紧急指针 2 如果URG标志位被设置，表示紧急数据的偏移量。
选项 可变 用于扩展TCP功能，如最大段大小（MSS）、窗口缩放等。
填充 可变 用于填充选项字段，使TCP头部长度为32位的倍数。

TCP 连接请求报文示例

1. 三次握手过程

  • 第一次握手（SYN）：客户端发送一个带有SYN标志的TCP报文，请求建立连接。
  • 第二次握手（SYN+ACK）：服务器收到请求后，发送一个带有SYN和ACK标志的TCP报文，确认收到请求并同意建立连接。
  • 第三次握手（ACK）：客户端收到确认后，发送一个带有ACK标志的TCP报文，确认连接建立。

2. 第一次握手（SYN）报文

假设客户端的源端口为12345，服务器的目的端口为80，客户端的初始序列号为1000。

1
2
3
4
5
6
7
8
9
10
11
12
源端口: 12345
目的端口: 80
序列号: 1000
确认号: 0
数据偏移: 5
保留: 0
控制位: SYN (0x02)
窗口大小: 65535
校验和: (计算得出)
紧急指针: 0
选项: (可选)
填充: (可选)

字段意义详解

  • 源端口：发送方的端口号，用于标识发送方的应用程序。
  • 目的端口：接收方的端口号，用于标识接收方的应用程序。
  • 序列号：发送方的序列号，用于标识发送的数据段。在连接请求中，序列号是客户端选择的一个随机初始值。
  • 确认号：接收方期望收到的下一个字节的序列号。在连接请求中，确认号为0。
  • 数据偏移：TCP头部的长度（以32位字为单位），通常为5（20字节）。
  • 保留：保留字段，必须设置为0。
  • 控制位：包含多个标志位，如SYN、ACK、FIN、RST等。在连接请求中，SYN标志位被设置为1。
  • 窗口大小：接收方的接收窗口大小，表示接收方可以接收的字节数。
  • 校验和：用于检测TCP报文头和数据的完整性。校验和包括伪头部（IP头部的一部分）、TCP头部和数据。
  • 紧急指针：如果URG标志位被设置，表示紧急数据的偏移量。在连接请求中，通常为0。
  • 选项：用于扩展TCP功能，如最大段大小（MSS）、窗口缩放等。在连接请求中，通常包含MSS选项。
  • 填充：用于填充选项字段，使TCP头部长度为32位的倍数。

伪头部

在计算TCP校验和时，需要使用伪头部，伪头部包括以下字段：

字段名称 长度（字节） 描述
源IP地址 4 (IPv4) 发送方的IP地址。
目的IP地址 4 (IPv4) 接收方的IP地址。
零填充 1 1字节的零填充。
协议 1 表示上层协议类型（6表示TCP）。
TCP长度 2 TCP报文的总长度（包括头部和数据）。

完整的TCP连接请求报文示例

1
2
3
4
5
6
7
8
9
10
11
12
源端口: 12345
目的端口: 80
序列号: 1000
确认号: 0
数据偏移: 5
保留: 0
控制位: SYN (0x02)
窗口大小: 65535
校验和: (计算得出)
紧急指针: 0
选项: MSS=1460
填充: (可选)

伪头部示例

1
2
3
4
5
源IP地址: 192.168.1.1
目的IP地址: 192.168.1.2
零填充: 00
协议: 6 (TCP)
TCP长度: 40 (20字节的TCP头部 + 20字节的选项)

ARP 协议

ARP协议，全称为地址解析协议（Address Resolution Protocol），是一种用于将网络层的地址转换为数据链路层地址的重要网络协议。在TCP/IP网络中，ARP的主要功能是将IP地址转换为MAC地址，这一过程对于网络中的数据传输至关重要。

一文详解ARP协议

ARP协议的作用

在以太网环境中，数据传输依赖于MAC地址，而非IP地址。当一个主机需要与另一个主机通信时，它必须知道目标主机的MAC地址。ARP协议正是用来解决这个问题的，它通过目标设备的IP地址查询目标设备的MAC地址，从而确保通信的顺利进行。

ARP工作流程

ARP的工作流程通常包括以下几个步骤：

主机A检查自己的ARP表，查看是否已经有主机B的MAC地址。

如果没有，主机A会发送一个ARP请求报文，询问网络中谁拥有主机B的IP地址。

网络中的所有主机都会收到这个ARP请求，但只有主机B会响应，因为它拥有被询问的IP地址。

主机B会发送一个ARP响应报文给主机A，告知自己的MAC地址。

主机A收到响应后，会更新自己的ARP表，并使用主机B的MAC地址来发送数据。

arp

ARP报文结构

ARP请求报文结构

前面 14 个字节构成标准以太网的首部，前两个字段 DST 和 SRC 分别表示 以太网的目的地址 和 以太网的源地址，以太网的目的地址如果是 ff:ff:ff:ff:ff:ff 全部为 1 表示广播地址，在同一广播域中的所有以太网接口可以接收这些帧。后面紧跟着的是 ARP 请求的长度/类型，ARP 请求 和 ARP 应答这个值为 0x0806。

硬件类型表示硬件地址的类型，硬件地址常见的有 MAC 物理或者以太网地址，对于以太网来说，此值为 1。
协议类型 指出映射的协议地址类型，对于 IPv4 地址，这个值是 0x0800。
硬件大小和 协议大小 分别指出硬件地址和协议地址的字节数。对于以太网中使用 IPv4 的 ARP 请求或应答，它们的值分别是 6 和 4。
Op 字段指出如果是 ARP 请求，Op = 1，ARP 应答 ，Op = 2，RARP 请求 Op = 3，RARP 应答，Op = 4。
紧跟在 Op 之后的是 发送方硬件地址(MAC 地址)，发送方的协议地址(IPv4 地址)，目的硬件地址 和 目的协议地址。

实验结果1

要求1-3已经概述过，这里不再赘述。

4.通过对捕获的数据包进行分析，提供证据，说明如何获得以下信息：

1）www.baidu.com 对应的IP地址，有几种方法可以获得该IP地址；

根据文档和前文内容，要通过捕获的数据包分析来获得www.baidu.com对应的IP地址，可以采用以下几种方法：

1. DNS查询

  • 方法：通过DNS（域名系统）查询来获取域名对应的IP地址。
  • 证据：
    • 在Wireshark中抓取的数据包中，查找DNS请求和应答报文。
    • DNS请求报文：在应用层的DNS部分，可以看到客户端发送的DNS查询请求，其中包含域名www.baidu.com。
    • DNS应答报文：在DNS应答报文中，可以看到服务器返回的IP地址。通常，DNS应答报文中的Answer部分会包含域名对应的A记录（IPv4地址）或AAAA记录（IPv6地址）。

2. TCP连接建立过程

  • 方法：通过观察TCP三次握手过程中涉及的IP地址。
  • 证据：
    • 在Wireshark中查找TCP三次握手的过程。
    • 第一次握手（SYN）：客户端发送一个带有SYN标志的TCP报文，目标IP地址为www.baidu.com的IP地址。
    • 第二次握手（SYN+ACK）：服务器回应一个带有SYN和ACK标志的TCP报文，源IP地址即为www.baidu.com的IP地址。
    • 第三次握手（ACK）：客户端发送一个带有ACK标志的TCP报文，确认连接建立，目标IP地址同样为www.baidu.com的IP地址。

3. HTTP请求和响应

  • 方法：通过HTTP请求和响应报文中的IP地址。
  • 证据：
    • 在Wireshark中查找HTTP请求和响应报文。
    • HTTP请求报文：在传输层的TCP头部，可以看到目标IP地址是www.baidu.com的IP地址。
    • HTTP响应报文：在传输层的TCP头部，可以看到源IP地址是www.baidu.com的IP地址。

4. ARP请求和应答

  • 方法：如果在同一局域网内，可以通过ARP请求和应答来获取IP地址对应的MAC地址，从而间接确认IP地址。
  • 证据：
    • 在Wireshark中查找ARP请求和应答报文。
    • ARP请求报文：如果客户端和服务器在同一局域网内，客户端会发送ARP请求以获取www.baidu.com的MAC地址，此时可以看到目标IP地址。
    • ARP应答报文：服务器回应ARP应答报文，其中包含其MAC地址和IP地址。

总结

通过上述方法，可以确定www.baidu.com对应的IP地址。具体步骤如下：

  1. DNS查询：在DNS应答报文中找到www.baidu.com的IP地址。
  2. TCP连接建立：在TCP三次握手的过程中，查看目标IP地址。
  3. HTTP请求和响应：在HTTP请求和响应报文中查看目标IP地址。
  4. ARP请求和应答：在ARP请求和应答报文中查看目标IP地址（适用于同一局域网内的情况）。

2）网关IP地址和MAC地址分别是多少，有几种方法可以获得；

要通过捕获的数据包分析来获得网关的IP地址和MAC地址，可以采用以下几种方法：

1. ARP请求和应答

  • 方法：通过ARP（Address Resolution Protocol）请求和应答报文来获取网关的IP地址和MAC地址。
  • 证据：
    • 在Wireshark中查找ARP请求和应答报文。
    • ARP请求报文：客户端发送ARP请求以获取网关的MAC地址。请求报文中会包含目标IP地址（即网关的IP地址），但目标MAC地址为全0（因为此时还不知道网关的MAC地址）。
    • ARP应答报文：网关回应ARP应答报文，其中包含网关的MAC地址和IP地址。

2. ICMP请求和应答

  • 方法：通过ICMP（Internet Control Message Protocol）请求（如ping）和应答报文来获取网关的IP地址。MAC地址可以通过ARP解析得到。
  • 证据：
    • 在Wireshark中查找ICMP Echo Request（ping请求）和ICMP Echo Reply（ping应答）报文。
    • ICMP Echo Request：客户端发送ICMP Echo Request到网关的IP地址。
    • ICMP Echo Reply：网关回应ICMP Echo Reply，源IP地址即为网关的IP地址。
    • 结合ARP请求和应答报文，可以找到与网关IP地址对应的MAC地址。

3. 路由表

  • 方法：查看本地主机的路由表来获取默认网关的IP地址。MAC地址可以通过ARP解析得到。
  • 证据：
    • 在Windows系统中，可以通过命令ipconfig /all查看默认网关的IP地址。
    • 使用arp -a命令可以查看ARP缓存，找到与网关IP地址对应的MAC地址。

4. TCP连接建立过程

  • 方法：在TCP三次握手过程中，如果客户端和服务器之间的通信需要经过网关，可以通过观察数据包中的IP地址和MAC地址来确定网关的信息。
  • 证据：
    • 在Wireshark中查找TCP三次握手的过程。
    • 第一次握手（SYN）：客户端发送一个带有SYN标志的TCP报文，目标IP地址为服务器的IP地址，但下一跳通常是网关的IP地址。
    • 第二次握手（SYN+ACK）：服务器回应一个带有SYN和ACK标志的TCP报文，源IP地址是服务器的IP地址，但下一跳通常是网关的IP地址。
    • 第三次握手（ACK）：客户端发送一个带有ACK标志的TCP报文，确认连接建立，目标IP地址同样是服务器的IP地址，但下一跳通常是网关的IP地址。
    • 通过这些报文的源/目标MAC地址，可以找到网关的MAC地址。

总结

通过上述方法，可以确定网关的IP地址和MAC地址。具体步骤如下：

  1. ARP请求和应答：在ARP请求和应答报文中找到网关的IP地址和MAC地址。
  2. ICMP请求和应答：在ICMP Echo Request和Echo Reply报文中找到网关的IP地址，并结合ARP解析找到MAC地址。
  3. 路由表：通过命令行工具查看默认网关的IP地址，并通过ARP缓存找到对应的MAC地址。
  4. TCP连接建立过程：在TCP三次握手的过程中，通过观察数据包中的IP地址和MAC地址来确定网关的信息。

3）发送方和接收方TCP协议协商的初始序号？真正发送数据的实际起始序号是多少？为什么？

在TCP连接建立过程中，发送方和接收方会协商初始序列号（Initial Sequence Number, ISN）。这些序列号用于确保数据传输的可靠性和顺序性。以下是关于初始序号和实际发送数据的起始序号的详细解释：

1. 初始序列号 (ISN)

  • 定义：初始序列号是TCP连接中第一个字节的序列号。每个方向的连接都有自己的初始序列号。
  • 生成方式：ISN通常是随机生成的，以提高安全性。现代操作系统通常使用一个复杂的算法来生成ISN，该算法基于时间戳和其他因素，以减少被猜测的风险。
  • 目的：通过使用随机的ISN，可以防止攻击者轻易地猜测序列号并进行重放攻击或注入恶意数据。

2. 真正发送数据的实际起始序号

  • 定义：实际发送数据的起始序号是从ISN开始的下一个可用序列号。在三次握手完成后，客户端和服务器都准备好发送数据。
  • 计算方法：
    • 客户端：客户端在SYN报文中发送ISN，假设为ISN_c。客户端在第三次握手（ACK）后发送的第一个数据段的序列号将是ISN_c + 1。
    • 服务器：服务器在SYN+ACK报文中发送ISN，假设为ISN_s。服务器在接收到客户端的ACK后发送的第一个数据段的序列号将是ISN_s + 1。

3. 为什么会有这样的设置？

  • 可靠性：通过使用ISN，TCP可以确保数据包按正确的顺序到达，并且能够检测到丢失的数据包。如果某个数据包丢失，接收方可以通过序列号请求重新发送。
  • 安全：随机生成的ISN增加了攻击者预测序列号的难度，从而提高了安全性。如果攻击者能够预测序列号，他们可能会插入恶意数据或执行其他攻击。
  • 同步：ISN允许双方在连接建立时同步它们的序列号计数器，从而确保数据传输的一致性和完整性。

示例

假设客户端和服务器之间的TCP连接建立过程如下：

  1. 第一次握手（SYN）：

    • 客户端发送一个带有SYN标志的TCP报文，序列号为ISN_c（例如1000）。
    • 报文格式：SYN, seq=1000

  2. 第二次握手（SYN+ACK）：

    • 服务器回应一个带有SYN和ACK标志的TCP报文，确认收到客户端的SYN，同时发送自己的ISN（例如2000），并且确认号为ISN_c + 1（即1001）。
    • 报文格式：SYN, ACK, seq=2000, ack=1001

  3. 第三次握手（ACK）：

    • 客户端发送一个带有ACK标志的TCP报文，确认收到服务器的SYN，确认号为ISN_s + 1（即2001）。
    • 报文格式：ACK, seq=1001, ack=2001

实际发送数据的起始序号

  • 客户端：在第三次握手后，客户端发送的第一个数据段的序列号将是ISN_c + 1，即1001。
  • 服务器：在接收到客户端的ACK后，服务器发送的第一个数据段的序列号将是ISN_s + 1，即2001。

总结

  • **初始序列号 (ISN)**：由客户端和服务器各自生成，用于确保数据传输的可靠性和安全性。
  • 实际发送数据的起始序号：从ISN加1开始，客户端为ISN_c + 1，服务器为ISN_s + 1。
  • 原因：这种机制确保了数据传输的顺序性和完整性，同时增加了安全性，防止攻击者轻易猜测序列号并进行攻击。

4）HTTP协议协商的版本号是多少？该版本号HTTP协议工作特点是什么？提供证据说明。

在HTTP协议中，版本号是请求行和状态行中的一个重要部分，它指定了使用的HTTP协议的版本。常见的HTTP版本包括HTTP/1.0、HTTP/1.1和HTTP/2。以下是这些版本的特点以及如何通过Wireshark捕获的数据包来确定HTTP协议的版本号。

HTTP 版本号

1. HTTP/1.0
  • 特点：
    • 每个请求都需要建立一个新的TCP连接。
    • 不支持持久连接（Persistent Connections）。
    • 不支持管道化（Pipelining），即客户端必须等待前一个请求的响应才能发送下一个请求。
    • 不支持分块传输编码（Chunked Transfer Encoding）。
    • 不支持虚拟主机（Virtual Hosting）。
2. HTTP/1.1
  • 特点：
    • 支持持久连接（Persistent Connections），默认情况下保持连接打开，直到客户端或服务器关闭连接。
    • 支持管道化（Pipelining），客户端可以连续发送多个请求而不必等待每个请求的响应。
    • 支持分块传输编码（Chunked Transfer Encoding），允许数据以小块的形式传输，不需要事先知道整个消息的长度。
    • 支持虚拟主机（Virtual Hosting），允许多个域名共享同一个IP地址。
    • 引入了更多的请求头和响应头，如Host、Connection等。
3. HTTP/2
  • 特点：
    • 多路复用（Multiplexing），允许多个请求和响应同时在单个TCP连接上进行。
    • 头部压缩（Header Compression），减少传输的头部信息量。
    • 服务器推送（Server Push），服务器可以在客户端请求之前主动推送资源。
    • 二进制格式（Binary Format），使用二进制格式而不是文本格式，提高解析效率。
    • 流控制（Flow Control），允许客户端和服务器对数据流进行更精细的控制。

证据说明

要通过Wireshark捕获的数据包来确定HTTP协议的版本号，可以通过以下步骤：

  1. 启动Wireshark并开始抓包：

    • 打开Wireshark并选择正确的网络接口开始抓包。
    • 在浏览器中访问www.baidu.com或其他网站，直到页面加载完成。
    • 停止抓包。

  2. 查找HTTP请求报文：

    • 在Wireshark的过滤器栏中输入http.request，筛选出HTTP请求报文。
    • 选择一个HTTP请求报文，查看其详细信息。

  3. 检查请求行：

    • 在请求报文中找到请求行（Request Line），通常位于报文的顶部。
    • 请求行的格式为：<Method> <URL> <HTTP-Version>。
    • 例如，GET /index.html HTTP/1.1 表示这是一个HTTP/1.1的GET请求。

  4. 确认版本号：

    • 从请求行中可以直接看到HTTP版本号，例如HTTP/1.1。

示例

假设我们捕获了一个HTTP请求报文，其请求行如下：

1
2
3
4
5
6
7
GET / HTTP/1.1
Host: www.baidu.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

在这个例子中，请求行GET / HTTP/1.1表明该请求使用的是HTTP/1.1版本。

总结

  • HTTP/1.0：每个请求都需要新的TCP连接，不支持持久连接和管道化。
  • HTTP/1.1：支持持久连接、管道化、分块传输编码和虚拟主机。
  • HTTP/2：支持多路复用、头部压缩、服务器推送和二进制格式。

通过Wireshark捕获的数据包，可以从请求行中直接看到HTTP协议的版本号，从而确定使用的HTTP版本及其工作特点。

5）一个TCP连接从建立到释放，总共发送和接收了多少字节数据？为什么？

要确定一个TCP连接从建立到释放过程中总共发送和接收了多少字节数据，可以通过Wireshark抓包工具来分析。以下是如何通过Wireshark获取这些信息的步骤和解释：

1. 使用Wireshark抓包

  • 启动Wireshark：打开Wireshark并选择正确的网络接口开始抓包。
  • 触发TCP连接：在浏览器中访问www.baidu.com或其他网站，直到页面加载完成。
  • 停止抓包：页面加载完成后，停止Wireshark的抓包。

2. 查找TCP连接

  • 过滤TCP连接：在Wireshark的过滤器栏中输入tcp，筛选出所有TCP报文。
  • 找到三次握手：查找三次握手过程（SYN, SYN+ACK, ACK）以确定TCP连接的开始。
  • 找到四次挥手：查找四次挥手过程（FIN, ACK, FIN, ACK）以确定TCP连接的结束。

3. 统计总字节数

  • 统计发送的数据量：

    • 在Wireshark中，可以使用Follow TCP Stream功能来查看整个TCP会话的数据流。
    • 右键点击任意一个属于该TCP连接的报文，选择Follow > TCP Stream。
    • 在弹出的窗口中，可以看到客户端和服务器之间的完整数据交换。
    • Wireshark会显示每个方向上发送的总字节数。

  • 统计接收的数据量：

    • 同样在Follow TCP Stream窗口中，可以看到服务器发送给客户端的数据总量。

4. 计算总字节数

  • 发送的总字节数：在Follow TCP Stream窗口中，查看客户端发送的数据总量。
  • 接收的总字节数：在Follow TCP Stream窗口中，查看服务器发送的数据总量。
  • 总字节数：将发送的总字节数和接收的总字节数相加，得到整个TCP连接期间发送和接收的总字节数。

5. 为什么需要这样计算？

  • 准确性：通过Follow TCP Stream功能，Wireshark能够准确地统计整个TCP连接期间的数据传输量，包括应用层数据和TCP头部数据。
  • 完整性：这种方法确保了统计的数据是完整的，包括所有数据段和重传的数据。
  • 直观性：Follow TCP Stream窗口提供了直观的数据视图，便于理解数据流的方向和内容。

示例

假设我们捕获了一个TCP连接，并且在Follow TCP Stream窗口中看到以下信息：

  • 客户端发送的数据总量：1024字节
  • 服务器发送的数据总量：8192字节

那么，这个TCP连接从建立到释放期间，总共发送和接收的字节数为：

1
2
总字节数 = 客户端发送的数据总量 + 服务器发送的数据总量
总字节数 = 1024 + 8192 = 9216字节

总结

  • 使用Wireshark的Follow TCP Stream功能：可以方便地查看和统计整个TCP连接期间的数据传输量。
  • 计算总字节数：通过统计客户端发送的数据总量和服务器发送的数据总量，然后相加得到总字节数。
  • 准确性与完整性：这种方法确保了数据统计的准确性和完整性。

6）针对一个TCP连接，提供该连接建立三次握手报文段和四次挥手报文段，为什么说该证据是针对一个TCP连接？

要提供一个TCP连接的三次握手和四次挥手的报文段，并解释为什么这些证据是针对同一个TCP连接，我们需要详细分析这些报文段中的关键字段。以下是具体的步骤和示例：

1. 三次握手报文段

第一次握手（SYN）
  • 发送方：客户端
  • 接收方：服务器
  • 报文格式：
    1
    SYN, seq=x
    • seq=x：客户端选择的初始序列号（ISN）。
第二次握手（SYN+ACK）
  • 发送方：服务器
  • 接收方：客户端
  • 报文格式：
    1
    SYN, ACK, seq=y, ack=x+1
    • seq=y：服务器选择的初始序列号（ISN）。
    • ack=x+1：确认客户端的初始序列号加1。
第三次握手（ACK）
  • 发送方：客户端
  • 接收方：服务器
  • 报文格式：
    1
    ACK, seq=x+1, ack=y+1
    • seq=x+1：客户端的下一个序列号。
    • ack=y+1：确认服务器的初始序列号加1。

2. 四次挥手报文段

第一次挥手（FIN）
  • 发送方：客户端或服务器
  • 接收方：对方
  • 报文格式：
    1
    FIN, seq=a
    • seq=a：发送方当前的序列号。
第二次挥手（ACK）
  • 发送方：对方
  • 接收方：发送方
  • 报文格式：
    1
    ACK, seq=b, ack=a+1
    • seq=b：对方当前的序列号。
    • ack=a+1：确认发送方的FIN序列号加1。
第三次挥手（FIN）
  • 发送方：对方
  • 接收方：发送方
  • 报文格式：
    1
    FIN, seq=c
    • seq=c：对方当前的序列号。
第四次挥手（ACK）
  • 发送方：发送方
  • 接收方：对方
  • 报文格式：
    1
    ACK, seq=a+1, ack=c+1
    • seq=a+1：发送方的下一个序列号。
    • ack=c+1：确认对方的FIN序列号加1。

3. 为什么说这些证据是针对一个TCP连接？

以下是一些关键点，可以证明这些报文段是针对同一个TCP连接：

1. 相同的源端口和目的端口
  • 在三次握手和四次挥手中，源端口和目的端口必须一致。例如，如果三次握手中的源端口是12345，目的端口是80，那么在四次挥手中，源端口和目的端口也必须是12345和80。
2. 连续的序列号和确认号
  • 序列号和确认号在三次握手和四次挥手中必须是连续的。例如，在三次握手中，客户端的初始序列号是x，那么在四次挥手中，客户端的序列号应该从x+1开始。
  • 确认号也是如此，服务器在三次握手中确认了客户端的x+1，那么在四次挥手中，服务器的确认号也应该基于这个值。
3. 相同的IP地址
  • 三次握手和四次挥手的IP地址必须一致。即客户端和服务器的IP地址在整个连接过程中保持不变。

示例

假设我们捕获了一个TCP连接的三次握手和四次挥手报文段，具体如下：

三次握手

  1. 第一次握手（SYN）

    1
    2
    3
    4
    5
    源IP: 192.168.1.10
    目的IP: 192.168.1.1
    源端口: 12345
    目的端口: 80
    SYN, seq=1000

  2. 第二次握手（SYN+ACK）

    1
    2
    3
    4
    5
    源IP: 192.168.1.1
    目的IP: 192.168.1.10
    源端口: 80
    目的端口: 12345
    SYN, ACK, seq=2000, ack=1001

  3. 第三次握手（ACK）

    1
    2
    3
    4
    5
    源IP: 192.168.1.10
    目的IP: 192.168.1.1
    源端口: 12345
    目的端口: 80
    ACK, seq=1001, ack=2001
四次挥手

  1. 第一次挥手（FIN）

    1
    2
    3
    4
    5
    源IP: 192.168.1.10
    目的IP: 192.168.1.1
    源端口: 12345
    目的端口: 80
    FIN, seq=1001

  2. 第二次挥手（ACK）

    1
    2
    3
    4
    5
    源IP: 192.168.1.1
    目的IP: 192.168.1.10
    源端口: 80
    目的端口: 12345
    ACK, seq=2001, ack=1002

  3. 第三次挥手（FIN）

    1
    2
    3
    4
    5
    源IP: 192.168.1.1
    目的IP: 192.168.1.10
    源端口: 80
    目的端口: 12345
    FIN, seq=2001

  4. 第四次挥手（ACK）

    1
    2
    3
    4
    5
    源IP: 192.168.1.10
    目的IP: 192.168.1.1
    源端口: 12345
    目的端口: 80
    ACK, seq=1002, ack=2002

为什么这些证据是针对同一个TCP连接？

  1. 相同的源端口和目的端口：

    • 三次握手和四次挥手中的源端口和目的端口都是12345和80。

  2. 连续的序列号和确认号：

    • 三次握手中的初始序列号是1000和2000，四次挥手中的序列号是从1001和2001开始的，确认号也是连续的。

  3. 相同的IP地址：

    • 三次握手和四次挥手的IP地址都是192.168.1.10和192.168.1.1。

通过这些关键点，我们可以确定这些报文段是针对同一个TCP连接的。

层次 数据链路层 (以太网帧) 网络层 (IP) 传输层 (TCP) 应用层 (HTTP)
目标MAC地址 6字节 （） （） （）
源MAC地址 6字节 （） （） （）
以太类型/长度 2字节 （） （） （）
数据部分 可变 （） （） （）
校验和 4字节 （） （） （）
版本 （） 4位 （） （）
头部长度 （） 4位 （） （）
服务类型 （） 8位 （） （）
总长度 （） 16位 （） （）
标识 （） 16位 （） （）
标志 （） 3位 （） （）
分片偏移 （） 13位 （） （）
生存时间 （） 8位 （） （）
协议 （） 8位 （） （）
头部校验和 （） 16位 （） （）
源IP地址 （） 32位 （） （）
目的IP地址 （） 32位 （） （）
选项 （） 可变 （） （）
填充 （） 可变 （） （）
源端口 （） （） 16位 （）
目的端口 （） （） 16位 （）
序列号 （） （） 32位 （）
确认号 （） （） 32位 （）
数据偏移 （） （） 4位 （）
保留 （） （） 6位 （）
控制位 （） （） 6位 （）
窗口大小 （） （） 16位 （）
校验和 （） （） 16位 （）
紧急指针 （） （） 16位 （）
选项 （） （） 可变 （）
填充 （） （） 可变 （）
数据部分 （） （） 可变 （）
请求行 （） （） （） 请求方法、请求URI 和 HTTP版本
请求头 （） （） （） 多个键值对，每个键值对占一行，以冒号分隔
空行 （） （） （） 请求头与请求体之间的空行
请求体 （） （） （） 可选，包含客户端发送给服务器的数据

（6）从应用层到数据链路层有哪些校验字段，分别采用什么方法计算校验码，其校验范围分别是什么，不同层重复的校验是多余的吗？为什么？

从应用层到数据链路层，每一层都有其特定的校验字段和校验方法。这些校验字段用于确保数据在传输过程中的完整性和正确性。以下是各层的校验字段、校验方法及其校验范围，并讨论不同层重复的校验是否多余。

1. 应用层 (HTTP)

  • 校验字段：无
  • 校验方法：HTTP协议本身没有内置的校验字段。数据的完整性通常依赖于下层协议（如TCP）提供的校验机制。
  • 校验范围：无

2. 传输层 (TCP)

  • 校验字段：校验和 (Checksum)
  • 校验方法：TCP校验和是通过计算整个TCP报文段（包括头部和数据部分）的16位补码和来生成的。具体步骤如下：
    1. 将TCP报文段分为多个16位的字。
    2. 对所有16位字进行求和。
    3. 如果结果超过16位，则将高16位加到低16位上。
    4. 取该和的16位补码作为校验和。
  • 校验范围：整个TCP报文段（包括头部和数据部分）

3. 网络层 (IP)

  • 校验字段：头部校验和 (Header Checksum)
  • 校验方法：IP头部校验和是通过计算IP头部的16位补码和来生成的。具体步骤如下：
    1. 将IP头部分为多个16位的字。
    2. 对所有16位字进行求和。
    3. 如果结果超过16位，则将高16位加到低16位上。
    4. 取该和的16位补码作为头部校验和。
  • 校验范围：仅IP头部

4. 数据链路层 (以太网)

  • 校验字段：帧校验序列 (FCS, Frame Check Sequence)
  • 校验方法：以太网帧使用CRC-32（循环冗余校验）来生成FCS。具体步骤如下：
    1. 使用生成多项式对整个以太网帧（不包括FCS字段）进行CRC-32计算。
    2. 计算结果作为FCS附加在帧尾部。
  • 校验范围：整个以太网帧（包括头部和数据部分，但不包括FCS字段）

不同层重复的校验是否多余？

不同层的校验并不是多余的，每层的校验都有其特定的目的和作用：

  1. **应用层 (HTTP)**：

    • HTTP本身没有校验字段，但可以通过下层协议（如TCP）提供的校验机制来保证数据的完整性。

  2. **传输层 (TCP)**：

    • TCP校验和确保了整个TCP报文段的完整性，包括头部和数据部分。这可以检测到数据在传输过程中可能发生的错误。

  3. **网络层 (IP)**：

    • IP头部校验和只检查IP头部的完整性，不包括数据部分。这是因为在IP层，数据部分可能会被分片或重组，因此单独校验头部可以确保头部信息的正确性。

  4. **数据链路层 (以太网)**：

    • 以太网帧的FCS确保了整个帧的完整性，包括头部和数据部分。这是因为在局域网内，数据可能会受到物理层干扰，FCS可以检测到这些错误。

为什么不同层的校验不是多余的？

  • 独立性：每一层的校验都是独立的，各自负责不同的数据范围。例如，IP头部校验和只检查IP头部，而TCP校验和检查整个TCP报文段。
  • 分层设计：网络协议采用分层设计，每一层都有其特定的功能和责任。不同层的校验确保了每一层的数据完整性，从而提高了整体的可靠性。
  • 故障隔离：不同层的校验可以帮助快速定位问题。例如，如果TCP校验失败，可以确定问题出在传输层；如果IP头部校验失败，可以确定问题出在网络层。
  • 冗余与安全性：多层校验提供了额外的安全性和冗余，即使某一层的校验失败，其他层的校验仍然可以提供一定程度的保护。

综上所述，不同层的校验虽然看起来有重叠，但实际上它们各自负责不同的数据范围和功能，共同确保了数据在传输过程中的完整性和正确性。

（7）如果在本次实验过程，对抓取的报文进行分析，发现DNS和ARP协议没有工作，为什么？如何解决该问题？在解决该问题过程中用到两个网络命令，分别是什么，写出这两个命令具体应用。

如果在实验过程中发现DNS和ARP协议没有工作，这可能意味着网络配置或网络设备存在问题。以下是一些可能的原因以及如何解决这些问题的步骤，包括使用两个网络命令来诊断和解决问题。

可能的原因

  1. 网络连接问题：

    • 网络接口可能未正确配置或未连接。
    • 网络设备（如路由器、交换机）可能存在故障。

  2. DNS服务器配置问题：

    • 本地DNS服务器地址可能未正确配置。
    • DNS服务器可能不可达或无响应。

  3. ARP缓存问题：

    • ARP缓存可能已损坏或未正确更新。
    • 局域网内的设备可能未正确响应ARP请求。

解决步骤

  1. 检查网络连接：

    • 确保网络接口已启用并正确连接。
    • 检查物理连接（网线、交换机端口等）是否正常。

  2. 检查DNS配置：

    • 确认本地DNS服务器地址是否正确配置。
    • 尝试使用不同的DNS服务器地址。

  3. 检查ARP缓存：

    • 清除ARP缓存并重新生成。
    • 确认局域网内的设备能够响应ARP请求。

使用的网络命令

1. ipconfig /all (Windows) 或 ifconfig (Linux/Mac)
  • 用途：显示当前网络接口的详细配置信息，包括IP地址、子网掩码、默认网关和DNS服务器地址。
  • 具体应用：

    • Windows:

      1
      ipconfig /all
      • 查看输出中的“DNS Servers”部分，确认DNS服务器地址是否正确。
      • 查看“IPv4 Address”和“Default Gateway”部分，确认IP地址和网关是否正确配置。

    • Linux/Mac:

      1
      ifconfig
      • 查看输出中的inet字段，确认IP地址和子网掩码。
      • 查看route -n命令的输出，确认默认网关。
2. nslookup 或 ping
  • 用途：
    • nslookup：用于查询DNS服务器，检查域名解析是否正常。
    • ping：用于测试网络连通性，检查目标主机是否可达。
  • 具体应用：

    • nslookup:

      1
      nslookup www.baidu.com
      • 如果返回正确的IP地址，说明DNS解析正常。
      • 如果返回错误信息，说明DNS服务器可能有问题。

    • ping:

      1
      ping www.baidu.com
      • 如果返回ICMP Echo Reply，说明目标主机可达。
      • 如果返回“Request timed out”或“Destination host unreachable”，说明网络连接或目标主机存在问题。

诊断和解决步骤

  1. 检查网络接口配置：

    • 在Windows上运行ipconfig /all，在Linux/Mac上运行ifconfig，确认IP地址、子网掩码、默认网关和DNS服务器地址是否正确配置。
    • 如果配置不正确，手动修改或通过DHCP获取正确的配置。

  2. 检查DNS服务器：

    • 运行nslookup www.baidu.com，查看是否能正确解析域名。
    • 如果无法解析，尝试更换DNS服务器地址。例如，在Windows上可以修改DNS服务器地址：
      1
      2
      netsh interface ipv4 set dns "以太网" static 8.8.8.8
      netsh interface ipv4 add dns "以太网" 8.8.4.4 index=2

  3. 检查ARP缓存：

    • 清除ARP缓存并重新生成：
      • Windows:
        1
        arp -d *
      • Linux/Mac:
        1
        sudo arp -a -d
    • 重新进行网络通信，观察ARP缓存是否正确更新。

  4. 检查网络连通性：

    • 使用ping命令测试与目标主机的连通性：
      1
      ping www.baidu.com
    • 如果ping失败，检查物理连接和网络设备状态。

通过上述步骤，可以诊断并解决DNS和ARP协议未工作的问题。

（8）如果在本次实验过程，用户在客户端DOS>ping www.baidu.com,连续发送了三次ICMP ECHO请求报文，但显示第一次接收ICMP ECHO应答报文超时，说明网络不通；但后面两次ICMP ECHO应答报文接收正常，又说明网络是连通的，为什么？

在实验过程中，用户在客户端使用ping www.baidu.com命令连续发送了三次ICMP ECHO请求报文，但第一次接收ICMP ECHO应答报文超时，而后面两次ICMP ECHO应答报文接收正常。这种情况可能有多种原因，以下是一些可能的解释和解决方法：

可能的原因

  1. 网络延迟或拥塞：

    • 第一次ICMP请求可能在网络中遇到了较高的延迟或拥塞，导致响应超时。
    • 后续的ICMP请求可能在网络状况改善后成功传输并收到了响应。

  2. DNS解析问题：

    • 第一次ICMP请求可能由于DNS解析问题导致超时。如果DNS服务器响应较慢或暂时不可达，可能会导致第一次请求超时。
    • 后续的ICMP请求可能使用了缓存的IP地址，因此能够快速响应。

  3. ARP缓存问题：

    • 第一次ICMP请求可能由于ARP缓存未更新或ARP请求未收到响应而导致超时。
    • 后续的ICMP请求可能已经更新了ARP缓存，因此能够成功发送和接收。

  4. 防火墙或安全设备：

    • 网络中的防火墙或其他安全设备可能对第一次ICMP请求进行了更严格的检查，导致响应延迟或被丢弃。
    • 后续的ICMP请求可能通过了这些安全检查，因此能够成功传输。

  5. 路由问题：

    • 第一次ICMP请求可能由于路由表未更新或路由路径不稳定导致超时。
    • 后续的ICMP请求可能使用了更新后的路由表或稳定的路由路径，因此能够成功传输。

解决步骤

  1. 检查网络延迟和拥塞：

    • 使用ping命令增加发送次数，观察是否有多次超时的情况。
    • 使用tracert（Windows）或traceroute（Linux/Mac）命令查看数据包在网络中的传输路径，找出可能的瓶颈或延迟点。
      1
      2
      tracert www.baidu.com
      traceroute www.baidu.com

  2. 检查DNS解析：

    • 使用nslookup命令检查DNS解析是否正常。
      1
      nslookup www.baidu.com
    • 如果DNS解析有问题，尝试更换DNS服务器地址。
      1
      2
      netsh interface ipv4 set dns "以太网" static 8.8.8.8
      netsh interface ipv4 add dns "以太网" 8.8.4.4 index=2

  3. 检查ARP缓存：

    • 清除ARP缓存并重新生成。
      • Windows:
        1
        arp -d *
      • Linux/Mac:
        1
        sudo arp -a -d
    • 重新进行ping测试，观察是否还有超时情况。

  4. 检查防火墙和安全设备：

    • 检查本地防火墙设置，确保ICMP请求和响应没有被阻止。
    • 检查网络中的其他安全设备（如路由器、交换机上的防火墙），确保它们没有阻止ICMP流量。

  5. 检查路由表：

    • 使用route print（Windows）或netstat -rn（Linux/Mac）命令查看当前的路由表。
      1
      2
      route print
      netstat -rn
    • 确认默认网关和其他路由条目是否正确配置。

示例

假设你在Windows上执行了以下命令：

1
ping www.baidu.com -n 3

输出如下：

1
2
3
4
5
6
7
8
9
Pinging www.a.shifen.com [14.215.177.38] with 32 bytes of data:
Request timed out.
Reply from 14.215.177.38: bytes=32 time=10ms TTL=56
Reply from 14.215.177.38: bytes=32 time=10ms TTL=56

Ping statistics for 14.215.177.38:
    Packets: Sent = 3, Received = 2, Lost = 1 (33% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 10ms, Average = 10ms

分析

  • 第一次请求超时：可能是由于网络延迟、DNS解析问题、ARP缓存问题、防火墙或路由问题。
  • 后续请求正常：说明网络连接在后续请求时是正常的，可能是因为网络状况改善、DNS缓存生效、ARP缓存更新或安全设备放行。

总结

这种情况下，网络可能在第一次请求时存在一些临时性的问题，但在后续请求时恢复正常。通过上述步骤，可以诊断并解决这些问题。

实验内容2: 网络广播报文发送

实验目标：

  • 编写程序实现三层广播报文的发送。
  • 使用抓包工具捕获广播报文，分析其头部信息。

实验内容：

  • 编写程序发送广播报文。
  • 利用抓包工具捕获这些广播报文，并分析报文头部信息，特别是五元组（源IP地址、目的IP地址、源端口、目的端口、协议类型）和数据帧头信息。

实验要求：

  • 从捕获的报文中筛选出源IP等于发送方IP地址的报文。
  • 分析广播报文传输层采用的协议（UDP/TCP），并解释为什么广播或组播通常不使用TCP。
  • 比较广播报文与单播UDP用户数据报在目的IP地址、源IP地址、协议类型、目的MAC地址、源MAC地址等方面的差异。

二层广播(帧广播)和三层广播(路由器广播)有什么区别？

提交内容：

  • 源代码、可执行代码及实验报告，需在下次课前提交至指定邮箱。

助教检查点：

  • 抓取发送的第一个广播报文，分析其中的五元组信息和数据帧头部信息。

此实验旨在让学生通过实践加深对网络协议的理解，尤其是对DNS、HTTP、TCP、UDP等常见协议的工作原理有更直观的认识。同时，通过编程实践，学生能够掌握如何发送广播报文及其在网络中的传播特性。

1. 从抓取的报文中过滤出源IP = 发送方IP地址的某一个报文

手动过滤
  • 在抓包工具（如Wireshark）中，可以手动浏览每个报文，查找源IP地址为发送方IP地址的报文。
使用过滤器
  • 在Wireshark中，可以使用显示过滤器来快速过滤出特定源IP地址的报文。例如，如果发送方IP地址是192.168.2.2，可以在过滤器栏中输入：
    1
    ip.src == 192.168.2.2

2. 分析广播报文传输层采用UDP/TCP，理解广播或者组播为什么不是TCP

广播报文传输层协议
  • 广播报文：通常采用UDP协议。
  • 组播报文：也通常采用UDP协议。
为什么广播或组播不是TCP
  • 连接建立：TCP是面向连接的协议，需要在数据传输前建立连接。而广播和组播不需要与每个接收者单独建立连接。
  • 可靠性：TCP提供可靠的数据传输，但广播和组播的目的是将数据发送给多个接收者，不保证每个接收者都能接收到数据。如果使用TCP，会增加网络开销，因为每个接收者都需要进行确认。
  • 效率：广播和组播的目的是高效地将数据发送给多个接收者。TCP的确认机制会导致大量的确认消息在网络中传输，增加了网络负载。
  • 延迟：TCP的三次握手和重传机制会导致较高的延迟，不适合广播和组播这种实时性要求较高的场景。

3. 抓取发送的广播报文，找出通信的五元组信息和数据帧首部信息，分析目的IP地址、源IP地址、协议类型、目的MAC地址、源MAC地址等与单播UDP用户数据报的不同

五元组信息
  • 源IP地址：发送方的IP地址。
  • 目的IP地址：广播地址（通常是255.255.255.255或子网广播地址）。
  • 源端口：发送方的端口号。
  • 目的端口：广播或组播的目的端口号。
  • 协议类型：通常是UDP。
数据帧首部信息
  • 目的MAC地址：对于广播，目的MAC地址通常是FF:FF:FF:FF:FF:FF；对于组播，目的MAC地址是一个特殊的组播MAC地址。
  • 源MAC地址：发送方的MAC地址。
  • 以太网类型：0x0800（表示IP协议）。
与单播UDP用户数据报的不同

  • 目的IP地址：

    • 单播：具体的单个IP地址。
    • 广播/组播：广播地址（如255.255.255.255）或组播地址（如224.0.0.1）。

  • 目的MAC地址：

    • 单播：具体的单个MAC地址。
    • 广播：FF:FF:FF:FF:FF:FF。
    • 组播：一个特殊的组播MAC地址，由组播IP地址映射而来。

  • 协议类型：

    • 单播：通常是UDP或TCP。
    • 广播/组播：通常是UDP。

  • 源IP地址和源MAC地址：

    • 单播：发送方的具体IP地址和MAC地址。
    • 广播/组播：发送方的具体IP地址和MAC地址。

示例

假设您抓取到以下广播报文：

  • 源IP地址：192.168.2.2
  • 目的IP地址：255.255.255.255
  • 源端口：12345
  • 目的端口：54321
  • 协议类型：UDP
  • 目的MAC地址：FF:FF:FF:FF:FF:FF
  • 源MAC地址：00:1A:2B:3C:4D:5E
  • 以太网类型：0x0800
分析
  • 目的IP地址：广播地址255.255.255.255，表示该报文将被发送到局域网内的所有主机。
  • 目的MAC地址：FF:FF:FF:FF:FF:FF，表示该报文将被发送到局域网内的所有设备。
  • 协议类型：UDP，适合广播和组播，因为它不需要建立连接且没有确认机制。
  • 源IP地址和源MAC地址：发送方的具体IP地址和MAC地址，用于标识报文的来源。

通过这些信息，可以清楚地看到广播报文与单播UDP用户数据报在目的地址和协议选择上的不同。

根据文档内容，实验总结部分可以围绕两个主要实验内容进行：网络协议分析与验证以及三层广播报文发送。以下是基于实验内容的总结草稿：

实验总结

1. 网络协议分析与验证

通过本次实验，我们深入理解了WEB服务系统的原理，特别是DNS、HTTP协议的工作机制以及TCP连接建立和断开的过程。具体收获包括：

  • DNS域名解析：学习了如何使用Wireshark捕获并分析DNS请求与响应报文，掌握了获取特定网站IP地址的方法。
  • TCP连接管理：通过观察三次握手（SYN, SYN+ACK, ACK）和四次挥手（FIN, ACK, FIN, ACK）过程，熟悉了TCP连接的建立和关闭机制。
  • ARP协议工作原理：了解了ARP请求和应答报文结构，以及ARP缓存更新的过程。
  • 数据链路层分析：研究了以太网帧格式及其校验字段，进一步理解了不同层级间的数据传输机制。
  • 问题解决能力提升：面对DNS和ARP协议未正常工作的情况时，能够运用ipconfig/ifconfig及nslookup等命令排查问题，并采取相应措施解决。

2. 三层广播报文发送

在该部分实验中，我们编写了程序实现三层广播报文的发送，并利用Wireshark工具对其进行了捕获与分析。主要内容有：

  • 广播报文编程实践：成功实现了UDP套接字的创建、配置为支持广播模式，并向指定子网内的所有主机发送了广播消息。
  • 抓包分析技能：通过筛选出具有特定源IP地址的报文，学会了识别广播报文的关键特征，如目的IP地址设置为全1的广播地址、目的MAC地址为FF:FF:FF:FF:FF:FF等。
  • 比较单播与广播/组播：明确了广播或组播通常选择UDP而非TCP的原因，认识到TCP面向连接的特性不适合于高效地向多个接收者分发信息。

总结

此次实验不仅加深了对计算机网络各层次协议的理解，还增强了实际操作能力和问题解决技巧。通过对真实网络通信过程的观察与分析，我们更直观地感受到了理论知识在现实中的应用价值。此外，也认识到了网络环境复杂性所带来的挑战，比如需要灵活应对各种异常情况，这要求我们在未来的学习工作中更加注重实践经验和细节处理能力的培养。

Comments