Day04-05 网络基础与进阶 - 测验与作业
[TOC]
题目一：OSI 五层协议每一层的核心协议及作用解析
参考答案
| 层级 | 名称 | 核心协议 | 数据单位 | 主要作用 |
|---|---|---|---|---|
| 5 | 应用层 | HTTP、SMTP、FTP、DNS、TLS | 消息/报文 | 为用户提供网络服务接口，实现应用程序间的通信 |
| 4 | 传输层 | TCP、UDP | 段（Segment） | 提供端到端的可靠/不可靠传输服务，通过端口区分应用 |
| 3 | 网络层 | IP、ICMP、ARP、RIP、OSPF | 包（Packet） | 实现不同网络间的路由转发，负责 IP 寻址和路径选择 |
| 2 | 数据链路层 | Ethernet（802.3）、PPP、VLAN | 帧（Frame） | 负责同一局域网内的数据转发，通过 MAC 地址寻址 |
| 1 | 物理层 | IEEE 802.3、光纤、同轴电缆 | 比特（Bit） | 在物理介质上传输原始比特流 |
核心要点
- 分层思想：每层只关心本层职责，上下层通过接口交互
- TCP vs UDP：
- TCP：面向连接、可靠传输、适合对可靠性要求高的应用
- UDP：无连接、快速传输、适合实时性要求高的应用
- ARP：IP → MAC 的桥梁，局域网内通信的关键协议
- 封装/解封装：数据从应用层向下逐层封装，接收时逐层解封装
题目二：如何让一个 IP 地址能表达出两层意思
参考答案
方法：通过子网掩码（Subnet Mask）
单独的 IP 地址只是一个 32 位数字，无法区分网络部分和主机部分。子网掩码的作用就是将 IP 地址划分为两个部分：
flowchart LR
A["IP 地址 + 子网掩码"] --> B["网络部分<br/>(代表一个网段)"]
A --> C["主机部分<br/>(代表具体主机)"]
示例说明
IP地址: 192.168.71.100
子网掩码: 255.255.255.0 (/24)
IP地址二进制:
11000000.10101000.01000111.01100100
子网掩码二进制:
11111111.11111111.11111111.00000000 (/24)
按位与运算后:
网络地址: 11000000.10101000.01000111.00000000 → 192.168.71.0
主机地址: 00000000.00000000.00000000.01100100 → 0.0.0.100
核心结论
| 表达内容 | 示例 |
|---|---|
| 网络地址 | 192.168.71.0（代表整个 192.168.71.x 网段） |
| 主机地址 | 0.0.0.100 或直接写 100（第 100 号主机） |
一句话总结：子网掩码决定了 IP 地址中哪些位是网络号，哪些位是主机号，从而让 IP 地址同时具备"网段身份"和"主机身份"两层含义。
题目三：局域网内与跨局域网通信流程
参考答案
flowchart TD
subgraph LAN["局域网通信"]
A1[源主机] --> A2{目标是否在同一局域网?}
A2 -->|是| A3[ARP 广播查询目标 MAC]
A3 --> A4[目标主机回应 ARP]
A4 --> A5[直接发送以太网帧]
A5 --> A6[目标接收数据]
end
subgraph CrossLAN["跨局域网通信"]
B1[源主机] --> B2{目标是否在同一局域网?}
B2 -->|否| B3[ARP 查询网关 MAC]
B3 --> B4[封装帧: 目标MAC=网关]
B4 --> B5[路由器接收帧并解封装]
B5 --> B6{到达目标网络?}
B6 -->|否| B7[根据路由表转发]
B7 --> B6
B6 -->|是| B8[ARP 查询目标 MAC]
B8 --> B9[封装新帧并发送]
B9 --> B10[目标主机接收]
end
style A1 fill:#e3f2fd
style B1 fill:#fff3e0
style B10 fill:#e8f5e9
详细流程对比
局域网内通信（同网段）
1. 源主机检查：目标 IP 与我是否在同一网段？
→ 计算：(源IP & 掩码) == (目标IP & 掩码) ？是
2. ARP 广播：发送 "谁拥有目标 IP？请告诉我你的 MAC"
→ 广播帧: FF:FF:FF:FF:FF:FF
3. 目标主机回应 ARP：包含自己的 MAC 地址
4. 源主机直接发送以太网帧：
源MAC → 目标MAC + 源IP → 目标IP + 数据
跨局域网通信（不同网段）
1. 源主机检查：目标 IP 与我是否在同一网段？
→ 计算：(源IP & 掩码) == (目标IP & 掩码) ？否
2. ARP 请求网关 MAC：发送 "谁拥有网关 IP？请告诉我 MAC"
3. 封装数据帧：
- 源MAC = 本机 MAC
- 目标MAC = 网关 MAC
- 源IP = 本机 IP
- 目标IP = 目标服务器 IP
4. 路由器逐跳转发：
- 每经过一个路由器，源/目标 MAC 会改变
- 源/目标 IP 保持不变（NAT 会改变源 IP）
5. 到达目标网络后，通过 ARP 获取目标主机 MAC
6. 最终交付数据
核心区别
| 对比项 | 局域网通信 | 跨局域网通信 |
|---|---|---|
| 是否需要网关 | 否 | 是 |
| ARP 查询目标 | 目标主机 MAC | 网关 MAC |
| MAC 地址变化 | 始终不变 | 每跳可能变化 |
| IP 地址变化 | 始终不变 | 可能有 NAT |
题目四：域名解析流程（标注递归/迭代环节）
参考答案
sequenceDiagram
participant User as 用户浏览器
participant Browser as Chrome DNS<br/>缓存
participant Hosts as HOSTS 文件
participant System as 系统 DNS<br/>缓存
participant Local as 本地 DNS<br/>服务器
participant Root as 根域名<br/>服务器
participant TLD as .com TLD<br/>服务器
participant Auth as 权威 DNS<br/>服务器
participant Web as 目标 Web<br/>服务器
User->>Browser: 查询 www.example.com
Browser-->>User: 缓存命中返回 IP
Note over User: 命中则结束
User->>Hosts: 查找 HOSTS 文件
Hosts-->>User: 找到则返回 IP
Note over User: 命中则结束
User->>System: 查询系统 DNS 缓存
System-->>User: 找到则返回 IP
Note over User: 命中则结束
rect rgb(200, 220, 255)
Note over User,Auth: 【递归查询】本地 DNS 代替客户端完成全部查询
User->>Local: 请帮我解析 www.example.com
rect rgb(255, 240, 200)
Note over Local,Root: 【迭代查询】本地 DNS 向根服务器查询
Local->>Root: www.example.com 是谁管理的？
Root-->>Local: 去问 .com TLD 服务器
end
rect rgb(255, 240, 200)
Note over Local,TLD: 【迭代查询】本地 DNS 向 TLD 查询
Local->>TLD: www.example.com 是谁管理的？
TLD-->>Local: 去问 example.com 的权威 DNS
end
rect rgb(255, 240, 200)
Note over Local,Auth: 【迭代查询】本地 DNS 向权威 DNS 查询
Local->>Auth: www.example.com 的 IP 是多少？
Auth-->>Local: IP 地址是 93.184.216.34
end
Local-->>User: 返回解析结果: 93.184.216.34
end
User->>Web: 建立 HTTP 连接
解析流程总结
flowchart TD
A["用户输入 URL"] --> B{"Chrome DNS 缓存"}
B -->|命中| Z["返回 IP"]
B -->|未命中| C{"HOSTS 文件"}
C -->|命中| Z
C -->|未命中| D{"系统 DNS 缓存"}
D -->|命中| Z
D -->|未命中| E["本地 DNS 服务器<br/>(递归查询)"]
E --> F["迭代查询1: 根域名服务器"]
F --> G["迭代查询2: .com TLD 服务器"]
G --> H["迭代查询3: example.com 权威 DNS"]
H --> Z
关键术语解释
| 术语 | 说明 |
|---|---|
| 递归查询 | 客户端向本地 DNS 发起请求，本地 DNS 代替客户端完成整个查询过程，最终返回完整结果 |
| 迭代查询 | DNS 服务器之间查询时，如果不知道答案，会返回另一个 DNS 服务器的地址，让查询方自行继续查询 |
| 根域名服务器 | 全球共 13 组，负责管理顶级域（如 .com、.cn） |
| TLD 服务器 | 顶级域名服务器，负责管理二级域（如 .com、.org、.cn） |
| 权威 DNS | 域名所有者配置的 DNS，拥有域名的最终解析权 |
题目五：TCP 三次握手和四次挥手流程图
参考答案
5.1 TCP 三次握手
sequenceDiagram
participant C as 客户端 Client
participant S as 服务端 Server
Note over C: 初始状态: CLOSED
Note over S: 初始状态: LISTEN（监听端口）
rect rgb(200, 230, 255)
Note over C,S: 【第一次握手】客户端发送 SYN
C->>S: SYN=1, seq=x
Note over C: 状态: SYN_SENT
Note over C,S: 客户端发送能力验证 ✓
end
rect rgb(255, 230, 200)
Note over C,S: 【第二次握手】服务端发送 SYN+ACK
S->>C: SYN=1, ACK=1, seq=y, ack=x+1
Note over S: 状态: SYN_RCVD
Note over C,S: 服务端接收能力 ✓<br/>服务端发送能力 ✓
end
rect rgb(200, 255, 200)
Note over C,S: 【第三次握手】客户端发送 ACK
C->>S: ACK=1, seq=x+1, ack=y+1
Note over C: 状态: ESTABLISHED
Note over S: 状态: ESTABLISHED
Note over C,S: 客户端接收能力 ✓<br/>双方通信能力确认完成
end
Note over C,S: 连接建立成功，可以传输数据
三次握手状态变化：
| 阶段 | 客户端状态 | 服务端状态 | 关键标志 |
|---|---|---|---|
| 初始 | CLOSED | LISTEN | - |
| 第1次握手 | SYN_SENT | - | SYN=1, seq=x |
| 第2次握手 | - | SYN_RCVD | SYN=1, ACK=1, ack=x+1 |
| 第3次握手 | ESTABLISHED | ESTABLISHED | ACK=1, ack=y+1 |
为什么需要三次？
- 第一次握手：证明客户端有发送能力
- 第二次握手：证明服务端有接收+发送能力
- 第三次握手：证明客户端有接收能力
5.2 TCP 四次挥手
sequenceDiagram
participant A as 主动关闭方
participant B as 被动关闭方
Note over A,B: 初始状态: ESTABLISHED（双方正常通信）
rect rgb(200, 230, 255)
Note over A,B: 【第一次挥手】主动方发送 FIN
A->>B: FIN=1, seq=u
Note over A: 状态: FIN_WAIT_1
Note over A,B: 主动方不再发送数据<br/>但仍可接收数据
end
rect rgb(255, 230, 200)
Note over A,B: 【第二次挥手】被动方发送 ACK
B->>A: ACK=1, ack=u+1
Note over B: 状态: CLOSE_WAIT
Note over A: 状态: FIN_WAIT_2
Note over A,B: 被动方确认收到 FIN<br/>等待处理剩余数据
end
Note over B: 被动方处理剩余未发送数据...
rect rgb(255, 240, 200)
Note over A,B: 【第三次挥手】被动方发送 FIN
B->>A: FIN=1, seq=w, ack=u+1
Note over B: 状态: LAST_ACK
Note over A,B: 被动方数据处理完毕<br/>请求关闭连接
end
rect rgb(200, 255, 200)
Note over A,B: 【第四次挥手】主动方发送 ACK
A->>B: ACK=1, ack=w+1
Note over B: 状态: CLOSED
Note over A: 状态: TIME_WAIT
Note over A,B: 主动方等待 2MSL 后关闭
end
Note over A: 等待 2MSL（约60秒）后
Note over A: 状态: CLOSED
Note over A,B: 连接完全关闭
四次挥手状态变化：
| 阶段 | 主动关闭方 | 被动关闭方 | 关键动作 |
|---|---|---|---|
| 初始 | ESTABLISHED | ESTABLISHED | 正常通信 |
| 第1次挥手 | FIN_WAIT_1 | CLOSE_WAIT | 发送 FIN，请求关闭 |
| 第2次挥手 | FIN_WAIT_2 | CLOSE_WAIT | 发送 ACK，同意关闭（但等待数据） |
| 第3次挥手 | TIME_WAIT | LAST_ACK | 发送 FIN，数据处理完毕 |
| 第4次挥手 | TIME_WAIT | CLOSED | 发送 ACK，收到后关闭 |
| 最终 | CLOSED | - | 等待 2MSL 后关闭 |
为什么需要四次？
- TCP 是全双工通信，每个方向都需要单独关闭
- 第一次/第二次挥手：关闭主动方 → 被动方的数据流
- 第三次/第四次挥手：关闭被动方 → 主动方的数据流
TIME_WAIT 等待 2MSL 的原因：
- 确保被动关闭方收到最后的 ACK
- 让本连接的所有报文在网络中消失，避免影响新连接
附加：常见面试追问
| 问题 | 答案要点 |
|---|---|
| TCP 和 UDP 的区别？ | 见主文档表格，重点：连接性、可靠性、效率 |
| 为什么 TCP 需要三次握手？ | 验证双方收发能力，避免历史连接干扰 |
| 为什么挥手需要四次？ | 全双工通信，每个方向单独关闭 |
| SYN Flood 攻击原理？ | 发送大量 SYN 不完成握手，耗尽服务端资源 |
| TIME_WAIT 过长怎么办？ | 调整内核参数、复用连接、使用 SO_LINGER |