1.3 解剖台受理的四类案子：排障、安全、取证与协议观察
1.3 解剖台受理的四类案子：排障、安全、取证与协议观察
行话认全之后，本章收尾回答一个实际问题：人们到底为什么抓包？本节把典型需求归成四类案子，每类给出"案情特征—第一眼看的字段—起步动作"。这张分类表是从第 2 章到第 8 章的全部内容的索引图——后面每一章的工具，最终都服务于其中某一类案子。
四类案子的现场特征
第一类：排障案。 案情是"慢、断、卡"：页面打不开、接口偶发超时、视频会议花屏。特点是当事人多、各有说辞——应用说网络抖，网络说应用慢，防火墙说没拦。报文层的价值在于把一句话争议拆成可测量的分段耗时：DNS 查询花了多久、TCP 握手几次重试、TLS 协商卡在哪个消息、首字节响应延迟多少。
第二类：安全案。 案情是"谁、什么时候、对谁做了什么"：内网扫描、恶意软件外联、数据渗出。抓包要回答的是行为证据链：哪些外部地址被反复访问、是否呈现固定间隔的信标特征、DNS 查询里有没有可疑的子域名编码。
第三类：取证案。 案情是"把发生过的事固化成证据"：安全事件溯源、合规检查、纠纷仲裁。重点从"看懂"转向"保管"——捕获文件的完整性校验、采集时间与位置记录、原始文件不动只在副本上分析。第 2 章的 pcapng 元数据与第 6 章的合规红线都为这类案子服务。
第四类：协议观察案。 案情是"验证行为是否符合预期"：客户端到底用的 TLS 哪个版本、HTTP/2 有没有协商成功、新部署的 QUIC 是否真的生效。这类案子的当事人是协议本身，解剖对象是协商过程与选项字段。
同一现场，不同问法
拿一次"用户反馈网页慢"来说，四类视角会给出完全不同的勘验单：
排障视角： $ tshark -r slow.pcapng -Y "dns || tcp.flags.syn==1 || tls.handshake.type" \ -T fields -e frame.time_relative -e dns.qry.name -e tls.handshake.type 0.000 www.example.org - 0.031 - - 0.045 - 1 <- ClientHello 发出 1.204 - 2 <- ServerHello 隔了 1.16 秒才回，慢点初步定位 安全视角： $ tshark -r slow.pcapng -Y "dns.qry.name contains tracker" -T fields -e dns.qry.name ads.tracker-a.net px.tracker-b.io <- 页面慢的另一半真相：第三方追踪请求成串 协议观察视角： $ tshark -r slow.pcapng -Y "tls.handshake.type == 2" -T fields -e tls.version 0x0303 <- TLS 1.2，未升级到 1.3，握手多一个来回
三个问题、三条过滤器、三份结论，全部来自同一份标本。这就是"先定案由再下刀"的意义。
💡 一个实用习惯：接到任何抓包需求，先用一句话把案由写下来——"我要证明 A 与 B 之间握手慢，还是证明 C 没有外联"。这句话决定了捕获点选在哪（第 2 章）、筛子怎么下（第 5 章）、结案报告写什么（第 8 章）。
结案演示：一桩排障案从接案到结案
把四类视角落成一桩完整的小案子。案情：用户反馈"订单页有时要好几秒才打开，有时又正常"。
接案定案由：一句话案由——"证明订单页偶发慢的病灶在哪一段"。属排障案，采集点选用户侧主机，抓故障发生时段。
采集：让用户复现一次慢的打开，全程捕获，存成 slow.pcapng。
勘验过程：
# 第一步：分段计时，把"慢"拆到四段里 $ 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 order.local <- DNS 段起点 0.028 - <- DNS 完成：28 毫秒，排除 0.041 - <- SYN 发出 0.069 - <- 握手完成：28 毫秒，排除 0.071 - <- ClientHello 0.098 - <- TLS 完成：27 毫秒，排除 2.417 200 <- 首字节响应：HTTP 段 2.3 秒，嫌疑集中 # 第二步：进 HTTP 段细看，确认服务端视角 $ tshark -r slow.pcapng -Y "http" -T fields -e frame.time_relative \ -e http.request.method -e http.request.uri -e http.response.code 2.417 GET /api/orders 200 <- 接口本身 2.3 秒 3.918 GET /static/a.js 304 7.988 GET /static/b.css 304 <- 静态资源串行加载，页面到 8 秒才渲染完
结案：网络三段全部健康（DNS、握手、TLS 各约 30 毫秒），病灶有二——订单接口服务端处理 2.3 秒（应用层），前端静态资源串行加载又拖了近 4 秒（页面结构）。"网络慢"的锅，网络没背。这份结论拿去和应用组、前端组对表，各有各的整改项；支撑它的每段数字都来自上面的会话，可复现、可质疑、可验证。
同一个案子换案由就换走法：安全案由会先看这次加载牵出了哪些第三方域；取证案由会先给文件算摘要、记录采集环境。案由决定姿势，这句话经过一次实操就长在身上了。
常见疑问
**问：四类案子会不会互相打架？**会，而且经常并发。一次安全事件既要还原行为（安全案）又要固定证据（取证案），此时先按取证纪律封存原件，再在副本上做安全分析——两套纪律同时在场时，封存优先级更高。
**问：接案时案情模糊怎么办？**先做十分钟"无差别普查"：capinfos 看时长与包数、协议构成看成色、会话矩阵找大流量方。普查不是分析，是给案由找线索——多数模糊案情在看完三台统计仪器后自己就清晰了（第 8 章展开）。
**问：四类案子的难度排序？**没有公认排序，但经验上"由易到难"大致是：协议观察（对象明确、帧数少）→ 排障（有明确症状指引）→ 安全（要对抗隐藏与混淆）→ 取证（技术之外还要程序正义全程在线）。难度不影响学习顺序——本册的章节顺序按知识依赖组织，四类案子在各章都会反复现身。
**问：一份文件能同时服务多类案子吗？**能——同一份镜像口捕获，排障视角看账本、安全视角看外联、取证视角先封存。区别只在纪律：取证要求一旦成立，这份文件的处置等级就按最高的那类执行。这条原则在多人协作时尤其要紧：文件在谁手里、按什么等级管，开工前说定，事后不扯皮。
案由决定采集姿势
案由不仅决定问法，还前置决定采集方式：排障案要在"故障路径的两端或中间点"采集，才能对表定位；安全案强调时间跨度要长，信标特征靠时间积累；取证案要求记录采集人、时间、接口与校验值，一条都不能少；协议观察案往往只需几十帧，但必须抓到完整协商过程，从第一个 ClientHello 开始。
四类案由与采集姿势的对应关系，此后各章会逐条兑现：第 2 章解决"怎么把证据合法、干净地取回来"，第 3 章拆开机器看流水线，第 4 章正式开始逐层解剖。读完本节，你已经可以在接案时准确说出案由与第一落点——这是合格勘验员的第一步。