网络故障进阶排查与抓包分析

好的，各位未来的网络专家们，请坐好。我是你们的导师，今天我们要聊点硬核的。你们已经不再是那个只会用 ping 和 tracert 的小白了，对吧？你们在工作中肯定遇到过这样的情况：用户说“网络慢”，老板说“查一下”，然后你看着Wireshark里密密麻麻的数据包，一脸茫然。

今天，这40分钟，我将带你们从“会用Wireshark”进化到“能读Wireshark”，从“会ping”进化到“能诊断”。我们将深入TCP/IP的骨髓，学习如何像一名老道的侦探一样，从数据包的蛛丝马迹中找出网络故障的真凶。

准备好了吗？让我们开始这场网络排障的进阶之旅。

---

一、概述

1. 应用场景与重要性

在复杂的网络环境中，网络故障早已不是简单的“网线没插好”。它可能表现为：

• **间歇性卡顿**：视频会议每隔几分钟就卡住，但ping网关却显示正常。
• **应用响应慢**：访问公司内部ERP系统要等10秒，但访问外网却很快。
• **丢包与重传**：文件传输经常中断，速度极慢。
• **安全事件**：怀疑有主机在发起DDoS攻击或扫描内网。

在这些场景下，单纯的网络层工具（如ping、tracert）已经无法提供足够的信息。我们需要深入到传输层和应用层，去观察数据包的“对话”是否正常。这就是 Wireshark抓包分析 的价值所在。

重要性：

• **证据确凿**：抓包数据是客观事实，能终结“是网络问题还是应用问题”的争吵。
• **定位精准**：能精确到是哪个TCP连接、哪个数据包、甚至哪个应用层字段出了问题。
• **性能优化**：通过分析TCP窗口、往返时延（RTT）、重传率，可以对网络和应用进行针对性优化。
• **安全审计**：识别异常流量、恶意扫描、数据泄露等行为。

2. 适合人群（前置知识）

这份教程是为进阶学员准备的，你至少需要具备以下基础：

• **网络基础**：熟悉OSI七层模型或TCP/IP四层模型，理解IP地址、子网掩码、默认网关、DNS的作用。
• **协议基础**：了解TCP三次握手、四次挥手，理解UDP与TCP的区别。
• **工具基础**：会用 `ping`, `tracert`, `nslookup`, `netstat` 等命令行工具进行基础排障。
• **Wireshark基础**：知道如何启动抓包，设置简单的过滤条件（如 `ip.addr == 192.168.1.1`），能看懂基本的包结构。

如果你对这些概念还比较模糊，建议你先去补一下基础。

---

二、核心知识

1. 核心技术原理讲解：TCP的“慢与重”

网络故障的核心往往与TCP协议的行为有关。TCP是一个可靠的、面向连接的协议，它通过各种机制来保证数据的可靠传输，但这些机制也正是很多“慢”问题的根源。

• **滑动窗口与流量控制**：接收方通过TCP头部的`Window Size`字段告诉发送方：“我还有多少缓存，你一次别发太多。”如果接收方处理不过来，它会缩小窗口，甚至发送`Window Size = 0`，迫使发送方停止发送。这就是**接收端瓶颈**。
• **拥塞控制**：发送方通过自己的算法（如慢启动、拥塞避免）来探测网络的承载能力，当检测到数据包丢失时，它会认为网络发生了拥塞，从而急剧降低发送速度。这就是**网络中间链路瓶颈**。
• **重传机制**：当发送方发出的数据包在超时（RTO，Retransmission Timeout）后没有收到ACK确认，它会重传该数据包。过多的重传是网络延迟和丢包的直接体现。

2. 关键概念与术语

• **RTT (Round-Trip Time)**：数据包从发送端到接收端再返回确认所花费的时间。这是衡量网络延迟的核心指标。
• **RTO (Retransmission Timeout)**：发送方等待ACK的超时时间。通常基于RTT动态计算，RTT越大，RTO越大。
• **TCP Dup ACK / Fast Retransmit**：当接收方收到一个乱序的数据包（例如，收到了#2包但没收到#1包），它会重复发送对#1包的ACK。发送方连续收到3个相同的Dup ACK后，就会立即重传丢失的包，而不用等待RTO超时。这叫快速重传。
• **Zero Window**：接收方窗口大小为0，通知发送方停止发送。
• **TCP Keep-Alive**：用于检测死连接，但很多应用层会自己实现心跳机制。

3. 核心知识点与示例

知识点一：识别“TCP重传”与“TCP快速重传”

问题：用户反馈文件上传很慢。 排查：在Wireshark中，直接过滤 tcp.analysis.retransmission 或 tcp.analysis.fast_retransmit。

示例分析：

• **TCP Retransmission**：你会发现一个数据包（例如Seq=100）被发送了两次，第二次的Info字段会显示`[TCP Retransmission]`。这说明该包在超时后未被确认，被重发了。**结论：网络存在丢包或严重延迟。**
• **TCP Fast Retransmit**：你会看到连续三个相同的Dup ACK，紧接着发送方重传了那个丢失的包。**结论：网络存在少量丢包，但TCP的快速重传机制在尽力恢复。**

诊断：使用 ping -t 观察是否有丢包。如果ping不丢包但TCP重传，说明问题可能出在中间设备的策略（如防火墙限速、QoS丢包）或应用层处理能力上。

知识点二：分析TCP握手与挥手

问题：用户访问网页慢，但ping正常。 排查：过滤 tcp.flags.syn == 1 或 tcp.port == 80，观察三次握手。

示例分析：

• **正常握手**：`SYN` -> `SYN, ACK` -> `ACK`。整个过程RTT应该在毫秒级。
• **异常握手**：
• **SYN重传**：客户端发送了`SYN`，但服务器没回`SYN, ACK`，客户端会重发`SYN`。这说明客户端到服务器的**中间链路**或**服务器本身**有问题。
• **SYN, ACK重传**：服务器回了`SYN, ACK`，但客户端没回`ACK`，服务器重发`SYN, ACK`。这说明服务器回客户端的链路有问题，或者客户端的TCP栈有问题。
• **握手RTT过大**：`SYN`到`SYN, ACK`的时间间隔超过1秒，说明网络延迟很高，或者服务器太忙。

诊断：结合ping和tracert，确认延迟发生在哪一跳。如果在服务器内网，可能是服务器CPU/网卡瓶颈。

知识点三：分析TCP窗口与吞吐量

问题：内网千兆环境，但文件拷贝速度只有10MB/s。 排查：在Wireshark中，添加一个计算列：tcp.window_size。或者使用“统计” -> “流量图” -> “TCP流图” -> “时间/序列(Stevens)”。

示例分析：

• **窗口瓶颈**：观察服务器的`Window Size`。如果它不断减小，甚至出现`Zero Window`，说明**服务器接收数据太慢**，导致其接收缓冲区被填满。这是典型的“接收端瓶颈”。解决方案是优化服务器应用或增加接收缓冲区。
• **带宽延迟积**：即使窗口很大，速度也上不去。可以计算理论最大吞吐量：`窗口大小 / RTT`。例如，窗口为64KB，RTT为100ms，理论最大吞吐量 = 64KB / 0.1s = 640KB/s。如果实际速度远低于此，说明网络中间链路存在瓶颈（如带宽不足、拥塞）。

知识点四：DNS解析延迟

问题：访问网站第一次慢，以后快。 排查：过滤 dns，找到对应的DNS查询和应答包。

示例分析：

• **查询时间**：看`Time`列，从DNS请求发出到收到响应的间隔。如果超过几百毫秒甚至几秒，说明DNS服务器响应慢或网络到DNS服务器延迟高。
• **查询失败**：出现`No such name`或`Server failure`。说明DNS配置错误或DNS服务器故障。
• **CNAME链过长**：一个域名查询返回了多个CNAME记录，客户端需要逐个解析，增加了延迟。

诊断：使用 nslookup 或 dig 命令手动测试不同DNS服务器（如8.8.8.8）的响应时间。

---

三、实操步骤

步骤1：搭建排障环境与抓包准备

1. 确定抓包点：

• **客户端侧**：在用户电脑上抓包。优点：能看到用户发出的所有请求。缺点：可能看不到服务器响应。
• **服务器侧**：在服务器网卡上抓包。优点：能看到服务器接收到的请求和发出的响应。缺点：可能看不到客户端网络问题。
• **中间交换机**：通过端口镜像（SPAN）抓包。优点：能看到中间链路的全貌。缺点：需要网络设备权限。

2. 设置过滤：

• **捕获过滤器**（在开始抓包前设置）：减少抓取的数据量，避免磁盘爆满。
• `host 192.168.1.100`：只抓取与某IP通信的包。
• `port 80 or port 443`：只抓取HTTP/HTTPS流量。
• `not arp`：排除ARP广播，减少噪音。
• **显示过滤器**（在抓包后设置）：聚焦分析。
• `ip.addr == 192.168.1.100 and tcp.port == 443`：精确到特定IP和端口。
• `tcp.analysis.flags`：显示所有TCP异常标记（重传、零窗口等）。
• `http.request or http.response`：只看HTTP请求和响应。

步骤2：复现故障并抓包

1. 启动Wireshark，选择正确的网卡（通常是连接内网的网卡）。 2. 设置捕获过滤器，减少噪音（例如只抓用户IP的流量）。 3. 点击“开始捕获”。 4. 让用户复现故障（例如：访问慢的网页、传输大文件、发起视频会议）。 5. 故障复现后，立即停止捕获。 6. 保存文件：文件 -> 导出特定分组，选择“所有分组”并保存为.pcapng格式。文件名要有意义，如 user_A_web_slow_20231027.pcapng。

步骤3：分析常见故障场景

场景一：分析“网络慢”问题

1. 观察整体RTT：点击“统计” -> “TCP流图” -> “往返时间”。看RTT的分布。如果RTT稳定在1ms以内，说明网络延迟很低，问题可能在应用层。 2. 检查重传：使用显示过滤器 tcp.analysis.retransmission or tcp.analysis.fast_retransmit。如果出现大量重传，点击“统计” -> “IO图表”，将Y轴设置为“分组”，并添加一个过滤器 tcp.analysis.retransmission。观察重传的分布。 3. 检查零窗口：使用过滤器 tcp.analysis.zero_window。如果出现，说明接收端处理能力是瓶颈。 4. 分析应用层：例如HTTP，看http.time（请求到响应的时间）。如果http.time很大，但网络RTT很小，说明服务器处理请求慢（后端数据库查询慢、应用逻辑复杂等）。

场景二：分析“连接不上”问题

1. 过滤TCP握手：tcp.flags.syn == 1。 2. 观察三次握手：客户端是否发了SYN？服务器是否回了SYN,ACK？

• 客户端发了SYN，但没收到SYN,ACK -> **SYN重传**。说明网络不通或服务器端口未监听。
• 客户端发了SYN，收到RST（Reset） -> 服务器主动拒绝连接。原因：端口未开放、防火墙规则、应用层拒绝。
• 客户端发了SYN，收到SYN,ACK，但客户端没回ACK -> 服务器重传SYN,ACK。说明回包链路有问题。

3. 检查DNS：dns.flags.response == 1。看DNS是否解析成功。

常见配置参数说明

• **Wireshark的TCP参数**：
• **Analyze TCP sequence numbers**：默认开启，用于计算重传、Dup ACK等。关闭后Wireshark将不进行TCP分析。
• **Relative sequence numbers**：默认开启，将Seq/Ack号显示为相对值（从0开始），便于阅读。关闭后显示绝对值。
• **Scale factor**：在TCP握手时协商，用于放大窗口大小，支持高带宽环境。例如，`Window Size value: 8192, [Calculated window size: 65536]` 表示缩放因子为8。

• **系统TCP参数**（Linux `sysctl`，Windows `netsh`）：
• `net.core.rmem_max` / `wmem_max`：系统最大接收/发送缓冲区。
• `net.ipv4.tcp_rmem` / `tcp_wmem`：TCP接收/发送缓冲区的最小、默认、最大值。
• `net.ipv4.tcp_slow_start_after_idle`：是否在空闲后重置拥塞窗口。关闭它可以加快短连接的速度。

---

四、故障排查

常见问题及解决方法

问题1：大量TCP重传，但Ping不丢包

• **判断思路**：Ping是ICMP协议，优先级低，且不经过TCP栈。TCP重传可能是由于中间设备（如防火墙、负载均衡器）对TCP报文进行了特殊处理（如限制速率、丢弃非首包）或者应用层处理不过来导致接收窗口关闭后，发送方重传。
• **排查流程**：

1. 在Wireshark中统计重传的IP对：统计 -> 端点，按IPv4排序，查看哪个IP对重传最多。 2. 检查重传包的TTL值是否一致。如果不一致，说明数据包走了不同的路径。 3. 检查是否伴随有TCP Window Update或Zero Window。如果是，问题在接收端。 4. 检查重传是否发生在特定时间点，与CPU/内存占用率图表对比。

• **解决方法**：
• 检查中间设备的QoS策略，确认是否有针对TCP的限速或丢包。
• 优化服务器应用，减少处理延迟，增大接收缓冲区。
• 检查网卡驱动或固件是否过时。

问题2：TCP连接建立缓慢（握手延迟高）

• **判断思路**：`SYN` 到 `SYN,ACK` 的时间间隔长。
• **排查流程**：

1. ping 服务器IP，看RTT是否正常。 2. tracert 服务器IP，看哪一跳延迟突然升高。 3. 在服务器端抓包，看服务器收到SYN到发出SYN,ACK的时间。如果服务器很快发出，说明问题在回包链路；如果服务器也延迟了，说明服务器TCP栈或应用层处理慢。

• **解决方法**：
• 如果是中间链路问题，联系网络管理员。
• 如果是服务器问题，检查服务器CPU、内存、网卡负载，以及`syn_backlog`（半连接队列）是否溢出。

问题3：HTTP请求响应慢，但网络RTT正常

• **判断思路**：`http.time` 很大。
• **排查流程**：

1. Wireshark中过滤 http.request and http.response，计算请求和响应的时间差。 2. 如果时间差很大，说明服务器处理请求慢。进一步分析HTTP请求内容，看是否在查询数据库、调用外部API等。 3. 检查是否有多个TCP连接建立（Keep-Alive失效），导致每次请求都重新握手。

• **解决方法**：
• 优化后端应用性能。
• 开启HTTP Keep-Alive，减少连接建立开销。
• 使用缓存。

问题4：文件传输速度达不到带宽上限

• **判断思路**：`吞吐量 = 窗口大小 / RTT`。
• **排查流程**：

1. 计算理论最大吞吐量。例如，RTT=10ms，窗口=64KB，理论吞吐量=6.4MB/s。 2. 如果实际速度远低于理论值，检查是否发生了拥塞控制（大量重传、窗口被缩小）。 3. 检查TCP窗口缩放因子是否协商成功（Scale factor）。

• **解决方法**：
• 增大TCP接收/发送缓冲区（`rmem`, `wmem`）。
• 使用支持窗口缩放的操作系统和网卡。
• 考虑使用多线程传输或UDP协议（如QUIC）。

问题5：间歇性丢包，难以复现

• **判断思路**：使用Wireshark的“IO图表”和“高级IO图表”进行长时间抓包分析。
• **排查流程**：

1. 设置一个循环抓包，只保留最近N分钟的数据（如 -b filesize:100000 -b files:10）。 2. 在Wireshark中，创建一个IO图表，添加两条线：tcp.analysis.lost_segment（丢包）和 tcp.analysis.retransmission（重传）。 3. 观察图表，找出丢包/重传的峰值时间点。 4. 查看该时间点附近的流量，分析是哪个IP/端口导致的。

• **解决方法**：
• 如果是突发流量导致，考虑增加带宽或实施QoS。
• 如果是物理链路问题（如网线松动、光模块故障），检查日志或更换硬件。

---

五、最佳实践与总结

行业最佳实践建议

1. 标准化抓包流程：制定团队内部的抓包规范，包括抓包点选择、过滤条件、文件命名规则、分析步骤等。例如，统一使用 .pcapng 格式，文件名包含时间、用户、应用。 2. 建立基线数据：在网络正常时，定期抓包并记录关键指标（如平均RTT、重传率、吞吐量）。当故障发生时，与基线对比，能快速发现问题。 3. 使用Wireshark专家系统：Wireshark的分析 -> 专家信息 窗口会汇总所有错误、警告、备注。这是快速定位问题的起点。 4. 多视角分析：不要只看一个抓包文件。如果条件允许，同时在客户端、服务器和中间交换机上抓包，从三个视角看同一个TCP连接，能快速定位故障点。 5. 善用命令行工具：tshark（Wireshark的命令行版本）可以用于自动化分析。例如，tshark -r capture.pcapng -q -z io,stat,1,tcp.analysis.retransmission 可以统计每秒的重传次数。

安全注意事项

• **抓包权限**：抓包需要管理员权限。在企业环境中，应遵循最小权限原则，只授权给网络运维人员。
• **数据隐私**：抓包文件可能包含敏感信息（如用户名、密码、Cookie、业务数据）。处理完故障后，应及时删除或脱敏存储。严禁将抓包文件随意分享或上传到不安全的平台。
• **合法合规**：在抓取用户流量前，确保已获得公司或用户的授权。在某些国家/地区，未经授权抓包是违法行为。
• **避免在公网抓包**：除非必要，不要在公网网卡上长时间抓包，以免泄露内部网络结构或遭受攻击。

扩展学习方向

• **协议深度**：学习更复杂的应用层协议，如 **SMB/CIFS**（文件共享）、**SQL**（数据库）、**RTP/RTCP**（音视频）、**HTTP/2** 和 **QUIC**。
• **网络性能工程**：研究如何通过调整TCP参数（如BDP、拥塞控制算法）来优化网络性能。
• **SDN与网络可编程性**：学习如何使用 **OpenFlow**、**P4** 等技术，对网络设备进行编程，实现更精细的流量监控和故障诊断。
• **自动化排障**：利用Python和Scapy库编写脚本，自动抓包、分析、生成报告，实现7x24小时的网络监控与告警。

总结：

各位，今天我们从一个只会“看”Wireshark的工程师，进化成了一个能“读”懂数据包背后故事的侦探。记住，网络排障不是玄学，而是基于证据的科学。Wireshark是你的显微镜，而你对TCP/IP协议的理解是你的智慧。

下次当用户再对你说“网慢”时，不要慌张。打开Wireshark，用我们今天学到的知识去分析：是握手慢了？是重传多了？是窗口堵了？还是应用层卡了？

纸上得来终觉浅，绝知此事要躬行。 回去后，找一台测试机，搭建一个简单的Web服务，然后模拟各种故障（如用 tc 命令模拟丢包、延迟），自己抓包、自己分析。只有亲手操作过，才能真正掌握这门手艺。

好了，下课！有问题随时来找我。

在博海学习网开始学习 →