1. 网络故障模拟到底在模拟什么

第一次接触“网络故障模拟”这个说法的人，脑子里冒出来的画面往往是机房着火、交换机冒烟、网线被老鼠咬断。但真正做过抓包分析的人都知道，日常工作中遇到的绝大多数“网络故障”，其实根本不是硬件坏了，而是协议行为不符合预期——TCP 该重传的时候没重传，UDP 该丢包的时候丢得莫名其妙，握手该三次的时候偏偏只走了两次。这些东西你在应用层是看不出来的，日志里只会写一句“连接超时”，然后就没有然后了。

所以网络故障模拟的核心，不是去制造物理损坏，而是在可控环境下复现那些“看起来像故障”的协议行为，再用抓包工具把整个过程录下来，逐帧分析。TCP 和 UDP 是绕不开的两个主角：TCP 面向连接、有状态、有重传机制，它的故障往往表现为握手失败、窗口冻结、RST 异常、重传风暴；UDP 无连接、无状态、不保证送达，它的故障更多体现在丢包、乱序、重复、MTU 分片问题上。两者的排查思路完全不同，抓包时的过滤策略也不一样。

这套东西适合谁？我个人的判断是三类人最需要：一是刚入行的运维或后端开发，线上出了问题只会重启服务，想往深了走必须懂抓包；二是做物联网、音视频、游戏这类对 UDP 依赖很重的开发者，UDP 的问题不抓包基本靠猜；三是准备面试网络相关岗位的人，TCP 三次握手四次挥手背得再熟，不如自己抓一次包看一遍来得扎实。

接下来我会按照“先搭环境、再制造故障、然后抓包、最后逐帧分析”的顺序，把整个流程拆开讲。中间会穿插大量我实际踩过的坑，比如为什么你抓到的包总是缺帧、为什么 Wireshark 显示的“重传”有时候是误报、为什么 UDP 抓包过滤规则写错了会漏掉关键数据。这些细节，文档里通常不会写，但恰恰是决定你能不能定位到问题的关键。

2. 动手之前：环境搭建与工具选型

2.1 抓包工具的取舍逻辑

抓包工具市面上主流的就是 Wireshark、tcpdump，再加上一些命令行小工具。我的建议是两个都要会，但分工明确。

Wireshark 是图形化分析的主力，优势在于协议解码极其完整，TCP 的每一个标志位、每一个选项字段都能展开看，还能自动标记重传、乱序、重复 ACK。但它的劣势也很明显：在服务器上跑图形界面不现实，而且抓大流量的时候内存吃得厉害。tcpdump 则是服务器端的标配，几乎任何 Linux 发行版都自带或者一条命令就能装，它负责“抓”，把包存成 pcap 文件，然后拉到本地用 Wireshark 分析。这个“服务器抓、本地析”的组合是我用得最多的。

至于故障模拟工具，Linux 下最顺手的是tc（traffic control）配合netem模块，可以模拟延迟、丢包、乱序、重复、损坏。Windows 下可以用 Clumsy 这类工具，但功能没 tc 细。如果你只是想模拟应用层的连接异常，用iptables直接 DROP 或 REJECT 某些包也能达到目的，而且更简单粗暴。

提示：不要一上来就上复杂工具。很多“故障”用 iptables 一条规则就能造出来，比如直接丢弃 SYN 包模拟服务不可达，比配置 tc 快得多。

2.2 实验环境的搭建步骤

我习惯用两台 Linux 虚拟机加一台宿主机来做这套实验。一台当客户端，一台当服务端，宿主机用来跑 Wireshark 分析。网络模式用 NAT 或者仅主机模式都行，关键是两台机器能互通，且你能控制它们之间的流量。

具体步骤：

1. 两台虚拟机都装好基础系统，确认ping能通。
2. 服务端装一个简单的 TCP 服务和 UDP 服务。TCP 用nc -l或者 Python 的 socket 都行，UDP 同理。我一般用 Python 写个十几行的小脚本，方便控制收发逻辑。
3. 客户端装tcpdump，服务端也装，因为有时候需要两端同时抓包对比。
4. 宿主机装 Wireshark，用来打开 pcap 文件。
5. 确认tc可用：tc qdisc show能输出内容就说明没问题。

这里有个容易被忽略的点：虚拟机的网卡类型会影响抓包结果。如果你用的是 virtio 网卡，某些情况下 TCP 校验和卸载（checksum offload）会导致 Wireshark 显示校验和错误，但那其实是网卡卸载造成的假象，不是真的错误。解决办法是在 Wireshark 里关掉校验和验证，或者用ethtool -K eth0 tx off rx off关掉卸载。这个坑我踩过不止一次，一开始以为是数据包损坏，查了半天才发现是卸载的锅。

2.3 抓包过滤规则的正确写法

抓包时最忌讳的就是“全抓”。全抓的后果是文件巨大、噪音极多，分析的时候光过滤就浪费半小时。正确的做法是在抓的时候就过滤，而不是抓完再过滤。

tcpdump 的过滤表达式基于 BPF 语法，几个我常用的：

# 只抓某台主机的 TCP 流量 tcpdump -i eth0 -w tcp.pcap host 192.168.1.100 and tcp # 只抓某个端口，且排除 SSH 自身流量 tcpdump -i eth0 -w udp.pcap udp port 9999 # 抓 TCP 握手和挥手相关的包 tcpdump -i eth0 -w handshake.pcap 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'

Wireshark 的显示过滤器则是另一套语法，常用的有tcp.analysis.retransmission（看重传）、tcp.flags.reset == 1（看 RST）、udp.length > 100（按长度过滤）。注意区分捕获过滤器和显示过滤器，前者在抓的时候就生效，后者只是隐藏不匹配的包，文件里其实还在。

注意：抓包时加-s 0表示抓完整包，不加的话默认只抓前 96 字节，TCP 选项字段可能被截断，分析握手参数时会缺信息。这个细节很多人不知道，导致抓到的包“看起来正常”但分析不了。

3. TCP 故障模拟与抓包实战

3.1 三次握手失败的三种典型场景

TCP 故障里最基础也最常考的就是握手失败。我把它分成三种：SYN 丢失、SYN-ACK 丢失、ACK 丢失。三种情况在抓包结果上表现完全不同，排查方向也不一样。

场景一：SYN 丢失。客户端发出 SYN 后，服务端根本没收到，所以不会有任何回应。抓包看到的是客户端反复重发 SYN，间隔按 1s、2s、4s、8s 指数退避，重试几次后放弃，报“连接超时”。这种故障通常意味着网络路径不通、防火墙拦截，或者服务端根本没在监听。

模拟方法很简单，在服务端用 iptables 丢弃入站 SYN：

iptables -A INPUT -p tcp --dport 8080 --syn -j DROP

抓包分析时重点看：客户端 SYN 的序列号是否每次相同（相同说明是重传，不是新连接）、重传间隔是否符合指数退避、有没有收到任何回应。

场景二：SYN-ACK 丢失。服务端收到了 SYN，回了 SYN-ACK，但这个回应在回程路上丢了。客户端视角和场景一一样，也是反复重发 SYN。但如果你在服务端抓包，会看到服务端其实回了 SYN-ACK，而且可能回了多次（因为服务端也在重传）。这种故障的迷惑性在于：客户端和服务端的抓包结果对不上，一个说“我发了你没回”，一个说“我回了你没收到”。这时候两端同时抓包对比就非常关键。

场景三：ACK 丢失。这个最隐蔽。服务端收到 SYN，回 SYN-ACK，客户端收到后回 ACK，但 ACK 丢了。服务端会认为握手没完成，重传 SYN-ACK；客户端认为自己已经 ESTABLISHED 了，收到重复的 SYN-ACK 会觉得奇怪。抓包时能看到服务端反复重传 SYN-ACK，而客户端可能已经开始发数据了。这种“半开连接”状态是很多诡异问题的根源。

3.2 用 tc netem 制造可控的丢包和延迟

iptables 只能做“丢”或“不丢”的二元选择，想要更精细的控制，比如“丢 30% 的包”“延迟 200ms 且抖动 50ms”，就得上 tc netem。

# 在 eth0 上添加 30% 丢包 tc qdisc add dev eth0 root netem loss 30% # 添加 200ms 延迟，抖动 50ms tc qdisc add dev eth0 root netem delay 200ms 50ms # 模拟乱序，25% 的包延迟 10ms 发送 tc qdisc add dev eth0 root netem delay 10ms reorder 25% # 用完记得删除，否则一直生效 tc qdisc del dev eth0 root

这里有个实操心得：netem 的丢包是随机的，不可复现。同样的配置跑两次，丢的包不一样。如果你需要精确复现某个故障场景，netem 不太合适，得用更底层的手段，比如自己写个代理程序按规则丢包。但对于学习抓包分析来说，随机丢包已经足够制造出重传、重复 ACK、快速重传这些现象了。

我一般会这样设计实验：先建立正常连接，抓一份“健康”的包作为基线；然后加上 netem 丢包，再抓一份“故障”的包；两份对比着看，差异一目了然。没有基线对比，你很难判断某个现象是正常的还是异常的。

3.3 重传与快速重传的抓包识别

TCP 重传分两种：超时重传和快速重传。超时重传是发送方等不到 ACK，超过 RTO 时间后重发；快速重传是发送方收到三个重复 ACK 后立即重发，不等超时。

在 Wireshark 里，超时重传会被标记为TCP Retransmission，快速重传标记为TCP Fast Retransmission。但要注意，Wireshark 的标记有时候是误报。比如它可能把正常的重传当成异常，或者因为抓包点位置不对而误判。判断重传是否真的发生了，最可靠的方法是看序列号：如果两个包的序列号相同、载荷相同，那就是重传。

重复 ACK 的识别也有讲究。接收方收到乱序的包时，会重复发送最后一个按序到达的 ACK，告诉发送方“我还在等某个序列号的包”。收到三个重复 ACK，发送方就触发快速重传。抓包时看到连续的、ACK 号相同的包，基本就是重复 ACK 了。

提示：分析重传时，把 Wireshark 的“相对序列号”打开（默认就是开的），比看绝对序列号直观得多。绝对序列号是一串大数字，相对序列号从 0 开始，一眼就能看出哪个包重传了。

3.4 RST 异常的排查思路

RST 包是 TCP 里的“急刹车”，收到 RST 意味着连接被强制终止。RST 出现的原因很多：连接到一个没监听的端口、防火墙主动拒绝、应用层主动关闭、半开连接收到数据等。

排查 RST 的第一步是看 RST 是谁发的、在什么阶段发的。如果是握手阶段服务端回 RST，说明端口没监听或者被防火墙 REJECT 了。如果是数据传输阶段某一方发 RST，可能是应用崩溃或者主动关闭。如果是连接空闲很久后突然 RST，可能是中间设备清理了会话表。

我遇到过一个很典型的案例：客户端连接服务端，握手正常，发第一个请求也正常，但发第二个请求时收到 RST。抓包发现服务端在收到第二个请求后立即回了 RST。查下来是服务端的连接池配置有问题，第一个请求处理完后连接被错误地关闭了，但客户端不知道，继续复用这个连接，服务端收到数据后发现连接已经不存在，只能回 RST。这种问题不看抓包根本定位不到。

4. UDP 故障模拟与抓包实战

4.1 UDP 抓包的特殊性

UDP 和 TCP 在抓包分析上的最大区别是：UDP 没有连接状态，没有握手挥手，没有重传机制。这意味着你抓到的每一个 UDP 包都是独立的，不存在“这个包属于哪个连接”的概念（除非应用层自己定义了会话 ID）。这给分析带来了两个困难：一是无法通过握手判断通信是否正常建立，二是丢包后没有任何协议层的补偿，只能靠应用层自己处理。

抓 UDP 包时，过滤规则要更精确。因为 UDP 没有标志位，你只能按端口、按 IP、按长度来过滤。我常用的：

# 按端口抓 tcpdump -i eth0 -w udp.pcap udp port 9999 # 按源或目的 IP 抓 tcpdump -i eth0 -w udp.pcap udp and host 192.168.1.100 # 排除某个端口，避免抓到噪音 tcpdump -i eth0 -w udp.pcap udp and not port 53

Wireshark 里分析 UDP 时，我建议打开“协议层次统计”和“会话统计”，能快速看出哪些 IP 对之间流量最大、包数量是否对称。UDP 的故障往往表现为“一方发了很多，另一方收得很少”，这种不对称在统计图里一眼就能看出来。

4.2 丢包、乱序、重复的模拟与识别

UDP 的故障模拟和 TCP 类似，也是用 tc netem，但因为 UDP 没有重传，丢包的影响更直接。

# 模拟 20% 丢包 tc qdisc add dev eth0 root netem loss 20% # 模拟乱序 tc qdisc add dev eth0 root netem delay 5ms reorder 50% 50% # 模拟重复 tc qdisc add dev eth0 root netem duplicate 10%

识别丢包的方法：在发送端和接收端同时抓包，对比两边的包序列号（如果应用层有序列号的话）。发送端发了 100 个包，接收端只收到 80 个，那 20 个就是丢了。如果应用层没有序列号，那就只能靠包的数量和内容来推断，难度大很多。这也是为什么我强烈建议自研的 UDP 协议一定要在应用层加序列号，不然出了问题根本没法排查。

乱序的识别：接收端收到的包序列号不是递增的，比如收到 1、2、4、3、5。Wireshark 本身不会标记 UDP 乱序（因为它不知道你的序列号规则），你得自己看载荷里的序列号字段。

重复的识别：同一个序列号的包出现了两次。netem 的 duplicate 是随机复制，所以你会看到某些包莫名其妙出现两遍。

4.3 MTU 与分片问题的抓包分析

UDP 还有一个 TCP 不太会遇到的问题：分片。UDP 包如果超过 MTU，IP 层会把它分片。分片本身不是故障，但分片会带来两个隐患：一是任何一片丢失，整个 UDP 包就废了，而 UDP 不会重传；二是某些防火墙或 NAT 设备对分片的处理不一致，可能导致分片被丢弃或重组失败。

抓包时识别分片：看 IP 头的Flags字段，MF（More Fragments）为 1 表示后面还有分片，Fragment Offset不为 0 表示这是后续分片。Wireshark 会把同一个 UDP 包的分片标记出来，但需要你手动开启“重组”功能才能看到完整的载荷。

我遇到过一个经典问题：客户端发一个 2000 字节的 UDP 包，服务端收不到。抓包发现包被分成了两片，第一片到了，第二片丢了。因为 UDP 不重传，服务端重组失败，整个包被丢弃。解决办法要么是减小包大小避免分片，要么是在应用层做分片和重传。这个问题的隐蔽性在于，小包测试一切正常，一大包就出问题，很容易误判为“服务端处理能力不足”。

注意：路径 MTU 发现（PMTUD）在 UDP 场景下经常失效，因为很多防火墙会丢弃 ICMP 的“需要分片”消息。所以 UDP 应用最好自己控制包大小，不要依赖 PMTUD。

5. 常见问题与排查技巧实录

5.1 抓包抓不到包的几个原因

这是新手最常遇到的问题：明明配置了抓包，但一个包都没有。我总结了几种可能：

还有一个隐蔽的原因：流量走了 loopback。如果客户端和服务端在同一台机器上，流量走的是lo网卡，你在eth0上抓是抓不到的。这个坑我踩过，当时以为是防火墙问题，查了半天才发现是网卡选错了。

5.2 Wireshark 分析中的误报与陷阱

Wireshark 很强大，但它的自动分析功能有时候会误导人。几个常见的误报：

校验和错误误报。前面提过，网卡卸载会导致 Wireshark 显示校验和错误，但实际包是好的。解决办法是关掉校验和验证，或者关掉网卡卸载。

重传误报。Wireshark 判断重传是基于序列号和时间的，如果抓包点位置特殊（比如在发送方和接收方之间的中间设备上抓），可能会把正常的包误判为重传。

乱序误报。多路径或者抓包点不对称时，Wireshark 可能把正常到达的包标记为乱序。

我的经验是：永远不要只信 Wireshark 的标记，要自己看序列号、看时间戳、看载荷。标记只是提示，最终判断得靠数据本身。

5.3 从抓包到定位问题的完整思路

抓包只是手段，定位问题才是目的。我一般的分析流程是：

1. 先看整体：用 Wireshark 的“统计”功能看包数量、会话分布、协议分布，快速定位异常点。
2. 再看异常：过滤出重传、RST、重复 ACK、ICMP 错误等异常包，看它们集中在哪个时间段、哪对 IP 之间。
3. 然后看细节：针对异常包，展开协议树，看序列号、标志位、选项字段、载荷内容。
4. 最后做对比：和正常情况的抓包对比，找出差异。没有对比就没有判断。

这个流程说起来简单，但实际操作中最难的是第 4 步。很多人抓了包，看到一堆重传就慌了，但其实如果基线抓包里也有重传，那说明重传在这个网络环境下是正常的，不是故障原因。建立基线这个习惯，是我做抓包分析这些年最重要的经验。

5.4 几个提升效率的小技巧

Wireshark 的“追踪 TCP 流”功能（Follow TCP Stream）能把一个连接的所有载荷拼起来看，分析应用层协议时特别有用。UDP 没有流的概念，但可以用“追踪 UDP 流”看一段时间内的所有包。

给 pcap 文件命名时带上时间、场景、过滤条件，比如20240115_tcp_retrans_loss30.pcap，过几天回头看还能想起来是什么实验。

分析大文件时，先用editcap按时间或包数量切分，再逐段分析，比一次性打开几百兆的文件流畅得多。

如果需要在多台机器上同时抓包，用tcpdump的-w写到文件，然后统一拉到一台机器上用 Wireshark 的“合并”功能合并，注意时间同步问题，机器之间时间差太大会导致合并后的时间线错乱。

最后分享一个我个人的习惯：每次做完故障模拟实验，我都会把抓包文件、分析笔记、结论整理成一个文档存档。下次遇到类似问题，直接翻文档比重新抓包分析快得多。网络故障这东西，太阳底下没有新鲜事，你遇到过的，大概率别人也遇到过，只是你当时没记下来而已。