任务导向计网学习

发表于 更新于 分类于 ， 阅读次数： 本文字数： 11k 阅读时长 ≈ 35 分钟

一、环境搭建

  1. 资源下载

    eve-ng 懒人版镜像文件在eve-ng懒人社区下载，记住要下载其客户端窗口
    vm或其他虚拟机软件部署

  2. 网络配置

二、网络设备以及配置知识

网络设备知识

1
2
3
4
5
华为：
	1.路由器：AR系列（save）
	2.交换机：CE系列（commit）
	3.防火墙：

基础实验一

0. 任务导向

知识要点：

  1. 路由器的ip配置
  2. 路由配置

1.设备静态ip配置

思科设备：

补充ip接口查看：

注意：

  1. 255.255.255.0 可以使用 24 代替
  2. show ip interface GigabitEthernet0/0 查看结果包括子网掩码

华山设备：

华为设备：

删除ip接口信息：

  1. 进入要删除的ip接口-> undo ip address -> 这个接口的所有ip信息被删除
  2. 进入要删除的ip接口-> undo ip address [ip] [mask] -> 接口的指定ip信息被删除

2.静态路由配置

目的：实现vIOS->HUSG600V

正向路由：

对vIOS

对vIOS2 的静态路由配置一样，只是传递的路由ip不同

值得注意的是H3CvSR是不需要配置路由的，因为其与目标设备是直连的。

回程路由：

对H3CvSR:

对于HUSG600V

理论上此时vIOS 可以 ping HUSG600V ， 都是忽略了防火墙是🈲ping的。

解决：需要配置防火墙的信任域

1
2
3
4
 华为防火墙默认策略：
同区域流量默认允许（如 trust → trust）
跨区域流量默认拒绝（如 untrust → trust）
所有流量默认拒绝（除非明确配置策略）

g1/0/0设置在信任任区：

1
2
3
4
5
HUSG600V指令：
进入防火墙信任域：
	firewall zone trust  # 查看信任域的详细配置（含绑定接口、优先级）
	display zone # 查看所有安全区域的简要信息（对比其他区域）
查看信任域： display zone trust

指令总结：

1
2
删除指令 ： undo 原有指令
实用查看指令：display this

基础实验二

0.任务导向

账号：AR1000vN（N：数字）
密码 qwer1234KK. 或 qwer1234KK 或 12345678KK
华为回退：ctrl+h

知识要点：

  1. NAT映射
  2. 路由直连

问题：

  1. vpc1怎么将数据包给AR1000v4？
  2. AR1000v4怎么将数据包给vpc2或vpc3？
  3. vpc2或vpc3怎么回复vpc1?

1.普通路由

对链路vpc1<—>vpc2：

（1）正向：

vpc的静态ip配置格式：ip <IP地址> <子网掩码> [<默认网关>]

这里的0.0.0.0并不代表有效的网关，实际效果等同于 “未配置可用网关”。此时 VPC 只能与同一子网内的设备通信（如192.168.1.x网段），无法访问其他子网

设置网关：

vpc1将包发给AR1000v4,需设置ARC1000v4到vpc2,vpc3的路由
静态路由格式：ip route-static <目的网段> <前缀长度> <下一跳IP地址>

对AR1000v:

对AR1000v6:

发现AR1000v6是有192.168.2.2的路由的（因为是直连）

（2）反向：

对AR1000v6:

同理：AR1000v4不需要配置vpc1的静态路由

vpc1:成功ping通

抓取vpc1-eth0：

抓取AR1000v4-g0/0/0：

抓取AR1000v4-g0/0/1：

2.NAT映射

对链路vpc1<—>vpc2 :

假设：有AR1000v4的权限，没有AR1000v5的权限，即无法配置其静态路由。由直连路由知识可知，AR1000v4与AR1000v5 AR1000V5与vpc2 由静态路由 。
所以，只要将vpc1的静态ip映射为AR1000v4与AR1000v5连接的接口的静态ip（10.2.2.1）,就可以实现数据传输

只需操作AR1000v4:

  1. 什么样的数据包需要做网络地址转换？(192.168.1.1/24)

配置AR1000v4到vpc2的路由：

[Huawei]ip route-static 192.168.3.0 24 10.2.2.2

此时，不需要对AR1000v5配置vpc1的路由，这是最重要的区别

实现NAT映射：

抓取vpc1-eth0：

抓取AR1000v4-g0/0/0：

抓取AR1000v4-g0/0/1：

基础实验三

0.任务导向

知识要点：

  1. 交换机配置（多vlan局域网配置，安全策略，跨网段路由配置）
  2. vlan间的可控互通（vlanif:vlan网关）
  3. acl：访问控制限制
  4. NAT的映射形式与端口映射

账号：AR1000vN（N：数字）
密码：qwer1234KK. 或 qwer1234KK 或 12345678KK
华为回退：ctrl+h

1.配置vlan

1
2
3
4
5
6
7
vlan：虚拟局域网，隔离广播，隔离故障
vlan接口类型：
	1.Access 接口主要用于连接终端设备，如计算机、打印机等。它属于某个特定的 VLAN，并且只能属于一个 VLAN 
	2.Trunk 接口主要用于交换机之间、交换机与路由器或三层交换机之间的互联链路。它可以允许多个 VLAN 的数据通过，从而实现不同交换机上相同 VLAN 之间的通信
	3.Hybrid 接口是一种比较灵活的接口类型，既可以连接终端设备，也可以用于交换机之间的互联 。它可以允许多个 VLAN 的数据通过，并且可以灵活地设置哪些 VLAN 的数据在转发时携带标签，哪些不携带标签

配置vlan:

查看vlan方式1：

查看vlan方式2:

特别注意：在用户视图中使用save保存配置

2.配置vlan接口

对三台vpc配置静态ip与网关后测试联通：

但是，配置CE6800-CE1的外接口的静态ip时出现问题：

原因：交换机的接口默认是交换模式，不可以直接配置静态ip，需要创建vlan，在vlan上配置静态ip

这里的 port link-type trunk 有个坑,下面会讲

小知识： 删除vlan前必须删除其关联的接口

3.配置路由

  1. CE6800-CE1路由

目标：让不同 VLAN 和外网互通

由于CE6800-CE1是三级交换机，整个大的局域网的数据包经过它在转发给路由器，整个局域网中的网络设备访问的公网地址很多，不可能都一一配置路由

  1. AR1000v5路由

目标：让不同 VLAN 和外网互通

  • 配置默认路由

正向： 指向AR1000v6 （三大运营商公司）

回程： 指向交换机CE6800-CE1

  • NAT映射

误区： AR1000v4使用NAT映射不代表AR1000v4就不需要设置回程路由

4.启动Proxy ARP

  1. 什么是ARP？

    ARP（Address Resolution Protocol，地址解析协议）的作用：将IP地址解析为MAC地址

1
2
3
4
5
6
7
8
9
10
11
主机A (IP: 192.168.1.10) 想要与 主机B (IP: 192.168.1.20) 通信

1. 主机A查看自己的ARP缓存表
2. 如果没有主机B的MAC地址，主机A广播发送ARP请求：
   "谁是192.168.1.20？请告诉你的MAC地址"

3. 局域网内所有主机都收到这个广播
4. 主机B识别到自己的IP，单播回复：
   "我是192.168.1.20，我的MAC是xx:xx:xx:xx:xx:xx"

5. 主机A将这条映射记录存入ARP缓存表
  1. 什么是Proxy ARP

    Proxy ARP（代理ARP） 是一种网络技术，允许一台设备（通常是路由器或防火墙）代表另一台设备响应ARP请求。
    它不是“标准ARP”，而是在特殊场景下“代答ARP”的机制。

1
2
3
4
设备A（192.168.10.2）想ping 192.168.10.3					设备A直接在本地广播ARP请求，设备B（192.168.10.3）回应自己的MAC地址		❌ 不需要Proxy ARP
设备A（192.168.10.2）想ping 192.168.20.3（不同网段）			设备A将包发给默认网关（CE6800-CE1），CE6800-CE1再转发				❌ 不需要Proxy ARP
设备A（192.168.10.2）想ping 10.1.1.1（AR1000v5的接口IP）	CE6800-CE1需要知道AR1000v5的MAC地址，但AR1000v5默认不响应ARP请求		✅需要Proxy ARP！

  1. 启动华为设备ARP代理（AR1000v5）

ARP 表中没有 10.1.1.2 ✅正常现象 这正是VPC8 无法 ping 通 10.1.1.1 的根本原因！

启动：

没有变化，难道是没有生效？
Proxy ARP 是实时响应 ARP 请求，不会在 ARP 表中添加新条目

此时vpc8还是无法ping通10.1.1.1，这是为什么？

根本原因：AR1000v5 和 CE6800-CE1 之间的接口 VLAN 配置不一致，导致二层通信失败。

设备 接口 当前 VLAN 配置 问题
CE6800-CE1 GigabitEthernet1/0/3 port link-type trunk + port trunk allow-pass vlan 40 发送带 VLAN 40 Tag 的帧
AR1000v5 GigabitEthernet0/0/0 port link-type access + port default vlan 1（默认） 丢弃带 VLAN 40 Tag 的帧

重新设置CE6800-CE1的g1/0/3接口类型

成功ping通(别忘记,此时的AR1000v5的g0/0/0接口启动ARP代理)

  1. AR1000v6路由
  • 处理回包
  • 联通linux服务1

在真实网络中，你不能把 8.8.8.8 当下一跳！
但在 EVE-NG 模拟环境 中，你可以这样配置，因为系统会自动处理回包。
✅ 这是模拟互联网的“作弊技巧” —— 没有它，ping 8.8.8.8 无法通！

5.linux网络配置

  1. 网卡信息分析
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

解释：
	1： -> 接口序号（内核分配）
	lo：-> 接口名称
	<LOOPBACK,UP,LOWER_UP> -> 接口标志
		LOOPBACK：回环接口
		up：接口已启用
		LOWER_UP：物理层正常（虽然回环没有物理层，但系统认为它“UP”）
	mtu 65536 -> 最大传输单元（MTU），回环接口默认很大
	qdisc noqueue -> 队列调度器类型（回环接口不需要排队）
	state UNKNOWN → 接口状态（回环接口通常显示为 UNKNOWN）
	group default → 接口组（默认组）
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
		link/loopback → 链路类型（回环）
		00:00:00:00:00:00 → MAC 地址（回环接口没有真实 MAC，所以是全 0）
		brd 00:00:00:00:00:00 → 广播地址（回环没有广播）
	inet 127.0.0.1/8 scope host lo
		inet → IPv4 地址
		127.0.0.1/8 → IP 地址 + 子网掩码（/8 表示 255.0.0.0）
		scope host → 地址范围（只在本机有效）
		lo → 所属接口名
	valid_lft forever preferred_lft forever
		valid_lft → 地址有效期（forever = 永久）
		preferred_lft → 首选有效期（forever = 永久）
	inet6 ::1/128 scope host
		inet6 → IPv6 地址
		::1/128 → IPv6 回环地址
		scope host → 范围（本机）
	valid_lft forever preferred_lft forever （同上）



2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:50:00:00:0b:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::250:ff:fe00:b00/64 scope link 
       valid_lft forever preferred_lft forever

解释：
	ens3: → 接口名称（这是你的实际网卡！）
	<BROADCAST,MULTICAST,UP,LOWER_UP>
		BROADCAST = 支持广播
		MULTICAST = 支持组播
	qdisc pfifo_fast → 队列调度器（先进先出）

	等等......

重要：ens3网卡已经启用，但是没有inet ,即没有ipv4地址

永久配置：

nano /etc/network/interfaces （vim等）
重启网卡服务：systemctl restart systemd-networkd

ctrl+o 保存 -> 回车确认 -> ctrl+x 退出

由于实验中的linux服务器是Slax轻量版，不会存储文件，为了方便实验的进行，使用vpc代替，如图：

测试NAT普通映射情况

  1. vpc8<–>vpc9
  1. vpc8<–>AR1000v5-g0/0/0

6.服务器的端口映射

  1. 一一对应的NAT映射

nat server global 64.1.1.2 inside 192.168.30.3 （华为设备的指令）

nat server：这是命令关键字，用于启动配置 NAT Server 功能，用来建立公网地址和私网地址之间的映射关系，使外部网络能访问内部网络的特定服务器

global：是一个关键字，表明后续跟的是公网侧的相关信息。

inside：也是一个关键字，用于标识后面跟随的是内网侧的相关信息。

剩下的为公网ip 与 私网ip

  1. 端口映射

nat server protocol { tcp | udp } global { 公网IP 公网端口 } inside { 内网IP 内网端口 }
nat server protocol { tcp | udp } global { current 公网端口 } inside { 内网IP 内网端口 }

对AR1000v5:

nat server protocol tcp global current 8080 inside 192.168.30.3 80

比如公司购买了一个公网ip，且公司有很多服务器设备，不可能每个服务器设备都购买一个公网ip，这样成本很高。接口绑定一个公网ip,而一个接口有多个端口，通过端口映射，实现一个公网ip就可以使外网设备访问内网的对应主机

8.8.8.8外网主机测试连接：

抓包验证：

  1. 对AR1000v5-g0/0/1接口抓包
  1. 对192.168.30.3抓包

流量是从NAT server转发，验证成功

基础实验四

0.windows网络配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
1.查看所有网络适配器详细信息：ipconfig /all
2.查看路由表：route print
3.查看网络连接状态：netstat -ano  # 显示所有 TCP/UDP 连接及进程 ID

4.静态 IP 配置：
	# 1. 查看网卡名称（需替换为实际名称，如“以太网”“WLAN”）
	netsh interface show interface  
	
	# 2. 设置静态 IP + 子网掩码 + 网关
	netsh interface ipv4 set address name="以太网" source=static addr=192.168.1.100 mask=255.255.255.0 gateway=192.168.1.1 gwmetric=1  
	
	# 3. 切换为 DHCP 自动获取 IP
	netsh interface ipv4 set address name="以太网" source=dhcp  

5.多 IP 地址绑定（同一网卡添加额外 IP）：
	netsh interface ipv4 add address name="以太网" addr=10.0.0.2 mask=255.255.255.0  

6.静态 DNS 服务器设置：
	# 首选 DNS
	netsh interface ipv4 set dnsservers "以太网" static 114.114.114.114 primary  
	
	# 备用 DNS
	netsh interface ipv4 add dnsservers "以太网" 8.8.8.8 index=2  

7.切换为 DHCP 自动获取 DNS：
	netsh interface ipv4 set dnsservers "以太网" source=dhcp  

8.刷新 DNS 缓存：ipconfig /flushdns  
9.查看本地 DNS 缓存：ipconfig /displaydns  

10.添加静态路由（临时 / 永久）：
	# 临时路由：访问 172.16.0.0/24 网段，通过网关 192.168.1.1
	route add 172.16.0.0 mask 255.255.255.0 192.168.1.1 metric 5  
	
	# 永久路由：重启后保留（加 -p 参数）
	route /p add 192.168.5.0 mask 255.255.255.0 10.0.0.1  

11.删除路由：
	route delete 172.16.0.0 mask 255.255.255.0  

12.清除所有非核心路由：
	route /f  

13.开放指定端口（以 TCP 80 为例）：
	netsh advfirewall firewall add rule name="允许 TCP 80 端口" dir=in action=allow protocol=TCP localport=80  

14.开放端口范围（如 1000-2000）：
	netsh advfirewall firewall add rule name="允许 TCP 1000-2000" dir=in action=allow protocol=TCP localport=1000-2000  

15.允许程序通过防火墙（以 “notepad.exe” 为例）：
	netsh advfirewall firewall add rule name="允许记事本联网" dir=in action=allow program="C:\Windows\System32\notepad.exe"  

16.启用 / 禁用防火墙：
	netsh advfirewall set allprofiles state on   # 启用
	netsh advfirewall set allprofiles state off  # 禁用

17.查看无线网卡驱动支持：
	netsh wlan show drivers  

18.创建并启动 Wi-Fi 热点：
	# 1. 启用热点（SSID: MyHotspot，密码: 12345678）
	netsh wlan set hostednetwork mode=allow ssid=MyHotspot key=12345678  
	
	# 2. 启动热点
	netsh wlan start hostednetwork  
	
	# 3. 查看热点状态
	netsh wlan show hostednetwork  
	
	# 4. 关闭热点
	netsh wlan stop hostednetwork  

19. 释放并续订 DHCP 地址：
	ipconfig /release   # 释放IP
	ipconfig /renew     # 重新获取IP


1.dhcp接口配置

2.dhcp全局配置

AR1000v 的配置指令与之前相同，只是中间加了一个交换机

3.dhcp中继配置

DHCP 依赖广播找服务器，但广播过不了路由器。
如果客户端和 DHCP 服务器在不同网段，客户端的“求 IP”广播会被路由器拦下，服务器永远收不到。
DHCP 中继就是路由器上的一个“信使”，它能收到客户端的广播，然后转发成单播给远端的 DHCP 服务器，让跨网段的客户端也能自动获取 IP。

三、数据包，段，帧等分析

1
2
3
4
5
6
7
8
9
10
[ Frame ] ———— 最外层：快递箱
    |
    └── [ Ethernet II ] ———— 外包装：收件人 MAC 地址、发件人 MAC 地址
            |
            └── [ Internet Protocol Version 4 ] ———— 中间层：IP 地址（192.168.1.10 → 8.8.8.8）
                    |
                    └── [ Transmission Control Protocol ] ———— 内包装：端口号（54321 → 80）
                            |
                            └── [ HTTP ] ———— 货物：你请求的网页内容

随便抓取一个tcp包进行分析:

物理层：

链路层：

[Stream index: 0]
这是抓包工具（如 Wireshark）的内部标识，表示该帧属于 “流索引为 0” 的数据包流（用于工具内部对相关数据包进行分组管理，方便分析同一 “流” 的通信）。

网络层：

传输层：

补充：

四、实验

1.网络搭建

  1. 左子网：

对AR1000v

win只需配置dhcp即可

  1. 右子网：

对于AR1000v

对winserver

配置静态ip:

安装DNS与IIS：

对DNS进行配置：

2.实验引入

没有进行任何操作对win进行抓包：

win主机向发送大量数据包，这是为什么？

Win (1) 节点是一个完整的 Windows 操作系统。当它启动并联网后，操作系统内部的许多服务和进程会自动开始工作，它们会发送各种网络请求，即使没有手动打开浏览器或执行命令。

1
2
3
4
5
6
7
8
这些“后台”活动包括：

1.网络发现服务：Windows 会尝试发现局域网内的其他计算机和共享资源。
2.NetBIOS 名称服务 (NBNS)：这是旧版 Windows 用于在局域网内解析计算机名称的服务。您看到的 NBNS 和 Name query NB ISATAP<00> 就是这类查询。
3.链路本地多播名称解析 (LLMNR)：这是现代 Windows 系统用来在局域网内解析主机名的一种替代方案。您看到的 LLMNR 数据包就是它发出的。
4.IPv6 邻居发现协议 (NDP)：用于 IPv6 地址的自动配置和邻居发现。您看到的 fe80::... 开头的地址就是 IPv6 的链路本地地址。
多播地址通信：224.0.0.252 是一个用于 LLMNR 的多播地址。Windows 会向这个地址发送查询，询问“谁叫这个名字？”。

解决方案：

1.wireshark 过滤信息
2.在抓包前清空缓存 （ipconfig /release； arp -d； ipconfig /flushdns）

实验1(wireshark基础抓包分析)

略过

指令：

  • win:
1
2
3
4
5
6
7
8
9
10
11
12
# 彻底清除ARP缓存
arp -d *

# 释放并更新IP（强制DHCP过程）
ipconfig /release
ipconfig /renew

# 清除DNS缓存
ipconfig /flushdns

# 重启网络服务（可选）
netsh int ip reset
  • AR1000v:
1
2
# 清除路由器ARP缓存
clear arp-cache
  • winserver:
1
2
# 清除服务器ARP缓存
arp -d *

实验2(以太网MAC 帧分析)

实验思路：刷新win的网卡信息，随后ping dns服务器，抓取win-e0数据包进行分析

win的网卡信息:

winserver网卡信息：

网关接口的mac地址：

arp广播包分析：

arp应答

实验3(IP数据包的解析)

1
2
3
4
5
6
7
8
9
10
11
12
ipconfig/release
arp -d
ipconfig/flushdns
pause
ipconfig/renew
ping -l 2000 -f 192.168.2.20  (向DNS服务器发送2000字节数据包，不拆分)
ping -l 2000 192.168.2.20     (向DNS服务器发送2000字节数据包，允许拆分)
tracert 192.168.2.20          (跟踪到DNS服务器的路由)
pause

重新得到的 Win主机ip地址是 192.168.1.188

实验数据分析：

网络层结构分析（下面图片的数据不是本环境所抓取）

重点分析一下指令产生的数据包：

  • ping -l 2000 -f 192.168.2.20 (向DNS服务器发送2000字节数据包，不拆分)
  • ping -l 2000 192.168.2.20 (向DNS服务器发送2000字节数据包，允许拆分)
  • tracert 192.168.2.20 (跟踪到DNS服务器的路由)
  1. 数据包过滤：icmp && ip.dst == 192.168.2.20 （所有Win主机向DNS服务器发送的icmp报文）
  1. 查看所有分片的数据包：ip.frag_offset != 0
  1. 查看所有不分片的icmp包：ip.dst == 192.168.2.20 && icmp && ip.flags.df == 1

实验3总结：

IP数据包解析实验验证了网络层协议的核心特性：通过分析头部字段（如版本、首部长度、TTL、协议类型及源/目的IP地址），成功实现了对数据包传输路径、存活时间及上层协议类型的准确识别

实验4(网际控制报文协议 ICMP分析)

1
2
3
4
5
6
7
8
9

ipconfig/release
arp -d
ipconfig/flushdns

# 使用wireshark抓取对应网卡
ipconfig/renew
ping www.sina.com
tracert www.baidu.com

ping www.sina.com

过滤数据包：icmp && ip.dst == 163.142.155.14

ICMP数据包分析：

补充ICMP分析：

指令：tracert www.Baidu.com

过滤指令：icmp && ip.dst == 157.148.69.151

第32个网络帧TTL情况（no response）：

第55个网络帧TTL情况（no response）：

第112个网络帧TTL情况（reply）：

数据包的整体情况：

TTL的值不断增加，其机制是：
tracert 是通过逐步增加 TTL（生存时间）值，结合 ICMP 协议来追踪路由的：

  1. 向目标发送第 1 组数据包时，设置TTL=1；
  2. 数据包到达第 1 跳路由器（比如本地网关），路由器将 TTL 减 1→变为 0，按照 IP 协议规则，路由器会返回一个 ICMP “时间超过” 消息，tracert 因此获取第 1 跳的地址；
  3. 接着发送第 2 组数据包，设置TTL=2，数据包到达第 2 跳路由器，TTL 减到 0，路由器返回 ICMP 超时消息→获取第 2 跳地址；
  4. 以此类推，直到数据包的 TTL 足够到达目标，目标会返回ICMP 回显响应（而非超时消息），tracert 结束跟踪。

实验5(TCP 数据包及连接建立过程分析)

TCP三次握手与四次挥手机制：

三次握手阶段（连接建立）

  1. 第1个包：客户端 → 服务器

    • 报文：SYN=1 Seq=x
    • 含义：
      • SYN=1：“同步”标志位，代表客户端向服务器发起连接请求；
      • Seq=x：客户端告诉服务器“我接下来发数据的初始序号是x”；
    • 状态变化：客户端从Closed→SYN_SEND，服务器保持Listen（监听状态）。

  2. 第2个包：服务器 → 客户端

    • 报文：SYN=1 ACK=1 Seq=y Ack=x+1
    • 含义：
      • SYN=1：服务器同时向客户端发起自己的连接请求；
      • ACK=1：“确认”标志位，代表服务器已收到客户端的连接请求；
      • Seq=y：服务器告诉客户端“我接下来发数据的初始序号是y”；
      • Ack=x+1：“确认号”，表示“我期望收到你下一个包的序号是x+1”（因为已收到你序号为x的包）；
    • 状态变化：服务器从Listen→SYN_RCVD，客户端仍在SYN_SEND。

  3. 第3个包：客户端 → 服务器

    • 报文：ACK=1 Seq=x+1 Ack=y+1
    • 含义：
      • ACK=1：客户端已收到服务器的连接请求；
      • Seq=x+1：客户端按序号规则，下一个包的序号是x+1；
      • Ack=y+1：期望收到服务器下一个包的序号是y+1；
    • 状态变化：客户端→Established，服务器→Established（双方进入“已连接”状态，可开始传数据）。

数据传输阶段

  • 报文：图中“数据传输”对应的是双方在Established状态下的数据包
  • 含义：
    • 标志位默认带ACK=1（确认对方之前的包）；
    • 包中会包含Application Data（实际要传输的内容，比如网页数据、文件内容）；
    • Seq和Ack会根据“已传输的字节数”递增（比如客户端发了100字节数据，下一个Seq就是x+1+100）。

四次挥手阶段（连接释放）

  1. 第1个包：客户端 → 服务器

    • 报文：FIN=1 Seq=u
    • 含义：
      • FIN=1：“结束”标志位，代表客户端请求关闭自己的发送通道；
      • Seq=u：客户端当前的序号是u；
    • 状态变化：客户端从Established→FIN_WAIT_1。

  2. 第2个包：服务器 → 客户端

    • 报文：ACK=1 Seq=v Ack=u+1
    • 含义：
      • ACK=1：服务器已收到客户端的关闭请求；
      • Ack=u+1：期望收到客户端下一个包的序号是u+1；
    • 状态变化：服务器从Established→CLOSE_WAIT，客户端从FIN_WAIT_1→FIN_WAIT_2。

  3. 第3个包：服务器 → 客户端

    • 报文：FIN=1 ACK=1 Seq=w Ack=u+1
    • 含义：
      • FIN=1：服务器请求关闭自己的发送通道；
      • ACK=1：附带确认客户端之前的包；
      • Seq=w：服务器当前的序号是w；
    • 状态变化：服务器从CLOSE_WAIT→LAST_ACK，客户端仍在FIN_WAIT_2。

  4. 第4个包：客户端 → 服务器

    • 报文：ACK=1 Seq=u+1 Ack=w+1
    • 含义：
      • ACK=1：客户端已收到服务器的关闭请求；
      • Ack=w+1：期望收到服务器下一个包的序号是w+1；
    • 状态变化：客户端从FIN_WAIT_2→TIME_WAIT（等待2MSL后回到Closed），服务器收到包后从LAST_ACK→Closed。

抓取虚拟机网卡，浏览器访问www.bilibili.com (http协议建立在tcp之上)

补充知识：
由于tcp数据包数量巨大，可以使用wireshark自带的 追踪流 功能（选中数据包，右键菜单窗口就会有 追踪流选项），追踪流也分多种，具体协议具体分析，缺陷：只能对明文信息进行追踪

TCP三次挥手分析：

获取 ‘bilibili’最近服务器的ip地址:157.148.134.11 port:443

指令：tcp.flags.syn == 1（只显示 SYN 标志为 1 的包）

可知 53号网络帧是第一次握手，57号网络帧是第二次握手；x=0 y=0

分析第三次握手的数据：
Seq=x+1 即 Seq=0+1=1; ACK=y+1 即 ACK=0+1=1

TCP四次挥手分析：

上面的抓包数据没有抓到完整的TCP的四次完整挥手包，需要重新抓取

Bilibili最近服务器的ip地址:157.148.134.11 port:443 与之前一样

指令：ip.addr == 192.168.79.134 && ip.addr == 157.148.134.11 && tcp.flags.fin == 1 （更加精准的过滤指令，抓取第一次，第三挥手的数据包）

  • 为什么第一次挥手与第三次挥手的网络帧编号‘差距’有点大呢？（相对于三次握手）

    首先要知道第三次挥手的意义：服务端告诉客户端‘正在’传输的数据传输完毕,也就是说，第一次挥手与第三次挥手之间的 时延 是为了将最后一次数据传输完毕

观察3361 3395 的ACK： 相同
1. 丢包了
2. 两次挥手之间就没有数据传输

显然是后者，所以 w=v 是合理的

实验总结

本次实验聚焦 TCP 协议的核心机制，通过 Wireshark 抓包验证了三次握手（连接建立）与四次挥手（连接释放）的流程。实验中，我们捕获目标网络连接的 TCP 数据包，利用过滤条件隔离有效报文，追踪 TCP 流分析 SYN、ACK、FIN 等标志位及序列号（Seq）、确认号（Ack）的变化规律。结果表明，抓包数据与理论机制完全吻合，Seq 与 Ack 严格遵循 “确认号 = 对方上一序列号 + 1” 的规则，成功验证了 TCP 协议 “面向连接、可靠传输” 的特性。通过实验，快速掌握了 Wireshark 抓包分析的核心技巧，深化了对 TCP 连接建立与释放逻辑的理解。

实验6(超文本传送协议HTTP分析)

由于之前的实验已经对应用层一下的网络层次结构作为分析，本次实验就不再分析了

分析http请求包：

分析http回应包：

实际上，http的内容字段各不相同，取决与服务器的资源格式
补充： http状态码
1. 信息性状态码：1xx（服务器已接收请求，正在处理，很少直接看到）
2. 成功状态码：2xx
3. 重定向 / 缓存状态码：3xx
4. 客户端错误状态码：4xx
5. 服务器错误状态码：5xx

实验总结：

本次实验通过 Wireshark 抓包分析 HTTP 协议，成功捕获访问国内网站的请求与响应数据包，验证了 HTTP 与 TCP 协议的协同工作逻辑。核心发现 HTTP 304 状态码实现缓存优化，抓包数据与理论机制一致。实验掌握了 Wireshark 抓包过滤技巧，深化了对应用层协议的理解

实验7(域名系统 DNS 分析)

1
2
3
4
5
6
ipconfig/release
arp -d
ipconfig/flushdns

ping www.bilibili.com

DNS请求包分析：

DNS响应包分析：

IP 地址 (class ,是一个16 位值，标记协议族或某一个协议实例，使用 IN 代表 internet 系统，CH代表 Chaos 系统; classIN 是一个 32 位 IP 地址 )

通过实验验证了 DNS 的核心作用：将人类易记的域名（如www.bilibili.com）转换为机器可识别的 IP 地址，同时观察到：
1. 大型网站常用 “CNAME 别名 + 多 A 记录” 的组合，兼顾域名灵活性与访问稳定性；
2. DNS 基于 UDP 53 端口通信（响应包较小），解析过程通过 “事务 ID” 确保请求与响应的精准匹配；
3. 本地 DNS 服务器（如 192.168.79.2）承担递归查询角色，替主机完成从根服务器→顶级域服务器→权威服务器的迭代查询，最终返回解析结果。

实验8(动态主机配置协议 DHCP 分析)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
动态主机配置协议 DHCP 提供了即插即用连网(plug-and-play networking)的机制。
这种机制允许一台计算机加入新的网络和获取 IP 地址而不用手工参与。
 需 要 IP 地 址 的 主 机 在 启 动 时 就 向 DHCP 服 务 器 广 播 发 送 发 现 报 文 （ DHCP
DISCOVER），这时该主机就成为 DHCP 客户。
 本地网络上所有主机都能收到此广播报文，但只有 DHCP 服务器才回答此广播报文。
 DHCP 服务器先在其数据库中查找该计算机的配置信息。若找到，则返回找到的信
息。若找不到，则从服务器的 IP 地址池(address pool)中取一个地址分配给该计算机。
DHCP 服务器的回答报文叫做提供报文（DHCP OFFER）
 并不是每个网络上都有 DHCP 服务器，这样会使 DHCP 服务器的数量太多。现在
是每一个网络至少有一个 DHCP 中继代理，它配置了 DHCP 服务器的 IP 地址信
息。
 当 DHCP 中继代理收到主机发送的发现报文后，就以单播方式向 DHCP 服务器转
发此报文，并等待其回答。收到 DHCP 服务器回答的提供报文后，DHCP 中继代
理再将此提供报文发回给主机。（DHCP OFFER）
 DHCP 客户从几个 DHCP 服务器中选择其中的一个，并向所选择的 DHCP 服务
器发送 DHCP 请求报文。（DHCP REQUEST）
 被选择的 DHCP 服务器发送确认报文 DHCPACK，进入已绑定状态。（DHCP ACK）

发现报文分析：

DHCP Discover 报文是 IP 地址分配流程的初始发起：客户端通过该报文以广播形式寻找网络中的 DHCP 服务器，传递自身硬件标识（MAC 地址）与会话标识（事务 ID），发起 IP 地址及网络配置的请求，标志 DHCP 全流程（Discover→Offer→Request→Ack）正式启动。

提供报文分析：

DHCP Request 报文是 IP 地址分配流程的方案锁定：客户端通过该报文明确选定目标 DHCP 服务器的 IP 分配方案，告知其他服务器释放预留资源，请求下发完整网络配置，标志 DHCP 全流程（Discover→Offer→Request→Ack）进入最终确认阶段

请求报文分析：

那DHCP请求报文存在的意义是什么？
DHCP Request 报文的核心作用是客户端向目标 DHCP 服务器确认租用其提供的 IP 地址，明确了客户端的地址需求与服务端标识，是 DHCP 地址分配流程中 “确认租用意向” 的关键环节，后续服务器会通过 DHCP Ack 报文完成最终的地址分配与配置下发

确认报文分析：

DHCP Ack 报文是IP 地址分配流程的最终确认：服务器通过该报文完成 IP 地址的正式分配，并下发子网掩码、网关、DNS 等完整网络配置，客户端接收后即可基于分配的 IP 地址建立网络连接，标志 DHCP 全流程（Discover→Offer→Request→Ack）完成

DHCP分配IP地址过程图：

实验9(WEB 页面请求全历程协议及数据包解析（综合性实验）)

访问我自己的博客网站，获取数据：http://zq-rookie-hacker.github.io

1. 为什么不直接使用https呢？
可以观察到HTTP到HTTPS的重定向过程

2. 访问这个网站可以获取实验所需的数据吗？
真实网络环境：GitHub Pages是真实的Web服务，完全符合实验要求的”访问目标WEB网站”条件可能包含重定向：GitHub Pages通常会将HTTP请求重定向到HTTPS，这正好可以帮助您分析实验要求中的”如果发生重定向，新的web页面的地址是什么”问题
DNS解析复杂性：GitHub Pages使用CNAME记录和全球CDN，会使DNS解析过程更丰富，有助于分析DNS解析内容
网络协议完整性：仍然会经历完整的DNS解析→TCP连接建立→HTTP请求→数据传输过程

清除网站cookie：

刷新网络信息：

DNS响应包：

查询IP地址:

  1. P地址归属：185.199.109.153 是 GitHub 的IP地址之一
    • 这是GitHub Pages服务使用的服务器IP地址
    • GitHub Pages是用来托管博客的平台
  2. “泛播”的含义：
    • “泛播”(Anycast)是一种网络技术，多个服务器使用相同的IP地址
    • 当您访问这个IP时，网络会自动将您的请求路由到最近的服务器
    • 这种技术提高了服务的可靠性和访问速度

TCP协议分析：

TCP三次握手：（之前的实验分析过TCP三次握手的数据包了）

TCP四次挥手：（之前的实验分析过TCP四次挥手的数据包了）

结合抓包数据与 TCP 状态图，u、v、w的取值是 “三次握手后数据传输驱动序列号递增” 及 “TCP 报文序列号规则” 共同作用的结果：u=489对应客户端发起 FIN 报文（包 366）的序列号，v=670对应服务器回复 ACK 报文（包 367）的序列号，二者的数值是三次握手后数据传输让初始序列号持续递增的结果；而w=670则因 TCP 纯 ACK 报文不占用序列号，服务器发起 FIN 时延续了回复 ACK 的序列号，同时服务器回 ACK 的确认号（490）也符合状态图 “ACK=u+1” 的规则。

TCP超时重传：tcp.analysis.retransmission

都是在重传同一个包

过滤：

第一：使用的是 ip.src == 4.145.79.80 的过滤指令，那就说明了 服务器一直重传失败
第二：不继续重传，说明触发发tcp重传的终止机制

一、核心机制 1：超时重传（Timeout Retransmission）
这是最基础的重传方式，靠 “超时等待” 触发：
1. 触发条件：发送方发送一个 TCP 报文后，会启动一个 “超时计时器（RTO，Retransmission Timeout）”；如果计时器到期前，没收到接收方的 ACK 确认包，就会重传这个报文。
2. 超时时间（RTO）怎么定？
- 初始 RTO 是系统默认值（比如 1 秒）；
- 后续会根据 “往返时间（RTT，报文发出去到收到 ACK 的时间）” 动态调整（比如 RTT 变长，RTO 也会跟着调大），避免误判超时。
3. 指数退避规则：每次重传失败后，RTO 会翻倍增长（比如第一次 RTO=1 秒，第二次 = 2 秒，第三次 = 4 秒…），避免短时间内重复发包导致网络拥塞。
4. 终止条件：重传次数达到系统设定的 “最大重传次数”（比如 Linux 默认 15 次）后，发送方会认为 “连接彻底不可用”，停止重传并断开 TCP 连接。
二、核心机制 2：快速重传（ Fast Retransmission）
这是更高效的重传方式，靠 “重复 ACK” 主动触发：
1. 触发条件：接收方收到 “乱序的 TCP 报文” 时（比如应该收 Seq=2，但先收到了 Seq=3），会重复发送 “对已收到报文的 ACK”（比如一直发 Ack=2）；当发送方收到3 个相同的重复 ACK，就会判定 “中间的报文（比如 Seq=2）丢失了”，直接重传这个丢失的报文。
2. 优势：不用等超时计时器到期，靠 “重复 ACK” 主动发现丢包，重传速度更快，能提升传输效率。

分析具体重传数据包：

http重定向分析：
http请求包：

http响应包：

Frame 269是 GitHub Pages 服务器的 “指令包”：它通过301状态码 +Location字段，强制将你原本访问的HTTP地址，重定向到更安全的HTTPS地址 —— 这是 GitHub Pages 的默认安全规则，也是当前网站普遍采用的 “HTTP→HTTPS 强制跳转” 实现方式

实验总结：

  1. WEB 页面请求是多协议协同的完整流程：DNS 解析（域名→IP）→TCP 连接（可靠传输基础）→HTTP 请求与响应（应用层数据交互）→重定向（协议 / 地址切换），各层协议各司其职、无缝衔接，确保请求合法、数据可靠传输。
  2. 关键技术与协议特性验证：GitHub Pages 采用 “CNAME 记录 + CDN + 泛播” 架构，通过多 IP 分发提升服务可用性；DNS 解析依赖事务 ID 与 UDP 端口保障通信精准性；TCP 三次握手是可靠连接的核心；HTTP 301 重定向是实现协议升级（HTTP→HTTPS）的标准方式，体现了应用层协议的灵活性与安全性设计。
  3. 抓包分析的核心技巧：清除缓存与历史会话是获取纯净数据包的前提；通过协议过滤（如dns tcp http）可快速定位关键流程；聚焦核心字段（DNS 的事务 ID、TCP 的标志位、HTTP 的状态码与 Location 头）能高效拆解协议交互逻辑