4.3 应用层三案：DNS、HTTP 与 TLS 握手解剖
4.3 应用层三案：DNS、HTTP 与 TLS 握手解剖
解剖台来到最内层。本节拆三个高频案宗：DNS（每次连接的前置问路）、HTTP（明文时代的完整语义）、TLS（加密时代的信封构造）。三案的报文结构差异很大，但解剖方法一脉相承——先看原文，再对照字段树，最后回到勘验判定。本节的 TLS 部分是第 6 章解密实战的地基。
案宗一：DNS，一次问路与两类失败
DNS 报文固定 12 字节头加四个计数节。先解剖头部：
真实解析现场与两类失败的判定：
$ tshark -r dns.pcapng -Y "dns.flags.response==1" -T fields \ -e dns.qry.name -e dns.flags.rcode -e dns.a -e dns.count.answers www.example.org 0 93.184.216.34 1 <- 正常：rcode 0，带回一条 A 记录 api.old-service.cn 3 - 0 <- NXDOMAIN：名字不存在 cdn.upstream.io 2 - 0 <- SERVFAIL：递归链上游出问题 # 有问无答：查询发出后 5 秒内无同 ID 响应（超时特征） $ tshark -r dns.pcapng -Y "dns.flags.response==0 && !dns.analysis.retrans" -c 2 8 10:15:22.331 192.168.31.14 → 223.5.5.5 Standard query 0x8f3a A www.example.org
事务 ID 是配对钥匙：响应的 ID 必须与查询一致，Wireshark 靠它把问答配成对。勘验时注意：同一 ID 短时间重复出现，除了重传，还可能是欺骗尝试的指纹。
案宗二：HTTP，明文语义的完整解剖
HTTP 报文是纯文本，解剖变成阅读。但结构仍要按解剖的纪律读：
$ tshark -r http.pcapng -Y "http.request" -T fields -e http.request.method \ -e http.host -e http.request.uri -e http.user_agent GET api.example.org /v2/orders?page=1 curl/8.5.0 $ tshark -r http.pcapng -Y "http.response" -T fields -e http.response.code \ -e http.response.phrase -e http.content_length -e frame.time_delta 200 OK 18742 0.041 <- 正常响应，41 毫秒 504 Gateway Timeout 0 30.002 <- 网关等上游超时，整 30 秒是网关超时默认值
排障价值最高的三个观察点：请求行与响应行的配对（哪个请求慢、哪个请求挂）、响应码的分布（5xx 集中出现的时间窗）、内容长度与实际字节的差（差值异常提示分块传输或截断）。HTTP/1.1 的管线化与连接复用让"一个 TCP 流里多次请求"，Follow Stream 看到的是交错文本——按请求行切分才不会读岔。
案宗三：TLS，加密信封的构造解剖
TLS 加密的是载荷，信封本身（记录层与握手消息）完全可见。这正是 TLS 勘验的价值所在：版本、套件、扩展、证书指纹、断链原因，全部在明文层。
# 一次 TLS 1.3 握手的关键帧 $ tshark -r tls.pcapng -Y "tls.handshake.type" -T fields \ -e frame.number -e tls.handshake.type -e tls.record.version 12 1 0x0303 <- ClientHello：版本 0x0303 是兼容写法，真实版本在扩展里 13 2 0x0303 <- ServerHello 14 11 0x0303 <- Certificate（加密传输，TLS 1.3 中证书也进了密文） 15 - 0x0303 <- 之后的应用数据全部是密文 # ClientHello 的关键扩展 $ tshark -r tls.pcapng -Y "tls.handshake.type==1" -T fields \ -e tls.handshake.extensions_server_name -e tls.handshake.extensions_alpn_str www.example.org h2,http/1.1
两个扩展值得点名：**服务器名称指示（SNI）**明文携带目标域名——即使全程加密，访问了哪个网站仍然一目了然，这是隐私与审计的双刃剑；**应用层协议协商（ALPN）**列出了客户端愿意讲的应用协议（h2 与 http/1.1），HTTP/2 是否协商成功看这里。TLS 1.2 与 1.3 的现场快速区分：1.3 的握手消息更少（ServerHello 后很快进入密文）、且 Change Cipher Spec 消失或仅为兼容占位。
握手失败的断链解剖，抓 alert 消息：
$ tshark -r tls.pcapng -Y "tls.record.content_type==21" -T fields \ -e tls.alert_message.desc -e tls.alert_message.level 40 2 <- handshake_failure：双方没有共同接受的套件或证书校验失败 70 2 <- protocol_version：版本不匹配
警报 40 与 70 是两类最常见的"握手死因"。完整的警报码表内建在解析器里，鼠标悬停即见中文释义——这也是 3.3 节"字段注册表带语义"的红利。
💡 明文层的价值再强调一次：即使你永远不解密（第 6 章才讲解密），SNI、ALPN、证书链长度、握手轮数、警报码这五项明文观察，已经能支撑大量 TLS 案宗的结案。
三案合审：一次"打不开"的全栈解剖
三个案宗的知识合起来用一次。案情：用户反馈某内部系统"打不开"，浏览器只显示连接被重置。
# 第 1 步：应用层先看断在哪一案 $ tshark -r cannot-open.pcapng -Y "dns || tls || tcp.flags.reset" -T fields \ -e frame.number -e dns.flags.rcode -e tls.handshake.type -e tls.alert_message.desc -e tcp.flags.reset 3 0 - - - <- DNS 正常返回 9 - 1 - - <- ClientHello 发出 10 - 2 - - <- ServerHello 回了：TLS 起步正常 12 - 11 - - <- 证书消息 15 - - 47 - <- 警报 47：illegal_parameter！ 16 - - - 1 <- 服务端随后 RST 断链
读法：DNS 结案（正常）、TLS 案宗接手（握手走到证书后被警报打断）、警报码 47 定性（参数非法——本例是客户端发的证书与协商套件不匹配）。三层案宗一次会话全部走完：应用层排障的功力，就是按"问路—敲门—递交证件"的顺序快速排除，断在哪一步，哪一案接手。
常见疑问
**问：怎么快速记住这么多警报码？**不用背。解析器的悬停释义就是速查（4.3 节的红利），真正要记住的是"高频凶手"：40 套件谈不拢、42 证书坏、46 证书链断、47 参数非法、70 版本不合。记住这五个，八成的 TLS 断链现场能当场定性。
**问：HTTP 报文跨多帧时怎么读全？**HTTP 层的字段由解析器重组后给出（3.3 节的会话状态），你看到的响应码、头部都是重组后的完整视图；要原始分帧细节再看字节面板。这也是"解剖刀有记账"在应用层的体现。
结案要点
- DNS 头 12 字节：事务 ID 是配对钥匙；RCODE 3 是名字不存在，2 是上游病了，有问无答查丢包。
- TXT 记录超长且含编码特征：C2 与渗出的经典指纹。
- HTTP 按"请求行配对"读：响应码分布与首字节延迟是两大观察点。
- TLS 信封明文可读：SNI 暴露域名、ALPN 决定协议版本、警报 40 与 70 是两大死因。
- 1.2 与 1.3 的现场区分：握手轮数与密文起点。
逐层解剖的功夫到手。下一章讲断案的第一件武器——把几百万帧筛到剩下的那几十帧。