3.3 解析器与字段树：解剖刀的分派机制

3.3 解析器与字段树：解剖刀的分派机制

解析段是 Wireshark 的心脏，也是全书的技术枢纽：第 4 章逐层解剖时你看到的每个字段、第 5 章显示过滤器里的每个名字，都是这一节讲的解剖刀体系生产出来的。本节讲三个机制——解剖刀怎么注册、帧怎么被分派到正确的刀、字段树怎么长出来——以及一个实战痛点：端口认错协议时怎么办。

解剖刀怎么挂上钩子：注册表机制

每把解剖刀（解析器）启动时向引擎登记"我在什么条件下出刀"。最常见的三种挂钩方式：

• 端口表：TCP 或 UDP 的端口号是最高频的分派依据。HTTP 解析器注册在 TCP 80 与 8080，DNS 解析器注册在 UDP 53 与 TCP 53。
• 类型字段表：链路层的 ethertype、IP 的协议号也各自是注册表。以太网类型 0x0800 指到 IPv4，IP 协议号 6 指到 TCP、17 指到 UDP。
• 启发式：没有约定俗成端口的协议（很多二进制 RPC、私有协议）注册一个"猜一猜"函数：给我前几十个字节，我看看像不像我。引擎按注册顺序逐个试，谁先认领谁解剖。

用 tshark 可以直接查询这些注册表。查"哪些协议挂在 UDP 端口上"：

$ tshark -G decodes | grep -i "udp.port" | head -8
"D","udp.port","53","dns"
"D","udp.port","67","bootpc"
"D","udp.port","68","bootps"
"D","udp.port","123","ntp"
"D","udp.port","161","snmp"
"D","udp.port","500","isakmp"
"D","udp.port","514","syslog"
"D","udp.port","1900","ssdp"
​

每一行是一份登记：UDP 端口 53 归 DNS 解析器处理，123 归 NTP，161 归 SNMP。这张表就是分派的真相之源。

一帧的解剖过程：从注册表到字段树

拿 3.1 节那枚 DNS 帧复盘全程。以太网解析器先出刀，读目的 MAC、源 MAC、类型 0x0800；查类型表，指到 IPv4 解析器；IPv4 解析器读版本、头长、协议字段 17；查协议表，指到 UDP；UDP 读端口 51822 与 53；查端口表，53 归 DNS；DNS 解析器读事务 ID、标志、问题数，最终把查询的主机名挂上字段树。每一把刀只做两件事：读懂自己的头，把"内层是什么"交给注册表裁决。

# 解剖的产物：字段树（-V 输出的结构化版本）
$ tshark -r first.pcapng -c 1 -T pdml | head -30
<?xml version="1.0"?>
<pdml version="0" creator="Wireshark/4.2.2">
<packet>
  <proto name="frame" showname="Frame 1" size="74">
    <field name="frame.interface_id" .../>
    <field name="frame.time_relative" showname="0.000000" .../>
  </proto>
  <proto name="eth" showname="Ethernet II" size="14">
    <field name="eth.dst" showname="Destination: aa:bb:cc:dd:ee:ff" .../>
    <field name="eth.src" showname="Source: 88:c9:d0:11:22:33" .../>
    <field name="eth.type" showname="Type: IPv4 (0x0800)" .../>
  </proto>
  <proto name="ip" ...>
  ...
​

PDML 是字段树的 XML 快照：proto 节点按层排列，field 节点带注册名。GUI 详情面板渲染的就是这棵树——你在树上选中的每个字段，机器里就是一个带名字的节点，显示过滤器的求值对象就是它们。

字段注册表：字段名的户籍处

显示过滤器里的 tcp.flags.syn 从哪来？解析器实现字段时向字段注册表登记。全表可以导出：

$ tshark -G field-names | grep -c ""
74000        <- 四位数级别的字段量级（随版本增长）

$ tshark -G field-names | grep "^tcp.window_size"
tcp.window_size
tcp.window_size_scalefactor
tcp.window_size_value
​

三个窗口字段的区别本身就是解剖层次的体现：window_size_value 是报文里的原始值，window_size 是按窗口缩放因子换算后的值，window_size_scalefactor 是换算系数。查表不仅能找到字段名，还能帮你理解字段的语义层次——写过滤器前查一下注册表，是避免"字段不存在"报错的正经手段。

误诊与纠正：decode as 的用法

分派机制的软肋是"端口说了算"。私有协议跑在 TCP 8080 上，会被 HTTP 解析器解剖成一堆解析错误；某设备的 SSDP 变种挂在 1900 之外，会被当纯 UDP 数据。纠正手段是临时改判——把某条流指定给正确的解析器：

# GUI：选中该流任一帧，右键"解码为"，选择目标协议
# 命令行等价物：
$ tshark -r odd.pcapng -d "tcp.port==9000,myproto" -T fields -e myproto.type

# 查看某端口当前归谁管：
$ tshark -G decodes | grep "tcp.port\",\"9000"
​

-d 参数的格式是"判据,协议名"。现场勘验里这是救命开关：镜像口上抓到的负载均衡健康检查、自定义 RPC，十有八九需要人工改判才能正确解剖。

另一个相关工具是启用与禁用解析器：全局偏好里可以关掉某把刀（比如关掉某类总在误报的启发式解析器），让帧退回更基础的层显示原始数据。

解剖刀的状态：会话与上下文

高级解剖刀是有状态的：TCP 解析器为每条流维护序号基线，才能标出"这是重传"；HTTP 解析器记住请求与响应的配对，才有响应时间；TLS 解析器攒齐握手消息才能命名密码套件。这就是为什么 8.2 节会提到"两遍解析"（two-pass analysis）：第一遍攒状态，第二遍用完整状态重新解剖，前后引用类分析（比如 TCP 流的完整重传标记）才准确。GUI 在打开文件时可能提示"发现两遍解析更优"，tshark 用 -2 显式开启。

💡 顺着"解剖刀会记账"这个思路，很多功能就说得通了：Follow Stream 能把流拼出来，是因为 TCP 解析器一直在按序号排字节；专家信息能喊出"重传"，是因为序号账本对不上。第 4 章讲 TCP 解剖时，这本账是主角。

结案要点

• 三种挂钩：端口表、类型字段表、启发式，分派真相在 tshark -G decodes。
• 字段树是解析的产物：显示过滤、列、统计、导出全部从它取数。
• 字段名有户籍：tshark -G field-names 查询，写过滤器前先查户口。
• 误诊用 decode as 纠正：-d "tcp.port==9000,协议名" 是现场救命开关。
• 解剖刀有状态：会话账本支撑重传标记与流重组，两遍解析让账本更完整。

解析段讲完，最后一站是呈现段——三块面板怎么把字段树送到你眼前。