8.3 故障排查模式库：六类高频故障的判定路径
8.3 故障排查模式库：六类高频故障的判定路径
全书的落点在这里：把第 4 章的字段知识、第 5 章的筛法、第 8.1 节的仪器，收束成六类高频故障的判定路径。每条路径按"现场长相—判定步骤—常见误判"三段展开。这张模式库的价值在于压缩时间：别人从零摸索两小时的案子，你按路径十分钟走到结论。
模式一：重传风暴
现场长相：tcp.analysis.flags 大面积命中，IO 图上重传曲线与流量曲线纠缠。
判定步骤：先看方向（-e ip.src 聚合，重传集中在哪侧）；再看时间分布（集中爆发还是全程弥散）；最后看伴随现象（有无乱序、重复确认同现）。三步各排除一批嫌疑。
分叉判定：重传伴随大量"重复确认"且乱序帧多——接收端乱序（路径不等价负载均衡的典型病）；重传干干净净、纯粹超时驱动——真丢包（链路质量或拥塞）。误判高发：把接收端乱序当丢包去换线路，方向就错了；乱序的现场特征是"重复确认紧跟着正常到达的原帧"。
模式二：零窗口与窗口骤降
现场长相：tcp.window_size == 0 命中成串，发送方每几秒一个窗口探测脉冲（纯一字节段）。
判定步骤：确认是谁在通告零（接收端是谁）；看持续时长与恢复方式；查接收端应用（读缓冲不消费的进程）。窗口骤降（从六万级跌到几百）同理，只是程度轻。
误判高发：把零窗口当网络丢包处理。4.2 节讲过，零窗口是"对端收不动"——病在接收应用的消费速度，网络再好也没用。方向反了，一切白干。
模式三：RST 断连
现场长相：数据流中途突现 RST，通常伴随应用侧"连接被重置"报错。
判定步骤：4.2 节的三步归因——看 RST 前一帧（SYN 后即 RST 是端口未开；数据中途 RST 是进程问题）、看时机（即时或延迟）、看 ICMP 伴随（有则是中间设备代答）。三步走完，锅基本能扣对。
误判高发：一见 RST 就说"防火墙拦了"。实际上端口未开与进程崩溃才是多数；把判定压缩成一步，是这一模式的经典翻车点。
模式四：DNS 失败
现场长相：dns.flags.rcode > 0 命中，或会话矩阵里 53 端口的"只问不答"形态。
判定步骤：rcode 分流（3 是名字不存在——查拼写与记录；2 是上游故障——查递归链）；有问无答的，确认是否伴随 UDP 重传（dns.analysis 与重传标记），是则丢包或端口被拦。
误判高发：把 NXDOMAIN 当 DNS 服务器故障。rcode 3 的意思是"权威说没有这条记录"——服务器工作正常，是记录本身的问题。两类失败的处理路径完全不同。
模式五：TLS 断链
现场长相：握手链（4.3 节的类型序列）中途终止，尾随警报记录。
判定步骤：找最末一个握手指到哪一型（ClientHello 后断是服务端拒绝或网络；证书阶段断是信任问题）；读警报码（40 握手失败——套件或证书不合规；70 版本不匹配——客户端太老或服务端强制新版本）。
误判高发：把应用层的问题当 TLS 问题。警报 40 的一类成因是"客户端证书未提供"——这是认证策略问题，不是加密协商问题。读警报码之外，还要结合部署变更（最近改过策略吗）。
模式六：慢页面
现场长相：用户说慢，监控无告警——这是最常见的接案形态。
判定步骤：分段计时四段拆解（1.3 节的预告在此兑现）：
$ tshark -r slow.pcapng -Y "dns.qry.name || tcp.flags.syn==1 || tls.handshake.type==1 || http.response" \ -T fields -e frame.time_relative -e dns.qry.name -e http.response.code 0.000 www.example.org <- DNS 段起点 0.031 - <- DNS 完成：31 毫秒，健康 0.045 - <- SYN 发出（TCP 段起点） 0.072 - <- 握手完成：27 毫秒，健康 0.074 - <- ClientHello（TLS 段起点） 1.830 - <- 首个应用数据：TLS 段耗时 1.76 秒！ 2.102 200 <- 首字节响应：HTTP 段 0.27 秒
四段里 DNS 与 TCP 都健康、TLS 段异常拉长——病灶锁定在协商阶段，接着用模式五的路径继续查（套件不匹配导致的多次往返？服务器负载？）。分段计时把"慢"翻译成位置，这是排障案最核心的一招。
结案报告的三段结构
模式库的最后一块拼图是表达。结案报告建议三段：结论先行（一句话病灶与证据）、证据链（关键帧号、过滤器、耗时数字，可复现——6.2 节与 7.1 节的复现要求）、建议与风险（改什么、影响面、需要谁配合）。报告是给非抓包人看的——数字与字段名够用即可，叙事要能被值班同学复述。
💡 模式库不是背出来的，是攒出来的。每结一个案子，问自己一句"这算新模式吗"——是就按三段格式补进来。个人的模式库超过二十条时，你会发现自己接案的姿势已经变了：先翻库，再动手。
模式库演练：一桩"周五下午全网变慢"的完整走法
把模式库串起来用一次。案情：周五下午多栋楼的用户同时反馈"打开内网门户慢"，监控曲线只有出口流量略高。
# 第 1 步：仪器定位（8.1）——先看成分与时段 $ tshark -r friday.pcapng -q -z io,phs | head -8 eth frames:2204118 ip frames:2203901 tcp frames:1811004 udp frames:392884 dns frames:388113 <- DNS 占 UDP 的 98%！正常内网不该这个比例 $ tshark -r friday.pcapng -q -z conv,udp | sed -n '5,8p' 10.0.1.55:53311 <-> 10.0.0.53:53 packets:131002 <- 单机 13 万次 DNS？ 10.0.1.55:53311 <-> 10.0.0.53:53 ...
第 1 步就锁定了异常结构：一台机器贡献了海量的 DNS。模式四启动。
# 第 2 步：筛法收窄（5.2）——看这台机器在查什么 $ tshark -r friday.pcapng -Y "ip.addr==10.0.1.55 && dns" \ -T fields -e dns.qry.name | sort | uniq -c | sort -rn | head -5 131002 a1b2c3d4e5f60718293a04b5c6d7e8f9.in-addr.lookup.local 412 www.intranet.local # 第 3 步：解剖定论（4.3）——读查询名特征 # 超长、十六进制编码、固定模式：典型 DNS 隧道信标 $ tshark -r friday.pcapng -Y "ip.addr==10.0.1.55 && dns.qry.type==16" -c 2 # TXT 查询也在 → 模式四升级为安全案：数据渗出嫌疑
结案路径：协议构成暴露 DNS 异常占比 → 会话矩阵找到嫌疑主机 → 查询名特征定性（超长编码名 + TXT 查询）→ 按 6.2 节纪律封存证据、通报安全团队隔离主机。后续处置不归网络组，但定位到"一台机器的 DNS 隧道拖慢了全员解析"只用了三条命令——这就是模式库压缩时间的直接证据。
结案报告模板（可直接套用）
【结论】一段话：病灶（哪台机器/哪条链路/哪个协议层）+ 关键证据数字 【证据链】 采集：时间窗、点位、接口、丢包统计 分析：仪器（哪个统计发现了什么）+ 筛法（哪个过滤器圈定了什么）+ 解剖（哪帧定论） 复现：三条以内的命令序列，任何人可重放 【建议与风险】整改项（归谁）、影响面、回滚方案 【归档】样本编号（入私有标本馆，7.3 的编目）、本报告引用的模式条目
模板的每一格都能从前面的工具链里直接取数——报告不是另起炉灶，是勘验过程的有序摘录。最后一格别省：归档让下一个相似案子站在这个案子的肩膀上。
结案要点
- 六类模式各有一条已验证路径：重传看方向与伴随、零窗口查接收应用、RST 三步归因、DNS 分流 rcode、TLS 读最末消息与警报、慢页面四段计时。
- 误判高发点在"压缩判定步骤"：每条路径的步骤都是前人踩坑换来的，别跳。
- 仪器—筛法—解剖三段纪律统一适用于所有模式。
- 分段计时是排障案的核心招：把"慢"翻译成"位置"。
- 结案报告三段：结论、证据链、建议——可复现、可复述。
模式库在手，主线完结。终章望向未来——加密洪流与云原生时代，解剖台往哪里走。