Wireshark抓包工具的使用：网络故障分析与攻击取证
摘要：## 当网络“抽风”时，我靠这个免费工具，把黑客和BUG都揪出来 前两天，一个做电商的朋友半夜给我打电话，声音都带着哭腔：“哥，网站后台突然卡成PPT，客服电话被打爆了，运维查了半天说服务器CPU、内存都正常，这到底啥情况啊？” 我让他别慌，先别急着重…
当网络“抽风”时，我靠这个免费工具，把黑客和BUG都揪出来
前两天，一个做电商的朋友半夜给我打电话，声音都带着哭腔：“哥，网站后台突然卡成PPT，客服电话被打爆了，运维查了半天说服务器CPU、内存都正常，这到底啥情况啊？”
我让他别慌，先别急着重启服务器（重启大法好，但会销毁证据）。我远程过去，做的第一件事，不是看日志，也不是调配置，而是默默打开了电脑上一个“上古神器”——Wireshark。
十分钟后，我告诉他：“不是被攻击了，是你家那个新上线的促销活动接口，有个蠢到家的死循环，每秒在疯狂内耗，自己人打自己人。”
问题定位，解决。他长舒一口气，问我用的是什么“高级监控”。我乐了：“哪有什么高级的，就是最老牌、最免费的那个抓包工具，Wireshark。”
说白了，在网络安全和运维这行干久了，你会发现，最复杂的故障，往往需要最基础的视角来还原。而Wireshark，就是那个能让你直接“听到”网络原始对话的听诊器。
一、别被“抓包”吓到，它其实就是网络的“电话录音”
很多人一听到“抓包”、“协议分析”，头就大了，觉得这是极客的专属。其实吧，你可以把它理解得特别接地气。
想象一下，你的整个公司网络就是一个巨大的开放式办公室，所有电脑、服务器、手机都在里面用“网络语言”喊话交流。平时秩序井然，你听不清具体内容。突然有一天，办公室变得异常嘈杂，工作效率暴跌。
这时候，Wireshark就相当于你在办公室正中央，架起了一个超级灵敏的录音设备，把所有“喊话”的内容、谁喊的、对谁喊的、喊的啥，一字不落地记录下来。
- 网络卡顿？ 就像录音里听到A对B喊话，B半天不回应，A就不停地重喊，占用了所有频道——这就是TCP重传泛滥，可能是线路问题或者B（服务器）处理不过来了。
- 遭遇攻击？ 就像录音里突然出现几百个陌生声音，用同样的内容对C（你的网站）进行复读机式的骚扰，让C无法处理正常对话——这很可能就是CC攻击的现场。
- 程序BUG？ 就像听到A对B喊了一句不符合语法的“黑话”，B当场死机，然后A还不停地喊——这就是我朋友遇到的情况，异常报文导致的资源耗尽。
所以，Wireshark的第一个核心价值：它不撒谎。日志可能被篡改，监控图表可能被平均，但抓到的一手数据包，就是事实本身。
二、真出了事，Wireshark怎么帮我“断案”？
光有录音没用，你得会听。下面我结合两个最常见的场景，说说我是怎么“听”的。
场景1：网站时快时慢，业务部门总抱怨——“网络故障分析”
这种问题最磨人，时好时坏。我的排查思路通常是这样：
- 先抓包，别废话。 在出问题的客户端或者流量必经的服务器上（比如网关），开Wireshark，开始捕获。最好能复现一下问题，比如让业务同事点一下那个慢的页面。
- 过滤器是“神器”。 全量抓包数据海了去了，你得用过滤器。比如，网站慢，我就先看和Web服务器的对话：
ip.addr == 你的服务器IP && tcp.port == 80（HTTP）或443（HTTPS）。瞬间，世界清静了，只剩下你和服务器的“二人转”。 - 关键指标，一眼定乾坤。
- 看TCP握手（SYN, SYN-ACK, ACK）： 建立连接快不快？有没有SYN发了没回应的？（可能是防火墙拦截或服务器端口没开）
- 看“时间”列： 这是Wireshark分析网络延迟的宝藏。重点关注 “Time since previous frame” （距上一帧时间）。如果某个请求发出去后，隔了好几秒才收到响应，那瓶颈就在服务器处理环节。如果每个包都间隔很久，可能是网络链路延迟或拥塞。
- 看TCP窗口大小： 如果窗口值变得很小，说明接收方（比如你的浏览器）忙不过来了，在告诉发送方“慢点发”，这也会导致传输变慢。
- 看重传（Retransmission）： 数据包丢了，TCP会重传。如果满屏都是重传包（标为黑色或红色），别犹豫，网络链路有问题（比如交换机、网卡、网线），赶紧找基础设施团队。
说白了，分析慢，就是找“等”的过程。 Wireshark帮你精确地定位到：是在等网络传输，还是在等服务器思考。
场景2：服务器突然CPU飙高，连接数爆炸——“攻击取证”
这时候气氛就比较紧张了。攻击往往来势汹汹，你要做的是快速识别并拿到证据。
- 快速捕获，保存证据。 第一时间在受影响服务器上抓包，抓个几十万包就停，赶紧存成
.pcap文件。这是原始证据，比任何截图都有力。 - 统计功能是“雷达”。 别傻看一个个包，点开 “统计” -> “对话” 。这里会按流量、包数排序，把所有通信对端列出来。
- 如果发现某个外部IP，在短时间内发起了成千上万的连接（看包计数），但每个连接只发一个小包（比如SYN，或HTTP GET），然后就没下文了——恭喜，你很可能遇到了SYN Flood或CC攻击的雏形。
- 如果发现大量连接都指向同一个URI，比如
/api/login，而且频率极高，那就是典型的CC攻击，在刷你的登录接口。
- 追踪攻击流。 在“对话”里找到可疑IP，右键 -> “应用为过滤器” -> “选中 … A<->B”。现在，画面里就只剩下你和攻击者的“聊天记录”了。
- 看Payload（载荷）。 如果是应用层攻击（比如HTTP Flood），展开数据包，你能看到完整的HTTP请求。攻击者的User-Agent、特殊的HTTP头、请求参数，都是宝贵的指纹信息。 把这些信息提取出来，立刻加到你的WAF（Web应用防火墙）黑名单或者高防IP的防护策略里，进行精准封堵。
- 别忘了看DNS。 有些攻击会伴随大量的DNS查询，把DNS服务器也拖垮。用过滤器
dns看一眼，如果全是针对你域名的畸形查询，那也是攻击特征。
取证的核心，是从海量噪音中，提取出攻击者的“行为模式”和“身份特征”。 Wireshark就是这个显微镜。
三、一些“人肉”出来的实战心得和坑
用了这么多年，有些经验是说明书里没有的：
- 别在核心生产服务器上长时间抓包。 抓包本身耗资源（尤其是磁盘I/O），可能让故障雪上加霜。抓够证据就停。
- 过滤器语法，记几个常用的就行。
ip.src、ip.dst、tcp.port、http、dns。组合使用，比如http and ip.addr==1.1.1.1。记不住？没关系，Wireshark有自动补全和颜色标记，你点一下某个IP或端口，右键就能“作为过滤器应用”。 - 面对HTTPS（密文）怎么办？ 这是常见误区。Wireshark确实看不到HTTPS的应用层内容，但TCP/IP层和TLS握手层的元数据全在啊！ 你依然能看到连接来自哪里、频率多高、握手是否成功、证书是否异常。对于判断DDoS、连接耗尽等攻击，这些信息足够了。要解密内容？那需要配置服务器的私钥，在可控的内部分析环境做，线上别想。
- 从“恐惧”到“依赖”。 新手看Wireshark，满屏十六进制，头晕。我的建议是：别一开始就试图读懂每个字节。先学会用统计视图和过滤器，找到异常点，再双击某个可疑的包，看看Wireshark已经帮你解析好的、树状结构的协议详情。这工具就像学游泳，在岸上看永远学不会，跳下去扑腾几次，自然就会了。
最后说句大实话：在现在这个云原生、全监控的年代，Wireshark看起来有点“古典”。很多高级的APM（应用性能监控）和NTA（网络流量分析）工具确实更直观、更自动化。
但是，当所有高级工具都告诉你“有问题”，却指不出“问题具体在哪”的时候，Wireshark永远是那个最后可以托底的、给你最原始真相的“老伙计”。 它不华丽，但足够锋利。
所以，如果你的服务器还在裸奔，或者你的运维工具箱里还没有它，我建议你，现在就下载一个试试。下次再遇到那种“薛定谔的网络故障”时，你至少能有一种方法，去亲手揭开谜底。
行了，不废话了，抓包去吧。