1. 动手前先搞懂三件事:抓包到底在抓什么
干了这么多年网络跟后端,我几乎每天都在跟 Wireshark 打交道。很多新手一上来就直接点开软件,对着满屏的流量发懵,然后问我:为什么我抓了一堆包,却什么都看不出来?其实问题往往不在操作,而在于没搞清楚抓包到底在干什么。
Wireshark 本质上是一个协议分析器。它把网卡上经过的数据包原样采集下来,然后按照 TCP/IP 协议栈的层次结构帮你解析成人类能看懂的语言。你看到的不只是一堆十六进制字符,而是一个个带有完整上下文的信息单元:谁在什么时间、从哪个端口、向哪个端口、发送了什么协议的数据。
在真正打开软件之前,有三件事我建议你先想清楚:第一,你的网卡能不能看到目标流量;第二,你选对了抓包的位置没有;第三,你有没有权限把原始数据包拿到手。
这三个问题直接决定了你后续做的所有分析有没有意义。
1.1 网卡不是“全知”的:混杂模式才是抓包的前提
网卡在默认状态下,只会把目标 MAC 地址是自己的数据帧交给系统处理。其他数据包虽然物理上也经过了这根网线,但网卡会直接丢弃,就像快递员看到收件人不是自己就直接略过一样。
Wireshark 要做的事情,是先把网卡切换到一种特殊状态,这种状态在网络术语里叫混杂模式。只有在这种模式下,网卡才会把经过的所有数据帧都复制一份交给抓包工具,而不论目标是本机还是别的机器。
你在 Wireshark 的抓包选项界面里,每个接口旁边都有一个“启用混杂模式”的复选框,默认是勾上的。很多人觉得这个选项无所谓,实测下来,它恰恰是区分“我只能抓自己的包”和“我能抓整个局域网里跟我同网段所有设备的包”的关键。
但是注意,混杂模式不是万能的。它只能在传统共享式集线器网络里做到“一抓全收”,现在的网络基本都是交换机组网,交换机只会把数据帧转发给目标端口,你接在交换机的一个口上,默认是收不到其他机器之间的通信流量的。
那怎么办?两个办法:一是把抓包设备接到交换机的镜像端口上,让交换机把进出某个端口的所有流量复制一份给你;二是直接在目标设备本机上抓。绝大多数日常排障场景,其实都属于后者——你抓的就是自己这台机器发出的、或者接收到的流量。
明白了这个原理,你就能理解为什么有时候明明连着同一个 WiFi,却抓不到手机上的包了。因为路由器天然隔离了无线客户端之间的二层转发,你拿电脑抓包,只能看到手机跟路由器之间的流量,看不到手机跟其他电脑之间直连的流量。
1.2 抓包位置决定你能看到什么:本机、交换机镜像、云端
抓包位置这件事,我用一句话总结:你站在什么地方看,决定了你只能看到什么地方的流量。
如果你想排查本机应用的问题,比如某个后台服务为什么连接不上数据库,直接在服务器上抓包最合适,因为流量必然经过本机的虚拟网卡或者物理网卡。你想看一个第三方网站为什么打开缓慢,那也是在自己的电脑上抓包,因为请求是从你这里发出去的,响应也是回到你这里的。
但如果你要排查的是两台服务器之间的通信问题,比如内网的 A 服务调用 B 服务超时,那 A 和 B 各抓各的,比对时间戳就能定位出问题到底出在发送端、接收端还是中间的网络上。这个思路非常实用,我经常远程指导别人这么干。
还有一种场景是旁路抓包,需要把抓包设备部署在交换机的镜像口,或者使用专门的网络分流器。这类场景一般用在安全审计和流量监控上,日常开发排障用到的相对少。不过你要知道有这种方案存在,因为当你面对的是没有登录权限的设备时,这可能就是你唯一的抓手。
我在实际项目里还遇到过一个特别典型的误区:有人在云服务器上想要抓别人访问自己服务的流量,但怎么都抓不到完整的握手过程。原因很简单,云上的负载均衡和防火墙设备已经在流量进入操作系统之前做了转发处理,你只能在服务器本机的内网网卡上抓到从负载均衡转发过来的流量,而客户端到负载均衡这一段你根本看不见。
认清抓包位置的边界,比学会操作 Wireshark 本身更值钱。
1.3 权限这件事:Windows 和 Linux 下的抓包差异
Wireshark 抓包需要系统授予访问底层网卡的权限。Windows 下你要么以管理员身份运行 Wireshark,要么确认 WinPcap 或 Npcap 服务已经正常安装并启动。很多人第一次装完 Wireshark 却发现打不开网卡,九成都是 Npcap 没装好或者被安全软件拦截了。
Npcap 是 Windows 平台下抓包的核心驱动组件,Wireshark 安装包会引导你一并安装它。安装的时候有两个细节值得留意:一个是“支持 802.11 无线数据包捕获”的选项,如果你的机器用无线网卡,建议勾上;另一个是“安装为开机自动启动的服务”的选项,默认设置就行,别改,否则之后每次都要手动启动服务。
Linux 下抓包则要面对另一个天然的屏障:raw socket 的访问权限。普通用户打开 Wireshark 图形界面,会发现网卡列表是空的,什么都没有。这是因为抓包操作需要 CAP_NET_RAW 这类内核能力,普通用户默认没有。
解决办法有两种,你按自己的习惯选就好。第一种是直接用 root 跑 Wireshark,简单粗暴,但不推荐长期这么干,图形界面程序用 root 跑总归不太优雅,而且仪表盘和配置文件权限会变成 root 属主,后续普通用户再启动会遇到各种小毛病。第二种是给当前用户添加抓包权限的组,Ubuntu 和 Debian 系的发行版里通常有个叫 wireshark 的组,把自己加进这个组,重启会话之后就能正常抓包了。
CentOS 没有现成的 wireshark 用户组,我一般是用 setcap 给 dumpcap 命令单独授予抓包能力,具体命令是:
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap执行完用getcap /usr/bin/dumpcap验证一下输出,确认能力挂上了就行。这样普通用户也能正常启动抓包,不用每次都 sudo。
如果你用的是图形界面不完整的服务器环境,那 Wireshark 的纯命令行版本 tshark 会更顺手,后面章节我会专门提到它的用法。
1.4 抓包合规这件事:只在你自己有权限的网络里操作
最后这条我必须放在动手之前说,因为它比任何技术细节都重要。Wireshark 是网络诊断工具,不是偷窥工具。平时做排障,抓包只能针对自己管理的服务器、自己开发的程序、或者你明确获得授权的网络环境。
我曾经见过有人在公司办公网里打开混杂模式,试图去抓同事电脑上的聊天记录流量,这种行为性质就完全变了。抓包工具本身是中性的,它能不能产生价值,取决于你拿它来解决什么问题。想排查自己服务的接口为什么慢,这是技术;想在别人的网络上采集别人设备的数据,这就是越界。
现在大多数网站和 App 的流量都是 HTTPS 加密的,你就算抓到了包里也只是一堆乱码,需要额外的解密手段才能看到明文,这本身就是一道天然的合规门槛。后面我会讲 TLS 解密的方法,但请你记住:那些方法只适用于你自己的服务、你自己的客户端,或者你正在做安全评估并且已经获得书面授权的系统。
好,基础概念讲完了,接下来我带你把第一个包真正抓出来。
2. 从启动到保存,把目标流量完整拿到手
很多教程喜欢一上来就堆过滤器和协议原理,但我觉得对实操者来说,最要紧的是先把“从打开软件到拿到一份干净数据包”这条链路走通。这个过程看起来简单,实则藏着不少细节,每一步做不对,后续分析就是白费功夫。
2.1 选对网卡接口,别选“所有接口”
Wireshark 启动后,第一个页面就是接口列表。你说它不复杂吧,确实就是几个网卡和对应的实时流量波形图;但很多老手栽过跟头的地方,恰恰是图省事直接双击了最上面那个“所有接口”。
选“所有接口”看起来很方便,实际上会把多个网卡的流量混在一起,而且包含大量系统内部的广播包、组播包,后续过滤的时候噪音非常大,分析体验极差。
我建议你养成一个习惯:每次抓包之前,先看一眼接口列表上方的实时流量预览曲线,哪个接口此刻有持续的起伏,哪个就是当前活动的网卡。同时留意接口名称后面的描述,无线网卡通常会标注 Wireless,虚拟网卡会标注 VMnet 或者 Virtual 之类的字样。
分清物理网卡和虚拟网卡这一点很关键。很多人电脑上装了虚拟机软件以后,会多出好几块虚拟网卡,这些网卡的流量如果不小心抓错了,你看到的就是一堆虚拟机和宿主机之间的私有网络通信,跟你想分析的目标完全对不上。
接口列表里还有一个“捕获过滤器”的下拉框,可以先在这里选一个预设过滤器,比如只抓 HTTP 流量。不过我不推荐你在这一步做太多限制,因为捕获过滤器一旦设置了,在抓包过程中是改不了的,那些没被匹配的包直接就丢了。万一你后来发现其实需要分析的是另一个协议,就得重新抓一遍。我的习惯是:捕获阶段尽量全部抓取,然后用显示过滤器在现场慢慢筛。
选好接口以后,双击它就能进入实时抓包界面。到这一步,你已经成功一半了。
2.2 快速抓包的五个标准动作
我总结了五个动作,你用顺了以后会发现抓包这件事一点也不神秘。
第一个动作,启动抓包。有两种方式:双击接口,或者选中接口后点左上角的蓝色鲨鱼鳍图标。抓包进行时,顶部工具栏会显示当前捕获到的包数量,这个数字是实时跳动的。
第二个动作,复现问题。抓包不是目的,抓到你想要的那个问题的现场才是目的。比如你要排查某个接口请求超时,那就先点开始抓包,然后在浏览器里或者用命令行工具重新发起一次请求,确保问题在你抓包的时间窗口内复现了一次。这一步很多新手容易忽略,经常是抓了半天回头一看,里面根本没有相关流量,白忙一场。
第三个动作,停止抓包。点红色的方块图标,或者按 Ctrl+E。停止之后,界面上所有包保持原样呈现在列表里,方便你慢慢分析。
第四个动作,保存文件。Ctrl+S,保存格式默认是 pcapng。文件名我建议你带上日期、时间和场景关键词,比如20250118_timeout_issue.pcapng,这个习惯能让你一周以后回头找数据的时候少死很多脑细胞。
第五个动作,过滤定位。保存完以后别急着关,在顶部的显示过滤器框里输入http或tcp.port == 443,把所有相关流量筛出来,然后从第一个包开始看。
整套流程跑下来不超过一分钟,但你拿到的是可以反复回看、可以对比分析的数据,而不是靠肉眼在终端日志里瞎猜。就这一点,已经比绝大多数嘴上说“我排查过网络问题”的人专业了。
2.3 两个高频快捷键,早学早省事
Wireshark 里快捷键非常多,我真正离不开的就两个:回车是切换显示过滤器是否生效,Ctrl+E 是开始或停止抓包。前者是因为你输入过滤表达式回车之后,表达式其实并没有真正生效,需要再按一次回车确认,很多新手在这里困惑好久;后者是因为抓包动作本身就是个高频切换操作,用鼠标点效率太低了。
还有一个跟快捷键配合的小技巧:抓包的时候按 Ctrl+Shift+N,可以刷新网卡列表,这个在你插拔网线或者切换 WiFi 之后特别管用。有时候网卡状态变了,Wireshark 界面还停留在旧状态,刷新一下就都回来了。
当你掌握了快速抓包这个基本能力之后,恭喜你,真正的门槛其实才刚开始。下一章我们聊过滤器,这是 Wireshark 使用频率最高、也最容易让人头疼的部分。
3. 过滤器这关过不了,后面全是白搭
我见过太多人用 Wireshark 的姿势是:抓完包,在列表里肉眼翻找。技术好的翻个十分钟能定位到问题,技术一般的翻一小时也未必找得到关键的那几个包。其实 Wireshark 早就给你准备好了趁手的工具,只是很多人没有认真学过滤器的用法。
过滤器分两种,一种叫捕获过滤器,一种叫显示过滤器。这两个概念的区别如果不搞清楚,用起来就总是差那么一口气。
3.1 捕获过滤器和显示过滤器,到底有什么区别
捕获过滤器的作用发生在数据包进入 Wireshark 之前,它直接决定哪些包会被写入内存。它的语法沿用的是传统 BPF(伯克利包过滤器)格式,比较原始,表达能力有限,但好处是精确,能在大流量环境下降低抓包工具本身的 CPU 和内存开销。
显示过滤器则是把已经捕获到的数据包做二次筛选,它不影响数据本身,只影响你当前看到的列表。显示过滤器用的是 Wireshark 自己的语法,表达能力非常强,可以基于协议字段、字符串内容、时间关系做各种组合查询,而且你可以随时切换过滤条件,不用重新抓包。
我用一句话帮你记住两者的区别:捕获过滤器是安检员,在入场的时候就决定谁能进来;显示过滤器是筛选漏斗,所有数据都在库房里,你用漏斗随心所欲地捞你需要的部分。
实际操作中,我绝大部分时间只用一个显示过滤器。只有在目标环境流量特别大,比如每秒几万包的情况下,我才会用捕获过滤器先限制范围,防止 Wireshark 本身被流量冲垮。
3.2 高频过滤表达式速查
我按场景整理了一份速查表,这些表达式你在实际工作中会反复遇到。
| 目标 | 捕获过滤器写法 | 显示过滤器写法 |
|---|---|---|
| 只看某台主机发出的流量 | src host 192.168.1.10 | ip.src == 192.168.1.10 |
| 只看发往某台主机的流量 | dst host 192.168.1.10 | ip.dst == 192.168.1.10 |
| 只看某两台主机之间的流量 | host 192.168.1.10 and host 192.168.1.20 | ip.addr == 192.168.1.10 && ip.addr == 192.168.1.20 |
| 只看某个端口的流量 | port 8080 | tcp.port == 8080 |
| 只看 HTTP 明文流量 | port 80 | http |
| 只看 HTTPS 的握手过程 | port 443 | tls.handshake.type == 1 |
| 只看 DNS 查询 | port 53 | dns |
| 过滤掉所有 ARP 噪音 | not arp | !(arp) |
| 只看重传包 | 不适用 | tcp.analysis.retransmission |
| 只看 TCP 握手包 | tcp port 80 | tcp.flags.syn == 1 |
这里有一个很多新手会踩的坑:显示过滤器里ip.addr == 192.168.1.10 && ip.addr == 192.168.1.20表达的是“一个包里同时包含这两个地址”,而不是“这两个地址之间的通信”。想表达两者之间的通信,逻辑上应该是“源地址是 A 且目的地址是 B,或者反过来”,所以你平时看到的正确写法其实是(ip.src == A && ip.dst == B) || (ip.src == B && ip.dst == A)。
别嫌啰嗦,这个细节我见过无数人栽过。Wireshark 的ip.addr是一个特殊字段,它同时代表源地址和目的地址,所以ip.addr == A && ip.addr == B只要你脑子里想的是“A 和 B 之间的通信”,那么一次简单的抓包测试就会告诉你结果不对。
3.3 用面包屑思路拆解组合过滤
当你面对一个复杂问题时,不要指望着一条过滤器公式一步到位。我推荐你用“面包屑”思路:先宽后窄,层层剥茧。
比如有个问题:某个 Java 后端服务请求外部订单接口,偶发超时。我的过滤路径是这样的:第一步,只保留这两台机器之间的流量,用上面提到的源目组合过滤;第二步,在结果里用tcp.port == 443把范围再缩小到订单接口使用的端口;第三步,用tcp.analysis.retransmission只看重传包,一眼就能看出是不是有丢包。
这样一步一筛,逻辑非常清晰,每一步你都明确知道自己在干什么,最后定位到的问题也就可靠得多。
Wireshark 的过滤性能方面有个小建议:显示过滤器的执行速度其实非常快,在几十万包的文件里做过滤通常只需要几十毫秒。但如果你在过滤框里用了一个错误的字段名,Wireshark 会在输入框变成红底提示你,这种时候别急,点开输入框后面的“表达式”按钮,在协议列表里搜索对应的字段就行。
过滤器熟练之后,接下来的实战场景分析就顺利多了。我挑三个最高频的场景,完整走一遍分析路径。
4. 高频实战场景:把理论知识变成排障结论
场景分析是 Wireshark 的价值落地点。理论知识再扎实,最后也得落地到“这个请求为什么慢”“这个接口为什么连不上”“这个页面为什么打不开”这些具体问题上。
4.1 定位 TCP 连接建立失败
有一次,某公司的内网系统突然无法访问,服务端进程活着,端口也处于监听状态,但客户端就是连不上。我在客户端的服务器上抓包,看到的现象是:客户端不断发出 TCP SYN 包,却始终收不到服务端的 SYN-ACK。
这里我们先复习一下 TCP 三次握手:客户端发 SYN,服务端回 SYN-ACK,客户端再回 ACK,连接建立。任何一个环节缺失,连接就建立不起来。我抓到的包里只有客户端的 SYN,没有服务端的任何响应,说明问题基本可以锁定在网络路径上或者服务端的防火墙策略上。
接下来我分两条线排查:一是在服务端本机抓包,看它有没有收到 SYN。如果收到了但没回 SYN-ACK,问题出在服务端的协议栈配置或防火墙;如果服务端也没收到,那问题就在中间的网络设备上。实测结果是服务端根本没有收到 SYN,于是我进一步检查中间防火墙的安全策略,发现是最近一次变更把客户端所在网段给拦了。
这个例子想说明什么?抓包分析的核心不是看单个包,而是对比两端的时间线。A 端发了 SYN,B 端有没有收到;B 端回了 SYN-ACK,A 端有没有收到。两端各自的抓包记录一对比,问题出在哪一跳就一目了然了。
4.2 一个接口请求为什么慢了三倍
另一个经典场景是接口响应慢。前端反馈说某个列表页加载时间从 1 秒涨到了 3 秒,后端说自己数据库查询只花了 20 毫秒。两边都觉得自己没问题,那就用抓包来定夺。
我在浏览器侧抓包,请求发出后,看到第一个明显的异常:TCP 握手本身没有异常,但客户端发出 HTTP 请求之后,服务端迟迟没有返回 ACK 确认。客户端发的同一个 TCP 段被重传了好几次,每一次相隔一秒钟左右。
这就解释了你感受到的那 1 秒延迟:当客户端的包在网络中丢失时,TCP 的指数退避重传机制会先把等待时间拉长。具体那次排查的结果是服务端物理机网卡发生了大量丢包,系统日志里出现了网卡环形缓冲区溢出的记录,最后通过调整网卡队列大小和中断绑定参数解决了问题。
如果你只看应用日志,根本不会往这个方向想,因为数据库查询确实只要 20 毫秒,Tomcat 的处理时间也正常,所有应用层面的指标都是健康的。只有抓包才能看见问题出在传输层。
4.3 用 DNS 过滤快速判断域名解析异常
域名解析慢也是我经常被问到的场景。用户说某个页面打开很慢,第一屏空白好久,我第一步就用dns过滤器和http过滤器分别看一下。
DNS 的耗时可以这样估算:在 Wireshark 的包列表里找到 DNS 查询包,记下时间戳,找到对应的 DNS 响应包,两个时间戳的差值就是一次 DNS 解析的耗时。正常局域网内解析应该在几毫秒到几十毫秒,跨运营商 DNS 一般 50 毫秒左右,如果这个值超过了 200 毫秒,用户感知就会明显变差。
有一次我发现页面上某个资源域名的 DNS 查询时间长达 800 毫秒,而且响应来自一个排在后位的 DNS 服务器,说明配置的首选 DNS 服务器一直没有回应。检查之后果然是服务器上的 DNS 配置被改错了,指向了一个不可达的地址。抓包把这种“隐性故障”变成了一目了然的事实。
4.4 分析流程的心法:先看时间线,再看细节
做了这么多场景,我总结出一个对新手极其有用的分析心法:拿到一个 pcapng 文件,先别急着点开某一个包看细节,而是先用“统计”菜单下的“流量图”功能,查看整段会话的时间线全貌。
这个功能会把每个连接画成一条横向的线条,线条上有表示数据包的点和颜色的状态标记。你一眼就能看出哪些连接用了很长时间,哪些连接反复断连,哪些连接的数据量异常大。从宏观时间线确定要重点分析的连接,再双击进入细节,效率会高得多。
我在实际工作中还有一个习惯:每个分析场景都会顺便开一个新的“着色规则”,把重传包、乱序包、零窗口这些异常包用醒目的颜色标出来。这样即使包很多,异常点也会在列表里跳出来,不会淹没在正常流量里。
5. 常见问题与排查技巧实录
最后这部分,我把自己这些年踩过的坑和帮别人排查过的典型问题集中整理一下。这些经验在 Wireshark 官方文档里不一定看得到,但你在实际操作中几乎一定会遇到。
5.1 抓不到包?先按这个顺序自查
抓包最让人崩溃的事情就是:明明在抓,列表却始终没有新流量进来。我通常按以下顺序一步步排查。
先检查接口选对没有。你正在用的网卡是哪个,就要在 Wireshark 里选那个接口,虚拟网卡、Loopback 接口都跟物理网卡不一样,选错了自然什么都看不到。上下滑动接口列表,找到名字和描述跟你实际使用的一致,再开始抓。
再确认流量确实途径这台设备。你抓本机和公网之间的流量肯定没问题,但如果你想让抓包设备看到另一台设备的流量,就必须依靠交换机镜像或者集线器,普通交换机端口不会把别人的流量复制给你。很多人以为连了同一个交换机就能互相抓包,这个认知是错的。
然后检查混杂模式是否被系统关闭。Windows 下如果 Npcap 版本太老,或安全软件启用了数据包拦截,混杂模式可能失效,解决办法是升级 Npcap 并检查安全软件设置。Linux 下可以执行ip link查看网卡状态,确认没有启用一些特殊的转发隔离参数。
最后确认是不是加密流量让你误以为没抓到。如果你访问的是 HTTPS 网站,抓到的包在列表里确实也能看到,但内容区域只会显示 TLS 加密后的数据,你会觉得“什么信息也没有”。这种感受不代表没抓到包,只是没有解密而已。可以用tls.handshake过滤器筛一下,如果确实存在 TLS 握手包,那说明抓包本身没问题。
5.2 看到一个 TCP 连接的完整生命周期
分析 TCP 连接,最直观的方式是右键点击任何一个 TCP 包,选择“追踪流”里的“TCP 流”。Wireshark 会把这条连接的所有包按时间顺序排列在一个窗口里,并自动把传输层的数据内容重新组合出来。
如果数据本身是 HTTP 明文,你在这个窗口里能直接看到请求行、请求头、响应状态码和响应体,定位接口问题是相当舒服的。如果是 HTTPS 加密流量,它显示的就是无法解读的密文,这种情况就要用到下一节的内容了。
关于 TCP 流的分析,我还想特别说一个概念:TCP 流在 pcapng 文件里的编号。当你打开一个抓包文件,Wireshark 会给每一条独立的 TCP 连接编号,从 0 开始。这个编号在“统计”菜单里的“会话”表中可以看到。当你怀疑一个接口慢是某个连接复用导致的,可以先把这条流的所有包过滤出来,再根据时间线逐段分析。
5.3 TLS 加密流量到底能不能看
很多人在真正上手 Wireshark 之后都会问:现在全网都是 HTTPS,抓包是不是就没意义了?这个问题要分两层回答:第一,TLS 握手的元数据永远能看到;第二,TLS 加密的内容可以在特定条件下解密。
握手阶段的可见信息非常丰富:客户端支持的 TLS 版本、加密套件列表、服务器证书信息、密钥交换参数、证书链是否存在问题、OCSP 查询是否失败,这些全在包里面。如果你负责的服务提示“证书过期”,你甚至不用登服务器,直接在客户端抓包看证书的有效期字段就能定位。
至于解密内容,前提是你必须拥有密钥。最常用的方式是利用环境变量SSLKEYLOGFILE,浏览器和部分应用程序在启用这个变量后,会把每次会话的对称密钥写到一个本地文件里,Wireshark 拿到这个文件就能解开对应的加密流量。
具体操作为:先设置一个环境变量指向某个文件,例如export SSLKEYLOGFILE=/tmp/keys.log,然后用这个环境启动浏览器,正常访问目标网站,最后在 Wireshark 的“首选项”里找到“TLS 协议”,把密钥文件路径填进去。刷新页面重新抓包,看到的内容就变成明文了。
方法本身不复杂,但我必须再次强调边界:这只适用于你自己发起的流量、你自己部署的服务,或者你明确有权限做安全评估的资产。密钥文件泄露的风险极大,任何人拿到它都能解开你的加密会话,所以用完以后记得清理,别把它留在生产服务器上。不要问“那别人的 HTTPS 流量能不能解”,答案你心里清楚,这个问题本身就不该提。
5.4 长时间抓包时,别忘了性能问题
最后聊一个经常被低估的细节:抓包工具本身的开销。Wireshark 在图形界面下抓包时,需要把每个数据包复制一份,再做协议解析和界面渲染,数据量大了以后,CPU 占用率和内存占用都会明显上涨。如果是在生产服务器上长时间抓包,这个问题尤其需要注意。
一个比较健康的方案是:需要长时间抓包时,不要开着 Wireshark 图形界面一直挂着,而是用 tshark 命令行工具抓到一个文件里,事后再用 Wireshark 图形界面分析。
sudo tshark -i eth0 -w /tmp/tshark_output.pcapng -b duration:300这条命令的含义是:从 eth0 网卡抓包,写入/tmp/tshark_output.pcapng,每 300 秒滚动生成一个新文件。滚动文件的机制能避免单个文件过大导致磁盘空间被撑满,同时也方便事后按时间段分段分析。走到这一步,你已经具备独立完成一次规范的抓包排障任务的所有能力了。
抓包这个技能,我可以负责任地说,属于投入产出比极高的一类:你只需要花一个下午把基础操作跑通,再花几天把过滤器和常见协议的状态机弄明白,之后几乎所有网络相关的问题排查,你都能用数据说话,而不是跟同事互相甩锅。Wireshark 不会替你判断结论,但它能给你最可靠的证据。学会用它观察网络,就等于给自己装了一双可以透视数据通路的眼睛。