Skip to content

Linux TC 网络排错实战：搞定延迟、抖动、丢包、带宽瓶颈

在后端、运维、测试日常工作中，绝大多数网络问题都不是“断网”这种简单故障，而是偶发超时、接口抖动、大文件传输卡顿、并发场景随机丢包、跨机房访问不稳定等隐性问题。

这类问题在正常网络环境下极难复现，单纯靠 ping、traceroute、tcpdump 只能看到结果，无法模拟故障、定位根因。

而 Linux TC（Traffic Control） 是内核级网络流量控制工具，也是服务端网络排错、稳定性测试的神器。它可以人为模拟各类网络异常，帮我们复现线上疑难问题、验证程序容错性、定位性能瓶颈。

本文聚焦网络排错真实场景，不讲空泛理论，结合4个生产高频故障案例，手把手教你用TC排查、复现、解决网络问题。

一、先搞懂：排错视角下的TC核心能力

很多人对TC的认知只停留在“限速”，但在排错场景中，它的核心价值是可控复现网络异常，精准模拟线上复杂网络环境：

  • 模拟网络延迟：跨机房、公网访问延迟高，排查接口超时问题

  • 模拟网络抖动：延迟忽高忽低，排查TCP重传、HTTP重试失败问题

  • 模拟随机丢包：弱网、公网丢包导致的接口报错、文件传输中断

  • 模拟带宽限流：排查大流量挤占带宽导致的核心业务卡顿

  • 模拟报文乱序、重复：排查特殊网络场景下的程序解析异常

关键核心知识点（排错必看）

1. TC 默认只管控网卡出方向（egress）流量，入方向限流需搭配 ifb 虚拟网卡；

2. 排错最常用两大队列：

  • netem：网络仿真，主打延迟、抖动、丢包、乱序（排错核心）

  • htb：带宽限流，主打精准限速、流量分级（瓶颈排查核心）

3. 所有规则临时生效，重启服务器或手动清空即可恢复，无永久副作用。

二、通用前置命令（所有案例通用）

操作前必须掌握清空、查看规则命令，避免规则残留干扰测试：

# 1. 清空网卡所有TC规则（必用，防止旧规则干扰）
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc del dev eth0 ingress 2>/dev/null

# 2. 查看当前生效的所有网络模拟/限速规则
tc qdisc show dev eth0

# 3. 查看流量分类、过滤规则
tc class show dev eth0
tc filter show dev eth0

后文所有案例网卡统一使用 eth0，可根据实际环境替换。

三、真实排错案例实战

案例一：线上接口偶发超时，排查是否为网络延迟导致

故障现象

本地、测试环境调用接口正常，线上跨机房访问偶尔超时，日志无代码异常，无法稳定复现，怀疑是公网/跨机房延迟过高导致。

排错思路

用 TC 固定增加网络延迟，模拟跨机房高延迟环境，复现超时问题，验证程序超时阈值是否合理。

实操命令

# 给网卡所有出站流量增加 150ms 固定延迟（模拟跨机房延迟）
tc qdisc add dev eth0 root netem delay 150ms

验证结果

ping 外网IP/接口域名
# 可观察到延迟稳定在150ms左右，复现线上超时问题

问题定位与优化

若150ms延迟下接口频繁超时，说明业务超时时间设置过短（如默认50ms、100ms），无法适配公网跨机房环境；解决方案：合理调大接口超时时间，或增加重试机制。

恢复环境

tc qdisc del dev eth0 root

案例二：业务抖动严重，排查网络延迟抖动问题

故障现象

服务响应时间不稳定，时而10ms、时而500ms，无规律波动，CPU、内存、GC均正常，怀疑网络抖动导致。

排错思路

真实公网网络并非固定延迟，而是存在波动。用TC模拟延迟抖动，复现响应时间波动问题。

实操命令

# 基础延迟200ms，上下浮动50ms（150ms~250ms随机波动）
tc qdisc add dev eth0 root netem delay 200ms 50ms

排错结论

开启抖动模拟后，业务响应时间波动与线上故障完全一致，证明业务抖动根因为网络延迟抖动，非程序问题。可通过优化TCP参数、启用连接池、增加超时重试、就近接入解决。

案例三：线上随机丢包，导致文件传输失败、接口重试报错

故障现象

线上偶尔出现文件上传/下载中断、HTTP接口请求失败、TCP重传增多，概率性出现，无固定规律，大概率是公网随机丢包。

排错思路

人为模拟固定概率丢包，复现故障，同时验证程序的容错、重试、断点续传能力是否达标。

实操命令

# 模拟5%随机丢包（公网常见弱网场景）
tc qdisc add dev eth0 root netem loss 5%

# 进阶：模拟10%丢包+网络抖动，极致压测容错性
tc qdisc add dev eth0 root netem delay 100ms 20ms loss 10%

故障定位

开启丢包模拟后，成功复现文件传输中断、接口报错问题，且与线上报错日志完全匹配。说明程序容错机制不完善，未处理网络丢包场景，需优化重试逻辑、增加异常捕获。

案例四：大流量挤占带宽，核心业务卡顿无响应

故障现象

服务器同步大文件、备份数据时，SSH连接卡顿、核心接口响应极慢，带宽被非核心业务占满，导致核心业务无资源可用。

排错思路

通过TC HTB队列做带宽限流，模拟带宽打满场景，验证带宽挤占问题，同时配置流量分级，实现生产环境带宽隔离。

实操命令

# 1. 初始化根队列，整机总带宽100Mbps
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit

# 2. 限制非核心业务（文件传输、备份）带宽最大20Mbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit ceil 20mbit

# 3. 匹配文件传输端口（以22端口ssh为例）限流
tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip dport 22 0xffff flowid 1:10

# 4. 核心业务默认占用剩余带宽，保障优先使用
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 80mbit ceil 100mbit

排错优化结果

限流后，大文件传输不再挤占全部带宽，SSH、核心接口访问恢复正常。通过TC实现业务带宽QoS优先级，彻底解决带宽抢占导致的核心业务卡顿问题。

四、高频排错组合命令（一键模拟复杂故障）

线上真实网络故障往往是多种问题叠加，分享生产最常用的组合模拟命令：

# 场景1：弱网环境（延迟+抖动+丢包，模拟4G/公网弱网）
tc qdisc add dev eth0 root netem delay 180ms 40ms loss 3%

# 场景2：高延迟+轻微丢包（跨机房专线不稳定场景）
tc qdisc add dev eth0 root netem delay 300ms loss 2%

# 场景3：网络乱序（极少数接口解析异常、TCP异常场景）
tc qdisc add dev eth0 root netem reorder 20% gap 3

五、排错常见误区（避坑指南）

1. 只控出站，不控入站：TC默认只能管控出站流量，排查下载、入站流量故障时，必须搭配 ifb 虚拟网卡，否则规则不生效；

2. 规则叠加不清理：多次执行TC命令会叠加规则，导致延迟、丢包翻倍，排错前务必清空旧规则；

3. 混淆bit和Byte：TC单位为mbit（比特），1MB/s=8mbit，不要误以为10mbit就是10MB/s；

4. 测试后不恢复环境：TC规则重启后失效，但线上测试必须手动清空，避免长期影响业务。

六、总结：TC在网络排错中的核心价值

绝大多数线上隐性网络故障，难点不在于“解决”，而在于无法复现、无法定位。

Linux TC 作为内核级流量控制工具，让我们可以人为、可控、精准地模拟所有线上网络异常场景：延迟、抖动、丢包、带宽瓶颈、报文乱序。

在网络排错、服务稳定性测试、容错性验证、QoS优化场景中，TC是不可或缺的核心工具，掌握它可以解决90%以上的疑难网络偶现故障。

附：快速恢复纯净网络环境

tc qdisc del dev eth0 root 2>/dev/null
tc qdisc del dev eth0 ingress 2>/dev/null
echo "网络规则已全部清空，恢复默认环境"