模块4：网络管理及互联网通信实战
·
模块4：网络管理及互联网通信实战
面向 Linux 云计算工程师的面试/实战进阶笔记。本篇全部示例均可运行，关键结论均来自对真实云主机的实连采集（非虚构）。配套源码已开源，文末附仓库地址与复现方法。
0. 实验环境与开篇说明
本篇所有"真实主机"数据均来自以下实际环境（已获授权实操）：
| 角色 | 主机 | 系统 | 内核 | 网卡/地址 |
|---|---|---|---|---|
| 业务 ECS | 120.46.70.168 (ecs-3e0b-0001) |
Ubuntu 24.04.4 LTS | 6.8.0-106 | eth0 192.168.0.45/24 |
| 部署机 | 117.72.182.3 (lavm-cw9k5dvspp) |
Ubuntu 22.04.3 LTS | 5.15.0-60 | eth0 172.16.0.3/16 |
计算类示例（子网运算、端口分类、TCP 状态机、路由查找）由本地 bash 5.3.9 真实运行；Linux 命令/诊断示例则直接引用上表两台主机的 ip/ss/netplan 真实输出。
1. 本篇使用的提示词（Prompt）与工具
提示词（用于驱动本次实战生成）：
参考教学目标：全面掌握 Linux 云计算工程师所需网络知识，包括
OSI 七层、MAC/网桥/交换机/VLAN、IP/子网/超网/路由、
RIP/OSPF/BGP、TCP 状态机(11 状态,三次握手/四次挥手)、端口分类、
Linux 网络配置(子网掩码/网关)、ifconfig/route/netstat 与 iproute2(ip/ss)、
ping/lftp/ftp/wget、bonding、nmcli/nmtui。
需要实操，并且体现实操效果。需要体现提示词、使用工具、源码仓库地址。
输出博客《模块4:网络管理及互联网通信实战.md》，适合在互联网平台发表。
使用工具：
| 工具 | 用途 |
|---|---|
bash 5.3.9 (Git Bash) |
运行全部计算/演示脚本，产出真实输出 |
paramiko 5.0.0 (Python SSH 库) |
脚本化实连云主机，批量采集 ip/ss/netplan 等只读诊断 |
iproute2 (ip/ss) |
现代 Linux 网络事实标准命令 |
git + Gitee OpenAPI v5 |
源码版本管理与远程仓库创建/推送 |
curl / ping |
连通性与 HTTP 探测 |
数据采集脚本
scripts/diag_target.py仅执行 16 条只读诊断命令（见源码），不会改动目标主机任何配置。
2. OSI 七层模型
网络排查的第一性原理：每一层只解决一类问题。自上而下：
| 层 | 名称 | PDU | 典型协议 | 典型设备 |
|---|---|---|---|---|
| 7 | 应用层 | 报文 | HTTP/HTTPS/FTP/DNS/SSH/SMTP | 无（应用程序） |
| 6 | 表示层 | 报文 | TLS/SSL/JPEG/ASCII/gzip | 无 |
| 5 | 会话层 | 报文 | RPC/NetBIOS/SOCKS | 无 |
| 4 | 传输层 | 段 | TCP/UDP/SCTP | 防火墙(L4)/LB |
| 3 | 网络层 | 包 | IP/ICMP/OSPF/BGP/RIP | 路由器/三层交换机 |
| 2 | 数据链路层 | 帧 | Ethernet/VLAN/PPP/ARP | 交换机/网桥/网卡 |
| 1 | 物理层 | 比特 | RJ45/光纤/802.3 物理规范 | 集线器/中继器/线缆 |
封装过程（发送方逐层加头，接收方逐层解头）：
应用数据
-> [TCP头|数据] 传输层(段)
-> [IP头|TCP头|数据] 网络层(包)
-> [MAC头|IP头|TCP头|数据|FCS] 数据链路层(帧)
-> 0101 比特流 物理层
二层 vs 三层关键概念（面试高频）：
- 数据链路层：用 MAC 地址（48bit，如本篇主机
fa:16:3e:06:5e:8b）在局域网内寻址；交换机依据 MAC 表转发帧；VLAN 在同一物理网络上划分逻辑广播域，隔离广播风暴。 - 网络层：用 IP 地址跨网络寻址；路由器依据路由表转发包。
- 网桥(bridge)：连接多个网段的二层设备，按 MAC 学习转发，可理解为"软件交换机"。
3. IP 地址、子网划分与超网（实跑）
子网划分的本质：用掩码把 32 位地址空间切成"网络位 + 主机位"。下面用纯 bash 实现的计算器（scripts/01_subnet_calc.sh）对真实主机地址做计算，输出为真实运行结果：
=================== IPv4 子网划分实战 ===================
输入 IP/CIDR : 192.168.0.45/24
子网掩码 : 255.255.255.0 (/24)
网络地址 : 192.168.0.0
广播地址 : 192.168.0.255
可用主机范围 : 192.168.0.1 ~ 192.168.0.254
可用主机数 : 254 (公式: 2^(32-24) - 2)
输入 IP/CIDR : 172.16.0.3/16 # atomcode 部署机真实地址
子网掩码 : 255.255.0.0 (/16)
网络地址 : 172.16.0.0
广播地址 : 172.16.255.255
可用主机范围 : 172.16.0.1 ~ 172.16.255.254
可用主机数 : 65534
输入 IP/CIDR : 203.0.113.130/30 # 点对点链路
网络地址 : 203.0.113.128
广播地址 : 203.0.113.131
可用主机范围 : 203.0.113.129 ~ 203.0.113.130
可用主机数 : 2
超网（CIDR 聚合）——把多条细路由合并成一条，减少路由表条目：
将 192.168.0.0/24、192.168.1.0/24、192.168.2.0/24、192.168.3.0/24 聚合：
聚合后网络地址 : 192.168.0.0/22
聚合后掩码 : 255.255.252.0
聚合覆盖范围 : 192.168.0.0 ~ 192.168.3.255
结论 : 4 个 /24 (共 1024 地址) 用 1 条 /22 路由即可表达。
注意：真实主机
192.168.0.45/24的ip -brief address也印证了该计算——eth0 UP 192.168.0.45/24。
4. 路由：路由表、最长前缀匹配与动态路由协议
**最长前缀匹配（LPM）**是路由器选路的铁律：目的 IP 与多条路由都匹配时，掩码最长（最精确）的那条胜出。scripts/06_route_demo.sh 真实运行结果：
=================== 模拟路由表 ===================
目的网络 接口 下一跳
0.0.0.0/0 eth0 192.168.0.1
192.168.0.0/24 eth0 -
10.0.0.0/8 eth1 10.0.0.1
10.1.2.0/24 eth2 10.1.2.1
169.254.169.254/32 eth0 192.168.0.1
-> 目的 192.168.0.45 命中: 接口=eth0 下一跳=直连 (前缀/24)
-> 目的 10.1.2.50 命中: 接口=eth2 下一跳=10.1.2.1 (前缀/24) # 比 /8 更精确
-> 目的 10.9.9.9 命中: 接口=eth1 下一跳=10.0.0.1 (前缀/8)
-> 目的 8.8.8.8 命中: 接口=eth0 下一跳=192.168.0.1 (前缀/0) # 默认路由兜底
-> 目的 169.254.169.254命中: 接口=eth0 下一跳=192.168.0.1 (前缀/32) # 主机路由最精确
真实主机的路由表（来自 120.46.70.168，ip route show 实采）：
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.45 metric 100
169.254.169.254 via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.45 metric 100
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.45 metric 100
动态路由协议对比（面试常考三剑客）：
| 协议 | 类型 | 算法 | 适用范围 | 度量 |
|---|---|---|---|---|
| RIP | 距离矢量 | Bellman-Ford | 小型网络 | 跳数（最大 15） |
| OSPF | 链路状态 | Dijkstra(SPF) | 中大型企业 | 带宽代价 |
| BGP | 路径矢量 | 策略路由 | 运营商/跨 AS | 属性策略（AS-PATH 等） |
云主机由 DHCP 下发路由（
proto dhcp），无需手动跑路由协议；但在企业网/IDC 中，OSPF 常用于内网收敛，BGP 用于多云/多运营商互联。
5. 传输层：端口分类与 TCP 状态机
5.1 端口分类（实跑）
端口空间: 0 ~ 65535 (16 bit)
[0-1023] 特权端口 — 系统/服务端常用, 绑定需 root
[1024-49151] 注册端口 — IANA 分配给特定服务
[49152-65535]动态端口 — 客户端 ephemeral 端口
对真实主机监听端口分类 (来自 ecs-3e0b-0001):
端口 22 -> 特权端口 (sshd, 需 root 绑定)
端口 53 -> 特权端口 (systemd-resolved DNS)
端口 29338 -> 注册端口 (uniagentd)
端口 29339 -> 注册端口 (uniagentd)
5.2 TCP 11 种状态 + 三次握手 / 四次挥手
=================== TCP 11 种状态速查 ===================
LISTEN 服务器等待被动连接(如 sshd 监听 0.0.0.0:22)
SYN-SENT 客户端已发 SYN, 等待对端 SYN+ACK
SYN-RECV 服务器收到 SYN, 已回 SYN+ACK, 等待 ACK
ESTABLISHED 连接已建立, 可双向传输数据
FIN-WAIT-1 主动关闭方已发 FIN, 等待 ACK 或 FIN+ACK
FIN-WAIT-2 收到对端 ACK, 等待对端 FIN
TIME-WAIT 主动关闭方收到 FIN, 等待 2*MSL 确保可靠关闭
CLOSE-WAIT 被动关闭方收到 FIN 并回 ACK, 等待应用关闭
LAST-ACK 被动关闭方发 FIN, 等待最后 ACK
CLOSING 双方同时关闭, 收到 FIN 但未收到自己 FIN 的 ACK
CLOSED 连接完全关闭, 初始/终态
三次握手（建立连接）
Client Server(:22)
| ---------- SYN (seq=x) ------------> | Client: SYN-SENT
| <----- SYN+ACK (seq=y,ack=x+1) ----- | Server: SYN-RECV
| ---------- ACK (ack=y+1) ---------> | Client/Server: ESTABLISHED
四次挥手（释放连接）
Client Server(:22)
| ---------- FIN (seq=u) ------------> | Active: FIN-WAIT-1 / Passive: CLOSE-WAIT
| <-------- ACK (ack=u+1) ----------- | Active: FIN-WAIT-2
| <-------- FIN (seq=v) ------------ | Passive: LAST-ACK
| ---------- ACK (ack=v+1) ---------> | Active: TIME-WAIT -> 2*MSL -> CLOSED
在真实主机上观察到这些状态（实采 ss -tan）：
ecs-3e0b-0001：LISTEN 0.0.0.0:22（sshd 监听）、ESTAB 192.168.0.45:22 <-> 113.90.145.122:56689（已建立的 SSH 会话）、TIME-WAIT 127.0.0.1:29338（残留等待释放）。117.72.182.3：还出现了SYN-SENT 172.16.0.3:58256 -> 192.0.2.99:9999—— 客户端已发 SYN 但未收到 SYN+ACK，典型对端不通或被防火墙丢弃，这正是排错的关键信号。
6. Linux 网络配置：掩码/网关、netplan、nmcli/nmtui
真实主机的 netplan 配置（实采）：
120.46.70.168（renderer 为 NetworkManager）：
network:
version: 2
renderer: NetworkManager
ethernets:
eth0: { dhcp4: true }
eth1: { dhcp4: true }
# ... eth2/eth3/eth4 同理
117.72.182.3（renderer 为 systemd-networkd，由 subiquity 安装器写入）：
network:
ethernets:
eth0:
dhcp-identifier: mac
dhcp4: true
renderer: networkd
version: 2
nmcli 常用操作（在 120.46.70.168 上 nmcli device status 真实可见 eth0 connected netplan-eth0）：
nmcli device status # 查看网卡状态
nmcli connection show # 查看连接
sudo nmcli con mod eth0 ipv4.addresses 192.168.0.10/24
sudo nmcli con mod eth0 ipv4.gateway 192.168.0.1
sudo nmcli con mod eth0 ipv4.dns 8.8.8.8
sudo nmcli con mod eth0 ipv4.method manual
sudo nmcli con up eth0 # 应用配置
nmtui # 文本图形界面, 适合新手
7. 网络诊断命令：旧族 vs 新族（实跑速查表）
ifconfig/route/netstat（net-tools）已被废弃，现代标准是用 iproute2 的 ip/ss：
旧命令 (net-tools) | 新命令 (iproute2)
--------------------------+-----------------------------------------
ifconfig -a | ip address / ip -brief address
ifconfig eth0 up | ip link set eth0 up
ifconfig eth0 1.2.3.4/24 | ip address add 1.2.3.4/24 dev eth0
route -n | ip route show
route add default gw x | ip route add default via x
arp -an | ip neigh show
netstat -tunlp | ss -tunap
netstat -rn | ip route show
netstat -i | ip -s link
(无) | bridge link / ip link (网桥/VLAN)
真实 ss -tunap 输出片段（来自 117.72.182.3，体现 LISTEN / ESTAB / SYN-SENT 多状态并存）：
tcp LISTEN 0 128 0.0.0.0:5000 0.0.0.0:* users:(("python3",pid=1283997,fd=3))
tcp LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("python3",pid=1503777,fd=4))
tcp LISTEN 0 4096 0.0.0.0:13457 0.0.0.0:* users:(("atomcode",pid=1283467,fd=9))
tcp ESTAB 0 0 172.16.0.3:22 113.90.145.122:60089 users:(("sshd",pid=1551644,fd=4))
tcp SYN-SENT 0 1 172.16.0.3:58256 192.0.2.99:9999 users:(("python3",pid=1503777,fd=7))
8. 客户端工具：ping / curl / wget / lftp / ftp
连通性排错逐段定位是核心方法论。下面是真实主机的 ping 与 curl 结果（实采）：
# ping 公网 DNS (120.46.70.168)
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=104 time=235 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=104 time=235 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=104 time=226 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 225.806/232.137/235.314/4.476 ms
# curl 探测 HTTP 头 (两台主机均返回 200)
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Content-Length: 0
Content-Type: text/html
常用客户端清单：
ping -c 4 8.8.8.8 # ICMP 连通性 + RTT
curl -sI https://baidu.com # 抓取响应头(HTTP 方法探测)
wget -c https://x/y.iso # 断点续传下载 (-c)
ftp 192.168.0.1 # 交互式 FTP(明文, 公网不推荐)
lftp -u user,pass ftp://h/ # lftp 功能更强(支持 sftp/https 镜像)
9. 网卡绑定（Bonding）高可用/带宽叠加
scripts/04_bonding_config.sh 生成的 netplan 配置（实跑输出节选）：
# active-backup 主备(高可用, 最常用容错方案)
network:
version: 2
renderer: networkd
ethernets:
eth0: { dhcp4: no }
eth1: { dhcp4: no }
bonds:
bond0:
interfaces: [eth0,eth1]
addresses: ["192.168.0.45/24"]
gateway4: "192.168.0.1"
parameters:
mode: active-backup
mii-monitor-interval: 100
Bonding 模式速查：0 balance-rr（轮询/需交换机）、1 active-backup（主备/最常用）、4 802.3ad(LACP)（标准聚合/需交换机）、6 balance-alb（自适应/零交换机配置）。
应用与验证：sudo netplan apply → ip link show bond0 → cat /proc/net/bonding/bond0。
10. 真实主机全方位诊断报告
每台主机都跑了一套 16 条只读诊断（uname/ip/ss/resolv.conf/netplan/nmcli/proc/net/dev/sysctl/ping/curl），完整日志见 outputs/120.46.70.168_diag.log 与 outputs/117.72.182.3_diag.log。关键结论：
| 检查项 | 120.46.70.168 | 117.72.182.3 |
|---|---|---|
| 系统 | Ubuntu 24.04.4 | Ubuntu 22.04.3 |
| 网卡 | eth0 192.168.0.45/24 |
eth0 172.16.0.3/16 |
| 默认路由 | via 192.168.0.1 |
via 172.16.0.1 |
| DNS | 127.0.0.53(systemd-resolved) |
同左 |
转发 ip_forward |
0 |
0 |
| ping 8.8.8.8 | 3/3 0% loss | 3/3 0% loss |
| curl baidu | 200 OK | 200 OK |
| 网络管理 | NetworkManager | systemd-networkd |
两台主机
ip_forward=0符合"终端主机"身份——它们不做路由转发；若要把某台配成网关/容器宿主，需sysctl -w net.ipv4.ip_forward=1并写入/etc/sysctl.conf。
11. tcpdump 抓包实战（实跑）
“ping 通但服务连不上”“延迟偶尔飙高”“DNS 解析慢”——这类问题光看 ip/ss 不够，必须抓包看导线里到底跑了什么。tcpdump 是 Linux 排障的"显微镜"，本文在两台真实云主机上实跑。
11.1 tcpdump 表达式语法（BPF）
过滤器遵循 Berkeley Packet Filter 语法：
type dir proto addr
type : host / net / port / portrange （默认 host）
dir : src / dst / src or dst(默认) / src and dst
proto: tcp / udp / icmp / ip / arp / ether
逻辑 : and(&&) or(||) not(!) 括号需转义 \( \)
常用过滤式：
tcpdump -n 'tcp dst port 80 and src host 10.0.0.5'
tcpdump -n 'icmp and not src 127.0.0.1'
tcpdump -n 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' # 只看带 SYN/FIN 的包
tcpdump -n 'udp port 53' # DNS
tcpdump -n 'host 192.168.0.45' # 某 IP 全部流量
11.2 常用 flag
| flag | 含义 |
|---|---|
-i any |
抓所有网卡（云主机首选） |
-n / -nn |
不解析主机名 / 不解析服务名 |
-v/-vv/-vvv |
详细程度递增 |
-c N |
抓满 N 个包即停 |
-w file / -r file |
写/读 pcap 文件 |
-X |
十六进制+ASCII 同时打印（看协议字段神器） |
-tttt |
可读时间戳 |
-e |
显示 MAC 头 |
11.3 实跑①：120.46.70.168（Ubuntu 24.04）抓 ICMP + DNS
真实命令：timeout 14 tcpdump -i any -nn -c 50 -tttt '(icmp or udp port 53 or tcp port 53)'，同时后台 ping 8.8.8.8 与 ping example.com 制造流量。
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
2026-07-20 21:51:10.028267 eth0 Out IP 192.168.0.45 > 172.66.147.243: ICMP echo request, id 9378, seq 2, length 64
2026-07-20 21:51:10.051800 eth0 In IP 8.8.8.8 > 192.168.0.45: ICMP echo reply, id 9377, seq 2, length 64
2026-07-20 21:51:10.214704 eth0 In IP 172.66.147.243 > 192.168.0.45: ICMP echo reply, id 9378, seq 2, length 64
2026-07-20 21:51:10.214865 lo In IP 127.0.0.1.55226 > 127.0.0.53.53: 50133+ [1au] PTR? 243.147.66.172.in-addr.arpa. (56)
2026-07-20 21:51:10.215042 eth0 Out IP 192.168.0.45.42113 > 100.125.1.250.53: 8968+ [1au] PTR? 243.147.66.172.in-addr.arpa. (56)
2026-07-20 21:51:10.723620 eth0 In IP 100.125.1.250.53 > 192.168.0.45.42113: 8968 NXDomain 0/1/1 (118)
...
17 packets captured
20 packets received by filter
0 packets dropped by kernel
怎么读这段输出：
Out/In：出/入方向；eth0/lo：走哪块网卡（反向解析走lo到本机127.0.0.53的 systemd-resolved）。172.66.147.243是example.com经 CDN（Cloudflare）解析后的地址，ping example.com顺带触发了 DNS。PTR? ... in-addr.arpa是反向 DNS 查询（把 IP 解析成域名），发往华为云内网 DNS100.125.1.250，返回NXDomain（无记录）——这是云主机做反向解析的正常现象，不是故障。0 packets dropped by kernel：抓包无丢包，数据可信。
11.4 实跑②：抓成 pcap 再用 -X 解剖协议字段
抓取并落盘，再读回做十六进制解析（节选自 120.46.70.168）：
===== 写入 pcap 文件 =====
已保存 6 个包到 /tmp/demo.pcap
===== 用 -r 读回 + -X 十六进制/ASCII 解析 =====
21:51:26.090044 eth0 Out IP 192.168.0.45 > 8.8.8.8: ICMP echo request, id 9461, seq 3, length 64
0x0000: 4500 0054 851e 4000 4001 e4a5 c0a8 002d E..T..@.@......-
0x0010: 0808 0808 0800 2743 24f5 0003 de27 5e6a ......'C$....'^j
0x0020: 0000 0000 af5f 0100 0000 0000 1011 1213 ....._..........
逐字节拆解（这就是 OSI 第 3 层 IP 头的真实样子）：
| 偏移 | 十六进制 | 含义 |
|---|---|---|
| 0x0000 | 45 |
4=IPv4，5=首部长度 5×4=20 字节 |
| 0x0002 | 0054 |
总长度 0x54=84 字节（20 IP + 8 ICMP + 56 数据） |
| 0x0006 | 4000 |
40=TTL=64，00=协议字段占位 |
| 0x0008 | 4001 |
01=上层协议 ICMP（0x06=TCP，0x11=UDP） |
| 0x000c | c0a8 002d |
源 IP 192.168.0.45（c0=192,a8=168,00=0,2d=45） |
| 0x0010 | 0808 0808 |
目的 IP 8.8.8.8 |
| 0x0010 | 0800 |
ICMP：08=type 8 (Echo Request)，00=code 0 |
一眼看穿"网络层"传说中的 IP 头，面试被问"IP 包长什么样"直接画这张表即可。
11.5 交叉验证：117.72.182.3（Ubuntu 22.04）
同法在另一台主机实跑，IP 段不同（内网 172.16.0.3），但现象一致，证明其普遍性：
2026-07-20 21:51:39.417217 eth0 Out IP 172.16.0.3 > 172.66.147.243: ICMP echo request, id 3, seq 2, length 64
2026-07-20 21:51:39.551504 eth0 In IP 8.8.8.8 > 172.16.0.3: ICMP echo reply, id 2, seq 2, length 64
2026-07-20 21:51:39.566882 eth0 Out IP 172.16.0.3.48158 > 103.224.222.222.53: 53448+ PTR? 243.147.66.172.in-addr.arpa. (45)
2026-07-20 21:51:39.576456 eth0 In IP 169.254.169.240.53 > 172.16.0.3.35121: 896 NXDomain 0/1/0 (107)
18 packets captured
注意它把反向解析同时发给了 103.224.222.222 与链路本地 169.254.169.240（云厂商元数据/内部 DNS），再次印证"反向解析 NXDomain 是常态"。
11.6 排错实战：抓包定位"能 ping 通但服务连不上"
经典场景：服务器其实在 8080 提供 HTTP，但客户端连不上。抓包一眼见分晓：
# 服务端抓入向、非 SSH 的包
tcpdump -nn -i any 'dst 192.168.0.45 and not port 22'
# 若只看到 In 的 SYN、却看不到 Out 的 SYN-ACK → 服务没监听/被防火墙 DROP
# 若根本没有任何包 → 链路/安全组没放行，问题在网络层而非应用层
结合前文 ss -tan 看到的 SYN-SENT（第 5 章）与 TIME-WAIT，抓包 + 套接字状态是定位网络故障的黄金组合。
11.7 小结
tcpdump -i any -nn -tttt是云主机排障起手式；- 用
-c限包数、-w落盘、-r -X回放解剖； - 反向 DNS 的
NXDomain、链路本地169.254.x.x都是正常现象，别误判为故障； - 真实抓包证据：
outputs/120.46.70.168_tcpdump.log、outputs/117.72.182.3_tcpdump.log（由scripts/diag_tcpdump.py在真实主机以 root 运行生成）。
12. 源码仓库与复现方法
仓库地址（Gitee）： https://gitee.com/LiaCin/linux-networking-practice
注：Gitee 新建仓库默认 私有。如需公开，请在仓库
Settings → 基本信息中把「是否公开」改为「公开」。本博客内容本身可独立在互联网平台发表。
# 1) 克隆
git clone https://gitee.com/LiaCin/linux-networking-practice.git
cd linux-networking-practice
# 2) 本地实跑全部计算/演示脚本（无需任何外部依赖）
bash scripts/run_all.sh
# 3) 对自有云主机做只读诊断（需 Python + paramiko）
pip install paramiko
python scripts/diag_target.py # 按脚本内 HOSTS 列表修改 IP/账号
# 4) 在真实主机抓取 tcpdump 包（需 Python + paramiko，目标机需 root）
python scripts/diag_tcpdump.py # 生成 outputs/<IP>_tcpdump.log
目录结构：
linux-networking-practice/
├── 模块4-网络管理及互联网通信实战.md # 本博客
├── scripts/
│ ├── 01_subnet_calc.sh # 子网/超网计算
│ ├── 02_port_class.sh # 端口分类
│ ├── 03_tcp_states.sh # TCP 11 状态机
│ ├── 04_bonding_config.sh # bonding 配置生成
│ ├── 05_osi_model.sh # OSI 七层
│ ├── 06_route_demo.sh # 最长前缀匹配
│ ├── 07_cmd_cheatsheet.sh # 新旧命令对照
│ ├── 08_tcpdump_demo.sh # tcpdump 语法/过滤式速查
│ ├── diag_target.py # 真实主机只读采集器
│ ├── diag_tcpdump.py # 真实主机 tcpdump 抓包采集器
│ └── run_all.sh
├── outputs/
│ ├── local_demo.log # 本地实跑输出
│ ├── 08_tcpdump_demo.log # 本地 tcpdump 脚本输出
│ ├── 120.46.70.168_diag.log # 真实主机诊断
│ ├── 117.72.182.3_diag.log
│ ├── 120.46.70.168_tcpdump.log # 真实主机 tcpdump 抓包
│ └── 117.72.182.3_tcpdump.log
└── docs/
└── diag.md # 采集器使用说明
13. 面试高频考点小结
- OSI 七层 & 每层协议/设备 —— 必背。
- 子网划分与超网 —— 会给 IP/掩码算网络地址、可用范围、主机数。
- TCP 三次握手/四次挥手 & 11 状态 —— 重点理解
TIME-WAIT（2*MSL）、SYN-SENT/SYN-RECV卡住的原因（防火墙/服务未起）。 - 端口分类 —— 0-1023 特权、1024-49151 注册、49152-65535 动态。
- 路由最长前缀匹配 —— 默认路由是 /0 兜底，主机路由 /32 最优先。
- RIP/OSPF/BGP 区别 —— 距离矢量 vs 链路状态 vs 路径矢量。
ifconfig/netstat已废弃，用ip/ss—— 体现工程素养。- 排错顺序 —— link → address → route → resolv.conf → ping 网关 → ping 公网 IP → ping 域名 →
ss看端口。 - bonding 模式 ——
active-backup容错、802.3ad带宽。 ip_forward—— 网关/容器宿主必须开启。
本文所有命令输出均来自真实运行（本地
bash 5.3.9或目标云主机实采），可放心引用。第 11 章 tcpdump 抓包证据由scripts/diag_tcpdump.py在真实云主机以 root 实跑得到；如需更多主机样本或深入特定协议，欢迎在仓库提 Issue。
更多推荐
3
0- 0
已为社区贡献15条内容
所有评论(0)