4. 数据包列表列定制：时间列、源/目的地址列、协议列、长度列、信息列的自定义与排序
Wireshark 的数据包列表，说白了就是你的「战场地图」。
默认的列布局能用，但离「顺手」还差得远。
我刚开始用 Wireshark 那会儿，就傻傻地盯着默认界面看，直到有一次排查一个跨三层丢包问题，折腾了三个小时……后来才发现，把时间列改成相对时间，问题五分钟就定位了。
嗯，从那天起，我养成了一个习惯：
每次开始抓包前，先花 30 秒定制列布局。
4.1 为什么默认列不够用？
默认情况下，Wireshark 显示这几列：
| 列名 | 默认内容 | 常见痛点 |
|---|---|---|
| No. | 包序号 | 只增不减，排查时参考价值有限 |
| Time | 秒数（从抓包开始） | 默认是绝对时间，对比延迟不方便 |
| Source | 源 IP | 有时需要显示端口或主机名 |
| Destination | 目的 IP | 同上 |
| Protocol | 协议缩写 | 无法区分 TCP 和 TLS |
| Length | 帧长度 | 默认是物理层长度，不是 IP 层 |
| Info | 摘要信息 | 内容太多，有时需要精简 |
你想想看，排查延迟问题时，默认的绝对时间能帮你快速算出 RTT 吗？
排查大包分片时，默认的帧长度能直接告诉你 MTU 超限了吗？
不能。所以，定制是必须的。
4.2 时间列：三种模式，各有用途
Wireshark 的时间列支持三种显示模式，我分别说说它们的适用场景。
核心原则：排查延迟用「相对时间」，排查时序用「绝对时间」，排查抖动用「增量时间」。
4.2.1 绝对时间（默认）
显示格式：2025-01-15 14:23:45.123456
适合场景：跨天抓包、需要与系统日志对齐时。
我一般只在需要跟服务器日志做时间戳比对时才切到这个模式。
4.2.2 相对时间（我最常用的）
显示格式：0.000000（从第一个包开始计时）
适合场景：计算 RTT、排查重传、分析三次握手延迟。
举个例子：你看到 SYN 在 0.000000，SYN-ACK 在 0.003245，那 RTT 就是 3.245ms，一目了然。
4.2.3 增量时间（Delta Time）
显示格式：+0.001234（与前一个包的间隔）
适合场景：分析数据包到达间隔、排查突发流量、检测抖动。
我曾经用这个模式排查过一个 VoIP 语音卡顿问题——正常间隔 20ms，突然出现一个 200ms 的间隔，嗯，问题就在那里。
如何切换？
菜单栏：View → Time Display Format，然后选择你需要的模式。
我的小技巧：我会把时间列复制一份，一列用「相对时间」，另一列用「增量时间」。这样既能看整体延迟，又能看包间间隔，排查问题时不用来回切换。
4.3 源/目的地址列：不止是 IP
默认的 Source 和 Destination 列只显示 IP 地址。
但很多时候，我们需要更多信息。
4.3.1 显示端口号
在列首右键 → Column Preferences → 把字段改成 ip.src 或 ip.dst 是不够的。
你需要用 ip.src: tcp.srcport 或 ip.dst: udp.dstport 这样的组合字段。
更简单的方法：
在列首右键 → Edit Column → 在「Field」输入框里直接写：
ip.src or tcp.srcport or udp.srcport
这样，源地址列就会显示成 192.168.1.1:443 这样的格式，排查 NAT 或端口映射时特别方便。
4.3.2 显示主机名
如果你在抓包时启用了 DNS 解析（默认是关闭的），可以把列字段改成 ip.host。
但注意：这会导致 Wireshark 变慢，因为每个包都要做反向 DNS 查询。
我一般只在分析内网流量时才开这个功能。
4.4 协议列：一眼识别封装层次
默认的 Protocol 列只显示最内层协议，比如 TCP、UDP、ICMP。
但有时候，我们需要看到完整的协议栈。
举个例子：
一个 HTTP/2 流量，默认只显示 TCP，但你想知道它是不是 TLS 加密的。
这时候，你可以把协议列的字段改成 frame.protocols。
效果是这样的：
eth:ip:tcp:tls:http2
嗯，一眼就能看出封装层次。我在分析 SDN 流量时经常用这个，因为 VXLAN 的封装层次特别深，默认列根本看不出来。
注意：frame.protocols 字段内容较长，建议把协议列的宽度拉到 200px 以上，否则会被截断。
4.5 长度列：帧长度 vs IP 长度
默认的 Length 列显示的是「帧长度」（包含以太网头部）。
但排查 MTU 问题时，我们更关心「IP 长度」。
如何切换？
在列首右键 → Edit Column → 把字段从 frame.len 改成 ip.len。
| 字段 | 含义 | 典型值 | 适用场景 |
|---|---|---|---|
frame.len |
帧总长度（含以太网头部 14 字节） | 1514 | 通用分析 |
ip.len |
IP 数据报长度（不含以太网头部） | 1500 | MTU 排查、分片分析 |
tcp.len |
TCP 载荷长度（不含 TCP 头部） | 1460 | 吞吐量计算、MSS 分析 |
我个人习惯在排查大包分片问题时，把长度列改成 ip.len，然后按长度降序排序。
如果看到超过 1500 的包，那基本就是分片了。
4.6 信息列：精简还是详细？
Info 列是 Wireshark 的「智能摘要」，但有时候它太智能了，信息太多反而看不清。
举个例子：
一个 TCP 重传包，默认 Info 列显示的是：
[TCP Retransmission] 443 → 54321 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
信息很全，但如果你只想看「是不是重传」，这个就太长了。
你可以自定义 Info 列的显示内容：
在列首右键 → Edit Column → 把字段改成 tcp.analysis.flags 或 http.request.uri 等更具体的字段。
我常用的几个自定义 Info 列：
- TCP 分析专用：
tcp.analysis.flags— 只显示重传、重复 ACK、零窗口等标志 - HTTP 分析专用：
http.request.uri— 只显示请求路径 - DNS 分析专用：
dns.qry.name— 只显示查询的域名
4.7 列的排序与组合技巧
排序不只是点一下列首那么简单。我分享几个实战中常用的排序组合。
4.7.1 按时间排序（默认）
点时间列首，默认升序。这是最常用的，看时序。
4.7.2 按长度排序（找大包）
点长度列首，降序排列。最上面的就是最大包。
我曾经用这个方法快速定位到一个 MTU 超限问题——排在最上面的包长度是 1514，但路径 MTU 只有 1500，分片标志位还是 DF，结果 ICMP 不可达就来了。
4.7.3 按协议排序（分类统计）
点协议列首，所有 TCP 包会排在一起，所有 UDP 包排在一起。
配合 frame.protocols 字段，可以快速统计各种协议的比例。
4.7.4 多列排序（高级技巧）
按住 Shift 键，依次点击列首。
比如：先点「协议列」升序，再点「长度列」降序。
效果：先按协议分组，每组内按长度从大到小排列。
这个技巧在分析混合流量时特别有用。
我的习惯：我会把常用的列布局保存为配置文件。菜单栏 View → Column Preferences → 调整好后，导出为 .cf 文件。换电脑或重装系统时，直接导入，不用重新配置。
4.8 实战案例：用定制列快速定位 TCP 重传
假设你抓到一个 pcap，怀疑有 TCP 重传问题。
用默认列布局，你得一个个看 Info 列，眼睛都看花了。
但如果你提前定制了列布局：
- 时间列：相对时间
- 源地址列：
ip.src: tcp.srcport - 目的地址列：
ip.dst: tcp.dstport - 协议列：
frame.protocols - 长度列：
tcp.len - 信息列：
tcp.analysis.flags
然后按信息列排序，所有带重传标志的包就会排在最前面。
再配合相对时间列，一眼就能看出重传间隔——是快速重传（几毫秒）还是超时重传（几百毫秒）。
嗯，这就是定制列的魅力。不是 Wireshark 不好用，是你还没把它调教好。
4.9 保存与加载列配置
调好列布局后，别每次都重新配。
Wireshark 支持保存和加载配置文件。
保存步骤：
- 调好所有列
- 菜单栏
View → Column Preferences - 点击右下角的
Export按钮 - 保存为
.cf文件（比如tcp_analysis.cf）
加载步骤：
- 菜单栏
View → Column Preferences - 点击右下角的
Import按钮 - 选择之前保存的
.cf文件
我电脑里存了 5 个配置文件：
tcp_analysis.cf、http_debug.cf、dns_check.cf、voip_jitter.cf、sdn_vxlan.cf。
遇到不同场景，直接导入对应的配置，不用每次都从头调。
额外福利：配置文件还可以分享给同事。团队统一列布局后，排查问题时沟通效率会高很多——你说「看第三列」，大家都知道是哪一列。
好了，列定制就讲到这里。
记住一句话：好的列布局，能让你的排查效率翻倍。
别偷懒，花 5 分钟调好它，后面省的是几个小时。