网络学习路径：从分层模型、DNS 到 TCP/TLS、抓包与 K8s 网络

使用方式

这条路径解决“ping 不通就重启网卡、超时就怪网络抖动”的问题：把连通性拆成链路、IP、路由、DNS、TCP、TLS 和 K8s 转发逐层验证。适合后端开发、SRE、以及需要处理线上网络问题的运维工程师。

前置知识：会用 Linux 命令行，知道 IP 地址、端口、网关和 DNS 的基本概念。四个阶段按依赖排序，每阶段建议 2–3 小时；实验在虚拟机、一次性容器或 kind 集群里做。

• 先读：按顺序读，先建立分层顺序，再看每个命令能证明哪一层。
• 再做：每阶段至少完成一次“先假设、再验证、后回滚”的检查。
• 后测：只看现象，能说出下一层该查什么、用哪条命令。

抓包可能包含凭据、Cookie 和个人数据；改路由、防火墙、MTU 或 CNI 可能直接断网。所有破坏性操作只允许在测试环境执行，并事先准备回滚命令。

阶段一：分层模型与 IP、路由、端口

目标：能把“连不上”拆成链路、IP、路由和端口四层，并用命令确认每一层的状态。

阅读顺序：

1. network-stack — Linux 网络栈从网卡到 socket 的路径。
2. ip — 地址、路由、链路和邻居表，替代旧的 ifconfig。
3. ss — 监听、连接、socket 队列和进程信息。
4. ping — ICMP 连通性和 RTT，不负责验证端口。
5. arp — 同网段 MAC 解析和邻居异常。
6. ethtool — 网卡速率、双工、丢包和驱动统计。
7. netstat — 旧工具仍常见，理解与 ss 的字段对应。
8. ipcalc — 快速判断网段、掩码、广播地址和可用主机数。
9. route — 旧路由命令，理解默认网关和路由优先级。
10. network-troubleshooting-cheatsheet — 先建立分层检查表。

动手任务：在 Linux 虚拟机或带网络工具的容器里检查地址、路由、监听端口，并起一个本地 HTTP 服务确认监听。环境必须是本机测试机；风险是修改 IP 或默认路由会让你从 SSH 断开，本任务只读不改。

ip -br addr
ip route
ss -lntp
ping -c 3 127.0.0.1
ethtool eth0 2>/dev/null | head -20
python3 -m http.server 8080 &
ss -lntp | grep 8080
kill %1

过关标准：

• 能根据 ip route 判断一个目标地址走哪条路由、下一跳是谁。
• 能区分 ss 中 LISTEN、ESTABLISHED、TIME_WAIT 和 SYN-SENT 的含义。
• 能解释同网段通信为什么需要 ARP，跨网段为什么必须经过网关。
• 能在不知道端口的情况下用 ss -lntp 找到监听进程。

阶段二：DNS 与路径诊断

目标：能区分解析失败、解析慢、连不上和路径不通，并定位到具体 DNS 服务器或中间跳。

阅读顺序：

1. dig — 查询记录、指定 DNS、看递归与权威应答。
2. nslookup — 快速查询和交互模式。
3. host — 简洁查询和反向解析。
4. getent — 走系统 NSS 路径，验证应用实际拿到的解析结果。
5. resolvectl — systemd-resolved 的链路、缓存和 DNSSEC 状态。
6. traceroute — 逐跳路径和超时位置。
7. mtr — 持续探测，区分偶发丢包和固定节点故障。
8. nc — TCP/UDP 端口连通性和简单监听。
9. dns-resolution-failed — 解析失败的排查顺序。
10. connection-refused — 有 RST 时的端口与服务检查。

动手任务：对比公共 DNS 与系统解析结果，用 getent 验证应用路径，再用 mtr 和 nc 检查目标端口。环境是本机测试机；风险是外部 DNS 查询会泄露访问域名，mtr 可能被限速，端口探测只能针对你拥有或获授权的目标。

dig example.com +short
dig @1.1.1.1 example.com +short
getent hosts example.com
resolvectl status 2>/dev/null | head -20
mtr -rwc 20 example.com
nc -vz -w 3 example.com 443

过关标准：

• 能解释 dig 成功但应用解析失败的可能原因：NSS、resolv.conf、缓存或搜索域。
• 能区分 NXDOMAIN、SERVFAIL 和查询超时分别说明什么。
• 能根据 mtr 丢包出现在哪一跳，判断问题在本地、运营商还是目标侧。
• 知道 nc -vz 成功只代表 TCP 握手成功，不代表 TLS 和 HTTP 正常。

阶段三：TCP、TLS 与抓包

目标：能用握手、重传、MTU 和 TLS 告警判断问题在传输层还是应用层，并用抓包验证判断。

阅读顺序：

1. tcpdump — 过滤器、抓包点、-w 保存和回读。
2. ngrep — 按内容匹配 HTTP/TCP 载荷。
3. tshark — 命令行解析 pcap，统计重传和握手。
4. curl — 分阶段耗时、HTTP 状态和 TLS 信息。
5. openssl — s_client 验证证书链、协议和 SNI。
6. socat — 构造 TCP/TLS 连接和端口转发。
7. conntrack — 连接跟踪表、NAT 和内核丢包。
8. tcp-retransmit — 重传率、RTT 和拥塞窗口。
9. tls-handshake-failed — 证书、协议和时钟问题。
10. mtu-issue — 小包通、大包断的排查。

动手任务：在本机回环地址起一个自签名 TLS 服务，用 curl、s_client 和 tcpdump 分别验证握手与证书。环境是本机测试机，证书只用于本次实验；风险是自签名证书不能用于生产，抓包可能捕获敏感内容，过滤器要限定端口和数量，实验结束删除 pcap。

mkdir -p /tmp/net-lab
openssl req -x509 -newkey rsa:2048 -nodes -keyout /tmp/net-lab/lab.key -out /tmp/net-lab/lab.crt -days 1 -subj '/CN=lab.local'
openssl s_server -accept 8443 -cert /tmp/net-lab/lab.crt -key /tmp/net-lab/lab.key -www &
curl -vk --max-time 3 https://127.0.0.1:8443/
openssl s_client -connect 127.0.0.1:8443 -servername lab.local </dev/null
tcpdump -ni lo 'tcp port 8443' -c 20
kill %1

过关标准：

• 能用 curl 的 time_namelookup、time_connect、time_appconnect、time_total 分段定位。
• 能判断 TLS 握手失败是证书过期、域名不匹配、协议不兼容还是时钟偏差。
• 能解释 TCP 重传与 MTU 黑洞的关系，并用 ping -M do 验证。
• 能写出一条只抓目标端口、限定数量的 tcpdump 过滤器，并说明抓包点在哪。

阶段四：K8s 网络与生产排查

目标：能把 Pod 网络问题映射到 CNI、CoreDNS、kube-proxy、NetworkPolicy 和抓包点。

阅读顺序：

1. cni — CNI 的职责和 Pod 网络创建流程。
2. coredns — 集群 DNS 的 Service、ConfigMap 和缓存。
3. calico — BGP/iptables 数据面和 NetworkPolicy。
4. cilium — eBPF 数据面、Hubble 和策略执行。
5. kube-proxy — Service 转发的 iptables/IPVS 模式。
6. hubble — 网络流可观测性，定位丢包和拒绝。
7. dns-troubleshooting — K8s DNS 的分层排查。
8. network-troubleshooting — 集群网络问题的检查顺序。
9. networkpolicy — 默认拒绝与显式放行。
10. k8s-dns-failed — CoreDNS、ndots 和 resolv.conf 故障。

动手任务：用 kind 起一个本地集群，运行带网络工具的 Pod，验证 Service DNS、Endpoints 和 CoreDNS 日志。环境是独立 kind 集群；风险是 netshoot 工具权限较大，不要在生产节点或共享集群运行，实验后删除整个集群。

kind create cluster --name netlab
kubectl run client --image=nicolaka/netshoot:v0.13 --restart=Never -- sleep 3600
kubectl wait --for=condition=Ready pod/client --timeout=90s
kubectl exec client -- dig kubernetes.default.svc.cluster.local +short
kubectl get svc,endpoints,endpointslices -A | head -30
kubectl -n kube-system logs -l k8s-app=kube-dns --tail=20
kind delete cluster --name netlab

过关标准：

• 能按 Pod → Service → Endpoints → CoreDNS → CNI 的顺序排查集群内访问失败。
• 能解释 ClusterIP、NodePort、LoadBalancer 和 Ingress 各自工作在哪一层。
• 能区分 NetworkPolicy 拒绝和 DNS 解析失败的现象与日志差异。
• 能在 Pod 内和节点上各选一个抓包点，并说明各自能看到什么、看不到什么。

常见误区

• ping 通就说明服务正常：ICMP 只证明网络层，端口、TLS 和 HTTP 仍可能失败。
• DNS 解析成功就说明网络通：解析成功只证明拿到了地址，TCP 仍可能被拒绝或超时。
• 抓不到包就是没有流量：可能抓错网卡、命名空间、方向或端口，先确认抓包点。
• 延迟高就是带宽不足：先看 RTT、重传、排队、MTU 和中间设备，而不是直接扩容。
• K8s 网络问题先重启 CNI：先确认 Pod、Service、Endpoints、策略和 DNS，再动数据面。
• 生产改路由或防火墙不需要回滚计划：远程操作可能立即断连，必须准备带外通道。
• 端口能连上就认为应用正常：TCP 握手成功只完成传输层，业务可能返回 500 或超时。

读完自测

合上页面，先回答，再展开对照。

1. curl 卡住不返回，如何用四个时间指标和抓包判断卡在 DNS、TCP、TLS 还是 HTTP？
2. 同网段能通、跨网段不通，先查什么？
3. Pod 内域名解析失败，但节点上 dig 正常，可能是什么原因？

相关条目

• network-troubleshooting-cheatsheet — 网络分层速查
• tcpdump-cheatsheet — 抓包过滤器速查
• openssl-cheatsheet — TLS 与证书速查
• curl-cheatsheet — HTTP 请求速查
• troubleshoot-mental-model — 排障心智模型
• linux-learning-path — Linux 学习路径