Wireshark抓包实战：过滤器、TCP重传与RTP流还原全指南

简介：Wireshark 是网络协议分析与抓包排查的常用工具，这份 1 个 PDF 的教程面向软件开发、网络运维及协议学习者，旨在以清晰的界面拆解帮助读者理解 TCP/IP 中各协议的实际工作过程。全文从启动界面入手，逐一介绍文件菜单、主工具栏、过滤工具栏以及 Packet List、Packet Detail、Packet Bytes 等面板的作用；同时详细说明菜单栏中 File、Edit、View、Analyze、Statistics 等常用功能，并重点讲解捕捉过滤器与显示过滤器的区别、语法规则和应用场景，包括协议、方向、主机、逻辑运算等过滤表达式的写法，便于读者在庞杂的抓包结果中快速定位目标数据。资源为单个 PDF 文件，大小仅 2.26MB，内容紧凑、目录清晰，适合作为 Wireshark 入门与查阅的手册。目前已有 555 人学习，对于希望系统掌握抓包分析、理解网络协议的开发者来说具有较好的参考和实战指导价值。

1. 抓包不是点一下开始，Wireshark 的门道在过滤器和分析视角

很多人在生产环境排查慢请求或协议兼容问题时，打开 Wireshark 点一下绿色鲨鱼图标，抓了一大堆包，然后盯着满屏的乱码不知从何下手。这不是个例——Wireshark 的安装包只有几十 MB，但它的价值从来不在「能抓到包」，而在「能不能把包变成结论」。一个 TCP 重传率超过 5% 的接口调用，一份带时间戳和过滤器的抓包文件，能直接省掉后端开发半天的心跳排查；而一份没加过滤器的全量抓包，只会让所有人盯着 10 万行未知流量发呆。

这篇教程按「先懂捕获原理 → 配好抓包参数 → 掌握分析视图 → 深入协议解码 → 搞定流媒体和长时抓包」的顺序展开，覆盖从 Wireshark 安装到 RTP 流还原的完整路径。适合刚入门的运维、后端开发，也适合需要处理 PCAP 取证和协议调试的网络工程师——第五章的 tshark 命令行和 RTP 视频还原技巧，对五年以上从业者也有参考价值。核心就一句话：Wireshark 是过滤器驱动的工具，不会写过滤表达式，就等于只会截屏。

2. Wireshark 安装与捕获前置：先定版本，再定抓包位置

2.1 为什么 Wireshark 4.0 是当前最稳的选择

Wireshark 的版本迭代很快，但选版本不能只看新。4.0 系列是分水岭：它把默认显示过滤器语法升级到了 2.0 风格，同时引入了pcapng文件的原生加密支持，还优化了多线程解包性能。对普通用户来说，4.0 之后的界面改动集中在「视图 → 时间显示格式」里增加了相对时间戳的毫秒精度选项，这对分析延迟问题非常重要。而 4.4 之后的版本适合需要新协议解析器的场景，比如 HTTP/3 的 QPACK 动态表调试。

安装时有个容易被忽略的选项：安装 Npcap（Windows）或 libpcap（Linux/macOS）。Wireshark 本身不负责抓包，它只是前端，真正的捕获引擎是 Npcap。如果安装时取消了 Npcap 组件，后面会看到「No interfaces found」的报错，这正是热搜词里「wireshark 打不开」「wireshark 为什么一直卡住」最常见的根源之一。

2.1.1 快速验证安装是否成功的两条命令

# Windows 验证 Npcap 服务状态 sc query npcap # Linux 验证 libpcap 版本 tshark --version

第一条命令返回RUNNING状态说明 Npcap 服务正常；第二条命令会同时输出 Wireshark 和 tshark 的版本号。如果 tshark 不存在，说明安装时没勾选命令行工具，重装时补上即可。验证完这两条，再打开 Wireshark 就不会遇到「接口列表空白」的尴尬。

2.2 捕获接口怎么选：管理口、业务口和数据口不是一回事

一台服务器上可能有多块网卡：管理口、业务口、备份口。抓包选错接口是新手最常见的错误——把抓包接口选成了管理口，结果业务流量全部旁路。判断方法是看「捕获 » 选项」对话框里每个接口的「每秒数据包数」实时滚动值。通常业务口的包速率远高于管理口，如果你看到两个接口速率差不多，那可能是交换机做了端口镜像，此时应该选镜像口。

选好接口后，在「捕获选项」里有一个「混杂模式」复选框。默认勾选，这意味着可以抓到非本机 MAC 地址的广播帧。如果抓不到目标流量但接口速率正常，先取消混杂模式再试——有些虚拟化平台（VMware、KVM）的虚拟交换机对混杂模式有特殊处理，反而需要关闭才能收到目标流量。

2.2.1 一块网卡抓多个 VLAN 的配置方法

# Linux 下为 eth0 创建 VLAN 子接口 sudo ip link add link eth0 name eth0.100 type vlan id 100 # 开启子接口 sudo ip link set eth0.100 up # Windows 下需要安装 Npcap 的 VLAN 支持并启用 802.1Q 标签

创建 VLAN 子接口后，Wireshark 的接口列表里会出现eth0.100，此时抓这个子接口就只包含 VLAN 100 的流量。原理是内核协议栈会在收包时自动剥离 VLAN 标签，Wireshark 拿到的是已经被识别为特定 VLAN 的纯 IP 包。这么做的好处是过滤压力小，因为抓包点提前就做了分流，不需要在 Wireshark 里再写vlan.id == 100这样的显示过滤器。注意：抓物理接口eth0依然能看到所有 VLAN 流量，只是每个包都会附带一个802.1Q头部，分析时要多一层解码。

3. 抓包核心参数：三种捕获过滤器与显示过滤器的本质差别

3.1 捕获过滤器是 BPF，显示过滤器是 Wireshark 语法，别混用

Wireshark 里有两套过滤系统，混用会直接导致抓不到包或显示异常。捕获过滤器在抓包前生效，用的是伯克利包过滤器（Berkeley Packet Filter, BPF）语法，它的作用是从源头丢弃不感兴趣的包，节省磁盘写和内存开销；显示过滤器在抓包后生效，作用于已经抓到的数据包，语法是 Wireshark 自定义的，支持字段级匹配。

有一个典型场景能说清两者差别：你想抓一台服务器和10.0.0.5之间的所有 HTTP 流量。如果写显示过滤器http && ip.addr == 10.0.0.5，抓包文件里依然会存下所有非 HTTP 流量，只是界面不显示；如果写捕获过滤器tcp port 80 && host 10.0.0.5，那么文件里只有 80 端口的包，后续用显示过滤器也找不回被丢弃的包。

注意：捕获过滤器不含ip.addr这种 Wireshark 层字段，它只有host、net、port、portrange等 BPF 原语。在「捕获选项」输入框里写ip.addr == 1.1.1.1会直接报错，因为 BPF 不认识ip.addr。

3.2 长时间抓包的三个必调参数：环形缓冲区、文件大小和 SIGUSR1

热搜词里「wireshark 长时间抓包怎么操作」是高频查询。在图形界面里点开始抓包然后挂一晚上，很可能第二天早上发现磁盘满了或者 Wireshark 卡死——因为默认情况下抓包文件是无上限增长的，而且 UI 渲染实时刷新的数据包列表本身就很消耗 CPU。生产环境长时间抓包，正确姿势不是打开图形界面挂着，而是用 tshark 配合环形缓冲区。

# 使用 tshark 做 24 小时抓包，每个文件 500MB，最多保留 20 个文件 tshark -i eth0 -f "tcp port 443" -b filesize:524288 -b files:20 -w /data/capture/$(date +%Y%m%d).pcapng

参数说明：-i eth0指定网卡；-f后跟捕获过滤器，这里只抓 443 端口；-b filesize:524288表示单个文件写到 512MB（单位是 KB）就滚动切换；-b files:20表示最多保留 20 个文件，超过后自动删除最早的。这样磁盘占用被锁死在 10GB 以内，且 Wireshark 的 UI 完全不参与，不会卡。抓完后用capinfos /data/capture/*.pcapng | grep "Capture duration"验证总时长是否符合预期。

Windows 下没有tshark的环境变量，需要去安装目录（默认C:\Program Files\Wireshark\）运行，或者把目录加进 PATH。还有一条更隐秘的技巧：tshark 支持在抓包期间通过信号控制滚动。Linux 上向进程发SIGUSR1会强制 tshark 立即关闭当前文件并切换到新文件，这比依赖 filesize 更精确：

# 找到 tshark 的 PID 后手动触发滚动 kill -USR1 $(pgrep -f "tshark -i eth0") # 对于每个滚动文件自动执行后续分析 # 配合 inotify 监听目录，新文件出现后立即跑分析命令 inotifywait -m /data/capture/ -e close_write | while read path action file; do tshark -r "/data/capture/$file" -Y "http.response.code >= 500" done

这段命令组合的核心逻辑是：tshark 写文件，inotify 监控文件写入完成事件，一旦完成就触发分析。增量式处理比等抓完再统一分析更省内存，适合长时抓包场景。

3.3 捕获选项里几个容易被忽略的字段

在「捕获选项」对话框底部有几个字段：缓冲区大小（Buffer size）、更新间隔（Update interval）、限制每个包的长度（Limit each packet to）。缓冲区的单位是 MB，它决定 Wireshark 临时存储捕捉数据的预留内存大小。高吞吐场景（比如万兆网卡）建议设到 200MB 以上，否则内核缓冲一满，丢包率会直线上升，界面右下角会出现「XX packets dropped」的红色提示。

限制每个包的长度是个双刃剑：设成 128 字节可以大幅降低磁盘占用，但会截断 payload——TCP payload 的 128 字节之外的内容全丢失。这导致两种结果：一是无法做流量还原（比如 HTTP 的 response body 还没到 128 字节就丢了），二是协议状态机能看到的序列号信息不完整。建议默认 262144 字节，只在确研究包长分布时才调小。

4. 抓包后的三种分析路径：主界面、统计菜单和 tshark 二次加工

4.1 主界面五栏布局与第一眼判断法

打开一个抓好的 pcapng 文件，默认界面从上到下依次是：显示过滤器栏、数据包列表（Packet List）、数据包详情（Packet Details）、数据包字节（Packet Bytes）。列表窗格的关键列有No.、Time、Source、Destination、Protocol、Length、Info。第一眼判断网络是否健康，不是看有没有红字，而是看三组数据：

• Protocol 列的分布：如果 ARP 请求占比超过 10%，大概率是 IP 地址冲突或二层环路。
• Time 列的时间差：连续两个包的 Time 差超过 1 秒，就是延迟点。
• Info 列的标记：出现[TCP Retransmission]、[TCP Dup ACK]、[TCP Fast Retransmission]时，说明传输链路存在丢包或乱序。

4.1.1 调整时间显示为相对时间

查看「视图 » 时间显示格式 » 自纪元起的秒数（Seconds Since Epoch），或者选择「相对日期和时间」（Relative Time with Date）。排查性能问题时用「自上一抓包数据包的秒数」（Seconds Since Previous Captured Packet）最直观——每个包显示与上一个包的时间间隔，这样就能秒级定位哪个包产生了 300ms 以上的等待：

No. Time (s) Source Destination Protocol Info 1 0.000000 10.0.0.1 10.0.0.2 TCP 80 → 443 [SYN] 2 0.287114 10.0.0.2 10.0.0.1 TCP 443 → 80 [SYN, ACK]

包 1 和包 2 之间隔了 287ms，这个值远超局域网正常范围（通常是 1ms 以内），说明请求到达服务器后应用层处理了一次用户态切换或排队，问题定位在服务端处理逻辑，而不是网络链路。

4.2 统计菜单：不写过滤器也能定位流量热点

统计菜单里有几个入口不需要任何过滤语法，但能快速抠出问题。第一个是「统计 » 协议分级」（Protocol Hierarchy），它展示各协议占流量的百分比树状图。如果 TCP 虽然占比 95%，但其中 70% 是重传包，这里会直接显示TCP Retransmission子节点并标注数量，一步得出「链路层干净、传输层在疯狂重传」的结论。

第二个是「统计 » 流量图」（I/O Graph）。默认有五条色线：TCP 速率、UDP 速率、TCP 错误（Errors）等。当 TCP Errors 曲线和 TCP 速率曲线同步上升时，说明业务在死亡边缘挣扎。菜单里可以新增一条 Y Axis 设置为Packets、Filter 写tcp.analysis.retransmission的曲线，用红色显示——这样一条重传率曲线就出来了：

# 等价的 tshark 命令，输出每秒重传数 tshark -r capture.pcapng -q -z io,stat,1,"tcp.analysis.retransmission"

-q表示安静模式，去掉抓包时的实时显示，只输出统计结果；-z是统计模块的入口，io,stat,1表示以 1 秒为间隔生成统计，最后的过滤字符串限定只统计重传包。-z后面能接的统计模块不止 io,stat，常用的还有http,tree（HTTP 方法统计）、conv,tcp（TCP 会话排行）。

4.3 显示过滤器最值得背的 12 个表达式

其中tcp.stream eq 12是最实用的一个——它把分散在列表里属于同一条 TCP 连接的包全挑出来，再配合右键「追踪流 » TCP 流」，就能直接看到应用层协议还原出的完整会话内容。比手动按 IP 加端口过滤省力得多。

5. 深入协议剖析：RTP 流还原、TLS 解密和 TCP 时间戳不可靠的陷阱

5.1 把 Wireshark 里的 RTP 流变成可播放的视频文件

热搜词「wireshark rtp流转成视频」指向一个非常具体的需求：抓到了 SIP 通话或 RTSP 视频流，怎么还原成.opus或.h264文件？Wireshark 4.0 之后的版本内置了这个能力，流程分四步。

第一步，在主界面显示过滤器里输入rtp，确保列表里只剩 RTP 包。第二步，点击「电话 » RTP » RTP 流分析」（Telephony → RTP → Stream Analysis）。这个对话框会列所有 RTP 流，每个流标注了 SSRC、源地址、目的地址以及丢包率。选丢包率最低的那个流，点击「保存」（Save）下拉框，选择「另存为……」（Save as），格式选*.raw。

# 假设保存的文件名为 audio.raw，用 ffmpeg 封装成可播放文件 ffmpeg -f mulaw -ar 8000 -ac 1 -i audio.raw audio.wav # 如果 RTP 里承载的是 G.711 A 律编码 ffmpeg -f alaw -ar 8000 -ac 1 -i audio.raw audio.wav

参数说明：-f mulaw告诉 ffmpeg 输入格式是 G.711 mu-law，-ar 8000是采样率，G.711 固定 8kHz，-ac 1是单声道。如果抓的是 Opus 编码的 RTP（常见于 WebRTC），需要先检查 RTP 包里的 payload type 编号，然后：

# 从抓包里提取 Opus 裸流 tshark -r call.pcapng -Y "rtp.payload" -T fields -e rtp.payload > rtp_payloads.txt

第三步，用rtpplay或wireshark内置的 Play 按钮试听。如果播放有杂音，检查丢包率——超过 2% 的 RTP 流，还原质量就基本不可用了。第四步，视频流的 H.264 还原稍微复杂：RTP 里会有 SPS/PPS（序列参数集和图像参数集）的包，需要先把这两个包识别出来，否则解码器不知道图像分辨率。用tshark -r video.pcapng -Y "h264" -T fields -e h264.parameter_sets把参数集单独导出，再拼接进原始流。

5.1.1 RTP 流分析里的两个关键指标

RTP 流分析窗口里有「Jitter」和「Max Delta」两列。Jitter 表示抖动，单位是毫秒，超过 20ms 就会影响听感；Max Delta 表示同一流中两个包的最大时间间隔，如果这个值超过 200ms，说明网络存在突发延迟。分析 RTP 质量问题，优先盯这两列，而不是只看丢包率——因为有些丢包能通过 PLC（丢包隐藏）技术掩盖，但抖动无法掩盖。

5.2 TLS 解密：只需要导入私钥，但有一个前置条件

Wireshark 抓 HTTPS 流量默认全是密文，但支持两种解密方式：一是导入 RSA 私钥，二是配置 SSLKEYLOGFILE 环境变量收集会话密钥。第一种方式限制很多——只适用于 RSA 密钥交换的 TLS 1.2 及更早版本，现在大部分服务已经改用 ECDHE，私钥导入完全无效；第二种方式是目前的主流方案，也是「wireshark 抓获 https 明文」的正确姿势。

先启动浏览器时设置环境变量：

export SSLKEYLOGFILE=/data/keys/premaster.txt google-chrome --user-data-dir=/tmp/chrome-new

然后在 Wireshark 的「编辑 » 首选项 » 协议 » TLS」里，(Pre)-Master-Secret log filename 指向/data/keys/premaster.txt。重新打开抓包文件，所有的 TLS 应用数据会直接解码成 HTTP 明文。这套方法的原理是 TLS 1.2/1.3 的客户端在每次握手时，都会把协商出的 premaster secret 写入这个文件，Wireshark 读取后重建会话密钥。注意：密钥文件只能解密同一台机器上、相同时段的流量，因为密钥是在内存里生成的，换机器就必须重新抓。

5.3 TCP 时间戳与重传分析：别被 Wireshark 的标记误导

Wireshark 的tcp.analysis.retransmission不是包里的标志位，而是计算出来的推断——判断依据是：序列号小于已确认的最高序列号，且时间晚于之前的包。在以下场景里这个推断会误报：

• TCP 时间戳选项：如果对端启用了tcp.timestamp，Wireshark 可以通过比较时间戳的值排除乱序包，但旧版本 Wireshark 会把时间戳跳变误判为重传。
• SPAN 端口重复收包：交换机镜像口偶尔会把同一包复制两次，Wireshark 行为看起来像重传但不是真的链路丢包。

遇到疑似重传，右键包信息，看 Expert Info（专家信息）里的说明文本。如果写的是This frame is a ( suspected ) retransmission，说明 Wireshark 也只是猜测。进一步判断方法是：给显示过滤器加上tcp.analysis.spurious_retransmission（虚假重传检测），如果这个字段为 1，则确认是误报。

# 统计真实重传率 tshark -r capture.pcapng -Y "tcp.analysis.retransmission" -q -z io,stat,0 | grep "Packets" # 对比虚假重传数量 tshark -r capture.pcapng -Y "tcp.analysis.spurious_retransmission" -q -z io,stat,0 | grep "Packets"

两组数据中的第二组如果和第一组数量接近，那网络链路本身没问题，问题大概率出在抓包方式或负载均衡的会话保持策略上。前几年我在一个真实项目里遇到过重传率显示 17% 的情况，排查了一天才发现是负载均衡设备在每个请求前故意插入了一个重复的 ACK 包——Wireshark 把它标记为 dup ACK，但应用层完全无感知。这个案例说明：专家信息是辅助，不是结论。

6. 命令行批量分析：tshark 替代图形界面的 5 个日常操作

tshark 是 Wireshark 的灵魂。图形界面适合交互式探查，但一旦涉及批量分析、定时任务、脚本化处理，就必须切换到 tshark。以下是五个我每天都在用的命令模板。

统计每个 IP 的流量排行：

tshark -r capture.pcapng -q -z conv,ip

输出结果按流量大小排序显示每个 IP 对的收发字节数。-z conv,ip的 conv 是 conversation 缩写，即会话统计；换成conv,tcp则显示 TCP 会话。

导出指定流的所有包的 payload：

tshark -r capture.pcapng -Y "tcp.stream eq 3" -T fields -e data.data | tr -d '\n'

-T fields表示输出字段，-e data.data提取应用层原始数据的十六进制表示，tr -d '\n'把多行合并成一行。得到十六进制串后，用xxd -r -p还原成二进制文件。

批量检查所有 TCP 流的 RTT 分布：

tshark -r capture.pcapng -q -z io,stat,1,tcp.analysis.ack_rtt

tcp.analysis.ack_rtt是每次 ACK 包确认一个数据包所经过的往返时间，按秒输出平均、最小、最大值。如果平均值超过 50ms 而物理链路明明是 2ms 延迟，那就存在中间节点缓存。

把抓包文件里的 HTTP 请求 URL 全部提取：

tshark -r capture.pcapng -Y "http.request" -T fields -e http.host -e http.request.uri

输出的两列正好拼成完整 URL。适合做流量审计或验证某个接口是否被调用。

按周期生成吞吐报告：

tshark -r capture.pcapng -q -z io,stat,60,"tcp.analysis.retransmission","tcp.analysis.lost_segment"

io,stat,60表示按 60 秒一个桶输出聚合统计，后面跟两个过滤条件，分别统计重传包和丢包段。把这个命令放进 crontab，就能得到一份趋势曲线数据，用于容量规划。用-q时不会破坏输出格式，-z的顺序决定了统计顺序。

以上操作对应的图形界面路径分别是：统计 → 会话、追踪流 → TCP 流、统计 → TCP 流图、显示过滤器加http.request后导出列、统计 → IO Graph。图形界面能做的事 tshark 都能做，反过来却不行——没有图形界面的服务器上，tshark 是唯一的分析工具。生产环境出问题，优先跑 tshark 而不是打开 Wireshark GUI，这是经验之谈。

本文还有配套的精品资源，点击获取