网络抓包工具怎么分析数据

Wireshark 抓到一个 TCP 重传包，网络红色背景，抓包看起来刺眼。工具但红色不等于故障。分析我见过有人盯着满屏红色惊呼“网络要炸了”，数据其实那只是网络接收端没来得及 ACK，发送端正常超时重传。抓包抓包工具本身不分析数据，工具它只是分析把网卡上的二进制流翻译成人能看懂的协议树。真正的数据分析发生在你脑子里。

先搞清楚你抓到的网络是什么。打开 Wireshark，抓包第一列是工具帧编号，第二列是分析时间戳，相对时间还是数据绝对时间取决于你的设置。我习惯把时间列改成“Seconds Since Beginning of Capture”，这样看延迟更直观。第三列源地址，第四列目的地址，第五列协议，第六列长度，第七列信息摘要。这七列就是你的地图。别急着点开协议树，先扫一遍摘要列。如果看到大量“TCP Retransmission”或者“TCP ZeroWindow”，那才是问题信号。ZeroWindow 意味着接收方缓冲区满了，发送方被迫停发。这比重传严重得多。

举个例子。某次排查视频卡顿，抓包发现每隔 3 秒出现一次 TCP ZeroWindow，持续 200ms。接收端是台老旧的机顶盒，内存吃紧。发送端是 CDN 节点，被迫暂停。卡顿就是这 200ms 造成的。如果只看重传，会误判为网络丢包。所以协议树里的 Window Size 字段比 Retransmission 更值得盯。

过滤表达式是抓包分析的命门。别用鼠标在列表里翻，直接敲 tcp.port == 443 && ip.addr == 192.168.1.100。更狠一点，用 tcp.analysis.flags 直接筛出所有异常标志。Wireshark 的 tcp.analysis 系列字段是分析利器：tcp.analysis.retransmission、tcp.analysis.duplicate_ack、tcp.analysis.zero_window。把这些组合起来，异常帧无处遁形。

看 TCP 流要跟“流”而不是“包”。右键任意一个包，选 Follow → TCP Stream。Wireshark 会把整个会话的 payload 拼起来，用不同颜色区分方向。这时候你看到的是应用层数据，HTTP 头、JSON body、TLS 握手记录。如果 Stream 里出现乱码或截断，说明抓包时没抓全，或者中间有设备改了包。我遇到过防火墙偷偷重置连接，Stream 里突然插入一个 RST，但两端应用日志都正常。这种“中间人”行为只有看流才能发现。

时间戳分析容易被忽略。两个包之间的 Delta Time 如果突然从 0.001 秒跳到 0.5 秒，那就是应用层处理慢或者网络抖动。但别只看平均值。把 tcp.time_delta 列打开，按降序排。最大的那几个 Delta 就是瓶颈点。有一次数据库查询慢，抓包发现 MySQL 协议里请求发出后 1.2 秒才收到响应，但网络 RTT 只有 2ms。问题在数据库本身，不在网络。抓包工具帮你排除了网络嫌疑。

TLS 加密流量现在占八成以上。没有密钥你只能看到握手和证书。但握手阶段的信息足够多：Client Hello 里的 SNI 告诉你访问哪个域名，Server Hello 里的证书链告诉你用了哪家 CA，Cipher Suite 告诉你加密套件。如果 TLS 握手失败，Alert 消息会明确告诉你原因，比如 handshake_failure 或者 bad_certificate。这些比应用层报错更底层。

最后说个反直觉的：别迷信抓包。交换机镜像口可能丢包，本机抓包可能被 CPU 调度延迟。我见过抓包文件里 TCP 窗口一直是 65535，但实际网卡是 10Gbps。那是抓包工具自己的缓冲区满了，不是网络问题。分析之前先确认抓包环境是否可靠。否则你分析的是抓包工具的幻觉，不是网络真相。