简介围绕Wireshark数据包分析实战第3版中的网络故障案例这份PDF整理了一次DNS查询与区域传送问题的完整排查笔记。案例从工作站172.16.16.101访问总部应用服务器172.16.16.200失败并被捕获的首包开始先后看到DNS A记录查询、服务器故障响应、分公司DNS服务器发出的TCP SYN连接请求。文档详细对比了UDP与TCP在DNS协议中的用途解释了当响应过大或进行区域传送时DNS会切换至TCP的原因并结合第7章关于区域传送的讨论将故障指向总部与分公司DNS服务器之间的资源记录同步失败。通过嗅探中心办公室DNS服务器流量发现SYN包实际从未到达服务器最终定位为中心办公室路由器仅允许53端口的UDP流量而阻止TCP流量这一配置错误。资源共1个PDF文件大小为644KB以图文对照方式呈现包含数据包截图与关键字段解读适合网络工程师、运维人员及Wireshark学习者练习从现象到根因的排障方法。目前已有326人学习下载可作为《Wireshark 数据包分析实战》第3版第10章的补充阅读材料。1. Wireshark 数据包分析实战第 3 版到底在练什么Wireshark 数据包分析实战第 3 版不是一本让你背协议的书它解决的是工程师最怕的一类问题网络明明是通的接口却慢得离谱服务端说没收到请求客户端说早就发出去了日志全绿用户已经骂街。抓包那一刻所有说法都要让位给数据包本身。这本书的实战之处就是把抓包变成一种排障习惯而不是偶尔打开看一眼的工具。标题里那个 10.5.2 分析我理解为一次完整会话的标准拆法连接建立、数据交换、连接释放。适合后端开发、运维、测试以及所有被网络问题折磨过的人。2. 抓包不是拿起就抓抓包点、网卡与循环抓包配置抓包前有三个决定必须先做在哪抓、抓多久、抓多大。这三个决定错了后面所有分析都白费甚至可能抓出一份“看起来没问题”的包把整个排障方向带偏。先讲抓包点选择这是新手最容易忽略、也是实际排障里最致命的一环。2.1 抓包点选择题本机回环、物理网卡还是镜像口抓本机进程之间的流量选回环接口。Linux 下叫 lomacOS 下是 Loopback: lo0。很多人在本机起了服务、本机访问结果在以太网卡上抓了半天一条包都没有就是因为本机访问本机的流量根本不经过物理网卡。回环接口抓到的是协议栈内部的流量能看到 TCP 三次握手、应用层数据但看不到真实线路上的电磁信号层面的问题。抓“客户端到服务器”的真实路径要把抓包点放在端点附近。放在客户端侧DNS 解析、TCP 建连、TLS 握手、首字节响应整个链路都能看到放在服务端侧你能确认的是请求有没有真正到达服务端以及服务端从收到请求到发出响应花了多久。这两类数据不能互相替代。排接口慢时我一般会在两端同时抓再对齐时间轴这样才能回答“慢在哪一段”而不是“到底谁撒谎”。还有一种常见做法是交换机镜像口把业务口的流量复制一份出来。适合抓不方便停服的线上设备但镜像口本身的丢包能力取决于交换机的硬件设计在流量接近端口上限时会出现统计缺口丢包率看着像网络问题实际上是抓包姿势问题。记住一个原则本机抓包用本机网卡跨设备排障用镜像口中间设备尽量不参与判断。提示抓无线网卡时很多人把“混杂模式”和“射频监控模式”混为一谈。混杂模式只能收到网卡能解码的帧射频监控模式才是把无线信道上的原始帧都收进来。两者入口不同别选错。2.2 用 tshark 找到网卡并启动循环捕获图形界面首页会列出可用网卡一眼能看到名字和 IP但命令行方式更可靠尤其在一台机器有多块网卡、多块虚拟网卡的环境里。先列出所有接口tshark -D这条命令会输出每个接口的编号、名称和描述。注意看描述列业务口通常有明确的名字比如 eth0、ens192虚拟网卡往往是 veth、docker0、vmnet 之类。找到目标接口后我习惯用 tshark 直接做带循环捕获的抓包而不是开图形界面因为长时间抓包时图形界面更容易被文件体积拖垮。sudo tshark -i eth0 -f tcp port 443 or tcp port 80 \ -b duration:60 -b files:5 -w /data/capture.pcapng参数说明-i指定接口-f是 BPF 捕获过滤器在抓包阶段就把无关流量丢掉能显著降低文件和 CPU 负载-b duration:60表示每 60 秒滚动一个新文件-b files:5表示最多保留 5 个文件超过后自动删除最老的。组合起来就是一个 5 分钟滑动窗口始终保留最近 5 分钟的包。-b还可以配合filesize用比如每个文件到 100MB 就切换同时满足体积和时间两个约束。这里要强调-f捕获过滤器属于 libpcap 的 BPF 语法它只支持“是否抓这个包”的粗粒度过滤比如按端口、按 IP、按协议。它不理解ip.addr这种 Wireshark 显示过滤器字段。抓包阶段的过滤是“丢掉的包永远找不回来”所以宁可在抓的时候多放一点也不要过滤太狠除非你非常清楚目标流量特征。2.3 环形缓冲与文件容量预算很多人抓到一半发现磁盘满了或者打开一个几个 G 的 pcapng 卡到怀疑人生。问题出在没做容量预算。环形缓冲的核心参数就三个单文件大小、单文件时长、保留文件数。总占用大致等于三个参数的乘积。参数组合单文件大小保留文件数预计最大占用duration:60, files:5视流量而定5约 5 分钟流量总量filesize:102400, files:10100 MB10约 1 GBduration:300, files:4视流量而定4约 20 分钟流量总量保存格式也需要考虑。新版 Wireshark 默认写 pcapng这种格式能保留多接口、注解、元数据适合精细分析。但如果是长期无人值守的高流量环境用-F pcap指定老式 pcap 格式写入开销更低兼容性也更好。另一个容易忽略的点是合规性抓包文件里往往包含完整应用数据可能涉及敏感信息。分析完需要移交或归档时用“导出特定分组”功能按需剥离避免把整份文件到处复制。3. 显示过滤器九成协议分析都在这里完成显示过滤器和捕获过滤器完全是两套东西。捕获过滤器在包进入内存之前就把包丢了显示过滤器则是把已经抓到的文件里把关心的包筛选出来。数据包分析里绝大多数操作都是显示过滤器所以它的语法和字段语义必须吃透。3.1 先搞清字段语义再谈语法技巧显示过滤器是建立在 Wireshark 字段解析树上的每一个过滤表达式都是在和字段打交道而不是在做字符串匹配。最容易翻车的是ip.addr。它表示“源地址或目标地址任意一个匹配”本质上是一个复合字段等价于ip.src x or ip.dst x。于是你会看到这样两个常见错误错误ip.addr 192.168.1.10 and ip.addr 192.168.1.20 正确(ip.src 192.168.1.10 and ip.dst 192.168.1.20) or (ip.src 192.168.1.20 and ip.dst 192.168.1.10)前者的语义是“同一个包里源地址和目的地址同时等于两个值”这在现实里不可能发生结果永远是 0 包。后者才表达“两台主机之间的双向流量”。想要省事可以直接用tcp.stream来定位会话这个字段在 Wireshark 里是每个 TCP 连接唯一的整数索引右键任意一个 TCP 包选择“追踪流”相当于自动执行了tcp.stream eq n。还有优先级陷阱。tcp.port 443 || 80不是“443 或 80 端口”而是“443 端口或者 80 这个值本身为真”。后者永远为真导致过滤器把所有包都放行。每个比较必须写完整不要依赖类似编程语言里的短路简化。语法错误时输入框会变红并提示但语义错误不会变红只能靠观察结果数量判断。写完过滤串先看一眼左下角状态栏的匹配包数量这是最直接的校验方式。3.2 常用过滤串清单查表即用下面这组过滤串是我在日常排障里用得最多的覆盖建连、重传、DNS、TLS、慢请求几类核心场景。分析场景显示过滤器说明只看 TCP 建连请求tcp.flags.syn1 and tcp.flags.ack0排除 SYN-ACK只看发起方向定位重传tcp.analysis.retransmission or tcp.analysis.fast_retransmission快速重传与超时重传分开看找连接重置tcp.flags.reset1RST 包出现的位置往往就是异常发生点只看 DNS 请求dns.flags.response0响应是 1请求是 0TLS 握手起始tls.handshake.type1ClientHello 出现即握手开始相邻包间隔过大tcp.time_delta 0.2两包间隔超过 200ms 的位置要关注大包排查tcp.len 1400超过常规 MSS 的包往往涉及巨型帧排除背景噪声!(icmp or arp or stp)把探测和广播协议踢掉ACK 响应耗时tcp.analysis.ack_rtt 0.1数据到 ACK 超过 100ms 说明接收侧处理慢注意tcp.analysis.ack_rtt这类 Expert Info 字段不是标准 TCP 头里的字段而是 Wireshark 根据文件内容计算出来的分析结果。它只在抓包文件具备完整时序信息时才有意义单独的包是算不出 RTT 的。3.3 把常用过滤串固化成按钮与 Profile每次排障都重新输入一遍长过滤串没有意义。新版 Wireshark 支持多 Profile每个 Profile 可以独立保存自己的显示过滤器按钮、着色规则、列配置。入口通常在右下角状态栏的 Profile 切换器或者通过“编辑 → 配置说明文件”进入。新建一个名为“troubleshoot”的 Profile然后把上一节那些过滤串逐个存成快捷按钮。# Linux 下 Wireshark 配置目录常见位置 # 个人 Profile 目录~/.local/lib/wireshark/profiles/ # Windows 下常见位置%APPDATA%\Wireshark\profiles\把整个 Profile 目录复制到另一台机器的相同位置就能实现团队内共享。新成员接手时直接切 Profile看到的是同样一组过滤按钮和着色规则不需要现场教一遍“重传要看哪个字段”。我维护的 Profile 里固定有六个按钮重传、RST、DNS、TLS 握手、慢包间隔、大包任何一次抓包进来先按这六类扫一遍问题大致方位就出来了。这也是第 3 版里反复强调的“先全局后局部”的分析节奏。4. 从 10.5.2 分析落地单次会话拆解的标准三步不管标题里的 10.5.2 是书里的练习编号还是你自己工单里的分析项方法是一致的任何一次会话都可以拆成建连、数据交换、释放三个阶段。把每个阶段的时间量化出来问题就藏不住。4.1 第一步从 SYN 定位流把会话从文件里挖出来拿到一份抓包文件我不会从头开始翻而是先找第一个 SYN 包因为它是一个 TCP 会话真实的起点。命令行里这样找tshark -r login.pcapng \ -Y tcp.flags.syn1 and tcp.flags.ack0 \ -T fields \ -e frame.number -e frame.time_relative \ -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport \ -e tcp.window_size_value参数说明-r指定读取文件-Y用的是显示过滤器语法和图形界面的输入框完全一致-T fields表示输出自定义字段-e后面每一个参数对应一列输出。frame.number是包在文件里的序号frame.time_relative是相对文件第一个包的时间tcp.window_size_value是 SYN 包宣告的接收窗口这个值能初步判断接收缓冲区大小。找到 SYN 后在图形界面里右键这个包选择“追踪 TCP 流”Wireshark 会自动用tcp.stream eq N过滤出整条会话。要注意同一个文件里可能会有多个 SYN说明有多次重连。此时按frame.time_relative排序确认哪一次会话对应要排查的时间点别把多轮重连当成一条流来分析。4.2 第二步调整时间列让异常自己浮出来默认的时间列是从抓包开始算的绝对时间看单条流没问题但多条流并行时很难对齐先后关系。我会先做两件事把时间显示格式改成“自参考时间起算”然后在流的第一个 SYN 包上设置时间参考这样整条流的时间都从 0 开始每一跳的间隔直接就是相对时间。再加一列tcp.time_delta显示相邻两包的时间差这个列是最直观的“卡顿探测器”。与之配合的是“专家信息”面板入口在“分析 → 专家信息”。它会按严重程度把所有异常汇总重传、快速重传、零窗口、乱序、重复 ACK 全部列出来。重点看四个信号。信号过滤/查看方式说明重传tcp.analysis.retransmission数据超时未确认常见于丢包或对端处理慢零窗口tcp.window_size_value 0接收方缓冲区耗尽应用没及时读走数据乱序tcp.analysis.out-of-order序号跳变或后到先达可能网络路径变化ACK RTTtcp.analysis.ack_rtt数据到达对端到对端回 ACK 的时间零窗口不能直接判死刑。它只代表接收缓冲区已满可能只是应用层线程卡顿不一定是网络问题。先用tcp.analysis.ack_rtt看响应速度再用零窗口判断哪个方向的接收端处理不过来两者配合才能定位是网络还是应用。4.3 第三步把 HTTP/TLS 的耗时拆到具体阶段接口慢是最常见的诉求。一份包里如果有 DNS 查询、TCP 建连、TLS 握手和 HTTP 请求我习惯按五个阶段拆DNS 解析、TCP 建连、TLS 握手、服务端处理、响应传输。每一段都能在包里找到边界包DNS 请求到 DNS 响应SYN 到 SYN-ACKClientHello 到服务端 FinishedHTTP 请求的最后一个字节到响应第一个字节响应开始到响应结束。用 tshark 的统计模块可以快速量化tshark -r api.pcapng -q -z io,stat,1 -z conv,tcp-q表示不输出每个包只输出统计结果-z io,stat,1按 1 秒间隔统计包量和速率-z conv,tcp输出 TCP 会话列表包含每个连接的收发字节数、相对起始时间。先看conv,tcp找到目标连接再用io,stat看那一时间段内的流量曲线传输速率是否在该时间段内出现断崖一目了然。TLS 握手本身也要细拆。Wireshark 的“统计 → TLS 握手”会列出每个握手的协商套件和耗时但如果想看加密后的应用数据往返耗时就需要解密。开发自建服务时最常见的方式是让服务端进程把会话密钥写入日志文件export SSLKEYLOGFILE/tmp/dev_keys.log node server.js参数说明SSLKEYLOGFILE是 OpenSSL、GnuTLS 等 TLS 库都支持的环境变量进程启动后会把每个 TLS 会话的密钥写进这个文件。在 Wireshark 的“协议 → TLS”设置里填入/tmp/dev_keys.log即可对抓到的 TLS 流量解密。注意三点环境变量必须在启动目标进程的那个终端里先导出密钥日志是持续追加的解密失败先确认文件里有没有覆盖抓包时间段的记录TLS 1.3 每次握手都产生新密钥文件写入频率更高要用会话建立前后的记录对照。如果目标程序不是用 OpenSSL 这类支持密钥导出的库实现的解密这条路走不通就在客户端和服务端同时抓包做时间对齐同样能拆出延迟分布。不要把解密当成必须的抓包分析的核心是“确认谁在等谁”而不是把每个字节读透。5. 数据包分析高频踩坑五条翻车记录抓包的坑基本不在“按开始按钮”这一步而在后续的分析姿势。下面五条都是实际排障现场反复出现的问题按现象到原因再到解决写清楚省得你再走一遍。5.1 抓到一堆包就是没有目标流量现象抓了十分钟文件里全是 ARP、广播、NetBIOS 之类的背景流量目标 IP 一个包都没有。原因抓包接口选错了。最常见的是本机回环和应用流量走的物理网卡不是同一个接口另一类常见原因是登录远程服务器排障时抓的是管理口业务流量走的是另一个口。解决先用tshark -D列出所有接口核对接口描述里的 IP 是否属于业务网段。拿不准时在同一终端里ping目标地址然后看抓包窗口里是否有对应 ICMP 请求包。有说明接口选对了没有换接口重抓。这个验证动作只需要几秒钟但能避免一小时的无效抓包。5.2 过滤串写出来“感觉对了”结果翻倍或归零现象同样一个 IP 地址用ip.addr 目标过滤出来大量单向包用ip.addr A and ip.addr B过滤则直接归零。原因ip.addr的语义是“源或目标任意匹配”等价于ip.src x or ip.dst x。两个ip.addr做 and 运算时要求同一个包里的源和目的同时各命中一个条件这在双向流量里几乎不可能成立。解决按 3.1 中的写法把双向流量展开成两个方向的组合。或者更省事先找到目标流里的任意一个包右键追踪 TCP 流用tcp.stream eq N定位完整会话不碰ip.addr的复合语义。5.3 时间列忽大忽小误判了乱序现象同一流的包在时间列里乱跳看起来像是网络乱序但着色规则里又没有标出乱序。原因时间显示格式默认是相对文件开始时间而一份 pcapng 文件里有多个接口、多段捕获时时间戳交错是正常的。另外TCP 乱序的判定依据是序号而不是时间戳时间列倒挂并不等于网络乱序。解决把时间显示格式切到“自参考时间起算”然后在目标流的 SYN 包上设置时间参考让所有包从 0 开始计数。要判断乱序直接看“分析 → 专家信息”里的 out-of-order 条目而不是凭时间列肉眼判断。5.4 TLS 解密始终失败key 文件填了还是密文现象Protocol 设置里填了密钥日志文件路径抓包里应用数据依然显示为Encrypted Application Data。原因要么密钥文件里没有覆盖抓包时段的记录要么目标进程根本不是用的支持SSLKEYLOGFILE的 TLS 库。还有一种情况是抓包开始得比进程早但密钥文件是进程启动后才创建的导致前几个会话没有密钥。解决先清空密钥文件再启动目标进程确认抓包开始时间在密钥文件首条记录之后。再检查SSLKEYLOGFILE是否传到了真正执行 TLS 握手的那一层很多语言框架里 SSL 卸载发生在独立模块环境变量没传进去就不会写文件。都不行就两端抓包对比别耗在解密上。5.5 几个 G 的抓包文件一打开就卡死现象双击 pcapng界面转圈几十秒输入过滤串后更卡最后只能强退。原因文件过大所有包一次性读入内存显示过滤器执行时要做全文件扫描内存和时间全都扛不住。解决先用capinfos 文件.pcapng看包量、时长、平均速率判断文件规模和复杂度。再用 editcap 按时间切分editcap -i 60 big.pcapng part.pcapng参数说明-i 60表示每 60 秒切一个文件输出的是一组part.pcapng-0、part.pcapng-1这样的分片。先定位问题时间段再切比从一开始就全量打开理智得多。也可以在切分时顺手用-c按包数切分适合时间跨度长但包量集中的文件。提示先 capinfos 再看包是省内存也省心情的习惯。文件看一眼大小就打开是新手最常见的浪费。6. 三个值得固化的进阶习惯把 Wireshark 用成网络画像工具第一个习惯任何抓包文件到手先跑capinfos。不打开图形界面只用一行命令拿到时长、包数、平均包速率、文件大小和是否有截断信息。我在区分“这个问题是否值得展开分析”时靠的就是这几个数字如果一份 5 秒的文件里有几十万个包先怀疑是风暴类问题而不是直接进去翻包。第二个习惯用 tshark 把抓包文件抽成资产清单。TLS 握手里的证书、HTTP 请求里的 User-Agent、DNS 查询里的域名都是现成的特征。排障时经常需要回答“这个网段上到底有哪些设备在通信”与其靠记忆不如直接抽字段归档。提取 TLS 证书和 UA 都是单条命令的事输出重定向到文本文件后还能做去重排序比人工翻包快了不止一个量级。第三个习惯把常用排障动作固化成着色规则和 Profile。重传的包标红RST 标橙SYN 标绿零窗口标紫。这样打开大文件后先不被详情面板干扰扫描一眼色块分布异常区域自己就跳出来了。配合前面做的过滤按钮新人拿到同一份 Profile操作路径和老师傅完全一致。这个习惯本质上是把“经验”从人脑迁移到工具配置里。有一回我连续抓了两个多小时最后发现抓的是本机回环接口而业务流量走的是物理网卡。那个教训让我养成一个习惯每换一个环境第一件事就是tshark -D确认接口名再用 ping 包验证抓包点最后才开始正式分析。抓包分析里先确认数据是从哪儿来的再谈数据说了什么。希望帮到你。本文还有配套的精品资源点击获取