网络排查与可观测性：从 ping 到 eBPF

0. 元信息

• 主题路径：docs/topics/network/subtopics/network-troubleshooting/
• 父主题：network
• 主分类：计算机基础
• 辅助分类：工程技术
• 适合对象：会用 curl、ping、会看 TCP 握手三次报文的开发者，想系统性排查网络问题的人
• 建议周期：3～4 周（每周 6～8 小时，含命令行练习、eBPF 脚本、案例复盘）
• 前置知识：tcp-ip-stack、tcp-and-udp、dns-and-naming、packet-analysis
• 最终目标：拿到一个网络问题能用 ping → mtr → ss → tcpdump → bpftrace 逐级下钻定位，能写一个 bpftrace 脚本观测内核 TCP 事件

1. 学习路线

分层排查方法论
  → ping / mtr / traceroute：连通性与路径
  → dig / nslookup / getent：DNS 解析
  → ss / netstat / lsof / ip：本地 socket 与路由表
  → curl / httpie / openssl s_client：应用层握手
  → tcpdump / Wireshark：包证据
  → conntrack / iptables / nft：NAT 与防火墙
  → perf / bpftrace / BCC：内核与可观测性
  → 综合案例：从告警到根因

每一步先想清楚“在哪一层、问什么、用哪个工具”。工具要随手能写命令，不靠搜。

2. 阶段周数分配

3. 九阶段表

4. 第一周任务

Day 7 拆解

步骤 A —— 最小可用（60 分钟）

1. 选一个目标（如 https://example.com）；
2. 用 time curl -o /dev/null -s -w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' https://example.com 拿到分段时间；
3. 用 dig +short example.com 拿 DNS 结果，用 ping -c 5 测 RTT；
4. 用 mtr -r -c 30 example.com 出报告；
5. 用 ss -tin '( dport = :443 )' 看完毕连接 RTT、重传、cwnd；
6. 把命令和输出贴到一个 markdown 报告里。

步骤 B —— 补齐四类边界（45 分钟）

• DNS 失败：用 dig +trace 看到底卡在哪一层；
• TCP 半连接：ss -tan state syn-recv 看是否有 SYN 队列溢出；
• TLS 慢：抓 ClientHello → ServerHello → Finished 各段时间；
• 防火墙丢包：抓包看到 SYN 无 SYN-ACK，再 iptables -L -nv 查 REJECT/DROP 计数。

5. 阶段通用验收

1. 不看笔记写出 15 条常用排查命令；
2. 能从 mtr 报告区分“本机丢包 vs 运营商丢包 vs 目标丢包”；
3. 能用 ss -tin 看到 RTT、重传、cwnd、拥塞状态；
4. 能写一个 bpftrace 单行脚本追踪 tcp_connect、tcp_sendmsg、netif_receive_skb；
5. 至少复现 3 类故障（DNS 慢、连接超时、TLS 握手失败）并给出证据；
6. 知道 conntrack 表满、nf_conntrack 限制、offload 对观测的影响；
7. 能把命令贴进笔记，第二天还能复现。

6. 最终验收

• 独立完成一次端到端排障：从用户报告“慢”→给出分段耗时→mtr 路径→ss 本地状态→tcpdump 包证据→bpftrace 内核事件，每一步贴命令和输出；
• 写出并验证至少 20 条 ss/mtr/curl/dig 命令；
• 至少分析 6 个案例：DNS 慢解析、TCP SYN 队列溢出、TLS 1.2 vs 1.3 握手差异、连接被防火墙 REJECT、conntrack 表满丢包、NIC offload 导致 RTT 偏低；
• 写出一个能跑的 bpftrace 脚本（追踪 tcp_connect 或 tcp_retransmit_skb）；
• 完成 1 个综合项目，交付排障报告、命令清单、pcap、复盘；
• 用 15 分钟讲清“从告警到根因”的下钻路径。

7. 综合项目

首选：一次线上“服务偶发 504”复盘。用本地 docker 起一个 HTTP 服务，模拟至少三种故障（DNS 慢解析、TCP 队列满、TLS 握手慢），逐个定位并给出证据。

备选：Kubernetes Pod 间偶发连接超时 / 公网 API 抖动复盘 / 视频流卡顿端到端分析。

项目必做要求：

1. 场景说明：拓扑、IP、节点、抓包点、时间同步；
2. 现象：用户报告、监控曲线、错误日志；
3. 分段耗时：DNS / TCP / TLS / 首字节 / 总耗时；
4. 命令清单：每一步用到的 mtr / dig / ss / tcpdump / bpftrace 命令；
5. 证据文件：pcap、bpftrace 输出、ss 截图；
6. 根因分析：哪一层、为什么、怎么验证；
7. 修复与预防：短期 workaround、长期方案、可观测性补强；
8. 复盘报告：用 5 段法（现象→定位→根因→修复→预防）输出 markdown。

本主题贡献

本主题沉淀分层下钻排障：从 ping/mtr → dig/getent → ss/curl → tcpdump → bpftrace 逐级穿透，每一步都能从「现象→假设→验证」走完整 RCA，所有命令贴进 README 第二天还能复现。

职责（3 项）

1. 用 mtr -r -c 30 + ping -c 区分丢包来自本机、运营商、目标，能解释为什么某跳高 Loss 不可信（后续跳 Loss 才算真实丢包）、为什么 ICMP 在运营商侧可能被限速；
2. 用 ss -tnap / ss -tin 看本地 socket 状态（LISTEN/ESTABLISHED/TIME_WAIT/SYN_RECV）、cwnd/rwnd/rtt/retrans、/proc/net/tcp 验证，能定位 TCP 半开连接与 SYN 队列溢出；
3. 写 bpftrace 单行脚本追踪 tcp_connect / tcp_sendmsg / tcp_retransmit_skb / netif_receive_skb，能在内核侧观测 conntrack 表满、qdisc 丢包、NIC offload 影响。

交付物（4 项）

1. 5 段法（现象→定位→根因→修复→预防）故障复盘报告（线上 504 / 服务慢 / 公网 API 抖动任一真实复现）；
2. 至少 20 条 ss / mtr / curl / dig / openssl s_client 命令清单（带 BPF filter：ss -tin '( sport = :443 )'）；
3. 一个能跑的 bpftrace 脚本（bpftrace -e 'kprobe:tcp_connect { printf("pid=%d comm=%s\n", pid, comm); }'）+ BCC 工具集（tcpconnect、tcpretrans）输出；
4. conntrack 监控（conntrack -L | wc -l、nf_conntrack_max）与 NAT MASQUERADE 链规则定位报告。

指标（3 项）

1. MTTR ≤ 30 分钟（从用户报告到定位根因）；
2. 排障定位 hop 数 ≤ 5（mtr 跳点 + ss 状态 + tcpdump 包证据联合判定）；
3. bpftrace 事件吞吐量 ≥ 1k events/s 不丢（高并发场景验证 -d debug 输出）。

8. 推荐开源资料

mtr、traceroute、bpftrace 均为开源工具，LICENSE 多为 GPL/BSD，引用前先看仓库 LICENSE。

9. 学习资料汇聚（v0.3 自包含）

本节由本计划生成。工具行为以官方手册、内核文档和实际样本为准。

9.1 背景与动机

网络问题常出现在三层：用户态（应用、DNS）、内核态（socket、conntrack、qdisc）、链路上（运营商、对端）。日志只看到一端的状态；mtr 看路径，ss 看本地 socket，tcpdump 看线上包，bpftrace 看内核事件。这四件事串起来才能完整还原链路。

Mike Muuss 写 ping 是 1983 年，Bug 报告里说“想测路径上的 RTT”。Van Jacobson 在 80 年代末写了 traceroute，原理是操纵 TTL 引发 ICMP Time Exceeded。Matt Kimball 1997 年写了基于 ICMP+UDP 的 mtr（Matt’s Traceroute），沿用至今。bpftrace 是 2017 年前后 Alastair Robertson、Brendan Gregg 等人在 BCC 之上做的高层前端，把 kprobe/tracepoint 包成 awk 风格。Linux 内核的 BPF 子系统从 2014 年起快速演进，是当代可观测性的基础设施。

排查网络问题需要逐层假设、逐层验证。工具会撒谎（mtu/ttl/conntrack/时钟），证据链必须能复现。

9.2 概念地图

flowchart LR
  App[应用层 HTTP/gRPC/DB] --> Socket[用户态 socket]
  Socket --> Conntrack[conntrack 表]
  Conntrack --> TC[TC qdisc]
  TC --> NIC[NIC driver]
  NIC --> Wire[物理链路]
  Wire --> Net[运营商 / 交换机]
  Net --> Peer[对端 socket]
  Peer --> PeerApp[对端应用]
  Ping[ping/mtr] --> ICMP[ICMP 探测]
  ICMP --> Net
  SS[ss/netstat] --> Socket
  Dig[dig/getent] --> DNS[DNS 解析链路]
  DNS --> Resolver[本地 resolver]
  Tcpdump[tcpdump] --> Wire
  Bpf[bpftrace/perf] --> Kernel[内核 kprobe/tracepoint]
  Kernel --> Socket
  Kernel --> Conntrack
  Kernel --> NIC

ICMP 探测看“链路通不通”，DNS 工具看“名字解不解”，ss 看“本地状态对不对”，tcpdump 看“线上包是什么样”，bpftrace 看“内核做了什么决定”。

9.3 基础知识讲解

经典论文 / RFC

经典书籍

优秀博客

核心人物

开发方法

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• ping/mtr/traceroute：基于 ICMP（部分用 UDP）探测路径与延迟。它们只能告诉你“探测包是否到、是否回”；探测包可能被运营商降速或过滤。
• dig/getent/host：DNS 解析工具。dig 直接走 resolver；getent hosts 走 nsswitch，会展示 /etc/hosts 与 DNS。
• ss/netstat：查看本地 socket 表。ss 比 netstat 快、信息全，支持 BPF filter 风格过滤。
• curl/openssl：应用层验证工具，能拆解 HTTP 状态、TLS 握手、证书链。
• tcpdump/tshark：抓包与解码（详见 §packet-analysis）。
• conntrack/nft/iptables：NAT 与防火墙状态。
• bpftrace/perf/BCC：内核可观测性。bpftrace 是单行脚本前端；BCC 是 Python+C 工具集；perf 是采样与 tracepoint。
• 关系：自下而上分层使用，前一层给后一层提供假设，后一层给前一层提供验证。

9.6.3 Structure

• mtr 报告模式：mtr -r -c N target 生成文本报告，关键字段：Loss%、Snt、Last、Avg、Best、Wrst、StDev。
• ss 常用语法：
  • ss -tnap：所有 TCP socket，进程与扩展信息；
  • ss -tin：显示 TCP 内部信息（cwnd、rtt、retrans）；
  • ss -tan state syn-recv：按状态过滤；
  • BPF filter：ss -tin '( sport = :443 )'。
• dig 常用：dig +short name、dig +trace name、dig @server name TYPE。
• curl 常用：curl -v、curl -w '%{time_namelookup} %{time_connect} ...' -o /dev/null、curl --http2。
• openssl s_client：openssl s_client -connect host:443 -tlsextdebug -servername host。
• bpftrace 单行：bpftrace -e 'kprobe:tcp_connect { printf("%s -> %s\n", comm, arg2); }'。
• conntrack：conntrack -L、conntrack -E、sysctl net.netfilter.nf_conntrack_max。

真实命令样例：

# mtr 报告 30 次
mtr -r -c 30 8.8.8.8

# ss 看本机到 :443 的连接 RTT / 重传 / cwnd
ss -tin '( sport = :443 )'

# DNS 解析链路
dig +trace example.com

# 应用层分段时间
curl -o /dev/null -s -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com

# 抓包
tcpdump -i any -nn -s 0 -w /tmp/c.pcap tcp port 443

# bpftrace 追踪 TCP 连接发起
sudo bpftrace -e 'kprobe:tcp_connect { printf("pid=%d comm=%s dest=%s\n", pid, comm, arg2); }'

9.6.4 Ecosystem

• 连通性工具：ping、mtr、traceroute、fping、nping、hping3；
• DNS 工具：dig、nslookup、host、drill、dog、getent；
• 本地 socket / 路由：ss、netstat、lsof、ip、ifconfig、arp、route；
• 应用层：curl、wget、openssl s_client、httpie、grpcurl；
• 抓包 / 解码：tcpdump、tshark、Wireshark、Zeek（详见 §packet-analysis）；
• 防火墙 / NAT：iptables、nft、ip6tables、ufw、firewalld、conntrack；
• 内核可观测性：bpftrace、BCC（tcpconnect、tcpretrans、tcpaccept、tcpdrop）、perf、ftrace、SystemTap、sysdig/Falco；
• 高级 / 商业：Wireshark + Cloudshark、Pixie、Ultraviolet、NetBox（资源库）；
• 事实标准：mtr 报告是社区通用的延迟证据格式；ss 几乎完全替代 netstat；bpftrace 已成为 Linux 内核可观测性首选前端之一。

9.6.5 Depth Tiers

本计划要求达到：L3。做 SRE/网络平台/性能工程师时进入 L4。

9.6.6 Source

• mtr 手册：https://github.com/traviscross/mtr
• ss(8) 手册：https://www.man7.org/linux/man-pages/man8/ss.8.html
• dig(1) 手册：https://manpages.ubuntu.com/manpages/jammy/man1/dig.1.html
• curl 文档：https://curl.se/docs/
• OpenSSL s_client：https://docs.openssl.org/3.0/man1/openssl-s_client/
• BPF 内核文档：https://docs.kernel.org/bpf/
• bpftrace 参考：https://github.com/bpftrace/bpftrace/blob/master/docs/reference_guide.md
• BCC 工具集：https://github.com/iovisor/bcc
• Brendan Gregg Linux Performance：http://www.brendangregg.com/linuxperf.html
• 引用的版本快照日期：2026-07-30。

10. 常见误区

• 把 ICMP 探测当成业务可用性证据：ICMP 在运营商侧可能限速或过滤；
• 用 ping localhost 测网卡不出问题就以为没问题：很多问题在协议栈或更上层；
• 不写时间戳、不记命令版本，复现时才发现环境变了；
• 把 ss 的 TIME_WAIT 多当 bug：TIME_WAIT 是 TCP 正常状态，关键是数量与变化率；
• 把 mtr 报告的某跳高 Loss 当成那跳丢包：后续跳 Loss 才算“真实丢包”；
• 在生产长时间无过滤抓全量，耗尽磁盘并收集敏感数据；
• 用 curl 失败就断网：可能只是 TLS 证书或 HTTP/2 问题；
• 不看 conntrack 表满的情况，连接被 NAT 默默丢；
• 忽略 NIC offload（TSO/LSO/GRO）让 RTT 看着偏低；
• bpftrace 报错就放弃，没有先看内核版本和 BPF 支持；
• 把排查命令贴在 IM 聊天里，不写进文档，第二天找不到；
• 在容器/Pod 里看不到主机网络，忘了用 nsenter 或抓 cni 网桥；
• 用单一端点的抓包做结论，没考虑中间设备的 RST/限速；
• 把“重启服务”当成修复，没有给出根因和预防措施。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础：ICMP、TCP/IP、DNS、conntrack、路由、内核网络栈
4. 工程技术：ping/mtr/ss/curl/tcpdump/bpftrace、故障复盘流程
5. Web 与后端：HTTP/TLS 握手、TLS 排障
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力：RCA、复盘、协作交接、可观测性
9. 安全与可靠性：防火墙、conntrack、offload、内核可观测性

本计划归属：计算机基础 主 + 工程技术 辅。