抓包这事，数实战很多人以为装个Wireshark就完事了。据包真到排查问题的分析时候，对着一屏密密麻麻的数实战十六进制发呆——这玩意儿到底怎么看？

我最早用Wireshark是帮朋友查一个"网站打开慢"的问题。浏览器F12看了半天没头绪，据包干脆抓包。分析结果一眼就看到：TCP三次握手之后，数实战服务器隔了整整1.2秒才回第一个HTTP响应。据包问题不在前端，分析不在DNS，数实战是据包后端应用层处理慢。整个过程从抓包到定位，分析不到五分钟。数实战

这就是据包Wireshark的价值：它不猜，它只看事实。分析

先搞清楚你在抓什么

打开Wireshark第一件事不是点开始，是选网卡。选错了，抓半天全是空气。有线网卡、无线网卡、loopback接口，各抓各的。我习惯先看一眼流量曲线——如果选对了网卡，那个小波形图会有明显起伏。

抓包过滤器（Capture Filter）和显示过滤器（Display Filter）是两码事，但新手特别容易搞混。抓包过滤器在抓之前生效，比如只抓80端口：port 80。显示过滤器在抓完之后筛，比如 http.request。前者决定你存什么，后者决定你看什么。我一般抓的时候不过滤，先全存下来，回头慢慢筛。硬盘空间换灵活性，值。

三次握手不是背书，是找线索

教科书上讲SYN、SYN-ACK、ACK，背得滚瓜烂熟。实际抓包时，这三个包能告诉你太多东西。

比如SYN发出去了，SYN-ACK没回来——要么对方没开机，要么中间防火墙拦了。SYN-ACK回来了但ACK没发出去——本机协议栈可能有问题。更常见的是SYN-ACK回来得特别慢，比如超过200ms，那基本能判断网络链路有延迟。

我遇到过一个案例：用户说访问内网服务器偶尔卡顿。抓包发现大部分连接正常，但每隔几十个连接就有一次SYN重传。重传间隔是1秒、2秒、4秒——典型的指数退避。这说明中间有设备在丢包。后来查出来是某台交换机的端口有问题。Wireshark不会直接告诉你"交换机坏了"，但它把证据摆在你面前。

跟着流走，别一个包一个包看

右键某个包，选"Follow TCP Stream"，这是最实用的功能之一。它把整个TCP会话的内容按顺序拼出来，HTTP请求和响应一目了然。不用在几百个包里一个个点。

但要注意：Follow Stream展示的是应用层数据，底层的重传、乱序它不显示。所以有时候Stream里看着正常，实际上底层已经重传了好几次。我的习惯是先用Stream看业务逻辑，再回到包列表看传输层有没有异常。

颜色规则是别人嚼过的口香糖

Wireshark默认的着色规则挺有用：黑色背景是TCP问题，红色是HTTP错误，浅蓝是UDP。但别完全依赖它。我见过有人看到黑色就紧张，其实只是普通的TCP Keep-Alive。颜色是辅助，不是判决书。

真正好用的是自定义着色规则。比如我常加一条：tcp.analysis.retransmission 标成亮黄色。这样重传包一眼就能看到，不用每次手动过滤。

统计功能被严重低估了

很多人只盯着包列表看，忽略了"Statistics"菜单。里面的"Conversations"能按IP或端口统计流量，"Expert Information"会直接列出它认为有问题的包。虽然Expert Information有时候过于敏感，但作为排查起点很好用。

有一次我怀疑某台机器在扫内网，用Conversations一看，那台机器在短时间内跟几十个不同IP建立了连接，每个连接只发了一个SYN就没了。不用看具体内容，行为模式已经说明问题了。

Wireshark不是万能钥匙。加密流量它解不开，应用层逻辑它看不懂。但它能告诉你"网络上到底发生了什么"。很多时候，知道这个就够了。