抓包这活儿，网络干久了会上瘾。数据不是包分看流量大小那种瘾，是网络那种在杂乱无章的字节流里，突然揪出一个异常包时，数据脑子里“叮”一声的包分爽感。Wireshark的网络列表滚动得飞快，颜色规则把不同协议染得花花绿绿，数据但真正的包分高手，只盯着那几列：Time、网络Source、数据Destination、包分Protocol，网络还有Info。数据别的包分，都是噪音。

有一次，公司线上应用半夜报警，用户反馈页面加载要转十几秒。服务器CPU不高，数据库慢查询日志也干净。运维重启了三回，没用。我抓了五分钟的包，一眼就看到TCP窗口大小不对劲——服务器通告的接收窗口，从65535字节一路跌到几百字节，典型的接收端缓冲区被占满，又迟迟不释放。顺着流往下追，发现应用层有个线程在死等一个不存在的锁，数据全堵在socket缓冲区里。代码问题，但包先说了实话。

分析数据包，本质上是在做翻译。把网线上那些肉眼不可见的电压变化，翻译成人类能理解的对话。三次握手是“在吗？”“在的”“那咱聊”——SYN、SYN-ACK、ACK，每个包都带着序号和确认号，像两个严谨的会计在对账。但真正有意思的，是那些不按剧本走的包。比如一个RST包，突然掐断连接，那背后可能是防火墙策略误杀，也可能是一方程序崩溃前发出的“最后通牒”。

别迷信那些花哨的仪表盘。图形界面好看，但丢包重传率、乱序比例这些指标，光看曲线图容易骗自己。得把原始包翻出来，看时间戳的间隔。有一次我排查视频卡顿，重传率只有0.3%，看着挺健康。但把时间轴拉细，发现每过两秒就有一批包延迟50毫秒到达，规律得跟心跳似的。最后定位到是网卡驱动的中断合并策略太激进，把本该分散的小包攒成一大坨再交上去。延迟不是丢包造成的，是攒出来的。

抓包的位置也讲究。在服务器上抓，看到的是“别人对我说了什么”；在客户端抓，看到的是“我实际发出了什么”；在中间交换机上镜像口抓，才勉强算“旁观者清”。但旁观者也未必清——交换机镜像口偶尔会丢包，抓到的数据本身就不完整。所以真正靠谱的做法，是两端同时抓，然后对比。哪边多了，哪边少了，真相往往藏在差值里。

说到工具，tcpdump是底线，wireshark是日常。但别只依赖图形界面，命令行下tcpdump配合BPF过滤表达式，效率高得多。比如抓HTTPS流量，直接过滤“tcp port 443 and tcp[13] & 8 != 0”，只看带PSH标志的包，能少一大半干扰。Wireshark的“Follow TCP Stream”功能好用，但那是把整个会话的payload重新拼起来看，容易忽略底层包边界。真正要查问题，还是得一个个包点开看TCP头的Flags、Sequence number、Acknowledgment number，那几个数字里全是戏。

干这行久了，会养成一个怪癖：看任何网络问题，第一反应不是看日志，是想“先抓个包再说”。日志是别人写好的剧本，包才是现场实录。哪怕最后证明不是网络问题，抓包也能帮排除嫌疑，省得运维跟开发互相甩锅。有一次俩部门吵了三天，说对方协议实现有bug，我抓了包往桌上一放，时间戳、重传、乱序全标出来，谁的责任一目了然。包不说话，但包不撒谎。就冲这点，这活儿值得干。

(责任编辑：休闲)