Linux 带宽跑满的分析思路

先确认带宽是否真跑满：用ethtool查网卡速率，sar -n DEV看txkB/s并换算为Mbps，iperf3多流测试吞吐，iftop与nethogs两级追踪进程，检查中断分布、连接队列溢出及TCP缓冲区与拥塞算法匹配业务特征。

先确认是不是真跑满了

别急着调参，先看清楚带宽到底有没有被吃光。很多“跑满”其实是错觉：比如 iftop 显示某 IP 占了 900Mbps，但网卡实际是 10Gbps，那根本没瓶颈；又或者 iperf3 -c 测出来只有 200Mbps，却看到 txkB/s 在 sar -n DEV 1 5 里飙到 120MB/s（≈960Mbps），这时得核对单位——sar 输出是 KB/s，不是 Kbit/s。

• 查网卡理论速率：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 到进程的两级追踪

带宽被谁用了？不能只靠 iftop 看个 IP 就封，得闭环到具体进程。常见陷阱是：看到大量 192.168.1.5:443 流量，以为是 https 服务，结果 nethogs eth0 一跑，发现是某个 python 脚本在后台轮询 API，根本不是 Web 服务器本身。

• iftop -i eth0 -P：按连接排序，暂停（P键）记下高流量端口
• nethogs -d 2 eth0：直接显示进程名+PID+实时速率，支持按流量排序（↑/↓）
• 若 nethogs 不可用或权限受限，用 ss -tunlp | grep :PORT 反查端口归属进程

排除内核与协议栈层面的隐形损耗

流量确实来自合法进程，但带宽还是上不去？很可能是内核“自己卡住了”。比如 /proc/interrupts 里 eth0-TxRx-0 中断全挤在 CPU0 上，其他核空转；或者 netstat -s | grep "listen drops" 输出非零，说明 SYN 包在进内核前就被丢弃了——这和应用层代码无关，是 net.core.somaxconn 或网卡 Ring Buffer 太小导致的。

• 查中断分布：watch -n1 'cat /proc/interrupts | grep eth0'，观察各 CPU 列数值是否严重不均
• 调大接收缓冲：ethtool -G eth0 rx 4096 tx 4096（需驱动支持，部分虚拟网卡不生效）
• 检查连接队列溢出：netstat -s | grep -i "listen.*drops|retransmit"，值持续增长就要调 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog

别让 TCP 参数成为带宽天花板

1Gbps 网络 + 30ms RTT，BDP ≈ 3.75MB，但默认 net.ipv4.tcp_rmem 最大才 4MB，表面够用，实际因窗口缩放未稳定启用或应用未设 SO_RCVBUF，真实接收窗口可能卡在 64KB。这时候再怎么加大带宽，单流也跑不满。

• 必须开窗口缩放：sysctl net.ipv4.tcp_window_scaling=1
• 缓冲区三元组按 BDP 设：net.ipv4.tcp_rmem = "4096 262144 8388608"（最后值 ≈ BDP × 1.2）
• 强制应用使用大缓冲：echo 'net.core.rmem_max = 8388608' >> /etc/sysctl.conf，否则某些程序会受限于默认 212992
• 拥塞算法换 bbr：sysctl net.ipv4.tcp_congestion_control=bbr，比 cubic 在丢包波动时更稳

真正难的不是改哪几行 sysctl，而是理解你的业务流量特征：是长连接大文件下载？还是短连接高并发 API？前者要调缓冲区和 TIME_WaiT 复用，后者得压 tcp_fin_timeout 和扩 ip_local_port_range。参数没有通用解，只有匹配场景的解。