打开Wireshark，网络选择网卡，数据点击开始。包捕屏幕上立刻滚过密密麻麻的获分色块——每一行都是一个数据包。大多数人第一次看到这场景会懵：全是网络IP地址、端口号、数据十六进制。包捕但如果你知道怎么看，获分这些乱码其实是网络一份完整的对话记录。

抓包这件事，数据本质上是包捕在网卡的"混杂模式"下偷听。正常情况下，获分网卡只接收发给自己的网络帧，混杂模式让它把经过网口的数据所有流量都收进来。这也是包捕为什么在交换式网络里，你只能抓到自己机器的流量，除非做端口镜像或者ARP欺骗。我在家里调试智能音箱配网问题时，就吃过这个亏——手机和音箱之间的通信经过路由器转发，笔记本上的Wireshark什么都看不到。后来在路由器上做了端口镜像，才抓到那段MQTT握手过程。

过滤器是绕不开的。抓包不过滤，就像用消防水管喝水。BPF语法（Berkeley Packet Filter）是底层规则，Wireshark又在其上封装了一套显示过滤器。两者的区别经常让人混淆：tcp port 443是抓包过滤器，写错了要重启抓包；tcp.port == 443是显示过滤器，随时改随时生效。我习惯先用宽松的抓包过滤器（比如只限定host），抓完再用显示过滤器层层缩小。这样不会因为过滤条件写太死而漏掉关键包。

分析一个具体的例子。某次同事反馈内部管理系统登录偶尔失败，但刷新几次又能进去。我在客户端抓包，过滤http.request，看到登录请求发出后，服务器返回了302重定向。问题出在重定向的Location头里——它指向了一个负载均衡器节点，而那个节点的会话表已经满了，新连接被丢弃。客户端等不到响应就超时，重试时恰好被分配到另一个节点，于是成功。如果只看应用日志，只会看到"登录超时"，根本定位不到负载均衡层。数据包不会撒谎，它把每一跳的延迟、每个TCP标志位的变化都记下来了。

TCP流重组是另一个实用功能。右键任意一个包，选择Follow → TCP Stream，Wireshark会把整条TCP连接的应用层数据拼成可读文本。调试HTTP接口时这招特别管用——你能直接看到请求体和响应体的原始内容，包括那些被gzip压缩过的（Wireshark会自动解压）。不过要注意，如果连接中途重置或者抓包不完整，重组出来的内容可能缺一段。我有次排查一个文件上传失败的问题，重组后的HTTP body里少了几KB，正好对应抓包停止的那一刻。这说明上传其实成功了，只是客户端没收到确认就断开了。

抓包也有边界。HTTPS流量默认加密，你只能看到TLS握手和证书信息，应用层内容全是乱码。要解密得拿到服务器私钥，或者客户端设置SSLKEYLOGFILE环境变量导出会话密钥。前者只适用于RSA密钥交换（现在基本被ECDHE取代了），后者需要能控制客户端环境。所以现实中抓包分析HTTP/2或QUIC流量，往往只能分析连接建立阶段和流量模式，看不到具体内容。这倒也不是坏事——至少能看出连接是否复用、有没有异常重传、RTT波动大不大。

最后说个容易忽略的细节：时间戳。Wireshark默认显示的是相对时间，但排查性能问题时应该切到绝对时间或者两个包之间的delta时间。有次我盯着一个"慢"接口，绝对时间显示请求和响应间隔800ms，看起来是服务器处理慢。但切到delta时间才发现，客户端发出请求后，第一个响应包在20ms内就回来了，后面是TCP窗口更新和ACK的往返。真正的瓶颈在客户端接收缓冲区太小，导致服务器分多次发送。换个角度，结论完全不一样。

抓包工具本身不复杂，复杂的是你对自己网络行为的理解。知道正常长什么样，才能认出异常。