8.2 抓包排错实战：一次故障的完整解剖

8.2 抓包排错实战：一次故障的完整解剖

本节摘要：排错是全册知识的毕业考试。本节以一次"用户访问内部系统偶发极慢"的真实故障为标本，完整走一遍分层定位法：从现象定义到逐层收敛，中间穿过 DNS 疑点、TCP 重传证据链与 MTU 黑洞，展示抓包阅读、工具组合与假设检验的完整方法。

急诊室开门。工具都见过（ping、traceroute、dig、抓包工具、netstat），这一节把它们组织成方法。排错的本质是收敛：从"现象"出发，用最小代价的检验把可能性空间砍半、再砍半，直到锁定"点"。

一、方法论：现象、分层、假设、证据

排错四步循环（全册工具的座次表）：

1. 定义现象：谁、访问什么、什么时候、必现还是偶发、
   "慢"是几秒（不定义清楚就没法度量）
2. 分层缩圈（1.2 的地图）：链路通吗（ping 网关）→
   DNS 对吗（dig）→ 路通吗（traceroute）→
   传输好吗（端口握手+重传统计）→ 应用层正常吗
3. 提出假设：一次只验一个，设计最小实验
4. 取证定罪：抓包是终审法庭——一切推断最后都要在
   包序列里找到物证

反模式（每个都来自真实教训）：
× 同时改三个配置看"好了没"——好了也不知道是谁的功
× 跳过分层直接重启——现象消失证据也消失，下周复发
× 只看设备日志不看包——日志说的是设备以为的，包才是事实
​

二、标本解剖：一次"偶发极慢"的完整排查

背景：某工作日上午起，员工反馈访问内部订单系统偶发卡 5~10 秒，刷新后正常。服务器 CPU、内存正常。

第一轮：定义现象。 抓取页面加载 waterfall——大部分请求毫秒级完成，个别请求卡在"初始连接"阶段 5 秒后成功。结论：不是传输慢（下载不慢），是连接建立阶段偶发超时。范围立即缩小到 TCP 握手或 DNS。

第二轮：分流两个假设。

# 假设 A：DNS 慢？
$ dig order.internal.corp +stats    （在故障复现窗口连测 50 次）
;; Query time: 0~1 msec ×50        ← 本地缓存全命中，排除

# 假设 B：握手/重传问题？看系统统计：
$ netstat -s | grep -i retrans
    9 segments retransmitted         ← 开机以来总数，太少
$ nstat -az | grep -i retrans        （换增量工具，每分钟采样）
    TcpRetransSegs  412   +412/分钟  ← 增量惊人！

结论：重传每分钟四百段——假设 B 成立，进入第三轮。
​

第三轮：抓包找重传模式。 在客户端与服务器同时抓，过滤重传：

# 过滤 tcp.analysis.retransmission，典型片段：

No. Time   Src            Dst          Info
141 10.1.0.23 → 10.1.4.80  [TCP ACKed unseen segment]
142 10.1.4.80 → 10.1.0.23  [TCP Window Update]
158 10.1.0.23 → 10.1.4.80  [Retransmission] seq=8192
160 10.1.4.80 → 10.1.0.23  [Dup ACK] ack=8192
173 10.1.0.23 → 10.1.4.80  [Retransmission] seq=16384

关键物证：两端都重传 + 出现 "ACKed unseen segment"
（对方确认了我没发出的段？！）——这是典型的
**非对称路径或中间设备复制/乱序**签名。
且两端各自抓到的同号包不同：有包只在一侧出现。

第四轮：缩小到链路。两端在同一 VLAN（第 3 章的地盘），
排查交换机：
Switch# show interfaces counters errors
Port      CRC     align    overrun
Gi0/12    1834    0        0            ← CRC 错！
Gi0/13    0       0        0

CRC 错 = 帧在物理层被损坏（2.1 的噪声、3.1 的校验丢弃）。
损坏的帧被丢弃 → TCP 层表现为丢失 → 重传；
重传恰好集中在握手小包（一次重传 RTO 起步就是 1 秒起、
指数退避，对"连接建立"体验放大成 5~10 秒卡顿）。

根源：Gi0/12 口的光模块老化，误码率随上午温度升高恶化。
换模块，重传增量归零，故障消失。

复盘变式：同样的"偶发 5~10 秒"症状家族——
若重传集中在特定大小的包：MTU 黑洞（4.2 的分片+丢弃），
处置是开路径 MTU 发现；
若 Dup ACK 三连成串但无 CRC 错：真拥塞（5.3），
去看接口利用率与队列；
若只在跨网段出现：中间路径问题，traceroute 定位到跳。
同一个症状，四种病理，证据链各不相同。
​

图：分层定位法的收敛路径

三、三条最常用的故障签名

把全册散落的签名集中备查：

签名一：连不上
  SYN 反复重传无应答 → 半路被丢或服务器不回
  （查防火墙与队列：5.2 与 7.3 的交叉点）
  SYN 有来有回、ACK 后立刻 RST → 端口没开或被拒
  握手全通、发请求后 RST → 应用层拒绝（认证、限流）

签名二：慢
  重传 + Dup ACK 成串 → 丢包（再分流：CRC 错=物理、
  利用率满=拥塞、特定包大小=MTU）
  窗口极小（win < MSS）→ 接收方处理不过来（5.3 流控）
  DNS 首查几百毫秒 → 缓存未命中或上游慢（6.1）

签名三：时好时坏
  交替解析到新旧 IP → DNS TTL 未到期（6.1 案例）
  双路径一好一坏 → 非对称路由（本节标本的变种）
  特定时段恶化 → 拥塞高峰或温度敏感的硬件劣化
​

💡 关键直觉：证据的"反常细节"比正常输出有用十倍。"确认了未见段"这行初看不起眼的告警，正是把排查从传输层推向链路层的转折点——排错高手的差别，就在于对这些反常的敏感度。

本节要点回顾

• 四步循环：定义现象、分层缩圈、单假设检验、抓包定罪
• 增量思维：用增量工具看重传，开机以来的总数毫无诊断价值
• 签名库：连不上、慢、时好时坏三大族，各自对应固定证据链
• 反常敏感：unseen segment、win 极小这类异常行是破案转折点
• 反模式清单：多变量齐改、无脑重启、只看日志不看包——都是证据毁灭者

最后一节望向新航路——当网络的管理与转发开始分离，SDN 与云正在改写游戏规则。