企业官网建设流程全解析

模块4：网络管理及互联网通信实战

面向 Linux 云计算工程师的面试/实战进阶笔记。本篇全部示例均可运行，关键结论均来自对真实云主机的实连采集（非虚构）。配套源码已开源，文末附仓库地址与复现方法。

0. 实验环境与开篇说明

本篇所有"真实主机"数据均来自以下实际环境（已获授权实操）：

计算类示例（子网运算、端口分类、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》，适合在互联网平台发表。

使用工具：

数据采集脚本scripts/diag_target.py仅执行16 条只读诊断命令（见源码），不会改动目标主机任何配置。

2. OSI 七层模型

网络排查的第一性原理：每一层只解决一类问题。自上而下：

封装过程（发送方逐层加头，接收方逐层解头）：

应用数据 -> [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

动态路由协议对比（面试常考三剑客）：

云主机由 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:2renderer:NetworkManagerethernets:eth0:{dhcp4:true}eth1:{dhcp4:true}# ... eth2/eth3/eth4 同理

117.72.182.3（renderer 为 systemd-networkd，由 subiquity 安装器写入）：

network:ethernets:eth0:dhcp-identifier:macdhcp4:truerenderer:networkdversion:2

nmcli常用操作（在120.46.70.168上nmcli device status真实可见eth0 connected netplan-eth0）：

nmcli device status# 查看网卡状态nmcli connection show# 查看连接sudonmcli con mod eth0 ipv4.addresses192.168.0.10/24sudonmcli con mod eth0 ipv4.gateway192.168.0.1sudonmcli con mod eth0 ipv4.dns8.8.8.8sudonmcli con mod eth0 ipv4.method manualsudonmcli 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-c48.8.8.8# ICMP 连通性 + RTTcurl-sIhttps://baidu.com# 抓取响应头(HTTP 方法探测)wget-chttps://x/y.iso# 断点续传下载 (-c)ftp192.168.0.1# 交互式 FTP(明文, 公网不推荐)lftp-uuser,pass ftp://h/# lftp 功能更强(支持 sftp/https 镜像)

9. 网卡绑定（Bonding）高可用/带宽叠加

scripts/04_bonding_config.sh生成的 netplan 配置（实跑输出节选）：

# active-backup 主备(高可用, 最常用容错方案)network:version:2renderer:networkdethernets: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-backupmii-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。关键结论：

两台主机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'# DNStcpdump-n'host 192.168.0.45'# 某 IP 全部流量

11.2 常用 flag

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 头的真实样子）：

一眼看穿"网络层"传说中的 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-iany'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) 克隆gitclone https://gitee.com/LiaCin/linux-networking-practice.gitcdlinux-networking-practice# 2) 本地实跑全部计算/演示脚本（无需任何外部依赖）bashscripts/run_all.sh# 3) 对自有云主机做只读诊断（需 Python + paramiko）pipinstallparamiko 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. 面试高频考点小结

1. OSI 七层 & 每层协议/设备—— 必背。
2. 子网划分与超网—— 会给 IP/掩码算网络地址、可用范围、主机数。
3. TCP 三次握手/四次挥手 & 11 状态—— 重点理解TIME-WAIT（2*MSL）、SYN-SENT/SYN-RECV卡住的原因（防火墙/服务未起）。
4. 端口分类—— 0-1023 特权、1024-49151 注册、49152-65535 动态。
5. 路由最长前缀匹配—— 默认路由是 /0 兜底，主机路由 /32 最优先。
6. RIP/OSPF/BGP 区别—— 距离矢量 vs 链路状态 vs 路径矢量。
7. ifconfig/netstat已废弃，用ip/ss—— 体现工程素养。
8. 排错顺序—— link → address → route → resolv.conf → ping 网关 → ping 公网 IP → ping 域名 →ss看端口。
9. bonding 模式——active-backup容错、802.3ad带宽。
10. ip_forward—— 网关/容器宿主必须开启。

本文所有命令输出均来自真实运行（本地bash 5.3.9或目标云主机实采），可放心引用。第 11 章 tcpdump 抓包证据由scripts/diag_tcpdump.py在真实云主机以 root 实跑得到；如需更多主机样本或深入特定协议，欢迎在仓库提 Issue。