网络故障模拟与抓包分析：用tc netem和tcpdump深入理解TCP/UDP行为

1. 为什么网络故障模拟值得每个后端和运维花时间啃

做后端开发或者运维的朋友，大概率都遇到过这种场景：线上服务突然大面积超时，监控面板上错误率飙升，但登录服务器一看，CPU、内存、磁盘IO全都正常，日志里也找不到明显的异常堆栈。这时候很多人第一反应是"重启试试"，重启完确实好了，但过两天又复发，根因始终没定位到。这类问题的本质，往往藏在网络层——丢包、乱序、重传、连接被重置、MTU不匹配、DNS解析抖动，这些故障在应用层日志里几乎看不到痕迹，只有把TCP和UDP的报文抓下来逐包分析，才能还原真相。

网络故障模拟这件事，核心价值不在于"制造故障"本身，而在于让你在可控环境里反复复现那些线上偶发、难以捕捉的网络异常，然后用抓包工具把每一个报文的行为看清楚。你只有亲手制造过20%的丢包，亲眼看到TCP三次握手在SYN重传三次后才成功，才会真正理解为什么某些接口的P99延迟会莫名其妙地飙到几秒。这种"从现象到报文"的对应关系，是任何文档和教程都替代不了的。

这篇文章适合三类人：一是后端工程师，想搞清楚自己写的服务在网络抖动时到底发生了什么；二是运维和SRE，需要一套可复现的故障注入方法来验证系统的容错能力；三是刚接触网络协议的学习者，想通过"制造问题—抓包—分析"的闭环把TCP和UDP的机制真正吃透。我会从工具选型、故障注入的具体操作、抓包分析的关键字段、以及我自己踩过的坑几个维度展开，尽量把每一步的"为什么"讲清楚，让你看完能直接在自己的测试环境里复现。

需要提前说明的是，网络故障模拟必须在你自己拥有完全控制权的隔离测试环境中进行，比如本地虚拟机、容器网络或者专门的测试网段。绝对不要在生产环境或者共享网络上做丢包、延迟注入，那会影响其他正常业务，这是底线。

2. 故障注入工具的选择逻辑与网络命名空间隔离

2.1 为什么优先选tc而不是应用层Mock

很多人做网络异常测试，第一反应是在代码里加个拦截器，模拟超时或者抛异常。这种做法的问题在于，它模拟的是"应用层感知到的结果"，而不是"网络层真实发生的过程"。比如你想测试服务在丢包情况下的重试逻辑，用Mock直接抛异常，你的TCP连接其实一直是健康的，重传机制根本没被触发，你测出来的行为和真实丢包场景完全不是一回事。

真正贴近真实的做法是用Linux内核自带的tc（traffic control）工具，配合netem（network emulation）模块。它工作在网络协议栈的链路层和网络层之间，能对真实的报文做延迟、丢包、乱序、重复、损坏等操作，上层的TCP/IP协议栈会像对待真实网络一样做出反应——该重传的重传，该降速的降速。这样你抓到的包，和线上出问题时的包在行为特征上是一致的。

tc的另一个好处是它不需要改任何应用代码，对被测服务完全透明。你只需要在网卡或者网络命名空间上挂一条规则，所有经过的流量就自动受影响。这对于验证第三方依赖、中间件、甚至数据库连接池的容错能力特别有用，因为你没法去改那些组件的代码。

2.2 用网络命名空间搭一个干净的实验台

直接在宿主机网卡上做故障注入有个风险：会影响你自己SSH连接或者其它正常流量。更稳妥的做法是用network namespace（网络命名空间）隔离出一对虚拟网卡，专门用来做实验。网络命名空间是Linux内核提供的网络隔离机制，每个命名空间有自己独立的网卡、路由表、iptables规则，互不干扰。

具体操作上，我通常建两个命名空间ns_client和ns_server，中间用一对veth（virtual ethernet）设备连起来，形成一个只有两个节点的迷你网络。这样无论我在哪一端注入多大的丢包和延迟，都不会影响到宿主机本身。命令大致如下：

# 创建两个网络命名空间 ip netns add ns_client ip netns add ns_server # 创建一对veth设备 ip link add veth_client type veth peer name veth_server # 分别放入两个命名空间 ip link set veth_client netns ns_client ip link set veth_server netns ns_server # 配置IP并启用 ip netns exec ns_client ip addr add 10.0.0.1/24 dev veth_client ip netns exec ns_client ip link set veth_client up ip netns exec ns_client ip link set lo up ip netns exec ns_server ip addr add 10.0.0.2/24 dev veth_server ip netns exec ns_server ip link set veth_server up ip netns exec ns_server ip link set lo up

配好之后，从ns_client里ping 10.0.0.2应该是通的。这个环境的好处是干净、可重复，实验做完直接ip netns del删掉，不留任何痕迹。我建议把这个搭建过程写成一个脚本，每次做实验前跑一遍，省得手动敲一堆命令还容易出错。

提示：如果你的内核没有加载netem模块，tc qdisc add会报错。用modprobe sch_netem手动加载一下，或者确认内核编译时已经包含该模块。

2.3 抓包工具的取舍：tcpdump与Wireshark的分工

抓包工具主流就两个：tcpdump和Wireshark。我的习惯是在命名空间里用tcpdump抓，把pcap文件导出来用Wireshark分析。原因很简单：tcpdump轻量、命令行友好、适合在隔离环境里跑；Wireshark的图形界面和协议解析能力更强，尤其是它的"Follow TCP Stream"和专家信息功能，能帮你快速定位重传、乱序、零窗口这些异常。

tcpdump的关键参数要记牢：-i指定网卡，-w写文件，-n不做DNS反解（避免抓包时产生额外流量干扰），-s 0抓完整报文（默认只抓前96字节，分析TCP选项时不够用）。一个典型的抓包命令：

ip netns exec ns_client tcpdump -i veth_client -n -s 0 -w /tmp/capture.pcap

抓完之后把/tmp/capture.pcap拷到宿主机，用Wireshark打开。这里有个细节：如果你在命名空间里抓包，文件路径是命名空间视角的，但命名空间和宿主机共享文件系统，所以直接就能访问，不用额外拷贝。

3. 用tc netem构造五类典型网络故障

3.1 延迟注入：理解RTT对吞吐的真实影响

延迟是最常见的网络故障之一。tc netem注入延迟的命令是：

ip netns exec ns_client tc qdisc add dev veth_client root netem delay 100ms

这条命令让从ns_client发出的所有报文都延迟100毫秒。注意是单向延迟，所以一个来回的RTT大约是200毫秒。你可以加抖动参数让它更真实：delay 100ms 20ms表示延迟在80到120毫秒之间随机波动，delay 100ms 20ms 25%表示25%的报文会有这个抖动。

延迟对TCP吞吐的影响，很多人只知道"延迟高吞吐低"，但不知道背后的机制。TCP的吞吐上限约等于窗口大小 / RTT。假设接收窗口是64KB，RTT是200ms，那理论吞吐就是64KB/0.2s=320KB/s，也就是2.5Mbps左右。这就是所谓的带宽时延积（BDP）限制。你在抓包里会看到，发送方发出去一批数据后，必须等ACK回来才能继续发，RTT越大，这个"等待"占的时间比例越高，链路利用率就越低。

实测的时候我建议你同时观察两个指标：一是ss -i看到的cwnd（拥塞窗口）和rtt，二是抓包里数据包和ACK的时间间隔。你会发现延迟注入后，cwnd的增长明显变慢，因为慢启动阶段每收到一个ACK才涨一个MSS，RTT翻倍意味着cwnd翻倍所需的时间也翻倍。

3.2 丢包注入：观察TCP重传与拥塞窗口的连锁反应

丢包注入的命令：

ip netns exec ns_client tc qdisc add dev veth_client root netem loss 10%

10%的丢包率在真实网络里已经算相当糟糕了。注入之后，你会看到TCP的行为发生一系列连锁反应。首先是快速重传：接收方收到乱序报文后会重复发送ACK，发送方收到三个重复ACK就立即重传丢失的报文，不用等超时。如果丢包严重到连重复ACK都凑不齐三个，就会触发RTO超时重传，这个代价就大了——RTO的最小值通常是200ms起步，而且超时后cwnd会被直接降到1个MSS，相当于重新慢启动。

抓包分析时，重点看这几个特征：Wireshark会把重传标记成[TCP Retransmission]，把快速重传标记成[TCP Fast Retransmission]，把乱序标记成[TCP Out-of-Order]。你可以统计一段时间内的重传率，如果重传率超过5%，基本可以判断链路质量有问题。另外注意看[TCP Dup ACK]，连续三个Dup ACK就是快速重传的触发信号。

我踩过的一个坑是：丢包率设得太高（比如30%），TCP连接可能直接卡死，因为ACK也丢了，双方都在等对方，最后只能靠RTO慢慢磨。这种极端场景虽然真实网络少见，但能帮你理解为什么有些弱网环境下连接会"假死"。

3.3 乱序与重复：区分网络问题和应用问题

乱序注入：

ip netns exec ns_client tc qdisc add dev veth_client root netem delay 50ms reorder 25% 50%

reorder 25% 50%的意思是25%的报文会被乱序发送，其中50%的乱序报文会被延迟发送。乱序和丢包在抓包上容易混淆，因为两者都会导致接收方收到乱序的序列号。区别在于：乱序的报文最终会到达，只是顺序不对；丢包的报文是真的没了，需要重传。

Wireshark对乱序的标记是[TCP Out-of-Order]，对丢包重传的标记是[TCP Retransmission]。如果你看到大量Out-of-Order但没有Retransmission，说明是网络乱序而非丢包。乱序本身不会导致数据丢失，但会触发快速重传机制（因为接收方发的Dup ACK和丢包场景一样），造成不必要的重传，浪费带宽。

重复注入用duplicate参数：

ip netns exec ns_client tc qdisc add dev veth_client root netem duplicate 5%

重复报文在抓包里表现为两个完全相同的序列号，接收方会丢弃第二个。这个场景主要用来测试应用层对重复数据的幂等处理能力。

3.4 报文损坏与MTU陷阱

报文损坏注入：

ip netns exec ns_client tc qdisc add dev veth_client root netem corrupt 3%

corrupt会随机修改报文中的某些比特位。对于TCP来说，损坏的报文会被校验和检测出来并丢弃，效果等同于丢包。但对于UDP来说，如果应用层没有校验机制，损坏的数据可能直接被业务逻辑处理，造成难以排查的数据错误。这也是为什么很多UDP协议（比如某些游戏协议）要在应用层自己做校验。

MTU问题更隐蔽。当路径MTU不匹配时，大包会被分片或者直接丢弃。你可以在命名空间里把MTU调小来模拟：

ip netns exec ns_client ip link set veth_client mtu 576

576字节是IPv4要求的最小重组缓冲区大小。调小MTU后，如果应用发送超过MTU的报文且设置了DF（Don't Fragment）标志，就会收到ICMP "Fragmentation Needed"消息。如果ICMP被防火墙拦了，就会出现经典的"小包能通、大包卡死"现象。抓包时你会看到发送方反复重传同一个大包，但始终收不到ACK。

3.5 带宽限制与队列规则

限速用tbf（token bucket filter）而不是netem：

ip netns exec ns_client tc qdisc add dev veth_client root tbf rate 1mbit burst 32kbit latency 400ms

这条命令把出口带宽限制在1Mbps。burst是令牌桶的容量，latency是允许的最大排队延迟。限速场景下，你会看到发送方的发送速率被压制，TCP的cwnd增长到一定程度就上不去了，因为链路容量就那么大。抓包里表现为数据包之间的间隔变大，但重传很少——这和丢包场景有本质区别。

把netem和tbf组合使用可以模拟更复杂的场景，比如"高延迟+低带宽"，这更接近卫星链路或者跨国专线的真实情况。组合的时候注意qdisc的层级，通常tbf作为根qdisc，netem作为子qdisc挂在下面。

4. 抓包分析的核心字段与异常识别方法

4.1 从三次握手看连接建立的健康度

分析任何TCP问题，第一步都是看三次握手。正常的握手是：客户端发SYN，服务端回SYN+ACK，客户端再回ACK。抓包里看这三个包的时间戳，就能算出连接建立的耗时。如果SYN和SYN+ACK之间隔了很久，说明网络延迟高或者服务端处理慢；如果客户端发了SYN但没收到SYN+ACK，会看到SYN重传，重传间隔通常是1秒、2秒、4秒这样的指数退避。

Wireshark的专家信息（Analyze → Expert Information）会直接告诉你有没有"Connection establish"相关的异常。我习惯先看这个面板，它能快速把重传、乱序、零窗口、连接重置这些异常分类列出来，比一个个包翻效率高得多。

握手阶段还有一个容易忽略的点：TCP选项。SYN包里会携带MSS、窗口缩放因子、SACK permitted、时间戳等选项。如果两端的窗口缩放因子不一致，或者一方不支持SACK，会影响后续的传输效率。比如窗口缩放因子是0（不支持缩放），那最大窗口就是64KB，在高延迟链路上吞吐会被严重限制。

4.2 重传、重复ACK与拥塞窗口的联动分析

重传分析是抓包的重头戏。Wireshark里重传的几种类型要分清楚：

虚假重传特别值得关注，它通常发生在网络乱序场景下：发送方以为丢包了触发重传，结果原报文和重传报文都到了接收方。这会造成带宽浪费。判断方法是看重传报文之后是否很快收到了对应原报文的ACK。

拥塞窗口的变化在抓包里不能直接看到，但可以通过发送速率间接推断。Wireshark的"TCP Stream Graphs"里有"Window Scaling"和"Throughput"图，能直观展示cwnd的增长和收缩。慢启动阶段是指数增长，进入拥塞避免后变成线性增长，一旦发生丢包cwnd会骤降。你在丢包注入实验里会看到这个曲线像锯齿一样上下波动，这就是TCP的AIMD（加性增乘性减）特性。

4.3 UDP抓包的特殊性：无连接、无重传、全靠应用层

UDP的抓包分析和TCP完全不同。UDP没有握手、没有ACK、没有重传、没有拥塞控制，每个报文都是独立的。这意味着：

• 丢包在UDP层面是"静默"的，抓包里就是少了一个序列号（如果应用层有序列号的话），没有任何协议层的异常标记。
• 乱序在UDP里是常态，因为UDP不保证顺序，应用层必须自己处理。
• 没有流的概念，Wireshark不会把UDP报文归并成"流"，你需要靠端口号和应用的序列号字段来重组。

分析UDP故障时，重点看几个东西：一是报文的时间间隔是否均匀，如果突然出现大段空白，说明中间有丢包或者网络抖动；二是应用层的序列号是否连续，很多自定义UDP协议会在payload里带seq号，这是判断丢包的唯一依据；三是报文大小是否超过MTU导致分片，分片后的UDP报文如果丢失任何一片，整个报文就废了。

我做过一个实验：在UDP流上注入10%丢包，然后用一个带序列号的应用层协议发送1000个报文。抓包统计发现实际到达的报文里，序列号缺口分布并不均匀，有时候连续丢好几个，有时候很久不丢。这说明了netem的丢包是独立随机事件，但真实网络的丢包往往是突发的（因为拥塞），所以做故障模拟时可以考虑用loss gemodel（Gilbert-Elliott模型）来模拟突发丢包，更接近真实。

4.4 用IO Graph和流量统计定位异常时间点

Wireshark的IO Graph（Statistics → IO Graph）是个被低估的功能。它能把抓包文件里的流量按时间画成曲线，你一眼就能看出哪个时间段流量突增或突降。比如你在做延迟注入实验，IO Graph上会看到流量呈现明显的"阶梯状"，因为TCP发一批等一批，RTT越大阶梯越宽。

流量统计（Statistics → Conversations）则能帮你快速找到流量最大的连接。有时候一个抓包文件里有几十个连接，你只需要分析出问题的那个，用Conversations按字节数排序，排在前面的通常就是问题连接。

还有一个技巧是用显示过滤器快速筛选异常包。比如tcp.analysis.retransmission只看重传，tcp.analysis.zero_window只看零窗口，tcp.flags.reset == 1只看RST包。把这些过滤器存成按钮，分析时一键切换，效率能提升不少。

5. 实操中容易翻车的细节与排查链路

5.1 qdisc规则不生效的三种常见原因

第一次用tc的人经常会遇到"命令执行成功了但流量没变化"的情况。我总结下来主要有三个原因：

第一，qdisc挂错了方向。tc qdisc add dev eth0 root影响的是出口流量，也就是从这块网卡发出去的包。如果你想影响入口流量，需要用ingress qdisc配合ifb设备做重定向，复杂得多。做实验时我建议统一在发送端注入，这样方向明确。

第二，命名空间里的网卡名和宿主机搞混了。在ip netns exec ns_client里执行tc，操作的是命名空间内的网卡；如果忘了加ip netns exec，操作的就是宿主机的网卡。这个错误很隐蔽，因为命令本身不报错，只是作用对象错了。

第三，已有的qdisc没清理。一个网卡上root qdisc只能有一个，如果你之前挂过netem没删，再挂新的会报"Exclusivity flag on, cannot modify"。正确做法是先tc qdisc del dev veth_client root清理，再挂新的。我习惯在实验脚本开头统一清理一遍。

5.2 抓包文件过大与过滤策略

做丢包实验时，如果流量大、跑得久，pcap文件可能几个GB，Wireshark打开直接卡死。解决办法有两个：一是抓包时就加过滤，只抓关心的流量，比如tcpdump -i veth_client 'tcp port 8080'；二是用-C参数限制单个文件大小，配合-W限制文件数量，实现循环覆盖。

ip netns exec ns_client tcpdump -i veth_client -n -s 0 -C 100 -W 5 -w /tmp/cap.pcap 'tcp port 8080'

这条命令每个文件最大100MB，最多5个文件循环写，总占用不超过500MB。对于长时间实验很实用。

另外，分析时善用Wireshark的"Export Specified Packets"功能，把关心的时间段或者特定TCP流单独导出成小文件，分析起来更流畅。

5.3 时间戳精度对RTT计算的影响

计算RTT时，时间戳精度很关键。tcpdump默认的时间戳精度是微秒级，对于局域网实验够用了。但如果你在跨主机做实验，两端时钟不同步，算出来的单向延迟就不准。这时候只能算RTT（同一个抓包点看到的SYN和ACK的时间差），不能算单向延迟。

Wireshark里有个实用功能：选中一个TCP流，用"TCP Stream Graphs → Round Trip Time"能自动画出RTT随时间的变化曲线。这个曲线在延迟注入实验里特别有用，你能直观看到RTT从几毫秒跳到几百毫秒的过程，以及TCP是如何适应这个变化的。

5.4 从现象反推根因的排查思路

最后分享一个我常用的排查链路。当你面对一个网络故障现象时，按这个顺序走：

1. 确认故障范围：是单个连接还是所有连接？是单向还是双向？这决定了是链路问题还是端点问题。
2. 看握手是否正常：握手都失败，问题在连接建立阶段，重点看SYN重传和RST。
3. 看传输阶段的重传率：重传率高说明链路质量差，重点看是超时重传还是快速重传。
4. 看窗口和拥塞控制：零窗口说明接收方处理不过来，cwnd骤降说明网络拥塞。
5. 看应用层行为：如果协议层都正常但业务还是有问题，那可能是应用层的超时设置、重试策略或者序列化问题。

这个链路的核心逻辑是"从下往上排除"，先把网络层的问题排干净，再怀疑应用层。很多团队排查故障时一上来就翻应用日志，结果网络层的问题被忽略了，绕了一大圈才回到抓包。

我在实际项目里遇到过一个案例：某个服务调用第三方接口，偶发超时，但第三方说他们那边一切正常。后来在调用方抓包发现，TCP连接建立后，第一个数据包发出去后等了整整3秒才收到响应，而第三方的日志显示他们100毫秒内就返回了。进一步分析发现，是中间某个网络设备的MTU问题导致大包被丢弃，小包正常，而第三方返回的响应恰好超过MTU。这种问题不抓包根本无从查起。

网络故障模拟和抓包分析这项技能，说到底就是"把不可见的东西变可见"。你制造的每一个丢包、每一毫秒延迟，最终都会在报文序列里留下痕迹，学会读这些痕迹，线上排障时心里就有底了。建议你从最简单的延迟注入开始，一步步加上丢包、乱序、限速，每加一个变量就抓一次包对比分析，做上十几轮，TCP和UDP的行为模式基本就刻在脑子里了。