ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

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 动态表调试。安装时有个容易被忽略的选项安装 NpcapWindows或 libpcapLinux/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 捕获接口怎么选管理口、业务口和数据口不是一回事一台服务器上可能有多块网卡管理口、业务口、备份口。抓包选错接口是新手最常见的错误——把抓包接口选成了管理口结果业务流量全部旁路。判断方法是看「捕获 » 选项」对话框里每个接口的「每秒数据包数」实时滚动值。通常业务口的包速率远高于管理口如果你看到两个接口速率差不多那可能是交换机做了端口镜像此时应该选镜像口。接口类型典型用途抓包建议管理口SSH/带外管理一般不用抓了也是控制面流量业务口对外服务通信首选直接反映业务问题汇聚口端口镜像/分光适合全流量分析注意吞吐量选好接口后在「捕获选项」里有一个「混杂模式」复选框。默认勾选这意味着可以抓到非本机 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 端口的包后续用显示过滤器也找不回被丢弃的包。需求捕获过滤器BPF显示过滤器只看某主机的所有流量host 192.168.1.10ip.addr 192.168.1.10只看某个端口的 TCPtcp port 443tcp.port 443排除 ARP 广播not arp!(arp)抓 DHCP 请求port 67 or port 68dhcp注意捕获过滤器不含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,treeHTTP 方法统计、conv,tcpTCP 会话排行。4.3 显示过滤器最值得背的 12 个表达式场景过滤器写法只看 TCP 三次握手失败的流tcp.flags.syn 1 tcp.flags.ack 0 tcp.analysis.retransmission定位 HTTP 500 响应http.response.code 500找 DNS 查询耗时长的包dns.flags.response 0 dns.time 0.1过滤特定 TLS 版本tls.handshake.version 0x0303只显示一个 TCP 流的包tcp.stream eq 12找大数据包frame.len 1400显示所有 SYN 包tcp.flags.syn 1 tcp.flags.ack 0显示所有 ACK 包tcp.flags.ack 1找 DHCP 中继响应dhcp.option.option_type 54筛选特定 MAC 地址eth.addr aa:bb:cc:dd:ee:ff抓带 RST 标志的 IPv6 包ipv6 tcp.flags.reset 1只看从客户端到服务器的方向ip.src 10.0.0.1 ip.dst 10.0.0.2其中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.timestampWireshark 可以通过比较时间戳的值排除乱序包但旧版本 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 会话。导出指定流的所有包的 payloadtshark -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_rtttcp.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_segmentio,stat,60表示按 60 秒一个桶输出聚合统计后面跟两个过滤条件分别统计重传包和丢包段。把这个命令放进 crontab就能得到一份趋势曲线数据用于容量规划。用-q时不会破坏输出格式-z的顺序决定了统计顺序。以上操作对应的图形界面路径分别是统计 → 会话、追踪流 → TCP 流、统计 → TCP 流图、显示过滤器加http.request后导出列、统计 → IO Graph。图形界面能做的事 tshark 都能做反过来却不行——没有图形界面的服务器上tshark 是唯一的分析工具。生产环境出问题优先跑 tshark 而不是打开 Wireshark GUI这是经验之谈。本文还有配套的精品资源点击获取
返回列表