简介《Wireshark网络分析的艺术》配套资料包面向网络管理员、开发人员及网络安全从业者帮助读者从抓包入门进阶到协议解析与故障定位。内容围绕Wireshark的安装配置、捕获与显示过滤器、TCP/IP协议栈各层解析展开并延伸至TCP连接建立与关闭、HTTP请求响应细节、网络性能分析与延迟丢包排查以及嗅探、中间人攻击、SQL注入等安全检测场景兼顾协议学习与实战排错。资源包共5个文件以pdf电子书为主体辅以htm网页资料、docx文档与txt说明压缩包约28.8MB便于离线阅读与查阅。目前已有589人学习下载适合希望系统掌握Wireshark使用技巧、深入理解网络通信本质并提升实际分析能力的读者参考。1. Wireshark网络分析的艺术从抓包到看懂一次TCP重传很多人装完 Wireshark打开网卡看到满屏滚动的数据包第一反应是“这玩意儿到底在看什么”。我见过太多人抓了一堆包最后只会在过滤框里敲个 http然后对着几百条记录发呆。Wireshark 网络分析的艺术核心不在抓而在“看懂”——看懂一次 TCP 重传为什么发生、看懂 HTTP 请求为什么卡在某个响应、看懂 ARP 风暴是怎么把交换机打瘫的。这篇笔记面向的是已经会点“开始捕获”但不知道怎么往下走的运维和开发也面向想系统补齐排障能力的后端工程师。我会从抓包环境准备讲到过滤语法、TCP 流追踪、典型故障定位最后落到几个我踩过的坑。读完你至少能做到拿到一个“网络慢”的反馈知道先抓哪、怎么过滤、看哪个字段。2. 抓包前的环境准备与网卡选型2.1 为什么“选错网卡”是第一个翻车点Wireshark 安装本身没什么难度Windows 下 Next 到底就行Linux 下apt install wireshark或yum install wireshark也够用。真正容易出问题的是网卡选择。很多人笔记本上同时有有线网卡、无线网卡、虚拟网卡VMware、VirtualBox、Docker 创建的 bridgeWireshark 的接口列表里一长串随手选一个就开始抓结果抓了半天全是无关流量。我一般会先确认目标流量走的是哪块网卡。如果是排查本机访问外部服务的延迟走的是物理网卡如果是排查本机两个容器之间的通信走的是 Docker 的 bridge 接口如果是排查虚拟机里的服务得在宿主机对应的虚拟网卡上抓。一个简单的判断方法先ping一下目标地址然后在 Wireshark 接口列表里看哪块网卡的流量在跳。提示Windows 上如果看不到物理网卡检查是否装了 Npcap 驱动Wireshark 安装时会提示别跳过。2.2 捕获选项里必须改的三个参数默认的捕获选项在大多数场景下不够用我通常会改三个地方。第一个是捕获缓冲区大小。默认值偏小在高流量场景下容易丢包。我一般设成 256 MB 或更高具体看内存。第二个是混杂模式。如果抓的是本机流量关掉混杂模式反而更干净如果抓的是交换机镜像口流量必须打开。第三个是捕获过滤器。很多人忽略这个直接全量抓结果文件几个 G分析时卡到崩溃。捕获过滤器的语法和显示过滤器不同它用的是 BPF 语法。比如只抓 80 端口的流量# 捕获过滤器示例只抓 80 端口 tcp port 80如果要抓某个 IP 的流量# 捕获过滤器示例只抓 192.168.1.100 的流量 host 192.168.1.100这两个可以组合# 捕获过滤器示例抓 192.168.1.100 的 80 端口流量 host 192.168.1.100 and tcp port 80逻辑说明捕获过滤器在驱动层生效不匹配的包直接丢弃不写入内存。参数说明host后面跟 IP 或域名tcp port后面跟端口号and、or、not是逻辑运算符。注意捕获过滤器不支持http这种应用层关键字那是显示过滤器的能力。2.3 显示过滤器的常用组合与踩坑抓完包之后显示过滤器才是真正干活的工具。新手最容易犯的错是把捕获过滤器和显示过滤器搞混。捕获过滤器在抓之前设显示过滤器在抓之后设。显示过滤器支持应用层协议比如http、dns、tcp.analysis.retransmission。我常用的几个组合# 只看 HTTP 请求和响应 http.request or http.response # 只看 TCP 重传 tcp.analysis.retransmission # 只看某个 IP 的流量 ip.addr 192.168.1.100 # 只看 DNS 查询 dns.qry.name contains example.com逻辑说明tcp.analysis.retransmission是 Wireshark 内置的分析字段标记了疑似重传的包。参数说明ip.addr匹配源或目的 IPdns.qry.name匹配 DNS 查询名。注意contains是模糊匹配是精确匹配。注意显示过滤器里tcp.port 80和tcp.srcport 80不一样前者匹配源或目的端口后者只匹配源端口。排查服务端问题时通常用tcp.srcport 80看服务端发出的包。3. 用 TCP 流追踪定位一次真实的重传故障3.1 从“网络慢”到“找到重传包”有一次同事反馈某个内部服务响应特别慢但服务端日志显示处理时间只有几十毫秒。这种“服务端说快、客户端说慢”的情况十有八九是网络层出了问题。我在客户端抓包先过滤出目标服务的流量# 显示过滤器目标服务 IP 和端口 ip.addr 10.0.1.50 and tcp.port 8080然后看tcp.analysis相关的字段。Wireshark 在专家信息里会汇总重传、乱序、重复 ACK 等异常。我直接看tcp.analysis.retransmission发现有好几个包被标记为重传。3.2 追踪 TCP 流看完整交互过滤出重传包之后右键任意一个包选择“追踪 TCP 流”。Wireshark 会把整个 TCP 会话的交互按时间顺序展示出来。这时候重点看几个东西重传发生的时间点和前后包的间隔服务端是否收到了重复 ACK窗口大小是否突然变小我那次的情况是客户端发出请求后服务端很快回了 ACK但数据包迟迟没到。客户端等了一段时间后触发重传。追踪流里能看到服务端的发送窗口从 65535 降到了 4096说明服务端侧有拥塞或缓冲区不足。3.3 关键字段解读RTT、窗口、MSS在追踪流里Wireshark 会显示每个包的相对时间。我一般关注三个指标字段含义异常表现RTT往返时间突然增大说明链路拥塞Window Size接收窗口持续变小说明接收方处理不过来MSS最大报文段长度协商值过小说明路径 MTU 有问题那次故障的根因是服务端所在主机的 TCP 缓冲区设置偏小高并发时窗口迅速缩小导致客户端频繁重传。调整内核参数后问题消失。# 查看当前 TCP 缓冲区设置 sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem # 临时调大接收缓冲区 sysctl -w net.ipv4.tcp_rmem4096 87380 6291456逻辑说明tcp_rmem三个值分别是最小、默认、最大接收缓冲区。参数说明调大最大值可以缓解高并发下的窗口收缩。注意这只是临时生效持久化需要写进/etc/sysctl.conf。4. 避开 Wireshark 使用中的五个血泪坑4.1 抓包文件过大导致分析卡死现象抓了半小时文件 2 GB打开时 Wireshark 无响应。原因全量抓包没有设捕获过滤器且缓冲区设得太大内存被占满。解决抓包前一定设捕获过滤器只抓目标流量。如果已经抓了大文件用editcap切割# 按时间切割每 60 秒一个文件 editcap -i 60 big.pcap split.pcap4.2 中文显示乱码现象HTTP 请求里的中文显示为乱码或问号。原因Wireshark 默认按 ASCII 解析没有识别字符集。解决在 HTTP 协议首选项里把“解码为”设置为 UTF-8。或者手动在包详情里右键选择“显示为”然后指定编码。4.3 抓不到本机回环流量现象本机服务之间用 localhost 通信Wireshark 抓不到。原因回环流量不走物理网卡Windows 上尤其明显。解决Windows 下需要装 Npcap 并勾选“支持回环流量”或者用RawCap工具。Linux 下直接抓lo接口即可。4.4 时间戳不准导致误判现象两个包的时间差看起来很大但实际业务没感觉慢。原因Wireshark 默认用系统时间如果系统时间被 NTP 调整过时间戳会跳变。解决在捕获选项里把时间戳精度设为纳秒并确保系统时间同步。分析时用“相对时间”而不是“绝对时间”。4.5 过滤语法写错导致漏包现象明明有 HTTP 流量但http过滤器显示为空。原因流量走的是 HTTPS或者端口不是 80。解决先用tcp.port 443确认是否有流量再用tls过滤器看握手。如果是非标准端口用tcp.port 自定义端口加http组合过滤。5. 进阶用 tshark 做批量分析与自动化排查5.1 为什么我最终转向了 tsharkWireshark 的图形界面适合交互式排查但如果你要分析几十个抓包文件或者要把分析结果接入监控系统图形界面就力不从心了。tshark 是 Wireshark 的命令行版本功能几乎一样但可以脚本化。我现在的习惯是先用 Wireshark 图形界面定位问题类型然后用 tshark 写脚本批量验证。比如每天早上跑一遍前一天的抓包文件统计重传率。5.2 用 tshark 统计 TCP 重传率# 统计单个文件的重传包数量 tshark -r capture.pcap -Y tcp.analysis.retransmission -T fields -e frame.number | wc -l # 统计总包数 tshark -r capture.pcap | wc -l逻辑说明-r指定读取文件-Y指定显示过滤器-T fields -e frame.number只输出帧号。参数说明wc -l统计行数。把两个结果一除就是重传率。如果要批量处理一个目录下的所有 pcap 文件#!/bin/bash # 批量统计重传率 for file in /path/to/pcaps/*.pcap; do total$(tshark -r $file 2/dev/null | wc -l) retrans$(tshark -r $file -Y tcp.analysis.retransmission 2/dev/null | wc -l) if [ $total -gt 0 ]; then rate$(echo scale4; $retrans / $total | bc) echo $file: total$total, retrans$retrans, rate$rate fi done逻辑说明循环遍历目录下所有 pcap 文件分别统计总包数和重传包数计算比率。参数说明2/dev/null屏蔽 tshark 的警告信息bc用于浮点运算。注意这个脚本在包量很大时会比较慢可以加-c限制只读前 N 个包。5.3 用 tshark 提取 HTTP 响应时间# 提取 HTTP 请求和响应的时间差 tshark -r capture.pcap -Y http.response -T fields -e frame.time_relative -e http.response.code -e http.time逻辑说明http.time是 Wireshark 计算的请求到响应的时间差。参数说明frame.time_relative是相对第一个包的时间。这个输出可以直接导入 Excel 做趋势图。5.4 一个我常用的排查习惯我现在遇到网络问题第一步不是打开 Wireshark而是先问三个问题影响范围是一个客户端还是所有客户端是持续慢还是偶发最近有没有改过网络配置或发布过新版本这三个问题的答案能帮我决定是在客户端抓、服务端抓还是在中间设备抓。抓包的时候我习惯同时开两个 Wireshark 实例一个抓客户端一个抓服务端。对比两边的时间戳和包序号能快速判断丢包发生在哪一段。这个习惯帮我省了很多“扯皮”的时间——到底是网络的问题还是应用的问题两边一对比就清楚了。提示如果两端时间不同步对比时间戳会误导。抓包前先确认 NTP 状态。最后说一个我踩过的坑有一次排查一个偶发的超时问题抓了好几次包都没复现。后来把捕获缓冲区调到 512 MB并且把抓包时间延长到 24 小时才抓到那个每几小时才出现一次的异常包。所以有时候不是分析技巧的问题是抓包策略的问题。希望帮到你。本文还有配套的精品资源点击获取