前几天帮同事排查一个接口偶发超时的问题本地怎么都复现不出来后来在测试机上敲了一条命令把延迟拉到 200ms、丢包 5%问题立刻稳定复现。事后复盘这一整套活儿其实不用动交换机、不用动路由器一条 linux tc 命令就够了。很多做后端、做嵌入式、做测试的同学都听过 tc 的大名但真上手的时候会被 htb、netem、u32、ifb 这些名词绕晕最后只能去网上抄一条命令碰运气。这篇就把我在实际项目里用 linux tc 做网络限速、丢包模拟、延迟设置这套东西从头到尾捋一遍包括概念、参数计算、完整命令、验证方式还有我踩过的那些坑。内容偏实战命令可以直接抄走改改就用适合运维、后端开发、测试工程师以及任何需要在一台机器上模拟弱网环境的人。不管你之前有没有碰过 tc看完至少能做到知道每条命令在干什么参数为什么这么填出了问题往哪儿查。1. 先把 tc 的底层逻辑搞清楚再敲命令1.1 内核流量控制的三层结构tc 全称 traffic control是 linux 内核自带的一套流量控制工具属于 iproute2 工具包的一部分。它的核心模型分三层队列规则qdisc、类别class、过滤器filter。这三层的关系我用一个快递分拣站的类比来讲最直观。qdisc 就是分拣站本身网卡发出的每一个包都要先进这个分拣站排队。一个网卡上根 qdisc 只能有一个ingress 方向除外后面会讲。class 是分拣站里的不同通道比如一条通道专门走内部办公流量一条通道走备份流量每个通道可以有自己的发送速率上限。filter 就是门口的安检员它根据包的 IP、端口、协议标志把包扔进对应的通道里。理解了这个模型再看命令就顺了tc qdisc add是建分拣站tc class add是开通道tc filter add是安排安检员。绝大多数场景下你只需要建一个根 qdisc加几个 class再加几条 filter就这么简单。如果你只是想做一个全局延迟或者全局丢包那连 class 和 filter 都不用直接建一个 netem 根 qdisc 就完事。这里有个特别容易忽略的点qdisc 默认是作用在 egress发送方向的。也就是说tc 管的是本机发出去的包。你想限制本机收到的包光靠 root qdisc 是做不到的得用 ifb 虚拟网卡把入向流量重定向过来再整形。这个我放到第 4 节展开讲先记住结论限速限的是发出去的不是收进来的。1.2 为什么不直接用应用层的限速方案很多人第一反应是限速嘛我写个脚本读网卡流量超了就 sleep 一下不就行了或者用应用层的连接池、令牌桶自己控。这些方案在小流量下能用但一到真实场景就露怯。应用层限速的问题有三个。第一是不精确你在用户态计算流量等算出超限了内核已经又发出去了几 MB限速曲线跟锯齿一样。第二是管不住别人你只能管自己这个进程同机器上其他进程照样把带宽吃干净。第三是不通用TCP、UDP、ICMP 你得分别处理遇到别人写的程序你根本插不进去。内核层的 tc 就没这些毛病。它是挂在网卡队列上的包从协议栈出来、进网卡驱动之前就被拦住了精确到包级别。不管是哪个进程、哪种协议只要从这个网卡出去统统走同一套规则。而且它几乎不占 CPU因为是内核里做的不需要上下文切换。这也是为什么做弱网测试、做多租户带宽隔离行业内默认都用 tc 而不是自己造轮子。注意tc 只在数据包离开本机网卡那一刻生效。它控制不了物理链路上的拥塞也控制不了对端的行为。所以做延迟模拟时你看到的是本机发包被延迟了而不是整条链路被延迟了这个认知差在排查问题时很关键。1.3 三个必须先记住的概念和单位在动手之前有几个概念和单位必须先统一不然命令写出来你自己都不知道对不对。handle 和 classid 的命名规则。handle 是 qdisc 的编号格式是主:次比如1:就是主编号 1、次编号 0次编号省略时默认 0。classid 是 class 的编号格式必须是主:次比如1:10就是挂在主编号 1 下面的第 10 号通道。filter 用parent 1:指向根 qdisc用flowid 1:10把包导向对应通道。编号只要保证同一层级内不冲突就行习惯上主编号用 1次编号从 10 开始中间留出空间方便以后插入新通道。速率单位。tc 里kbit、mbit、gbit是 1000 进制kib、mib是 1024 进制另外kbps在 tc 里等价于kbit都是 1000。限速时建议统一用mbit写起来清楚也不容易搞混。你要是把 100Mbps 写成 100mib实际会变成 104.8Mbps测出来的结果和预期对不上这种低级错误我见过不少人犯。burst 和 cburst。这两个是 HTB 特有的参数表示令牌桶的容量。burst 是普通桶cburst 是ceil 桶发送超过 rate 时用的突发额度。很多人限速不生效、或者一限速就卡顿得厉害八成是这两个参数没调好。桶太小包发不出去被丢表现为限速之后丢包严重桶太大突发流量直接冲破限制表现为限速根本没用。概念讲完了下面直接进环境准备。2. 环境准备与基础命令速查2.1 确认内核版本和 tc 版本动手之前先确认两件事内核支持哪些 qdisctc 命令是不是新的。# 查看内核版本 uname -r # 查看 tc 版本一般 iproute2 都在 4.x 以上 tc -V # 查看当前内核支持的所有 qdisc 类型 ls /lib/modules/$(uname -r)/kernel/net/sched/ # 查看内核 HZ 值这个后面算 burst 会用到 zcat /proc/config.gz 2/dev/null | grep CONFIG_HZ # 如果上面没输出试试 grep CONFIG_HZ /boot/config-$(uname -r)CONFIG_HZ这个值非常关键它决定了 TC 的最小 burst。内核每秒钟产生 HZ 次时钟中断理论最小 burst 就是rate / HZ。比如 Ubuntu 常见CONFIG_HZ250你要限速 1mbit那最小 burst 就是 4000bit折算下来 500 字节。如果 burst 给得比这个还小内核会自动调整到一个能工作的值但限速精度就崩了。所以记住一个经验值burst 取rate × 10ms左右基本不会出错。1mbit 的限速burst 填 10kbit100mbit 的限速burst 填 1000kbit。netem 模块一般内置如果没有加载一下modprobe sch_netem modprobe sch_htb modprobe sch_tbf modprobe ifb2.2 查看当前的队列规则改之前一定先看现状不然很容易把系统默认的 qdisc 覆盖掉导致网络行为变化。# 看网卡上一个根 qdisc tc qdisc show dev eth0 # 看详细信息包含统计计数 tc -s qdisc show dev eth0 # 看 class 和 filter tc class show dev eth0 tc filter show dev eth0现代发行版的默认根 qdisc 通常是fq_codel这个队列本身有抗缓冲膨胀的能力延迟表现不错。如果你只是临时加个 netem用replace会把 fq_codel 换掉测试完记得删掉恢复默认。真实生产机上做限速时我一般会把 fq_codel 作为叶子 qdisc 保留下来而不是直接丢掉。网卡名字这块顺便提一句现在很多系统用enp3s0、ens33这种可预测命名ip link show看一眼就知道哪个是你真正在用的网卡。虚拟机上通常是ens33或eth0容器里是veth打头的操作 veth 也能影响到容器的网络行为。2.3 几条高频命令的模板我把自己最常用的几条命令整理成模板改改参数就能用。# 1) 临时删除根 qdisc恢复默认 tc qdisc del dev eth0 root # 2) 全局延迟 100ms抖动 10ms tc qdisc add dev eth0 root netem delay 100ms 10ms # 3) 全局丢包 5% tc qdisc add dev eth0 root netem loss 5% # 4) HTB 限速总带宽 100mbit默认走 1:30 tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1mbit ceil 2mbit tc class add dev eth0 parent 1:1 classid 1:30 htb rate 90mbit ceil 100mbit # 5) 把目标 IP 走限速通道 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 192.168.1.100/32 flowid 1:10注意第 4 条里default 30的含义没有匹配上任何 filter 的包默认走 1:30 这个通道。这是个安全阀防止你一加 filter 就把默认流量全丢了。很多人第一次配 HTB忘了写 default结果所有不匹配的流量全走 1:0 这个不存在的类直接断网然后就以为 tc 把机器搞崩了。3. 网络限速实战Qdisc 选型与参数计算3.1 HTB、TBF、CBQ 到底怎么选限速这一块常用的 qdisc 就三个TBF、HTB、CBQ。CBQ 是老古董算法复杂、参数难调现在已经基本被淘汰新项目不要碰。剩下两个怎么选我给你一张对照表。特性TBFHTB适用场景单条流简单限速多通道、分层限速是否支持分类不支持支持可挂多个 class最小速率限制约 1kbit 以上可低至 1bit突发控制参数少控制粗burst/cburst 精细控制叶子 qdisc无可挂 netem 等子 qdisc配置复杂度低中结论很明确只做单点限速用 TBF 图省事只要涉及多通道、分层、或者要和 netem 组合必须用 HTB。HTB 可以做总带宽 100MA 部门 30MB 部门 20M剩下共享这种结构TBF 做不到。还有一点TBF 的最小速率有限制如果你想限到 1kbit 这种极低值TBF 会报错换成 HTB 就没问题。至于 CBQ除非你在维护十年前的老系统否则不要用。3.2 令牌桶参数到底怎么算HTB 的核心是令牌桶算法。你可以把它想成一个水桶桶上面有个水龙头按 rate 往桶里滴水每个包要拿走跟它大小相等的水才能被发出去。桶满了水会溢出桶空了包就得等。burst 就是桶的容量cburst 是超额桶的容量。参数怎么定我总结了一套自己的算法rate你要限的目标速率直接填。burst取rate × 10ms。为什么是 10ms因为 TCP 的 RTT 通常在几十毫秒量级10ms 的突发窗口足够兜住一次 ACK 回包后的突发又不至于让突发流量把限速冲垮。算例限速 10mbitburst 10mbit × 0.01s 0.1mbit 100kbit大概 12.5KB。cburst一般取和 burst 相同或者稍微大一点。如果你希望某条流能在空闲时借更多带宽cburst 可以给到 burst 的 2 倍。ceil这条通道能借到的最大速率上限。如果不想让它借带宽ceil 就等于 rate。如果允许借ceil 设成父类的 rate 就行。一个具体的完整算例机器总出口 100mbit要给测试机 192.168.1.100 限速 5mbit突发不超过 10mbit。# 根 qdisc总带宽 100mbit tc qdisc add dev eth0 root handle 1: htb default 999 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit # 目标通道rate 5mbitceil 10mbit # burst 5mbit × 10ms 50kbit # cburst 10mbit × 10ms 100kbit tc class add dev eth0 parent 1:1 classid 1:10 htb \ rate 5mbit ceil 10mbit burst 50kbit cburst 100kbit # 默认通道吃掉剩下的带宽 tc class add dev eth0 parent 1:1 classid 1:999 htb \ rate 90mbit ceil 100mbit burst 900kbit cburst 1000kbit这套参数我在多个环境里验证过限速曲线很平稳用tc -s class show dev eth0看 rate 那一列会稳定在设定值附近小幅波动不会出现大起大落。3.3 Filter 的三种匹配写法包怎么进对应通道全靠 filter。常用的有三种匹配方式各有适用场景。u32 匹配最灵活直接匹配 IP、端口、协议。适合目标固定的场景。# 按目标 IP 限速 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 192.168.1.100/32 flowid 1:10 # 按目标端口限速匹配 ipv4 且目的端口 8080 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip dport 8080 0xffff flowid 1:10fw 匹配配合 iptables 的 MARK 标记来分流。适合规则复杂、要按用户或连接状态分流的场景因为 iptables 的匹配能力比 tc 强得多。# iptables 打标记 iptables -t mangle -A OUTPUT -d 192.168.1.100 -j MARK --set-mark 10 # tc 按标记分流注意这里要写 handle 0x10 而不是数字 10 tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw flowid 1:10这里有个经典的坑fw filter 里的 handle 默认按十六进制解析。你 iptables 打的 mark 是 10十进制tc 里写handle 10会被当成 0x10 16对不上就永远不生效。写法是handle 0x10。这个问题我在真实项目里排查了两个小时最后靠tc -s filter show里 counter 一直是 0 才定位出来。flower 匹配现代内核推荐的方式语法比 u32 友好性能也更好新一点的发行版都支持。tc filter add dev eth0 protocol ip parent 1: prio 1 flower \ ip_proto tcp dst_port 443 classid 1:10三种方式我都用过日常小场景用 u32 足够规则多了以后建议切到 fw iptables可维护性好很多。flower 是趋势新项目可以优先考虑。4. 延迟与丢包netem 模块的完整用法4.1 延迟、抖动、相关性三个参数netemnetwork emulator是专门用来模拟网络损伤的 qdisc延迟、丢包、乱序、重复、损坏都能做。做延迟模拟的基本命令是这一条tc qdisc add dev eth0 root netem delay 100msdelay 100ms表示每个包延迟 100ms 再发出去。但真实网络的延迟不是恒定值而是有波动的所以还有两个参数要掌握。# 100ms 基础延迟上下抖动 20ms tc qdisc add dev eth0 root netem delay 100ms 20ms # 抖动带相关性20% 的包延迟受前一个包影响 tc qdisc add dev eth0 root netem delay 100ms 20ms 25%第一个附加参数是jitter抖动表示延迟在100±20ms区间内随机分布。第二个附加参数是correlation相关性它表示当前包的延迟有多大程度继承上一个包的延迟。这个参数很反直觉但很重要没有相关性时每个包的延迟完全独立随机你 ping 出来的曲线是杂乱无章的加上相关性后延迟会出现成片偏高、成片偏低的现象更接近真实广域网的表现。做测试时如果需要模拟真实的跨地域延迟建议加上 20%~30% 的相关性。还可以指定分布模型让随机值符合特定规律# 正态分布 tc qdisc add dev eth0 root netem delay 100ms 20ms distribution normal # 泊松分布模拟突发式延迟 tc qdisc add dev eth0 root netem delay 100ms 20ms distribution pareto默认是 uniform均匀分布。做网络仿真论文时一般用 normal 或 pareto日常测试用默认的就够。4.2 丢包、重复、乱序的组合写法丢包的语法和延迟类似# 随机丢包 5% tc qdisc add dev eth0 root netem loss 5% # 5% 丢包25% 相关性 tc qdisc add dev eth0 root netem loss 5% 25%相关性在这里的含义是上一次丢包之后这次继续丢的概率加成。无线网络、移动网络里丢包往往是成片的信号差的时候连续丢加上相关性才能模拟出这种特征。做弱网测试时我一般用loss 2% 50%这种配置能模拟出比较真实的地铁、电梯场景。重复、乱序、损坏也一并列出来# 重复 1% 的包 tc qdisc add dev eth0 root netem duplicate 1% # 乱序5% 的包乱序其中 50% 有相关性 tc qdisc add dev eth0 root netem reorder 5% 50% # 损坏1% 的包某个 bit 被翻转 tc qdisc add dev eth0 root netem corrupt 1%想组合多个效果直接写在一条命令里tc qdisc add dev eth0 root netem delay 50ms 10ms loss 3% duplicate 1% reorder 2%这条命令我用得特别多它基本能模拟出网络一般般但不是完全不能用的那种状态用来测 APP 的抗弱网能力非常合适。注意netem 的所有参数都是在发包时生效的。对于本机收包方向的延迟netem 管不了得靠 ifb。另外延迟值是单向的你在 lo 上加 100msping 127.0.0.1 看到的 RTT 大概是 200ms 上下因为包出和包回各过一次 qdisc。别看到这个数字以为命令写错了。4.3 限速和弱网叠加时的顺序问题实际项目里经常要同时限速和加延迟。这时候 qdisc 的组织就讲究了一个 qdisc 只能挂一个根你得把 netem 作为 HTB 的叶子 qdisc挂上去。# 根 HTB tc qdisc add dev eth0 root handle 1: htb default 999 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit ceil 10mbit # 在 1:10 这个类下面挂 netem单位是 10: tc qdisc add dev eth0 parent 1:10 handle 10: netem delay 100ms 10ms loss 2% # 流量导入 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip dst 192.168.1.100/32 flowid 1:10顺序是这样的包先被 filter 识别送进 1:10 这个类类先按 5mbit 的令牌桶判断能不能发能发的话再经过挂在下面的 netem加 100ms 延迟和丢包最后出网卡。限速在前、弱网在后这个顺序别搞反反过来会先加延迟再排队实际的带宽利用率会明显下降。还有一个细节parent 1:10这里写的是 class 的 classidhandle 10:是给这个 netem 起的新编号两者不是一回事。第一次写的时候很容易写成parent 1:10 handle 1:10那样会报错因为 handle 的主编号不能和父级重复。5. 入向流量的处理与 ifb 虚拟网卡5.1 为什么必须用 ifb前面反复强调过tc 的 root qdisc 作用在 egress。那如果我要限制别的机器发给我的流量怎么办答案是 ifbIntermediate Functional Block虚拟网卡。思路是这样的用 ingress qdisc 把入向的包抓出来通过 mirred 动作重定向到 ifb0 这块虚拟网卡上。因为对 ifb0 来说这些包是发送方向的所以就能正常挂 HTB 和 netem 来整形了。整完形之后再从物理网卡发出去实际上包已经到本机了只是处理流程上被绕了一圈。# 加载模块 modprobe ifb numifbs1 # 启动虚拟网卡 ip link set dev ifb0 up # 在物理网卡上挂 ingress qdisc tc qdisc add dev eth0 handle ffff: ingress # 把所有入向流量重定向到 ifb0 tc filter add dev eth0 parent ffff: protocol ip u32 \ match u32 0 0 action mirred egress redirect dev ifb0 # 现在可以像操作普通网卡一样操作 ifb0 了 tc qdisc add dev ifb0 root handle 2: htb default 999 tc class add dev ifb0 parent 2: classid 2:1 htb rate 100mbit tc class add dev ifb0 parent 2:1 classid 2:10 htb rate 5mbit ceil 5mbit tc filter add dev ifb0 protocol ip parent 2:0 prio 1 u32 \ match ip src 192.168.1.100/32 flowid 2:10match u32 0 0是 u32 的写法意思是匹配所有包这两个 0 分别代表值和掩码都为 0等价于无条件匹配。这条命令很容易记混写错一个字符就匹配不上。5.2 ifb 的几个实操要点ifb 好用但有几个点必须注意。第一ingress qdisc 和 root qdisc 是两套独立的东西。一个网卡上可以有root和ffff:两个 qdisc 同时存在它们互不干扰。入向的走 ifb出向的走 root配的时候别搞混。第二ifb 设备默认只有一个 ifb0要用多个得改 numifbs。一般场景一个就够。如果你要分别处理不同来源的流量用一个 ifb0 加多组 class filter 就足够了不用开多块虚拟网卡。第三redirect 是单向的。包被重定向到 ifb0 之后处理完会继续往协议栈上层走不会卡住。但如果你同时给物理网卡装了 iptables 规则要注意规则是在 redirect 之前还是之后生效顺序不一样结果不一样。iptables 的 mangle 表规则作用在 tc 之前nat 表则在更早的阶段这块如果排查起来比较绕建议一次只开一层确认没问题再加下一层。第四主机的内核要支持 ifb 模块。大多数发行版都带容器环境里可能没有需要宿主机先加载好模块再把 veth 挂进去。容器里做弱网测试更简单的做法是在宿主机上对容器的 veth 做 egress 限制效果是一样的。5.3 用 iperf3 和 ping 验证效果命令敲完不代表成功必须验证。验证工具就两个iperf3 测带宽ping 测延迟和丢包。# 服务端 iperf3 -s # 客户端跑 30 秒4 条并发流 iperf3 -c 192.168.1.10 -t 30 -P 4输出里看 Sender 那一行的 Bitrate是不是稳定在限速值附近。如果限速 5mbit 但跑出 5.2mbit属于正常浮动TCP 开销如果跑出 10mbit那说明限速根本没生效。# 延迟测试20 个包 ping -c 20 192.168.1.10 # 看统计里的 avg、mdev、lossmdev就是抖动值配了delay 100ms 20ms之后avg 应该在 200ms 左右mdev 在 20ms 到 40ms 之间波动。loss 要和 netem 配的丢包率对得上。还可以直接用 tc 自带的统计来看tc -s qdisc show dev eth0 tc -s class show dev eth0 tc -s filter show dev eth0filter 那一段里的Sent计数如果一直是 0说明 filter 压根没匹配上包问题多半出在掩码写错、方向搞反、或者 handle 进制弄混。这是排查 tc 问题的第一步先看 filter 命中没有再看 class 的限速生效没有最后看 qdisc 的丢包计数一层一层往下查。6. 常见问题与排查技巧实录6.1 命令没报错但就是不生效这是最高频的问题。命令执行返回 0tc qdisc show也能看到规则但实际测速毫无变化。我遇到过很多次原因基本集中在下面几个。网卡写错了。机器上有 eth0、eth1、docker0、lo 一堆网卡你把规则加在 eth0 上实际流量走的是 eth1。用ip route get 8.8.8.8看默认路由走哪块网卡或者直接ip -s link对比各网卡的发包计数就知道真实出口是哪块。filter 没命中。前面说过先看tc -s filter show dev eth0Sent 计数是不是在涨。不涨就是匹配规则有问题IP 掩码忘了写/32、端口写成主机字节序、方向ip dst写成了ip src。端口匹配这块还有个小坑u32 里匹配端口的值要写成 16 进制并且注意字节序像match ip dport 8080 0xffff这种写法在多数场景下没问题但如果遇到匹配不上可以试试 flower它会自动处理字节序。对端做了限速。你在 A 上给 B 限速但如果 B 本身带宽就比限速值低那自然看不出区别。测试之前先不加任何规则跑一遍 iperf3看看基线速度是多少再决定限速值。容器里的 veth 没对准。容器网络里每个容器的 veth 对一端在容器里叫 eth0另一端在宿主机上叫 vethxxxx。你要限的是宿主机上那一端还是容器里那一端效果完全不同。经验是限容器发出去的流量在容器的 eth0 上做 egress 最简单限容器收进来的流量在宿主机的 veth 上做 egress 更直接。6.2 问题速查表我把这些年遇到过的典型问题和解决方法整理成一张表出问题时按这个顺序查。现象可能原因排查方法解决方式限速完全无效网卡名写错ip route get 8.8.8.8改到正确网卡filter 计数为 0匹配规则错tc -s filter show检查 mask、方向、进制限速后大量丢包burst 给得太小看 qdisc 的 dropped 计数burst 提到 rate×10ms限速后带宽超标burst 给得太大对比 rate 和实际值缩小 burst 和 cburstfw filter 不生效handle 进制问题打印 filter 配置写成handle 0x10入向限制没反应没用 ifbtc qdisc show dev ifb0配 ingress mirred重启后规则消失tc 不持久化重启后tc qdisc show写进 rc.local 或 systemd加延迟后 RTT 翻倍出和回各过一次ping 观察属正常不用改多队列网卡只生效一半root qdisc 只在队列 0tc qdisc show看是否多行用 mq 每队列配最后一行解释一下现代服务器网卡一般有多个发送队列硬件上会并行处理。默认tc qdisc add dev eth0 root只作用在第一个队列上其他队列的流量不受影响。如果你发现限速只有一部分生效可以先用ethtool -l eth0看队列数然后用mqqdisc 给每个队列单独配限速规则。这是高阶用法日常测试机单队列居多碰到的概率不大但生产环境做精确限速时一定要留意。6.3 我的几条避坑经验先删后加别硬 replace。反复调参的时候用tc qdisc del dev eth0 root清干净再加比用replace靠谱。因为 netem 和 HTB 的参数结构不一样从一个换成另一个时 replace 有时会保留旧参数导致行为诡异。把命令写成脚本别手敲。tc 命令长、参数多手敲一次错一个字符排查半天。我习惯把完整的配置写成一个setup.sh把清理写成一个cleanup.sh出问题先跑 cleanup 再跑 setup环境永远是干净的。netem 只在测试机用别上生产。生产环境需要限速就用 HTB不要挂 netem。netem 的延迟会显著增加排队时间CPU 开销也比单纯限速大几个 G 的流量下延迟会把你整台机的网络拖慢。弱网模拟一定在隔离的测试环境做。虚拟化环境里效果会打折。在 KVM、VirtualBox 这类虚拟机上做精确限速结果往往和物理机有差异因为虚拟网卡的处理路径和物理网卡不完全一样。做严谨的带宽测试尽量用物理机或者在宿主机的物理网卡上做整形别在虚机内部做。记得算上协议开销。你限速 100mbit实际 TCP 吞吐大概只能跑到 94mbit 左右因为 IP 头、TCP 头占了开销。这不是 bug是正常现象。做验收时留 5% 到 8% 的余量别拿 100mbit 去卡 100mbit。7. 规则持久化与清理7.1 让规则在重启后依然生效tc 的规则是纯内存的重启就没了。生产环境要做持久化有三种做法。最简单的是塞进/etc/rc.local在exit 0之前加上你的 tc 命令。缺点是没有依赖管理网卡如果启动得晚命令会失败。更规范的是写 systemd 服务[Unit] DescriptionTC Traffic Shaping Afternetwork-online.target Wantsnetwork-online.target [Service] Typeoneshot RemainAfterExityes ExecStart/usr/local/bin/tc-setup.sh ExecStop/usr/local/bin/tc-cleanup.sh [Install] WantedBymulti-user.target配合前面的 setup.sh 和 cleanup.sh 两个脚本systemctl start tc-shaping加载规则systemctl stop tc-shaping清空规则非常干净。注意脚本里网卡名不要写死用变量从配置里读换机器的时候改一处就行。第三种是用发行版自带的网络管理工具比如 NetworkManager 的 dispatcher 脚本网卡 up 的时候触发。这种方式能确保网卡已经就绪适合多网卡、频繁插拔的场景。我个人最推荐 systemd 这套可控、可查、可回滚。7.2 一键清理的正确姿势清理看着简单其实也有讲究。清理顺序要从叶子往根清先删 filter再删子 qdisc最后删根 qdisc。实际上直接删根 qdisc 会把整棵树上挂的东西全部带走所以大多数时候一条命令就够tc qdisc del dev eth0 root 2/dev/null tc qdisc del dev eth0 ingress 2/dev/null tc qdisc del dev ifb0 root 2/dev/null ip link set dev ifb0 down 2/dev/null加2/dev/null是为了让脚本在规则本来就不存在时不报错方便重复执行。ifb0 处理完之后建议 down 掉不然它会一直挂着占用资源。清理完务必验证一下tc qdisc show dev eth0 # 应该看到只有默认的 fq_codel 或者 pfifo_fast如果你忘了清理就直接改规则最常见的结果是两个 qdisc 规则叠加延迟翻倍、限速值打架。所以养成习惯改之前先清清完再改。写到这里把 tc 这套东西从概念到落地基本都过了一遍。我个人在几个不同项目里长期用下来感受最深的一点是tc 的命令本身不难难的是一开始不知道自己在干什么抄一条命令跑不通就换下一条越换越乱。真正把 qdisc、class、filter 这三层和 egress 这个方向搞清楚之后不管你面对的是限速、延迟还是丢包本质上都是往同一个框架里填参数。另一个小心得是手上永远留一份能一键清空的 cleanup 脚本比什么都重要——我见过太多次因为规则叠加导致测试结论完全跑偏的情况最后花的时间比配置本身还多。测之前先跑基线改完立刻用 iperf3 和 tc 的统计交叉验证这两步做到位基本不会再被 tc 坑。