带宽跑满需先区分真饱和、假报警或内核/配置瓶颈，核心是定位流量来源、排查协议栈隐性问题并科学限速。具体分四步：一查网卡真实速率与实时吞吐；二用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
