带宽跑满需先区分真饱和、假报警或内核 / 配置瓶颈，核心是定位流量来源、排查协议栈隐性问题并科学限速。具体分四步：一查网卡真实速率与实时吞吐；二用 iftop/nethogs 追踪 ip 至进程；三检中断均衡、连接队列丢包及 tcp 窗口；四用 tbf 或 cgroup2 合理限速，避免误配恶化性能。
带宽跑满不是“网卡亮红灯”就完事，得先分清是真饱和、假报警，还是被内核或配置拖了后腿。重点不在“限速”，而在“看清谁在用、为什么用不满、哪里卡住了”。
一、确认是不是真跑满了
很多所谓“跑满”，其实是单位看错、网卡速率误判或测试方法不对。
- 查网卡真实速率 ：运行
ethtool eth0 | grep Speed，确认是 1G/10G/25G，别把协商速率当瓶颈 - 看实时出向流量 ：用
sar -n DEV 1 5 | grep eth0，盯txkB/s值，换算成 Mbps（×8÷1000），和网卡理论带宽比对 - 测端到端吞吐 ：服务端跑
iperf3 -s -B 10.0.0.10，客户端用iperf3 -c 10.0.0.10 -P 8 -t 30，单流容易被窗口限制，多流才能暴露调度或缓冲问题
二、定位流量来源：从 IP 到进程闭环追踪
看到高流量 IP 不能直接拉黑，得落到具体进程，否则可能误杀业务脚本。
- 按连接看分布 ：运行
iftop -i eth0 -P，暂停（P 键）记下高流量端口 - 直击进程级消耗 ：用
nethogs -d 2 eth0，显示进程名、PID、实时速率，支持↑/↓排序；若权限受限，可用ss -tunlp | grep :PORT反查端口归属 - 抓包辅助验证 ：必要时
tcpdump -i eth0 -c 100 port 443抓少量包，确认协议和载荷是否符合预期（如是不是大量小文件轮询）
三、检查内核与协议栈隐性瓶颈
流量来自合法进程，但带宽就是上不去？可能是中断不均、队列溢出或 TCP 窗口卡死。
- 看中断是否偏科 ：运行
watch -n1 'cat /proc/interrupts | grep eth0'，观察各 CPU 列数值是否严重倾斜（如 90% 集中在 CPU0） - 查连接队列丢包 ：执行
netstat -s | grep -i "listen.*drops|retransmit"，值持续增长说明 SYN 或数据包在进内核前就被丢弃，需调net.core.somaxconn和net.ipv4.tcp_max_syn_backlog - 验 TCP 窗口是否够用 ：1Gbps + 30ms RTT → BDP ≈ 3.75MB，但默认
tcp_rmem最大仅约 6MB，且若未启用窗口缩放（net.ipv4.tcp_window_scaling=1）或应用未设SO_RCVBUF，实际窗口可能卡在 64KB
四、合理限速：避免越限越卡
限速不是加个 tc 命令就完事，选错 qdisc、绑错方向或 burst 设太小，反而导致 ACK 丢包、吞吐骤降。
- 全局限速优先用 TBF：如限 100Mbps 出口，
tc qdisc add dev eth0 root tbf rate 100mbit burst 1600kbit latency 50ms；注意必须用root，不能用parent - 按进程限速用 cgroup2+clsact：创建 cgroup 并写入
net_cls.classid，再挂tc qdisc add dev eth0 clsact，配合tc filter add …… classid绑定，比按 IP/ 端口更精准 - 别碰 ingress 和 pfifo_fast：限速只对 egress 生效；默认 qdisc（pfifo_fast）不支持速率控制，必须显式指定 tbf 或 htb
